eselarm

Yes I explicitly checked. I personally do not really care about the labels/names in the software, although I must know what is what. I look at the picture of the PCB mostly. Or '1G' and '2.5G' that make more sense in my case as I do not use it as a router. I have defined a software ethernet bridge br0 that includes both ports as I need that for virtualization anyway.

Note that for the NanoPi R6C it is correct. Although lan2 could be removed because PCI-E 0004 node contains my NVME SSD. EDIT: I see https://github.com/armbian/build/blob/main/config/boards/nanopi-r6c.csc is correct, no lan2. It is just that on my installation the rules file is not updated. It is from image older than a year.

For my ROCK3A (rockchip RK3568) using Armbian 24.11.x I enable SATA (beta 6.1.84 kernel). I need the file: /boot/dtb/rockchip/overlay/rock-3a-sata.dtbo, that exists. I see in armbianEnv overlay_prefix=rk35xx, but from boot.cmd there is now an extra option without applying overlay_prefix, which is needed in my case I see. I compared with and older NanoPi-NEO (allwinner sun8i/H3), how i did it there. So my statement added in armbianEnv.txt is: overlays=rock-3a-sata and that works. Note that I added it with a text editor to armbianEnv.txt myself, as I needed to change paths related to booting unusual things that armbian-config doesn't know.

I am almost sure now that the reason I saw: 'Running /scripts/local-premount ... Scanning for Btrfs filesystems' is power supply or circuitry related. What exactly is a question still. If I want to know, I have to go back to the situation on the day before yesterday when I tried to boot the new ROCK3A v1.31 with the original downloaded noble 6.2.62 based images. Radxa wiki mentions 5V/2A is needed, so I took a known-to-work PSU (used for diskless RPi4B) rated 5V/2.4A, added my https://www.fnirsi.com/products/fnb48s and with HDMI, serial console, RJ45 connected as well. The FNB48S displayed values well below 5V/2A. What worries me is that several strange things happened: - with 2 different brand SD-cards, the board went in a low-power state, stalled. Disconnect and then reconnect USB-c power cable made it boot further mostly, until 1 time full success - the HDMI monitor sometimes shows a shaky flash. That is the most strange; I suspect a loop in cabling somehow, but it isn't there (in theory). The workaround is to make sure no loops, so no HDMI, serial console connected laptop on batteries - around kernel/systemd messaging about NPU power also something changed, either stall or success. In the end, as stated already, Radxa Debian11 CLI image worked. But also the Armbian Bookworm minimal IoT image with kernel 6.6.62. So I used the latter one to set up some basic things like ssh access and keys and correct MAC/IP address (networkd fails somehow with DNS in my homelan, so purged netplan and (re-)installed NM). And the converted the whole rootfs of-line to Btrfs with btrfs-convert, put SD-card back in and it still worked. Yesterday, the day after, I swapped the 5V/2.4A+FNB48S for just a new RaspberryPi 5V/5A PSU (not that the 5A matters) but was new/unused and also got 2 the other already setup noble rootfs systems onto extra partitions on the same SD-card. No issues, although now it is kernel 6.6.63 or 6.6.64 already as I put it on the beta repo. My use-case was replacing an old dead Intel Asrock server board handling a large SATA HDD, so I needed the 6.1.84 vendor kernel which now includes a SATA overlay and that works (kernel sees it at least). So my guess is I have/had some (GND)loop or whatever. I always can run the whole setup via an off-grid standalone 12V car-battery, in case I want some 'proof'. it was late in the evening, too tired as well I guess.

@AaronNGrayI have the 500G variant in my NanoPi-R6C: Model: "Samsung SSD 970 EVO Plus 500GB" FW Rev: 1B2QEXM7 You can use the tool 'nvme list' to see your details. This 970 EVO Plus series is well known, I don't expect it a source or trouble. A year ago a RaspberryPi engineer mentioned fantastic speed on a Pi5 (via some adaptor board that was available at that time). I think it was PCI-E v3 mode, that is not formally supported on a Pi5, but generally works. But that is just some side info. Your board is 4-lane PCI-E v3 formally supported by the RK3588. My RK3588S based NanoPi-R6C is only 1 lane PCi-E v2, I have not seen any issues in dmesg. Have you already booted/tested with 6.12.2 mainline or later? You don't need t build it, it is available via apt on the armbian beta repo. Make sure the correct files are in /boot (or where your U-boot looks for at poweron).

