jock

Hello! There was an ancient bug with lightdm-gtk-greeter that was behaving the way you describe. Maybe it is an old image? You could try to upgrade the packages using apt and see if it gets fixed, otherwise you may install and configure slick-greeter which was the solution adopter in armbian to workaround the bug.

Don't use my driver, it is half-baked and for testing only. Use the original one.

@MarcoFdN I updated the debian bullseye image and the upgrade packages to include the fix for bluetooth and rk3318-config script.

@lucky62 unfortunately the openvfd driver does not comply at all with the standard linux led framework, so you can't use the triggers like what you would do straight away as like as other leds. Openvfd driver forces the need for the userspace process to control the leds. You may also want to write your own userspace code to control the leds the way you like, but triggers are provided by linux kernel and what you can do is just "simulate" the same behaviour in userspace. In practice, the openvfd driver needs quite a bit of refactoring to be more standard compliant.

Yes, you're right! rk3318-config should check for mmc4 and not mmc3, I will fix in the next release. Thanks for spotting this! The error messages are from brcmfmac driver are expected and a bit misleading: it tries to load those firmware files, can't find them and goes further, but then it leave you with no success message, so the user thinks that some firmware is missing, but it is not. It was confusing for me as well. Everything seems in the right place to me, both wifi and bluetooth, and everything should work right fine, but looking better I missed to copy a patch from 5.10 tree into 5.15: https://github.com/paolosabatino/armbian-build/blob/rk3318/patch/kernel/archive/rockchip64-5.10/general-workaround-broadcom-bt-serdev.patch this issue was one of the most bastard things ever, and it still keeps biting the ass I'll fix this other thing and rebuild kernel soon!

@MarcoFdN Yes, armbian-config is not included in any Armbian minimal releases (not just mine), because if it was it would not be minimal anymore: armbian-config requires lots of dependencies and, for this reason, it is undergoing a vast refactoring which I don't know when it will be ready. In the meantime, no armbian-config for minimal images. Plus minimal images are for more experienced debian users, since target is server-like tasks. dmesg log is essential for such issues: x88 boards have wifi over "external" sdmmc controller, thus rk3318-config should already have warned you that you had to configure, reboot and then run again rk3318-config to get wifi and bluetooth detected and working. wifi can be configured either from command line with nmcli, but also with nmtui which provide a nice and simpler text-based UI even on minimal distros.

Not a wise thing to do at all. Kernels are different, kernel configurations are different, there is no reason at all to use the same device tree, even because the device tree for the multitool is made for maximum compatibility and enables only the essential devices; armbian device tree is also made for compatibility but to be completed with overlays to enable the needed functionalities per-board. Don't do it, it's a bad mistake.

@Zippy Glad to hear it works! For bluetooth there is the need for some more bits in the kernel config and a device tree overlay. Everything is already working for rk322x board series so I need to find some time to transpose the things on rk3318, hoping it works the very same way. You may find some instructions here and there to get bluetooth up and running using only userland applications for realtek. I'm not experienced with realtek, but I can say that for broadcom it required quite a bit of time to get things squared out.

Minor upgrade! Not so many fancy things, this time, but those interested in rtl8723cs, rtl8703bs and ssv6051 wifi chips may give a look into! I upgraded the Debian Bullseye Minimal image (not the others) to kernel 5.15.16 kernel. Also deb packages have been updated for manual upgrade to avoid system reinstall (instruction on first page, as usual). @Zippy may be particularly interested in this. Enjoy and give feedback!

@MattWestB Could you please test rk322x-box.dtb attached here and overwrite the one that comes in the multitool fat partition? This has the emmc clock set to 50MHz, it would be nice to know if this setting let the multitool recognize the eMMC correctly on your box rk322x-box.dtb

@MattWestB Glad to hear your experiments did well! rk322x-config won't work if you do tricky things with the bootloader, since u-boot applies the device tree overlay rk322x-config configures. The u-boot in multitool is not made to do so, so whatever you choose, it will just be ignored. The nice thing is that the eMMC is getting detected and appears to work fine at 50MHz frequency. This is weird too, but it's fine. I guess it does not like 37.5MHz at all, so maybe it is time to raise the frequency to 50MHz in Multitool and forget about it. Anyway, you could test the eMMC just doing dd and reading some megabytes of data, but usually when it gets detected correctly it works fine (if it is not broken). If you want to erase it, I suggest the command blkdiscard /dev/mmcblk2 which is way faster than dd because it uses the eMMC commands to invalidate the pages instead of zero-filling the whole content. You could although do a full backup of it first using the usual dd command. To me, your eMMC looks fine. I mean: Android is booting fine, so there is no reason to guess that it is faulty at all. Multitool is just not able to detect it because of some reason (probably the operating frequency, but can be also a bug in the kernel 4.4 code...), but that does not mean anything since these eMCP modules are a "recent" hardware addition and I could not test hardware compatibility.

