<stikonas>fossy: since it might be that we'll need to go gcc3 route, maybe postpone bash rebuild and xz till after that? We can still merge libtool 2 though <stikonas>pder: hmm, we still need to deal with fixincludes even in gcc3 <stikonas>gcc 3 (or 2) might not be much easier then <stikonas>fossy: pder: maybe the easier option is to build gcc4 but do not use top level configure and Makefile? <stikonas>I think that is much simpler than trying to build guile with gcc <pder>Is fixincludes necessary? Maybe gcc 4 could be done in two passes First pass avoids top level Makefile.in. Then build guile and autogen, then second gcc pass is a normal build. <Hagfish>that would be a really smart solution if it works <fossy>stikonas[m]: hm that might work... <bauen1>pder: as far as i know you should be able to get away without fixincludes as that is usually used to "fix" broken system headers, but if we control all headers there should be no harm in patching it out <gforce_de1977>i was looking on ebay for an 386DX40 with 8MB RAM for letting bootstrap run on real hardware, and there are really selling people such (working!) stuff for ~100 euro. so booting from floppy, and install all the stuff on IDE-HDD + swap-partitions is maybe possible <bauen1>a swap partition would make things incredibly slow (with just 8mb ram) <bauen1>and i wonder if every program run fits into those 8mb, if yes then it could work good enough, it will be slow <bauen1>gforce_de1977: better question: how do you plan on loading the first bytes into memory ? <gforce_de1977>fossy: ofcourse, also 2mb is ok if you strip some things out (!) <gforce_de1977>why not? 2 megabyte if a huuuuuuge amount of memory if you think about it. <fossy>linux is a monolithic kernel though <fossy>also mescc will become very very very slow <fossy>if you do end up doing this though i would love to hear about it <fossy>that is on my wishlist for live-bootstrap :) <gforce_de1977>bauen1: the first bytes into memory? floppy disk! on x86 we have a BIOS, it's ofcourse cheating somehow, but... <gforce_de1977>speaking of the 2mb memory: i have a mips box (a wifi router) lying around, where i want to testbuild a initramfs-linux with nothing (only serial console). i know that a full openwrt - webserver, ssh + wifi (!) runs on this box with 8mb ram, but yeah, kernel 2.4.37 <stikonas>newer openwrt need much more RAM... I have a DSL modem with 32 MB RAM and maybe it would work with 16 but not any fewer <stikonas>and it's just a modem, so no routing or wifi <gforce_de1977>stikonas: thats clear, but thats because of extended userspace and a lot of kernelmodules loaded <gforce_de1977>i will start to add a wrapper, which calls find first and adds the full path <stikonas>one example would be ./miniperl -Ilib $< lib/*.pm lib/*/*.pm from sysa/perl-5.6.2/mk/main.mk <bauen1>gforce_de1977: but how do you write the floppy disk in the first place lol <stikonas>yeah, I'm not convinced that floppy disk and old computer would give us more than modern one <stikonas>only full bootstrap with visible optical components can help here... <stikonas>or at least something that can read data from paper tape <bauen1>i have a 65c816 based computer, add an sd card writer, some bit switches and an array of leds and you can hack in the first 512 bytes per hand into the sd card <bauen1>using bit switches you can even program a rom by hand with a monitor for the 65c816 ; so you can probably get away with just an eeprom, ram, 65c816, sd card rw and a few additional gates to do that <gforce_de1977>bauen1: ok, i think we will just wait for universitis building single board computers with dip switches. when you ask about the first bits in memory, thats really hard 8-) because for now we rely on a kernel which is just "there". our initial binary seed will not work without a kernel. <OriansJ>gforce_de1977: depends one which binary seed you use. The stage-posix binary seeds absolutely need a POSIX to work but the bare-metal seeds have no such requirements. <OriansJ>stikonas: yes paper tape is certainly an auditable option, the reader/writer need to have an auditable design otherwise it could be possible for firmware inside of it to tamper with what is read/written. <OriansJ>bauen1: I have reservations about SD cards because they have internal software running with KB of RAM and up to 4MB ROM but probably would be fine if they are older than the architectures they are used to bootstrap. <bauen1>but if you implement verification of the storage medium you can in theory use any untrusted medium (such as an ssd), you just need to verify every blob you read before you use it <OriansJ>bauen1: assuming you have enough ram to do so and solve bootstrapping the verifier in RAM without using that medium. <OriansJ>it is certainly a much easier task if the untrusted medium isn't used until after you get a kernel with a crypto filesystem support <OriansJ>a proper luks volume and a checksuming filesystem like btrfs should be sufficient <OriansJ>Which the /boot should be able to fit on a 50MB Zip Disk or optical media <gforce_de1977>OriansJ: great, that there is a binary-seed for bare metal, i have overlooked this ***pgreco_ is now known as pgreco
***Noisytoot is now known as noisytoot[x]
***noisytoot[x] is now known as Noisytoot
<stikonas>fossy: pder: so I've got gcc 4.0.4 building without pre-gen <pder>stikonas: nice work. did you have to work around fixincludes? <stikonas>well, need to test whether gcc is functional... <Hagfish>do you have a pre-computed hash you are expecting to see, or are you checking that a chain of self-builds reaches a fixed point? <Hagfish>(it's funny to think that by reaching gcc 4.0.4, we're now starting to focus on code that is younger than most computer science undergraduate students) <stikonas>Hagfish: no, I just build it and calculate the hash of that build <stikonas>one rebuild should be enough to get rid of all tcc issues... <stikonas>we still need to build autogen soonish... <stikonas>but that should now be a bit easier with GCC... <stikonas>I'll update PR soon (probably just push to libtool PR) <stikonas>not sure why libtool PR is failing now... <stikonas>I can't reproduce it in either chroot or qemu <stikonas>but GCC PR changes the way gcc is built... <stikonas>anyway, building gcc core with just C backend without top-level Makefile is not too bad <stikonas>but for full GCC with C++ I think we should try to get Autogen <fossy>guile is in-progress, should be OK <stikonas>ok, my commit works, just need to update bash checksum <stikonas>but that is the very last thing in the build, so next build should work <OriansJ>gforce_de1977: the initial build of the bootstrap binaries is always an implementation detail left to the person needing it. Be it hand toggled into RAM, read from punched cards or some other implementation detail. That is for the person do in a manner they trust. Everything else after that is the natural result of applying tools to sources. <stikonas>I guess bash checksum was affected because I didn't run fixincludes... <OriansJ>As for why the native x86 port isn't further along. Short version POSIX was prioritized to help janneke and Guix get their root of trust first and the handful of pieces could be done at a more relaxed pace. <stikonas>also POSIX is easier, especially to automate, so makes sense to start with a bit easier stuff <OriansJ>stikonas: actually it was a compromise as porting things such as Mes or TCC to run on bare metal appeared as a big problem but Writing a Minimal POSIX in the M2-Planet C subset seemed possible (if not annoying to do) <OriansJ>The manual steps to M2-Planet could be done in a relatively short period of time (Depending on the speed of media change of course) (90 seconds of compute time on a 1MHz CPU and a couple MB of RAM) <OriansJ>But the pieces after M2-Planet absolutely needed a POSIX and 1+GB of RAM to run <OriansJ>with considerably longer build times <OriansJ>So in theory stage0 from hex0 to M2-Planet should run on a 386 with 4MB or RAM <OriansJ>Which should give us a huge set of systems we could bootstrap from and get a working POSIX kernel to do the rest to GCC+Linux+Guile <OriansJ>One could say I am stuck in too many directions: Do M2libc, M3 work, stage0-CPM, stage0 bootstrap work, custom FPGA work and custom Hardware work. And most of my free time is being spent with my son. <Hagfish>if he grows up knowing what a cool dad he has (who wants to spend time with him), and then gets into a project like this when he's old enough, then that's a completely valid long-term strategy :D