All Activity

This stream auto-updates     

  1. Past hour
  2. My Building experience... added: KERNELBRANCH='branch:orange-pi-5.1' BOOTBRANCH='tag:v2019.04' - (yes also tried with the latest version and came into same result below so wonder if I use the same kernel that runs on the other board) to build/userpatches/lib.config Run the command... sudo ./compile.sh BOARD=bananapim64 RELEASE=bionic BUILD_MINIMAL=no BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no INSTALL_HEADERS=yes INSTALL_PATCHES=yes CREATE_PATCHES=yes at the time it asks me for the mainline-kernel 5.1 to add my patch, I modify the "sun50i-a64-bananapi-m64.dts" file and add the second "sun50i-a64-cpu-opp.dtsi" needed file as well. it create the patch that I have shown a few messages back. compilation continue... than a bug... Building image : pkg-deb: building package 'linux-headers-5.1.21-sunxi64' in '../linux-headers-5.1.21-sunxi64_20.05.0-trunk_arm64.deb'. dpkg-deb: building package 'linux-libc-dev' in '../linux-libc-dev_20.05.0-trunk_arm64.deb'. dpkg-deb: building package 'linux-image-5.1.21-sunxi64' in '../linux-image-5.1.21-sunxi64_20.05.0-trunk_arm64.deb'. dpkg-buildpackage: info: binary-only upload (no source included) dpkg-deb: building package 'linux-source-5.1.21-current-sunxi64' in '/home/ilan/armbian/build/.tmp/linux-source-current-sunxi64_20.05.0-trunk_all.deb'. but after a while it want to install then into the image... but try to install not existent files... [ .... ] Installing [ linux-image-current-sunxi64_20.05.0-trunk_arm64.deb ] [ .... ] Installing [ linux-u-boot-current-bananapim64_20.05.0-trunk_arm64.deb ] [ .... ] Installing [ linux-headers-current-sunxi64_20.05.0-trunk_arm64.deb ] [ .... ] Installing [ armbian-config_20.05.0-trunk_all.deb ] [ .... ] Installing [ armbian-firmware_20.05.0-trunk_all.deb ] It doesnt install them since they are not exist on that name. So I have changed the files names to current and apply them just after the compiler create the Image file, that the script can find those files and install them… Ok... copy the image to the microSD and....... how lovely... after all the hours invested so far i get this present: U-Boot SPL 2019.04-armbian (Feb 21 2020 - 23:45:31 +0200) DRAM: 2048 MiB Trying to boot from MMC1 NOTICE: BL31: v2.2(debug):eda880f NOTICE: BL31: Built : 23:45:21, Feb 21 2020 NOTICE: BL31: Detected Allwinner A64/H64/R18 SoC (1689) NOTICE: BL31: Found U-Boot DTB at 0x4097918, model: BananaPi-M64 INFO: ARM GICv2 driver initialized INFO: Configuring SPC Controller INFO: PMIC: Probing AXP803 on RSB INFO: PMIC: Enabling DRIVEVBUS INFO: PMIC: dcdc1 voltage: 3.300V INFO: PMIC: dcdc5 voltage: 1.500V INFO: PMIC: dcdc6 voltage: 1.100V INFO: PMIC: dldo1 voltage: 3.300V INFO: PMIC: dldo2 voltage: 3.300V INFO: PMIC: Enabling DC SW INFO: BL31: Platform setup done INFO: BL31: Initializing runtime services INFO: BL31: cortex_a53: CPU workaround for 843419 was applied INFO: BL31: cortex_a53: CPU workaround for 855873 was applied INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x4a000000 INFO: SPSR = 0x3c9 U-Boot 2019.04-armbian (Feb 21 2020 - 23:45:31 +0200) Allwinner Technology CPU: Allwinner A64 (SUN50I) Model: BananaPi-M64 DRAM: 2 GiB MMC: Device 'mmc@1c11000': seq 1 is in use by 'mmc@1c10000' mmc@1c0f000: 0, mmc@1c10000: 2, mmc@1c11000: 1 Loading Environment from EXT4... ** File not found /boot/boot.env ** ** Unable to read "/boot/boot.env" from mmc0:1 ** In: serial Out: serial Err: serial Allwinner mUSB OTG (Peripheral) Net: phy interface7 eth0: ethernet@1c30000 Warning: usb_ether using MAC address from ROM , eth1: usb_ether starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 USB2: USB EHCI 1.00 USB3: USB OHCI 1.0 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 1 for devices... 1 USB Device(s) found scanning bus 2 for devices... 2 USB Device(s) found scanning bus 3 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 3033 bytes read in 2 ms (1.4 MiB/s) ## Executing script at 4fc00000 U-boot loaded from SD Boot script loaded from mmc 104 bytes read in 1 ms (101.6 KiB/s) 9444540 bytes read in 427 ms (21.1 MiB/s) ## Loading init Ramdisk from Legacy Image at 4fe00000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 9444476 Bytes = 9 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 4fa00000 Booting using the fdt blob at 0x4fa00000 Loading Ramdisk to 496fe000, end 49fffc7c ... OK Loading Device Tree to 000000004968b000, end 00000000496fdfff ... OK Starting kernel ... "Synchronous Abort" handler, esr 0x02000000 elr: ffffffffccee4000 lr : 000000004a002cf0 (reloc) elr: 0000000040e30000 lr : 00000000bdf4ecf0 x0 : 000000004968b000 x1 : 0000000000000000 x2 : 0000000000000000 x3 : 0000000000000000 x4 : 0000000040080000 x5 : 0000000000000001 x6 : 0000000000000008 x7 : 0000000000000000 x8 : 00000000b9f23a00 x9 : 0000000000000002 x10: 000000000a200023 x11: 0000000000000002 x12: 0000000000000002 x13: 0000000000000160 x14: 00000000b9f23a2c x15: 00000000bdf4e274 x16: 0000000000000020 x17: 0000000000000000 x18: 00000000b9f2bde0 x19: 00000000bdfe43d0 x20: 0000000000000000 x21: 0000000000000400 x22: 0000000000000710 x23: 00000000bdf4ed18 x24: 0000000000000003 x25: 00000000b9f85408 x26: 00000000bdfd3e48 x27: 0000000000000000 x28: 00000000b9f81d20 x29: 00000000b9f23b20 Resetting CPU ... resetting ... The only thing I can say now is: WHAT? WHAT WHAT?? WHAT WHAT WHAT??? WAHHHAHAAT??? WHAT WHAT, WHAT ?? WHAT? Really I have no other words to say. corona virus?
  3. u can add a code block inside the spoiler or what do u mean? // sent from mobile phone //
  4. Today
  5. Well, I don't want to point out something that went wrong, but on the contrary I want to emphasize all the things that went well. Having been disconnected from Armbian for some months, I can see a major improvement in the project's organization. Things like a predictable release cycle, tagged repo with all the releases, scheduling and coordinating, bug tracking... I can see a lot of work has been put into it, and IMO the results are excellent. So a big congrats to everyone who took part on it! Great job!
  6. Cheers ! Got the M3 with Apache, MariaDB, and vsftpd now gotta get it up and running with WordPress for my father.
  7. Would be nice to tweak the forum theme so that spoilers used code-friendly formatting
  8. We just pushed a few updates. you may want to download the latest lepotato image we posted today.
  9. Get DTB file from recovery.PARTITION file. Here is a second take a getting DTB file as extracting via /sys/firmware/devicetree/base using dtc didn't appear to work . This time get DTB from recovery.PARTITION file using termux. Firstly on a PC, download and unzip stock tvbox image. Then unpack firmware.img file with amlogic unpacker. Now transfer the recovery.PARTITION file to termux home folder. The DTB file is embedded in this file so now just extract it. I already installed git, python, perl and wget etc to termux. The resulting file was 76,302 bytes in my case from a magicsee N5 plus box. I still can't test yet because I haven't got it to boot from external storage but can confirm the dtc command worked on it. dtc -I dtb -O dts -o mybox.dts mybox.dtb Update: This also worked from a recovery image created by dd if=/dev/block/recovery of=recovery.img by using recovery.img instead of recovery.PARTITION and recovery.img.second.gz etc. n5plus.dtb n5plus.dts
  10. moved to p2p tech support.. I doubt this board will get any armbian support at all (except you make it happen on your own), there's no reliable reseller to buy them in quantities and therefore it doesn't really fit into rk3399 development.. I wish you the best to get something out of it.
  11. the RCs should be 'somehow' predictable.. e.g. for the linux kernel you know it's monday morning (europe) when the next one drops in how many RCs we have mostly depends on how smooth things go.. so it is possible that the releasedate is not always 100% clear.. I guess it's up to the release maintainer to decide when things are mature enough, but maybe we need a few 'must haves' and a few 'this will delay' defined (means if, it's important enough that it will delay a release).. the images which are finally released should be somehow reproducible.. something like ./compile.sh $RANDOM_FANCY_VARIABLE=release_2002 and it fetches exactly the sources which were used to produce the release (either over the armbian repo/sources) or by commit hash (which can be problematic from time to time, ask @TonyMac32 and the story of rockchip). So that someone who wants to build a 'know working' (in case it was tested for the board in question) image can build and patch on top of the release.. except the commits which alternate the rc numbers in the buildscript rc's should IMO have no commits which are not available in master as well so that after the release we can go 'back to work' without a discussion what we've to cherry pick from the release to work on master, this also means if someone wants to bring up a fancy feature during rc this must imo kept 'on hold' until the release is here.. Otherwise we end in the same mess as we had between master and our 'development' branch and all other attempts to have a 'stable' branch.. for sure stuff I didn't thought about yet..
  12. That's a shame as I am using the Orange Pi Zero LTS 256MB and the Orange Pi One boards only. I will try to contact Steven and ask if it is doable getting the external 32768 crystal on the(se) H2+/H3 boards.
  13. Some new ones : I've done tests on my OPiPC2, OPiZeroPlus2, OPi+2E, OPiOne and OPiLite which also don't have a external 32768 crystal, drifts are seen only on H3 but not on H5 ... Also, the H3 RTC drift is late/slow compared to H2+ of the OPiZero previously tested which were ahead/fast.
  14. Did you check out the Armbian-config? It seems weird to do it that way around, you want to donwload to emmc to boot from it? What about sd to emmc?
  15. FYI I am working to document things that went wrong / improvement areas... so please share those thoughts on this thread.
  16. That strange, you drifts is really bigger than mines, mines are 1 or 2 or 3 seconds per 2 minutes ... I've added "hwclock -w" before the loop and get the following results (not that I forgot to add UTC to "date") : Yes, it seems that a background process is doing "hwclock -w" in background, maybe every 12 minutes, as you said, most probably the ntp or chrony service ... BTW, I've the same test on my OPi3 which actually has an external crystal, no drifts at all ...
  17. I would say both at the same time? Whatever we are agreed upon, we are documenting here https://github.com/armbian/documentation/blob/master/docs/Process_Release-Model.md that we have a better process plan for next release. Thanks, noted. BTW. It seems my Teres have some hardware issues
  18. See the remarkable output below. Many observations and some questions: The internal RTC seems to be useless with the internal OSC. The internal RTC gets updated; once every ? seconds. From which source? What is the source for the date command? Specific which ARM Counter or with SoC Timer? This test is with an Internet connection; hence the system clock gets updated with the NTP Client. Interesting to know what happens with no Internet connection. pi@orangepizero:~$ cat ./rtc_test.sh while true do ./devmem2 0x01f00014 | tail -n 1 |rev|cut -f1 -d' '|rev | ./convert echo `date +"%H:%M:%S"` echo ============== sleep 120 done /* * convert.c */ #include <stdio.h> #include <stdlib.h> #define TIME_GET_SEC_VALUE(x) ((x) & 0x0000003f) #define TIME_GET_MIN_VALUE(x) (((x) & 0x00003f00) >> 8 ) #define TIME_GET_HOUR_VALUE(x) (((x) & 0x001f0000) >> 16) int main(void) { unsigned num; fscanf(stdin, "%x", &num); printf("%.2d:%.2d:%.2d\n", TIME_GET_HOUR_VALUE(num), TIME_GET_MIN_VALUE(num), TIME_GET_SEC_VALUE(num)); return EXIT_SUCCESS; }
  19. This is to discuss and prioritize enhancements and bugfixes we want to target for v20.05 (Kagu). We will lock this thread 2020-03-15 to manage scope creep. Many items are currently in Jira here https://armbian.atlassian.net/projects/AR/versions/10002/tab/release-report-all-issues If you're a frequent contributor and would like to join our Jira, please PM me. It's not mandatory, but it would make things easier. To track. Remember the Armbian Mission Statement: Armbian is a base operating system platform for single board computers that other projects can trust to build upon. Let's try to prioritize things that help us deliver on that mission
  20. If i'm not wrong, there is an ongoing development on a mainline kernel module called "meson_vdec" that should allow to take advantage (at least partially) of the VPU inside the soc to get hardware decoding. I also tried to get this module working with modprobe, but with no success. Probably a very cutting edge kernel is needed to get this working. Once this module starts to working, i think libraries like ffmpeg and gstreamer (and consequently the programs that use them) should take advantage of it.and consequently the programs that use them) should take advantage of it. There is also a guide on the Amlogic forum section to get hardware acceleration using some scrips, but, like the author says, it is for testers, not for daily use. I have not tried it personally.
  21. not sure how you'd manage the .debs for it.. but as u-boot... its just pointing to a symlinks to the different active versions.. so you can just modify symlinks lane@cranbone:/boot$ ls -l total 37442 -rw-r--r-- 1 root root 166 Feb 19 14:13 armbianEnv.txt -rw-r--r-- 1 root bin 0 Nov 20 2018 armbianEnv.txt.out -rw-r--r-- 1 root root 1536 Nov 18 2018 armbian_first_run.txt.template -rw-r--r-- 1 root root 230454 Nov 18 2018 boot.bmp -rw-r--r-- 1 root root 2970 Nov 18 2018 boot.cmd -rw-r--r-- 1 root root 4882 Nov 18 2018 boot-desktop.png -rw-rw-r-- 1 root root 3042 Nov 18 2018 boot.scr -rw-r--r-- 1 root root 168792 Dec 22 09:31 config-5.4.6-sunxi64 lrwxrwxrwx 1 root root 17 Dec 28 17:27 dtb -> dtb-5.4.6-sunxi64 drwxr-xr-x 2 root root 1024 Dec 28 17:06 dtb-5.3.9-sunxi64 drwxr-xr-x 3 root root 1024 Dec 28 17:06 dtb-5.4.6-sunxi64 lrwxrwxrwx 1 root root 17 Nov 23 19:03 dtb.old -> dtb-5.3.9-sunxi64 lrwxrwxrwx 1 root root 21 Dec 28 17:27 Image -> vmlinuz-5.4.6-sunxi64 -rw-r--r-- 1 root root 9418877 Feb 19 14:00 initrd.img-5.4.6-sunxi64 drwx------ 2 root root 12288 Nov 18 2018 lost+found -rw-r--r-- 1 root root 3381515 Dec 22 09:31 System.map-5.4.6-sunxi64 lrwxrwxrwx 1 root root 21 Feb 19 14:01 uInitrd -> uInitrd-5.4.6-sunxi64 -rw-r--r-- 1 root root 9418941 Feb 19 14:01 uInitrd-5.4.6-sunxi64 -rwxr-xr-x 1 root root 15685640 Dec 22 09:31 vmlinuz-5.4.6-sunxi64
  22. @Igor I found why anx6345 mainlined in 5.5 doesn't work on TERES-I. https://github.com/Icenowy/linux/commit/e20b4f7fade6a7305599aa8e279c013c3144226b an overflow bug.
  23. Hi, i own a Libre Computer Le Potato (AML-S905X-CC) board and i would like to compile my own customized kernel to try patches for bug fixing and experimenting unstable "features", like lima driver. The problem is that i currently use this board as daily driver and i would like the possibility to have a backup kernel (a stable one) in case something goes wrong. So the question is: it is possible to have multiple installed kernel and decide which one boot (like GRUB behaviour) using the uboot bootloader? If it is impossible, i'm sorry for the stupid question. I don't know how exactly the boot sequence works, from a low level point of view. Thanks a lot for the attention and the dedicated time.
  24. In fact, this URL is completely obsolete, it is a snapshot of code from 4 years ago ... The current Mainline is here : https://github.com/torvalds/linux/blob/master/drivers/rtc/rtc-sun6i.c But they still don't check the LOSC_AUTO_SWT_STA_REG register ... EDIT: I've done few tests with measurement at 8 minutes intervals, it is loosing/gaining around 8 seconds / 8 minutes, but since it is both loosing/gaining, overall the average should be good.
  25. @keynote. Shame the dtb not working . Probably need some python/perl script to parse the dts file Not all boxes are equal, Is there a bootloader partition? This should list all emmc partitions ls $(find /dev/block/platform/ -name "by-name") su dd if=$(find /dev/block/platform/ -name "by-name")/bootloader of=/sdcard/bootloader.img Or try TWRP backup function. Apply zip file using update app or from recovery mode (this will not overwrite your stock recovery). TWRP_3.2.2_Android_9.0.zip
  26. Therefore I am also showing the seconds from the date command. I will do another test. However, the apt update/upgrade I just did, it broke the startup.
  1. Load more activity