@MattWestB What what I see from the log of the original firwmare there are some weird things: the firmware is very old: ddrbin v1.06 is the oldest going around. Other boards that have appeared here on the forum have ddrbin v1.09 and I ship v1.10 with armbian: this does not change much, it's just weird the original firmware has the eMMC part of the eMCP configured to run at the slowest ever frequency of 31.5 Mhz Oldest boards have that frequency to 37.5 Mhz. but practically all eMMC chips around support at least 52Mhz. This is strange too, this may be the reason kernel is complaining about the eMMC when running the multitool. If so, that would be very sad because either the eMMC is crap or the board is crap too. There could be some missing setting for your board in the dtb that maybe fixes the situation About the partitions, if you take a look to the kernel command line of the original firmware: [ 0.000000] Kernel command line: vmalloc=496M psci=enable rockchip_jtag console=ttyFIQ0 androidboot.selinux=permissive androidboot.hardware=rk30board androidboot.console=ttyFIQ0 init=/init mtdparts=rk29xxnand:0x00002000@0x00002000(uboot),0x00004000@0x00004000(trust),0x00002000@0x00008000(misc),0x00000800@0x0000A000(baseparamer),0x00007800@0x0000A800(resource),0x00006000@0x00012000(kernel),0x00006000@0x00018000(boot),0x00010000@0x0001E000(recovery),0x00020000@0x0002E000(backup),0x00040000@0x0004E000(cache),0x00008000@0x0008E000(metadata),0x00002000@0x00096000(kpanic),0x00400000@0x00098000(system),-@0x00498000(userdata) storagemedia=emmc uboot_logo=0x02000000@0x9dc00000 loader.timestamp=2019-04-04_11:13:45 hdmi.vic=65536 tve.format=1 SecureBootCheckOk=0 you can see that they are specified right there after mtdparts argument Other errors are not really errors, in particular the HDMI IRQ error message appears on all the boards where mainline kernel is running, but that does not prevent HDMI to work right. Maybe I can prepare a dtb to run the eMMC at 31.5 Mhz to see if the multitool is able to give you access to it. It would be interesting to know what is the problem that prevents the eMMC to run at full speed though.

Much better, I totally forgot about nand-sata-install script, mostly because I never tested it on rk3318 boards

"Loader" is a composition of various pieces that do various boot things, so the concept of "standard loader" does not exist here. There are several versions of each piece that can be combined together and rk322x_loader_v1.10.256.bin is simply a loader that is made up of the latest available bits at the time I put them together. But you should not end up using it if you don't do bad mistakes. Writing an armbian image into eMMC without prior testing it can be such bad mistake. By the way, you may want to test that loader if it works for you. Once the eMMC is erased, give power to the board without any sdcard in the slot. The board will be in maskrom mode, so you can run the command: rkdeveloptool db rk322x_loader_v1.10.256.bin and this will just boot the board with the loader. db command does not write anything to the eMMC, so you're safe enough, then you could run other rkdeveloptool command to get some info like flash info, chip id, etc... if they work, then that loader is compatible. If you get the serial port working, you would also read the loader messages. Just unplug the power when you're done. Well that depends on the original firmware design... some firmwares don't have a proper partition table at all, but have that "PARM" section somewhere on the eMMC with a string that is a hardwired "partition table". Proprietary u-boot read that string and passes it to the kernel command line, then the kernel spawns partitions at those positions on the eMMC. This is rather hacky and proprietary way, I guess it has been dropped in u-boot for libreelec, hence you don't get any partition when you boot libreelec. Take this as a grain of salt, that's just my guessing. Ok, this is one of the "bad mistakes" you can do I mean: you can proceed to burn armbian on eMMC, but first you must test if the image works for your board: erase the internal eMMC boot the armbian image from sdcard be sure armbian image boots without issues That's because the very very first piece of code of the loader (the ddrbin) initializes the DRAM memory. If it is not compatible with your RAM, it will just freeze the board. If so, your board is bricked and the only chance is to enter maskrom mode, but entering maskrom mode requires to short the clock pin on the eMMC. You have an eMCP chip, so where is the clock pin? And the answer is... "we don't know!". You may now guess that if you get in troubles this way, you're almost on your own. The original device tree is useful but alone it is not enough to bring HDMI up. For that I would require to have such a board in my hands, there are tests to be conducted which cannot be made without the hardware. As much as I could tinker with the dtb, how can I have the feedback of a working HDMI? If we're lucky, the issue is in the dtb and it "just" requires a careful inspection, but if not it may require kernel recompilations, dozens of reboots, hours and hours of work, ...

