more advice please

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hello everyone,

We are just starting off here and need a little advice, It seems that as
far as a GNU debugger programmer for ARM9 is concerned the OpenOCD
system is the way to go, for this you need a DLC5 Jtag cable or
equivalent, How slow is the DLC5 Jtag cable in practise, is it usable or
will it frustrate me? Does any one have a Gerber file or a eagle board
layout/Schematic for a DLC5 Jtag PCB. I know there are commercial
versions available to purchase such as the ARM-USB-Tiny but I am eager
to get going and live in South Africa where I can find no commercial
system off the shelf to work with OpenOCD. We did purchase a KEIL ULINK2
jtag unit but the cost of the compiler is forcing us to look at other
options. I am fairly certain the KEIL UNLINK2 jtag unit will not
function with OpenOCD.

Are there any other chips that have enough RAM and ROM to host a Linux
kernel?

Any other options I should consider?

Thanks


Jannie

Re: more advice please
I can't comment on your questions, and I have no decent experience with
ARM, but:

Why do you think you need JTAG equipment. As you are on Linux/GNU the
usual way is to preprogram a flash chip with a bootloader (such as
UBOOT) and start the system. Now you can use UBOOT to load a Linux
distribution e.g. via a serial interface.

Of course you need a UBOOT that fits your hardware, but if the hardware
UBOOT is supposed to use is not too non-standard you should be able to
create same without debugging.

AFAIK, a JTAG debugger will not help much when doing Linux application
(user land) software here most developers seem to use code
instrumentation and remote GDB via Ethernet (optionally  controlled by
Eclipse on the PC site).

For Kernel development (and extended driver work) using a JTAG debugger
is said to be helpful in some cases.

-Michael

Re: more advice please
Quoted text here. Click to load it


I understood that the only way to get the ARM boot loader up was via
JTAG, you say pre program a flash chip with the boot loader and then....
how do you get the micro to refer to the flash chip as its reset vector?
Please be patient with us here this is all too new. What type of a flash
chip would this be, a flash card, a serial device, a SPI or I2C device?

Jannie




Re: more advice please
Quoted text here. Click to load it
As I said, I'm not an ARM expert at all, but...

After reset (and no JTAG attached) the chip will boot somehow. It would
not be useful in user devices else :).

AFAIK, many ARM based chips have an internal ROM the reset vector points
to. What happens then depends on that ROM and should be documented with
the chip. The ROM code in an Atmel chip I took a look at scans several
interfaces (maybe it was SPI, Flash-card, USB, Ethernet and UART for
finding bootable attachments).

-Michael

Re: more advice please
On Nov 23, 8:12 am, Michael Schnell
Quoted text here. Click to load it

Most of the ARM7 chips have onboard flash and are meant to be all in 1
micro controllers.  However Jannie seems to say that they use ARM9,
which is a different beast.  From the ARM9 versions I've seen (ATMEL
ARM9 models), they do not have an onboard flash.  What that means is
they will have an internal EEPROM or a "boot time hardware tie-up"
mechanism to select where the bootup code is and where the reset
vector is.  Typical options for boot vector locations will be :
- External flash chip on the local bus
- External chip on the I2C bus
- External chip on the SPI bus
- or hardcoded memory location on local bus
It is a lot of work in trying to get one of these chips up on your
custom board (HW design, Bus delay specs, etc...).  Easiest will be to
get an reference design board/evaluation board from a manufacture
which already have these things done for you.  They will usually
provide a boot loader (UBoot or alike) and a working embedded Linux
distro (such as Denx).  I suggest you play around with such a board
and understand all the HW and SW nitty gritties before attempting to
design your own board.
As Michael says, if you are only doing app level work on a eval board,
you don't need a JTAG.  But I will highly recommend compatible JTAG
device if you are going to build your custom boards, where you need to
boot them up from scratch.

Depending on your application, you may be able to fit your app in a
ARM7 board (which is simpler) using an RTOS rather than Linux.  But if
you want all the bells and whistles, go with Linux.

I personally use the PowerPC chips with Linux, and I am used to them
now after about 1 year of doing things with them.
Cheers
  Janaka

