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

[Rob Clark <robdclark@gmail.com>]

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