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

[Guillermo Rodriguez Garcia <guille.rodriguez@gmail.com>]

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

2014-12-03 17:01 GMT+01:00 Carlos Leyva Guerrero <carlos.leyva@idener.es>:

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

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


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


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


> 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 :)

Guillermo

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

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

-- 
ptxdist mailing list
ptxdist@pengutronix.de