<bslsk05>
www.tomshardware.com: Intel Kills Optane Memory Business Entirely, Pays $559 Million to Exit | Tom's Hardware
<zid>
I hope someone has bought the tech but doesn't wanna announce yet..
<GeDaMo>
"Micron was the sole high-volume fabricator of 3D XPoint, the memory Intel uses to make Optane, and the company later sold its 3D XPoint fab to Texas Instruments, leaving Intel with no production facilities of its own."
vai has quit [Read error: Connection reset by peer]
ghee has quit [Quit: EOF]
<immibis>
Would it be appropriate to create a Pinephone page on the wiki, like the Raspberry Pi has?
<heat>
sure
<immibis>
Last year I got it to run a blink program over USB but stopped there
DoubleJ has joined #osdev
[itchyjunk] has joined #osdev
terminalpusher has joined #osdev
srjek has joined #osdev
lleo has joined #osdev
lleo has left #osdev [#osdev]
the_lanetly_052_ has quit [Ping timeout: 240 seconds]
socksonme_ has quit [Ping timeout: 268 seconds]
gmacd has joined #osdev
<gmacd>
I'm looking to get physical memory map for raspberry pi (on qemu atm) - should I be using devicetree for this? In particular the reserved memory map
<clever>
gmacd: `info mtree` in the qemu monitor console tells you the exact memory layout that is being emulated
<clever>
what exactly are you looking for?
<gmacd>
I'm trying to get the physical memory map for raspi. I came across ATAGs, then read that device trees are the more recent way to find that kind of info.
<clever>
device-tree tells you the address of every single peripheral, where ram is, and what is reserved ram
<clever>
but ive also got things memorized
<clever>
and its also in the official docs
<gmacd>
I'm trying to poke around the device tree that I specified in qemu (downloaded from the raspi github) but the reserverd memory map seems to be empty, so I'm wondering if I'm looking in the wrong place, or I've screwed up
<clever>
the firmware populates the reserved map during boot
<clever>
qemu may not populate it with the same data, or at all
<clever>
you can also just read the device tree source files from linux, or decode the .dtb with dtc
<clever>
when i ask dtc to decode the file, i see this
<clever>
which covers just the spin-tables and armstub
poyking16 has joined #osdev
<gmacd>
ok, so I see that when I decode the dtb. Does the /memreserve/ line simply state address and size (like the structure)?
<clever>
i believe so
terminalpusher has quit [Remote host closed the connection]
<clever>
gmacd: for the pi3, you have 1gig of ram, which starts at 0, but there are a few special holes, the top 16mb (1008mb to 1024mb, starting at 0x3f000000) is peripheral memory (MMIO), gpu_mem= from config.txt sets how much of the top memory is used by the gpu firmware, the device-tree is auto-patched to not report gpu_mem to the arm
<clever>
and the lower 0x1000 you see in the reserved, is just the spintables and armstub, which are required to safely turn on the other 3 cores
<clever>
assuming gpu_mem=16, then i think you can use the entire 1008mb of ram, from 0 to 1008mb-1
<gmacd>
so what I'm looking for is how to derive the physical memory map, which I can then use for a physical page allocator.
<clever>
you want to look at the /memory node in device-tree
<bslsk05>
github.com: lk-overlay/platform.c at master · librerpi/lk-overlay · GitHub
<clever>
gmacd: and the reverse, parsing it to setup the allocator
<clever>
in this case, the code isnt parsing it fully
<clever>
line 190 assumes the ram starts at some position, and 474 assumes the 1st entry in /memory/reg has the length for it, and there is no 2nd entry
<gmacd>
thanks for all this. i'm going to dig in and see if i'm looking in the right place - i suspect not
<heat>
yes, use /memory nodes
<heat>
reserved may not be there at all
<heat>
at least I've certainly not seen it in qemu platforms
<clever>
gmacd: you also need to pay attention to #address-cells and #size-cells
<clever>
#address-cells says how many 32bit ints long an address is, and #size-cells says how big a size is
<clever>
/memory/reg is then made up of addr+size pairs
poyking16 has quit [Ping timeout: 268 seconds]
socksonme_ has joined #osdev
saltd has joined #osdev
poyking16 has joined #osdev
gmacd has quit [Ping timeout: 244 seconds]
zhiayang has quit [Quit: oof.]
zhiayang has joined #osdev
zhiayang has quit [Quit: oof.]
zhiayang has joined #osdev
gmacd has joined #osdev
zhiayang has quit [Quit: oof.]
zhiayang has joined #osdev
dutch has quit [Ping timeout: 245 seconds]
dutch has joined #osdev
saltd has quit [Read error: Connection reset by peer]
<mrvn>
gmacd: also remeber that #address-cells and #size-cells is A) inherited from the parent, B) entries can have a local address (#address-cells) and parent address (parents #address-cells).
<mrvn>
Also they can be 0, in which case the field in entries is skipped.
gmacd has quit [Ping timeout: 255 seconds]
saltd has joined #osdev
saltd has quit [Remote host closed the connection]
zhiayang has quit [Quit: oof.]
zhiayang has joined #osdev
saltd has joined #osdev
zhiayang has quit [Client Quit]
zhiayang has joined #osdev
zhiayang has quit [Client Quit]
zhiayang has joined #osdev
poyking16 has quit [Ping timeout: 252 seconds]
poyking16 has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
gmacd has joined #osdev
zhiayang has quit [Quit: oof.]
zhiayang has joined #osdev
zhiayang has quit [Client Quit]
poyking16 has quit [Read error: Connection reset by peer]
zhiayang has joined #osdev
gmacd has quit [Ping timeout: 255 seconds]
[itchyjunk] has quit [Read error: Connection reset by peer]
foudfou has joined #osdev
puck has quit [Excess Flood]
puck has joined #osdev
gmacd has joined #osdev
<heat>
mrvn, devicetree really is a wonderful format :^
<heat>
I think it's still better than ACPI but it's hard to screw that up I guess
<geist>
hmm,there was some subtlety that heat found for me though what was it?
<geist>
something other than simply it overriding parent stuff
<heat>
default address-cells is 2 and size-cells is 1
<geist>
ah maybe that was it, i had assumed 1/1
<heat>
silly geist
<heat>
that would make too much sense
<geist>
all thsi aside if you're using C/C++ i highly recommend libfdt to help you. it's a very thin and simple lib that does the silly work for you
<geist>
you provide the logic, it provides the mechanism to walk the tree
<clever>
yep
gmacd has quit [Ping timeout: 268 seconds]
<heat>
the best part is that devicetree is kinda standardized but not really so you can't be too pedantic, else you break some random chinese vendor's devicetree
<geist>
and if you just need it to go find some known node it does most of the work
<geist>
yah i'm not a fan of device tree, but i like it better than the alternatives
<geist>
and i think for the simpler, more basic stuff, it works pretty well (/chosen, /cpu, /memory, etc)
<geist>
it's the device specific nodes that turns into an unstandard mess, but you're not required to pay attentiont o it if you dont need to
<heat>
what do you mean you don't like importing 100kloc for a bytecode interpreter
<heat>
that's just silly
<geist>
100%
<geist>
i have vaguely thought it might be fun to write a smaller interpreter and see how small can do it
<geist>
but then i just have more fun things to do than that
<heat>
reading ACPI legalese and writing parsing code for a horrible, horrible bytecode language isn't very fun
<heat>
I've tried it
<geist>
yah i haven't really looke dmuch into precisely what the structure of the bytecode is, etc. i like writing emulators of things, but if it's not nicely designed then that would suck the fun out of the room
saltd has quit [Read error: Connection reset by peer]
<mxshift>
For Hubris, we're moving toward using KDL to build a DSL to accomplish the same kind of tasks as devicetree.
<j`ey>
surely hubris is only ever going to have a target known at compile time?
<mrvn>
geist: like with DT a big problem with ACPI is vendors not following the specs.
<clever>
large chunks of rpi code just ignore #address-cells entirely
<clever>
the firmware just assumes it has a certain value
<clever>
the userland code just tries to parse 64bit ints as 32bit ints, and if the number is grossly wrong, re-parses it
<mrvn>
clever: iirc it assumes 64bit values witll be 0 as 32bit since it's little endian.
<clever>
yep
<mxshift>
Yes, hubris only has to deal with compile time but maintaining all the target variations is very similar to the dynamic target problems
<mrvn>
Have fun building a RPi with 6GB of memory.
<clever>
but in theory, the DT specs allot for 96bit ints
<mrvn>
2G? ok, it's 32bit.,
<clever>
mrvn: that mis-parsing only occurs in the code for finding the MMIO base addr
<mrvn>
clever: should be everywhere it checks for 32/64.
<clever>
exactly
<clever>
but userland only reads a single dt value, the peripheral base addr
<mrvn>
hehe
<clever>
i also discovered a trick i hadnt noticed before, when helping gmacd above
<mrvn>
The RPi DT has a lot of special cases. Like going cells = 1 -> 2 -> 1. or cells = 0
<clever>
for the vc4 series, the physical space is only 1gig in size
<clever>
and if you have 1gig of ram, the MMIO is covering up the last 16mb of it
<clever>
and the lowest you can set the gpu_mem, is 16mb, and its always at the top of ram
<clever>
based on that, i can assume that the firmware is hiding in the 16mb hole, that the MMIO covers up
<mrvn>
So the part the GPU steals you fill with peripherals?
<clever>
yep
<geist>
hmm, what's the name of a type of problem where someone is asking something specific
<geist>
but it's clearly some sort of second or third dervitive of the real problem
Vercas6 has quit [Quit: Ping timeout (120 seconds)]
wootehfoot has quit [Ping timeout: 245 seconds]
Vercas6 has joined #osdev
heat_ has joined #osdev
heat has quit [Ping timeout: 240 seconds]
lawliet has joined #osdev
Gooberpatrol66 has quit [Quit: Leaving]
Gooberpatrol66 has joined #osdev
jimmy has joined #osdev
jims-revenge has joined #osdev
<saltd>
√
jimmy has quit [Ping timeout: 240 seconds]
heat_ has quit [Read error: Connection reset by peer]
heat_ has joined #osdev
jims-revenge is now known as jimmy
jimmy is now known as rethinkpad
rethinkpad has quit [Quit: Leaving]
socksonme_ has quit [Ping timeout: 240 seconds]
foudfou has quit [Quit: Bye]
foudfou has joined #osdev
<junon>
For a page frame allocator, why can't I store the N+1 most recently released frame's offset in the N'th most recently released frame's first bytes? I don't see this suggested anywhere. I've already started sort of writing this and running into a page table chicken/egg scenario, but wondering if this is practical to do.
<heat_>
none
<heat_>
it's a legit strategy
<heat_>
you form a list of pages using the pages as memory
<heat_>
very popular actually
heat_ is now known as heat
<geist>
indeed. it has limitations, but it's not a terrible way to do it when first getting started
<junon>
So you have to bring the page into the page table first, then read its old value and store it as the next free page offset in the allocator, right? Otherwise you pagefault
<geist>
early on you generally only care about allocated/not allocated, in which case a bitmap or a list of pages themselves is pretty sufficient
<junon>
Yeah exactly, I just want to get this off the ground at this point.
<geist>
also yes indeed, this *does* imply that all of the pages are mapped somewhere
<geist>
so if you do have a physmap (all of the pages mapped somewhere into the kernel, usually ina large block) this is an okay strategy
<geist>
typically over time OSes end up with a per-page structure, outside of the page itself, as a strategy, since it helps you both track free pages (you get a thing to stuff in a free list) and a place to track data once the page is allocated
<heat>
hey thats not a horrible idea
<geist>
but bootstrapping things is a bit more complex there
<heat>
I had never considered using struct page for that
<geist>
yea,h consider the free state of the page as just another state. so when free you can just take the existing page struct and put it in a free list
<heat>
i vaguely recall windows doing something like that
<geist>
yah lots of systems do that
<geist>
the free list might get more complicated with buddy allocators and whatnot, but over time the amount of state you track per page tends to go up, and page tables themselves become not as useful
<geist>
but again, when first getting started just having a free list/bitmap is typically sufficient
<heat>
💯
<heat>
struct page is hard
<geist>
and it oes burn a fixed amount of memory to tack memory, which is a bit annoying
<geist>
but gotta crack eggs to make omlette, etc
<heat>
a fun thing I had to fix when moving away from x86 was that my code assumed memory started at 0
<geist>
i once had a huge argument in here about using struct page for free list, with the general counter argument that 'you're wasting memory to track free pages'
<geist>
but my counter to that is 'it's free pages, if you have free pages you're not tight on ram'
<heat>
so if DRAM started at 4GB I used 4GB/sizeof(struct page) worth of worthless pages
<geist>
yah and worse, x86-pc in particular, you might end up with multiple segments of physical ram
<geist>
in LK/zircon it tracks those as 'arenas' of physical ram
<heat>
but just a single pagemap no?
<geist>
what do you mean by pagemap here?
<heat>
just a simple array
<heat>
struct page pagemap[NrPages];
<geist>
no, there's one per physical run of pages
<heat>
:|
Vercas6 has quit [Remote host closed the connection]
<geist>
that's also an annoying thing you get into with systems with discontiguous memory
<heat>
that's... non conventional
<geist>
x86-pc is pretty bad about it
<geist>
0-640k, 1MB - <somewhere around 3GB>, 4GB+
Vercas6 has joined #osdev
<heat>
fun fact: QEMU stops at 2GB
<geist>
so you can either find the overall range and just 'burn' some pages that are never going to be used
<bslsk05>
github.com: lk/vm.h at master · littlekernel/lk · GitHub
<geist>
zircon uses basically the same mechanism but it's a bit more optimized
<junon>
If all of my pages have to be mapped into the kernel for this to work, though, is there a way to do that with a paging? Or were you confirming that I have to modify the page table to map the page into the kernelspace before I can read/write the list information?
<junon>
I mean of course there's a way to do it with paging, but it means I need to actually map 100% of the pages into the kernel using page table entries, right?
<geist>
junon: depends. which architecture are you implementing this for?
<junon>
amd64
<junon>
Oh nevermind, I totally see why I'm pagefaulting.
<junon>
The bootloader is set to do a 1:1 map, but it does so at an offset
<junon>
so the memory map tells me physical page addresses but I wasn't adding the base offset to that in order to actually access them
<geist>
hmm, looks like LK is not picking up all of ram from multiboot on x86-64
<geist>
a mystery!
<geist>
odd it steems the multiboot info isn't filled out > 4GB.
<junon>
Ayy that worked. Neat.
<junon>
Basically I only ever traverse the memory map from the bootloader if I've exhausted all released pageframes now.
<junon>
and if I've traversed the entire memory map + all released frames, then I'm OOM.
<heat>
erm no
<heat>
the point is that you never traverse a memory map from the bootloader
<heat>
you set that up for every page
<geist>
you set up your pmm based on what is in the memory map, and then never look back, basically
<heat>
yes
<heat>
although not strictly
<heat>
you'll find that you need to reserve a bunch of things
<heat>
except if your bootloader does it for you, but they usually don't
<junon>
What do you mean you never traverse a memory map from the bootloader
<junon>
The bootloader hands me a list of memory regions and whether or not they're usable.
<geist>
actually i dunno precisely what heat is trying to say there
<geist>
oh duh, looks like the LK x86 code simply picks out the first largest block and uses it
<geist>
huh, okay. shows you how far behind the x86 code is
<heat>
geist, you have to reserve things (kernel image, bootloader structures, initrd) so you don't accidentally try and allocate those pages
<heat>
you can't just take what the bootloader gives you
<geist>
oh sure. but you still have to add those to the pmm
<geist>
or at least that's what i do
<heat>
ah
<heat>
well, I don't
<geist>
i create the pmm, bootstrap the VM, and then part of the vm bootstrap is to mark the kernel pages as wired
<clever>
yeah, when doing DT booting, you get the addr+length pairs for all ram, an addr+length for the initrd, and the kernel itself is just unknown
<geist>
then once the vmm is up, it can start mapping more stuff
<clever>
but your linker script can generate symbols to tell you how big the kernel is, and pc-relative addressing can tell you where the kernel is loaded
<bslsk05>
docs.rs: Mapper in x86_64::structures::paging::mapper - Rust
<heat>
yo dawg, I heard your memory manager needs memory, so I built a memory manager to manage memory for your memory manager that manages memory
<lawliet>
XD
<geist>
okay, time to redo the multiboot shit in the pc part
<heat>
this is literally what it looks like
<geist>
part of it is the code used to be valid without the MMU, but that ship sailed a long time ago. the x86 port requires mmu (and vm)
<junon>
Particularly the `map_to()` method. Takes a virtual page and maps a physical frame to it. Automatically allocates more pages to set up the page table entries if needed. Then returns a TLB flush object that you must either use to flush the entry or explicitly ignore it.
<heat>
I built a bootmem memory allocator that is just a list of ranges
<lawliet>
Serious question isn't that insecure tho @heat
<heat>
insecure why?
<heat>
junon, that seems horrible
<heat>
sucks the fun out of kernel dev IMO
<lawliet>
If your not careful with how you use memory it sounds like a disaster
<heat>
you're being very vague
<lawliet>
Like creating page-tables is indeed insafe and from looking at it seems a bit too complex for memory management most designs usually just have on manager detecited for everything
<heat>
what is "careful with how you use memory"?
<lawliet>
For example of use memory after you free it you get a uaf
<heat>
I don't see how that's related here
<junon>
heat: in my case, I'm trying to get this kernel out of the way. It's part of a much larger vision, and the sooner I can get a POC kernel finished, the better.
<junon>
I've already written a lot of this stuff in C before, so I understand what's happening. I'm just being careful to use the right abstractions now to speed up development a bit.
<lawliet>
Again I don't know much Rust but from reading the document dependig how things are done mutiple things can go wrong for example if you don't manage the flags when your managing memory
<heat>
junon, why rust?
<heat>
what's your goal?
<heat>
lawliet, oh that? I don't know how that works
<heat>
I don't use it
<junon>
lawliet: None of this abstracts the CPU stuff away for you, it just provides nice interfaces to do what you need to do.
<junon>
With perhaps the exception of the bootloader crate, most things have been fairly transparent about how they work.
<junon>
And don't make assumptions or try to make everything batteries included.
<lawliet>
@junon makes more sense the yo dawg meme was a bit misleading :_; I mean I scrolled through the doc high quaility documentation if i'm being honest
<heat>
my comment was not related
<heat>
I was just how things work
<heat>
they *always* work like this
<heat>
your page allocator will invariably need memory to set up its own data structures
<heat>
so you end up setting up an early boot memory allocator to take of that, reserve ranges, etc
<heat>
that early boot mem allocator will also need memory, so you either establish a limit and statically allocate an array or something, or you do static allocation + dynamic growing a la linux bootmem
<heat>
it's never pretty
<gog>
never need memory
<heat>
a lot of this early bringup code is super gory
<heat>
it's just the way it is
<heat>
real hairy, manly men do programming like this
<junon>
Not sure what you mean. The bootloader puts the kernel and any BSS sections into a memory region that is marked as "bootloader" that is not considered by the PFA at all. Then the Mapper (linked above) takes not only a virtual address and an already-allocated physical page, but also the pageframe allocator itself in the event the mapping _also_ requires a page for the page table entry itself. Both the target page frame plus the page table frame allocation are
<junon>
performed by the same pageframe allocator.
<junon>
The x86_64 crate takes care of all of the page table munging stuff for me, including encoding/decoding addresses, giving me a nice interface for flushing the TLB, and error handling that fits directly in with the typical way of doing so in Rust (Result objects).
<heat>
ok
<heat>
i dunno what you're talking about
<heat>
your fancy crates don't skip the requirement of a memory allocator for your memory allocator
<junon>
Which memory allocator are you referring to? Page frame allocator? Or heap allocator?
<heat>
page frame allocator
<junon>
The base allocator is stored in a BSS segment, allocated by the bootloader and off-limits to the kernel's page frame allocator.
<heat>
at least a sufficiently evolved design needs it
<heat>
how is an allocator stored in a BSS segment?
<junon>
I don't think my approach is considered a sufficiently evolved design, but it gets the job done for now.
<junon>
My page frame allocator is O(1) space and O(1) time though, by the way. The PFA itself requires no additional memory.
<junon>
The page table mappings do, of course, but those source pages from the PFA when needed.
<heat>
anyway
<heat>
what's your design
<heat>
what are you trying to do
<junon>
kernel-wise?
<clever>
junon: one thing to keep in mind, does it just give a list of pages that total to the requested size, or does it give you a physically contiguous block?
<heat>
system wise
nyah has quit [Ping timeout: 268 seconds]
<junon>
clever: the PFA just shells out singular pages. "give me a page" and "this page is no longer needed" operations. Nothing more.
<heat>
you say you want a POC kernel for a larger vision
<junon>
The actual heap allocator hasn't been writtne yet.
<junon>
It's a microkernel, essentially
<heat>
do you actually care about the kernel?
<heat>
if not, you could've taken it from somewhere else
<heat>
i.e lk
<heat>
or mine! high quality engineering
<junon>
I do, yes. The kernel needs to work in a very specific manner.
<junon>
No kernel that exists now would work.
<heat>
why?
<junon>
Hard to put into a few IRC messages. The kernel's design is simply unlike any other I'm aware of. It has a few primitives that collectively provide the modularity, IPC and security needs all at once, and eschews syscalls as much as possible to do so.
<junon>
The kernel itself is aware of the processes to be run in a particular process-group-like environment and performs IPC channel initialization before ever jumping to their respective entry points. I think Zircon is doing something similar but haven't looked too deep into it.
<junon>
That said, Zircon is cap-based. This one is not.
<heat>
that seems very possible to fit into an existing kernel
<heat>
although if you're liking the kernel dev, keep going!
<heat>
it's fun
<lawliet>
OST is going to be releasing their Windows-Kernel courses and Windows-Internals is quite intrestring
<junon>
The IPC design is too novel I think. I'm sure I could shoehorn this in to another kernel but there's a lot of value in doing this from scratch, at least from all the options I've considered over the last ~7 years haha
<junon>
And yes, it's fun.
<lawliet>
I honestly like Kernel Sec as a topic writing a driver to hide from something like an EDR is a fun challenge
<heat>
what's OST?
<lawliet>
OpenSecurityTraining
<lawliet>
Also when you sub to the lkml do you get emails immedaitely ?
<heat>
yes
<heat>
a whole boatload of them probably
<heat>
brace yourself and set up a filter
<lawliet>
Just subbed haven't got any
<heat>
depends on the list
<lawliet>
I sent an eamil to the vvger.kernel.org one
<lawliet>
Got an email seems like I have to send another
chartreuse has joined #osdev
<geist>
okay spiffed up the multiboot detection for x86:
<geist>
that's the multiple arena thing i was talking about. there's one per run in multiboot (this is on qemu)
<geist>
except i also ignored < 1MB
<heat>
noice
<heat>
ignoring < 1MB is relatively smart although if the memory map is fucked you should submit a bug to the firmware vendor
<geist>
yeah its also useful for things like trampolines for booting secondary cpus, etc
bauen1 has quit [Quit: leaving]
<geist>
so usually easier to just treat it as a special case
<geist>
i think for zircno we tossed up a simple bitmap allocator for 0-640k for that purposes
<geist>
also useful if you want to write a driver that uses ISA dma, lets you allocate a few 64k bounce buffers out of it
<heat>
i just reserve the first page for the smp trampoline
<heat>
i hate the code but... it is what it is
<geist>
yah hadn't gotten around to adding smp to lk x86
<heat>
I built something that's essentially relocatable but not really and is just a blob that gets copied to 0x0
<geist>
it's more of a procedure at this point, but it's not high on my list of fun things to do
<geist>
yah
<heat>
man lk x86 is really undeveloped isn't it?
<clever>
geist: i'm assuming secondary core bringup is handled by acpi?
<heat>
no
<geist>
clever: nope.
<heat>
thank fuck
* heat
knocks on wood
<geist>
heat: somewhat. really it's the lack of smp that's the biggest thing. the mmu and 32 vs 64 and whatnot is fairly mature
<geist>
i'll get around to it someday, but it's not really what folks use LK for. x86 is usually there just to get fast qemu emulation of some generic task
<heat>
you send a sequence of special IPIs to wake APs, although you discover those APs with ACPI ofc
<heat>
I think they're also thinking of a new way to wake them up
<heat>
where you just wake a doorbell and they wake up
<clever>
heat: ah
<heat>
a-la arm I think
<clever>
yeah, that sounds similar to the spin-tables on rpi
opal has quit [Read error: Connection reset by peer]
gxt___ has quit [Remote host closed the connection]
<heat>
I've read this somewhere, although I don't quite recall where
<geist>
has a small 0xc000 sized arena in there, probably should set some sort of lower limit of the size, but whateves
<heat>
yeah that's really awkward
<heat>
I keep everything in the same pool
<heat>
the pagemap is a big array, lookups are super fast
<geist>
yah this is the awkward bulldozer machine i keep around for this stuff
<heat>
and they need to as a good chunk of my design is kinda linux inspired and so page_to_pfn needs to be fast
<geist>
it's like the weird middle child that's good at nothing at all
<clever>
for LK, you have a compile-time number of arena's, and it can either initialize a default one from .bss, or it can be entirely manual
<geist>
clever: yes in this case it's manual. walks the multiboot table, fills out a bunch of arenas and installs them to the pmm
<clever>
yeah, when you have good state from a bootloader, that sounds best
skipwich has quit [Ping timeout: 245 seconds]
bauen1 has joined #osdev
skipwich has joined #osdev
<immibis>
when I don't comment out this undocumented write to an undocumented register in an undocumented DRAM controller, the DRAM is unreliable. Even though u-boot supposedly writes this register
<immibis>
Right to repair should include DRAM controller documentation :)
<heat>
which platform?
<clever>
immibis: the ddr4 controller on the pi is a major source of pain for me, i have no source available, and must rely on a blob to even get ram
<clever>
the ddr2 controller on the pi0-pi3 series seems to work perfectly with the source i found
<heat>
welcome to the real world
<immibis>
clever: "Just" reverse engineer the blob
<heat>
old coreboot platforms also use a mrc.bin blob
<clever>
immibis: been been studying it for months
<immibis>
heat: pinephone
<heat>
new coreboot platforms use the FSP/AGESA
<heat>
although by the time AGESA runs you already have memory up anyway
<heat>
immibis, is that documented?
<clever>
heat: thats more feasible on the latest pi4 firmware, because the they now have a smaller blob, that only does ram-init, and then runs a .elf in SPI
<heat>
could you, erm, feasibly upstream your shit to tianocore?
<clever>
heat: the SPI flash is only 512kb, there wouldnt be room for tianocore
<heat>
because it sounds pretty cool to just put it into SPI
<heat>
oh
<heat>
yeah lol
<heat>
unless...
<clever>
the ram-init blob also checks how big the spi chip is, and will fail to boot if its not a supported size
<heat>
you could /theoretically/ build a super minimal platform, I just don't know how minimal
<clever>
yeah
<clever>
or store tianocore on a 2nd custom spi chip
<clever>
on a gpio header
<immibis>
heat: about the same as raspberry pi, I think. Well, it can run fully open source code, but that doesn't mean that code isn't basically a blob
<immibis>
Of course the vendor's open source code is just writing arbitrary values to arbitrary registers
<immibis>
there is minimal documentation based on terse comments and register names