Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 03 May 2017 19:15:18 +0200
From:      Emmanuel Vadot <manu@bidouilliste.com>
To:        mattia.rossi.mate@gmail.com
Cc:        ARM <freebsd-arm@freebsd.org>
Subject:   Re: OrangePi-Plus-2 boot process hangs in ubldr.bin
Message-ID:  <e6df870dfed1c38fc9c45dcade958ba7@megadrive.org>
In-Reply-To: <7ee97ba7-3dd2-6df8-8d06-776d01a772be@gmail.com>
References:  <f95b8a1b-1d92-4402-4fc6-e8b2006b593b@gmail.com> <20170502105007.0424f8cb7c8021951bf04495@bidouilliste.com> <7ee97ba7-3dd2-6df8-8d06-776d01a772be@gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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@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@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@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@bidouilliste.com> <manu@freebsd.org>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e6df870dfed1c38fc9c45dcade958ba7>