gmane.linux.kernel.embedded

Bids for open project proposals

Tim Bird — 2012-05-24T23:59:23

Everyone,

The CE Working Group has been collecting project proposals for 2012
contract work at:

http://elinux.org/Project_Proposals_for_2012

Most of this work is related to enhancing aspects of the Linux
kernel for use in embedded products.

The Architecture Group of the CEWG will be considering these
proposals at a meeting in Japan on June 5.  I realize that time
is very short, and I apologize for the late notice.  However,
if you are interested in bidding on any of these projects, please
send me an email with either a formal bid, or at a minimum, some
information about yourself.  This should include your hourly rate,
amount of available time, and experience with embedded Linux
development.  If you have any special qualifications - like having
worked on the particular subsystem in question - then please
list that as well.

Thanks and regards,
 -- Tim

=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================

[PATCH] kernel: Shrink embedded kernel, remove WARN strings when !CONFIG_PRINTK

Joe Perches — 2012-05-23T01:34:14

WARN strings are currently always saved in text.
When printk is not enabled, this wastes space.

Don't call or compile slowpath_warn_<foo> when !CONFIG_PRINTK.

This makes an embedded image without printk support ~1% smaller.

x86-32 allnoconfig/embedded:

$ size vmlinux.new vmlinux.old
   text   data    bss    dec    hexfilename
1180807 18272012693722632899 282cc3vmlinux.new
1198760 18272012679482649428 286d54vmlinux.old

Signed-off-by: Joe Perches <joe< at >perches.com>
---
 include/asm-generic/bug.h |   18 +++++++++++++++++-
 kernel/panic.c            |    3 +++
 2 files changed, 20 insertions(+), 1 deletions(-)

diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 2520a6e..a16101a 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
< at >< at > -59,7 +59,8 < at >< at > struct bug_entry {
  * appear at runtime.  Use the versions with printk format strings
  * to provide better diagnostics.
  */
-#ifndef __WARN_TAINT
+#if !defined(__WARN_TAINT)
+
 #ifndef __ASSEMBLY__
 extern __printf(3, 4)
 void warn_slowpath_fmt(const char *file, const int line,
< at >< at > -70,15 +71,30 < at >< at > void warn_slowpath_fmt_taint(const char *file, const int line, unsigned taint,
 extern void warn_slowpath_null(const char *file, const int line);
 #define WANT_WARN_ON_SLOWPATH
 #endif
+
+#ifdef CONFIG_PRINTK
 #define __WARN()warn_slowpath_null(__FILE__, __LINE__)
 #define __WARN_printf(arg...)warn_slowpath_fmt(__FILE__, __LINE__, arg)
 #define __WARN_printf_taint(taint, arg...)\
 warn_slowpath_fmt_taint(__FILE__, __LINE__, taint, arg)
 #else
+#define __WARN()do {} while (0)
+#define __WARN_printf(fmt, ...)\
+do {\
+if (0)\
+printk(fmt, ##__VA_ARGS__);\
+} while (0)
+#define __WARN_printf_taint(taint, fmt, ...)\
+__WARN_printf(fmt, ##__VA_ARGS__)
+#endif
+
+#else
+
 #define __WARN()__WARN_TAINT(TAINT_WARN)
 #define __WARN_printf(arg...)do { printk(arg); __WARN(); } while (0)
 #define __WARN_printf_taint(taint, arg...)\
 do { printk(arg); __WARN_TAINT(taint); } while (0)
+
 #endif
 
 #ifndef WARN_ON
diff --git a/kernel/panic.c b/kernel/panic.c
index 8ed89a1..bc57785 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
< at >< at > -396,6 +396,7 < at >< at > struct slowpath_args {
 va_list args;
 };
 
+#ifdef CONFIG_PRINTK
 static void warn_slowpath_common(const char *file, int line, void *caller,
  unsigned taint, struct slowpath_args *args)
 {
< at >< at > -449,6 +450,8 < at >< at > void warn_slowpath_null(const char *file, int line)
 EXPORT_SYMBOL(warn_slowpath_null);
 #endif
 
+#endif
+
 #ifdef CONFIG_CC_STACKPROTECTOR
 
 /*

Order Enquiry

Mcckoy Robertson — 2012-05-20T15:22:23

Hello Sales
     I went over your contact online and found some items which we have interest in purchasing to our store in Spain for urgent supply. I will like to know the prices per each items plus the shipping cost. I also want to know if Letter of Credit or T/T is acceptable for payment. I await your quick response asap so i can proceed with my needed items and quantity.

Thank you
mcckoy robertson


N.B.M Global Supply Inc
Address: Autovía A-5,
salidas 22 y 26.
Arroyomolinos,
28939 Madrid Spain
Tel: +34 902 26 77 26
Email: nbmglobalsupply< at >gmail.com
Website : http://www.brplastics.com

BUSINESS PROPOSAL!!

Wong Hui — 2012-05-16T12:47:18

Streaming Service

2012-05-15T19:35:19

Our Streaming Server is powerful and optimized server for live and on-demand audio/ video streaming content delivery. 
Our Streaming Server features with high performance streaming throughput, network & storage I/O and optimized configurations for its high scalability and reliability.
Our server supports latest Windows Media Technologies such as Fast Streaming, Fast Cache, Fast Start, Wireless Streaming as well as feature-rich add-on modules such as sophisticated content management, monitoring, logging reports, billing, authentications, load-balancing & clustering for all needs. 

Pls send us email for further information.Thanks,

Boris 
boris< at >dedicatedserver.com.hk

If you do not wish to further receive this event message, email "borislamsv2< at >gmail.com" to unsubscribe this message or remove your email from the list.

haalloo,

abi — 2012-05-12T16:57:35

haalloo,
how are you doing,i hope you are fine,my name is miss abi okom i got your
contact and want us to be a good friend,
please try and write back to me so that i will give you my pictures and tell
you more about me,

Re: Handling of modular boards

Igor Grinberg — 2012-05-10T12:40:56

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/05/12 01:09, Mark Brown wrote:

I agree on this (and also with Ben), all our boards/extensions/base boards/etc
can be discovered in the boot loader and we will use the DT to pass
the relevant information on the attached extensions and used base board.

Also, most (if not all) of our boards/extensions have I2C EEPROM which
describes the devices on that board/extension which is useful for
building/extending the DT in the bootloader.

- -- 
Regards,
Igor.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPq7dXAAoJEBDE8YO64Efag7sQAJ4Ipk/A24p6mO6ROtcd+q2s
gGlEjLHeZ7sNPnwCOCakCgX7+SYXKBv6w5aWKM70eLDUfoVLu9eaUeT4sYd2fGtR
4xFVkcYRenzkuO7MZ3GccAAF4Hg4WwMAn/3StIJU6pyBY7OmOsbqnoTa7PJjKr/J
HwwM8g8eo3q4tg2sB5P922Fol61BK2Wo3S7I9kzHtnwUx9yW3aG2mf/ublfXHUkQ
3RKfXrdREFJL30j9SrJzh6wVqQoE9Y7UrYs1BIiAs9AL/d2+eYgSPNKh/iBw+26f
V+Tr8t9xPyP1b1HGUjLVtGmwWtLncws2kfYnMcjvLKgES967SRbSboqRqwJL95yR
h9xKoVVrqC9lCXZn/uZCHmRaj/7DaPqr4/tbJefJTcU4ErS7bv/QxXARaj41SmS9
sq8A+qefiKaleBfinmiXjoCu8QcUKmfLF8oLt52tylb/4CUnipf4jLbnQ9fdPxGB
gQnrlg6T3WVTR7fzhOsXrgHQvocJa+3/YSYUyWbNvfjJBWFV6ZqERjTQCvhkXivG
bbwBn6tHAol+tRAUfGudlwzcaZZGbJ+vvK/GmSCI+tSfgz++O9uvd0spklatB4ab
NyikQLZBvSufnyWSY6Mp3iShhwgGZosxu9OGgQzclEh1tC8LQEbxOwETaRi/7uGq
PkkXsoPrmBc0C0dO+fIc
=icYW
-----END PGP SIGNATURE-----

Re: Handling of modular boards

Ben Dooks — 2012-05-10T10:41:36

I agree, the list of devices should be in the device-tree handed to
whatever OS is being booted. It isn't a Linux specific problem that
we're looking at here.

Any operating system, pre-OS test suite, etc. is going going to need
this information, and in my view the bootloader should be doing whatever
is needed to create a device-tree to passed through to the next loaded
system.

Also, having the information available to $bootloader means the user
can verify the presence of the peripherals before the OS is loaded.

Re: Handling of modular boards

Ben Dooks — 2012-05-10T10:43:11

Interesting, but how does it sort ofu things like mapping GPIO lines from
the add-in board's view to the rest of the system?

Re: Handling of modular boards

Linus Walleij — 2012-05-08T12:26:54


The same issue sort of comes up with any system that uses the idiom
to have a few GPIO lines indicate in a binary code what version of the
board we're dealing with and what devices are thus on it, right?

We have this issue for the U9540 reference design and potentially
on the Snowball as well.

Yours,
Linus Walleij

Re: Handling of modular boards

Russell King - ARM Linux — 2012-05-04T23:52:25

How about this - we have struct platform_device_info, which is used to
create platform devices.  We can use this as an array to describe what
platform devices to create in the sub-driver, including what the resources
should be etc.

However, there's a problem with this - what if you need to do some board
level init before hand?  That needs to be handled somehow before these
devices are instantiated.  That could be done via a callback through
platform data.

But... this all seems wrong, because rather than having a driver which
knows about the details of the board, we now have all the details of the
board in question back in platform code which originally declared the
board device.  That's wrong, because a daughter board may be shared
between different platforms, and we don't want multiple copies of that
data all around the place.

I don't think there's an easy or generic solution to this.

The best I can think of is ACPI, where they _do_ handle devices and
such like coming and going dynamically (I know this, it happens to my
serial and printer ports every time I dock and undock the laptop - and
stock Linux doesn't support that.  Which reminds me I need to get those
patches properly prepared and submitted...)  I'd assume that it also
deals with PCI bridges and buses behind that if you have one of those
docking stations too (I don't)...

Re: Handling of modular boards

Russell King - ARM Linux — 2012-05-04T22:55:14

I don't think its true to say that there's no support for this kind of
thing.

If you're thinking about a motherboard with separate add-on cards, then
you can view the cards as their own separate platform device.  Your
platform device driver would be a "whole board driver" responsible
for creating and registering the specific devices found on the board
in its probe function, and unregistering them in the remove function.

This is exactly how I've now setup the Assabet with Neponset daughter
board - all the Neponset devices sit behind the Neponset platform
device, including things like the SA1111 multifunction chip and SMC91x
network interface.  I can bind and unbind the Neponset device from its
driver and have everything behind that driver appear and disappear
appropriately - which is useful if your modules can be hotplugged.

It also helps to give the right model to the power management support,
because you're automatically arranging the child devices below the
board-level device, which means all the child devices should be
suspended before the board level device, and the board level device
should be resumed before the child devices.

Re: Handling of modular boards

Mark Brown — 2012-05-04T21:52:30





Yeah, similar setup for our boards except the PMICs are soldered down
onto other boards.  We've got a mainboard, three audio boards of various
kinds, a random non-audio components board and a CPU/DRAM board.

There's good solid engineering reasons for doing this.  CPUs and RAMs
tend to be very high density devices with lots of pins and be difficult
enough to route to require large numbers of layers (and ideally you want
the PMIC to be physically close to them since long traces tend to become
electrically interesting for CPU style loads, especially when routed
through connectors) all of which leads to an expensive board which you
pay for by area.  With reference boards with large form factors it's
worth the effort to have a separate, smaller, board manufactured to meet
these requirements - even in very low volumes the cost wins are
noticable.

Re: Handling of modular boards

Stephen Warren — 2012-05-04T21:09:19

A board I have sitting on my desk right now has separate boards for (and
multiple options for each of):

* Motherboard
* CPU+DRAM
* PMU/PMIC
* Display (LCD)
... and many more.

Interaction with the PMU/PMIC is required for at least some of the boot
media options.

Interaction with the display (LCD) while not technically required to
simply boot the kernel is required by desired use-cases, in order to
display a splash screen ASAP during early boot.

Oh, and the motherboard has a gazillion different HW mux options, which
affect, amongst many other things, which SD/eMMC/SDIO ports are usable
on the motherboard, and which are routed to various daughter boards. I'm
not actually 100% sure if the switches controlling those mux settings
are readable from SW. I certainly hope so...

Re: Handling of modular boards

Wolfgang Denk — 2012-05-04T20:38:57

Dear Stephen,

In message <4FA432E9.9050606< at >wwwdotorg.org> you wrote:

I expect that this will quickly cause problems, for example in those
many cases where pins and peripheral functions are multiplexed, or
usable for different purposes. I would not want to maintain a DT that
has to describe all combinations used by some boards - in a way that
does not cause conflicts on either of them.

Best regards,

Wolfgang Denk

Re: Handling of modular boards

Wolfgang Denk — 2012-05-04T20:33:57

Dear Arnd,

In message <201205041934.08830.arnd< at >arndb.de> you wrote:

On the other hand, some of the issues we're trying to solve here
for the kernel are also present in the boot loader, so this needs to
do this anyway - whether by inserting new or modifying (enabling or
disabling) existing properties in the DT is not really relevant here.


Best regards,

Wolfgang Denk

Re: Handling of modular boards

Mark Brown — 2012-05-04T20:07:00


I think anything that relies on bootloaders (or DT for that matter) is a
bit of a non-starter for my personal use cases.  Even where we're using
DT relying on a sane bootloader seems a bit scary - my personal use
cases would rely on updating this stuff in the field for non-technical
users who would have trouble recovering from issues.


I can see the theory, but I can also see some practical concerns.  And
with the boards I'm working with we currently have 8 bits of data so...

Re: Handling of modular boards

Arnd Bergmann — 2012-05-04T19:34:08

Hi Mark,

Thanks for getting the discussion started. I've seen the same issue come
up for arch/arm/mach-ux500/board-mop500*uib.c and for the beaglebone.
I'm sure there are many more, but we should make sure that everyone
of these can live with whatever we come up with.


One idea that I've heard before is to put device tree fragments into the
kernel and dynamically add them to the device tree that was passed by the
boot loader whenever we detect the presence of a specific device.
This obviously means it works only for boards using DT for booting, but
it allows us to use some infrastructure that we already have.

Another idea was to put all the possible extensions into the device tree
for a given board and disable them by default, putting it into the
responsibility of the boot loader to enable the one that is actually
being used. This has serious scalibility problems when there are many
possible extensions and also relies more on the boot loader than I would
like.

An intermediate solution that I really like is the ability to
stuff device tree fragments on extension board themselves, but that
can only work for new designs and causes problems when that information
is not actually correct.

Arnd

Server Rental Service in Hong Kong

2012-05-03T18:25:09

Dear All,

We have our own datacenter in Hong Kong & provide email/application/web rental service to clients.We are APNIC member & provide clean IP to clients.

Dell? PowerEdge? EnterpriseRack Mount Server
-Intel(R) Xeon(R) E3-1240 Processor (3.3GHz, 8M Cache, Turbo, 4C/8T, 80W)
-8GB RAM, 2x4GB, 1333MHz, DDR-3, Dual Ranked UDIMMs
-500GB, 3.5", 6Gbps SAS x 2
-Raid 1 Mirroring Protection
-Remote KVM (iDRAC6 Enterprise)

Dell(TM) PowerEdge(TM) R410 Rack Mount Server
-Intel(R) Quad Core E5606 Xeon(R) CPU, 2.13GHz, 4M Cache, 4.86 GT/s QPI
-4GB Memory (2x2GB), 1333MHz Dual Ranked RDIMMs Fully-Buffered
-500GB 7.2K RPM SATAII 3.5" Hard Drive x 2
-iDRAC6 Enterprise or Express (Remote KVM Management)

Every Dedicated Server Hosting Solution Also Includes: 
 
Software Specification 
- CentOS / Fedora / Debian / FreeBSD / Ubuntu / Redhat Linux 
- Full root-level access 
- Data Center Facilities 
- Shared Local & International Bandwidth 
- 2 IP Addresses Allocation 
- Un-interruptible Power Supply (UPS) backed up by private diesel generator 
- FM200¡§based fire suppression system 
- 24x7 CRAC Air Conditioning and Humidity Control 
- 24x7 Security Control 
- 24x7 Remote Hand Service 

Pls send us email for further information.Thanks,

Boris 
boris< at >dedicatedserver.com.hk

If you do not wish to further receive this event message, email "borislamsv2< at >gmail.com" to unsubscribe this message or remove your email from the list.

Advanced Cloud Hosting/Server

2012-04-25T13:15:10

Dear All,

Shoud you need Web, Email, EDM, Streaming, FTP.......server or hosting space?

We have providing better and lower cost service of Cloud Hosting (Cloud Server / Hosting / CDN)

Just USD$1.99 for experience, let's come to join us and enjoy our powerful and stable cloud system.

Please kindly visit our website as following link for more details. Thank you very much.

http://www.cloudluca.com/ 

Best Regards,
The 36cloud Team





If you do not wish to further receive this event message, email "subscriber< at >dedicatedserver.com.hk" to unsubscribe this message or revoe your email from the list.

Server Rental Service in HK

2012-04-22T00:42:50

Dear All,

We have our own datacenter in Hong Kong & provide email/application/web rental service to clients.We are APNIC member & provide clean IP to clients.

Dell? PowerEdge? EnterpriseRack Mount Server
-Intel(R) Xeon(R) E3-1240 Processor (3.3GHz, 8M Cache, Turbo, 4C/8T, 80W)
-8GB RAM, 2x4GB, 1333MHz, DDR-3, Dual Ranked UDIMMs
-500GB, 3.5", 6Gbps SAS x 2
-Raid 1 Mirroring Protection
-Remote KVM (iDRAC6 Enterprise)

Dell(TM) PowerEdge(TM) R410 Rack Mount Server
-Intel(R) Quad Core E5606 Xeon(R) CPU, 2.13GHz, 4M Cache, 4.86 GT/s QPI
-4GB Memory (2x2GB), 1333MHz Dual Ranked RDIMMs Fully-Buffered
-500GB 7.2K RPM SATAII 3.5" Hard Drive x 2
-iDRAC6 Enterprise or Express (Remote KVM Management)

Every Dedicated Server Hosting Solution Also Includes: 
 
Software Specification 
- CentOS / Fedora / Debian / FreeBSD / Ubuntu / Redhat Linux 
- Full root-level access 
- Data Center Facilities 
- Shared Local & International Bandwidth 
- 2 IP Addresses Allocation 
- Un-interruptible Power Supply (UPS) backed up by private diesel generator 
- FM200¡§based fire suppression system 
- 24x7 CRAC Air Conditioning and Humidity Control 
- 24x7 Security Control 
- 24x7 Remote Hand Service 

Pls send us email for further information.Thanks,

Boris 
boris< at >dedicatedserver.com.hk

If you do not wish to further receive this event message, email "borislamsv2< at >gmail.com" to unsubscribe this message or remove your email from the list.