* Re: [PATCH] console - Add configurable support for console charset translation
From: Rob Landley @ 2008-06-03 21:31 UTC (permalink / raw)
To: Matt Mackall; +Cc: H. Peter Anvin, Tim Bird, linux-tiny, linux-embedded
In-Reply-To: <1212507964.3953.67.camel@calx>
On Tuesday 03 June 2008 10:46:04 Matt Mackall wrote:
> On Mon, 2008-06-02 at 18:34 -0700, H. Peter Anvin wrote:
> > Tim Bird wrote:
> > > With CONSOLE_TRANSLATIONS turned off, this saves about 6K
> > > on my kernel configured for an ARM development board (OMAP
> > > 5912 OSK). In embedded products I'm familiar with,
> > > console translations are not needed.
> >
> > On most embedded products I'm familiar with, you wouldn't have virtual
> > consoles at all...?
>
> Actually, lots have frame buffers these days.
Cell phones, for instance.
My research is out of date now, but back in 2007 I tried to give a sense of
scale at my cross compiling tutorial at OLS. A cut and paste from my
(18 month old) notes:
--------------------------------------------------------------------------
According to http://eetimes.eu/showArticle.jhtml?articleID=199702110
Arm shipped the processors in 250 million "smart phones" in 2006 (83%
market share in that niche).
According to ARM Inc. quarterly results for Q1 2007:
http://media.corporate-ir.net/media_files/irol/19/197211/press/Q12007EarningsRelease.pdf
In the first quarter of 2007, the licensees of ARM Inc. shipped 724 million
ARM processors. In one quarter. (ARM Inc. collected $45 million in license
fees, which is an average of 6.2 cents/processor.)
In a May 23 2006 presentation to ARM investors, ARM Inc. estimated its 2006
market share at 80-90% of the cell phone market, but only 21% of the larger
market. (The embedded world is big, folks.)
Drew highlighted five key growth areas for ARM between now and 2010...
[The first four are] set-top-box, high-definition television and DVD systems,
solid-state and hard disk drive storage, automotive electronics and 32-bit
microcontrollers. In these areas in 2006, ARM had market shares of 14, 20,
5 and 13 percent respectively... They are also market sectors that will
represent a total available annual market of nearly a billion cores or more
each in 2010. The biggest annual market opportunities are likely to be
automotive and 32-bit microcontrollers at 2.0 billion and 1.9 billion cores
each.
ARM's fifth key target market is the smart phone, where it is already
enjoying success. In this area the company shipped 250 million units in 2006
and has a market share of 83 percent, according to its own estimates.
--------------------------------------------------------------------------
(And that's why Apple did the iPhone.)
Speaking of set-top boxes (another thing with a framebuffer), Netflix is
transitioning its business model to video-on-demand, with a $99 set top box
that runs Linux on Arm:
http://www.linuxdevices.com/news/NS8633598605.html
Here's the CEO of netflix saying the DVD-by-mail business will peak within
the next 5 years:
http://www.reuters.com/article/marketsNews/idINN2843042120080528?rpc=44
And the manufacturer almost immediately went to a 10 day wait on delivery of
new devices:
http://forums.roku.com/viewtopic.php?t=16722
(And that's why Apple did Apple TV.)
Rob
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
^ permalink raw reply
* Re: [PATCH] console - Add configurable support for console charset translation
From: Matt Mackall @ 2008-06-03 21:30 UTC (permalink / raw)
To: Rob Landley; +Cc: linux-tiny, linux-embedded
In-Reply-To: <200806031618.06523.rob@landley.net>
On Tue, 2008-06-03 at 16:18 -0500, Rob Landley wrote:
> On Monday 02 June 2008 17:37:09 Tim Bird wrote:
> > With CONSOLE_TRANSLATIONS turned off, this saves about 6K
> > on my kernel configured for an ARM development board (OMAP
> > 5912 OSK). In embedded products I'm familiar with,
> > console translations are not needed.
> >
> > This was taken from the Linux-tiny project and updated slightly
> > for 2.6.25.
>
> Er, what _is_ the relationship between linux-tiny and linux-embedded lists
> now?
>
> I've been on linux-tiny for years, but it's been mostly dead since Matt moved
> on (not one message in the whole of may, 4 the month before that), and this
> seems the more logical place to discuss kernel patches that might actually
> want to go upstream someday anyway.
Linux-embedded is the place to be, folks. It's intended to be the
catch-all list for embedded kernel work. When traffic there picks up a
bit more, I'll start bouncing linux-tiny mail.
--
Mathematics is the supreme nostalgia of our time.
^ permalink raw reply
* Re: [PATCH] console - Add configurable support for console charset translation
From: David Woodhouse @ 2008-06-03 21:26 UTC (permalink / raw)
To: Rob Landley; +Cc: linux-tiny, Tim Bird, linux-embedded
In-Reply-To: <200806031618.06523.rob@landley.net>
On Tue, 2008-06-03 at 16:18 -0500, Rob Landley wrote:
> Er, what _is_ the relationship between linux-tiny and linux-embedded lists
> now?
There's been a bunch of embedded-related lists, and one of the reasons
for doing linux-embedded@vger (rather than @lists.infradead.org as would
have been my first inclination) is to set up an 'official' one that
people can congregate on.
--
dwmw2
^ permalink raw reply
* Re: [PATCH] console - Add configurable support for console charset translation
From: Rob Landley @ 2008-06-03 21:18 UTC (permalink / raw)
To: linux-tiny; +Cc: Tim Bird, linux-embedded
In-Reply-To: <48447615.5050806@am.sony.com>
On Monday 02 June 2008 17:37:09 Tim Bird wrote:
> With CONSOLE_TRANSLATIONS turned off, this saves about 6K
> on my kernel configured for an ARM development board (OMAP
> 5912 OSK). In embedded products I'm familiar with,
> console translations are not needed.
>
> This was taken from the Linux-tiny project and updated slightly
> for 2.6.25.
Er, what _is_ the relationship between linux-tiny and linux-embedded lists
now?
I've been on linux-tiny for years, but it's been mostly dead since Matt moved
on (not one message in the whole of may, 4 the month before that), and this
seems the more logical place to discuss kernel patches that might actually
want to go upstream someday anyway.
Just curious...
Rob
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
^ permalink raw reply
* Re: initramfs size limitation
From: Rob Landley @ 2008-06-03 20:59 UTC (permalink / raw)
To: Mike Frysinger; +Cc: pwilshire, linux-embedded
In-Reply-To: <8bd0f97a0806011725u3dc70e2cy1b317b2b6564f5c8@mail.gmail.com>
On Sunday 01 June 2008 19:25:11 Mike Frysinger wrote:
> On Sun, Jun 1, 2008 at 8:03 PM, Rob Landley wrote:
> > On Saturday 31 May 2008 07:44:14 Phil Wilshire wrote:
> >> I hope this is the right place and the right sort of question.
> >>
> >> I work closely with the Blackfin systems and they have now integrated
> >> the initramfs generation into their system build. The result is great
> >> the root fs is ready to run from the page cache.
> >
> > Is it possible to get blackfin working with a vanilla gcc release yet, or
> > do you still need out-of-tree patches? (I have a blackfin board I got at
> > OLS, but it needs a toolchain I can't reproduce.)
>
> there's plenty of usable binaries available
I like to build things from source. (I'm funny that way, I realize this is
totally out of place when dealing with Linux, but it's what I do.) I also
like to use vanilla release packages where possible, and failing that a patch
against against the release version. (Again, a personal idiosyncrasy...)
To me, saying "you need this binary-only toolchain to build" is like
saying "you need this binary-only driver to boot".
> > fact it would be really nice if qemu grew blackfin support because
> > messing
>
> i imagine it would be ... too bad qemu lacks real documentation
Actually there was documentation on the old stuff if you knew where to dig it
up (a good starting point was Fabrice's old usenix paper and then I had some
links I'd collected from there), but they just ripped out the old code
generator in favor of a new one
(See http://lists.gnu.org/archive/html/qemu-devel/2008-02/msg00011.html ) so
there's not much point in going there right now. (Hopefully they'll have a
1.0 release within our lifetimes.)
I'm guessing that's why your qemu blackfin work on wh0rd.net stalled last
year?
Rob
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
^ permalink raw reply
* Re: [PATCH] console - Add configurable support for console charset translation
From: Matt Mackall @ 2008-06-03 15:46 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Tim Bird, linux-tiny, linux kernel, linux-embedded
In-Reply-To: <48449FAE.70404@zytor.com>
On Mon, 2008-06-02 at 18:34 -0700, H. Peter Anvin wrote:
> Tim Bird wrote:
> > With CONSOLE_TRANSLATIONS turned off, this saves about 6K
> > on my kernel configured for an ARM development board (OMAP
> > 5912 OSK). In embedded products I'm familiar with,
> > console translations are not needed.
>
> On most embedded products I'm familiar with, you wouldn't have virtual
> consoles at all...?
Actually, lots have frame buffers these days.
--
Mathematics is the supreme nostalgia of our time.
^ permalink raw reply
* Re: [PATCH] console - Add configurable support for console charset translation
From: David Woodhouse @ 2008-06-03 14:10 UTC (permalink / raw)
To: Holger Schurig; +Cc: linux-tiny, Tim Bird, linux kernel, linux-embedded
In-Reply-To: <200806031606.29574.hs4233@mail.mn-solutions.de>
On Tue, 2008-06-03 at 16:06 +0200, Holger Schurig wrote:
> Maybe change the Kconfig entry so that:
>
> * with CONFIG_EMBEDDED=y it's configuration
> * with CONFIG_EMBEDDED=n it's on by default
That's what Tim's patch did (although I moved it to drivers/char/Kconfig
and made it depend on CONFIG_VT).
--
dwmw2
^ permalink raw reply
* Re: [PATCH] console - Add configurable support for console charset translation
From: Holger Schurig @ 2008-06-03 14:06 UTC (permalink / raw)
To: linux-tiny; +Cc: David Woodhouse, Tim Bird, linux kernel, linux-embedded
In-Reply-To: <1212500751.16924.322.camel@pmac.infradead.org>
Maybe change the Kconfig entry so that:
* with CONFIG_EMBEDDED=y it's configuration
* with CONFIG_EMBEDDED=n it's on by default
^ permalink raw reply
* Re: [PATCH] console - Add configurable support for console charset translation
From: David Woodhouse @ 2008-06-03 13:45 UTC (permalink / raw)
To: Tim Bird; +Cc: linux-tiny, linux-embedded, linux kernel
In-Reply-To: <48447615.5050806@am.sony.com>
On Mon, 2008-06-02 at 15:37 -0700, Tim Bird wrote:
> With CONSOLE_TRANSLATIONS turned off, this saves about 6K
> on my kernel configured for an ARM development board (OMAP
> 5912 OSK). In embedded products I'm familiar with,
> console translations are not needed.
>
> This was taken from the Linux-tiny project and updated slightly
> for 2.6.25.
I prefer it like this... we can drop consolemap.o and
consolemap_deftbl.o from the build completely. It saves 7.2KiB on a
ppc32 build here.
diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 595a925..f740190 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -36,6 +36,13 @@ config VT
If unsure, say Y, or else you won't be able to do much with your new
shiny Linux system :-)
+config CONSOLE_TRANSLATIONS
+ default y
+ bool "Enable character translations in console" if EMBEDDED
+ ---help---
+ This enables support for font mapping and Unicode translation
+ on virtual consoles.
+
config VT_CONSOLE
bool "Support for console on virtual terminal" if EMBEDDED
depends on VT
diff --git a/drivers/char/Makefile b/drivers/char/Makefile
index 4c1c584..6ef173c 100644
--- a/drivers/char/Makefile
+++ b/drivers/char/Makefile
@@ -12,8 +12,8 @@ obj-y += mem.o random.o tty_io.o n_tty.o tty_ioctl.o
obj-$(CONFIG_LEGACY_PTYS) += pty.o
obj-$(CONFIG_UNIX98_PTYS) += pty.o
obj-y += misc.o
-obj-$(CONFIG_VT) += vt_ioctl.o vc_screen.o consolemap.o \
- consolemap_deftbl.o selection.o keyboard.o
+obj-$(CONFIG_VT) += vt_ioctl.o vc_screen.o selection.o keyboard.o
+obj-$(CONFIG_CONSOLE_TRANSLATIONS) += consolemap.o consolemap_deftbl.o
obj-$(CONFIG_HW_CONSOLE) += vt.o defkeymap.o
obj-$(CONFIG_AUDIT) += tty_audit.o
obj-$(CONFIG_MAGIC_SYSRQ) += sysrq.o
diff --git a/include/linux/consolemap.h b/include/linux/consolemap.h
index e2bf7e5..c4811da 100644
--- a/include/linux/consolemap.h
+++ b/include/linux/consolemap.h
@@ -3,6 +3,9 @@
*
* Interface between console.c, selection.c and consolemap.c
*/
+#ifndef __LINUX_CONSOLEMAP_H__
+#define __LINUX_CONSOLEMAP_H__
+
#define LAT1_MAP 0
#define GRAF_MAP 1
#define IBMPC_MAP 2
@@ -10,6 +13,7 @@
#include <linux/types.h>
+#ifdef CONFIG_CONSOLE_TRANSLATIONS
struct vc_data;
extern u16 inverse_translate(struct vc_data *conp, int glyph, int use_unicode);
@@ -18,3 +22,13 @@ extern int conv_uni_to_pc(struct vc_data *conp, long ucs);
extern u32 conv_8bit_to_uni(unsigned char c);
extern int conv_uni_to_8bit(u32 uni);
void console_map_init(void);
+#else
+#define inverse_translate(conp, glyph, uni) ((uint16_t)glyph)
+#define set_translate(m, vc) ((unsigned short *)NULL)
+#define conv_uni_to_pc(conp, ucs) ((int) (ucs > 0xff ? -1: ucs))
+#define conv_8bit_to_uni(c) ((uint32_t)(c))
+#define conv_uni_to_8bit(c) ((int) ((c) & 0xff))
+#define console_map_init(c) do { ; } while (0)
+#endif /* CONFIG_CONSOLE_TRANSLATIONS */
+
+#endif /* __LINUX_CONSOLEMAP_H__ */
diff --git a/include/linux/vt_kern.h b/include/linux/vt_kern.h
index 9448ffb..81ed155 100644
--- a/include/linux/vt_kern.h
+++ b/include/linux/vt_kern.h
@@ -12,6 +12,7 @@
#include <linux/mutex.h>
#include <linux/console_struct.h>
#include <linux/mm.h>
+#include <linux/consolemap.h>
/*
* Presently, a lot of graphics programs do not restore the contents of
@@ -54,6 +55,7 @@ void redraw_screen(struct vc_data *vc, int is_switch);
struct tty_struct;
int tioclinux(struct tty_struct *tty, unsigned long arg);
+#ifdef CONFIG_CONSOLE_TRANSLATIONS
/* consolemap.c */
struct unimapinit;
@@ -70,6 +72,18 @@ int con_set_default_unimap(struct vc_data *vc);
void con_free_unimap(struct vc_data *vc);
void con_protect_unimap(struct vc_data *vc, int rdonly);
int con_copy_unimap(struct vc_data *dst_vc, struct vc_data *src_vc);
+#else
+#define con_set_trans_old(arg) (0)
+#define con_get_trans_old(arg) (-EINVAL)
+#define con_set_trans_new(arg) (0)
+#define con_get_trans_new(arg) (-EINVAL)
+#define con_clear_unimap(vc, ui) (0)
+#define con_set_unimap(vc, ct, list) (0)
+#define con_set_default_unimap(vc) (0)
+#define con_copy_unimap(d, s) (0)
+#define con_get_unimap(vc, ct, uct, list) (-EINVAL)
+#define con_free_unimap(vc) do { ; } while (0)
+#endif
/* vt.c */
int vt_waitactive(int vt);
--
dwmw2
^ permalink raw reply related
* Re: [PATCH] console - Add configurable support for console charset translation
From: David Woodhouse @ 2008-06-03 8:36 UTC (permalink / raw)
To: Tim Bird; +Cc: linux-tiny, linux-embedded, linux kernel
In-Reply-To: <48447615.5050806@am.sony.com>
On Mon, 2008-06-02 at 15:37 -0700, Tim Bird wrote:
> With CONSOLE_TRANSLATIONS turned off, this saves about 6K
> on my kernel configured for an ARM development board (OMAP
> 5912 OSK). In embedded products I'm familiar with,
> console translations are not needed.
I'd have been more inclined to put the #ifdef and the empty functions
into <linux/vt_kern.h>. Then you don't need to provide real stub
functions -- they can be inlined at the caller.
--
dwmw2
^ permalink raw reply
* Re: Fwd: Some embedded topics
From: Marco Stornelli @ 2008-06-03 8:32 UTC (permalink / raw)
To: Tim Bird, rob; +Cc: linux-embedded
In-Reply-To: <48407DE5.3000208@am.sony.com>
Tim Bird ha scritto:
> Marco Stornelli wrote:
>> There's a MontaVista patent on PRAMFS and I think that most of times
>> when a company hears this thing it skips quickly this solution.
>
> Hmmm. I don't recall anything about a patent on PRAMFS.
>
> There are lots of issues here, but I think it's OK to use.
> At a minimum, MontaVista's PRAMFS was submitted to the CE Linux Forum
> in an older kernel (2.4.20-based). MontaVista was well-aware
> of this submission (although it did not come directly from them).
> MV was under an IP agreement with CELF which required them to
> disclose such patents to the forum, and none was received.
>
> In any event (and without wanting to start a large off-topic legal
> thread here), some lawyers would interpret the knowing publication
> of an implementation embodying a patent under the GPL to be an
> implicit license of use for the patent.
>
> YMMV. IANAL. Seek your own counsel on this.
>
>> Sometimes ago I sent a porting to 2.6.24, but I didn't receive any
>> response.
>
> I'd love to see this. Did this go to LKML? If so, about when?
> (Alternatively, could you make it available somewhere?)
>
> Thanks,
> -- Tim
>
> =============================
> Tim Bird
> Architecture Group Chair, CE Linux Forum
> Senior Staff Engineer, Sony Corporation of America
> =============================
>
>
From MontaVista site:
"...File system designed by MontaVista Software for embedded systems -
MontaVista has a patent pending on this code, but is licensing the
patent freely for use in GPL software."
I agree with you Tom and Rob but I meant that especially for a little
company only reading "patent pending" can be dread, and you know that
legal arguments can be long and expensive.
About my patch, I sent an email to Steve Longerbeam on March because I
read his name on the pramfs sourceforge project page. Now I haven't the
patch anymore, however the latest patch is for 2.6.10 and the porting to
2.6.24 was easy because there weren't a lot of differences.
Regards.
--
Marco Stornelli
Embedded Software Engineer
CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
http://www.coritel.it
marco.stornelli@coritel.it
+39 06 72582838
^ permalink raw reply
* Re: [PATCH] console - Add configurable support for console charset translation
From: Jamie Lokier @ 2008-06-03 7:00 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Tim Bird, linux-tiny, linux-embedded, linux kernel
In-Reply-To: <48449FAE.70404@zytor.com>
H. Peter Anvin wrote:
> Tim Bird wrote:
> >With CONSOLE_TRANSLATIONS turned off, this saves about 6K
> >on my kernel configured for an ARM development board (OMAP
> >5912 OSK). In embedded products I'm familiar with,
> >console translations are not needed.
>
> On most embedded products I'm familiar with, you wouldn't have virtual
> consoles at all...?
On anything with a framebuffer, VCs are quite handy for debugging.
Saving 6k won't save the world on those devices, but each little bit
helps - especially due to no-MMU fragmentation.
-- Jamie
^ permalink raw reply
* Re: [PATCH] console - Add configurable support for console charset translation
From: H. Peter Anvin @ 2008-06-03 1:34 UTC (permalink / raw)
To: Tim Bird; +Cc: linux-tiny, linux-embedded, linux kernel
In-Reply-To: <48447615.5050806@am.sony.com>
Tim Bird wrote:
> With CONSOLE_TRANSLATIONS turned off, this saves about 6K
> on my kernel configured for an ARM development board (OMAP
> 5912 OSK). In embedded products I'm familiar with,
> console translations are not needed.
On most embedded products I'm familiar with, you wouldn't have virtual
consoles at all...?
-hpa
^ permalink raw reply
* [PATCH] console - Add configurable support for console charset translation
From: Tim Bird @ 2008-06-02 22:37 UTC (permalink / raw)
To: linux-tiny, linux-embedded, linux kernel
With CONSOLE_TRANSLATIONS turned off, this saves about 6K
on my kernel configured for an ARM development board (OMAP
5912 OSK). In embedded products I'm familiar with,
console translations are not needed.
This was taken from the Linux-tiny project and updated slightly
for 2.6.25.
drivers/char/consolemap.c | 81 ++++++++++++++++++++++++++++++++++++++++++++++
drivers/char/vt.c | 4 ++
init/Kconfig | 7 +++
3 files changed, 92 insertions(+)
Signed-off-by: Tim Bird <tim.bird@am.sony.com>
--- a/drivers/char/consolemap.c
+++ b/drivers/char/consolemap.c
@@ -22,6 +22,8 @@
#include <linux/consolemap.h>
#include <linux/vt_kern.h>
+#ifdef CONFIG_CONSOLE_TRANSLATIONS
+
static unsigned short translations[][256] = {
/* 8-bit Latin-1 mapped to Unicode -- trivial mapping */
{
@@ -742,3 +744,82 @@ console_map_init(void)
}
EXPORT_SYMBOL(con_copy_unimap);
+
+#else
+
+u16 inverse_translate(struct vc_data *conp, int glyph, int use_unicode)
+{
+ return glyph;
+}
+
+unsigned short *set_translate(int m, struct vc_data *vc)
+{
+ return NULL;
+}
+
+int con_set_trans_old(unsigned char *arg)
+{
+ return 0;
+}
+
+int con_get_trans_old(unsigned char *arg)
+{
+ return -EINVAL;
+}
+
+int con_set_trans_new(ushort *arg)
+{
+ return 0;
+}
+
+int con_get_trans_new(ushort *arg)
+{
+ return -EINVAL;
+}
+
+int con_clear_unimap(struct vc_data *vc, struct unimapinit *ui)
+{
+ return 0;
+}
+
+int con_set_unimap(struct vc_data *vc, ushort ct, struct unipair *list)
+{
+ return 0;
+}
+
+int con_set_default_unimap(struct vc_data *vc)
+{
+ return 0;
+}
+
+int con_copy_unimap(struct vc_data *d, struct vc_data *s)
+{
+ return 0;
+}
+
+int con_get_unimap(struct vc_data *vc, ushort ct, ushort *uct,
+ struct unipair *list)
+{
+ return -EINVAL;
+}
+
+void con_free_unimap(struct vc_data *vc) { }
+
+int conv_uni_to_pc(struct vc_data *conp, long ucs)
+{
+ return ucs > 0xff ? -1: ucs;
+}
+
+void __init console_map_init(void) { }
+
+u32 conv_8bit_to_uni(unsigned char c)
+{
+ return c;
+}
+
+int conv_uni_to_8bit(u32 uni)
+{
+ return (int)uni & 0xff;
+}
+
+#endif
--- a/drivers/char/vt.c
+++ b/drivers/char/vt.c
@@ -2198,7 +2198,11 @@ rescan_last_byte:
c = 0xfffd;
tc = c;
} else { /* no utf or alternate charset mode */
+#ifdef CONFIG_CONSOLE_TRANSLATIONS
tc = vc->vc_translate[vc->vc_toggle_meta ? (c | 0x80) : c];
+#else
+ tc = c;
+#endif
}
/* If the original code was a control character we
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -758,6 +758,13 @@ config PROC_PAGE_MONITOR
/proc/kpagecount, and /proc/kpageflags. Disabling these
interfaces will reduce the size of the kernel by approximately 4kb.
+config CONSOLE_TRANSLATIONS
+ default y
+ bool "Enable character translations in console" if EMBEDDED
+ help
+ This enables support for font mapping and Unicode translation
+ on virtual consoles.
+
endmenu # General setup
config SLABINFO
^ permalink raw reply
* Re: initramfs size limitation
From: Bryan Wu @ 2008-06-02 0:42 UTC (permalink / raw)
To: Mike Frysinger; +Cc: Rob Landley, pwilshire, linux-embedded
In-Reply-To: <8bd0f97a0806011725u3dc70e2cy1b317b2b6564f5c8@mail.gmail.com>
On Mon, Jun 2, 2008 at 8:25 AM, Mike Frysinger <vapier.adi@gmail.com> wrote:
> On Sun, Jun 1, 2008 at 8:03 PM, Rob Landley wrote:
>> On Saturday 31 May 2008 07:44:14 Phil Wilshire wrote:
>>> I hope this is the right place and the right sort of question.
>>>
>>> I work closely with the Blackfin systems and they have now integrated
>>> the initramfs generation into their system build. The result is great
>>> the root fs is ready to run from the page cache.
>>
>> Is it possible to get blackfin working with a vanilla gcc release yet, or do
>> you still need out-of-tree patches? (I have a blackfin board I got at OLS,
>> but it needs a toolchain I can't reproduce.)
>
> there's plenty of usable binaries available
>
>> fact it would be really nice if qemu grew blackfin support because messing
>
> i imagine it would be ... too bad qemu lacks real documentation
>
>>> There is one problem that I can see that may be more serious for
>>> embedded users.
>>> As far as I can tell the initramfs filesystem is not restricted in size.
>>> You can keep writing files until it uses all available memory.
>>
>> Yup. There have intermittently been patches to make rootfs be tmpfs instead
>> of ramfs, the most recent of which I remember was:
>> http://lkml.org/lkml/2007/7/13/354
>
> it wouldnt matter. tmpfs on NOMMU doesnt support any of the options
> like MMU. look at mm/tiny-shmem.c and init/Kconfig.
> -mike
> --
Right, I still got one bug related to tmpfs/ramfs on NOMMU. That is
the fcntl/cease problem.
Some LTP testcases still fail because of this.
-Bryan
^ permalink raw reply
* Re: initramfs size limitation
From: Mike Frysinger @ 2008-06-02 0:25 UTC (permalink / raw)
To: Rob Landley; +Cc: pwilshire, linux-embedded
In-Reply-To: <200806011903.47135.rob@landley.net>
On Sun, Jun 1, 2008 at 8:03 PM, Rob Landley wrote:
> On Saturday 31 May 2008 07:44:14 Phil Wilshire wrote:
>> I hope this is the right place and the right sort of question.
>>
>> I work closely with the Blackfin systems and they have now integrated
>> the initramfs generation into their system build. The result is great
>> the root fs is ready to run from the page cache.
>
> Is it possible to get blackfin working with a vanilla gcc release yet, or do
> you still need out-of-tree patches? (I have a blackfin board I got at OLS,
> but it needs a toolchain I can't reproduce.)
there's plenty of usable binaries available
> fact it would be really nice if qemu grew blackfin support because messing
i imagine it would be ... too bad qemu lacks real documentation
>> There is one problem that I can see that may be more serious for
>> embedded users.
>> As far as I can tell the initramfs filesystem is not restricted in size.
>> You can keep writing files until it uses all available memory.
>
> Yup. There have intermittently been patches to make rootfs be tmpfs instead
> of ramfs, the most recent of which I remember was:
> http://lkml.org/lkml/2007/7/13/354
it wouldnt matter. tmpfs on NOMMU doesnt support any of the options
like MMU. look at mm/tiny-shmem.c and init/Kconfig.
-mike
^ permalink raw reply
* Re: Fwd: Some embedded topics
From: Rob Landley @ 2008-06-02 0:09 UTC (permalink / raw)
To: Tim Bird; +Cc: Marco Stornelli, Joe MacDonald, linux-embedded
In-Reply-To: <48407DE5.3000208@am.sony.com>
On Friday 30 May 2008 17:21:25 Tim Bird wrote:
> Marco Stornelli wrote:
> > There's a MontaVista patent on PRAMFS and I think that most of times
> > when a company hears this thing it skips quickly this solution.
>
> Hmmm. I don't recall anything about a patent on PRAMFS.
>
> There are lots of issues here, but I think it's OK to use.
> At a minimum, MontaVista's PRAMFS was submitted to the CE Linux Forum
> in an older kernel (2.4.20-based). MontaVista was well-aware
> of this submission (although it did not come directly from them).
> MV was under an IP agreement with CELF which required them to
> disclose such patents to the forum, and none was received.
>
> In any event (and without wanting to start a large off-topic legal
> thread here), some lawyers would interpret the knowing publication
> of an implementation embodying a patent under the GPL to be an
> implicit license of use for the patent.
Yup. Although IBM and Red Hat make this license explicit: you may use (at
least some of) their patents in code licensed under the terms of GPLv2. I
don't know if MontaVista has an explicit license statement or not.
IBM licensed the RCU patents as a condition of the code getting merged into
Linux, and Red Hat's patent policy is here:
http://www.redhat.com/legal/patent_policy.html
More recently, they all joined the "open invention network" which is a
mutually assured destruction patent pool thingy:
http://www.ibm.com/news/us/en/2005/11/2005_11_10.html
http://arstechnica.com/news.ars/post/20070807-google-signs-on-with-open-invention-network.html
Beyond all that, there's a legal theory (as yet untested in court) that taking
patent enforcement action against GPLv2 code is grounds for any copyright
holder in the GPL project to terminate _your_ right to use that code, because
it's a direction violation of GPLv2 clause 6 forbidding additional
restrictions on recipients exercise of rights. (Fairly straightforward
argument, really.)
That hasn't been tested in court, and attempts to do so could easily drag on
for quite a while. The end result could easily be "nobody can legally
distribute the version that violates the patent, including the patentholder"
since GPLv2 is designed to break closed.
I neither know nor care about GPLv3. (As with vogon grandmothers, "In brief:
avoid.")
Rob
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
^ permalink raw reply
* Re: initramfs size limitation
From: Rob Landley @ 2008-06-02 0:03 UTC (permalink / raw)
To: pwilshire; +Cc: linux-embedded
In-Reply-To: <4841481E.8090406@cox.net>
On Saturday 31 May 2008 07:44:14 Phil Wilshire wrote:
> Hi All,
>
> Firstly, thanks for this list I hope we can get some interesting things
> happening.
>
> I have a question regarding initramfs and tmpfs in a NOMMU environment.
/me pleads the fifth.
> I hope this is the right place and the right sort of question.
>
> I work closely with the Blackfin systems and they have now integrated
> the initramfs generation into their system build. The result is great
> the root fs is ready to run from the page cache.
Is it possible to get blackfin working with a vanilla gcc release yet, or do
you still need out-of-tree patches? (I have a blackfin board I got at OLS,
but it needs a toolchain I can't reproduce.)
All my builds these days are based on http://landley.net/code/firmware (and in
fact it would be really nice if qemu grew blackfin support because messing
with real hardware is a pain while using a laptop at coffee shops).
> There is one problem that I can see that may be more serious for
> embedded users.
> As far as I can tell the initramfs filesystem is not restricted in size.
> You can keep writing files until it uses all available memory.
Yup. There have intermittently been patches to make rootfs be tmpfs instead
of ramfs, the most recent of which I remember was:
http://lkml.org/lkml/2007/7/13/354
If they ever got merged, I didn't hear about it. People keep bringing up
vague handwaving about potential problems with memory management setup
sequencing, since tmpfs potentially interacts with swap and that's not set up
yet when tmpfs gets mounted. (Then again no swap partitions are mounted at
that point either.) I'm unaware of anybody who tried it reporting any actual
problems, but oh well...
> ? Would the mainline kernel be receptive to such modifications ?
Post a patch, get a signed-off-by David Woodhouse (in his role as embedded
maintainer), and submit to Andrew Morton's tree. That way, at each point,
you at least know who owes you a response (even if it's "no").
Rob
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
^ permalink raw reply
* Re: Some embedded topics
From: Rob Landley @ 2008-06-01 23:52 UTC (permalink / raw)
To: Josh Boyer; +Cc: Tim Bird, vb, David VomLehn, linux-embedded
In-Reply-To: <20080530190423.67ac3139@vader.jdub.homelinux.org>
On Friday 30 May 2008 19:04:23 Josh Boyer wrote:
> > I'm not sure, however, that the buffers are pushed to user-space,
> > through the daemon, and back to the file system in an expedient manner.
> > I agree it might be worth a look for this use case. We use it at
> > Sony quite a bit and it's valuable.
>
> With a little bit of work, you could have it trace into a circular
> buffer in DRAM. Then you can preserve that via mem= reservations,
> etc.
At this point, I feel the need to remind people of the time Linus Torvalds got
a mac mini, tried to get software suspend working on it, and wound up using
the RTC as a debug register to tell him where it hung/rebooted:
Thread starts here:
https://lists.linux-foundation.org/pipermail/linux-pm/2006-June/008465.html
A few interesting posts in the thread:
https://lists.linux-foundation.org/pipermail/linux-pm/2006-June/008470.html
https://lists.linux-foundation.org/pipermail/linux-pm/2006-June/008475.html
https://lists.linux-foundation.org/pipermail/linux-pm/2006-June/008491.html
Rob
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
^ permalink raw reply
* Re: Some embedded topics
From: Geert Uytterhoeven @ 2008-05-31 13:32 UTC (permalink / raw)
To: Tim Bird
Cc: Rob Landley, T Ziomek, Mike Frysinger, David VomLehn,
linux-embedded
In-Reply-To: <484086B8.4030909@am.sony.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1371 bytes --]
On Fri, 30 May 2008, Tim Bird wrote:
> Geert Uytterhoeven wrote:
> > Yep, we've been doing this on Amiga for more than a decade, when `debug=mem'
> > is
> > passed. Cfr. arch/m68k/tools/amiga/dmesg.c.
>
> Wow! If tidbits like these are going to keep surfacing,
> I feel like maybe CELF should get someone to just
> permanently monitor this list and take interesting
> info like the above and put it on the elinux wiki.
>
> There's a lot of interesting stuff flowing out of
> people's brains onto the list in the last few
> days.... It's great!
> -- Tim
>
> P.S. Is debug=mem something specific to Amiga? I find
> no mention of it in Documentation/kernel-parameters.txt
It's supported on Amiga and Q40, although Q40 is not mentioned in
Documentation/m68k/kernel-options.txt.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · BIC GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* initramfs size limitation
From: Phil Wilshire @ 2008-05-31 12:44 UTC (permalink / raw)
To: linux-embedded
Hi All,
Firstly, thanks for this list I hope we can get some interesting things
happening.
I have a question regarding initramfs and tmpfs in a NOMMU environment.
I hope this is the right place and the right sort of question.
I work closely with the Blackfin systems and they have now integrated
the initramfs generation into their system build. The result is great
the root fs is ready to run from the page cache.
There is one problem that I can see that may be more serious for
embedded users.
As far as I can tell the initramfs filesystem is not restricted in size.
You can keep writing files until it uses all available memory.
It should be possible to mount (or rather remount) the initramfs read
only and use tmpfs for a restricted size read/write file system.
The trouble is that the size option for tmpfs is removed for NOMMU systems.
Has anyone else seem this problem ?
I dont think the fixes are complicated but has any one attempted to fix it ?
Would the mainline kernel be receptive to such modifications ?
Regards
Phil Wilshire
^ permalink raw reply
* Re: Some embedded topics
From: Josh Boyer @ 2008-05-31 0:07 UTC (permalink / raw)
To: Tim Bird
Cc: Geert Uytterhoeven, Rob Landley, T Ziomek, Mike Frysinger,
David VomLehn, linux-embedded
In-Reply-To: <484086B8.4030909@am.sony.com>
On Fri, 30 May 2008 15:59:04 -0700
Tim Bird <tim.bird@am.sony.com> wrote:
> Geert Uytterhoeven wrote:
> > Yep, we've been doing this on Amiga for more than a decade, when `debug=mem' is
> > passed. Cfr. arch/m68k/tools/amiga/dmesg.c.
> >
>
> Wow! If tidbits like these are going to keep surfacing,
> I feel like maybe CELF should get someone to just
> permanently monitor this list and take interesting
> info like the above and put it on the elinux wiki.
I think that's a great idea. Perhaps we can discuss some further
things we can do for interaction at the Embedded Linux BOF for those
attending OLS.
josh
^ permalink raw reply
* Re: Some embedded topics
From: Josh Boyer @ 2008-05-31 0:04 UTC (permalink / raw)
To: Tim Bird; +Cc: vb, David VomLehn, linux-embedded
In-Reply-To: <4840815E.9020002@am.sony.com>
On Fri, 30 May 2008 15:36:14 -0700
Tim Bird <tim.bird@am.sony.com> wrote:
> Josh Boyer wrote:
> > lttng can trace quite a few events. Interrupts, system calls, etc.
> > Might be worth a look, and it's quite well maintained against various
> > kernel versions.
>
> It's pretty heavyweight, but you could use filters to cut down on
> the events traced. By default output goes to the file system, which
> could be on pramfs. (Or NFS - I'm sorry I lost track of the original
> request - don't know if this is an option or not.)
Indeed, it is fairly heavy in what it traces. I was just suggesting it
as a starting point.
> I'm not sure, however, that the buffers are pushed to user-space,
> through the daemon, and back to the file system in an expedient manner.
> I agree it might be worth a look for this use case. We use it at
> Sony quite a bit and it's valuable.
With a little bit of work, you could have it trace into a circular
buffer in DRAM. Then you can preserve that via mem= reservations,
etc.
josh
^ permalink raw reply
* Re: Some embedded topics
From: Jordan Crouse @ 2008-05-30 23:20 UTC (permalink / raw)
To: Tim Bird
Cc: Geert Uytterhoeven, Rob Landley, T Ziomek, Mike Frysinger,
David VomLehn, linux-embedded
In-Reply-To: <484086B8.4030909@am.sony.com>
On 30/05/08 15:59 -0700, Tim Bird wrote:
> P.S. Is debug=mem something specific to Amiga? I find
> no mention of it in Documentation/kernel-parameters.txt
It would be interesting to standardize this interface and
extend it to dump logs from the firmware loader / monitor as well.
I know that coreboot for one has the ability to store logs and
communicate them to the kernel, and I think some of the more
popular embedded loaders support store logs too
(or if they don't, they should).
Jordan
--
Jordan Crouse
Systems Software Development Engineer
Advanced Micro Devices, Inc.
^ permalink raw reply
* Re: Some embedded topics
From: Tim Bird @ 2008-05-30 22:59 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Rob Landley, T Ziomek, Mike Frysinger, David VomLehn,
linux-embedded
In-Reply-To: <Pine.LNX.4.64.0805291130580.16206@vixen.sonytel.be>
Geert Uytterhoeven wrote:
> Yep, we've been doing this on Amiga for more than a decade, when `debug=mem' is
> passed. Cfr. arch/m68k/tools/amiga/dmesg.c.
>
Wow! If tidbits like these are going to keep surfacing,
I feel like maybe CELF should get someone to just
permanently monitor this list and take interesting
info like the above and put it on the elinux wiki.
There's a lot of interesting stuff flowing out of
people's brains onto the list in the last few
days.... It's great!
-- Tim
P.S. Is debug=mem something specific to Amiga? I find
no mention of it in Documentation/kernel-parameters.txt
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox