RE: [ECOS] Building stub to AEB1-revC fails

RE: [ECOS] Building stub to AEB1-revC fails

[Andreas.Karlsson]

The board is a revC. I've been using the image that ships with eCos
loaders/arm-aeb/gdb_module-revC.img for 5 months and it still works.

brgds Andreas



> -----Original Message-----
From: Jesper Skov [ mailto:jskov@redhat.com ]
Sent: den 9 november 2000 14:46
To: Karlsson Andre

> as
Cc: ecos-discuss@sourceware.cygnus.com; jlarmour@cygnus.co.uk
Subject: Re: [ECOS] Building stub to AEB1-revC fails




> >>>>> "Andreas" == Andreas Karlsson 

> <Andreas.Karlsson@combitechsystems.com> writes:

> Andreas> Is this a bug? Is there anyone that have succeeded creating a

> Andreas> stub to AEB1-revC? Any hints?

> 

> Is the board actually a rev C? Or is it just a rev B which you add

> extra RAM to?  Rev C differs in other regards than just the amount of

> memory.

> 

> If rev B mode works, adjust the memory map and init code for rev B

> instead of trying to get rev C mode working.

> 

> Jesper

> 

RE: [ECOS] Building stub to AEB1-revC fails

[Jesper Skov]

>>>>> "Andreas" == Andreas Karlsson <Andreas.Karlsson@combitechsystems.com> writes:

Andreas> The board is a revC. I've been using the image that ships
Andreas> with eCos loaders/arm-aeb/gdb_module-revC.img for 5 months
Andreas> and it still works.

No idea then, sorry. Something broke since last release,
probably. Even though I can't imagine what should have broken - there
isn't much difference in the HAL between rev B and C.

Jesper

Re: [ECOS] Building stub to AEB1-revC fails

[Jesper Skov]

>>>>> "Andreas" == Andreas Karlsson <Andreas.Karlsson@combitechsystems.com> writes:

Andreas> I have noticed that in CVS this file is updated and the
Andreas> section reserved_not_mapped is removed, should I remove it
Andreas> also?

Note that it is not just removed. The addressed of SECTION_data is
increased as well.

Jesper

RE: [ECOS] Building stub to AEB1-revC fails

[Andreas.Karlsson]

Hi again,

Well, after a lot of trial and error I'm now able to create the AEB revC
stub and it is working. The change I have to do in the sources form v_1_3_1
is to change mlt_arm_aebC_rom.ldi from:

SECTIONS

{

    SECTIONS_BEGIN

    SECTION_rom_vectors (rom, 0x4018000, LMA_EQ_VMA)

    SECTION_text (rom, ALIGN (0x4), LMA_EQ_VMA)

    SECTION_fini (rom, ALIGN (0x4), LMA_EQ_VMA)

    SECTION_rodata (rom, ALIGN (0x4), LMA_EQ_VMA)

    SECTION_rodata1 (rom, ALIGN (0x4), LMA_EQ_VMA)

    SECTION_fixup (rom, ALIGN (0x4), LMA_EQ_VMA)

    SECTION_gcc_except_table (rom, ALIGN (0x4), LMA_EQ_VMA)

    __reserved_vectors = 0; . = __reserved_vectors + 0x1000;

    SECTION_data (ram, ALIGN (0x4), FOLLOWING (.gcc_except_table))

    SECTION_bss (ram, ALIGN (0x4), LMA_EQ_VMA)

    __reserved_not_mapped = ALIGN (0x4); . = __reserved_not_mapped + 0x7000;

    SECTIONS_END

}

to

SECTIONS

