From paul at boddie.org.uk  Tue Jul  7 21:50:24 2020
From: paul at boddie.org.uk (Paul Boddie)
Date: Tue, 07 Jul 2020 22:50:24 +0200
Subject: [Arm-netbook] EOMA68 Computing Devices Update: Command Not Found
In-Reply-To: <CAPweEDyz5jRUE=Wr843s=Mkh5PBBMszKRJdf2VQ-+aJLhBOZow@mail.gmail.com>
References: <1010621589845316@mail.yandex.ru>
	<CAPweEDyz5jRUE=Wr843s=Mkh5PBBMszKRJdf2VQ-+aJLhBOZow@mail.gmail.com>
Message-ID: <7024647.GB3jCFk4Qm@jason>

On Tuesday, 19 May 2020 02:05:52 CEST Luke Kenneth Casson Leighton wrote:
> On Tue, May 19, 2020 at 12:43 AM Pičugins Arsenijs <crimier at yandex.ru> 
wrote:
> > https://www.crowdsupply.com/eoma68/micro-desktop/updates/command-not-found
> > 
> > Note on the 'lsusb' thing: I personally like the 'dmesg -Hw &' command, it
> > stays in the background and prints the dmesg info in realtime - in
> > particular, letting you see detailed data about newly-connected devices.
> ah!  thank you :)

Any word on the shipment? I guess these things will be taking rather longer 
than usual.

Hope everything is otherwise fine (with everyone)!

Paul




From lkcl at lkcl.net  Tue Jul  7 21:53:27 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Tue, 7 Jul 2020 21:53:27 +0100
Subject: [Arm-netbook] EOMA68 Computing Devices Update: Command Not Found
In-Reply-To: <7024647.GB3jCFk4Qm@jason>
References: <1010621589845316@mail.yandex.ru>
	<CAPweEDyz5jRUE=Wr843s=Mkh5PBBMszKRJdf2VQ-+aJLhBOZow@mail.gmail.com>
	<7024647.GB3jCFk4Qm@jason>
Message-ID: <CAPweEDxkBJynzuww4NENqN1x1Bf6s=Fh1Vtxv4V=tNHivqku=Q@mail.gmail.com>

On Tue, Jul 7, 2020 at 9:50 PM Paul Boddie <paul at boddie.org.uk> wrote:

> Any word on the shipment? I guess these things will be taking rather longer
> than usual.

it arrived safely, no problem - i've just been so busy with libre-soc
that i haven't had time to test it.

> Hope everything is otherwise fine (with everyone)!

:)

yes, it is ironic that i've been living a reclusive lifestyle for 10
years, and now the rest of the world is doing the same... :)

l.


From pablo at parobalth.org  Wed Jul  8 09:52:28 2020
From: pablo at parobalth.org (Pablo Rath)
Date: Wed, 8 Jul 2020 10:52:28 +0200
Subject: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
In-Reply-To: <4214810.6asa3Lq2br@jason>
References: <20200616084447.zq25ovnqbfotyb5h@pabbook>
	<4214810.6asa3Lq2br@jason>
Message-ID: <20200708085228.ngtruk365rw3cksb@cherry>

On Wed, Jun 17, 2020 at 01:09:42AM +0200, Paul Boddie wrote:
> On Tuesday, 16 June 2020 10:44:47 CEST Pablo Rath wrote:
[..]

> > If some of you already have their preproduction boards ready, I would
> > appreciate any help, hints and suggestions to help me getting started.
> 
> I certainly don't have one, nor are there likely to be many in circulation, 
> but maybe there are some people assisting Luke who have some experience with 
> them. 

My hope is that a handful of boards made it to some developers who signed
up on rhombus-tech. The only confirmation of one board out in the wild I have is Richard Wilburs
email with questions.
I am waiting as patiently as I can, but the itch to do something grows
stronger. Over the years I grew quite fond of eoma68 and this mailing-list and
the progress and success of this project is very important to me. 

[...]

> However, I did summarise the state of certain things on the wiki at one point:
> 
> http://rhombus-tech.net/crowdsupply/status/

Thanks for your reply and for reminding me of your summary. It was a
good refresher for me. 

> > 5. Git, notes and documentation
> > Finally I am wondering where to put my notes. A subpage on rhombus-tech
> > seems like a good idea good to me and indicates a work in progress in
> > contrast to the various wikis out there. Where do you want me to push my
> > work in progress git branches if I manage to hack something useful
> > together?
> 
> You could probably make a wiki page on the rhombus-tech site with your notes, 
> maybe linking to it from the one mentioned above.

Sounds good to me. Let us wait on Lukes reply to see if he agrees. 

kind regards
Pablo


From lkcl at lkcl.net  Wed Jul  8 11:46:49 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Wed, 8 Jul 2020 11:46:49 +0100
Subject: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
In-Reply-To: <20200616084447.zq25ovnqbfotyb5h@pabbook>
References: <20200616084447.zq25ovnqbfotyb5h@pabbook>
Message-ID: <CAPweEDzOKuB8gJzE1APurcOFE6s3rJQyTnKng2eY2HNWY51Z8w@mail.gmail.com>

On Tue, Jun 16, 2020 at 9:45 AM Pablo Rath <pablo at parobalth.org> wrote:
>
> I have recieved an EOMA68-A20 2.7.4 preproduction computer card and the 1.7
> micro desktop (MD) last week. Just for clarification these boards are nothing new
> and have been discussed on this mailing list.
> If some of you already have their preproduction boards ready, I would
> appreciate any help, hints and suggestions to help me getting started.
>
> Altough I have some experience with handling arm-boards I am now afraid to do something
> **stupid** and break/fry the boards.
> After some digging in the list-archives I found this thread ([1]) where Richard and
> Luke discuss how to connect the bare computer card with the bare micro
> desktop.
> I have many questions:
> 1. Connecting computer card and micro desktop:
> I am aware of the photos attached to [2].
> Does the mentioned video exist?

no.

> Richard, did you send photos to Luke? (If yes, can I have them?)
> Luke, do you want me to send you photos too before apllying power?

yes that would be good.  visually it is pretty obvious.  just do *not*
bend or waggle the Card as it's inserted (however you may find that
the connector is soldered at a slight angle of 1 to 3 degrees).

from visual inspection from the top, the gap left and right should be
equal.  this should be logically fairly obvious.

from visual inspection from the front, it should also be obvious if
the card has been inserted where the top row of pins has gone into the
bottom part of the connector or vice-versa.

If You Can See Pins You Got It Wrong.

also, once inserted, place the anti-static bag *in between* the Card
and the MicroDesktop PCB.

>
> 2. PSU for micro desktop:
> According to the mentioned thread ([1]): "5.5mm jack with a 2.1mm centre hole, middle is
> +ve (aka "pin positive")", "Anywhere between 7 and 21v is fine, minimum 1A, 1 5A is better"
>
> So I searched for a DC PSU in my household and read Wikipedia where it is
> mentioned that OD 5.5 mm / ID 2.1 mm is common on guitar effect pedals but my
> multi guitar effect pedal PSU did not fit (ID too small). Finally I found a
> matching DC PSU from a low volatage guitar amp. It says O / P: DC 15V, 2A and a symbol (positive polarity):
> L. P. S.
> - -(.- +

you're better off checking with a multimeter.  it's pretty standard
(pin positive) however there is no substitute for actually checking.
i.e.: don't guess - check.  hardware is unforgiving.

> So I think this should be good to go. Can anyone please confirm. Thank you.
>
> Should we document this somewhere on rhombus-tech.net?

yes, good idea.

> 4. SD-card ready / U-Boot
> Tried to compile u-boot-sunxi [4] and make exits with "System not configured".
> So Luke, what did you use as config

it's on the wiki somewhere.  it has been 5 years so i will be
searching just as much as you would be.


> or has something changed over the years?

no.

> I also tried mainline U-Boot but could not find "EOMA68-A20-foo_defconfig"
> and "sun7i-eoma68-a20-foo.dts". What kind of defconfig and *.dts was used for
> the mainline U-Boot demos? My search of the mailing list archives and
> rhombus-tech was not futile. I could only dig up an old thread from 2014 where wookey was
> "assigned" to work on a minimal dts/dtb.
>
> 5. Git, notes and documentation
> Finally I am wondering where to put my notes. A subpage on rhombus-tech seems like a good idea
> good to me

yes.

> and indicates a work in progress in contrast to the various wikis
> out there. Where do you want me to push my work in progress git branches if I
> manage to hack something useful together?

i never needed to make any modifications to any linux kernel or u-boot
source code, so one has not been set up.

l.


From pablo at parobalth.org  Thu Jul  9 11:27:29 2020
From: pablo at parobalth.org (Pablo Rath)
Date: Thu, 9 Jul 2020 12:27:29 +0200
Subject: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
In-Reply-To: <CAPweEDzOKuB8gJzE1APurcOFE6s3rJQyTnKng2eY2HNWY51Z8w@mail.gmail.com>
References: <20200616084447.zq25ovnqbfotyb5h@pabbook>
	<CAPweEDzOKuB8gJzE1APurcOFE6s3rJQyTnKng2eY2HNWY51Z8w@mail.gmail.com>
Message-ID: <20200709102729.iwox3ruslk5nxuk7@cherry>

On Wed, Jul 08, 2020 at 11:46:49AM +0100, Luke Kenneth Casson Leighton wrote:
> On Tue, Jun 16, 2020 at 9:45 AM Pablo Rath <pablo at parobalth.org> wrote:
> >
> > I have recieved an EOMA68-A20 2.7.4 preproduction computer card and the 1.7
> > micro desktop (MD) last week. Just for clarification these boards are nothing new
> > and have been discussed on this mailing list.
> > If some of you already have their preproduction boards ready, I would
> > appreciate any help, hints and suggestions to help me getting started.
> >
> > Altough I have some experience with handling arm-boards I am now afraid to do something
> > **stupid** and break/fry the boards.
> > After some digging in the list-archives I found this thread ([1]) where Richard and
> > Luke discuss how to connect the bare computer card with the bare micro
> > desktop.
> > I have many questions:
> > 1. Connecting computer card and micro desktop:
> > I am aware of the photos attached to [2].
> > Does the mentioned video exist?
> 
> no.
> 
> > Richard, did you send photos to Luke? (If yes, can I have them?)
> > Luke, do you want me to send you photos too before apllying power?
> 
> yes that would be good.  visually it is pretty obvious.  just do *not*
> bend or waggle the Card as it's inserted (however you may find that
> the connector is soldered at a slight angle of 1 to 3 degrees).
> 
> from visual inspection from the top, the gap left and right should be
> equal.  this should be logically fairly obvious.
> 

Images can be found here (I could not upload them to the rhombus-tech
wiki becaus a virus checker is not defined):
https://www.parobalth.org/eoma68-a20/eoma68-A20_2-7-4_1.JPG
https://www.parobalth.org/eoma68-a20/eoma68-A20_2-7-4_2.JPG
https://www.parobalth.org/eoma68-a20/eoma68-A20_2-7-4_3.JPG
https://www.parobalth.org/eoma68-a20/eoma68-A20_2-7-4_4.JPG

> from visual inspection from the front, it should also be obvious if
> the card has been inserted where the top row of pins has gone into the
> bottom part of the connector or vice-versa.

Visual inspection from the front looks good to me but is difficult to
photograph with good light and correct focus. 

> If You Can See Pins You Got It Wrong.

I can't see pins anymore.
> 
> also, once inserted, place the anti-static bag *in between* the Card
> and the MicroDesktop PCB.
>

Is this for anti-static purpose or to add a bit of stability? Do you
fold your bag to fit the entire length of computer-card?

> >
> > 2. PSU for micro desktop:
> > According to the mentioned thread ([1]): "5.5mm jack with a 2.1mm centre hole, middle is
> > +ve (aka "pin positive")", "Anywhere between 7 and 21v is fine, minimum 1A, 1 5A is better"
> >
> > So I searched for a DC PSU in my household and read Wikipedia where it is
> > mentioned that OD 5.5 mm / ID 2.1 mm is common on guitar effect pedals but my
> > multi guitar effect pedal PSU did not fit (ID too small). Finally I found a
> > matching DC PSU from a low volatage guitar amp. It says O / P: DC 15V, 2A and a symbol (positive polarity):
> > L. P. S.
> > - -(.- +
> 
> you're better off checking with a multimeter.  it's pretty standard
> (pin positive) however there is no substitute for actually checking.
> i.e.: don't guess - check.  hardware is unforgiving.
> 
Bought a multimeter and checked. DC PSU is good to go.

> > Should we document this somewhere on rhombus-tech.net?
> 
> yes, good idea.

Will do it in next couple of days. 

> > 4. SD-card ready / U-Boot
> > Tried to compile u-boot-sunxi [4] and make exits with "System not configured".
> > So Luke, what did you use as config
> 
> it's on the wiki somewhere.  it has been 5 years so i will be
> searching just as much as you would be.

Ok. 

> > or has something changed over the years?
> 
> no.
> 

> > 5. Git, notes and documentation
> > Finally I am wondering where to put my notes. A subpage on rhombus-tech seems like a good idea
> > good to me
> 
> yes.

After a quick check it seems one can not create subpages from the online
editor (only edit pages). 
Can I still send you an ssh-key to get a better access to the wiki?

> > and indicates a work in progress in contrast to the various wikis
> > out there. Where do you want me to push my work in progress git branches if I
> > manage to hack something useful together?
> 
> i never needed to make any modifications to any linux kernel or u-boot
> source code, so one has not been set up.

Ok. Thanks. 

kind regards 
Pablo



From laserhawk64 at gmail.com  Thu Jul  9 11:40:01 2020
From: laserhawk64 at gmail.com (Christopher Havel)
Date: Thu, 9 Jul 2020 06:40:01 -0400
Subject: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
In-Reply-To: <20200709102729.iwox3ruslk5nxuk7@cherry>
References: <20200616084447.zq25ovnqbfotyb5h@pabbook>
	<CAPweEDzOKuB8gJzE1APurcOFE6s3rJQyTnKng2eY2HNWY51Z8w@mail.gmail.com>
	<20200709102729.iwox3ruslk5nxuk7@cherry>
Message-ID: <CA+kEFNKrV0VgazXYMUTVHSZgWR++YvFq9L7_8KeSPisHCMdO5w@mail.gmail.com>

Forgive the horribly embarrassingly so-late-it's-early chime-in from a dork
on his phone :P but it's worth noting that antistatic bags are generally
conductive on one side (and only one side!) -- especially the
darkly-translucent aluminized Mylar kind.

It strikes me that getting that conductive side oriented in the wrong
direction could prove spectacularly catastrophic, so I thought I'd pipe up
about that...

I mean, fireworks can be fun, but usually not that kind, and as far as I
know all the major holidays involving such things are either already over
or way later in the year... could be wrong tho. ( :P )

...but seriously, let's keep the "magic smoke" inside the componentry where
it belongs ;) IIRC most of those shiny-ish bags should be
multimeter-verifiable as to which side is which.

From lkcl at lkcl.net  Thu Jul  9 11:43:58 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Thu, 9 Jul 2020 11:43:58 +0100
Subject: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
In-Reply-To: <20200709102729.iwox3ruslk5nxuk7@cherry>
References: <20200616084447.zq25ovnqbfotyb5h@pabbook>
	<CAPweEDzOKuB8gJzE1APurcOFE6s3rJQyTnKng2eY2HNWY51Z8w@mail.gmail.com>
	<20200709102729.iwox3ruslk5nxuk7@cherry>
Message-ID: <CAPweEDxw2sUbo_Lrd3P1wzetCkis3EuDiMkQfseghgB03EDCQQ@mail.gmail.com>

On Thu, Jul 9, 2020 at 11:28 AM Pablo Rath <pablo at parobalth.org> wrote:

> Images can be found here (I could not upload them to the rhombus-tech
> wiki becaus a virus checker is not defined):

ah sorry :)

> https://www.parobalth.org/eoma68-a20/eoma68-A20_2-7-4_1.JPG

ok can you re-take this one *exactly* from above?  as it is slightly
to the side it is not visually possible to confirm that the gap on the
left is exactly the same as the gap on the right, because perspective
(and shadows).

> https://www.parobalth.org/eoma68-a20/eoma68-A20_2-7-4_2.JPG

it's slightly out of focus, the camera selected the ASICs not the
connector, didn't it?

> https://www.parobalth.org/eoma68-a20/eoma68-A20_2-7-4_3.JPG

ah that's better.

> https://www.parobalth.org/eoma68-a20/eoma68-A20_2-7-4_4.JPG

ah ha!  cancel that on the 1st one, that looks even on both sides, doesn't it?

ok there's one more: a picture from the *underside* - actually
*between* the PCBs (try to get some light in there).  don't for
goodness sake pry the cards apart, obviously you'll need to take the
anti-static bag out.

whilst the no 4. photo showed that the pins from the *top* row are not
showing, i.e. the Card was not inserted too low, this does *NOT*
guarantee that the card was inserted TOO HIGH.

and you will find that out by VERY CAREFULLY inspecting *between* the
PCBs.  if the Card was inserted 1.5 mm too high, you will be able to
see the bottom PCMCIA row of pins clearly.

BE CAREFUL ok?

> > from visual inspection from the front, it should also be obvious if
> > the card has been inserted where the top row of pins has gone into the
> > bottom part of the connector or vice-versa.
>
> Visual inspection from the front looks good to me but is difficult to
> photograph with good light and correct focus.
>
> > If You Can See Pins You Got It Wrong.
>
> I can't see pins anymore.

you need to check top and bottom.  top looks good, bottom also needs checking.

> >
> > also, once inserted, place the anti-static bag *in between* the Card
> > and the MicroDesktop PCB.
> >
>
> Is this for anti-static purpose or to add a bit of stability?

although it has that effect, it's there to protect against possible
short-circuit.  the top of the MD is lacquered, and there are no
components, however why take the risk?

anti-static means that when handling - inserting the bag - you don't
zap anything.


> Do you fold your bag to fit the entire length of computer-card?

nonono, that would put pressure on the PCB and bend the connector.
just slide it in gently in a U-shape.

> > you're better off checking with a multimeter.  it's pretty standard
> > (pin positive) however there is no substitute for actually checking.
> > i.e.: don't guess - check.  hardware is unforgiving.
> >
> Bought a multimeter and checked. DC PSU is good to go.

staaaar :)


>
> > > Should we document this somewhere on rhombus-tech.net?
> >
> > yes, good idea.
>
> Will do it in next couple of days.
>
> > > 4. SD-card ready / U-Boot
> > > Tried to compile u-boot-sunxi [4] and make exits with "System not configured".
> > > So Luke, what did you use as config
> >
> > it's on the wiki somewhere.  it has been 5 years so i will be
> > searching just as much as you would be.
>
> Ok.

there should be some a20_defconfigs... sitemap...  arse.  no, let's
try the git repo instead...
http://rhombus-tech.net/allwinner_a10/boot/

AH!  GOT IT:
http://rhombus-tech.net/allwinner/a20/boot/

there you go.

> After a quick check it seems one can not create subpages from the online
> editor (only edit pages).

yes, this is standard practice.  you create the link on the parent,
first, then it creates a question-mark, then you get an edit link.  if
you know what you're doing you can manually create edit links :)

> Can I still send you an ssh-key to get a better access to the wiki?

sure.  that would help you as well as you can use "find" etc.

in case it wasn't obvious, thank you for this. pablo.  i really
appreciate you taking the time to get this sorted.

l.


From lkcl at lkcl.net  Thu Jul  9 11:49:02 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Thu, 9 Jul 2020 11:49:02 +0100
Subject: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
In-Reply-To: <CA+kEFNKrV0VgazXYMUTVHSZgWR++YvFq9L7_8KeSPisHCMdO5w@mail.gmail.com>
References: <20200616084447.zq25ovnqbfotyb5h@pabbook>
	<CAPweEDzOKuB8gJzE1APurcOFE6s3rJQyTnKng2eY2HNWY51Z8w@mail.gmail.com>
	<20200709102729.iwox3ruslk5nxuk7@cherry>
	<CA+kEFNKrV0VgazXYMUTVHSZgWR++YvFq9L7_8KeSPisHCMdO5w@mail.gmail.com>
Message-ID: <CAPweEDwdEYicZBRhOZ=+5=A6SCvdV4xMvL+mqXuVK0ZVGDPZ4w@mail.gmail.com>

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

On Thu, Jul 9, 2020 at 11:40 AM Christopher Havel <laserhawk64 at gmail.com> wrote:
>
> Forgive the horribly embarrassingly so-late-it's-early chime-in from a dork
> on his phone :P but it's worth noting that antistatic bags are generally
> conductive on one side (and only one side!) -- especially the
> darkly-translucent aluminized Mylar kind.

ah.  that's good to know :)

i've never had any issues with this, perhaps a different type of bag?

still if you are concerned, pablo, use a piece of paper instead.  just
please not a plastic bag (PC, Nylon, PVA)

it goes without saying that you should not be wearing your favourite
polyester shirt, rubber-soled shoes and the 70s nylon fashionable
trousers and the brown wool hairy cardigan [i actually had one of
those], doing this all on the shag rug carpet.

if you don't have an anti-static mat (with the strap and everything)
then a tiled floor, wooden desk, and if you have a radiator nearby or
you know *for a fact* that a piece of electrical or electronic
equipment has an earth connection (many laptop PSUs *DO NOT HAVE
GROUND*) just touch the metal before handling the PCBs ok?

l.


From pablo at parobalth.org  Fri Jul 10 07:59:07 2020
From: pablo at parobalth.org (Pablo Rath)
Date: Fri, 10 Jul 2020 08:59:07 +0200
Subject: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
In-Reply-To: <CAPweEDxw2sUbo_Lrd3P1wzetCkis3EuDiMkQfseghgB03EDCQQ@mail.gmail.com>
References: <20200616084447.zq25ovnqbfotyb5h@pabbook>
	<CAPweEDzOKuB8gJzE1APurcOFE6s3rJQyTnKng2eY2HNWY51Z8w@mail.gmail.com>
	<20200709102729.iwox3ruslk5nxuk7@cherry>
	<CAPweEDxw2sUbo_Lrd3P1wzetCkis3EuDiMkQfseghgB03EDCQQ@mail.gmail.com>
Message-ID: <20200710065907.7djfc3g6xlvfa6ff@avocado>

On Thu, Jul 09, 2020 at 11:43:58AM +0100, Luke Kenneth Casson Leighton wrote:
> On Thu, Jul 9, 2020 at 11:28 AM Pablo Rath <pablo at parobalth.org> wrote:
> 
> 
> > https://www.parobalth.org/eoma68-a20/eoma68-A20_2-7-4_3.JPG
> 
> ah that's better.
> 
> > https://www.parobalth.org/eoma68-a20/eoma68-A20_2-7-4_4.JPG
> 
> ah ha!  cancel that on the 1st one, that looks even on both sides, doesn't it?

Yes, looks even to me.

> 
> ok there's one more: a picture from the *underside* - actually
> *between* the PCBs (try to get some light in there).  don't for
> goodness sake pry the cards apart, obviously you'll need to take the
> anti-static bag out.
> 
> whilst the no 4. photo showed that the pins from the *top* row are not
> showing, i.e. the Card was not inserted too low, this does *NOT*
> guarantee that the card was inserted TOO HIGH.
> 
> and you will find that out by VERY CAREFULLY inspecting *between* the
> PCBs.  if the Card was inserted 1.5 mm too high, you will be able to
> see the bottom PCMCIA row of pins clearly.
> 
> BE CAREFUL ok?

I am extremely careful. I triple checked from all sides and especially
from the *underside* and there are no pins visible. I tried to take a
picture yesterday and today in good daylight, with and without camera
flash, with and without additional lighting but I can't get a usable
picture *between* the PCBs. I wish you could see through my eyes :)
I think we have to trust in my assessment. I am *very* confident that
the connection is correct. 

> 
> > > from visual inspection from the front, it should also be obvious if
> > > the card has been inserted where the top row of pins has gone into the
> > > bottom part of the connector or vice-versa.
> >
> > Visual inspection from the front looks good to me but is difficult to
> > photograph with good light and correct focus.
> >
> > > If You Can See Pins You Got It Wrong.
> >
> > I can't see pins anymore.
> 
> you need to check top and bottom.  top looks good, bottom also needs checking.
> 

Done like described above. 

> > >
> > > also, once inserted, place the anti-static bag *in between* the Card
> > > and the MicroDesktop PCB.
> > >
> >
> > Is this for anti-static purpose or to add a bit of stability?
> 
> although it has that effect, it's there to protect against possible
> short-circuit.  the top of the MD is lacquered, and there are no
> components, however why take the risk?
> 
> anti-static means that when handling - inserting the bag - you don't
> zap anything.
> 
> 
> > Do you fold your bag to fit the entire length of computer-card?
> 
> nonono, that would put pressure on the PCB and bend the connector.
> just slide it in gently in a U-shape.
> 

Ok. 

> >
> > > > 4. SD-card ready / U-Boot
> > > > Tried to compile u-boot-sunxi [4] and make exits with "System not configured".
> > > > So Luke, what did you use as config
> > >
> > > it's on the wiki somewhere.  it has been 5 years so i will be
> > > searching just as much as you would be.
> >
> > Ok.
> 
> there should be some a20_defconfigs... sitemap...  arse.  no, let's
> try the git repo instead...
> http://rhombus-tech.net/allwinner_a10/boot/
> 
> AH!  GOT IT:
> http://rhombus-tech.net/allwinner/a20/boot/
> 
> there you go.

Ah, yes. This is what I found and mentioned in my email. Thank you for
looking it up and confirming. Will give it another try.  
> 
> > After a quick check it seems one can not create subpages from the online
> > editor (only edit pages).
> 
> yes, this is standard practice.  you create the link on the parent,
> first, then it creates a question-mark, then you get an edit link.  if
> you know what you're doing you can manually create edit links :)
> 

Thank you for the crash course. Worked... almost like... *magic*.
I have created a subpage under a20 and will put everthing there and we
can move individual sections later if necessary. 

> in case it wasn't obvious, thank you for this. pablo.  i really
> appreciate you taking the time to get this sorted.

It is kind of obvious but still nice when explicitly mentioned. :)

So the next and last step hardware wise is to solder the UART connection
to the micro desktop? Can I use standard pin headers?

kind regards
Pablo


From pablo at parobalth.org  Fri Jul 10 08:06:10 2020
From: pablo at parobalth.org (Pablo Rath)
Date: Fri, 10 Jul 2020 09:06:10 +0200
Subject: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
In-Reply-To: <CAPweEDwdEYicZBRhOZ=+5=A6SCvdV4xMvL+mqXuVK0ZVGDPZ4w@mail.gmail.com>
References: <20200616084447.zq25ovnqbfotyb5h@pabbook>
	<CAPweEDzOKuB8gJzE1APurcOFE6s3rJQyTnKng2eY2HNWY51Z8w@mail.gmail.com>
	<20200709102729.iwox3ruslk5nxuk7@cherry>
	<CA+kEFNKrV0VgazXYMUTVHSZgWR++YvFq9L7_8KeSPisHCMdO5w@mail.gmail.com>
	<CAPweEDwdEYicZBRhOZ=+5=A6SCvdV4xMvL+mqXuVK0ZVGDPZ4w@mail.gmail.com>
Message-ID: <20200710070610.fpk3jmmm6ghh545o@avocado>

On Thu, Jul 09, 2020 at 11:49:02AM +0100, Luke Kenneth Casson Leighton wrote:
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> 
> On Thu, Jul 9, 2020 at 11:40 AM Christopher Havel <laserhawk64 at gmail.com> wrote:
> >
> > Forgive the horribly embarrassingly so-late-it's-early chime-in from a dork
> > on his phone :P but it's worth noting that antistatic bags are generally
> > conductive on one side (and only one side!) -- especially the
> > darkly-translucent aluminized Mylar kind.
> 
> ah.  that's good to know :)
> 
> i've never had any issues with this, perhaps a different type of bag?
> 
> still if you are concerned, pablo, use a piece of paper instead.  just
> please not a plastic bag (PC, Nylon, PVA)
> 
> it goes without saying that you should not be wearing your favourite
> polyester shirt, rubber-soled shoes and the 70s nylon fashionable
> trousers and the brown wool hairy cardigan [i actually had one of
> those], doing this all on the shag rug carpet.
> 
> if you don't have an anti-static mat (with the strap and everything)
> then a tiled floor, wooden desk, and if you have a radiator nearby or
> you know *for a fact* that a piece of electrical or electronic
> equipment has an earth connection (many laptop PSUs *DO NOT HAVE
> GROUND*) just touch the metal before handling the PCBs ok?

Thank you both for the warning and advice. I am going to take it serious
and be careful.

...besides that your wording is absolutley hilarious. Just imagine me in
the described 70s outfit amidst whisps of *magic smoke*...


From lkcl at lkcl.net  Fri Jul 10 14:03:23 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Fri, 10 Jul 2020 14:03:23 +0100
Subject: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
In-Reply-To: <20200710065907.7djfc3g6xlvfa6ff@avocado>
References: <20200616084447.zq25ovnqbfotyb5h@pabbook>
	<CAPweEDzOKuB8gJzE1APurcOFE6s3rJQyTnKng2eY2HNWY51Z8w@mail.gmail.com>
	<20200709102729.iwox3ruslk5nxuk7@cherry>
	<CAPweEDxw2sUbo_Lrd3P1wzetCkis3EuDiMkQfseghgB03EDCQQ@mail.gmail.com>
	<20200710065907.7djfc3g6xlvfa6ff@avocado>
Message-ID: <CAPweEDxJJg+So8RbqNLkbGuvG5CwCApcT5YODdjXeaDtZe+=Sw@mail.gmail.com>

> On Thu, Jul 09, 2020 at 11:43:58AM +0100, Luke Kenneth Casson Leighton wrote:

> So the next and last step hardware wise is to solder the UART connection
> to the micro desktop? Can I use standard pin headers?

yehyeh.  that's what it's for.  standard 2.54mm pitch.  it's designed
precisely for that.

actually i soldered directly to the PCB.  don't tell no-one :)

http://rhombus-tech.net/allwinner/a20/eoma68_a20_usb_uart_connect.jpg

there you will see *only* GND, TX and RX connected.  do not *under any
circumstances* connect the VCC_IO line.  this is a reference power
supply *from the USB UART*.  so is the 3.3v supply from the EOMA68
PCB.

if you connect them together they will destroy each other.

given that USB UART is "pulldown" (floating indicates LOW) it is
perfectly fine not to have a converter IC.  which normally would be
the responsibility of the developer to create an external PCB that did
that.  if they wanted to.  rather than use the pins as GPIO.

when doing it this way (without a converter IC) you will find however
that even just the power coming from the TX and RX pins is enough to
provide 3.3v to the actual A20 processor.

therefore you *will* need to disconnect the USB cable when powering
down.  simply switching off the 12v PSU (15v in your case) is *not
enough*.

also watch out for GROUND loops between:

* laptop / desktop PSU
* laptop / desktop
* USB UART port connected to laptop
* EOMA68 PCB
* 12 (15) volt PSU

if you get problems (which will show up as corrupted data and possible
eventual destruction of the FT232 USB UART IC - yes this is just how
it goes) then disconnect the laptop's PSU whilst powering on.

i have in the past hotwired a 5V USB cable (cut the connector off)
directly into the 5V rail of the micro-desktop PCB, bypassing the RT
power converter IC.  if you happen to have one of those "back-to-back
USB cables" around (i had one for a laptop fan base for example) then
you could actually plug that back-to-back USB cable directly into one
of the micro-desktop USB ports.

the USB power is connected straight to the 5.0V rail, which in turn
(through a SY6280 current limiter) powers the EOMA68 Card.

that way you could plug the back-to-back USB cable into the *same
device* as what you also plug in the USB-UART, and you will not end up
with 240v mains-related power fluctuations on the GND cables.

which as i warned you about, in some PSUs might not actually exist
(particularly cheap PSUs - they have a plastic GND pin here in the
UK).

when that happens the *only way* that you get a common GND reference
is actually *through the EOMA68 PCB* via the USB cable, and that
really does not go down well when there is a large amount of 240v 50
hz EMI being radiated about.

l.


From paul at boddie.org.uk  Sat Jul 18 18:19:37 2020
From: paul at boddie.org.uk (Paul Boddie)
Date: Sat, 18 Jul 2020 19:19:37 +0200
Subject: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
In-Reply-To: <20200710065907.7djfc3g6xlvfa6ff@avocado>
References: <20200616084447.zq25ovnqbfotyb5h@pabbook>
	<CAPweEDxw2sUbo_Lrd3P1wzetCkis3EuDiMkQfseghgB03EDCQQ@mail.gmail.com>
	<20200710065907.7djfc3g6xlvfa6ff@avocado>
Message-ID: <1905390.52KMNcSDfW@jason>

On Friday, 10 July 2020 08:59:07 CEST Pablo Rath wrote:
> On Thu, Jul 09, 2020 at 11:43:58AM +0100, Luke Kenneth Casson Leighton 
wrote:
> > 
> > yes, this is standard practice.  you create the link on the parent,
> > first, then it creates a question-mark, then you get an edit link.  if
> > you know what you're doing you can manually create edit links :)
> 
> Thank you for the crash course. Worked... almost like... *magic*.
> I have created a subpage under a20 and will put everthing there and we
> can move individual sections later if necessary.

I think I had similar problems until I realised that it is all very "old-
school wiki", first creating links for new pages in existing pages, then 
getting the magic question mark, and then having the opportunity to create the 
new page. I suppose it encourages people to link to new content and to 
consider whether they really need a new page.

I saw that there is a section about legacy U-Boot in the page:

http://rhombus-tech.net/allwinner/a20/EOMA68-A20_2-7-4_preproduction/

The experience I had with old U-Boot versions that were contemporary with 
older versions of GCC is that the compiler-tweaking headers from Linux 
generally spew out lots of errors with newer compilers. One apparent solution 
was to just copy in the header from a more recent version of Linux (or maybe 
U-Boot) which is what I did for the MIPS Creator CI20 U-Boot, copying from a 
more recent version of Linux:

cp ../CI20_linux-ci20-v3.18/include/linux/compiler-gcc.h include/linux

However, that doesn't seem to be sufficient here. The structure of the Linux 
headers have changed, and while newer U-Boot versions seem to have adopted 
this structure, it doesn't seem to be easy to introduce to the legacy U-Boot 
for the Allwinner boards.

So, what seems to be necessary is to get an older compiler and to use that 
instead. Since distributions retire older compilers regularly, I used 
Buildroot to create a suitable GCC 4.9 cross-compiler than can then build the 
legacy U-Boot. To make things complicated here, Buildroot also retires support 
for older compilers, so I had to find a version still supporting GCC 4.x that 
didn't also suffer from this issue:

https://git.busybox.net/buildroot/commit/?
id=c48f8a64626c60bd1b46804b7cf1a699ff53cdf3

Anyway, here are the commands I used:

git clone git://git.buildroot.net/buildroot
cd buildroot
git checkout 2018.08.4
make menuconfig

In the menu, the following settings were inspected/changed:

Target options
  Target Architecture (ARM (little endian))
  Target Binary Format (ELF)
  Target Architecture Variant
  Target ABI (EABIhf)
  Floating point strategy (NEON/VFPv4)
  ARM instruction set (ARM)

Toolchain
  GCC compiler Version (gcc 4.9.x)

To build the toolchain, run...

make toolchain

