search

29jm / SnowflakeOS

"It is very special"
https://jmnl.xyz
MIT License
316 stars 18 forks source link

Update build-toolchain Script #38

Closed Kimitzuni closed 2 years ago

Kimitzuni commented 2 years ago

3 things were changed in the build-toolchain.sh file.

1 - Check to see if the tar files exist before attempting to download them, avoid unnecessary network I/O. This involves a new function, aptly named extract

2 - wget was throwing errors for me while trying to download from ftp://ftp.gnu.org, so I changed that to https://ftp.gnu.org

3 - Create the directories in 1 mkdir command, as the -p flag was already being used, it makes sense (from a logical standpoint) to create the subdirectories at the same time

29jm commented 2 years ago

I appreciate the fix and improvements to that script, thanks :+1:

Just curious, did you get a chance to run the OS, any issues there?

Kimitzuni commented 2 years ago

Just curious, did you get a chance to run the OS, any issues there?

I first downloaded the ISO from the releases, as I just wanted to have a mess around with it before dealing with building and modifying it. I tried that in both QEMU and on real hardware (ThinkPad X230: i5 w/ 12GB RAM + Legacy Boot Only).

It booted on the ThinkPad, but locked up instantly upon loading the GUI.

As for building it from source, I encountered no issues when building.

29jm commented 2 years ago

Thanks for the feedback, much appreciated.

I assume by locked up you mean even the timer didn't move and no blinking cursor in the terminal? If so that is too bad, on some of the last tests I was able to run it didn't crash but the PS/2 driver didn't work (PS/2 is an atrocity to get correct, and even worse to get working).

An actual crash sounds interesting though, I wish I had hardware to test it on - my own damned laptop is locked to secure boot.

Kimitzuni commented 2 years ago

I assume by locked up you mean even the timer didn't move and no blinking cursor in the terminal? If so that is too bad, on some of the last tests I was able to run it didn't crash but the PS/2 driver didn't work (PS/2 is an atrocity to get correct, and even worse to get working).

Yeah. I do have some other machines I can test it on, but I don't think it's going to run on a 2007 Mac Mini.

my own damned laptop is locked to secure boot.

Secure Boot: The Feature No-One Wanted

Kimitzuni commented 2 years ago

I assume by locked up you mean even the timer didn't move and no blinking cursor in the terminal? If so that is too bad, on some of the last tests I was able to run it didn't crash but the PS/2 driver didn't work (PS/2 is an atrocity to get correct, and even worse to get working).

So, I have an update. I did a build from the source. Booted it on the X230. And it didn't crash. Timer was ticking, cursor was flashing. However, I could not interact with the system. First working boot on hardware?

29jm commented 2 years ago

PXL_20220417_204814538

Well the terminal crashed when I pressed enter so there's that, but wow, am I an idiot for not figuring out the secure boot thing earlier (for reference: set a supervisor password and the option unlocks). Also no mouse input even with the cable, debugging will be done. Now I wonder if the current master would still crash for you.

29jm commented 2 years ago

So, I have an update. I did a build from the source. Booted it on the X230. And it didn't crash. Timer was ticking, cursor was flashing. However, I could not interact with the system. First working boot on hardware?

Who knows who got there first :smile: ? Interesting that you don't get keyboard and I do! I will have to dig for a working implementation of a PS/2 controller driver... This is impossible to figure out without owning a dozen computers.

29jm commented 2 years ago

If you're so inclined, you can try to modify terminal.c to show the kernel log at startup, that will show what PS/2 peripherals the kernel tried to initialize, and possibly errors. You would have to add these lines somewhere before the main loop:

 sys_info_t info;
 info.kernel_log = malloc(2048);
 syscall2(SYS_INFO, SYS_INFO_LOG, (uintptr_t) &info);
 str_append(text_buf, info.kernel_log);
 free(info.kernel_log);

Increasing theight to something like 600px might help also.

In any case, I'm really glad you jolted me to figure out this secure boot thing - I just got to play DOOM with zero emulator !

Also fwiw, in my case the kernel sees a mouse, but no data is generated from it. It's possible that it's my broken touchpad (zero input even on usual OSes) and not my external mouse that's patched through though.

Kimitzuni commented 2 years ago

After adding those lines, this is the output 20220417_212921

29jm commented 2 years ago

keyboard sent fa mouse sent fa, fa

Such a confusing response ! But super instructive. It could be that the driver doesn't wait long enough between reads from the PS/2 controller (this is currently done in a very dumb way, see ps2_wait_ms in ps2.c) and so we somehow read the ACK several times in a row. That, or your particular PS/2 controller has a strange sense of humor.

May I ping you again tomorrow or next week to try a few more things?

Kimitzuni commented 2 years ago

Feel free to add me on Discord, I'm often on Discord more than I have GitHub open

rtw#4390

29jm commented 2 years ago

Added you :+1:

If you don't mind, it'd be awesome if you could try to boot with the changes in the ps2-debugging branch (or equivalently the iso here).

It seems to me now that the waiting times I had there during reset were 1) useless and 2) actively harmful, I removed them, and increased some other timeout which was suspiciously low. Also now if a read from the PS/2 controller fails, it'll show in the kernel log. It should have been doing that already, but I got got by an off by one error. And, there is now a reboot command to save some time.