RE: Queston about Walnut

quoted

I would suggest inspecting the timings for memory access.
If this is SDRAM, you must have had to program the UPM for
it, I suppose. Might be that VxWorks has it right, and you
have set it up differently.

Also, writing to address 0 might be a Bad Ideam (tm), if you
have set this area to hold interrupt vectors.

Did you try single write (say, "mw 100000 0") ?

    Thanks for you suggestion. Not only single write, I can
now write to anywhere except the first 1MB of SDRAM. I think
it is occupied by u-boot?

Possibly, but you should check that for yourself. There is
documentation on what u-boot does to RAM upon power-on.

So, I think memory is ok now.

Seems right.

    Do you have any idea it hangs at __sti()?

As I said, I know next to nothing about the Walnut. My own
embedded uboot/Linux experience is as follows:

I had a 855T-based custom board, so I took u-boot, duplicated
the TQM855L-specific files into a custom directory *and checked
every single setting* against my own hardware. Once u-boot
started OK on my board, Linux followed almost without trouble.

Only problems were with a weird bootup IMMR address setting
(settled by modifying u-boot's startup code) and FEC MII
interrupt mishandling (settled by careful option setting in
the kernel).

You should ensure that you have access to both software (u-boot
and Linux) *and* hardware (both PPC and your board) resources.

HTH,

Albert.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/