<Tartarus>
arm64 tends to use the efi boot stub, one way or another
<Tartarus>
And the normal debian/arm64 flow does that, yes?
<NishanthMenon>
rcn-ee: ^^ I think we do use the efi stub
<rcn-ee>
they use the efi stub too.. i guess i just got confused, everyone seems to build vmlinuz's with compression.. i've implemented your cat | gunzip -d and calling it good..
<rcn-ee>
trying to keep our tree generic, you know how off in the weeds we can some times get..
* vagrantc
waves
<Tartarus>
'everyone' who, for arm64?
<Tartarus>
but yeah, I guess a distro Image is gonna tend to get large so some form of compression on top
<rcn-ee>
everyone --- default arm64 defconfig in linux tree..
<Tartarus>
just confusing that it's not a self-decomp like before
<Tartarus>
rcn-ee: I don't see where the tree, rather than deb wrapper scripts, are making a vmlinuz
<rcn-ee>
it might be done in some random postinstall script..
<Tartarus>
Like, kernel-wise, lemme see if the doc is still saying what I think it does..
<j`ey>
for arm64 it creates vmlinux (not compressed) and Image (not compressed)
<rcn-ee>
vagrantc: in normal Debian, how does u-boot get an uncompress vmlinuz?
<j`ey>
and optionally you can: make Image.{gz, lzo, etc}
<Tartarus>
Yeah, vmlinuz==Image.gz in this case.
<Tartarus>
That's all it is
<vagrantc>
rcn-ee: it's been a while since i've done that manually, all the boards i work with use distro_boot ... either with a boot.scr that uses booti or extlinux (which maybe also uses booti under the hood)
<Tartarus>
and u-boot bootefi will check for some known comp magics and decomp, if set. But when handing off to grub, grub also handles that on its own
<vagrantc>
on a good day, i even use u-boot's UEFI implementation and just load grub :)
<vagrantc>
rcn-ee: debian's kernel packages build with uncompressed kernels
<vagrantc>
or at least, that's what they install
<rcn-ee>
ah! so just mainline's deb-pkg that doesn't have a special case yet..
<vagrantc>
possibly
* vagrantc
has always thought upstream linux's deb-pkg should produce packages as similar to Debian as reasonably possible but not everyone agrees apparently
<rcn-ee>
i agree with you..
camus has quit [Ping timeout: 256 seconds]
camus has joined #u-boot
<cambrian_invader>
vagrantc: IMO the in-tree generator needs substantial tweaking to be used in a debian system
<cambrian_invader>
I ended up just creating a debian directory and doing it myself last time
<rcn-ee>
i guess it's just confusing to vmlinuz in both uncompressed and compressed states..
<vagrantc>
ah, yes. debian's choice of name is ... foolish here.
<rcn-ee>
as an end user will just shove it into /boot/* and then wonder why it locked up?
<rcn-ee>
this would be silly, but we are using extlinux.conf, we could have an uefi program to figure out and uncompress it... (goes and hides. ;) )
<vagrantc>
by default uefi is loaded after extlinux ...
<vagrantc>
i did see some bootspec proposal that looked interesting a while back
m5zs7k has quit [Ping timeout: 256 seconds]
vagrantc has quit [Quit: leaving]
thopiekar has quit [Ping timeout: 256 seconds]
thopiekar has joined #u-boot
<samueldr>
for scripting mmc writes with U-Boot hush, is there any way to get the block size? I'm writing a generic script that should stay true for any platform, and using `$filesize` from `load` (and yes, `setexpr` I guess will be involved)
m5zs7k has joined #u-boot
ekathva has joined #u-boot
lowfi has joined #u-boot
sbach has quit [Read error: Connection reset by peer]
sbach has joined #u-boot
GNUtoo has quit [Remote host closed the connection]
GNUtoo has joined #u-boot
lowfi has quit [Quit: Leaving]
urja has quit [Read error: Connection reset by peer]
camus1 has joined #u-boot
camus has quit [Remote host closed the connection]
camus1 is now known as camus
dmh has joined #u-boot
urja has joined #u-boot
gsz has joined #u-boot
fdanis_away is now known as fdanis
gsz has quit [Ping timeout: 256 seconds]
ad__ has quit [Quit: ZNC 1.7.2+deb3~bpo9+1 - https://znc.in]
ad__ has joined #u-boot
frieder has joined #u-boot
mckoan|away is now known as mckoan
cpackham[m] has joined #u-boot
guillaume_g has joined #u-boot
mmu_man has joined #u-boot
milkylainen has quit [Quit: Ping timeout (120 seconds)]
milkylainen has joined #u-boot
ekathva_ has joined #u-boot
ekathva has quit [Ping timeout: 250 seconds]
ad__ has quit [Quit: ZNC 1.7.2+deb3~bpo9+1 - https://znc.in]
ad__ has joined #u-boot
sszy has joined #u-boot
ad__ has quit [Quit: ZNC 1.7.2+deb3~bpo9+1 - https://znc.in]
ad__ has joined #u-boot
ad__ has quit [Quit: ZNC 1.7.2+deb3~bpo9+1 - https://znc.in]
ad__ has joined #u-boot
matthias_bgg has joined #u-boot
tnovotny has joined #u-boot
monstr has joined #u-boot
tnovotny has quit [Remote host closed the connection]
tnovotny has joined #u-boot
ad__ has quit [Quit: ZNC 1.7.2+deb3~bpo9+1 - https://znc.in]
ad__ has joined #u-boot
ad__ has quit [Client Quit]
ad__ has joined #u-boot
ad__ has quit [Quit: ZNC 1.7.2+deb3~bpo9+1 - https://znc.in]
ad__ has joined #u-boot
apritzel has joined #u-boot
fdanis has quit [Remote host closed the connection]
<tg-bridge-bot-ub>
<Clamor_S> Header 2 is minimal iirc
<tg-bridge-bot-ub>
<Clamor_S> At least it is what u-boot tells in lof
mmu_man has joined #u-boot
<Tartarus>
Then yeah, we don't support that android image itself I guess, if there's just no dtb anywhere
<Tartarus>
That sounds like some rather old HW?
<Tartarus>
Or is the dtb embedded in some strange spot?
<tg-bridge-bot-ub>
<Clamor_S> This one
<tg-bridge-bot-ub>
<Clamor_S> Android is from pre-dts era
<Tartarus>
I think the bridge dropped something? This one what?
<Tartarus>
But yeah, ok, I assume old HW and so it's ATAG booting and it's a 2.4 kernel or something
<tg-bridge-bot-ub>
<Clamor_S> No, Asus T30 transformers on 3.1.10
<Tartarus>
If you can unpack the android image in to something normal, you can probably bootm it again, and if you're on modern u-boot, make sure to enable support for ATAG booting
<tg-bridge-bot-ub>
<Clamor_S> Ok, will try
ekathva_ has quit [Remote host closed the connection]
gsz has quit [Ping timeout: 256 seconds]
<tg-bridge-bot-ub>
Max has joined the Telegram Group!
zibolo has quit [Ping timeout: 256 seconds]
fdanis is now known as fdanis_away
sdfgsdfg has quit [Quit: ayo yoyo ayo yoyo hololo, hololo.]
mmu_man has quit [Ping timeout: 256 seconds]
monstr has quit [Remote host closed the connection]
<tg-bridge-bot-ub>
Antoni (@aat596) has joined the Telegram Group!
mmu_man has joined #u-boot
<tg-bridge-bot-ub>
<Clamor_S> Tartarus ATAG enabling worked, but it is set as XIP kernel
<kettenis>
so with some help from jannau we now have u-boot working on the Apple M1 Pro/Max machines
<kettenis>
which raises the question what I can do to make the nvme and spi series go forward...
___nick___ has quit [Ping timeout: 256 seconds]
sdfgsdfg has joined #u-boot
redbrain has quit [Ping timeout: 256 seconds]
gsz has quit [Ping timeout: 256 seconds]
<Tartarus>
Uh, sorry, most of the outstanding patches are about old enough to go in
<Tartarus>
I just grabbed TI stuff today, and I'm doing the usual dance around a Kconfig migration series
<Tartarus>
everything builds now, waiting for the before/after to finish so I can at least spot check for bad migrations
<Tartarus>
more platform patches is probably next up
<kettenis>
cool, thanks
brujah has quit [Quit: Leaving]
torez has quit [Quit: torez]
sdfgsdfg has quit [Quit: ayo yoyo ayo yoyo hololo, hololo.]
<Tartarus>
sjg1: Is there any way to rework the buildman logic so that if I'm building a range of commits, and have per-board rather than per-thread output directories, the board dir is re-used for each commit?