<zid>
I don't think much hardware doesn't still support bios booting, and you can use a uefi program which boots your program as though the bios booted it
<zid>
so either is fine, and will stay fine
<Mutabah>
Most of the concepts carry over, and the good tutorials just use a pre-made bootloader, so there's no need to care what firmware interface is in use
<sonny>
ok, thanks
* sonny
is very unimpressed with amd64
<klange>
"too bad"
<sonny>
I know
<sonny>
I'll just keep screwing myself over by ignoring it xD
<sonny>
guess I'll have to wait for the Arm version of that article
<sonny>
or ... read the source code o.O
<sonny>
trying to understand cruntime and freestanding atm
skipwich has joined #osdev
<sonny>
I think I just need a minimum set of functions that can be used by a programming language, in the case of C I'm not sure how much before I can link the runtime
<klange>
ARM has no standardized boot process. For all its oddities, one actually nice thing about x86/x86-64 is that there is a common platform - one that has iteratively changed over the years.
* sonny
looses it
<sonny>
ok, you win intel
<klange>
Freestanding C does not have a runtime. There are a couple of functions _you_ need to provide, and your compiler probably has a support library it references for awkward things.
<sonny>
there's no crt0?
<zid>
you need to provide that, it generally only consists of clearing .bss though, and that's if your loader doesn't do it anyway
<zid>
and for user programs it needs to turn the sysv entry point argument style to the C style
pretty_dumm_guy has quit [Ping timeout: 256 seconds]
<sonny>
ah ok
<zid>
for some reason sysv passes arguments on the stack, but C passes them in registers
<sonny>
yeah that's odd
<klange>
C doesn't define that.
<zid>
sysv defines both
<klange>
For some reason _sysv_ defines program startup as taking arguments on the stack, but uses a C abi that passes arguments in registers
<zid>
I know that's sorta, stretching what words mean, but it is reality
<zid>
in that _start and main() use different ABIs under sysv
<klange>
(on x86-64; on x86 they're still on the stack, but it's still different from program startup)
<klange>
but this does not exist in freestanding, there is no program startup in freestanding C
<sonny>
damn
<zid>
There might be if you decide there is arguments to your freestanding program
<klange>
(Does the freestanding spec even define the concept of program entry?)
<sonny>
guess I have a lot of reading to do then
<zid>
I do, for example, but I just use the C abi on both sides so crt0 has do do.. nothing, and thus doesn't exist
<heat>
sonny, why are you unimpressed with x86_64?
haliucinas has quit [Quit: haliucinas]
dennis95 has quit [Quit: Leaving]
haliucinas has joined #osdev
heat has quit [Read error: Connection reset by peer]
heat has joined #osdev
<sonny>
heat: platform startup, just all the legacy stuff, crazy encodings etc
<heat>
platform startup is fine, legacy stuff is minimal (just the IDT and GDT really, plus a fake and very different TSS), crazy encodings are something you don't need to worry about
<sonny>
ok, fair
<zid>
plus what you're describing is basically "isn't a microcontroller"
Likorn has joined #osdev
sonny has quit [Ping timeout: 252 seconds]
<heat>
tbf arm64 is design is cleaner and the instructions are way simpler to parse
<heat>
s/arm64 is/arm64's/
dude12312414 has joined #osdev
eryjus has quit [Remote host closed the connection]
XgF has quit [Ping timeout: 248 seconds]
gmodena has quit [Ping timeout: 240 seconds]
XgF has joined #osdev
Ali_A has quit [Quit: Connection closed]
heat has quit [Remote host closed the connection]
heat has joined #osdev
pretty_dumm_guy has joined #osdev
terminalpusher has quit [Remote host closed the connection]
kingoffrance has quit [Ping timeout: 240 seconds]
MrPortmaster has quit [Quit: ZNC 1.7.5+deb4 - https://znc.in]
gildasio has quit [Ping timeout: 240 seconds]
sonny has joined #osdev
Likorn has quit [Quit: WeeChat 3.4.1]
<geist>
more and more so, yes
<geist>
ah another delayed response
<heat>
yo geist do you know if the amd PSP and the intel ME processor have memory of their own?
<geist>
and yeah, x86-64 is unimpressive, but for the most part all complex high end architectures have lots of accumulated cruft. its inevitable
<geist>
heat: good question, or do they carve out a piece of the main ram
<geist>
probalby the ltatter, since they're running more than microcontrollery stuff
<geist>
but they might have ta least one bank of private ram
<geist>
but honestly i dunno
heat_ has joined #osdev
heat has quit [Read error: Connection reset by peer]
<heat_>
intel's i486 thingy running on DDR5 seems fun :D
<bslsk05>
tice.sea.eseo.fr: emulsiV - Simulator for Virgule, a minimal processor based on the RISC-V architecture
<heat>
ooooooooh very cool
<sonny>
geist: yeah I just came back so I wondered what the response was to
<sonny>
nice emulator
<jimbzy>
Oh wow. That is really nifty.
<geist>
sonny: oh it was a response to the 'does uefi matter' question
gmodena has joined #osdev
<sonny>
ok
MiningMarsh has quit [Ping timeout: 240 seconds]
<heat>
sonny, if you don't like x86's BIOS bootloader part, UEFI is perfect for you
<heat>
you'll also start seeing UEFI firmware without the CSM module that lets it pretend it's a BIOS
<sonny>
seems so, but I'm just trying to wrap my head around some things before I decide yet
MrBonkers has joined #osdev
<heat>
which things?
<sonny>
I don't need to pretend it's a bios, making my OS an efi app sounds like a good idea
<heat>
your kernel shouldn't be an EFI app
<heat>
at least not all the way
<sonny>
heat: minor stuff, like my development env, and libc / platform setup
<heat>
usually you have your bootloader which just loads your kernel and jumps to it
kingoffrance has joined #osdev
<geist>
also FWIW UEFI is taking hold in at least some part of the arm and riscv space
<sonny>
isn't a kernel an executable?
<heat>
some os's opt into the efi stub thing where the kernel pretends it's a regular UEFI app until it "gets out" of the efi environment
<sonny>
why not be an efi app?
<geist>
it's a matter of perspective
<sonny>
ok
<geist>
right, what heat said
<geist>
you cna load it as an EFI app if you'd like, but 'keeping efi around' is relatively hard, but it has a call for precisely 'i'm done and want to take control of the system'
<geist>
ExitBootServices()
<sonny>
oh ok
<geist>
so it's not a weird thing to load as EFI, do what you need to do, and then 'take over'
<heat>
like, UEFI has its boot environment with boot services, drivers and all that, and regular UEFI apps never exit; bootloaders and kernels usually exit out of it as soon as they can
<sonny>
that makes sense
<heat>
if you think you could use EFI's drivers, you can't
<heat>
unless you want to be a poor man's DOS
MiningMarsh has joined #osdev
<sonny>
haha
<geist>
in the old days when DOS was more around it was fairly frequent to use DOS as a loader, effectively. not fundamentally that different from this
<geist>
ie, run LOADLIN.EXE, etc
<heat>
they're really good but also limited and without interrupts
<sonny>
oh, also character devices is something I'm thinking about
<sonny>
to either use serial or a custom console driver
<sonny>
the latter I can't run on real hardware though
<heat>
(something i've been doing is that i've been using the UEFI drivers as reference sometimes, and it's pretty sweet since they're usually super correct; these "intel" folks seem to know what they're doing :P)
<heat>
sonny, what's a custom console driver?
<sonny>
I'll make something like windows console, then make a driver for it so I can visualize stuff in my OS
<heat>
that works in real hardware
<sonny>
not sure how to explain
<heat>
how do you think linux's ttys work? :P
<sonny>
it's just going to be a text edit ui widget
<geist>
on what hardware does this happen?
<sonny>
It won't actually do real graphics
<heat>
traditional unix designs treat everything as TTYs, which are just pipes through which you pipe text in and out of
<sonny>
ah
<heat>
in linux, /dev/tty0 is a virtual terminal (emulated in your computer and gets drawn onto your screen), /dev/ttyS0 is a serial port, /dev/ttyUSB0 is a usb serial port, /dev/ttyAMA0 is raspi's uart, etc
<heat>
(the 0 is an example, you can have multiple (or none) ttys of each kind)
<sonny>
right, yeah that sounds familar
<heat>
then you also have pseudo terminals which let you do the terminal emulation in user-space
<heat>
/dev/pts/0 for instance
Ali_A has joined #osdev
<sonny>
ok great, I'm starting to get a better picture in my head
<heat>
basically, the terminal (the thing behind the tty) does the displaying, input, and tracks which cells have what
<heat>
the tty does basic input/output to the terminal, plus some basic text transformation (for example, '\n' usually gets transformed into '\r\n') and job control
<geist>
of course this was an outgrowth of early terminals being serial based character things, teletypes probably. hence tty
<heat>
for instance when the tty subsystem gets a ^C from the terminal, it sends SIGINT to the foreground process(es)
<geist>
but it's a minimum abstraction over the time of the minimum hardware to accomplish it
<geist>
but it's a nice lowest common denominator
<heat>
yeah
<heat>
for instance, you can technically set your baud rate through the tty interface but your virtual terminal (in your screen) doesn't have a concept of a baud rate so it's a no-op
<sonny>
heh, so I could replace a virtual terminal with something better!
<sonny>
thanks to tty
<geist>
yah. that's why things like vt100 control signals exist: let you via a single stream of characters also do more advanced stuff like move around a screen, etc
<heat>
you can replace a virtual terminal with a terminal emulator over serial, a real vt100 or ssh/putty as they all speak the same vt100 language over the tty interface
heat has quit [Remote host closed the connection]
<geist>
it was a hack on top of an existing teletype based system, where you couldn't reallly do much execept move forward on the page
heat has joined #osdev
<geist>
but then CRT based terminals came along and needed a way to embed more control signals in it
<geist>
but, eve though it was designed in the 60s, it still works fairly well
<geist>
sometimes simple, 60s era abstractions and solutions are still pretty good in the end
<sonny>
afk
<heat>
if there's something you don't want to do though, it's to not implement a vt100
<heat>
because everyone speaks vt100
<heat>
(actually, everthing speaks xterm which is a superset of the vt100 interface)
<bslsk05>
netxs-group/vtm - Terminal multiplexer with window manager and session sharing (30 forks/964 stargazers/MIT)
<geist>
i was actuallyl thinking it might be the opposite and the linux TERM is simpler, but not easy to find good docs on it
<heat>
nah it implements mostly everything in a vt100
<heat>
not perfect of course, but good enough
<heat>
the terminfo of TERM=linux is a bit more complex than the standard vt100
<geist>
yah looks like it might be a superset of vt100 but a subset or vt220 and/or xterm
<geist>
maybe vt100 + colors or something
<geist>
heat: oh you might be interested, was just fiddling with qemu 7.0 for riscv and it seems to have some sort of built in (or probably in /usr/share) uboot and/or uefi firmware for riscv
<geist>
i just told it to boot a ubuntu riscv uefi image and it just started up without anything external
<heat>
but yeah there's theoretical RISCV support in edk2
<heat>
not sure how well it works
<geist>
yah in this case it's probably uboot that's providing a uboot
<geist>
er uefi
gmodena has quit [Ping timeout: 256 seconds]
XgF has joined #osdev
<gog>
oof-ey
<gog>
öfey
<j`ey>
qemu 7.0 also has fixes to work on linux on apple silicon!
vimal has quit [Remote host closed the connection]
<heat>
does it have venus?
<heat>
please tell me it has venus
dude12312414 has quit [Remote host closed the connection]
<heat>
ohhh right that reminds me
<heat>
let me see if i can build crosvm
Gooberpatrol66 has quit [Remote host closed the connection]
<geist>
j`ey: yeah iirc there was something that handles the fact that M1 has a short IPA
<geist>
36 bits i think
<j`ey>
yep!
<geist>
when i was fiddling with it before i had to use ,himem=off to avoid the virt putting the high PCI aperture in a bad place
<j`ey>
I think qemu just defaulted to 42 bits
<geist>
right
<j`ey>
although that fix was in the kvm parts, not sure if hvf works without that now, havent tried
<geist>
i was looking at the s390x support in qemu. you *can* write code on an emulated VM. kida like the virt arm/riscv machine
<geist>
also a mystery solved: s390 == s/390, 90s era 32bit IBM mainframes
<geist>
s390x == z/Machine, the 64bit extension that is current
<geist>
the x matters. that was confusing me a bit
<geist>
apparenlty the x is a linuxism, qemu is just calling it what linux calls it
freakazoid333 has quit [Quit: Leaving]
Likorn has joined #osdev
freakazoid333 has joined #osdev
<geist>
heat: so all is not well. the uboot i'm using seems like maybe isn't good enough UEFI wise, the kernel panics always a bit in with some uefi call
<geist>
haven't debugged it, but i suspect it's uboot related
<geist>
or more specifically uboot-providing-uefi related
ssiyad has quit [Remote host closed the connection]
GeDaMo has quit [Remote host closed the connection]
<heat>
j`ey, hey rust person, isn't cargo build supposed to output stuff to target/debug/...?
wootehfoot has quit [Quit: Leaving]
* geist
puts the rust person on the spot
<heat>
"If you simply want to try crosvm, run cargo build. Then the binary is generated at ./target/debug/crosvm"
<heat>
it's not there
<heat>
???
<j`ey>
heat: woops
<j`ey>
it should be yes, or target/<arch>/debug/
<j`ey>
or maybe it's in release?
<geist>
if only there was a way to instruct the computer to search for the file
<heat>
it's still not there
<heat>
cargo build didn't build it?
<heat>
google is scamming me :(
<geist>
maybe yuo have to build from a subdir? i vaguely remember it was a little funny
<geist>
built it once a while back
<geist>
like maybe you have to cd to src and build in there?
<heat>
the docker thing they gave me didn't work
<heat>
it did work from Arch Linux, which I do use
<heat>
btw
<heat>
i should look into what kernels it can boot
<heat>
if it only boots linux then that's kinda sad :/
<heat>
i wanted to see how venus works, et al
<j`ey>
just make the kernel look like linux
the_lanetly_052_ has quit [Ping timeout: 272 seconds]
sonny has quit [Ping timeout: 252 seconds]
<heat>
j`ey, the day I use linux's x86 boot protocol is the day my kernel goes from poor man's linux to shitty poor man's linux
Gooberpatrol66 has joined #osdev
<j`ey>
:-)
sonny has joined #osdev
sonny has quit [Quit: Client closed]
netbsduser has joined #osdev
netbsduser` has quit [Ping timeout: 240 seconds]
gog has quit [Ping timeout: 256 seconds]
mahmutov has quit [Ping timeout: 272 seconds]
ptrc has quit [Remote host closed the connection]
ptrc has joined #osdev
gog has joined #osdev
heat has quit [Remote host closed the connection]
sonny has joined #osdev
heat has joined #osdev
jhagborg has joined #osdev
Ali_A has quit [Quit: Connection closed]
heat has quit [Remote host closed the connection]
Ali_A has joined #osdev
jhagborg_ has joined #osdev
jhagborg has quit [Ping timeout: 240 seconds]
jhagborg_ has quit [Read error: Connection reset by peer]
jhagborg_ has joined #osdev
sonny has quit [Ping timeout: 252 seconds]
pretty_dumm_guy has quit [Quit: WeeChat 3.5]
Burgundy has quit [Ping timeout: 256 seconds]
sonny has joined #osdev
hodbogi has joined #osdev
<hodbogi>
I am evil and made a 64K 4K aligned PAD at the beginning of .data for scratch memory until the memory manager is active.
<hodbogi>
(I call it the PAD because I like Forth)
<sonny>
what is "Scratch Memory"?
jhagborg_ has quit [Remote host closed the connection]
jhagborg_ has joined #osdev
<klange>
https://youtu.be/3-drTA8FvkQ did some improvements to my path stroking so I can actually dynamically render these graphs each frame
<bslsk05>
'ToaruOS System Monitor dynamic graphs' by K Lange (00:01:06)
<kingoffrance>
scratch == "use for any purpose" ? you see it with registers some times