Re: more advice please
Quoted text here. Click to load it

JTAG can be used for debugging , but i do not think that you need to
play so much with the bootloader.
Bootloaders like UBoot and Umon are tooo good that you just need to
put it in the right place in the memory (Fusing in the Flash Memory
at the correct location/sector/segment/block) and link it with the
application by giving the proper entry points / handovers.
Lot of Flash drivers/tools will be available with the Flash Memory
vendors
that can be used for fusing in to the correct/desired location.

You have to configure your Chip Select and do the necessary
flash memory initialisation before transferrring control to the
application(secondary bootloader) present in the Flash Memory.

This Chipselect and Configuration of the Flash Memory can
be done by a small code residing inside the processor's internal
memory. So, after reset this will get executed and it will
transfer control to the Flash Memory's bootloader which inturn
will transfer the control to the application in RAM (This application
can be copied to the RAM from the flash Memory by the secondary
bootloader)

If you do not use any kind of bootloader,
Place the application in the correct place after reset.
In ARM, Reset is at 0x00000000 that will inturn branch to the
application location
or entry point.

If you use Bootloader,
Configure the Application's Entry point correctly(Linker script or by
passing as compile/link time
argument) and make your bootloader to handover
the execution after doing the basic hardware initialisations/MMU to
the application's
entry point.
You can also have the Bootloader to decide between the number of
images
to be loaded into RAM and get executed based on the requirements
present.
and a boot loader provides some protection against a corrupted kernel
image interms
of having some recovery mechanism.

Quoted text here. Click to load it

It all depends on the type of design/cost you are looking for.
In the case of uClinux, you can have either the RAM or Flash Memory
for it to start. It also depends on the type of Filesystem you have
for
the application. If it is Romfs, it is sequenial & readonly in the
Flash and so no
worries for XIP(NOR Flash Memory).But the size is bit large. If you go
for other kind like cramfs,
then, the image will be in compressed format and it is not ideal for
Flash Memory
XIP. There are Flash Memories that have their blocks/segments
specially for
various purposes that can also be helpful to you.


Re: more advice please
Quoted text here. Click to load it

JTAG can be used for debugging , but i do not think that you need to
play so much with the bootloader.
Bootloaders like UBoot and Umon are tooo good that you just need to
put it in the right place in the memory (Fusing in the Flash Memory
at the correct location/sector/segment/block) and link it with the
application by giving the proper entry points / handovers.
Lot of Flash drivers/tools will be available with the Flash Memory
vendors
that can be used for fusing in to the correct/desired location.

You have to configure your Chip Select and do the necessary
flash memory initialisation before transferrring control to the
application(secondary bootloader) present in the Flash Memory.

This Chipselect and Configuration of the Flash Memory can
be done by a small code residing inside the processor's internal
memory. So, after reset this will get executed and it will
transfer control to the Flash Memory's bootloader which inturn
will transfer the control to the application in RAM (This application
can be copied to the RAM from the flash Memory by the secondary
bootloader)

If you do not use any kind of bootloader,
Place the application in the correct place after reset.
In ARM, Reset is at 0x00000000 that will inturn branch to the
application location
or entry point.

If you use Bootloader,
Configure the Application's Entry point correctly(Linker script or by
passing as

compile/link time
argument) and make your bootloader to handover
the execution after doing the basic hardware initialisations/MMU to
the application's
entry point.
You can also have the Bootloader to decide between the number of
images
to be loaded into RAM and get executed based on the requirements
present.
and a boot loader provides some protection against a corrupted kernel
image interms
of having some recovery mechanism.

Quoted text here. Click to load it

It all depends on the type of design/cost you are looking for.
In the case of uClinux, you can have either the RAM or Flash Memory
for it to start. It also depends on the type of Filesystem you have
for
the application. If it is Romfs, it is sequenial & readonly in the
Flash and so no
worries for XIP(NOR Flash Memory).But the size is bit large. If you go
for other kind like
cramfs,
then, the image will be in compressed format and it is not ideal for
Flash Memory
XIP. There are Flash Memories that have their blocks/segments
specially for
various purposes that can also be helpful to you.

Karthik Balaguru

Site Timeline