* [U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case
@ 2017-10-04 16:29 Fabio Estevam
2017-10-04 17:12 ` Rob Clark
` (2 more replies)
0 siblings, 3 replies; 21+ messages in thread
From: Fabio Estevam @ 2017-10-04 16:29 UTC (permalink / raw)
To: 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 <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
^ permalink raw reply related [flat|nested] 21+ messages in thread
* [U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case
2017-10-04 16:29 [U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case Fabio Estevam
@ 2017-10-04 17:12 ` Rob Clark
2017-10-05 4:36 ` Jonathan Gray
2017-10-05 11:01 ` Peter Robinson
2017-10-05 21:52 ` [U-Boot] " Tom Rini
2 siblings, 1 reply; 21+ messages in thread
From: Rob Clark @ 2017-10-04 17:12 UTC (permalink / raw)
To: u-boot
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
>
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case
2017-10-04 17:12 ` Rob Clark
@ 2017-10-05 4:36 ` Jonathan Gray
2017-10-05 9:05 ` Rob Clark
2017-10-07 17:46 ` Fabio Estevam
0 siblings, 2 replies; 21+ messages in thread
From: Jonathan Gray @ 2017-10-05 4:36 UTC (permalink / raw)
To: u-boot
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 **
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case
2017-10-05 4:36 ` Jonathan Gray
@ 2017-10-05 9:05 ` Rob Clark
2017-10-06 4:35 ` Jonathan Gray
2017-10-07 17:46 ` Fabio Estevam
1 sibling, 1 reply; 21+ messages in thread
From: Rob Clark @ 2017-10-05 9:05 UTC (permalink / raw)
To: u-boot
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 **
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case
2017-10-04 16:29 [U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case Fabio Estevam
2017-10-04 17:12 ` Rob Clark
@ 2017-10-05 11:01 ` Peter Robinson
2017-10-05 21:52 ` [U-Boot] " Tom Rini
2 siblings, 0 replies; 21+ messages in thread
From: Peter Robinson @ 2017-10-05 11:01 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] disk: part_dos: Use the original allocation scheme for the SPL case
2017-10-04 16:29 [U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case Fabio Estevam
2017-10-04 17:12 ` Rob Clark
2017-10-05 11:01 ` Peter Robinson
@ 2017-10-05 21:52 ` Tom Rini
2 siblings, 0 replies; 21+ messages in thread
From: Tom Rini @ 2017-10-05 21:52 UTC (permalink / raw)
To: u-boot
On Wed, Oct 04, 2017 at 01:29:57PM -0300, Fabio Estevam wrote:
> Since commit ff98cb90514d ("part: extract MBR signature from partitions")
> SPL boot on i.MX6 starts to fail:
>
> U-Boot SPL 2017.09-00221-g0d6ab32 (Oct 02 2017 - 15:13:19)
> Trying to boot from MMC1
> (keep in loop)
>
> Use the original allocation scheme for the SPL case, so that MX6 boards
> can boot again.
>
> This is a temporary solution to avoid the boot regression.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
> Acked-by: Rob Clark <robdclark@gmail.com>
> Tested-by: Peter Robinson <pbrobinson@gmail.com>
Applied to u-boot/master, thanks!
--
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>
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case
2017-10-05 9:05 ` Rob Clark
@ 2017-10-06 4:35 ` Jonathan Gray
2017-10-06 12:21 ` Rob Clark
0 siblings, 1 reply; 21+ messages in thread
From: Jonathan Gray @ 2017-10-06 4:35 UTC (permalink / raw)
To: u-boot
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
...
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case
2017-10-06 4:35 ` Jonathan Gray
@ 2017-10-06 12:21 ` Rob Clark
2017-10-06 12:26 ` Rob Clark
2017-10-07 2:08 ` Jonathan Gray
0 siblings, 2 replies; 21+ messages in thread
From: Rob Clark @ 2017-10-06 12:21 UTC (permalink / raw)
To: u-boot
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
> ...
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case
2017-10-06 12:21 ` Rob Clark
@ 2017-10-06 12:26 ` Rob Clark
2017-10-07 2:08 ` Jonathan Gray
1 sibling, 0 replies; 21+ messages in thread
From: Rob Clark @ 2017-10-06 12:26 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case
2017-10-06 12:21 ` Rob Clark
2017-10-06 12:26 ` Rob Clark
@ 2017-10-07 2:08 ` Jonathan Gray
2017-10-07 12:23 ` Rob Clark
1 sibling, 1 reply; 21+ messages in thread
From: Jonathan Gray @ 2017-10-07 2:08 UTC (permalink / raw)
To: u-boot
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
...
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case
2017-10-07 2:08 ` Jonathan Gray
@ 2017-10-07 12:23 ` Rob Clark
2017-10-07 13:20 ` Jonathan Gray
2017-10-08 23:00 ` Peter Robinson
0 siblings, 2 replies; 21+ messages in thread
From: Rob Clark @ 2017-10-07 12:23 UTC (permalink / raw)
To: u-boot
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
> ...
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case
2017-10-07 12:23 ` Rob Clark
@ 2017-10-07 13:20 ` Jonathan Gray
2017-10-08 23:00 ` Peter Robinson
1 sibling, 0 replies; 21+ messages in thread
From: Jonathan Gray @ 2017-10-07 13:20 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case
2017-10-05 4:36 ` Jonathan Gray
2017-10-05 9:05 ` Rob Clark
@ 2017-10-07 17:46 ` Fabio Estevam
2017-10-08 1:06 ` Jonathan Gray
1 sibling, 1 reply; 21+ messages in thread
From: Fabio Estevam @ 2017-10-07 17:46 UTC (permalink / raw)
To: u-boot
Hi Jonathan,
On Thu, Oct 5, 2017 at 1:36 AM, Jonathan Gray <jsg@jsg.id.au> wrote:
> This does not seem to be a complete fix, cubox is still broken when
> U-Boot proper loads, unless the efi loader commits are to blame
> for introducing unaligned accesses.
I cannot reproduce the problem on mx6q cubox:
U-Boot SPL 2017.11-rc1-00101-gafbdfd8 (Oct 07 2017 - 14:41:16)
Trying to boot from MMC1
U-Boot 2017.11-rc1-00101-gafbdfd8 (Oct 07 2017 - 14:41:16 -0300)
CPU: Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz)
CPU: Extended Commercial temperature grade (-20C to 105C) at 23C
Reset cause: POR
Board: MX6 Cubox-i
DRAM: 2 GiB
MMC: FSL_SDHC: 0
No panel detected: default to HDMI
Display: HDMI (1024x768)
In: serial
Out: serial
Err: serial
Net: FEC
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
336 bytes read in 70 ms (3.9 KiB/s)
## Executing script at 12000000
37669 bytes read in 69 ms (532.2 KiB/s)
6378872 bytes read in 361 ms (16.9 MiB/s)
## Flattened Device Tree blob at 18000000
Booting using the fdt blob at 0x18000000
Using Device Tree in place at 18000000, end 1800c324
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case
2017-10-07 17:46 ` Fabio Estevam
@ 2017-10-08 1:06 ` Jonathan Gray
2017-10-08 12:56 ` Fabio Estevam
0 siblings, 1 reply; 21+ messages in thread
From: Jonathan Gray @ 2017-10-08 1:06 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case
2017-10-08 1:06 ` Jonathan Gray
@ 2017-10-08 12:56 ` Fabio Estevam
2017-10-08 14:04 ` Jonathan Gray
0 siblings, 1 reply; 21+ messages in thread
From: Fabio Estevam @ 2017-10-08 12:56 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case
2017-10-08 12:56 ` Fabio Estevam
@ 2017-10-08 14:04 ` Jonathan Gray
2017-10-09 1:56 ` Fabio Estevam
0 siblings, 1 reply; 21+ messages in thread
From: Jonathan Gray @ 2017-10-08 14:04 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case
2017-10-07 12:23 ` Rob Clark
2017-10-07 13:20 ` Jonathan Gray
@ 2017-10-08 23:00 ` Peter Robinson
1 sibling, 0 replies; 21+ messages in thread
From: Peter Robinson @ 2017-10-08 23:00 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case
2017-10-08 14:04 ` Jonathan Gray
@ 2017-10-09 1:56 ` Fabio Estevam
2017-10-09 3:12 ` Tom Rini
0 siblings, 1 reply; 21+ messages in thread
From: Fabio Estevam @ 2017-10-09 1:56 UTC (permalink / raw)
To: u-boot
On Sun, Oct 8, 2017 at 11:04 AM, Jonathan Gray <jsg@jsg.id.au> wrote:
> It turns out to be
>
> commit 2460098cffacd18729262e3ed36656e6943783ed
> Author: Tom Rini <trini@konsulko.com>
> Date: Fri Sep 22 07:37:43 2017 -0400
>
> fs/fat: Reduce stack usage
>
> We have limited stack in SPL builds. Drop itrblock and move to
> malloc/free of itr to move this off of the stack. As part of this fix a
> double-free issue in fat_size().
>
> Signed-off-by: Tom Rini <trini@konsulko.com>
> ---
> Rework to use malloc/free as moving this to a global overflows some SH
> targets.
>
> fs/fat/fat.c | 14 ++++++++++----
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> With that reverted I just get the efi loader problem, no alignment errors.
Thanks for doing the bisect.
Tom, can you prepare a fix for this?
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case
2017-10-09 1:56 ` Fabio Estevam
@ 2017-10-09 3:12 ` Tom Rini
2017-10-09 6:19 ` Jonathan Gray
0 siblings, 1 reply; 21+ messages in thread
From: Tom Rini @ 2017-10-09 3:12 UTC (permalink / raw)
To: u-boot
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>
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case
2017-10-09 3:12 ` Tom Rini
@ 2017-10-09 6:19 ` Jonathan Gray
2017-10-09 12:08 ` Tom Rini
0 siblings, 1 reply; 21+ messages in thread
From: Jonathan Gray @ 2017-10-09 6:19 UTC (permalink / raw)
To: u-boot
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;
^ permalink raw reply related [flat|nested] 21+ messages in thread
* [U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case
2017-10-09 6:19 ` Jonathan Gray
@ 2017-10-09 12:08 ` Tom Rini
0 siblings, 0 replies; 21+ messages in thread
From: Tom Rini @ 2017-10-09 12:08 UTC (permalink / raw)
To: u-boot
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>
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2017-10-09 12:08 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-10-04 16:29 [U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case Fabio Estevam
2017-10-04 17:12 ` Rob Clark
2017-10-05 4:36 ` Jonathan Gray
2017-10-05 9:05 ` Rob Clark
2017-10-06 4:35 ` Jonathan Gray
2017-10-06 12:21 ` Rob Clark
2017-10-06 12:26 ` Rob Clark
2017-10-07 2:08 ` Jonathan Gray
2017-10-07 12:23 ` Rob Clark
2017-10-07 13:20 ` Jonathan Gray
2017-10-08 23:00 ` Peter Robinson
2017-10-07 17:46 ` Fabio Estevam
2017-10-08 1:06 ` Jonathan Gray
2017-10-08 12:56 ` Fabio Estevam
2017-10-08 14:04 ` Jonathan Gray
2017-10-09 1:56 ` Fabio Estevam
2017-10-09 3:12 ` Tom Rini
2017-10-09 6:19 ` Jonathan Gray
2017-10-09 12:08 ` Tom Rini
2017-10-05 11:01 ` Peter Robinson
2017-10-05 21:52 ` [U-Boot] " Tom Rini
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.