On Mon, 29 Oct 2007, Guennadi Liakhovetski wrote:
>1. Why have you dropped he list from cc??? Please, when you reply to
>email, keep the contents, if you can, and re-add the list.
Well actually it's just a mistake. It's now corrected ;)
>On Mon, 29 Oct 2007, snatcher snatcher wrote:
>> Hi Guennadi :)
>> My goal is to merge the arch-orion stuff (the arch that will be
>> in the vanilla kernel one day) in the 2.6.23 (or 2.6.24-rc1) kernel
>> to make it boot a kurobox pro ! It's sonds simple as the guys from
>> Marvell sent the patches but I got some exchanges with the guy from
>> marvell and I ack that the actual patch can't run a kurobox pro
>> (actually it can only run 88f5281 devices not 88f5182 ones) and told
>> what to do to enable 88f5281 devices support ! I need to test that
>> of course to add the buffalo stuff in the kernel ;)
>The first series of patches from Tzachi was for the Marvell Feroceon
>core family, the latest patch series explicitely says to support
>(RD(2) NAS from Marvell and KuroBox-Pro). Have you talked to Tzach
>that? Can you forward those emails to the list too? Can we have an OPEN
>discussion with him either on the linkstationwiki or on the arm-kernel?
>Private email exchange really makes things very difficult.
Yes I talked to Tzachi after the last patch set, and he told me to merge some of the stuff from the previous patch to enable 88f5182 support (the mandatory things beeing the change in arch/arm/boot/compressed/head.S file and the changes in proc-arm926.S file)!
The origin of that is that the 88f5182 SoC have a standard ARM926 id while the 88f5281 have a specific tag (so the boot process can identify it as a specific processor attached to the description in proc-feroceon.S file).
So for buffalo's devices (using the 88f5182 processor), we have to merge some modifications in the proc-arm926.S (using the CONFIG_CPU_FEROCEON switch would be the best way to do it)! Tzachi is also using a specific type in /arch/arm/tool/mach-type for the kurobox pro, to support that we have to update the u-boot to give the new value, or to change the mach-type file to set kurobox pro id to the value given by buffalo's u-boot (526) => The correct thing to do will of course be to update the u-boot, but for now I've changed the value in mach-type (I'll play with u-boot once it'll boot correctly ...)
Tzachi also told me to set the u-boot var 'enaWrAllo' to 'no' (default value is yes) to disable Write Allocate. The words he used to explain that are : "There is a problem that I need to solve with this feature, but not at the moment. Just disable it for now.".
I won't copy/paste his mails as I don't know if he would be happy about that, but I can tell you the important informations (beside technical stuff descibed just above) I got from our discution :
- Tzachi submitted what could be merged in vanilla kernel
- For now only ethernet (merged in 2.6.24-rc1) and USB support have been released in some mailing list. Sata support will be released later (don't know when anyway)
- Specific hardware support that can't be merged in the vanilla kernel (ie : XOR hardware & CESA engine support) will be available (later) in some out-of-tree patches
You can of course send some question/answers in lak mailing list, he will be happy to see some interest in his patch set !
>> You can read about my progress here :
>> http://forum.nas-central.org/viewtopic.php?f=18&t=4242 . I'll be idle
>> that topic for 1 or 2 weeks as I have some other thing to do :(
>What I suggested was a developer's (your) progress-log (blog) with you
>being the owner and posting the linear progress scale, and others
>the ability to comment to your posts or discuss them. Whereas Forum is
>means of communication, where everybody can post to any (normal)
>You can certainly abuse forum as a developer log, but...
Well, I've never used such a thing ... I'll check what is the best way to do such a thing and I'll tell you ;)
>> See you,
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail