On 03.04.14 14:32, Guillaume Gardet wrote:
CC'ing -arm ML
Le 03/04/2014 13:48, Alexander Graf a écrit :
On 03.04.14 13:47, Guillaume Gardet wrote:
Le 03/04/2014 13:39, Alexander Graf a écrit :
On 02.04.14 20:48, Guillaume Gardet wrote:
Hi,
please find in attachment an ARMv7 -default config update to fix Ethernet and
HDMI output on iMX6 SABRE Lite board. It also add initial support to USB on
this board.
This patch is against master branch.
Signed-off-by: Guillaume GARDET <[email protected]>
Moving modules from =m to =y is the wrong answer usually. Why don't the modules
work as modules?
I do not know.
Modules are loaded with no error but they do not work. The fact is switching
FEC and SDMA from =m to =y fix the problems. It is true for 13.1 and master
branches.
Yes, I've spent some time myself to fix FEC as a module on i.MX53 a while ago.
We really don't want to even start going into the game of enabling random
devices as =y on the default config, otherwise we'll end up with a 30MB kernel
on all boards.
I agree, but the fact is we have no board which works really fine ATM. See:
http://en.opensuse.org/openSUSE:Supported_ARM_boards#13.1
There are only RPi and Chromebook which have a correct support (and they use
_downstream_ kernels).
But chromebook boot only once and need a hack to boot then (I am on it, Marcus
gave me some hints to fix that using kiwi hooks) and had a lot of X stability
problems (random freezes, X crash when switching VT).
Raspberry Pi is not booting at all as is (kiwi partitioning bug) and need a
hack to get a bootable image:
http://en.opensuse.org/HCL:Raspberry_Pi#Known_Issues
Maybe Beaglebone or Beaglebone black have a good support? (I do not have such
devices and there is no feedback on our wiki)
Now, SABRE Lite is the only board where I got graphics working with upstream
kernel. The last blocking problem on this board is USB which is not working,
even with imx_v6_v7_defconfig.
I guess we can ask Sascha here too :).
The main things to do for boards support are :
1) Get boards booting Linux (should be a minimum).
2) Have a maximum number of supported devices (USB, sound, video, etc.) on each
board (even if it does mean to have '=y' instead of '=m').
3) Clean-up / fix our kernel / kernel configs to use modules (=m) instead of
built-in (=y) when it is possible.
I agree with 1), but it'll be a real nightmare to clean things up once
we start going down the path of 2). Let's see if Sascha has ideas to get
us out of the mess where we need =y for things that really shouldn't
have to be compiled in.
I think we should use again our Trello board or setup a wiki page or something
to write down what must be done for each board and who is taking care of each
task.
What do you think about that?
I think that makes sense. I would also consider "Contrib" a good place
to play with hacks like setting options to =y to at least get
_something_ working. So if you like we can create a contrib directory
for i.MX6 and put a kernel in there that has everything it needs
compiled in.
Alex
--
To unsubscribe, e-mail: [email protected]
To contact the owner, e-mail: [email protected]
