Alexey Brodkin <alexey.brodkin@xxxxxxxxxxxx> writes: > Hi Vineet, Corentin, > >> -----Original Message----- >> From: Vineet Gupta <vgupta@xxxxxxxxxxxx> >> Sent: Tuesday, February 5, 2019 7:42 PM >> To: Eugeniy Paltsev <paltsev@xxxxxxxxxxxx>; clabbe@xxxxxxxxxxxx >> Cc: linux-kernel@xxxxxxxxxxxxxxx; alexey.brodkin@xxxxxxxxxxxx; khilman@xxxxxxxxxxxx; linux-snps- >> arc@xxxxxxxxxxxxxxxxxxx >> 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@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/linux-snps-arc
