IRC channel logs
2024-10-21.log
back to list of logs
<stikonas>timafrolov: Hi, so we mostly have riscv64 userspace bootstrap path mapped out and working, but not fully implemented in live-bootstrap <stikonas>probably userspace bootstrap should be finished before we think about kernel bootstrap... <stikonas>for kernel, we need some early kernel and intermediate kernel as you have said <stikonas>perhaps we can reuse (unfinished) stage0-uefi stuff for early baremetal bootstrap <stikonas>If I remember correctly uefi/x86_64 I was able to bootstrap up to tcc-mes (which sometimes segfaults on x86_64 userspace bootstrap too, though a bit later... Anyway my "kernel" would need more features before tcc-mes works) <stikonas>pure non-UEFI bootstrap would probably need to be done on a per SoC basis... <timafrolov>stikonas: Hi. Is there a place where I can look at riscv64 bootstrap path and see what is working and what is not? <stikonas>timafrolov: I can share some documentation, it's still a bit raw but better than nothing <timafrolov>As for early kernel - I see only amd64 support in stage0-uefi so I am not sure how reusing it is different from reusing stage0-posix with riscv port of builder-hex0 project <timafrolov>stikonas: yeah, I would really like to see any documentation. Should I provide you with an email address to send it or you can just send link? <stikonas>basically most of the live-bootstrap path works (I haven't tested perl / autotools but presumably they should work) <stikonas>efraim: is also working on integrating that in Guix <stikonas>timafrolov: builder-hex0 is kind of the same, that kernel is somewhat similar to porting it to C <stikonas>but what I'm thinking is that riscv doesn't have BIOS <stikonas>so you can't just write something portable that can print to script and do disk operations <stikonas>so you either need to write builder-hex0 kind of thing specific to your board <stikonas>or we can assume UEFI (which in practive likely to be U-boot but does't matter I guess) <stikonas>but anyway, nothing is complete there... <stikonas>so it's up to people who do work to decide <stikonas>timafrolov: also bootstrappable tcc has a small missing bit <stikonas>we have a version that works on riscv64 but not on x86 and vice versa <stikonas>it would be nice to fix it, so it works on both <stikonas>this revert breaks riscv64 and restores x86 support <stikonas>this is probably the main blocker for non-hacky upstreaming to live-bootstrap <timafrolov>I'm not sure wheter api that uefi gives will be sufficient (tbh, never looked at uefi). If i recall corectly, in raw machine (or supervisor) mode on risc-v even interaction with interrupt controller could differ a little from board to board so portability could be a problem <timafrolov>but I guess we can have builder-hex0 kind of thing that requires only little tweaks (e.g. adding disk operations and interrupts controller handlers at bottom of file) in order to work on specific board <timafrolov>tcc problem looks interesting, maybe I will take a look at it <timafrolov>and about gcc 4 backport - is it functional? (Can it compile things that are used later in the bootstrap process?) <stikonas>well, UEFI gives us file I/O (so higher level than disk i/o), output to screen (potentially keyboard input too but I haven't looked at it) <stikonas>timafrolov: yes, gcc 4 backport can compile at least binutils and gcc 9 <timafrolov>oh, okay, then assuming UEFI sounds really convenient <stikonas>M2libc already has UEFI support, so that's good in principle, though early hex stages of course are somewhat different <stikonas>UEFI API is harder to use than POSIX API <stikonas>well, I suggest, let's start with finishing userspace bootstrap, then do UEFI, and if you like you could then bootstrap pure machine... <timafrolov>Isn't translating POSIX API calls into UEFI API calls what early kernel supposed to do? <timafrolov>Bon appetit. I probably will go sleep by the time you return, so if you have anything more to say - I will read it in logs in the morning. <stikonas>timafrolov: yes, but given the complexity of writing hex code for riscv64, it's probably easier to postpone kernel itself till you have C <stikonas>even builder-hex0 does minor cheating, it kind of is written in hex2 and then gets autotranslated into well commented hex0 <stikonas>and significant chunk of functionality is only needed for later post-C stages <stikonas>now builder-hex0 has a small early stage that knows hex0 and can build much larger 4KiB kernel (real builder-hex0) <stikonas>I guess if somebody would start writing x86 builder-hex0 from scratch, one could instead do early loader that then loads next small loader that knows hex1 and then next one that knows hex2 and that could build 4 KiB kernel from hex2. But oh well, I don't think this will happen now <stikonas>timafrolov: well, basically posix-runner now does exactly that, translates POSIX API calls to UEFI API calls, though it misses some other things that kernel really needs... <stikonas>timafrolov: in particular I need to add at least a bit of support for paging, right now only relocatable binaries work, and on UEFI we can't put child processes in hardcoded locations <stikonas>(of course that stuff is all very platform specific, riscv64 kernel would need quite a bit of porting) <stikonas>alternatively, we could read all files into memory shut down UEFI services and then we have more control <stikonas>but we would have to implement other parts of the kernel then, basic FS should be easy enough, probably directly port from builder-hex0. But we would also have to deal with display framebuffer, etc... <Googulator>yeah, builder-hex0 has it easy because it can (ab)use the VGA BIOS & VGA text modes - in the UEFI world, and especially on arm/riscv, "text mode" doesn't exist <Googulator>(UEFI allows, but doesn't require, exposing native text modes pre-ExitBootServices) <stikonas>all those additional features: paging, fs and framebuffer output would basically make it a proper kernel rather than UEFI program... <stikonas>but yes, builder-hex0 has some things easy... <stikonas>so it can act as a kernel without any support for paging or framebuffer <Googulator>Even without BIOS, it could get away with directly writing the "native" VGA text mode "frame" buffer, something you can't do on systems without VGA compatibility <Googulator>At the same time, it's kind of cheating from a free software standpoint: after all, what is the license of the font embedded in your VGA controller's hardware? (You usually can't know.) <Googulator>I'd argue it's relevant in this case, as the hardware manufacturer might try to abuse copyright to claim that the bootstrap's visual output is owned by them <Googulator>although it certainly doesn't affect Trusting Trust-resistance <matrix_bridge><Jeremiah Orians> Well fonts could be simple if we are ok with ascii only for the early bootstrap <stikonas>ascii is probably sufficient for bootstrap