TonyMac32

I'm wondering if CEC is part of the problem, I just disabled DW_HDMI_CEC on Amlogic to solve a similar (looking) problem.

Hi @Neil Armstrong, I'm at the day job (interestingly working with my colleagues in Toulouse), I will gather the requested information later, but for what I can answer now: It happened on both that have issue with hdmi powerup. I did not test the little 7" one until after I'd disabled CEC, since it is usually my "problem monitor". The K2, C2, and Le Potato were affected. I did not, but can. I realised they had both been applied while still getting boot loops so I got rid of the old patch early on.

2 changes are in queue on my workstation, one is u-boot 2018.11, the other is updating the Dev patchset and beginning to iron out 4.19 Kernel. The first I honestly don't see any issues with moving forward, but want people to know about it, the second is a bit of a hairball and I'll need some help with debugging, and in fixing. Detail of changes: U-boot: Currently Meson64 and Odroid C2 are using 2018.05 and 2018.07, respectively. I will be moving all to 2018.11, and eliminating the "specialness" of the Odroid C2 in our build system, so Meson64 will be inheriting the C2 boot script under the "Meson64 name, it will no longer have its own u-boot patch folder/etc. The board will finally be fully integrated into the Meson64 configuration, although it will still have the special Odroid firmware blob (all Amlogic SoC's have their own blobs, so no special changes need made to allow for the C2 to have a different one than the K2) Current Concerns: packaging scripts on 4.14 kernel are not creating a symlinked named "Image" for the updated boot script. I didn't consider that and only caught it today. U-boot is obviously unimpressed. Kernel 4.19: This will eventually become the "Default" kernel, once it has been debugged and proven out, as Amlogic Mainline kernels can now be easily patched with full video decoder support (already done), and Mali support is available (I need to finish integrating that, later date) Current concerns: -HDMI displays seem to be a sore spot, I have 1 that works flawlessly (hilariously a 7" waveshare-like HDMI), while the other needs to be plugged in after boot to work, and an HDMI-DVI adapter one is nonfunctional. (it seems to think it's attached, but no image) - I am getting a million "failed to change cpu frequency: -5" errors again. The clock marked as critical fix is in there, needs verified as it looks different than the old one. - I had to disable CEC entirely to get the system to boot with a display attached, it would fault, reboot, fault, etc. Plugging in a display after boot yielded an oops. No CEC = that problem is gone. Tagging @Neil Armstrong, for tracking if interested/have ideas. I'm using Neil's always helpful meta-meson patchset, these were squirreled away in "next" so I assume they are not complete/some WIP, so this can be some good feedback/etc. No one can break things like an end user.

Looks like u-boot 2018.11 is viable for all Meson64 boards, oddly enough USB works on C2 from boot with this U-boot, but now USB on K2 does not. I've got quite a bit of cleaning to do, C2 doesn't need it's own top-level u-boot patch folder/etc. [edit] It looks like CEC is crashing the board, disabling any mention of it in the config makes it boot successfully, however the HDMI doesn't want to come up either, unless you boot without the HDMI plugged in, and plug it in after Linux is up. Then you can have a 4K 30Hz desktop if your monitor is so capable. HDMI --> DVI on my Acer monitor though, a no-go. [edit] My 7" Waveshare HDMI worked from boot.

I do not think the K1+ has an RGB controller broken out on the gpio. That isn't a controller hat, it's just an adapter to go from the 0.1" header to the flat cable for the LCD.

I have a CoCo 2 and a Model 100 Portable.

The nand-sata-install script does that adjustment for you, that's the issue I think. https://github.com/armbian/build/blob/master/packages/bsp/common/usr/sbin/nand-sata-install#L205 I'm building a model train speed controller to replace the 1970's one that just failed on my son, a bit distracted. :-)

OK, so, for you/anyone doing this before it's officially baked in: Download 4.18 image Build newest 4.18 kernel/u-boot update boot script with the one currently in our repo reboot (because of superstition) run nand-sata-install I would recommend being on the moderately advanced side before attempting it, unless you really want to experiment.

Wouldn't boot from eMMC or from SD? It should still work from SD with old boot script, just not from eMMC.

I think wait until 4.19, I was working with @sbc_chrisb to get an image with the typical Armbian package support (kernel/etc). The updated boot script and a fresh 4.18 build can identify and install armbian to the eMMC without boot issues. I assume the issue being seen by Chris has to do with the older image being updated, as you mentioned. Just for sanity I booted my Le Potato up with only the eMMC present again to make sure. ;-) Rebuilt images should work, if you would want to test (assuming you have an eMMC...)

