Re: [PATCH] usb: dwc3-generic: Ensure reset GPIO is configured as an output

[Marek Vasut]

On 6/28/23 14:26, Peter Korsgaard wrote:

GPIOD_ACTIVE_LOW is not enough to configure a GPIO as an output, we need
GPIOD_IS_OUT as well.

Fixes: b252d79b0936d60b ("usb: dwc3: Add support to reset usb ULPI phy")
Signed-off-by: Peter Korsgaard 


Applied to usb/master, thanks !

[PATCH v2] ARM: imx: romapi: Fix signed integer bitwise ops misuse

[Marek Vasut]

Bitwise operations on signed integers are not defined,
replace them with per-call checks.

Reviewed-by: Peng Fan 
Signed-off-by: Marek Vasut 
---
Cc: "NXP i.MX U-Boot Team" 
Cc: Fabio Estevam 
Cc: Heiko Schocher 
Cc: Heinrich Schuchardt 
Cc: Rasmus Villemoes 
Cc: Simon Glass 
Cc: Stefano Babic 
Cc: Tom Rini 
Cc: Ye Li 
---
V2: - s@then@them@
- Add RB from Peng
---
 arch/arm/mach-imx/spl_imx_romapi.c | 32 --
 1 file changed, 21 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-imx/spl_imx_romapi.c 
b/arch/arm/mach-imx/spl_imx_romapi.c
index 9164045115f..4af41699678 100644
--- a/arch/arm/mach-imx/spl_imx_romapi.c
+++ b/arch/arm/mach-imx/spl_imx_romapi.c
@@ -76,13 +76,16 @@ static int spl_romapi_load_image_seekable(struct 
spl_image_info *spl_image,
u32 image_offset;
 
ret = rom_api_query_boot_infor(QUERY_IVT_OFF, &offset);
-   ret |= rom_api_query_boot_infor(QUERY_PAGE_SZ, &pagesize);
-   ret |= rom_api_query_boot_infor(QUERY_IMG_OFF, &image_offset);
+   if (ret != ROM_API_OKAY)
+   goto err;
 
-   if (ret != ROM_API_OKAY) {
-   puts("ROMAPI: Failure query boot infor pagesize/offset\n");
-   return -1;
-   }
+   ret = rom_api_query_boot_infor(QUERY_PAGE_SZ, &pagesize);
+   if (ret != ROM_API_OKAY)
+   goto err;
+
+   ret = rom_api_query_boot_infor(QUERY_IMG_OFF, &image_offset);
+   if (ret != ROM_API_OKAY)
+   goto err;
 
header = (struct legacy_img_hdr *)(CONFIG_SPL_IMX_ROMAPI_LOADADDR);
 
@@ -124,6 +127,10 @@ static int spl_romapi_load_image_seekable(struct 
spl_image_info *spl_image,
}
 
return 0;
+
+err:
+   puts("ROMAPI: Failure query boot infor pagesize/offset\n");
+   return -1;
 }
 
 static ulong spl_ram_load_read(struct spl_load_info *load, ulong sector,
@@ -344,12 +351,12 @@ int board_return_to_bootrom(struct spl_image_info 
*spl_image,
u32 boot, bstage;
 
ret = rom_api_query_boot_infor(QUERY_BT_DEV, &boot);
-   ret |= rom_api_query_boot_infor(QUERY_BT_STAGE, &bstage);
+   if (ret != ROM_API_OKAY)
+   goto err;
 
-   if (ret != ROM_API_OKAY) {
-   puts("ROMAPI: failure at query_boot_info\n");
-   return -1;
-   }
+   ret = rom_api_query_boot_infor(QUERY_BT_STAGE, &bstage);
+   if (ret != ROM_API_OKAY)
+   goto err;
 
printf("Boot Stage: ");
 
@@ -374,4 +381,7 @@ int board_return_to_bootrom(struct spl_image_info 
*spl_image,
return spl_romapi_load_image_stream(spl_image, bootdev);
 
return spl_romapi_load_image_seekable(spl_image, bootdev, boot);
+err:
+   puts("ROMAPI: failure at query_boot_info\n");
+   return -1;
 }
-- 
2.40.1

[PATCH v5] dt-bindings: riscv: deprecate riscv,isa

[Conor Dooley]

From: Conor Dooley 

intro
=

When the RISC-V dt-bindings were accepted upstream in Linux, the base
ISA etc had yet to be ratified. By the ratification of the base ISA,
incompatible changes had snuck into the specifications - for example the
Zicsr and Zifencei extensions were spun out of the base ISA.

Fast forward to today, and the reason for this patch.
Currently the riscv,isa dt property permits only a specific subset of
the ISA string - in particular it excludes version numbering.
With the current constraints, it is not possible to discern whether
"rv64i" means that the hart supports the fence.i instruction, for
example.
Future systems may choose to implement their own instruction fencing,
perhaps using a vendor extension, or they may not implement the optional
counter extensions. Software needs a way to determine this.

versioning schemes
==

"Use the extension versions that are described in the ISA manual" you
may say, and it's not like this has not been considered.
Firstly, software that parses the riscv,isa property at runtime will
need to contain a lookup table of some sort that maps arbitrary versions
to versions it understands. There is not a consistent application of
version number applied to extensions, with a higgledy-piggledy
collection of tags, "bare" and versioned documents awaiting the reader
on the "recently ratified extensions" page:
https://wiki.riscv.org/display/HOME/Recently+Ratified+Extensions

As an aside, and this is reflected in the patch too, since many
extensions have yet to appear in a release of the ISA specs,
they are defined by commits in their respective "working draft"
repositories.

Secondly, there is an issue of backwards compatibility, whereby allowing
numbers in the ISA string, some parsers may be broken. This would
require an additional property to be created to even use the versions in
this manner.

~boolean properties~ string array property
==

If a new property is needed, the whole approach may as well be looked at
from the bottom up. A string with limited character choices etc is
hardly the best approach for communicating extension information to
software.

Switching to using properties that are defined on a per extension basis,
allows us to define explicit meanings for the DT representation of each
extension - rather than the current situation where different operating
systems or other bits of software may impart different meanings to
characters in the string.
Clearly the best source of meanings is the specifications themselves,
this just provides us the ability to choose at what point in time the
meaning is set. If an extension changes incompatibility in the future,
a new property will be required.

Off-list, some of the RVI folks have committed to shoring up the wording
in either the ISA specifications, the riscv-isa-manual or
so that in the future, modifications to and additions or removals of
features will require a new extension. Codifying that assertion
somewhere would make it quite unlikely that compatibility would be
broken, but we have the tools required to deal with it, if & when it
crops up.
It is in our collective interest, as consumers of extension meanings, to
define a scheme that enforces compatibility.

The use of individual elements, rather than a single string, will also
permit validation that the properties have a meaning, as well as
potentially reject mutually exclusive combinations, or enforce
dependencies between extensions. That would not have be possible with
the current dt-schema infrastructure for arbitrary strings, as we would
need to add a riscv,isa parser to dt-validate!
That's not implemented in this patch, but rather left as future work (for
the brave, or the foolish).

parser simplicity
=

Many systems that parse DT at runtime already implement an function that
can check for the presence of a string in an array of string, as it is
similar to the process for parsing a list of compatible strings, so a
bunch of new, custom, DT parsing should not be needed.
Getting rid of "riscv,isa" parsing would be a nice simplification, but
unfortunately for backwards compatibility with old dtbs, existing
parsers may not be removable - which may greatly simplify
dt parsing code. In Linux, for example, checking for whether a hart
supports an extension becomes as simple as:
of_property_match_string(node, "riscv,isa-extensions", "zicbom")

vendor extensions
=

Compared to riscv,isa, this proposed scheme promotes vendor extensions,
oft touted as the strength of RISC-V, to first-class citizens.
At present, extensions are defined as meaning what the RISC-V ISA
specifications say they do. There is no realistic way of using that
interface to provide cross-platform definitions for what vendor
extensions mean. Vendor extensions may also have even less consistency
than RVI do in terms of versioning, or no care about backwards
com

Re: [PATCH] bootstd: USB devtype detection for script boot

[Simon Glass]

On Sat, 1 Jul 2023 at 20:10, Simon Glass  wrote:
>
> On Fri, 30 Jun 2023 at 18:50, John Clark  wrote:
> >
> > Change the device type from "usb_mass_storage" to "usb" when
> > booting a script.
> >
> > Before this change:
> >=> printenv devtype
> >devtype=usb_mass_storage
> >
> > After this change:
> >=> printenv devtype
> >devtype=usb
> >
> > Signed-off-by: John Clark 
> > ---
> >
> >  boot/bootmeth_script.c | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
>
> Reviewed-by: Simon Glass 
> Fixes d9409244 ("bootstd: Add an implementation of script boot")

I mean:
Fixes: d9409244 ("bootstd: Add an implementation of script boot")

Re: [PATCH] bootstd: USB devtype detection for script boot

[Simon Glass]

On Fri, 30 Jun 2023 at 18:50, John Clark  wrote:
>
> Change the device type from "usb_mass_storage" to "usb" when
> booting a script.
>
> Before this change:
>=> printenv devtype
>devtype=usb_mass_storage
>
> After this change:
>=> printenv devtype
>devtype=usb
>
> Signed-off-by: John Clark 
> ---
>
>  boot/bootmeth_script.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)

Reviewed-by: Simon Glass 
Fixes d9409244 ("bootstd: Add an implementation of script boot")

Re: How u-boot can chain "grub" and booting a mainline kernel on my ARM Chromebook

[Mario Marietto]

Hello.

I've been able to understand what was the X variable,the component that
allows the hexdump0815 ubuntu iso images to boot correctly : it is
syslinux. So,now I know what I should do : to try to chainload the u-boot
installed on the first partition with syslinux,installed on the 4 partition
I think,I don't know. I would like to understand if this task can be
accomplished or not.

On Sat, Jul 1, 2023 at 3:25 PM Mario Marietto 
wrote:

