<geist>
you probably never got the -mmio version of virtio working, but it's not too complicated
<doug16k>
tedious declaration stuff I can steal for sure
<geist>
basically instead of using PCI there's a 4K window defined which combines the discovery + basic ring registers
<geist>
so you need at least that level of abstraction i your virtio solution, but that's about it
Arthuria has quit [Ping timeout: 264 seconds]
<clever>
geist: i think you need some similar stuff, to make the broadcom xhci work, since the mmio isnt on pci-e, just bare mmio
<doug16k>
ah.. the other access method
<doug16k>
I know what you mean
<doug16k>
not-pci one
<clever>
is xhci without pci more common?
<doug16k>
virtio-gpu
<doug16k>
xhci practically assumes pcie
<clever>
the rpi4-uefi stuff, basically claims the pcie xhci controller, is not pcie
<doug16k>
not strictly required though, you could make it not pcie
<clever>
because windows lacks drivers for the pcie controller
<doug16k>
you'd have to make something up to handle delivering IRQs for interrupters
<clever>
so the uefi pre-configures the pcie, and then lies to the os, claiming "oh, the mmio is over there, no pcie involved"
<doug16k>
there is more to the pcie part than just the BARs
<clever>
for the internal broadcom xhci, its got its own line to the GIC
<doug16k>
it also defines how interrupt messages are set up
<clever>
device-tree tells you the mmio window, and irq#, and then it "just works"
<doug16k>
yeah, you'd have to replace those pieces if not pcie
<doug16k>
discovery, BAR and interrupt delivery
<clever>
yeah, i can see how DT covers all 3
<clever>
discovery, walk the tree until you find a node with an xhci compatible
<clever>
BAR, the reg= tells you where the mmio window is, it cant be moved
<clever>
irq's, DT tells you which irq# on what irq controller
superleaf1995 has joined #osdev
<doug16k>
sophisticated ones would support a way to do per-cpu interrupters
<doug16k>
so if cpu 3 does a usb read, for example, the completion goes to cpu 3
<doug16k>
not cpu <where driver lives> then <ipi hop to kick other cpu scheduler>
<clever>
i think due to design choice limitations, peripheral irq's can only be routed to a single core of the bcm2711
<clever>
so you have no way to do that on a pi4
<doug16k>
yeah, they don't need to handle high parallelism
<clever>
the genet ethernet controller, can max out an entire core with its rx interrupts
<doug16k>
you need to be prepared to fall all the way down to no IRQ at all, and poll the PCI IRQ status bit in config space, if necessary
<clever>
and then you have nothing left for any other peripherals
<doug16k>
...in a perfect world
<doug16k>
the progression is: <yay MSI-X>, <alright MSI isn't too bad>, <seriously wire irq? I guess>, <you seriously want me to poll the interrupt status?>
<clever>
that reminds me, one of my old 486 laptops, i'm not sure if it had cardbus or pcmcia
<clever>
but when i popped my wifi card (802.11b) into it, the driver didnt work
<clever>
digging around, i found that the problem was irq routing
<clever>
either the acpi didnt declare it, or the wire wasnt wired!
<clever>
i tried to brute-force which irq, but none of them worked
<clever>
and based on how shared irq's work in linux (calling a handler at the wrong time is harmless), i tried making it polling based (kernel timer runs irq handler)
<clever>
but that also didnt work
<kingoffrance>
"wire wasnt wired" reminds me of ep0 driver http://web.mit.edu/custer/Desktop/custer/MacData/afs/sipb/project/freebsd/head/share/man/man4/man4.i386/ep.4 "ep0: 3c509 in test mode. Erase pencil mark!" This means that someone has scribbled with pencil in the test area on the card. Erase the pencil mark and reboot. (This is not a joke)." i think i had one of those lol else i just remember reading it because i had similar dri
<kingoffrance>
ver maybe
<kingoffrance>
took me a long time to find that and verify i wasnt making things up from faulty memory
<clever>
kingoffrance: :O lol
<kingoffrance>
saves a plastic jumper i suppose
<doug16k>
need, ran this loop: declare -a virtworks=() && for arch in $qemuarches; do qemu-system-$arch -M virt -monitor stdio < <(printf 'q\n') && virtworks+=($arch); done and got: aarch64 arm m68k riscv32 xtensa riscv64 xtensaeb
<doug16k>
neat*
<doug16k>
the rest errored because it hated -M virt
<doug16k>
and didn't append it to the list
jjuran has quit [Quit: Killing Colloquy first, before it kills me…]
superleaf1995 has quit [Quit: Client closed]
jjuran has joined #osdev
iorem has joined #osdev
<doug16k>
so riscv32, xtensa, and xtensaeb should practically write themselves
<doug16k>
can maybe put this into a command line query thing. gimme a list of arches that can add this device or something
farcas has joined #osdev
farcas has quit [Ping timeout: 264 seconds]
<doug16k>
found reasons that way is a bad idea, trying grepping -device help instead
<doug16k>
this is actual list of arches that support secondary-vga: aarch64 mips64 alpha mips64el sh4 arm mipsel sh4eb sparc64 hppa i386 ppc ppc64 x86_64 x86_64-spice riscv32 xtensa riscv64 xtensaeb mips
<doug16k>
awesome
<doug16k>
getting every one of those bootstrapping the screen and wrangling the APs would be neat
isaacwoods has quit [Quit: WeeChat 3.1]
gog has quit [Ping timeout: 264 seconds]
Beato has quit [Ping timeout: 272 seconds]
<doug16k>
ah I could make it so the pci arches expect pci init did something, use pci bar information. otherwise they must just know the base addresses
<geist2>
booted up (well, started to boot) first time after creating a new arch, stubbing everything out (hence the unimplemented)
<geist2>
now i just gotta fill in the details. IRQ handling is going to be the fun one since 68k has a fairly wonky exception system
<geist2>
well, and the mmu
vin has quit [Ping timeout: 272 seconds]
vin has joined #osdev
Robbe has quit [Ping timeout: 272 seconds]
Robbe has joined #osdev
dh` has quit [Ping timeout: 272 seconds]
dh` has joined #osdev
<doug16k>
I need to make it easier to do a test run that distcleans, reconfigures, builds, and boots every arch, and each run turns itself off if it makes it to the end of main
<doug16k>
or maybe just leave them running
Mikaku has quit [Ping timeout: 272 seconds]
Mikaku has joined #osdev
<doug16k>
ah... I could read a line from fifo file which is attached to a chardev which is attached to a serial port. then take a screenshot with the monitor when the guest sends the "go" message line, and kill the guest
Bitweasil has quit [Ping timeout: 272 seconds]
Bitweasil has joined #osdev
<doug16k>
oh!!! what if I run an info mtree command in configure, and automagically set all the constants?!
<doug16k>
\o/
<doug16k>
then it's pci autoconfig or info mtree configure cheat
<doug16k>
and probably configure cheat the pci mmio
<doug16k>
in all but x86_64 and i386
<doug16k>
maybe even say screw it and use the ecam on those too :P
<doug16k>
uh oh, I am collapsing them all into one thing
<kingoffrance>
i forget the word for "heartbeat" type stuff "fencing" i think
<kingoffrance>
for physical machines, same thing though
<kingoffrance>
watchdog sort of
ZetItUp has quit [Ping timeout: 272 seconds]
<kingoffrance>
re: "screenshots" i thought about doing that for real macines, but not anywhere close to that
<kingoffrance>
a general mechanism i think that stuff is useful even outside of VMs
<kingoffrance>
at least for basic tests that nothing broke etc.
<doug16k>
yeah, it can be a great clue to go with a bug
<doug16k>
log might be ok but screen is funny
wgrant has quit [Ping timeout: 272 seconds]
<doug16k>
did someone make a doom bios yet?
<doug16k>
it powers up into doom like a cartridge-type console?
<doug16k>
press reset to get back to main menu
<doug16k>
maybe be the first to say "press hardware reset to continue", and advance to next screen of UI when they press reset
<moon-child>
somebody did a nes emulator in efi
wgrant has joined #osdev
<doug16k>
I wonder how they did the sound
<doug16k>
rest is fairly straightforward
<moon-child>
think it just didn't bother
<doug16k>
ah
<kingoffrance>
dreaming, but i think thats what anyone would do with unlimited funds. a lab with bunch of machines, all on relays, make sure at least major changes you didnt break anything, etc.
<doug16k>
in EFI, you could spin up an AP to do nothing but bitbang the PC speaker to PWM PCM buffers
<doug16k>
nevermind the timer, just turn it on and off with cpu
<doug16k>
use rdtsc to have the required determinism
thaumavorio has quit [Ping timeout: 272 seconds]
bsdbandit01 has joined #osdev
bsdbandit01 has quit [Read error: Connection reset by peer]
<doug16k>
I bet the PIT is sitting right there
<doug16k>
being a crappy little speaker like a TV might have had back then, might add to the nostalgia
thaumavorio has joined #osdev
<doug16k>
I need to get one of those old school actual speaker coils (not piezo one they use now) while they still exist
<geist>
huh just wrote the context switch routine on 68k. it's pretty trippy
<doug16k>
if you append this to a qemu command line, it tells you the pcie ecam range like "0000000030000000-000000003fffffff": -monitor stdio < <(printf "info mtree\nq\n")|grep pcie-ecam |grep -oP '(?<= )([0-9a-fA-F]+-?){2}'|sort --unique
<geist2>
motorola is like 'i know you like vax so i put some vax in your vax'
<geist>
cheat sheet is the instructions are left to right, and @ is a dereference of the register in front of it
<doug16k>
or @ means [0]
<geist>
yah it appears you can leave off () after it
<geist>
a0@ seems to equal a0@(0)
<doug16k>
ah
<geist>
but since both sides can be a memory reference you can directly do some stuff
<geist>
like ' movel %a1@(4), %sp@-' which loads from 4 bytes off a1 and pushes it on the stack while decrementing the stack pointer
<geist>
anyway i can see why folks were pretty religious about this arch. it's pretty powerful and clearly takes a lot of patterns from VAX
<geist>
contemporary x86 at the tme would have appeared to be a crappy clone
<kingoffrance>
reminds me of ++ --
<geist>
haven't looked at how the more compelx addressin modes work. this also appears to be an AT&T vs motorola syntax thing, since the motorola manual has a different syntax
<doug16k>
*whatever++ is optimal on m68k right?
<doug16k>
it doesn't like whatever[i] as much
<geist>
you should realy check out the manual. the number of addressing modes is pretty astonishing
<geist>
i'm counting 18 different modes
<doug16k>
for speed I mean
<geist>
oh who the hell knows
<geist>
i'm doing this almost entirely by cribbing what gcc has done via objdump and then mimicing it
<doug16k>
modern cpus love [i] because optimizers love [i], then the optimizer does best thing anyway
<geist>
thign is there was never a modern 68k. it just stopped
<doug16k>
yeah :(
<geist>
so possible at the tie it never got into 'please dont do this because it's hard for the OOO architecture to dealw ith it'
<geist>
taht being said there are tables for 030 and 040 and whatnot that explicitly talk about how much each addressing mode costs
<doug16k>
each instruction doing a lot means there is potential for extremely high code density
<geist>
yah from looking at the code coming out of the compiler it's kidna a wall of text
<doug16k>
nowadays they could run m68k deeply out of order, no problem, as long as you are ok with bad first time then flies in a loop
<doug16k>
yeah it generates a lot?
<doug16k>
maybe it is emitting fast code though
<geist>
well, i mean a lot of dense, wordy instructions
<doug16k>
that's what you do to go fast
<doug16k>
hand made slow dense code would use tons of memory to memory stuff and zero registers
<geist>
that being said i'm not seeing a lot of complex addressing mdoes
<doug16k>
like, would gcc do a load, then add, then store, scheduled out, or a read-modify-write add?
<geist>
seems to mostly be fairly simple register + immediate and mybe soe sort of post increment
<geist>
thoguh i do see a fair amount of memory to memory
<doug16k>
I always thought m68k would have good code density
<geist>
oh hey, clang has actual 68k support. no idea if it's any good,b ut you can use it on godbolt
<geist>
oh oops no.
<doug16k>
I love how the instructions to bring up godbolt are: type "god" in the address bar, and press enter
<geist>
ah looks like though there is new 68k support in clang, godbolt hasn't picked it up yet
<geist>
it's only months old so may not be enabled, or the toolchain hasn't been rebuilt
<geist>
-print-targets seem to show all the thing it knows
skipwich has quit [Ping timeout: 252 seconds]
<doug16k>
funny how qemu has no default machine for aarch64
<doug16k>
everyone would be so jealous of the winner that nobody can win :(
<doug16k>
how is virt not the default. something strange going on there
<doug16k>
virt == native as hell
<doug16k>
isn't it?
<geist>
virt is mostly there for KVM style virtualization
<geist>
ie, dont pretend to be emulating a real machine
<geist>
but i think it's taken on a life of its own as you see it for thingsl ike 68k which will never get KVM
<doug16k>
hmmm. I suppose if you were probing for configurations, you would see the message needing -machine and recurse into a -machine help parser and do each of those
<doug16k>
maybe failing is by design
<doug16k>
sometime I want to see how many pci devices I can jam into qemu, if I put my mind to it
<doug16k>
bridges upon bridges or something
<doug16k>
expander?
<doug16k>
I bet you I find a bunch of array overruns
<doug16k>
you can corrupt it with too many secondary-vga
<doug16k>
you can segfault it too
<doug16k>
I mean qemu core dumps
<doug16k>
I could just take the info mtree verbatim, and link it into the rom, and parse it at runtime
bsdbandit01 has joined #osdev
bsdbandit01 has quit [Read error: Connection reset by peer]
superleaf1995 has joined #osdev
<riverdc>
is there a standard way to include data (i.e. console font) in the kernel itself, before I implement a filesystem to load from?
<superleaf1995>
put it on rodata
<superleaf1995>
aka: const array
<riverdc>
kk
<klange>
fifty years with the language and there's still no good way to just throw a file at it and get a symbol, but there are several bad ways
<kazinsal>
yeah, my preferred bad way is to just craft an assembly language file that does it
<bslsk05>
github.com: toaruos/vga_font.c at old_kernel_shell · klange/toaruos · GitHub
bsdbandit01 has joined #osdev
<superleaf1995>
just use the magic `xlatb` instruction
bsdbandit01 has quit [Read error: Connection reset by peer]
<moon-child>
xxd -i
<moon-child>
but hey, #embed is coming Soon™
<klange>
There's some ld incantation, and graphitemaster's incbin
<klange>
the latter of which is named for the assembler directive of the same name
<klange>
I had a text file I was including in a source for Kuroko (it was bootstrapping some stuff with managed code) and I discovered there really is a limit to how long a char[] constant can be in gcc.
<klange>
(Kuroko no longer bootstraps itself with any managed code, mostly because it made debugging a nightmare, and it was slow)
<moon-child>
yeah, wouldn't want to xxd any huge media files. But it should be fine for a dinky bitmap font you use before fs stuff is done
<klange>
I should switch my dinky bitmap font to binary literals.
<klange>
My old one used a macro for it, but since I rely heavily on gcc extensions anyway, should just use the native ones...
<klange>
I even had a syntax highlighting rule in Vim to make them look cool in the editor.
<klange>
I should bring that back for bim...
<klange>
wait i had a :tohtml for this somewhere...
superleaf1995 has quit [Ping timeout: 250 seconds]
srjek has quit [Ping timeout: 264 seconds]
<graphitemaster>
Yeah incbin is solid, just remember to manually add each incbin file to your deps list in your Makefile for each file the macro is used :P
<graphitemaster>
Otherwise if you change your incbin files make can't see them and rebuild source files that include them.
<graphitemaster>
Only downside :(
<graphitemaster>
Alternatively, just force the source file to always rebuild that you incbin shit
<bslsk05>
'How does a USB keyboard work?' by Ben Eater (00:34:15)
<geist>
nothing i hadn't seen before from piddling with usb, but it's neat to see it scoped out
<Mutabah>
I knew the protocol layer stuff... mostly, but the translation to electrical is neat
<geist>
alas my rigol has some decode ability but not usb
<Mutabah>
Might be able to "find" some unlock codes?
<geist>
lets say hypothetically i did, i dont think they have usb in their decoders
<geist>
not that i need it anyway, i have a real usb bus analyzer
<Mutabah>
That works ;)
<geist>
but it has some simple decoders like serial and i2c and whatnot, which is pretty useful
<klange>
The most annoying thing with wifi is it's almost always hands-off requests to a firmware, and the hardest part is half of them from this era required you to load the firmware blob.
<klange>
And still they won't release datasheets for the interface to do that...
piotr_ has quit [Remote host closed the connection]
piotr_ has joined #osdev
farcas has quit [Ping timeout: 272 seconds]
zhiayang has quit [Ping timeout: 272 seconds]
zhiayang has joined #osdev
MarchHare has quit [Ping timeout: 264 seconds]
kazinsal has quit [Ping timeout: 272 seconds]
kazinsal has joined #osdev
sm2n has quit [Read error: Connection reset by peer]
sm2n has joined #osdev
cultpony has quit [Ping timeout: 244 seconds]
cultpony has joined #osdev
<kingoffrance>
i was gonna say "code released" you mean firmware blobs :)
<kingoffrance>
its better than that. some drivers only work with certain firmware versions
<kingoffrance>
so if you have really old wifi like a pci card...that means boot to dos to flash
<kingoffrance>
find the ancient utility
sortie has joined #osdev
piotr_ has quit [Remote host closed the connection]
koolazer has quit [Ping timeout: 272 seconds]
koolazer has joined #osdev
<doug16k>
klange, they can put all their secrets in the blob, and not be terrified half to death that you are going to steal it. I think that is how they see it
<kazinsal>
I think the "proper" way to support wireless in a hobby OS is to just support whichever ones OpenBSD does.
<klange>
That's what irks me about it, though, if all the secrets are in the blob, why won't you tell me how to turn on the card and talk to the blob so I can do the not-secret stuff?
<klange>
But yeah, as much as I want to have a datasheet so I can bash my head against my desk until this works with only my name in the copyright header, if I want to use this card - or any other wifi chipset - I'm going to need to import a BSD driver.
<doug16k>
they want that last miniscule bit of security, by obscurity
<klange>
Anyway, back to the tethered world...
<doug16k>
I send emails to companies asking for information about their registers, maybe once a year, just for a laugh
<j`ey>
lol
<j`ey>
ever get a response?
<klange>
I'm sure there's some intel names in my contact list I could pretty-please for a datasheet for a decade+-old card... right?
<doug16k>
almost always get apologetic negative, definitely not now, not ever, and never
<klange>
maybe I should try some of the names from the actual driver sources
<klange>
bah, must finish new network stack before even thinking about wireless support for it...
<doug16k>
couple of times I replied "yeah but they already bought it, I just want to make your stuff work, for free!"
<klange>
can frob the bits and get an IPv4 address out of DHCP, works on hardware with a real router, now I need to switch this API over to the sockets interface...
<doug16k>
you did the raw stuff for your dhclient like you mentioned?
<klange>
I even improved it to actually look at the DHCP stuff and get the netmask, gateway, and dns, instead of just doing the bootp stuff.
<doug16k>
nice
<klange>
* caveat: it just prints the the gateway and nameserver for now, as I intend to add route tables and have it shell out or call the relevant api directly / write /etc/resolv.conf or whatever, but good enough to demonstrate it's getting a proper response
<klange>
this is just a couple of dumb ioctls to a device file to set/get the various things, but that's better than the read-only, single-card interface I had in toaru32
<doug16k>
any ioctl at all is good
<doug16k>
it's individual then yeah
<klange>
would you happen to know how to put multiple nics on the same slirp network in qemu?
<klange>
oh, I have -netdev but I guess I want -net and -nic
<klange>
hm, no nic sounds like netdev but shorter...
<klange>
bleh
<doug16k>
I think you said it
<doug16k>
make the nic and carefully connect it to the same user networking
<geist>
oh woot, got exceptions and interrupts working on 68k
<klange>
"The hubport netdev lets you connect a NIC to a QEMU emulated hub instead of a single netdev. Alternatively, you can also connect the hubport to another netdev with ID nd by using the netdev=nd option."
<klange>
`-net user` gets me hub 0 connected to slirp, then instead of -netdev user I use -netdev hubport to add ports to that hub and attach those to nics
sham1_ has joined #osdev
<klange>
excellent, this is doing what I want and showing me the bug I was expecting to see
<sortie>
Someone needs to step up and fail to stop this unstoppable klange
chin123 has joined #osdev
<klange>
might need to break out the notebook and draw some diagrams to figure out what I'm doing at this stage...
<klange>
this is all talking directly to the two devices, so I have a sort-of device-bound raw socket interface through that; I need to switch it over to the standard socket interface, so you can socket(..., SOCK_RAW), SO_BINDTODEVICE, and then get the packets from your device... while those packets also go through a processing flow...
dennis95 has joined #osdev
Arthuria has joined #osdev
<klange>
weird to be digging into old c network stuff I made in my youth to understand what I'm doing here ;)
<doug16k>
I bet it has invalid xml and they don't notice, like x86 was
<doug16k>
it falls back to some other description, but qemu keeps obliviously using the same offsets, because it thinks qemu used the description
<doug16k>
it thinks gdb used*
<doug16k>
a reliable stub always gives a description - the fallback is just in case, it's a guess
<doug16k>
a vaguely sane machine description will start with all of the general registers contiguously, so that part of the guess is probably correct every time
<doug16k>
so you can hardly tell the machine description is screwed up
transistor has quit [Ping timeout: 264 seconds]
junon has quit [Ping timeout: 264 seconds]
isaacwoods has joined #osdev
junon has joined #osdev
bsdbandit01 has joined #osdev
bsdbandit01 has quit [Read error: Connection reset by peer]
junon has quit [Ping timeout: 252 seconds]
junon has joined #osdev
qookie has joined #osdev
<doug16k>
qemu-system-aarch64 is sending the 32 bit machine description to aarch64-*-gdb and it is rejected
<bslsk05>
www.andywest.org: What if Operating Systems Were Airlines?
<gog>
yes that's the one
<gog>
well sort of
gmacd has joined #osdev
<johnjay>
i guess now it's you still have to bring the seat but there is a cart and you have to go to github and clone the right seat for your comfort
bsdbandit01 has joined #osdev
<gog>
or if you get one of the pre-made seats you get a takedown notice for using bittorrent to download and share schematics
<johnjay>
> When you board the plane, you are given a seat, four bolts, a wrench and a copy of the file seat-HOWTO.html
<johnjay>
step 1 in that file is to run seatConfigure checklist, where you answer a long list of questions like "Check that your wrench is made of metal not clay" and "Verify metric system is in use for screws, nuts, and bolts"
<johnjay>
if the metric system check fails you go to a help forum and ask how to use imperial tools on metric nuts and screws
<johnjay>
for this purpose planeOverflow is created where everyone can go to ask such questions
bsdbandit01 has quit [Read error: Connection reset by peer]
<dh`>
what do you mean checklist? we don't do that in software
<johnjay>
It's part of the AutoTools Seatcrafting Manual issued to all airline service techs on Linux Airways
farcas has quit [Ping timeout: 245 seconds]
bsdbandit01 has joined #osdev
bsdbandit01 has quit [Read error: Connection reset by peer]
bsdbandit01 has joined #osdev
<geist>
sortie: did someone say beos?
<gog>
it's the ghost
<gog>
his name even means 'ghost'
<geist>
ghost of os past
<sortie>
What calling convention you gonna call with
<brynet>
o/
<sortie>
The net of bry!
<kazinsal>
Ohai
<sortie>
KAZINSAL
<sortie>
The whole gang (adoring emoji)
<kazinsal>
uh oh, that intensity usually means I'm about to have a networking question thrown at me
<kazinsal>
:D
<sortie>
Alas I must disappoint you, while your services are required, I am in fact just happy to see y'all
bsdbandit01 has quit [Read error: Connection reset by peer]
<geist>
hey i did a thing last night! I got my thing ported to 68k
<geist>
now i just need to build a 68k board
<kazinsal>
woohoo!
<geist>
stll got something wrong with disabling ints or whatnot, but other than that it seems stable
<NieDzejkob>
How can I test disk read retry code?
<kazinsal>
I'm not sure if there are any good ways to emulate a slightly messed up hard drive
<gog>
perhaps there should be
<geist>
or if it is even a thing that exists anymore?
<geist>
depends on the interface i guess
<kc8apf>
hard drive firmware already does a bunch of retries before returning a read error to the controller. Pretty rare that a host-initiated retry will change that.
<geist>
yah tat's my point. it may be that realistically no modern drive would let the failure ripple up to the interface like that, without it being something totally catastrophic
<kc8apf>
if you want to play with it anyway, I'd probably either modify a qemu model to return occasional read errors _or_ use something like https://greatscottgadgets.com/luna/ to implement a USB mass storage device that returns occasional failures
<bslsk05>
greatscottgadgets.com: LUNA - Great Scott Gadgets
<kc8apf>
sometimes the sector is recoverable by writing to it. The data previously stored in that sector is gone though.
<kc8apf>
Only other case I can think of is when a drive is locked so all read/write commands fail.
<clever>
i think device-mapper in linux can also do that
<clever>
flakey Creates a similar mapping to the linear target but exhibits unreliable behaviour periodically. Useful for simulating failing devices when testing.
<clever>
yep, its in the `man dmsetup`
<kazinsal>
dm-dust does something similar yeah
<clever>
then expose that device to your kernel under qemu, and pray qemu can forward errors
<kazinsal>
I think the other question is, can qemu-- yeah
<clever>
delay Delays reads and/or writes to different devices. Useful for testing.
<clever>
that would need testing
gog has quit [Ping timeout: 264 seconds]
<j`ey>
why is '.' (current dir) useful to have in a VFS?
<NieDzejkob>
some systems do implement the notion of cwd in userspace, if that's what you're asking
<kazinsal>
Being able to check what the inode stats of your current directory are is handy
<NieDzejkob>
but if you have a way of specifying relative paths, specifying the current directory is useful too, if you're asking
<NieDzejkob>
I often do mv ~/Downloads/foo . for example
<j`ey>
where is it useful?
<j`ey>
ok yeah, that makes sense
<j`ey>
(I mean you can just $PWD or something..)
<kazinsal>
. also explicitly states a directory, so that's why running executables in the current directory requires prefixing with ./
<j`ey>
i just had a brainfart/blank, of course I know these use cases >_<
<clever>
another trick, is `mv file.txt foo` vs `mv file.txt foo/`
<clever>
if foo doesnt exist, you can rename something by mistake
<clever>
but with a trailing /, it will fail
GeDaMo has quit [Quit: Leaving.]
hgoel_ has joined #osdev
<NieDzejkob>
j`ey: then, for consistency, you should require $PWD/foo/bar
<gog>
about to topple over the jenga tower that is my mental health
<gog>
i know that seems counterintuitive but i'm getting really poor sleep :p
<kazinsal>
Today I took a nap instead of a lunch break
<kazinsal>
Definitely worth it
immibis_ is now known as immibis
<doug16k>
"squealing tires" was always the theme song for my sleeping schedule, with the odd mailbox being destroyed
<doug16k>
I stopped doing the crazy 20-year-old "oh I might as well stay up until tomorrow night" though
ephemer0l is now known as GeneralDiscourse
matt|home has quit [Read error: No route to host]
mahmutov has quit [Ping timeout: 245 seconds]
<doug16k>
geez, qemu build is over 100 source files per second on my machine
<doug16k>
ah, must be ludicrous speed from --disable-debug, all arch build, 1m24s :D
<doug16k>
8861 sources
<doug16k>
going to see why gdbstub sends a stupid <architecture>arm</architecture> on aarch64
<doug16k>
gdb won't face the reality that cpus change modes and their register file changes
<doug16k>
apparently never will if decades of that problem went unfixed on x86
<doug16k>
thumb mode really put a damper on the "one register file forever!" party
<doug16k>
have to how they very carefully implemented it so only arm can do it
<doug16k>
and every other cpu still can;t
<dh`>
fsf-quality code
bas1l is now known as basil
sortie has quit [Quit: Leaving]
<doug16k>
time for another comical debugging session, where I attach a debugger to the debugger attached to qemu and attach a debugger to qemu and debug the debugger and qemu simultaneously :P
<gog>
yo dawg we heard you like debuggers
<moon-child>
lol
<kingoffrance>
quis debuggiet ipsos debuggodes ?
<kingoffrance>
who is watching the watchpoints
ahalaney has quit [Quit: Leaving]
gmacd has quit [Read error: No route to host]
<gog>
lmao
gmacd has joined #osdev
Sos has quit [Quit: Leaving]
warlock has joined #osdev
gmacd has quit [Remote host closed the connection]
<doug16k>
haha, I just objdumped the toolchain to see if debug info was ok. it's laid out all nice so init is very first, then all the plt trampolines, then at the very end _fini all nicely at the end
<doug16k>
you can just fling it all in there somewhere and it works anyway
<doug16k>
flung things push hot code and data apart and screw up locality, I guess
<bslsk05>
github.com: qemu-rom/configure at master · doug65536/qemu-rom · GitHub
<j`ey>
pretty cool
<doug16k>
should be as easy as: git clone ... && mkdir build && ../qemu-rom/configure --host=something-elf && make -j$(nproc) run
<doug16k>
where it can be x86_64, i386, aarch64, riscv64 so far
<doug16k>
m68k next
<doug16k>
probably mips and alpha soon
<doug16k>
mips64
<j`ey>
can I use the same gcc I build the kernel with?
<j`ey>
the linux kernel I mean
<doug16k>
it's not that big of a deal to make a port though. I have to do a memcpy and a memset and figure out the power up memory layout for linker script
<doug16k>
j`ey, maybe
<doug16k>
it did work with system aarch64 compiler at first
<j`ey>
does it detech arch from the --host?
<doug16k>
before I started using proper toolchain. I had a hack in configure to use gdb-multiarch
<doug16k>
yes
<j`ey>
*detect
<j`ey>
cool, I will have a try tomorrow
<doug16k>
nice
<doug16k>
no pressure :D
<j`ey>
no pressure felt ;)
* gog
pressures j`ey
<geist>
j`ey: yeah come on
<doug16k>
it's fun dealing with the awkward things you do at early bootstrap. weird stuff where you can't even reach the address you want normally
<doug16k>
or running at an address, and the code is linked for another address
<doug16k>
riscv64 can't even reach ram with the biggest mcmodel from power up rom at 0x1000
<doug16k>
(from compiled code)
<doug16k>
you know it's weird when the ram is too far away :D
<doug16k>
that's a "1st clue"
<gog>
how does it bootstrap? cache-as-ram-type technique?
<doug16k>
you can run from registers easy
<gog>
oh right risc
<doug16k>
until you get the rom image copied to ram, then jump there and good to go
<doug16k>
after clear bss too
<doug16k>
only riscv64 has to do that
<doug16k>
all the others can reach far enough to keep using the rom image
<doug16k>
only their .data are copied to ram
<doug16k>
in entry_arch.S in each architecture (except x86, it holds both arches entry code in the machine/x86
<doug16k>
x86_64 had a little trouble with reach though
<doug16k>
you can't reach all the way down to 0x40000 from 0xffffxxxx