<anton[m]>
Is there anyone able to help with review and merge?
dev_mohe has joined #nixos-aarch64
dev_mohe has quit [Client Quit]
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 260 seconds]
luxemboye has quit [Remote host closed the connection]
luxemboye has joined #nixos-aarch64
h0m1 has quit [Quit: WeeChat 3.1]
h0m1 has joined #nixos-aarch64
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
superherointj has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
luxemboye has quit [Remote host closed the connection]
luxemboye has joined #nixos-aarch64
justanotheruser has joined #nixos-aarch64
<samueldr>
I need to actually take time to look into it... but I'm not too thrilled with the prospect of relying on a non-mainline U-Boot after we were able to remove all non-mainline U-Boot uses recently
<samueldr>
hm, though I see it's for "firmware" stuff, not U-Boot per se
<samueldr>
my lack of confidence / hands-on experience with Amlogic stuff doesn't help
<samueldr>
but isn't the S905 series of chip able to be used blob-free?
cole-h has joined #nixos-aarch64
<samueldr>
at least, I saw that TF-A (ATF; arm trusted firmware) supports(?) S905 recently
<samueldr>
anton[m]: you won't really like it because it means it won't be merged quickly, but I have a new clearer plan for better support of any meson platforms that I'm looking into implementing on top of your changes
<samueldr>
e.g. I don't have any odroid boards to test with, but I do have an amlogic board I could, and it just struck me how to tie this all up together better
<samueldr>
and it should allow me to better test the change
<anton[m]>
samueldr: I am actually happy, and happy to test whatever you have in mind on the boards I have.
<samueldr>
anton[m]: is there a particular reason for going with the OEM u-boot repo for the binaries?
<samueldr>
I'm thinking about switching (from armbian) to LibreELEC's which has AFAICT the better collection
<samueldr>
should make adding support for other amlogic boards much easier since it's a common source
<anton[m]>
I used OEM as those were more stable for me on C2 boards couple years ago. To be honest I don't remember what was the difference when I digged into couple years ago. As long as the boards stable I am ok. My motivation to use OEM is based on better experience.
<samueldr>
right
<anton[m]>
I'll look at LibreELEC, I don't mind to give it a time to run and see how stable it is
<samueldr>
anyway the way I'm thinking of doing it it should be a cinch to use any other source as a replacement
<samueldr>
something similar, not sure yet if it'll be a discrete input per component (allowing BL31 from TF-A to be switched in through an override) or a single input for all blobs
<anton[m]>
yes, makes sense
<samueldr>
oh, and TF-A for S905 is already in your build
<samueldr>
[for the C2]
quinn has quit [Ping timeout: 252 seconds]
rajivr has quit [Quit: Connection closed for inactivity]
<samueldr>
anton[m]: were you using the `sd_fusing.sh` script?
<samueldr>
AFAIUI it's just a convention from hardkernel
<samueldr>
for amlogic boards it just writes the binary starting at sector 0x01 (0x00 being the first sector)
<anton[m]>
samueldr:
<samueldr>
not sure if you just highlighte me or something didn't come through the matrix to irc semantics
<anton[m]>
* samueldr: it is convention. I used ready script to put it along with u-boot so that someone could use it to flash the card right away.
<samueldr>
right, I'm thinking that none of the U-Boot builds in Nixpkgs provide scripts of the sort
<samueldr>
I'm not entirely against, but I don't see it as being really needed in the end
<anton[m]>
I feel like it is a good thing. Though I had in mind, after this patches be merged, to make the changes so that it would be possible to generate entire sd_image with the uboot in it
quinn has joined #nixos-aarch64
<anton[m]>
for odroid boards
<samueldr>
in Nixpkgs?
<samueldr>
that's going in the direction I'm trying to bring things about
<samueldr>
against
<samueldr>
important word to forget to include in the edit :(
<samueldr>
let me rephrase
<samueldr>
I'm trying to remove as much board-specific "weirdness" as possible from Nixpkgs
<samueldr>
I'm still kicking myself from adding temporarily a raspberry pi 4 disk image build
<samueldr>
it probably created wrong expectations
<samueldr>
oh, I see now that the C2 and C4 builds are *really* different
<anton[m]>
hmm... do you mean you would ideally see one image that fits all? (this arm boards are really crazy, even though it became better with aarch64, comparing to arm32 zoo)
<samueldr>
kind of
<samueldr>
it's already the case in fact
<samueldr>
mostly
<anton[m]>
I don't think it is possible to remove the weirdness, though make it somewhat sane - perhaps
<samueldr>
end-users have to assemble the firmware in the disk image when the firmware is not provided in a dedicated storage (e.g. SPI NOR Flash)
<samueldr>
and except for the Raspberry Pi, it is mostly a successful strategy
<samueldr>
... and then I am working on the side on a new strategy that will obsolete even that strategy... hopefully
<anton[m]>
cool, do you have this all ideas somewhere in git or written? I'd be happy to follow
<anton[m]>
and help, if I can
<samueldr>
I'll ping you later either this week or next week
<samueldr>
anton[m]: you have a C4, right? do you also have a C2?
<anton[m]>
samueldr: yeah, I have couple C2s and C4s
<samueldr>
good, also helpful to confirm we are not breaking the C2 build with the changes
<samueldr>
oh, I see it's in yuor "Things done" :)
<anton[m]>
there was a guy with HC1, which is similar to C4, he confirmed the changes working for him either
<samueldr>
I wonder if we can make the C2 and C4 build use the same tooling
<anton[m]>
nope ... at least not for signing the blobs, I found a weird reverse-engineered (my best guess) signer for C4. meson64-tools package, which has a benefit of being able to compile for aarch64. the proprietary one is x86_64 only.
<anton[m]>
meson64-tools does the work, though I'd be happy to have something instead. I don't believe I will ever have time to re-write it myself. :)
* samueldr
learned maybe more than desirable about amlogic init setup
<samueldr>
I could not test against a C2 or C4, having neither, but `xxd` comparisons tell me that the only real difference here at the end is with the specific blobs used
<samueldr>
according to the U-Boot documentation, this should be usable with 9 other boards as-is
<samueldr>
and some of the preparations here should make it usable for 9 other U-Boot supported boards