YuiPark
Posts: 1
Joined: Sat Apr 02, 2016 2:45 pm

Act LED (hello world)' Programming on RPi 3 (BCM2837)

Thu Apr 21, 2016 12:05 am

I am currently trying to learn how to control the on board LEDs of RPi 3 first and other low level peripherals after.

I know there are some good tutorials regarding this topic: Baking Pi and Bare Metal Programming in C Pt1. However, as far as I know they are targeting RPi 2 and documentation for BCM2837 is not available. Due to these reasons I find it is very difficult to proceed and feel stuck.

Having said that, I would like to ask some questions please:

1. Are there other resources which I can read about and can help me go forward?
2. What are the usual steps which follow LED control practice, for hardware programming?
3. In this thread, the user gregeric commented "On the Pi3B the red & green LEDs are no longer connected to bcm GPIOs; instead they are driven from an i2c GPIO expander: U20 located near the DSI connector." If this is the case for RPi 3, how can I program I2C GPIO expander, to control on board LEDs?

I know these are novice questions, but I seek guidance please. Any help would be appreciated!

dwelch67
Posts: 835
Joined: Sat May 26, 2012 5:32 pm

Re: Act LED (hello world)' Programming on RPi 3 (BCM2837)

Thu Apr 21, 2016 6:01 pm

you are not the only one trying to find that led. in theory it is on a gpio expander on i2c. there are examples in this forum that use a mailbox to ask the gpu to do it for you.

David

User avatar
MarkHaysHarris777
Posts: 1820
Joined: Mon Mar 23, 2015 7:39 am
Location: Rochester, MN
Contact: Website

Re: Act LED (hello world)' Programming on RPi 3 (BCM2837)

Thu Apr 21, 2016 6:18 pm

YuiPark wrote:I am currently trying to learn how to control the on board LEDs of RPi 3 first and other low level peripherals after.
The on-board LEDs are not meant to be controlled by the user... the red LED is a power indicator, while the green LED is an SD card read|write activity indicator. The activity light used to be tied to the GPIO; this is no longer the case. It wasn´t really useful on the 2B either; because, the system would use it as an activity light and it would blink out after being set.

It would be useful (in future versions of the PI board) if there were three or four dedicated on-board LEDs (red, green, yellow, blue) under user control via programming; similar to the pyboard, or the Arduino board. I realize that its a matter of cost; just saying.

That said, its easy to have an off-board LED ... test bed; its one miniature bread board, one resistor, one LED, two jumper wires (female-->male) and some python. (this is where I would start)
marcus
:ugeek:

jahboater
Posts: 1868
Joined: Wed Feb 04, 2015 6:38 pm

Re: Act LED (hello world)' Programming on RPi 3 (BCM2837)

Thu Apr 21, 2016 6:33 pm

The on-board LEDs are not meant to be controlled by the user... the red LED is a power indicator, while the green LED is an SD card read|write activity indicator.
They were rather good on the Pi2 ...

Code: Select all

pi@raspberrypi:/sys/class/leds/led0 $ cat trigger
none [mmc0] mmc1 timer oneshot heartbeat backlight gpio cpu0 cpu1 cpu2 cpu3 default-on input 

hippy
Posts: 2252
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Act LED (hello world)' Programming on RPi 3 (BCM2837)

Thu Apr 21, 2016 6:40 pm

This is bare metal so having a LED to flash is a good way to show the code is (mostly) correct, has compiled, and is working.

Having an on-board LED takes out all the uncertainty that it is the LED and related circuit and wiring at fault when it doesn't flash; if it works when booted with Raspbian it should work when moving to bare metal.

tgritchie
Posts: 19
Joined: Fri Jun 01, 2012 4:07 pm
Location: United Kingdom

Re: Act LED (hello world)' Programming on RPi 3 (BCM2837)

Sat Apr 23, 2016 2:08 pm

YuiPark wrote: 3. In this thread, the user gregeric commented "On the Pi3B the red & green LEDs are no longer connected to bcm GPIOs; instead they are driven from an i2c GPIO expander: U20 located near the DSI connector." If this is the case for RPi 3, how can I program I2C GPIO expander, to control on board LEDs?
Further into this thread there is a snippet of assembler which does just this albeit using the FASMARM syntax. It is relatively straightforward to translate it to the GNU assembler - I have just done it myself :) The code is AIUI extracted from a much larger project by Arjan van Vught. Rst's Circle OS (https://github.com/rsta2/circle) also does a splendid job of dealing with this and much more of the differences between the various Pi models by using the object-oriented approach of C++

