From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-lb0-f182.google.com ([209.85.217.182]) by metis.ext.pengutronix.de with esmtp (Exim 4.72) (envelope-from ) id 1XwDHn-0002Qi-U7 for ptxdist@pengutronix.de; Wed, 03 Dec 2014 18:00:21 +0100 Received: by mail-lb0-f182.google.com with SMTP id f15so13873899lbj.13 for ; Wed, 03 Dec 2014 09:00:14 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: Date: Wed, 3 Dec 2014 18:00:14 +0100 Message-ID: From: Carlos Leyva Guerrero Subject: Re: [ptxdist] Compilation for ARM926ej-s --> S3c2451 Reply-To: ptxdist@pengutronix.de, carlos.leyva@idener.es List-Id: PTXdist Development Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1114715901==" Sender: ptxdist-bounces@pengutronix.de Errors-To: ptxdist-bounces@pengutronix.de To: Guillermo Rodriguez Garcia Cc: "ptxdist@pengutronix.de" --===============1114715901== Content-Type: multipart/alternative; boundary=001a113474f80457f5050952c75f --001a113474f80457f5050952c75f Content-Type: text/plain; charset=UTF-8 On 3 December 2014 at 17:47, Guillermo Rodriguez Garcia < guille.rodriguez@gmail.com> wrote: > 2014-12-03 17:01 GMT+01:00 Carlos Leyva Guerrero : > >> On 3 December 2014 at 12:24, Guillermo Rodriguez Garcia < >> guille.rodriguez@gmail.com> wrote: >> >>> 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 ? >>> >> >> I examined the modifications that FA performed to the 3.6 kernel and >> create a diff patch, then started from a basic 3.6 clean kernel, add the >> patch (there are some modifications on nand hadling an HW ECC, platform >> definition, etc.). >> > > For what it's worth I was in contact with someone who was also using Linux > (I think it was 3.9 in this case) on a Mini2451 derivative and they > confirmed that none of the modifications in the FA kernel are actually > necessary (I explicitly asked about the ECC stuff in the NAND driver). > Mmm ,interesting thing, I will try to check if everything is ok with further kernels (i.e. 3.14) and will share the output. > > >> I also included support for yaffs2 (which is not my goal, but while we >> have a working barebox allowing burning ubi fs....) >> >> >>> >>> > - 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? >>> >> >> The common (not remember exactly) "Decompressing Linux Kernel Image . . . >> " (Same message appears with mmy other compilations, only difference is >> that now it hangs there) >> >> >>> >>> > - 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. >>> >>> >> Have you tested nand performance, HW ecc? >> > > Not yet due to the issue described earlier -- I am initially mounting the > rootfs over NFS because superboot wouldn't let me flash a jffs2 image. > > >> >> If I provide you the patch and config file I did for the kernel 3.6, >> would you mind testing if you are able to compile and boot with it? >> > > Sure, I can do that, but it will probably be 2-3 weeks before I can try > it. I have some high priority stuff to take care off before that (this is > also why I had to put my ongoing work on barebox in standby). > > I can also send you my kernelconfig and platformconfig files if you think > this would be helpful. > Please send them so I can run some additional checks, see diferences in kernels that could explain the non-booting issue. > > >> >> >>> > >>> > - 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 >>> >> >> Did that, but didn't work with my kernel, strange thing. >> >> >>> >>> 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. >>> >>> >> I think I know how you should proceed (not exactly how to implement it, >> :)). >> >> In order to solve you could have two options: first only guessing, second >> the good (but hard) solutions. >> >> - Use minitools instead of scripts, and test the two modes to operate (1, >> preparing the SD card with the fused superboot.bin and an script stsatin >> Usb-mode = yes, 2 boot from nand while pressing K1 button (this will >> automatically activate USB mode)). This way you can launch a binary and >> maybe (just maybe) the nand won't get locked. >> > > I will try this but I dont't think this will work. The NAND locking is not > accidental -- it is done explicitly by superboot through the "tight lock" > bit in the S3C2451 NAND controller. So I expect they would also do the same > in USB mode. > I am in contact with the original manufacturer of the boards, and I have talked with them several time about uboot, I will contact them and will ask if they in fact block the nand in all modes. > > >> Remember to use a good quality mini-usb cables, If you have problems >> detecting the board, messages like "data not accepted by the board", it is >> due to bad quality wires. >> >> - You have to fuse the bootloader into the SD card or the nand, process >> similar to the one used to get uboot working in our boards (there are >> boards in china with uboot working with 2451, and there is some >> documentation from samsung (I can provide it to you if you want). >> >> If first stage bootloader lock nand in any situation, there is no other >> solution than using the SD fused bootloader option. >> > > Yes. This one will work for sure. Actually I am waiting for some boards > with u-boot preloaded, this will help me proceed without worrying about > superboot for the time being :) > This statement is the most surprising!. Pre-loaded uboot? can I ask which provider will serve this boards to you (you can answer by private if you can't share it openly)? I have identify other providers with same chip (s3c2451) but different boards and unless USA FA distributor AAH ships the boards with uboot, I have missed a new distributor!. > Guillermo > Carlos Leyva --001a113474f80457f5050952c75f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 3 December 2014 at 17:47, Guillermo Rodriguez Garcia <guille.rodriguez@gmail.com> wrote:
2014-12-03 17:01 GMT+01:00 Carlos Leyva Guerrero <carlo= s.leyva@idener.es>:
On= 3 December 2014 at 12:24, Guillermo Rodriguez Garcia=C2=A0<guill= e.rodriguez@gmail.com>=C2=A0wrote:
= 2014-12-03 11:58 GMT+01:00 Carlos Leyva Guerrero <carlos.leyva@idener.es>:
&g= t; Buenas Guillermo,
>
> - I used OSELAS arm-v5te pre-build too= lchain (ubuntu repositories).
> - I got two working kernels (one usin= g friendly arm 4.4.3 toolchain and the
> other with the CodeSourcery = 2009q3).
> - With those two kernels, I also got a fully working rootf= s (burned into
> nand using superboot) and i get the system up & = ready, but:

