Jump to content

DaveWK

Members
  • Content Count

    8
  • Joined

  • Last visited

Community Reputation

0 Neutral

About DaveWK

  • Birthday September 29

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. After being pretty disappointed with the ancient kernels that Asus/TB has been releasing, I finally found a well-maintained distro to put on the TB2. Yay! https://dietpi.com/#downloadinfo You can dd this directly to an SD card or to the onboard MMC, and it works including the USB ports, HDMI and Ethernet. I was able to get the wifi to scan and connect but did not have antennas which may be causing my weak signal. I also ordered a newer m.2 AX210NGW Wifi 6/Bluetooth 5.3 card to replace the RTL8822CE card so we'll see if that improves. I also have been experimenting, and have been able to steal the u-boot and kernel from this image and set up Arch Linux as well. After successfully flashing the dietpi image and patching to the latest kernel, I deleted everything from the dietpi filesystem, extracted the Arch Arm rootfs, but kept the boot directory. I was then able to successfully boot into arch linux. The "edge" kernel is at around v6.6.xx and surprisingly works very well. One thing I was not sure how to do was fetch and rebuild new kernels for Arch which include the TB2 DTB and put it in the right place.
  2. Good to see other folks are starting to check out the armbian image as well. Asus or whoever they sold the support of the Tinker 2 to has been obsessed with some outdated v 4.xx custom kernel and u-boot distro, when I really wished they'd spend time just fixing up the drivers on armbian or getting mainline u-boot support so I can install whatever distro I want. I've found the wifi to be OK for the most part, but the problem really is that the tinker 2 devs are keeping the changes they made to the standard buck converters on the board a secret, which causes a bunch of downstream problems, since HDMI video output/wifi/disk performance all is impacted by needing to black-box reverse engineer how to make sure all the components power up correctly during startup and stay at the correct voltages. So far the disk IO finally works, but the performance would be better if the correct power-up and voltage suppliers were known. There is a higher speed driver (hs400) that would be usable but it has problems after start-up because of the power and Asus' secret buck converter. I had trouble with the armbian HDMI/GPU drivers on a 4k 60hz setup (half the screen was white) as well as not being able to have audio output at the same time as graphics from HDMI. Were you able to get 4k video 60hz to work with the latest panfrost drivers?
  3. All the repositories on github are for a very old Debian 10 release for v4.19 kernel. If someone from Asus/Tinker Board 2 team could please give us a dts for u-boot for a kernel v5 release it would be much more productive than all the edits and changes they keep making to this old distribution nobody is interested in using.
  4. Unfortunately I am running into the same thing as this guy: https://forum.armbian.com/topic/17448-is-asus-tinker-board-2-supported-by-armbian/#comment-122107 I did figure out that when I use fedora's u-boot for roc-cc-rk3399 that they include in the RPM's that it doesn't have the problem with writing to the MMC, but unfortunately the USB and ethernet doesn't come up (can only use the serial console). Sad because it is really quick to boot and even loads the driver correctly for Graphics on fedora. Not sure who's putting out these old debian 4.19 releases, but I wished they'd work on making a dts compatible with the latest u-boot so I can use whatever distro I want instead of forcing some ancient debian fork on folks who mistakenly bought this thinking it would work with mainline u-boot.
  5. It seems like the u-boot supplied by fedora for roc-pc-rk3399 is very close to what would be needed for a mainline u-boot release. I was successfully able to boot fedora from the MMC using the following steps: - On an x86 installer machine (running fedora) install the uboot-tools package (https://src.fedoraproject.org/rpms/uboot-tools/tree/rawhide), uboot-images-armv8 package (https://packages.fedoraproject.org/pkgs/uboot-tools/uboot-images-armv8/ ) losetup, and rkdeveloptool package (all available in the standard fedora repo) - Download a Fedora raw image aarch64, and extract it to a .img file. for this example I am using Fedora-Minimal-36-1.5.aarch64.raw - Run "losetup /dev/loop0 Fedora-Minimal-36-1.5.aarch64.raw" to make a loopback device for the image. Run gparted on the loopback device ("gparted /dev/loop0") and resize the partitions which overlap with idbloader.img and u-boot.itb. Close gparted and run "gdisk /dev/loop0" to convert the MBR to a GPT partition. Unmount the loopback device. - Put the jumper in the tinkerboard to boot into MASKROM. After it is turned on and seen by the OS, put the jumper back to the normal position. Run "rkdeveloptool db rk3399_loader_v1.20.119.bin" as root, substituting for the rk3399 loader you are using. You must swap the jumper while it is on or else it will not flash the mmc. - cd to "/usr/share/uboot/roc-pc-rk3399" on the host machine. Run "rkdeveloptool wl 0x0 Fedora-Minimal-36-1.5.aarch64.raw" as root where the .raw image is the one that you edited with the loopback device. at this time you should now see the partitions when you run "rkdeveloptool ppt". - Run "rkdeveloptool wl 0x40 idbloader.img" and then "rkdeveloptool wl 0x4000 u-boot.itb" from the "/usr/share/uboot/roc-pc-rk3399" directory as root. - Reboot the device. Be sure to have a serial usb attached. At this point, it will boot into Fedora successfully. Unfortunately, due to differences in the device dtb, there is no USB or ethernet support, however the Serial connection does work, so you can use the keyboard via the serial connection. This is where I am stuck. It's unfortunate because it does seem to boot very quickly, and has a very solid HDMI connection, so this would be a great OS to use with a modern 5.xx kernel. Any tips to get this working the rest of the way?
  6. I think I have narrowed the problem down to the emmc configuration.. For armbian I see: &sdhci { bus-width = <8>; mmc-hs400-1_8v; supports-emmc; mmc-hs400-enhanced-strobe; non-removable; keep-power-in-suspend; status = "okay"; }; &sdmmc { clock-frequency = <150000000>; clock-freq-min-max = <100000 150000000>; supports-sd; bus-width = <4>; cap-mmc-highspeed; cap-sd-highspeed; disable-wp; num-slots = <1>; //sd-uhs-sdr104; vmmc-supply = <&vcc3v3_s3>; vqmmc-supply = <&vccio_sd>; pinctrl-names = "default"; pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_cd &sdmmc_bus4>; status = "okay"; }; Is the use of mmc-hs400-1_8v here correct, as well as hs400-enhanced-strobe? I see in some cases this has been disabled due to the frequency being too low for the driver, so the hs200 is used instead. In the case of helios, another rk3399 board, hs400 was re-enabled: https://github.com/armbian/build/pull/2677/files#diff-1ffa592865c07dc11cdd53c328d714c1f7160c3170279467f8138f11d6166d02 Should this be using hs200 of hs400, and at what clock speed?
  7. Hi, I've been attempting to get Fedora aarch64 to work with the tinkerboard 2. In order to do so, it seems like I need to somehow modify the u-boot to properly handle the layout that fedora sets up in it's images. It seems like the current u-boot config is not set up to find the FDT in the layout, and has some hardcoded values for partitions which are very inflexible. Previously on rk3328 boards I was able to use this: https://pagure.io/arm-image-installer/blob/main/f/socs.d/Rockchips-ARMv8 to get it to flash the EMMC in the proper places for u-boot, but this has not worked on the Tinkerboard 2 for me.. For reference, fedora has a patch here: https://src.fedoraproject.org/rpms/uboot-tools/blob/rawhide/f/uefi-distro-load-FDT-from-any-partition-on-boot-device.patch which should allow it to scan for the FDT and load the EFI, however I have been having trouble porting the u-boot configuration that is in the Tinkerboard2 git repo to a more modern version. I was wondering if anyone has had any success in setting up a Tinkerboard 2 config in the mainline u-boot repo, or if there might be a compatible variant already there? I tried using rk3399-evb, however this is configured to use DDR3 and does not boot successfully. I was also wondering about if it would be an easier approach to modify the u-boot in the github repo for tinkerboard2 to point to the correct partition layout for a fedora install and copy the dtb into the image somehow, hot have not been able to get this to work either.
  8. Hi I noticed that Armbian has an experimental start to a Tinkerboard 2 build. This is really interesting because it uses the current Mainline kernel (5.19) instead of the ancient 4.xx builds that seem to be the only thing available in downloads. for example here's the kernel config: https://github.com/armbian/build/blob/master/patch/kernel/archive/rockchip64-5.19/add-board-tinker-board-2.patch and the u-boot config: https://github.com/armbian/build/blob/master/patch/u-boot/u-boot-rockchip64/add-board-tinker-board-2.patch This boots somewhat successfully however I think it needs a bit more work to be usable. When it boots you'll see a bunch of CQE errors like: running CQE recovery I/O error, dev mmcblk1 and mmc1: cqhci: spurious TCN for tag 5 which result in the filesystem going into read-only mode, and the system being pretty unusable. I found this somewhat recent post about rk3399's: https://patchwork.kernel.org/project/linux-arm-kernel/patch/20190301164349.60589-3-christoph.muellner@theobroma-systems.com/ and tried adding the disable-cqe-dcmd into the proper location, but it did not work. So I was wondering about: Is the Tinkerboard 2 supposed to have CQE dcmd support? I couldn't tell from the hardware specs if this was the case. If so, how should I fix this issue? This has not been updated in a little while, and I was unsure about the modifications this made to drivers/power/regulator/fan53555.c and drivers/power/pmic/fan53555.c in order to use it as a regulator for the gpu and cpu.. It seems like a lot of other rk3399 use compatible = "silergy,syr827"; is this a better option?
×
×
  • Create New...