Re: [Arm-netbook] Ubuntu Computer Card

[mike.v...@gmail.com]

2016-08-05 7:44 GMT+02:00 KillerKink Goh :

>
>
> Any chance that there will be ubuntu-based computer card shipped as
> default?
>
> There is already debian/fedora based.
>
I Don't think so. Ubuntu is in no way FSF endorsable. Ubuntu has one-click
access to non-free drivers and apps or even automated.

Debian is already on the tipping point hence the "Practically Perfect" name.

But Since Debian is running, installing Ubuntu should be possible.

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

Re: [Arm-netbook] Ubuntu Computer Card

[mike.v...@gmail.com]

2016-08-05 8:37 GMT+02:00 Christian Kellermann :

> * KillerKink Goh  [160805 07:45]:
> > Any chance that there will be ubuntu-based computer card shipped as
> default?
> > There is already debian/fedora based.
>
> Hm, that would need a plethora of work atm. While there is an Ubuntu
> ARM system targeted at ARMv7+ architectures one would need to add a
> custom kernel package to it amonst other things. As noone has done so,
> you'd either have to do it yourself or look for someone doing it.
>

> This might be a lot of work or it might not, depending on the state of
> the Ubuntu ARM release.
>

http://linux-sunxi.org/Bootable_OS_images (none for EOMA-68 off course)
http://linux-sunxi.org/Build_Instructions_for_Ubuntu


>
> But I would not expect Luke to put in this effort at this stage, since
> there are a plethora of options available already, most respecting
> your freedom better than Ubuntu.
>

I think so too


>
> Kind regards,
>
> Christian
>
> --
> May you be peaceful, may you live in safety, may you be free from
> suffering, and may you live with ease.
>
> ___
> arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netb...@files.phcomp.co.uk
>
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] HDMI HEC on future boards

[mike.v...@gmail.com]

2016-09-07 21:38 GMT+02:00 Vincent Legoll :

> >  it just never occurred to me (it definitely should
> > have) that that would result in potential "lock-in".
>
> I don't buy into this, there's no lock-in to me. The user
> will fill his needs whatever the mean, either by using
> something provided (almost) freely by the SoC, or by
> buying additional HW.
>

I tend to agree. The EOMA Cards slides in only one way so it's very awkward
to have a receptacle utilizing both sides. Besides it would not receive
certification. The one item that still tingles my brain is
the physical limit to how far the user facing side may extend outwards, in
any direction. We have seen some fancy "bulbs" on pc-cards in the past.

For example:
http://pascal.hansotten.com/uploads/electronics/images/delockparallel.jpg

That one extends in all directions right out of the pc-card enclosure.
Might even block the ejector.

So do receptacles need a clearance around the slot or do cards need to stay
inside. And may a receptacle block the user facing side, for waterproofing
etc.


>
> So what can be argued is: will the few things added to
> every boards to provide the SoC specific functionalities
> be compensated by the things not needed for those who
> will get it anyways. That's a trade-of, additional price will
> also be a factor.
>
> But providing additional interface on the far end of the
> card is no philosophical problem to me. Especially for
> ubiquitous things like ethernet, I can't think of this being
> a locking-in feature. After all these boards are designed
> to have a long lifespan, so the need to upgrade is not as
> important.
>
> And if (and only if) a future upgrade does not provide it,
> then you always be able to switch to an USB one, if (and
> only if) you still need it...
>
> >  i always thought, y'know, things like HDMI would be ubiquitous /
> > common enough that you would always be able to find an upgraded
> > computer card with USB-OTG and HDMI: the impact of specialisation at
> > the *user-facing* end never hit my tiny brain :) huh.
>
> In my computer life I've seen 2 wired net techs (BNC & eth), whereas
> I've used 5 for display (VGA, BNC, DVI, HDMI, DP). I'm OK with USB
> because of its backward compatibility (I'm still not sure it will stay that
> way) So I'm not sure trying too hard to guess the future is mandated
> here, just being pragmatic. Which I can (and have) be(en) convinced
> EOMA68 is...
>
> But I'm convinced that providing as much of the SoC functionalities as
> pragmatically possible is better. Either by enabling more widespread
> adoption, or by avoiding the need for USB-based addons.
>

My guess is that the USB type C connector is probably going to be standard.
It's already got USB 2, 3, Power, DisplayPort, MHL,HDMI,Thunderbolt, Analog
audio and Ethernet is being discussed.

Still a single port can only issue a single mode at the same time at once,
power can be mixed. So multiple ports are needed if you need those things
in parallel. And it does need a capable switch tho pass everything output
to a single port.

I really hope that ethernet comes through on USB-C, RJ type connectors were
not meant to endure so many push and pull cycles and survive bags and other
cables.


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

Re: [Arm-netbook] brief update

[mike.v...@gmail.com]

2016-09-16 0:59 GMT+02:00 Luke Kenneth Casson Leighton :

> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>
>
> On Thu, Sep 15, 2016 at 3:38 PM, pelzflorian (Florian Pelz)
>  wrote:
> > On 09/15/2016 04:01 PM, Luke Kenneth Casson Leighton wrote:
> >>> I stuck S5P6818 in the search at http://elinux.org/ (nope) and
> http://rhombus-tech.net/ (yep). Looks like a 64 bit chip with no 64 bit
> support.
> >>
> >>  correct.  given that it can only address 2GB of RAM that really
> doesn't matter.
> >>
> >> l.
> >>
> >
> > What about virtual addressing / swap space? Then you may want more than
> > 2GB address space.
>
>  you do _not_ want to be using swap space on raw nand or even eMMC.
>

Well, Google has released statistical data on their SSD usage and it seems
that there is no correlation between number of writes and failure. It's
more dependent on 'age'.

But SSD are 'less' reliable than HDD because of bad cell and bad writes. So
error correction becomes more important.

http://www.zdnet.com/article/ssd-reliability-in-the-real-world-googles-experience/

Raw NAND access means you have to do the ECC. With and SSD that taken care
of by.firmware.

Now the 3.4 (Lichee)kernel from AW has, AFAICT, shady NAND support. And
mainline is growing, proper, NAND support.

Most bootloaders depend on fixed addresses region without ECC. So if the
boot region gets "bad" you're device is toast. A20 still boots from SD
though.

Still on low speed machines try to avoid swap to any medium. All will get
very slow; I/O contention. Memory usually has it's separate/private
bus/tracs/connection. The rest, Network, Sata, USB, GPIO, SPI etc. shares a
common bus.

So keep away from high profile desktops/compositors like Gnome and KDE on
low memory systems.

IOS and Andriod have very strict policies on apps to get exit the system if
not used to keep memory free for the active application.



> or USB-based external storage media.  in fact, you don't want to be
> using swap space at all... with the exception possibly of compswap
> (the much better version of zram, which linus torvalds refused to
> allow the full set of patches for, into the linux kernel).
>
> l.
>
> ___
> arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netb...@files.phcomp.co.uk
>
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] [Dev] [libreplanet-discuss] EOMA68 and freedom in digital technology

[mike.v...@gmail.com]

2016-09-14 12:34 GMT+02:00 Luke Kenneth Casson Leighton :

> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>
>
> On Wed, Sep 14, 2016 at 10:07 AM, Josh Branning
>  wrote:
>
> > Getting rid of boot0 is not far away:
> >
> > http://git.denx.de/?p=u-boot/u-boot-sunxi.git;a=tree;f=board/sunxi;h=
> 6419936f8b204d43c146ff5d8c88d1b0484fdcae;hb=refs/heads/next


Can't reply to josh directly.

There are two problems. 1st a legal one 2nd a technical. The technical one
is being resolved by the community. With little help from Allwinner. I say
a "little help" not "no help". When A64 is bootable by uboot then it might
by a possible EOMA68 target, from firmware perspective.

AFAIK:

The early boot loader in AW SOC's is BROM: http://linux-sunxi.org/BROM. It
built in on production and cannot be modified, hence ROM: Read Only Memory.
The ROM can be read however. The BROM is the first software loaded in the
chain. Currently it can load the AW Boot0 or U-Boot SPL.

After Boot0 comes Boot1. After U-Boot SPL comes U-Boot.

boot1 is a AW modified U-Boot.

So if i'm correct there is a for stage boot sequence.
1. BROM (Find and start bootable software)
2. Boot0/U-Boot SPL (Init Hardware like memory, uart, clocks, regulators
then load the next stage)
3. Boot1/U-Boot (Init perhipials and load the final stage: Linux)
4. Linux

The SoC have a tiny bit embedded RAM (SRAM). Just large enough for boot0 os
U-Boot SPL which init's the external RAM (DRAM) and load the next boot
stage to is and starts it.

The legal problem is different. And the cannot, easily,  be fixed
afterwards. AW has sold/is selling SoC's including binary, modified, copies
of GPL software. U-Boot (boot1), FFMpeg(cedar) and few other.

While in China this is not a big, legal, problem. In most other countries
this is plain illegal.

So if I were to buy hardware from AW along with the software they provided
and resell it I would be making three violations.
1. Selling illegal software
2. Buying illegal software
3. Helping another parties sell illegal software

And anyone reselling my products would face the same issues

And once done it cannot be undone, damage has been done. But as long as
nobody complains I can keep doing it. That's the way the world works. But
it still would put me at risk of prosecution, import blokkades, etc.

Every country weighs violations differently. In some countries I would be
part of criminal cartel, not very hard to imagine.

I can try to rectify and publish afterwards. But I can still be held
accountable for damage done.

I can try sending out replacement software "stripped" of the GPL violation
stuff. But I can still be held accountable for damage done.

I can try sending out replacement software masking the GPL violation stuff.
But I can still be held accountable for damage done and being done.

When I'm reselling I don't have any of the options above. I can only hope
AW wil help me. But as they already have my money I'm of little interest i
guess. I could spend a lot of time and money to rectify it myself, but as
you can see with the sunxi community that probably be too slow and
expensive. But for Allwinner it would be almost cost-less to do.

GPL software is free but comes with some, legally binding, restrictions.
When your not abiding those restrictions you are violating a legal
contract. Hence the illegal software. Contracts do not always require
signatures. Contracts are a formal agreement of terms.

Look at Oracle, Samsung, Google, SCO, etc. They have done all of the above.
And now they are 'actively' changing their ways. But they are big enough to
stall. SCO tried and died. It's never pretty.

Luke's EOMA68-A20 is something unheard of. Buying hardware without SDK and
probably support. And selling it with a totally free stack of software and
firmware.

That and no co-processors which can work independently from your system to
help/spy/corrupt you.

The only exception is the BROM. But that can/should be considered hardware
as it cannot be changed and is build-in. Plus the bonus that it can be read
and verified.


>
>  i'm not sure why you're referencing this, josh - it
>
> > I'm sure, and there is some evidence that Olimex puts pressure as it is
> on
> > Allwinner to release their code and stop ignoring GPL licensing
> conditions.
>
>  you'll need to be more specific.
>
> > You say Olimex made a GPL-violation and then basically made the fool of
> you
> > 'in-front of 20,000 people', but they seem otherwise. [1]
>
>  you'll need to reference archive.org to find the conversation.
> tsvetan's disdain is very very clear.  and he also, just as clearly,
> doesn't actually answer the question.
>
>
> > According to them, you were complaining that they hadn't released the
> source
> > early enough, because they hadn't written a tutorial of how to build as
> soon
> > as they released the images.
>
>  i don't believe it (but i could be wrong - i often am).  allwinner
> hadn't actually released the source of the pr

Re: [Arm-netbook] Batteries and materials (was Re: Code of conduct?)

[mike.v...@gmail.com]

2016-09-21 3:47 GMT+02:00 Luke Kenneth Casson Leighton :

> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>
>
> On Tue, Sep 20, 2016 at 1:47 PM, Paul Boddie  wrote:
>
> > I don't really want to weigh in on a topic that I don't have any specific
> > interest or expertise in, but my impression was (Musk aside) that nobody
> > really expects battery technology to stick with lithium or "rare earths".
>

Musk's take of the cut, drivers others to find alternatives.


> > Here, progress in materials science appears to be driving development
> towards
> > more mundane materials.
>
>  that just leaves copper.  if there existed a room-temperature
> flexible superconductor replacement we'd do okay.
>

We're getting there:
https://upload.wikimedia.org/wikipedia/commons/b/bb/Timeline_of_Superconductivity_from_1900_to_2015.svg

http://phys.org/news/2016-02-graphene-superconductiveelectrons-mass-resistance.html

But it'll take a while before production. But the higher the demands on
batteries and semiconductors. The harder the search for alternatives.

All semiconductor companies have serious trouble further miniaturizing
silicon lithography. If we find ways to reduce resistance in the materials
than the miniaturization becomes less of an issue.


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

Re: [Arm-netbook] EOMA68 R/Evolution bumper sticker

[mike.v...@gmail.com]

2016-09-21 5:14 GMT+02:00 Luke Kenneth Casson Leighton :

> ok apologies i haven't much time/energy to deal with this one, so am
> asking a huge favour / volunteer to recreate the prototype bumper
> sticker that i put together.  ideally it should be an SVG.


Picture/Resource please. And what licence would you like it to have?


> this is
> from chris:
>
> I've used this site for bumper stickers before and liked them (the
> people behind it have a freedom-oriented slant too which is neat):
>
> https://thebumpersticker.com/shop/stickers/vinyl-stickers/
>
> I would suggest the following:
>
> Material: White Vinyl
> Shape: Rectangle
> Height: 3 inches
> Width: 9 inches
>
> now, i'd very much like to add some words at the top just above the
> main image: "It's R/Evolution, baby" or something equally ridiculous.
> any suggestions welcome - the more ridiculous or cheesy the better.
> nothing crude or derogatory!
>
> l.
>
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>
> ___
> arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netb...@files.phcomp.co.uk
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] EOMA Specification / Documentation Issues

[mike.v...@gmail.com]

2016-09-24 5:27 GMT+02:00 Luke Kenneth Casson Leighton :



>
>
> > Let's switch to the Pocket QWERTY Computer as an example instead of
> router. The A20 cpu card ships with Parabola, a desktop/workstation style
> OS. I want my customers to have a good experience when they use my handheld
> housing. Using an OS tailored for desktop/workstation computing is *not* a
> good experience on a small screen (I've tried this with the Zipit and it
> "worked", but was not very productive). I can make this transition even
> *easier* for average consumer by supplying a SD card with Replicant or some
> other custom libre distribution designed for small screens.
>
> or, you could supply multiple OS SD cards for them, and set up the
> NAND to look an OS on the A20's MicroSD Card slot.
>
> yes, i'm keenly aware that the alteration of the OS to suit LCD size
> is a Big Deal.  putting it another way: it's a PAIN IN THE ASS! :)
>
> it's made even more complicated (for the A20) by the fact that the
> people who did the sunxi u-boot and mainline kernel didn't think about
> this in advance: they've specified that the LCD shall be set up by
> u-boot and u-boot alone, leaving absolutely no possibility for
> changing the LCD size without a total reboot!  oops...
>

Not quite sure that is the case. U-Boot provides "early" setup, regulator
and clocks etc., for u-boot output. SimpleFB takes over the settings from
U-Boot (via u-boot modified device-tree). But a proper KMS/DRM driver
(sunxi has something working for A13, H3, A33) may change all that. Too bad
that libv got burned and refused to release his work.
https://lkml.org/lkml/2015/10/30/358
http://linux-sunxi.org/Linux_mainlining_effort

So yeah for SimpleFB you're bound to change the display settings in advance
of a (re)boot. To the specific device. With proper KMS not.

Which leads to the EOMA68 minimum allowed display resolution should be set
in U-Boot.



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

Re: [Arm-netbook] EOMA Specification / Documentation Issues

[mike.v...@gmail.com]

2016-10-02 10:03 GMT+02:00 Vincent Legoll :

> Hello,
>
> On Tue, Sep 27, 2016 at 4:55 PM, mike.v...@gmail.com
>  wrote:
> > Not quite sure that is the case. U-Boot provides "early" setup, regulator
> > and clocks etc., for u-boot output. SimpleFB takes over the settings from
> > U-Boot (via u-boot modified device-tree). But a proper KMS/DRM driver
> (sunxi
> > has something working for A13, H3, A33) may change all that.
>
> There are problems with the H3 (& variants) display driver, on the
> HDMI output front,
> as seen on : http://linux-sunxi.org/GPL_Violations
>
> Currently the driver cannot be mainlained as-is.
>

Bear in mind that page is regarding the code in the "Allwinner (Lichee)"
kernel. This does not reflect the code made by the sunxi community to
enable graphics output on mainline.

Besides the code from Allwinner, even with the proper licencing, is not
mainline material. Very quick and dirty code and hacks.

H3 support is mostly hindered by availability and interest.


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

Re: [Arm-netbook] Some Pine64 Experiences (via Planet Debian)

[mike.v...@gmail.com]

2016-10-12 4:54 GMT+02:00 Luke Kenneth Casson Leighton :

> On 10/11/16, Wookey  wrote:
> > On 2016-10-11 19:11 +0200, Paul Boddie wrote:
>
> > I don't really know about the pine people specifically, but having
> > recently met with a guy from Allwinner (who is paying Luke to educate
> > his engineers :-)
>
> correction / misunderstanding: he's not.
>
> > They have noticed the persistent bad press/poor reputation and have
> > understood that what geeks think does actually matter in the long
> > term, as does upstreaming.
>
> well, it's about to get a hell of a lot worse.  i flew 20,000 miles
> round the world, was invited here to speak with their engineers, help
> them out, set up a FusionForge for them, make it possible for them to
> present the R-Series processors to open hardware and software libre
> people across the world, even present the idea of using RISC-V and
> Nyuzi 3D for a future processor...
>
> ... and i learn the day after that from being on their premises for
> only five hours i've been accused of being here to commit industrial
> espionage, to steal their proprietary source code.
>

I bet you wished you met them on neutral ground. Someone there is got very
antsy with your arrival on their turf.

Like Frank Herbert wrote "Show me a completely smooth operation and I'll
show you someone who's covering mistakes. Real boats rock."

An you just got bitten by the one covering mistakes.


>
> now, from 20 years experience i know that i cannot work with engineers
> who do not welcome what i have to say or contribute.  in this case i
> cannot even be in the building because there is the opportunity that
> if someone else *does* actually commit industrial espionage, they
> might accuse *me* - and the person who invited me into the building -
> of being the one that stole the code.
>
> this from the company that's been stealing software libre source and
> profiting with complete disregard or respect for the people whose work
> they critically rely on.
>
> i'm really upset.
>
> i'll be leaving zhuhai either today or tomorrow.
>
> if they apologise i'll come back.
>

I hope they do but I doubt they will (be able to). Luckily the A20 is
available on the open market. But I guess some suppliers will be steered.

Good luck. And don't forget to breathe.


>
> irony is that i need somewhere to live for myself and my family, and
> zhuhai looks like it's the best place to be.
>
> l.
>
> ___
> arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netb...@files.phcomp.co.uk
>
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

[Arm-netbook] Opensouce TPM

[mike.v...@gmail.com]

Interesting:
http://phoronix.com/scan.php?page=news_item&px=Google-Building-OSS-TPM2
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] new development laptop needed, looking at dell xps 13 9350

[mike.v...@gmail.com]

2016-12-04 12:15 GMT+01:00 Luke Kenneth Casson Leighton :

