Programming the ARM chip

[hippy]

RS232 operates at +/-15v so it won't work 'bit-banging' TTL lines.

Often +/-10V from a desktop PC or USB to 9-way D, but I believe the spec allows +/-25V.

Interfacing via current limiting resistor and bit-banging does however work as can be testified by anyone who has done it ( and I'm speaking from experience ). The current limiting resistor and internal clamping diodes ( external if no internal ) allow negative and greater than supply voltages without demonstrably causing damage, and most PC's and RS232 9-way D will accept serial input signals of 0V/3V3.

When I get an R-Pi I intend to have a go at it. I'll be surprised if it doesn't work. It will be the first micro I've used which hasn't worked if it does not.

[Dave_G_2]

@hippy

Using series resistors and clamping diodes does work for receiving RS232 levels and I have also
used it countless times.
However the problem comes in driving the RS232 TX line.
I have come across a few PCs and laptops (yes some do have serial ports) that don't reliably see
3.3V or even 5V logic levels as a proper RS232 level.

[dwelch67]

more typos in the datasheet

page 196, it is an SP804 not AP804
page 197, bit 1, 32 bit counter not 23 bit counter
page 198, they cant both be at 0x40C, neither is 0x40C one is 0x410 the other 0x414

[dwelch67]

I am not seeing 700Mhz on the arm. It is running at or on a par with the 250MHz system clock. Is there a place/register/etc that is used to bump the 250MHz clock or multiply it for the ARM?

[annodomini2]

ALL the USB-RS232 converters are based on the FTDI chipset.

[annodomini2]

I am not seeing 700Mhz on the arm. It is running at or on a par with the 250MHz system clock. Is there a place/register/etc that is used to bump the 250MHz clock or multiply it for the ARM?

What are the PLL settings?

[__----__----__]

ALL the USB-RS232 converters are based on the FTDI chipset.

No they are not, many use the Prolific chipset.
http://www.prolific.com.tw/eng/products.asp?id=59

Many of the available USB to serial converters are based on these and most
Linux distros come with the drivers for them.

From the Prolific website:

NOTE: No need to install drivers for following:
Linux Kernel 2.4.31 and above already includes built-in drivers for PL-2303H, PL-2303XA/HXA and PL-2303HXD.
NOTE: Google Android OS is also based on Linux kernel so it also supports PL2303.

Driver Source:
http://lxr.free-electrons.com/source/dr ... l/pl2303.c
http://lxr.free-electrons.com/source/dr ... l/pl2303.h

Kernel (go to \drivers\usb\serial folder):
http://www.kernel.org/pub/linux/kernel/

Accessing Serial Ports for Android:
http://code.google.com/p/android-serialport-api/

[__----__----__]

I am not seeing 700Mhz on the arm. It is running at or on a par with the 250MHz system clock. Is there a place/register/etc that is used to bump the 250MHz clock or multiply it for the ARM?

Where are you measuring that frequency?

[DexOS]

I am not seeing 700Mhz on the arm. It is running at or on a par with the 250MHz system clock. Is there a place/register/etc that is used to bump the 250MHz clock or multiply it for the ARM?

I think you need to go though the GPU
Because you can change it by a config file read by the GPU.

config.txt: A configuration file read by the GPU. Use this to override set the video
mode, alter system clock speeds, voltages, etc.

http://www.riscosopen.org/forum/forums/ ... 997?page=1

[dwelch67]

I timed a tight loop, two, three, four, etc instructions, a few million loops, with and without instruction cache. With instruction cache it was on a par with 250mips not 700mips. I checked the timers against a watch to understand their properties, counts per second. They match the documented 250mhz system clock.

[dom]

What are the bogomips reported in /proc/cpuinfo?

[jamesh]

Also, what happens when you over clock the CPU using the setting in config.txt? What sort of figures do you then get?

[dwelch67]

What are the bogomips reported in /proc/cpuinfo?

No, not running linux, no overhead, no interrupts to confuse the numbers, mess with the cache, just a handful of instructions in cache, actually counting the instructions being executed...

[dwelch67]

What are the bogomips reported in /proc/cpuinfo?

No, not running linux, no overhead, no interrupts to confuse the numbers, mess with the cache, just a handful of instructions in cache, actually counting the instructions being executed...

What I meant to say is, this was bare metal, something along the lines of

test:
subs r0,r0,#1
bne test

and change the number of subs (to get a feel for the bne time), that kind of thing. No other code, no interrupts, no operating system. instruction cache on and off.

[dwelch67]

There is no JTAG on the Arm - you don't really need JTAG except during board bring up. You can write arm assembler and run it in the Linux environment using GDB as your debugger, which should be more than enough for learning Arm assembler, as should the documentation available - you don't need anything more than the peripheral spec already provided.

All ARM cores have jtag for debugging, certainly ARM11 class cores. This one is no exception.

[dwelch67]

I have the ARM JTAG up and running. Mostly on the P1 connector using jumper wires. One signal is from what I can tell not on P1. I did have to solder a wire on to S5 to get that signal. With a very simple boot program to switch the GPIO pins to their alternate functions you can use jtag to halt and load (bare metal, or other )programs and run them on the ARM. Makes life so much easier...

http://github.com/dwelch67/raspberrypi/ then click on armjtag

[tufty]

I have the ARM JTAG up and running. Mostly on the P1 connector using jumper wires. One signal is from what I can tell not on P1. I did have to solder a wire on to S5 to get that signal. With a very simple boot program to switch the GPIO pins to their alternate functions you can use jtag to halt and load (bare metal, or other )programs and run them on the ARM. Makes life so much easier...

http://github.com/dwelch67/raspberrypi/ then click on armjtag

This is exceptionally cool. Well done.

There is no JTAG on the Arm - you don't really need JTAG except during board bring up. You can write arm assembler and run it in the Linux environment using GDB as your debugger, which should be more than enough for learning Arm assembler, as should the documentation available - you don't need anything more than the peripheral spec already provided.

Oh, come on James. You know better than that. It's been stated numerous times by Gert that JTAG does exist for the ARM, but that it's a bugger to get at (including stuff that's only available via the SD connector).

No, most people won't need it. but David is, like myself, DexOS and numerous others, aiming at something significantly more than that. Something that involves - yep - "board bring up".

Simon

[dwelch67]

What I meant to say is, this was bare metal, something along the lines of

test:
subs r0,r0,#1
bne test

and change the number of subs (to get a feel for the bne time), that kind of thing. No other code, no interrupts, no operating system. instruction cache on and off.

I read up on the config.txt file, which if you are not running from a linux/mounted perspective is actually the root of the fat partition where kernel.img, etc lives. Change or create config.txt and

Code: Select all

arm_freq=200

to change the frequency, the default appears to be 700mhz if you dont have that file or a setting, I expect more than 700million instructions per second but so far I can only get into the 600s

http://stackoverflow.com/questions/1088 ... 7#10904717

http://github.com/dwelch67/raspberrypi bench02 directory

[tufty]

I read up on the config.txt file, which if you are not running from a linux/mounted perspective is actually the root of the fat partition where kernel.img, etc lives. Change or create config.txt and

Code: Select all

arm_freq=200

to change the frequency, the default appears to be 700mhz if you dont have that file or a setting, I expect more than 700million instructions per second but so far I can only get into the 600s

My understanding is certainly that the default is 700Mhz. ISTR it being mentioned on the forum that the default memory mapping on the GPU->ARM MMU was to map the ARM's memory to the 0xCnnnnnnn range on the GPU, which is, as I understand it, uncached. This may have some bearing on matters.

Simon

[dwelch67]

I read up on the config.txt file, which if you are not running from a linux/mounted perspective is actually the root of the fat partition where kernel.img, etc lives. Change or create config.txt and

Code: Select all

arm_freq=200

to change the frequency, the default appears to be 700mhz if you dont have that file or a setting, I expect more than 700million instructions per second but so far I can only get into the 600s

My understanding is certainly that the default is 700Mhz. ISTR it being mentioned on the forum that the default memory mapping on the GPU->ARM MMU was to map the ARM's memory to the 0xCnnnnnnn range on the GPU, which is, as I understand it, uncached. This may have some bearing on matters.

Simon

Yeah, reading up on this split thing (really ruined an afternoon with memory spaces that you could fetch instructions but not do data reads) basically the 256M is shared between the ARM and gpu. Now the L1 cache is inside the ARM core from what I know and my tests were cache based so one time out of a few million it fetched from the shared ram the rest from cache.

[dwelch67]

I read up on the config.txt file, which if you are not running from a linux/mounted perspective is actually the root of the fat partition where kernel.img, etc lives. Change or create config.txt and

Code: Select all

arm_freq=200

to change the frequency, the default appears to be 700mhz if you dont have that file or a setting, I expect more than 700million instructions per second but so far I can only get into the 600s

My understanding is certainly that the default is 700Mhz. ISTR it being mentioned on the forum that the default memory mapping on the GPU->ARM MMU was to map the ARM's memory to the 0xCnnnnnnn range on the GPU, which is, as I understand it, uncached. This may have some bearing on matters.

Simon

Yeah, reading up on this split thing (really ruined an afternoon with memory spaces that you could fetch instructions but not do data reads) basically the 256M is shared between the ARM and gpu. Now the L1 cache is inside the ARM core from what I know and my tests were cache based so one time out of a few million it fetched from the shared ram the rest from cache.

Okay I get it now, it really wants you to start your program at 0x8000. Or lets say it wont load under that, wont load at 0x000 in arms space even with the config.txt setting (will accept addresses larger than that), perhaps because that is the gpu space and at least on boot it is using that space. Who knows. I thought I was loading at 0, was doing absolute addressed data access into my binary, and what I was expecting wasnt there, because it was at address 0x8000+expectation. This means that to build an arm exception table, say to handle interrupts for example you have to build or at least place the instructions after the arm boots, not compiled in the bin at the proper place. Unless there are yet more raspi config.txt tricks I have not found (and dont have much interest in, prefer to use as few backdoor tricks as possible)

[DexOS]

Okay I get it now, it really wants you to start your program at 0x8000. Or lets say it wont load under that, wont load at 0x000 in arms space even with the config.txt setting (will accept addresses larger than that), perhaps because that is the gpu space and at least on boot it is using that space. Who knows. I thought I was loading at 0, was doing absolute addressed data access into my binary, and what I was expecting wasnt there, because it was at address 0x8000+expectation. This means that to build an arm exception table, say to handle interrupts for example you have to build or at least place the instructions after the arm boots, not compiled in the bin at the proper place. Unless there are yet more raspi config.txt tricks I have not found (and dont have much interest in, prefer to use as few backdoor tricks as possible)

dwelch67, you could of saved yourself a lot of work by listening to me, first the config.txt file and now the 0x8000 offset
See here:
http://www.raspberrypi.org/phpBB3/viewt ... 725#p80725
http://www.raspberrypi.org/phpBB3/viewt ... 094#p82094

One word of note, if you do not disable in the config file "disable_commandline_tags" or have no config.txt something is written above 0x8000 not sure what yet, as i have only just got my print code working.
I only found this out because it wrote it to where my background image was stored, if i replace the image with code it crashes.
I will dump it to screen to see what it is.
If you disable "disable_commandline_tags" in the config.txt its not written there.
Also have you played with these setting in the config.txt
"disable_l2cache"
disable arm access to GPU's L2 cache. Needs corresponding L2 disabled kernel. Default is 0.

[dwelch67]

Okay I get it now, it really wants you to start your program at 0x8000. Or lets say it wont load under that, wont load at 0x000 in arms space even with the config.txt setting (will accept addresses larger than that), perhaps because that is the gpu space and at least on boot it is using that space. Who knows. I thought I was loading at 0, was doing absolute addressed data access into my binary, and what I was expecting wasnt there, because it was at address 0x8000+expectation. This means that to build an arm exception table, say to handle interrupts for example you have to build or at least place the instructions after the arm boots, not compiled in the bin at the proper place. Unless there are yet more raspi config.txt tricks I have not found (and dont have much interest in, prefer to use as few backdoor tricks as possible)

dwelch67, you could of saved yourself a lot of work by listening to me, first the config.txt file and now the 0x8000 offset
See here:
http://www.raspberrypi.org/phpBB3/viewt ... 725#p80725
http://www.raspberrypi.org/phpBB3/viewt ... 094#p82094

One word of note, if you do not disable in the config file "disable_commandline_tags" or have no config.txt something is written above 0x8000 not sure what yet, as i have only just got my print code working.
I only found this out because it wrote it to where my background image was stored, if i replace the image with code it crashes.
I will dump it to screen to see what it is.
If you disable "disable_commandline_tags" in the config.txt its not written there.
Also have you played with these setting in the config.txt
"disable_l2cache"
disable arm access to GPU's L2 cache. Needs corresponding L2 disabled kernel. Default is 0.

I wish those things had registered in my mind, I would have saved some time. Learned a bit though, wasnt all pain there is fun to figuring stuff out.

My concern about using config.txt is if I end up with a handful of different config.txt settings I need depending on what program I want to run then either I have to just adopt a policy of 1)always carry a config.txt with a kernel.img or 2) never carry a config.txt with a kernel.img or 3) create one config.txt that I use with every kernel.img I make and load that one one time.

