I am using a custom davinci board running Arago project. I am using analog video out (PAL), and though the OLED display powers on with uboot, no image comes till the kernel has finished loading. I want to display a logo as soon as uboot starts and display powers on. I tried adding
#define CONFIG_SPLASH_SCREEN
in the uboot config file, but that doesn't work.
One approach I can think of is to put an image in the NAND memory, and then use the
setenv splashimage <address>
command to display it during uboot. But the problem is, I do not know how to put the image in the NAND memory in a particular address.
Alternative methods are also welcome.
Thanks!
The CONFIG_SPLASH_SCREEN only tells U-Boot to include the code required for supporting splash screens. It says absolutely nothing about how to display the splash screen or where to find it. It only provides you with helpful functionality to achieve that goal.
There is no need to put your image at a specific address in NAND. If your U-Boot can access the filesystem, you could just have the image in a file. You could also embed the image in the U-Boot image if you like. That's entirely up to you. The functionality included by the CONFIG_SPLASH_SCREEN will help you load an image from any number of sources.
The trick is getting it displayed. You'll need to teach U-Boot enough about your graphics hardware to get the image out. On most SoCs, that's just a matter of setting up the framebuffer, loading your image into it, and telling the hardware to start clocking it out.
It doesn't look like someone has written a framebuffer driver for the DM365, so you'll have to do that yourself. Or maybe ask on the mailing list if anyone has done it but not contributed it back yet. If you have to do the work yourself, it's probably easiest to start from the Linux driver and port only the bits you need.
You'll find here the official documentation for u-boot's splash. It has an example on how to load the file into nand, using tftp.
Find here how to set the tftp server in case you don't already have.
Related
I am writing a high performance video application in linux and C++ (but language shouldn't matter for this question)
I currently have my application such that I can display images to the Framebuffer. When my computer boots, the resolution of the display connected seems to be set permanently. I would like to be able to change the resolution output on the computer dynamically. I have tried fbset but it did not work. I am not using X11 because I assumed that there would be a performance decrease.
Is directly writing to the framebuffer the best way to be doing my
rendering for performance?
If I use X11 I see that I can get commands
to change the resolution. Should this be something I investigate?
Is there another way to change resolution?
How to get screenshot of graphical application programmatically? Application draw its window using EGL API via DRM/KMS.
I use Ubuntu Server 16.04.3 and graphical application written using Qt 5.9.2 with EGLFS QPA backend. It started from first virtual terminal (if matters), then it switch display to output in full HD graphical mode.
When I use utilities (e.g. fb2png) which operates on /dev/fb?, then only textmode contents of first virtual terminal (Ctrl+Alt+F1) are saved as screenshot.
It is hardly, that there are EGL API to get contents of any buffer from context of another process (it would be insecure), but maybe there are some mechanism (and library) to get access to final output of GPU?
One way would be to get a screenshot from within your application, reading the contents of the back buffer with glReadPixels(). Or use QQuickWindow::grabWindow(), which internally uses glReadPixels() in the correct way. This seems to be not an option for you, as you need to take a screenshot when the Qt app is frozen.
The other way would be to use the DRM API to map the framebuffer and then memcpy the mapped pixels. This is implemented in Chromium OS with Python and can be translated to C easily, see https://chromium-review.googlesource.com/c/chromiumos/platform/factory/+/367611. The DRM API can also be used by another process than the Qt UI process that does the rendering.
This is a very interesting question, and I have fought this problem from several angles.
The problem is quite complex and dependant on platform, you seem to be running on EGL, which means embedded, and there you have few options unless your platform offers them.
The options you have are:
glTexSubImage2D
glTexSubImage2D can copy several kinds of buffers from OpenGL textures to CPU memory. Unfortunatly it is not supported in GLES 2/3, but your embedded provider might support it via an extension. This is nice because you can either render to FBO or get the pixels from the specific texture you need. It also needs minimal code intervertion.
glReadPixels
glReadPixels is the most common way to download all or part of the GPU pixels which are already rendered. Albeit slow, it works on GLES and Desktop. On Desktop with a decent GPU is bearable up to interactive framerates, but beware on embedded it might be really slow as it stops your render thread to get the data (horrible framedrops ensured). You can save code as it can be made to work with minimal code modifications.
Pixel Buffer Objects (PBO's)
Once you start doing real research PBO's appear here and there because they can be made to work asynchronously. They are also generally not supported in embedded but can work really well on desktop even on mediocre GPU's. Also a bit tricky to setup and require specific render modifications.
Framebuffer
On embedded, sometimes you already render to the framebuffer, so go there and fetch the pixels. Also works on desktop. You can enven mmap() the buffer to a file and get partial contents easily. But beware in many embedded systems EGL does not work on the framebuffer but on a different 'overlay' so you might be snapshotting the background of it. Also to note some multimedia applications are run with UI's on the EGL and media players on the framebuffer. So if you only need to capture the video players this might work for you. In other cases there is EGL targeting a texture which is copied to the framebuffer, and it will also work just fine.
As far as I know render to texture and stream to a framebuffer is the way they made the sweet Qt UI you see on the Ableton Push 2
More exotic Dispmanx/OpenWF
On some embedded systems (notably the Raspberry Pi and most Broadcom Videocore's) you have DispmanX. Whichs is really interesting:
This is fun:
The lowest level of accessing the GPU seems to be by an API called Dispmanx[...]
It continues...
Just to give you total lack of encouragement from using Dispmanx there are hardly any examples and no serious documentation.
Basically DispmanX is very near to baremetal. So it is even deeper down than the framebuffer or EGL. Really interesting stuff because you can use vc_dispmanx_snapshot() and really get a snapshot of everything really fast. And by fast I mean I got 30FPS RGBA32 screen capture with no noticeable stutter on screen and about 4~6% of extra CPU overhead on a Rasberry Pi. Night and day because glReadPixels got was producing very noticeable framedrops even for 1x1 pixel capture.
That's pretty much what I've found.
I've recently bricked one of my embedded Marvell ARM systems, was upgrading to a new u-boot.bin over TFTP from within u-boot via the bubt tool. bubt fetched the image, burned it to Flash, didn't give any output saying there was anything wrong.
On reboot the system got stuck in an endless loop on the primary bootloader.
Therefore my question is, does the u-boot.bin file have any inbuilt checksums, magic header numbers etc. that could be used to validate the file is good before burning it?
No, there isn't. .bin is a raw image of u-boot.
You could do it yourself encapsulating the raw file into a image file, e.g.: with a file header the hold a CRC32, length of file and so on.
Take notes that the standard u-boot upgrade procedure delete the existant one before to flash the new one. If something happend between cancellation and re-flash the board will be corrupted.
BTW are you sure that your problem belong to a wrong write to memory, and not to a bugged u-boot?
Not sure if this is two question, but I wanted to start with both here in case they are related. I use a Linux PXE and grub for dos boot in various ways. I have used the same file system adding a few scripts here and there but mostly updating the kernel for new hardware. Starting with kernel 3.12.xxx and the latest 3.18 rc4 main line I am getting "oom_adj" deprecated and some wait_for_sysfs errors. My Linux skill level is somewhat basic out of ignorance mostly. I have goggled and learned a lot, so just because I use a term it does not mean I know what I am saying :-)
Background:
I started by remastering P.I.N.G from windowsdream. http://www.windowsdream.com/ping.html This is a cool ISO that will backup and restore hard drive images to a share. It's basically a big Pearl script that uses Linux commands to create shares, save partition, clear and make them back. So I started with that and made a intrd.gz file system. So I imagine a lot of my issues could be out of date lib's, my udev rules need to be updated, or my kernel make file (.config) is wrong. Also, sometimes, not always, my mouse USB will cycle though disconnects/re-connects. It seems to very from boot to boot. This boot may do it and the next boot will not. I will attache some screen shots and my .config file. BTW, P.I.N.G was based on Linux From Scratch (LFS).
Questions:
The open ended question is how to fix it?
Are the following questions related?
Is there setting in the .config to switch from oom_adj to oom_score_adj?
Is the /proc/2000 a lib issue?
Is the waiting_for_sysfs udev rules issues?
For the USB disconnecting/re-connecting, I read somewhere that Intel question something about some timing and some cheaper hardware may have pushed the spec a little. I can not find it any more. I did find something in the .config about using uHCI, but I saw somewhere about xHCI. I assume it has something to do with USB 2.0 vs USB 3.0, but I am not sure. Also, is this USB 1?
Any thoughts?
Looks like there are too many lines for the .config, I don't see how to attach it. If anyone wants to see it, let me know either how to post it or send it to them.
I'm working on embedded device with screen rotated 90 degrees clockwise: screen controller reports 800x600 screen, while device's screen is 600x800 portrait.
What do you think, whose responsibility it is to compensate for this: should kernel rotate framebuffer to provide 800x600 screen as expected by upper-level software or applications (X server, bootsplash) should adapt and draw to rotated screen?
Every part of stack is free software, so there are no non-technical problems for modification, the question is more about logical soundness.
It makes most sense for the screen driver to do it - the kernel after all is supposed to provide an abstraction of the device for the userspace applications to work with. If the screen is a 600x800 portrait oriented device, then that's what applications should see from the kernel.
yes,I agree, The display driver should update the display accordingly and keep the control
Not sure exactly how standard your embedded device is, if it is running a regular linux kernel, you might check in the kernel configurator (make xconfig, when compiling a new kernel) , one of the options for kernel 2.6.37.6 in the device, video card section, is to enable rotation of the kernel messages display so it scrolls 90 degrees left or right while booting up.
I think it also makes your consoles be rotated correctly after login too.
This was not available in kernels even 6-8 months ago, at least not available in kernel that slackware64 13.37 came with about that time.
Note that the bios messages are still rotated on a PC motherboard,
but that is hard-coded in the bios, which may not apply to the embedded system you are working with.
If this kernel feature is not useful to you for whatever reason, how they did it in the linux kernel might be good example of where and how to go about it. Once you get the exact name of the option from "make xconfig", it should be pretty easy to search where ever they log the kernel traffic for that name and dig up some info about it.
Hmmm. I just recompiled my kernel today, and I may have been wrong about how new this option is. Looks like it was available with some kernel versions before the included-with-Slackware64 versions that I referenced. Sorry!