[U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case

[U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case

[Fabio Estevam]

Since commit ff98cb90514d ("part: extract MBR signature from partitions")
SPL boot on i.MX6 starts to fail:

U-Boot SPL 2017.09-00221-g0d6ab32 (Oct 02 2017 - 15:13:19)
Trying to boot from MMC1
(keep in loop)

Use the original allocation scheme for the SPL case, so that MX6 boards
can boot again.

This is a temporary solution to avoid the boot regression.

Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
Hi Tom,

I do not have time this week to further investigate and narrow down 
this problem.

Using the old allocation scheme fixes the mx6 SPL boot problem.


 disk/part_dos.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/disk/part_dos.c b/disk/part_dos.c
index 1a36be0..6dd2c2d 100644
--- a/disk/part_dos.c
+++ b/disk/part_dos.c
@@ -89,6 +89,7 @@ static int test_block_type(unsigned char *buffer)
 
 static int part_test_dos(struct blk_desc *dev_desc)
 {
+#ifndef CONFIG_SPL_BUILD
 	ALLOC_CACHE_ALIGN_BUFFER(legacy_mbr, mbr, dev_desc->blksz);
 
 	if (blk_dread(dev_desc, 0, 1, (ulong *)mbr) != 1)
@@ -102,6 +103,15 @@ static int part_test_dos(struct blk_desc *dev_desc)
 		dev_desc->sig_type = SIG_TYPE_MBR;
 		dev_desc->mbr_sig = mbr->unique_mbr_signature;
 	}
+#else
+	ALLOC_CACHE_ALIGN_BUFFER(unsigned char, buffer, dev_desc->blksz);
+
+	if (blk_dread(dev_desc, 0, 1, (ulong *)buffer) != 1)
+		return -1;
+
+	if (test_block_type(buffer) != DOS_MBR)
+		return -1;
+#endif
 
 	return 0;
 }
-- 
2.7.4

[U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case

[Rob Clark]

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
>

[U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case

[Jonathan Gray]

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 **

[U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case

[Rob Clark]

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 **

[U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case

[Jonathan Gray]

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
...

[U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case

[Rob Clark]

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
> ...

[U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case

[Rob Clark]

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 at 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 at 07864000.blk for environment...
Found uboot.env on sdhci at 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 at 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

[U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case

[Jonathan Gray]

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 at 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 at 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 at 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 at 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] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case

[Rob Clark]

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 at 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 at 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 at 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 at 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] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case

[Jonathan Gray]

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

[U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case

[Peter Robinson]

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 at 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 at 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 at 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 at 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 at lists.denx.de
> https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case

[Fabio Estevam]

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

[U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case

[Jonathan Gray]

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

[U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case

[Fabio Estevam]

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.

[U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case

[Jonathan Gray]

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.

[U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case

[Fabio Estevam]

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?

[U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case

[Tom Rini]

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?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171008/71018eda/attachment.sig>

[U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case

[Jonathan Gray]

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;

[U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case

[Tom Rini]

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;

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171009/92c98afd/attachment.sig>

[U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case

[Peter Robinson]

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 at lists.denx.de
> https://lists.denx.de/listinfo/u-boot

[U-Boot] disk: part_dos: Use the original allocation scheme for the SPL case

[Tom Rini]

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!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171005/8747c24b/attachment.sig>