allwinner/nanopi neo boot issues

Sun Sep 2 16:33:38 UTC 2018

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

>> Also, the network interface does not attach:
>>
>> awg0: <Allwinner Gigabit Ethernet> mem 0x1c30000-0x1c3ffff irq 22 on
>> simplebus0
>> awg0: soft reset timed out
>> device_attach: awg0 attach returned 60
>   Yes there is a problem on some boards when the cable isn't connected,
> someone (tm) will need to debug that one day.

Alright, with a cable connected during boot it works.