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
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 <[email protected]>
---
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
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 <[email protected]>
---
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
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 <[email protected]>
> ---
> 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
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
Hi Vineet, Corentin,
> -----Original Message-----
> From: Vineet Gupta <[email protected]>
> Sent: Tuesday, February 5, 2019 7:42 PM
> To: Eugeniy Paltsev <[email protected]>; [email protected]
> Cc: [email protected]; [email protected]; [email protected]; linux-snps-
> [email protected]
> 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
Alexey Brodkin <[email protected]> writes:
> Hi Vineet, Corentin,
>
>> -----Original Message-----
>> From: Vineet Gupta <[email protected]>
>> Sent: Tuesday, February 5, 2019 7:42 PM
>> To: Eugeniy Paltsev <[email protected]>; [email protected]
>> Cc: [email protected]; [email protected]; [email protected]; linux-snps-
>> [email protected]
>> 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