I last wrote about arm64 two months ago when I was excited for my Honeycomb LX2K board.
Well, it's arrived! and it's glorious! Everything is just ...
For further actions, you may consider blocking this person and/or reporting abuse
Dang, even v2 silicon needs OS quirks for PCIe still. It's ridiculous that to this day, the Armada8k (macchiatobin) has the least worst PCIe problem, among the affordable devices at least (Ampere eMAG is pretty much fully everything compliant but that's $thousands).
Also it's funny that their board is called the same as your company :D
The issue with PCIe is not a quirk, but a bug in the PCIe code that has been in the kernel since 2017. Yes we are exposing the bus in a non-standard way to work around silicon limitations but the bug we exposed is due to the code not being written to the PCIe spec, not what we are doing. The only consumer of the function that needs to be patched is the amdgpu driver. This is made worse by the amdgpu driver not respecting the ACPI tables telling it not to re-assign those resources.
Huh, cool. I guess this bug might not be present in other operating systems.
Most likely not. The code was an assumption you wouldn't re-assign a bar on the device sitting on the root of the bus. Even though in our implementation this node is not actually the root controller, that assumption is still invalid since root controllers can have their own bars.
Do operating systems need to handle the NXP0016 device?
NetBSD does: github.com/NetBSD/src/commit/1a0fb...
but, hm, github doesn't find "NXP0016" in Linux.
Thanks for reporting on this. I'm curious, when you built the UEFI image, did you check out a specific branch or have to do any troubleshooting otherwise? I was having a different set of problems every way I tried it, but your image booted right up.
Ah ... The UEFI branch has been removed from SolidRun's github.
Out of sheer luck I seemed to have unintentionally downloaded the UEFI branch(lsdk-19.09-sr-uefi) when it was still available back in January. (I don't know the exact date when they removed it)
I was reading somewhere that they might re-release a UEFI branch in a few weeks time.
Having said that, I was shocked when the UEFI build generated an image straight away and the generated image booted into GRUB menu right away. My problems happen after this point.
As mentioned in this article, I only built the boot image using that UEFI branch. The complete/linux build fails on the UEFI branch I have.
I am not sure if this helps.
What issues are you facing by the way ?
I found another user on github who had actually cloned that repo and still had the uefi branch in it, so that's a thing I tried, but the final image didn't seem to do anything. Liz's image boots, but I get memory errors trying to boot any kernel, which I'm thinking has to do with the ram speed that image was built for not matching mine (operating under an u-boot image I built myself is fine). I've spent the last few days hacking my way through the runme script and pulling different branches of things to mixed results, both in and out of docker. Closest I got on the master branch was a 20.04 UEFI loader that starts to boot up and then panics.
Anyway I'm still trying. Lol. I saw on Jon's Twitter new features coming down in it, so it has to be working somewhere.
Actually this must be why:
SoC: LX2160ACE Rev2.0 (0x87360020)
I notice in the latest runme.sh it implies that 19.09 is only for rev1. The image provided here is for 20.04 though, so still very curious.
So if I understood the directions correctly, if you have managed to get your hands on a brach with UEFI in it, you use that branch to build the BOOTLOADER_ONLY image.
This can be done by either setting the parameter BOOTLOADER_ONLY inside the runme.sh script or passed as a parameter: BOOTLOADER_ONLY=yes ./runme.sh
You will also need to set the DDR_SPEED.
The purpose of this image is only to boot the system with UEFI and not provide a working userspace filesystem (which is the default settings that uses u-boot)
If the image generation goes through, you should be able to boot the board into UEFI shell at the very least.
If you have a ubuntu-server.iso on a USB, it should take you upto the grub2 boot menu. where you chose to install/try ubuntu-server.
I probably should have chimed in that I found out what's going on.
The UEFI image here (which I've found out does work and I'm just having some weird kernel problems) is being passed around by the community at the moment while they get the new branch ready. There's a Discord chat you can get invited to if you reach out to SolidRun's support. Images built with the old UEFI branch don't work with the rev2 board. Currently I can get Fedora to boot on it and working on getting Debian Bullseye to boot.
Hey Liz,
Great article. But I'm struggling to install this on my HoneyComb LX2K. I'm hoping you or someone on this forum can help.
I'm able to boot to GRUB menu and it looks like the Kernel boots successfully into the ubuntu-installer. But I can't proceed any further because the installer menu/GUI does not display properly on the serial console.
I've tried a bunch of different console applications like screen and minicom but the issue remains the same.
Do you have any suggestions to bypass the installation menu or fix the garbled menu display.
P.S: My LX2160A silicon version is 1.4