<Ali_A>
so, after booting to x86 where can I read about starting to write a VGA driver (I saw a page on VGA hardware which is a good start but what after that?) I am using qemu so I don't have a real hardware to work with
<mrvn>
Do you have a working VGA driver?
<mrvn>
Do you have a working vga driver for all the vga cards qemu and bochs can emulate?
<moon-child>
mrvn: stack alignment
<mrvn>
ahh, because of the CALL. grrr
<moon-child>
note clang has the useless pushes and pops, which accomplish the same thing
<mrvn>
And why isn't it using "DIV r/m64"? Doublequadword/quadword
<Ali_A>
mrvn no I just booted my kernel and I want to read about writing a VGA driver, the problem is that there are a lot of hardware `abbreviations` and things I don't know when reading online tutorials, so if there is something like `read this first` before writing a VGA driver would be great, sounds like a nooby question but honestly can not find any
<Ali_A>
resources that just doesn't smash code without talking first about the hardware, how it works and so on
<moon-child>
idk
<mrvn>
I've added assert(a < n) but it still doesn't use div
<moon-child>
replace assert with __builtin_assume?
<moon-child>
(or, if(!whatever)__builtin_unreachable(), same thing)
<mrvn>
Ali_A: vga and even svga is stone age tech. You don't want it anyway.
<mrvn>
Urgs, gcc then adds a "call __builtin_assume"
<Ali_A>
that is what I thought, but read on OSdev formus, if u never wrote a vga driver, u will be struggling to write a proper modern driver, so they suggested to start there
<mrvn>
Ali_A: just tell grub to give you a framebuffer and start there
<Ali_A>
I don't have that, I am boot-loading it myself
<mrvn>
Ali_A: there is your first mistake
<Ali_A>
'=D which I was told countless times it is a bad idea
<Ali_A>
it is my first iteration in OSdev I really wanna understand everything that happens first,
<Ali_A>
it is more of understanding what the tool can do for me before I use them. at least that is my idea about it
<bslsk05>
gcc.gnu.org: GCC 12 Release Series — Changes, New Features, and Fixes - GNU Project
<geist>
it mentions CTF as a lightweight debugging format. might be a nice substitute for dwarf or whatnot for in-kernel backtraces
Vercas has quit [Ping timeout: 240 seconds]
wootehfoot has joined #osdev
mahmutov has joined #osdev
w41 has quit [Ping timeout: 276 seconds]
<kazinsal>
oh, that could be handy
ex0matter has joined #osdev
<kazinsal>
(Note one irregularity here: the ctf_archive_t is not a typedef to struct ctf_archive, but a different typedef, private to libctf, so that things that are not really archives can be made to appear as if they were.)
<kazinsal>
oh gnu. you're so wacky.
<zid>
ooh digit seps and %b
eroux has joined #osdev
Clockface has quit [Ping timeout: 246 seconds]
<zid>
oh the always init stuff is now mainline eh, kernel's been using that for a loong time
eroux has quit [Ping timeout: 256 seconds]
bauen1 has quit [Ping timeout: 250 seconds]
bauen1 has joined #osdev
w41 has joined #osdev
Likorn has joined #osdev
Burgundy has joined #osdev
ex0matter has quit [Ping timeout: 240 seconds]
Vercas has joined #osdev
vimal has joined #osdev
wootehfoot has quit [Read error: Connection reset by peer]
<mrvn>
goodby m68k*-*-openbsd* and vax-*-openbsd*
<moon-child>
mrvn: out of curiosity, what are you using the 128-bit ints for?
<mrvn>
primality test for uint64_t
the_lanetly_052 has joined #osdev
pretty_dumm_guy has joined #osdev
mahmutov has quit [Ping timeout: 276 seconds]
nyah has joined #osdev
dude12312414 has joined #osdev
heat has joined #osdev
alpha2023 has quit [Read error: Connection reset by peer]
<mrvn>
You know some programming course assigned some homework when 3 people come to stackoverflow having problems writing a function "printmat".
Vercas has quit [Remote host closed the connection]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
heat has quit [Remote host closed the connection]
heat has joined #osdev
Vercas has joined #osdev
bauen1 has quit [Ping timeout: 250 seconds]
bauen1 has joined #osdev
dude12312414 has joined #osdev
ngc0202 has joined #osdev
the_lanetly_052 has quit [Ping timeout: 260 seconds]
<Ali_A>
so I am filling the screen by writing to pixels at address `0xA0000` looping by (320*200 -1) however, I feel like the display kinda have gaps in it? is this normal? or is it related to qemu or what exactly?
<Ali_A>
(this happens immediately after I boot and switch to 32-bit mode)
<bslsk05>
pastebin.com: ; bootloader.asm; A simple bootloader[bits 16];org 0x7c00 ; the addres - Pastebin.com
<Ali_A>
here is the bootloader code I am using, I set the video mode to 0x13 in the beginning
<GeDaMo>
Ali_A: VGAMemory should be char * or uint8_t *
<GeDaMo>
Well, unsigned char *
<Ali_A>
GeDaMo That worked, it seems I was having a problem since the bios memory for text mode uses unsigned short, this one just uses the unsigned char.
<Ali_A>
I did change it before that, but now I noticed I changed the BIOSMemory pointer and not the VGAmemory but thanks! it is fully clearing it
<GeDaMo>
Text modes use two bytes, one for the character the other for the attribute
<Ali_A>
and I believe if I wanted text in this mode, I have to write my own bitmap font right?
<GeDaMo>
Yes
<Ali_A>
sounds a bit fun, going back to the old days + that helped a lot thanks!
<bslsk05>
wiki.postgresql.org: Fsync Errors - PostgreSQL wiki
<mrvn>
No idea if it is buggy or not but POSIX says fsync returns EIO on error.
<mjg>
oh it is
<mjg>
Linux < 4.13: fsync() errors can be lost in various ways; also buffers are marked clean after errors, so retrying fsync() can falsely report success and the modified buffer can be thrown away at any time due to memory pressure
<mjg>
fixed past that
<mrvn>
good to know. but back to mmap
<mjg>
my general point being that trusting your data to be on storage requires a lot of faith
<mjg>
ye, mmap can get you fucked
<mjg>
you either can tolerate it or not, if not, don't use it
<mrvn>
there is no EIO specified for msync(). So the kernel can't even report an IO error later when you do msync
<mjg>
i'm guessing you would sync_file_range despite using mmap
<mjg>
but again, i don't trust data to be safely recoverable from storage no matter how many :"flush everyting" calls you make
<mrvn>
And then there is the obvious drawback that if you memcpy 4096 bytes into an mmaped file it first reads the old block just to overwrite it.
<mjg>
if you are trying to say that there are cases where mmapping is a bad idea, i don't think it's much of a contested point
<mjg>
also i don't know if you are trying to defened that SO guy or what
<mrvn>
More. I'm saying mmap of a file is nearly always a bad idea. Only good use case I see is to use a big file as swap private to your app.
<mrvn>
mjg: I haven't touched on the speed yet. :) I believe read/write done properly will be faster than mmap too.
<mjg>
mmap will easily be a huge win if what you have is a big f-word file you just need to processes
<mjg>
process
<mjg>
read-only
<mrvn>
yep. That's your private swap file usage.
<mjg>
well can be if you it happened to use hugepages
<mjg>
the moment you start writing we run into a lot of handwaving territory
<mjg>
boiling down to "bench it"
<mrvn>
Gimp stores the image data in mmaped files. Another good private swap file use case.
<mrvn>
If you have data near or bigger than your ram then mmap is your friend, at least if you need random and partial access.
<mrvn>
if you arte writing control software for a nuclear reactor then maybe stay far away from mmap.
<geist>
heh freebsd 13.0 recommends i upgrade to a newer release because 13.0 is reaching EOL
<geist>
but 13.1 isn't released yet
<geist>
thoguh i guess the recommendation isn't strictly speaking nonsense. it's just timed such that it starts warning a bit too early, IMO
<mjg>
tf you have freebsd for
<geist>
<Gasp> heretical right!
<mjg>
to be fair, 13.1 was supposed to be out but funny regressions resulted in delays
<geist>
i have only prayed to linus 3 times today
<mjg>
rc6 just built
<mjg>
official release on may 16
<geist>
yah probably just delays and they had some sort of hard EOL baked into 13.0, i'm guessing
<mjg>
you reminded me of eler though
<mjg>
lemme find the classic
<mrvn>
maybe you should upgrade to openbsd or hurt?
<geist>
it's one of my VMs. i keep around one of a lot of systems
<bslsk05>
geekz.co.uk: An actual woman – Everybody loves Eric Raymond
<mjg>
geist: which illumos? i used to have omnios, but eventually it stopped being able to update to "bloody" and i gave up on it
<geist>
was a few years back
<geist>
i honestly dont remember. the VM file is floating around here somewhere but it was virtualbox at the time
<geist>
would need to convert over
<mjg>
i got free, net, open, dfly, omnios and TEMPLEOS
<mjg>
forgot about that one
sonny has quit [Ping timeout: 252 seconds]
<mjg>
any usage problems with illumos aside, it keeps eating CPU while idle
<mjg>
i did some dtracing to figure out what's going on
<mjg>
the kernel keeps having fun doing tons of avoidable maintanence work
<mjg>
and most importantly zfs has fun constantnly generating i/o
<mjg>
afair it was at about 15% cpu on my laptop while supposedly idle
sonny has joined #osdev
<mrvn>
I'm daeth on that kind of behavior.
<mjg>
also funzy. the vm is 2 thread. it runs into lock contention
<mjg>
:)
<mjg>
while idle
elastic_dog has quit [Ping timeout: 240 seconds]
<mrvn>
Poll: Who is `using namespace std::literals;`?
elastic_dog has joined #osdev
elastic_dog has quit [Excess Flood]
<mjg>
fuck man, i'm tracking my weight every day since march 17
<mjg>
i just plotted it
<mjg>
got from 69 kg to 76
<mrvn>
intentionally?
<mjg>
no
<mjg>
now i'm slightly overweight
<zid>
have you considered only eating foods ending with x
<mjg>
like pizzax?
<zid>
it's a good diet because your food options are so limited besides borax
<mjg>
i could still have clorox
<mrvn>
I only eat on days ending in y
<mjg>
but no, i have not came to that yet
elastic_dog has joined #osdev
<mrvn>
Ritter Sport chocolate has a flavour for every diet but I'm not sure if it has any that ends in x
<mjg>
i just made up my own: peanut butter sandwitchx
<mrvn>
no jelly?
<mjg>
i thought pb&j is a USA thing
<mjg>
also sounds gross
<geist>
ugh, gcc 12 is even more aggressive about array bounds
<geist>
seems to hate it any time you simply derefrence a memory address
<geist>
because it claims it out of bounds of some sort of implicit zero length array
<mjg>
you got [0] arrays?
<geist>
yep
<mjg>
just [] them
<geist>
well, i mean it's not an array
<mrvn>
geist: you mean (ptr*)0x423423; kind of things?
<geist>
like if you just make a pointer to some address and deref it
<geist>
yep
<geist>
whats the canonical solution to that?
<moon-child>
mjg: lox!
<mrvn>
That's a regresion. The warning was supposed to catch access to NULL with a small offset
<moon-child>
geist: iirc there was some bug
<geist>
i remember there was some blab about it a while back
<geist>
and iirc there was a lot of pushback to the effect of 'good programmers shoulnd't do that'
<mrvn>
I don't think there is a solution for it yet. You have to turn off the warning for that.
<geist>
thanks. sometimes when you're embedded the thing is literally right there and you need to deref it
<geist>
yah
<mjg>
hm. you would think this would be sorted out with freestanding
<mrvn>
mjg: freestanding can do (*NULL).foo too
<moon-child>
need -fno-delete-null-pointer-checks if you wanna play that kinda game
<geist>
looks like making an array out of it doesn't help
<mjg>
-fno-surprises
<mrvn>
geist: volatile?
<mjg>
not implementable
<geist>
ie, int *foo = address; foo[2] is out of range
<geist>
volatile doesn't seem to change anything
<mjg>
can you make foo to be typed as an array
<moon-child>
mjg: i wish. -fwrapv -fno-strict-aliasing -fno-delete-null-pointer-checks, still provenance rules tho...
<mrvn>
geist: volatile int * volatile?
<geist>
interesting, that seems to work around it
<geist>
by making the pointer itself volatile
<geist>
ie, `volatile int * volatile foo = (void *)address;`
<mrvn>
mjg: There is no way to specify an array size for a literal address like 0xFE201000
<geist>
then yuo seem to be able to deref foo all you want
<mrvn>
by making it volatile the compiler can no longer reason about the content so it looses the info that it's a literal.
<geist>
also sort of interestingly you can assign it null and then deref that
<mrvn>
Drawback is that "foo[0] + foo[1]" will read foo twice.
<geist>
thus allowing you to deref any pointer as an array offset
<mjg>
maybe you can devolatile the final pointer and still keep the workaround working?
<geist>
anyway, ugh this sucks
<mrvn>
geist: It could be a hardware register where you write in a descriptor and then read out the address associated with the descriptor or something.
<geist>
yes except thats not what this is
<geist>
oh yeah i mean yeah
<geist>
exactly. like where's the thing? it's here, cast a thing to it. BOOM YOU DIE
<geist>
in this precise code i have a word that was written in firmware, at the fixed adress
mahmutov has quit [Ping timeout: 260 seconds]
<geist>
i just want to read the word. becuase it's ltierally just there
<mrvn>
Only thing that helps is getting all your hardware addresses out of the DT dynamically instead of hardcoding addresses. :)
<mrvn>
(or disable the stupid warning)
<geist>
yah it's really dumb
<geist>
or at least not very helpful to low level programming. i hate to turn off warnings for edge cases like this, but still
<mrvn>
gets lots of false positives wiht linux too. It's a wonder they haven't fixed it yet.
<mrvn>
I want something like volatile uint32_t *periphery = (volatile uint32_t *)0xFE201000 __attribute__(("bounds", 0, 0x100));
<clever>
kinda, but the type of dlist_memory immediately throws that size part out?
<mrvn>
nah, gcc should remember it
<clever>
what if this was extern
<clever>
and other modules accessed it?
<mrvn>
Then it won't know what size it is and not give any warnings
<clever>
yeah
<mrvn>
This was to fix the problem that REG32(SCALER_LIST_MEMORY) is marked as size [0] and alway warns.
<mrvn>
For extern use you need to change the type and struct with an array works best
sonny has quit [Quit: Client closed]
<mrvn>
geist: you could put the address into the linker script and mark it extern.
<geist>
also ugh, gcc 12.1 riscv seems to make you want to have to pass 'zicsr' to the march switch to allow yuo to get to CSR instructions
<geist>
which are technically an extension, but seemed to be implicit before
<geist>
so i add that (-march=rv64imaczicsr) and now it messes up my multilib matching
gog has joined #osdev
<geist>
CSRs are control registers, so i think the idea of having it be an extension is either you're compiling user code which i think can't touch any CSRs because there arent any, or i guess maybe you can build an extremely deeply embeded core that doesn't implement interrupts or exceptions and thus never need to read any?
<mrvn>
Not sure something like that should change the ABI for multilib