Discussion:
[Arm-netbook] Top Priority Software Tasks
Adam Van Ymeren
2017-11-28 01:11:15 UTC
Permalink
Hey Luke,

As I eagerly await the preproduction board, I figure it would be a good idea to touch base on what needs doing on the software side.

I've started looking at http://rhombus-tech.net/allwinner_a10/source_code/ for inspiration.

But I'd like to know which tasks are a priority for you to deliver the current crowd supply pledges.

Cheers! Hope the Shenzen was fun.
-Adam

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm
Luke Kenneth Casson Leighton
2017-11-28 11:53:01 UTC
Permalink
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
Post by Adam Van Ymeren
Hey Luke,
As I eagerly await the preproduction board, I figure it would be a good idea to touch base on what needs doing on the software side.
hmmm well having someone confirm that the OSes run would be good (wih
systemd removed as an absolute top priority, sole exception being
fedora).

next up would be working on a distribution mechanism for the images.
my feeling is, setting up a bittorent network, a simple (SMALL)
script/image that self-boots then grabs the image and drops it onto
the target sd card.

or... some instructions on how people can directly download then get
the image onto a microsd card

reason: the budget's simplly not large enough now ship out a thousand
4GB / 8GB microsd cards with the OS pre-installed on it. people are
going to have to get their own (or use one they already have).
Post by Adam Van Ymeren
I've started looking at http://rhombus-tech.net/allwinner_a10/source_code/ for inspiration.
But I'd like to know which tasks are a priority for you to deliver the current crowd supply pledges.
all hardware-related.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send la
Bill Kontos
2017-11-28 17:13:45 UTC
Permalink
Post by Adam Van Ymeren
Hey Luke,
I've started looking at http://rhombus-tech.net/allwinner_a10/source_code/ for inspiration.
But I'd like to know which tasks are a priority for you to deliver the current crowd supply pledges.
I think finding out what that bug that prevents us from using a modern
version of linux is a high priority too.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large at
Luke Kenneth Casson Leighton
2017-11-28 19:03:50 UTC
Permalink
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
Post by Bill Kontos
Post by Adam Van Ymeren
Hey Luke,
I've started looking at http://rhombus-tech.net/allwinner_a10/source_code/ for inspiration.
But I'd like to know which tasks are a priority for you to deliver the current crowd supply pledges.
I think finding out what that bug that prevents us from using a modern
version of linux is a high priority too.
the list of peripherals and features supported is right there on the
linux mainline sunxi page. when it's at 100% full and complete
support for *all* hardware features (VPU, 2D engine etc. included),
and the available libraries (libcedrus through libvdpau,
xserver-xorg-fb-turbo and more) have *all* been updated to support
that linux mainline kernel version, then and *only* then is it okay to
*consider* abandoning the many months of (tested, proven) work done
over the past few years and to *consider* releasing updated OSes to go
on top of them.

remember: with the sunxi 3.4.104 kernel *xserver fb turbo works*.
libcedrus *works*. acceleration of video decoding and display *works*
in firefox and chrome (although i didn't test the accelerated display
bit because it requires OpenGL and i refuse to install the proprietary
OpenGL MALI library).

by converting over right now to the linux mainline kernel *all those
accelerated functions are cut off*, plus even some critical
peripherals are cut off, as well.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachme
Bill Kontos
2017-11-28 20:24:05 UTC
Permalink
On Tue, Nov 28, 2017 at 9:03 PM, Luke Kenneth Casson Leighton
Post by Luke Kenneth Casson Leighton
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
remember: with the sunxi 3.4.104 kernel *xserver fb turbo works*.
libcedrus *works*. acceleration of video decoding and display *works*
in firefox and chrome (although i didn't test the accelerated display
bit because it requires OpenGL and i refuse to install the proprietary
OpenGL MALI library).
Maybe when you start a future crowdfunding campaign for another card
it would be a good idea to look at what functionality is missing from
mainline and factor in some extra costs around paying people to
mainline these patches.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phc
Luke Kenneth Casson Leighton
2017-11-29 08:07:09 UTC
Permalink
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
Post by Bill Kontos
Maybe when you start a future crowdfunding campaign for another card
it would be a good idea to look at what functionality is missing from
mainline and factor in some extra costs around paying people to
mainline these patches.
i specifically picked the RK3288 because of exactly this. reading
between the lines, google's financial muscle clearly had an impact on
rockchip and got them to comply fully with the GPL *and* get
everything up and running, all aspects of all hardware, as full libre
sourced stacks.

