zador.blood.stained

What do you mean by that exactly? zram for the build host or for built OS images? If lack of a proper build HW counts as a technical roadblock (in addition to existing problems like a time bomb log2ram implementation and non-technical project goals/aims and resulting motivation) then yes.

They were always hardcoded, it's just that the sunxi legacy kernel has some hacks and closed source blobs that allow reconfiguring the DRAM frequency on the fly. "Should" is subjective here. Since nobody tried to implement this yet you can assume that developers think that this is not necessary or can't be reliably or cleanly implemented.

By rebuilding u-boot with changed CONFIG_DRAM_CLK value.

Community supported configuration. This means that somebody wanted to have a target for building kernels and/or images for this device, but the core team does not have this device and does not have interest in obtaining and supporting this device (otherwise this would be a stable or Work-In-Progress configuration). Adding its support into the build system, preferably without breaking anything for other existing boards. I think the only real requirement is that it must not be a custom/private design. Yes, making sure that everything that should work still works, adjusting build related configuration and testing resulting packages and images.

Only HDMI is supported (or rather still WIP) on R40: https://linux-sunxi.org/Linux_mainlining_effort

If it is powering related, it may be possible to solve this either with soldering, buying a miniPCIe-PCIe and PCIe-miniPCIe adapters (edit: or a miniPCIe extender + soldering to give the card external power) with external power support or designing and manufacturing a custom adapter board. It also could be power filtering related, or EMI (with Espressobin non-power circuits) related. Software development, testing and support takes more than just time. The cheapest variant of GT 8K costs $200+, not including shipping cost.

It is available only in the development branch for now, and it needs to be reworked before it can be pulled to master/stable.

I missed this initially, but you also need to check this: https://www.kernel.org/doc/Documentation/gpio/board.txt Your DT properties should be named <function>-gpios and in devm_gpiod_get you should omit the "-gpios" suffix. I.e. reset-gpios = <&pio 8 17 0>; /* PI17 */ ... priv->reset_gpios = devm_gpiod_get(&client->dev, "reset", GPIOD_OUT_HIGH);

This will also include bridge interfaces which are usually named brX, so this regexp may need further rework.

@Igor You could hide all options that depend on NM if it is not installed and move network-manager from dependencies to suggested package for armbian-config.

Also not relevant to your issue, but if you need interrupts, you could look at this and register your device as an interrupt controller client rather than trying to use the GPIO framework.

You didn't say which SoC are you developing for. For common sunxi SoCs like A20, H3, ... this reset_gpios = <&pio 8 17>; /* PI17 */ int_gpios = <&pio 8 16>; /* PI16 */ aint_gpios = <&pio 8 19>; /* PI19 */ error_gpios = <&pio 8 18>; /* PI18 */ is wrong since you need 4 cells for a GPIO property: pin controller phandle, pin bank number, pin number in the bank and flags. Flags parameter is mandatory and is usually set to 0. So you most likely need to update your DT to this reset_gpios = <&pio 8 17 0>; /* PI17 */ int_gpios = <&pio 8 16 0>; /* PI16 */ aint_gpios = <&pio 8 19 0>; /* PI19 */ error_gpios = <&pio 8 18 0>; /* PI18 */

Looks like some RSS settings can be changed by creating custom feeds in Forums-Settings section in AdminCP, but I don't have permissions to do that.

Also it would be nice to remove the "Newsletter" box from the Activity pages, and at least for me nick and date separators for the posts on the main page are broken (most likely theme related): DLink - DWA 131 - Rev E1- … By Mustafa85base_forum_author_date_sep Yesterday at 01:03 PM

For me it switched (?) to the "Haze 4.3.x" theme which is pretty much broken and I had to search for the black "Theme" selection link on black background.

It is not available from Allwinner under a redistributable license that would allow to put it in OS images or in a Github repository. As I see it the blobs are not hardware specific and you could use a blob found anywhere for other platforms as long as they were built for the same GPU core and revision. It is a difficult question that depends on the definition of "using", and there are different blob types (fbdev, xorg, wayland) and different architectures (armhf and arm64). You could probably find a blob for one of those combinations. AW guys don't care (at least ones that could release a properly licensed mali blob). You can use GPU on Android, and that is all they care about.

If you did not apply any patches (from Maxime's or Icenowy's sunxi-mali repositories) to the upstream r8p0 driver it's not surprising that it does not work. The driver will look for the "compatible" properties in DT, if nothing matches then it won't do anything when you load it. You can dump the running DT with dtc if you want to check it dtc -I fs /proc/device-tree

This driver is only for Mali400: https://github.com/mripard/sunxi-mali/blob/master/patches/0005-mali-Add-sunxi-platform.patch#L100 You may have to copy patches from mripard's tree into Icenowy's one, specifically this patch: https://github.com/mripard/sunxi-mali/blob/master/patches/0012-mali-support-building-against-4.14.patch

Yes, creating and loading an overlay is the easiest way to add modifications to the DT, but in this case you will need to either replace all macro constants like GIC_SPI, IRQ_TYPE_LEVEL_HIGH, CLK_BUS_GPU by their numerical values or add #include directives for all necessary headers and ensure that compiler will find those headers, which is a bit tricky if overlays are compiled out of tree.

Since there needs to be an exact match between the userspace and kernel driver versions a kernel-side driver will not be mainlined unless the userspace side becomes open-source too. Especially since the kernel side part may not meet the kernel code quality and integration criteria.

This is hardware specific and will not work on anything other than Raspberry Pi boards.

By adding a custom video mode to extraargs? https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/fb/modedb.txt https://wiki.archlinux.org/index.php/kernel_mode_setting#Forcing_modes

We have multiple files in our archive, does Etcher deal with this correctly without decompressing the archive manually?

And also https://linux-sunxi.org/Linux_mainlining_effort for the A83T mainlining status and progress (we are not touching the BSP for this SoC).

Sometimes. Mainline driver has not reached upstream yet, it may have bugs. Bugs that will not be fixed in this version or that may have been fixed already in the version that will appear upstream. And kernel related questions asked without providing debug logs in form of output of "armbianmonitor -u" are often ignored, when people don't read this page that is linked below the forum header why should we bother to read and try to answer in return? This path should be relative to /lib/firmware, which means that if edid/1920x1080.bin is specified then /lib/firmware/edid/1920x1080.bin should already exist, assuming the DRM output notation "HDMI-A-1" is correct.