<doug16k>
radens, in a normal qemu, your A20 is on forever
<geist>
if you're inside uefi then a20 is *definitely* enabled
<radens>
that's what I figure
<doug16k>
only weird config with custom rom ever turns it off
<geist>
and since uefi has to 1:1 map physical, etc it can't be off there
<radens>
Okay, so I'm hitting that print, cr0 is okay, I think I set the lock bit, the a20 ought to be set.
<radens>
How do I peek msrs on bochs?
<doug16k>
bochs rom has A20 on unless you went into seabios menuconfig and explicitly selected A20 default off, and recompiled, then told qemu to use it
<doug16k>
told bochs*
<doug16k>
your code can read port 0x92
<doug16k>
bit 2 will be set if A20 is on
<doug16k>
I just checked bochs code
<radens>
I mean, I don't think it's the a20, but I think I'm setting everything else in that if statement right.
<radens>
I will check that port
<doug16k>
sorry, bit 1
Oli has joined #osdev
<geist>
if you could rebuild bochs you could just add a printf to see where the check fails
<radens>
yeah but then I have to rebuild bochs :P
<doug16k>
bochs has pretty extensive tracing infrastructure. did you enable the vmx traces?
<radens>
doug16k: I did not, tell me more
<doug16k>
or just make cpu one verbose as hell
<doug16k>
do you have a display window?
<radens>
display window?
<doug16k>
bochs - the guest display window
<radens>
I probably don't
<doug16k>
ok 1 sec
<radens>
FYI I'm still on my shitty headless wsl setup
<doug16k>
you get the text menu system at start right?
<radens>
yes I think?
<doug16k>
1-7. 7 is quit. 3 is edit. etc?
<doug16k>
ok go into edit, then Log options for individual devices
<doug16k>
then edit the CPU row, and make it say report report report way more
<doug16k>
instead of ignore
<kazinsal>
install something like vcxsrv and export DISPLAY="0:0"
<kazinsal>
WSL will forward X11 to the X server on Windows
<doug16k>
I asked about display window because with that, at any time, you can just click the "config" button on the toolbar to teleport straight to the log option stuff
<radens>
I don't see a cpu row under the text menu
<doug16k>
getting loads of spam from touching registers and stuff now?
<doug16k>
you have symbols in your bochs right?
<doug16k>
you generate symbols?
<doug16k>
the disassembler is fairly symbolic if you give it symbols
<doug16k>
bochs wants a simple one-symbol-per-line addr<whitespace>name formatted file
<radens>
00916067964d[SYS ] A20: get() = 1
<doug16k>
you can geenrate that from an elf with some objdump sed grep tricks
<radens>
brilliant thanks doug16k
<doug16k>
nice
<radens>
I generate symbols, I do get loads of spam. I can nm my efi pe file and save that to a file and load the output of nm into the bochs debugger. Surprised it works tbh
<doug16k>
neat
<radens>
How can I view the state of the MSR_IA32_FEATURE_CONTROL ?
<doug16k>
uh oh
<doug16k>
how badly do you want to know?
<doug16k>
I don't think you can read an msr in the debugger
<doug16k>
but if you had to, you could find an msr instruction, set $rip=there set $rcx=MSR_IA32_FEATURE_CONTROL and s
<doug16k>
rdmsr instruction*
<doug16k>
and it would clobber rdx:rax
<radens>
that would do it
<doug16k>
I am definitely fixing that in my bochs fork
<doug16k>
same with finding a20 status
<doug16k>
should be info msr [address] that'll even dump them all with, decoded, with names
<doug16k>
and an msr command to set one
<doug16k>
maybe 1 parameter is get, 2 parameter is set, and info msr is always dump all
<doug16k>
should probably have info vmx to do a complete dump of vmx stuff
<doug16k>
it's fun to touch bochs command language. have to touch bison stuff, which is nostalgic :)
<bslsk05>
pastebin.com: <bochs:34> set rip=0x3e5b3bc8<bochs:35> set rcx=0x003a<bochs:36> u 0x3e5 - Pastebin.com
<radens>
Is all 0 a valid value for that msr?
<doug16k>
yes
<doug16k>
table 2-20 Address 3A
<doug16k>
3AH
<doug16k>
should narrow it down better
Oli has quit [Quit: leaving]
<doug16k>
pdf page 4548 in mine. Table 2-2. IA-32 Architectural MSRs
<doug16k>
looks like all zero is fine to me
junon has joined #osdev
<radens>
okay so I the msr to 0x7 (lock bit vmx in smm, vmx outside smm) and set rip to vmxon again and hit a different error, so it must be an issue with my setting of that msr
<radens>
lol yup confused eax and edx in the wrmsr
Oli has joined #osdev
<doug16k>
msb goes on left. sorry :D
<doug16k>
edx:eax is "correct" way to write
<doug16k>
but yeah, eax is low part of 64 bit value
<Oli>
As a brief tangent, I want to comment that in SeaBIOS, the behavior of the seven bit text display attribute is making the background color brighter, while on my hardware, it makes the foreground color blink between foreground and background colors instead.
<doug16k>
Oli, right
<doug16k>
there is a bios call to set that I believe, or just do the I/O yourself
<doug16k>
don't know if it emulates it though. doubt it
<doug16k>
blink sucks
<doug16k>
it became a joke in html
<doug16k>
I wonder what it does nowadays. haven't tried in ages
<doug16k>
nothing happens
<doug16k>
probably a bad idea just in case of epilepsy
<Oli>
Thank you for mentioning about a BIOS call for. I am currently refactoring my bootloader to do work directly rather than using BIOS calls, by looking at code in interrupt vectors. I am yet to find out if there is a scope in which I *must* use a BIOS call in my bootloader.
<doug16k>
no, there's nothing you must use a bios for except getting the memory map and finding out how irqs are wired and the processor ids and stuff
<doug16k>
stuff that you can't do
<doug16k>
in that case I mean mostly ACPI BIOS call
<doug16k>
and finding the ACPI tables
<doug16k>
everything you can do, go nuts. that is why people just know ports off the top of their head. you can just assume a ton on something that is bios booting
<doug16k>
like com1 is "obviously" port 0x3f8, for example
<doug16k>
and PIC is "obviously" at 0x20
<doug16k>
etc
<doug16k>
if efi booting, you can't be making so many wild assumptions
<johnjay>
quick sanity check
<johnjay>
when we talk about bitwise operations like and and or what is the opposite of that
<johnjay>
like when ou're talking about control flow like if, while, do/while, etc?
<klange>
opposite of bitwise? logical
<johnjay>
those are "logical" right?
<johnjay>
ok. i'm reading code and it defines logand as the bitwise and of two numbers. @_@
<klange>
they're the same operations applied to different kinds of arguments
<doug16k>
logical is about a thing being true or not true. bitwise is just doing some operation on each bit
<johnjay>
when you're talking control flow it's also boolean
<johnjay>
at least that's what comes to mind
<johnjay>
i.e. for what expressions will an if/else execute
<klange>
boolean logic :P
<johnjay>
but ok. in this code logical and means bitwise and.
<kingoffrance>
for shifting there is logical v arithmetic
<kingoffrance>
is it something like that?
<geist2>
is this a different language than used to?
<geist2>
or some sort of pseudocode?
<doug16k>
logical operations can short circuit. bitwise operations can't
<Oli>
Thank you for kindly sharing insight of yours about.
<doug16k>
logical can allow it to skip stuff that can't be true
<johnjay>
nope it literally just says logand, and the comment says "compute the bitwise and"
<johnjay>
so i thought i was crazy for a second. XD
<doug16k>
like if you said if (1 || do_hard_math_question()) it wouldn't call do_hard_math_question() because 1 || anything is true, so don't bother evaluating right side
<doug16k>
but if I said if (1 | do_hard_math_question()) it has to call do_hard_math_question()
<johnjay>
i tested it by computing logand(4,6) and it said 4
<johnjay>
so i guess someone just got confused
<geist>
if it's some new language, etc they can make the rules for what they call it
<johnjay>
i guess. if i make a new language and do something stupid at least i should document it
<johnjay>
"define +(a,b) // Compute a minus b"
<Oli>
logand(4,6)=4, since 4=0b100 and 6=0b110: Between them, only bit 2 coincides in being set
<Oli>
Counting bits from 0
dormito has quit [Ping timeout: 264 seconds]
<klysm>
// add two numbers, stack a twice and b as parameters to the next function.
dormito has joined #osdev
<Oli>
Wait
<Oli>
\*I said to myself, please, don't wait\*
<kingoffrance>
logical w.r.t. e.g. filesystems, partitioning type stuff, sometimes means "virtual" as opposed to real, physical, actual. so concurring, another case where "logical" seems opposite or at least another layer than "bitwise"
<doug16k>
looks like armv8 is waking up at ip=0x0
<kingoffrance>
i guess i would be sketchy on naming something bitwise as "logical" even if i had a good reason...too many other uses with opposite sense
<moon-child>
lisp uses logior logxor logand... for its bitwise operations. It is very confusing
<kingoffrance>
^
<kingoffrance>
thats what i suspected
<Oli>
I still have yet to figure out whether the nomenclatures function and method are synonymous in Python slang.
<kingoffrance>
it is some ancient assembly convention :D
<doug16k>
if you define true as -1 (all bits 1) then logical and bitwise are the same thing
<klange>
prefix, infix, postfix, all equally powerful - and in fact the bytecode form is essentially all postfix operations
<klysm>
agreed.
<doug16k>
is pflash1 a file mapping of the nvram? writing there writes the "vars" file?
<doug16k>
as opposed to pflash0 I mean
<klange>
So from my tests, it appears my IPC mechanisms are stable and synchronized properly now; process creation and destruction is still likely unstable, and I left in a workaround that will leak memory but avoid a crash in a known race...
<klange>
I still haven't done squat on the network stack since I built the new bit-banged DHCP client...
<klange>
ToaruOS 2.0 is right around the corner, I swear...
<klysm>
network semantics may need a properly working signal set
<klange>
One little issue I have right now with my current debug set up is that if you plug in the Ethernet but don't run the dhcp client, an unbounded queue of frames fills up until you run out of memory :)
<klange>
(assume there's a talkative network on the other side)
<doug16k>
this appears to be the PCI I/O ports on aarch64 virt vm: 000000003eff0000-000000003effffff (prio 0, i/o): gpex_ioport
<doug16k>
geist, so just frobbing bytes into the base MMIO byte of the pl011 should pop out bytes on first serial?
<doug16k>
if I take it easy I mean
<klange>
oh it crashed; maybe the tty layer isn't totally stable :)
<doug16k>
uh oh, how do I reach something that won't fit aarch64 ldr 19-bit range
farcas has joined #osdev
<doug16k>
`ldr x0,=___initial_stack` seems to work
<doug16k>
does that get the address of the constant or the value of __initial_stack?
<radens>
What's the proper inline assembly for sgdt? Is it `"sgdt ($0)" : "+r"(gdtrptr)`?
<radens>
Is the +r constraint right?
<doug16k>
memory operand
<doug16k>
percent
<doug16k>
that would work though if you use a pointer
<doug16k>
fix the $
<doug16k>
+r is a lie
<doug16k>
change that to : : "r" (gdtrptr)
<doug16k>
it won't change r
<doug16k>
needs a memory clobber too
<doug16k>
change to : : "r" (gdtrptr) : "memory"
Oli has quit [Ping timeout: 272 seconds]
<doug16k>
if you read or write any memory operands, you need a memory "clobber"
<doug16k>
just tells flow analysis "don't be cute, you won't see what I am accessing"
<doug16k>
"if you were assuming nobody loads a bunch of those stores that just happened, stop that, I'm going to read them"
<doug16k>
"if you thought you already know all the memory values, stop that, I probably wrote something that you can't be sure I didn't write"
<doug16k>
you would think that if you stored a bunch of stuff to an array, and passed the address of the array to asm, *surely* that would make it know you use the stores to that array without "memory". wrong.
<doug16k>
it'll happily throw away all the dead stores and pass you the address of the uninitialized array
<doug16k>
it will be proud about how many instructions it avoided executing
<doug16k>
modern compilers try to throw away your entire program, we just corner it into including some code
<doug16k>
well, my aarch64 rom makes it into the compiler code then quickly goes off the rails
<doug16k>
is -march=armv8-a ok, or should it be -mcpu=armv8-a
<doug16k>
both?
<doug16k>
ah I see, mcpu sets arch and tune
farcas has quit [Ping timeout: 272 seconds]
srjek has quit [Ping timeout: 272 seconds]
<doug16k>
ok I see, ldr x0,=___whatever_symbol just instantly puts __whatever_symbol in x0
<doug16k>
something seriously wrong with aarch64 debugging
<doug16k>
u command (unassemble) advanced to next instruction
<doug16k>
it stepped too
Oli has joined #osdev
<doug16k>
aarch64 just takes off on you in qemu debugger
<doug16k>
didn't they teach aarch64 to "sit" and "stay"?
<doug16k>
I am using crappy toolchain though
<doug16k>
I should go grab the one geist's script pumps out, so it's not such a stupid toolchain
<doug16k>
gcc 7.5.0
pieguy128 has joined #osdev
<geist>
yah i have since bumped main to 10.2, but there should be a tag for 7.5.0
<geist>
i have gotten it building 11.1 but haven't pushed it upstream yet
<geist>
doug16k: also i have a bunch o prebuilts on newos.org/toolchains
<doug16k>
no I meant the old one is 7.5.0, should use newer proper cross toolchain
<bslsk05>
newos.org: Index of /toolchains
<geist>
got it
<doug16k>
thanks
<doug16k>
got i386 and x86_64 and aarch64 building
<geist>
re: march vs mcpu, etc
<doug16k>
realized that u means "until". it steps !
<geist>
on arm toolchains in general mcpu will imply march and mtune, but you can also generally override everything with the last one in the list
<geist>
or specify a generic arch with march and it'll pick a generic tuning
<doug16k>
using goofy system compiler for now for aarch64
<doug16k>
made it work
<doug16k>
I got the toolchain script checked out though
<doug16k>
pc=0x200. don't see that everyday eh? :P
<geist>
well.... actually i do a lot
<doug16k>
yeah? wouldn't that be the rom?
<geist>
since that's one of the exception vectors. but that's because i work with arm64 a lot :)
<doug16k>
ah!
<doug16k>
yeah how much space do I need to sidestep
<geist>
the default VTOR is probably pointing at 0
<doug16k>
I did realize it lands in the middle of stuff on exceptions lol
<geist>
and ARM exception vctors are 16 vectors, each 0x80 apart? (or is it 0x100, i foget)
<doug16k>
how far from zero should I jump over?
<geist>
but 0x200 is one of the common ones, i think maybe 'exception taken in current EL level to itself?'
<geist>
well, you can also just reload your vector table
<geist>
VBAR_EL1 is it
<geist>
usually that's basically the first thig you do
<geist>
note VAR must be 10 bit aligned, i believe, or maybe 11? it's an odd offset
<doug16k>
oh cool. the "lidt" analog?
<geist>
basically
<doug16k>
then I don't jump over anything, I moved it out of my face
<geist>
but yeah look into the exception table thing, it's 16 different vectors, each air gapped with 0x80 i believe (thus 16 * 0x80 = 0x800 bytes long)
<geist>
and the cpu just branches to it, so usually the first thing you do in each 0x80 slot is save some regs and branch somewhere else
<geist>
or you can just treat it as a able and have it immediately do a branch out of it
<doug16k>
ah, similar to how my x86_64 interrupt entry points work, mine are 16 bytes each
<bslsk05>
github.com: lk/exceptions.S at master · littlekernel/lk · GitHub
<geist>
'synchronous exception from current EL to itself using SP ELx'
<geist>
basically there are 4 kinds of exception vectors and then 4 different places they could have been from, so total there are 4 copies of 4 vectors
<doug16k>
ah. I think I understand the power up better. exception 0 is reset, and if VBAR is 0 then initial pc=0
<doug16k>
is that what's happening?
<geist>
yah, though i *think* it's decoupled, and reset on the cpu is simple 'put the PC at 0'
<doug16k>
it's taking interrupt zero at powerup?
<doug16k>
ah
<geist>
i dont think it's actually taking an exception
<geist>
since vector 0 is 'syn exception to same EL using SP0' which isn't really whats happening
<doug16k>
ok
<geist>
and the ESR and whatnot isn't populated. i dont think there's a sync exception for 'reset'
<doug16k>
so they just start you in the middle of some exception entry point at the start, and doesn't matter
<geist>
i *think* actually the hard reset address is configurable in verilog, so SOC designers can set it to point at whatever their ROM is and it doesn't have to be zero
<doug16k>
ok
<geist>
but since only EL3 really has to worry about a hard reset, all the subsequent layers (EL2, EL1, etc) are by defiition handed control by software at a higher level
<geist>
which can set everything up (or not) depending on how the software works
<geist>
so EL1 code calls PSCI routine in a higher run level (EL2/EL3 depending on two traps it) to boot secondary cpus, and hands it the start address
<geist>
how the sausage is made doesn't matter to EL1 as long as the firmware sets it up to start at the requested address with the requested arg in x0
<doug16k>
oh ya smp
<doug16k>
will all the cpus come flying in at the entry point smashing the same stack, if I don't do something?
<geist>
so even things like cpu suspend and whatnot are handled in PSCI (in gneeral) so the firmware there can handle parking the cpu, saving its state, and putting it back after waking the cpu out of reset
<geist>
almost certainly, since you're choosing to write EL3 code
lg has quit [Quit: leaving]
<doug16k>
where do I look to see which cpu I am?
<geist>
that is what you're doing right? telling qemu to not run existing firmware and you're in EL3?
<doug16k>
ya I am writing the reset entry point code
<geist>
MIDR_EL3
<geist>
er er. sorry
<geist>
MPIDR_EL3
<geist>
MIDR is the top level 'what type of cpu is this'
<geist>
MPIDR is basically where you read the equivalent of the APIC id
<doug16k>
neat
<geist>
side note, are you sure you're in EL3? I dont know if you need additional switches to enable it
<doug16k>
yeah I think you need to do a thing to make it el3
<geist>
it might be starting you in EL1 or something, and then just pretending EL2 and EL3 doesn't exist
<doug16k>
I remember reading about a switch
<doug16k>
vaguely
<geist>
which is actually valid according to the arch. apple M1 for example just doesn't implement EL3
<geist>
by specifying the -bios it may implicitly do it, but there's otherwise a switch for it. easy enough to find out. just check the PSTATE from info registers
<geist>
it'll tell you what EL you're in
<doug16k>
how do you read that exactly in assembly?
<bslsk05>
github.com: lk/asm.S at master · littlekernel/lk · GitHub
<doug16k>
nice
<geist>
PSTATE is weird. it's a pseudo register made up from a bunch of smaller 'single topic' registers
<geist>
like CurrentEL, etc
<geist>
but it gets packaged up as a single 32bit thing when it's exception time
<doug16k>
I see
<geist>
otherwise you have a bunch of little pseudo registers that represent one or more bits from it that you directly access
<doug16k>
yeah pstate did seem odd
<geist>
kinda nice actually because now you dont have to do a bunch of RMW actions to fiddl ewith pieces of it
<doug16k>
yeah
<doug16k>
probably not cheap fiddling either sometimes
<geist>
so for example disabling/enabling interrupts you're fiddling with DAIF
<geist>
which is basically 4 bits in PSTATE (debug, async exceptions, interrupt, fast irq) disable bits
<doug16k>
daif with those clear and set doorbell thingies
<geist>
right
<geist>
it's really 4 bits within the larger PSTATE register, but they give you little windows into it. so it's really kinda neat
<geist>
when you take an exception though it gets saved into the SPSR_ELx register, and then eret puts it back
<geist>
so which EL are you in?
<doug16k>
sec
<geist>
so here's the big annoying thing: when accessing banked EL registers (ie, say SCTLR_EL1, SCTLR_EL2, SCTLR_EL3) there's no way to specifying 'the current EL'
<geist>
so if you intend for your code to run at an arbitrary EL it's really difficult
<doug16k>
says 0x4
<doug16k>
is that 3?
<doug16k>
should be 2?
<geist>
it's shifted 2, for some reason
<geist>
so i think that means it started you in EL1
<geist>
which makes sense. i think you have to tell qemu to emulate EL2 and/or EL3. *normally* when you boot via -kernel or whatnot it'll start you in EL1, no EL2 present, and a faked out EL3 where if you make PSCI calls it just traps and handles a few of them directly in qemu
<geist>
no actual firmware
<doug16k>
ah, you have to tell qemu to use gic-version=3 and virtualization=true to get el2
<geist>
you definitely have to tell it you want EL2 in that case, i forget the switch
<geist>
yeah that
<doug16k>
on -machine
<j`ey>
and secure=true for el3
<geist>
there's also a way to specify you want EL3 though. lemme see real quick. i saw a how to guide in th.... oh there we go
<geist>
j`ey got it
<geist>
note i think when you do that you'll definitely get the firehose of all the cpus start simultaneously
<geist>
whereas normally if you start in EL1 or so and you let qemu emulate basic PSCI it'll trap everything but cpu 0
asymptotically has joined #osdev
<geist>
no biggue though you can just test MPIDR and let cpu 0 in and trap the other ones
<geist>
be warned: there's a high bit in MPIDR that's set so you have to AND it with a mask before testing against 0
<geist>
i've been personally burned by that once by not reading the docs close enough
<geist>
(or use ubfx to extra the fields you care about)
<geist>
extract
<geist>
anyway, godspeed!
<doug16k>
you gave me a bunch of work to do :P
<geist>
yah dont want to tell you *all* the tricks
<geist>
just the huge pothole you'll probably step in and break your ankle
<geist>
note: unless you really really are a masochist i would not recommend replacing the faked out PSCI firmware
<geist>
it's a different universe in ARM with EL3 and whatnot. think of it as just being an extension of the cpu, not a bios you have to replace
<geist>
be happy having basically full control of the cpu even though there's a higher authority
<doug16k>
I pressed the 'max masochism' button when I passed -bios didn't I?
<geist>
i hoenstly dont know. i think it might simply mean 'put this .bin at 0 and branch into it'
<doug16k>
even the x86 builds have to initialize the bars from zeros :D
<geist>
unclear if it enabled/disabled the faked out PSCI stuff
<geist>
since the virt machine has like 64MB of flash at 0 (ram starts at 0x4000.0000)
<doug16k>
I replaced that
<doug16k>
that is my rom
<geist>
-bios may simply be a shortcut for 'load this .bin file at 0'
<doug16k>
mostly zeros now
<geist>
note that even if i boot with -bios <smoe pointer to UEFI image>, uefi gets loaded at EL2 and there's still a faked out PSCI in EL3
<doug16k>
that is what it does on arm exactly
<doug16k>
on x86 it loads what you said at the top of the bottom 4GB
<doug16k>
so the entry point is always the last 16 bytes of the rom
<doug16k>
on x86
<geist>
so i suspect what *really* turns off the faked out PSCI is 'secure=true'
<geist>
or more precisely it gives you access to EL3 so it can no longer fake out the presence of a firmware living there
<geist>
also note there are ID registers (sort of analogous to CPUID) that tell you which ELs are present on the cpu. i suspect qemu by default says 'EL3 present, EL2 not present, EL1/EL0 present'
<geist>
even though it doesn't directly giv eyou access to running EL3 code unless you specify secure=true
<geist>
it maintains the fiction of a faked out psci
<doug16k>
I got currentel up to 8
<geist>
that's EL2
<geist>
currentel is shifted left 2 for some reason. i forget why. bottom 2 bits are always 0 i believe
<doug16k>
then secure right? let me try that
<doug16k>
got it up to 12
<geist>
yep. there ya go
<doug16k>
what is this sequence?
<geist>
EL3 THE POWER OF GREYSKULL
<maurer>
I gotta go to sleep 30 minutes ago, so I can't give a ton of explanation, but if you repo clone at the Trusty manifest (https://android.googlesource.com/trusty/manifest) we're using the EL3 emulation stuff with TF-A
<doug16k>
I have it at full power now?
<bslsk05>
android.googlesource.com: trusty/manifest - Git at Google
<doug16k>
I can crush the EL below me?
<geist>
12? 0b1100
<maurer>
so you may be able to template some of your emulation stuff off us
<geist>
again the currentel register's current EL is in bits [3:2]
<maurer>
(Specifically look at trusty/device/generic/arm64/project/qemu/
<doug16k>
maurer, thanks
<geist>
huh trusty running at EL3? mind blown
<maurer>
geist: No
<maurer>
Trusty has a SPD we need to test
alexander has joined #osdev
<maurer>
so we run TF-A, with Trusty SPD enabled, which requires EL3 emulation
<geist>
oh oh, i see. yeah
<j`ey>
SPD?
<maurer>
"secure payload disaptcher"
<geist>
makes sense. yah for reasons i wont go into with doug16k right now 'secure=true -> EL3 and the secure mode stuff'
<maurer>
it's an armism for "module which translates/relays SMC calls to appropriate S-EL1 actions"
<geist>
whcih doug16k can mostly ignore for now. EL3 gives him secure mode powers which you can not use if you dont need it
<geist>
yah, and/or BL31
<maurer>
Yeah, I was explaining SPD for j`ey
<geist>
word.
<j`ey>
I havent looked at the secure stuff yet
<j`ey>
Im starting to look at some TPM2 things
<maurer>
It's not that exciting tbh. For the most part it's just "You can map bonus memory, which is protected by hardware specific mechanisms", plus the scary "Nobody thought S-EL1 needed to be stopped from touching EL3 or Normal EL2/EL-1, so it's not
<geist>
yah eally isnt
<doug16k>
it's nice to be able to check that and get it into a known state in my toy rom project
<geist>
aside from the non regularity of current lack of secure EL2, etc (fixed in newer specs) i do like the general nested exception level stuff though
<maurer>
j`ey: Only obliquely. I'm ex-Trusty, and now do Rust-in-Android, which means I'm supporting hafnium from the Rust side of things, and sometimes consult with them from the ex-Trusty side of things
<doug16k>
how gnarly is that reset wakeup?
<maurer>
doug16k: I do not think you want to port TF-A to risc-v
<doug16k>
no my little rom that initializes unlimited secondary-vga displays in qemu
<geist>
loosely speaking in riscv machine mode == EL3, supervisor mode == EL1, user mode == EL0, tere's no equivalent of EL2 (yet)
<maurer>
Ah, OK, that's fine then
<geist>
but the model is roughly the same
<doug16k>
I have i386, x86_64, (partially working so far) aarch64
<bslsk05>
doug65536/qemu-rom - Simple QEMU -bios ROM that initializes PCI and dispi framebuffers on all attached PCI-VGA (0 forks/0 stargazers)
<geist>
the new hypervisor etensions in riscv apparently started with an EL2 style design a-la arm but ended up morphing into an x86 style design
<doug16k>
need to push a lot
<geist>
i am a bit dissapoint that they did that, but so it goes.
<doug16k>
it must be simpler to do x86 way then?
<geist>
i dunno. i haven't sat down to try to grok the riscv thing
<doug16k>
I'd guess they always go simpler route
<geist>
probably more performant in the end i guess
<geist>
well see i figured the ARM route would be simpler: much more software offload to do the VM context switching
<doug16k>
ah
<geist>
just provide another layer, let software deal with switching between guests
<doug16k>
x86 way can be hardware accelerated?
<geist>
but... i may be talking out my ass so i dunno. i haven't read the current version of the hypervisor spec
<geist>
i dont think it's ratified yet
<doug16k>
if there are no flags, then whatever virtualization thing they do gotta be simpler :D
<geist>
yah possble the full hardware context switch is far simpler on an arch with less moving parts
ad__ has joined #osdev
<ad__>
hi all gm
<ad__>
on an sdcard, i see partition table at 1b0. but at start (0) i see an header "fa b8". What is it ?
<Mutabah>
Probably a `jmp` instructions
<Mutabah>
The first sector of almost any volume will contain executable x86 code
<ad__>
mm, so mbr ? shouldn't be a signature in first bytes ?
<ad__>
ah ok thanks, isee, first bytes are just code, signature is @510
FireFly has quit [Changing host]
FireFly has joined #osdev
MarchHare has quit [Ping timeout: 264 seconds]
<doug16k>
ad__, mbr signature is at offset 510: 0x55 0xaa
<doug16k>
ah you already figured it out
<doug16k>
expect a partition table near the end too
<doug16k>
at offset 0x1BE
<ad__>
doug16k, k thanks
<doug16k>
yeah, all the cpus come flying into my rom in el3 config at start
Oli has quit [Ping timeout: 245 seconds]
junon has quit [Ping timeout: 272 seconds]
<j`ey>
doug16k: wheee!
lg has joined #osdev
flx- has quit [Ping timeout: 272 seconds]
junon has joined #osdev
asymptotically has quit [Quit: Leaving]
piotr_ has joined #osdev
dnny has quit [Quit: dnny]
Oli has joined #osdev
<Belxjander>
Anyone here ever play with a BeagleBone or RaspberryPi (original B+) for OSdev stuff?
<geist>
yah
<geist>
i wouldn't recommend it anymore, but about 10 years ago it was the bees knees
<geist>
now the main problem is they're old cores, 32bit, using an old revision of the arm architecture
<geist>
so it's somewhat akin to playing with a 486 or a pentium PC in the PC world. still useful, but old tech
<j`ey>
but unless you have any 'nostalgia' to it, why bother?
<geist>
right, the obvious retort it 'but it's cheap and i can get one easily'
<geist>
but you can also generally get a new one easily and cheaply too
<j`ey>
>:D
<geist>
also from an osdev experience ARM architecture is not exactly like x86: it's not infinitely backwards and forward compatible
<Belxjander>
I already have a BBB sitting here... just want to see if it is usable for anything other than being a slave device with linux on it
<geist>
once you go back far enough you start getting into thins that have changed in more recent designs and thus are literally dead tech
<geist>
BBB is a bit better since iirc it's a cortex-a8 and it's a TI soc, which is very well documented
<Belxjander>
if there is nothing dev wise useful for either to do anything then I'll just slave them as linux devices once I re-install them both
<geist>
cortex-a8s are the very first armv7 core, so they're at least a little bit more standardized and 'modern' than an armv6 core, like the original raspberry pi is
<Belxjander>
the main thing I am interested in at the moment is possibly getting Android on one of them workable...
<geist>
eh... probably nothing modern
<Belxjander>
but that would still need to me work out how to forward the display to the desktop after getting that running
<geist>
you're talking about stuff that's probably an order or magnitude or two slower than current gen ARM socs
<geist>
so keep that in mind
<Belxjander>
geist: not worried about the speed so much
<Belxjander>
as my desktop is a PPC 440EP @ ~600MHz or so
<geist>
se, but android does.
<Belxjander>
other machines in the house are mostly x86/amd64 stuff for my wife
<geist>
trying to run modern android on a thing that's super slow by modern standards is kinda like trying to install NT on a penium. sure. it might work, but it's no fun
<j`ey>
and building android is no fun
<geist>
again. it's still a thing that can run stuff. it's not 64bit, because it's pre-64bit. it's single core, because cortex-a8 was never SMP capable
<geist>
it's running < 1Ghz, etc
Arthuria has joined #osdev
<geist>
so for osdev purposes. it's a 32bit arm core that's functional, but a brand new cheap rpi4 or something is probably 10x as fast if not more and modern and 64bit, etc
<j`ey>
and rpi4 can still run aarch32 :)
<geist>
right
<geist>
ARM tech has moved so much in the last 10-15 years it's like PC x86 tech growth over 30 years compressed into 10
<geist>
so at some point it's just too old to do anything modern with, or at least a new modern thing can cheaply replace the old one
<geist>
gosh just thinking about it. about 2005 was the first of the armv6 cores showing up
<geist>
state of the art for ARM would have been a arm1136 @ 600mhz, maybe 16KB L1 cache, paging mmu, VIPT effective
<geist>
right about then it was suddenly possible to actually run serious multiple-address-space kernels
<geist>
prior to that armv4 and v6 cores (arm920t for example) you could run a paging OS, but it was VIVT so you had to dump the entire cache on every context switch
<geist>
and had serious aliasing problems (couldn't map the same page twice, etc)
<geist>
useful for embedded or simpler kernels, but wasn't really *that* suitable to run linux or bsd or whatnot. you could, but it was slow
<geist>
and lo and behod that was just about when things like iphone and android started to seriously get worked on. suddenly it was possible to actually run a unix (or other paging, MAS OS) on arm stuff. was right when everything exploded in terms of handheld smartphones and whatnot
<j`ey>
and now, here we are, with aarch64 servers :D
<geist>
yah exactly, but 2009 there was armv7 stuff, which standardized a lot of the things like cache architecture, etc. also ARM start punching out cores at a much higher rate. IMO they started being much easier to work with then too. that's when cortex-a* designs came out. also cortex-m which took over the embedded world (or at least a lot of it)
<geist>
then by 2014 or so armv8 was out and 64bit was a thing, etc
<geist>
so teh arch itself has been growing at a pretty fast clip. even going back 10-12 years you're two or three generations of architecture back
<geist>
and of course armv9 was just released
<geist>
anyway, off to bed
<j`ey>
ciao!
<immibis>
i still keep thinking of ARM as the ARM7TDMI in the gameboy advance
<j`ey>
immibis: welcome to 2021!
dormito has quit [Quit: WeeChat 3.1]
GeDaMo has joined #osdev
sortie has joined #osdev
piotr_ has quit [Ping timeout: 252 seconds]
piotr_ has joined #osdev
dormito has joined #osdev
Oli has quit [Ping timeout: 245 seconds]
dutch has quit [Quit: WeeChat 3.0.1]
qookie has joined #osdev
pretty_dumm_guy has joined #osdev
dutch has joined #osdev
flx- has joined #osdev
StaticSaga has joined #osdev
Oli has joined #osdev
nyah has joined #osdev
gareppa has joined #osdev
leo has joined #osdev
leo has quit [Ping timeout: 245 seconds]
ahalaney has joined #osdev
gareppa has quit [Quit: Leaving]
pretty_dumm_guy has quit [Quit: WeeChat 3.2-dev]
mahmutov has joined #osdev
srjek has joined #osdev
piotr_ has quit [Ping timeout: 244 seconds]
MiningMarsh has quit [Read error: Connection reset by peer]
MiningMarsh has joined #osdev
Oli has quit [Ping timeout: 268 seconds]
StaticSaga has quit [Quit: Connection closed]
xenos1984 has quit [Remote host closed the connection]
KillerWasp has left #osdev [YOU KIDDING ME?? YOU KIDDING MEEE???? (PC drinking beer) *kernel panic!*]
gareppa has joined #osdev
<nur>
1993 wow
mahmutov has quit [Remote host closed the connection]
gareppa has quit [Remote host closed the connection]
<nur>
without reading the paper I feel like papers from that time overgeneralize "structure" and ignore implementation-dependent things when measuring performance
<nur>
from the get-go it's 2 different OS's so it's apples and oranges already
<vin>
I believe the strategy used plays a bigger role than implementation details. Assuming both systems are compiled and run similarly - which the authors do.
<vin>
The paper really argues about nonolothic vs micokernels and shows the imporatnce of system performance even amidst optimized user apps.
mahmutov has joined #osdev
<vin>
Assertions such as "OS has less instruction and data locality than user programs" is something I am curious about
<vin>
Some assertions are obvious and hold - demand paging is better than loading the entire program on startup. Mach vs Ultrix.
flx-- has joined #osdev
flx- has quit [Ping timeout: 272 seconds]
<NieDzejkob>
hmm. When I copy my bootsector with dd onto a USB stick, it doesn't persist, even if I `sync` before removing it. But if I copy an image with the bootsector and some dummy sectors afterwards, it works. What are you supposed to do to write reliably?
<GeDaMo>
Maybe you have to write a whole block?
LittleFox has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
<NieDzejkob>
Do you think this behavior is introduced in the Linux kernel or the USB stick firmware?
LittleFox has joined #osdev
pretty_dumm_guy has joined #osdev
Arthuria has quit [Ping timeout: 245 seconds]
<maurer>
NieDzejkob: Did you eject it?
<maurer>
I don't remember the details, but there was a similar issue (albeit with a filesystem in the way) that I saw get resolved by ejecting the usb scsi device
<NieDzejkob>
you're supposed to use eject(1) on USB devices?! TIL
<geist>
if it's not mounted, no activity on it, etc its probably unnecessary, but wouldn't hurt
<geist>
it would at least make sure everything is written back to it, though in my experience linux at least doesn't do delayed writeback of block devices after the last thing has released its handle
<geist>
cant say the same for other unices
<nur>
geist, okay uh, I've appended .size to the end of my interrupt handler but the debugger still has trouble finding the bounds of it
<geist>
possible you need a bunch of .cfi stuff for it to really work
<nur>
.size isr_wrapper, . - isr_wrapper_default
<geist>
but i have honestly no idea. i never use the debugger
<nur>
oh how do you debug the thing then
<geist>
without a debugger
<geist>
all the other multitude of ways you can debug things without source level debugging
<nur>
I have some really weird behaviour
<geist>
in this case, for example i'd probabl just use qemu or bochs's built in mechanism to step it through
<geist>
or put some infinite loops in the code and stop and inspect the state
<gog>
you can also set disassemble-next-line on
<gog>
and stepi
<geist>
right
<geist>
and look at the register state, etc
<nur>
gog : is that a qemu thing?
<gog>
it's a gdb thing
<nur>
gdb is having trouble stepping into my asm
<nur>
:(
<geist>
nur: hmm, actually that .func thing i dunno what's up
<geist>
does it actually emit a symbol named isr_wrapper?
<geist>
if you look at your binary with nm does it show a valid size for that symbol?
<gog>
also the symbol names don't match, that might be causing gdb to be confused
<nur>
oh crap it doesn't
<gog>
.type isr_wrapper_default, @function
<geist>
yah what's up with that?
<geist>
right, i usually use the .type thing. .func might do it too, but i've never seen it
<gog>
ok wife wants to hang out bbl possibly
<nur>
q00100904 T isr_wrapper_default
gog has quit [Quit: bye]
<geist>
hmm, i forget. one of nm, size, objdump, etc gives you the length of the symbol too
<geist>
but yeah get those names all lined up
<geist>
also, it's possible everything is fine but your IDT is set up wrong and the IP is at the 'wrong' spot so gdb doesn't know what it is
<geist>
is the IP correct?
<nur>
I think so
<nur>
hang on
<nur>
do I call the function isr_wrappr_default too
<nur>
as well as the label
<geist>
up to you
<geist>
get everything to line up
<nur>
okay doing that now
<nur>
let's see if that works first
<geist>
right, also indeed. change one thing at a time
<kazinsal>
test, fix, recompile, repeat
<nur>
Single stepping until exit from function isr_wrapper_default,
<nur>
which has no line number information.
<nur>
Cannot find bounds of current function
<nur>
sigh
<geist>
probably need some more .cfi stuff i bet
<geist>
*this* precisely is why i dont bother with source level debugging
<kazinsal>
reminds me, I need to work on improving my debugging config system
<geist>
it works pretty well in user programs, but as soon as you get to low level kernel stuff, relocatable binaries, debugging assembly, etc it starts to get tricky and annoying and requires more work than i'm willing to use
<nur>
fair
<nur>
time to rethink this
<geist>
some folks plow through it, doug16k knows a bunch more about it
<geist>
but like i said i'm the least helpful person for getting gdb working since i never use it
<nur>
thank you anyway :)
<nur>
man when did it become 4am
<nur>
maybe it's time to give it a rest
<geist>
whoa! yeah and see ifyou cna catch doug16k next time
<geist>
but... also next time we can try to just debug the problem you're tryng to debug too
<geist>
without gdb, i'm up for that
<nur>
thanks geist!
<geist>
cheers!
<nur>
cheers
asymptotically has quit [Quit: Leaving]
mahmutov has quit [Read error: Connection reset by peer]
mahmutov has joined #osdev
GeDaMo has quit [Quit: Leaving.]
wovixo has quit [Quit: Leaving]
dormito has quit [Quit: WeeChat 3.1]
dbittman has joined #osdev
SwitchToFreenode has quit [Remote host closed the connection]
KREYREEN has joined #osdev
jjuran has quit [Ping timeout: 272 seconds]
jjuran has joined #osdev
alexander has quit [Ping timeout: 264 seconds]
dormito has joined #osdev
mctpyt has joined #osdev
flx-- has quit [Ping timeout: 268 seconds]
ahalaney has quit [Quit: Leaving]
dennis95 has quit [Quit: Leaving]
Oli has quit [Ping timeout: 252 seconds]
gog has joined #osdev
Oli has joined #osdev
* gog
meows
* moon-child
pets god
* gog
purrs
* moon-child
scratches under god's chin
* gog
bites
<doug16k>
nur, do you assemble assembly source with gcc?
<doug16k>
or directly with as?
<doug16k>
if with gcc, add this: -Wa,-g if as, add this: -g
<doug16k>
"step" means step to next line, so if it doesn't have line number information, it "can't find the bounds of the current function". you can force through that with si "step instruction", or assemble with debug info so there are line number records
<doug16k>
if you want to force it to show you where you are, do this: x /10i $eip
<moon-child>
can also enter tui mode
<doug16k>
it will disassemble the next 10 instructions that would execute if it continued
<moon-child>
C-x a
Arthuria has joined #osdev
<moon-child>
'la n' and 'la p' a bit and see what catches your fancy. ('layout next' / 'layout previous')
<doug16k>
yeah you can "layout asm" if you want to unblind yourself in stuff with no debug info, and use si
<doug16k>
if you have a lot of stuff with no debug info, you can use `set step-mode off` and it will make it stop at lines where it has no clue what it is, rather than stepping until it lands at a recognizable place
<doug16k>
...during a step
<gog>
ooh that's actually a useful feature for me
<gog>
TIL
<doug16k>
noprmally step-mode off means "don't bother me with instructions in the prologue that aren't covered by debug info"
<doug16k>
it will just step a few times and get to a proper place
<doug16k>
that probably isn't what you want when debugging something with spotty info or that could jump to weeds
<doug16k>
oops I reversed the polarity: set step-mode on means make it stop at the first sign of trouble. off is the usual behaviour that means step until you know where you are
<doug16k>
know where you are in source file/line
<doug16k>
it always knows the program counter when stepping
<doug16k>
obivously :)
<doug16k>
that is probably the most important value for a debugger to know about the inferior, by far
<doug16k>
you can just blurt out a few registers you think it ought to know in a stop reply. if the stub is smart is just proactively tells gdb the pc and sp and probably frame pointer in the stop packet
<doug16k>
saves a round trip for it to tediously get it every step
<clever>
doug16k: random thought, what if the stub stores a complete snapshot of the registers at every stop, and reports a diff?
<doug16k>
you could do that, gdb wouldn't be inferring that you didn't change the ones you didn't mention though
<clever>
it would maybe need another feature flag, for the stub to report that its doing a diff for you, and any not mentioned are unchanged
pretty_dumm_guy has quit [Quit: WeeChat 3.2-dev]
<doug16k>
usually you only send the ones that it needs to know to decide whether to step again
<doug16k>
if the stub is really smart, it will have range stepping and offload that decision to the stub
<doug16k>
gdb can tell the stub, "instruction step, but, if it is within here to here range, just step again without telling me about it"
<clever>
ah
<clever>
that sounds like the leave command
<doug16k>
so it can just give the range of all the crap up to the next line and say, step all that
<doug16k>
but if it escapes that region somehow and goes to some weird place, it stops there
<doug16k>
it's not equivalent to placing a breakpoint on next line and saying go
<clever>
i always thought it was just setting a regular hard breakpoint
<doug16k>
nope, way more careful than that
<doug16k>
tons and tons of round trips in qemu
<doug16k>
each instruction
<doug16k>
it doesn't care because localhost is a bazillion bits per second
<doug16k>
and speed of light like latency :P
<doug16k>
if you used qemu over serial, step would be quite sluggish
<doug16k>
I had to add range stepping in my gdbstub for really serial debugging, to make it not suck
<doug16k>
went from sucks to fairly peppy
<doug16k>
debugger line-step does it with a spam of singlesteps
<doug16k>
instruction steps
<doug16k>
finds all the instructions between this line and the next line, and tells gdb, instruction step forever until pc is outside here
<doug16k>
next (step over) is likely a temporary breakpoint on the next line and a continue
<moon-child>
that couldn't work because you might recurse
<moon-child>
i.e. end up at the same ip but in a different stack frame
<doug16k>
yeah
<doug16k>
technically it means keep continuing until this is the current stack frame too
<doug16k>
er, keep continuing until the top of stack is the same one as it was when next was issued or below
<doug16k>
I am not sure about exactly when gdb steps or makes breakpoints or exactly how it handles returns and stuff, I know it does it very well though :)
<doug16k>
a lot of it boils down to stepping a lot and deciding what to do all over again each step
<doug16k>
clever, yeah, the remote protocol is extremely extensible. you could make up a capability if you added it to gdb and mention it in stub replies
<clever>
doug16k: does that also apply to a protocol between gdb and openocd maybe?
<doug16k>
yes
<clever>
so multiple things can benefit from such an upgrade, nice
<doug16k>
that's that weird somehow-closed source gdb?
<clever>
not that i know of
<doug16k>
oh sorry ya not that
<doug16k>
do they have a modified gdb?
<clever>
nope, ive used it with stock gdb
<doug16k>
do they get you to load python or source something with source or -x?
<doug16k>
you could totally make stuff up with the `maintenance packet` command
<clever>
they do let you load tcl scripts
<doug16k>
you can just send whatever you want and gdb says sir yes sir and sends it
<doug16k>
then gdb shows the reply and prompts for another command
<clever>
the tcl scripts deal with wiring together a debug protocol (jtag), a driver (rpi gpio bitbang), and a core debugger (cortex-a7 for ex)
<bslsk05>
github.com: openocd/rp2040.c at rp2040 · raspberrypi/openocd · GitHub
<clever>
which is over here
<clever>
it uses the debug port to shove buffers into ram, and then force the cpu to execute self-flashing routines in the boot rom
<clever>
so the chip ultimately handles flashing itself
<doug16k>
you like hyper-specific stuff eh?
Bonstra has joined #osdev
<doug16k>
I gravitate toward stuff for which you can make generic drivers
<clever>
i believe you could add that register diffing to openocd, in a generic fasion
<clever>
then it would apply to every core it can debug
<doug16k>
I suppose this might be on tons of those so it is "generic" in their world
<doug16k>
ah
<doug16k>
you are likely to be using a sluggish connection on those too
<doug16k>
embedded things
<clever>
my rough understanding, is that you have the shared gdb protocol layer, then per-arch and per-core drivers, then protocol drivers, then hw drivers for a specific debugger
<doug16k>
just proactively providing pc sp fp gets you most of the way there
<clever>
yeah, when using a case like 1mhz SWD, it could be costly to dump the entire state from mcu->openocd, diff it, then send a minimal state over tcp
<doug16k>
just making sure it does that would be a good boost, if it doesn't
<doug16k>
qemu doesn't. I added that in a patch. it saves a round trip every step
<doug16k>
very easy to forget/miss that you can give it some important registers in a stop packet
<doug16k>
it might naively just say "stopped!" and that's it
<doug16k>
then gdb has to get registers
<doug16k>
every time. it MUST have pc
flx-- has joined #osdev
<doug16k>
it doesn't have the slightest clue what to do without pc
<doug16k>
every step might to absolutely anything
<doug16k>
nop could go flying into a fault, an irq using corrupt thing
<clever>
that reminds me, of the smp bugs i had on the pi2
<clever>
during linux bootup, right after the mmu is enabled, and it enters the main bulk of C code, it would crash hard
<clever>
the cause, printk uses a mutex to manage exclusive access to the dmesg ringbuffer
<clever>
smp was disabled, so mutex opcodes where an exception
<clever>
the vector table hasnt been initialized yet, so the exception jumped off into uninitialized ram
<doug16k>
ya my aarch64 rom did that a bit. all threads went flying into the entry point and they all used the same stack, and I got 4 stops in the debugger because gdb was all confused by all four threads using the same stack frame lol
<bslsk05>
github.com: qemu-rom/entry.S at master · doug65536/qemu-rom · GitHub
<clever>
ive also had bugs, because i assumed the c code never returns
<clever>
i now have a `b .` in my start.S, to catch if it does
<clever>
but your idle_trap is better, since it goes into a low power mode
<doug16k>
yeah, being right after bl main is not a coincidence :)
<doug16k>
if that returns it idles too
<doug16k>
when that returns I should say. it returns
<doug16k>
I can't help but think of that "me, me, me, me, me" part in the matrix in this rom project. in this everything is *really* my fault
<doug16k>
*everything*
<doug16k>
it executed nothing but my instructions
<doug16k>
and I instantiated the environment it executes in, so I am even responsible for the presence or absence of everything in the machine
<doug16k>
sometimes I wonder if I do this stuff just to get away from libraries I have to deal with in paid work
<doug16k>
I hate libraries
<doug16k>
they usually either have vague or nonexistent documentation, or there are so many versions of it that you are bombarded with stuff that doesn't work when attempting to learn it
elastic_dog has quit [Quit: elastic_dog]
<doug16k>
I'm a zero-library js developer, when possible
elastic_dog has joined #osdev
<geist>
oh yay re the arm bits
<doug16k>
yeah it gets pretty far. not 100% yet. I need to stop playing around with this system aarch64 toolchain and point it at a proper cross one that is 11+
<doug16k>
I found the PCI I/O window
<doug16k>
I poke the pl011 with debug chars
<doug16k>
not using I/O window for anything though
<doug16k>
lets me give arch_* port accesses someday
<doug16k>
what do you think of my configure script?
<geist>
so based on that it seems at least in this particular situation the PIO addresses are still relative to the base of PIO space
<doug16k>
should be
<kingoffrance>
its my favorite, allows for interceptor pattern :) im not certain, i used to invoke like instead of "$TOUCH" $TOUCH to allow for custom args too :) but probably a) overkill b) doublecheck that if you change it
<doug16k>
geist, I think of it as telling it what bus cycles to respond to when I set a BAR
<geist>
this is how i expect it to work, so SGTM
<geist>
and FWIW linux /proc/ioports shows the allocations as I expeft
<geist>
it says PCI bus 0 owns 0 - 0xffff and then the three devices seem to be grabbing their little piece