# Gentoo on ECS Liva (BAT-MINI--Bay Trail SoC)

## SiliconFiend

I just picked up one of the ECS Liva (2 GB RAM, 32 GB eMMC, Intel Bay Trail N2807, Ethernet, USB 2.0 and USB 3.0, HDMI + VGA, WiFi+BlueTooth via M.2 card) on sale at Newegg to use as a MythTV frontend and I wanted to share some notes from my install experience, hopefully to save someone some time and frustration. First of all, when you're installing the included wireless antennas, don't try to pull off the plastic shields on the wires or you will likely pull off the connectors. Just push them up on the wire out of the way.

The only boot option for this system is USB (unless you can get PXE/netboot working, but I'll assume USB). So the first step is finding a workable USB boot disk. The Gentoo install ISOs claim to be hybrid and that you can just dd the ISO to the USB stick and boot from that, but I did not have any luck with that method. It was not recognized at all as valid boot media. I finally got it working by mounting the ISO from SysRescueCD (which is Gentoo-based) as a loopback (on another Linux system) and then running the included usb_inst.sh script. I suspect it's because the Gentoo install CDs may be MBR boot based and this system apparently only supports UEFI boot. Anyway, once it brought up the GRUB menu, I had to select the Alternative Kernel option; anything else wouldn't boot.

After booting, I followed the AMD64 Gentoo Handbook install instructions, but ran into some pitfalls as those instructions are again geared toward MBR boot but UEFI requires a different partitioning for boot. Here's how my partitions ended up (after some rearranging thanks to gparted):

mmcblk0p1: 128 MiB, EFI System partition (gdisk code EF00), formatted FAT32. Note that FAT32 seems to be important here, and that requires a minimum filesystem size.

mmcblk0p2: 128 MiB, boot (gdisk code 8300), formatted ext2

mmcblk0p3: 512 MiB, swap (gdisk code 8200), formatted with mkswap. Not sure if it's required for this system or even a good idea on an SSD, but...

mmcblk0p4: rest of disk (~29 GiB), root (gdisk code 8300), formatted brtrfs

I installed the stage3 tarball, chroot'd, did all the config steps in the handbook and then configured the kernel. This was by far the most time-consuming step and involved a lot of test, modify config, recompile and reinstall, reboot. One thing I did to try to get everything working is search for config features with BAY or TRAIL in the name and enable anything BayTrail related. There were also a number of SoC config options which were applicable. Also I enabled all the modules which were detected and loaded by the USB boot disk. Some key notes to getting the WiFi card working: It's a Broadcom 43241 and it uses the brcmfmac driver with the SDIO interface. It also needs the linux-firmware package installed, specifically the /lib/firmware/brcm/brcmfmac43241b4-sdio.bin file. One more thing I needed to do is to copy the NVRAM settings from /sys/firmware/efi/efivars/nvram-(some string of numbers) to /lib/firmware/brcm/brcmfmac43241b4-sdio.txt That file had some garbage characters on the first and last lines but I stripped them out with nano. Not sure if it was necessary to get rid of that garbage or not. Note that I did this step after already booting on the new kernel so the boot USB may not have what you need to get those nvram settings. The kernel needs efivars enabled at a minimum. More information about the firmware here. The kernel I installed was 3.16.5-gentoo (the boot USB was 3.14.something). The wireless driver (really just firmware files) on the ECS support website is targeted at an earlier kernel, because they are named brcmfmac-sdio.bin and brcmfmac-sdio.txt and the naming changed to more specific model names somewhere around 3.10 or 3.11 I think. Note that based on some discussion on a mailing list I did not enable power saving for the wireless driver. I may try to enable it now that everything's working, but the whole system is only 15 W max (and probably more like 5W typical), so I doubt it would make much difference anyway. The Ethernet port uses the RealTek r8169 driver. Video is the Intel i915 driver. USB uses the xhci driver. I can share my kernel config if someone wants it.

grub2-install seemed to work fine with the defaults (which is a 64 bit EFI install), but you need to mount /boot, and then mount the EFI system partition on /boot/efi before running grub2-install. I tried to keep it simple and boot with just a kernel without an initramfs, but I think the eMMC storage wouldn't work, so I used dracut to create the initramfs with 

```
dracut --hostonly '' 3.16.5-gentoo
```

 and then 

```
grub2-mkconfig -o /boot/grub/grub.cfg
```

I had some struggles getting the WiFi adapter working the way I want. I made the mistake of putting dhcpcd and the net.wlan0 modules in the default runlevel, which caused wpa_supplicant to be started twice, and the second time (in net.wlan0), it threw the following error and wouldn't start (although wireless was still working, thanks to dhcpcd):

```
ctrl_iface exists and seems to be in use - cannot override it

Delete '/var/run/wpa_supplicant/wlan0' manually if it is not used anymore
```

I tried to use the net.* scripts as in the handbook but for some reason it didn't appear to be running dhcpcd for wlan0 after wpa_supplicant connected, so I gave up, removed the net.* scripts from the default runlevel and added dhcpcd back. It seems to be working now, but I'll probably revisit this since I'd prefer to use the net.* scripts because they seem to give me more control (and I want to try to set up an Ethernet bridge)

Some notes on installing packages: This thing is not a compile beast, but it is totally adequate (make sure you add MAKEOPTS="-j3" to take advantage of the 2 cores). I did an emerge mythtv and it pulled in 105 packages, including mariadb and most of the qt libs. It took about 5 hours to compile all that. For some reason it didn't pull in the xorg-server packages (I'll mention that to the mythtv package maintainer) and I think emerge xorg-server took maybe another hour. After installing all this it used only about 4 GiB. I don't envision installing much more but the 32 GB is plenty of space for this application.

The system is pretty quick to boot. Since it's only a frontend it's not running many services. From power-on to X starting is about 20 seconds. I had to add a 10 second delay before starting mythfrontend because it was coming up before the wireless card got an address, which put myth into "new config" mode. One nice thing--VAAPI worked right away; all the necessary libraries were pulled in automatically by way of the vaapi USE flag. I had to change the MythTV painter to OpenGL, but other than that, it worked great.

