Re: [ECOS] ROMRAM on EB55

[Nick Garnett <nickg at ecoscentric dot com>]

Alan Bowman <ABowman@synaptics-uk.com> writes:

> I've connected a Wiggler to the board, and here are my results so far:
> 
> mlt_arm_at91_eb55_romram.ldi contains a line -> SECTION_rom_vectors
> (ram, 0x02008000, LMA_EQ_VMA).  I believe that this is causing the
> ROMRAM image to be linked to run from 0x02008000 upwards.  However,
> in the assembly code in the appropriate hal_platform_setup.h file,
> we mask an address (because at this point we want to point to flash,
> not to RAM).  The code that performs the masking shifts the address
> down in to (pre-remap) flash, but it still points at 0x8000 upwards
> - I need this bit to be removed as well, so it seems that the
> masking code is incomplete.  We then copy some useless area of
> memory into the registers and use it to setup our EBI.
> 
> I have tried changing the .ldi file such that the
> SECTION_rom_vectors is now at 0x02000000 and recompiled.  This
> causes the redboot_ROMRAM image to load correctly, and bring up a
> command prompt, as I would expect.  However, when I use Insight to
> load a RAM image of my application for debugging, it crashes.  I
> presume that I am attempting to load the RAM image over the top of
> Redboot.
>
> There seems to be two alternatives to this problem - change the .ldi
> file for my RAM builds, such that RAM images do not overwrite
> redboot, or to alter the assembly code in hal_platform_setup.h to
> better mask the address that is given in the .ldi file down to the
> correct location.  Which of these is the "correct" way (or is there
> something else that I haven't mentioned)?  Do you think that these
> changes will break other things?


It makes more sense to load the ROMRAM executable at 0x02000000, so
the change to the .ldi file is the right one to use. There also seems
little need to over-complicate the masking code.

One of the problems with these EBXX boards is that they don't have
much RAM. In other targets where we support both ROM and ROMRAM
RedBoots we have just set the load address for RAM applications to be
well above either and waste some space in the ROM case. Usually these
targets have several Mb of RAM so this doesn't matter much. The EBXX
boards only have 256 or 512Mb, so the load address for RAM apps is set
as close as possible to the RAM RedBoot upper limit as possible. This
means that the ROMRAM RedBoot overlaps with RAM apps.

We have therefore not really supported the ROMRAM startup type for
RedBoot, which is why it has fallen into disuse and suffered a bit of
bitrot.

If you want to use the ROMRAM RedBoot, then you will need to raise the
RAM application base address. However, if you are running self-booting
stand-alone applications, then you are probably now in a good position
to go forward.

If you would like to submit a patch (+ChangeLog) I'll be happy to
check it in.

-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com      The eCos and RedBoot experts


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss