Re: [coreboot] Working with flash emulator traces (Dediprog EM100Pro)

2017-02-11 Thread Peter Stuge 
Paul Menzel via coreboot wrote:
> find out what parts take too long to read for example?

Nothing will "take too long to read" - the emulator always replies
quickly.


> Are there tools available to help work with these traces, and for
> example map certain areas to the corresponding code?

The address is shown for each command. Just translate that to the
cbfs .rom file. Flash lives at end of 4 GB.


> Is documentation available for working with these traces?
> What to look for, how to use them to analyze the coreboot code?

It's not really so useful for analyzing coreboot code.. The only thing
it tells you is when what parts of coreboot.rom are read by the CPU.


> How do you use it efficiently?

The only thing that comes to my mind as far as performance goes is to
make a histogram of addresses being accessed with a count, and see if
there are any with a particularly high count. Then you can map those
to coreboot.rom manually (cbfstool print and one subtraction) to find
out what is at that address.


//Peter

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Working with flash emulator traces (Dediprog EM100Pro)

2017-02-11 Thread Paul Menzel via coreboot 
Dear coreboot folks,


At work, I have access to a Dediprog EM100Pro, and I am currently to
use it to test coreboot on the Asus KGPE-D16.

The utility em100 for the emulator [1], also provides the switch `
--trace`, and the output looks like below [2].

```
Time: 00. command # 1  : 0x03 - read
00f0 : e9 25 f4 ff 
Time: 00.0879 command # 2  : 0x03 - read
00c0 : 00 00 00 00 
Time: 00.1635 command # 3  : 0x03 - read
00c4 : 00 00 00 00 
Time: 00.2333 command # 4  : 0x03 - read
00c8 : 00 00 Warning: EM100pro sends too much data.
00 00 
Time: 00.3024 command # 5  : 0x03 - read
00cc : 00 00 00 00 
Time: 00.3780 command # 6  : 0x03 - read
00d0 : 00 00 00 00 
Time: 00.4471 command # 7  : 0x03 - read
00d4 : 00 00 00 00 
Time: 00.5227 command # 8  : 0x03 - read
00d8 : 00 00 00 00 
Time: 00.5918 command # 9  : 0x03 - read
00dc : 00 00 00 00 
Time: 00.6674 command # 10 : 0x03 - read
00e0 : 00 00 00 00 
Time: 00.7373 command # 11 : 0x03 - read
00e4 : 00 00 00 00 
Time: 00.8064 command # 12 : 0x03 - read
00e8 : 00 00 00 00 
Time: 00.8820 command # 13 : 0x03 - read
00ec : 00 00 00 00 
Time: 00.9576 command # 14 : 0x03 - read
00f0 : e9 25 f4 ff 
Time: 00.00010267 command # 15 : 0x03 - read
00f4 : ff 66 90 66 
Time: 00.00011023 command # 16 : 0x03 - read
00f8 : 90 66 90 66 
Time: 00.00011714 command # 17 : 0x03 - read
00fc : 38 01 00 ff 
Time: 00.00012665 command # 18 : 0x03 - read
00fff400 : ff ff ff ff 
Time: 00.00013421 command # 19 : 0x03 - read
00fff404 : ff ff ff ff 
Time: 00.00014112 command # 20 : 0x03 - read
00fff408 : ff ff ff ff 
Time: 00.00014868 command # 21 : 0x03 - read
00fff40c : ff ff ff ff 
Time: 00.00015624 command # 22 : 0x03 - read
00fff410 : ff ff ff ff 
Time: 00.00016315 command # 23 : 0x03 - read
00fff414 : ff ff ff ff 
[…]
```

Are there tools available to analyze these traces? For example find out
 what parts take too long to read for example?

Are there tools available to help work with these traces, and for
example map certain areas to the corresponding code?

Is documentation available for working with these traces? What to look
for, how to use them to analyze the coreboot code?

How do you use it efficiently?


Thanks,

Paul


[1] https://www.coreboot.org/EM100pro
[2] https://www.molgen.mpg.de/~pmenzel/20170210%E2%80%93coreboot/201702
10%E2%80%93kgpe-d16%E2%80%93em100%E2%80%93trace.txt

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot