[Arm-netbook] Crowsupply update

Luke Kenneth Casson Leighton lkcl at lkcl.net
Mon Jan 8 22:09:40 GMT 2018


On Mon, Jan 8, 2018 at 9:22 PM, Richard Wilbur <richard.wilbur at gmail.com> wrote:

> One downside of the 2.7.4 board at this point is the changes in capacitor pricing that have been ameliorated only on version 2.7.5.  Here's hoping the 2.7.5 board works!

 darn yeah i'd forgotten about the implications of the price-hike.  whoops.

> […]
>> software-wise i need something that does nothing more complex than
>> mount stuff on a micro-sd card, show boot messages on both screens,
>> and maybe has 2 keyboards plugged in (one into each USB socket) so
>> that they can bash some keys and see that crud comes up on-screen for
>> each.
>>
>> going beyond that... testing I2C, UART and the GPIO.... *sigh*...
>> that involves writing some software.
>
> I'd be happy to write some test software for I2C, UART, GPIO, etc.
>  I've worked on drivers for those interfaces on embedded machines in the past.
> I also have experience creating and implementing software and hardware test
> designs.  One example, I modified my employer's PCI VGA BIOS to test the card
> at boot which significantly streamlined testing of our cards.  Another example,
> in order to test a design I created I2C driver and test code to demonstrate feasibility
> on a prototype and then incorporated it into production code in the BIOS and driver.

 nice!  well, this would be a lot simple: scan the I2C bus (lmsensors
debian package), see if a peripheral at address 0x51 comes up, if it
does _great_.  it's a few lines of shell script.

 UART: if i add a USB-to-UART adapter onto a "test" microdesktop unit,
if there's output on the console and it's not garbage, that's good
enough.

 the GPIO... yes, that's where some coding comes in.  there's actually
only a few pins spare, they're all on the 14-pin header of the
microdesktop board.  except for two which are intended for bit-banging
a separate I2C driver for VGA "EDID" detection....


> Happy to collaborate on board bring up as well.

 great.

>   I've worked on bringing up in-house boards for two employers:
> PCI graphics cards (for which we used oscilloscope and completed someone
> else's programmable logic design), embedded computers in different modules
> of high-speed wireless communications links (tools used:  spectrum analyzer,
> oscilloscope, logic analyzer, PCI bus analyzer, MPEG protocol analysis
> software, processor In-Circuit Emulator, serial terminal).

 ooo fuuun :)

 honestly the board's pretty "mature" and a lot simpler than that.  no
PCI, no PCIe, it's all SD/MMC, UART, USB, I2C, SPI, RGB/TTL, that sort
of thing, where all of those have all worked in previous boards, no
reason why they shouldn't work in the 2.7.5 version (except i tidied
up the USB lines a bit... never keen on altering stuff that works...
ah well).

 on the actual board itself, it's so tightly integrated (and also
quite simple) that it tends to be an all-or-nothing.   does power
work, measure the voltages, yes no.  ok does plugging in USB-OTG only
have it show up on "lsusb" yes no.  yes ok great let's load the FEL,
does _that_ work, yes no, yes ok great, now does loading u-boot
directly into DDR3 RAM work, yes, no.

 the FEL (u-boot-spl) loader has a nice debug feature of displaying a
few lines of early UART.  so that's a really good way to tell if the
A20's alive.

 from there i can compile u-boot to look for a particular micro-sd
card slot, which it will scan, and show debug messages "SD card
detected" and so on.  i can do commands which list the partitions and
so on.

 it's pretty straghtforward: anything not working shows up really
quickly and easily.

> If you've got that covered, I'm happy playing the role of the ally
>  you can describe the problem to and who, through listening to
> your description, helps you see the solution!

 appreciated.

 ... y'know... when we get to the RISC-V 64-bit SoC then that's going
to be a lot trickier.  aside from anything it will be necessary to do
the DDR3 layout from scratch.  i can't stand doing DDR3 layouts,
they're... blegh :)  get it wrong and yeah you reaaaly need a logic
analyzer...

oh.  i have an RK3288 board that could use your help.  i only got one
of the DDR3 lanes up and running.

l.



More information about the arm-netbook mailing list