IRC channel logs

<Googulator>aggi: I mean the "kexec()" system call that kexec-utils relies on when running under Linux

<Googulator>IIRC that was a 2.6 feature, which is why I'm asking if it's backported

<aggi>Googulator: thanks for the hint; grep -R kexec /usr/src/linux-2.4 doesn't show any

<Googulator>That's a major hurdle... it means, the only way to transfer from linux-tcc to a modern kernel is by rebooting

<Googulator>and that means block device access is required in linux-tcc

<Googulator>no way to do it in memory

<aggi>to avoid confusion, it's two scenarios: kexec(from builder-hex0/fiwix, to linux-tcc) which might work

<aggi>and kexec(from linux-tcc, to another-kernel)

<Googulator>yes - builder-hex0 has no memory protection, so you can "kexec" out of it just by loading a kernel into memory and jumping to it

<Googulator>Fiwix has memory protection, but implements a built-in kexec facility (AFAIK not the real kexec() system call - rather, you write the new kernel image to a special ramdisk device, and then issue a normal reboot)

<aggi>however, once linux/tcc/busybox are booted that yields an unrestricted development environment

<Googulator>yeah, but you still need to rely on the kernel for doing a kexec, or accessing block storage

<Googulator>if the kernel can't see your storage, and doesn't provide a way to transition to another kernel without touching storage, you're out of luck :(

<aggi>though lwext4-1.0.0-lb1 is compiled _before_ kexec

<aggi>but long story short, builder-hex0 does not provide block device access to disk to prepare that for root=/dev/hda whatever

<Googulator>that's a bit misleading - "lwext4" is really make-fiwix-initrd

<Googulator>builder-hex0 has implicit kexec support, by virtue of not having any memory management whatsoever

<Googulator>it keeps the memory map BIOS hands to it, which is what another kernel will expect when booted directly (i.e. not via kexec)

<aggi>so obviously the only route to bootstrapping linux-tcc is builder-hex0 -> kexec_fiwix and having a block device prepared for with ext2fs -> kexec_linux

<Googulator>The problem is that we can't expect a modern or future computer to have a block device Fiwix or linux-tcc can access

<aggi>assuming fiwix got block device access to disk, and/or i would not bother with a reboot into linux-tcc instead of kexec_linux either

<aggi>i see, fiwix got PATA/IDE support "only"

<Googulator>and even then, only if it actually emulates an IBM PC/AT IDE controller when viewed from the CPU side

<Googulator>I've not been able to make it work on a Core 2 Duo system

<Googulator>and that's not very modern already

<aggi>don't mean to blame fiwix in any way for this, it's a bliss fiwix got PATA/IDE support at least

<Googulator>but we don't use it, precisely because it's so fragile

<aggi>so, too chances are PATA/IDE emulation that various BIOS support for SATA/AHCI might not work either, i guess

<Googulator>yeah

<Googulator>I know it has issues with BIOS-based AT/PS2 keyboard emulation

<Googulator>as in, pressing Num Lock on a USB keyboard instantly locks up Fiwix, at least when booted via the fake-kexec we currently use to get from BH0 to Fiwix

<aggi>USB-storage is a discussion of it's own, even when USB was implemented with fiwix, interrupt controller (modern APIC i think) is a non-trivial thing needed for various USB controllers

<aggi>which contradicts the whole idea of Fiwix, to keep that sane and simple for bootstrapping and as a general purpose kernel

<Googulator>basically, you want to avoid interacting with hardware until you have a modern-ish Linux kernel

<Googulator>otherwise you will run into compatibility issues

<aggi>historically linux could be loaded from DOS, with loadlin.exe; but a FreeDOS type system is nowhere of being bootstrappable with extended hardware support either

<Googulator>I mean, ~99% of the Linux kernel code is dedicated to dealing with hardware

<aggi>*nowhere near

<Googulator>also, FreeDOS just does the same thing as builder-hex0

<Googulator>i.e. stay in the BIOS memory map, and use real BIOS calls for any hardware access needs

<Googulator>loadlin at its core is a "poor man's kexec" like what kexec-fiwix does

<Googulator>it relies on the CPU's memory management facilities being uninitialized

<aggi>which is too what various bootloaders do: syslinux, tccboot (which got support for disk access)

<aggi>but there's no way around of builder-hex0 which would need that too

<Googulator>so right now, we let BIOS load builder-hex0 (in 2 stages), use BIOS-based disk access just to load the srcfs into RAM in one go, then stop accessing hardware until we have a full-fat kernel

<Googulator>then, we use lwext4 to build an initrd for Fiwix (it has to be an initrd, because Fiwix has no ramfs/tmpfs/initramfs support), and poor-mans-kexec to Fiwix with that initrd loaded as a ramdisk

<Googulator>Fiwix does all of its work in that ramdisk, then once we have a Linux kernel, we write it + an initramfs to Fiwix's special kexec ramdisk, and "reboot" to trigger a switch to the Linux kernel

<Googulator>And that final step requires the Fiwix kernel's active assistance

<Googulator>so if we replace Fiwix with linux-tcc, we lose that transition

<Googulator>unless kexec() can be backported to linux-tcc

<aggi>currently the only way to arrive at any linux-kernel version is fiwix, in any case

<Googulator>If we can build any Linux kernel in BH0, we can poor-mans-kexec to it without issue

<Googulator>the problem is getting from that Linux to a modern one, without kexec

<aggi>i consider this a non-issue, since when i consider a reboot from linux to any other acceptable

<Googulator>For that, you need to trust linux-tcc's block device support on hardware it was never meant to run on

<aggi>it's not possible to write any rootfs to disk

<aggi>from bh0

