Re: [Arm-netbook] Microdesktop v1.7

[Luke Kenneth Casson Leighton]

i added it here
http://rhombus-tech.net/community_ideas/micro_desktop/mdesktop_i2c.jpg

could you link that on the page
http://rhombus-tech.net/community_ideas/micro_desktop/
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Wed, Jul 18, 2018 at 1:52 AM, Richard Wilbur
 wrote:
> Here's the circuit diagram-scribbled on a piece of paper with pencil.
> Photo shot with phone camera and cropped and scaled down in GIMP.  If it
> needs to be larger to be readable, I still have the original so can rescale
> as needed.
>
> ___
> arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netb...@files.phcomp.co.uk

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

Re: [Arm-netbook] Microdesktop v1.7

[Richard Wilbur]

Here's the circuit diagram-scribbled on a piece of paper with pencil.
Photo shot with phone camera and cropped and scaled down in GIMP.  If it
needs to be larger to be readable, I still have the original so can rescale
as needed.
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] Microdesktop v1.7

[Richard Wilbur]

On Tue, Jul 17, 2018 at 7:43 PM, Luke Kenneth Casson Leighton 
wrote:
>
> Richard can you please edit community_ideas micrideksoo oage rhuombustech
> maintain all of this there revisioons to revisions of email knoen to be
not
> a sustainable way to track detailed important information

Luke,

That's a great idea.  I was just noticing how the updates weren't fitting
into the original so well and thinking I didn't know which wiki page on
which to write stuff.

Thank you for answering my question before I had a chance to ask it!

Richard
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] Microdesktop v1.7

[Richard Wilbur]

Here are links to the files:
ftp://lists.phcomp.co.uk/files/arm-netbook/EOMA_I2C_VESA_calc.pdf

ftp://lists.phcomp.co.uk/files/arm-netbook/EOMA_I2C_circuit_small.png

These are evidently by default good till 18 August 2018.  If they are still
cogent to the discussion I will try to keep them around longer.

Richard
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] Microdesktop v1.7

[Luke Kenneth Casson Leighton]

Richard can you please edit community_ideas micrideksoo oage rhuombustech
maintain all of this there revisioons to revisions of email knoen to be not
a sustainable way to track detailed important information

On Wednesday, July 18, 2018, Richard Wilbur 
wrote:

> Addendum
>
> Why?
> 1.  Make VESA DDC lines conform to VESA DDC spec. (VDD=5.0V, I2C
> signalling)[1]
> 2.  Respect VREFTTL in the range of 3.3-5.0V on EOMA side of VESA DDC
> lines.
> 3.  Respect EOMA requirement that all lines except EOMA I2C be tri-stated
> at power on.
>
> How?
> 1.  Connect pull-up resistors for VESA_SDA(R8) and VESA_SCL(R12) to
> VESA_PWR (+5.0V) instead of VREFTTL.  Maximum current requirement on
> VESA_PWR is ~670uA.
> 2.  Implement circuit in attached
> diagram[EOMA_I2C_circuit_sketch_small.png] on each of SDA and SCL.  I have
> attached a spreadsheet[EOMA_I2C_VESA_calc.pdf] showing how this
> accommodates the I2C signalling for VDD=3.3V=VREFTTL and VDD=5.0V.[2]  It
> also accommodates the EOMA68 VREFTTL input levels by not allowing the EOMA
> side of the signal to exceed one Schottky diode drop(0.3V) above VDD=3.3V.
> 3.  Enable the current limiting regulator (SY6280) for VESA_PWR (+5.0V on
> VGA pin 9) with latch of LCDDE when it first goes active (line coming from
> EOMA68 connector).
>
> References:
>
> [1] https://en.wikipedia.org/wiki/Display_Data_Channel
> [2] http://www.nxp.com/documents/user_manual/UM10204.pdf
> ___
> arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netb...@files.phcomp.co.uk



-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] Microdesktop v1.7

[Richard Wilbur]

