IRC channel logs
2025-02-06.log
back to list of logs
<pabs3>ACTION mentioned bootstrappable.org <Mikaku>pabs3: I appreciate your comments, thank you! <Mikaku>I don't understand the order of the comments: a recent comment from you is placed at the top and another one also recent, almost at the bottom <nimaje>for one, comments can be a reply to another comment, so you have a tree structure there, additionally there is a voting system for comments and highly voted comments go to the top <Mikaku>nimaje: ah, perhaps I don't see the votes for each comment because I'm not registered <nimaje>no idea if anyone can see them or if they are just used internally, what you can see is the upvote button (the triangle at the start of the comment) and if some coment gets downvoted too much it will get grayer and grayer and eventually filtered (I don't have a hn account too, but read there sometimes) <aggi>seems, ~20years ago, C++ dependencies had remained cleanly separated from base system components written in C <aggi>GNU texinfo is just another example of important components that are affected by this <aggi>anyway, i can't comment on fiwix, since i don't use any "modern" web-browser either <aggi>the 16bit real-mode bootcode/bios issues aren't specific to fiwix, no clue why this argument got used to critize fiwix <aggi>to advertize risc-v, isn't commonly available, why 99% of all commodity hardware can run i386 fiwix bare metal <aggi>and to my knowledge risc-v hasn't got a _complete_ bootstrapping pather either, to avoid i386 being involved as development host towards risc-v <aggi>it's interesting however, for one or another the MIT v6 system retained PDP-11 target support instead of x86, until year 2006 <aggi>*while 99% of all commodity hardware (coffee didn't make it into my brain yet) <aggi>anyway, at Telekom University they had decided to throw Motorola ASM at the students <aggi>without any BIOS of cause, and beginning with initializing basic adress registers and similar <aggi>then again, university didn't bother with system integration concerns and bootstrapping paths <aggi>for digital circuit design you've just had to install some of their Altera Studio onto some micros~1 vista machine <aggi>only a few guys were smart enough, to proceed with their digital circuit design training with pencil and paper, connecting a handfull of PALs and GALs <aggi>i suspect, when switching from PDP-11 type systems to x86/i386, at university, a complete bootstrapping path that includes hardware-design is lost <aggi>a thing such as Gigatron TTL can be designed and constructed from scratch onto a breadboard, without relying on gigantic IDEs <aggi>*for one or another reason <lanodan>risc-v full bootstrap path should be possible, at least with considering flashing the bootchip to be a pre-bootstrap phase as x86 also gets away with a full on BIOS (or worse a UEFI system) <lanodan>Part of that being thanks to u-boot (which you put on the bootchip) effectively allowing to load an extlinux/extlinux.conf file <aggi>to my knowledge, there isn't complete (posix) toolchain and kernel support for risc-v, that avoided c++ (as an initial criteria) <aggi>tinycc/risc-v (another simplified criteria to look at) isn't complete yet, and you couldn't compile a linux kernel with it anyway <aggi>u-boot introduces a gigantic dependency graph circular dependency; finally, that's what i fear, RISC-V adds up compexity atop x86/i386 <lanodan>tcc mob works for riscv with making sure you don't pass -g <lanodan>And there's alloca missing on riscv but that's non-standard <aggi>excellent, but you couldn't compile a linux-kernel version needed... last linux kernel version that i could confirm was linux-2.4 <aggi>and that one didn't have risc-v on board; of cause there might be any other POSIX kernel for risc-v that tinycc could digest sources for <Googulator>what's missing on riscv is an early kernel like builder-hex0 or posix-runner <Googulator>and also possibly an intermediate one like Fiwix <lanodan>yeah kernel I haven't tried, so far just alpine's kernel + bootstrap-initrd and I only get stuck at compiling git due to lack of alloca <aggi>kernel, bootloader, firmware... there is a potential gigantic circular dependency to crack open, with risc-v, and this too implies avoiding i386 as intermediate development host <lanodan>Well bootloader is droppable, check u-boot docs really and that's the BIOS-equivalent stuff <lanodan>Otherwise it would be comparable to bootstrapping on non-PC x86 like the PS4 <aggi>i got a prognosis for risc-v, that is it will end up just like aarch32/64 did, without a complete bootstrapping path, and the need for most recent kernel and toolchain versions <lanodan>Well arm is one where even just getting mainline linux to boot up regardless of bootstrapping is a challenge <Googulator>and Arm at least has the SystemReady standards, most boards just don't care about them <lanodan>risc-v entirely has systemready equivalent and effectively that's why VisionFive2 can just boot up full mainline in a generic manner <Googulator>on x86, we're currently relying on residual "IBM compatibility" to simplify things (e.g. Fiwix expects IDE controllers at fixed addresses), something other archs never had <lanodan>Even platforms like sun sparc and macppc? <Googulator>AFAIK those used OpenFirmware, which is where DT comes from <Googulator>so any risc-v bootstrap would need to implement DT or ACPI parsing even in the "simple" kernels <Googulator>the only reason we can "cheat" on x86 is because OEMs copied IBM's address space layout, rather than adding a description language <Googulator>and ACPI then standardized much of that as "fixed devices" <Googulator>any ACPI system without "fixed devices" is "hardware-reduced", including all non-x86 systems <Googulator>sure enough, we can't currently complete a bootstrap on a "hardware-reduced" system <aggi>interestingly, the linux2.4/tinycc kernel that i salvaged does boot on various x86 hardware, without ACPI support <aggi>ioAPIC is needed for some USB/SATA controllers <aggi>to my understanding, APM and ACPI aren't equivalent, and i don't care if i have to cold-reset a system at the power-plug <aggi>the linux2.4 kernel even initializes SMP, without the presence of ACPI <aggi>anyway, i've had my fun with aarch32/64, fiddling together some custom firmware for rockchip/pro devices <aggi>and such type of system will _force_ you to update kernel/toolchain <lanodan>Yeah I just wouldn't put riscv in the same category as arm, specially rockchip where you're typically stuck to vendor kernels (like my rockpro64 annoyingly seems to be) <aggi>a rather simple criteria to have a look at: avoiding c++ completely, as either build-time or run-time dependence, direct or transitive <aggi>c++ must remain optional, and currently it isn't with either aarch32/64 nor riscv, if you wanted to end up with a posix development host <lanodan>Even with considering that opensbi+u-boot can just be on the bootchip and so get a bios exception? <aggi>last time i had a look at uboot, that introduced python/swig/c++ as build-time dependency, which can be fixed, but it's not trivial <lanodan>Yeah but coreboot has the exact same problems if not worse <lanodan>And I doubt Tianocore/edk2 is much better and that's just a bootloader. <aggi>if at all some coreboot support was available, exactly, and i haven't tried yet if at least tinycc could be hooked into <aggi>to compile coreboot itself <aggi>syslinux did pass with tinycc, but that's only some bootloader, not the bios/firmware <lanodan>yeah you'd need to compile seabios for this, otherwise the bootstrap would be different <aggi>and this too implies a circular dependency tinycc/tccboot <--> syslinux <--> tinycc/tccboot; simplified speaking <aggi>aarch32/64 and risc-v aren't much different, at least their uboot firmware is opensource, but it's not bootstrappable <aggi>i suspect MIT must have had their reasons, to keep their v6 PDP-11 on university schedule <aggi>until year 2006, and then switched to vx6 <aggi>recently they've ported it to risc-v, but i doubt the hardware design and implementation could have remained covered as it was with their PDP-11 variant <aggi>to my understanding MIT argument was, students were overloaded with PDP-11 and X86 lectured in parallel <aggi>i had quit at Telekom University 2005, for some reason <aggi>and nowadays receive regular blackmail and extortion letters from bureaucracy <aggi>the c++ madness too is something we've had to thank telekom for <aggi>anyway, there was _two_ "scientific calculator" series from texas instruments <aggi>one was built upon Z80 (TI83), and the "superior" design had chosen Motorola (TI89) <aggi>to my knowledge the Z80 series remained in prodcution, while the superio motorala design one went EOL <aggi>z80, that's the infamous 16bit real-mode <aggi>nowadays those TI scientific calculators are equipped with ARM, i couldn't care less <aggi>the superior motorola design already surpassed my intellect by far already <aggi>although we too covered digital circuit design, signal processing, and a gigangic load of other things, in three years, as a few other "hobbies" <aggi>compensated _below_ minimum wage <aggi>the last remaining telekom unversity in germany closed year 2021, 15 years after i had left <aggi>don't ask me what happened to Bell Labs, or any other of such entitites <aggi>to my knowledge the computer algebra system of TI83 and TI89 had never been opensourced <aggi>few month ago, german military was complaining, they had dumped almost 10billion cash into their military radio system upgrade <aggi>but things just didn't match specification or something, due to flawed system-integration <aggi>similar stories surrounding railway, that Telekom had outsourced X.25 for, and terminated support <aggi>they're throwing dozens of billions of cash at it too <aggi>for those few missing "hobbiest" pieces of real-mode assembler and hardware design, intel(R) demanded another 12billion from a german subsidy cash pot