UBoot

Altera_Forum · ‎03-17-2005

Hi All,

Seems I'm posting every day so apologies and bare with me.

Has anyone encountered behaviour with UBoot such that it will boot from SDRAM but

not from FLASH?

I've downloaded an image file (using dhcp) into SDRAM say at 0x01100000

If I do an iminfo on that memory address it reports back okay,

If I do a bootm from that location it loads up (to location 0x01000000) and executes

correctly.

Now I take the image and program it into flash (protect off/ erase/ cp) and put the image

at location 0. When I look it is there fine, a compare says it is identical to the SDRAM copy,

yet when I try and execute that version with bootm 0 It just stalls and never enters the code.

Short of setting up the debug kernel has anyone any suggestions?

Regards,

...

Altera_Forum · ‎03-17-2005

Hmm well sorted,

At the final call stage there was a print statement, somehow that was causing the

cpu to hang just before the kernel call.

strange but hey ho.

Altera_Forum · ‎03-18-2005

> when I try and execute that version with bootm 0 It just stalls and

> never enters the code.

use the 'go' command -- bootm is for booting a u-boot image file

(e.g. linux kernel). So bootm will/should never work. E.g:

==> go 0

Regards,

--Scott

Altera_Forum · ‎03-18-2005

Yep, and the image was a UBoot image file made with mkimage http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/wink.gif

It just seems that the code is unhappy to hand off to the new code although the problem appears to have gone away now I'm keeping an eye open.

I'm wondering if there is some issue with the ICACHE not being properly cleared after the call to kernel() is executed.

Regards,

Altera_Forum · ‎03-18-2005

> Yep, and the image was a UBoot image file made with mkimage

Duh ... it's been a long week 8-P ... not sure where my brain was ...

my apologies for adding confusion.

Regards,

--Scott

Altera_Forum · ‎03-21-2005

On the continuing voyage with UBoot and Nios.....

Can anyone suggest a possible cause for the following:

Monday morning, start up, UBoot runs but fails to autoboot into the main app.

Try running uboot manually and executing bootm 0, app fails to run,

Try power cycling and generally playing around in a similar way a few times, no success.

Download the target app directly from NIOS IDE, it works fine,

try uboot again doesn't work.

power cycle the board, uboot now runs it..

Try downloading the app via dhcp and reflashing it, all works okay, try bootm 0, no success, however if I try bootm from the dhcp target download location it works?!.

This goes on in a similar vain and has been doing it all day (I've checked for overheat/timing problems with the old can of freezer spray but no joy).

It just seems that sometimes in the final call to kernel() in do_linux_bootm nothing happens and I don't know why.

Frankly I'm a bit stumped how to even debug this otherwise working board, has anyone got any suggestions?

Regards,

...

Altera_Forum · ‎03-21-2005

hi cybdenw,

A few questions:

Which Nios-II flavor are you using ... II/e, II/s, II/f ?

Are you booting from flash, on-chip memory, or epcs_controller?

Are you sharing pins between flash & sdram?

When bootm fails, do you see a CRC error message?

Also, if autoboot or manual bootm fails, what does 'imi 0' report?

Regards,

--Scott

Altera_Forum · ‎03-22-2005

Hi Scott,

Okay i'm using a II/f

I'm booting from EPCS (see all the numerous other threads http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/wink.gif !! )

UBoot is in the EPCS, it , as far as I can tell, comes up cleanly. Certainly all the

prompts/commands seem to work so I don't think it's corruption there. (Although

of interest I did get a couple of times an illegal instruction trap inside uboot but that

went away and hasn't returned).

UBoot is copied into the high end of SDRAM,

My application comes from FLASH at location 0, obviously therefore the flash and sdram ram

pins are separate (basically it's a cyclone dev board). It gets copied into the bottom of SDRAM replacing the uboot exception trampoline. I've manually, and correctly, relocated the .entry section of the app from what would have been epcs base to SDRAM base, so that the instruction cache is initialised correctly. Like I say though it is weird in that it sometimes works and othertimes not.

When bootm fails it just hangs, sits there and does the knitting! http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/wink.gif , no error messages

of any sort.

If I do an iminfo on location 0 it checks out fine, CRC is all good etc.

Additionally if I remove the final call to kernel() in do_bootm_linux and do a cmp.b

between the SDRAM data and my image (+ 0x40 to allow for the image header) it all

checks out as correct, i.e. it was copied correctly.

I'm wondering if it is a cache problem with the data cache (containing the copied

instructions) not being flushed before calling?

Altera_Forum · ‎03-22-2005

Think I've sorted it,

It does seem to be down to the cache not flushing before jumping to the newly relocated code.

Basically, I've defined in the board.h file

<CODE># define __HAVE_ARCH_MEMMOVE# define __HAVE_ARCH_MEMCPY

</CODE>

and then implemented my own assembler versions of these two functions in cache.s

and all seems to be good now. The assembler version incorporate the explicit dcache flush code as per the altera software manual page 7-5 on each byte moved. It's little bit cumbersome but seems to work fine. (If anyone has a similar problem and needs the code please email me)

thanks everyone.

Altera_Forum · ‎03-22-2005

Hi cybdenw,

> It does seem to be down to the cache not flushing before jumping

> to the newly relocated code.

Ok ... then this is a bug in u-boot that needs fixing. The code in

the common tree _should_ take care of flushing the data cache

AND invalidating the instruction cache for the bootm target address

range (as it does for commands like loadb) ... but I sure can't find it

anywhere 8-/

I'll contact the main u-boot maintainers for some guidance on how to

proceed ... a board port shouldn't have to worry about this ... it should

be handled in the architecture-specific code.

Thanks for tracking this down :-)

Regards,

--Scott