On Tue, Jul 17, 2018 at 7:04 PM, Pičugins Arsenijs 
wrote:
>
> > 2. Implement circuit in attached
> > diagram[EOMA_I2C_circuit_sketch_small.png] ...
>
> Did not get your attachments. I'm thinking they were scrubbed
> by the ML software? Maybe post a link - imgur/other sharing
> service?

It is likely the PDF was scrubbed.  The PNG got into moderation because it
was too large.  So I sent them both to the E-mail address at the bottom of
the mailing list signature, below:

> ___
> arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netb...@files.phcomp.co.uk
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] Microdesktop v1.7

[Richard Wilbur]

On Jul 17, 2018, at 19:04, Pičugins Arsenijs  wrote:

>> 2. Implement circuit in attached
>> diagram[EOMA_I2C_circuit_sketch_small.png] ...
> 
> Did not get your attachments. I'm thinking they were scrubbed
> by the ML software? Maybe post a link - imgur/other sharing
> service?
> 
> Arsenijs
> 
> ___
> arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netb...@files.phcomp.co.uk

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

Re: [Arm-netbook] Microdesktop v1.7

[Pičugins Arsenijs]

> 2. Implement circuit in attached
> diagram[EOMA_I2C_circuit_sketch_small.png] ...

Did not get your attachments. I'm thinking they were scrubbed
by the ML software? Maybe post a link - imgur/other sharing
service?

Arsenijs

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

Re: [Arm-netbook] Microdesktop v1.7

[Richard Wilbur]

Addendum

Why?
1.  Make VESA DDC lines conform to VESA DDC spec. (VDD=5.0V, I2C
signalling)[1]
2.  Respect VREFTTL in the range of 3.3-5.0V on EOMA side of VESA DDC lines.
3.  Respect EOMA requirement that all lines except EOMA I2C be tri-stated
at power on.

How?
1.  Connect pull-up resistors for VESA_SDA(R8) and VESA_SCL(R12) to
VESA_PWR (+5.0V) instead of VREFTTL.  Maximum current requirement on
VESA_PWR is ~670uA.
2.  Implement circuit in attached
diagram[EOMA_I2C_circuit_sketch_small.png] on each of SDA and SCL.  I have
attached a spreadsheet[EOMA_I2C_VESA_calc.pdf] showing how this
accommodates the I2C signalling for VDD=3.3V=VREFTTL and VDD=5.0V.[2]  It
also accommodates the EOMA68 VREFTTL input levels by not allowing the EOMA
side of the signal to exceed one Schottky diode drop(0.3V) above VDD=3.3V.
3.  Enable the current limiting regulator (SY6280) for VESA_PWR (+5.0V on
VGA pin 9) with latch of LCDDE when it first goes active (line coming from
EOMA68 connector).

References:

[1] https://en.wikipedia.org/wiki/Display_Data_Channel
[2] http://www.nxp.com/documents/user_manual/UM10204.pdf
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] Microdesktop v1.7

[Richard Wilbur]

On Tue, Jul 17, 2018 at 7:02 AM, Pičugins Arsenijs 
wrote:
>
> Some thoughts:
>
> > 3. Add another SY6280 current limiter for +5V and connect to VGA pin
> > 9 (VESA power). Seems to be some difference of opinion on current
> > requirements: 50mA[2], 300mA-1000mA[1]. If we were to limit at
> > 300mA, it should easily supply the needs of I2C serial EEPROM and
> > probably not over-tax our power supply.
>
> I've also seen the VGA/HDMI +5V used to power various converters
> (most often, HDMI->VGA, but I imagine the inverse is sometimes used
> as well).