> ok. Can we come back to the main problem,please ? Is there a method to do
> what I want ? Is there some kind of technique ? Very thanks.
>
> On Sat, Jul 1, 2023 at 2:57 PM Mario Marietto 
> wrote:
>
>> Some days ago I successfully compiled the kernel version. 5.4.244 with
>> all the kvm flags enabled and the exynos 5250-snow.dtb file.
>>
>> On Sat, Jul 1, 2023 at 2:46 PM Peter Robinson 
>> wrote:
>>
>>> On Sat, Jul 1, 2023 at 1:40 PM Mario Marietto 
>>> wrote:
>>> >
>>> > Excuse me. The problem is not the kernel version that I'm running,but
>>> how to use the unverified u-boot created by virtual open systems to
>>> chainload the kernel of whatever used to boot one recent ISO image created
>>> by hexdump0815. Because it contains the code to put the chromebook in
>>> hypervisor mode. Without that special u-boot version,I can for sure install
>>> one ISO image of hexdump0815 (I've chosen jammy as an example,but
>>> hexdump0815 created some more updated isos),but KVM will not be enabled.
>>>
>>> You'll note I didn't comment on the U-Boot piece, but my point still
>>> remains, that KVM for a 32 bit Arm host was removed in the 5.7 kernel
>>> upstream, so even when you sort out the other problem you still won't
>>> have virt due to the kernel.
>>>
>>> > On Sat, Jul 1, 2023 at 2:34 PM Peter Robinson 
>>> wrote:
>>> >>
>>> >> On Sat, Jul 1, 2023 at 1:25 PM Mario Marietto 
>>> wrote:
>>> >> >
>>> >> > Hello.
>>> >> >
>>> >> > I would like to enable KVM virtualization on my old ARM Chromebook
>>> >> > laptop,based on the Exynos5250 arm 32 bit cpu aka snow,model
>>> xe303c12.
>>> >>
>>> >> Upstream Linux kernel dropped support for running virt on 32 bit hosts
>>> >> (you can still run a 32 bit guest on a 64 bit host) in the upstream
>>> >> linux kernel with the 5.7 release (May 31st, 2020) so you'll probably
>>> >> have to run a 5.4.x LTS kernel rather than 5.18.x (not sure why you
>>> >> chose that one) at the very least.
>>> >>
>>> >> > The first thing I did has been to dd the image below directly on
>>> the sd
>>> >> > card :
>>> >> >
>>> >> >
>>> https://github.com/hexdump0815/imagebuilder/releases/download/220619-01/chromebook_snow-armv7l-jammy.img.gz
>>> >> >
>>> >> > and it worked like a charm,but kvm was disabled. So,I have started
>>> to look
>>> >> > for a good documentation to understand how to enable kvm and I
>>> found this :
>>> >> >
>>> >> >
>>> http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebook/
>>> >> >
>>> >> > I've followed all the instructions and it worked,but only with
>>> Ubuntu 13.04
>>> >> > and 14.04. More upgraded ubuntu versions give a lot of problems and
>>> they
>>> >> > don't work.
>>> >> >
>>> >> > So,I've thought about a fresh idea. What about to install the
>>> virtual open
>>> >> > systems "non-verified u-boot" on the first partition like explained
>>> in the
>>> >> > tutorial,and,instead of starting another u-boot after the
>>> original,can I
>>> >> > chain grub with the kernel installed for example by the ubuntu
>>> jammy iso
>>> >> > image created by "hexdump0815" ? To be honest I'm not sure if
>>> hexdump0815
>>> >> > used grub,but I will explain this later.
>>> >> >
>>> >> > Anyway,I've got the idea by reading here :
>>> >> >
>>> >> >
>>> https://unix.stackexchange.com/questions/599141/how-to-install-grub-bootloader-as-second-stage-bootloader
>>> >> > So,now,I'm going to explain what's the content of the partitions on
>>> my
>>> >> > Frankenstein sd card.
>>> >> >
>>> >> > 1) /dev/sdh1 = unknown = 16 MB. I've created this partition by
>>> doing :
>>> >> >
>>> >> > $ sudo dd if=nv_uboot-snow.kpart of=/dev/sdh1
>>> >> >
>>> >> > Where I've got the file nv_uboot-snow.kpart ? From here :
>>> >> >
>>> >> >
>>> http://www.virtualopensystems.com/downloads/guides/kvm_on_chromebook/nv_u-boot-snow.kpart
>>> >> >
>>> >> > 2) /dev/sdh2 = unknown = 16 MB. This partition has been created by
>>> >> > executing the following
>>> >> >
>>> >> > script :
>>> >> >
>>> >> > $ sudo ./scripts/sdcard.sh /dev/sdh
>>> >> >
>>> >> > 3) /dev/sdh3 = ext2 BOOT.
>>> >> >
>>> >> > Inside the partition /dev/sdh3 I have copied the following files and
>>> >> > folders (taken
>>> >> > from the hexdump0815 "chromebook_snow-armv7l-jammy.img.gz" file :
>>> >> >
>>> >> > a) dtb-5.18.1-stb-cbe+ = directory
>>> >> > b) extlinux = directory
>>> >> > c) extra = directory
>>> >> >
>>> >> > d) config.5.18.1-stb-cbe+ : file
>>> >> > e) initrd.img-5.18.1-stb-cbe+ : file
>>> >> > f) System.map-5.18.1-stb-cbe+ : file
>>> >> > g) vmlinux.kpart-5.18.1-stb-cbe+ : file
>>> >

Pull request efi-2023-07-rc6

[Heinrich Schuchardt]

Dear Tom,

The following changes since commit 5fa30f2351ac3c0458069896bc868eae927df410:

  smegw01: Fix wrong symbol override (2023-06-29 09:55:50 -0400)

are available in the Git repository at:

  https://source.denx.de/u-boot/custodians/u-boot-efi.git
tags/efi-2023-07-rc6

for you to fetch changes up to 2b17dd1d9d8ca2cfc7f5e964384d4d8418904c35:

  ARM: arm11: Add C wrapper for allow_unaligned() (2023-07-01 17:29:15
+0200)

Gitlab CI showed no issues:
https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/16741


Pull request efi-2023-07-rc6

Documentation:

* man-pages for the loads and saves commands

UEFI:

* fix implementation of allow_unaligned() for armv7 and arm11


Heinrich Schuchardt (3):
  doc: loads man-page
  doc: saves man-page
  doc: fix typo loady in loadb man-page

Marek Vasut (2):
  ARM: armv7: Add C wrapper for allow_unaligned()
  ARM: arm11: Add C wrapper for allow_unaligned()

 arch/arm/cpu/arm11/cpu.c |  6 +++
 arch/arm/cpu/arm11/sctlr.S   |  6 +--
 arch/arm/cpu/armv7/cpu.c |  5 +++
 arch/arm/cpu/armv7/sctlr.S   |  6 +--
 arch/arm/include/asm/arm11.h | 12 ++
 arch/arm/include/asm/armv7.h |  1 +
 doc/usage/cmd/loadb.rst  |  2 +-
 doc/usage/cmd/loads.rst  | 96

 doc/usage/cmd/saves.rst  | 88 
 doc/usage/index.rst  |  2 +
 10 files changed, 217 insertions(+), 7 deletions(-)
 create mode 100644 arch/arm/include/asm/arm11.h
 create mode 100644 doc/usage/cmd/loads.rst
 create mode 100644 doc/usage/cmd/saves.rst

[PATCH v2 2/2] ARM: arm11: Add C wrapper for allow_unaligned()

[Marek Vasut]

Rename current assembler implementation of allow_unaligned() to
arm11_arch_cp15_allow_unaligned() and add it into arm11.h header,
then add C wrapper of allow_unaligned().

This fixes misbehavior when linking U-Boot, where the CPU specific
allow_unaligned() implementation was ignored and instead the
__weak allow_unaligned() implementation from lib/efi_loader/efi_setup.c
was used, which led to "data abort" just before booting Linux via tftp,
in efi_dp_from_file() -> path_to_uefi() -> utf16_put() .

The problem is triggerd by c7c0ca37673 ("efi_loader: fix efi_dp_from_file()") .
Adding the wrapper fixes the problem.

Fixes: d47a774680d ("arm: arm11: allow unaligned memory access")
Signed-off-by: Marek Vasut 
---
V2: Update Fixes tag and commit message
---
Cc: Fabio Estevam 
Cc: Heinrich Schuchardt 
Cc: Ilias Apalodimas 
Cc: Simon Glass 
Cc: Tom Rini 
---
 arch/arm/cpu/arm11/cpu.c |  6 ++
 arch/arm/cpu/arm11/sctlr.S   |  6 +++---
 arch/arm/include/asm/arm11.h | 12 
 3 files changed, 21 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/include/asm/arm11.h

diff --git a/arch/arm/cpu/arm11/cpu.c b/arch/arm/cpu/arm11/cpu.c
index ffe35111d58..1e16b89d006 100644
--- a/arch/arm/cpu/arm11/cpu.c
+++ b/arch/arm/cpu/arm11/cpu.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static void cache_flush(void);
 
@@ -43,6 +44,11 @@ int cleanup_before_linux (void)
return 0;
 }
 
