System_Error has quit [Remote host closed the connection]
System_Error has joined #linux-rockchip
kevery has quit [Remote host closed the connection]
kevery has joined #linux-rockchip
vagrantc has quit [Quit: leaving]
naoki has joined #linux-rockchip
stikonas has quit [Quit: Konversation terminated!]
System_Error has quit [Remote host closed the connection]
System_Error has joined #linux-rockchip
hexdump0815 has quit [Ping timeout: 260 seconds]
hexdump0815 has joined #linux-rockchip
System_Error has quit [Remote host closed the connection]
System_Error has joined #linux-rockchip
System_Error has quit [Remote host closed the connection]
naoki has quit [Quit: naoki]
naoki has joined #linux-rockchip
naoki has quit [Client Quit]
naoki has joined #linux-rockchip
naoki has quit [Quit: naoki]
naoki has joined #linux-rockchip
franoosh has joined #linux-rockchip
ungeskriptet has quit [Ping timeout: 244 seconds]
ungeskriptet has joined #linux-rockchip
ungeskriptet_ has joined #linux-rockchip
ungeskriptet has quit [Ping timeout: 252 seconds]
ungeskriptet_ is now known as ungeskriptet
Woutervanh has joined #linux-rockchip
<Woutervanh>
robmur01: I must be doing something wrong then. I enabled both vopb and vopl, but then none of the cards work. I also see logs about cycle dependencies on lvds/edp. I guess because both vopb and vopl support lvds/edp. I'm in doubt how to do routing correct. Is there an example dts somewhere? You mention chromebooks?
raster has joined #linux-rockchip
<mmind00>
Woutervanh: there should be no "routing" ... both VOPs can drive the eDP and both VOPs can drive the LVDS ... and the source-vop is selected in the output drivers (edp + lvds) to set the (hopefully) correct bit in GRF_SOC_CON6 ... for where they should get their output
<Woutervanh>
based on what will it assign a vop then?
<mmind00>
first-come-first-serve normally :-)
<mmind00>
and for most displays that also is fine
<Woutervanh>
Well, now I added both lvds and edp in my devicetree, and have vopl, vopl_mmu, vopb and vopb_mmu all okayed, but none of them works. Not lvds, not edp
<mmind00>
(high-res hdmi or so can be a problem, when connected to the "little" vop, I think)
<Woutervanh>
there's no hdmi, only lvds (dual channel, 1920x1080) and edp
<Woutervanh>
edp also 1920x1080 if that matters
<mmind00>
Woutervanh: you might want to push your DT to some github repo so people can look at actual code ;-) ... also "edp" and "edp_phy" are both on, right?
<Woutervanh>
yes, they are. Indeed, was just going to put it online
<mmind00>
and maybe also post the dmesg output to some paste-thing ;-)
<mmind00>
Woutervanh: the complete absence of "drm"-related lines in there, makes it look like dependency problem
<mmind00>
with the drm-driver never actually starting to probe at all
<Woutervanh>
in the dmesg you mean? Yeah, but if I remove the edp cruft in the dts, then it does work. I'll also upload a dts which actually works with lvds, mom
<mmind00>
Woutervanh: ah, so lvds-only works
<Woutervanh>
correct, I updated the gist with the working dts
<qschulz>
dvergatal: he literally wrote 15seconds before :D
<Woutervanh>
mmind00: hm, should the panel type matter? I was under the impression it was something else as it was stating nvidia...
<mmind00>
Woutervanh: yes it matters a lot ... the edp-driver _needs_ its panel, your panel-compatible does not even exist, so no panel driver ever probes
<mmind00>
Woutervanh: so the edp's panel requirement never gets satisfied, so the rockchip-drm waits indefinitly for the edp to appear
<dvergatal>
qschulz: ooo you are as well in here as in yocto:P
<dvergatal>
qschulz: hi
* qschulz
waves
<dvergatal>
qschulz: i know he has but I didn't know if he has time to chat that is why i asked
<dvergatal>
mmind00: do you have some contacts to sales department in rockchip? caz i can't reach kever...
<mmind00>
dvergatal: not at all ... I only know technical people
<dvergatal>
mmind00: can you reach them? or ask for contact to the sales department?
<Woutervanh>
mmind00: I changed it to compatible = "edp-panel", but still the same
<qschulz>
Woutervanh: I have virtually no experience there, but maybe enable one at a time? LVDS first, then eDP once the former is working?
<rtp>
oh, looks like I failed to read it entirely :(
naoki has quit [Client Quit]
<rtp>
clone the repo. thansk
naoki has joined #linux-rockchip
<mmind00>
dvergatal: not sure what you need their sales people for ... I'd think one of their distributors would be the better match, except when you plan on buying tenthousands of chips?
<dvergatal>
mmind00: sorry i had to gone for a couple of hours
<dvergatal>
go*
stikonas has joined #linux-rockchip
tlwoerner has joined #linux-rockchip
<qschulz>
anyone with an Orange Pi 5+ or Rock 5 ITX by any chance? On RK3588 Jaguar, the USB stick connected to the USB-C ports is running in USB2-only when in reverse direction
<qschulz>
and I want to know if it's something specific to Jaguar or not :)
<qschulz>
obviously USB3 when in normal direction
<qschulz>
s/direction/orientation/
<wens>
qschulz: have one Orange Pi 5+, though I'm not at my place over the weekend
System_Error has quit [Remote host closed the connection]
System_Error has joined #linux-rockchip
<Kwiboo>
qschulz: not sure usb-c orientation switch is fully functional,
MyNetAz has quit [Remote host closed the connection]
<Kwiboo>
had some issues on my rk356x board before, but may have been that it did not use a full fusb302
naoki has quit [Quit: naoki]
<qschulz>
Kwiboo: ah good point, looking at the schematics I can see that the USB2 lines are routed the same regardless of the orientation
<rtp>
Kwiboo: thanks to qschulz, I've used your git branch. It worked on roc-pc-rk3399 and rock5b. Managed to boot the 2 binaries with my current snagrecover branch
MyNetAz has joined #linux-rockchip
Woutervanh has joined #linux-rockchip
<Woutervanh>
mmind00: thanks for the help so far. I already get the 2 cards now. No visual yet though, think I will need to fiddle a bit with panel/backlight
<mmind00>
Woutervanh: great that you had progress
<qschulz>
Woutervanh: you may want to generate a pattern with modetest -s, I sometimes have blank displays that work just fine
<Woutervanh>
yeah, will continue on that after the weekend (y)
Woutervanh has quit [Client Quit]
<Kwiboo>
rtp: for rk3588 devices there may be an issue with 16GB+ ram devices, forgot to mention that when sending out the series, when SPL+FIT (usb472) is sent to device, it will overwrite the rk-atags that signal the usable dram areas
<rtp>
I wish I had a 32gb version of rock5b but that's not the case. When I bought it, there was only 16GB available. So, obviously, I can't run into this issue
<qschulz>
Kwiboo: oh, that's bad
<qschulz>
I assume there's no way to specify a specific offset for usb472 when uploading, it just starts at 0?
<qschulz>
Kwiboo: why 16+ specifically, don't we have holes for anything above 4GB?
<rtp>
I don't remember seeing some code mentioning you can specify the upload offset
<diederik>
Kwiboo: is that >= 16GB or > 16GB?
<rtp>
diederik: > 16GB (unless I'm lucky). It worked on my 16GB rock5b
<diederik>
Thanks :) My 16GB Rock5b is on the way ;)
<diederik>
(and considered the 32GB one, but didn't go for it (but it was an option when I ordered))
<qschulz>
Kwiboo: sorry to keep asking the same questions, but we're uploading to 471 and 472 and then only executing the code?
<qschulz>
basically my idea being: can we upload 471, read the DRAM to store the ATAGS on the host, inject the ATAGS in the 472 payload and then upload to 472 to continue execution?
<Kwiboo>
rtp: at least in the idblock image we can say what sram/dram an image should be loaded to, I am guessing it may also be possible with the 471/472 commands, have so far not seen any code that tries to load the second blob somewhere else beside start of dram
<Kwiboo>
qschulz: maskrom seem to be executing the blob as soon as the last packet has been sent, i.e. once it receive a command indicating packet size != 4096 (or similar)
<qschulz>
is there any command to read stuff from the DRAM is now the question :D because then once TPL returns to BROM we could read the DRAM for the ATAGS and inject them in the 472 payload
<Kwiboo>
so maskrom starts waits on 471 commands, append the data to SRAM, and once data-packed lenght != 4096, jumps/runs the code, once TPL return-to-brom bootrom will listen for 472 commands and write to DRAM instead of SRAM
<Kwiboo>
at least that is my understanding of how it seem to work :-)
<qschulz>
that'd make sense
<Kwiboo>
if we can signal at where in dram the 472 payload is written, we could put it somewhere else and just have a small relocation code (memmove) run before regular code
<Kwiboo>
for the new rk3506 (armv7) they have put tee-os at 0x1000 and spl at ~63MiB, have not looked at how that works with maskrom download, but may suggest it can be possible to have it load to different address
<rtp>
Kwiboo: oh, thanks. Will update it on monday :)
<mmind00>
Kwiboo: rk3506 and armv7 ... whut? :-D
<CounterPillow>
mmind00: yes :(
<CounterPillow>
armv7 will never die
<mmind00>
seems like Google does not yet know the rk3506
<CounterPillow>
meanwhile, STM is rebranding their Cortex-A7 based designs to be targeted at "AI", because what really makes me think of the future is a design from 2011 on a foundry process from the 00s
<mmind00>
but ... but ... but ... it has "AI" ... that has to count for something
* mmind00
somehow combined rk3506 with armv7 ... and searched for rk3507 ;-)
<CounterPillow>
Kwiboo: oh neat, I wonder if the RK3506 on those is upstream-able unlike the RV110x chips they used previously which iirc needed some stuff that simply wasn't gonna fly
<mmind00>
Kwiboo: my arm32 branch is terribly empty still for 6.15 ... you can change that :-D
<CounterPillow>
oh it uses the SAI IP for audio
<CounterPillow>
I'm currently working on an upstream port of that
<mmind00>
3 cores? ... is that some sort of thing with one disabled core due to manufacturing?
<CounterPillow>
would be a weird choice when there's no 4-core version
dsimic has quit [Ping timeout: 248 seconds]
dsimic has joined #linux-rockchip
<CounterPillow>
Honestly, weird SoC. Claims to be aimed at audio applications and has plenty of audio interfaces but no DSP?
<robmur01>
but hey you've got two whole A7s with NEON to run your DSP on while the third one runs the OS :D
raster has quit [Quit: Gettin' stinky!]
<CounterPillow>
There's a mention of a "DSP0 Power" in the datasheet with no other mention of DSP as far as I can tell, so maybe there is a DSP and they just glossed over that essential feature