Looks like there is already framebuffer support for RPi, but still I would like to play with it and add some GUI example as in https://blog.thelunatic.dev/gsoc-final-report/
On Sat, Dec 21, 2019 at 2:32 PM Niteesh <gsnb...@gmail.com> wrote: > I am very much interested in taking part in GSOC 2020. I want to get this > running on raspberrypi3 > so that I could start learning and exploring more of RTEMS. I am planning > to add framebuffer support, using this year's GSOC work > on beagle bone as a reference. > On Sat, Dec 21, 2019 at 2:20 PM Christian Mauderer <l...@c-mauderer.de> > wrote: > >> On 21/12/2019 08:28, Niteesh wrote: >> > Did you take a look at the exception? >> >> Not yet. >> >> > I still couldn't get it running on >> > the rpi3 using rpi2 bsp. >> >> Again: It's quite likely that the serial interface is a problem. I don't >> think that you'll see any output on rpi3 without changes. >> >> > I built the bsp again by checking out a commit before >> > c5fd79cd4704a4270ba0114a1009ab8556f997c9 >> > and created a kernel.img using objcopy. >> >> That should work. But Most likely you'll get your output on the serial >> interface that is pointing to the bluetooth module. >> > I configured such that PL011 it is pointing to the serial port. We can do > that by adding disable-bt in the config.txt file. > >> > I tried running it on gdb with set scheduler-locking on. I seem to jump >> > to bsp_vector_table_begin and hang there (0x000000c). >> >> I thought you don't have a debugger connected? How do you run it with gdb? > > Ran the executable with qemu and connected to it. > qemu-system-arm -M raspi2 -m 1G -kernel hello.exe -serial mon:stdio > -nographic -S -s > >> >> > >> > >> > On Sat, Dec 21, 2019 at 1:42 AM Christian Mauderer <l...@c-mauderer.de >> > <mailto:l...@c-mauderer.de>> wrote: >> > >> > On 20/12/2019 19:19, Niteesh wrote: >> > > How do you test a patch? Do you checkout that particular commit >> and >> > > build and the BSP again?. >> > >> > Basically yes: You check out the version that you want fixed and >> apply >> > the patch. In that case I have gone back and forward a few times to >> find >> > the commit that introduced the second bug. >> > >> > > @Christian Mauderer <mailto:l...@c-mauderer.de >> > <mailto:l...@c-mauderer.de>> how did you build it >> > > for the rpi1? Did you follow the steps as in previous threads? >> > >> > Basically the same steps like for every BSP: >> > 1. Build a recent toolchain using RSB. >> > 2. Build the BSP. >> > 3. Test it on the board. >> > >> > For the rpi1 the BSP is "raspberrypi" instead of "raspberrypi2". >> And I >> > didn't install the BSP because I only wanted the tests and no extra >> > application. >> > >> > For testing it I used the guide that you found: Objcopy into a >> binary >> > file and replace the kernel.img with it. >> > >> > > and how did you come to the conclusion that these changes cause >> the >> > > exceptions, >> > >> > I had a look at the history of the raspberry BSP (`gitk >> > bsps/arm/raspberrypi` or `git log bsps/arm/raspberrypi`) and looked >> for >> > suspicious patches. For the raspberry there are not much patches in >> the >> > last year so that was quite easy. Then I just tested before and >> after >> > some of the patches to find the ones that introduced the bugs. >> > >> > Again: In this case it was necessary to backport Sebastians patch so >> > that I have been able to test before / after the one that >> introduces the >> > exception. >> > >> > I haven't had a detailled look at the exception yet but I assume >> it's >> > some problem that the wrong variant is used or that my RPi1 is an >> early >> > model with less RAM or something like that. >> > >> > > as a beginner these ideas >> > > will help in the future. >> > > On Fri, Dec 20, 2019 at 2:46 PM Christian Mauderer >> > <l...@c-mauderer.de <mailto:l...@c-mauderer.de> >> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>> wrote: >> > > >> > > On 20/12/2019 09:22, Christian Mauderer wrote: >> > > > On 20/12/2019 07:33, Sebastian Huber wrote: >> > > >> On 19/12/2019 15:28, Niteesh wrote: >> > > >>> As far as I know, 0x8000 is a fixed address where the >> > bootloader >> > > jumps >> > > >>> to after loading the application assuming the CPU is in >> > 32bit mode. >> > > >>> For 64bit mode, it jumps to 0x80000. >> > > >> >> > > >> Would you mind testing this patch: >> > > >> >> > > >> >> > https://lists.rtems.org/pipermail/devel/2019-December/056551.html >> > > >> >> > > > >> > > > On the Pi 1 now the binary has three time the size (with a >> > lot of 0x00 >> > > > in it) and at least RTEMS starts. But it runs into an >> > exception quite >> > > > fast. I'll investigate that a bit. >> > > > >> > > > @Niteesh: For the Pi 3 I would expect that it still doesn't >> > print >> > > > anything on the console due to the different UART pins. >> > > > >> > > > The output on the Pi 1 is: >> > > > >> > > > executing� >> > > > *** FATAL *** >> > > > fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION) >> > > > >> > > > R0 = 0xfc037f80 R8 = 0x00000000 >> > > > R1 = 0xfc345980 R9 = 0x00000010 >> > > > R2 = 0x00000001 R10 = 0xfc037f8a >> > > > R3 = 0x03fc8080 R11 = 0x0030da00 >> > > > R4 = 0xfc037f80 R12 = 0xfc345988 >> > > > R5 = 0x00000008 SP = 0x00300ba8 >> > > > R6 = 0x0030d9fe LR = 0x00205a78 >> > > > R7 = 0x00305218 PC = 0x00205ac8 >> > > > CPSR = 0x600001d3 VEC = 0x00000004 >> > > > RTEMS version: >> 5.0.0.254f38583fe68c3e17dfe274a2deeb00a5a538d6 >> > > > RTEMS tools: 7.5.0 20191114 (RTEMS 5, RSB 5 (6c65fc237b9e >> > modified), >> > > > Newlib d14714c69) >> > > >> > > The exception seems to be caused by some of the changes in >> > bspstart.c >> > > and bspgetworkarea.c in patch >> > a4d7e4cee77d16b0e34ef543f0804e7eb2954137. >> > > So the fix for the linker command file is fine. >> > > >> > >> >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
