<Armbian-Discord>
<rpardini> remember, we use flash-kernel which transports the dtbs, kernel, etc from their standard Debian places to the /boot/firmware fat partition
<Armbian-Discord>
<rpardini> "standard places" being /usr/lib et al
<Armbian-Discord>
<Tenkawa> but that extra /./ is suspicious
<Armbian-Discord>
<rpardini> not non-standard /boot/dtb
<Armbian-Discord>
<rpardini> yeah. fact the dtbs are even there suggest something is very wrong
<Armbian-Discord>
<IgorPec> "very wrong" 🙂
<Armbian-Discord>
<IgorPec> dtb package has dtbs
<Armbian-Discord>
<IgorPec> so i would suspect its something related to mount
<Armbian-Discord>
<IgorPec> partitioning? it says efi
<Armbian-Discord>
<IgorPec> what Oleg changed here?
<Armbian-Discord>
<rpardini> not accusing him no, I just though maybe something there related to partitioning
<Armbian-Discord>
<rpardini> indeed /boot/firmware is mostly empty now
<Armbian-Discord>
<rpardini> rpi firmware says his .elf bins are missing, and stops with firmware not found.
<Armbian-Discord>
<rpardini> so not only dtb, but all firmware missing
<Armbian-Discord>
<IgorPec> yes
<Armbian-Discord>
<IgorPec> this is done by flash-kernel scripts?
<Armbian-Discord>
<rpardini> yes, but if partitioning changed... what it does might end up in /dev/null or in the wrong partition
<Armbian-Discord>
<rpardini> I am debugging... long time no see this code
<Armbian-Discord>
<IgorPec> yeah, for me it was almost for the first time 😉
<Armbian-Discord>
<IgorPec> as i haven't check those rpi tricks
<Armbian-Discord>
<rpardini> you did fix the linux-firmware-raspi2 -> linux-firmware-raspi rename
<Armbian-Discord>
<IgorPec> yes, that package name changed.
<Armbian-Discord>
<IgorPec> hmm
<Armbian-Discord>
<IgorPec> no change if raspi2 is used
<Armbian-Discord>
<IgorPec> "Creating EFI partition [ FAT32 /boot/firmware on /dev/loop0p1 label RPICFG ]" this is ok?
<Armbian-Discord>
<rpardini> yes
<Armbian-Discord>
<rpardini> it uses the EFI partition as /boot/firmware, that was I think always like that
<Armbian-Discord>
<rpardini> thing is, flash-kernel is not doing anything and also not giving error
<Armbian-Discord>
<rpardini> still debugging... unfortunately update-initramfs with qemu is extremely slow, will take me a while
<Armbian-Discord>
<rpardini> yeah all indicates flash-kernel changed... so not any of us fault
<Armbian-Discord>
<rpardini> it now refuses to run in chroot by default
<Armbian-Discord>
<IgorPec> what?
<Armbian-Discord>
<rpardini> are you building jammy or kinetic?
<Armbian-Discord>
<rpardini> someone should rewrite (without making the wheel square) this, it's not complicated what it does; a kernel hook can work just as well and also work in Debian releases
<Armbian-Discord>
<rpardini> well, it's 100% broken, so it won't make it worse for sure 😉
<Armbian-Discord>
<IgorPec> haha
<Armbian-Discord>
<IgorPec> yeah, make a summary of what should be done to get rid of flash-kernel. i might take a look after we are done with releses
<Armbian-Discord>
<IgorPec> to jira
<Armbian-Discord>
<IgorPec> from head, no special research
<Armbian-Discord>
<rpardini> it's mostly the same as we have in postinstall for normal kernels... except instead o linking /boot/image, we need to copy the kernel and some other stuff to /boot/firmware
<Armbian-Discord>
<IgorPec> so we could actually add it to kernel postinst ?
<Armbian-Discord>
<rpardini> I think so, and do away with the whole flash-kernel, just keep it simple
<Armbian-Discord>
<rpardini> it's a hook today, it's setup in /etc/initramfs/post-update.d/flash-kernel
<Armbian-Discord>
<rpardini> just use a simple/our script instead
<Armbian-Discord>
<IgorPec> won't change this today. have to go off grid for few hours, then proceeding with bug hunt
<Armbian-Discord>
<rpardini> yep, I'm not doing it either. rpi4b is already back in drawer. found some TB2's now 😉
<Armbian-Discord>
<IgorPec> oh 🙂 that's even more troublesome
<Armbian-Discord>
<Tonymac32> I guess if we use blobs it's fine 🤷♂️
<Armbian-Discord>
<Tonymac32> Shortages brought a need for multiple RAM suppliers I guess
<Armbian-Discord>
<rpardini> Remember that ASUS's original blobs, cheap-RAM worked, but not i2c, spi, or anything else... so it's not fine... I am gonna test the new blobs someone sent soon
Armbian-Discord has quit [Remote host closed the connection]
Armbian-Discord has joined #armbian-broadcom
Armbian-Discord has quit [Remote host closed the connection]
Armbian-Discord has joined #armbian-broadcom
<Armbian-Discord>
<Tonymac32> I don't think any of the options are "cheap-RAM", but they certainly had different preferences for initializing
<Armbian-Discord>
<Tonymac32> I'm also curious how any of the rest was impacted by the ram blobs...
<Armbian-Discord>
<rpardini> true. I misspoke, it's not cheap, just different.