@AaronNGray As amazingfate hints, running a 6.12 mainline based kernel would likely get you further a bit faster in figuring out why the NVME/PCIe storage fails. It is a RK3588, so pretty standard. Then it might simply be that your specific type of NVME (and/or its internal firmware variant/version) might be the cause of the problems. I have been following many efforts getting a Pi5 running with NVME and not every NVME is guaranteed to work. Problem with Pi5 is that extra flatcable and interface board and powering that is well, this is N/A for RK3588 SBCs with M.2 M-key on-board. If you only need headless/server in the end, use that. An maybe not noble but bookworm based. I spend several hours yesterday to discover that my carefully prepared noble image for Rock3A is unstable w.r.t. SD-card at boot, but same kernel version with bookworm no issues. Is another topic, other board, but still maybe a hint. I currently have no clue (yet) why the noble install ran fine in a VM on RK3588S (pinned to 2x Cortex-A55) and not on the real RK3568 (4x Cortex-A55, many more HW peripherals). Seems like U-boot config/version or so.

There is an issue with SD-card interfacing in the 'noble_current_6.6.62' images I think. I see the same: Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems and is is because after the kernel is loaded and starting to run (doing scripts from initramfs etc), the SD-card/MMC interfacing get flaky or so. That endless wait is just that initrd can't find the rootfs. It also happened in an earlier phase that communication with the SD-card gets into trouble. Then many block I/O errors. It seems on older slower card 1 out of 4 powercycles it works, and then also no problem at all. The successful run I managed to setup the full system KDE neon desktop. But now it always fails, so I took a complete image of the SD-card and will try later. In my case it is a ROCK3A so different SoC. A Radxa Debian11 CLI image gives no problems. I will make an own topic later when I know more.

Another update, basically marking this topic as obsolete (concerning myself, my use-cases), is that KDE worked well when using the KDE neon build based on ubuntu22 image for NanoPi-R6C. I won't try any further with KDE(Wayland)+bookworm+NanoPi-R6C. X11 works, but I use headless/CLI mostly. There is also now an ubuntu24 based image available with 6.12 mainline kernel, so if I want to use desktop again I will use that and likely merge my bookworm server-oriented functionality into that.

Btrfs can detect and even correct block errors when dup or raid1 profile is used, but from the dmesg kernel log you can see that the whole NVME storage device disappears. I use 'btop' CLI tool via ssh, shows temperature as well. It is no guarantee that with 6.1.84 it works. If it is {old) SW implementation in the vendor code for PCIe as igor hints, then mainline kernel might be a better test/try. If power issue then I don't know. I used 6.10.10 kernel with ubuntu 22 KDE neon image as test, very well working GPU accel operation. Now there is noble based I see in downloads, but I use headless and bookworm based(don't need GUI/HDMI).

Ii your first log with 6.1.75 kernel I see: [ 48.606684] nvme nvme0: controller is down; will reset: CSTS=0xffffffff, PCI_STATUS=0x10 [ 48.606692] nvme nvme0: Does your device have a faulty power saving mode enabled? [ 48.606694] nvme nvme0: Try "nvme_core.default_ps_max_latency_us=0 pcie_aspm=off" and report a bug [ 48.643584] nvme0n1: I/O Cmd(0x2) @ LBA 0, 8 blocks, I/O Error (sct 0x3 / sc 0x71) [ 48.643602] I/O error, dev nvme0n1, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 2 [ 48.666942] nvme 0000:01:00.0: enabling device (0000 -> 0002) [ 48.667012] nvme nvme0: Removing after probe failure status: -19 [ 48.680284] Buffer I/O error on dev nvme0n1, logical block 0, async page read [ 48.680286] nvme0n1: detected capacity change from 3907029168 to 0 I recognise 'aspm' from RPi5 related PCIe, but don't know more. But you might look into that. My NanoPi-R6C with alu casing goes to 76 degrees when room 20degres and kernel compile in armbian build. If I put metal can with water on it 47 degrees or so. No fan, Samsung 970 512G PCie 2 x1 NVME. U-boot, BootFAT is on eMMC. Only GMAC ethernet. I currently use 6.1.84 vendor, but if troubles I will boot with 6.12.2 mainline. I have no trouble with NVME or PCIE, only get reboots if I mess with power supply like adding meters or using cheap USB-C PB DC/DC from 12V car battery. Your NVME is PCIe3x4 I think, it is more demanding I think, I am not sure how PD operates on RK3588 boards. vendor and mainline might differ, My understanding is vendor can negotiate >5V, mainline not yet. But I am guessing now. You should put USB-C PD analyser on the powerline for actual status.

