Jump to content

John Brooks

Members
  • Posts

    10
  • Joined

  • Last visited

Everything posted by John Brooks

  1. I am using the OPIZp2:H5 for a small-volume retro-AppleII hobby project called VidHD which emulates an NTSC CRT on a modern 1080p HDMI TV. Out of 500x OPIZp2:H5 boards used for this project, we are seeing intermittent emmc boot failures on about 10% of them. On some boards, the emmc boot rarely fails (works 80%-90% of the time), while on other boards the emmc boot fails nearly every time. All these boards boot correctly 100% of the time from micro SD card. I am using mainline linux 4.20.8 with uboot 2019.01, built with buildroot. uboot 2019.01 is configured to disable networking and display/DE2. Disabling uboot video was recommended by Jernej because several boards had intermittent (presumably race-condition) failures in the linux HDMI DDC/EDID setup when uboot had already initialized HDMI. Some boards had frequent HDMI failures, some had few/none. Jernej was not able to reproduce the intermittent HDMI failure, but with so many boards, I have been able to test those boards which have high failure rates. Disabling uboot video has made linux HDMI DDC init work correctly every time, but it appears to have exposed or exacerbated the uboot emmc issue. Using a serial port to observe the boot log, uboot starts from emmc, loads the SPL, then fails to load the kernel. I have not yet investigated further. Log from emmc boot failure: U-Boot SPL 2019.01 (Feb 14 2019 - 13:45:37 -0800) DRAM: 512 MiB Trying to boot from MMC2 Log from emmc boot success (same board on the next power cycle): U-Boot SPL 2019.01 (Feb 14 2019 - 13:45:37 -0800) DRAM: 512 MiB Trying to boot from MMC2 U-Boot 2019.01 (Feb 14 2019 - 13:45:37 -0800) Allwinner Technology DRAM: 512 MiB MMC: SUNXI SD/MMC: 0, SUNXI SD/MMC: 1 Loading Environment from FAT... *** Warning - bad CRC, using default environment Net: No ethernet found. starting USB... No controllers found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc1(part 0) is current device Scanning mmc 1:1... Found U-Boot script /boot.scr 942 bytes read in 0 ms ## Executing script at 4fc00000 ... I will look at the emmc part number to see if that correlates with the boot failures. Edit: Almost all the boards that are failing to boot have emmc parts which end in GETF. There are a couple boards with a Samsung emmc ending in WEPD-B031. The Samsung emmcs are failing more often than the newer GETF ones, but both types work fine on some boards while other boards have high failure rates. Edit2: Below is my buildroot patch which disables uboot video & networking: --- a/configs/orangepi_zero_plus2_defconfig 2018-10-02 10:49:28.790123474 -0700 +++ b/configs/orangepi_zero_plus2_defconfig 2018-10-02 10:49:28.790123474 -0700 @@ -14,3 +14,17 @@ CONFIG_SUN8I_EMAC=y CONFIG_USB_EHCI_HCD=y CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y + +# VidHD +CONFIG_BOOTDELAY=0 +CONFIG_SILENT_CONSOLE=y +CONFIG_DISPLAY_CPUINFO=n +CONFIG_DISPLAY_BOARDINFO=n +CONFIG_SYS_CONSOLE_INFO_QUIET=y +NET=n +CONFIG_VIDEO_DE2=n +CONFIG_DM_VIDEO=n +CONFIG_DISPLAY=n +CONFIG_I2C_EDID=n +CONFIG_VIDEO_DT_SIMPLEFB=n + -JB
  2. BTW, I noticed that there is a USB-related patch which is disabled for both the 4.14 next and 4.17 dev branches: fix-usb-phy-probe.patch.disabled I enabled the patch as a test, but it throws compiler errors due to requiring a probe index: -int sunxi_usb_phy_probe(void) +int sunxi_usb_phy_probe(int i) -JB
  3. Both the next & dev branches contain identical overlay lines in /boot/armbianEnv.txt: overlay_prefix=sun50i-h5 overlays=usbhost2 usbhost3 USB is working with kernel 4.14.41 + u-boot v2017.11, but not with kernel 4.17.2 + u-boot 2018.03. -JB
  4. BTW, I built 64-bit 4.17.2 in the dev branch today and did some light testing using an Orange PI Zero Plus 2 H5. Most things worked well (816MHz, HDMI display, WIFI, LEDs). The only thing I saw that was nonfunctional was the USB ports. Looking at the DT, the USB ports & PHY are listed but disabled: usb@1c1b400 { phy-names = "usb"; resets = <0x3 0x13 0x3 0x17>; interrupts = <0x0 0x4b 0x4>; clocks = <0x3 0x22 0x3 0x26 0x3 0x5d>; compatible = "allwinner,sun8i-h3-ohci", "generic-ohci"; status = "disabled"; phys = <0x11 0x1>; reg = <0x1c1b400 0x100>; phandle = <0x36>; }; phy@1c19400 { clock-names = "usb0_phy", "usb1_phy", "usb2_phy", "usb3_phy"; reg-names = "phy_ctrl", "pmu0", "pmu1", "pmu2", "pmu3"; resets = <0x3 0x0 0x3 0x1 0x3 0x2 0x3 0x3>; clocks = <0x3 0x58 0x3 0x59 0x3 0x5a 0x3 0x5b>; #phy-cells = <0x1>; compatible = "allwinner,sun8i-h3-usb-phy"; status = "disabled"; reg = <0x1c19400 0x2c 0x1c1a800 0x4 0x1c1b800 0x4 0x1c1c800 0x4 0x1c1d800 0x4>; phandle = <0x11>; reset-names = "usb0_reset", "usb1_reset", "usb2_reset", "usb3_reset"; }; I'm not that familiar with DT, so not sure if the USB status is being disabled in u-boot and passed into the kernel, or if a kernel patch is needed to fix this. I'm happy to test potential fixes, else just passing along test findings. -JB twitter: @JBrooksBSI
  5. The H5 has a 1KB security ID at 0x01C14000 to 0x01C143FF. You could try using that for the unique CPU identifier. -JB @JBrooksBSI
  6. Thanks for the links jernej. Looking at the lowlevel BSP src files, the DE system sure has a lot of registers and functionality. With a footprint of 4 megs, it consumes more address space than any other H5 subsystem. It looks like the H5 support for 4.11 expects a simple framebuffer passed in from uboot, but it looks like the new uboot is passing an HDMI device entry to 4.13 instead of a framebuffer? It makes sense to have Linux create it's own framebuffer when HDMI is detected/activated instead of being a one-time event at boot. -JB @JBrookSBSI
  7. I built the mainline 'next' branch today (not dev) using the compile.sh UI option and targeting the OPIZP2-H5 board. It built and booted up fine using serial tty, though there were 2-3 boot log errors. The CPU was running at 768MHz and did not seem to scale with CPU load or thermals. With a heat sink attached to the H5, I was able to change the clock speed to 1200MHz via CCU reg 0 and it appeared to stick (ie, not altered by linux). Performance was about 33% faster at 1200MHZ compared to 768MHZ. FWIW, all 4 cores share one clock, so no per-core speed control on the H5. Wifi is working now on the Zero-H5. The missing items I noticed today compared to 4.11 were no HDMI console, and no /dev/sda* for mounting USB flash drives. It looks like the HDMI console is handled differently in the new uboot & kernel 4.13 (ie, no framebuffer@x device, but rather an HDMI device). Thanks for the rapid improvements on kernel 4.13. Impressive work. -JB @JBrooksBSI
  8. How do I select that branch during the Armbian build? I am currently using "./compile.sh BOARD=orangepizeroplus2-h5" which selects the icenowy 4.13 branch. -JB @JBrooksBSI
  9. That is why I was thinking of building the 4.11 version from source so I might compare its working wifi & HDMI console to the inoperative versions in 4.13. My expertise is more embedded systems/C/asm, so I didn't spot anything obvious in the shell scripts. All the --menu args appeared to correctly have 5 parameters. I am not sure where to find the source & OPIZP2-H5 config for that version. Can someone point me in the right direction? I saw another distro forum talking about an A0 and A1 firmware version for the AP6212. Any idea which version the OPIZP2-H5 needs and if that could be part of the problem? Can the (working) 4.11 driver be used with 4.13 or is there a compatibility issue? Other questions/findings: 1) I can't seem to find register info for the Allwinner Display Engine (DE) 2.0 in either the H3 or H5 TRM. I did find a reasonable description of the DE 1 registers in the A33 TRM, but it is a generation out of date and of questionable value. Anyone have tips on where to find DE 2 info? 2) FYI: I'm pretty sure there is a hardware bug in the H5 (and probably H3) SPI controller when configured in slave mode. The bug is that when the H5 empties the Tx FIFO, instead of sending bytes of zeroes on subsequent master-initiated transfers, it sends a repeating 4-byte pattern of zero bytes alternating with some of the last bytes the app wrote to the Tx FIFO - ie, Tx register is not properly cleared at FIFO empty which then causes retransmitted 'garbage' slave data. My current workaround is to end each SPI slave transfer with an extra 4 bytes of zeroes. Thank you for your help and pointers guys. -JB @JBrooksBSI
  10. I am interested in evaluating the work-in-progress Armbian for OrangePiZeroPlus2-H5 using the mainline kernel. The binary image "ARMBIAN 5.27.170614 nightly Ubuntu 16.04.2 LTS 4.11.1-sun50iw2" has worked well for me for several weeks and I would like to try building it from source. Any tips/pointers on where to grab the source and configuration for that version or is it just github master branch as of 5.27.17? I have pulled and built the latest in-progress 4.13 kernel version "ARMBIAN 5.32 user-built Ubuntu 16.04.3 LTS 4.13.0-sun50iw2", and would prefer to evaluate and contribute to fixing this codebase if possible. The head builds fine using the config "./compile.sh BOARD=orangepizeroplus2-h5" and the resulting image does boot. Here are the issues I've seen so far testing the master branch for OPIZP2-H5: 1) Boot errors: [ OK ] Started Login Service. Starting LSB: set CPUFreq kernel parameters... [FAILED] Failed to start LSB: Patch firmware for ap6212 adapter. See 'systemctl status ap6212-bluetooth.service' for details. [ OK ] Started LSB: set CPUFreq kernel parameters. root@orangepizeroplus2:~# systemctl status ap6212-bluetooth.service ● ap6212-bluetooth.service - LSB: Patch firmware for ap6212 adapter Loaded: loaded (/etc/init.d/ap6212-bluetooth; bad; vendor preset: enabled) Active: failed (Result: exit-code) since Mon 2017-09-11 18:17:48 UTC; 3min 53 Docs: man:systemd-sysv-generator(8) Process: 575 ExecStart=/etc/init.d/ap6212-bluetooth start (code=exited, status Sep 11 18:17:48 orangepizeroplus2 ap6212-bluetooth[575]: /etc/init.d/ap6212-blue Sep 11 18:17:48 orangepizeroplus2 ap6212-bluetooth[575]: /etc/init.d/ap6212-blue Sep 11 18:17:48 orangepizeroplus2 ap6212-bluetooth[575]: sh: echo: I/O error Sep 11 18:17:48 orangepizeroplus2 ap6212-bluetooth[575]: Can't get port settings Sep 11 18:17:48 orangepizeroplus2 ap6212-bluetooth[575]: Can't initialize device Sep 11 18:17:48 orangepizeroplus2 ap6212-bluetooth[575]: Can't get device info: Sep 11 18:17:48 orangepizeroplus2 systemd[1]: ap6212-bluetooth.service: Control Sep 11 18:17:48 orangepizeroplus2 systemd[1]: Failed to start LSB: Patch firmwar Sep 11 18:17:48 orangepizeroplus2 systemd[1]: ap6212-bluetooth.service: Unit ent Sep 11 18:17:48 orangepizeroplus2 systemd[1]: ap6212-bluetooth.service: Failed w 2) HDMI console is not working. U-boot draws text to the HDMI console at power up, but there is no output from linux afterward and the display reports no HDMI output signal. I'm using a serial tty console for now. 3) WiFi is not working. This is the major blocker for me to do more testing with the H5 & 4.13 kernel. root@orangepizeroplus2:~# nmcli g STATE CONNECTIVITY WIFI-HW WIFI WWAN-HW WWAN disconnected none enabled enabled enabled enabled Armbian config reports errors on the UI: I'd appreciate any tips on how to proceed and/or how I might contribute to fixing things. Thanks! -JB @JBrooksBSI
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines