<not_not>
so im thinking, not gonna write an OS or anything just wanna do bare metal work, should i write a x86 real mode kernel with a debugger and a sort of assembler so i can build into protected and long mode from there?
isaacwoods has quit [Quit: WeeChat 3.3]
dude12312414 has joined #osdev
<not_not>
never written any non userspace code on x86 but i have broad enough understanding of protected mode paging and the stack etc to start doing this little side hobby project
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<moon-child>
not_not: standard advice is to spend little time outside of long mode, and not to write your own debugger or assembler
<moon-child>
that said, whatever suits your fancy, go ahead and do
<not_not>
ok
<not_not>
well as from gnu binutils will always work anyhow
<not_not>
no need to write my own
<not_not>
so u reccomend just copy pasting a boot loader that gets you into long mode and start coding from there?
<not_not>
man im scared i wanna go back to userspace now
<Mutabah>
Usual suggestion is to either use grub to load you into protected mode (and then almost immediately switch to long mode)
<Mutabah>
or use uEFI to go straight into long mode
<not_not>
mhm
pretty_dumm_guy has quit [Quit: WeeChat 3.3]
<not_not>
gonna read up on uEFI
pretty_dumm_guy has joined #osdev
pretty_dumm_guy has quit [Client Quit]
Matt|home has quit [Quit: Leaving]
<Ameisen>
a 7-bit shift in all cases is more performant than a 6-bit shift. Obviously, 8-bit is ideal
<Ameisen>
but that's getting into page sizes where the transfer costs become large
<Ameisen>
5 bit I think would be too small, though - there'd be too much thrashing at <= 32B
<Ameisen>
though I think it's also one of those things that needs to be profiled under normal usage
<Ameisen>
whatever normal usage actually means in that case
<Ameisen>
I was also going over on paper how to implement things like pipes and usch
<Ameisen>
such*
<Ameisen>
effectively, once the base system is in-place, anything that isn't a core OS structure has to be able to be virtualized and paged
<Ameisen>
there just isn't enough SRAM otherwise.
<Ameisen>
with an SRAM expansion, that's still the case; though it would give a bit more freedom depending on how it's used (since it would be banked memory, with either 56KiB per bank or 64KiB per bank)
<Ameisen>
though I'd rather use banks for more page associativity
skipwich has joined #osdev
<Ameisen>
I'm not sure if this is easier or harder than traditional osdev.
<zid>
Ameisen: Make a supercomputer out of those 6 cent prom micros
<Ameisen>
D:
<Ameisen>
which 6 cent proms
<zid>
for 6 cents each you could use them as individual logic gates :p
<Ameisen>
I don't normally look at those
<zid>
padauk pmc150 I think?
<Ameisen>
my other thought was having a ton of AVR cores with an AVR or ARM 'master' that distributed tasks
<Ameisen>
but I wanted something that you could just flash to an arduino
<Ameisen>
so other people could just use it
<Ameisen>
and go "... why?"
<zid>
I say that about MIPS
<Ameisen>
I don't think you should use those as logic gates
<Ameisen>
or at least, not traditional ones
<Ameisen>
they're more powerful than that - think neurons with X inputs and Y outputs
<zid>
Yes I was.. nevermind
<Ameisen>
MIPS... spans the board from 'really basic' to 'really complex'
<zid>
mips goes from "Insane" to "insane and useless"
<Ameisen>
the spec is _very_ flexible in what is acceptable
<Ameisen>
something I've taken advantage of :|
<Ameisen>
that padauk chip's instruction set... reminds me of AVR's
[itchyjunk] has quit [Ping timeout: 260 seconds]
[itchyjunk] has joined #osdev
nvmd has quit [Quit: Later, nerds.]
vdamewood has joined #osdev
Guest64873 has joined #osdev
Guest64873 has left #osdev [#osdev]
vinleod has joined #osdev
vdamewood has quit [Ping timeout: 252 seconds]
sdfgsdfg has quit [Quit: ZzzZ]
scoobydoob has joined #osdev
<geist>
does remind me, omswhere in there i have a board of one of those propellor chips, which were momentarily interesting
scoobydoo has quit [Ping timeout: 260 seconds]
scoobydoob is now known as scoobydoo
vinleod is now known as vdamewood
sdfgsdfg has joined #osdev
srjek_ has quit [Ping timeout: 252 seconds]
sdfgsdfg has quit [Client Quit]
[itchyjunk] has quit [Read error: Connection reset by peer]
sdfgsdfg has joined #osdev
darkstarx has quit [Read error: Connection reset by peer]
darkstardevx has joined #osdev
darkstardevx has quit [Remote host closed the connection]
scoobydoob has joined #osdev
scoobydoo has quit [Ping timeout: 252 seconds]
darkstardevx has joined #osdev
scoobydoob is now known as scoobydoo
Burgundy has joined #osdev
darkstardevx has quit [Read error: Connection reset by peer]
ravan has quit [Read error: No route to host]
ravan has joined #osdev
darkstardevx has joined #osdev
darkstardevx has quit [Remote host closed the connection]
darkstardevx has joined #osdev
scoobydoo has quit [Read error: Connection timed out]
darkstardevx has quit [Remote host closed the connection]
scoobydoo has joined #osdev
ElectronApps has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
darkstardevx has joined #osdev
darkstardevx has quit [Remote host closed the connection]
darkstardevx has joined #osdev
sdfgsdfg has quit [Quit: ZzzZ]
sdfgsdfg has joined #osdev
zaquest has quit [Remote host closed the connection]
zaquest has joined #osdev
<geist>
argh, trying to receive a packet, but getting a fifo overflow
<geist>
something isn't quite right, but can't figure out what it is
<geist>
also i get precisely one fifo overflow, which is strange, unless there's some state you have to clear other than the interrupt
<geist>
time to use the qemu source
<zid>
head and tail swapped?
<zid>
I had docs that described them backwards relative to qemu/bochs
<geist>
oh. hrm. worth double checking
<geist>
ah nope. same
darkstardevx has quit [Read error: Connection reset by peer]
<zid>
I just debugged qemu itself with qdb it was easiest :D
<geist>
yah it even sees my head/tail pointers: e1000_receiver_overrun Receiver overrun: dropped packet of 90 bytes, RDH=0, RDT=32
<geist>
what's odd is it does that precisely once and then never again, like it's decided it's not going to receive or do anything else
<geist>
seems if it was still getting packets it'd jsut trigger that constantly
<zid>
head 0 and tail 32 seems good, too
<geist>
yah
<geist>
and i have the ring len set to 64, so it's not that it's wrapped
<geist>
i have the bsize set to 1024
<zid>
64 is too small for that I think?
<geist>
well, okay i mean 64 entries
<geist>
but i'll double check that i got that right
darkstardevx has quit [Remote host closed the connection]
<geist>
maybe it's upset that i'm not actually triggering a real interrupt. at the moment i'm just spinning on ICR waiting for it to change
<zid>
I think that code only gets hit by comparing various sizes in res
pg12 has quit [Ping timeout: 240 seconds]
<zid>
regs*
<geist>
looking at the qemu code that should work fine. since if ICR ever gets anything nonzero in it reading from it will just set it back to 0
darkstardevx has joined #osdev
<zid>
s->rxbuf_size < packet_size or whatever
<geist>
yah i look at the overrun code in qemu, it should work. it just does a comparison of the gap between tail/head and multiplies by BSIZE and if that's >= packet you're golden
<geist>
it's almost like it got stuck in that do loop and rolled all the way over
<zid>
so it's the left side of the if that bailed, because it never filled out a descriptor?
<zid>
start is still equal to head
<zid>
which can only happen if line 1018?
<zid>
++RDH >= RDLEN
<geist>
myu guess is my buffers pointers are null and it just skips them
<geist>
because of if(desc.addr)
<zid>
but you don't get the DBGOUT for Null RX descriptor?
<zid>
ah
<zid>
weird that the *hardware* is checking those for 0
<geist>
and that's exactly what seems to be the case. i added a printf to the top of that do loop, and it seems to cycle through the whole thing and come back to 0
<zid>
That's a neat way to do the error checking at least
<zid>
increment and scan, if you get back to where you started, something has gone wrong
<zid>
trying to write that as a for condition would be hairy
<geist>
yah there's some verbiage in the intel docs that if you have a null address it will skip it on rx and tx
<geist>
you can use it to align split packets' descriptors to a cache line
<geist>
to optimize how it fetches PCI/etc
<geist>
since it's doing internally a burst dma of a block of descriptors at a time
<zid>
Was just looking at desc.status
<zid>
it doesn't seem to check it for anything, but it bothers to reset it back to 0?
<zid>
oh it ORs on RDX_STAT_DD and these aren't copies of the descriptors they're the real ones
<zid>
(*I* am the one who checks it, but I guess it's sorta useless in the tx case except for my own amusement)
<geist>
okay it's definitely reading the wrong descriptors
<geist>
so something is off with how i'm loading the address for the ring
scoobydoo has quit [Read error: Connection timed out]
<zid>
hopefully tx_desc[0].addr is something useful.. but I imagine it is 0
<zid>
Given that's the current head
<geist>
the plot keeps thickening
<zid>
rx*
<zid>
I'm dumb so I just load every descriptor with a free page at rx_init, so hopefully at least 16 packets have to appear before it crashes ;)
scoobydoo has joined #osdev
<geist>
all the addresses are right, and i can confirm in qemu that physically at the right address the descreiptor is there
<geist>
via xp /32, etc
<geist>
so almost got it...
<zid>
did you.. forget to put the address for the descriptor array into the register? :)
<zid>
That'd make it very unable to find your perfectly valid buffer_addr fields
<geist>
ooooh, you know i think i forgot to enable the PCI device
<geist>
so qemu is faithfully emulating it not being able to bus master
<geist>
i traced it all the way to doing the pci_dma_read() and then getting back basically nothing
<geist>
frack. that was it. :)
<zid>
yea I forgot to enable bus mastering, I had no idea I was supposed to, to be fair
<zid>
why is that causing overruns though?
<zid>
it's reading 0s from your memory?
<geist>
it's reading 0s when it tries to read the rx descriptors
<zid>
desc.xxx all come back as 0s because it'd need bus mastering to snoop your ram
<zid>
right
<geist>
which then means it gets a 0
<geist>
and then when it goes to find a descriptor it loops all the way around and overruns because none are available for use
<geist>
cuuuute
<geist>
and now it's gleefully reading packets like a boss
<geist>
woot
<zid>
nice, feature parity with mine then
<geist>
thank you Zid The Duck
<zid>
did you do MSIs yet or did you do dumb-pci first?
<geist>
dump 'set everything up and spin on the ICR' first
<zid>
ah the double-dumb
<geist>
now i'm going to need to hack MSI support real quick and wire up the interrupt
<geist>
but i have found the MSI capability and whatnot, so it's mostly a matter of quickly tossing ogether some sort of platform specific IRQ allocator and the logic to synthesize the MSI address/data word
<zid>
pfft irq allocator
<zid>
it's an E1000 so it gets interrupt 0xE1, done ;)
<geist>
well, want to at least make sure two drivers dont get the same one
xenos1984 has joined #osdev
<zid>
My plan when I next worked on my shit was to parse the madt to get the ioapic addr, then switch e1000 to msi
<zid>
so you should just send me your diff afterwards and I'll see if it applies to my code
<geist>
yeah i was working at it from the othe end. the work in the last few months started with the MADT and then built up wards from that
<geist>
i tend to be bottom up with these sort of things
<geist>
which also is why i tend to have tons of unfinished stuff, since i implement all the foundation first, but if i dont get to the end there's no much good stuff to show for it
<geist>
ugh i forget. whats the generic arch neutral way to test for 32 vs 64bit?
<geist>
I guess sizeof(void *) but i need to do it in the preprocessor
<geist>
__INTPTR_WIDTH__ seems to be interesting
<kingoffrance>
yah was gonna say even freestanding surely has defines
<bslsk05>
github.com: lk/e1000.cpp at wip/pci · littlekernel/lk · GitHub
<geist>
clearly has a lot of cleanup, but enough to find the device, try to get it going and then just sit there and endlessly toil reading the interrupt status
<geist>
reason i was using 1k BUFLEN is the pktbuf chained things are like 1800 bytes long. basically 2K buffers chopped into a header + payload. since the e1000 can only read powers of 2 it's a little annoying since i cant just queue it up with a 1500 byte payload, but all the drivers prior to this have been a bit more flexible in how their RX lengts were set
<geist>
so might rethink this a bit
<geist>
but a 1k buffer is fine for RX, it'll just have to at worst chain two of them together, which the net stack can handle
<geist>
i suppse i could live a *little* dangerously and go ahead and set the RXLEN to 2K and just rely on it only receiving 1500 byte packets, but that's pushing it a bit
<geist>
but, another day
xenos1984 has quit [Quit: Leaving.]
scoobydoo has quit [Read error: Connection timed out]
xenos1984 has joined #osdev
scoobydoo has joined #osdev
<gog>
mew
Matt|home has joined #osdev
sdfgsdfg has quit [Quit: ZzzZ]
<geist>
hiya gog
<gog>
mornin' geist
<gog>
up late?
seL4 has joined #osdev
<klange>
lots of bugs in kuroko today
scoobydoo has quit [Read error: Connection timed out]
scoobydoo has joined #osdev
seL4 has left #osdev [#osdev]
seL4 has joined #osdev
scoobydoo has quit [Remote host closed the connection]
scoobydoo has joined #osdev
dormito has quit [Quit: WeeChat 3.3]
sdfgsdfg has joined #osdev
[itchyjunk] has joined #osdev
fwg has joined #osdev
fwg has quit [Client Quit]
seL4 has quit [Remote host closed the connection]
dormito has joined #osdev
[itchyjunk] has quit [Read error: Connection reset by peer]
heat has joined #osdev
GeDaMo has joined #osdev
[itchyjunk] has joined #osdev
sdfgsdfg has quit [Quit: ZzzZ]
ravan has quit [Remote host closed the connection]
pretty_dumm_guy has joined #osdev
<heat>
are there any ports that get very sad when you add options to CC and CXX?
<kingoffrance>
"$CC" in shell will break. $CC will be fine. i dont know, yes? supposed to be CFLAGS CXXFLAGS surely?
<kingoffrance>
im sure ive ran into that, either something didnt use flags or i was finaggling something.....i just wouldnt say my situation is comparable to most ppl. hopefully that stuff is fixed :)
<kingoffrance>
"supposed to be" CFLAGS etc. i dont know of posix or somebody saying that though . its on "the honor system" is my understanding
<kingoffrance>
ad hoc "standard" to my knowledge
<kingoffrance>
i have no idea who started it
<kingoffrance>
a cheat is to write some stupid wrapper script of course
<klange>
Worth mentioning that most things are built from autotools and GNU has an absolutely massive list of what they consider standard variables, targets, and so on.
<kingoffrance>
^ yeah im not worried about autotools stuff, its all the otehr stuff
<kingoffrance>
people who write "configure" by hand, or do the spaceballs thing "why you always configure? just make" :)
<kingoffrance>
not that i am against such things, just their variables might not match
<heat>
lots of packages ignore CFLAGS or CXXFLAGS
<heat>
or have really weird setups for cross compilation flags
<kingoffrance>
i think even autotools stuff, ppl might hardcode sometimes
<heat>
case in point: openssl ignores CFLAGS and CXXFLAGS (you specify those in perl config files), but uses CC and CXX
<kingoffrance>
i remember when i had an alpha -ffast-math (for stuff like ffmpeg, dont recall) would break IIRC was hardcoded for multimedia stuff
<heat>
also with clang you need to pass --target *everywhere* and its way easier to pass it directly in CC
<kingoffrance>
freebsd base system used to too. they didnt want you building -Os for kernel or somethings, youd have to edit the makefile to not mess with your flags (not saying one should do that, unsupported)
<kingoffrance>
the makefile would substitute some things out
<kingoffrance>
i mean their is "partial support" too
<kingoffrance>
some flags pass through, others disappear
<j`ey>
heat: does $target-triple-clang work?
<kingoffrance>
i woulda preferred LIVE_DANGEROUSLY=y
<klange>
--fuck-my-shit-up
<heat>
j`ey: dunno, does it? I've never tried to symlink stuff like that
<klange>
Presumably there's something less borked than forcing --target, as clang is building all sorts of cross targeted shit at Apple these days.
<heat>
at least with autoconf I've noticed that passing --host=$TARGET will always make it look for $TARGET-gcc
<heat>
ohhhhh the symlinks work
<klange>
argv[0] magic is saucy
<j`ey>
heat: oh it does, cool!
<heat>
wait no it doesn't this dude just wrote a script
<heat>
lol
<j`ey>
:D
heat has quit [Remote host closed the connection]
scoobydoo has quit [Read error: Connection timed out]
heat has joined #osdev
scoobydoo has joined #osdev
vdamewood has joined #osdev
dutch has quit [Quit: WeeChat 3.3]
xenos1984 has quit [Remote host closed the connection]
dutch has joined #osdev
xenos1984 has joined #osdev
bauen1 has quit [Ping timeout: 256 seconds]
heat has quit [Remote host closed the connection]
heat has joined #osdev
srjek_ has joined #osdev
darkstardevx has joined #osdev
ecs has quit [Ping timeout: 268 seconds]
heat has quit [Remote host closed the connection]
nshp has quit [Ping timeout: 245 seconds]
ecs has joined #osdev
raggi has quit [Ping timeout: 245 seconds]
raggi has joined #osdev
cheapie has quit [Ping timeout: 268 seconds]
nvmd has joined #osdev
bauen1 has joined #osdev
[itchyjunk] has quit [Read error: Connection reset by peer]
bauen1 has quit [Ping timeout: 250 seconds]
bauen1 has joined #osdev
dormito has quit [Ping timeout: 245 seconds]
dormito has joined #osdev
ElectronApps has quit [Remote host closed the connection]
cheapie has joined #osdev
mahmutov has joined #osdev
bauen1 has quit [Ping timeout: 240 seconds]
bauen1 has joined #osdev
dutch has quit [Quit: WeeChat 3.3]
scoobydoo has quit [Read error: Connection timed out]
scoobydoo has joined #osdev
SpikeHeron has joined #osdev
xenos1984 has quit [Quit: Leaving.]
bauen1 has quit [Ping timeout: 268 seconds]
bauen1 has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
xenos1984 has joined #osdev
lleo has joined #osdev
leo__ has joined #osdev
bauen1 has quit [Ping timeout: 260 seconds]
bauen1 has joined #osdev
leo__ has quit [Ping timeout: 256 seconds]
lleo has quit [Ping timeout: 256 seconds]
freakazoid333 has joined #osdev
[itchyjunk] has joined #osdev
scoobydoo has quit [Read error: Connection timed out]
<bslsk05>
googleprojectzero.blogspot.com: Project Zero: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution
<Bitweasil>
JBIG2 doesn't have scripting capabilities, but when combined with a vulnerability, it does have the ability to emulate circuits of arbitrary logic gates operating on arbitrary memory. So why not just use that to build your own computer architecture and script that!? That's exactly what this exploit does. Using over 70,000 segment commands defining logical bit operations, they define a small computer architecture with features such as registers and a
<Bitweasil>
full 64-bit adder and comparator which they use to search memory and perform arithmetic operations. It's not as fast as Javascript, but it's fundamentally computationally equivalent.
<kingoffrance>
Looking at the selector name, the intention here was probably to just copy the GIF file before editing the loop count field, but the semantics of this method are different. Under the hood it uses the CoreGraphics APIs to render the source image to a new GIF file at the destination path.
<kingoffrance>
with that, it almost seems inevitable
<Bitweasil>
Yeah. :/
Starfoxxes has quit [Ping timeout: 252 seconds]
<kingoffrance>
numSyms += ((JBIG2SymbolDict *)seg)->getSize(); // (2) <-- didnt check for overflow, which seems like it wouldve mitigated
<Bitweasil>
It's a tiny image, won't overflow, no problme!
<kingoffrance>
sure, trust random files from random text messages :D
<Bitweasil>
I like getting text messages, therefore anyone who texts me is my friend, and friends wouldn't try to pwn my device!
<Bitweasil>
:(
<Bitweasil>
Seriously, though.
<Bitweasil>
This is literally what that whole Blast Door thing was supposed to sandbox off.
Starfoxxes has joined #osdev
srjek_ has quit [Ping timeout: 252 seconds]
sdfgsdfg has joined #osdev
darkstardevx has quit [Quit: Leaving]
heat has joined #osdev
bauen1 has quit [Ping timeout: 256 seconds]
bauen1 has joined #osdev
wand has quit [Ping timeout: 276 seconds]
zaquest has quit [Remote host closed the connection]
CryptoDavid has joined #osdev
zaquest has joined #osdev
sortie has quit [Quit: Leaving]
<junon>
Two potentially really dumb questions I think I already know the answer to but want to check. 1) Do most/all modern ISAs have the concept of page fault trapping? page switching for memory mapped regions and the like (which assumes it also has the concept of virtual memory) and 2) even on a memory constrained system, the entire address space is usable (not considering higher-half). Like, even if I only allocated a single 4KiB page of memory, I could re-map the same
<junon>
4KiB page over and over again for the entirety of the 32-bit/64-bit address space for a userspace process (again, in theory) - right?
<junon>
Mostly concerned with x86_32/64 and ARM but also interested in other archs if someone knows.
sortie has joined #osdev
<junon>
oh also, hi everyone
<sortie>
Oh geez junon
<sortie>
That's like a lot of people to say hi to
<junon>
and I mean every single "hi"
<junon>
I expect responses btw.
<junon>
all 550 people in here must tell me hello
<junon>
it's the rule
<sortie>
Somebody assign this mad scientist an IP so there's no need to broadcast
<j`ey>
I assume they do for 1, otherwise what would happen if the page faulted
<junon>
j`ey irrrecoverable crash though... now that I've actually put two seconds of thought into it, of course that's not what happens.
<heat>
junon, warm greetings
<junon>
henlo heat
* junon
cracks open a goesser
<heat>
i know some weird architectures like IA-64 have odd ways to handle page faults
<heat>
geist knows a lot about that
<j`ey>
junon: is #2 talking about virtual memory?
<j`ey>
im kinda confused what youre asking
<junon>
j`ey: yes
<heat>
but basically everthing modern that has paging also has page faults, that's just how it goes
<junon>
even if I only have a few hundred mb's of physical ram, there's nothing stopping me from utilizing the entire address space in one way or another, right?
<heat>
basically yeah
<heat>
the only thing that stops you from using the entire address space is page table overhead
bauen1 has quit [Ping timeout: 265 seconds]
<heat>
i.e you run out of physical memory for page tables
<junon>
right okay. like I said, dumb question. I just needed to sanity-check my own thoughts.
<heat>
unless you dupe those
<junon>
Writing some stuff down and second guessed myself lol
<heat>
which is probably totally legit but I'm not too sure on that
<heat>
(like mapping the same PT over and over again)
<heat>
i know there has been some talks on COWing page tables on fork() in lkml
<junon>
isn't that what vfork does?
<heat>
no
<heat>
vfork() is weird
bauen1 has joined #osdev
<heat>
the semantics are weird in general for all the systems
<heat>
but in linux, what happens is that your parent process gets "suspended"
<heat>
if you touch memory, you lose; if you call a function, you lose; if you return from the function, you lose
<heat>
there's no COW
Vercas has quit [Quit: Ping timeout (120 seconds)]
<junon>
Yeah reading the manpage idk why I thought it did COW.
<heat>
it's basically process *p = process_create(); p->address_space = parent->address_space
<junon>
Huh so there's really not been a COW version of fork yet?
<heat>
junon, yes it's called fork
<heat>
fork() COWs pages
<heat>
private mappings, that is
<junon>
oh cow-ing page tables, not pages. I misread your earlier message.
Vercas has joined #osdev
<clever>
vfork was originally a hack, to deal with fork not having cow
<heat>
still is
<clever>
with fork having cow, vfork isnt really of any use
<heat>
vfork() is mostly a hack for no MMU systems
<clever>
but on an mmu-free system, exactly
<heat>
fork() has had COW since forever
<heat>
(where forever is something remotely modern, probably 90s)
<clever>
i assumed that vfork came before cow fork?
<radens>
The raspberry pi versions >=2 have three timers afaict, a system timer, a local timer, and an arm timer. Which is recommended to use as an OS's timer source? Is it possible to have each core receive interrupts and manage its timers independently?
<j`ey>
I'd say use the arm timer
<junon>
But how many no-MMU systems exist these days? No MMU = no paging = no v-mem, right? Or am I missing something?
<clever>
radens: the arm timers are best, because there is one per core, and they can do per-core irq's
<j`ey>
since that's portable
<heat>
clever: dunno
<clever>
they also dont have to be shared with the firmware
<j`ey>
junon: arm64 can run without the MMU on!
<heat>
that's a great question
<radens>
junon: plenty of embedded systems have an mpu memory protection unit or no memory protection at all
<clever>
ive ran no-mmu linux on a treo 650 before
<clever>
due to the lack of mmu, any palmos app can just turn interrupts off and jump to the linux entry-point, lol
<heat>
junon: no MMU is mostly dead but OSS folks usually have a big will to support dead configurations if *someone* *somewhere* still uses it
<heat>
good desktop usage? nah, lets work on the ia-64 port
<j`ey>
heat: why are you working on onyx then? :P
<radens>
junon: oxide computer company just released an os for an embedded system they're using for the bmc which only runs on devices with an mpu not an mmu
<radens>
It seems like the raspberry pi 0 only has the system timer? It sounds like the raspberry pi 0 uses armv6 and the arm timer is an armv7 feature?
<heat>
j`ey: cuz onyx can into space
<heat>
linux s390 cannot into space
<clever>
radens: the pi0 and pi1 have only the legacy vc4 timers
<bslsk05>
cliffle.com: On Hubris And Humility - Cliffle
<clever>
radens: 4 compare registers, that check against the lower 32bits of a global 1mhz counter, and its shared with the firmware
<radens>
clever: thanks
<clever>
radens: with the introduction of 4 arm cores, sharing 4 compare registers between 4 arm and 2 vpu just isnt possible
<heat>
>shared with the firmware
<radens>
clever: am I supposed to only use one of the counters and are some of the counters reserved for the gpu or somethign?
<clever>
radens: exactly
<heat>
bahahahaha that's a recipe for disaster
<clever>
heat: your supposed to just ignore some of the compare registers
<clever>
act like they dont exist
<radens>
clever: do you know which ones, or where I can find more on that? Is it in the bcm2835 datasheet?
wootehfoot has joined #osdev
<clever>
radens: dont remember
<radens>
thanks
<clever>
you could read out the 4 compare regs, and see which one is changing
<clever>
maybe check the linux src
<radens>
lol that's a recipe for disaster
<clever>
the device-tree may tell you
<radens>
Yeah
<clever>
each of the 4 channels also has its own irq
<clever>
so you can mask off interrupts from the firmware timer
<clever>
but the legacy irq controller, can only send hw interrupts to a single arm core
<clever>
so you have no way to route one timer to core-0 and another timer to core-1
<clever>
other then the proper arm timers
<heat>
also in linux you can have a mix of fork(), vfork(), and whatever else you want by using clone(2)
<heat>
turns out the really shitty linux process/thread design is also really powerful
<junon>
Lots of info here, thanks. I think I have the answers I'm looking for. :)
<heat>
note: please don't go for the linux process/thread design
<junon>
heat: I am not. :)
<kingoffrance>
dont tell me what not to do, tell me what to do
<heat>
it's insanity * 10
<heat>
use processes that have a list of threads
<junon>
Does x86/arm always have an MMU? If not, is there not a CPUID flag or something to detect its presence?
<heat>
not processes that also can be apart of thread groups, which are really just groups of processes. also, getppid() and getpid() lie
<heat>
junon, x86 does, arm64 does too afaik
<kingoffrance>
sounds like messed up nomenclature
<j`ey>
arm64 can run without mmu though
<j`ey>
in 64 bit mode, which x86 cant
<kingoffrance>
1 volume > many libraries all over again
<heat>
no caching right?
<clever>
heat: no-mmu arm64 can only get i-cache
<junon>
j`ey: but it always has one available if the OS requires it, right?
Oli has quit [Quit: leaving]
<clever>
with arm64, the cpu starts in a no-mmu 64bit state, and you just make paging tables and turn the mmu on
<clever>
with x86, i dont think no-mmu 64bit exists? and you have to make the paging tables from 32bit???
<heat>
correct
<j`ey>
junon: Im pretty sure MMU isnt optional
<j`ey>
for arm64, never checked
<junon>
arm cortex-M apparently does not have an MMU according to this site I just read
<heat>
mr arm doesn't know every arm detail :O
<junon>
oh, aka stackoverflow.
<Bitweasil>
A series ARM cores will have a MMU that does page tables and such. R series ARM cores have a protection unit with deterministic behavior and a number of sections you can map, but no page tables. M series... doesn't have that, but has a damned fine interrupt vector unit.
<j`ey>
heat: im big dumb
<Bitweasil>
You can definitely run ARM without the MMU, without the caches, etc. There will be some system control register values you can check. ARM also starts in the most privileged EL, so, for a modern A series core, typically EL3.
<bslsk05>
github.com: linux/bcm2835_timer.c at 5bfc75d92efd494db37f5c4c173d3639d4772966 · torvalds/linux · GitHub
<j`ey>
Cortex-M can have an MPU too
<clever>
radens: ah
<Bitweasil>
The MPU is less than even the protected memory management unit, though (PSMA).
<clever>
radens: another interesting fact, the ST_CLO starts counting the instant the soc comes out of reset, when it begins running the boot rom
<radens>
yeah so it will have been running for a while, right?
<clever>
radens: so if you just look at the value when your kernel is booted, you know how long the firmware (rom+bootcode+start.elf) took to boot and pass on control
<radens>
cool thanks
<clever>
yep
<clever>
i have a util that will compare /proc/uptime to that, and tell you the difference
simpl_e has quit [Remote host closed the connection]
<clever>
but with a custom kernel, you can just get the answer directly
sdfgsdfg has quit [Quit: ZzzZ]
<heat>
that's how all the CPU timers work
<heat>
pretty sure you can get timing data like that for x86
<heat>
if you try systemd-analyze you can get precise timing on each part of the booting phase
<clever>
heat: that relies on a very limited subset of api's to access the data
<clever>
heat: when the open VPU firmware turns on the arm core and runs the arm bootloader, there will be some DTB already loaded in ram, with a timestamps node, containing some VPU side timestamps
<bslsk05>
github.com: lk-overlay/loader.c at master · librerpi/lk-overlay · GitHub
<clever>
when patching the DTB for linux, it will then add those timestamps in, along with others
wand has quit [Remote host closed the connection]
<junon>
What is the benefit of the Present bit?
wand has joined #osdev
<junon>
Why not just remove the entry?
<clever>
junon: in paging tables? to define if the page is mapped or not
<clever>
an entry cant be missing, because its a fixed size array
<junon>
Derp, right, thanks
<Bitweasil>
^^ Yeah. If an entry is present, the lookup will proceed. If not, you'll get the appropriate fault for whatever stage of translation failed.
<Bitweasil>
On ARMv7, that includes the level it failed at.
<Bitweasil>
I assume ARMv8 as well, just haven't actually written the MMU for it yet.
<j`ey>
yes for v8 too
<Bitweasil>
ok
<junon>
cool
sdfgsdfg has joined #osdev
<heat>
also if an entry isn't present the rest of the bits are ignored
<heat>
which means you can store data on them if you so desire
<clever>
i think linux at one time used that for swap related state
<Bitweasil>
Didn't L1TF demonstrate that wasn't quite true?
<clever>
so it could swap the page back in
<heat>
clever, yeah I honestly dunno how linux swap works
<Bitweasil>
I thought that was one of the "... actually, you shouldn't, because it could lead to unintended speculative reads" things.
<Bitweasil>
I've always wondered how long a system would run swapping to /dev/null
<Bitweasil>
Sadly, you can't write the "swapfile" bits to /dev/null to get it to use it as swap.
<Bitweasil>
:)
<Bitweasil>
zswap is pretty slick, though.
<clever>
Bitweasil: my system once had a bug, where the hdd showed up as both sda and hda at the same time
<heat>
you can't mount it can you
<clever>
Bitweasil: because i did swap by label, it swapon'd the same partition twice
<clever>
and because i did swap priorities, instead of filling one first and failing like others
<clever>
mine tried to stripe between the 2, lol
<Bitweasil>
Oh my.
<heat>
won't you get all sorts of page cache incoherencies?
<clever>
heat: the main symptom was segfaults
<heat>
hmm actually swap doesn't use the page cache probably
<clever>
because it just silently swapped back in the wrong data
<heat>
the coolest thing I've done with the page/buffer cache is generating incoherencies between the files' page cache and sdaX's page cache
<heat>
turns out it's really easy
<heat>
there's absolutely no relation between both
<Bitweasil>
Yup.
<Bitweasil>
Some of the rowhammer exploits relied on that.
<Bitweasil>
Corrupt the file in memory, it won't be read off the disk again as long as it's in memory.
<heat>
filesystems do direct reads/writes to data blocks and sdaX has its own page cache for metadata and regular read/write(2)
<heat>
write and allocate blocks for a file, look at the block in sdaX, write to it, read back from the file
<heat>
the file will be what you originally wrote
<heat>
if you do an O_DIRECT read it will read whatever got flushed last
<heat>
also linux dirties inodes, not individual pages per se
dormito has quit [Quit: WeeChat 3.3]
<heat>
pages/buffers get marked as dirty but the only things that get queued for flushing are inodes, linux does the dirtying from there
<heat>
and by using a radix tree/xarray they can easily find out what's dirty (works like a page table, dirty bits get propagated all the way up the table) and do coalescing of reads/writes
<heat>
erm, not reads, just writes
<clever>
that reminds me about the scheduler in LK
<clever>
each priority level has its own linked list of pending threads
<clever>
but there is also a bitfield, saying which list has something
<clever>
so you can skip viewing a list you know will be empty
<heat>
yes but that's not how radix trees work
<clever>
yeah, your doing that at multiple layers
<clever>
where you have a pointer to a set of nodes, and a "is any dirty" flag
<heat>
it's almost literally a regular page table structure but the height varies dynamically
<clever>
and doing a whole tree of it
<heat>
so like a file that holds a single page won't have 4 or 5 levels worth of pointer indirection to go through
<clever>
yeah
<heat>
i know there has been a bunch of work in the kernel to better support huge pages and huge pages inside fs code
dude12312414 has joined #osdev
<heat>
including a madvise call you can point at a memory region and it will transform a range into huge pages
<bslsk05>
github.com: rpi-open-firmware/mmu.c at master · librerpi/rpi-open-firmware · GitHub
<Bitweasil>
Oh, wait, no. For the supersections, they all point to the base of the section.
<clever>
Bitweasil: this code will identity map a large chunk of ram
<heat>
j`ey, cute doc
<Bitweasil>
In my test code: // All pages in the 16MB section are identical
<heat>
arm64 names hurt my brain
<heat>
ID_AA64MMFR0_EL1
<Bitweasil>
Oh, nice.
<Bitweasil>
(j`ey's link)
<Bitweasil>
Identification, AArch64, Memory Management Feature Register 0, from EL1 or higher.
<Bitweasil>
Makes sense to me. :(
<j`ey>
ID register, AArc.. there
<heat>
that's what too much arm64 does to you
<Bitweasil>
I'm now working on ARMv8/AArch64, so, yeah.
<j`ey>
Bitweasil: welcome!
<heat>
it's like they chose the stupidest names ever
<heat>
almost ntoskrnl like
<Bitweasil>
heat, that actually makes a ton of sense as a name.
<Bitweasil>
It's better than Intel's "Drop the vowels sometimes, but not always" convention.
<heat>
it makes sense when you're not trying to decode it
<Bitweasil>
So, uh... OS development, who wants to hack on the PinePhone or something? :D
<Bitweasil>
I can't decide if I should obtain one of those or not.
<Bitweasil>
I'm pretty sure they're entirely broken as an actual phone.
<j`ey>
immibis was writing some arm asm for the pinephone
<geist>
in my experience your enjoyment of low level hackery is directly dependent on whether or not you can get good SOC level docs
<geist>
if you can't, it's not any fun, unless that's your thing (reverse engineering stuff)
<heat>
clever, btw I entirely respect your fx-8350 but you should definitely upgrade :D
<clever>
i find figuring out things without docs fun!
<clever>
heat: yeah, i really need to replace this system
<geist>
indeed, it's like mining bitcoins, that cpu is a waste of energy
<Bitweasil>
Need a Core 2 Quad? :D
<clever>
Bitweasil: ive got some core2duo's
<kazinsal>
I think I bought my grandmother a new cheap laptop that's more beefy than an FX-8350...
<heat>
get a solid mobo and a 5600X
<heat>
you're set for a while
<Bitweasil>
Oof. $$$
<heat>
hmm? it's not that expensive
<Bitweasil>
I guess my server has a "AMD Ryzen 7 3700X 8-Core Processor" in it...
<Bitweasil>
Aren't those still in short supply/scalperville?
<heat>
no
<heat>
CPUs never were
<Bitweasil>
Oh, hrm.
<heat>
just GPUs
<Bitweasil>
I thought some of the AMD CPUs were.
<heat>
i don't think so
<Bitweasil>
I guess a couple hundred for a CPU isn't awful.
<Bitweasil>
They last a long time nowl
<heat>
prices have risen a bit but that's because of amd/intel, not scalpers
<kazinsal>
enterprise gear is still unobtanium
<kazinsal>
but that's supply chains being all afuck
<Bitweasil>
The 5600X is on sale at Newegg right now. $299.00, was $299.99!
<Bitweasil>
(lol)
<heat>
stonks
<heat>
i'm looking at a 12900K or a (future) 13900K in the future
<heat>
really fast and has a decent-enough GPU
<heat>
unless GPUs are obtainable next summer or so
<Bitweasil>
No idea. :( The big.LITTLE stuff in... Alder lake, I think? looks pretty interesting, and the benchmarks are solid, just "Wow, what a room heater."
<Bitweasil>
I'm probably done with Intel, though.
<heat>
amd has really really good iGPUs but they don't put them in top of the line stuff
<Bitweasil>
Though I'm rapidly running out of corners of compute to remain in.
<heat>
i like playing games and compiling clang so i'm screwed with amd
<Bitweasil>
I assume for thermal/power reasons?
<Bitweasil>
What's wrong with AMD for gaming?
<Bitweasil>
Windows schedulers are broken half the time on the big chips, but other than that...
<heat>
no real GPUs and no iGPUs in top of the line stuff
<heat>
for amd
<Bitweasil>
"real GPUs"?
<heat>
discrete
<Bitweasil>
I thought their discrete stuff was fine and/or you could use an nVidia card.
wootehfoot has quit [Read error: Connection reset by peer]
<Bitweasil>
I haven't kept up, though.
<heat>
considering intel put an iGPU inside the 12900K, which is the definition of much power hungry such wow, I can't imagine it's because of power/thermals
<heat>
Bitweasil, the issue is that they're unobtainable
<heat>
GPUs are either out of stock or scalped as all hell
<heat>
the best chance to get one is in cpus
<heat>
amd makes really good iGPUs but only puts them in weird APUs
<Bitweasil>
Ah, ok.
<Bitweasil>
I pretty much dropped out of the GPU realm around the 290X/GTX1080 days.
<Bitweasil>
I've got some shit consumer grade card in the house desktop now.
<Bitweasil>
Which I should probably replace with a little ARM box, it's an Intel board. :(
<Bitweasil>
Plays too many games too well.
<heat>
intel has been getting a lot better in iGPUs (probably due to DG1 stuff) but they're not nearly as good
<heat>
anything that runs csgo 1080p well is good enough for me though
<heat>
at least as a temp solution
<heat>
Bitweasil, spend $way_too_much_money on a riscv64 board lol
<Bitweasil>
Are there any Rpi4 or better performance RISCV boards out there?
bauen1 has quit [Ping timeout: 260 seconds]
<Bitweasil>
I'm not opposed to it, but neither do I want to drop $5k on an FPGA rig to emulate at Pentium Pro performance.
<heat>
the only riscv64 board I know of(sifive $stupid_marketing_name) is like $300
<heat>
totally doubt it's anything much better than an rpi 4B
<heat>
the "mobo" itself is way better but dunno about the CPU
<Bitweasil>
They've got the HiFive Unmatched, 16GB RAM...
CryptoDavid has quit [Quit: Connection closed for inactivity]
bauen1 has joined #osdev
<Bitweasil>
For $660, not in stock anywhere...
srjek_ has joined #osdev
<heat>
i swear it was around 300
<heat>
but yeah, big waste of money
bauen1 has quit [Ping timeout: 260 seconds]
vdamewood has joined #osdev
dormito has joined #osdev
<Bitweasil>
Yeah... idk.
<Bitweasil>
I don't even really like computers anymore.
<Bitweasil>
Or, at least, what's being done with them.
<Bitweasil>
Turns out, a Pi4 with a USB SSD actually does a lot of what I need.
vinleod has joined #osdev
vdamewood has quit [Ping timeout: 252 seconds]
kingoffrance has quit [Remote host closed the connection]
kingoffrance has joined #osdev
mahmutov has quit [Ping timeout: 256 seconds]
sdfgsdfg has quit [Quit: ZzzZ]
<kazinsal>
sand was never meant to think
<sortie>
kazinsal, we need to make that the official motto of the osdev wiki
<kazinsal>
The OSDev Foundation: Sand Was Never Meant To Think
<heat>
we're electrocuting it D:
<Bitweasil>
Sounds about right...
<kazinsal>
The OSDev Foundation is like the SCP Foundation, but instead of anomalous entities we're containing undefined behaviour
<junon>
hahahaha
<Bitweasil>
Hey now. In ARMv8, some of it is "CONSTRAINED UNDEFINED."
<Bitweasil>
"You can do this or that, but you can't just go light the building on fire."
<kazinsal>
i386 is definitely Object Class: Keter
<Bitweasil>
SCP foundation is the creepystory archive?
<junon>
Yes
<kazinsal>
collaborative horror fiction in a shared metauniverse, basically
<junon>
I just tried playing the new containment breach multiplayer thing and was totally loss
<kazinsal>
there is no one "canon" in it, but entries tend to reference each other
<Bitweasil>
*nods*
<kazinsal>
it's how you can have shitty late 2000s edgy things like That Fucking Unkillable Lizard in the same meta-universe as Gamers Against Weed (the name is ironic) and canon hub what is for dado yes