Myy

I've generated a new test build that incorporates an alternative (ugly) reboot hack. You'll still need to add rockchip_tinkerrebootfix=on to the boot command line to use it, though. If you're unsure whether the kernel was booted with this option, do a `cat /proc/cmdline` and check the output. https://github.com/Miouyouyou/RockMyy-Build/tree/Tinkering

No, a screen won't be of any use, unless you try to record the screen with a 60fps+ video camera. That's insane. Instead, could you paste the content of : cat /proc/cmdline In order to know if the bootloader gets configured correctly or not.

Well, it is a Tinkerboard specific issue, so I'm unsure whether Chromebooks had the same exact issue. I have a RK3288 MiQi board which does not present such issues. Anyway, concerning the logs, it looks like the system is not outputting the kernel messages directly on the console, except when journald dies I guess. The only kernel message visible being : [ 616.164534] reboot: Restarting system IIRC Armbian is already configured to output kernel messages to the console displayed with ALT+F12, so I'll try to look around, see if I can find how to configure systemd to output the kernel messages on the serial console. Meanwhile, you can try to change ttyS2 to ttyS1 in boot.cmd, rerun the commands shown in boot.cmd comments and give it a try.

Ok... turns out that the mainlined rk3288.dtsi references a "job" IRQ that is completely unknown and fail the Mali GPU detection... However, I did it the same way before and it worked. So I don't know what they've added that could fail... Anyway, I've started to do some prep work for my new repositories. The first one is here and contains my new patches : https://github.com/Miouyouyou/RockMyy EDIT : Well my 4.12 DTB file works so it's clearly an issue generated by the new definition... Oh... please... /tmp/RockMyy/linux/drivers/gpu/arm/midgard/mali_kbase_core_linux.c if (!strncmp(irq_res->name, "JOB", 4)) { irqtag = JOB_IRQ_TAG; } else if (!strncmp(irq_res->name, "MMU", 4)) { irqtag = MMU_IRQ_TAG; } else if (!strncmp(irq_res->name, "GPU", 4)) { irqtag = GPU_IRQ_TAG; } else { dev_err(&pdev->dev, "Invalid irq res name: '%s'\n", irq_res->name); return -EINVAL; } I replaced the strncmp calls by strncasecmp and... it works... Well, I'll reassemble the patches, and commit this.

Well, the reboot issue will be a problem if you want some kind of unattended web server that you can upgrade through SSH. If you can unplug / plug the cable back, it will be a hassle, but not a blocker though. Since servers don't reboot that often, and personal servers on personal networks, shielded from the outside, almost never reboot, you might not even face it. Anyway, I don't see any problem in using that board for a test web server, though Tinkerboard owners might be aware of network issues that I don't. Note that you can run : systemctl set-default multi-user.target To boot your system directly in text mode, instead of booting in desktop mode. From there, you might be able to delete desktop packages and keep only the server packages you need.

