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