One other note: I also got an MCE remote to use with this system (an OEM-branded Ortek VRC1100). Thanks to devinput it worked right away out-of-the-box (even the mouse!). However, the "Back" (left arrow) button adjacent to the directional keys maps to Backspace, and the "Clear" button on the bottom center below the number buttons maps to Escape. MythTV did not fully support remapping those keys itself (some things worked, some didn't) so I used ir-keytable to swap them. I added the command in a udev rule as follows (based on a rule from here):

```
KERNEL=="event*",SUBSYSTEM=="input",ATTRS{idVendor}=="05a4",ATTRS{idProduct}=="9881",IMPORT{program}="input_id %p"

KERNEL=="event*",SUBSYSTEM=="input",ATTRS{idVendor}=="05a4",ATTRS{idProduct}=="9881",ENV{ID_INPUT_KEYBOARD}=="1",ACTION=="add",SYMLINK="input/irremote0",RUN+="/usr/bin/ir-keytable --set-key=0x70029=KEY_BACKSPACE,0x7002a=KEY_ESC --device /dev/input/irremote0"

KERNEL=="event*",SUBSYSTEM=="input",ATTRS{idVendor}=="05a4",ATTRS{idProduct}=="9881",ENV{ID_INPUT_MOUSE}=="1",SYMLINK="input/irremote1"
```

With the one exception of the Bluetooth, everything is working on the system--HDMI (audio + video), VGA, analog audio, WiFi, Ethernet, etc. I haven't seen any indication of driver support for the Bluetooth but that's not important to me. I'm happy to share any config files, etc. if that will help someone. I'm pretty persistent and don't get easily frustrated when working with hardware, so I don't mind slogging it out until it works the way I want it to. As one of my customers once said: "An engineer will work on something until you take it away from him[/her]."

Edit: Added details about the hardware and antenna installation

Edit2: I've switched to using analog audio, but unfortunately it seems the analog audio output levels are extremely low, so I added an alsa pre-amp via the softvol plugin. Found a good guide here: http://blog.tpa.me.uk/2013/10/23/alsa-pre-amp-volume-boost-the-simple-explanation/ Effectively it involves creating an /etc/asound.conf with the following contents:

```
pcm.!default {

      type plug

      slave.pcm "softvol"

  }

  pcm.softvol {

      type softvol

      slave {

          pcm "dmix"

      }

      control {

          name "Pre-Amp"

          card 0

      }

      min_dB -5.0

      max_dB 40.0

      resolution 12

  }
```

Note that in order for the pre-amp to show up in alsamixer you have to actually play a sound (I used aplay <some wav file.wav>) Then you can open alsamixer and adjust the pre-amp level. I think Mythfrontend needs to be restarted to pick up the new configuration, and you'll need to change your audio device from 'ALSA:default:card=PCH' to just read 'ALSA:default' (mine threw an error about invalid device until I deleted the card= stuff).Last edited by SiliconFiend on Fri Jan 02, 2015 5:17 am; edited 1 time in total

----------

## snkmoorthy

Thank you friend, I mean Fiend   :Razz: 

----------

## WD-40

Thanks SiliconFiend!  This was definitely helpful information, and well timed too as I saw your post on the MythTV Users mailing list right after I received my LIVA last week.    :Cool: 

A couple comments based on my own install:

I didn't have any luck either booting from Gentoo-based USB media, so I instead used the 64-bit Linux Mint 17.1 XFCE RC on a USB stick as my boot media / installation environment.  (http://blog.linuxmint.com/?p=2742)

This was almost completely successful, and I was able to proceed through the AMD64/x86_64 handbook (https://wiki.gentoo.org/wiki/Handbook:AMD64) for a pure 64-bit no-multilib install.  The only catch was that two packages (pypy I believe?) failed to compile with sandbox errors in the chrooted environment.  (Not a problem, just picked them up on the reboot in the native environment.)  Otherwise it worked well, and I didn't need the Gentoo installation CD/ISO or anything other than the Mint installer stick and the Gentoo stage 3 tarball.

I omitted the swap partition, with no ill effects.

I used ext4 as the filesystem for my root partition....  SiliconFiend, any particular reason you used brtrfs?   :Question: 

If it helps any, I found out that an initramfs / dracut is NOT required.   I too like to keep things simple.  :Wink:     The key was that the system was loading too fast for the eMMC to be available in time for the root mount... so the fix was to edit /etc/default/grub, and add "rootdelay=8" to the GRUB_CMDLINE_LINUX_DEFAULT line for default kernel parameters and regenerate the grub config.  After that, the system would pause on boot, the eMMC partitions would populate, and then the booting would resume with the root filesystem mount after the 8 second timeout.    :Cool:     8 seconds was somewhat arbitrary... less may be OK, but I decided to play it safe.

I used the current (3.17.7) kernel source

I don't have wireless working yet with the internal M.2 Broadcom wifi card, but I temporarily substituted a USB Ralink adapter and made the connection using ConnMan.   I did the bulk of the initial install with a batch of 'emerge --fetchonly' commands in the chroot environment followed by "off-line" compiles once booted directly.  

SiliconFiend, are you having any issues with display tearing in X and/or in MythTV?  I ran a test using an install of Mint 16 (before I made the 17.1 stick) on the LIVA before I started, and I had tearing and frame drops on the frontend.  This was somewhat expected, as I did essentially zero to configure the frontend before wiping it for the Gentoo install.    :Wink:       But once I had Gentoo installed, I enabled the "TearFree" graphics driver option, and it DID fix tearing, but at a noticeable negative impact to even general purpose non-video usage.      :Confused:      I also have an issue that launching glxgears results in an *immediate* crash of Xorg and dumps me back to the console.   Curiously, other OpenGL applications (Neverball, etc.) seem to run fine?   If I run as-is (without the TearFree option), I see visible tearing in Neverball and can just barely detect it if I move windows around quickly on my X desktop.

Initial power consumption looks very good... scratch that... incredible.   With my USB hub, wifi adapter, a few USB sticks, etc, I was seeing 2-3 watts on my Kill-A-Watt meter.    :Cool:    I'm going to have to upgrade to a different meter to get a reading in tenths of a watt to see what the actuals are.    :Cool: 

Thanks again for being the pioneer and sharing your findings!    :Cool: 

----------

## SiliconFiend

 *WD-40 wrote:*   

> Thanks SiliconFiend!  This was definitely helpful information, and well timed too as I saw your post on the MythTV Users mailing list right after I received my LIVA last week.   
> 
> A couple comments based on my own install:
> 
> <snip>
> ...

 Nothing particularly special, but I wanted a modern FS and I use it on my Myth combined front/backend for mass storage. One advantage is no boot-time fsck so you don't get stuck with an hour+ fsck when you just wanted to reboot real quick. Plus I can use subvolumes to partition a pool of storage between different uses without the hard boundaries that hard drive partitions give you.

 *WD-40 wrote:*   

> If it helps any, I found out that an initramfs / dracut is NOT required.   I too like to keep things simple.     The key was that the system was loading too fast for the eMMC to be available in time for the root mount... so the fix was to edit /etc/default/grub, and add "rootdelay=8" to the GRUB_CMDLINE_LINUX_DEFAULT line for default kernel parameters and regenerate the grub config.  After that, the system would pause on boot, the eMMC partitions would populate, and then the booting would resume with the root filesystem mount after the 8 second timeout.       8 seconds was somewhat arbitrary... less may be OK, but I decided to play it safe.

 Interesting find. I have an initramfs now, though, so I'll probably just stay with it. I have to have one for my main system anyway (root is on a software RAID 5) so there was no learning curve there.

 *WD-40 wrote:*   

> I used the current (3.17.7) kernel source
> 
> 

 Yes, I just upgraded to that also, since it was stabilized.

 *WD-40 wrote:*   

> I don't have wireless working yet with the internal M.2 Broadcom wifi card, but I temporarily substituted a USB Ralink adapter and made the connection using ConnMan.   I did the bulk of the initial install with a batch of 'emerge --fetchonly' commands in the chroot environment followed by "off-line" compiles once booted directly.  
> 
> 

 Once I got the firmware thing sorted out it really wasn't a big deal. Just install and configure wpa-supplicant and away you go. Although I'm a little frustrated right now--it won't hold a connection for more than a few seconds right now. Not sure if I broke something or just the signal is too weak (but it was pretty solid when I first put it back there). Needless to say, it's useless as a frontend until I finish my CAT6 install.

 *WD-40 wrote:*   

> 
> 
> SiliconFiend, are you having any issues with display tearing in X and/or in MythTV?  I ran a test using an install of Mint 16 (before I made the 17.1 stick) on the LIVA before I started, and I had tearing and frame drops on the frontend.  This was somewhat expected, as I did essentially zero to configure the frontend before wiping it for the Gentoo install.         But once I had Gentoo installed, I enabled the "TearFree" graphics driver option, and it DID fix tearing, but at a noticeable negative impact to even general purpose non-video usage.          I also have an issue that launching glxgears results in an *immediate* crash of Xorg and dumps me back to the console.   Curiously, other OpenGL applications (Neverball, etc.) seem to run fine?   If I run as-is (without the TearFree option), I see visible tearing in Neverball and can just barely detect it if I move windows around quickly on my X desktop.
> 
> 

 I haven't tested it much at all, and it's been generally with SD MPEG2. I did do a quick test with the sample videos from the frontend setup wizard and the HD looked pristine (to me anyway). Make sure you enable the vaapi USE flag when you install everything. And if you didn't initially, you should do an 'emerge -uND @world' after enabling it to rebuild the applicable packages. And of course the frontend renderer has to be set to OpenGL for VAAPI to work.

 *WD-40 wrote:*   

> Initial power consumption looks very good... scratch that... incredible.   With my USB hub, wifi adapter, a few USB sticks, etc, I was seeing 2-3 watts on my Kill-A-Watt meter.      I'm going to have to upgrade to a different meter to get a reading in tenths of a watt to see what the actuals are.   
> 
> Thanks again for being the pioneer and sharing your findings!   

 Yep, the power consumption is pretty amazing, and is really the icing on the cake given the functionality of this little unit.

No problem, I'm glad to share back with the community that has helped me so much (mostly in documenting the tricky bits).

----------

## WD-40

 *SiliconFiend wrote:*   

> 
> 
>  *WD-40 wrote:*   I don't have wireless working yet with the internal M.2 Broadcom wifi card, but I temporarily substituted a USB Ralink adapter and made the connection using ConnMan.   I did the bulk of the initial install with a batch of 'emerge --fetchonly' commands in the chroot environment followed by "off-line" compiles once booted directly.  
> 
>  Once I got the firmware thing sorted out it really wasn't a big deal. Just install and configure wpa-supplicant and away you go. Although I'm a little frustrated right now--it won't hold a connection for more than a few seconds right now. Not sure if I broke something or just the signal is too weak (but it was pretty solid when I first put it back there). Needless to say, it's useless as a frontend until I finish my CAT6 install.
> ...

 

I finally got my Broadcom M.2 wifi card working today.    :Surprised: 

I had a few different problems with it...  I'm not 100% sure, but I *think* it was having the same problem as the eMMC in that it was being loaded too early (before the eMMC in fact), and because of that, it wasn't able to read the firmware file at boot time?   This was the error I was receiving:  (posted for the search engines to find)

```
[    2.477972] brcmfmac: brcmf_sdio_drivestrengthinit: No SDIO Drive strength init done for chip 4324 rev 5 pmurev 17

[    2.482115] brcmfmac_sdio mmc1:0001:1: Direct firmware load for brcm/brcmfmac43241b4-sdio.bin failed with error -2
```

So I changed the kernel to build it as a module, so that I could manually load it after the boot finishes.

I also was having a problem in that my system didn't have the /sys/firmware/efi/efivars directory, so I couldn't follow SiliconFiend's instructions for the nvram file.  But some searching for 'efi' in the kernel config, enabling a few more items, and another kernel rebuild fixed that.  So once that directory was populated, I was able to copy the nvram file.  SiliconFiend- on my machine, I didn't edit out the garbage at the top and the bottom - mainly because I forgot - and it still worked.  So I guess, as you theorized, that step isn't actually necessary.    :Wink: 

After that, I was getting a lot more chatter in dmesg about the card... but it still wasn't functional.   Log messages like this don't ever look good...   :Confused: 

```
[  568.362980] brcmfmac: brcmf_sdio_drivestrengthinit: No SDIO Drive strength init done for chip 4324 rev 5 pmurev 17

[  568.515485] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Jul 17 2013 07:36:07 version 6.10.197.71 (r412987) FWID 01-882d2634

[  568.578419] brcmfmac: brcmf_add_if: ERROR: netdev:wlan0 already exists

[  568.578428] brcmfmac: brcmf_add_if: ignore IF event

[  579.165951] brcmfmac: brcmf_cfg80211_escan: Connecting: status (3)

[  579.165960] brcmfmac: brcmf_cfg80211_scan: scan error (-11)

[  582.002842] brcmfmac: brcmf_cfg80211_escan: Connecting: status (3)

[  582.002851] brcmfmac: brcmf_cfg80211_scan: scan error (-11)

[  591.002493] brcmfmac: brcmf_cfg80211_escan: Connecting: status (3)

[  591.002502] brcmfmac: brcmf_cfg80211_scan: scan error (-11)

[  618.003390] brcmfmac: brcmf_cfg80211_escan: Connecting: status (3)

[  618.003399] brcmfmac: brcmf_cfg80211_scan: scan error (-11)

[  618.424181] brcmfmac: brcmf_cfg80211_escan: Connecting: status (3)

[  618.424190] brcmfmac: brcmf_cfg80211_scan: scan error (-11)

[  699.060427] brcmfmac: brcmf_cfg80211_escan: Connecting: status (3)

[  699.060437] brcmfmac: brcmf_cfg80211_scan: scan error (-11)

[  818.596739] kworker/dying (865) used greatest stack depth: 12736 bytes left

[  942.097899] brcmfmac: brcmf_cfg80211_escan: Connecting: status (3)

[  942.097908] brcmfmac: brcmf_cfg80211_scan: scan error (-11)

[ 1651.400342] ------------[ cut here ]------------

[ 1651.400359] WARNING: CPU: 1 PID: 19 at net/wireless/sme.c:655 __cfg80211_connect_result+0x3e6/0x430()

[ 1651.400363] Modules linked in: brcmfmac brcmutil iosf_mbi [last unloaded: brcmutil]

[ 1651.400377] CPU: 1 PID: 19 Comm: kworker/u4:1 Not tainted 3.17.7-gentoo #10

[ 1651.400381] Hardware name: ECS BAT-MINI/BAT-MINI, BIOS 5.6.5 07/28/2014

[ 1651.400387] Workqueue: cfg80211 cfg80211_event_work

[ 1651.400392]  0000000000000009 ffff880074a53cb8 ffffffff817bbeab 0000000000000000

[ 1651.400399]  ffff880074a53cf0 ffffffff81042d28 0000000000000000 0000000000000000

[ 1651.400405]  ffff8800736f9618 ffff88006d87c008 ffff88006d87b000 ffff880074a53d00

[ 1651.400412] Call Trace:

[ 1651.400424]  [<ffffffff817bbeab>] dump_stack+0x4e/0x7a

[ 1651.400431]  [<ffffffff81042d28>] warn_slowpath_common+0x78/0xa0

[ 1651.400438]  [<ffffffff81042e05>] warn_slowpath_null+0x15/0x20

[ 1651.400444]  [<ffffffff8174f3c6>] __cfg80211_connect_result+0x3e6/0x430

[ 1651.400452]  [<ffffffff8172b703>] cfg80211_process_wdev_events+0x153/0x1d0

[ 1651.400459]  [<ffffffff8172b7b0>] cfg80211_process_rdev_events+0x30/0x70

[ 1651.400465]  [<ffffffff81726879>] cfg80211_event_work+0x19/0x30

[ 1651.400473]  [<ffffffff81057eaa>] process_one_work+0x14a/0x410

[ 1651.400480]  [<ffffffff81058289>] worker_thread+0x119/0x490

[ 1651.400487]  [<ffffffff81058170>] ? process_one_work+0x410/0x410

[ 1651.400493]  [<ffffffff8105cdf4>] kthread+0xc4/0xe0

[ 1651.400500]  [<ffffffff8105cd30>] ? kthread_create_on_node+0x170/0x170

[ 1651.400507]  [<ffffffff817c48ec>] ret_from_fork+0x7c/0xb0

[ 1651.400514]  [<ffffffff8105cd30>] ? kthread_create_on_node+0x170/0x170

[ 1651.400533] ---[ end trace aed6e9438e39ea2b ]---

[ 1651.403306] brcmfmac: brcmf_cfg80211_del_key: invalid key index (4)

[ 1651.403313] brcmfmac: brcmf_cfg80211_del_key: invalid key index (5)
```

More Google searching led me to this Bugzilla entry:

https://bugzilla.kernel.org/show_bug.cgi?id=88061

 *Quote:*   

> Kernel Bug Tracker – Bug 88061
> 
> Summary: brcmfmac lacks proper runtime-pm support 
> 
> Status: NEW 
> ...

 

Bummer!  But at least the discussion details a temporary workaround.

I tried those recommendations, and am still seeing the "ERROR: netdev:wlan0 already exists" errors, but apparently those aren't serious or are recoverable, as it will still works in that condition?    :Question: 

So anyway, to wrap it all up, I compiled the wireless driver as a module, and then after logging in, I manually run this simple script:

```
rmmod brcmfmac

rmmod brcmutil

echo on > /sys/bus/platform/drivers/sdhci-acpi/INT33BB\:00/power/control

modprobe brcmfmac

```

It would be great if this was automated, but for now, this will work.     :Wink: 

//edit:  Almost forgot - I've run this for three or four hours now, streaming HD content from a separate backend...  and I haven't experienced any dropouts or other issues with the wireless connection.   So I bet your issue is just the location / signal strength.    :Wink: 

----------

## SiliconFiend

 *WD-40 wrote:*   

> 
> 
> I had a few different problems with it...  I'm not 100% sure, but I *think* it was having the same problem as the eMMC in that it was being loaded too early (before the eMMC in fact), and because of that, it wasn't able to read the firmware file at boot time?   This was the error I was receiving:  (posted for the search engines to find)
> 
> ```
> ...

 Yeah, I compiled mine as a module from the start. For devices that need firmware loaded, that seems to be the most straightforward way to make it work easily.

 *WD-40 wrote:*   

> I also was having a problem in that my system didn't have the /sys/firmware/efi/efivars directory, so I couldn't follow SiliconFiend's instructions for the nvram file.  But some searching for 'efi' in the kernel config, enabling a few more items, and another kernel rebuild fixed that.  So once that directory was populated, I was able to copy the nvram file.  SiliconFiend- on my machine, I didn't edit out the garbage at the top and the bottom - mainly because I forgot - and it still worked.  So I guess, as you theorized, that step isn't actually necessary.   
> 
> 

 Sorry, I forgot to mention I enabled efivars (I think that was one of the modules that was loaded by the boot USB so I just enabled it in the kernel config)

 *WD-40 wrote:*   

>  *Quote:*   Kernel Bug Tracker – Bug 88061
> 
> Summary: brcmfmac lacks proper runtime-pm support 
> 
> Status: NEW 
> ...

 Yeah, I forgot to mention I left out power management in the kernel config because I saw a note on a mailing list that power management was leading to unstable signal, so I disabled it for the card. But hey, the whole system is ~5 watts so it's hardly a power hog.

 *WD-40 wrote:*   

> So anyway, to wrap it all up, I compiled the wireless driver as a module, and then after logging in, I manually run this simple script:
> 
> ```
> rmmod brcmfmac
> 
> ...

 Hmm... I didn't need to do any of that stuff. The WiFi just works as a module. Maybe if you tried disabling the power management in the kernel config for brcmfmac, that might solve the problem? I can't find the kernel config option right now. I swear I thought it was a suboption of the brcmfmac driver but it doesn't seem to be there. If I find it I'll let you know.

 *WD-40 wrote:*   

> //edit:  Almost forgot - I've run this for three or four hours now, streaming HD content from a separate backend...  and I haven't experienced any dropouts or other issues with the wireless connection.   So I bet your issue is just the location / signal strength.   

 Nice! I think you're right, but tomorrow I'll finish my CAT6 install and turn my attention to making this device an access point for the back of the house.

----------

## WD-40

 *SiliconFiend wrote:*   

> Sorry, I forgot to mention I enabled efivars (I think that was one of the modules that was loaded by the boot USB so I just enabled it in the kernel config)

 

No worries - this is my first efi system, so I didn't quite know what all would be needed.   My usual approach is to start with a completely stripped down minimal kernel - just enough of the mandatory basics to boot, but not much else.  Then I add in more functionality piece-by-piece to make things work, so that I end up with the smallest and leanest kernel possible.    :Cool:      It takes a lot longer to do it that way, but I go years and years and years without hardware changes on my myth boxes, so kernel updates are a snap with 'make oldconfig'.

 *SiliconFiend wrote:*   

> Yeah, I forgot to mention I left out power management in the kernel config because I saw a note on a mailing list that power management was leading to unstable signal, so I disabled it for the card. But hey, the whole system is ~5 watts so it's hardly a power hog.

 

 *SiliconFiend wrote:*   

> Hmm... I didn't need to do any of that stuff. The WiFi just works as a module. Maybe if you tried disabling the power management in the kernel config for brcmfmac, that might solve the problem? I can't find the kernel config option right now. I swear I thought it was a suboption of the brcmfmac driver but it doesn't seem to be there. If I find it I'll let you know.

 

Let me know if you find it - I looked, but didn't find anything myself that was specific for the wireless...

I initially didn't have any of the power management items enabled, but then I noticed that - as expected - the CPU cores were not clocking down when idle.   These newer chips do some dynamic clocking and thermal balancing between the CPU/CPU/GPU, so I believe there is a possibility - especially with a small heatsink passive cooler - that you could actually lower the overall system performance if power management is completely disabled?   

Another thing I noticed when experimenting with the power management was that enabling the agressive power management for the audio chipset is a definite bad idea if you're using the LIVA's analog output instead of the HDMI digital audio.  The audio chip makes several loud "pops" as part of waking up, which is quite objectionable when starting/stopping programs on the myth front end.    :Sad: 

Now that I have things getting closer to being fully functional, I was able to remove my USB hub and the memory sticks, and run with just the keyboard and mouse plugged in.  I hooked up my P4400 Kill-A-Watt meter and got these results:   

Idle at console: 1 watt    :Exclamation: 

Idle in X: 1 watt   :Exclamation: 

Idle at MythFrontend menu screen: still 1 watt!    :Shocked:   :Shocked: 

vaapi playback of 720p/60 MPEG2 content: 6 watts

vaapi playback of 1080p/30 MPEG2 content: 5 watts

I then repeated the test with all of the possible additional power saving options temporarily enabled (using Intel PowerTop), and got the following:

Idle at console: zero watts!   :Shocked: 

Idle in X: zero watts!  

Idle at MythFrontend menu screen: still zero watts!    :Shocked:   :Shocked:   :Shocked: 

vaapi playback of 720p/60 MPEG2 content: 5 watts

vaapi playback of 1080p/30 MPEG2 content: 5 watts

(All of this with wifi connected, and a 1920x1080 monitor, tested with both VGA and HDMI connections with identical results.)

I'm absolutely floored by this.   My other combined FE/BE machine is an ultra-low-power 1037U system, and with a lot of tuning I had it down to an 8 watt idle and I think I could push it up to ~32 watts if I had *everything* running full tilt (triple tuners, 6x multirec recordings while playing back HD content, etc).   This little ECS LIVA uses, what, a sixth of the power at load, and so little at idle (<1 watt?) that my meter can't even measure it accurately?    :Shocked:    It's just absolutely incredible.    :Shocked: 

I'm planning on evaluating this one as another combined backend/frontend machine, so I'll have to see how the power usage changes once I have the drives, tuners, IR receiver, etc all connected.  I'm also going to borrow my father's P4400.01 here pretty soon and give it another check.  The older P4400 Kill-A-Watt meters only measure in full watts, but the newer ones will give tenths of a watt.   Beyond that, I'll probably have to use a different meter on the DC USB side of the power adapter to get a more accurate measurement.

----------

## NeddySeagoon

WD-40,

 *Quote:*   

> 
> 
> ```
> rmmod brcmfmac
> 
> ...

 

Thats what /etc/local.d is for.  See the README

----------

## SiliconFiend

 *WD-40 wrote:*   

> No worries - this is my first efi system, so I didn't quite know what all would be needed.   My usual approach is to start with a completely stripped down minimal kernel - just enough of the mandatory basics to boot, but not much else.  Then I add in more functionality piece-by-piece to make things work, so that I end up with the smallest and leanest kernel possible.        It takes a lot longer to do it that way, but I go years and years and years without hardware changes on my myth boxes, so kernel updates are a snap with 'make oldconfig'.

 Yep, I do the same thing. And since my first MythTV build in 2005 I've never reinstalled the OS, just do daily updates. Even with a new motherboard and new storage, I kept the same install. I love Gentoo for that. 

 *WD-40 wrote:*   

>  *SiliconFiend wrote:*   Hmm... I didn't need to do any of that stuff. The WiFi just works as a module. Maybe if you tried disabling the power management in the kernel config for brcmfmac, that might solve the problem? I can't find the kernel config option right now. I swear I thought it was a suboption of the brcmfmac driver but it doesn't seem to be there. If I find it I'll let you know. 
> 
> Let me know if you find it - I looked, but didn't find anything myself that was specific for the wireless...
> 
> I initially didn't have any of the power management items enabled, but then I noticed that - as expected - the CPU cores were not clocking down when idle.   These newer chips do some dynamic clocking and thermal balancing between the CPU/CPU/GPU, so I believe there is a possibility - especially with a small heatsink passive cooler - that you could actually lower the overall system performance if power management is completely disabled?   
> ...

 I'm sorry, but I've searched high and low and I can't find the kernel option or the mailing list post that discussed it. It was somebody complaining about an unstable connection and the recommendation was to disable power management for that chip. I don't have all power management disabled, just the WiFi (I think!). I would attach my kernel config for you to compare, but this forum doesn't seem to support attachments. I can put it in a Dropbox or something if you want to see it.

 *WD-40 wrote:*   

> Another thing I noticed when experimenting with the power management was that enabling the agressive power management for the audio chipset is a definite bad idea if you're using the LIVA's analog output instead of the HDMI digital audio.  The audio chip makes several loud "pops" as part of waking up, which is quite objectionable when starting/stopping programs on the myth front end.   

 I'm using an HDMI-to-composite (and stereo) converter so no problem there, but thanks for the tip.

 *WD-40 wrote:*   

> Now that I have things getting closer to being fully functional, I was able to remove my USB hub and the memory sticks, and run with just the keyboard and mouse plugged in.  I hooked up my P4400 Kill-A-Watt meter and got these results:   
> 
> Idle at console: 1 watt   
> 
> Idle in X: 1 watt  
> ...

  That is pretty darned amazing. As I mentioned on the MythTV list, I think this is the cheap, (very!) low power, fully capable remote Myth frontend we've all been waiting for.

 *WD-40 wrote:*   

> I'm planning on evaluating this one as another combined backend/frontend machine, so I'll have to see how the power usage changes once I have the drives, tuners, IR receiver, etc all connected.  I'm also going to borrow my father's P4400.01 here pretty soon and give it another check.  The older P4400 Kill-A-Watt meters only measure in full watts, but the newer ones will give tenths of a watt.   Beyond that, I'll probably have to use a different meter on the DC USB side of the power adapter to get a more accurate measurement.

 That would be interesting to see, but it's really pretty academic at this point. I mean even if it was 5 W idle that would still be amazing.

I've made some further progress on the networking and now it's set up the way I want it, but that warrants another post by itself, so...

----------

## WD-40

 *NeddySeagoon wrote:*   

> WD-40, *Quote:*   
> 
> ```
> rmmod brcmfmac
> 
> ...

 

Thanks for the tip.    :Cool:     You would think I would/should know that after more than a decade using Gentoo...    :Embarassed: 

I tried adding my script as a local.d item...  but after doing that, I had no network on boot, and worse, connmanctl would segfault immediately when launching.  My theory was that there was some sort of race condition between the two during the boot stage, so I made sure that rc_parallel was explicitly disabled in /etc/rc.conf, and added a ten second sleep statement at the beginning of my local.d wifi script.  This seems to have done the trick, but I'm not very happy with it.   :Confused:    I think the real solution is to prevent the wifi from loading at all during the initial boot and then start it from within the local script?

----------

## WD-40

 *SiliconFiend wrote:*   

> Yep, I do the same thing. And since my first MythTV build in 2005 I've never reinstalled the OS, just do daily updates. Even with a new motherboard and new storage, I kept the same install. I love Gentoo for that. 

 

Same here, aside from when I did the 32->64 bit hardware transition.   Gentoo really is perfect for this sort of semi-embedded usage.    :Cool: 

I sometimes miss it, but I'm glad I'm not doing a Stage 1 install on the LIVA here.   :Laughing:   :Laughing: 

 *SiliconFiend wrote:*   

> I'm sorry, but I've searched high and low and I can't find the kernel option or the mailing list post that discussed it. It was somebody complaining about an unstable connection and the recommendation was to disable power management for that chip. I don't have all power management disabled, just the WiFi (I think!). I would attach my kernel config for you to compare, but this forum doesn't seem to support attachments. I can put it in a Dropbox or something if you want to see it.

 

No worries, I'll just keep chugging along with this.   Thanks for looking though!    :Wink: 

 *SiliconFiend wrote:*   

>  *WD-40 wrote:*   I'm planning on evaluating this one as another combined backend/frontend machine, so I'll have to see how the power usage changes once I have the drives, tuners, IR receiver, etc all connected.  I'm also going to borrow my father's P4400.01 here pretty soon and give it another check.  The older P4400 Kill-A-Watt meters only measure in full watts, but the newer ones will give tenths of a watt.   Beyond that, I'll probably have to use a different meter on the DC USB side of the power adapter to get a more accurate measurement. That would be interesting to see, but it's really pretty academic at this point. I mean even if it was 5 W idle that would still be amazing.

 

Mostly academic for me.   :Wink:     Since I'm building a FE/BE combo, my end goal is to discard the original power brick and power the whole thing off of a separate dedicated 5V power supply that has an integrated battery backup.  Technically it would still be a "UPS", but not a traditional relay-switched inefficient monster on the 110V AC side, but rather something dedicated and highly efficient on the 5V DC side.    Our area has frequent brownouts and short-duration power outages in the summer, so something as insignificant as dropping from 5 to 4 watts actually corresponds to either a 20% runtime extension on battery power, or the ability to get by with a battery 80% of the size for the same runtime.    :Cool: 

----------

## WD-40

Ok, here's a puzzle I could use some help with.   :Confused: 

For my wireless network, I ended up with this configuration:

 brcmfmac and brcmfmac_sdio built as modules in the kernel

 firmware and nvram set up as instructed earlier

 ConnMan to manage the wireless connection.  (https://01.org/connman)

(With the connman agent activated and my desired wireless access point configured manually through connmanctl.)

 runtime_pm power management enabled in the kernel

 Using 'echo on > /sys/bus/platform/drivers/sdhci-acpi/INT33BB\:00/power/control' to disable power saving on the Broadcom card.  

(Referenece Broadcom kernel driver power management bug: https://bugzilla.kernel.org/show_bug.cgi?id=88061)

 Ensured that Broadcom modules are NOT loaded during the regular/automatic part of the kernel boot, either directly or as a dependency of another system.  

This involved:

```
rc-update del connman default

rc-update del netmount default

rc-update del dbus default

rc-update del net.eth0 default
```

as well as adding a new file /etc/modprobe.d/LIVA_WiFi.conf, which has the lines:

```
# Do not load the ECS LIVA Broadcom wifi modules at boot.

blacklist brcmfmac

blacklist brcmutil
```

 Added two new scripts in /etc/local.d/

/etc/local.d/LIVA_WiFi.start:

```
#!/bin/sh

logger LIVA WiFi: Starting...

echo LIVA WiFi: Starting...

logger LIVA WiFi: Removing existing Broadcom kernel modules...

echo LIVA WiFi: Removing existing Broadcom kernel modules...

rmmod brcmfmac

rmmod brcmutil

# Note: D-Bus is required for ConnMan, but not necessarily for anything else.

# Therefore, it is best to leave it out of the 'default' rc runlevel, and start

# it here manually instead.

logger LIVA WiFi: Starting D-Bus...

echo LIVA WiFi: Starting D-Bus...

/etc/init.d/dbus start

logger LIVA WiFi: Activating Broadcom kernel modules with Power Management patch...

echo LIVA WiFi: Activating Broadcom kernel modules with Power Management patch...

echo on > /sys/bus/platform/drivers/sdhci-acpi/INT33BB\:00/power/control

modprobe brcmfmac

logger LIVA WiFi: Starting ConnMan...

echo LIVA WiFi: Starting ConnMan...

/etc/init.d/connman start

logger LIVA WiFi: Started.

echo LIVA WiFi: Started.
```

/etc/local.d/LIVA_WiFi.stop:

```
#!/bin/sh

logger LIVA WiFi: Stopping...

echo LIVA WiFi: Stopping...

# Note: Comment out this section if you are using ConnMan for other interfaces (ethernet, alternate WiFi, etc).

logger LIVA WiFi: Stopping ConnMan...

echo LIVA WiFi: Stopping ConnMan...

/etc/init.d/connman stop

logger LIVA WiFi: Removing Broadcom kernel modules...

echo LIVA WiFi: Removing Broadcom kernel modules...

rmmod brcmfmac

rmmod brcmutil

# Note: D-Bus is started in the 'start' script, but not stopped here as other items may be using it.

logger LIVA WiFi: Stopped.

echo LIVA WiFi: Stopped.

```

... and activated those with 'rc-update add local default'.

This, in general, works perfectly.   The boot speed is substantially faster than before (with my script with the ten second sleep statement to avoid the race condition), there is no unnecessary module loading/unloading before the power management parameter has been changed, it works reliably every time on a cold boot or warm reboot, it is completely automatic, it can be stopped and re-started manually once booted, and a 'start' when already started is OK.  That sounds like it meets all of the criteria, right??

The problem...  It fails if I have a USB stick inserted!  :Confused: 

USB stick not in at boot?  Works great.

USB stick installed at boot?  It "connects", gets an IP address, and fills in the routing table, but acts like zero network traffic can be routed. (no DNS resolution either.)

USB stick installed at boot, wifi failure, USB stick removed, and then the scripts re-run?  Connects and works OK!

USB stick not in at boot, wifi works OK, then connection stopped, USB stick added, and a reconnect attempt with scripts?  Doesn't work (same symptoms as above)

Any thoughts?   :Question: 

I should also add - the USB stick, along with my keyboard and mouse, are connected through a powered USB 3.0 hub on the USB 3.0 port on the LIVA.  It's a 7-port Anker hub, which identifies itself to Linux as two 'Asmedia ASM107x' 4-port hubs, so the 'second' hub must be internally connected to the fourth port of the 'first'.   The USB stick is a USB 3.0 16GB SanDisk 'Ultra Fit' (the tiny one).

----------

## SiliconFiend

I'm sorry I don't have any answers to your strange puzzle... But I did want to add a couple notes here. First, I wrote up my updated network config (turned the Liva into a remote access point) here: https://forums.gentoo.org/viewtopic-p-7673376.html. Second, I think the wireless problems I was having were not really the issue. The symptom I was seeing was that X would start, and mythtv would start, I would see the blue screen of the myth theme, but then it would exit out and X would end (I have it set up so that X exits and restarts when mythfrontend exits). I assumed it was a network problem which was causing myth to exit, because occasionally I would get the "new configuration" screen on myth when it couldn't find the backend because the network was too spotty. However, when I changed it to start xterm instead of mythfrontend directly I discovered that myth was triggering a segfault in the intel X video drivers. I just updated to the most recent unstable xf86-video-intel drivers and that seems to have solved the problem.

----------

## WD-40

 *WD-40 wrote:*   

> The problem...  It fails if I have a USB stick inserted! 
> 
> USB stick not in at boot?  Works great.
> 
> USB stick installed at boot?  It "connects", gets an IP address, and fills in the routing table, but acts like zero network traffic can be routed. (no DNS resolution either.)
> ...

 

A bit more info:

I opened two xterm windows, one with 'ping google.com' running continuously, the other with 'tail -f /var/log/messages' running continuously, and found some interesting results:

 If the wifi is connected (pings going through OK) and I plug in the flash drives, the pinging halts immediately.  Unplug the flash drive and it resumes.   

(So the problem isn't related to the presence of the flash drive during the wifi initialization, and the wifi doesn't have to be restarted manually after the flash drive is removed.)

 The kernel logs during this time look completely normal - almost identical to what I see when I plug in a USB 2.0 flash drive, which doesn't halt the network.

 There are no network, connman, or broadcom related messages printed to the kernel log - only the regular usb/usb-storage/sd/scsi messages.

 This behavior only happens when everything in the chain is USB 3.0.   

If I plug the USB 3.0 flash stick into the USB 2.0 port on the LIVA, everything is fine.  

If I plug the USB 3.0 flash stick into the USB 3.0 hub and plug that into the USB 2.0 port on the LIVA, everything is fine.

If I plug the USB 3.0 flash stick into the USB 3.0 port on the LIVA, that is also fine!

However, USB 3.0 flash stick + USB 3.0 hub + USB 3.0 port on the LIVA = problems!

Not sure what this means yet, other than that I have some more digging to do.    :Sad: 

----------

## WD-40

 *SiliconFiend wrote:*   

> I assumed it was a network problem which was causing myth to exit, because occasionally I would get the "new configuration" screen on myth when it couldn't find the backend because the network was too spotty. However, when I changed it to start xterm instead of mythfrontend directly I discovered that myth was triggering a segfault in the intel X video drivers. I just updated to the most recent unstable xf86-video-intel drivers and that seems to have solved the problem.

 

I've been having that problem too.   :Sad:     Running MythTV in a window seemed to *really* aggrevate it, so much so that I couldn't even start the frontend again to change back to fullscreen.  Luckily I was able to run 'mythfrontend -reset' and go back to the defaults, which was a fullscreen configuration.

Can you try something for me?   On my machine, I can reliably crash X if I launch glxgears.  It just dumps me straight to the console with a stack trace that goes through the intel drivers.    :Sad:    It's instant, and repeatable 100% of the time.  Does it do the same for you?

Versions I'm running:

```
# emerge -pv intel-gpu-tools xf86-video-intel libva-intel-driver libva

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild   R    ] x11-drivers/xf86-video-intel-2.21.15  USE="dri sna udev -glamor -uxa -xvmc" 1,932 KiB

[ebuild   R    ] x11-apps/intel-gpu-tools-1.3  VIDEO_CARDS="-nouveau" 576 KiB

[ebuild   R    ] x11-libs/libva-1.3.1  USE="X drm opengl -egl -vdpau -wayland" VIDEO_CARDS="intel -dummy -fglrx -nvidia" 743 KiB

[ebuild   R    ] x11-libs/libva-intel-driver-1.3.0  USE="X drm -wayland" 943 KiB

Total: 4 packages (4 reinstalls), Size of downloads: 4,192 KiB
```

... and for completeness, the latest versions available:

```
# ACCEPT_KEYWORDS="~amd64" emerge -pv intel-gpu-tools xf86-video-intel libva-intel-driver libva

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild     U  ] x11-drivers/xf86-video-intel-2.99.916 [2.21.15] USE="dri sna udev -debug% -glamor -uxa -xvmc" 2,190 KiB

[ebuild     U  ] x11-apps/intel-gpu-tools-1.7 [1.3] USE="-python%" PYTHON_SINGLE_TARGET="-python3_3% -python3_4%" PYTHON_TARGETS="python3_3%* -python3_4%" VIDEO_CARDS="-nouveau" 11,505 KiB

[ebuild     U  ] x11-libs/libva-1.4.1 [1.3.1] USE="X drm opengl -egl -vdpau -wayland" VIDEO_CARDS="intel -dummy -fglrx -nvidia" 744 KiB

[ebuild     U  ] x11-libs/libva-intel-driver-1.4.1 [1.3.0] USE="X drm -wayland" 958 KiB

Total: 4 packages (4 upgrades), Size of downloads: 15,395 KiB
```

----------

## SiliconFiend

 *WD-40 wrote:*   

> Can you try something for me?   On my machine, I can reliably crash X if I launch glxgears.  It just dumps me straight to the console with a stack trace that goes through the intel drivers.      It's instant, and repeatable 100% of the time.  Does it do the same for you?
> 
> 

 No, sorry, glxgears runs fine here. Here are my package versions (I don't have intel-gpu-tools installed):

```
$ emerge -pv intel-gpu-tools xf86-video-intel libva-intel-driver libva mesa

These are the packages that would be merged, in order:

Calculating dependencies                     ... done!

[ebuild   R    ] media-libs/mesa-10.2.8  USE="classic dri3 egl gallium gbm llvm nptl udev xvmc -bindist -debug -gles1 -gles2 -opencl -openmax -openvg -osmesa -pax_kernel -pic -r600-llvm-compiler (-selinux) -vdpau -wayland -xa" ABI_X86="(64) (-32) (-x32)" VIDEO_CARDS="i915 i965 intel (-freedreno) -ilo -nouveau -r100 -r200 -r300 -r600 -radeon -radeonsi -vmware" 0 KiB

[ebuild   R   ~] x11-drivers/xf86-video-intel-2.99.916  USE="dri sna udev xvmc -debug -glamor -uxa" 0 KiB

[ebuild  N     ] x11-libs/cairo-1.12.16  USE="X glib opengl svg (-aqua) -debug (-directfb) -doc (-drm) (-gallium) (-gles2) -legacy-drivers -openvg (-qt4) -static-libs -valgrind -xcb -xlib-xcb" 35,049 KiB

[ebuild  N     ] x11-apps/intel-gpu-tools-1.3  VIDEO_CARDS="-nouveau" 576 KiB

[ebuild   R    ] x11-libs/libva-1.3.1  USE="X drm opengl -egl -vdpau -wayland" ABI_X86="(64) (-32) (-x32)" VIDEO_CARDS="intel -dummy -fglrx -nvidia" 0 KiB

[ebuild   R    ] x11-libs/libva-intel-driver-1.3.0  USE="X drm -wayland" ABI_X86="(64) (-32) (-x32)" 0 KiB

Total: 6 packages (2 new, 4 reinstalls), Size of downloads: 35,624 KiB
```

I put my kernel config in a DropBox here: https://dl.dropboxusercontent.com/u/6715292/ECS%20Liva%203.17.7-gentoo.config It's not 100% the way I want it (I just noticed an IOMMU config issue I need to sort out) but it works for me. It would be worthwhile to do a diff to your config and see where the differences are.

Karl

----------

## WD-40

 *SiliconFiend wrote:*   

> No, sorry, glxgears runs fine here. Here are my package versions (I don't have intel-gpu-tools installed):

 

Good to know.  I took a look at the change log for xf86-video-intel:

http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/NEWS

and there were a HUGE number of fixes between 2.21.15 and 2.99.916.   I set the "~amd64" keyword for intel-gpu-tools, libva, libva-intel-driver, and xf86-video-intel, and after rebuilding those, the crashes are gone.    :Very Happy: 

 *SiliconFiend wrote:*   

> I put my kernel config in a DropBox here: https://dl.dropboxusercontent.com/u/6715292/ECS%20Liva%203.17.7-gentoo.config It's not 100% the way I want it (I just noticed an IOMMU config issue I need to sort out) but it works for me. It would be worthwhile to do a diff to your config and see where the differences are.

 

Thanks!  I did a quick diff between our configs, and the result was enormous.   :Shocked:    I'll take another look at it later, and try to do the diff on just the options we have enabled with the rest filtered out, so that the output is more meaningful.    :Wink: 

By the way, I pulled the LIVA off my desk and it has been up and running for two days now at the TV.  Frontend/Backend combo with three USB tuners, IR receiver with LIRC, audio, wireless, AirPlay, auto-launching, etc.   After working through the system/hardware issues, I restored my database backup, put my old recordings drive in an external enclosure, re-configured Myth, and everything is working fantastic.    :Cool:      There's a spaghetti pile of wires and boxes I need to tidy up, but other than that, this thing is just perfect for the job.    

I could be wrong, but I think I'm the first person to use one of these as a FE/BE combo?   I set the bar low and was going to be OK if it wasn't up to the task...  but nope! Its working great!    :Very Happy: 

I still have that USB 3.0 issue to resolve...  For now, I connected the hard drive directly to the LIVA's USB 3.0 port, and put everything else on that same USB 3.0 hub but plugged that into the LIVA's USB 2.0 port so that it runs at the lower speed.  I'm not completely happy with it, particularly since I wanted the USB 3.0 hard drive to be downwind of a powered hub instead of being powered from the LIVA's USB port... but this is good enough for now.   :Wink: 

----------

## davidbrooke

 *SiliconFiend wrote:*   

> From power-on to X starting is about 20 seconds. I had to add a 10 second delay before starting mythfrontend because it was coming up before the wireless card got an address, which put myth into "new config" mode.

 

Please give more detail as to how you created and implemented your "10 second delay"

Thanks

----------

## SiliconFiend

 *davidbrooke wrote:*   

>  *SiliconFiend wrote:*   From power-on to X starting is about 20 seconds. I had to add a 10 second delay before starting mythfrontend because it was coming up before the wireless card got an address, which put myth into "new config" mode. 
> 
> Please give more detail as to how you created and implemented your "10 second delay"
> 
> Thanks

 

I'm not really using this any longer since I have the CAT6 Ethernet connected and don't have to wait for the wireless, but it's just a "sleep 10" at an appropriate spot, either in the script that runs on autologin to start X (~/.bash_profile in my case), or maybe in your ~/.xinitrc

For example, here's my ~/.xinitrc

```

# .xinitrc

[ -x /usr/bin/nvidia-settings ] && /usr/bin/nvidia-settings -l

#/usr/bin/xset s noblank

#/usr/bin/xset s off

#/usr/bin/xset -dpms

# I want the screen to blank after 2 minutes

/usr/bin/xset dpms 120 240 300

/usr/bin/evilwm &

/usr/bin/xhost +local:

#/usr/bin/xterm

# You may want to add the delay here (just uncomment the next line)

#sleep 10

# Configure arguments via /etc/conf.d/mythfrontend

exec /usr/bin/mythfrontend

```

----------

## jamtat

I've gotten a Liva X that I'm hoping to turn into a Mythtv FE/BE. I've communicated a bit with one of the posters in this thread on the Mythtv mailing list--which is how I found this thread. If I end up putting Gentoo on this thing, I'll need to make a lot of recourse to this thread; although I did run Gentoo for a short time about a decade ago, a Gentoo-using friend actually did the initial installation for me--all I did was administer the system for a few months. So I'm really quite inexperienced with Gentoo. So I'll probably end up making a separate thread in some newbie forum on here and post in this one with Liva-specific or Mythtv-specific questions.

I think I'll download the kernel config that was posted here since I've had very scant experience with compling kernels. Was a more detailed diff between the configs of the kernels the two main posters in this thread ever done? Also, I'm not entirely sure those configs will suit this hardware: are there hardware differences, other than more RAM and eMMC space, between the Liva X and the earlier Liva's?

Finally, I see from SiliconFiend's most recent post that he appears to be running evilwm as the WM for his Mythtv, correct? I was just today wondering what might be the most minimalist WM one could use with Mythtv. I used to run evilwm on one of my computers before switching over to i3, so that was definitely one of the minimalist WM's I was considering.

Thanks in advance for any input on my project.

----------

## SiliconFiend

 *jamtat wrote:*   

> I think I'll download the kernel config that was posted here since I've had very scant experience with compling kernels. Was a more detailed diff between the configs of the kernels the two main posters in this thread ever done? Also, I'm not entirely sure those configs will suit this hardware: are there hardware differences, other than more RAM and eMMC space, between the Liva X and the earlier Liva's?

 

As I understand it, there are notable differences with the Liva X. Not sure what exactly but some people have reported problems with, for example, HDMI audio on the X where the original was okay. Not sure the original kernel config will work for you. But it might be a good starting point; you'd just have to find out what additional drivers you might need.

 *jamtat wrote:*   

> Finally, I see from SiliconFiend's most recent post that he appears to be running evilwm as the WM for his Mythtv, correct? I was just today wondering what might be the most minimalist WM one could use with Mythtv. I used to run evilwm on one of my computers before switching over to i3, so that was definitely one of the minimalist WM's I was considering.

 

evilwm is installed by default with MythTV on Gentoo. I've never had a problem with it, but my MythTV machines are dedicated to that purpose (i.e., no desktop usage). It's pretty lightweight. My evilwm shows VmSize:    58588 kB  I've also heard ratpoison recommended for a lightweight WM.

----------

## jamtat

 *SiliconFiend wrote:*   

> As I understand it, there are notable differences with the Liva X. Not sure what exactly but some people have reported problems with, for example, HDMI audio on the X where the original was okay. Not sure the original kernel config will work for you. But it might be a good starting point; you'd just have to find out what additional drivers you might need.

 

For what it's worth, I've so far booted this thing successfully with the Bodhi live iso and everything worked: sound (through the analog port--I won't be using audio through HDMI), wifi, and video all worked without a hitch from within Bodhi. I actually did an lshw and saved the output, but it's too extensive to post here (should've used the -short switch). I may boot that distro again and post shorter output.

 *Quote:*   

> evilwm is installed by default with MythTV on Gentoo. I've never had a problem with it, but my MythTV machines are dedicated to that purpose (i.e., no desktop usage). . .  I've also heard ratpoison recommended for a lightweight WM.

 

evilwm is fine by me since I'm already familiar with it. Not sure ratpoison would afford that much less overhead. Thanks for your input.

----------

## jamtat

Here's some output I get when booted into Bodi on the Liva X:

```
lshw -short

H/W path         Device    Class       Description

==================================================

                           system      LIVA-XBAT2NBW-64 (To be filled by O.E.M.)

/0                         bus         BAT-MINI2

/0/0                       memory      64KiB BIOS

/0/28                      memory      4GiB System Memory

/0/28/0                    memory      4GiB DIMM DDR3 1600 MHz (0.6 ns)

/0/30                      memory      112KiB L1 cache

/0/31                      memory      1MiB L2 cache

/0/32                      processor   Intel(R) Celeron(R) CPU  N2808  @ 1.58GHz

/0/100                     bridge      ValleyView SSA-CUnit

/0/100/2                   display     ValleyView Gen7

/0/100/13                  storage     ValleyView 6-Port SATA AHCI Controller

/0/100/14                  bus         ValleyView USB xHCI Host Controller

/0/100/17                  generic     ValleyView MIPI-HSI Controller

/0/100/1a                  generic     ValleyView SEC

/0/100/1b                  multimedia  ValleyView High Definition Audio Controller

/0/100/1c                  bridge      ValleyView PCI Express Root Port

/0/100/1c.1                bridge      ValleyView PCI Express Root Port

/0/100/1c.1/0    wlan0     network     RT3290 Wireless 802.11n 1T/1R PCIe

/0/100/1c.1/0.1            generic     RT3290 Bluetooth

/0/100/1c.2                bridge      ValleyView PCI Express Root Port

/0/100/1c.2/0    p2p1      network     RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller

/0/100/1f                  bridge      ValleyView Power Control Unit

/0/100/1f.3                bus         ValleyView SMBus Controller

/0/1             scsi2     storage     

/0/1/0.0.0       /dev/sda  disk        1048MB SCSI Disk

lsmod=================================================

Module                  Size  Used by

zram                   20081  2 

lz4_compress           12529  1 zram

tda18212               13063  1 

lgdt3305               19271  1 

em28xx_dvb             31985  0 

dvb_core              121659  2 em28xx_dvb,lgdt3305

intel_rapl             18783  0 

arc4                   12608  2 

rt2800pci              13630  0 

rt2800mmio             20986  1 rt2800pci

rt2800lib              89076  2 rt2800pci,rt2800mmio

snd_hda_codec_hdmi     47548  1 

rt2x00pci              13287  1 rt2800pci

intel_powerclamp       18823  0 

rt2x00mmio             13603  2 rt2800pci,rt2800mmio

rt2x00lib              55307  5 rt2x00pci,rt2800lib,rt2800pci,rt2800mmio,rt2x00mmio

coretemp               13441  0 

snd_hda_codec_realtek    72791  1 

snd_hda_codec_generic    68937  1 snd_hda_codec_realtek

em28xx                 84619  1 em28xx_dvb

mac80211              652718  3 rt2x00lib,rt2x00pci,rt2800lib

snd_hda_intel          30428  5 

snd_hda_controller     31056  1 snd_hda_intel

snd_hda_codec         139682  5 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_intel,snd_hda_controller

kvm_intel             143590  0 

kvm                   452043  1 kvm_intel

snd_hwdep              17698  1 snd_hda_codec

snd_pcm               104112  5 snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel,snd_hda_controller

snd_seq_midi           13564  0 

snd_seq_midi_event     14899  1 snd_seq_midi

tveeprom               21216  1 em28xx

snd_rawmidi            30876  1 snd_seq_midi

cfg80211              494330  2 mac80211,rt2x00lib

snd_seq                63074  2 snd_seq_midi_event,snd_seq_midi

v4l2_common            15681  1 em28xx

crct10dif_pclmul       14307  0 

videodev              153793  2 em28xx,v4l2_common

crc32_pclmul           13133  0 

eeprom_93cx6           13344  1 rt2800pci

ghash_clmulni_intel    13230  0 

dm_multipath           22843  0 

cryptd                 20359  1 ghash_clmulni_intel

scsi_dh                14882  1 dm_multipath

joydev                 17393  0 

snd_seq_device         14497  3 snd_seq,snd_rawmidi,snd_seq_midi

crc_ccitt              12707  1 rt2800lib

media                  21903  1 videodev

snd_timer              29562  2 snd_pcm,snd_seq

snd                    79468  20 snd_hda_codec_realtek,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_seq,snd_rawmidi,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel,snd_seq_device

mei_txe                19704  0 

mei                    87875  1 mei_txe

soundcore              15047  2 snd,snd_hda_codec

snd_soc_sst_acpi       13007  0 

lpc_ich                21093  0 

iosf_mbi               13541  0 

mac_hid                13227  0 

parport_pc             32741  0 

ppdev                  17671  0 

lp                     17759  0 

parport                42348  3 lp,ppdev,parport_pc

squashfs               48362  1 

overlayfs              27916  1 

nls_utf8               12557  1 

isofs                  39837  1 

dm_mirror              22135  0 

dm_region_hash         20862  1 dm_mirror

dm_log                 18411  2 dm_region_hash,dm_mirror

hid_generic            12559  0 

usbhid                 52616  0 

hid                   110426  2 hid_generic,usbhid

uas                    23159  0 

usb_storage            66545  2 uas

mmc_block              36056  0 

r8169                  71694  0 

i915                  905798  6 

mii                    13934  1 r8169

i2c_algo_bit           13413  1 i915

video                  20128  1 i915

drm_kms_helper         61574  1 i915

ahci                   34062  0 

drm                   311018  8 i915,drm_kms_helper

libahci                32424  1 ahci

sdhci_pci              23301  0 

sdhci                  43685  1 sdhci_pci

lspci============================

00:00.0 Host bridge: Intel Corporation ValleyView SSA-CUnit (rev 0e)

00:02.0 VGA compatible controller: Intel Corporation ValleyView Gen7 (rev 0e)

00:13.0 SATA controller: Intel Corporation ValleyView 6-Port SATA AHCI Controller (rev 0e)

00:14.0 USB controller: Intel Corporation ValleyView USB xHCI Host Controller (rev 0e)

00:17.0 SD Host controller: Intel Corporation ValleyView MIPI-HSI Controller (rev 0e)

00:1a.0 Encryption controller: Intel Corporation ValleyView SEC (rev 0e)

00:1b.0 Audio device: Intel Corporation ValleyView High Definition Audio Controller (rev 0e)

00:1c.0 PCI bridge: Intel Corporation ValleyView PCI Express Root Port (rev 0e)

00:1c.1 PCI bridge: Intel Corporation ValleyView PCI Express Root Port (rev 0e)

00:1c.2 PCI bridge: Intel Corporation ValleyView PCI Express Root Port (rev 0e)

00:1f.0 ISA bridge: Intel Corporation ValleyView Power Control Unit (rev 0e)

00:1f.3 SMBus: Intel Corporation ValleyView SMBus Controller (rev 0e)

02:00.0 Network controller: Ralink corp. RT3290 Wireless 802.11n 1T/1R PCIe

02:00.1 Bluetooth: Ralink corp. RT3290 Bluetooth

03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c)

```

----------

## SiliconFiend

That's great. The module list in particular will help make sure you have the right kernel config options enabled.

----------

## jamtat

 *SiliconFiend wrote:*   

> That's great. The module list in particular will help make sure you have the right kernel config options enabled.

 

Spot any differences between your hardware and mine? I see the CPU number is different--2807 as opposed to 2808. Looks like the NICs might be different, too: the X seems to have realtek chips in both wired and wifi NICs.

----------

## jamtat

 *jamtat wrote:*   

> the X seems to have realtek chips in both wired and wifi NICs.

 

Make that Realtek for the wired NIC and Ralink 2800 for the wifi. See my new installation help request thread at https://forums.gentoo.org/viewtopic-t-1012756.html if anyone from this thread would care to offer assistance. Thanks.

----------

## jamtat

 *SiliconFiend wrote:*   

> I tried to keep it simple and boot with just a kernel without an initramfs, but I think the eMMC storage wouldn't work . . .

 

This is the problem I'm having: I can't get the non-initramfs kernel to see the eMMC. Nothing I've tried over the last 3 or 4 days has resolved it (see https://forums.gentoo.org/viewtopic-t-1012756.html ). No help has been forthcoming in that thread so far: all posts are by me, except for one.

 *WD-40 wrote:*   

> If it helps any, I found out that an initramfs / dracut is NOT required.   I too like to keep things simple.     The key was that the system was loading too fast for the eMMC to be available in time for the root mount... so the fix was to edit /etc/default/grub, and add "rootdelay=8" to the GRUB_CMDLINE_LINUX_DEFAULT line for default kernel parameters and regenerate the grub config.  After that, the system would pause on boot, the eMMC partitions would populate, and then the booting would resume with the root filesystem mount after the 8 second timeout.       8 seconds was somewhat arbitrary... less may be OK, but I decided to play it safe.

 

I tried the rootdelay= option (tried first 5, then 10 seconds) too. I got the kernel panic (not finding the root file system) with both. Then I tried rootwait, which just pauses forever because the kernel is not finding the eMMC drive--as onscreen output shows. The pause comes right after the kernel finds the second USB drive I have hooked to the device. I should mention that I'm not using GRUB, if that matters. I put the kernel in the fat32 partition that, were the system to actually finish booting, would get mounted under /boot. So the system is booting via UEFI. The boot commands are being passed to the kernel, in my case, via the bult-in kernel command line as follows; root=/dev/mmcblk0p3 rootwait.

Could I ask that that you post your kernel config file on pastebin or some such, WD-40? I've looked over SiliconFiend's and modified in some ways my config accordingly. But since he is using an initramfs, yours, which apparently does not--as I wish to do as well--might prove more decisive in helping me get my system to finally boot.

Thanks

Oh, by the way, my kernel config is posted at http://pastebin.com/tSsmxNRj .

----------

## SiliconFiend

 *jamtat wrote:*   

>  *SiliconFiend wrote:*   I tried to keep it simple and boot with just a kernel without an initramfs, but I think the eMMC storage wouldn't work . . . 
> 
> This is the problem I'm having: I can't get the non-initramfs kernel to see the eMMC. Nothing I've tried over the last 3 or 4 days has resolved it (see https://forums.gentoo.org/viewtopic-t-1012756.html ). No help has been forthcoming in that thread so far: all posts are by me, except for one.
> 
>  *WD-40 wrote:*   If it helps any, I found out that an initramfs / dracut is NOT required.   I too like to keep things simple.     The key was that the system was loading too fast for the eMMC to be available in time for the root mount... so the fix was to edit /etc/default/grub, and add "rootdelay=8" to the GRUB_CMDLINE_LINUX_DEFAULT line for default kernel parameters and regenerate the grub config.  After that, the system would pause on boot, the eMMC partitions would populate, and then the booting would resume with the root filesystem mount after the 8 second timeout.       8 seconds was somewhat arbitrary... less may be OK, but I decided to play it safe. 
> ...

 

Why not just use an initramfs? I would have rather not had one either, but any small deviation from a strict set of rules basically makes it a requirement now. It's really not a big deal to set one up. dracut generally automatically includes all the things you need. If you want to try to run without an initramfs, though, the one tip I would add is to make sure the eMMC driver and any bus drivers, etc. it needs are compiled in to the kernel and not as modules (i.e., * not M).

----------

## jamtat

 *SiliconFiend wrote:*   

> Why not just use an initramfs? I would have rather not had one either, but any small deviation from a strict set of rules basically makes it a requirement now. It's really not a big deal to set one up. dracut generally automatically includes all the things you need. If you want to try to run without an initramfs, though, the one tip I would add is to make sure the eMMC driver and any bus drivers, etc. it needs are compiled in to the kernel and not as modules (i.e., * not M).

 

Thanks for your additional input, SiliconFiend. I've so far thought of 2 possible ways out of my present impasse: one is to try booting the system with GRUB and not using UEFI; the other is to use an initramfs. I have no idea why either of those should work while what I'm presently doing does not, but it's something to try; I see that doing those things has allowed others to come up with a bootable Liva system. 

Here's my point of hesitation regarding the initramfs option. I have tried, through some research and by soliciting input from others (not a lot of which has been forthcoming), to determine what I need to compile into my kernel (as * and not M) to support this hardware. There must be some error in my configuration, since the kernel is not finding the eMMC: but I cannot so far determine where that error lies. So, in offering dracut as a solution, are you saying that it will be able to determine, without input from me, what modules need to be loaded in order for the kernel to find and use the eMMC? If it can do that, it does definitely seem like a way out of the impasse. I will not, if I apply that sort of dracut solution, end up learning what I've done wrong in my kernel compilation. But it can at least allow me to finally be able to boot this system. 

So, is that what dracut does? I.e., does it do detection of all hardware and cause all needed modules to be loaded, independent of user input?

----------

## SiliconFiend

 *jamtat wrote:*   

>  *SiliconFiend wrote:*   Why not just use an initramfs? I would have rather not had one either, but any small deviation from a strict set of rules basically makes it a requirement now. It's really not a big deal to set one up. dracut generally automatically includes all the things you need. If you want to try to run without an initramfs, though, the one tip I would add is to make sure the eMMC driver and any bus drivers, etc. it needs are compiled in to the kernel and not as modules (i.e., * not M). 
> 
> So, is that what dracut does? I.e., does it do detection of all hardware and cause all needed modules to be loaded, independent of user input?

 

No, dracut only generates an initramfs, but it populates it with the modules, config files, etc. that you need to get a bootable system. You still have to have the right drivers configured in the kernel for your hardware. I *think* with an initramfs that it's more flexible about being able to use drivers as loadable modules instead of compiled in to the kernel though. If your boot CD/DVD was able to see the eMMC storage (using a partition editor, etc.), then you just need to look at the loaded modules under that environment for a clue as to what needs to be configured.

----------

## jamtat

 *SiliconFiend wrote:*   

> dracut only generates an initramfs, but it populates it with the modules, config files, etc. that you need to get a bootable system. You still have to have the right drivers configured in the kernel for your hardware. I *think* with an initramfs that it's more flexible about being able to use drivers as loadable modules instead of compiled in to the kernel though. If your boot CD/DVD was able to see the eMMC storage (using a partition editor, etc.), then you just need to look at the loaded modules under that environment for a clue as to what needs to be configured.

 

Thanks for the clarification, SiliconFiend. Yes, my boot media (Bodhi live environment dd'd to a USB flash drive) does see the eMMC, and I can, from within that environment, do disk partitioning and the like on the eMMC. 

Actually, you should be saying "you just need to look yet again at the loaded modules under that environment for a clue as to what needs to be configured."  :Smile:  I've looked at it many, many times. But, given the fact that I'm new at this and that this is relatively new hardware, I may well have overlooked some thing(s). So I'll go over the dmesg/lsmod and other relevant output again while considering the dracut option.

----------

## jamtat

I took a suggestion someone made of changing UEFI settings to Windows 8 in CSM mode, then setting the eMMC as the first boot option. With those settings applied, I've now been able to boot my Gentoo kernel for the first time. I'll have to see whether things continue to work on this thing, but there is at least some progress to report.

----------

## steveL

 *jamtat wrote:*   

> I took a suggestion someone made of changing UEFI settings to Windows 8 in CSM mode, then setting the eMMC as the first boot option. With those settings applied, I've now been able to boot my Gentoo kernel for the first time.

 

Yay :-)

Celebrate while you can. ;-)

----------

## noisome

You guys have a step by step on what worked for you?  Yes, its like asking for hand holding instead of reading, but heck, it would be nice with this box.  :Very Happy: 

----------

## steveL

 *noisome wrote:*   

> You guys have a step by step on what worked for you?  Yes, its like asking for hand holding instead of reading

 

You're clearly about to try it; so whatever notes you do get from others, can I ask you to summarise the process in a step-by-step, either in this thread or a new one (preferably the latter, but we can take it in stages.)

Think of it as backup in case your machine gets fried, and you need to redo the whole thing on a fresh install (from scratch.)

Regards

steveL

----------

## jamtat

 *WD-40 wrote:*   

> But once I had Gentoo installed, I enabled the "TearFree" graphics driver option, and it DID fix tearing, but at a noticeable negative impact to even general purpose non-video usage.

 

I thought I'd read this thread pretty thoroughly. But just now re-reading it, I noted this thing about tearing, which I've been seeing to a minor degree when I view HD content. So I researched a bit further and found a good write-up on the Arch wiki about some modifications one can introduce into xorg.conf to deal with the problem of tearing (see https://wiki.archlinux.org/index.php/Intel_graphics). So I added the file /etc/X11/xorg.conf.d/20-intel.conf with the content 

```
Section "Device"

   Identifier  "Intel Graphics"

   Driver      "intel"

   Option      "TearFree"    "true"

EndSection
```

 I also found a Gentoo forum thread on this that stipulated another line that could be added--Option "AccelMethod" "sna" (https://forums.gentoo.org/viewtopic-p-7279402.html)--so I put that in too. Once I'd killed and restarted X, sure enough, that resolved the tearing problem. So there's another tweak that can be done to imporve the way this hardware renders video.

----------

## jamtat

My system has been up and running for awhile now and is functioning pretty well. There are still a few areas where I'd like to check to make sure I've got everything optimally configured, and one is playback of video. I note that, when I'm playing back an HD video I've recorded, CPU usage runs at between 15% and 20% per CPU. Does that match what others who have installed MythTV on their Liva systems are seeing? I have no experience with vaapi and GPU decoding, so I am uncertain what I should be expecting here. So, should CPU usage be lower that this if all is properly configured for GPU decoding? Or does this sort of CPU usage look about right?

I'll mention in closing that part of the reason I've begun investigating this is because I've had to compile MythTV with -vaapi (though I do have the vaapi option enabled system-wide in make.conf). Introducing -vaapi was the only way I was able to compile MythTV after I'd switched this system to the no-multilib profile. I'm uncertain whether that could be affecting video playback on this system, since MythTV's internal player is, as I understand it, just a modified version of ffmpeg. And ffmpeg compiled fine on this system, without the need for setting -vaapi.

Input will be appreciated.

----------