The most distasteful is that their gpu bootloader has all of these knobs to turn, keep it simple, let the programmers build binaries the way they normally build embedded binaries. We dont normally have some pre-processor-boot hardware that wanders about reading ascii files and making changes. We build our binaries the way we want them with atags in the right place the bootloader doing what it is supposed to do, correct addresses, etc. The more closed code they have the more risk for bugs, more risk they are going to muck with things every version, etc, I wish they had taken a keep it simple stupid approach to booting the arm.

ATAGs, yes, they get shoved in somewhere relative to the start (32 kbytes? 64 kbytes, some nice boundary like that if I remember), my programs have been fairly small I must have been lucky. Maybe I should just do what I was planning to do and get it over with, write a program whose kernel.img is big, fills up ram, then have a program sweep ram looking for anything that got modified. (then try this config.txt thing to see if it disables that).

I did not play with the l2 cache disable, I have been avoiding the config.txt file as much as possible. Since I have a couple of benchmark programs might be interesting to just turn it off and see how much worse it gets.

[dwelch67]

My concern about using config.txt is if I end up with a handful of different config.txt settings I need depending on what program I want to run then either I have to just adopt a policy of 1)always carry a config.txt with a kernel.img or 2) never carry a config.txt with a kernel.img or 3) create one config.txt that I use with every kernel.img I make and load that one one time.

