Got another (broken again) am4 board off of ebay, and this time, the VRM controller let out the magic smoke when I turned it on. Hopefully at least the interesting parts are still fine
Remote
Coreforge
@coreforge@furry.engineer
mastodon 4.6.8+glitchI sometimes do things
71 Followers
8 Following
28 Posts
Joined November 28, 2024
The codec on the other board seems to still be dead, but I now have input working on this one (same interface in the end, it's all HD-Audio).
It's not a very useful USB soundcard at mono 48kHz, but it sounds not too bad.
Mainly shouting into the void, but does anyone happen to be a bit more familiar with the LPC bus (or know someone who is)?
I'm trying to implement it on an rp2040, and writes seem to be working fine, but the SuperIO chip (NC6795) doesn't drive the bus after the turnaround cycles.
Writes are still received correctly by the SuperIO, as I can see data being output if I write to port 80, and I can control GPIOs fine too.
When checking the bus with an oscilloscope, the rp2040 seems to tri-state the data pins correctly. Adjusting the exact time the pin direction is set didn't make a difference so far. Since comparing with the spec and other captures I've found didn't result in anything, and writes have an effect, I'm running out of ideas.
I haven't tried a different board yet in case it's hardware damage to the SuperIO, but I somewhat doubt that (it would have to be just the output drivers that are damaged).
If anyone has any ideas, I'd appreciate them.
Looks like you can't take your eyes off of these things for even a second without them going for your PC
Replying to
only SATA and the PCIe switch properly work so far though, the ethernet driver fails to initialize, and USB doesn't detect any devices (on the ports where it should)
I got Deutsche Bahned a bit on my way back from EF
I think I might actually be running into some of the broken aspects of this motherboard now.
When trying to get VCore up, I notices SLEEP_S3 was missing on one transistor, keeping a few rails from turning on (in other places, it was present, and according to the schematic and board view I have, they should be directly connected).
Since the enable signal for the VRM controller (RT8894A) is still low with no obvious reason, I tried simply pulling it high (first with a resistor), which had the chip heat up a lot. It should just be an input, so that chip is likely bad (the high-side VDDP mosfets being stuck on also isn't a great sign, and puts that rail at 12V instead of the usual ~1V it should be).
Still not bad for the price I paid for it, but I might have to look for a more functional one (maybe with a better chipset too, 4 gen2 lanes are fine, but more could be nice to have, even if the chipset it still only connected with one lane).
18 Minutes of delay so far, hopefully I won't get Deutsche Bahned too badly
apparently even PCIe gen2 works with my loose wire setup, with still no errors reported (and the speed did double from gen1). gen3 gets no link though, which isn't really a surprise.
Replying to
@Holocene@techtoots.com The first HUB pcie lane on the socket (there's 16 GFX lanes, which goes to the x16 slot usually used for a GPU, 4 GPP lanes, here they're connected to the m.2 slot, and 4 HUB lanes that go to the chipset)
Replying to
@chocolateloverraj@mastodon.social mostly, everything that's connected to the chipset (the x16 slot and the m.2 slot are directly connected to the CPU, so they don't work).
On this board, that's four PCIe lanes distributed over four slots, a USB controller (for the USB-C port on the back), an ethernet controller (which doesn't work yet), and the USB and SATA controller integrated into the chipset.
The pi5 firmware really doesn't like if you mess with the connection to the RP1 in any way, disconnecting just one lane seems to already make it fail. I don't know if maybe putting a PCIe switch in between could work (but it seems a bit unlikely), but I don't really have the soldering equipment to try that right now (without the risk of just fully breaking this thing being too high, which I'd rather not do)
Replying to
To read out the iNVM, read 64 32-bit words starting at 0x12120 from BAR 0 of the controller (with something like pcimem). This does (or at least should) contain your MAC address, if you want to keep that private.
Replying to
@ronya@chaos.social GPUs were the reason I bought this pi in the first place, but those have been working for a little while now
Replying to
@Foxarc@furry.engineer I usually post it in the github issue. high-speed now works too though
Got a CM5 now, hopefully I won't break it immediately :3
(looks like the firmware probably wouldn't like what I originally wanted to do, but there's still a couple options I want to try)
Replying to
With that fixed, it's still down at 25fps often enough (mostly CPU bound, the GPU is getting bored)
Replying to
@scavello @thomasjwebb .wang domains also give you some pretty good options (but half the thesaurus for some words is already taken)
Replying to
@omegatotal@mas.to someone briefly started on a cm5 carrier board. I don't think powering it through the socket would work though, the socket only provides 3.3V at the highest, and I don't know how much current you get get through there (it's only two pins)
Replying to
@omegatotal@mas.to I guess that would work. I haven't had VCore turned on yet, but that can go up to 1.5V, which I think is the highest of the high power rails on the socket. For anything that's not a compute module (and for those as well tbh), it's easier though to just take 5V from the power supply directly, or through one of the rear USB ports that don't work anyways.
For a full carrier board it would be nice though if it's doable with the thickness of the inductors you'd need.
Replying to
@chocolateloverraj@mastodon.social It's connected to PCIe. The chipset is just a PCIe device.
Replying to
@max@peering.social If you have a reason to actually do this, it might be. This should work fine for pretty much any chipset from B350 onwards, just firmware loading might be a bit different.