IRC channel logs

<fossy>Googulator: yeah i'm already aware why initramfs generation is failing, i think initramfs generation is working now locally but not kexec, i'm working on it now

<Googulator>that's interesting as I had kexec working already

<Googulator>(with broken initramfs, so Linux dies trying to start userspace, but good enough that I got penguins on the screen on bare metal)

<Googulator>what's your kexec size (defined, confusingly, in kexec-fiwix)?

<Googulator>I run with this:

<Googulator>#define INITRD_MB 1280

<Googulator>#define KEXEC_MB 256

<Googulator>(kexec-fiwix originally hardcodes KEXEC_MB, I made it a define for easier tweaking)

<fossy>oh, kexec in and of itself works, the boot just does not complete

<Googulator>where does it break?

<Googulator>does it get to where it's looking for init?

<matrix_bridge><Andrius Štikonas> Googulator: somewhat confusingly tcc 0.9.26 in live bootstrap is not 0.9.26

<Googulator>Is 0.9.27 really 0.9.27 though?

<matrix_bridge><Andrius Štikonas> Yes

<Googulator>Cosinusoidally now has it working (to an extent)

<Googulator>Testing/hacking on it right now

<matrix_bridge><Andrius Štikonas> And "0.9.26" is about 8 months or so before

<matrix_bridge><Andrius Štikonas> Rather than 5 years

<matrix_bridge><Andrius Štikonas> It's nice to have alternative bootstrap path

<matrix_bridge><Andrius Štikonas> Thou it is really x86 only :(

<Googulator>isn't tcc x86-only in general?

<Googulator>Maybe it's sacrilegious for some, but another platform where bootstrap now works with my builder-hex0 PRs is Hyper-V: https://github.com/ironmeld/builder-hex0/assets/16308406/71da451b-2ac7-4b6c-b38b-23c7c7dac77c

<Googulator>this would previously black screen in stage1, just like my Asus board in IDE mode

<Googulator>It still fails when trying to get into Fiwix

<Googulator>"Starting fiwix.ext2 at addr 0xf0002000"

<Googulator>that address doesn't look right...

<fossy>"where it breaks" is currently continually changing, as i go through the cycle of testing and fixing

<Googulator>I'm currently testing with this: https://gist.github.com/Googulator/3a8b84b29dfe4c2601ffd92f48d69c6f

<Googulator>I also changed the kernel file name in linux's build sh file to match the usual convention of /boot/vmlinuz-$(uname -r)

<Googulator>added move_disk.sh since that's modified too

<fossy>i have a bit of a different solution in the works, skipping the use of gen_initramfs_list.sh entirely because on my system at least it is particularly slow and can be replaced with a few find commands at least in our case...

<fossy>i've also modified kexec-linux to allow an argument to be execution of a command (ie, reading from a pipe), which avoids writing the initramfs to ramdisk, further decreasing the required RAM space

<fossy>i appreciate your testing & enthusiasm but as i've said a few times i am currently working on the exact same issues with the PR, and i'm not really having any issues solving these problems, they're pretty straightforward, so we're kind of duplicating work right now - which is totally fine if you want to do that, it just might not produce any changes to the tree

<matrix_bridge><Andrius Štikonas> Googulator: tcc supports at least x86, x86_64 and risc64

<matrix_bridge><Andrius Štikonas> well, riscv64 support is more limitted

<matrix_bridge><Andrius Štikonas> it is only supported in tcc mob and bootstrappable tinycc, but right now not on 0.9.27

<matrix_bridge><Andrius Štikonas> but live-bootstrap on ricv64 can run all the way till tcc 0.9.27 step (and then of course it fails)

<fossy>no arm?

<fossy>also, gotta say it's a little bit funny that stikonas managed to get the matrix_bridge nick :P

<oriansj>I think that is just a side effect of the matrx bridge itself, I don't think it has anything to do with the fact that stikonas is the one maintaining the bridge

<fossy>mes 0.26, nice, looks like we are getting module uspport

<Googulator>Is the build of mes-tcc supposed to be super memory bandwidth intensive?

<Googulator>I noticed it's more than an order of magnitude slower on my Core 2 Duo/Quad bare metal systems than in qemu on a Zen 4

<Googulator>Linux kernel build is only about 2x slower on the same system

<Googulator>The only thing with such a massive difference between the two seems to be RAM

<Googulator>10 vs 90GB/s bandwidth

<Googulator>(and core count of course, but there's no SMP in builder-hex0 to take advantage of that)

<Googulator>Clock/IPC difference explains the Linux build time, but not mes-tcc

<fossy>i do believe the build of mes-tcc is highly memory intensive, yes

<fossy>not sure why though :)

<fossy>might just be a side effect of mes

<Googulator>Seems to not just use a lot of allocated RAM, but also do a lot of memory IO

<Googulator>How does Fiwix decide where to allocate ram1 (the kexec ramdisk)?

<Googulator>I have this in the log: ram1 0xc44b7700-0xd44b7700 RAMdisk of 262144KB size, 1KB blocksize

<Googulator>Seems to work OK for me, but that's potentially MMIO address space

<Mikaku>Googulator: the memory layout of the Fiwix kernel is explained in the file 'docs/kmem_layout.txt', but I'm not sure if your patched kernel matches with that file

<Googulator>Alright, got to a fully booted Linux kernel, and successfully built curl using the new codebase - only to die of a stupid error (I accidentally inserted the "create swap" code in 2 different locations, and they conflicted)

<janneke>snuik: later tell artimist: just learnt about your aarch64 work for mes, you'll want to rebase onto mes branch version-0.25 which has quite some 64bit fixes (because of riscv64)

<snuik>janneke, you have 2 messages

<snuik>janneke, ekaitz says: truncate-shift might be garbage

<snuik>janneke, ekaitz says: setjmp... you have to talk with stikonas for that

<snuik>Will do.

<janneke>snuik: botsnack

<snuik>:)

<ekaitz>old messages janneke

<ekaitz>but still true

<janneke>hmm, it seems /me has been too quiet for some time :)

<ekaitz>:)

<ekaitz>busy with 0.26

<janneke>yeah

<janneke>phew

<janneke>i didn't know about this aarch64 effort!

<ekaitz>:)

<janneke>people just start to work on mes without even thinking to ping me...

<janneke>mes is starting to mature, i guess

IRC channel logs

2023-12-04.log