I am curious about this, superboot expects a yaffs2 imag= e, which IIRC
requires kernel patches and is not supported out of the bo= x by
ptxdist. Did you use yaffs2, or did you manage to get superboot to<= br>install a jffs2 or ubi image ?

I exam= ined the modifications that FA performed to the 3.6 kernel and create a dif= f patch, then started from a basic 3.6 clean kernel, add the patch (there a= re some modifications on nand hadling an HW ECC, platform definition, etc.)= .

For what it'= ;s worth I was in contact with someone who was also using Linux (I think it= was 3.9 in this case) on a Mini2451 derivative and they confirmed that non= e of the modifications in the FA kernel are actually necessary (I explicitl= y asked about the ECC stuff in the NAND driver).

Mmm ,interesting thing, I will try to check i= f everything is ok with further kernels (i.e. 3.14) and will share the outp= ut.=C2=A0
=C2=A0
I also included support for yaffs= 2 (which is not my goal, but while we have a working barebox allowing burni= ng ubi fs....)
=C2=A0

>=C2=A0 =C2=A0 = =C2=A0- 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).
>=C2=A0 =C2=A0 =C2=A0- with CS 2009q3= - everything alright but, the specific version of
> binutils used fo= r compiling the toolchain is not publicly available (I
> suppose it w= as a custom build from CodeSourcery) so I cannot use the exact
> same= binutil version (not a big problem but..)
>=C2=A0 =C2=A0 =C2=A0- wit= h 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?

= The common (not remember exactly) "Decompressing Linux Kernel Image . = . . " (Same message appears with mmy other compilations, only differen= ce is that now it hangs there)
=C2=A0

>= ; - 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 pt= xdist patches, and just adapted the mach-mini2451
file from FA.

<= /span>

Have you tested nand performance, HW ecc?

Not yet due to the = issue described earlier -- I am initially mounting the rootfs over NFS beca= use superboot wouldn't let me flash a jffs2 image.
=C2=A0

If I provide you the pat= ch and config file I did for the kernel 3.6, would you mind testing if you = are able to compile and boot with it?
<= br>
Sure, I can do that, but it will probably be 2-3 weeks= before I can try it. I have some high priority stuff to take care off befo= re that (this is also why I had to put my ongoing work on barebox in standb= y).

