<GreaseMonkey>
seems XGA probably doesn't do polygons
<GreaseMonkey>
Trio64 supports flat polygons and patterned polygons (not texture-mapped) but not in the DOSBox implementations of it
<GreaseMonkey>
which is a shame as it would be fun to write a demo for that
<klys_>
it seems dosbox won't work deterministically for me at least yesterday
<klys_>
today I had bash and ls via djgpp and wanted to load them into the same program, hit an obscure internal_malloc error via bash libmalloc.o after setting the segment limits extra high on cs and ds so as to fit both images. here is an image of me trying to load bash4 after setting the high segment limit in crt0.o: http://show.ing.me/paste/dossimul/djgpp-malloc-03dec2021.png
<bslsk05>
github.com: djlsr/crt0.S at master · PC-98/djlsr · GitHub
<klys_>
s/today/yesterday/
mahmutov has joined #osdev
<kazinsal>
When the wiki is back up I’m probably going to start putting together a todo list of articles that either need major cleanup or are in my wheelhouse and need to be more than just stubs
wootehfoot has quit [Read error: Connection reset by peer]
<zid>
It'd be nice if someone could sort of.. standardize on mmap and inb oub or whatever names at least
<zid>
that's my major pet peeve with the wiki
Oli has quit [Quit: leaving]
* kazinsal
cackles and a finger on the monkey’s paw curls
<kazinsal>
Wish granted; NT naming conventions are standard going forward
<klange>
Imagine if the wiki was all a Literate Programming OS.
<GreaseMonkey>
...ok, found a doc in vgadoc4b.zip which says "The entire S3 family are basically 8514/As with a VGA front-end." and yeah that seems to be the case ish
<GreaseMonkey>
and yes a literate programming OS would be sick
Oli has joined #osdev
<GreaseMonkey>
...this doc unfortunately does not elaborate on the Trio64-specific commands
mahmutov has quit [Ping timeout: 256 seconds]
<GreaseMonkey>
also it seems that the rectangle fill commands were combined into one command on the Trio
<zid>
I wouldn't mind it looking like windows kernel code as long as it was consistent, that's my main gripe
<Belxjander>
zid: from what I have heard... Windows development had a manager team and various programming teams for specific parts
<Belxjander>
the only commonality was how the parts talked to each other
<Belxjander>
so don't expect anything consistent once the person who wrote the code changes
radens has joined #osdev
<radens>
dumb question: the docs for the arm register MPIDR_ELx say this about the Aff0 field:
<radens>
Affinity level 0. The level identifies individual threads within a multi-threaded core. The Cortex-A75 core is single-threaded, so this field has the value 0x0
<radens>
Is this a reference to hyperthreading? Are they saying Aff0 is the hyper-thread id within a physical core, and that the a-75 is not hyper-threaded so it will always be zero?
<bslsk05>
developer.arm.com: Documentation – Arm Developer
<j`ey>
hyperthreading/SMT
<Belxjander>
hrmmm
Burgundy has quit [Ping timeout: 252 seconds]
<radens>
Okay, so imagine I just want to use this as an index into an array of per-core data. With the A-75 I can just shift these bits off and continue with my day, but with some future core there may be hyperthreading. But in a big little world it's possible that some of the cores would have hyperthreading bits and others wouldn't
<radens>
which mean my array would have holes in it wasting space
<j`ey>
yes
<Belxjander>
radens: then do an array of pointers and only allocate entries that are valid...
<Belxjander>
therefore limiting the space?
<Belxjander>
and you can then do a list/array of per-core data and vector into it from the array
<Belxjander>
it also means you can close any gaps to being "pointer" sized instead of larger
* Belxjander
is dealing with that kind of setup in writing an XHCI USB3 device driver for AmigaOS...
<Belxjander>
still need to finish out the init routine for Command and Event rings
<Belxjander>
I've just done the Device/Slot/EndPoint descriptors setup
<Belxjander>
instead of this "DeviceContext32" and "DeviceContext64" with "union DeviceContext" setup...
sdfgsdfg has quit [Quit: ZzzZ]
<Belxjander>
I'm allocating a 32byte header... followed by "SlotContext" and an array of 32 "EndPointContext"s with 64bytes of a Tail reservation...
<Belxjander>
so 32bytes * 36 entries for each "ExtendedDeviceContext" spanned out as an array of 256 for the whole setup
<Belxjander>
this means I put the "ExtendedDeviceContext->SlotContext" address into the array for reference...
<Belxjander>
and optionally skip the first EndPointContext that follows the SlotContext based on 32bit/64bit selection
ElectronApps has joined #osdev
<Belxjander>
using a simple test & increment for "ExtendedDeviceContext->EndPointContext[0]" to use the "ExtendedDeviceContext->EndPointContext[1]" address instead
<Belxjander>
for the AmigaOS memory handling... this works and lets me handle "ExtendedDeviceContext" structures in a linked list arrangement
pretty_dumm_guy has joined #osdev
sonny has joined #osdev
sonny has quit [Ping timeout: 256 seconds]
MiningMarsh has quit [Ping timeout: 256 seconds]
<radens>
Is the osdev wiki down right now?
<immibis>
it's just pining for the fjords
<klange>
Yes, the previous issues have escalated to a whole server outage so the wiki is dead as well.
<zid>
weirdly, so is my left foot, completely dead
<zid>
hopefully both will sort themselves out
srjek|home has joined #osdev
Alpha2023 has joined #osdev
srjek has quit [Ping timeout: 252 seconds]
pretty_dumm_guy has quit [Quit: WeeChat 3.3]
sonny has joined #osdev
<Alpha2023>
o/
<zid>
You're not due for another year and a bit sorry
<radens>
I'm pretty damn sure I'm not in thumb mode or anything weird. I'm just entering userland for the first time for a new process for the third time and boom.
<Mutabah>
radens: Remember that IP is off by an instructi on when there's a fault
<Mutabah>
Although... that's a really round ELR
sdfgsdfg has joined #osdev
<radens>
Mutabah: by off by an instruction do you mean that the fault is caused by elr_el1+4 or elr_el1-4 ?
<Mutabah>
-4 ... usually
<radens>
Because if it's -4 I might be doing something weird and attempting to execute before the beginning of my code?
<radens>
but I should get a translation fault, right??
<Mutabah>
yeah, that's what feels strange
<radens>
I diff'd info registers from entering userspace for the first time for the faulting process and a not faulting process and the only difference was in SP_EL1 and TTBR0_EL1 (different process different kernel stack and address space)
<Mutabah>
actually.. I think with exceptions it's accurate
<Mutabah>
doesn't explain why it's a UD
<radens>
accurate?
<Mutabah>
I.e. ELR is the faulting instruction
<radens>
oh okay, yeah that's what I expected
MarchHare has joined #osdev
[itchyjunk] has quit [Ping timeout: 252 seconds]
ravan has joined #osdev
[itchyjunk] has joined #osdev
sonny has joined #osdev
sonny has quit [Ping timeout: 256 seconds]
[itchyjunk] has quit [Remote host closed the connection]
sonny has joined #osdev
sonny has quit [Client Quit]
Alpha2023 has quit [Remote host closed the connection]
sonny has joined #osdev
YuutaW has quit [Ping timeout: 252 seconds]
sonny has quit [Quit: Client closed]
<radens>
Mutabah: in case anyone else shows up with that issue, ask them if they've invalidate their tlb properly.
* Mutabah
is away (Out)
<radens>
I kinda skipped tlb invalidationg figuring 1. in an emulator it wouldn't matter. and 2. in a single core system it wouldn't matter
zaquest has quit [Remote host closed the connection]
Jari-- has joined #osdev
<Jari-->
morning from Finland
zaquest has joined #osdev
the_lanetly_052_ has joined #osdev
<geist>
radens: it matters in single core
sdfgsdfg has quit [Quit: ZzzZ]
<geist>
radens: in that trap, what was SP set to before the instruction?
<radens>
at eret it was set to like 0x3000 or 0x2fff0 or something, I don't remember
<radens>
For the user sp_el0
<radens>
The kernel sp was the trap frame, I checked
<geist>
well for a second i was thinking it was a misaligned SP, but that would be a different exception
<geist>
so actually not real obvious what's going on there
<radens>
all of the sp's were aligned, I checked for that
<geist>
so unless it's a bad TLB. also could be a unsynced data/instruction cache issue. did you just fill in the page with new data?
<radens>
I just tore down a page table for the first time
<geist>
and you flushed the tlb right?
<radens>
I assumed that changing TTBR0 flushed the tlb
<radens>
I'm guessing it doesn't because adding the tlb flush made that problem go away
<geist>
no
<geist>
reloading it absolutely does not
<radens>
(but not the latent memory corruption lurking)
<radens>
I thought reloading cr3 flushed the tlb?
<geist>
that is x86. this is arm
<geist>
those things do not apply to arm
<radens>
ya bad assumption on my part ofc
the_lanetly_052_ has quit [Ping timeout: 256 seconds]
doppler has quit [Ping timeout: 265 seconds]
GeDaMo has joined #osdev
sdfgsdfg has joined #osdev
Burgundy has joined #osdev
mahmutov has joined #osdev
<geist>
as far as whether or not TLB flushes do anything on emulators, like qemu when not using kvm. maybe?
<geist>
i never actually looked into it, but i would not be surprised if they dont have a translation cache to assist lookups
<geist>
and use TLB shootdowns in the usual way
<geist>
may even be worse: it might have esssentially an infinitely large TLB
<geist>
or at least many time the size of a 'real' one
the_lanetly_052_ has joined #osdev
<j`ey>
radens: is your stuff public?
<geist>
and for arches where the i and d cache aren't synced up like ARM they can even avoid having to toss old JITted sequences of code when the data cache is written to because
<geist>
actually now i'm kinda curous how QEMU tracks their jitted sequences
<geist>
if you treated it basically like a vipt cache and only really toss jitted sequences when the cache and/or TLB is cleared for the range in question you could hold onto translations, even across context switches
<geist>
because ARM has the ASID stuff
<geist>
vs x86 where i presume it has to dump the jits between context switches
<moon-child>
i/d$ isn't guaranteed to be synced perfectly in x86 either. If you wanna do self-modifying code you have to jump to it directly or have a fence
mahmutov has quit [Ping timeout: 252 seconds]
<moon-child>
or--I think there's another condition under which it's ok but forget what
<geist>
yah but since you can't explicit flush te icache like you can on arm then it's probably just a condition the x86 jitter/emulator has to deal with to detect a collision
<geist>
but it can delay it to a fence/branch out of block i guess
<geist>
whereas on ARM you can define it as undefined until the code explicitly flushes it, thus avoiding have to worry about it
* moon-child
nods
<geist>
actually just had a thought that i should really actually look into this. i've noticed in general that fuchsia runs slower and slower on QEMU w/TCG on ARM (TCG being 'not running on KVM but jitted')
<geist>
and i vaguely remember we tightened up the i&d cache syncing a while back to be super conservative and generally dump the entire i cache (via a dedicated instruction) when setting up new code pages
<geist>
on real hardware it wasn't that noticable, since the size of the L1 i cache is not that big so the cost isn't immense
<geist>
but... if it actually causes qemu to dump everything its jitted up until then then it may actually cause far more damage for the emulator
<kazinsal>
yeah, flushing like 8K of icache on a single core isn't that hard
<kazinsal>
QEMU TCG is... weird, though
<geist>
yeah i've always wondered precisely how cache/TLB/jit traces are tracked/emulated/ignored
<geist>
and it's possibly per arch
<geist>
guess that's an action item.
<kazinsal>
"Correct translated code invalidation is done efficiently by maintaining a linked list of every translated block contained in a given page. Other linked lists are also maintained to undo direct block chaining."
<geist>
physical or virtual page?
<kazinsal>
that's all there is in the TCG document about invalidating icache in case of translated code invalidation
<geist>
and can that survive context switches (and on what arch if yes)
<geist>
ah so they may also conflate cache and TLB translation too into a single level
<geist>
so may effectively be acting like a 4K cache line
<geist>
yah i think the way to debug this is to start with the code and follow that thread from the place where it actually emulates the instructions
<kazinsal>
I'm wondering if you need to execute an explicit cache line invalidation on something in that page to get QEMU to kick it out of the TLB and then re-interpret it with TCG
<geist>
exactly
<geist>
or a TLB flush of the same page one way or another, if it's all virtually tracked
<kazinsal>
it all seems kind of roundabout, but in retrospect it's kind of expected considering the origins of qemu
<geist>
since ARM has ASIDs it doesn't have to dump them on a context switch too
hbag has quit [Quit: Ping timeout (120 seconds)]
MarchHare has quit [Ping timeout: 252 seconds]
mahmutov has joined #osdev
AmyMalik has quit [Quit: Bye Open Projects!]
AmyMalik has joined #osdev
mahmutov has quit [Ping timeout: 256 seconds]
m3a has quit [Quit: leaving]
Jari-- has quit [Ping timeout: 256 seconds]
<sortie>
<kazinsal> I'm more and more on board with sortie's "osdev foundation" idea every day
<sortie>
Heck yeah
<sortie>
Contain those anomalous operating systems
<sortie>
<klange> Just as long as we don't seel the name "osdev" to some Korean prince to run a conference...
<sortie>
I... do.. have an IRC network... I could sell out
<kazinsal>
Segfault. Compile. Perfect.
<sortie>
:D
pretty_dumm_guy has joined #osdev
the_lanetly_052 has joined #osdev
sdfgsdfg has quit [Quit: ZzzZ]
the_lanetly_052_ has quit [Ping timeout: 256 seconds]
Starfoxxes has quit [Ping timeout: 268 seconds]
sdfgsdfg has joined #osdev
<j`ey>
feels like cheating when im adding printfs in qemu to figure out whats wrong with my GIC code
Starfoxxes has joined #osdev
<zid>
a bit, but I'd do it every time
<zid>
I debugged the e1000 driver to figure out how it expected the head/tail to work, my two docs conflicted :p
<j`ey>
kinda weird, but I figured out that if you mask interrupts, you don't get interrupts
<j`ey>
:|
<zid>
strange
<j`ey>
the interrupt was coming tbrough as a FIQ, not an IRQ, and I only unmasked IRQs
<j`ey>
that was kinda anticlimatic, but at least it's working now
<Belxjander>
Whats an FIQ?
<clever>
Belxjander: fast irq
<clever>
its a seperate vector in arm, and it banks a number of registers
<clever>
so you dont have to save/restore them
<j`ey>
doesnt do that on arm64, which is what im working on
<Belxjander>
so basically a second form of MPU Interrupt with extra features so the codepath is "quicker" to start?
<clever>
yeah, but only quicker on arm32
<clever>
its also at the end of the vector table, so you dont need a jump
<j`ey>
it's mostly used on arm64 for secure mode stuff
<clever>
for arm, the interrupts just set PC
<clever>
and the vector table doesnt give enough room for code
<j`ey>
linux only started using FIQ at all because the Apple M1's timer uses FIQ for some reason
<clever>
so each slot must be a jump opcode, to go somewhere with more room
<clever>
j`ey: rpi linux also used fiq for the dwc host mode
<clever>
due to the dwc lacking certain features, the host must do a task at 8khz, any time its waiting for something from usb
<j`ey>
clever: rpi linux for arm32 you mean?
<j`ey>
I meant arm64 linux only just started to use fiq
<clever>
yeah
<clever>
ahh
<clever>
i dont know what arm64 linux rpi does
<Belxjander>
well the only things I am caring about right now are the Command and Event Queues (TransferRingBuffer) handling for XHCI USB3 operations right now
<j`ey>
clever: M1 cant run 32bit code :P
<clever>
j`ey: even in EL0?
<Belxjander>
looking at the dgos-master/kernel/device/usb_xhci.cc code for it... but the posix "mmap()" calls and alloc()/free() logic just ... doesn't read very well at this point for me
<j`ey>
clever: correct
<Belxjander>
I have 4K set aside for each already... just need to actually format out each TRB for Commands and Events to use it from what I can tell... that part is not as easy to read though
<Belxjander>
any other USB3 XHCI driver implimentations floating around for comparison?
<klange>
As me again next year.
<klange>
Ask*
<Belxjander>
ahhh well I was hoping to get past this init part before January though... ahh well
sdfgsdfg has quit [Quit: ZzzZ]
xing_song has quit [Read error: Connection reset by peer]
xing_song has joined #osdev
Arthuria has joined #osdev
<zid>
got my day 5 stars in aoc.. wish I had drawn a line more recently than the 80s
<zid>
90s*
Arthuria has quit [Ping timeout: 252 seconds]
Oli has joined #osdev
gog has joined #osdev
<zid>
heya gog
<zid>
partaking in advent?
<gog>
nope we do a pagan thing for solstice
<gog>
basically begging the sun to come back
<gog>
works every year
<j`ey>
gog: advent of code zid means
<gog>
oh
<zid>
surprised you hadn't seen its name in the past few days and clocked what I meant, sorry
<gog>
also no
<zid>
Need more idiots to talk about it with, randomly people in my haunts aren't this year
<gog>
i'm the wrong idiot
<zid>
got one person at least who's doing it, but they're spotty about being around
mahmutov has joined #osdev
Jari-- has joined #osdev
<Jari-->
hi whats up
k0valski18 has quit [Quit: Peace out !]
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
sonny has joined #osdev
sonny has left #osdev [#osdev]
<junon>
klange is doing it pretty diligently I thought?
<junon>
I only did day 3 because everyone said it was confusing af.
<zid>
day 3 wasn't really confusing, but it was definitely the hardest thing they've set so far.
<zid>
It's what makes the pattern in the christmas tree though, hard levels mixed with easier ones
<zid>
That and news bumps
<zid>
klange is on a very very different timezone to me
<zid>
and I don't understand the weird languge he's using
<junon>
english?
<j`ey>
kaurko
<junon>
OH you mean the coding language
<zid>
surprisingly :P
<junon>
It's python
<junon>
just with explicit variable decls
<zid>
tbh I don't know python either. I can cobble together nonsense just barely
<zid>
but I don't use it as a daily driver enough to read people's set map lambda bananas
the_lanetly_052_ has joined #osdev
the_lanetly_052 has quit [Ping timeout: 256 seconds]
dutch has quit [Quit: WeeChat 3.3]
bgs has quit [Ping timeout: 256 seconds]
bgs has joined #osdev
dutch has joined #osdev
doppler has joined #osdev
heat has joined #osdev
ElectronApps has quit [Remote host closed the connection]
gog has quit []
hbag has joined #osdev
the_lanetly_052 has joined #osdev
the_lanetly_052_ has quit [Ping timeout: 256 seconds]
[itchyjunk] has joined #osdev
the_lanetly_052 has quit [Ping timeout: 252 seconds]
xing_song has quit [Read error: Connection reset by peer]
xing_song has joined #osdev
wikan has joined #osdev
the_lanetly_052 has joined #osdev
<j`ey>
overwrote my gic code with gicv3, but just realised rpi + kvm doesnt support v3, so I have to bring back v2 support anyway heh
<zid>
I did that with fastcgi
<zid>
"This would be better with fastcgi" *implements fastcgi client version* "Oh, nobody supports fastcgi"
MarchHare has joined #osdev
CaCode has joined #osdev
cooligans has joined #osdev
<cooligans>
I'm having some problems with stacktracing in my os
<cooligans>
it keeps on outputting the wrong symbol name and offset
<zid>
file kernel.elf in gdb and it built with debug symbols isn't enough?
<cooligans>
I like to run my kernel on real hardware
<cooligans>
gdb dosen't work there
<zid>
it would with a gdb stub, but the point, you're printing your own stack traces?
<j`ey>
sounds like ir
<j`ey>
*it
<cooligans>
sid: how?
<cooligans>
modern computers don't have serial ports
<zid>
they do, and they also have ethernet po`rts
<cooligans>
and I am too early in the osdev journey to implement usb
<cooligans>
and my problem is that the stacktrace function is returning wrong values
<zid>
did you give it the right values?
<cooligans>
yes
<zid>
you confirmed this, printed them etc and tried to correlate them?
<cooligans>
the symbol map is defined weak, because I run the kernel through nm and create a c file with a proper table
<cooligans>
zid: yes, the table is completely fine
<cooligans>
The problem is the function addr_to_name
<zid>
values are fine, table is fine, so you suspect the lookup?
<cooligans>
yes
<zid>
How are you supposing the lookup works, that doesn't look like a lot of code to do u64 space -> u8 or such
<cooligans>
it returns the last entry in the symbol_table, regardless of the values passed
<zid>
normally you'd hash or walk a list or something
<zid>
sounds like it didn't find it then?
<zid>
and you just fell off the end
<cooligans>
yea
<cooligans>
but addr2line suggeests otherwise
<zid>
did you consider testing the method in userspace?
<cooligans>
no, not really
<zid>
It's often a good method
<zid>
just write a little C program with a flat array with some random values in it, and feed them via int main(void) { blah(testvlaue1); blah(testvalue2); }
<zid>
then your debugger will work also
<cooligans>
aah
<heat>
symbols also have sizes
<cooligans>
ok
<heat>
dunno what you're doing with weak there
<cooligans>
I define it as weak
<heat>
why?
<cooligans>
because another file (generated by make) contains all the symbols in a array by the same name
<cooligans>
this more recent array overrides the old one
<cooligans>
providing valid data
<zid>
did you verify they stay valid btw
<cooligans>
yrs
* cooligans
meant yes
<zid>
how are you stopping it vibrating?
<heat>
how do you get symbols without linking them first?
<cooligans>
I link the kernel
<cooligans>
then I gen the file with help from awk,nm,sort etc
<zid>
like, you link it all once to find the offsets, then relink it with diff data, and pray everything stays where it 'should' be?
<cooligans>
yeah
<j`ey>
linux does that somehow
<zid>
I guess if the arrays are the same size it's highly likely at least
<zid>
Depends on the cart, but the cart ram is the cart ram, whether it's persistant (battery backed, permanent storage) is up to the cart
<gog>
pff
<heat>
but you said you were going to do it
<heat>
so do it
<heat>
i'll pay you in exposure
<zid>
please don't expose yourself to gog
<gog>
i've already been exposed enough
<zid>
that's my job
<zid>
There's a gameboy channel on the emudev discord and a gameboy dev discord too fwiw
* bauen1
double checks that this is #osdev
gareppa has joined #osdev
gareppa has quit [Remote host closed the connection]
m3a has joined #osdev
<catern>
hm, someone told me that the virtual-memory doubly-mapped-ring-buffer trick has some slight performance overhead on x86 because there's overhead of mapping the same physical memory twice, anyone know about that?
<clever>
catern: ive not head of that overhead, but i only learned of that trick maybe a week ago
wootehfoot has joined #osdev
ss4 has joined #osdev
DanDan has quit [Read error: Connection reset by peer]
grange_c8 has joined #osdev
bgs has quit [Ping timeout: 256 seconds]
grange_c has quit [Read error: Connection reset by peer]
grange_c8 is now known as grange_c
wootehfoot has quit [Ping timeout: 256 seconds]
bgs has joined #osdev
dennis95 has joined #osdev
wikan has quit [Quit: Client closed]
xing_song has quit [Read error: Connection reset by peer]
xing_song has joined #osdev
DanDan has joined #osdev
<geist>
catern: i dont personally know of any overt performance issues with mapping the same page twice on x86. the pages are cached PIPT so shouldn't matter
<geist>
unless there's some sort of L1 VIPT trick that causes the first mapping to evict the second one
<j`ey>
geist: incase you dont read all the scroll back.. I had my gic v3 code working, but group0 interrupts always come in as FIQ (I didnt realise), and I had FIQs masked
<geist>
as in they fired anyway or they were hard coded to be mapped to fiq?
<geist>
if the latter, that may be because one of the upper levels (EL2/EL3) is rerouting group0 to fiq
<geist>
iirc that's generally how it's used: group0 == fiq == secure irqs, group1 everything else that EL1 system wants to do
<j`ey>
the gicv3 spec says that group0 interrupts are always FIQ
<geist>
ah there you go
<geist>
and when secure interrupts are present in the system then EL3 can set a control register (probably HCTLR_EL3) that redirects all fiqs there first
<geist>
and thus no secure irq for you
<j`ey>
I swapped to using group1 now :)
<geist>
it's a pretty hacky solution. i'd kinda hope that armv9 cleaned it up a bit, maybe added something a bit more clear whats going on
<geist>
like, having the ability for the gic to simply say 'this goes to ELx' instead of this roundabout group -> fiq -> EL stuff
<geist>
though i guess it's clean in the sense that the gic doesn't care about EL, it only cares about 2 classes of irqs and its the cpus job to figure out what that means
<j`ey>
no idea if v4 adds anything here
<geist>
iirc v4 and 4.1 are all about hypervisor extensions
<geist>
i think they start adding some more virtualization assist stuff
<j`ey>
ah
<geist>
and also iirc v4.x is a pure superset of v3 so your v3 driver should just work with it
<geist>
but you see what i was talking about with the gic manual not making a lot of sense unless you were already clued in about secure mode and how fiqs are used to do it, etc
<geist>
there's all thsi machinery in the gic that doesn't seem to make any sense unless you understand how it's all supposed to wire together in ARMs model of how that all works
<j`ey>
yeah, definitely isn't a standlone thing
<geist>
and it's almost worse if you have a history with arm and previously used FIQs for the original purpose
<geist>
side note, apparenty apple M1 uses fiqs in the Old Way: they treat it as a second irq level and can use it for things like timers or whatnot
<geist>
since they have no secure mode hardware and no EL3 to route it to, EL2/EL1 is free to use it as a second level irq
<j`ey>
yup, I mentioned that a bit here. Linux had to gain FIQ support just for the M1s
<geist>
yah
<j`ey>
probably not going to write an AIC driver, so not too worried about m1 :P
<geist>
that's their interrupt controller?
<j`ey>
yeah
<geist>
makes sense they built their own, why not?
<geist>
for the fuchsia thing FWIW it's fairly easy to rig up your kernel to generate a constant stream of events and most of the work is offline processing it into something coherent
<geist>
the harder part is syncing things up with user space tracing or whatnot if you want it
<geist>
it's much fancier now, but relies on substantial offline processing to try to unifiy logging schemes from multiple things (kernel, user space, etc)
<geist>
i dont know the name of it off the top of my heead, but chrome has a built in timeline style visualizer now that you can basically feed xml data to and it does all the rendering