lanefu
-
Posts
1148 -
Joined
-
Last visited
Posts posted by lanefu
-
-
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?
-
2 hours ago, piter75 said:
I am not sure of that.
My understanding is that we are still building release images from master branch and the removal of this line from targets.conf:
-rockpi-4b legacy focal cli stable yes
means that focal legacy image for rockpi-4b will not be built.
Lack of focal legacy image among 20.02.3 release images (built after the referred commit was merged) seems to corroborate that theory ;-)
Hmm. when I doubt just blame @Igor
-
10 minutes ago, piter75 said:
IMHO it's more than that ;-)
There will be older releases in the archive but no new ones.
That would only impact nightlies not the most recent release
-
6 hours ago, Drakes said:
I've made a long article about everything I tried
OMG that's an understatement. Impressive article.
-
3 hours ago, pumuckl said:
ook's like the Download of Rockpi 4 A / B / C Armbian Focal is offline.
I think we just have a bad mapping in our download tool. Should be able to find manually here
-
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.
-
Create the file
/etc/X11/xorg.conf.d/01-driver.confwith the following contents.
SpoilerSection "Device"
Identifier "Rockchip Graphics"
## Use modesetting and glamor
Driver "modesetting"
Option "AccelMethod" "glamor" ### "glamor" to enable 3D acceleration, "none" to disable.
Option "DRI" "2"
Option "Dri2Vsync" "true"
Option "TripleBuffer" "True"
## End glamor configuration
EndSection
you may need to set
Option AccelMethodtononedepending on your use. -
PS send me one
-
On 3/8/2021 at 1:41 AM, Heisath said:
Please add developers and more topics below, I will then also add them here.
@Myy @TonyMac32 @balbes150 @piter75 @sfx2000 @ebin-dev @chwe @ning @lanefu @gprovost @aprayoga @5kft @JMCC @martinayotte @going @jeanrhum @dolphs @jock @belfastraven @TRS-80 @Bozza @Rich Neese @sgjava @Mangix @Pali
Hi! reminding everyone of meetingOn 3/8/2021 at 1:41 AM, Heisath said:Release Planning: April 3rd. Meeting in IRC channel #armbian on freenode. Meeting starts at 2pm GMT.
(let me know if this is a bad date, because it is around easter holiday in Germany for example)
-
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
zcat /proc/config.gzbetween the two kernels please -
3 hours ago, Salvador Liébana said:
oh, it says fb. maybe I should try the other one.. how i switch to that one?
look in
/etc/X11/x.org.conf.dor something similar to that name -
On 3/22/2021 at 7:25 PM, Salvador Liébana said:
Hi guys! I need to run some game on full screen, and they are old school windows one. the thing is that adding the modeline worked perfectly fine on rpi4, not on armbian sadly. it seems to change the resolution and then it go "out of signal". I used the same parametes than on rpi4. also generated new ones just in case. the thing is I cant make it to work and maybe iut's something deep into armbian.
exaple:
xrandr --newmode "640x480_60.00" 23.75 640 664 720 800 480 483 487 500 -hsync +vsync
xrandr --addmode HDMI-1 640x480_60.00
make sure the Xorg config is using themodesettingdriver and notfbExample 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
root@orangepi4:/sys/class/drm/card1-HDMI-A-1# pwd
/sys/class/drm/card1-HDMI-A-1anyway 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 -uhelps 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
-
2 hours ago, The 15 Cents said:
Also, when plugging in a headphone the audio playback wont auto-mute the speakers, ill have to open alsamixer and mute the speakers and bring up the headphone volume; every time i restart the computer.
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
-
41 minutes ago, hexdump said:
loading a mainline u-boot.bin (which has nice features like extlinux.conf
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
-
3 minutes ago, TRS-80 said:
("here, hold my beer!"), I decided to just give it a go. And IT VEERRRRRKS!
That's how it done my friend. nice work!
Make forum messages friendlier -- 2021 Edition!
in Armbian Project Administration
Posted
Per meeting, we're still trying to improve our responses to "unsupported' inquries.
current thoughts
* revise "invalid label"
* focus on moving messages