I hate what I call the sd card dance:

Code: Select all

1) power off raspi
2) remove sd card
3) insert sd card in reader
4) plug reader into computer
5) mount/wait
6) copy binary file to kernel.img
7) sync/wait
8) unmount
9) insert sd card in raspi
10) power raspi
11) repeat

Any changes to config.txt involve the sd card dance, where changes in the arm program or binary I dont have to touch the sd card I either use jtag or a serial bootloader. I still have to power cycle, but hoping to find a reset solution (was just about to go back to the schematics when I saw your post). either one config.txt that fits all my needs or no config.txt...

[DexOS]

I agree with you dwelch67 and feel your pain, i would go as far as to say if you want to learn bare metal coding chose another Arm, i have worked on a lot of different processors and this one is really a pain.
Code should work or not work, there should be know gray areas.
I read some where that ATAGs start at offset 0x100, but this was for general linux.

As a side note, you do know about the need to "memory barrier"

Code: Select all

MemoryBarrier:
	mcr	p15, 0, ip, c7, c5, 0		@ invalidate I cache
	mcr	p15, 0, ip, c7, c5, 6		@ invalidate BTB
	mcr	p15, 0, ip, c7, c10, 4		@ drain write buffer
	mcr	p15, 0, ip, c7, c5, 4		@ prefetch flush
	mov	pc, lr

When changing between ARM peripheral see page 7 of the BCM2835-ARM-Peripherals.pdf

Accesses to the same peripheral will always arrive and return in-order. It is only when
switching from one peripheral to another that data can arrive out-of-order. The simplest way
to make sure that data is processed in-order is to place a memory barrier instruction at critical
positions in the code.