{

    SECTIONS_BEGIN

    SECTION_rom_vectors (rom, 0x4018000, LMA_EQ_VMA)

    SECTION_text (rom, ALIGN (0x4), LMA_EQ_VMA)

    SECTION_fini (rom, ALIGN (0x4), LMA_EQ_VMA)

    SECTION_rodata (rom, ALIGN (0x4), LMA_EQ_VMA)

    SECTION_rodata1 (rom, ALIGN (0x4), LMA_EQ_VMA)

    SECTION_fixup (rom, ALIGN (0x4), LMA_EQ_VMA)

    SECTION_gcc_except_table (rom, ALIGN (0x4), LMA_EQ_VMA)

    __reserved_vectors = 0; . = __reserved_vectors + 0x1000;

    __reserved_not_mapped = 0x1000; . = __reserved_not_mapped + 0x7000;

    SECTION_data (ram, ALIGN (0x4), FOLLOWING (.gcc_except_table))

    SECTION_bss (ram, ALIGN (0x4), LMA_EQ_VMA)

    SECTIONS_END

}

Not knowing that much what I'm doing this seems to work. Now can I start
with getting my expanded memory working by modifying platform_setup I think.

I have noticed that in CVS this file is updated and the section
reserved_not_mapped is removed,  should I remove it also?

/Andreas

RE: [ECOS] Building stub to AEB1-revC fails

[Andreas.Karlsson]

I'm using release v1.3.1

/Andreas



> -----Original Message-----
From: Jesper Skov [ mailto:jskov@redhat.com ]
Sent: den 9 november 2000 15:24
To: Karlsson Andre

> as
Cc: jskov@redhat.com; ecos-discuss@sourceware.cygnus.com;
jlarmour@cygnus.co.uk
Subject: RE: [ECOS] Building stub to A

> EB1-revC fails


>>>>> "Andreas" == Andreas Karlsson 

> <Andreas.Karlsson@combitechsystems.com> writes:

> 

> Andreas> The board is a revC. I've been using the image that ships

> Andreas> with eCos loaders/arm-aeb/gdb_module-revC.img for 5 months

> Andreas> and it still works.

> 

> No idea then, sorry. Something broke since last release,

> probably. Even though I can't imagine what should have broken - there

> isn't much difference in the HAL between rev B and C.

> 

> Jesper

> 

Re: [ECOS] Building stub to AEB1-revC fails

[Jesper Skov]

>>>>> "Andreas" == Andreas Karlsson <Andreas.Karlsson@combitechsystems.com> writes:
Andreas> Is this a bug? Is there anyone that have succeeded creating a
Andreas> stub to AEB1-revC? Any hints?

Is the board actually a rev C? Or is it just a rev B which you add
extra RAM to?  Rev C differs in other regards than just the amount of
memory.

If rev B mode works, adjust the memory map and init code for rev B
instead of trying to get rev C mode working.

Jesper

[ECOS] Building stub to AEB1-revC fails

[Andreas.Karlsson]

Hi,

I had some problem while building a new stub to my AEB-board with expanded
RAM-memory.

So I thought that I firstly had to build a clean stub just see that it
works, it didn't. The funny thing is that it works if I don't change the
options to revC. But when running the stub as revB (128KB RAM instead of
256KB) of course the download fails when passing the 128 KB limit. (I link
with eCos configured for revC)



Jifl asked me if I had tried this with clean code. Ok, I have been playing a
little bit with the sources so:

I installed Linux on a computer (since there is no uuencoder in the cygwin
library, just to eliminate one more possible error source), downloaded and
installed eCos and the tools. Then I followed the manual to create a new
stub:

1. $ ecosconfig new aeb stubs. There where five resolved conflicts.

2. Editing ecos.ecc setting CYGHWR_HAL_ARM_AEB_REVISION to C

3. $ ecosconfig tree

4. $ make 

5. Downloaded the stub to the board as described in the documentation

6. When downloading the program gdb just hangs. Not a single byte is
downloaded.

As when doing this with cygwin tools it all works when I change
CYGHWR_HAL_ARM_AEB_REVISION back to B.

Is this a bug? Is there anyone that have succeeded creating a stub to
AEB1-revC? Any hints?

/Andreas