XO Debugging tips: Difference between revisions
(→OFW) |
|||
| Line 42: | Line 42: | ||
To check that USB read times aren't slowing down fs-update, you |
To check that USB read times aren't slowing down fs-update, you |
||
ok dev fsdisk : write-blocks-end ; : erase-blocks 2drop ; : write-blocks-start 3drop 0 ; dend fs-update u:\ |
ok dev fsdisk : write-blocks-end ; : erase-blocks 2drop ; : write-blocks-start 3drop 0 ; dend fs-update u:\osXXX.zd |
||
and then |
|||
ok t( fs-update u:\os111.zd )t |
|||
The first command directs redirects writes to SD into /dev/null, keeping everything else the same. fs-update tries to overlap reads and writes, so adding read time + write time doesn't give you the answer, but if you find that the null-write case exceeds your normal fs-update timings, then USB read time is a factor. |
The first command directs redirects writes to SD into /dev/null, keeping everything else the same. fs-update tries to overlap reads and writes, so adding read time + write time doesn't give you the answer, but if you find that the null-write case exceeds your normal fs-update timings, then USB read time is a factor. |
||
Revision as of 18:56, 4 August 2010
SD Card
Specially useful for XO-1.5
Retrieve internal SD card manufacturer
From Linux
find /sys -name oemid | xargs cat
From OFW (Q3E49 and newer)
ok select int:0 ok show-cid
On older OFW try
ok dev /sd patch get-cid get-csd attach-card select int:0 " cid" $call-parent 10 dump
Interpreting the dump is not trivial. WMB dixit: "One of the fields is an enumerated hex number, another is a two-ascii character assigned ID (stored backwards), another is a 5-byte arbitrary ascii string (stored backwards), another is a BCD two-nibble version number, another is a 12-bit BCD code date, and another is a 4-byte serial number"
OEMID list
- ADATA 0x534d or 0x5344
- Kingston 0x544d
- SanDisk (?) 0x4144
OFW
Timing commands in OFW
Try
ok t( yourcommand )t
For example you can time an fs-update command:
ok t( fs-update u:\os111.zd )t
Timing reads from USB in OFW
To check that USB read times aren't slowing down fs-update, you
ok dev fsdisk : write-blocks-end ; : erase-blocks 2drop ; : write-blocks-start 3drop 0 ; dend fs-update u:\osXXX.zd
The first command directs redirects writes to SD into /dev/null, keeping everything else the same. fs-update tries to overlap reads and writes, so adding read time + write time doesn't give you the answer, but if you find that the null-write case exceeds your normal fs-update timings, then USB read time is a factor.