On Fri 17 Aug 2007 17:10, David Brownell pondered:
> On the other hand, maybe you want your "typical" customer to
> be more of a systems integrator than anything else.
We are getting yelled at by our customers (I was on the phone yesterday),
because the kernel build environment we distribute (the default) was not
inside Eclipse, and someone couldn't push a button on a GUI rather than
typing "make".
While Linux and other open source software is free, for some taking advantage
of its benefits can require a significant investment in time. Linux is
powerful, rich, and flexible. It is these very characteristics that make
Linux so appealing that also create a significant level of complexity.
We are seeing more and more "first time buyers" jumping from bare metal - no
OS, to Linux. For them - the ease of not having to write configuration files
gives them a warm fuzzy feeling when they boot their board, and it
just "works".
> > While potentially causing conflicting usage, for someone without
> > detailed hardware knowledge. The platform device board file is a good
> > thing to track conflicting memory or IO space resources as well as
> > IRQs. We also utilize platform device files for exactly these purposes.
> >
> > The dynamic resource allocation for pinmux and gpio seems to us the
> > best way to handle things. The "resource allocation" mechanism will
> > spill an error and dump in case conflicting usage is detected. It'll
> > also tell you who is causing the conflicting usage.
>
> That's your call, of course. I was pointing out why the "early"
> binding of pin resources is the more usual strategy with Linux.
> A "late" strategy is a bit surprising, and has its own issues.
Agreed - Every implementation has its own issues, but based on what we were
being asked to do - it was the best way we could accommodate everyone.
> > >That said, how you handle pinmux on Blackfin is your business.
> > >
> > >But you should know that this approach seems idiosyncratic and
> > >more complex than needed: when pin config is done early and as
> > >part of board setup, drivers don't need to care about it or to
> > >handle any pinmux errors. And heck, products can sometimes be
> > >shipped with the bootloader having done all pinmux setup, so
> > >Linux won't need to worry about it at all. That can help ship
> > >multiple board revisions using the same kernel.
> >
> > This works for fixed function boards.
>
> That is, for typical products embedding Linux...
We have multiple customers shipping the same bootloader/kernel binary on
different products, and the only difference is the /etc/rc file - which
drivers they install, and a few things in userspace.
Could this be smaller - sure - but NAND is cheap (according to them) compared
to the effort and cost of maintaining and testing multiple kernel versions
for every product.
Could this be faster - sure - but it is done at init - and then never again.
We have a ~2-3 second boot time - maybe we shave off a few ms - things go
pretty fast at 600MHz.
-Robin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
