Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 4 Sep 2018 19:10:53 +0200
From:      Jakob Alvermark <jakob@alvermark.net>
To:        Emmanuel Vadot <manu@bidouilliste.com>, Daniel Braniss <danny@cs.huji.ac.il>
Cc:        "freebsd-arm@freebsd.org" <arm@freebsd.org>
Subject:   Re: allwinner/nanopi neo boot issues
Message-ID:  <79e69d73-b4f0-177a-15da-786c4101697a@alvermark.net>
In-Reply-To: <20180904181603.916a3a6fbf05ecce149f6ea1@bidouilliste.com>
References:  <42AA3AE2-E101-4B7B-B373-BEC178321671@cs.huji.ac.il> <C745EB05-187D-4821-8CE3-5ADEF055231A@cs.huji.ac.il> <0fdbd315-f37d-e3d3-9309-612f53c4d379@alvermark.net> <8459A9BA-183A-461B-9050-3631C51218F9@cs.huji.ac.il> <474af48e-ba82-62ce-34a3-70dfc4382723@alvermark.net> <20180901224629.3997b4de29e4bf5f893dac79@bidouilliste.com> <03d4cb0a-c218-a186-936d-765261da2775@alvermark.net> <20180902172444.c4911c8c65a99a7d5e9fe8fa@bidouilliste.com> <4410f41b-79f5-f397-b0b1-84bceae82bd0@alvermark.net> <E43D3D96-9471-43EC-8F6F-D40C420EA7D8@cs.huji.ac.il> <d58c37b6-c551-0def-f966-38a8833339d3@alvermark.net> <855C0010-888D-4988-8056-7788CBCF5A48@cs.huji.ac.il> <20180904181603.916a3a6fbf05ecce149f6ea1@bidouilliste.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 9/4/18 6:16 PM, Emmanuel Vadot wrote:
> On Mon, 3 Sep 2018 11:21:09 +0300
> Daniel Braniss <danny@cs.huji.ac.il> wrote:
>
>>
>>> On 3 Sep 2018, at 11:05, Jakob Alvermark <jakob@alvermark.net> wrote:
>>>
>>>
>>> On 9/3/18 9:01 AM, Daniel Braniss wrote:
>>>>
>>>>> On 2 Sep 2018, at 19:33, Jakob Alvermark <jakob@alvermark.net <mailto:jakob@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@alvermark.net <mailto:jakob@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@alvermark.net <mailto:jakob@alvermark.net>> wrote:
>>>>>>>>
>>>>>>>>> On 8/29/18 2:22 PM, Daniel Braniss wrote:
>>>>>>>>>>> On 29 Aug 2018, at 15:17, Jakob Alvermark <jakob@alvermark.net <mailto:jakob@alvermark.net>
>>>>>>>>>>> <mailto:jakob@alvermark.net <mailto:jakob@alvermark.net>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 8/24/18 10:02 AM, Daniel Braniss wrote:
>>>>>>>>>>>>> On 24 Aug 2018, at 09:34, Daniel Braniss <danny@cs.huji.ac.il <mailto:danny@cs.huji.ac.il>
>>>>>>>>>>>>> <mailto:danny@cs.huji.ac.il <mailto:danny@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.

I just tried with 
FreeBSD-12.0-ALPHA4-arm-armv7-CUBIEBOARD2-20180831-r338410.img

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...


