From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-wg0-x22d.google.com ([2a00:1450:400c:c00::22d]) by metis.ext.pengutronix.de with esmtp (Exim 4.72) (envelope-from ) id 1Xw82W-0007a4-Li for ptxdist@pengutronix.de; Wed, 03 Dec 2014 12:24:13 +0100 Received: by mail-wg0-f45.google.com with SMTP id b13so19777123wgh.18 for ; Wed, 03 Dec 2014 03:24:07 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: Date: Wed, 3 Dec 2014 12:24:07 +0100 Message-ID: From: Guillermo Rodriguez Garcia Subject: Re: [ptxdist] Compilation for ARM926ej-s --> S3c2451 Reply-To: ptxdist@pengutronix.de List-Id: PTXdist Development Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ptxdist-bounces@pengutronix.de Errors-To: ptxdist-bounces@pengutronix.de To: carlos.leyva@idener.es Cc: "ptxdist@pengutronix.de" 2014-12-03 11:58 GMT+01:00 Carlos Leyva Guerrero : > Buenas Guillermo, > > - I used OSELAS arm-v5te pre-build toolchain (ubuntu repositories). > - I got two working kernels (one using friendly arm 4.4.3 toolchain and the > other with the CodeSourcery 2009q3). > - With those two kernels, I also got a fully working rootfs (burned into > nand using superboot) and i get the system up & ready, but: I am curious about this, superboot expects a yaffs2 image, which IIRC requires kernel patches and is not supported out of the box by ptxdist. Did you use yaffs2, or did you manage to get superboot to install a jffs2 or ubi image ? > - with FA - I cannot compile udev, the used glibc version for such > toolchain seems lower than 2.10, so I get errors compiling udev ('accept4' > related). > - with CS 2009q3 - everything alright but, the specific version of > binutils used for compiling the toolchain is not publicly available (I > suppose it was a custom build from CodeSourcery) so I cannot use the exact > same binutil version (not a big problem but..) > - with the prebuild arm5vte oselas version, after burning to the board, > the kernel get extracted and then .. no output, system hang. What is the last thing you see in the console? > - I also used kernel from FA as source, but some modifications were done, > i.e (remove initramfs, removed cpio file, ...) Note that I did not use the kernel from FA. I used a standard 3.7 kernel with the ptxdist patches, and just adapted the mach-mini2451 file from FA. > > - I am currently testing the system with newer CodeSourcery version > (2013.11-33), but i have the same 'problem', custom binutils build. > > > You mentioned that you built a customized arm-v5te toolchain (well you don > exactly say so, but given I got no good results with the default > configuration, I will suppose that), Did you add/remove any specific FLAG > for the toolchain compilation (besides mtune)? I built my own but did not need any customizations. Started from OSELAS.Toolchain-2012.12.1 (same as is used in the last published mini2440 BSP), then just did: ptxdist clean rm selected_ptxconfig ptxdist select ptxconfigs/arm-v5te-linux-gnueabi ptxdist go With the resulting toolchain I am able to build userland binaries and also a kernel using ptxdist. For this I created a new "platformconfig" based on platform-friendlyarm-mini2440. In my first tests I just modified the platform name (as ptxdist places all output files in platform-${platformname}) and selected the new Toolchain. I did not touch any other architecture specific flags such as hardware floating point support and so on -- I wanted to do a basic test first (which worked fine) > > Regarding the barebox, I am pretty interested. I was planning also to try it > but I have no more available hours in the day, ;). Please keep me up with > you progress and let me know if you need anything. I got it to the point where barebox is booting as a 2nd stage bootloader, does low level PLL and SDRAM configuration, and has working support for timers, serial ports, and Ethernet. Next on the list was NAND support but then I found that when you use superboot to run a "user binary" (with Action=Run instead of Action=Install) it locks the NAND in a way that cannot be unlocked by software. So I need to find a way around superboot in order to continue testing this. Guillermo -- ptxdist mailing list ptxdist@pengutronix.de