Myy

  • Posts

    364
  • Joined

  • Last visited

 Content Type 

Forums

Member Map

Store

Crowdfunding

Applications

Everything posted by Myy

  1. I'm currently finishing the last features for builders, like : the ability to provide a list of packages to uninstall before generating the image; limiting the desktops selection menus to the ones supported by Armbian and the architecture; parsing the distribution info from configuration files. I also went back to a clean Armbian fork, https://github.com/Miouyouyou/build/tree/desktop , so that pull requests are 'doable'. I still need to re-arrange the changes into specific branches to make pull requests "nicer" and also : add documentation for the new features; remove the whole debug messages mess; refactor a good part of the new code.
  2. I thought about it and I guess this could be implemented by aggregating the information provided in custom/boards_families and custom/boards . That could also be implemented by just created a folder, then creating symlinks to in the right places, though, Git symlinks might pose some issues on some Windows systems.
  3. @JMCC The current system actually supports "appgroups", which should provide enough flexibility in regards to Hardware acceleration packages and multimedia apps. The appgroups can also contain additional packages depending on the selected board and Desktop Environment.
  4. Greetings, I'm currently modifying the Armbian build system, making it easier to add new desktop environments and application groups. This architecture is subject to heavy modifications until it is merged with the current Armbian build system. A repository with the modified build system is available here : https://github.com/Miouyouyou/armbian-desktop Currently, I only tested adding Ubuntu Focal + XFCE and application groups, since I had to make sure that the postinst and create_desktop_package.sh were actually aggregated correctly, now that they're split into multiple files, and, for comparison, we only have such scripts for XFCE. Also : the current list of packages for XFCE include unrelated packages (like neverball), added to test the packages files aggregation; there's a lot of debug messages added here and there, in order to have an overview of the current build state. The actual packages list for other desktop environments and distributions, along with the scripts, still have to be added. (They're currently empty) That said, I'd like to have a few maintainers test (quickly) the new architecture, in order to check if there isn't any obvious feature missing. So, here's how to add a desktop environment with the new architecture : Adding a desktop environment Currently, only official repositories are supported. Let's say that you want to add that new desktop environment "superduperde", that is now available on official on Debian/Ubuntu repositories. First, focus on one specific distribution like focal (Ubuntu) or buster (Debian). In our example, will take focal. We'll create our first configuration 'full', which should provide the DE along with all its specific apps, widgets and the kitchen sink. Create the directory config/desktop/focal/environments/superduperde/config_full Create the file config/desktop/focal/environments/superduperde/config_full/packages Open the packages file, add the list of packages for apt. Then select it in the configuration menu, or pass the following variables to ./compile.sh : BUILD_DESKTOP="yes" RELEASE="focal" DESKTOP_ENVIRONMENT="superduperde" DESKTOP_ENVIRONMENT_CONFIG_NAME="config_full" Then test the resulting image ! Adding an appgroup Appgroups are roughly the same. Let's say that you want to add remotecontrol to the appgroups for Ubuntu focal : Create the directory config/desktop/focal/appgroups/remotecontrol Create the file config/desktop/focal/appgroups/remotecontrol/packages Open the packages file, add the list of packages for apt. Tale a look at https://github.com/Miouyouyou/armbian-desktop#the-architecture-added-to-the-build-system, for a more detailed documentation of the new architecture, and how to add special packages files for specific boards, and desktop configurations, along with specific debian/postinst and armbian/create_desktop_packages.sh files. What needs to be quickly tested : Modifying an existing desktop environment (gnome, kde, ...). Adding a new desktop environment or window manager (mate-desktop, i3, fluxbox, ...) Adding a new appgroup Bonus points for adding a desktop environment with Wayland support (but remember that default installations come with terrible OpenGL support on most boards !)
  5. If you're doing a simple copy (with Thunar, Nautilus, Dolphin or the simple cp command) there's no synchronisation mechanism, so it's either Replace All or Skip All, meaning it will replace every file present at the destination, or skip the copy of any file being present at the destination, regardless of its other attributes. What you're looking for is a synchronisation software, like 'rsync'. Though, you should try your hands with this software using a few dummy folders, since synchronisation softwares can be complex. Rsync allow you to synchronise two folders, with options like "copy the files not present", or "only replace files that are more recent", ... And can also do that through the network.
  6. Well, to add the "Virtual Framebuffer" driver, you'll have to reconfigure and recompile the Linux kernel using the armbian build tools, and ensure that CONFIG_FB_VIRTUAL is set to 'y (* compiled within the kernel)' or 'm' (compiled as a loadable module) when configuring the kernel... If you're not familiar with these tools, and you have no idea what "recompiling a kernel" means, the $3 Dummy HDMI plug might be WAY better for the time being. Even more due to the fact that I'm not sure that it will solve TeamViewer problem entirely. I just think so, since the virtual framebuffer can be used for "off-screen rendering purposes", so TeamViewer should be able to use it to read/write pictures into the framebuffer, and then send it through the network... Edit : Yes, you'll need to follow the guide you mentioned, if you want to reconfigure and recompile a custom kernel for your board.
  7. Note that the serial console clock changes to 1500000n8 when it boots, so be sure that the serial console receiver also reads at that speed, else you might not see any log after booting.
  8. I guess that you could always try to recompile your kernel and enable the "Virtual Framebuffer" driver ( CONFIG_FB_VIRTUAL=y ) and see how it goes. This should create a virtual /dev/fbX node... If you don't plug your monitor on startup, this one should be /dev/fb0 . Else, you'll have to play with udev to either force vfb to /dev/fb0 or the rockchip driver to /dev/fb1.
  9. Is it possible to get the patched .dts file at least ? This way, we could create a patch and integrate it to the armbian build tree.
  10. Here's the (very late) pull request : https://github.com/armbian/build/pull/2149
  11. Here's the patch : https://gist.githubusercontent.com/Miouyouyou/31d7d4ff0a2d5b8941d746ee6248f8b1/raw/a9ea4692642f1c59bfa6d562b9d35e25e5ce7123/drivers-staging-rtl8723bs-Initialize-structures-corr.patch While the kernel drivers doesn't generate any BUG now, the connection still fails in one way or another, since hostapd appears to be unable to setup wlan0 correctly. Or maybe it's just my hostapd.conf that's badly setup... Give it a try and tell me how it goes. From 48646460655b36cb616c7ad05f66f63631bfe1d8 Mon Sep 17 00:00:00 2001 From: "Miouyouyou (Myy)" <myy@miouyouyou.fr> Date: Fri, 14 Aug 2020 09:27:49 +0200 Subject: [PATCH] drivers: staging: rtl8723bs: Initialize structures correctly This avoids a BUG when freeing the ressources in nl80211_send_station . Signed-off-by: Miouyouyou (Myy) <myy@miouyouyou.fr> --- drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c index 2fb80b6eb..aef9cd888 100644 --- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c +++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c @@ -2384,7 +2384,7 @@ void rtw_cfg80211_indicate_sta_assoc(struct adapter *padapter, u8 *pmgmt_frame, DBG_871X(FUNC_ADPT_FMT"\n", FUNC_ADPT_ARG(padapter)); { - struct station_info sinfo; + struct station_info sinfo = {0}; u8 ie_offset; if (GetFrameSubType(pmgmt_frame) == WIFI_ASSOCREQ) ie_offset = _ASOCREQ_IE_OFFSET_; -- 2.28.0
  12. Ok, that clearly seems to be a badly initialized structure issue. Changing struct station_info sinfo; by struct station_info sinfo = {0}; in drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c : rtw_cfg80211_indicate_sta_assoc remove the BUG calls on a client connection. Now, I'll have to test it in a real environment, to check if the Wifi connection works and is stable. I'll post a clean patch tomorrow.
  13. I'm trying to understand the issue, but it seems rather bizarre. Basically, when freeing the station_info structure in nl80211_send_station, kfree is called with a somewhat valid pointer, but then kfree (SLUB version) trips when calling PageCompound on the page of the provided pointer. My best bet is that the structure isn't initialized correctly, leading some fields to be initialized with garbage values. However, it seems strange that everything goes without any bug until that specific point.
  14. Just tried it today, but without network though. It boots correctly. There's no desktop, obviously, since it's a minimal image. But I was able to log-in as root, add a user, reboot a few times and log-in as the user. Could you tell us what's happening actually ? No Tinkerboard led ? Stays red without any activity ? It boots without HDMI ? An error message appears ?
  15. Thanks for testing ! I guess we can include this patch in the next release, then.
  16. It seems to be the same issue as : I'll try to investigate this, see if the patch provided there works nicely. Also, does this problem happens every time you run in AP mode ?
  17. Sooo, I tried to fix the issue, using a 5.8-rc3 kernel... While the frequencies are back, there's some heavy glitches with Panfrost drivers and I don't know if that's due to kernel changes (entirely plausible) or if that's due to the patch. I'll try test a 5.8-rc3 kernel without this patch, just to check who's the culprit. Meanwhile, here's a patch that brings 500Mhz frequencies back for Mali GPU on RK3288 boards : https://gist.github.com/Miouyouyou/0dad9c4a321349166bbc9d49ffec315a From 73258d32daf3a661281bb5c77c5e2e06c7ff714e Mon Sep 17 00:00:00 2001 From: "Miouyouyou (Myy)" <myy@miouyouyou.fr> Date: Fri, 3 Jul 2020 02:02:18 +0200 Subject: [PATCH] arm: dtsi: rk3288: add GPU 500 Mhz OPP again Undoing the very bizarre mainline kernel patch, 75481833c6dbab4c29d15452f6b4337c16f5407b which main purpose is to sync some 3.14 kernels hacks to mainline kernels, for reasons that only matter for a few Chromebooks, and shove it down the throat of every RK3288 user. If you need to avoid the GPU going to 500 Mhz on Chromebooks, remove the OPP entry inside the DTS that actually matters to RK3288 Chromebooks. Meanwhile, the 600 Mhz operating point can prove to be unstable on some RK3288 boards, while 500 Mhz works fine. https://forum.armbian.com/topic/13515-panfrost-on-rk3288-and-gpu-on-600mhz-problems/ Signed-off-by: Miouyouyou (Myy) <myy@miouyouyou.fr> --- arch/arm/boot/dts/rk3288.dtsi | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi index a66412547..ef7457f79 100644 --- a/arch/arm/boot/dts/rk3288.dtsi +++ b/arch/arm/boot/dts/rk3288.dtsi @@ -1312,6 +1312,10 @@ opp-400000000 { opp-hz = /bits/ 64 <400000000>; opp-microvolt = <1100000>; }; + opp-500000000 { + opp-hz = /bits/ 64 <500000000>; + opp-microvolt = <1200000>; + }; opp-600000000 { opp-hz = /bits/ 64 <600000000>; opp-microvolt = <1250000>; -- 2.27.0
  18. Somebody had some issues with a few screens on X11, when testing the latest DRM patches to improve HDMI handling of various screens, and were able to force X11 to use manually input EDID values. https://github.com/armbian/build/pull/1887#issuecomment-642832922 If you could retrieve the EDID values used by the TinkerOS and feed them to X11, you might be able to get this resolution working... Though, that's a weird bug. I might have to reintroduce a way to get the list of EDID values obtained and evaluated by the DRM driver, for each plugged screen, in the dmesg logs.
  19. I was wondering the last day I touched the GPU frequencies. I never touched that. CPU frequencies, yes. GPU frequencies, no. All my patches are available on RockMyy . The removal of the 500 MHZ GPU frequencies were done on the mainline kernel here : https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/rk3288.dtsi?id=75481833c6dbab4c29d15452f6b4337c16f5407b That's a pretty heavy-handed patch, I agree (Some Chromebooks are broken so let's remove the functionality for everyone). I don't know if it's possible to patch frequencies within a sub-DTS file. Something like (untested) : @gpu_opp_table { opp-500000000 { opp-hz = /bits/ 64 <500000000>; opp-microvolt = <1200000>; }; }; I'll give it a try when possible.
  20. Could you provide your dmesg after trying to setup the right resolution ? I guess that others resolutions fail too, or are not available ?
  21. According to chrony, the system clock was wrong when it started up, and it was 97380 seconds late, which is roughly 27H, which fits with the "1 day 3 hours ago" diagnostic. Now, I don't know how the clock is updated and it seems that systemd is displaying the "running" time based on the day time, instead of a monotonic clock. There might be a way to force it to display the "running" time using a monotonic clock, though.
  22. Interesting approach. I'd just like to mention that factorizing is required, if the patches apply to the same file AND the same blocks (functions, DTS, ...). If you create THAT big patch that add 50 entries to a single DTS file, and the mainline DTS file gets updated with the addition of, like, 3 entries out of the 50, then you won't be able to apply your big patch AND you'll need to rework it. Since you won't be able to apply it again, you can either pray that 3-way merging works, or you'll have to do a copy-paste of every missing entry from the patch, back to the DTS file AND regenerate a patch from there. Now, if you got 5 patches affecting "that same function" or "that same DTS block", then yes, merging is required. Anyway, this tool should greatly help in reducing the number of patches. Just don't do a blind factorization, it will back-fire very quickly.
  23. If anyone could test the following pull request, with a Tinkerboard and a screen supporting resolutions like 1366x768, this should settle the HDMI issues with RK3288 boards for now : https://github.com/armbian/build/pull/1887 Note : I prepared a Debian Bullseye image with the patches reworked here : https://miouyouyou.fr/static/Armbian_20.05.0-trunk_Tinkerboard_bullseye_dev_5.5.19_desktop.img Since it uses the reworked patches, and not the patches as provided in the pull request, if that doesn't work, give the pull request patches a try ! The reworked patches are available here : https://github.com/Miouyouyou/build/tree/Rework/patch/kernel/rockchip-dev (4005 to 4012)
  24. Just in case, I have a very small example that uses DRM and OpenGL ES : https://gist.github.com/Miouyouyou/89e9fe56a2c59bce7d4a18a858f389ef You'll have to compile it like this : gcc -o drmgl Linux_DRM_OpenGLES.c `pkg-config --cflags --libs libdrm` -lgbm -lEGL -lGLESv2 This will only throw a glClearColor on the screen, with a blueish tone. You might want to try it, if you want to check for DRM/KMS capabilities on your hardware. Note that if you have multiple /dev/dri/cardX nodes, you'll have to edit the source code accordingly : https://gist.github.com/Miouyouyou/89e9fe56a2c59bce7d4a18a858f389ef#file-linux_drm_opengles-c-L129 If your system crashes with KMS/DRM, could you try to get some logs from a serial console ?