>>>>>>>>> EFI LOAD FAILED: continuing...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Tried manually loading ubldr.bin:
>>>>>>>>>
>>>>>>>>> => fatload mmc 0 0x42000000 ubldr.bin
>>>>>>>>> 306972 bytes read in 15 ms (19.5 MiB/s)
>>>>>>>>> => go 0x42000000
>>>>>>>>> Loading kernel...
>>>>>>>>> /boot/kernel/kernel text=0x85d7f0 data=0xaf620+0x24e1e0
>>>>>>>>> syms=[0x4+0xa87d0+0x4+0x10c603]
>>>>>>>>> Loading configured modules...
>>>>>>>>> /boot/kernel/umodem.ko text=0x1bf4 text=0x1320 data=0x1080+0xf88
>>>>>>>>> syms=[0x4+0x1070+0x4+0xbcd]
>>>>>>>>> loading required module 'ucom'
>>>>>>>>> /boot/kernel/ucom.ko text=0x1f8c text=0x2e90 data=0x1080+0x17bc
>>>>>>>>> syms=[0x4+0x14f0+0x4+0xc5d]
>>>>>>>>> Could not load one or more modules!
>>>>>>>>>
>>>>>>>>> Hit [Enter] to boot immediately, or any other key for command prompt.
>>>>>>>>> Booting [/boot/kernel/kernel]...
>>>>>>>>> /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)
>>>>>>>>>
>>>>>>>>> And then it reboots...
>>>>>>>>    I've just re-introduce the cache patches for u-boot as it appears that
>>>>>>>> some boards needs them (I've probably tested the wrong unpatched u-boot
>>>>>>>> when I removed them ...) so booting with ubldr.bin should work now.
>>>>>>>>    For the EFI issue I don't really know what is happening.
>>>>>>> Thanks! With the updated U-boot it now boots with ubldr.bin.
>>>>>>>
>>>>>>> How can I make it do this automatically?
>>>>>>   If you copy the boot.scr file from the port/package to the root of the
>>>>>> fat partition this will load ubldr.bin directly.
>>>>> Thanks again! It works!
>>>>>
>>>>>
>>>>>>   I'm more interested to debug the efi problem, I'll try on a H2 board.
>>>>> If there is anything I can do to help let me know.
>>>>>
>>>>> I tried with boot1.efi as /efi/boot/bootarm.efi:
>>>>>
>>>>> ## Starting EFI application at 42000000 ...
>>>>>>> FreeBSD EFI boot block
>>>>>     Loader path: /boot/loader.efi
>>>>>
>>>>>     Initializing modules: UFS
>>>>>     Load Path: /\efi\boot\bootarm.efi
>>>>>     Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(1,0x01,0,0x800,0x2000)
>>>>>     Probing 3 block devices.....* done
>>>>>      UFS found 1 partition
>>>>> Consoles: EFI console
>>>>> failed to allocate staging area: 14
>>>>> failed to allocate staging area
>>>>> Failed to start image provided by UFS (5)
>>>>> panic: No bootable partitions found!
>>>>> ## Application terminated, r = 1
>>>>> EFI LOAD FAILED: continuing?
>>>> shot in the dark:
>>>> 	I found out that if the root partition is not freebsd-ufs the efi boot failed.
>>>> do a gpart show,
>>>>
>>>> mine looks like this:
>>>> neo-001> gpart show
>>>> =>      63  15523777  mmcsd0  MBR  (7.4G)
>>>>         63      1985          - free -  (993K)
>>>>       2048    102400       1  fat32lba  [active]  (50M)
>>>>     104448   6187008       2  freebsd  (3.0G)
>>>>    6291456   9232384          - free -  (4.4G)
>>>>
>>>> =>      0  6187008  mmcsd0s2  BSD  (3.0G)
>>>>         0  6187008         1  freebsd-ufs  (3.0G)
>>> Nope, mine looks almost the same:
>>>
>>> =>      63  31116225  mmcsd0  MBR  (15G)
>>>          63      1985          - free -  (993K)
>>>        2048      8192       1  fat16  (4.0M)
>>>       10240      6144          - free -  (3.0M)
>>>       16384   4177920       2  freebsd  (2.0G)
>>>     4194304  26921984          - free -  (13G)
>>>
>>> =>      0  4177920  mmcsd0s2  BSD  (2.0G)
>>>          0  4177920         1  freebsd-ufs  (2.0G)
>>>
>>> Interestingly, loading bootarm.efi(boot1.efi) manually gets me to the loader:
>>>
>>>
>> bootarm.efi should be a copy of loader.efi not boot1.efi as far as I know.
>   Both should work.
>
>>> => fatload mmc 0 0x42000000 efi/boot/bootarm.efi
>>> 39500 bytes read in 4 ms (9.4 MiB/s)
>>> => bootefi 0x42000000
>>> But it does not boot:
>>>
>>> Type '?' for a list of commands, 'help' for more detailed help.
>>> OK load boot/kernel/kernel
>>> boot/kernel/kernel text=0x89ef08 data=0xae620+0x1f5aa0 syms=[0x4+0xa6d30+0x4+0x109e65]
>>> OK load -t dtb boot/dtb/sun8i-h2-plus-orangepi-r1.dtb
>>> boot/dtb/sun8i-h2-plus-orangepi-r1.dtb size=0x6333
>>> OK boot
>>> Using DTB from loaded file 'boot/dtb/sun8i-h2-plus-orangepi-r1.dtb'.
>>> EHCI failed to shut down host controller.
>>> Kernel entry at 0x43000180...
>>> Kernel args: (null)
>>> modulep: 0xc0d03000
>>> relocation_offset 0
>>> --Hangs here--
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?79e69d73-b4f0-177a-15da-786c4101697a>