Re: 32 bit architecture advice (ARM, PPC etc.)

From: Mad_at_Spammers (ih8sp4m_at_yahoo.com)
Date: 11/06/03

  • Next message: Neil Horman: "Re: Making code non-preemptable" 
    Date: 6 Nov 2003 10:57:58 -0800

    "Lewin A.R.W. Edwards" <larwe@larwe.com> wrote in message news:<BZWdnfRwY-MJwjeiU-KYiw@broadviewnet.net>...
    > > I see your point and have to agree. As for the problem, there is not
    > > properly a specificaly one, just bad feelings based upon what I have
    > > read in mailing lists, particularly comments in RTAI's one and several
    > > associated bugs to the complexity added by PXA's interrupts operation
    >
    > Okay. Well, it sounds like you're at the start of a hardware/software design
    > project, and having qualms about committing down a particular HW path,
    > because the potential difficulty of HW/SW integration is shrouded in mist. I

    That's exactly the point.

    > sympathize deeply with that problem.
    >

    Thanks. I appreciated it. :-)

    > Having done a _little_ PPC development, and quite a lot of ARM development,
    > I'd have to say that ARM is considerably easier to understand. So for a
    > project where I know I'll have to be doing a lot of hand-rolling in assembly
    > language, I'd be instantly biased towards ARM for that reason only.
    >
    > Yes, ARM requires some software handling of interrupt priorities [usually].
    > There's a little overhead there. But it's not onerous.
    >

    That's part of the information I was after.

    > > any time soon. So one must stick either with kernel 2.4.19 or go to
    > > 2.6 if wants PXA support *and* bug fixes to several bug fixes ever
    >
    > If there is no compelling reason to use 2.4, I'd lean heavily towards 2.6.
    > I'm trying to migrate myself, but I'm having trouble with some third-party
    > drivers that can't be compiled [yet?] - USB peripherals, all of them. Seems
    > a bunch of definitions were deleted or renamed in the USB handling code, and
    > 2.4 drivers won't build as a result. Apart from that, I am very happy with
    > 2.6 (on x86, anyway).

    There's three reasons to use 2.4.x. First is stability: just remember
    how long it took for 2.4 series to become stable (only with 2.4.16
    IIRC and still there were some minor problems with 2.4.17). I hope 2.6
    series follows 2.2 series track which became stable quite fast - IIRC
    with 2.2.5. The second reasib is only now RTAI folks is starting to
    actively (or should I say agressively) develop for 2.6. They seem to
    be as conservative in some ways as my software buddys here (I started
    with hardware and do software mostly but still design hardware). The
    third reason you just mentioned: drivers.

    >
    > > as things will eventually stabilize (and maybe the backport will be
    > > done). The question is how long it will take.
    >
    > The complementary question is how long it will be before your hardware is
    > ready for the "real OS", too :)

    In not more than three months. Still we have a PXA255 based board here
    to start develping software. The reason I originaly posted is that
    Intel support here in Brazil has been damned bad (I started with
    Motorolas iMX based ADS - and their support was quite opposite to
    Intels - unfortunately its LCD controller does not support DSTN
    panels) and I started wondering if I shouldn't switch to another
    architecture while in early development steps even though it should
    delay my schedule. Your postings helped me to make up my mind and I
    really appreciated them. As for support, I'm affraid I am on my own
    (some corporations definetely are not small companies friendly).
    Regarding Linux, I will stick with 2.4.19 and focus on RTAI which will
    need some effort to work things out for my application.

    Do you have experience with or recommend some JTAG tool aimed at GNU
    toolchain?

    Again, thanks a lot for your help.

    Elder.

  • Next message: Neil Horman: "Re: Making code non-preemptable"

    Relevant Pages

    • Re: [PATCH 0/6] MSI portability cleanups
      ... which is using hardware isolation so it is safe to ... The enable/disable ops are optional for that reason. ... However I don't think it will be to hard to support your HV once we get ... other approach would be to remove it, have each backend have it's own ...
      (Linux-Kernel)
    • Re: Linux 2.6.16.30-pre1
      ... I avoided to add support for new hardware. ... The reason is very simple. ... That was a bugfix as the driver could not access that device without ...
      (Linux-Kernel)
    • Re: Wireless networking in CentOS 4.4
      ... Is there any reason that you need to use Cent OS 4.4 for this? ... would surely have better support for newer hardware such as you are running. ... Fedora or Ubuntu would probably work even better on your laptop. ...
      (RedHat)
    • Re: what version to use for home desktop?
      ... >> the reason I ... >> want CURRENT is mostly hardware support (e.g. ... I don't have one of those, but the hardware notes for 4.10 as can be ...
      (freebsd-stable)
    • Re: rt20 scheduling latency testcase and failure data
      ... The system was under heavy network load for some of the time, ... # Firmware Drivers ... # ACPI Support ... # ISDN4Linux hardware drivers ...
      (Linux-Kernel)