IRC channel logs

<rickmasters>stikonas: I have hardware to try it on. Yes, it's a good idea to disconnect your main hard drive before booting the bootstrap drive.

<rickmasters>stikonas: I won't be able to run the hardware test for a few weeks though. Its in a different location...

<stikonas>well, no rush

<stikonas>and I'm retesting mescc on riscv... After discovering that last crashes were simply due to old build file (crt1.o)

<stikonas>janneke: I think mescc actually works now on riscv

<stikonas>I was able to build mes with it

<stikonas>there is something a bit wrong it it and it prints lots of debug statementssuch as read fd=22 c=)

<muurkha>nice

<stikonas>so takes a long long time to start

<stikonas>let's see if newly built mes is actually capable of running mescc

<stikonas>ok, so I think mescc is self-hosting but is really slow due to all debug output

<stikonas>in more than 1h it only compiled 5 files

<stikonas>maybe something is bad with environmental variables...

<stikonas>hmm, no but something else is miscompiled in __mes_debug.c

<stikonas>if I replace the whole thing with return -1 things seem to work

<muurkha>hmm, this 510-byte "C" compiler looks pretty impressive: https://xorvoid.com/sectorc.html

<stikonas>argh, it's initialization with -1 that goes wrong in __mes_debug.c... so that's a problem with my mescc chnages

<stikonas>muurkha: wow that is impressive

<stikonas>even if it is not capable of building M2-Planet

<stikonas>it might be possible to write port let's say cc_amd64 to something that is supported by sectorc

<stikonas>though on the other hand it is a bit less readable

<stikonas>than cc_amd64.S

<stikonas>but given that you need to read 10 times less code it might pay off

<stikonas>janneke: this is working now https://git.stikonas.eu/andrius/mes/commit/d8ea9fa46c40e722867b9a811eb5a80c2024bd87 please review and merge

<pder>rickmasters: great. I tried doing 'vboxmanage debugvm "live-bootstrap" dumpvmcore --filename live-bootstrap.elf' but have not had luck yet with extracting the memory dump

<oriansj>muurkha: A FORTH with C syntax and everything is global and no struct support or array support

<oriansj>it is a very neat hack

<oriansj>for a second there I thought they embedded an actual assembler but nope just decimal to byte

<oriansj>sector assembly with nasm syntax however would be massively impressive

<janneke>stikonas[m]: \o/ good job, will do!

<rickmasters>stikonas: really great work once again!

<rickmasters>so, what's the overall status of riscv and x86_64 in live-bootstrap? How far does it go on those architectures?

<stikonas[m]>rickmasters: with some small local changes to pull in unreleased git commits of mes, they can build mes (self bootstrapped one, as opposed to mes-m2 binary that is built by M2-Planet)

<stikonas[m]>But tcc step is only working on x86

<rickmasters>stikonas[m]: Thanks. And what is needed for tcc?

<stikonas[m]>Not sure, I guess port x86 patches...

<stikonas[m]>At least for amd64

<stikonas[m]>For risc-v we would need to backport the whole new arch to old tcc

<rickmasters>stikonas[m]: ok thanks

<stikonas[m]>rickmasters: there is some branch https://gitlab.com/janneke/tinycc/-/tree/wip-riscv?ref_type=heads

<stikonas[m]>But I haven't tried anything tcc there

<rickmasters>stikonas[m]: Your recent link was my first exposure to Forejo and the story of its origin. Interesting drama there.

<stikonas[m]>Yeah, we'll see how it resolves...

<janneke>stikonas[m]: yeah, you'll learn more about that from ekaitz

<[exa]>Forejo drama?

<rickmasters>[exa]: If you're asking which drama it was the forking of Gitea due to trademark transfer: https://gitea-open-letter.coding.social/

<[exa]>oh wow, gitea fork?

<[exa]>ok thanks for the link

<stikonas[m]>[exa]: that's half a year old or so by now

<stikonas[m]>It's more like a (mercurial style) patch queue on top of gitea rather than fork

<stikonas[m]>They keep rebasing on top of gitea

<muurkha>oriansj: that seems like a good description

<muurkha>oriansj: but to be a FORTH it would need to support function arguments

<oriansj>muurkha: have you seen: https://github.com/kvakil/0asm

<stikonas[m]>janneke: have you managed to test mescc on risc-v?

<stikonas[m]>I've only tried with my kaem script

<stikonas[m]>Not with configure and make...

<stikonas[m]>Though maybe we should upstream that kaem.script too

<plasma41>oriansj: That's pretty cool :-)

<janneke>stikonas[m]: not yet, i should get to that this weekend

<stikonas[m]>No problem...

<stikonas[m]>Just saying that I hasn't tested any of the build system stuff

<stikonas[m]>Only mes/mescc itself

<stikonas[m]>And only on risc-v, if you can please retest other arches

<janneke>stikonas[m]: well, to have mescc work, ie, produce running code, that would be amazing

<janneke>mes-m2 already worked again, right?

<stikonas[m]>janneke: both work

<stikonas[m]>You can build mes-m2 using M2-Planet and the use it to run mescc to build mes which is functional and is again capable of running mescc

<stikonas[m]>After that mes reaches fixed point in term of hash

<oriansj>plasma41: yeah, it tempts me with a M0 rewrite

<oriansj>as it certainly contains enough to write M0 and hex2 without much trouble but would run out of memory before it could do something like cc_*

<Irvise_>theruran: just bought SICP and The Scheme Programming Language just for the bootstrap compiler. I don't like amazon, but nobody else imports those books at reasonable prices and I like to have them physically...

