Good Evening All,

I have been able to get the 4.4.91 kernel compiled and working for the Novena! This is also with full disk encryption support. Based on this: … r-6-years/

The 4.4 kernel should be in service until 2022, so I wanted to try to get our 4.4 kernel updated for it.

I added a readme here to get it working (along with all of the patches), and am currently working on getting it packaged up for Debian. When it is, I will add it in the github site.

EDIT: See the bottom post, I have updated for 4.4.92

EDIT: When new patches come out, I will just put them at the bottom.

Out of curiosity, are you cross compiling or compiling on the Novena?


(17 replies, posted in Software)

At this time I have been unable to successfully compile the kernel with Full system encryption support. Right now I am trying to compile xobs' kernel from his github page. If I try to compile it with the default novena_defconfig, I still get the "Cannot initialize device-mapper" issue where it complains that dm_mod cannot be found.

I fixed it via the guide I referenced, and the error I know get is:

"dm_crypt: Unkown symbol _GLOBAL_OFFSET_TABLE_ (err 0)"

At this point I am not really sure how to proceed, any help would be appreciated, as I would like to be able to get 4.4.90 to work so we have a recent kernel here (and possibly get 4.12.4 or the current kernel working).

EDIT: I got xobs' kernel to successfully boot with encryption support! I have added the config file here:

The other nice thing I found out is that there is no special hook needed in the initramfs-tools with this config. I think the default kernel did not have the correct configuration needed in order to get it to work right, hence the hacks for it in "Novena-debian-support". The strange thing is if I made some of the options above modules instead of compiling directly in, they did not work. I am now wokring on the 4.7.2 kernel and getting encryption support to work. Now that I figured it out on xobs', I am a lot more confident I can get 4.7.2 to work.

EDIT 2: I now have the 4.7.2 kernel working with full system encryption support! In addition to the edtis above, I had to compile in the XTS support. I still got a couple fo errors with ipv6 and x-tables with the "Unkown symbol _GLOBAL_OFFSET_TABLE_ (err 0)" error, and that is a matter of hunting them down in the config file and changing the module to compile in. If anyone knows where they are I would appreciate it. I have added that config file here along with instructions to recreate what I did:


(17 replies, posted in Software)

Has anyone gotten the 4.7.2 to work an encrypted root disk? I cannot do that with the current novena_defconfig, and I have a feeling there is an option I am not enabling (I am able to make a uInitrd for with this guide): … ARM-device

