IRC channel logs
2024-07-21.log
back to list of logs
<andydude1>test/test1/hello.sh: line 37: 129 Segmentation fault (core dumped) ./test/results/test1-binary < test/test1/hex0.hex0 > test/test1/proof1 <andydude>I also had a question about code, are C and Scheme the only languages allowed? or would you also welcome bootstrap code in, say Lua or Wren? <nimaje>more bootstrap paths are better, even if incomplete, if you can connect your stuff to the live-bootstrap seed it would be nice, but if you assume lua and bootsrap stuff from that it is fine too <andydude>Wren is a super tiny OOP language, I really like it <stikonas>andydude: other languages are fine, but how do you bootstrap them? <andydude>well, Lua and Wren are both written in C <stikonas>stage0-posix contains two C compilers but both are quite limitted <stikonas>especially the first one that is written in assembly <stikonas>then M2-Planet is somewhat better but still far from C99 <stikonas>e.g. it doesn't even support stuff like i++ <stikonas>but if you can make lua or wren build with it, then why not <stikonas>porting a small program to M2-Planet is not too hard <andydude>I saw oriansj had some sub-repos for people who worked on UEFI stuff <stikonas>I was the only one who worked on UEFI as far as I know... <andydude>UEFI has a whole mini-OS that would be super useful if available <stikonas>but if you want to help with UEFI, any help would be appreciated <andydude>I know the edk2 repo like the back of my hand <stikonas>well, I started writing my own POSIX compatibility kernel <stikonas>but didn't spend that much time on it yet <andydude>I'm super familiar with C and Scheme, but honestly, I haven't experimented with mes/mescc <stikonas>I'm not super familiar with mes/mescc either <andydude>I can imagine maybe having two versions of each app, like an ELF version and a UEFI version <stikonas>andydude: so for stage0-uefi we have UEFI version of each app <andydude>you would need like EXT2 drivers at the UEFI to write to a file or something <stikonas>or wrote some posix loader that can run posix apps in UEFI <stikonas>at the beginning you can just use UEFI api to read stuff from ESP and write there <stikonas>if you want, one can read all the source data in the memory work there <andydude>well, UEFI has builtin support for FAT, so I suppose we could just depend on that <stikonas>I guess there are options forward with UEFI kernel <stikonas>1. read all the sources in the memory, shut down UEFI services and be a full kernel <andydude>you could install your own FS drivers, so make creating/writing files easier <stikonas>2. keep using UEFI API as long as possible <stikonas>well, one could use something simpler than fat... <stikonas>e.g. write a driver for file system that builder-hex0 implemented (for BIOS/MBR bootstrap) <stikonas>so far I just used FAT support from UEFI <stikonas>I haven't even implemented paging yet... <andydude>One thing I did on one of my laptops was get rid of GRUB entirely <stikonas>well, it is doable, though then you need to have unencrypted boot <andydude>I just put a little uefi-shell script at /boot/something.sh that calls vmlinuz directly with the command line arguments I wanted <andydude>super user unfriendly, but I like how I could just throw grub in the garbage! <stikonas>it does build quite a lot of stuff there <stikonas>including M2-Planet.efi (subset of) C compiler <stikonas>and some makefiles to create qemu images <stikonas>I did test it on my laptop too, but it hasn't seen wider baremetal testing <andydude>But ethically, is it wrong to depend so much on UEFI? <andydude>I've reverse engineered hundreds of vendor's interpretation of UEFI <andydude>for one, the memory training is always closed source <stikonas>well, you can do similar stage0 stuff on other architectures <stikonas>and we do have non-x86 posix versions of stage0 <stikonas>but for modern x86 hardware you can't start bellow UEFI... <andydude>The only other platform I have access to is too many raspberry pi picos <stikonas>stage0 doesn't use too many syscalls/services, you mainly need to be able to do i/o <andydude>iirc, the biggest hurdle with linux on the pico is that it doesn't have an MMU <stikonas>probably fine for most stage0 stuff but I guess harder to go further <andydude>the marketing website says "264KB of SRAM, 2MB of on-board flash" <stikonas>that's probbably enough to run hex0, hex1, hex2 and M0 <stikonas>probably not sufficient to run stage0 compilers <andydude>My dream would be to connect multiple picos, and have one running gcc, one running scheme, one running python, etc. and connect all of them to a bigger host with UART <stikonas>maybe you could tweak them a bit to move stuff form memory to flash <andydude>not sure if that fits with with bootstrapping <andydude>I must admit that the whole idea of starting out with a hex monitor is a little intimidating <andydude>There are so many other places I would start, but it seems like all of them have the possibility of introducing binary black boxes <stikonas>well, most stage0-* things start with hex0 <stikonas>so they expect source to be already on the media that is available for hex0 to read <andydude>TFTP is something that could be used to transfer binaries from another host, but again, how do you verify that it isn't something malicious? <stikonas>even if you can verity software, you will have fw and or hardware trust issues <stikonas>unless you run your own silicon fab in the garage <stikonas>but it's harder to do something malicious at lower levels <andydude>although he was more destroying chips than building them <andydude>Also, I think it's probably easier to trust microcontrollers at this point <andydude>I suppose the line drawn by this project is "we will not knowingly introduce any bad code" <andydude>This posix-runner would allow the binary to be in ELF format, and use linux-ish syscalls? <stikonas>well, any binary is a bit overselling it <stikonas>right now I think what works is only something that is built to be position independent binary and also have just a single text section <stikonas>former needs paging to support non-position independent binaries <stikonas>latter needs some improvements to elf header parser <stikonas>so in practice I think now stage0-posix-amd64 binaries work (appart from kaem-optional-seed) and stuff built using mescc <mihi>andydude: welcome. If you want to bootstrap a language that is not yet bootstrapped (fpc, ada, haskell, ocaml, to name the elephants in the room), you can use any language for it that is bootstrappeable (c, java, python, perl, ...) Only for bootstrapping the low level stuff (c, binutils, linux) you'd need to use lower level languages. Not sure about lua and wren - try to build the from the system that <mihi>live-bootstrap outputs (from tarballs where all generated files are removed), and if you succeed, they are bootstrappable. <mihi>Having a quick look at Wren, its build scripts are generated using premake5. Which itself uses premake5 to build. There is a bootstrap.mak and a bootstrap.bat (each ~150 lines), though. If they are not autogenerated and they still work to bootstrap the build system, it can be used to build the generated files of Wren. While Wren uses an intermediate bytecode, at quick glance I did not find any "precompiled" files <mihi>checked into source control. But that would be another thing to verify if you want to go that route. <mihi>(for reference, I did the bootstrap of gnu autogen - a code generator used to generate gcc's Makefiles - and of guile's syntax-case implementation) <stikonas>even if they are not adopted by upstreams...