[Arm-netbook] EOMA68-A20 schematics review / comparison needed - simple task.. just needs eyes

[Luke Kenneth Casson Leighton]

ok i need to do a schematic / PCB upgrade to add an extra address line
to the current EOMA68-A20 PCB to be able to access 2GB of RAM instead
of the current limit of 1GB. i've looked at the cost of the 2x DDR3
x16 RAM ICs and they're nuts: $9 **EACH** whereas 4x DDR3 x8 RAM ICs
are $3.95 giving a total of $12 for the 2GB RAM.

this is why the cubietruck has 4x DDR3 x8 whereas the cubieboard2 only
has 2x DDR3 x16.

to pull this off i therefore need to copy the cubietruck's schematics
and make them exactly the same. so far i've spotted that there's an
extra address line marked "SCS1" to pin AA4 on the EOMA68-A20
schematics (Page 5), that's marked "SA15" on the Cubietruck schematics
(Page 1).

what *really* needs to be done with as many eyes on it as possible is
to just go over both schematics and play "spot the difference".

* Page 1 of the CT schematics needs to be compared to Page 5 of the
EOMA68-A20 ones
* Page 4 likewise needs to be compared to Page 10.

http://hands.com/~lkcl/eoma/allwinner/a20/A20_Cubietruck_HW_V10_130606.pdf
http://hands.com/~lkcl/eoma/allwinner/a20/DS113-V2.2-2014-07-24.pdf

now, i'm designating this page for notes:

http://rhombus-tech.net/allwinner/a20/DDR3_review/

feel free to edit or if difficulties reply here and i'll add the
discrepancies for you.

thx all.

l.

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.ph

[Wolfram Kahl]

Post by Luke Kenneth Casson Leighton
what *really* needs to be done with as many eyes on it as possible is
to just go over both schematics and play "spot the difference".
* Page 1 of the CT schematics needs to be compared to Page 5 of the
EOMA68-A20 ones
* Page 4 likewise needs to be compared to Page 10.
http://hands.com/~lkcl/eoma/allwinner/a20/A20_Cubietruck_HW_V10_130606.pdf
http://hands.com/~lkcl/eoma/allwinner/a20/DS113-V2.2-2014-07-24.pdf

In what formats and where are the sources for these available?

(This question arises as secondary from the more primary question:
``are automated eyes for this purpose feasible'',
for which I might be tempted to attempt to force a ``Yes'' answer
if I find sources in appropriate formats.)


Wolfram

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp.c

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

Post by Wolfram Kahl

Post by Luke Kenneth Casson Leighton
what *really* needs to be done with as many eyes on it as possible is
to just go over both schematics and play "spot the difference".
* Page 1 of the CT schematics needs to be compared to Page 5 of the
EOMA68-A20 ones
* Page 4 likewise needs to be compared to Page 10.
http://hands.com/~lkcl/eoma/allwinner/a20/A20_Cubietruck_HW_V10_130606.pdf
http://hands.com/~lkcl/eoma/allwinner/a20/DS113-V2.2-2014-07-24.pdf

In what formats and where are the sources for these available?

PDFs... and no. the cubietruck's board layout is proprietary.

Post by Wolfram Kahl
``are automated eyes for this purpose feasible'',
for which I might be tempted to attempt to force a ``Yes'' answer
if I find sources in appropriate formats.)

nehhhh good question but you'd be looking at installing windows 7,
then installing ORCAD 16.3 and Mentor PADS 9.5... i mean i _have_
actually managed to get ORCAD running under Wine but due to a severe
limitation of wine that the developers have failed to comprehend for
over 10 years now the thing utterly sucks and blows at the same time
gaaaaaad it's slow :)

by the time you've gone through all that hassle a simple visual scan
(i did one just now... 5 minutes... i'll do another one later, and
again next week) is far far quicker.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachment

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Mon, Aug 15, 2016 at 1:58 AM, Luke Kenneth Casson Leighton

Post by Luke Kenneth Casson Leighton
by the time you've gone through all that hassle a simple visual scan
(i did one just now... 5 minutes... i'll do another one later, and
again next week) is far far quicker.

... mind you i have a 2560x1600 LCD so can fit the two PDFs side-by-side... :)

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netbook@

[Xavi Drudis Ferran]

Post by Luke Kenneth Casson Leighton
ok i need to do a schematic / PCB upgrade to add an extra address line
to the current EOMA68-A20 PCB to be able to access 2GB of RAM instead
of the current limit of 1GB. i've looked at the cost of the 2x DDR3
x16 RAM ICs and they're nuts: $9 **EACH** whereas 4x DDR3 x8 RAM ICs
are $3.95 giving a total of $12 for the 2GB RAM.

I thought the production units were going to be like the existing
prototype, but since there's a redesign I just thought it might be
time to add some switch or jumper to enable/disable writing to some
NAND area or SD or something ?

I don't know how to go about it, the idea would be to "answer" the
request for secure boot of those people saying they can't trust an ARM
device without Trust Zone.