(note to disable CONFIG_DEBUG_INFO=y so the initramfs isn't huge)

and I got past the "cannot initialize device-mapper" error with this guide: … ice-mapper

The latest error is that it could not find AES-XTS-128, but that was loaded as a module. I am recompiling with a suggestion form this post: … d=642#p642

I am also using the config from /proc/config.gz right now instead of the novena_defconfig one.

EDIT: I tried both, and got an error of "unknown symbol GLOBAL_OFFSET_TABLE" and still had the error of "Check that kernel supports aes-xts-plain64 cipher". I also tried pulling off the patches to get it working in the 4.4.90 kernel (as 4.4 will be supported until 2022), but I got a blank screen on it. When I have some more time, I will hook up the SPI port and see if I see more, and if I can actually compile xobs linux-novena and get it to boot with the encrypted hard drive.


(3 replies, posted in Hardware)


It is actually a lot simpler than that. All I had to do was build an out of tree module, and the command is

make -C /lib/modules/`uname -r`/build M=$PWD

You do that in the "Novena-RF/driver" if I remember doing this right. It will build you the module you need. No need for any recompiling.


(5 replies, posted in Hardware)

From what I have looked around for that's the only one that would fit because of the shape of the commerical batteries. The one the Novena has is a custom one.


I had no trouble with it. All you need to do is change the repos in /etc/apt/sources.list from Jessie to Stretch (with the exception of the one). It's pretty atraight forward.

EDIT: As I am sure you have noticed, I have been trying to get things more up to date to get Stretch working. I have a thread on a new kernel and new u-boot. The new u-boot has the support files to propoerly install the kernel with initramfs (so full disk encryption works). The kernel is still on 4.4, but it is being supported until 2022. Since the newest LTS kernel will be 4.14, I am thinking it would be a good idea to port all of the patches to that. etnaviv has been upstreamed to the kernel and to the DRM, how the debian archives do not have etnaviv extensions in stable, onlu unstable. However, you can get the package yourself and recompile it with that extension and install it yourself. That makes most of the packages on the related to xserver unnessesary.

However, the will no longer update, as it is signed with an older hashing algorithm.


(5 replies, posted in Hardware)


In the earlier Novena, they had this battery: … -pack.html … kerbox.jpg

I would imagine it fits in the case.


(5 replies, posted in Software)

Good Morning,

That is probably the issue! I am on Stretch now and that's when it happened.


(5 replies, posted in Software)


Sorry I should have made that clear in the original post, it is unrelated to that issue. I have the latest Repo Key, and up until two days ago, I did not have this issue.


(5 replies, posted in Software)

Is anyone else having this issue? When I try to update, I get this error:

Hit:3 jessie InRelease             
Err:3 jessie InRelease
  The following signatures were invalid: 7DE573926937EAFC75C33CB9F899B4CA0F7B2548
Reading package lists... Done
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: jessie InRelease: The following signatures were invalid: 7DE573926937EAFC75C33CB9F899B4CA0F7B2548
W: Failed to fetch  The following signatures were invalid: 7DE573926937EAFC75C33CB9F899B4CA0F7B2548
W: Some index files failed to download. They have been ignored, or old ones used instead.


(11 replies, posted in Software)

Unfortunately past that I do not know. The only thing I can say is that I recently reinstalled the OS on my Novena, and that I am using the SSD for the video.

Maybe xobs could chime in?


(11 replies, posted in Software)

Good Morning,

I know it's a dumb question but I will ask, you have xorg-novena, xserver-xorg-video-armada, xserver-xorg-video-armada-etanviv installed? and what driver is Xorg using, and what kernel version are you using?

I have used VLC when I tested, and it worked like I would expect it to.


(11 replies, posted in Software)

Hey Nopsled,

Just to clarify, have you tried watching a 720p video that you have on your hard drive versus watching something on youtube with firefox? When watching a 720p video with VLC from my local hard drive I have no problems, but I do not doubt for a second that attempting to watch a youtube video would be painful.

As a side note though, I upgraded from Debian Jessie to Stretch and installed Firefox (which is v50.1.0 versis Firefox ESR which is v45), and firefox runs a lot faster now.


(3 replies, posted in Firmware)

You are welcome!

So you know, there is a specific way of updating the SPL (That is the first stage boot loader for u-boot). I believe the script you need is novena-install-spl. You don't need to copy it over into the SD card.


(3 replies, posted in Firmware)


If I remember right, part of the debian installation process copies a u-boot.img file onto /boot/. I think that installation assumes that the SD Card is mounted as /boot. If you do not mount your SD Card as /boot, then the u-boot.img copied to SATA Drive /boot folder is there instead.

I would trust that the boot screen is telling you the correct version number.

I hope that helps!


(15 replies, posted in Hardware)

There is a button on the Battery Board called "Prime". That "jumpstarts" the gas gauge.


(15 replies, posted in Hardware)

The other thought I have is to do a reflash of the gas gauge:

You just need to compile the tools and run the command shown there.

After you do that, I would recommend a "gg reboot" then a "gg it".

As a further thought, you can try reflashing the senoko firmware, but it doesn't seem like that is the issue.


(15 replies, posted in Hardware)

a) It should be safe to do the pfreset command
b) sometimes you have to do the "gg it", I would issue that command too.


(15 replies, posted in Hardware)


I seem to recall having a similar issue, what happened was the individual cells are not charged evenly (if you look they are almost 100 mV difference). There should be a way of balancing the cells charge (I forget if it was through just normal charging or is I needed to do a special command).

Try just charging it up overnight and coming back to it.


(39 replies, posted in Software)


I remember having this issue. In the thid line of the uEnv.txt (where it asked for the UUID), you need to change that to the UUID of the root disk. When it drops to the initramfs console, go to /dev/disk/by-uuid/ . One of them is the correct one (I honestly forget which one, just try each one until it boots).

I edited the uEnv.txt file by moving the microSD card to another computer and editing it there.

I finally figured out the issue. The battery that powers the RTC when it powered off was at 0.3 V. I replaced that battery and it appears to work!


(3 replies, posted in Firmware)


See if this post helps: … 2175#p2175

So I thought I corrected it, but it is in the wrong time again. I am wondering if in the low power state (after shutdown, but the battery is still attached), the oscillator is being set incorrectly?


(55 replies, posted in Hardware)

That makes sense! Well it has been working normally since my last post, so I think whatever issues I have been having are over!