(Use -j <processes> for parallel builds, of course. You may need to install 
rsync if you haven't already done so. Other packages may also be necessary.)

Setting PATH to reference this toolchain in output/host/bin, you can now build 
the legacy U-Boot as follows:

git clone https://github.com/linux-sunxi/u-boot-sunxi.git
cd u-boot-sunxi
make CROSS_COMPILE=arm-linux- EOMA68_A20_config
make CROSS_COMPILE=arm-linux-

(Again, use -j <processes> to make this go faster. Note that Buildroot 
compilers tend to use their own naming, so it is arm-linux- and not arm-linux-
gnueabihf- that needs to be used.)

Here, the use of EOMA68_A20_config sets up a bootloader for SD cards, whereas 
EOMA68_A20_FEL_config would set up a USB-bootable payload. See here for all 
the details:

https://github.com/linux-sunxi/u-boot-sunxi/wiki

This should get you the u-boot-sunxi-with-spl.bin file that needs to be 
deployed.

Hope this was helpful!

Paul




From pablo at parobalth.org  Sun Jul 19 12:17:38 2020
From: pablo at parobalth.org (Pablo Rath)
Date: Sun, 19 Jul 2020 13:17:38 +0200
Subject: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
In-Reply-To: <1905390.52KMNcSDfW@jason>
References: <20200616084447.zq25ovnqbfotyb5h@pabbook>
	<CAPweEDxw2sUbo_Lrd3P1wzetCkis3EuDiMkQfseghgB03EDCQQ@mail.gmail.com>
	<20200710065907.7djfc3g6xlvfa6ff@avocado>
	<1905390.52KMNcSDfW@jason>
Message-ID: <20200719111737.fnqekqvocerothan@pabbook>

>On Sat, Jul 18, 2020 at 07:19:37PM +0200, Paul Boddie wrote:
> 
> I saw that there is a section about legacy U-Boot in the page:
> 
> http://rhombus-tech.net/allwinner/a20/EOMA68-A20_2-7-4_preproduction/
> 

Yes, obviously I had to start with U-Boot first. 
Luke told me that sunxi U-Boot should build fine and that nothing has
changed so I started there.

For mainline U-Boot I still need a valid config file to do 'make
eoma68_foo_defconfig'. There is a .dts file here
(http://rhombus-tech.net/allwinner/a20/boot/sun7i-a20-eoma68-a20.dts)
but I don't know if it was used for mainline U-Boot and not just for
Kernel compilation. 

> The experience I had with old U-Boot versions that were contemporary with 
> older versions of GCC is that the compiler-tweaking headers from Linux 
> generally spew out lots of errors with newer compilers. One apparent solution 
> was to just copy in the header from a more recent version of Linux (or maybe 
> U-Boot) which is what I did for the MIPS Creator CI20 U-Boot, copying from a 
> more recent version of Linux:
> 
> cp ../CI20_linux-ci20-v3.18/include/linux/compiler-gcc.h include/linux
> 
> However, that doesn't seem to be sufficient here. The structure of the Linux 
> headers have changed, and while newer U-Boot versions seem to have adopted 
> this structure, it doesn't seem to be easy to introduce to the legacy U-Boot 
> for the Allwinner boards.
> 
> So, what seems to be necessary is to get an older compiler and to use that 
> instead. Since distributions retire older compilers regularly, I used 
> Buildroot to create a suitable GCC 4.9 cross-compiler than can then build the 
> legacy U-Boot. 

I have realised that on Debian gcc versions are kept installed. I have
a native armhf installation (initially installed with Jessie) currently
upgraded to stretch and gcc-4.9 is still installed. Changed between gcc
versions with 'update-alternatives'. I don't know if this also apllies
to cross-toolchains because my experience with crossbuilding is limited. 

Sid (unstable) still has gcc-4.9 and even gcc-4.7 native armhf packages
so this could be another solution I have not tested yes as I have no
armhf sid installation. 

>To make things complicated here, Buildroot also retires support 
> for older compilers, so I had to find a version still supporting GCC 4.x that 
> didn't also suffer from this issue:
> 
> https://git.busybox.net/buildroot/commit/?
> id=c48f8a64626c60bd1b46804b7cf1a699ff53cdf3
> 
> Anyway, here are the commands I used:
> 
> git clone git://git.buildroot.net/buildroot
> cd buildroot
> git checkout 2018.08.4
> make menuconfig
> 
> In the menu, the following settings were inspected/changed:
> 
> Target options
>   Target Architecture (ARM (little endian))
>   Target Binary Format (ELF)
>   Target Architecture Variant
>   Target ABI (EABIhf)
>   Floating point strategy (NEON/VFPv4)
>   ARM instruction set (ARM)
> 
> Toolchain
>   GCC compiler Version (gcc 4.9.x)
> 
> To build the toolchain, run...
> 
> make toolchain
> 
> (Use -j <processes> for parallel builds, of course. You may need to install 
> rsync if you haven't already done so. Other packages may also be necessary.)
> 
> Setting PATH to reference this toolchain in output/host/bin, you can now build 
> the legacy U-Boot as follows:
> 
> git clone https://github.com/linux-sunxi/u-boot-sunxi.git
> cd u-boot-sunxi
> make CROSS_COMPILE=arm-linux- EOMA68_A20_config
> make CROSS_COMPILE=arm-linux-
> 
> (Again, use -j <processes> to make this go faster. Note that Buildroot 
> compilers tend to use their own naming, so it is arm-linux- and not arm-linux-
> gnueabihf- that needs to be used.)
> 

This is extremly helpful. I am going to try it out. Can you copy that to
the wiki? Maybe as a separate subpage or at the end. I think we should
keep everything short and clear for those who know what they are doing
but still provide enough hand-holding and external context for those
with less experience.  

> Here, the use of EOMA68_A20_config sets up a bootloader for SD cards, whereas 
> EOMA68_A20_FEL_config would set up a USB-bootable payload. See here for all 
> the details:
> 
> https://github.com/linux-sunxi/u-boot-sunxi/wiki
> 
> This should get you the u-boot-sunxi-with-spl.bin file that needs to be 
> deployed.

Good news is that I made it to the sunxi U-Boot prompt on Friday. Booted
via USB-FEL. So my
soldered Pins, UART connection, Power Supply, µUSB-OTG on the card work fine.

Next I have planned to compile a sunxi 3.4 Kernel and debootstrap a
Debian rootfs.
Then I want to try mainline U-Boot and a mainline Kernel.
Feel free to share your solutions and best practices with me!

> 
> Hope this was helpful!

Thank you for your help. Please add to the wiki. 

Pablo


From lkcl at lkcl.net  Sun Jul 19 13:17:21 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Sun, 19 Jul 2020 13:17:21 +0100
Subject: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
In-Reply-To: <20200719111737.fnqekqvocerothan@pabbook>
References: <20200616084447.zq25ovnqbfotyb5h@pabbook>
	<CAPweEDxw2sUbo_Lrd3P1wzetCkis3EuDiMkQfseghgB03EDCQQ@mail.gmail.com>
	<20200710065907.7djfc3g6xlvfa6ff@avocado> <1905390.52KMNcSDfW@jason>
	<20200719111737.fnqekqvocerothan@pabbook>
Message-ID: <CAPweEDzdahz6M7Zre3oGt1iak0u0ATE2fjkftwy=VQdJwMFfQg@mail.gmail.com>

(btw thank you paul - and pablo - both)

On Sun, Jul 19, 2020 at 12:18 PM Pablo Rath <pablo at parobalth.org> wrote:
>
> >On Sat, Jul 18, 2020 at 07:19:37PM +0200, Paul Boddie wrote:
> >
> > I saw that there is a section about legacy U-Boot in the page:
> >
> > http://rhombus-tech.net/allwinner/a20/EOMA68-A20_2-7-4_preproduction/
> >
>
> Yes, obviously I had to start with U-Boot first.
> Luke told me that sunxi U-Boot should build fine and that nothing has
> changed so I started there.
>
> For mainline U-Boot I still need a valid config file to do 'make
> eoma68_foo_defconfig'. There is a .dts file here
> (http://rhombus-tech.net/allwinner/a20/boot/sun7i-a20-eoma68-a20.dts)
> but I don't know if it was used for mainline U-Boot and not just for
> Kernel compilation.

it would be both (for mainline in each case).

> I have realised that on Debian gcc versions are kept installed.

yes, i have 35 separate different gcc compiler packages installed and
unfortunately at some point i removed the gnueabihf arm 4.7.2 one.
damn

> I have
> a native armhf installation (initially installed with Jessie) currently
> upgraded to stretch and gcc-4.9 is still installed. Changed between gcc
> versions with 'update-alternatives'. I don't know if this also apllies
> to cross-toolchains because my experience with crossbuilding is limited.

export the right environment variables and it's not necessary to use
"update-alternatives".

export CC=gcc-4.9
export CROSS_COMPILE=arm-linux-gnueabihf- (or something)
export ARCH=arm

or just:

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- CC=gcc-4.9 {insertwhatever}

yes, here you go, the "make blah blah" lines:
http://rhombus-tech.net/allwinner/a20/boot/

just add the extra parameter CC=gcc-4.9 (or gcc-4.7)


> Sid (unstable) still has gcc-4.9 and even gcc-4.7 native armhf packages
> so this could be another solution I have not tested yes as I have no
> armhf sid installation.

arse.  this is the earliest i can find so far.

http://ftp.debian.org/debian/pool/main/g/gcc-6-cross/

that *might* be back far enough to work.


> This is extremly helpful. I am going to try it out. Can you copy that to
> the wiki?

yes please, paul.

> > This should get you the u-boot-sunxi-with-spl.bin file that needs to be
> > deployed.
>
> Good news is that I made it to the sunxi U-Boot prompt on Friday. Booted
> via USB-FEL. So my
> soldered Pins, UART connection, Power Supply, µUSB-OTG on the card work fine.

fantastic!

> Next I have planned to compile a sunxi 3.4 Kernel and debootstrap a
> Debian rootfs.

you should pretty much be able to download and use anything.  use
debootstrap if you like (in cross-arch mode).  this you can do using
qemu-arm to "prepare / finish" things.  actually there's now a
qemu-debootstrap command so it should be dead simple:

http://logan.tw/posts/2017/01/21/introduction-to-qemu-debootstrap/


> Then I want to try mainline U-Boot and a mainline Kernel.

good idea.

l.


From paul at boddie.org.uk  Sun Jul 19 13:29:47 2020
From: paul at boddie.org.uk (Paul Boddie)
Date: Sun, 19 Jul 2020 14:29:47 +0200
Subject: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
In-Reply-To: <20200719111737.fnqekqvocerothan@pabbook>
References: <20200616084447.zq25ovnqbfotyb5h@pabbook>
	<1905390.52KMNcSDfW@jason>
	<20200719111737.fnqekqvocerothan@pabbook>
Message-ID: <2174894.T1YheNfcNQ@jason>

On Sunday, 19 July 2020 13:17:38 CEST Pablo Rath wrote:
> >On Sat, Jul 18, 2020 at 07:19:37PM +0200, Paul Boddie wrote:
> > I saw that there is a section about legacy U-Boot in the page:
> > 
> > http://rhombus-tech.net/allwinner/a20/EOMA68-A20_2-7-4_preproduction/
> 
> Yes, obviously I had to start with U-Boot first.
> Luke told me that sunxi U-Boot should build fine and that nothing has
> changed so I started there.
> 
> For mainline U-Boot I still need a valid config file to do 'make
> eoma68_foo_defconfig'. There is a .dts file here
> (http://rhombus-tech.net/allwinner/a20/boot/sun7i-a20-eoma68-a20.dts)
> but I don't know if it was used for mainline U-Boot and not just for
> Kernel compilation.

I'm not sure what the relationship is between U-Boot and Linux. My impression 
is that U-Boot borrows code from Linux, and there are benefits to U-Boot 
knowing about device tree files, but my own experiences with U-Boot 
development are rather limited.

[...]

> > So, what seems to be necessary is to get an older compiler and to use that
> > instead. Since distributions retire older compilers regularly, I used
> > Buildroot to create a suitable GCC 4.9 cross-compiler than can then build
> > the legacy U-Boot.
> 
> I have realised that on Debian gcc versions are kept installed. I have
> a native armhf installation (initially installed with Jessie) currently
> upgraded to stretch and gcc-4.9 is still installed. Changed between gcc
> versions with 'update-alternatives'. I don't know if this also apllies
> to cross-toolchains because my experience with crossbuilding is limited.
> 
> Sid (unstable) still has gcc-4.9 and even gcc-4.7 native armhf packages
> so this could be another solution I have not tested yes as I have no
> armhf sid installation.

It's useful to hear that GCC versions are kept around. Recently, I upgraded 
hardware and now have Debian Buster installed, and I think GCC 7 is about as 
old as the packages get. For cross-compilers, GCC 8 seems to be what is 
offered.

I did realise that you had probably managed just fine without having to find a 
toolchain, but it is probably useful to provide a path for others to follow as 
well.

[...]

> This is extremly helpful. I am going to try it out. Can you copy that to
> the wiki? Maybe as a separate subpage or at the end. I think we should
> keep everything short and clear for those who know what they are doing
> but still provide enough hand-holding and external context for those
> with less experience.

I'll try and add the recipes to the wiki. I was going to do so, but then found 
myself doing other things instead.

[...]

> Good news is that I made it to the sunxi U-Boot prompt on Friday. Booted
> via USB-FEL. So my
> soldered Pins, UART connection, Power Supply, µUSB-OTG on the card work
> fine.

Great!

> Next I have planned to compile a sunxi 3.4 Kernel and debootstrap a
> Debian rootfs.
> Then I want to try mainline U-Boot and a mainline Kernel.
> Feel free to share your solutions and best practices with me!

I'll try and take another look at this today. Hopefully, the old code can 
still be built without too many obstacles. The mainline code might present 
some challenges, at least with regard to specific hardware support.

Paul




From lkcl at lkcl.net  Sun Jul 19 14:10:52 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Sun, 19 Jul 2020 14:10:52 +0100
Subject: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
In-Reply-To: <2174894.T1YheNfcNQ@jason>
References: <20200616084447.zq25ovnqbfotyb5h@pabbook>
	<1905390.52KMNcSDfW@jason>
	<20200719111737.fnqekqvocerothan@pabbook> <2174894.T1YheNfcNQ@jason>
Message-ID: <CAPweEDyjdc6F0wMzMUkryz3-Y0kX6Kaqt=3MC8Lu9fy_Gv2_ug@mail.gmail.com>

On Sun, Jul 19, 2020 at 1:30 PM Paul Boddie <paul at boddie.org.uk> wrote:

> I'm not sure what the relationship is between U-Boot and Linux. My impression
> is that U-Boot borrows code from Linux,

yes.  they basically borrow / forward-port (on an irregular basis)
device driver code.  combined with parts of libc6 (or uclibc),
"executables" can be built with a minimum of fuss that look pretty
much like standard c programs except that it's one entire static
binary.  imagine something like busybox combined with parts of the
linux kernel into a single static in-memory binary and that's pretty
much what it is.

l.


From paul at boddie.org.uk  Sun Jul 19 16:17:48 2020
From: paul at boddie.org.uk (Paul Boddie)
Date: Sun, 19 Jul 2020 17:17:48 +0200
Subject: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
In-Reply-To: <CAPweEDzdahz6M7Zre3oGt1iak0u0ATE2fjkftwy=VQdJwMFfQg@mail.gmail.com>
References: <20200616084447.zq25ovnqbfotyb5h@pabbook>
	<20200719111737.fnqekqvocerothan@pabbook>
	<CAPweEDzdahz6M7Zre3oGt1iak0u0ATE2fjkftwy=VQdJwMFfQg@mail.gmail.com>
Message-ID: <16795888.6kndLeLFWl@jason>

On Sunday, 19 July 2020 14:17:21 CEST Luke Kenneth Casson Leighton wrote:
> (btw thank you paul - and pablo - both)
> 
> On Sun, Jul 19, 2020 at 12:18 PM Pablo Rath <pablo at parobalth.org> wrote:
> >
> > This is extremly helpful. I am going to try it out. Can you copy that to
> > the wiki?
> 
> yes please, paul.

OK, I've updated this page...

http://rhombus-tech.net/allwinner_a10/source_code/

It now links to these pages:

http://rhombus-tech.net/allwinner_a10/Buildroot_Toolchain/
http://rhombus-tech.net/allwinner_a10/Building_U-Boot/

Hopefully, it still makes sense and can be followed by anyone wanting to get 
involved with this.

Paul




From hendrik at topoi.pooq.com  Sun Jul 19 16:28:27 2020
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Sun, 19 Jul 2020 11:28:27 -0400
Subject: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
In-Reply-To: <CAPweEDzdahz6M7Zre3oGt1iak0u0ATE2fjkftwy=VQdJwMFfQg@mail.gmail.com>
References: <20200616084447.zq25ovnqbfotyb5h@pabbook>
	<CAPweEDxw2sUbo_Lrd3P1wzetCkis3EuDiMkQfseghgB03EDCQQ@mail.gmail.com>
	<20200710065907.7djfc3g6xlvfa6ff@avocado>
	<1905390.52KMNcSDfW@jason>
	<20200719111737.fnqekqvocerothan@pabbook>
	<CAPweEDzdahz6M7Zre3oGt1iak0u0ATE2fjkftwy=VQdJwMFfQg@mail.gmail.com>
Message-ID: <20200719152826.rrrq6beex5576cbt@topoi.pooq.com>

On Sun, Jul 19, 2020 at 01:17:21PM +0100, Luke Kenneth Casson Leighton wrote:

> 
> > Sid (unstable) still has gcc-4.9 and even gcc-4.7 native armhf packages
> > so this could be another solution I have not tested yes as I have no
> > armhf sid installation.
> 
> arse.  this is the earliest i can find so far.
> 
> http://ftp.debian.org/debian/pool/main/g/gcc-6-cross/
> 
> that *might* be back far enough to work.

debian does have an archive site somewhere where they keep totally 
obsolete and discontinued distributions.  It may be worth while looking 
for it.  I no longer have the link to that site, but I did use it once 
to find a discontinued package.  I managed to download the source 
package.  However, it had so many build-time dependencies that is turned 
out to be essentially useless.

gcc just might have fewer dependencies.  Maybe you can still find the 
one that works for you.

-- hendrik


From lkcl at lkcl.net  Sun Jul 19 16:31:30 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Sun, 19 Jul 2020 16:31:30 +0100
Subject: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
In-Reply-To: <16795888.6kndLeLFWl@jason>
References: <20200616084447.zq25ovnqbfotyb5h@pabbook>
	<20200719111737.fnqekqvocerothan@pabbook>
	<CAPweEDzdahz6M7Zre3oGt1iak0u0ATE2fjkftwy=VQdJwMFfQg@mail.gmail.com>
	<16795888.6kndLeLFWl@jason>
Message-ID: <CAPweEDwkKxXMWZaDJpJcwP7H8YgZBS5cs-b8sKgwPBNpaEEKTw@mail.gmail.com>

On Sunday, July 19, 2020, Paul Boddie <paul at boddie.org.uk> wrote:

>
> OK, I've updated this page...
>
> http://rhombus-tech.net/allwinner_a10/source_code/
>
> It now links to these pages:
>
> http://rhombus-tech.net/allwinner_a10/Buildroot_Toolchain/
> http://rhombus-tech.net/allwinner_a10/Building_U-Boot/


thank you paul, that's really appreciated.

l.



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

From lkcl at lkcl.net  Sun Jul 19 16:32:41 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Sun, 19 Jul 2020 16:32:41 +0100
Subject: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
In-Reply-To: <20200719152826.rrrq6beex5576cbt@topoi.pooq.com>
References: <20200616084447.zq25ovnqbfotyb5h@pabbook>
	<CAPweEDxw2sUbo_Lrd3P1wzetCkis3EuDiMkQfseghgB03EDCQQ@mail.gmail.com>
	<20200710065907.7djfc3g6xlvfa6ff@avocado> <1905390.52KMNcSDfW@jason>
	<20200719111737.fnqekqvocerothan@pabbook>
	<CAPweEDzdahz6M7Zre3oGt1iak0u0ATE2fjkftwy=VQdJwMFfQg@mail.gmail.com>
	<20200719152826.rrrq6beex5576cbt@topoi.pooq.com>
Message-ID: <CAPweEDyNxbmj-ijC+RnuHHjOV00nC-H_dB0MUfkz=0YgD4mGHA@mail.gmail.com>

On Sunday, July 19, 2020, Hendrik Boom <hendrik at topoi.pooq.com> wrote:

> On Sun, Jul 19, 2020 at 01:17:21PM +0100, Luke Kenneth Casson Leighton
> wrote:
>
> >
> > > Sid (unstable) still has gcc-4.9 and even gcc-4.7 native armhf packages
> > > so this could be another solution I have not tested yes as I have no
> > > armhf sid installation.
> >
> > arse.  this is the earliest i can find so far.
> >
> > http://ftp.debian.org/debian/pool/main/g/gcc-6-cross/
> >
> > that *might* be back far enough to work.
>
> debian does have an archive site somewhere where they keep totally
> obsolete and discontinued distributions.


http://archive.debian.org is supposed to be that location.

however the pool directory does not contain gcc cross compilers.

l.



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

From paul at boddie.org.uk  Sun Jul 19 17:05:37 2020
From: paul at boddie.org.uk (Paul Boddie)
Date: Sun, 19 Jul 2020 18:05:37 +0200
Subject: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
In-Reply-To: <CAPweEDyNxbmj-ijC+RnuHHjOV00nC-H_dB0MUfkz=0YgD4mGHA@mail.gmail.com>
References: <20200616084447.zq25ovnqbfotyb5h@pabbook>
	<20200719152826.rrrq6beex5576cbt@topoi.pooq.com>
	<CAPweEDyNxbmj-ijC+RnuHHjOV00nC-H_dB0MUfkz=0YgD4mGHA@mail.gmail.com>
Message-ID: <8269760.Ujr68MHIDi@jason>

On Sunday, 19 July 2020 17:32:41 CEST Luke Kenneth Casson Leighton wrote:
> On Sunday, July 19, 2020, Hendrik Boom <hendrik at topoi.pooq.com> wrote:
> > 
> > debian does have an archive site somewhere where they keep totally
> > obsolete and discontinued distributions.
> 
> http://archive.debian.org is supposed to be that location.
> 
> however the pool directory does not contain gcc cross compilers.

Cross-compilers are relatively new in Debian as broadly supported things 
(ignoring things like Atmel cross-compilers and one-off attempts at providing 
toolchains for some release architectures). I think that they first made it 
into the distribution properly for Stretch, meaning that we're only on the 
second release that has them.

Also, older packages probably have all sorts of dependencies on older 
distribution versions, and with that there's the need to virtualise or chroot 
entire software distributions. And then, it might turn out that the precise 
configuration of the compilers isn't entirely suitable, as I have discovered 
for various SoCs in the past [*].

Paul

[*] However, that was actually related to soft-float support for MIPS, which 
needs to be configured at build-time for GCC, but which was omitted from the 
Debian toolchains because the assumption is that all the code compiled by the 
Debian compiler will be deployed on Linux, and Linux has run-time support for 
floating point instruction emulation (that a bare metal or alternative 
environment might not have). But in general, you cannot be too careful with 
some of this stuff, and not all shortcuts turn out to be what they seemed to 
be.




From pablo at parobalth.org  Sun Jul 19 21:02:07 2020
From: pablo at parobalth.org (Pablo Rath)
Date: Sun, 19 Jul 2020 22:02:07 +0200
Subject: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
In-Reply-To: <CAPweEDzdahz6M7Zre3oGt1iak0u0ATE2fjkftwy=VQdJwMFfQg@mail.gmail.com>
References: <20200616084447.zq25ovnqbfotyb5h@pabbook>
	<CAPweEDxw2sUbo_Lrd3P1wzetCkis3EuDiMkQfseghgB03EDCQQ@mail.gmail.com>
	<20200710065907.7djfc3g6xlvfa6ff@avocado>
	<1905390.52KMNcSDfW@jason>
	<20200719111737.fnqekqvocerothan@pabbook>
	<CAPweEDzdahz6M7Zre3oGt1iak0u0ATE2fjkftwy=VQdJwMFfQg@mail.gmail.com>
Message-ID: <20200719200206.oye5qvrwjoio5zvl@pabbook>

>On Sun, Jul 19, 2020 at 01:17:21PM +0100, Luke Kenneth Casson Leighton wrote:

[...]

> > For mainline U-Boot I still need a valid config file to do 'make
> > eoma68_foo_defconfig'. There is a .dts file here
> > (http://rhombus-tech.net/allwinner/a20/boot/sun7i-a20-eoma68-a20.dts)
> > but I don't know if it was used for mainline U-Boot and not just for
> > Kernel compilation.
> 
> it would be both (for mainline in each case).

Ok. But what did you use as defconfig in configs/ (U-Boot mainline)?
> 
> > I have realised that on Debian gcc versions are kept installed.
> 
> yes, i have 35 separate different gcc compiler packages installed and
> unfortunately at some point i removed the gnueabihf arm 4.7.2 one.
> damn
> 
> > I have
> > a native armhf installation (initially installed with Jessie) currently
> > upgraded to stretch and gcc-4.9 is still installed. Changed between gcc
> > versions with 'update-alternatives'. I don't know if this also apllies
> > to cross-toolchains because my experience with crossbuilding is limited.
> 
> export the right environment variables and it's not necessary to use
> "update-alternatives".
> 
> export CC=gcc-4.9
> export CROSS_COMPILE=arm-linux-gnueabihf- (or something)
> export ARCH=arm
> 
> or just:
> 
> make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- CC=gcc-4.9 {insertwhatever}
> 
> yes, here you go, the "make blah blah" lines:
> http://rhombus-tech.net/allwinner/a20/boot/
> 
> just add the extra parameter CC=gcc-4.9 (or gcc-4.7)
> 
I have read about CC=gcc-foo and tried but it did not work as expected. Maybe I did
something wrong. Will try again. 

Pablo


From lkcl at lkcl.net  Sun Jul 19 21:19:37 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Sun, 19 Jul 2020 21:19:37 +0100
Subject: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
In-Reply-To: <20200719200206.oye5qvrwjoio5zvl@pabbook>
References: <20200616084447.zq25ovnqbfotyb5h@pabbook>
	<CAPweEDxw2sUbo_Lrd3P1wzetCkis3EuDiMkQfseghgB03EDCQQ@mail.gmail.com>
	<20200710065907.7djfc3g6xlvfa6ff@avocado> <1905390.52KMNcSDfW@jason>
	<20200719111737.fnqekqvocerothan@pabbook>
	<CAPweEDzdahz6M7Zre3oGt1iak0u0ATE2fjkftwy=VQdJwMFfQg@mail.gmail.com>
	<20200719200206.oye5qvrwjoio5zvl@pabbook>
Message-ID: <CAPweEDzwg17RXH=WQ6-pWhhktpeVdRG=_6hBYG_KcQg2rshGJA@mail.gmail.com>

On Sun, Jul 19, 2020 at 9:02 PM Pablo Rath <pablo at parobalth.org> wrote:

> Ok. But what did you use as defconfig in configs/ (U-Boot mainline)?

it was 4 years ago: your guess is as good as mine, unless i happened
to put it in the wiki somewhere.

l.


From paul at boddie.org.uk  Sun Jul 19 21:35:31 2020
From: paul at boddie.org.uk (Paul Boddie)
Date: Sun, 19 Jul 2020 22:35:31 +0200
Subject: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
In-Reply-To: <CAPweEDzwg17RXH=WQ6-pWhhktpeVdRG=_6hBYG_KcQg2rshGJA@mail.gmail.com>
References: <20200616084447.zq25ovnqbfotyb5h@pabbook>
	<20200719200206.oye5qvrwjoio5zvl@pabbook>
	<CAPweEDzwg17RXH=WQ6-pWhhktpeVdRG=_6hBYG_KcQg2rshGJA@mail.gmail.com>
Message-ID: <1840268.Wscf4kDpAb@jason>

On Sunday, 19 July 2020 22:19:37 CEST Luke Kenneth Casson Leighton wrote:
> On Sun, Jul 19, 2020 at 9:02 PM Pablo Rath <pablo at parobalth.org> wrote:
> > Ok. But what did you use as defconfig in configs/ (U-Boot mainline)?
> 
> it was 4 years ago: your guess is as good as mine, unless i happened
> to put it in the wiki somewhere.

Currently, I am updating this page:

http://rhombus-tech.net/allwinner_a10/Building_Linux/

On which I noted that the boot page...

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

...provides a special configuration (eoma68-a20-4.7-config) that would 
presumably get copied into the configs directory as some kind of defconfig. 
However, it is probably superseded by the sunxi_defconfig file now, for the 
most part.

It looks like the device tree (sun7i-a20-eoma68-a20.dts) is very similar to 
that from the Cubietruck 2. Were the differences documented and are there any 
schematics to provide any necessary insight when updating the device tree? 
(Since these things appear to change all the time - or just decay - in the 
Linux kernel distribution.)

Paul




From lkcl at lkcl.net  Sun Jul 19 21:43:59 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Sun, 19 Jul 2020 21:43:59 +0100
Subject: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
In-Reply-To: <1840268.Wscf4kDpAb@jason>
References: <20200616084447.zq25ovnqbfotyb5h@pabbook>
	<20200719200206.oye5qvrwjoio5zvl@pabbook>
	<CAPweEDzwg17RXH=WQ6-pWhhktpeVdRG=_6hBYG_KcQg2rshGJA@mail.gmail.com>
	<1840268.Wscf4kDpAb@jason>
Message-ID: <CAPweEDxh4rZ4su4Y+jA-xLmfn2dd1iqJLy=9VB=9QuRT54oqnQ@mail.gmail.com>

On Sun, Jul 19, 2020 at 9:35 PM Paul Boddie <paul at boddie.org.uk> wrote:
>
> On Sunday, 19 July 2020 22:19:37 CEST Luke Kenneth Casson Leighton wrote:
> > On Sun, Jul 19, 2020 at 9:02 PM Pablo Rath <pablo at parobalth.org> wrote:
> > > Ok. But what did you use as defconfig in configs/ (U-Boot mainline)?
> >
> > it was 4 years ago: your guess is as good as mine, unless i happened
> > to put it in the wiki somewhere.
>
> Currently, I am updating this page:
>
> http://rhombus-tech.net/allwinner_a10/Building_Linux/
>
> On which I noted that the boot page...
>
> http://rhombus-tech.net/allwinner/a20/boot/
>
> ...provides a special configuration (eoma68-a20-4.7-config) that would
> presumably get copied into the configs directory as some kind of defconfig.
> However, it is probably superseded by the sunxi_defconfig file now, for the
> most part.

sounds about right.

> It looks like the device tree (sun7i-a20-eoma68-a20.dts) is very similar to
> that from the Cubietruck 2.

that sounds about right.  possibly the original cubieboard.

> Were the differences documented and are there any
> schematics to provide any necessary insight when updating the device tree?

there's PDFs somewhere... http://hands.com/~lkcl/eoma/
such as this: http://hands.com/~lkcl/eoma/DS113-V2.7-2017-02-17.pdf

the thing is that it is critically important that the dts file *do
not* include the peripherals associated with the "Boards"
(Micro-Desktop, 15in laptop).  the peripheral sets *MUST* go into a
"dynamic include" file that is detected at boot time and "inserted"
into the live device-tree.

this functionality - dynamic runtime "insertion" of device-tree
fragments - was an idea *in development* back in.... 2013  we have had
to wait several years for this functionality to make its way into both
u-boot and the linux kernel.

l.


From paul at boddie.org.uk  Sun Jul 19 22:32:05 2020
From: paul at boddie.org.uk (Paul Boddie)
Date: Sun, 19 Jul 2020 23:32:05 +0200
Subject: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
In-Reply-To: <CAPweEDxh4rZ4su4Y+jA-xLmfn2dd1iqJLy=9VB=9QuRT54oqnQ@mail.gmail.com>
References: <20200616084447.zq25ovnqbfotyb5h@pabbook>
	<1840268.Wscf4kDpAb@jason>
	<CAPweEDxh4rZ4su4Y+jA-xLmfn2dd1iqJLy=9VB=9QuRT54oqnQ@mail.gmail.com>
Message-ID: <1825604.k1WfSWoTxO@jason>

On Sunday, 19 July 2020 22:43:59 CEST Luke Kenneth Casson Leighton wrote:
> On Sun, Jul 19, 2020 at 9:35 PM Paul Boddie <paul at boddie.org.uk> wrote:
> >
> > It looks like the device tree (sun7i-a20-eoma68-a20.dts) is very similar
> > to that from the Cubietruck 2.
> 
> that sounds about right.  possibly the original cubieboard.

OK. From what I can see, there are strong similarities between the above file 
and both sun4i-a10-cubieboard.dts and sun7i-a20-cubieboard2.dts. (I got mixed 
up and wrote Cubietruck 2 above.)

The principal differences appear to be as follows:

The EOMA68-A20 DT doesn't have HDMI nodes whereas the Cubieboard DTs have 
nodes for HDMI connectors and the usual peripheral nodes (&hdmi, &hdmi_out). 
Given the effort that went into putting micro-HDMI on the computer card, I 
guess there might be some definitions to add here.

The EOMA68-A20 DT has a special pinctrl node for mmc3_cd_pin (MMC3 card 
detect, I guess). There are also LED pin differences, but I think these are 
explained by pin definitions migrating to the sun7i-a20.dtsi file.

Some I2C definitions seem to be different in the Cubieboard DTs, but that 
could also be due to pin definitions migrating to the sun7i-a20.dtsi file.

The Cubieboard DTs enable the display engine (&de) and power 
(&ac_power_supply).

There are some changes to the Ethernet node (&gmac). (I didn't think Ethernet 
was exposed by the computer cards when the specification was updated after the 
first round of cards being made.)

The Cubieboard DTs enable USB OTG (&usb_otg) whereas the EOMA68-A20 DT has a 
node &reg_usb0_vbus that the other DTs do not have.

So, it seems possible that an updated DT file would be a minor variation on 
the Cubieboard 2 file.

> > Were the differences documented and are there any
> > schematics to provide any necessary insight when updating the device tree?
> 
> there's PDFs somewhere... http://hands.com/~lkcl/eoma/
> such as this: http://hands.com/~lkcl/eoma/DS113-V2.7-2017-02-17.pdf

And, as usual, when I go to download it, I find that I already have it 
alongside a schematic for the Cubietruck!

> the thing is that it is critically important that the dts file *do
> not* include the peripherals associated with the "Boards"
> (Micro-Desktop, 15in laptop).  the peripheral sets *MUST* go into a
> "dynamic include" file that is detected at boot time and "inserted"
> into the live device-tree.

Indeed. I guess the computer card device tree sits at a level between the 
chipset device tree and what would normally be the machine device tree.

> this functionality - dynamic runtime "insertion" of device-tree
> fragments - was an idea *in development* back in.... 2013  we have had
> to wait several years for this functionality to make its way into both
> u-boot and the linux kernel.

I guess I should ask whether such support made it into either of them.

Paul




From lkcl at lkcl.net  Sun Jul 19 23:20:58 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Sun, 19 Jul 2020 23:20:58 +0100
Subject: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
In-Reply-To: <1825604.k1WfSWoTxO@jason>
References: <20200616084447.zq25ovnqbfotyb5h@pabbook>
	<1840268.Wscf4kDpAb@jason>
	<CAPweEDxh4rZ4su4Y+jA-xLmfn2dd1iqJLy=9VB=9QuRT54oqnQ@mail.gmail.com>
	<1825604.k1WfSWoTxO@jason>
Message-ID: <CAPweEDx3PCqRTP2AJ6ub-obshFBr4UvhQbTdegn91XgSfnkS_w@mail.gmail.com>

On Sunday, July 19, 2020, Paul Boddie <paul at boddie.org.uk> wrote:

> On Sunday, 19 July 2020 22:43:59 CEST Luke Kenneth Casson Leighton wrote:
> > On Sun, Jul 19, 2020 at 9:35 PM Paul Boddie <paul at boddie.org.uk> wrote:
> > >
> > > It looks like the device tree (sun7i-a20-eoma68-a20.dts) is very
> similar
> > > to that from the Cubietruck 2.
> >
> > that sounds about right.  possibly the original cubieboard.
>
> OK. From what I can see, there are strong similarities between the above
> file
> and both sun4i-a10-cubieboard.dts and sun7i-a20-cubieboard2.dts. (I got
> mixed
> up and wrote Cubietruck 2 above.)
>
> The principal differences appear to be as follows:
>
> The EOMA68-A20 DT doesn't have HDMI nodes whereas the Cubieboard DTs have
> nodes for HDMI connectors and the usual peripheral nodes (&hdmi,
> &hdmi_out).
> Given the effort that went into putting micro-HDMI on the computer card, I
> guess there might be some definitions to add here.


yes.


>
> The EOMA68-A20 DT has a special pinctrl node for mmc3_cd_pin (MMC3 card
> detect, I guess). There are also LED pin differences, but I think these
> are
> explained by pin definitions migrating to the sun7i-a20.dtsi file.


ah.  the updates to the hardware it is now mmc0


>
> Some I2C definitions seem to be different in the Cubieboard DTs, but that
> could also be due to pin definitions migrating to the sun7i-a20.dtsi file.
>
> The Cubieboard DTs enable the display engine (&de) and power
> (&ac_power_supply).
>
> There are some changes to the Ethernet node (&gmac). (I didn't think
> Ethernet
> was exposed by the computer cards when the specification was updated after
> the
> first round of cards being made.)


no it's gone


>
> The Cubieboard DTs enable USB OTG (&usb_otg) whereas the EOMA68-A20 DT has
> a
> node &reg_usb0_vbus that the other DTs do not have.
>
> So, it seems possible that an updated DT file would be a minor variation
> on
> the Cubieboard 2 file.


pretty much.


>
> > > Were the differences documented and are there any
> > > schematics to provide any necessary insight when updating the device
> tree?
> >
> > there's PDFs somewhere... http://hands.com/~lkcl/eoma/
> > such as this: http://hands.com/~lkcl/eoma/DS113-V2.7-2017-02-17.pdf
>
> And, as usual, when I go to download it, I find that I already have it
> alongside a schematic for the Cubietruck!


:)


>
> > the thing is that it is critically important that the dts file *do
> > not* include the peripherals associated with the "Boards"
> > (Micro-Desktop, 15in laptop).  the peripheral sets *MUST* go into a
> > "dynamic include" file that is detected at boot time and "inserted"
> > into the live device-tree.
>
> Indeed. I guess the computer card device tree sits at a level between the
> chipset device tree and what would normally be the machine device tree.


if i understand you correctly: not quite.

the closest equivalent  is 96boards and arduino shield dtbs.

here the 96boards dtb file *is* the machine level.

the pin header dtb locations however are NOT FILLED IN.

they instead have special references - pointers. each pointer is named
(given the pin number) but is set to NULL by default.

at RUNTIME - not "device tree compile time" - at **RUNTIME** - a special
command is run with a "shield dtb fragment" that directly and DYNAMICALLY
replaces those named parameter pointers with the reference to the dtb
fragment.



> > this functionality - dynamic runtime "insertion" of device-tree
> > fragments - was an idea *in development* back in.... 2013  we have had
> > to wait several years for this functionality to make its way into both
> > u-boot and the linux kernel.
>
> I guess I should ask whether such support made it into either of them.


investigating 96boards and how their shields are supported should give some
leads, there.

the absolute last thing needed however is hardcoded static compiled dtb,
one for eoma68-a20-microdesktop, one for laptop, then one for
eoma68-rk3288-microdesktop

it would be utterly disastrous for EOMA68 to consider the base dtb file to
be a "chipset" level tree.

it has to be a *board* level (machine level) tree because of the standalone
nature of EOMA68 Cards.

however all 68 pins are "shield" pins, *not* "machine" pins, and need to be
dynamically connected just like for 96boards shields.

l.



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

From paul at boddie.org.uk  Sun Jul 19 23:56:19 2020
From: paul at boddie.org.uk (Paul Boddie)
Date: Mon, 20 Jul 2020 00:56:19 +0200
Subject: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
In-Reply-To: <CAPweEDx3PCqRTP2AJ6ub-obshFBr4UvhQbTdegn91XgSfnkS_w@mail.gmail.com>
References: <20200616084447.zq25ovnqbfotyb5h@pabbook>
	<1825604.k1WfSWoTxO@jason>
	<CAPweEDx3PCqRTP2AJ6ub-obshFBr4UvhQbTdegn91XgSfnkS_w@mail.gmail.com>
Message-ID: <3195004.8AKI5GIMNm@jason>

On Monday, 20 July 2020 00:20:58 CEST Luke Kenneth Casson Leighton wrote:
> On Sunday, July 19, 2020, Paul Boddie <paul at boddie.org.uk> wrote:
> > 
> > The principal differences appear to be as follows:
> > 
> > The EOMA68-A20 DT doesn't have HDMI nodes whereas the Cubieboard DTs have
> > nodes for HDMI connectors and the usual peripheral nodes (&hdmi,
> > &hdmi_out).
> > Given the effort that went into putting micro-HDMI on the computer card, I
> > guess there might be some definitions to add here.
> 
> yes.

OK, I'll add them.

> > The EOMA68-A20 DT has a special pinctrl node for mmc3_cd_pin (MMC3 card
> > detect, I guess). There are also LED pin differences, but I think these
> > are explained by pin definitions migrating to the sun7i-a20.dtsi file.
> 
> ah.  the updates to the hardware it is now mmc0

OK.

> > Some I2C definitions seem to be different in the Cubieboard DTs, but that
> > could also be due to pin definitions migrating to the sun7i-a20.dtsi file.
> > 
> > The Cubieboard DTs enable the display engine (&de) and power
> > (&ac_power_supply).
> > 
> > There are some changes to the Ethernet node (&gmac). (I didn't think
> > Ethernet was exposed by the computer cards when the specification was
> > updated after the first round of cards being made.)
> 
> no it's gone

OK.

> > The Cubieboard DTs enable USB OTG (&usb_otg) whereas the EOMA68-A20 DT has
> > a node &reg_usb0_vbus that the other DTs do not have.
> > 
> > So, it seems possible that an updated DT file would be a minor variation
> > on the Cubieboard 2 file.
> 
> pretty much.

I'll have to look at the OTG thing to figure out its significance.

[...]

> > Indeed. I guess the computer card device tree sits at a level between the
> > chipset device tree and what would normally be the machine device tree.
> 
> if i understand you correctly: not quite.
> 
> the closest equivalent  is 96boards and arduino shield dtbs.
> 
> here the 96boards dtb file *is* the machine level.
> 
> the pin header dtb locations however are NOT FILLED IN.
> 
> they instead have special references - pointers. each pointer is named
> (given the pin number) but is set to NULL by default.
> 
> at RUNTIME - not "device tree compile time" - at **RUNTIME** - a special
> command is run with a "shield dtb fragment" that directly and DYNAMICALLY
> replaces those named parameter pointers with the reference to the dtb
> fragment.

I understood the run-time aspect, but I thought that the specialisation would 
be a bit like the way something like the Cubieboard DT specialises the A20 DT.

So, there would be the A20 DT itself, the EOMA68-A20 DT which exposes or 
enables various peripherals, and then - at run-time - each housing's DT which 
activates the peripherals that were exposed but not enabled.

I guess the challenge is to describe the peripherals in a neutral way in the 
housing's DT so as not to taint them with the specifics of a particular 
computer card DT.

For example, how would a VGA output port be defined? Normally, there would be 
a connector node with an endpoint, so something like this in the housing DT, 
perhaps:

vga0: connector at 0 {
        compatible = "vga-connector";
        label = "vga";

        port {
                vga_connector_in: endpoint {
                        remote-endpoint = <&vga_out>;
                };
        };
};

And I guess there could be a corresponding endpoint in the computer card DT 
that makes VGA output a possibility. There might also have to be some kind of 
ddc-i2c-bus attribute referencing a node elsewhere, too.

Sorry if this was discussed on the list or documented elsewhere!

[...]

> > I guess I should ask whether such support made it into either of them.
> 
> investigating 96boards and how their shields are supported should give some
> leads, there.

This was the first thing I found:

https://www.96boards.org/documentation/consumer/dragonboard/dragonboard410c/
guides/dt-overlays.md.html

But there is also this:

https://www.kernel.org/doc/html/latest/devicetree/overlay-notes.html

Oddly, the syntax in the above is far simpler than various other guides to 
overlays, making me wonder whether they are describing different kinds of 
overlays. For example (see part 2):

https://www.raspberrypi.org/documentation/configuration/device-tree.md

> the absolute last thing needed however is hardcoded static compiled dtb,
> one for eoma68-a20-microdesktop, one for laptop, then one for
> eoma68-rk3288-microdesktop
> 
> it would be utterly disastrous for EOMA68 to consider the base dtb file to
> be a "chipset" level tree.
> 
> it has to be a *board* level (machine level) tree because of the standalone
> nature of EOMA68 Cards.

Yes, I think everyone understands this now, at least intuitively if not the 
precise mechanism. :-)

> however all 68 pins are "shield" pins, *not* "machine" pins, and need to be
> dynamically connected just like for 96boards shields.

The mechanism, yes.

Paul




From lkcl at lkcl.net  Mon Jul 20 00:38:34 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Mon, 20 Jul 2020 00:38:34 +0100
Subject: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
In-Reply-To: <3195004.8AKI5GIMNm@jason>
References: <20200616084447.zq25ovnqbfotyb5h@pabbook>
	<1825604.k1WfSWoTxO@jason>
	<CAPweEDx3PCqRTP2AJ6ub-obshFBr4UvhQbTdegn91XgSfnkS_w@mail.gmail.com>
	<3195004.8AKI5GIMNm@jason>
Message-ID: <CAPweEDyRc3DnffZMC8GaxWpmi3M_80aMx2KiDwuvvWnq1BBKQA@mail.gmail.com>

On Sunday, July 19, 2020, Paul Boddie <paul at boddie.org.uk> wrote:

>
> > > The Cubieboard DTs enable USB OTG (&usb_otg) whereas the EOMA68-A20 DT
> has
> > > a node &reg_usb0_vbus that the other DTs do not have.
> > >
> > > So, it seems possible that an updated DT file would be a minor
> variation
> > > on the Cubieboard 2 file.
> >
> > pretty much.
>
> I'll have to look at the OTG thing to figure out its significance.


if starting from a recent cubietruck dts, the interface (schematic) is
exactly the same, so cut/paste is perfectly appropriate.

the 2 other USB ports are plain USB2 and go out on EOMA68 pins.


>
> [...]
>
> > > Indeed. I guess the computer card device tree sits at a level between
> the
> > > chipset device tree and what would normally be the machine device tree.
> >
> > if i understand you correctly: not quite.
> >
> > the closest equivalent  is 96boards and arduino shield dtbs.
> >
> > here the 96boards dtb file *is* the machine level.
> >
> > the pin header dtb locations however are NOT FILLED IN.
> >
> > they instead have special references - pointers. each pointer is named
> > (given the pin number) but is set to NULL by default.
> >
> > at RUNTIME - not "device tree compile time" - at **RUNTIME** - a special
> > command is run with a "shield dtb fragment" that directly and DYNAMICALLY
> > replaces those named parameter pointers with the reference to the dtb
> > fragment.
>
> I understood the run-time aspect, but I thought that the specialisation
> would
> be a bit like the way something like the Cubieboard DT specialises the A20
> DT.


ah, yes.


>
> So, there would be the A20 DT itself, the EOMA68-A20 DT which exposes or
> enables various peripherals,


>
so, some peripherals like the otg, mmc0, hdmi and also interestingly the 2
USB ports despite being on the EOMA68 connector, these would all go in the
same level as cubietruck i.e. machine level.



> and then - at run-time - each housing's DT which
> activates the peripherals that were exposed but not enabled.


yes.  the 2nd sdmmc (mmc3 i think), the i2c, uart, spi, rgbttl and eint,
all those would go into "dynamic pointer default NULL" set.



>
> I guess the challenge is to describe the peripherals in a neutral way in
> the
> housing's DT so as not to taint them with the specifics of a particular
> computer card DT.


that's where the "shield" thing comes in.

>
> For example, how would a VGA output port be defined?


that ie precisely what the dynamic thing does: it's specified in the
dynamic fragment.

the dynamic fragment contains the names eoma68-pin1 to 68 and says that
when eoma68-pin33 is connected it shall be given the purpose "RGBTTL HSYNC".



>  Normally, there would be
> a connector node with an endpoint, so something like this in the housing
> DT,
> perhaps:
>
> vga0: connector at 0 {
>         compatible = "vga-connector";
>         label = "vga";
>
>         port {
>                 vga_connector_in: endpoint {
>                         remote-endpoint = <&vga_out>;
>                 };
>         };
> };


this definition would go in the *Housing* dtb fragment.

the vga_out is defined to contain *dynamic*  connections which link HSYNC
to eoma68-pin33 (whatever).

only when the "dynamic merge" kernel syscall is made will the substitutions
occur, *including* the (now new) definition of vga0

events will then fire, the associated rgbttl.ko gets loaded, and
(eventually) /dev/fb0 appears.


> And I guess there could be a corresponding endpoint in the computer card
> DT
> that makes VGA output a possibility.


no: it really does go in the *Housing* dtb fragment.



>  There might also have to be some kind of
> ddc-i2c-bus attribute referencing a node elsewhere, too.


exactly.  and one for mmc3, and one for SPI and uart.  but all in the
*fragment* not the main eoma68 board file.

all with pin definitions that are *only* connected up at runtime.

all of which reference the eoma68 pins.

note:

any developer that connects peripherals via external arduino circuits
(breadboards) is on their own, here, although the process needs documenting.

a user connecting say an SPI Ethernet to the MicroDesktop header would need
to start from the Microdesktop dts fragment, add the spi peripheral to it,
the run the "dynamic dtb load" command.

i *hope* that they implemented "unload dynamic dtb" by now.


>
> Sorry if this was discussed on the list or documented elsewhere!


a long time ago.


>
> [...]
>
> > > I guess I should ask whether such support made it into either of them.
> >
> > investigating 96boards and how their shields are supported should give
> some
> > leads, there.
>
> This was the first thing I found:
>
> https://www.96boards.org/documentation/consumer/
> dragonboard/dragonboard410c/
> guides/dt-overlays.md.html


ta-daaa that's it.  overlays.

give me a sec to review the links

l.



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

From lkcl at lkcl.net  Mon Jul 20 00:56:34 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Mon, 20 Jul 2020 00:56:34 +0100
Subject: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
In-Reply-To: <CAPweEDyRc3DnffZMC8GaxWpmi3M_80aMx2KiDwuvvWnq1BBKQA@mail.gmail.com>
References: <20200616084447.zq25ovnqbfotyb5h@pabbook>
	<1825604.k1WfSWoTxO@jason>
	<CAPweEDx3PCqRTP2AJ6ub-obshFBr4UvhQbTdegn91XgSfnkS_w@mail.gmail.com>
	<3195004.8AKI5GIMNm@jason>
	<CAPweEDyRc3DnffZMC8GaxWpmi3M_80aMx2KiDwuvvWnq1BBKQA@mail.gmail.com>
Message-ID: <CAPweEDyBR6mH8KQbd5u3UiOkKTEGDuSa6jxB9UUNAqPDDqeCcA@mail.gmail.com>

On Monday, July 20, 2020, Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

>
>
>
> i *hope* that they implemented "unload dynamic dtb" by now.
>

 Finally, if you need to remove all overlays in one-go, just call
of_overlay_remove_all() which will remove every single one in the correct
order.

it got implemented, thank goodness.

that means (hypothetically) that Cards can be powered from OTG, *unplugged
live*, put into a *new housing* and not require a reboot.

ultimately some Cards might actually have small internal batteries or
supercapacitors to keep running for long enough to transfer without
external power.

cat tsys01.dtbo > /sys/kernel/config/device-tree/overlays/tsys01/dtbo

that looks pretty straightforward.

the rest is probably because the dragonboard was quite early, and now the
docs are out of date


the rbpi doc looks pretty garbled.  phandles.  *that* was the name of the
pointer thing i mentioned.


it doesn't help the person writing that document that the rbpi foundation
actually changed the pinouts between versions of hardware, and of course
everyone expects the old overlays to "just work".

this kind of hell is precisely why eoma68 will not be "upgraded".  or if it
is, it'll be "faster sdmmc" or "faster usb3" both of which do dynamic
hardware-level runtime negotiation that has nothing to do with pinouts
themselves.

i.e. there will *never* be "abandonment" of pinout definitions.  a pin
defined now as i2c-clk *will remain defined as such*, forever.


one minor complication with eoma68 is that all pins (except usb) are
dual-purpose (GPIO) multiplexed however given that this is standard fare
for shield headers i do not anticipate problems in the overlay fragment
definitions.

l.



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

From sokolgeo at posteo.net  Mon Jul 20 07:57:01 2020
From: sokolgeo at posteo.net (George Sokolsky)
Date: Mon, 20 Jul 2020 08:57:01 +0200
Subject: [Arm-netbook] Current status
In-Reply-To: <mailman.1.1595197284.6429.arm-netbook@lists.phcomp.co.uk>
References: <mailman.1.1595197284.6429.arm-netbook@lists.phcomp.co.uk>
Message-ID: <3F4D6D72-F0A1-4BC2-9838-573C6B29CDE5@posteo.net>

Hi,

sorry to interrupt - does that look like we're not getting our EOMAs this year again, if ever? How people are moving forward with their computing needs? What's the 'next best thing' to invest here? 

George

From lkcl at lkcl.net  Mon Jul 20 11:33:51 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Mon, 20 Jul 2020 11:33:51 +0100
Subject: [Arm-netbook] Current status
In-Reply-To: <3F4D6D72-F0A1-4BC2-9838-573C6B29CDE5@posteo.net>
References: <mailman.1.1595197284.6429.arm-netbook@lists.phcomp.co.uk>
	<3F4D6D72-F0A1-4BC2-9838-573C6B29CDE5@posteo.net>
Message-ID: <CAPweEDy+_0QtUk8ievdp_s-hrnLBfa0iCCrEtLf4J3fgmjxFLA@mail.gmail.com>

On Monday, July 20, 2020, George Sokolsky <sokolgeo at posteo.net> wrote:

> Hi,
>
> sorry to interrupt


no feel free, george, this list is an open one.


>  - does that look like we're not getting our EOMAs this year again, if
> ever?


it happens when it happens.  i would love to have not encountered so many
technical issues.


>  How people are moving forward with their computing needs? What's the
> 'next best thing' to invest here?


really good questions.

l.



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

From paul at boddie.org.uk  Mon Jul 20 19:05:05 2020
From: paul at boddie.org.uk (Paul Boddie)
Date: Mon, 20 Jul 2020 20:05:05 +0200
Subject: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
In-Reply-To: <CAPweEDyRc3DnffZMC8GaxWpmi3M_80aMx2KiDwuvvWnq1BBKQA@mail.gmail.com>
References: <20200616084447.zq25ovnqbfotyb5h@pabbook>
	<3195004.8AKI5GIMNm@jason>
	<CAPweEDyRc3DnffZMC8GaxWpmi3M_80aMx2KiDwuvvWnq1BBKQA@mail.gmail.com>
Message-ID: <6937918.eijiAQAnco@jason>

On Monday, 20 July 2020 01:38:34 CEST Luke Kenneth Casson Leighton wrote:
> On Sunday, July 19, 2020, Paul Boddie <paul at boddie.org.uk> wrote:
> > 
> > So, there would be the A20 DT itself, the EOMA68-A20 DT which exposes or
> > enables various peripherals,
> 
> so, some peripherals like the otg, mmc0, hdmi and also interestingly the 2
> USB ports despite being on the EOMA68 connector, these would all go in the
> same level as cubietruck i.e. machine level.

Right.

> > and then - at run-time - each housing's DT which
> > activates the peripherals that were exposed but not enabled.
> 
> yes.  the 2nd sdmmc (mmc3 i think), the i2c, uart, spi, rgbttl and eint,
> all those would go into "dynamic pointer default NULL" set.

Yes, and I guess that the rgbttl peripheral would be the thing providing the 
VGA output, so there would potentially be something there with a device tree 
"port" that can connect to a corresponding port in the housing's DT...

[...]

> > For example, how would a VGA output port be defined?
> 
> that ie precisely what the dynamic thing does: it's specified in the
> dynamic fragment.
> 
> the dynamic fragment contains the names eoma68-pin1 to 68 and says that
> when eoma68-pin33 is connected it shall be given the purpose "RGBTTL HSYNC".

How does this correspond to the pinctrl groups that one usually sees? In the 
sun7i-a20.dtsi file there is a pinctrl node with lots of groups defined.

Would there be some kind of "logical" pin group like this...?

&pio {
	eoma68_lcd_pins: eoma68-lcd-pins {
		/* assuming that LCD0 pins are routed via the connector's LCD pins */
		pins = "PD0", "PD1", ... ;
		function = "eoma68-lcd";
	};
};

(Here, I used the sun7i-a20-olinuxino-micro.dts file to provide some hints. In 
the Ingenic DT files, by the way, you don't see so much of this any more 
because the groups are actually defined in the driver itself.)

And then, there would be something using this pin group. Here, I have to guess 
which phandle to use amongst other things. Since tcon0 is an A20 thing, this 
would be in the computer card DT, with other card DTs providing their own 
necessary recipes:

&tcon0 {
	ports {
   		tcon0_lcd_out: port at 2 {
			...
			tcon0_out_lcd: endpoint at 2 {
				...
				remote-endpoint = <&vga_connector_in>;
			};
		};
	};
};

Here, I'm missing the mechanism by which the pin group gets selected. Some 
kind of coordination with the driver would be needed, I guess. Otherwise, it 
wouldn't know which mode to use so as to produce output on the LCD0 pins.

> > Normally, there would be a connector node with an endpoint, so something
> > like this in the housing DT, perhaps:
> > 
> > vga0: connector at 0 {
> > 
> >         compatible = "vga-connector";
> >         label = "vga";
> >         
> >         port {
> >         
> >                 vga_connector_in: endpoint {
> >                 
> >                         remote-endpoint = <&vga_out>;
> >                 
> >                 };
> >         
> >         };
> > 
> > };
> 
> this definition would go in the *Housing* dtb fragment.

Yes, in the housing DT.

> the vga_out is defined to contain *dynamic*  connections which link HSYNC
> to eoma68-pin33 (whatever).
> 
> only when the "dynamic merge" kernel syscall is made will the substitutions
> occur, *including* the (now new) definition of vga0 events will then fire,
> the associated rgbttl.ko gets loaded, and (eventually) /dev/fb0 appears.

Yes, I'm just missing some idea of the actual device tree plumbing. But then I 
don't think I'm particularly good at figuring out Linux device drivers and 
device trees.

Paul




From lkcl at lkcl.net  Mon Jul 20 23:49:48 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Mon, 20 Jul 2020 23:49:48 +0100
Subject: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
In-Reply-To: <6937918.eijiAQAnco@jason>
References: <20200616084447.zq25ovnqbfotyb5h@pabbook>
	<3195004.8AKI5GIMNm@jason>
	<CAPweEDyRc3DnffZMC8GaxWpmi3M_80aMx2KiDwuvvWnq1BBKQA@mail.gmail.com>
	<6937918.eijiAQAnco@jason>
Message-ID: <CAPweEDxf0WtMWh1Q0fGwg+hMrWBK1Vso2-Dy7PADuD4qUSQ40Q@mail.gmail.com>

On Monday, July 20, 2020, Paul Boddie <paul at boddie.org.uk> wrote:

>
> Yes, and I guess that the rgbttl peripheral would be the thing providing
> the
> VGA output, so there would potentially be something there with a device
> tree
> "port" that can connect to a corresponding port in the housing's DT...


if we follow the idea put forward  by the rbpi "hat" community, actually
"VGA peripheral" or "SPI Ethernet peripheral" would be yet further separatw
dtb fragments (overlays) that get dropped on top of a "Housing" overlay.

even the EOMA68 SDMMC interface could potentially have a "hat" file for a
SD WIFI Card or other type of non-dynamically-detectable peripheral.

it gets complicated, pretty quickly, but this is kinda unavoidable.

part of my responsibility as the Cerification Mark holder is to maintain
that database of overlay fragments and ensure that it is properly compliant
and well documented.



> [...]
>
> > > For example, how would a VGA output port be defined?
> >
> > that ie precisely what the dynamic thing does: it's specified in the
> > dynamic fragment.
> >
> > the dynamic fragment contains the names eoma68-pin1 to 68 and says that
> > when eoma68-pin33 is connected it shall be given the purpose "RGBTTL
> HSYNC".
>
> How does this correspond to the pinctrl groups that one usually sees? In
> the
> sun7i-a20.dtsi file there is a pinctrl node with lots of groups defined.


the overlays *use* those pinctrl groups and basically limit them to a hard
subset of functionality.

 so for example, one set of pins routed to EOMA68 I2C *might* also be
capable of supporting UART by a happy coincidence.

however despite this being possible it is NOT permitted to advertise that
fact... and also claim EOMA68 Compliance.

to protect users who expect interoperability now and in 20 years time i
have to drop a ton of bricks on anyone trying to say "oh yes, EOMA68
devices can do UART on the I2C pins" for example.



Would there be some kind of "logical" pin group like this...?
>
> &pio {
>         eoma68_lcd_pins: eoma68-lcd-pins {
>                 /* assuming that LCD0 pins are routed via the connector's
> LCD pins */
>                 pins = "PD0", "PD1", ... ;
>                 function = "eoma68-lcd";
>         };
> };


i would prefer a level of indirection that names the EOMA68 pins by
numbers, these numbers to be nothing to do with the function

the reason being that exactly like pinctrl all EOMA68 Interface pins
(except USB) can be GPIO.

then, just like pinctrl, the next layer drops overlays onto those 68 pins
to provide LCD ... *if the Housing  Manufacturer wants them to be LCD*.

if the Housing Manufacturer wants 15 pin RGBTTL not 24 pin RGBTTL that
frees up quite a few pins in the EOMA68 RGBTTL bank for use as GPIO.

likewise SDMMC can operate in 1 pin mode, freeing up 3 other pins for GPIO.

these examples shows that it is therefore quite important to not drop
functions directly onto pins but to have that "redirection" layer:

&pio {
        eoma68_pin0:  {
                pins = "PD0"
                function = "eoma68-pin0";
        };
        eoma68_pin1:  {
                pins = "PE5"
                function = "eoma68-pin1";
        };
        .....
        .....
};

and *then* have an LCD dtb overlay (one 24, one 18, one 16 and one 15)
which refers to the pins by their *EOMA68* name

NOT the pinctrl name (e.g. from sunxi a20 dts) which is SoC specific.


>
> Here, I'm missing the mechanism by which the pin group gets selected.


the abstraction / indirection, explicitly naming the pins with EOMA68 pin
names, i believe answers this.

Cards dtb files *provide* those 68 pins as named in the dtb file

Housing overlays *use* those 68 names.

Engineers using rbpi style Housings (such as the Microdesktop with its 20
pin header) drop "hat" overlays onto functions such as eoma68_spi or
eoma68_i2c and so on.


Some
> kind of coordination with the driver would be needed, I guess. Otherwise,
> it
> wouldn't know which mode to use so as to produce output on the LCD0 pins.


correct.  this is what the I2C EEPROM is for.

it is the responsibility of uboot and the linux kernel to:

* read the EEPROM
* determine the Housing type
* load the correct dtb overlay

at that point the Card can automatically recognise the Housing, drivers
load from there and users are happy. "Plug it in, it will just work" is
satisfied.

of course, this means they need to regularly keep the dtb overlay database
updated...

 .

>
> Yes, I'm just missing some idea of the actual device tree plumbing. But
> then I
> don't think I'm particularly good at figuring out Linux device drivers and
> device trees


it's all there.  the pieces are in place.  reading the I2C EEPROM however
does need to be written.

alan cox suggested this be added to lib/eoma68 in the linux kernel source
tree.

l.


>
> Paul
>
>
>

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

From doark at mail.com  Tue Jul 21 02:02:14 2020
From: doark at mail.com (David Niklas)
Date: Mon, 20 Jul 2020 21:02:14 -0400
Subject: [Arm-netbook] Current status
In-Reply-To: <CAPweEDy+_0QtUk8ievdp_s-hrnLBfa0iCCrEtLf4J3fgmjxFLA@mail.gmail.com>
References: <mailman.1.1595197284.6429.arm-netbook@lists.phcomp.co.uk>
	<3F4D6D72-F0A1-4BC2-9838-573C6B29CDE5@posteo.net>
	<CAPweEDy+_0QtUk8ievdp_s-hrnLBfa0iCCrEtLf4J3fgmjxFLA@mail.gmail.com>
Message-ID: <20200720210214.79d4c075@Phenom-II-x6.niklas.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Monday, July 20, 2020, George Sokolsky <sokolgeo at posteo.net> wrote:
>  How people are moving forward with their computing needs?

I'm not receiving an EOMA68, rather I'm building my own laptop from a
firefly RK3399 SBC. It's more powerful then the EOMA68, but it's lack of
FLOSS SW support is problematic. For example, the firmware flashing
didn't flash firmware and did mess up my kernel enough to require a
reboot. Grrr!
I'm working on and off on the SW and HW.

The RK3399 is a real winner of a processor, being sold on a lot of SBCs
for as little as $50. It's getting better and better SW support as devs
reverse engineer it's internal mali GPU and associated interconnect and
power controls.
AMDs laptop offerings are also very temping and I'm recommending them to
normal people who want to purchase a laptop. Linux support is in great
shape for the 4000 series AFAIK[1]. Supposedly, AMD is coming out with an
APU even more amazing before the end of the year.

Again, personally, I'll bang my head against this SBC until it does what
I want! No PSP[2] for me!

>  What's the 'next best thing' to invest here?  

Off the top of my head since the inception of the EOMA68...

Correct me mercilessly if I'm wrong, luke.
@ @
 V

The RISC-V folks are being unkind to luke and other devs (they
will not let them participate), so that's out of the question.
The Epiphany processor was looking like it's silicon form would really be
a powerful CPU, but then the guys in charge said that there were not
enough people who wanted one to manufacture them on silicon.
MIPS was looking promising until you read it's "open source" license.
Currently, the folks of the POWER arch are releasing version 9 as
open-source (still hacking out the terms AFAIK).

So, if you're looking for Linux kernel rate OSHW releases you're
bound to be disappointed. Otherwise I'd wait for OpenPOWER and invest in
products from that endeavor -- assuming it doesn't go South too.

Other then that, you can look at OSHW crowdsourced projects and continue
to invest your money to what you can use there.

Sincerely,
David




[1]:
https://www.phoronix.com/scan.php?page=news_item&px=Ryzen-7-4700U-Daily-Driver
https://www.phoronix.com/scan.php?page=article&item=141-benchmarks-laptops&num=1

[2]: Platform Security Processor. Less scary then Intel's ME (Management
Engine) but still noteworthy. Talks on all three:
https://youtu.be/bKH5nGLgi08
https://youtu.be/0o8Co1ekemU
https://youtu.be/3CQUNd3oKBM
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEL2N7+xWmVOJDQxWGm3XCrhg2YP8FAl8WPpcACgkQm3XCrhg2
YP9WyQ//SpoG6Zjyy9eyadrDyD5roXld+5Poq9MkLTYcQq12NTNXhUw1+DWyI5rc
ca8xUpTWkVS6OzcX8d/eik+VGT9im+qRRKHEx6T3xDtd4NDiv1Wl/Vi5bttxU1Ps
unyJuX3ukR8EaT6ZLF33/o1CtHbt5hU5oZ+A2bRQO46iwIwL3NIsQ8pAO/y5de+8
+7/wXsWECh7Rqjh9uHitvONqFefsMvIMn1N07r1Zo/yOgYqbRnmpsv04wxhFkj1t
/lhF0p4N7ve/GyRYWpIpdfd8wCX2NFs+nJpgIv6bwNtj5lSmKbDiitcMzKCy+YHe
J6SsrujfovAfE76TZZ8MXhZO5waAx86QNemoWeCKWmDwYDxaml9ySqzRVvaFIQun
PZmJiUtaWEAOI6VwVO7Yw/9cctb0mJ9jjQi9Qrp2pJoCgrm8oAMfPwKQF+QjGjkb
BkcLSSw/K1/n9CNpGI0QbVG4474vCpmNRi4d82x7xvRJ0TbZ2cdviuO4zngkEj4K
dcthC0Q9Ayhj8yAM9If9v6krjhnaFB86Wj0UKFikiVfiX+hha1oYBEzt9eGjgr92
YkjzxCn9m0Opz/C9HieA84u8mao6mZaE4GhRnhdFxTzMXojPgmsMmPtsJ5jy13sq
wZcYQ5aYu/Gvhscfh2tmLoHfjI8rTA0swNuZmf/zPjQ0qs0X/Y0=
=Ur0+
-----END PGP SIGNATURE-----

From laserhawk64 at gmail.com  Tue Jul 21 02:25:41 2020
From: laserhawk64 at gmail.com (Christopher Havel)
Date: Mon, 20 Jul 2020 21:25:41 -0400
Subject: [Arm-netbook] Current status
In-Reply-To: <3F4D6D72-F0A1-4BC2-9838-573C6B29CDE5@posteo.net>
References: <mailman.1.1595197284.6429.arm-netbook@lists.phcomp.co.uk>
	<3F4D6D72-F0A1-4BC2-9838-573C6B29CDE5@posteo.net>
Message-ID: <CA+kEFNJU88sCGzZncWcM8m2ttbXz8mWYvb_8h5Y_ei_0c99bMQ@mail.gmail.com>

On Mon, Jul 20, 2020, 2:57 AM George Sokolsky <sokolgeo at posteo.net> wrote:

> How people are moving forward with their computing needs? What's the 'next
> best thing' to invest here?


I've long since held that the universal computer is the one you build
yourself. It's far simpler and easier than the average person is willing to
admit to themselves, and it has a wide range of benefits, from
customization and the options for it, through to financial benefits.

For perspective... I have Asperger's, just strong enough so to keep me on
the unemployment line. I'm weird enough, just baseline naturally, to creep
out any prospective employers for positions where I might actually be of
use. My Disability "check" (as we call it here in the USA -- those in
Europe would likely consider it a form of pension, but here that's really
something only for retired people) is 1095 USD a month.

I don't moonlight, so that 1095 USD has to cover *everything* -- rent,
electricity, water/sewer, Internet service, mobile/cell phone service,
food, medication, and (since I don't drive) public transportation... and
I'm able to set aside 100-150 USD after that, roughly, for "disposable
income", which covers the fun stuff -- computer tinkering, art supplies,
decorations, etc.

I'm building my seventh computer in the cyberdeck form factor that I've
come to love... and I'm planning out #8, slowly, as I do so.

#7 aka "SPACE CAADET" (after the famous MIT Lisp Machine -- or would that
be "MIT Lithp Maschthine", the way Sylvester Cat would say it on Looney
Tunes? -- keyboard), yes I named it, I always do that, I'm silly ;) and I'm
not shouting, it's a (b)ac(k)ronym... it's going to be my first to run off
battery power (unfortunately, it can't run and charge at the same time) and
my first with a Celeron N4000 SoC -- prior to this, everything I've used
pretty well topped out at an Atom x5-8300.

Follow along here, if you'd like (warning to those still on
limited/90s-kind-of-slow connections -- it's *extremely* picture heavy!) --
https://hackaday.io/project/173780-space-caadet

I intend, if I can ever get myself together enough,  to someday put
together a book, which I'll also have done up as a series of online videos
if I can, that teaches people how to make their own.

That's my answer :)

From lkcl at lkcl.net  Tue Jul 21 04:31:43 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Tue, 21 Jul 2020 04:31:43 +0100
Subject: [Arm-netbook] Current status
In-Reply-To: <20200720210214.79d4c075@Phenom-II-x6.niklas.com>
References: <mailman.1.1595197284.6429.arm-netbook@lists.phcomp.co.uk>
	<3F4D6D72-F0A1-4BC2-9838-573C6B29CDE5@posteo.net>
	<CAPweEDy+_0QtUk8ievdp_s-hrnLBfa0iCCrEtLf4J3fgmjxFLA@mail.gmail.com>
	<20200720210214.79d4c075@Phenom-II-x6.niklas.com>
Message-ID: <CAPweEDx0-Hdq0jouskOVGiDRCnC03azLc2CJRvzvKEzfRQJdMA@mail.gmail.com>

On Tuesday, July 21, 2020, David Niklas <doark at mail.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Monday, July 20, 2020, George Sokolsky <sokolgeo at posteo.net> wrote:
> >  How people are moving forward with their computing needs?
>
> I'm not receiving an EOMA68, rather I'm building my own laptop from a
> firefly RK3399 SBC. It's more powerful then the EOMA68,


correction: EOMA68 is a protocol standard.  an SBC cannot be compared to a
standard.

you must mean "an EOMA68-A20 computer card".

if in the future an EOMA68-RK3399 existed, it would compare directly with
and have exactly the same speed, capactity and performance as the RK3399
Firefly.


> but its lack of
> FLOSS SW support is problematic. For example, the firmware flashing
> didn't flash firmware and did mess up my kernel enough to require a
> reboot. Grrr!
> I'm working on and off on the SW and HW.
>
> The RK3399 is a real winner of a processor, being sold on a lot of SBCs
> for as little as $50. It's getting better and better SW support as devs
> reverse engineer its internal mali GPU and associated interconnect and
> power controls.


this is one thing that really concerns me.  the RK3399 came out nearly 3
years ago yet you're saying that *only now* is support for it trickling
through to mainstream? what gives?

AMDs laptop offerings are also very temping and I'm recommending them to
> normal people who want to purchase a laptop. Linux support is in great
> shape for the 4000 series AFAIK[1]. Supposedly, AMD is coming out with an
> APU even more amazing before the end of the year.


they're just doing so much better than intel.  you saw the news about Apple
reporting more QA issues in Skylake during its development than Intel
engineers?



>
> Again, personally, I'll bang my head against this SBC until it does what
> I want! No PSP[2] for me!
>
> >  What's the 'next best thing' to invest here?
>
> Off the top of my head since the inception of the EOMA68...
>
> Correct me mercilessly if I'm wrong, luke.
> @ @
>  V


:)


>
> The RISC-V folks are being unkind to luke and other devs


anyone who will not join the Foundation, basically, is unwelcome.

 (they
> will not let them participate),


oh you can use the Standards: you just can't participate in their
enhancement without joining rge Foundation.

which sounds reasonable until you read the fine print and find that there
are secrecy clauses that are completely incompatible with transparency and
openness requirements of, for example, the Charitable Foundation that is
funding my work on Libre-SOC.


>
> so that's out of the question.
> The Epiphany processor was looking like its silicon form would really be
> a powerful CPU, but then the guys in charge said that there were not
> enough people who wanted one to manufacture them on silicon.


sigh, bless them, they didn't properly "read" their customers' needs.  my
brother understande this extremely well.  it's not the product itself that
sells itself, it's whether the team can explain to the potential customers
that they can be trusted to help them fulfil their needs.



> MIPS was looking promising until you read it's "open source" license.


 i did try contacting them.  the open website was closed for business.  oops

Currently, the folks of the POWER arch are releasing version 9 as
> open-source (still hacking out the terms AFAIK).


that's done.

long story, here.  a group has been working for a LONG time (like 10 years)
to create the OpenPOWER Foundation.  right in rhe middle of that, RISCV
started up :)

the EULA was out in... january i think.  i got "helloworld" running a
couple of weeks ago in simulation, in the Libre-SOC core.

if you want to know more then do join one if rhe virtual coffee calls

https://openpowerfoundation.org/openpower-virtual-coffee-calls/


> So, if you're looking for Linux kernel rate OSHW releases you're
> bound to be disappointed. Otherwise I'd wait for OpenPOWER and invest in
> products from that endeavor -- assuming it doesn't go South too.


it won't.   IBM is not going away.

l.



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

From doark at mail.com  Tue Jul 21 20:28:46 2020
From: doark at mail.com (David Niklas)
Date: Tue, 21 Jul 2020 15:28:46 -0400
Subject: [Arm-netbook] Current status
In-Reply-To: <CAPweEDx0-Hdq0jouskOVGiDRCnC03azLc2CJRvzvKEzfRQJdMA@mail.gmail.com>
References: <mailman.1.1595197284.6429.arm-netbook@lists.phcomp.co.uk>
	<3F4D6D72-F0A1-4BC2-9838-573C6B29CDE5@posteo.net>
	<CAPweEDy+_0QtUk8ievdp_s-hrnLBfa0iCCrEtLf4J3fgmjxFLA@mail.gmail.com>
	<20200720210214.79d4c075@Phenom-II-x6.niklas.com>
	<CAPweEDx0-Hdq0jouskOVGiDRCnC03azLc2CJRvzvKEzfRQJdMA@mail.gmail.com>
Message-ID: <20200721152846.410d57d4@Phenom-II-x6.niklas.com>

On Tue, 21 Jul 2020 04:31:43 +0100
Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote:
> On Tuesday, July 21, 2020, David Niklas <doark at mail.com> wrote:
> > On Monday, July 20, 2020, George Sokolsky <sokolgeo at posteo.net>
> > wrote:  
> > >  How people are moving forward with their computing needs?  
> >
> > I'm not receiving an EOMA68, rather I'm building my own laptop from a
> > firefly RK3399 SBC. It's more powerful then the EOMA68,  
> 
> 
> correction: EOMA68 is a protocol standard.  an SBC cannot be compared
> to a standard.
> 
> you must mean "an EOMA68-A20 computer card".

Yes. My bad.

> if in the future an EOMA68-RK3399 existed, it would compare directly
> with and have exactly the same speed, capactity and performance as the
> RK3399 Firefly.
> 
> 
> > but its lack of
> > FLOSS SW support is problematic. For example, the firmware flashing
> > didn't flash firmware and did mess up my kernel enough to require a
> > reboot. Grrr!
> > I'm working on and off on the SW and HW.
> >
> > The RK3399 is a real winner of a processor, being sold on a lot of
> > SBCs for as little as $50. It's getting better and better SW support
> > as devs reverse engineer its internal mali GPU and associated
> > interconnect and power controls.  
> 
> 
> this is one thing that really concerns me.  the RK3399 came out nearly 3
> years ago yet you're saying that *only now* is support for it trickling
> through to mainstream? what gives?

You're the one to tell us how open-HW is best and you're asking what
gives? Surely, this is just another example of how much better FLOSS
is!

> AMDs laptop offerings are also very temping and I'm recommending them to
> > normal people who want to purchase a laptop. Linux support is in great
> > shape for the 4000 series AFAIK[1]. Supposedly, AMD is coming out
> > with an APU even more amazing before the end of the year.  
> 
> they're just doing so much better than intel.  you saw the news about
> Apple reporting more QA issues in Skylake during its development than
> Intel engineers?
> 

Yes, but forgot to save the article.

"Acer Swift 3 Narrow Bezel Laptop, 14" IPS Full HD, Ryzen 7 4700U 8-Core
up to 4.10 GHz (beats i7-1065G7), 8GB RAM, 256GB SSD, USB-C/DP, Wi-Fi 6,
FP Reader, Backlit, Mytrix Ethernet USB Hub, Win 10"
               ^^^^^^^^^^^^^^^^^
It's such a bad PR situation that sellers are literally spelling it
out in their advertisements.

> > so that's out of the question.
> > The Epiphany processor was looking like its silicon form would really
> > be a powerful CPU, but then the guys in charge said that there were
> > not enough people who wanted one to manufacture them on silicon.  
> 
> 
> sigh, bless them, they didn't properly "read" their customers' needs.
> my brother understande this extremely well.  it's not the product
> itself that sells itself, it's whether the team can explain to the
> potential customers that they can be trusted to help them fulfil their
> needs.
> 

If you have a link or more to say, please continue. I thought it was a
wonderful project but wanted to wait until they did the silicon vs. the
Xylinx FPGA CPU.
My choice, no doubt also the same as others, made the initial project
appear less successful then it really was.

> > MIPS was looking promising until you read it's "open source"
> > license.  
> 
> 
>  i did try contacting them.  the open website was closed for business.
> oops

lol

> Currently, the folks of the POWER arch are releasing version 9 as
> > open-source (still hacking out the terms AFAIK).  
> 
> 
> that's done.
> 
> long story, here.  a group has been working for a LONG time (like 10
> years) to create the OpenPOWER Foundation.  right in rhe middle of
> that, RISCV started up :)
> 
> the EULA was out in... january i think.  i got "helloworld" running a
> couple of weeks ago in simulation, in the Libre-SOC core.
> 
> if you want to know more then do join one if rhe virtual coffee calls
> 
> https://openpowerfoundation.org/openpower-virtual-coffee-calls/
 
:cry:
Another Zoom conference. Proprietary executable. Known spying company.
Why luke, why do people always have to choose the worst of proprietary
stuff?

https://nypost.com/2020/04/10/chinese-spies-are-trying-to-snoop-on-zoom-chats-experts-say/
https://medium.com/swlh/zoom-are-you-spying-me-7c07feebf85

We have linphone, ekiga, not to mention the myriad of stuff on shareware
sites ( Here's a good one I know from my windowz days
https://www.freewarefiles.com/ ), if it must be proprietary.
We have IRC, Jabber, Argh! So much good stuff!
Conferencing stuff (not all FLOSS, but still a lot there):
https://www.ubuntupit.com/top-20-best-linux-video-conferencing-software/

> > So, if you're looking for Linux kernel rate OSHW releases you're
> > bound to be disappointed. Otherwise I'd wait for OpenPOWER and invest
> > in products from that endeavor -- assuming it doesn't go South too.  
> 
> 
> it won't.   IBM is not going away.
> 
> l.
> 

All 3 projects I listed as failed/failing have problems that are not
technical. I'd love to be excited, but I'm feeling cautious and pensive.

Thanks for your thoughts, luke,
David

From lkcl at lkcl.net  Tue Jul 21 20:37:15 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Tue, 21 Jul 2020 20:37:15 +0100
Subject: [Arm-netbook] Current status
In-Reply-To: <20200721152846.410d57d4@Phenom-II-x6.niklas.com>
References: <mailman.1.1595197284.6429.arm-netbook@lists.phcomp.co.uk>
	<3F4D6D72-F0A1-4BC2-9838-573C6B29CDE5@posteo.net>
	<CAPweEDy+_0QtUk8ievdp_s-hrnLBfa0iCCrEtLf4J3fgmjxFLA@mail.gmail.com>
	<20200720210214.79d4c075@Phenom-II-x6.niklas.com>
	<CAPweEDx0-Hdq0jouskOVGiDRCnC03azLc2CJRvzvKEzfRQJdMA@mail.gmail.com>
	<20200721152846.410d57d4@Phenom-II-x6.niklas.com>
Message-ID: <CAPweEDx41ktDjgPe7ny_hG_tiovKYePifKDXJZy4TjbaD_YWxw@mail.gmail.com>

On Tue, Jul 21, 2020 at 8:29 PM David Niklas <doark at mail.com> wrote:
> > this is one thing that really concerns me.  the RK3399 came out nearly 3
> > years ago yet you're saying that *only now* is support for it trickling
> > through to mainstream? what gives?
>
> You're the one to tell us how open-HW is best and you're asking what
> gives? Surely, this is just another example of how much better FLOSS
> is!

it's more another example of the shocking waste of talent and
resources of proprietary companies spongeing off of software libre
resources, expecting them to "pick up after them".

the Libre-SOC ASIC is a hard lesson learned from that: i am making
sure that *everything* is in place even before the first silicon is
out the door.


> > if you want to know more then do join one if rhe virtual coffee calls
> >
> > https://openpowerfoundation.org/openpower-virtual-coffee-calls/
>
> :cry:
> Another Zoom conference. Proprietary executable. Known spying company.
> Why luke, why do people always have to choose the worst of proprietary
> stuff?

i'm not going to try to explain that one to them.  it's "open" calls,
there's nothing confidential discussed.  and there do exist telephone
numbers.

sigh.

anyway, they are really wonderful people.  the conversations are
fascinating, and funny, and often bugger-all to do with PowerISA :)

l.


From lkcl at lkcl.net  Tue Jul 21 20:39:23 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Tue, 21 Jul 2020 20:39:23 +0100
Subject: [Arm-netbook] 2.7.5 latest pre-production boards tested and working
Message-ID: <CAPweEDxY1Ur3eCCTqDypficTNAyogH0JpL4o=9Fvav1+kMjm3w@mail.gmail.com>

yes, a few months ago, mike sent me 2 new prototypes, using
"single-panel" PCB from a high-quality manufacturer.  i tested them
just now (yes, long story, very busy with Libre-SOC) and they work
fine.  boot off of the usual micro-sd card i've been using.

l.

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


From doark at mail.com  Tue Jul 21 21:07:40 2020
From: doark at mail.com (David Niklas)
Date: Tue, 21 Jul 2020 16:07:40 -0400
Subject: [Arm-netbook] Current status
In-Reply-To: <CAPweEDx41ktDjgPe7ny_hG_tiovKYePifKDXJZy4TjbaD_YWxw@mail.gmail.com>
References: <mailman.1.1595197284.6429.arm-netbook@lists.phcomp.co.uk>
	<3F4D6D72-F0A1-4BC2-9838-573C6B29CDE5@posteo.net>
	<CAPweEDy+_0QtUk8ievdp_s-hrnLBfa0iCCrEtLf4J3fgmjxFLA@mail.gmail.com>
	<20200720210214.79d4c075@Phenom-II-x6.niklas.com>
	<CAPweEDx0-Hdq0jouskOVGiDRCnC03azLc2CJRvzvKEzfRQJdMA@mail.gmail.com>
	<20200721152846.410d57d4@Phenom-II-x6.niklas.com>
	<CAPweEDx41ktDjgPe7ny_hG_tiovKYePifKDXJZy4TjbaD_YWxw@mail.gmail.com>
Message-ID: <20200721160740.67885761@Phenom-II-x6.niklas.com>

On Tue, 21 Jul 2020 20:37:15 +0100
Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote:
> On Tue, Jul 21, 2020 at 8:29 PM David Niklas <doark at mail.com> wrote:
<snip>
> > > if you want to know more then do join one if rhe virtual coffee
> > > calls
> > >
> > > https://openpowerfoundation.org/openpower-virtual-coffee-calls/
> >
> > :cry:
> > Another Zoom conference. Proprietary executable. Known spying company.
> > Why luke, why do people always have to choose the worst of proprietary
> > stuff?
>
> i'm not going to try to explain that one to them.  it's "open" calls,
> there's nothing confidential discussed.  and there do exist telephone
> numbers.
>
> sigh.
>
> anyway, they are really wonderful people.  the conversations are
> fascinating, and funny, and often bugger-all to do with PowerISA :)
>
> l.
>

