| View previous topic :: View next topic |
| Author |
Message |
mDup
Apprentice
Joined: 14 Apr 2006
Posts: 212
|
 Posted: Tue Jan 10, 2017 9:38 pm Post subject: |
 |
|
| erm67 wrote: | /dev/mmcblk0p2 s probably your sd card, it doesn't support TRIM and the write speed will very soon drop to ~0 ......
There are varius ways to use the internal memory, the less risky way that also preserves your android environment is to boot balbes (or kszaq) kernel from sd and use /dev/data as root partition you can use another android partition (like /dev/cache or /dev/system) for swap but don't forget to go to android recovery and format cache&user data&system again before using android.
The root device is probably set in your uboot environment, altering uboot variables probably involves a very slight risk of bricking, it is safer do it on a serial console; a quick and dirty way is decompress the init image, extract it and modify the init bash script to boot from the /dev/data partition, recreate and compress the init image put it on the sd card and boot. Move the gentoo system to /dev/data first, that should be easy for you. This way you'll be using the sd only for booting.
The extreme solution is convert the binary dtb to dts (decompile), edit it to create the partitions you want, and recompile it.
What sounds less complicated and risky to you?
There is another way of course boot from the sd and than switch root to /dev/data, it is good to prepare the gentoo system. |
Thanks for explaining. You are right, it should be do-able for a non coward  .
The init image modifying ( decompress compress ) is a bit new to me. The one I have is an u-boot one
I sometimes used 'genkernel' and 'dracut' on gentoo amd64 and I am not yet familiar with 'u-boot'
| Code: | # ls
uInitrd
# file *
uInitrd: u-boot legacy uImage, uInitrd, Linux/ RAMDisk Image (gzip), 4344229 bytes, Sat Nov 5 11:54:18 2016, Load Address: 0x00000000, Entry Point: 0x00000000, Header CRC: 0xC58DA75B, Data CRC: 0xE6D43875
# gzip -d uInitrd
gzip: uInitrd: unknown suffix -- ignored
# cp -p uInitrd uInitrd.gz
# gzip -d uInitrd.gz
gzip: uInitrd.gz: not in gzip format
|
Perhaps you manage init image other way?
Thanks |
|
| Back to top |
|
 |