Trevor

ahnjoan
Posts: 3
Joined: Wed Apr 27, 2016 6:52 pm

Re: Act LED (hello world)' Programming on RPi 3 (BCM2837)

Wed Apr 27, 2016 6:54 pm

Trevor - If you are able to turn the RPi3 red LED off, would you please post how you do it?

Ahnjoan

tgritchie
Posts: 19
Joined: Fri Jun 01, 2012 4:07 pm
Location: United Kingdom

Re: Act LED (hello world)' Programming on RPi 3 (BCM2837)

Tue May 03, 2016 7:49 pm

ahnjoan wrote:Trevor - If you are able to turn the RPi3 red LED off, would you please post how you do it?

Ahnjoan
As I said before the code is available further into the quoted post but here it is anyway :-)

Code: Select all

; format binary as 'img'
format ELF as 'elf'

org    $0000

; Return CPU ID (0..3) Of The CPU Executed On
      mrc p15,0,r0,c0,c0,5    ; R0 = Multiprocessor Affinity Register (MPIDR)
      ands r0,3 	      ; R0 = CPU ID (Bits 0..1)
      bne CoreLoop	      ; IF (CPU ID != 0) Branch To Infinite Loop (Core ID 1..3)

      mov    sp, #0x8000
      bl      LedInit
Boucle:
      bl      LedOn
      mov    r0, #500
      bl      Delay
      bl      LedOff
      mov    r0, #500
      bl      Delay
      b      Boucle

CoreLoop: ; Infinite Loop For Core 1..3
  b CoreLoop

      align   16
Request:
      dw      0x1c
      dw      0
      dw      0x00040010
      dw      4
      dw      0
      dw      0
      dw      0

pLed:	dw	0
pBal:	dw	0x3f00b880
pHtr:	dw	0x3f003004
LedInit:
      push   {r0, r1, lr}
      ldr    r1, [pBal]
