MICROBLAZE: Using external instruction memory

Hi all,

I'm trying to design a Microblaze system which uses an external SRAM
as instruction memory. I'm using the V2MB1000 board from Insight Memec
with P160 Communication module.

The SRAM is conected to Microblaze through an external memory
controller conected to the Instruction side OPB bus.
The thing is that I don't know how to save my "executable.elf" file to
the external SRAM.
I've seen other microprocessors that firstly they copy the program
from flash or another Read Only storage device to a faster memory,
such as SRAM. They use a boot program, stored in FLASH, to do this.

But in my system I don't know neither how to save it to the FLASH
because my program is too large and it can't be stored in the Block
RAMs.

I'll very grateful if someone could help me.

Thanks a lot.

Arkaitz.

Hi Arkaitz,

You can always download the executable to the external memory from the
host using the xmd tool.

G�ran

Arkaitz wrote:

> Hi all,
>
> I'm trying to design a Microblaze system which uses an external SRAM
> as instruction memory. I'm using the V2MB1000 board from Insight Memec
> with P160 Communication module.
>
> The SRAM is conected to Microblaze through an external memory
> controller conected to the Instruction side OPB bus.
> The thing is that I don't know how to save my "executable.elf" file to
> the external SRAM.
> I've seen other microprocessors that firstly they copy the program
> from flash or another Read Only storage device to a faster memory,
> such as SRAM. They use a boot program, stored in FLASH, to do this.
>
> But in my system I don't know neither how to save it to the FLASH
> because my program is too large and it can't be stored in the Block
> RAMs.
>
> I'll very grateful if someone could help me.
>
> Thanks a lot.
>
> Arkaitz.

you create a small flash loader that you use to program your flash,
then you run your programs from flash. optionally you may copy to sram
but it in your case I think it doesnt make sense.

the flash loader is not a problem, but for programs that are then executed
from flash you need to use custom linker script and optionally copy
some segments to sram, also you should use sram for stack and heap,
as the blockrams get low for that too.

if you have not done that before it will take you approx 2 weeks to get
fully it runnging and set up.

antti



agaztelu@ikerlan.es (Arkaitz) wrote in message news:<b79e7ab9.0309160241.3eef5362@posting.google.com>...
> Hi all,
> 
> I'm trying to design a Microblaze system which uses an external SRAM
> as instruction memory. I'm using the V2MB1000 board from Insight Memec
> with P160 Communication module.
> 
> The SRAM is conected to Microblaze through an external memory
> controller conected to the Instruction side OPB bus.
> The thing is that I don't know how to save my "executable.elf" file to
> the external SRAM.
> I've seen other microprocessors that firstly they copy the program
> from flash or another Read Only storage device to a faster memory,
> such as SRAM. They use a boot program, stored in FLASH, to do this.
> 
> But in my system I don't know neither how to save it to the FLASH
> because my program is too large and it can't be stored in the Block
> RAMs.
> 
> I'll very grateful if someone could help me.
> 
> Thanks a lot.
> 
> Arkaitz.

Hi Antti,

I've done a flash loader but I don't know which file do I have to
store in flash in order to enable to execute it.

I've proved storing the "executable.elf" file which contains the
crt0.o initialization code linked and then I jump to that address from
a program stored in the Block RAMS, but as I supposed it doesn't work.

So may be I'm wrong but what I have in mind is to have a program
stored in flash and then store a simple program in the Block RAMs
where there is only a branch to the flash base address.

What do you think about this and how would it be done?

Thanks a lot,

Arkaitz.


