Subject:
|
Re: Flash Write Cycles
|
Newsgroups:
|
lugnet.robotics.nxt
|
Date:
|
Sun, 10 Sep 2006 23:40:52 GMT
|
Viewed:
|
13312 times
|
| |
|
|
"Sivan Toledo" <stoledo@tau.ac.il> wrote in message
news:J5DMMp.Bs5@lugnet.com...
> One probable reason that the NXT does not do any wear leveling is that it
> executes instructions directly from flash (the instructions in the • firmware
> itself), which is memory mapped. This requires that these instructions are
> contiguous, which makes wear-leveling difficult or impossible (this is • called
> XIP in some of the technical literature, for execute-in-place).
True, you can't level the firmware - only file systems can be wear leveled.
I understand that there has been discussion concerning the SAMBA (Boot
Assistant) and the NVM lock-bit locking/unlocking limit of 100 cycles.
Surely the lock bits aren't being unlocked with every firmware download -
are they?
I have written flash loaders for cell phones (a few years ago), and what I
remember is that there is a boot sector that is meant to contain basic code
for configuring enough hardware to allow flashing and providing routines to
write to and read from memory. We called this the ROM bootloader.
The boot code that we wrote would wait for one or two character commands
from a PC. If it didn't get a command within a second or two, it would jump
to the firmware start address. We would send commands to download a RAM
bootloader (from the PC) which had routines that would do the flashing (i.e.
firmware download).
The boot sector is not meant to be changed. It is a simple program. In fact,
there used to be flash devices that would only let you lock it one time. The
100 cycles is a big improvement and way more than enough. Subsequent
firmware downloads did not require unlocking of the boot sector. The RAM
bootloader would flash to the non-boot sectors.
The part I don't understand is why a boot sector has to be unlocked to do a
firmware download. I read the AT91SAM7S256 spec sections on booting and it
sounds like there is a ROM boot program which jumps to the SAMBA boot loader
after setting up hardware and communication mechanisms like USB. The SAMBA
loader is in the first two flash sectors. It then copies itself to RAM to do
the firmware download. I assume it does this so that it can overwrite itself
in the first two sectors.
Does the NXT firmware have a bootloader that is locked in the first couple
of sectors? And if so, why would it be required to be unlocked?
Forgive me if I have misinterpreted what may have been previously discussed,
or if this issue has already been discussed and resolved.
Dave
|
|
Message has 1 Reply:
 | | Re: Flash Write Cycles
|
| (...) As I understand it, the lock bits are only touched if SAMBA mode is entered, which is done when the reset button is pressed for more than about three seconds. At that point, the ARM erases the bottom two sectors and installs the SAMBA firmware (...) (18 years ago, 11-Sep-06, to lugnet.robotics.nxt)
|
Message is in Reply To:
| | Re: Flash Write Cycles
|
| (...) One probable reason that the NXT does not do any wear leveling is that it executes instructions directly from flash (the instructions in the firmware itself), which is memory mapped. This requires that these instructions are contiguous, which (...) (18 years ago, 10-Sep-06, to lugnet.robotics.nxt)
|
14 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
Active threads in NXT programmable brick
|
|
|
|
|
|
