<pmjdebruijn>
yeah I'm trying to see to add n2+ support to buildroot
buzzmarshall has joined #linux-amlogic
<chewitt>
lots of prior art in LE, Armbian and Yocto
<pmjdebruijn>
yeah
<chewitt>
and N2/N2+ share the same u-boot sources
<pmjdebruijn>
I guessed as much
<pmjdebruijn>
I wonder if meson-tools could be used instead of the binary tools
<pmjdebruijn>
but it's amazingly conveluted
<chewitt>
the missing bit, which should really be done in u-boot not in distros, is to detect aa revC chip and presence of the n2-plus.dtb and amend the FDT used for boot
<pmjdebruijn>
I must admit that having petitboot on the N2+ is rather nice, being able to boot a kernel in no-time is really nice
<chewitt>
meson-tools = no, because G12B is not supported
<pmjdebruijn>
it's allowed me to boot my self built kernel without being forced to setup uboot first
<chewitt>
petitboot is a workaround for vendors too lazy too get their products properly supported in upstream distros
<pmjdebruijn>
now I know I have a good kernel, I can circle back to uboot :)
<chewitt>
I keep the switch to the right :)
<pmjdebruijn>
once I get uboot to build right, I'll probably too
<pmjdebruijn>
my main point being, having options is nice
<pmjdebruijn>
oh crap that depends on mbedtls
<pmjdebruijn>
oh wait, it's in-tree
plntyk has joined #linux-amlogic
kaspter has quit [Quit: kaspter]
<buzzmarshall>
chewitt's right... petitboot is a pain as u-boot is much more capable and the trade off of having kexec based warm boot isn't worth the trouble it causes
<buzzmarshall>
if your interested in kernel dev and testing just use tftp to mount the kernel and file system
<buzzmarshall>
warm boot can be accomplished in other ways that still use u-boot if one wants to be creative
cmeerw has joined #linux-amlogic
<pmjdebruijn>
I never argued that petitboot should replace uboot in any way
<pmjdebruijn>
chewitt: have you used meson64-tools yourself?
kaspter has joined #linux-amlogic
<pmjdebruijn>
ah wait, I was missing a file, and mkboot failed silently
<pmjdebruijn>
still no joy
<pmjdebruijn>
oh wait
<buzzmarshall>
sorry i didnt mean to imply you were... just agreeing with chewitts statement about lazy boardmakers who should no better but decide to depend on the public to do their grunt work
<pmjdebruijn>
chewitt: meson64-tools seems to be missing the bl1 (as in the first 444/512 bytes)
<pmjdebruijn>
buzzmarshall: I don't disagree :)
<pmjdebruijn>
yep, when I extract the BL1 (first 444 bytes) from the blob generated by the propriery tools, and use the rest of the meson64-tools generated blob, I have a booting system
<pmjdebruijn>
chewitt: is there another way to get the bl1 generated? if not, could I convince you to put the bl1 in your firmware repo as well?
yann has quit [Ping timeout: 264 seconds]
vagrantc has joined #linux-amlogic
yann has joined #linux-amlogic
kaspter has quit [Quit: kaspter]
ldevulder_ is now known as ldevulder
<chewitt>
BL1 is in the SoC itself, it is never generated
<pmjdebruijn>
chewitt: there something that needs to be in the first 444 bytes, and meson64-tools isn't generating it
<pmjdebruijn>
meson64-tools generates fip/u-boot.bin and not fip/u-boot.bin.sd.bin (that's the version with the extra 512 byte prepended)
<pmjdebruijn>
hardkernel seems to call it bl1
<pmjdebruijn>
whether that's technically correct is a different matter
<pmjdebruijn>
the proprietary tools DOES have that extra 512byte
<pmjdebruijn>
in fip/u-boot.bin.sd.bin
<pmjdebruijn>
so it figures you've not noticed this
<pmjdebruijn>
this issue is specific to meson64-tools' mkboot
<chewitt>
ah, ok
<chewitt>
i've not used it
<pmjdebruijn>
I loathe sticking to a binary only tool
<pmjdebruijn>
not even sure buildroot would accept that
<pmjdebruijn>
but now I'm faced with having to put/source a small binary file from somewhere
<pmjdebruijn>
if you were to put it into your repo, I'd have a coherent source of binaries
<pmjdebruijn>
other than this I have meson64-tools working
sputnik_ has joined #linux-amlogic
sputnik_ has quit [Ping timeout: 246 seconds]
sputnik_ has joined #linux-amlogic
benoitm974 has quit [Quit: Connection closed]
benoitm974 has joined #linux-amlogic
<benoitm974>
So I change board since the initial H9 X3 received was not Gigabit, switch to H96Max X3
<benoitm974>
Was able to extract device tree with script from hexdump, dumping the u-boot boot message, and the boot log from android, I'll start playing with an armbian and booting from the SDcard