TonyMac32

As far as no boot after cold start, @Tido, I have to ask if you added "fdt_file=rk3288-miniarm.dtb" to the armbianEnv.txt file at some point, or if you upgraded from the 4.4 kernel. There was a link in place so anything looking for rk3288-miniarm.dtb would get forwarded to the rk3288-tinker.dtb, @Igor had added it when the file names didn't match between mainline and Rockchip/ASUS code. I can't remember where/how exactly it was stuck in there, but that could be it. <--Found it: https://github.com/armbian/build/commit/9dbc69e0ed609185abbaf28144db714684b1f395#diff-92fd175af58f1b9b7cf350b58398929d If you change the armbianEnv.txt file to have "rk3288-tinker.dtb" it should work. Curiosity, how long have you been maintaining/upgrading this particular install? None of mine go more than a couple weeks due to testing/etc.

Fascinating. Well then.

Why on Earth is it looking for miniarm dtb... Sent from my Pixel using Tapatalk [Edit] Hang on, why is it showing u-boot from mmc and showing 2 mmc devices? Is this a tinker S?

I can't imagine that being on purpose, sounds like an environment issue rather than a BSP package issue though, So it's not my department. [edit] My 4.14.80 build does not have any issues with bringing up LAN on boot.

I've found something additional, it appears the vendor U-boot toggled the line low to assert reset, then brought it high upon the driver being configured. I don't see any evidence of that happening, and using the datasheet I'm less than certain about trying to do that given this: https://github.com/trini/u-boot/blob/master/arch/arm/include/asm/arch-meson/gx.h

The sound on these boards is thanks to a set of patches by @JeromeB as part of the work on the Amlogic SoC's. I have not spent enough time with 4.18/4.19 to know what is going on there exactly, I have, however, updated patches recently to match the current recipes by BayLibre, I think sound may be available now (as of 4.18.16). I don't know if any build has taken place since then, but the kernel has other issues, so it may not be wise to change yet.

My comment was that I got a random reboot with the default image: I was not exceptionally clear, this was without using@JMCC's script, demonstrating something wrong with the kernel. Sent from my Pixel using Tapatalk

@Tido I would suggest to take a step back. Relating one's experience and results is perfectly fine, as well as replying to such information reasonably. I also caution that my experience with 4.14 is of course with my hardware, not with your hardware. Now then, I will have some time to review the bsp, at least the rockchip-specific part, directly. We can then reasonably and *with civil discourse* discuss the path forward. I would very much like the dmesg output you get when plugging your monitors in, and of course any serial debug output you can provide on failed boot events. Sent from my Pixel using Tapatalk

It would seem booting it without the HDMI attached and adding it later works. Then, if you build your own kernel, install the dtb's. Now remember my testing was not exhaustive. @Igor has there been any issue with Allwinner HDMI recently? This board and the Amlogic SoC's use the DW-HDMI, and Amlogic is a mess with HDMI right now as well. Probably unlikely, but seems odd. Sent from my Pixel using Tapatalk

I'll have to get my house in order (Mess-on 64) and Rocktastrophe), this board does look interesting, although that M.2 seems awkward, and the typical "both sides must be smart" statement for the USB-C PD. There will be a lot of low-information users having problems with this board.