Can I use the general email to contact them and try to convince them
myself? Or would you advise I not convince them or talk to someone
particular?

Thanks,
David


From lkcl at lkcl.net  Tue Jul 21 21:13:07 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Tue, 21 Jul 2020 21:13:07 +0100
Subject: [Arm-netbook] Current status
In-Reply-To: <20200721160740.67885761@Phenom-II-x6.niklas.com>
References: <mailman.1.1595197284.6429.arm-netbook@lists.phcomp.co.uk>
	<3F4D6D72-F0A1-4BC2-9838-573C6B29CDE5@posteo.net>
	<CAPweEDy+_0QtUk8ievdp_s-hrnLBfa0iCCrEtLf4J3fgmjxFLA@mail.gmail.com>
	<20200720210214.79d4c075@Phenom-II-x6.niklas.com>
	<CAPweEDx0-Hdq0jouskOVGiDRCnC03azLc2CJRvzvKEzfRQJdMA@mail.gmail.com>
	<20200721152846.410d57d4@Phenom-II-x6.niklas.com>
	<CAPweEDx41ktDjgPe7ny_hG_tiovKYePifKDXJZy4TjbaD_YWxw@mail.gmail.com>
	<20200721160740.67885761@Phenom-II-x6.niklas.com>
Message-ID: <CAPweEDxUdRxfDHrbhOF6sFRTHKPBnUHQ3b+G65ANBTBT6JYVNg@mail.gmail.com>