+void allow_unaligned(void)
+{
+   arm11_arch_cp15_allow_unaligned();
+}
+
 static void cache_flush(void)
 {
unsigned long i = 0;
diff --git a/arch/arm/cpu/arm11/sctlr.S b/arch/arm/cpu/arm11/sctlr.S
index 74a7fc4a25b..8722f8380c8 100644
--- a/arch/arm/cpu/arm11/sctlr.S
+++ b/arch/arm/cpu/arm11/sctlr.S
@@ -8,7 +8,7 @@
 #include 
 
 /*
- * void allow_unaligned(void) - allow unaligned access
+ * void arm11_arch_cp15_allow_unaligned(void) - allow unaligned access
  *
  * This routine sets the enable unaligned data support flag and clears the
  * aligned flag in the system control register.
@@ -16,10 +16,10 @@
  * data abort or undefined behavior but is handled by the CPU.
  * For details see the "ARM Architecture Reference Manual" for ARMv6.
  */
-ENTRY(allow_unaligned)
+ENTRY(arm11_arch_cp15_allow_unaligned)
mrc p15, 0, r0, c1, c0, 0   @ load system control register
orr r0, r0, #1 << 22@ set unaligned data support flag
bic r0, r0, #2  @ clear aligned flag
mcr p15, 0, r0, c1, c0, 0   @ write system control register
bx  lr  @ return
-ENDPROC(allow_unaligned)
+ENDPROC(arm11_arch_cp15_allow_unaligned)
diff --git a/arch/arm/include/asm/arm11.h b/arch/arm/include/asm/arm11.h
new file mode 100644
index 000..5276f735ef9
--- /dev/null
+++ b/arch/arm/include/asm/arm11.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2023 Marek Vasut 
+ */
+#ifndef ARM11_H
+#define ARM11_H
+
+#ifndef __ASSEMBLY__
+void arm11_arch_cp15_allow_unaligned(void);
+#endif /* ! __ASSEMBLY__ */
+
+#endif /* ARM11_H */
-- 
2.40.1

[PATCH v2 1/2] ARM: armv7: Add C wrapper for allow_unaligned()

[Marek Vasut]

Rename current assembler implementation of allow_unaligned() to
v7_arch_cp15_allow_unaligned() and add it into armv7.h header,
then add C wrapper of allow_unaligned().

This fixes misbehavior when linking U-Boot on ARMv7a i.MX6Q, where the
CPU specific allow_unaligned() implementation was ignored and instead the
__weak allow_unaligned() implementation from lib/efi_loader/efi_setup.c
was used, which led to "data abort" just before booting Linux via tftp,
in efi_dp_from_file() -> path_to_uefi() -> utf16_put() .

The problem is triggerd by c7c0ca37673 ("efi_loader: fix efi_dp_from_file()") .
Adding the wrapper fixes the problem.

Fixes: 78f90aaeecc ("arm: armv7: allow unaligned memory access")
Signed-off-by: Marek Vasut 
---
V2: Update Fixes tag and commit message
---
Cc: Fabio Estevam 
Cc: Heinrich Schuchardt 
Cc: Ilias Apalodimas 
Cc: Simon Glass 
Cc: Tom Rini 
---
 arch/arm/cpu/armv7/cpu.c | 5 +
 arch/arm/cpu/armv7/sctlr.S   | 6 +++---
 arch/arm/include/asm/armv7.h | 1 +
 3 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/arch/arm/cpu/armv7/cpu.c b/arch/arm/cpu/armv7/cpu.c
index 68807d20997..6259ffa5108 100644
--- a/arch/arm/cpu/armv7/cpu.c
+++ b/arch/arm/cpu/armv7/cpu.c
@@ -83,3 +83,8 @@ int cleanup_before_linux(void)
 {
return cleanup_before_linux_select(CBL_ALL);
 }
+
+void allow_unaligned(void)
+{
+   v7_arch_cp15_allow_unaligned();
+}
diff --git a/arch/arm/cpu/armv7/sctlr.S b/arch/arm/cpu/armv7/sctlr.S
index bd56e41afe1..d44b21498f6 100644
--- a/arch/arm/cpu/armv7/sctlr.S
+++ b/arch/arm/cpu/armv7/sctlr.S
@@ -8,15 +8,15 @@
 #include 
 
 /*
- * void allow_unaligned(void) - allow unaligned access
+ * void v7_arch_cp15_allow_unaligned(void) - allow unaligned access
  *
  * This routine clears the aligned flag in the system control register.
  * After calling this routine unaligned access does no longer lead to a
  * data abort but is handled by the CPU.
  */
-ENTRY(allow_unaligned)
+ENTRY(v7_arch_cp15_allow_unaligned)
mrc p15, 0, r0, c1, c0, 0   @ load system control register
bic r0, r0, #2  @ clear aligned flag
mcr p15, 0, r0, c1, c0, 0   @ write system control register
bx  lr  @ return
-ENDPROC(allow_unaligned)
+ENDPROC(v7_arch_cp15_allow_unaligned)
diff --git a/arch/arm/include/asm/armv7.h b/arch/arm/include/asm/armv7.h
index 2fb824b69e2..c002998ac0b 100644
--- a/arch/arm/include/asm/armv7.h
+++ b/arch/arm/include/asm/armv7.h
@@ -156,6 +156,7 @@ void v7_arch_cp15_set_l2aux_ctrl(u32 l2auxctrl, u32 
cpu_midr,
 u32 cpu_rev);
 void v7_arch_cp15_set_acr(u32 acr, u32 cpu_midr, u32 cpu_rev_comb,
  u32 cpu_variant, u32 cpu_rev);
+void v7_arch_cp15_allow_unaligned(void);
 #endif /* ! __ASSEMBLY__ */
 
 #endif
-- 
2.40.1

Re: [PATCH 1/2] ARM: armv7: Add C wrapper for allow_unaligned()

[Marek Vasut]

On 7/1/23 16:57, Heinrich Schuchardt wrote:

On 7/1/23 15:00, Marek Vasut wrote:

Rename current assembler implementation of allow_unaligned() to
v7_arch_cp15_allow_unaligned() and add it into armv7.h header,
then add C wrapper of allow_unaligned().

This fixes misbehavior when linking U-Boot on ARMv7a i.MX6Q, where the
CPU specific allow_unaligned() implementation was ignored and instead the
__weak allow_unaligned() implementation from lib/efi_loader/efi_setup.c
was used, which led to "data abort" just before booting Linux via tftp,
in efi_dp_from_file() -> path_to_uefi() -> utf16_put() .

Adding the wrapper fixes the problem.

Fixes: c7c0ca37673 ("efi_loader: fix efi_dp_from_file()")


Hello Marek,

Thank you for investigating this issue.

Looking at
https://lore.kernel.org/u-boot/20230320171335.1368308-1-ilias.apalodi...@linaro.org/
the problem predates c7c0ca37673. So this fixes line seems wrong.


That commit does trigger the error however . Maybe this was broken ever 
since allow_unaligned() was introduced ?



Your series has a fix for armv7 but misses arm11.


That's exactly what 2/2 in this series does ?


So we would be better
of with Ilias patch. Somehow Ilias never followed up on my questions and
we lost track.

Could you, please, test Ilias patch.


That patch corrupts r0 register in both cases in the asm volatile(), 
since it does not push r0 on stack or use %0 temporary or whatever .

Re: [PATCH 1/2] ARM: armv7: Add C wrapper for allow_unaligned()

[Heinrich Schuchardt]

On 7/1/23 15:00, Marek Vasut wrote:

Rename current assembler implementation of allow_unaligned() to
v7_arch_cp15_allow_unaligned() and add it into armv7.h header,
then add C wrapper of allow_unaligned().

This fixes misbehavior when linking U-Boot on ARMv7a i.MX6Q, where the
CPU specific allow_unaligned() implementation was ignored and instead the
__weak allow_unaligned() implementation from lib/efi_loader/efi_setup.c
was used, which led to "data abort" just before booting Linux via tftp,
in efi_dp_from_file() -> path_to_uefi() -> utf16_put() .

Adding the wrapper fixes the problem.

Fixes: c7c0ca37673 ("efi_loader: fix efi_dp_from_file()")


Hello Marek,

Thank you for investigating this issue.

Looking at
https://lore.kernel.org/u-boot/20230320171335.1368308-1-ilias.apalodi...@linaro.org/
the problem predates c7c0ca37673. So this fixes line seems wrong.

Your series has a fix for armv7 but misses arm11. So we would be better
of with Ilias patch. Somehow Ilias never followed up on my questions and
we lost track.

Could you, please, test Ilias patch.

Best regards

Heinrich


Signed-off-by: Marek Vasut 
---
Cc: Fabio Estevam 
Cc: Heinrich Schuchardt 
Cc: Simon Glass 
Cc: Tom Rini 
---
  arch/arm/cpu/armv7/cpu.c | 5 +
  arch/arm/cpu/armv7/sctlr.S   | 6 +++---
  arch/arm/include/asm/armv7.h | 1 +
  3 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/arch/arm/cpu/armv7/cpu.c b/arch/arm/cpu/armv7/cpu.c
index 68807d20997..6259ffa5108 100644
--- a/arch/arm/cpu/armv7/cpu.c
+++ b/arch/arm/cpu/armv7/cpu.c
@@ -83,3 +83,8 @@ int cleanup_before_linux(void)
  {
return cleanup_before_linux_select(CBL_ALL);
  }
+
+void allow_unaligned(void)
+{
+   v7_arch_cp15_allow_unaligned();
+}
diff --git a/arch/arm/cpu/armv7/sctlr.S b/arch/arm/cpu/armv7/sctlr.S
index bd56e41afe1..d44b21498f6 100644
--- a/arch/arm/cpu/armv7/sctlr.S
+++ b/arch/arm/cpu/armv7/sctlr.S
@@ -8,15 +8,15 @@
  #include 

  /*
- * void allow_unaligned(void) - allow unaligned access
+ * void v7_arch_cp15_allow_unaligned(void) - allow unaligned access
   *
   * This routine clears the aligned flag in the system control register.
   * After calling this routine unaligned access does no longer lead to a
   * data abort but is handled by the CPU.
   */
-ENTRY(allow_unaligned)
+ENTRY(v7_arch_cp15_allow_unaligned)
mrc p15, 0, r0, c1, c0, 0   @ load system control register
bic r0, r0, #2  @ clear aligned flag
mcr p15, 0, r0, c1, c0, 0   @ write system control register
bx  lr  @ return
-ENDPROC(allow_unaligned)
+ENDPROC(v7_arch_cp15_allow_unaligned)
diff --git a/arch/arm/include/asm/armv7.h b/arch/arm/include/asm/armv7.h
index 2fb824b69e2..c002998ac0b 100644
--- a/arch/arm/include/asm/armv7.h
+++ b/arch/arm/include/asm/armv7.h
@@ -156,6 +156,7 @@ void v7_arch_cp15_set_l2aux_ctrl(u32 l2auxctrl, u32 
cpu_midr,
 u32 cpu_rev);
  void v7_arch_cp15_set_acr(u32 acr, u32 cpu_midr, u32 cpu_rev_comb,
  u32 cpu_variant, u32 cpu_rev);
+void v7_arch_cp15_allow_unaligned(void);
  #endif /* ! __ASSEMBLY__ */

  #endif

Re: How u-boot can chain "grub" and booting a mainline kernel on my ARM Chromebook

[Mario Marietto]

ok. Can we come back to the main problem,please ? Is there a method to do
what I want ? Is there some kind of technique ? Very thanks.

On Sat, Jul 1, 2023 at 2:57 PM Mario Marietto 
wrote:

> Some days ago I successfully compiled the kernel version. 5.4.244 with all
> the kvm flags enabled and the exynos 5250-snow.dtb file.
>
> On Sat, Jul 1, 2023 at 2:46 PM Peter Robinson 
> wrote:
>
>> On Sat, Jul 1, 2023 at 1:40 PM Mario Marietto 
>> wrote:
>> >
>> > Excuse me. The problem is not the kernel version that I'm running,but
>> how to use the unverified u-boot created by virtual open systems to
>> chainload the kernel of whatever used to boot one recent ISO image created
>> by hexdump0815. Because it contains the code to put the chromebook in
>> hypervisor mode. Without that special u-boot version,I can for sure install
>> one ISO image of hexdump0815 (I've chosen jammy as an example,but
>> hexdump0815 created some more updated isos),but KVM will not be enabled.
>>
>> You'll note I didn't comment on the U-Boot piece, but my point still
>> remains, that KVM for a 32 bit Arm host was removed in the 5.7 kernel
>> upstream, so even when you sort out the other problem you still won't
>> have virt due to the kernel.
>>
>> > On Sat, Jul 1, 2023 at 2:34 PM Peter Robinson 
>> wrote:
>> >>
>> >> On Sat, Jul 1, 2023 at 1:25 PM Mario Marietto 
>> wrote:
>> >> >
>> >> > Hello.
>> >> >
>> >> > I would like to enable KVM virtualization on my old ARM Chromebook
>> >> > laptop,based on the Exynos5250 arm 32 bit cpu aka snow,model
>> xe303c12.
>> >>
>> >> Upstream Linux kernel dropped support for running virt on 32 bit hosts
>> >> (you can still run a 32 bit guest on a 64 bit host) in the upstream
>> >> linux kernel with the 5.7 release (May 31st, 2020) so you'll probably
>> >> have to run a 5.4.x LTS kernel rather than 5.18.x (not sure why you
>> >> chose that one) at the very least.
>> >>
>> >> > The first thing I did has been to dd the image below directly on the
>> sd
>> >> > card :
>> >> >
>> >> >
>> https://github.com/hexdump0815/imagebuilder/releases/download/220619-01/chromebook_snow-armv7l-jammy.img.gz
>> >> >
>> >> > and it worked like a charm,but kvm was disabled. So,I have started
>> to look
>> >> > for a good documentation to understand how to enable kvm and I found
>> this :
>> >> >
>> >> >
>> http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebook/
>> >> >
>> >> > I've followed all the instructions and it worked,but only with
>> Ubuntu 13.04
>> >> > and 14.04. More upgraded ubuntu versions give a lot of problems and
>> they
>> >> > don't work.
>> >> >
>> >> > So,I've thought about a fresh idea. What about to install the
>> virtual open
>> >> > systems "non-verified u-boot" on the first partition like explained
>> in the
>> >> > tutorial,and,instead of starting another u-boot after the
>> original,can I
>> >> > chain grub with the kernel installed for example by the ubuntu jammy
>> iso
>> >> > image created by "hexdump0815" ? To be honest I'm not sure if
>> hexdump0815
>> >> > used grub,but I will explain this later.
>> >> >
>> >> > Anyway,I've got the idea by reading here :
>> >> >
>> >> >
>> https://unix.stackexchange.com/questions/599141/how-to-install-grub-bootloader-as-second-stage-bootloader
>> >> > So,now,I'm going to explain what's the content of the partitions on
>> my
>> >> > Frankenstein sd card.
>> >> >
>> >> > 1) /dev/sdh1 = unknown = 16 MB. I've created this partition by doing
>> :
>> >> >
>> >> > $ sudo dd if=nv_uboot-snow.kpart of=/dev/sdh1
>> >> >
>> >> > Where I've got the file nv_uboot-snow.kpart ? From here :
>> >> >
>> >> >
>> http://www.virtualopensystems.com/downloads/guides/kvm_on_chromebook/nv_u-boot-snow.kpart
>> >> >
>> >> > 2) /dev/sdh2 = unknown = 16 MB. This partition has been created by
>> >> > executing the following
>> >> >
>> >> > script :
>> >> >
>> >> > $ sudo ./scripts/sdcard.sh /dev/sdh
>> >> >
>> >> > 3) /dev/sdh3 = ext2 BOOT.
>> >> >
>> >> > Inside the partition /dev/sdh3 I have copied the following files and
>> >> > folders (taken
>> >> > from the hexdump0815 "chromebook_snow-armv7l-jammy.img.gz" file :
>> >> >
>> >> > a) dtb-5.18.1-stb-cbe+ = directory
>> >> > b) extlinux = directory
>> >> > c) extra = directory
>> >> >
>> >> > d) config.5.18.1-stb-cbe+ : file
>> >> > e) initrd.img-5.18.1-stb-cbe+ : file
>> >> > f) System.map-5.18.1-stb-cbe+ : file
>> >> > g) vmlinux.kpart-5.18.1-stb-cbe+ : file
>> >> > h) zImage-5.18.1-stb.cbe+ : file
>> >> >
>> >> > Inside the directory "dtb-5.18.1-stb-cbe+" there are the following
>> files :
>> >> >
>> >> > a) exynos5250-snow.dtb
>> >> > b) exynos5250-snow-rev5.dtb
>> >> > c) exynos5250-spring.dtb
>> >> >
>> >> > Inside the directory "extlinux",there is the following file :
>> >> >
>> >> > a) extlinux.conf : that has the following content :
>> >> >
>> >> > TIMEOUT 30
>> >> >
>> >> > DEFAULT linux-snow-rev4
>> >> >
>> >> > MENU TITLE snow chromebook boot options
>> >> >
>> >> > # rev4 snow chromebook
>> >> > LABEL linux

