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.
>> 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.
> 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.
I agree as you increase the number of people debugging a problem the
amount of time that the problem will be fixed in decreases. Although I
think you would be surprised to see how quickly Technologic Systems is
able to fix bugs in software we have developed. Send in a bug report,
and we can see how long it takes to post a patch. Assuming this is a
problem with Technologic Systems software, and not a custom block driver
someone wrote...
A bug report can be sent to support_at_embeddedarm_dot_com or eddie at
the same domain...
--
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/
|