June 2023 - U-Boot

[PATCH] usb: eth: lan78xx: Fix logic in lan78xx_read_otp() to avoid a warning
by Tom Rini 20 Jun '23

20 Jun '23

In lan78xx_read_otp() we want to know if sig is LAN78XX_OTP_INDICATOR_1 or LAN78XX_OTP_INDICATOR_2. In the case of matching the first one we set offset to itself, and clang warns about this. Rework the logic so that if sig is the second indicator we adjust the offset as today and if it does not match the first indicator we return -EINVAL Cc: Marek Vasut <marex(a)denx.de> Signed-off-by: Tom Rini <trini(a)konsulko.com> --- drivers/usb/eth/lan78xx.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/usb/eth/lan78xx.c b/drivers/usb/eth/lan78xx.c index e34ad2603fbb..d147412990de 100644 --- a/drivers/usb/eth/lan78xx.c +++ b/drivers/usb/eth/lan78xx.c @@ -146,11 +146,9 @@ static int lan78xx_read_otp(struct usb_device *udev, u32 offset, ret = lan78xx_read_raw_otp(udev, 0, 1, &sig); if (!ret) { - if (sig == LAN78XX_OTP_INDICATOR_1) - offset = offset; - else if (sig == LAN78XX_OTP_INDICATOR_2) + if (sig == LAN78XX_OTP_INDICATOR_2) offset += 0x100; - else + else if (sig != LAN78XX_OTP_INDICATOR_1) return -EINVAL; ret = lan78xx_read_raw_otp(udev, offset, length, data); if (ret) -- 2.17.1

2 2

[PATCH] spl: spl-nor: return error if no valid image was loaded
by Mario Kicherer 20 Jun '23

20 Jun '23

If only FIT images are enabled and loading the FIT image fails, spl_nor_load_image() should return an error instead of zero. Without this patch: >>SPL: board_init_r() spl_init Trying to boot from NOR Unsupported OS image.. Jumping nevertheless.. image entry point: 0x0 With patch: >>SPL: board_init_r() spl_init Trying to boot from NOR SPL: failed to boot from all boot devices (err=-6) .### ERROR ### Please RESET the board ### Signed-off-by: Mario Kicherer <dev(a)kicherer.org> --- common/spl/spl_nor.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/spl/spl_nor.c b/common/spl/spl_nor.c index ffb3566d89..e75127b275 100644 --- a/common/spl/spl_nor.c +++ b/common/spl/spl_nor.c @@ -120,6 +120,6 @@ static int spl_nor_load_image(struct spl_image_info *spl_image, &hdr); } - return 0; + return -EINVAL; } SPL_LOAD_IMAGE_METHOD("NOR", 0, BOOT_DEVICE_NOR, spl_nor_load_image); -- 2.34.1

2 1

[PATCH 0/3] iot2050: Re-unify its configs and build processes
by Jan Kiszka 20 Jun '23

20 Jun '23

This restores the possibility to build firmware images for both PG1 and PG2-based IOT2050 devices in one run. We still end up with different binaries, but the the build is now fed again from a single defconfig. Should simplify maintenance and will also simplify our generation tooling around it. Jan CC: Simon Glass <sjg(a)chromium.org> Jan Kiszka (3): binman: Allow to define custom arguments iot2050: Use binman in signing script boards: siemens: iot2050: Unify PG1 and PG2/M.2 configurations again Makefile | 1 + arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 299 ++++++++++-------- board/siemens/iot2050/Kconfig | 30 +- board/siemens/iot2050/board.c | 14 +- board/siemens/iot2050/config.mk | 6 +- ...ot2050_pg1_defconfig => iot2050_defconfig} | 3 +- configs/iot2050_pg2_defconfig | 150 --------- doc/board/siemens/iot2050.rst | 29 +- tools/iot2050-sign-fw.sh | 13 +- 9 files changed, 203 insertions(+), 342 deletions(-) rename configs/{iot2050_pg1_defconfig => iot2050_defconfig} (97%) delete mode 100644 configs/iot2050_pg2_defconfig -- 2.35.3

2 24

[PATCH 1/3] arm: dts: imx8mm: move firmware/optee node to common imx8mm-u-boot.dtsi
by Tim Harvey 20 Jun '23

20 Jun '23

Move the firmware/optee node to the common imx8mm-u-boot.dtsi and protect it with an ifdef CONFIG_OPTEE as it is a meaningless node without the optee driver enabled. Signed-off-by: Tim Harvey <tharvey(a)gateworks.com> --- arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi | 7 ------- arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi | 7 ------- arch/arm/dts/imx8mm-evk-u-boot.dtsi | 7 ------- arch/arm/dts/imx8mm-kontron-bl-common-u-boot.dtsi | 7 ------- arch/arm/dts/imx8mm-phg-u-boot.dtsi | 7 ------- arch/arm/dts/imx8mm-u-boot.dtsi | 9 +++++++++ arch/arm/dts/imx8mm-verdin-wifi-dev-u-boot.dtsi | 7 ------- 7 files changed, 9 insertions(+), 42 deletions(-) diff --git a/arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi b/arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi index 484e31824b85..d12ce6069cc7 100644 --- a/arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi +++ b/arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi @@ -6,13 +6,6 @@ #include "imx8mm-u-boot.dtsi" / { - firmware { - optee { - compatible = "linaro,optee-tz"; - method = "smc"; - }; - }; - wdt-reboot { compatible = "wdt-reboot"; bootph-pre-ram; diff --git a/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi b/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi index 1878c4e13fbe..219504f61105 100644 --- a/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi +++ b/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi @@ -6,13 +6,6 @@ #include "imx8mm-u-boot.dtsi" / { - firmware { - optee { - compatible = "linaro,optee-tz"; - method = "smc"; - }; - }; - wdt-reboot { compatible = "wdt-reboot"; bootph-pre-ram; diff --git a/arch/arm/dts/imx8mm-evk-u-boot.dtsi b/arch/arm/dts/imx8mm-evk-u-boot.dtsi index 13688ec0d0f2..155670da18d1 100644 --- a/arch/arm/dts/imx8mm-evk-u-boot.dtsi +++ b/arch/arm/dts/imx8mm-evk-u-boot.dtsi @@ -11,13 +11,6 @@ wdt = <&wdog1>; bootph-pre-ram; }; - - firmware { - optee { - compatible = "linaro,optee-tz"; - method = "smc"; - }; - }; }; &aips4 { diff --git a/arch/arm/dts/imx8mm-kontron-bl-common-u-boot.dtsi b/arch/arm/dts/imx8mm-kontron-bl-common-u-boot.dtsi index 65dfd33725ee..1ad9d49a1118 100644 --- a/arch/arm/dts/imx8mm-kontron-bl-common-u-boot.dtsi +++ b/arch/arm/dts/imx8mm-kontron-bl-common-u-boot.dtsi @@ -16,13 +16,6 @@ wdt = <&wdog1>; bootph-pre-ram; }; - - firmware { - optee { - compatible = "linaro,optee-tz"; - method = "smc"; - }; - }; }; &crypto { diff --git a/arch/arm/dts/imx8mm-phg-u-boot.dtsi b/arch/arm/dts/imx8mm-phg-u-boot.dtsi index 3ced97cfaafa..c9e0b4420500 100644 --- a/arch/arm/dts/imx8mm-phg-u-boot.dtsi +++ b/arch/arm/dts/imx8mm-phg-u-boot.dtsi @@ -11,13 +11,6 @@ wdt = <&wdog1>; bootph-pre-ram; }; - - firmware { - optee { - compatible = "linaro,optee-tz"; - method = "smc"; - }; - }; }; &aips4 { diff --git a/arch/arm/dts/imx8mm-u-boot.dtsi b/arch/arm/dts/imx8mm-u-boot.dtsi index 7fd5a05fad3c..c48b5f2ef026 100644 --- a/arch/arm/dts/imx8mm-u-boot.dtsi +++ b/arch/arm/dts/imx8mm-u-boot.dtsi @@ -7,6 +7,15 @@ binman: binman { multiple-images; }; + +#ifdef CONFIG_OPTEE + firmware { + optee { + compatible = "linaro,optee-tz"; + method = "smc"; + }; + }; +#endif }; &soc { diff --git a/arch/arm/dts/imx8mm-verdin-wifi-dev-u-boot.dtsi b/arch/arm/dts/imx8mm-verdin-wifi-dev-u-boot.dtsi index 494229e4e62a..f2c7bd919970 100644 --- a/arch/arm/dts/imx8mm-verdin-wifi-dev-u-boot.dtsi +++ b/arch/arm/dts/imx8mm-verdin-wifi-dev-u-boot.dtsi @@ -6,13 +6,6 @@ #include "imx8mm-u-boot.dtsi" / { - firmware { - optee { - compatible = "linaro,optee-tz"; - method = "smc"; - }; - }; - wdt-reboot { compatible = "wdt-reboot"; bootph-pre-ram; -- 2.25.1

2 5

[PATCH] spl: spl_nor: use panic instead of hang if booting fails
by Mario Kicherer 20 Jun '23

20 Jun '23

On systems without a watchdog, using hang() prevents a system to recover from an error. For example, a board could implement a boot counter to switch to an alternative load address after some failed tries. Signed-off-by: Mario Kicherer <dev(a)kicherer.org> --- common/spl/spl.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/common/spl/spl.c b/common/spl/spl.c index 2855cdd117..d1aa2fb8a9 100644 --- a/common/spl/spl.c +++ b/common/spl/spl.c @@ -822,11 +822,10 @@ void board_init_r(gd_t *dummy1, ulong dummy2) if (ret) { if (CONFIG_IS_ENABLED(SHOW_ERRORS) && CONFIG_IS_ENABLED(LIBCOMMON_SUPPORT)) - printf(SPL_TPL_PROMPT "failed to boot from all boot devices (err=%d)\n", - ret); + panic(SPL_TPL_PROMPT "failed to boot from all boot devices (err=%d)\n", + ret); else - puts(SPL_TPL_PROMPT "failed to boot from all boot devices\n"); - hang(); + panic_str(SPL_TPL_PROMPT "failed to boot from all boot devices\n"); } spl_perform_fixups(&spl_image); -- 2.34.1

2 1

[PATCH] Add Renesas patch attribution domain mapping
by Marek Vasut 20 Jun '23

20 Jun '23

Add domain mapping for the +renesas mail, so that the patches get attributed to to Renesas Electronics correctly. Signed-off-by: Marek Vasut <marek.vasut+renesas(a)mailbox.org> --- u-boot-config/domain-map | 3 +++ 1 file changed, 3 insertions(+) diff --git a/u-boot-config/domain-map b/u-boot-config/domain-map index f64147e..478696f 100644 --- a/u-boot-config/domain-map +++ b/u-boot-config/domain-map @@ -536,3 +536,6 @@ sjg(a)chromium.org Google, Inc. # Louis Yung-Chieh Lo <yjlou(a)chromium.org> # yjlou(a)google.com Google, Inc. + +# Marek Vasut +marek.vasut+renesas(a)mailbox.org Renesas Electronics -- 2.39.2

2 1

Re: [SPAM] Re: [PATCH] cmd: usb: Prevent reset in usb tree/info command
by Xavier Drudis Ferran 20 Jun '23

20 Jun '23

Sorry, I replied to Marek only but meant to reply to all. El Fri, Jun 09, 2023 at 03:20:33AM +0200, Marek Vasut deia: > > No. Well, in some tests yes and some no, but I got the error in all cases. > > This is doubtful. It is mandatory to run 'usb start' or 'usb reset' before > you would get any meaningful result out of 'usb info'. Without either, you > would get 'USB is stopped.' message. Could it be there are some extra > scripts in your environment that manipulate the USB ? > I saw usb_boootdev_hunt() calls usb_init() in drivers/usb/host/usb_bootdev.c But maybe I don't get that called and it's really something silly in my setup as you say later... Maybe it doesn't get called unless it finds nothing else useful to boot. > > Can you test with stock U-Boot ? > I don't know. I'll see if I have time ... I'd rather read the code to understand what's the condition for finding bootdevices... > Can you test with another USB stick, i.e. is the issue specific to this USB > stick ? > I could test this, yes. > Is the issue specific to this partition layout of this USB stick, i.e. if > you clone (dd if=... of=...) the content of the USB stick to another USB > stick, does the error still occur. > I'll try to partition and flash a new USB. > [...] > > > Model: Radxa ROCK Pi 4B > > Net: eth0: ethernet@fe300000 > > Hit any key to stop autoboot: 2 1 0 > > rockchip_pcie pcie@f8000000: PCIe link training gen1 timeout! > > Bus usb@fe380000: USB EHCI 1.00 > > Bus usb@fe3c0000: USB EHCI 1.00 > > Bus usb@fe800000: Register 2000140 NbrPorts 2 > > Starting the controller > > USB XHCI 1.10 > > Bus usb@fe900000: Register 2000140 NbrPorts 2 > > Starting the controller > > USB XHCI 1.10 > > scanning bus usb@fe380000 for devices... 1 USB Device(s) found > > scanning bus usb@fe3c0000 for devices... 2 USB Device(s) found > > scanning bus usb@fe800000 for devices... 1 USB Device(s) found > > scanning bus usb@fe900000 for devices... 1 USB Device(s) found > > rockchip_pcie pcie@f8000000: failed to find ep-gpios property > > ethernet@fe300000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! > > Could not initialize PHY ethernet@fe300000 > > rockchip_pcie pcie@f8000000: failed to find ep-gpios property > > ethernet@fe300000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! > > Could not initialize PHY ethernet@fe300000 > > Is this some $preboot script which initializes your hardware ? > Mmm... yes, I used to have it... I thought not in this test, but I'd better recheck Anyway, one should be allowed to stop the boot, call usb start and usb tree and don't get a reset, shouldn't one? > => printenv preboot > I'll send this later when I repeat the test. I'd like to find a minimal test case or something... > > => usb tree > > USB device tree: > > 1 Hub (480 Mb/s, 0mA) > > u-boot EHCI Host Controller > > 1 Hub (480 Mb/s, 0mA) > > | u-boot EHCI Host Controller > > | > > uclass_id=64 > > |+-2 Mass Storage (480 Mb/s, 200mA) > > TDK LoR TF10 07032B6B1D0ACB96 > > uclass_id=22 > > uclass_id=25 > > "Synchronous Abort" handler, esr 0x96000010, far 0x948 > > elr: 00000000002157d4 lr : 00000000002157d4 (reloc) > > elr: 00000000f3f4f7d4 lr : 00000000f3f4f7d4 > > Take the u-boot (unstripped elf) which matches this binary, and run > aarch64-...objdump -lSD on it, then search for the $lr value, see > doc/develop/crash_dumps.rst for details. That should tell you where exactly > the crash occurred. Where did it occur ? > I didn't do it exactly so, but from u-boot.map I gathered that it was in cmd/usb.c and the fact that my patch fixed it implies the problem is the functions usb_show_tree_graph() or usb_show_info() get called recursively with null as a first parameter. Now I don't have that u-boot.map anymore and would have to repeat the experiment, to find out exactly as you say, so I won't do it right now. But thanks, understood. The reason usb_show_tree_graph() gets called with a null usb_device * is that the code in cmd/usb.c for usb info and usb tree assumes everything a UCLASS_MASS_STORAGE device can have as children are devices with some usb_device in their dev_get_parent_priv(). It carves out exceptions to this general rule for UCLASS_USB_EMUL and UCLASS_BLK, but not for UCLASS_BOOTDEV. When it finds a child that is UCLASS_BOOTDEV it happily recurses on it passing its parent_priv as usb_device, but the bootdev code did not put any usb_device there, it's null. So the first access causes a null pointer dereference. I would have to wrap my mind around more code to start understanding if it's better to give that UCLASS_BOOTDEV some usb_device as parent priv data, or it is better to give USB devices that can be enumerated for listing (usb tree or usb info) some RECURSIBLE flag that indicates their priv parent data is reliably a usb_device. So checking that the alledged usb_device at least isn't null as in my patch is possibly a partial solution. I'm sure if it's null we shouldn't call, but if it points to something other than a usb_device we shouldn't either, and it doesn't address why it is null (well, because it's not really a USB internal node, not even a proper leaf, so it shouldn't be recursed anyway). In usb_show_info() it is similar, usb_display_desc() gets called with a null udev because that's what came in. Recursion is avoided for UCLASS_USB_EMUL or UCLASS_BLK but not for UCLASS_BOOTDEV. A different solution could be to expand the exception to UCLASS_BOOTDEV, but it still seems a wrong strategy to expect to know everything you can find so you can list all the exceptions, instead of checking that you have something expected that you can recurse on. Not completely sure, just smells so to me. At least checking for null is more general. Maybe the solution is to fix common/usb_storage.c when it calls bootdev_setup_sibling_blk(), to ensure there's some useful usb_device there as parent priv. Or something needs fixing in drivers/usb/host/usb_bootdev.c ??? But I'm not sure. We really shouldn't call recursively for usb info or tree anyway. For now I was trying to understand when that UCLASS_BOOTDEV is added and why, and whether it should be removed at some time. This should hint me at what is the minimum scenario to reproduce the issue. > > The NAK is really only to prevent this from accidentally going on. > The NAK it's OK. I like people to want to understand stuff. Don't worry. > Please see above, maybe it could be narrowed down ? I'll see if I can test better and send more useful reports. Not sure when. I'm not sure I'll have the time to learn all I need. I just hoped someone else had it in mind...

3 14

[PATCH] board_f: Relocate fdt if SKIP_RELOC and fdt is in bss
by Kunihiko Hayashi 20 Jun '23

20 Jun '23

There are cases that the devicetree blob is placed after _end, such as fdt_find_separate() returns _end. This is in bss area cleared before relocation. When GD_FLG_SKIP_RELOC is set, the blob is still in bss, but will be cleared. As a result, the devicetree become invalid. To avoid this issue, should relocate it to the new fdt area using the latter condition in reloc_fdt(). Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko(a)socionext.com> --- common/board_f.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/common/board_f.c b/common/board_f.c index 51d2f3c365e9..9a245872d190 100644 --- a/common/board_f.c +++ b/common/board_f.c @@ -622,7 +622,8 @@ static int init_post(void) static int reloc_fdt(void) { if (!IS_ENABLED(CONFIG_OF_EMBED)) { - if (gd->flags & GD_FLG_SKIP_RELOC) + if (gd->flags & GD_FLG_SKIP_RELOC && + gd->fdt_blob != &_end) return 0; if (gd->new_fdt) { memcpy(gd->new_fdt, gd->fdt_blob, -- 2.25.1

2 4

[PATCH] mkimage: Use PATH_MAX for path length
by mingli.yu＠eng.windriver.com 20 Jun '23

20 Jun '23

From: Mingli Yu <mingli.yu(a)windriver.com> Fixed when build xilinx_zynqmp in long directory ( >256): | /buildarea1/testtest/wr_build/wr1023test_secureboot/test1-what/test2-what/test3-what/test4-what/test5-what/test6-what/test7-what/test8-what/test9-what/test10-what/test11-what/test12-what/build/tmp-glibc/work/xilinx_zynqmp-wrs-linux/u-boot-xlnx/1_v2023.01-xilinx-v2023.1+gitAUTOINC+40a08d69e7-r0/build/fitImage-linux: Image file name (uboot-mkimage) too long, can't create tmpfile. | Error: Bad parameters for FIT image type Signed-off-by: Mingli Yu <mingli.yu(a)windriver.com> --- tools/mkimage.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/mkimage.h b/tools/mkimage.h index f5ca65e2ed..d92a3ff811 100644 --- a/tools/mkimage.h +++ b/tools/mkimage.h @@ -17,6 +17,7 @@ #include <sys/stat.h> #include <time.h> #include <unistd.h> +#include <limits.h> #include <u-boot/sha1.h> #include "fdt_host.h" #include "imagetool.h" @@ -44,7 +45,7 @@ static inline ulong map_to_sysmem(void *ptr) #define ALLOC_CACHE_ALIGN_BUFFER(type, name, size) type name[size] #define MKIMAGE_TMPFILE_SUFFIX ".tmp" -#define MKIMAGE_MAX_TMPFILE_LEN 256 +#define MKIMAGE_MAX_TMPFILE_LEN PATH_MAX #define MKIMAGE_DEFAULT_DTC_OPTIONS "-I dts -O dtb -p 500" #define MKIMAGE_MAX_DTC_CMDLINE_LEN 2 * MKIMAGE_MAX_TMPFILE_LEN + 35 -- 2.25.1

2 1

[BUG] bind command leads to invalid state where plaform data is NULL
by Heinrich Schuchardt 20 Jun '23

20 Jun '23

Hello Simon, from origin/next I build qemu_arm64_defconfig with CONFIG_CMD_BIND=yes. I ran the image with: qemu-system-aarch64 -semihosting \ -machine virt,gic-version=max -accel $(ACCEL) -m 1G -smp cores=2 \ -bios u-boot.bin -cpu $(CPU) -nographic -gdb tcp::1234 \ -netdev user,id=eth0,tftp=tftp -device e1000,netdev=eth0,romfile= \ -drive if=none,file=arm64.img,format=raw,id=mydisk \ -drive if=pflash,format=raw,index=1,file=envstore.img \ -device virtio-rng-pci \ -device ich9-ahci,id=ahci -device ide-hd,drive=mydisk,bus=ahci.0 => scsi bind => dm tree Class Index Probed Driver Name ----------------------------------------------------------- root 0 [ + ] root_driver root_driver pci 0 [ + ] pci_generic_ecam |-- pcie@10000000 pci_generi 0 [ ] pci_generic_drv | |-- pci_0:0.0 ahci 0 [ + ] ahci_pci | `-- ahci_pci scsi 0 [ + ] ahci_scsi | `-- ahci_scsi blk 0 [ + ] scsi_blk | |-- ahci_scsi.id0lun0 partition 0 [ + ] blk_partition | | |-- ahci_scsi.id0lun0:1 partition 1 [ + ] blk_partition | | `-- ahci_scsi.id0lun0:15 bootdev 2 [ ] scsi_bootdev | `-- ahci_scsi.id0lun0.bootdev => unbind blk 0 => dm tree Class Index Probed Driver Name ----------------------------------------------------------- root 0 [ + ] root_driver root_driver pci 0 [ + ] pci_generic_ecam |-- pcie@10000000 pci_generi 0 [ ] pci_generic_drv | |-- pci_0:0.0 ahci 0 [ + ] ahci_pci | `-- ahci_pci scsi 0 [ + ] ahci_scsi | `-- ahci_scsi bootdev 2 [ ] scsi_bootdev | `-- ahci_scsi.id0lun0.bootdev => bind scsi 0 scsi_blk => dm tree Class Index Probed Driver Name ----------------------------------------------------------- root 0 [ + ] root_driver root_driver pci 0 [ + ] pci_generic_ecam |-- pcie@10000000 pci_generi 0 [ ] pci_generic_drv | |-- pci_0:0.0 ahci 0 [ + ] ahci_pci | `-- ahci_pci scsi 0 [ + ] ahci_scsi | `-- ahci_scsi bootdev 2 [ ] scsi_bootdev | |-- ahci_scsi.id0lun0.bootdev blk 0 [ ] scsi_blk | `-- scsi_blk => part list scsi 0 dev_get_uclass_plat: null device "Synchronous Abort" handler, esr 0x96000004, far 0xd503201f14000072 elr: 000000000003392c lr : 0000000000033924 (reloc) elr: 000000007ff1492c lr : 000000007ff14924 x0 : d503201f1400000a x1 : 0000000000000000 x2 : 0000000000000090 x3 : 0000000000000013 x4 : 000000007eda0419 x5 : 0000000000000020 x6 : 00000000ffffffd0 x7 : 000000007eda06b0 x8 : 0000000000000010 x9 : 0000000000000000 x10: 0000000000000006 x11: 000000000001869f x12: 0000000000000016 x13: 0000000000000004 x14: 0000000000000000 x15: 000000007eda073c x16: 000000007ff2547c x17: 0000000000000000 x18: 000000007eea0db0 x19: 0000000000000000 x20: 0000000000000000 x21: 0000000000000001 x22: 0000000000000000 x23: 000000007eda0740 x24: 0000000000000000 x25: 0000000000000000 x26: 0000000000000000 x27: 0000000000000000 x28: 0000000000000000 x29: 000000007eda06d0 Code: aa0303f7 94000287 aa0003f4 f9400260 (f9403418) Resetting CPU ... The crash occurs in blk_read(). blk_read() does not check if desc == NULL. I would have expected "bind scsi 0 scsi_blk" to create a valid state where the platform data is set up. Best regards Heinrich

2 5