All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Clark <robdclark@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case
Date: Fri, 6 Oct 2017 08:21:26 -0400	[thread overview]
Message-ID: <CAF6AEGtv5BWMn-F8Uy2AYFxH532q0YDPCfMHtFY6eF2S3qe8hg@mail.gmail.com> (raw)
In-Reply-To: <20171006043519.GA8064@largo.jsg.id.au>

On Fri, Oct 6, 2017 at 12:35 AM, Jonathan Gray <jsg@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 <jsg@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.estevam@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.estevam@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 <robdclark@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
> ...

  reply	other threads:[~2017-10-06 12:21 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-04 16:29 [U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case Fabio Estevam
2017-10-04 17:12 ` Rob Clark
2017-10-05  4:36   ` Jonathan Gray
2017-10-05  9:05     ` Rob Clark
2017-10-06  4:35       ` Jonathan Gray
2017-10-06 12:21         ` Rob Clark [this message]
2017-10-06 12:26           ` Rob Clark
2017-10-07  2:08           ` Jonathan Gray
2017-10-07 12:23             ` Rob Clark
2017-10-07 13:20               ` Jonathan Gray
2017-10-08 23:00               ` Peter Robinson
2017-10-07 17:46     ` Fabio Estevam
2017-10-08  1:06       ` Jonathan Gray
2017-10-08 12:56         ` Fabio Estevam
2017-10-08 14:04           ` Jonathan Gray
2017-10-09  1:56             ` Fabio Estevam
2017-10-09  3:12               ` Tom Rini
2017-10-09  6:19                 ` Jonathan Gray
2017-10-09 12:08                   ` Tom Rini
2017-10-05 11:01 ` Peter Robinson
2017-10-05 21:52 ` [U-Boot] " Tom Rini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAF6AEGtv5BWMn-F8Uy2AYFxH532q0YDPCfMHtFY6eF2S3qe8hg@mail.gmail.com \
    --to=robdclark@gmail.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.