Neil Armstrong

Hi @TonyMac32 I'm having a look at this. First, please apply these 2 fixes to remove the kernel warnings : https://github.com/freedesktop/drm-misc/commit/2bcd3ecab773f73211c45bb1430bb52ac641f271 https://github.com/freedesktop/drm-misc/commit/995b278e4723b26f8ebf0e7c119286d16c712747 (They will be backported to 4.19 in the next weeks) Can you try powering the monitor on an external power source, then power the board with the display already powered ? I have an issue with USB Displays, since the kernel enables the USB power very late, the monitor EDID is not available and the kernel fallsback automatically to 1024x768 resolution. This could explain why if you unplug/replug, it works. Powering the display *before* could solve this, the solution is to enable the 5V USB power from U-Boot. You can also try adding "usb start" in the boot script before starting the kernel. @guidolyour monitor seems weird ! Could you provide the EDID of the monitor ? Could you try this patch https://patchwork.freedesktop.org/patch/254756/ this should avoid the "*ERROR* Failed to set fbdev configuration" error ?

Hi @TonyMac32! thanks for these reports, I really near 0 report rate on the display support... so it’s cool to have something at least ! If you need to plug the displays after boot is because they depends on the usb 5v which is enabled too late in the boot and the display driver fails to get a correct EDID table for the monitor and falls back to 1024x768 which is not always supported by the small displays. The simplest way is to enable the 5v regulator from u-boot, but it needs a patch. can you give me the /sys/kernel/debug/dri content and the edid of the dvi adapter in /sys/class/dri/HDMI-A-1/edid for the cec issue, no idea at all !! On which board does this happens ? And on which monitor ? for the -5 clock issue, did you apply chewitt’s « clk_div3 » patch aswell ?

@TonyMac32 Here is a fix : https://lore.kernel.org/patchwork/patch/949665/

@TonyMac32 yeah, I know this one, and I need to solve it. Hopefullyt it won't harm, it's just a warning I need to solve and find time to solve it...

@TonyMac32 Yep I forgot this fix for the audio... for 4.18 you will need to take a rework of the audio driver since a lot changed in ALSA. The cpufreq error this is solved with https://patchwork.kernel.org/patch/10462135/ It’s the main issue for this error, and this solved it. I don’t have other cases for this error

@TonyMac32 this one is just a warning, it will disappear on 4.18 (4.19 ?) by itself, don't worry

Hi @TonyMac32 this patch will solve the issue on 4.17 and 4.18-rc3 : https://patchwork.kernel.org/patch/10462135/ it should be merged for -rc4 and hopefully be backported to 4.17 next week

@mboehmer great job ! I’m happy it’s finally working !

Power-Off and Suspend is managed by the same code. The code I linked is build in the "FIP" binaries packages with U-boot, these can be changed to match the platform. It's technically part of u-boot, but is build in the same time in the amlogic source tree. Under Linux, each driver would need to setup the registers to permit the Cortex-M3 to acknowledge the inputs and wakeup.

The wakeup from power-off is indeed managed by the Cortex-M processor with some code loaded in the boot time. This code can be modifier and is present in amlogic's u-boot source : https://github.com/BayLibre/u-boot/blob/n-amlogic-openlinux-20170606/board/amlogic/gxl_p212_v1/firmware/scp_task/pwr_ctrl.c#L184 But, it's linked to the Amlogic kernel implementation, and supporting it with mainline linux will need some work.

@TonyMac32 It's not an issue, u-boot will cycle over all mmc interfaces, numbers are unrelated, mmc0 is the first mmc interfaces, on Potato it's the SDCard.

@TonyMac32I took your changes and wrote the README to generate the binary and tested it, it worked like a charm ! https://github.com/superna9999/u-boot/commits/u-boot/topic/nanopi-k2 I can push them to uboot uptream if you can validate it also works on your side

@TonyMac32 Ok i didn't find the patch myself... There is no real magic in FIP. The problem is that HardKernel make some changes to the u-boot build system for the FIP stuff, but the K2 follows the "standard" AMlogic way to build it. So it should be more like the GXL based uboot, but for GXBB. Do you want to push the patch to u-boot upstream ? I can push it and retain your authorship if you want.

@TonyMac32 Hi, I just realized you were making a K2 port of U-boot. First, avoid 2018.03 since the MMC driver is buggy and crashes at boot, switch to 2018.05 or 2018.01. Did you push your code somewhere ? I'll be interested to have it pushed on U-boot mainline !

Hi @TonyMac32 I just pushed a 4.16 patchset : https://github.com/superna9999/meta-meson/tree/master/recipes-kernel/linux/linux-yocto-meson64-4.16

Yes this should be the scheme, default should be the last long-term kernel, next should be the last stable, and dev should be the current -rc kernel.

Ho @TonyMac32 this seems reasonable.

These names should be printed in the /sys/kernel/début/gpio if not there must be a mismatch in the number of entries. can you dump the dmesg somewhere ? Here is a sheet of all the pins exported by the potato board https://docs.google.com/spreadsheets/d/1uu09Fp14bJ9YhlEIYVn5R430V4p-v6A4SsAgdEem9EI To know the gpio number, the first bank with 10 gpios is the AO bank from GPIOAO_0 to 9. the second bank mapping can be found in the kernel header : https://github.com/torvalds/linux/blob/master/include/dt-bindings/gpio/meson-gxl-gpio.h

Beware using my 4.14 patchset to have it booting, I hope it will work with 4.15 mainline, but for sure it will for 4.16 If you stick with my 4.14 patchset it should work

Just FYI, mainline U-boot is ongoing, I hope Potato will show up in next version, meanwhile the following tree can be used : https://github.com/BayLibre/u-boot/tree/u-boot/libretech-cc

Good, please tell me if an issue appears with this patchset ! I cleaned it up because it was insane !

Hi, Mainline Linux has support for the SCPI Temperature Sensor, please check in /sys/class/hwmon/hwmon0/temp1_input For the hard crash, looking at the logs seems to indicate a memory issue, we will investigate further ! Thanks, Neil