Re: [PATCH v2 3/3] spl: spl_legacy: Fix spl_end address

[Marek Vasut]

On 7/1/23 04:30, Fabio Estevam wrote:

From: Fabio Estevam 

Currently, spl_end points to the __bss_end address, which
is an external RAM address instead of the end of the SPL text
section in the internal RAM.

This causes boot failures on imx6-colibri, for example:

```
Trying to boot from MMC1
SPL: Image overlaps SPL
resetting ...
```
Fix this problem by assigning spl_end to _image_binary_end, as this
symbol properly represents the end of the SPL text section.


From u-boot-spl.map:


.end
  *(.__end)
 0x009121a4_image_binary_end = .

Fixes: 77aed22b48ab ("spl: spl_legacy: Add extra address checks")
Reported-by: Francesco Dolcini 
Signed-off-by: Fabio Estevam 
Tested-by: Tom Rini 


Reviewed-by: Marek Vasut 
Tested-by: Marek Vasut  # DH i.MX6Q DHCOM PDK2

Re: [PATCH v2 2/3] microblaze: u-boot-spl.lds: Pass _image_binary_end

[Marek Vasut]

On 7/1/23 04:30, Fabio Estevam wrote:

From: Fabio Estevam 

Pass _image_binary_end to make a standard way to indicate the end
of the text section in SPL.

The motivation for this is to have a uniform way to handle
the SPL boundary checks.

Signed-off-by: Fabio Estevam 


Reviewed-by: Marek Vasut 

Re: [PATCH v2 1/3] sunxi: u-boot-spl.lds: Pass _image_binary_end

[Marek Vasut]

On 7/1/23 04:30, Fabio Estevam wrote:

From: Fabio Estevam 

Pass _image_binary_end to make a standard way to indicate the end
of the text section in SPL.

The motivation for this is to have a uniform way to handle
the SPL boundary checks.

Signed-off-by: Fabio Estevam 


Reviewed-by: Marek Vasut 

[PATCH 1/2] ARM: armv7: Add C wrapper for allow_unaligned()

[Marek Vasut]

Rename current assembler implementation of allow_unaligned() to
v7_arch_cp15_allow_unaligned() and add it into armv7.h header,
then add C wrapper of allow_unaligned().

This fixes misbehavior when linking U-Boot on ARMv7a i.MX6Q, where the
CPU specific allow_unaligned() implementation was ignored and instead the
__weak allow_unaligned() implementation from lib/efi_loader/efi_setup.c
was used, which led to "data abort" just before booting Linux via tftp,
in efi_dp_from_file() -> path_to_uefi() -> utf16_put() .

Adding the wrapper fixes the problem.

Fixes: c7c0ca37673 ("efi_loader: fix efi_dp_from_file()")
Signed-off-by: Marek Vasut 
---
Cc: Fabio Estevam 
Cc: Heinrich Schuchardt 
Cc: Simon Glass 
Cc: Tom Rini 
---
 arch/arm/cpu/armv7/cpu.c | 5 +
 arch/arm/cpu/armv7/sctlr.S   | 6 +++---
 arch/arm/include/asm/armv7.h | 1 +
 3 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/arch/arm/cpu/armv7/cpu.c b/arch/arm/cpu/armv7/cpu.c
index 68807d20997..6259ffa5108 100644
--- a/arch/arm/cpu/armv7/cpu.c
+++ b/arch/arm/cpu/armv7/cpu.c
@@ -83,3 +83,8 @@ int cleanup_before_linux(void)
 {
return cleanup_before_linux_select(CBL_ALL);
 }
+
+void allow_unaligned(void)
+{
+   v7_arch_cp15_allow_unaligned();
+}
diff --git a/arch/arm/cpu/armv7/sctlr.S b/arch/arm/cpu/armv7/sctlr.S
index bd56e41afe1..d44b21498f6 100644
--- a/arch/arm/cpu/armv7/sctlr.S
+++ b/arch/arm/cpu/armv7/sctlr.S
@@ -8,15 +8,15 @@
 #include 
 
 /*
- * void allow_unaligned(void) - allow unaligned access
+ * void v7_arch_cp15_allow_unaligned(void) - allow unaligned access
  *
  * This routine clears the aligned flag in the system control register.
  * After calling this routine unaligned access does no longer lead to a
  * data abort but is handled by the CPU.
  */
-ENTRY(allow_unaligned)
+ENTRY(v7_arch_cp15_allow_unaligned)
mrc p15, 0, r0, c1, c0, 0   @ load system control register
bic r0, r0, #2  @ clear aligned flag
mcr p15, 0, r0, c1, c0, 0   @ write system control register
bx  lr  @ return
-ENDPROC(allow_unaligned)
+ENDPROC(v7_arch_cp15_allow_unaligned)
diff --git a/arch/arm/include/asm/armv7.h b/arch/arm/include/asm/armv7.h
index 2fb824b69e2..c002998ac0b 100644
--- a/arch/arm/include/asm/armv7.h
+++ b/arch/arm/include/asm/armv7.h
@@ -156,6 +156,7 @@ void v7_arch_cp15_set_l2aux_ctrl(u32 l2auxctrl, u32 
cpu_midr,
 u32 cpu_rev);
 void v7_arch_cp15_set_acr(u32 acr, u32 cpu_midr, u32 cpu_rev_comb,
  u32 cpu_variant, u32 cpu_rev);
+void v7_arch_cp15_allow_unaligned(void);
 #endif /* ! __ASSEMBLY__ */
 
 #endif
-- 
2.40.1

[PATCH 2/2] ARM: arm11: Add C wrapper for allow_unaligned()

[Marek Vasut]

Rename current assembler implementation of allow_unaligned() to
arm11_arch_cp15_allow_unaligned() and add it into arm11.h header,
then add C wrapper of allow_unaligned().

This fixes misbehavior when linking U-Boot, where the CPU specific
allow_unaligned() implementation was ignored and instead the
__weak allow_unaligned() implementation from lib/efi_loader/efi_setup.c
was used, which led to "data abort" just before booting Linux via tftp,
in efi_dp_from_file() -> path_to_uefi() -> utf16_put() .

Adding the wrapper fixes the problem.

Fixes: c7c0ca37673 ("efi_loader: fix efi_dp_from_file()")
Signed-off-by: Marek Vasut 
---
Cc: Fabio Estevam 
Cc: Heinrich Schuchardt 
Cc: Simon Glass 
Cc: Tom Rini 
---
 arch/arm/cpu/arm11/cpu.c |  6 ++
 arch/arm/cpu/arm11/sctlr.S   |  6 +++---
 arch/arm/include/asm/arm11.h | 12 
 3 files changed, 21 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/include/asm/arm11.h

diff --git a/arch/arm/cpu/arm11/cpu.c b/arch/arm/cpu/arm11/cpu.c
index ffe35111d58..1e16b89d006 100644
--- a/arch/arm/cpu/arm11/cpu.c
+++ b/arch/arm/cpu/arm11/cpu.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static void cache_flush(void);
 
@@ -43,6 +44,11 @@ int cleanup_before_linux (void)
return 0;
 }
 
