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) 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 > ... _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot