IRC channel logs

<fossy>rickmasters: i'll give it a look today & merge if it's all good :)

<nektro>is there any work being done on bootstrapping ruby? building from git master requires ruby and guix pulls from tarball

<muurkha>h0rror: your connection is bouncing

<nektro>oh i see the mention of miniruby now

<fossy>its in haskell thouhg -.-

<fossy>well one of the many minirubys is lol

<sam_>there's mruby (which is C)

<sam_>there's miniruby which is in MRI's source, no idea what that is

<fossy>ah

<nektro>doing `make miniruby` ran me into the same error as before anyways so im asking in the ruby community for build help

<fossy>ok, merging kernel bootstrap :D

<rickmasters>fossy: Thank you! Although I still have a lot of work to do it's a huge milestone.

<rickmasters>Now I won't have to maintain a separate fork on my own.

<fossy>I was looking at the HDD issue in Fiwix repo. glad to see progress on that!

<rickmasters>Besides finishing Fiwix to Linux transition I'd like to improve the performance of the initial stage of loading the source.

<rickmasters>fossy: Yes, there have been breakthroughs on that in the last couple of days.

<rickmasters>I'm not sure if I'll keep working on that or move on to Linux transition next.

<fossy>whichever interests you more at the moment, im excited for both in their time :)

<rickmasters>fossy: by the way, I'll redo the help2man PR now. I was holding off to avoid a conflict with the kernel bootstrap PR.

<fossy>sounds good

<stikonas[m]>rickmasters: maybe we should submit kernel seed to bootstrap-seeds repo that oriansj maintains?

<stikonas[m]>Now building boot image only works on x86/amd64 systems

<stikonas[m]>As we run hex0-seed in image preparation stage

<stikonas[m]>(Quick fix might be calling arch dependant hex0 binary rather than x86)

<rickmasters>stikonas: I'm fine with that. I thought "compiling" the seed seemed more bootstrappy.

<rickmasters>stikonas: I'm not sure what you mean re: arch dependant hex0 binary rather than x86

<stikonas[m]>Say I have aarch64 machine

<stikonas[m]>And I want to bootstrap my new x86 pc

<rickmasters>stikonas: ok, I see

<rickmasters>Yeah, that almost seems like a bug, if live-bootstrap is supposed to be arch independent

<stikonas[m]>Running rootfs.py to create builder hex0 image won't work due to call to x86/hex0-seed

<stikonas[m]>It's something to think about

<stikonas[m]>Not sure what's the best way of dealing with it

<stikonas[m]>rootfs.py is not really bootstrap yet, it's just helper to prepare image

<stikonas[m]>(As manually creating any image on modern media is basically impossible)

<rickmasters>stikonas: I see what you mean. It would be easy to use args.arch to parameterize that seed or compilation.

<rickmasters>stikonas: Or is that the target arch?

<stikonas[m]>args.arch is target

<stikonas[m]>I think we need native

<stikonas[m]>Which I guess is uname call

<rickmasters>Ok, well args.arch could select a binary seed so maybe that's why we should just use a binary seed?

<stikonas[m]>Well, fundamentally kernel is a bootstrap seed...

<stikonas[m]>So maybe we just use it

<stikonas[m]>oriansj: should we add it to your repo?

<rickmasters>And I'd be able to get rid of the kernel-bootstrap directory

<rickmasters>I'm hoping to reduce the seed to one sector by using builder-hex0-mini as the starting seed but it needs changes to avoid a reboot.

<stikonas[m]>Yeah, perhaps we can sort this native arch issue later when you go for mini seed

<rickmasters>stikonas: And if we're putting the binary seed in a stage0 related repo then the source probably belongs in a related repo (which I'm fine with if oriansj is)

<fossy>isnt there source hex0 in bootstrap-seeds anyways

<stikonas[m]>There is

<rickmasters>yeah, I guess its the same repo

<rickmasters>It's a little confusing, the source is in more than one place

<rickmasters> https://github.com/oriansj/stage0-posix-x86 and and https://github.com/oriansj/bootstrap-seeds

<stikonas[m]>Yes, a bit confusing though having just binaries without source in the repo is also bad

<aggi>not important, just crossed my mind, once i arrive at bootstrapping from the hex0 seed, i'll consider writing the scriping as posix shell

<aggi>just because, python got issues, when a posix shell may be easier to handle, or lua

<aggi>i'll have to debug tcc-compiler/jit-compilation of linux kernel first, because all available test-setups error-out

