Using redboot with x/y modem

Hi Mike,

If you can't solve your problem with redboot, you might want to try u-boot -- it supports kermit and

x/y modem was recently added.

Regards,

--Scott

Hi Scott,

Thanks for that suggestion. I hadn't heard of u-boot before and after a brief look at the u-boot web page I think it might be just what I need (I like the name too!). I notice that your name appears in the copyright at the top of the files relating to the Nios processor in the u-boot source respository. You're too modest! Now that I know about u-boot I have also found lots of discussion about it in the Nios general software forum.

I will set aside some time over the next few days to try and make u-boot work for me. In thew past you have posted some pre-compiled binaries and source code for use with Nios II 5.0 on some of the older dev boards. I am guessing that those files will work with Nios 5.1 on a Cyclone II 2C35 board without much effort?

Mike

Hi Mike,

> I am guessing that those files will work with Nios 5.1 on a Cyclone II 2C35 board without much effort?

It shouldn't be too difficult, several people have done so for the 2C35 board. I still haven't received my

2C35 board (some delays due to ROHS redesign) -- which is why I haven't updated the pre-built

binaries and cygwin-friendly source tarball yet. When my board gets here I'll be updating everything

and adding direct support for the 2C35 (along with some other features).

In the mean time, just post any questions and I'll do my best to respond.

Regards,

--Scott

Hi Scott,

I have started making a u-boot configuration for my 2C35 based Nios dev kit by adjusting the files that you produced for the 1C20. I think I have most of it figured out, except for the definition of TEXT_BASE.

In the file board\altera\ep1c20\config.mk there is a definition for TEXT_BASE:

TEXT_BASE = 0x01fc0000

And in file include\configs\ep1c20.h starting at line 50 there are definitions of the base addresses of the blocks of memory:

#define CFG_FLASH_BASE  0x00000000    /* FLASH base addr    */# define CFG_FLASH_SIZE  0x00800000    /* 8 MByte  */# define CFG_SDRAM_BASE  0x01000000    /* SDRAM base addr    */# define CFG_SDRAM_SIZE  0x01000000    /* 16 MByte  */# define CFG_SRAM_BASE  0x02000000    /* SRAM base addr    */# define CFG_SRAM_SIZE  0x00100000    /* 1 MB (only 1M mapped)*/

So, the TEXT_BASE is inside the SDRAM, but what does the offset of 0x00fc0000 mean?

The memory definition for my board is (I think this is still the standard example project for the 2C35):

#define CFG_FLASH_BASE  0x00000000    /* FLASH base addr    */# define CFG_FLASH_SIZE  0x01000000    /* 16 MByte  */# define CFG_SDRAM_BASE  0x04000000    /* SDRAM base addr    */  # define CFG_SDRAM_SIZE  0x02000000    /* 32 MByte  */      # define CFG_SRAM_BASE  0x02000000    /* SRAM base addr    */# define CFG_SRAM_SIZE  0x00200000    /* 2 MB      */    

Can you tell me tell me how to work out what TEXT_BASE should be for my board?

Thanks,

Mike

I think I've worked it out: TEXT_BASE is the location in RAM which u-boot will use and you've set it so that it is simply near the end of the DRAM.

Mike

Hi Scott,

OK, I have configured u-boot for the EP2C35 dev board, built it, downloaded it to RAM and run it. I can also burn it into flash and then have it start when I reset the board. So far so good!

I have an elf file and a .flash (S-record) file for the application which I want to boot using u-boot. I'm struggling to get u-boot to download files into flash memory. Should I use the .flash or the elf file?

To try and get started I have tried to simply use u-boot to burn the u-boot.bin file into flash memory at address 0. The "protect off all" command works OK. Next I need to erase the flash. I have tried "erase all", "erase bank 1" and "erase 1:0-100" but each command replies with "Timeout" after writing "." characters for a few seconds. If I read the flash memery using md then I can see that the memory started at address 0 is not blank and matches the last file which I burned using the tools in the Nios IDE.

The flash configuration in my u-boot configration file (EP2C35.h) is shown below. The flash device on the EP2C35 board is an Am29LV128, which is bigger than on the boards for which you provided sample u-boot files. Have I changed the configuration properly for this device?

#define CFG_FLASH_BASE  0x00000000    /* FLASH base addr    */# define CFG_FLASH_SIZE  0x01000000    /* 16 MByte  */
/*------------------------------------------------------------------------
 * FLASH (AM29LV065D)
 *----------------------------------------------------------------------*/# define CFG_MAX_FLASH_SECT    256  /* Max#  sects per bank */# define CFG_MAX_FLASH_BANKS    1  /* Max#  of flash banks */# define CFG_FLASH_ERASE_TOUT    8000  /* Erase timeout (msec) */# define CFG_FLASH_WRITE_TOUT    100  /* Write timeout (msec) */# define CFG_FLASH_WORD_SIZE    unsigned char    /* flash word size    */

I feel that I am really close to cracking this, but I need a bit of help!

Mike

Hi Mike,

Sorry for the delay in responding ... I'm on vacation right now, so it's difficult to get Internet access.

> I have an elf file and a .flash (S-record) file for the application which I want to boot using u-boot.

> I'm struggling to get u-boot to download files into flash memory. Should I use the .flash or the elf file?

When using u-boot to program flash it's best to load a binary image into ram, then copy the image