It is extremely helpful that this is billed as a low-cost S905X. What I've read so far just basically says it's a clocked down Meson GXL with a few missing hardware supports (Max 1 GB RAM, 1080p, simpler vdec, etc). So software support should be mainly the same drivers, just a sparser device tree (I'm obviously glossing over some specifics that could be theoretically be an issue, but this is nothing like using an all-new SoC).

This week we discontinued the default 3.x kernel for the Odroid C2, and are working on the 4.18/4.19 kernels. A few odds and ends have come up, the biggest one appears to be the gpio-hog in the C2 device tree somehow not working, causing the USB hub on the board to never be powered on. root@odroidc2:/sys/class/gpio# cat /sys/kernel/debug/gpio gpiochip1: GPIOs 378-496, parent: platform/c8834000.periphs:pinctrl@4b0, periphs-banks: gpio-392 ( |mdio-reset ) out hi gpio-407 ( |reset ) out hi gpio-422 ( |cd ) in lo gpio-465 ( |TFLASH_VDD ) out hi gpiochip0: GPIOs 497-511, parent: platform/c8100000.bus:pinctrl@14, aobus-banks: gpio-500 ( |TF_IO ) out lo gpio-501 ( |usb-hub-reset ) out hi gpio-502 ( |USB_OTG_PWR ) out hi gpio-510 ( |c2:blue:alive ) out lo The hog claims it is there, but I get no power to the port. The other is the HDMI output becoming extremely fussy about the sort of monitor it's been given. [update] On the NanoPi K2 I actually get a crash on boot with my HDMI --> DVI adapter monitor. With both monitors, if plugged in after boot, desktop displays (on C2 only the pure HDMI monitor will display at all), but a fault occurs: FYI @Neil Armstrong

Sometimes people can get preview parts, these boards don't just go from draft table to production very often, there are usually beta parts. Ugh, @chwe you may be right.

Agreed. I was working through the changes slowly (along with some other stuff). If you can do as you said above, go for it.

Now that this is getting closer to physically existing (ideally I'll have one soon, whether we support it here or not) 1) No SD initially worried me because of the normal proprietary loaders/etc. However we support FEL on Sunxi, UMS on Tinker, and @Neil Armstrong / BayLibre is shoving a ton of patches to get the Amlogic USB boot support into u-boot (2018.11?) 2) SPI flash for u-boot, or at least the u-boot environment. I don't have all the details, but if done correctly this board could keep a consistent hardware profile across distros (MAC address/etc). ASUS tried this halfway, but didn't go full on for a SPI flash boot. 3) The SoC is a Meson64, and has nothing to do with an S805, so think low-power S905X 4) This thing should be able to run in very low power mode, assuming the Amlogic blob behaves.

No worries, I was testing to try to remove u-boot from the list of things that might be wrong.

The C2 was using a different recipe for a while that might still have ttyS0 hiding in it, I have a few irons on the fire at the moment, I'll take a look if I get a moment

OK, So for the boot issue, I just booted against every display in my home, including 2 televisions, no issues with the 4.14 kernel (4.14.80). That, in my opinion, rules out u-boot to the extent that I can test. Given my experience with the 4.4 kernel, I am of the opinion that it can't get any worse than it is, especially since we've been mangling the shite out of it to try to keep up with Rockchip and made one hell of a mess. @JMCC if you have tested the 4.4 you've frozen so far, we can get that up to feature parity and move forward. We can't keep dodging Rockchip updates, and we can't go back to the old MQMaker kernel because it's old enough to have moss growing on it. I'll take a look at the patches and see which ones go where and how much work we're in for, things like the reboot I think need a complete rework, some of the later Rockchip work fixed it in a more correct fashion if I'm reading properly.

Fair. I need to do a build and take a look at where it lies. Sent from my Pixel using Tapatalk

I did a small test on the 4.4 image, it would actually shut down randomly without provocation, so there is something there to work out. :-/. As for these HDMI issues so far no luck reproducing it, I got a false positive by accidentally using the cable for my Arduino programming (activated UMS). I'll pull the non-standard resolution one off of my other project and see if that works.

There are 2 video related updates in the last 5 months in u-boot, one was a patch from ASUS doubtless for Rockchip's fork of U-boot, which does mess with the ddc channel: https://github.com/armbian/build/blob/master/patch/u-boot/u-boot-rockchip/board_tinkerboard/0017-Fix-HDMI-some-issues.patch Specifically: @@ -340,7 +340,7 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, u32 mpixelclock) hdmi_phy_i2c_write(hdmi, hdmi->mpll_cfg[i].cpce, PHY_OPMODE_PLLCFG); hdmi_phy_i2c_write(hdmi, hdmi->mpll_cfg[i].gmp, PHY_PLLGMPCTRL); - hdmi_phy_i2c_write(hdmi, hdmi->mpll_cfg[i].curr, PHY_PLLCURRCTRL); + hdmi_phy_i2c_write(hdmi, 0x0000, PHY_PLLCURRCTRL); hdmi_phy_i2c_write(hdmi, 0x0000, PHY_PLLPHBYCTRL); hdmi_phy_i2c_write(hdmi, 0x0006, PHY_PLLCLKBISTPHASE); @@ -560,8 +560,8 @@ static int hdmi_read_edid(struct dw_hdmi *hdmi, int block, u8 *buff) u32 n; /* set ddc i2c clk which devided from ddc_clk to 100khz */ - hdmi_write(hdmi, hdmi->i2c_clk_high, HDMI_I2CM_SS_SCL_HCNT_0_ADDR); - hdmi_write(hdmi, hdmi->i2c_clk_low, HDMI_I2CM_SS_SCL_LCNT_0_ADDR); + //hdmi_write(hdmi, hdmi->i2c_clk_high, HDMI_I2CM_SS_SCL_HCNT_0_ADDR); + //hdmi_write(hdmi, hdmi->i2c_clk_low, HDMI_I2CM_SS_SCL_LCNT_0_ADDR); hdmi_mod(hdmi, HDMI_I2CM_DIV, HDMI_I2CM_DIV_FAST_STD_MODE, HDMI_I2CM_DIV_STD_MODE); And another to simply enable the u-boot bring-up of the video hardware, because the kernel no longer seems to want to take responsibility for that task: https://github.com/armbian/build/blob/master/patch/u-boot/u-boot-rockchip/board_tinkerboard/101-u-boot-0002-rockchip-tinker-enable-rockchip-video-driver.patch I need to verify I can get the fault, then try to squash.

Hmm, I haven't either. I'll be looking at this here in a little bit.

Do you know if FriendlyELEC has a script or a key mapping associated with that gpio? It may be something as simple as that.

No worries, I don't like that something is wrong, like I said I think it is spilling over into the kernel and needs to be addressed.

Ok, that gives me a direction, the kernels are having I2C problems now too that were noticed. I'm going to make the crazy guess it all lies in U-boot.