Message ID | 1507134597-6831-1-git-send-email-fabio.estevam@nxp.com |
---|---|
State | Accepted |
Commit | 3ea0520512089cffbe02b7d6eb645cdfddb09c5c |
Delegated to: | Tom Rini |
Headers | show |
Series | [U-Boot] disk: part_dos: Use the original allocation scheme for the SPL case | expand |
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 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!
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
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 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
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;
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; }
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(+)