[PATCH 0/2] arc: hsdk_defconfig: permit kernelci jobs

[PATCH 0/2] arc: hsdk_defconfig: permit kernelci jobs

[Corentin Labbe]

Hello

In our kernelci lab, we have one hsdk device and since it is the only
ARC device at our disposal, it is important to made it availlable for
kernelci boot jobs.

Since kernelci build only defconfig without hacking it, it is important
that defconfig are bootable by default.
And so for hsdk_defconfig, it miss two CONFIGs for let hsdk boot.

Thanks
Regards

Corentin Labbe (2):
  arc: hsdk_defconfig: Enable CONFIG_BLK_DEV_RAM
  arc: hsdk_defconfig: enable CONFIG_ARC_UBOOT_SUPPORT

 arch/arc/configs/hsdk_defconfig | 2 ++
 1 file changed, 2 insertions(+)

-- 
2.19.2

[PATCH 1/2] arc: hsdk_defconfig: Enable CONFIG_BLK_DEV_RAM

[Corentin Labbe]

We have now a HSDK device in our kernelci lab, but kernel builded via
the hsdk_defconfig lacks ramfs supports, so it cannot boot kernelci jobs
yet.

So this patch enable CONFIG_BLK_DEV_RAM in hsdk_defconfig.

Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
---
 arch/arc/configs/hsdk_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arc/configs/hsdk_defconfig b/arch/arc/configs/hsdk_defconfig
index 6fd3d29546af..0e5fd29ed238 100644
--- a/arch/arc/configs/hsdk_defconfig
+++ b/arch/arc/configs/hsdk_defconfig
@@ -8,6 +8,7 @@ CONFIG_NAMESPACES=y
 # CONFIG_UTS_NS is not set
 # CONFIG_PID_NS is not set
 CONFIG_BLK_DEV_INITRD=y
+CONFIG_BLK_DEV_RAM=y
 CONFIG_EMBEDDED=y
 CONFIG_PERF_EVENTS=y
 # CONFIG_VM_EVENT_COUNTERS is not set
-- 
2.19.2

[PATCH 2/2] arc: hsdk_defconfig: enable CONFIG_ARC_UBOOT_SUPPORT

[Corentin Labbe]

We have now a HSDK device in our kernelci lab, but kernel builded via
the hsdk_defconfig ignore bootargs, so it cannot boot kernelci jobs yet.
Furthermore, I think the probability is that devices will be booted more via
uboot than by a debugger.

So this patch enable CONFIG_ARC_UBOOT_SUPPORT in hsdk_defconfig.

Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
---
 arch/arc/configs/hsdk_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arc/configs/hsdk_defconfig b/arch/arc/configs/hsdk_defconfig
index 0e5fd29ed238..b80e3ac5c93c 100644
--- a/arch/arc/configs/hsdk_defconfig
+++ b/arch/arc/configs/hsdk_defconfig
@@ -9,6 +9,7 @@ CONFIG_NAMESPACES=y
 # CONFIG_PID_NS is not set
 CONFIG_BLK_DEV_INITRD=y
 CONFIG_BLK_DEV_RAM=y
+CONFIG_ARC_UBOOT_SUPPORT=y
 CONFIG_EMBEDDED=y
 CONFIG_PERF_EVENTS=y
 # CONFIG_VM_EVENT_COUNTERS is not set
-- 
2.19.2

Re: [PATCH 2/2] arc: hsdk_defconfig: enable CONFIG_ARC_UBOOT_SUPPORT

[Eugeniy Paltsev]

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.

On Tue, 2019-02-05 at 08:32 +0000, Corentin Labbe wrote:
> We have now a HSDK device in our kernelci lab, but kernel builded via
> the hsdk_defconfig ignore bootargs, so it cannot boot kernelci jobs yet.
> Furthermore, I think the probability is that devices will be booted more via
> uboot than by a debugger.
> 
> So this patch enable CONFIG_ARC_UBOOT_SUPPORT in hsdk_defconfig.
> 
> Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
> ---
>  arch/arc/configs/hsdk_defconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arc/configs/hsdk_defconfig b/arch/arc/configs/hsdk_defconfig
> index 0e5fd29ed238..b80e3ac5c93c 100644
> --- a/arch/arc/configs/hsdk_defconfig
> +++ b/arch/arc/configs/hsdk_defconfig
> @@ -9,6 +9,7 @@ CONFIG_NAMESPACES=y
>  # CONFIG_PID_NS is not set
>  CONFIG_BLK_DEV_INITRD=y
>  CONFIG_BLK_DEV_RAM=y
> +CONFIG_ARC_UBOOT_SUPPORT=y
>  CONFIG_EMBEDDED=y
>  CONFIG_PERF_EVENTS=y
>  # CONFIG_VM_EVENT_COUNTERS is not set
-- 
 Eugeniy Paltsev

Re: [PATCH 2/2] arc: hsdk_defconfig: enable CONFIG_ARC_UBOOT_SUPPORT

[Vineet Gupta]

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.

-Vineet

RE: [PATCH 2/2] arc: hsdk_defconfig: enable CONFIG_ARC_UBOOT_SUPPORT

[Alexey Brodkin]

Hi Vineet, Corentin,

> -----Original Message-----
> From: Vineet Gupta <vgupta@synopsys.com>
> Sent: Tuesday, February 5, 2019 7:42 PM
> To: Eugeniy Paltsev <paltsev@synopsys.com>; clabbe@baylibre.com
> Cc: linux-kernel@vger.kernel.org; alexey.brodkin@synopsys.com; khilman@baylibre.com; linux-snps-
> arc@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.

-Alexey

RE: [PATCH 2/2] arc: hsdk_defconfig: enable CONFIG_ARC_UBOOT_SUPPORT

[Kevin Hilman]

Alexey Brodkin <alexey.brodkin@synopsys.com> writes:

> Hi Vineet, Corentin,
>
>> -----Original Message-----
>> From: Vineet Gupta <vgupta@synopsys.com>
>> Sent: Tuesday, February 5, 2019 7:42 PM
>> To: Eugeniy Paltsev <paltsev@synopsys.com>; clabbe@baylibre.com
>> Cc: linux-kernel@vger.kernel.org; alexey.brodkin@synopsys.com; khilman@baylibre.com; linux-snps-
>> arc@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