Programming the ARM chip


135 posts   Page 3 of 6   1, 2, 3, 4, 5, 6
by tufty » Sat May 19, 2012 3:41 pm
That looks about right. I'm not sure why you're worried about this 20K thing, though. Some sort of tool failure?

You will probably need to put the reset vector in its own named section, rather than leaving it in the .text section - that way you can ensure (via your linker script) that it's the very first thing in the finalised binary.

Simon
Posts: 1367
Joined: Sun Sep 11, 2011 2:32 pm
by DexOS » Sat May 19, 2012 5:00 pm
Dave_G_2 wrote:Been doing some more reading and if the reset vector is at 0x0000000 then ignoring interrupts
and stack etc for now, then won't simple code like this work as a starting point?
Once this is working then support for INTS and Fast INTS, STACK etc can be added.

Code: Select all
format binary
org     0x00000000
use32

; -------------------------------------------------------
; Vector table, only _RESET used for now
; others added after this confirmed
; to work.
; -------------------------------------------------------

Start:
   b   RealStart
   b   EndlessLoop
   b   EndlessLoop
   b   EndlessLoop
   b   EndlessLoop
   b   EndlessLoop
   b   EndlessLoop
   b   EndlessLoop

; -------------------------------------------------------
; For now, IRQ's, etc not used so
; simply go into endless loop or even
; toggle a GPIO pin every second.
; -------------------------------------------------------

EndlessLoop:

   b   EndlessLoop

; -------------------------------------------------------
The "kernel" will start here.
; -------------------------------------------------------

RealStart:

; kernel code here
; for example the DexOS Uart code.

; -------------------------------------------------------
; DATA and variables go here.
; As a basic start, we have no stack so
; variables can be used to store each of
; the 32 registers plus an extra for the
; PC register.
; -------------------------------------------------------

align 4
VAR_R0    dw 0x0
VAR_R1    dw 0x0
VAR_R2    dw 0x0
VAR_R3    dw 0x0

; etc etc

VAR_PC     dw 0x0

align 4
; -------------------------------------------------------
; Just pack the progam out, but as long as your program
; is at least 20k, you should not need this.
; -------------------------------------------------------

times 20000- ($-Start)  db 0



The disassembly as follows:

Code: Select all
Start:

0x00000000   ea000007   b   loc_24 ; (start of vector table)
0x00000004   ea000005   b   loc_20
0x00000008   ea000004   b   loc_20
0x0000000c   ea000003   b   loc_20
0x00000010   ea000002   b   loc_20
0x00000014   ea000001   b   loc_20
0x00000018   ea000000   b   loc_20
0x0000001c   eaffffff   b   loc_20 ; (end of vector table)

EndlessLoop:

0x00000020         loc_20: 
0x00000020   eafffffe   b   loc_20

RealStart:

0x00000024         loc_24:  ("kernel" code would normally follow)

DataSection

