TonyMac32

I applied that to get my board booting, but those errors still show up.

I second Igor's statement, I use an i7-3770 for the job. Sent from my Pixel using Tapatalk

@Neil Armstrong I found the audio crash/hang issue, Jerome put in the fix due to the divider being base 1, which got audio working again. The CPU frequency errors are still present however: cpufreq: __target_index: Failed to change cpu frequency: -5

The only time I ever built any kernel in the cloud was good old Narcissus with Angstrom for my Mini2440. I'm afraid I don't know of any free resources (or any resources) to do this with Armbian.

Well I can't get it to build again, so... I promote no such thing. I said commonize, which is quite different.

We have no options as far as security updates go in the kernel, we can't build it to add them. As long as Ayufan's kernel hasn't mucked around with anything that could break the rk3288 this won't be too difficult. Would the direction then be to commonize things in a similar fashion to Sunxi, or simply use the same kernel each with their own patchset (any common to all devices should be pushed to Ayufan anyway)? Sent from my Pixel using Tapatalk

That's fine, I'm not too worried about the work needed, I've made the board work with 2 different kernel sources at this point, and mainline, and almost (at least in between commit-tastrophe's) the current Rockchip one. As long as the thingy is stable and behaves itself we're good.

I'll have to give that a look and try it.

I planned on doing that on their next release tag, but then the completely screwed up every aspect of their source code before pushing another tag. They also don't squash commits to keep things in chronological order, so a commit dump from them can very easily modify past "clean points". It's basically an unacceptable situation for anyone planning to use the code for anything.

4K, VPU, touchscreen as of last functional kernel Theoretically camera as well, but I never got that working Now, I should, with some time, be able to get touchscreen and camera on mainline for Tinker. I think only @Myy can speak about VPU prospects.

no, you're not. :-/ Also, Rockchip-default imploded again, something about the rockchip efuse driver and of_videomode driver illegally sharing values and spreading cyber diseases... When "Microsoft" lets us have github again I'll just disable literally everything and see if it will work. (OK, just the efuse driver)

I'm not so sure of that, are you getting nothing from the serial port at all?

Hmmm ok, it pops up before all the clock-related errors is all. Any guidance as to what is causing that?

Let me try it again, the image from Igor had no issues of that type, but I haven't tried to rebuild myself in a day or two. Sent from my Pixel using Tapatalk

Yep, just checked the potato I left running overnight, I have general sound core failure, I'd say to be conservative I have about 197 billion errors pertaining to not being able to set the I2S clock rates and a trace. Disabling the sound card for now then as well. OK, found a relevant error I think: [ 1.589945] gxbb-clkc c883c000.clock-controller: failed to get HHI regmap - Trying obsolete regs @Neil Armstrong I'm looking through patches to see if something is pending for this regmap area, but won't have a ton of time today.

:-/. I had an oops while the system tried to set the I2S clock while DVFS was disabled, and noticed a short hang there a couple times during startup (hang at simple sound card). I saw (I think), a patch about that, going digging....

That did the trick, and is applied to next. @Igor take a look, I don't know if that other patch is necessary or not now, I did some general cleanup as well if you want to try it out.

That works, but I'm still curious if anyone else is having this issue, or if @Neil Armstrong has seen it on 4.17...

How many times can you recycle HDPE, and what is the process? :-P. Plastics are quite cheap to make, and relatively low energy. It's the disposal and reuse that becomes the problem. My point was, Aluminum is aluminum forever, unless some of the neutrons decay Plastic waste is, well, garbage.

@Igor can you verify that an image you build today for Le Potato Next will boot? I'm hanging on dvfs, I tried with and without that scpi regression patch, no change. Starting kernel ... domain-0 init dvfs: 4

My system was still building old images, why? Good question. I'll double check today though, I also can't get Le Potato to boot at all on 4.17, which doesn't make any sense, it looks like DVFS is hanging it, which also doesn't make sense. Sent from my Pixel using Tapatalk

Patch added to next and dev,

Well, if the manufacturing is done intelligently, the tailings get recycled nicely. You could argue the energy involved in it, but I'd probably counter the cast ones use far more energy than simply machining out of large blocks. In general aluminum and steel are quite "eco" compared to any plastic, and certainly better than say copper as far as mining/refining are concerned. (off topic, but interesting)

U-Boot 2018.05-armbian (Jul 02 2018 - 00:54:54 -0400) Model: Tinker-RK3288 DRAM: 2 GiB PC event = 0x20 usb connected to SDP, force enter ums mode rk3288_maskrom_ctrl: enable_emmc = 1 usb_current_limit_ctrl: unlock_current = 1 MMC: dwmmc@ff0c0000: 1, dwmmc@ff0f0000: 0 Loading Environment from EXT4... ** Unable to use mmc 0:auto for loading the env ** Failed (-5) In: serial Out: serial Err: serial Model: Tinker-RK3288 Net: failed to enable clock 0 No ethernet found. UMS: LUN 0, dev 0, hwpart 0, sector 0x0, count 0x1d5a000 \wait for usb get descriptor cmd timeout rk3288_maskrom_ctrl: enable_emmc = 0 usb_current_limit_ctrl: unlock_current = 0 Hit any key to stop autoboot: 0 Card did not respond to voltage select! switch to partitions #0, OK mmc1 is current device Scanning mmc 1:1... Found U-Boot script /boot/boot.scr 1498 bytes read in 17 ms (85.9 KiB/s) ## Executing script at 00000000 U-boot loaded from eMMC 178 bytes read in 14 ms (11.7 KiB/s) 41042 bytes read in 35 ms (1.1 MiB/s) 4908082 bytes read in 238 ms (19.7 MiB/s) 9272512 bytes read in 433 ms (20.4 MiB/s) ## Loading init Ramdisk from Legacy Image at 21000000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 4908018 Bytes = 4.7 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 01f00000 Booting using the fdt blob at 0x1f00000 Loading Ramdisk to 0fb51000, end 0ffff3f2 ... OK Loading Device Tree to 0fb43000, end 0fb50051 ... OK gets right to starting kernel. The delay is the dev kernel I was building.

I tried it last night without any UART connection, it took it about 5 minutes to boot. So I'm not certain what's going on, I have some other stuff to work on first in any case.