zador.blood.stained

Well, it could be that the issue is the same. I fixed my U-Boot driver. It seems that we shouldn't adjust addresses at all. Hm... I should test that also with One or Lite, but currently I don't have such board at hand. Do you?

- link is password protected
- it's better to release instructions (and references) than prebuilt image, this definitely will be more helpful

IMO we should switch back to 'by date' as default. With current sorting new users accessing this page get the impression that this here is all about boring Bananas while the average potential new Armbian user searches for 'hot stuff' (like OPi Zero in this case).

I managed to write H3 HDMI driver for mainline U-Boot. Source can be found here:
https://github.com/jernejsk/u-boot
 
You should also add CONFIG_VIDEO=y to defconfig for your board.
 
It should work nicely for standard resolutions (720p, 1080p). Other resolutions might work, but some additional work needs to be done. Currently, this can be used for working with U-Boot (instead of serial console) or splash screen.

And previous post of this user is the exact copy of this.

To resolve this problem enough in fex config file on mm2_para change sdc_detmode from 1 to 3.
764 [mmc2_para] 765 sdc_used = 1 ~ 766 sdc_detmode = 3 767 sdc_buswidth = 8 768 sdc_clk = port:PC05<3><1><2><default> 769 sdc_cmd = port:PC06<3><1><2><default> 770 sdc_d0 = port:PC08<3><1><2><default> 771 sdc_d1 = port:PC09<3><1><2><default> 772 sdc_d2 = port:PC10<3><1><2><default> 773 sdc_d3 = port:PC11<3><1><2><default> 774 sdc_d4 = port:PC12<3><1><2><default> 775 sdc_d5 = port:PC13<3><1><2><default> 776 sdc_d6 = port:PC14<3><1><2><default> 777 sdc_d7 = port:PC15<3><1><2><default> 778 emmc_rst = port:PC16<3><1><2><default>

Speaking of download page, it would be nice to sort boards alphabetically by name.

There is a syntax for sources.list to tell which architectures to use for the repository:
deb [arch=armhf] https://dev2day.de/pms/ jessie main

already said on facebook... you are doing spam everywhere, and with a product which is a rip-off/clone of the witty esp8266 board, which exists from months, now...

Building using Docker should not be much different from standard setup, but we could use more testing, polishing and enhancements for the build process.
 
This includes
testing and providing logs for full image build to check if current workarouns for loop devices are working or need adjustments enhancing Dockerfile if there are any options that may make default experience better testing whether Docker implementation on Windows works fine for full image builds

Building using Docker should not be much different from standard setup, but we could use more testing, polishing and enhancements for the build process.
 
This includes
testing and providing logs for full image build to check if current workarouns for loop devices are working or need adjustments enhancing Dockerfile if there are any options that may make default experience better testing whether Docker implementation on Windows works fine for full image builds

Banana Pi Pro DT file doesn't have audio codec enabled, so it had to be patched manually. Unfortunately the patch fell out after switching to another DT file. This should be fixed in new release.

Started to write a long wall of text several times, but wasn't happy with the result, so to keep this short:
 
Making Armbian for selected number of boards and kernel configurations more IoT friendly is possible, but requires some effort to maintain (for mainline kernel).
Compared to RPI we don't have uniform interface for activating and configuring different hardware interfaces, so everything should be done (for legacy kernel) and maintained (for mainline) for each SoC and board/group of similar boards individually.
 
GPIO group and udev rules should be done as an option in armbianmonitor (since we don't have any GUI/dialog based system configurator) should be provided by default in board support package, users will be able to use this by adding themselves to "gpio" group.

Who said that? Any u-boot that supports reading from ext4 can be "convinced" to use single partition scheme, we just need to get enough logs and feedback to properly implement this.

Please try rebuilding the kernel with updated config. Since kernel doesn't pick command line both from legacy and mainline u-boot, it must be a kernel issue.

There is no onboard battery controller or PMU on H3 based boards, compared to Pine64 or A20 based Bananas. So you will need external device to safely charge the battery, and possibly something like I2C ADC to read out battery voltage from OS.

@zador.b.s
your latest updates for XU4/next (uboot 2016.09) are working fine on SD, I will check when possible for legacy
 
 
edit: for eMMC, the sd_fusing.sh script is needed to wipe out uboot 2012.07 from "boot0" with 2016.09. if not wiped, booting is weird/KO.

Since it is failing at building additional tools, you can try adding EXTERNAL=no to compile.sh to disable building these tools.
 
Maybe we should not interrupt build process if non-critical packages failed to build, or even remove temper and USB redirector since they are not specific to our supported hardware and most people don't need these tools.

Ext4 support is missing in odroid-specific u-boot config - added with a patch, will need a new test image

Regarding XU4 there are these things to test:
Initrd support that was added recently Not a real test, but more a request for test or documentation - check if mainline u-boot can be used both for legacy and next kernels, also what problems forced using 2016.05 version (compilation issues?) In case legacy u-boot is still required, check loading environment from a text file like it's done, for example, here: https://github.com/igorpecovnik/lib/blob/master/config/bootscripts/boot-pine64-default.cmd#L15-L17 In case u-boot environment is properly loaded, booting by filesystem UUID can be activated for XU4.

Sorry, yes, there is an output, monitor reports 1280x1024 in its menu, so looks like framebuffer size is the only issue.

If you make a test image for one of the boards listed in my signature, I can test it on a TV which has lower native resolution.

Now setting display resolution in uEnv.txt is supported for Pine64 default kernel:
root@pine64:~# cat /boot/uEnv.txt ethaddr=ca:17:10:f7:2b:29 disp_mode=720p60 Available modes are listed in boot script. Al least 720p60 works for me in addition to default 1080p60

I also added DVI compatibility option (disp_dvi_compat=on), untested.

Once NAND is properly supported in mainline kernel and u-boot, NAND support will be easy to implement.
 
If this parameter is required, it should be added to armbianEnv.txt from family_tweaks to keep main boot script simple. Now it is not present in new simplified boot-sunxi.cmd script anyway.