LedInit1:
      ldr    r0, [r1, #0x18]
      ands   r0, #0x80000000
      bne    LedInit1
      adr    r0, Request + 8
      str    r0, [r1, #0x20]
LedInit2:
      ldr    r0, [r1, #0x18]
      ands   r0, #0x40000000
      bne    LedInit2
      ldr    r0, [Request + 0x14]
      bic    r0, #0xc0000000
      str    r0, [pLed]
      pop    {r0, r1, pc}


LedOn:
      push   {r0, r1, lr}
      ldr    r1, [pLed]
      ldr    r0, [r1]
      add    r0, #0x00010000
      str    r0, [r1]
      pop    {r0, r1, pc}


LedOff:
      push   {r0, r1, lr}
      ldr    r1, [pLed]
      ldr    r0, [r1]
      add    r0, #0x00000001
      str    r0, [r1]
      pop    {r0, r1, pc}

Delay:
;      r0 = mS
      push   {r0, r1, r2, lr}
      mov    r1, #1000
      mul    r0, r1
      ldr    r1, [pHtr]
      ldr    r2, [r1]
Delay1:
      ldr    r3, [r1]
      sub    r3, r2
      cmp    r3, r0
      blo    Delay1
      pop    {r0, r1, r2, pc}
This is for the FASMARM assembler though - not everyone's cup of tea but easy enough to convert to GNU assembler

Trevor

eunwoo
Posts: 1
Joined: Fri Aug 18, 2017 2:47 pm

Re: Act LED (hello world)' Programming on RPi 3 (BCM2837)

Fri Aug 18, 2017 2:56 pm

Hello,

I've got RPi3 and am running test on ACT led.
I converted the assembly into the arm assembler(as) version which is shown below.

Code: Select all

.globl _start
_start:
@; Return CPU ID (0..3) Of The CPU Executed On
      mrc p15,0,r0,c0,c0,5    @; R0 = Multiprocessor Affinity Register (MPIDR)
      ands r0,#3 	      @; R0 = CPU ID (Bits 0..1)
      bne CoreLoop	      @; IF (CPU ID != 0) Branch To Infinite Loop (Core ID 1..3)

      mov    sp, #0x8000
      bl      LedInit
Boucle:
      bl      LedOn
      mov    r0, #500
      bl      Delay
      bl      LedOff
      mov    r0, #500
      bl      Delay
      b      Boucle

CoreLoop: @; Infinite Loop For Core 1..3
  b CoreLoop

      .align   4
Request:
      .int      0x1c
      .int      0
      .int      0x00040010
      .int      4
      .int      0
      .int      0
      .int      0

pLed:	.int	0
pBal:	.int	0x3f00b880
pHtr:	.int	0x3f003004
LedInit:
      push   {r0, r1, lr}
      ldr    r1, pBal
LedInit1:
      ldr    r0, [r1, #0x18]
      ands   r0, #0x80000000
      bne    LedInit1
      adr    r0, Request + 8
      str    r0, [r1, #0x20]
LedInit2:
      ldr    r0, [r1, #0x18]
      ands   r0, #0x40000000
      bne    LedInit2
      ldr    r0, Request + 0x14
      bic    r0, #0xc0000000
      str    r0, pLed
      pop    {r0, r1, pc}


LedOn:
      push   {r0, r1, lr}
      ldr    r1, pLed
      ldr    r0, [r1]
      add    r0, #0x00010000
      str    r0, [r1]
      pop    {r0, r1, pc}


LedOff:
      push   {r0, r1, lr}
      ldr    r1, pLed
      ldr    r0, [r1]
      add    r0, #0x00000001
      str    r0, [r1]
      pop    {r0, r1, pc}

Delay:
;      r0 = mS
      push   {r0, r1, r2, lr}
      mov    r1, #1000
      mul    r0, r1
      ldr    r1, pHtr
      ldr    r2, [r1]
Delay1:
      ldr    r3, [r1]
      sub    r3, r2
      cmp    r3, r0
      blo    Delay1
      pop    {r0, r1, r2, pc}
	  
And I also compared listing file which contains disassembly and both are the same.
Another thing is that I added "kernel_old=1" to config.txt in order to reflect the 'org $0000' in the fasmarm source.

here's the linker command file.
SECTIONS {
.text 0x000 : {
*(.text)
}

/* Put the data after the code */
.data : {
*(.data)
}
}

Here's the listing file of the gnu as assembly.


build/kernel.elf: file format elf32-littlearm


Disassembly of section .text:

00000000 <_start>:
0: ee100fb0 mrc 15, 0, r0, cr0, cr0, {5}
4: e2100003 ands r0, r0, #3
8: 1a000008 bne 30 <CoreLoop>
c: e3a0d902 mov sp, #32768 ; 0x8000
10: eb000014 bl 68 <LedInit>

00000014 <Boucle>:
14: eb000021 bl a0 <LedOn>
18: e3a00f7d mov r0, #500 ; 0x1f4
1c: eb00002b bl d0 <Delay>
20: eb000024 bl b8 <LedOff>
24: e3a00f7d mov r0, #500 ; 0x1f4
28: eb000028 bl d0 <Delay>
2c: eafffff8 b 14 <Boucle>

00000030 <CoreLoop>:
30: eafffffe b 30 <CoreLoop>
34: e1a00000 nop ; (mov r0, r0)
38: e1a00000 nop ; (mov r0, r0)
3c: e1a00000 nop ; (mov r0, r0)

00000040 <Request>:
40: 0000001c andeq r0, r0, ip, lsl r0
44: 00000000 andeq r0, r0, r0
48: 00040010 andeq r0, r4, r0, lsl r0
4c: 00000004 andeq r0, r0, r4
...

0000005c <pLed>:
5c: 00000000 andeq r0, r0, r0

00000060 <pBal>:
60: 3f00b880 svccc 0x0000b880

00000064 <pHtr>:
64: 3f003004 svccc 0x00003004

00000068 <LedInit>:
68: e92d4003 push {r0, r1, lr}
6c: e51f1014 ldr r1, [pc, #-20] ; 60 <pBal>

00000070 <LedInit1>:
70: e5910018 ldr r0, [r1, #24]
74: e2100102 ands r0, r0, #-2147483648 ; 0x80000000
78: 1afffffc bne 70 <LedInit1>
7c: e24f003c sub r0, pc, #60 ; 0x3c
80: e5810020 str r0, [r1, #32]

00000084 <LedInit2>:
84: e5910018 ldr r0, [r1, #24]
88: e2100101 ands r0, r0, #1073741824 ; 0x40000000
8c: 1afffffc bne 84 <LedInit2>
90: e51f0044 ldr r0, [pc, #-68] ; 54 <Request+0x14>
94: e3c00103 bic r0, r0, #-1073741824 ; 0xc0000000
98: e50f0044 str r0, [pc, #-68] ; 5c <pLed>
9c: e8bd8003 pop {r0, r1, pc}

000000a0 <LedOn>:
a0: e92d4003 push {r0, r1, lr}
a4: e51f1050 ldr r1, [pc, #-80] ; 5c <pLed>
a8: e5910000 ldr r0, [r1]
ac: e2800801 add r0, r0, #65536 ; 0x10000
b0: e5810000 str r0, [r1]
b4: e8bd8003 pop {r0, r1, pc}

000000b8 <LedOff>:
b8: e92d4003 push {r0, r1, lr}
bc: e51f1068 ldr r1, [pc, #-104] ; 5c <pLed>
c0: e5910000 ldr r0, [r1]
c4: e2800001 add r0, r0, #1
c8: e5810000 str r0, [r1]
cc: e8bd8003 pop {r0, r1, pc}

000000d0 <Delay>:
d0: e92d4007 push {r0, r1, r2, lr}
d4: e3a01ffa mov r1, #1000 ; 0x3e8
d8: e0000091 mul r0, r1, r0
dc: e51f1080 ldr r1, [pc, #-128] ; 64 <pHtr>
e0: e5912000 ldr r2, [r1]

000000e4 <Delay1>:
e4: e5913000 ldr r3, [r1]
e8: e0433002 sub r3, r3, r2
ec: e1530000 cmp r3, r0
f0: 3afffffb bcc e4 <Delay1>
f4: e8bd8007 pop {r0, r1, r2, pc}
f8: e1a00000 nop ; (mov r0, r0)
fc: e1a00000 nop ; (mov r0, r0)

Disassembly of section .ARM.attributes:

00000000 <.ARM.attributes>:
0: 00001341 andeq r1, r0, r1, asr #6
4: 61656100 cmnvs r5, r0, lsl #2
8: 01006962 tsteq r0, r2, ror #18
c: 00000009 andeq r0, r0, r9
10: 01080106 tsteq r8, r6, lsl #2

Here's the listing file of the fasmarm assembly.


kernel5.elf: file format elf32-littlearm


Disassembly of section .flat:

00000000 <.flat>:
0: ee100fb0 mrc 15, 0, r0, cr0, cr0, {5}
4: e2100003 ands r0, r0, #3
8: 1a000008 bne 0x30
c: e3a0d902 mov sp, #32768 ; 0x8000
10: eb000014 bl 0x68
14: eb000021 bl 0xa0
18: e3a00f7d mov r0, #500 ; 0x1f4
1c: eb00002b bl 0xd0
20: eb000024 bl 0xb8
24: e3a00f7d mov r0, #500 ; 0x1f4
28: eb000028 bl 0xd0
2c: eafffff8 b 0x14
30: eafffffe b 0x30
34: ffffffff ; <UNDEFINED> instruction: 0xffffffff
38: ffffffff ; <UNDEFINED> instruction: 0xffffffff
3c: ffffffff ; <UNDEFINED> instruction: 0xffffffff
40: 0000001c andeq r0, r0, ip, lsl r0
44: 00000000 andeq r0, r0, r0
48: 00040010 andeq r0, r4, r0, lsl r0
4c: 00000004 andeq r0, r0, r4
...
60: 3f00b880 svccc 0x0000b880
64: 3f003004 svccc 0x00003004
68: e92d4003 push {r0, r1, lr}
6c: e51f1014 ldr r1, [pc, #-20] ; 0x60
70: e5910018 ldr r0, [r1, #24]
74: e2100102 ands r0, r0, #-2147483648 ; 0x80000000
78: 1afffffc bne 0x70
7c: e24f003c sub r0, pc, #60 ; 0x3c
80: e5810020 str r0, [r1, #32]
84: e5910018 ldr r0, [r1, #24]
88: e2100101 ands r0, r0, #1073741824 ; 0x40000000
8c: 1afffffc bne 0x84
90: e51f0044 ldr r0, [pc, #-68] ; 0x54
94: e3c00103 bic r0, r0, #-1073741824 ; 0xc0000000
98: e50f0044 str r0, [pc, #-68] ; 0x5c
9c: e8bd8003 pop {r0, r1, pc}
a0: e92d4003 push {r0, r1, lr}
a4: e51f1050 ldr r1, [pc, #-80] ; 0x5c
a8: e5910000 ldr r0, [r1]
ac: e2800801 add r0, r0, #65536 ; 0x10000
b0: e5810000 str r0, [r1]
b4: e8bd8003 pop {r0, r1, pc}
b8: e92d4003 push {r0, r1, lr}
bc: e51f1068 ldr r1, [pc, #-104] ; 0x5c
c0: e5910000 ldr r0, [r1]
c4: e2800001 add r0, r0, #1
c8: e5810000 str r0, [r1]
cc: e8bd8003 pop {r0, r1, pc}
d0: e92d4007 push {r0, r1, r2, lr}
d4: e3a01ffa mov r1, #1000 ; 0x3e8
d8: e0000091 mul r0, r1, r0
dc: e51f1080 ldr r1, [pc, #-128] ; 0x64
e0: e5912000 ldr r2, [r1]
e4: e5913000 ldr r3, [r1]
e8: e0433002 sub r3, r3, r2
ec: e1530000 cmp r3, r0
f0: 3afffffb bcc 0xe4
f4: e8bd8007 pop {r0, r1, r2, pc}


But the ACT led doesn't blink.

Any comments would help.

Thank you.

inaciose
Posts: 15
Joined: Thu Aug 24, 2017 3:34 pm

Re: Act LED (hello world)' Programming on RPi 3 (BCM2837)

Thu Aug 24, 2017 3:55 pm

Some time ago I found some code to switch on/off the green led on pi3 using mailboxes.

I merge it with dWelch code.

It's available here: https://github.com/inaciose/noos/tree/m ... /blinker02

tgritchie
Posts: 19
Joined: Fri Jun 01, 2012 4:07 pm
Location: United Kingdom

Re: Act LED (hello world)' Programming on RPi 3 (BCM2837)

Fri Aug 25, 2017 12:33 pm

The only minor difference I see from my code is in the GNU asm .ld file where my version places the _start code in the .init section. However I don't think this should make much difference especially given that the FASMARM version seems to produce the same code. Two other things you could check is to examine the actual .img file to ensure that at least the first few instructions are in the right place. Also it might be worth posting the entire config.txt file in case there is something amiss there

Trevor
eunwoo wrote:
Fri Aug 18, 2017 2:56 pm
Hello,

I've got RPi3 and am running test on ACT led.
I converted the assembly into the arm assembler(as) version which is shown below.

Code: Select all

.globl _start
_start:
@; Return CPU ID (0..3) Of The CPU Executed On
      mrc p15,0,r0,c0,c0,5    @; R0 = Multiprocessor Affinity Register (MPIDR)
      ands r0,#3 	      @; R0 = CPU ID (Bits 0..1)
      bne CoreLoop	      @; IF (CPU ID != 0) Branch To Infinite Loop (Core ID 1..3)

      mov    sp, #0x8000
      bl      LedInit
Boucle:
      bl      LedOn
      mov    r0, #500

snipped

  ec:	e1530000 	cmp	r3, r0
  f0:	3afffffb 	bcc	0xe4
  f4:	e8bd8007 	pop	{r0, r1, r2, pc}


But the ACT led doesn't blink.

Any comments would help.

Thank you.
[/quote]

LdB
Posts: 562
Joined: Wed Dec 07, 2016 2:29 pm

Re: Act LED (hello world)' Programming on RPi 3 (BCM2837)

Fri Aug 25, 2017 1:41 pm

It's pretty obvious the provide data size is 0 bytes according to your structure .. you even have it commented so let me change it

Code: Select all

.section .data
.align 4 @; This ensures lowest 4 bits are 0 for the following label
PropertyInfo:
  @; = Message Header =
  .int PropertyInfoEnd - PropertyInfo @; Calculate buffer size
  .int 0 @; Request code: Process Request
  @; = Tag Header =
  .int 0x00038041 @; Tag ID (SET_GPIO_STATE)
  .int 8 @; Value buffer size
  .int 8 @; Request/response size     >>> **** YOUR ERROR THE RESPONSE SIZE IS 8 NOT 0 YOU HAD <<<
  @; = Tag Value Buffer =
  .int 130 @; ACT_LED pin number
  .int 1 @; Turn it on
  .int 0 @; End tag
PropertyInfoEnd:
If you had checked the response correctly it would have told you the error.
Your MailboxWrite routine also has a bug we have discussed many times which comes from wrong historic code on the net. It isn't causing you any problems in this instance but will come out to haunt you one day.

Code: Select all

.global MailboxWrite
MailboxWrite:
  message .req r0
  add message, r1 @; Add the channel to the message
  mailbox .req r2
  ldr mailbox, =0x3f00b880 @; Load the mailbox's base address into r2
  wait_write$:
    status .req r3
    ldr status, [mailbox, #0x38] @; Load the status of the mailbox (0)    >>>  **** FIX ERROR WRITE STATUS IS OFFSET 0x38 not 0x18 <<<
    tst status, #0x80000000 @; Check the status against the FULL bit
    .unreq status
    bne wait_write$ @; Keep checking the mailbox until it isn't full

  str message, [mailbox, #0x20] @; Put the message in the mailbox (1)
  .unreq mailbox
  .unreq message
  mov pc, lr @; Return from the function

inaciose
Posts: 15
Joined: Thu Aug 24, 2017 3:34 pm

Re: Act LED (hello world)' Programming on RPi 3 (BCM2837)

Fri Aug 25, 2017 2:48 pm

Your MailboxWrite routine also has a bug...
(...)

ldr status, [mailbox, #0x38] @; Load the status of the mailbox (0) >>> **** FIX ERROR WRITE STATUS IS OFFSET 0x38 not 0x18 <<<
We also need to change to 0x38 the other 0x18 offsets?

MailboxRead function, on line:
ldr status, [mailbox, #0x18] @; Load the mailbox (0) status address

SetActLEDState function on line :
str state, [message, #0x18] @; Put the requested state in the tag value buffer

I checked all 3 functions with the 0x18 changed to 0x38 in 2 code samples (blinker02 and blinker03)
If I use 0x38 in the SetActLEDState the blinker02 works the blinker03 wont, and should.

The 0x18 offset produce a consistent result.

On https://github.com/raspberrypi/firmware/wiki/Mailboxes

Mailbox Peek Read/Write Status Sender Config
0 0x10 0x00 0x18 0x14 0x1c
1 0x30 0x20 0x38 0x34 0x3c

LdB
Posts: 562
Joined: Wed Dec 07, 2016 2:29 pm

Re: Act LED (hello world)' Programming on RPi 3 (BCM2837)

Fri Aug 25, 2017 2:56 pm

Nope the read mail gets it's status from 0x18, you read from 0x00
Write mail status is 0x38, you write to 0x20

See they are paired as are the offsets and that is what that shows
https://github.com/raspberrypi/firmware/wiki/Mailboxes

So technically 0x18 is the VC to ARM status and 0x38 is the ARM to VC status. So when you are writing you need to make sure mailbox isn't full. When you are reading you need to wait for mail to arrive.

It works for you at the moment because the read mailbox is empty and you aren't pushing enough data to fill the write mailbox which you don't even check. So effectively your write status check does absolutely nothing remove it and you will see :-)

inaciose
Posts: 15
Joined: Thu Aug 24, 2017 3:34 pm

Re: Act LED (hello world)' Programming on RPi 3 (BCM2837)

Fri Aug 25, 2017 3:10 pm

Thank you for your comment.
Just changed the code in github samples.

LdB
Posts: 562
Joined: Wed Dec 07, 2016 2:29 pm

Re: Act LED (hello world)' Programming on RPi 3 (BCM2837)

Fri Aug 25, 2017 3:15 pm

Yep looks correct now and should be working. You will run into problem with your linker file down the track just a heads up.
Update: Change that actually I am surprised your current code works because you have no data section in your linker file. If it is retaining the data section it's by shear luck because you definitely declare it as a data section in the assembler file.

The mailbox error was picked up by rst .. so thank him.
viewtopic.php?f=72&t=165529

It's pretty simple code to test he just jams lots and lots of data at the writebox and looked which status reported full. It was 0x38.

We have been slowly trying to stamp it out on all net samples but it takes some time because it's in a couple of notable historic github sites.
My version of yee old blinker ... https://github.com/LdB-ECM/Raspberry-Pi ... /myBlinker :-)

Update: Can I suggest you change sections in memmap .. will save you a lot of grief going forward

Code: Select all

SECTIONS
{
.text :
    {
        . = ALIGN(4);
         _start = .;
        *(.text .text.*)
    } > ram

 .bss :
    {
        . = ALIGN(4);
        *(.bss .bss.*)
   } > ram

.data :
    {
        . = ALIGN(4);
        *(.data .data.*)
   } > ram
}
Last edited by LdB on Fri Aug 25, 2017 3:44 pm, edited 2 times in total.

inaciose
Posts: 15
Joined: Thu Aug 24, 2017 3:34 pm

Re: Act LED (hello world)' Programming on RPi 3 (BCM2837)

Fri Aug 25, 2017 3:39 pm

My version of yee old blinker ... https://github.com/LdB-ECM/Raspberry-Pi ... /myBlinker :-)
Never see your github repo before.
I will take a look.
Thank you

LdB
Posts: 562
Joined: Wed Dec 07, 2016 2:29 pm

Re: Act LED (hello world)' Programming on RPi 3 (BCM2837)

Fri Aug 25, 2017 3:45 pm

Just check you read my update above :-)

inaciose
Posts: 15
Joined: Thu Aug 24, 2017 3:34 pm

Linker memory map

Fri Aug 25, 2017 9:37 pm

Code: Select all

Just check you read my update above
Yah. I notice your advise and do the change.

Do you know a good resource to learn about linker memory map for ARM?

For now i will read the following page/pages

https://sourceware.org/binutils/docs-2. ... ripts.html

I'm looking to understand the following code :

. = 0x80020000;

.text : AT(0x20000){
*(.text .text.* .gnu.linkonce.t.*)
}

From code comments i know that the code is loaded at 0x20000 and run at 0x80020000;
The reason of the AT 0x20000 is to reduce the length of produced binary file?

LdB
Posts: 562
Joined: Wed Dec 07, 2016 2:29 pm

Re: Act LED (hello world)' Programming on RPi 3 (BCM2837)

Sat Aug 26, 2017 3:00 am

Yeah sorry I don't know any sites that cover linker files , it is one of those things I have acquired over years of doing it. Maybe one day I will write one :-)

The dot (.) means always means position the fact it is outside section means physical position
. = 0x80020000;
Is pretty obvious physical position is set to 0x80020000;

Now next is a section command and it refers to the text section which means your code. I know its weird when is code ever called text but it is in linker files because most compilers call it that
.text : AT(0x20000){
*(.text .text.* .gnu.linkonce.t.*)
}
It says place all code data at position 0x20000 in the file. So here position is file not physical because it's inside a section area.

So first we see two clear different addresses at play one the actual address it will be to the CPU and the second is the position in the file. So what it is telling you basically is the section 0x20000 in the file is loaded to position 0x80020000 on the CPU. How you don't know but one would assume there is a bootloader doing it. So the linker file provides a description of what is intended to happen.

The reason isn't to reduce the binary size although it has that effect it is simply describing some physical setup on the CPU architecture that everyone can agree on and check against. I rarely use that instruction I tend to use the keyword .ORIGIN

The Pi for example loads to 0x8000, you can't actually load data into 0-0x8000 using the bootloader Pi provides even if you put it in the file. So in a similar way you could describe the Pi as

. = 0x8000;
.text : AT(0x0000){
*(.text .text.* .gnu.linkonce.t.*)
}

I take it you understand the 3 section fields being *.text .text* .gnu.linkonce.t.* which are the names the compiler or you called code sections. For any compiler you can just dump the listings and see what it calls the sections. I automatically dump listings on compilation and if you open any of the list.txt files on my repo it's what the C compiler is dumping. From there you can check the listing sections names and here is an example

Code: Select all

.file	"main.c"
               		.global	__aeabi_uldivmod
               		.text
               		.align	2
               		.global	kernel_main
You can see it is using .text so it will meet the first entry .text and so it will put code from the compiler in that section. Different compilers use different section names and your sample just covers the 3 main groups GCC C, GCC C++ and GNU-C.

So hopefully you have got the concept of physical address, file address and what section control does.

Return to “Bare metal”

Who is online

Users browsing this forum: No registered users and 3 guests