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