Programming the SPI FLASH: Difference between revisions

From OLPC
Jump to navigation Jump to search
No edit summary
(Deprecate LinuxBIOS related info)
 
(27 intermediate revisions by 6 users not shown)
Line 1: Line 1:
{{deprecated}}
(Preliminary instructions from Richard Smith)


The OLPC LinuxBIOS includes an "olpcflash" utility which lets you reprogram the main SPI FLASH that contains LinuxBIOS and the microcode for the EC controller chip.
==olpcflash now works==


==Layout==
The source code is [[olpcflash.c]]


The spansion 25FL008A SPI 1 MiB flash on the unit is divided into 2 main areas.
I'm booting my board with Linuxbios from the SPI part.


* The EC area (0x0 - 0xffff)
If you are currently booting from a PLCC then please give this a try.
* The LinuxBIOS area (0x10000 - 0xfffff)
''The rest of you should probably wait a bit and see if I've changed
professions to bricklaying.''


The EC (Embedded Controller) area is where the code for the 8051 uP in the EC lives. Changing the code in this area, unless you really know what you are doing and are prepared to deal with the breakage that can occur, is a Very Bad Thing.
One thing I noticed is that SPI boot is slower than the PLCC by just
'''There is currently not a recovery method if you trash your EC code.'''
enough that I thought it had crashed after "Copying LinuxBIOS to RAM."


Because of this, olpcflash does not mess with the first 64KiB of the part.
To compile:


==Usage==
gcc -O olpcflash.c -o olpcflash


* If you plan to write to the SPI FLASH, make sure you're not going to lose power; you really don't want to have a bad BIOS flash. If possible, plug your board into an uninterruptible power supply.
or if you test it under the buildrom uClibc env then you will need to
* Boot to the LinuxBIOS shell prompt.
add the -static option
* Mount some device (e.g. a USB flash key) to use for file storage. If you want to write a new image to the SPI flash, make sure that image file is already on the device.
* cd to a directory on the mounted device.


To Read the LinuxBIOS area.
To use:
$ olpcflash -r filename


To Write the LinuxBIOS area. (Write will erase the area first)
- Read.
./olpcflash -r filename
$ olpcflash -w filename


To Verify the contents of the LinuxBIOS area vs a file.
- Write (Write does an erase first)
./olpcflash -w filename
$ olpcflash -v filename


If the verify fails, <b>do not power off or reboot your machine</b> as you may not be able to reboot if the flash has been corrupted; please reattempt to write and verify the flash. If the write/verify operations continue to fail, please get help. A good channel for help is the #OLPC IRC channel on irc.freenode.net.
- Verify
./olpcflash -v filename


My testing/developement method was to compile it static and copy it to
The method used during developement/testing was to link olpcflash staticly and copy it to
a USB key. Then using a serial console, boot under the buildrom env from PLCC,
a USB key.
mount the USB key, and run olpcflash.
Then using a serial console I boot under the buildrom env from PLCC,
mount the USB key, and run the program.


Olpcflash is currently being incorporated into buildrom and various root image files. Look for it soon in your favorite image.
A side note is that I build with my USB mass storage 'use_delay' set
zero and that appears to be working fine for my massive sample set of
1 key.


==Known Issues==
==What I claim to have tested and Works For Me==


* '''THERE ARE NO SAFEGUARDS!!!'''
* read
* write
* verify
* erase


Adding them is on the TODO list. Think twice, flash once.
==Known Issues==

* PS/2 keyboard/mouse are disabled during and after a flash attempt.

Part of the programming sequence is to place the EC's 8051 uP in reset to keep it from conflicting with the program cycles. This disables PS/2 keyboard/mouse. The uP is left in reset after olpcflash is finished. This prevents the possibility of the EC running code you may have just corrupted. You must reboot to restore PS2 keyboard/mouse.
* Booting from the SPI FLASH is a bit slower than from the PLCC FLASH. This is most noticable just after the message "Copying LinuxBIOS to RAM."

==How to do it the first time==
So how can you get it going before you have an olpcflash-equipped LinuxBIOS installed?

If you have the ability to program PLCC FLASH chips for the OLPC board (see [[Flashing LinuxBIOS]]), you can build the latest LinuxBIOS (see [[Building LinuxBIOS]]), load it into a PLCC FLASH, then boot from that.

Otherwise, you'll have to build olpcflash.c from source, put the executable file onto an external device like a USB disk, then run it under a Linux environment.


You can get the latest source code from the buildrom tree (see [[Building LinuxBIOS]]) in work/olpcflash/olpcflash/olpcflash.c .
''''THERE ARE NO SAFEGUARDS!!!''''


