Flash programmer via ethernet

Scott,

My system has the same 8MB flash device as the PK1C20 at 0x0, and 2MB sram at 0x800000. My HW has already been fully tested under uCos, and I thought the bootloader functions would be a nice addition.

The download image is the same size (90KB) as the PK1C20 consuming 2 sectors of flash. The ram usage described in the CFG settings is roughly: 128K of relocated code, 64K of env space, 128K of heap, plus whatever stack space say 64K. This all adds up to 384K of RAM in rough numbers. I was saying sectors before, but of course this is ram so it is not quite so bad. The code does not fill up the entire 128K, and the stack wont use up the entire 64K. Probably closer to 300K actual ram use. If I am missing something, let me know.

I have not burned u-boot into my flash on this board. I have download u-boot over jtag to get it running, but have been unable to use u-boot to download an image of itself for flashing because this step crashes.

My TEXT_BASE is 0x9D0000, so I would expect no u-boot use below 0x9A0000 (256K). When I do a mw.b for the memory from 0x800000 to 0x9D0000, u-boot crashes (locks) apparently because I am writing over some parts it is actively using. There are two regions. First, I see three long words at 0x800020 that I verified with objdump are the trampoline instructions you mentioned, but writing over them causes u-boot to either reset, lockup or stop working correctly (depends on which one I write over). If I understand the trampoline, it is only using during relocation, and it should&#39;t matter what happens to that memory afterwards. Also my <myboard>.h file I created defines CFG_EXCEPTION_ADDR to be x900020. Isn&#39;t this where the trampoline should be?

Likewise there is a region from x8cfa00 - x8d0000 (~1500 bytes) that seems to be a critical area of some kind. When I try to write over this region I get a lockup. A subsequent download and md shows this region to be unchanged as if it were .data or vector table. Lots of xdeadbeef entries in the region.

Hmm.. I don&#39;t think I am getting a good build. I see some inconsistent behavior. The prompt doesn&#39;t appear after the splash screen when I re-download after a crash as if u-boot were not inited properly.

Some things I have changed:

TEXT_BASE 0x9D0000

CFG_RESET_ADDR 0x900000

CFG_EXCEPTION_ADDR 0x900020

CFG_NIOS_TMRMS 1

base addresses for uarts etc are different in general

I started with u-boot 1.1.2 src.

If I change the first three to 0x900000, 0x800000, 0x800020 I get more consistent behavior, but I still cant use the lower memory.

BTW the netconsole stuff appears to be just stubs.

Hi tns1,

> When I do a mw.b for the memory from 0x800000 to 0x9D0000, u-boot crashes (locks)

> apparently because I am writing over some parts it is actively using.

Yes, you&#39;re overwriting the stack and the heap.

> First, I see three long words at 0x800020 that I verified with objdump are the trampoline

> instructions you mentioned, but writing over them causes u-boot to either reset, lockup or

> stop working correctly (depends on which one I write over).

If this is the case, your exception address is probably 0x800020. When the timer interrupt

fires and the exception is taken, the core executes corrupted code.

> Also my <myboard>.h file I created defines CFG_EXCEPTION_ADDR to be x900020. Isn&#39;t this

> where the trampoline should be?

There are two critical macros that must be correct in your config file: CFG_RESET_ADDR and

CFG_EXCEPTION_ADDR. These _must_ match your hardware configuration (cpu settings in SOPC builder).

The u-boot build process is not very sophisticated -- this is good and bad. The good part is that it&#39;s

simple -- you only need a shell and the cross-development tools to build it -- no interactions with an

IDE, etc -- you can edit & control the whole process with a text editor. The bad part is, well ...

it&#39;s simple ;-) so it won&#39;t automagically update the config file for you (or warn you) when your config

file doesn&#39;t match your actual hardware.

> If I understand the trampoline, it is only using during relocation, and it should&#39;t matter what

> happens to that memory afterwards.

Correct. The trampoline gets copied to CFG_EXCEPTION_ADDR when u-boot relocates itself.

This allows u-boot to stored at the reset address (e.g. flash) or any other arbitrary address.

When u-boot begins execution, it copies itself to TEXT_BASE (ram) and jumps to the relocated

u-boot image. After a few more initializations (e.g. clearing bss, etc), u-boot checks to see if the

trampoline is at the proper exception address. If it&#39;s not, it copies the trampoline to

CFG_EXCEPTION_ADDR. The trampoline code does nothing more than jump to u-boot&#39;s

exception handler.

NOTE: In some cases, the trampoline does not need to be copied. This would be the case