I agree.  I designed a converter that was powered by VGA DDC pin 9 power
or, in the absence of that, the VESA DDC SDA and SCL pull-up, or the VGA
horizontal and vertical synchronization signals.  I don't remember exactly
how much power it used but it was relatively efficient as I used low-power
CMOS PAL (Programmable Array Logic, precursor to FPGA's).  Basically its
largest-current operating mode was driving to TTL loads across the video
cable.

> > For VESA_SDA and VESA_SCL, add diode limiters connected to ground
> > similar to ESD117-ESD123 on the SD bus lines provided the
> > diode-limiting voltage is greater than VREFTTL nominal range.
> > Otherwise use BAT54S connected between ground and VREFTTL.
>
> Is it not possible that VESA_SDA and VESA_SCL are 5V? If so, they could
> require level shifting from 5V, am I wrong here?

It turns out VESA DDC uses I2C signalling.[1]  I2C signalling is
bi-directional open drain or open collector so the high state is due to a
pull-up resistor.  The I2C bus voltage can be +5 V or +3.3 V, although
other voltages are permitted.[2]  All the devices on the bus have to
tolerate the bus voltage.

In my experience, the VESA DDC reference design used a pull-up supply of +5
V.  The EOMA68 card doesn't have to drive it that high, simply go hi-Z and
the pull-up resistor in the microdesktop will pull it that high.  But the
EOMA68 card will have to tolerate +5 V on those two lines (VESA_SDA,
VESA_SCL) or we jump into the tricky area of logic-level translation for
bi-directional open-drain signals.

Good observations.  Thanks Arsenijs!

References:
[1] https://en.wikipedia.org/wiki/Display_Data_Channel
[2] https://en.wikipedia.org/wiki/I%C2%B2C
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] Microdesktop v1.7

[Pičugins Arsenijs]

Some thoughts:

> 3. Add another SY6280 current limiter for +5V and connect to VGA pin
> 9 (VESA power). Seems to be some difference of opinion on current
> requirements: 50mA[2], 300mA-1000mA[1]. If we were to limit at
> 300mA, it should easily supply the needs of I2C serial EEPROM and
> probably not over-tax our power supply.

I've also seen the VGA/HDMI +5V used to power various converters
(most often, HDMI->VGA, but I imagine the inverse is sometimes used 
as well).

> For VESA_SDA and VESA_SCL, add diode limiters connected to ground
> similar to ESD117-ESD123 on the SD bus lines provided the
> diode-limiting voltage is greater than VREFTTL nominal range.
> Otherwise use BAT54S connected between ground and VREFTTL.

Is it not possible that VESA_SDA and VESA_SCL are 5V? If so, they could
require level shifting from 5V, am I wrong here?

Cheers!
Arsenijs

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

Re: [Arm-netbook] Microdesktop v1.7

[Richard Wilbur]

On Jul 3, 2018, at 03:19, Luke Kenneth Casson Leighton  wrote:
>
>> On Tue, Jul 3, 2018 at 1:57 AM, Richard Wilbur  
>> wrote:
>>
>> By the way, what is the status of the microdesktop
>> design v1.7?  Have you already invested in parts (specifically
>> the 2x10 header) and/or circuit boards?
>
> yep all good.  the funds that were transferred to mike 18+ months ago
> ($60k) are down to around $45k now and he's got most of that left with
> which to order components for the 1.7 md and 2.7.5 card.

I was asking with regard to the possibility of releasing a
microdesktop v1.8 with a few refinements (presumably
electrical/electronic changes that fit within the same form factor, id
est, no change to the case).

Why?
1.  Open up more possibilities for experimentation by tripling the
number of GPIO lines available at expansion connector(2 → 6).
2.  Add soft-start to the power regulator for 3.3V supply.
3.  Support VESA DDC Plug and Play monitor detection regardless of
power-up order between monitor and computer.[1]
4.  Improve signal quality (and reduce radiated/coupled EMI) for VGA interface.
5.  Improve Electro-Static Discharge protection (page 1 of the
schematic says: “TODO: ESD protection”).

