on line 868 of the boot log i see 1. tegra-xusb 70090000.xusb: Direct firmware load for tegra21x_xusb_firmware failed with error -2
so i guess the firmware file is not loaded at boot time, is that right?
is there a way to see what is inside the boot kernel?
now these are the lines i found about the symlinking, from 1310,
’
1. ueventd: Failed to symlink /dev/block/sda1 to /dev/block/by-name/APP, which already links to: /des
2. ueventd: Failed to symlink /dev/block/sda2 to /dev/block/by-name/EBT, which already links to: /dev/block/mmcblk0p2: File exists
3. ueventd: Failed to symlink /dev/block/sda3 to /dev/block/by-name/RP1, which already links to: /dev/block/mmcblk0p3: File exists
4. ueventd: Failed to symlink /dev/block/sda4 to /dev/block/by-name/TOS, which already links to: /dev/block/mmcblk0p4: File exists
5. ueventd: Failed to symlink /dev/block/sda5 to /dev/block/by-name/LNX, which already links to: /dev/block/mmcblk0p5: File exists
6. ueventd: Failed to symlink /dev/block/sda6 to /dev/block/by-name/DTB, which already links to: /dev/block/mmcblk0p6: File exists
7. ueventd: Failed to symlink /dev/block/sda7 to /dev/block/by-name/EKS, which already links to: /dev/block/mmcblk0p7: File exists
8. ueventd: Failed to symlink /dev/block/sda8 to /dev/block/by-name/BMP, which already links to: /dev/block/mmcblk0p8: File exists
9. ueventd: Failed to symlink /dev/block/sda9 to /dev/block/by-name/SOS, which already links to: /dev/block/mmcblk0p9: File exists
10. ueventd: Failed to symlink /dev/block/sda10 to /dev/block/by-name/CAC, which already links to: /dev/block/mmcblk0p10: File exists
but i guess it runs AFTER boot, when vendor/etc/init/hw/init.porg_sd.rc is hit
ok, i patched the wrong dts file, as mine is a jetson a02, not a b01, so it still loaded the dts for a02 which wasn’t pointing to sda1
did a new patch, now i will build and try :)
ok, built it again, but can’t seem to build anymore, as the script errors out when running mkbootimg with missing pyyaml (within the build environment) and i really don’t know how to pass this
Yeah, things are in a bit of flux atm as I integrate l4t r34.1 stuff. The new version of tegraflash has additional python library dependencies, and pyyaml isn’t available in the android python prebuilt. I’ve got a local patch to vendor/nvidia I’m using to build, but don’t know that I want to commit that or not.
ok, it built fine, i guess it flashed fine i reached recovery and could flash the image, and saw usb activity, so the files were going to the nvme, and i can see in the nvme a partition with a recovery folder with logs saying i last installed eng.sucche.20220419.181734), but it only boots to recovery, no way to make it boot to system here is a boot log sending me to recovery, if you need the ‘new’ patches, here we go
thanks for any help :)
Lineage 18.1 for Nano has been released as of last week.
The opening post cannot be modified, but is still mostly applicable. Bullet points 3 and 4 no longer apply. The bootloader can be updated inline now (through a method akin to hitting the problem with a bigger hammer) and the boot stack is now inline with l4t 32.7.1.
A new note:
In recovery, the Nano 2GB carrier boards 2 usb host ports stacked together do not work. The single usb host port does work, so the input device used for recovery needs plugged in there. All usb ports work in android itself.
I have tried to fix up emmc module support, but since I still do not own one, I cannot test that. It would be appreciated if someone could try to install the new releases on an emmc module and report if it works or what specifically went wrong if it does not.
The error line tells you what’s wrong. The 17.1 zips cannot upgrade/downgrade the bootloader, as is stated in the opening post. You have to use the 17.1 flash package to install a 17.1 zip. The androidfilehost link on the Lineage wiki has a 17.1-old folder which contains the 17.1 flash package.
An 18.1 zip can upgrade from the 17.1 flash package. And of course installing 18.1 from the 18.1 flash package works. But going backwards from an 18.1 flash package to a 17.1 zip is not supported.
Forgive me if I come across as naïve since I’m a newbie at this. I’ve been racking my brain at this all day attempting to follow these instructions to install LineageOS 18.1 (Android 11.0) and have been stuck and not sure for the life of me what I’m doing wrong. So let me explain: I own both the 4GB (B01) and 2GB models of the NVIDIA Jetson Nano Development Kit. I have Linux (Ubuntu 20.04) installed on both devices, but I’m installing Android on the 2GB device while using the the 4GB device to run terminal in order to flash the 2GB device. I’m not well versed in Linux, but know enough to get around the OS. Where I get stuck at is at step 5 when attempting to “Install a custom recovery using ‘Tegraflash’”. I presumed that “Force Recovery mode” should be working after I connected a jumper to the recovery [FRC REC (10) + GND (9)] pin, plugged in the USB cable from the host [4GB (B01)] to the micro-USB port of 2GB Nano device followed by plugging in the USB-Type C power cable. I then entered “sudo dmesg” and verified 'APX becomes listed as available before removing the jumper from the 2GB device. Unfortunately, each time I run the following command “sudo ./flash.sh” , I get the following error message: “Checking compatibility. No compatible devices found. No Jetson Nano Devkit found”
I’m not sure what else is there to do or what details from the instructions am I overlooking or lack thereof, but I would greatly appreciate it if some kind soul would advise as to what other direction I could take to get “Force Recovery mode” detected. All helpful responses are welcome.
You say you’re flashing from a nano? Nvidia does not support aarch64 with their tegraflash tools. I could probably add an extra check to my flash script to explicitly state that. But yes, you need use an x86_64 desktop/laptop to run the flash script.
Ok, that’s reassuring… I thought I was doing everything right. Unfortunately, I was afraid that might’ve been the case regarding your revelation. Guess I gotta setup a fresh new installation of Linux (Ubuntu) on one of my other desktops. Thanks for the feedback, kudos.
I installed Ubuntu 20.04 on an x64 desktop and was able to get TegraFlash to initiate after running command “sudo ./flash.sh” in Terminal in the folder. At the same time, I have an HDMI cable connected from my Nano (2GB) to my TV/monitor and I can tell that my Nano is attempting to reboot into recovery b/c my TV prompts that there’s an incoming signal coming from the Nano but when I switch the TV input to output the Nano, there’s no signal. I’m not sure if I missed a step or if if it’s expected of me to already be aware of what to do next based on the limited scope of the instructions here.
Also, the instructions for installing “adb” and “fastboot” on Linux here seem to have implied steps b/c I can’t make out if doing it correctly b/c when I follow step 3 “Add the following to ~/.profile”, I don’t get any kind of feedback or prompt from Terminal; it’s just blank. Is it possible to get a brief rundown regarding how to enable adb and fastboot or could you provide me w/ a link to a site w/ a tutorial if possible.
Why are you using instructions from every site except the official wiki? The links in the OP are the ones officially supported. Any site that is not lineageos.org can’t be supported by the project since we don’t control them, you’d have to talk to whoever maintains the site.
Regarding the missing display. I’ve had issues if the display was not on when booting the device. If you hotplug a display or switch inputs, recovery is unable to reconfigure the framebuffer live. See if it works having that input selected before plugging power into the devkit.
Fair enough, but the instructions from “lineageosroms.com” are literally identical to the wiki, however, I will respect your wishes by refraining from using them while using the wiki instead.
Speaking of the display issue, I will leave on the secondary display while the nano is connected to it via HDMI before reenacting the TegraFlash sequence and see if that clears up my issue.
The “no signal in display” issue keeps recurring after reenacting the steps here. I made sure that my secondary display was turned on, connected to the nano via HDMI and on the correct input to eliminate the need for switching, but I still encounter no display.
Here is the print feed I am being presented w/ in Terminal.:
That said, that’s the end of the log? That’s not even getting to the part for flashing the device. Is there an sdcard in the target unit? That’s the only thing coming to mind that causes a hang there. If that’s not it, I don’t have any idea.
My fault… I thought I was looking at the correct instructions so my apologies. Shouldn’t I be using the instructions for Android TV since that’s the version I intend to install?
And yes, there’s an SD card in the unit. However, it’s not empty since I already had Ubuntu installed on it. Does the recovery not load if there’s still data stuck on the SD card? Does the recovery not overwrite the SD card?
—Edit—
Oh ish, when I thought maybe I should clean the SD card by reformatting it, I realized that there was no SD card in the unit, smfh. I know I already told you I was such a noob and that should be proof of it. My apologies again.
You linked porg_tab, so I linked porg_tab. If you do want atv, then yes you want the porg target.
The flash package rewrites everything, yes. The internal qspi and the sdcard. But the problem is, it’s not even getting that far. The flash process is hanging. Per your log, the last thing that happens is ‘retrieving storage information’. Iiuc, that’s checking to see what storage devices are available, like qspi, emmc, sd, nvme, etc. I don’t know why it would be hanging there. Like I said before, the only time I have seen that is when there was no sdcard in the target device. Do you have a different card you can try?
Oh ish, when I thought maybe I should clean the SD card by reformatting it, I realized that there was no SD card in the unit, smfh. I know I already told you I was such a noob and that should be proof of it. My apologies again.
—Edit—
Recovery has been successfully loaded, thanks for the tips. I’ll be sure to make a note of it for future reference.