Check you powersupply I think. And run armbianmonitor -u and post the URL so we see what versions and so on you are running.

Besides the manual CLI running of VMs with tasksel, there is also a good/acceptable way-of-working when using virt-manager/libvirt/virsh. Problem is already old I see, also the workaround here: So in my case on a NanoPi-R6C, that I just did upgrade, so got kernels: -rw-r--r-- 1 root root 33792512 Dec 5 18:28 vmlinuz-6.12.2-current-rockchip-rk3588 -rw-r--r-- 1 root root 39705088 Dec 1 18:38 vmlinuz-6.1.84-vendor-rk35xx I replaced: <vcpu placement="static">2</vcpu> with: <vcpu placement='static' cpuset='2-3'>2</vcpu> meaning now my home automation VM runs on 2x Cortex-A55 and I rebooted using the 6.1.84-vendor-rk35xx kernel. So far so good. This is great as I want also to do some video transcoding HEVC->H264 in the backgound (live) and hopefully also RKNPU experiments.

Indeed not really a tutorial. Also ROCK 3A has SPI, which is a not the case for my BananaPi M1, NanoPi-NEO, NanoPi-R6C. I'll see what that brings. But the issue is generic Armbian, personally for me like 2+ years or so that I am trying to figure out the best way of working. For my 5x NanoPi-NEO I have simply cloned the first part of the SD-card long time ago, split/resized the root Ext4 into bootfs (Ext4) and rootfs (Btrfs), so standard Armbian/Debian kept working. I also tested with an EFI+GRUB layer (openSUSE) which then offers easy multi-kernel at boot via grub serial console, but I did not figure out how to enable S/P DIF and 1-wire and other GPIO's there.

As listed in the topic, this is my desired and actual partition table setup for a lot of my computers. The U-boot 'partition 0' is typically somewhere in sector 1 till where partition 1 starts and only for SoCs/boards that do not understand any filesystem, like Allwinner and Rockchip based platforms. Also old BIOS PCs actually. It can be MBR or GPT (+hybrid) if more than 4 partitions are needed, for multi-boot, like adding Linux to a new Win11 pre-installed PC. The FAT is ESP or just type 0x0c/0x0700. Now I am struggling a bit with the case where a preinstalled ROCK 3A (RK3568, board ordered, not delivered yet) image has FAT mounted in /boot. RaspberryPi and UEFI PC have 1st FAT mounted on /boot/firmware and /boot/efi usually. For fast and easy multi-kernel management, I want to have the kernel file/image to be there as vmlinuz-<version> on Btrfs as master/base and not as file "Image" on the FAT. For my NanoPi-R6C (RK3588s) I made and extra multi-OS capable script that copies files from Btrfs to FAT as I see no way the default Armbian methods can handle this correctly. Maybe I miss some info, but I needed to fix bootup several times as something related to boot.cmd and/or armbianEnv.txt was not correct. To not risk any actions from existing tools (on any OS) I use /boot/uboot to mount the FAT partition 1. I also have /boot/tftp and /boot/vfat, for other purposes and workarounds, but that is another story. By having an own hook script for dracut and/or initramfs, I could leave the out-of-the box FriendlyElec Android/OpenWRT u-boot loader (2017.x) in the first 32k sectors as is, without knowing much about Rockchip ROM loader and offsets etc. AFAIK, the default 24.10 U-boot config is to not have Btrfs included, so I kept it like this so far. I have build own U-boot with Btrfs, removed the FAT and made Btrfs partition 1 as test for 64-bit QEMU imagefile and 32-bit AllwinnerH3 SD-card. So then the symlinks for kernel, uInitrd, DTB are used without any further changes in Armbian scripts or so. However, that same OS image (whole SD-card or as image file) does not boot in a VM then (virt-manager, EFI needed). I normally add grub-efi etc so there is a /boot/efi/EFI/... to do a default UEFI boot with the same mainline based rockchip-rk3588 kernel. That is really great option to do some initial config and so on before writing SD-card (and going outside where the real board is / will be). So the question is now: How can I keep the desired partitioning scheme and filesystem formatting, but get rid of my own initramfs hook and double/extra boot.cmd ? My current own script (pseudo-code) does not use optional moves but always copies (see /etc/initramfs/post-update.d/99-uboot for original): # $1 is kernelversion string echo "update-initramfs: U-boot: copy DTBs to boot partition" >&2 rsync -ac /usr/lib/linux-image-$1/ /boot/uboot/dtb/ echo "update-initramfs: U-boot: copy kernel to boot partition" >&2 rsync -ac /boot/vmlinuz-$1 /boot/uboot/Image echo "update-initramfs: U-boot: copy uInitrd to boot partition" >&2 cp -a /boot/uInitrd-$1 /boot/uboot/uInitrd echo "update-initramfs: U-boot: done." >&2 U-boot by default does not scan all disks AFAIK, it only wants/sees boot.scr on partition 1. An workaround is to place the FAT after the rootfs, so partition number 2-128 (or 2-4 in case MBR). That works for UEFI based, but not for RaspberryPi3 and older. For RPi4 I am not sure.

