<html><body><div><span style="line-height: 1.5;">On Jul 22, 2015, at 05:50 AM, Pavel Pisa <<a href="mailto:pisa@cmp.felk.cvut.cz" onclick="return false;">pisa@cmp.felk.cvut.cz</a>> wrote:</span></div><div><br></div><div><blockquote type="cite"><div class="msg-quote"><div class="_stretch"><span class="body-text-content"><span class="body-text-content">Hello Qiao Yang,<br><br>On Wednesday 22 of July 2015 11:19:35 QIAO YANG wrote:<br></span></span><blockquote class="quoted-plain-text" type="cite">Hi,</blockquote><blockquote class="quoted-plain-text" type="cite"><br></blockquote><blockquote class="quoted-plain-text" type="cite">When I updated to the latest firmware start.elf , the graphic doesn’t show</blockquote><blockquote class="quoted-plain-text" type="cite">anymore. I haven’t yet found out what has been changed in the latest</blockquote><blockquote class="quoted-plain-text" type="cite">firmware. I’ve uploaded my firmware. I’ve retested my latest commit, it</blockquote><blockquote class="quoted-plain-text" type="cite">worked with hello, ticker and rbi samples.</blockquote><blockquote class="quoted-plain-text" type="cite"><br></blockquote><blockquote class="quoted-plain-text" type="cite"><a href="https://www.dropbox.com/sh/95bu6skofkmrlvc/AABXjwvvFhQScJdo_rwj12V6a?dl=0">https://www.dropbox.com/sh/95bu6skofkmrlvc/AABXjwvvFhQScJdo_rwj12V6a?dl=0</a></blockquote><blockquote class="quoted-plain-text" type="cite"><<a href="https://www.dropbox.com/sh/95bu6skofkmrlvc/AABXjwvvFhQScJdo_rwj12V6a?dl=0>">https://www.dropbox.com/sh/95bu6skofkmrlvc/AABXjwvvFhQScJdo_rwj12V6a?dl=0></a></blockquote><span class="body-text-content"><br>I have been able to run your binary of ticker and its console is displayed<br>on the RPi correctly. Whwn I have used your binary and start.elf on my card<br>then it runs OK as well. I have tried even your binary when loaded<br>by u-boot from TFTP server. I have hard time to find right version<br>of U-boot with working network support.<br><br>Only older version works correctly and I am not sure<br>if that one was compiled by me or even loaded from some<br>site<br><br>U-Boot 2014.10-rc2-g600877e-dirty (Sep 25 2014 - 09:57:12)</span></div></div></blockquote><span> </span></div><div>here is a working u-boot for rpi, contributed by swarren.</div><div><a>git://github.com/swarren/u-boot.git</a></div><div>you can checkout his branches rpi_dev*</div><div><br><blockquote type="cite"><div class="msg-quote"><div class="_stretch"><span class="body-text-content"><br><br>But with right U-boot version the binary works as well.<br>I have build successfully ticker binary myself as well.<br><br>Then I have tested my complete graphic application example.<br>I have to disable keyboard and mouse config and then have<br>obstacle with framebuffer driver setup<br><br>#if (BSP_HAS_FRAME_BUFFER == 1)<br> #define CONFIGURE_APPLICATION_NEEDS_FRAME_BUFFER_DRIVER<br>#endif<br><br>#define CONFIGURE_INIT<br>#include <rtems/confdefs.h><br><br>Because raspberrypi BSP does not set define BSP_HAS_FRAME_BUFFER yet.<br>When I forced graphics inclusion then application starts.<br><br>But there seems to be some problem with some parameters obtained<br>from graphic driver probably or some other similar problem<br>because image is screwed on the couple of the first lines.<br>But start of the display seems to be right.<br><br>Parameters<br><br>[#]fb_var_screeninfo: xres : 1280<br>[#]fb_var_screeninfo: yres : 1024<br>[#]fb_var_screeninfo: bpp : 32<br><br>matches monitor info and values in the driver structures looks<br>reasonable either<br><br>fb_fix_info = {smem_start = 0xe6fa000 "\377", smem_len = 5242880,<br> type = 0, visual = 2, line_length = 160}<br><br>But there is a mistake with computed line_length. It is number<br>of bytes for one image line. So next change is required<br><br>--- a/c/src/lib/libbsp/arm/raspberrypi/console/fb.c<br>+++ b/c/src/lib/libbsp/arm/raspberrypi/console/fb.c<br>@@ -126,7 +126,8 @@ fb_init(void)<br> fb_var_info.bits_per_pixel = init_frame_buffer_entries.depth;<br> fb_fix_info.smem_start = init_frame_buffer_entries.base;<br> fb_fix_info.smem_len = init_frame_buffer_entries.size;<br>- fb_fix_info.line_length = fb_var_info.xres/VIDEO_FONT_WIDTH;<br>+ fb_fix_info.line_length = fb_var_info.xres *<br>+ ((fb_var_info.bits_per_pixel + 7) / 8);</span></div></div></blockquote><span>I misunderstood the comment " </span>/* number of chars per line */ <span style="line-height: 1.5;">" I thought it was the number of characters.</span></div><div>Does this fix the mess of first few lines? Or there may be some other problems?</div><div><br><blockquote type="cite"><div class="msg-quote"><div class="_stretch"><span class="body-text-content"><br><br> printk("[#]fb_var_screeninfo: xres : %lu\n", fb_var_info.xres);<br> printk("[#]fb_var_screeninfo: yres : %lu\n", fb_var_info.yres);<br><br>As for the<br><br>fb_var_info = {xres = 1280, yres = 1024, bits_per_pixel = 32,<br> red = {offset = 0, length = 0, msb_right = 0},<br> green = {offset = 0, length = 0, msb_right = 0},<br> blue = {offset = 0, length = 0, msb_right = 0},<br> transp = {offset = 0, length = 0, msb_right = 0}}<br><br>the colors fields locations are missing but that information<br>is ignored by actual Microwindows so it is not problem for now.</span></div></div></blockquote><span><div><span><br></span></div>In fact I didn't quite understand the use of color palette. In some other bsp's implementation, they just define the structure but I didn't see any hardware related code, and some just return zero. I've seen that we can setup the color palettes with videocore interface by mailbox. I can complete that later if necessary. Since it's ignored, I would place it with lower priority.</span></div><div><br><blockquote type="cite"><div class="msg-quote"><div class="_stretch"><span class="body-text-content"><br><br>As for the memory map setup, the RTEMS does use only<br>single level pagetable/MMU regions setup for CP15 (MMU)<br>equipped arms. That means that maping works with 1 MB<br>blocks granularity.<br><br>Look at arm_cp15_start_setup_translation_table() and <br>arm_cp15_start_set_translation_table_entries() functions in<br>in<br><br> c/src/lib/libbsp/arm/shared/include/arm-cp15-start.h<br><br>and other related functions in in<br> c/src/lib/libbsp/arm/shared/arm-cp15-set-ttb-entries.c<br> c/src/lib/libbsp/arm/shared/arm-cp15-set-ttb-entries.c<br><br>The 1 MB granularity/page size is reflected by<br><br> #define ARM_MMU_SECT_BASE_SHIFT 20<br><br>in<br><br> c/src/lib/libcpu/arm/shared/include/arm-cp15.h<br><br>So if you detect size of the memory window for VideoCore,<br>you should align it/extend it down and up to 1 MB boundary<br>or at least consider that behavior of the mapping functions.<br><br>The actual limit of the memory usable for RTEMS application<br>below VideoCore region should be used to setup limit<br>for RTEMS workspace and application memory size later.</span></div></div></blockquote><span>Excuse me, I'm not sure if I've got it right.</span></div><div><span>Do you mean that when I setup the memory area in mmu table, I should make the area aligne to 1MB?</span></div><div><span><br></span></div><div><span>I've understood your ideas on setting up the mmu table. I'll give that a try.</span></div><div><br><blockquote type="cite"><div class="msg-quote"><div class="_stretch"><span class="body-text-content"><br><br>Best wishes,<br><br> Pavel<br></span></div></div></blockquote><span> </span></div><div><span>Thank you very much for all helps.</span></div><div><span><br></span></div><div><span>Best wishes</span></div><div><span><br></span></div></body></html>