+void allow_unaligned(void)
+{
+   arm11_arch_cp15_allow_unaligned();
+}
+
 static void cache_flush(void)
 {
unsigned long i = 0;
diff --git a/arch/arm/cpu/arm11/sctlr.S b/arch/arm/cpu/arm11/sctlr.S
index 74a7fc4a25b..8722f8380c8 100644
--- a/arch/arm/cpu/arm11/sctlr.S
+++ b/arch/arm/cpu/arm11/sctlr.S
@@ -8,7 +8,7 @@
 #include 
 
 /*
- * void allow_unaligned(void) - allow unaligned access
+ * void arm11_arch_cp15_allow_unaligned(void) - allow unaligned access
  *
  * This routine sets the enable unaligned data support flag and clears the
  * aligned flag in the system control register.
@@ -16,10 +16,10 @@
  * data abort or undefined behavior but is handled by the CPU.
  * For details see the "ARM Architecture Reference Manual" for ARMv6.
  */
-ENTRY(allow_unaligned)
+ENTRY(arm11_arch_cp15_allow_unaligned)
mrc p15, 0, r0, c1, c0, 0   @ load system control register
orr r0, r0, #1 << 22@ set unaligned data support flag
bic r0, r0, #2  @ clear aligned flag
mcr p15, 0, r0, c1, c0, 0   @ write system control register
bx  lr  @ return
-ENDPROC(allow_unaligned)
+ENDPROC(arm11_arch_cp15_allow_unaligned)
diff --git a/arch/arm/include/asm/arm11.h b/arch/arm/include/asm/arm11.h
new file mode 100644
index 000..5276f735ef9
--- /dev/null
+++ b/arch/arm/include/asm/arm11.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2023 Marek Vasut 
+ */
+#ifndef ARM11_H
+#define ARM11_H
+
+#ifndef __ASSEMBLY__
+void arm11_arch_cp15_allow_unaligned(void);
+#endif /* ! __ASSEMBLY__ */
+
+#endif /* ARM11_H */
-- 
2.40.1

Re: How u-boot can chain "grub" and booting a mainline kernel on my ARM Chromebook

[Mario Marietto]

Some days ago I successfully compiled the kernel version. 5.4.244 with all
the kvm flags enabled and the exynos 5250-snow.dtb file.

On Sat, Jul 1, 2023 at 2:46 PM Peter Robinson  wrote:

> On Sat, Jul 1, 2023 at 1:40 PM Mario Marietto 
> wrote:
> >
> > Excuse me. The problem is not the kernel version that I'm running,but
> how to use the unverified u-boot created by virtual open systems to
> chainload the kernel of whatever used to boot one recent ISO image created
> by hexdump0815. Because it contains the code to put the chromebook in
> hypervisor mode. Without that special u-boot version,I can for sure install
> one ISO image of hexdump0815 (I've chosen jammy as an example,but
> hexdump0815 created some more updated isos),but KVM will not be enabled.
>
> You'll note I didn't comment on the U-Boot piece, but my point still
> remains, that KVM for a 32 bit Arm host was removed in the 5.7 kernel
> upstream, so even when you sort out the other problem you still won't
> have virt due to the kernel.
>
> > On Sat, Jul 1, 2023 at 2:34 PM Peter Robinson 
> wrote:
> >>
> >> On Sat, Jul 1, 2023 at 1:25 PM Mario Marietto 
> wrote:
> >> >
> >> > Hello.
> >> >
> >> > I would like to enable KVM virtualization on my old ARM Chromebook
> >> > laptop,based on the Exynos5250 arm 32 bit cpu aka snow,model xe303c12.
> >>
> >> Upstream Linux kernel dropped support for running virt on 32 bit hosts
> >> (you can still run a 32 bit guest on a 64 bit host) in the upstream
> >> linux kernel with the 5.7 release (May 31st, 2020) so you'll probably
> >> have to run a 5.4.x LTS kernel rather than 5.18.x (not sure why you
> >> chose that one) at the very least.
> >>
> >> > The first thing I did has been to dd the image below directly on the
> sd
> >> > card :
> >> >
> >> >
> https://github.com/hexdump0815/imagebuilder/releases/download/220619-01/chromebook_snow-armv7l-jammy.img.gz
> >> >
> >> > and it worked like a charm,but kvm was disabled. So,I have started to
> look
> >> > for a good documentation to understand how to enable kvm and I found
> this :
> >> >
> >> >
> http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebook/
> >> >
> >> > I've followed all the instructions and it worked,but only with Ubuntu
> 13.04
> >> > and 14.04. More upgraded ubuntu versions give a lot of problems and
> they
> >> > don't work.
> >> >
> >> > So,I've thought about a fresh idea. What about to install the virtual
> open
> >> > systems "non-verified u-boot" on the first partition like explained
> in the
> >> > tutorial,and,instead of starting another u-boot after the
> original,can I
> >> > chain grub with the kernel installed for example by the ubuntu jammy
> iso
> >> > image created by "hexdump0815" ? To be honest I'm not sure if
> hexdump0815
> >> > used grub,but I will explain this later.
> >> >
> >> > Anyway,I've got the idea by reading here :
> >> >
> >> >
> https://unix.stackexchange.com/questions/599141/how-to-install-grub-bootloader-as-second-stage-bootloader
> >> > So,now,I'm going to explain what's the content of the partitions on my
> >> > Frankenstein sd card.
> >> >
> >> > 1) /dev/sdh1 = unknown = 16 MB. I've created this partition by doing :
> >> >
> >> > $ sudo dd if=nv_uboot-snow.kpart of=/dev/sdh1
> >> >
> >> > Where I've got the file nv_uboot-snow.kpart ? From here :
> >> >
> >> >
> http://www.virtualopensystems.com/downloads/guides/kvm_on_chromebook/nv_u-boot-snow.kpart
> >> >
> >> > 2) /dev/sdh2 = unknown = 16 MB. This partition has been created by
> >> > executing the following
> >> >
> >> > script :
> >> >
> >> > $ sudo ./scripts/sdcard.sh /dev/sdh
> >> >
> >> > 3) /dev/sdh3 = ext2 BOOT.
> >> >
> >> > Inside the partition /dev/sdh3 I have copied the following files and
> >> > folders (taken
> >> > from the hexdump0815 "chromebook_snow-armv7l-jammy.img.gz" file :
> >> >
> >> > a) dtb-5.18.1-stb-cbe+ = directory
> >> > b) extlinux = directory
> >> > c) extra = directory
> >> >
> >> > d) config.5.18.1-stb-cbe+ : file
> >> > e) initrd.img-5.18.1-stb-cbe+ : file
> >> > f) System.map-5.18.1-stb-cbe+ : file
> >> > g) vmlinux.kpart-5.18.1-stb-cbe+ : file
> >> > h) zImage-5.18.1-stb.cbe+ : file
> >> >
> >> > Inside the directory "dtb-5.18.1-stb-cbe+" there are the following
> files :
> >> >
> >> > a) exynos5250-snow.dtb
> >> > b) exynos5250-snow-rev5.dtb
> >> > c) exynos5250-spring.dtb
> >> >
> >> > Inside the directory "extlinux",there is the following file :
> >> >
> >> > a) extlinux.conf : that has the following content :
> >> >
> >> > TIMEOUT 30
> >> >
> >> > DEFAULT linux-snow-rev4
> >> >
> >> > MENU TITLE snow chromebook boot options
> >> >
> >> > # rev4 snow chromebook
> >> > LABEL linux-snow-rev4
> >> >   MENU LABEL linux rev4 snow
> >> >   LINUX ../zImage-5.18.1-stb-cbe+
> >> >   INITRD ../initrd.img-5.18.1-stb-cbe+
> >> >   FDT ../dtb-5.18.1-stb-cbe+/exynos5250-snow.dtb
> >> >   APPEND console=tty1 root=LABEL=rootpart ro rootwait
> net.ifnames=0
> >> > ipv6.disable=1 fsck.repair=yes noresume

Re: How u-boot can chain "grub" and booting a mainline kernel on my ARM Chromebook

[Peter Robinson]

On Sat, Jul 1, 2023 at 1:40 PM Mario Marietto  wrote:
>
> Excuse me. The problem is not the kernel version that I'm running,but how to 
> use the unverified u-boot created by virtual open systems to chainload the 
> kernel of whatever used to boot one recent ISO image created by hexdump0815. 
> Because it contains the code to put the chromebook in hypervisor mode. 
> Without that special u-boot version,I can for sure install one ISO image of 
> hexdump0815 (I've chosen jammy as an example,but hexdump0815 created some 
> more updated isos),but KVM will not be enabled.

You'll note I didn't comment on the U-Boot piece, but my point still
remains, that KVM for a 32 bit Arm host was removed in the 5.7 kernel
upstream, so even when you sort out the other problem you still won't
have virt due to the kernel.

> On Sat, Jul 1, 2023 at 2:34 PM Peter Robinson  wrote:
>>
>> On Sat, Jul 1, 2023 at 1:25 PM Mario Marietto  wrote:
>> >
>> > Hello.
>> >
>> > I would like to enable KVM virtualization on my old ARM Chromebook
>> > laptop,based on the Exynos5250 arm 32 bit cpu aka snow,model xe303c12.
>>
>> Upstream Linux kernel dropped support for running virt on 32 bit hosts
>> (you can still run a 32 bit guest on a 64 bit host) in the upstream
>> linux kernel with the 5.7 release (May 31st, 2020) so you'll probably
>> have to run a 5.4.x LTS kernel rather than 5.18.x (not sure why you
>> chose that one) at the very least.
>>
>> > The first thing I did has been to dd the image below directly on the sd
>> > card :
>> >
>> > https://github.com/hexdump0815/imagebuilder/releases/download/220619-01/chromebook_snow-armv7l-jammy.img.gz
>> >
>> > and it worked like a charm,but kvm was disabled. So,I have started to look
>> > for a good documentation to understand how to enable kvm and I found this :
>> >
>> > http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebook/
>> >
>> > I've followed all the instructions and it worked,but only with Ubuntu 13.04
>> > and 14.04. More upgraded ubuntu versions give a lot of problems and they
>> > don't work.
>> >
>> > So,I've thought about a fresh idea. What about to install the virtual open
>> > systems "non-verified u-boot" on the first partition like explained in the
>> > tutorial,and,instead of starting another u-boot after the original,can I
>> > chain grub with the kernel installed for example by the ubuntu jammy iso
>> > image created by "hexdump0815" ? To be honest I'm not sure if hexdump0815
>> > used grub,but I will explain this later.
>> >
>> > Anyway,I've got the idea by reading here :
>> >
>> > https://unix.stackexchange.com/questions/599141/how-to-install-grub-bootloader-as-second-stage-bootloader
>> > So,now,I'm going to explain what's the content of the partitions on my
>> > Frankenstein sd card.
>> >
>> > 1) /dev/sdh1 = unknown = 16 MB. I've created this partition by doing :
>> >
>> > $ sudo dd if=nv_uboot-snow.kpart of=/dev/sdh1
>> >
>> > Where I've got the file nv_uboot-snow.kpart ? From here :
>> >
>> > http://www.virtualopensystems.com/downloads/guides/kvm_on_chromebook/nv_u-boot-snow.kpart
>> >
>> > 2) /dev/sdh2 = unknown = 16 MB. This partition has been created by
>> > executing the following
>> >
>> > script :
>> >
>> > $ sudo ./scripts/sdcard.sh /dev/sdh
>> >
>> > 3) /dev/sdh3 = ext2 BOOT.
>> >
>> > Inside the partition /dev/sdh3 I have copied the following files and
>> > folders (taken
>> > from the hexdump0815 "chromebook_snow-armv7l-jammy.img.gz" file :
>> >
>> > a) dtb-5.18.1-stb-cbe+ = directory
>> > b) extlinux = directory
>> > c) extra = directory
>> >
>> > d) config.5.18.1-stb-cbe+ : file
>> > e) initrd.img-5.18.1-stb-cbe+ : file
>> > f) System.map-5.18.1-stb-cbe+ : file
>> > g) vmlinux.kpart-5.18.1-stb-cbe+ : file
>> > h) zImage-5.18.1-stb.cbe+ : file
>> >
>> > Inside the directory "dtb-5.18.1-stb-cbe+" there are the following files :
>> >
>> > a) exynos5250-snow.dtb
>> > b) exynos5250-snow-rev5.dtb
>> > c) exynos5250-spring.dtb
>> >
>> > Inside the directory "extlinux",there is the following file :
>> >
>> > a) extlinux.conf : that has the following content :
>> >
>> > TIMEOUT 30
>> >
>> > DEFAULT linux-snow-rev4
>> >
>> > MENU TITLE snow chromebook boot options
>> >
>> > # rev4 snow chromebook
>> > LABEL linux-snow-rev4
>> >   MENU LABEL linux rev4 snow
>> >   LINUX ../zImage-5.18.1-stb-cbe+
>> >   INITRD ../initrd.img-5.18.1-stb-cbe+
>> >   FDT ../dtb-5.18.1-stb-cbe+/exynos5250-snow.dtb
>> >   APPEND console=tty1 root=LABEL=rootpart ro rootwait net.ifnames=0
>> > ipv6.disable=1 fsck.repair=yes noresume
>> >
>> > # rev5 snow chromebook
>> > LABEL linux-snow-rev5
>> >   MENU LABEL linux rev5 snow
>> >   LINUX ../zImage-5.18.1-stb-cbe+
>> >   INITRD ../initrd.img-5.18.1-stb-cbe+
>> >   FDT ../dtb-5.18.1-stb-cbe+/exynos5250-snow-rev5.dtb
>> >   APPEND console=tty1 root=LABEL=rootpart ro rootwait net.ifnames=0
>> > ipv6.disable=1 fsck.repair=yes noresume
>> >
>> > # spring chromebook - untested
>> > LABEL linu