Shame on me that I don't have a USB-A to USB-C cable. Only USB-C to USB-C (including powermeasuring in connector). Also have several USB3-A to microUSB3 for Samsung phone debugging (S5). Because the S5 needs USB3 for ADB, I think the same is for Rockchips which also are main business case Android I think. My NanoPi-R6C is promoted to 'production' so must run 24/7 UPS connected. I am looking to buy some other Rockchip based board so I have an option to play with 2-storage device/rootfs issues. I have an RK3066 (in MK808 Android stick) but that is stuck at Debian7 more or less and 32-bit. Maskrom works as expected there with USB2-A to mini-USB2 cable. I can read/write ranges from its 8GB MTDblock, so including some Linux kernel 3.0.36. The EDK2 UEFI RK3588 I know and tried, but it hides the eMMC, so only NVME is usable (with standard ARM64 UEFI kernels). Also no option if you want HW accelerated Wayland/X11/DRM/GUI. Modern U-boot can do/emulate EFI as well, so together with matching Linux kernel DTB that is a better option. The U-boot in my NanoPi-R6C in eMMC is now '2024.10-armbian-2024.10-Sf919-P485c-H3f52-V1bfa-Bda0a-R448a', verified that it comes from eMMC. Which also means I don't have a method to boot from SD-card, unless a watchdog or so would try SD-card in case eMMC boot area would be corrupted with random data. All zeros in eMMC would result in boot from SD-card I think. This is something different from the 2017 U-boot from OpenWRT pre-installed. So the worry is still there that I currently don't have an un-brick method I think, so will order some cable types that are needed.

Strange that this need to be changed. I see for mine: grep CONFIG_DISABLE_CONSOLE /usr/lib/u-boot/nanopi-r6c-rk3588s_defconfig # CONFIG_DISABLE_CONSOLE is not set

initramfs is re-run/updated whenever a tool or setting or package in initramfs is changed/updated. So for example, I don't use NTFS on Linux only boards, so when I remove the ntfs-3g package, initramfs is regenerated as the ntfs tooling is removed from initramfs.

The first question is: What U-boot binary blob is written to your storage? In my installation, the U-boot binary blob is not written during upgrade. I do this myself with dd. Was originally some 2017 version. I always had all text displayed. The loglevel in armbianEnv.txt is for kernel, although mine is at 7, but that should not matter for U-boot AFAIK. I have a NanoPi-R6C (is RK3588S) but also several other Armbians, did apt update && apt upgrade yesterday (current branch). Now kernel 6.12.1 and also a newer U-boot. The version is listed in: /usr/share/doc/linux-u-boot-nanopi-r6c-current/changelog.gz mine is: Similar path specific for your Rock 5B. Should come from package 'linux-u-boot-rock-5b-current/bookworm 25.2.0-trunk.100 arm64' or later. The use configuration used for compile is: /usr/lib/u-boot/nanopi-r6c-rk3588s_defconfig Again, similar path specific for your Rock 5B.