Well not just the kernel, but the whole rootfs must sit on SSD. Plus if you cloned you sdcard on SSD, both sdcard rootfs and SSD rootfs have the same UUID, and this may confuse the kernel about which rootfs use at boot. This is pretty normal if you think about it: how does the kernel can know if you want to boot from sdcard or boot from SSD when both contain the same bootable system? The rootfs UUID is specified in /boot/armbianEnv.txt. There are several approaches: You clone the sdcard on SSD, then you remove the rootfs partition from the sdcard Install just the bootloader on the eMMC erasing the eMMC and then copying the first 4 megabytes of the sdcard (/dev/mmblk0) on the eMMC (/dev/mmcblk2) Change the UUID of the sdcard rootfs, but this will prevent the sdcard rootfs from full boot The most clean approach is #2, taking in account that you should not plug both sdcard and SSD at the same time when the same cloned filesystem is on them for the usual UUID reason of above.

@MattWestB I saw your pictures, but it would be wise to put a picture of the whole board itself. I see that you already have spotted some serial port tx and rx pins since I see some serial logging, or am I wrong? According to Micron Part number decoder, your eMCP is a MT29TZZZ8D5BKFAH-125, which is a 8 gigabyte eMMC + 8 gigabit LPDDR3 part. Datasheet is under NDA, but at least general specs are available on micron site: https://www.micron.com/products/multichip-packages/emmc-based-mcp/part-catalog/mt29tzzz8d5bkfah-125-w It is definitely not a samsung part, but probably the tool is just reporting a wrong thing because it is not aware of such part. I have little experience with tools for Windows, I usually use rkdeveloptool for linux to dump the internal eMMC or write images directly to eMMC. I DON'T suggest you at this stage to write directly on eMMC. You should do a backup of the internal eMMC and be sure your backup is sane: data is there, partitions are there: your backup should not be filled with zeros of 0xff's, you should get a PARM structure starting at sector 0x2000 (or somewhere else...). Then you may even proceed to erase the eMMC to force to board to boot from sdcard. There you may run either LibreELEC or Armbian. Armbian has ssh access enabled by default, credentials are root:1234 on first boot. But still I miss the point of doing so: you still won't get any HDMI output until the source of the problem is discovered and addressed properly.

First post: there is a list of things useful for support and debug.

No simple instructions for such task, you need quite a deep knowledge of both u-boot and platform to get something usable. If I have to tell you where to download u-boot probably you won't be able to do anything with it (it is available on github anyway)

Of course, you need u-boot installed in emmc or sdcard to boot from USB. AFAIK no rockchip chips are able to boot from USB on their own, just eMMC, NAND (<- not the rk33x8 case) or sdcard

You have to ask u-boot people about. Honestly I don't know the current state of USB 3 port in u-boot, I didn't go deep into the matter. It is strange it does not even work in USB2 mode, maybe there is something missing from the dtb but cannot be sure about.

Good!

This is clearly stated in rk3318-config.sh if you paid attention to what the script tells. In particular, it tells you that if you have issues, you should NOT activatate those options and you have to try what's best for you. USB3 driver is what it is, I guess all rk3328 boards have same or similar issues. 🤷‍♂️

Probably you are right, from a quick check I see v1.15 on multitool, got to update it there, but at the moment I am a bit busy elsewhere. You can write a backup image from a running system from sdcard, for example: if you have a properly armbian image installed on eMMC, you can write the image with gzip and dd command. Something like this would be suffice: gzip -d backup.gz | dd of=/dev/mmcblk2 bs=512k iflag=fullblock oflag=direct status=progress That is strange, I see v1.16 (yours) is in use for the armbian image.

@boyshongke photos are not very well detailed and signatures on wifi chip and quartz are not readable at all. You should take a closer look (maybe you need a magnifying lens) and see if you read "37.4", "26.0" or "24.0" or whatever on the quartz (it's the smaller "chip" nearby the bottom left corner of the wifi chip).

A very detailed photo of the board may come useful, in particular the area around the wifi chip and its quartz clock generator. Usually these kind of issues come from a bad nvram firmware file.