antti@case2000.com (Antti Lukats) wrote in message news:<80a3aea5.0309160942.23beb3dd@posting.google.com>...
> you create a small flash loader that you use to program your flash,
> then you run your programs from flash. optionally you may copy to sram
> but it in your case I think it doesnt make sense.
> 
> the flash loader is not a problem, but for programs that are then executed
> from flash you need to use custom linker script and optionally copy
> some segments to sram, also you should use sram for stack and heap,
> as the blockrams get low for that too.
> 
> if you have not done that before it will take you approx 2 weeks to get
> fully it runnging and set up.
> 
> antti
> 
> 
> 
> agaztelu@ikerlan.es (Arkaitz) wrote in message news:<b79e7ab9.0309160241.3eef5362@posting.google.com>...
> > Hi all,
> > 
> > I'm trying to design a Microblaze system which uses an external SRAM
> > as instruction memory. I'm using the V2MB1000 board from Insight Memec
> > with P160 Communication module.
> > 
> > The SRAM is conected to Microblaze through an external memory
> > controller conected to the Instruction side OPB bus.
> > The thing is that I don't know how to save my "executable.elf" file to
> > the external SRAM.
> > I've seen other microprocessors that firstly they copy the program
> > from flash or another Read Only storage device to a faster memory,
> > such as SRAM. They use a boot program, stored in FLASH, to do this.
> > 
> > But in my system I don't know neither how to save it to the FLASH
> > because my program is too large and it can't be stored in the Block
> > RAMs.
> > 
> > I'll very grateful if someone could help me.
> > 
> > Thanks a lot.
> > 
> > Arkaitz.

Hi Arkaitz,

arkaitz wrote:
> I've done a flash loader but I don't know which file do I have to
> store in flash in order to enable to execute it.
> 
> I've proved storing the "executable.elf" file which contains the
> crt0.o initialization code linked and then I jump to that address from
> a program stored in the Block RAMS, but as I supposed it doesn't work.

you must use mb-objdump utility to convert the elf file into an 
executable binary image.  elf files themselves cannot be directly 
executed, they must be loaded, have the relocations resolved, etc etc. 
You want something like:

mb-objcopy -O binary --remove-section=.stab --remove-section=.stabstr 
executable.elf executable.bin

The --remove-section options are specifying not to copy debug string 
information into the final binary.

Then, once you have your executable.bin file - that is the code you want 
to place into flash, prior to being copied into RAM for execution.

This is how kernel images for microblaze uClinux (and most other uClinux 
ports) are done.

Regards,

John

John Williams wrote:
> Hi Arkaitz,
> 
> arkaitz wrote:
> 
>> I've done a flash loader but I don't know which file do I have to
>> store in flash in order to enable to execute it.
>>
>> I've proved storing the "executable.elf" file which contains the
>> crt0.o initialization code linked and then I jump to that address from
>> a program stored in the Block RAMS, but as I supposed it doesn't work.
> 
> 
> you must use mb-objdump utility to convert the elf file into an 
                 ^^^^^^^^^

oops I meant objcopy of course!

Thanks John,

Now, where can I find some information related to the "elf" extension
file? If I'm not wrong it's used in Linux, isn't it?

Just another question: I've been looking to the MicroBlaze's manual
but I haven't found anything about "mb-objcopy". Is it in the manual?

Thanks again for your help.

Arkaitz.

John Williams <jwilliams@itee.uq.edu.au> wrote in message news:<bm207h$4b3$2@bunyip.cc.uq.edu.au>...
> John Williams wrote:
> > Hi Arkaitz,
> > 
> > arkaitz wrote:
> > 
> >> I've done a flash loader but I don't know which file do I have to
> >> store in flash in order to enable to execute it.
> >>
> >> I've proved storing the "executable.elf" file which contains the
> >> crt0.o initialization code linked and then I jump to that address from
> >> a program stored in the Block RAMS, but as I supposed it doesn't work.
> > 
> > 
> > you must use mb-objdump utility to convert the elf file into an 
>                  ^^^^^^^^^
> 
> oops I meant objcopy of course!

arkaitz wrote:
> Thanks John,
> 
> Now, where can I find some information related to the "elf" extension
> file? If I'm not wrong it's used in Linux, isn't it?

Yes - it's the standard object file format used by Gnu-based compilers (GCC)

> Just another question: I've been looking to the MicroBlaze's manual
> but I haven't found anything about "mb-objcopy". Is it in the manual?

