All Activity

Hello, I would like to add support for Milk-V Mars in the Armbian build system. Right now I am building for visionfive2(build boots fine with u-boot in spi) and intend to see if I can reuse the DTBs produced by the Milk-V Mars official SDK build(https://github.com/milkv-mars/mars-buildroot-sdk/releases/). I am looking for guidance on how to proceed. The board has the same SoC as the Visionfive2 but different peripherals (USB, m.2).

@voapilro oops, did you backup your original u-boot from the image? to restore this, you would need that u-boot backup. some u-boot bin files are customized with particular ways to start the kernel and that stored into u-boot that 1st 1 meg or so. For the standard u-boot, it uses files in /boot/boot.cmd or /boot/boot.scr in the Linux root partition to boot linux, that is normally the case for Armbian distributions

This is due to wrong cable being used: moin moin moin ( p1mon ) : duh therefore this topic can be removed as I will find proper AP9827 cable first...

Hi @prahal, Yes, for few weeks I took the habit to use the serial console to better understand whether the boot crashes or is stuck at some steps (I've got a long long network config step with systemd-networkd). The message appears after u-boot gives the hand to linux, and is part of the very first lines where linux checks the hard drive filesystem.

Thanks @ag123 for your help! I tried your u-boot image and I got a different error, probably because Debian image I have is different than yours, so I have to restore u-boot from backup. This is console output I got: I see some differences from u-boot of my Debian image, but I am not able to see what is wrong or missing. Here is normal console log to compare:

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... edit: board is one where BTOOTH seems like it works and WIFI does not due to new brcm chipset etc. etc.

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. I've created a 'sd image u-boot patcher' uploaded here in github gist: https://gist.github.com/ag88/cebfcd2bc1b413d2a0d43dafa6b572f0 usage: image-u-boot-patcher.py [-h] [--nobak] image uboot_bin patch u-boot binary into image positional arguments: image image file uboot_bin u-boot bin file options: -h, --help show this help message and exit --nobak do not backup image you need python3 to use that 'sd image u-boot patcher' https://www.python.org/downloads/release/python-3123/ it is a console app, which means that for Windows users, it'd need to be run in a Cmd prompt window. note: I've not tried running this in windows, only tested in Linux. This may help for 'Windows' users who may not have access to commands like 'dd' which is mainly available in unix, Linux. This is to that you can patch the image file directly and perhaps use Balena etcher https://etcher.balena.io/ or Rufus https://rufus.ie/en/ to write the image to an SD card / usb drive. 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-spl1_5gfix.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.