To compile standalone:
nuff said.


gcc -O olpcflash.c -o olpcflash
- Its really slow.


If you link under glibc, yet want to run it under the uClibc based buildrom env, then you will need to add the -static option
Currently it takes a little over 11 minutes to program the part. A
large part of this is due to only doing a single byte each program
cycle.
The part can program up to 256 bytes each cycle so that may be the
next feature to add. According to the typical program time in the
datasheet it will only drop to around 6 minutes though so it may not
be worth it.


As stated earlier, olpcflash should start showing up as a standard command in OLPC images so building from source is probably not necessary.
- Re-entry from KBC reset back into KBC run mode causes the board to reboot.


[[Category:Hardware]]
Need to ask EnE about this. For now putting the KBC back into run
[[Category:Developers]]
mode after I finish the operation is disabled. This will allow you to
[[Category:OS]]
use verify and make sure it worked ok. If you use a PS2 keyboard you
are toast at this point.

Latest revision as of 23:17, 6 June 2007

Stop hand.png WARNING:
The content of this section is considered
DEPRECATED and OBSOLETE
It is preserved for historical or documenting reasons.

The OLPC LinuxBIOS includes an "olpcflash" utility which lets you reprogram the main SPI FLASH that contains LinuxBIOS and the microcode for the EC controller chip.

Layout

The spansion 25FL008A SPI 1 MiB flash on the unit is divided into 2 main areas.

  • The EC area (0x0 - 0xffff)
  • The LinuxBIOS area (0x10000 - 0xfffff)

The EC (Embedded Controller) area is where the code for the 8051 uP in the EC lives. Changing the code in this area, unless you really know what you are doing and are prepared to deal with the breakage that can occur, is a Very Bad Thing. There is currently not a recovery method if you trash your EC code.

Because of this, olpcflash does not mess with the first 64KiB of the part.

Usage

  • If you plan to write to the SPI FLASH, make sure you're not going to lose power; you really don't want to have a bad BIOS flash. If possible, plug your board into an uninterruptible power supply.
  • Boot to the LinuxBIOS shell prompt.
  • Mount some device (e.g. a USB flash key) to use for file storage. If you want to write a new image to the SPI flash, make sure that image file is already on the device.
  • cd to a directory on the mounted device.

To Read the LinuxBIOS area.

$ olpcflash -r filename

To Write the LinuxBIOS area. (Write will erase the area first)

$ olpcflash -w filename

To Verify the contents of the LinuxBIOS area vs a file.

$ olpcflash -v filename

If the verify fails, do not power off or reboot your machine as you may not be able to reboot if the flash has been corrupted; please reattempt to write and verify the flash. If the write/verify operations continue to fail, please get help. A good channel for help is the #OLPC IRC channel on irc.freenode.net.

The method used during developement/testing was to link olpcflash staticly and copy it to a USB key. Then using a serial console, boot under the buildrom env from PLCC, mount the USB key, and run olpcflash.

Olpcflash is currently being incorporated into buildrom and various root image files. Look for it soon in your favorite image.

Known Issues

  • THERE ARE NO SAFEGUARDS!!!

Adding them is on the TODO list. Think twice, flash once.

  • PS/2 keyboard/mouse are disabled during and after a flash attempt.

Part of the programming sequence is to place the EC's 8051 uP in reset to keep it from conflicting with the program cycles. This disables PS/2 keyboard/mouse. The uP is left in reset after olpcflash is finished. This prevents the possibility of the EC running code you may have just corrupted. You must reboot to restore PS2 keyboard/mouse.

  • Booting from the SPI FLASH is a bit slower than from the PLCC FLASH. This is most noticable just after the message "Copying LinuxBIOS to RAM."

How to do it the first time

So how can you get it going before you have an olpcflash-equipped LinuxBIOS installed?

If you have the ability to program PLCC FLASH chips for the OLPC board (see Flashing LinuxBIOS), you can build the latest LinuxBIOS (see Building LinuxBIOS), load it into a PLCC FLASH, then boot from that.

Otherwise, you'll have to build olpcflash.c from source, put the executable file onto an external device like a USB disk, then run it under a Linux environment.

You can get the latest source code from the buildrom tree (see Building LinuxBIOS) in work/olpcflash/olpcflash/olpcflash.c .

To compile standalone:

gcc -O olpcflash.c -o olpcflash

If you link under glibc, yet want to run it under the uClibc based buildrom env, then you will need to add the -static option

As stated earlier, olpcflash should start showing up as a standard command in OLPC images so building from source is probably not necessary.