USB disconnects (was: Only bootlog available on the console)

[Martin Guy]

On 11/17/09, marcus <cmp...@gmail.com> wrote:
> hub 1-0:1.0: port 1 disabled by hub (EMI?), re-enabling...
> usb 1-1: USB disconnect, address 2

> What is the current knowledge about this?

No idea. I've written what I know in one of the "Issues".
I guess putting any of the filesystem onto USB storage will suffer
from the same failures until we find out what the problem is.

M

[Marcus]

I've been thinking about this USB disconnection problem. Im far from
knowledged in the field, so do correct me if Im wrong...

I took it for granted but then I noted that the USB-connector
"housing" on Sim.One is not connected to GND.
Do you ever consider that as a problem?

Also the routing on the board might be done in a more EMI friendly
way. It looks like there is some space for alternative routings on
layer 4. For USB 2.0 there's other recommended solutions for EMI
filtering than the Sim.One uses. Maybe that could be somethink for you
too consider as well.

This is an very basic overview I read:
http://www.usb.org/developers/presentations/pres0602/jim_choate_pdc.pdf
Someone else have to dig into the details.

But if hardware can not solve the problem, Im sure software will.

Cheers,
Marcus

[Marcus]

Maybe this is old news to you:

Unfortunately a vanilla 2.6.31.6 kernel suffer the same kind of USB
disconnects as 2.6.24.7 on the Sim.One.

Regards,
Marcus

[Martin Guy]

On 11/22/09, Marcus <cmp...@gmail.com> wrote:
> Unfortunately a vanilla 2.6.31.6 kernel suffer the same kind of USB
> disconnects as 2.6.24.7 on the Sim.One.

Do you mean 2.6.31.6 running on the sim.one?
If so, can you post the patches you made to it?

M

[marcus]

Martin Guy wrote:
> On 11/22/09, Marcus <cmp...@gmail.com> wrote:
>> Unfortunately a vanilla 2.6.31.6 kernel suffer the same kind of USB
>> disconnects as 2.6.24.7 on the Sim.One.
>
> Do you mean 2.6.31.6 running on the sim.one?

Yes, what else? :)

> If so, can you post the patches you made to it?

Sure, But these are _ugly_ ones, quickly produced from butching your 2.6.24.7
patches.
Dont know if they're of any use. There's for example no ethernet, no rtc, no
sound, no video and no mmc as I only was interested in the USB part.

Also I forced USB_SPEED_HIGH, which supposably is not a good thing. But I
imagined it worked somewhat better on my setup, making the disconnects more
sparse. This was also noted with 2.6.24.7. But I really dont know if actual
transfer speeds are altered. No speed test was made. Maybe it affect delays
somewhere. Might be a step closer to understanding what and where things happen.
Forcing USB_SPEED_LOW was unsuccessfull in my hands.

I noted on 2.6.31.6 I needed a longer rootdelay in the boot parameters with
USB_SPEED_FULL (the "normal" speed).

I have been experimenting with the timeouts in hub_port_debounce(). Having a
long timeout of about 6 seconds allows programs like e2fsck to finish
succesfully, even though the USB bus gets reset multiple times. But it doesnt
help a later USB disconnect during normal system run due to EMI (or whatever
causes the disconnect).

Im currently doing experiments to lower the frequency of the USB hub to 12 Mhz,
hoping that this can smoothen whatever glitches there are on the board/kernel.

I would like to know if the USB2 port of Sim.One suffer the same disconnect
problems as USB0 and USB1. But I need to solder an adapter/cable for that. But I
dont have any old USB cable to sacrifice right now.

It would be nice to have some electronical characteristica of the Sim.One USB
bus. What does the oscilloscope say?

On the hardware level: I found this white paper, which might contain some new
ideas. But maybe all this is already known to the Sim.One project? Having guard
traces was a new method to me. Does it work well?

http://www.ti.com/sc/docs/apps/msp/intrface/usb/emitest.pdf


Regards,
Marcus

