<stikonas>I need to do the other ARCHes too before I can push <stikonas>but this will allow environmental variables to propagate from stage0-posix into live-bootstrap (e.g. ARCH will be defined) <stikonas>oriansj: I've now added M2-Mesoplanet into stage0-posix but it's not used there yet (I got segfault when I tried to build blood-elf) <fossy>stikonas[m]: when updating stage0-posix, often find mes breaks, so just be careful w that <gbrlwck>stikonas[m]: $TOOLS and $BINDIR are identical -- as intended? <stikonas[m]>gbrlwck: I'll check, it was just copied from other file <stikonas>gbrlwck: well, mescc-tools-extra kaem file makes distinction between TOOLS and BINDIR <stikonas>so I think yes, they are intentionally the same in AMD64/kaem.run <stikonas>fossy: after stage0-posix was refactored not to require that much tweaking on live-bootstrap side, I find that updating stage0-posix in live-bootstrap if fairly trivial <stikonas>it gets rid of arch.kaem.x86 file and renames kaem.run into after.kaem (this is the script that replaces stage0-posix after.kaem hook) <stikonas>fossy: btw, you mentioned that we need to build some older python first before we can get newer one <stikonas>or is it not sufficient to bootstrap proper python3 <stikonas>at least it seems to have a simple build system (just make) which generated headers on the fly <doras>stikonas @stikonas:libera.chat: nice! <oriansj>gbrlwck: they are identical simply because the TOOLS path (Where the tools we used to build are located) is the same as the BINDIR path (where we want the resulting binaries to be put). They are different variables to enable easier relocation. <doras>stikonas: I'm getting the following error: <doras>Unable to open for reading file: ../M2-Mesoplanet/cc.h <doras>Perhaps I need to somehow trigger the download process again? <doras>No, it comes from the submodule... <doras>I did run "git submodule update --recursive" though. Is it not enough? <doras>Wait, I was missing "--init" <doras>Yeah, it works now. "Hello,M2-mes!" <bauen1>it sure took me a while to join here ... <stikonas>bauen1: oh you were on old freenode network? <bauen1>i just switched laptops, barely configured my irc client, and just never had too much free time (because studying, building a satellite and live does that to you) <bauen1>anyway, i've had the following idea: i have a pine a64 lts lying around doing absolutely nothing, so i bought an external tpm module to have some fun with it, but then i also have a pine h64 that is also doing nothing, so i'm back to having a free pine a64 lts ; and i know it can boot from spi flash, and i have some laying around, and i want to program these by hand using dip-switches and get the <bauen1>a64 to boot from this flash chip <nanonyme>stikonas, interesting. I wonder if that micropython is actually one of the missing pieces bootstrapping to modern glibc (which requires Python to build) <bauen1>nanonyme: how does glibc depend on python ? <stikonas>nanonyme: normal python is also buildable, I was thinking of reducing number of steps <stikonas>bauen1: modern glibc indeed depedns on python <nanonyme>stikonas, when I built normal Python with live-bootstrap, math module failed to build and it was critical or being useful in glibc build process <stikonas>nanonyme: well, possibly need to update something first before building python <stikonas>but it shouldn't be something too cyclic <nanonyme>Yeah. Maybe not. I was mostly trying to glue our current bootstrap into what live-bootstrap outputs directly and noticed there were these subtle things that didn't work as expected :) <stikonas>but fossy said it's not there in python2, so one can build python2 and then run asdl.py with it <stikonas>nanonyme: some thing not working as expected I guess are still expected <stikonas>in particular because toolchain in live-bootstrap is still quite old <nanonyme>Yeah. We weren't really prepared to bootstrap from so old seed image <stikonas>but i think it's only a few steps to build newer binutils and gcc <nanonyme>It's probably doable, just requires a bit more glue <stikonas>but with binutils and gcc you either rely on pregenerated Makefile.in or use somewhat ugly hack where you don't use top-level configure file <stikonas>Makefile.in is generated with autogen and autogen is just hopeless <stikonas>well, most distros are of course happy with pre-generated non-source files (like configure script) <stikonas>but in live-bootstrap we tried to be more rigorous <stikonas>bauen1: hmm, but what thing are you going to run from spi flash? stage0? <nanonyme>I see. I also got some comments about lack of __thread when building initial elfutils. Is that also because of the old GCC? <bauen1>stikonas: seeing as i'll have to toggle it in by hand, probably a hex0 (iirc that what reads in hex from stdin, compiles it to binary and runs it) equivialent with a small driver for the UART <bauen1>stikonas: after that, i'm not sure, i'll probably start writing some drivers / library for SPI so I can read/write the flash from the A64 itself <bauen1>stikonas: i'm probably not going to get very far but then you'd need some more compilers a small unix kernel to start the bootstrap <stikonas>well, it's a nice project. Although I guess it will take a long time <stikonas>inputing code using dip-switches will be even worse than writing .hex0 code (so hex0, kaem-minimal and hex1) <bauen1>stikonas: yeah, i'll probably not get very far, but UART and then SPI driver is the goal <stikonas>well, input/output is the biggest problem on baremetal bootstrap <bauen1>true, and using UART is kind of cheating <stikonas>yes, but still lower level than POSIX bootstrap <stikonas>still, driving those using machine code or assembly is not easy <bauen1>if i even get to the point where i need to worry about initialising the DRAM i'd be very surprised ***ChanServ sets mode: +o janneke
<stikonas>how much of RAM do you have access to before initialising DRAM? <bauen1>stikonas: with the a64 roughly in that ball park <bauen1>i have at least 32kb, and that is afaik as big as i can go before the boot rom will break when trying to load my "bootloader" from flash <stikonas>so maybe you are limited to M0, so assembly <bauen1>but i'm pretty sure i have at least another 108kb, and then there is supposedly another 64kb but iirc that memory area is quite special <stikonas>nanonyme: oh, actually micropython is no go... <stikonas>just tried to test it and it actually needs python3 <stikonas>so I think the way to go is to build old python2 first as fossy suggested