IRC channel logs
2023-12-02.log
back to list of logs
<matrix_bridge><cosinusoidally> Andrius Štikonas: ah I now see that the later build of M2-Planet from stage0-posix uses buffered io. I was initially using the "Phase-5 Build M2-Planet from cc_x86" version of M2 which is also slow due to unbuffered io. My plan is to minimise my dependencies (and the build time). I was using M2 during dev since it gives better error messages. I then made my code compatible with cc_x86 to remove the... <matrix_bridge><Andrius Štikonas> yeah, that first build of M2 is not using full M2libc <matrix_bridge><Andrius Štikonas> generally, cc_x86 is developed only with the goal of building M2 (without full M2libc) <matrix_bridge><Andrius Štikonas> and going from cc_x86 to full M2-Planet is very quick anyway <matrix_bridge><cosinusoidally> I'm currently going from nothing to tcc 0.9.23 in about 40s (though I can't actually run that version of tcc as my cobbled together partial libc isn't yet complete enough). On the same machine I can go from nothing to a full M2-Planet in about 30s. <fossy>Mikaku: i might be a bit silly here, but how does one mount /proc under fiwix? the usual mount -t proc proc /proc isn't working for me... <GoogulatorMobile>Found an exceedingly ugly, but potentially viable workaround for the IDE freezing issue <GoogulatorMobile>If I never enable interrupts while in protected mode ("cli" before entering protected mode, and only ever "sti"-ing in real mode), there's no freeze. <GoogulatorMobile>Of course, this is an issue because syscalls are implemented using int 0x80, so we must _eventually_ enable interrupts in protected mode befor le executing any non-built-in commands <GoogulatorMobile>But if we rewrite "src" to directly call the relevant syscall handlers (possible because everything is in ring 0), and only enable interrupts once "src" completes - we can boot on Intel & NVIDIA IDE! <GoogulatorMobile>It looks as if we're not servicing some critical interrupt on these platforms, which causes IDE to hang <GoogulatorMobile>The downside is, we would probably still die if we tried to write the HDD using builder-hex0 with this hack <oriansj>cosinusoidally: neat to see your progress. <Mikaku>fossy: the command you said is the way to go, it works for me <Mikaku>fossy: what 'mount' command are you using? are you on FiwixOS 3.x? <Googulator>fossy: have you found a fix for the make PATH issue? <Googulator>I tried giving it an environment, but got nowhere. <Googulator>rickmasters: what happened to builder-hex0-x86-stage2.hex2 in the ironmeld repo? Only the hex0 version is in the repository. <rickmasters>Googulator: You can generate the stage2 hex0 like so: <rickmasters>The hex2 is the definitive source and the hex0 is derived so I stopped keeping the hex0 in source control <rickmasters>Googulator: correction: the hex0 version is still in source control. <rickmasters>Googulator: Not handling interrupts properly in protected mode makes sense as an explanation for your problem. <rickmasters>Googulator: There is history consistent with this. I had a similar problem when I didn't handle the timer interrupt in protected mode. <rickmasters>Googulator: My solution was to put in a stub handler but it bothered me that I didn't really know what was going on. <rickmasters>Googulator: Another possible approach would be to try to "relay" interrupts in protected mode to their real mode handlers. <rickmasters>Googulator: I'm not sure if that is even possible to do reliably though. <rickmasters>You'd have to enter real mode, manually push an interrupt return frame onto the stack and jump to the real mode handler. <rickmasters>When the real mode handler does the iret it would come back to the relay handler which would restore protected mode and return from interrupt again. <rickmasters>Just an idea. Disabling interrupts is obviously easier if it works. <GoogulatorMobile>Turns out, you can syscall just fine using int 80h even when interrupts are disabled <GoogulatorMobile>Maybe _software_ interrupts don't get disabled by "cli", or int 80h has special handling on these CPUs <oriansj>or switching between 16 and 32bit modes have side effects <Googulator>oriansj: I don't see how side effects could play into this <Googulator>int 80h is executed in 32-bit mode, while interrupts are disabled - and surprisingly, it still works <oriansj>Googulator: as in changing between the two modes might be causing interrupts to be turned back on <oriansj>which can be proven by just throwing a cli after switching the mode before doing the int <GoogulatorMobile>I doubt it, because this version of builder-hex0 boots on boards that lock up in srcfs read if I don't disable interrupts in protected mode <GoogulatorMobile>fossy: after the $PATH issue, there's a 2nd bug that blocks kernel bootstrap with simplify <GoogulatorMobile>As a workaround, I added a mkdir -p tmp to the kaem for building patch - now it's able to continue, currently building the first gcc