leowt changed the topic of #linux-rockchip to: Rockchip development discussion | http://linux-rockchip.info | http://irclog.whitequark.org/linux-rockchip
GeorgeJ has quit [Remote host closed the connection]
ssvb has quit [Ping timeout: 256 seconds]
arokux2 has quit [Ping timeout: 260 seconds]
ssvb has joined #linux-rockchip
ausjke has quit [Remote host closed the connection]
tonikasch has quit [Quit: Bye!]
Galland has quit [Quit: Saliendo]
akaizen has quit [Remote host closed the connection]
Astralix has joined #linux-rockchip
Astralix1 has quit [Ping timeout: 264 seconds]
akaizen has joined #linux-rockchip
akaizen has quit [Ping timeout: 245 seconds]
akaizen has joined #linux-rockchip
Theueip_ has quit [Quit: Leaving...]
Theueip has joined #linux-rockchip
hipboi has quit [Quit: Leaving]
tonikasch has joined #linux-rockchip
tonikasch has quit [Quit: Bye!]
ibrah is now known as eebrah
eebrah is now known as Guest25610
sarg has joined #linux-rockchip
<sarg> Astralix, hi, you wrote me about bootloader yesterday
tonikasch has joined #linux-rockchip
AstralixNB has joined #linux-rockchip
AstralixNB has quit [Client Quit]
hipboi has joined #linux-rockchip
mcbrick has quit [Remote host closed the connection]
GeorgeJ has joined #linux-rockchip
Guest25610 is now known as eebrah_
GeorgeJ has left #linux-rockchip ["http://quassel-irc.org - Chat comfortably. Anywhere."]
atiti has joined #linux-rockchip
eebrah_ is now known as eebrah
rellla has joined #linux-rockchip
Super-noob has quit [Ping timeout: 260 seconds]
libv has quit [Ping timeout: 263 seconds]
Super-noob has joined #linux-rockchip
PiyushVerma has quit [Read error: Operation timed out]
* tonikasch ciao!
tonikasch has quit [Quit: Bye!]
libv has joined #linux-rockchip
mmind00 has joined #linux-rockchip
AstralixNB has joined #linux-rockchip
sarg has left #linux-rockchip ["Leaving"]
sarg has joined #linux-rockchip
AstralixNB has left #linux-rockchip [#linux-rockchip]
AstralixNB has joined #linux-rockchip
<AstralixNB> hi all
<AstralixNB> hi sarg
<sarg> hi AstralixNB, you wished to talk about rk bootloader yesterday
<AstralixNB> as you wrote me, I already did usb traces using commercial and free tools
<sarg> what device do you own? Mine is rk3066 tablet Yandao N101
<AstralixNB> I prefer the wireshark way now as the pcap logs could be shared if needed without people needing to buy commercial tools
<AstralixNB> I have several devices from old 2918 up to 3188
<sarg> nice
<AstralixNB> I already saw some differences in the protocol.
<sarg> so, they all have the same bootloader?
<AstralixNB> ah... no I don't thnik so
<AstralixNB> I think the loaders for 2928, 30xx and 31xx are mostly the same
<AstralixNB> Inside the latest 30xx loader some strings mention 2928 chips.
<AstralixNB> But the 2918 behaves somewhat different
<AstralixNB> So short summary of what I found out:
<AstralixNB> 1) The 2918 requests some data at the beginning that is requested byte by byte issuing the 0600 command multiple times.
<AstralixNB> 2) The 30xx/31xx systems get a NAK 06 at the command 06 00
<sarg> 0600 is a "ping" command
<AstralixNB> yes and no
<sarg> just tests that device is powered on and working
<AstralixNB> on 3xxx this is true and the device answers 06 00
<AstralixNB> but in 2918 the device responds 00 00 01
<AstralixNB> giving the command again it responds 01 [data] 01
<AstralixNB> and again 02 [other byte] 01
<AstralixNB> up to 07 [byte] 01
<sarg> AstralixNB, am I right, you willing to write universal rkflashtools for rockchip devices?
<AstralixNB> and last 00 06 00
<AstralixNB> why not
<sarg> have you sorted out IDB structure?
<AstralixNB> the only really big difference I saw is, that 2918 only accepts 16k bulks of data
<sarg> sorry, I am not aware of 2918, as I only have 3066 device
<AstralixNB> while 3xxx devices get 1MB per transfer
<AstralixNB> So I need to figure out, which device is on the other end and how much data can be sent in a single transfer call
<AstralixNB> But..
<sarg> there is command 0x061B
<AstralixNB> IDB is still a big mistery for me
<AstralixNB> let me check my traces...
<sarg> IDB is a reserved area on NAND, which could be named as MBR in PC terminology
<AstralixNB> yes
<sarg> it is crypted, and consists of few blocks
<sarg> one of them is NAND bad block table
<AstralixNB> AFAIK NAND requires some special handling
<AstralixNB> yes
<sarg> so, if you want to make proper flash, you need to disassemble NAND flash translation layer
<AstralixNB> I am familiar with the NAND technology and saw that the first IDB actions was to save the exosting bad block table
<AstralixNB> I am not sure about encryption
<sarg> you know about MaskRom flash mode?
<AstralixNB> I think they read out bad block table, recalculate a new layout around the bad blocks and preload the FTL with ECC values
<AstralixNB> I know about the mask rom loader
<sarg> MaskRom uses completely different protocol to flash device
<AstralixNB> yes but it is the only way to load something if you bricked the NAND bootloader
<AstralixNB> but only the batchtool supports using it, the rkandroidtool does not really work with it
<sarg> so, 0x061B command, have you found it?
<AstralixNB> yes
<sarg> 0x061A - flash info command
<AstralixNB> 55 53 42 43 E5 59 7A 95 00 00 00 00 80 00 06 1B 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
<AstralixNB> [IN 16 byte ID of device: B01321020311001V]
<AstralixNB> 55 53 42 53 E5 59 7A 95 00 00 00 00 00
<AstralixNB> 55 53 42 43 DB 2C BF D2 00 00 00 00 80 00 06 1A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
<AstralixNB> 55 53 42 53 DB 2C BF D2 00 00 00 00 00
<AstralixNB> [IN 512 bytes of data containing probably NAND related information]
<AstralixNB> There is another block of data with command 06 03
<AstralixNB> 55 53 42 43 03 4D 83 B5 00 00 00 00 80 00 0A 03 00 00 00 00 00 00 02 00 00 00 00 00 00 00 00
<AstralixNB> [IN 64 bytes of all 0x00]
<AstralixNB> 55 53 42 53 03 4D 83 B5 00 00 00 00 00
neodallas has joined #linux-rockchip
<sarg> 0x61b is called at very beginning of device flashing process
<AstralixNB> yes
<sarg> I think, rkandroidtool.exe determines chip version using this command
<AstralixNB> the only obvious info in it is the CPU code B013
<AstralixNB> in the 06 1a command must be the information of how large a block may be for transfer, sort of NAND layout information.
<AstralixNB> I know from eMMC that you can call some virtual sectors from the device to tell you all about it.
<AstralixNB> But reading the specs from some of the memory chips of my devices, there is only the usual vendor/device id request command
<AstralixNB> the one you know from old FLASH memories.
atiti has quit [Ping timeout: 276 seconds]
PiyushVerma has joined #linux-rockchip
<AstralixNB> but in the 4th identifyer byte there is the magic: Page size, Block size, Redundant area size
<AstralixNB> ah, btw. The final goal would be to replace the whole rk-magic FTL thing with some well working open source
<sarg> there are opensourced FTLs ?
<sarg> a have found one, but it is a academic research, nothing production-ready
<AstralixNB> there are I guess...
<sarg> pastebin file is a dump of successfull flashing of rk3066
<AstralixNB> f2fs
<AstralixNB> yes already reading it
<sarg> here is packet structure:
<AstralixNB> yes, I know that
<AstralixNB> but for the IDB data, I guess the unknown things is the used ECC algo. If you have that, the rest of the data will be FTL.
<sarg> ECC is known
<AstralixNB> it is?
<sarg> yes, i am searching for it
<sarg> * searching in my logs
<AstralixNB> lol
<AstralixNB> Need to set up a knowledge database
<AstralixNB> btw, I had made some traces too
<sarg> AstralixNB, do you know wodz from rockbox.org ?
<AstralixNB> nope
<sarg> he knows a lot about rk27 devices
<AstralixNB> rk27?
<sarg> yes, mp3 players chip
<AstralixNB> Ah, these are still mentioned in the bootloader sources
<AstralixNB> rk27 is listed as unusable ports of rockbox...
atiti has joined #linux-rockchip
<AstralixNB> how did you export this log?
<sarg> perl scripts
<AstralixNB> ah, ok
<sarg> i exported dump in xml format
<sarg> then using perl scripts obtained all i needed
<sarg> RKFCMD_DRAM_WRITE, RKFCDM_DRAM_GO
<AstralixNB> perl is not my thing... I am more the low level guy.... assembler, C up to ANSI C 99
<sarg> you hope to find those commands?
<AstralixNB> I hope to as I would like to put a kernel right into ram and run it
<AstralixNB> without having to flash it
<sarg> I had that idea too )
<AstralixNB> still trying to find the command table in the bootloader
<sarg> I am trying to open my old diassemblies with IDA
<sarg> but it keep telling me "Use newer version"
<AstralixNB> hmmm... my VM lost the shared folder
Dan68 has quit [Remote host closed the connection]
tonikasch has joined #linux-rockchip
atiti has quit [Remote host closed the connection]
atiti has joined #linux-rockchip
atiti has quit [Read error: Operation timed out]
atiti has joined #linux-rockchip
tinti_ has joined #linux-rockchip
tinti_ has joined #linux-rockchip
tinti_ has quit [Changing host]
tonikasch has quit [Quit: Bye!]
tonikasch has joined #linux-rockchip
naobsd has joined #linux-rockchip
<naobsd> astralix: I told you some days ago, there is more info about result of 061b in arch/arm/plat-rk/include/plat/cpu.h
<naobsd> res of 061a is 512B, 0x36th value is related to number of blocks
<naobsd> (res[0x2d] << 8) * (res[0x36] << 8) * 512byte = NAND capacity (it's my guess, but it's correct for my RK2918/2928/3066/3188)
<naobsd> res[0x2d] may be 0x05 or 0x06 or 0x26, I'm not sure, but probably it's block size
<naobsd> ah, cpu.h is in RK's 3.0.36 kernel source
rellla has quit [Quit: Nettalk6 - www.ntalk.de]
<naobsd> hipboi: ping
atiti has quit [Ping timeout: 276 seconds]
Theueip has quit [Quit: Leaving...]
AstralixNB has quit [Ping timeout: 264 seconds]
mmind00 has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
atiti has joined #linux-rockchip
ausxxh has joined #linux-rockchip
arokux2 has joined #linux-rockchip
neodallas has quit []
eebrah is now known as eebrah|doze
tonikasch has quit [Read error: Connection reset by peer]
tonikasch has joined #linux-rockchip
jpsminix has quit [Remote host closed the connection]
<tonikasch> Astralix http://free-electrons.com/doc/training/embedded-linux/slides.pdf <-- page 258 and so on, might be of help for that of replacing the nand filesystems you talked about some days ago?
<Astralix> Ok, MTD is something very common. But yes it is the upper part of a system where a filesystem hooks up onto.
<Astralix> But below MTD there is a special driver for NAND flash missing in that sheets
<tonikasch> don't know actually, I'm just seeking information to prepare myself for kernel hacking
<Astralix> I am not sure if writing an FTL is the right point to start...
<tonikasch> what does FTL stand for?
<Astralix> Just to give some hints, MTD is kind of a virtual device layer that abstracts the different technologies of electronical memories
<tonikasch> aha
<Astralix> So NAND flash has very limited number of writes available
<Astralix> and second, cells may be altered by read or write that are not part of the date read or written
<Astralix> So what kills data is each of these cases
<Astralix> but what renders NAND cells unusable is only the erase
<Astralix> To limit the number of erases, a software needs to memorize which blocks had already been erased lots of times, and which not
<Astralix> so wear-leveling means, if you write data, write it at the leased erased block that you can find
<Astralix> least
<Astralix> (the one with the minimal erase cycles)
<tonikasch> yes, I understand that
<Astralix> Additionally NAND is organized in different block sizes
<Astralix> but our filesystems calculate in 512bytes
<Astralix> so the software has to track, where a 512byes sector resides together with other 512 bytes sectors in one block
<Astralix> And on top of that there is the fact, that the erase pages are built of multiple blocks
<tonikasch> aha
<Astralix> so the FTL (Flash Translation Layer) software has to keep log about each and every 512bytes sector that is spread somewhere on that NAND.
<Astralix> The address a driver gives to the MTD has nothing to do with the real address of the sector inside the NAND.
<Astralix> And for the bit scrambling cause by near area access of bit cells, a good ECC system must be used that is able to correct multiple bit errors per sector
<Astralix> so here is the big thing in NAND tech:
<Astralix> 1) you may not write to often, as erasing kills your memory
<Astralix> 2) You must read-correct-write memory some times as it gets weak over time.
<tonikasch> aha
mcbrick has joined #linux-rockchip
<Astralix> You can read all that from someone who must know it:
<Astralix> https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CDEQFjAA&url=https%3A%2F%2Fwww.micron.com%2F~%2Fmedia%2FDocuments%2FProducts%2FPresentation%2Fflash_mem_summit_jcooke_inconvenient_truths_nand.pdf&ei=9Pc5UuKhL9TwhQet7YHQDg&usg=AFQjCNF6rPPTTNX_ECTZk7wKQDl6eGEgNw&sig2=3iherTtvjoxgCqtjOvGR6w&bvm=bv.52288139,d.ZG4&cad=rja
<Astralix> grrr.... google...
<tonikasch> yeah, I can get the address ;)
<tonikasch> I have to leave now for dinner, I'm going to read it afterwards
<tonikasch> Thanks!
<Astralix> welcomed
<tonikasch> Astralix Perhaps you said that rk30xxnand.ko did strange things? I assume so that you did a objdump of it?
<Astralix> yes I did that
<Astralix> but reverse engineering the mechanisms that rockchips marked as their private property...
<Astralix> I'd prefer do replace this code with something open source and well documented
Astralix has quit [Remote host closed the connection]
Astralix has joined #linux-rockchip
<Astralix> Sorry, my IRC client crashed
<tonikasch> now I'm reading this: http://www.linux-mtd.infradead.org/doc/ubi.html
<tonikasch> np
<tonikasch> do you know if rockchip devices have an internal bootloader on rom loaded before the actual modified u-boot?
<Astralix> ah... did you read the TRM of RK3066?
<Astralix> there is written how the mask rom loader works
<Astralix> and ubi is probably not what you want
<Astralix> for NAND you should look at f2fs
<tonikasch> f2fs? In fact you were looking for someone with experience on it, wasn't it?
<Astralix> we need to team up a bit
<Astralix> doing this all alopne doesn't make sense
<tonikasch> yes, I know
_shb_ has joined #linux-rockchip
arokux2 has quit [Remote host closed the connection]
arokux2 has joined #linux-rockchip
tonikasch has quit [Quit: Bye!]
_shb_ has quit [Quit: Yaaic - Yet another Android IRC client - http://www.yaaic.org]
tonikasch has joined #linux-rockchip
tonikasch has quit [Client Quit]
Astralix has left #linux-rockchip [#linux-rockchip]
soletti has left #linux-rockchip [#linux-rockchip]
arokux2 has quit [Read error: Connection reset by peer]
arokux2 has joined #linux-rockchip
arokux2 has quit [Remote host closed the connection]
naobsd has quit [Quit: Page closed]
arokux2 has joined #linux-rockchip
tinti_ has quit [Read error: Connection reset by peer]
Galland has joined #linux-rockchip
<Galland> hi