[Openec] Few questions about KB3700/3926

[Maxim Levitsky]

Richard A. Smith wrote:
> Frieder Ferlemann wrote:
> 
>>> Some day I might help with that, you say I can disassemble the firmware,
>>> and give you directions how to power up the CPU?
>>
>> Most likely - that would be great!
> 
> Most of the info needed to determine the proper sequencing is in the AMD 
> data sheet which is available.  The parts you are missing are what IO 
> lines are connected to the enables for each of the regulators.  Very 
> little of that has changed across the XO versions.
> 
>>> Btw, using some instruments and destroying a single OLPC you could 
>>> figure the schematics by unsoldering the parts?
> 
> I don't think you would need to destroy an XO for the purposes of 
> figuring out how the EC is wired.  It would just take a lot of care.
Maybe, but I once tried to trace wires on a TV card, and figured out 
that that is impossible unless I unsolder the parts, and I don't think 
it is easy to unsolder a ~100 pins chip without damaging it.

> 
>> While this might technically work (given sufficient resources/time)
>> it socially probably would not: you would get to know how it is
>> done (but not why, or how future version would look like, and
>> the chance to be involved early in the development phase would be lost).
> 
> Perhaps not quite so bad.  You have access to devleopers that can help 
> guide you just not tell you flat out.
> 
>>> I guess that small devices like sensors and voltage regulators should 
>>> have datasheets.
> 
> Most of those would not be needed since they are simple parts with just 
> off/on enable lines.  The main power plant IC however does have some 
> lines that the EC twiddles for various battery charging states.  I'm not 
> sure if the datasheet for that IC is public.  I'll have to check.
> 
>> Richard, Paul, are you following this thread?
> 
> I am,  with much interest. But I've just had too much other stuff to do 
> so I'm slow on responding.
> 
> Maxim, Did you say that one of those banks has RAM or all they all rom 
> code?
No, I figured that out.
First bank (0x0000-0x4000) is switched between 4 areas in SPI flash chip
00K, 64K, 80K, 96K

other banks are mapped normally.

Or in other words 00-64K contains regular firmware, and 3 additional 
areas on top of that are mapped at 0x0000 (each area has to be 16K since 
this is limitation of XSEGn)

Ram is at place it should be according to datasheet, at SRAM area.



> 
> Also you should explore if the EC reset works for you chip.  Look at 
> page 30 of the 3700 datasheet at the PXCFG register.  On the 3700 If you 
> write a 0x01 into that register you will hold the 8051 cpu in reset but 
> all the indexed IO access still works.  So you can read and write all 
> the registers.  If you can change values in those banks they you either 
> have ram or a register bank.

Thanks for the pointer, but I don't want to poke at EC yet.
What happens if I reset it? Could it be confused?
The EC is very powerful, since it can toggle several GPIO lines that can
damage the system if used incorrectly.

I know that temperature sensors/fan/battary aren't problem since fan 
here is usually off, EC doesn't have temperature sensors, but it relies 
of stupid PME/ACPI code to feed it with core 2 on-die sensor.
And I obivosly remove battery so EC won't send wrong commands to it.


> 
> Something else you may be able to do is use the SPI interface to read 
> the contents of the SPI part.  The read command is standard across all 
> of the SPI parts.  There are 2 ways to try.  1 is by using the SPI 
> bridge.  If you write the address into SPIA0-A3 then a 0x02 into the 
> SPICMD register and then read the results back in SPIDAT after status 
> bit in SPICFG is clear.
> 
> You can also do it manually in passthroug mode. Where you issue the all 
> the commands directly to the SPI part.  You can find all the gory 
> details here.
Can be done too,  thanks.

> 
> http://dev.laptop.org/git?p=projects/olpcflash;a=summary
> 
> If your laptop chipset has the entire EC space decoded via the LPC buss 
> then you may be able to just read it via mmap().
Exactly, it is mapped, this probably the best way.


Btw, does flash have a limit on number of reads?


Best regards,
	Maxim Levitsky