All Activity

hmm once cable is attached it does report FTDI USB Serial Device converter is attached, however apcupsd does not want to comm. with my APC Back-UPS 650, so either Modular or compiled in does not resolve my issue. [160575.289133] usb 7-1: new full-speed USB device number 3 using xhci-hcd [160575.444894] usb 7-1: New USB device found, idVendor=0403, idProduct=6001, bcdDevice= 6.00 [160575.444943] usb 7-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [160575.444966] usb 7-1: Product: FT232R USB UART [160575.444985] usb 7-1: Manufacturer: FTDI [160575.445003] usb 7-1: SerialNumber: AL[hidden] [160575.453241] ftdi_sio 7-1:1.0: FTDI USB Serial Device converter detected [160575.453585] usb 7-1: Detected FT232R [160575.455687] usb 7-1: FTDI USB Serial Device converter now attached to ttyUSB0

Thanks!, saved me significant messing around. Generic-ish "T95MAX"(lol) here, 4GB... bridged UART rx FET Source Drain but no luck with that... mounted SD to setup some credentials. Don't really use HDMI, BTOOTH, WIFI(rarely) but I owe you(s) one so if you need something let me know...

I do not use quotas, so the fix for this issue is: https://github.com/openSUSE/snapper/issues/894#issuecomment-2054220427

Yes it needs to be low and then the broadcom dongle host driver needs to search for any hw on the sdio, which fires the init seaquence and enables the wifi module. This dhd is for some reason not started during boot.

Thanks @FRANK333 , I actually have an orange pi too so bookmarked that guide. For future readers: As for changing u-boot on Le Potato, I just followed https://docs.u-boot.org/en/latest/build/gcc.html https://docs.u-boot.org/en/latest/board/amlogic/libretech-cc.html they've guides for lots of boards. Everything seems to work so far as I was able to boot into armbian. Also, I recommend getting a USB U-art cable and using the terminal program minicom so you can see what happens during u-boot and with timestamps

Alright, thanks again to the replies ! I followed the u-boot guides and it worked out ! "make menuconfig" let me change the environment variable I wanted to. Compiling took just a few minutes. I did the dd commands from the guide and was able to boot the board. Armbian is intact, no issues.

Not sure 'AI' is the answer, this requires actual embedded dev skills. I have (lame) news tho. I gave the box away. A family member needed a TV box and the Tanix is doing that now. Giving up is kinda lame I know but there were good reasons for it. Mostly that the box is pretty much undocumented except that it has an rk3566 on it. This and that the manufacturer seems to have no interest in open source support and never replied to repeated attempts of getting some documnetation, SDK etc. The idea was to teach myself SBC embedded linux/android and reverse engineering seemed interesting at first but ialso maybe not the best way to learn. In the end it didnt seem worth the effort. I bought a firefly rk3566 instead, stationpc m2 instead. Well documented board with NVME interface, good wiki/docs, Android and Linux SDKs on gitlab, plenty of tools and firmware to play with. It's a much more rewarding environment for a developer to learn. Sorry if I disappointed people replying, trying to support here. Thanks in any case!

If the issue is that the cpu frequency is switched too fast and I can reproduce the crash with a regulator-ramp-delay of 1000, then there is no point in testing anything above 1000 that will make the issue worse. regulator-ramp-delay is badly named. It is not a dealy it is a divider for the delay. The greater regulator-ramp-delay the fastest the transition (I believe the Kobol team made this mistake, but as I also believe the issue could be otherwise than the delay between transitions this is not a big deal). I still have not tried with a lower than 1000 value for regulator-ramp-delay (ie without tweaking the opp voltages as I am currently doing).

@ebin-devI believe initramfs messages are not written to syslog. @Trillien you see that message on the serial console? /usr/share/initramfs-tools/scripts/local-bottom/mdadm is part of the mdadm package which pcakaged by Debian. "dpkg -S /usr/share/initramfs-tools/scripts/local-bottom/mdadm", "apt policy mdadm" Though it could be the fact that the generated initramfs lack/bin/rm is armbian specific. You might want to open a bug against armbian or at least open a topic in the forum. But nothing helios64 specific as far as I know. Could even be a Debian bug. I don't even know if we ought to fix this missing /bin/rm for mdadm at the board level, even as a workaround.

could you try my older test case code: Turns out I did not compile my test case anew before pasting it to github gist and could be the new one I pasted there is not testing what I expected (in that it could be I changed it to try testing CPU frequency changes from max to min instead of each step). Mind I use a binary of the test case I made long ago for my tests which is the one in the link above. I did not feel like sharing a binary test case was a good idea. I prefer you to be able to audit the code (or have someone audit it for you). , I did not have much time to devote to sharing my findings so I checked the source was fine but not if the test was the same as the one I used on my side to stress test the big cpu. Sorry. It looks normal for you the test case I shared to you working fine as as far as I know 1.8GHz 1.2V and 408MHz at 825mV are pretty stable. They could crash I am not sure of that, but it would take more than 50 runs of the test for it to happen (at least it took 80 of them for the 600MHz to fail at 825mV). Mind you should do at least 5 runs of the above test case to be somewhat confident you cannot get the cpu b to crash. The fact that it does not crash is not the point of the test. Its usefulness is that it nearly always crashes the big cpu on the first run. EDIT: the previous gists I gave you as a test case was my v1. The current test case is https://gist.github.com/prahal/8fab73325eb0d7091ad7c4627bf8e25a which is in the other thread I linked in this comment.

