Date: Wed, 3 Jan 2018 18:52:12 -0800 From: Mark Millard <markmi@dsl-only.net> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm@freebsd.org Subject: Re: RPI2 boot hangs with red light on Message-ID: <B0FDE9B0-91EF-4B71-9292-1A3D1C0B2377@dsl-only.net> In-Reply-To: <20180104023257.GA15177@www.zefox.net> References: <20180102222730.GB10596@www.zefox.net> <3EE68320-8359-495D-AFCE-098A2220C6AE@dsl-only.net> <20180104023257.GA15177@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[ubldr.bin needs to be copied to the msdosfs.]
On 2018-Jan-3, at 6:32 PM, bob prohaska <fbsd at www.zefox.net> wrote:
> On Tue, Jan 02, 2018 at 03:50:40PM -0800, Mark Millard wrote:
>>
>> On 2018-Jan-2, at 2:27 PM, bob prohaska <fbsd at www.zefox.net> wrote:
>>
>>>
>>> U-Boot 2015.04 (Jun 26 2017 - 22:31:06)
>>
>> This is older than is in ports these days
>> [U-Boot 2017.09 (Dec 16 2017 - 03:23:07 +0000)].
>>
>
> Very true.
>
>>>
>>> FreeBSD/armv6 U-Boot loader, Revision 1.2
>>> (Mon Jun 26 22:46:48 UTC 2017 root@releng3.nyi.freebsd.org)
>>
>> [Note that armv6 above.]
>>
>
> That does give me pause, but the kernel went to v7 at least
> a few build/install cycles ago and seemed to boot fine....
>
>> What I get based on modern material is
>> (and use of ubldr.bin instead of ubldr):
>>
>
> Both ubldr and ubldr.bin are present in /boot and date from Jan 2nd.
That is where they are built but for the rpi2
that is not the copy used during boot: ubldr.bin
needs to be copied to the msdosfs.
(The following is based on modern materials, as that
is what I have for reference.)
In the original reply I'd quoted /usr/src/release/arm/RPI2.conf
and part of that was:
chroot ${CHROOTDIR} cp -p ${UFSMOUNT}/boot/ubldr.bin \
${FATMOUNT}/ubldr.bin
chroot ${CHROOTDIR} cp -p ${UFSMOUNT}/boot/dtb/rpi2.dtb \
${FATMOUNT}/rpi2.dtb
For modern materials ubldr.bin and rpi2.dtb are
supposed to be copied to the msdosfs, with the
rpifirmware materials and the like.
The stages prior to the kernel load and its
own dtb load are not from the UFS file
system but from msdosfs.
ubldr.bin and/or ubldr need to be copied over
for older rpifirmware and u-boot-rpi2 materials
as well as I understand. The copy that is on
the msdosfs is the one being used (and so controls
the vintage of ubldr.bin or ubldr that is used).
>> Found FreeBSD U-Boot Loader (bin)
>> reading ubldr.bin
>> 231872 bytes read in 32 ms (6.9 MiB/s)
>> ## Starting application at 0x01000000 ...
>> Consoles: U-Boot console
>> Compatible U-Boot API signature found @0x3af5d988
>>
>> FreeBSD/armv7 U-Boot loader, Revision 1.2
>>
>>
>> I do not know if mixing older armv6 materials
>> and newer armv7 materials has any problems. My
>> context is all armv7 (cortex-a7 targeted).
>>
>
> It didn't initially, far as I can tell. There's nothing obvious in
> /usr/src/UPDATING about a need to alter u-boot, though there is a
> reference to new variable names in November. None seem applicable
> to the Pi.
>
>>> Hit [Enter] to boot immediately, or any other key for command prompt.
>>> Booting [/boot/kernel/kernel]...
>>> Using DTB provided by U-Boot at address 0x100.
>>
>> Using modern materials indicated:
>>
>> /boot/dtb/bcm2836-rpi-2-b.dtb size=0x346b
>> Loaded DTB from file 'bcm2836-rpi-2-b.dtb'.
>>
>>> Kernel entry at 0x2200100...
>>> Kernel args: (null)
>>
>> And I see on what I use:
>>
>> Kernel entry at 0x1200100...
>> Kernel args: (null)
>>
>
> This looks very different.
>
> It's plausible that u-boot needs to be updated, but it'd be nice to see
> confirmation somewhere. Needless changes are a good way to push problems
> past redemption.
===
Mark Millard
markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B0FDE9B0-91EF-4B71-9292-1A3D1C0B2377>