Still undergoing attempt to boot Umon from SD

[Ed Sutter]

On 6/28/2015 11:48 PM, Jarielle Catbagan wrote:
> 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.
I wouldn't even think about that until it boots standalone, even then, 
the ethernet
driver would be ranked higher (IMHO) than getting it into RSB.
>
> 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!
Once I get over the repo issues, I'll lend a hand here as well...
>
>> Chris
> Best Regards
> Jarielle
> _______________________________________________
> umon-devel mailing list
> umon-devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/umon-devel