[sergio.sorrenti]

for this USB disconnects problem...

I am trying to see if this is an hardware problem.
It seem, that microcontrollers can accept any design on USB.
That is not true for USB 2.0 implementations with faster MCU.

We was thinking to solve this problem in the software...
Maybe we was wrong.

Fortunately one of our member have worked a lot in USB stuff.
I will try to see the problem with him going deep into the design,
and report here in the list if any fix can be done.

Sergio

[Martin Guy]

On 11/23/09, sergio.sorrenti <ser...@4star.it> wrote:
> for this USB disconnects problem...
>
> I am trying to see if this is an hardware problem.
> It seem, that microcontrollers can accept any design on USB.
> That is not true for USB 2.0 implementations with faster MCU.

"USB version 1.1 supported two speeds, a full speed mode of 12Mbits/s
and a low speed mode of 1.5Mbits/s. The 1.5Mbits/s mode is slower and
less susceptible to EMI.
USB 2.0 [...] has upped the stakes to 480Mbits/s."

My storage device is USB1.1
($ lsusb -v | less; and look at the bcdUSB field)

I get 932Kbytes/sec or 7456kbit/sec, so it must be using 12Mbit/s.
Unfortunately we cannot get round it in software by telling high-speed
USB1.1 devices to run in low-speed mode - the speed selection is done
by a pull-up resistor in the device itself and communication starts in
that mode.

However, it doesn't look like a USB2.0 issue, though the low-speed USB
1.1 devices (keyboard and mouse) seem to work ok, though I'm assuming
they're low-speed devices; I don't know that for a fact.

M

[marcus]

nuccio raciti wrote:
> ?CJ M??????2 bank?'?H??? ? ? basYKX Ne{.??? {ize
> ?? ? c0000000 ? ? 02000000


Partially good news and a few questions,

This post is regarding the USB disconnect/reset problem and the serial console
garbage problem, which I believe have a common source: A clocking issue.
At least that is my hypothesis. I dont believe minicom is to blame for serial
garbage.

Questions:
===========
I need more info before going into detail.
How was the crystals on Sim.One assambled?
What temperatures were used to solder them?
What are their accuracy/error on their datasheets?
What does the real world oscilloscope say?
What are the real world measurements of the VDD_PLL pin?
What are the real world measurements of GND_PLL?
Recommended maximum operating temperature range is fairly low of the EP9307. The
board run pretty hot when enclosed in a case. Did anyone measure temp. on the
chip surface?

Best would be to do measurements on a board like Nuccios, which display *good*
garbage on the serial console.

The reason is, the PLLs are acting strange in my hands.

Crystals are known to be somewhat sensitive to heat during soldering.
PLLs have this wonderful feature that whatever error is on the crystals feeding
them will be multiplied several times (about 30 times in EP9307 if Im correct)
when run through the PLLs.
So even if the error in the crystall frequency is very small, it can affect
things like the RS232 and USB communication.

Industrial grade EP9307 run their PLLs at lower frequency than Sim.One.

Experiments:
=============
I did some experiments regarding the USB frequency in 2.6.31.6, which I also
transfered to 2.6.24.7 for testing. If I'm reading linux correct the USB ran at
24 MHz, how this is possible I can not see. There actually seem to be a
deviation in how linux report the frequencys and what the chip actually use,
which I found out when I tried to lower the USB frequency. Either that, or I do
something wrong.

Since 24 MHz performed so poor, I raised the freq. to 48 Mhz. And this was a
true boost in performance. I also did test with different priorities of the USB,
DMA and CPU, but could see no difference from the USB disconnect point of view.

Improvement:
============
The improvement I saw was:
* My earlier uptimes were in the order of 15 seconds (!) to 5 min at the best
(15 min once when fudging high speed) when running the rootfs from a USB 2.0
stick.
During these new experiments I had the Sim.One running from USB for over an
hour, installing packages with apt-get and writing big files with dd most of the
time.

* My earlier write speeds were in the order of 750-800 kb/s,
I now reached 1.1 Mb/s when writing 128 Mb of zeros to the stick. Which I
consider fair enough for Sim.One.

* Programs like apt-get and dd which always made USB disconnect or Reset now
works better. In 2.6.24.7 I still get disconnects, but far, far less often.
In 2.6.31.6 I saw no USB disconnects, probably due to not being
able to stress it enough with apt-get, since I have not patched the eth for that
kernel yet.

Downgrade:
==========
In order to get rid of the USB disconnects I have now lowered the PLLs
drastically to 73 and 48 Mhz to cut down on the possible errors from a large
multiplication of a faulty crystal. Still running the USB at 48 Mhz the low
frequency of the CPU affect the writing speed to USB, I'm now getting 700-750
kb/s. scp of large files over the eth interface to USB-stick is about 530 kb/s.
At this low frequency mpg123 doesnt love me any more. It performes about three
times as poor, which is logical considering the CPU frequency.

Im doing tests on 2.6.24.7 right now and have passed 2 hours of apt-get and dd
abuse on a USB rootfs connected on a 1.8 m cable of unknown quality for some
extra stress. Just lets hope it works out well, however I doubt it will in the
long run.

I wish I had a second monitor so that I conveiniently could run X for some extra
abuse of the system.

So far I have had no garbage on the serial console.

When this test finally fail, or I grow tired, I will raise the CPU freq in steps
until the disconnect problem become serious. It might be good to know the
"limit" in the future.

Also, what is important to know is that a cold start and a reset-button reset is
*not* the same regarding the PLLs. So whenever looking into this problem, you
should take great note of if your restarts are power toggling or resets!

I'd like to hear your conclutions from this. And answers to the above questions.

Martin Guy wrote:
> However, it doesn't look like a USB2.0 issue, though the low-speed USB
> 1.1 devices (keyboard and mouse) seem to work ok, though I'm assuming
> they're low-speed devices; I don't know that for a fact.