On Tue, Jul 21, 2020 at 9:08 PM David Niklas <doark at mail.com> wrote:

> Can I use the general email to contact them and try to convince them
> myself? Or would you advise I not convince them or talk to someone
> particular?

well... it's hugh (personally) who is running them.  he's been in the
open source community for... over 25 years?  so he will know the
story.  i'd leave it.  he knows already and will have good reasons.

l.


From paul at boddie.org.uk  Tue Jul 21 21:56:45 2020
From: paul at boddie.org.uk (Paul Boddie)
Date: Tue, 21 Jul 2020 22:56:45 +0200
Subject: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
In-Reply-To: <CAPweEDxf0WtMWh1Q0fGwg+hMrWBK1Vso2-Dy7PADuD4qUSQ40Q@mail.gmail.com>
References: <20200616084447.zq25ovnqbfotyb5h@pabbook>
	<6937918.eijiAQAnco@jason>
	<CAPweEDxf0WtMWh1Q0fGwg+hMrWBK1Vso2-Dy7PADuD4qUSQ40Q@mail.gmail.com>
Message-ID: <2850838.AkLWLTjZdL@jason>

On Tuesday, 21 July 2020 00:49:48 CEST Luke Kenneth Casson Leighton wrote:
> 
> i would prefer a level of indirection that names the EOMA68 pins by
> numbers, these numbers to be nothing to do with the function
> 
> the reason being that exactly like pinctrl all EOMA68 Interface pins
> (except USB) can be GPIO.
> 
> then, just like pinctrl, the next layer drops overlays onto those 68 pins
> to provide LCD ... *if the Housing  Manufacturer wants them to be LCD*.

OK, so the housing DT will contain the following for a VGA port...

An actual connector definition for the benefit of various mechanisms. The 
reason why I keep mentioning this is because the DRM mechanisms seem to depend 
on it: there needs to be some kind of sink for the signal, and it's usually 
some kind of connector. But this is arguably the easy part.

Something that indicates the EOMA pin requirements to supply that connector. 
Normally, pin usage gets written on a specialisation of a device peripheral. 
For example, for the Ben NanoNote:

&lcd {
        pinctrl-names = "default";
        pinctrl-0 = <&pins_lcd>;

        port {
                panel_output: endpoint {
                        remote-endpoint = <&panel_input>;
                };
        };
};

But in the EOMA68 universe, we don't want to override a specific peripheral 
(&lcd here refers to the LCD controller on the JZ4720), nor do we want to 
indicate pins that are SoC-specific.

So, we can define some kind of mapping for pins in the computer card DT, just 
as you do here...

> these examples shows that it is therefore quite important to not drop
> functions directly onto pins but to have that "redirection" layer:
> 
> &pio {
>         eoma68_pin0:  {
>                 pins = "PD0"
>                 function = "eoma68-pin0";
>         };
>         eoma68_pin1:  {
>                 pins = "PE5"
>                 function = "eoma68-pin1";
>         };
>         .....
>         .....
> };
> 
> and *then* have an LCD dtb overlay (one 24, one 18, one 16 and one 15)
> which refers to the pins by their *EOMA68* name
> 
> NOT the pinctrl name (e.g. from sunxi a20 dts) which is SoC specific.

But what I am missing is the construct by which you might apply the pin 
reservations, unless you are merely making aliases for platform-specific pin 
names within pinctrl and then using those in places where pinctrl attributes 
are used.

Specifically, what I wonder about is how the equivalent of the <&pins_lcd> 
gets applied at the SoC level given some kind of (platform-neutral) pin 
reservation in the housing DT.

Sorry if this is obvious, but without concrete DT syntax for the configuration 
throughout the different layers, I cannot see exactly how this would be done.

Paul

P.S. But recent experiences may be colouring my judgement here, having been 
trying to shake the box of existing drivers and DT fragments to try and 
persuade my CI20 to produce HDMI output, so far unsuccessfully. And yet, 
practically the same code produces a picture just fine when ported to L4Re, 
without all the distractions of driver frameworks and device trees (and the 
DRM stack testing modes over and over and over again).




From lkcl at lkcl.net  Tue Jul 21 22:25:12 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Tue, 21 Jul 2020 22:25:12 +0100
Subject: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
In-Reply-To: <2850838.AkLWLTjZdL@jason>
References: <20200616084447.zq25ovnqbfotyb5h@pabbook>
	<6937918.eijiAQAnco@jason>
	<CAPweEDxf0WtMWh1Q0fGwg+hMrWBK1Vso2-Dy7PADuD4qUSQ40Q@mail.gmail.com>
	<2850838.AkLWLTjZdL@jason>
Message-ID: <CAPweEDz2aazHGjUKSR2UMdfdkCA2S1M-pxhZfTEfbaYrNrGn3g@mail.gmail.com>

On Tue, Jul 21, 2020 at 9:57 PM Paul Boddie <paul at boddie.org.uk> wrote:

> OK, so the housing DT will contain the following for a VGA port...

paul: quite late, here, more tomorrow.  summary strategy:

* look at rbpi "hats" and how dtb overlays are done
* copy that
* rename rbpi "hat" overlay pins 0 to M to "eoma68 pins 1 to 68"

in theory that should be pretty much the entire job, bar removing all
multiplexed options other than the 1 specialist function and the GPIO
option.  where in rbpi base "hat" interface there would be up to 4
multiplexed options per pin (one of which will be GPIO), that must be
restricted to "GPIO" and "EOMA68 function", per pin.

that really should be all.

l.


From paul at boddie.org.uk  Tue Jul 21 22:36:28 2020
From: paul at boddie.org.uk (Paul Boddie)
Date: Tue, 21 Jul 2020 23:36:28 +0200
Subject: [Arm-netbook] Current status
In-Reply-To: <20200720210214.79d4c075@Phenom-II-x6.niklas.com>
References: <mailman.1.1595197284.6429.arm-netbook@lists.phcomp.co.uk>
	<CAPweEDy+_0QtUk8ievdp_s-hrnLBfa0iCCrEtLf4J3fgmjxFLA@mail.gmail.com>
	<20200720210214.79d4c075@Phenom-II-x6.niklas.com>
Message-ID: <2034287.2zzArLbcde@jason>

On Tuesday, 21 July 2020 03:02:14 CEST David Niklas wrote:
> On Monday, July 20, 2020, George Sokolsky <sokolgeo at posteo.net> wrote:
> 
> >  How people are moving forward with their computing needs?

[...]

> The RK3399 is a real winner of a processor, being sold on a lot of SBCs
> for as little as $50. It's getting better and better SW support as devs
> reverse engineer it's internal mali GPU and associated interconnect and
> power controls.

These Rockchip SoCs reportedly run pretty hot, don't they? That said, I 
noticed that the Raspberry Pi 4 has fan accessories available for it. So much 
for keeping up the pretense of Cambridge continuity with Acorn Computers 
unless the ultimate aim is to replicate products like the (unreleased) Acorn 
Business Computer with, apparently, a very noisy fan.

> AMDs laptop offerings are also very temping and I'm recommending them to
> normal people who want to purchase a laptop. Linux support is in great
> shape for the 4000 series AFAIK[1]. Supposedly, AMD is coming out with an
> APU even more amazing before the end of the year.

I just upgraded my system (after fifteen years!) to one using a Ryzen 3400G 
APU (if they still call them that). However, Linux kernel compatibility is 
such that I'm running a kernel from the Debian backports repository because 
system reliability with these parts was a long time coming. And you have to 
use proprietary firmware blobs because all these companies need to have their 
secret sauce.

So, upcoming AMD products could be decent, but I would be wary about stability 
for a while after their release. Following the Linux kernel bug tracker can be 
informative:

https://bugzilla.kernel.org/

Searching for "amdgpu" is probably what you want to do. For quite some time, 
people were having problems with the 3200G, and that made me worried about the 
3400G, but it seems that even within product families there might be some 
parts that are better supported than others.

[...]

> MIPS was looking promising until you read it's "open source" license.

Since I've experimented with MIPS things for a while, I have to say that the 
custodianship of MIPS has been generally disappointing.

First of all, Imagination Technologies seemed to want to either compete head-
on with ARM by having a processor architecture and graphics technologies, or 
(when their Apple partnership collapsed) to broaden their offerings and to use 
MIPS as a vehicle into IoT and such. At that time, they had their academic 
programme to try and get people to experiment with the architecture. But RISC-
V was already on the runway at that point, so it was too little too late.

Then, when ImgTec was acquired, MIPS got acquired and quickly passed on to 
Wave Technologies (presumably making some people some quick and easy money). 
But the MIPS business seems to be in maintenance mode, at least if you look at 
their Web assets. And, of course, all the MIPS Creator stuff just fell off the 
desk. Any announcements about opening the architecture might well be perceived 
as just making some noise and keeping existing licensees on board.

Indeed, casually following Microchip over the last couple of years or so, I 
saw it said that Microchip's acquisition of Atmel would mean that Microchip 
would probably double down on ARM and abandon new MIPS product development. 
Various pundits/punters claimed that Microchip wouldn't look twice at RISC-V. 
But then I saw this:

"A low-cost dev kit for Microchip's PolarFire SoC, a low-power FPGA integrated 
with a hardened quad core 64-bit RISC-V microprocessor subsystem"

https://www.crowdsupply.com/microchip/polarfire-soc-icicle-kit

That is from the Microsemi part of Microchip's business, however, meaning that 
it is another recent acquisition: Microchip presumably buying in new 
technology to remain competitive.

Paul




From paul at boddie.org.uk  Tue Jul 21 23:08:18 2020
From: paul at boddie.org.uk (Paul Boddie)
Date: Wed, 22 Jul 2020 00:08:18 +0200
Subject: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
In-Reply-To: <3195004.8AKI5GIMNm@jason>
References: <20200616084447.zq25ovnqbfotyb5h@pabbook>
	<CAPweEDx3PCqRTP2AJ6ub-obshFBr4UvhQbTdegn91XgSfnkS_w@mail.gmail.com>
	<3195004.8AKI5GIMNm@jason>
Message-ID: <5337655.Y5RyGiiSvx@jason>

On Monday, 20 July 2020 00:56:19 CEST Paul Boddie wrote:
> 
> But there is also this:
> 
> https://www.kernel.org/doc/html/latest/devicetree/overlay-notes.html

Which had been removed when I just checked.

> Oddly, the syntax in the above is far simpler than various other guides to
> overlays, making me wonder whether they are describing different kinds of
> overlays. For example (see part 2):
> 
> https://www.raspberrypi.org/documentation/configuration/device-tree.md

This is explained here:

https://source.android.com/devices/architecture/dto/syntax

Paul




From paul at boddie.org.uk  Tue Jul 21 23:53:23 2020
From: paul at boddie.org.uk (Paul Boddie)
Date: Wed, 22 Jul 2020 00:53:23 +0200
Subject: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
In-Reply-To: <CAPweEDz2aazHGjUKSR2UMdfdkCA2S1M-pxhZfTEfbaYrNrGn3g@mail.gmail.com>
References: <20200616084447.zq25ovnqbfotyb5h@pabbook>
	<2850838.AkLWLTjZdL@jason>
	<CAPweEDz2aazHGjUKSR2UMdfdkCA2S1M-pxhZfTEfbaYrNrGn3g@mail.gmail.com>
Message-ID: <7061140.N2zkLYW9tH@jason>

On Tuesday, 21 July 2020 23:25:12 CEST Luke Kenneth Casson Leighton wrote:
> On Tue, Jul 21, 2020 at 9:57 PM Paul Boddie <paul at boddie.org.uk> wrote:
> > OK, so the housing DT will contain the following for a VGA port...
> 
> paul: quite late, here, more tomorrow.  summary strategy:
> 
> * look at rbpi "hats" and how dtb overlays are done
> * copy that
> * rename rbpi "hat" overlay pins 0 to M to "eoma68 pins 1 to 68"

It would be useful to know where all these "hats" are defined. I found the 
following:

https://github.com/raspberrypi/linux/tree/rpi-5.4.y/arch/arm/boot/dts/overlays

A common theme seems to involve augmenting the gpio node from the chipset DT 
as follows (in the nicer syntax):

&gpio {
    some_pins: some_pins {
        brcm,pins = <...>;
        ...
    };
};

Then, various other nodes are augmented, also with device-specific details.

> in theory that should be pretty much the entire job, bar removing all
> multiplexed options other than the 1 specialist function and the GPIO
> option.  where in rbpi base "hat" interface there would be up to 4
> multiplexed options per pin (one of which will be GPIO), that must be
> restricted to "GPIO" and "EOMA68 function", per pin.
> 
> that really should be all.

Sorry, I just don't see how the overlays I found do this generically. All the 
node referencing is device-specific, although there is some aliasing done in 
"the firmware" for a limited number of nodes.

That works just fine with things like Raspberry Pi, but what we really need to 
see is what a device tree overlay looks like for a product that is used on 
multiple devices without needing to be customised for each one, if such an 
overlay exists.

The only thing I've found that seems to do pin aliasing is this:

https://beagleboard.org/blog/2018-01-17-building-a-device-tree-overlay-for-your-new-pocketcape-design

Even then, there is some pretty liberal usage of what appear to be device-
specific node references alongside the pin aliases, but I guess it is a start.

Paul




From allanitomwesh at gmail.com  Wed Jul 22 03:13:55 2020
From: allanitomwesh at gmail.com (Allan Mwenda)
Date: Wed, 22 Jul 2020 05:13:55 +0300
Subject: [Arm-netbook] Current status
In-Reply-To: <2034287.2zzArLbcde@jason>
References: <mailman.1.1595197284.6429.arm-netbook@lists.phcomp.co.uk>
	<CAPweEDy+_0QtUk8ievdp_s-hrnLBfa0iCCrEtLf4J3fgmjxFLA@mail.gmail.com>
	<20200720210214.79d4c075@Phenom-II-x6.niklas.com>
	<2034287.2zzArLbcde@jason>
Message-ID: <CAKG4L-XAto0jBjyYQoETytdMytbhKoBDE3p6wgOZJ2GnxggLSg@mail.gmail.com>

So basically, Ryzen is okay-ish, RISC-V and OpenPOWER are worth watching,
MIPS is dying and Intel are in deep shit? Good times.

On Wed, Jul 22, 2020 at 12:36 AM Paul Boddie <paul at boddie.org.uk> wrote:

> On Tuesday, 21 July 2020 03:02:14 CEST David Niklas wrote:
> > On Monday, July 20, 2020, George Sokolsky <sokolgeo at posteo.net> wrote:
> >
> > >  How people are moving forward with their computing needs?
>
> [...]
>
> > The RK3399 is a real winner of a processor, being sold on a lot of SBCs
> > for as little as $50. It's getting better and better SW support as devs
> > reverse engineer it's internal mali GPU and associated interconnect and
> > power controls.
>
> These Rockchip SoCs reportedly run pretty hot, don't they? That said, I
> noticed that the Raspberry Pi 4 has fan accessories available for it. So
> much
> for keeping up the pretense of Cambridge continuity with Acorn Computers
> unless the ultimate aim is to replicate products like the (unreleased)
> Acorn
> Business Computer with, apparently, a very noisy fan.
>
> > AMDs laptop offerings are also very temping and I'm recommending them to
> > normal people who want to purchase a laptop. Linux support is in great
> > shape for the 4000 series AFAIK[1]. Supposedly, AMD is coming out with an
> > APU even more amazing before the end of the year.
>
> I just upgraded my system (after fifteen years!) to one using a Ryzen
> 3400G
> APU (if they still call them that). However, Linux kernel compatibility is
> such that I'm running a kernel from the Debian backports repository
> because
> system reliability with these parts was a long time coming. And you have
> to
> use proprietary firmware blobs because all these companies need to have
> their
> secret sauce.
>
> So, upcoming AMD products could be decent, but I would be wary about
> stability
> for a while after their release. Following the Linux kernel bug tracker
> can be
> informative:
>
> https://bugzilla.kernel.org/
>
> Searching for "amdgpu" is probably what you want to do. For quite some
> time,
> people were having problems with the 3200G, and that made me worried about
> the
> 3400G, but it seems that even within product families there might be some
> parts that are better supported than others.
>
> [...]
>
> > MIPS was looking promising until you read it's "open source" license.
>
> Since I've experimented with MIPS things for a while, I have to say that
> the
> custodianship of MIPS has been generally disappointing.
>
> First of all, Imagination Technologies seemed to want to either compete
> head-
> on with ARM by having a processor architecture and graphics technologies,
> or
> (when their Apple partnership collapsed) to broaden their offerings and to
> use
> MIPS as a vehicle into IoT and such. At that time, they had their academic
> programme to try and get people to experiment with the architecture. But
> RISC-
> V was already on the runway at that point, so it was too little too late.
>
> Then, when ImgTec was acquired, MIPS got acquired and quickly passed on to
> Wave Technologies (presumably making some people some quick and easy
> money).
> But the MIPS business seems to be in maintenance mode, at least if you
> look at
> their Web assets. And, of course, all the MIPS Creator stuff just fell off
> the
> desk. Any announcements about opening the architecture might well be
> perceived
> as just making some noise and keeping existing licensees on board.
>
> Indeed, casually following Microchip over the last couple of years or so,
> I
> saw it said that Microchip's acquisition of Atmel would mean that
> Microchip
> would probably double down on ARM and abandon new MIPS product
> development.
> Various pundits/punters claimed that Microchip wouldn't look twice at
> RISC-V.
> But then I saw this:
>
> "A low-cost dev kit for Microchip's PolarFire SoC, a low-power FPGA
> integrated
> with a hardened quad core 64-bit RISC-V microprocessor subsystem"
>
> https://www.crowdsupply.com/microchip/polarfire-soc-icicle-kit
>
> That is from the Microsemi part of Microchip's business, however, meaning
> that
> it is another recent acquisition: Microchip presumably buying in new
> technology to remain competitive.
>
> Paul
>
>
>
> _______________________________________________
> arm-netbook mailing list arm-netbook at lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netbook at files.phcomp.co.uk

From lkcl at lkcl.net  Wed Jul 22 10:21:41 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Wed, 22 Jul 2020 10:21:41 +0100
Subject: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
In-Reply-To: <7061140.N2zkLYW9tH@jason>
References: <20200616084447.zq25ovnqbfotyb5h@pabbook>
	<2850838.AkLWLTjZdL@jason>
	<CAPweEDz2aazHGjUKSR2UMdfdkCA2S1M-pxhZfTEfbaYrNrGn3g@mail.gmail.com>
	<7061140.N2zkLYW9tH@jason>
Message-ID: <CAPweEDzWoD6NC9oG8TqF71kHEGERehn9VJ-P65D55U8SZWr=3A@mail.gmail.com>

On Tue, Jul 21, 2020 at 11:53 PM Paul Boddie <paul at boddie.org.uk> wrote:
>
> On Tuesday, 21 July 2020 23:25:12 CEST Luke Kenneth Casson Leighton wrote:
> > On Tue, Jul 21, 2020 at 9:57 PM Paul Boddie <paul at boddie.org.uk> wrote:
> > > OK, so the housing DT will contain the following for a VGA port...
> >
> > paul: quite late, here, more tomorrow.  summary strategy:
> >
> > * look at rbpi "hats" and how dtb overlays are done
> > * copy that
> > * rename rbpi "hat" overlay pins 0 to M to "eoma68 pins 1 to 68"
>
> It would be useful to know where all these "hats" are defined. I found the
> following:
>
> https://github.com/raspberrypi/linux/tree/rpi-5.4.y/arch/arm/boot/dts/overlays

https://github.com/raspberrypi/linux/blob/rpi-5.4.y/arch/arm/boot/dts/overlays/gpio-ir-overlay.dts

they're merging the pull-up and setup functionality with the actual
device itself.  this completely defeats the object of the exercise.


> > that really should be all.
>
> Sorry, I just don't see how the overlays I found do this generically.

if that IR example is anything to go by.

> That works just fine with things like Raspberry Pi, but what we really need to
> see is what a device tree overlay looks like for a product that is used on
> multiple devices without needing to be customised for each one, if such an
> overlay exists.
>
> The only thing I've found that seems to do pin aliasing is this:
>
> https://beagleboard.org/blog/2018-01-17-building-a-device-tree-overlay-for-your-new-pocketcape-design

yes, pin aliasing should do the trick.  so instead of (as in the IR example)

                                brcm,pins = <18>;
 // pin 18
                                brcm,function = <0>;                    // in
                                brcm,pull = <2>;                        // up

it would be

                                eoma68,pins = <18>;
   // pin 18
                                eoma68,function = <0>;                    // in
                                eoma68,pull = <2>;                        // up


> Even then, there is some pretty liberal usage of what appear to be device-
> specific node references alongside the pin aliases, but I guess it is a start.

indeed.

so what it looks like is, the beagleboard example shows how to
"disable" pins (describes it as "get them back").  following that, if
those pins can be cut/paste redefined and given eoma68 names, i
believe we're good to go.

i believe it may be necessary to have two definitions for each pin,
though (in each Card Overlay).

* one definition for the EOMA68 pin as a GPIO
* one definition for the EOMA68 pin in its "function" capacity.  SPI
MOSI for example.

the "hats" then choose which of these to "group together" in order to
create "EOMA68 SPI" or "EOMA68 LCD 15 pin bus" and so on.

l.


From lkcl at lkcl.net  Wed Jul 22 10:55:52 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Wed, 22 Jul 2020 10:55:52 +0100
Subject: [Arm-netbook] Current status
In-Reply-To: <CAKG4L-XAto0jBjyYQoETytdMytbhKoBDE3p6wgOZJ2GnxggLSg@mail.gmail.com>
References: <mailman.1.1595197284.6429.arm-netbook@lists.phcomp.co.uk>
	<CAPweEDy+_0QtUk8ievdp_s-hrnLBfa0iCCrEtLf4J3fgmjxFLA@mail.gmail.com>
	<20200720210214.79d4c075@Phenom-II-x6.niklas.com>
	<2034287.2zzArLbcde@jason>
	<CAKG4L-XAto0jBjyYQoETytdMytbhKoBDE3p6wgOZJ2GnxggLSg@mail.gmail.com>
Message-ID: <CAPweEDwohZezd7MVYLZHrj84hYxkzFYEC+cx8sJy2mASbOgRUA@mail.gmail.com>

On Wed, Jul 22, 2020 at 3:14 AM Allan Mwenda <allanitomwesh at gmail.com> wrote:
>
> So basically, Ryzen is okay-ish, RISC-V and OpenPOWER are worth watching,
> MIPS is dying and Intel are in deep shit?

embarrassingly large amounts of doo-doo, up to their eyeballs, yes.

hilariously, despite that, i now have an 8-core i9 dual hyper-threaded
5 ghz dell laptop with *64* GB of DDR4 RAM, and am really happy with
it.

l.


From allanitomwesh at gmail.com  Thu Jul 23 08:06:43 2020
From: allanitomwesh at gmail.com (Allan Mwenda)
Date: Thu, 23 Jul 2020 10:06:43 +0300
Subject: [Arm-netbook] Current status
In-Reply-To: <CAPweEDwohZezd7MVYLZHrj84hYxkzFYEC+cx8sJy2mASbOgRUA@mail.gmail.com>
References: <mailman.1.1595197284.6429.arm-netbook@lists.phcomp.co.uk>
	<CAPweEDy+_0QtUk8ievdp_s-hrnLBfa0iCCrEtLf4J3fgmjxFLA@mail.gmail.com>
	<20200720210214.79d4c075@Phenom-II-x6.niklas.com>
	<2034287.2zzArLbcde@jason>
	<CAKG4L-XAto0jBjyYQoETytdMytbhKoBDE3p6wgOZJ2GnxggLSg@mail.gmail.com>
	<CAPweEDwohZezd7MVYLZHrj84hYxkzFYEC+cx8sJy2mASbOgRUA@mail.gmail.com>
Message-ID: <CAKG4L-XJzkKQcA3NykAWZeW8sj=3UtTDFopK9BcBgHndkTmmSQ@mail.gmail.com>

i9's are power hungry as sin, and completely overshadowed by the new 4000
series mobile Ryzens which are both faster AND cheaper. In other news,this
looks like something you would be interested in Luke.
https://www.techpowerup.com/270207/globalfoundries-partners-with-synopsys-mentor-and-keysight-on-interoperable-process-design-kit

On Wed, Jul 22, 2020 at 12:56 PM Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> On Wed, Jul 22, 2020 at 3:14 AM Allan Mwenda <allanitomwesh at gmail.com>
> wrote:
> >
> > So basically, Ryzen is okay-ish, RISC-V and OpenPOWER are worth watching,
> > MIPS is dying and Intel are in deep shit?
>
> embarrassingly large amounts of doo-doo, up to their eyeballs, yes.
>
> hilariously, despite that, i now have an 8-core i9 dual hyper-threaded
> 5 ghz dell laptop with *64* GB of DDR4 RAM, and am really happy with
> it.
>
> l.
>
> _______________________________________________
> arm-netbook mailing list arm-netbook at lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netbook at files.phcomp.co.uk

From lkcl at lkcl.net  Thu Jul 23 09:50:16 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Thu, 23 Jul 2020 09:50:16 +0100
Subject: [Arm-netbook] Current status
In-Reply-To: <CAKG4L-XJzkKQcA3NykAWZeW8sj=3UtTDFopK9BcBgHndkTmmSQ@mail.gmail.com>
References: <mailman.1.1595197284.6429.arm-netbook@lists.phcomp.co.uk>
	<CAPweEDy+_0QtUk8ievdp_s-hrnLBfa0iCCrEtLf4J3fgmjxFLA@mail.gmail.com>
	<20200720210214.79d4c075@Phenom-II-x6.niklas.com>
	<2034287.2zzArLbcde@jason>
	<CAKG4L-XAto0jBjyYQoETytdMytbhKoBDE3p6wgOZJ2GnxggLSg@mail.gmail.com>
	<CAPweEDwohZezd7MVYLZHrj84hYxkzFYEC+cx8sJy2mASbOgRUA@mail.gmail.com>
	<CAKG4L-XJzkKQcA3NykAWZeW8sj=3UtTDFopK9BcBgHndkTmmSQ@mail.gmail.com>
Message-ID: <CAPweEDx1DJTz=3Gzxoskpx_g49yyPTjRKY_Q+nDQRq61Jm5Fkw@mail.gmail.com>

On Thursday, July 23, 2020, Allan Mwenda <allanitomwesh at gmail.com> wrote:

> cheaper. In other news,this
> looks like something you would be interested in Luke.
> https://www.techpowerup.com/270207/globalfoundries-
> partners-with-synopsys-mentor-and-keysight-on-interoperable-
> process-design-kit


 ah what they mean by that is, "open and shared between themselves once you
have signed the ipen iPDK NDA".

*face-palm*...




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

From maillist_arm-netbook at aross.me  Thu Jul 23 12:54:33 2020
From: maillist_arm-netbook at aross.me (Alexander Ross)
Date: Thu, 23 Jul 2020 12:54:33 +0100
Subject: [Arm-netbook] Current not intel Laptop/UMPC/Handheld Options
Message-ID: <02127d77-cf1a-ac64-1d72-b581052e7628@aross.me>

Been wondering if theres any new products from the last say 2years? As
i’ve not kept up with whats new else where.

I know pyra is progressing and dare i say, nearly ready.

For a laptop/umpc the more ram the better but a netbook size keyboard
thats easy for large adult hands to type on. when i was a teenager i
think keyboards like GPD pocket 1 where not so hard to type on but the
pocket came at a time when i was at the end of teenage years and had
grow more/fully and now i find it it bit awkward to type on, unlike my
10inch asus netboot.

Any fav chrome books to librate?

new handheld computers?, including intel cpus out of curiosity. like
pyra, smaller or a bit bigger.

or heck large laptops but not intel or amd? I do know of power cpu
laptop projects.

https://pyra-handheld.com/boards/forums/pyra-news.250/


From lkcl at lkcl.net  Thu Jul 23 21:03:10 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Thu, 23 Jul 2020 21:03:10 +0100
Subject: [Arm-netbook] openpower virtual coffee
Message-ID: <CAPweEDy=UQNh7te4XRU7gWSXd7cby0bQ46AfQ2xAq8gKkBkg9g@mail.gmail.com>

https://openpowerfoundation.org/openpower-virtual-coffee-calls/

in 2 hours.  conference call dial-in numbers at the above web page
(which do not involve running non-free proprietary software to attend)

these are an open informal chat, not recorded, no "agenda".  topics
have been thoroughly eclectic and enjoyable.

l.

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


From richard.wilbur at gmail.com  Fri Jul 24 02:26:10 2020
From: richard.wilbur at gmail.com (Richard Wilbur)
Date: Thu, 23 Jul 2020 19:26:10 -0600
Subject: [Arm-netbook] Current status
In-Reply-To: <20200721152846.410d57d4@Phenom-II-x6.niklas.com>
References: <20200721152846.410d57d4@Phenom-II-x6.niklas.com>
Message-ID: <1BB7E4F0-B399-4347-BDEF-6F93A59A8F96@gmail.com>