<aggi>AoT-compiled linux-2.4/tcc-0.9.[any] panics; and JIT-compiled linux-2.4/tccboot-0.9.22 errors during compilation phase; debugging either is difficult

<aggi>and i'll try to avoid latest tcc-versions which require a tad too many libc-symbols/headers

<aggi>tcc-0.9.27 is affected by this already; don't know which version bootstrappable aimed at, and if any which libc was supposed to be linked against

<aggi>(original) tccboot/tcc-version seems to be a relevant piece to bootstrapping in this context, because it's dependencies are minimal, to compile, load and execute a kernel (if i manage to repair it)

<avih>aggi: if you want sh help or review, ping me, i like sh.

<muurkha>the POSIX shell has a lot of problems but it's probably fine for this

<stikonas[m]>It's not python there that has issues, the same issue would be with shell

<stikonas[m]>If you try to run e.g. x86 binary on arm

<stikonas[m]>the issue I guess is that bootstrap seeds are just seeds, we shouldn't rebuild them during preparation stage

<aggi>stikonas[m]: why would anyone try to execute x86 binary on arm?

<aggi>otherwise, a clean cross-compile of python is one such issue

<stikonas[m]>Well, rickmasters script just tries to run hardcoded x86/hex0-seed

<aggi>clean, by definition, avoiding qemu-user for cross-compilation for example, and not poisoning build-host and build-target with each other

<stikonas[m]>To build builder-hex0 from source

<stikonas[m]>Anyway, it's not really a bootstrap issue, just a question of how to prepare bootstrap image

<aggi>well

<stikonas[m]>If you do it on paper tape, you would have neither bash nor python...

<stikonas[m]>And it will also take ages...

<aggi>yes

<aggi>question is, where the bootstrapping hooks into

<aggi>since bootstrappable avoids, most, hardware development related issues, the choice of tools and platform is less critical

<aggi>a z80/FuzixOS (16bit unix), gigatron ttl etc. begin elsewhere, including hardware

<aggi>z80 is known for deployment to fpga, gigatron may be, and for x86 there is ao486 (which requires undesireable tooling in comparison to z80)

<aggi>and if you look at z80, the main compiler for this is SDCC, which is written in c++

<aggi>that's why, backtracking, reaches as far as tiny basic paper tape

<aggi>or gigatron ttl, the hardware design can be accomplished with pencil and paper, and pieces soldered onto breadboard

<aggi>which is where bootstrapping begins, with pencil and paper

<aggi>most adafruit seems debatable, when it requires an eclipse ide, python, java, c++ and all this, for development

<aggi>because, their products are involved often

<aggi>the hex0 is important, to establish a chain-of-trust at the software side, yet with x86 problems remain at the hardware side

<aggi>opencores.org documents some of the hardware-related components, what's open and what isn't; FYI, usb1.x at most it seems for example

<aggi>ao486, doesn't implement a FPU, and tcc-assembler errored with the softfloat implementation in linux-2.x; just collecting issues

<aggi>if one day, bootstrappable wanted to move onto a free/open hardware

<aggi>ACTION shuts up, to avoid any confusion

<muurkha>aggi: having only 64K of address space is a pretty big pain

<muurkha>but SeRV is comparable in complexity to Gigatron

<aggi>muurkha: of cause; although some z80 can be equipped with a MMU, for "bank switching", such as 10banks 64K each... that's the 640K boundary

<muurkha>yeah, lots of Z80 machines used bank switching heavily, without even an MMU

<muurkha>but it's a huge pain in the ass

<aggi>no expert, seems this is where the segmented memory originated, switching 64K segments

<muurkha>generally they don't switch out the whole 64K address space

<muurkha>no, segmented memory originated in the desire to run multiple timeshared processes on the same computer and be able to move them around to make room for new ones without invalidating all their pointers

<muurkha>in the 01960s

<oriansj>stikonas: I am good with adding the kernel under the NATIVE folder with its respective architecture

<muurkha>a flat 32-bit address space (or even 24-bit) makes it much easier to write compilers, debug compiled programs, and write assembly

<oriansj>that way if it is ported to more architectures, then we can just create matching folders and be done.

<muurkha>IBM PCs in the 80s used bank switching a lot too with LIM EMS

<oriansj>(feel free to clear out everything in the x86 folder as they would all be replaced by the wonderful work of rickmasters)

<muurkha>:)

<avih>oriansj: any progress with the hex0 strict spec? if not, can i help with anything?

IRC channel logs

2023-04-11.log