• Content Count

  • Joined

  • Last visited

About 5kft

  • Rank
    Elite member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Interesting...this reminds me of a post from my OrangePi overclocking thread: https://forum.armbian.com/topic/6866-orange-pi-zero-plus2-h5-hardware-oddity-in-vdd_cpux-power-circuit/?do=findComment&comment=52485, where @Da Xue notes:
  2. Yes these look quite familiar... It'd be great if they were pushed upstream, it could reduce our patchset size. I wonder why they were never taken?
  3. @sfx2000 Well, considering where this all started, it is great to see it stable at least If you're interested, we could try clocking the CPU at 1.1GHz at 1.3v. Let me know and I could create a test overlay.
  4. Strange...I would imagine that it should have some stability at a higher clockrate and 1.3v CPU VDD... Luck of the draw...?
  5. Just to make sure...this is a v1.1 board, correct?
  6. No problem - whenever you get a chance. If it doesn't work, it'd be helpful to verify that this test bootloader was properly flashed/booted.
  7. @sfx2000, unfortunately I can't repro any crashes at 1.2GHz (w/the DDR clock at 504MHz)...but after some quick searching it seems that the original FA H5 clock default was 408MHz. Could you try the attached bootloader? This version has the DDR clock lowered to 408MHz. Install it via my instructions above, and make sure the bootloader was written to flash correctly by checking the build date in the console when it boots ("Mar 09 2020 -14:48:34"): U-Boot SPL 2019.10-armbian (Mar 09 2020 - 14:48:34 +0000) DRAM: 512 MiB Trying to boot from MMC1 NOTICE: BL31: v2.2(debug):03ea84c-dirty NOTICE: BL31: Built : 14:47:31, Mar 9 2020 NOTICE: BL31: Detected Allwinner H5 SoC (1718) NOTICE: BL31: Found U-Boot DTB at 0x4094d90, model: FriendlyARM NanoPi NEO 2 INFO: ARM GICv2 driver initialized INFO: Configuring SPC Controller NOTICE: PMIC: Assuming H5 reference regulator design INFO: BL31: Platform setup done INFO: BL31: Initializing runtime services INFO: BL31: cortex_a53: CPU workaround for 855873 was applied NOTICE: PSCI: System suspend is unavailable INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x4a000000 INFO: SPSR = 0x3c9 U-Boot 2019.10-armbian (Mar 09 2020 - 14:48:34 +0000) Allwinner Technology CPU: Allwinner H5 (SUN50I) Model: FriendlyARM NanoPi NEO 2 DRAM: 512 MiB MMC: mmc@1c0f000: 0 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 NanoPi NEO2 v1.1 detected Net: phy interface7 ... It'll be interesting to see if this makes a difference...! linux-u-boot-current-nanopineo2_408_MHz_20.05.0-trunk_arm64.deb
  8. How are you managing power to the GNSS radio and the LTE modem? If you're just sending the GNSS data out over the LTE modem, it seems like you could use a simple MCU w/a couple of UARTs to interface with the radios (i.e., a whole SBC as the bridge seems like overkill...?).
  9. I'm not clear about your use case...does your SBC-based solution need to be powered off of a battery?
  10. By default the Fire3 doesn't really have a "sleep" mode per se; it's actually powered off. The PMIC MCU always remains powered via the USB and will power the system back on (resulting in a cold boot) after the wake timer expires or when the PWRKEY button is pressed. In the powered-off state, my board draws about 15mA via the USB power interface (measured with a Ruideng UMC25C) - so it's actually drawing quite a bit of current. From what I can tell, the RTC battery is only used to power the RTC in the S5P6818. (However I don't have a LiPo and haven't tried this feature at all.)
  11. Changes checked in: https://github.com/armbian/build/commit/42201fd3fc1386c6dc8785c4f85db35289bfe2db After building a new u-boot, you can copy it to your board, then install it to the filesystem via "dpkg -i ...": root@nanopineo2:~/tmp# dpkg -i linux-u-boot-current-nanopineo2_20.05.0-trunk_arm64.deb (Reading database ... 33567 files and directories currently installed.) Preparing to unpack linux-u-boot-current-nanopineo2_20.05.0-trunk_arm64.deb ... Unpacking linux-u-boot-nanopineo2-current (20.05.0-trunk) over (20.05.0-trunk) ... Setting up linux-u-boot-nanopineo2-current (20.05.0-trunk) ... root@nanopineo2:~/tmp# Then, to install it to your SD/eMMC, run "armbian-config". In the menu, select "System and security settings", then "Install to/update boot loader", then "Install/Update the bootloader on SD/eMMC", then "Yes" at the WARNING prompt. Exit armbian-config, then reboot.
  12. OK well that answers that... I think it's clear that the memory tests used back in 2017 weren't sufficient to determine the stability of this clock. Why don't I go ahead and set it to 504MHz as that's the FA default, then if desired people could look at overclocking this further.
  13. Unfortunately not - the DDR clocks are set in u-boot... However users could feel free to build their own u-boots that use higher DDR clocks.