Hi --
--- In Eddie Dawydiuk <> wrote:
>
> Hello,
>
> > * Enable HRT by default. For your ep93xx boards, this should be just
> > a matter of selecting it when make menuconfig. For your orion
> > board(s), there would be some back-porting, but AFAIK the code is all
> > there in later kernels. Orion support in mainline didn't come until
> > after 2.6.21.
> >
> > * Enable low latency option (CONFIG_PREEMPT). Same as above. These
> > two, HRT & PREEMPT, would give most users features they want from an
> > RT system, without resorting to the complexities of other, hard-RT
> > approaches. They are in the vanilla kernel.
>
> As far as I know we have PREEMPT support, it is enabled by default in
> our default TS-7800 config file. Please let me know if I am mistaken,
> but I see CONFIG_PREEMPT=y in our default TS-7800 config file.
>
> > * Make it possible access to use your binary SD module in a vanilla
> > kernel build.
>
> This should be possible, I haven't been following this mailing list to
> closely but we provide a OS independent object file that provides the
> read, write, reset functionality for the SD card. I can see the block
> driver may need to be modified as the API changes over time, but the
> block driver is open source. Can you provide more information on what
> you mean?
I have not pursued this myself, but judging from the number of
postings on the ML, it is either not working when used outside of the
TS kernel (or toolchain?), or it's not sufficiently clear what needs
to be done. Maybe the process just needs to be documented, with an
example.
>
> This is good to hear, we are interested in hearing what features are
> customers find useful. I'll make a note of this and if we get some free
> cycles and management buys in I'll see if we can get these features
back
> ported.
>
> >> As we all know Linux is under constant development, new features are
> >> constantly being added. It would be great if Technologic Systems
would
> >> back port every new feature in Linux. But unfortunately the
> >> managers/business people tell us it's not economical to do this.
> >
> > Well, it's a two-way street: if you (or the community) does the
> > up-front work to get your board support into the vanilla kernel, then
> > these new features come automatically as they are added later!
> > Although it is work to get your code accepted (as Alex can attest), it
> > is usually for good reason. Later, if a developer adds a feature to
> > the kernel, breaking an internal ABI, then he is responsible for
> > fixing what he breaks in the process, so there is much more on-going
> > community maintenance for mainline code.
>
> I agree with you. We had a meeting when choosing which kernel to use
for
> the TS-7800. I suggested working on getting the TS-7800 in the
mainline.
> I made the same argument, it would be more work up front, but in the
> long run the Linux community would help support our kernel. Although at
> the time the Orion SOC was not supported in mainline, so we would have
> been responsible for getting the Orion SOC supported in mainline as
well
Yes, platform support is a big stumbling block, especially for a
first-time contributor to the kernel, and dealing with a secretive
vendor on top of that (Marvell).
> as the TS-7800. The conclusion was the added work to get the TS-7800
and
> Orion supported in the mainline kernel was an unknown. There was
quite a
> bit of risk involved, and from a business standpoint management decided
> it was not a wise decision. I guess what it comes down to from a
> business standpoint is would our customers be willing to pay more money
> for a TS-7800 if it was supported in the mainline. As I mentioned above
> management came to the conclusion more than likely our customers would
> not be willing to pay more money for a TS-7800 that is supported in the
> mainline.
Maybe not pay more, but IMHO you may draw more customers ...
>
> There are some engineers here at Technologic Systems who feel it would
> be wise for Technologic Systems to get our kernels in the mainline.
> While others would argue it is not beneficial from a business
standpoint
> as Technologic Systems will never change default shipping kernels, so
> why should we spend more time/money and take a bigger risk to get
> mainline support if we never plan to ship any of the new kernels.
Good point, though some would question the 'never plan to ship new
kernels' part of that. No code is perfect, and fixes, silicon
workarounds & new features will be coming for a long time. If you are
not monitoring ongoing arm kernel development and doing the backports,
those fixes will be lost to TS-7800 users.
>
> Although in the near future we will be releasing a PPC based SBC,
and as
> far as I know the SOC already has mainline support. So I can guarantee
> you there will be a meeting to decide what kernel to use. The question
> will more than likely be brought up again, are our customers willing to
> pay more money for a TS-xxxx board that has mainline support...
IMHO, if the platform support is already in, then the board support is
almost trivial, and would be well-worth your while. Again, not to
command a higher price, but to appeal to a wider audience.
>
> > This bug has been around forever, starting in redboot on ts-7200, and
> > Jesse was going to look into fixing it [1]. The failure is that
> > TS-7XXX boards are purported to work with vanilla kernels, but if a
> > naive user builds an unpatched kernel, or does not modify the binary
> > image, he gets a puzzling failure to boot. It's all about playing
> > nice with others, and making your product easy to use for people who
> > choose to use SW other than your default build.
>
> Interesting, thanks for the information. I'll push to see if we can
> register a unique board ID in the future.
>
> >> Please keep in mind one of our primary concerns as an industrial SBC
> >> vendor is reliability. Technologic Systems doesn't typically make
> >> changes to there design unless there is a good reason to do so.
> >
> > I agree completely. However, by locking into a kernel version
> > prematurely, (ie, orion boards before orion support was in main-line
> > kernel),
>
> We are primarily a hardware company, we don't choose components
based on
> whether there is Linux support in the mainline or not. We choose
You mis-interpreted my comment :). I just think it's just unfortunate
that you are locked forever to a kernel version that is lacking in
mainline support for the orion chips, when orion SOC support is so
much better a short while later. But I understand your decision ...
> components based on cost and functionality. As you've pointed out it is
> important to you that our kernels are supported in the mainline, but
> from feedback from our customers the majority or our customers could
> care less. Management would argue they would prefer we didn't have
> mainline support as it reduces the cost of our products. Not
Maybe up front, but look at long term support: take the recently
reported 'sd writes hang the system after running a while' for
example. How many cycles will TS spend trying to replicate that,
debug it, fix it, test the fixes, etc., all by a small (handful?) of
TS engineers. Now hypothetically, if the user was running a vanilla
kernel (including SD drivers), he would post on one of the many kernel
lists, and probably have a diagnosis & fix before the end of the day.
> product until there is mainline support or designing a product around
> what is supported in the mainline kernel isn't really a viable option.
>
> > Hope this doesn't come off too critical. You asked :), and that's a
> > good thing!
>
> Not at all. I think it's very important to get feedback from our
> customers. We appreciate your comments. We will take them into account
> when making decisions on future products.
OK, I'll shut up now :) It's good to hear there is internal
discussion about vanilla kernel support; I just wanted to give the
advocates some other arguments.
Regards, ......... Charlie
>
> --
> Best Regards,
> ________________________________________________________________
> Eddie Dawydiuk, Technologic Systems | voice: (480) 837-5200
> 16610 East Laser Drive Suite 10 | fax: (480) 837-5300
> Fountain Hills, AZ 85268 | web: www.embeddedARM.com
>
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|