> On Jul 21, 2020, at 13:29, David Niklas <doark at mail.com> wrote:
> 
> On Tue, 21 Jul 2020 04:31:43 +0100
> Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote:
[…]
>> if you want to know more then do join one if rhe virtual coffee calls
>> 
>> https://openpowerfoundation.org/openpower-virtual-coffee-calls/
> 
> :cry:
> Another Zoom conference. Proprietary executable. Known spying company.
> Why luke, why do people always have to choose the worst of proprietary
> stuff?
> 
> https://nypost.com/2020/04/10/chinese-spies-are-trying-to-snoop-on-zoom-chats-experts-say/
> https://medium.com/swlh/zoom-are-you-spying-me-7c07feebf85
> 
> We have linphone, ekiga, not to mention the myriad of stuff on shareware
> sites ( Here's a good one I know from my windowz days
> https://www.freewarefiles.com/ ), if it must be proprietary.
> We have IRC, Jabber, Argh! So much good stuff!
> Conferencing stuff (not all FLOSS, but still a lot there):
> https://www.ubuntupit.com/top-20-best-linux-video-conferencing-software/

What about Jitsi Meet?
https://jitsi.org/jitsi-meet/

Free Software
Encrypted
Anonymous
Free Service



From lkcl at lkcl.net  Fri Jul 24 02:29:16 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Fri, 24 Jul 2020 02:29:16 +0100
Subject: [Arm-netbook] Current status
In-Reply-To: <1BB7E4F0-B399-4347-BDEF-6F93A59A8F96@gmail.com>
References: <20200721152846.410d57d4@Phenom-II-x6.niklas.com>
	<1BB7E4F0-B399-4347-BDEF-6F93A59A8F96@gmail.com>
Message-ID: <CAPweEDwZeVkoLqcwamrpznksBySet4AXEtKrAB7+VCpq8ny3sw@mail.gmail.com>

On Friday, July 24, 2020, Richard Wilbur <richard.wilbur at gmail.com> wrote:

>
> What about Jitsi Meet?
> https://jitsi.org/jitsi-meet/


really nice as long as no participants use firefox, at which point
everybody's browsers crash.

l.



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

From ericbavier at centurylink.net  Fri Jul 24 03:31:13 2020
From: ericbavier at centurylink.net (Eric Bavier)
Date: Thu, 23 Jul 2020 21:31:13 -0500
Subject: [Arm-netbook] Current status
In-Reply-To: <CAPweEDwZeVkoLqcwamrpznksBySet4AXEtKrAB7+VCpq8ny3sw@mail.gmail.com>
References: <20200721152846.410d57d4@Phenom-II-x6.niklas.com>
	<1BB7E4F0-B399-4347-BDEF-6F93A59A8F96@gmail.com>
	<CAPweEDwZeVkoLqcwamrpznksBySet4AXEtKrAB7+VCpq8ny3sw@mail.gmail.com>
Message-ID: <a103b4f119bc17682b1702eba97f359a0c83e3ac.camel@centurylink.net>

On Fri, 2020-07-24 at 02:29 +0100, Luke Kenneth Casson Leighton wrote:
> On Friday, July 24, 2020, Richard Wilbur <richard.wilbur at gmail.com>
> wrote:
> 
> > What about Jitsi Meet?
> > https://jitsi.org/jitsi-meet/
> 
> really nice as long as no participants use firefox, at which point
> everybody's browsers crash.

This seems to have been fixed sometime late May:

  
https://github.com/jitsi/jitsi-meet/issues/5439#issuecomment-635623174

Cheers,
`~Eric



From lkcl at lkcl.net  Sat Jul 25 13:29:45 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Sat, 25 Jul 2020 13:29:45 +0100
Subject: [Arm-netbook] Current not intel Laptop/UMPC/Handheld Options
In-Reply-To: <02127d77-cf1a-ac64-1d72-b581052e7628@aross.me>
References: <02127d77-cf1a-ac64-1d72-b581052e7628@aross.me>
Message-ID: <CAPweEDz1fFrAf+hzO5mG4cDw9uFbZKNU+0E5QL0xCm8bcu0APg@mail.gmail.com>

https://www.pine64.org/2020/07/24/all-about-the-pinetab-update/

lots of things still going on with Pine64.

l.


From paul at boddie.org.uk  Sat Jul 25 16:47:57 2020
From: paul at boddie.org.uk (Paul Boddie)
Date: Sat, 25 Jul 2020 17:47:57 +0200
Subject: [Arm-netbook] Current not intel Laptop/UMPC/Handheld Options
In-Reply-To: <CAPweEDz1fFrAf+hzO5mG4cDw9uFbZKNU+0E5QL0xCm8bcu0APg@mail.gmail.com>
References: <02127d77-cf1a-ac64-1d72-b581052e7628@aross.me>
	<CAPweEDz1fFrAf+hzO5mG4cDw9uFbZKNU+0E5QL0xCm8bcu0APg@mail.gmail.com>
Message-ID: <2929784.svU4ecNQhM@jason>

On Saturday, 25 July 2020 14:29:45 CEST Luke Kenneth Casson Leighton wrote:
> https://www.pine64.org/2020/07/24/all-about-the-pinetab-update/
> 
> lots of things still going on with Pine64.

The Pyra is still edging its way towards completion, too:

https://pyra-handheld.com/boards/forums/pyra-news.250/

Paul




From paul at boddie.org.uk  Sat Jul 25 16:58:24 2020
From: paul at boddie.org.uk (Paul Boddie)
Date: Sat, 25 Jul 2020 17:58:24 +0200
Subject: [Arm-netbook] DDR3 RAM Design Rules and Techniques
Message-ID: <8060963.J5Lu24a4qz@jason>

Hello,

One thing that just came up in another forum is the matter of routing PCB 
tracks for DDR3 RAM, and this is probably a topic that was encountered by both 
the Pyra...

https://pyra-handheld.com/boards/threads/analyzing-4gb-ram.81687/

https://pyra-handheld.com/boards/threads/is-there-really-a-light-at-the-end-of-the-journey.83007/

...and the EOMA68 initiatives. Is there any pertinent documentation describing 
this exercise in the EOMA68 board design process? Searching for DDR3 on the 
Rhombus Tech site [*] indicates that some boards were done with guidance (at 
some level) from the vendors:

http://rhombus-tech.net/ingenic/jz4775/news/11jul2014_routing_completed/

http://rhombus-tech.net/allwinner/a31/news/

Previous discussions of KiCad and Olimex boards, which presumably involved 
DDR3 routing, can be found via this message:

http://lists.phcomp.co.uk/pipermail/arm-netbook/2019-May/016062.html

I ask about this in the context of someone who just made design files 
available for a board using the Ingenic JZ4780 that they had been working on. 
Those files are here:

https://gitlab.com/igagis/cranberrypi

Paul

[*] http://rhombus-tech.net/cgi-bin/rhombus/ikiwiki.cgi?P=DDR3




From lkcl at lkcl.net  Sat Jul 25 17:02:55 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Sat, 25 Jul 2020 17:02:55 +0100
Subject: [Arm-netbook] DDR3 RAM Design Rules and Techniques
In-Reply-To: <8060963.J5Lu24a4qz@jason>
References: <8060963.J5Lu24a4qz@jason>
Message-ID: <CAPweEDwx+5maA49WTK-y7=1snJgVwy2k07fQ=mv4pU6bHuQyTg@mail.gmail.com>

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

On Sat, Jul 25, 2020 at 4:58 PM Paul Boddie <paul at boddie.org.uk> wrote:
>
> Hello,
>
> One thing that just came up in another forum is the matter of routing PCB
> tracks for DDR3 RAM,

yes.  it's a pig.  specialist people with a huge amount of expertise
can do it - or, if you have the right proprietary software, much of it
can be handled automatically.

> ...and the EOMA68 initiatives. Is there any pertinent documentation describing
> this exercise in the EOMA68 board design process?

put simply: i take an existing Reference Design, do *not* touch the
DDR layout - at all.

that's it.

l.


From pablo at parobalth.org  Sun Jul 26 10:30:01 2020
From: pablo at parobalth.org (Pablo Rath)
Date: Sun, 26 Jul 2020 11:30:01 +0200
Subject: [Arm-netbook] EOMA68-A20, MD 1.7 severe Power Problems
Message-ID: <20200726093000.nltv6wypuaztdesa@pabbook>

I am very sorry to inform everyone on this list that I had a severe power problem with my Micro Desktop 1.7.
I applied power to the DC Jack and the area right to the jack burned
out. (see attached picture).
One thing that I noticed today was that UART worked when the
card was powered up whilst attached to USB OTG alone (DC
Jack on MD not connected)! But according to the wiki this
should not work at all because of the Y6280 current control
IC set at 1A acting as a diode in this case.
When I applied power only to the MD I noticed that UART
output was complete garbage (random characters). I don't know if only
sometimes or everytime. When on DC power, board in FEL-mode with no card
and pressing '2', then connecting USB OTG and booting U-Boot sunxi over FEL everything worked flawlessly.

As I said I am very sorry that I screwed up.
Luke, do you have any ideas what went wrong? Do you think this
+also destroyed the computer card?
If the error is on my side (embarassing but still the better
+case) I
will have to swallow the bitter pill that I screwed up badly.
I am still going to cover the costs of computer card and MD so there will not be a financial loss to the project. 
I am very disappointed as I have made could progress. Had sunxi U-Boot,
sunxi 3.4.104 kernel running and booting Debian Stretch rootfs...

On the other hand if this is a general problem
better we know it now and can take the necessary steps.

Pablo

-------------- next part --------------
A non-text attachment was scrubbed...
Name: MD1-7_pablo_small.JPG
Type: image/jpeg
Size: 736479 bytes
Desc: not available
URL: <http://lists.phcomp.co.uk/pipermail/arm-netbook/attachments/20200726/cf1d790c/attachment-0001.jpe>

From pablo at parobalth.org  Sun Jul 26 10:36:29 2020
From: pablo at parobalth.org (Pablo Rath)
Date: Sun, 26 Jul 2020 11:36:29 +0200
Subject: [Arm-netbook] Resending: EOMA68-A20, MD 1.7 severe Power Problems
Message-ID: <20200726093629.e5ckg3sz2wdailem@pabbook>

Resending without attachement:


I am very sorry to inform everyone on this list that I had a severe power problem with my Micro Desktop 1.7.
I applied power to the DC Jack and the area right to the jack burned
out. (see attached picture).
One thing that I noticed today was that UART worked when the
card was powered up whilst attached to USB OTG alone (DC
Jack on MD not connected)! But according to the wiki this
should not work at all because of the Y6280 current control
IC set at 1A acting as a diode in this case.
When I applied power only to the MD I noticed that UART
output was complete garbage (random characters). I don't know if only
sometimes or everytime. When on DC power, board in FEL-mode with no card
and pressing '2', then connecting USB OTG and booting U-Boot sunxi over FEL everything worked flawlessly.

As I said I am very sorry that I screwed up.
Luke, do you have any ideas what went wrong? Do you think this
+also destroyed the computer card?
If the error is on my side (embarassing but still the better
+case) I
will have to swallow the bitter pill that I screwed up badly.
I am still going to cover the costs of computer card and MD so there will not be a financial loss to the project. 
I am very disappointed as I have made could progress. Had sunxi U-Boot,
sunxi 3.4.104 kernel running and booting Debian Stretch rootfs...

On the other hand if this is a general problem
better we know it now and can take the necessary steps.

Pablo




----- End forwarded message -----


From lkcl at lkcl.net  Sun Jul 26 10:54:27 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Sun, 26 Jul 2020 10:54:27 +0100
Subject: [Arm-netbook] EOMA68-A20, MD 1.7 severe Power Problems
In-Reply-To: <20200726093000.nltv6wypuaztdesa@pabbook>
References: <20200726093000.nltv6wypuaztdesa@pabbook>
Message-ID: <CAPweEDx+0ZpJZ7_ER0OA3Pcs4zzapcXi81bxhZruKKVgUCwrTw@mail.gmail.com>

On Sun, Jul 26, 2020 at 10:33 AM Pablo Rath <pablo at parobalth.org> wrote:
>
> I am very sorry to inform everyone on this list that I had a severe power problem with my Micro Desktop 1.7.
> I applied power to the DC Jack and the area right to the jack burned
> out. (see attached picture).

thank you for sending this to the list, as i asked, after you sent it
initially privately.  i had this happen to a 1.5 MD board 3 years ago,
but no others, despite them running for prolonged periods of time.

what i noticed about that board was that the inductor was not properly
soldered down.  this would be insufficient contact, introduce
resistance, and at that point the RT8288 would go unstable.


> One thing that I noticed today was that UART worked when the
> card was powered up whilst attached to USB OTG alone (DC
> Jack on MD not connected)!

yes, i mentioned this already.  the TX and RX line GPIO current is
sufficient to "power" the LEDs and possibly the FT2322 IC as well.

> But according to the wiki this
> should not work at all because of the Y6280 current control
> IC set at 1A acting as a diode in this case.

no: it's not being powered through the 5.0V rail: the LEDs on the
USB-UART are being powered through the *processor*, through the TX and
RX lines.

> When I applied power only to the MD I noticed that UART
> output was complete garbage (random characters).

yes.  i did say.  you get GND loops that spike the USB-UART
sufficiently to trigger the RX line.

> I don't know if only
> sometimes or everytime. When on DC power, board in FEL-mode with no card
> and pressing '2', then connecting USB OTG and booting U-Boot sunxi over FEL everything worked flawlessly.
>
> As I said I am very sorry that I screwed up.
> Luke, do you have any ideas what went wrong?

not in the slightest.  or - maybe: have a look at the contact points
where the inductor sits on the PCB.  there should be quite a lot of
solder, there.


> Do you think this
> +also destroyed the computer card?

when it happened for me it did no damage.  all i did was (because i
didn't have any spares) find a USB2 back-to-back power cable (i may
have made one by cutting a plug off a USB device and wiring it to a
5.0v supply), plug it into one of the USB2 ports and provided "direct"
5.0v power that way.  you *need* a stable supply to do that (1.5
preferably 2.0 A) designed *specifically* for providing USB power.
UNDER NO CIRCUMSTANCES plug the 12v PSU into the USB socket.  and DO
NOT use an "off-the-shelf generic 5.0v wall wart".  use something
SPECIFICALLY designed for providing USB power because it is (a) stable
and (b) current-limited.

if you plug the Card directly into a socket (OTG, removed from the
MicroDesktop) - not via a USB hub - "ls" should show the familiar USB
ID for the A20.


> If the error is on my side (embarassing but still the better
> +case) I
> will have to swallow the bitter pill that I screwed up badly.
> I am still going to cover the costs of computer card and MD so there will not be a financial loss to the project.

appreciated


> I am very disappointed as I have made could progress. Had sunxi U-Boot,
> sunxi 3.4.104 kernel running and booting Debian Stretch rootfs...

great!

> On the other hand if this is a general problem
> better we know it now and can take the necessary steps.

modifying the 1.7 MD PCB and going through *yet another* round of PCB
development costs and time delays - this not something i want everyone
to have to go through.   particularly because they're already
manufactured.

sigh.

l.


From lkcl at lkcl.net  Sun Jul 26 11:54:28 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Sun, 26 Jul 2020 11:54:28 +0100
Subject: [Arm-netbook] EOMA68-A20, MD 1.7 severe Power Problems
In-Reply-To: <CAPweEDx+0ZpJZ7_ER0OA3Pcs4zzapcXi81bxhZruKKVgUCwrTw@mail.gmail.com>
References: <20200726093000.nltv6wypuaztdesa@pabbook>
	<CAPweEDx+0ZpJZ7_ER0OA3Pcs4zzapcXi81bxhZruKKVgUCwrTw@mail.gmail.com>
Message-ID: <CAPweEDwL7iUbO_d_ur7zWSb=55hSjJUnB6WVbVOyEsaMVU-hNw@mail.gmail.com>

this is from the RT8288 datasheet.  i think for a 1.8 MD this area
will need rework.  a rework of the VGA area is needed anyway.

l.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2020-07-26_11-52.png
Type: image/png
Size: 83468 bytes
Desc: not available
URL: <http://lists.phcomp.co.uk/pipermail/arm-netbook/attachments/20200726/dc1cbbfa/attachment-0001.png>

From allanitomwesh at gmail.com  Sun Jul 26 19:27:09 2020
From: allanitomwesh at gmail.com (Allan Mwenda)
Date: Sun, 26 Jul 2020 21:27:09 +0300
Subject: [Arm-netbook] Current status
In-Reply-To: <CAPweEDx1DJTz=3Gzxoskpx_g49yyPTjRKY_Q+nDQRq61Jm5Fkw@mail.gmail.com>
References: <mailman.1.1595197284.6429.arm-netbook@lists.phcomp.co.uk>
	<CAPweEDy+_0QtUk8ievdp_s-hrnLBfa0iCCrEtLf4J3fgmjxFLA@mail.gmail.com>
	<20200720210214.79d4c075@Phenom-II-x6.niklas.com>
	<2034287.2zzArLbcde@jason>
	<CAKG4L-XAto0jBjyYQoETytdMytbhKoBDE3p6wgOZJ2GnxggLSg@mail.gmail.com>
	<CAPweEDwohZezd7MVYLZHrj84hYxkzFYEC+cx8sJy2mASbOgRUA@mail.gmail.com>
	<CAKG4L-XJzkKQcA3NykAWZeW8sj=3UtTDFopK9BcBgHndkTmmSQ@mail.gmail.com>
	<CAPweEDx1DJTz=3Gzxoskpx_g49yyPTjRKY_Q+nDQRq61Jm5Fkw@mail.gmail.com>
Message-ID: <CAKG4L-X8TaHfEsa-qM-RFqE3opf-RkROCiw_WGj=EF2EG=1LOg@mail.gmail.com>

There was another one by Google but at like 100nm, maybe that one has no
caveats?

https://antmicro.com/blog/2020/06/skywater-open-source-pdk/

On Thu, Jul 23, 2020 at 11:50 AM Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> On Thursday, July 23, 2020, Allan Mwenda <allanitomwesh at gmail.com> wrote:
>
> > cheaper. In other news,this
> > looks like something you would be interested in Luke.
> > https://www.techpowerup.com/270207/globalfoundries-
> > partners-with-synopsys-mentor-and-keysight-on-interoperable-
> > process-design-kit
>
>
>  ah what they mean by that is, "open and shared between themselves once you
> have signed the ipen iPDK NDA".
>
> *face-palm*...
>
>
>
>
> --
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> _______________________________________________
> arm-netbook mailing list arm-netbook at lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netbook at files.phcomp.co.uk

From lkcl at lkcl.net  Sun Jul 26 19:59:21 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Sun, 26 Jul 2020 19:59:21 +0100
Subject: [Arm-netbook] Current status
In-Reply-To: <CAKG4L-X8TaHfEsa-qM-RFqE3opf-RkROCiw_WGj=EF2EG=1LOg@mail.gmail.com>
References: <mailman.1.1595197284.6429.arm-netbook@lists.phcomp.co.uk>
	<CAPweEDy+_0QtUk8ievdp_s-hrnLBfa0iCCrEtLf4J3fgmjxFLA@mail.gmail.com>
	<20200720210214.79d4c075@Phenom-II-x6.niklas.com>
	<2034287.2zzArLbcde@jason>
	<CAKG4L-XAto0jBjyYQoETytdMytbhKoBDE3p6wgOZJ2GnxggLSg@mail.gmail.com>
	<CAPweEDwohZezd7MVYLZHrj84hYxkzFYEC+cx8sJy2mASbOgRUA@mail.gmail.com>
	<CAKG4L-XJzkKQcA3NykAWZeW8sj=3UtTDFopK9BcBgHndkTmmSQ@mail.gmail.com>
	<CAPweEDx1DJTz=3Gzxoskpx_g49yyPTjRKY_Q+nDQRq61Jm5Fkw@mail.gmail.com>
	<CAKG4L-X8TaHfEsa-qM-RFqE3opf-RkROCiw_WGj=EF2EG=1LOg@mail.gmail.com>
Message-ID: <CAPweEDydn-E6GxYuFyHnNeJUhS_p-eUL7tJnb_T2eY8eWExDcA@mail.gmail.com>

On Sunday, July 26, 2020, Allan Mwenda <allanitomwesh at gmail.com> wrote:

> There was another one by Google but at like 100nm,


130nm.


> maybe that one has no
> caveats?


caveat: designs must be libre / open.

(yay!)


>
> https://antmicro.com/blog/2020/06/skywater-open-source-pdk/
>
>
>

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

From pablo at parobalth.org  Sun Jul 26 20:58:49 2020
From: pablo at parobalth.org (Pablo Rath)
Date: Sun, 26 Jul 2020 21:58:49 +0200
Subject: [Arm-netbook] 2.7.5 latest pre-production boards tested and
 working
In-Reply-To: <CAPweEDxY1Ur3eCCTqDypficTNAyogH0JpL4o=9Fvav1+kMjm3w@mail.gmail.com>
References: <CAPweEDxY1Ur3eCCTqDypficTNAyogH0JpL4o=9Fvav1+kMjm3w@mail.gmail.com>
Message-ID: <20200726195849.6krb3dwwrhycuw2k@pabbook>

On Tue, Jul 21, 2020 at 08:39:23PM +0100, Luke Kenneth Casson Leighton wrote:
> yes, a few months ago, mike sent me 2 new prototypes, using
> "single-panel" PCB from a high-quality manufacturer.  i tested them
> just now (yes, long story, very busy with Libre-SOC) and they work
> fine.  boot off of the usual micro-sd card i've been using.

Great news! Makes me wonder why no one replied... 
Is the next step the small production run with 100 Units or
do you have to do additional tests?
What about HDMI?

Pablo


From lkcl at lkcl.net  Sun Jul 26 21:10:33 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Sun, 26 Jul 2020 21:10:33 +0100
Subject: [Arm-netbook] 2.7.5 latest pre-production boards tested and
	working
In-Reply-To: <20200726195849.6krb3dwwrhycuw2k@pabbook>
References: <CAPweEDxY1Ur3eCCTqDypficTNAyogH0JpL4o=9Fvav1+kMjm3w@mail.gmail.com>
	<20200726195849.6krb3dwwrhycuw2k@pabbook>
Message-ID: <CAPweEDzKwaVRsqJTxtHid77d2jhxNVDs5GCipT6SFS9aXqBUJw@mail.gmail.com>

On Sun, Jul 26, 2020 at 8:59 PM Pablo Rath <pablo at parobalth.org> wrote:
>
> On Tue, Jul 21, 2020 at 08:39:23PM +0100, Luke Kenneth Casson Leighton wrote:
> > yes, a few months ago, mike sent me 2 new prototypes, using
> > "single-panel" PCB from a high-quality manufacturer.  i tested them
> > just now (yes, long story, very busy with Libre-SOC) and they work
> > fine.  boot off of the usual micro-sd card i've been using.
>
> Great news! Makes me wonder why no one replied...
> Is the next step the small production run with 100 Units

yehyeh - once Mike responds.  he'll need some "confidence-building"
and reassurance to go ahead.

> or do you have to do additional tests?

it boots which means MicroSD worked, DDR3 worked, power worked, UART worked,

> What about HDMI?

honestly i'm not going to worry about it.  if it works, it works.  if
it doesn't there's nothing i can do at this point, until we're beyond
the "shipping" phase.

l.


From pablo at parobalth.org  Sun Jul 26 21:31:08 2020
From: pablo at parobalth.org (Pablo Rath)
Date: Sun, 26 Jul 2020 22:31:08 +0200
Subject: [Arm-netbook] EOMA68-A20, MD 1.7 severe Power Problems
In-Reply-To: <CAPweEDx+0ZpJZ7_ER0OA3Pcs4zzapcXi81bxhZruKKVgUCwrTw@mail.gmail.com>
References: <20200726093000.nltv6wypuaztdesa@pabbook>
	<CAPweEDx+0ZpJZ7_ER0OA3Pcs4zzapcXi81bxhZruKKVgUCwrTw@mail.gmail.com>
Message-ID: <20200726203108.66ndgur3imhsyhdu@pabbook>

>On Sun, Jul 26, 2020 at 10:54:27AM +0100, Luke Kenneth Casson Leighton wrote:
>> On Sun, Jul 26, 2020 at 10:33 AM Pablo Rath <pablo at parobalth.org> wrote:
> >
> > I am very sorry to inform everyone on this list that I had a severe power problem with my Micro Desktop 1.7.
> > I applied power to the DC Jack and the area right to the jack burned
> > out. (see attached picture).
> 
> thank you for sending this to the list, as i asked, after you sent it
> initially privately.  i had this happen to a 1.5 MD board 3 years ago,
> but no others, despite them running for prolonged periods of time.
> 
> what i noticed about that board was that the inductor was not properly
> soldered down.  this would be insufficient contact, introduce
> resistance, and at that point the RT8288 would go unstable.

Ok. As you have probably deduced from my questions I am not really into
hardware. Thank you for all your explanations and clarifications. 
I still try to wrap my head around what should work straight away, what
could work with the right modifications and what can never work...

[...]

> > As I said I am very sorry that I screwed up.
> > Luke, do you have any ideas what went wrong?
> 
> not in the slightest.  or - maybe: have a look at the contact points
> where the inductor sits on the PCB.  there should be quite a lot of
> solder, there.

Sorry for the dumb question but where can I find the inductor?

> > Do you think this
> > +also destroyed the computer card?
> 
> when it happened for me it did no damage.  all i did was (because i
> didn't have any spares) find a USB2 back-to-back power cable (i may
> have made one by cutting a plug off a USB device and wiring it to a
> 5.0v supply), plug it into one of the USB2 ports and provided "direct"
> 5.0v power that way.  you *need* a stable supply to do that (1.5
> preferably 2.0 A) designed *specifically* for providing USB power.
> UNDER NO CIRCUMSTANCES plug the 12v PSU into the USB socket.  and DO
> NOT use an "off-the-shelf generic 5.0v wall wart".  use something
> SPECIFICALLY designed for providing USB power because it is (a) stable
> and (b) current-limited.

I have a power supply from a Huawei Tablet (Output 5V, 2A) and one from
an old Ipad Mini (Output 5V, 1A) both with a wall plug and a female USB
socket. Can I use one of them with a standard USB 2.0 USB A to USB A (male to
male) cable?
The term 'back-to-back' power cable yielded limited search results in my
case. 
Another option is an official PSU for the Raspberry Pi, 5V, 2A with wall
plug and a non-detachable micro-usb cable. I can buy a micro-usb to USB
A adapter if this is going to work.
So I have to either buy a cable, an adapter or a whole new USB Power
supply depending on your opinion.

> if you plug the Card directly into a socket (OTG, removed from the
> MicroDesktop) - not via a USB hub - "ls" should show the familiar USB
> ID for the A20.

My initial thought today was: "NO, now everything is lost." so your
reply made my day. Tested the Card standalone and 'sunxi-fel version'
shows an Allwinner Device in FEL-Mode. Computer Card still alive!

Pablo


From allanitomwesh at gmail.com  Sun Jul 26 21:44:01 2020
From: allanitomwesh at gmail.com (Allan Mwenda)
Date: Sun, 26 Jul 2020 23:44:01 +0300
Subject: [Arm-netbook] Current status
In-Reply-To: <CAPweEDydn-E6GxYuFyHnNeJUhS_p-eUL7tJnb_T2eY8eWExDcA@mail.gmail.com>
References: <mailman.1.1595197284.6429.arm-netbook@lists.phcomp.co.uk>
	<CAPweEDy+_0QtUk8ievdp_s-hrnLBfa0iCCrEtLf4J3fgmjxFLA@mail.gmail.com>
	<20200720210214.79d4c075@Phenom-II-x6.niklas.com>
	<2034287.2zzArLbcde@jason>
	<CAKG4L-XAto0jBjyYQoETytdMytbhKoBDE3p6wgOZJ2GnxggLSg@mail.gmail.com>
	<CAPweEDwohZezd7MVYLZHrj84hYxkzFYEC+cx8sJy2mASbOgRUA@mail.gmail.com>
	<CAKG4L-XJzkKQcA3NykAWZeW8sj=3UtTDFopK9BcBgHndkTmmSQ@mail.gmail.com>
	<CAPweEDx1DJTz=3Gzxoskpx_g49yyPTjRKY_Q+nDQRq61Jm5Fkw@mail.gmail.com>
	<CAKG4L-X8TaHfEsa-qM-RFqE3opf-RkROCiw_WGj=EF2EG=1LOg@mail.gmail.com>
	<CAPweEDydn-E6GxYuFyHnNeJUhS_p-eUL7tJnb_T2eY8eWExDcA@mail.gmail.com>
Message-ID: <CAKG4L-XJZj47zypb_w+7E0sMCsTuvHErU1-i3=xH8xRKkF-1hg@mail.gmail.com>

get in there and test some RISC-V and OpenPOWER designs amirite?!

On Sun, Jul 26, 2020 at 10:00 PM Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> On Sunday, July 26, 2020, Allan Mwenda <allanitomwesh at gmail.com> wrote:
>
> > There was another one by Google but at like 100nm,
>
>
> 130nm.
>
>
> > maybe that one has no
> > caveats?
>
>
> caveat: designs must be libre / open.
>
> (yay!)
>
>
> >
> > https://antmicro.com/blog/2020/06/skywater-open-source-pdk/
> >
> >
> >
>
> --
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> _______________________________________________
> arm-netbook mailing list arm-netbook at lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netbook at files.phcomp.co.uk

From paul at boddie.org.uk  Sun Jul 26 22:00:30 2020
From: paul at boddie.org.uk (Paul Boddie)
Date: Sun, 26 Jul 2020 23:00:30 +0200
Subject: [Arm-netbook] EOMA68-A20, MD 1.7 severe Power Problems
In-Reply-To: <CAPweEDx+0ZpJZ7_ER0OA3Pcs4zzapcXi81bxhZruKKVgUCwrTw@mail.gmail.com>
References: <20200726093000.nltv6wypuaztdesa@pabbook>
	<CAPweEDx+0ZpJZ7_ER0OA3Pcs4zzapcXi81bxhZruKKVgUCwrTw@mail.gmail.com>
Message-ID: <1634177.2ahI1gIysu@jason>

On Sunday, 26 July 2020 11:54:27 CEST Luke Kenneth Casson Leighton wrote:
>
> you *need* a stable supply to do that (1.5 preferably 2.0 A) designed
> *specifically* for providing USB power. UNDER NO CIRCUMSTANCES plug the 12v
> PSU into the USB socket.  and DO NOT use an "off-the-shelf generic 5.0v wall
> wart".  use something SPECIFICALLY designed for providing USB power because
> it is (a) stable and (b) current-limited.

All this talk of regulated power supplies reminded me of this product which 
takes a range of inputs via the barrel jack socket:

https://proto-pic.co.uk/product/sparkfun-prt-13032-breadboard-power-supply-stick-5v-3-3v/

Meanwhile, the CI20 can be powered from a USB port and employs a barrel jack 
socket to accept that power. According to the hardware reference it is 
actually "a 5V 4mm (shield) x 1.7mm (pin) center positive connector ... 
identical to that of the original Sony PSP":

https://www.elinux.org/CI20_Hardware#Power

I'm not sure if either of these things are relevant here, though.

Paul




From lkcl at lkcl.net  Sun Jul 26 22:29:07 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Sun, 26 Jul 2020 22:29:07 +0100
Subject: [Arm-netbook] EOMA68-A20, MD 1.7 severe Power Problems
In-Reply-To: <20200726203108.66ndgur3imhsyhdu@pabbook>
References: <20200726093000.nltv6wypuaztdesa@pabbook>
	<CAPweEDx+0ZpJZ7_ER0OA3Pcs4zzapcXi81bxhZruKKVgUCwrTw@mail.gmail.com>
	<20200726203108.66ndgur3imhsyhdu@pabbook>
Message-ID: <CAPweEDxBeffn3CzWxG4XuJy7zDDjyPTbmFbQBneSXaozjD=DBg@mail.gmail.com>

On Sunday, July 26, 2020, Pablo Rath <pablo at parobalth.org> wrote:

> >
> > not in the slightest.  or - maybe: have a look at the contact points
> > where the inductor sits on the PCB.  there should be quite a lot of
> > solder, there.
>
> Sorry for the dumb question but where can I find the inductor?


big square thing 10x10mm by about 5mm high with a round thing in the
middle.  metal thing on two sides, wire leading into the round thing.

inductors are electromagnets basically.



>
> I have a power supply from a Huawei Tablet (Output 5V, 2A) and one from
> an old Ipad Mini (Output 5V, 1A) both with a wall plug and a female USB
> socket.


ok you need... a male to male cable.


> Can I use one of them with a standard USB 2.0 USB A to USB A (male to
> male) cable?


yes that's the one.  usually used on laptop fan bases.



>
> > if you plug the Card directly into a socket (OTG, removed from the
> > MicroDesktop) - not via a USB hub - "ls" should show the familiar USB
> > ID for the A20.
>
> My initial thought today was: "NO, now everything is lost." so your
> reply made my day. Tested the Card standalone and 'sunxi-fel version'
> shows an Allwinner Device in FEL-Mode. Computer Card still alive!


hurrah.  so yes just ignore the blown RT8288 entirely.

actually to get better power stability (no GND loops) you can plug the
USBA-to-A cable into the same device as the USB-UART is going into.

one thing occurred to me is the possibility that the AC Mains hum combined
with ground loops (through the USB UART into the laptop) may have been
enough to overload the RT8288 just as the PSU was being plugged in.

given that this is going to be a fairly normal configuration (leaving the
UART plugged into a laptop) i am not very happy.

l.



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

From richard.wilbur at gmail.com  Mon Jul 27 00:44:42 2020
From: richard.wilbur at gmail.com (Richard Wilbur)
Date: Sun, 26 Jul 2020 23:44:42 -0000
Subject: [Arm-netbook] EOMA68-A20, MD 1.7 severe Power Problems
In-Reply-To: <20200726203108.66ndgur3imhsyhdu@pabbook>
References: <20200726093000.nltv6wypuaztdesa@pabbook>
	<CAPweEDx+0ZpJZ7_ER0OA3Pcs4zzapcXi81bxhZruKKVgUCwrTw@mail.gmail.com>
	<20200726203108.66ndgur3imhsyhdu@pabbook>
Message-ID: <CAC4=CAFvypqijRhuVGNpmCUvD3C28_x=v4twBQGKiVS7rnxJ3A@mail.gmail.com>

On Sun, Jul 26, 2020 at 2:31 PM Pablo Rath <pablo at parobalth.org> wrote:
>
> >On Sun, Jul 26, 2020 at 10:54:27AM +0100, Luke Kenneth Casson Leighton wrote:
> >> On Sun, Jul 26, 2020 at 10:33 AM Pablo Rath <pablo at parobalth.org> wrote:
> > >
> > > I am very sorry to inform everyone on this list that I had a severe power problem with my Micro Desktop 1.7.
> > > I applied power to the DC Jack and the area right to the jack burned
> > > out. (see attached picture).
> >
> > thank you for sending this to the list, as i asked, after you sent it
> > initially privately.  i had this happen to a 1.5 MD board 3 years ago,
> > but no others, despite them running for prolonged periods of time.
> >
> > what i noticed about that board was that the inductor was not properly
> > soldered down.  this would be insufficient contact, introduce
> > resistance, and at that point the RT8288 would go unstable.
>
> Ok. As you have probably deduced from my questions I am not really into
> hardware. Thank you for all your explanations and clarifications.
> I still try to wrap my head around what should work straight away, what
> could work with the right modifications and what can never work...
>
> [...]
>
> > > As I said I am very sorry that I screwed up.
> > > Luke, do you have any ideas what went wrong?
> >
> > not in the slightest.  or - maybe: have a look at the contact points
> > where the inductor sits on the PCB.  there should be quite a lot of
> > solder, there.
>
> Sorry for the dumb question but where can I find the inductor?

Without the assembly drawing at my fingertips this would be my
educated guess.  It’s the closest component to the offending regulator
IC that looks the part of an inductor.
[see attached picture]

I am going to check my mini desktop PCB for good solder on the
inductor.  I will also look at possible modifications/improvements to
that feedback circuit layout given the present PCB layout.  (I have
some experience with specifying rework/changes to remedy deficits in
already-fabricated PCB’s.)

Best wishes,
Richard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Inductor.jpg
Type: image/jpeg
Size: 35822 bytes
Desc: not available
URL: <http://lists.phcomp.co.uk/pipermail/arm-netbook/attachments/20200726/6d110432/attachment-0001.jpg>