Re: U-Boot: extlinux.conf boot menu support appears to be broken by commit 739e8361f3fe78038251216df6096a32bc2d5839
On Tue, Jan 17, 2023 at 09:39:09AM +0100 Manuel Traut wrote: > Can you test with the attached patch? [...] > From: Manuel Traut > Date: Tue, 17 Jan 2023 09:30:27 +0100 > Subject: [PATCH] menu: Ignore prompt variable if timeout is != 0 > > Since 739e8361f3fe78038251216df6096a32bc2d5839, a system with the following > /boot/extlinux/extlinux.conf (which sets timeout to 50) immediately boots the > first entry in the config without displaying a boot menu. According to the > description, that should only happen if both prompt and timeout are set to > zero > in the config, but it also happens with timeout set to a non-zero value. > > Reported-by: Karsten Merker > Signed-off-by: Manuel Traut Tested-by: Karsten Merker Hello, many thanks for the patch. I have tested it on top of current git head and it solves the extlinux.conf menu issue: with timeout set to a non-zero value the menu gets displayed and with timeout set to zero the system immediately boots the default entry, i.e. both cases work as expected. JFTR, here are the boot logs for both test cases: -8<--8<--8<--8<--8<--8<- With timeout=50: U-Boot 2023.01-00623-g1d3da4d31b (Jan 17 2023 - 21:17:48 +0100) [...] Hit any key to stop autoboot: 0 Device 0: QEMU VirtIO Block Device Type: Hard Disk Capacity: 102400.0 MB = 100.0 GB (209715200 x 512) ... is now current device Scanning virtio 0:1... Found /boot/extlinux/extlinux.conf Retrieving file: /boot/extlinux/extlinux.conf U-Boot menu 1: Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 2: Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 (rescue target) 3: Debian GNU/Linux bookworm/sid 6.0.0-6-riscv64 4: Debian GNU/Linux bookworm/sid 6.0.0-6-riscv64 (rescue target) 5: Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64 6: Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64 (rescue target) Enter choice: 1 1: Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 Retrieving file: /boot/vmlinux-6.1.0-1-riscv64 Retrieving file: /boot/initrd.img-6.1.0-1-riscv64 append: root=/dev/vda1 rw noquiet Moving Image from 0x8400 to 0x8020, end=815e5000 ## Flattened Device Tree blob at ff7334b0 Booting using the fdt blob at 0xff7334b0 Working FDT set to ff7334b0 Using Device Tree in place at ff7334b0, end ff737dea Working FDT set to ff7334b0 Starting kernel ... -8<--8<--8<--8<--8<--8<- With timeout=0: === U-Boot 2023.01-00623-g1d3da4d31b (Jan 17 2023 - 21:17:48 +0100) [...] Hit any key to stop autoboot: 0 Device 0: QEMU VirtIO Block Device Type: Hard Disk Capacity: 102400.0 MB = 100.0 GB (209715200 x 512) ... is now current device Scanning virtio 0:1... Found /boot/extlinux/extlinux.conf Retrieving file: /boot/extlinux/extlinux.conf 1: Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 Retrieving file: /boot/vmlinux-6.1.0-1-riscv64 Retrieving file: /boot/initrd.img-6.1.0-1-riscv64 append: root=/dev/vda1 rw noquiet Moving Image from 0x8400 to 0x8020, end=815e5000 ## Flattened Device Tree blob at ff7334b0 Booting using the fdt blob at 0xff7334b0 Working FDT set to ff7334b0 Using Device Tree in place at ff7334b0, end ff737dea Working FDT set to ff7334b0 Starting kernel ... -8<--8<--8<--8<--8<--8<- Regards, Karsten -- Hiermit widerspreche ich ausdrücklich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung.
U-Boot: extlinux.conf boot menu support appears to be broken by commit 739e8361f3fe78038251216df6096a32bc2d5839
Hello, it looks like the following commit has broken the extlinux.conf boot menu support in U-Boot: -8<--8<--8<--8<--8<--8<- commit 739e8361f3fe78038251216df6096a32bc2d5839 Author: Manuel Traut Date: Fri Nov 18 09:00:27 2022 +0100 distro/pxeboot: Handle prompt variable Regarding the documentation found here: https://github.com/u-boot/u-boot/blob/master/common/menu.c#L347 If both timeout and prompt is set to 0 the default entry shall be booted immediately. However the current behaviour is that the prompt is shown (tested with distroboot) until the user selects an entry (no timeout). This change implements a behaviour as documented. It was tested with distroboot. Signed-off-by: Manuel Traut Reviewed-by: Simon Glass Reviewed-by: Simon Glass -8<--8<--8<--8<--8<--8<- Since the commit above, a system with the following /boot/extlinux/extlinux.conf (which sets timeout to 50) immediately boots the first entry in the config without displaying a boot menu. According to the description, that should only happen if both prompt and timeout are set to zero in the config, but it also happens with timeout set to a non-zero value as in the config below: -8<--8<--8<--8<--8<--8<- ## /boot/extlinux/extlinux.conf ## ## IMPORTANT WARNING ## ## The configuration of this file is generated automatically. ## Do not edit this file manually, use: u-boot-update default l0 menu title U-Boot menu prompt 0 timeout 50 label l0 menu label Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 linux /boot/vmlinux-6.1.0-1-riscv64 initrd /boot/initrd.img-6.1.0-1-riscv64 append root=/dev/vda1 rw noquiet label l0r menu label Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 (rescue target) linux /boot/vmlinux-6.1.0-1-riscv64 initrd /boot/initrd.img-6.1.0-1-riscv64 append root=/dev/vda1 rw noquiet single label l1 menu label Debian GNU/Linux bookworm/sid 6.0.0-6-riscv64 linux /boot/vmlinux-6.0.0-6-riscv64 initrd /boot/initrd.img-6.0.0-6-riscv64 append root=/dev/vda1 rw noquiet label l1r menu label Debian GNU/Linux bookworm/sid 6.0.0-6-riscv64 (rescue target) linux /boot/vmlinux-6.0.0-6-riscv64 initrd /boot/initrd.img-6.0.0-6-riscv64 append root=/dev/vda1 rw noquiet single label l2 menu label Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64 linux /boot/vmlinux-6.0.0-5-riscv64 initrd /boot/initrd.img-6.0.0-5-riscv64 append root=/dev/vda1 rw noquiet label l2r menu label Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64 (rescue target) linux /boot/vmlinux-6.0.0-5-riscv64 initrd /boot/initrd.img-6.0.0-5-riscv64 append root=/dev/vda1 rw noquiet single -8<--8<--8<--8<--8<--8<- Up to commit 51c5c28af59c19407d6602336ac7374dd1432c49 the boot process with the extlinux.conf above looks as follows: -8<--8<--8<--8<--8<--8<- Hit any key to stop autoboot: 0 Device 0: QEMU VirtIO Block Device Type: Hard Disk Capacity: 102400.0 MB = 100.0 GB (209715200 x 512) ... is now current device Scanning virtio 0:1... Found /boot/extlinux/extlinux.conf Retrieving file: /boot/extlinux/extlinux.conf U-Boot menu 1: Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 2: Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 (rescue target) 3: Debian GNU/Linux bookworm/sid 6.0.0-6-riscv64 4: Debian GNU/Linux bookworm/sid 6.0.0-6-riscv64 (rescue target) 5: Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64 6: Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64 (rescue target) Enter choice: -8<--8<--8<--8<--8<--8<- The user can then either select a boot menu entry or - if there is no user input - the system boots the first entry after the timeout set in extlinux.conf is over. Starting with commit 739e8361f3fe78038251216df6096a32bc2d5839, the boot process looks as follows, i.e. there isn't a boot menu anymore but the system immediately boots the first entry: -8<--8<--8<--8<--8<--8<- Device 0: QEMU VirtIO Block Device Type: Hard Disk Capacity: 102400.0 MB = 100.0 GB (209715200 x 512) ... is now current device Scanning virtio 0:1... Found /boot/extlinux/extlinux.conf Retrieving file: /boot/extlinux/extlinux.conf 1: Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 Retrieving file: /boot/vmlinux-6.1.0-1-riscv64 Retrieving file: /boot/initrd.img-6.1.0-1-riscv64 append: root=/dev/vda1 rw noquiet Moving Image from 0x8400 to 0x8020,
Re: [PATCH v2] vbe: Allow probing the VBE bootmeth to fail in OS fixup
On Thu, Jan 12, 2023 at 04:48:54PM -0700 Simon Glass wrote:
> This device is created when there are no bootmeths defined in the device
> tree. But it cannot be probed without a device tree node.
>
> For now, ignore a probe failure.
>
> Signed-off-by: Simon Glass
> Reported-by: Karsten Merker
> Suggested-by: Heinrich Schuchardt
> Fixes: a56f663f0707 ("vbe: Add info about the VBE device to the fwupd node")
Tested-by: Karsten Merker
Hello,
applying this patch fixes the boot failure on the riscv64
qemu virt platform:
U-Boot 2023.01-1-g5c392f7ced (Jan 15 2023 - 21:34:26 +0100)
CPU: rv64imafdch_zicsr_zifencei_zihintpause_zba_zbb_zbc_zbs_sstc
Model: riscv-virtio,qemu
DRAM: 8 GiB
Core: 31 devices, 15 uclasses, devicetree: board
Flash: 32 MiB
Loading Environment from nowhere... OK
In:serial@1000
Out: serial@1000
Err: serial@1000
Net: eth0: virtio-net#2
Working FDT set to ff7344b0
Hit any key to stop autoboot: 0
Device 0: QEMU VirtIO Block Device
Type: Hard Disk
Capacity: 102400.0 MB = 100.0 GB (209715200 x 512)
... is now current device
Scanning virtio 0:1...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
U-Boot menu
1: Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64
2: Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 (rescue target)
3: Debian GNU/Linux bookworm/sid 6.0.0-6-riscv64
4: Debian GNU/Linux bookworm/sid 6.0.0-6-riscv64 (rescue target)
5: Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64
6: Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64 (rescue target)
Enter choice: 1:Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64
Retrieving file: /boot/initrd.img-6.1.0-1-riscv64
Retrieving file: /boot/vmlinux-6.1.0-1-riscv64
append: root=/dev/vda1 rw noquiet
Moving Image from 0x8400 to 0x8020, end=815e5000
## Flattened Device Tree blob at ff7344b0
Booting using the fdt blob at 0xff7344b0
Working FDT set to ff7344b0
Using Device Tree in place at ff7344b0, end ff738dea
Working FDT set to ff7344b0
Starting kernel ...
[0.00] Linux version 6.1.0-1-riscv64 (debian-ker...@lists.debian.org)
(gcc-12 (Debian 12.2.0-11) 12.2.0, GNU ld (GNU Binutils for Debian)
2.39.90.20221231) #1 SMP Debian 6.1.4-1 (2023-01-07)
[0.00] random: crng init done
[0.00] OF: fdt: Ignoring memory range 0x8000 - 0x8020
[0.00] Machine model: riscv-virtio,qemu
[...]
Regards and many thanks,
Karsten
--
Hiermit widerspreche ich ausdrücklich der Nutzung sowie der Weitergabe
meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt-
oder Meinungsforschung.
U-Boot v2023.01 broken on riscv64 qemu virt platform: "fdt fixup event failed"
Hello, it looks like U-Boot v2023.01 is currently broken for the riscv64 architecture on the qemu "virt" platform; the boot process of a riscv64 VM fails during FDT fixup: -8<--8<--8<--8<--8<--8<- OpenSBI v1.1 _ _ / __ \ / | _ \_ _| | | | |_ __ ___ _ __ | (___ | |_) || | | | | | '_ \ / _ \ '_ \ \___ \| _ < | | | |__| | |_) | __/ | | |) | |_) || |_ \/| .__/ \___|_| |_|_/|/_| | | |_| Platform Name : riscv-virtio,qemu Platform Features : medeleg Platform HART Count : 4 Platform IPI Device : aclint-mswi Platform Timer Device : aclint-mtimer @ 1000Hz Platform Console Device : uart8250 Platform HSM Device : --- Platform Reboot Device: sifive_test Platform Shutdown Device : sifive_test Firmware Base : 0x8000 Firmware Size : 312 KB Runtime SBI Version : 1.0 Domain0 Name : root Domain0 Boot HART : 2 Domain0 HARTs : 0*,1*,2*,3* Domain0 Region00 : 0x0200-0x0200 (I) Domain0 Region01 : 0x8000-0x8007 () Domain0 Region02 : 0x-0x (R,W,X) Domain0 Next Address : 0x8020 Domain0 Next Arg1 : 0x8220 Domain0 Next Mode : S-mode Domain0 SysReset : yes Boot HART ID : 2 Boot HART Domain : root Boot HART Priv Version: v1.12 Boot HART Base ISA: rv64imafdch Boot HART ISA Extensions : time,sstc Boot HART PMP Count : 16 Boot HART PMP Granularity : 4 Boot HART PMP Address Bits: 54 Boot HART MHPM Count : 16 Boot HART MIDELEG : 0x1666 Boot HART MEDELEG : 0x00f0b509 U-Boot 2023.01+dfsg-1 (Jan 10 2023 - 03:18:09 +) CPU: rv64imafdch_zicsr_zifencei_zihintpause_zba_zbb_zbc_zbs_sstc Model: riscv-virtio,qemu DRAM: 8 GiB Core: 31 devices, 15 uclasses, devicetree: board Flash: 32 MiB Loading Environment from nowhere... OK In:serial@1000 Out: serial@1000 Err: serial@1000 Net: eth0: virtio-net#2 Working FDT set to ff7344b0 Hit any key to stop autoboot: 0 Device 0: QEMU VirtIO Block Device Type: Hard Disk Capacity: 102400.0 MB = 100.0 GB (209715200 x 512) ... is now current device Scanning virtio 0:1... Found /boot/extlinux/extlinux.conf Retrieving file: /boot/extlinux/extlinux.conf U-Boot menu 1: Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 2: Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 (rescue target) 3: Debian GNU/Linux bookworm/sid 6.0.0-6-riscv64 4: Debian GNU/Linux bookworm/sid 6.0.0-6-riscv64 (rescue target) 5: Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64 6: Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64 (rescue target) Enter choice: 1:Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 Retrieving file: /boot/initrd.img-6.1.0-1-riscv64 Retrieving file: /boot/vmlinux-6.1.0-1-riscv64 append: root=/dev/vda1 rw noquiet Moving Image from 0x8400 to 0x8020, end=815e5000 ## Flattened Device Tree blob at ff7344b0 Booting using the fdt blob at 0xff7344b0 Working FDT set to ff7344b0 Using Device Tree in place at ff7344b0, end ff738dea Working FDT set to ff7344b0 ERROR: fdt fixup event failed: -22 - must RESET the board to recover. FDT creation failed! hanging...### ERROR ### Please RESET the board ### -8<--8<--8<--8<--8<--8<- Software versions used: - OpenSBI 1.1 (Debian package: opensbi 1.1-2) - QEMU 7.2.0 (Debian package: qemu-system-misc 1:7.2+dfsg-1+b2) - U-Boot v2023.01 (Debian package: u-boot-qemu 2023.01+dfsg-1) The issue is independent from the kernel that gets booted. With U-Boot v2022.10 everything works without problems. I have used git bisect (with qemu-riscv64_smode_defconfig) to narrow down the specific change that triggers the issue and that has resulted in the following commit: -8<--8<--8<--8<--8<--8<- commit a56f663f07073713042bb0fd08053aeb667e717b (HEAD) Author: Simon Glass Date: Thu Oct 20 18:23:14 2022 -0600 vbe: Add info about the VBE device to the fwupd node At present we put the driver in the /chosen node in U-Boot. This is a bit strange, since U-Boot doesn't normally use that node itself. It is better to put it under the bootstd node. To make this work we need to copy create the node under /chosen when fixing up the device tree. Copy over all the properties so that fwupd knows what to do. Update the sandbox device tree accordingly. Signed-off-by: Simon Glass -8<--8<--8<--8<--8<--8<- If you should happen to run Debian/unstable, the easiest way to reproduce the problem is as
Re: Using gerrit or github for review?
On Mon, Jul 13, 2020 at 06:05:42PM -0400, Corey Clayton wrote: > On Mon, Jul 13, 2020 at 12:25:42PM -0600, Simon Glass wrote: > > > At present U-Boot uses the mailing list for patch review. What do > > people think about trying out geritt or github for this? I'd be > > willing to do a trial with the -dm mailing list. > > This is both my first message to the mailing list and my first > email sent using mutt. I'm hoping to eventually participate > with patches and reviews but the mailing-list-driven > developement model has been a barrier for myself an probably > many others. I'm slowly trying to climb over it now but some > will never find the time. Perhaps a good question is: How long > does it take to learn the mailing-list workflow vs the github > workflow? > > If u-boot was using github, I would have contributed long ago > and I suspect there are others in the same bucket. Thats my > perspective at least :) Hello, to provide a different perspective: if U-Boot would have done everything inside github instead of using its traditional mailinglist-based workflow, I would never have contributed to U-Boot, and moving everything from the mailinglist to github would make any future contributions infeasible for me. The github workflow makes it impossible to open an issue or to comment on an existing issue or to provide feedback about a patch without being a github customer, and becoming a github customer is not an option for me (and quite a number of other open-source developers) as the github TOS contain clauses that I (and other people) consider completely unacceptable. Besides the aforementioned points I am generally concerned about the closed nature of the github issue- and pull-request system. While it is of course easily possible to move a git repo from github to somewhere else, it is as far as I know (please correct me if I should me misinformed here) not possible to export the comments and discussions in issues and pull requests in any meaningful way to some other hosting platform, which creates a strong vendor-lock-in once a project starts using the github issue and pull-request facilities. With the traditional mailinglist-based workflow on the other hand, moving everything to another hosting platform is trivial, so vendor-lock-in is not a problem there. Another problem that I see in the github workflow is that it requires being online all the time while the mailinglist-based workflow makes it easy to read and comment on patches while being offline. I am sure that many people will now think "everybody is online all day nowadays", but that's not true everywhere. I for example travel a lot by train and use the time on the train for catching up with current developments and for reviewing things. Where I live, for most practical purposes being on the train effectively means being offline as far as modern web applications are concerned. Availability of mobile internet access is spotty at best, and if one has internet connectivity inside the train at all, it is often so slow that using it for interactive work on a web interface is not feasible. Receiving, writing and sending emails on the other hand works without problems even with spotty and slow internet connectivity. Regards, Karsten -- Hiermit widerspreche ich ausdrücklich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung.
Re: [U-Boot] [v4 PATCH] RISCV: image: Add booti support
On Mon, May 06, 2019 at 10:06:39PM +0200, Heinrich Schuchardt wrote: > On 5/6/19 8:11 PM, Atish Patra wrote: > > This patch adds booti support for RISC-V Linux kernel. The existing > > bootm method will also continue to work as it is. [...] > > + "boot arm64/riscv Linux Image image from memory", booti_help_text > > %s/Image image/image/ > > "arm64/riscv" is distracting. If I am on RISC-V I cannot boot an ARM64 > image here. Remove the reference to the architecture, please. Hello, I'm not sure about the last point - ISTR (please correct me if my memory betrays me here) that an arm64 U-Boot can in principle be used to boot either an arm64 or an armv7 kernel, but the commands are different in those cases (booti for an arm64 "Image" format kernel and bootz for an armv7 "zImage" format kernel), so having the information which kernel format is supported by the respective commands appears useful to me. If the arm64 kernel image format would have a distinctive name (like "zImage" on armv7 or "bzImage" on x86) that would be less problematic, but with the confusion potential of "boot a Linux Image" (as in the arm64/riscv-specific "Image" format) vs "boot a Linux image" (as in generally some form of kernel image), I think explicitly mentioning the supported architectures makes sense. Regards, Karsten -- Ich widerspreche hiermit ausdrücklich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC PATCH 1/1] riscv: increase the environment size for the qemu-riscv platform to 128kB
The existing default size of 4kB is too small as the default environment has already nearly that size and defining a single additional environment variable can exceed the available space. Signed-off-by: Karsten Merker --- include/configs/qemu-riscv.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/qemu-riscv.h b/include/configs/qemu-riscv.h index 2588c5a0b2..3d9208bab2 100644 --- a/include/configs/qemu-riscv.h +++ b/include/configs/qemu-riscv.h @@ -20,7 +20,7 @@ #define CONFIG_STANDALONE_LOAD_ADDR0x8020 /* Environment options */ -#define CONFIG_ENV_SIZESZ_4K +#define CONFIG_ENV_SIZESZ_128K #define BOOT_TARGET_DEVICES(func) \ func(QEMU, qemu, na) \ -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC PATCH 0/1] riscv: qemu-riscv environment size
Hello, currently the environment size for the qemu-riscv platform is set to only 4kB. The default environment (with distro_bootcmd support) has already nearly 4kB, so defining additional environment variables very quickly exceeds the allocated space. Is there a specific reason to use only 4kB for the environment? If not, I would like to propose to increase the environment size to 128kB similar to what we have on a number of other platforms. Regards, Karsten Karsten Merker (1): riscv: increase the environment size for the qemu-riscv platform to 128kB include/configs/qemu-riscv.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] RISC-V: Crashes with OpenSBI+U-Boot on the qemu "virt" machine
Hello,
I'm currently testing the U-Boot patch for adding booti support
on the RISC-V architecture and the corresponding kernel patch on
a qemu riscv64 "virt" machine with OpenSBI. While performing the
tests, I have found two probably unrelated issues in U-Boot and
OpenSBI, though I'm unsure whether the actual source of the
problem is on the OpenSBI or on the U-Boot side, therefore I'm
sending this to both the U-Boot and the OpenSBI lists.
a) U-Boot crashes if the system has 2GB of RAM or more and
uses OpenSBI as the first stage:
-8<--8<--8<--8<--8<--8<-
OpenSBI v0.3 (May 3 2019 16:43:55)
_ _
/ __ \ / | _ \_ _|
| | | |_ __ ___ _ __ | (___ | |_) || |
| | | | '_ \ / _ \ '_ \ \___ \| _ < | |
| |__| | |_) | __/ | | |) | |_) || |_
\/| .__/ \___|_| |_|_/|/_|
| |
|_|
Platform Name : QEMU Virt Machine
Platform HART Features : RV64ACDFIMSU
Platform Max HARTs : 8
Current Hart : 0
Firmware Base : 0x8000
Firmware Size : 100 KB
Runtime SBI Version: 0.1
PMP0: 0x8000-0x8001 (A)
PMP1: 0x-0x (A,R,W,X)
U-Boot 2019.07-rc1-1-gc7ec976ce75 (May 03 2019 - 16:42:32 +0200)
CPU: rv64imafdcsu
Model: riscv-virtio,qemu
DRAM: 2 GiB
exception code: 7 , Store/AMO access fault , epc 8020019c , ra 8020a834
### ERROR ### Please RESET the board ###
-8<--8<--8<--8<--8<--8<-
With 1.9GB or less, the combination of U-Boot and OpenSBI works
and successfully boots a Linux system:
-8<--8<--8<--8<--8<--8<-
OpenSBI v0.3 (May 3 2019 16:43:55)
_ _
/ __ \ / | _ \_ _|
| | | |_ __ ___ _ __ | (___ | |_) || |
| | | | '_ \ / _ \ '_ \ \___ \| _ < | |
| |__| | |_) | __/ | | |) | |_) || |_
\/| .__/ \___|_| |_|_/|/_|
| |
|_|
Platform Name : QEMU Virt Machine
Platform HART Features : RV64ACDFIMSU
Platform Max HARTs : 8
Current Hart : 0
Firmware Base : 0x8000
Firmware Size : 100 KB
Runtime SBI Version: 0.1
PMP0: 0x8000-0x8001 (A)
PMP1: 0x-0x (A,R,W,X)
U-Boot 2019.07-rc1-1-gc7ec976ce75 (May 03 2019 - 16:42:32 +0200)
CPU: rv64imafdcsu
Model: riscv-virtio,qemu
DRAM: 1.9 GiB
In:uart@1000
Out: uart@1000
Err: uart@1000
Net:
Warning: virtio-net#2 using MAC address from ROM
eth0: virtio-net#2
Hit any key to stop autoboot: 0
Device 0: QEMU VirtIO Block Device
Type: Hard Disk
Capacity: 102400.0 MB = 100.0 GB (209715200 x 512)
... is now current device
Scanning virtio 0:1...
BOOTP broadcast 1
DHCP client bound to address 10.0.2.15 (2 ms)
Using virtio-net#2 device
TFTP from server 10.0.2.2; our IP address is 10.0.2.15
Filename 'boot.scr.uimg'.
Load address: 0x8210
Loading: *
TFTP error: 'Access violation' (2)
Not retrying...
BOOTP broadcast 1
DHCP client bound to address 10.0.2.15 (0 ms)
Using virtio-net#2 device
TFTP from server 10.0.2.2; our IP address is 10.0.2.15
Filename 'boot.scr.uimg'.
Load address: 0x8100
Loading: *
TFTP error: 'Access violation' (2)
Not retrying...
=> load virtio 0:1 ${kernel_addr_r} /boot/Image
8949964 bytes read in 4 ms (2.1 GiB/s)
=> booti ${kernel_addr_r} - ${fdtcontroladdr}
## Flattened Device Tree blob at f91353d0
Booting using the fdt blob at 0xf91353d0
Using Device Tree in place at f91353d0, end f9138d9c
Starting kernel ...
[0.00] OF: fdt: Ignoring memory range 0x8000 - 0x8020
[0.00] Linux version 5.1.0-rc7-1-g988141059a7b (build@localhost)
(gcc version 8.3.0 (Debian 8.3.0-7)) #1 SMP Fri May 3 16:36:57 CEST 2019
[0.00] initrd not found or empty - disabling initrd
[0.00] Zone ranges:
[0.00] DMA32[mem 0x8020-0xffff]
[0.00] Normal empty
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00] node 0: [mem 0x8020-0xffff]
[0.00] Initmem setup node 0 [mem 0x8020-0xffff]
[0.00] software IO TLB: mapped [mem 0xf3693000-0xf7693000] (64MB)
[0.00] elf_hwcap is 0x112d
[0.00] percpu: Embedded 17 pages/cpu s29592 r8192 d31848 u69632
[0.00] Built 1 zonelists, mobility grouping on. Total pages: 490759
[0.00] Kernel command line: console=ttyS0 rw root=/dev/vda1
[0.00] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
[0.00] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
[0.00] Sorting __ex_table...
[0.00] Memory: 1885148K/1990248K available (5585K kernel code, 353K
rwdata,
Re: [U-Boot] [PATCH] riscv: qemu: Use correct SYS_TEXT_BASE for S-mode on 32bit system
On Thu, Apr 11, 2019 at 06:52:12AM +, Anup Patel wrote: > For 32bit system, the OpenSBI (or BBL) will jump to 0x8040 address > in S-mode whereas for 64bit system it will jump to 0x8020 address > in S-mode. > > Currently, the S-mode U-Boot sets SYS_TEXT_BASE to 0x8020 for both > 32bit and 64bit system. This breaks S-mode U-Boot for 32bit system. > > This patch sets different SYS_TEXT_BASE for 32bit and 64bit system so > that S-mode U-Boot works fine for both. > > Signed-off-by: Anup Patel > --- > board/emulation/qemu-riscv/Kconfig | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/board/emulation/qemu-riscv/Kconfig > b/board/emulation/qemu-riscv/Kconfig > index cf057e7de6..20ea6dc59b 100644 > --- a/board/emulation/qemu-riscv/Kconfig > +++ b/board/emulation/qemu-riscv/Kconfig > @@ -14,7 +14,8 @@ config SYS_CONFIG_NAME > > config SYS_TEXT_BASE > default 0x8000 if !RISCV_SMODE > - default 0x8020 if RISCV_SMODE > + default 0x8020 if RISCV_SMODE && ARCH_RV64I > + default 0x8040 if RISCV_SMODE && ARCH_RV32I > > config BOARD_SPECIFIC_OPTIONS # dummy > def_bool y Hello Rick, may I kindly ping you regarding this patch (patchwork entry at http://patchwork.ozlabs.org/patch/1083725/)? It would be great if you could commit it soonish as without it the qemu RV32 target is currently non-functional. The patch has received two reviews and a tested-by and doesn't touch any generic code, so it should be safe to apply. Regards, Karsten -- Ich widerspreche hiermit ausdrücklich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] net: phy: Realtek RTL8211B/C PHY ID fix
The RTL8211B_driver structure in drivers/net/phy/realtek.c contains a
wrong PHY ID (0x1cc910 instead of 0x1cc912) in the uid field.
The lowest four bits of the PHY ID encode the chip revision (B+C/D/E/F)
of the RTL8211 and the code originally applied a mask of 0xf0 to
the PHY ID, so that matching the PHY ID to the appropriate driver code
was only done on the chip type (RTL8211), but not on a specific
revision.
After introduction of support for the RTL8211E, which needed another
startup function than the older chip revisions, commit
42205047674d7fc9e0aa747273fbc7dcfbac3183 changed the mask to 0xff
to make the chip revision relevant for the match, but didn't provide
the now-relevant lower bits of the uid field for the RTL8211B/C.
Fix this by setting the full PHY ID in the RTL8211B_driver uid field.
Fixes: 42205047674d ("net/phy: realtek: Fix the PHY ID mask to ensure the
correct Realtek PHY is detected")
Signed-off-by: Karsten Merker <mer...@debian.org>
---
drivers/net/phy/realtek.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index 259a87f..b8525dd 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -5,6 +5,7 @@
*
* Copyright 2010-2011, 2015 Freescale Semiconductor, Inc.
* author Andy Fleming
+ * Copyright 2016 Karsten Merker <mer...@debian.org>
*/
#include
#include
@@ -223,7 +224,7 @@ static int rtl8211f_startup(struct phy_device *phydev)
/* Support for RTL8211B PHY */
static struct phy_driver RTL8211B_driver = {
.name = "RealTek RTL8211B",
- .uid = 0x1cc910,
+ .uid = 0x1cc912,
.mask = 0xff,
.features = PHY_GBIT_FEATURES,
.config = _config,
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] booti: Help text rework.
Hello, while experimenting with the arm64 support I have stumbled over two small spelling issues in the "booti" help text: s/specifying the size of RAW initrd/specifying the size of a RAW initrd/ s/a Linux kernelrequires/a Linux kernel requires/ While editing the help text I have ended up with also slightly rewording it and adjusting the long description headline to match the short description similar to the the help texts for bootm and bootz. Patch following ;-). Regards, Karsten Karsten Merker (1): booti: Help text rework. cmd/bootm.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] booti: Help text rework.
Fix spelling errors in the "booti" help text and bring it more in line with the bootm/bootz help texts. Signed-off-by: Karsten Merker <mer...@debian.org> --- cmd/bootm.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/cmd/bootm.c b/cmd/bootm.c index 48738ac..555ccbc 100644 --- a/cmd/bootm.c +++ b/cmd/bootm.c @@ -755,15 +755,15 @@ int do_booti(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) #ifdef CONFIG_SYS_LONGHELP static char booti_help_text[] = "[addr [initrd[:size]] [fdt]]\n" - "- boot Linux Image stored in memory\n" + "- boot arm64 Linux Image stored in memory\n" "\tThe argument 'initrd' is optional and specifies the address\n" - "\tof the initrd in memory. The optional argument ':size' allows\n" - "\tspecifying the size of RAW initrd.\n" + "\tof an initrd in memory. The optional parameter ':size' allows\n" + "\tspecifying the size of a RAW initrd.\n" #if defined(CONFIG_OF_LIBFDT) - "\tSince booting a Linux kernelrequires a flat device-tree\n" - "\ta third argument is required which is the address of the\n" - "\tdevice-tree blob. To boot that kernel without an initrd image,\n" - "\tuse a '-' for the second argument.\n" + "\tSince booting a Linux kernel requires a flat device-tree, a\n" + "\tthird argument providing the address of the device-tree blob\n" + "\tis required. To boot a kernel with a device-tree blob but\n" + "\twithout an initrd image, use a '-' for the initrd argument.\n" #endif ""; #endif -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 0/2] sunxi: support for a second SD card socket
Hello, this patchset enables the full-size SD card socket on the A20-Olimex-SOM-EVB baseboard in u-boot and adds support for including this kind of secondary socket into the boot environment provided by config_distro_bootcmd.h on sunxi-based systems. The latter is particularly useful on the A20-Olimex-SOM-EVB as changing the card in the primary micro-SD socket is kind of fiddly when the SOM is plugged into the baseboard. Changes since V1: I had botched the patch generation for V1 so that the posted patch was incomplete. This is now the complete patch. Regards, Karsten Karsten Merker (2): sunxi: A20-Olimex-SOM-EVB defconfig: enable mmc3 sunxi: Enable a second mmc socket as boot target in the environment configs/A20-Olimex-SOM-EVB_defconfig | 3 +++ include/configs/sunxi-common.h | 7 +++ 2 files changed, 10 insertions(+) -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 2/2] sunxi: Enable a second mmc socket as boot target in the environment
Some sunxi-based boards (such as the Olimex A20-SOM-EVB) have a second MMC socket. This socket is not bootable hardware-wise, i.e. u-boot itself cannot be loaded from it, but once u-boot has started, the second socket can be used in the boot process provided by config_distro_bootcmd.h. If a second MMC socket is present, place it in the boot order after the first MMC socket. Signed-off-by: Karsten Merker <mer...@debian.org> --- include/configs/sunxi-common.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index 98a2c74..33f765c 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -418,8 +418,14 @@ extern int soft_i2c_gpio_scl; #ifdef CONFIG_MMC #define BOOT_TARGET_DEVICES_MMC(func) func(MMC, mmc, 0) +#if CONFIG_MMC_SUNXI_SLOT_EXTRA != -1 +#define BOOT_TARGET_DEVICES_MMC_EXTRA(func) func(MMC, mmc, 1) +#else +#define BOOT_TARGET_DEVICES_MMC_EXTRA(func) +#endif #else #define BOOT_TARGET_DEVICES_MMC(func) +#define BOOT_TARGET_DEVICES_MMC_EXTRA(func) #endif #ifdef CONFIG_AHCI @@ -447,6 +453,7 @@ extern int soft_i2c_gpio_scl; #define BOOT_TARGET_DEVICES(func) \ func(FEL, fel, na) \ BOOT_TARGET_DEVICES_MMC(func) \ + BOOT_TARGET_DEVICES_MMC_EXTRA(func) \ BOOT_TARGET_DEVICES_SCSI(func) \ BOOT_TARGET_DEVICES_USB(func) \ func(PXE, pxe, na) \ -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 1/2] sunxi: A20-Olimex-SOM-EVB defconfig: enable mmc3
The Olimex A20-SOM-EVB is an evaluation board for the Olimex A20-SOM system-on-module. The baseboard provides a full-size SD socket (connected to mmc3) in addition to the micro-SD socket on the SOM itself (which is connected to mmc0). Enable the mmc3 controller in the board defconfig. Signed-off-by: Karsten Merker <mer...@debian.org> --- configs/A20-Olimex-SOM-EVB_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configs/A20-Olimex-SOM-EVB_defconfig b/configs/A20-Olimex-SOM-EVB_defconfig index 5166c06..34b3f36 100644 --- a/configs/A20-Olimex-SOM-EVB_defconfig +++ b/configs/A20-Olimex-SOM-EVB_defconfig @@ -3,6 +3,9 @@ CONFIG_ARCH_SUNXI=y CONFIG_MACH_SUN7I=y CONFIG_DRAM_CLK=480 CONFIG_MMC0_CD_PIN="PH1" +CONFIG_MMC3_CD_PIN="PH0" +CONFIG_MMC3_PINS="PH" +CONFIG_MMC_SUNXI_SLOT_EXTRA=3 CONFIG_USB0_VBUS_PIN="PB9" CONFIG_USB0_VBUS_DET="PH5" CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-olimex-som-evb" -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2] sunxi: support for a second SD card socket
Hello, this patchset enables the full-size SD card socket on the A20-Olimex-SOM-EVB baseboard in u-boot and adds support for including this kind of secondary socket into the boot process provided by config_distro_bootcmd.h. The latter is particularly useful on the A20-Olimex-SOM-EVB as changing the card in the primary micro-SD socket is kind of fiddly when the SOM is plugged into the baseboard. Regards, Karsten Karsten Merker (2): sunxi: A20-Olimex-SOM-EVB defconfig: enable mmc3 sunxi: Enable a second mmc socket as boot target in the environment configs/A20-Olimex-SOM-EVB_defconfig | 3 +++ include/configs/sunxi-common.h | 6 ++ 2 files changed, 9 insertions(+) -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] sunxi: Enable a second mmc socket as boot target in the environment
Some sunxi-based boards (such as the Olimex A20-SOM-EVB) have a second MMC socket. This socket is not bootable hardware-wise, i.e. u-boot itself cannot be loaded from it, but once u-boot has started, the second socket can be used in the boot process provided by config_distro_bootcmd.h. If a second MMC socket is present, place it in the boot order after the first MMC socket. Signed-off-by: Karsten Merker <mer...@debian.org> --- include/configs/sunxi-common.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index 98a2c74..53ad6d2 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -418,6 +418,11 @@ extern int soft_i2c_gpio_scl; #ifdef CONFIG_MMC #define BOOT_TARGET_DEVICES_MMC(func) func(MMC, mmc, 0) +#if CONFIG_MMC_SUNXI_SLOT_EXTRA != -1 +#define BOOT_TARGET_DEVICES_MMC_EXTRA(func) func(MMC, mmc, 1) +#else +#define BOOT_TARGET_DEVICES_MMC_EXTRA(func) +#endif #else #define BOOT_TARGET_DEVICES_MMC(func) #endif @@ -447,6 +452,7 @@ extern int soft_i2c_gpio_scl; #define BOOT_TARGET_DEVICES(func) \ func(FEL, fel, na) \ BOOT_TARGET_DEVICES_MMC(func) \ + BOOT_TARGET_DEVICES_MMC_EXTRA(func) \ BOOT_TARGET_DEVICES_SCSI(func) \ BOOT_TARGET_DEVICES_USB(func) \ func(PXE, pxe, na) \ -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] sunxi: A20-Olimex-SOM-EVB defconfig: enable mmc3
The Olimex A20-SOM-EVB is an evaluation board for the Olimex A20-SOM system-on-module. The baseboard provides a full-size SD socket (connected to mmc3) in addition to the micro-SD socket on the SOM itself (which is connected to mmc0). Enable the mmc3 controller in the board defconfig. Signed-off-by: Karsten Merker <mer...@debian.org> --- configs/A20-Olimex-SOM-EVB_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configs/A20-Olimex-SOM-EVB_defconfig b/configs/A20-Olimex-SOM-EVB_defconfig index 5166c06..34b3f36 100644 --- a/configs/A20-Olimex-SOM-EVB_defconfig +++ b/configs/A20-Olimex-SOM-EVB_defconfig @@ -3,6 +3,9 @@ CONFIG_ARCH_SUNXI=y CONFIG_MACH_SUN7I=y CONFIG_DRAM_CLK=480 CONFIG_MMC0_CD_PIN="PH1" +CONFIG_MMC3_CD_PIN="PH0" +CONFIG_MMC3_PINS="PH" +CONFIG_MMC_SUNXI_SLOT_EXTRA=3 CONFIG_USB0_VBUS_PIN="PB9" CONFIG_USB0_VBUS_DET="PH5" CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-olimex-som-evb" -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] sunxi: Fix wrong pinmux names in arch/arm/cpu/armv7/sunxi/board.c
Commit 487b3277d4f70bcb2e4a1930beb6438565f25910 (sunxi: GPIO pin mux hardware-feature-specific function index defines) has removed and/or changed the names of various pinmux definitions, but has missed two instances in arch/arm/cpu/armv7/sunxi/board.c that still refer to the old-style names, which can now no longer be resolved. Use the new-style pinmux names instead. Signed-off-by: Karsten Merker mer...@debian.org --- arch/arm/cpu/armv7/sunxi/board.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm/cpu/armv7/sunxi/board.c b/arch/arm/cpu/armv7/sunxi/board.c index 0344362..1c26865 100644 --- a/arch/arm/cpu/armv7/sunxi/board.c +++ b/arch/arm/cpu/armv7/sunxi/board.c @@ -45,11 +45,11 @@ static int gpio_init(void) sunxi_gpio_set_cfgpin(SUNXI_GPB(23), SUNXI_GPIO_INPUT); #endif #if defined(CONFIG_MACH_SUN8I) - sunxi_gpio_set_cfgpin(SUNXI_GPF(2), SUN8I_GPF_UART0_TX); - sunxi_gpio_set_cfgpin(SUNXI_GPF(4), SUN8I_GPF_UART0_RX); + sunxi_gpio_set_cfgpin(SUNXI_GPF(2), SUN8I_GPF_UART0); + sunxi_gpio_set_cfgpin(SUNXI_GPF(4), SUN8I_GPF_UART0); #else - sunxi_gpio_set_cfgpin(SUNXI_GPF(2), SUNXI_GPF_UART0_TX); - sunxi_gpio_set_cfgpin(SUNXI_GPF(4), SUNXI_GPF_UART0_RX); + sunxi_gpio_set_cfgpin(SUNXI_GPF(2), SUNXI_GPF_UART0); + sunxi_gpio_set_cfgpin(SUNXI_GPF(4), SUNXI_GPF_UART0); #endif sunxi_gpio_set_pull(SUNXI_GPF(4), 1); #elif CONFIG_CONS_INDEX == 1 (defined(CONFIG_MACH_SUN4I) || defined(CONFIG_MACH_SUN7I)) -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] MSI_Primo81_defconfig: enable USB OTG port and keyboard support
The MSI Primo 81 is an Allwinner A31s-based tablet on which the OTG port is the only accessible USB interface. The existing defconfig had VGA console on the LCD enabled, but was missing keyboard support because the prerequisites for that (sunxi MUSB support and AXP221 GPIO support) had not been available before. All previously missing dependencies are available now, so this patch enables keyboard support and its prerequisites in the defconfig. Signed-off-by: Karsten Merker mer...@debian.org --- configs/MSI_Primo81_defconfig | 6 ++ 1 file changed, 6 insertions(+) diff --git a/configs/MSI_Primo81_defconfig b/configs/MSI_Primo81_defconfig index 83a95cb..8ae8c71 100644 --- a/configs/MSI_Primo81_defconfig +++ b/configs/MSI_Primo81_defconfig @@ -17,3 +17,9 @@ CONFIG_VIDEO_LCD_SPI_CS=PH9 CONFIG_VIDEO_LCD_SPI_SCLK=PH10 CONFIG_VIDEO_LCD_SPI_MOSI=PH11 CONFIG_VIDEO_LCD_SPI_MISO=PH12 +CONFIG_AXP_GPIO=y +CONFIG_DM_GPIO=y +CONFIG_USB0_VBUS_PIN=AXP0-VBUS-ENABLE +CONFIG_USB0_VBUS_DET=AXP0-VBUS-DETECT +CONFIG_USB_MUSB_SUNXI=y +CONFIG_USB_KEYBOARD=y -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Document the format of the console environment variable
config_distro_bootcmd.h defines a common boot environment for multiple platforms. Document the format of the console environment variable to allow the use of generic boot scripts on all supported platforms. Signed-off-by: Karsten Merker mer...@debian.org --- doc/README.distro |9 + 1 file changed, 9 insertions(+) diff --git a/doc/README.distro b/doc/README.distro index 0308a4c..3f7ee85 100644 --- a/doc/README.distro +++ b/doc/README.distro @@ -201,6 +201,15 @@ variables be set. Default values for these variables are often hard-coded into CONFIG_EXTRA_ENV_SETTINGS in the board's U-Boot configuration file, so that the user doesn't have to configure them. +console: + + Mandatory. The default console device to be passed to the Linux kernel. + + The console device is specified in accordance with the guidelines + described in Documentation/serial-console.txt in the Linux kernel sources. + If the device is a serial port, the console variable must specify the + console baudrate in addition to the console device, e.g. ttyS0,115200. + fdt_addr: Mandatory for any system that provides the DTB in HW (e.g. ROM) and wishes -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] Document config_distro_bootcmd environment variables for interactive booting.
Changes since V1: - Explicitly define the target format for storage and network targets - Include a list of all valid bootcmd targets which are currently supported - Make the commit log more verbose Karsten Merker (1): Document config_distro_bootcmd environment variables for interactive booting. doc/README.distro | 47 +++ 1 file changed, 47 insertions(+) -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] Document config_distro_bootcmd environment variables for interactive booting.
config_distro_bootcmd.h defines a common boot environment for multiple platforms, including several environment variables that are intended for interactive use by an end-user. Document which variables are considered public interfaces that must remain compatible in future u-boot versions. Signed-off-by: Karsten Merker mer...@debian.org --- doc/README.distro | 47 +++ 1 file changed, 47 insertions(+) diff --git a/doc/README.distro b/doc/README.distro index dd0f1c7..0308a4c 100644 --- a/doc/README.distro +++ b/doc/README.distro @@ -1,6 +1,7 @@ /* * (C) Copyright 2014 Red Hat Inc. * Copyright (c) 2014-2015, NVIDIA CORPORATION. All rights reserved. + * Copyright (C) 2015 K. Merker mer...@debian.org * * SPDX-License-Identifier: GPL-2.0+ */ @@ -339,3 +340,49 @@ scan_dev_for_scripts: If you want to disable boot.scr on all disks, set the value to something innocuous, e.g. setenv scan_dev_for_scripts true. + + +Interactively booting from a specific device at the u-boot prompt += + +For interactively booting from a user-selected device at the u-boot command +prompt, the environment provides predefined bootcmd_target variables for +every target defined in boot_targets, which can be run be the user. + +If the target is a storage device, the format of the target is always +device typedevice number, e.g. mmc0. Specifying the device number is +mandatory for storage devices, even if only support for a single instance +of the storage device is actually implemented. + +For network targets (dhcp, pxe), only the device type gets specified; +they do not have a device number. + +Examples: + + - run bootcmd_usb0 + boots from the first USB mass storage device + + - run bootcmd_mmc1 + boots from the second MMC device + + - run bootcmd_pxe + boots by tftp using a pxelinux.cfg + +The list of possible targets consists of: + +- network targets + * dhcp + * pxe + +- storage targets (to which a device number must be appended) + * mmc + * sata + * scsi + * ide + * usb + +Other *boot* variables than the ones defined above are only for internal use +of the boot environment and are not guaranteed to exist or work in the same +way in future u-boot versions. In particular the device type_boot +variables (e.g. mmc_boot, usb_boot) are a strictly internal implementation +detail and must not be used as a public interface. -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Document config_distro_bootcmd environment variables for interactive booting.
Signed-off-by: Karsten Merker mer...@debian.org --- doc/README.distro | 17 + 1 file changed, 17 insertions(+) diff --git a/doc/README.distro b/doc/README.distro index dd0f1c7..5150eda 100644 --- a/doc/README.distro +++ b/doc/README.distro @@ -1,6 +1,7 @@ /* * (C) Copyright 2014 Red Hat Inc. * Copyright (c) 2014-2015, NVIDIA CORPORATION. All rights reserved. + * Copyright (c) 2015 K. Merker mer...@debian.org * * SPDX-License-Identifier: GPL-2.0+ */ @@ -339,3 +340,19 @@ scan_dev_for_scripts: If you want to disable boot.scr on all disks, set the value to something innocuous, e.g. setenv scan_dev_for_scripts true. + + +Interactively booting from a specific device at the u-boot prompt += + +For interactively booting from a user-selected device at the u-boot command +prompt, the environment provides predefined bootcmd_target variables for +every target defined in boot_targets, which can be run be the user. + +Examples: + + - run bootcmd_usb0 + boots from the first USB mass storage device + + - run bootcmd_mmc1 + boots from the second MMC device -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] config_distro_bootcmd and boot environment (was: Regression in bootcmd handling in v2015.04-rc3?)
Tom Rini tr...@konsulko.com wrote: So then we're settled on run bootcmd_usb was unintended but run bootcmd_usb0 is and must remain so if anything a slight update to doc/README.distro would be expected and we're good, right? Thanks guys! Following is a patch to add such a description to doc/README.distro. Regards, Karsten Karsten Merker (1): Document config_distro_bootcmd environment variables for interactive booting. doc/README.distro | 17 + 1 file changed, 17 insertions(+) -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [sunxi] [RFC/RFH] Adding mainline u-boot support for the Olimex A20-SOM-EVB
Hello, I am working on adding support for the Olimex A20-SOM-EVB development board to mainline u-boot (and to the mainline Linux kernel, but that is a topic for a different thread). The board package actually consists of two parts, the A20-SOM-EVB baseboard providing I/O and power supply, and the A20-SOM CPU/memory board that gets plugged onto the baseboard. The schematics for the boards are available online: - A20-SOM CPU module: https://github.com/OLIMEX/SOM/blob/master/A20/A20-SOM/A20-SOM_board_rev_D.pdf?raw=true - A20-SOM-EVB baseboard: https://www.olimex.com/Products/SOM/A20/A20-SOM-EVB/resources/A20-SOM-EVB_schematic.pdf I use the following defconfig with the master branch of git://git.denx.de/u-boot-sunxi.git, but I currently cannot get it to work fully as intended and would appreciate any advice. configs/Olimex-A20-SOM-EVB_defconfig: = CONFIG_SPL=y CONFIG_SYS_EXTRA_OPTIONS=AXP209_POWER,SUNXI_GMAC,RGMII,AHCI,SATAPWR=SUNXI_GPC(3),USB_EHCI CONFIG_FDTFILE=sun7i-a20-olimex-a20-som-evb.dtb CONFIG_MMC0_CD_PIN=PH1 CONFIG_USB1_VBUS_PIN=PH6 CONFIG_USB2_VBUS_PIN=PH3 +S:CONFIG_ARM=y +S:CONFIG_ARCH_SUNXI=y +S:CONFIG_MACH_SUN7I=y +S:CONFIG_DRAM_CLK=384 +S:CONFIG_DRAM_ZQ=127 +S:CONFIG_DRAM_EMR1=4 I try to start u-boot via FEL, as the Micro-SD slot on the A20-SOM is very difficult to reach (even using pliers) when it is plugged onto the baseboard, and having to change SD cards all the time while testing is really cumbersome. The first problem showing up is that starting u-boot via FEL in the traditional style (using a FEL-specific build) does not work. The SPL gets transferred properly and the fel exe command that starts the SPL returns without error, although I get no output on the serial console. Trying to transfer the main u-boot image afterwards fails: $ make distclean $ make Olimex-A20-SOM-EVB_felconfig [...] $ make -j3 [...] $ fel version AWUSBFEX soc=1651(A20) 0001 ver=0001 44 08 scratchpad=7e00 $ fel write 0x2000 spl/u-boot-spl.bin $ fel exe 0x2000 [wait a few seconds for DRAM init] $ fel write 0x4a00 u-boot.bin [takes some time] libusb usb_bulk_send error -7 I have no idea how to further debug this. My first thought was that my DRAM parameters (based on data from a manufacturer-supplied FEX file for the board) are wrong, so that I run into problems while writing the main u-boot image to DRAM, but this is probably not the reason - see below. Running Siarhei's new fel spl command (using a normal non-FEL u-boot build) succeeds in transferring and starting the SPL, which then - with a build from git://git.denx.de/u-boot-sunxi.git - either complains that it cannot do the SD card voltage select when no card is inserted: U-Boot SPL 2015.01-03533-gdb62a4a (Feb 12 2015 - 20:04:29) DRAM: 1024 MiB CPU: 96000Hz, AXI/AHB/APB: 3/2/2 Card did not respond to voltage select! spl: mmc init failed: err - -17 ### ERROR ### Please RESET the board ### or boots straight into the old u-boot-sunxi that I have on the card: U-Boot SPL 2015.01-03533-gdb62a4a (Feb 12 2015 - 20:04:29) DRAM: 1024 MiB CPU: 96000Hz, AXI/AHB/APB: 3/2/2 U-Boot 2014.04-10733-gea1ac32 (Feb 08 2015 - 20:04:39) Allwinner Technology CPU: Allwinner A20 (SUN7I) Board: Olimex_A20-SOM I2C: ready DRAM: 1 GiB MMC: SUNXI SD/MMC: 0 *** Warning - bad CRC, using default environment In this case the SPL does not know that it is booted via FEL, so it tries to load the main u-boot binary from the SD card. The fact that chainloading the (old) u-boot from the SD card works, shows me that the DRAM is working, so I suppose that my DRAM parameters are probably not the reason why the old-style FEL booting does not work. When using a u-boot build from the 20150208-fel-fixes branch of Siarhei's repository at https://github.com/ssvb/u-boot-sunxi.git (plus Hans' config_distro_bootcmd fix from http://lists.denx.de/pipermail/u-boot/2015-February/204286.html) as follows: $ make distclean [...] $ make Olimex-A20-SOM-EVB_defconfig [...] $ make -j3 [...] $ fel version AWUSBFEX soc=1651(A20) 0001 ver=0001 44 08 scratchpad=7e00 $ fel spl u-boot-sunxi-with-spl.bin $ fel write 0x4a00 u-boot.bin $ fel exe 0x4a00 $ u-boot boots fine until it tries to initialize the EHCI controllers: U-Boot SPL 2015.04-rc1-04039-g6385323 (Feb 12 2015 - 21:08:28) DRAM: 1024 MiB CPU: 96000Hz, AXI/AHB/APB: 3/2/2 U-Boot 2015.04-rc1-04039-g6385323 (Feb 12 2015 - 21:08:28) Allwinner Technology CPU: Allwinner A20 (SUN7I) I2C: ready DRAM: 1 GiB MMC: SUNXI SD/MMC: 0 *** Warning - bad CRC, using default environment In:serial Out: serial Err: serial SCSI: SUNXI SCSI INIT SATA link 0 timeout. AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode flags: ncq stag pm led clo only pmp pio slum part ccc apst Net: dwmac.1c5 starting USB... USB0: Then u-boot hangs. The problem appears to be with the GPIO pins that control the USB voltage
Re: [U-Boot] [PATCH fix for v2014.10 0/1] sunxi: Fix gmac not working reliable on the Bananapi
On Tue, Sep 30, 2014 at 06:45:31PM +0200, Hans de Goede wrote: Hi Tom, Here is a last minute sunxi bug-fix for v2014.10, which fixes the ethernet on the bananapi being unusable. Ian and I (the sunxi custodians) would like to see this included in v2014.10, can you please apply it to master before the release ? Hello, as the planned release date of u-boot v2014.10 is just one week away, may I ping you on this issue? Kind regards, Karsten -- Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC/PATCH] sunxi: Populate the default environment for sunxi-based systems
Hello, in the following email you can find a patch to populate the default environment for sunxi-based systems about which I would apprechiate your opinion. With the current progress in mainlining sunxi platform support, mainline u-boot will probably soon be able to replace u-boot-sunxi (https://github.com/linux-sunxi/u-boot-sunxi) for many use cases. Currently the default environment in mainline u-boot for sunxi-based systems is rather bare; the only predefined variable is bootm_size (which is required for proper initrd- and dtb-relocation). U-boot-sunxi predefines a set of environment variables which are commonly used by existing boot scripts and also offers a predefined bootcmd for automatic search and execution of bootscripts. I think that to facilitate using mainline u-boot as a drop-in replacement for u-boot-sunxi, mainline u-boot should provide similar defaults. The original environment in u-boot-sunxi was written for an older u-boot release and does not make use of modern u-boot features (e.g. it uses hardcoded filesystem-specific load commands), so just copying the environment 1:1 to mainline u-boot does not make sense IMHO. My patch tries to implement the minimum required for autobooting existing boot scripts with more modern u-boot functions. In addition to that, the patch defines some standard environment variables which are commonly defined on other u-boot platforms, but which have not been defined by u-boot-sunxi, in particular kernel_addr_r, ramdisk_addr_r and fdt_addr_r. Debian supports a wide range of armhf system and tries to unify support for the different platforms as good as possible. Having the same predefined variables with (platform-specific) load addresses on all platforms would help us a lot with regard to generic boot scripts and simplified user documentation. Regarding the actual values for the various load addresses I am not in all cases perfectly sure about the best variant. Following is the reasoning for my choices: - fdt_addr_r U-boot-sunxi loads the FEX binary (Allwinner's proprietary hardware description format for their android kernels, i.e. a file functionally roughly equivalent to a dtb) to address 0x4300, so I guess using the same for the dtb makes sense. - scriptaddr has historically been expected to be 0x4400; some old boot scripts assume this address. - kernel_addr_r and ramdisk_addr_r Allwinner has historically loaded their kernels to 0x4800 (system specific kernels with all drivers compiled in, no initrd). Debian has been using 0x4600 for the kernel and 0x4800 for the initrd. These values work well in practice, so I have used them in the patch, but if there are reasons to change them, I am happy to do so. Comments welcome :-). Regards, Karsten -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC/PATCH 1/1] sunxi: Populate the default environment for sunxi-based systems
Predefine a set of standard environment variables (kernel_addr_r,
ramdisk_addr_r, fdt_addr_r and scriptaddr) to sensible values on
sunxi-based systems and provide a default environment that allows
autobooting of existing boot scripts which were written for
pre-mainlining u-boot-sunxi versions.
Signed-off-by: Karsten Merker mer...@debian.org
---
include/configs/sunxi-common.h | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 6a3044f..ac8cb8f 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -124,7 +124,17 @@
#define CONFIG_ENV_SIZE(128 10) /* 128 KiB */
#define CONFIG_EXTRA_ENV_SETTINGS \
- bootm_size=0x1000\0
+ bootm_size=0x1000\0 \
+ fdt_addr_r=0x4300\0 \
+ scriptaddr=0x4400\0 \
+ kernel_addr_r=0x4600\0 \
+ ramdisk_addr_r=0x4800\0 \
+ device=mmc\0 \
+ partition=0:1\0 \
+ bootdelay=3\0 \
+ bootcmd=if test -n \${loadbootscr}\; then run loadbootscr; fi\0 \
+ bootscr=boot.scr\0 \
+ loadbootscr=if test -n \${device}\ test -n \${partition}\; then
for p in /boot/ /; do load ${device} ${partition} ${scriptaddr} ${p}${bootscr}
echo \Running ${p}${bootscr} from ${device} ${partition}\ source
${scriptaddr}; done; fi\0
#define CONFIG_SYS_BOOT_GET_CMDLINE
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC/PATCH] sunxi: Populate the default environment for sunxi-based systems
On Mon, Aug 11, 2014 at 06:22:09PM +0200, Hans de Goede wrote:
On 08/10/2014 11:00 PM, Karsten Merker wrote:
Hello,
in the following email you can find a patch to populate the
default environment for sunxi-based systems about which I would
apprechiate your opinion.
With the current progress in mainlining sunxi platform support,
mainline u-boot will probably soon be able to replace
u-boot-sunxi (https://github.com/linux-sunxi/u-boot-sunxi) for
many use cases. Currently the default environment in mainline
u-boot for sunxi-based systems is rather bare; the only
predefined variable is bootm_size (which is required for proper
initrd- and dtb-relocation). U-boot-sunxi predefines a set of
environment variables which are commonly used by existing boot
scripts and also offers a predefined bootcmd for automatic search
and execution of bootscripts. I think that to facilitate using
mainline u-boot as a drop-in replacement for u-boot-sunxi,
mainline u-boot should provide similar defaults.
[...]
Thanks for this patch, but this does the same as a series
I've already pending, see:
https://github.com/jwrdegoede/u-boot-sunxi/commits/next
Sorry, I had not seen that - in this case please disregard
my patch.
I've not yet send a pull-request for this because it uses the new
generic $bootcmd support:
https://github.com/jwrdegoede/u-boot-sunxi/commit/34e421a155c83c52f6e6edb2594458af27ef7517
This commit has just been merged by Tom Rini, so right now
these patches are good to go. I'll send a pull-request for them
soon.
Let me know if somehow these patches won't work for Debian. One of the
goals of the generic $bootcmd support is that distributions can just
drop an extlinux.conf in the boot partition, and then u-boot will
automatically find it and do the right thing.
I have just run a few short tests with them - looks good. Using
the new infrastructure requires adjustments to existing
bootscripts written for u-boot-sunxi due to different variable
names (${devtype} vs. ${device}, ${devnum}:${bootpart} vs.
${partition}), so it is not a real drop-in replacement for
u-boot-sunxi, but if it gets adopted by all platforms, I think
having a common and versatile infrastructure for all of them is
worth breaking compatibility to u-boot-sunxi in this regard.
Regards,
Karsten
--
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
