View previous topic :: View next topic |
Author |
Message |
el_Salmon Guru
Joined: 15 Dec 2003 Posts: 339 Location: Around 2.4GHz
|
Posted: Mon Feb 09, 2015 8:08 am Post subject: Gentoo on Raspberry Pi 2 |
|
|
Hi,
I'm ordering a Raspberry Pi 2 to replace my old RPi 1, that runs Raspbian (Debian) currently. I'm thinking to begin to use Gentoo Linux but I'm not sure if the new model be able to compile ebuilds itself without distcc. I'm suppose it does, because is a Quad-core 900 MHz with 1 GB DDR2 RAM. What's your experience or technical opinion? _________________ Linux Proud User: HP Pavilion 15-an002ns laptop (KDE Neon), Xiaomi Mi Air 12 (KDE Neon), Raspberry Pi 3 (Nextcloudpi), Docooler MS9 Pro (LibreElec) |
|
Back to top |
|
|
Roman_Gruber Advocate
Joined: 03 Oct 2006 Posts: 3846 Location: Austro Bavaria
|
Posted: Mon Feb 09, 2015 8:18 am Post subject: Re: Gentoo on Raspberry Pi 2 |
|
|
Nope. AFAIK its arm, like my smartphone and that architecture has not much calc power.
Code: | cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Duo CPU T9500 @ 2.60GHz
stepping : 6
microcode : 0x60f
cpu MHz : 800.000
cache size : 6144 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm ida dtherm tpr_shadow vnmi flexpriority
bogomips : 5189.68
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Duo CPU T9500 @ 2.60GHz
stepping : 6
microcode : 0x60f
cpu MHz : 800.000
cache size : 6144 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm ida dtherm tpr_shadow vnmi flexpriority
bogomips : 5189.68
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
|
You may compare my antiquie cpu with the bogomips with your newly bought pi and you will may understand why it does not make much sense.
and it does not matter what you push on your pi, afaik debian is a binary distro and afaik you only put a binary distro on a pi.
so you can crosscompile and put a binary "gentoo" on that pi.
but compiling on the pi could be fun when you have much time. does it makes sense, i doubt.
Do not get fooled by fancy arm MHZ Numbers, they say nothing.
The architecture + bogomips determines the calculations. |
|
Back to top |
|
|
snkmoorthy Guru
Joined: 19 Nov 2002 Posts: 376
|
Posted: Mon Feb 09, 2015 11:48 am Post subject: |
|
|
http://wiki.gentoo.org/wiki/Raspberry_Pi
use crossdev on your powerful machine and compile for armv6[7] to your hearts content. Native compilations will be slow. |
|
Back to top |
|
|
Leio Developer
Joined: 27 Feb 2003 Posts: 494 Location: Estonia
|
Posted: Mon Feb 09, 2015 1:32 pm Post subject: |
|
|
BogoMIPS is NOT usable for performance comparison between different CPUs. Especially not with ARM vs not ARM - http://en.wikipedia.org/wiki/BogoMips#Timer-based_delays
With RPi2 now being quad-core, native compilation isn't that slow; and together with --jobs=n or something, to battle slow single core configure runs, it shouldn't be all that bad. Of course at least distcc is hugely desirable still.
I didn't find any RPi2 specific material in our wiki page yet, so keep that in mind (CFLAGS, etc). But most other things are equal, including graphics stuff.
I'm setting up a full graphical system on RPi2 with Gentoo now, so happy to share notes, mostly via IRC. #gentoo-embedded or #rpi-gentoo channel or something.
Code: |
# cat /proc/cpuinfo # without overclocking config
processor : 0
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 38.40
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5
processor : 1
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 38.40
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5
processor : 2
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 38.40
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5
processor : 3
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 38.40
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5
Hardware : BCM2709
Revision : a01041
Serial : <snipped>
|
_________________ GNOME team lead; GStreamer; MIPS/ARM64 |
|
Back to top |
|
|
Roman_Gruber Advocate
Joined: 03 Oct 2006 Posts: 3846 Location: Austro Bavaria
|
Posted: Tue Feb 10, 2015 7:39 pm Post subject: |
|
|
I read about today taht the cpu gets full utilization when playing fullhd videos. i do not trust much about golem.de knowledge base at all.
I am interested in user expierence here.
The hardware could be fun for some small projects though I wonder if I can find really a use case for it |
|
Back to top |
|
|
1clue Advocate
Joined: 05 Feb 2006 Posts: 2569
|
Posted: Tue Feb 10, 2015 7:51 pm Post subject: |
|
|
I tried Gentoo on a model b+ for awhile. Never got a working kernel, I robbed the one from Raspbian and used that mostly.
A kernel compile on a B+ is 10+ hours unless something went wrong. If you can avoid doing a clean, subsequent compiles are quicker. First time I've ever spent less time configuring the kernel than compiling it on Gentoo. Back in the pentium days I could, because the kernel was a lot simpler and CPUs slower than the pi.
I also had tried to set up Gentoo for distcc but never got it to work from the pi.
You're using armv7 where I was using armv6, so that might make a difference by itself.
My opinion is that if you're doing this for fun and have lots of time and patience, then it might be worthwhile. If you actually want to use the pi for a project and don't need an extremely customized install then it's probably better to trim down/modify some other distro. |
|
Back to top |
|
|
Leio Developer
Joined: 27 Feb 2003 Posts: 494 Location: Estonia
|
Posted: Tue Feb 10, 2015 7:51 pm Post subject: |
|
|
CPU utilization ought to be in the 20% area of one core for 720p/1080p playback. At least so it was with the weaker model, and all the video bits are still the same, just with different/more memory.
If it's full utilization, they are doing something wrong and aren't using acceleration via OpenMAX properly. _________________ GNOME team lead; GStreamer; MIPS/ARM64 |
|
Back to top |
|
|
Leio Developer
Joined: 27 Feb 2003 Posts: 494 Location: Estonia
|
Posted: Tue Feb 10, 2015 9:12 pm Post subject: |
|
|
Setting up distcc is trivial with portage on rpi and crossdev on the helper machine.
Just did a toolchain for rpi2 to my desktop today
Code: | crossdev --target armv7a-hardfloat-linux-gnueabi |
20 minutes later and all done.
Now I just need to install distcc on rpi2, add it to FEATURES, configure hosts, increase some MAKEOPTS and good to go. Though I have distcc on the amd64 already all set up, otherwise there is some more work there.
Though currently going native only and things speed along quickly for my ~arm upgrades, it seems. Will get to webkit-gtk and the likes soon enough
Right now I'm using
CFLAGS="-O2 -pipe -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -mtls-dialect=gnu2"
as the basis for RPi2, as far as CFLAGS are concerned, btw. (I don't know about the tls-dialect exactly, that's what -mcpu=native seems to enable with =gnu, gcc man page suggests gnu2 might be better if I have new enough toolchain, which is very likely to be the case).
Kernel compile on a big host is trivial with the appropriate env var that just makes everything a given CHOST, but I don't bother with that either for now and simply grab prebuilt ones from git clone https://github.com/raspberrypi/firmware.git (kernel7.img) together with all the other boot files and the modules directory to /lib/modules too. Something to tune much much later in my case. _________________ GNOME team lead; GStreamer; MIPS/ARM64 |
|
Back to top |
|
|
keet Guru
Joined: 09 Sep 2008 Posts: 573
|
Posted: Sat Feb 14, 2015 8:50 pm Post subject: |
|
|
I just got my Raspberry Pi 2. I'm thinking of using it as a file server. The only problem is that the storage would need to be encrypted, and my Raspberry Pi 1 was much too slow for this (3MB/s). Does anyone here know how well the 2 performs in this respect? I hope to start installing Gentoo on it soon. |
|
Back to top |
|
|
1clue Advocate
Joined: 05 Feb 2006 Posts: 2569
|
Posted: Sun Feb 15, 2015 2:22 am Post subject: |
|
|
100 mbps nic should tell you everything you need to know about a pi as a file server. |
|
Back to top |
|
|
keet Guru
Joined: 09 Sep 2008 Posts: 573
|
Posted: Thu Feb 19, 2015 1:24 am Post subject: |
|
|
I have mine working so far. I downloaded a stage 3, but took the boot files from a Raspbian installation. After that and other basic configuration, I set up distcc, ran 'emerge -e system', and installed a few world packages.
I got the Raspberry Pi 2 kernel sources from Github and built them within an hour or so, and rebooted successfully.
Udev failed to build, so I am curious about that, but I'm not worried about it.
Another odd thing that I noticed is that only about 750MB of R.A.M. are available. I set gpu_mem=16, so that is probably not the problem. Considering that it has four cores, and only 1GB of R.A.M., it would be nice to have more available. A potential fix is at http://www.raspberrypi.org/forums/viewtopic.php?f=56&t=98997&start=25, so I will try that when I have time. |
|
Back to top |
|
|
Leio Developer
Joined: 27 Feb 2003 Posts: 494 Location: Estonia
|
Posted: Thu Feb 19, 2015 10:40 am Post subject: |
|
|
keet wrote: | Udev failed to build, so I am curious about that, but I'm not worried about it.
Another odd thing that I noticed is that only about 750MB of R.A.M. are available. I set gpu_mem=16, so that is probably not the problem. Considering that it has four cores, and only 1GB of R.A.M., it would be nice to have more available. A potential fix is at http://www.raspberrypi.org/forums/viewtopic.php?f=56&t=98997&start=25, so I will try that when I have time. |
If you use my CFLAGS with -mtls-dialect=gnu2, then that fails with udev due to systemd configure (which udev uses as it's building out of the systemd tree) forcing the gold linker if it's present. But it fails at linking udev itself (as opposed to the tiny test program they test gold with before forcing its usage) as gold linker doesn't seem to support those tls relocations yet. I workarounded it by adding -Wl,-fuse-ld=bfd to LDFLAGS for udev building. Using the default tls-dialect of gnu should work too, but I use gnu2, which is ARM specific and supposedly a bit faster in relocations, just cause I can and I'm not completely sure if mixing gnu and gnu2 is fine or not. I filed https://bugs.gentoo.org/show_bug.cgi?id=539998 for this.
Regarding the RAM, I heard the kernel from RPi Foundation came with a 1/3 GB memory model split at some point, and that was the problem; while 2/2 GB had problems on some specific other things at some point. Maybe your kernel configuration has that memory model choice as well. I *think* this is the choice between VMSPLIT_3G, VMSPLIT_2G and VMSPLIT_1G in kernel configuration and/or CONFIG_HIGHMEM.
I just use prebuilt kernel and modules from https://github.com/raspberrypi/firmware for the time being, until I have everything else going good. Those use VMSPLIT_2G and do not have HIGHMEM set _________________ GNOME team lead; GStreamer; MIPS/ARM64 |
|
Back to top |
|
|
olek Apprentice
Joined: 22 Oct 2011 Posts: 173
|
Posted: Thu Feb 19, 2015 6:13 pm Post subject: |
|
|
I'm using the original model B and even compile everything right on it with an attached hard drive.
it's a headless server and I also like to choose less boated software on all of my machines. it works fine. _________________ https://plaintext.blog |
|
Back to top |
|
|
keet Guru
Joined: 09 Sep 2008 Posts: 573
|
Posted: Sat Feb 21, 2015 12:01 am Post subject: |
|
|
Choosing VMSPLIT_2G fixed the memory problem; I now have about 975MB. Thank you for the tip.
Now I'm working on building media-tv/kodi-14.1. I a'm not sure whether I will end up using this, but I want to see whether it works. Of course, it's in ~x86 and ~amd64, but not marked for arm at all, but I'll try it. |
|
Back to top |
|
|
Yamakuzure Advocate
Joined: 21 Jun 2006 Posts: 2305 Location: Adendorf, Germany
|
Posted: Fri Feb 27, 2015 3:55 pm Post subject: |
|
|
Leio wrote: | Setting up distcc is trivial with portage on rpi and crossdev on the helper machine.
Just did a toolchain for rpi2 to my desktop today
Code: | crossdev --target armv7a-hardfloat-linux-gnueabi |
20 minutes later and all done. | I am stuck right there. The re-merge of glibc fails with the following error: Code: | checking for .preinit_array/.init_array/.fini_array support... no
configure: error: Need linker with .init_array/.fini_array support. | I have already tried to build newer versions, clearing my LDFLAGS as suggested in [solved] Crossdev, ".init_array/.fini_array support" and unmerged/remerged all crossdev packages again, and switched between with and without stable switch "-S".
Everything that google comes up with is very old, or suggests to remove -fPIC - which is not enabled here...
I am completely at sea, does anybody have an idea?
Versions that are to be installed: Code: | ~ # eix -I -C cross-armv7a-hardfloat-linux-gnueabi -c
[I] cross-armv7a-hardfloat-linux-gnueabi/binutils [1] (2.25(2.25)@27.02.2015): Tools necessary to build programs
[I] cross-armv7a-hardfloat-linux-gnueabi/gcc [1] (4.9.2(4.9.2)@27.02.2015): The GNU Compiler Collection
[I] cross-armv7a-hardfloat-linux-gnueabi/glibc [1] (2.20-r2(2.2)@27.02.2015): GNU libc6 (also called glibc2) C library
[I] cross-armv7a-hardfloat-linux-gnueabi/linux-headers [1] (3.18@27.02.2015): Linux system headers |
_________________ Edited 220,176 times by Yamakuzure |
|
Back to top |
|
|
Yamakuzure Advocate
Joined: 21 Jun 2006 Posts: 2305 Location: Adendorf, Germany
|
Posted: Fri Feb 27, 2015 6:56 pm Post subject: |
|
|
Solved it myself.
As you can see above, I am using gcc-4.9.2. The problem is, that this does not set __ARM_ARCH (ARM support was dropped?) and in the glibc build dir one can find in sysdeps/arm/sysdep.h: Code: | /* The __ARM_ARCH define is provided by gcc 4.8. Construct it otherwise. */ | I found out about this after yet another clear of the toolchain and a retry. When merging the glibc headers, a lot of messages that the arch architecture would be unknown are shown. But I never actually watched the build process, so I missed the message. The glibc headers are merged nevertheless.
My fix, as I do not want to install another gcc on my system but need gcc-4.9.2 for my work:- Set the crossdev toolchain to build gcc-4.8.3 for itself (by masking/keywording)
- Build the toolchain and halt the build of the glibc-headers using ctrl+z once prepared
- Add "#define __ARM_ARCH_7A__" in the glibc build dir/sysdeps/arm/sysdep.h
- continue with "fg"
And now 2.20-r2 just got merged successfully. *yay* _________________ Edited 220,176 times by Yamakuzure |
|
Back to top |
|
|
UncleVan n00b
Joined: 08 Feb 2011 Posts: 72
|
Posted: Sat Feb 28, 2015 10:13 pm Post subject: @ Leio |
|
|
Hi Leio,
Now, this wold be my second Gentoo ARM clone, since I succesfully build a fully functional distro for Raspberry Pi model B: cross(dev) toolchain, kernel from source, distcc/qemu user emu etc - details on request - but I have a pretty basic question about the cross-compiler:
How you came across this tuple:
Code: | crossdev -t armv7a-hardfloat-linux-gnueabi |
and I mean the ARCH one "armv7a" ?
How you know this is the "right one" for Pi 2 ? Where can one get a list of tuples avialable for/supported by the current gcc ?
(Somehow this https://www.gentoo.org/proj/en/base/embedded/handbook/tuples.xml doesnt work for me)
Thanks in aDVANCE. |
|
Back to top |
|
|
cwr Veteran
Joined: 17 Dec 2005 Posts: 1969
|
Posted: Mon Mar 02, 2015 3:43 pm Post subject: |
|
|
A while back I built a Gentoo system for a BeagleBone Black which had the root filesystem on NFS.
Cross-compiling the kernel wasn't a problem, and nor was most of the other cross-compiling
I did. I found an ARM Stage 3 somwhere, and built relatively few packages; some stuff (eg. Python)
had to be build natively.
Will |
|
Back to top |
|
|
Leio Developer
Joined: 27 Feb 2003 Posts: 494 Location: Estonia
|
Posted: Tue Mar 03, 2015 2:19 pm Post subject: Re: @ Leio |
|
|
Try https://wiki.gentoo.org/wiki/CHOST meanwhile.
But basically you want the CHOST that your stage tarball uses, and for rpi2 you can pick an ARMv7 one, and you find that CHOST from its make.conf _________________ GNOME team lead; GStreamer; MIPS/ARM64 |
|
Back to top |
|
|
UncleVan n00b
Joined: 08 Feb 2011 Posts: 72
|
Posted: Tue Mar 03, 2015 8:28 pm Post subject: Best way of cross compiling |
|
|
@Leio : Thanks - nevertheless it's a fuzzy area
@cwr:
Simply cross compiling on the host - "i686-pc-linux-gnu" - didn't work well for me either, or is simply too complicated. You can run builds on the target - Raspberry Pi for me - with cross-distcc on some bigger machine; but is still very slow, because all autoconf checks and unpack/install stuff are still local.
Best way I found is with qemu user emulation + chroot into the target file system; could be directly on the SD card too. You'd need binformat (module binfmt_misc) enabled & set up - in the "local" services for example.
Everything is very well documented by Gentoo or Sysresccd.
This waS THE ONLY WAY FOR ME TO RECOMPILE THE GCC ITSELF TO 4.7.3
Funniest thing is if you still could use cross-distcc on the same machine to utilize other cores, gotta try this out.
PS:
Dont know whether applicable for BB though...
PPS:
don't forget to comment out the line in the /etc/ld.so.preload if you are emulating into the original raspbian, or qemu will core-dump |
|
Back to top |
|
|
el_Salmon Guru
Joined: 15 Dec 2003 Posts: 339 Location: Around 2.4GHz
|
Posted: Wed Mar 04, 2015 4:31 pm Post subject: |
|
|
keet wrote: | I have mine working so far. I downloaded a stage 3, but took the boot files from a Raspbian installation. After that and other basic configuration, I set up distcc, ran 'emerge -e system', and installed a few world packages.
I got the Raspberry Pi 2 kernel sources from Github and built them within an hour or so, and rebooted successfully.
Udev failed to build, so I am curious about that, but I'm not worried about it.
Another odd thing that I noticed is that only about 750MB of R.A.M. are available. I set gpu_mem=16, so that is probably not the problem. Considering that it has four cores, and only 1GB of R.A.M., it would be nice to have more available. A potential fix is at http://www.raspberrypi.org/forums/viewtopic.php?f=56&t=98997&start=25, so I will try that when I have time. |
Which instructions have you followed? Gentoo Wiki is for model 1 (armv6), not the new one. I have tried the Wolfgang steps but keyboard doesn't response after first boot, so I cannot continue with the Gentoo setup. _________________ Linux Proud User: HP Pavilion 15-an002ns laptop (KDE Neon), Xiaomi Mi Air 12 (KDE Neon), Raspberry Pi 3 (Nextcloudpi), Docooler MS9 Pro (LibreElec) |
|
Back to top |
|
|
f.kater Guru
Joined: 23 May 2002 Posts: 342 Location: Berlin
|
Posted: Wed Mar 04, 2015 4:38 pm Post subject: |
|
|
Just for those thinking about cross compiling, qemu or direct compilation on
the RPI:
I've tried all the three ways, but finally found that compiling on the RPI is
absolutely ok for everything that might be necessary on that box (samba,
gnumeric, ...), compared to the whole configuration overhead you have with
maintaining gcc/arm cross-compilers, the whole qemu image, dependant arm
libraries etc.
Just compile on the RPI -- I am using the old A model (with systemd
and paludis/cave instead of emerge).
About the kernel: Get the rpi kernel sources via github. Note: Since the
developers are working on new versions constantly, make sure you grab all the
required commits on top of the usual kernel tag (this might require to compare
two or three version tags to understand what is required extra stuff). And
then just try the "simple" kernel config example given in the kernel sources as
a start. I only had to add the HID driver for my cherry keyboard later on.
The resulting kernel is quite small, compilation takes way less than 10+ hours
(see postings above). Also, you might want to avoid kernel modules totally,
so you can exchange kernel images easily. |
|
Back to top |
|
|
UncleVan n00b
Joined: 08 Feb 2011 Posts: 72
|
Posted: Thu Mar 05, 2015 10:49 am Post subject: raspi kernel 3.18.8 successfullybuild |
|
|
Sorry Kater, cant confirm nor recommend: It is much better - and easier in long terms - to spend, say, 6 hours to set up arm cross-compiler + distcc and user-qemu ONCE and them use it anytime anywhere, then to wait days and weeks for some native build. It can not recompile gcc itself (and most other complex stuff) just bec. lack of memory - as far as Raspberry 1 is concerned. I still dont have model 2, but curious about it's gcc performance...
Last evening build the Raspperry kernel 3.18.8 from git: Code: | git clone --depth 1 git://github.com/raspberrypi/linux.git linux-rpi | with Code: | cross-armv6j-hardfloat-linux-gnueabi/gcc-4.8.3:4.8 |
Took 1:40h for Intel(R) Core(TM) i3 CPU U 380 @ 1.33GHz on a single core; with -j4 could do better. Works perfect OOB on both original 2014-12-24-wheezy-raspbian.img as well with my own Gentoo port based on armv6j_hardfp-20130207.tar.bz2.
imagetool-uncompressed.py not needed anymore; just pick /sources/linux-rpi/arch/arm/boot/zImage and "ab die Post", even with the firmware from mid 2013...
I simply took the /proc/config.gz from original raspbian wheezy and run oldconfig over it.
Right know I consider building an armv7a-hardfloat-linux-gnueabi to compile a kernel + modules for the new one, but I still havent got a model 2 board, so someone of you here will have to test it - can someone provide me the original /proc/config.gz ? And the git location, if different ? |
|
Back to top |
|
|
Leio Developer
Joined: 27 Feb 2003 Posts: 494 Location: Estonia
|
Posted: Thu Mar 05, 2015 12:24 pm Post subject: Re: raspi kernel 3.18.8 successfullybuild |
|
|
UncleVan wrote: | Right know I consider building an armv7a-hardfloat-linux-gnueabi to compile a kernel + modules for the new one, but I still havent got a model 2 board, so someone of you here will have to test it - can someone provide me the original /proc/config.gz ? And the git location, if different ? |
Just grab kernel7.img and the matching modules (in the <kernelver>-v7+ modules dir) from git://github.com/raspberrypi/linux.git, boot from that and you can get the config.gz of that.
kernel7.img is booted by armv7 new pi, kernel.img by armv6 old pi's.
You would be getting the firmware files (bootcode.bin, start.elf and many more) from there too. _________________ GNOME team lead; GStreamer; MIPS/ARM64 |
|
Back to top |
|
|
ShiroiKuma n00b
Joined: 09 Nov 2012 Posts: 40 Location: Japan
|
Posted: Thu Mar 05, 2015 12:41 pm Post subject: |
|
|
Just wondering, has anyone got "crossdev -S -v -t armv6j-hardfloat-linux-gnueabi" to work on the Pi2 yet?
Thanks to this thread my Pi2 is running nicely with Gentoo, but thinking... maybe I could use the Pi2 to assist with compiles (distcc) from the Pi1 still laying around.
Everytime I try crossdev I'm ending up with a "the selected processes does not support thumb" error. Just trying one last time with "CLFLAGS="-marm" crossdev -S -v -t armv6j-hardfloat-linux-gnueabi" to see if that helps but I'm not holding hope. It's only the final glibc stage that's failing. |
|
Back to top |
|
|
|