I can also send you my kernelconfig and platfo= rmconfig files if you think this would be helpful.
<= /blockquote>

Please send them so I can run some addition= al checks, see diferences in kernels that could explain the non-booting iss= ue.=C2=A0
=C2= =A0
=C2=A0
>
> - I am currently testing the system with newer CodeSour= cery version
> (2013.11-33), but i have the same 'problem', c= ustom binutils build.
>
>
> You mentioned that you built = a customized arm-v5te toolchain (well you don
> exactly say so, but g= iven I got no good results with the default
> configuration, I will s= uppose that), Did you add/remove any specific FLAG
> for the toolchai= n compilation (besides mtune)?

I built my own but did not need any c= ustomizations. 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-gnuea= bi
ptxdist go

Did that, but didn'= t work with my kernel, strange thing.
=C2=A0

With the resulting toolchain I am able to build userland binaries andalso a kernel using ptxdist. For this I created a new "platformconfi= g"
based on platform-friendlyarm-mini2440. In my first tests I just=
modified the platform name (as ptxdist places all output files in
pl= atform-${platformname}) and selected the new Toolchain. I did not
touch = any other architecture specific flags such as hardware floating
point su= pport and so on -- I wanted to do a basic test first (which
worked fine)=

>
> Regarding the barebox, I am pretty interested. I was p= lanning also to try it
> but I have no more available hours in the da= y, ;). Please keep me up with
> you progress and let me know if you n= eed anything.

I got it to the point where barebox is booting as a 2n= d stage
bootloader, does low level PLL and SDRAM configuration, and has<= br>working support for timers, serial ports, and Ethernet. Next on the
l= ist was NAND support but then I found that when you use superboot to
run= a "user binary" (with Action=3DRun instead of Action=3DInstall) = it
locks the NAND in a way that cannot be unlocked by software. So I nee= d
to find a way around superboot in order to continue testing this.
<= font color=3D"#888888">

I think I= know how you should proceed (not exactly how to implement it, :)).=C2=A0

In order to solve = you could have two options: first only guessing, second the good (but hard)= solutions.

- Use= minitools instead of scripts, and test the two modes to operate (1, prepar= ing the SD card with the fused superboot.bin and an script stsatin Usb-mode= =3D yes, 2 boot from nand while pressing K1 button (this will automaticall= y activate USB mode)). This way you can launch a binary and maybe (just may= be) the nand won't get locked.=C2=A0

I will try this but I dont't think this wi= ll work. The NAND locking is not accidental -- it is done explicitly by sup= erboot through the "tight lock" bit in the S3C2451 NAND controlle= r. So I expect they would also do the same in USB mode.

I am in contact with the original manu= facturer of the boards, and I have talked with them several time about uboo= t, I will contact them and will ask if they in fact block the nand in all m= odes.
=C2=A0
=C2=A0
Remember to use a good = quality mini-usb cables, If you have problems detecting the board, messages= like "data not accepted by the board", it is due to bad quality = wires.

=
- You have= to fuse the bootloader into the SD card or the nand, process similar to th= e one used to get uboot working in our boards (there are boards in china wi= th uboot working with 2451, and there is some documentation from samsung (I= can provide it to you if you want).=C2=A0

If first stage bootloader lock nand in any situat= ion, there is no other solution than using the SD fused bootloader option.<= /div>

Yes. This one wil= l work for sure. Actually I am waiting for some boards with u-boot preloade= d, this will help me proceed without worrying about superboot for the time = being :)

This state= ment is the most surprising!. Pre-loaded uboot? can I ask which provider wi= ll serve this boards to you (you can answer by private if you can't sha= re it openly)? I have identify other providers with same chip (s3c2451) but= different boards and unless USA FA distributor AAH ships the boards with u= boot, I have missed a new distributor!.


=
=
<= div>
=
Guil= lermo

Carlos Leyva



--001a113474f80457f5050952c75f-- --===============1114715901== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- ptxdist mailing list ptxdist@pengutronix.de --===============1114715901==--