#Astral
1 messages Β· Page 4 of 1
per spec, the type of FAT is determined by the size of the volume
and supporting FAT12 and FAT16 is a few dozen more lines of code
especially in a high level language like C
^ whoops, infy already mentioned it
takes a break for a few days
"dead project lol"
Its used automatically for small filesystems
You cant force a bigger fat type because of what luk said
who would want a <2mb file system
would you want to refuse mounting a very small file system because it has too few clusters?
just for the sake of saving 8 lines of code
i mean fair enough
but it's not just β8 lines of codeβ
you gotta write different next-cluster-number accessing logic
which is like a handful of lines
well, except when it goes over sector boundaries
but that is also not more than a dozen lines
like
if (IsFat32()) {
ReadSector(buff, sector + currCluster / 128);
return uint32Ptr(buff) + currCluster % 128;
} else if (IsFat16()) {
ReadSector(buff, sector + currCluster / 256);
return uint16Ptr(buff) + currCluster % 256;
} else { // Fat12
// huh
}
lol
thats fucked up
but yeah just a couple more lines
oh its not that hard
the other diff is how to identify the root directory
nah
on fat32 it's linked to a cluster specified in the BPB
it's the same as FAT16
so if you already do FAT16, you already have FAT12 root directory support
oh well, I guess if you want to write a function that returns a pointer to a FAT entry in a buffer, then it's not easy for FAT12
I have readFATEntry and setFATEntry functions, basically
It's really not
Tbh root dir being at a fixed place and fixed size is annoying
well, I'm assuming already having implemented FAT16
anyone with a floppy drive
anyone working on ultra embedded systems
probably more that I'm not thinking of atm
x forwarding does work when sshing into the host
should've run something like firefox :^)
believe me, I tried it. it wouldn't run and I don't feel like debugging X forwarding too much 
ah lol
think it was complaining that it was insecure or something
probs cuz I was doing ssh -Y
i would try direct X forwarding rather than the SSH tunnel thing
I have no idea how to do that, Id need to look into it
export DISPLAY=whatever:0
well my ext2 driver is a bit borked and I've managed to half consistently reproduce it by untarring and editing a file in that tarball
its nothing too apparent at first glance but it ends up having e2fsck scream at me
and later down the line will cause an assert fail
hm it could be some vnode refcounting memes
ext2 is always fun
yup, it is a refcount meme
link count = 0 with one last reference to it somewhere
which explains the behaviour its getting, which is leaving more things allocated than expected by e2fsck
hm it doesn't seem like a bug with ext2 in specific, also reproducible on tmpfs
well at least I actually know the issue now
.
I Am Not Releasing The File
finally
doesn't happen with vim anymore
./configure also caused this and iirc git clone too
so gonna check that as well
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa it didn't fix ./configure
one less bug though
gonna see if git clone still does it
Havent ported it cuz too lazy to deal with llvm
Working git is pretty nice
The real question is does it boot on real hw
Last time I checked it got to a bash prompt but the kb didnt work
That was like last year tho lol
that doesn't matter, it must only be able to run rainbow triangle
Probably can, quake is perfectly playable so if mesa is ported I dont see why not
Needs DRM now
(for my triangle program specifically)
but does he have opengl?
Yes
Tyrquake does software rendering on its own thing Im pretty sure
I dont have opengl
I will accept a mesa and llvmpipe pr tho 
Or I can do that when I get home
Wait u don't have mesa ported?
I dont
The biggest thing is the llvm part of it but meh I can do that as a break from trying to catch that extra vnode refcount
Smth is causing the conftest vnodes to have an extra reference when running ./configure
Which kinda breaks ext2 a bit
If the system is turned off
u can shutdown the system?
you can use soft pipe
that's a software renderer with no LLVM involved
isnt that super slow
wasnt the speedup mostly achieved by using SSE and stuff
As in, syncing and pressing the power button lmao
Oh
If Im gonna do it Im just gonna do llvmpipe so I dint have to deal with it again
so theoretically, if i just mount the iso provided on github, copy out the kernel & initrd to my boot partition, then make a limine entry, it could work?
so it loads the kernel, but, it seems stuck on smp? it just prints smp: 12 processors then seems to freeze. is there a kernel option to disable smp?
weird
Pass nosmp to the cmdline
Think thats the option
My ipi might not work on real hw or smth
And Ive probably fixed some bugs from the version in the release page its like over a month old I think
Doesnt even have a page cache lol
oh yea lol, i should specifically mention i'm using the release, not built from source
Still should hopefully boot with nosmp passed to it
Otherwise thats another thing Ill have to debug if its not fized in source
Its a bug in astral ps2 init code
And not surprising as its not trivial to get right
oh yeah, fair enough
That trademark is reserved
well, do i need a mouse?
For the normal console usage nah
The touchpad would work if this ps2 init code worked
yeah, so if i build from source, could i just comment out that assert? 
Well yes but its not as simple lol
You could get it to boot but your keyboard and touchpad wouldn't work
The keyboard seemed to init so it might just be a mouse issue somehow
maybe log all incoming bytes?
I'm gonna try booting it up on my laptop later to see if that bug happens on it
since apparently it did do most of the init stuff just fine, it just seems like its complaining when I tell it to start actually reporting stuff
my laptop is a thinkpad, and i'm pretty sure it's got some funky trackpad & nipple-mouse driver moments
I guess I could just make it print and error message and not continue, its not really fatal
Yeah its a multiplexed ps2 controller
But its backwards compatible
Not quirky in any way
Idrk if this could be it but maybe its already enabled or something, I forgot if its disabled at the device reset
@warped plinth I'll send you an iso without the assert and you try it out
lol oke
i cloned the repo and hit make, but the jinx cache seems to be taking a while to download πΏ
yes but it should work always
speed wasn't really a concern in the design of jinx, more so reproducibility and ensuring one is able to build an OS distro start to finish regardless of host system state
sent in dms
while I'm at it might as well try it myself, no reason not to
awesome, thanks so much!
uh
but it should work always
but it should work always
but it should work always
but it should work always
wtf happened π
jinx moment?
but it should work always
think I'm not zeroing some memory in the pmm when I should
trying to boot on my main desktop failed with that
but it does seem like it doesn't hang at the ps2 init anymore
died at processing the initrd
and also it triple faults when trying to run with smp, cool
I really need to take a week or two in the future to try to make smp better
what
idk it was just spamming that in a terminal when i was building astral
not sure what you're on about sorry
oh maybe it's an astral thing?
oh yeah, the initrd is too big for my EFI partition (which is fairly large, 512MiB)
GUH THE INITRD IS 1.4GB????
aight it's partitioning time πͺ π
Yup. This guy's awesome π
gwah
its something with me freeing the initird memory
oh I know why smp just instantly dies lol lmao
I forgor to zero memory
but the pmm bug is not related so
you know, maybe I should have tested on real hardware more often
like I did with old astral
that worked just fine and xorg ran on my laptop
God help me
at least smp doesnt die there now 
well some lines commented out make it not happen so I have to look deeper
Kb aint working but it got to a bash prompt
Gonna take a shower and see whats up later
I'm starting to think that it might be something to do with the fact that first first pages of the 4gb+ section are in the initrd
and my multiple page allocation (used by the flanterm initialisation) doesn't like that too much
which I think might explain those weird patterns on the screen?
actually hm
also, even with the new kernel it's the same error?
think its just straight up broken in real hw
I fixed a few bugs already but I have to fix another
ah alright, i thought maybe i didn't install it correctly?
i'll build from source and try disable the mouse πΏ
once I have it known working on my desktop and laptop I'll send you a new iso
When I get home I should test Astral on my Chromebook
I dont have any specific tools written to stress test it but every so often I do try to run multiple more demanding stuff at the same time
Which has helped me find some bugs
Think stuff like running configure twice while building astral and playing quake
Uhhh
Maybe put a limiter on that lmao
for i in {0..10000}; do doomgeneric &; done or something
That may or may not be valid syntax
It's 3am
almost, heheh
well that memory bug is reproducible with uefi on qemu
so thats a bug that only happens when running astral on uefi systems lol lmao
are you maybe getting confused by extra mmap entries?
I'm almost certain its likely a bug with my multiple page allocation thing I just need to see whats actually causing it
either way having it happen inside qemu makes my life much much much muuuuuuuuch easier
I can test on a real BIOS system if you want
I have a core 2 duo e8400 in an optiplex 755
well that was fucking stupid
I was forgetting to account for the module entries in a specific thing
and in the bios memory layout it didnt matter
but in the uefi layout it did
Get real
So yes indeed
Time to test on my laptop which actually can have the touchpad be exposed as a ps/2 mouse
My laptop runs into the same issue funnily enough, hm
Old astral ps2 mouse code did work on my laptop so I can have that as a base kinda
ohhh this might be it
in old astral I read it with a timeout but in new astral I do the 5 times retry one
ahh
so probably the issue is that the device is just not ready yet
which does make sense why it works in a vm but not real hw
actuallywait no
oh
he discovered something so deeply concerning that he had to vanish
I wouldnt even know where to begin
well you already have PCIe, because you have NVMe support
you start by giving up
so just look for the ID of the GPU
and you initialize it
and start passing commands to it to draw stuff
it's the last 2 that are the hard part
yeah, ez, right??
mhmm, totally super easy
but nah in all seriousness if you were to actually do that I do actually have a GT 210 I could send you, but I imagine you probably wouldn't
i do not think hardware to test with is the issue
its decently stable on real hw without smp
with smp it boots to fvwm but then gets funky and locks up
and runs better than on kvm I think
either way it runs on the two computers I have to thats a win
even tho my laptop is better supported cuz ps2 mouse
just get a motherboard with ps2 ports
like seriously, godsent
either that or wait for me and @robust geyser to finish our portable USB driver :^)
my mobo has those tho I only have one usb to ps2 adapter
My primary desktop also has PS2 ports
Asus prime h610m-e d4
LGA1700
i3-12100f
But I have a real deal PS2 mouse, as well as USB adapters for mouse and kbd
I do have a ps/2 keyboard somewhere so if I wanted to try I could try to find it and use the adapter for the mouse
.
/
a
.
o
u
t
grrr I need to fix these last few bugs but the motivation is severely lacking
may the death of nyaux be your motivation
What helps me with that is to take a day to just chill out, then promise to come back stronger tomorrow and tackle at least one large problem, then actually follow through with it
Idk if it'll help you, but it does with me
@grand shadow what references did you use for your NVMe driver?
the nvme spec is very good
yeah, mostly the spec
i saw a lot of macros reading astral's impl, why is that?
also which parts of the spec were used? the base spec?
yeah the base spec
I mean is there any issues with that?
idk I just felt like it was more readable than having a bunch of shifts and masks everywhere
mrow
well that was fucking stupid
I ended up straight up forgetting to handle the edge case of dirty file pages being truncated, which left an extra reference every time it happened
actually mad at myself for this bruh
quake multiplayer needs getifaddrs, this is so sad
how much work do you think that'd take?
Its some non posix api I rewlly dont feel lioe working on
I will fix those few other issues and then finally work on a fat driver
@grand shadow found an issue I think
the edgetrigger and deassert are supposed to be flipped
so you or the value with 1<<15 if edgetrigger is FALSE and not true
same with deassert
the OSdev wiki article on PCI doesnt have this issue
any chance you're in need of Astral testing on random real hardware?
idk, I have some spare time where I can't do much atm, so I figured I would pop in and see if that would be useful
if you want to go ahead, theres an iso I left at http://avalios.dev/astral.iso
I forgor if that one is from before or after the ps/2 fix commit
alright
well this isn't a great start
Dell Precision T1650, booting from initrd
hangs at ps2kbd: irq enabled with vector 35
my USB keyboard (presumably in PS2 emulation mode from the BIOS) doesn't seem to do anything
Hmm, seems like it panicked on my OptiPlex 755
[1;31mmm/vmm.c:vmm_init:694: vmm_map(MAKE_HHDM(e->base), e->length, VMM_FLAGS_EXACT, mmuflags, NULL) failed
[0mcpu0: Oops.
[hang]```
And a pic Incase a messed up typing it out
ThinkPad T480, initrd (and limine sure took it's time to load it, so ik it did load it)
ThinkPad T14 Gen 1 AMD, initrd
maybe theres overlapping memory map entries, I don't actually check for the type of mapping when mmaping it (I probably should though)
now this one is weird wtf
Oh I think I have a weirder one lmao
32 bit hpet not supported
Dell Latitude 5491
Limine had that garbage on the screen (with only the bottom of it visible up at the top there), carried over into astral, and it hung there
wtf
HP ProBook 4540s
Uhhh... Yeah
uh, that doesn't sound right
your assessment that is, doesn't sound right
in that what you see at the top there is not Limine output
at any point
yes
Limine looked like that
Had that random garbage at the bottom, and the bottom half of the limine boot menu at the top
The same state persisted into astral, where it hung (that pic)
can you show a picture of that
likewise with this, is this before or after booting astral?
Mhmm, and that was before
After booting on the probook it showed a garbled version of an astral error message
Undecipherable
Both are UEFI, but I would need to double check what mode they're booting in, as theyve both had CSM on or off in various times
Heres limine in the glitched state, in CSM mode, on the Latitude
Let me try again with UEFI boot and see if it's the same, one sec
Yeah, same idea at the same time lol
Nah looks fine on UEFI
Weird
Astral hangs at the same spot, ending with PCI logs, though
likewise, what about BIOS?
Working on it
kk
Weird
Works fine on BIOS
i wouldn't say it's weird
both of these issues seem related to the way the framebuffer information has been passed to the bootloader
switching BIOS and UEFI changes that radically
In each case I can vouch that GRUB works on this machine
I used both of these machines with Linux at various times, with both BIOS and UEFI mode
The ProBook, Latitude (the 2 we were just talking about), and T480 support both, and have been used with both, at native laptop panel resolution (varies between machine)
The T14 has only been used in UEFI
The OptiPlex 755 and Precision T1650 have both only been used in BIOS
to be clear
i meant what resolution was GRUB using
because Linux has its own video drivers
so the issue wouldn't apply
Yes, that's what I was referring to as well, GRUB runs at full resolution
I could go double check if necessary on each if you want, I have a bootable GRUB USB
that would be nice, if it's not too much effort
alongside having GRUB print the video mode info
No prob
That's kind of what I'm here doing lol, testing things since I have some spare time
ty lol
it is actually quite unfortunate and weird to see 2 of your machines both fail with Limine, and in similar video mode related ways
i can't say i've ever seen anyone report anything similar before
especially the shifted up framebuffer one
Also, Astral has the same bug as on the T480, here in the ProBook in BIOS
Might want to double check this image in QEMU quick, since its weird that this image would have the same weird issue on 2 machines
there could be actually a chance of your drive being faulty or the image being corrupted :^)
Possible, that's why I'm checking in QEMU directly with the image Mathew linked
While I wait for it to boot I'll check those laptops with GRUB
i'd say that i think the broken drive hypothesis is more likely than the image being faulty; that said having you try a known-working image on a different usb stick would be the proof that neither are the case
- ProBook - BIOS: GRUB defaults to 1024x768 (and displays correctly like that), but if told to use 1366x768 (native panel res), works fine
- ProBook - UEFI: Same as above
- Latitude - BIOS: GRUB defaults to 1024x768 (and displays correctly), but if told to use 1920x1080 (native panel res), works fine
- Latitude - UEFI: same as above
also astral booted fine in QEMU so ig it's just either a Ventoy issue (would be weird, since limine seems to successfully load the initrd, typically when I see ventoy issues, whatever I'm booting just fails to find the drive at all) or a bad USB stick issue
let me try another stick, flashed directly, on the 2 machines that made it far enough to care
whenever you can, try this on a fresh usb stick, as well
lmfao, the probook wants nothing to do with booting the USB directly, at least in BIOS mode
in UEFI it's the same garbled mess, but in BIOS it just kicks me to PXE boot
welp
some machines may not like this kind of hybrid ISO on a USB stick in BIOS mode
that's not that interesting of a find
setting the protective MBR GPT partition as bootable may get them to boot, but then they won't boot in UEFI mode on other machines so whack-a-mole
so in UEFI you still get the wrong pitch-looking one?
yup
alright
i really hope this isn't a situation where GRUB just has a list of quirks for these specific machines
And on the T480 with UEFI, Limine works great, then Astral gets to here and it just hangs here it seems
just to be clear, this is with the ISO i sent or the astral one?
keyboard LEDs don't seem to respond
that's astral, I'm about to test your ISO rn, just didn't want to reflash twice
alright, hopefully the ISO i sent boots in both modes
template works great with T480 UEFI, doesn't boot on T480 BIOS
testing on ProBook now
works great on ProBook BIOS, boots but garbled on ProBook UEFI
works great on Latitude UEFI & BIOS
was the T480 even having an issue to begin with?
wait, the latitude being the one with the shifted-up framebuffer issue?
nope but I just already had it hooked up so I figured I would check
yup, Latitude had the bugged graphics in BIOS with Ventoy -> Astral ISO, but not UEFI
unfortunately the Astral ISO doesn't boot flashed directly with BIOS, I could try setting the partition as bootable like you said and see if I could get it to boot to try to reproduce it though
but the iso i sent does work booted directly in BIOS mode?
because you said it works great BIOS and UEFI
the wrong pitch could have to do with some shenenigans pulled off by Ventoy
would be interesting to load this iso with Ventoy to see if it can reproduce
but only the ProBook in UEFI mode had the wrong pitch bug if I'm not mistaken
it's the only one that's 100% garbled
well actually yeah I could try that, idk what i was thinking of there π€¦
yeah, ProBook UEFI -> Ventoy -> template still has the busted pitch
ah sorry nvm
this is the shifted up fb
not the wrong pitch
the wrong pitch one is the completely garbled one
yup
ProBook UEFI -> Ventoy -> template has the bad pitch, as did everything else I tried with it booting Limine in UEFI
what about the Latitude one though?
Latitude BIOS (the one with the shifted up screen) -> Ventoy -> template is fine
the same setup booting astral is not
that's odd
i wonder if the Astral Limine config file forces a resolution or something
doesn't seem like it
techflash in ~ at Michael-ArchT14 β cat /mnt/iso/limine.cfg
TERM_MARGIN=40
TERM_MARGIN_GRADIENT=40
TERM_WALLPAPER=boot:///liminebg.bmp
TERM_WALLPAPER_STYLE=stretched
TIMEOUT=5
[many lines of boot entries]
let me try to reproduce this config
the file hashes don't match up, so presumably they're different versions of limine
it's gonna take a hot minute to upload on my DSL, give it ~1m, it's like 24MB
no worries
ok try this
k, one sec
bugged when loaded via ventoy
let me try directly
not bugged when loaded directly
ok so the template that i sent earlier, when loaded via ventoy, is fine, but this template isn't?
I believe so
let me double check
indeed
Latitude BIOS -> Ventoy -> old template.iso is fine
Latitude BIOS -> Ventoy -> new template.iso has the same pushed up on the screen issue
works fine via ventoy
yeah i think i may have some idea of what's going on here
hm?
it's probably a memory corruption related to when Limine draws the shading around the terminal box
with this specific shading width
which happens to be the same as the margin width
now the issue is: how to reproduce without needing Ventoy's "layout randomisation" lol
also it's interesting that it only happens on that one laptop
I can't reproduce that issue on anything else
@fleet osprey could you try this one?
it's likely some very specific corruption, idk
sure, one sec
same issue, but now there's a cyan box around the bottom, left, and right of "real" screen
yeah
alright
@fleet osprey
that works
unless I copied it wrong?
I messed up the first time but recopied it and it worked I think
how long was it there for?
a lot
i pushed a fix
you see, this wouldn't have happened if Limine was written in Rust :^)
lmao
since this commit, july 9th, 2021
and it was @flat copper :^)
well anyways that fixes one of the 2 issues
maybe both :^)
try it
having a corrupted framebuffer pointer and a corrupted framebuffer pitch doesn't sound too far off
Argh
If only you would have asked like 2 minutes ago lmao
I'm afk now, and will be for a bit
20 - 60m
ah no worries then
But I don't think its a corrupted fb pointer
I could see it updating through the garbage, just, not really able to make out what exactly it's doing
And it did mildly resemble the correct background
actually it's this https://github.com/limine-bootloader/limine/commit/8a8b4374379b1bd8fc6fdb0e9df5023d97132205 commit, but whatever
the scrolled up one was the corrupted fb pointer
the other one with the slanted pixels is the corrupted pitch
Oh really? Ok then, I would've thought if the fb pointer corrupted it would just be dumping image data somewhere in RAM, or elsewhere (and probably crash)
i mean it would, and it likely did, it's whatever was before the actual framebuffer window
it's just that the pointer got corrupted a bit, only a low byte or something, that caused it to slide back a bit
but still have parts of it visible
sure
i have a uhhhh
my guess would be 80% chance that it is fixed
the issue is just too similar and too coincidental, and caused by Astral's Limine config settings (well, not caused, but it shows because of that)
italians at it again
fucking italians amirite
About to go check on the ProBook, give me like, 3m
okie
nah it's still busted on the ProBook on the latest template
same thing where you can almost make out certain shapes if you stare at it diagonally
A vid of me pressing keys, you can see the selection distorted to hell on the right
I love carpet floors
as do i
well that's a shame, i guess the 20% was right
yes that's what an incorrect pitch value usually looks like
@fleet osprey try this
same
@fleet osprey sorry to waste your time btw
@fleet osprey
same thing once again
yikes
yeah i think that laptop's video mode is just broken
unless, hey @analog berry do you have any idea? i remember you yapping something about VBE not too long ago
@fleet osprey this fails both when loaded with Ventoy and not, right?
iirc it does, yes
I can check again, hang on
thanks
indeed it does
yeah it would be weird if it did not
it's just weird that I don't have that problem with anything else that I've tested on it
what's the resolution of this laptop? can you try editing the config to change the resolution to something else?
1366x768
alr
k
working on it
forcing 1024x768 (what GRUB defaults to) works
but forcing 1366x768 break, unlike on GRUB
interesting
could you print the mode info with grub
for 1366x768, or generally the mode listing it prints
google how to do it because i do not remember
have you been hacking the wrong code this entire time?
lmao, sorry
yes
i did sort out some issues there though
i needed to do it anyways so i guess there's that
that explains why there were no changes with different tests lol
yeah
so the pitch according to grub appears to be exactly 1366*4
let's see what Limine thinks the pitch is, i guess
there may be an issue with calculating the colour depth in Limine
i see no other place where it could fail
could try forcing it to always think 4 no matter what anything else says to see if that's it I suppose
well yeah but then if that ends up not being the issue at all, you don't need to go debug that code
idk, that's typically how I try to solve issues
oh no, i mean, i understand that and i completely agree, but when i am confident something isn't needed, especially when sending images to other people is necessary, i try to avoid it
oh damn
I flashed that image, set the res to 1366x768 in the new config file, booted, and it's still the same
try this, i force the pitch to 5464 manually
still busted... somehow
odd
looks exactly the same?
maybe the pitch is reported the same as what GRUB says
and the issue is that it's not true
which would tie in with this UEFI being fucked and GRUB probably having some quirk
yeah, same thing
and it really wouldn't shock me to learn that HP of all manufactureres wrote terrible firmware for a crappy consumer grade laptop
it's just odd that neither GRUB, nor Windows, or anything else that I've found has this same issue
well but on my end i can say that it is likewise odd that no other machine exhibits this symptom :^)
i'll keep looking at the code and trying to find debug paths/solutions and let you know
@fleet osprey
same issue unfortunately
@fleet osprey
nope
are you absolutely positive it's booting using UEFI lol
I don't see any reason it shouldn't be
if I boot ventoy it says UEFI, and in the BIOS setup it says the boot mode is UEFI Native with no CSM
I can also select UEFI "Hybrid" w/ CSM, or Legacy mode
now it's just a black screen
that's fine lol, no worries
take as much time as you need, I'll still be here
Any tldr?
the issue wasn't VBE in the first place, it's actually GOP
Btw if you have so many computers would be nice to get acpi dumps from them if you get around to it
And maybe try managarm on them as well
the issue is that Limine framebuffer is bugged, having the wrong pitch, only on 1366x768 mode, which is listed as ^^^^
nothing else other than Limine seems to have that issue here, nor does it happen on any other computer, nor does it happen on this one when using BIOS
exmple of it ^^^
and sure, I can do both of those
Nice
Well that sounds like some sort of limine bug to me
awesome, it doesn't have an EFI console
Mint did you look at the values you're getting from it?
Just dump the video mode struct
And try overwriting pitch to native screen size * 4
i did that already
Didn't help?
also i cannot dump that struct as there is no EFI console and obviously no video mode working
no, same thing
Damn
try Hyper lol
Well colors do look correct right
yeah
So its definitely pitch
I mean sure but it doesn't draw anything
well i mean
It uses the tty
it does load kernels that do though, no?
Yup
Does astral boot fine with if u manage to get through the menu?
Or what happens
yea, it boots astral, as well as mint's template kernel
they're just unusably garbled on screen
Oh so their fb is also fucked
i mean it uses the same fb so yeah
sounds good
It draws a bunch of stuff
sure
only requirement to make it break is it needs to either not specify a resolution, or force 1366x768
any other res works fine
Although if this is old hw we might run into the broken GetMemoryMap issue
it's a HP ProBook 4540s, so yeah it's pretty old
it's 3rd gen intel
you know what's funny? that qemu used to support 1366x768 and whenever you'd modeset that it'd have the exact same issue
and not just with Limine
Linux and FreeBSD too
it could be a massive coincidence
or something to do with the numbers "1366" and "768"
fuck if i know
good morning
sure, one sec
it's fine, i fixed the issue i pinged you for
good morning :^)
just a black screen
let me check
it probably does, Limine is fine on BIOS as well
yea, let me get a pic of it
its this issue on uefi
one day ill get around to making a workaround
didn't mean for it to rotate, oops
how does xstart>xend even happen
tbh it's not a you bug
it's more of a
"you're holding it wrong" sort of bug
wrt that function you wrote
in any case this fixes it so no harm no foul lol
nice yeah that looked like bios did work, but uefi is untestable until i make a firmware bug workaround
couldn't you for now, for testing, print something to screen
inside the bootloader
after modesetting
like try printing a square or something
it doesnt have any facilities for that
give me code to draw something 
memset the screen lol
but that wouldnt help
memsetting won't help as you wouldn't see the issue
just draw a square, it's not that hard
ask saga for code
i am sure he has it
ill paste it in if saga has it
I'm in bed lmao
lol
osdevs fight over who writes code for drawing a square
i woke up like 10 mins ago
I would just go write one myself but I've never been able to get a functional UEFI dev environment (and I've tried 3 separate times), lol
just use Limine :^)
bro seriously drawing a square ain't that hard
hell
you don't even need to draw a square
just draw a vertical line @analog berry
and don't tell me you don't know how
it's just x_pos + pitch * i
in a for loop
would you look at that
that is exactly 100% the same output, I'm nearly certain
I'm seeing the same patterns of pixels
all i did was try 1366x768 on ovmf qemu
that one still supports 1366x768
well i guess having this reproducer is nice
nvm i'm stupid, no shit the problem only exists with ovmf lol
uhhhh
that pitch looks fine
the Limine template looks fine when it boots
it means it's some sort of drawing issue?
oh no wait
that changes the res
yeah okay
@fleet osprey does this look the same for you?
on the ProBook the actual kernel looks fine with this ^^^ template
idk when that changed, because it didn't initially, and didn't test that on the other ones, I just assumed it wouldn't work, since Limine's interface was busted
hmm
For reference, what I see, and I think is correct?
It's coherent, which is more than I can say about Limine's UI on there lol
if i subtract 24 to the pitch it works
which would mean the actual pitch is 5441
@fleet osprey try this, get past the menu
k
limine looks... differently fucked than it did before
also whatever it's trying to output after loading is also garbled
also, I need to head out for the night
it's 2:38AM over here
if you have anything left for me to test, send it in the next 5-10m pls, otherwise I'll get to it when I wake up in ~8h
yeah i have no idea
just a question
do any of your other laptops have a 1366 screen?
if so, does Limine work there?
Uhhh
Only other one is the one I donated to my mom
I could steal it for 5m to test, just lmk what image to use
also @flat copper do you happen to have any idea?
ok one sec
let me look at the convo in general
the only thing i can think of is that 1366 isn't a multiple of 4
but most gpus require alignment
use this
what's funny is that qemu is also borked
on 1366
and not just with Limine
what the fuck
#1061407633745125397 message
My real hardware is different tho, so it's super odd
thing is that i am also pretty sure Limine works on 1366 hardware
at least some of it
on qemu if i subtract 24 from 5464 it works fine
but on their hardware it does not
their pitch skew is different than qemu
Works fine on this
Alr
Let me know overnight if there's anything else you need, I'll check tmrw morning
sure thanks for the help
i don't think it's a Limine bug personally
i don't see where the bug could be
how would one even check for that
yeah but wouldn't everything else be distorted then? no way all other software that exists has a hack specifically for this exact laptop
try drawing a white vertical line at x=1365
ok so i think in qemu the screen is 1360
and actually reported wrong
hence why the minus 24 makes it work
and also why it breaks Linux and FreeBSD too
but their laptop, i have no idea
maybe checking the EDID, but idfk
why would the default UEFI mode be broken
that, i do not know
Just spent 30m trying to netboot that laptop, just to realize I already had Linux on it π
But yes, according to Xorg, it is in fact 1366x768, so I don't think UEFI is lying about it
i'm sorry to hear you were still awake
_ _
annoying
well i wanted to send a message, but i have nothing to say
then dont send a message!
but i wanted to send a message
then say something in that message!
lmao

aghhh I need the willpower to work on this
I have an old 2000s x86-64 computer laying around
its new enough to be 64 bit but old enough that it doesn't boot with uefi iirc
I should try to see if astral boots on that
some time
i have a stack of 3 x86_64 laptops from around 2008 if you want me to test it on them
I mean I don't expect it to work that much on real hw rn and I'd much rather test it somewhere I can easily debug
ty tho
same but i think i might try it regardless of whether math wants or not
I mean go ahead just don't expect it to work :p

i mean on one of them managarm boots up fine into weston (off of ahci even)
I'm gonna update the iso on avalios.dev to be the under the newest commit
one has a slightly messed up madt and managarm doesn't like that (two ISOs for the same irq)
and one i haven't tested because i only got it working recently (had a bad ram stick)
how messed up is it
iirc there's 2 madt ISOs for pic irq 9
one with actual flags, and the second one that just says default flags
also it MCEs while booting linux but that's neither here nor there 
I suppose in those cases if you even want to support machines like that you just have to use the one with actual flags?
i guess? some time ago i checked what linux does in that case but i forgor
iirc it just doesn't care about the second entry?
if it works it works
i think the code might not have any checks for it and it reinserts the irq into the array but default flags just mean it doesn't overwrite whatever they already were so it works out
well I copied the updated iso into https://avalios.dev/astral.iso if y'all want to try it
@wild marsh @neon crane
thinking of it, it could be a pretty interesting way to test my shit on real hw
it has 2 dvd drives one connected to ide and one on sata, a floppy disk if I even feel like it and iirc several old internal hdds
just don't know if it even works, last time I powered it on was 2021 IIRC
if i was really motivated i could grab an athlon 64 x2 computer from the attic to test :^)
I think thats the cpu in that computer
I have a spare ps2 keyboard and a spare screen, I could just leave it neatly set up in a corner and test it
yeah I think this weekend I'm gonna clean the dust off it and see if its working at all
i'm starting to suspect something is wrong with the image
none of the 3 laptops even got into limine
all stuck on a blank screen with just the text mode cursor
also does not boot as a hard drive image in qemu...
@grand shadow
wtf
qemu-system-x86_64 -cdrom astral.iso -enable-kvm -m 2G vs qemu-system-x86_64 -hda astral.iso -enable-kvm -m 2G
did you run limine bios-install astral.iso?
I just uploaded the iso my makefile makes
hmm
hmm i wonder if i have any dvd i could burn the image to :^)
I don't see why it wouldn't work tho
maybe it worked for me cuz I was using rufus or something?
possible
also now that i think about it, i think only one of the laptops actually has enough ram to load the initrd
nice
i ran limine bios-install on the image and it now attempts to boot with -hda
but complains about a size mismatch
even though i did use the same version (?)
for what
to put the ISO on a USB?
if UEFI you can just dd it
if BIOS and you're lucky you can also just dd it, but it's not garuanteed to work
the instructions from limine barebones should work
I used Ventoy to boot the ISO from a filesystem (and works on everything), but it might have been what caused the issues with init failing to load on the machines where it got that far
to make an image that should also boot on bios
it works fine on BIOS on a couple of machines when dd'd iirc
it's just because you're not supposed to do that with an ISO specifically, if I remember the issue correctly
yeah but the instructions are specifically to make a hybrid image
that both works as an iso and a hdd image
think I do use something derivated from that
@grand shadow hey, it seems like https://github.com/Mathewnd/Astral/blob/rewrite/kernel-src/io/block/nvme.c#L720 software progress isnt supported on QEMU
do you even use it for anything?
Spec said to do something with it iirc
Pre-boot Software Load Count (PBSLC): Indicates the load count of pre-boot software. After
successfully loading and initializing the controller, pre-boot software should set this field to one
more than the previous value of the Pre-boot Software Load Count. If the previous value is 255,
then the value should not be updated by pre-boot software (i.e., the value does not wrap to 0). OS
driver software should set this field to 0h after the OS has successfully been initialized.
I see
Yeah that happens cuz I try to map everything into the hddm including overlapping stuff
note: this is running on an Intel Pentium D, a CPU from like 2005 or 6
I should fix that and send you a new iso when Im home
why do you need to map stuff into the HHDM anyway?
are you rebuilding all the page tables?
Yeah
makes sense
Lol astral has been tested on more hw than mathew would want i feel like 
just because its so cool
32 bit hpet makes sense
Thats also on my todo list which I have been procrastinating with ftl lately
The 32 bit hpet and overlapping ranges thing also happened on some of techflash's computers so thats fix some of those as well
Wonder if theyd happen on that desktop of mine sitting around
what's the HPET used for here
in my instance, only for calibrating the APIC timer
or well, that was what nanoshell64 used it for, I don't support the hpet in boron (it's commented out)
I use it for calibraring too but I also use it for keeping the time with some precision without needing to service an interrupt but that can be delegated to another timer easily
TSC :^)
iirc they're of about the same ages too
HPET issues was on my ThinkPad T14 Gen 1 AMD
VMM issues was on my Dell Optiplex 755 (Core 2 Duo E8400, circa 2007)
similar issues as me huh
well, you didn't spark a multi hour long debug session the ended in the fixing of multiple video bugs on Limine, and the conclusion that the HP ProBook 4540s in UEFI specifically, has busted video modes
so you're having better luck than me so far
yeah but it also needs to be built by the same toolchain
for obvious reasons
okay fair i didn't actually think about that
alright, I fixed the overlapping entries thing
now I need to see what I'm gonna do about supporting a 32 bit hpet or doing smth else entirely
I'll do that tomorrow actually, I'm not going to uni so I'll be able to come home earlier from work
I should also try to build gcc again now that the funny ext2 stuff has been fixed
woo!
As for the 32 bit hpet support, making it so it increases once every nanosecond and getting an interrupt once it overflows (so around once every 4.3 seconds) doesnt sound too bad to be honest
Does the HPET do interrupts?
Yeah
Nice
so qemu doesn't support FSB irqs
for the hpet
I want to support both legacy replacement and fsb as the 32 bit fallbacks
so I have to hope vmware or vbox support these
vmware supports fsb
Hyprland
I rewrote the whole thing since then and went for fvwm now lol
Sounds cool
I don't know if anyone who rolls their own kernel is going to have Wayland running
managarm did
bruh they only added a -trace for hpet recently
I'm gonna have to compile qemu from source again, fun
might as well leave it compiling and go sort out dinner
the legacy replacement irq routing is done, now for the fsb message stuff
I think I had misread it cuz its not now
ah well should work on enough pieces of hardwaire with legacy replacement only
and if it doesn't I will curl up into a ball and cry
also @fleet osprey @neon crane, I fixed that vmm initialisation bug and support a 32 bit hpet now so if you feel like testing it again on those computers thatd be cool
w/ a full distro on the usual https://avalios.dev/astral.iso
oh sweet the full one is already updated? alr
btw I'll also retest that PS2 init code on the Precision since you said you weren't sure if it had the updated code or not last time
would be neat ty
32 bit hpet (ThinkPad T14 Gen 1 AMD) works great
No keyb though
Idk how it's connected
nice!
I'll go check how it's connected in a sec
Also I see nvme0 logs up there, good to see that's working as well
Yippe
I never tested nvme on real hw, great that it at least initialises lmao
on Linux it seems like all of my key presses are coming from AT Translated Set 2 Keyboard, it reports a PS/2 keyboard as being connected, and I don't see any keyboard-looking devices on USB, so I'm fairly certain it's PS/2
but ig that makes sense, you did say PS/2 support is iffy
smh, I still can't get the image flashed with dd to boot on legacy BIOS
I even tried in Windows with rufus this time and says that it's "not compatible with ISO/File Copy mode", so it had to fall back to dd mode
one sec, let me break out the Ventoy disk again, because ig that's the only way I can try to see if it can boot on the OptiPlex
even if I might not be able to get to a root prompt
I can at least test if it crashes in the VMM like it did last time
well while I wait for that to copy, I'll try this out on the Precision, where it hung doing PS/2 stuff
Also doesn't boot in BIOS there, let's see if UEFI works first then I'll try it in BIOS with Ventoy when its done copying
Only way I can see this happening in the code is if it silently fails the self test by timing out, weird
I should add a print for that tbh
I'm gonna test this latest iso on my chromebook
Ooh, it works on the Precision now (at least, in UEFI, which isn't how I tested it last time)
USB kbd doesn't work though
One sec let me bust out the PS/2 kbd adapter lol
Aw well that's annoying
My only keyboard has too much fancy RGB, draws too much power, and doesn't turn on in the adapter
Aw
What were the ps/2 logs here?
Sec, let me try rebooting it
While that goes I'm gonna test the other drive on the OptiPlex
ps2: controller found with 2 ports
That's it
Guess its a timeout again
Weird
It also might not be emulating anything on it
Or that might just only be the real controller that i can't use
True could be
that was odd...
it stopped at this for me
then I ran a command and it booted...
and by ran a command I mean hit a key

