+++ David Bisset [2011-10-25 08:59 +0100]:
> On 24 Oct 2011, at 19:22, Wookey wrote:
>
> > Hi people
> >
> > I'm trying to wire up a loon with debian/emdebian armel rootfs and USB
> > host working so I can test modern gpsd with a PPS timing signlal from
> > a GPS.
> > bootloader is Rev 3-3-0 for Balloon [LARGE_MEMORY_MODEL] [BIG_KERNEL]
> > [MD5] [NAND] [YAFFS] [MONO]
> > Last link date: Thu May 20 13:17:31 BST 2010
> >
> > installer kernel that works is:
> > Linux 2.6.29.1-pxa270 #10 Thu May 20 02:57:47 BST 2010 armv5tel unknown
OK, turns out that that _is_ rel 1.0. So moving to 1.0 doesn't solve the
'BSD kernel boot death' issue.
> > I also discovered that you can't use USB host on older loon with the
> > breakout boards - you have to use a CUED board. Wired up wrong
> > port/pins I guess.
Even with a modern 3.32 board there was no power on USB host connector
suggesting that something softwary needs to hapen to get that turned
on. But I'm not sure what.
> > This is all teriffically urgent as I am leaving on a plane tomorrow,
> > and want to leave GPS-research man with a working board.
We eventually succeeded by about 2:30am, with only 'quite a lot of
fairly nerdy dicking about'. I'll spare you all the details but can
confirm that this combo works:
Current trunk configured as 'generic balloon' and rootfs with modules
built in, otherwise defaults. 3v21 CPLD balloon connected to
CUED board for USB host and slave.
The important secret is to use the new chainboot config to get the
real kernel read off NAND by the boot kernel, and not by bootldr. Well
done for sorting that out someone (and putting it on the wiki!)
I did find that bash/dash fails to configure in the rootfs, but not in
a fatal way. Also no password was set so I had to chroot in via the
installer environment and set one in order to be able to login to the
normal boot.
So that means that current trunk works with older boards (at least
CPLD), which is good. (I assume it already works with newer ones :-).
Slave works OK on the breakout board, but host does nothing. Haven't
yet worked out why - will come back to that. Interestingly if you plug
in both breakout board (via pinko) and CUED board (via J11) then only
the slave on the CUED board works. Anyone know why that is - shouldn't
either connector work?
> > this is what you get if you let the balloon boot the normal kernel:
> > MMU table entries
> > 00000000 A3E00C0A
> > 00000040 04000C02
> > 00000080 08000C02
> > 00000100 10000C02
> > 00000140 14000C02
> > 00000000 A3E00C0A
> > 00000500 00000C02
> > 00000A00 A0000C0A
> > 00000A40 A4000C0A
> > 00000E00 E0000C02
> > Enabling MMU... OK
> > UNDF
> > F1DA87EC
> > CB777BF1
> >
> > or, stopping at the boot prompt to enable debug:
> > Enabling MMU... OK
> > boot> boot
> > booting yaffs...
> > Rootfs is "yaffs2"
> > Kernel filesize = 0x001E00A0
> > Booting file "/boot/zImage"...
> > kernel partition base A0008000
> > kernel_magic=00000000
> > kernel_region_words[9]=00000000
> > copying NetBSD kernel ... done
> > done!
> > Jumping to 0xF0000020..
> > UNDF
> > F1DA87EC
> > CBFF7BF1
So this is the thing that is avoided by using the chainboot config,
(details here:
http://www.balloonboard.org/balloonwiki/QuickInstall
under 'installing a new Rootfs (ubifs)'
Documenting this for future unfortunates that stumble across this
problem.
A few other notable points:
Getting JTAG going in a hurry didn't work, as usual, with some
mysterious complaint about 'parameter '2' not known'.
However bbl did work nicely for uploading bootloader and
installer-kernel. Of course it no longer works for uploading boot
kernel because that has to be written by kernel, not bootldr. An
update there would be useful.
USB gadget networking only ever works shortly after replugging the
cable.
USB gadget networking doesn't work if network-manager is
installed, because it turns it off again after about 30 seconds.
Run wicd instead of network-manager to fix this (there is probably
some slicker way we should document.)
The installer/config kernel is rather meanly supplied with modules by
default - it has g_ether and that's it. So you can't use a USB drive
to get the rootfs and kernel image loaded. I had to set up a
web-server and wget them. Any good reason why that is the generic
default (I assume it can be changed in the menuconfig stuff?)
Downloading a 1.0 release set of binaries to install seems awkward and
poorly documented. I had to wget -r all those so you end up with piles of
index.html files everywhere (and other releases you didn't want).
I'll look over the docs and add some stuff for a group we don't cater
for well: People with working hardware who want to update to current
release (either binary or locally built).
> > If I go to new hardware how do I get USB host wired up?
> I can only comment on the hardware.
>
> Firstly the two connectors where USB Host might appear are:
> J11 (on the bottom at the processor end) this is the "Comms Connector"
> J13 (top next to the power connector) this is the Pinko Connector.
>
> J11 will only be fitted on early CUED boards.
> J13 should be fitted on all Balloons.
>
> The USB Host power is an integral part of the USB Host signals as it must switch on and off appropriately.
> This is available on J11, or on the white SUR connector J4 next to the processor.
>
> The USB Host availability changes depending on board revision as a result of finding OTG doesn't work.
>
> 3v21 (early CUED and single sided CPLD Barric) USB Host - and + only available on J1,1 power on J11 and J4
> 3v31 USB Host - and + available on J13 p22 and p23. Power available on J11 and J4.
> 3v32 (single side FPGA build) same as 3v31
> 3v33 (Current production) USB Host + and - as 3v31 but Host power available on J13 p16 and p17.
>
> Board revisions are in copper on the rear top left of the board, you will need a magnifier to see it...
Thanks for that - very helpful. I've left Nial to work this out.
expect mail in a while :-)
I couldn't find a schematic for the breakout board last night, but
have just relaised it's inside JTAGTest 2V2.zip on
http://www.balloonboard.org/balloonwiki/breakout2v2
We could make that info a bit more accessible.
That shows that USB host on that board can never work with 3.21
because it's only connected to pinko, not J11. Doesn't explain why we
couldn't get it working with a 3.32 board either.
> From memory there is a "lock step" sync between bootloader rev and
> Kernel rev, get the wrong combination and it won't work.
> YAFFS compatibility issues?
Yes, although it's only fatal on FPGA boards IIRC. We managed to avoid
that trap in fact as the board we had were already at 1.0
> However I've not tried current builds on older hardware, however
> beyond USB issues caused by the above the only other hardware changes
> (between 3v31 and 3v33) have been to improve audio sound quality and
> fix minor bugs.
OK. That's what I thought. Cheers.
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
(text/plain)