From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Robinson Date: Mon, 9 Oct 2017 00:00:32 +0100 Subject: [U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case In-Reply-To: References: <1507134597-6831-1-git-send-email-fabio.estevam@nxp.com> <20171005043646.GB8685@largo.jsg.id.au> <20171006043519.GA8064@largo.jsg.id.au> <20171007020841.GB47267@largo.jsg.id.au> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Sat, Oct 7, 2017 at 1:23 PM, Rob Clark wrote: > On Fri, Oct 6, 2017 at 10:08 PM, Jonathan Gray 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 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 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 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 >>> >> >> > --- >>> >> >> > 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 >>> >> >> >>> >> >> 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 >>> > 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