more advice please

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

Reply to
Jannie du Preez
Loading thread data ...

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

Reply to
Michael Schnell

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

Reply to
Jannie du Preez

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

Reply to
Michael Schnell

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

Reply to
Janaka

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.

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.

Reply to
karthikbalaguru

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.

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

Reply to
karthikbalaguru

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.