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

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

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

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

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

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

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

-- 
ptxdist mailing list
ptxdist@pengutronix.de