stikonas has quit [Remote host closed the connection]
nsaenz has joined #linux-rockchip
nsaenz has quit [Ping timeout: 245 seconds]
<mmind00>
anarsoul: also you could check first of course if your mode turns up in /sys/class/dri/*/modes and after that check the clk_set_rate in rockchip_drm_vop what rate it tries to set and which rate this actually results in
<Kwiboo>
yeah, my patch adds most clocks for the DRM_MODE I could find in drivers/gpu/drm/drm_edid.c, 2560x1440 is not listed but worked last time I tested, I will run a new test on my 2560x1440 screen later today
stikonas has joined #linux-rockchip
<t3st3r>
Are there rockchip boards around $30-40 that are reasonably supported by mainline? Ideally same or very similar board(s) should be multi-sourced by several vendors.
<t3st3r>
Interesting board, though CPU makes me scared on TDP & power grounds. Is boot software opensource? E.g. early boot loaders, ARM trusted firmware (if needed)? Mainline kernel, etc?
<t3st3r>
So basically would all-open software bring me to my OS image?
<mmind00>
t3st3r: just realized there isn't a mainline dts for nanopi-neo4 yet ... only nanopi-m4 and -t4 (but that should be easily doable)
<mmind00>
t3st3r: for other parts ... rk3399 has u-boot support, ATF support for rk3399 is upstream
<mmind00>
t3st3r: due to rk3399 being part of recent chromeos devices it got (and still gets) a lot of attention in mainline
<mmind00>
t3st3r: and of course rk3399 is the soc, panfrost is developed on (panfrost being the free mali-midgard driver) ;-)
<t3st3r>
mmind00> I guess I can live with non-mainline DTS - if it just that. But I do care to be able to change any part of boot sequence without some "secure boot" or proprietary blobs on the way.
<t3st3r>
on a very basic level I want something like automation controller and I'm curious if there're rockchip things that could help with it. I see rockchip got plenty of commits to mainline, etc. That's why I'm curious.
<mmind00>
t3st3r: boot sequencing on rockchip is pretty open ... most socs do have support in uboot for both boot stages ... and atf support for all 3 arm64 socs is also in the upstream repo ... but rk3399 is the most widespread soc from these
<mmind00>
t3st3r: with quite a number of people working on it also caring about software freedom
sb35 has joined #linux-rockchip
<t3st3r>
Sounds good to me. That's what makes me curious to try rockchip SoCs.
ldevulder_ has joined #linux-rockchip
ldevulder has quit [Ping timeout: 250 seconds]
scelestic has quit [Quit: leaving]
scelestic has joined #linux-rockchip
sb35 has quit [Ping timeout: 250 seconds]
sb35 has joined #linux-rockchip
ldevulder_ has quit [Read error: Connection reset by peer]
ldevulder_ has joined #linux-rockchip
marcodiego has joined #linux-rockchip
<hanetzer>
I own 3 rockchip devices (all chromebooks). Wonderful little things :)
BenG83 has quit [Ping timeout: 240 seconds]
<t3st3r>
I'm not interested in chromebooks at this point, just SBC or maybe module. Also I can imagine getting rid of Google "goodies" can be a challenge.
<hanetzer>
for the ones I got nah. YOu can run fully ungoogled
<t3st3r>
Still if I would like something non-x86 like laptop that could be more or less trusted, olimex got funny open-hardware thing.
<t3st3r>
it as open as having CAD files of PCBs available, using opensource KiCAD. Guess persuading 'em to do module based on rockchip same way could be great idea.
<t3st3r>
They seems to be fans of open things and also use ICs of another chinese vendor already. At 1st glance rockchip seems to be more cooperative in terms of mainline HW support and so on.
cyteen has quit [Remote host closed the connection]
<hanetzer>
t3st3r: there are some rockchip modules. DIMM form factor
<t3st3r>
if it comes to laptops my favorite would be https://www.olimex.com/Products/DIY-Laptop/ - it meant to be able to use different CPUs. But so far it got non-rockchip cpu from less friendly vendor.
<t3st3r>
The only laptop I know boasting CAD files for PCBs editable in opensource CAD program, a very cool idea to my taste. It also meant to support different CPUs over time.
t3st3r has quit [Ping timeout: 256 seconds]
t3st3r has joined #linux-rockchip
stikonas has quit [Remote host closed the connection]
stikonas has joined #linux-rockchip
<anarsoul>
Kwiboo: mmind00: well, the mode is in edid, so I'm not sure why it doesn't show up in /sys/class/dri/*/modes
<anarsoul>
btw I tried libreelec build for rock64 and it can do only 1080p on this monitor
vstehle has joined #linux-rockchip
<Kwiboo>
anarsoul: hum, I would have thought libreelec would work in that resolution, I will test my rock64 on my 2560x1440 monitor shortly
<anarsoul>
Kwiboo: mine is 2560x1440x60 Hz
<anarsoul>
Kwiboo: btw, does libreelec support IR receiver on rock64?
<Kwiboo>
I have a HP Z27n monitor that should use same resolution, and yes the ir-receiver should work and it is pre-configured to use a mapping with the pine64 remote
<Kwiboo>
all media related input/output should work (hdmi/(hdmi)audio/cec/ir/lan/usb + wifi/bt on some boards) they are the ones I test, other input/output will probably not work
aalm has quit [Ping timeout: 240 seconds]
<anarsoul>
Kwiboo: I take my words back, it actually works fine with nightly build
<alibabashack>
Hi guys! I'm currently playing with an RK3066 via rockusb in mask ROM mode. Does somebody know if it is possible to read the internal SRAM and ROM regions?
<alibabashack>
rkflashtool m 0x10100000 1024 >foo always returns zeros only
<alibabashack>
My final aim is to load and execute a small image to the internal SRAM without initialization of DRAM. Hints are very welcome. Thanks.
<mmind00>
alibabashack: just look at uboot's spl stage? While there is no direct rk3066 support yet, the rk3188 is nearly identical, so that should possibly help you already?
<alibabashack>
mmind00: That might help for the image preparation, thank you, but for now I am not quite sure whether it is actually possible to write to the SRAM directly via mask ROM. The protocol doc of rkflashtool only speaks about DRAM and flash.
<mmind00>
alibabashack: the "downloadboot" option would be the appropriate one I think
<mmind00>
which is the part that downloads the initial code (with RKxx header) into the blank sram
<alibabashack>
mmind00: ah great, thanks! Just wondering: When the chip runs from mask ROM, isn't a part of the SRAM in use for stack and .data/.bss sections? Which parts can I safely overwrite? Is there any documentation on that?
nashpa has joined #linux-rockchip
<mmind00>
alibabashack: I guess just look at how uboot handles that
<mmind00>
alibabashack: there is a stack pointer and stuff used in uboots SPL and that generally works nicely there
<alibabashack>
mmind00: I'll have a look at uboot then. Thanks again.
alibabashack has left #linux-rockchip [#linux-rockchip]