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