Flash programmer via ethernet

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

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

...

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

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.

> 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

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.

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

> 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.