err4o4 / spotify-car-thing-reverse-engineering

390 stars 5 forks source link

Superbird Working Linux 6.6 / Buildroot 2024.3 / Armbian 24.5 #30

Open alexcaoys opened 2 weeks ago

alexcaoys commented 2 weeks ago

Hi everyone,

I am currently working on a forked Linux 6.6 (or maybe next LTS in the future).

Originally I wanted to publish it after everything is working so that I can give everyone a fully functional Kernel + system environment. But looks like there has been a lot of attention on this device recently. I guess this is a great opportunity to bring it to everyone's attention.

Kernel: https://github.com/alexcaoys/linux-superbird-6.6.y

My notes: https://github.com/alexcaoys/notes-superbird

Although it's not completed yet, the only thing partially working is the display (color is incorrect). Everything else I can think of is tested, working fine. I am in touch with one of Linux Amlogic Maintainers working on the display issue so I have faith it will be finished within the next few weeks/months. If anyone wants to help, please submit an issue there. I also have a working buildroot 2024.2 running on it (Other distro is possible but not recommended since their higher hardware requirements). and cog on it should provide a much better browser experience.

Please note this is only for expert users for now. I will try to come up with a better guide/notes/steps in the near future. By the way Mainline kernel is actually not working for this device, unifreq only provide his version for LTS versions.

I have to say the recent news are a bit unfair to this device since Raspberry Pi 2 W has only 512MB RAM too and This SOC is even better (https://www.cnx-software.com/2021/11/01/raspberry-pi-zero-2-w-vs-radxa-zero-features-and-benchmarks-comparison/). In my mind, this device should be a really good remote control for all sorts of things. (I was thinking Home Assistant when I bought this)

Hopefully all these will better help this community.

lmore377 commented 2 weeks ago

Amazing job getting this far! We've talked about compiling custom kernels for the car thing a bit but never went further than just recompiling the stock kernel. Have you looked into resizing partitions or getting USB host working? I know those two things would be really helpful for a lot of projects.

Also if you haven't joined already, there's a discord where some people have been working on a lot of different stuff and it'd be great to have you there! https://discord.com/invite/3UyX9zRa7p

alexcaoys commented 2 weeks ago

Thanks! The stock kernel is a bit of lost cause, old and contains a lot of vendor stuff. Sadly that's the case for many SBC/vender kernels out there. Thankfully we have people working on this SOC for mainline kernel support.

For that two things in particular:

  1. partitioning are doable but high risk since some encrypted partitions need to be tweaked. I have notes/reference on that in my repo. I tried but since then I couldn't use booti on recompiled stock kernel, run storeboot can still work. I think I need the stock firmware to work for my reference so I won't touch it for now before everything on the custom kernel is working fine.
  2. I use USB port for Gadget Ethernet (g_ether) for now so I am not sure if it works as HOST. But looks like it might have the same hardware design as the USB-OTG port on Radxa Zero (https://wiki.radxa.com/Zero/hardware/zero). You are welcome to tweak the device tree to check if it can work as power+host.

Thanks for your invite, but I am not really a Discord user. You can post this on Discord so more people can see it. I might join it later, let's see.

Cheers!

lmore377 commented 2 weeks ago
  1. I tried but since then I couldn't use booti on recompiled stock kernel, run storeboot can still work.

I'm a bit confused for what you mean, are you saying that boot completely fails when the DTS is changed?

Sidenote, is there anything that I or anyone else could do to help? I'm only somewhat familiar with kernel development (ported openwrt to a router) but I'm more than willing to learn some new stuff. Also, I'm sure there's some people in the Discord that are much more familiar with it than I and I could bring them over here

alexcaoys commented 2 weeks ago

Let me try to elaborate more on that. I will also put it on my notes later.

According to the reference I found (Links on my notes), in order to repartition the emmc using the tool they provide, we need to extract and decrypt a vendor dts from a reserved partition (not the one in dtbo partitions), and then put the decrypted version back. I tried, after doing so, the stock firmware won't boot at all (probably due to vendor u-boot restrictions).

Since I need the stock firmware to work as a reference while I am working on the new kernel, I put the backup/encrypted version back. But even with the encrypted version in place now, this bit (which is using booti on u-boot) will not work at all. The only way to boot into stock firmware is by run storeboot from u-boot.

I am not sure if the encrypted one is device specific. So essentially if someone mess up the partitions and have no backup for that, the device will not work with the stock firmware at all.

Because the kernel I used can read the Amlogic partition tables, and 512MB system partition is enough for me to use at the current stage. I don't plan to repartition my device before we have a fully functional kernel/system. I suggest everyone to do the same.

The only important thing left are the MIPI DSI display (which is quite important). The upstream source code for MIPI DSI only became available/usable on Linux 6.10 several weeks ago. I have already contacted Neil, the main contributor of Amlogic Display Driver. He said he will help me take a look since he has this device too, but I believe he's also super busy. If there's anyone familiar with MIPI DSI Display Driver / Display Panel Driver / DRM etc., welcome to take a look and possibly provide a fix for that. I can also put a TODO list on my notes repo so everyone will know what's the next steps for this project.

lmore377 commented 2 weeks ago

Is the vendor dts at the beginning of the flash? If it is, the unbrick folder here might help: https://mega.nz/folder/NxNXQCaT#-n1zkoXsJuw-5rQ-ZYzRJw

A while ago I made a backup of the the first 60mb of the flash so the car thing could be recovered in the event that something happens to the bootloader or if the flash is zero'ed out and I suspect that the vendor dts is somewhere in there. I've successfully brought 2 car things back to life with that file

alexcaoys commented 2 weeks ago

Oh yes, it's around 40MiB (https://7ji.github.io/crack/2023/01/08/decrypt-aml-dtb.html). If that works for multiple devices, that might not be unique for each device. Still, for my testing propose, since I only have one device, I will keep the partition tables for now. I might repartition it after everything is working. If I remember correctly, repartitioning actually requires a working third party system (which cannot be on emmc). I used initramfs when I was testing that. I guess we'll need to create one for everyone later. (This will be on the TODO list then)

lmore377 commented 2 weeks ago

Yeah the only thing that seems to be unique per car thing is the serial number but that's burned into the efuses

alexcaoys commented 6 days ago

Providing more updates here as well.