IRC channel logs
2026-05-24.log
back to list of logs
<aggi>reading recent discussion (forth), curious how this relates to early platform initialization <aggi>with the assumption, this is the earliest stage where bootstrapping begins <aggi>and how a simple "BIOS" would be implemented in forth, to poke a few registers for address space layout initialization etc. <aggi>of cause, at this stage of bootstrapping, typically there is no c-compiler nor macro assembler available <aggi>this is just hidden by the fact, almost always systems are shipped with some firmware (bios, uboot, etc) deployed already <xentrac>are they? I guess it's pretty common, even like Arduino <aggi>xentrac: didn't play with arduino yet, only noticed programming such devices often needs heavy IDE tooling (Eclipse and whatever) <aggi>remembering the same with some Motorola 68k programming, to poke a few registers this required a heavyweight windows computer with some IDE <aggi>ups, connection loss (awful usb-ethernet dongle) <aggi>anyway, i guess even with forth the early platform initialization is a major challenge for bootstrapping, and unresolved with any known approach <matrix_bridge><Jeremiah Orians> aggi: the solution is simple but ugly. You need 2 systems. An 8bit (with 16-24bit address space) cpu which we can avoid most initialization problems entirely which then can be used to create the bootstrap for a 32/64 bit cpu which can go the rest of the way. <matrix_bridge><Jeremiah Orians> A 200byte wozmon is sufficient to bootstrap from and ultimately get to M1 and then a proper bootstrap bios is just a manual exercise of implementing a specification. <matrix_bridge><Jeremiah Orians> The commanderX16 presents a well thought out to achieving 24bit address space with only 16 address pins <aggi>certainly not trivial. other than the transition 16bit->32bit the 6502 is a different ISA than X86 <aggi>and i'm scratching my head over the fact most modern x86 systems can and do operate in 16bit real-mode just fine <aggi>this is what typical boot loaders do, switching from real-mode into protected-mode <aggi>but it just seams not feasible to hack something bootstrappable for platform initialization with x86 <aggi>even when AMD FM2 type systems are 100% open source (coreboot/seabios, https://15h.org documents a few variants both server and cheapo consumer desktop boards) <aggi>the whole ACPI/AGESA codebase is huge <aggi>and it needs a gigantic GNU toolchain to compile <aggi>a bootstrap for a commanderX16 (Z80, etc. 16bit type system) is feasible, but it seems almost impossible to bridge the gap towards x86 from there <aggi>then, when i'm reading FPGA involved... the type of development utilities needed for that were not available at the time when c64/z80 etc. were common <aggi>all this seems gone missing nowadays, the hardware design and development tools that existed on 16bit systems to develop/bootstrap later 32bit ones <aggi>goes without saying, a GNU toolchain may not suitable for hosting on 16bit systems even with 24bit address space available, as far as firmware compilation was concerned <xentrac>aggi: you can program an Arduino with some debounced DIP switches, and even the Arduino IDE is just a wrapper around avr-gcc and avrdude <xentrac>early platform initialization is not really a major challenge for most CPUs <aggi>i tend to disagree xentrac, depending on what "most CPUs" were, that is in practice ARM/aarch32/64 and X86_32/64 <xentrac>where it gets complicated is when you want to do platform initialization that runs on many different systems. do we have RAM? how much? let's try to enable the RAM now. is there a PCIe bus? etc. <aggi>for the former you would need to compile uboot and atf firmware, with gcc <aggi>but with bootstrappable acceptance criteria GNU toolchain is NOT available at the time when platform initialization has to be done <xentrac>"X86_32/64" is a tiny, tiny minority of most CPUs <aggi>you can't compile uboot/atf, same with coreboot/seabios (and that's a rare case a few boards got free/open firmware with sources available at least) <xentrac>those are to solve the problem where you don't know what platform you're initializing <aggi>depends, if a bootstrap shall bridge the gap, from lets say commanderX16 towards x86 <xentrac>where you have to start with "do we have RAM? how much? let's try to enable the RAM now." because, like, the user may have upgraded the RAM since the machine last powered off <aggi>well, ok, it's probably too feasible to strip most of the ACPI junk, and start X86 in non-SMP mode then <xentrac>it would be good to delineate precisely what threat model you want to defend against, if defending against a threat model is what you're up to <aggi>or, lurking at older coreboot versions at the time when ACPI wasn't common <aggi>it's less of a threat-model concern than a principle engineering one <xentrac>I mean, if you want to avoid relying on bootloaders, probably you also want to avoid relying on field-upgradable microcode? <aggi>i didn't yet dig into "microcode" specifics, f15h.org merely mentioned some of this was open-source <aggi>bottom line, modern computers had to be avoided entirely for compliance with acceptance criteria <aggi>development got stuck at 16bit era 1980s (and earlier) systems <xentrac>also easier to program. even if Thumb2 is not the friendliest machine code it's a lot less suffering than 8086 <aggi>i'm almost certain all of those (ARM etc) are stuck with build-time circular dependencies, regardless of ISA specifics <aggi>and the platform initialization with ARM in particular, is at least as problematic as x86 was <xentrac>ARM doesn't have platform initialization at all <aggi>what's the ATF and Uboot doing then? <xentrac>what has platform initialization is whatever SoC the ARM is built into, and that can be very simple <xentrac>you're talking about, like, laptops with PCIe buses and stuff. you don't need any of that <aggi>depends, on, let's say, requirements, if any bootstrapped systems shall be capable to navigate internet, have some ethernet and TCP/IP stack <xentrac>that's mostly irrelevant to whether you have PCIe buses and stuff <xentrac>TCP/IP is mostly just a matter of software. you can run lwIP on anything <aggi>anyway, for that matter i kept in mind AX.25 as another side-track <xentrac>USB and Ethernet is probably extra complexity you can avoid. Stick to PPP, PS/2 keyboards, and SD/MMC mass storage <xentrac>I mean there are plenty of SoCs with built-in USB peripherals, and initializing them doesn't require anywhere close to the complexity of ATF <xentrac>because you know which USB peripheral is present on your chosen chip and you can just set its registers to the tested values. you don't have to go probing through different setups to figure out which USB hardware is present at each boot or which bugs it has <aggi>in practice however, i am not aware of any such SoC/SPC bundled with software to launch a mutt mailer type of thing <xentrac>and it's doable in a fully bootstrapped way <xentrac>maybe I shouldn't be so confident about something that nobody has done, but it seems clear to me that it's doable, just a lot of work <aggi>i've paused hacking when tumbling over cdrtools/syslinux/isolinux - that 16bit ASM had not been compiled for 10years (according to gentoo ebuilds) <xentrac>hmm, I imagine Debian's copy gets built from source regularly <xentrac>they're kind of fanatical about fixing FTBFS bugs (or removing the packages) <aggi>the 16bit real-mode isolinux.bin pieces? probably not. and even when, it's not done bootstrappable style <xentrac>over the last week I've been looking at cheap hardware on LCSC. I'd previously mentioned that you can get 74HC08s for 4.22¢, but did you know you can get NP0/C0G capacitors for 0.03¢, 1% resistors for 0.05¢, and 0.1% resistors for 0.25¢? <xentrac>and although I don't think you're likely to be able to run a self-hosting toolchain on it, you can get an 8-MIPS microcontroller for 2.1¢, the PMS150G-U06 <aggi>good to know this competence arrived here <aggi>i can't say much about 8/16bit systems, merely had programming z80 on my hobby wish list for a little while <aggi>too reminds me of the many assembler variants involved for x86/16bit: nasm, yasm, fasm, gas, as86 <aggi>isolinux was hacked with nasm iirc, don't remember what syslinux chose, and linux2 had both as86/intel and gas syntax variants <aggi>thanks for the friendly chat; i'll notify once i made a little progress with cdrtools/isolinux ported to live-bootstrap <xentrac>my cousin programs old Z80 game systems all the time. it can be a fun puzzle, figuring out how to do things with such a limited system <xentrac>8086 is already a lot less frustrating, but ARM assembly is almost as high-level as C <matrix_bridge><Jeremiah Orians> Also a full tcp/ip stack already exists for the Commodore 64 <matrix_bridge><Jeremiah Orians> Also with a couple MB of RAM, large enough external storage and a little clever work making a 32bit sweet16 vm; you could simulate a much more powerful architecture and use it to build pieces that you needed if you really wanted to solve it the hard way. <matrix_bridge><Jeremiah Orians> A 486 bios for a machine with 4GB of RAM is plenty powerful enough for live-bootstrap and could easily fix in less than 32KB of ROM and could be written in M1 assembly <xentrac>yeah, Contiki ran a couple of different TCP/IP stacks on the C64; one of them was uIP, and the other was lwIP, which is what I was mentioning above. Contiki grew to support a lot of microcontrollers later on, and now contiki-ng is supporting a bunch of new microcontrollers I've never heard of: https://docs.contiki-ng.org/en/develop/doc/platforms/index.html <xentrac>as I understand it, it's a 100MIPS RISC-V microcontroller with 240KiB of Flash, 12KiB of RAM, and built-in Bluetooth LE <xentrac>microcontrollers don't normally use bootloaders at all, and system initialization is a question of setting some peripheral registers to values you've previously decided to set them to <xentrac>sometimes you use bootloaders during development to speed up the feedback loop