<griddle>
Hmm, isn't the device tree pointer passed in x0? At least in the qemu virt
<griddle>
Oh, it's actually at the physical address 0
<mrvn>
ugh? last time that's where my kernel was.
gog has quit [Read error: Connection reset by peer]
pg12 has joined #osdev
vdamewood has joined #osdev
freakazoid333 has quit [Ping timeout: 244 seconds]
Brnocrist has quit [Ping timeout: 268 seconds]
Brnocrist has joined #osdev
<griddle>
The fun of having an already portable kernel is that you have to start out w/ the MMU :)
nur has quit [Quit: Leaving]
<heat>
the "fun"
<griddle>
i just want it to run in arm64 because running riscv in TCG is slow in an M1 VM :)
<griddle>
my x86 arch has fallen behind cause I dev on this WMO machine, so x86 emu is dog slow and often incorrect
genpaku has quit [Read error: Connection reset by peer]
genpaku has joined #osdev
zaquest has quit [Remote host closed the connection]
zaquest has joined #osdev
griddle has quit [Ping timeout: 268 seconds]
ebrasca has quit [Remote host closed the connection]
griddle has joined #osdev
heat has quit [Ping timeout: 272 seconds]
<geist>
griddle: yeah that's a good reason
<griddle>
do you practically have to worry about EL{2,3}?
[itchyjunk] has quit [Read error: Connection reset by peer]
<griddle>
Coming from RV64, those modes just feel like M mode, which you can ignore in the presence of S
<geist>
yes and no. in qemu with TCG you can tell it to optionally emulate EL2 and EL3, but the default is to drop you in EL1. in the case of qemu + HVF on a M1 you only get EL1. M1 cpus only actually implement EL2-EL0 (no EL3) and that's where the apple hypervisor/kernel is running at
<geist>
on real hardware, yo might have to at least deal with being booted in EL2 and dropping down to EL1. That's fair common on random arm dev boards coming out of grub or UEFI
<geist>
and yes, for the most part think of EL3 == machine mode, EL1 == supervisor mode, and EL2 is the virtualization mode that risc-v was *going* to implement but they switched gears for their virt extension to be more of a sidestep in supervisor mode
<griddle>
I assume going up to EL1 from 2 is relatively trivial
<griddle>
only machines I may run this on in real hardware are a rpi or a big dual socket ampere altra machine
<geist>
well, yes and no. you can only switch from a lower to a higher mode via an exception or a particular instructio that triggers an exception
Matt|home has quit [Ping timeout: 255 seconds]
<geist>
er, oh wait you said up to. i think of it as down. yeah, dropping to a lower mode (EL2 -> EL1) is basically an eret instruction with teh approproiate state
<geist>
more or less the same as riscv
<griddle>
sans SBI ofc
<griddle>
okay that makes sense
<geist>
right, though ARM has a thing called PSCI, usually implemented at EL3, that you can make calls to that's kinda similar to SBI though less features
<geist>
basically you call it for power management things, oincluding bringing up and shutting down cores
<griddle>
you can trampoline to EL1 w/o having to also support EL2 to a significant degree
<griddle>
?
<geist>
yes. it's easy to drop from EL2 to EL1
<griddle>
Cool thanks
<geist>
you just have to set up a little bit of state, in the form of control registers at EL2 that control the state of EL1 first
<bslsk05>
github.com: lk/asm.S at master · littlekernel/lk · GitHub
<geist>
takes whatever mode you're in and drops to EL1 after setting some state bits
<griddle>
Oh yeah that's trivial
<geist>
note that lots of control registers in ARM64 are banked, much like say mstatus/sstatus
<geist>
they differentiate them with the suffix
<geist>
so say SCTLR_EL3, SCTLR_EL2, etc
<griddle>
arguably better
<geist>
usual rules: you can access the registers in the modes lower than or the same as yours
<griddle>
is the terminology that EL1 is a "higher" mode than EL2 or the other way
<geist>
i generally say lower
<geist>
and i like that numbering convention
<geist>
you 'drop to' a lower mode
<griddle>
I like that. You have lower priv
<geist>
right. i like the numbering in that direction better than the x86 rings being backwards
<griddle>
or riscv being letters :^)
<griddle>
esp in the light of x86 having ring -3
<geist>
yah. note that the numbering of the modes in riscv is the same direction
<geist>
ie, m = 3, s = 1, u = 0, etc
<geist>
yah x86 rings are a direct copy of VAX rings, so can blame DEC for that
<griddle>
yeah, kinda an intel footgun
<griddle>
copy VAX, nobody uses it
<griddle>
now you are stuck w/ higher priv modes being negative
<geist>
note that ARM64 allows a lotof the modes to be optional, though differently than riscv
<geist>
riscv mandates that M mode always exist and most of the rest of the modes are optional, except i think U must exist if S exists
<griddle>
yeah
<geist>
arm is the other way around. EL0 and EL1 must exist i think, the other modes above are optional
<griddle>
M, M+U, M+S+U
pretty_dumm_guy has quit [Quit: WeeChat 3.5]
<griddle>
so EL0 is just defacto "user mode" code
<griddle>
or "at least less priv than whatever the highest priv"
<geist>
the higher levels in ARM are not really any more intrinsically priviledged except that levels above can take things away from them, etc
<geist>
yes, and EL0 has much less accessed to priviledged instructions, etc
<griddle>
Ah so do the ELs have intrinsic capabilities?
<griddle>
or can I allow or block certain functionality in lower modes
<geist>
somewhat. EL0 is obviously user and can do less things, but otherwise EL1 - EL3 each have their own mmu and page tables (unlike riscv)
<griddle>
Interesting
<geist>
but EL2 has hypervisor capabilities in that it *also* has a second level mmu that EL1 nests with
<geist>
and yes you can block various functionality in lower modes, or arrange for various things to trap into a higher mode
<geist>
EL3 tends to exist solely to be where you put priviledged firmware
<griddle>
a-la riscv delegation?
<griddle>
Makes sense
<geist>
and to allow multiple hypervisors/OSes to run at the same time
<geist>
surprisingly aplpe M1 does not implement EL3. only arm64 core i know of that doesn't
<geist>
also didn't mention, arm64 has similar rules to riscv in the bitness of lower levels. ie you can drop to a lower level and go from 64 -> 32bit, but not the other way
<griddle>
they expose power management through some bits somwhere right?
<geist>
and also based on if the hardware imeplements arm32/etc
<geist>
since the arm32 state fits entirely within the arm64 state
Matt|home has joined #osdev
<geist>
yah that's the PSCI stuff. usually implemented at EL3, though it could be virtually implemented at EL2
<geist>
like you'd get under some sort of hypervisor
<griddle>
So since EL1 and EL0 have different page tables, do systems which assume a single table write the same table to both registers?
<geist>
no they usually split
<geist>
it's actually not that EL0 and EL1 have separate tables it's that there are simply two page tables
<geist>
one for 0 ... N and another from -N ... 0
<griddle>
oh will a miss in El1 mean it scans EL0?
matt__ has joined #osdev
<griddle>
thats actually really cool
<geist>
each independent with their own permission bits. but it's convention that the kernel lives in negative space
<geist>
so when you switch user page tables you usually leave the kernel one there
matt__ is now known as freakazoid333
<geist>
but they can be independently turned off and whatnot
<geist>
a very very nice feature. was sad to see that riscv didn't implement that
<griddle>
Feel like riscv didn't for impl complexity reasons
<geist>
has the whole single top level table thing with non canonical pages and whatnot, exactly like x86
<geist>
oh almost certainly
<griddle>
riscv folks keep boxing themselves into the "low power" category
<geist>
yeah, agreed
<geist>
case in point: no banked timers, so you have to use SBI to virtualize it for you
<geist>
that's pretty painful
<griddle>
sifive keeps saying their hardware is fast
<griddle>
but don't include an l2 prefetcher
<geist>
or needing SBI to do TLB shootdown
<griddle>
300mb/s memory bandwidth
<geist>
yah my experience with real riscv hardware is its anything but fast. but i like it just the same. it's sooooo simple to work with
<griddle>
silicon is slower than a firesim machine
<geist>
a great canonical simple architecture to fiddle with
<griddle>
yeah, it's so simple I love it
<geist>
and pretty great for embedded. it's going to totally soak up that whole space
<geist>
i think ARM is getting pretty worried there
<griddle>
I think arm is shifting more consumer
<griddle>
at least it feels like that
<griddle>
they are pushing into server stuff
<geist>
the M1 wsas a huge win. legitimizes it in the desktop space
<griddle>
absolutely
<geist>
i was honestly blown away, and i've been following that forever
<geist>
(typing on one right now)
<griddle>
plus, their relatively small core size lets them just pack so much more in
<griddle>
the altra I've got has 128 hardware threads
<griddle>
no SMT
<griddle>
I've got an M1 pro and it's currently drawing 6w
<geist>
yah i have a Thunder X2 here with 256 threads. SMT4!
<griddle>
xps15 in the corner is probably drawing 15 watts in smm
<griddle>
off topic from osdev, but I'm angry at apple
<griddle>
they killed off their old text rendering system
<griddle>
if you don't have a 200+ppi display, text looks horrid
<griddle>
big LG ultrawide, 144hz, etc
<geist>
ah yeah
<griddle>
genuinely has the readability of a 480p CRT television from 1993
<geist>
i can see that
<geist>
i have a m1 mini but it's hooked up to an el cheapo 4K so looks okay
<geist>
and this laptop is a m1 pro so it's got a very dense display
<griddle>
yeah that display is the best one I have
<griddle>
so actually
<griddle>
Apple's scaling policy when using 4k is to render at 5k and downsample
<geist>
gotta put that gpu to use!
<griddle>
from system info: U2790B:
<griddle>
Resolution:5120 x 2880 (5K/UHD+ - Ultra High Definition Plus)
<griddle>
UI Looks like:2560 x 1440 @ 60.00Hz
<geist>
kk, gotta go. getting kicked out of a starbux
<griddle>
oof, safe travels
<moon-child>
kicked out? Why?
<griddle>
closing i assume
Terlisimo has quit [Quit: Connection reset by beer]
<griddle>
they dimmed the lights and turned off the R&B
<moon-child>
oh, sure
tsraoien has quit [Ping timeout: 252 seconds]
<geist>
heh yeah mor elike they're putting the chairs up
<griddle>
cutting it close
<geist>
yah it's a nice starbux though. we dont get a lot of places to go here that stay open this late (8pm)
<geist>
at least around here
Terlisimo has joined #osdev
ajr has quit [Quit: WeeChat 3.6]
griddle has quit [Quit: griddle]
griddle_ has joined #osdev
griddle_ has quit [Client Quit]
skipwich has quit [Quit: DISCONNECT]
griddle has joined #osdev
skipwich has joined #osdev
griddle has quit [Client Quit]
griddle has joined #osdev
smeso has quit [Quit: smeso]
<griddle>
So it seems like arm has a bunch of all caps "FEAT_*" stuff. Am I to assume these all function as separate registers?
zid` has quit [Ping timeout: 268 seconds]
<griddle>
Also, QEMU virt dropped me into EL4?
smeso has joined #osdev
<griddle>
Oh my bad, nvm (didn't read the encoding)
gog` has quit [Ping timeout: 252 seconds]
zid has joined #osdev
<zid>
I have sausage rolls
<j`ey>
griddle: FEAT are encoded in the ID registers
<geist>
yeah the EL is shifted over for some reason
\Test_User has quit [Ping timeout: 268 seconds]
\Test_User has joined #osdev
tsraoien has joined #osdev
the_lanetly_052 has joined #osdev
tsraoien has quit [Ping timeout: 245 seconds]
gog` has joined #osdev
marshmallow has joined #osdev
invalidopcode has quit [Quit: Ping timeout (120 seconds)]
justmatt has joined #osdev
invalidopcode has joined #osdev
scaleww has joined #osdev
ripmalware__ has joined #osdev
ripmalware_ has quit [Ping timeout: 240 seconds]
basil has quit [Remote host closed the connection]
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
eroux has joined #osdev
nyah has joined #osdev
<griddle>
Late hello
<mrvn>
Anyone a clue how to change the boot order of a supermicro server via redfish?
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
jimbzy has quit [Read error: Connection reset by peer]
fwg has joined #osdev
gog has joined #osdev
opal has quit [Ping timeout: 268 seconds]
gildasio has quit [Remote host closed the connection]
gildasio has joined #osdev
fwg_ has joined #osdev
fwg has quit [Ping timeout: 268 seconds]
opal has joined #osdev
sikkiladho_ has quit [Quit: Connection closed for inactivity]
fwg_ has quit [Quit: .oO( zzZzZzz ...]
elastic_dog has quit [Ping timeout: 255 seconds]
sikkiladho_ has joined #osdev
wolfshappen has quit [Ping timeout: 252 seconds]
<sikkiladho_>
any clue how do you get the value of something like INIT_SCTLR_EL1_MMU_OFF in linux kernel which are nested with other macros. I was just curious.
elastic_dog has joined #osdev
<GeDaMo>
Write a C program to print it out?
<j`ey>
^ thats what I do
gildasio has quit [Ping timeout: 268 seconds]
gildasio has joined #osdev
<sikkiladho_>
macro is inside the kernel, so I should write a kernel module to access and print it?
<GeDaMo>
The macro is in C, a program doesn't have to be a kernel module to resolve the name
<j`ey>
sikkiladho_: copy all the macros into a file
<sikkiladho_>
Thanks, will do.
mzxtuelkl has quit [Read error: Connection reset by peer]
<GeDaMo>
You don't even have to run the program, just put it through the preprocessor
gildasio has quit [Ping timeout: 268 seconds]
wolfshappen has joined #osdev
<geist>
also if it's just loaded into a register in C you can probalby just look at the dissassembly and see what it computed
<geist>
for something like arm it'll be a load into a x register and then a msr into SCTLR
wolfshappen has quit [Ping timeout: 268 seconds]
* zid
checks what -E does on godbolt
<zid>
ah it works cool
wolfshappen has joined #osdev
<zid>
return EXIT_FAILURE;
<zid>
return
<zid>
# 5 "/app/example.c" 3 4
<zid>
1
wolfshappen has quit [Quit: later]
wolfshappen has joined #osdev
blockhead has joined #osdev
jimbzy has joined #osdev
opal has quit [Remote host closed the connection]
opal has joined #osdev
HaxCPU is now known as WaxCPU
gildasio has joined #osdev
ptrc has quit [Remote host closed the connection]
ptrc has joined #osdev
ajr has joined #osdev
the_lanetly_052_ has quit [Ping timeout: 245 seconds]
gildasio has quit [Quit: WeeChat 3.6]
gxt_ has quit [Ping timeout: 268 seconds]
gxt_ has joined #osdev
liz has quit [Quit: leaving]
jafarlihi has joined #osdev
<jafarlihi>
geist: Hey! Do you know what's the difference between workstation and workstation_eng in Fuchsia?
<geist>
_eng has more stuff in it. i forget the details, but it's a superset
<jafarlihi>
OK, thanks
jafarlihi has quit [Quit: WeeChat 3.0]
gildasio has joined #osdev
foudfou has quit [Remote host closed the connection]
FreeFull has joined #osdev
foudfou has joined #osdev
_whitelogger has joined #osdev
foudfou has quit [Remote host closed the connection]
<ebrasca>
geist: Your code is helpfull , it helped me progress with my driver!
<geist>
cool!
<geist>
the e1000 stuff?
<ebrasca>
Yes
foudfou has joined #osdev
<geist>
it may not be the most rock solid driver, since i just wrote it and it hasn't been stressed out, but should be much easier to understand for basic setup
<ebrasca>
I need to finish init , read and write and I will call it done!
<ebrasca>
I like to have it to test better tcp ip in the OS!
<heat>
i'm reasonably proud of my e1000 driver
<heat>
supports most basic "fancy" features like csum offloading
<heat>
although I don't support segmentation offloading
<heat>
still haven't quite wrapped my head around that
<geist>
yeah the seg offloading looked a bit more complex to set up
<geist>
looks like you have to stuff metdata packets into the queue to tell it what its doing? something like that
<geist>
or something like that
<heat>
you mean the extended descriptor format?
<geist>
something like tat? been a whie since i looked at it
<heat>
I'm not quite worried about segmentation offloading in the driver itself, but any possible side-effects of using it inside the network stack
<geist>
i thought there was some mechanism by which you dscribe some external data outside of packets itself
<heat>
and actually enable it
<geist>
indeed, you'd have to at the minimum be able to deal with 64k MTU packets at the net stack, etc
<heat>
checksum offloading is also tricky sometimes
<heat>
I can't remember why exactly, but fragmented packets can't use it
<heat>
oh of course
<heat>
how can the csum offloading engine calculate a csum if it can only see part of it
gildasio has quit [Remote host closed the connection]
foudfou has quit [Remote host closed the connection]
gildasio has joined #osdev
foudfou has joined #osdev
<zid>
My e1000 is garbage and might be completely wrong, but it sends and recvs packets and it's like 50 lines so whatever :p
lkurusa has quit [Quit: I probably fell asleep (or went out). Who will ever know.]
<bslsk05>
github.com: boros/e1000.c at master · zid/boros · GitHub
<heat>
it's 6 times as long
<heat>
fake news
<zid>
50 * 6 = 230 now?
<zid>
fake fake news
<zid>
like 100 of it is struct decs
<zid>
it used to be 50 lines of actual cod
<heat>
shit
<heat>
me no math
<heat>
that seems like a challenge though
mavhq has quit [Ping timeout: 252 seconds]
<heat>
codegolf a driver
<ebrasca>
I see 238
<heat>
or a whole operating system really
<heat>
OG C unix
<zid>
The problem is, you can cheat a lot
<zid>
like the famous story of the 4k demo competition where they ran code coverage to see what they could delete to save a few bytes
<zid>
and found out that none of the testers ever pressed backwards
<zid>
so they just removed that feature
<heat>
yes
<zid>
if you remove *all* the edge cases, free, etc it'll all run fine, until it doesn't :D
<heat>
that's not cheating
<heat>
that's like how old UNIX worked
<zid>
you end up rubbing against "does this still count?" quite hard, and it turns into rules lawyering
GeDaMo has quit [Quit: There is as yet insufficient data for a meaningful answer.]
<zid>
i.e qemu never delivers fragmented packets, does the e1000 code still count if it can't handle them? It would definitely not work on a lot of networks.
k8yun has joined #osdev
<ebrasca>
Does qemu do something special for rst packets?
<zid>
qemu shouldn't care what's in the packets at all should it
<zid>
I doubt it even knows you're doing tcp/ip
<zid>
appletalk for life
<ebrasca>
I send rst packets from the guest but I don't see them on wireshark
<ebrasca>
for some reason I see fin + ack instead
<zid>
sounds like something your host is doing
<ebrasca>
What do you mean?
<zid>
it's going through several software stacks before wireshark sees it, potentially
<heat>
zid, qemu does know you're doing tcp/ip
<zid>
orly, whyso?
<heat>
when you do SYN-ACK-SYNACK you're not actually connecting directly with user mode networking
<mrvn>
zid: That's how the smallest C source that outputs itself reaches 0 bytes.
<zid>
oh I've never used user mode networking
<ebrasca>
I just like to test rst packets in my OS on qemu!
<heat>
everything goes through slirp
<zid>
I use tunnels and bridges and shit
Dreg has quit [Read error: Connection reset by peer]
<heat>
zid the infrastructure man
<mrvn>
slirp rocks
Dreg has joined #osdev
mavhq has joined #osdev
rwb has quit [Ping timeout: 244 seconds]
xenos1984 has quit [Ping timeout: 272 seconds]
lkurusa has joined #osdev
<mrvn>
zid: My avian carriers ignore tunnels and bridges and de-encapsulation from hawks is messy.
xenos1984 has joined #osdev
dude12312414 has joined #osdev
rwb has joined #osdev
<gorgonical>
Man why can't I get club mate here
<mrvn>
Man why can't I get Duncan Donuts here?
<jimbzy>
mrvn, Have you asked Mr. Donuts to come by?
<mrvn>
They don't deliver
<jimbzy>
Jerks...
<jimbzy>
Like they have anything better to do.
<gorgonical>
There's a place near me that has cinnamon rolls the size of dinner plates
<gorgonical>
I love that place
Ram-Z_ has quit [Ping timeout: 255 seconds]
<jimbzy>
We have a little coffee/muffin place here with muffins like that.
k8yun has quit [Quit: Leaving]
<jimbzy>
Absolutely massive
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
Ram-Z has joined #osdev
gog has quit [Read error: Connection reset by peer]
gog has joined #osdev
<zid>
I bought a puzzle game on steam, so now I am writing an enigma machine implementation
freakazoid333 has quit [Ping timeout: 272 seconds]
gildasio has quit [Ping timeout: 268 seconds]
gildasio has joined #osdev
frkazoid333 has joined #osdev
elastic_dog has quit [Ping timeout: 240 seconds]
<mats1>
tis 100?
<zid>
heh no, some random short/cheap game called cypher
elastic_dog has joined #osdev
elastic_dog has quit [Excess Flood]
chartreuse has joined #osdev
elastic_dog has joined #osdev
<zid>
bastards, last bit needs me to implement plugs and three rotors and rotor swaps
<zid>
and initial rotor positions
<zid>
*reads a book instead*
gildasio has quit [Quit: WeeChat 3.6]
gxt_ has quit [Remote host closed the connection]
opal has quit [Remote host closed the connection]
gxt_ has joined #osdev
opal has joined #osdev
SpikeHeron has quit [Quit: WeeChat 3.6]
opal has quit [Remote host closed the connection]
xenos1984 has quit [Read error: Connection reset by peer]