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.

[sghazagh]

I have downloaded your latest build on "Rocky-Build". Reboot didn't work again. syslog has nothing to provide!!!

[Miouyouyou]

Well, the logs I'm expecting are the ones that can be seen through a serial console, configured correctly. A lot of debian releases seem to configure the serial console in a weird way, so you'll have to :

• open up /etc/sysctl/10-console-messages.conf
• replace kernel.printk values with 7 4 1 7
• Save the file, reboot and enjoy a serial console acting like a serial console !

If you don't have such file, just grep for kernel.printk in /etc/sysctl to be sure that nothing change the log level on serial consoles.

Anyway, I'll wait for the logs of @resipat then ! (｀・ω・´)

[resipat]

Hey @Miouyouyou - nothing to see in reboot logs: Kernel_4.13.txt

Still no working reboot.

[Miouyouyou]

Did you rebuild it or just used the RockMyy-Build zImage ? The zImage should return the following uname -a :

4.13.0-rc1-RockMyy-XIII #2 SMP PREEMPT Sat Jul 22 20:09:07 UTC 2017 armv7l

Meanwhile, I'll try to update the patch and put some logs in it, just to be sure that the hack is activating correctly.

[Miouyouyou]

Note that there's a new Armbian release incorporating the reboot fix too. Give it a try : https://dl.armbian.com/tinkerboard/Ubuntu_xenial_next_desktop_nightly.7z

[Miouyouyou]

I pushed a new RockMyy-Build image, in the Tinkering branch, including the verbose reboot patch. This should help trying to figure out what's going on if the reboot patch doesn't work for you.

[Miouyouyou]

It seems that the 4.12 Armbian image works so it looks like this will just be a matter of DTS changes.

[resipat]

@Miouyouyou: I've tried both. Rebuild and ready zImage.

[Miouyouyou]

Try the latest zImage from the Tinkering branch. If that doesn't work, try at least this one : http://apt.armbian.com/pool/main/l/linux-4.12.0-rockchip/linux-image-dev-rockchip_5.32_armhf.deb

If both don't work, it's a DTB issue. I've seen a few places where rk3288-miniarm and rk3288-tinker differ, so there might be that.

So, only if both kernels don't work with reboot, download http://apt.armbian.com/pool/main/l/linux-4.12.0-rockchip/linux-dtb-dev-rockchip_5.32_armhf.deb and boot the kernel using the dtb/rk3288-miniarm.dtb file, then reboot.

If nothing works, paste the logs here, so that I can at least determine if everything which branch is called in the reboot hack code.

[Tonymac32]

I switched my 4.12 Armbian image to grab the latest nightly incorporating the patch, it works now as well.

My DTS is here: http://electricgraveyard.com/armbian/dts/

[elar-systems]

As far as I remember, Armbian uses different set of kernel and boot method is different. so can we then use it's kernel zImage and DTS file to use on mainline kernels? If yes, can you link your zImage here as well?

[Tonymac32]

Armbian uses the kernel source directly from Kernel.org on any Mainline build. The kernel configs are all available on the Armbian build GitHub, and the build system itself is so easy the only thing it doesn't do is install itself for you.

Boot method is Rockchip standard, other than not using the multi partition Android-style setup, all data is put into the correct location without the partitions, which is unimportant as the MaskRom does not care either way.

[elar-systems]

So in short, can we use Armbian zImage, DTB and Modules and place it in legacy FAT partition like what we get from official image to boot the legacy images??

[Miouyouyou]

Yes. It's just a kernel and a DTB.

[elar-systems]

So I assume all kernel modules are built-in then,correct?

[Miouyouyou]

You'll have to copy the modules if you want to use them. However, the issue here being a reboot issue, all you'll have to do is boot the system and reboot it.

[Miouyouyou]

The main branches of RockMyy and RockMyy-Build have been updated. They include the reboot patch so, you know the drill.

