Solved Bumping the U-boot Master port

Phishfry

Phishfry

I am in a stand-still until FreeBSD updates u-boot to 2023.07 To be released tomorrow.

To waste some time I decided to try to bring the Master port up to 2023.4 which is last official release tag.
/sysutils/u-boot-master/
UBOOT_VERSION?= 2023.04

Simple as changing the verison in our u-boot Master ports Makefile. Whoa. Not so simple.
It seems I keep bumping up against u-boot changes.

It looks to me from reading that they are changing the way the FIT image is produced?
Code: 
=> SHA256 Checksum OK for u-boot/u-boot-2023.04.tar.bz2.
===>  Patching for u-boot-nanopc-t4-2023.04
find: arch/arm/mach-rockchip/make_fit_atf.py: No such file or directory
*** Error code 1
This script no longer exists.
So as a hack I tried to copy over ./arch/arm/mach-rockchip/ from 2023.01 but of course that just delayed the inevitable fail.

Looks like another case of binman screwing me. They have changed the way they build FIT image here I think.

Anybody have a WIP for the master port? Any hints? I don't want to bug evadot@.
(Note the slave port shown is a personal one)
 
I just discovered this relevant line in the u-boot master port Makefile.
Code: 
SHEBANG_FILES= tools/binman/binman arch/arm/mach-rockchip/make_fit_atf.py

So it references binman. Which is present in the form of a soft-linked symbolic file to main.py in the same directory.

Very confused. make_fit_atf.py missing in newer u-boot but binman is there.
Why is it using the python shebang too?
 
Well I feel dumb.
I simply removed the missing script from the SHEBANG= and it builds sucessfully.
Phishfry said:
SHEBANG_FILES= tools/binman/binman
Click to expand...

I am ready now for uboot 2023.07
Maybe they released it early for me.

Nope. wait until midnight...
Code: 
===>   u-boot-rockpro64-2023.07 depends on file: /usr/local/sbin/pkg - found
=> u-boot/u-boot-2023.07.tar.bz2 is not in /usr/ports/sysutils/u-boot-rockpro64/../u-boot-master/distinfo.
=> Either /usr/ports/sysutils/u-boot-rockpro64/../u-boot-master/distinfo is out of date, or
=> u-boot/u-boot-2023.07.tar.bz2 is spelled incorrectly.
*** Error code 1
 
I would like to understand if I have made the proper choice here.

Can anyone explain how this works in a ports Makefile:

Code: 
SHEBANG_FILES= tools/binman/binman arch/arm/mach-rockchip/make_fit_atf.py

Is it attempting to use both programs or either/or? Priority?

I have found if I remove the SHEBANG= line it still compiles.

So I am guessing this line was a crutch to allow both methods to work until binman conversion was complete on all boards?

I understand the shebang line:
forums.freebsd.org

Solved - [Solved] What is the PROPER shebang for a new perl port?

Greetings, I get annoyed by the output generated by (type)script. That is; the output has windows line endings (CRLF) maintains the ANSI control sequences (for replay) I whipped up a simple perl script to clean up the offending items. Then thought it might be (especially) useful for the...
forums.freebsd.org forums.freebsd.org
Just not sure about two options on it.

Wondering if my BL31 ArmTrustedFirmware got built. One way to find out. Got to start testing.
 
I did not. It did seem to update itself OK.
Code: 
TIMESTAMP = 1688870559
SHA256 (u-boot/u-boot-2023.04.tar.bz2) = e31cac91545ff41b71cec5d8c22afd695645cd6e2a442ccdacacd60534069341
SIZE (u-boot/u-boot-2023.04.tar.bz2) = 19130089


The whole BL31 Arm Trusted Firmware is weird to me.
U-Boot builds its own but we have one in ports too?

Why?
Code: 
atf-rk3328-v2.8.0_1            ARM TF-A for platform rk3328
atf-rk3399-v2.8.0_1            ARM TF-A for platform rk3399
atf-sun50i_a64-v2.8.0_1        ARM TF-A for platform sun50i_a64
atf-sun50i_h6-v2.8.0_1         ARM TF-A for platform sun50i_h6
 
That makes sense.
Also I thought about BL31 used in arm64 EDK2 builds too.
I dunno if they link too?
 
u-boot ports build it as a dep for certain boards. sometimes it gets embedded in the u-boot image, sometimes in trust.img seems board dependent
 
Look at the error again. It's telling you the distinfo file is out of date or the file name is incorrect. I would pose that the file may be available but the checksums don't match because the distinfo is for the 2023.4 version and not for the 2023.7 version.

distinfo does not update automatically, it is updated after a "make makesum" command in the port's directory. Then you should check the downloaded file's checksum in /usr/ports/distfiles directory against the known checksum supplied by the download repository.
 
How do you add a dash to a PORTVERSION ?

PORTVERSION "2023.07-rc6" may not contain '-'

I tried single and double quotes.
 
Thanks Everyone for your help. Tag must have been cut late last night.
I deleted distinfo and ran make clean, make and then make makesum. Then make again.
Leading to a successful build.

===> Staging for u-boot-nanopc-t4-2023.07
 
So far I have built these successfully on 2023.07 for testing.
sysutils/u-boot-rock-pi-4
sysutils/u-boot-rock64
sysutils/u-boot-rpi3
sysutils/u-boot-cubox-hummingboard
sysutils/u-boot-beaglebone
sysutils/u-boot-bananapi


These failed to build:
sysutils/rockpro64
Code: 
/bin/sh: ./scripts/gen_ll_addressable_symbols.sh: not found
gmake[2]: *** [Makefile:1718: keep-syms-lto.c] Error 127
gmake[2]: *** Deleting file 'keep-syms-lto.c'
gmake[2]: Leaving directory '/usr/ports/sysutils/u-boot-rockpro64/work/u-boot-2023.07'
===> Compilation failed unexpectedly.
 
Anatomy of a botched launch?
source.denx.de

Tags · U-Boot / U-Boot · GitLab

"Das U-Boot" Source Tree
source.denx.de source.denx.de

One day after release a flurry of fixes? Gulp.

I wonder if and what branch we update u-boot-master to.
With this using .02 suffix in name I can easily adjust that versus a dash in release candidates.

I like this master port solution. Making a personal port couldn't be easier.
Add a defconfig to a Makefile and see if if will build.

Plus if you need to build an old version it is as simple as rolling back master for the one slave build.
 
You must log in or register to reply here.
Back
Top