IRC channel logs

<Googulator>fossy: IMO the right way to "solve" it is via posix-runner

<Googulator>adding paging support to builder-hex0 seems like a fool's errand

<Googulator>& there's not much else you can do besides paging to deal with a memory hole @ 1GiB

<Googulator>and then, you have the issue of moving to Fiwix

<Googulator>where the initrd needs to be contiguous in physical RAM

<Googulator>Mikaku: Fiwix doesn't support anything like an initramfs, right?

<Googulator>if it did, we could skip the ext2 ramdisk creation and just hand the builder-hex0 ramfs over to Fiwix and have it parse it into a proper initramfs

<fossy>well, isn't the ext2 ramdisk ~= initramfs?

<Googulator>no, it's initrd

<Googulator>it's backed by a block device backed by RAM

<Googulator>vs an initramfs, which has no block device - basically just a tmpfs that's prefilled

<fossy>ah, okay

<fossy>hmmmmmm, that would be very useful

<fossy>hmm, would not be straightforward though...

<Googulator>For a start, it would mean not having to allocate a full 1GiB+ contiguous memory block for a ramdisk initially only holding a couple hundred MiB

<Googulator>And this is a real issue for UEFI as well - we might not have a 1GiB+ contiguous block at all

<Googulator>A tmpfs or initramfs can be discontiguous, in theory

<Googulator>and it can grow or shrink dynamically

<fossy>a RAMdisk could be discontiguous in theory as well

<fossy>clearly builder-hex0 doesn't support that, but i assume Fiwix does

<stikonas>well, we do need to add paging support to posix-runner though

<stikonas>but at least it should be easier

<stikonas>than with builder-hex0

<stikonas>and it's not just about 1 GiB contiguous block

<stikonas>it's also about the fact that we request some memory in fiwix, even if it is 1 GiB contigous block, it might not be the right block that we want

<fossy>yes, if we were to link anything between builder-hex0 and fiwix we would have to coerce/patch fiwix into reserving a particular block

<stikonas>anyway, we are nowhere close to building fiwix there...

<stikonas>first of all, even x86_64 userspace bootstrap doesn't work and tcc-mes is buggy

<aggi>if the route mes->tcc,busybox-stuff is feasible, i can fiddle together tccboot+linux24/romfs

<aggi>although i didn't continue testing tccboot/jit, but i do recall i had once pulled in some recent libtcc version into tccboot, sufficient for linux-2.4.37.11 for nosmp boot with extended hardware-support

<aggi>tccboot itself however does need binutils for 16bit asm

<aggi>this might need a re-integration of binutils due to autotools involved, but oasis-linux already had some lua-scripting for this which can be used as template

<aggi>i don't know at which phase any build-time dependency needed the fiwix/linux2 abi - and binutils(detangled from autotools) must be compiled without the presence of fiwix/linux2x

<aggi>tccboot could be utilized for fiwix too; in any case a 16bit assembler is needed _before_ any such kernel abi

<aggi>if 16bit bootcode was rewritten, as86 assembler would introduce a less excessive dependency graph than binutils-as would

<Mikaku>Googulator: yes, Fiwix supports initrd as long as you pass it as part of a Multiboot spec v1 data

<Mikaku>under QEMU would be: qemu-system-i386 ... -append "root=/dev/ram0 ramdisksize=nnn initrd=initrd.img" -initrd initrd.img

<Mikaku>Googulator: ah, now I read you meant a dynamic ramdisk (like tmpfs). No this is not supported

<Mikaku>I think that putting the buffer cache on top of the current ramdisk driver could be a solution to avoid having to preallocate 1GiB of contiguous memory

<aggi>is it possible to bootstrap a binutils-as (when detangled from autotools) and/or as86 assembler for 16bit bootcode asm processing, without the presence of fiwix/linux2 ABI as build-time dependency?

<mwette>ludocode: I stumbled across here. I was reading the onramp description and wondered what you do about alignment of data and how that maps to restrictions on machine hardware loads and stores.

<stikonas>that probably only matters if you try to optimize things?

<mwette>some machines will raise exception if you try to load a 32 bit data from a 16 bit aligned address

<mwette>from the riscv-unpriv spec: "loads and stores that are not naturally aligned may either complete execution successfully or raise an exception"

<stikonas>hmm, I don't think I saw this in practice...

<stikonas>stage0-riscv64 seems to be running fine

<stikonas>and variables in .text are not aligned there

<mwette>The behavior would be specific to processor implementation, what processor are you running on?

<stikonas>jh7110

<stikonas>(visionfive2)

<mwette>Thx. I'm familiar w/ vf2 (have one but it's not working right now). I was just looking through qemu source to see if they have a switch for the behavior.

<stikonas>oh, that might be useful to know

<stikonas>for now I keep using older qemu

<stikonas>since on newer qemu stage0-posix-riscv* exibit random crashes

<stikonas>at some point I should try to bisect git revisions between versions 8.0 and 8.1...

<stikonas>still, it's probably something else

<mwette>riscv/translate.c(gen_jal) has code to gen execption on misaligned jal

<stikonas>oh, but that's not so easy to get misaligned

<stikonas>since all the instructions have the same length (32-bits)

<stikonas>so you have to do something very deliberately to misalign instructions

<mwette>right. I didn't anticipate branches would be an issue.

<stikonas>I think the most realistic thing to get misaligned are some stored variables at the end of the file

<mwette>Check target/riscv/tcg/tcg-cpu.c. There is a config that sets do_unaligned_access.

<stikonas>i.e. assembly equivalent of global variables

<stikonas>yeah, I can see it

<stikonas>also, jal can only address 16-byte chunks if I remember correctly

<stikonas>let me check

<stikonas>yes, for J type instructions immediate[0] is not encoded

<stikonas>so jumps are automatically even

IRC channel logs

2025-01-05.log