Grab the zImage, grab the new DTB, boot, reboot. If that doesn't reboot correctly, provide useful logs.

[Tonymac32]

Go to sleep! :rofl:

[elar-systems]

I'll check this today and will let you know the result...

[Miouyouyou]

What is this sleep word you're talking about ? (・ω・)

[elar-systems]

got you now! Yes , meaningless for me too :)

[Tonymac32]

Woohoo 4.13 Armbian is (well, will be once I commit my changes... :smiley: ) a thing! Also, reboot works there for me as well. I get to mark that one off the list at last...

[Miouyouyou]

Well, turns out that I was trying to compile mupen64 on RK3288 boards. The compilation went fine but I remembered that I butchered X11 on this installation. And I don't remember the X11 package for RK3288 boards.　（￣〜￣；

But yeah, I'll go have a nice sleep while you torture your Tinkerboards （・ヮ・）

[elar-systems]

@Tonymac32: What about here? we (at least me) not using Armbian kernel. That's why I am here. We need to get it work here mate ;)

[Tonymac32]

Well, the patch should be exactly the same, as I think the dts turned out to be the issue. I think @Miouyouyou has fixed it, but needs the logs/feedback from eager users.

[sghazagh]

got the latest 'zImage' and 'rk3288-tinker.dtb' from your Rock-Build repo. Boots the device ok but "reboot" causes Kernel Panic. Got a snapshot this time, [Sorry, no access to Serial]... See Here tried:

• reboot
• shutdown -r now
• used graphic "reboot" button from OS All same. Somesort it shutdowns the system all LEDs go away, and kernel panics!

UPDATE

"echo b > /proc/sysrq-trigger" cause the system to reboot properly. The "reboot" itself cause the kernel panic!

One step forward :)

[resipat]

I can confirm the kernel panic. I've tried the latest zImage and rk3288-tinker.dtb like @sghazagh. See attached the serial log: Kernel_Panic_4.13.txt

[Miouyouyou]

Ok, I removed references to regulator_get_voltage during the reboot phase.

Just grab the latest master branch RockMyy-Build zImage and give it a try ! Nothing else changed beside the System.map anyway.

[resipat]

and again.. no reboot Reboot_again_4.13.txt

[Miouyouyou]

Try to extract the rk3288-miniarm.dtb of this package : http://apt.armbian.com/pool/main/l/linux-4.12.0-rockchip/linux-dtb-dev-rockchip_5.32_armhf.deb and see if using it with the same zImage allows the system to reboot.

Also try echo b > /proc/sysrq-trigger.

[Miouyouyou]

I'm still surprised that regulator_get_voltage would generate a NULL dereference kernel panic. But whatever.

Removed the logs in the patch, just in case sending printk with an error level in the logs fucked up the reboot on the ASUS SugarBoard. Redefined the variables outside the if branches when possible and added a printk during the emergency reboot, just in case the Out-Of-Order execution model of the ARM processors might have generated issues. (And also to see if the issue comes from the printk call).

Still, just to give you an idea, this is the Armbian patch, this is my last rework of the reboot patch. You can compare them with meld if you want.

Here's a comparison anyway. This patch is known to work.

I compared the DTS too, there's no differences beside indentation and nodes relative position.

So, yeah, if that does not work, just create a service that does echo b > /proc/sysrq-trigger after the filesystems get unmounted and call it ASUS-Expertise.service.

[elar-systems]

