LineageOS is a free, community built, aftermarket firmware distribution of Android, which is designed to increase performance and reliability over stock Android for your device.
LineageOS is based on the Android Open Source Project with extra contributions from many people within the Android community. It can be used without any need to have any Google applications installed. Linked in the instructions is a package that has come from another Android project that restores the Google parts. LineageOS does still include various hardware-specific prebuilts for which source is not available.
All the source code for LineageOS is available in the LineageOS Github repo. And if you would like to contribute to LineageOS, please visit out Gerrit Code Review.
This has been tested on the 2GB devkit, the a02 4GB devkit, and the b01 4GB devkit. It should work on the production modules, but I don’t have access to any to test.
The 2GB model is expected to have the usb wifi card that is bundled with it. The 4GB models are built to support the enli bcm4356, available from embedded works, but should work without it as long as ethernet is connected.
Inline updates work as expected, but the bootloader cannot be updated inline. This is because the L4T cboot doesn’t support USP updates. It tries, but panics. So if the bootloader needs updated, the device needs completely reflashed. The bootloader should not change outside of android major version updates, however.
The boot stack is a bit of Frankensteins monster. The bulk is from L4T r32.5.1, but nvtboot is from L4T r32.4.4. This is because nvtboot from r32.5.1 removed the ability to load a boot image (LNX) from the sd card. I did report this as a regression, but Nvidia does not consider it a problem.
There is no Android boot stack available for the Nano. The boot stack used for the shield devices does not support booting from qspi or p3450 in general. The L4T boot stack does work for android, but it’s not ideal. Several boot parameters have to be hardcoded. If the source to the t210 cboot was released, this could be fixed.
ok, i tried it with an Intel 8265 andit booted (damn slow from sd card) bot had no connection, had to wre the ethernet to pass the initial configuration. Once wired it works, but it’s extremely slow running from the sd, 'd like to run from an usb nvme or sata disk but, as you say, some boot parameters are hardcoded so i don’t think dding the sd to a NVME will work, even if the qspi on my nano supports booting from usb. Is there a way for it?
The intel 8265 isn’t supported in these builds. It’s possible it could be supported in custom builds if development was done for it, but I don’t know how much work that would be. I have mainly focused on supporting broadcom/cypress and realtek chipsets that Nvidia has used in consumer android devices or jetson modules.
USB boot. Yes and no. Again, this would be custom development for a custom build. The fstab and kernel device tree could be modified to look for most partitions on usb-storage. But the boot image (on the LNX partition) would still have to be accessible by the t210 cboot. I have not experimented to see which types beyond emmc and sd are supported there. Usb might well be.
ok, no problem for the 8265, i can live with ethernet (even if i’d like to add some more wifi stacks if i’d run into custom builds)
anyway, as i’d like to go deep in source customization, have you got any hints on where to start for the boot from usb part? i have no problem at all in having an sd card inserted, should it need to boot from sd and then look for the data partition elsewhere (as we jetson people used to do back in 4.4 L4T), but would need to know what to change in the source to point to another partition elsewhere
ok, another question… i noticed that while running android the fan has always been idle so the cpu gets quite hot, is there a way to run the fancontrol (or similar) under android?
Now, i’m downloading the source tree, hope to run the ‘source edit’ step tonight or tomorrow morning and the build tomorrow
Hmm, to be honest, I don’t know. The devices that ship with a fan have the controls set up in the kernel device tree. You might be able to look at jetson_cv (the Jetson TX1 devkit) and use the fan nodes as a baseline. Would have to look up what the right power rails and gpio controls are, though. If they’re not already labelled in the porg dt.
Fwiw, my nano devkits don’t have any aftermarket fans. I’ve not melted one yet. Though, on a related note, nvidia controls power states on the jetsons using something called nvpmodel. Unfortunately, the consumer shield devices do not use this, meaning there’s no publicly available copy of nvpmodel for android. If we had that, it’d be a lot easier to set power states for TDP caps. Due to this missing piece, the tx2 and xavier targets aren’t able to run at full performance either.
I tried it last night, seems like I accidentally installed the tablet version (just as well, none of my bluetooth adapters are supported) but I managed to play back 4k30 video perfectly fine in Chrome from youtube… once I got the full-screen dialog box to go away.
It’s super interesting though. I don’t know where to start with adjusting it for custom carriers, does it use the same device tree? What kernel is it using, just 4.9.140 with the android extensions or something else?
It’s going to depend on the carrier. I’ve not looked at any of the nano custom carriers. I’m slightly more familiar with the tx2 original module and tx2/xavier nx carriers. Most of the ones I looked at there were designed to be compatible with the devkit carrier. But not all were. Like on the tx2, it’s common to see usb issues when not using the custom dtb. Check to see if the manufacturer provides a custom dts/dtb or says to just use L4T with no modifications.
I would note that my flash scripts cannot check the carrier board id on t210. So if someone flashes to a custom carrier board, it’s on them to make sure that a compatible dtb is used. Even on t186/t194, it’s not required for a carrier board to have an eeprom at all, so it’s likely that the scripts cannot do sanity checks to verify the correct dtb and other configs are used.
The kernel is a bit of a mess, unfortunately. Reader digest: it’s the l4t r32.5.1 kernel with the android rel-32 changes rebased on top plus a few Lineage specific changes.
Longer explanation: Nvidia stopped releasing kernel history for the android rel-32 branch midway through the Android P release cycle. Current releases are essentially tarballs. The l4t kernel releases still have full history. The android and l4t kernels share the same baseline and are mostly intercompatible. So to supplement the missing history from the android releases, I’m baselining on the l4t kernel history. Using the l4t kernel as a baseline also makes supporting the nano and nx models more feasible as the android branch does not support these devices. So to be specific on what I’ve done with my kernel: I started with rel-32-r5, the last android kernel branch with history, then rebased on l4t r32.5.1. I diffed rel-32-r5 to the first tarball release and applied the diff to my new branch. Then diffed every tarball release to the next and applied that to the new branch. Then I looked at the diffs and checked the google-common kernel for related changes and applied those before the magic tarball diffs until only nvidia specific changes remained. Beyond that, I’ve added changes to enable hardware support for the nano and nx models, mainly defconfig changes.
Long story short, it’s been a royal pain to manage the kernel for these builds already, due to nvidia removing commit history for the android branches. And that’s with a semi-close l4t kernel to help alleviate the lack of history. I suspect the upcoming major version update for the SHIELD devices will deviate the kernel further. If that has no history, my job of updating Lineage is going to be really difficult. Related to that, if the kernel dt repos have deviated much, and the t186/t194 dt repos are not released as part of the shield source release (traditionally, they have not been), then it may be nigh impossible for me to continue to support tx2 and xavier.
ahem… the build fails when building the kernel, i guess that’s because i’m running ubuntu 22.04 (or 21.10 devel), coming with glibc 2.34 which errors out… i guess i’ll have to install some older version and try again
I’ve heard some whispers of that. Been avoiding updating to Fedora 35 on my primary workstation due to those. I should probably do some testing at some point. But since the official build bots use Ubuntu 18 or 20, I forget which atm, that’s all that is ‘officially’ supported. Not to say the Lineage team doesn’t try to make it work elsewhere, but issues like what can come up with newer glibc aren’t considered critical.
ok, i built for the first time, without any modifications, and it worked as expected… now i modified the files you mentioned (putting /dev/sda1 instead of /dev/mmcblk0p1 and turning all the /dev/block/platform/sdhci-tegra.0 but the boot one into /dev/block/platform/70090000.xusb as i want it to be on an usb nvme), now it’s building again but i don’t know how to install… i guess i could install the update on sd and then clone the sd card to the nvme, isn’t it?
btw, couldn’t there be another target for porg_usb to put the fstab in a new file instead of editing fstab.porg_sd (just as with the foster fstabs)?
thanks for the help
There could be a porg_usb product, but would need to make another kernel dt to set ro.hardware differently to use it. If someone gets usb working and pushes to gerrit, that would be what I’d want.
Initial flash to usb is a missing piece of the puzzle. I don’t know if tegraflash supports that. If not, some other method needs done, not certain what though.
ok, it didn’t work (as somehow expected) with /dev/block/platform/70090000.xusb ,i will have to start an android from sd and look for the device nodes with adb and then modify the files accordingly and build again… will let you know :)
ok, still didn’t succeed in listing the device nodes, as i have no root access… tried to install magisk but ended booting to bootloader. Is there a simple way to gain root access?
btw, i saw the developer for nvidia devices for lineageos and twrp is the same, webgeek1234, is there a twrp built for porg?
thanks
Root should work. Not su, but 98% of the time, you don’t need su. Got to dev settings and enable adb root. Then run ‘adb root’ from the host machine. Then the shell will have root access.
Re twrp: Yes and no. There’s not directly a porg build that you could fastboot flash. But there is porg support in the foster releases. The only difference between a porg build and a foster build is that the porg boot and recovery images are signed to make the l4t bootloader happy. So in theory you could fastboot boot a foster image and it’d work. Note that I haven’t tested that. The other option is to replace recovery.img in the flash package with a foster twrp release. Then the flash process will sign the image before it writes to the device. This I have tested, it works fine. You could also run your own build twrp for porg, then it should be fastboot flashable. Again, I’ve not tested that.
ok, i really didn’t know about adb root, will try that. for the twrp part, i tried to boot foster twrp from fastboot (fastboot boot twrp.img) but it seemed to hang (waited for 5 minutes and no go). Yesterday i tried to build twrp for porg, the build succeeded but i had no time to test if it fastboot booted, will try today.
btw i saw that magisk had some problems with foster in the past, and it doesn’t work now with porg (it boots to bootloader), does it need some code adjustment to run on porg?
thanks for all the help you are giving
I explicitly want nothing to do with magisk. The way it monkeys with the frameworks makes it virtually impossible to debug problems. Any bug reports to Lineage that have magisk in the logs will be rejected simply because we cannot know what magisk has done to the system. You would have to raise any such issues on the magisk issue tracker.
I am trying to build the lineageos image on ubuntu 20.04 for porg (android TV) but I have problems in the blobs extraction step. After downloading and extracting a bunch of files I get the error:
error: t186/firmware/xusb/tegra18x_xusb_firmware
I tried both methods, using adb and from installable zip. Any advice, please?
Thank you
