Tuesday, September 21, 2004
How Stuff Is Arranged In Flash
It took a while to figure this out. As far as I know this is not documented by Digi. I kinda think their tech support guys think it's obvious, but like I say, it took me a while to figure it out. While I was able to write my source without this knowledge, I could not understand the instructions for loading code into a non-JTAG target until this picture formed in my head.
=============================================
Memory Top
NonVolatile Memory
Flash File System (if compiled into application)
User Application (includes BSP)
-----
Boot Loader
Memory Bottom
Maybe someday I'll draw a real picture. For now, the outline above will do.
In the original ConnectMe, the Boot Loader was not user accessible. It is, however, built by the Development Kit (DK) along with the Board Support Package (BSP). In the latest DK, the boot loader image is linked as:
netos60_gnu/src/bsp/bootloader/romImage/rom.bin
In the original ConnectMe, everything above the dashed line is changeable, but everything below the dashed line is locked. So, you cannot change the boot loader (or can you...). Changing the boot loader would be convenient because it kinda sucks. When the system boots, the boot loader does a sum check of the code in application space. If good, the boot loader jumps to that code. If bad, the boot loader attempts DHCP; if that works, then it tries to bootp a new image from the DHCP server. I have not verified this part experimentally, but I have read that the bootp will only be attempted from the successful dhcp server. There is no way to escape to the boot loader on reset, or from the application; therefore, if you load code into the ConnectMe that satisfies the boot loader's sumcheck, but makes the thing continually reset, you have just wasted a ConnectMe.
The BSP source ends up as:
netos60_gnu/lib/32b/libbsp.a
and is linked into the Boot Loader as well as into your application. That took a while for me to verify - the BSP is linked into my app, as opposed to residing in system Flash like some kind of BIOS. Again, when I verified this observation with Digi Tech Support, they just said, yeah, how else would it be done?
Your application is compiled to image.elf (JTAG/gdb image) and image.bin (Flash image).
If your application requires a Flash File System, you will need to compile and link it into your app. I have not worked with this yet.
=============================================
Once I put together the information above, I was able to understand the procedures for updating firmware at the end of the Programmers' Guide:
Rebuild BSP, bootloader and application
Use JTAG and gdb to run an FTP server in RAM
Use the RAM based ftp server to load the bootloader with reserved filename rom.bin
Use the RAM based ftp server to load the application with reserved filename image.bin
Larry Martin
www.GlueLogix.com
Copyright (c) 2004 Larry Martin. All Rights reserved.
=============================================
Memory Top
NonVolatile Memory
Flash File System (if compiled into application)
User Application (includes BSP)
-----
Boot Loader
Memory Bottom
Maybe someday I'll draw a real picture. For now, the outline above will do.
In the original ConnectMe, the Boot Loader was not user accessible. It is, however, built by the Development Kit (DK) along with the Board Support Package (BSP). In the latest DK, the boot loader image is linked as:
netos60_gnu/src/bsp/bootloader/romImage/rom.bin
In the original ConnectMe, everything above the dashed line is changeable, but everything below the dashed line is locked. So, you cannot change the boot loader (or can you...). Changing the boot loader would be convenient because it kinda sucks. When the system boots, the boot loader does a sum check of the code in application space. If good, the boot loader jumps to that code. If bad, the boot loader attempts DHCP; if that works, then it tries to bootp a new image from the DHCP server. I have not verified this part experimentally, but I have read that the bootp will only be attempted from the successful dhcp server. There is no way to escape to the boot loader on reset, or from the application; therefore, if you load code into the ConnectMe that satisfies the boot loader's sumcheck, but makes the thing continually reset, you have just wasted a ConnectMe.
The BSP source ends up as:
netos60_gnu/lib/32b/libbsp.a
and is linked into the Boot Loader as well as into your application. That took a while for me to verify - the BSP is linked into my app, as opposed to residing in system Flash like some kind of BIOS. Again, when I verified this observation with Digi Tech Support, they just said, yeah, how else would it be done?
Your application is compiled to image.elf (JTAG/gdb image) and image.bin (Flash image).
If your application requires a Flash File System, you will need to compile and link it into your app. I have not worked with this yet.
=============================================
Once I put together the information above, I was able to understand the procedures for updating firmware at the end of the Programmers' Guide:
Rebuild BSP, bootloader and application
Use JTAG and gdb to run an FTP server in RAM
Use the RAM based ftp server to load the bootloader with reserved filename rom.bin
Use the RAM based ftp server to load the application with reserved filename image.bin
Larry Martin
www.GlueLogix.com
Copyright (c) 2004 Larry Martin. All Rights reserved.
# posted by Larry Martin @ 5:42 PM 
