sdfgsdfg has quit [Quit: ayo yoyo ayo yoyo hololo, hololo.]
torez has joined #u-boot
persmule has quit [Quit: Leaving]
persmule has joined #u-boot
persmule has quit [Remote host closed the connection]
persmule has joined #u-boot
mmu_man has quit [Ping timeout: 256 seconds]
zibolo has quit [Quit: bye]
<apritzel>
Tartarus: so looking at the CI log, I take it there is no really nice way to satisfy all the external blob requirements for buildman?
<apritzel>
Tartarus: I use SCP=/dev/null BL31=/dev/null when running buildman manually, and that works for sunxi, but fails on most Rockchip, as some expect a valid ELF there
matthias_bgg has quit [Remote host closed the connection]
<kettenis>
is there a reason the CI can't make sure those are there?
apritzel_ has joined #u-boot
<kettenis>
we have an OpenBSD package for the sinxi and rockchip bl31 files
<kettenis>
so maybe there is a linux distro that has something similar?
<apritzel>
kettenis: just for *build-testing* in the buildman context you don't need the real binaries
<mps>
kettenis: alpine have some bl31 and sunxi targets
<apritzel>
getting the right bl31.bin per board is not trivial, and probably out of scope for buildman
<apritzel>
kettenis: I am curious what's in those OpenBSD packages, do you have a pointer?
<alpernebbi>
Debian and Ubuntu have an arm-trusted-firmware package as well
<apritzel>
and do you really call then "sinxi", or was that a Freudian typo?
apritzel_ has quit [Ping timeout: 256 seconds]
<mps>
sunxi I bet
<kettenis>
sunxi indeed; won't comment on the Freudian thing ;)
<kettenis>
basically builds sun50i_h6-bl31.bin, sun50i_a64-bl31.bin, rk3399-bl31.elf and rk3328-bl32.elf
<kettenis>
rk3328-bl31.elf I mean
mmu_man has joined #u-boot
<kettenis>
those don't have any board-specific customizations but for the rockchip and sunxi boards that seems to work just fine
<kettenis>
and the CI mostly cares about building stuff isn't it?
<apritzel>
kettenis: thanks. We started to introduce build options in sunxi TF-A, but so far nothing critical
<apritzel>
kettenis: yeah, as hinted above, the CI deals just fine with /dev/null
<apritzel>
at least for sunxi, which it just needs some binary for the final packaging
<apritzel>
Rockchip requires an ELF file to be *linked*, so you need a real thing. But maybe a dummy ELF would do?
<kettenis>
it needs to have three PT_LOAD segments
persmule has quit [Ping timeout: 276 seconds]
persmule has joined #u-boot
torez has quit [Ping timeout: 240 seconds]
<Tartarus>
apritzel: sjg1 has talked about adding some way for binman/buildman to know where to fetch known good blobs from.
persmule has quit [Remote host closed the connection]
<Tartarus>
I mean, how?
<apritzel>
Tartarus: which brings me some interesting question: can we host binary U-Boot board builds somewhere?
persmule has joined #u-boot
<Tartarus>
Well, if someone updates the Dockerfile to know where to fetch what blobs from and where, that'd be the first step
<Tartarus>
Then whatever needs doing so that binman/buildman know to search /over/there/
<apritzel>
Tartarus: because that would make so much more sense than letting *distributions* ship outdated firmware images for a random subset of boards
guillaume_g has quit [Quit: Konversation terminated!]
<apritzel>
Tartarus: is there some (web) server in the U-Boot universe that could host images?
Sout_ has joined #u-boot
<Tartarus>
There was a series a while back to "better" fake the binaries for CI I think
<Tartarus>
But wasn't followed up on feedback about
<apritzel>
Tartarus: that would be another option, and less complicated for buildman
torez has joined #u-boot
<Tartarus>
In that if we faked the blobs better in CI, but they still didn't boot, we could then make lack of blobs always a fatal problem and so that would make a nicer user experience, it would be good to make CI do something better
<Tartarus>
Given that our Dockerfile already builds grub, I don't see a problem grabbing or building some known things.
<Tartarus>
And then update the build tasks (GitLab and Azure are annoyingly similar but different syntax esp around multi-line things) to know BL31 or SCP or whatever is ...
<Tartarus>
And also-also, the series sjg1 posted recently to make amlogic be able to use binman instead may provide some hints on what to do for rockchip/sunxi as they have their own extra fun set of steps to make things Just Right
<apritzel>
Tartarus: I wonder if a simpler solution (/dev/null or dummy ELFs) would solve this also outside of the CI, so when people run buildman directly
behanw has joined #u-boot
<apritzel>
I built bl31.elf for rk3328, and that made most RK boards happy, except RK3399
vagrantc has joined #u-boot
<Tartarus>
I'm not a lawyer and we've never been formally working with any enough to get advise on distributing binaries esp once we start talking about TF-A and other blobs being in the mix.
<Tartarus>
I also don't know if I want people picking up builds from CI and using them since it's not tested on HW
<kettenis>
building binaries including blobs built from the official TF-A repository should be absolutely fine
<apritzel>
yeah, I think those are separate problems: providing actually working images and making CI builds work better
<kettenis>
but using vendor-provided binaries is very questionable
<apritzel>
kettenis: what vendor?
<apritzel>
I am tempted to check if I can use github's release feature to provide people with binaries for some Allwinner boards
<kettenis>
pretty much all of them
<kettenis>
allwinner, amlogic, rockchip
<apritzel>
kettenis: I mean most board or SoC vendors are not really involved in mainline U-Boot, are they?
<Tartarus>
Well, there's a flag for faking binaries now in buildman/binman
<apritzel>
and did I miss something for the M1? ;-)
<Tartarus>
But sunxi does things differently than imx8 which is the first/main user of that
<Tartarus>
ie some SoCs are "make FOO=/path/to/bar.bin" and others are "export FOO=/path/to/bin;make"
<Tartarus>
and then there's amlogic
<Tartarus>
afk call
<kettenis>
apritzel: I mean these vendors do provide TF-A binaries of some sort on various websites but don't specify a license at all or use a license that is so restrictive that you defenitely can't redistribute binaries that include that code
<kettenis>
for M1 we absolutely don't distribute any Apple binaries ;)
<apritzel>
kettenis: to be clear: it would be the community that provides those images
<apritzel>
kettenis: and for sunxi we are 100% open source / community built, we don't need any blobs from Allwinner
<kettenis>
right, that's my point
<kettenis>
for allwinner and many rockchip boards you can build fully open source firmware and there is no problem with distributing binaries
<kettenis>
some rockchip boards only work with the proprietary TF-A binaries and/or initial loader though
<kettenis>
and amlogic is a total thrashfire
<apritzel>
kettenis: well, I guess we can't solve that problem easily, but at least we can try to tackle those boards with are 100% free
<kettenis>
yup
<apritzel>
kettenis: are there firmware binaries to get an M1 booted, somewhere?
gsz has joined #u-boot
<kettenis>
there is a script to download those from Apple's server create a bootable environment from them
<kettenis>
then you can install the open source bootloader (m1n1 + u-boot) into that environment
<kettenis>
the idea is that Asahi Linux will provide an installer that runs that script and installs pre-built m1n1 + u-boot binaries
<kettenis>
at that point you have an UEFI environment that can just boot a standard arm64 OS
<apritzel>
mps: the TF-A build looks alright (there is not really much to it, really), but misses h616 and r329 as build targets (though mainline Linux support is not fully there for those yet)
<apritzel>
mps: and that's a good example why distros shouldn't be involved in firmware building: that's just a random subset of boards, not different from the other ones in the U-Boot tree
gsz has quit [Ping timeout: 256 seconds]
<kettenis>
we're pretty much in the same boat with OpenBSD
<mps>
apritzel: well, these targets are there because someone asked for them and someone added them
<kettenis>
we build a package with u-boot binaries for a random collection of boards that is basically just the boards that have been reported as working at some point in time
<apritzel>
I understand that, but it's still random, and from a distro point of view there is really no difference between a OrangePi PC2 and a Pine64 LTS
<kettenis>
we tend to update and use the most recent u-boot release fairly quickly
<apritzel>
kettenis: but your OpenBSD builds and mps Arch builds of U-Boot should not be different
<kettenis>
but we invariably end up with some u-boot binaries not working because they're broken in that release
<kettenis>
apritzel: I'm not contradicting you ;)
<mps>
apritzel: not Arch but Alpine, though I think Arch have similar builds
<apritzel>
mps: sorry, everything not Slackware looks the same to me :-D
<sjg1>
apritzel: Tartarus: Yes I have done that for bintools (like fiptool) and think it could be done for binaries too. But it is board-specific so needs some thought
<sjg1>
Tartarus: apritzel: For rk3399 I have a series in the works to move to binman instead of the bash script. I hope to send it out by Monday but we will see
<sjg1>
cambrian_invader: It works in CI and with 'make qcheck' but does seem to die with 'ut dm' sometimes. I have not dug into it. But I believe there is a malloc() failure at some point. We need a function to call to check that malloc() is healthy
<sjg1>
cambrian_invader: If I recall correctly, this is the var that gets corrupted in dlmalloc: top (av_[2])