Still undergoing attempt to boot Umon from SD

[Jarielle Catbagan]

On Sun, Jun 28, 2015 at 7:43 PM, Chris Johns <chrisj at rtems.org> wrote:
> On 29/06/2015 12:10 pm, Jarielle Catbagan wrote:
>>
>> I did worked on trying to get "raw" mode working very briefly before I
>> switched over to try to boot off of an MBR/FAT filesystem.  I actually
>> did not take into account about the potential issue with SFN/LFN, but
>> now that you mentioned it I'll try to get "raw" mode working.
>>
>
> I suspect the reason umon is not booting is common to both approaches.
>
>>
>> Interesting, I'll definitely take a look into it to see if I could use this.
>>
>
> The #beagle IRC channel maybe able to help.
>
>>
>> I did manage to get Umon built using the RTEMS tools.  One thing worth
>> mentioning is that the current Umon sources has an external dependence
>> on the C library, and so I had to link it with the RTEMS C library.
>> The reason for this external dependence is that the previous Umon
>> version contained files that defined functions that would otherwise be
>> defined by the C library but had to be removed due to a conflict in
>> licenses.  In the meantime until a solution is provided to remove this
>> dependence on the external C library, Ed has provided me with the
>> necessary files as a temporary fix for now.  With these temporary
>> files, I am able to build the current version of Umon that I have
>> right now with the RTEMS tools without linking to the RTEMS C library.
>>
>
> Not using RTEMS's libc is important.
>
> Once the files are in the umon repo I will build and take a close look
> with JTAG.

The uMon repo actually has the patches I submitted merged in already.
It allows a basic uMon image for the BBB to be built. The only thing
is that the master uMon repo is not set up yet to build using the
RTEMS tools.  The reason for this is that I wanted to get the
necessary files that removed the data exception that was occurring
merged in before updating the build process to use the RTEMS tools
instead.  I do want to mention that I plan to get uMon integrated into
the RTEMS Source Builder and have it built that way and so I'll be
taking a closer look into this shortly.  Any advice on how I should
proceed will be much appreciated.

The files that temporarily rectify the data exception is not included
but building uMon should allow it to still reach the uMon command
line.  And so to have the master uMon repo to build using the RTEMS
tools is just a matter of updating the ABIDIR and the TOOL_PREFIX
variables in the BBB Makefile.

So to build the master uMon sources using the RTEMS tools, in my case
the values of these variables were simply

ABIDIR = $(HOME)/opt/lib/gcc/arm-rtems4.11/4.9.2

and

TOOL_PREFIX = $(HOME)/opt/bin/arm-rtems4.11

then the steps to build uMon with the current directory pointed to the
BBB port directory are

$ source bashrc
$ make boot

which then produces the binaries in the build_BEAGLEBONEBLACK
directory.  The built image is boot.bin.

If it's not much trouble at all, if you do take a closer look at uMon
attempting to boot off of an SD card, that would be great!

>
> Chris

Best Regards
Jarielle