I'm relunctant in general to trust Trust Zone/Secure boot, because it
is too complex even if well designed, and even when the owner has all
the keys. But smarter people than me seem to find it useful, so I'm
not ready to outright dismiss it either. For me it is not so much about
controlling what gets installed but about letting others control what
is installed (the delegation is forced in the case of bad secure
boot and decided by the owner in the case of good secure boot).
The advantage of delegation is that some party that centralizes security
may be able to devote more resources, and the disadvantage that that
also becomes a more attractive target for attacks or failures that
compromise everyone who has delegated to them (see
http://arstechnica.com/security/2016/08/microsoft-secure-boot-firmware-snafu-leaks-golden-key/
)

Once I read the verified boot idea in chromebook devices
http://www.chromium.org/chromium-os/chromiumos-design-docs/firmware-boot-and-recovery

It looks like roughly right (disregarding the paternalism, cloud
backups, scaremongering people modifiying their OS, etc.). And to
simplify, I wouldn't care about malicious users "borrowing" the device
and returning it with malware, just about remote attacks. After all
compute cards are small enough that you can keep them in a safe or locked
box or your pocket. It does not require Trusted Zone, and could be
simplified further.

What it boils down to is that if the compute card had some sort of
jumper or switch that users with physical access could operate
intentionally, it could have two positions. In one the computer card
is unbrickable just like it is now and can boot from several places,
all those places readwrite or replaceable. In the other the device can
only boot from a section of the NAND and that section is readonly
(until the switch changes position).

The computer cards would be delivered as unbrickable, without any verified
boot software, but any user wishing to develop or adapt a verified
boot firmware could develop and install it themselves and have the
minimal hardware support to operate it with the flip of a switch. If
someone wants to set up a system for users who don't understand
verified boot they can seal the switch with an adhesive tape or just
instruct the users to never touch it whatever it happens.

If the NAND eventually becomes too corrupt to boot from it, then the
computer card can be repurposed to non-verified uses or sold to someone
who wants such uses. (or the NAND could be socketed enabling repair,
but that does not seem easy at all).

Now I don't know what hardware design it would require. I read some
EEPROMs have read only sections. Maybe we could just make do with
complete readonly NAND (not just part of it) by an AND of the switch
and the write enable signal. 8GB read only seems a waste, but if it is
simple enough to get it's already something. Or maybe some simple
logic circuit from the address bus (if parallel, but address goes
probably in serial through the wires?). And then somehow prevent
booting from other sources when the switch is on to protect from
remote attackers modifying the boot media. Can the A20 be straped to
boot only from NAND ? I think the JZ4775 can, by just troggling some
input lines.

I really don't know if it is possible or hard, I just thought I could
comment it in case someone had a simple solution that would not cause
too much trouble in redesign, retest, etc. If it is too complex, I don't
think it is worth it.

Also, it'd be best if some expert in security would chime in to say
how much the idea is worth. For instance an objetion I can see is that
malware in the writable storage (part of the NAND, or SD or whatever)
could just wait until the user flips the switch for a regular update
and sneak something bad in the boot code. But then the verified boot
should have prevented that malware being there at all, I guess. It's a
matter of the verified OS preventing access. And foremost, the code in
the readonly part should be as simple and audited as possible and not
be updated too often, maybe only after strict verification of the
whole system, I don't know. I mean the code doing the verification in
secure boot/trusted zone is just in there read only, so if you trust
that you could trust some other verifying code and just never flip the
switch?

I don't know. I'm just trying to make Trust Zone believers happy
without really being one myself, so I may be wrong.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

Post by Xavi Drudis Ferran

Post by Luke Kenneth Casson Leighton
ok i need to do a schematic / PCB upgrade to add an extra address line
to the current EOMA68-A20 PCB to be able to access 2GB of RAM instead
of the current limit of 1GB. i've looked at the cost of the 2x DDR3
x16 RAM ICs and they're nuts: $9 **EACH** whereas 4x DDR3 x8 RAM ICs
are $3.95 giving a total of $12 for the 2GB RAM.

I thought the production units were going to be like the existing
prototype, but since there's a redesign I just thought it might be
time to add some switch or jumper to enable/disable writing to some
NAND area or SD or something ?

no. sorry. this is already the absolute minimum that i'm prepared to
do, and it's risky enough as it is. the board is UNBELIEVABLY dense -
there's hardly a single area of the board where routing on TOP, BOTTOM
and internal Layer 3 aren't absolutely stressed to the limit.

Post by Xavi Drudis Ferran
If the NAND eventually becomes too corrupt to boot from it, then the
computer card can be repurposed to non-verified uses or sold to someone
who wants such uses. (or the NAND could be socketed enabling repair,
but that does not seem easy at all).

it's doable using a BGA Infra-red Solder Station, heats up the board
locally to 230C and that one IC can be taken off easily. the only
thing you have to watch is to not knock any of the surrounding
components, or heat the board up so much that components on the other
side start to move or fall off.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook