4.12.0-rc4 Kernel: Reboot does not work

[sghazagh]

Kernel 4.12.0-RC4 is compiled successfully and boots the Tinker Board just fine. Thank you for adding WIFI to, so WIFI is working just fine as well.

However, REBOOT does not restart the board and after turning off the device, cannot get it up again! I have a same issue if I use "echo b > /proc/sysrq-trigger" as well.

[Miouyouyou]

The new kernel will be delayed to tonight (UTC) as I had to spend a few hours dealing with multiple versions of (crashing) Firefox... instead of doing anything productive.

[Tonymac32]

But technology always makes life better! ;-)

[Miouyouyou]

... When it works ! :smiley_cat: I've added more logging when voltage is modified by the rk808 driver and when the MMC driver is removed, or shutdown.

Test the new image with a serial output, power the machine off and see if there's anything useful in the logs. Added logs have been prefixed by "( Myy )" characters.

[resipat]

Hi, are there any updates about the reboot problem? It seems to be a general problem with all kernels except the original of TinkerOS. My problem is: I'want to use DRBD on Tinkerboard and with standard TinkerOs the kernel module isn't available. I'm not able to compile it by myself without compiling a complete new kernel --> reboot problem.

I'm a totally novice in kernel and module compiling...

Thanks!

[Miouyouyou]

No, currently, as it stands, I need to have someone :

• boot the Tinkering branch kernel, with the rockchip_tinkerrebootfix=on option, while using a serial console
• reboot the machine and provide me the logs printed on the serial console.

[Tonymac32]

The current 4.4 kernel in Armbian has the reboot fix included, if you look there that may solve it short term by recompiling using the Armbian build system. (I maintain the Tinker Board BSP at Armbian) As far as 4.12 goes, it has been a strangely difficult problem.

[resipat]

Maybe I'm able to post some logs from serial console today.

[resipat]

Hello Miouyouyou,

here are some log files. The first one is the reboot Log with original Kernel, the second one is serial output from 4.12 Kernel with your Logs. There's not much to see..

If I can assist you again, you just have to say it. TinkerOS_Kernel_4.4_reboot.txt Kernel_4.12_reboot.txt

[Miouyouyou]

I see that the fix is clearly trying to set up the MMC voltage... However, I'm not showing the value returned by regulator_set_voltage, so I don't know if it succeeds in doing so...

Anyway, thanks for the report. I'll try to create a Tinkering branch on the RockMyy repository in order to analyse this issue on the 4.13-rc1. At the same time, I'll create a bug report on Linux Bugzilla, as the arm-soc team should clearly investigates this issue.

[elar-systems]

Guys, ASUS has fixed the issue which I had reported while ago regarding "echo b > /proc/systrigger" causing the TB to not reboot properly. here is the commit: https://github.com/TinkerBoard/debian_kernel/commit/15a531028f80eef8f2385173ec39d370cac88486

Have a look you might find something helpful guide you to fix the reboot issue for kernel 4.12.y.

cheers,

[Tonymac32]

That may actually be useful, I'll take a look, although declaring all reboots "emergencies" seems extreme...

[Tonymac32]

Actually, that looks identical to the hack, functionally. Of course my phone isn't the greatest analysis tool. ;-)

[Miouyouyou]

Well, it's almost identical, however, it also re-enable the regulator... I'll try this tomorrow.

[Miouyouyou]

Also, it power off the MMC driver before re-enabling it... Yeah, that's a bit different but, who knows, that might work.

[Tonymac32]

I was going to say, it's starting to get a bit late for you, isn't it? I stay up til around 1:00 typically. I will give it a shot as well, we can compare notes. Also, starting work on 4.13.

[Miouyouyou]

Well, it's actually 23:00 here, but I didn't really see the time flied today with the new repositories, and advertising the new releases on various forums. Not counting that I share the Mali patches on the ARM Community.

Anyway, if you can give it a try, I can try to quickly set up a patch for the 4.13 kernel now, yeah. You'll have to endure a full kernel compile run though, as uploading a new kernel build branch will take me between 10 and 30 minutes, just for the upload. (´・ω・`　)

[Miouyouyou]

