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