Fwd: Barebox 2017.02 works great but no Linux Framebuffer... :-/
gianluca
gianlucarenzi at eurekelettronica.it
Fri Jun 23 02:45:31 PDT 2017
On 06/21/2017 05:30 PM, Lucas Stach wrote:
> Am Mittwoch, den 21.06.2017, 17:18 +0200 schrieb gianluca:
>> On 06/21/2017 01:50 PM, Lucas Stach wrote:
>>> root at edelin:~# cat /proc/cmdline
>>> console=ttymxc2,115200 rootwait noswap ip=none noinitrd rootfstype=nilfs2 \
>> > root=/dev/mmcblk1p3 fec.macaddr=0x7a,0x3f,0x03,0xe3,0xa2,0xff \
>> > system_rev=0xe3600000 system_serialnr=0x00000000 \
>> > lcd_type=am1280800n3tz fastboot quiet loglevel=3 console=tty0 \
>> > video=mxcfb0:dev=ldb,if=RGB24,bpp=32 \
>> > fbmem=32M vmalloc=400M imx-drm.legacyfb_depth=32
>>
>> As you can see imx-drm.legacy_depth=32 is passed to the kernel from
>> bootloader.
>
> The module is called "imxdrm" without a dash, so the correct way to
> specify the parameter on the command line is "imxdrm.legacyfb_depth=32".
>
> I'm not sure what you are trying to achieve with the mxcfb and fbmem
> parameters. They are certainly ignored by a mainline kernel.
>
It works now, the culprit was the name of the driver: imxdrm is the
right one.
Now a little bit off-topic question:
- Is it better to use Xorg X11 (with a custom full screen application
using Qt 5) [with all concerns about using a Debian Jessie for armhf,
i.e.: imx-drm-vivante driver, opengl/opencl custom libraries etc.,...]
or using a framebuffer Qt application??? I know the framebuffer does not
have any acceleration, but I suppose the CPU (even the dual-core) is
powerful enough to manage some simple transition of the application pages...
What do you think about this?
Regards,
--
Eurek s.r.l. |
Electronic Engineering | http://www.eurek.it
via Celletta 8/B, 40026 Imola, Italy | Phone: +39-(0)542-609120
p.iva 00690621206 - c.f. 04020030377 | Fax: +39-(0)542-609212
More information about the barebox
mailing list