Finished hacking for this weekend.

Lessons learned are:

1) Use the official RPi compiler (raspbian-x64)
2) Nuke the entire 
"arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/lib/gcc/arm-linux-gnueabihf/4.8.3/include"
 directory

Still not compiling just yet as I'm hitting a new error now :)

( cd /home/dave/dev/rumpkernel/rumprun/lib/libcompiler_rt && 
/home/dave/dev/rumpkernel/rumprun/./obj-evbearmhf-el-hw-raspberrypi/rumptools/rumpmake
 
MAKEOBJDIR=/home/dave/dev/rumpkernel/rumprun/./obj-evbearmhf-el-hw-raspberrypi/lib/libcompiler_rt
 RUMPSRC=/home/dave/dev/rumpkernel/rumprun/src-netbsd obj && 
/home/dave/dev/rumpkernel/rumprun/./obj-evbearmhf-el-hw-raspberrypi/rumptools/rumpmake
 
MAKEOBJDIR=/home/dave/dev/rumpkernel/rumprun/./obj-evbearmhf-el-hw-raspberrypi/lib/libcompiler_rt
 RUMPSRC=/home/dave/dev/rumpkernel/rumprun/src-netbsd includes && 
/home/dave/dev/rumpkernel/rumprun/./obj-evbearmhf-el-hw-raspberrypi/rumptools/rumpmake
 
BMKHEADERS=/home/dave/dev/rumpkernel/rumprun/./obj-evbearmhf-el-hw-raspberrypi/include
 
MAKEOBJDIR=/home/dave/dev/rumpkernel/rumprun/./obj-evbearmhf-el-hw-raspberrypi/lib/libcompiler_rt
 RUMPSRC=/home/dave/dev/rumpkernel/rumprun/src-netbsd dependall )
#    objdir  
/home/dave/dev/rumpkernel/rumprun/./obj-evbearmhf-el-hw-raspberrypi/lib/libcompiler_rt
nbmake[1]: don't know how to make __aeabi_idiv0.c. Stop

nbmake[1]: stopped in /home/dave/dev/rumpkernel/rumprun/lib/libcompiler_rt
../Makefile.inc:67: recipe for target 
'/home/dave/dev/rumpkernel/rumprun/./obj-evbearmhf-el-hw-raspberrypi/lib/libcompiler_rt/libcompiler_rt.a'
 failed

I had to fix some bad syntax in my code to get this far (see [1])

I've rather naively edited boardreg.h and machdep.c from the integrator-cp port
As the RPi only has one timer [2], I'm intending to used the free running clock 
as TMR1 and the countdown clock as TMR2
I have very little confidence that this will work as both clocks are sharing an 
interrupt, or at least that's how I'm reading the docs.

I'm going to have to drink a lot more coffee, read some manuals and think some 
more on this.
Any pointers will be greatly appreciated, as this is all new territory for me.

[1]: https://github.com/dave-tucker/rumprun/tree/raspberrypi
[2]: 
https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2835/BCM2835-ARM-Peripherals.pdf


> On 31 Jan 2016, at 11:37, Dave Tucker <[email protected]> wrote:
> 
> Confirming - blitzing this directory,
> https://github.com/raspberrypi/tools/tree/f5642106425d430e1f82ee064121a5fd0e05a386/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/lib/gcc/arm-linux-gnueabihf/4.8.3/include/ssp
> 
> Gets the compilation moving further...
> 
> Next status update coming soon
> 
>> On 31 Jan 2016, at 11:21, Dave Tucker <[email protected]> wrote:
>> 
>> Looks like my problem might be related to not picking up the includes from 
>> within `--sysroot`
>> I don't have any ssp headers on my host system (`dpkg -l | grep ssp` is 
>> empty)
>> `find / -name ssp.h` only yields results from within the netbsd-src or the 
>> my toolchain directories
>> 
>> I can force include 
>> /path/to/obj-evbearmhf-el-hw-raspberrypi/rumptools/dest/usr/include/ssp 
>> Which gets compilation a little further, but causes issues later on with as 
>> `ssp/stdio.h` shadows `stdio.h`
>> 
>>> On 30 Jan 2016, at 10:31, Antti Kantee <[email protected]> wrote:
>>> 
>>> On 29/01/16 22:28, Dave Tucker wrote:
>>>>> See
>>>>> http://wiki.rumpkernel.org/Info%3A-Notes-on-hardware-platforms#raspberry-pi
>>>>> 
>>>>> I filed a NetBSD PR about that "spoiler" years ago, don't remember what
>>>>> the conclusion was off the top of my head, but anyway, the workaround
>>>>> should be fine.  At least it worked when I last was building for RPi.
>>>> 
>>>> Thanks!
>>>> I tried it out today with the official compiler and it complained if 
>>>> couldn't find <ssp.h>
>>>> After adding `-I<long path to rpi compiler>/includes/ssp` to CFLAGS I'm 
>>>> now getting more errors along the lines of:
>>>> 
>>>> '__ssp_real' declared as function returning a function
>>>> 
>>>> I think this is a gcc related issue, so next step is to see if I can 
>>>> rebuild the compiler with support for gcc >= 4.9
>>> 
>>> It's a known problem, but the only known workaround -- known to me at any 
>>> rate -- is to uninstall the host ssp headers.  See:
>>> https://github.com/rumpkernel/rumprun/issues/14
>>> 
>>> In case someone's tweakfinger is tingling, a solution for that would be 
>>> very welcome.
>>> 
>> 
> 


Reply via email to