Myy

Members
  • Content count

    61
  • Joined

  • Last visited

About Myy

  • Rank
    Advanced Member

Contact Methods

  • Website URL
    https://github.com/Miouyouyou/RockMyy

Profile Information

  • Gender
    Not Telling
  • Interests
    https://pledgie.com/campaigns/33598

Recent Profile Visitors

118 profile views
  1. preview

    But wait... you got Bluetooth working on 4.12 kernels ? Are you using an external Bluetooth dongle or did you just start your Bluetooth keyboard and it worked out the box ? Edit : Ah, didn't read correctly, you're using an external dongle. Well given the bad feedback I got from the tinkering forum on the internal Bluetooth, I guess it's the best choice.
  2. preview

    That too, yeah. But at least, you'll know which one it is.
  3. preview

    Try to execute lsmod on the working kernel. Since most drivers are compiled modules, that should tell you what is the driver, I think. Then, from the module name, you can retrace the config option required and its dependencies. It might also be possible to determine the driver used using /sys nodes. But I don't know how exactly. udevadm can also help you. But yeah, try lsmod first.
  4. Alright. The issue seems to be fixed anyway. If it works, just paste your uname -a and tell me which DTB you're using, for the record.
  5. If you remove references to loglevel in the boot parameters, does it improve anything ?
  6. Well, I'll see if everything goes fine in my Github issue page tomorrow. If everything goes fine, I'll consider the case closed for now ! Yay !
  7. Yay ! So we got a 4.13 kernel that can reboot on ASUS Systems then ?
  8. Alright, I've regenerated a kernel based on @TonyMac32 patch. The base patch doesn't work on MiQi, generating kernel panic during the reboot phase (´・ω・` ). The new patch tries to resolve the issue : https://github.com/Miouyouyou/RockMyy/blob/Tinkering/patches/kernel/v4.13/0005-Fugly-MMC-hack-trying-to-resolve-Tinkerboard-s-reboo.patch https://github.com/Miouyouyou/RockMyy/tree/Tinkering https://github.com/Miouyouyou/RockMyy-Build/tree/Tinkering
  9. Could you provide your cat /proc/cmdline output ? There might a log=X in your current boot command line that defines another loglevel.
  10. Give me that package ! I'll test it ! ( ・`ω・´)
  11. By that time, ASUS will already be using 4.9 kernels ! That said, if echo b > /proc/sysrq-trigger works, one workaround will be to put this as the last action before rebooting.
  12. The emergency reboot one or the rockchip_tinkerbootfix one ? Anyway, glad to see some progress !
  13. Yeah, that seems to do the trick, thanks for the information. So, in order to display all the kernel messages on the serial console : 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 ! To see even the debug messages, you might need to set it up to 8 4 1 7. The meaning of the values are defined in syslog(2)
  14. I missed the target then, I guess. My cmdline is earlyprintk console=ttyS2,115200n8 rw root=/dev/mmcblk1p5 rootfstype=ext4 init=/sbin/init Which is the same I used on my Gentoo system, however I got the kernel messages on Gentoo. So, yeah, that might be 10-console-messages.conf # the following stops low-level messages on console kernel.printk = 4 4 1 7 I guess that setting this to 7 4 1 7 will allow kernel messages on... the console ? Like every console ? I'll give it a try.
  15. Indeed. No virtual platform representing this device really makes things difficult. The schematics won't lead us far in knowing what's going on exactly. And systemd seems to love shunting kernel messages logging on the serial console, making things harder to analyze. And contrary to what the StackOverflow guys said, not putting any loglevel on the command line makes no difference when it comes to not displaying kernel messages, beside the emergency ones, on the serial console. Maybe the journald developers thought that people would like to use serial consoles every day, because, you know, DVI and HDMI are so overrated. Well, the last issue can be alleviated by just spouting log messages with printk using the "emergency" log level. It's ugly but everything is ugly on test kernels anyway. I really need to investigate this issue however. If I have some time this week, I'll see if I can force the Rockchip system to reboot in various modes, and test if one of this mode just resolve the issue automagically. Anyway, I'm not in a hurry. Take your time.