Mouse and keyboard might disconnect or reset, but get connected very fast again.
The user will not notice, or think it is due to the "slow" CPU (some ppl call
2.2 GHz on a single core to be slow, they're just plain twisted). There's alot
of reports on the internet where PC users have problems with their mouse.


Regards,
Marcus

[sergio.sorrenti]

Some answer that i am able to reply to Marcus:

> Questions:
> ===========
> I need more info before going into detail.
> How was the crystals on Sim.One assambled?
> What temperatures were used to solder them?

If i remember correctly Gaspare use mid aged
Samsung pick and place to populate circuits.
Regarding the oven temperature and other assembly details,
i'll try to involve him in the discussion,
i've already asked him the above dettails privately.

> What are their accuracy/error on their datasheets?

Datasheet is here => http://www.box.net/shared/cj1n8l7ilr

The specs should be the following:

Package:HC-49SMD
Frequency:14.7456MHz
Tolerance:+/-50ppm(standard)
Stability:-40℃--+85℃（Standard）
Load CAPACITANCE :18PF

> What does the real world oscilloscope say?
> What are the real world measurements of the VDD_PLL pin?
> What are the real world measurements of GND_PLL?

Let us check...

> Recommended maximum operating temperature range is fairly low of the EP9307. The
> board run pretty hot when enclosed in a case. Did anyone measure temp. on the
> chip surface?

Yes, and it's not warm at all,
so we do not used a temperature sensor for this.
Should we?

>
> Best would be to do measurements on a board like Nuccios, which display *good*
> garbage on the serial console.

Yes, it's perfect to debug.
We are also checking the capacity of the tranceiver,
as we changed from Maxim to Texas equivalent,
maybe we was too easy dooing that.

Regards,
Sergio

[Martin Guy]

On 11/24/09, marcus <cmp...@gmail.com> wrote:
> This post is regarding the USB disconnect/reset problem and the serial
> console garbage problem, which I believe have a common source: A clocking
> issue.

> ...

> The reason is, the PLLs are acting strange in my hands.

On 11/28/09, Marcin Juszkiewicz <mar...@juszkiewicz.com.pl> wrote:
> Image Name: Linux-2.6.31.5
> [ 0.280000] e�93xx: PLL1 running at 4p0 MHz, PLL2 at 192 MHz
> [ 0.2800p0] ep93xx: FCLK 200 MHz, HCLK 100 MHz, PCLK 50 MHz

According to this thread on the linux-cirrus mailing list:
http://www.freelists.org/post/linux-cirrus/edb93xx-RedBoot-PLL1-settings-out-of-spec
we are running PLL1 out of spec. Quote:

"According to page 131 of the EP93xx user manual the PLL1_X1 output
frequency range is > 294 MHz and < 368 MHz"

Is clock instability maybe the single cause of the all the serial, USB
and MMC problems? The posts in that suggest some possible alternative
settings.

M

[sergio.sorrenti]

Regarding USB disconnects, no news at now,
we are checking our routing and the intel guidelines
to spot any improper routing issue.
I will send some measurement later...

Gaspare have keeped out from the Windows 95 machine
of the soldering file.

Is showed in this celsius vs. time graph:

http://www.simplemachines.it/doc/Sim1_Soldering.png

> This post is regarding the USB disconnect/reset problem and the serial console
> garbage problem, which I believe have a common source: A clocking issue.
> At least that is my hypothesis. I dont believe minicom is to blame for serial
> garbage.
>
> Questions:
> ===========

[marcus]

Hi, Sorry for a lenghty post.

Martin Guy wrote:
> According to this thread on the linux-cirrus mailing list:
>
http://www.freelists.org/post/linux-cirrus/edb93xx-RedBoot-PLL1-settings-out-of-spec
> we are running PLL1 out of spec. Quote:
>
> "According to page 131 of the EP93xx user manual the PLL1_X1 output
> frequency range is > 294 MHz and < 368 MHz"
>
> Is clock instability maybe the single cause of the all the serial, USB
> and MMC problems? The posts in that suggest some possible alternative
> settings.

The "recommended" PLL setting:
-------------------------------
I have just verified and tried the exact value from that post in our kernel
2.6.24.7. Unfortunately USB disconnects happen as easily as previously during
apt-get. In fact, the second restart (cold boot) had a USB disconnect within 5
seconds. :/

When I have done my experiment on the PLL1/PLL2/FCLK/HCLK/PCLK frequencies. I
have both stayed in spec. for all the limits mentioned in the datasheet and for
some test I deliberately was *out* of spec on some of them. What adds to the
complexity is that there is two PLLs and about 17-18 different clocks derived
from then main 14.7456 Mhz crystal and the PLLs. Add up the AHB and APB busses
and a bunch of FIQ and IRQ and there's a mess even without mutexes. My tests
have been random trial-and-error type, just to get a feeling for what works and
what doesnt.

The latest finding I have done are these:
-------------------------------------------
* By lowering the peripherial clock, PCLK, I seem to be able to induce USB
disconnect. With 99% probability I can get a spontaneous USB disconnect within
5-120 seconds from the USB connect during boot. That is without teasing the USB
with apt-get or dd.

* When the peripherial clock is overclocked, and runs at the same freq as the
AHB bus clock, HCLK, I can not induce USB disconnect. It seem pretty stable to
apt-get and dd. However, there seem to be some pretty good disturbances of the
CS4202 chip and probably is not a good thing to do for the system as a whole.
These test have never lasted for longer than 4 hours. Im setting up the CPU
right now to do an over-night run.

* There is a "feature" in the DMA: When a DMA channel is enabled you have to
wait some clock cycles before you can access the DMA channel. This waiting time
depends on the clocks for AHB and peripherials. This must be investigated further.

* When serious garbage appear on the serial console, waiting 20-40 min without
touching the Sim.One restore the serial communication to a good state. Now, how
weird is that?! At least this has worked four times for me, interesting to know
if it does for you too.

* There can be bus errors on the AHB bus. These, in combination with some long
IRQs, might screw things up for the USB unit. Remember, setting an extremely
long timeout period allowed fsck to finish its job even when multiple USB resets
was issued.

* This is one thing I have not tested, but I strongly believe it can be part of
the solution: We're running the Sim.One in Fast Bus mode. What I'd like to test
is to run in Async mode. When running in Fast Bus mode, the CPU is clocked with
the HCLK, which only is half of the FCLK. So I think the CPU actually only run
at 100 Mhz, when you think it goes at 200 Mhz. I dont know if the bogoMIPS can
be of guidance here. AVR32 running at 140Mhz and says 140 bogoMIPS, Sim.One say
99 bogoMIPS and 200 Mhz. AVR32 have single cycle execution instructions. Im new
to 920t, so I cant be certain. Do you know?

* I tried to run the system with I-cache and/or D-cache disabled (3
combinations) but as the system was sooo slow none of the test was completed. No
conclution, except them caches being necessary for speed, could be drawn.

Ideas/conslutions/questions/and thoughts:
-------------------------------------------
* Kernel version, 2.6.2x or 2.6.3x doesnt seem to matter for the USB
disconnect/serial garbage problem.

* The garbage and USB disconnect problem might be related to time. (garbage,
wait 30 min, no garbage). What does the RTC and other time functions do in the
software. Do they write any registers that could affect USB transmission. (How
can baud rate (garbage) be affected by this???)

* The peripherial clock might disturb the USB clock (resonance, noise, whatever,
I dont know).

* There might be a lock in a peripherial irq or a mutex, which blocks the USB
code from doing its magic. Bus errors help to prolong the waiting time?

* Need to find out if linux heed the need to wait before accessing DMA channels,
when they just have been enabled.

* Running the system various clocks at less than 100 Mhz, and as equal as
possible, has been the best for me so far.


The need for U-boot source:
----------------------------
To get into async mode it is needed to be in a privileged mode. Using openocd
and Jtag to tweak into this mode have been unsuccessful for me.
I would need sources and patches for any version of U-boot.
I have tried, but failed, to get U-boot compiling. As I do not fully understand
the compile system of U-boot. Hacking the binary dump of the U-boot is an
option, but gives less flexibility. As I gave this a shot, I noted that the
patches in post:
http://groups.google.com/group/sim1/browse_thread/thread/c62c88ecfdf4e043#
have not been applied intact (or at all).


About USB:
------------
There is actually two instances of the USB problem:
Disconnect and Reset. I get both. The difference is the lenght of the signal.

* A USB disconnect for low and full speed USB devices occur when the
differential D+ and D- are logic low for more than 2.5 us. A differential logic
low occur when D+ is logic low and D- is logic high. This is called Single-ended
zero state (SE0). SE0 is used for entering End-of-packet, Disconnect and Reset
states.

* A Reset state occur when the SE0 state lasted at least 10 ms.

(End-of-Packet state is entered when SE0 state during at least 1 bit time, then
Data J state (D+/D- hi/lo levels depending on low/hispeed device) for at least 1
bit time.

(Source of info: USB complete 3ed [Axelson, ISBN10 1-931448-02-7])

Does our end-of-packet end up being interpreted as a disconnect due to bus
errors (AHB bus) and/or long IRQ service times?


Reduction of complexity:
-------------------------
To reduce the complexity of the linux kernel, I'd like to have a minimal OS
which does USB and serial communication. Is there any options available?
Newer versions of U-boot can do USB communication.
Should I just make a minimal linux kernel with most things excluded, like I did
with 2.6.31.6?

If there's silicon bugs, like the Maverick. It will be very difficult to sort
this out running a full system.


The crystal:
--------------
sergio.sorrenti wrote:
> Frequency:14.7456MHz
> Tolerance:+/-50ppm(standard)

Great. So *if* the error is multiplied in the PLL without being smoothed out,
worst case you'd get ~1.5% error in the PLL going from the 14.7456 Mhz to 400
Mhz PLL. However PLLs are pretty complex, as they themself produce noise and
jitter beyond our control. I think my assumption of doing a linear
multiplication to get the error is wrong.

I could not exacly read the info on highest allowed assembly temperature for the
crystal from the datasheet. Maybe Im blind. But the assembly temperature plot at
least show that the peek temp of about 220-225 C is only held for 5-10 seconds
which seem "normal" and hopefully is not too long or hot for this specific crystal.

Only one though: Wasnt the software for the pick-n-place machine Y2K compatible!
The dates... ;) Im assuming this is the correct plot.

> We are also checking the capacity of the tranceiver,
> as we changed from Maxim to Texas equivalent,

Is this the correct datasheet?
http://focus.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=max3243&fileType=pdf

Regards,
Marcus

[sergio.sorrenti]

On 28 Nov, 16:13, marcus <cmp1...@gmail.com> wrote:

> Only one though: Wasnt the software for the pick-n-place machine Y2K compatible!
> The dates... ;) Im assuming this is the correct plot.

