stikonas has quit [Remote host closed the connection]
vstehle has quit [Ping timeout: 260 seconds]
vicencb has quit [Quit: Leaving.]
field^Zzz3 has joined #linux-rockchip
field^Zzz2 has quit [Ping timeout: 246 seconds]
field^Zzz4 has joined #linux-rockchip
field^Zzz3 has quit [Ping timeout: 244 seconds]
solarsparq has joined #linux-rockchip
vstehle has joined #linux-rockchip
ldevulder_ is now known as ldevulder
nlhowell has joined #linux-rockchip
midnight has quit [Ping timeout: 244 seconds]
midnight has joined #linux-rockchip
vicencb has joined #linux-rockchip
lkcl__ has quit [Ping timeout: 260 seconds]
lkcl__ has joined #linux-rockchip
<topi`>
it seems this board is dissimilar from radxa rock2. It uses a RK808 regulator instead of Active Semi act8846
<topi`>
let's see if any rk3288 boards out there in the mainline kernel are using rk808...
stikonas has joined #linux-rockchip
<robmur01>
topi`: yes, if anything the RK808 version of the RK3288 reference design is more common than the ACT8846 one
<robmur01>
if you have a vendor DTB, it shouldn't be massively difficult to reverse-engineer the differences - other than chromebooks, most boards don't deviate *too* much from the reference design
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 246 seconds]
kevery1 is now known as kevery
<DuClare>
topi`: You're buying more boards? :P
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 240 seconds]
kevery1 is now known as kevery
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 272 seconds]
kevery1 is now known as kevery
<topi`>
DuClare: just for a customer...
<topi`>
robmur01: yeah, I already found out the rk3288-evb-rk808 dtsi, trying to use that as a template
<topi`>
the vendor supplied Android kernel tree is from 2014, so it's going to be out of date at least for some parts
<topi`>
e.g. the rk_sdmmc.c is nowadays called dw_mmc-rockchip.c
<topi`>
I'm not going to even pretend that a .dts made for a 2014 kernel would work out of the box.
<topi`>
it's just sad that the vendors in Embedded system space are content with using 3.x kernels in year 2020.
<robmur01>
sure, it won't work, but it'll still describe GPIOs, regulators, etc in a recognisable way that you can base a new DT on ;)
<topi`>
i'm trying to get the basic stuff working first. sdmmc, gmac, usb etc
<topi`>
the end user will install these in a headless way anyway
<DuClare>
I'm using 5.4.x
<topi`>
most rockchip things are in a very good shape in 5.x kernels
<topi`>
it was a bit riskier back in 2015 :)
<robmur01>
my favourite trick is to build the EVB/generic TV box DTBs from the 4.4/3.10/whatever BSP branch, then diff the vendor DTB against those - usually the changes turn out to be minimal
nlhowell has quit [Ping timeout: 256 seconds]
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 260 seconds]
kevery1 is now known as kevery
<topi`>
ERROR (phandle_references): /vcc-host-regulator: Reference to non-existent node or label "host_vbus_drv"
<topi`>
ok, I still need to work on this :)
<topi`>
I guess I'll go with rk3288-evb's defconfig and see if there are missing bits in the kernel
<topi`>
hmm... there is no rockchip_defconfig ... maybe go with multi_v7_defconfig?
<topi`>
I wonder if I could re-use this vendor shipped U-boot...
<topi`>
it just needs to load zImage and pass on the DTB in r2, right?
<topi`>
Hit any key to stop autoboot: 0
<topi`>
it seems the timer has been set to count to 0 ... is there any way to break this boot_
<robmur01>
you can hack it, but it's barely worth the bother - the BSP U-Boot has virtually no useful commands built in
<robmur01>
you need to package everything up with the magic image headers and flash them to the special places defined by the horrible parameters.txt mechanism
<topi`>
so, I can't load a modern kernel with it?
<topi`>
OK, good to know.
<topi`>
I'll start building a 2020 u-boot
<topi`>
does u-boot somehow benefit from the .dtb file from kernel?
<robmur01>
you can, it's just a massive pain in the bum to get to the point of being able to do so :)
<topi`>
I had a SDcard that boots on the Radxa Rock2, and it almost booted on this rk3288 board as well. It just couldn't enable the VCC for sdcard or usb.
<topi`>
(which naturally is because the pm is from a rk808)
<robmur01>
for legacy Android flow, IIRC it expects rk-kernel.dtb in a "resource" image
<robmur01>
for mainline, just load the DTB you want from wherever
<topi`>
I'm not interested in android, so I'll just forget this
<topi`>
this board has SPI, the endgame would be to flash a proper U-boot on the spi.
<topi`>
btw, I just noticed I have 200 days uptime on my rk3399 "workstation"!
<topi`>
isn't dbus written in C? everything that's written in C, will be exploited at some stage.
<topi`>
we have modern tools, like Rust, so use them for god's sake
<mps>
no, C is not problem, coders attitude are problem
<topi`>
C is a glorified assembly language
<topi`>
I liked assembly coding when I was 16, because "it was cool". not so today.
<mps>
rust tries to be better c++ and nothing more
<topi`>
I don't think it relates to c++ - it goes straight past the object-oriented paradigm to offer something more modern
<mps>
imo, C is still best
<topi`>
but yeah, it's a difficult beast to tacke
<topi`>
you're entitled to your opinion. I'm not going to give up the progress computer science has had these last 10-20 years
<topi`>
argh, the old Scaleway ARM node is *still* compiling my kernel
<topi`>
it takes more than 2 hours probably
<topi`>
I have a spare rk3288 box lying there, maybe I should hook it with some SATA drive to make it an armv7 compile box.
<mps>
well, I hear every few years that some new lang will 'kill' C, and I'm listening this about three decades :)
<robmur01>
at least a new language kills C++ every few years, it's just a shame that said new language is still C++
kevery has quit [Ping timeout: 264 seconds]
kevery has joined #linux-rockchip
<DuClare>
I'd just cross-compile on a real computer, not some arm toy :P
kevery1 has joined #linux-rockchip
kevery has quit [Read error: Connection reset by peer]
kevery1 is now known as kevery
Net147 has joined #linux-rockchip
<robmur01>
DuClare: nah, cross-compiling sucks, just build ARMv7 stuff in a chroot on a fat arm64 box :P
* robmur01
waits patiently for an Altra, even though the eMAG is perfectly tolerable...
mias has joined #linux-rockchip
ela724 has joined #linux-rockchip
<ela724>
hi , i am trying to interface GREY sensor (Y8) with rk3399 . our sensor successfully streaming out GREY (which we verified with other platforms)
<ela724>
here i am facing issue "rkisp1: CIF_ISP_PIC_SIZE_ERROR (0x00000001)" , when i configure input and output formats of ISP with Y8 640x480
<ela724>
after so much of above error , i am getting ISP frame complete for single capture ! . which is also not proper data.
<ela724>
any advice would be helpfull
<ela724>
thanks in advance
drg has joined #linux-rockchip
JohnDoe_71Rus has joined #linux-rockchip
drg has quit [Remote host closed the connection]
ela724 has quit [Remote host closed the connection]
stikonas has quit [Remote host closed the connection]
stikonas has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 272 seconds]
kevery1 is now known as kevery
kaspter has quit [Quit: kaspter]
mias has quit [Quit: Konversation terminated!]
afaerber has quit [Ping timeout: 260 seconds]
kevery1 has joined #linux-rockchip
kevery has quit [Remote host closed the connection]