[Arm-netbook] It arrived in the post just now!

[luke.leighton]

On Thu, Aug 1, 2013 at 9:24 AM, Henrik Nordström
<henrik at henriknordstrom.net> wrote:
> tor 2013-08-01 klockan 02:01 +0100 skrev luke.leighton:
>>  ok.  right.  there's i think _one_ possible last spare pin on the
>> 68-pin header (i've been thinking of making UART_TX and UART_RX part
>> of the EOMA-68 spec) - which could potentially be used here to get a
>> CPU card to go into "bootloader" mode.
>
> Are you sure it should go into EOMA68 standard?

 that's the key question...

 ... this is about bringing the card up in a mass-volume-install-friendly way.

> It is not strictly
> needed for EOMA68-A20 if the SD port in the EOMA68 connector works.

 ... but there are other cards.  think "huge test bed" doing 50,000
units, how can they easily be OS-flashed in a simple automated way,
using robots (not humans).

> But yes probably something is needed to avoid requiring a recovery
> button on each card. Most CPUs do require pin strapping to select boot
> source, usually not as friendly as A10/A13/A10s/A20 where the CPU tries
> the different sources in order. Even the A31 does require pin strapping
> to select boot source, fortunately just a single pin for FEL.
>
>>  however... that's typically going to be CPU-card-specific.  but... if
>> you need to boot and install a CPU Card from scratch you *will* know
>> which one you're dealing with, therefore you'd put the right OS on,
>> use the right tools etc. etc. and would use the appropriate boot
>> pinout setup etc. etc.
>
> Yes, what "bootloader" mode means will differ between cards. For some it
> will simply mean "boot from external storage instead of internal flash",
> for others "enter USB diagnostics/install" such as the FEL mode on
> Allwinner CPUs, for others something else, what external connectors a
> EOMA68 card have is card specific. For some maybe nothing (not required,
> i.e. when the boot media itself can be changed).
>
> For those not capable of booting from any of the available storage types
> or connectors other solutions need to be found such as switching
> external USB port from USB to something else. I.e. turn it into a JTAG
> port or similar. All card specific outside EOMA68.

 yeah which is quite awkward for a robot to put that Micro-USB
connector into the other end, it's a real tight fit.

> If end users are to use this to recover "bricked" cards then we can't
> rely on any other EOMA68 pins such as the UART pins there.

 .... hadn't thought about end-user recovery... have to think about that

> If it's not for endusers then the pin can mean that the card is
> connected to an engineering/service station and EOMA68 pins can get
> other defined meaning, but that route easily leads to CPU specific
> requirements.

 yeah the issue is that the EOMA68-A20 doesn't _have_ an
easy-to-put-into-boot-mode pin.

> With fully assembled cards built for mechanical durability we can not
> count on users being able to at all disasemble the PCMCIA casing to
> enter service mode as doing so will likely destroy the casing.

 correct.

> It's easy
> to open the current EOMA68-A20 only because it's not fully assembled
> missing external faceplate, and also having some margin inside allowing
> the casing to flex and not providing any tension to the metal shield to
> grip into the plastic.
>
> For the production run you want to adjust things so that the card i
> flush against the plastic of the casing so the metal shields get a good
> grip, add some fillers between PCB and shield to provide additinal
> support for the metal shields, where one of these is thermally
> conducting connecting the CPU to the metal shield for cooling
> (preferably both CPU and PCB sides), add a suitable external faceplate
> and a bit more glue on that side as well to hold it together. Opening
> that will be a nightmare.

 yeahh for the ones which use close to 5W we're looking to fill them
with thermal gel.  baaad idea to open those :)

l.