DC-IRC has quit [Remote host closed the connection]
DC-IRC has joined #armbian-broadcom
<DC-IRC> <clever___> i vaguely remember an engineer saying it works with the radxa?
<DC-IRC> <clever___> the argument ive heard there, is that a 5A capable C<->C cable, needs its own PD comms chip, which drives up the cost
<DC-IRC> <clever___> a PSU with a fixed cable can just claim to be both parties
<DC-IRC> <clever___> but i do agree, when the cable does fail, it going to be a lot more expensive to replace
<DC-IRC> <mariob> not sure where I read that, but it was from an engineer too i believe
<DC-IRC> <mariob> someone reported that it doesn't negotiate more than 3A
<DC-IRC> <mariob> and the engineer ordered one to test and see why
<DC-IRC> <clever___> i believe all of the PD negotiation is done in the bcm2712 firmware on the VPU
<DC-IRC> <clever___> so they can fix such bugs with just an `rpi-eeprom-update` call
<DC-IRC> <mariob> the first time i heard about 5V 5A is from this radxa psu
<DC-IRC> <clever___> something else i want from the pi5, is a sort of PD reporter
<DC-IRC> <clever___> exactly what modes does the attached device list as valid?
<DC-IRC> <mariob> the first time i heard about 5V 5A PD is from this radxa psu
<DC-IRC> <mariob> if that runs on the VPU, unlikely that they'll ever provide that
<DC-IRC> <mariob> if it runs on the VPU, unlikely that they'll ever provide that
<DC-IRC> <clever___> they already have 2 ways to access the PMIC
<DC-IRC> <clever___> `vcgencmd pmicrd 0x12` can read any PMIC register
<DC-IRC> <mariob> one could actually request more from the PSU and fry the board
<DC-IRC> <clever___> `vcgencmd pmicwr 0x12 0x34` can write any PMIC register
<DC-IRC> <mariob> one could actually request higher voltage from the PSU and fry the board
<DC-IRC> <clever___> but, there are no da9091 datasheets, and i would assume the PD peripheral will get confused if 2 hosts try to boss it around at once
<DC-IRC> <clever___> `drivers/rtc/rtc-rpi.c` talks to the firmware over the standard property mailbox
<DC-IRC> <clever___> the RTC itself, is a feature of the da9091, so the firmware then relays those commands to the PMIC
<DC-IRC> <clever___> so all they need, is a way to PD packet out the port, and a big scary warning
<DC-IRC> <Tonymac32> PD requires the cable also identify as 5A capable
<DC-IRC> <Tonymac32> basically PD is an awesome, amazing, super useful, pain in the ass
<DC-IRC> <infinity_q> lol
<DC-IRC> <Tonymac32> these are not mobile devices, use a barrel
<DC-IRC> <clever___> yeah, thats why i mentioned, a psu with a removable cable is more expensive overall
<DC-IRC> <clever___> because it needs a smart cable
<DC-IRC> <clever___> while the rpi psu, has a permanently attached cable, so they can cheat and have 1 chip doing both psu and cable roles
<DC-IRC> <Tonymac32> yeah that's fine, it's their liability
<DC-IRC> <clever___> thats also why i want better pd logging and diagnostics
<DC-IRC> <Tonymac32> *I* am not running 5A through a usb cable to a marginally engineered SBC
<DC-IRC> <Tonymac32> 😄
<DC-IRC> <clever___> so i can both debug pi5 problems, and document what a cable or psu can do, and figure out its compatability matrix with non-rpi devices
<DC-IRC> <clever___> and the pi5 can throttle itself and run at 3a
<DC-IRC> <clever___> most of that i think is "spare" power for the usb-a ports and hdd's
<DC-IRC> <mariob> that's probably it. the cable i got with my radxa psu is not e-marked
<DC-IRC> <Tonymac32> the fact it is 5V is a complete and utter travesty
<DC-IRC> <mariob> yet they promote it as PD too 🤦‍♂️
<DC-IRC> <infinity_q> I mean, seriously? rk3588 has more io *and* more cpu. and it only usually requires 4A
<DC-IRC> <Tonymac32> well, the nanopi M4, M4V2, etc are the same
<DC-IRC> <Tonymac32> and it is... less than optimal
<DC-IRC> <mariob> it doesn't need that much current, but you know, peripherals
<DC-IRC> <Tonymac32> I don't currently run any RK3588 at 5V so I don't know what the pull is there
<DC-IRC> <Tonymac32> but Mario is correct, if you want USB to work you need some oomph
<DC-IRC> <Tonymac32> Asus handled this by putting power electronics that could jump a car on the front end of the Tinker board 2
<DC-IRC> <Tonymac32> up to 19V in
<DC-IRC> <Tonymac32> barrel jack
<DC-IRC> <Tonymac32> every USB port conforms to standards for current output
<DC-IRC> <Tonymac32> also a bit expensive, and only I have mainline images 😉
<DC-IRC> <clever___> rpi engineers have stated, that they only accept 5v, because of board space issues, and extra waste heat from a variable->5v buck converter
<DC-IRC> <Tonymac32> pfffffffft
<DC-IRC> <mariob> rock 5a in the meanwhile
<DC-IRC> <Tonymac32> the heat is nothing, that's pure lies
<DC-IRC> <clever___> but i did give an example, of how to abuse the ideal diode....
<DC-IRC> <mariob> with PD and m.2 slot
<DC-IRC> <infinity_q> but that oomph is not really best suited to be coming from the SBC, unless the board is like industrial rated
<DC-IRC> <clever___> a basic switching PSU diagram i found online
<DC-IRC> <Tonymac32> well, I've maintained for a long time if they put the blue ports on there, 900 mA better come out of all of them at the same time
<DC-IRC> <clever___> you just PWM the transistor, and you get a variable voltage, add some feedback, and your done
<DC-IRC> <clever___> if you feed 5v in, and 100% duty cycle, you should get 5v out?
<DC-IRC> <clever___> only limited by the series resistance of L1
<DC-IRC> <Tonymac32> thousands of buck convereter IC's exist that can do this job, every Rockchip has them
<DC-IRC> <clever___> and current spikes wont pass as easily
<DC-IRC> <mariob> it's not that they couldn't add it due to space or other BS, just cost
<DC-IRC> <infinity_q> that would require some beefy filtering
<DC-IRC> <mariob> if even cost
<DC-IRC> <Tonymac32> hell I built one for a motor control hat that was up to 24 v in to 5V out 3 A
<DC-IRC> <Tonymac32> wasn't even hard
<DC-IRC> <Tonymac32> spent 30 minutes on it
<DC-IRC> <clever___> how would it be done better?
<DC-IRC> <Tonymac32> and the board space is almost nothing
<DC-IRC> <clever___> where would you fit it on here?
<DC-IRC> <mariob> backside
<DC-IRC> <Tonymac32> lol in place of the PD BS
<DC-IRC> <mariob> how did radxa pull it off on 5a?
<DC-IRC> <Tonymac32> 🙂
<DC-IRC> <clever___> there is a lot of traces in the power corner, on the back side.....
<DC-IRC> <Tonymac32> like all their boards this is just poor layout
<DC-IRC> <infinity_q> because they are not rpi
<DC-IRC> <Tonymac32> remember it took unitl the 3 or 3+ or something to figure out that ground planes can be used to move heat
<DC-IRC> <Tonymac32> and the bragged about it
<DC-IRC> <Tonymac32> when really they should have been ashamed 😄
<DC-IRC> <Tonymac32> it's fine if they aren't up to industry standards, until they sell themselves as such. I wouldn't give them any grief if they werent so absorbed in their own image
<DC-IRC> <Tonymac32> This board looks ok, I'm not sold I want their "southbridge" IP on it though
<DC-IRC> <Tonymac32> seems syupid to reinvent the wheel
<DC-IRC> <Tonymac32> seems stupid to reinvent the wheel
<DC-IRC> <clever___> the way i see it, all of the peripherals that make an rpi an rpi, are now isolated from the SoC
<DC-IRC> <clever___> so they could switch to another SoC vendor, without it ceasing to be rpi like
<DC-IRC> <mariob> they moved a ton of stuff there though..
<DC-IRC> <mariob> this seems the most plausible reason tbh
<DC-IRC> <Tonymac32> well, they are stuck to the VC like nothing else
<DC-IRC> <clever___> any SoC with a pcie controller could be slotted in, and it would basically still be an rpi
<DC-IRC> <Tonymac32> moving to a different GPU would wreck their entire ecosystem I think
<DC-IRC> <clever___> for the pi5, yeah
<DC-IRC> <clever___> but now that the RP1 is done, does it need to stay with broadcom?
<DC-IRC> <Tonymac32> the VC is still the system supervisor isn't it?
<DC-IRC> <clever___> only the vc4 v3d has been properly documented
<DC-IRC> <clever___> everything else is undocumented and driven thru linux drivers
<DC-IRC> <clever___> yes, even on the pi5
<DC-IRC> <Tonymac32> yeah, they'd have to have all new everything to retool fromt hat
<DC-IRC> <Tonymac32> yeah, they'd have to have all new everything to retool from that
<DC-IRC> <clever___> they already did on the pi5
<DC-IRC> <clever___> the VPU firmware is doing almost nothing, compared to the pi4
<DC-IRC> <clever___> it only manages basic bootup logic, and thermal/voltage throttling
<DC-IRC> <Tonymac32> did they fully abstract that behind some EFI firmware or something?
<DC-IRC> <clever___> you could easily do that with just u-boot
<DC-IRC> <clever___> PSCI for secondary core bringup, shutdown, reboot, and suspend2ram
<DC-IRC> <Tonymac32> interesting, they might be moving in the right direction, by 2027 we might see something interesting. 😉
<DC-IRC> <clever___> i found chunks of <https://github.com/ARM-software/arm-trusted-firmware> in the armstub
<DC-IRC> <mariob> i'm surprised they got rid of vchiq
<DC-IRC> <Tonymac32> (sarcasm of course)
<DC-IRC> <Tonymac32> I noticed a push to use libgpiod finally
<DC-IRC> <mariob> i'm surprised they got rid of vchiq (or did they actually?)
<DC-IRC> <clever___> the only thing vchiq was handling, was hw encoders and pwm audio
<DC-IRC> <clever___> hw encoders are missing, and the pwm audio service was deleted
<DC-IRC> <Tonymac32> *ears bleeding from that pwm audio*
<DC-IRC> <mariob> what is vcgencmd using?
<DC-IRC> <Tonymac32> they couldn't manage PDM?
<DC-IRC> <clever___> not sure, i havent dug into that much yet
<DC-IRC> <Tonymac32> it's almost the same
<DC-IRC> <mariob> that was the worst thing ever
<DC-IRC> <clever___> the pwm audio was always a hack
<DC-IRC> <clever___> pi5 has something new, but not fully documented
<DC-IRC> <clever___> a hw block on the rp1 does the same math the VPU was doing on a vector core, and drives a pwm like signal
<DC-IRC> <mariob> they even went as far as to implement some noise shaping stuff
<DC-IRC> <mariob> but it sounded the same lol
<DC-IRC> <Tonymac32> My $3 ESP32 can do PDM https://en.wikipedia.org/wiki/Pulse-density_modulation
<DC-IRC> <mariob> with all the bg noise
<DC-IRC> <clever___> that might be what the RP1 is now doing, but we will have to wait for more docs
<DC-IRC> <Tonymac32> no it sounded pure PWM grossness
<DC-IRC> <Tonymac32> I have the OG Pi1 with no extra headers/etc
<DC-IRC> <Tonymac32> lol
<DC-IRC> <clever___> thats not the RP1
<DC-IRC> <clever___> thats the RP**I**1
<DC-IRC> <mariob> 2 unused SDHCI controllers, no $0.000 something eMMC slot..
<DC-IRC> <mariob> so much wasted potential there
<DC-IRC> <mariob> SD cards should die already for OS usage
<DC-IRC> <Tonymac32> eh they obviously use low layer count PCB's
<DC-IRC> <Tonymac32> so no way to route it out
<DC-IRC> <clever___> ive tried implementing PWM audio on the pi3, and i just did the dumb thing, take each audio sample, and feed it directly to the pwm controller, and it sounds like crap 😛
<DC-IRC> <clever___> the closed firmware PWM audio sounds much better, to my untrained ears
<DC-IRC> <mariob> does it?
<DC-IRC> <mariob> i couldn't tell any difference
<DC-IRC> <clever___> compared to my own implementation, it does
<DC-IRC> <clever___> here is an entirely custom/open implementation of PWM audio
<DC-IRC> <Tonymac32> the comparisons of PWM to PDM are startlinly different
<DC-IRC> <clever___> you can hear major distortion on every drum beat
<DC-IRC> <Tonymac32> higher quality than any RPi pwm I've ever heard
<DC-IRC> <clever___> and here is the exact same hardware, but with the closed firmware helping out
<DC-IRC> <clever___> which would you say is better of those 2?
<DC-IRC> <Tonymac32> hmmm, what is the voltage max of the output and did you account for the 2V line max
<DC-IRC> <Tonymac32> I made that mistake on my board once, made a horrible sound by just overshooting the input
<DC-IRC> <clever___> i suspect its just 3.3v, let me find the scope traces...
<DC-IRC> <Tonymac32> yeah my esp32 board would go full 3.3 and it sounded trash until I limited it to the line out standard
<DC-IRC> <mariob> yeah, there seems to be something wrong in the open firmware one
<DC-IRC> <mariob> i've mostly compared it to the windows driver msft wrote some years ago
<DC-IRC> <mariob> which just sends samples to pwm via dma
<DC-IRC> <clever___> bottom is the raw pwm on a gpio pin (may be in a different vref bank)
<DC-IRC> <clever___> top is after the stock low-pass filter, and run thru some long-ish RCA cables
<DC-IRC> <clever___> this is in PWM mode, so its 1 pulse per sample
<DC-IRC> <mariob> it sounds the same
<DC-IRC> <Tonymac32> since I didn't l-pad it I had to do it in software which cut my bits
<DC-IRC> <Tonymac32> nice tek, I haven't handled one of those ina while
<DC-IRC> <Tonymac32> at work we have lecroy, and I have some Chinese one
<DC-IRC> <clever___> same traces, but i switched the PWM to M/S mode
<DC-IRC> <clever___> so if you set the range to 100, and pass it a sample of 20
<DC-IRC> <clever___> it will produce 20 highs out of 100 clocks, but they are randomly distributed
<DC-IRC> <clever___> that eliminates the strong peak at the PWM period frequency
<DC-IRC> <clever___> but to my untrained ear, it made no difference in audio quality
<DC-IRC> <mariob> i remember having a lot of fun with pwm audio pitch
<DC-IRC> <mariob> they kept changing the PLLs every now and then
<DC-IRC> <mariob> in the f/w
<DC-IRC> <clever___> i have full control over the PLL's, because i replaced every blob
<DC-IRC> <Tonymac32> this reminds me of trying to put a linux SoC ona 4-layer board
<DC-IRC> <Tonymac32> I gave up and didn't want to do 6/8 layers
<DC-IRC> <clever___> line 127 sets this code to 8bit mode
<DC-IRC> <clever___> line 154 sets it to play each sample once
<DC-IRC> <clever___> in 8 bit mode, the range must be 2^8 or 256
<DC-IRC> <clever___> and at 48khz sample rate, the pwm needs a clock of `48*256`khz
<DC-IRC> <clever___> line 181 sets the PWM to be driven from PLLC (but PLLH also works), and computes the correct divisor, based on the current PLL frequency
<DC-IRC> <mariob> have you tried higher depth?
<DC-IRC> <clever___> higher bit depth needs higher clocks
<DC-IRC> <mariob> it can take quite a bit of overclock
<DC-IRC> <clever___> 16bit PWM would need a 3.14ghz pwm clock
<DC-IRC> <Tonymac32> 😄
<DC-IRC> <mariob> it works at 13 bit 44.1 khz nice
<DC-IRC> <clever___> and the pwm has a /2 as a minimum
<DC-IRC> <clever___> so i would need a 6ghz PLL
<DC-IRC> <clever___> which is out of spec on many places
<DC-IRC> <clever___> ```
<DC-IRC> <clever___> > 100000000 / Math.pow(2,7)
<DC-IRC> <clever___> 781,250
<DC-IRC> <clever___> ```
<DC-IRC> <clever___> the official firmware, does non-integer upscaling, to ~781khz and 7bit
<DC-IRC> <clever___> and uses dithering to wiggle bit0 of that, to simulate a higher bit depth
<DC-IRC> <clever___> plus all kinds of fancy math i cant wrap my head around and dont want to replicate
<DC-IRC> <clever___> that then lets it use a simple 100mhz pwm clock
<DC-IRC> <Tonymac32> fractional clock multipliers, ugh
<DC-IRC> <clever___> depending on the PLL rate, you may also need fractional division, to clock the PWM
<DC-IRC> <clever___> since i control the PLL, i can avoid that
<DC-IRC> <Tonymac32> yeah
<DC-IRC> <clever___> i was initially having trouble there, because the composite video needs a pure 108mhz to output color correctly
<DC-IRC> <clever___> but now that i got PLLH working, i have 2 clocks to pick from
<DC-IRC> <clever___> and the conflicts have vanished
<DC-IRC> <clever___> the full clock tree, for the vc4 (pi0-pi3) family
<DC-IRC> <clever___> pi4 and pi5 seem to have inherited most of that, but differ in some places
<DC-IRC> <clever___> pwm is over in the peripheral muxes region
<DC-IRC> <clever___> each peripheral has its own private divider and clock mux input
<DC-IRC> <clever___> ive got PLLB, PLLC, and PLLH working under the open firmware
<DC-IRC> <clever___> the others, i mostly just havent bothered trying to get online
<DC-IRC> <clever___> ```c
<DC-IRC> <clever___> bool clock_set_pwm(int freq, enum peripheral_clock_tap source) {
<DC-IRC> <clever___> int reference = get_peripheral_parent(source);
<DC-IRC> <clever___> float desired_divider = (float)reference / freq;
<DC-IRC> <clever___> int divisor_fixed = desired_divider * 4096;
<DC-IRC> <clever___> int mash = 0;
<DC-IRC> <clever___> printf("ref: %d, target: %d, divisor(f): %f, divisor(fixed): 0x%x\n", reference, freq, (double)desired_divider, divisor_fixed);
<DC-IRC> <clever___> if (divisor_fixed < 0x2000) {
<DC-IRC> <clever___> puts("divisor too low, abort!");
<DC-IRC> <clever___> return false;
<DC-IRC> <clever___> }
<DC-IRC> <clever___> if (divisor_fixed >= 0x1000000) {
<DC-IRC> <clever___> puts("divisor too high, abort!");
<DC-IRC> <clever___> return false;
<DC-IRC> <clever___> }
<DC-IRC> <clever___> if (divisor_fixed & 0xfff) mash = 1;
<DC-IRC> <clever___> *REG32(CM_PWMDIV) = CM_PASSWORD | divisor_fixed;
<DC-IRC> <clever___> *REG32(CM_PWMCTL) = CM_PASSWORD | CM_PWMCTL_ENABLE | source | mash<<CM_PWMCTL_MASH_LSB;
<DC-IRC> <clever___> return true;
<DC-IRC> <clever___> }
<DC-IRC> <clever___> ```
<DC-IRC> <clever___> this is an example of configuring the PWM clock
<DC-IRC> <mariob> i don't remember getting frac div to work on pwm
<DC-IRC> <clever___> i had no trouble with it
<DC-IRC> <mariob> not sure why
<DC-IRC> <clever___> the only surprise i ran into, is that `/1` isnt possible
<DC-IRC> <clever___> and it instead does `/4096` when you request `/1`
<DC-IRC> <mariob> probably that
<DC-IRC> <clever___> i initially struggled to get good audio, because of the severe underclock that caused
<DC-IRC> <clever___> and only because i tried making it even slower, did it actually go faster, lol
<DC-IRC> <clever___> when someone else pointed out, they had the same limit on SMI
<DC-IRC> <mariob> yep.. that sounds familiar
<DC-IRC> <clever___> ```c
<DC-IRC> <clever___> int htotal = t->hfp + t->hsync + t->hbp + t->hactive;
<DC-IRC> <clever___> int vtotal = t->vfp + t->vsync + t->vbp + t->vactive;
<DC-IRC> <clever___> int total_pixels = htotal * vtotal;
<DC-IRC> <clever___> float desired_divider = (float)freq_pllc_per / total_pixels / fps;
<DC-IRC> <clever___> #if 1
<DC-IRC> <clever___> int lower_fps = freq_pllc_per / (int)desired_divider / total_pixels;
<DC-IRC> <clever___> int higher_fps = freq_pllc_per / ((int)desired_divider+1) / total_pixels;
<DC-IRC> <clever___> printf("divisor %f, fps bounds %d-%d, ", (double)desired_divider, lower_fps, higher_fps);
<DC-IRC> <clever___> #endif
<DC-IRC> <clever___> if (AVOID_MASH) {
<DC-IRC> <clever___> desired_divider = (int)(desired_divider + 0.5f);
<DC-IRC> <clever___> printf("AVOID_MASH set, divider forced to %d, ", (int)desired_divider);
<DC-IRC> <clever___> }
<DC-IRC> <clever___> ```
<DC-IRC> <clever___> and this is for DPI video, which can do vga or a lot of parallel digital LCD's
<DC-IRC> <clever___> in this case, its able to avoid fractional division, at the cost of changing the fps
<DC-IRC> <clever___> and i have seen, LCD's get weird artifacting if you use fractional and no pixel clock
<DC-IRC> <clever___> the lcd is sampling in the middle of every pixel time
<DC-IRC> <clever___> the pixels vary in size, due to fractional division
<DC-IRC> <clever___> that causes horizontal noise, as the pixels jiggle left/right
<DC-IRC> <clever___> it can be solved, by just sampling on the pixel clock edge, but not all displays support that
<DC-IRC> <clever___> with the current state of the open firmware, i can boot linux on both the pi2 and pi3, and ive even got usb booting working on the pi3
<DC-IRC> <clever___> but i have 2 major roadblocks in the path of using it as a desktop machine
<DC-IRC> <clever___> * the arm cant access the HVS registers, so no 2d accel for linux, enless i re-write the drivers
<DC-IRC> <clever___> * the hdmi block isnt online, and all hdmi registers ignore writes, and return garbage data on read
<DC-IRC> <clever___> so you can only use it on dpi(or vga) or composite, or just headless
<DC-IRC> <mariob> that's pretty cool
<DC-IRC> <clever___> this is the final result of getting side-tracked while implementing usb host
<DC-IRC> <clever___> i had trouble decoding tga files (1 per frame) due to cpu usage
<DC-IRC> <clever___> so i switched to a custom uncompressed palette based video format
<DC-IRC> <clever___> each frame, is just a raw bitmap, 1 bit per pixel
<DC-IRC> <clever___> the video, is just a series of frames!
<DC-IRC> <clever___> ```c
<DC-IRC> <clever___> for (int i=0; i<frames; i++) {
<DC-IRC> <clever___> //printf("frame %d\n", i);
<DC-IRC> <clever___> ret = fs_read_file(video, nextFrame, i * frame_bytes, frame_bytes);
<DC-IRC> <clever___> ```
<DC-IRC> <clever___> then i just do reads (over ext4 and usb), for each frame
<DC-IRC> <clever___> its not even buffering or reading ahead!
<DC-IRC> <clever___> and the 2d core can accept 1bit per pixel images just fine
<DC-IRC> <clever___> you can even change what color the 2 states represent, and throw alpha blending into the mix
<DC-IRC> <clever___> this video is also running at double speed
<DC-IRC> <clever___> its a 30fps video, but i configured it to play 1 frame per vsync
<DC-IRC> <clever___> with with 480i, its getting 60 syncs/sec!
<DC-IRC> <clever___> had to adjust the code after realizing that, to halve the playback speed
<DC-IRC> <clever___> @mariob another thing ive done, that varies massively from the closed firmware
<DC-IRC> <clever___> `/boot` isnt fat32 anymore, its just a directory on `/` and must be ext4
<DC-IRC> <clever___> the boot firmware supports ext4, and just reads the kernel from there!
<DC-IRC> <clever___> id say it offers far more stability in terms of an improper shutdown, but i have yet to implement handling the journal, so it may crash from a partial write confusing things