when TEXT_BASE is set to the exception address minus 0x0020 -- since the trampoline code is

conveniently located at the start address + 0x0020 it&#39;s already where it needs to be.

> If I change the first three to 0x900000, 0x800000, 0x800020 I get more consistent behavior,

Yes, this makes sense. This would indicate that your actual hardware configuration has the

exception address set to 0x80_0020. BTW: the "irqinfo" command shows the timer interrupt

count. The count should be incrementing if everything is operating ok.

> but I still cant use the lower memory.

I had a similar problem since I mapped the low-end of SDRAM into a PCI window. When the

host cleared the memory, my core would basically lock up once the timer interrupt fired.

(It would simply execute jmp 0). The solution was to define a small section of on-chip

RAM (0x40 bytes) and set the exception address to offset 0x20 in this memory. This kept

SOPC builder happy, and prevented the host from trashing my interrupts ;-)

> I have been unable to use u-boot to download an image of itself for flashing because this

> step crashes.

I believe this is all related -- the downloaded image is probably corrupting the trampoline,

the heap, or the stack. Based on your ealier comments, you&#39;re probably downloading to

0x80_0000 for subsequent copy into flash. This overwrites the trampoline and causes a

crash once the timer interrupt fires.

> My HW has already been fully tested under uCos, and I thought the bootloader functions

> would be a nice addition.

Absolutely ... and I&#39;ll do my best to help you get there :-) Once things are stable, I think you&#39;ll

really enjoy the more "interesting" features like cramfs/jffs2 support and scripting.

Try the following:

1. Add some on-chip memory and set the exception address to offset 0x20 in the memory.

2. Update you config file with the actual reset/exception addresses from SOPC builder.

3. Rebuild u-boot and strip the elf.

4. Determine the actual u-boot size using objdump and set TEXT_BASE appropriately.

5. Rebuild.

Hope this helps,

--Scott

PS:

> I discovered that once you have built, you cannot copy the source tree to another

> folder and rebuild.

use &#39;make distclean&#39; prior to copying the source tree -- it should remove any absolute

path references. In the new tree you&#39;ll have to make xxx_config again though.

OK, now that I understand things better I have it flashed and running. I&#39;ve added the map info to the bdinfo cmd like so:

==> bdinfo

flash start = 0x00000000

flash size = 0x00800000

flash offset= 0x00000000

sram start = 0x00800000

sram size = 0x00200000

ethaddr = 01:00:00:00:00:00

ip_addr = 192.168.1.113

baudrate = 115200 bps

reset addr = 0x00000000

except addr = 0x00800020

monitor size= 0x00020000

monitor base= 0x009D0000

heap size = 0x00030000

heap base = 0x009A0000

env size = 0x00010000

env base = 0x009A0000

globals size= 0x00000080

globals base= 0x0099FF80

stack top = 0x0099FF80

==>

Of course now that I have it working I&#39;ll probably never need the info http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/wink.gif

My ram is free from 800100 to at least 99F000

Now to get the ethernet working.

Scott,

Got the ethernet up. On my custom board the lan chip is wired up differently than the kit; 16bit interface but with registers on word boundaries. Apparently the same as existing ADNPESC1 configuration.

Now I can ping and tftpboot. One quirk is that tftpboot hangs after the download. It does not report the bytes transferred or return to a prompt. By resetting and doing a cmp, I can tell the download was correct and proceed to burning flash. The same thing also happens with loadb, so its not an ethernet problem. I dont get the prompt back with loads either. I am using an offset of 801000 and image sizes too small to collide with anything.

On the kit board I did not have these problems. Any ideas?

You mentioned the timer earlier. I had originally set CFG_NIOS_TMRMS to 1 thinking I had to match the default hw. I changed it back to 10 after reading the comments.

thanks again

Solved it.

Since I have no cache at all, I had set all the cache CFG macros to 0. This will cause cache_flush routine to hang. I set the macros back to the PK1C20 defaults and all the downloads finish properly. I guess it does not matter that I have no cache.

As far as I can tell, u-boot is working on both boards now. If anyone you would like the mods for the DK1S10(NiosII), let me know.

Great to hear everything is working now. So now you play with scripting. E.g. --

automatically attempt an NFS download and execute the download on success,

otherwise jump into flash ;-)

Some notes:

> I had originally set CFG_NIOS_TMRMS to 1 thinking I had to match the default hw.

The timer stuff can be confusing. The two most important macros are:

cfg_nios_tmrms -- number of milliseconds between each timer interrupt.

cfg_hz -- the frequency of the timer interrupt.

