From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gary Thomas To: Nicolas Pitre Cc: Jordi Colomer , ecos-discuss@sources.redhat.com Subject: RE: [ECOS] Re: Redboot on Assabet (fwd) Date: Thu, 07 Jun 2001 14:14:00 -0000 Message-id: References: X-SW-Source: 2001-06/msg00208.html We've seen some differences with the Assabet - it seems that they are not all "created equal" :-) In particular, the DRAM setup gave me fits. Look in the file hal/arm/sa11x0/assabet/current/include/hal_platform_setup.h you'll see: // DRAM controller initialization dram_table: .word SA11X0_DRAM0_CAS_0, 0xAAAAAA7F .word SA11X0_DRAM0_CAS_1, 0xAAAAAAAA .word SA11X0_DRAM0_CAS_2, 0xAAAAAAAA // .word SA11X0_STATIC_CONTROL_0, 0x4B384B38 // .word SA11X0_STATIC_CONTROL_1, 0x22212419 .word SA11X0_EXP_BUS_CONFIGURATION, 0x994A994A .word SA11X0_REFRESH_CONFIGURATION, 0x49FC0327 .word SA11X0_DRAM2_CAS_0, 0xAAAAAA7F .word SA11X0_DRAM2_CAS_1, 0xAAAAAAAA .word SA11X0_DRAM2_CAS_2, 0xAAAAAAAA // .word SA11X0_STATIC_CONTROL_2, 0x42194449 .word SA11X0_SMROM_CONFIGURATION, 0xAFCCAFCC .word SA11X0_DRAM_CONFIGURATION, 0x72547254 // Disabled .word 0, 0 Perhaps fiddling with these numbers, especially the commented ones, will help. Note: the commented values don't seem to need to be written for the beastie to work, at least no with any of the units we have. On 07-Jun-2001 Nicolas Pitre wrote: > > [ forwarded to the eCos mailing list where the RedBoot development > is happening ] > > ---------- Forwarded message ---------- > Date: Thu, 07 Jun 2001 19:43:53 +0200 > From: Jordi Colomer > To: Nicolas Pitre , linux-arm-kernel@lists.arm.linux.org.uk > Subject: Re: Redboot on Assabet > >> > Hi, >> > >> > I have downloaded and written Nico's Redboot image for the >> > Assabet. Right after the Jflash programming, and even after >> > a reset, Redboot boots up normally, but after a power-up, >> > it doesn't. Not a single character shows up on the terminal. >> >> Don't forget the 38400 baud rate... > > No. It is ok. > >> >> > Using a boundary-scan tester, the pin samples of the >> > StrongArm show that it is continously accessing the first >> > words of the flash (addresses 0x00000010 and 0x0000000C). >> > >> > I can't figure out why it boots after a reset, but not >> > after a power-up. Maybe Redboot is not fully initializing >> > the CPU ? >> >> Can't tell. It works pretty well for me and apparently for others as well. >> Looks strange. Are you sure your hardware is OK? Is your flash socketed? >> > > Well, the assabet works great with a bootldr and a 2.4.3 linux kernel. > The flash does not have a socket. The neponset is not attached. > >> > To restore the Assabet, I must rewrite "bootldr" and then >> > "Redboot" again. >> >> Are you sure RedBoot is correctly flashed? >> > > Yes, it is. I use my own boundary-scan tool (similar to Jflash) to > readback > the contents of the flash into a file. There are no differences with the > original > redboot.bin file. > > Note that RedBoot initially does work ok : I can ping a machine, load > and flash > a file and even reset the assabet. But, when I power the board off and > on, > redboot doesn't run (minicom is still in 38400 baud). The flash still > verifies > against redboot.bin. > > That makes me wonder if there are any registers (?) in the > strongArm/assabet that > are not affected by a CPU reset. Maybe the previous execution of bootldr > initialized them properly , but redboot doesn't. Just an hypothesis... > > Another member in this list reported me that he hasn't faced this > problem with > his assabet. He is using a binary image of redboot compiled by himself > from > older eCos sources. Unfortunately, I cannot use his .ecc file because it > is > too old for my current version of eCos, which was downloaded last > tuesday. > > On the other hand, I cannot rebuild redboot using your .ecc file > because the 'cpp' of the arm-elf toolchain returns a "too many input > files" > error. If I use the Netwinder toolchain, objcopy generates a huge binary > file > padded with zeroes from 0x00000000 to 0x50000000 (the virtual address of > the > flash). > > Jordi Colomer.