<aggi>which contains tcc.bin and busybox.bin for example

<Googulator>you could, with BIOS calls - the problem is having the 2nd kernel (e.g. linux-tcc) access the rootfs from disk

<Googulator>To go from linux-tcc to linux 4.x, linux-tcc needs to write linux 4.x and its initramfs to disk, and then issue a reboot - impossible if the disk is NVMe

<Googulator>or if the storage controller is too quirky for linux-tcc to work with

<Googulator>(e.g. an emulated IDE controller)

<aggi>well, linux-tcc got support for usb-storage, pata/ide, sata/ahci, which is what _all_ x86 hardware got nowadays

<aggi>it's bh0 and fiwix whose hardware support is limited

<Googulator>yeah, support for the USB UMS, PATA and AHCI *standards*

<Googulator>that's not the same as real hardware

<aggi>it's a moot discussion, if linux could load it's rootfs from any of this, if bh0 and fiwix can't write to it _before_

<Googulator>much of modern Linux's massive HW support codebase is dedicated to working around hardware bugs & implementation quirks

<Googulator>We can avoid writing to disk before linux-tcc

<aggi>so far i've not had any issue with generic usb1/2 and sata/ahci and linux-tcc here

<Googulator>Do you test on bare metal?

<aggi>Googulator: yes, of cause, i'm running a linux-tcc development box on some AMD FM2 up and running for almost one year

<aggi>sata/ahci and usb-storage work perfect

<Googulator>oh, I assumed you were doing everything in a VM

<aggi>nope, bare-metal; i've too tested PATA/IDE and USB1/2 on some ancient thinkpad t40, that's x86 hardware spanning ~15years

<aggi>but i did not yet have access to modern Intel or AMD Ryzen

<Googulator>PATA and SATA on those systems can be rather challenging

<Googulator>because often it's some Chinese controller chip hanging off of PCIe

<Googulator>requiring vendor-specific quirks to work stable

<Googulator>Mainline Linux is full of workaround code for this reason

<aggi>and APIC support (which is what could bite fiwix too if anytime that desired USB support for example)

<Googulator>Yeah, but my proposal is to get rid of Fiwix completely

<Googulator>and have BH0 load linux-tcc directly

<Googulator>that's something we can even do in memory

<aggi>Googulator: for _practical_ reasons I tend to prefer BH0 -> kexec_linux-tcc directly too

<Googulator>The issue is getting _out of_ the linux-tcc environment

<aggi>but fiwix itself is a precious kernel, 50k lines of code, in comparison to 4milllion lines of code with linux-tcc

<aggi>well, for bootstrapping, linux-tcc is a fully capable development host

<aggi>the reason i blocked at linux-2.4 indefinitely isn't related to bootstrapping however

<Googulator>Fully capable, as long as you don't have to interact with weird hardware

<aggi>don't remind me, the backported usb-ethernet dongle tends to panic() still, if that's operated faster than 10Mbps

<aggi>but, at least, there is some common cheapo usb-eth that is stable at 10Mbps

<aggi>i've too updated the realtek Gigabit driver, it's working with either PCI or PCIe

<aggi>anyway, i've not yet fully recovered from the recent piles of cigarettes

<Googulator>having a kexec-like facility in linux-tcc would make it possible not to rely on linux-tcc's hardware driver code at all, keeping everything in memory until full-fat Linux is ready

<aggi>ok. the reason i picked up linux-tcc was to avoid latest linux versions to begin with

<aggi>of cause, you can bootstrap gcc and linux4/5/6/7 anytime, that's not been the main problem

<aggi>the problem was to salvage linux2 as the _main_ development host

<aggi>the issue isn't getting out of linux-tcc environment, there is no limitations to cross-compile and reboot into almost everything desired

<aggi>the problem is the gigantic dependency graph once you bootstrap beyond linux-tcc/x86_32/legacy-BIOS

<Googulator>But I see no hope of getting linux-tcc to work as an interactive OS for development use on generic hardware, unless you add driver code of comparable complexity to what's in modern mainline linux

<Googulator>Without that, it's always gonna be a matter of hunting down compatible hardware to run it on

<Googulator>Expect hardware that talks SATA to get increasingly rare (let alone even earlier storage interfaces like PATA)

<notgull>Yeah the reboots seem like the hard part

<aggi>that's the userspace parts already backported onto linux/tcc: http://tinyfront.mooo.com/downloads/x86-embedded/666666/tinyfront-packages.list

<aggi>all statically-linked and cross-compile confirmed; i guess that's sufficient to yield a capable development host for a very long time to come

<aggi>besides tcc/x86_32 i too kept the gcc/aarch32 cross-compile covered with this, so the entire userspace is portable towards either linux5/gcc and/or linux2/tcc still

<aggi>but i could not yet do this with the live-bootstrap configurator steps/; for this the initial package set would shrink a little

<aggi>gladly gentoo-portage emits complete build.logs, which helps a little with re-integration

<aggi>and i've had to block and fully fork gentoo/portage/python for this, it's a mess i rather not git-push in it's current shape

<aggi>which is the current development host here, a gentoo/linux-2.4/tcc synced against latest portage tree february 2025

<aggi>as for hardware support, i confirmed it's sufficiently stable on coreboot AMD/FM2 (year 2013), HP T620 thin client, and an ancient Thinkpad T40

<aggi>the aarch32/gcc variant is running on rock64 just fine, but i'll phase out this one, because it remains blocked indefinitely with fully bootstrapping this

<aggi>with regards to gentoo, the tcc/python.static/portage situation deserved another discussion; i'll phase out python/portage hence since the bootstrapping of it is covered elsewhere (midkid i think did it with gcc)

IRC channel logs

2026-10-06.log