Heads up: new uboot coming today

Thu Jul 27 14:17:01 UTC 2017

On Jul 27, 2017, at 1:49 AM, Emmanuel Vadot <manu at bidouilliste.com> wrote:

> On Wed, 26 Jul 2017 20:45:06 -0400
> Paul Mather <paul at gromit.dlib.vt.edu> wrote:
> 
>> On Jul 24, 2017, at 10:43 AM, Warner Losh <imp at bsdimp.com> wrote:
>> 
>>> Barring any last minute unforeseen issues, I'll be committing the upgrade
>>> of the master uboot port to 2017.07 today, thanks to the hard work of
>>> Emmanuel Vadot. It fixes a few minor things, but also marks the move to the
>>> freebsd github u-boot repo from my private repo.
>> [[...]]
>>> ALLWINNER, BBB and iMX6 based boards are on u-boot-master. It should be
>>> fine, but if there's issues with the new uboot, please let me know. Others
>>> will come as soon as we can update those parts (the arm64 boards, and rPi
>>> being the main stragglers).
>> 
>> 
>> I updated my u-boot-beaglebone port to u-boot-beaglebone-2017.07.00 today.  I then copied the MLO and U-BOOT.IMG files to the /boot/msdos partition of my BBB (as directed by the port README) and performed a reboot.  Alas, the system would not boot up.  It appears it cannot locate a DTB file:
>> 
>> =====8<=====
>> [[...]]
>> Rebooting...
>> 
>> U-Boot SPL 2017.07 (Jul 26 2017 - 22:56:32)
>> Trying to boot from MMC1
>> *** Warning - bad CRC, using default environment
>> 
>> reading u-boot.img
>> reading u-boot.img
>> 
>> 
>> U-Boot 2017.07 (Jul 26 2017 - 22:56:32 +0000)
>> 
>> CPU  : AM335X-GP rev 2.0
>> I2C:   ready
>> DRAM:  512 MiB
>> No match for driver 'omap_hsmmc'
>> No match for driver 'omap_hsmmc'
>> Some drivers were not found
>> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
>> *** Warning - bad CRC, using default environment
>> 
>> <ethaddr> not set. Validating first E-fuse MAC
>> Net:   cpsw, usb_ether
>> Press SPACE to abort autoboot in 2 seconds
>> switch to partitions #0, OK
>> mmc0 is current device
>> SD/MMC found on device 0
>> reading boot.scr
>> ** Unable to read file boot.scr **
>> reading uEnv.txt
>> ** Unable to read file uEnv.txt **
>> switch to partitions #0, OK
>> mmc0 is current device
>> Scanning mmc 0:1...
>> Found FreeBSD U-Boot Loader (bin)
>> reading ubldr.bin
>> 223912 bytes read in 22 ms (9.7 MiB/s)
>> ## Starting application at 0x82000000 ...
>> Consoles: U-Boot console
>> Compatible U-Boot API signature found @0x9df2ec58
>> 
>> FreeBSD/armv6 U-Boot loader, Revision 1.2
>> (root at releng2.nyi.freebsd.org, Fri Aug 12 13:23:34 UTC 2016)
>> 
>> DRAM: 512MB
>> Number of U-Boot devices: 3
>> U-Boot env: loaderdev not set, will probe all devices.
>> Found U-Boot device: disk
>>  Probing all disk devices...
>>  Checking unit=0 slice=<auto> partition=<auto>... good.
>> Booting from disk0s2a:
>> /boot/kernel/kernel text=0x5cf800 data=0x4b8e8+0x147f18 syms=[0x4+0x944f0+0x4+0x9499c]
>> 
>> Hit [Enter] to boot immediately, or any other key for command prompt.
>> 
>> 
>> Type '?' for a list of commands, 'help' for more detailed help.
>> loader> boot -s
>> Booting...
>> No valid device tree blob found!
>> No device tree blob found!
>> 
>> loader>
>> =====>8=====
>> 
>> Is there some other file I need to copy to /boot/msdos when updating U-Boot?  Here is what I have right now (note, I moved the old, working MLO and U-BOOT.IMG files into uboot.old):
>> 
>> =====8<=====
>> root at beaglebone:/boot/msdos # ls -alR
>> total 950
>> drwxr-xr-x  1 root  wheel   16384 Dec 31  1979 .
>> drwxr-xr-x  9 root  wheel    1024 Jul 23 19:33 ..
>> -rwxr-xr-x  1 root  wheel   75884 Jul 26 20:09 MLO
>> -rwxr-xr-x  1 root  wheel    1083 Aug 13  2016 README
>> -rwxr-xr-x  1 root  wheel  376600 Jul 26 20:09 U-BOOT.IMG
>> -rwxr-xr-x  1 root  wheel  272013 Aug 13  2016 UBLDR
>> -rwxr-xr-x  1 root  wheel  223912 Aug 13  2016 UBLDR.BIN
>> drwxr-xr-x  1 root  wheel     512 Jul 26 20:11 uboot.old
>> 
>> ./uboot.old:
>> total 462
>> drwxr-xr-x  1 root  wheel     512 Jul 26 20:11 .
>> drwxr-xr-x  1 root  wheel   16384 Dec 31  1979 ..
>> -rwxr-xr-x  1 root  wheel   78928 Aug 13  2016 MLO
>> -rwxr-xr-x  1 root  wheel  376740 Aug 13  2016 U-BOOT.IMG
>> root at beaglebone:/boot/msdos #
>> =====>8=====
>> 
>> Note, the kernel boots via the old U-Boot.  Any help is appreciated.
>> 
>> Cheers,
>> 
>> Paul.
>> 
>> _______________________________________________
>> freebsd-arm at freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
> 
> Hello Paul,
> 
> This is not really a u-boot problem but more a DTB one, we've switched
> to the upstream dts for beaglebone a while ago and I guess that you
> don't have the right one in /boot/dtb/
> U-Boot is setting a variable for the dtb to load named fdtfile and now
> it's using the upstream name (am335x-boneblack.dtb) while before the
> file was named beaglebone-black.dtb.
> Rebuilding a kernel should fix this.

