baantonia
Posts: 63
Joined: Fri Feb 06, 2015 2:19 pm

Suspicious atags address

Fri Aug 12, 2016 12:50 pm

Hi,

In preparation of trying to read and interpret the atags, I get the following values passed to my main code. I do have intervening code which sets up stacks for the different processor modes but I save off r0, r1 and r2 just below where my image loads with the code:

Code: Select all

mov    sp,   #0x8000
stmfd  sp,  {r0-r2}
I then send the contents of the parameters of my main C code to putty via UART along with the contents starting at the address pointed to by r2. To check I'm passing the parameters which was passed to my kernel image, I have also sent the contents of the 3 words below 0x8000 which was saved with the above code. Looking at other posts in the forums, mine looks very different. Register r0 appears correct with 0x00000000, r1 appears to be correct with 0x00000C42 but r2 is 0x1BFEC700. I am using a compute module if that makes a difference.

r0 param = 0x00000000
r1 param = 0x00000C42
atags param = 0x1BFEC700

Memory locations
0x8000-4 = 0x1BFEC700
0x8000-8 = 0x00000C42
0x8000-12 = 0x00000000

Contents starting from address 0x1BFEC700 (just the first few words)
0xEDFE0DD0
0x75380000
0x38000000
0xC4320000
0x28000000

BrianW
Posts: 83
Joined: Sun Jul 29, 2012 9:03 pm

Re: Suspicious atags address

Thu Aug 25, 2016 9:22 am

Hi,

I notice you're storing R0-R2 on the stack using stmfd sp, {r0-r2}

Generally, you would use stmfd sp!, {r0-r2}

The ! causes the SP register to be updated (in this case, from 0x8000 to 0x7ff4). Without that, the next thing to use the stack will write to 0x7ffc (where your R2 register is stored) rather than free space at 0x7ff0.

I'm guessing that in between storing R0-R2 and retreiving it, you have some function which puts a temporary variable on the stack.

When you come to load the R0-R2 registers back off the stack, you should use ldmfd sp!, {r0-r2}, if you're not already

baantonia
Posts: 63
Joined: Fri Feb 06, 2015 2:19 pm

Re: Suspicious atags address

Thu Aug 25, 2016 9:53 am

Hi BrianW,
Sorry, my bad. The code I posted was incorrect, the code you suggested is in fact what I'm using, but thank you for your response.
Still haven't fathomed that one out.

Currently puzzling over why I cannot seem to get the SPI slave configuration working. I'm thinking of switching to I2C slave and master to link two Pis together, I'm using UART to monitor my bare metal code so that's a no go.

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Suspicious atags address

Fri Aug 26, 2016 11:12 pm

Why are you setting the stack to 0x8000?

That is the load address of a kernel. Below that is normally some other stuff provided by the loader (which I overwrite, as it is useless to me). Though for your system level stack it would make more since to use an area starting some distance past the end of your kernel heap, or near the top of ARM RAM.

