Google SOC project tinyRTEMS
x ray
rayx.cn at gmail.com
Tue Mar 25 06:47:09 UTC 2008
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.
BTW, the default stack size for each thread is 4K by default. It seems
that we also need configuration options for the stack size.
BTW, I have registered as a mentor of GSoC.
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
More information about the users
mailing list