Still undergoing attempt to boot Umon from SD

[Ed Sutter]

On 6/29/2015 11:15 AM, Jarielle Catbagan wrote:
> On Sun, Jun 28, 2015 at 11:21 PM, Chris Johns <chrisj at rtems.org> wrote:
>> On 29/06/2015 1:48 pm, Jarielle Catbagan wrote:
>>>> 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.
>> Ok.
>>
>>> 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.
>> Once it is building on the supported hosts it should be easy.
>>
>>> 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
>> I do not have bash installed.
> Oh I see.  The build process would have to be updated to be more
> general. Or perhaps, correct me if I am wrong, once uMon is at a
> certain point to be ready to be integrated with RSB, this would
> probably be not an issue as the build process would be more
> standardized.
IIRC, there's nothing in there that's bash specific.  Its just setting 
up some
environment variables used by the makefile.
The stuff in there should be independent of the shell.  I had used that name
because I used to kick off a bash shell to startup in that directory and 
be a
custom environment setup for uMon devel.
I suppose, a name change would be in order at a minimum.
>> Chris
>>
>>> 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!
>>>
>> I will try but I am traveling later this week and thing have already
>> piped up.
>>
>> Chris
> No worries.  If ever, I will look at it through JTAG once I have my
> JTAG debugger set up.
> _______________________________________________
> umon-devel mailing list
> umon-devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/umon-devel