Working frame buffer for kernel 4.1

[tmcdos]

I needed a minimal kernel for my LED-strips project (inspired by Jeroen Domburg)
Kernel has almost all peripherals working - excluding WiFi, NetFilter, IPsec, power management,fancy filesystems and other non-relevant stuff.
Frame-buffer is working (it took me whole day to make it work due to some missing information in DTS) and there is also Timer 1 as 30MHz clock source for userspace. Hardware I2C is disabled, because it overlaps with LCD pins, but software bit-banging can be used.

The contributions here are:
1) added 16-bit LCD interface in device tree according to Jeroen Domburg`s patch on his web page (link is above)
2) included important parameters as per Documentation/devicetree/bindings/fb/mxsfb.txt in the stock kernel 4.1
3) copied parameter clocks from imx23.dtsi into imx23-olinuxino.dts - otherwise there is no /dev/fb0
4) patched /drivers/clocksource/mxs_timer.c as per aero-linux patch

Get the files from Mirror Creator

[Fabio Estevam]

Any plans to sending the patches upstream?

Regards,

Fabio Estevam

[swahren]

Providing a Windows Executable is pretty unusual for Linux sources. Looks suspicious to me.

[tmcdos]

Providing a Windows Executable is pretty unusual for Linux sources. Looks suspicious to me.

I am not sure what do you mean. There is no executable file in the archive - only textual information (besides the DTB, but you can always compile it from the DTS).
If you are talking about choosing ZIP instead of GZ or XZ or even TAR - I can not see a strong enough reason why to prefer one over another, they are all equally suitable for the purpose.

Regarding sending the patches upstream - I am still quite new to this forum and to the hardware platform itself, and do not know what is the procedure. I do not need a credit, just wanted to share a working solution for a specific problem.

[swahren]

I am not sure what do you mean. There is no executable file in the archive - only textual information (besides the DTB, but you can always compile it from the DTS).
If you are talking about choosing ZIP instead of GZ or XZ or even TAR - I can not see a strong enough reason why to prefer one over another, they are all equally suitable for the purpose.

If i click on your link above then i'll get an imx233_0.zip.exe

[tmcdos]

If i click on your link above then i'll get an imx233_0.zip.exe

If I click, then I see a list of download locations (like UptoBox, HugeFiles, AFile, TusFiles, FileRIO ....)
Then if I click one of these download links - I get a ZIP file, not EXE.
I would be more than happy to attach the files here in the forum - but unfortunately attachments are disabled by forum administrator

[swahren]

Another option would be to clone an existing Linux repository at a Git provider and apply your patches.

Edit: Okay, it was my fault to click on the obvious link. Thanks for providing.

[JohnS]

It's generous to provide the file(s), and I expect will help people, but an EXE is about the worst option, sadly.  Is there no other host where a ZIP (or bz2 or whatever) can be put?

John

[tmcdos]

http://dox.bg/files/dw?a=7dc66a68e9

I really do not want to be rude, but I do wonder how do you people are "fighting" with a complex beast like Linux and with hardware devices, but could not see so obvious hyperlinks for downloading ....

If there is a moderator - it seems that the option for attaching small (e.g. up to 10 MB) files would be extremely handy.

[lambda]

Regarding sending the patches upstream - I am still quite new to this forum and to the hardware platform itself, and do not know what is the procedure.

At least three people (including me) answering in this thread could help you getting started.
However I don't have any LCD hardware for testing your work, so I'd hope one of the other
two jumps in if possible.

I do not need a credit, just wanted to share a working solution for a specific problem.

IMO sending patches upstream isn't for credit, but to have it work out of the box should you ever
need to upgrade to a newer kernel. Also of course you learn a lot during the review process.

HTH,
Harald

[Chris]

I tried to compile a fresh kernel (4.1.4) with your patches and .config, but it won't boot at all. Compilation completed without errors (however, modules are disabled??), but when booting it only says:

Code Select Expand

bus = 0xb83d34c8

and then locks up.
Any idea?

Thanks,
Chris

[Chris]

PS: I added some options in the menuconfig (like essential boot options!) and now it will come up, but fails with a kernel panic:

Code Select Expand

Kernel panic - not syncing: Requested init /usr/lib/systemd/systemd failed (error -2).
CPU: 0 PID: 1 Comm: swapper Not tainted 4.1.4-ARCH #9
Hardware name: Freescale MXS (Device Tree)
[<c000ef4c>] (unwind_backtrace) from [<c000cf0c>] (show_stack+0x10/0x14)
[<c000cf0c>] (show_stack) from [<c03fdb20>] (panic+0x98/0x200)
[<c03fdb20>] (panic) from [<c03fca7c>] (kernel_init+0x80/0xec)
[<c03fca7c>] (kernel_init) from [<c000a3b0>] (ret_from_fork+0x14/0x24)
---[ end Kernel panic - not syncing: Requested init /usr/lib/systemd/systemd failed (error -2).


Ideas??
What filesystem (distro) are you using?

Thanks,
Chris

[swahren]

Hello Chris,

without your actual Kernel config and used bootloader it would be hard to find the problem.

Maybe you missed the systemd requirements?

[Chris]

Code Select Expand

without your actual Kernel config and used bootloader it would be hard to find the problem.


I used the kernel config provided here in the first post from tmcdos.

Bootloader (Bootlets) taken from https://github.com/koliqi/imx23-olinuxino 
(It's not a bootloader problem - even running the kernel under Qemu will bring the Kernel panic above.)

RootFS taken from
https://www.olimex.com/wiki/images/4/49/Imx233_kernel_2.6_ARCH_FS_WIFI_release_4.torrent

[swahren]

Did you try it without tmcdos patches?

Did you try to the fix systemd requirements?