On Mon, Jan 8, 2018 at 9:22 PM, Richard Wilbur richard.wilbur@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.