Flash programmer via ethernet

[Altera_Forum]

Now that I have ethernet working on my custom board, I'd like to use it to update the board, or at least the flash memory. It is mentioned in the existing board kit docs that board updates via http are somehow supported. Etherblaster is also a setting in one of the dialogs. Rather than reinvent the wheel, is there some existing code or feature I missed about this? 

 If I rebuilt the flash programmer project to include ethernet, what else would I need to come up with to make it work?

[Altera_Forum]

All fixed. See 'reset & config revisited' thread.

[Altera_Forum]

I've been following that thread ... great news ... congrats! 

 BTW: in an earlier post you mentioned the 'go bug':  > ==> go 0 ;starts u-boot (the go bug is fixed)   Is this a u-boot bug? If so please let me know so I can add the fix to the source tree.  Thanks, --Scoot

[Altera_Forum]

I had problems with the 'go' cmd in the code you had posted on your site. I thought you mentioned in a post that it did not work. 

Anyway in cmd_boot.c: ...# if !defined(CONFIG_NIOS)  /* old code I could not quite follow. syntax? */  /* rc = ((ulong (*)(int, char *[]))addr) (--argc, &argv[1]); */   /* tkc just need simple function pointer, no args */  ulong (*fnjump)(void) = (ulong (*)(void))addr;  disable_interrupts();   rc = (*fnjump)();# else ...

[Altera_Forum]

Ahhh ... yes ... the jump table for u-boot mini-apps is (still) broken. 

But passing the args should be correct -- I'll check on this. Thanks for the heads-up :-)  Regards, --Scott

[Altera_Forum]

Having some problems getting u-boot up on a new board using the psyent source.  

The symptom is that the u-boot banner and prompt show up, blinking cursor and all, but that's it. It wont accept or echo any chars.  If I simply change the timer irq assignment in the mybd.h file to any other irq (even unassigned ones), then everything works except for the timer dependant functions; irqinfo shows no counting, ethernet stuff doesn't work.  I am certain my address and irq assignments for the timer are correct. I have tested the timer and its irq with a separate piece of code and it is working.   The same basic HW worked with a previous version of u-boot.

[Altera_Forum]

> The symptom is that the u-boot banner and prompt show up, blinking 

> cursor and all ... > If I simply change the timer irq assignment in the mybd.h file to any > other irq (even unassigned ones), then everything works except for the > timer dependant function  Sounds like your system is interrupt bound ... try reducing the the frequency of the timer interrupt. If you're using a full-featured timer, you can set CFG_NIOS_TMRCNT as needed.  Regards, --Scott

[Altera_Forum]

There is some kind of HW problem with the board I was using - not clear exactly what.  

I tried a 2nd board and it worked OK.

[Altera_Forum]

With u-boot on the \f core, it seems the dcache is not invalidated for a flash erase.  

This will cause some confusion when displaying a sector, erasing it, and then displaying it again. 'md' does not bypass dcache, and maybe that is the way it should be, so what is the proper way to handle this?   BTW I do not see any doc details on how dcache is supposed to work - like what is the behavior on read vs write, and what sort of latency before actual HW access in each case. Does cache_bypass macro just bypass or also update cache?  thanks

[Altera_Forum]

> With u-boot on the \f core, it seems the dcache is not invalidated for 

> a flash erase.  u-boot is normally run with data cache disabled. Unfortunately, Nios-II does not provide a mechanism to disable the data cache (as many other processors do). Regardless, commands that affect cache coherency are expected to invalidate/flush the data cache as appropriate if the data cache is enabled ... so you should invalidate the appropriate memory regions in your flash_erase() and write_buff() routines.  > 'md' does not bypass dcache, and maybe that is the way it should be,  Correct.  > so what is the proper way to handle this?  If flash_erase() and write_buff() do not invalidate the affected memory regions, you can just use bit-31 bypass when specifying the address to the 'md' command.  > Does cache_bypass macro just bypass or also update cache?  It simply sets bit 31 of the address ... nothing more. The readx/writex macros (i.e. readb/writeb, readw/writew, etc) should be used when possible rather than CACHE_BYPASS.  Regards, --Scott  BTW: readx/writex are defined in include/asm-nios2/io.h.