0x00000024   00000000   andeq   r0, r0, r0 ; (ignore as it's data for VAR_R1)
0x00000028   00000000   andeq   r0, r0, r0 ; (ignore as it's data for VAR_R2)
0x0000002c   00000000   andeq   r0, r0, r0 ; (ignore as it's data for VAR_R3)
0x00000030   00000000   andeq   r0, r0, r0 ; (ignore as it's data for VAR_R4)
       etc etc


Obviously this wouldn't make for a very useful OS.
It's meant only as a start off point.

Yes that would be fine has a starting point, i would just add a loop after RealStart for now just in case some one try to run it as is.
Batteries not included, Some assembly required.
User avatar
Posts: 860
Joined: Wed May 16, 2012 6:32 pm
by DexOS » Sat May 19, 2012 5:15 pm
tufty wrote:That looks about right. I'm not sure why you're worried about this 20K thing, though. Some sort of tool failure?

You will probably need to put the reset vector in its own named section, rather than leaving it in the .text section - that way you can ensure (via your linker script) that it's the very first thing in the finalised binary.

Simon

He's using FasmARM, assembling as BIN file, there's no need for a linker with fasm (Flat asm) ;).
Its so simple, no need for tool chains, linkers, scripts etc.
\fasmArm myfile.asm myfile.bin or img etc then <enter>

Fasms less than 100k, keep a copy in every folder of your code, simple.

.text section and that are for file layouts needed by the OS, we have no OS.
Batteries not included, Some assembly required.
User avatar
Posts: 860
Joined: Wed May 16, 2012 6:32 pm
by Dave_G_2 » Sat May 19, 2012 5:38 pm
tufty wrote:That looks about right. I'm not sure why you're worried about this 20K thing, though. Some sort of tool failure?


DexOS mentioned it in his code, and as he is much more experienced then me, I assumed it's a valid
minimum limit.

tufty wrote:You will probably need to put the reset vector in its own named section, rather than leaving it in the .text section - that way you can ensure (via your linker script) that it's the very first thing in the finalised binary.


It's a "flat" binary (not elf) so there are no .text, .bss or .data sections.
If you look at the disassembly, you will see that the vectors are in the right place.

@DexOS
Yep you are right, using FASMARM so no linker scripts required.
User avatar
Posts: 196
Joined: Sat Apr 14, 2012 7:04 pm
by Morgaine » Sat May 19, 2012 6:50 pm
I'm very happy to see people start with bare-metal programming on the Pi. The fact that the VideoCore isn't available for register-level programming isn't fatal, only annoying at worst. You can still do pretty much everything else you need to do with the ARM1176JZFS and the rest of the peripherals.

What's more, this is very important given the educational goals of the project. Linux device drivers don't write themselves, somebody has to write them, and the Pi makes a very nice target for such experimental driver work, which is always bare metal.

And finally, if someone wants to write a new O/S based on different principles to Linux, all power to them. There may be a new Linus Torvalds in the making. :)

Morgaine.
Intolerance is a failure of education. Education is predicated on tolerance of the uneducated.
User avatar
Posts: 141
Joined: Mon Mar 12, 2012 1:13 am
by DexOS » Sat May 19, 2012 7:14 pm
This is what the basic start code should be, from the little info available.
Code: Select all
format binary
org     0x00000000
use32

; -------------------------------------------------------
; Vector table, only _RESET used for now
; others added after this confirmed
; to work.
; -------------------------------------------------------

Start:
   b   RealStart
   b   EndlessLoop
   b   EndlessLoop
   b   EndlessLoop
   b   EndlessLoop
   b   EndlessLoop
   b   EndlessLoop
   b   EndlessLoop

; -------------------------------------------------------
; For now, IRQ's, etc not used so
; simply go into endless loop or even
; toggle a GPIO pin every second.
; -------------------------------------------------------

EndlessLoop:

   b   EndlessLoop
; -------------------------------------------------------
; For now, IRQ's, etc not used so
; simply go into endless loop or even
; toggle a GPIO pin every second.
; -------------------------------------------------------

times 0x8000- ($-Start)  db 0 ; this may be needed (that the offset for linux kernels)

; -------------------------------------------------------
; The "kernel" will start here.
; -------------------------------------------------------

RealStart:
   b   RealStart
; kernel code here
; for example the DexOS Uart code.

; -------------------------------------------------------
; DATA and variables go here.
; As a basic start, we have no stack so
; variables can be used to store each of
; the 32 registers plus an extra for the
; PC register.
; -------------------------------------------------------

align 4
VAR_R0    dw 0x0
VAR_R1    dw 0x0
VAR_R2    dw 0x0
VAR_R3    dw 0x0

; etc etc

VAR_PC     dw 0x0

; -------------------------------------------------------
; Just pack the progam out, but as long as your program
; is at least 20k, you should not need this.
; ADD above instead.
; -------------------------------------------------------
                                                     

I have found some info including "screen buff address", but still need to test this for real.
I will post more tomorrow, when i have done more studying of available info.
And finally, if someone wants to write a new O/S based on different principles to Linux, all power to them. There may be a new Linus Torvalds in the making. :)

@Morgaine:
I coded this OS:
http://www.youtube.com/watch?v=mYJx2zZK7c8
But 10 yeas to late :cry:
Batteries not included, Some assembly required.
User avatar
Posts: 860
Joined: Wed May 16, 2012 6:32 pm
by Dave_G_2 » Sat May 19, 2012 7:34 pm
DexOS wrote:I have found some info including "screen buff address" [....]


0xC000000 ?
I wonder if for text it's similar to the old VGA layout, 2 bytes per character?
One byte for the ascii code and the other for the attributes.
User avatar
Posts: 196
Joined: Sat Apr 14, 2012 7:04 pm
by DexOS » Sat May 19, 2012 8:07 pm
Dave_G_2 wrote:
DexOS wrote:I have found some info including "screen buff address" [....]


0xC000000 ?
I wonder if for text it's similar to the old VGA layout, 2 bytes per character?
One byte for the ascii code and the other for the attributes.


I think it will be more a case of drawing the fonts pixel by pixel eg: letter A
00#00
0#0#0
#####
#000#
0 = do not draw pixel, just increase one pixel
# = draw pixel ( text color)

This is a basic example, we will write function and use fonts data of right size, at first the fonts will just be 0 & 1 s
Batteries not included, Some assembly required.
User avatar
Posts: 860
Joined: Wed May 16, 2012 6:32 pm
by Dave_G_2 » Sat May 19, 2012 8:12 pm
DexOS wrote:
I think it will be more a case of drawing the fonts pixel by pixel eg: letter A
00#00
0#0#0
#####
#000#
0 = do not draw pixel, just increase one pixel
# = draw pixel ( text color)

This is a basic example, we will write function and use fonts data of right size, at first the fonts will just be 0 & 1 s


Simple pixel map style, makes sense.
User avatar
Posts: 196
Joined: Sat Apr 14, 2012 7:04 pm
by DexOS » Sat May 19, 2012 8:23 pm
Dave_G_2 wrote:
DexOS wrote:
I think it will be more a case of drawing the fonts pixel by pixel eg: letter A
00#00
0#0#0
#####
#000#
0 = do not draw pixel, just increase one pixel
# = draw pixel ( text color)

This is a basic example, we will write function and use fonts data of right size, at first the fonts will just be 0 & 1 s


Simple pixel map style, makes sense.

This is just a guess, as that how its usually done under bare metal arm (unlike x86 bios)

I PM you some more info.
Batteries not included, Some assembly required.
User avatar
Posts: 860
Joined: Wed May 16, 2012 6:32 pm
by Dave_G_2 » Sat May 19, 2012 8:39 pm
Thanks DexOS, got it.
User avatar
Posts: 196
Joined: Sat Apr 14, 2012 7:04 pm
by Morgaine » Sun May 20, 2012 2:27 am
DexOS wrote:@Morgaine:
I coded this OS:
http://www.youtube.com/watch?v=mYJx2zZK7c8
But 10 yeas to late :cry:

Well done DexOS. Just watched it and pushed your Youtube counter to a really nice number for counters, 555. :P

Morgaine.
Intolerance is a failure of education. Education is predicated on tolerance of the uneducated.
User avatar
Posts: 141
Joined: Mon Mar 12, 2012 1:13 am
by hippy » Sun May 20, 2012 7:40 pm
__----__----__ wrote:Can gcc produce straight binary (compiled) ARM bytecode which would run as is much like NASM? (i.e. no elf headers, relocation code, bss,data & code sections) Otherwise it would just compile it to standard Linux elf which is not much good for a bare metal setup.

mole125 wrote:Presumably if it can produce the linux kernel which runs from bare metal (give or take a bootloader) then it can build an alternative 'kernel' running a specific bare metal application?

This seems to be a good guide on what's needed, or at least a starting point, though having never done it before I don't know how easy or not it will be. Wish me luck ...

http://www.eetimes.com/design/embedded/ ... ng-Started
Posts: 774
Joined: Fri Sep 09, 2011 10:34 pm
by tufty » Sun May 20, 2012 7:47 pm
__----__----__ wrote:Can gcc produce straight binary (compiled) ARM bytecode which would run as is much like NASM? (i.e. no elf headers, relocation code, bss,data & code sections) Otherwise it would just compile it to standard Linux elf which is not much good for a bare metal setup.


It's fine. You build and link as usual, producing (as you correctly surmise, an ELF file), and then there's an extra step of running objcopy to extract the binary.

Assuming you're running an arm-none-eabi toolchain and your output file is called kernel.elf, your command line will look like this
Code: Select all
arm-none-eabi-objcopy -O binary kernel.elf kernel.img


Simon
Posts: 1367
Joined: Sun Sep 11, 2011 2:32 pm
by annodomini2 » Fri May 25, 2012 1:48 pm
Another option are the LPCxpresso boards, ~£20 ($30), integrated JTAG, free IDE, programming tools etc.

DIP fitting to attach peripherals or breadboard work.
Posts: 33
Joined: Sun Feb 05, 2012 12:00 am
by annodomini2 » Fri May 25, 2012 1:58 pm
One thing of note though, ARM has several instruction sets, depending on the architecture you are working on.

If you're looking for embedded, look at Cortex-mx stuff, 3+ preferably as this more current than the old ARM7TDMI setups.

The Cortex-Ax stuff is more mobile and home appliance friendly, but dev boards are hard to come by.
Posts: 33
Joined: Sun Feb 05, 2012 12:00 am
by dwelch67 » Sat May 26, 2012 6:05 pm
Got my (first) raspberry pi yesterday

http://github.com/dwelch67/raspberrypi

I have just started a set of bare metal arm programming examples for the rpi. Quite disappointed that the arm jtag is not easier to get to. If nothing else a very small kernel.img that changes gpio pins to alternate function of arm jtag then from there let jtag take over for development. Much more reliable and easier and pain free than having to power off, pull the sd card, put the sd card in a reader, plug the reader in, wait/mount, copy a file, wait/sync, eject, remove reader, remove card from reader, plug card in rpi, power rpi. repeat.

With jtag you are looking at

> halt
> load_image myprog.elf
> resume

Jtag for arm is under $50 now, easy to come by. Cheaper if you live in europe (well I assume the amontek jtag-tiny is very nice but doubles in price with shipping to the US).

And once you type those commands once, then it is three up arrows enter, three up arrows enter, three up arrows enter, to retry. Occasionally power cycle.

Are the board layouts available with more trace information than the elinux.org wiki page? Not just pins and pads but vias and traces?

Unfortunately the gpio lines selected dont all go to external pins. I think everything can be gotten at, G12 and 13 and 26 are no connects. ARM_TMS, ARM_TCK, and ARM_TDI. but you can get TMS on CAM_GPIO which might be a challenge to solder to, even to remove that connector, will see. TCK on GPIO25 which goes to P1 and TDI on GPIO4 which goes to P1 as well, so TMS is the stumbling block.

Interesting looking at this schematic, two dedicated jtag headers, presumably for board manufacture/bring up but no header for arm development. At least routing to holes without populating would have been nice.

If the uart works I should have a bootloader up and running before long, avoiding the painful 27 step development test procedure. (developing on this board feels like the 1990s or 1980s or older, pulling a through hole part out of a socket and putting it into a zif socket based programmer, although that was fewer steps). Hmmm, a virtual sd card, connected to the computer would work, or perhaps something dual ported if there is such a thing. Is it documented how the GPU accesses the sd card (isnt there a serial mode and parallel mode for sd cards, something like that?)?

Dont get me wrong I do very much like this idea of (presumably) non-brickable arm program loaded into ram and release reset model. I have paid much much more for similar projects, had to wait months/years, and been thourougly dissapointed. My open pandora failed within minutes (after waiting well over a year), and with the turnaround time on the repair I finally told them to just keep the unit and money as a donation to the cause, I never checked to see if they kept the money. The Raspberry Pi though, wow, nothing I have bought at any price has come up that easily.

Is it possible to have on the download page an sd card image that is light weight and doesnt have linux basically, just the files needed to get the GPU to grab and use kernel.img....
Posts: 414
Joined: Sat May 26, 2012 5:32 pm
by Dave_G_2 » Sat May 26, 2012 6:41 pm
dwelch67 wrote: Is it documented how the GPU accesses the sd card (isnt there a serial mode and parallel mode for sd cards, something like that?)?


I doubt it very much for two reasons:

1) Broadcom are very touchy about the GPU.
2) SD cards have 2 modes, a slower SPI mode and a closed (much faster) propriety mode.

