<klange>
rtl8139 is a very old chipset, but it seems odd to disable support for a device like that
<klange>
distro maintainers for qemu play around with frontend options a lot, and I'm still kinda mad about this gtk interface since it continues to have a bunch of issues
<kingoffrance>
yeah, my understanding is rtl81[23]9 was like ne 2000 pretty universal for emulators to support, because almost any os had a driver
<kingoffrance>
i of course dont know all the details/variants/etc.
<kazinsal>
now everyone's got an e1000 driver
<klange>
The default these days is e1000 and it's a much better choice
<klange>
(-M q35, you get the PCIe "e1000e" variety)
<kazinsal>
yeah, big bonus from the e1000e is that you get MSI and MSI-X
<kazinsal>
and deeper queueing etc
<geist>
if you want something old and similarly as complex as rtl8139 you can use pcnet32
<geist>
from an earlier era, but pci native
<geist>
and very documented
<geist>
which qemu and a bunch of virtual machines emulate
<kazinsal>
iirc vmware will do it if you set the nic type to "flexible"
<geist>
but all this aside, qemu itself does understand rtl8139, at least the one i have here
<geist>
it's listed in `-device help`
<klange>
It used to be the default.
<klange>
I wonder if a bunch if someone flubbed something when that switched to the e1000?
<klange>
s/if a bunch//
<geist>
yah and FWIW i'm using qemu 6.1, built from source
<geist>
so the arch linux one could be patched or old or something, but there really isn't anything newer than 6.1 except tip-of-tree
<klange>
looking at my git checkout from august, the code is still there
<klange>
let's update this
<kaichiuchu>
i think i might've made a mistake for what it's worth
<kaichiuchu>
all I know is compiling from source was the only thing that worked
<kaichiuchu>
heh
<geist>
yeah dunno if the arch linux build maybe patched it out for some reason?
<klange>
and they still haven't fixed double and triple click in the GTK interface being interrupted as a button release
<klange>
idiots
<kingoffrance>
eh, yeah it just sounded like a weird thing for them to disable, unless there was some known bug
<klange>
Probably a good time to recover my rtl8139 and pcnet drivers...
<klange>
They're the last bits of toaru32 I haven't ported over to misaka, just because they didn't feel worth the effort.
sonny has quit [Ping timeout: 256 seconds]
ElectronApps has joined #osdev
ElectronApps has quit [Remote host closed the connection]
<klange>
My ext2 driver is... doing some things wrong with locks that are making it difficult to fix up the ATA disk drivers... ugh, stupid me, you can't take a spin lock and then hold it through a potentially blocking operation, that's not how any of that works...
Brnocrist has quit [Ping timeout: 268 seconds]
sonny has joined #osdev
sonny has left #osdev [#osdev]
nyah has quit [Ping timeout: 256 seconds]
<junon>
Custom build system is back to feature parity with the old cmake scripts. Mkrescue working now. Considerably less configuration necessary while being more flexible. I can also do per-file flags or custom toolchains and stuff without much fuss at all, unlike CMake.
<junon>
Just need the Ninja maintainers to merge a PR and I can add CMake subproject support without much effort. Ninja currently doesn't handle subninja correctly at all IMO, and there's a PR to fix it. But it's hung up on Windows support weirdly enough.
gog has quit []
gog has joined #osdev
givemeyourpies has quit [Remote host closed the connection]
freakazoid343 has joined #osdev
zaquest has quit [Remote host closed the connection]
m3a has quit [Quit: leaving]
pretty_dumm_guy has quit [Quit: WeeChat 3.3]
dutch has quit [Quit: WeeChat 3.3]
m3a has joined #osdev
dutch has joined #osdev
skipwich has quit [Ping timeout: 250 seconds]
ElectronApps has joined #osdev
myon98 has joined #osdev
sdfgsdfg has joined #osdev
sdfgsdfg has quit [Read error: Connection reset by peer]
sdfgsdfg has joined #osdev
dude12312414 has quit [Remote host closed the connection]
dude12312414 has joined #osdev
dude12312414 has quit [Client Quit]
<klange>
today in distractions from a 2.0 release... tracking down why save games in doom don't work, it's calling rename(2) which I have yet to actually implement...
<klange>
so okay we can do that the bad way and make it a move as if it were cross-filesystem, negating _why_ they do a rename, but let's just take a look at what we need to do support rename(2) nicely...
<klange>
well it would be nice if I could know if two paths are in the same fs; this code is at least doing something in the easy case - rename file in same directory...
GeDaMo has joined #osdev
<klange>
looking at what I shove in `struct stat` and just getting very mad at myself
srjek has quit [Ping timeout: 264 seconds]
<klange>
This whole VFS needs a rewrite... which shouldn't affect userspace or the syscall interface, so it's not something I need to do now to not feel terrible about breaking compatibility...
<klange>
It would be nice to actually support, like, actually relative file paths. And be able to implement all the *at() functions...
<zid>
rename seems like it'd be fun to write tbh
<klange>
It's "surprisingly powerful".
<zid>
seems like you'd need to implement it per-fs though to get the real power of it
myon98 has quit [Quit: Bouncer maintainance...]
<klange>
I think a big problem is that my VFS design caters more to the virtual device files I have, rather than actual filesystems...
<klange>
I didn't really design much for things like know what "filesystem" a file is on.
sdfgsdfg has quit [Quit: ZzzZ]
<klange>
There's room for that sort of thing in there, but it's not followed correctly
<klange>
Like the main struct representing a file in the vfs has a ->device member and that _should_ be a pointer to something representative of the filesystem as a whole, but then I look at things like the tmpfs where nope that's the underlying structure of the file in memory
<klange>
and _that_ was done because "the main struct representing a file in the vfs" isn't a shared thing like an inode cache entry, it's an instance specific to one call to open()... so it's more like a file descriptor...
<klange>
a while back I was kicking myself over this same thing, as I was trying to figure out why an attempt to mark the size of a ramdisk as 0 after freeing it wasn't doing anything - of course because I set the size of a copy...
<graphitemaster>
Why don't you design your filesystem based on market forces
<bslsk05>
'Students who grew up with search engines might change STEM education forever' - 'Professors are struggling to teach Gen Z'
<graphitemaster>
:D
* kingoffrance
in honor of klange's time he referenced space balls "dont configure, just make!"
<kingoffrance>
"Wait a minute! There's paths here! There's protocols (drive letters), there's trees, there's subdirectories in URLs, there's files at the end. Come on, we'll bless them all until we get vashnigyered [drunk] "
<kingoffrance>
and the cycle begins again
<zid>
kill em all and let the free market sort it out
<kingoffrance>
the students or the professors?
[itchyjunk] has joined #osdev
sdfgsdfg has joined #osdev
elastic_dog has quit [Ping timeout: 245 seconds]
elastic_dog has joined #osdev
[itchyjunk] has quit [Remote host closed the connection]
<graphitemaster>
The market has decided files are for boomers.
<zid>
files should be associated with the app that created them, by the programmer, and nothing else
<zid>
users should just get abstract representations, like thumbnail galleries or something
<sham1>
The fact that smartphone manufacturers unironically agree with that is annoying
sdfgsdfg has quit [Quit: sdfgsdfg]
<kingoffrance>
"the market has decided" thats the surest sign it will be reinvented under another name
<kingoffrance>
not the market, i mean pretending something doesn't exist
<kingoffrance>
it will be forced to be recreated
auronandace has joined #osdev
<graphitemaster>
It's market forces, not market forced.
<kingoffrance>
its just word games
<graphitemaster>
The market maketh and taketh but your files were never safe
<bslsk05>
www.righto.com: Reverse-engineering the Yamaha DX7 synthesizer's sound chip from die photos
Brnocrist has joined #osdev
<kingoffrance>
well i dont doubt conway's law -- ppl who grew up with x will be different than ppl from another env. but as a local dead tree paper article once said (paraphrase teacher) "we can create any kind of ppl you want" i dont mean that in a spooky controlled consciousness way, just that its a self-created problem of the education industry "market forces" if they think there is some "change"
<kingoffrance>
if there was a change, they helped create it
<kingoffrance>
and they can fix it if they wish
sdfgsdfg has quit [Quit: ZzzZ]
<kingoffrance>
thats why i dont buy "students think differently" -- sure, because someone x years before you changed the curriculum/whatever
<kingoffrance>
maybe teachers have little say, are bound by "market forces" but someone made that call
<geist>
ooooh ken did a teardown of a synth chip. gnna be good
myon98 has joined #osdev
<geist>
huh interesting: never knew about te trick of storing a sine wave in a table and then walking through the table with a different stride to generate different frequencies
<geist>
seems pretty obvious once you notice it
<geist>
(in the righto teardown article before talking about 80s FM synthesis)
CryptoDavid has joined #osdev
mahmutov has quit [Ping timeout: 245 seconds]
<geist>
GeDaMo: thanks for the link, that was really neat
<GeDaMo>
Yeah :)
<geist>
now i wonder a bit about the OPL3 and how it compares
<geist>
it seems simpler, but probably a similar architecture
<bslsk05>
'Students who grew up with search engines might change STEM education forever' - 'Professors are struggling to teach Gen Z'
<j`ey>
weird, never met anyone that didnt understand files/folders
<gog>
yeah sounds like an extrapolation from a small sample
<jimbzy>
bslsk05, I can believe that.
<jimbzy>
I had to act as a translator between my CS professors and the other students...
<j`ey>
jimbzy: bslsk05 is the bot :P
<clever>
pounce: iOS isnt helping, the bulk of the UI just acts like folders dont exist, lol
<jimbzy>
yeah I just realized that.
<pounce>
yeah but everybody's going to have a different background on this, it's not like that's ever changed
<pounce>
if you can't handle that it's not "gen z"'s fault
<jimbzy>
I'm trying to ignore a meltdown in progress, so ignore me.
<pounce>
:') good luck
elastic_dog has quit [Quit: elastic_dog]
<jimbzy>
But seriously. Most of the CS students I have encountered have no interest in computers and/or science.
elastic_dog has joined #osdev
dennis95 has quit [Quit: Leaving]
cheapie has quit [Quit: Local host tripped over the cable]
cheapie has joined #osdev
<sham1>
Well could be that most CS students are after easy money
<j`ey>
(which is also fine)
<sham1>
It's fine
freakazoid343 has quit [Read error: Connection reset by peer]
wikan has joined #osdev
rorx has joined #osdev
elastic_dog has quit [Ping timeout: 264 seconds]
chir4gm has joined #osdev
Qubasa has joined #osdev
freakazoid343 has joined #osdev
elastic_dog has joined #osdev
CryptoDavid has joined #osdev
wikan has quit [Quit: Client closed]
wolfshappen has quit [Quit: later]
elastic_dog has quit [Ping timeout: 264 seconds]
elastic_dog has joined #osdev
wolfshappen has joined #osdev
srjek has quit [Quit: Leaving]
Oshawott has joined #osdev
archenoth has quit [Ping timeout: 245 seconds]
<geist>
good afternoon folks
<jimbzy>
What's happening, geist?
<geist>
not much, had a nice windstorm here last night, but nothing fell down
<geist>
so that's nice
<jimbzy>
Yeah, that's always a good thing.
isaacwoods has joined #osdev
<gog>
same here
<gog>
found my neighbor's garbage bin in the street earlier :p
<gog>
that's about it tho
bauen1 has joined #osdev
<[itchyjunk]>
I have a dumb question. can there be just one kernel? like say a cpu has a gpu as it's peripheral device. would each of these have their own "kernel" ?
<[itchyjunk]>
or is it better to think of kernel as a top (bottom) level thing that nothing else superseeds?
<geist>
hmm
<geist>
not sure i completely understand what you mean by 'one kernel'
<geist>
like one kernel as in a single code base, or one instance of a kernel running on both cpu and gpu at the same time?
<geist>
for the latter. not really. gpus and cpus are different enough that trying to run the same code on both simultaneously isn't really realistic
<bauen1>
intel (and arm) have already implemented hardware features so that the "kernel" in the traditional sense isn't the layer with the most privileges
<geist>
but, gpus have their own firmware usually that the cpu talks to, so it works fine
<geist>
same way that lots of peripherals have their own firmware with their own OS (think SSDs, or wifi chips, or SD cards, or whatnot)
<[itchyjunk]>
not in the sense of being the same code base. rather the structure. like a car can have only one driver
<[itchyjunk]>
even if there is another car hooked behind the first car, one driver controls the whole thing
<clever>
even a usb3 chip can have its own firmware and cpu core
<geist>
yah. so sure your model is fine. ignoring any special security processors or whatnot, usually the main cpu is 'in charge'
<[itchyjunk]>
ah so each "cpu" would have it's own "kernel" and they just talk to each other then
<geist>
or at least they think they are. there are levels of abstraction like virtualization or hidden security processors and whatnot that violate that rule
<geist>
sure
<geist>
a modern machine, and especially things like cell phones or tablets, have lots of little cpus running their own OS all talking to each other
<geist>
the interface abstractions help keep the complexity of that to a minimum
<clever>
there was a phone wifi exploit a few years ago called broadpwn
<[itchyjunk]>
so there is no one piece of software in cell phone that is truly in charge
<clever>
basically, the wifi chipset runs its own OS, that handles 90% of the idle wifi chatter, so the big arm cpu can stay in sleep mode
<clever>
and there was a buffer overflow exploit in it, which can lead to remote code execution on the wifi chipset
<geist>
[itchyjunk]: depends on your definition of in charge, so it gets a bit blurry
<[itchyjunk]>
ah, useful to save power i assume
<geist>
but conceptually the main cpu that the main os runs on is in charge yes
<clever>
[itchyjunk]: until the firmware leads to a remote attacker having control of your wifi chip
<[itchyjunk]>
right, i don't have good working definition for this stuff
<geist>
though implementation wise you can make arguments as to which one has more authority to do stuff
elastic_dog has quit [Ping timeout: 245 seconds]
<[itchyjunk]>
clever, would you the arm part of the phone know that this other chip is executing random codes?
<geist>
but as a product you want to give the illusion that the user is in control, so in general buttons that the user presses should go to a cpu that is running an OS that can respond to it and make global, visible changes
<clever>
[itchyjunk]: probably not, enless your actively checking debug control registers
<geist>
and usually that is what you'd probably consider 'in charge'
<clever>
[itchyjunk]: depending on the variant of the wifi chip, it may be on a pci-e bus, and can then attack the host ram
<[itchyjunk]>
hmmm
<geist>
perhaps the button has its own io processor that already handled the button press? sure, but it forwards the results to the central 'main' OS
<geist>
so in general the model would be there's a main cpu that runs a main OS and a cluster of various io processors each running their own, that talk to the main cpu
<geist>
the details vary, but that's still a general model that most things follow
<[itchyjunk]>
right, good enough
<clever>
my work for the open rpi firmware is taking things in a bit of an odd direction, the same "OS" (little-kernel) is running on both the gpu and the arm core
<[itchyjunk]>
different instance of same OS ?
<clever>
[itchyjunk]: yeah, different builds (each for a different ISA), running on different cores, each with its own heap
<clever>
and with different modules enabled
<[itchyjunk]>
ah interesting
<clever>
it gets really confusing, when your talking to both over the same uart
<clever>
they are nearly identical, so you cant tell them apart, lol
<clever>
] whatareyou
<clever>
i am VPU with cpuid 0x04000140
<clever>
i had to add a custom command, that uses #ifdef's to figure out which ISA its on
<clever>
and later added cpuid into it
X-Scale has quit [Ping timeout: 256 seconds]
X-Scale` has joined #osdev
<[itchyjunk]>
i would think that a con of such thing is that redundant code is being run in each chip since once chip code might have been able to manage all that. what is the pro of this approach?
<clever>
[itchyjunk]: the modules are configured so that each instance is managing different things
X-Scale` is now known as X-Scale
<clever>
the GPU build manages initializing all of the hw (thats the only way to get the arm to even run) and driving the video output ports
GeDaMo has quit [Remote host closed the connection]
<clever>
the ARM build manages loading zImage + cmdline.txt + initrd from the SD card, and passing the arm core off to linux
<clever>
but if you dont want linux involved, the ARM build could do other tasks directly
<clever>
you could also ditch the ARM entirely, and have the GPU do the entire job by itself
<clever>
but ive been writing the code in a portable manner, so i can easily move a task around
<noocsharp>
does the gpu have an arm core? i imagine it must to load LK
<clever>
noocsharp: the GPU on the rpi is a dual-core VPU (its own ISA)
<bslsk05>
www.righto.com: Reverse-engineering the Yamaha DX7 synthesizer's sound chip from die photos
<clever>
noocsharp: and the arm core where you typically run linux, is more of a peripheral hanging off the GPU
<noocsharp>
yeah, i've always found it strange that you need proprietary firmware in order to even get a kernel running on the rpi
<clever>
noocsharp: with the work ive been doing, you can boot a pi2 or pi3 headlessly with open firmware, or boot a pi2 to a full gui with a different open firmware
<noocsharp>
sounds interesting, do you know of something similar for the pi1?
<clever>
noocsharp: i can start linux on a pi1, but it crashes mid way thru the bootup
<clever>
before it tries to mount the rootfs
<clever>
all attempts to debug it just led to more confusion, the fault would move when i add print statements
<clever>
but i now suspect i might have been overclocking it by 2x, or under-volting it
<clever>
i dont change the voltages at all on any model
<clever>
and the default voltage may not be high enough to run it at full tilt
greaser|q is now known as GreaseMonkey
<clever>
noocsharp: next time i look into the pi1, i should both try lower freqs, and also investigate the voltage controls in more depth
<clever>
parallel to all of that, is replacing the LK-arm payload with u-boot
<clever>
or at least making it an option
<clever>
i have 3 different payloads i can run on the arm, LK, uboot, or uefi
<clever>
oh, and 4, the original rpi-open-firmware/arm_chainloader
<geist>
how much time have you spent with the rpi-uefi stuff? is it a complete implementation?
<geist>
curious, might be interesting to use it as a base for fuchsia porting
<geist>
since uefi
<clever>
geist: ive not worked on its code yet, or ran it, but i am in their discord server, and ask questions every now and then
<clever>
it has both acpi and device-tree modes
<geist>
yah i fiddled a bit the other day trying to figure out how to find the acpi tables on qemu-arm-virt. it's there, but it's hidden behind this fw_cfg interface
<geist>
ie, not just mapped in memory like the device tree is
<geist>
but presumably a UEFI implementation just pops it out of the fw_cfg interface
<geist>
so it makes sense that that's where they put that
<clever>
i think fw_cfg is meant to be a side-channel to pass data to the firmware (uefi), which should then re-expose it to the OS under more normal api's
<clever>
but linux does have fw_cfg drivers, so it can peek
<geist>
exactly
<clever>
rpi-open-firmware needs similar things, because the arm core starts executing at pc=0, and there is no way to pass it arguments
<clever>
so you need to edit the ram before you begin execution
<geist>
all i really wanted to do was find the PCI ECAM, so i ended up resorting to just reading it out of the device tree, since i was already parsing that
elastic_dog has joined #osdev
<clever>
geist: oh, but the rpi4 uefi, doesnt expose the pci-ecam, because its that wonky muxed one that acpi doesnt have a name for
<clever>
that uefi will just claim the vl805 is a platform xhci controller
dude12312414 has joined #osdev
<geist>
ah and it sets it up already configured and claming a fixed IRQ
<clever>
yeah
<clever>
the pci-e is pre-configured, and uefi just claims there is no pci-e
sdfgsdfg has joined #osdev
<clever>
so you can just skip directly to MMIO'd the xhci registers
<geist>
makes sense. not good for power management and you can't use MSIbut then if you just have a single IRQ it's probably not the end of the world
<geist>
theres a bit of that shenanigans in the opposite direction on some of the thunderX arm socs
<geist>
from reading the manual it loos like they have a bunch of 'fixed' peripherals like AHCI controllers and whatnot that also appear in their PCI ecam
<clever>
weird
<geist>
but... are fixed in location so yo ureally cant relocate them by reprogramming a PCI bar
<geist>
so it's sort of a lie. here's a bus! but it's pretend
<geist>
it's possible there's some obscure feature of PCIe that allows that. maybe there's a bit i dont know about that says 'this is a locked peripheral'
<clever>
something else ive heard about, is that there is a max packet size for pci-e
<clever>
and the bios is supposed to negotiate what the largest packet size is on a per-port basis, and set it as high as possible
<geist>
they also of course have a real PCIe bus, but it's just some of the root peripherals are fixed in location. though possibly that's exactly what intel and amd does: peripherals on bus 0
<clever>
and it was recently discovered, that the rpi4 linux drivers dont do that by default, because they assume the bios did it
<clever>
so that was resulting in more overheads on the pci-e link
xenos1984 has joined #osdev
<geist>
ah and are using like 1 byte at a time trnasfers or something
<geist>
i can see that
<clever>
128 byte transfers i think, rather then 256 or 512 byte
<geist>
i encourage you to give the pcie spec a read over. or at least as much as you can. it's fascinating at the link layer
<geist>
like AXI but hella complicated
<clever>
the forum thread went into detail of how many bytes of overhead are in each packet
<bslsk05>
forums.raspberrypi.com: What happens if you add pci=pcie_bus_safe to cmdline.txt on a Pi 4? - Raspberry Pi Forums
<clever>
yeah, it was defaulting to 128 byte packets, but the bcm2711+vl805 can support 256 byte packets
<clever>
and the specs define a max of 4096 as the upper limit
<clever>
and each packet will have 24 bytes of header, before the payload of the above size
<geist>
the way pcie stripes across lanes and then reassembles at the end is super slick
<clever>
so you can then add that all up, and divide by the pci-e link bandwidth
<clever>
to get the actual useful data transfer bandwidth
<clever>
i know of at least 4 protocols that can stripe over a variable number of lanes, SD, CSI, DSI, and PCI-e
<clever>
SD does bit level striping, so you will send the 4 lower bits, then the 4 higher bits (not sure on order), over 4 wires, if in 4 lane mode
<clever>
CSI does byte level striping, so each lane gets a whole byte
<clever>
DSI/PCI-e, i aint got a clue
<clever>
CSI also has a start/end symbol, which gets broadcast over all lanes
<geist>
that's why i was suggesting it's a fun read to read the spec
<clever>
so a csi transfer would look like [start,start], [byte0,byte1], [byte2,end], [end]
<clever>
yeah, i need to find a pdf copy of the pci-e specs
<geist>
yah i forget precisely how it's striped on pci-e. i think it's a byte at a time, but it also explicitly handles the fact that each serial link has its own clock and can arrive at different times
<geist>
so there's some amount of packet level buffering that has to be done to reconstruct the packet with a fairly large amount of skew allowed
<clever>
SD and CSI have one clock for the whole set
<clever>
HDMI also has one clock, but some mechanims for tuning to the skew
<geist>
right, this is one of those things that PCI-e explicitly deals with. running at hecka high frequencies, so each link is its own thing
<clever>
for hdmi, there is a special set of 4 10bit symbols used in the blanking interval, with a very high edge densitity
<geist>
and even at short distances like across the motherboard, at 5ghz or so you really start to see substantial skew
<clever>
so the rx end can measure the exact skew between the re-created bitclock and each lane
<geist>
yah, in other words HDMI is lame
<geist>
or at least a product of the early 2000s
<clever>
and hdmi has a special set of low edge densitity 10bit codes for the visible area, to reduce EMI
<clever>
but the striping is super dumb, one lane per color :P
<geist>
being that it's really just DVI in another package they had limited ability to deal with it
<geist>
a bit dissapoint personally that displayport hasn't taken off in consumer TV space yet
<geist>
dunno if it's a complexity thing, or licensing thing, or just HDMI is good enough thing
<clever>
audio is done in the blanking interval
elastic_dog has quit [Ping timeout: 245 seconds]
elastic_dog has joined #osdev
zaquest has joined #osdev
YuutaW has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
sdfgsdfg has quit [Quit: ZzzZ]
gog` has joined #osdev
gog has quit []
gog` is now known as gog
CryptoDavid has quit [Quit: Connection closed for inactivity]