Re: How u-boot can chain "grub" and booting a mainline kernel on my ARM Chromebook

[Mario Marietto]

Excuse me. The problem is not the kernel version that I'm running,but how
to use the unverified u-boot created by virtual open systems to chainload
the kernel of whatever used to boot one recent ISO image created by
hexdump0815. Because it contains the code to put the chromebook in
hypervisor mode. Without that special u-boot version,I can for sure install
one ISO image of hexdump0815 (I've chosen jammy as an example,but
hexdump0815 created some more updated isos),but KVM will not be enabled.

On Sat, Jul 1, 2023 at 2:34 PM Peter Robinson  wrote:

> On Sat, Jul 1, 2023 at 1:25 PM Mario Marietto 
> wrote:
> >
> > Hello.
> >
> > I would like to enable KVM virtualization on my old ARM Chromebook
> > laptop,based on the Exynos5250 arm 32 bit cpu aka snow,model xe303c12.
>
> Upstream Linux kernel dropped support for running virt on 32 bit hosts
> (you can still run a 32 bit guest on a 64 bit host) in the upstream
> linux kernel with the 5.7 release (May 31st, 2020) so you'll probably
> have to run a 5.4.x LTS kernel rather than 5.18.x (not sure why you
> chose that one) at the very least.
>
> > The first thing I did has been to dd the image below directly on the sd
> > card :
> >
> >
> https://github.com/hexdump0815/imagebuilder/releases/download/220619-01/chromebook_snow-armv7l-jammy.img.gz
> >
> > and it worked like a charm,but kvm was disabled. So,I have started to
> look
> > for a good documentation to understand how to enable kvm and I found
> this :
> >
> > http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebook/
> >
> > I've followed all the instructions and it worked,but only with Ubuntu
> 13.04
> > and 14.04. More upgraded ubuntu versions give a lot of problems and they
> > don't work.
> >
> > So,I've thought about a fresh idea. What about to install the virtual
> open
> > systems "non-verified u-boot" on the first partition like explained in
> the
> > tutorial,and,instead of starting another u-boot after the original,can I
> > chain grub with the kernel installed for example by the ubuntu jammy iso
> > image created by "hexdump0815" ? To be honest I'm not sure if hexdump0815
> > used grub,but I will explain this later.
> >
> > Anyway,I've got the idea by reading here :
> >
> >
> https://unix.stackexchange.com/questions/599141/how-to-install-grub-bootloader-as-second-stage-bootloader
> > So,now,I'm going to explain what's the content of the partitions on my
> > Frankenstein sd card.
> >
> > 1) /dev/sdh1 = unknown = 16 MB. I've created this partition by doing :
> >
> > $ sudo dd if=nv_uboot-snow.kpart of=/dev/sdh1
> >
> > Where I've got the file nv_uboot-snow.kpart ? From here :
> >
> >
> http://www.virtualopensystems.com/downloads/guides/kvm_on_chromebook/nv_u-boot-snow.kpart
> >
> > 2) /dev/sdh2 = unknown = 16 MB. This partition has been created by
> > executing the following
> >
> > script :
> >
> > $ sudo ./scripts/sdcard.sh /dev/sdh
> >
> > 3) /dev/sdh3 = ext2 BOOT.
> >
> > Inside the partition /dev/sdh3 I have copied the following files and
> > folders (taken
> > from the hexdump0815 "chromebook_snow-armv7l-jammy.img.gz" file :
> >
> > a) dtb-5.18.1-stb-cbe+ = directory
> > b) extlinux = directory
> > c) extra = directory
> >
> > d) config.5.18.1-stb-cbe+ : file
> > e) initrd.img-5.18.1-stb-cbe+ : file
> > f) System.map-5.18.1-stb-cbe+ : file
> > g) vmlinux.kpart-5.18.1-stb-cbe+ : file
> > h) zImage-5.18.1-stb.cbe+ : file
> >
> > Inside the directory "dtb-5.18.1-stb-cbe+" there are the following files
> :
> >
> > a) exynos5250-snow.dtb
> > b) exynos5250-snow-rev5.dtb
> > c) exynos5250-spring.dtb
> >
> > Inside the directory "extlinux",there is the following file :
> >
> > a) extlinux.conf : that has the following content :
> >
> > TIMEOUT 30
> >
> > DEFAULT linux-snow-rev4
> >
> > MENU TITLE snow chromebook boot options
> >
> > # rev4 snow chromebook
> > LABEL linux-snow-rev4
> >   MENU LABEL linux rev4 snow
> >   LINUX ../zImage-5.18.1-stb-cbe+
> >   INITRD ../initrd.img-5.18.1-stb-cbe+
> >   FDT ../dtb-5.18.1-stb-cbe+/exynos5250-snow.dtb
> >   APPEND console=tty1 root=LABEL=rootpart ro rootwait net.ifnames=0
> > ipv6.disable=1 fsck.repair=yes noresume
> >
> > # rev5 snow chromebook
> > LABEL linux-snow-rev5
> >   MENU LABEL linux rev5 snow
> >   LINUX ../zImage-5.18.1-stb-cbe+
> >   INITRD ../initrd.img-5.18.1-stb-cbe+
> >   FDT ../dtb-5.18.1-stb-cbe+/exynos5250-snow-rev5.dtb
> >   APPEND console=tty1 root=LABEL=rootpart ro rootwait net.ifnames=0
> > ipv6.disable=1 fsck.repair=yes noresume
> >
> > # spring chromebook - untested
> > LABEL linux-spring
> >   MENU LABEL linux spring
> >   LINUX ../zImage-5.18.1-stb-cbe+
> >   INITRD ../initrd.img-5.18.1-stb-cbe+
> >   # rev4 snow chromebook
> >   FDT ../dtb-5.18.1-stb-cbe+/exynos5250-spring.dtb
> >   APPEND console=tty1 root=LABEL=rootpart ro rootwait net.ifnames=0
> > ipv6.disable=1 fsck.repair=yes noresume
> >
> > Inside the extra directory there are the following fil

Re: How u-boot can chain "grub" and booting a mainline kernel on my ARM Chromebook

[Peter Robinson]

On Sat, Jul 1, 2023 at 1:25 PM Mario Marietto  wrote:
>
> Hello.
>
> I would like to enable KVM virtualization on my old ARM Chromebook
> laptop,based on the Exynos5250 arm 32 bit cpu aka snow,model xe303c12.

Upstream Linux kernel dropped support for running virt on 32 bit hosts
(you can still run a 32 bit guest on a 64 bit host) in the upstream
linux kernel with the 5.7 release (May 31st, 2020) so you'll probably
have to run a 5.4.x LTS kernel rather than 5.18.x (not sure why you
chose that one) at the very least.

> The first thing I did has been to dd the image below directly on the sd
> card :
>
> https://github.com/hexdump0815/imagebuilder/releases/download/220619-01/chromebook_snow-armv7l-jammy.img.gz
>
> and it worked like a charm,but kvm was disabled. So,I have started to look
> for a good documentation to understand how to enable kvm and I found this :
>
> http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebook/
>
> I've followed all the instructions and it worked,but only with Ubuntu 13.04
> and 14.04. More upgraded ubuntu versions give a lot of problems and they
> don't work.
>
> So,I've thought about a fresh idea. What about to install the virtual open
> systems "non-verified u-boot" on the first partition like explained in the
> tutorial,and,instead of starting another u-boot after the original,can I
> chain grub with the kernel installed for example by the ubuntu jammy iso
> image created by "hexdump0815" ? To be honest I'm not sure if hexdump0815
> used grub,but I will explain this later.
>
> Anyway,I've got the idea by reading here :
>
> https://unix.stackexchange.com/questions/599141/how-to-install-grub-bootloader-as-second-stage-bootloader
> So,now,I'm going to explain what's the content of the partitions on my
> Frankenstein sd card.
>
> 1) /dev/sdh1 = unknown = 16 MB. I've created this partition by doing :
>
> $ sudo dd if=nv_uboot-snow.kpart of=/dev/sdh1
>
> Where I've got the file nv_uboot-snow.kpart ? From here :
>
> http://www.virtualopensystems.com/downloads/guides/kvm_on_chromebook/nv_u-boot-snow.kpart
>
> 2) /dev/sdh2 = unknown = 16 MB. This partition has been created by
> executing the following
>
> script :
>
> $ sudo ./scripts/sdcard.sh /dev/sdh
>
> 3) /dev/sdh3 = ext2 BOOT.
>
> Inside the partition /dev/sdh3 I have copied the following files and
> folders (taken
> from the hexdump0815 "chromebook_snow-armv7l-jammy.img.gz" file :
>
> a) dtb-5.18.1-stb-cbe+ = directory
> b) extlinux = directory
> c) extra = directory
>
> d) config.5.18.1-stb-cbe+ : file
> e) initrd.img-5.18.1-stb-cbe+ : file
> f) System.map-5.18.1-stb-cbe+ : file
> g) vmlinux.kpart-5.18.1-stb-cbe+ : file
> h) zImage-5.18.1-stb.cbe+ : file
>
> Inside the directory "dtb-5.18.1-stb-cbe+" there are the following files :
>
> a) exynos5250-snow.dtb
> b) exynos5250-snow-rev5.dtb
> c) exynos5250-spring.dtb
>
> Inside the directory "extlinux",there is the following file :
>
> a) extlinux.conf : that has the following content :
>
> TIMEOUT 30
>
> DEFAULT linux-snow-rev4
>
> MENU TITLE snow chromebook boot options
>
> # rev4 snow chromebook
> LABEL linux-snow-rev4
>   MENU LABEL linux rev4 snow
>   LINUX ../zImage-5.18.1-stb-cbe+
>   INITRD ../initrd.img-5.18.1-stb-cbe+
>   FDT ../dtb-5.18.1-stb-cbe+/exynos5250-snow.dtb
>   APPEND console=tty1 root=LABEL=rootpart ro rootwait net.ifnames=0
> ipv6.disable=1 fsck.repair=yes noresume
>
> # rev5 snow chromebook
> LABEL linux-snow-rev5
>   MENU LABEL linux rev5 snow
>   LINUX ../zImage-5.18.1-stb-cbe+
>   INITRD ../initrd.img-5.18.1-stb-cbe+
>   FDT ../dtb-5.18.1-stb-cbe+/exynos5250-snow-rev5.dtb
>   APPEND console=tty1 root=LABEL=rootpart ro rootwait net.ifnames=0
> ipv6.disable=1 fsck.repair=yes noresume
>
> # spring chromebook - untested
> LABEL linux-spring
>   MENU LABEL linux spring
>   LINUX ../zImage-5.18.1-stb-cbe+
>   INITRD ../initrd.img-5.18.1-stb-cbe+
>   # rev4 snow chromebook
>   FDT ../dtb-5.18.1-stb-cbe+/exynos5250-spring.dtb
>   APPEND console=tty1 root=LABEL=rootpart ro rootwait net.ifnames=0
> ipv6.disable=1 fsck.repair=yes noresume
>
> Inside the extra directory there are the following files :
>
> a) kernel-chromebook_snow-legacy.tar.gz
> b) uboot.kpart.cbe-snow
> c) uboot.kpart.cbe-snow-alternative
> d) uboot.kpart.cbe-spring
>
> 4) /dev/sdh4 : inside here I have copied all the files of the jammy
> userland prepared by hexdump0818.
>
> That's all. What I want to do is if and how can I chainload the
> "non-verified u-boot"
> that is installed on the partition /dev/sdh1 with grub or whatever
> mechanism it is able to boot the hexdump0815 jammy iso image.
>
> As I repeat,the "non-verified u-boot" is produced by the script called
> "build.sh",that's stored inside the u-boot/scripts directory. And if what I
> want to do is impossible,can you explain to me how I can enable kvm on my
> chromebook arm,using the most recent kernel possible ? I already know that
> the support for kvm on

