Google SOC project tinyRTEMS

Joel Sherrill joel.sherrill at OARcorp.com
Tue Mar 25 14:26:03 UTC 2008


x ray wrote:
> Try rtl22xx_t BSP, which is a thumb version and 25% smaller.
> I think our goal is reduce the default ARM version of rtl22xx to
> around 24K ROM and <4K RAM for ticker. And the second one (2KRAM) is
> more important and more hard to achieve.
>   
Yes. But a journey of a 1000 miles is made of many steps. :)

For 4.6.6, the smallest executable I could get with the sparc/sis BSP
was ~72K code. For 4.7.1, that number was 57.4K. Today on the CVS
head, that same test executable is 53K with more functionality
enabled and no special compiler flags or conditional compilation.
With compilation options selected to trim it, I have seen ~45K
executables from this test on this BSP.

Also these benefits tend to be across all BSPs. The code is shared
so when you trim fat from one place, all benefit. Some m68k BSPs
have minimums of ~32K now with no attention at all paid to them
specifically.
> BTW, the default stack size for each thread is 4K by default. It seems
> that we also need configuration options for the stack size.
>
>   
This is a good example of how you have to think with RTEMS configuration.
The default stack size could be a conditional compilation option that you
specify when you build RTEMS. Although this would work, it is not desirable
because it would force you to recompile RTEMS to change the default stack
size.

Better would be to add an entry to the RTEMS configuration table for
task minimum stack size. Have the default come from the CPU port
as it does now. But if the user provides a configuration value for this,
then use that.

Obviously the user can produce a very broken system if they configure
a stack size that is too small but that is often the case.

Another interesting TinyRTEMS issue is that currently confdefs.h assumes
all threads are floating point and reserves memory for an FP context. Often
this is way too conservative. There are probably other cases in confdefs.h
that are generous in their estimation.
> BTW, I have registered as a mentor of GSoC.
>
>   
As you know I accepted you. Thanks. :-D

