OrangePi-Plus-2 boot process hangs in ubldr.bin
Emmanuel Vadot
manu at bidouilliste.com
Wed May 3 17:15:28 UTC 2017
On 2017-05-03 18:39, Mattia Rossi wrote:
> On 02/05/17 10:50, Emmanuel Vadot wrote:
>> On Sun, 30 Apr 2017 13:07:23 +0200
>> Mattia Rossi <mattia.rossi.mate at gmail.com> wrote:
>>
>>> Hi all,
>> Hello,
>>
>>> I've tried to upgrade u-boot on the OrangePi-Plus-2 (not the 2e) from
>>> mainline u-boot and on the outside it looks fine.
>> When you say mainline, what exact version did you took ?
>> I assume you took some patches also as it seems that your u-boot
>> have
>> API support.
>>
>>> U-boot loads, and it boots ubldr.bin.
>>>
>>> I'm using the orangepi-plus-2e.dtb as it has been working well for
>>> this
>>> board before (It all used to work).
>>>
>>> Now ubldr can't boot the kernel though, and I don't know why. I've
>>> rebuilt ubldr, world and kernel from svn. Revision number is 317594
>>>
>>> Any help would be appreciated
>>>
>>> The output before it stops is:
>>>
>>> U-Boot SPL 2017.05-rc2-00061-g12af9399e7 (Apr 25 2017 - 19:27:44)
>>> DRAM: 2048 MiB
>>> Trying to boot from MMC1
>>>
>>>
>>> U-Boot 2017.05-rc2-00061-g12af9399e7 (Apr 25 2017 - 19:27:44 +0200)
>>> Allwinner Technology
>>>
>>> CPU: Allwinner H3 (SUN8I 1680)
>>> Model: Xunlong Orange Pi Plus 2E
>>> I2C: ready
>>> DRAM: 2 GiB
>>> MMC: SUNXI SD/MMC: 0, SUNXI SD/MMC: 1
>>> In: serial
>>> Out: serial
>>> Err: serial
>>> Net: phy interface7
>>> eth0: ethernet at 1c30000
>>> starting USB...
>>> USB0: USB EHCI 1.00
>>> USB1: USB OHCI 1.0
>>> USB2: USB EHCI 1.00
>>> USB3: USB OHCI 1.0
>>> USB4: USB EHCI 1.00
>>> USB5: USB OHCI 1.0
>>> scanning bus 0 for devices... 1 USB Device(s) found
>>> scanning bus 2 for devices... 1 USB Device(s) found
>>> scanning bus 4 for devices... 1 USB Device(s) found
>>> scanning usb for storage devices... 0 Storage Device(s)
>>> found
>>> Hit any key to stop autoboot: 0
>>> Booting from: mmc 0 ubldr.bin
>>> reading ubldr.bin
>>> 237168 bytes read in 34 ms (6.7 MiB/s)
>>> ## No elf image at address 0x42000000
>>> ## Starting application at 0x42000000 ...
>>> Consoles: U-Boot console
>>> Compatible U-Boot API signature found @0xbbf3f690
>>>
>>> FreeBSD/armv6 U-Boot loader, Revision 1.2
>>> (Sat Apr 29 19:16:42 CEST 2017 root at freebsd101)
>>>
>>> DRAM: 2048MB
>>> MMC Device 2 not found
>>> MMC Device 3 not found
>>> Number of U-Boot devices: 2
>>> U-Boot env: loaderdev='mmc 0'
>>> Found U-Boot device: disk
>>> Checking unit=0 slice=<auto> partition=<auto>... good.
>>> Booting from disk0s2:
>>> /boot/kernel/kernel data=0x6a82c0+0x1a7d40
>>> syms=[0x4+0xba030+0x4+0xaa532]
>>>
>>> Hit [Enter] to boot immediately, or any other key for command prompt.
>>> Booting [/boot/kernel/kernel]...
>>> /boot/dtb/orangepi-plus-2e.dtb size=0x6326
>>> Loaded DTB from file 'orangepi-plus-2e.dtb'.
>>> Kernel entry at 0x42200100...
>>> Kernel args: (null)
>> This is probably a cache problem, the u-boot from ports (using imp@
>> branch on github) do take care of that.
>>
>
> So, I've used u-boot from ports (u-boot-orangepi-one) and it boots
> (using dd if=u-boot-sunxi-with-spl.bin of=<disk> bs=1024 seek=8).
> Guess I won't find out what the differences were, but so far I don't
> care. Was able to use the .dtb I've compiled from the GNU .dts files
> I've copied over from the latest linux kernel source tree. Was a bit
> of macking around to get the build through, but. Now I have a fully
> working system. Except ZFS is not working yet ;-)
>
> Thanks for the pointers,
>
> Mat
Not all patches have been upstreamed yet, I'm still working on that.
And ZFS will never work on this board (or on almost any of the ARM32
boards ...)
--
Emmanuel Vadot <manu at bidouilliste.com> <manu at freebsd.org>
More information about the freebsd-arm
mailing list