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
