FASMARM on C.H.I.P. the US$ 9 computer by Next Thing

Index > Non-x86 architectures > FASMARM on C.H.I.P. the US$ 9 computer by Next Thing

Author

Thread

pelaillo
Missing in inaction

Joined: 19 Jun 2003
Posts: 878
Location: Colombia

pelaillo 11 Oct 2015, 06:08

I just got an alpha c.h.i.p. computer. It is an ARM Cortex A8 core with ARMv7 instruction set and Hard Float support.
I got it ready, flashed buildroot and connected to ssh via wifi.

Then I have tested the fasmarm 'armelf' example but I get a segmentation fault. Doing the same test with gnu assembler and linking with ld and the result is the same segmentation fault. Inspecting with readelf does not show anything strange.

The same program runs properly in a Raspberry Pi.

Any hints?

11 Oct 2015, 06:08

pelaillo
Missing in inaction

Joined: 19 Jun 2003
Posts: 878
Location: Colombia

pelaillo 11 Oct 2015, 06:34

That's the 9 dollars computer running. It has bluetooth, wifi, usb, power management with battery charger, voltage regulator, 1GHz processor, 512Mb ram, 4 Gb storage, a/v composite output, gpio, all included in that small board.

Just imagine a 100% assembly OS running on it...

Description:
Filesize:	49.62 KB
Viewed:	20464 Time(s)

Last edited by pelaillo on 12 Oct 2015, 23:32; edited 1 time in total

11 Oct 2015, 06:34

sleepsleep

Joined: 05 Oct 2006
Posts: 12931
Location: ˛　　　　　　　　　　　　　　　　　　　　　　　　　　　　　⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣Posts: 0010456

sleepsleep 11 Oct 2015, 06:59

exciting times,

would take over those fragile android if extended into a mobile phone.

11 Oct 2015, 06:59

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20414
Location: In your JS exploiting you and your system

revolution 11 Oct 2015, 15:00

pelaillo wrote:

I just got an alpha c.h.i.p. computer. It is an ARM Cortex A8 core with ARMv7 instruction set and Hard Float support.
I got it ready, flashed buildroot and connected to ssh via wifi.

Then I have tested the fasmarm 'armelf' example but I get a segmentation fault. Doing the same test with gnu assembler and linking with ld and the result is the same segmentation fault. Inspecting with readelf does not show anything strange.

The same program runs properly in a Raspberry Pi.

Any hints?

Show your code. We don't know what you have done.

11 Oct 2015, 15:00

pelaillo
Missing in inaction

Joined: 19 Jun 2003
Posts: 878
Location: Colombia

pelaillo 11 Oct 2015, 16:42

I am trying with the unmodified armelf example on fasmarm distribution. The same binary produced by fasmarm runs in a Raspberry Pi and produces a segmentation fault on the c.h.i.p.

Code:

        format ELF executable
        entry start

        segment readable executable

start:  mov     r0,0
        add     r1,pc,hello-$-8
        mov     r2,hello_len
        swi     0x900004
        mov     r0,6
        swi     0x900001

hello:  db      'Hello world',10
hello_len=$-hello

        ;dummy section for bss, see http://board.flatassembler.net/topic.php?t=3689
        segment writeable

The result:

Code:

# readelf -l armelf

Elf file type is EXEC (Executable file)
Entry point 0x8074
There are 2 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000074 0x00008074 0x00008074 0x00018 0x00018 R E 0x1000
  LOAD           0x00008c 0x0000908c 0x0000908c 0x00000 0x00000  W  0x1000
# ./armelf
Segmentation fault

11 Oct 2015, 16:42

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20414
Location: In your JS exploiting you and your system

revolution 12 Oct 2015, 00:36

You could try an even simpler example and see if that seg faults:

Code:

        format ELF executable
        entry start

        segment readable executable

start:  swi     0x900001  ;exit

        segment writeable

If that also seg faults then it would suggest that the SWI values are different on the OS. Perhaps the base of 0x900000 has been changed?

12 Oct 2015, 00:36

pelaillo
Missing in inaction

Joined: 19 Jun 2003
Posts: 878
Location: Colombia

pelaillo 12 Oct 2015, 05:30

Same problem.
Tried also changing swi by svc but it's still segfault.

I noticed this:

Code:

# objdump -d armelf

armelf:     file format elf32-littlearm

#

objdump cannot disassemble the file.

How to find if the 0x900000 base is changed?

Last edited by pelaillo on 12 Oct 2015, 05:38; edited 1 time in total

12 Oct 2015, 05:30

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20414
Location: In your JS exploiting you and your system

revolution 12 Oct 2015, 05:36

What is the OS that the board uses? I presume the source code is available so perhaps the SWI/SVC base value is different.

Are you using the latest version of fasmarm?

BTW: SWI and SVC are the same instruction, renamed by ARM for some reason.

Last edited by revolution on 12 Oct 2015, 05:52; edited 1 time in total

12 Oct 2015, 05:36

pelaillo
Missing in inaction

Joined: 19 Jun 2003
Posts: 878
Location: Colombia

pelaillo 12 Oct 2015, 05:43

Quote:

Are you using the latest version of fasmarm?

I'm using v1.36 in linux

Code:

# cat /proc/cpuinfo
processor       : 0
model name      : ARMv7 Processor rev 2 (v7l)
BogoMIPS        : 1001.88
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x3
CPU part        : 0xc08
CPU revision    : 2

Hardware        : Allwinner sun4i/sun5i Families
Revision        : 0000
Serial          : 1625420501c2c134

# cat /proc/version
Linux version 4.2.0-rc1 (ubuntu@ip-172-31-37-115) (gcc version 4.9.2 20140904 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.09) ) #1 SMP Fri Oct 2 23:23:30 UTC 2015

12 Oct 2015, 05:43

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20414
Location: In your JS exploiting you and your system

revolution 12 Oct 2015, 05:53

What is the SWI/SVC base value? Is it 0x900000?

12 Oct 2015, 05:53

pelaillo
Missing in inaction

Joined: 19 Jun 2003
Posts: 878
Location: Colombia

pelaillo 12 Oct 2015, 06:21

I think the problem resides in elf formatter.

12 Oct 2015, 06:21

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20414
Location: In your JS exploiting you and your system

revolution 12 Oct 2015, 07:16

pelaillo wrote:

I think the problem resides in elf formatter.

Can you be more specific about where the fault is? Is there some dbugging output from the ELF loader? Can a debugger show where the seg fault occurs?

BTW: You also wrote this above:

pelaillo wrote:

Doing the same test with gnu assembler and linking with ld and the result is the same segmentation fault. Inspecting with readelf does not show anything strange.

The same program runs properly in a Raspberry Pi.

Does that mean that the GNU tools also generate incorrect ELF files?

12 Oct 2015, 07:16

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20414
Location: In your JS exploiting you and your system

revolution 12 Oct 2015, 07:38

pelaillo wrote:

How to find if the 0x900000 base is changed?

It appears to be defined in the file unistd.h

e.g. http://lxr.free-electrons.com/source/arch/arm/include/asm/unistd.h?v=3.1

According to that link the base might be either 0x900000 or 0x000000. You could try 0x000000. Otherwise the source code for your OS should indicate what value is being used.

12 Oct 2015, 07:38

pelaillo
Missing in inaction

Joined: 19 Jun 2003
Posts: 878
Location: Colombia

pelaillo 12 Oct 2015, 22:36

Found it! The problem is in a changed calling convention -> http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=3105/4

Quote:

legacy ABI:
- put fd into r0
- put length into r1-r2
- use "swi #(0x900000 + 194)" to call the kernel
new ARM EABI:
- put fd into r0
- put length into r2-r3 (skipping over r1)
- put 194 into r7
- use "swi 0" to call the kernel

I wonder how Raspbian can use both calling conventions while the newer Linux 4.2 don't. The change is quite old (2006)
However, the final example is running in both raspberry pi and chip:

Code:

format ELF executable
        entry start
        segment readable executable

start:  mov     r0,0
        add     r1,pc,hello-$-8
        mov     r2,hello_len
        mov     r7,4
        swi     0
        mov     r7,1
        mov     r0,6
        swi     0

hello:  db      'Hello world',10
hello_len=$-hello

        segment writeable

Thank you revolution. Now I'll start playing with my favourite assembler.

12 Oct 2015, 22:36

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20414
Location: In your JS exploiting you and your system

revolution 13 Oct 2015, 00:52

Glad you found the change.

But that would suggest that backward compatibility has recently been dropped in the latest Linux?

That is sad. So now old versions of Linux won't run the newer code. And the newest versions of Linux won't run the old code. This makes me wonder what the devs there are smoking. Confused

13 Oct 2015, 00:52

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum