00:34
GeorgeJ has quit [Remote host closed the connection]
00:47
ssvb has quit [Ping timeout: 256 seconds]
00:47
arokux2 has quit [Ping timeout: 260 seconds]
00:48
ssvb has joined #linux-rockchip
01:20
ausjke has quit [Remote host closed the connection]
01:35
tonikasch has quit [Quit: Bye!]
02:29
Galland has quit [Quit: Saliendo]
02:33
akaizen has quit [Remote host closed the connection]
04:20
Astralix has joined #linux-rockchip
04:23
Astralix1 has quit [Ping timeout: 264 seconds]
04:24
akaizen has joined #linux-rockchip
04:28
akaizen has quit [Ping timeout: 245 seconds]
04:30
akaizen has joined #linux-rockchip
04:57
Theueip_ has quit [Quit: Leaving...]
05:25
Theueip has joined #linux-rockchip
06:01
hipboi has quit [Quit: Leaving]
06:15
tonikasch has joined #linux-rockchip
06:24
tonikasch has quit [Quit: Bye!]
06:24
ibrah is now known as eebrah
06:24
eebrah is now known as Guest25610
06:27
sarg has joined #linux-rockchip
06:28
<
sarg >
Astralix, hi, you wrote me about bootloader yesterday
06:32
tonikasch has joined #linux-rockchip
06:50
AstralixNB has joined #linux-rockchip
06:50
AstralixNB has quit [Client Quit]
07:00
hipboi has joined #linux-rockchip
07:05
mcbrick has quit [Remote host closed the connection]
07:06
GeorgeJ has joined #linux-rockchip
07:08
Guest25610 is now known as eebrah_
07:26
atiti has joined #linux-rockchip
07:31
eebrah_ is now known as eebrah
07:38
rellla has joined #linux-rockchip
07:59
Super-noob has quit [Ping timeout: 260 seconds]
08:00
libv has quit [Ping timeout: 263 seconds]
08:04
Super-noob has joined #linux-rockchip
08:38
PiyushVerma has quit [Read error: Operation timed out]
08:41
tonikasch has quit [Quit: Bye!]
08:46
libv has joined #linux-rockchip
08:54
mmind00 has joined #linux-rockchip
08:55
AstralixNB has joined #linux-rockchip
08:57
sarg has left #linux-rockchip ["Leaving"]
08:57
sarg has joined #linux-rockchip
08:57
AstralixNB has left #linux-rockchip [#linux-rockchip]
08:57
AstralixNB has joined #linux-rockchip
09:01
<
AstralixNB >
hi all
09:02
<
AstralixNB >
hi sarg
09:03
<
sarg >
hi AstralixNB, you wished to talk about rk bootloader yesterday
09:03
<
AstralixNB >
as you wrote me, I already did usb traces using commercial and free tools
09:03
<
sarg >
what device do you own? Mine is rk3066 tablet Yandao N101
09:04
<
AstralixNB >
I prefer the wireshark way now as the pcap logs could be shared if needed without people needing to buy commercial tools
09:04
<
AstralixNB >
I have several devices from old 2918 up to 3188
09:05
<
AstralixNB >
I already saw some differences in the protocol.
09:05
<
sarg >
so, they all have the same bootloader?
09:05
<
AstralixNB >
ah... no I don't thnik so
09:06
<
AstralixNB >
I think the loaders for 2928, 30xx and 31xx are mostly the same
09:06
<
AstralixNB >
Inside the latest 30xx loader some strings mention 2928 chips.
09:07
<
AstralixNB >
But the 2918 behaves somewhat different
09:07
<
AstralixNB >
So short summary of what I found out:
09:07
<
AstralixNB >
1) The 2918 requests some data at the beginning that is requested byte by byte issuing the 0600 command multiple times.
09:08
<
AstralixNB >
2) The 30xx/31xx systems get a NAK 06 at the command 06 00
09:09
<
sarg >
0600 is a "ping" command
09:09
<
AstralixNB >
yes and no
09:09
<
sarg >
just tests that device is powered on and working
09:09
<
AstralixNB >
on 3xxx this is true and the device answers 06 00
09:10
<
AstralixNB >
but in 2918 the device responds 00 00 01
09:10
<
AstralixNB >
giving the command again it responds 01 [data] 01
09:10
<
AstralixNB >
and again 02 [other byte] 01
09:10
<
AstralixNB >
up to 07 [byte] 01
09:10
<
sarg >
AstralixNB, am I right, you willing to write universal rkflashtools for rockchip devices?
09:10
<
AstralixNB >
and last 00 06 00
09:11
<
AstralixNB >
why not
09:11
<
sarg >
have you sorted out IDB structure?
09:11
<
AstralixNB >
the only really big difference I saw is, that 2918 only accepts 16k bulks of data
09:11
<
sarg >
sorry, I am not aware of 2918, as I only have 3066 device
09:12
<
AstralixNB >
while 3xxx devices get 1MB per transfer
09:12
<
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
09:12
<
sarg >
there is command 0x061B
09:12
<
AstralixNB >
IDB is still a big mistery for me
09:12
<
AstralixNB >
let me check my traces...
09:13
<
sarg >
IDB is a reserved area on NAND, which could be named as MBR in PC terminology
09:13
<
sarg >
it is crypted, and consists of few blocks
09:14
<
sarg >
one of them is NAND bad block table
09:14
<
AstralixNB >
AFAIK NAND requires some special handling
09:14
<
sarg >
so, if you want to make proper flash, you need to disassemble NAND flash translation layer
09:14
<
AstralixNB >
I am familiar with the NAND technology and saw that the first IDB actions was to save the exosting bad block table
09:15
<
AstralixNB >
I am not sure about encryption
09:16
<
sarg >
you know about MaskRom flash mode?
09:16
<
AstralixNB >
I think they read out bad block table, recalculate a new layout around the bad blocks and preload the FTL with ECC values
09:16
<
AstralixNB >
I know about the mask rom loader
09:16
<
sarg >
MaskRom uses completely different protocol to flash device
09:17
<
AstralixNB >
yes but it is the only way to load something if you bricked the NAND bootloader
09:17
<
AstralixNB >
but only the batchtool supports using it, the rkandroidtool does not really work with it
09:18
<
sarg >
so, 0x061B command, have you found it?
09:19
<
sarg >
0x061A - flash info command
09:19
<
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
09:19
<
AstralixNB >
[IN 16 byte ID of device: B01321020311001V]
09:19
<
AstralixNB >
55 53 42 53 E5 59 7A 95 00 00 00 00 00
09:20
<
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
09:20
<
AstralixNB >
55 53 42 53 DB 2C BF D2 00 00 00 00 00
09:20
<
AstralixNB >
[IN 512 bytes of data containing probably NAND related information]
09:20
<
AstralixNB >
There is another block of data with command 06 03
09:20
<
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
09:20
<
AstralixNB >
[IN 64 bytes of all 0x00]
09:20
<
AstralixNB >
55 53 42 53 03 4D 83 B5 00 00 00 00 00
09:21
neodallas has joined #linux-rockchip
09:22
<
sarg >
0x61b is called at very beginning of device flashing process
09:22
<
sarg >
I think, rkandroidtool.exe determines chip version using this command
09:22
<
AstralixNB >
the only obvious info in it is the CPU code B013
09:25
<
AstralixNB >
in the 06 1a command must be the information of how large a block may be for transfer, sort of NAND layout information.
09:25
<
AstralixNB >
I know from eMMC that you can call some virtual sectors from the device to tell you all about it.
09:26
<
AstralixNB >
But reading the specs from some of the memory chips of my devices, there is only the usual vendor/device id request command
09:26
<
AstralixNB >
the one you know from old FLASH memories.
09:26
atiti has quit [Ping timeout: 276 seconds]
09:27
PiyushVerma has joined #linux-rockchip
09:28
<
AstralixNB >
but in the 4th identifyer byte there is the magic: Page size, Block size, Redundant area size
09:30
<
AstralixNB >
ah, btw. The final goal would be to replace the whole rk-magic FTL thing with some well working open source
09:30
<
sarg >
there are opensourced FTLs ?
09:30
<
sarg >
a have found one, but it is a academic research, nothing production-ready
09:30
<
AstralixNB >
there are I guess...
09:31
<
sarg >
pastebin file is a dump of successfull flashing of rk3066
09:31
<
AstralixNB >
yes already reading it
09:32
<
sarg >
here is packet structure:
09:33
<
AstralixNB >
yes, I know that
09:35
<
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.
09:35
<
sarg >
ECC is known
09:35
<
AstralixNB >
it is?
09:36
<
sarg >
yes, i am searching for it
09:36
<
sarg >
* searching in my logs
09:36
<
AstralixNB >
Need to set up a knowledge database
09:37
<
AstralixNB >
btw, I had made some traces too
09:38
<
sarg >
AstralixNB, do you know wodz from rockbox.org ?
09:38
<
sarg >
he knows a lot about rk27 devices
09:39
<
sarg >
yes, mp3 players chip
09:39
<
AstralixNB >
Ah, these are still mentioned in the bootloader sources
09:40
<
AstralixNB >
rk27 is listed as unusable ports of rockbox...
09:41
atiti has joined #linux-rockchip
09:44
<
AstralixNB >
how did you export this log?
09:44
<
sarg >
perl scripts
09:44
<
AstralixNB >
ah, ok
09:45
<
sarg >
i exported dump in xml format
09:45
<
sarg >
then using perl scripts obtained all i needed
09:46
<
sarg >
RKFCMD_DRAM_WRITE, RKFCDM_DRAM_GO
09:46
<
AstralixNB >
perl is not my thing... I am more the low level guy.... assembler, C up to ANSI C 99
09:46
<
sarg >
you hope to find those commands?
09:46
<
AstralixNB >
I hope to as I would like to put a kernel right into ram and run it
09:47
<
AstralixNB >
without having to flash it
09:47
<
sarg >
I had that idea too )
09:47
<
AstralixNB >
still trying to find the command table in the bootloader
09:47
<
sarg >
I am trying to open my old diassemblies with IDA
09:48
<
sarg >
but it keep telling me "Use newer version"
09:50
<
AstralixNB >
hmmm... my VM lost the shared folder
10:05
Dan68 has quit [Remote host closed the connection]
10:49
tonikasch has joined #linux-rockchip
11:07
atiti has quit [Remote host closed the connection]
11:08
atiti has joined #linux-rockchip
11:50
atiti has quit [Read error: Operation timed out]
12:09
atiti has joined #linux-rockchip
12:40
tinti_ has joined #linux-rockchip
12:40
tinti_ has joined #linux-rockchip
12:40
tinti_ has quit [Changing host]
13:26
tonikasch has quit [Quit: Bye!]
14:48
tonikasch has joined #linux-rockchip
14:53
naobsd has joined #linux-rockchip
15:04
<
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
15:10
<
naobsd >
res of 061a is 512B, 0x36th value is related to number of blocks
15:12
<
naobsd >
(res[0x2d] << 8) * (res[0x36] << 8) * 512byte = NAND capacity (it's my guess, but it's correct for my RK2918/2928/3066/3188)
15:13
<
naobsd >
res[0x2d] may be 0x05 or 0x06 or 0x26, I'm not sure, but probably it's block size
15:24
<
naobsd >
ah, cpu.h is in RK's 3.0.36 kernel source
15:34
<
naobsd >
hipboi: ping
15:49
atiti has quit [Ping timeout: 276 seconds]
16:25
Theueip has quit [Quit: Leaving...]
16:50
AstralixNB has quit [Ping timeout: 264 seconds]
17:07
atiti has joined #linux-rockchip
17:15
ausxxh has joined #linux-rockchip
17:22
arokux2 has joined #linux-rockchip
17:29
neodallas has quit []
18:08
eebrah is now known as eebrah|doze
18:25
tonikasch has quit [Read error: Connection reset by peer]
18:30
tonikasch has joined #linux-rockchip
18:32
jpsminix has quit [Remote host closed the connection]
18:44
<
Astralix >
Ok, MTD is something very common. But yes it is the upper part of a system where a filesystem hooks up onto.
18:45
<
Astralix >
But below MTD there is a special driver for NAND flash missing in that sheets
18:45
<
tonikasch >
don't know actually, I'm just seeking information to prepare myself for kernel hacking
18:45
<
Astralix >
I am not sure if writing an FTL is the right point to start...
18:46
<
tonikasch >
what does FTL stand for?
18:46
<
Astralix >
Just to give some hints, MTD is kind of a virtual device layer that abstracts the different technologies of electronical memories
18:47
<
Astralix >
So NAND flash has very limited number of writes available
18:48
<
Astralix >
and second, cells may be altered by read or write that are not part of the date read or written
18:49
<
Astralix >
So what kills data is each of these cases
18:49
<
Astralix >
but what renders NAND cells unusable is only the erase
18:49
<
Astralix >
To limit the number of erases, a software needs to memorize which blocks had already been erased lots of times, and which not
18:50
<
Astralix >
so wear-leveling means, if you write data, write it at the leased erased block that you can find
18:51
<
Astralix >
(the one with the minimal erase cycles)
18:51
<
tonikasch >
yes, I understand that
18:51
<
Astralix >
Additionally NAND is organized in different block sizes
18:52
<
Astralix >
but our filesystems calculate in 512bytes
18:52
<
Astralix >
so the software has to track, where a 512byes sector resides together with other 512 bytes sectors in one block
18:55
<
Astralix >
And on top of that there is the fact, that the erase pages are built of multiple blocks
18:55
<
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.
18:56
<
Astralix >
The address a driver gives to the MTD has nothing to do with the real address of the sector inside the NAND.
18:57
<
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
18:57
<
Astralix >
so here is the big thing in NAND tech:
18:58
<
Astralix >
1) you may not write to often, as erasing kills your memory
18:58
<
Astralix >
2) You must read-correct-write memory some times as it gets weak over time.
18:59
mcbrick has joined #linux-rockchip
19:00
<
Astralix >
You can read all that from someone who must know it:
19:00
<
Astralix >
grrr.... google...
19:00
<
tonikasch >
yeah, I can get the address ;)
19:01
<
tonikasch >
I have to leave now for dinner, I'm going to read it afterwards
19:01
<
tonikasch >
Thanks!
19:04
<
Astralix >
welcomed
20:10
<
tonikasch >
Astralix Perhaps you said that rk30xxnand.ko did strange things? I assume so that you did a objdump of it?
20:12
<
Astralix >
yes I did that
20:13
<
Astralix >
but reverse engineering the mechanisms that rockchips marked as their private property...
20:13
<
Astralix >
I'd prefer do replace this code with something open source and well documented
20:15
Astralix has quit [Remote host closed the connection]
20:24
Astralix has joined #linux-rockchip
20:24
<
Astralix >
Sorry, my IRC client crashed
20:27
<
tonikasch >
do you know if rockchip devices have an internal bootloader on rom loaded before the actual modified u-boot?
20:42
<
Astralix >
ah... did you read the TRM of RK3066?
20:42
<
Astralix >
there is written how the mask rom loader works
20:43
<
Astralix >
and ubi is probably not what you want
20:43
<
Astralix >
for NAND you should look at f2fs
20:51
<
tonikasch >
f2fs? In fact you were looking for someone with experience on it, wasn't it?
20:53
<
Astralix >
we need to team up a bit
20:53
<
Astralix >
doing this all alopne doesn't make sense
20:55
<
tonikasch >
yes, I know
21:37
_shb_ has joined #linux-rockchip
21:41
arokux2 has quit [Remote host closed the connection]
21:43
arokux2 has joined #linux-rockchip
21:45
tonikasch has quit [Quit: Bye!]
21:46
tonikasch has joined #linux-rockchip
21:49
tonikasch has quit [Client Quit]
22:02
Astralix has left #linux-rockchip [#linux-rockchip]
22:17
soletti has left #linux-rockchip [#linux-rockchip]
22:50
arokux2 has quit [Read error: Connection reset by peer]
22:51
arokux2 has joined #linux-rockchip
23:01
arokux2 has quit [Remote host closed the connection]
23:17
naobsd has quit [Quit: Page closed]
23:28
arokux2 has joined #linux-rockchip
23:46
tinti_ has quit [Read error: Connection reset by peer]
23:57
Galland has joined #linux-rockchip