Still undergoing attempt to boot Umon from SD
ed.sutter at alcatel-lucent.com
Mon Jun 29 12:41:14 UTC 2015
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,
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
> 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...
> Best Regards
> umon-devel mailing list
> umon-devel at rtems.org
More information about the umon-devel