<SGautam>
Nah I was thinking they OSS'd the lower level docs maybe because now GPUs are everywhere
<heat>
yeah but no one needs the docs dude
<SGautam>
I mean yeah, you can just read the CUDA docs for most of your needs
<heat>
amdgpu is a code dump, nvidia is a code dump, intel has _some_ docs but also lots of magical voodoo coming from in-house
<heat>
arm gpus are all code dumps
<heat>
most operating systems not named windows or macOS use the linux drivers
jedesa has joined #osdev
<SGautam>
Code dump as in?
<SGautam>
They've open sourced the driver code?
<heat>
those are all open source
<heat>
but they're not "open"
<zid`>
REGISTER_47 = CONSTANT_12;
<heat>
no docs no explanation just rawdogging 15KLOC in one patch
<zid`>
A lot of this stuff is heavily patent encumbered, and it'd cost millions in lawyer fees to clear it all, and require code changes probably. So they just anonymize it all.
<zid`>
it works, but it doesn't tell you much of anything
<zid`>
about as much as just sniffing the mmio accesses would have
<kof673>
my understanding of code dump is like agile said they would cure waterfall methodology....write the code in house, then toss it over the wall (versus supposed "community" development and "outside feedback" ) ....NIH in a way, or metaphorical walled garden as far as development goes
<bslsk05>
github.com: open-gpu-kernel-modules/src/common/sdk/nvidia/inc/ctrl/ctrl0080/ctrl0080fb.h at d5a0858f901d15bda4c3d6db19a271507722a860 · NVIDIA/open-gpu-kernel-modules · GitHub
<kof673>
*waterfall to all appearances to the outside world; internally could still be developed however, just that is the only thing the outside world sees
<heat>
dont you hate it when your ctrl0080fb goes NV0080_CTRL_FB_CAPS_BLOCKLINEAR_GOBS_512 and then you need to NV0080_CTRL_FB_CAPS_L2_TAG_BUG_632241
Dead_Bush_Sanpai has quit [Read error: Connection reset by peer]
Dead_Bush_Sanpai has joined #osdev
<heat>
and this is from the cleaned OSS source too, can't imagine what the internal nvidia.ko codebase looks like
<zid`>
it looks like 40 separate teams marking their territory ^ :P
Dead_Bush_Sanpai has quit [Read error: Connection reset by peer]
Dead_Bush_Sanpai has joined #osdev
Dead_Bush_Sanpai has quit [Read error: Connection reset by peer]
Dead_Bush_Sanpai has joined #osdev
Dead_Bush_Sanpai has quit [Read error: Connection reset by peer]
Dead_Bush_Sanpa1 has joined #osdev
Dead_Bush_Sanpa1 has quit [Read error: Connection reset by peer]
Dead_Bush_Sanpai has joined #osdev
Dead_Bush_Sanpai has quit [Read error: Connection reset by peer]
Dead_Bush_Sanpa1 has joined #osdev
Dead_Bush_Sanpa1 is now known as Dead_Bush_Sanpai
obrien has joined #osdev
Dead_Bush_Sanpai has quit [Read error: Connection reset by peer]
Dead_Bush_Sanpai has joined #osdev
<kof673>
i am not arguing either way either, just that there is a myth waterfall died, or agile superceded it, can say that about many things
<kof673>
much like GPL following legal systems, allows an "individual" to be a corp etc. ....you can perhaps move the goalposts any which way depending on how you define a "group" lol
GeDaMo has joined #osdev
<SystemPrompt>
SGautam: has anyone tried asking chatgpt to generate register descriptions based on driver code? That's how ML/AI stuff works ... just ask chatgpt and see if you get something useful or not
<SGautam>
Good idea actually
<GeDaMo>
If you don't already know the answer, how can you be sure if ChatGPT's output is correct?
<SGautam>
Wonder if there's a codeGPT trained on code and documentation that can spit out documentation from given code.
<vai>
hi
Burgundy has joined #osdev
Dead_Bush_Sanpai has quit [Read error: Connection reset by peer]
Dead_Bush_Sanpai has joined #osdev
<nikolar>
I thought amd and Intel were better than this
obrien has quit [Remote host closed the connection]
Left_Turn has joined #osdev
Left_Turn has quit [Ping timeout: 246 seconds]
_ngn- has joined #osdev
_ngn has quit [Remote host closed the connection]
<the_oz>
It isn't whether it's correct or not, it has already been proven to tell falsehoods, meaning that it's a liar. Furthermore, it prefers social policies than accuracy
vursc has quit [Ping timeout: 244 seconds]
vursc has joined #osdev
<dormito>
nvidia (and I think AMD) is moving more of their "driver" code to on-GPU micro where they can hide it from you. I wonder how long until the "
<dormito>
"GPU" interface is just a simple RDMA network interface.
<dormito>
(that's somewhat sarcastic humor btw)
<kof673>
kof's law: whatever sarcasm you may come up with, some corp. is planning to do it
<dormito>
urph. I know
<dormito>
btw: there IS (or was) a public git repo of intel gpu (i915 series) "docs"... mostly registers. Probably not enough to write something comprehensive from scratch. but definitely helpful when debugging random things. Like their i2c controller
<clever>
dormito: that on-gpu microcode style, is basically how the rpi broadcom gl worked, but it has been largely replaced by proper source in linux
<clever>
originally, the VPU core's ran the whole opengl stack, and basically every opengl function was just an RPC call from arm->vpu
<dormito>
clever: isn't the rpi a GPU with with a hardware accelerated conventional processing?
<clever>
dormito: the rpi has seperate 2d and 3d gpu's
<clever>
the 2d gpu can do basic scaling, alpha blending, pixel format conversion, axis flips, and at some cost axis swaps
<clever>
the 3d gpu takes shaders and attributes, generates 3d data, flattens it down to 2d, then applies textures to the flattened polygons
<clever>
the 3d core is basically single-threaded, and in general renders 1 complete frame at a time, but a smarter driver could interleave different frames into the command queue
<clever>
but a single render job on that single-threaded core, will then issue jobs out to the shader compute cores, where it widens out, and becomes heavily vector/parallel based
<dormito>
clever: what I was refering to about on-GPU micro wasn't really "microcode" or "firmware" in the traditional sense of GPUs over the last 20 years. IIRC modern nvidia cards has an additional/seperate risc-v processors that is what configures the real gpu. My understanding is that nvidias "open source" driver just IPCs to that.
<clever>
yeah, and the VPU that managed the broadcom gl, was a dual-core cpu, with a load/store architecture
<dormito>
oh interesting
<clever>
ive got a gcc port that can target the VPU, and i have littlekernel running there, along with tinyusb and LWIP
<dormito>
isn't broadcom fairly agrressive about NOT documenting thier SoCS?
<clever>
there was a contest years ago, to port the 3d drivers
<clever>
they released header files, for the entire SoC, all peripherals
<clever>
ive spent years RE'ing the hw, and writing the missing documentation
<dormito>
well, that's better than nothing. but in general/for real-world-use I'd never go near a SoC without readily available docs.
<clever>
the docs vary wildly from soc to soc
<clever>
the bcm2835 has the most coverage in its docs, but omits a lot of peripherals they dont expect you to use
<dormito>
I really wish hw vendors would generate decent docs, and stay the hell away from sw. every time I have to deal with vendor sw... it's crap, and shipping it (like in a product) is a QA nightmare
<clever>
the bcm2836 docs, basically just explain how the arm core changed (arm local timer, and irq), and then just say "see bcm2835 docs"
<clever>
2837 was similar
<clever>
2711 changed more, and sort of re-described it all
<clever>
2712, the docs just dont exist, all GPIO/peripherals are on a PCIE slave, which does have far better docs (but still has holes)
<clever>
dormito: the things that are missing, are things like the dram bringup, arm bringup, the h264/mpeg2 stuff, the ISP (camera stuff), anything to do with the VPU, and some clock tree things
SGautam has quit [Quit: Connection closed for inactivity]
<dormito>
clock trees are evil. the only thing worse that a non-trivial clock tree, is a not properly documented non-trivial clock tree
<bslsk05>
elinux.org: The Undocumented Pi - eLinux.org
<clever>
each block of peripherals (say all of the core peripherals) share a mux layout (for core, 1 is crystal, 4 is PLLA_CORE), and then have a CTRL and DIV register
<clever>
dormito: but linux has since gained drivers to control most of the clock tree directly, but some PLL's and dividers where omitted
<clever>
so you can take the gpclk docs, the linux drivers, and the header drop, and fill in the blanks
<SystemPrompt>
GeDaMo: it's 2024, the world is post truth and hypernormalized, appearing to be right matters more than actually being right... but this is a technical question so actually being right is what matters. Who even knows if the answer is right but might as well try asking.
<dormito>
yeah. the problem with that approach is, it's undefined behavior. it works.... until it doesn't. It's great if you just want to mess around with the system.
<dormito>
but if you want to build & maintain something reliable, it becomes a nightmare
<clever>
dormito: officially, your supposed to leave the undocumented clocks up to the firmware blobs, and its RPF's job to maintain that code
<SystemPrompt>
when you reverse engineer, all behavior is either defined or not yet reverse engineered. You can't really RE something and then determine it's undefined. Undefined means no guarantees from the docs writer, the chip still does something.
<clever>
but ive been working on replacing those blobs with open source
<dormito>
nice!
<kof673>
^^^ re: asking gpt...well, if you have a black box, and write a driver without the official docs, and it appears to work.........i mean best you can ever get then is "appears to work", and multiply this all the way down i suppose...
<SystemPrompt>
recently on HB: someone REd the state of the carry flag after a multiplication on ARM7TDMI (Gameboy advance processor)
<clever>
dormito: with the latest commit on github, you can boot linux on the pi2 or pi3, and the pi3 can boot from a usb drive
<SystemPrompt>
It's extremely complicated and useless
<SystemPrompt>
On HN*
<clever>
with the stuff ive been working on the last week (not pushed), the open firmware can download files over tftp, so network boot is not far away
<dormito>
clever: blob free? or free of bootchain blobs? In either case, that's really neat
<clever>
dormito: it can boot linux and get working ntsc video and network, with zero blobs involved
<dormito>
nice!
<clever>
but wifi needs a blob, so no wifi for you
<kof673>
and not to sidetrack, but that usenix video the other day, he emphasizes something like "ontological trap; do not care what it is, but what it does" i wouldn't separate them so much maybe, although he is saying focussing on what something "is" heavily skews the picture...
<bslsk05>
'rpi open firmware boot' by michael bishop (00:02:23)
<dormito>
meh. wifi is overrate. lol. And blob-free wifi is nearly non-existant. I think there's one or two older chipsets that are blob free. but I have heard of nothing modern.
<clever>
its a pi3 i think? booting linux from an SD card
<kof673>
i have a nethack philosophy; you can use it as labelled, or find some other use for an item lol
<clever>
in parallel to linux booting on the arm, the VPU is doing 2d and 3d demos
<SystemPrompt>
kof673: it was like "the OS is what controls the hardware" vs "the OS is the kernel and system libraries". One is a much better definition.
<kof673>
well yes, he is saying he labels no longer have any match to reality
<kof673>
*the labels
<clever>
dormito: the top half of the screen is mapped to the text console for littlekernel on the VPU, where it can print debug logs
<SystemPrompt>
one of them is inherent and the other is accidental
<clever>
the bottom half of the screen maps to `/dev/fb0` in linux, for its text console, and xfce even runs
<clever>
the bouncing rpi logo is animated in the 2d core, i'm just changing the XY coords, it uses basically 0 cpu
<clever>
and the spinning triangle is a 3d job, i calculate the XY for the 3 corners in the VPU, then the 3d core and shaders render out a single frame, with alpha
<kof673>
i guess i would use "is" opposite, older style, "Is" is what something is regardless of label, but i understood what he meant anyways
<clever>
and at the end of the above demo, you can hear me mashing keys, and no input works
<kof673>
but even that i would say, is already an inherent philosophy......anyways...
<clever>
that is the moment i discovered, usb only worked in linux, if you use the official bootcode.bin blob and network boot (it speeds up development)
<clever>
and when you switch to the open bootcode.bin, usb stopped working
<clever>
i have since fixed that issue
<clever>
there is a PHY behind the usb controller, and the official start.elf blob will initialize it before booting linux
<clever>
if you bypass that, then the PHY is never initialized, except
<kof673>
basically you are approaching philosophical duck typing ......anyways.........
<clever>
if the bootcode.bin blob needs usb (MSD or network boot), it will initialize the PHY
vinleod has joined #osdev
<clever>
however, i have since discovered, the official bootcode.bin blob, doesnt initialize the PHY correctly
<dormito>
lol
<clever>
resulting in random packet corruption when doing tcp transfers
<clever>
ssh and https get upset and hang up
<clever>
http doesnt notice and corrupts your files
<dormito>
"vendor code is to be assumed wrong until proven wrong"
<clever>
nobody has noticed, because start.elf re-initializes the phy seconds later
<clever>
this time with the correct parameters
<clever>
in theory, this could result in start.elf itself being corrupted in transit, ive not been able to confirm or deny that
<clever>
once i decompiled start.elf and ripped out the right chunk of code, the problem was solved
vdamewood has quit [Ping timeout: 248 seconds]
<dormito>
is it a discreet external phy (maybe even documented? IIRC their are standards for external usb phys...), or an intigrated usb phy?
<clever>
integrated usb phy
<clever>
with the MDIO port within the dwc2 usb controller
<clever>
zero documentation on which phy it is
<dormito>
ooooh, you mean an ETHERNET phy (e.g. rgmii or such), not an actual USB phy
<bslsk05>
github.com: lk-overlay/platform/bcm28xx/usb-phy/phy.c at master · librerpi/lk-overlay · GitHub
<dormito>
really? I thought ULPI and friends where entirely their own thing
<clever>
its just a fire&forget thing
<clever>
one of those registers, configures the PLL to go from 19.2mhz to whatever frequency the PHY needs
<clever>
because the crystal fitted on the board can vary
Lucretia has quit [Quit: Konversation terminated!]
<clever>
by messing with that register, i can change the rate of SOF packets, and the link will obviously fail due to the usb device not agreeing on the speed
Lucretia has joined #osdev
<clever>
dormito: i have also recently started messing with ethernet PHY stuff more
<clever>
how much do you know about the ethernet on the pi1-pi3 family?
<dormito>
clever: basically nothing. I used RPis 1-3 a tiny bit when they first came out. But basically stopped messing with them before RPi4 came out.
<clever>
basically, they have a funky chip, that includes a usb hub, a usb network card, and an ethernet phy
<dormito>
however for unrelated reasons, I HAVE recently read 802.3 so I AM familiar with eithernet, lol
<clever>
for some models, its a 3 port hub, with 1 port internally used
bessieTheBoy has joined #osdev
<clever>
for others, its a 5 port hub, with 1 internally used
<clever>
ive been implementing usb drivers, for the usb NIC half of that chip lately
<clever>
and one option i noticed in the datasheet, is that it supports an external phy, even though it has an internal one
<dormito>
I think that's not uncommon
<clever>
basically, you can power-down the internal phy, and then re-mux some gpio as external phy pins
<dormito>
IIRC a lot of intel Ethernet MAC+PHYS allow external phys as well
<clever>
the datasheet mentioned something about an HPNA PHY (ethernet over coax)
<clever>
and allowing you to dynamically switch between the PHY's at runtime
<clever>
for the pi3+, they also upgrade to a 1gbit ethernet controller (on a 480mbit usb2 bus)
<clever>
its bottlenecked, but 480mbit is still better then 100mbit
<clever>
dormito: oh, right, guess what RPF managed to mess up on the original pi1 design?
<bessieTheBoy>
Sorry to interrupt, but I've been trying to get gdb to work b/c it had no xml support. I compiled it by itself but aftere its compilied when I run "gdb --configuration" it still says "--without-expat" which I believe is the issue. How can I install expat? Im on fedora by the way.
<dormito>
I've heard in passing of several bugs on the rpi hw series. not recalling a major one on the rpi1. though I consider their inablility to use the "usb power port" as a USB gadget device on the 2nd usb contorler to be a design falw
<dormito>
*flaw
<clever>
dormito: the one i was thinking of, is that they saw the 3.3v OUT on the usb hub (meant to be a place for external bypass caps), and they thought it was 3.3v IN
<clever>
so they wired it up to the main 3.3v regulator
<dormito>
uph
vinleod has quit [Ping timeout: 248 seconds]
<clever>
due to slight production variation, sometimes the hub 3.3v was 3.31v, and the main reg was 3.29v
<clever>
so the usb hub decided to supply all of the 3.3v current, for the entire system
<clever>
and the main 3.3v reg did nothing
<clever>
that was over its rating, and it got super hot :P
<dormito>
lol
<clever>
thats why you dont parallel up voltage regulators
<clever>
and i should get to bed now, dormito if you want more rpi news, keep an eye on #raspberrypi-internals
vdamewood has joined #osdev
<dormito>
good to know
<Ermine>
heat: panthor and panfrost are not code dumps i believe
<Ermine>
Meanwhile, "DRM_MODE_TYPE_CLOCK_C and DRM_MODE_TYPE_CRTC_C: Define leftovers which are stuck around for hysterical raisins only. No one has an idea what they were meant for. Don’t use."
<Mondenkind>
what the actual fuck
<Mondenkind>
actual utter trash
<Mondenkind>
min(2, 1, 3) => 2
<Mondenkind>
it just keeps getting worse
<Ermine>
comma operator strikes you in the foot
<Ermine>
Seriously, why it's even a thing? So certain people can write return errno=ELULZ, -1 ?
<Mondenkind>
for (...; ...; i++, j += 5) type of thing ig
<Ermine>
ah, this
<heat>
i have a few return errno=ELULZ, -1 i picked up from sortie a loooooooooong time ago
<Mondenkind>
sortie: pls explain
<Ermine>
sortie probably picked that from skarnet. Or the other way around
<heat>
i'm slowly whacking errno usage in my kernel though
<bslsk05>
lore.kernel.org: [PATCH] MAINTAINERS: Remove some entries due to various compliance requirements. - Greg Kroah-Hartman
<Ermine>
heat: this got even in the non-technical media here
<Ermine>
I wouldn't even be surprised if this gets on TV
<nikolar>
what's that all about
<heat>
ok so 3 non-joke thoughts: 1) the LF handled this terribly and should've been transparent from the start (basically bottomley's email should be in the commit message) 2) this is reasonable as LF is a US institution 3) the removed maintainers should've been added to CREDITS as is tradition
<heat>
1 joke thought: you know it's good shit when the thread has links to the wikipedia page for finland in WW2 and the siege of leningrad
<nikolar>
lol i am sure that's relevant
<heat>
nikolar, ok so basically TL;DR the linux foundation was forced to remove some russian maintainers due to sanctions and US law
<Ermine>
Well, WW2 links just must have been posted
<heat>
it started the biggest shitstorm of randos posting to the list that i've ever seen
<nikolar>
nice
<nikolar>
so what triggered this
<nikolar>
why did they suddenly decide to remove maintainers
<heat>
idk, their lawyers said so
<Ermine>
Hypothesis is that they suddenly got some legal paper from some US agency demanding them to remove maintainers
<nikolar>
that's what i'd expect
<nikolar>
people don't just do this randomly years after sanctions were issued
<bslsk05>
lore.kernel.org: Re: [PATCH] MAINTAINERS: Remove some entries due to various compliance requirements. - James Bottomley
<Ermine>
also, judging by the timing, it can theoretically be related to NK troops
<Ermine>
non-joke thought 4: there is a bunch of drivers which have become unmaintained now
<nikolar>
nicež
<heat>
yeah, PATA code for instance
<heat>
and ipv4 gre code
gildasio has quit [Ping timeout: 260 seconds]
gildasio has joined #osdev
<nortti>
reminds me, the upstream sortix repository is unreachable for at least one user in iran due to gitlab deying access on grounds of the US sanctions
<heat>
github will soon be unavailable for all of china, as they continue their plans for ipv6-only
<heat>
:D
aethlas_ has quit [Read error: No route to host]
aethlas has joined #osdev
<Ermine>
heat: what's your philosophy on passing error data now then?
* Ermine
thinks of EBFYTW
<heat>
return -ENOMEM; or return ERR_PTR(-ENOMEM); are both clever ideas
<heat>
which don't require a fucking global
<heat>
or return ENOMEM if you're in the classic UNIX/BSD sphere
<heat>
in C++ you'd see the ERR_PTR pattern as kind of like expected/unexpected, in rust you'd see it as std::Result
X-Scale has joined #osdev
<Ermine>
okay, thx
aethlas has quit [Quit: bye]
aethlas has joined #osdev
aethlas has quit [Ping timeout: 252 seconds]
aethlas has joined #osdev
khimaros has quit [Remote host closed the connection]