mrueg has quit [Remote host closed the connection]
mrueg has joined #linux-rockchip
ckeepax has quit [Ping timeout: 276 seconds]
ckeepax has joined #linux-rockchip
<mmind00>
topi`: rk3368 and rk3288 share most of their IP blocks [sometimes with minimal differences]
kapouer has quit [Quit: kapouer]
ckeepax has quit [Ping timeout: 256 seconds]
ckeepax has joined #linux-rockchip
kapouer has joined #linux-rockchip
kapouer has quit [Quit: kapouer]
<Darkarnium>
Hey all, I'm seeing some odd behaviour with an RK3188 based device. I'm trying to dump the flash before modifying anything (from factory), but reading the contents of the flash (rkflashtool r 0x0 0x1000000) is yielding an image that contains no data.
<Darkarnium>
Any ideas? :)
<Darkarnium>
I can't seem to find any documentation on the SoC / Package itself, so I'm guessing it's all under NDA (past a datasheet which has the ball layout and pin map, etc) :(
<sjoerd>
but the nand flash parts are indeed not publically available
<topi`>
mmind00: so, adding device/platform support for mainline is surely just a simple .dts job?
<topi`>
from 3288 -> 3368
<Darkarnium>
sjoerd: thanks, I'll have a look :)
<mmind00>
topi`: in essence yet ... we currently already have support for two rk3368 boards, so adding the geekbox is no real problem
<topi`>
mmind00: I guess the guys behind Geekbox have already done some work
<mmind00>
topi`: as always except graphics ... IP blocks are similar but some bits in the registers shifted, so need someone looking at that + iommu handling seems to have changed
<mmind00>
topi`: I don't really think so ... all these chineese/whatever makers just seem to take the vendor kernel
<mmind00>
topi`: and while Rockchip also does provide rk3368 patches now, the full-featured thing is currently still the vendor kernel
ckeepax has quit [Ping timeout: 265 seconds]
<Darkarnium>
This may be a silly question, and I appologize if that is the case, but in rkflashtool the 'RKFT_CMD_' defines are register locations from which the data is being read (via usb), or is based on an API rather than direct access to registers?
<Darkarnium>
Aka RKFT_CMD_READFLASHINFO at 0x8000061a
<Darkarnium>
There is some additional data in protocol.txt on the flashtool tree that makes me thing this is an API?