the only difficulty with the RK3288 is that there are *so many*
muppets out there @begin whine i gotta gweat idea on how ter put
erbuuntewww onna cwohmmebook here's my wuurpwess bhurlooorg gimme five
an'a' facebhuuk liiiiiike @end whine that they're *completely*
deluging *actual* expertise which allows you to get right down to the
bedrock of the SoC.

many of the wordpress-whiners for example *keep* the UEFI-based
adaptation of u-boot that goes with chromebooks, so all their
instructions are on (a) bypassing the restrictions built-in to that
version of u-boot (b) discussing the UEFI partition format. those
that aren't chroot environments only, at least.

actually finding the linux kernel and u-boot source was a bitch: most
of the searches direct you to *google's* releases / trees.

*EVENTUALLY* i found the right experts on the #linux-rockchip forum
who were able to direct me correctly to the appropriate (libre) tools
and resources (a good percentage of them being on the t-firefly
website), and was able to confirm that yes, you CAN get everything -
including GPU (proprietary / MALI) and VPU (libre) libraries, and yes,
it's completely mainlined, yes it's entiirely device-tree'd, yes it's
full and complete support across the board 100% libre for the full and
complete hardware.

in short, bill, the A20 was selected as a low-cost option with a lot
of community enthusiasm and willingness to reverse-engineer it, which
has since died out because of allwinner repeatedly fucking about.