Here's the new patch. It compiles but I haven't tried it yet, on any board (aka if it crashes, catches fire and your house is suddenly invaded by rabid raccoons, I'm not responsible).

https://gist.github.com/Miouyouyou/1a4e49f7b32bc14afe57e78fea4b97af

[Miouyouyou]

The patch has been integrated to the new Tinkering branch of RockMyy : https://github.com/Miouyouyou/RockMyy/tree/Tinkering

[Tonymac32]

Well, since I have racoons in my chimney right now... (Waiting for the babies to get old enough to get out, then sealing it.)

[Miouyouyou]

As long as they don't become rabid, I guess it's okay.

[Miouyouyou]

Well, I'll go to sleep for now. If you'd like to try the new Tinkering branch and see if it solves (or not) the reboot issue, here it is : https://github.com/Miouyouyou/RockMyy/tree/Tinkering

If it doesn't work, I'll appreciate some logs though :C

[Miouyouyou]

You can now grab a fresh build incorporating this ugly hack here : https://github.com/Miouyouyou/RockMyy-Build/tree/Tinkering

Test it and see if it resolves your reboot issues.

[resipat]

Hello, bug is still alive, logfile is attached.

Kernel_4.13_reboot.txt

[Miouyouyou]

I'll try to log the voltage of the MMC after applying the hack this week, see if the hack is doing what it's supposed to do. I'll also try add some logging near mmc_power_off, to be sure that it's not powered off just after.

If that doesn't work, the issue might be somewhere else I guess. The fact that power hack worked on a modified 4.4 kernel might be due to a side effect generated by all the patches they previously applied.

[Tonymac32]

https://github.com/armbian/build/blob/master/patch/kernel/rockchip-dev/9300_Tinker_Reboot_Hacks.patch

Added the mmc_power_off(mmc) call to the other hacks and it worked. Apparently the shutdown on newer kernels isn't certain by the time platform shutdown is called, so this makes sure. @wzyy2 , perhaps the Rockchip Linux patch should be updated to make sure the powerdown happened as well to avoid future complications?

[sghazagh]

@Tonymac32: That's a good news. Well done! So Moiyouyou, please let us know when you applied this in a master or a clean branch then we can final test on Tinker Board with all your patches for kernel and Mali driver. Hope we can close this issue soon then...

[Tonymac32]

Don't cheer too quickly, this fix is broken again in 4.13 due to it's hackish nature (actual build failure), I'll see if I can track down the specific issue, however it works on 4.12.

[sghazagh]

Seriously! that's disappointing! :(

[Tonymac32]

On the bright side 4.12 is the stable mainline. 4.13 is only RC1, so hopefully we can get this sorted before final.

@Miouyouyou I see you did the same in your 4.13, confused? It looks like it was called based on the log by @resipat. I thought maybe it hadn't gotten hooked into the platofrm driver since I didn't see the ".shutdown = ..." in the patch...

[Miouyouyou]

Well, in my version, the member is only set during the interception of the rockchip_tinkerbootfix parameter.

static int dw_mci_rockchip_setup_tinker_reboot_fix(char *str)
{
    if (strstr(str, "on")) {
        printk(KERN_ERR "( Myy ) Enabling Tinkerboard's reboot fix !\n");
        dw_mci_rockchip_pltfm_driver.shutdown = 
            dw_mci_rockchip_platfm_shutdown;
    }
    else 
        printk(
            KERN_INFO "( Myy ) Not enabling Tinkerboard's reboot fix\n"
        );

    return 0;
}

__setup("rockchip_tinkerrebootfix=", dw_mci_rockchip_setup_tinker_reboot_fix);

However, maybe it will act differently if the member is set directly ?

Could you just test with this addition in the dw_mmc-rockchip.c and without setting the shutdown member directly, see if that makes a difference ? Of course, you'll have to add rockchip_tinkerrebootfix=on to the kernel boot parameters

I didn't add the emergencyReboot part in my patch, so the issue might be there in my version.

Anyway, I'll try to readapt my patch to add this part and try to release something between tonight and tomorrow.

[Miouyouyou]

Also, I'm pretty sure your patch doesn't compile due to a small change in the MMC structure members names. cur_slot has been replaced by slot in recent versions, since there's only one slot on these boards MMC.

[Tonymac32]

I agree on the last point, I was running out of steam and didn't want to hunt it down last night. I missed the conditional assignment, I'll try it out. In the meantime, are you able to compile Armbian, or would you prefer I build an image and give you a link to it to test just having it enabled on the MiQi? It could have been an adverse reaction to whatever made the patch not work that hung the board.

[Miouyouyou]

If you got a binary build, I'm all for it, since I don't have the armbian installation scripts prepared right here. (And I don't think the entire armbian image can be built with only 8 GB of disk space.)

I'll modify my patch meanwhile.

[Miouyouyou]

I'm writing the new patch right now but I never took a look at kernel/reboot.c in the end.

There's an option you can pass to the bootloader to specify which reboot mode you want.

The option is reboot=X

where X is either w (WARM), c (COLD), h (HARD), sN (SOFT) where N is a number, smpN where N is a number, g (GPIO), b a k t e p set the variable reboot_type which is known to bypass some checks, f (FORCE).

By default, unicore 32 bits ARM systems use the hard reboot mode. It's not clear for the rest.

Has anyone tested any of these flags to see if it improved the situation ? Test the flags with a clean kernel, BTW. Either take the main MiQi or RockMyy branch kernels, not the Tinkering ones, if you want to test the reboot=X flag.

Anyway, the hack should be ready in ~1H.

[Miouyouyou]

https://github.com/Miouyouyou/RockMyy/tree/Tinkering ready ! https://github.com/Miouyouyou/RockMyy-Build/tree/Tinkering ready !

The fugly patch with more logs !

https://github.com/Miouyouyou/RockMyy/blob/Tinkering/patches/kernel/v4.13/0005-Fugly-MMC-hack-trying-to-resolve-Tinkerboard-s-reboo.patch

[sghazagh]

Tried your build on "RockMyy-Build" for 4.13.1-rc1. Reboot does not work!

[Miouyouyou]

Then, provide the logs.

[wzyy2]

Tried your build on "RockMyy-Build" for 4.13.1-rc1. Reboot does not work!

I guess you didin't add "supports-sd" in sdmmc node. "supports-sd" is a rockchip-defined property and upstream dts don't have that.

[Tonymac32]

It should look something like this, assuming there haven't been binding changes I have missed. That's why I haven't used the upstream dts except as a very simple starting point.

&sdmmc { bus-width = <4>; cap-mmc-highspeed; cap-sd-highspeed; sd-uhs-sdr12; sd-uhs-sdr25; sd-uhs-sdr50; sd-uhs-sdr104; card-detect-delay = <200>; disable-wp; / wp not hooked up / num-slots = <1>; pinctrl-names = "default"; pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_cd &sdmmc_bus4>; status = "okay"; supports-sd; vmmc-supply = <&vcc33_sd>; vqmmc-supply = <&vccio_sd>; };

[Miouyouyou]

Ah, thanks for the informations !

However, turns out I already did that, in another patch that I should definitely split : https://github.com/Miouyouyou/RockMyy/blob/master/patches/kernel/v4.13/DTS/0007-Enabling-Tinkerboard-s-Wifi-Third-tentative.patch

If the kernel does not reboot, could you at least provide your /proc/cmdline and tell which DTB you're using. Also, do an md5sum or sha1sum on the DTB.

Also, provide me reboot logs if you can （￣〜￣　）

[Miouyouyou]

I've updated the Tinkering branches of RockMyy and RockMyy-Build . Just grab the kernel in RockMyy-Build, try to boot and reboot it.

The reworked patch, based on @TonyMac32 and Tinkerboard's patch is here : https://github.com/Miouyouyou/RockMyy/blob/Tinkering/patches/kernel/v4.13/0005-Fugly-MMC-hack-trying-to-resolve-Tinkerboard-s-reboo.patch

This time no boot parameter is required, but you'll have to use the rk3288-tinker.dtb file when booting.

[Tonymac32]

If using Armbian dev or Next branches, the miniarm dts includes asus,rk3288-tinker in it's compatibles.

[Miouyouyou]

Good news ! ＼（・ω・）／

[Tonymac32]

Yep, added the check and good to go on 4.12, I'm guessing that means it doesn't crash the MiQi anymore? :-P. I'll get 4.13 working on Armbian this afternoon, it's raining so I can't do any yard work... :-/

[Miouyouyou]

Nope, doesn't crash on MiQi when doing normal reboot ! That's the first thing I tested ! I haven't tried SysRQ reboot though.

I exchange you the rain against heat + hot winds !

[Tonymac32]

Well, that's the trouble, it is raining and 27 C, 100% relative humidity... :-(

[Miouyouyou]

Super Mario 64 - Water Theme / Dire Dire Docks

[resipat]

Sorry guys I'm not at home these days. Thanks for your work. Tomorrow I will try your new patch and provide logs if necessary.

[Miouyouyou]

Alright !

[sghazagh]

Miouyouyou, I hadn't compile the kernel. I just downloaded your already compiled kernel and modules and that didn't work. Sorry I am setting up something different these days and changing all setting back to work with yours is a little bit time consuming. Anyway, I have used rk3288-tinker.dtb file.

The reboot stuck at the time. so I saw you have changed some settings as well. So I'll download your latest build and try again. What log I can provide? the system shuts down immediately and have no message print out... unless I give you the syslog in next boot!