Author Topic: Bootloader on NE64  (Read 7513 times)

Offline Jamier

  • Newbie
  • *
  • Posts: 14
    • View Profile
Bootloader on NE64
« on: February 14, 2008, 06:20:24 AM »
Hi Mark,

From our email correspondence you may recall that I am required to implement a bootloader on the NE64.  I wanted to bring this discussion here for the benefit of other users.

Here is a summary of what I am trying to achieve - at the end I'll have a couple questions that will help solidify my plans.

Since the application is expected to exceed 32k, I have been provided with a SPI EEPROM (25AA512) for external storage - not the ideal case in the uTasker environment.


What I would like to do is receive an application .bin file over FTP and rather than writing to the internal file system, write the data to the EEPROM in chunks as each piece of the file is received.  Once written to EEPROM, the application would validate the application image (in EEPROM) and if all is well, reboot.

Upon reset, the bootloader runs first and checks the EEPROM for an application.  If one is found, the bootloader will erase the application stored in FLASH and copy the new application from EEPROM to FLASH.  If the copy was successful and the application in FLASH is valid, the EEPROM is erased and the device reboots.  New application runs.


The real challenge, I think, is modifying uTasker to direct the received application .bin file to EEPROM rather than the internal file system.

Mark, is my proposal possible?  Would you recommend a different way?

I know your next SP for uTasker NE64 has greater functionality for external file system support, but in my case with the EEPROM I have been given, I don't think it will help me much - is this correct?

Thanks.

Jamie.


Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3188
    • View Profile
    • uTasker
Re: Bootloader on NE64
« Reply #1 on: February 14, 2008, 10:42:21 AM »
Hi Jamie

