Changing functions/code on running target - Embedded

This is a discussion on Changing functions/code on running target - Embedded ; Hi, I'm running 2.4 on an Intel IXP425, and I'm not happy with my development efficiency: - I modify code in the kernel, kernel modules, and applications. - Compilation of the image takes 3 minutes, which I find annoying. - ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Changing functions/code on running target

  1. Changing functions/code on running target

    Hi,

    I'm running 2.4 on an Intel IXP425, and I'm not happy with my
    development efficiency:

    - I modify code in the kernel, kernel modules, and applications.
    - Compilation of the image takes 3 minutes, which I find annoying.
    - A reboot takes 30 seconds and destroys all state.
    - Some kernel modules cannot be reloaded, so a full compile and reboot
    is necessary.

    The simplest way to solve all these problems would be the ability to
    change functions on the running target. It should not matter if the
    code is in the kernel or in an application. Is there anything like
    this?

    Thanks,
    Daniel


  2. Re: Changing functions/code on running target

    In article <1156324874.511569.74560@m73g2000cwd.googlegroups.c om>,
    "Daniel" writes:
    > Hi,
    >
    > I'm running 2.4 on an Intel IXP425, and I'm not happy with my
    > development efficiency:
    >
    > - I modify code in the kernel, kernel modules, and applications.
    > - Compilation of the image takes 3 minutes, which I find annoying.
    > - A reboot takes 30 seconds and destroys all state.
    > - Some kernel modules cannot be reloaded, so a full compile and reboot
    > is necessary.
    >
    > The simplest way to solve all these problems would be the ability to
    > change functions on the running target. It should not matter if the
    > code is in the kernel or in an application. Is there anything like
    > this?


    Well, if the code is in the kernel, and if it is not a module, then
    you can not avoid a reboot, thereby loosing all state. If it *is* a
    module, it should be possible to compile it seperate from the kernel and
    unload/reload it in a running system. However, you said above that
    "Some kernel modules cannot be reloaded". Care to explain why?

    IMHO the ideal setup for quick development turnaround times is
    an NFSroot system: Keep the root file system on the development
    host and let the target mount it via NFS. That way, you can rebuild
    any files on the development host and just load them on the target.
    We do that all the time.


    Rob

    --
    Robert Kaiser email: rkaiser AT sysgo DOT com
    SYSGO AG http://www.elinos.com
    Klein-Winternheim / Germany http://www.sysgo.com

  3. Re: Changing functions/code on running target

    > However, you said above that "Some kernel modules cannot be
    > reloaded". Care to explain why?


    We are using the Intel Ethernet driver module ixp425_eth.c, which
    complains about "locked resources" or so.

    > IMHO the ideal setup for quick development turnaround times is
    > an NFSroot system: Keep the root file system on the development
    > host and let the target mount it via NFS. That way, you can rebuild
    > any files on the development host and just load them on the target.
    > We do that all the time.


    We use a commercial Linux distribution (not sure if I'm allowed to
    name it), which officially doesn't support NFS root file systems.
    Maybe there is a simple way of making this work?

    -- Daniel


  4. Re: Changing functions/code on running target

    Daniel wrote:

    [snip]

    > We use a commercial Linux distribution (not sure if I'm allowed to
    > name it), which officially doesn't support NFS root file systems.
    > Maybe there is a simple way of making this work?


    Check Documentation/nfs-root.txt in the kernel source directory.

    --
    :wq
    ^X^Cy^K^X^C^C^C^C

  5. Re: Changing functions/code on running target

    In article <1156428950.313510.143760@i3g2000cwc.googlegroups.c om>,
    "Daniel" writes:
    >> However, you said above that "Some kernel modules cannot be
    >> reloaded". Care to explain why?

    >
    > We are using the Intel Ethernet driver module ixp425_eth.c, which
    > complains about "locked resources" or so.


    Hmm, that could be a bug in the driver. Anyway, if you build an
    NFSroot system, you don't want to unload the NIC driver as that
    is your link to the root file system. Typically, you would link
    it into the kernel statically.

    >
    >> IMHO the ideal setup for quick development turnaround times is
    >> an NFSroot system: Keep the root file system on the development
    >> host and let the target mount it via NFS. That way, you can rebuild
    >> any files on the development host and just load them on the target.
    >> We do that all the time.

    >
    > We use a commercial Linux distribution (not sure if I'm allowed to
    > name it), which officially doesn't support NFS root file systems.




    There is an embedded Linux distribution available that comes with
    a number of preconfigured configurations, NFSroot being one of them.
    (Hint: see my .sig)




    > Maybe there is a simple way of making this work?


    As another poster has suggested: read Documentation/nfs-root.txt


    Good Luck

    Rob

    --
    Robert Kaiser email: rkaiser AT sysgo DOT com
    SYSGO AG http://www.elinos.com
    Klein-Winternheim / Germany http://www.sysgo.com


+ Reply to Thread