DEV Community

First experiences with Honeycomb LX2K

Liz Fong-Jones on May 13, 2020

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 ...
Collapse
 
valpackett profile image
Val Packett

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

Collapse
 
jnettlet profile image
Jon Nettleton

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.

Collapse
 
valpackett profile image
Val Packett

Huh, cool. I guess this bug might not be present in other operating systems.

Thread Thread
 
jnettlet profile image
Jon Nettleton

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.

Thread Thread
 
valpackett profile image
Val Packett

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.

Collapse
 
beerdrinksblake profile image
Blake Hartshorn

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.

Collapse
 
uh13719 profile image
uh13719

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 ?

Collapse
 
beerdrinksblake profile image
Blake Hartshorn

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.

Thread Thread
 
beerdrinksblake profile image
Blake Hartshorn

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.

Thread Thread
 
uh13719 profile image
uh13719

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.

Thread Thread
 
beerdrinksblake profile image
Blake Hartshorn

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.

Collapse
 
uh13719 profile image
uh13719 • Edited

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