disk: part_dos: Use the original allocation scheme for the SPL case

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

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

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

This is a temporary solution to avoid the boot regression.

Signed-off-by Fabio Estevam <[email protected]>

---
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(+)

disk/part_dos.c +10 -1

index 1a36be0..6dd2c2d 100644
@@ -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

Quoted 12 lines · 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.

Quoted 9 lines

Signed-off-by Fabio Estevam <[email protected]>

---
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 <[email protected]>

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

Quoted 25 lines · Rob Clark

Quoted 12 lines · 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.

Quoted 9 lines

Signed-off-by Fabio Estevam <[email protected]>

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

Quoted 8 lines

Acked-by Rob Clark <[email protected]>

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

Quoted 62 lines · Jonathan Gray

Quoted 25 lines · Rob Clark

Quoted 12 lines · 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.

Quoted 9 lines

Signed-off-by Fabio Estevam <[email protected]>

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

Quoted 8 lines

Acked-by Rob Clark <[email protected]>

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

Quoted 3 lines

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

Quoted 1 line

OpenBSD/armv7 BOOTARM 0.9

Quoted 1 line

OpenBSD/armv7 BOOTARM 0.9

Quoted 69 lines · Rob Clark

Quoted 62 lines · Jonathan Gray

Quoted 25 lines · Rob Clark

Quoted 12 lines · 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.

Quoted 9 lines

Signed-off-by Fabio Estevam <[email protected]>

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

Quoted 8 lines

Acked-by Rob Clark <[email protected]>

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

Quoted 3 lines

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:

Quoted 8 lines

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

Quoted 1 line

Quoted 1 line

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

Quoted 1 line

Quoted 1 line

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

Quoted 133 lines · Jonathan Gray

Quoted 69 lines · Rob Clark

Quoted 62 lines · Jonathan Gray

Quoted 25 lines · Rob Clark

Quoted 12 lines · 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.

Quoted 9 lines

Signed-off-by Fabio Estevam <[email protected]>

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

Quoted 8 lines

Acked-by Rob Clark <[email protected]>

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

Quoted 3 lines

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:

Quoted 8 lines

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

Quoted 1 line

Quoted 1 line

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

Quoted 2 lines

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?

Quoted 1 line

OpenBSD/arm64 BOOTAA64 0.8

Quoted 133 lines · Jonathan Gray

Quoted 69 lines · Rob Clark

Quoted 62 lines · Jonathan Gray

Quoted 25 lines · Rob Clark

Quoted 12 lines · 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.

Quoted 9 lines

Signed-off-by Fabio Estevam <[email protected]>

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

Quoted 8 lines

Acked-by Rob Clark <[email protected]>

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

Quoted 3 lines

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:

Quoted 8 lines

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

Quoted 1 line

Quoted 1 line

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

Quoted 2 lines

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?

Quoted 1 line

OpenBSD/arm64 BOOTAA64 0.8

Quoted 1 line

OpenBSD/arm64 BOOTAA64 0.8

Quoted 137 lines · Rob Clark

Quoted 135 lines · Jonathan Gray

Quoted 69 lines · Rob Clark

Quoted 62 lines · Jonathan Gray

Quoted 25 lines · Rob Clark

Quoted 12 lines · 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.

Quoted 9 lines

Signed-off-by Fabio Estevam <[email protected]>

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

Quoted 8 lines

Acked-by Rob Clark <[email protected]>

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

Quoted 3 lines

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:

Quoted 8 lines

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

Quoted 1 line

Quoted 1 line

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

Quoted 4 lines

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.

Quoted 5 lines

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

Quoted 1 line

Quoted 1 line

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

Quoted 1 line

Quoted 1 line

OpenBSD/arm64 BOOTAA64 0.8

boot>
booting sd0a:/bsd: 3871708+578596+509352+803952\[283845+96+451968+239920]=0x82f330
...

Quoted 138 lines · Jonathan Gray

Quoted 137 lines · Rob Clark

Quoted 135 lines · Jonathan Gray

Quoted 69 lines · Rob Clark

Quoted 62 lines · Jonathan Gray

Quoted 25 lines · Rob Clark

Quoted 12 lines · 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.

Quoted 9 lines

Signed-off-by Fabio Estevam <[email protected]>

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

Quoted 8 lines

Acked-by Rob Clark <[email protected]>

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

Quoted 3 lines

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:

Quoted 8 lines

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

Quoted 1 line

Quoted 1 line

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

Quoted 7 lines

Quoted 4 lines

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

Quoted 9 lines

Quoted 5 lines

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

Quoted 1 line

OpenBSD/armv7 BOOTARM 1.0

Quoted 1 line

OpenBSD/armv7 BOOTARM 1.0

Quoted 138 lines · Jonathan Gray

Quoted 137 lines · Rob Clark

Quoted 135 lines · Jonathan Gray

Quoted 69 lines · Rob Clark

Quoted 62 lines · Jonathan Gray

Quoted 25 lines · Rob Clark

Quoted 12 lines · 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.

Quoted 9 lines

Signed-off-by Fabio Estevam <[email protected]>

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

Quoted 8 lines

Acked-by Rob Clark <[email protected]>

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

Quoted 3 lines

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:

Quoted 8 lines

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

Quoted 1 line

Quoted 1 line

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

Quoted 7 lines

Quoted 4 lines

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

Quoted 9 lines

Quoted 5 lines

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

Quoted 74 lines

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

Quoted 1 line

Quoted 1 line

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

Quoted 4 lines

Quoted 1 line

Quoted 1 line

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

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.

Hi Jonathan,

Quoted 3 lines · Jonathan Gray

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

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?

Quoted 1 line · Jonathan Gray

I wonder if you have the same kind of fat filesystem.

No, I have only used ext4 file system.

Quoted 3 lines

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 <[email protected]>
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 <[email protected]>

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

Quoted 17 lines · Jonathan Gray

It turns out to be

commit 2460098cffacd18729262e3ed36656e6943783ed

Author: Tom Rini <[email protected]>
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 <[email protected]>

---
Rework to use malloc/free as moving this to a global overflows some SH targets.

Quoted 4 lines

 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?

Quoted 22 lines · Fabio Estevam

Quoted 20 lines · Jonathan Gray

It turns out to be

commit 2460098cffacd18729262e3ed36656e6943783ed

Author: Tom Rini <[email protected]>
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 <[email protected]>

---
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(-)

Quoted 5 lines

Quoted 1 line

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?

Quoted 1 line

OpenBSD/armv7 BOOTARM 1.0

Quoted 25 lines · Tom Rini

Quoted 24 lines · Fabio Estevam

Quoted 21 lines · Jonathan Gray

It turns out to be

commit 2460098cffacd18729262e3ed36656e6943783ed

Author: Tom Rini <[email protected]>
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 <[email protected]>

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

Quoted 6 lines

Quoted 3 lines

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

Quoted 1 line

Quoted 1 line

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

fs/fat/fat.c +3 -3

index 3d3e17e8fa..d299f317a9 100644
@@ -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;

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 <[email protected]>

---
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(+)

disk/part_dos.c +10 -1

index 1a36be0..6dd2c2d 100644
@@ -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

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 <[email protected]>

Acked-by Rob Clark <[email protected]>

Tested-by Peter Robinson <[email protected]>