On Fri, Oct 6, 2017 at 10:08 PM, Jonathan Gray <j...@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 <j...@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 <j...@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.este...@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.este...@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 <robdcl...@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@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 sd...@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@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 sd...@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@lists.denx.de
https://lists.denx.de/listinfo/u-boot
