lanefu

Per meeting, we're still trying to improve our responses to "unsupported' inquries. current thoughts * revise "invalid label" * focus on moving messages

Any chance you can share the patched version of the dts. Will make it easier to add it back into armbian build

great find.... not sure if that's sysctl setting or a module parameter... would be interesting to find the origin of the default value.. or whether that's dynamically adjusted otherwise. if you do figure it out.. we do keep various optimizations here https://github.com/armbian/build/blob/master/packages/bsp/common/usr/lib/armbian/armbian-hardware-optimization

@TheLinuxBugyou have any thoughts?

Hmm. when I doubt just blame @Igor

That would only impact nightlies not the most recent release

OMG that's an understatement. Impressive article.

I think we just have a bad mapping in our download tool. Should be able to find manually here https://mirrors.netix.net/armbian/dl/rockpi-4b/archive/

Sunxi is one of the platform where we dont follow mainline directly and can be behind depending on maintainers progress. https://github.com/armbian/build/blob/master/config/sources/families/include/sunxi_common.inc We often add patches to bring it current. @Igorupdated it a few weeks ago but rolled them back after i had a problem.... which i think turned out to be caused by another issue i haven't figured out yet. Probably safe to add payches back.

@Salvador Liébana Create the file code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } /etc/X11/xorg.conf.d/01-driver.conf with the following contents. you may need to set code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } Option AccelMethod to code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } none depending on your use.

PS send me one

Hi! reminding everyone of meeting

yeah I'm excited about 8Gig chips... skeptical on AI functionality until there's a way to build DKMS against mainline..

compare the results of code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } zcat /proc/config.gz between the two kernels please

look in code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } /etc/X11/x.org.conf.d or something similar to that name

make sure the Xorg config is using the code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } modesetting driver and not code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } fb Example here: https://github.com/armbian/build/blob/c1ef2aeba9ab782ec543e37425f2da61b2f4c4fb/packages/bsp/pinebook-pro/xorg.conf#L9 Otherwise it's a constraint of the driver for the SoC.. not really an Armbian limitation. Also it's possible the port may be called HDMI-A-1 code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } root@orangepi4:/sys/class/drm/card1-HDMI-A-1# pwd /sys/class/drm/card1-HDMI-A-1 anyway I suspect you need to use the other driver and will be able to use normal means of adjusting resolution FYI I hid your feature request post because it was redundant and I've responded here.

Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

Half-relevant. Had fun idea for new simple feature: control mode of onboard leds. (Heartbeat, io, etc) Basically enumerate whats in /sys/class/led and pick their setting via the tui. Just use a systemd.unit as a oneshot service that reads config file to set value at startup

no coding needed.. this is just configuration stuff... If you're able to figure out what config files on the desktop need to be fixed and what settings need to be placed in them, that's a huge help... and honestly 80% of the work needed... I can help get the configs into the build after that

Interesting I'll have to learn more about extlinux.conf

try out using `pyenv` for installing different versions

https://armbian.atlassian.net/browse/AR-702 (Don't worry I only tagged it for the 21.08 Release -- so we have plenty of time to think this through) Armbian provides a lot of extra device tree improvements for support. Currently they’re added to the build system via patches, which is very difficult to follow. We need a new approach that makes our device tree files and overlays more visible within the Armbian-build framework.. as well as make it easier for us to upstream our faces to SoC maintainer kernel trees. Obviously lots to figure out here. Tagging a few.. please tag more @martinayotte @TonyMac32@Igor@Rich Neese@Werner

Hi! what's everybody workin on

I havent read the whole thread so im just kind of chiming in anyway. i could be wrong but how the "chainloading" typically works in out world is that the first uboot stage loads... and then it can pick up the second stage / SPL (secondary program loader) on another device if the first stage uboot is able to do it. Other implementations like petitboot are actually using the system uboot and then loading a tiny linux and using kexec to load kernel from other devices similar to how you might boot another linux. By updatting grub.cfg

That's how it done my friend. nice work!