<river>i hope you enjoy the book Irvise_ :)

<theruran>Irvise_: good news!

<Irvise_>:)

<stikonas>janneke: hmm, something is broken with mes-m2 step now...

<stikonas>not sure what causes it, yesterday it was working

<stikonas>janneke: I think you pulled in some older checkout

<stikonas>not my latest commit...

<pder>rickmasters: I noticed that bootstrap.cfg is not created correctly when you run ./rootfs.py -b -p so that may be at least part of the reason the build fails under VirtualBox. The Fiwix build is skipped and make is built under builder-hex0 which is not correct

<rickmasters>pder: ok, let me take a look. I hope so, that should be easy to fix.

<rickmasters>pder: confirmed, but I'm not sure why it explicitly creates an empty file if args.bare_metal

<rickmasters>stikonas, fossy: Any idea why this is here?: https://github.com/fosslinux/live-bootstrap/blob/master/rootfs.py#L138

<Mikaku>I've just came across this <https://xorvoid.com/sectorc.html> - "SectorC: A C Compiler in 512 bytes"

<Mikaku>don't know if you already knew it

<rickmasters>pder: I can't imagine why it does that. We can try deleting those lines from rootfs.py

<stikonas[m]>rickmasters: git blame?

<pder>I can't think of a reason for that either- maybe something before the kernel bootstrap was a thing?

<stikonas[m]>But yes, I can't see Amy reason for it either

<rickmasters>stikonas[m]: no help from git blame; part of a larger commit from fossy

<rickmasters>Mikaku: Yes, it was discussed a bit in the last day or so, muurkha posted: https://logs.guix.gnu.org/bootstrappable/2023-05-25.log

<pder>I removed those lines and the bootstrap.cfg included in sysa.img looks better. I'll try it again in VirtualBox

<rickmasters>pder: I'm glad you found that. I was on a wild goose chase. I'm also testing in VB right now.

<pder>The technique I used was filming the VirtualBox window with my phone in slow motion mode, and playing it back :)

<pder>Thats when I noticed Fiwix was never built

<rickmasters>pder: heh. Ye Old Slow Mo Playback technique. I haven't used that in years.

<rickmasters>pder: well, it gets to booting Fiwix but then hangs for me so I'll have to look into this more.

<rickmasters>pder: now that I think about it, when it hits Fiwix output moves to serial port. I'll look at that.

<stikonas>Fiwix stage is reasonably short

<stikonas>perhaps you can wait a bit and see if Linux boots

<pder>rickmasters: that is what I am seeing. Last line on the screen is kexec-fiwix: jumping to trampoline

<rickmasters>I'm running a test with serial redirected to a file.

<rickmasters>stikonas: I think linux uses serial port too?

<rickmasters>yeah, serial port console

<pder>so i shouldn't expect anything to update on the screen but perhaps if I wait until Linux boots I can see some disk activity

<rickmasters>pder: yes, if its working. Might take 30 minutes

<pder>Unfortunately, I'm not seeing enough VB CPU activity for me to think it is doing anything

<rickmasters>Mikaku: Any known issues with fiwix under VirtualBox by chance?

<Mikaku>rickmasters: no, I check it periodically and I get the same results as in QEMU

<rickmasters>Mikaku: Thanks. Good to know

<Mikaku>rickmasters: regarding my link above, sorry, I should figure you already know it :-)

<rickmasters>Mikaku: no worries, dups are posted here a lot, me included, especially if they were on HackerNews recently

<Mikaku>rickmasters: I saw this this link in a mailing list of tuhs.org

<Mikaku>anyway, talk to you later

<rickmasters>bye

<rickmasters>Mikaku: if your still around. Ever notice a difference in the bios memory map under VirtualBox?

<rickmasters>pder: I'm getting output! It looks like it's working

<Mikaku>rickmasters: if is not the same, is pretty similar to the memory map under QEMU

<rickmasters>Mikaku: Ok, thanks!

<Mikaku>rickmasters: you're welcome

<rickmasters>pder: Not sure if you're using GUI or CLI, but try configuring COM1 to redirect to a file.

<rickmasters>pder: From command line its VBoxManage modifyvm $vmname --uart1 0x3F8 4 --uartmode1 file $filename

<pder>rickmasters: thanks, I will try that. Are you getting any serial port output in your file?

<pder>Oops, I didnt read above

<rickmasters>Yeah, its chugging along up to coreutils-5.0. I'm using tail -f $filename to monitor it

<pder>Awesome, one of these days I want to try on real hardware

<rickmasters>pder: me too. I have an old VT220 that I can hook up for serial output. It will probably be gloriously slow :)

<pder>could Fiwix output to the console with a different kernel parameter depending on the mode?

<rickmasters>pder: probably. Kernel params are in sysa/kexec-fiwix/src/kexec-fiwix.c

<rickmasters>pder: But some might prefer serial. qemu with -nographic redirects serial to stdout which is good if your running ssh. Console might require graphics mode.

<rickmasters>pder: Using console might require a new live-bootstrap option

<pder>I wondered if bare metal option should default to console output

<rickmasters>pder: Maybe. It may be worth opening an Issue so the details can be sussed out.

<rickmasters>pder: so the VirtualBox build got past Linux and is building fine in sysc.

<rickmasters>pder: I will followup later on getting bootstrap.cfg fixed for bare metal.

<rickmasters>pder: I've reached the end of my work day but catch me later if you have any other issues...