I just read this nugget in the blog post "Meeting Snowden in Princeton"[0] by Ross Anderson based on discussions about NSA operations:

"The export control mechanisms are also used as an early warning mechanism, to tip off the agency that kit X will be shipped to country Y on date Z. Then the technicians can insert an implant without anyone at the exporting company knowing a thing. This is usually much better than getting stuff Trojanned by the vendor."

This is referring to the targeted interception programs run by some governments[1] and which (maybe!) have been used against Tor developers[2].

I'm curious if the Crowdsupply and Novena folks needed to fill out ITAR or EAR style paperwork as part of customs for Novena hardware, either for the finished boards or for the raw components (particularly the Xilinx FPGA). I assume the assembled bare boards were shipped from Shenzhen to the USA for final boxing and then shipped onward internationally, but the Xilinx components might have been shipped from the USA to Shenzhen at some point.

I don't mean to be negative (ZOMG SPIES!!111!) or suggest that paperwork shouldn't be filed as necessary, i'm just curious if this is even an issue speculatively, as a gedankenexperiment. I've filled out plenty of export paperwork for specific digital components in the past and always just whined about the red tape, but I might think about it differently in the future. Off the top of my head, a way to avoid this on an individual level might be to get sensitive hardware shipped to a domestic friend in the USA and have them hand carry it (by plane?), filling out whatever export duties are necessary (IANAL, don't know if/how this can be done entirely legally). On a regional scale, folks can try to source components and do at least the pick-and-place assembly locally (made much more feasible by Novena being open hardware! <3).


URLs mangled to get around forum restrictions:
[0] lightbluetouchpaper.org /2015/05/02/meeting-snowden-in-princeton/
[1] arstechnica.com /tech-policy/2014/05
[2] privacysos.org /node/1311


(24 replies, posted in Hardware)

russm: this was also a problem with my Just the Board: the standoffs I got were orange and kind of weird (only a half-circle on one side), and resulted in a twerked/bent GPBB. bunnie implied it was a was a miscommunication or last minute factory oops.

dpapathanasiou: My understanding of xobs' design decision, and the configuration I've described in the guide, is to always boot u-boot and the linux kernel from the microSD card, and then based on EEPROM flags (that u-boot reads and uses to configure the kernel?) can boot with the rootfs on a SATA drive. There is also some recovery partition that I haven't dug in to yet.

This system makes it basically impossible to brick the board because you can always put in a fresh re-flashed microSD card to recover. I would imagine it is possible to get the i.mx6 CPU to boot from other sources, maybe including SATA, perhaps by pulling different boot pins high/low at power on, but one would need to read the i.mx6 documentation and novena schematic to see if this is feasible on the Novena board.

I've started writing a developer-oriented guide to getting started with the novena:


The idea is not to supplant the wiki or other resources, but to consolidate stable information already existing elsewhere into a quick reference format. The target audience would be folks just getting their boards and not yet knowing where to start (eg, console baud rates, etc) and developers who might have experience with one of {hardware, firmware, software, FPGAs}, but not the others, and wants to get up to speed on full-systems development.

It's mostly just a skeleton for now, i'll be filling it in over the coming weeks as I start using my board more. Corrections and contributions are welcome, or if anybody has made further progress along with something similar i'd be happy to redirect my efforts there instead.

Git repo (for source code) is on github (bnewbold/novena-guide); I can't direct link because of anti-spam measures (one URL per post).


(7 replies, posted in Hardware)

I'm unable to replicate this problem, using Xilinx ISE 14.7 on debian jessie (x86_64). I do get the "Critical Warnings" about not being able to find previous build logs (which seem to be noise), but the bitfile builds successfully (though I haven't verified it in hardware yet).

I do have a


file, which is 4.7MB and has a SHA1 of


. My particular install has been transferred from an old hard disk, so I might have expected corruption, but there doesn't seem to be any.

EDIT: there exists a Xilinx Q&A entry on this exact error, which implies that a corrupt file is to blame, though this does seem less likely if you've both just installed from scratch: http://www.xilinx.com/support/answers/35547.html