[U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case
Since commit ff98cb90514d ("part: extract MBR signature from partitions") SPL boot on i.MX6 starts to fail:
U-Boot SPL 2017.09-00221-g0d6ab32 (Oct 02 2017 - 15:13:19) Trying to boot from MMC1 (keep in loop)
Use the original allocation scheme for the SPL case, so that MX6 boards can boot again.
This is a temporary solution to avoid the boot regression.
Signed-off-by: Fabio Estevam fabio.estevam@nxp.com --- Hi Tom,
I do not have time this week to further investigate and narrow down this problem.
Using the old allocation scheme fixes the mx6 SPL boot problem.
disk/part_dos.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/disk/part_dos.c b/disk/part_dos.c index 1a36be0..6dd2c2d 100644 --- a/disk/part_dos.c +++ b/disk/part_dos.c @@ -89,6 +89,7 @@ static int test_block_type(unsigned char *buffer)
static int part_test_dos(struct blk_desc *dev_desc) { +#ifndef CONFIG_SPL_BUILD ALLOC_CACHE_ALIGN_BUFFER(legacy_mbr, mbr, dev_desc->blksz);
if (blk_dread(dev_desc, 0, 1, (ulong *)mbr) != 1) @@ -102,6 +103,15 @@ static int part_test_dos(struct blk_desc *dev_desc) dev_desc->sig_type = SIG_TYPE_MBR; dev_desc->mbr_sig = mbr->unique_mbr_signature; } +#else + ALLOC_CACHE_ALIGN_BUFFER(unsigned char, buffer, dev_desc->blksz); + + if (blk_dread(dev_desc, 0, 1, (ulong *)buffer) != 1) + return -1; + + if (test_block_type(buffer) != DOS_MBR) + return -1; +#endif
return 0; }
On Wed, Oct 4, 2017 at 12:29 PM, Fabio Estevam fabio.estevam@nxp.com wrote:
Since commit ff98cb90514d ("part: extract MBR signature from partitions") SPL boot on i.MX6 starts to fail:
U-Boot SPL 2017.09-00221-g0d6ab32 (Oct 02 2017 - 15:13:19) Trying to boot from MMC1 (keep in loop)
Use the original allocation scheme for the SPL case, so that MX6 boards can boot again.
This is a temporary solution to avoid the boot regression.
Signed-off-by: Fabio Estevam fabio.estevam@nxp.com
Hi Tom,
I do not have time this week to further investigate and narrow down this problem.
Using the old allocation scheme fixes the mx6 SPL boot problem.
Hi Tom, if you are ok with this as a temporary fix, then this is:
Acked-by: Rob Clark robdclark@gmail.com
I'm getting some help from some of the fedora-arm folks so hopefully I can get some idea what is going wrong, but I'd like to unblock folks w/ mx6 boards..
BR, -R
disk/part_dos.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/disk/part_dos.c b/disk/part_dos.c index 1a36be0..6dd2c2d 100644 --- a/disk/part_dos.c +++ b/disk/part_dos.c @@ -89,6 +89,7 @@ static int test_block_type(unsigned char *buffer)
static int part_test_dos(struct blk_desc *dev_desc) { +#ifndef CONFIG_SPL_BUILD ALLOC_CACHE_ALIGN_BUFFER(legacy_mbr, mbr, dev_desc->blksz);
if (blk_dread(dev_desc, 0, 1, (ulong *)mbr) != 1)@@ -102,6 +103,15 @@ static int part_test_dos(struct blk_desc *dev_desc) dev_desc->sig_type = SIG_TYPE_MBR; dev_desc->mbr_sig = mbr->unique_mbr_signature; } +#else
ALLOC_CACHE_ALIGN_BUFFER(unsigned char, buffer, dev_desc->blksz);if (blk_dread(dev_desc, 0, 1, (ulong *)buffer) != 1)return -1;if (test_block_type(buffer) != DOS_MBR)return -1;+#endif
return 0;}
2.7.4
On Wed, Oct 04, 2017 at 01:12:48PM -0400, Rob Clark wrote:
On Wed, Oct 4, 2017 at 12:29 PM, Fabio Estevam fabio.estevam@nxp.com wrote:
Since commit ff98cb90514d ("part: extract MBR signature from partitions") SPL boot on i.MX6 starts to fail:
U-Boot SPL 2017.09-00221-g0d6ab32 (Oct 02 2017 - 15:13:19) Trying to boot from MMC1 (keep in loop)
Use the original allocation scheme for the SPL case, so that MX6 boards can boot again.
This is a temporary solution to avoid the boot regression.
Signed-off-by: Fabio Estevam fabio.estevam@nxp.com
Hi Tom,
I do not have time this week to further investigate and narrow down this problem.
Using the old allocation scheme fixes the mx6 SPL boot problem.
Hi Tom, if you are ok with this as a temporary fix, then this is:
Acked-by: Rob Clark robdclark@gmail.com
I'm getting some help from some of the fedora-arm folks so hopefully I can get some idea what is going wrong, but I'd like to unblock folks w/ mx6 boards..
BR, -R
This does not seem to be a complete fix, cubox is still broken when U-Boot proper loads, unless the efi loader commits are to blame for introducing unaligned accesses.
Works with 2017.09.
U-Boot SPL 2017.11-rc1-00026-g14b55fc833 (Oct 05 2017 - 15:17:47) Trying to boot from MMC1
U-Boot 2017.11-rc1-00026-g14b55fc833 (Oct 05 2017 - 15:17:47 +1100)
CPU: Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz) CPU: Extended Commercial temperature grade (-20C to 105C) at 34C Reset cause: WDOG Board: MX6 Cubox-i DRAM: 2 GiB MMC: FSL_SDHC: 0 *** Warning - bad CRC, using default environment
No panel detected: default to HDMI Display: HDMI (1024x768) In: serial Out: serial Err: serial Net: FEC Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... CACHE: Misaligned operation at range [8f89da30, 8f89e230] CACHE: Misaligned operation at range [8f89da30, 8f89e230] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89da30 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e230 CACHE: Misaligned operation at range [8f89da30, 8f89e230] CACHE: Misaligned operation at range [8f89da30, 8f89e230] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89da30 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e230 CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0] CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0] CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0] CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0] CACHE: Misaligned operation at range [8f89dc68, 8f89e468] CACHE: Misaligned operation at range [8f89dc68, 8f89e468] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dc68 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e468 CACHE: Misaligned operation at range [8f89dc68, 8f89e468] CACHE: Misaligned operation at range [8f89dc68, 8f89e468] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dc68 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e468 CACHE: Misaligned operation at range [8f89dab0, 8f89e2b0] CACHE: Misaligned operation at range [8f89dab0, 8f89e2b0] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dab0 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e2b0 CACHE: Misaligned operation at range [8f89dab0, 8f89e2b0] CACHE: Misaligned operation at range [8f89dab0, 8f89e2b0] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dab0 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e2b0 CACHE: Misaligned operation at range [8f89dca8, 8f89e4a8] CACHE: Misaligned operation at range [8f89dca8, 8f89e4a8] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dca8 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e4a8 CACHE: Misaligned operation at range [8f89dca8, 8f89e4a8] CACHE: Misaligned operation at range [8f89dca8, 8f89e4a8] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dca8 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e4a8 CACHE: Misaligned operation at range [8f89dc70, 8f89e470] CACHE: Misaligned operation at range [8f89dc70, 8f89e470] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dc70 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e470 CACHE: Misaligned operation at range [8f89dc70, 8f89e470] CACHE: Misaligned operation at range [8f89dc70, 8f89e470] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dc70 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e470 CACHE: Misaligned operation at range [8f89e488, 8f89ec88] CACHE: Misaligned operation at range [8f89e488, 8f89ec88] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89e488 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89ec88 CACHE: Misaligned operation at range [8f89e488, 8f89ec88] CACHE: Misaligned operation at range [8f89e488, 8f89ec88] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89e488 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89ec88 CACHE: Misaligned operation at range [8f89e470, 8f89ec70] CACHE: Misaligned operation at range [8f89e470, 8f89ec70] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89e470 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89ec70 CACHE: Misaligned operation at range [8f89e470, 8f89ec70] CACHE: Misaligned operation at range [8f89e470, 8f89ec70] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89e470 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89ec70 CACHE: Misaligned operation at range [8f89e488, 8f89ec88] CACHE: Misaligned operation at range [8f89e488, 8f89ec88] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89e488 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89ec88 CACHE: Misaligned operation at range [8f89e488, 8f89ec88] CACHE: Misaligned operation at range [8f89e488, 8f89ec88] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89e488 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89ec88 CACHE: Misaligned operation at range [8f89e438, 8f89ec38] CACHE: Misaligned operation at range [8f89e438, 8f89ec38] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89e438 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89ec38 CACHE: Misaligned operation at range [8f89e438, 8f89ec38] CACHE: Misaligned operation at range [8f89e438, 8f89ec38] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89e438 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89ec38 AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl SATA mode flags: ncq stag pm led clo only pmp pio slum part No port device detected!
Device 0: Model: Firm: Ser#: Type: Hard Disk Capacity: not available ... is now current device ** Bad device size - sata 0 ** starting USB... USB0: Port not available. USB1: USB EHCI 1.00 scanning bus 1 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found
Device 0: device type unknown ... is now current device ** Bad device usb 0 ** ** Bad device usb 0 **
On Thu, Oct 5, 2017 at 12:36 AM, Jonathan Gray jsg@jsg.id.au wrote:
On Wed, Oct 04, 2017 at 01:12:48PM -0400, Rob Clark wrote:
On Wed, Oct 4, 2017 at 12:29 PM, Fabio Estevam fabio.estevam@nxp.com wrote:
Since commit ff98cb90514d ("part: extract MBR signature from partitions") SPL boot on i.MX6 starts to fail:
U-Boot SPL 2017.09-00221-g0d6ab32 (Oct 02 2017 - 15:13:19) Trying to boot from MMC1 (keep in loop)
Use the original allocation scheme for the SPL case, so that MX6 boards can boot again.
This is a temporary solution to avoid the boot regression.
Signed-off-by: Fabio Estevam fabio.estevam@nxp.com
Hi Tom,
I do not have time this week to further investigate and narrow down this problem.
Using the old allocation scheme fixes the mx6 SPL boot problem.
Hi Tom, if you are ok with this as a temporary fix, then this is:
Acked-by: Rob Clark robdclark@gmail.com
I'm getting some help from some of the fedora-arm folks so hopefully I can get some idea what is going wrong, but I'd like to unblock folks w/ mx6 boards..
BR, -R
This does not seem to be a complete fix, cubox is still broken when U-Boot proper loads, unless the efi loader commits are to blame for introducing unaligned accesses.
Works with 2017.09.
U-Boot SPL 2017.11-rc1-00026-g14b55fc833 (Oct 05 2017 - 15:17:47) Trying to boot from MMC1
U-Boot 2017.11-rc1-00026-g14b55fc833 (Oct 05 2017 - 15:17:47 +1100)
CPU: Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz) CPU: Extended Commercial temperature grade (-20C to 105C) at 34C Reset cause: WDOG Board: MX6 Cubox-i DRAM: 2 GiB MMC: FSL_SDHC: 0 *** Warning - bad CRC, using default environment
No panel detected: default to HDMI Display: HDMI (1024x768) In: serial Out: serial Err: serial Net: FEC Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1...
I don't think any efi_loader code is running here, you would see a message like:
## Starting EFI application at XYZ
But to be sure you can disable CONFIG_EFI_LOADER in menuconfig to confirm.
I guess this is some unrelated change. I suspect Tom's change to malloc the fat_itr's which would make the buffers used for fs_exists()/etc not cache aligned. I thought there was a patch floating around to change that to memalign().
BR, -R
CACHE: Misaligned operation at range [8f89da30, 8f89e230] CACHE: Misaligned operation at range [8f89da30, 8f89e230] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89da30 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e230 CACHE: Misaligned operation at range [8f89da30, 8f89e230] CACHE: Misaligned operation at range [8f89da30, 8f89e230] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89da30 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e230 CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0] CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0] CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0] CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0] CACHE: Misaligned operation at range [8f89dc68, 8f89e468] CACHE: Misaligned operation at range [8f89dc68, 8f89e468] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dc68 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e468 CACHE: Misaligned operation at range [8f89dc68, 8f89e468] CACHE: Misaligned operation at range [8f89dc68, 8f89e468] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dc68 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e468 CACHE: Misaligned operation at range [8f89dab0, 8f89e2b0] CACHE: Misaligned operation at range [8f89dab0, 8f89e2b0] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dab0 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e2b0 CACHE: Misaligned operation at range [8f89dab0, 8f89e2b0] CACHE: Misaligned operation at range [8f89dab0, 8f89e2b0] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dab0 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e2b0 CACHE: Misaligned operation at range [8f89dca8, 8f89e4a8] CACHE: Misaligned operation at range [8f89dca8, 8f89e4a8] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dca8 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e4a8 CACHE: Misaligned operation at range [8f89dca8, 8f89e4a8] CACHE: Misaligned operation at range [8f89dca8, 8f89e4a8] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dca8 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e4a8 CACHE: Misaligned operation at range [8f89dc70, 8f89e470] CACHE: Misaligned operation at range [8f89dc70, 8f89e470] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dc70 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e470 CACHE: Misaligned operation at range [8f89dc70, 8f89e470] CACHE: Misaligned operation at range [8f89dc70, 8f89e470] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dc70 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e470 CACHE: Misaligned operation at range [8f89e488, 8f89ec88] CACHE: Misaligned operation at range [8f89e488, 8f89ec88] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89e488 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89ec88 CACHE: Misaligned operation at range [8f89e488, 8f89ec88] CACHE: Misaligned operation at range [8f89e488, 8f89ec88] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89e488 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89ec88 CACHE: Misaligned operation at range [8f89e470, 8f89ec70] CACHE: Misaligned operation at range [8f89e470, 8f89ec70] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89e470 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89ec70 CACHE: Misaligned operation at range [8f89e470, 8f89ec70] CACHE: Misaligned operation at range [8f89e470, 8f89ec70] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89e470 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89ec70 CACHE: Misaligned operation at range [8f89e488, 8f89ec88] CACHE: Misaligned operation at range [8f89e488, 8f89ec88] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89e488 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89ec88 CACHE: Misaligned operation at range [8f89e488, 8f89ec88] CACHE: Misaligned operation at range [8f89e488, 8f89ec88] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89e488 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89ec88 CACHE: Misaligned operation at range [8f89e438, 8f89ec38] CACHE: Misaligned operation at range [8f89e438, 8f89ec38] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89e438 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89ec38 CACHE: Misaligned operation at range [8f89e438, 8f89ec38] CACHE: Misaligned operation at range [8f89e438, 8f89ec38] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89e438 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89ec38 AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl SATA mode flags: ncq stag pm led clo only pmp pio slum part No port device detected!
Device 0: Model: Firm: Ser#: Type: Hard Disk Capacity: not available ... is now current device ** Bad device size - sata 0 ** starting USB... USB0: Port not available. USB1: USB EHCI 1.00 scanning bus 1 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found
Device 0: device type unknown ... is now current device ** Bad device usb 0 ** ** Bad device usb 0 **
On Thu, Oct 05, 2017 at 05:05:49AM -0400, Rob Clark wrote:
On Thu, Oct 5, 2017 at 12:36 AM, Jonathan Gray jsg@jsg.id.au wrote:
On Wed, Oct 04, 2017 at 01:12:48PM -0400, Rob Clark wrote:
On Wed, Oct 4, 2017 at 12:29 PM, Fabio Estevam fabio.estevam@nxp.com wrote:
Since commit ff98cb90514d ("part: extract MBR signature from partitions") SPL boot on i.MX6 starts to fail:
U-Boot SPL 2017.09-00221-g0d6ab32 (Oct 02 2017 - 15:13:19) Trying to boot from MMC1 (keep in loop)
Use the original allocation scheme for the SPL case, so that MX6 boards can boot again.
This is a temporary solution to avoid the boot regression.
Signed-off-by: Fabio Estevam fabio.estevam@nxp.com
Hi Tom,
I do not have time this week to further investigate and narrow down this problem.
Using the old allocation scheme fixes the mx6 SPL boot problem.
Hi Tom, if you are ok with this as a temporary fix, then this is:
Acked-by: Rob Clark robdclark@gmail.com
I'm getting some help from some of the fedora-arm folks so hopefully I can get some idea what is going wrong, but I'd like to unblock folks w/ mx6 boards..
BR, -R
This does not seem to be a complete fix, cubox is still broken when U-Boot proper loads, unless the efi loader commits are to blame for introducing unaligned accesses.
Works with 2017.09.
U-Boot SPL 2017.11-rc1-00026-g14b55fc833 (Oct 05 2017 - 15:17:47) Trying to boot from MMC1
U-Boot 2017.11-rc1-00026-g14b55fc833 (Oct 05 2017 - 15:17:47 +1100)
CPU: Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz) CPU: Extended Commercial temperature grade (-20C to 105C) at 34C Reset cause: WDOG Board: MX6 Cubox-i DRAM: 2 GiB MMC: FSL_SDHC: 0 *** Warning - bad CRC, using default environment
No panel detected: default to HDMI Display: HDMI (1024x768) In: serial Out: serial Err: serial Net: FEC Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1...
I don't think any efi_loader code is running here, you would see a message like:
## Starting EFI application at XYZ
But to be sure you can disable CONFIG_EFI_LOADER in menuconfig to confirm.
I guess this is some unrelated change. I suspect Tom's change to malloc the fat_itr's which would make the buffers used for fs_exists()/etc not cache aligned. I thought there was a patch floating around to change that to memalign().
The imx6 problems still occur with CONFIG_EFI_LOADER disabled indeed.
I can no longer load a kernel via efi on bbb though:
U-Boot SPL 2017.11-rc1-00066-g4ac7de9239 (Oct 06 2017 - 14:21:51) Trying to boot from MMC1 reading u-boot.img reading u-boot.img
U-Boot 2017.11-rc1-00066-g4ac7de9239 (Oct 06 2017 - 14:21:51 +1100)
CPU : AM335X-GP rev 2.1 I2C: ready DRAM: 512 MiB No match for driver 'omap_hsmmc' No match for driver 'omap_hsmmc' Some drivers were not found MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 <ethaddr> not set. Validating first E-fuse MAC Net: cpsw, usb_ether Press SPACE to abort autoboot in 2 seconds switch to partitions #0, OK mmc0 is current device SD/MMC found on device 0 ** Unable to read file boot.scr ** ** Unable to read file uEnv.txt ** switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... reading /am335x-boneblack.dtb 35712 bytes read in 10 ms (3.4 MiB/s) Found EFI removable media binary efi/boot/bootarm.efi reading efi/boot/bootarm.efi 65448 bytes read in 16 ms (3.9 MiB/s) ## Starting EFI application at 82000000 ... Scanning disks on usb... Scanning disks on mmc... MMC Device 2 not found MMC Device 3 not found Found 6 disks
OpenBSD/armv7 BOOTARM 0.9
boot> cannot open sd0a:/etc/random.seed: Device not configured booting sd0a:/bsd: open sd0a:/bsd: Device not configured failed(6). will try /bsd boot> cannot open sd0a:/etc/random.seed: Device not configured booting sd0a:/bsd: open sd0a:/bsd: Device not configured failed(6). will try /bsd Turning timeout off. boot> ls sd1a:/ stat(sd1a:/): Device not configured
To reproduce replace the existing MLO/u-boot.img in the FAT fs in https://ftp.openbsd.org/pub/OpenBSD/snapshots/armv7/miniroot-am335x-62.fs
U-Boot 2017.09 works fine.
U-Boot SPL 2017.09 (Sep 12 2017 - 13:40:28) Trying to boot from MMC1 reading u-boot.img reading u-boot.img
U-Boot 2017.09 (Sep 12 2017 - 13:40:28 +1000)
CPU : AM335X-GP rev 2.1 I2C: ready DRAM: 512 MiB No match for driver 'omap_hsmmc' No match for driver 'omap_hsmmc' Some drivers were not found MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 <ethaddr> not set. Validating first E-fuse MAC Net: cpsw, usb_ether Press SPACE to abort autoboot in 2 seconds switch to partitions #0, OK mmc0 is current device SD/MMC found on device 0 reading boot.scr ** Unable to read file boot.scr ** reading uEnv.txt ** Unable to read file uEnv.txt ** switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... reading /am335x-boneblack.dtb 35712 bytes read in 10 ms (3.4 MiB/s) Found EFI removable media binary efi/boot/bootarm.efi reading efi/boot/bootarm.efi 65448 bytes read in 14 ms (4.5 MiB/s) ## Starting EFI application at 82000000 ... Scanning disks on usb... Scanning disks on mmc... MMC Device 2 not found MMC Device 3 not found Found 6 disks
OpenBSD/armv7 BOOTARM 0.9
boot> booting sd0a:/bsd: 3933596+165624+561144|[282400+90+521200+244991]=0x579920
OpenBSD/armv7 booting ... arg0 0xc0879920 arg1 0xe05 arg2 0x88000000 Allocating page tables freestart = 0x8087a000, free_pages = 128902 (0x0001f786) IRQ stack: p0x808a8000 v0xc08a8000 ABT stack: p0x808a9000 v0xc08a9000 UND stack: p0x808aa000 v0xc08aa000 SVC stack: p0x808ab000 v0xc08ab000 Creating L1 page table at 0x8087c000 Mapping kernel Constructing L2 page tables undefined page pmap [ using 1049136 bytes of bsd ELF symbol table ] board type: 3589 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2017 OpenBSD. All rights reserved. https://www.OpenBSD.org ...
On Fri, Oct 6, 2017 at 12:35 AM, Jonathan Gray jsg@jsg.id.au wrote:
On Thu, Oct 05, 2017 at 05:05:49AM -0400, Rob Clark wrote:
On Thu, Oct 5, 2017 at 12:36 AM, Jonathan Gray jsg@jsg.id.au wrote:
On Wed, Oct 04, 2017 at 01:12:48PM -0400, Rob Clark wrote:
On Wed, Oct 4, 2017 at 12:29 PM, Fabio Estevam fabio.estevam@nxp.com wrote:
Since commit ff98cb90514d ("part: extract MBR signature from partitions") SPL boot on i.MX6 starts to fail:
U-Boot SPL 2017.09-00221-g0d6ab32 (Oct 02 2017 - 15:13:19) Trying to boot from MMC1 (keep in loop)
Use the original allocation scheme for the SPL case, so that MX6 boards can boot again.
This is a temporary solution to avoid the boot regression.
Signed-off-by: Fabio Estevam fabio.estevam@nxp.com
Hi Tom,
I do not have time this week to further investigate and narrow down this problem.
Using the old allocation scheme fixes the mx6 SPL boot problem.
Hi Tom, if you are ok with this as a temporary fix, then this is:
Acked-by: Rob Clark robdclark@gmail.com
I'm getting some help from some of the fedora-arm folks so hopefully I can get some idea what is going wrong, but I'd like to unblock folks w/ mx6 boards..
BR, -R
This does not seem to be a complete fix, cubox is still broken when U-Boot proper loads, unless the efi loader commits are to blame for introducing unaligned accesses.
Works with 2017.09.
U-Boot SPL 2017.11-rc1-00026-g14b55fc833 (Oct 05 2017 - 15:17:47) Trying to boot from MMC1
U-Boot 2017.11-rc1-00026-g14b55fc833 (Oct 05 2017 - 15:17:47 +1100)
CPU: Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz) CPU: Extended Commercial temperature grade (-20C to 105C) at 34C Reset cause: WDOG Board: MX6 Cubox-i DRAM: 2 GiB MMC: FSL_SDHC: 0 *** Warning - bad CRC, using default environment
No panel detected: default to HDMI Display: HDMI (1024x768) In: serial Out: serial Err: serial Net: FEC Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1...
I don't think any efi_loader code is running here, you would see a message like:
## Starting EFI application at XYZ
But to be sure you can disable CONFIG_EFI_LOADER in menuconfig to confirm.
I guess this is some unrelated change. I suspect Tom's change to malloc the fat_itr's which would make the buffers used for fs_exists()/etc not cache aligned. I thought there was a patch floating around to change that to memalign().
The imx6 problems still occur with CONFIG_EFI_LOADER disabled indeed.
I can no longer load a kernel via efi on bbb though:
U-Boot SPL 2017.11-rc1-00066-g4ac7de9239 (Oct 06 2017 - 14:21:51) Trying to boot from MMC1 reading u-boot.img reading u-boot.img
U-Boot 2017.11-rc1-00066-g4ac7de9239 (Oct 06 2017 - 14:21:51 +1100)
CPU : AM335X-GP rev 2.1 I2C: ready DRAM: 512 MiB No match for driver 'omap_hsmmc' No match for driver 'omap_hsmmc' Some drivers were not found MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 <ethaddr> not set. Validating first E-fuse MAC Net: cpsw, usb_ether Press SPACE to abort autoboot in 2 seconds switch to partitions #0, OK mmc0 is current device SD/MMC found on device 0 ** Unable to read file boot.scr ** ** Unable to read file uEnv.txt ** switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... reading /am335x-boneblack.dtb 35712 bytes read in 10 ms (3.4 MiB/s) Found EFI removable media binary efi/boot/bootarm.efi reading efi/boot/bootarm.efi 65448 bytes read in 16 ms (3.9 MiB/s) ## Starting EFI application at 82000000 ... Scanning disks on usb... Scanning disks on mmc... MMC Device 2 not found MMC Device 3 not found Found 6 disks
OpenBSD/armv7 BOOTARM 0.9
boot> cannot open sd0a:/etc/random.seed: Device not configured booting sd0a:/bsd: open sd0a:/bsd: Device not configured failed(6). will try /bsd boot> cannot open sd0a:/etc/random.seed: Device not configured booting sd0a:/bsd: open sd0a:/bsd: Device not configured failed(6). will try /bsd Turning timeout off. boot> ls sd1a:/ stat(sd1a:/): Device not configured
To reproduce replace the existing MLO/u-boot.img in the FAT fs in https://ftp.openbsd.org/pub/OpenBSD/snapshots/armv7/miniroot-am335x-62.fs
Can you reproduce this on any aarch64 device? I don't have anything armv7 to try. (I guess the kernel won't actually boot on my db410c but at least it should get as far as trying if I could reproduce this on aarch64)
I guess the openbsd bootloader is recognizing the "disks" differently now with more accurate devicepaths. Or maybe some hack that was used to make things work before with the non-standard dp's is causing problems now?
BR, -R
U-Boot 2017.09 works fine.
U-Boot SPL 2017.09 (Sep 12 2017 - 13:40:28) Trying to boot from MMC1 reading u-boot.img reading u-boot.img
U-Boot 2017.09 (Sep 12 2017 - 13:40:28 +1000)
CPU : AM335X-GP rev 2.1 I2C: ready DRAM: 512 MiB No match for driver 'omap_hsmmc' No match for driver 'omap_hsmmc' Some drivers were not found MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 <ethaddr> not set. Validating first E-fuse MAC Net: cpsw, usb_ether Press SPACE to abort autoboot in 2 seconds switch to partitions #0, OK mmc0 is current device SD/MMC found on device 0 reading boot.scr ** Unable to read file boot.scr ** reading uEnv.txt ** Unable to read file uEnv.txt ** switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... reading /am335x-boneblack.dtb 35712 bytes read in 10 ms (3.4 MiB/s) Found EFI removable media binary efi/boot/bootarm.efi reading efi/boot/bootarm.efi 65448 bytes read in 14 ms (4.5 MiB/s) ## Starting EFI application at 82000000 ... Scanning disks on usb... Scanning disks on mmc... MMC Device 2 not found MMC Device 3 not found Found 6 disks
OpenBSD/armv7 BOOTARM 0.9
boot> booting sd0a:/bsd: 3933596+165624+561144|[282400+90+521200+244991]=0x579920
OpenBSD/armv7 booting ... arg0 0xc0879920 arg1 0xe05 arg2 0x88000000 Allocating page tables freestart = 0x8087a000, free_pages = 128902 (0x0001f786) IRQ stack: p0x808a8000 v0xc08a8000 ABT stack: p0x808a9000 v0xc08a9000 UND stack: p0x808aa000 v0xc08aa000 SVC stack: p0x808ab000 v0xc08ab000 Creating L1 page table at 0x8087c000 Mapping kernel Constructing L2 page tables undefined page pmap [ using 1049136 bytes of bsd ELF symbol table ] board type: 3589 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2017 OpenBSD. All rights reserved. https://www.OpenBSD.org ...
On Fri, Oct 6, 2017 at 8:21 AM, Rob Clark robdclark@gmail.com wrote:
On Fri, Oct 6, 2017 at 12:35 AM, Jonathan Gray jsg@jsg.id.au wrote:
On Thu, Oct 05, 2017 at 05:05:49AM -0400, Rob Clark wrote:
On Thu, Oct 5, 2017 at 12:36 AM, Jonathan Gray jsg@jsg.id.au wrote:
On Wed, Oct 04, 2017 at 01:12:48PM -0400, Rob Clark wrote:
On Wed, Oct 4, 2017 at 12:29 PM, Fabio Estevam fabio.estevam@nxp.com wrote:
Since commit ff98cb90514d ("part: extract MBR signature from partitions") SPL boot on i.MX6 starts to fail:
U-Boot SPL 2017.09-00221-g0d6ab32 (Oct 02 2017 - 15:13:19) Trying to boot from MMC1 (keep in loop)
Use the original allocation scheme for the SPL case, so that MX6 boards can boot again.
This is a temporary solution to avoid the boot regression.
Signed-off-by: Fabio Estevam fabio.estevam@nxp.com
Hi Tom,
I do not have time this week to further investigate and narrow down this problem.
Using the old allocation scheme fixes the mx6 SPL boot problem.
Hi Tom, if you are ok with this as a temporary fix, then this is:
Acked-by: Rob Clark robdclark@gmail.com
I'm getting some help from some of the fedora-arm folks so hopefully I can get some idea what is going wrong, but I'd like to unblock folks w/ mx6 boards..
BR, -R
This does not seem to be a complete fix, cubox is still broken when U-Boot proper loads, unless the efi loader commits are to blame for introducing unaligned accesses.
Works with 2017.09.
U-Boot SPL 2017.11-rc1-00026-g14b55fc833 (Oct 05 2017 - 15:17:47) Trying to boot from MMC1
U-Boot 2017.11-rc1-00026-g14b55fc833 (Oct 05 2017 - 15:17:47 +1100)
CPU: Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz) CPU: Extended Commercial temperature grade (-20C to 105C) at 34C Reset cause: WDOG Board: MX6 Cubox-i DRAM: 2 GiB MMC: FSL_SDHC: 0 *** Warning - bad CRC, using default environment
No panel detected: default to HDMI Display: HDMI (1024x768) In: serial Out: serial Err: serial Net: FEC Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1...
I don't think any efi_loader code is running here, you would see a message like:
## Starting EFI application at XYZ
But to be sure you can disable CONFIG_EFI_LOADER in menuconfig to confirm.
I guess this is some unrelated change. I suspect Tom's change to malloc the fat_itr's which would make the buffers used for fs_exists()/etc not cache aligned. I thought there was a patch floating around to change that to memalign().
The imx6 problems still occur with CONFIG_EFI_LOADER disabled indeed.
I can no longer load a kernel via efi on bbb though:
U-Boot SPL 2017.11-rc1-00066-g4ac7de9239 (Oct 06 2017 - 14:21:51) Trying to boot from MMC1 reading u-boot.img reading u-boot.img
U-Boot 2017.11-rc1-00066-g4ac7de9239 (Oct 06 2017 - 14:21:51 +1100)
CPU : AM335X-GP rev 2.1 I2C: ready DRAM: 512 MiB No match for driver 'omap_hsmmc' No match for driver 'omap_hsmmc' Some drivers were not found MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 <ethaddr> not set. Validating first E-fuse MAC Net: cpsw, usb_ether Press SPACE to abort autoboot in 2 seconds switch to partitions #0, OK mmc0 is current device SD/MMC found on device 0 ** Unable to read file boot.scr ** ** Unable to read file uEnv.txt ** switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... reading /am335x-boneblack.dtb 35712 bytes read in 10 ms (3.4 MiB/s) Found EFI removable media binary efi/boot/bootarm.efi reading efi/boot/bootarm.efi 65448 bytes read in 16 ms (3.9 MiB/s) ## Starting EFI application at 82000000 ... Scanning disks on usb... Scanning disks on mmc... MMC Device 2 not found MMC Device 3 not found Found 6 disks
OpenBSD/armv7 BOOTARM 0.9
boot> cannot open sd0a:/etc/random.seed: Device not configured booting sd0a:/bsd: open sd0a:/bsd: Device not configured failed(6). will try /bsd boot> cannot open sd0a:/etc/random.seed: Device not configured booting sd0a:/bsd: open sd0a:/bsd: Device not configured failed(6). will try /bsd Turning timeout off. boot> ls sd1a:/ stat(sd1a:/): Device not configured
To reproduce replace the existing MLO/u-boot.img in the FAT fs in https://ftp.openbsd.org/pub/OpenBSD/snapshots/armv7/miniroot-am335x-62.fs
Can you reproduce this on any aarch64 device? I don't have anything armv7 to try. (I guess the kernel won't actually boot on my db410c but at least it should get as far as trying if I could reproduce this on aarch64)
I guess the openbsd bootloader is recognizing the "disks" differently now with more accurate devicepaths. Or maybe some hack that was used to make things work before with the non-standard dp's is causing problems now?
hmm, I tried:
https://ftp.openbsd.org/pub/OpenBSD/snapshots/arm64/miniroot62.fs
and it appears to work fine:
U-Boot 2017.11-rc1-00058-g5df8694f0e-dirty (Oct 05 2017 - 09:49:18 -0400) Qualcomm-DragonBoard 410C
DRAM: 986 MiB MMC: sdhci@07864000: 0 In: serial Out: serial Err: serial Net: No ethernet found. USB0: USB EHCI 1.00 scanning bus 0 for devices... 2 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Scanning disk sdhci@07864000.blk for environment... Found uboot.env on sdhci@07864000.blk:1 reading uboot.env Hit any key to stop autoboot: 0
Device 0: unknown device MMC Device 1 not found no mmc device at slot 1 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found EFI removable media binary efi/boot/bootaa64.efi Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** libfdt fdt_check_header(): FDT_ERR_BADMAGIC Scanning disk sdhci@07864000.blk... Found 1 disks reading efi/boot/bootaa64.efi 78287 bytes read in 36 ms (2.1 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC ## Starting EFI application at 81000000 ... WARNING: Invalid device tree, expect boot to fail
OpenBSD/arm64 BOOTAA64 0.8
boot> cannot open sd0a:/etc/random.seed: No such file or directory booting sd0a:/bsd: 2371620+366316+8311264+731216 [183923+96+285960+157516]=0xf39220
On Fri, Oct 06, 2017 at 08:21:26AM -0400, Rob Clark wrote:
On Fri, Oct 6, 2017 at 12:35 AM, Jonathan Gray jsg@jsg.id.au wrote:
On Thu, Oct 05, 2017 at 05:05:49AM -0400, Rob Clark wrote:
On Thu, Oct 5, 2017 at 12:36 AM, Jonathan Gray jsg@jsg.id.au wrote:
On Wed, Oct 04, 2017 at 01:12:48PM -0400, Rob Clark wrote:
On Wed, Oct 4, 2017 at 12:29 PM, Fabio Estevam fabio.estevam@nxp.com wrote:
Since commit ff98cb90514d ("part: extract MBR signature from partitions") SPL boot on i.MX6 starts to fail:
U-Boot SPL 2017.09-00221-g0d6ab32 (Oct 02 2017 - 15:13:19) Trying to boot from MMC1 (keep in loop)
Use the original allocation scheme for the SPL case, so that MX6 boards can boot again.
This is a temporary solution to avoid the boot regression.
Signed-off-by: Fabio Estevam fabio.estevam@nxp.com
Hi Tom,
I do not have time this week to further investigate and narrow down this problem.
Using the old allocation scheme fixes the mx6 SPL boot problem.
Hi Tom, if you are ok with this as a temporary fix, then this is:
Acked-by: Rob Clark robdclark@gmail.com
I'm getting some help from some of the fedora-arm folks so hopefully I can get some idea what is going wrong, but I'd like to unblock folks w/ mx6 boards..
BR, -R
This does not seem to be a complete fix, cubox is still broken when U-Boot proper loads, unless the efi loader commits are to blame for introducing unaligned accesses.
Works with 2017.09.
U-Boot SPL 2017.11-rc1-00026-g14b55fc833 (Oct 05 2017 - 15:17:47) Trying to boot from MMC1
U-Boot 2017.11-rc1-00026-g14b55fc833 (Oct 05 2017 - 15:17:47 +1100)
CPU: Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz) CPU: Extended Commercial temperature grade (-20C to 105C) at 34C Reset cause: WDOG Board: MX6 Cubox-i DRAM: 2 GiB MMC: FSL_SDHC: 0 *** Warning - bad CRC, using default environment
No panel detected: default to HDMI Display: HDMI (1024x768) In: serial Out: serial Err: serial Net: FEC Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1...
I don't think any efi_loader code is running here, you would see a message like:
## Starting EFI application at XYZ
But to be sure you can disable CONFIG_EFI_LOADER in menuconfig to confirm.
I guess this is some unrelated change. I suspect Tom's change to malloc the fat_itr's which would make the buffers used for fs_exists()/etc not cache aligned. I thought there was a patch floating around to change that to memalign().
The imx6 problems still occur with CONFIG_EFI_LOADER disabled indeed.
I can no longer load a kernel via efi on bbb though:
U-Boot SPL 2017.11-rc1-00066-g4ac7de9239 (Oct 06 2017 - 14:21:51) Trying to boot from MMC1 reading u-boot.img reading u-boot.img
U-Boot 2017.11-rc1-00066-g4ac7de9239 (Oct 06 2017 - 14:21:51 +1100)
CPU : AM335X-GP rev 2.1 I2C: ready DRAM: 512 MiB No match for driver 'omap_hsmmc' No match for driver 'omap_hsmmc' Some drivers were not found MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 <ethaddr> not set. Validating first E-fuse MAC Net: cpsw, usb_ether Press SPACE to abort autoboot in 2 seconds switch to partitions #0, OK mmc0 is current device SD/MMC found on device 0 ** Unable to read file boot.scr ** ** Unable to read file uEnv.txt ** switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... reading /am335x-boneblack.dtb 35712 bytes read in 10 ms (3.4 MiB/s) Found EFI removable media binary efi/boot/bootarm.efi reading efi/boot/bootarm.efi 65448 bytes read in 16 ms (3.9 MiB/s) ## Starting EFI application at 82000000 ... Scanning disks on usb... Scanning disks on mmc... MMC Device 2 not found MMC Device 3 not found Found 6 disks
OpenBSD/armv7 BOOTARM 0.9
boot> cannot open sd0a:/etc/random.seed: Device not configured booting sd0a:/bsd: open sd0a:/bsd: Device not configured failed(6). will try /bsd boot> cannot open sd0a:/etc/random.seed: Device not configured booting sd0a:/bsd: open sd0a:/bsd: Device not configured failed(6). will try /bsd Turning timeout off. boot> ls sd1a:/ stat(sd1a:/): Device not configured
To reproduce replace the existing MLO/u-boot.img in the FAT fs in https://ftp.openbsd.org/pub/OpenBSD/snapshots/armv7/miniroot-am335x-62.fs
Can you reproduce this on any aarch64 device? I don't have anything armv7 to try. (I guess the kernel won't actually boot on my db410c but at least it should get as far as trying if I could reproduce this on aarch64)
Dale Rahn was working on DragonBoard support and had a driver for the MSM UART but those changes are not currently in the tree/snapshots.
I guess the openbsd bootloader is recognizing the "disks" differently now with more accurate devicepaths. Or maybe some hack that was used to make things work before with the non-standard dp's is causing problems now?
Same problem with the aarch64 rpi_3 target. The same efiboot binary works fine on U-Boot 2017.09 and the EDK2 based firmware on the OverDrive 1000.
U-Boot is built with linaro gcc 6.3.2017.02
U-Boot 2017.11-rc1-00066-g4ac7de9239 (Oct 07 2017 - 12:44:27 +1100)
DRAM: 948 MiB RPI 3 Model B (0xa02082) MMC: sdhci@7e300000: 0 reading uboot.env In: serial Out: vidconsole Err: vidconsole Net: No ethernet found. starting USB... USB0: Core Release: 2.80a scanning bus 0 for devices... 4 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found Hit any key to stop autoboot: 0
Device 0: Vendor: SanDisk Rev: 1.00 Prod: Ultra Type: Removable Hard Disk Capacity: 29327.3 MB = 28.6 GB (60062500 x 512) ... is now current device Scanning usb 0:1... Found EFI removable media binary efi/boot/bootaa64.efi reading efi/boot/bootaa64.efi 78287 bytes read in 86 ms (888.7 KiB/s) ## Starting EFI application at 01000000 ... Scanning disk sdhci@7e300000.blk... Scanning disk usb_mass_storage.lun0... Found 2 disks
OpenBSD/arm64 BOOTAA64 0.8
boot> cannot open sd0a:/etc/random.seed: Device not configured booting sd0a:/bsd: open sd0a:/bsd: Device not configured failed(6). will try /bsd boot> cannot open sd0a:/etc/random.seed: Device not configured booting sd0a:/bsd: open sd0a:/bsd: Device not configured failed(6). will try /bsd Turning timeout off. boot> ls sd0a:/ stat(sd0a:/): Device not configured boot> ls sd1a:/ stat(sd1a:/): Device not configured boot>
U-Boot 2017.09 (Sep 12 2017 - 13:08:30 +1000)
DRAM: 948 MiB RPI 3 Model B (0xa02082) MMC: sdhci@7e300000: 0 reading uboot.env In: serial Out: vidconsole Err: vidconsole Net: No ethernet found. starting USB... USB0: Core Release: 2.80a scanning bus 0 for devices... 4 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found Hit any key to stop autoboot: 0
Device 0: Vendor: SanDisk Rev: 1.00 Prod: Ultra Type: Removable Hard Disk Capacity: 29327.3 MB = 28.6 GB (60062500 x 512) ... is now current device Scanning usb 0:1... Found EFI removable media binary efi/boot/bootaa64.efi reading efi/boot/bootaa64.efi 78287 bytes read in 76 ms (1005.9 KiB/s) ## Starting EFI application at 01000000 ... Scanning disk sdhci@7e300000.blk... Scanning disk usb_mass_storage.lun0... Found 2 disks
OpenBSD/arm64 BOOTAA64 0.8
boot> booting sd0a:/bsd: 3871708+578596+509352+803952[283845+96+451968+239920]=0x82f330 ...
On Fri, Oct 6, 2017 at 10:08 PM, Jonathan Gray jsg@jsg.id.au wrote:
On Fri, Oct 06, 2017 at 08:21:26AM -0400, Rob Clark wrote:
On Fri, Oct 6, 2017 at 12:35 AM, Jonathan Gray jsg@jsg.id.au wrote:
On Thu, Oct 05, 2017 at 05:05:49AM -0400, Rob Clark wrote:
On Thu, Oct 5, 2017 at 12:36 AM, Jonathan Gray jsg@jsg.id.au wrote:
On Wed, Oct 04, 2017 at 01:12:48PM -0400, Rob Clark wrote:
On Wed, Oct 4, 2017 at 12:29 PM, Fabio Estevam fabio.estevam@nxp.com wrote: > Since commit ff98cb90514d ("part: extract MBR signature from partitions") > SPL boot on i.MX6 starts to fail: > > U-Boot SPL 2017.09-00221-g0d6ab32 (Oct 02 2017 - 15:13:19) > Trying to boot from MMC1 > (keep in loop) > > Use the original allocation scheme for the SPL case, so that MX6 boards > can boot again. > > This is a temporary solution to avoid the boot regression. > > Signed-off-by: Fabio Estevam fabio.estevam@nxp.com > --- > Hi Tom, > > I do not have time this week to further investigate and narrow down > this problem. > > Using the old allocation scheme fixes the mx6 SPL boot problem. >
Hi Tom, if you are ok with this as a temporary fix, then this is:
Acked-by: Rob Clark robdclark@gmail.com
I'm getting some help from some of the fedora-arm folks so hopefully I can get some idea what is going wrong, but I'd like to unblock folks w/ mx6 boards..
BR, -R
This does not seem to be a complete fix, cubox is still broken when U-Boot proper loads, unless the efi loader commits are to blame for introducing unaligned accesses.
Works with 2017.09.
U-Boot SPL 2017.11-rc1-00026-g14b55fc833 (Oct 05 2017 - 15:17:47) Trying to boot from MMC1
U-Boot 2017.11-rc1-00026-g14b55fc833 (Oct 05 2017 - 15:17:47 +1100)
CPU: Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz) CPU: Extended Commercial temperature grade (-20C to 105C) at 34C Reset cause: WDOG Board: MX6 Cubox-i DRAM: 2 GiB MMC: FSL_SDHC: 0 *** Warning - bad CRC, using default environment
No panel detected: default to HDMI Display: HDMI (1024x768) In: serial Out: serial Err: serial Net: FEC Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1...
I don't think any efi_loader code is running here, you would see a message like:
## Starting EFI application at XYZ
But to be sure you can disable CONFIG_EFI_LOADER in menuconfig to confirm.
I guess this is some unrelated change. I suspect Tom's change to malloc the fat_itr's which would make the buffers used for fs_exists()/etc not cache aligned. I thought there was a patch floating around to change that to memalign().
The imx6 problems still occur with CONFIG_EFI_LOADER disabled indeed.
I can no longer load a kernel via efi on bbb though:
U-Boot SPL 2017.11-rc1-00066-g4ac7de9239 (Oct 06 2017 - 14:21:51) Trying to boot from MMC1 reading u-boot.img reading u-boot.img
U-Boot 2017.11-rc1-00066-g4ac7de9239 (Oct 06 2017 - 14:21:51 +1100)
CPU : AM335X-GP rev 2.1 I2C: ready DRAM: 512 MiB No match for driver 'omap_hsmmc' No match for driver 'omap_hsmmc' Some drivers were not found MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 <ethaddr> not set. Validating first E-fuse MAC Net: cpsw, usb_ether Press SPACE to abort autoboot in 2 seconds switch to partitions #0, OK mmc0 is current device SD/MMC found on device 0 ** Unable to read file boot.scr ** ** Unable to read file uEnv.txt ** switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... reading /am335x-boneblack.dtb 35712 bytes read in 10 ms (3.4 MiB/s) Found EFI removable media binary efi/boot/bootarm.efi reading efi/boot/bootarm.efi 65448 bytes read in 16 ms (3.9 MiB/s) ## Starting EFI application at 82000000 ... Scanning disks on usb... Scanning disks on mmc... MMC Device 2 not found MMC Device 3 not found Found 6 disks
OpenBSD/armv7 BOOTARM 0.9
boot> cannot open sd0a:/etc/random.seed: Device not configured booting sd0a:/bsd: open sd0a:/bsd: Device not configured failed(6). will try /bsd boot> cannot open sd0a:/etc/random.seed: Device not configured booting sd0a:/bsd: open sd0a:/bsd: Device not configured failed(6). will try /bsd Turning timeout off. boot> ls sd1a:/ stat(sd1a:/): Device not configured
To reproduce replace the existing MLO/u-boot.img in the FAT fs in https://ftp.openbsd.org/pub/OpenBSD/snapshots/armv7/miniroot-am335x-62.fs
Can you reproduce this on any aarch64 device? I don't have anything armv7 to try. (I guess the kernel won't actually boot on my db410c but at least it should get as far as trying if I could reproduce this on aarch64)
Dale Rahn was working on DragonBoard support and had a driver for the MSM UART but those changes are not currently in the tree/snapshots.
cool.. but I guess not really necessary to debug, as long as bootloader gets as far as trying to boot the kernel
I guess the openbsd bootloader is recognizing the "disks" differently now with more accurate devicepaths. Or maybe some hack that was used to make things work before with the non-standard dp's is causing problems now?
Same problem with the aarch64 rpi_3 target. The same efiboot binary works fine on U-Boot 2017.09 and the EDK2 based firmware on the OverDrive 1000.
*maybe* it could be a legacy vs DM thing.. there are differences in construction devicepaths for the two cases, and I don't really have a good way to test legacy. (And hopefully folks will hurry up and port legacy devices so we can simplify the efi_loader code.)
I'm not quite sure which category rpi3 falls into. But iirc Peter Robinson tested that with the efi_loader patches + grub2 + fedora and it all worked.
Maybe there is a way I can reproduce this in qemu?
BR, -R
U-Boot is built with linaro gcc 6.3.2017.02
U-Boot 2017.11-rc1-00066-g4ac7de9239 (Oct 07 2017 - 12:44:27 +1100)
DRAM: 948 MiB RPI 3 Model B (0xa02082) MMC: sdhci@7e300000: 0 reading uboot.env In: serial Out: vidconsole Err: vidconsole Net: No ethernet found. starting USB... USB0: Core Release: 2.80a scanning bus 0 for devices... 4 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found Hit any key to stop autoboot: 0
Device 0: Vendor: SanDisk Rev: 1.00 Prod: Ultra Type: Removable Hard Disk Capacity: 29327.3 MB = 28.6 GB (60062500 x 512) ... is now current device Scanning usb 0:1... Found EFI removable media binary efi/boot/bootaa64.efi reading efi/boot/bootaa64.efi 78287 bytes read in 86 ms (888.7 KiB/s) ## Starting EFI application at 01000000 ... Scanning disk sdhci@7e300000.blk... Scanning disk usb_mass_storage.lun0... Found 2 disks
OpenBSD/arm64 BOOTAA64 0.8
boot> cannot open sd0a:/etc/random.seed: Device not configured booting sd0a:/bsd: open sd0a:/bsd: Device not configured failed(6). will try /bsd boot> cannot open sd0a:/etc/random.seed: Device not configured booting sd0a:/bsd: open sd0a:/bsd: Device not configured failed(6). will try /bsd Turning timeout off. boot> ls sd0a:/ stat(sd0a:/): Device not configured boot> ls sd1a:/ stat(sd1a:/): Device not configured boot>
U-Boot 2017.09 (Sep 12 2017 - 13:08:30 +1000)
DRAM: 948 MiB RPI 3 Model B (0xa02082) MMC: sdhci@7e300000: 0 reading uboot.env In: serial Out: vidconsole Err: vidconsole Net: No ethernet found. starting USB... USB0: Core Release: 2.80a scanning bus 0 for devices... 4 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found Hit any key to stop autoboot: 0
Device 0: Vendor: SanDisk Rev: 1.00 Prod: Ultra Type: Removable Hard Disk Capacity: 29327.3 MB = 28.6 GB (60062500 x 512) ... is now current device Scanning usb 0:1... Found EFI removable media binary efi/boot/bootaa64.efi reading efi/boot/bootaa64.efi 78287 bytes read in 76 ms (1005.9 KiB/s) ## Starting EFI application at 01000000 ... Scanning disk sdhci@7e300000.blk... Scanning disk usb_mass_storage.lun0... Found 2 disks
OpenBSD/arm64 BOOTAA64 0.8
boot> booting sd0a:/bsd: 3871708+578596+509352+803952[283845+96+451968+239920]=0x82f330 ...
On Sat, Oct 07, 2017 at 08:23:31AM -0400, Rob Clark wrote:
On Fri, Oct 6, 2017 at 10:08 PM, Jonathan Gray jsg@jsg.id.au wrote:
On Fri, Oct 06, 2017 at 08:21:26AM -0400, Rob Clark wrote:
On Fri, Oct 6, 2017 at 12:35 AM, Jonathan Gray jsg@jsg.id.au wrote:
On Thu, Oct 05, 2017 at 05:05:49AM -0400, Rob Clark wrote:
On Thu, Oct 5, 2017 at 12:36 AM, Jonathan Gray jsg@jsg.id.au wrote:
On Wed, Oct 04, 2017 at 01:12:48PM -0400, Rob Clark wrote: > On Wed, Oct 4, 2017 at 12:29 PM, Fabio Estevam fabio.estevam@nxp.com wrote: > > Since commit ff98cb90514d ("part: extract MBR signature from partitions") > > SPL boot on i.MX6 starts to fail: > > > > U-Boot SPL 2017.09-00221-g0d6ab32 (Oct 02 2017 - 15:13:19) > > Trying to boot from MMC1 > > (keep in loop) > > > > Use the original allocation scheme for the SPL case, so that MX6 boards > > can boot again. > > > > This is a temporary solution to avoid the boot regression. > > > > Signed-off-by: Fabio Estevam fabio.estevam@nxp.com > > --- > > Hi Tom, > > > > I do not have time this week to further investigate and narrow down > > this problem. > > > > Using the old allocation scheme fixes the mx6 SPL boot problem. > > > > Hi Tom, if you are ok with this as a temporary fix, then this is: > > Acked-by: Rob Clark robdclark@gmail.com > > I'm getting some help from some of the fedora-arm folks so hopefully I > can get some idea what is going wrong, but I'd like to unblock folks > w/ mx6 boards.. > > BR, > -R
This does not seem to be a complete fix, cubox is still broken when U-Boot proper loads, unless the efi loader commits are to blame for introducing unaligned accesses.
Works with 2017.09.
U-Boot SPL 2017.11-rc1-00026-g14b55fc833 (Oct 05 2017 - 15:17:47) Trying to boot from MMC1
U-Boot 2017.11-rc1-00026-g14b55fc833 (Oct 05 2017 - 15:17:47 +1100)
CPU: Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz) CPU: Extended Commercial temperature grade (-20C to 105C) at 34C Reset cause: WDOG Board: MX6 Cubox-i DRAM: 2 GiB MMC: FSL_SDHC: 0 *** Warning - bad CRC, using default environment
No panel detected: default to HDMI Display: HDMI (1024x768) In: serial Out: serial Err: serial Net: FEC Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1...
I don't think any efi_loader code is running here, you would see a message like:
## Starting EFI application at XYZ
But to be sure you can disable CONFIG_EFI_LOADER in menuconfig to confirm.
I guess this is some unrelated change. I suspect Tom's change to malloc the fat_itr's which would make the buffers used for fs_exists()/etc not cache aligned. I thought there was a patch floating around to change that to memalign().
The imx6 problems still occur with CONFIG_EFI_LOADER disabled indeed.
I can no longer load a kernel via efi on bbb though:
U-Boot SPL 2017.11-rc1-00066-g4ac7de9239 (Oct 06 2017 - 14:21:51) Trying to boot from MMC1 reading u-boot.img reading u-boot.img
U-Boot 2017.11-rc1-00066-g4ac7de9239 (Oct 06 2017 - 14:21:51 +1100)
CPU : AM335X-GP rev 2.1 I2C: ready DRAM: 512 MiB No match for driver 'omap_hsmmc' No match for driver 'omap_hsmmc' Some drivers were not found MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 <ethaddr> not set. Validating first E-fuse MAC Net: cpsw, usb_ether Press SPACE to abort autoboot in 2 seconds switch to partitions #0, OK mmc0 is current device SD/MMC found on device 0 ** Unable to read file boot.scr ** ** Unable to read file uEnv.txt ** switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... reading /am335x-boneblack.dtb 35712 bytes read in 10 ms (3.4 MiB/s) Found EFI removable media binary efi/boot/bootarm.efi reading efi/boot/bootarm.efi 65448 bytes read in 16 ms (3.9 MiB/s) ## Starting EFI application at 82000000 ... Scanning disks on usb... Scanning disks on mmc... MMC Device 2 not found MMC Device 3 not found Found 6 disks
OpenBSD/armv7 BOOTARM 0.9
boot> cannot open sd0a:/etc/random.seed: Device not configured booting sd0a:/bsd: open sd0a:/bsd: Device not configured failed(6). will try /bsd boot> cannot open sd0a:/etc/random.seed: Device not configured booting sd0a:/bsd: open sd0a:/bsd: Device not configured failed(6). will try /bsd Turning timeout off. boot> ls sd1a:/ stat(sd1a:/): Device not configured
To reproduce replace the existing MLO/u-boot.img in the FAT fs in https://ftp.openbsd.org/pub/OpenBSD/snapshots/armv7/miniroot-am335x-62.fs
Can you reproduce this on any aarch64 device? I don't have anything armv7 to try. (I guess the kernel won't actually boot on my db410c but at least it should get as far as trying if I could reproduce this on aarch64)
Dale Rahn was working on DragonBoard support and had a driver for the MSM UART but those changes are not currently in the tree/snapshots.
cool.. but I guess not really necessary to debug, as long as bootloader gets as far as trying to boot the kernel
I guess the openbsd bootloader is recognizing the "disks" differently now with more accurate devicepaths. Or maybe some hack that was used to make things work before with the non-standard dp's is causing problems now?
Same problem with the aarch64 rpi_3 target. The same efiboot binary works fine on U-Boot 2017.09 and the EDK2 based firmware on the OverDrive 1000.
*maybe* it could be a legacy vs DM thing.. there are differences in construction devicepaths for the two cases, and I don't really have a good way to test legacy. (And hopefully folks will hurry up and port legacy devices so we can simplify the efi_loader code.)
I'm not quite sure which category rpi3 falls into. But iirc Peter Robinson tested that with the efi_loader patches + grub2 + fedora and it all worked.
Maybe there is a way I can reproduce this in qemu?
BR, -R
Yes, the behaviour also occurs with the vexpress_ca15_tc2 target:
$ qemu-system-arm -m 1024 -M vexpress-a15 \ -kernel /usr/local/share/u-boot/vexpress_ca15_tc2/u-boot \ -sd miniroot-am335x-62.fs -serial stdio WARNING: Image format was not specified for 'miniroot-am335x-62.fs' and probing guessed raw. Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. Specify the 'raw' format explicitly to remove the restrictions.
U-Boot 2017.09 (Sep 12 2017 - 15:05:11 +1000)
DRAM: 1 GiB WARNING: Caches not enabled Flash: 128 MiB MMC: MMC: 0 *** Warning - bad CRC, using default environment
In: serial Out: serial Err: serial Net: smc911x-0 Hit any key to stop autoboot: 0 MMC Device 1 not found no mmc device at slot 1 switch to partitions #0, OK mmc0 is current device env - environment handling commands
Usage: env default [-f] -a - [forcibly] reset default environment env default [-f] var [...] - [forcibly] reset variable(s) to their default values env delete [-f] var [...] - [forcibly] delete variable(s) env export [-t | -b | -c] [-s size] addr [var ...] - export environment env import [-d] [-t [-r] | -b | -c] addr [size] - import environment env print [-a | name ...] - print environment env run var [...] - run commands in an environment variable env save - save environment env set [-f] name [arg ...]
Scanning mmc 0:1... Found EFI removable media binary efi/boot/bootarm.efi reading efi/boot/bootarm.efi 67372 bytes read in 113 ms (582 KiB/s) ## Starting EFI application at a0008000 ... WARNING: Invalid device tree, expect boot to fail Scanning disks on mmc... MMC Device 1 not found MMC Device 2 not found MMC Device 3 not found Found 1 disks
OpenBSD/armv7 BOOTARM 1.0
boot> cannot open sd0a:/etc/random.seed: No such file or directory booting sd0a:/bsd: 2305632+7989448+444512|[174378+90+319888+152368]=0xae1134 qemu-system-arm: terminating on signal 2
$ qemu-system-arm -m 1024 -M vexpress-a15 \ -kernel vexpress_ca15_tc2/u-boot \ -sd miniroot-am335x-62.fs -serial stdio WARNING: Image format was not specified for 'miniroot-am335x-62.fs' and probing guessed raw. Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. Specify the 'raw' format explicitly to remove the restrictions.
U-Boot 2017.11-rc1-00066-g4ac7de9239 (Oct 08 2017 - 00:07:26 +1100)
DRAM: 1 GiB WARNING: Caches not enabled Flash: 128 MiB MMC: MMC: 0 *** Warning - bad CRC, using default environment
In: serial Out: serial Err: serial Net: smc911x-0 Hit any key to stop autoboot: 0 MMC Device 1 not found no mmc device at slot 1 switch to partitions #0, OK mmc0 is current device env - environment handling commands
Usage: env default [-f] -a - [forcibly] reset default environment env default [-f] var [...] - [forcibly] reset variable(s) to their default values env delete [-f] var [...] - [forcibly] delete variable(s) env export [-t | -b | -c] [-s size] addr [var ...] - export environment env import [-d] [-t [-r] | -b | -c] addr [size] - import environment env print [-a | name ...] - print environment env run var [...] - run commands in an environment variable env save - save environment env set [-f] name [arg ...]
Scanning mmc 0:1... load - load binary file from a filesystem
Usage: load <interface> [<dev[:part]> [<addr> [<filename> [bytes [pos]]]]] - Load binary file 'filename' from partition 'part' on device type 'interface' instance 'dev' to address 'addr' in memory. 'bytes' gives the size to load in bytes. If 'bytes' is 0 or omitted, the file is read until the end. 'pos' gives the file byte position to start reading from. If 'pos' is 0 or omitted, the file is read from the start. Found EFI removable media binary efi/boot/bootarm.efi Scanning disks on mmc... MMC Device 1 not found MMC Device 2 not found MMC Device 3 not found Found 1 disks reading efi/boot/bootarm.efi 67372 bytes read in 55 ms (1.2 MiB/s) ## Starting EFI application at a0008000 ... WARNING: Invalid device tree, expect boot to fail
OpenBSD/armv7 BOOTARM 1.0
boot> cannot open sd0a:/etc/random.seed: Device not configured booting sd0a:/bsd: open sd0a:/bsd: Device not configured failed(6). will try /bsd boot> ls sd0a:/ stat(sd0a:/): Device not configured boot> ls sd1a:/ stat(sd1a:/): Device not configured boot> qemu-system-arm: terminating on signal 2
On Sat, Oct 7, 2017 at 1:23 PM, Rob Clark robdclark@gmail.com wrote:
On Fri, Oct 6, 2017 at 10:08 PM, Jonathan Gray jsg@jsg.id.au wrote:
On Fri, Oct 06, 2017 at 08:21:26AM -0400, Rob Clark wrote:
On Fri, Oct 6, 2017 at 12:35 AM, Jonathan Gray jsg@jsg.id.au wrote:
On Thu, Oct 05, 2017 at 05:05:49AM -0400, Rob Clark wrote:
On Thu, Oct 5, 2017 at 12:36 AM, Jonathan Gray jsg@jsg.id.au wrote:
On Wed, Oct 04, 2017 at 01:12:48PM -0400, Rob Clark wrote: > On Wed, Oct 4, 2017 at 12:29 PM, Fabio Estevam fabio.estevam@nxp.com wrote: > > Since commit ff98cb90514d ("part: extract MBR signature from partitions") > > SPL boot on i.MX6 starts to fail: > > > > U-Boot SPL 2017.09-00221-g0d6ab32 (Oct 02 2017 - 15:13:19) > > Trying to boot from MMC1 > > (keep in loop) > > > > Use the original allocation scheme for the SPL case, so that MX6 boards > > can boot again. > > > > This is a temporary solution to avoid the boot regression. > > > > Signed-off-by: Fabio Estevam fabio.estevam@nxp.com > > --- > > Hi Tom, > > > > I do not have time this week to further investigate and narrow down > > this problem. > > > > Using the old allocation scheme fixes the mx6 SPL boot problem. > > > > Hi Tom, if you are ok with this as a temporary fix, then this is: > > Acked-by: Rob Clark robdclark@gmail.com > > I'm getting some help from some of the fedora-arm folks so hopefully I > can get some idea what is going wrong, but I'd like to unblock folks > w/ mx6 boards.. > > BR, > -R
This does not seem to be a complete fix, cubox is still broken when U-Boot proper loads, unless the efi loader commits are to blame for introducing unaligned accesses.
Works with 2017.09.
U-Boot SPL 2017.11-rc1-00026-g14b55fc833 (Oct 05 2017 - 15:17:47) Trying to boot from MMC1
U-Boot 2017.11-rc1-00026-g14b55fc833 (Oct 05 2017 - 15:17:47 +1100)
CPU: Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz) CPU: Extended Commercial temperature grade (-20C to 105C) at 34C Reset cause: WDOG Board: MX6 Cubox-i DRAM: 2 GiB MMC: FSL_SDHC: 0 *** Warning - bad CRC, using default environment
No panel detected: default to HDMI Display: HDMI (1024x768) In: serial Out: serial Err: serial Net: FEC Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1...
I don't think any efi_loader code is running here, you would see a message like:
## Starting EFI application at XYZ
But to be sure you can disable CONFIG_EFI_LOADER in menuconfig to confirm.
I guess this is some unrelated change. I suspect Tom's change to malloc the fat_itr's which would make the buffers used for fs_exists()/etc not cache aligned. I thought there was a patch floating around to change that to memalign().
The imx6 problems still occur with CONFIG_EFI_LOADER disabled indeed.
I can no longer load a kernel via efi on bbb though:
U-Boot SPL 2017.11-rc1-00066-g4ac7de9239 (Oct 06 2017 - 14:21:51) Trying to boot from MMC1 reading u-boot.img reading u-boot.img
U-Boot 2017.11-rc1-00066-g4ac7de9239 (Oct 06 2017 - 14:21:51 +1100)
CPU : AM335X-GP rev 2.1 I2C: ready DRAM: 512 MiB No match for driver 'omap_hsmmc' No match for driver 'omap_hsmmc' Some drivers were not found MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 <ethaddr> not set. Validating first E-fuse MAC Net: cpsw, usb_ether Press SPACE to abort autoboot in 2 seconds switch to partitions #0, OK mmc0 is current device SD/MMC found on device 0 ** Unable to read file boot.scr ** ** Unable to read file uEnv.txt ** switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... reading /am335x-boneblack.dtb 35712 bytes read in 10 ms (3.4 MiB/s) Found EFI removable media binary efi/boot/bootarm.efi reading efi/boot/bootarm.efi 65448 bytes read in 16 ms (3.9 MiB/s) ## Starting EFI application at 82000000 ... Scanning disks on usb... Scanning disks on mmc... MMC Device 2 not found MMC Device 3 not found Found 6 disks
OpenBSD/armv7 BOOTARM 0.9
boot> cannot open sd0a:/etc/random.seed: Device not configured booting sd0a:/bsd: open sd0a:/bsd: Device not configured failed(6). will try /bsd boot> cannot open sd0a:/etc/random.seed: Device not configured booting sd0a:/bsd: open sd0a:/bsd: Device not configured failed(6). will try /bsd Turning timeout off. boot> ls sd1a:/ stat(sd1a:/): Device not configured
To reproduce replace the existing MLO/u-boot.img in the FAT fs in https://ftp.openbsd.org/pub/OpenBSD/snapshots/armv7/miniroot-am335x-62.fs
Can you reproduce this on any aarch64 device? I don't have anything armv7 to try. (I guess the kernel won't actually boot on my db410c but at least it should get as far as trying if I could reproduce this on aarch64)
Dale Rahn was working on DragonBoard support and had a driver for the MSM UART but those changes are not currently in the tree/snapshots.
cool.. but I guess not really necessary to debug, as long as bootloader gets as far as trying to boot the kernel
I guess the openbsd bootloader is recognizing the "disks" differently now with more accurate devicepaths. Or maybe some hack that was used to make things work before with the non-standard dp's is causing problems now?
Same problem with the aarch64 rpi_3 target. The same efiboot binary works fine on U-Boot 2017.09 and the EDK2 based firmware on the OverDrive 1000.
*maybe* it could be a legacy vs DM thing.. there are differences in construction devicepaths for the two cases, and I don't really have a good way to test legacy. (And hopefully folks will hurry up and port legacy devices so we can simplify the efi_loader code.)
I'm not quite sure which category rpi3 falls into. But iirc Peter Robinson tested that with the efi_loader patches + grub2 + fedora and it all worked.
The RPi doesn't use SPL as the firmware loads the u-boot directly.
Maybe there is a way I can reproduce this in qemu?
BR, -R
U-Boot is built with linaro gcc 6.3.2017.02
U-Boot 2017.11-rc1-00066-g4ac7de9239 (Oct 07 2017 - 12:44:27 +1100)
DRAM: 948 MiB RPI 3 Model B (0xa02082) MMC: sdhci@7e300000: 0 reading uboot.env In: serial Out: vidconsole Err: vidconsole Net: No ethernet found. starting USB... USB0: Core Release: 2.80a scanning bus 0 for devices... 4 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found Hit any key to stop autoboot: 0
Device 0: Vendor: SanDisk Rev: 1.00 Prod: Ultra Type: Removable Hard Disk Capacity: 29327.3 MB = 28.6 GB (60062500 x 512) ... is now current device Scanning usb 0:1... Found EFI removable media binary efi/boot/bootaa64.efi reading efi/boot/bootaa64.efi 78287 bytes read in 86 ms (888.7 KiB/s) ## Starting EFI application at 01000000 ... Scanning disk sdhci@7e300000.blk... Scanning disk usb_mass_storage.lun0... Found 2 disks
OpenBSD/arm64 BOOTAA64 0.8
boot> cannot open sd0a:/etc/random.seed: Device not configured booting sd0a:/bsd: open sd0a:/bsd: Device not configured failed(6). will try /bsd boot> cannot open sd0a:/etc/random.seed: Device not configured booting sd0a:/bsd: open sd0a:/bsd: Device not configured failed(6). will try /bsd Turning timeout off. boot> ls sd0a:/ stat(sd0a:/): Device not configured boot> ls sd1a:/ stat(sd1a:/): Device not configured boot>
U-Boot 2017.09 (Sep 12 2017 - 13:08:30 +1000)
DRAM: 948 MiB RPI 3 Model B (0xa02082) MMC: sdhci@7e300000: 0 reading uboot.env In: serial Out: vidconsole Err: vidconsole Net: No ethernet found. starting USB... USB0: Core Release: 2.80a scanning bus 0 for devices... 4 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found Hit any key to stop autoboot: 0
Device 0: Vendor: SanDisk Rev: 1.00 Prod: Ultra Type: Removable Hard Disk Capacity: 29327.3 MB = 28.6 GB (60062500 x 512) ... is now current device Scanning usb 0:1... Found EFI removable media binary efi/boot/bootaa64.efi reading efi/boot/bootaa64.efi 78287 bytes read in 76 ms (1005.9 KiB/s) ## Starting EFI application at 01000000 ... Scanning disk sdhci@7e300000.blk... Scanning disk usb_mass_storage.lun0... Found 2 disks
OpenBSD/arm64 BOOTAA64 0.8
boot> booting sd0a:/bsd: 3871708+578596+509352+803952[283845+96+451968+239920]=0x82f330 ...
U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Hi Jonathan,
On Thu, Oct 5, 2017 at 1:36 AM, Jonathan Gray jsg@jsg.id.au wrote:
This does not seem to be a complete fix, cubox is still broken when U-Boot proper loads, unless the efi loader commits are to blame for introducing unaligned accesses.
I cannot reproduce the problem on mx6q cubox:
U-Boot SPL 2017.11-rc1-00101-gafbdfd8 (Oct 07 2017 - 14:41:16) Trying to boot from MMC1
U-Boot 2017.11-rc1-00101-gafbdfd8 (Oct 07 2017 - 14:41:16 -0300)
CPU: Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz) CPU: Extended Commercial temperature grade (-20C to 105C) at 23C Reset cause: POR Board: MX6 Cubox-i DRAM: 2 GiB MMC: FSL_SDHC: 0 No panel detected: default to HDMI Display: HDMI (1024x768) In: serial Out: serial Err: serial Net: FEC Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 336 bytes read in 70 ms (3.9 KiB/s) ## Executing script at 12000000 37669 bytes read in 69 ms (532.2 KiB/s) 6378872 bytes read in 361 ms (16.9 MiB/s) ## Flattened Device Tree blob at 18000000 Booting using the fdt blob at 0x18000000 Using Device Tree in place at 18000000, end 1800c324
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0
On Sat, Oct 07, 2017 at 02:46:04PM -0300, Fabio Estevam wrote:
Hi Jonathan,
On Thu, Oct 5, 2017 at 1:36 AM, Jonathan Gray jsg@jsg.id.au wrote:
This does not seem to be a complete fix, cubox is still broken when U-Boot proper loads, unless the efi loader commits are to blame for introducing unaligned accesses.
I cannot reproduce the problem on mx6q cubox:
I wonder if you have the same kind of fat filesystem.
Can you try writing https://ftp.openbsd.org/pub/OpenBSD/snapshots/armv7/miniroot-cubox-62.fs to an sd card then write a new SPL/U-Boot at the standard raw offsets?
The disk image has:
# fdisk vnd0 Disk: vnd0 geometry: 368/1/100 [36864 Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H S [ start: size ] ------------------------------------------------------------------------------- *0: 0C 20 0 49 - 61 0 44 [ 2048: 4096 ] FAT32L 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 3: A6 61 0 45 - 368 0 64 [ 6144: 30720 ] OpenBSD
# disklabel vnd0 # /dev/rvnd0c: type: vnd disk: vnd device label: fictitious duid: 0067acdd9b2c9bc1 flags: bytes/sector: 512 sectors/track: 256 tracks/cylinder: 16 sectors/cylinder: 4096 cylinders: 9 total sectors: 36864 boundstart: 6144 boundend: 36864 drivedata: 0
16 partitions: # size offset fstype [fsize bsize cpg] a: 30720 6144 4.2BSD 2048 16384 240 c: 36864 0 unused i: 4096 2048 MSDOS
U-Boot SPL 2017.11-rc1-00101-gafbdfd8 (Oct 07 2017 - 14:41:16) Trying to boot from MMC1
U-Boot 2017.11-rc1-00101-gafbdfd8 (Oct 07 2017 - 14:41:16 -0300)
CPU: Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz) CPU: Extended Commercial temperature grade (-20C to 105C) at 23C Reset cause: POR Board: MX6 Cubox-i DRAM: 2 GiB MMC: FSL_SDHC: 0 No panel detected: default to HDMI Display: HDMI (1024x768) In: serial Out: serial Err: serial Net: FEC Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 336 bytes read in 70 ms (3.9 KiB/s) ## Executing script at 12000000 37669 bytes read in 69 ms (532.2 KiB/s) 6378872 bytes read in 361 ms (16.9 MiB/s) ## Flattened Device Tree blob at 18000000 Booting using the fdt blob at 0x18000000 Using Device Tree in place at 18000000, end 1800c324
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0
On Sat, Oct 7, 2017 at 10:06 PM, Jonathan Gray jsg@jsg.id.au wrote:
I wonder if you have the same kind of fat filesystem.
No, I have only used ext4 file system.
Can you try writing https://ftp.openbsd.org/pub/OpenBSD/snapshots/armv7/miniroot-cubox-62.fs to an sd card then write a new SPL/U-Boot at the standard raw offsets?
Maybe it will be easier if you try a 'git bisect' to find out where the regression is coming from.
On Sun, Oct 08, 2017 at 09:56:15AM -0300, Fabio Estevam wrote:
On Sat, Oct 7, 2017 at 10:06 PM, Jonathan Gray jsg@jsg.id.au wrote:
I wonder if you have the same kind of fat filesystem.
No, I have only used ext4 file system.
Can you try writing https://ftp.openbsd.org/pub/OpenBSD/snapshots/armv7/miniroot-cubox-62.fs to an sd card then write a new SPL/U-Boot at the standard raw offsets?
Maybe it will be easier if you try a 'git bisect' to find out where the regression is coming from.
It turns out to be
commit 2460098cffacd18729262e3ed36656e6943783ed Author: Tom Rini trini@konsulko.com Date: Fri Sep 22 07:37:43 2017 -0400
fs/fat: Reduce stack usage
We have limited stack in SPL builds. Drop itrblock and move to malloc/free of itr to move this off of the stack. As part of this fix a double-free issue in fat_size().
Signed-off-by: Tom Rini trini@konsulko.com --- Rework to use malloc/free as moving this to a global overflows some SH targets.
fs/fat/fat.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-)
With that reverted I just get the efi loader problem, no alignment errors.
On Sun, Oct 8, 2017 at 11:04 AM, Jonathan Gray jsg@jsg.id.au wrote:
It turns out to be
commit 2460098cffacd18729262e3ed36656e6943783ed Author: Tom Rini trini@konsulko.com Date: Fri Sep 22 07:37:43 2017 -0400
fs/fat: Reduce stack usage We have limited stack in SPL builds. Drop itrblock and move to malloc/free of itr to move this off of the stack. As part of this fix a double-free issue in fat_size(). Signed-off-by: Tom Rini <trini@konsulko.com> --- Rework to use malloc/free as moving this to a global overflows some SH targets.fs/fat/fat.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-)
With that reverted I just get the efi loader problem, no alignment errors.
Thanks for doing the bisect.
Tom, can you prepare a fix for this?
On Sun, Oct 08, 2017 at 10:56:26PM -0300, Fabio Estevam wrote:
On Sun, Oct 8, 2017 at 11:04 AM, Jonathan Gray jsg@jsg.id.au wrote:
It turns out to be
commit 2460098cffacd18729262e3ed36656e6943783ed Author: Tom Rini trini@konsulko.com Date: Fri Sep 22 07:37:43 2017 -0400
fs/fat: Reduce stack usage We have limited stack in SPL builds. Drop itrblock and move to malloc/free of itr to move this off of the stack. As part of this fix a double-free issue in fat_size(). Signed-off-by: Tom Rini <trini@konsulko.com> --- Rework to use malloc/free as moving this to a global overflows some SH targets.fs/fat/fat.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-)
With that reverted I just get the efi loader problem, no alignment errors.
Thanks for doing the bisect.
Tom, can you prepare a fix for this?
No, this is a required fix for other platforms. Why is this failing in the particular case that it's failing in?
On Sun, Oct 08, 2017 at 11:12:28PM -0400, Tom Rini wrote:
On Sun, Oct 08, 2017 at 10:56:26PM -0300, Fabio Estevam wrote:
On Sun, Oct 8, 2017 at 11:04 AM, Jonathan Gray jsg@jsg.id.au wrote:
It turns out to be
commit 2460098cffacd18729262e3ed36656e6943783ed Author: Tom Rini trini@konsulko.com Date: Fri Sep 22 07:37:43 2017 -0400
fs/fat: Reduce stack usage We have limited stack in SPL builds. Drop itrblock and move to malloc/free of itr to move this off of the stack. As part of this fix a double-free issue in fat_size(). Signed-off-by: Tom Rini <trini@konsulko.com> --- Rework to use malloc/free as moving this to a global overflows some SH targets.fs/fat/fat.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-)
With that reverted I just get the efi loader problem, no alignment errors.
Thanks for doing the bisect.
Tom, can you prepare a fix for this?
No, this is a required fix for other platforms. Why is this failing in the particular case that it's failing in?
Switching the malloc calls for malloc_cache_aligned also avoids the problem.
U-Boot SPL 2017.11-rc1-00026-g14b55fc833 (Oct 05 2017 - 15:17:47) Trying to boot from MMC1
U-Boot 2017.11-rc1-00026-g14b55fc833 (Oct 05 2017 - 15:17:47 +1100)
CPU: Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz) CPU: Extended Commercial temperature grade (-20C to 105C) at 34C Reset cause: WDOG Board: MX6 Cubox-i DRAM: 2 GiB MMC: FSL_SDHC: 0 *** Warning - bad CRC, using default environment
No panel detected: default to HDMI Display: HDMI (1024x768) In: serial Out: serial Err: serial Net: FEC Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... CACHE: Misaligned operation at range [8f89da30, 8f89e230] CACHE: Misaligned operation at range [8f89da30, 8f89e230] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89da30 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e230 CACHE: Misaligned operation at range [8f89da30, 8f89e230] CACHE: Misaligned operation at range [8f89da30, 8f89e230] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89da30 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e230 CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0] CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0] CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0] CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0] CACHE: Misaligned operation at range [8f89dc68, 8f89e468] CACHE: Misaligned operation at range [8f89dc68, 8f89e468] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dc68 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e468 CACHE: Misaligned operation at range [8f89dc68, 8f89e468] CACHE: Misaligned operation at range [8f89dc68, 8f89e468] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dc68 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e468 CACHE: Misaligned operation at range [8f89dab0, 8f89e2b0] CACHE: Misaligned operation at range [8f89dab0, 8f89e2b0] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dab0 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e2b0 CACHE: Misaligned operation at range [8f89dab0, 8f89e2b0] CACHE: Misaligned operation at range [8f89dab0, 8f89e2b0] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dab0 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e2b0 CACHE: Misaligned operation at range [8f89dca8, 8f89e4a8] CACHE: Misaligned operation at range [8f89dca8, 8f89e4a8] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dca8 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e4a8 CACHE: Misaligned operation at range [8f89dca8, 8f89e4a8] CACHE: Misaligned operation at range [8f89dca8, 8f89e4a8] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dca8 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e4a8 CACHE: Misaligned operation at range [8f89dc70, 8f89e470] CACHE: Misaligned operation at range [8f89dc70, 8f89e470] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dc70 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e470 CACHE: Misaligned operation at range [8f89dc70, 8f89e470] CACHE: Misaligned operation at range [8f89dc70, 8f89e470] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dc70 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e470 CACHE: Misaligned operation at range [8f89e488, 8f89ec88] CACHE: Misaligned operation at range [8f89e488, 8f89ec88] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89e488 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89ec88 CACHE: Misaligned operation at range [8f89e488, 8f89ec88] CACHE: Misaligned operation at range [8f89e488, 8f89ec88] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89e488 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89ec88 CACHE: Misaligned operation at range [8f89e470, 8f89ec70] CACHE: Misaligned operation at range [8f89e470, 8f89ec70] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89e470 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89ec70 CACHE: Misaligned operation at range [8f89e470, 8f89ec70] CACHE: Misaligned operation at range [8f89e470, 8f89ec70] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89e470 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89ec70 CACHE: Misaligned operation at range [8f89e488, 8f89ec88] CACHE: Misaligned operation at range [8f89e488, 8f89ec88] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89e488 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89ec88 CACHE: Misaligned operation at range [8f89e488, 8f89ec88] CACHE: Misaligned operation at range [8f89e488, 8f89ec88] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89e488 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89ec88 CACHE: Misaligned operation at range [8f89e438, 8f89ec38] CACHE: Misaligned operation at range [8f89e438, 8f89ec38] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89e438 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89ec38 CACHE: Misaligned operation at range [8f89e438, 8f89ec38] CACHE: Misaligned operation at range [8f89e438, 8f89ec38] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89e438 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89ec38 AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl SATA mode flags: ncq stag pm led clo only pmp pio slum part No port device detected!
Device 0: Model: Firm: Ser#: Type: Hard Disk Capacity: not available ... is now current device ** Bad device size - sata 0 ** starting USB... USB0: Port not available. USB1: USB EHCI 1.00 scanning bus 1 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found
Device 0: device type unknown ... is now current device ** Bad device usb 0 ** ** Bad device usb 0 **
U-Boot SPL 2017.11-rc1-00111-g3e161bd647-dirty (Oct 09 2017 - 17:03:13) Trying to boot from MMC1
U-Boot 2017.11-rc1-00111-g3e161bd647-dirty (Oct 09 2017 - 17:03:13 +1100)
CPU: Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz) CPU: Extended Commercial temperature grade (-20C to 105C) at 48C Reset cause: POR Board: MX6 Cubox-i DRAM: 2 GiB MMC: FSL_SDHC: 0 No panel detected: default to HDMI Display: HDMI (1024x768) In: serial Out: serial Err: serial Net: FEC Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... reading /imx6q-cubox-i.dtb 37669 bytes read in 20 ms (1.8 MiB/s) Found EFI removable media binary efi/boot/bootarm.efi Scanning disks on usb... Scanning disks on mmc... MMC Device 1 not found MMC Device 2 not found MMC Device 3 not found Scanning disks on sata... Found 6 disks reading efi/boot/bootarm.efi 67372 bytes read in 31 ms (2.1 MiB/s) ## Starting EFI application at 12000000 ...
OpenBSD/armv7 BOOTARM 1.0
boot> booting sd0a:/bsd: 3926840+164812+561396|[283058+90+521360+245040]=0x571a54 Writing to MMC(0)... done
OpenBSD/armv7 booting ... arg0 0xc0871a54 arg1 0x0 arg2 0x18000000 Allocating page tables freestart = 0x10872000, free_pages = 522126 (0x0007f78e) IRQ stack: p0x108a0000 v0xc08a0000 ABT stack: p0x108a1000 v0xc08a1000 UND stack: p0x108a2000 v0xc08a2000 SVC stack: p0x108a3000 v0xc08a3000 Creating L1 page table at 0x10874000 Mapping kernel Constructing L2 page tables undefined page pmap [ using 1050004 bytes of bsd ELF symbol table ] board type: 0 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2017 OpenBSD. All rights reserved. https://www.OpenBSD.org ...
diff --git a/fs/fat/fat.c b/fs/fat/fat.c index 3d3e17e8fa..d299f317a9 100644 --- a/fs/fat/fat.c +++ b/fs/fat/fat.c @@ -1038,7 +1038,7 @@ int fat_exists(const char *filename) fat_itr *itr; int ret;
- itr = malloc(sizeof(fat_itr)); + itr = malloc_cache_aligned(sizeof(fat_itr)); ret = fat_itr_root(itr, &fsdata); if (ret) return 0; @@ -1055,7 +1055,7 @@ int fat_size(const char *filename, loff_t *size) fat_itr *itr; int ret;
- itr = malloc(sizeof(fat_itr)); + itr = malloc_cache_aligned(sizeof(fat_itr)); ret = fat_itr_root(itr, &fsdata); if (ret) return ret; @@ -1089,7 +1089,7 @@ int file_fat_read_at(const char *filename, loff_t pos, void *buffer, fat_itr *itr; int ret;
- itr = malloc(sizeof(fat_itr)); + itr = malloc_cache_aligned(sizeof(fat_itr)); ret = fat_itr_root(itr, &fsdata); if (ret) return ret;
On Mon, Oct 09, 2017 at 05:19:53PM +1100, Jonathan Gray wrote:
On Sun, Oct 08, 2017 at 11:12:28PM -0400, Tom Rini wrote:
On Sun, Oct 08, 2017 at 10:56:26PM -0300, Fabio Estevam wrote:
On Sun, Oct 8, 2017 at 11:04 AM, Jonathan Gray jsg@jsg.id.au wrote:
It turns out to be
commit 2460098cffacd18729262e3ed36656e6943783ed Author: Tom Rini trini@konsulko.com Date: Fri Sep 22 07:37:43 2017 -0400
fs/fat: Reduce stack usage We have limited stack in SPL builds. Drop itrblock and move to malloc/free of itr to move this off of the stack. As part of this fix a double-free issue in fat_size(). Signed-off-by: Tom Rini <trini@konsulko.com> --- Rework to use malloc/free as moving this to a global overflows some SH targets.fs/fat/fat.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-)
With that reverted I just get the efi loader problem, no alignment errors.
Thanks for doing the bisect.
Tom, can you prepare a fix for this?
No, this is a required fix for other platforms. Why is this failing in the particular case that it's failing in?
Switching the malloc calls for malloc_cache_aligned also avoids the problem.
Ah, good one. Can you please submit this as a proper patch? Thanks!
U-Boot SPL 2017.11-rc1-00026-g14b55fc833 (Oct 05 2017 - 15:17:47) Trying to boot from MMC1
U-Boot 2017.11-rc1-00026-g14b55fc833 (Oct 05 2017 - 15:17:47 +1100)
CPU: Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz) CPU: Extended Commercial temperature grade (-20C to 105C) at 34C Reset cause: WDOG Board: MX6 Cubox-i DRAM: 2 GiB MMC: FSL_SDHC: 0 *** Warning - bad CRC, using default environment
No panel detected: default to HDMI Display: HDMI (1024x768) In: serial Out: serial Err: serial Net: FEC Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... CACHE: Misaligned operation at range [8f89da30, 8f89e230] CACHE: Misaligned operation at range [8f89da30, 8f89e230] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89da30 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e230 CACHE: Misaligned operation at range [8f89da30, 8f89e230] CACHE: Misaligned operation at range [8f89da30, 8f89e230] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89da30 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e230 CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0] CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0] CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0] CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0] CACHE: Misaligned operation at range [8f89dc68, 8f89e468] CACHE: Misaligned operation at range [8f89dc68, 8f89e468] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dc68 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e468 CACHE: Misaligned operation at range [8f89dc68, 8f89e468] CACHE: Misaligned operation at range [8f89dc68, 8f89e468] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dc68 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e468 CACHE: Misaligned operation at range [8f89dab0, 8f89e2b0] CACHE: Misaligned operation at range [8f89dab0, 8f89e2b0] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dab0 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e2b0 CACHE: Misaligned operation at range [8f89dab0, 8f89e2b0] CACHE: Misaligned operation at range [8f89dab0, 8f89e2b0] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dab0 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e2b0 CACHE: Misaligned operation at range [8f89dca8, 8f89e4a8] CACHE: Misaligned operation at range [8f89dca8, 8f89e4a8] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dca8 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e4a8 CACHE: Misaligned operation at range [8f89dca8, 8f89e4a8] CACHE: Misaligned operation at range [8f89dca8, 8f89e4a8] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dca8 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e4a8 CACHE: Misaligned operation at range [8f89dc70, 8f89e470] CACHE: Misaligned operation at range [8f89dc70, 8f89e470] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dc70 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e470 CACHE: Misaligned operation at range [8f89dc70, 8f89e470] CACHE: Misaligned operation at range [8f89dc70, 8f89e470] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dc70 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e470 CACHE: Misaligned operation at range [8f89e488, 8f89ec88] CACHE: Misaligned operation at range [8f89e488, 8f89ec88] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89e488 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89ec88 CACHE: Misaligned operation at range [8f89e488, 8f89ec88] CACHE: Misaligned operation at range [8f89e488, 8f89ec88] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89e488 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89ec88 CACHE: Misaligned operation at range [8f89e470, 8f89ec70] CACHE: Misaligned operation at range [8f89e470, 8f89ec70] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89e470 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89ec70 CACHE: Misaligned operation at range [8f89e470, 8f89ec70] CACHE: Misaligned operation at range [8f89e470, 8f89ec70] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89e470 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89ec70 CACHE: Misaligned operation at range [8f89e488, 8f89ec88] CACHE: Misaligned operation at range [8f89e488, 8f89ec88] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89e488 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89ec88 CACHE: Misaligned operation at range [8f89e488, 8f89ec88] CACHE: Misaligned operation at range [8f89e488, 8f89ec88] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89e488 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89ec88 CACHE: Misaligned operation at range [8f89e438, 8f89ec38] CACHE: Misaligned operation at range [8f89e438, 8f89ec38] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89e438 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89ec38 CACHE: Misaligned operation at range [8f89e438, 8f89ec38] CACHE: Misaligned operation at range [8f89e438, 8f89ec38] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89e438 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89ec38 AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl SATA mode flags: ncq stag pm led clo only pmp pio slum part No port device detected!
Device 0: Model: Firm: Ser#: Type: Hard Disk Capacity: not available ... is now current device ** Bad device size - sata 0 ** starting USB... USB0: Port not available. USB1: USB EHCI 1.00 scanning bus 1 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found
Device 0: device type unknown ... is now current device ** Bad device usb 0 ** ** Bad device usb 0 **
U-Boot SPL 2017.11-rc1-00111-g3e161bd647-dirty (Oct 09 2017 - 17:03:13) Trying to boot from MMC1
U-Boot 2017.11-rc1-00111-g3e161bd647-dirty (Oct 09 2017 - 17:03:13 +1100)
CPU: Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz) CPU: Extended Commercial temperature grade (-20C to 105C) at 48C Reset cause: POR Board: MX6 Cubox-i DRAM: 2 GiB MMC: FSL_SDHC: 0 No panel detected: default to HDMI Display: HDMI (1024x768) In: serial Out: serial Err: serial Net: FEC Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... reading /imx6q-cubox-i.dtb 37669 bytes read in 20 ms (1.8 MiB/s) Found EFI removable media binary efi/boot/bootarm.efi Scanning disks on usb... Scanning disks on mmc... MMC Device 1 not found MMC Device 2 not found MMC Device 3 not found Scanning disks on sata... Found 6 disks reading efi/boot/bootarm.efi 67372 bytes read in 31 ms (2.1 MiB/s) ## Starting EFI application at 12000000 ...
OpenBSD/armv7 BOOTARM 1.0
boot> booting sd0a:/bsd: 3926840+164812+561396|[283058+90+521360+245040]=0x571a54 Writing to MMC(0)... done
OpenBSD/armv7 booting ... arg0 0xc0871a54 arg1 0x0 arg2 0x18000000 Allocating page tables freestart = 0x10872000, free_pages = 522126 (0x0007f78e) IRQ stack: p0x108a0000 v0xc08a0000 ABT stack: p0x108a1000 v0xc08a1000 UND stack: p0x108a2000 v0xc08a2000 SVC stack: p0x108a3000 v0xc08a3000 Creating L1 page table at 0x10874000 Mapping kernel Constructing L2 page tables undefined page pmap [ using 1050004 bytes of bsd ELF symbol table ] board type: 0 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2017 OpenBSD. All rights reserved. https://www.OpenBSD.org ...
diff --git a/fs/fat/fat.c b/fs/fat/fat.c index 3d3e17e8fa..d299f317a9 100644 --- a/fs/fat/fat.c +++ b/fs/fat/fat.c @@ -1038,7 +1038,7 @@ int fat_exists(const char *filename) fat_itr *itr; int ret;
- itr = malloc(sizeof(fat_itr));
- itr = malloc_cache_aligned(sizeof(fat_itr)); ret = fat_itr_root(itr, &fsdata); if (ret) return 0;
@@ -1055,7 +1055,7 @@ int fat_size(const char *filename, loff_t *size) fat_itr *itr; int ret;
- itr = malloc(sizeof(fat_itr));
- itr = malloc_cache_aligned(sizeof(fat_itr)); ret = fat_itr_root(itr, &fsdata); if (ret) return ret;
@@ -1089,7 +1089,7 @@ int file_fat_read_at(const char *filename, loff_t pos, void *buffer, fat_itr *itr; int ret;
- itr = malloc(sizeof(fat_itr));
- itr = malloc_cache_aligned(sizeof(fat_itr)); ret = fat_itr_root(itr, &fsdata); if (ret) return ret;
On Wed, Oct 4, 2017 at 5:29 PM, Fabio Estevam fabio.estevam@nxp.com wrote:
Since commit ff98cb90514d ("part: extract MBR signature from partitions") SPL boot on i.MX6 starts to fail:
U-Boot SPL 2017.09-00221-g0d6ab32 (Oct 02 2017 - 15:13:19) Trying to boot from MMC1 (keep in loop)
Use the original allocation scheme for the SPL case, so that MX6 boards can boot again.
This is a temporary solution to avoid the boot regression.
Signed-off-by: Fabio Estevam fabio.estevam@nxp.com
Tested-by: Peter Robinson pbrobinson@gmail.com
Tested on both a wandboard quad and a hummingboard2 (mx6cuboxi) and it works for me.
Peter
Hi Tom,
I do not have time this week to further investigate and narrow down this problem.
Using the old allocation scheme fixes the mx6 SPL boot problem.
disk/part_dos.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/disk/part_dos.c b/disk/part_dos.c index 1a36be0..6dd2c2d 100644 --- a/disk/part_dos.c +++ b/disk/part_dos.c @@ -89,6 +89,7 @@ static int test_block_type(unsigned char *buffer)
static int part_test_dos(struct blk_desc *dev_desc) { +#ifndef CONFIG_SPL_BUILD ALLOC_CACHE_ALIGN_BUFFER(legacy_mbr, mbr, dev_desc->blksz);
if (blk_dread(dev_desc, 0, 1, (ulong *)mbr) != 1)@@ -102,6 +103,15 @@ static int part_test_dos(struct blk_desc *dev_desc) dev_desc->sig_type = SIG_TYPE_MBR; dev_desc->mbr_sig = mbr->unique_mbr_signature; } +#else
ALLOC_CACHE_ALIGN_BUFFER(unsigned char, buffer, dev_desc->blksz);if (blk_dread(dev_desc, 0, 1, (ulong *)buffer) != 1)return -1;if (test_block_type(buffer) != DOS_MBR)return -1;+#endif
return 0;}
2.7.4
U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
On Wed, Oct 04, 2017 at 01:29:57PM -0300, Fabio Estevam wrote:
Since commit ff98cb90514d ("part: extract MBR signature from partitions") SPL boot on i.MX6 starts to fail:
U-Boot SPL 2017.09-00221-g0d6ab32 (Oct 02 2017 - 15:13:19) Trying to boot from MMC1 (keep in loop)
Use the original allocation scheme for the SPL case, so that MX6 boards can boot again.
This is a temporary solution to avoid the boot regression.
Signed-off-by: Fabio Estevam fabio.estevam@nxp.com Acked-by: Rob Clark robdclark@gmail.com Tested-by: Peter Robinson pbrobinson@gmail.com
Applied to u-boot/master, thanks!
participants (6)
-
Fabio Estevam -
Fabio Estevam -
Jonathan Gray -
Peter Robinson -
Rob Clark -
Tom Rini