cnxsoft has quit [Remote host closed the connection]
hipboi has joined #linux-rockchip
hipboi has quit [Client Quit]
levd1 has joined #linux-rockchip
cnxsoft has joined #linux-rockchip
levd has quit [Ping timeout: 265 seconds]
levd1 is now known as levd
kapouer has quit [Quit: kapouer]
<naobsd>
Darkarnium: rkflashtool is not for "recovery", it's for "loader mode" and "mask rom mode"
levd1 has joined #linux-rockchip
<naobsd>
there is small "glue" code for NAND in RK kernel source tree
levd has quit [Ping timeout: 245 seconds]
levd1 is now known as levd
<naobsd>
some people misunderstood some secret was released, but no, it's just glue code.
<naobsd>
erase command is not implemented in rkflashtool. "rkflashtool e" doesn't do "erase" operation, it just does "write" 0xff
<naobsd>
personally I want to remove "e" from rkflashtool
cnxsoft has quit [Read error: Connection reset by peer]
levd1 has joined #linux-rockchip
cnxsoft has joined #linux-rockchip
levd has quit [Ping timeout: 255 seconds]
levd1 is now known as levd
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 256 seconds]
levd1 is now known as levd
cnxsoft has quit [Quit: cnxsoft]
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 240 seconds]
levd1 is now known as levd
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 272 seconds]
levd1 is now known as levd
cnxsoft has joined #linux-rockchip
levd1 has joined #linux-rockchip
Ueno_Otoko has quit [Ping timeout: 245 seconds]
levd has quit [Ping timeout: 260 seconds]
levd1 is now known as levd
Ueno_Otoko has joined #linux-rockchip
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 276 seconds]
levd1 is now known as levd
Luke-Jr has quit [Excess Flood]
Luke-Jr has joined #linux-rockchip
Luke-Jr has quit [Excess Flood]
Luke-Jr has joined #linux-rockchip
<Darkarnium>
naobsd: that's fair, sorry, I wasn't clear. I'm just trying to dump (read / r) the entire NAND to my machine for backup. On this device, not even the parameters file can be read. I'm referring to it as 'recovery' in this context as that's what I'm trying to use it for, nomenclature not withstanding :)
<naobsd>
Darkarnium: are you sure device is in loader mode?
<Darkarnium>
I can read the Flash ID (RKFT_CMD_READFLASHID), Flash Info (RKFT_CMD_READFLASHINFO) and RKFT_CMD_READCHIPINFO without issue. I can also issue a reboot to the device using RKFT_CMD_RESETDEVICE
<Darkarnium>
RKFT_CMD_READLBA also reads data back from the device, however, if I dump the entire address space of the NAND device it appears to be blank (not zeroed, but what appears to tbe the same string of bytes over and over).
<Darkarnium>
So from what I can tell, it appears to be :)
<naobsd>
can you explain with more accurate word? all I could understand is you did something and you got something without issue, and you got something with issue.
<Darkarnium>
I get output, but it appears to be the same string of bytes over and over
<naobsd>
it's very accurate/complete explanation, thank you. then,
<naobsd>
(1st) parameter information is missing/broken
<naobsd>
which device are you using?
<Darkarnium>
A non descript tablet (no marked supplier / vendor).
<naobsd>
you don't have serial console, right?
<Darkarnium>
Unfortunately not :(
<naobsd>
is it bootable?
<Darkarnium>
Yes, outside of loader mode it loads an OS without issue
<naobsd>
how about "rkflashtool r 0 0x2000 | hexdump -C |grep PARM"?
<Darkarnium>
Running at the moment :)
<Darkarnium>
rkflashtool: info: reading flash memory at offset 0x00001fe0... Done!
<Darkarnium>
Nothing output :(
<naobsd>
all parameter info include backups are missing... if it's true, it shouldn't be bootable. reading function in loader and/or rkflashtool is not working properly :(
<Darkarnium>
It's very strange. I have a feeling the vendor are doing something sneaky. I'll keep looking though! :)
<Darkarnium>
Thanks for your assistance
<naobsd>
many operations in rkflashtool doesn't check error, it's difficult to know which operation is not working
<naobsd>
can you get kernel command line from running Android on your device?
kapouer has joined #linux-rockchip
<naobsd>
btw, if you're using Windows or Linux, you can use official tool instead of rkflashtool
<naobsd>
I guess it will work
<naobsd>
rkflashtool need to be refined...
<Darkarnium>
Is that the bulk load tool you are referring to (the official one)?
<naobsd>
AndroidTool.exe and upgrade_tool should able to do same as "rkflashtool r"
<naobsd>
(I cannot remember how for now)
levd has quit [Ping timeout: 265 seconds]
Ueno_Otoko has quit [Ping timeout: 260 seconds]
<sjoerd>
mmind00: oh interesting issue with the orphand clock patch sclk_edp_24m stays orphaned as its (default) parent is an external clock
<mmind00>
sjoerd: on the one hand, doing that in every board-file is cumbersome, on the other hand, doing that for the whole rk3288 will affect boards that actually provide the external clock (if there are any)
<sjoerd>
heh, ext_edp_24m can be 27m ?
<sjoerd>
I did wonder why it had both and internal 24m clock and an external one
<mmind00>
sjoerd: seems like it ... it can supplied by some external clock for that ... but I'm actually not sure if anybody does that
<sjoerd>
Well nothing in mainline at least
<sjoerd>
based on grepping the dts for something that provides that clock
<mmind00>
setting a soc-wide default for a leaf-clock still feels strange :-)
<mmind00>
but I guess that would be the best option until some board actually providing the external one comes along
<sjoerd>
Is that assignement mandatory or just a default?
<mmind00>
it's a default ... i.e. the edp-phy _could_ override it
<sjoerd>
doesn't seem to bad to mux it like that by default and rely on the higher layers to switch it to an extenra clock if they need that rate
Ueno_Otoko has joined #linux-rockchip
Ueno_Otoko has quit [Ping timeout: 246 seconds]
Apocx_ has joined #linux-rockchip
ssvb has quit [Ping timeout: 260 seconds]
azend|vps has quit [Remote host closed the connection]
vickycq has quit [Ping timeout: 240 seconds]
Apocx has quit [Ping timeout: 250 seconds]
ssvb has joined #linux-rockchip
vickycq has joined #linux-rockchip
azend|vps has joined #linux-rockchip
Astralix has joined #linux-rockchip
Ueno_Otoko has joined #linux-rockchip
Ueno_Otoko has quit [Ping timeout: 256 seconds]
<sjoerd>
mmind00: I guess the fundamental issue is that we can't currently model an unconnected clock line
<mmind00>
sjoerd: I don't think it is supposed to get "modelled" .. the clock framework handles orphans gracefully (when they appear later or so, because i2c device or something) ... so I guess we really should go the way to just always reparent that and see if someone shouts ;-)
<sjoerd>
oh yeah that's the quick fix and valid for now
<sjoerd>
The only case that would be an issue would be if an external provide is hooked up, is used by the bootloader and you don't want screen glitches when booting linux (e.g. don't change modes or clock)
<sjoerd>
mmind00: There is a important difference between an orphan, because the driver isn't there yet or an "orphan" becuse there isn't really anything on that line
<sjoerd>
deferring makes no sense in the latter case as, well, you'll defer forever :)
<mmind00>
sjoerd: yeah being able to clk_get + clk_set_parent those unconnected clocks might be nice to have, but I don't think you could sanely model that in ccf + devicetree
_whitelogger has joined #linux-rockchip
_whitelogger has quit [Ping timeout: 240 seconds]
_whitelogger_ has joined #linux-rockchip
cnxsoft has quit [Quit: cnxsoft]
cnxsoft has joined #linux-rockchip
premoboss has joined #linux-rockchip
afaerber has quit [Quit: Ex-Chat]
Apocx_ is now known as Apocx
premoboss has quit [Ping timeout: 240 seconds]
premoboss has joined #linux-rockchip
afaerber has joined #linux-rockchip
afaerber has quit [Quit: Ex-Chat]
afaerber has joined #linux-rockchip
cnxsoft has quit [Remote host closed the connection]
Ueno_Otoko has joined #linux-rockchip
enkoder has quit [Ping timeout: 240 seconds]
kodie has quit [Ping timeout: 264 seconds]
JohnDoe_71Rus has joined #linux-rockchip
<topi`>
shit. My RK3288 based Rock2 tries to boot from /dev/sda but I have a blank image on the HDD so no go... does anyone remember where I need to binary edit to change the bootstring?
<topi`>
IIRC the boot params live somewhere on the emmc but where...
<topi`>
hmm. There seems to be ANDROID! kernel image in /boot/boot.img
<topi`>
I thought Rockchip has a custom img format?
<sjoerd>
if you use the rockchip bootlaoder then yes
<topi`>
how do I find out if this board uses the rockchip bootloader?
<topi`>
hmm, radxa2 bringup document talks about compiling u-boot
<topi`>
so I guess this must be using uboot
<topi`>
no video when rebooting the board :( only after the kernel is running I get video
<sjoerd>
If you didn't put the upstream u-boot on it yourself you're using the rockchip one
<topi`>
ok
<topi`>
btw do you have any info about the RK3288 based chromebooks? there are plenty. Can they directly boot linux nowadays? I mean some decently recent kernel, 3.14 and up
JohnDoe5 has joined #linux-rockchip
<via>
topi`: i'm booting 4.4 on an asus c201
<topi`>
sounds cool
<topi`>
the c201 has a very lucrative price point :)
<topi`>
do you have the 4GB model?
<via>
2GB
JohnDoe_71Rus has quit [Ping timeout: 260 seconds]
<via>
the arm thumb shows its use -- with X and firefox and a normal set of things running i'm not using >50% of my memory
<topi`>
yeah, ARM machine codes take up significantly less space than x86_64
<topi`>
so a chromebook with Atom at 2 GB is slightly too little ram - whereas I have an old Samsung Exynos chromebook with 2 GB, and it's plenty
<via>
yeah, thats about my experience
<topi`>
I wish the RK3288 chromebooks would eventually lead to better u-boot/linux support
<topi`>
for other rk3288 boards as well
<via>
supposedly libreboot works on that chromebook
<via>
i was going to load it eventaully
<topi`>
I found a copy of the kernel params string at emmc offset 0x400000
<topi`>
let's see if it refuses to boot if I just poke new characters to that string with bvi (binary-vi)
<mmind00>
topi`: all the recent improvements on mainline Linux support for the rk3288 are due to the Chromebooks
<mmind00>
topi`: aka without Chromebooks we wouldn't have a DRM/KMS, hdmi driver at all
Ueno_Otoko has quit [Ping timeout: 240 seconds]
Ueno_Otoko has joined #linux-rockchip
<topi`>
no hdmi? ouch
<topi`>
well, this makes the rk3288 clearly a much better deal than the competing Allwinner chips
<topi`>
the rk3288 should be price competitive with AW's chips as well
<topi`>
this is not as a disrespect at the linux-sunxi folks
<topi`>
just thinking about the future :)
enkoder has joined #linux-rockchip
premoboss has quit [Quit: Sto andando via]
Ueno_Otoko has quit [Ping timeout: 245 seconds]
matthias_bgg has joined #linux-rockchip
<matthias_bgg>
naobsd, hi. afaerber told me you wanted to talk to me about my tronsmart rockchip effort :)
dlezcano has quit [Remote host closed the connection]
<matthias_bgg>
yes, I started to create a dts for the device
<naobsd>
matthias_bgg: is there any progress?
<matthias_bgg>
I need to send it upstream.
<naobsd>
sounds good
<matthias_bgg>
Actually I got stuck on the sd-card slot, as it shares the pin with the serial console. I tried to get the serial console on uart4 but had no luck
<naobsd>
I'm using uart4 as console
<matthias_bgg>
really?
<matthias_bgg>
did you do any special hacks in the dts?
<matthias_bgg>
apart from adding uart4?
<naobsd>
probably I just modified chosen { stdout-path = ... }
<matthias_bgg>
alright, well that looks like as if I have a HW problem
<matthias_bgg>
I don't have my board at hand, but maybe we can check some revision number (if present...)
<naobsd>
I also modified u-boot to see u-boot output with uart4
<matthias_bgg>
naobsd, alright. did you put this in any oficial repository?
<matthias_bgg>
I didn't dare to reflash the uboot, because I feared to brick my device
<naobsd>
bricking is almost impossible
Astralix has quit [Remote host closed the connection]
<naobsd>
but I put everything include u-boot on SD
<naobsd>
and wiped eMMC
<matthias_bgg>
naobsd, sound interesting
<matthias_bgg>
I have to go now. Let's keep talking about that.
<matthias_bgg>
see you
<naobsd>
see you later
<afaerber>
naobsd: is the SD card layout the same as on rk3288?
<naobsd>
afaerber: yes
<afaerber>
unfortunately the GeekBox has the same UART2/SD issue; Landingship hopefully has the other pins
<vlcn>
I've tried a few different versions of afptool now with the same results -- I can't seem to find any information on what the parameter file is supposed to contain.