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
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Tue, Nov 28, 2017 at 1:11 AM, Adam Van Ymeren adam@vany.ca wrote:
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).
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.
On Tue, Nov 28, 2017 at 3:11 AM, Adam Van Ymeren adam@vany.ca wrote:
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.
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Tue, Nov 28, 2017 at 5:13 PM, Bill Kontos vkontogpls@gmail.com wrote:
On Tue, Nov 28, 2017 at 3:11 AM, Adam Van Ymeren adam@vany.ca wrote:
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.
On Tue, Nov 28, 2017 at 9:03 PM, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
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.
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Tue, Nov 28, 2017 at 8:24 PM, Bill Kontos vkontogpls@gmail.com wrote:
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.
On Tue, Nov 28, 2017 at 07:03:50PM +0000, Luke Kenneth Casson Leighton wrote:
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.
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Tue, Nov 28, 2017 at 8:51 PM, Tzafrir Cohen tzafrir@cohens.org.il wrote:
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.
On Wed, Nov 29, 2017 at 08:16:05AM +0000, Luke Kenneth Casson Leighton wrote:
On Tue, Nov 28, 2017 at 8:51 PM, Tzafrir Cohen tzafrir@cohens.org.il wrote:
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
On Wed, Nov 29, 2017 at 8:46 AM, Pablo Rath pablo@parobalth.org wrote:
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.
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"
On 2017-11-29 at 21:00:37 -0500, Stefan Monnier wrote:
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.
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.
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
On 2017-11-30 at 08:14:09 -0500, Stefan Monnier wrote:
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.
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).
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Thu, Nov 30, 2017 at 1:37 PM, Elena ``of Valhalla'' valhalla-l@trueelena.org wrote:
On 2017-11-30 at 08:14:09 -0500, Stefan Monnier wrote:
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.
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-wi...
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.
Am 30.11.2017 um 15:25 schrieb 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'' valhalla-l@trueelena.org wrote:
On 2017-11-30 at 08:14:09 -0500, Stefan Monnier wrote:
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.
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-wi...
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-vu...
The repository to follow is hosted here: https://github.com/yuq/mesa-lima
Regards Andreas
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-netbook@files.phcomp.co.uk
On Thu, Nov 30, 2017 at 2:59 PM, Andreas Baierl list@imkreisrum.de wrote:
He announced the status of his project just recently: https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/opengl-vu...
faaan-f****g-tastic!
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@lists.phcomp.co.uk
-
Adam Van Ymeren -
Andreas Baierl -
Bill Kontos -
Elena ``of Valhalla'' -
Luke Kenneth Casson Leighton -
Pablo Rath -
Stefan Monnier -
Tzafrir Cohen