Jump to content

jmaus

Members
  • Posts

    8
  • Joined

  • Last visited

  1. Absolute awesome. Thank you @Igor for the fast response. Now all the kernel and kernel headers are there and I can compile additional kernel modules. Highly appreciated!
  2. Yes, indeed. I just checked that myself as well. Newer experimental Armbian (v24, edge, current) contains the corresponding header and image deb files for the RaspberryPi5. However, not the latest stable version. Furthermore, the stable version for the RaspberryPi4 seems to be affected as well. Also there I can't install the corresponding linux-headers package patching the currently running kernel version. See: # apt install linux-headers-$(uname -r) Reading package lists... Done Building dependency tree... Done Reading state information... Done E: Unable to locate package linux-headers-6.1.68-current-bcm2711 E: Couldn't find any package by glob 'linux-headers-6.1.68-current-bcm2711' And the same applies for the linux-image package: # apt reinstall linux-image-current-bcm2711 Reading package lists... Done Building dependency tree... Done Reading state information... Done Reinstallation of linux-image-current-bcm2711 is not possible, it cannot be downloaded. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Hopefully some Armbian dev can fix that ASAP so that the corresponding linux-headers and linux-image packages for the RaspberryPi5 and RaspberryPi4 are available in the apt repositories.
  3. I was about to ask/write the same here. I am also in need of the corresponding kernel headers for the 6.1.68.current-bcm2712 kernel distributed with Armbian for RaspberryPi5. In addition, I just recognized that kernel reinstallation also does not work because the kernel image package also seems to be missing in the apt repositories as it seems. See here: # apt reinstall linux-image-current-bcm2712 Reading package lists... Done Building dependency tree... Done Reading state information... Done Reinstallation of linux-image-current-bcm2712 is not possible, it cannot be downloaded. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Thus, would be great if some armbian dev (perhaps the maintainer – @viraniac – of the RaspberryPi5 port, see https://www.armbian.com/rpi5b/) can have a look and provide the necessary packages...
  4. I actually analysed the issue once more and found out that the issue actually seems to be related to the way I am bringing up network interfaces in the buildroot-based system I am using. Here I have an init.d based startup script (S40network) which first brings up the network interface via `ip link set eth0 up`, then waits 5 seconds and then performs a check if /sys/class/net/eth0/carrier changed to the value 1 or if it is still 0 and then stops initialisation for a certain network device and continues with the other ones (see here for the network startup script I am using). This was actually working perfectly fine for all RaspberryPis I am supporting and was also not a problem with the rockchip-default version of the patches (kernel 4.4.x). However, something must have changed in kernel 4.14.x or rockchip-next because these 5 seconds seem to be not enough anymore if a Tinkerboard is powerup up for the first time. And for every reboot from then it seems to be enough again. Nevertheless I was able to workaround the issue by simply setting the delay to 10 seconds. In fact, for the final version I changed my network startup script to use while loop to check for the carrier in regular intervals (2 seconds) and up to a maximum time of 12 seconds. Still the question remains why the ethernet device takes more than 5 seconds until the network link settled while after a reboot this seem to take under 5 seconds again?!? And why didn't the issue manifest itself with rockchip-default (kernel 4.4.x)?!?
  5. Hello, I am using the armbian kernel+uboot patchset of the rockchip-next (4.14.x) part to support Tinkerboard+TinkerboardS in an own home automation environment. U-Boot 2018.05 and kernel 4.14.53 are working fine so far with the current patchset published on GitHub (thanks for this great work!). However, the only issue I am still having is, that the ethernet port always comes up with "no-link" on the intial powerup of the Tinkerboard. As soon as I software reboot it after the initial powerup the ethernet port perfectly comes up with a link and I am able to setup all IP data, etc. But as soon as I completely power down the system and replug the power-cable it again comes up with "no link" and it requires another software reboot to recover with the ethernet reporting a link and being able to setup it accordingly. Does the same happen with Armbian and rockchip-next and might there be a patch or explanation for the issue or any hint in how I can workaround the issue until the root is identified and fixed? Any help is highly appreciated...
  6. Thanks for linking me to this information and thanks for your example dts. With the reference patch and your short example I was able to tune my dts patch to actually work. The result can be viewed here: https://github.com/jens-maus/RaspberryMatic/blob/e9d3293109933c78acb834673e4f6b5735044e90/buildroot-external/board/tinkerboard/kernel-patches/0002-rk3288-tinker.patch The actual bit that made the GPIO setup (in/out) finally work was the additional "pinctrl-names" and "pinctrl-0" setting within the "&pinctrl {...}" part of the dts. Previously I just had them in the "gpio-leds {...}" part, but this doesn't seem to have been enough to actually trigger a correct setup. So thanks again for your pointer and help. Apart from that I am of course still curious if and how the support dt overlays with a Tinkerboard is actually? It would be great if I would not have to patch the "rk3288-tinker.dts" file directly in the linux kernel tree but use a dtoverlay file similar to how this is done with a RaspberryPi. Any more detailed/updated information on that?
  7. I would of course prefer to use a dt overlay. However, I have learned so far that this is not really supported by the Tinkerboard. But I might of course be wrong. As said, I am using Boot 2018.05 with the armbian patches, thus U-Boot should be as prepared for dtbo like armbian is. However, there AFAIK also no dtoverlays are using, isn't it? No matter how, what I need to know is how I can tuned the device tree so that the default GPIO pin settings are changed (to OUT direction) for the pins specified in my first posting. Regarding my build environment. It is indeed already prepared to create a dtoverlay if it might be necessary. But I would of course also be fine with directly patching rk3288-tinker.dts in the linux kernel tree like I currently do.
  8. Hello, I am the author of a home automation platform (RaspberryMatic) which is targeted for embedded platforms like RaspberryPi or Tinkerboard. I am regularly following Armbian kernel and u-boot updates for the Tinkerboard and integrate them into my buildroot-based environment so that recent kernel and u-boot versions can be used. I have already updated my environment to kernel 4.14.x and U-boot 2018.05 using the great armbian patchset from GitHub (Thanks for the hard work to get all the Tinkerboard S related issues sorted out recently). What I am currently trying to achieve is to get the Tinkerboard to use a different set of standard gpio settings for certain GPIOs because my application requires this for some additional HAT hardware. On the RaspberryPi I was able to perform this by using a device tree overlay and using the following device tree definitions: [...] brcm,pins = <18 12 16 20 21>; // 18=reset, 12=button, 16=red, 20=green, 21=blue brcm,pull = <0 2 0 0 0>; // 18=no-pullup, 12=pullup, 16,20,21=no-pullup brcm,function = <1 0 1 1 1>; // 18=output, 12=input, 16,20,21=output [...] For the tinkerboard I tried to applied similar setting (but using rockchip-like device tree definition) as a patch against linux/arch/arm/boot/dts/rk3288-tinker.dts in the kernel tree. The corresponding patchset which I developed can be found here: https://github.com/jens-maus/RaspberryMatic/blob/master/buildroot-external/board/tinkerboard/kernel-patches/0002-rk3288-tinker.patch It is essentially trying to achieve the same like the above RaspberryPi-based device tree overlay by using: [...] rockchip,pins = <7 RK_PA7 RK_FUNC_GPIO &pcfg_output_high>, <6 RK_PA3 RK_FUNC_GPIO &pcfg_output_high>, <6 RK_PA4 RK_FUNC_GPIO &pcfg_output_high>; [...] However, this does not seem to work somehow because after booting the GPIOs in question are still partly assigned as input direction gpios rather than output direction gpio like I need them. Does anyone have any idea how to solve this issue or point me at the bug in my device tree patch which might explain why I cannot change the default GPIO setup for the Tinkerboard? BTW: Using WiringPi during bootup of course works (and I am using this as a workaround). But I would like to perform this without using WiringPi directly in the device tree.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines