Alexey Brodkin <alexey.brod...@synopsys.com> writes: > Hi Vineet, Corentin, > >> -----Original Message----- >> From: Vineet Gupta <vgu...@synopsys.com> >> Sent: Tuesday, February 5, 2019 7:42 PM >> To: Eugeniy Paltsev <palt...@synopsys.com>; cla...@baylibre.com >> Cc: linux-ker...@vger.kernel.org; alexey.brod...@synopsys.com; >> khil...@baylibre.com; linux-snps- >> a...@lists.infradead.org >> Subject: Re: [PATCH 2/2] arc: hsdk_defconfig: enable CONFIG_ARC_UBOOT_SUPPORT >> >> On 2/5/19 3:42 AM, Eugeniy Paltsev wrote: >> > Hi Corentin, >> > >> > In case of devboards (like HSDK) we really often disable bootloader and >> > load >> > Linux image in memory via JTAG. Enabling CONFIG_ARC_UBOOT_SUPPORT by >> > default will break it as we will try to interpret some junk in a registers >> > as a pointers to bootargs/etc which aren't set by anyone in case of JTAG >> > using. >> > >> > So it isn't a good idea to have CONFIG_ARC_UBOOT_SUPPORT enabled by >> > default. >> >> Right. >> >> It is difficult to accommodate everyone's needs (often conflicting) in a >> single >> defconfig. >> Can you folks create an out-of-tree defconfig or some such. > > I do think there's a proper solution which [hopefully] makes both parties > happy. > Eugeniy is about to send-out a patch which allows us to not care about > garbage in R0/R2 when running after U-Boot.
OK, cool, that sounds like a good workaround for the JTAG use case. Just curious: what is the more common case for end-users? u-boot or JTAG? At least on every other arch/board we use in kernelCI, u-boot is the *much* more common load path than JTAG. IMO, I would suggest that in the case of unresolvable conflicts like, u-boot should be the normal path, and JTAG would be the special case. Anyways, hopefully the patch from Eugeniy works and gets rid of the conflict. Related: if you end up accepting this series, they'll also need to be backported to stable branches if we want to support them in kernelCI. Kevin _______________________________________________ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