Hi, I've been using the /dev/ttyAML1 UART port on my Odroid N2+ at the GPIO pins 8 and 10 with buster. With the update to bullseye, the /dev/ttyAML1 device disappeared. Also now in bookworm it is no longer present. Now I happen to need the UART at GPIO 8 and 10 again and did some more persistent research and came across this post over in the DietPI forum. It provided an alternative meson-g12b-odroid-n2-plus.dtb which I installed in my system. Since then my /dev/ttyAML1 device is back and I can use the UART at GPIO 8 and 10 as I wished. However, I am a bit nervous, since I just installed some binary dtb file to my system at a path which is owned by the linux-dtb-current-meson64 package. So it is endangered by a system update. Is there an "official" way to get back my /dev/AML1 UART device which is sustainable? Thank you very much

Hi, to my side same: root@helios64:~# cat /var/log/syslog | grep mdadm root@helios64:~# and, for moment not crash/freeze to my helios64...

Hi @Igor. All the above are 5 commands?

Sorry for the confusion. For the moment I'm using it with original android firmware. I tried the build suggested by user blustOne (above in this thread), booting from SD card, GPU has signal output but seems not to have HW acceleration for playback (it loads the file, but stutter/choppy playback). Also no sound through HDMI port. I'm tring to first dump the entire firmware of the device. I don't want to get it bricked because of playing with it. Once I can dump it, I will try to play with the armbian variants, try to build my own, etc. I have never done this and I know I have a long way ahead reading and learning (and no much time), just I want to start with the backup. I will also try to debloat the android version. I'm using it connecting a flash drive with videos, I connect it to internet as little as possible, it has many bloatware that I'm not sure of what thing it can cause in my private network. Probbaly i'm worring too much about it? ..

