* mvebu-dev: refresh all patches with quilt
Cleaned up based on kernel 5.9.12.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
* mvebu-current: refresh patches with quilt
Based on kernel version 5.9.12
Signed-off-by: Rosen Penev <rosenp@gmail.com>
* mvebu-legacy: refresh patches with quilt
Based on kernel 4.19.161
Signed-off-by: Rosen Penev <rosenp@gmail.com>
* mvebu-legacy: remove custom helios4 dts file
This is already added upstream. No need to have it here.
Continued refreshing the other patches.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
* patch: kernel: rockchip-dev: Handle more resolutions with HDMI (β)
The added patch add more PLL configurations, in order to satisfy
more HDMI frequencies requirements.
This should allow users to benefit from more resolutions.
However, this is fairly untested. I only tested it on my 1080p
screen and, yeah, it works but so does the kernel without this
patch.
Signed-off-by: Miouyouyou (Myy) <myy@miouyouyou.fr>
* patch: kernel: rockchip-dev: Handle more resolutions with HDMI (β)
Now with proper patches names.
Anyway :
The added patch add more PLL configurations, in order to satisfy
more HDMI frequencies requirements.
This should allow users to benefit from more resolutions.
However, this is fairly untested. I only tested it on my 1080p
screen and, yeah, it works but it also does without this
patch.
So could anyone test this with the following configurations ?
* [ ] A HDMI 4K screen
* [ ] A HDMI 1366x768 screen resolution
* [ ] A VGA screen with a VGA to HDMI adapter
* [ ] A DVI screen with a DVI to HDMI adapter
Signed-off-by: Miouyouyou (Myy) <myy@miouyouyou.fr>
* Using the patches provided by @Kwiboo for HDMI
This provides me way more resolutions, including interlaced modes.
I don't see 4K modes, though the screen attached can't do it,
so I still don't know if that can help provided 4K modes on mainline
kernels.
Signed-off-by: Miouyouyou (Myy) <myy@miouyouyou.fr>
* Support for 4K screens
Using fixes provided by @czak
Tested and approved by @czak too !
Signed-off-by: Miouyouyou (Myy) <myy@miouyouyou.fr>
* Renamed some patches for better organization
Still, they should all be numbered correctly...
Signed-off-by: Miouyouyou (Myy) <myy@miouyouyou.fr>
* Preliminary support for "support" checs
The point is to only allow the selection of "supported" desktops
environments and appgroups in the menus, and provide proper errors
and warnings when trying to use unsupported features while not
being an "EXPERT".
This should provide a solution to the following feature request
https://github.com/Miouyouyou/armbian-desktop/issues/13
Signed-off-by: Miouyouyou (Myy) <myy@miouyouyou.fr>
* Moved the desktop selection menus inside configuration.sh
The whole problem being that, in order to provide a custom menu, for
the selected board and architecture, I need to know the actual
architecture of the selected board, which is not easy since the
board definition files depends from other generic information files...
The whole architecture sampling is done during configuration.sh, along
with some default variables configuration just in case the board files
didn't contain all the information.
Trying to move the part that sample the ARCH information from the board
definitions files inside main.sh, while leaving the default values
initialization code in configuration.sh, left me with compiling an arm32
image for an arm64 board, because the parsed variables were replaced
by the default ones.
So, the whole desktop selections menus have been moved inside
configuration.sh, just after sampling the selected board information
just like before, in order to provide only options that catter to the
current build, and also provide actual error messages when invalid
elements were selected.
There's still errors to catch here and there, notably for appgroups,
but the generated image works, which is the most important part.
Signed-off-by: Miouyouyou (Myy) <myy@miouyouyou.fr>
* Delete 1017-ARM-DTSI-rk3288-add-GPU-500-Mhz-OPP-again.patch
* Update only_for
Co-authored-by: Igor Pečovnik <igorpecovnik@users.noreply.github.com>
* Add WIP support for Orangepi Zero 2
* squeeze H616 patches into sunxi-dev
* Update linux-sunxi64-dev.config
* H616: Limit CPUMAX
* Enable DEV only
* H616: remove patches from sunxi-current
* H616: apply new patchset
Co-authored-by: EvilOlaf <werner@armbian.de>
Co-authored-by: Werner <EvilOlaf@users.noreply.github.com>
Some of these get applied at wrong offsets or have fuzz. Fix.
Remove patch 93. It's already upstream. It also has other fixes applied
to it.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
* sunxi: kernel: current/dev: enable sun6i-csi and disable LL debug on UART0
The former is useful on some boards, e.g. PineCube.
The latter blocks boards that do not utilize UART0 from booting.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
* sunxi: add new family sun8i-v3s
This family is intended for boards with V3/V3s/S3/S3L chips and low
DRAM capacity.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
* sunxi: add PineCube board
This board features Sochip S3 SoC (Allwinner V3 die + co-packaged 128MiB
DRAM), and an OmniVision OV5640 camera is shipped with the board.
Add support for it. It could be used as an IP camera then.
Kernel support is only added to current/dev branch, with dev just using
mainline-merged DT and current using backported DT from 5.10-rc.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
* sunxi: kernel: current/dev: add V3s OHCI/EHCI nodes
These are needed for USB host on V3s boards to work.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
