RE: [ECOS] Re: Redboot on Assabet (fwd)

[Gary Thomas <gthomas at cambridge dot redhat dot com>]

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 <jco@ict.es>
> To: Nicolas Pitre <nico@CAM.ORG>, 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.