dwelch67 wrote:Is it possible to have on the download page an sd card image that is light weight and doesnt have linux basically, just the files needed to get the GPU to grab and use kernel.img....

A good point as now one has to download the whole distro (480MB) just to use start.elf.
User avatar
Posts: 196
Joined: Sat Apr 14, 2012 7:04 pm
by tufty » Sat May 26, 2012 7:10 pm
Dave_G_2 wrote:
dwelch67 wrote: Is it documented how the GPU accesses the sd card (isnt there a serial mode and parallel mode for sd cards, something like that?)?

I doubt it very much

IIRC, the SD card access is via a macrocell on the ARM side. IP from Arasan (although I don't know which particular version), with a couple of minor Broadcom mods, I believe. The datasheet / programmer's manual for this is, unfortunately - ahem - "hard to come by", so it's down to reverse-engineering the Linux code for us non-linuxers. Not fun.

Start here : https://github.com/raspberrypi/linux/bl ... -bcm2708.c

Edit - page 65 of the datasheet says it's Arasan SDIO 3.0 eMMC v4.4

dwelch67 wrote:Is it possible to have on the download page an sd card image that is light weight and doesnt have linux basically, just the files needed to get the GPU to grab and use kernel.img....

https://github.com/raspberrypi/firmware ... aster/boot should do it for you.
Last edited by tufty on Sat May 26, 2012 7:20 pm, edited 1 time in total.
Posts: 1367
Joined: Sun Sep 11, 2011 2:32 pm
by Dave_G_2 » Sat May 26, 2012 7:13 pm


Ahha, forgot about that. :oops:
User avatar
Posts: 196
Joined: Sat Apr 14, 2012 7:04 pm
by Dave_G_2 » Sat May 26, 2012 7:16 pm
tufty wrote:IIRC, the SD card access is via a macrocell on the ARM side.


macrocell as in cplds?
User avatar
Posts: 196
Joined: Sat Apr 14, 2012 7:04 pm
by johnbeetem » Sat May 26, 2012 8:34 pm
Dave_G_2 wrote:
tufty wrote:IIRC, the SD card access is via a macrocell on the ARM side.

macrocell as in cplds?

My guess:
No, macro cell as in ASIC design, specifically a "hard macro" that Broadcom licenses from the company that designed it. Much more complex than a CPLD macro cell.
User avatar
Posts: 942
Joined: Mon Oct 17, 2011 11:18 pm
Location: The Coast
by Dave_G_2 » Sat May 26, 2012 8:58 pm
johnbeetem wrote:My guess:
No, macro cell as in ASIC design, specifically a "hard macro" that Broadcom licenses from the company that designed it. Much more complex than a CPLD macro cell.


A more likely scenario is that it's designed by Broadcom themselves and manufacture is outsourced
to a company such as TSMC or UMC that do OEM for fabless companies such as Broadcom which
then create/compile the required firmware using MetaWare or similar.
User avatar
Posts: 196
Joined: Sat Apr 14, 2012 7:04 pm
by dwelch67 » Sat May 26, 2012 9:42 pm
I am struggling to turn off the pull down for GPIO14 and 15 (UART). from the diagram in the docs it implies that pull up/down are indpendent of function/alternate function. is that correct? If I have switched to the alternate function for the GPIO do I need to modify the pull up/down?

What I am doing

1) write a 0 to GPPUD of disable pull up/down
2) wait a bit, 500 or so arm cycles
3) write GPUDCLK0 with bits 14 and 15 set
4) wait a bit
5) write to GPPUDCLK0

GPPUD is already zero does it need to be written again?

Whatever I am doing is hanging the ARM. I dont have jtag yet but have isolated the problem to the above...
Posts: 414
Joined: Sat May 26, 2012 5:32 pm
by dwelch67 » Sat May 26, 2012 10:01 pm
And getting hangs talking to the mini-uart. I write a 0x1 to the AUX_ENABLES then try to write to the control register in the mini uart and that appears to cause a hang. Am I missing something?
Posts: 414
Joined: Sat May 26, 2012 5:32 pm