--joel
> 2008/3/25, 阎淼 <yanmiaobest at gmail.com>:
>   
>> Hi,
>>    when using arm rtl22xx bsp, is the default size of minimu.exe about 24k?
>>    mine is much larger than that.
>>    and when using stubs to disable newlibc reentrancy, applications
>>  still need to define CONFIGURE_DISABLE_NEWLIB_REENTRANCY, otherwise
>>  there will be a link error. I think we could make this easier for user
>>  by combining something in confdefs.h and no_lib.c and put it into
>>  optman directory?
>>
>>
>>  2008/3/24, x ray <rayx.cn at gmail.com>:
>>  > I do not aware of the new branch remove the newlib option in the
>>  > latest release.
>>  > From the code you digging now, you will have to add some stub and
>>  > change the automake file first.
>>  >
>>  > As for replace printf to printk, only by doing this can we compile
>>  > ticker. I think we will have to add some release notes for the user if
>>  > they want to use tiny.
>>  >
>>  > I have no idea of how to fill the application firm. Let leave this
>>  > question to Joel.
>>  >
>>  >
>>  > 2008/3/24, 阎淼 <yanmiaobest at gmail.com>:
>>  > > Hello,
>>  > >  The newlibc's option is not functional( rtems-4.8.0 ),  it even does't
>>  > >  compile the newlibc stubs, so we have to do something to make it work.
>>  > >   As for filesystem stubs, it do not automatically link to application,
>>  > >  so we also need to do something.
>>  > >
>>  > >  Redefine prink to printf is a good idea. But maybe there is a problem:
>>  > >  so far as I know, prink in rtems is a subset of printf, what if we
>>  > >  redefine prink to printf, and users use it as real printf function and
>>  > >  supply format specifiers that printk does't support?
>>  > >
>>  > >  And I see iwip is another project in the list, it should be an option
>>  > >  but in long term.
>>  > >
>>  > >  BTW: Is there any form template for us to fill in?
>>  > >
>>  > >
>>  > >  2008/3/24, x ray <rayx.cn at gmail.com>:
>>  > >
>>  > > > You have found where the rub is. : )
>>  > >  >
>>  > >  > The newlibc's option you mentioned have be in the code for a time.
>>  > >  > However, I do not check the correctness of this code.
>>  > >  >
>>  > >  > first, let's set the object :
>>  > >  > (1) From developer's view, we want the newlib, file systems to be configurable
>>  > >  > (2) From user's view, we still need to use a small fraction of newlib
>>  > >  > (printf for example). And, at least. also, Ticker.exe can run without
>>  > >  > newlib and filesystem(ticker is more colse to a real application than
>>  > >  > minium).
>>  > >  >
>>  > >  > So, here is the problem, we want the code small, also we want the
>>  > >  > console driver. In fact, what the user really want, is printk and
>>  > >  > getch/putch instead of whole newlibc+filesystem which will cost them
>>  > >  > 2K+ sram and 4K+ ROM..
>>  > >  >
>>  > >  > What should we do?  We will have to redefine printf to printk, getch
>>  > >  > to BSP_getch…….. Also, made the open_dev_console to an empty function
>>  > >  > (see no-console.c).
>>  > >  >
>>  > >  > Also, we might want to design or include some test case for the tiny rtems.
>>  > >  >
>>  > >  > I also believed that there is something we missed in tiny rtems, that
>>  > >  > is lwip. I think we should put it as an option to users. (This can be
>>  > >  > consider as a long term goal)
>>  > >  >
>>  > >  > 2008/3/23, 阎淼 <yanmiaobest at gmail.com>:
>>  > >  > > Hello,
>>  > >  > >
>>  > >  > >       There are no_libc.c in libcsupport directory. In order to
>>  > >  > >  disable newlib reentrancy, application defines
>>  > >  > >  CONFIGURE_DISABLE_NEWLIB_REENTRANCY in its configuration file and link
>>  > >  > >  to libcsupport_a-nolibc.o ( maybe through manager mechanism, or add
>>  > >  > >  something like --disable-newlibc during configration process).
>>  > >  > >        As for filesystem, put no-filesystem.o into to the final
>>  > >  > >  executable, this is the same as newlibc(add --disable-filesystem or
>>  > >  > >  treat filesystem as a manager, and application should define
>>  > >  > >  CONFIGURE_HAS_OWN_MOUNT_TABLE). But only doing this can not elimiate
>>  > >  > >  all filesystem code out, because in bsp_post_driver_hook, there is a
>>  > >  > >  function open_dev_console, which calls open to create stdin, stdout.
>>  > >  > >  The open function call will get many filesystem stuff in.  So we need
>>  > >  > >  to provide another set of std io routines( open, read, write, ioctl,
>>  > >  > >  close...maybe don't need to implement all of them ), which translate
>>  > >  > >  device name( string like "/dev/console", "/dev/rtc") to its device
>>  > >  > >  number, and use device number to find the right device driver.
>>  > >  > >       If application needs filesystem, everything is not changed,
>>  > >  > >  device creation is through filesystem. If application does't need
>>  > >  > >  filesystem but needs stdio, it is linked to the interface just
>>  > >  > >  provided, mapping device name to  device number. If appliction does't
>>  > >  > >  need stdio and filesystem, it just gets stubs. Am I right?
>>  > >  > >
>>  > >  > >
>>  > >  > >
>>  > >  > >  在 08-3-21,Joel Sherrill<joel.sherrill at oarcorp.com> 写道:
>>  > >  > >
>>  > >  > > > 阎淼 wrote:
>>  > >  > >  > > Hello all,
>>  > >  > >  > >
>>  > >  > >  > >    I  am  interest  in tinyRTEMS project,  I have read the wiki page,
>>  > >  > >  > > and there are a lot of work has been done. I would like to know what
>>  > >  > >  > > is the direction of Tiny RTEMS project.
>>  > >  > >  > >
>>  > >  > >  > As stated, its goal is to shrink the minimum footprint of an RTEMS
>>  > >  > >  > executable
>>  > >  > >  > and a number of issues have already been addressed. Many of the issues are
>>  > >  > >  > fairly subtle and if you are new to RTEMS might be hard to figure out.
>>  > >  > >  >
>>  > >  > >  > One of the larger issues left and probably the only one worth even thinking
>>  > >  > >  > about as a GSOC project are the last three on the list.
>>  > >  > >  >
>>  > >  > >  > *disable newlib reentrancy (which might already be partially there)
>>  > >  > >  > *disable filesystem
>>  > >  > >  > *"device table filesystem". Functionality similar to how device names were
>>  > >  > >  > handled in RTEMS 4.0.0. Now we have a real POSIX style filesystem with
>>  > >  > >  > devices. Then we had a lookup table which mapped device names into
>>  > >  > >  > major/minor. So when you call open(), the device name isn't looked up
>>  > >  > >  > in a filesystem, it is looked up in a table of strings.
>>  > >  > >  >
>>  > >  > >  > Many of the TinyRTEMS ideas require the addition of application time
>>  > >  > >  > configuration to select the run-time capabilities. This one is a bit harder
>>  > >  > >  > because it spans the IO and filesystem infrastructure. You will have to
>>  > >  > >  > baseline
>>  > >  > >  > the size of the minimum, hello and ticker executables and work to eliminate
>>  > >  > >  > filesystem code you are replacing with a lighter alternative.
>>  > >  > >  >
>>  > >  > >  > In minimum, you want to push to have NO filesystem and IO code.
>>  > >  > >  >
>>  > >  > >  > In hello, you want the "device name lookup".
>>  > >  > >  >
>>  > >  > >  > Together the list above looks to be about 1/3-1/2 of the code in the minimum
>>  > >  > >  > executable on the ARM/Thumb rtl22xx_t BSP I use as a reference. So even
>>  > >  > >  > though
>>  > >  > >  > you might only save 8-12K total, you are moving from ~24K to 12-16K minimum.
>>  > >  > >  >
>>  > >  > >  > Does that make sense?
>>  > >  > >  >
>>  > >  > >  >
>>  > >  > >  > NOTE: Many space based systems using RTEMS do not use the filesystem and
>>  > >  > >  > hack it out anyway. This is just providing this reduced functionality
>>  > >  > >  > mode as
>>  > >  > >  > a real configure option.
>>  > >  > >  > > _______________________________________________
>>  > >  > >  > > rtems-users mailing list
>>  > >  > >  > > rtems-users at rtems.com
>>  > >  > >  > > http://rtems.rtems.org/mailman/listinfo/rtems-users
>>  > >  > >  > >
>>  > >  > >  >
>>  > >  > >  >
>>  > >  > >  > --
>>  > >  > >  > Joel Sherrill, Ph.D.             Director of Research & Development
>>  > >  > >  > joel.sherrill at OARcorp.com        On-Line Applications Research
>>  > >  > >  > Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>>  > >  > >  >   Support Available             (256) 722-9985
>>  > >  > >  >
>>  > >  > >  >
>>  > >  > >  >
>>  > >  > >  _______________________________________________
>>  > >  > >  rtems-users mailing list
>>  > >  > >  rtems-users at rtems.com
>>  > >  > >  http://rtems.rtems.org/mailman/listinfo/rtems-users
>>  > >  > >
>>  > >  >
>>  > >  >
>>  > >  > --
>>  > >  > Thanks & Best Regards!
>>  > >  >
>>  > >  > Ray, Xu
>>  > >  >
>>  > >
>>  >
>>  >
>>  > --
>>  > Thanks & Best Regards!
>>  >
>>  > Ray, Xu
>>  >
>>
>>     
>
>
> --
> Thanks & Best Regards!
>
> Ray, Xu
>   


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985





More information about the users mailing list