garrit has quit [Remote host closed the connection]
garrit has joined #osdev
<heat>
geist, in riscv what's a "Supervisor software interrupt"?
<geist>
basically IPIs
<geist>
you set a software interrupt on a remote cpu and it fires
<heat>
ah nice
<geist>
when using SBI you do that via their interface and it arranges for one of these to be triggered no your cpu
MiningMarsn is now known as MiningMarsh
garrit has quit [Remote host closed the connection]
garrit has joined #osdev
<heat>
what's the difference between an access fault an a page fault?
<heat>
man these docs are bad
<dmh>
which are you reading
<dmh>
not that i've looked at risc-v in years
<heat>
the privileged spec
<heat>
ok I think access faults are for when the permissions are wrong and page faults are for when there's no mapping
<heat>
actually no access faults are for PMP
<geist>
right. ARM has a similar distinction
<geist>
oh wait, yes that
<geist>
arm has permissions and access faults and whatnot, as a subcode. that's what i was thinking about
<geist>
at the high level yes riscv has stuff for the PMP and stuff that's paging related
cppimmo has quit [Remote host closed the connection]
<heat>
i was wondering how to find out I came from user-space and realised I forgot to save sstatus
<geist>
but yeah grepping through the docs no where does it at least simply say 'access fault is this' 'page fault is that'
<geist>
yep, it copies the previous modes to second fields within the same reg. i think MIPS did precisely the same thing
<geist>
and you have to save it because an eret copies it back
sprock has quit [Ping timeout: 240 seconds]
<heat>
found this out through the sifive forum
<heat>
they should rewrite the freaking docs
[itchyjunk] has quit [Remote host closed the connection]
<geist>
oh thats right. rereading this thing i forgot that it's annoying to figure out the cause of the page fault
<geist>
it breakds them into three vectors: instruction, load, store page fault. so that gets you basically R/W
<geist>
but to figure out if it's a permission or access bit or page not present: gotta dig into the page tables
<geist>
which... i guess is not really any worse than x86 iirc. CR2 doesn't hold much more than that
<geist>
i'm used to arm64 breaking all of that out into a very complete exception syndrome field
<geist>
since on page faults it only saves the address in `stval` and that's all yous got
<heat>
the cr2 only holds the address, the PF data is held in the error code
<geist>
er yeah that
<heat>
but you do know if the PF happened while reading, writing, executing, (or had a reserved bit set in the page tables iirc)
<geist>
yah so i guess this is about as complete as that
<heat>
it doesn't tell you what's wrong but it also doesn't vector the page fault into 3 different trap vectors
<geist>
ah i see why i wasn't able to trivially find where it says what an access fault is: in one part of the docs it calls it '* fault' and in another it calls it '* exception'
<geist>
ie, access exception, load exception, etc
<geist>
riscv is very much like 'here's this go kart and some tools, have fun!'
<geist>
which, can be fun, you just gotta tinker
<heat>
the anti-intel
dequbed has quit [Quit: bye!]
dequbed has joined #osdev
mahmutov has quit [Ping timeout: 256 seconds]
sprock has joined #osdev
dmh has quit [Changing host]
dmh has joined #osdev
<mrvn>
geist: at least they provide tools
<mrvn>
On a lot of ARMs it's: Here boots linux, have fun.
<dmh>
very true
<dmh>
they patch uboot and get it to load a kerenl and ship it
<heat>
the only reason that's no true in riscv is that you can't get a riscv board :P
<klange>
actually existing is left as an exercise to the reader
<gog>
brb doing VLSI lithography in my bedroom
<mrvn>
I still remember my first ARM specs, confidential papers for an Allwinner SOC. It literally just said: The Allwinner has an uart similar to the 16550. The 16550 has the following registers and then a long list of stuff that every uart had since the invention of fire. No mention of *where* the uart is.
<mrvn>
repeat for other peripherals.
<dmh>
i have the first risc-v board
<mrvn>
oh wow, when will they produce the second? :)
<dmh>
the highfive unleashed
<dmh>
yea good question
<mrvn>
I have a CyberPPC boasrd for my Amiga, serial #15.
<dmh>
unmatched is borderline usable for modern desktop XD
<mrvn>
closest I ever came to "first board"
<heat>
the unmatched is 500 euro :)
<mrvn>
An RPi is 50 EUR and quite usable as desktop
<heat>
all I want is a raspberry pi but riscv
<klange>
riscv just feels like the CPU equivalent of what most of us are doing here
<dmh>
yea decent price finally
<geist>
yah i had an unleashed but gave it to someone else at work
<geist>
but i do have an unmatched. alas it's a weird pre-production so without some work linux doesn't run on it
<heat>
everything is either 32-bit and more embedded or really hardcore unmatched crap
<dmh>
ya kinda sucks
<geist>
there was another new one coming out that i was interested in. lemme find it
<geist>
like a dual core 64bit board for $150 range or so
<heat>
my rpi zero 2 w was *15 euro* and has 512MB, 4 cores and 64-bit
<dmh>
its also a broadcom chip have fun
<mrvn>
dmh: I do. Still the chip I can work with best
<klange>
but it exists and it works
<dmh>
ya
<heat>
it do the beep boop
<mrvn>
There is just so much specs and examples for the RPi that you can get it to work easily.
<heat>
my imaginary riscv board doesn't do the beep boop because it doesn't exist
<bslsk05>
'Bad Apple!! - Full Version w/video [Lyrics in Romaji, Translation in English]' by luigiman09 (00:05:24)
<heat>
yeah its $200 no thanks
<geist>
yah. not free for sure
<dmh>
only from it playing on a longan nano lcd
<dmh>
thta board looks nice
<bauen1>
heat: but that's still a lot closer to affordable than a year ago
<dmh>
i eyeroll at the edge compute AI stuff just like the kendrytes
<dmh>
but ya solid
<heat>
bauen1, but nowhere near affordable for something like a hobby
<dmh>
will wait for it to come out, have the usual ethernet timing issues and a few revs or what have you hehe
<dmh>
im surprised its that low
<klange>
can I get that without all the extra video stuff that's probably half the cost?
<dmh>
seriously tho. give me a non embedded set riscv with no ai crap and no video enc/dec
<klange>
i like how the encoder/decoder chip for the mipi can do 4k/60 but the HDMI can't, that amuses me for some reason
<geist>
iirc i thik this was the chip that was going to go in the BeagleV before they cancelled it
<dmh>
aha
<geist>
so it seems like maybe it's an attempt for starfive to actually sell the chip
<klange>
like if these weren't weird domain-specific things or insanely overpriced dev boards, I would care more about riscv
<geist>
yah i like to have Lk ready to go for it so people can pick it up for their domain-specific thing
<geist>
but for general purpose it's a bit harder pill to swallow
<dmh>
need all the people writing disk drivers in risc-v to get board and start their own stuff
<geist>
aside from general hackery on multiple arches which is an itch i like to scratch
<klange>
I did aarch64 mostly because I wanted to prove that my new kernel really was portable.
<klange>
And I want to target the rpi400 as a platform because it gives me a consistent, modern, and affordable thing I can point to and be like "buy one of those and you can run ToaruOS on real hardware with 'full' support"
<geist>
yah and it's a nice little thing too
<klange>
And I want to do M1 because it actually seems to be really easy, especially when the primary dev REing is a friend of mine - and not just in the usual online sense, I helped him move into his current apartment
<geist>
yah totally. i stay away from any REing on it because i'm a little bit too close to it, but others have been enjoying that anyway
<klange>
iirc the keyboard and trackpad are really straightforward peripherals, and iboot just hands you a framebuffer for the most part, so I might even have full GUI on that pretty quickly once I get my kernel loaded
<clever>
klange: any interest in having hw accelerated 2d composition? or 3d rendering?
Oli has joined #osdev
Oli has quit [Client Quit]
ElectronApps has joined #osdev
<heat>
geist, do you write all your risc assembly or is writing stuff in C, getting the assembly and adjusting it a good option?
<heat>
for non trivial things of course
vdamewood has quit [Remote host closed the connection]
vdamewood has joined #osdev
<heat>
i need to write the standard user <-> kernel primitives and the compiler is infinitely better than me at writing this
[itchyjunk] has joined #osdev
pretty_dumm_guy has quit [Quit: WeeChat 3.4]
<dmh>
i hate computr
<dmh>
not tru
<heat>
i hat compot
* klys
considering getting a new lifebook
theruran has joined #osdev
<heat>
haha asm gotos are soo cool
* moon-child
smacks heat's inline assembler around a bit with a large trout
<dmh>
bx ?
<dmh>
im tryin to make a bootloader so i can shoot code to it instead of writing a sdcard 1000s of times
<dmh>
just did my 'take me to this address' rawdog
<dmh>
time to pivot and make a forth
dude12312414 has joined #osdev
the_lanetly_052 has joined #osdev
sprock has quit [Ping timeout: 272 seconds]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
nyah has quit [Ping timeout: 240 seconds]
heat has quit [Ping timeout: 250 seconds]
<g1n>
hello
GeDaMo has joined #osdev
the_lanetly_052 has quit [Ping timeout: 272 seconds]
terminalpusher has joined #osdev
<geist>
hello
<g1n>
hi geist
terminalpusher has quit [Remote host closed the connection]
zaquest has quit [Quit: Leaving]
zaquest has joined #osdev
the_lanetly_052 has joined #osdev
the_lanetly_052 has quit [Ping timeout: 240 seconds]
mahmutov has joined #osdev
<klange>
i find myself having to sprinkle more and more magic into my device drivers to get them working in kvm on the pi, just the right cache nudging here and there... spent a while today getting that nic driver to not crumble, had to add a few extra things now to get keyboard+tablet to respond quickly...
<klange>
also as cute as the classic home micro 'computer in the keyboard' design is, this keyboard sucks and I should really get the other kind of KVM to make devving on this less annoying
<klange>
I have my mouse's dongle plugged into it, so I can unplug it from its tether and it'll automatically switch, but the keyboard is too squishy
<j`ey>
the other kind of KVM?
<j`ey>
ohh
<j`ey>
(keyboard mouse switcher thing, /me is slow)
<klange>
keyboard-video-mouse switch, though no need for the video
<klange>
I don't know if they're still in vogue, but I recall in the early days of USB there were ones that would sort of cache the attached devices so when you switched it wasn't just disconnect/reconnecting
<bslsk05>
en.wikipedia.org: Dynamic device mapping - Wikipedia
aejsmith has quit [Remote host closed the connection]
aejsmith has joined #osdev
<moon-child>
klange: ssh -X?
<klange>
Did that for a bit, but the latency of pushing a framebuffer is quite visible. Mostly qemu's fault.
<klange>
Not that I'm helping matters with the RPi on wifi.
<klange>
VNC with the actual output still being enable may work... or I can try Synergy, but it's always been a bit odd and I'm not sure I trust any of these solutions to quite do what I want.
<klange>
Dschinghis Khan was weirdly popular in Japan. Personally think their other big single, Moskau, is a better song.
masoudd has joined #osdev
nyah has joined #osdev
[itchyjunk] has quit [Read error: Connection reset by peer]
<g1n>
hi one more time, i was trying to fix page frame allocation, and i found that kalloc_frame and kfree_frame working fine, but it can't allocate more than one page (i mean, if i allocate first page, and then allocate second, it page faults, but if i free before second page, it is fine). Seems there problem with initial freeing all pages in paging_init
<g1n>
GeDaMo: on start next_page and free_pages are 0, then i allocate 2 pages: 0, 16777216 (if display with %d), then printing last time, next_page is 2, free_pages 0
<g1n>
i need to go now, see you later
<GeDaMo>
:|
<GeDaMo>
I thought you set next_page to something
<GeDaMo>
And that suggests your page size is 1
terminalpusher has joined #osdev
<nomagno>
Can a fixed instruction size of 1-5 bytes be considered RISC?
<nomagno>
Well not fixed, but fixed in each opcode
<GeDaMo>
The definition of RISC is very fuzzy, you could probably fit it in :P
<nomagno>
And the rest of the instruction set would probably qualify as MISC :D
<g1n>
GeDaMo: cool! it works! thanks :), should i change memory there?
<GeDaMo>
'memory' is just an array I used in place of your actual memory
<g1n>
GeDaMo: so i should put there location where my kernel ends?
<GeDaMo>
page_t *next_page = (page_t *)memory; next_page should be initialized to the lowest address you want to use for allocating
<g1n>
ok
mahmutov has joined #osdev
<g1n>
hmm, seems i messed up something with linker script
terminalpusher has quit [Remote host closed the connection]
terminalpusher has joined #osdev
gxt has quit [Quit: WeeChat 3.4]
gxt has joined #osdev
<mrvn>
Mutabah: a trivial stack for free physical pages is perfectly fine unless you need to deal with devices that need continous physical memory. No need for anything more complex.
<zid`>
I have two stacks for 2M and 4k but yea, same shit
<Mutabah>
mrvn: Sure... just that example assumed identity mapping
<mrvn>
Mutabah: yes. but he is just starting
<mrvn>
g1n: remember: you should start at kernel_end to free pages.
<Mutabah>
Oh, definitely.
<Mutabah>
I probably wasn't properly clear. I appreciate that design... just kinda don't like the identity mapping assumption (it's dangerous if you're only just learning)
<mrvn>
Mutabah: having a struct phys_addr_t (pages), struct phys_addr_t (addresses) and void * (mapped memory) helps a lot to catch errors in C.
<mrvn>
What do you name your module files in c++?
mahmutov has quit [Ping timeout: 272 seconds]
mahmutov has joined #osdev
nyah has quit [Quit: leaving]
nyah has joined #osdev
pretty_dumm_guy has joined #osdev
terminalpusher has quit [Remote host closed the connection]
ElectronApps has quit [Remote host closed the connection]
the_lanetly_052 has joined #osdev
[itchyjunk] has joined #osdev
dude12312414 has joined #osdev
the_lanetly_052_ has joined #osdev
the_lanetly_052 has quit [Ping timeout: 256 seconds]
heat has joined #osdev
k8yun has joined #osdev
the_lanetly_052_ has quit [Ping timeout: 256 seconds]
k8yun has quit [Read error: Connection reset by peer]
xenos1984 has quit [Remote host closed the connection]
xenos1984 has joined #osdev
<gog>
have a strange problem, kprintf() doesn't seem to work inside an irq handler. it enters and exits the handler stub and next level fine but maybe i misaligned the stack somewheres
<gog>
it works inside my page fault handler
<gog>
hm
<zid`>
the stack alignment *shouldn't* matter unless your kprintf is doing unaligned stores of the fpu regs to the stack
<mrvn>
hidden problem #1: if kprintf supports %f/%g then it uses the fpu/sse
<zid`>
which is why it matters for regular printf
<gog>
not using floating point arguments
<mrvn>
hidden problem #2: on irq the stack is not 16 byte aligned
<gog>
gonna double check that
<gog>
i have a macro that is supposed to align before calling the next handler
<zid`>
can't hurt to toss in a fake push to test it
<mrvn>
gog: you don't have to use them, if they are supported then the VARGS store fpu/sse regs
<zid`>
even if it was aligned before and it unaligns it, it still tests it both ways
<heat>
zid`, I think codegen can still get borked even if the FPU is disabled
<mrvn>
gog: check the calling convention or asm output. Maybe you have to misalign the stack
<zid`>
heat: Can't think of a way how personally
<mrvn>
heat: if the fpu is disabled in the compiler it just won't compile
<heat>
i know
<mjg>
does not work in an irq handler at all?
<mjg>
maybe you are just recursing into it? :)
<mrvn>
gog: how doesn't it work? desdlocks? throws an exception?
<mrvn>
x86_64, ARM or ARM64?
<zid`>
gcc's codegen for va_arg is kinda.. bad, wow
<gog>
it prints, just doesn't pop values off of the va_args
<gog>
lemme throw more shit at it and see what happens
<mrvn>
gog: "just doesn't pop values off of the va_args" results in what?
<mrvn>
and outside the irq a volatile short short unsigned n = 42; kprintf(""%s of irq%hhu\n", "unhandled activation", n); works?
<heat>
wtf
<zid`>
% d
<heat>
half-half unsigned
<heat>
amazing
<zid`>
I hope your thing handles % d without.. getting very upset
<gog>
it does
<zid`>
Mine probably breaks I'm not sure I tested bad specifiers :D
<GeDaMo>
"space: if the result of a signed conversion does not start with a sign character, or is empty, space is prepended to the result. It is ignored if + flag is present." https://en.cppreference.com/w/c/io/fprintf
<mrvn>
gog: va_list might already be a pointer, which is why it works
<gog>
that's what i'm wondering
<gog>
GeDaMo: yeah reading that
<gog>
> If a va_list instance is created, passed to another function, and used via va_arg in that function, then any subsequent use in the calling function should be preceded by a call to va_end.
<mrvn>
GeDaMo: How do you pass a va_list to helper functions so they can modify it?
<gog>
not sure i grok this line
<zid`>
f(ap); va_end(ap);?
<gog>
so after every parse_specifier and print_* call i need to call va_end()?
<GeDaMo>
Looks like it's just the va_list name, no &
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<bslsk05>
github.com: bootstrap/Makefile at master · zid/bootstrap · GitHub
<zid`>
but it's not in that branch
<mrvn>
zid`: no dependency generation for headers?
<gog>
ok passing va_list by pointer does not work
<mrvn>
gog: are you derefing it on use?
<gog>
kprint.c:83:70: note: expected '__va_list_tag (*)[1]' but argument is of type '__va_list_tag **'
<gog>
yes
<heat>
zid`: this is why you should use clang
<heat>
gdt.c:64:30: warning: 'size' argument to memset is '0'; did you mean to transpose the last two arguments? [-Wmemset-transposed-args]
<gog>
what i mean is it doesn't compile
<mrvn>
gog: your array has decayed
<gog>
why did it do that
<zid`>
heat: What do I win if that's a false pos?
<mrvn>
because C does not have arrays, that's an illusion
<heat>
zid`, the bad code award 2022
<zid`>
damn, the warning is right
<zid`>
thanks heat
<j`ey>
heh
<zid`>
Are you going to offer it up a patch
<mrvn>
heat: doesn't gcc have a "not 0" flags on the size too?
<heat>
don't thank me kids, thank the clang
<zid`>
or should I just write one and slag you off in the notes
<gog>
wait
<gog>
i found it
<gog>
forgot to change a parameter
<heat>
do whatever you want, I'm adding clang
<zid`>
"Thanks to the good-for-nothing heat, who uses obscure compilers, through lots of hard work by me personally, I have discovered an argument transposition that leads to the GDT not being cleared. This has no runtime effect."
<heat>
hahahaha
<zid`>
adding clang?
<zid`>
don't you just do CC=clang make?
<zid`>
*((u32 *)&e[1]) = tssptr >> 32;
<mrvn>
zid`: if only it where that simple
<zid`>
I think that might be my favourite line in this project
<zid`>
rather than fixing the memset I should just.. make a union so I can do e[1].tss = tssptr;
<heat>
interrupt.c:60:2: warning: interrupt service routine should only call a function with attribute 'no_caller_saved_registers' [-Winterrupt-service-routine]
<heat>
you get a bunch of these
<zid`>
sounds like a clang issue to me
<clever>
heat: oh, that brings up an idea, about interrupt safe functions, like not touching the fpu, and not blocking, but can gcc accept such custom tags and filters?
<zid`>
function attribute to compile it -mgeneral-regs-only?
<gog>
ok changing it to pointers doesn't do shit
<gog>
and infact makes my code gp
[itchyjunk] has quit [Remote host closed the connection]
<mrvn>
interesting
<gog>
it works as is rn even if it may be relying on UB
<gog>
ill cross that bridge if i have to
<mrvn>
gog: I will stick with not passing va_list around more than once.
<zid`>
heat: What's it even moaning about for the interrupty thing, does clang not push enough regs to make C functions not trash regs?
<zid`>
I glanced at gcc's output when I first wrote it and it looked like 'all regs', from what I remember
<gog>
i'm gonna YOLO and pass it around everywhere
<zid`>
or at least the C trashy ones
* gog
passes the va_list to zid
* zid`
passes it to int f(char *fmt, va_list ap, ...)
<heat>
you're gonna have to wait for clang 14 to build boros with it
* zid`
puts up the 'universe is currently out of order' sign
<heat>
it doesn't like your inline intel assembly
<zid`>
heat: Oh is that when clang starts to work?
<zid`>
does it want plan9 or something
<heat>
it's when clang starts to handle crappy inline intel syntax better
<zid`>
seems like it worked though from what you showed?
<heat>
it failed to compile every file with inline asm
<zid`>
oh where did the screenshot come from then, gcc?
<heat>
I tried it in godbolt and yeah, fails for 13.0.0 (latest release) but works with trunk
<heat>
zid`, yes
<zid`>
gcc > clang then confirmed I guess
<heat>
*sad freebsd noises*
<mjg>
:)
<zid`>
sad freebsd noises are just bsd noises
<kingoffrance>
no, he was happy as a daemon with a pitchfork until they made him a floating orb
<heat>
zid`, godbolt says __attribute__((interrupt)) functions don't save any regs
<heat>
there's no interrupt frame at least
<zid`>
did you call something from inside it?
<zid`>
afaik it was eliding it if it didn't matter
<mrvn>
heat: the intgerrupt frame comes from the hardware
<mrvn>
__attribute__((interrupt)) is basically useless
<zid`>
those are all the regs a C function would clobber, afaik?
<zid`>
so that attribute does.. literally exactly what I'd want
<heat>
>Exception handlers should only be used for exceptions that push an error code; you should use an interrupt handler in other cases. The system will crash if the wrong kind of handler is used.
<heat>
haha
<mrvn>
zid`: for that one narrow case
<zid`>
heat: i take it you skipped the g() part and it optimized for you?
<heat>
yes
<zid`>
I bet clang doesn't even know what registers are
<zid`>
it doesn't even know intel made my cpu
<mrvn>
.oO(intel didn't make my cpu)
<zid`>
There should be a HP syntax, then we could match my cpu to the OEM at least
<heat>
anyway you should all feel blessed by clang, the permissively licensed C/C++/bytecode compiler with great tooling
<heat>
may clangd bless your souls
<zid`>
*CLANG*
<zid`>
I assume that's what you say instead of Amen
<mrvn>
heat: tell me again when c++20 support works
<heat>
hey it works
<heat>
i'm compiling with -std=c++20
<mrvn>
20:09 < heat> mrvn, gcc's is better, clang's c++20 is going slowly
<mrvn>
ok, s/works/works better/
<zid`>
clang is obviously just a cheap gash crab
<heat>
gcc's c++20 IS better
<heat>
but none have <format>
<heat>
so we're all fucked anyway
<heat>
and even if they had, there's no std::print
<mrvn>
heat: not much of a problem, the STL doesn't work well for kernels anyway
<heat>
i also write the rest :)
<zid`>
nobody liked my spoonerism + joke? dang
<mrvn>
heat: are you using modules?
<heat>
no
<mrvn>
concepts?
<heat>
no
<mrvn>
what c++20 feature do you use?
<heat>
i like std::span :D
<bauen1>
mrvn: if you're needing to use concepts, that's nice because it's cleaner than the mess that is static_asserts etc..., but if you have to use them you're already deep in templates ...
<mrvn>
heat: have to implement that one
<heat>
i also use plenty of [[likely]] and [[unlikely]]
<mrvn>
bauen1: seems like if I write a sort function and auch then I should add concepts and requires to it
<heat>
and some constexpr stuff maybe
<bauen1>
mrvn: hm, true that's probably not a terrible use case for them
<mrvn>
bauen1: the main benefit I except would be better error messages
<bauen1>
mrvn: so from the template magic i had to deal with, they're better, at least they're no longer a couple (i think 4-10) kilobytes big, but only a few hunderd bytes and a lot more readable, but still not helpful
<bauen1>
mrvn: i think it will tell you that a parameter is invalid, but it won't tell you why or something like that :D
<mrvn>
bauen1: it's supposed to tell you the concept it violates recursively along the declaration of the concept.
<mrvn>
bauen1: so if it isn't sortable it recurses and tells you it lacks the operator <
<heat>
what the fuck is wrong with those error messages
<heat>
if you're in deep shit with templates you should stop what you're doing immediately
<mrvn>
heat: you can't read a 1MB error message at a glance?
<heat>
that's a problem I haven't encountered yet
<heat>
because I don't abuse templates
<mrvn>
heat: then you haven't played in deep shit with templates
<heat>
why do you?
<mrvn>
STL error messages are horrible.
<heat>
those are bad but not bad bad
<mrvn>
heat: because my oldest ARM has no FPU and I need a sin, cos and tan table.
<mrvn>
heat: modern c++ you just do a for() loop to constinit the table.
<heat>
but constexpr are cleaner and faster and better in every way
<mrvn>
for (int i = 0; i <= 90; ++i) { tbl[i] = cos(rad(i)); }
<mrvn>
now do that with a recursive template.
<heat>
no
<heat>
u
<mrvn>
heat: looking at some STL code from today I noticed why g++ increased the template recursion depth from 14 to 509.
<bauen1>
heat: once you need to implement a "list of templated types" that can be "applied" to another template with ~50 items is when you'll start to have ... intriguing ... error messages
<heat>
i think that's all bad code
<mrvn>
bauen1: try an error about a function call with 16384 arguments.
<bauen1>
heat: i agree, however there's not much i can do about it :(
<heat>
work?
<bauen1>
heat: no, a project using an underlying rtos that uses templates, and it only escalates from there
<bauen1>
the thing is, that once you start using templates you literally can't stop
<gog>
it's like pringles
<heat>
:D
<bauen1>
gog: true, and they're both not good for you
<gog>
despite the marketing
<mrvn>
templates at least are better than void*
<heat>
i use templates in moderation and that's why my code is fast to compile
<zid`>
I use templates when my code is too fast too
<zid`>
oh sorry misread
<heat>
mrvn, they're better except when they cause code duplication for no reason
<mrvn>
heat: g++ has become tons better at avoiding that.
<heat>
when you could do a little type punning and boom, ez
<bauen1>
then there's also global constructors, which are really fun to deal with in the embedded system, they're probably an even bigger mistake
<mrvn>
heat: I'm missing an attribute [[type-pruned]]
<heat>
bauen1, oh i feel you
<mrvn>
bauen1: the one thing wrong with global constructors is a lack of order.
<heat>
i have percpu structs, those structs have members
<heat>
those members are used elsewhere in the code
<heat>
i may want to add a constructor to those members so they're easier to use and initialise
<mrvn>
bauen1: I have one file that declares and enum for global constructors and all global constructors then have a priority from that enum so they have a well defined order.
<heat>
they need to be constexpr else booting breaks because percpu variables' addresses are 0 based
<mrvn>
heat: struct per_cpu { int foo{0}; }?
<bauen1>
i think i read https://phaazon.net/blog/blog/c++-constructors which compares c++ constructor (madness) with how rust effectively only has aggregate types, constructors just cause so much pain
<bauen1>
mrvn: do you have that code somewhere i can look at ?
<bslsk05>
github.com: Onyx/apic.cpp at master · heatd/Onyx · GitHub
<mrvn>
why?
<heat>
it runs the global constructor and this = NULL + a few bytes
<heat>
as I said, my .percpu has a base address of 0
<heat>
as to make something like "mov %gs:variable, %rax" work
<mrvn>
heat: how does any access to lapic_timer work?
<heat>
get_per_cpu_ptr
<heat>
so like timer *t = get_per_cpu_ptr(lapic_timer)
<mrvn>
heat: and that adds %gs to the offset of lapic_timer?
<heat>
if it were a simple 1, 2, 4, 8 byte variable I could just use the standard read/write/add macros
<heat>
get_per_cpu_ptr fetches the percpu base and adds the offset of lapic_timer yes
<mrvn>
heat: why not do the reverse. Keep the per_cpu_vars in normal memory and calculate the offset for simple 1,2,4,8 byte variable accesses
<bauen1>
mrvn: nice, that would make a few things much better, can you do something similiar for global static constructors ?
<mrvn>
bauen1: You mean gloabl "Foo foo();"?
<heat>
mrvn, like keeping all percpu memory in a row?
<mrvn>
bauen1: I think that can take an __attribute__((constructor(__CONCAT(INIT_,name)))) too
<bauen1>
mrvn: thanks, i'll have to experiment with that a bit
<mrvn>
heat: no. keep in the .data/.bss section or allocate it dynamically so the address is a valid one.
<heat>
i could allocate it dynamiclly and keep a pointer
<heat>
that would work
<mrvn>
heat: that would support different numbers of cpus as well.
<heat>
this also supports hotplugging
<mrvn>
heat: And new PerCPU(id, ...); will just work.
<mrvn>
heat: the problem I have is that you can't have any pointers in the PerCPU struct because you can't make them relative to the begining of the struct.
<heat>
they don't need to be relative
<mrvn>
heat: then how do you access the %gs relative?
<mrvn>
s/the/them/
<heat>
the per cpu variables' addresses are relative
<heat>
the members might have absolute pointers
<mrvn>
heat: not in my case because the structs in my case end up at different addresses in different processes
<mrvn>
What I want are pointers from different address spaces, accessed through a base register.
<mrvn>
heat: imagine %fs, %gs would access separate memory that you can't access without them.
<heat>
that's simply not possible
<mrvn>
yeah, a short coming of C for micro controllers
<heat>
mrvn, well, depends on the target
<heat>
clang and gcc have support for separate address spaces
<heat>
for example x86 have address spaces for %fs and %gs
<mrvn>
heat: how?
<clever>
in the old days (pre-286?) there was a segment base register, which just gets <<16 i think, and then added in, but there is now something (blanking on the name) that gives a 64bit? offset for each segment addr
<gog>
FSBASE/GSBASE MSR
<gog>
?
sprock has joined #osdev
<mrvn>
clever: still the same thing %fs, %gs. It's just 64bit, not shifted in long mode and set via MSR.
<clever>
mrvn: i remember something about a table in ram, that maps each value to a 64bit int
<clever>
but most things assume that you only have 1 value, 0
<mrvn>
clever: the problem is telling C that you have pointers in the %fs or %gs address space.
<clever>
yeah
<clever>
the only time ive seen c use that, is with TLS
<zid`>
would be quite nice to be able to tag address spaces in C
<mrvn>
clever: TLS stores the address of the thread local address table relative to %fs and uses asm to get it.
<clever>
ah, i thought it was something like %fs points directly to the local vars
<geist>
there are builtins for gcc/clang at least to deref off of fs/gs
<heat>
__attribute__((address_space(number))
<geist>
a good way to codegen since the compiler can be smart about it
<geist>
yah though i thought there was also a __builtin_fs or __builtin_gs or something
<heat>
__seg_gs and __seg_fs
<geist>
yes that
<mrvn>
clever: then every access would have to use %fs and then you can't pass pointers around because C has no way to tag a pointer to belong to a address space.
<mrvn>
clever: or read of %fs and add it yourself. That's slow.
<clever>
mrvn: ah, i was assuming you would have a way to convert in an opcode, but maybe not
<clever>
some ISA's have a "load effective address" to turn a pc-relative addr into an absolute addr
<mrvn>
clever: you can do %fs:offset but not load %fs + offset into a register.
<clever>
ahh
<mrvn>
clever: and reading %fs is an MSR and iirc that clears the pipeline. So 100 cycles slower than accessing %fs:0
<clever>
ouch
<clever>
semi-related, a lot of the rpi firmware is doing `ld r0, (gp+0x1234)` and `add r0, gp, 0x1234`, for PIC reasons
<clever>
setting gp once at startup, is far cheaper then patching every single reference
<mrvn>
clever: TLS might do both, keep the address in %fs:0 and have the variables at %fs:8 and following. So direct access and address taking is fast. Not sure.
<clever>
all staticly allocated objects are then in that gp area
<mrvn>
clever: gp being some scarcth register C doesn't use?
<clever>
yeah
<clever>
its set once and then never changed again
joe9 has quit [Ping timeout: 256 seconds]
<mrvn>
clever: you can tell gcc/clang about such global registers but if you do too much of it it blows up because it fails to find enough usable registers.
<clever>
you would also need to have one multi-megabyte struct, which that register points to
<mrvn>
clever: especially with x86 being so register starved
<clever>
the rpi firmware compiler just dynamically decides that gp is the base of .data, and anything the linker put in .data goes thru gp
<clever>
so its far more seamless
<mrvn>
ocaml use it to point to the memory manager / GC struct. It's not that big but access needs to be really fast.
<zid`>
yea gp is used for sbss on mips a lot
<clever>
a very small number of things, are access with gp and a negative offset
<clever>
i'm not sure on the logic of why
<mrvn>
.rodata?
<clever>
probably
<clever>
let me double-check the code...
<mrvn>
putting gp in the middle doubles the addresses you can cover
<mrvn>
signed offset in the opcode
<clever>
its also flexible, `st r1, (gp+0x18)` is a 32bit opcode, but `ld r6, (gp+0x6a0)` is a 48 bit opcode
<clever>
each variant of the opcode, has a different allowed range for the immediate offset
<mrvn>
ld and st have different range? odd.
<clever>
nope, its because the immediate had too many bits in it
<geist>
re: getting address of gs:0, it's i think a common pattern to store the flat pointer in the 0th slot
<mrvn>
geist: yep, faster than the MSR to read gs
<geist>
yah the MSR access to GS and FS is extremely slow in my experience
<geist>
avoid it at all costs in a fast sequence of code (ie, context switch)
<geist>
and/or use the new fsgsbase instructions if available for that
<clever>
mrvn: hmmm, i cant find a negative offset, those are only ever done thru the add opcode
<mrvn>
I hate if-available things
<geist>
agreed. this one is probably worth it though
<heat>
mrvn, i think those attributes tag the pointer but don't quote me on that
<heat>
right now I'm keeping all the percpu bases in an array and I index into it using the cpu nr
<heat>
i think the common pattern is better but well, tough shit
<mrvn>
"As an extension, GNU C supports named address spaces as defined in the N1275 draft of ISO/IEC DTR 18037. Support for named address spaces in GCC will evolve as the draft technical report changes. Calling conventions for any target might also change. At present, only the AVR, M32C, PRU, RL78, and x86 targets support address spaces other than the generic address space. " What about x86_64?
<moon-child>
gcc had a way to globally reserve a register, right?
<mrvn>
I'm not getting the syntax right
<mrvn>
moon-child: yes
<heat>
mrvn: it's int *p __seg_fs
<heat>
actually, int __seg_fs *p
<moon-child>
how do I do that? I think something like register long foo __asm__("rax"); to associatea global variable, but how do I keep it from actually using the register for anything?
<mrvn>
moon-child: command line argument. How you set it is your problem then.
<heat>
moon-child, I think it can't use the register after you assign it to a variable
<geist>
--ffixed-reg
mahmutov has quit [Ping timeout: 256 seconds]
<geist>
but it's arch specific. works pretty good for certain registers on arm64 and riscv for example
<bslsk05>
github.com: [fdtwalk] Fix a bug in #address-cells parsing by heatd · Pull Request #317 · littlekernel/lk · GitHub
<geist>
not sure how well it works for x86, especialyl registers with specific uses (like rax)
<zid`>
I wonder if you still need taht with -fwhole-program
<moon-child>
thanks, right
<mrvn>
heat: not quite. register arguments just put the value in that register but gcc happily spills it to the stack.
<geist>
oh and regs that participate in calling convention probably are Right Out
<geist>
heat: yeah jsut saw that, just booted up computer to take the patch
<clever>
ive also had bugs before on arm32, when the arguments spill into the stack, gcc still wants the args to be aligned to their size
<geist>
heat: oh and i remember what the other one was: #interrupt-cells
<clever>
so if a 64bit arg winds up not being 64bit aligned, gcc creates a 32bit hole on the stack, to fix the alignment
<geist>
i think that shows up from time to time
<clever>
but if you wind up calling a function with a 32bit arg, but the caller thinks the arg is 64bit
<mrvn>
clever: the CPU faults if you load a register pair unaligned.
<clever>
then the called function looks in the hole
<mrvn>
clever: and you have just discovered the evil of implicit prototypes.
<clever>
and then you go nuts, trying to figure out why its not even a corrupt value, but just undefined
<geist>
arm64 took it to the next level and just make it hard illegal for the stack to not e 16 byte aligned at any point
<mrvn>
clever: make implicit prototypes an error. Problem solved.
<clever>
mrvn: in my exact case, it was an ffi api, where glibc was doing `#define mmap mmap64` to alias you over, but the ffi didnt respect that
<mrvn>
hehe, another evil
<heat>
geist: what parts of lk are supposed to be platform neutral (e.g read from the device tree, etc)?
<geist>
that is
<geist>
it's fairly ad hoc, but in gneral most of the lib code should be platform neutral
<geist>
if it's inside arch or platform then it's more specific
<heat>
I was looking into your RISCV timer code and you don't seem to read it from the dt
<geist>
drivers are more ad hoc, some are written assuming they pretty much run on one platform, so can make assumptions (like endian, presence of io addressing)
<heat>
it = the frequency
<geist>
yah could do that for sure
<geist>
iirc it passes it in from the platform code which then gets it however it wants though right?
<mrvn>
geist: wouldn't it be nice to have a __seg_fs like thing for the thread registers on ARM?
<clever>
heat: semi related, there is a dedicated arm register for the generic timer freq, but that register has no actual function at all
<geist>
mrvn: iirc there is some sort of builtin but i forgot what it was
<heat>
geist, you use a platform specific define iirc
<clever>
its purely just a 32bit chunk of ram, that the bootloader uses to talk to the os
<geist>
ah
GeDaMo has quit [Remote host closed the connection]
<geist>
yah should at least change it to have it passed in fromt platform
<geist>
then platform can decide if it wants to get it out of FDT or hard code it there
<geist>
the platform/target level is where the sausage is generally made, since it remains flexible to allow it to work differently (ie, presence of FDT, hard coded, some other mechanism)
<heat>
i'll add an issue and I'll look into it if you don't mind
<geist>
sure thing
<geist>
i assume your'e set up to run local tests there?
<geist>
it's all about scripts/do-qemuriscv. can run all the modes and even a embedded version, so it gets most of the coverage
<geist>
-e, -6, -6S, <no arg> gets all of the 4 modes
<bslsk05>
github.com: lk/platform.c at master · littlekernel/lk · GitHub
<geist>
yep
<clever>
this function is called with either 0 or a real value
<geist>
yah
<clever>
and the prototype in the .h says freq_override, yep
<clever>
and the implementation will read_cntfrq() if zero
<geist>
yah for the riscv thign i ended up jsut setting a #define. i think at the time i was trying to be maximally efficient so it would be compile time optimized
<geist>
possible with SBI you can read it out of the interface too
<bslsk05>
github.com: lk/time.c at master · littlekernel/lk · GitHub
<geist>
but otherwise it calls into SBI
<clever>
could LTO solve the optimize thing you where doing with a #define?
<geist>
not if it's read out of a FDT
<clever>
ah yeah
<clever>
nothing can solve that case
<geist>
but what that code should really do is do a more fancy fixed point divide
<geist>
there's a lib for that... i think lib/fixed_point
<geist>
heat can look into that
<heat>
I literally use that lol
<heat>
geist, do you end up unflattening the dt at any point?
<geist>
unflattening as in?
<geist>
decompiling back to source?
<mrvn>
clever: static inline function is sufficient, no LTO needed
<heat>
getting a tree-like structure out of the fdt
<heat>
in the kernel
<clever>
mrvn: yeah, but then you have to move the code into a .h, while LTO magically does it program-wide
<geist>
not in the kernel no, but i have done it offhand
<clever>
mrvn: much more like sqlite's single-unit compile hack
<geist>
er offline
<mrvn>
clever: you have to declare the prototype in .h anyway.
<geist>
so far i'm adopting the strategy of just poking into the DT for things i know i need
<geist>
but not really adopting a parse-the-tree-find-drivers-to-start model
<heat>
no you never look into things by path?
<geist>
since LK tends to be used in a more embedded like environment
<geist>
ah no
<geist>
would be easy enough to do though
<mrvn>
clever: static inline void *mmap(void *addr, size_t length, int prot, int flags, int fd, off_t offset) { return mmap64(addr, length, prot, flags, fs, offset); }
<clever>
mrvn: off_t can be either 32bit or 64bit, and in haskell, there is a dedicated COff type that is "supposed" to match up, but assumes 64bit, because haskell was built in large-file mode
<mrvn>
clever: you also need an mmap32 for the other case while the code just has a mmap function there
<mrvn>
clever: IMHO just drop the 32bit function and make off_t always 64bit.
<clever>
that requires calling into the mmap64 variant
<clever>
which doesnt exist on aarch64
<clever>
so now you have to know what bit-width your on, at compile time
<clever>
i solved it with a thin c wrapper between the ffi and libc, and that wrapper has defined bit-widths
<mrvn>
clever: drop it in the kernel
<mrvn>
it's stupid that libc still supports files < 2GB
<bslsk05>
github.com: lk-overlay/inter-arch.c at master · librerpi/lk-overlay · GitHub
<mrvn>
it's been at least 25 years since large file support was added. At some point legacy software just has to die.
<clever>
in theory, it could be faster, because its only having to traverse the DT once
<mrvn>
clever: how often do you traverse the DT?
<clever>
mrvn: its more of a question of traversing it once per key your interested in, or once total
<mrvn>
clever: the DT also has aliases. you might have to loop back a few times.
<clever>
mrvn: oh, and a large chunk of the early boot code in nixos, happens to still build with large-file support off, so readdir with 64bit inodes returns -EOVERFLOW, and console font utils then claim file not found, lol
<mrvn>
clever: But how often do you actualy look up something in the DT compared to running the rest of the time. It's a pointless optimization to speed up DT lookups.
<clever>
mrvn: in the code i linked, i'm just fetching 6 properties out of DT on boot, and then never touching that DT again
<clever>
its a custom DT layout with no aliases
<mrvn>
clever: My DT lookup on RPi has to traverse the tree sometimes 3 or 4 times to lookup a symbol. Really doesn't matter.
<clever>
i simply picked DT so i could extend it in the future, without compatability issues
<clever>
basically, this is a multi-boot inspired api, to pass data from the VPU to the ARM, when you have no way to control any registers when the arm code begins
<mrvn>
clever: I decided on just parsing the DT on the fly on every lookup because at the time I need DT values I don't even know how much memory I have. No easy way to allocate something to parse the DT into.
<heat>
if you were to unflatten the device tree into a tree like structure is it better to expose properties as nodes?
<mrvn>
heat: the flat DT is a tree with nodes in an array. Unflatening just helps you skip boring parts.
<mrvn>
heat: or I'm not getting your question
<heat>
i'm unflattening it
<heat>
nodes are nodes
<heat>
but I dunno if having a property has a node in my tree would be a good idea
<mrvn>
heat: can you give an example of a property?
<mrvn>
size = 4?
<heat>
well for example, timebase-frequency
<mrvn>
iirc each node has a number of key=value pairs and other nodes
wootehfoot has quit [Quit: Leaving]
[itchyjunk] has joined #osdev
<mrvn>
*whine*https://godbolt.org/z/oK4h1zGP6 __seg_fs of a struct doesn't apply to members of the struct, have to define each pointer in the struct with __seg_fs too.
<bslsk05>
godbolt.org: Compiler Explorer
<clever>
mrvn: and a node concists of a "start <nodename>" tag, and a "end" tag
<clever>
and between those, is other nodes, and key/value pairs
<mrvn>
clever: yes
<mrvn>
clever: I wouldn't make the key/value pairs nodes
<clever>
so you need to know how many starts youve seen, and decrement each time you hit an end
<mrvn>
My code just recurses
xenos1984 has quit [Read error: Connection reset by peer]
<mrvn>
clever: On a DT you have to remember the size property and some other on each level. So you can't just count start/end blocks.
<mrvn>
size is also inherited to the next level if not overwritten
<mrvn>
The RPi4 DT actually jumps between 32bit and 64bit addresses as you recurse into the tree to find nodes. It's pretty confusing.
<clever>
mrvn: ah yeah, if you want to deal with 32bit vs 64bit, yep
<clever>
parent and child size
<clever>
and ranges too
<clever>
and dma-ranges
<mrvn>
yep. So the node itself is some 32bit chunk. And then the parent at some point remaps the whole range into 64bit address space.
rorx has quit [Read error: No route to host]
<clever>
and on at least the vc4 era soc's, the 16mb mmio block at 0x7e00_0000, can be mapped to any 16mb aligned chunk of the arm physical space
<clever>
so ive made a pi3 boot with mmio at 0x2000_0000 in the arm space
<mrvn>
heat: do you apply the range remaps as your unflatten the tree of when you lookup something?
<heat>
mrvn, what's a range remap?
<mrvn>
heat: in the DT a node can define address ranges mapping all the child nodes to different memory regions.
<bslsk05>
github.com: userland/bcm_host.c at 97bc8180ad682b004ea224d1db7b8e108eda4397 · raspberrypi/userland · GitHub
<clever>
you have permission to cry
<clever>
if you use an old version of userland(pre-pi4), it will just give you the wrong answer
<mrvn>
clever: oh, that just reads out the values that Linux parsed for you already.
<clever>
yeah, half parsed
<clever>
the ranges turns into a byte array
<clever>
but you need to read the #*cells fields, to know how to parse that byte array
<clever>
this code doesnt bother
<mrvn>
clever: tested to work on all RPi released to that date and garanteed to break in the future.
<clever>
exactly
<clever>
the other anoying bit, is how the mmio is ever moving
<mrvn>
I want my peripherals up in 64bit above the 8GB of memory I have.
<heat>
is there no way to create an alias of a templated function using "using" in C++?
<heat>
like you'd do with types
<clever>
mrvn: the pi0/pi1 put the mmio at 0x2000_0000 (+512mb), just above ram
<mrvn>
heat: using CharString = std::string<char>?
<clever>
mrvn: then the pi2 had more ram, so it moved, then the pi4 had more ram, so it moved again
<heat>
mrvn, like that but for a function yeah
<mrvn>
heat: for functions?
<mrvn>
using char_foo = foo<char>; doesn't work?
<clever>
mrvn: but thats a tricky question, do you put mmio in the middle of ram, and make the ram more complex, or do you move the mmio with every model?
<heat>
like "using read_u32 = read_integer<uint32_t>;"
<bslsk05>
github.com: userland/bcm_host.c at master · raspberrypi/userland · GitHub
<clever>
i do it out of habit, any time a 3rd party interrupts the flow, so its clear who i'm speaking to
<geist>
yah for the first response yeah
<mrvn>
I just noticed the return value is "unsigned". So it always returns just 4 byte. No way a high address can work at all.
<geist>
i only complain because my IRC client dings when i get a notification and i have it running on like 5 devices
<clever>
yep, thats why i asked about the size of unsigned
<geist>
so i hear this whole cascade of dings every time
<heat>
oh no
<clever>
the matrix bridge has been doing that to me a lot lately
<mrvn>
ding ding ding ding
<heat>
turn them dings off
<clever>
but #osdev isnt joined by my bridged user
<mrvn>
geist: ding should have a cooldown
<clever>
the +r got in the way
<geist>
yeah but *usually* it's good because it's someione seeking my attention
<geist>
yah like mrvn said. if it had a cooldown...
<clever>
some programs (discord, hangouts) seem to tie the cooldown to your "msg read" events
<clever>
if the desktop keeps ack'ing messages, the phone stops dinging
<geist>
yah
<geist>
though to be fair i dont think i'm hearing any digs right now so may be irccloud does do the right thing here
<mrvn>
that's stupid. If someone dinged me at 1am and I didn't read it then it won't ding me at 8am?
<geist>
or the app is simply not listening at the moment
<geist>
probably if it senses at least one of the clients (or web tabs) is active it squelches it
<clever>
mrvn: ah, found it, 0x4_7c00_0000 in high-peri mode, and 0xfc00_0000 in low-peri mode
<clever>
the 7e vs 7c error, because the pi4 mmio grew downwards
<clever>
all of the old mmio is still at the same addr at 7e and up, and new mmio is below 7e
<clever>
so the base is actually 7c now
<mrvn>
clever: did they need the space?
<clever>
not sure, it might have been a bit of not wanting to mess with the verilog that already works
<clever>
and rather then modify it drastically, they just added another slave port to the axi bus
<geist>
also with LPAE you can still get to it in arm32
<clever>
geist: but only after you enable the mmu, right?
<geist>
as long as you dont put something super important there. so linux probably works fine on it, and thus they're done
<clever>
so no earlyprintk
<geist>
sure, but is the uart up there?
<clever>
everything is up there, including uart
<geist>
ah and the low aperture is turned off?
<mrvn>
geist: everything is up there if you select high mode
<clever>
yep
<geist>
ah yeah well that's broadcomm for ya!
<clever>
so the ram is one solid 8gig block, with zero holes
<geist>
making life unnecessarily hard Because They Can
<clever>
its optional
<mrvn>
geist: Unlike other ARMs the RPI memory doesn't start at 0x2000_0000 but at 0x0000_0000
<clever>
i think its just for the guys that cant deal with a hole in their ram
<geist>
yah so even worse, there are now mulitiple modes. what problem did that solve?
<clever>
ive never actually had to enable that feature
<geist>
yah the general solutio is to jsut start at 1GB or 2GB and run right over. yuo can still have a high aperture, but you can put your basic periphs low
<geist>
but i guess in the legacy bcm mode ram starts at 0, so i guess they wanted to keep that but have a single block
<clever>
i think the root of all of those problems, is that the arm reset vector has always been 0
<mrvn>
geist: but that requires looking ahead to where you might have more RAM in the future. :)
<clever>
so you must have ram at 0
<geist>
and thus the only solution is high periphs
<clever>
yep
<geist>
AFAIK the arm reset vector doesn't have to be 0. and if they had a proper EL3 it's mostly an EL3 problem
<mrvn>
or just stick a little bit of ram as peripheral at 0
<geist>
you can configure it in hardware to be anywhere via a 'define in verilog
<geist>
or ROM which you then turn off the overlay with a control bit somewhere
<geist>
(that's what i've seen *most* arm socs do that really want to solve those problems)
<heat>
sifive chips have the reset vector at like 0x1000
<heat>
it's like 12 instructions that jump to the actual firmware
<geist>
anyway, whatever. bcm always zags where everyone else zigs
<clever>
but the rpi already has a boot rom for the vpu
<clever>
and they want the arm bootrom to be ram
<geist>
that's the most annoying part of it. though i guess technically M1 is far more divergent of socs than any other arm soc
<mrvn>
clever: they could have just mapped 1 page of memory at 0, peripherals 0x1000, memory at 0x2000_0000
<geist>
and the AMD Seattle was *extremely* weird WRT memory layout, but it's dead so no one cares :)
<clever>
mrvn: with the open firmware, i can do exactly that, but the page-size is 16mb
<geist>
or ROM at 0, and jsurt leave it there
<geist>
the ROM could just bounce to ram or something if they wanted
<mrvn>
With the ARM on the RPI being just a second class cpu to the VC you can do any kind of hackish memory layout you like.
<heat>
haha x86 go brrrrrrrrr
<geist>
you need rom *anyway* or it's not useful
<clever>
geist: the pi3 defaults to booting in 32bit mode, enless you set a magic flag to consent to 64bit mode
<clever>
so now your rom becomes an issue
<geist>
where's the magic flag?
<clever>
in one of the arm control registers, set by the firmware
<heat>
hogwarts
<geist>
unlessi t's a hardware fuse it *must* boot into 64bit by definition of the architectures
<clever>
that was likely for backwards compat with industrial customers
<clever>
its a ram based flag
<clever>
so the firmware must set it on every boot
<geist>
yah it's booting into 64bit and then the firmware is dropping it into 32bit and resetting
<clever>
ive seen no signs of it booting twice
<clever>
it just immediately starts in 32bit mode
<geist>
sure, but there's maybe like 5 instructions in 64bit mode
<geist>
you wont see it, because it's just part of the cpu coming up
<mrvn>
geist: the VC might be setting a hardware fuse
<clever>
and jtag cant pause there?
<geist>
oh that yeah. actually. the VC probably jsut sets the hardawre
<geist>
iirc there's a control line coming into the cpu that can override the default endianness. that's how you could hard fuse it (if the arm was the first hing starting)
<clever>
yep
<geist>
so probablywhats going on there is the VC is setting a latch somewhere that just wires into the cpu and then yeah the ARM is truly starting in 32bit mode
<clever>
but if you route that kind of thing to a bit in a register
<geist>
keep forgetting about that VC being in charge
<clever>
yep
<geist>
right. if you were ARM first you could set the latch and then reset yourself and now you're in 32bit mode
<mrvn>
From an ARM perspective the BCM chips are truely horrible.
<geist>
though iric there's maybe a way to do that in theARM ARM without needing external hardware? i forget
<clever>
there is also a proper aarch64 register, to reboot into 32bit EL3
<clever>
yeah, no external hw needed
<clever>
and you choose your new 32bit dest
<geist>
yah, i think you're right. you found it. probably an internal latch on that same line
<mrvn>
geist: hehe, and once in a blue moon a stray cosmic ray hits that register on power up and the system fails to boot.
<geist>
but it's i think only an EL3 thing. you can't necessarily drop your EL1 from 64bit to 32bit, for example
<clever>
yeah
<geist>
without EL2 or EL3 doing it for you
thinkpol has quit [Remote host closed the connection]
thinkpol has joined #osdev
<mrvn>
What's the ARM soc to get nowadays if one wants SATA and GBIT without USB?
<clever>
well.... the bcm2711 has native RGMII for gigabit, and pci-e for sata
<mrvn>
clever: but no SATA connector on the RPi 4b
<clever>
the CM4 will expose the pci-e lane, so you can use your own pci-e<->sata card
<mrvn>
a CM4, an IO board and a SATA controller. not really feeling it.
<clever>
you can buy IO boards that hava a sata controller built in
<mrvn>
99$ to pre-order. So a bit over 100EUR. Not too bad.
<clever>
and then add any CM4 you want, 1gig/2gig/4gig/8gig of ram, with or without wifi/bt, and a range of emmc sizes
<clever>
i dont see a uSD socket on the board, so a lite cm4 wont have anything on the SD bus
<clever>
and cm4 cant boot from sata yet
<mrvn>
now if only it also had an M2.key or (less good) an internal USB socket for the OS....
<clever>
M2 would be pci-e right?
<clever>
but the CM4 only has a single pci-e lane
<clever>
other boards include a pci-e switch to share it
<clever>
CM4 can boot from nvme, but not if its behind a switch
<mrvn>
clever: yes. I've seen carrier boards with M2.key. But it's probably either or unless you add more PCIe stuff
<clever>
CM4 can also boot over usb, but the internal controller is only usb2
<clever>
xhci over pci-e can also work
<mrvn>
are the CM4 with microSD?
<mrvn>
as in directly on the module
<clever>
nope
<clever>
the lite cm4 has no emmc, and just exposes the SD bus on the hi-densitity connectors
<clever>
so the IO board can provide the uSD socket
<mrvn>
I really like that I can just take out the SD card from my RPi and write to it from my desktop when I screw up my kernel. No way I want to develope with eMMC flash.
<clever>
if you put a jumper on the pcb, you can boot the CM4 in rpiboot mode
<clever>
it will then emulate a usb msd, and exposed the emmc
<clever>
then you can mount it and edit whatever
<mrvn>
clever: don't think the Interceptor has that.
<clever>
yeah, i'm not seeing that either
<clever>
oh, and it seems to have a usb-hub as well
<clever>
that blocks device mode
pretty_dumm_guy has quit [Quit: WeeChat 3.4]
heat has quit [Remote host closed the connection]
<mrvn>
100EUR for the CM4 (a big one), 100EUR for the carrier. Not really cheap just to play with it.
<mrvn>
I still have a BananaPi version 1 with the real SATA port. But it's 32bit only. *sigh* can't have it all.
<mrvn>
clever: I've bookmarked the board for the future. thanks.
<clever>
ive got a banana pi r1
<clever>
i'm not sure if it was my psu, but i never got it to reliably even start u-boot
<mrvn>
clever: did you power the SATA extra?
<mrvn>
iirc it only worked with low power 2.5" SATA drives