I have done a bit more trial-error and it turns out that the USB port where the A-A cable is inserted won't initialize/open. I can see that via strace and also upgrade_tool creates a log file in a hardcoded filefolderpath /root/upgrade_tool/log/ It looks like I need to buy an USB3 A-A cable if I want to know more. What for sure is not working is pressing maskrom button and hoping that the R6C boots from SD-card. When I don't press the maskrom button, so normal power on, then the "U-Boot 2024.10-armbian-2024.10-Sf919-Pbdc8-H3f52-V1bfa-Bda0a-R448a-dirty (Oct 22 2024 - 11:19:49 +0000)" also prints: rockchip_dnl_key_pressed: no saradc device found That is some sign to me although I vaguely know/guess that there is no DC level voltage detected indication what to do. Or more likely that the driver for SARADC is missing. Anyway, I can stop via keypress at autoboot via serial console and then do: => bootflow scan [...] => bootflow list Showing all bootflows Seq Method State Uclass Part Name Filename --- ----------- ------ -------- ---- ------------------------ ---------------- 0 efi_mgr ready (none) 0 <NULL> 1 script ready mmc 1 mmc@fe2e0000.bootdev.part /boot.scr 2 script ready mmc 1 mmc@fe2c0000.bootdev.part /boot/boot.scr 3 efi ready nvme 1 nvme#0.blk#1.bootdev.part /EFI/BOOT/BOOTAA64.EFI --- ----------- ------ -------- ---- ------------------------ ---------------- (4 bootflows, 4 valid) So this is with valid IP-address, SD-card with older know to work minimal Armbian Bookworm, eMMC with 1st FAT boot, NVME with openSUSE and a handful others. Number 0 is not clear to me, likely this is when there is some real UEFI somewhere in MTD or so like on x86 PCs. From number 1 and 2 I have to guess what is SD-card and eMMC, but that is do-able. I am not sure where the loaded U-boot comes from. I have to write an own/other one on eMMC I think, and just make sure I know the version already from the file written with dd, not only from the bootlog via serial console.

I see Allwinner A20 is a mix of sun4i and sun7i as drivers in dmesg. I have only temp sensors on Allwinner H3 that is sun8i, at least I see other pinctrl there. My BPI M1 must run for a week or more for figuring out another problem, but at some point I could connect a 1-wire temp sensor and see what happens. I used direct editing of armbianEnv.txt What is in yours?

I managed to build u-boot-2024.10 with Btrfs for 32-bit (using systemd-nspawn). See: https://docs.u-boot.org/en/latest/build/index.html It would be more easy to do for native aarch64, but that I already knew when building for 'machine' 'qemu-arm64'. As example for my NanoPi-NEO, all in extra separate src/build folder: dpkg -L linux-u-boot-nanopineo-current - add/change CONFIG_CMD_BTRFS=y CONFIG_FS_BTRFS=y in nanopi_neo_defconfig make menuconfig and save the .config make -j8 - see platform_install.sh how and where to write the newly build u-boot-sunxi-with-spl.bin (about 570kByte, so fits in my MBR partition starting at sector 2048) So after merging boot files from the mmcblk0p1 Ext4 partition to a folder /boot on mmcblk0p2 Btrfs rootfs, I started fdisk and made Btrfs rootfs p1 (using the same start-end sectors), so only 1 partition. Same as you actually have on standard Armbian images. And comment out the line in fstab for mount of separate boot partition (or add nofail option maybe). Then reboot and restarted without problems. I did actually all via remote ssh, although i also had serial USB console cable connected as I wanted to see the boot log, but was as expected. A remark I saw was that it could not write environment to FAT. That is something I need to think about. Do I gain something if that is possible. Currently not on single OS SBCs for me I guess. A bootFAT might be more convenient for people who rely more or only on a Windows/MacOS computer as their main desktop. I use Linux so no issue with fixing SD-cards in case of non-boot because I messed up something testing or so. What went wrong afterwards is my backup script via ssh. For SoCs that use binary blob bootloader, I copy/compare/backup the first sectors till p1 (usually 2048 or so, so a 1 MiB file). That size determination went wrong, it created a 257MiB file in /tmp, so fails with a 512MiB SBC. But learning more now after 10+ years SBCs, I think I should do that smarter, just re-use platform_install.sh or so. I think I will have to look at 1st boot resize script(s). It is max SD-card, so all space gone for Ext4. I really hate that. Even more when done on fixed/soldered eMMC or NVME. Ext4 cannot be shrunk in a running system later on. Btrfs can, so last hack I did on an Ext4 downloaded image (RPiOS64 Lite) was double the image file, max Ext4 on that image and then convert to Btrfs with btrfs-convert. It also need kernel cmdline and fstab change still, but that is more or less it.

