Flash programmer via ethernet

also take a look at the nios ethernet development kit (http://digital5.ece.tntech.edu/public/altera/books/ug/niosedk.pdf) doco for more information ...

i do hope that this is possible

> There is also a port of UBoot available which I believe will do the same job

Yes, u-boot supports file download via tftp, NFS, serial (kermit/SREC),

and flash programming ... along with the associated support for BOOTP/DHCP,

ping, netconsole, etc.

u-boot however, is purely "pull" model for file download ... i.e. all download

activity is initiated on the target via command line interface. So a "remote"

upgrade would require u-boot to be configured with netconsole suport, or

you'll need remote access to the serial/JTAG-uart port.

Regards,

--Scott

Halfway thru writing my own ethernet downloader, I decided to check out the alternatives.

The Redboot docs indicate that no port exists for Nios boards. If someone has one, maybe they could post it.

u-boot looks more promising. I was able to build for the "PK1C20" board configuration, and it can download and partially run on a 1S10_ES kit board I have. The console works but the ethernet does not, so there must be some critical differences between these boards.

The image is smaller than I expected at ~100kB. This is probably smaller than my own downloader code, but with more features.

I'd like to see it fully working on the 1S10 board before I spend my days porting u-boot to run on my custom board (The README is rather large). Does anyone know of more ports available or what I need to change to get it fully working on my kit board?

Hi tns1,

> The Redboot docs indicate that no port exists for Nios boards. If someone

> has one, maybe they could post it.

Redboot is included with ecos.

> The image is smaller than I expected at ~100kB. This is probably smaller than my

> own downloader code, but with more features.

You can reduce the size further by eliminating features you don't need. This is done in

the board's config file. For the PK1C20, the config file is include/configs/PK1C20.h.

For example, you can exclude the hush parser (scripting) and long help:

Undefine CFG_LONGHELP and CFG_HUSH_PARSER.

> The console works but the ethernet does not

Please provide some details.

> Does anyone know of more ports available or what I need to change to get it fully

> working on my kit board?

Unfortunately, I don't have a 1S10 board to test with. But here are some things you

might want to check:

1. Make sure your ethernet environment variables are set correctly. Here's a list variables

you may need to modify/create:

-- serverip - ip address of the tftp server

-- netmask - you're network's netmask

-- gatewayip - the ip address of the primary gateway (if needed).

2. Before trying tftpboot, use the ping command to test connectivity.

3. In include/configs/PK1C20.h:

-- check the ethernet macros to make sure they're correct (for the 1s10 board).

E.g. CONFIG_SMC91111_BASE etc.

-- check the timer macros (CFG_NIOS_TMRxxxx) -- you may be timing out early.

4. In drivers/smc91111.c change the SMC_DEBUG macro to 3. This will provide lots of debug

output to the console.

5. Finally, you can review the config files for the Nios-32 port (DK1C20.h and DK1S10) for

some clues. But be warned .... the Nios-32 config files have been confounded by a well

intended, but poorly executed attempt at making things flexible ;-)

Regards,

--Scott

Thanks Scott,

I found my main problem was those env variables. The 1S10_ES kit board (DK1S10?) must be very close to the PK1C20 configuration since most things are working. I have tested downloading images to this board using srec over serial, binary over serial and tftp (after installing the free solarwinds tftp server). I burned u-boot into the board using u-boot itself as in the USING directions.

u-boot is pretty slick. It give you most of the features you would want from a boot monitor program. I have not been able to download and run the supplied hello world example, though. I used the "loads" and it did load, but a "go 800000" just seems to reboot u-boot. The example output is supposed to appear in the u-boot console window isnt it (not the jtag uart or debug port) ?

It would be nice to have the following:

A way to connect to the u-boot console over ethernet. As you mentioned, u-boot downloads are "pull" model, but if I could use telnet or ssh to get to the console, it would be exactly what I am looking for.

A command that tells you where u-boot is executing from, and what system resources it is using. This is not very clear.

