PaddleStroke

I found how to modify pyA20 to check the register value. I added this to gpio_lib.c and gpio_lib.h, then some other things in gpio.c to declare the new module. - added in gpio_lib.h #define HDMI_PHY_BASE 0x01ef0038 - added in gpio_lib.c int get_HDMI_HPD() { if (SUNXI_PHY_BASE == 0) return -1; uint32_t reg = (uint32_t *)SUNXI_PHY_BASE; return (reg & ( 1 << 19))>> 19; } However I still can't read the hpd status. At the beginning it just returned me 1, if HDMI connected or not. Then to further investigate I modified the function to : int get_HDMI_HPD() { if (SUNXI_PHY_BASE == 0) return -1; uint32_t reg = (uint32_t *)SUNXI_PHY_BASE; return reg & 1048575; #1048575 because it's 11111111111111111111 in binary. } So I could read the 20 first bits of the register, and see what happens. Then I have some very strange results. The value returned does not depend if HDMI is connected or not. So when I run my python script, it initialize pyA20 (so the mmap to dev/mem) Then whenever I check get_HDMI_HPD() I have the same number returned again and again. Even if I unconnect HDMI. For example - return = 11010010000000111000 (= 860216 in dec) - disconnect HDMI - return = 11010010000000111000 (= 860216 in dec) - wait 10 minutes - return = 11010010000000111000 (= 860216 in dec) Then if I close the python script and open again (so mmap is reinitialized) the number change : - return = 01010111000000111000 (356408) - disconnect HDMI - return = 01010111000000111000 (356408) ... I tested several times and each time mmap is reinitialized the number changes. HDMI has no effect what so ever. 11010010000000111000 860216 10111101000000111000 774200 11011111000000111000 913464 11001010000000111000 827448 01010111000000111000 356408 00000001000000111000 4152 the mmap seem correct : int sunxi_gpio_init(void) { int fd; unsigned int addr_start, addr_offset; unsigned int PageSize, PageMask; void *pc; void *pc2; fd = open("/dev/mem", O_RDWR); if (fd < 0) return -1; //mmap for GPIO PageSize = sysconf(_SC_PAGESIZE); PageMask = (~(PageSize - 1)); addr_start = SW_PORTC_IO_BASE & PageMask; addr_offset = SW_PORTC_IO_BASE & ~PageMask; pc = (void *)mmap(0, PageSize * 2, PROT_READ | PROT_WRITE, MAP_SHARED, fd, addr_start); if (pc == MAP_FAILED) return -1; SUNXI_PIO_BASE = (unsigned int)pc; SUNXI_PIO_BASE += addr_offset; //mmap for HPD addr_start = HDMI_PHY_BASE & PageMask; addr_offset = HDMI_PHY_BASE & ~PageMask; pc2 = (void *)mmap(0, PageSize * 2, PROT_READ, MAP_SHARED, fd, addr_start); if (pc2 == MAP_FAILED) return -1; SUNXI_PHY_BASE = (unsigned int)pc2; SUNXI_PHY_BASE += addr_offset; close(fd); return 0; } Do you see something wrong in my mmap? I used the same syntax with the GPIO mmap, and I tested the GPIO are still working correctly, even if the getHPD always give the same result. Are you sure about the register address for HPD? Or maybe it's not in the dev/mem file, I don't know how this file works. Is it the full register values? Enclosed are the modified pyA20 files. gpio.c gpio_lib.c gpio_lib.h

Thanks! Is this the same with access rights 0666 ? If not how to enable this access? Also do you know how to read from registers? From my reading we can use dev/mem file right? In pyA20 there's an example but I am not sure to understand how it works. and how this mem file is structured. Any hints how to read a specific register address from it?