to the target flash address (after erasing the appropriate sectors). U-boot will recognize the target

address as flash and automatically perform the programming.

If you have the elf file, you can use objcopy to generate the binary:

$ nios2-elf-objcopy -O binary foo.elf foo.bin

> Have I changed the configuration properly for this device?

The config looks ok, but since the device is Am29LV128M (rather than 065D), the flash driver

probably needs some modifications. I just received my 2c35 board on Monday (at least that's

what I've been told). As soon as I return I'll be working on u-boot support for the board.

In the mean time, take a look at the board/altera/common flash.c and AMD065D.c files. The

most important being flash_init() int AMD065D.c.

Regards,

--Scott

Hi Scott,

Don't worry about the delay, I figured that you would at least be taking the 4th of July as a vacation. I'm on vacation now myself for a few days so hopefully you'll have found your 2C35 board waiting on your desk and cracked this problem before I get back! I don't need to get this working right now as we're not due to start shipping for a couple of months yet so I can spend some time working on my application while I wait to see if you post a solution for the flash driver.

I wonder if the RoHS compliant version of the 2C35 board even has an Am29LV128 device on it? We are due to receive our first custom Cyclone II boards in a week or two. Those boards have been made RoHS compliant and I know that the engineer who designed them used a Spansion device because he could not get hold of a RoHS compliant Am29LV128, but I think he picked the device that was the closest match to the Am29LV128. I had hoped that our board would be as similar to the dev board as possible to minimise the riskof having components that were unsupported by you guys (This is the first project for us that uses this technology).

Mike

Hi Scott,

I couldn&#39;t wait any more for you to fix this for me, so I have fixed it myself http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/wink.gif

I compared the datasheets for the AMD29LV065D and the AMD29LV128 and noticed that the difference is that the erase and program commands need to be written to specific address for the AMD29LV128 whereas the AMD29LV128 does not care where the commands are written to. I changed the code in flash_erase() in AMDLV065D.c from

  writeb (addr, 0xaa);
  writeb (addr,  0x55);
  writeb (addr,  0x80);
  writeb (addr,  0xaa); 
  writeb (addr,  0x55);
  writeb (addr2, 0x30);

to

  writeb (0xaaa, 0xaa);
  writeb (0x555,  0x55);
  writeb (0xaaa,  0x80);
  writeb (0xaaa,  0xaa);
  writeb (0x555,  0x55);
  writeb (addr2, 0x30);

This change allowed u-boot to erase sectors in my flash. Then I changed the code in write_buff() in AMDLV065D.c from

  writeb (cmd,  0xaa);
  writeb (cmd,  0x55);
  writeb (cmd,  0xa0);
  writeb (dst, b);

to

  writeb (0xaaa,  0xaa);
  writeb (0x555,  0x55);
  writeb (0xaaa,  0xa0);
  writeb (dst, b);

This change allowed u-boot to write data into my flash. So far so good! But I haven&#39;t worked out how to use u-boot reliably.

I have copied u-boot.bin to address 0x0 in flash so that it boots when I reset the board. I have made an s-record image of my application and then downloaded it into flash at 0x00050000 using the u-boot commands protect off / erase/ loads 0x00050000. If I then read the file back from flash using saves then I can verify that u-boot has correctly written the file to flash.

I have tried to start the app using the u-boot commands:

cp 0x00050000 0x02000020 0x8000

go 0x020001c8

This works sometimes, but not every time. When it fails, it fails after the cp command. I think the problem is due to overwriting the exception address at 0x02000020. I am only using the SRAM on my dev board, and TEXT_BASE for u-boot has been set safely high in SRAM at 0x021E0000.

I have also tried building a binary file that includes the Altera bootloader (As made by the flash programmer in the IDE). When I use that image I can sometimes start it by simply using the command go 0x00050000 which causes the app to copy itself to SRAM and start running. But this doesn&#39;t work every time either.

The bootm command sounds good as it disables interuupts before copying the image, but I don&#39;t have the mk-image tool.

Can you tell me a few basic steps to make a binary file, download it into flash at an address above 0x0 and then execute it? I think I am close, but I am also stuck.

Thanks,

Mike

Scott,

I tried a simple experiment to see if my hunch about interrupts was right. I have edited the code in command/cmd_mem.c to change the function do_mem_cp(). What I have done is disable the interrupts just before the cp command copies the data. I have left the interrupts disabled:

int do_mem_cp ( cmd_tbl_t *cmdtp, int flag, int argc, char *argv)
{
  ..
  ..
  // MJS: try disabling interrupts
  disable_interrupts();
  while (count-- > 0) {
    if (size == 4)
      *((ulong  *)dest) = *((ulong  *)addr);
    else if (size == 2)
      *((ushort *)dest) = *((ushort *)addr);
    else
      *((u_char *)dest) = *((u_char *)addr);
    addr += size;
    dest += size;
  }
  return 0;
}

I then typed these commands into u-boot:

cp 0x00050000 0x02000020 0x40000

go 0x02000154

and was very surprised to find that it now works perfectly!

If I remove the line which disables the interrupts then u-boot crashes and resets after I send the cp command. What does u-boot use interrupts for anyway? Timers for the timeouts perhaps? I am sure my quick and dirty fix here will have some serious side-effects somewhere else!

Mike