If you have an UART cable, it might easier to connect it to the Tinkerboard, open a serial console on the host and, then, power on the Tinkerboard by plugging the micro-USB cable on. The serial console will get all the messages in real time. The issue with writing on the SD card is that, the reboot issue is related to the MMC driver lowering the voltage of the SD/MMC hardware during the shutdown phase, to a point that it does not get up again (for reasons I don't understand, since I guess that it gets up automatically during a cold boot...). So, that might be the reason why you're getting issues with writing the shutdown messages to the filesystem. That said, I wonder if that reboot issue also occurs with official Android images and what happen if you tell the system to reboot in recovery mode.

I'll take care of the patches this week. I thought that the rc1 would be released today, but it seems to have been released yesterday. I'll incorporate the Mali r18p0 drivers this time, as they have incorporated various patches and are now directly usable with 4.11 kernels, lowering the number of patches required to integrate it with 4.13 kernels ! Yay ! For the reboot fixes, I'll wait until I get more logs from the Tinkering branch, in order to have a clearer understanding of the shutdown process. For the bluetooth fixes, since nobody got it working with the weird Rockchip RFKill thingy, I'll try another way. That said, the main focus with this release will be : The hardware video decoder/encoder chip. RK3288 boards are mostly advertised for their abilities to play videos smoothly, and a lot of tinkerboard owners just want to watch movies on Netflix with it. Trying to start pushing patches to arm-soc . The more patches are integrated into the arm-soc branch, the less we'll have to maintain in the future. And the less, the merrier, when it comes to maintaining patches. Now, this might take a few days to get the first release coming, and the new releases will be done in a new repository that will be splitted in two. One of the kernel build scripts and patches, and one with the actual kernel files. That way, people looking for the builds won't have to download 100M of data and people looking for prebuilt kernels will have a clean repo and releases.

You might have to append it to at the end of the setenv bootargs command of the boot.cmd command, and then run mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr again. Note that whether you use rk3288-miniarm.dtb or rk3288-tinker.dtb, be sure to adapt the fdt_file variable in consequence. Currently it seems to refer to the MiQi dtb. I don't know which one has priority though. the armbianEnv one or the boot.cmd one.

Glad you made it ! The option is not automatically enabled though. You'll have to edit the right bootloader configuration file. It should be /boot/extlinux.conf if I'm not mistaken (I've kinda butchered my ARMbian installation, so I'm not totally sure). So edit the right bootloader configuration file in order to add rockchip_tinkerrebootfix=on to the command line. If you're using an extlinux.conf file, add it to the end of the the 'append' line. Now, the thing is, the first dmesg included in the armhwinfo.log give me some idea of what's going on, but I really need the messages output by the kernel, during the shutdown phase. The same ones displayed by dmesg. If you can configure journald somehow to be more verbose and show kernel messages, this might do the trick. The information I need to get is whether the shutdown fix gets executed or not, and whether the suspend system is disabling the power sent to the MMC hardware before letting the drivers execute the .shutdown phase.

I don't know if it's possible to display, when posting for the first-time in a SBC sub-forum, a form like this : [ ] I have checked my power supply requirements (Link how to check that for that board). [ ] I have checked that my system is up-to-date by running (insert command here). [ ] I have run this program. [ ] Went there, done that ! And then, when posted, paste the result of the form at the top of the post, with an automatic bot response if some checkboxes are missing. The form idea is based on Mastodon Issues template https://github.com/tootsuite/mastodon/issues/4210

It's both actually ! In the boot, lib and usr directories for the release, you'll have the appropriate files you need to copy in your system's /boot, /usr and /lib directories. That said, I haven't generate any release for the Tinkering branch, so you'll have to clone it through Git. Basically, you could do something like this to generate a kernel archive that you can unpack elsewhere : git clone -b Tinkering --depth 1 https://github.com/Miouyouyou/MyyQi cd MyyQi tar cJpvf kernel.tar.xz boot lib usr Then you can copy the kernel.tar.xz in the MyyQi folder on your RK3288 board, unpack it in tmp, mount your /boot partition if it's on a specific partition, and copy the each folder like this : tar xJpvf kernel.tar.xz cp -r usr/* /usr/ cp -r lib/* /lib/ Then copy the zImage in boot/ in your boot partition, along with the rk3288-tinker.dtb or rk3288-miniarm.dtb. On Armbian, DTB files should be placed in /boot/dtb . You might also have to play with your bootloader, in order to boot this specific image. If you know what you're doing, you could just copy the kernel.tar.xz in / and unpack it directly, though. I'll try to make this clearer for the next release. Now, concerning the kernel compilation, you just need to copy the compilation script somewhere, edit the export CROSS_COMPILE=armv7a-hardfloat-linux-gnueabi- So that it matches your cross-compiler prefix. If you don't know what is a cross-compiler prefix, it's basically what's prefixed to cross-compiling binaries names. In my case, the cross-compiling gcc is actually : armv7a-hardfloat-linux-gnueabi-gcc and the cross-compiling ld is actually : armv7a-hardfloat-linux-gnueabi-ld , etc...

While having more than 1KB of storage in registers is extremely valuable, don't you lose cache capacity if you have to encode addresses on 64 bits ? Not counting the fact that data structures that fit well in 32 bits might fit very badly in 64 bits, due to bad padding. Thanks to the x86-64 architectures, most data structures are optimized for 64 bits. That said, in cases where the data structures have been optimized for ARM32, this can also have an impact on the data cache. Anyway, if you have to encode addresses on 64 bits, you'll have more data cache pressure if memory pointers are abused, as it's the case with a lot of tools. Also, GCC had a bad reputation regarding optimized ARM code generation, and I'm wondering if the new GCC and CLANG (which should be very ARM oriented, due to Apple current hardware alignments) can generate code that take profit of all the features of this new architecture.

Well, it's always better than enabling support for RPi oriented Sound cards, like the Raspberry PI Cirrus Logic, that are not even mainlined ! （・ヮ・）

You can try my configuration file if you want, as a basis, since I've already enabled it. Turns out : 1) It's currently a staging driver. Meaning that it *could* work with *some* Raspberry Pi camera. As I understand, there's two completely different versions of the Raspberry Pi Camera and only one is mainlined in the staging folder. 2) It has a lot of weird dependencies, like requiring Mailbox hardware support, Broadcom SoC support, Raspberry PI Firmware loading support, ... The configuration key is named VIDEO_BCM2835 . Its basic requirements are : CONFIG_STAGING, CONFIG_BCM_VIDEOCORE, CONFIG_MEDIA_SUPPORT, CONFIG_VIDEO_V4L2, CONFIG_ARCH_BCM2835 CONFIG_BCM_VIDEOCORE requires CONFIG_RASPBERRYPI_FIRMWARE, which in turn requires CONFIG_BCM2835_MBOX, hence the requirement for Mailbox hardware support.

When looking for 'reboot' hooks on the platform_driver structure, I stumbled into this : https://groups.google.com/forum/?_escaped_fragment_=topic/linux.kernel/QFt8UL8WgxQ#!topic/linux.kernel/QFt8UL8WgxQ I don't know if that could be related to this issue. It talks about setting up special registers on reboot, to tell the Rockchip boot system which mode should be used for the next cycle.

The RFKill system, in this example, is detected and enabled like this in rfkill-bt.c : #ifdef CONFIG_OF static struct of_device_id bt_platdata_of_match[] = { { .compatible = "bluetooth-platdata" }, { } }; MODULE_DEVICE_TABLE(of, bt_platdata_of_match); #endif //CONFIG_OF Basically, if there's a DTS node "compatible" with bluetooth-platdata, the driver will get loaded and the whole probing process will start. The DTS reading and detection is performed by the 'platform_driver' detection mechanism. static struct platform_driver rfkill_rk_driver = { .probe = rfkill_rk_probe, .remove = rfkill_rk_remove, .driver = { .name = "rfkill_bt", .owner = THIS_MODULE, .pm = &rfkill_rk_pm_ops, .of_match_table = of_match_ptr(bt_platdata_of_match), }, }; Basically, it will call rfkill_rk_probe and starts the whole thing. Now, the rfkill system already has some hooks. Notably one that is used in a lot of other drivers, including the HCI driver : static const struct rfkill_ops rfkill_rk_ops = { .set_block = rfkill_rk_set_power, }; In this example, rfkill-bt.c, rfkill_rk_set_power is called everytime an RFkill block request is sent. The RFkill callbacks are defined here https://github.com/torvalds/linux/blob/master/include/linux/rfkill.h. Basically, the function will receive 'true' when blocked and 'false' when unblocked. The HCI driver defines the same kind of function and callback here : https://github.com/torvalds/linux/blob/master/net/bluetooth/hci_core.c#L1988 The HCI driver defines the flag HCI_RFKILLED when blocked. This flag is then read by other functions to determine if they should operate or not. Concerning the Rockchip GPIO Bluetooth RFKILL system, the thing is, I still don't know why there's YET another GPIO driver. There's already a GPIO driver that seems to work fine on Intel platform. The detection is performed through ACPI, which is only used to get the GPIO numbers through ACPI tables, instead of DTS files. https://github.com/torvalds/linux/blob/master/net/rfkill/rfkill-gpio.c#L73 I'll continue with the rfkill-bt driver until it works, and then see if it's not possible to just add DTS detection method to rfkill-gpio. This would be cleaner and simpler, IMHO.

@TonyMac32 I gave it a shot with the latest linux-image-rockchip and DTB, however rebooting just froze the machine (´・ω・`　) The green light is not blinking too. I guess that adding a special kernel option might be required. Something like rockchip.TBrebootfix=1 and add check this option in the reboot fix function, so that it doesn't impact the others boards. @Kwiboo Interesting ! Could you paste your dmesg so that I know what kind of messages I should expect from the driver ?

Well, I guess that the most difficult part will be to know which GPIO you should read to get informations about the temperature... of the CPU I guess ? Or is that the main room temperature ? Anyway, same thing for the humidity sensor GPIO. Once you have these informations, the rest should be easier.

Could it be a protocol issue ? Like the Android smartphone supports WiFi protocols that the tablet doesn't ? Are all devices communicating through the same channel ? With the same frequency (2.4 Ghz) ? Also, is the Tinker powered correctly ? Underpowered boards might have issues when it comes to WiFi stability (or stability overall). That said, to analyse such issues Wireshark and the Aircrack-ng suite might be welcome, in order to capture raw 802.11 packets and have a clear idea about what's going on in the bad case, and what's going on in the good case.

I'll try to give it a shot this week-end, if nobody tested that before.

Well, you might want to try recompiling a kernel using the rk3288-box.dts to generate a DTB file. And then... 'May the source be with you, Shimon'

@Peba were able to boot a Ugoos system using MiQi DTS and kernels. Few things didn't work well however. He blogged about it here : http://www.bitkistl.com/2016/10/ugoos-ut3-devices-with-firmware-from.html So, you might be able to use MiQi's DTS file as a start and solve the few remaining issues through trials, errors and DTS editing. It sounds painful and, yet, it might easier than trying to extract AND adapt DTS files targeting 3.10 kernels from random Android kernel images. Note that ARMbian already apply a few patches to MiQi's DTS files. These patches are available here : https://github.com/armbian/build/tree/master/patch/kernel/rockchip-dev Note that the Rockchip's maintained 4.4 kernel has DTS files named 'rk3288-box' which might also help : https://github.com/rockchip-linux/kernel/blob/release-4.4/arch/arm/boot/dts/rk3288-box.dts

Ah ! I didn't know. I'll let tinkerboarders try this command and see if this unblock the situation

Interesting. I'll see if Tinkerboarders are able to use that one. Still, I didn't know that you had to load the firmware using the UART protocol.

I just checked, the rtl8723bs module has an absurd number of options ! parm: rtw_ips_mode:The default IPS mode (int) parm: rtw_usb_rxagg_mode:int parm: rtw_btcoex_enable:Enable BT co-existence mechanism (int) parm: rtw_ant_num:Antenna number setting (int) parm: rtw_qos_opt_enable:int parm: ifname:The default name to allocate for first interface (charp) parm: rtw_initmac:charp parm: rtw_channel_plan:int parm: rtw_chip_version:int parm: rtw_rfintfs:int parm: rtw_lbkmode:int parm: rtw_network_mode:int parm: rtw_channel:int parm: rtw_wmm_enable:int parm: rtw_vrtl_carrier_sense:int parm: rtw_vcs_type:int parm: rtw_busy_thresh:int parm: rtw_ht_enable:int parm: rtw_bw_mode:int parm: rtw_ampdu_enable:int parm: rtw_rx_stbc:int parm: rtw_ampdu_amsdu:int parm: rtw_lowrate_two_xmit:int parm: rtw_rf_config:int parm: rtw_power_mgnt:int parm: rtw_smart_ps:int parm: rtw_low_power:int parm: rtw_wifi_spec:int parm: rtw_antdiv_cfg:int parm: rtw_antdiv_type:int parm: rtw_enusbss:int parm: rtw_hwpdn_mode:int parm: rtw_hwpwrp_detect:int parm: rtw_hw_wps_pbc:int parm: rtw_max_roaming_times:The max roaming times to try (uint) parm: rtw_mc2u_disable:int parm: rtw_80211d:Enable 802.11d mechanism (int) parm: rtw_notch_filter:0:Disable, 1:Enable, 2:Enable only for P2P (uint) parm: rtw_hiq_filter:0:allow all, 1:allow special, 2:deny all (uint) parm: rtw_tx_pwr_lmt_enable:0:Disable, 1:Enable, 2: Depend on efuse (int) parm: rtw_tx_pwr_by_rate:0:Disable, 1:Enable, 2: Depend on efuse (int) parm: rtw_phy_file_path:The path of phy parameter (charp) parm: rtw_load_phy_file:PHY File Bit Map (int) parm: rtw_decrypt_phy_file:Enable Decrypt PHY File (int) Playing with rtw_btcoex_enable=1 and rtw_ant_num=1 might change something, I don't know. That said, Indeed, I guess that the current best bet might be hadess and Larry Finger repositories. At least, it should be easier to put some printk during the BT initialization code in order to see why the Bluetooth chip is not enabled. Currently, the BTCoexist serial number seems to be a value read from the hardware itself, so that doesn't tell much aside that the driver could read some metadata from the chip itself. I'll postpone that to this week-end.