>
> * 2560x1600 or greater resolution LCD (CAD development)
> * 13in size (has to fit in my backpack)
> * below 1.5kg weight (carryable)
> * 16GB of RAM (i'm maxing out the 8GB)
> * 512GB SSD (i've maxed out the 256GB drive)
> * cooperative manufacturer that hasn't caved in to microsoft
> cartelling business practices
>

That's  a pretty short list for those specs:
https://tweakers.net/categorie/496/laptops/producten/#filter:RY1BCoMwEEXvMmsrk8QYzQGELrpyWboIGkqKVkmklEru3pkW2tVjHv__2WGJo49d8NMIFtYYbgmKr-yXuJFzafiZ1Q9Hyh1EAau7-j68PFiBWHBz8KdwB0tHolwXps3HBHYHVUlkPtwE9gxSGKTFWrYNQTZaEZQyLcMoQTCqrRhoFFwyaTSfhZkfgEBZIbDWovlrLGXNrdk9OVRqCTnnNw

Dismissed M$ stamp, that was not a selectable option ;-)

i looked at the lenovo yoga 900: zowee, lenovo are unethical.  they've
> locked the BIOS so that you can't switch the NVMe SSD out of RAID mode
> (so you can't even install windows from a windows CD), they've refused
> refunds to people who claim mis-selling, they're ACTIVELY working to
> release new BIOS updates that prevent and prohibit people from
> installing linux, and they're scrambling to constantly censor reports
> and complaints on their forum.
>

I Thought that issue was only for the "Signature" certified ones and they
already caved to the shitstorm.

http://mjg59.dreamwidth.org/44694.html

http://support.lenovo.com/se/nl/products/Laptops-and-netbooks/Yoga-Series/yoga-900-13isk2/downloads/DS119354

However Lenovo's direction is clearly becoming that of selling machine.
Whitout regard of what happens after sale. They've bough Motorola in hopes
to copy the succes recipe but their own rotten mobile department killed it
instantly.

My view on the succes of motorola: Bugetphone's with high enoug spec's and
updates! Now: Pricey phones with not enough specs to rival the rest in
price range and zero updates or very tardy.

You are not done with a product once it has left the store. When a product
leaves that store it becomes a showcase for your company. And that can be
good or bad!

And a good customer support does not fix that.


>
> i also looked at the asus zenbook: fantastic machine except the
> 13in variant peaks at 12GB of RAM.
>
> sony... have stopped doing laptops!  that's the end of an era: i'm
> amazed...
>
> now, before i go spending $USD 1500 of crowd-funding money (which is
> easily justifiable as it's absolutely essential that i have a working
> machine and a half-decent backup) i'd like to double-check with people
> if they know of anything better than the XPS 9350, both in terms of
> specification as well as support for the linux community from the
> manufacturer.  dell appear to be cooperating, releasing BIOS updates
> that *actively* help linux users (as opposed to lenovo who do the
> complete opposite and then try to hide the fact, generally being
> incredibly evasive and unethical).
>
> thoughts and suggestions appreciated for evaluation.  the 9350's at
> the top of the list right now.
>
> l.
>
> ___
> arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netb...@files.phcomp.co.uk
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] new development laptop needed, looking at dell xps 13 9350

[mike.v...@gmail.com]

2016-12-05 11:55 GMT+01:00 Luke Kenneth Casson Leighton :

> *sigh* argh i can just feel that, after thinking it through, 16GB
> simply isn't going to be enough, long-term.
>

How about using a lighter/smaller laptop and a "mini" desktop as a server,
SSH/VNC. Like an Intel NUC

Asus ZenBook UX305CA-FB649T

(13,3"
(3200x1800 IPS), 128GB (ssd), 1,2kg, €699)
Shuttle XPC Nano NC02U
 (Max
32GiB Ram, Intel Celeron 3855U, 0.4 kg, €129,-)


Small desktops capable of at least 32GiB RAM
https://tweakers.net/categorie/713/pcs/producten/#filter:PYuxCsIwFEX_5c4RkqbVkg8oODh1FIeQPuRJtOGlOFjy7yYITpd7OGfHKgvJxBQXOCThR4b6wXmVrTKfw58kCufqHYxC8nea-UNwRmvVykAXfsHVk6s3cdxIMtwOM-q-7dtHuCuGwVrcikJvO934s2Ww3ek4opTyBQ

https://tweakers.net/categorie/326/barebones/producten/#filter:PYxNCsIwFITvMusISdTG5gAFF656gpA-JNLa8NKFWHJ3XxC6Guabnx0rT8RDonmCR-b0KlB_OK68CQslHiRTvEvvZBRyeNKYvgRvtFZtGemR3vBiivSGNG_EBX7HxfW66dJinK3rbvK4hI84q3tnrha11h8

Laptops with adquate screen resolution:
https://tweakers.net/categorie/496/laptops/producten/#filter:PY3LCoMwEEX_Zdap5KVRP0DooiuXxUWIQ0mJVRIppZJ_7wShq8Oce2fmgDXOGAePYYYetuifCdgpxzXu5Gxyf7Ohu1LvIhhs9oGj_yL0gnNWNh3e_At6GhIGdDvOZz9Bf1e1aJnW0kyUkh182DFScoDSkhe-baAiSGE4_Wtk1xJkWyuCUqYrMEoQjOp0ATcKpkyajpcLS3kPvJJNiRf7oUlUtYCc8w8

P.S. Look at ram compression. Browsers are quite bloated in RAM usage these
days.



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

Re: [Arm-netbook] new development laptop needed, looking at dell xps 13 9350

[mike.v...@gmail.com]

2016-12-05 13:55 GMT+01:00 Luke Kenneth Casson Leighton :

> On 12/5/16, mike.v...@gmail.com  wrote:
> > 2016-12-05 11:55 GMT+01:00 Luke Kenneth Casson Leighton :
> > How about using a lighter/smaller laptop and a "mini" desktop as a
> server,
> > SSH/VNC. Like an Intel NUC
>
>  nice idea... can't do it.  remember, i would have to carry the mini
> desktop as a server, plus its power supply, plus network cables, in my
> backpack, setting it up at the factory, or at a client, or at a hotel,
> or a supplier, every single time.
>
>  plus, openscad, which is heavy on the 3D OpenGL side, simply wouldn't
> work over X11
>

1. Cables; Buy a beefier adapter and fit it with two ends, one for the
laptop and one for the desktop. Might not work for Dell etc beacause of
their 1-wire protocol [1]. Use wireless between the laptop and desktop.
They're close together. Most Wifi cards can do AP and Client simultaneously
sap laptop in dual mode and desktop in client. But bring a cable just in
case...

2. Remte access; Don't do X11, do VNC or RDP. Or use a hdmi/dvi grabber. If
you need X11 use SSH compression. Works wonders!. I'm used to narrow lines
and old Unix systems and SSH compression saves the day. Most cpu's even
have compression processors to do the heavy lifting.

It's a little more work to set up but more versatile and replaceable. Most
32GiB Laptops are huge, heavy and expensive and drain a lot of battery
fast. I gather from your response CPU is not the issue RAM is. Those
"Mobile workstations" have consuming but faster CPU's.

This setup allows you to run browsers/presentations on your laptop and your
workflow on the desktop. Gaining extra RAM! Laptop+Deskop.

But do what you feel is best and give you the most productive environment.

This is bootstrapping the EOMA. You don't produce cars with cars. Those are
produced with factories and trucks etc. This laptop is your factory.

To bad most software doesn't scale out and run on ARM ABI's. Then a cluster
of EOMA's could do the trick ;-)

[1]
http://hackaday.com/2014/03/03/hacking-dell-laptop-charger-identification/
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] new development laptop needed, looking at dell xps 13 9350

[mike.v...@gmail.com]

2016-12-07 10:56 GMT+01:00 Michael Howard :

> On 07/12/2016 09:07, Philip Hands wrote:
>
>> If everyone that doesn't like systemd runs screaming away from Debian,
>> shouting about libsystemd0, and doesn't bother to report bugs where our
>> ambition to support other inits falls short, then they just ensure that
>> the future they fear comes to pass.
>>
>> Wow, that last paragraph is the height of arrogance. Choice, long may it
> live.


I fail to see the arrogance in that paragraph. That's a simple cause and
effect. If you don't point out an issue, nothing can be done about it.
Simple logic to me. If enough issues are unreported things simply become
unusable. This relates to every sense of community.

Since we're dealing with shared code, most of the issues in Debian occur in
other distro's as well.

Since debian usually holds "older" versions. Frequently a backport fix is
needed to fix the issue. But maintainers need to know abaout the issue
first.

And I didn't read that Phil says you're not allowed to choose differently.
Merley the consequence of the choice not reporting your issue, before
leaving, has future consequences.


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

Re: [Arm-netbook] new development laptop needed, looking at dell xps 13 9350

[mike.v...@gmail.com]

2016-12-08 16:08 GMT+01:00 Adam Van Ymeren :

> On Thu, Dec 8, 2016 at 7:41 AM, Tzafrir Cohen 
> wrote:
> > On Wed, Dec 07, 2016 at 04:49:36PM +0100, Ythogtha wrote:
> >
> >>   I'm new on this list, so hello everybody :)
> >>
> >> If I may make a small remark...
> >> I feel that somehow, having a library installed only to know wether
> some other
> >> software is present or not feels the wrong way to do things.
> >
> > I don't have SELinux enabled on my system. Still many core components on
> > my system are linked with libselinux.so.1. Will you fork Debian to
> > patch out the SELinux support?
>
> I don't see libselinux.so.1 on my debian system.
>

I'd like to suggest, not demand, to move this discussion/quest/...
somewhere else. It is no longer about the original discussion nor about
linux/arm, arm-netbooks, eoma68. And it keeps demanding time from our
friend Luke. Who is more than busy with changing the world ;-)


>
> >
> > What is the actual overhead?
> >
> > libsystemd0 takes 646kb of disk space. It adds a negligible amount of
> > memory and run time (for the case of not using systemd).
>
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] Opensouce TPM

[mike.v...@gmail.com]

2016-11-23 18:21 GMT+01:00 Denis 'GNUtoo' Carikli :

> On Thu, 3 Nov 2016 10:28:22 +
> Luke Kenneth Casson Leighton  wrote:
>
> > On 11/3/16, mike.v...@gmail.com  wrote:
> > > Interesting:
> > > http://phoronix.com/scan.php?page=news_item&px=Google-
> Building-OSS-TPM2
> >
> >  yeah, very.  means they no longer trust third party proprietary TPM
> > implementations, which is in and of itself all we really need to know.
> There isn't only that. You also need to force the hardware to use the
> TPM. ChromeOS probably already does that.
>
> Using an ME to do that is not compatible with freedom.
> When there is no ME, BIOSes and UEFI typically set the bootblock
> read-only and have code in there to start using the TPM.
> Otherwise there is no way to prevent a malicious user to replay a good
> boot to the TPM while a totally different boot software was used.
>
> There are patches for flashrom that are being reviewd AFAIK for adding
> the ability to set flash zones read-only.
> Note that "read-only" can have different meaning:
> - The zone can be forever read-only
> - The zone can be read-only if the write protect pin of the flash is
>   grounded.
> - The zone can be read-only until the next boot or reboot.
>
> On x86 hardware, the chipset can also be programmed to do make zones
> of the boot flash read-only until the next boot.
>
> AFAIK chromeOS uses the flash read-only features to do it, while
> typicall BIOS/UEFI uses the chipset's read-only features or the ME.
>
> >  now let's see if they create an SSD with full firmware source code
> > available.  the first low-cost SoC with on-board RAM, ability to
> > connect to multiple eMMC ICs and a USB3-OTG would do the job.
> They probably don't trust SSD and most storage device either.
>
> Given that:
> - Most storage devices (HDD,SSD,USB keys, SD, microSD, etc) have
>   non-free firmwares.
> - GNU/Linux probably trust storage devices by default. Storage devices
>   could easily detect (by looking at the access pattern) what
>   program/os is accesing a given file. That probably leads to TOCTOU
>   attacks.
> - The boot flash(which has libreboot/coreboot/The BIOS/UEFI/etc) has no
>   firmware so far. As far as I know it's only hardware.
>
> You don't have many options left if you want to avoid such attacks.
> ChromeOS chose to verify the kernel+(initramfs?) from code that is
> running from the boot flash and then to use dm-verity for the
> filesystem.
>

Probably nothing on the open market. EOMA68 comes close. But does not have
tamper protection. It does however give to option to verify every aspect.
Making it tamper protected would make this even harder exercise even more
difficult.

The issue is that we work with complex systems. There is no longer one
single CPU. A lot of parts are timing sensitive and are general purpose,
power management, communication. Even within the SoC. The cheap solution is
to use general purpose microcontrollers are used opposed to build logic
systems from ground up. Building logic systems is expensive and time
consuming. Writing software is fast(er) and cheap(er).

Every microcontroller is a "computer" on it's own. And thus an attack
vector.

Attack vectors for EOMA68-A20 that I see:
1. Microcontrollers in every USB connector. (But that's an vector for all
systems)
2. A20 has a RISC cpu inside for power management purposes. Not used by
currently iirc. But not checked either.
3. The PMIC is an Microcontroller with firmware
4. The housing has a ARM microcontroller. Which runs it's own RTOS.
5. Audio attacks on the sound stack

The list for Intel machines is miles longer though and more profitable.
Which is a large item in assessing the risk


>
> A fully encrypted rootfs (no /boot in clear) is also a possible way to
> workaround such issue. Libreboot (trough GRUB) can support such thing.
>
> At the end of the day it's still a pain because you also need to wory
> about protecting the device at installation time...
>
> I'm working on a script[2] that build an image with the following
> softaware to address the issue:
> - Coreboot
> - SeaBIOS and iPXE
> - GRUB
>

Hi Dennis, you're being a bit too vague here. If I understand correctly you
are trying to build a installation verification tool?


>
> It fetches a GNU/Linux distribution kernel and initramfs (used in
> netinstall images) in the computer RAM and then computes the checksums.
> It's then up to the user to boot the images or not, to verify that
> the checksums are the ones expected.
>
> So far I've been able to bootstrap debian from it but I've still some
> issues to fix:
> - Debian is not FSDG compliant. Parabola and 

Re: [Arm-netbook] Warning about tablets/netbooks with detachable keyboards

[mike.v...@gmail.com]

2016-12-17 16:13 GMT+01:00 
>
>
>The "ThinkPad"-series had (or has) convertibles ("X41 Tablet", "X60
> Tablet, Helix) [1].
>(By the way, the X60-convertible is listed as supported by "libreboot"
> [2].)
>This line of computers seems to have been distinctively-sturdy.  And
> the X60-convertible was said to have "signature ~ bulletproof build
> quality" and be "more ~ sturdy than any ultralight convertible we have
> used." [3].
>So maybe how they JOINed the key-board to the screen, was more sturdy
> than other often-problematic "implementations".  (But I have neither seen
> nor read HOW Lenovo connected the two parts.)
>As far as I see, there are two separate concerns- (1) the
> data-connection (USB here, I guess Luke wrote) (the concern of the original
> post), and (2) how the screen and the key-board are held (joined) together
> (a 2nd thing discussed in this context, like the arms mentioned above).
>

The X41 and X60 do not have detachable screens. The screens are on a hinge.
The hinge is propriety hardware produced in 'small' volumes. Tailor made
for these laptops.

The Helix is detachable probably uses a tailor made connector produced in
'small' volumes.

By small I mean a big volume enough for production of the
laptops/convertables/tablets and some stock as replacement parts or batch
filling.

The EOMA products are based on "ominous parts". Parts not made for specific
products but used in many. Luke recently found that one selected part did
not meet that criteria and had to change the PCB to fit a more ominously
available part.

This makes it the "EOMA" products sustainable and relatively cheap.

The are a few options as far as I see.

1. Magnetic connectors, like the now dropped apple mag-safe(tm) connector.
It might work as there are "Chinese" knockoffs for micro-usb. But power
only.
2. "Pogo pins" with, neodymium, magnets to snap them to the right place.
Doable but needs testing and probably a few iterations for reliability if
even possible.
3. Dell, Lenovo or HP docking station connectors. Probably widely available
as long as Dell, Lenovo or HP sticks with their format.
4. A 14/15 inch EOMA-68 tablet with a keyboard/battery "dock" connected via
USB cable to the "tablet"

But the current connectors used by the "big" manufacturers are product
specific and quite expensive for low volume production and not sustainable.



>
>[1] https://en.wikipedia.org/wiki/ThinkPad_X_Series
> if you press ctrl f and look for "conver"
>[2] https://libreboot.org/docs/hcl/index.html#supported_laptops_
> x86intel
>[3] http://www.laptopmag.com/reviews/laptops/lenovo-thinkpad-x60-tablet
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] Laptop Housing Questions

[mike.v...@gmail.com]

2016-12-19 22:56 GMT+01:00 Luke Kenneth Casson Leighton :

> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>
>
> On Mon, Dec 19, 2016 at 9:45 PM, Jonathan Frederickson
>  wrote:
> > Hey, I have a few questions about the laptop housing.
> >
> > - How does one connect it to power?
>
>  standard DC jack, anywhere between 7 and 19v.
>

I've never found a standard DC jack ;-). I presume a "dognut" type plug? If
so, of what dimensions and which polarity or does it have a polarity
switcher or at least a polarity safety?

I think the USB-C connector is going to be the first "standard" "universal"
charging connector. Standard USB-C cable should be able to provide 60W
(20V*3A) and power cables 100W (20V*5A). But not "ominous" enough yet.


> > Can it be powered over USB
>
>  powered no, charged, yes.  current limit on the OTG port.
>

Well if the input minimum is 7V than neither.

But if I understood correctly the EOMA-68 card accepts power over the OTG
port and passes through, any surplus, to the housing. Thus slowing down the
battery drainage of the housing(laptop/tablet). And charging, although
slow, when the housing is turned off. And a little faster when both,
housing and card, are turned off.

Standard USB only delivers 5V*500mA= 2.5W. But various options are allowed
apparently. https://en.wikipedia.org/wiki/USB#Power


>
> >  or does
> > it require a specific AC adapter?
>
>  no.  min 4A is best, but if you're prepared to reprogram the
> STM32F072 yourself you could get away with less
>

4A on the output side I presume so 19v*4A=76W, So a 95W power supply with
80% efficiency (90*80%=76). Or 85W at 90%.


>
> > I have a portable solar array with a
> > battery pack that can charge portable devices over USB, and I'm trying
> > to work out whether or not I'll be able to power the laptop from it.
>

If it has 12v out that would be your best bet I guess.
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] Laptop Housing Questions

[mike.v...@gmail.com]

2016-12-20 14:27 GMT+01:00 Julie Marchant :

> This is a bit off-topic, but I think you're confusing "ominous" with
> "ubiquitous". "Ominous" means it foreshadows evil, or otherwise exhibits
> a bad omen.
>
> https://www.merriam-webster.com/dictionary/ominous
>
> I stand corrected. Thank you.


> If anything, the only connectors that are ominous are the proprietary ones!
>

Indeed


>
> --
> Julie Marchant
> https://onpon4.github.io
>
> Protect your emails with GnuPG:
> https://emailselfdefense.fsf.org
>
> ___
> arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netb...@files.phcomp.co.uk
>
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] Intel at CES

[mike.v...@gmail.com]

2017-01-09 0:08 GMT+01:00 peter green :

> On 08/01/17 12:58, Luke Kenneth Casson Leighton wrote:
>
>> On Thu, Jan 5, 2017 at 9:24 PM, Luke Kenneth Casson Leighton
>>  wrote:
>>
>>   i'm not letting you off the hook here after you said that EOMA68's
>>> interfaces are "crippled", peter.
>>>
>> ok, so can you see what i did, peter?  you laid down a challenge (to
>> do better)... and after three days, you've not responded.  you
>> *provisionally* described an alternative standard... but did not
>> follow through.
>>
>>   *that's* what makes the difference, here.  it's *not enough* to say
>> "the standard you came up with is rubbish", you have to *follow
>> through*, and if you can't follow through then it's you know what
>> i'm trying to say?
>>
> The compromises you made are a result of your goals. You wanted a standard
> that could be implemented with virtually any cheap SoC. That basically
> forced you into the decisions to use USB and parallel RGB.
>
> Unfortunately USB has a reputation for poor performance and reliability.
> Some of this is possibly the fault of the USB standards themselves, some is
> a result of crappy implementations.
>

Examples please.

If USB had such a bad track record then why is it the most used peripheral
interface?

And which part of the USB standard? The physical interface or the
communication protocols?


>
> Intel has different goals, their job is to make something that takes best
> advantage of their own current and future products. EOMA68 does not do
> that, it drags it down to the lowest common denominator. As such I believe
> that by adopting EOMA68 Intel would be crippling their product. I gave some
> examples of interfaces I think Intel should include that were unsuitable
> for EOMA68.
>

The lowest common denominator is what's going to get this running. Everyone
can join in with almost everything. You could even create a EOMA Card with
a beefy Microcontroller.

Once everyone is in, new interfaces can be chosen/developed for the next
version/type.


>
> I don't know exactly what Interfaces it would be best for Intel to
> include, that would require knowing both full details of the chips they
> plan to use in their current cards as well as their future roadmaps (if
> they have something on their SoCs today but plan to drop it in the future
> it would be stupid for them to put it on their compute cards).


Intel could force a "new" standard by flooding or hyping the market. That
would require every other vendor to follow the Intel route.

For other company's to follow that usually comes in two tracks:
1. Intel has made a success en the they "chime" in on the succes
2. Intel actively recruits "partners" to co-develop products

But I don't think so. Intel is desperate to find new grounds and are
shooting with hail. It'll surprise me if they are still around after ten
years.

1. Desktop and Laptop markets are shrinking.
2. Server market is shifting to better Power/Watt ratios. ARM is gaing. The
market is opening again to other CPU architectures becaus of Saas offerings.
3. Computing market is shifting to GPU's.
4. Intel failed at the mobile market. To power hungry/To late.
5. Intel failed at the IoT market. To power hungry/To late.




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

Re: [Arm-netbook] Another laptop project: PINEBOOK

[mike.v...@gmail.com]

2017-01-12 14:09 GMT+01:00 Luke Kenneth Casson Leighton :

>
> On Thu, Jan 12, 2017 at 1:02 PM, David Boddie  wrote:
>
> > It's clearly not comparable to the EOMA68 laptop because it lacks the
> > modularity, and is obviously not as flexible as a result, and it's fairly
> > limited in terms of the interfaces and expansion options it offers.
>
>  and uses a processor which cannot be brought up without a proprietary
> binary-only bootloader, yippeee!
>
> Is an Allwinner A64 SoC. The linux-sunxi community is almost done with a
open boot0/1 replacement:

https://groups.google.com/forum/#!topic/linux-sunxi/XQGd7O-ZhWo

The thing that bugs me the most is the 2GiB limit.

Currently it's more capable than my "poulsbo", Dell inspiron mini 1010,
netbook.
1. KMS drivers.
2. Motion video codec acceleration. http://linux-sunxi.org/Cedrus
3. Small hopes for open 2D/3D drivers. http://limadriver.org
4. Better price.
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] The dream of Ara

[mike.v...@gmail.com]

2017-01-13 4:56 GMT+01:00 Luke Kenneth Casson Leighton :

> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>
>
> On Thu, Jan 12, 2017 at 8:13 PM, Wolfgang Romey 
> wrote:
> > I think my FairPhone 2, which I own for a month, is some kind of a
> modular
> > smartphone.
>
>  it's not: they lied.
>

If they're intentions were honest it's not a lie. It's just being naive.

But all most parts are, user, replaceable. Which indeed does not make it
modular, but serviceable.