The two are of course redundant, but they&#39;re both defined to encourage using the

preprocessor for divide/multiply where possible.

Sine the Nios timer may be configured with/without the period registers, another

macro, cfg_nios_tmrcnt is used. If this macro is defined, the value is

written into the timer&#39;s period registers when u-boot starts, but is otherwise

never referenced. If the macro is not defined, the period registers are never

accessed, period. The intent of CFG_NIOS_TMRCNT is to allow users to slow down

the interrupt rate when the period is programmable. A 1 ms rate is (normally)

overkill in a boot monitor.

Since I have a tendency to misplace the decimal point, I use the sleep command

to do a sanity check. Try for example, "sleep 10" while looking at your watch ;-)

BTW: the timer macros are (indirectly) used by most of the network protocol

modules, and by the flash programming code.

>I guess it does not matter that I have no cache.

Correct, the cache instructions behave as NOP when no cache is configured -- so

the bogus instructions do little more than add an unnecessary delay loop when they&#39;re

left in the code.

After downloading, u-boot invalidates the region that was loaded (both data and

instruction caches) to ensure everything is coherent.

For my custom board, I finally got around to putting u-boot and my C application both in the flash. With just u-boot in the flash, it would start up when the board was powered. With both in the flash, my app starts up instead - not what I expected.

My flash is 0x0 to 0x800000. My sram is 0x800000 to 0xA00000. My reset vector is 0x0. My exception vector is 0x800020.

u-boot is flashed at 0x0 and linked to run at 0x9d0000. My app image is flashed at 0x400000 and linked with the default NiosII bootstrap to run at 0x800000. I used u-boot to flash both images and verify the locations (not the IDE flash programmer), so I they should be where I think they are.

The u-boot boot process seems to be start.S -> board_init() -> main_loop(). As far as I can tell, when I power cycle my board board_init() is never reached and my app is loaded and executed instead. If I erase the section of flash where my app resides, then u-boot begins normally again. I don&#39;t see anything in start.S that would explain this behavior. Somehow it is jumping to some location below the app image in flash (0x400000) and above the u-boot image in order to invoke the app bootstrap routine.

To test, I load u-boot over jtag and made sure to clear sram before my tests so I am not accidentally re-executing previously loaded code. I can then try one of:

==> go 0 ;starts u-boot (the go bug is fixed)

==> reset ;starts u-boot

(power cycle) ;app starts

==> go 400000 ;app starts

I see that u-boot has all kinds of options related to autobooting of images, but I don&#39;t think they are enabled. I should at least get to main_loop() and see some u-boot prompt before this happens anyway. I&#39;ve a few more things to try before I gut my project to make room for the hw debugger, but would appreciate any insight.

Hi tns1,

> I can then try one of:

> ==> go 0 ;starts u-boot (the go bug is fixed)

> ==> reset ;starts u-boot

> (power cycle) ;app starts

> ==> go 400000 ;app starts

This looks like your reset address is set to 0x40_0000. If &#39;go 0&#39; and &#39;reset&#39;

correctly starts u-boot (they&#39;er basically the same) ... then a POR with the

reset address set to 0 will behave identically. Better double-check your

config in SOPC builder ... or better, your ptf file reset_slave/reset_offset.

You might want to try flashing the app at 0 and u-boot 0x40_0000 as well.

> I should at least get to main_loop() and see some u-boot prompt before

> this happens anyway.

Agreed ... that&#39;s why I don&#39;t think the u-boot entry point is being called at all

for POR.

BTW: Did you move to Quartus 4.2? Or are you still at 4.1? I haven&#39;t installed

the upgrade yet ... too close to finishing a job ;-)

Regards,

--Scott

I am sticking with Q4.2 and NiosII1.01 until the dust clears.

SOPC says my reset address is in flash at 0x0 with offset 0x0.

The ptf agrees with this.

CPU_RESET_ADDRESS is 0x0,

reset_slave = "flash/s1";

reset_offset = "0x00000000";

The board is working HW and has displayed no flakeyness while running, but POR is always special.

I have created a stripped down project that includes the fs2 module which should allow me to step thru the flashed start.S.

This required moving from the e core to the s core so now I have a cache to think about. I am hoping I will see an incorrect

jump early in the code to explain this behavior. If the bug only occurs for a real power cycle and not a soft reset, I wont see it in the

debugger and will instead have to probe the buses directly. I don&#39;t have debug headers for these buses - any signaltap gurus out there?

I&#39;ll have to make sure to disable cache so all cycles are visible.

I&#39;ll swap the code locations as you suggest before I dive in.