I just see your difference and I see that there are couple of things are not same. For instance the struct mmc has not default value in your verision (you set it later inside 'if' !!!) but Armbian one has (line 77 red: mmc = mSdhost->slot->mmc; and line 98 red: static int dw_mci_init_slot(struct dw_mci *host, unsigned int id) has 3rd parameter green one doesn't)

Does this something you should know about? also see some other difference between you and Armbian. Those might be the case! Would you please check again and see if the patches are identical between your version and Armbian one?

[Tonymac32]

"ASUS-Expertise.service" 🤣

Honestly this and the Bluetooth shenanigans nearly had me considering pulling the plug on my support for this board, and since I'm the only contributor to it on Armbian... Add the completely unnecessary Audio Codec and the fact you cannot power it over microUSB without a brownout if anything is plugged into the USB ports...

Beautiful board with exceptional build quality. But it ends there.

Now off to look at my new shiny RK3328 and A905X boards for a while and cool down on the Tinker Toy before I do something rash. I bought it to be a media center/gaming box, wound up buying a Ugoos UT3S instead...

[Miouyouyou]

the line 77 will crash any board that could not set the mSdhost value, with a NULL dereference.

The unsigned int id is actually removed in 4.13 kernel https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/mmc/host/dw_mmc.c?id=e4a65ef7687b6aaf36bedb497d3fd1480163d2d5

[Tonymac32]

Oops, I should probably switch that then, although the flood of RK3288 boards hasn't happened, has it? Probably the 32-bitness, even if it is very powerful.

[elar-systems]

@Tonymac32 , I understand your frustration as there is no documentation for this board after all this times! But regarding USBMicro power, honestly I have not any issue as I am using a 5V, 3A adapter and it never complains for power! I always connect a USB dongle for Bluetooth mouse and keyboard and it also can handle that as well! You might need to check your power source.

[Miouyouyou]

Well, if you can try to set the value inside the if branch and see if it changes anything when you do an emergency reboot, I'd appreciate that.

That said, it only concerns the emergency reboot system, which @sghazagh said was working so...

[elar-systems]

@Miouyouyou , The interesting thing is that, the reboot shuts-down the power completely as all LEDs goes off, however, the echo b> ... one keeps the LED lights open and can restart! Is there anything forcing that to power off the board? Do you wanna check that one?

[Miouyouyou]

Well, first give a try to the latest zImage here https://github.com/Miouyouyou/RockMyy-Build . Just grab the zImage in /boot and the rk3288-tinker.dtb too. Boot them, try a reboot and if that does not work, try an emergency one.

Meanwhile, I'll try to see what are the major differences between the emergency reboot and the standard one.

[Tonymac32]

@elar-systems I'm an electrical engineer, I actually did a write-up specifically concerning powering this board, measuring the voltage drops/etc. If your supply is a 5.25 Volt unit and your usb peripherals are comfortable at 4.5 V you can get away with it, assuming 18 AWG and a shorter cable. The amp rating is irrelevant if the series resistance causes too large a voltage drop.

The "factory" failed reboot causes the light to stay on, so the mmc supply is being disabled, but not re-enabled. Why the light is affected I actually don't know...

[elar-systems]

Sure you know better mate, just was saying... ;) I am not an Electronic guy as I am a Mechanical Engineer. The Single Board computers and ARM world is what we offer at industrial level for Automation. I design the Mechanical part of that based on the client requests. Now that the market is so quiet, I am learning the Linux more and like to understand the ARM based system more and more. I wish I could understand the electronic part of the system but I think it's a little bit late for me (45 now ;)) anyway...

[Miouyouyou]

Well, the difference between simple restart and SysRQ restart seems blurry. That's the kind of code where I'll need some ways to get call graphs of any code that can call the machine_restart function.

Now, for the record, here's how emergency_restart is implemented

#ifndef _ASM_GENERIC_EMERGENCY_RESTART_H
#define _ASM_GENERIC_EMERGENCY_RESTART_H

static inline void machine_emergency_restart(void)
{
    machine_restart(NULL);
}

#endif /* _ASM_GENERIC_EMERGENCY_RESTART_H */

There's a special version of emergency_machine_restart, but only on X86 systems it seems.

That said, it seems that any driver can set up special callbacks when SysRQ mechanisms are triggered, so that mean that drivers could behave completely differently when calling the SysRQ reboot mechanism.

