ts-7000
[Top] [All Lists]

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

To:
Subject: [ts-7000] Re: Scheduled activity on a TS-7800
From: "charliem_1216" <>
Date: Thu, 26 Jun 2008 16:59:04 -0000
Hi Eddie --

--- In  Eddie Dawydiuk <> wrote:
>
> Hello,
> 
> >>> * 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.
> 
> We don't typically document generic Linux kernel/gcc related issues. We 
> have several customers who are using the SD card object file in other 
> OSes(e.g. winCE) as well as software running on the bare hardware(FAA). 
> Although if a number of people on this list are having difficulty 
> compiling an SD card block driver by linking against an object file we 
> can point them in the right direction. If anyone would find an example 
> helpful please let me know, I can put together a sample  Makefile 
> demonstrating how to accomplish this.

I think a lot of people would appreciate that.

For an idea of the issues, see threads starting here:
http://tech.groups.yahoo.com/group/ts-7000/message/11859
http://tech.groups.yahoo.com/group/ts-7000/message/10666
http://tech.groups.yahoo.com/group/ts-7000/message/9422

My guess is that the issues relate to tool-chain version matching,
kernel symbol versioning, EABI vs OABI, hard-float vs sof-float,
ep93xx vs orion, etc.

> 
> >> 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.  
> 
> Reliability is a very high priority, as a result once software has been 
> released we only change the software to fix bugs. We do not release new 
> software to add new features. I should qualify this by saying the above 
> statements apply to our default shipping software. Our large customers 
> freak out when the board silkscreen changes colors-- transitioning our 
> current shipping software would be chaos(paraphrased from a post from 
> Jesse).
> 
> >> 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.
> 
> Interesting, unfortunately no one has reported such a failure to 
> Technologic Systems. I would highly recommend someone put together some 
> information describing the failure condition, as well as some 
> information on how to reproduce the failure and send this
information as 
> a bug report to Technologic Systems.

I just saw it today, and suggested they both report it:
http://tech.groups.yahoo.com/group/ts-7000/message/11881

Regards, ......... Charlie


------------------------------------

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