How?
1.  Bring the remaining 4 GPIO lines from the EOMA68 connector (J14
pins 20,54,21,55) to the expansion header(J5).  Dropping VESA_SCL and
VESA_SDA lines from J5 (available and used on VGA connector J4) gets
us two pins for free.  Then we either get a larger connector (2x11
instead of 2x10), find two other signals to drop from the expansion
header (EOMA68-I2C_SCL, EOMA68-I2C_SDA which are connected to the
serial EEPROM for chassis identification?), or decide we are happy to
have doubled the GPIO presence (2 → 4) and stop.
2.  Add a 10K Ohm resistor between +5V and Enable(pin 1) on U9.
3.  Add another SY6280 current limiter for +5V and connect to VGA pin
9 (VESA power).  Seems to be some difference of opinion on current
requirements:  50mA[2], 300mA-1000mA[1].  If we were to limit at
300mA, it should easily supply the needs of I2C serial EEPROM and
probably not over-tax our power supply.
4.  Route signals as high-speed/frequency pairs.[1]
  A.  Change the name of VGA pins(J4):
pin  Name
 5  HSYNC_RTN
 6  RED_RTN
 7  GREEN_RTN
 8  BLUE_RTN
 9  PWR
10  VSYNC_DDC_RTN
  B.  Make sure the following pairs are routed as microstrip pairs
from connector pins to signal driver:
VGA_ROUT/VGA_R(1), RED_RTN(6)
VGA_GOUT/VGA_G(2), GREEN_RTN(7)
VGA_BOUT/VGA_B(3), BLUE_RTN(8)
VGAHSYNC/VGA_HSYNC(13), HSYNC_RTN(5)
VGAVSYNC/VGA_VSYNC(14), VSYNC_DDC_RTN(10)

Return lines should connect to ground pins of signal driver and/or
ground side of power supply decoupling capacitor at signal driver.
The first three pairs (video lines) should be over unbroken ground
plane as they are the highest-frequency lines (12.6MHz-388MHz
depending on video mode).

Add VREFTTL decoupling capacitor next to R12 and R8 (pull-ups for
VESA_SCL and VESA_SDA) then route the following pairs from VGA
connector to pull-ups/decoupling capacitor ground:
VESA_SDA/SDA(12), VSYNC_DDC_RTN(10)
VESA_SCL/SCL(15), VSYNC_DDC_RTN(10)

5.  Filter VGA cable shield connection to ground with ferrite beads
(J4 pins 16,17).  Likewise USB2 ports (J11, J3) pins M0 and M1.  Also
EOMA68 connector (J14) pins “0”, “0/2”, if those are connector shield
connections?  What are J14 pins 73 and 74?  (They are labelled “GND”
but left unconnected?)

We don't have a metal chassis here to connect the shields directly to.
If we did, I'd suggest connecting shields to chassis ground and then
ferrite bead to separate chassis ground from power/signal ground.

For VESA_SDA and VESA_SCL, add diode limiters connected to ground
similar to ESD117-ESD123 on the SD bus lines provided the
diode-limiting voltage is greater than VREFTTL nominal range.
Otherwise use BAT54S connected between ground and VREFTTL.

Add BAT54S connected between ground and USB2VBUS across USB2 data
lines EOMA68-DM0, EOMA68-DP0, DM2, DP2.

Just some thoughts. ;>)

Richard

References:
[1] https://en.wikipedia.org/wiki/VGA_connector
[2] https://en.wikipedia.org/wiki/Display_Data_Channel

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

Re: [Arm-netbook] Microdesktop v1.7

[Luke Kenneth Casson Leighton]

On Tue, Jul 3, 2018 at 1:57 AM, Richard Wilbur  wrote:

> By the way, what is the status of the microdesktop
> design v1.7?  Have you already invested in parts (specifically
> the 2x10 header) and/or circuit boards?

 yep all good.  the funds that were transferred to mike 18+ months ago
($60k) are down to around $45k now and he's got most of that left with
which to order components for the 1.7 md and 2.7.5 card.

l.

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

Re: [Arm-netbook] microdesktop v1.7 arrived, works fine... but...

[Luke Kenneth Casson Leighton]

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


