[Arm-netbook] 480 × 272 5" LCD lash up ready for testing

[luke.leighton]

On Sat, Sep 14, 2013 at 7:25 PM, joem <joem at martindale-electric.co.uk> wrote:
>
>  it's more complex than you're imagining it to be
>
> ---
>
> Dah!
>
> Luke you are getting to the point where you have to step back
> and take stock of one important formula.

 joe - you're almost there.  you're truly underestimating how much
you've achieved already.  it only looks like you've not achieved a lot
because you're not familiar with linux kernel deployment on embedded
hardware [it's radically different from the average x86 / amd64
install.   _radically_ different].


> Project well being = Human endeavor x (Tools)^2

 yes.  i'm... rather surprised that there are 25 CPU Cards out there
and only 3 of us actively using them.  you, me and chris.

> What that is telling you is that if you could put out some tools
> such as uSD  dd images, some 30+ people could endeavor immediately,
> and just having one more tool improves the project by the
> square. So your most useful job right now it to put out 2 or more
> tools out there that are working that clowns like myself can use.

 you're not a clown - you're a hardware engineer.

> (The formula applies to every open source project - if you want success, put more
> easy to use tools in the hands of developers first.)

 we're not *at* that stage yet.  we're at the
"pre-tools-for-developers" stage.  given that there are 25 CPU Cards
out there i was anticipating a hell of a lot more assistance from the
people who bought the cards to help those people who are clearly *not*
software developers (such as yourself) to get up-and-running.

once we're beyond this incredibly early phase where we've only just
confirmed that the hardware's all working (as of last week), there
will be far more people, and what you want *will* become available,
because there will be people who will do it, because they understand
that if they don't, they'll forget how they did it and they've done
that so many times that they know from experience to bloody well
document things.


> So my advise, ease up on all your recipes for success, (they are not tools)
> and whatever else baggage you are carrying (such as a bad experiences
> with distributing images),

 there's never been a bad experience: you've misunderstood.  i
*disagree* with the concept of providing ready-baked images to people
because it rings massive alarm bells for several reasons

 1) the provision of pre-baked images is massively wasteful of resources

 2) the provision of pre-baked images *automatically* means that the
image comes with pre-baked decisions that will not suit *anyone* (let
alone will not suit everyone).  wasted space, extra packages, default
passwords, wrong disk size, wrong fstab entries: you name it, it's
wrong.

 3) the provision of pre-baked images *deprives* you of the skill,
knowledge and ability to get your *own* hardware up-and-running

 4) the provision of pre-baked images results in people being
critically dependent on the provider for that image.


> go make some dd uSD images, virtual machines,
> and take up some janitorial duties such 100% improving and fixing the documentation.

 i'm only one person, and my priority right now is to get this tablet
I/O board up-and-running with absolute top priority.

 the other 20 people who have CPU Cards were sold those cards pretty
much at-cost so as to be able to help with exactly the tasks that
you've mentioned.

 my role is therefore to teach those early people so that they become
independent and can teach others.


> Its not meant to be a criticism, because it takes all sorts to make
> the open source world go round. Its a case of finding the right balance
> as your project is taking off, hardware is working, there is an eager band
> of supporters and now software needs to work without you having to be directly involved.
> So I hope the advise is taken

 i hear you - and i'm going to pass it on to the other 20 people who
have CPU Cards, for them to respond.  i'm going to assume that they're
on the list, and are reading it.  if we don't hear from any of them
within a week i'll contact them directly.

 in the meantime joe can you send me your telephone number (off-list)
and we'll make arrangements to talk and go through things.  perhaps
you could join a debian VM to my VPN [i have the setup scripted - it's
3 commands] and then i will be able to ssh in and get you set up.

 i'm taking a break from the 26th (next week) through to the 9th, i
will be on the tablet i/o board full-time so will have more time to
help you out.

 but i am *not* going to do pre-baked images.  you need to be
independent.  no, let me put that better.  *i* need *you* to feel that
you are independent of me for getting the software up and running, and
i need you to understand that this isn't just some random reason:
alarm bells are going off that you're not listening to and following
instructions.  we need to resolve exactly why, because if you get
something wrong because you didn't listen or didn't feel comfortable
listening to instructions you're going to blow something up.

 to illustrate that in hardware terms, it's as if i'm saying "you need
to read the datasheet for the LCD named 'eoma68-a20' and to create a
hardware circuit that properly respects the power-up sequence in the
datasheet for that very very specific LCD".... and you go off and
download the datasheet for the LCD named 'sunxi-3.4-cubieboard2', you
create a hardware circuit based around that which provides a totally
wrong voltage, totally wrong timings, it either blows up or doesn't
work...

 ... and rather than tell me *exactly* what it was that you did, you
tell me "the LCD's not working" - and when i ask "which LCD" you don't
answer the question!

can you appreciate that that would give me some concern, if it
happened more than not once or twice but *consistently*?

so.  to summarise, and set some rules (otherwise we're going to get into chaos):

1) you're almost there.  please keep going.

2) no images.  you don't need one (see 1); i would be doing you a
massive disservice to provide you one, and even if i did, the key
differences would be... absolutely miniscule.

3) please when i say "give absolute unambiguous answers" please reply
and clarify - don't avoid a *single* question.  answer them all.

4) until you've answered every single question that was asked (or
asked for further clarification) please don't raise any more issues in
the same message.

5) if you _do_ need to raise any further issues, please raise them as
a *separate* subject line so as to keep them out of the other thread.

6) send me your number off-list and we'll work out how to get you sorted.

l.