allwinner/nanopi neo boot issues

Emmanuel Vadot manu at bidouilliste.com
Fri Sep 7 13:58:56 UTC 2018


On Wed, 5 Sep 2018 17:34:05 +0200
Jakob Alvermark <jakob at alvermark.net> wrote:

> On 9/5/18 5:24 PM, Jakob Alvermark wrote:
> >
> > On 9/5/18 2:41 PM, Emmanuel Vadot wrote:
> >> On Tue, 4 Sep 2018 19:10:53 +0200
> >> Jakob Alvermark <jakob at alvermark.net> wrote:
> >>
> >>> On 9/4/18 6:16 PM, Emmanuel Vadot wrote:
> >>>> On Mon, 3 Sep 2018 11:21:09 +0300
> >>>> Daniel Braniss <danny at cs.huji.ac.il> wrote:
> >>>>
> >>>>>> On 3 Sep 2018, at 11:05, Jakob Alvermark <jakob at alvermark.net> 
> >>>>>> wrote:
> >>>>>>
> >>>>>>
> >>>>>> On 9/3/18 9:01 AM, Daniel Braniss wrote:
> >>>>>>>> On 2 Sep 2018, at 19:33, Jakob Alvermark <jakob at alvermark.net 
> >>>>>>>> <mailto:jakob at alvermark.net>> wrote:
> >>>>>>>>
> >>>>>>>> On 9/2/18 5:24 PM, Emmanuel Vadot wrote:
> >>>>>>>>> On Sun, 2 Sep 2018 17:14:10 +0200
> >>>>>>>>> Jakob Alvermark <jakob at alvermark.net 
> >>>>>>>>> <mailto:jakob at alvermark.net>> wrote:
> >>>>>>>>>
> >>>>>>>>>> On 9/1/18 10:46 PM, Emmanuel Vadot wrote:
> >>>>>>>>>>> On Sat, 1 Sep 2018 15:50:25 +0200
> >>>>>>>>>>> Jakob Alvermark <jakob at alvermark.net 
> >>>>>>>>>>> <mailto:jakob at alvermark.net>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> On 8/29/18 2:22 PM, Daniel Braniss wrote:
> >>>>>>>>>>>>>> On 29 Aug 2018, at 15:17, Jakob Alvermark 
> >>>>>>>>>>>>>> <jakob at alvermark.net <mailto:jakob at alvermark.net>
> >>>>>>>>>>>>>> <mailto:jakob at alvermark.net 
> >>>>>>>>>>>>>> <mailto:jakob at alvermark.net>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 8/24/18 10:02 AM, Daniel Braniss wrote:
> >>>>>>>>>>>>>>>> On 24 Aug 2018, at 09:34, Daniel Braniss 
> >>>>>>>>>>>>>>>> <danny at cs.huji.ac.il <mailto:danny at cs.huji.ac.il>
> >>>>>>>>>>>>>>>> <mailto:danny at cs.huji.ac.il 
> >>>>>>>>>>>>>>>> <mailto:danny at cs.huji.ac.il>>> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> hi,
> >>>>>>>>>>>>>>>> with the latest current r338243 no longer boots via 
> >>>>>>>>>>>>>>>> ubldr, efi does
> >>>>>>>>>>>>>>>> but with overlays I have to manually enter the root 
> >>>>>>>>>>>>>>>> partition.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> this is where it hangs via ubldr:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Autoboot in 8 seconds, hit [Enter] to boot or any other 
> >>>>>>>>>>>>>>>> key to stop
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Loading kernel...
> >>>>>>>>>>>>>>>> /boot/kernel/kernel text=0x8a0950 data=0xae160+0x184520
> >>>>>>>>>>>>>>>> syms=[0x4+0xa6d70+0x4+0x109f17]
> >>>>>>>>>>>>>>>> Loading configured modules...
> >>>>>>>>>>>>>>>> /boot/entropy size=0x1000
> >>>>>>>>>>>>>>>> /boot/dtb/sun8i-h3-nanopi-neo.dtb size=0x601b
> >>>>>>>>>>>>>>>> Loaded DTB from file 'sun8i-h3-nanopi-neo.dtb'.
> >>>>>>>>>>>>>>>> Kernel entry at 0x42400180...
> >>>>>>>>>>>>>>>> Kernel args: (null)
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> older - r337232 - boots fine,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> any ideas where to look?
> >>>>>>>>>>>>>>> should have done an update before writing!
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> with the latest (and greatest) all is back to normal!
> >>>>>>>>>>>>>>> so now on to test orange pi one(h3), nanopi neo 2 (h5) 
> >>>>>>>>>>>>>>> and nanopi
> >>>>>>>>>>>>>>> neo a64
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> thanks,
> >>>>>>>>>>>>>>> danny
> >>>>>>>>>>>>>> Hi,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I am trying to get an Orange Pi R1 going, I get the same.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Loading kernel...
> >>>>>>>>>>>>>> /boot/kernel/kernel text=0x89ee40 data=0xae620+0x1f5ba0
> >>>>>>>>>>>>>> syms=[0x4+0xa6d20+0x4+0x109e51]
> >>>>>>>>>>>>>> Loading configured modules...
> >>>>>>>>>>>>>> Could not load one or more modules!
> >>>>>>>>>>>>>> /boot/dtb/sun8i-h2-plus-orangepi-r1.dtb size=0x6333
> >>>>>>>>>>>>>> Loaded DTB from file 'sun8i-h2-plus-orangepi-r1.dtb'.
> >>>>>>>>>>>>>> Kernel entry at 0x42400180...
> >>>>>>>>>>>>>> Kernel args: (null)
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> This is at r338369.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> try booting via efi;
> >>>>>>>>>>>>> make sure to copy /boot/loader.efi to 
> >>>>>>>>>>>>> /boot/msdos/EFI/BOOT/bootaa64.efi
> >>>>>>>>>>>>> remove /boot/msdos/boot.scr
> >>>>>>>>>>>>> good luck,
> >>>>>>>>>>>>> danny
> >>>>>>>>>>>> I tried the ALPHA4 snapshot, this happens:
> >>>>>>>>>>>>
> >>>>>>>>>>>> Hit any key to stop autoboot:  0
> >>>>>>>>>>>> switch to partitions #0, OK
> >>>>>>>>>>>> mmc0 is current device
> >>>>>>>>>>>> Scanning mmc 0:1...
> >>>>>>>>>>>> 25395 bytes read in 4 ms (6.1 MiB/s)
> >>>>>>>>>>>> Found EFI removable media binary efi/boot/bootarm.efi
> >>>>>>>>>>>> Scanning disks on usb...
> >>>>>>>>>>>> Disk usb0 not ready
> >>>>>>>>>>>> Disk usb1 not ready
> >>>>>>>>>>>> Disk usb2 not ready
> >>>>>>>>>>>> Disk usb3 not ready
> >>>>>>>>>>>> Scanning disks on mmc...
> >>>>>>>>>>>> MMC Device 1 not found
> >>>>>>>>>>>> MMC Device 2 not found
> >>>>>>>>>>>> MMC Device 3 not found
> >>>>>>>>>>>> Found 3 disks
> >>>>>>>>>>>> 508704 bytes read in 26 ms (18.7 MiB/s)
> >>>>>>>>>>>> ## Starting EFI application at 42000000 ...
> >>>>>>>>>>>> Consoles: EFI console
> >>>>>>>>>>>> failed to allocate staging area: 14
> >>>>>>>>>>>> failed to allocate staging area
> >>>>>>>>>>>> ## Application terminated, r = 5
> >>>>    So this is weird, it mean that loader.efi couldn't allocate some 
> >>>> pages.
> >>>>
> >>>>    I've just tried ALPHA4 on my orangepi-zero (closer board that I 
> >>>> have),
> >>>> I've just overwritten u-boot using the port we have for it and the
> >>>> board boots just fine.
> >>>>    How did you generate the image for this one ?
> >>>>    Could you test with my method ? Thanks.
> >>> Which image should I use? For ALPHA3 there is a GENERICSD image, but 
> >>> not
> >>> for ALPHA4.
> >>   Build fail due to some (maybe) race condition.
> >>
> >>> I just tried with
> >>> FreeBSD-12.0-ALPHA4-arm-armv7-CUBIEBOARD2-20180831-r338410.img
> >>   Any of the armv7 image will do, they are all the same except the
> >> u-boot part.
> >>
> >>> dd the u-boot from the port (latest one, u-boot-orangepi_r1-2018.07_3)
> >>>
> >>> Put the SD card in and this happened:
> >>>
> >>> Hit any key to stop autoboot:  0
> >>> switch to partitions #0, OK
> >>> mmc0 is current device
> >>> Scanning mmc 0:1...
> >>> 25395 bytes read in 3 ms (8.1 MiB/s)
> >>> Found EFI removable media binary efi/boot/bootarm.efi
> >>> Scanning disks on usb...
> >>> Disk usb0 not ready
> >>> Disk usb1 not ready
> >>> Disk usb2 not ready
> >>> Disk usb3 not ready
> >>> Scanning disks on mmc...
> >>> MMC Device 1 not found
> >>> MMC Device 2 not found
> >>> MMC Device 3 not found
> >>> Found 3 disks
> >>> 508704 bytes read in 25 ms (19.4 MiB/s)
> >>> ## Starting EFI application at 42000000 ...
> >>> Consoles: EFI console
> >>> failed to allocate staging area: 14
> >>> failed to allocate staging area
> >>> ## Application terminated, r = 5
> >>> EFI LOAD FAILED: continuing...
> >>>
> >>>
> >>   Could you try to decrease EFI_STAGING_SIZE to 32 in
> >> stand/efi/loader/copy.c ?
> >
> > Didn't make any difference:
> >
> > Found EFI removable media binary efi/boot/bootarm.efi
> > Scanning disks on usb...
> > Disk usb0 not ready
> > Disk usb1 not ready
> > Disk usb2 not ready
> > Disk usb3 not ready
> > Scanning disks on mmc...
> > MMC Device 1 not found
> > MMC Device 2 not found
> > MMC Device 3 not found
> > Found 3 disks
> > 508704 bytes read in 26 ms (18.7 MiB/s)
> > ## Starting EFI application at 42000000 ...
> > Consoles: EFI console
> > failed to allocate staging area: 14
> > failed to allocate staging area
> > ## Application terminated, r = 5
> > EFI LOAD FAILED: continuing...
> 
> 
> Disregard that. I copied the wrong file.
> 
> I boots with EFI_STAGING_SIZE set 32.

 Ok, thanks.
 I'm wondering if we should try with EFI_STAGING_SIZE/2 if the first
allocate_pages failed ...

> 
> 
> >
> >>   We currently request 64M for the staging size which seems to be too
> >> big for this board.
> >>   U-Boot cannot find enough memory it seems,
> >> https://elixir.bootlin.com/u-boot/latest/source/lib/efi_loader/efi_memory.c#L300 
> >>
> >>
> > _______________________________________________
> > freebsd-arm at freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> > To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"


-- 
Emmanuel Vadot <manu at bidouilliste.com> <manu at freebsd.org>


More information about the freebsd-arm mailing list