--- In "Breton M. Saunders" <>
wrote:
>
> Daniel Smolik wrote:
> > Doug napsal(a):
> >
> >>
> >>
> >> --- In <ts-7000%40yahoogroups.com>,
> >> "Breton M. Saunders" <breton.saunders@> wrote:
> >>
> >> Hey Brett,
> >>
> >> > I am unconvinced by the stability of the sdcard driver.
> >>
> >> Me too. We first noticed this problem because it was causing corrupted
> >> versions of shared libraries to be loaded into RAM, causing a strange
> >> program crash. We also saw other odd behavior (playsound was cutting out
> >> on some sounds and making the sounds stutter, and saying invalid format
> >> on others). When we loaded our program from the NAND instead of the SD
> >> card all was fine. Hopefully it's an easy fix, we'll see...anyway, we've
> >> seen a lot of random weird behavior with the SD card and we're hoping
> >> this problem I reported is the root cause of it. We tried to reduce it
> >> down to a simple test case so it would be easy to reproduce.
> >>
> >> > I'm not sure about the 7350 - but on the TS7400 there is a design issue
> >> > (or rather lack of clarity): The port_b4 gpio line doubles up as the
> >> > dmaenable line for dma channel 0. This is undocumented - and caused a
> >> > problem with a board I designed. The issue arises when using dma
> >> > enabled on the driver and channel 0 is used.
> >> >
> >> > The driver software for the 8 bit CPLD interfaces (7250 and 7400)
> >> > contain a busy wait loop in them to stop faulty signaling on them. Im
> >> > not sure about the 16 bit interfaces (e.g. the 73 series) - but there
> >> > may be an equivalent loop or a race condition in that loop in the
> >> driver.
> >> >
> >> > Id suggest checking that the two external DMA signaling lines aren't
> >> > attached to any circuitry you may be using.
> >>
> >> Thanks for the ideas...we'll definitely check on this on Monday to make
> >> sure. We've seen this problem on two TS-7390 boards, and on one of them
> >> I believe all we had hooked up externally was the two wires to the TS
> >> uart and an ethernet cable, so I dunno.
> >>
> >> > Does anyone fancy co-operating on reverse engineering and open sourcing
> >> > the SDcard driver?
> >> > Is doing that legal?
> >>
> >> Not sure on the legality of it. I think it would be easier to just take
> >> the binary blob as is and port the open source portion of the driver to
> >> newer kernel versions perhaps? It would be an interesting thing to try
> >> (either method).
> >>
> >>
> > But it is lot of work I spend lot of time to try port wrapper from 2.6.21
> > to 28 but it is not possible.
> > There are lot of internal changes in kernel BIO layer. I mean that wrapper
> > driver must be rewritten from scratch.
> >
> Actually, I have repaired the wrapper for use with 2.6.27 - as I'm not
> convinced the memory management is correct in the later kernels yet -
> maybe someone can correct me on this.
I think sparsemem is working OK in 2.6.28+, modulo one bug exposed by 'cat
/proc/pagetypeinfo'. Mel Gorman wrote a patch addressing that, but I haven't
checked lately to see if it made it into 2.6.30 yet:
http://marc.info/?l=linux-arm-kernel&m=124238736603218&w=4
>
> I also reverse engineered the blob part from object module for use on
> the ts7400 about 10 months ago. The reverse engineered blob works only
> on - rev 0 8 bit CPLD controllers (e.g. 7250 and 7400, not 73xx nor
> 78xx) - but one may infer from the blob dump that the 16 bit interfaces
> are fairly similar, and likely several oddities (e.g. hardware bugs) are
> fixed.
>
> Nothing is sacred in the controller blob - all of the SD commands are
> published; so TS's argument about not releasing the driver because they
> paid for access to secure documents doesn't apply anymore (it may have
> at one time). I suspect that TS's argument against publishing the
> driver source code is more of exposing bugs in the CPLD implementation,
> and/or showing their ugly code. If they would chill out and come clean
> with the code then we (the collective community) could get it working,
> burn in tested and supported on modern (e.g. usable) kernels.
This would be great. I think TS just doesn't see or doesn't understand the
benefits of releasing the code.
IIRC, one TS concern was an NDA they signed, but every NDA I've seen has had an
escape clause (paraphrasing): if the secrets are revealed through other means
and become widely known, the parties are released from the NDA. Sounds like
the SD association voided a lot of NDAs when they published the SD commands.
>
> I have tested my implementation with Bonnie++, and it does seem to work
> on 10MiB test files - although I haven't done much more sophisticated
> burn-in testing. My driver also works with DMA reads, DMA writes are
> unsupported (similarly to the ts implementation).
So you have a modified driver, which requires a modified binary blob?
>
> My main question - and primarily one for the GNU's lawyers is whether or
> not I can release the code under a GNU license.
I'm pretty sure you cannot release a modified binary blob. Perhaps you could
release a script that would patch the blob, so anyone who has a license for the
blob could modify it as you did.
regards, .......... Charlie
>
> -bms
>
------------------------------------
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/
|