ALowther has quit [Remote host closed the connection]
ALowther has joined #osdev
<ALowther>
I've got a USB drive that I can't seem to find through any disk utility commands. The USB drive lights up when I plug it in, so it seems to be drawing power. Are there any lower level methods that I could try that might be able to give me more raw access to the hardware to try and troubleshoot what is going on?
<mrvn>
dmesg
<Andrew>
"disk utility commands"?
<Andrew>
dmesg doesn't give raw access though
<Andrew>
ALowther: You didn't even tell us what system you're using
<ALowther>
Andrew: MacOS
<ALowther>
mrvn: Looking into that now.
<Andrew>
macOS - I won't be of any help then :|
Ram-Z has joined #osdev
<zid>
yea if it were anything but macos I could help :P
<Andrew>
"AndrewBruhOS" :)
pretty_dumm_guy has quit [Quit: WeeChat 3.5]
<ALowther>
Thank you. Maybe dmesg will provide what I need.
<Mutabah>
Since power is supplied, the OS should know what part of USB initialisation failed
<sbalmos>
does osx have lsusb?
<mrvn>
it should at least tell you if the thing is even a disk anymore.
<sbalmos>
mrvn: it identifies as a meat popsicle now
<Andrew>
macOS uses a bunch of FreeBSD utilities, FreeBSD doesn't have lsusb last I checked
<Andrew>
lsusb: No such file or directory
<mrvn>
better than a vegan popsicle
<zid>
power is only power if a data pin is damaged though
<zid>
lights don't mean a usb handshake happened
<zid>
so it could be a fully dead controller board still
<mrvn>
yeah, just a resistor and LED across +5V and GND bypassing the controller alltogether.
ALowther has quit [Remote host closed the connection]
<Andrew>
yup
mctpyt has joined #osdev
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
rpnx-phone has quit [Ping timeout: 246 seconds]
srjek has quit [Ping timeout: 255 seconds]
mrlemke has joined #osdev
PSedlacek has joined #osdev
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
<mrvn>
Food for thought: What happens if you splice a datagram socket?
mctpyt has quit [Ping timeout: 260 seconds]
dh` has joined #osdev
knusbaum has quit [Ping timeout: 246 seconds]
knusbaum has joined #osdev
<zid>
I found the thing I wanted to post like 12 hours ago
<bslsk05>
lkml.org: LKML: Linus Torvalds: Re: [RFC PATCH 03/13] usb: remove the usage of the list iterator after the loop
<Griwes>
wow that piece of code he uses as an example there is so bad tho
<Griwes>
and the last sentence is just... uhhhh, does he not understand that ub on overflow is actually why signed computations are actually faster
<zid>
it violates strict aliasing, but *obviously* conveys the intent to a human reader in an unambiguous way
<zid>
You can still have fast signed ops even if you define what overflow does
<Griwes>
the only thing that conveys the intent to a human reader is the name
<zid>
ah yes, 'read a short from this address' is totaly incomprehensible without a macro name
<Griwes>
zid, well, compiler people disagree and urged us to not define what overflow on signed ops does even when we added a requirement that signed integers be 2's complement
<zid>
Yes, that's because that's backwards
<Griwes>
and, quite frankly, I'll take a compiler engineer's word on optimizations over Linus' any day
<zid>
You shouldn't define it, the *compiler* should
<Griwes>
the compiler will just define it to say "it's illegal for you to overflow" if it wants to generate decent code
<zid>
They should come out and say "If this overflows, the result on x86 is blah"
<zid>
not "The result is nethack runs"
<Griwes>
and then it will optimize based on the assumptions that overflows never happen
<zid>
It's still the *exact* same code and optimizations
<zid>
Except we don't have the retarded "the code compiles, the compiler sees that it's UB, and does something fucking stupid instead"
<Griwes>
"nethack runs" is a hyperbole that noone actually implements
<Griwes>
just use as much emotion as possible without using actual arguments
<zid>
I figured being obviously correct was enough
<Griwes>
lmao
<Griwes>
claiming to be obviously correct when you're missing the point of how compilers optimize is quite the statement
<zid>
If you think they have to change the code-gen for how signed overflow works if they're forced to write it in a .txt file
<zid>
idk where to go from there
<zid>
reality transplant?
<Griwes>
what.
<Griwes>
the "fucking stupid code" that compilers generate is because they reason based on the assumption you've written correct code
<Griwes>
optimizations assume certain things don't happen, and generate code based on that
<Griwes>
kill that and you've killed a good chunk of compiler optimizations
<zid>
you don't think "empty label and no ret" is fucking stupid then?
the_lanetly_052 has joined #osdev
<kazinsal>
optimizing out the whole body of f1 and effectively assigning it the same address as f2 should be considered a bug
<zid>
There isn't even a *point* to deleting that code, practically
<kazinsal>
f1 and f2 are fundamentally different functions. they should have different addresses.
<zid>
they saw the spec allowed them to do it and went "ooh a shiny trigger to pull"
<Griwes>
that's... not how compiler writers write code
<Griwes>
they are not fucking malicious
<zid>
Except in this case they obviously are
<Griwes>
oh fuck off
<zid>
note that it doesn't do it in C mode, but only because the C spec doesn't allow it
<kazinsal>
it may not be malice, but it sure is fucking stupid.
<Mutabah>
Nah, what you're seeing is a combination of a bunch of optimisations
<Griwes>
^
<zid>
Which they've intentionally allowed despite the consequences
<Griwes>
you... you really have no clue how anything works
<Griwes>
I'm going to ignore you now
<Mutabah>
Optimising compilers are HARD
<zid>
Thank fuck for that
<kazinsal>
the bugID for it being basically closed with "fine by default, doesn't happen when you add the sanitize ub flag" does make me think that they're *okay* with this
<zid>
you weren't even part of the conversation
<kazinsal>
imo if UB is allowed to do things like this, -fsanitize-undefined should be default
<Mutabah>
... that said, looking at the original code, I'm surprised that it did't emit a `ud2`
<Griwes>
it's fine by me vOv they've got more important things to work on
<kazinsal>
Mutabah: in the comments for the bugID the clang devs claim that emitting a ud2 is too costly for space in the resulting binary
<zid>
yea if it emitted an ud2 it'd be excusable at least
<zid>
but if their excuse is "ud2 is too big whaa" then they just need pillorying
<kazinsal>
oh no my two precious bytes. ha ha hard drive formatter go brrrr
<zid>
Compilers are for writing software with, not wanking over openbenchmark.org/compiler/ud2/speed
<zid>
Those things are *secondary*
<Mutabah>
You'd think that...
<zid>
I assume it's just the class of people who are willing to dive super deep into compiler internals
<Mutabah>
but people get really grumpy when a compiler upgrade causes performance regressions
<bslsk05>
bugs.llvm.org: 49599 – Signed integer overflow causes program to skip the epilogue and fall into another function
<zid>
Okay the bloaty thing is because it requires a global flag to make it apply to *all* unreachables?
<kazinsal>
one of the stated "solutions" is "use a different linker"
<kazinsal>
which is also an incredibly dense take from the compiler devs imo
<zid>
Literally nobody considered "revert the code that did this until it stops doing it"
<Mutabah>
It's UB
<zid>
Yup, sure is.
<Mutabah>
The compiler is allowed to do anything.
<zid>
UB should not be an excuse to be as insane as possible however.
<Mutabah>
It's not chosing "as insane as possible"
<Mutabah>
There's nothing there that picks the worst possible option. In fact, you could say it's picking the best topion
<Mutabah>
The one where a completely empty function is emitted (thus taking up no space in the output)
<zid>
What's more insane? Given the constraints of "they're at least trying to achieve something, like code speed, with these UB outcomes"
<kazinsal>
I think since f1 doesn't have attribute((noreturn)) it should at least emit a ret
<kazinsal>
that is imo the largest failing here -- UB aside the function is not being compiled as per the attributes of the calling convention
<zid>
In what universe do I as a programmer when I *accidentally* write an infinite loop into my program, want the compiler to "run a different piece of code instead", rather than a diagnostic to let me know that's what I did, given clang clearly knows I did so else it wouldn't have deleted the loop
<kazinsal>
if "optimize out UB" is an acceptable method of handling then optimizing out the for loop should not result in optimizing out the ret
Jari-- has joined #osdev
<zid>
"The compiler can do what it wants" is not news, but "it does something not even remotely helpful to anybody" is an incredibly poor outcome. "I've solved the famine, I shot all the citizens!"
<Mutabah>
Clarification: I think that the clang team should make the compiler do something here to trigger a crash instead of running into another function...
<Mutabah>
but, UB is UB. Maybe it's my rust shining through, but UB is the programmer's problem
<zid>
"just be perfect and we won't put root exploits into your code" sounds like rackteering :P
jack_rabbit has joined #osdev
<zid>
"It'd be a shame if someone were to run this unrelated setguid code if you happened to forget a loop conditional somewhere"
<zid>
Literally "somewhere" too, not at the site of the loop
<kazinsal>
hmm. upon testing, the compiler admits that, despite all this, f1 and f2 are not the same function. since they're not the same function, but they have the same address, this is against the spec
knusbaum has quit [Ping timeout: 255 seconds]
<kazinsal>
this behaviour is not compliant with the C++ standard
<Mutabah>
That bug is still open, and has a lot of interesting discussions
<bslsk05>
en.cppreference.com: C++ attribute: no_unique_address (since C++20) - cppreference.com
<Mutabah>
Compilers are hard
<zid>
some silly optimization the spec allows for empty functions to not need a byte of object
<zid>
because of templates
<Mutabah>
If it's important to you, you could discuss it on the clang/llvm forums/channels and see if you can push towards the issue being fixex
<zid>
I'm thankfully immune to this because I don't write C++ or use clang :P
<kazinsal>
I write very little C++ these days but I wouldn't mind switching to clang at some point
<kazinsal>
if only to free myself of gnu
<stephe>
what is the best beverage to consume when writing assembly code
<kazinsal>
bourbon. bottom shelf.
<Mutabah>
Water, keep hydrated
<geist>
oh that reminds me i have some patches against LK to enable clang. need to rationalize them a bit since each patch is incomplete
<stephe>
you sweating a lot when writing assembly code? :)
<geist>
tis the general curse of build system stuff from users downstream: everyone has their one use case they submit a patch to that breaks everything else
<zid>
It's the steam coming off his head
<zid>
Mutabah's like a racehorse that was put away wet
<kazinsal>
oh, something I discovered today -- for anyone who remembers those terrible Killer brand NICs, Intel purchased them and all new Killer brand NICs are just I225s with a different PCI device ID
<zid>
yea I did hear killer nic was back vaguely
<geist>
ahah nice
<Mutabah>
zid: I live in Australia, during my prime coding season (christmas leave) it's F___ing hot
<zid>
were they actually terrible? I heard they were just little linux computers on a pci card
<zid>
obviously nonsense in terms of 'hurr' factor, but.. rpi before rpis existed
<kazinsal>
they were pretty unreliable. basically dedicated embedded SoCs doing "hardware offload" in questionably written software bolted onto inexpensive atheros NICs
<geist>
hurr factor is srs bsns
<zid>
it's a shame they were crap, but you could ssh into the SoC as far as I know
<zid>
I heard all sorts of silly things people did with them
<geist>
probably some osdev hacker was like 'oh shit i can write a little kernel that hacks packets' and then figured out how to sell it
<zid>
Basically a cheap linksys router on a pci card
<kazinsal>
someone on SA mentioned that they were concerned about ASRock's X670 boards all only having Killer NICs so I did some digging and discovered that they're just regular Intel 2.5GbE NICs with an ID of 8086:3100
<zid>
I only support 100E, rip those guys
<kazinsal>
datasheet says the capabilities are identical to the I225-LM
<moon-child>
I realised that a minute later. But it doesn't make any sense byteswapped either
<moon-child>
xor ch, ch??
<Mutabah>
beware if you're using objdump, pad with CC for a good 6 bytes more
<moon-child>
and it still has push rbp :P
<zid>
did you try all possible alignments? :P
<moon-child>
zid: at some point I'm gonna do a fancy graph-disassembler that does that automatically...
<zid>
I remembered I should probably initialize RSP, but it didn't fix it, now I'm out of ideas
vdamewood has quit [Read error: Connection reset by peer]
Jari-- has quit [Ping timeout: 246 seconds]
vai has joined #osdev
vai is now known as Jari--
vdamewood has joined #osdev
jafarlihi has joined #osdev
jafarlihi has quit [Ping timeout: 255 seconds]
jafarlihi has joined #osdev
<jafarlihi>
What is gcc '-lk" flag?
<jafarlihi>
It's in meaty skeleton
<moon-child>
-lfoo means link to libfoo
<stephe>
theres a libk.a in the libc/Makefile, so guess it just links that in
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
<kazinsal>
in traditional unix argument parsing style, the space between a single character argument eg. -l and its parameter eg foo can be omitted
<kazinsal>
-l foo and -lfoo are usually parsed the same
jafarlihi has quit [Ping timeout: 255 seconds]
kingoffrance has joined #osdev
Likorn has joined #osdev
jafarlihi has joined #osdev
<jafarlihi>
Will I regret it later if I use only a single Makefile at the root to compile all libs and shit?
<kingoffrance>
eh, i like interceptor pattern. single place to override. so i tend to try to route things to single area on purpose
<kingoffrance>
serenade the code down a primrose path, and then snap its head off when its not looking lol
<kazinsal>
I use one per major compilation basically
<kazinsal>
each library gets one, and then the kernel has one big thicc one that makes everything
<kazinsal>
and then a top-level shell script directs it all
Burgundy has quit [Ping timeout: 258 seconds]
<jafarlihi>
Do you need to link in shit like crti and crtn if you are not gonna be using cpp?
<klange>
You mean if you're not using C++? C++ is not the only thing that might populate init/fini sections.
jafarlihi has quit [Ping timeout: 244 seconds]
jafarlihi has joined #osdev
<jafarlihi>
klange: Like what?
<geist>
kingoffrance: i'll have to remember that one :)
<klange>
__attribute__((constructor))
<kingoffrance>
encapsulation -- code is on a need to know basis
nyah has joined #osdev
sortie has quit [Ping timeout: 272 seconds]
sortie has joined #osdev
<geist>
wow, was just glancing at the e810 ethernet datasheet someone linked a while back. it's a pretty super serial ethernet interface
<geist>
clearly an extension of the previous e1000 stuff
GeDaMo has joined #osdev
<gamozo>
Right!?
<gamozo>
I'm pretty sure it's just a few tweaks to get an e1000 driver working for it
<gamozo>
Honestly, Intel's NICs are just so nice to write drivers for. Super straight forward, and you can get a lot of perf out of them with even the most basic driver
mykernel has joined #osdev
<jafarlihi>
Does GRUB intentionally does BIOS interrupt 0x10 to set VGA mode to "text 80*25 16 color"? Does system have default VGA mode before GRUB?
<kingoffrance>
no idea, but i have not seen anything implying sucha default. besides, there was not just VGA :) EGA CGA see ralf brown's interrupt list... and headless :)
<kingoffrance>
there are text "pages" i have not seen anything guaranteeing those either
<klange>
With BIOS, there are no guarantees as there is no spec, only the collective amalgamation of things implementations happen to align on.
<kingoffrance>
^ ralf brown much of it is "but this system might do this, etc."
Burgundy has joined #osdev
<klange>
Grub will specifically put you in text mode if you didn't request a video mode in your headers. You can also manually request text mode if you did ask for a graphics mode.
<klange>
(see 'gfxpayload' grub variable; set it to 'text' for text mode, or a resolution (WxH or WxHwD) for graphics mode, or 'keep' for "whatever grub is in" though I think that is specifically graphics modes)
<kazinsal>
the pro tier move is to just ignore the vga console and just assume there's a proper console attached to the serial port
<kazinsal>
and thus assume the terminal on the other end of the serial port can respond to your vt100 and xterm crap happily
<kazinsal>
easier than implementing all of that in vga text mode
<kingoffrance>
^ do the same with loading code if you are crazy like a fox :)
<bslsk05>
github.com: xv6-public/kbd.h at eeb7b415dbcb12cc362d0783e41c3d1f44066b17 · mit-pdos/xv6-public · GitHub
<GeDaMo>
It's a hexadecimal value
<jafarlihi>
Why is it inside brackets and what is it doing in char array initialization?
<kazinsal>
it's an offset in a compound constructor (someone more sober than I am should correct that description)
<kazinsal>
the definition of that static uchar shiftmap[] skips to [0x9C] and plants a '\n' there, then on the next line it jumps to [0xB5] and plants a '/' there
<jafarlihi>
Oh cool. What is it called?
<kazinsal>
no idea, I don't think I've ever used that kind of explicit placement syntax before
<kazinsal>
mostly because it leaves the intermediate bytes in the structure not explicitly defined
<jafarlihi>
This page https://wiki.osdev.org/Detecting_Memory_(x86) says that a memory region reported by GRUB memory map as available might be used by your kernel. How do you know what kernel occupies? Do you know by labels in linker script?
<bslsk05>
wiki.osdev.org: Detecting Memory (x86) - OSDev Wiki
<jafarlihi>
Should you go over whole memory map reported by GRUB in your page frame allocator and cook your data structures to avoid holes?
jafarlihi has quit [Quit: WeeChat 3.5]
jafarlihi has joined #osdev
ripmalware_ is now known as ripmalware
<jafarlihi>
What is the difference between "size" and "length" fields of multiboot_memory_map_t?
<mykernel>
is gcc using stdcall or cdecl by default
<jafarlihi>
mykernel: cdecl
the_lanetly_052 has quit [Ping timeout: 240 seconds]
<mykernel>
then, when i want to retrive movl 8(%ebp), %eax # accessing first argument
<mykernel>
^ to acces first parameter, and caller function will then clear this
<mykernel>
access
sonny has joined #osdev
sonny has left #osdev [#osdev]
<mrvn>
jafarlihi: the memory map can have holes but also overlaps.
<mrvn>
mykernel: why are you still doing a 32bit kernel?
<mykernel>
too much work to switch to 64bit
<mrvn>
It's one file with a screenfull of asm.
<zid>
jafarlihi: where ‘size’ is the size of the associated structure in bytes, which can be greater than the minimum of 20 bytes. ‘base_addr’ is the starting address. ‘length’ is the size of the memory region in bytes.
<zid>
size is the stride of the struct entries, each entry describes a {base, length, type} region of memmory
jafarlihi has quit [Ping timeout: 260 seconds]
xenos1984 has quit [Read error: Connection reset by peer]
the_lanetly_052 has joined #osdev
Likorn has quit [Quit: WeeChat 3.4.1]
Jari-- has quit [Ping timeout: 260 seconds]
xenos1984 has joined #osdev
gwizon has joined #osdev
gwizon has quit [Client Quit]
<zid>
wish qemu had reverse-stepi
pretty_dumm_guy has joined #osdev
<Mutabah>
it does, iirc, have a mode to trace all jumps
<zid>
any idea what the tracer name is
Ali_A has joined #osdev
Ali_A has quit [Client Quit]
Ali_A has joined #osdev
Ali_A has quit [Client Quit]
Ali_A has joined #osdev
<zid>
I suppose in theory I could make gdb spam stepi and log it :P
gorgonical has joined #osdev
<zid>
would need a way to stop it though
<gorgonical>
Long time no see everyone. Anyway, in Linux's head.S for RISC-V there's a sequence I don't really understand. It isn't specific to Linux, either. In the MMU enable routine they briefly change to the trampoline pgtbl. The comments say that this causes a trap if VA != PA, but why do they do this?
<zid>
I don't know for sure, but it sounds like a really normal identity map trampoline
<zid>
where when you're dicking with the page tables, you need the memory that PC points to to still be there after you enable paging
<zid>
else you're going to have a REALLY bad time trying to execute the instruction after the one that enables paging
<zid>
so on x86 the kernel is often at 0MB/1MB or such, and enables paging to put itself up at -2GB instead. That requires temporarily mapping 1M to 1M so that the paging code itself can turn paging on, then you jump to -2GB, then you remove the 1M mapping.
<gorgonical>
Okay but why do this when we're just a few lines from starting the regular kernel pts?
<zid>
It's sounds like they're doing the same thing
<gorgonical>
Because AFAICT the sequence goes directly like this: load trampoline pts -> setup a holding pen in the trap vector -> reload the global pointer (another question I have) -> load kernel pts
<zid>
I don't know anything about risc-v so I can't answer, that was just my best guess based on similar stuff
<gorgonical>
Yeah it's a little murky. Even less information and blogs online than with arm64
<zid>
if it's in the mmu init, and is called a trampoline, they probably need to do similar trickery for some reason
<zid>
Mutabah: -d cpu gives cpu tracing at least, but I need to enable it and disable it on certain boundary conditions else universe heatdeath issues :(
<zid>
the terminator I can probably do just by breakpointing int_pf in gdb stub at least
<zid>
btw idk how to get the 50 billion instructions it takes out of the way first
<zid>
I'll maybe go ask oftc
eroux has quit [Read error: Connection reset by peer]
eroux has joined #osdev
eroux has quit [Client Quit]
nvmd has joined #osdev
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
<mrvn>
gorgonical: is this during boot?
<gorgonical>
Yeah, in the kernel's head.S
<mrvn>
gorgonical: so the code runs in physical memory and wants to end up running in virtual memory in higher half.
Burgundy has joined #osdev
<mrvn>
You can't switch on the MMU *AND* jump to higher half at the same time. So first you switch on the MMU with an identity mapping so it's totally transparent. And then you jump to higher half and remove the identity mapping.
<zid>
okay `log cpu` is the toggle
<zid>
watching it paint the screen in realtime is kinda funny
<zid>
It's doing about a scanline a second, and my 140p display needs to do a couple hundred frames.. back in a few hours I guess
<mrvn>
gorgonical: I suspect the "trampoline_pg_dir" is a small page table with minimal identity mapping to bring up extra cores.
<mrvn>
"only correct for the first superpage"
<gorgonical>
So you're seeing that there's such a short gap for turning trampoline pts and then the kernel pts. In the beginning we relocate the return address to the virtual address, so as long as we are running valid pts by the time we do ret we end up on virtual addrs
<mrvn>
gorgonical: the holding pen, if I understand this right, is just there in case someone messed up to make the core loop forever instead of running wild all over the system.
<mrvn>
e.g if you call this again when already in virtual space
<gorgonical>
So you're suggesting that the trampoline pts are a guard?
<mrvn>
No, the trampoline has the identity mapping that allows you to jump to higher half.
<gorgonical>
The only purpose being that you don't want idmap pages in the real kernel pts?
<mrvn>
gorgonical: the trap vector is the guard
<mrvn>
gorgonical: yes
<mrvn>
as far as I understand from this little bit of code
<mrvn>
Kernels generally don't like anything mapped at 0 to catch nullptr access.
<gorgonical>
That would make sense. So if you write the kernel pts at the end there's still two instructions. What happens at those PCs?
<gorgonical>
Because the PC loaded there should be the physical one, right?
<mrvn>
which line?
<gorgonical>
After 123 before the ret
srjek has joined #osdev
<gorgonical>
Are we relying on that ifetch is wide enough that the fence and ret are already in there?
<mrvn>
"because that first superpage is translated the same way" sounds like the page is still mapped. But then why the trampoline?
<gorgonical>
Because the way I see it if the kernel has a PA != VA mapping for this bit of code then once we switch to the kernel pts we will page fault on ifetch down the line here. That's why we fixup/relocate the return address at the top, so we return to the virtual address version
<gorgonical>
Hmm indeed
<gorgonical>
So this whole block is also mapped in to the kernel pts
<gorgonical>
superpage/block of code/whatever
<mrvn>
I'm missing a "jmp <label>" in there to get into the new address space
<mrvn>
sorry, no idea what magic they do there.
<gorgonical>
At the very top by the label they do some math on ra (return address) to, I think, change it to the virtual address instead
<gorgonical>
Lines 80 or so
<mrvn>
look at what stvec does, maybe that explains it.
<gorgonical>
stvec is the trap vector register base
<gorgonical>
Unless writing to stvec has some unusual effects I haven't read yet
Matt|home has quit [Quit: Leaving]
<gorgonical>
trap vector base register*
<mrvn>
gorgonical: might it be that the code is supposed to trap? It's setting the trap vector to the instruction after loading the page table.
<mrvn>
So if it has to relocate it traps and jumps to the new address.
<mrvn>
if it's already at the right place it doesn't trap and falls through.
<gorgonical>
That only modifies the control flow if la a0, trampoline_pg_dir would provoke the trap, right
<mrvn>
gorgonical: as the comment says: when PA != VA
<gorgonical>
I don't really understand what VA != PA means here. If we are here with higher virtual addresses already?
<gorgonical>
Or is this a "in case something is wrong" thing
<gorgonical>
VA == PA only under idmap, which only the trampoline pts will have, right?
<mrvn>
I'm thinking it might not be a "something i wrong" thing but an intentional trapping
Matt|home has joined #osdev
dennis95 has quit [Quit: Leaving]
<mrvn>
It might be intentional that the trampoline doesn't have an identity mapping so it traps to the virtual address and then continues.
<mrvn>
Have you tried booting in qemu with a breakpoint and single step the code?
<gorgonical>
Oh I think you may have just figured it out
<gorgonical>
I think the ra ret fixup is a red herring
<mrvn>
gorgonical: at the top the code checks for 3 different RiscV setups. So it might do one thing on one of them and another on the rest.
gog has quit [Quit: byee]
<mrvn>
Might just be some clever way to make it work in all cases.
gog has joined #osdev
<gorgonical>
I think that's it. That's the jump to virtual address space, the trap vector is what actually jumps us to virtual memory
<gorgonical>
about qemu; no I haven't, I'm still in the flowchart and writing down my thoughts stage
<gorgonical>
I should definitely try that to confirm, though
dude12312414 has joined #osdev
<gorgonical>
The second mystery is why you would reload the global pointer
<mrvn>
because it will probably point to the physical address of the .GOT
<gorgonical>
But we already load it in _start_kernel. Does the address somehow change?
<mrvn>
gorgonical: that runs in physical space
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
<gorgonical>
Right. But the value in __global_pointer$ is gonna be the same both times, right?
<mrvn>
should be. it's not adjusted to the phyical address?
<mrvn>
and is _start_kernel run for all cores or just the primary core?
<gorgonical>
I think _start_kernel may be only the primary
<gorgonical>
So if the global pointer address will be same in both cases why reload it?
<geist>
hmm, trying to read the backlog
<geist>
but. this looks pretty standard. my code does basically the same thing
<mrvn>
so why the trampoline and not use the kernel page table to jump directly to it?
nvmd has quit [Quit: WeeChat 3.5]
<geist>
usual reasons: you have the turn on the mmu, and so you need the code the cpu is at to be mapped
<mrvn>
but you don't since that causes the trap and jump to the virtual address
<geist>
so you set up the new page tables with an identity map, then enable the mmu
<geist>
okay so i dot follow
<mrvn>
I don't see how the code would switch to virtual space if it doesn't trap.
<geist>
oh are they doing the vector table trap to the final address trick?
<mrvn>
looks like it
<geist>
ah okay. yeah that's the other way to do it
<mrvn>
Also looks like it also works with running the kernel in lower half with PA=VA
<geist>
just map the kernel to its final location, est the vector table to trap to it, and then enable the mmu, let the cpu bounce to it
* geist
nods
<geist>
what it doesn't work is 32bit cases where the physical address is kinda offset from virtual
<geist>
but i dont think linux cares about that
<mrvn>
I think that trick should remove the need for a trampoline.
<geist>
that's always a tricky case
<geist>
possibly. do they still set up a trampoline?
<mrvn>
PA=VA just keeps running, PA != VA traps and goes virtual.
mykernel has quit [Quit: leaving]
<mrvn>
yeah, that's what he was asking about.
<geist>
well, if they set up an identity map then it wont trap
<geist>
so then presumabky after enabling the mmu they do a hard branch
<geist>
just to double check
<mrvn>
except there is no branch
<geist>
ah then i dunno, probably is or it's something implicit
<geist>
bummer they dont comment it enough to be ovious
<geist>
but that's par the course
<mrvn>
Maybe it used to be with a branch and hence the need for a trampoline but then someone added the trick with the trap but never removed the trampoline.
<geist>
but that sounds weird, because if the trampoline is still there then it wont trap most of the time and thus not work
<geist>
so there must be something that someone is missing here
<geist>
like it implicity triggers an exception in a non obvious way
<mrvn>
Maybe the tramopoline is there because the kernel page tables have an identity mapping and wouldn't trap. The trampoline on the oither hand has no such mapping and traps.
<mrvn>
Kind of the reverse of the usual setup.
<mrvn>
I think the best way to tell is to set a breakpoint in qemu and look at the mappings and single step the code.
terminalpusher has joined #osdev
<geist>
yep
<geist>
as a side note i've thought of doing the trap to get to higher half thing for arm64 at least
<geist>
someone even submitted a PR for it. makes sense, and it cleans up the code, but i worry there's some situation that's non obvious where it'll fail
<geist>
or more importantly some *device* where it'll fail
<mrvn>
Can you do that on ARM too?
<geist>
i dont see why not. really you should be able to do it on any arch that doesn't just totally crash in an unpredictable way
<mrvn>
I guess. it's just like a normal page fault except you never return.
<geist>
the ergonomics are mostly dictated by how easy it is to set up a fake vector table
<geist>
based on the arch. riscv is the simplest since there's literally one vector
<mrvn>
and you have to fence the icache so it actually fails
<geist>
that's the part i'm worried about
<geist>
technicly speaking it's probably UNDEFINED in arm world exactly where it triggers
<geist>
but an ISB after the enabling of the mmu should do it
<geist>
or, question is if you do something like `mov x0, address_of_kernel; msr sctlr,enable_mmu_bit; b x0; isb` does that sometimes take the branch?
<mrvn>
would it matter?
<mrvn>
More importantly: Would it sometimes fail but then jump to the old vector?
mrlemke_ has joined #osdev
mrlemke has quit [Ping timeout: 244 seconds]
<geist>
i dunno. i worry it might trigger some sort of fatal exception that EL3 catches, or makes an emulator unhappy, or something like that
<geist>
but cant think of any
gog has quit [Ping timeout: 246 seconds]
<geist>
but i have to be pretty careful since the ARM and arm64 bits of LK are used by lots of folks downstream that wouldn't necessarily have the capabiity to debug it
<geist>
so probably better safe than sorry
Likorn has joined #osdev
<mrvn>
I see the biggest benefit in not having to build the identity mapping in the page table. The jump is a trivial thing.
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
srjek has quit [Ping timeout: 260 seconds]
jafarlihi has joined #osdev
<jafarlihi>
I followed the Higher Half Bare Bones and set up paging but my multiboot info argument broke. It crashes as soon as I try to access the "flags" field. It is passed to kernel_main as 0x10000. I tried adding 0xC0000000 to it but it still crashes. Any idea why?
ripmalware_ has joined #osdev
ripmalware has quit [Ping timeout: 246 seconds]
<geist>
Crashes how?
<geist>
Also are you accessing the multi boot info before or after enabling paging?
<jafarlihi>
Not sure how it crashes, just reboots QEMU and it complains about not being able to boot. I access multiboot info in C after turning on paging in asm.
<mrvn>
ask qemu to tell you why, turn on debug output
ripmalware_ is now known as ripmalware
<jafarlihi>
Doesn't log anything, just says that could not read the boot disk
<Griwes>
I don't think you've followed the 'turn on debug output' part of the instructions
mahmutov has joined #osdev
<mrvn>
or it isn't even bvooting the kernel at all
<jafarlihi>
It boots as soon as I remove the access to flags field
<jafarlihi>
Griwes: How do you do that? I googled it and added -D flag
<Griwes>
you mean -d int?
dude12312414 has quit [Remote host closed the connection]
dude12312414 has joined #osdev
<gorgonical>
mrvn: I sent the original author an email and he replied very promptly and I think I understand the deal with the trampoline pages now
<jafarlihi>
Griwes: It's not helping
<Griwes>
have you read the output it produces? what exceptions do you see?
<gorgonical>
Basically he's saying that because of the way the bootloaders vary we know little about how the page tables are set up. Basically, the bootloader page tables might have VA=PA and they might not, and that code snippet allows us to get to VA-land in either case
<jafarlihi>
It doesn't log anything to the file, but says could not read the boot disk in application
xenos1984 has quit [Read error: Connection reset by peer]
<gorgonical>
The thing with the _global_pointer$ is that it's PC-relative, so you can relocate that into VA-land by reloading it, since that's also PC-relative
<Griwes>
jafarlihi, that sounds like it's not booting your thing
<jafarlihi>
Yes but it goes away as soon as I remove printf("%x\n", mboot_header->flags);
<Griwes>
what if you add a for(;;); somewhere before that line?
<mrvn>
gorgonical: is your kernel still multiboot with that line? Your linker script might be broken.
<jafarlihi>
Griwes: boots normally then
<Griwes>
so it's either faulting somewhere in that instruction, somehow, and -d int should give you a print of what's going on, or you are making your binary not multiboot at a specific instruction stream
<Griwes>
oh, duh
<Griwes>
are you doing this with -enable-kvm?
<jafarlihi>
no
<Griwes>
okay. asking because -d int doesn't function (or at least not well?) with kvm
<bslsk05>
wiki.osdev.org: Exceptions - OSDev Wiki
<jafarlihi>
so it's a page fault?
<Griwes>
you may want to use -no-shutdown -no-reboot too, that'll make it stop at triple fault and not close, so you can use the debug console to inspect things
<Griwes>
specifically, what you want to inspect when you get a page fault is `info mem` and possibly `info tlb`
<jafarlihi>
ok thanks
<jafarlihi>
I access QEMU with vncviewer, how do I get to the debug console? CTRL-ALT-3 doesn't work
<Griwes>
you're starting it from a terminal, right? -monitor stdio will give it to you in the same terminal you run the command in
<jafarlihi>
that works
xenos1984 has joined #osdev
Ali_A has quit [Quit: Connection closed]
<jafarlihi>
I've got two mappings: 00000000c0100000-00000000c010d000 000000000000d000 -rw
<bslsk05>
wiki.osdev.org: Higher Half x86 Bare Bones - OSDev Wiki
<jafarlihi>
Something must be wrong with it
<jafarlihi>
I can't quite decipher it
dh` has quit [Quit: brb]
jafarlihi has quit [Ping timeout: 256 seconds]
dh` has joined #osdev
srjek has joined #osdev
GeDaMo has quit [Quit: There is as yet insufficient data for a meaningful answer.]
mykernel has joined #osdev
gildasio has quit [Quit: WeeChat 3.5]
Matt|home has quit [Ping timeout: 246 seconds]
terminalpusher has quit [Remote host closed the connection]
dude12312414 has quit [Remote host closed the connection]
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
floss-jas has quit [Ping timeout: 255 seconds]
Oli has joined #osdev
mahmutov has quit [Ping timeout: 240 seconds]
mykernel has quit [Quit: leaving]
Oli has quit [Quit: leaving]
Oli has joined #osdev
<gorgonical>
I've started reading papers about risc-v and stuff and it absolutely blew my mind to realize that with risc-v you can design a chip in verilog and then transform it into an fpga map and actually just run it
<gorgonical>
I'm learning maybe I should have done computer engineering instead of or along with computer science but the notion that you can just do it that way is incredible to me. So much room for interesting custom hardware with risc-v
<mrvn>
Can somone explain to me why when calling `foo(5)` the 5 isn't a constexpr? Why do I have to put the parameters into template parameters `foo<5>()` to make them constexpr?
Oli has left #osdev [#osdev]
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<moon-child>
because c++ sucks? :P
<moon-child>
it works that way in d
<moon-child>
ditto common lisp, more or less
_xor has joined #osdev
<LittleFox>
anyone with some uefi dev experience online? have a problem with SetVirtualAddressMap() not returning on some firmware (all encountered so far are Lenovo, but wide year range) - looking for ideas how to debug, what might be the cause and stuff