Re: [PATCH v4] dt-bindings: riscv: deprecate riscv,isa

[Andrew Jones]

On Fri, Jun 30, 2023 at 07:04:04PM +0100, Conor Dooley wrote:
> From: Conor Dooley 
...
> +oneOf:
> +  - required:
> +  - riscv,isa
> +  - required:
> +  - riscv,isa-base
> +

I guess this means a DT must have either isa or isa-base, but not both.
What should QEMU and other platforms which want to provide DTs that work
for older kernels, but also start using the new schema do? I'd guess
they'd like to provide both, where they'd expect isa-base to be used by
newer kernels and isa by the old.

Thanks,
drew

How u-boot can chain "grub" and booting a mainline kernel on my ARM Chromebook

[Mario Marietto]

Hello.

I would like to enable KVM virtualization on my old ARM Chromebook
laptop,based on the Exynos5250 arm 32 bit cpu aka snow,model xe303c12.
The first thing I did has been to dd the image below directly on the sd
card :

https://github.com/hexdump0815/imagebuilder/releases/download/220619-01/chromebook_snow-armv7l-jammy.img.gz

and it worked like a charm,but kvm was disabled. So,I have started to look
for a good documentation to understand how to enable kvm and I found this :

http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebook/

I've followed all the instructions and it worked,but only with Ubuntu 13.04
and 14.04. More upgraded ubuntu versions give a lot of problems and they
don't work.

So,I've thought about a fresh idea. What about to install the virtual open
systems "non-verified u-boot" on the first partition like explained in the
tutorial,and,instead of starting another u-boot after the original,can I
chain grub with the kernel installed for example by the ubuntu jammy iso
image created by "hexdump0815" ? To be honest I'm not sure if hexdump0815
used grub,but I will explain this later.

Anyway,I've got the idea by reading here :

https://unix.stackexchange.com/questions/599141/how-to-install-grub-bootloader-as-second-stage-bootloader
So,now,I'm going to explain what's the content of the partitions on my
Frankenstein sd card.

1) /dev/sdh1 = unknown = 16 MB. I've created this partition by doing :

$ sudo dd if=nv_uboot-snow.kpart of=/dev/sdh1

Where I've got the file nv_uboot-snow.kpart ? From here :

http://www.virtualopensystems.com/downloads/guides/kvm_on_chromebook/nv_u-boot-snow.kpart

2) /dev/sdh2 = unknown = 16 MB. This partition has been created by
executing the following

script :

$ sudo ./scripts/sdcard.sh /dev/sdh

3) /dev/sdh3 = ext2 BOOT.

Inside the partition /dev/sdh3 I have copied the following files and
folders (taken
from the hexdump0815 "chromebook_snow-armv7l-jammy.img.gz" file :

a) dtb-5.18.1-stb-cbe+ = directory
b) extlinux = directory
c) extra = directory

d) config.5.18.1-stb-cbe+ : file
e) initrd.img-5.18.1-stb-cbe+ : file
f) System.map-5.18.1-stb-cbe+ : file
g) vmlinux.kpart-5.18.1-stb-cbe+ : file
h) zImage-5.18.1-stb.cbe+ : file

Inside the directory "dtb-5.18.1-stb-cbe+" there are the following files :

a) exynos5250-snow.dtb
b) exynos5250-snow-rev5.dtb
c) exynos5250-spring.dtb

Inside the directory "extlinux",there is the following file :

a) extlinux.conf : that has the following content :

TIMEOUT 30

DEFAULT linux-snow-rev4

MENU TITLE snow chromebook boot options

# rev4 snow chromebook
LABEL linux-snow-rev4
  MENU LABEL linux rev4 snow
  LINUX ../zImage-5.18.1-stb-cbe+
  INITRD ../initrd.img-5.18.1-stb-cbe+
  FDT ../dtb-5.18.1-stb-cbe+/exynos5250-snow.dtb
  APPEND console=tty1 root=LABEL=rootpart ro rootwait net.ifnames=0
ipv6.disable=1 fsck.repair=yes noresume

# rev5 snow chromebook
LABEL linux-snow-rev5
  MENU LABEL linux rev5 snow
  LINUX ../zImage-5.18.1-stb-cbe+
  INITRD ../initrd.img-5.18.1-stb-cbe+
  FDT ../dtb-5.18.1-stb-cbe+/exynos5250-snow-rev5.dtb
  APPEND console=tty1 root=LABEL=rootpart ro rootwait net.ifnames=0
ipv6.disable=1 fsck.repair=yes noresume

# spring chromebook - untested
LABEL linux-spring
  MENU LABEL linux spring
  LINUX ../zImage-5.18.1-stb-cbe+
  INITRD ../initrd.img-5.18.1-stb-cbe+
  # rev4 snow chromebook
  FDT ../dtb-5.18.1-stb-cbe+/exynos5250-spring.dtb
  APPEND console=tty1 root=LABEL=rootpart ro rootwait net.ifnames=0
ipv6.disable=1 fsck.repair=yes noresume

Inside the extra directory there are the following files :

a) kernel-chromebook_snow-legacy.tar.gz
b) uboot.kpart.cbe-snow
c) uboot.kpart.cbe-snow-alternative
d) uboot.kpart.cbe-spring

4) /dev/sdh4 : inside here I have copied all the files of the jammy
userland prepared by hexdump0818.

That's all. What I want to do is if and how can I chainload the
"non-verified u-boot"
that is installed on the partition /dev/sdh1 with grub or whatever
mechanism it is able to boot the hexdump0815 jammy iso image.

As I repeat,the "non-verified u-boot" is produced by the script called
"build.sh",that's stored inside the u-boot/scripts directory. And if what I
want to do is impossible,can you explain to me how I can enable kvm on my
chromebook arm,using the most recent kernel possible ? I already know that
the support for kvm on arm 32 has been dropped on kernel 5.7,but for me to
use a lower kernel than 5.7 is ok. I've been working on this project for a
lot of months. I would like to see some progress. Thanks.

-- 
Mario.

Re: [PATCH v4] dt-bindings: riscv: deprecate riscv,isa

[Conor Dooley]

On Sat, Jul 01, 2023 at 01:01:40PM +0200, Andrew Jones wrote:
> On Fri, Jun 30, 2023 at 07:04:04PM +0100, Conor Dooley wrote:
> > From: Conor Dooley 
> ...
> > +oneOf:
> > +  - required:
> > +  - riscv,isa
> > +  - required:
> > +  - riscv,isa-base
> > +
> 
> I guess this means a DT must have either isa or isa-base, but not both.
> What should QEMU and other platforms which want to provide DTs that work
> for older kernels, but also start using the new schema do? I'd guess
> they'd like to provide both, where they'd expect isa-base to be used by
> newer kernels and isa by the old.

Sure, is just s/oneOf/anyOf/.


signature.asc
Description: PGP signature

Aw: Re: Re: Re: distro_boot vs. env-based bootmenu

[Frank Wunderlich]

Hi Jonas

thx again for your valuable answer

