Re: [ptxdist] Compilation for ARM926ej-s --> S3c2451

[Carlos Leyva Guerrero <carlos.leyva@idener.es>]

[-- Attachment #1.1: Type: text/plain, Size: 9199 bytes --]

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 <carlos.leyva@idener.es>:
> > 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.). 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?

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?


> >
> > - 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.
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.

Guillermo


Carlos



-- 



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 <carlos.leyva@idener.es>:
> > 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
>

[-- Attachment #1.2: Type: text/html, Size: 13433 bytes --]

[-- Attachment #2: Type: text/plain, Size: 48 bytes --]

-- 
ptxdist mailing list
ptxdist@pengutronix.de