Thank you for the help.  I forgot to mention in my original post that I am running 11-STABLE on my BeagleBoneBlack.  There, /usr/src/sys/modules/dtb/am335x/Makefile still references the old names whereas HEAD references the new ones (creating links for the old ones):

=====8<=====
root at chumby:/build/src # cat head/sys/modules/dtb/am335x/Makefile
# $FreeBSD: head/sys/modules/dtb/am335x/Makefile 312969 2017-01-29 22:06:52Z gonzo $
# All the dts files for am335x systems we support.
DTS=    \
        am335x-bone.dts \
        am335x-boneblack.dts \
        am335x-bonegreen.dts \
        ufw.dts

LINKS= \
        ${DTBDIR}/am335x-bone.dtb ${DTBDIR}/beaglebone.dtb \
        ${DTBDIR}/am335x-boneblack.dtb ${DTBDIR}/beaglebone-black.dtb

.include <bsd.dtb.mk>
root at chumby:/build/src # cat releng_11/sys/modules/dtb/am335x/Makefile
# $FreeBSD: stable/11/sys/modules/dtb/am335x/Makefile 312756 2017-01-25 14:49:42Z loos $
# All the dts files for am335x systems we support.
DTS=    \
        beaglebone.dts \
        beaglebone-black.dts \
        ufw.dts

.include <bsd.dtb.mk>
root at chumby:/build/src #
=====>8=====

Am I correct in thinking that creating symlinks in /boot/dtb for am335x-bone.dts and am335x-boneblack.dts to their respective old names should fix my booting problem, then?

Are there any plans to MFC the new DTB names to STABLE, or is the u-boot-beaglebone port implicitly meant only for CURRENT users?

BTW, is it also good form to copy /boot/ubldr and /boot/ubldr.bin to /boot/msdos when updating the kernel and/or U-Boot?

Cheers,

Paul.