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

Sun Oct 8 23:00:32 UTC 2017

On Sat, Oct 7, 2017 at 1:23 PM, Rob Clark <robdclark at gmail.com> wrote:
> On Fri, Oct 6, 2017 at 10:08 PM, Jonathan Gray <jsg at 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 at 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 at 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 at 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 at 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 at 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