Super moderator
  • Content count

  • Joined

  • Last visited

About zador.blood.stained

  • Rank
    Embedded member

Profile Information

  • Gender

Recent Profile Visitors

3384 profile views
  1. This. Both overlays and fixup scripts need updates after migration from 4.14 to 4.17.
  2. zador.blood.stained


    It also has a description config BTRFS_FS_CHECK_INTEGRITY bool "Btrfs with integrity check tool compiled in (DANGEROUS)" depends on BTRFS_FS help Adds code that examines all block write requests (including writes of the super block). The goal is to verify that the state of the filesystem on disk is always consistent, i.e., after a power-loss or kernel panic event the filesystem is in a consistent state. If the integrity check tool is included and activated in the mount options, plenty of kernel memory is used, and plenty of additional CPU cycles are spent. Enabling this functionality is not intended for normal use. In most cases, unless you are a btrfs developer who needs to verify the integrity of (super)-block write requests during the run of a regression test, say N You can read the btrfs FAQ to start with
  3. Yes, we need to start working on 4.17 or 4.18 (which in addition has basic DVFS for H3), but I would prefer to do it in a separate repository branch (I already created one and cleaned up obviously obsolete patches there) rather than in the "dev" kernel target.
  4. zador.blood.stained

    A20-SOM wake up from NMI_N

    You may want to look at the legacy stack implementation: when power_start != 1 kernel reboots instead of shutting down, so you have to modify or replace the poweroff hook AXP209 PMIC "scratchpad" registers are used as a non-volatile storage to hold the suspend/wait for interrupts flag u-boot checks the PMIC scratchpad to differentiate between normal boot, normal reboot and reboot to suspend
  5. zador.blood.stained

    NanoPC T4

    And what about the Do you know if it needs additional software support on top of the base USB-C and whether it should be working already?
  6. zador.blood.stained

    NanoPC T4

    Is it? RK3399 .dtsi and the status matrix show a lot of supported HW features. But I didn't pay much attention to Rockchip development, so can you please name some roadblocks for getting at least server images with the mainline stack working? I'm not saying that we should immediately release mainline based images, I just indicated my opinion on next and dev kernel branch mapping.
  7. zador.blood.stained

    NanoPC T4

    My 2 cents (thx to FriendlyArm and Igor for the sample) Subjective pros: Lots of fast interfaces (PCIe, USB3 and Type C) with a pretty fast CPU Good software support (for the SoC), both BSP and mainline, we'll have to see if the audio chip and PMIC have good support too Subjective cons / nitpicks: Type C can't be used for powering the board Finding an appropriate connector for the fan may be tricky, though it is understandable given the component density on the PCB Serial console baud rate (1500000) may not work with some USB-UART adapters (applies to all Rockchip SoCs and devices AFAIK), it was a bit disappointing that the default kit does not include a USB-UART adapter M.2 connector has a standoff for only one card form factor, though again it is understandable given the component density on the PCB Details to keep in mind: Some I/O interfaces are 1.8V only according to specifications I'm in favor of having a single kernel source(s) too (default - 4.4 BSP, next - mainline, dev - maybe ayufan's mainline?) I think (and hope) that the mainline kernel should be suitable for server and lightweight desktop usage scenarios, and hope that this device along with Odroid N1 and RockPro64 will get upstream DTs soon enough ... without active cooling, which is IMO a not a bad idea for this board, especially if you install a M.2 SSD on it.
  8. zador.blood.stained

    Terminal video corruption/sync problem - Tinker Board

    How exactly did you copy the SD cards? Raspberry Pi and Raspbian distributions are a very rare instance where it is enough to simply clone the partitions or rsync to a prepared and mounted card, for most other SoCs you need to raw copy the whole card or reinstall the bootloader manually on new cards because it is not stored on a partition, and if you are using a filesystem level copy you have to adjust the UUID in two places.
  9. zador.blood.stained

    Rock64 nightly image

    You didn't add necessary kernel arguments (i.e. root= ), so it's not stuck, it's working exactly as expected
  10. zador.blood.stained

    Rock64 nightly image

    64bit boards usually have an uncompressed kernel (/boot/Image) that should be started with booti instead of bootz
  11. zador.blood.stained

    A20-SOM wake up from NMI_N

    Yes, this is already implemented in the legacy/BSP stack. Since mainline u-boot and kernel were made from scratch rather than by porting the Allwinner code, this functionality and many other things were not added.
  12. zador.blood.stained

    A20-SOM wake up from NMI_N

    It is not powered off completely in this state, it is sitting in a standby mode in the legacy u-boot. Both mainline u-boot and kernel do not support such functionality unless you implement it by yourself.
  13. Prebuilt images provided at - no, because they contain non-free elements: firmware in /lib/firmware and non-free (but not essential for system operation) packages such as iozone3. Obviously those parts can be removed from an installed system at any time.
  14. zador.blood.stained

    Orange Pi Zero + Max 816 Mhz

    The upper frequency point is limited for a reason
  15. zador.blood.stained

    R16 - Porting of BPI M2 Magic

    Pessimistic/realistic expectations based on the status or timeline of some other kernel features (i.e. MLC NAND, requests API, sunxi DE2 driver / H3 DVFS and THS, ...) I see things like this and this, and as I understand it, you need to have support for such devices without any userspace hacks (i.e. loading firmware) in order to add it to the kernel. And generic serdev bindings don't support any resets/clocks/regulators.