First run of removing code specific to CSB740/OMAP3530 and replacing it with that of BBB/AM335xin BBB port

Ed Sutter edsutterjr at
Tue Jun 23 03:49:43 UTC 2015

Ok, my bad... Yea, I do  recall reading these earlier today, and they were staring
at me in my inbox...
Got 'em now...

By the way, here' s my current hunt...
Based on your earlier emails, I was able to quickly catch up and isolate things to the
isspace macro as well.   I think we're close...
Notice at the top of the docmd.c file... there are two strange pointers

const char *__ctype_ptr;
conts char *__ctype_ptr__;

without them compilation fails.  With them, runtime crashes.
These pointers are null, and my guess is that somewhere they should have been
pre-initialized.  The fact that they are null explains the exception.

I recall in the process of me pulling out some of the code that we decided not to use
for RTEMS (my own local version of the ctype stuff); I found that linkage failed without
these pointers.  Adding them cleaned up the link, but is apparently not the correct
approach.  They need to be initialized, but I'm not sure how.

It was issues like this that caused me to pull this kind of stuff right into the umon
source tree in the first place....
Anyway, I'm 99% sure that's the cause of the exception, lemme know what you think.
I'll be calling it quits shortly...
> Ed,
> I apologize for the inconvenience, but I forgot to mention I submitted
> an additional four patches after the set of 13.  One of which updates
> the BOOTRAMBASE and BOOTROMBASE variables.  Another one updates the
> CONSOLE_UART_BASE, another updates the -mcpu compiler option, and
> another, which I think is crucial, maps Umon's exception handlers in
> the AM335x exception vector table.
> Here are the links to the patches :
> 1.
> 2.
> 3.
> 4.
> On Mon, Jun 22, 2015 at 7:50 PM, Ed Sutter <edsutterjr at> wrote:
>> Jarielle,
>> Ok, I think I'm where you are now.  Good job with the patches!
>> Note, I'm *still* not using the RTEMS compiler (which I need to do).  I
>> just wanted to walk through some of the patches to see if I could get
>> to your state.  Building it this way, it appears that I have the same
>> problem
>> you've been talking about.  On the other hand, if I build off of umon1.19
>> there is no problem (which, again, I think is the same thing you reported).
>> I had to make two changes after applying all the patches you submitted, but
>> you must have them already.  Let me know if you disagree...
>> They are regarding the BOOTROMBASE/BOOTRAMBASE variables in the Makefile
>> and the UART base address in config.h.
>> The intelligent thing at this point would be to back off and install the
>> compiler; however, its too late to start that now so I'm just gonna play
>> around
>> with this for an hour or so...
>> Ed
>> diff --git a/ports/beagleboneblack/Makefile b/ports/beagleboneblack/Makefile
>> index 77af32d..7986561 100644
>> --- a/ports/beagleboneblack/Makefile
>> +++ b/ports/beagleboneblack/Makefile
>> @@ -23,14 +23,15 @@ CUSTOM_CFLAGS       = -mcpu=arm1136j-s -O2 -isystem
>> $(ABIDIR)/include -Wno-char
>>   # Memory map configuration:
>>   # The following variables are used to establish the system's memory map.
>>   #
>> -BOOTROMBASE=0x08000000
>> +BOOTROMBASE=0x402f0400
>>   BOOTROMLEN=0x100000
>> -BOOTRAMBASE=0x80000000
>> +BOOTRAMBASE=0x40300400
>>   BOOTRAMLEN=0x100000
>>   RAMTSTROMBASE=0x80100000
>>   RAMTSTROMLEN=0x100000
>>   ATAGSIZE=0x1000
>> +
>>   # These next two hard-coded values are used by the ramtst version of
>>   # uMon to allow it to know where these flash-based structures are located.
>>   MACADDRBASE=0x08000020
>> diff --git a/ports/beagleboneblack/config.h b/ports/beagleboneblack/config.h
>> index c623456..e246f88 100644
>> --- a/ports/beagleboneblack/config.h
>> +++ b/ports/beagleboneblack/config.h
>> @@ -25,7 +25,8 @@
>>    */
>>   //#define MORE_PUTCHAR lcd_putchar
>>   //#define CONSOLE_UART_BASE (OMAP35XX_L4_IO_BASE+0x6C000)
>> -#define CONSOLE_UART_BASE 0x4806C000
>> +//#define CONSOLE_UART_BASE 0x4806C000
>> +#define CONSOLE_UART_BASE 0x44e09000
>>   #define SIO_STEP 4
>>   #define IEN_DEFAULT 0x40
>> @@ -143,8 +144,8 @@
>>    * allocated to malloc in the monitor.  Note that this size can be
>> dynamically
>>    * increased using the heap extension option in the heap command.
>>    */
>> -#define ALLOCSIZE      1024    // (64*1024)
>> -#define MONSTACKSIZE   (16*1024)
>> +#define ALLOCSIZE              (1*1024)
>> +#define MONSTACKSIZE   (1*1024)
>>   // Cogent specific options
>>   #define INCLUDE_I2C                            0
>> _______________________________________________
>> umon-devel mailing list
>> umon-devel at

More information about the umon-devel mailing list