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