i won't make that mistake again and yes have added much stricter
criteria to processor selection (as you can see from the "Selecting a
Processor" update on the crowdsupply page): ensuring that people
*don't have to be be paid because everything's already available* is
one of the criteria to consider.

of course if it's risc-v, that's exciting and innovating and gets
people interested and engaged, which completely over-rules the
"everything has to be available already" criteria, because instead
it's pioneering work and we are *empowered* to make everything
available.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@file
Tzafrir Cohen
2017-11-28 20:51:38 UTC
Permalink
Post by Luke Kenneth Casson Leighton
Post by Bill Kontos
I think finding out what that bug that prevents us from using a modern
version of linux is a high priority too.
the list of peripherals and features supported is right there on the
linux mainline sunxi page. when it's at 100% full and complete
support for *all* hardware features (VPU, 2D engine etc. included),
and the available libraries (libcedrus through libvdpau,
xserver-xorg-fb-turbo and more) have *all* been updated to support
that linux mainline kernel version, then and *only* then is it okay to
*consider* abandoning the many months of (tested, proven) work done
over the past few years and to *consider* releasing updated OSes to go
on top of them.
Originally the issue was that it has failed to boot. Issues with the
boot loader. What about those? An issue with kernel >= 4.9 or so.
--
Tzafrir Cohen | ***@jabber.org | VIM is
http://tzafrir.org.il | | a Mutt's
***@cohens.org.il | | best
***@debian.org | | friend

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm
Luke Kenneth Casson Leighton
2017-11-29 08:16:05 UTC
Permalink
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
Post by Tzafrir Cohen
Originally the issue was that it has failed to boot. Issues with the
boot loader. What about those? An issue with kernel >= 4.9 or so.
my understanding was, when i looked at this, was it's something to do
with how old-uboot initialises the processor.... can't remember the
details. a "fix" was added as a parameter that allowed old-u-boot to
boot newer kernels, and new-u-boot to boot older kernels.

however.... last year, when investigating, there was *another* issue,
which is that somewhere around... i think it was 4.7rc1 ... it would
systematically and totally unreliably come to a grinding halt at
anywhere between 30 and 180 seconds into the boot.

i think i maybe did a HUNDRED AND FIFTY separate kernel compiles (git
bisect and other techniques), trying for several DAYS to narrow down
which commit was responsible, but because of the unreliability of the
crashing it was near-impossible to narrow down. the best / closest i
could get was something like, "4.7rc1 is fine, 4.7rc5 isn't".

since then whatever underlying bug is there MIGHT have been tracked
down and fixed, as there were people who were vaaaguely aware of the
problem, on other hardware.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.
Pablo Rath
2017-11-29 08:46:41 UTC
Permalink
Post by Luke Kenneth Casson Leighton
Post by Tzafrir Cohen
Originally the issue was that it has failed to boot. Issues with the
boot loader. What about those? An issue with kernel >= 4.9 or so.
my understanding was, when i looked at this, was it's something to do
with how old-uboot initialises the processor.... can't remember the
details. a "fix" was added as a parameter that allowed old-u-boot to
boot newer kernels, and new-u-boot to boot older kernels.
however.... last year, when investigating, there was *another* issue,
which is that somewhere around... i think it was 4.7rc1 ... it would
systematically and totally unreliably come to a grinding halt at
anywhere between 30 and 180 seconds into the boot.
i think i maybe did a HUNDRED AND FIFTY separate kernel compiles (git
bisect and other techniques), trying for several DAYS to narrow down
which commit was responsible, but because of the unreliability of the
crashing it was near-impossible to narrow down. the best / closest i
could get was something like, "4.7rc1 is fine, 4.7rc5 isn't".
since then whatever underlying bug is there MIGHT have been tracked
down and fixed, as there were people who were vaaaguely aware of the
problem, on other hardware.
Now I am confused. In this reply
(http://lists.phcomp.co.uk/pipermail/arm-netbook/2017-May/013653.html)
you have told me the reason for the kernel bug is/was a power
instability. So I thought this is going to be fixed and said kernel bug
is no more.
Are there multiple kernel bugs?

kind regards
Pablo

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb
Luke Kenneth Casson Leighton
2017-11-29 09:21:39 UTC
Permalink
Post by Pablo Rath
Now I am confused. In this reply
(http://lists.phcomp.co.uk/pipermail/arm-netbook/2017-May/013653.html)
you have told me the reason for the kernel bug is/was a power
instability. So I thought this is going to be fixed and said kernel bug
is no more.
i solved that by simply cutting off NAND entirely and re-routing the
pins on SD/MMC so that MMC0 is now the user-facing SD slot and MMC2 is
the EOMA68 SD/MMC interface.

both are eGON BOOTROM interfaces.

previously i was forced to route MMC3 to the user-facing SD slot and
MMC0 to the EOMA68 interface.

MMC3 is *not* bootable from the A20 eGON BOOTROM.

i think that's what it was. it's been too long to recall exact details.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netboo
Stefan Monnier
2017-11-30 02:00:37 UTC
Permalink
Post by Adam Van Ymeren
As I eagerly await the preproduction board, I figure it would be a good idea
to touch base on what needs doing on the software side.
IIUC now that DRM support for the A20 is in mainline (well, not quite
there yet, but it's in linux-next), the next thing is video decoding,
I think. There's currently work going on for that up at
https://github.com/free-electrons/linux-cedrus, so help would be welcome
there.


Stefan "who doesn't know if the proprietary binary-blob MALI
driver currently works with mainline Linux"


_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb
Elena ``of Valhalla''
2017-11-30 09:31:57 UTC
Permalink
Post by Stefan Monnier
Stefan "who doesn't know if the proprietary binary-blob MALI
driver currently works with mainline Linux"
There was a talk on that blob at the debian minidebconf cambridge last
weekend (video available)

https://wiki.debian.org/DebianEvents/gb/2017/MiniDebConfCambridge/Sliepen

and informations are being kept updated on the debian wiki:

https://wiki.debian.org/MaliGraphics (and related pages)

but there doesn't seem to be much work done for allwinner SoCs, at the
moment.
--
Elena ``of Valhalla''

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp.
Stefan Monnier
2017-11-30 13:14:09 UTC
Permalink
Post by Elena ``of Valhalla''
https://wiki.debian.org/MaliGraphics (and related pages)
but there doesn't seem to be much work done for allwinner SoCs, at the
moment.
According to that web-page, there shouldn't need to be anything
Allwinner-specific anyway, right (other than adding the GPU nodes to
the relevant DTS)?


Stefan


_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netbo
Elena ``of Valhalla''
2017-11-30 13:37:35 UTC
Permalink
Post by Stefan Monnier
Post by Elena ``of Valhalla''
https://wiki.debian.org/MaliGraphics (and related pages)
but there doesn't seem to be much work done for allwinner SoCs, at the
moment.
According to that web-page, there shouldn't need to be anything
Allwinner-specific anyway, right (other than adding the GPU nodes to
the relevant DTS)?
The talk in the video explained that right now packages have to be
SoC-specific (and there may even be some allwinner-specific code that is
required, but not necessarily available).

I don't remember all the details, however, and the talk explains them
better than I could (sorry for the lack of text-based references).
--
Elena ``of Valhalla''

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-net
Luke Kenneth Casson Leighton
2017-11-30 14:25:58 UTC
Permalink
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Thu, Nov 30, 2017 at 1:37 PM, Elena ``of Valhalla''
Post by Elena ``of Valhalla''
Post by Stefan Monnier
Post by Elena ``of Valhalla''
https://wiki.debian.org/MaliGraphics (and related pages)
but there doesn't seem to be much work done for allwinner SoCs, at the
moment.
According to that web-page, there shouldn't need to be anything
Allwinner-specific anyway, right (other than adding the GPU nodes to
the relevant DTS)?
The talk in the video explained that right now packages have to be
SoC-specific (and there may even be some allwinner-specific code that is
required, but not necessarily available).
I don't remember all the details, however, and the talk explains them
better than I could (sorry for the lack of text-based references).
no problem elena - i tracked it down:
http://linux-sunxi.org/Mali400#Binary_driver

two variants / sets of instructions:

http://linux-sunxi.org/Mali_binary_driver
http://free-electrons.com/blog/mali-opengl-support-on-allwinner-platforms-with-mainline-linux/

those are proprietary drivers so they will most definitely *NOT* be
going onto the RYF-Certified EOMA68-A20 Cards. btw that reminds me,
does anyone know the progress of the guy working for AMD who in his
spare time is implementing MALI400 OpenGL compatible entirely libre
drivers? he's *referencing* libv's work but is reimplementing the
library from scratch. he... maay run into difficulties as MALI400 is
so basic it requires significant parts to be done in software
(CPU-side).

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm
Andreas Baierl
2017-11-30 14:59:53 UTC
Permalink
Post by Luke Kenneth Casson Leighton
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Thu, Nov 30, 2017 at 1:37 PM, Elena ``of Valhalla''
Post by Elena ``of Valhalla''
Post by Stefan Monnier
Post by Elena ``of Valhalla''
https://wiki.debian.org/MaliGraphics (and related pages)
but there doesn't seem to be much work done for allwinner SoCs, at the
moment.
According to that web-page, there shouldn't need to be anything
Allwinner-specific anyway, right (other than adding the GPU nodes to
the relevant DTS)?
The talk in the video explained that right now packages have to be
SoC-specific (and there may even be some allwinner-specific code that is
required, but not necessarily available).
I don't remember all the details, however, and the talk explains them
better than I could (sorry for the lack of text-based references).
http://linux-sunxi.org/Mali400#Binary_driver
http://linux-sunxi.org/Mali_binary_driver
http://free-electrons.com/blog/mali-opengl-support-on-allwinner-platforms-with-mainline-linux/
those are proprietary drivers so they will most definitely *NOT* be
going onto the RYF-Certified EOMA68-A20 Cards. btw that reminds me,
does anyone know the progress of the guy working for AMD who in his
spare time is implementing MALI400 OpenGL compatible entirely libre
drivers? he's *referencing* libv's work but is reimplementing the
library from scratch. he... maay run into difficulties as MALI400 is
so basic it requires significant parts to be done in software
(CPU-side).
Mesa kmscube demo is running, though some/many components are still
missing to call it complete.

He announced the status of his project just recently:
https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/opengl-vulkan-mesa-gallium3d/991441-there-s-an-arm-mali-gallium3d-driver-still-being-developed?p=991690#post991690

The repository to follow is hosted here: https://github.com/yuq/mesa-lima

Regards
Andreas
Post by Luke Kenneth Casson Leighton
l.
_______________________________________________
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send
Luke Kenneth Casson Leighton
2017-11-30 18:18:48 UTC
Permalink
Post by Andreas Baierl
https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/opengl-vulkan-mesa-gallium3d/991441-there-s-an-arm-mali-gallium3d-driver-still-being-developed?p=991690#post991690
faaan-f****g-tastic!
Post by Andreas Baierl
The repository to follow is hosted here: https://github.com/yuq/mesa-lima
haaaa that's what i was looking for. ha that would be f*****g
amazing to have, it's the last piece that would make the A20 fully
libre.

thank you andreas.

l.

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

Loading...