erm67
l33t
Joined: 01 Nov 2005
Posts: 653
Location: EU
|
| Posted: Tue Jan 10, 2017 9:53 pm Post subject: |
|
|
Wait, there is another way that I have not tested, but should work:
IIRC balbes kernel boots using root=label=ROOTFS
So if you format the /dev/data partition using the ext4 and label it ROOTFS and wipe (or relabel) the ROOTFS from the sd card it should boot from the SD and use /dev/data as rootfs, I wanted to test it but than installed a kernel in the internal memory replacing android 
Of course you have to make sure the gentoo system in /dev/data is actually bootable and contains all required modules and firmware
_________________
Ok boomer
True ignorance is not the absence of knowledge, but the refusal to acquire it.
Ab esse ad posse valet, a posse ad esse non valet consequentia
My fediverse account: @erm67@erm67.dynu.net |
|
| Back to top |
|
|
mDup
Apprentice
Joined: 14 Apr 2006
Posts: 212
|
| Posted: Tue Jan 10, 2017 10:46 pm Post subject: |
|
|
| erm67 wrote: |
IIRC balbes kernel boots using root=label=ROOTFS
So if you format the /dev/data partition using the ext4 and label it ROOTFS and wipe (or relabel) the ROOTFS from the sd card it should boot from the SD and use /dev/data as rootfs, [...] |
Right, that could be an alternative.
Or if build speed is all that matters I could just mount android data partition style /var/tmp/portage ... (and maybe system one style /usr/portage)
like:
| Code: | # mkdir /mnt/data
# mount /dev/data /mnt/data
# mkdir /mnt/data/tmp
# chmod 777 /mnt/data/tmp
# chmod +t /mnt/data/tmp
# cp -pr /var/tmp/portage /mnt/data/tmp
|
and setting
| Code: | PORTAGE_TMPDIR=/mnt/data/tmp/
|
in make.conf
I am more concerned about your saying: "probably your sd card, it doesn't support TRIM and the write speed will very soon drop to ~0 ...... ".
I am using it for almost 1 year now.
PS: I tried internal data partition for a tiny 'time emerge bc' and noticed some improvement (but that package only compiles a few files)
when PORTAGE_TMPDIR /mnt/data/tmp/
real 1m31.484s
when PORTAGE_TMPDIR /var/tmp/
real 1m42.618s |
|
| Back to top |
|
|
erm67
l33t
Joined: 01 Nov 2005
Posts: 653
Location: EU
|
| Posted: Wed Jan 11, 2017 5:05 am Post subject: |
|
|
I used the SD only for the first emerge -e word, months ago, the difference was considerable, several hours less. Consider that booting from the sd and having root in the /data partition involves 0 risks .... I was really surprised of the speed, expecially using -j4, sd really uscks when multiple processes write to it. eMMC is, in practice an embedded SD with an SSD controller that supports TRIM.
Ideally someone should update the uboot bootloader, archlinuxarm always ships recent uboot with network console enabled for supported platforms, it's very nice to enter the uboot 'bios' over the network without opening the case and use an usb->ttl .... but that is really risky
I am really considering to re-emerge -e world using -flto and -ftree-vectorize graphite usually makes only little difference and is still hard masked somewhere.
_________________
Ok boomer
True ignorance is not the absence of knowledge, but the refusal to acquire it.
Ab esse ad posse valet, a posse ad esse non valet consequentia
My fediverse account: @erm67@erm67.dynu.net |
|
| Back to top |
|
|
mDup
Apprentice
Joined: 14 Apr 2006
Posts: 212
|
| Posted: Wed Jan 11, 2017 3:32 pm Post subject: |
|
|
| erm67 wrote: | I used the SD only for the first emerge -e word, months ago, the difference was considerable, several hours less. Consider that booting from the sd and having root in the /data partition involves 0 risks .... I was really surprised of the speed, expecially using -j4, sd really uscks when multiple processes write to it. eMMC is, in practice an embedded SD with an SSD controller that supports TRIM.
Ideally someone should update the uboot bootloader, archlinuxarm always ships recent uboot with network console enabled for supported platforms, it's very nice to enter the uboot 'bios' over the network without opening the case and use an usb->ttl .... but that is really risky
I am really considering to re-emerge -e world using -flto and -ftree-vectorize graphite usually makes only little difference and is still hard masked somewhere. |
Thanks so much for your valuable time and expert advice and experience. I will want to go bite the bullet and prepare to run from internal. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22586
|
| Posted: Thu Jan 12, 2017 2:05 am Post subject: |
|
|
| mDup wrote: | | Code: | # mkdir /mnt/data/tmp
# chmod 777 /mnt/data/tmp
# chmod +t /mnt/data/tmp
|
|
This can be compressed to one command mkdir -m1777 path. If the directory already exists, you can use chmod 1777 path to set the mode and the sticky flag in a single step. |
|
| Back to top |
|
|
mDup
Apprentice
Joined: 14 Apr 2006
Posts: 212
|
| Posted: Thu Jan 12, 2017 11:50 pm Post subject: |
|
|
| Hu wrote: | | mDup wrote: | | Code: | # mkdir /mnt/data/tmp
# chmod 777 /mnt/data/tmp
# chmod +t /mnt/data/tmp
|
|
This can be compressed to one command mkdir -m1777 path. If the directory already exists, you can use chmod 1777 path to set the mode and the sticky flag in a single step. |
Learning new UNIX CLI tricks never stops (also not after 30 years of practice).  |
|
| Back to top |
|
|
erm67
l33t
Joined: 01 Nov 2005
Posts: 653
Location: EU
|
| Posted: Fri Jan 13, 2017 7:04 am Post subject: |
|
|
I also found a new trick 
useflags can be unmasked here:
/etc/portage/profile/use.mask
| Code: | mysql
-aacplus
-fuse
-java
-kerberos
-ldap
-ladspa
-mono
-mercurial
-musepack
-pkcs11
-sasl
-toolame
-vpx
-xfs
-xine
-zvbi
-x264
-x265
-bluray
-graphite
|
this is mine so far ...
_________________
Ok boomer
True ignorance is not the absence of knowledge, but the refusal to acquire it.
Ab esse ad posse valet, a posse ad esse non valet consequentia
My fediverse account: @erm67@erm67.dynu.net |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54575
Location: 56N 3W
|
| Posted: Fri Jan 13, 2017 11:03 am Post subject: |
|
|
erm67,
/etc/portage/profile/use.mask actually inverts the USE mask in force.
arm64 has (-java) so the -java entry inverts the forced off. You can also force things off here.
/etc/portage/profile/package.use.mask allows per package USE unmasking
So far, I have | Code: | media-libs/mesa -video_cards_vc4
x11-libs/libdrm -video_cards_vc4
# java is hard masked on arm64
app-office/libreoffice -java |
java seems OK, the vc4 video needs more kernel work for 64 bit operation,
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
mDup
Apprentice
Joined: 14 Apr 2006
Posts: 212
|
| Posted: Fri Jan 13, 2017 4:20 pm Post subject: |
|
|
| NeddySeagoon wrote: | | [...]/etc/portage/profile/use.mask actually inverts the USE mask in force.[...] |
Exactly, that's what I explained earlier with -x246 ... e.g.: without it one cannot build ffmpeg using x246 on arm64
So if I add any other of your -xxx to my profile use.mask, my particular 'system' and 'world' deep emerge does not need update, but if I do not uncomment, for example upnp, then vlc 9999 needs rebuild in my world.
That's because none of the -xxx you added are forcibly masked for arm64 for any of my ebuilds in my world or system (recall -x246 was for ffmpeg), but I want to use upnp for all ebuilds that I ask to use it (I happen to have it in make.conf but that does not matter, I could have it just for vlc in package.use).
So e.g. in profile use mask I have (amongst many other changes)
-x246 : force allow individual ebuilds that are forced to not use x246 on arm64 to use it anyway
#upnp : allow any ebuild to use upnp on arm64
Last edited by mDup on Fri Jan 13, 2017 5:17 pm; edited 1 time in total |
|
| Back to top |
|
|
erm67
l33t
Joined: 01 Nov 2005
Posts: 653
Location: EU
|
| Posted: Fri Jan 13, 2017 5:04 pm Post subject: |
|
|
@NeddySeagoon let's face the truth, be honest with yourself and the others, some stuff that works perfectly on all other arm64 distro is masked in gentoo for no reason at all SINCE 2010, in 7 years nobody tested them or unmasked the stuff, do you think maybe in another 7 years someone will unmask that stuff? All those programs and features works already without any modification simply unmasking them, what's the added value in waiting for someone to unmask them? TBH it's a shame that all that stuff is still masked in 2017, but arm64 is not an official arch anyway.
_________________
Ok boomer
True ignorance is not the absence of knowledge, but the refusal to acquire it.
Ab esse ad posse valet, a posse ad esse non valet consequentia
My fediverse account: @erm67@erm67.dynu.net |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54575
Location: 56N 3W
|
| Posted: Fri Jan 13, 2017 5:17 pm Post subject: |
|
|
erm67,
keyword additions are one of the easiest githup PRs to get into the tree.
Join #gentoo-proxy-maint to dip a toe in the water. Oh, I can't commit things as I'm not an ebuild developer.
When some reasonably performing arm64 hardware in available, 1G RAM/core. SATA. ... > 4 cores, arm64 will interest
more people. The cello looked promising but the PCIe slot
doesn't work with new AMD silicon.
I don't see me keywording KDE on a Raspberry Pi but I've made a start on smaller packages.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
erm67
l33t
Joined: 01 Nov 2005
Posts: 653
Location: EU
|
| Posted: Sun Jan 15, 2017 8:08 am Post subject: |
|
|
| NeddySeagoon wrote: | erm67,
keyword additions are one of the easiest githup PRs to get into the tree.
Join #gentoo-proxy-maint to dip a toe in the water. Oh, I can't commit things as I'm not an ebuild developer.
When some reasonably performing arm64 hardware in available, 1G RAM/core. SATA. ... > 4 cores, arm64 will interest
more people. The cello looked promising but the PCIe slot
doesn't work with new AMD silicon.
I don't see me keywording KDE on a Raspberry Pi but I've made a start on smaller packages. |
I don't believe keywording is useful at this point and I found something a bit more interesting, mono was fixed for aarch64 in fedora & debian, since I might be interested in running emby I guess I need to fix an ebuild after a very long time (All other distro ships mono builds for aarch64)
And the php guys fixed opcache building for aarch64 ..... but I guess the php ebuild will be updated as soon as it is relesed upstream.
The problem with arm is the graphic drivers, to use it as a desktop. I think most peole use it as a htpc, there is plenty of boards fast out there. Of course with all that hardmasked stuff gentoo arm64 is useless as an htpc so any potential user is scared away.
The problem of the raspberryPi is really slow IO, I have no problems using gentoo on the internal SSD or even over (Gbit) iscsi. emerge takes more or less the same time as on a not so recent amd64 laptop, maybe less than one using a rotational disk. Also harkernel odroid supports eMMC drives so the potential nuber of user is increasing ...
_________________
Ok boomer
True ignorance is not the absence of knowledge, but the refusal to acquire it.
Ab esse ad posse valet, a posse ad esse non valet consequentia
My fediverse account: @erm67@erm67.dynu.net |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54575
Location: 56N 3W
|
| Posted: Sun Jan 15, 2017 11:52 am Post subject: |
|
|
erm67,
You are right about the really slow IO on the Pi. Just a single USB2 root hub for USB and ethernet.
The vc4 hardware driver still looks to be 32 bit only, so its framebuffer only for me at the moment.
sdlmame builds but with sub 1Hz framerates, it not useful.
I don't agree about keywording. Adding ~arm64 shows a package had had some testing.
It may encourage less adventurous users to play on arm64. Its going to be required to get more than @system stable on arm64.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
erm67
l33t
Joined: 01 Nov 2005
Posts: 653
Location: EU
|
| Posted: Sun Jan 15, 2017 8:09 pm Post subject: |
|
|
| NeddySeagoon wrote: |
I don't agree about keywording. Adding ~arm64 shows a package had had some testing.
It may encourage less adventurous users to play on arm64. Its going to be required to get more than @system stable on arm64. |
I don't think gentoo has enough manpower to do that in a credible way, if I cannot buy a Ferrari maybe I still need to buy a Yugo to drive at my workplace... And aarch64 is really stable at this point, there are a lot less problems compared to mips (which I use with openwrt), basically all problems have been fixed in the last 4 years by the other distros actively developing for aarch64, and using recent releases of all packages there are no problems.. It makes a lot sense make at least everything available as ~arm64 .......
https://forums.gentoo.org/viewtopic-p-7921472.html?sid=4813717a338cfe557720e74b13be30eb
Did you ever manage to build icedtea for arm64?
Build openjdk from source outside portage seems the the most reasonable solution at this point aarch64 is an official arch for jdk9, and jdk8....
BTW emby works like a charm on arm64 with mono from ~amd64 ...
_________________
Ok boomer
True ignorance is not the absence of knowledge, but the refusal to acquire it.
Ab esse ad posse valet, a posse ad esse non valet consequentia
My fediverse account: @erm67@erm67.dynu.net |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54575
Location: 56N 3W
|
| Posted: Sun Jan 15, 2017 9:28 pm Post subject: |
|
|
erm67,
Yes I have icedtea for arm64
Its a bit of a hack but you will only do it once.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
erm67
l33t
Joined: 01 Nov 2005
Posts: 653
Location: EU
|
| Posted: Mon Jan 16, 2017 12:00 pm Post subject: |
|
|
Thank you, it works, but there's only a jdk available for arm64 and not a jre .... in a couple of places you wrote jre in other jdk ....
I choose not to emerge it since it pulls in Xorg even using USE=headless_awt, I only need java for a couple of things (like projectx) and I'll be fine with oracle jdk.
_________________
Ok boomer
True ignorance is not the absence of knowledge, but the refusal to acquire it.
Ab esse ad posse valet, a posse ad esse non valet consequentia
My fediverse account: @erm67@erm67.dynu.net |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54575
Location: 56N 3W
|
| Posted: Mon Jan 16, 2017 12:50 pm Post subject: |
|
|
erm67,
The jdk includes the jre. There are probably not enough users to package a separate jre.
I didn't notice the dependency on Xorg as I run a desktop on my Pi3,
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
mDup
Apprentice
Joined: 14 Apr 2006
Posts: 212
|
| Posted: Sun Jan 29, 2017 5:30 pm Post subject: gentoo s905x image |
|
|
https://yadi.sk/d/8WUMwurb38CYTi
Gentoo_8gb_20170128.img.xz
md5sum da1c74abca86f07e866dac6cced01f7c
This gentoo system image and kernel are 100% natively built on minimx-g s905 itself.
It has been verified to run on s905x too.
The gentoo is bleeding edge in that it accepts all keywords,
also: gcc-6.3.0 and glibc-2.24 ebuilds are hacked (KEYWORDS un-commented),
and: arm64 use.mask profile is less restrictive.
A few packages are added in top of system.
You must set date manually or emerge will complain. In root there is a README file.
To change resolution, etc.. follow same procedure as outlined by Author balbes150 in OP.
In fact: all kind help comes from him and all credits go to him.
Kernel is 150balbes github branch S905X. It is natively built with gcc-4.9.4.
Starting from this image I have built a LxQt centric Desktop without much pain.
You can use it to build any other gentoo machine you feel like building.
Kernel is work in progress. There is another branch (ordroid) in 150balbes github which may become the next kernel. But ordroid kernel is s905 -only for now. |
|
| Back to top |
|
|
erm67
l33t
Joined: 01 Nov 2005
Posts: 653
Location: EU
|
| Posted: Mon Jan 30, 2017 7:24 pm Post subject: |
|
|
Do you have the overlayfs backport patch? It comes from the odroid kernel but it was ported to kszaq kernel for libreelec 8.0 beta, I think it might work with minor change also with balbes kernel
The patch is in libreelec git:
LibreELEC.tv/packages/linux/patches/amlogic-3.14/linux-002-backport_overlayfs.patch
overlayfs is really a bonus to run docker since, well, the device-mapper backend of docker never worked very well and btrfs in kernel 3.14 is too ancient to be relayed on.
_________________
Ok boomer
True ignorance is not the absence of knowledge, but the refusal to acquire it.
Ab esse ad posse valet, a posse ad esse non valet consequentia
My fediverse account: @erm67@erm67.dynu.net |
|
| Back to top |
|
|
mDup
Apprentice
Joined: 14 Apr 2006
Posts: 212
|
| Posted: Mon Jan 30, 2017 10:04 pm Post subject: |
|
|
| erm67 wrote: | Do you have the overlayfs backport patch? It comes from the odroid kernel but it was ported to kszaq kernel for libreelec 8.0 beta, I think it might work with minor change also with balbes kernel
The patch is in libreelec git:
LibreELEC.tv/packages/linux/patches/amlogic-3.14/linux-002-backport_overlayfs.patch
overlayfs is really a bonus to run docker since, well, the device-mapper backend of docker never worked very well and btrfs in kernel 3.14 is too ancient to be relayed on. |
I do not have the patch in kernel. It is exact recent 150balbes github cloned code. But I guess anyone can add it and build own kernel and other boot files.
see: https://forum.armbian.com/index.php/topic/3344-trying-to-recompile-the-kernel-for-mini-m8s/
update: the ordroid 150balbes github branch does have the overlayfs backport patch.
but this kernel is from S905X branch. |
|
| Back to top |
|
|
erm67
l33t
Joined: 01 Nov 2005
Posts: 653
Location: EU
|
| Posted: Tue Jan 31, 2017 12:29 pm Post subject: |
|
|
| mDup wrote: | | erm67 wrote: | Do you have the overlayfs backport patch? It comes from the odroid kernel but it was ported to kszaq kernel for libreelec 8.0 beta, I think it might work with minor change also with balbes kernel
The patch is in libreelec git:
LibreELEC.tv/packages/linux/patches/amlogic-3.14/linux-002-backport_overlayfs.patch
overlayfs is really a bonus to run docker since, well, the device-mapper backend of docker never worked very well and btrfs in kernel 3.14 is too ancient to be relayed on. |
I do not have the patch in kernel. It is exact recent 150balbes github cloned code. But I guess anyone can add it and build own kernel and other boot files.
see: https://forum.armbian.com/index.php/topic/3344-trying-to-recompile-the-kernel-for-mini-m8s/
update: the ordroid 150balbes github branch does have the overlayfs backport patch.
but this kernel is from S905X branch. |
We should create an overlay with ebuild relative to S905, TBH I am not using any custom ebuild ATM, but some are required for desktop, like libamlogic, opengl, kodi patches .....
I am using kszaq kernel from the libreelec 8.0 beta now, it is probably the most uptodate.
kernel 4.10 boots fine using odroid dts but HDMI is not supported (yet).
_________________
Ok boomer
True ignorance is not the absence of knowledge, but the refusal to acquire it.
Ab esse ad posse valet, a posse ad esse non valet consequentia
My fediverse account: @erm67@erm67.dynu.net |
|
| Back to top |
|
|
mDup
Apprentice
Joined: 14 Apr 2006
Posts: 212
|
| Posted: Tue Jan 31, 2017 1:56 pm Post subject: |
|
|
| erm67 wrote: | [...]
We should create an overlay with ebuild relative to S905, TBH I am not using any custom ebuild ATM, but some are required for desktop, like libamlogic, opengl, kodi patches .....
I am using kszaq kernel from the libreelec 8.0 beta now, it is probably the most uptodate.
kernel 4.10 boots fine using odroid dts but HDMI is not supported (yet). |
Did you build kszaq's kernel yourself? If so, what is your recipe? I ask because kszaq's kernel uses the special media driver repository.
The odroid kernel, IMO, is also very much up to date. It is 3.14.79 with a lot of drivers.
As for 4.10, can you provide the .config ? |
|
| Back to top |
|
|
erm67
l33t
Joined: 01 Nov 2005
Posts: 653
Location: EU
|
| Posted: Tue Jan 31, 2017 9:19 pm Post subject: |
|
|
| mDup wrote: | | erm67 wrote: | [...]
We should create an overlay with ebuild relative to S905, TBH I am not using any custom ebuild ATM, but some are required for desktop, like libamlogic, opengl, kodi patches .....
I am using kszaq kernel from the libreelec 8.0 beta now, it is probably the most uptodate.
kernel 4.10 boots fine using odroid dts but HDMI is not supported (yet). |
Did you build kszaq's kernel yourself? If so, what is your recipe? I ask because kszaq's kernel uses the special media driver repository.
The odroid kernel, IMO, is also very much up to date. It is 3.14.79 with a lot of drivers.
As for 4.10, can you provide the .config ? |
yes, the media build from linuxtv, I also have a dvb-t adapter that only works with recent drivers, that's relatively easy.... well, there's a quick&dirty wayto compile kszaq kernel, of course all credits go to him and libreelec contributors, etc etc etc, (I don't want to start a distro war):
clone the git repo for libreelec on your PC
build it (you can kill the build process while it's compiling the kernel
go to the build.LibreELEC-S905.arm-8/
directory and copy the kernel sources with all libreelec patches already appliedy .... don't forget to thank kszaq
(alternatively you can grab the patches and apply them but it's faster to build the distro)
if you want I can post my .config, I just added what was required to run docker and a couple of other things that sometimes emerge.log recommends and iscsi drivers, I mount all write intensive dirs over iscsi to spare the internal ssd, the eth is really fast for such a small board, only slightly slower than the eMMC ... and full duplex unlike the USB2 ports.
In theory a 16Gb eMMC with a worst case 3000 write cycles should have a life long enough, but better be safe.
for linux 4.10 I just followed the recipe at http://linux-meson.com/doku.php; make defconfig will enable all amlogic drivers, the problem is that the dtb are different and the ones we're using do not work (probably), also you really need a serial terminal to boot it, otherwise there is only a black screen, the linux-meson guys are working already on hdmi support.
I am thinking about merging the existing dtb with the new ones shipped with linux 4.10, mostly to partition the emmc drive with the android partitioning scheme, at least until linux supports the board fully.
_________________
Ok boomer
True ignorance is not the absence of knowledge, but the refusal to acquire it.
Ab esse ad posse valet, a posse ad esse non valet consequentia
My fediverse account: @erm67@erm67.dynu.net |
|
| Back to top |
|
|
mDup
Apprentice
Joined: 14 Apr 2006
Posts: 212
|
| Posted: Wed Feb 01, 2017 12:28 am Post subject: |
|
|
| erm67 wrote: | [...]
for linux 4.10 I just followed the recipe at http://linux-meson.com/doku.php; make defconfig will enable all amlogic drivers, the problem is that the dtb are different and the ones we're using do not work (probably), also you really need a serial terminal to boot it, otherwise there is only a black screen, the linux-meson guys are working already on hdmi support.
I am thinking about merging the existing dtb with the new ones shipped with linux 4.10, mostly to partition the emmc drive with the android partitioning scheme, at least until linux supports the board fully. |
Thanks for pointing to http://linux-meson.com/
just for all clarity
1) this is just unaltered linux 4.x kernel code right (y/n)?
2) does HDMI work on none or only not on your box?
[I would prefer to wait for hdmi support ...] |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo on ARM