Not expected, root dev should be modified in the armbianEnv.txt file. Sent from my Pixel using Tapatalk

I would agree with that, but some of these are simple enough with the documentation in the kernel. The C2 appears to be set up for overlays, I'll have to experiment with that as well.

@mboehmer I am tempted to try just pulling that out of the device tree and making it an available GPIO with a rule attached, in case anyone wants to shut down the extra USB's.

Tritium tested, fixed (DTS/config in u-boot back-ported from 2018.09), and complete with "testings" files merged. I see NanoPi K1+ is done already, so my work here is done. :-)

The RK3328 has proven to be a bit of a tough SoC for support due to incomplete upstream support. Well, as time permits, more or less. Remember that we do a lot of kernel and platform work to bring Armbian to the world (more the others, I'm a minor character). With such a small team, unfortunately the result is a limited group of baords receive better support than others, or you wind up with "focus kernels" where, as we recently decided with Odroid-C2, the vendor legacy kernel is simply abandoned in favor of simply using mainline to reduce workload and problems. In an ideal world the manufacturers of boards who want to see Armbian support would provide a headcount and/or some sponsoring for the project. There are some small examples of that, and some nearly equivalent situations like Libre Computer and the BayLibre team with mainline Amlogic support. For the large part though, you get one-off boards that simply take more resources than they are worth (we just purged a bunch of those) The greatest way you could give your thanks is to pitch in and test what we've created and report back, providing proper logs/etc, and sharing projects on the forum to help build community and hopefully get some more involvement from others to keep the project healthy.

Hmm, I see it is not enabled. I will enable as module/build it to test for future, our other kernels have it. eMMC has a partition format unlike SD, so there is a boot and an environment partition, if I remember correctly.

I have Tritium series.

Yes, the Next images are 4.18, I will be turning my attention to 4.19 and it will eventually become the default image. I don't mess with the building if official images (honestly don't know if I can/how), so that will be Igor's decision. Sent from my Pixel using Tapatalk

Hmm ok. I have not been tracking the development/maintenance of the nand-sata-install, it took about 45 minutes for mine to get to the "reboot now" screen. I was using a 4.18 Stretch build.

Also forgot, you need to run the command that is commented in the bottom of the cmd file to create a script file out of it Sent from my Pixel using Tapatalk

This I have not experienced, I used it for some web browsing/etc. Any logs of the crash this time? Sent from my Pixel using Tapatalk

I am using the image family you would find on the Armbian download page, you are correct that the configuration of Balbes' images are different. Whenever the next round of images are made this update will be included.

This should just need a bootscript update to work properly under standard Armbian. I ran nand-sata-install and the board boots, but the script isn't ready for it and tries to load everything from SD even though it doesn't exist. [update] https://github.com/armbian/build/commit/cfd8a8956814a2f9da465769c1f9f5ad49e369cc This boot script takes care of eMMC and has overlays baked in, that I need to experiment with/test. File size set to 102400 kB Record Size 4 kB Record Size 16 kB Record Size 512 kB Record Size 1024 kB Record Size 16384 kB Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Output is in kBytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 kBytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 4 14931 15285 18479 21632 17644 13118 102400 16 20817 25509 43118 43201 39345 23868 102400 512 26357 26404 76260 76124 76281 26328 102400 1024 27718 27917 77808 77832 77815 27793 102400 16384 27825 28640 81196 81216 81233 28761

Split cold non-booting issue to own topic, still need to review HDMI topic. In other news, I noticed my 4.14.80 install mentioned I had an SDR104 SDHC and that it had successfully tuned the phase, not something I remember seeing before (haven't looked in a long time) So with the typical iozone parameters I got > 66 MB/s random read, and > 58 MB/s random write. Not too shabby. (SD Card: SanDisk Extreme 32 GB U3) File size set to 102400 kB Record Size 4 kB Record Size 16 kB Record Size 512 kB Record Size 1024 kB Record Size 16384 kB Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Output is in kBytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 kBytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 4 3228 3295 12302 12802 11459 5036 102400 16 10544 10785 30695 30729 30434 15796 102400 512 51482 50931 62070 61959 61823 48392 102400 1024 58030 58118 63218 63221 63333 53391 102400 16384 57062 60069 68049 67967 68066 59411

Split from main discussion as this appears to be a specific problem. Re-created the symlink patch so future updates won't break.