Thanks for your reply jernej! I could fix my rotate problem by hardware modification of the LCD. However I have not yet got the HDMI/AV switch working. I think I have a total lack of understanding on how drv_hdmi and drv_tv work. Also I don't understand how this CONFIG_SWITCH works. But is it not possible to just use a simple daemon that would do something like : define last_read_HPD = 0 While 1 HDMI_HPD = read status directly from registry if HDMI_HPD =! last_read_HPD if HDMI_HPD = 1 turn OFF disp1 as you describe here turn ON disp0 if HDMI_HPD = 0 turn OFF disp0 turn ON disp1 last_read_HPD = HDMI_HPD However I don't know how to read the HDMI_HPD status. I checked the H3 datasheet but can't find HPD registry address. I have found there (line 114) a function that seem to be doing just that but I can't understand how it works. 114 static int sunxi_dw_hdmi_get_plug_in_status(void) 115 { 116 struct sunxi_hdmi_phy * const phy = 117 (struct sunxi_hdmi_phy *)(SUNXI_HDMI_BASE + HDMI_PHY_OFFS); 118 119 return !!(readl(&phy->status) & (1 << 19)); 120 } I can't find where is defined SUNXI_HDMI_BASE (and so it's value) to get the exact address. Also I don't understand the return. Do you know how to read HPD status from the daemon? Do you think this simple methode would work? Thanks!

Thanks for your reply! Module you mean the chip does not have power? module will not install if IC is not responding is it so? It's bad, do you mean it's not working correctly or consumming too much or failling often or both? If so maybe I will remove it from the schematic! Is there a H3 board who has a correct wifi chip?

Hi there, I am trying to have the wifi working on my board and I have some more problems It's same schematic as orange pi zero. So I checked the orangepizero.conf and it is : MODULES="#w1-sunxi #w1-gpio #w1-therm #sunxi-cir xradio_wlan g_serial xradio_wlan" So I tried to enable the module xradio_wlan but I have : MODPROB ERROR : "could not insert 'xradio_wlan' : Connection timed out" Any idea of the possible problem? Maybe a dependency issue with another module missing?

Hi there! I am using a H3 board with TV out on a small 3.5" LCD screen (with composite->RGB24 IC). But I have a problem with picture being way too bright/washed out. The LCD luminosity can be modified with LCD-driving IC buttons, when set to lower value the picture gets better but colors are still too bright (even if luminosity is low) I have tested the LCD with raspberry pi and output colors are normal. I was wondering if there is a known reason for this and if it can be fixed? So far I have just found a topic about a raspberry pi HDMI output being too bright (https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=50726) They suggest that a parameter "hdmi_pixel_encoding=2" in config.txt can help on raspberry pi for this issue. So I was wondering if they were some similar settings on armbian? Thanks! edit: I just had a suggestion of adding a 50ohm resistor between AV and ground. I will test and feedback if it helps 2nd edit: I added a 50 ohm resistor and it worked. The thing was that my board was missing a small schematic at TV out. Most important was 50ohm resistor between AV and GND. Same problem is on orange pi zero which don't have this schematic neither. If it can help some one some time.

Ah unfortunately they make aluminium board only for 1 layer PCB