I think they use the file name to save the work session,
maybe their RTC is not working for a battery problem,
i received a data file called Sim-1.kdf and the Image Graph.
I am unble to open the .kdf, it should be some proprietary
format unrecognized also with file.

>
> > We are also checking the capacity of the tranceiver,
> > as we changed from Maxim to Texas equivalent,
>

> Is this the correct datasheet?http://focus.ti.com/general/docs/lit/getliterature.tsp?genericPartNum...

No, we used in this first production v1.3 the TRS3243ECDB
http://focus.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=TRS3243E&fileType=pdf

On the Martin's board,
Green Prototype #2 there is instead the MAX3243CAI
http://datasheets.maxim-ic.com/en/ds/MAX3221-MAX3243.pdf

Sergio

[Gaspare Bianco]

Hello, Attention perhaps the problem of the stability of quartz, if one speaks of quartz, Y2, the ability to reference on the PCB are not symmetrical and could create this problem of instability of the oscillator. may want to try a staccarre quartz, connected to the output of micro pin pretty short and solder the 2 abilities C57 and C58 between pin and GND still pretty short, I enclose a footprint of quartz to understand the odds

 

By 

Gaspare Bianco

2009/11/28 Martin Guy <marti...@gmail.com>

--
Gaspare Bianco
Sa.Ni.Co. srl
Z.Ind. Santissimo, comp."C" L.10/12
91029 Santa Ninfa (TP) Italy
tel +39 092462200
fax +39 092461330
skype: biancogaspare
mobile phone +39 3355269746
e-mail:bianco....@gmail.com
e-mail:g.bi...@sanico.it
Web: www.sanico.it

