zador.blood.stained

Super moderator
  • Content Count

    3621
  • Joined

  • Last visited

About zador.blood.stained

  • Rank
    Embedded member

Profile Information

  • Gender
    Male

Recent Profile Visitors

4056 profile views
  1. zador.blood.stained

    NanoPC T4

    Looks like we got an upstream DT for the T4: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/arm64/boot/dts/rockchip?id=e7a095908227fb3ccc86d001d9e13c9ae2bef8e6
  2. zador.blood.stained

    H5 FEL/NFS test mode?

    No. Root on NFS should not be hard by itself (similar to H3, loading u-boot and kernel from SD). FEL support, on the other hand, is not implemented in the mainline u-boot for 64-bit chips, so it requires either using prebuilt u-boot binaries or adding patches to u-boot and rewriting the build script.
  3. zador.blood.stained

    H5 FEL/NFS test mode?

    There is no FEL support for 64-bit targets in the build script.
  4. zador.blood.stained

    Clearfog[Pro]mikroBus UART 5V tolerant

    According to the SoC HW specifications MPP pins are not 5V tolerant.
  5. zador.blood.stained

    Is Mali GPU driver available in Mainline for H3?

    Last time I tried it I didn't get it past the low FPS issue described in this thread. The only documentation I can point is this repository which contains some instructions that may or may not work with the kernel currently available in Armbian.
  6. zador.blood.stained

    Is Mali GPU driver available in Mainline for H3?

    Who is the customer of who here? AFAIK most Chinese makers sell these boards not much above the BOM cost, and even Allwinner tries to cut their cost as much as possible, i.e. by not purchasing Mali driver licenses that are useless for them with Android: https://irclog.whitequark.org/linux-sunxi/2017-12-07#20730568; (timestamp 07:39) It only helps running the kernel-side driver. It still requires a userspace closed-source driver of a specific type (framebuffer, Xorg, Wayland) and applications that can use this driver, i.e. you need a special shim (xf86-video-armsoc) to make use of Mali with X.org.
  7. zador.blood.stained

    board support - general discussion / project aims

    And also Terms of Use / Community guidelines should be linked somewhere in plain sight. Right now it can be accessed when registering, and even there it is not clearly shown as a link. IMO it should be on the top menu row as it is more important than i.e. Privacy policy that exists mostly for legal reasons. Edit: It's also on the bottom bar, but it will be hidden after you click "Accept", looks like by a specific cookie. Edit 2: Now that I'm looking at those (Registration Terms specifically) - they should be a numbered list instead of a bullet list, and we should probably add a new rule "Try to stay on topic defined by the starting post or developer posts in the thread. Off-topic posts that derail the discussion may be hidden, moved or deleted."
  8. zador.blood.stained

    OrangePi One v. 1.1 not booting

    Changing DT will have no effect this early (in SPL), SPL relies on CONFIG_MMC0_CD_PIN configuration option. And at least previous versions printed "mmc: no card present" when trying to access a card with broken CD pin.
  9. zador.blood.stained

    FEL mass storage or writing images directly to eMMC

    As I wrote in the issue, you need zImage and matching uInitrd with a custom premount script from the repository. There are no guides on how exactly to create them. The only thing that makes it easier is that mentioned eMMC CSD revision patch is already included in the Armbian patchset, but this assumes that CSD revision 8 is the problem which is impossible to confirm without kernel logs.
  10. zador.blood.stained

    FEL mass storage or writing images directly to eMMC

    This does not depend on u-boot (and it doesn't have much checks for eMMC revisions anyway). Most likely this could be solved by patching the CSD check: https://github.com/zador-blood-stained/fel-mass-storage/issues/5
  11. zador.blood.stained

    RK3288 device tree overlays

    At least the vanilla mainline u-boot "fdt apply" requires OF_LIBFDT_OVERLAY (which there is set on the per board basis, but it's easier to "select" or "imply" it from ARCH_ROCKCHIP like here: https://github.com/armbian/build/blob/master/patch/u-boot/u-boot-sunxi/enable-DT-overlays-support.patch
  12. zador.blood.stained

    Got questions on how to rebuild app packages w new options

    Or you would need to change the package names and installation paths for those libraries so they could coexist with upstream ones, and build mpv and plex against those. Or use static linking to libav* and libsw* libraries.
  13. zador.blood.stained

    Got questions on how to rebuild app packages w new options

    As long as you can make it work with ffmpeg versions that match the upstream distribution versions (Xenial, Stretch, Bionic), it could be done. We tried building newer ffmpeg and mpv in extras-buildpackages and providing those packages (you can probably recover the files from git history), but it resulted in breaking more than improving (or you would need to rebuild every upstream Debian/Ubuntu package that depends on libav* and libsw* packages, and building ffmpeg by itself in a generic automated way creates a dependency nightmare already).
  14. zador.blood.stained

    board support - general discussion / project aims

    Yes, but is it still manufactured? Is it still sold worldwide? And what will you do if you are an "interested developer" and your board dies? Buy another one (if it would be even possible) or move it to "community supported"? I'm not saying that we should drop support for this particular board right now (I'm sure that @tkaiser would have a different opinion) but any device will fade out in time, regardless of the history.
  15. zador.blood.stained

    board support - general discussion / project aims

    No need to be surprised, absolutely any device can be dropped based on objective reasons, mainly lack of an interested developer or persisting HW or SW issues that we can't solve. or quite the opposite - do not enforce things unless absolutely necessary, to cut support efforts on "Armbian-specific" tweaks that sometimes break. We are talking about KISS but still piling up unnecessary tweaks like DNS servers (if only there was some mechanism to automatically get a DNS server preferred by the user address among other things, I think we could even call it a "dynamic host configuration protocol") or rather an "unmarketing manager" to reduce the attention to the project to help developers catch their breath