• Content Count

  • Joined

  • Last visited

Everything posted by zador.blood.stained

  2. I tested it on OPi Zero (basically the same device) with u-boot master branch and it passed the loopback test. defconfig changes: diff --git a/configs/orangepi_zero_defconfig b/configs/orangepi_zero_defconfig index e5a4c1d9fc..39528026a6 100644 --- a/configs/orangepi_zero_defconfig +++ b/configs/orangepi_zero_defconfig @@ -9,10 +9,19 @@ CONFIG_DRAM_ODT_EN=y CONFIG_SPL_SPI_SUNXI=y CONFIG_NR_DRAM_BANKS=1 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set +# CONFIG_USE_BOOTCOMMAND is not set CONFIG_CONSOLE_MUX=y # CONFIG_CMD_FLASH is not set +CONFIG_CMD_SF=y +CONFIG_CMD_SF_TEST=y +CONFIG_
  3. There is no SPI driver for H3 in the "main" u-boot (CONFIG_SUN4I_SPI is for older SoCs), but software SPI (CONFIG_SOFT_SPI) should work if configured correctly.
  4. I think you meant "expect the user to read and not just mindlessly tick checkboxes that prevent them from posting their question"?
  5. It's not defined in DT and is created dynamically by the DRM subsystem.
  6. There is an old upstream mainline kernel issue that never was fixed:!topic/linux-sunxi/Ar9A_OYzk1Q And we can't pull random patches without proper long term testing because they may break more things than they fix.
  7. First I would change and reword the current implementation - use something like "I understand that not providing requested information will reduce the chance to solve my issue" (current one with the possibility of getting banned doesn't correlate with the forum rules), explain why providing armbianmonitor -u info is needed (I checked a few new new threads and they don't have it), deal with old images that try to upload the info to (i.e. by linking an instructions for updating the script without updating the BSP), ideally deal with the possibility that may stop to provide its f
  8. This is not a networking issue but a repository and protocol limitation, as I remember supports shallow clones only via the git:// protocol
  9. Don't get me wrong, I'm not a fan of the current form implementation, but it's only the first iteration. Since "Technical support" section is mostly used as a bug tracker and we wouldn't be able to support a standalone bug tracker / task management system, adding data collection form to the forum is a step in the right direction.
  10. Unfortunately "getting information" != "answering the same questions and requesting even the basic info again and again and again". For example, threads like this one would have 1 reply with a simple answer - eMMC CSD checks for revision 8 were fixed more than a year ago. It took 5 posts to confirm that this is the culprit and it is still impossible to tell which kernel version (I mean kernel compilation date) is used due to missing dmesg from "armbianmonitor -u". Funny thing is that this thread was created after the addition of the new information collection form, so w
  11. Perhaps. @zador.blood.stained? Not sure about this. - the second tab on Github project is called "Issues", not "Discussions" or "all stuff", and it has "Open"/"Closed" statuses more suitable for tracking actual bugs/issues than discussing build script usage - this would make it impossible to easily move framework related discussions from the forum to the right place
  12. Looks like we got an upstream DT for the T4:
  13. 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.
  14. There is no FEL support for 64-bit targets in the build script.
  15. According to the SoC HW specifications MPP pins are not 5V tolerant.
  16. 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.
  17. 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:; (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) t
  18. 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 probab
  19. 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.
  20. 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.
  21. 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:
  22. 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:
  23. 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.
  24. 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).