I know Ext4 and 1st boot resize is used, but I have manually recreated rootfs to be Btrfs. On NanoPi-R6C it is u-boot code in first 16M of SD or eMMC, then a 256M FAT32 partition with Image uInitrd DTB overlays. I made an extra script for update-iniitramfs to copy those for a certain kernel version to the FAT partition. In a qemu VM, I use a custom enhanced u-boot that has Btrfs support, so no bootFAT needed anymore. This should also work on real HW, The advantage of Btrfs for root is that you can move the rootfs from SD to eMMC (or NVME) I a live running system (btrfs replace start ...) At finish, only dd with u-boot loader to eMMC is needed. Then take out SD-card and done, no reboot needed, same rootfs UUID. Creating partition on eMMC is still needed of course, but can be just max of eMMC. Btrfs can always be shrunk later on in live system. So that is what I did several times also to install other OS variants in other partitions of the eMMC (and mostly NVME as that is much faster). I haven't looked in armbiam-installer. I know when selecting Btrfs as rootfs in builder, you get Ext4 for boot and Btrfs for root. This is what I use on NanoPi-NEO and BananaPi-M1 (created manually long time ago). Those don't have eMMC or SPI-flash and it works fine. But tempting to write a Btrfs enabled u-boot to the proper place at the beginning of the SD-card and merge Ext4 /boot into rootfs. I am a bit unsure about building 32-bit u-boot but i think i can temporary used systemd-nspawn of a 32-biit rootfs on RK3588 so fast building.

I have been reading various info mostly last 2 years on RPi forum, maybe scan https://forums.raspberrypi.com/search.php?keywords=libgpiod Many people don't want change so most is about keeping it the old way. I saw a warning in dmesg for 6.12.0-current-rockchip-rk3588 on my NanoPi-R6C. I don't use it there for own code, but do on a NanoPi-NEO to toggle an ON/OFF power-switch. Works still there for 6.6.44, but might be that some small C-program is needed in future, haven't looked at it further yet.

I see you use or need some GPIO in order to have audio device enabled. In newer kernel versions GPIO numbering will be sort of random and AFAIK this sysfs method will disappear. So I think for future, extra code is needed to find the correct GPIO and then also treat it like a character device. So open, close etc. See libgpiod for more info.

@DantesWhen I still had the original 2017 U-boot on the eMMC (from the OpenWRT that came pre-installed), inserting an SD-card with some recent Armbian image booted always from the SD-card. So in serial/debug console I had full control of the eMMC (and also an NVME in the M.2 slot). So that is also how I recently wrote a new/latest 2024 U-boot from the current-branch Armbian to the eMMC with dd. But that 2024 U-boot is more flexible and I needed quite some time to and figure out what was what (after stop autoboot prompt): 1 - SD-card with a known good simple basic Armbian Bookworm 2 - eMMC where the custom kernel did not work 3 - NVME with an EFI boot partition with grub.efi and some variant of openSUSE and some Debian flavor After reading U-boot command docs like 'bootflow', I somehow booted from NMVE. Fine but I want also operation with no NVME in the M.2 slot inserted. So eMMC and SD-card can be selected in U-boot but was a bit guessing as I had to rely on some addresses, so 3rd try or so I started the good simple basic Armbian Bookworm from SD-card and from there I could put a working kernel Image/uInitrd/DTB on the eMMC again. But what will happen if the somehow the U-boot on eMMC is corrupt? That has not happened, but when it would, will it then always somehow re-init and try SD-card? That is my point, that is why I thought I should also get to know USB loading, like I know from Android smartphones with fastboot tool. But you state: "Boot from sdcard with maskrom", that I had not thought of. Does that skip eMMC always? And scp? You mean the ethernet port(s) is/are up and running then? Or something over serial cable downloading what is known from simple old processor boards?