Yeah Armbian is booting correctly now! It works surprisingly well for a first prototype It overheats a bit, but same as most H3 boards I guess. Maybe I will have to get a 2 oz copper layer for the ground plane. Or maybe aluminium core (opi use them, it's special PCB used in LED boards), but there's not much suppliers of those pcb. Now I only have few little things to correct : 1 - wifi not working out of the box. I think it's probably because I use "opi pc plus" image and my wifi schematic is the one of "orange pi Zero" In the build repository in the board config files I see the different board have different "modules" Can someone tell me a bit more about those modules? I can't find them in repository. I think wifi setup might have to do with the modules. 2 - I have GPIO buttons that I can't get to work using PYA20. Those GPIO buttons are PD GPIO. Is there something special with D GPIO interfering? In orangepi PC schematic those are writen to be : ERXD3 ETXD0 ETXD1 ETXD2 ETXD3 ECRS ETXEN ECOL EMDC EMDIO ... But they don't seem to be connected to anything in the schematic. So I think they might just be floating. edit: After bit of reading I found out that pyA20 is for A20 board (which makes sense !) and on A20 the PD are used by the LCD. So I think they probably not included the D GPIO in their script. I'll let you know. edit: There was a problem with pyA20 package indeed, I was using a old version of the package, and in fact the new version of the package should work in most cases out of the box with H3. If a GPIO is not working it's likely not been included in the mapping.h file of the package.

That was the trick! Added a pull up resistor to AP-RESET# it was enought. The boards are booting now. Starting boot at least I'll have to modify few things I guess

Ok maybe we found out the mistake. I have not included the AP-reset# schematic... Damn it was writen reset-option on the schematics, I should have thought better! I'll try to hand solder it.

@@lex That does sound interesting. But I can't find reference to this in the topic you linked? I am downloading a bananapi m2+ image to try it, it should have the u-boot patch you'r telling me about. edit: no luck with banana pi m2+ image. I will have to wait to read serial console. Hope it will help

Thanks for your feedbacks! @guidol Just ordered few UART USB to check on that. So just to be sure to understand correctly, in the script.bin file I read that UART gates functions are assigned there. But if it can't boot and read script.bin then it means PA4 and PA5 default function is UART right? @@lex Yes I think I should use another uboot, but I am not sure any current uboot will be ok for this board as it's not exact same schematic with other h3 boards. And for SD slot the thing is that I have 4 prototypes and none is working so it sounds unlickely to be the SD slot.

Got it thanks! How can I read the uboot serial log then? Should I simply use the UART0 (PA4/PA5 GPIO)? Does it have something to do with uboot pin?

@Tido problem is to be sure of HW, schematic seem correct but I am not entirely sure it's without mistakes. I would rather bet on the contrary! I think the problem of undervoltage on most opi boards are due to the fact that they use SY8113 buck to make the CPU 1.3V, and this IC voltage rating is 4.5-16V. So with inner voltage drop the opi boards voltage can be close to the minimum 4.5V, at which the buck is likely to work not correctly. On my board I use AXP8036 which voltage rating is 2.3-6V (or something similar) so it should be fine even with voltage drop. @guidol Thanks for this idea! I was in fact not sure how to find debugging infos. Fortunately I did made a test point for u-boot. Sorry for the stupid question, but how can I read the serial log from u-boot? What hardware should I use?

Thanks for reply, 1. Yes I used micro-USB for powering. Mainly because of PCB footprint is smaller. But it can be changed to Barrel Jack for later version. Is it a problem because of max current rating of micro-USB? If it's about voltage drop, the buck AXP8036 support lower voltage than 5V, as it can run on battery with voltage as low as 3-3.2V 2. I just found this link ealier today. I am browsing the build files right now. I'll try to find what to modify. I think (not really sure) main problem is because clock is share with wifi XR819 as opi zero and ram is same 1GB with opi pc +. I should have thought better before mixing schematics... 3. SD card have been tested on other orange pi and works correctly.

Hey guys and a happy new year! I am working on a custom H3 board and I just got the prototypes from the oven. I am now trying to boot armbian on them. And as it's first prototypes I expected problems but I have trouble figuring out. I think it's because of my lack of understanding the boot process. See picture of the board enclosed. It don't tell much but it's nice to have a visual I think. On top right is a battery manager/power input. Right under is AXP8036 that makes 4 buck channels (1.35V for ram, 1.2V sys, 1.3Vcpu and 3.3V) Most is similar with orange pi PC schematic, there is few changes : - crystal and wifi is same with orangepi zero, are 22pF at X24in and 9pF at X24in - PL03 is left floating instead of PWR-KEY - UBOOT is left floating - PL10 and PG11 are left floating (they are mentionned in boot-begin.cmd) - Then lot of others GPIO are left floating or pulled up, used as GPIO buttons at the back of the board. My approach was to first edit the script.bin with bin2fex/fex2bin in order to modify according to my board differences with opi pc and opi zero. When I plug the SD and turn ON, the ethernet LEDs turn ON and don't blink. And no signal is sent to HDMI. Exactly the same as when I turn on an orange pi (or my board) without SD card at all. - My first guess was a power problem, but I checked all voltages are OK, I even tried to supply the bucks directly 5V from a charger tested on orangepi. And the buck AXP8036 is a model specially designed for H3. - Second guess was that I made an error in the script.bin. But I tried to boot an orangepi with a SDcard without any script.bin and the orangepi start and display signal on HDMI with first lines of booting until "script.bin not found". - Then I thought maybe SD detect is not working, but schematic is same with orangepi (on PF0-PF6) and I have 4 prototypes so it's unlickely hardware defect. Could it be because I left PL03 floating (on orange pi zero they keep it pulled up even if there is no power button)? But it seems to me the powerkey GPIO is assigned in the script.bin so it sounds unlickely. And UBOOT floating? But I tried connect pull up resistor it does not change. Or PL10/PG11 ? as they are called in this boot file I wonder. But PG11 is CSI_EN on orangepi PC schematic, and PL10 is the status LED which is output GPIO. Or Crystal capacitor as it's shared with the wifi it may need some adjustments? I don't understand very well the boot process but I read somewhere that the first 1MB of SD is a bootloader. Could the problem be in there? Maybe there is hardware specification in there? I know it's a very difficult topic, but if someone has some hints, or insight on boot process it would be really awesome! I can send you the schematic if someone care to give it a look! Thanks,

Hi there, Is there a way to make an automatic switch between AV and HDMI when HDMI connector is connected/disconnected? ie By default AV composite signal is ON, if HDMI is detected while booting, then video and sound are output to HDMI instead of AV/L/R output. I read that if both TV out and HDMI are enable at the same time it can result in artifacts on HDMI and for that reason TV was disabled by default. So is there a way to detect if HDMI is plugged in, and if so disable TV out. I would say it needs 2 .bin files with each config, but how to detect if HDMI is present before loading .bin and load the right .bin according to situation? Also is it possible to rotate display by 90 or 180° ? Would it be possible to have : - by default AV with 180° rotation - if HDMI detected then HDMI without rotation? Thanks! (for H2+/H3 board)

Hey guys, I would like to interface a small RGB24 LCD on the H3 GPIO, similar to this on raspberry pi : https://www.raspberrypi.org/documentation/hardware/raspberrypi/dpi/README.md http://blog.reasonablycorrect.com/raw-dpi-raspberry-pi Is this feature already present on armbian device tree overlay? If no, how would one make it? Could someone help drawing the big picture so I know where to start? After having a look at this section : https://docs.armbian.com/Hardware_Allwinner_overlays/ I understand that it would require writing a dt overlay (.dts file) to attribute the different functions to the GPIOs. But then how to write the functions? I am quite familiar with the LCD datasheet and RGB pins function, the part that is still mistery for me is the driver writing: what file format? what programming language? where to drop the file? Thanks! Pierre

Hey guys, Thank you tkaiser for this write up! I am starting to design a PCB based on H3 or H2+ that is intended to run on battery. I started with H3-Olinuxino design files. I did not find many data about power managment on H3 boards (only that H3 does not support PM). The C.H.I.P based on a R8 SoC use a AXP209. Do you have any hints on what PM IC to use? My best choice right now is to make a power-managment design separated from H3 and that will just have an ON/OFF switch to supply the rest of the PCB. Which will not enable to have safe shutdown. Also do you have some hardware advices to reduce power consumptions? I read that reducing DDR voltage from 1.5V to 1.35V will help reduce overheating and power consumption. Also from your experience with H3 boards what would be good hardware design practices to reduce over-heating of the SoC? About the orange pi copper layer to spread the heat do you have more data on this? Does he use ground planes on the different layers on does he have a dedicated layer with special copper thickness? If you have any hardware design advices it would be great!