On Tue, Apr 18, 2017 at 10:22 PM,   wrote:
> On  Thu, 6 Apr 2017 06:12:16 +0100
> Luke Kenneth Casson Leighton  wrote:
>> ok so the story goes like this:
>>
>> back in august 2016 i got the A20 card up and running with mainline
>> 4.7rc1 (or thereabouts), including patching in NAND support for a
>> proper mtd device.  it worked... up to a point... except when u-boot
>> did a complete scan it CORRUPTED the NAND flash... just from reads.
>>
>> i figured this was "just software" as it's pretty experimental, and
>> the 3.4.104 sunxi-nand works perfectly.
>>
>> fast-foward to a few months ago, when i was testing the external
>> micro-sd slot, weirdly it resulted in a kernel segfault *from the
>> sunxi-nand driver*.  i thought, "that's weird, might be to do with
>> current-fighting from the micro-desktop PCB not having level-shifting"
>>
>> sooo... that's now fixed: the micro-sd slot works perfectly through
>> the new revision 1.7 microdesktop's level-shifting IC.  however i got
>> exactly the same kernel segfault in the sunxi-nand driver, so i
>> temporarily took it out of the kernel config, tested again, and yes,
>> the micro-sd worked fine.
>>
>> ... except that when i booted it up again, the nand flash had been
>> corrupted.  now, bear in mind there's *NO DRIVER INSTALLED*.
>>
>> this is just too weird for me to deal with.  not to mention, because
>> of the age of the A20's Boot ROM there is now a limited set of
>> "legacy" NAND ICs available i've had it with them.
>>
> 
>
> I'm sorry to hear you are having trouble.
> Personally, I like the super weird Linux problems. Can I have one of
> those malfunctioning alpha boards to try to figure out what's going on?
> I grant you that I've never worked on something quite this low level
> before, so I won't be solving it any time soon, but it would be worth
> looking into just so that we don't have this problem again (yes, I would
> like to learn how to create SBCs).

 sure - once i have working prototypes to replace it with.

l.

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

Re: [Arm-netbook] microdesktop v1.7 arrived, works fine... but...

[zap]

On 04/06/2017 07:05 PM, Luke Kenneth Casson Leighton wrote:
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>
>
> On Thu, Apr 6, 2017 at 5:38 PM, Vincent Legoll  
> wrote:
>>>  basic logical reasoning says: remove the NAND IC.
>> Yes, stop the madness, make it work as-is/as-you-can,
>> and keep the fancy for V2 :-)
>>
>> Half-joke aside, I'm with you, get it out the door and take
>> a break.
>>
>> If I undestand, the V2 may not even be A20-based...
>  slight misunderstanding: i'm working on a second card that happens to
> have an RK3288 processor, named EOMA68-RK3288, current revision 0.1.
> that cannot be called "V2" i.e. is totally separate and distinct from
> the card named EOMA68-A20, current revision 2.7.4
I am sure you will succeed in reverse engineering all the blobs out. and
once you do, I will most definitely buy one and laptop casing.  and if
you want I will donate an extra 30$ because I didn't buy the original
a20.

He does indeed have a point though, once you get it out the door take a
break. You deserve it. :)

> l.
>
> ___
> arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netb...@files.phcomp.co.uk


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

Re: [Arm-netbook] microdesktop v1.7 arrived, works fine... but...

[Luke Kenneth Casson Leighton]

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


On Thu, Apr 6, 2017 at 5:38 PM, Vincent Legoll  wrote:
>>  basic logical reasoning says: remove the NAND IC.
>
> Yes, stop the madness, make it work as-is/as-you-can,
> and keep the fancy for V2 :-)
>
> Half-joke aside, I'm with you, get it out the door and take
> a break.
>
> If I undestand, the V2 may not even be A20-based...

 slight misunderstanding: i'm working on a second card that happens to
have an RK3288 processor, named EOMA68-RK3288, current revision 0.1.
that cannot be called "V2" i.e. is totally separate and distinct from
the card named EOMA68-A20, current revision 2.7.4

