Loading ...
Sorry, an error occurred while loading the content.

Re : Re : LS-Pro patches from Tzachi / Marvell

Expand Messages
  • snatcher snatcher
    ... this ... Well actually it s just a mistake. It s now corrected ;) ... merged ... and ... me ... and ... CPU ... 88f5182 ... AFTER ... Yes I talked to
    Message 1 of 2 , Oct 29, 2007
    • 0 Attachment
      On Mon, 29 Oct 2007, Guennadi Liakhovetski wrote:

      >Hi Sylver
      >
      >1. Why have you dropped he list from cc??? Please, when you reply to
      this
      >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
      merged
      >> in the vanilla kernel one day) in the 2.6.23 (or 2.6.24-rc1) kernel
      and
      >> 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
      me
      >> what to do to enable 88f5281 devices support ! I need to test that
      and
      >> of course to add the buffalo stuff in the kernel ;)
      >
      >The first series of patches from Tzachi was for the Marvell Feroceon
      CPU
      >core family, the latest patch series explicitely says to support
      88f5182
      >(RD(2) NAS from Marvell and KuroBox-Pro). Have you talked to Tzach
      AFTER
      >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
      on
      >> 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
      having
      >the ability to comment to your posts or discuss them. Whereas Forum is
      a
      >means of communication, where everybody can post to any (normal)
      thread.
      >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 ;)

      Sylver

      >
      >Thanks
      >Guennadi
      >
      >> See you,
      >> Sylver
      >





      _____________________________________________________________________________
      Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail
    • Guennadi Liakhovetski
      Please, also wrap your lines at about 72 characters, makes it easier to read and reply, thanks. ... Ok, I ll have to read it more attentively when I come round
      Message 2 of 2 , Oct 29, 2007
      • 0 Attachment
        Please, also wrap your lines at about 72 characters, makes it easier to
        read and reply, thanks.

        On Mon, 29 Oct 2007, snatcher snatcher wrote:

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

        Ok, I'll have to read it more attentively when I come round to trying it,
        thanks for the info!

        > I won't copy/paste his mails as I don't know if he would be happy about
        > that,

        Sure, only upon his agreement.

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

        Sure, just for now I don't have anything to say:-)

        Just a request to you - you said you wanted to commit his patches and any
        additional modifications you do into the sourceforge svn repository. We
        talked with Jon a few weeks ago and agreed that it would be better to do
        the *Pro development in a git tree. He's even set up a git server on the
        linkstationwiki server, and we wanted to start committing there, but then
        Jon said, that Tzachi is about to present his patches, so, we decided to
        wait. Would be really nice to use git instead of svn - for easier
        interoperability with mainline developers and for all the advantages of
        git.

        Thanks
        Guennadi
        ---
        Guennadi Liakhovetski
      Your message has been successfully submitted and would be delivered to recipients shortly.