> Gesendet: Samstag, 01. Juli 2023 um 10:12 Uhr
> Von: "Jonas Karlman" 
> An: "Frank Wunderlich" 
> Cc: "Simon Glass" , "U-Boot Mailing List" 
> , "Heinrich Schuchardt" 
> , "Ilias Apalodimas" 
> 
> Betreff: Re: Aw: Re: Re: distro_boot vs. env-based bootmenu
>
> Hi Frank,
> On 2023-06-30 19:51, Frank Wunderlich wrote:
> > Hi Jonas
> > 
> > sorry for the delay. i came back to this and tried your way. Thx for your 
> > information...there is no real example in the docs (or i didn't found it) 
> > for manual trigger the extlinux-boot, so your information helps a lot.
> > 
> >> Gesendet: Sonntag, 30. April 2023 um 19:40 Uhr
> >> Von: "Jonas Karlman" 
> >> An: "Frank Wunderlich" , "Simon Glass" 
> >> 
> >> Cc: "U-Boot Mailing List" , "Heinrich Schuchardt" 
> >> , "Ilias Apalodimas" 
> >> 
> >> Betreff: Re: Aw: Re: distro_boot vs. env-based bootmenu
> >>
> >> Hi Frank,
> >>
> >> On 2023-04-30 15:25, Frank Wunderlich wrote:
> >>> Hi
> >>>
> >>> I tried to find out why distroboot is enabled (i have not set it in my 
> >>> defconfig) and i think this is why:
> >>>
> >>>   │ Symbol: DISTRO_DEFAULTS [=y]  
> >>>   │  
> >>>   │ Type  : bool  
> >>>   │  
> >>>   │ Prompt: Select defaults suitable for booting general purpose Linux 
> >>> dist │  
> >>>   │   Location:   
> >>>   │  
> >>>   │ (3) -> Boot options   
> >>>   │  
> >>>   │   Defined at boot/Kconfig:833 
> >>>   │  
> >>>   │   Selects: BOOT_DEFAULTS [=y] && AUTO_COMPLETE [=y] && 
> >>> CMDLINE_EDITING  │  
> >>>   │   Implied by [y]: 
> >>>   │  
> >>>   │   - ARCH_ROCKCHIP [=y] &&  && !ROCKCHIP_RK3399 [=n]
> >>>
> >>> as far as i see you've got a response from Jonas about this option and he 
> >>> changed Kconfig file to BOOTSTD_DEFAULTS
> >>>
> >>> as i have not used BOOTSTD_DEFAULTS before, what needs to be changed to 
> >>> have it working?
> >>
> >> Please update to latest master branch, rk356x is not fully working
> >> with v2023.04 or earlier, especially BOOTSTD without extra CONFIGs.
> >>
> >> With latest master branch CONFIG_BOOTSTD_DEFAULTS=y should be set by
> >> default for all ARCH_ROCKCHIP. And should work very similar to if you
> >> used to have "run distro_bootcmd" as your bootcmd.
> > 
> > As i use builtin-environment there is no distro_bootcmd which i can run.
> >  
> >> It is still unclear what script/bootcmd you are trying to use, or if
> >> you used to have "run distro_bootcmd" as a fallback. Replacing
> >> "run distro_bootcmd" with "bootflow scan -lb" or "bootflow scan"
> >> could work as such fallback option.
> > 
> > but with "bootflow scan -lb" it works except 1 thing: old bootchain looked 
> > in config directory for the files (kernel+fdt) whereas new way looks in 
> > root of partition and now needs additional extlinux prefix.
> 
> This could be related to an issue that was fixed in v2023.07-rc5:
> 
>   bootstd: Fix relative path use in extlinux bootmeth
> 
> See 
> https://source.denx.de/u-boot/u-boot/-/commit/a7e4dffcd8c582bf4344548270d2fc7ac6c0f9ec
> 
> If not then please provide more details, in case this is a bug.

thx, after rebase on rc5 it works as expected...rebased on rc4 a few hours 
before rc5 was relasted :p

as this commit was done by you thx for fixing this ;)

> > 
> > and yes i want distroboot as fallback...
> > 
> > is there a way to avoid this to hold the file compatible?
> 
> The intent is that the new standard boot should be as compatible as
> possible as the old script based distro boot, depending on you boot
> script.
> 
> If you use any of the script part that the old distro boot provided you
> will have to adjust your boot script, e.g. replace "run distro_bootcmd"
> with "bootflow scan -lb" or "bootflow scan", and modify boot_targets and
> bootmeths to control boot order.
> 
> See 
> https://u-boot.readthedocs.io/en/latest/develop/bootstd.html#controlling-ordering

simply added this to my builtin-environment if anyone wants to run 
distro_bootcmd manually (was called automaticly before).

distro_bootcmd=bootflow scan -lb

now all looks good

> > 
> > why i use the environment bootmenu? i do a bit more in the menuitems (and 
> > before) e.g. loading a uEnv.txt to override some options
> > and for testing. have bootargs only defined once, have testkernels with 
> > initrd and some special stuff with asking for user input
> > (list kernels from mmc/tftp/... and let user choose which 
> > kernel/fdt/initrd/...). Such things are imho not possible with extlinux 
> > way.
> 
> I think there are some limited menu handling with standard boot, it may
> depend on a working video driver, something that RK356x does not have.
> 
> Regards,
> Jonas
> 
> > 
> > currently only bpi-r2pro u

Aw: Re: distro_boot vs. env-based bootmenu

[Frank Wunderlich]

Hi

thanks for your anser

> Gesendet: Samstag, 01. Juli 2023 um 04:08 Uhr
> Von: "AKASHI Takahiro" 
> Hi,
>
> On Wed, Apr 12, 2023 at 11:22:23AM +0200, Frank Wunderlich wrote:
> > Hi,
> >
> > i try to move from distro-boot (extlinux-config files) to an env-based 
> > bootmenu (builtin-environment) for
> > my bananapi r2pro.
> >
> > basicly it works, but i see more bootmenu-entries than i have defined in my 
> > environment
> >
> >  *** U-Boot Boot Menu ***
> >
> >   1. Boot from SD/EMMC.
> >   mmc 1:2
> >   mmc 1:3
> >   mmc 1:4
> >   U-Boot consoleHit any key to stop autoboot: 2
> >
> > i have only defined one botmenu-entry (first one in uEnv_r2pro.txt)
> >
> > bootmenu_0=1. Boot from SD/EMMC.=run newboot
> > bootmenu_default=0
> >
> > i guess the 3 mmc 1:x entries are part from distro-boot. i see a series 
> > from simon where he drops
> > distroboot for rockchip-boards.
>
> Probably they came from UEFI's removable media support, specifically
> commit c606c0059f7f
> Author: Masahisa Kojima 
> Date:   Thu Apr 28 17:09:42 2022 +0900
>
> bootmenu: add UEFI boot entry into bootmenu

yes, thats right, disabling efi (that was somehow enabled by default as i do 
not find any EFI in my defconfig)

https://github.com/frank-w/u-boot/blob/2023-07-bpi/configs/evb-rk3568_defconfig

> > https://patchwork.ozlabs.org/project/uboot/patch/20230409084454.v9.8.I4cf7708a1ba953b9abd81375d93af34665c7b251@changeid/
> >
> > can anyone explain me where i can disable the mmc 1:x entries? i wanted to 
> > leave distro_boot as
> > fallback but it seems this is not possible.
>
> Try to disable either CONFIG_CMD_EFICONFIG or CONFIG_CMD_BOOTEFI_BOOTMGR,
> even CONFIG_EFI_LOADER if you don't need UEFI subsystem at all.

disabled CONFIG_EFI_LOADER=n and CONFIG_EFI_LOADER and now the menuitems are 
disappeared and i have no efi-options set

> -Takahiro Akashi

regards Frank

Re: Aw: Re: Re: distro_boot vs. env-based bootmenu

[Jonas Karlman]

Hi Frank,
On 2023-06-30 19:51, Frank Wunderlich wrote:
> Hi Jonas
> 
> sorry for the delay. i came back to this and tried your way. Thx for your 
> information...there is no real example in the docs (or i didn't found it) for 
> manual trigger the extlinux-boot, so your information helps a lot.
> 
>> Gesendet: Sonntag, 30. April 2023 um 19:40 Uhr
>> Von: "Jonas Karlman" 
>> An: "Frank Wunderlich" , "Simon Glass" 
>> 
>> Cc: "U-Boot Mailing List" , "Heinrich Schuchardt" 
>> , "Ilias Apalodimas" 
>> 
>> Betreff: Re: Aw: Re: distro_boot vs. env-based bootmenu
>>
>> Hi Frank,
>>
>> On 2023-04-30 15:25, Frank Wunderlich wrote:
>>> Hi
>>>
>>> I tried to find out why distroboot is enabled (i have not set it in my 
>>> defconfig) and i think this is why:
>>>
>>>   │ Symbol: DISTRO_DEFAULTS [=y]
>>> │  
>>>   │ Type  : bool
>>> │  
>>>   │ Prompt: Select defaults suitable for booting general purpose Linux dist 
>>> │  
>>>   │   Location: 
>>> │  
>>>   │ (3) -> Boot options 
>>> │  
>>>   │   Defined at boot/Kconfig:833   
>>> │  
>>>   │   Selects: BOOT_DEFAULTS [=y] && AUTO_COMPLETE [=y] && CMDLINE_EDITING  
>>> │  
>>>   │   Implied by [y]:   
>>> │  
>>>   │   - ARCH_ROCKCHIP [=y] &&  && !ROCKCHIP_RK3399 [=n]
>>>
>>> as far as i see you've got a response from Jonas about this option and he 
>>> changed Kconfig file to BOOTSTD_DEFAULTS
>>>
>>> as i have not used BOOTSTD_DEFAULTS before, what needs to be changed to 
>>> have it working?
>>
>> Please update to latest master branch, rk356x is not fully working
>> with v2023.04 or earlier, especially BOOTSTD without extra CONFIGs.
>>
>> With latest master branch CONFIG_BOOTSTD_DEFAULTS=y should be set by
>> default for all ARCH_ROCKCHIP. And should work very similar to if you
>> used to have "run distro_bootcmd" as your bootcmd.
> 
> As i use builtin-environment there is no distro_bootcmd which i can run.
>  
>> It is still unclear what script/bootcmd you are trying to use, or if
>> you used to have "run distro_bootcmd" as a fallback. Replacing
>> "run distro_bootcmd" with "bootflow scan -lb" or "bootflow scan"
>> could work as such fallback option.
> 
> but with "bootflow scan -lb" it works except 1 thing: old bootchain looked in 
> config directory for the files (kernel+fdt) whereas new way looks in root of 
> partition and now needs additional extlinux prefix.

This could be related to an issue that was fixed in v2023.07-rc5:

  bootstd: Fix relative path use in extlinux bootmeth

See 
https://source.denx.de/u-boot/u-boot/-/commit/a7e4dffcd8c582bf4344548270d2fc7ac6c0f9ec

If not then please provide more details, in case this is a bug.

> 
> and yes i want distroboot as fallback...
> 
> is there a way to avoid this to hold the file compatible?

The intent is that the new standard boot should be as compatible as
possible as the old script based distro boot, depending on you boot
script.

If you use any of the script part that the old distro boot provided you
will have to adjust your boot script, e.g. replace "run distro_bootcmd"
with "bootflow scan -lb" or "bootflow scan", and modify boot_targets and
bootmeths to control boot order.

See 
https://u-boot.readthedocs.io/en/latest/develop/bootstd.html#controlling-ordering

> 
> why i use the environment bootmenu? i do a bit more in the menuitems (and 
> before) e.g. loading a uEnv.txt to override some options
> and for testing. have bootargs only defined once, have testkernels with 
> initrd and some special stuff with asking for user input
> (list kernels from mmc/tftp/... and let user choose which 
> kernel/fdt/initrd/...). Such things are imho not possible with extlinux 
> way.

I think there are some limited menu handling with standard boot, it may
depend on a working video driver, something that RK356x does not have.

Regards,
Jonas

> 
> currently only bpi-r2pro uses extlinux boot and the other 3 boards using the 
> builtin environment bootmenu. So to keep all boards nearly same i want to 
> have the same for r2pro but allow users with extlinux still using this.
> 
>>> basicly my Plan is to script the bootup via env in script with a bootmenu 
>>> (default entry + additional ones which can be 
>>> changed by an env.txt file), but i do not want to break existing setups 
>>> (using extlinux/*.conf behaviour) and no additional
>>> bootmenu-entries.
>>
>> The "distro" bootmeth described at the documentation you linked to will
>> looks for a file called extlinux/extlinux.conf.
>>
>> Is there a special reason why you need to use a custom bootmenu script
>> and are moving from distro-boot (extlinux-config files)?
>>
>>>
>>> is there any documentation describing the "Standard boot"?
>>>
>>> i found this, but it looks