A little more description for the configuration options. The custom board I need to port to has a different memory map and no SDRAM bank. It is not clear if I simply remove CFG options, and what option controls where u-boot relocates to.

Hi tns1,

Glad to hear things are working :-)

> I have not been able to download and run the supplied hello world example, though.

This is currently broken. The global pointer is not being handled properly ... I'll add

it to the TODO list ;-)

> A way to connect to the u-boot console over ethernet.

You could try configuring "net console" ... which basically sends console output to

a particular ipaddr:udp port (and accepts input on a particular port). I haven't tried it yet.

If you need some help you can post questions on the u-boot-users mailing list.

> A command that tells you where u-boot is executing from, and what system resources

> it is using.

There are a few commands that might have some of the info you need: "bdinfo", "flinfo", "irqinfo".

It's very easy to add custom commands to get precisely what you need using the

U_BOOT_CMD macro. You can see common/cmd_misc.c for some examples. Just implement

your custom commands in your board-specific directory.

> The custom board I need to port to has a different memory map and no SDRAM bank.

Not a problem. You _should_ be able to just customize the macros in your board's

config file.

> A little more description for the configuration options.

Most of the configuration options are described in the main README (although several

are admittedly a bit short on details). There is also some additional information in the doc

directory ... and lots of info that may be useful at:

http://www.denx.de/twiki/bin/view/dulg/manual (http://www.denx.de/twiki/bin/view/dulg/manual)

> It is not clear if I simply remove CFG options, and what option controls where u-boot

> relocates to.

For basic memory macros, you should leave them defined with a length of zero. The relocation

address is controlled by the TEXT_BASE definition in the board-specific config.mk file.

See board/psyent/pk1c20/config.mk for example.

Regards,

--Scott

Scott,

Thanks for the help so far. I have u-boot up on my custom board, but have run into a few things.

I needed to add# if defined() for the SDRAM init portion in board.c, since I have none.

My niosII has no cache so I have set those CFG entries to 0.

I discovered that once you have built, you cannot copy the source tree to another folder and rebuild. There are some absolute paths created by the make that are not cleaned.

All I have is 2MB of ram @ x800000, and I would like to keep at least the lower MB clear for application downloads. It looks like u-boot consumes about 6 sectors (64k*6=384k) in the default configuration once you add up all the link sections, so I set TEXT_BASE for the upper 2 sectors.

It does load & run, but I have found thru memory testing that u-boot still keeps a few necessary objects in lower memory. Most notably, there are vectors at x800020 even though my CFG_RESET_ADDR and CFG_EXCEPTION_ADDR are both set much higher. Also more than one item in x830000 - x900000 region. I haven't yet found why these objects are there and or how to fix it.

My ethernet does not work with the default driver, but it is using a 16bit interface so I expected some fixing would be needed there.

Hi tns1,

Glad to hear you have u-boot running on your custom board.

When you say you have only 2 MB ram, and that the size of your u-boot image is

about 384k, I'm guessing you're using your elf file on a ROM-less target with the epcs

bootloader ... correct? Or do you have some (parallel) flash?

Other than relocating itself to TEXT_BASE, the only other code that is copied when

u-boot starts up is the exception trampoline, which is copied to CFG_EXCEPTION_ADDR.

This is a very small piece of code (3 instructions) that simply jumps to the exception handler

(see cpu/nios2/start.S -- "_except_start"). This allows you to set TEXT_BASE

anywhere in RAM (not just at exception address - 0x20).

The u-boot "global data" struct, the heap, and the stack are placed immediately below

TEXT_BASE (see include/configs/PK1C20.h -- CFG_MALLOC_BASE, CFG_SP_INIT, etc).

All of which is configured to be about 128k for the PK1C20.

Other than the above, the only thing that extends below the heap is the stack. So you

shouldn't be seeing any memory use at the base of your ram. If TEXT_BASE is set to

0x009c_0000, for example, you shouldn't see anything (other than the stack) below

say, 0x009a_0000.

What address are you using for TEXT_BASE, and exception/reset?

--Scott