No - it's just part of the gnu tools distributed in EDK.  Get a login on 
a linux box and do "man objcopy" - mb-objcopy is just the cross-platform 
version.  mb-objcopy --help will probably tell you something too.

www.gnu.org has an excellent documentation section - lots and lots of 
details about the linkers and compilers and so on - since mb-gcc and 
friends are direct descendants, 99.99% of that info is still highly 
relevant and useful.

Regards,

John

Thanks a lot.

But, I don't understand how can I execute an "elf" file that affects
only to the internal registers of MicroBlaze enabling the timer,
interrupts, etc. but when I create a "hello world" program which
contains only a "print" code-line it doesn't work.

Have you done a flash programmer. How have done it? Via XMD or Serial?

Thanks again.

John Williams <jwilliams@itee.uq.edu.au> wrote in message news:<bm30hp$fto$1@bunyip.cc.uq.edu.au>...
> arkaitz wrote:
> > Thanks John,
> > 
> > Now, where can I find some information related to the "elf" extension
> > file? If I'm not wrong it's used in Linux, isn't it?
> 
> Yes - it's the standard object file format used by Gnu-based compilers (GCC)
> 
> > Just another question: I've been looking to the MicroBlaze's manual
> > but I haven't found anything about "mb-objcopy". Is it in the manual?
> 
> No - it's just part of the gnu tools distributed in EDK.  Get a login on 
> a linux box and do "man objcopy" - mb-objcopy is just the cross-platform 
> version.  mb-objcopy --help will probably tell you something too.
> 
> www.gnu.org has an excellent documentation section - lots and lots of 
> details about the linkers and compilers and so on - since mb-gcc and 
> friends are direct descendants, 99.99% of that info is still highly 
> relevant and useful.
> 
> Regards,
> 
> John

arkaitz wrote:
> Thanks a lot.
> 
> But, I don't understand how can I execute an "elf" file that affects
> only to the internal registers of MicroBlaze enabling the timer,
> interrupts, etc. but when I create a "hello world" program which
> contains only a "print" code-line it doesn't work.

don't forget you need to link your executable in "executable" mode, not 
xmdstub.

then, once you run make (or generate from the xps), in the directory 
<myproject>/microblaze0/code will be a file executable.elf - that's the 
one you run objcopy over.

> Have you done a flash programmer. How have done it? Via XMD or Serial?

i started with xmd-based routines (they are still up on my website 
somewhere, i think under downloads), but now that uclinux is pretty much 
done, and i have network support i copy new images directly over the 
network into the flash, just using standard linux tools (NFS mounting, 
dd, MTD flash drivers and so on).  For small systems this might not me 
an option.

http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux

Regards,

John


> 
> Thanks again.
> 
> John Williams <jwilliams@itee.uq.edu.au> wrote in message news:<bm30hp$fto$1@bunyip.cc.uq.edu.au>...
> 
>>arkaitz wrote:
>>
>>>Thanks John,
>>>
>>>Now, where can I find some information related to the "elf" extension
>>>file? If I'm not wrong it's used in Linux, isn't it?
>>
>>Yes - it's the standard object file format used by Gnu-based compilers (GCC)
>>
>>
>>>Just another question: I've been looking to the MicroBlaze's manual
>>>but I haven't found anything about "mb-objcopy". Is it in the manual?
>>
>>No - it's just part of the gnu tools distributed in EDK.  Get a login on 
>>a linux box and do "man objcopy" - mb-objcopy is just the cross-platform 
>>version.  mb-objcopy --help will probably tell you something too.
>>
>>www.gnu.org has an excellent documentation section - lots and lots of 
>>details about the linkers and compilers and so on - since mb-gcc and 
>>friends are direct descendants, 99.99% of that info is still highly 
>>relevant and useful.
>>
>>Regards,
>>
>>John


-- 
Dr John Williams, Research Fellow,
Reconfigurable Computing, School of ITEE
University of Queensland, Brisbane, Australia
Ph : (07) 3365 8305