l.

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

Re: [Arm-netbook] microdesktop v1.7 arrived, works fine... but...

[Luke Kenneth Casson Leighton]

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


On Thu, Apr 6, 2017 at 1:38 PM, Joseph Honold  wrote:
> On 04/06/2017 12:12 AM, Luke Kenneth Casson Leighton wrote:
>> now, i _could_ convert to eMMC but it's too much of a major redesign:
>> it involves disrupting the RGB/TTL tracks, and may require at least
>> two more rounds of pre-production prototyping...
>>
>> ... it's too much: it's too risky... and i'm getting fed up.  so.
>> what i'm going to do instead is: cut the NAND IC entirely, then wire
>> SDC2 (which is the same pins as the NAND) to the *ON-BOARD* Micro-SD
>> card slot, instead.
>
> Not that I'm against dual SD slots, but from what I see, NAND and eMMC
> share the same pins so it should be easy enough to add the bga
> footprint and the required passives.

 should... but (a) if i get it wrong it's yet another $1500-$2000 and
yet another 8 week delay, which means that it could be $3000-$4000 and
16 weeks because it will be necessary to do *two* more revisions, one
to find out that the PCB design was wrong and one to add corrections

 and (b) yes the same wires can be used but no the boot order cannot
be changed because as it's the exact same wires there's still no room
to cross over MMC3 and MMC0 to make MMC0 the "on-board" boot and MMC3
the EOMA68 off-board microsd.

 the other alternative is to turn the A20 round by 90 degrees and to
use two DDR3x16 RAM ICs instead of four DDR3x8 RAM ICs.

 howevver...

 (a) the cost of 2x DDR3x16 RAM ICs to make up 2GB is a COMPLETELY
INSANE $20 just for the memory alone.

 (b) replacing the memory layout and adjusting the power management is
basically a total redesign of the board, i might as well chuck the
ENTIRE design away and start completely from scratch.

i estimate that would take about three revisions, thus would be
somewhere between $4,500-$6,000 and take an estimated 10-12 weeks.

 and it'll be a $40 PCB.  which there isn't enough cash for.

 basic logical reasoning says: remove the NAND IC.

l.

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

Re: [Arm-netbook] microdesktop v1.7 arrived, works fine... but...

[Joseph Honold]

On 04/06/2017 12:12 AM, Luke Kenneth Casson Leighton wrote:
> now, i _could_ convert to eMMC but it's too much of a major redesign:
> it involves disrupting the RGB/TTL tracks, and may require at least
> two more rounds of pre-production prototyping...
> 
> ... it's too much: it's too risky... and i'm getting fed up.  so.
> what i'm going to do instead is: cut the NAND IC entirely, then wire
> SDC2 (which is the same pins as the NAND) to the *ON-BOARD* Micro-SD
> card slot, instead.

Not that I'm against dual SD slots, but from what I see, NAND and eMMC
share the same pins so it should be easy enough to add the bga
footprint and the required passives.

The MarsBoard A20 has pads for both NAND and eMMC in the same
footprint so you can use one or the other without losing board space.

http://www.haoyuelectronics.com/service/A10-A20/Schematics/CM-A10/

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

Re: [Arm-netbook] microdesktop v1.7 arrived, works fine... but...

[David Boddie]

On Thu Apr 6 06:12:16 BST 2017, Luke Kenneth Casson Leighton wrote:

> ... it's too much: it's too risky... and i'm getting fed up. so.
> what i'm going to do instead is: cut the NAND IC entirely, then wire
> SDC2 (which is the same pins as the NAND) to the *ON-BOARD* Micro-SD
> card slot, instead.
> 
> what that will give is *two* bootable Micro-SD card options, priority
> being first the external one (MMC0) and second the on-board one
> (MMC2).

I can't comment on the technical issues but I think this is an improvement in
terms of usability, at least from my experience using other systems that
relied on booting from Micro-SD instead of from NAND flash.

David

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