sdfgsdfg has quit [Quit: ayo yoyo ayo yoyo hololo, hololo.]
sdfgsdfg has joined #osdev
sdfgsdfg has quit [Ping timeout: 240 seconds]
gorgonical has joined #osdev
gorgonical has quit [Read error: Connection reset by peer]
gorgonical has joined #osdev
gorgonical has quit [Read error: Connection reset by peer]
gorgonical has joined #osdev
gog has quit [Quit: byee]
zeroc00l0 has joined #osdev
[itchyjunk] has joined #osdev
zeroc00l0 has left #osdev [#osdev]
dequbed has quit [Remote host closed the connection]
dequbed has joined #osdev
dude12312414 has joined #osdev
gorgonical has quit [Ping timeout: 256 seconds]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
pretty_dumm_guy has quit [Quit: WeeChat 3.4]
gorgonical has joined #osdev
Clockface has joined #osdev
<Clockface>
i saw something in the wiki about running the BIOS code with an interpreter, is there anywhere that describes this in more detail if it is correct?
<bslsk05>
github.com: linux/vm86_32.c at master · torvalds/linux · GitHub
<klange>
"386+" yes but it's completely dropped once you hit long mode and it's an absolute nightmare when you _do_ have it
<klange>
and all of this is useless if you're on an EFI system
<klys>
wonder if there's a way to run seabios on a pentium motherboard from dos
<klys>
just to correct the cmos disk geometry
<klys>
my piix4 socket 7 board has a "security feature" where it has to reboot in order to adjust the cmos disk type. int 0x19 doesn't work that way, I guess. I would like to bypass this feature with some hacking.
<moon-child>
x comes with an x86 implementation?
<moon-child>
xorg*
<moon-child>
why am I not surprised...
<klange>
It's realmode-only, and it's bundled.
sdfgsdfg has joined #osdev
<klys>
well the disk parameters are stored in a "rom bios" table in upper memory. they are modified at boot time, which is the only time they can be modified.
troseman has quit [Ping timeout: 250 seconds]
<Clockface>
i was mostly interested in doing it by software, since v86 mode doesnt work in long mode
<zid>
I mean it's just a brain dead x86 emulator and you map the bios area into it
<klange>
Frankly, there's very little reason to go through the trouble of setting something up so you can do this stuff at runtime.
<zid>
and you just wait for it to do all its little out dx, al stuff for you
<klange>
We're not using CRTs that properly accepted multiple modes anymore, and none of these BIOS-driven interfaces are going to get you external monitors.
<zid>
I'd only do it if you wanted basic mode changing support on hw with no drivers
<zid>
which just sorta isn't how hw works these days? nobody *uses* the vga adapter
<klange>
There's no reason to be switching display resolutions under these restrictions, so just let someone above you do it once (feel free to write that bit yourself, though, it's kinda fun!) and be done with it.
<zid>
if they have one it's a 2MB matrox framebuffer thing on their mobo, or they have a 1050 ti
<zid>
(the former that they don't use)
<Clockface>
i know for a real project i should write drivers, but "long mode BIOS" sounds like a cool thing on its own
<zid>
if all you're doing is drawing something silly in 320x200 then go for it
<zid>
if you can just do text/serial until you have drivers, I'd ignore it
<klange>
My BIOS loader runs in protected mode, but will switch back to real mode to do display switches from a menu. It was a fun bit of trampoline code to write so I could do it from C and align functionality with my EFI loader that does it through GOP.
<Clockface>
i guess running BIOS in that way could make for one hell of a DOS extender, lel
<Clockface>
screw that, at that point you run DOS itself as well
<Clockface>
a long mode DOS extender sounds like fun
<Clockface>
random question: what does everyone think of the motorolla instruction set stuff?
<zid>
eh?
<zid>
is there a thing going round?
<Clockface>
its just an instruction set a lot of microcontrollers still use
<zid>
you mean.. motorolla chips
<kazinsal>
there are a lot of motorola ISAs
<zid>
I think it is what it is
<zid>
it has opcodes and operands and stuff, and compilers spit it out when you set your arch to it
<Clockface>
some manufacturers make motorolla compatible chips for embedded stuff
<zid>
drop in replacements so nobody has to re-write anything legacy
<Clockface>
well some people seem to prefer writing motorolla assembly to x86
<zid>
yea almost certainly
<zid>
I prefer gbz80
<Clockface>
the cool thing about embedded is that you can do literally whatever you want
<klange>
ugh I'm trying to run qemu over ssh with -X/-Y and it just... isn't showing anything... and I am going to laugh my ass off if I switch monitors back to the host and it's still spitting out a window to the local wayland...
<klange>
yep
sdfgsdfg has quit [Quit: ayo yoyo ayo yoyo hololo, hololo.]
<Griwes>
me: implements a generic avl tree with only a little of hair pulling and just a few pages of "paper" written over with unreadable scribbles of tree structures and the necessary transformations
<Griwes>
also me: forgets to pass "flags::user" to a call to map usermode's process' stack
<Griwes>
and spends 5 minutes staring at the screen before figuring it out
<Griwes>
human brains are just a *mess*
<Clockface>
only 5 minutes?
<Clockface>
you are lucky!
<Griwes>
I eventually noticed the conspicuously missing 'u' in `info mem`
<Griwes>
the funnier thing that I've done - but at least this one I noticed immediately after actually switching address spaces - was that I forgot to pass in an address space argument to my lowest level "map memory" functions, I should probably just make them always take a VAS argument
<Griwes>
alright, we're back to userspace, this time with things set up in a way that's closer to how I eventually want them
<Griwes>
next step is syscalls and a framework for capabilities
srjek has quit [Ping timeout: 240 seconds]
<geist>
yah good work!
<Griwes>
we'll see how successful I am with it, but I'm trying an approach of having three layers of abstraction to kernel objects, namely objects themselves, handles, and tokens
<Griwes>
where tokens end up being semi-random integers that serve as keys into per-process handle tables
<geist>
oh weird. had a gap, was responding to something hours ago
<zid>
rekt Griwes
<Griwes>
what I wrote was mostly detached from that comment ;p
<Griwes>
but it was in fact targeted primarily at geist :P
<zid>
"Wow you're so pretty" "Oh not you, I was looking at the person behind you" "gee thanks"
<geist>
haha good job too
<geist>
well the problem was it wasn't showing new comments, at the time i typed it it was hours ago
<Griwes>
(by semi-random I mean it's a xor of pointer values and a timer timestamp, sooooooo)
<Griwes>
(but all the syscall entrypoints are only look for handles designated by tokens in the current process' tables, so hopefully that's reasonably fine)
<geist>
or you could go farther and do something like handles are 128 bit values, passed through a vector
<geist>
and are a hash to a thing
<geist>
or tokens in this case
<Griwes>
hmm, actually, I should probably do something smarter there, because xoring two kernel space pointers is going to make some of the bits essentially always be 0
<Griwes>
I'll deal with this another day tho
<Griwes>
it's such a buried implementation detail that it shouldn't matter
<geist>
yah we do a cheezy thing in zircon by just xoring the handles with a per process seed
<Griwes>
(until it does)
<zid>
Multiply by 0x12345 like The Best RNG(tm)
<geist>
not cryptographically meaningful, but it means handles dont just increment or whatnot
<geist>
so user space cant easily predict the next handle
<Griwes>
yeah, tho the most random source of bits i have right now is the timestamp of the main timer, lol
<Griwes>
and it depends on the address of the handle object itself, so shouldn't really be guessable
<Griwes>
also I figured out how to deal with the initial userspace init's logging needs
<Griwes>
I'll just... give it a write-only mailbox lol
<Griwes>
and let it write pointers into it
<Griwes>
I think I'm beginning to think in microkernels ;>
<geist>
hah yeah, it's kinda intoxicating
<Griwes>
(oh, and of course I will give it that mailbox by putting a token of it into the read-only mailbox that I'm already giving it to pass it other objects)
bauen1 has quit [Ping timeout: 240 seconds]
the_lanetly_052 has joined #osdev
ElectronApps has quit [Remote host closed the connection]
kingoffrance has quit [Ping timeout: 240 seconds]
zaquest has quit [Remote host closed the connection]
zaquest has joined #osdev
bauen1 has joined #osdev
g1n_ has joined #osdev
<g1n_>
hello
<g1n_>
idk why, but i have done isr working, but it works only if i don't use -O2 flag or use -O0
<g1n_>
works with -g
<zid>
sounds like UB
<Mutabah>
Probably not saving the right registers
<Mutabah>
OR, your stack is unaligned
ElectronApps has joined #osdev
<g1n_>
oh
<g1n_>
hmm
<zid>
You broke the promises you made to your program by invalidating the C execution environment, rip :(
<g1n_>
zid: wdym?
<zid>
C programs don't appreciate the registers randomly changing values etc behind its back
<klange>
the same things the other folks said, but phrased differently
kingoffrance has joined #osdev
<g1n_>
oh ok
the_lanetly_052 has quit [Ping timeout: 240 seconds]
sdfgsdfg has joined #osdev
<moon-child>
g1n_: redzone
<moon-child>
probably
<g1n_>
moon-child: what is it?
<zid>
are you 64bit and compiling without -mno-redzone?
<moon-child>
g1n_: compile with -mno-red-zone
<zid>
if not, nothing
<g1n_>
i am doing it for x86
<zid>
you don't have a redzone then
<g1n_>
hmmm, ok
<g1n_>
when i am using gdb (with -g) exception is also not get handled
<g1n_>
but if not using gdb, exception is handled
<zid>
well if you've broken interrupts
<zid>
I wouldn't expect interrupts to work
ert has joined #osdev
<g1n_>
zid: hmmm, but without optimizing flags it is working
<zid>
yea you said that part
<zid>
it's the exact same symptom
<zid>
exceptions are interrupts, you said it breaks your interrupts, ergo ofc it breaks your exceptions
<g1n_>
yes
<g1n_>
so, what should i do with registers?
<g1n_>
oh
<klange>
bochs and qemu both have good support for debugging interrupt handling (though stick to software emulation in qemu, KVM and other accelerators will prevent qemu from observing interrupts)
<g1n_>
maybe that i am using pushad in isr_wrapper it is not good?
<zid>
you should load every register with 0x55555555, sit in a while(1); loop, take an interrupt, then ask qemu what's in your registers, to see which one your ISR corrupted, or use a debugger. Or look at your code.
<zid>
a gajillion things you can try
<g1n_>
ok
<CompanionCube>
today on 'pointless ideas scrollback has given me': an x86 bios that somehow leverages AMD SVM's 'paged real mode'
<g1n_>
zid: oh, seems esp, ebp and edi are broken
<klange>
those are important
<zid>
Those are very important :P
<g1n_>
lol
* moon-child
breaks esp's kneecaps
<zid>
kneecaps are considered dangerous afterall
<g1n_>
but, i had put break point on my func that fills registers
<g1n_>
and it gives me that result
<kingoffrance>
not sure if related, but i recall that: https://www.x.org/archive/X11R7.5/doc/man/man5/xorg.conf.5.html Disables the Int10 module, a module that uses the int10 call to the BIOS of the graphics card to initialize it. Default: false. Use the Int10 module to initialize the primary graphics card. Normally, only secondary cards are soft-booted using the Int10 module, as the primary card has already been initialized by the BIOS at boot time. De
<klange>
it's on the stack in the interrupt context
<Mutabah>
with 32-bit x86, SS/SP are pushed on transitions from user to kernel space
<klange>
it's popped by iret
<Mutabah>
with 64-bit they're always pushed on interrupt
<kingoffrance>
update: yes, xorg/xfree86 int10 stuff used/uses x86emu, at least optionally, so that is one place it was/is needed
<klange>
kingoffrance: you are several hours behind
<klange>
just want to make sure you're not scrolled up mistakenly
<kingoffrance>
sorry, i didnt say anything but CompanionCube revived it
<kingoffrance>
it had/has a point, that's all
<klange>
its point was actually the thing that led to its mention
<klange>
so we're full circle
<kingoffrance>
i see no mention of multihead
<g1n_>
i hadn't fixed that issue, but isr handler works (i mean it prints interrupt number)
<klange>
kingoffrance: notably that's just for startup, but the x86emu interface would also be used to change display resolutions if you were using the fallback `vesa` driver
<klange>
Definitely have some experience with it from configuring boxes with nvidia cards back when Grub wouldn't even bother with graphics modes and you'd get something "safe" when you hit X like 640x480...
<klange>
But then kernel mode setting happened, and nouveau... and also somewhere DKMS stopped being terrible for installing the proprietary drivers...
[itchyjunk] has quit [Remote host closed the connection]
bas1l has joined #osdev
<klange>
And teh vbe support was actually in a separate directory from the int10 interface until, apparently, 2019?
<klange>
that's a surprisingly recent change to that code
<klange>
apparently you could build with int10 without vbe and I... don't know what that gets you.
jstoker has quit [Remote host closed the connection]
froggey has quit [Remote host closed the connection]
terrorjack5 has joined #osdev
tenshi has quit [Ping timeout: 268 seconds]
gruetzkopf has quit [Ping timeout: 268 seconds]
ids1024_ has quit [Ping timeout: 268 seconds]
manawyrm has quit [Ping timeout: 268 seconds]
jstoker has joined #osdev
aejsmith has quit [Ping timeout: 240 seconds]
froggey has joined #osdev
terrorjack has quit [Ping timeout: 268 seconds]
basil has quit [Ping timeout: 268 seconds]
bslsk05 has quit [Ping timeout: 268 seconds]
hbag has quit [Ping timeout: 268 seconds]
terrorjack5 is now known as terrorjack
gruetzkopf has joined #osdev
tenshi has joined #osdev
froggey has quit [Read error: Connection reset by peer]
froggey has joined #osdev
manawyrm has joined #osdev
GeDaMo has joined #osdev
ids1024_ has joined #osdev
fwg has joined #osdev
nick64 has joined #osdev
aejsmith has joined #osdev
cln has quit [Ping timeout: 252 seconds]
MiningMarsh has quit [Ping timeout: 260 seconds]
MiningMarsh has joined #osdev
cln has joined #osdev
kazinsal has quit [Ping timeout: 250 seconds]
kazinsal has joined #osdev
pretty_dumm_guy has joined #osdev
<geist>
g1n_: good re: isr handler. the problem probably is that the isr handler is not properly saving and restoring registers from what it interrupted
<geist>
so in that case the isr handler probably works fine, but it subtly corrupts what it interrupted
<geist>
and then it's pretty random what sort of corruption you'll get, and things like -O settings andwhatnot for your compiler will move things around enough such that it may appear more often or not
<geist>
also it may be that you have multiple problems, so you have to methodically solve them one at a time. sounds like that's what you're doing, excellent
qubasa has quit [Ping timeout: 240 seconds]
dormito has quit [Quit: WeeChat 3.3]
<klange>
fixed up clone(), got my magic thread exit wired up, no more userspace hacks in my working directory except for the DE startup script; still no actual interrupts, but i have been working all day
<klange>
working on work-related things, I should clarify
<sortie>
Magic thread exit?
the_lanetly_052 has joined #osdev
<GeDaMo>
Band name? :P
dennis95 has joined #osdev
<zid>
`magic thread` is my spider-themed final attack in my boss form
<GeDaMo>
"Is this stuff coming outta you?" :|
dormito has joined #osdev
dormito10 has joined #osdev
dormito has quit [Ping timeout: 256 seconds]
dormito has joined #osdev
dormito10 has quit [Ping timeout: 256 seconds]
gog has joined #osdev
<klange>
sortie: it's the dumbest thing, and I shouldn't even need it since I switched my libc pthread implementation to always start threads in a wrapper function, but I inject a very specific return address into the call frame when starting a new userspace thread
<klange>
it's also how I do signal entry
<klange>
so when it returns you get an identifiable fault and treat it like a graceful exit / return from signal handler / whatever
<klange>
okay, bit more fun with instruction caches and I have page freeing, which I had skipped, working nicely on the kvm setup
<klange>
(dynamically linked stuff was producing a mysterious fault)
<klange>
(and apparently I'm missing an EL0 permission bit somewhere because the two instructions for correcting this are supposed to be userspace accessible and gcc has a builtin for them?)
bauen1 has quit [Ping timeout: 260 seconds]
<sortie>
Ah gotcha I see
bauen1 has joined #osdev
<sortie>
My thread creation system call lets you specify the state of every single register and other thread meta data (such as blocked signals) so it atomically creates a thread with the given state, and I use that to directly invoke the thread entry point with the right stack, set up to return to pthread_exit
<sortie>
For signals, the kernel has a page mapped somewhere readable by user-space, and it sets up the signal handler stack to return to that trampoline, which invokes the sigreturn system call
<klange>
This is kinda just one of those holdovers from the old kernel that I kept for no reason other than it was working.
<sortie>
Yeah totally, takes years to clean up all such details in the background
<klange>
my rpi only has a 16GB SD card which is not really enough to hold the insanity that is a binutils+gcc toolchain with sources from git... and it's not exactly fast anyway, so
<klange>
my dev environment is to build on my (x86) desktop and then scp kernel+ramdisk to the rpi
<sortie>
16 GB seems enough for that, at least if the git history isn't involved?
<klange>
honestly the real problem is that I decided to use Ubuntu on it and, well, 16GiB disappears quickly
<sortie>
I hear ya. I am always running out of disk space
dormito10 has joined #osdev
dormito has quit [Ping timeout: 268 seconds]
bauen1 has quit [Ping timeout: 268 seconds]
bauen1 has joined #osdev
<klange>
I guess I should teach this to find out how much memory it has...
heat has joined #osdev
bauen1 has quit [Ping timeout: 256 seconds]
<heat>
does libfdt do any dynamic memory allocation?
<klange>
I neither know nor care to check as of course I'm not using it.
<klange>
In my current environment, things are fairly straightforward to parse. They'll get more complicated when I have to read something for a real machine and read the cell size stuff beyond hardcoding things...
<heat>
how are you not using it?
<heat>
did you roll your own?
<klange>
The format of a device tree is incredibly straightforward? It's the encoded data that is bit trickier, but for the stuff I've needed it's "search for this string in a structured tree and you're basically done".
<heat>
ah, i've never looked at the format
<klange>
It's basically a bunch of big endian 32-bit ints with the occasional nil-padded string thrown in
<klange>
okay, there we go, at least for the virt machine that has a single range of RAM... and uses this specific cell size... that should be good to go
<klange>
Correctly marking my used memory, reserving only what I need for the kernel and ramdisk, and freeing things up on task exit, we are down to 93MB in use, and a properly reported 3072 MB total available on a VM where that is what I gave.
nyah has joined #osdev
bauen1 has joined #osdev
zaquest has quit [Remote host closed the connection]
ElectronApps has quit [Remote host closed the connection]
bslsk05 has joined #osdev
sahibatko has quit [Quit: leaving]
sahibatko has joined #osdev
heat has quit [Remote host closed the connection]
dude12312414 has joined #osdev
sdfgsdfg has quit [Quit: ayo yoyo ayo yoyo hololo, hololo.]
dequbed has quit [Remote host closed the connection]
dequbed has joined #osdev
[itchyjunk] has joined #osdev
vdamewood has joined #osdev
<vdamewood>
Slurp slurp, everyone!
<gog>
hi hi
* vdamewood
pulls out a fishy
* vdamewood
gives gog the fishy
* gog
chomps the fishy
<gog>
i had cheese on toast today tho, no bagels :(
<gog>
or lox
<vdamewood>
Cheese on toast is yummy, too.
<vdamewood>
But isn't bagel and lox.
<gog>
doesn't slap the same
<gog>
still slaps
<vdamewood>
Now I want a bagel and cream cheese.
<gog>
:D
dequbed has quit [Quit: bye!]
bxh7 has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
srjek has joined #osdev
troseman has joined #osdev
dude12312414 has joined #osdev
g1n_ is now known as g1n
hbag has joined #osdev
gwizon has joined #osdev
orthoplex64 has joined #osdev
crm has quit [Ping timeout: 268 seconds]
gwizon has quit [Client Quit]
gwizon has joined #osdev
Celelibi has quit [Ping timeout: 250 seconds]
Celelibi has joined #osdev
gwizon has quit [Ping timeout: 256 seconds]
the_lanetly_052 has quit [Ping timeout: 256 seconds]
<bslsk05>
github.com: lk/fdtwalk.c at master · littlekernel/lk · GitHub
<geist>
it's a weird quirk of device trees as far as i can tell
<geist>
the size/address nodes may not be present first at any given level, but they modify everyting at that level (and everything underneath it, unless overridden)
<geist>
that's why i had to keep a size/address stack as it walks the tree
<heat>
yeah I got that part
<geist>
i'm about 90% sure i'm interpreting that properly. so to bootstrap the process it reads it once at the root before iterating through things at the root level
<geist>
it may be extraneous though, and the read inside the loop may also be guaranteed to fire once at level 0
<heat>
yes but wouldn't you get node offset = 0 through fdt_next_node anyway?
<geist>
probalby, yes
<heat>
also any reason why you don't use fdt_address_cells() and fdt_size_cells()?
<geist>
probably just didn' tknow it existed. does it do the same thing as the routine i made?
<heat>
reads the address and size so yeah
<geist>
you give it an offset and it finds the local version of the node or stops within that level?
<geist>
or does it read up the tree and recursively compute it?
<geist>
if the latter, that would be nice (thoug a bit ore expensive)
<geist>
since it'd just completely remove the need for that stack nonsense
<heat>
just uses getprop unfortunately
<heat>
but it's a nice wrapper
<geist>
ah
<geist>
that could be another, more expensive solution to needing to keep that stack
<geist>
write two routines that just starts over from the root and walks down to the offset you give it, accumulating size/address
dequbed has joined #osdev
<geist>
would probably want to keep a stack of nodes you visited, i guess
<geist>
but thats more logically simpler than the other oe
<geist>
or of course could write the walker recursively, which is clearly the way its designed to be implemented
<geist>
i just get nervous about writing recursive functions in limited memory environments, so i usually end up flattening them to a loop like this out of habit
<heat>
yeah I like your solution
<heat>
it's relatively elegant
<geist>
yah it wors well enough
<geist>
now, whether or not you want to do the callback style stuff i have there is up to you. that's a bit unweildy but works so far
<geist>
it's clearly only sufficient for parsing a fixed number of types of nodes for specific uses
<geist>
vs some sort of more generic visitor pattern i guess
<heat>
also do you need to look at the memory reservations of the device tree?
<geist>
probably. iirc there arent any on qemu virt so it hasn't really come up
<geist>
on real hardware i think that's a real thing to worry about
<heat>
don't the rest of lk's platforms use device tree?
<geist>
generally no
<geist>
i only really added it for qemu because you need it to at least find the memory size and cpu count
<heat>
static platform devices?
<geist>
yes
<geist>
LK generally is used in an embedded construct or doesn't have a device tree available (ARM bootloaders are a big use case)
<geist>
so it doesn't overtly depend on it necessarily
<geist>
embedded style things usually are perfectly fine being statically allocated
<geist>
it's really up to the platform, which is why the per-platform code drives the FDT logic
<heat>
yeah
<geist>
but if you look at zircon you'll see there are remnants of the platform logic left. basically there's a platform/pc and platform/arm-generic ad nothing else
<heat>
question: can't you have multiple nodes per depth?
<geist>
the arm-generic platform in zirco is essentially the 'make a single platform that uses FDT/etc to drive the logic' and then we trimmed it
<geist>
trimmed all the hard coded ones so that it's the only arm platform left
<geist>
could do the same thing in L
<geist>
LK. sorry fingers aren't typing that good this morning
<heat>
:D
<geist>
what do you mean multiple nodes per depth?
<heat>
can't you have like "node1" and "node2" @ depth 1 for example
<geist>
sure
<geist>
the fdt logic i think just walks all the nodes in linear order
<heat>
oh wait forget it
<geist>
so it reads the depth as it goes
<heat>
i get it
<heat>
you keep set the current depth's stack again every time you visit a node
<heat>
setting*
<heat>
because that's per node not per depth
<geist>
i forget how depth is encoded in the fdt, but fairly certain the nodes are jsut packed in order. the depth may be part of the encoding of the node i guess
<geist>
ah yeah fdt_next_node returns the current depth
<geist>
i guess the hazard there would be if it somehow returned something that was more than 2 depths deeper than the previous: it would end up copying bogus address/size data from the parent depth
<geist>
but that's probably an illegal encoding
<geist>
but since the FDT library keeps no state between calls, the depth must be easy to compute per node. probably each node just encodes everything it needs to be self contained, and the next node is always after the previous one, so you can set your cursor anywhere in the FDT and parse
<geist>
it's fairly well designed, IMO
<heat>
you have a bug I think
<geist>
i always hate it when people design these sort of data structures are usually cheese out and skip making them self contained
<heat>
the spec says the default address-cells is 2
<bslsk05>
www.spinics.net: Re: [PATCH] libfdt: fdt_address_cells() and fdt_size_cells() — Linux Device Tree Compiler
<geist>
definitely makes more sense if the nodes were just always there
<geist>
hmm is there a fdt_prev_node?
<geist>
if so could faily easily (though O(N^2)) build a routine that walks backwards up the tree and does the recursive size/address thing
<heat>
no
<geist>
which from the wording in that message. okay
<geist>
guess that wuld be hard because you wouldn't kow where the prvious one started
<geist>
also interesting in that patch the submitter is trying to only set the deafult size to 2 if sparc, otherwise 1
<geist>
but then it's shot down so i dunno
<geist>
in practice i bet pretty much all FDTs have at least a size/address in the root, so it's only if that doesn't happen
<geist>
as a side note isnt there a third # property like this? I thought i saw it once but just dont use it
<heat>
i don't think so
<geist>
i forgot why you were lookig into this. getting the riscv-virt machine working right?
<heat>
yes
<geist>
cool. did you know about the dumpdtb switch? klange mentioned it a few days ago
<heat>
no, what's that? qemu switch?
<geist>
it's helpful for this since you can get a copy to disassemble to check against
<geist>
yah, machine=virt,dumpdtb=file.dtb
<geist>
it wont run the machine, but it'll start it up, compute the dtb as it normally would, dump it to the file and stop
<geist>
then you can disassemble it via the `dtc` command and get a source version of it
<geist>
i keep a copy of a bunch of these around to check against
<geist>
i basically just wrote the fdtwalker stuff to parse what i already had in front of me, so it's a pretty directed solution
<heat>
how useful is that though?
<geist>
what part of that?
<heat>
i'm not writing my own fdt parser
<heat>
dumpdtb
<geist>
okay. then what are you doing with FDT?
<heat>
well, i'm parsing the device tree, libfdt deals with the format
<geist>
well sure. that's parsing
<heat>
i don't think there's much to screw up
<geist>
structure parsing
<geist>
okay. suit yourself. i found it incredibly useful
xenos1984 has quit [Read error: Connection reset by peer]
<heat>
my plan is to get the memory allocation working (possibly cpus but at the time this runs it's too early) and publish every other node to a device_tree_bus
<geist>
sure. seems that having a text version of it that you can at least eyeball and make sure you 'interpreted' it precisely would be useful, no?
<heat>
possibly yeah
<geist>
that's all i mean with the dumpdtb stuff. useful to make sure you're not off in the weeds
<heat>
not a thing for riscv64
<geist>
and yeah when i get around it i'll probably restructure the fdtwalker library to be more of a visitor style thin
<geist>
and then have a series of helper routines that look for specific stuff
<heat>
qemu-system-riscv64 -machine virt,dumbdtb=virt.dtb -----> qemu-system-riscv64: Property 'virt-machine.dumbdtb' not found
<geist>
fdt_walker_find_all_cpus(cpucallback) etc. may be more expensive because it'd make multiple passes
<geist>
but the current scheme of passing in a bunch of callbacks is getting unweildy
<geist>
dumpdtb
<heat>
hahahaha oopsie
<geist>
i mean it is kinda dumb
<heat>
yeah you were right, it is useful :)
fwg has quit [Ping timeout: 240 seconds]
fwg has joined #osdev
xenos1984 has joined #osdev
srjek has quit [Ping timeout: 240 seconds]
<heat>
geist, is the fdt required to be in physical memory?
<heat>
ok turns out the root node doesn't appear when traversing
<geist>
yah
<geist>
well depends on which side of that sentence you're asking. required to be somewhere, or required to be in physical
<geist>
required to be somewhere, depends on the bootloader/machine/etc
<geist>
it's implementation defined how to find it
<geist>
but. if you're searching for it on qemu-virt-riscv there are some caveats. what are you doing?
<geist>
same as virt-arm machine. depending on where you tell it to load your kernel ou might not find it since it can only place the fdt if your kernel is out of the way
<geist>
it just silently omits it
<geist>
also looks like on riscv it's passed in via a reg: const void *fdt = (void *)lk_boot_args[1];
<geist>
probably a1
<geist>
iirc a0 has the hart id in it
sdfgsdfg has joined #osdev
<heat>
i just wanna make sure the fdt is inside the big kernel mapping
<heat>
i already have it
<heat>
my page allocation code is struggling with this foreign concept called "ram doesn't start at 0"
epony has quit [Quit: QUIT]
gwizon has quit [Ping timeout: 268 seconds]
<heat>
ah my boot page allocator is too bad for virt
<heat>
it only allocates at the start or end of a memory region and doesn't do splitting
<heat>
issue: my kernel is at the start and the fdt is at the end
<heat>
causing it to fail to allocate memory for the actual page allocator
Lugar has joined #osdev
mahmutov_ has quit [Ping timeout: 268 seconds]
dormito10 has quit [Quit: WeeChat 3.3]
heat has quit [Ping timeout: 250 seconds]
GeDaMo has quit [Remote host closed the connection]
<geist>
and yeah the 'memory doesn't start at 0' thing definitely can foul things up
<klange>
I just YOLO'd it and wasted a few KB in my page bitmap
<zid>
and I was given side-eye for allocating off the end of my kernel load address, now who's the fool! :p
srjek has joined #osdev
ensyde has joined #osdev
fwg has quit [Quit: .oO( zzZzZzz ...]
dormito has joined #osdev
fwg has joined #osdev
ensyde has quit [Quit: Leaving]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]