The setting you need to do this is
#define SPI_SW_UPLOAD
#define FLASH_FILE_SYSTEM
(without #define SPI_FILE_SYSTEM)

This will allows an internal file system to operate and a file transferred by HTTP or FTP to be saved directly to a special location in external SPI FLASH. The boot loader also requires the setting #define SPI_SW_UPLOAD which then works as you have specified.

However with the NE64 there will be some work to be done.
1. The SPI_SW_UPLOAD is not supported in the HW file and so will have to be added (I will send you the M5223X project as reference since this is supported there - the difference is still that it supports it to SPI FLASH and not SPI EEPROM, although this should be no great difficulty to change).
2. The bootloader doesn't include the NE64 so this will have to be adapted. Once the routines for the HW access have been solved these can be put there so this is not very difficult. More complicated is the requirement to have the boot loader supporting the interrupt handling, but we have discussed this before and it is certainly possible (although out of the scope of the general boot loader).

Good luck.

Regards

Mark

PS. The operation of the SW_UPLOAD is described in http://www.utasker.com/docs/uTasker/BM-Booloader_for_M5223X.PDF
If you use the uTasker simulator with the M5223X you can try this out and use it as a refence for the NE64 modifications.

Offline Jamier

  • Newbie
  • *
  • Posts: 14
    • View Profile
Re: Bootloader on NE64
« Reply #2 on: February 16, 2008, 10:42:29 PM »
Hi Mark,

I am having lots of fun playing with uTasker and it various capabilities!  I find as I go I am learning a lot and correcting some misunderstandings I have been harbouring since starting my evaluation.

One particular misunderstanding I have had, I think, is regarding the file system and application.

Correct me if I am wrong, but the application does not live in the file system, does it?

I think my task creating a bootloader for NE64 is now simplified.

In config.h, I can define SPI_FILE_SYSTEM and not define FLASH_FILE_SYSTEM.  That way files uploaded to the NE64 get written to a 64K external SPI EEPROM while the application still runs out of internal FLASH as usual.  The drawback is the 16k reserved for internal file system is not available for files.  (But I suppose it frees up 16k for application code, correct?)  Reading the documentation again seems to state this quite clearly - I am not sure how I missed it!

So ignoring the complications with interrupts as we discussed previously, would it not be possible to have the firmware upgrade process work as follows (using the releases code for NE64 uTasker SP1):

1. Start with programming via BDM the blank NE64 FLASH with the applicatin - EEPROM is blank.
2. Run the application, connect with TFTP (rather than FTP since TFTP takes dramatically less resources).
3. uTasker receives webpage files and stores them to SPI EEPROM.
4. Webpages are now active and can be browsed.
5. Some time later, we want to do a firmware upgrade.
6. Connect via TFTP and transfer a new application file.  The file gets written to the file system on EEPROM, as usual.
7. Reboot.  (What follows will be standard boot process regardless of firmware upgrade or not)
8. Bootloader, which I've developed, checks the EEPROM for a valid application which has been predefined to start at a certain address.  If found, copy the file to internal FLASH.  If not found, jump to application in FLASH.  The application in EEPROM can be erased by the bootloader, or by the application at startup.
9. User reconnects via TFTP and transfers new webpages, if required.  (If new applicaiton is less than 48k, webpages stored in EEPROM remain intact. so no webpage transfer is required)

6a. Alternative to step 6.  Rather than TFTP, a webpage can provide this functionality, as long as application is less than 48k so that webpages do not have to be erased.


Does this seem like the best approach, after the other scenarios that we've discussed?

Your comments are greatly appreciated!

Jamie

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3188
    • View Profile
    • uTasker
Re: Bootloader on NE64
« Reply #3 on: February 17, 2008, 01:00:55 AM »
Hi Jamie

Before answering the details it may be useful to explain some fundamental decisions made when the project was initially developed.

The NE64 is a nice chip but it is 16 bit and requires paging operation as soon as more than 48k FLASH is addressed by the program code. Using external memory it is possible to address quite a large address space like this.
The down side of using paging is that it is not very efficient - it requires trampoline functions to jump from code running on one page to a sub-routine in another page. The compiler will handle all of the details (usually) but I wanted to use the GNU compiler and I found that this didn't work well with paging at all (I could onyl get it working by forcing certain routines to certain pages - which was a real mess).

This is why the uTasker project uses linear addressing with the NE64 and restricts the program memory to 48k (although there is nothing to actually stop someone using paging - it is basically a compiler and linker configuration). But the uTasker's goal was to enable a small footprint solution with real single-chip devices and requiring extended memory seemed to be missing the goal. With a good compiler you can fit quite a lot of functionality into 48k code space, including most TCP/IP stuff - and most such projects need a web server, which needs some web pages to be served. Fortunately 16k is quite a suitable size for such web pages in a typical NE64 project and the remaining (paged) 16k of FLASH was thus allocated for that. The result was that the project code is very efficient (no trampoline function for paging and no extended addressing) and the file system makes good use of the non-code-addressable remaining FLASH.

The file system has to switch in the 16k FLASH page when it reads or writes, so the data in the file system can not be accessed using pointers but instead the window has to be switched in and out when the file system specifically needs to access it.

The question about the application not being in the file system is this confirmed. No code can be in the file system since no code can be executed in the paged sector.

There is now a pre-release of a new NE64 service pack which changed some restrictions as discussed above. It now adds support for internal and external file system memory at the same time. The only way to do this however was to 'force' the use of 32 bit pointers (not paging though) which is less code efficent for the 16 bit device. It now means that parameters can be internal (the 16k page), some files can be internal and the rest external (SPI FLASH or SPI EEPROM). This means that no internal memory is lost (although it could be used for code if paging operation were used - the uTasker project just never does any paging though) but also enables files for the HTTP server to be positioned in code. This is not possible when using the original method and this is why the HTTP 404 error page has to be loaded to the file system in the NE64 project without the new support.

Now - with this background - we can discuss the boot loader theme:

Your firmware upgrade is perfectly correct. If you want to use TFTP in the process I see no reason to change anything that you suggest.
The comments that I make are more alternatives which you may like to consider or simply some more background info.:

2. Run the application, connect with TFTP (rather than FTP since TFTP takes dramatically less resources).

TFTP requires only UDP, whereas FTP requires TCP. In addition the code for an FTP server (which uses 2 TCP connections to do the work) is rather larger. This is why TFTP was traditionally used for such functions.
If your application uses FTP then there is probably no advantage of loading the web pages by TFTP (DOS FTP can be run using a script file which automates everything) - only when FTP is not necessary in the application will TFTP save application code space.
FTP is more flexible since it doesn't need a known TFTP server running. It can also work over the Internet (TFTP is more suitable in a LAN and not so for working outside of this).


6a. Alternative to step 6.  Rather than TFTP, a webpage can provide this functionality, as long as application is less than 48k so that webpages do not have to be erased.

In fact it is also possible to live without any FTP or TFTP to do all file transfer work.
If the new support for addressing with long pointer is active it is possible to have a single fixed web page in code. This can be used to allow file transfer of all further web pages and also SW upload files using HTTP POST method.
I have to admit that I haven't actually used this technique in this form but it will certainly work - this default web page could simply replace the standard 404 error page...

Good luck

Regards

Mark



Offline Jamier

  • Newbie
  • *
  • Posts: 14
    • View Profile
Re: Bootloader on NE64
« Reply #4 on: February 20, 2008, 07:15:52 AM »
Mark,

Thanks for the explanation and feedback.

Regarding your uTaskerConverter tool...  will it be of use to me in converting my .s19 for an NE64 application to a usable binary file for my custom bootloader?  Is there any documentation that goes with the tool?

Thanks.

Jamie.


Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3188
    • View Profile
    • uTasker
Re: Bootloader on NE64
« Reply #5 on: February 20, 2008, 10:14:57 PM »
Hi Jamie

The conversion utility is described briefly in http://www.utasker.com/docs/uTasker/uTaskerBoot_003.PDF
It is quite simple and there is no further documentation. It simply calculates and adds a header to the binary code. Rather than generating an SREC file you can generate a binary file and use the utility as it is - it is not processor specific - therefore I see no reasons for not being able to use it on the NE64.

A possible complication would be if you need to split the code to use different regions of memory rather than just be in one block. The only reason for this may be because of fixed locations for interrupt vectors - placing these at 0x4000 rather than 0xff00 (as the freescale serial loader does, if I remember rightly) would probably avoid such requirements.

Regards

Mark