[Martin Guy]

On 11/28/09, marcus <cmp...@gmail.com> wrote:
> Hi, Sorry for a lenghty post.

No problem. Your analyses are interesting

> When running in Fast Bus mode, the CPU
> is clocked with the HCLK, which only is half of the FCLK. So I think the CPU
> actually only run at 100 Mhz, when you think it goes at 200 Mhz. I dont know
> if the bogoMIPS can be of guidance here. AVR32 running at 140Mhz and says
> 140 bogoMIPS, Sim.One say 99 bogoMIPS and 200 Mhz. AVR32 have single cycle
> execution instructions. Im new to 920t, so I cant be certain. Do you know?

BogoMIPS are a measure of a 2-instruction loop used for small, precise
delays, not of anything meaningful. There are two other 200MHz EP93xx
boards here, the TS7250 and the Armadillo-9, and the sim1's bogomips
figure is the same as them, and execution speed of applications is
similar (about 10% faster than the TS, because sim1 has a 32-bit data
path to the RAM and TS 16-bit).

If it's useful for comparisons, you can ssh into
gu...@arma.martinwguy.co.uk with passwd friend or I can create a
personal account if you need a secure account. That's old-ABI but the
performance is the same except for floating point (30 times slower!)
and it has a frame buffer running like the sim1.

