ts-7000
[Top] [All Lists]

Re: [ts-7000] Re: Scheduled activity on a TS-7800

To:
Subject: Re: [ts-7000] Re: Scheduled activity on a TS-7800
From: Eddie Dawydiuk <>
Date: Wed, 25 Jun 2008 09:04:23 -0700
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?

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

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.

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

> 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 
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 releasing a 
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.

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

<Prev in Thread] Current Thread [Next in Thread>
Admin

Disclaimer: Neither Andrew Taylor nor the University of NSW School of Computer and Engineering take any responsibility for the contents of this archive. It is purely a compilation of material sent by many people to the birding-aus mailing list. It has not been checked for accuracy nor its content verified in any way. If you wish to get material removed from the archive or have other queries about the archive e-mail Andrew Taylor at this address: andrewt@cse.unsw.EDU.AU