Page MenuHomeFreeBSD

u-boot: Update to v2018.01
ClosedPublic

Authored by manu on Feb 6 2018, 9:53 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Mar 23, 8:06 AM
Unknown Object (File)
Dec 22 2023, 11:14 PM
Unknown Object (File)
Nov 16 2023, 12:29 PM
Unknown Object (File)
Nov 9 2023, 8:15 PM
Unknown Object (File)
Nov 1 2023, 4:37 PM
Unknown Object (File)
Oct 15 2023, 11:31 AM
Unknown Object (File)
Oct 8 2023, 6:59 PM
Unknown Object (File)
Sep 30 2023, 4:35 PM

Details

Summary
  • Track upstream directly We cannot build u-boot directly on FreeBSD as it needs gmake, gsed etc ... Earlier update dealt with that using BINARY_ALIAS to avoid patching. The cache patches have been sent upstream (a V2 is needed as some arch don't have those functions) so put them in the ports tree for now. This is the only patches needed to build a u-boot for armv6/armv7/arm64 so do not use the freebsd github fork anymore as they will go away soon.
  • We now use boot.scr (converted with mkimage from sysutils/u-boot-tools) instead of patching u-boot. U-Boot have two way for dealing with distribution, one is boot scripts and the other is extlinux. extlinux will be harder as we use raw binary for ubldr and use go $address, this cannot fail and the boot process could be in a bad state so this is something that upstream doesn't want to merge in mainline. boot script are easy to write and compile and also give a way to the user to customize it's boot (printing a message, setting variable etc ...)
  • CONFIG_API isn't defined by default so use a configuration fragment and generate our final config with scripts/kconfig/merge_config.sh Other configuration value could be added in the futur. For now only arm uses it as we don't use CONFIG_API on arm64.
  • Switch the maintainer to uboot@freebsd.org

Tested-On: RPI2
Tested-On: Pine64-LTS
Tested-On: BananaPi-M2
Tested-On: BeagleBone Black

Diff Detail

Repository
rP FreeBSD ports repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

I'm a little uneasy about un-forking, but we're past the craziness of the past so maybe it's OK so I'll approve it.

sysutils/u-boot-master/Makefile
120 ↗(On Diff #38974)

I'd add a comment here that says we do this for CONFIG_API, but only on arm.

121 ↗(On Diff #38974)

why not plain 'else'?

sysutils/u-boot-master/files/patch-boot.cmd
5 ↗(On Diff #38974)

I'd put this file and Fragment into files as plain files and copy them as needed.

This revision is now accepted and ready to land.Feb 6 2018, 10:27 PM
ian added inline comments.
sysutils/u-boot-master/files/patch-boot.cmd
5 ↗(On Diff #38974)

This should probably be

fatload ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} ubldr.bin && go ${kernel_addr_r}
echo Cannot load ubldr.bin
This revision now requires review to proceed.Feb 12 2018, 6:58 PM
manu marked 2 inline comments as done.Feb 12 2018, 6:58 PM

Just be curious, this patch would affect many u-boot-* which are slave port of this, and they might not be tested before this patch hits the tree. Should we provide a co-existing new or old version of u-boot-master port and migrate the slave ports to new version one by one after tested?

Just be curious, this patch would affect many u-boot-* which are slave port of this

There are a couple of ways I can see going forward.

My proposal (which imp dislikes intensly) is to have:

  • one u-boot-master-foo port that works exactly like the current one (tracks the FreeBSD u-boot fork). This remains the default masterport. All the packages we build on the cluster will be from this one.
  • one u-boot-master-bar port that tracks the upstream (unforked) u-boot. This would be assumed to be for developer use/testing only. Developers could ("somehow") specify that for their own testing, to use this one as the masterport.
  • one u-boot-master-bar-devel port that tracks the upstream (unforked) u-boot, but the prerelease candidate. This would be assumed to be for developer use/testing only. Developers could ("somehow") specify that for their own testing, to use this one as the masterport.

I have an incomplete snapshot of my patches in D14314.

I'm completely uncaring about what the names are.

The problem is that imp hates all this, and, in fact, has indicated to me that he disagrees with the whole approach in this whole differential revision.

I am blocked on doing any commit until we can find some approach that both imp and manu agree on.

Just be curious, this patch would affect many u-boot-* which are slave port of this, and they might not be tested before this patch hits the tree. Should we provide a co-existing new or old version of u-boot-master port and migrate the slave ports to new version one by one after tested?

If you have a good way to do that please tell me.
As noted in the summary I do test on different board. I cannot, of course, test every port but testing one board per family is perfectly fine. I think that @ian tested imx since he tested using efi and this will need latest u-boot.
I plan to commit this version this week unless someone have any other objection. (I was waiting to see if the EFI breakage was U-Boot or FreeBSD fault, it was us and it's fixed in r329517).

Just be curious, this patch would affect many u-boot-* which are slave port of this

There are a couple of ways I can see going forward.

My proposal (which imp dislikes intensly) is to have:

  • one u-boot-master-foo port that works exactly like the current one (tracks the FreeBSD u-boot fork). This remains the default masterport. All the packages we build on the cluster will be from this one.

As the one who updated u-boot the last 3 or 4 time, I can say that using the freebsd fork is much harder than using upstream directly.
It also not motivate us to upstream our change and I believe we will soon be in the same case than before, having a lot of patches (except that instead of being in ports repo they will be in the fork repo).
Using config Fragment and U-Boot script is much easier than patches as this will not break (unless something shitty happens in U-Boot).

  • one u-boot-master-bar port that tracks the upstream (unforked) u-boot. This would be assumed to be for developer use/testing only. Developers could ("somehow") specify that for their own testing, to use this one as the masterport.

The upstream version must be the one we track.

  • one u-boot-master-bar-devel port that tracks the upstream (unforked) u-boot, but the prerelease candidate. This would be assumed to be for developer use/testing only. Developers could ("somehow") specify that for their own testing, to use this one as the masterport.

This I want, but I'm not sure what's the best way to provide that.

I have an incomplete snapshot of my patches in D14314.

I'm completely uncaring about what the names are.

The problem is that imp hates all this, and, in fact, has indicated to me that he disagrees with the whole approach in this whole differential revision.

I am blocked on doing any commit until we can find some approach that both imp and manu agree on.

I think that we (@imp and I) mostly agree, in fact he accepted this review.

In D14230#302519, @manu wrote:

Just be curious, this patch would affect many u-boot-* which are slave port of this

There are a couple of ways I can see going forward.

My proposal (which imp dislikes intensly) is to have:

  • one u-boot-master-foo port that works exactly like the current one (tracks the FreeBSD u-boot fork). This remains the default masterport. All the packages we build on the cluster will be from this one.

As the one who updated u-boot the last 3 or 4 time, I can say that using the freebsd fork is much harder than using upstream directly.
It also not motivate us to upstream our change and I believe we will soon be in the same case than before, having a lot of patches (except that instead of being in ports repo they will be in the fork repo).
Using config Fragment and U-Boot script is much easier than patches as this will not break (unless something shitty happens in U-Boot).

I think moving to all these things are fine.

I plan on maintaining the FreeBSD fork such that one could checkout from upstream and use patches, or from our fork with patches pre-applied. I have some bitmap stuff that I'll need to stage there first. The pain of updating the fork is the motivation to merge upstream, imho, though I'd submit that git rebase to do the update is 100x easier and faster than what we had to do in the past before you got involved :)

With one patch, it's a wash imho whether we should do it one way or the other, which is why I'm cool with manu@ switching to upstream + 1 logical patch. If we don't grow more patches, that makes sense. If we do, then I want things to be the same either way, so all those changes are nothing but good, as manu correctly points out. I personally hate patches in the ports system, but that's mostly due to the state of the world before where we had half a dozen ports, each with similar patches, each needed to be regenerated after moving forward. It was an unbelieveable pain to cope with, which is why I have the visceral reactions I've had to it :) So to be clear, I'm good with manu's commit going in w/o further changes. I'd prefer if he also updated the freebsd-fork tree, but I will if he's declines when I need it for the bitmap stuff.

What I object to enough to yell "hold on", maybe because I don't grok how ports work well enough, is having two versions, especially with a split pull location. I do not see how that helps things. I get people want old packages easily available, but I don't see how to do that easily for all the boards short of having a separate port for each board. That way lies madness, imho. We've not bothered in the past to do this, and I think our testing matrix is sufficient that we need not do it now. We'll fix what's broken when people complain, otherwise I fear people will take the easy way, use the old stuff and not report it so it stays broken. So to move forward with that, I need to understand how it hooks into the ports system. How does the u-boot-pcduino3-oldrev package get generated and built? But we can hash out these issues elsewhere.

This comment was removed by lwhsu.

Had a talk with @manu and @imp on IRC, and I realized their thoughts that we probably don't need to have multiple version of u-boot-master ports, at least not for now.
Because:

  1. The chance to break multiple slave ports is rather small, most cases are tested.
  2. Revert one slave port to use previous working version of u-boot is easy
  3. We can re-add old version and devel version of u-boot anytime, not necessary to be now. It doesn't conflict with this update.

If we really break too many things, what we can do is:

I read the u-boot-master's Makefile again carefully, so slave ports can override UBOOT_VERSION and switch back to another version.

I would say I don't copmletely like this approach because if we keep the ability of allowing slave port overrides UBOOT_VERSION, the u-boot-master needs to maintain the compatibility of multiple versions, that makes u-boot-master's Makefile complicated.
This is probably not a big problem because we surely don't want to keep more than 2 versions. Having one for new, one for old is enough.
So the only thing we need to care is maintaining u-boot-master's distinfo well.

IMHO, just having u-boot-master* as separated directories is easier, each one can focus on its own version and adding -devel (RC) version is still easy.

And for pre-built binary packages:

Providing pre-built old packages on pkg.freebsd.org, like u-boot-oldrev-pcduino3, enables people fallback without building things themselves when u-boot-pcduino3 doesn't work, but the drawback is people might stay with the old version and never report that.

Don't provide legacy u-boot version on master might disappoint some people who find the only available version on pkg.freebsd.org, like u-boot-pcduino3 doesn't work. The might just give up without report anything.

Anyway, it is useless to worry too early. Let's see what happens and take the necessary action. Sorry for the noise, and thanks for the work!

Basically, the project doesn't have the bandwidth to support multiple versions of u-boot, unless there's a demonstrated actual need (not a theoretical need) to do so.
All board use the same version. Any board / SoC family that can will get a one or two release in upstream to get it fixed, then cut loose. We don't have the resources to support something so 'backwater' as to lose upstream u-boot support.
We depend heavily on upstream support, and if that ceases, the solution isn't to freeze that version. The solution is to delete the ports affected and drop support for the board.
To date, we've had no issues since the big switch supporting one version, though the infrastructure allows for one per family if needed.
I want only one version of packages. It greatly increases the support load to deal with old versions of u-boot and we get fewer complaints of breakage if recovery from breakage is easy. Since breakage is rare, we bias to fast discovery rather than bending over backwards to keep the user up and running. The cost/benefit ratio is far too low for this platform to be able to do that absent some compelling, as yet to be articulated, benefit.

Basically, the more time we can spend leveraging one version, the better job u-boot will be as a 'force multiplier' enabling us to have multiple ports at little to no cost. The higher cost the slave-port is, the less time we have to spend on other things.

I know some of this sounds harsh, but it's trying to set reasonable boundaries that deliver us the most benefit with the least impact on our limited developer resources. Given the recent history, I think these are fair boundaries. Should the fundamentals change (more talented hours for this coupled with more frequent breakage), of course we'll reconsider.

This revision was not accepted when it landed; it landed in state Needs Review.Mar 24 2018, 8:40 PM
Closed by commit rP465468: u-boot: Update to v2018.01 (authored by manu). · Explain Why
This revision was automatically updated to reflect the committed changes.