That is unless you are using a higher half kernel (where the kernel is mapped to the space between 0xFFFFFFFF - KernelSize and 0xFFFFFFFF.

And what assembler are you using that uses C style designations for hexadecimal? All the ARM assemblers I know of use the form &F00F (using a well known Intel Opcode as example).
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

User avatar
rpdom
Posts: 15184
Joined: Sun May 06, 2012 5:17 am
Location: Chelmsford, Essex, UK

Re: Suspicious atags address

Sat Aug 27, 2016 7:03 am

DavidS wrote:Why are you setting the stack to 0x8000?
Why not?

Using STMFD to store things on the stack would put the first entry at 0x7FFC, then next at 0x7FF8 etc. That won't overwrite the kernel at 0x8000, just the bits which, as you say, is some stuff provided by the loader, and can be safely overwritten.

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Suspicious atags address

Sat Aug 27, 2016 2:02 pm

rpdom wrote:
DavidS wrote:Why are you setting the stack to 0x8000?
Why not?

Using STMFD to store things on the stack would put the first entry at 0x7FFC, then next at 0x7FF8 etc. That won't overwrite the kernel at 0x8000, just the bits which, as you say, is some stuff provided by the loader, and can be safely overwritten.
Well as it is below the kernel, and thus not above the system heap, it is non traditional. And what happens when you decide to protect the lower pages, or relocate them (to protect the vector table, etc)?

I just have the lib loader placed at &8000, and load the kernel at address 0, as the first section of the kernel in my case is the vector table. The loader is left at &8000 so that it can be used to load the rest of the needed libraries, and is treated as part of the kernel. And, no my kernel is not that big, it just gives space to load a lot of extra libraries between the kernel and the lib loader.

The lib loader provides the minimal services for reading and writing the SD, as well as an implementation of FAT32 (that is later overwritten by the FAT32 driver), and the means to load and link dynamic libraries.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

BrianW
Posts: 83
Joined: Sun Jul 29, 2012 9:03 pm

Re: Suspicious atags address

Sat Aug 27, 2016 9:40 pm

DavidS wrote:And what assembler are you using that uses C style designations for hexadecimal? All the ARM assemblers I know of use the form &F00F (using a well known Intel Opcode as example).
GCC's assembler?

Probably most assemblers would use 0x notation.

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Suspicious atags address

Sat Aug 27, 2016 11:23 pm

BrianW wrote:
DavidS wrote:And what assembler are you using that uses C style designations for hexadecimal? All the ARM assemblers I know of use the form &F00F (using a well known Intel Opcode as example).
GCC's assembler?

Probably most assemblers would use 0x notation.
Do not use GNU AS. I use !ObjAsm, !Asm, !ExtAsm, and as (not gnu).
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

baantonia
Posts: 63
Joined: Fri Feb 06, 2015 2:19 pm

Re: Suspicious atags address

Sun Aug 28, 2016 6:58 am

Hi,

I'm used to both GNU and RISCOS assembler so the 0x and & are familiar to me. In fact as I'm trying to communicate between two Pis, one being bare metal and the other running RISCOS I have had to use both notations.

As rpdom said, 0x8000 is being used as a starting point for a full descending stack to save off the atags temporarily while the zero page system vectors are set up and are then retrieved later on.

I could change the registers used in the zero page vector setup process so this temporary stack doesn't need to be used but I don't think the atags address in the register will be any different.

I would like to interpret the atags at some point but at present it's not vital.

My current issue is trying to create a bare metal SPI slave, data gets written into the TX FIFO and eventually fills it with no data being released on the wire to the master. The master is communicating and supplying both data and clock, which is read by the slave.

Curious???

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Suspicious atags address

Tue Aug 30, 2016 5:32 pm

baantonia wrote:Hi,

I'm used to both GNU and RISCOS assembler so the 0x and & are familiar to me. In fact as I'm trying to communicate between two Pis, one being bare metal and the other running RISCOS I have had to use both notations.
Ah. And RISC OS simplifies bare-metal development so much. The assembly language tools we have on RISC OS are so easy to deal with compared to the Unix styled tools of BSD and Linux.
As rpdom said, 0x8000 is being used as a starting point for a full descending stack to save off the atags temporarily while the zero page system vectors are set up and are then retrieved later on.

I could change the registers used in the zero page vector setup process so this temporary stack doesn't need to be used but I don't think the atags address in the register will be any different.
It should be fairly easy to get that far without using the stack, with no trouble at all. If you are not using the stack you have R0,R1, and R3 through R13 to work with, that is 13 registers, just save R14 to a register when making a call, and keep the calls only one level deep until everything is setup (or move down through the top 4 registers before each call, making a sort of register stack).
I would like to interpret the atags at some point but at present it's not vital.
I do not see why. Now all the information in the atags is provided by the mailbox interface from the GPU, and you already need to deal with the mailbox interfaces so why add code for atags?
My current issue is trying to create a bare metal SPI slave, data gets written into the TX FIFO and eventually fills it with no data being released on the wire to the master. The master is communicating and supplying both data and clock, which is read by the slave.

Curious???
Yes, I am.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

baantonia
Posts: 63
Joined: Fri Feb 06, 2015 2:19 pm

Re: Suspicious atags address

Wed Aug 31, 2016 6:39 am

Does anyone have any clues why the SPI slave FIFO doesn't release data, I've been stuck on this for a few weeks and am now seriously considering the slower I2C master/slave route instead.

Return to “Bare metal, Assembly language”