> caches being necessary for speed,

indeed

> * The garbage and USB disconnect problem might be related to time.

> What does the RTC and other time functions do in the software. Do they write
> any registers that could affect USB transmission.

The RTC is the DS1337 chip on the I2C serial port - I don't think it
writes anything in the EP9307 except when it it accessed to get/set a
value which just uses general-purpose registers.

> The need for U-boot source

I aplogise; Nuccio sent me this a week ago but I've been sitting on it
for a week hoping to sanitise it for publication. Unfortunately my
landlord has been rebuilding my appt around me for the last three
weeks, with workmen in the flat every day from 8am destroying and
creating, and it's driving me crazy.

I'll be delirious for another week or so, so I've put it up on the
downloads page, more or less as received.
http://sim1.googlecode.com/files/u-boot-1.1.6-nuccio.tgz

I compiled it using:

$ CROSS_COMPILE=arm-linux-gnueabi- make edbSIMONE_config
$ CROSS_COMPILE=arm-linux-gnueabi- make u-boot.bin
# It spews "cc1: warning: target CPU does not support interworking"
but don't worry about that;
# it's because Makefile selects -march=armv4 instead of armv4t - but
it doesn't use thumb instructions or interworking.
$ download u-boot.bin # assuming simone is on ttyS0/COM1
# it says "Waiting for board" or something like that; then you
# put J1 on 1-2 and switch the sim1 on and it'll flash u-boot

It also worked the same for me with
CROSS_COMPILE=arm-linux-gnu-

There are instructions where to get the "download" program on the
"Boot Loader" wiki page

With the green prototype #2 it worked.
With one of the white sim1's ( #24), u-boot spews
eth.c: 677: eth_rx(): packet rx error, status B0020100 800003AC
forever trying to load uImage via tftp and goes no further (which is
odd, because it worked fine with the u-boot that was programmed into
it when I received it!)
With the other white one (#25) it works.

Nuccio, do you have the u-boot.bin executable that was programmed into
the boards as they were sent out, to see if that brings #24 back to
life?

> To reduce the complexity of the linux kernel, I'd like to have a minimal OS

> Should I just make a minimal linux kernel with most things excluded, like I
> did with 2.6.31.6?

Yes, that should work.

> If there's silicon bugs, like the Maverick. It will be very difficult to
> sort this out running a full system.

Only the FPU has silicon bugs as far as I know but see the EP9307 errata
cirrus.com -> ARM processors -> EP9307 -> Errata rev E1
(silicon revision is the 5th and 6th letters of the second line of
text on the EP9307 package)

If I continue not to make much sense for another week or so, you'll
understand why...

M

[nuccio raciti]

Hi Martin,
u-boot.bin is here:
http://groups.google.it/group/sim1/web/u-boot.bin?hl=it

N

On 29 Nov, 14:33, Martin Guy <martinw...@gmail.com> wrote:
> On 11/28/09, marcus <cmp1...@gmail.com> wrote:> Hi, Sorry for a lenghty post.

> downloads page, more or less as received.http://sim1.googlecode.com/files/u-boot-1.1.6-nuccio.tgz

[Martin Guy]

Hi
Gaspare has written to me in italian explaining his suggestion
clearly. He says:
----
I understand that there are some problems on the USB port, and it was
said that the quartz crystal might be unstable and might be
interrupting the usb communication for this reason. We were giong mad
once with a circuit on which we had put the crystal a short diatance
away from the CPU, and after some testing we found that the position
of the crystal was causing the problem. To check, I sent a photo of a
PCB where you can see the footprint of the microchip and the crystal
with the two capacitors placed near to the 2 pins of the crystal and
the the reference ground as close as possible to the the ground of the
CPU.
Therefore to check whether you have this problem on the PCB, I would
advise you to connect the crystal directly to the two pins of the CPU
and the two capacitors between the two pins and ground, using very
short pins in all cases. If this resolves the problem, we can then see
how to compensate for other issues that depend on this.
----

M