The Rockchip systems seem to register at least 2 reboot handlers in :

• syscon-reboot-mode.c
• clk.c

That said, that does not clearly tell me why the LEDS are shut off during simple reboot, and why they're not with the SysRQ one.

Also, machine_restart can be called with a special command. It might be the case here, I don't know.

[Tonymac32]

I tried it, nothing changed... :-/ echo b > /proc/sysrq-trigger went off without a hitch...

[Miouyouyou]

Thought so. Well, at least RK3288 boards that doesn't have a support-sd property on the SDMMC node won't panic on emergency reboot at least.

Anyway, I'll leave this bug opened for a week, just in case someone either :

• got it working with RockMyy-Build zImage and latest DTB. Grab the DTB seriously;
• got a very bright idea.

And then, I'll close this bug if that's not the case.

The patch has been applied. If that doesn't work for you, I don't know what will. I mean, really !

It's not a patch issue. It's not a DTS/DTB issue. The ARMbian rockchip-dev also apply roughly the same kernel patches as me.

ARMbian users got it working, so try ARMbian. Maybe they applied additional power supply fixes in their distro that make this patch work fine. They've been fed up of power supply issues on their forum so it's highly possible they did things to lower the probability of such problems occurring. If their kernel work, try this one just in case. If it works too, leave a comment ! Re-open the bug if needed !

You got the compilation script here. You got the patches. The script prefers local patches over net patches anyway, so just clone the repo and get to work ! You can add any patch easily by just putting the patch in the right folder, and adding it to the list in the script. If you find any combination of patches that works for you, meaning that the board reboots fine with your combination, leave a comment too ! Re-open the bug too if needed !

If the emergency reboot works, meaning echo b > /proc/sysrq-trigger works, create a service like specified earlier, that will be executed before shutdown and trigger the emergency reboot. I'm not very familiar with creating services but that should not be very hard on systemd.

You can try various reboot=X arguments, as specified in an earlier post, and see if that works. Maybe Soft Reboot might work, even though they're extremely ill advised on SMP.

You could also try to get kexec working on your board, this will avoid doing a power cycle and just load up a new kernel directly, by-passing the whole boot cycle. Good luck though, as this is the most untested way of loading up kernels.

At last, if you really want to get this bug fixed, and all the alternatives failed, either :

• ask ASUS to send me a sample;
• pop 60$ on my Patreon or my Pledgie and I'll buy one;
• hone your electronic skills and debugging skills and get to work !

[Tonymac32]

As a last thought, I have CONFIG_SYSCON_REBOOT_MODE=m as the system is supposed to support it according to the dtsi, no idea if that would have an impact.

ASUS never got armbian any boards to my knowledge, despite promising them.

[resipat]

@Miouyouyou I think you got it. The reboot works. Attached the logfile. Tinkering_4.13_reboot.txt

Great work!

[sghazagh]

Congratulation everyone! the reboot works fine for me too

Well done Miouyouyou. all are working:

• GUI "reboot"
• terminal "reboot"
• shutdown -r now
• and "echo b > /proc/sysrq-trigger"

We are waiting for merging this to master and adding a new fresh branch. Thanks for all your efforts...

[Miouyouyou]

Well, I'll port the patch to the 4.12, so that it's also usable on MyyQi. Then I'll close this bug.

Thank you everyone for your efforts.

Glad this bug is solved.

[Miouyouyou]

Patch backported on MyyQi. If you really want to use a 4.12 for some reasons, give it a try.

In any case, I'll close this bug tomorrow if I don't have any more reports.

[elar-systems]

@Miouyouyou , The latest stable 4.12 release is 4.12.3. I do recommend you make a tag for 4.12.3 and apply the patches. Let us check and if all was good make it as release. This way we have working 4.12.3 and you can have a master as ongoing work for 4.13.x series.

I personally will stick to 4.12.3 as 4.13 is release candidate and is not stable. Please update us if will you do this... Thanks