If there is a true lie, I'd like to hear about it.


>
> > I use it with the FairPhone Open Os, which is Google free. Of
> > course I could root it without problems. I know (luke) that it is not
> real
> > free hardware and comes with blobs.
>
>  you mean, "it comes with software from one of THE most unethical
> companies in the world that is undergoing court cases for
> anti-competitive practices


That's true for most companies. BTW which company are we talking about.
Farphone1: Mediatek SoC
Faiphone2: Quallcomm snapdragon SoC

, where we KNOW that they just roll over and
> give direct access, through their OS, *AT RUNTIME*, to allow arbitrary
> code-execution OVER THE AIR without your knowledge, EVEN IF THE DEVICE
> IS POWERED DOWN?"
>

Which is true for every GSM modem and SIM card, mandated by the GSM network
operators and probably, directly or indirectly, some government agency's.

The biggest issue is that they've tied the modem and SIM directly to the
rest of the system. It's a cheap decision. Which most manufactures have
done unfortunately. [1]

[1]http://neo900.org/news/about-the-asn1-vulnerability
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] The dream of Ara

[mike.v...@gmail.com]

2017-01-13 9:11 GMT+01:00 Luke Kenneth Casson Leighton :

> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>
>
> On Fri, Jan 13, 2017 at 7:55 AM, mike.v...@gmail.com
>  wrote:
> > 2017-01-13 4:56 GMT+01:00 Luke Kenneth Casson Leighton :
> >>
> >> ---
> >> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> >>
> >>
> >> On Thu, Jan 12, 2017 at 8:13 PM, Wolfgang Romey 
> >> wrote:
> >> > I think my FairPhone 2, which I own for a month, is some kind of a
> >> > modular
> >> > smartphone.
> >>
> >>  it's not: they lied.
> >
> >
> > If they're intentions were honest it's not a lie. It's just being naive.
>
>  no, it's called lying.  or, at best, deceptive marketing.
>
> > But all most parts are, user, replaceable. Which indeed does not make it
> > modular, but serviceable.
>
>  correct.
>
>  if it was a truly modular design, the parts would snap or slide-lock
> apart in some fashion, there would be a hardware and software standard
> published, and the parts would be re-useble in future designs and they
> would have PUBLISHED SOME INDICATION OF THEIR EXISTENCE already.
>
>  so it's total horseshit and they know it.  they're not stupid: they
> had enough people on their forums talk about dave hakkan's phonebloks
> concept for them to have heard the word "modular" enough times.
>
>
> > The biggest issue is that they've tied the modem and SIM directly to the
> > rest of the system. It's a cheap decision. Which most manufactures have
> done
> > unfortunately. [1]
>
>  i told them that it's easy to get hold of a cheap 3G modem containing
> a qualcomm MSM chipset.  they ceased communication shortly afterwards.
>

You're being to brief here. I don't understand.

They are using a Qualcomm MSM (Snapdragon 801) chip for their "Fairphone
2".

Which in my opnion is both good and bad.
Good:
- Open source kernels without NDA
- Opensource display drivers: Freedreno
Bad:
- Modem and SIM are remote programmable and have direct, unswitched,
uncontrolled access to power and RAM. So very bad for your privacy.
- Little effort in up-streaming their modifications to the Linux Kernel
- No free unbricking software.

How bad for your privacy? One rogue cell transceiver (ca. 800$) and
complete control over your phone forever.

But that is true for almost all phones.


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

[Arm-netbook] personal fight against the modern laptop

[mike.v...@gmail.com]

http://hackaday.com/2017/01/26/a-personal-fight-against-the-modern-laptop/
https://youtu.be/Ib7tFvw34DM

I Commented on the video that EOMA might be what he'd like.

I tried to point him to the EC firmware but "http://hands.com/~lkcl/eoma";
is bit of a mess. It contains a lot of (historical) info without structure.

Also I find. http://rhombus-tech.net/community_ideas/laptop_15in/ and the
e-linux wiki hard to navigate. It's messy.

If I'd like to start hacking on the laptop a staring point would be nice.
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] personal fight against the modern laptop

[mike.v...@gmail.com]

Op 27 jan. 2017 16:59 schreef "mike.v...@gmail.com" :

http://hackaday.com/2017/01/26/a-personal-fight-against-the-modern-laptop/
https://youtu.be/Ib7tFvw34DM

Wrong link
https://youtu.be/Fzmm87oVQ6c



I Commented on the video that EOMA might be what he'd like.

I tried to point him to the EC firmware but "http://hands.com/~lkcl/eoma";
is bit of a mess. It contains a lot of (historical) info without structure.

Also I find. http://rhombus-tech.net/community_ideas/laptop_15in/ and the
e-linux wiki hard to navigate. It's messy.

If I'd like to start hacking on the laptop a staring point would be nice.
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] Logging and journaling

[mike.v...@gmail.com]

2017-02-08 15:33 GMT+01:00 Julie Marchant :

> I just want to make sure of something: are the EOMA68-A20 computer cards
> going to be shipped with logging and journaling disabled (so that the
> storage isn't constantly being written to)? I'm asking because this is
> pretty much a necessity for an OS running on NAND or an SD card if you
> don't want to have to constantly buy new SD cards because the previous
> one reached its write limit.
>

NAND wear is probably more linked to age than number of writes. NAND has
more faults than harddisk. The trick is ECC and headroom and mapping for
faulted sectors.

The biggest issue is boot fixed read addresses.


>
> Ditto for swap, but given the small amount of NAND on the A20 card, I'm
> sure not having swap is a given anyway. ;)
>
> --
> Julie Marchant
> https://onpon4.github.io
>
> Protect your emails with GnuPG:
> https://emailselfdefense.fsf.org
>
>
> ___
> arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netb...@files.phcomp.co.uk
>
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] Logging and journaling

[mike.v...@gmail.com]

Op 8 feb. 2017 16:11 schreef "Julie Marchant" :

On 02/08/2017 09:46 AM, mike.v...@gmail.com wrote:
> NAND wear is probably more linked to age than number of writes.

No, NAND is flash memory, it has a definite limit on the number of times
it can be written to (in each sector, that is). It doesn't matter how
old flash memory is, if you reach its write limit, it's useless.

All flash memory is like this, including most SSDs. The only variation
is what the limit is and what the firmware does to compensate. So one
might take more writes than another, but regardless, every write
*necessarily* brings it closer to the end of its life.

.

That's debatable:
https://www.google.nl/amp/embedded#amp=http%253A%252F%252Fwww.zdnet.com%252Fgoogle-amp%252Farticle%252Fssd-reliability-in-the-real-world-googles-experience%252F&idx=0


--
Julie Marchant
https://onpon4.github.io

Protect your emails with GnuPG:
https://emailselfdefense.fsf.org


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

Re: [Arm-netbook] Logging and journaling

[mike.v...@gmail.com]

2017-02-08 21:02 GMT+01:00 Adam Van Ymeren :

> On Wed, Feb 8, 2017 at 2:54 PM, mike.v...@gmail.com 
> wrote:
>
>>
>>
>> Op 8 feb. 2017 16:11 schreef "Julie Marchant" :
>>
>> On 02/08/2017 09:46 AM, mike.v...@gmail.com wrote:
>> > NAND wear is probably more linked to age than number of writes.
>>
>> No, NAND is flash memory, it has a definite limit on the number of times
>> it can be written to (in each sector, that is). It doesn't matter how
>> old flash memory is, if you reach its write limit, it's useless.
>>
>> All flash memory is like this, including most SSDs. The only variation
>> is what the limit is and what the firmware does to compensate. So one
>> might take more writes than another, but regardless, every write
>> *necessarily* brings it closer to the end of its life.
>>
>> .
>>
>> That's debatable:
>> https://www.google.nl/amp/embedded#amp=http%253A%252F%252Fww
>> w.zdnet.com%252Fgoogle-amp%252Farticle%252Fssd-reliabilit
>> y-in-the-real-world-googles-experience%252F&idx=0
>>
>
> Link doesn't work for me (Thanks Google!) but this one does.
>
> http://www.zdnet.com/article/ssd-reliability-in-the-real-
> world-googles-experience/
>
> Assuming this is what you meant to link to.
>

Yes thank you


>
>
>>
>>
>>
>> --
>> Julie Marchant
>> https://onpon4.github.io
>>
>> Protect your emails with GnuPG:
>> https://emailselfdefense.fsf.org
>>
>>
>> ___
>> arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
>> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
>> Send large attachments to arm-netb...@files.phcomp.co.uk
>>
>>
>>
>> ___
>> arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
>> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
>> Send large attachments to arm-netb...@files.phcomp.co.uk
>>
>
>
> ___
> arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netb...@files.phcomp.co.uk
>
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] Logging and journaling

[mike.v...@gmail.com]

2017-02-09 12:03 GMT+01:00 Julie Marchant :

> On 02/09/17 01:50, Luke Kenneth Casson Leighton wrote:
>
>>   do you know the mkfs.ext4 commands needed or the ext2flags command?
>>
>
> No, but just using an ext2 filesystem instead should suffice (since ext2
> doesn't support journaling). That's the standard advice for the OpenPandora.


As we all have established. We have flash memory. Which comes in a few
flavors. NAND (Not AND) and NOR (Not Or). Which is the type of logic gate
used.

Then we have SLC (Single level), MLC (Multi level) (And TLC, QLC)

With MLC, TLC, QLC you read/write multiple bits at once.
These come with an issue:
https://en.wikipedia.org/wiki/Solid-state_drive#Battery_or_supercapacitor

Then we have wear leveling. With bare Flash you have none. With SD/MCC/eMMC
and SSD you have some. This is done via hardware/firmware. This is useally
done in a way that is support regular rotating disk filesystem.

The mechanics are though obscure and those controller usually are
programmed by closed firmware.

So for bare NAND you should not use a regular filesystem like EXT, XFS,
FAT, NTFS, etc. Also F2FS is not build for bare nand. It is made for
controlled flash.

For bare NAND you should use special drivers and filesystems like MTD and
UBIFS or YaFFS.
http://linux-sunxi.org/NAND

The Allwinner 3.4 kernel contains a NAND driver. But I don't know what the
quality of it is. I though that I read it was not that great and that the
new mainline driver had a lot of hoops to go trough to support flash
formatted/controlled by the 3.4 driver.

So MLC has problems with power loss. So a journalling filesystem is a must.
A journalling FS has noting to do with logging. But with write consistency.

With (e)MMC/SD adn SSD you lose a bit of freedom and gain extra security
issues. But makes programming easier.

So weather NAND suffers from wear or age: You need a good controller
(hardware or software) identifying broken cells and marking them unfit and
not bother progams or users with unwritable sectors.




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

Re: [Arm-netbook] Logging and journaling

[mike.v...@gmail.com]

2017-02-10 8:53 GMT+01:00 mike.v...@gmail.com :

>
>
> 2017-02-09 12:03 GMT+01:00 Julie Marchant :
>
>> On 02/09/17 01:50, Luke Kenneth Casson Leighton wrote:
>>
>>>   do you know the mkfs.ext4 commands needed or the ext2flags command?
>>>
>>
>> No, but just using an ext2 filesystem instead should suffice (since ext2
>> doesn't support journaling). That's the standard advice for the OpenPandora.
>
>
> As we all have established. We have flash memory. Which comes in a few
> flavors. NAND (Not AND) and NOR (Not Or). Which is the type of logic gate
> used.
>
> Then we have SLC (Single level), MLC (Multi level) (And TLC, QLC)
>
> With MLC, TLC, QLC you read/write multiple bits at once.
> These come with an issue:
> https://en.wikipedia.org/wiki/Solid-state_drive#Battery_or_supercapacitor
>
> Then we have wear leveling. With bare Flash you have none. With
> SD/MCC/eMMC and SSD you have some. This is done via hardware/firmware. This
> is useally done in a way that is support regular rotating disk filesystem.
>
> The mechanics are though obscure and those controller usually are
> programmed by closed firmware.
>
> So for bare NAND you should not use a regular filesystem like EXT, XFS,
> FAT, NTFS, etc. Also F2FS is not build for bare nand. It is made for
> controlled flash.
>
> For bare NAND you should use special drivers and filesystems like MTD and
> UBIFS or YaFFS.
> http://linux-sunxi.org/NAND
>
> The Allwinner 3.4 kernel contains a NAND driver. But I don't know what the
> quality of it is. I though that I read it was not that great and that the
> new mainline driver had a lot of hoops to go trough to support flash
> formatted/controlled by the 3.4 driver.
>
> So MLC has problems with power loss. So a journalling filesystem is a
> must. A journalling FS has noting to do with logging. But with write
> consistency.
>

The biggest writer in a desktopish environment are the system and
application logs.

So move var log to ram. This is usually enough for debugging purposes. But
it should remain easily possible to write to flash/disk if debugging
hanging systems issues.

Further the files system "acces time" stamps is a big writer. With BTRFS
you have the "relatime" option (relax acces time updates).

This does break some programs which rely on accurate "atime". But for most
end users this is not a problem.


>
> With (e)MMC/SD adn SSD you lose a bit of freedom and gain extra security
> issues. But makes programming easier.
>
> So weather NAND suffers from wear or age: You need a good controller
> (hardware or software) identifying broken cells and marking them unfit and
> not bother progams or users with unwritable sectors.
>
>
>
>
>>
>>
>> ___
>> arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
>> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
>> Send large attachments to arm-netb...@files.phcomp.co.uk
>>
>
>
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] A suggestion why Systemd may be bad

[mike.v...@gmail.com]

2017-02-15 7:30 GMT+01:00 John Luke Gibson :

> Perhaps it is the idea that a linux machine should be wholly modular
> and attaching a library to a critical component of the system,
> shouldn't be a viable strategy for popularizing one's work.
>
True


>
> When a distro is forced to carry a package due to a dependency of a
> dependency, or any magnitude there of, it breaks a core separation of
> power there. The users depend on distro's to provide reliable
> packages, however if a package is intentionally interweaving files to
> make these dependencies simply a part of the file and therefore
> robbing the distro's the ability to choose a different dependency
> should another developer or team thereof prove more reliable or more
> suited for their distro.
>

It's not really about "files". It's about functionality.

The reason for an "init" system is automation. In order to have a
"functional " desktop a log of services need to be running.

Different functionality requirements require different "init" systems. So
in order for software to support all different "init" systems you need to
go an extra mile which not  every maintainers is willing to do.

So for distro's to support multiple "init" systems they need to
modify/enhance software from others. And they need to test all possible
configurations. Which is extra effort not everyone is willing to do.


>
> Systemd in this sense would be like microsoft robbing those wishing to
> distinguish themselves of the ability by increasing the magnitude of
> difficulty in doing so.
>

If I read the discomfort correctly the systemd maintainers are too focused
on their own use case and seek to little collaboration with the rest of the
community during development.

This results in issues for people with "corner" cases, which don't get
resolved. And massive code dumps which result in massive rewrites too get
support from the rest of the community.

This is indeed quite similar to a closed source business like Microsoft.
The company sets their goals and developers need to follow the goals set by
the company. Not the goals set by others or what might even be a beter goal
for the user.

I think in the end, the one that pays decides. To change code you need
time. That time needs to be paid. Individual developers can donate time
they have left after earning that by other work. Company's can donate time
of employees. But the time spent must be paid, either by other work or by
the result of the donated time. Usually it is the latter so that's why
company's decide where time is spent within a project.

But for a OS project to be successful you need to consider the needs of
others so it's a balancing act.


>
> Now, keep in mind, I am not fluent in any programming language and
> have not audited Systemd, nor do I know anyone who has. This is based
> on a compiled understanding of observations expressed in arguments
> both infavor and against Systemd.
>
> ___
> arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netb...@files.phcomp.co.uk
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] Logging and journaling

[mike.v...@gmail.com]

2017-03-09 15:37 GMT+01:00 Hendrik Boom :

> On Sun, 12 Feb 2017 19:35:00 +, Lyberta wrote:
>
> > Eric Duhamel:
> >> Depending on what you mean by "newbies", I don't think they would know
> >> if they want any particular image of GNU/Linux except the one that was
> >> designed to run on the product by the maker of the product. After all,
> >> they don't know the nooks and crannies of GNU/Linux and would just want
> >> to receive a product that works.
> >
> > OK, I'm a software developer, not a system administrator. I have no idea
> > what 90% of packages installed on my system do. I only use terminal to
> > upload my code to the Git repository. But I need g++ 6.
> >
> > Debian Jessie has g++ 4.9.2 which is extremely old and none of my
> > software will compile there. When I pledged for Debian card, I expected
> > stock Debian with maybe a few custom packages which would be explicitly
> > marked as such. And the first thing I'd do is to upgrade to Testing
> > which as of writing this has g++ 6.3.0.
> >
> > Now I'm told that issuing "apt-get dist-upgrade" is taking
> > responsibility, etc. So I'm stuck with old and unusable frankendistro
> > and on my own if I want to make it work.
> >
> > I've chosen GNU/Linux because of its freedom and I've chosen Debian
> > because it doesn't have proprietary software in main. I have no idea of
> > what is going under the hood. I don't care what init system I run as
> > long as it is free software and it boots my PC.
> >
> > A couple of years ago I needed to buy a laptop. I've looked for one
> > which doesn't come with Windows and I've found one with Ubuntu. Now, I
> > really hate Ubuntu and the first thing I've done was to install Debian
> > in dual boot. For some reason, Debian couldn't power off my laptop so I
> > removed it and I'm still stuck with Ubuntu.
> >
> > I know what you're going to say: "You should've looked for the solution
> > on the Internet.". Well, sometimes I don't have time and am scared of
> > bricking my hardware. I want things to "just work".
>
> If you can boot your machine from USB, you won't brick it by changing the
> OS, because you can boot a Debian or Ubuntu installer and reinstall
> whichever you want.  So your laptop is probably safe.
> >
> > It looks like EOMA68-A20 is not going to just work. I don't want it to
> > end like my laptop.
>
> Will the EOMA68-A20 boot from USB to run an installer?
>

Not unless it's build.

Also most installers have limited support for non x86 devices. Intel
platforms provide a somewhat "standard" way for booting external media. For
ARM etc. there is no such thing.

For Intel you have the BIOS. For ARM you usually have u-boot.

When a A20 is powered. It reads from an internal ROM. This contains a
minimal init program for loading a program and inits SRAM. This ROM is what
Luke is fighting with because it cannot read from currently produced NAND
Flash types. It searches in NAND and SD for a "magic" token and loads the
data following that into internal RAM (sram) and than tries to run what's
loaded. What's loaded is usually a minimal u-boot (SPL/boot0) which inits
external RAM etc and loads another program, usally a full u-boot (mainline
or boot1), from whatever location is programmed into u-boot SPL. That stage
init's other peripherals and then loads the OS, usually linux from whatever
location you specify.

boot0/boot1 are u-boot implementations by Allwinner. Mainline u-boot has
support for A20. So no need for a butched version from AW.

u-boot does not a have a standard for searching locations and booting from
those.

Since there is no standard, generic installers cannot work and thus
installers must by tailored.

So for EOMA we must set/invent a standard which Installers can use
regardless the SoC type used in the EOMA card.

Other ARM device vendor usually build their own installers. But that's a
quick and dirty solution only only last as long as the vendor invests in
that method.

On A20 et.al. there is the FEL mode. Which is initialized by that first
loaded program. In this FEL mode you can push an image over USB-OTG. But
that requires an active USB host not just an USB thumb drive.

http://linux-sunxi.org/FEL/USBBoot#Booting_U-Boot_over_USB
http://linux-sunxi.org/BROM

So the question is are "we" going to build such a thing?



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

Re: [Arm-netbook] EOMA68 booting process

[mike.v...@gmail.com]

2017-03-10 8:15 GMT+01:00 Luke Kenneth Casson Leighton :
>
>  ah.  right.  the way i see it, the only thing that needs to happen is
> that the card has to have enough on-board storage to get to u-boot (or
> similar) where it can then recognise the EOMA68 I2C EEPROM (and get
> the ID info) or for it to (pretty much) always boot externally and do
> the same.
>

Always boot externally? That means that every housing must contain storage
and an OS.

That would kill a seamless environment on every device and any form of
suspend and resume.

I think the OS should remain with the card. Weather that's on NAND, eMMC or
SD. That should be irrelevant.

But for the average jane/joe to switch/repair/upgrade that OS we must have
a "simple" mechanism for booting external media while keeping the main
media connected.

A Intel BIOS usually has a "boot" order which can be modified. For EOMA we
don't have that "luxury". The housing may not have a screen or an input
device for changing options.

I guess it should be that the last boot init should scan for external
devices and look for a specific file name "eomaboot.txt" or some thing.

If that is found try to boot from it. If it fails perhaps write log to that
file.

If that file is not found boot from internal media.

I guess this is somewhat different from normal because usually u-boot is
build with the OS payload attached kernel,initram,devicetree.

Updating the kernel means updating u-boot.

The second stage u-boot is something akin to GRUB/LILO/etc. But fixed to a
single boot option.

Blindly booting something external is probably a security issue. But I see
little alternatives to keep is simple. So simple that all you need is a
thumbdrive to bootstrap an EOMA card.

On Android they use fastboot and recovery. Which is toggling some
persistent data from the running OS that u-boot reads from the next boot
and chooses a different image to load.

It usually also listens to a button press during boot to do the same.

I find that method flawed. It either requires a running OS or a button to
press. On EOMA there is no button. Else we have to introduce something like
a reset button/pinhole on the user facing side of the card.


>
> anything beyond tthat needs to be analysed *really* carefully, right
> through its impllications down the *entire* lifecycle.


Absolutly, I too think this is something not to be taken lightly. Any
mistake will hunt EOMA for a Long time


> which is why i
> currently have it as (pretty much) "card must self-boot and must adapt
> to EOMA68 EEPROM ID" and it's left as generically as that
>
> > On A20 et.al. there is the FEL mode. Which is initialized by that first
> > loaded program.
>
>  from ROM.
>
> > In this FEL mode you can push an image over USB-OTG. But
> > that requires an active USB host not just an USB thumb drive.
>
>  i do this all the time.  i don't develop for the A20 in any other
> way.  when i see the shit that people get themselves into *even though
> usb-fel was written years ago* by trying to un-fuck their systems
> using LIVESHIT.EXE and other crap i'm just... staggered and genuinely
> confused.
>
>  it's *real* simple and needs just *seven* lines of bash script:
>
> fel write 0x2000 ./fel-boot-spl-EOMA68_A20_2GB.bin
> sleep 1
> fel exe 0x2000
> sleep 1
> fel write 0x4a00 u-boot.new.bin
> sleep 1
> fel exe 0x4a00
>
> the fel-boot-spl.bin is actually the u-boot-spl.bin executable that's
> compiled by default in u-boot if you select "CONFIG_SPL".  the
> u-boot.new.bin is u-boot without the spl part tacked onto the front.
>
> it really couldn't be simpler.  you can if you want directly upload
> the linux kernel, script.bin, dtb file, initramdisk WHATEVER YOU LIKE
> directly into memory and then execute it DIRECTLY.  you don't even
> need u-boot to do it.
>
>
> > http://linux-sunxi.org/FEL/USBBoot#Booting_U-Boot_over_USB
> > http://linux-sunxi.org/BROM
> >
> > So the question is are "we" going to build such a thing?
>
>  i'm yet to be convinced that it's necessary, beyond adapting u-boot
> and the linux kernel to read and adapt to the ID in the EOMA68 EEPROM.
> what specifically did you have in mind?
>
> l.
>
> >
> >>
> >>
> >> -- hendrik
> >>
> >>
> >> ___
> >> arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
> >> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> >> Send large attachments to arm-netb...@files.phcomp.co.uk
> >
> >
> >
> > ___
> > arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
> > http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> > Send large attachments to arm-netb...@files.phcomp.co.uk
>
> ___
> arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netb...@files.phcomp.co.uk
___
arm-netbook mailing list arm-netbook@lists.

Re: [Arm-netbook] EOMA68 booting process

[mike.v...@gmail.com]

2017-03-10 16:12 GMT+01:00 Luke Kenneth Casson Leighton :

> On Fri, Mar 10, 2017 at 1:56 PM, mike.v...@gmail.com
>  wrote:
> > Always boot externally? That means that every housing must contain
> storage
> > and an OS.
>
>  not at all.  you misunderstand.  external *on the card*.  for
> example: the micro-sd card slot on the EOMA68-A20.
>

Figured as much just wanted to be explicit

>
> > I think the OS should remain with the card. Weather that's on NAND, eMMC
> or
> > SD. That should be irrelevant.
>
>  that's not entiirely for us to decide (as in: booting from Housings
> should not be *prohibited*) but yes, of course the Card has to be
> capable of stand-alone boot.


Then multi boot is implied.

>
> > But for the average jane/joe to switch/repair/upgrade that OS we must
> have a
> > "simple" mechanism for booting external media while keeping the main
> media
> > connected.
> >
> > A Intel BIOS usually has a "boot" order which can be modified. For EOMA
> we
> > don't have that "luxury".
>
>  well... we do... as i believe it is reasonable to simply say that the
> responsibility is with the retailer to ensure that whatever
> function(s) and housing(s) they sell must actually work as sold.  if
> they want to provide a boot order, they may do so.
>

Although in this stage of the project it is not really a hot issue.

Leaving this to the "market" will result in 1001 different options which
will require 1001+ methods for loading a new OS on the card.

No way a independent software vendor is going to support 1001+ boot/install
options.


>
> > The housing may not have a screen or an input
> > device for changing options.
>
>  correct... however anyone who supplies such housings would also be
> taking full responsibility for creating a suitable OS.
>
> > I guess it should be that the last boot init should scan for external
> > devices and look for a specific file name "eomaboot.txt" or some thing.
>
>  too complex and not really necessary if it is the responsibility of
> the retailer to ensure that the product they sell "works".  btw to
> emphasise: one of the other responsibilities of the retailer is to NOT
> lock down the device so that 3rd parties are no longer permitted to
> replace the OS and boot mechanism entirely.
>

I afraid that's not enough. They release a card or housing make an OS for
it and then they are done.

Not locking down to boot is enough to say: "Hey they can load something
else. If they know wat they are doing"

That's the status right now. A product is made software is tweaked to work
and done...

Loading a Android MOD is a tricky business. It's replacing the running OS
using the running system. When failed it's bricked.

The bootloading process of AW(FEX) has been reverse engeneerd. The other
SoC not. They all require propriety software to flash software to a bricked
device like Allwinners Livesuit/Phoenixsuit.

It doesn't have to be a fixed standard. If a mechanism is proposed, than
it's more likely to be used than left to each individual vendor to invent.


>
>  also, *when* microsoft and apple start creating proprietary Cards
> (hard as it may be for them to support the full range of available
> Housings by the time they get the memo) it should not be made
> difficult or impossible for them to comply with the standard because
> it's been "assumed all along that Linux Is God".   remember, it's
> perfectly possible to have an EOMA68-compliant FPGA Card.
>

Or a STM32F. I know. You could even build one from discrete logic.

But most need software to work. That software should be "easely"
maintainable. If not they are going to the landfill if they don't work or
become outdated.

But I understand it is a tricky one. An EOMA card can have varying
"intelligence" and "hardware". A single "boot" method may not be possible.
At least we could try to limit it so that it becomes more
adoptable/maintainable to the end-user.




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

[Arm-netbook] Funding

[mike.v...@gmail.com]

Interesting read:
https://medium.com/open-collective/why-and-how-to-fund-the-open-source-projects-you-depend-on-da62a582307#.qborgcu54
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] libre 64-bit risc-v SoC

[mike.v...@gmail.com]

2017-04-27 13:21 GMT+02:00 Luke Kenneth Casson Leighton :

> ok so it would seem that the huge amount of work going into RISC-V
> means that it's on track to becoming a steamroller that will squash
> proprietary SoCs, so i'm quite happy to make sure that it's
> not-so-subtly nudged in the right direction.
>
> i've started a page where i am keeping notes:
> http://rhombus-tech.net/riscv/libre_riscv/ and the general goal is to
> create a desirable mass-volume low-cost SoC, meaning that it will need
> to at least do 1080p60 video decode and have 3D graphics capability.
> oh... and be entirely libre.
>

That's one hornet nest you're going into. But I'd really like to see you
pull it off.


>
> the plan is:
>
> * to create an absolute basic SoC, starting from lowRISC (64-bit),
> ORGFX (3D graphics) and MIAOW (OpenCL engine), in at least 90nm as a
> low-cost proof-of-concept where mistakes can be iterated through
> * provide the end-result to software developers so that they can have
> actual real silicon to work with
> * begin a first crowd-funding phase to create a 28nm (or better)
> multi-core SMP SoC
>
> for this first phase the interfaces that i've tracked down so far are
> almost entirely from opencores.org, meaning that there really should
> be absolutely no need to license any costly hard macros.  that
> *includes* a DDR3 controller (but does not include a DDR3 PHY, which
> will need to be designed):
>
> * DDR3 controller (not including PHY)
> * lowRISC contains "minion cores" so can be soft-programmed to do any GPIO
> * boot and debug through ZipCPU's UART (use an existing EC's on-board
> FLASH)
> * OpenCores VGA controller (actually it's an LCD RGB/TTL controller)
> * OpenCores ULPI USB 2.0 controller
> * OpenCores USB-OTG 1.1 PHY
>

I'm not much into HW design. But I think it would be wise to aim for USB-C
connectivity.

USB-C does not imply USB3.0 AFAIKT.

USB-C has to option of channeling USB2/3,HDMI,DP via the alternate modes
and power. So a stack of USB-C connectors on the User Facing Side would be
awesome.

It would also limit the need for other connectors and PHY's.

The problem is MUXing all modes to a single output. New Apple laptops have
USB-C but not all ports support all functions.

Perhaps a bit of FPGA could be the key?

Ethernet over UCB-C is still being discussed. So the FPGA might be handy to
have when/if that mode is materialized.

A bit of FPGA would be nice to have anyway. Media codecs keep on changing
and would extend the life of the SoC.


>
> note that there are NO ANALOG INTERFACES in that.  this is *really*
> important to avoid, because mixed analog and digital is incredibly
> hard to get right.  also note that things like HDMI, SATA, and even
> ethernet are quite deliberately NOT on the list.


That's what phy's are for right?

VGA is on decline I would bother with it too much. But that's personal.


> Ethernet RMII (which
> is digital) could be implemented in software using a minion core.  the
> advantage of using the opencores VGA (actually LCD) controller is: i
> already have the full source for a *complete* linux driver.
>
> I2C, SPI, SD/MMC, UART, EINT and GPIO - all of these can be
> software-programmed as bit-banging in the minion cores.
>
> these interfaces, amazingly, are enough to do an SoC that, if put into
> 40nm, would easily compete with some of TI's offerings, as well as the
> Allwinner R8 (aka A13).
>
> i've also managed to get alliance and coriolis2 compiled on
> debian/testing (took a while) so it *might* not be necessary even to
> pay for the ASIC design tooling (the cost of which is insane).
> coriolis2 includes a reasonable auto-router.  i still have yet to go
> through the tutorials to see how it works.  for design rules: 90nm
> design rules (stacks etc.) are actually publicly available, which
> would potentially mean that a clock rate of at least 300mhz would be
> achievable: interestingly 800mhz DDR3 RAM from 2012 used 90nm
> geometry.  65 down to 40nm would be much more preferable but may be
> hard to get.
>

I Don't think speed is to much of an issue right now. Having something
workable like this, even only suitable for embedded use, would gain
traction fast enough to get attention and help for new revisions with
smaller and faster production.

Besides the max for silicon scaling is nearing. EULV is still not generally
available.

Better architectures are needed. Just like better programming.


>
> graphics: i'm going through the list of people who have done GPUs (or
> parts of one).  MIAOW, Nyuzi, ORGFX.  the gplgpu isn't gpl. it's been
> modified to "the text of the GPL license plus an additional clause
> which is that if you want to use this for commercial purposes then...
> you can't". which is *NOT* a GPL license, it's a proprietary
> commercial license!
>
> MIAOW is just an OpenCL engine but a stonking good one that's
> compatible with AMD's software.  nyuzi is an experimental GPU where i
> hope its developer believes in its potential.  ORGFX i 

Re: [Arm-netbook] libre 64-bit risc-v SoC

[mike.v...@gmail.com]

2017-04-27 13:21 GMT+02:00 Luke Kenneth Casson Leighton :

> ok so it would seem that the huge amount of work going into RISC-V
> means that it's on track to becoming a steamroller that will squash
> proprietary SoCs, so i'm quite happy to make sure that it's
> not-so-subtly nudged in the right direction.
>
> i've started a page where i am keeping notes:
> http://rhombus-tech.net/riscv/libre_riscv/ and the general goal is to
> create a desirable mass-volume low-cost SoC, meaning that it will need
> to at least do 1080p60 video decode and have 3D graphics capability.
> oh... and be entirely libre.
>
> the plan is:
>
> * to create an absolute basic SoC, starting from lowRISC (64-bit),
> ORGFX (3D graphics) and MIAOW (OpenCL engine), in at least 90nm as a
> low-cost proof-of-concept where mistakes can be iterated through
> * provide the end-result to software developers so that they can have
> actual real silicon to work with
> * begin a first crowd-funding phase to create a 28nm (or better)
> multi-core SMP SoC
>
> for this first phase the interfaces that i've tracked down so far are
> almost entirely from opencores.org, meaning that there really should
> be absolutely no need to license any costly hard macros.  that
> *includes* a DDR3 controller (but does not include a DDR3 PHY, which
> will need to be designed):
>
> * DDR3 controller (not including PHY)
> * lowRISC contains "minion cores" so can be soft-programmed to do any GPIO
> * boot and debug through ZipCPU's UART (use an existing EC's on-board
> FLASH)
>

Perhaps put it sirectly to an USB bridge. UART's on debugging hardware is
non existant. We all use FTDI dongles.

Look like OpenCores has a module. https://opencores.org/project,usb2uart



> * OpenCores VGA controller (actually it's an LCD RGB/TTL controller)
> * OpenCores ULPI USB 2.0 controller
> * OpenCores USB-OTG 1.1 PHY
>
> note that there are NO ANALOG INTERFACES in that.  this is *really*
> important to avoid, because mixed analog and digital is incredibly
> hard to get right.  also note that things like HDMI, SATA, and even
> ethernet are quite deliberately NOT on the list.  Ethernet RMII (which
> is digital) could be implemented in software using a minion core.  the
> advantage of using the opencores VGA (actually LCD) controller is: i
> already have the full source for a *complete* linux driver.
>
> I2C, SPI, SD/MMC, UART, EINT and GPIO - all of these can be
> software-programmed as bit-banging in the minion cores.
>
> these interfaces, amazingly, are enough to do an SoC that, if put into
> 40nm, would easily compete with some of TI's offerings, as well as the
> Allwinner R8 (aka A13).
>
> i've also managed to get alliance and coriolis2 compiled on
> debian/testing (took a while) so it *might* not be necessary even to
> pay for the ASIC design tooling (the cost of which is insane).
> coriolis2 includes a reasonable auto-router.  i still have yet to go
> through the tutorials to see how it works.  for design rules: 90nm
> design rules (stacks etc.) are actually publicly available, which
> would potentially mean that a clock rate of at least 300mhz would be
> achievable: interestingly 800mhz DDR3 RAM from 2012 used 90nm
> geometry.  65 down to 40nm would be much more preferable but may be
> hard to get.
>
> graphics: i'm going through the list of people who have done GPUs (or
> parts of one).  MIAOW, Nyuzi, ORGFX.  the gplgpu isn't gpl. it's been
> modified to "the text of the GPL license plus an additional clause
> which is that if you want to use this for commercial purposes then...
> you can't". which is *NOT* a GPL license, it's a proprietary
> commercial license!
>
> MIAOW is just an OpenCL engine but a stonking good one that's
> compatible with AMD's software.  nyuzi is an experimental GPU where i
> hope its developer believes in its potential.  ORGFX i am currently
> evaluating but it looks pretty damn good, and i think it is slightly
> underestimated.  i could really use some help evaluating it properly.
> my feeling is that a combination of MIAOW to handle shading and ORGFX
> for the rendering would be a really powerful combination.
>
> so.
>
> it's basically doable.  comments and ideas welcome, please do edit the
> page to keep track of notes http://rhombus-tech.net/riscv/libre_riscv/
>
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>
> ___
> arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netb...@files.phcomp.co.uk
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] libre 64-bit risc-v SoC

[mike.v...@gmail.com]

2017-04-28 13:23 GMT+02:00 Luke Kenneth Casson Leighton :

> On Fri, Apr 28, 2017 at 11:29 AM, mike.v...@gmail.com
>  wrote:


> > The problem is MUXing all modes to a single output. New Apple laptops
> have
> > USB-C but not all ports support all functions.
> >
> > Perhaps a bit of FPGA could be the key?
>
>  yeah.
>
> > Ethernet over UCB-C is still being discussed. So the FPGA might be handy
> to
> > have when/if that mode is materialized.
> >
> > A bit of FPGA would be nice to have anyway. Media codecs keep on changing
> > and would extend the life of the SoC.
>
>  at the expense of power consumption.


If you're trying to trans-code something that you don't have a
co-processor/module for you're forced to CPU/GPU trans-coding. Would a FPGA
still be more power huns gry then?

I think/hope FPGA's are more efficient for specific tasks then CPU/GPU's

We can always have evolution create a efficient decoder ;-)
https://www.damninteresting.com/on-the-origin-of-circuits/
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.50.9691&rep=rep1&type=pdf







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

Re: [Arm-netbook] libre 64-bit risc-v SoC

[mike.v...@gmail.com]

2017-04-28 14:58 GMT+02:00 Luke Kenneth Casson Leighton :

>
>  in the case where you have something that falls outside of the custom
> silicon (a newer CODEC for example) then yes, an FPGA would *possibly*
> help... if and only if you have enough bandwidth.
>

That is what I was talking about.


>
>  video is RIDICULOUSLY bandwidth-hungry.  1920x1080 @ 60fps 32bpp
> is... an insane data-rate.  it's 470 MEGABYTES per second.  that's
> what the framebuffer has to handle, so you not only have to have the
> HDMI (or other video) PHY capable of handling that but the CODEC
> hardware has to be able to *write* - simultaneously - on the exact
> same memory bus.
>

I Overestimated the capabilities of an FPGA. I've just read You need
two/four FPGA linked to do H264 in realtime. Or a full new one. FPGA's also
are usually are very slow.

I found a nice presentation on using FPGA's for video codecs.
https://www.ece.cmu.edu/~ece796/seminar/10/seminar/FPGA.ppt

The most facinating option I found is to reconfigure the FPGA for each
processing step.


>
>  the point is: if you're considering using an FPGA to accelerate video
> it's gonna be a *really* big and expensive FPGA, and you would need to
> implement something like PCIe just to cope with the communications
> between the two.
>
>  costs just escalated way beyond market value.
>
>  this is why companies just simply... abandon one SoC and do another
> one which has an improved custom CODEC silicon which *does* handle the
> newer CODEC(s).
>

Hmm. So for longevity the video decoder should be outside the SoC and be
serviceable... Nah just buy a new EOMA card and keep the rest. ;-)

Speaking of which any plans for a en/decoder module(IP Block is therm
right?) in the new SoC? Or leaving that out?
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] libre 64-bit risc-v SoC

[mike.v...@gmail.com]

2017-04-28 16:17 GMT+02:00 Luke Kenneth Casson Leighton :

>
>  the rest of the article makes a really good point, which has me
> deeply concerned now that there are fuckwits out there making
> "driverless" cars, toying with people's lives in the process.  you
> have *no idea* what unexpected decisions are being made, what has been
> "optimised out".
>

That's no different from regular "human" programming. If you employ IA
programming you still can validate the code like you would that of a normal
human.

Or build a second independ IA for the "four" eye principle.


>  with aircraft it's a different matter: the skies are clear, it's a
> matter of physics and engineering, and the job of taking off, landing
> and changing direction is, if extremely complex, actually just a
> matter of programming.  also, the PILOT IS ULTIMATELY IN CHARGE.
>
>  cars - where you could get thrown unexpected completely unanticipated
> scenarios involving life-and-death decisions - are a totally different
> matter.
>
>  the only truly ethical way to create "driverless" cars is to create
> an actual *conscious* machine intelligence with which you can have a
> conversation, and *TEACH* it - through a rational conversation - what
> the actual parameters are for (a) the laws of the road (b) moral
> decisions regarding life-and-death situations.
>

The problem is nuance. If a cyclist crosses your path and escaping
collision can only be done by driving into a group of people waiting to
cross after you passed them. The choice seems logical: Hit the cyclist.
Many are saved by killing/injuring/bumping one.

Humans are notoriously bad in taking those decisions themselves. We only
consider the cyclist. That's our focus. The group become the second
objective.

Many people are killed/injured by trying to avoid hitting animals. You try
to avoid collision only to find you'r vehicle becoming uncontrollable or
finding a new object on your new trajectory, mostly trees.

The real crisis comes from outside control. The car can be hacked and
become weaponized. That works with humans as well but is more difficult and
takes more time. Programming humans takes time.

Or some other Asimov related issue ;-)


>
>  applying genetic algorithms to driving of vehicles is a stupid,
> stupid idea because you cannot tell what has been "optimised out" -
> just as the guy from this article says.
>
> l.
>
> ___
> arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netb...@files.phcomp.co.uk
>
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] libre 64-bit risc-v SoC

[mike.v...@gmail.com]

2017-05-04 12:51 GMT+02:00 Luke Kenneth Casson Leighton :

>
>  ha, bit of irony for you: gaisler research released the LEON3 SPARCv8
> core a number of years ago under the GPLv2, so that people could use
> it for "academic and research purposes", the expectation being that
> for "commercial" use, they would seek a license from gaisler because
> you can't mix GPLv2 source with proprietary hard macro source.
>
>  the irony / beauty is: by seeking out *specifically* hard macros even
> for DDR3 that are compatible with the GPL, no proprietary license is
> needed :)
>
>  so... the source code which implements SMP cache coherency for a
> multi-core LEON3... i can pull that out and use it :)
>

Uhhm. So your going to use the GLP'ed macro for "SMP cache coherency" from
the LEON3 SPARCv8 design into the RISC-V so you can build a Multi core
(SMP) RISC-V?

Or are you considering a new SoC SPARC design?

According to wikipedia there is also a LEON4. If it is based on the LEON3
then the source code should be available right? Or is a materialized HW
design no obligated to ship with the source since it's not binary/machine
code?


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

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[mike.v...@gmail.com]

2017-05-04 9:04 GMT+02:00 John Luke Gibson :

> Since it seems like a trivially simple task that for some reason no
> one has taken up, I would like to take the opportunity to exercise a
> learning experience and simultaneously benefit the community, by
> liberating PocketCHIP by deblobbing the source and re-compiling.
>

The PocketCHIP is powered by their SoM:
http://linux-sunxi.org/NextThingCo_CHIP

That is apparently a Allwinner R8 pared with an external rtl8723bs Wifi/BT
chip.

The R8 is a rebranded A13.

If you look at
https://getchip.com/pages/chip

You'll see:
On the left image the RAM (Hynix) and Wifi+BT (Realtek) and Power module
(Allwinner AXP209)
On the right the SoC (R8/A13) and NAND (Samsung)

The A13 does not need blob's to run anymore, the WiFi+BT chip does.  AFAIKT

Display output needs some checking in Linux and U-boot mainline. But most
should be available or somewhat easily hacked in.

GPU needs a BLOB which does not work on mainline AFAIKT. Luc Verhaegen did
get quite far before he burned out.

But looking at the SUNXI wiki the CHIP products could need some TLC.

The PocketCHIP does not have it's own page there and probably needs a DT
overlay. I doubt that runtime can autosense the hardware on that.


>
> Browsing the archives to see if this had been talked about before, I
> find it very incredibly humourous I got name dropped on the mailing
> list by Parobath:
>
> > Date: Sat, 29 Oct 2016 20:13:10 +0200
> > From: Parobalth 
> > To: arm-netbook@lists.phcomp.co.uk
> > Subject: closed-source BootROM and RYF certification
> > User-Agent: Mutt/1.5.23 (2014-03-12)
> >
> > At the forum of NextThing Chip is a thread about Chip and a
> > possible RYF certification. I wrote there that I think that is unlikely
> > to happen and linked to https://www.crowdsupply.com/
> eoma68/micro-desktop/updates/fsf-ryf-background.
> > Then someone else mentioned that a closed-source BootROM is used for
> Chip.
> > Another guy with username "eaterjolly" wrote about this BootROM: "The
> same type of SOC is
> > used for the EOMA croud project which is vying for ryf-endorsement quite
> > openly [...]"
> >
> > You can find the forum thread here:
> > https://bbs.nextthing.co/t/ntc-thoughts-on-ryf-endorsement/4490
> >
> > Because they use Discourse to power their forum which relies heavily on
> > JavaScript I also attach a Pdf version of the forum post.
> >
> > I wonder if the mentioned statements are correct and how it relates to
> > the RYF certification of the EOMA68-A20 Libre Tea card.
> >
> > kind regards
> > Paro
>
> Like reading that URL, I was like? didn't I start that thread? then I
> re-read the post and noticed I was quoted in the email xD I didn't
> participate in the list back then, cause I was afraid my ignorance
> would be spurred, of course I know that not to be true in hindsight.
> Feels a bit melodramatic being name dropped on a linux mailing list,
> usually you only see legends get mentioned by name when they aren't
> around xD
>
> Anywhoo, I more or less just wanted to start this thread because I
> wanted to know if any one could point out anything that would need be
> removed besides the wifi firmware. I searched the sunix-uboot
> repository on github for the word blob and got a few interesting hits
> for the code in the folder binman:
>
> https://github.com/linux-sunxi/u-boot-sunxi/search?q=blob
>
> Particularly in files mentioning the devil:
>
> "# Entry-type module for Intel Chip Microcode binary blob"
>

That contains a full copy of U-Boot, not the Linux kernel, and thus
initialization for all type of hardware. Most of which requires microcode
of firmware to work.


>
> I suppose this is just another aspect of mainlining, meant to be
> parsed out once it's discovered that there are no such blobs in the
> kernel, but personally I'd feel more comfortable with a script
> removing these sections of the code altogether.
>
> If I had been actually reading the list digests back when I could have
> posted more accurate information in that thread rather than just
> guessing. Well, I suppose I can do so now.
>
> How humorous it is though too that I've run into the same 40k file
> limit? Small tiny things suggesting the work of the vicissitudes of
> fate, much like deja vu in the matrix.
>
> ___
> arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netb...@files.phcomp.co.uk
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] libre 64-bit risc-v SoC

[mike.v...@gmail.com]

2017-05-07 22:26 GMT+02:00 :

> I apologize for DOS'ing the list, I can only get online about once a week.
>
> On Fri, 28 Apr 2017 13:58:57 +0100
> Luke Kenneth Casson Leighton  wrote:
> >
> > On Fri, Apr 28, 2017 at 12:47 PM, mike.v...@gmail.com
> >  wrote:
> >
> > > If you're trying to trans-code something that you don't have a
> > > co-processor/module for you're forced to CPU/GPU trans-coding.
> >
> >  you may be misunderstanding: the usual way to interact with a GPU is
> > to use a memory buffer, drop some data in it, tell the GPU (again via
> > a memory location) "here, get on with it" - basically a
> > hardware-version of an API - and it goes an executes its *OWN*
> > instructions, completely independently and absolutely nothing to do
> > with the CPU.
> >
> >  there's no "transcoding" involved because they share the same memory
> > bus.
> >
> > > Would a FPGA
> > > still be more power huns gry then?
> >
> >  yes.
> >
> > > I think/hope FPGA's are more efficient for specific tasks then
> > > CPU/GPU's
> >
> >  you wouldn't give a general-purpose task to an FPGA, and you wouldn't
> > give a specialist task for which they're not suited to a CPU, GPU _or_
> > an FPGA: you'd give it to a custom piece of silicon.
>
> I always thought that FPGA's were good for prototyping or small fast
> tasks... But that's just how I learned about them.
>

Don't think of what you were thought. Think of what you can do which has
not been thought.

The world outside the box is bigger than the on inside the box ;-)


>
> >  in the case where you have something that falls outside of the custom
> > silicon (a newer CODEC for example) then yes, an FPGA would *possibly*
> > help... if and only if you have enough bandwidth.
> >
> >  video is RIDICULOUSLY bandwidth-hungry.  1920x1080 @ 60fps 32bpp
> > is... an insane data-rate.  it's 470 MEGABYTES per second.  that's
> > what the framebuffer has to handle, so you not only have to have the
> > HDMI (or other video) PHY capable of handling that but the CODEC
> > hardware has to be able to *write* - simultaneously - on the exact
> > same memory bus.
> >
> 
> Your number seemed off to me so I did the math:
> 1920*1080*60*4 ==
> 497,664,000
> You're off by almost 30 MiB.
>

497,664,000 ~= 498 MB (Units of 1000)
497,664,000 ~= 475 MiB (Units of 1024)


> Most video cameras (that I've been able to locate), do 24bpp, 640x480 at
> 30fps, so that would make the bandwidth requirements.
> 27,648,000
>

I was specifically hinting at decoding. That's the most used function. But
encoding should these days also be capable of FullHD


> Which should be more reasonable for an FPGA (not that I have all the
> specs sitting in front of me, mind you).
> I am assuming that "encoding video" means encoding from a video camera or
> a small youtube video as opposed to encoding to send to a device over,
> say, an HDMI cable.
>

The problem is that the FPGA has to be very big or very fast. FPGA are,
apparently, not very fast thus they need to be big. Bandwith x speed.
The'res not enough space.


>
> >
> > > We can always have evolution create a efficient decoder ;-)
> > > https://www.damninteresting.com/on-the-origin-of-circuits/
> >
> 
>
> Sincerely,
> David
>
> ___
> arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netb...@files.phcomp.co.uk
>
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[mike.v...@gmail.com]

2017-05-08 3:34 GMT+02:00 :

> I apologize for DOS'ing the list, I can only get online about once a week.
>
> On Thu, 4 May 2017 17:13:23 +0200
> "mike.v...@gmail.com"  wrote:
> >
> > 2017-05-04 9:04 GMT+02:00 John Luke Gibson :
> >
> > > Since it seems like a trivially simple task that for some reason no
> > > one has taken up, I would like to take the opportunity to exercise a
> > > learning experience and simultaneously benefit the community, by
> > > liberating PocketCHIP by deblobbing the source and re-compiling.
> > >
> >
> > The PocketCHIP is powered by their SoM:
> > http://linux-sunxi.org/NextThingCo_CHIP
> >
> > That is apparently a Allwinner R8 pared with an external rtl8723bs
> > Wifi/BT chip.
> >
> > The R8 is a rebranded A13.
> What? I own one of those and I'm almost certain that the CPU is an A7.
> Let's boot the PocketCHIP up...
> The processor is detected as an A7.
>

It should be a Cortex-A8.
http://linux-sunxi.org/Allwinner_SoC_Family

The new chip GR8, which is specific SoC for NextThingCo, seems to be an "sun5i"
as well. Also a slightly modified A13 I guess.

The're seems to but mainline support for it. Icenowy Zheng has addid it I
think. But the'res no wiki page fo it.
http://linux-sunxi.org/Linux_mainlining_effort
http://linux-sunxi.org/GR8




> I'll attach the output, it would probably be interesting to see all of
> it...
> Done, it's compressed bzip2 since it's ~300KiB decompressed which is large
> for an email.
>

Use pastebin or sorts. Or just cut out the specifica part.


> Unless your saying that the WiFi has a built in ARM R8 (Why)? which would
> really surprise me considering how large the processor chip is compared
> with the WiFi chip.
>

I'm not saying that at all.The SoC is indeed  the biggest IC. And the WiFi
is on the other side of the PCB. A blue piece of PCB. next the NXP209. WiFi
chips are very small.
from https://getchip.com/pages/chip:
https://cdn.shopify.com/s/files/1/1065/9514/t/28/assets/chipAllSidesView.png?9186386361907538453


> You're not giving us enough details. Who is Verhaegen? What did he burn
> out on?
> When I first considered purchasing a PocketCHiP I read about the GPU
> not having 3D capabilities because of a binary blob. So, the CHIP folks
> hired (I think it was an extended goal of the kickstarter campaign), a
> kernel dev to add support to the Linux kernel for the GPU.


That did not happen. The're is no Opensource linux driver for MALI. NTC
hardly involves itself with the linux-sunxi community.

Their website is hardly obvious to the software needs of running their
hardware.

How hard can it be

"To use our hardware you have two options: Our BSP which has closed source
drivers, but you have full utilization of the hardware. Or use the mainline
kernel with some restrictions"

And state your involvement in freeing the hardware or not.

NTC website is just one big selling machine.


> I was going to
> mention this on this list before, but it's been so active...
>
> Sincerely,
> David
>
> ___
> arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netb...@files.phcomp.co.uk
>
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] firefly 3399 all source software disclosed?

[mike.v...@gmail.com]

2017-05-08 11:02 GMT+02:00 Bill Kontos :

> I think arm has open source kernel drivers but there is no way they will
> get mainlined any time soon. The question is, how much does the userland
> blob do and how much work needs to be done to get libre 2d accel.
>
A display pipeline is a complex one which requires multiple drivers.
Especially on ARM devices where the display pipeline is a "mix and match"
one.

So ARM has released a "driver". What type of driver? What functions does it
have?

Is it one for their display encoder, a crtc driver? A framebuffer driver? A
clasic DRM driver, A KMS driver? A 2D Accelerator for X? A 3D accelator. A
shim to acces the hardware using a BLOB build for one specific version of X
relying  and kernel on a specific ARM Core design? Probably the last.

And ARM specific driver without sources is worthless. It's use once and
only for short time.

SoC with ARM desing are mix and match. Different ARM core designs.
Different and mixed GPU's MALI, Vivante, PowerVR, etc. Output (CRTC etc)
from all type of different vendors ARM, Designware, etc. Most of the time
the manufacture is not disclosed.

If you look at Allwinner. The community now has two display engine drivers.
The drivers only setup output and change video modes. GPU type is MALI.

Bealebone has TI SoC for which a KMS/DRM driver was written by Rob clark,
tilcdc, which has support for a NXP HDMI controller/encoder. It also has a
2d accelerator from vivante and a 3d accelatror from Imation(powerVR).

With the recent release of the etnaviv driver the BB community wrote a
patch to have 2d acceleration.

Etnaviv and Freedreno had a hard time being included into the Linux
projects because of their mix and match nature. A single driver was
impossible.

I've once had bought an Atom mini laptop (Dell Mini 1010). Which I
explicitly bought because of the most powerful Intel ATOM GPU at the time.
Intel has a reasonable Opensource GPU track record. Poulsbo turned out to
be an Imation PowerVR licenced design. Boy was I misled: no opensource
drivers only blob's compatible with aging and broken kernels and X-servers.
So no upgrades for me or anyone else.

So a perfectly capable laptop to the trash.

Intel did release a Opensource driver. A KMS driver. So that means
modesetting and nothing more. No 2d acceleration no 3d acceleration nog
hardware video decoding. Intel could not build anything better because
Imation did not let them. The Intel engineer said that there was enough
code and documentation available to create decoder though. But he didn't
write it.

This is way closed source drivers a bad idea. They limit the use and
lifetime of your devices.

I guess the company's building those GPU are too scared that if they open
their drives their competitors see the copyright and/or patent infringement
their design has.

And ARM and Imation are scared the most.

Thankfully Imation is going to die soon. Apple has announced to create
their own GPU. and rob Imation from 60% of their income. Imation anounced a
patent war agains Apple. SCO Unix anyone?



> On May 8, 2017 7:47 AM, "Luke Kenneth Casson Leighton" 
> wrote:
>
>> ---
>> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>>
>>
>> On Sun, May 7, 2017 at 10:10 PM, zap  wrote:
>> >
>> >
>> > On 05/07/2017 04:29 PM, ronwirr...@safe-mail.net wrote:
>> >> All software for the mali-t860 is open source?
>>
>>  none.  MALI is proprietary.
>>
>> ___
>> arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
>> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
>> Send large attachments to arm-netb...@files.phcomp.co.uk
>
>
> ___
> arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netb...@files.phcomp.co.uk
>
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] firefly 3399 all source software disclosed?

[mike.v...@gmail.com]

2017-05-08 16:39 GMT+02:00 Bill Kontos :

Please don't top post. Gmail has inline capability.

> Imagination is far from dead yet. They did a mistake when they based all
> of their gpu income on apple, but their ip is rather advanced.
>

ImgTec income is going to be cut by 60%. That's not something most
companies can survive.

Their plan is to sue Apple for using of their IP and forcing them te keep
paying royalties.

To fund that they are selling of vital parts, like the recently aquired
MIPS.
, to fund the legal fees and supplement their loss of income.

Apple will stall, they have the money to do so, and probably force them to
trial. In trail ImgTec is forced to disclose publicly what they think
belongs to them. Which they will be reluctant to do because then the other
GPU manufactures might be able file suits for infringement to ImgTec.

Hence my reference to the SCO suit against Linux users. Which ultimately
failed and killed the company.

The same issue for them is they open up their driver sources.

All GPU manufactures are bound to infringement because sometimes things are
invented twice or more at different places. Which makes sense when you're
trying to reach the same goal with the same means and knowledge.

If only they'd sit around and say let's all open up our drivers and not sue
each other for current design and start over from there.

I'll be surprised if they'll survive this. Apple has probably tried to buy
and failed so they move to kill. This is join us or die tactics. And Apple
has more money thus is able to strike harder and longer.

Also on the plus side there has been discussion about them open sourcing
> their drivers a few months back and afterwards they hired new developers. I
> wouldn't be surprised if they actually saw this coming and reacted before
> it happened.
>

ImgTec has been holding that bone for our noses for years. Ten to be exact
Poulsbo dates from 2007. I don't believe it until it's proven.

So if I'd place a bet to
1. ImgTec releasing sources
2. ImgTec dying from Apple lawsuit

I'd place on the second one. Their selling long term part for short term
money for a lost cause.

The only winning parties here are going to be the lawyers just like with
SCO.


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

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[mike.v...@gmail.com]

Don't top post please

2017-05-08 17:23 GMT+02:00 :

>  Original Message 
> From: Bill Kontos 
>
> > Verhaegen is one of those selected individuals who had the luxury of
> getting all the shit of the world thrown at their face for trying to do the
> right thing. He was one of the leaders in pushing amd into mainlining gpu
> drivers( which they have been successful to and keep working on)  and got
> shit for that. He attempted to reverse engineer the arm mali drivers( look
> up lima driver) and he succeeded to some extend, then he run out of money
> becaue nobody was willing to help him and arm has put significant effort
> into destroying his life.  The nda a company has to sign for getting the
> mali drivers requires 0 interaction with his work, therefor no company can
> hire him now.
>
"Is it common to do something like this against a person?"

No but not uncommon as well. Luc pressed were it hurts and Luc has a
somewhat unfiltered personalty. Manager etc. usually have filtered
personalities.

Managers also usually people with little technical insight and need to rely
in information from others, the lack of information makes for easier
decision making is the though here. And usually those that talk smooth are
easier to listen to than those with an sound opinion, those are usually
spoken loudly and don't concur with the mainstream thoughts.

ARM was afraid of lawsuits for infringement and loss of income by the
details Luc might unveil on his RE quest.

This is how politics and business works.


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

Re: [Arm-netbook] Totally derailed topic

[mike.v...@gmail.com]

2017-05-09 10:45 GMT+02:00 Lyberta :

> do...@mail.com:
> > I think you're caught in the same trap, unable to realize your own
> > potential for lack of a moral standard (it also suffers as a result of
> > an Atheistic philosophy), and unable to accept a pointless existence.
>
> When I was 19, I was in a very bad situation. Everything I've ever
> believed in was false. So I've spent the next 6 months looking for
> truth. Thankfully, I have dropped out of college by this time so I had
> time to investigate.
>
> And in one moment it dawned upon me. There is no truth. Everything is
> relative. People invent their own truth and start believing in it. So if
> I want to stay unshackled I must not believe in anything.
>

There are many truths but non come close to reality.


>
> The next thing was supposed to be suicide but I couldn't do it. I don't
> know the future and I don't know what will happen when I die. In fact,
> I'm trapped inside my own consciousness and by definition can't escape
> it and see the truth. Remember Plato's allegory of the cave?
>
> Another thing that bugs me is, since I don't believe in anything, I also
> don't believe in science. I can't predict what's gonna happen in the
> next moment. Every once in a while I get in this state of mind where I
> understand that I understand nothing.
>

Believe that you are here. Your time here is brief. Enjoy it while you can.


>
> > In any and all cases I think you might enjoy a book that is eyeopening,
> > insightful and uplifting, with respect to the world around you, as
> > opposed to your more dreary, despairing, world view.
>
> I was forced to read books at school and this gave a huge hatred for
> them. I remember I've tried to read a fiction book at psychiatric
> hospital and after the 1st paragraph I was so enraged that I quickly put
> it away. Though this mostly applies to fiction.
>

You can't control anything but a small part of yourself.

You do however have a choice. Not making a choice is a choice itself.

The're is no thing in this world that you must but one thing: Undergo the
results of your choice.

Getting enraged by books is a choice.

Don't get overwhelmed. When that happens you'll panic and reason will
vacate your mind.

You are allowed to believe in things that are not real.

Science is not a fixed thing. It's an ever changing truth towards reality.
http://chem.tufts.edu/answersinscience/relativityofwrong.htm

Religions mostly advocate absolute truth. There is no absolute truth.

Sience is knowing that your viewing the universe through a keyhole and you
are probably be wrong in your assessment of what you see.

Accept that you'll need to base your choices on what you know now. You
cannot make choices based on things you might come to know.

Relax and live. It is worth your time. Don't anger yourself on ignorance of
others. But don't think you are above another. We're all different. Be
proud of it.

This life might just be a test for the next. And the more/fuller you live
the bigger your obstacles you must overcome. At least that's how I see it.


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

Re: [Arm-netbook] Totally derailed topic

[mike.v...@gmail.com]

2017-05-09 11:48 GMT+02:00 mike.v...@gmail.com :

>
>
> 2017-05-09 10:45 GMT+02:00 Lyberta :
>
>> do...@mail.com:
>> > I think you're caught in the same trap, unable to realize your own
>> > potential for lack of a moral standard (it also suffers as a result of
>> > an Atheistic philosophy), and unable to accept a pointless existence.
>>
>> When I was 19, I was in a very bad situation. Everything I've ever
>> believed in was false. So I've spent the next 6 months looking for
>> truth. Thankfully, I have dropped out of college by this time so I had
>> time to investigate.
>>
>> And in one moment it dawned upon me. There is no truth. Everything is
>> relative. People invent their own truth and start believing in it. So if
>> I want to stay unshackled I must not believe in anything.
>>
>
> There are many truths but non come close to reality.
>
>
>>
>> The next thing was supposed to be suicide but I couldn't do it. I don't
>> know the future and I don't know what will happen when I die. In fact,
>> I'm trapped inside my own consciousness and by definition can't escape
>> it and see the truth. Remember Plato's allegory of the cave?
>>
>> Another thing that bugs me is, since I don't believe in anything, I also
>> don't believe in science. I can't predict what's gonna happen in the
>> next moment. Every once in a while I get in this state of mind where I
>> understand that I understand nothing.
>>
>
> Believe that you are here. Your time here is brief. Enjoy it while you can.
>
>
>>
>> > In any and all cases I think you might enjoy a book that is eyeopening,
>> > insightful and uplifting, with respect to the world around you, as
>> > opposed to your more dreary, despairing, world view.
>>
>> I was forced to read books at school and this gave a huge hatred for
>> them. I remember I've tried to read a fiction book at psychiatric
>> hospital and after the 1st paragraph I was so enraged that I quickly put
>> it away. Though this mostly applies to fiction.
>>
>
> You can't control anything but a small part of yourself.
>
> You do however have a choice. Not making a choice is a choice itself.
>
> The're is no thing in this world that you must but one thing: Undergo the
> results of your choice.
>
> Getting enraged by books is a choice.
>
> Don't get overwhelmed. When that happens you'll panic and reason will
> vacate your mind.
>
> You are allowed to believe in things that are not real.
>
> Science is not a fixed thing. It's an ever changing truth towards reality.
> http://chem.tufts.edu/answersinscience/relativityofwrong.htm
>
Found a more complete one:
http://hermiene.net/essays-trans/relativity_of_wrong.html


>
>
> Religions mostly advocate absolute truth. There is no absolute truth.
>
> Sience is knowing that your viewing the universe through a keyhole and you
> are probably be wrong in your assessment of what you see.
>
> Accept that you'll need to base your choices on what you know now. You
> cannot make choices based on things you might come to know.
>
> Relax and live. It is worth your time. Don't anger yourself on ignorance
> of others. But don't think you are above another. We're all different. Be
> proud of it.
>
> This life might just be a test for the next. And the more/fuller you live
> the bigger your obstacles you must overcome. At least that's how I see it.
>
>
>>
>>
>> ___
>> arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
>> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
>> Send large attachments to arm-netb...@files.phcomp.co.uk
>>
>
>
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] I saw your recent update, Luke

[mike.v...@gmail.com]

2017-05-09 12:55 GMT+02:00 zap :

>
>
> On 05/09/2017 04:32 AM, Bill Kontos wrote:
>
> Something that crossed my mind, does the lack of flash mean we can now
> update to kernels newer than 3.x ?
>
>
> Just a thought but I believe top posting annoys Luke.
>

 Bill didn't know how to post in-line. But we figured it out right Bill?
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] I saw your recent update, Luke

[mike.v...@gmail.com]

2017-05-10 4:34 GMT+02:00 Kyle :

> Damn. You know a list has been taken over by posting nazis when entire
> threads get hijacked just to tell anyone who cares to listen that someone
> top posted, and that breaks someone's flow.
>

I'm not seeing any of that. The inline posting is simply the format chosen,
for various reasons, on this list. Everyone from the "Outlook" world is
unfamiliar with type of communication, that was including me.

But I find the inline posting quite refreshing. And doesn't require an
email client capable of "story-lining". And helps with addressing multiple
issues and responses in one thread.

 TL;DR

Thanks for your point of view. But I wonder who's the posting n..i here.

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

Re: [Arm-netbook] EOMA68 card based on NXP i.MX7 (work in progress)

[mike.v...@gmail.com]

2017-05-09 22:53 GMT+02:00 Vincent :

> Hi everybody,
>
> Since this is my first post on this list, please allow me to get off my
> chest a few things:
>
> - huge thanks to Luke for getting this project started
> - me = funding a PFY laptop, eagerly awaiting for it to arrive ;-)
> - me = working at a research institute, focused on hardware security
>
> As a private individual but also as at work, having an EOMA68 card based
> on an NXP i.MX7 would be very useful. It is a powerful processor with a
> heterogeneous architecture (2x A7, 1x M4) which makes it an interesting
> choice for energy-limited applications (M4 can turn off/on A7) and
> scenarios where safety/security are important (M4 can do real-time aside
> from workload on A7).
>
> The i.MX7 has many useful security features (crypto accelerators,
> high-assurance boot, TrustZone, etc.).
>
> An initial check with the EOMA68 infrastructure indicates compatibility.
>
> My personal goals with this are as follows:
> - Create an EOMA68 card with i.MX7 to complement my research (in fact, I
> simply need a good demo for the stuff I'm doing)
> - Provide the community an even better microprocessor card
> - Have a complex PCB project to learn along the way (I did PCB designs
> beforehand but never that complex)
>

Looks like a good objective. The i.MX display pipeline is reasonably
reverse engineered to have a full open open source experience.

Reading this list I guess you'll need a few things before you start:
1. Check is the i.MX7 fits the powerprofile
2. Find a reference design. NDA free
3. Check if the i.MX7 has all required outputs. Or needs converter IC's
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[mike.v...@gmail.com]

2017-05-10 16:38 GMT+02:00 Luke Kenneth Casson Leighton :

> On Wed, May 10, 2017 at 3:23 PM, Pablo  wrote:
>
> > With any non-Chip-kernel you will lose NAND support.
> > So you can either:
> > a)patch your libre kernel
> > or
> > b) ignore NAND and use flash memory via usb port.
> >
> > For b) you will need mainline U-Boot because NextThings U-Boot fork
> > supports NAND but not booting via usb.
>
>  this sounds weird / not quite right. the R8 (aka A13, aka the A10)
> should be able to use the same sunxi 3.4.104+ kernel source as i've
> been using for the A20, which has the (sunxi, libre) NAND driver in
> it.  afaik they didn't change the NAND hardware from the A10/A20 to
> the A13 to the R8 so this should be a non-issue.
>
>  also from what i gather there's been mainline support for the
> (completely different, MTD-compatible) NAND driver for quite some
> time, so again, should be a non-issue.
>
>  perhaps someone could ask on #linux-sunxi and/or their mailing list
> for confirmation of the facts?

Wiki says "work in progress"

http://linux-sunxi.org/Mainlining_Effort
http://linux-sunxi.org/NAND (Fun facts on supported NAND)
http://linux-sunxi.org/MTD_Driver

https://groups.google.com/forum/#!searchin/linux-sunxi/mtd%7Csort:relevance

Boris has commit access so it's probably all there since 4.7

His work and derivatives did touch a lot of NAND/MTD drivers though.

Someone needs to crawl the linux kernel commits though or ask directly.
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] Totally derailed topic

[mike.v...@gmail.com]

2017-05-11 0:44 GMT+02:00 Luke Kenneth Casson Leighton :

> On Wed, May 10, 2017 at 10:23 PM, zap  wrote:
>
> > it is sad because they think they will be rewarded at the end. But they
> > already have their temporary very short term reward. Though they deserve
> > it, I feel a mixture of pity and anger towards them.
>
>  steady, zap: i struggle with anger towards people who've betrayed me
> (etc.) - so i'm not the person to say "don't do that"... even though i
> know it's doing *me* harm to be so angry i can't even sleep at night,
> sometimes.  what i would like to say is: f you manage to get your
> anger under control, do tell me how you managed it, ok? :)
>

If the effect is not immediate we have the tendency to ignore. "I'm driving
200Km/h on the high way without crashing for four days so what's the
problem? Let's up it another 10"

When other people do things that "hurt" you the first reaction might be
anger. We immediately think that they hurt us on purpose. But in fact
70-90% time they are just doing what suits them. Not on purpose to you and
blissfully unaware of the effects it has on you. You vent you anger and
hurt them back. Only to be repaid with more hurting and anger. So anger
might not be your best response. It is however a natural one. Just like
tensing on impact while release might be a better one.

But beware of the trap that you disallow yourself to feel hurt because they
didn't do it on purpose. They did hurt you and they need to stop their
behavior even though it might be even unconsciously.

With hurt I mean it in a widest sense every form of mental of physical pain
on any level from touch to damage, from discomfort to inability.

The mental pain is a perceived one and with change of perception you can
alleviate the pain.


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

[Arm-netbook] What's your EOMA card doing

[mike.v...@gmail.com]

Let's have a "What's your EOMA card doing" site so the world can see where
and how long cards are alive and what use they have.

Perhaps have each card have a, printed, unique number. So it's journey can
be followed.

This obviously has security and privacy issues attached so it would need a
lot of thinking through.

What does everyone else thinks of this?
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] mali gpu reverse engineering lkcl may ignore

[mike.v...@gmail.com]

2017-05-22 0:06 GMT+02:00 :

> Because I deleted a previously email about this subject, I start a new
> email.
> Info. Lkcl said, he is not in favor of reverse engineering a mali gpu.
> Because it is about 15eu and new gpus will emerge during the reverse
> engineering and the outcome is uncertain.
>
> I agree on his arguments.

I assume you don not agree.

 15eu is a crowd funding of 3 people, each 5eu. I would pay an
> extra 5eu to be able to buy a source code computer.
>

Th issue with revese engineering the MALI gpu's is not justs about money.
ARM ltd. actively Seeks and destroys attempts on a OSS mail driver.

So that money needed is not only going to coding but is probably also
needed for legel fees and marketing against the smear and laster campaign.

They have already made one person's life very difficult:
http://libv.livejournal.com/


> I do not know if 3 people are interested or if they can agree on one
> board.
>

But freeing MALI would help a lot of devices out there. So I'd trough in
some bucks. RE'ing MALI would not be for just one board.



> You cannot get the mali source code faster, if you put more people on it?
>

Finding the right minds and right amount of them working on the same thing
is a hard equation.

You could add me to that team but my skills would be of limited use. Adding
someone of the same skill set would probably be even less effective.

So more money or more people is not the solutions. The right people and the
right amount is needed.


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

Re: [Arm-netbook] designing a low-cost decent 3d printing board

[mike.v...@gmail.com]

2017-05-23 3:27 GMT+02:00 Luke Kenneth Casson Leighton :

> hi all,
>
> ok so i've been looking around and the practice of creating a
> "modular" 3d printing electronics board is extremely common, thanks,
> many years ago, to the stupid, stupid decision to use prototyping
> (evaulation) plugin boards with 1.3 to 2.0 *amp* stepper ICs mounted
> onto micro-postage-stamp-sized PCBs.  the problems these cause are
> endless.
>

You're being a bit brief here. But essentially, the community has been
using "default" boards, which are cheapish and fairly
documented/understood, but too generic and thus not able enough?


> so instead of an on-board ATSAM4, you use an arduino due.  instead of
> WIFI you use a *standard arduino WIFI shield*.
>

Read about a guy RE'ing "hoverboards" and he's creating an OSS firmware
replacement for these, which seem to be desinged around the fafourite
STM32F*.
https://opensourceebikefirmware.bitbucket.io/About_the_project.html

But how about the ESP32? (Successor to the ESP8266). Reasonable beefy CPU
with build in WiFi. The Duet is using the ESP8266 as the WiFi bridge.

now, debatable is whether to split out the MOSFETs, endstops and
> thermistors into their own separate shield as well, which i feel might
> be sensible.
>

Why not place all controllers separately and direct to their HW and connect
them via a bus? This gives you freedom to expand and replace. And use a
EOMA card as the "master"?

Or would that kind of modularity up the costs too much?
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] GR8 based EOMA68 card

[mike.v...@gmail.com]

2017-05-21 1:45 GMT+02:00 Luke Kenneth Casson Leighton :

> the layout's hilarious: the PCB is over 50% completely empty.  what i
> haven't done is:
>

Would it make sense to add a small LiPo battery, to fill the empty space?
That way you can swap a card from one housing to another, without the need
to reboot.
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] $150 taobao knock-off 3d printer doing 200mm/sec

[mike.v...@gmail.com]

2017-05-28 4:49 GMT+02:00 Luke Kenneth Casson Leighton :

> On Fri, May 26, 2017 at 3:25 AM, Luke Kenneth Casson Leighton
>  wrote:
> > https://www.reddit.com/r/3Dprinting/comments/6de5sv/
> looking_for_ways_to_maximise_the_mm_sec_metric/
> >
> > ok so i asked on reddit, let's see if anyone pitches in...
>
> ... they did! wow!  so i updated the post, and did another test part,
> that was at 175mm/sec on a layer height of 0.15 (nozzle is still
> 0.4mm) and that came out far better than i expected, too.
>
>  i'm really excited by how the quality's turning out for such a low
> investment.  i still haven't added a nozzle fan yet!  i did however
> stiffen up the frame somewhat with more wood-working 50mm steel corner
> triangles.  the bracing's not perfect but seems to be having an
> appreciable improvement.
>

I might have missed it but: Do you need/want other people running the
finalized modification of this printer? This to parallelize and globalize
the build of the laptop parts? If so is there list were you can people can
sign up?


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

Re: [Arm-netbook] $150 taobao knock-off 3d printer doing 200mm/sec

[mike.v...@gmail.com]

2017-05-29 17:11 GMT+02:00 Luke Kenneth Casson Leighton :

> On Mon, May 29, 2017 at 11:39 AM, Luke Kenneth Casson Leighton
>  wrote:
> > On Mon, May 29, 2017 at 9:54 AM, mike.v...@gmail.com
> >  wrote:
> >
> >> I might have missed it but: Do you need/want other people running the
> >> finalized modification of this printer?
>
>  that and also i would like to do an experimental design as well:
>  http://forums.reprap.org/read.php?177,767087,770804#msg-770804
>
>  the idea is to have a double pulley arrangement which will provide
> balanced forces acting as far apart as possible, but also with a 4x
> multiplier on the force thanks to the twin pulleys.
>
>  also i plan to use double rods rather than single because double rods
> will turn any "twisting" (rotation) of the rods into a side-loading
> force against the linear rails.  the further apart the rods are the
> more effective the leverage preventing "twisting", but they can't be
> too far apart else the carriage has to be too big, and also the rods
> have to be much longer...
>
> ... i was thinking of starting with a distance of 70mm between rod
> centres and seeing how that goes.  should mean i can use 300mm rods.
>

I remembered an post from Hackaday.
http://www.doublejumpelectric.com/projects/core_xy/2014-07-15-core_xy/



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

Re: [Arm-netbook] $150 taobao knock-off 3d printer doing 200mm/sec

[mike.v...@gmail.com]

2017-05-29 12:39 GMT+02:00 Luke Kenneth Casson Leighton :

> On Mon, May 29, 2017 at 9:54 AM, mike.v...@gmail.com
>  wrote:
> > If so is there list were you can people can sign up?
>
>  i hadn't thought that far ahead!  hmmm, let's add it to the libre
> laptop page for now:
>  http://rhombus-tech.net/community_ideas/laptop_15in/casework/
>
> l.
>
Looks like I've been signed up ;-)
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[mike.v...@gmail.com]

2017-05-29 23:37 GMT+02:00 David Niklas :

> On Mon, 08 May 2017 09:59:50 +0100
> "mike.v...@gmail.com"  wrote:
> > 2017-05-08 3:34 GMT+02:00 :
>
> Sorry, I (foolishly) though that ARMv7 == A7 (i.e. a contraction).
>
Don't worry that is  common one.

>
> >
> > > I'll attach the output, it would probably be interesting to see all of
> > > it...
> > > Done, it's compressed bzip2 since it's ~300KiB decompressed which is
> > > large for an email.
> > >
> >
> > Use pastebin or sorts. Or just cut out the specifica part.
> >
>
> Sorry, I thought the rest of it might be useful to look at.
>

It might be. That's why I suggested pastebin et al. Those are better for
public mailinglists than zipped files.


>
> 
> > > You're not giving us enough details. Who is Verhaegen? What did he
> > > burn out on?
> > > When I first considered purchasing a PocketCHiP I read about the GPU
> > > not having 3D capabilities because of a binary blob. So, the CHIP
> > > folks hired (I think it was an extended goal of the kickstarter
> > > campaign), a kernel dev to add support to the Linux kernel for the
> > > GPU.
> >
> >
> > That did not happen. The're is no Opensource linux driver for MALI. NTC
> > hardly involves itself with the linux-sunxi community.
> >
> > Their website is hardly obvious to the software needs of running their
> > hardware.
> >
> > How hard can it be
> >
> > "To use our hardware you have two options: Our BSP which has closed
> > source drivers, but you have full utilization of the hardware. Or use
> > the mainline kernel with some restrictions"
> Where is that quote from?
>

No ware. It was suggestion from me for them. That's what I would like to
see on all those sites selling this type of s*ht.

Be honest, be open. Don't façade the truth. It will come out and it will
bite you.

I don't believe the quote above would scare any potential buyer. The fact
they don't mention it while I know it is a reason I wouldn't buy from them.

It's like selling a car of which they have painted over rust and rewinded
the odo-meter. On first glance it looks terrific but when you find the
truth it will leave you angry and you'll go and tell everyone you know not
to buy from them.

So whenever I see a fancy site trying to sell a product of which I know the
limitations and they hide it: They become unreliable to me and I'll move
one and suggest to everyone that want's to listen to do the same.

Sadly that's the state of all vendors today. So everybody buy a crappy
painted over car with hardly any km/miles on it. ;-)
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] libre 64-bit risc-v SoC

[mike.v...@gmail.com]

2017-05-29 23:24 GMT+02:00 David Niklas :

> On Mon, 8 May 2017 06:24:08 +0100
> Luke Kenneth Casson Leighton  wrote:
> > On Mon, May 8, 2017 at 4:00 AM, David Niklas  wrote:
> 
> > >> > important to avoid, because mixed analog and digital is incredibly
> > >> > hard to get right.  also note that things like HDMI, SATA, and even
> > >> > ethernet are quite deliberately NOT on the list.  Ethernet RMII
> > >> > (which is digital) could be implemented in software using a minion
> > >> > core.  the advantage of using the opencores VGA (actually LCD)
> > >> > controller is: i already have the full source for a *complete*
> > >> > linux driver.
> > >
> > > Considering that analog was around *long* before digital I'm surprised
> > > that it is "Hard to get right",
> >
> >  analog isn't "hard".  digital isn't "hard".  specifically *MIXING*
> > them is ultra-hard.
> >
> > > is there a reason for this?
> >
> >  completely different processes and design criteria.  the restrictions
> > (design rules) placed on digital ASIC layouts have to be adhered to in
> > the *analog* areas: you can't just change the stack to suit the analog
> > areas.  i don't know the full details, but i know someone with 30
> > years experience of working with ASICs who does.
> >
> > > Isn't there a chip for just this kind of thing?
> >
> >  no.  not a custom one... and we're taking custom ASICs.
>
> Forgive me for contradicting you again, but don't all computers that have
> a MIC in jack using some sort of analog to digital converter?
> And vice-versa with Headphone out?
> I think they all use PCM.
> Would such a converter be suitable? Why?
>

Crosstalk

Plug in your headphones in a laptop and listen to computer hard at work.

The speed of current digital signals makes them behave like analog signals.
And as such analog signals interfere with the digital signals.

With cables you can use shielding to mitigate that. On PCB's and inside IC.
That's a lot harder because of their stacked nature.


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

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[mike.v...@gmail.com]

2017-05-30 4:36 GMT+02:00 Luke Kenneth Casson Leighton :

> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>
>
> On Mon, May 29, 2017 at 10:48 PM, David Niklas  wrote:
>
> > I am just a tad confused.
> > 1. You started a reverse engineering project on NT domains.
> > 2. You presented your success to MS as a security problem.
>
>  and also a collaboration and interoperability opportunity (which
> worked extremely successfully).
>
>  and it also galvanised them to do a proper documentation effort.
> basically there wasn't any.  at all.  the code had been organically
> develeped by engineers that were getting on for retirement age.  as
> they were the only ones left who understood the security implications,
> they began a rather urgent process called the "CIFS Initiative" to
> document the protocol so that their *own engineers could understand
> it*.
>
>  frickin funny, really.
>
> > 3. You were hired.
> > 4. Someone in MS complained.
>
>  some fuckwit in the brain-washed marketing department, yes.  what's
> hilarious is that microsoft's own employees - the ones with good
> reputations and standing - had to tell this particular specimen of
> brainwashed fuckwittery, "you _do_ realise what this one individual
> could do to our company if you ever pissed him off??"
>
>  :)
>
>
> > So, the FLOSS folks never saw your work anyway?
>
>  they did and they resented it, very very badly.  the so-called
> leaders of the samba team *really* did not like the fact that i knew
> more than them about MSRPC, and that the work that i spearheaded
> increased the codebase of samba at the time by a whopping THIRTY
> PERCENT.
>
>  so they engineereed a way to get me out.
>
>  by 2003 someone in the FLOSS community tracked my work on Exchange
> 5.5 reverse-engineering, copied it, reimplemnted it, and did not tell
> anyone that i was the one who had done the reverse-engineering.
>
>  20 years later samba is considered to be a failure.  samba 4 was
> something like 10 years in the making, and yet failed to deliver.
> companies that had held on to samba 3, which the samba developers
> STOPPED work on because they didn't understand it properly, were
> struggling to keep it up and running and were totally incensed when
> samba 4 was finally released and was even worse and even harder to
> configure.
>
>  they pushed me out and FLOSS has suffered as a result, because the
> complexity is so high it's beyond their ability to cope.
>

You're sounding like libv here ;-)


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

Re: [Arm-netbook] revision control in the arts?

[mike.v...@gmail.com]

2017-06-06 15:47 GMT+02:00 Hendrik Boom :

> On Mon, Jun 05, 2017 at 05:47:35PM -0400, John Luke Gibson wrote:
>
> For word processing, I think the only good solution is a document
> compiler, with the writer editing the source code.
>

The're is a way for arbitrary documents so work with version control.
conversion to an intermediate format like markdown.
http://blog.martinfenner.org/2014/08/25/using-microsoft-word-with-git/
https://github.com/vigente/gerardus/wiki/Integrate-git-diffs-with-word-docx-files

It uses pandoc to convert to markdown and then to git.

Found it on hackady
http://hackaday.com/2017/05/23/stupid-git-tricks
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] bunnie about riscv

[mike.v...@gmail.com]

2017-06-12 2:02 GMT+02:00 Neil Jansen :

> On Sun, Jun 11, 2017 at 4:38 PM,  wrote:
>
> > We should have libre software hdds and ram.
>
> Can you elaborate on that a bit?  I don't understand what you mean.
>

It's the same principle as explained by bunnie in the video. HDD and RAM
process all the data. But they have hard/soft programming which proces that
data.

If you can't audit the hard/soft programming then you don't know if your
data is being read/copied/manipulated.

