XO Debugging tips: Difference between revisions
(→OFW) |
|||
| (7 intermediate revisions by 3 users not shown) | |||
| Line 9: | Line 9: | ||
find /sys -name oemid | xargs cat |
find /sys -name oemid | xargs cat |
||
From OFW ( |
From OFW (Q3A49 and newer) |
||
ok select int:0 |
ok select int:0 |
||
| Line 22: | Line 22: | ||
==OEMID list== |
==OEMID list== |
||
* ADATA |
* ADATA or 0x4144 "AD" |
||
* Kingston 0x544d |
* Kingston 0x544d "TM" |
||
* SanDisk 0x5344 "SD" or 0x534d "SM" (I think that SM means the card was made by Samsung - wmb) |
|||
* SanDisk (?) 0x4144 |
|||
* Panasonic 0x5041 "PA" |
|||
* Transcend 0x5365 "SV" |
|||
I have seen MicroSD cards that were labeled as Transcend, but with the same electronic ID as SanDisk - wmb. |
|||
==Get performance timings== |
|||
See [[SD_and_USB_FLASH_Drive_Performance]] for more info. With XO-1.5 Q3A50 or later, XO-1 Q2E45 or later, but not XO-1.75 or XO-4, test the internal SD card with: |
|||
ok .speed int:0 |
|||
For external SD card, |
|||
ok .speed ext:0 |
|||
= OFW = |
= OFW = |
||
| Line 37: | Line 51: | ||
ok t( fs-update u:\os111.zd )t |
ok t( fs-update u:\os111.zd )t |
||
this is redundant however -- fs-update reports its timings at the end of the run. |
|||
== Timing reads from USB in OFW == |
== Timing reads from USB in OFW == |
||
| Line 42: | Line 58: | ||
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. |
||
Latest revision as of 01:39, 31 December 2013
SD Card
Specially useful for XO-1.5
Retrieve internal SD card manufacturer
From Linux
find /sys -name oemid | xargs cat
From OFW (Q3A49 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 or 0x4144 "AD"
- Kingston 0x544d "TM"
- SanDisk 0x5344 "SD" or 0x534d "SM" (I think that SM means the card was made by Samsung - wmb)
- Panasonic 0x5041 "PA"
- Transcend 0x5365 "SV"
I have seen MicroSD cards that were labeled as Transcend, but with the same electronic ID as SanDisk - wmb.
Get performance timings
See SD_and_USB_FLASH_Drive_Performance for more info. With XO-1.5 Q3A50 or later, XO-1 Q2E45 or later, but not XO-1.75 or XO-4, test the internal SD card with:
ok .speed int:0
For external SD card,
ok .speed ext:0
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
this is redundant however -- fs-update reports its timings at the end of the run.
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.