<immibis>
alternate object versions are terrible unless one is just an old snapshot that you are still reading
<immibis>
or they serve some specific purpose such as history
<immibis>
don't let two people open the same document and then edit the same document separately without realizing they're conflicting with each other. It may sound technically cool to do that without a conflict, but one of them is still going to overwrite the other's changes
<immibis>
or corrupt the document entirely when you merge them
biblio has quit [Quit: Leaving]
<gog>
data integrity is overrated
Burgundy has quit [Ping timeout: 256 seconds]
gog` has joined #osdev
gog has quit []
gog` is now known as gog
<immibis>
chaos monkey operating system
dude12312414 has joined #osdev
<gog>
chimpin ain't easy
sdfgsdfg has joined #osdev
freakazoid12345 has joined #osdev
freakazoid343 has quit [Ping timeout: 250 seconds]
dude12312414 has quit [Remote host closed the connection]
kingoffrance has quit [Ping timeout: 240 seconds]
skipwich has quit [Read error: Connection reset by peer]
ElectronApps has joined #osdev
x__ has joined #osdev
sdfgsdfg has quit [Quit: ZzzZ]
<x__>
"i think a fun part about defining an interface that's not C/posixy looking is really rooting out all the edge case semantics" yes, i think it would be important to make sure things actually use whatever interface i.e. userland written to take advantage. that would be the fun IMO to see what develops there and where that leads
x__ is now known as kingoffrance
<kingoffrance>
rather than half-heartedly porting things from elsewhere
pretty_dumm_guy has quit [Quit: WeeChat 3.4]
<moon-child>
ah yes, the beautiful, clear, and obvious interface that handles all edge cases: open() close() read() write() and ... ioctl()
<kingoffrance>
well yeah, ioctl strikes me as pragma, can do anything :)
<kingoffrance>
no edge cases :)
<moon-child>
why not just dispence with the former four? ioctl(special, OPEN, ...). ioctl(fd, READ, buf, ...)
scoobydoo has quit [Ping timeout: 240 seconds]
<kingoffrance>
exactly!
<zid>
that's called winapi
<zid>
CreateWindowEx with 14 args and it can do nearly anything
<geist>
kingoffrance: heh i didn't go there re: versions
<geist>
but you *could*
sonny67 has joined #osdev
<GreaseMonkey>
a potential OS paradigm would be to have your entry point return some structure which tells the OS how to set up the process and its threads and whatnot
<GreaseMonkey>
dunno how garbage that would be but it might actually be fun to explore
<moon-child>
why would that be better than the alternative?
<dh`>
more or less what dynamic linkers do
<sonny67>
things to explore are security, currency, and networking imo. I think that will determine what the rest of your os will look like
<moon-child>
process model is killing unix
<moon-child>
io_uring is cool but sometimes you need to synchronize
<moon-child>
and software-based security is faster anyway
<zid>
yea that's basically identical to how ld.so works
sonny67 has quit [Quit: Client closed]
ravan has joined #osdev
sonny has joined #osdev
sdfgsdfg has joined #osdev
sonny has quit [Quit: Client closed]
rustyy has quit [Quit: leaving]
rustyy has joined #osdev
GeDaMo has joined #osdev
zaquest has quit [Remote host closed the connection]
zaquest has joined #osdev
MarchHare has joined #osdev
mahmutov has joined #osdev
<zid>
I slowly closed the light novel volumes I was reading as I was done, and I finally got to the one tab I was dreading
<zid>
325462-sdm-vol-1-2abcd-3abcd.pdf
<GeDaMo>
No volume 4? :P
<kazinsal>
bizarrely volume 4 *is* in that file, it's just not in the name
<kazinsal>
at least, it is in my copy
<zid>
The plot isn't very interesting
<kingoffrance>
i thought you liked big words?
<geist>
kazinsal: question: what grub.cfg syntax do you use to load your kernel?
<kazinsal>
via TFTP?
<kazinsal>
one sec
<geist>
yah, i have grub loading off tftp, etc
<geist>
but then was trying to build a menu.cfg and so far it's pretty linux centric
<geist>
before going down that rabbit hole i was hoping there was still a simple command for 'put this multiboot stuff there'
<kazinsal>
this one's basically set up to quickly boot via TFTP as fast as possible
<geist>
hmmm, multiboot is the one i was hoping would work
<kazinsal>
serial console, no menu unless you hit enter within the 2 second timeout period
<geist>
this particular grub (cribbed from a mint linux install /boot partition) gives a symbol error when trying to use the multiboot command
<geist>
'err: symbol grub_calloc not found' etc
<geist>
but, then i didn't build it so maybe its simply broken
<kazinsal>
did you just grab modules etc from there or did you run grub-mknetdir?
<geist>
i basically grabbed /boot/grub/.... stuff
<geist>
and dumped it in the tftp root so it loaded it up
<geist>
so i guess i should do the right thing
<kazinsal>
ah, run `grub-mknetdir --net-directory=/your/tftp/root/directory`
<geist>
also, and this may be a deal breaker, i'm currently using the UEFI version of it
<kazinsal>
it'll grab modules from /usr/lib/grub/<platform>
<geist>
but i assume grub may be able to multiboot load something even if it was previously loaded from UEFI
<geist>
kk
<kazinsal>
it should, yeah
<geist>
kk trying.
<zid>
how does pxe.. work?
<zid>
It has bootstrapping issues
<kazinsal>
there's a ROM on a PXE-compatible NIC that provides some basic services for UDP/IP and TFTP
<geist>
have to configure a DHCP server to tell the device what tftp server to fetch files from
<geist>
or in this case, the UEFI bios simply understands all of this
<zid>
it has to obtain an ip and stuff? that fast?
<zid>
I figured it used some much simpler thing cus that's too slow
<geist>
takes a second or two
<kazinsal>
yeah, it basically does a 3-second wait when the option ROM is first run for a DHCPOFFER
<kazinsal>
if it gets one, and options 66 and 67 are present, it uses those to TFTP a boot program
<geist>
grub itself immediately fetches a bunch of additional things over tftp as well
<kazinsal>
iirc the boot program can be up to 32K
<kazinsal>
or maybe it's 64K
<geist>
yah and *that* is the old PXE boot. there's new things called more or less the same thing (or confusingly called that)
<zid>
it's weird that in that system every machine rapidly does two dhcps, once for the bios and once for the OS when it boots, unless pxe has some multiboot type thing and you can transfer that info
<kazinsal>
boot/grub/i386-pc/core.0 is the NBP for GRUB and it's 48K
<geist>
that use the same scheme to simply fetch UEFI binaries off tftp
<kazinsal>
yeah each stack does its own DHCP stuff
<geist>
oh this is an ancient grub binary. need to find a newer one. that's the problem
<kazinsal>
most DHCP servers remember MAC addresses though so chances are your OS's DHCPDISCOVER will be replied to with the same address it handed out to the PXE
<zid>
yea probably
<kazinsal>
geist: I can tar up my TFTP directory for you if you want
<geist>
are you using UEFI in this caes?
<kazinsal>
oh, no, i386-pc
<geist>
rtight, exactly
<geist>
i'm hoping this will work so i dont have to enable CSM on this particular machine
<geist>
but turns out the grub uefi binary i grabbed off the net is from 2014, so it's out of date with the modules it's trying to load
<zid>
You can't just.. install grub?
<zid>
from your package manager
* gog
yawns
<geist>
no
<gog>
no time for coffee ;-;
<geist>
hmm, yes it's as a feared. you need a network equipped grub
<geist>
normal grubx64.efi you get on regular boot partitions doesn't seem to do network
<geist>
the plot thickens
<zid>
hmm I don't see a network option
<zid>
just efi-32 efi-64 multiboot xen etc
<zid>
nls?
<kazinsal>
check if you have a net.mod
<geist>
that may be precisely why i had grabbed this random grubnetx64.efi off the net. it may be special
<geist>
kazinsal: doesn't matter. the trace on tftp (tcpdump of port 69) shows that it doesn't try to fetch any mods
<geist>
because it doesn't understand networking intrinsically
<geist>
yah i figured it was, i just really have little desire to futz with multiboot fundamentally, so i usually just cobble something together and forget about it until next time
Goodbye_Vincent has joined #osdev
<geist>
a little slow. about 25 second turnaround
<geist>
so not ideal
<geist>
from reset button through grub
Jari-- has quit [Remote host closed the connection]
k0valski18 has quit [Remote host closed the connection]
<geist>
but like 18 of those are just this particular machine POSTing so oh well
gog has quit [Ping timeout: 252 seconds]
k0valski18 has joined #osdev
<geist>
kinda neat watching grub use its mods. that command.list file apparently contains a mapping of command line commands to which modules they come from
wand has quit [Remote host closed the connection]
<geist>
so it seems to lazily load a .mod only when needed. also fs.lst, etc
<geist>
makes sense
wand has joined #osdev
<zid>
woo I am sub 10 minutes at 4x4x4 rubik's cube, time to go pro
<GeDaMo>
Great, we can all quit our jobs and live off of zid! :P
gog has joined #osdev
Burgundy has joined #osdev
scoobydoo has quit [Read error: Connection timed out]
scoobydoo has joined #osdev
gog has quit [Ping timeout: 252 seconds]
biblio has joined #osdev
gog has joined #osdev
<gog>
mew
MarchHare has quit [Quit: Leaving]
sortie has quit [Ping timeout: 240 seconds]
sortie has joined #osdev
wikan has joined #osdev
ElectronApps has quit [Remote host closed the connection]
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<bslsk05>
github.com: sophia/cpu.c at main · adachristine/sophia · GitHub
jafarlihi has quit [Ping timeout: 240 seconds]
<gog>
ope
mahmutov has quit [Ping timeout: 256 seconds]
nyah has joined #osdev
freakazoid12345 has quit [Ping timeout: 240 seconds]
the_lanetly_052 has joined #osdev
freakazoid333 has joined #osdev
biblio has joined #osdev
jjuran has quit [Ping timeout: 240 seconds]
jjuran has joined #osdev
freakazoid333 has quit [Ping timeout: 250 seconds]
scoobydoo has quit [Read error: Connection timed out]
scoobydoo has joined #osdev
freakazoid333 has joined #osdev
mahmutov has joined #osdev
mahmutov has quit [Ping timeout: 252 seconds]
freakazoid333 has quit [Ping timeout: 250 seconds]
ElectronApps has quit [Remote host closed the connection]
dude12312414 has joined #osdev
<gog>
my code is trying to execute at 0xb0000
* gog
scratches head
terminalpusher has joined #osdev
<terminalpusher>
Computers using PowerPC can't use UEFI to boot up and have to use the old BIOS because UEFI doesn't support PowerPC, correct?
<gog>
PowerPC typically has OpenFirmware
<terminalpusher>
oh, on Wikipedia I read that "Unofficial UEFI support is under development for POWERPC64 by implementing TianoCore on top of OPAL"
<terminalpusher>
so I assumed the support wasn't finished yet
<gog>
i can't think of any production machines currently using ppc64
<gog>
any that are are most assuredly IBM
<terminalpusher>
hmm yeah I suppose it is a rather rare ISA anyway
<gog>
yeah ever since apple abandoned it it's dwindling
<terminalpusher>
Are there any notable systems still using BIOS?
<gog>
in a sense, UEFI systems with CSM are technically emulating BIOS
<gog>
for x86 and x86_64
<terminalpusher>
I mean, not the BIOS that is emulated by the UEFI
<terminalpusher>
in other words computers without UEFI support
<gog>
i think most vendors have moved on from old-style BIOS
<gog>
but it's possible
<terminalpusher>
hmm yeah I bet there are some companies etc. still running servers or something that old
<gog>
there might be a handful of suppliers for industrial applications that absolutely need a real PC-compatible BIOS in new hardware
<gog>
that's really the only possibility that comes to mind
<terminalpusher>
I see. So since most systems run on UEFI and support it nowadays, what would the reason be for using the old BIOS VESA/VBE framebuffer graphics stuff nowadays instead of the modern GOP of UEFI when making an OS and stuff?
<bslsk05>
github.com: serenity/GraphicsManagement.cpp at 3e7e503dee9f5e36d4d77c47edfb2af7b4f1ef67 · SerenityOS/serenity · GitHub
<terminalpusher>
it talks about VBE and stuff
<terminalpusher>
What would the reason for this be?
<terminalpusher>
And well generally I'm pretty sure SerenityOS boots using the BIOS
<terminalpusher>
It could of course be simple nostalgia for using the old stuff like BIOS and VBE
<terminalpusher>
any guesses?
<gog>
depending on the underlying hardware GOP is a wrapper around VBE which is why once boot services mode is exited you need a native driver for the card to change modes
<gog>
because VBE doesn't play nice with long mode
<gog>
also they mention multiboot here, which typically implies GRUB but GRUB can generate multiboot structures from BIOS or UEFI and also do graphics mode setting with GOP or VBE
<gog>
so they're entirely relying on the boot-time code to set graphics mode
<gog>
and it's agnostic of whether that's via GOP or VBE
freakazoid343 has joined #osdev
<terminalpusher>
ooh, that's interesting that GOP is actually a wrapper around VBE...
<gog>
i'm not 100% certain on that
<gog>
this is bizarre. i call ConOut->OutputString and it somehow slides into executing at 0xb0000
<gog>
and doesn't display the string
<gog>
the pointer seems to be at the right place
<terminalpusher>
that seems weird. Are you sure your string is UTF16LE?
freakazoid343 has quit [Ping timeout: 260 seconds]
<gog>
yeah -fshort-wchar is set
<terminalpusher>
but to access the VBE I would probably have to use some assembly and I've already got the GOP stuff working so it's probably better if I just use GOP right?
<gog>
yeah just use GOP
<gog>
it's the easiest way
<gog>
until you need modesetting
<gog>
then you'll need a native driver
<terminalpusher>
Hmm for the forseeable future I probably won't need modesetting outside of the UEFI
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
the_lanetly_052 has quit [Ping timeout: 240 seconds]
<terminalpusher>
https://i.imgur.com/lEW9lRt.png so today I got my GOP framebuffer working and now I can draw both console text and arbitrary pixels anywhere on the screen which is pretty cool. But I was wondering, is this always the case that the system can just print console text to the screen like that?
<terminalpusher>
because the ability to use the console doesn't go away after you exit the boot services etc. right?
<terminalpusher>
So for example could Linux if it wanted just print the console text "hello" right onto my screen and replace the pixels on it and appear in that VGA font white on black on my screen?
<gog>
no you can't use the UEFI text output service after boot services
<gog>
you
<gog>
'll need text rendering of your own
<gog>
you can force text output mode though
<gog>
i've never done it so i don't know the details
<terminalpusher>
Oh, because I saw this today in SerenityOS: https://youtu.be/VgjCUeQtbsE?t=2761 you can see the system running out of memory and then panicking like that and printing this console text right onto the screen
<bslsk05>
'OS hacking: Let's start improving the SerenityOS kernel heap allocator' by Andreas Kling (01:05:47)
<gog>
also now i'm getting a page fault at some bizarre address so there's something way wrong with my code lol
<terminalpusher>
Oh, so maybe it is forcing text output mode then in that video?
<gog>
idk how serenityos works unfortunately so idk
<terminalpusher>
well I looked a little bit at the code to find out and I will try to find it again
<bslsk05>
github.com: serenity/TextModeConsole.cpp at 3e7e503dee9f5e36d4d77c47edfb2af7b4f1ef67 · SerenityOS/serenity · GitHub
<gog>
i think this is a calling convention problem
<gog>
the header declares it EFIAPI but the compiler is generating mov's to rsi and rdi before the call
<gog>
that's sysv not msabi
freakazoid12345 has joined #osdev
<gog>
WOO fixed it
<gog>
i am a terrible programmer but i can make things work
<gog>
which means i am actually a good programmer
<jimbzy>
You just have to create the proper square peg to round hole adapter.
<gog>
nah just hammer that bitch in
<gog>
WONTFIX: WORKSFORME
<jimbzy>
You'd make a great blacksmith, gog.
<jimbzy>
That's known as "drifting a hole"
<gog>
lewd
freakazoid12345 has quit [Ping timeout: 252 seconds]
<gog>
i do have a friend in syracuse who's an apprentice blacksmith, maybe i can ask her about a change in careers
<jimbzy>
I wish I had learned about it when I was younger, but I am happy with the work I was able to accomplish.
<terminalpusher>
Is it true that UEFI runs in long mode on 64 bit and in protected mode on 32 bit CPUs?
sonny has joined #osdev
freakazoid343 has joined #osdev
<gog>
yes
<terminalpusher>
I see
<terminalpusher>
without needing to do anything, that's nice
<gog>
one of the main reasons i use it; no long-mode transition needed
<jimbzy>
I am reading about std::map. I think this will work for my keywords.
<gog>
are you gonna have STL in SOSIG kernel?
<jimbzy>
I'm working on a programming language now called 'pea'
<gog>
ahhh ok
<gog>
what does it look like?
<gog>
or is it something entirely different from anything in existence?
<jimbzy>
It's looking kinda c-like at the moment, or maybe like javascript?
<jimbzy>
I don't know yet, really. I'm exploring!
<gog>
what are your goals with it?
<gog>
that's fair
<jimbzy>
Figure out how interpreters and compilers work.
<gog>
a worthwhile endeavor imo
<jimbzy>
It's been on my TODO list since I first used qbasic back in the day.
<geist>
terminalpusher: also i think it wasn't pointed out before but BIOS is 100% a PC thing. ie, BIOS is intrinsically x86 centric
<geist>
so anything that isn't x86 by definition had some other kind of firmware
<terminalpusher>
ah, I see
<geist>
and i say 'BIOS' as the thing you make int 21, etc calls to, instead of a more generic term like 'a BIOS'
<terminalpusher>
geist: also, why is it that PC (personal computer) apparently refers exclusively to x86 computers? I've never understood that actually. A lot of computers can be personal computers.
<gog>
that's why i specified PC-compatible BIOS during the conversation :p
<geist>
but no one really uses the word BIOS to mean anything but 'the firmware as originally shipped on an IBM PC and then extended ad nauseum'
<geist>
gog: got it
<geist>
terminalpusher: well I say 'PC' in the sense of 'the IBM PC and its derivatives'
yomon has joined #osdev
<geist>
as in it was a marketing term that now means things that are compatible with it
<terminalpusher>
ahh ok
<geist>
yes, generically personal computer could refer to lots of other things, but it has a specific connotation
<geist>
like mac or amiga or something
<sonny>
There isn't interest in a new spec, except uefi stuff right?
Burgundy has quit [Ping timeout: 250 seconds]
<gog>
"the lineage of systems deriving from or compatible with the original IBM 5050 PC XT" :p
<gog>
5150*
<terminalpusher>
and I feel like PC for some people refers to Windows computers
<jimbzy>
gog, Dynamic typing, reference counting for managing memory, and some other crap.
<gog>
refcounting is based
<sonny>
osdev will sorta always be for ibm pc derivative, what is a modern PC is a question mark to me
<jimbzy>
I was reading about tracing, but I'm just not there yet.
<gog>
is the SOSIG userspace going to be implemented with pea?
<jimbzy>
Probably not.
<sonny>
dynamic typing D:
<jimbzy>
That reminds me that I still need to move sosig over to my new repository.
<gog>
sonny: but what about people doing osdev for MIPS or ARM
<gog>
they exist
<sonny>
I haven't a clue lol
<jimbzy>
You'll fit in great here, sonny.
<sonny>
how do they even boot?
<gog>
idfk i'm an x86 scrub
<jimbzy>
It's a burden being the only clueless person in the lot. ;)
<terminalpusher>
I've been wondering about that too
<sonny>
I know there is coreboot and stuff
<sonny>
jimbzy yeah we'll be like peas in a pod :-)
<gog>
or SOSIG in a casing
<jimbzy>
It's funny you said that, because I was thinking about calling my objects 'pods' XD
<gog>
:D
<gog>
do it
<gog>
do it do it
<sonny>
guess the short version is, a custom boot process
<sonny>
once you hand off to the OS, doesn't really matter
<jimbzy>
What do you expect from a person who created a minimal kernel with the sole purpose of drawing an ASCII version of a Gordon Ramsey meme?
<jimbzy>
There are billions of people who will never get the joke, but there are a couple hundred in this channel who will, so it was worth the effort. :)
<gog>
i think i'm reaching the limit of my ability to focus on work for the moment
<jimbzy>
Sorry! I am a distraction.
<gog>
it's not you, it's my brain and my stomach
<gog>
i had too much caffeine too and i'm starting to crash
<jimbzy>
Ah, yeah I feel you there.
<gog>
my wife makes really strong coffee and i had two cups
<jimbzy>
I'll probably have a couple of cups later. Went with the OJ this morning.
freakazoid343 has quit [Ping timeout: 260 seconds]
<gog>
ok i'm at the point where i can enter my kernel at its physical address
<gog>
well back at the point
Terlisimo has quit [Quit: Connection reset by beer]
<gog>
after this long meandering redesign
<gog>
this is the last time i'm doing that i swear (i'm lying)
Burgundy has joined #osdev
Terlisimo has joined #osdev
yomon has quit [Ping timeout: 240 seconds]
<geist>
sonny: oh sorry, wasn't paying attention
<sonny>
no worries
<geist>
re: booting on non x86s, the answer is there are simply different mechanisms
<geist>
*usually* better, sometimes much more ad-hoc
<geist>
however, UEFI is a new standard that is largely cross-architecture too
<geist>
there are specs for ARM and RISCv for example
<sonny>
non x86 doesn't seem to have a general spec? it's hardware specific?
<geist>
and some of those devices use UEFI
<sonny>
ah neat
<sonny>
(or not if you don't like UEFI)
<geist>
but, other than that the only real serious cross-arch spec that ever was used much was Openfirmware
<geist>
makes sense, because it's written in forth, so it's intrinsically largely portable
<sonny>
oh, that's cool
<geist>
sun workstations (sparc) and lots of PPC machines (newworld macs, etc) were openfirmware based
<sonny>
uefi is a lot more complex, but it's written. Is the complexity warranted?
<geist>
then over inthe ARM world there hasn't really been a standard until fairly recently with UEFI, but a pseuco standard is u-boot
yomon has joined #osdev
<geist>
pseudo
<sonny>
yeah I've heard of u-boot
<geist>
lots of arm dev boards and some cell phones use it
<geist>
though in the ARM world the notion of firmware and bootloader have a much more nuanced and complicated relationship
<geist>
but also that's because there hasn't been an old legacy standard holding everything back, so stuff has evolved over time
Burgundy has quit [Ping timeout: 256 seconds]
elastic_dog has quit [Ping timeout: 240 seconds]
<geist>
re: complexity of UEFI, well that's debatable. it's unclear how much UEFI will catch on in ARM world. will see. its in use in servers for sure, and i think it makes total sense there
<geist>
for consumer level hardware it does seem a bit overkill, since most consumer ARM hardware is only deesigned to boot exactly one thing and always boot that thing for its lifetime
<gog>
the standard itself is rather complex, but not every single protocol needs to be implemented
<gog>
there are really only a few key ones that are necessary to get booted
<gog>
from local storage anyhow
<sonny>
ohhhh
<geist>
yah and the UEFI spec for things that are non PC tend to be simpler. ACPI can be defined for non x86 too and it's usually much simpler there
<geist>
since there's less legacy nonsense to describe
<gog>
yes
elastic_dog has joined #osdev
elastic_dog has quit [Client Quit]
elastic_dog has joined #osdev
* gog
watches horrified as she breaks everything again, unable to stop herself
<gog>
why am i like this
terminalpusher has quit [Remote host closed the connection]
<j`ey>
gog: gotta break it to fix it
<gog>
good point
* geist
pets the gog
<geist>
knocking things off the table again?
ravan has quit [Remote host closed the connection]
<gog>
geist: trying to knock things on the (page) table actually :p
<gog>
but i've had a regression and am somehow sliding back into executing at 0xb0000
<gog>
not sure why yet :p
<gog>
might help if i actually set cr3 to the right address (d'oh)
freakazoid12345 has joined #osdev
freakazoid12345 has quit [Ping timeout: 245 seconds]
<friedy10>
Why don't embedded ARM devices come with buses that support enumeration?
<gog>
aha, taking the address of when you're not supposed to take the address of
<gog>
page tables build correctly and the kernel self-relocates correctly, gdt and idt are right, segment descriptors are right
<gog>
i am back in business :D
<gog>
it is now possible to do KASLR in both physical and virtual address
<geist>
friedy10: mostly because that adds a bunch of unnecessary complication
<geist>
ARM was pushing a long time ago for some sort of self identification in some device mmio apertures, but it never seemed to catch on
<geist>
but as a result some of the ARM designed peripherals (PL011, PL031?, etc) have a semi standard structure in the top of their mmio range to describe what they are
<geist>
but the particular solution that is en vogue nowadays is to simply describe the hardware in soem sort of external data structure, like device tree
<j`ey>
if its really embeded, everything is just at some magic fixed addresses that the manual tells you :P
<geist>
for fixed devices at least. for purely dynamic busses like PCI or USB or SDIO, there are already standard interfaces
<geist>
right, and/or You Just Know
Burgundy has joined #osdev
yomon has quit [Ping timeout: 252 seconds]
<geist>
and just knowing where everything is pretty fine for devices that are embedded, since it's totally standard practice to simply compile a binary to run on that device for that application. so statically configuring things is fine and produces tighter, smaller code anyway
Burgundy has quit [Ping timeout: 268 seconds]
<friedy10>
geist: Thanks for answering my question.
biblio has quit [Quit: Leaving]
<immibis>
nowadays people want to run linux on their random arm devices, and it would be convenient if it could configure itself based on what's actually installed
<geist>
yep, that's why linux uses device tree
<immibis>
i suppose a device tree provided by the bootloader serves that exact purpose
mctpyt has quit [Ping timeout: 240 seconds]
<sonny>
what was before device tree?
<geist>
right. and incidentially device tree came out of openfirmware (and/or was defined about the same time)
<immibis>
linux board files, I think. You'd just write a "driver" for your overall hardware platform
<geist>
right. and either you hard code that linux kernel to run on exactly that machine
<immibis>
(by "hard code" you mean set a configuration option so it compiles and links the right board file)
<geist>
or the bootloader passed via a register or arg to the kernel what board it was. there was a numeric table for it
<sonny>
ugh
<geist>
right. yah, configure the kernel and compile it for that
<geist>
device tree for the ARM linux platform was fairly late. i remember it starting to pick up steam around 2010 or so
<geist>
because the board file stuff was really getting out of hand
<geist>
note that device tree itself is a very old spec, came out of openfirmware (and/or was commonly associated with OF)
<sonny>
I see
sdfgsdfg has joined #osdev
<geist>
it's roughly equivalent to ACPI configuration tables, though its purely a description, doesn't have bytecode, etc
<geist>
so what's fun is on modern ARM server class machines you actually have both: UEFI + ACPI + device tree
<gog>
for small systemd devicetree makes more sense
<gog>
systems*
<geist>
it's a bit ambiguous exactly which one takes precedence. but from what i understand, in that situation ACPI and DT have the same data, and it's mostly based on whether or not you're running windows or everything else
<sonny>
gog like system on a chip stuff?
<geist>
since windows i think only consults ACPI and everyone else uses DT almost exclusively
<sonny>
interesting
<gog>
well that gets complicated because larger systems now incorporate SoC
<gog>
like Apple M1
<geist>
yah, soc is kinda a blurred concept now
<geist>
and folks will argue that modern desktop/laptop intel and amd cpus are socs too, etc
<gog>
yeah once the memory controller started moving to the CPU package
<gog>
then you're starting to look more like SoC
<geist>
generally when i think of a soc in non x86 world it's mostly dscribing the fact that there's a little universe of how things are wired up, what busses go where, what is mapped where, that can vary much more greatly on an ARM or riscv soc than a PC soc
<geist>
so you may say 'this is a qualcomm SOC' or 'this is a broadcomm SOC' and that tends to describe a particular design pattern that those companies use
<gog>
all of these distinctions are rather arbitrary anyway because what even is a "system"
<geist>
where stuff is located, what the basic peripheral set is, etc
<immibis>
there can be a bug in your device tree and that's an issue, unless you can update the bootloader. You can patch it in the kernel but then other people have problems running linux on your device
<friedy10>
For my research project I need to write a camera driver for an embedded device. There already exist a driver implemention for Video4Linux, but I need to get this to work in another kernel, which obviously doesn't support V4L2. How would I go about doing that?
<geist>
but... in the end if you want to boot a kernel on ARM that runs on multip[le platforms, it's not fundamentally that different from x86, except you have to be a bit more flexible in basic driver selection (interrupt controllers, serial ports, display, etc) that are kinda assumed to be fixed on a PC
<geist>
it's my experience that camera driver stacks are very complicated, but there's also a big difference between getting something basically working and having a really good and flexible solution
<gog>
there's linux driver source on this page, are you allowed to take that and chop it up and reassemble it to suit your purposes?
<friedy10>
gog: I was thinking about doing that, but I'm not sure how to get it working because I wouldn't have V4L2.
<friedy10>
gog: I'm guessing that's probably the best route.
<gog>
the V4L stuff would mostly be interface glue i think
<gog>
unless there's generic processing that it depends on
<gog>
but the most relevant stuff is the device registers and such, the rest is just figuring how to slurp the bits from the sensor
<gog>
much easier jumping-off point than from the docs alone
<geist>
are you allowed to because of licensing though?
dude12312414 has joined #osdev
sortie has quit [Quit: Leaving]
<friedy10>
geist: I have no idea.
<gog>
most of this file is an enormous regval_list array lol
<friedy10>
I'm also running this kernel with Linux on a hypervisor, so I was thinking I could just use message passing or something. Linux could capture the frames, and send them to my kernel.
freakazoid333 has joined #osdev
<j`ey>
you mean Linux is the host and your kernel is the guest?
<gog>
actual code starts at line 5218 after some more reval_list arrays
sortie has joined #osdev
<friedy10>
j'ey: It's a type 1 hypervisor.
<j`ey>
what's "it"?
<friedy10>
j'ey: I'm using the Hafnium hypervisor.
<j`ey>
ok so you meant Linux as a guest kernel too
<friedy10>
Yeah
<friedy10>
gog, geist, sonny, bslsk05: Thanks for the help.
<j`ey>
if you can message pass and you dont need "real time" camera, that sounds easier than writing a driver
<sonny>
np, but I barely helped lol
<j`ey>
sonny: and bslsk05 is a bot :P
<sonny>
haha
* gog
beeps
<gog>
i'm a catbot
<friedy10>
bslsk05: You are a good bot.
<sortie>
bslsk05 is to ensure this place is xkcd 380 compliant
<friedy10>
j`ey: Yeah, this kind of sucks because I need a real time camera.
<j`ey>
rewrite your kernel as a linux userspace application :P
skipwich has joined #osdev
<gog>
NO
freakazoid333 has quit [Ping timeout: 240 seconds]
freakazoid343 has joined #osdev
freakazoid343 has quit [Ping timeout: 245 seconds]
freakazoid12345 has joined #osdev
sdfgsdfg has quit [Quit: ZzzZ]
freakazoid12345 has quit [Ping timeout: 250 seconds]
GeDaMo has quit [Remote host closed the connection]
mctpyt has joined #osdev
sdfgsdfg has joined #osdev
epony has quit [Ping timeout: 240 seconds]
epony has joined #osdev
Oli has joined #osdev
sonny has quit [Quit: Client closed]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]