Hi,
I don't know whether this proposal really makes sense but 8051 based Embedded Controlers are very likely to have 0x02 (the opcode for LJMP) at address 0x0000 and at some of its IRQ entry points at address 0x0003 + n*8
It might be worth warning about because erasing/writing the flash while the EC is running might not be a good idea.
This posting was triggered by todays publication of: "Flash Programming for Dummies", A book by Carl-Daniel Hailfinger which specifically mentions interactions with embedded controlers.
And a grep for "Embedded" "Controler" "EC" within the flashrom sources did not reveal a warning message.
Greetings, Frieder
Hi Frieder,
On 11.05.2009 19:44, Frieder Ferlemann wrote:
I don't know whether this proposal really makes sense but 8051 based Embedded Controlers are very likely to have 0x02 (the opcode for LJMP) at address 0x0000 and at some of its IRQ entry points at address 0x0003 + n*8
It might be worth warning about because erasing/writing the flash while the EC is running might not be a good idea.
Right. How big can n get? I'd simply read address 0x0000 and all IRQ entry points and check if more than m of them are 0x02.
This posting was triggered by todays publication of: "Flash Programming for Dummies", A book by Carl-Daniel Hailfinger which specifically mentions interactions with embedded controlers.
:-D
And a grep for "Embedded" "Controler" "EC" within the flashrom sources did not reveal a warning message.
Yes indeed. If you have more ideas about EC detection heuristics, please tell us. Emitting a warning may be appropriate if we can make reasonably sure that it won't trigger too many false positives.
Regards, Carl-Daniel
Hi Carl-Daniel,
Carl-Daniel Hailfinger schrieb:
On 11.05.2009 19:44, Frieder Ferlemann wrote:
I don't know whether this proposal really makes sense but 8051 based Embedded Controlers are very likely to have 0x02 (the opcode for LJMP) at address 0x0000 and at some of its IRQ entry points at address 0x0003 + n*8
It might be worth warning about because erasing/writing the flash while the EC is running might not be a good idea.
Right. How big can n get? I'd simply read address 0x0000 and all IRQ entry points and check if more than m of them are 0x02.
For the ENE KB3700 n <= 0x1f (so the IRQ entry points fit within the first 256 bytes). (Datasheet: http://wiki.laptop.org/images/a/ab/KB3700-ds-01.pdf Interrupt vectors table is at 4.12.1).
This posting was triggered by todays publication of: "Flash Programming for Dummies", A book by Carl-Daniel Hailfinger which specifically mentions interactions with embedded controlers.
:-D
I like the book:)
Yes indeed. If you have more ideas about EC detection heuristics, please tell us. Emitting a warning may be appropriate if we can make reasonably sure that it won't trigger too many false positives.
False positives: If all values bytes for the first byte were equally likely (which is a wrong assumption) then around 0.5% false positives could be expected. If one would further require at least two of the 32 IRQ entry points to hold 0x02 (m=2, it's probably a good assumption that at least one timer IRQ and a host interface IRQ is in use) this would likely reduce false positives by around a factor of 60.
False negatives: yes, likely few. F.e. the 8051 knows three different jump instructions ljmp, sjmp, ajmp and while ljmp is the one that would almost always be used here there is no guarantee. (And there might be EC firmware without IRQ - probably depends on the direction the NDA'ed sample code or SDK that comes with the EC pushes EC firmware developers:)
Greetings, Frieder
-
Carl-Daniel Hailfinger -
Frieder Ferlemann