http://spritesmods.com/?art=hddhack

More and more hardware is using CPU to function. And thus have soft
programming (firrmware) which can be altered.
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] EOMA68-A20 2.7.4 pre-production prototypes received and working

[mike.v...@gmail.com]

2017-06-16 8:19 GMT+02:00 Luke Kenneth Casson Leighton :
>
>
>  there's not really any other options: you can see how little
> clearance there is to the edge of the board: it's flat-out impossible
> to bring tracks in either in between those two sets, or round the
> back... and you don't want to anyway: they're differential pairs (up
> to 1ghz clock rate) because this is HDMI.
>

Hmm. Then how are other users of this connector doing it? This seems like a
generic problem. The solder technique is generic afaikt.
1. Either they are using smaller width tracks and are passing between the
left hand pads.
2. They have via's right to the pads. But that's very close to the edge.

The options I see...
. find other schematics using this connector.
. Use smaller width tracks.
. Cut the pads tight a little shorter and place the via's to the right
creating a bottleneck but stil far enough from the edge
. The above but to the left, via's in the middle.


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

Re: [Arm-netbook] EOMA68-A20 2.7.4 pre-production prototypes received and working

[mike.v...@gmail.com]

2017-06-15 21:01 GMT+02:00 Luke Kenneth Casson Leighton :

> okaay so the HDMI connection isn't so hot on these 2.7.4 boards.  it
> works... but there is significant line-interference under certain
> circumstances, even for 720p50.  1080p60 there is huge amounts of
> interference resulting in green horizontal lines.  *sigh* i'll just
> have to have another go at the layout... blech.


How about having GND tracks parallel to each Tx/Rx pair. Creating a sink
for EM signals to drain into instead of crossing over.

---GND0
---Tx--[ ]
---Rx--[ ]
---GND0
---Tx--[ ]
---Rx--[ ]
---GNDo
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] EOMA68-A20 2.7.4 pre-production prototypes received and working

[mike.v...@gmail.com]

2017-06-16 8:54 GMT+02:00 Luke Kenneth Casson Leighton :

> On Fri, Jun 16, 2017 at 7:51 AM, mike.v...@gmail.com
>  wrote:
> > . Use smaller width tracks.
>  can't.
>
Was afraid of that

>
> > . Cut the pads tight a little shorter and place the via's to the right
> > creating a bottleneck but stil far enough from the edge
>
>  possible.
>
> > . The above but to the left, via's in the middle.
>
>  possible but risky.
>

Depends on how near to can get to left hand pads or the egde on the right
and were the pads in the connector have most tolerance.

Speaking of near the edge. The tracks on the board seem awfully close the
boards cutoff edge. Doesn't that create a problem for cutting them out?
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] EOMA68-A20 2.7.4 pre-production prototypes received and working

[mike.v...@gmail.com]

2017-06-16 9:07 GMT+02:00 Luke Kenneth Casson Leighton :

> On Fri, Jun 16, 2017 at 8:03 AM, mike.v...@gmail.com
>  wrote:
> >
> > Speaking of near the edge. The tracks on the board seem awfully close the
> > boards cutoff edge.
>
>  yyep they are.
>
> > Doesn't that create a problem for cutting them out?
>
>  no but it does cause an imbalance in the differential pairs unless
> the tracks come in dead-straight from the left, and it also means that
> ground shielding isn't possible.
>
>  normally the connector would be at least 20-30 mil away from the edge
> so that ground vias could be placed all along the right-hand edge.
> that's near-flat-out impossible.  the best that can be hoped for is
> that the three pins (in grey) which are GND will do the job of
> creating an EMI shield instead.
>

I was talking about the photo's not the connector.
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] EOMA68-A20 2.7.4 pre-production prototypes received and working

[mike.v...@gmail.com]

2017-06-16 8:55 GMT+02:00 mike.v...@gmail.com :

>
>
> 2017-06-15 21:01 GMT+02:00 Luke Kenneth Casson Leighton :
>
>> okaay so the HDMI connection isn't so hot on these 2.7.4 boards.  it
>> works... but there is significant line-interference under certain
>> circumstances, even for 720p50.  1080p60 there is huge amounts of
>> interference resulting in green horizontal lines.  *sigh* i'll just
>> have to have another go at the layout... blech.
>
>
> How about having GND tracks parallel to each Tx/Rx pair. Creating a sink
> for EM signals to drain into instead of crossing over.
>
> ---GND0
> ---Tx--[ ]
> ---Rx--[ ]
> ---GND0
> ---Tx--[ ]
> ---Rx--[ ]
> ---GNDo
>
>
Looking at the schematics I see that is already being done. I do however
see a lot of gaps between GND tracks. Especially on the blue layer.

Too bad the HDMI pads are so close to each other otherwise you could have
had a GND  track run between them fully enclosing the HS pads.

To the left I see that all HDMI tracks are routed trough some chips. What
are those? Magnetics, impedance matchers? I mention that because on the
blue tracks the'res a log of extra track for matching track length. maybe
that should that be done before those chips.

Also the pads are shortened. I hope that's on purpose.


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

Re: [Arm-netbook] EOMA68-A20 2.7.4 pre-production prototypes received and working

[mike.v...@gmail.com]

2017-06-16 9:33 GMT+02:00 mike.v...@gmail.com :

>
>
> 2017-06-16 8:55 GMT+02:00 mike.v...@gmail.com :
>
>>
>>
>
> To the left I see that all HDMI tracks are routed trough some chips. What
> are those? Magnetics, impedance matchers? I mention that because on the
> blue tracks the'res a log of extra track for matching track length. maybe
> that should that be done before those chips.
>

Just a design thought on track length. Because of impedance matching HF
tracks should be of equal length. And to minimize their EM emission the
need to run parallel. But when changing direction you get an inner and
outer track where the outer track becomes longer. To mitigate that you have
those curly lines scattered around, usually at the end. Those cost a lot of
room.

Since the schematics already show two layers with HF signal tracks why not
place the Tx and Rx track on top of each other. Result: Parallel tracks.
And very close to each other. Equal lengths on "curves". And minimize the
curly tacks.

I know that this introduces issue when you need tracks crossing. But that
could be solved by cross bridging... Hmm how am I going to visualize that
in text

 T  R
 x  x
 |  |
   Tx_
  /  |  | \
 /   |  |  o
Tx/Rx---<|  |   >Rx/Tx
 o   |  |  /
  \Rx_/
 |  |
 |  |

ASCII art needs monospace font...

Tx/Rx on the left come in stacked. Before the bridge they split Rx passes a
via to the Tx layer. leaving the Rx layer free for other tracks to pass on
the Rx layer. After the bridge Tx passes the via the the previous Rx layer
and Rx continues on the Tx layer, The swapped layers. Both Rx and Tx have
passed a keeping a match via count for impedance matching.
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] EOMA68-A20 2.7.4 pre-production prototypes received and working

[mike.v...@gmail.com]

Op 16 jun. 2017 15:57 schreef "Luke Kenneth Casson Leighton" :

On Fri, Jun 16, 2017 at 11:06 AM, mike.v...@gmail.com
 wrote:

> Since the schematics already show two layers with HF signal tracks why not
> place the Tx and Rx track on top of each other. Result: Parallel tracks.

the impedance of different layers is different, so no this does not
work.  or forces you to do a stack analysis.  and simulations.  which
cost tens of thousands of dollars.


Bleh. It looked so pretty in my mind. ;-(

So different layers have different copper thickness.


l.

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

Re: [Arm-netbook] EOMA68-A20 2.7.4 pre-production prototypes received and working

[mike.v...@gmail.com]

Op 16 jun. 2017 16:03 schreef "Luke Kenneth Casson Leighton" :

On Fri, Jun 16, 2017 at 2:59 PM, Neil Jansen  wrote:
> I'm on mobile at work, I've confirmed with an EE here that does this sort
> of thing all the time.
>
> The good news is that your easiest bet is to just ask the board house to
> fill the vias with epoxy,

 awesome.  that's two great ideas.  via-over-pad (which involves
resin-filling as well).


So the PCB factory is not the party populating the board?


l.

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

Re: [Arm-netbook] EOMA68-A20 2.7.4 pre-production prototypes received and working

[mike.v...@gmail.com]

2017-06-17 11:17 GMT+02:00 Luke Kenneth Casson Leighton :
> On Fri, Jun 16, 2017 at 8:40 PM, mike.v...@gmail.com
>  wrote:
>
>> Bleh. It looked so pretty in my mind. ;-(
>
>  i knoow...   btw can you possibly investigate why, when you hit
> "reply", the ">"s are not added?

I was using gmail in HTML mode, apparently. I've found a switch.
Hopefully this works better.

N.B. Was this a problem before the auto HTML conversion on the list?

>
>> So different layers have different copper thickness.
>
>  in a stack you tell the factory what thicknesses you want, as well as
> what material in between, and what thickness of that, too.  so you get
> different capacitance on different layers.  thus, the problem is: you
> cannot guarantee the impedance will be identical on different layers.
> so having differential pairs on different layers is the worst possible
> thing you could do *unless* you have access to PCB simulators.
> which are ultra-expensive.

So it doesn't have to be a problem. As long as you control the layers
that have traces have the same thicknesses.

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

Re: [Arm-netbook] EOMA68-A20 2.7.4 pre-production prototypes received and working

[mike.v...@gmail.com]

2017-06-15 16:02 GMT+02:00 Luke Kenneth Casson Leighton :
> i received the latest pre-production cards yesterday and have tested
> one of them: it works.
>
> however (and this is the whole point of doing pre-production
> prototypes) in endeavouring to use automated assembly and solder paste
> it was discovered that the VIAs underneath the pads for the JAE DC3
> Micro-HDMI connector are sucking the solder paste in and down, leaving
> the pins not properly connected.
>
How about placing the connector on a small flex-PCB and then connect
the flex-PCB to the hard-PCB? Then you don't have to worry about the
correct mount height of the connector, leaving you with a bigger
variety of connectors. But then you'll need find another way to fixate
the connectors to the card housing. 3D print?

Also you can test connectors independently of the whole board.

I understand such a change might be to big to do in terms of time and costs.

Just trying to think outside the box here ;-)

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

Re: [Arm-netbook] Rv: Update: 2.7.4 EOMA68-A20 Cards Arrived

[mike.v...@gmail.com]

2017-06-21 12:56 GMT+02:00 Luke Kenneth Casson Leighton :
> On Wed, Jun 21, 2017 at 5:31 AM, el_gallo_azul via arm-netbook
>  wrote:
>> I'd be happy enough to supply my own MicroSD card (in place of the TSSOP-48 
>> NAND IC).
>
>  thanks greg.  very much appreciated.
>
>> Greg Flint
>>#yiv0042324540 body, #yiv0042324540 #yiv0042324540bodyTable,
>
> yarg, greg, eek!  please do read up on how to interact with other
> people on mailing lists!  you received a welcome message, with links
> on posting style and posting netiquette.  please read it!

You sure that this is not the result of the auto HTML converter?

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

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

Re: [Arm-netbook] EOMA68-A20 2.7.4 pre-production prototypes received and working

[mike.v...@gmail.com]

2017-06-21 13:00 GMT+02:00 Luke Kenneth Casson Leighton :
> .On Wed, Jun 21, 2017 at 9:35 AM, mike.v...@gmail.com
>  wrote:
>> 2017-06-17 11:17 GMT+02:00 Luke Kenneth Casson Leighton :
>>> On Fri, Jun 16, 2017 at 8:40 PM, mike.v...@gmail.com
>>>  wrote:

>>>  i knoow...   btw can you possibly investigate why, when you hit
>>> "reply", the ">"s are not added?
>>
>> I was using gmail in HTML mode, apparently. I've found a switch.
>> Hopefully this works better.
>
>  it does.  yay!

For those wonder how.
https://www.youtube.com/watch?v=kDP3VcmsYtg

>>>  in a stack you tell the factory what thicknesses you want, as well as
>>> what material in between, and what thickness of that, too.  so you get
>
>> So it doesn't have to be a problem. As long as you control the layers
>> that have traces have the same thicknesses.
>
>  technically correct but far too much risk and hassle.  you end up
> tying the PCB layout to a specific PCB manufacturing factory.

Hmm. If only we could include parameterised sections in the design to
accommodate that.

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

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

Re: [Arm-netbook] EOMA68-A20 2.7.4 pre-production prototypes received and working

[mike.v...@gmail.com]

2017-06-21 20:04 GMT+02:00 Luke Kenneth Casson Leighton :
> On Wed, Jun 21, 2017 at 6:26 PM, Wolfram Kahl  wrote:
>> On Wed, Jun 21, 2017 at 12:00:07PM +0100, Luke Kenneth Casson Leighton wrote:
>>> .On Wed, Jun 21, 2017 at 9:35 AM, mike.v...@gmail.com
>>> >>  in a stack you tell the factory what thicknesses you want, as well as
>>> >> what material in between, and what thickness of that, too.  so you get
>>>
>>> > So it doesn't have to be a problem. As long as you control the layers
>>> > that have traces have the same thicknesses.
>>>
>>>  technically correct but far too much risk and hassle.  you end up
>>> tying the PCB layout to a specific PCB manufacturing factory.
>>
>> Are there high-frequency risks/problems with switching back and forth
>> between the layer pair.
>
>  there are.

Every set of parallel wires act as both inductors and capacitors.
https://www.engineersgarage.com/sites/default/files/imagecache/Original/wysiwyg_imageupload/4214/CIRCULAR%20CONNECTORS%203.JPG.

With DC inductance is less of a problem. But with HF signals you don't
want return signals canceling out the main signal.

That's why the lines need to be parallel and of equal length.

And why I hate the length matching only on the end of the line.

> the more VIAs you have the more EMI there is.  R.F. (and
> HDMI is R.F.)

HDMI is HF, High frequency, which causes RF, Radio Frequency's, emissions.

EMI, Elektro Magnetic Interference, is the result of RF hitting your
signal line and creating noise and distortion.

Every electrical current causes an EM field. But with DC it is static.
With HF is dynamic making to harder to read the signal properly and
without errors.

>
>  the best track layouts use curves not 45 degree transitions.

That might not be true. Curves might actually be more problematic.
When the signal hits a wall it deflects. Like light on a mirror. With
curves the signal starts bouncing in zigzag pattern. Making the
distance traveled more unpredictable. And in worst case the signal
starts traveling backwards creating echo's.

HF Signals also tend to move on the outside of a conductor/track.

I guess that's why via's are so bad. The are round and change route at
90 degrees, downward or upward. So the signal starts bouncing and
echoing. Creating RF noise.

But with BGA IC's you have no other option than to use VIA's and
sometimes signals need to cross so you have to as well.

> the best layouts have no track changes at all, are as symmetrical as
> possible, are completely surrounded symmetrically by the exact same
> amount of space on either side, and the exact same number of vias on
> both sides of the track.  and also are impedance matched in terms of
> distance between the pairs, width of the tracks, *and* the distance
> between layers *and* the dielectric constant of the insulation between
> the layers.
>
> it's a pretty heavy-duty amount of requirements.
>
> l.
>
> ___
> arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netb...@files.phcomp.co.uk

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

Re: [Arm-netbook] HDMI High-Frequency Layout: Timing

[mike.v...@gmail.com]

2017-08-01 12:29 GMT+02:00 Luke Kenneth Casson Leighton :
> ok reading in full, cutting extraneous, answering only with confirmation.
>
> On Tue, Aug 1, 2017 at 10:57 AM, Richard Wilbur
>  wrote:
>
>> So, while we will try to match the impedance of our traces
>> (transmission lines) as carefully as possible to the characteristic
>> impedance specified for the cable, until we get to 4.3 inches from the
>> signal source the line driver should be able to squash most
>> reflections on the leading edges (first quarter wavelength).
>
>  actual distance is 55mm, under half the 4.3in.
>
>> Inter-pair skew:  (Requirements for HDMI v1.4)
>> clock-data skew:  Δt <150ps[3]
>>  => Δl < v * Δt = 22mm ~= 870mil
>> T(Pixel) = 1/(pixel clock) = 2.94ns
>> Skew(Inter-Pair) < 0.20 * T(Pixel)[4][5] = 588ps
>>  => Δl < v * Δt = 88.2mm ~= 3470mil
>> Chrontel suggests matching between any two pairs be within 100mil.[5]
>> => Δl < 100mil => Δt < Δl / v = 2540um / (150um/ps) = 17ps
>
>  actual difference between CK and Tx2 is 55 - 48mm, or 7mm. so... 275
> mil.  whoops.
>
>  between CK and Tx2 is 55 - 52 = 3mm, so... 118 mil.  again whoops.
>
>> Of these design parameters Chrontel's 100mil recommendation seems to
>> be the most restrictive, but still not out of the realm of possibility
>> and probably a good precautionary limit.  With only 17ps of inter-pair
>> skew we meet even much tighter skew timings.  Having non-vanishing
>> inter-pair skew seems to actually be beneficial for reducing
>> Electro-Magnetic Interference (EMI) by avoiding simultaneous
>> transitions on multiple lines.  Indeed the standard seems to be
>> designed to recover up to 5 bits of worst-case inter-pair skew.[6]
>> (Half of the 10-bit pixel time.)  A Texas Instruments (TI) employee
>> specifically suggested to keep the clock pair longer than the data
>> pairs.[7]
>
>  sounds like a good idea... and has to happen anyway: the clock lines
> have slightly further to go.
>
>> Intra-pair skew:  (Requirements for HDMI v1.4)
>> Toradex:  Δt < 5ps[3]
>>  => Δl < v * Δt = 0.75mm ~= 30 mil
>> Chrontel, Texas Instruments:  T(bit) = 0.1 * T(Pixel) = 294ps
>> Skew(Intra-Pair) = 0.15 * T(bit)[4][5] = 44.1ps
>>  => Δl = v * Δt =  6.62mm ~= 261 mil
>> (Chrontel suggests, without saying why, that matching between
>> signals should be within 5mil.[5]  Given the context and calculations
>> above suggesting 261 mil for total, this should probably be 5mil skew
>> per segment.)
>
>  i try to meet that - 5 didn't know it was as little as 5mil though.
> that's absolutely tiny!
>
>> Chamferred Corners (or Trace Bend Geometry)
>>
>> I'm glad to see you are already using 45 degree bends instead of 90
>> degree corners.  This helps the corners maintain the proper impedance.
>> When serpentine traces (meanders) are needed to attain certain lengths
>> of a single-ended trace, make sure individual segment lengths are at
>> least 1.5x the width of the trace.  Also, the spacing between parallel
>> segments of the same trace should be at least 4x the width of the
>> trace.[9]
>
>  that's going to be very very hard to achieve: there is an extremely
> limited amount of space.
>
>> Length Matching
>>
>> Differential pair signals should not propagate asynchronously over a
>> distance greater than 15mm[10] = 590mil.  Thus the compensation for
>> length mis-matches should be placed as close to the mismatch as
>> possible.  Differential traces can be segmented by a connector, pad
>> (component or IC), or via.[10][5]  "Each segment of a differential
>> pair connection needs to be matched individually."[10]
>
>  yeah i saw that in the toradex recommendations, otherwise there's
> skew between traces.
>
>> Ideal serpentine trace geometry for equalizing differential traces
>> consists of the following proportions:  the spacing between traces in
>> the meanders should not exceed twice the normal spacing, and the
>> length of more widely spaced traces should not exceed three times the
>> normal trace width.[10, see Figure 23]
>
>  there's a lot of other stuff in here which is really good, such as
> making sure that lengths on each *layer* are matched, and that even
> when turning corners the lengths are matched.  and matching just after
> VIAs *not* before... damn

Between via's the length should be matched right? Length mismatch
should be solved as soon as possible to accommodate eddy-currents
right?

Found a nice post from TI
https://e2e.ti.com/blogs_/b/analogwire/archive/2015/06/10/differential-pairs-four-things-you-need-to-know-about-vias


>
>  so thank you - much to correct and think about.  really appreciated
> you finding all this stuff richard.
>
> l.
>
> ___
> arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netb...@files.phcomp.co.uk

___
arm-netbook mailing list

Re: [Arm-netbook] HDMI High-Frequency Layout: Timing

[mike.v...@gmail.com]

2017-08-01 16:11 GMT+02:00 Luke Kenneth Casson Leighton :
> On Tue, Aug 1, 2017 at 2:51 PM, mike.v...@gmail.com  
> wrote:
>
> [trimming a huge amount of unnecessary context on your behalf, mike...
> hint, hint]

My apologies to all.

>
>>>  there's a lot of other stuff in here which is really good, such as
>>> making sure that lengths on each *layer* are matched, and that even
>>> when turning corners the lengths are matched.  and matching just after
>>> VIAs *not* before... damn
>>
>> Between via's the length should be matched right? Length mismatch
>> should be solved as soon as possible to accommodate eddy-currents
>> right?
>
>  yes.  the toradex article explains it very well, also mentions the
> importance of symmetry (as does the TI post).
>
>> Found a nice post from TI
>> https://e2e.ti.com/blogs_/b/analogwire/archive/2015/06/10/differential-pairs-four-things-you-need-to-know-about-vias
>
>  nice!  dang, above 10ghz the thickness of the via starts to matter
> and needs to be drilled out, post-production.  dang.
>
>  *sigh* unfortunately symmetry is not completely achievable with the
> drastically-reduced amount of space available.  the HDMI signals come
> out right at the bottom of the board.

That might not be to problematic. I've search to the net for talk
about running tracks on top of each other. It keeps hunting me. And
found a knowledable awnser.

http://www.sigcon.com/Pubs/news/2_30.htm

On of the things mentioned is that the differential signals might not
be quite aligned to begin with. So achieving symmetry might look nice
on but can only give limited help in minimizing emission and pickup.

>
> l.

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

Re: [Arm-netbook] HDMI High-Frequency Layout: Impedance

[mike.v...@gmail.com]

2017-08-03 17:28 GMT+02:00 Luke Kenneth Casson Leighton :
>  ok i did a video explaining: https://youtu.be/vFbzAmLSHPY

Informative. Might I suggest a screen recorder? Although that might be
a bit more work in post editing, it might be more clear and .

The middle GND traces could use a bit more riveting(via's). There's
space in the corners. The outer HDMI GND trace, on the inner side of
the board, might benefit from some riveting like to one on the outer
side.

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

Re: [Arm-netbook] HDMI High-Frequency Layout: Impedance

[mike.v...@gmail.com]

2017-08-04 9:19 GMT+02:00 Luke Kenneth Casson Leighton :
> On Thu, Aug 3, 2017 at 11:53 PM, Richard Wilbur
>  wrote:
>
>> 3.  Instead of using two separate anti-pads on signal vias, combine
>> them into an oval shared antipad (on every layer) to reduce parasitic
>> capacitance.
>
>  oo.  never heard of this practice.   never heard of "anti-pads"
> either!  so sorry, if you put some references i missed them.
>
https://e2e.ti.com/cfs-file/__key/communityserver-blogs-components-weblogfiles/00-00-00-03-25/3124.Fig1.jpg

From
https://e2e.ti.com/blogs_/b/analogwire/archive/2015/06/10/differential-pairs-four-things-you-need-to-know-about-vias

Basically a barrier between a via and a passing layer. Something
default to prevent shorting.

With differentals have them combined so there is nothing in between
them in a horizontal line/z axis as well.

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

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[mike.v...@gmail.com]

2017-08-04 8:17 GMT+02:00 Luke Kenneth Casson Leighton :
> ---
>
>  you cannot expect companies to drop everything and help just you.
> you're just one person: you're expected to work these things out for
> yourself.
>
>  now, if you were placing an order for ten THOUSAND *then* they might
> be interested.

Well they've announced the CHIP to be more open and supported than
actually delivered.

Now that is unfortunately common practice. And due to experiences in
the past, Poulsbo, Andriod, I already knew that they would not be able
to deliver that, especially at that price point. Hey they even
promised opensource 3d graphics if the crowdfunding was successful
enough, if I recall correctly.

But that is just us. That might not, and probably is, be true for a
lot of their customers, like David. That's we're the evil lies I
think. Announcing a "libre" computer but fail to follow it through.
Yes there is open source software for you to use, yes there
schematics.

But from what I've learned, a lot of it here on the list and from you
Luke. That's not enough.

There needs to be a reproducible process and clearly state what is
open and what is not.

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

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

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[mike.v...@gmail.com]

2017-08-08 12:11 GMT+02:00 Pablo Rath :
> On Fri, Aug 04, 2017 at 10:17:22AM +0200, mike.v...@gmail.com wrote:
>> Well they've announced the CHIP to be more open and supported than
>> actually delivered.
>>
>> Now that is unfortunately common practice. And due to experiences in
>> the past, Poulsbo, Andriod, I already knew that they would not be able
>> to deliver that, especially at that price point. Hey they even
>> promised opensource 3d graphics if the crowdfunding was successful
>> enough, if I recall correctly.
>>
>> But that is just us. That might not, and probably is, be true for a
>> lot of their customers, like David. That's we're the evil lies I
>> think. Announcing a "libre" computer but fail to follow it through.
>> Yes there is open source software for you to use, yes there
>> schematics.
>
> Please correct me if I am wrong but I am pretty sure they did not
> announce a "libre" computer. They use the term "open source" and "very
> open source" on their kickstarter page. People in the "Open Source Camp"
> seem to be more inclined to accept a very open source system with
> proprietary wifi.

The term libre is somewhat new. The average joe knows about open
source these days. But if I drop the libre keyword they don't
understand.

And they did not get to "very open" in my opinion. But the level op
openness should be stated more clearly.

As it is the system for all functionality is tied to a 3.4 kernel and
fixed X11 version display stack. Or Android.

So for all the openness upgrading is neigh impossible. As is running a
generic Linux distribution.

So in my opinion opensource means that you can upgrade and the every
bit can be mainlined.

Firmware, however evil in it's own right, is independent on the OS
software stack and thus does not impair upgrading or switching OS
and/or OS versions. So hence the general acceptance I guess.

The MALI GPU requires a closed source driver dependent on the OS
stack. Thus locking you in place.

The Cedar VPU requires a closed source driver dependent on the OS
stack. Thus locking you in place. That situation, again no thanks to
NTC, is improving, albeit slowly.

Thankfully display drivers (That's not the GPU. So no 2d or 3d
acceleration!) are available or worked on. But no help from NTC.

So on paper nothing better than a Intel GMA500 (Poulsbo/PowerVR). E.g.
a Dell mini 1010 sold with Ubuntu, the trap I fell into, Three Ubuntu
iterations further and that was it for that Laptop.

When announcing an open source system. Companies should be very clear
on what they are selling.
Does it include firmware? (Acceptable ?)
Does it include closed source drivers? (That limits upgradablity and
usefull lifetime)
Do you provide a complete stack, Source, Compile chain, Documentation?
Do you provide schematics?
Do you provide a BoM?
Do you provide comprehensive component documentation free of NDA's?
etc.

Simply saying "we're selling an opensource system" is a farce. That's too broad.

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

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

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[mike.v...@gmail.com]

2017-08-08 16:28 GMT+02:00 Luke Kenneth Casson Leighton :
> On Tue, Aug 8, 2017 at 2:57 PM, mike.v...@gmail.com  
> wrote:
>
>> The Cedar VPU requires a closed source driver dependent
>
>  you mean a criminally-infringing library which has at the very least
> stolen copyright code from ffmpeg confirmed (not a "closed source"
> driver).

:-) yep that one! And the driver source, while constructed out of gpl
software, was never released. And thus still closed software. Illegal,
gpl violating, but closed. Their attempt to rectify was to create a
open source stub driver and a closed source userspace part, consisting
of obfuscated FFMPEG code. [1]


Luc Verhagen, et al. explained and barked loudly at Allwinner on what
they had to do to rectify. But I guess the IP owner of cedarx is not
AllWinner. And their vendor, the IP owner, the original infringer, did
not give them permission to rectify properly. Or something else. [1]

>
>> on the OS
>> stack. Thus locking you in place. That situation, again no thanks to
>> NTC, is improving, albeit slowly.
>
>   libcedrus has been around and working for a long, long time on the
> A13 / R8 / GR8 (all the same SoC).  it also works on the A20 and i had
> full 1080p video playback fully operational back in august 2016.  so i
> know it's a fully libre video stack.

sunxi-vdpau is open source but it is a hack. An unsafe one! [3]
sunxi-cedrus is not ready for primetime last time I checked. V4L is
slow to accept the needed changes.[2]

[1] http://linux-sunxi.org/CedarX
[2] http://linux-sunxi.org/Cedrus
[3] http://linux-sunxi.org/Cedrus/libvdpau-sunxi

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

Re: [Arm-netbook] HDMI High-Frequency Layout: Recommendations

[mike.v...@gmail.com]

2017-08-09 12:39 GMT+02:00 Luke Kenneth Casson Leighton :
> ... forgot the images...
No image's here on the list

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

Re: [Arm-netbook] HDMI High-Frequency Layout: Recommendations

[mike.v...@gmail.com]

2017-08-09 15:23 GMT+02:00 Luke Kenneth Casson Leighton :
> next set...
>
GND shielding parallel to the differentials is interrupted quite
often. Those GND tracks act as shields, for emission and reception.
I'd try to put as much parallel GND as possible.

And trace the parallel GND around the via's, see attachment.

Make sure the'res as much solid GND on the layer above and below the
traces, again shielding.

Also I'd personally not use curved wriggles. HF signals travel in a
straight direction. With curves they start diffracting and start
bouncing cross each other and might start to radiate or echo back. But
I see that the community is divided on that stance.

If tight for space you can use 90% corners with a chamfered outer
edge. I suppose the chamfer acts like a mirror.

https://www.maximintegrated.com/en/app-notes/index.mvp/id/5100
Figure 6
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] HDMI High-Frequency Layout: Recommendations

[mike.v...@gmail.com]

2017-08-10 10:18 GMT+02:00 Luke Kenneth Casson Leighton :
> On Thu, Aug 10, 2017 at 9:01 AM, mike.v...@gmail.com
>  wrote:
>> 2017-08-09 15:23 GMT+02:00 Luke Kenneth Casson Leighton :
>> Make sure the'res as much solid GND on the layer above and below the
>> traces, again shielding.
>
>  these are layer 1 and layer 6, and layer 2 and 5 are solid GND.

I was referring mostly to layer 3 and 4. The diff pair is either on 3
or 4. If it is on 3 a slab of GND should be on 4 and vice versa.

It's
1. Vsuply + components
2. Ground
3. HF
4. HF
5. Ground
6. Vsuply + componnents

Right?

>> If tight for space you can use 90% corners with a chamfered outer
>> edge. I suppose the chamfer acts like a mirror.
>
>  i'd *really* prefer not to do that :)
>
>> https://www.maximintegrated.com/en/app-notes/index.mvp/id/5100
>> Figure 6
>
> wow that's pretty bad-ass.

Yeah I had read a more extensive guide in a TI pdf somewhere, can find
it at the moment. But TI documentation also schizo's on curves vs.
corners of 35 degrees and chamfered 90 degrees.

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

Re: [Arm-netbook] HDMI High-Frequency Layout: Recommendations

[mike.v...@gmail.com]

2017-08-10 10:45 GMT+02:00 Luke Kenneth Casson Leighton :
> On Thu, Aug 10, 2017 at 9:38 AM, mike.v...@gmail.com
>  wrote:
>> 2017-08-10 10:18 GMT+02:00 Luke Kenneth Casson Leighton :
>>> On Thu, Aug 10, 2017 at 9:01 AM, mike.v...@gmail.com
>>>  wrote:
>>>> 2017-08-09 15:23 GMT+02:00 Luke Kenneth Casson Leighton :
>>>> Make sure the'res as much solid GND on the layer above and below the
>>>> traces, again shielding.
>
> 1. SIG1 + components
> 2. Ground
> 3. SIG3
> 4. POWR
> 5. Ground
> 6. SIG6 + componnents
>
That work's as well. But the enclosure should shield very well. And
there should not be a HF signals on layer 3.

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

Re: [Arm-netbook] HDMI High-Frequency Layout: Recommendations

[mike.v...@gmail.com]

2017-08-10 10:18 GMT+02:00 Luke Kenneth Casson Leighton :
> On Thu, Aug 10, 2017 at 9:01 AM, mike.v...@gmail.com
>  wrote:
>> 2017-08-09 15:23 GMT+02:00 Luke Kenneth Casson Leighton :
>>> next set...
>>>
>> GND shielding parallel to the differentials is interrupted quite
>> often.
>
>  because there's simply not enough space to do otherwise.  if i could
> move the entire CPU and RAM up another 0.5mm it would be doable.  but
> then i would have to re-route 12 signals which go around the top area
> of the board and that's (a) risky and (b) not enough space to do it.
>

I found quite some room. See attachments. Red: Easy improvement.
Yellow questionable but could use some improvement. Excuse the crappy
image editor it's all I have at the moment.

Also wouldn't a GND infill on the signal layers be preferable? As log
not unconnected islands emerge.
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] HDMI High-Frequency Layout: Recommendations

[mike.v...@gmail.com]

2017-08-10 13:09 GMT+02:00 Luke Kenneth Casson Leighton :
> On Thu, Aug 10, 2017 at 11:14 AM, mike.v...@gmail.com
>  wrote:
>
>> Also wouldn't a GND infill on the signal layers be preferable? As log
>> not unconnected islands emerge.
>
>  GND infill *is* going to be done on the signal layers.  but the
> copper-to-track clearance is 10mil (where tracks are 5mil). so what
> happens is: any space smaller than 10mil does *not* get flood-filled.
> so i put little "leaders" - like you can see - into the areas where
> the beer cannot reach.

Ah that explains a lot indeed. Too bad the infill isn't visualized.

Sadly the space between the HDMI connectors is to small to fill. That
would encapsulate the HDMI signal pairs.

>  https://www.youtube.com/watch?v=ab6dJYDgj48

LOL

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

Re: [Arm-netbook] Conflict-free minerals

[mike.v...@gmail.com]

2017-08-11 8:03 GMT+02:00 Luke Kenneth Casson Leighton :
> On Fri, Aug 11, 2017 at 1:08 AM, Jean Flamelle  wrote:
>
>> I can imagine many OEM's don't publish or even pay attention to where
>> they get minerals from, so I imagine the potential parts list dwindles
>> beyond reason at simply limiting one's self to OEM's that at least
>> list their mineral sources, much less then actually trying to them
>> limit it based on the fairly subjective "conflict-free" qualification.
>
>  fairphones does but they then screwed up by not bothering with
> the ethical issues of ensuring that the operating system was
> actually... legal to distribute.   so all the Fairphone 1 products
> they designed are basically a ticking landfill timebomb ENTIRELY
> DEFEATING the whole fucking point of the exercise.
>
>  they still have not resolved the use of the GPL-violating Mediatek OS
> distributed with that phone, meaning that they have LOST ALL RIGHTS TO
> DISTRIBUTE PRODUCT - including the Fairphone 2 and all future
> products.

True and the FP1 has been officially been discontinued from support.
FP2 is a Qualcomm device.

>
>  the way that they can fix that is to ask every single contributor to
> u-boot and the linux kernel for their distribution rights back, but
> first obtain the full GPLv2 source to that Mediatek OS.
>
>  alcatel did this (alcatel is one of the main sources of mediatek
> GPLv2 compliant source code).
>
>  Fairphones did not.

They've tried to do better with FP2. But still they did not fully
grasp the implications.

>
>
>  so.
>
>  what do you think of that, jean? should we go out and buy Fairphone products?

Well, They've focused on one side of the equation, upstream. We've
focused on the to other, downstream.

So in the end we need both approaches.

At least they've raised some awareness and show the world that a
viable business can be founded with focus on ethical hardware
resources.

The software part remained as shitty as the rest. Let us show the
world that can be done as well!

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

Re: [Arm-netbook] HDMI High-Frequency Layout: Recommendations

[mike.v...@gmail.com]

2017-08-13 14:20 GMT+02:00 Luke Kenneth Casson Leighton :
> btw yes i managed to move IPSOUT slightly to the right and got a GND
> line in between them, without too much disruption.  thank you for
> prompting me to do that.

Amazing! Just a nitpick left. You mentioned the GND flood-fill
distance is 10mil. That means that GND will 10 mil removed from
tracks. Personally I'd trace the GND as close as possible to the diff
signals. But that may be just overcautious.

I don't have any fancy math like Richard so it might be FUD. Or just
my mild form of OCD. :-)

Or is that 10mil the minimum gap size? That would make sense.

Anyway a picture of the flood-fill will reveal everything.

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

Re: [Arm-netbook] frickin funny

[mike.v...@gmail.com]

2017-08-13 15:49 GMT+02:00 Luke Kenneth Casson Leighton :
> https://motherboard.vice.com/en_us/article/78w8jy/pcmcia-once-defined-portable-computing-now-its-a-cable-industry-oddity

LOL. Even EOMA gets mentioned.

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

[Arm-netbook] PCB Collaboration and Revision

[mike.v...@gmail.com]

https://hackaday.com/2011/10/14/hardware-version-control-using-visual-diff/

http://www.evilmadscientist.com/2011/improving-open-source-hardware-visual-diffs/

For the next project

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

Re: [Arm-netbook] HDMI High-Frequency Layout: Recommendations

[mike.v...@gmail.com]

2017-08-14 9:14 GMT+02:00 Luke Kenneth Casson Leighton :
> On Mon, Aug 14, 2017 at 7:43 AM, mike.v...@gmail.com
>  wrote:
>> Anyway a picture of the flood-fill will reveal everything.
>
>  attached.  greyscaled (smaller).  original GND tracks are still
> visible but they're *combined* with the floodfill.
>
Looks pretty. Seeing that does raise a question too me. Is it
necessary to match length between the different pairs? I didn't think
that was a requirement. Because I see pairs wriggling and wasting a
lot of space.

I thought that only matching was required on a single pair. Impedance matching.

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

Re: [Arm-netbook] HDMI High-Frequency Layout: Recommendations

[mike.v...@gmail.com]

2017-08-16 11:33 GMT+02:00 Luke Kenneth Casson Leighton :
> On Wed, Aug 16, 2017 at 10:31 AM, mike.v...@gmail.com
>  wrote:
>
>> Looks pretty. Seeing that does raise a question too me. Is it
>> necessary to match length between the different pairs? I didn't think
>> that was a requirement. Because I see pairs wriggling and wasting a
>> lot of space.
>>
>> I thought that only matching was required on a single pair. Impedance 
>> matching.
>
>  that's what we've been discussing.  read richard's message and my response.

I've read it again. But did not digest that from Richard's responses.

Inter-pair skew: Length (un)matching between two traces making op one
differential pair?

Intra-pair skew: Length (un)matching between differential pairs? Not mentioned.

What else I read so far:

Possibly remove the GND traces between pairs. Differential pairs are
designed to cancel each other out thus limit radiation. The pair
coupling creates force to repel incoming radiation noise. Correct me
if I'm wrong

The same construction as in twisted pair cables. But there you have
differential pair twisting creates an even bigger effect. But there we
also have types with shielding. Shielding around the whole set and
even with shielding per pair. The HMDI cables I've  butchered had per
pair shielding and the other lines, clock, cec, etc, unshielded
bundled in one extra shield.

Removing the, intra pair, GND traces improves impedance, but decreases
shielding from external incoming radiation. But I suspect that effect
is limited due to the GND layer below, far bigger and nearer than
those traces.

Differential pairs should have a bigger, dielectric, space surrounding
them than they have to each other. Because the nearer you get to a
pair the less the differential cancelling effect. With the exception
for GND, which should act as a sink for EM emissions.

Removing the, intra pair, GND traces won't give you more space because
the pairs should keep the extra distance from each other.

Via's should occur only when, inter pair, length is matched.
Differential via's should have a rounded, oval,  common, dielectric,
space surrounding them so the Z-axis radiation can cancel out
uninterrupted.

Digital differential signals might be skewed to begin with. Limiting
the differential EM canceling effect to begin with.

I'd say keep the intra pair GND traces. Maybe loose the intra pair
length mathing.

There should be no electric/magnetic coupling between intra pairs. But
if their length differs the parallel digital signals might become time
skewed. But I doubt that on this length that would be a problem.

Richards math should help with that along with max allowed digital
signal skew. Don't have the time to convert the math in a spreadsheet
calculator to confirm.

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

Re: [Arm-netbook] HDMI High-Frequency Layout: Recommendations

[mike.v...@gmail.com]

2017-08-16 15:17 GMT+02:00 mike.v...@gmail.com :
> 2017-08-16 11:33 GMT+02:00 Luke Kenneth Casson Leighton :
>> On Wed, Aug 16, 2017 at 10:31 AM, mike.v...@gmail.com
>>  wrote:
>>
>>> Looks pretty. Seeing that does raise a question too me. Is it
>>> necessary to match length between the different pairs? I didn't think
>>> that was a requirement. Because I see pairs wriggling and wasting a
>>> lot of space.
>>>
>>> I thought that only matching was required on a single pair. Impedance 
>>> matching.
>>
>>  that's what we've been discussing.  read richard's message and my response.
>
> I've read it again. But did not digest that from Richard's responses.
>
> Inter-pair skew: Length (un)matching between two traces making op one
> differential pair?
>
> Intra-pair skew: Length (un)matching between differential pairs? Not 
> mentioned.

Ah it seems it's the other way around. Silly me. I knew why I kept
away from the intra and inter prefixes. I always switch them.

> The HMDI cables I've  butchered had per
> pair shielding and the other lines, clock, cec, etc, unshielded
> bundled in one extra shield.

Sorry. Clock is also one of the diff-pairs. As well as pin 17 and 19,
HEAC, Utilized for ARC (S/PDIF) and Ethernet. But not in the A20 so
less of a problem.

> Richards math should help with that along with max allowed digital
> signal skew. Don't have the time to convert the math in a spreadsheet
> calculator to confirm.

Hmm not the only ones out there with these questions.

https://e2e.ti.com/support/interface/high_speed_interface/f/138/t/267205
"intra-pair length mismatch is recommended to be less than 5mils,
inter-pair length mismatch is less of a concern but the recommendation
is to keep the traces <2" and keep the clock slightly longer than the
data traces."

Keeping the clock longer makes sense. All the data is buffered before
the clock signal arrives.

https://forum.allaboutcircuits.com/threads/hdmi-inter-intra-pair-skew-inter-pair-synchronization.75801/
5bits of buffer.

http://ieeexplore.ieee.org/document/1706346/
https://www.researchgate.net/publication/224650488_Effects_of_skew_on_EMI_for_HDMI_connectors_and_cables
paywall, blegh. Put in a request on the second one. Let's see

https://www.infocomm.org/cps/rde/xbcr/infocomm/Dietro_HDMI.pdf
That explained the "eye diagrams". Overlapping differential signals.
Hmm 1bit buffer? 1920x1080p60 = 148.5 Mhz

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