Mitch Posted April 20, 2017 Posted April 20, 2017 When trying to build my own image for Orange PI Win using Ubuntu Xenial 16.04 x64 on VirtualBox i am getting a bunch of messages like below CC spl/drivers/block/blk_legacy.o In file previous definition from include/configs/sunxi-common.h:22,UNXI_TVE0_BASE 0x01c0a000 from include/configs/sun50i.h:28, from include/config.h:5, from include/common.h:21, from drivers/block/blk_legacy.c:8: ./arch/arm/include/asm/arch/cpu_sun4i.h:169:0: warning: "SUNXI_TVE0_BASE" redefined #define SUNXI_TVE0_BASE 0x01e40000 │ LD spl/drivers/block/built-in.o │ │ CC spl/drivers/gpio/sunxi_gpio.o In fil location of the previous definition from include/configs/sunxi-common.h:22, #define SUNXI_TVE0_BASE 0x01c0a000 from include/configs/sun50i.h:28, from include/config.h:5, from include/common.h:21, from drivers/gpio/sunxi_gpio.c:13: ./arch/arm/include/asm/arch/cpu_sun4i.h:169:0: warning: "SUNXI_TVE0_BASE" redefined #define SUNXI_TVE0_BASE 0x01e40000 │ LD spl/drivers/gpio/built-in.o │ │ CC spl/drivers/mmc/mmc_legacy.o In file included from ./arch/arm/include/asm/arch/cpu.h:13:0,h:38:0: note: this is the location of the previous definition from include/configs/sunxi-common.h:22, #define SUNXI_TVE0_BASE 0x01c0a000 from include/configs/sun50i.h:28, from include/config.h:5, from include/common.h:21, from drivers/mmc/mmc_legacy.c:8: ./arch/arm/include/asm/arch/cpu_sun4i.h:169:0: warning: "SUNXI_TVE0_BASE" redefined #define SUNXI_TVE0_BASE 0x01e40000 ERROR: Couldn't open "config.its": No such file or directory u-boot/tools/mkimage: Can't read u-boot.itb.tmp: Invalid argument ^ make: *** [orangepiwin] Error 255 [ error ] ERROR in function compile_uboot [ common.sh:113 ] [ error ] U-boot file not found [ u-boot-sunxi-with-spl.bin ] [ o.k. ] Process terminated Any Ideas what i am doing wrong or is the custom image currently broken for Orange PI Win?
martinayotte Posted April 20, 2017 Posted April 20, 2017 Note that most of the above are warning for the HDMI driver, you shouldn't care to much about them. The real error you faced is : ERROR: Couldn't open "config.its" And that reveal to me that I forgot to commit 1 files during my initial commit few days ago : missing blobs/sun50i_a64_opiwin.its added. I've just committed it now ... ( @zador.blood.stained, in fact, this forgotten file should be directly in your u-boot proxy repository, but I presume I can't commit it there directly, so, in the mean time, I've done it inside a patch)
martinayotte Posted April 21, 2017 Posted April 21, 2017 On another subject, since this is a new build target only since few days, my recent works as to get R_PIO working on OPiWin to allows getting the WiFi AP6212 working soon. Unfortunately, I didn't get expected success yet. R_PIO seems to be properly initialized, but neither wifi_en_pin@0 (PL8) or manual sysfs PL9 on header doesn't work. The sad thin is that the sames R_PIO patches works well on Pine64 where I've been able to blink PL7 LED. That make me think that the schematic we got ORANGEPI-Winplus-V1_3.pdf maybe not matching the real hardware, the "plus" maybe means "another" board, not yet available. @Igor could you confirm with Steven ? There many other schematics that never been published yet, that should be updated ...
Mitch Posted April 21, 2017 Author Posted April 21, 2017 Thanks for the patch it now builds the ubuntu desktop image that is able to boot on my Orange PI Win. I have not tried the wifi yet. i did notice armbianmonitor gives message /usr/bin/armbianmonitor: line 264: /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq: No such file or directory but other then that is seams be running great. much faster then the images available from orangepi.org
martinayotte Posted April 21, 2017 Posted April 21, 2017 @Igor, thanks for confirmation ! I will continue digging ...
martinayotte Posted April 22, 2017 Posted April 22, 2017 @Igor, can you confirm with Steven that PL9 is really on pin 16 of the header ? It doesn't work and since the PDF is named ORANGEPI-Winplus-V1_3.pdf and not ORANGEPI-Win-V1_x.pdf, i suspect some discrepancies ... Same thing with ORANGEPI-Prime_V1_0.pdf, the STATUS-LED doesn't light up when bring PA15 to HIGH. And if I remember this is the same issue with ORANGE_PI-PC2-V1_2_schematic.pdf, the STATUS-LED doesn't light up when bring PA15 to HIGH ! Steven should make sure that his schematics are reflecting the reality !!! EDIT : Ok ! I found the discrepancies. In top area of the schematic, it says PA15 = STATUS-LED, but on the CPU pins , it is PA20. Same thing for PC2.
@lex Posted May 7, 2017 Posted May 7, 2017 On 4/21/2017 at 10:43 PM, martinayotte said: And if I remember this is the same issue with ORANGE_PI-PC2-V1_2_schematic.pdf, the STATUS-LED doesn't light up when bring PA15 to HIGH ! Steven should make sure that his schematics are reflecting the reality !!! EDIT : Ok ! I found the discrepancies. In top area of the schematic, it says PA15 = STATUS-LED, but on the CPU pins , it is PA20. Same thing for PC2. I would like to ask if you mean STATUS-LED the one beside the Power Led (RED)? I am trying to understand the schematic and the Pins, if i understand anything PA15 is used on uart3 according to Fex (opi PC2) and the STATUS-LED is PA20, for opi-win schematic is PH11 (GPIO asssignment).... obvioulsy wrong.
martinayotte Posted May 7, 2017 Posted May 7, 2017 One my OPiWin, the STATUS-LED is really PH11, but it's brightness is very dimmed, only small tiny green dot... But my issue is that PL9 isn't working on pin 16 of the header. Maybe there still issues with R_PIO patches ...
@lex Posted May 7, 2017 Posted May 7, 2017 Ouch, i got it wrong...sorry. Just for curiosity, did you enabled uart3? i was looking at buddy dts and schematic for the uart3, PH4,PH5,PH6,PH7 can't be acquired on legacy kernel and PH7 is shared with codec (may be multiplexed?).
martinayotte Posted May 8, 2017 Posted May 8, 2017 No, I didn't try, but also I only use Mainline. In Mainline, those PH4 to PH7 are free, so maybe a UART3 overlay could be written later.
tkaiser Posted May 8, 2017 Posted May 8, 2017 I'm too lazy (or dumb) to read schematic: Which VDD_CPUX voltage is OPi Win currently using when nothing has been configured? According to xhpl64 my OPi Win starts to fail at 1056 MHz but no data corruption is reported at 1008 MHz (running latest nightly). Is this also 1.1V by default like with Pine64?
MMGen Posted October 13, 2017 Posted October 13, 2017 On 4/22/2017 at 1:43 AM, martinayotte said: @Igor, can you confirm with Steven that PL9 is really on pin 16 of the header ? It doesn't work and since the PDF is named ORANGEPI-Winplus-V1_3.pdf and not ORANGEPI-Win-V1_x.pdf, i suspect some discrepancies ... Same thing with ORANGEPI-Prime_V1_0.pdf, the STATUS-LED doesn't light up when bring PA15 to HIGH. And if I remember this is the same issue with ORANGE_PI-PC2-V1_2_schematic.pdf, the STATUS-LED doesn't light up when bring PA15 to HIGH ! Steven should make sure that his schematics are reflecting the reality !!! EDIT : Ok ! I found the discrepancies. In top area of the schematic, it says PA15 = STATUS-LED, but on the CPU pins , it is PA20. Same thing for PC2. Can confirm: ORANGE_PI-PC2-V1_2_schematic.pdf erroneously has STATUS-LED as PA15 when it's really PA20. But this is the RED led (next to the green one, which is always on). I think power led and status led might be reversed then on the PC2. On RPi/Raspbian the power led is red and status is green.
martinayotte Posted October 13, 2017 Posted October 13, 2017 As said earlier, the ORANGE_PI-PC2-V1_2_schematic.pdf shows erroneously PA15 in the Pin Grid Summary, but is correct in the wiring itself, showing clearly that it is on PA20, and Yes it is the RED LED that is connected there.
MMGen Posted October 13, 2017 Posted October 13, 2017 23 minutes ago, martinayotte said: As said earlier, the ORANGE_PI-PC2-V1_2_schematic.pdf shows erroneously PA15 in the Pin Grid Summary, but is correct in the wiring itself, showing clearly that it is on PA20, and Yes it is the RED LED that is connected there. So power green, status red is OK? This is the standard for Armbian? Just wanted to clarify that.
martinayotte Posted October 13, 2017 Posted October 13, 2017 6 minutes ago, MMGen said: So power green, status red is OK? Yes, power is the green one ! 6 minutes ago, MMGen said: This is the standard for Armbian? This is nothing related to Armbian, it is the board manufacturer that probably decided that, or it was a manufacturing mistake in the pick-and-place machine ... (Same thing appended with OPiPrime vs OPiWin, the colors differ ... EDIT : For Prime, it is explicitly describe as a decision, For PC2, it seems to be pick-and-place error ...)
MMGen Posted October 13, 2017 Posted October 13, 2017 1 hour ago, martinayotte said: Yes, power is the green one ! This is nothing related to Armbian, it is the board manufacturer that probably decided that, or it was a manufacturing mistake in the pick-and-place machine ... (Same thing appended with OPiPrime vs OPiWin, the colors differ ... EDIT : For Prime, it is explicitly describe as a decision, For PC2, it seems to be pick-and-place error ...) Thanks! It's sort of like the mix-up with USB slots on computers. Some are upside-down, others right side up. And it's a constant source of annoyance. Hardware manufacturers are horrible when it comes to observing standards.
Recommended Posts