Dear All, I get frequent and random disconnection from orangepizero3 onboard wifi with armibian community (self-built) both trunk and 24.02 current kernel, 6.6.26 and 6.6.28 message is always [21738.338021] sprdwl:sprdwl_fc_add_share_credit, 536, mode:1 closed, index:0, share it [21848.116072] sprdwl:sprdwl_fc_add_share_credit, 536, mode:1 closed, index:0, share it [21915.426734] unisoc_wifi unisoc_wifi sta0: sprdwl_report_connection sm_state (5), status: (2)! [21915.426817] unisoc_wifi unisoc_wifi sta0: sprdwl_report_connection Vodafone-CSC failed status code:1! [21919.477424] sprdwl:sprdwl_fc_add_share_credit, 536, mode:1 closed, index:0, share it [[21738.338021] sprdwl:sprdwl_fc_add_share_credit, 536, mode:1 closed, index:0, share it [21848.116072] sprdwl:sprdwl_fc_add_share_credit, 536, mode:1 closed, index:0, share it [21915.426734] unisoc_wifi unisoc_wifi sta0: sprdwl_report_connection sm_state (5), status: (2)! [21915.426817] unisoc_wifi unisoc_wifi sta0: sprdwl_report_connection Vodafone-CSC failed status code:1! [21919.477424] sprdwl:sprdwl_fc_add_share_credit, 536, mode:1 closed, index:0, share it Full logs available at armbianmonitor -u Any help/hint/solution deeply appreciated

can't confirm (my system is now based on Armbian 23.5.4): # cat /var/log/syslog | grep mdadm #

i'm using RFkill command $ rfkill ID TYPE DEVICE SOFT HARD 0 bluetooth hci0 unblocked unblocked i'm switching DTB on this board to test, and I think the problem was on the new DTS file that dont work. also the old 6.2 DTS file dont boot on 6.6 kernel rk3566-firefly-roc-pc.dtb rk3566-h96-tvbox.dtb rk3566-h96-tvbox.dts rk3566-firefly-roc-pc.dts I think gpio2 PB1 on wifi need to be ACTIVE LOW Will test it tomorrow This device tree without board project is hard to fix i'm testing and this pin is tricky it has gpio low and pull up

Glad to hear you got it working. I've gone through the same issues you had in the past when trying upgrades, so the steps were in the back of my mind. It should be fine to now remove the obsolete packages.

ok just an update, I managed to get past that '1.5GB' issue the hack is done in u-boot, but the bad news is that that alone won't fix things: This gpu over temperature is nonsense, the chip is hardly warm and this same image boots just fine on a 2GB device with the 'standard' u-boot. It'd seem that some other things is at play here, e.g. that the registers for 1.5GB model are after all different and may need a different DTS configuration. I don't have a solution to go forward for now for 1.5GB devices, configuring DTS takes much more than this little hack, in the sense that we'd not know if this gpu thermal thing is the only odd thing or that there are other things that needs to be fixed as well. -- for those who insist if you would like to test this solution, the attached file is the modified u-boot compiled from https://source.denx.de/u-boot/u-boot https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/mach-sunxi/dram_sun50i_h616.c?ref_type=heads#L1353 the function arch / arm /mach-sunxi /dram_sun50i_h616.c function mctl_calc_size() is modified as: static unsigned long mctl_calc_size(const struct dram_config *config) { u8 width = config->bus_full_width ? 4 : 2; /* 8 banks */ unsigned long long memsz = (1ULL << (config->cols + config->rows + 3)) * width * config->ranks; log_info("detected memsize %d M\n", (int)(memsz >> 20)); /* 1.5 GB hardcoded */ memsz = 2048UL * 1024UL * 1024UL * 3 / 4; return memsz; } i.e. that 1.5GB is *hardcoded*, obviously this won't be appropriate for most boards except in particular case of 1.5GB. Initially, i placed an if statement that says if the detected ram is 2GB say that it is 1.5GB, that is bad as well as then 2GB boards will simply read 1.5GB. however, during tests, I noted that the detected dram size varies between 2 GB and 4 GB. my guess is there are timing issues associated with the 1.5GB dram chip, hence I resorted to hard coding which does not bother how much dram is really detected. if you prefer to build u-boot from sources, follow instructions from here: https://docs.u-boot.org/en/latest/board/allwinner/sunxi.html To use this modified u-boot, the best practice is to start with / use an image that is known to work on 1GB / 2GB / 4GB Orange Pi Zero 3 boards. assuming that your image SD card is mounted at /dev/sdX, you can backup your existing u-boot e.g. sudo dd if=/dev/sdX of=u-boot-backup.bin bs=1024 skip=8 count=1024 that should backup the u-boot in your device to u-boot-backup.bin then to write the modified u-boot into the SD card it is (be sure that you are writing to the correct device ! mistakes here can corrupt your existing hard disks / storage) sudo dd if=u-boot-sunxi-with-spl.bin of=/dev/sdX bs=1024 seek=8 it may be possible to write that to an existing image file (do backup your image file beforehand) dd if=u-boot-sunxi-with-spl.bin of=file.img bs=1024 seek=8 conv=notrunc but that I've not tried this. and note this is caveat emptor (let the user beware, use at your own risk), there is no assurance if after all it fixes anything or break other things. u-boot-sunxi-with-spl.bin

This make Mac Book Air 2010 (Snow leopard) a breeze to Leo Tux ..just the trackpad is crazy but I used a mice - Big thanks to all the Armbian Team! YOUPIE OH!! Cheers SoSie.

It is a twofold problem. First is a base definition compiled with kernel itself, which has to simply put a LUT which ID loads which driver bin file. If it is not there, you will see a dmesg error message. So if this is not recompiled with kernel itself it won't even try to load a bin file nor will it throw any error messages. Can you check if the kernel sees any new hw device IDs?

So it was a success. Version information updated too now But it did want to both uninstall and update armbian-bsp-cli-orangepiplus after updating armbian.list file and running apt update/upgrade Do you think it is safe to autoremove them if the system is up and running? I am so happy I managed to fix my junk from 2015.... It is probably a $30 board from china. But there is just something about making old hardware work for as long as possible. Thank you all!

Seems to be a kernel thing that has changed... Made me curious and I found this: https://forums.raspberrypi.com/viewtopic.php?t=325309 Obv not a solution for you since the tread is about rpi OS (but other hardware outside of rpi is actually mentioned). You might get some good info on how to move forward reading that. I do not know how to do this on armbian. Maybe you can use x11vnc (I have no idea if this exists in the repos) and set the resolution as described here (very old thread): https://stackoverflow.com/questions/12050021/how-to-make-xvfb-display-visible/40678605#40678605 Or maybe you can do the solution mentioned here, where you get a cheap usb > hdmi adapter for a few $$ that fools the SBC that it has a monitor connected.

nightly kernel? I think you are talking about nightly releases that are not yet stable or tested. Unfortunately I don't have time to test kernels and wait for any bugs.

==> shrink-backup v1.0 <== I have made the decision to not deal with other partitions than boot and root for the 1.0 release. Instead I introduced the --loop function to let the user expand the img file using the [extra space] option and then manually create partitions by running for example: sudo gparted /dev/loop0 in a terminal to edit partitions in a graphical interface using gparted. I want to give the user freedom, but I also have to stay true to my initial plan with this script: a very fast utility to create a bootable img file from the system and subsequently keep it updated. I haven't dropped the idea of at least handling /home completely, but the script goes from "kinda basic functionality" to "advanced script" pretty fast when I start working on the feature. If I do this, I still want the script to be as easy as possible to use, but at the same time give power users the ability to fine tune, ie a lot of work. Features in the release: Introduction of --loop, --fix & -z (zoom speed) Now crosschecks fstab with lsblk for certain operations. Changed MB to MiB etc. Old habits die hard. Will now, if needed, check and/or ask for installing gdisk on debian and arch based systems. GPT partition table now supported Various bug fixes. I hope you find it useful!