From: khilman@baylibre.com (Kevin Hilman)
To: linux-snps-arc@lists.infradead.org
Subject: [PATCH 2/2] arc: hsdk_defconfig: enable CONFIG_ARC_UBOOT_SUPPORT
Date: Tue, 05 Feb 2019 12:14:12 -0800 [thread overview]
Message-ID: <7h4l9ivvqj.fsf@baylibre.com> (raw)
In-Reply-To: <4881796E12491D4BB15146FE0209CE64681D4DC3@DE02WEMBXB.internal.synopsys.com>
Alexey Brodkin <alexey.brodkin at synopsys.com> writes:
> Hi Vineet, Corentin,
>
>> -----Original Message-----
>> From: Vineet Gupta <vgupta at synopsys.com>
>> Sent: Tuesday, February 5, 2019 7:42 PM
>> To: Eugeniy Paltsev <paltsev at synopsys.com>; clabbe at baylibre.com
>> Cc: linux-kernel at vger.kernel.org; alexey.brodkin at synopsys.com; khilman at baylibre.com; linux-snps-
>> arc at 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
prev parent reply other threads:[~2019-02-05 20:14 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-05 8:32 [PATCH 0/2] arc: hsdk_defconfig: permit kernelci jobs Corentin Labbe
2019-02-05 8:32 ` [PATCH 1/2] arc: hsdk_defconfig: Enable CONFIG_BLK_DEV_RAM Corentin Labbe
2019-02-05 8:32 ` [PATCH 2/2] arc: hsdk_defconfig: enable CONFIG_ARC_UBOOT_SUPPORT Corentin Labbe
2019-02-05 11:42 ` Eugeniy Paltsev
2019-02-05 16:42 ` Vineet Gupta
2019-02-05 16:51 ` Alexey Brodkin
2019-02-05 20:14 ` Kevin Hilman [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7h4l9ivvqj.fsf@baylibre.com \
--to=khilman@baylibre.com \
--cc=linux-snps-arc@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox