Status of Raspberry Pi native support

[deadwood]

@mschulz is not on this forum, but you should be able to catch him on discord

[NinjaCowboy]

Now I'm pretty sure that this is a binutils issue. I compiled boot.c with the AROS compiler and had it output assembly. I then assembled it with both the AROS binutils and my system's binutils (both are version 2.32) and used the same exact flags, but got different output for the branch instruction at address 30.

AROS binutils:

Code: [Select]

Disassembly of section .aros.startup:

00000000 <bootstrap>:
   0:   e10f4000        mrs     r4, CPSR
   4:   e204401f        and     r4, r4, #31
   8:   e3a0801a        mov     r8, #26
   c:   e1540008        cmp     r4, r8
  10:   0a000007        beq     34 <leave_hyper>

00000014 <continue_boot>:
  14:   f1020013        cps     #19
  18:   e59fd030        ldr     sp, [pc, #48]   ; 50 <tmp_stack_ptr>
  1c:   ee114f50        mrc     15, 0, r4, cr1, cr0, {2}
  20:   e384460f        orr     r4, r4, #15728640       ; 0xf00000
  24:   ee014f50        mcr     15, 0, r4, cr1, cr0, {2}
  28:   e3a04101        mov     r4, #1073741824 ; 0x40000000
  2c:   eee84a10        vmsr    fpexc, r4
  30:   ea000000        b       22c <.LC24+0x4>
                        30: R_ARM_JUMP24        boot-0x8

00000034 <leave_hyper>:
  34:   e24f4028        sub     r4, pc, #40     ; 0x28
  38:   e12ef304        msr     ELR_hyp, r4
  3c:   e10f4000        mrs     r4, CPSR
  40:   e204401f        and     r4, r4, #31
  44:   e3844013        orr     r4, r4, #19
  48:   e16ef304        msr     SPSR_hyp, r4
  4c:   e160006e        eret

00000050 <tmp_stack_ptr>:
  50:   00000ff0        strdeq  r0, [r0], -r0   ; <UNPREDICTABLE>

System binutils:

Code: [Select]

Disassembly of section .aros.startup:

00000000 <bootstrap>:
   0:   e10f4000        mrs     r4, CPSR
   4:   e204401f        and     r4, r4, #31
   8:   e3a0801a        mov     r8, #26
   c:   e1540008        cmp     r4, r8
  10:   0a000007        beq     34 <leave_hyper>

00000014 <continue_boot>:
  14:   f1020013        cps     #19
  18:   e59fd030        ldr     sp, [pc, #48]   ; 50 <tmp_stack_ptr>
  1c:   ee114f50        mrc     15, 0, r4, cr1, cr0, {2}
  20:   e384460f        orr     r4, r4, #15728640       ; 0xf00000
  24:   ee014f50        mcr     15, 0, r4, cr1, cr0, {2}
  28:   e3a04101        mov     r4, #1073741824 ; 0x40000000
  2c:   eee84a10        vmsr    fpexc, r4
  30:   eafffffe        b       224 <boot>
                        30: R_ARM_JUMP24        boot

00000034 <leave_hyper>:
  34:   e24f4028        sub     r4, pc, #40     ; 0x28
  38:   e12ef304        msr     ELR_hyp, r4
  3c:   e10f4000        mrs     r4, CPSR
  40:   e204401f        and     r4, r4, #31
  44:   e3844013        orr     r4, r4, #19
  48:   e16ef304        msr     SPSR_hyp, r4
  4c:   e160006e        eret

00000050 <tmp_stack_ptr>:
  50:   00000ff0        strdeq  r0, [r0], -r0   ; <UNPREDICTABLE>

I realize that we patch binutils to add AROS support. Why do we need to make all of the relocations section-relative here? https://github.com/aros-development-team/AROS/blob/master/tools/crosstools/gnu/binutils-2.32-aros.diff#L190 It seems like this change may be causing the problem.

One thing I've noticed is that my system's arm-none-eabi-as will only write REL relocations (with no addend), while arm-raspi-aros-as will only write RELA relocations. I'm not sure whether the assembler or linker is responsible for the 8 byte fixup for PC-relative instructions. Since RELs don't have an addend, I assume the linker would have to do it, but then again, the AROS assembler produces RELA relocations with a -8 addend already there.

[NinjaCowboy]

As a workaround, I changed elf_backend_may_use_rel_p to 1 and changed elf_backend_may_use_rela_p and elf_backend_default_use_rela_p to 0 here. This forces the assembler to emit REL relocations instead of RELA (which seem to be buggy on ARM), and all of the branch instructions seem to work properly now.

[deadwood]

Glad you made it work for you

[NinjaCowboy]

After tinkering with the code some more, I finally got the kernel to boot on my Pi. Nothing works yet, and it complains about unsupported relocations (yes, more of these bollocks to deal with), but it's progress. I've ordered a USB serial adapter to capture the UART output from the Pi, but it has yet to arrive. In the meantime, the VC framebuffet boot console seems to work, though scrolling is extremely slow.

[OlafS3]

great that you invest the time 

[Amiwell]

many thanks

[NinjaCowboy]

I've finally gotten it to run kernel_cstart from core.elf. The elf loader is buggy and doesn't resolve R_ARM_MOVW_ABS_NC and R_ARM_MOVT_ABS relocations correctly (I don't know enough about the details of how these two relocations work to fix it), so access to variables in the .data section is broken. I was able to work around this by recompiling everything with the -mword-relocations flag so that it avoids using movw/movt and simply loads 32-bit values from the pool instead. Now, the kernel gets as far as here, then crashes. I will look into this more tonight and try to get it further into the boot process.

[NinjaCowboy]

Well, after a bit more work, I can now say that it "boots" on my Raspberry Pi! I had to disable most of Poseidon, since it was causing crashes during boot (which is expected, since the DWC2 USB drivers are incomplete), but Intuition shows up (though all green for some reason). Mice and keyboards don't work yet, so you can't do anything with it, and it seems to have trouble loading Wanderer.

I remember hearing something about AROS not being able to run correctly from a FAT formatted partition. Is there a way to configure AROS so that it runs from a separate partition? Since this is a Raspberry Pi, the kernel and boot rom need to be on a FAT partition, but I imagine I should be able to put the rest of the system on a SFS partition.

[deadwood]

Congratz on your progress.

As for your question, dos.library is the place to look. In it's boot sequence it assigns which device will be SYS:. You need to look at that code and either hardcode your other partition of check if AROS.boot file will work (if I remember correctly, AROS.boot file put in root of file system indicate this is a partition to boot from). I think AROS.boot has to have a string containing name of architecture (so armhf in your case).

[AMIGASYSTEM]

@Ninja

I confirm, inside AROS.boot you can find the name of the architecture used there.

Riguado the FAT filesystem, but also NTFS, are supported by AROS, but some apps may not work, as well as some commands do not work correctly, example if you try to rename a file with the same name, the file will be deleted.

In any case if you use InstallAROS you will have only two choices SFS (recommended) and FFS

[NinjaCowboy]

Is there a way to format a SFS or FFS partition in Linux? Can hosted AROS do that?

[deadwood]

Well, depends on what you have this partition. If it is a pen drive, you can attach it to VM and boot AROS in VM to format it.

[NinjaCowboy]

I'm currently messing with the USB driver, hopefully trying to eventually get a mouse and keyboard working. It's a very frustrating experience, but I'm learning a lot about the USB protocol and AROS drivers in the process.

[AMIGASYSTEM]

Mouse and Keyboard PS2 and Wireless work perfectly on AROS, if the PC hardware is supported !