* Re: how to increase memory limit reduced at boot-time by "mem"
From: Geert Uytterhoeven @ 2010-09-24 15:42 UTC (permalink / raw)
To: CEVAN Ondrej; +Cc: Linux Embedded Maillist
In-Reply-To: <9E0336F52EEC16458D081AA4C618AD8F5B6DE4@VIECLEX02.frequentis.frq>
On Fri, Sep 24, 2010 at 14:30, CEVAN Ondrej <Ondrej.CEVAN@frequentis.com> wrote:
> If the upper memory limit is reduced at booting by using the kernel command
> line parameter "mem" is there a way how this memory limit could be increased
> at some later point of kernel execution? In other words, if I exclude the
> upper part of system memory from kernel's use at boot time, can I reclaim it
> back at some later point?
>
> Particularly I am interested if this would work on the PowerPC and ARM
> architecture, or is it not architecture depending?
You can use memory hotplugging to add the memory later.
As this has been used on e.g. PS3, it should work on PowerPC.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* how to increase memory limit reduced at boot-time by "mem"
From: CEVAN Ondrej @ 2010-09-24 12:30 UTC (permalink / raw)
To: Linux Embedded Maillist
In-Reply-To: <4C96B77D.3040509@lougher.demon.co.uk>
Hi all!
If the upper memory limit is reduced at booting by using the kernel command
line parameter "mem" is there a way how this memory limit could be increased
at some later point of kernel execution? In other words, if I exclude the
upper part of system memory from kernel's use at boot time, can I reclaim it
back at some later point?
Particularly I am interested if this would work on the PowerPC and ARM
architecture, or is it not architecture depending?
Thanks a lot for your answer!
Ondrej
^ permalink raw reply
* Re: Linux Plumbers Embedded microconference
From: Grant Likely @ 2010-09-20 22:31 UTC (permalink / raw)
To: Kevin Hilman
Cc: Mark Brown, Jeremy Kerr, Tim Bird, Scott Wood, linux-embedded,
Liam Girdwood, Lo?c Minier, John Linn, Becky Bruce, Kumar Gala,
Paul Walmsley
In-Reply-To: <8739t41gn0.fsf@deeprootsystems.com>
On Mon, Sep 20, 2010 at 10:14:43AM -0700, Kevin Hilman wrote:
> Grant Likely <grant.likely@secretlab.ca> writes:
> > Here is my draft list:
> >
> > Kevin: How HWMOD is used to describe interconnections between internal
> > SoC devices.
>
> For omap_hwmod, I would like Paul Walmsley (Cc'd) to lead this
> discussion (or co-present) as he is the primary author and maintainer of
> this for linux-omap.
>
> Paul is planning to be at LPC already, so one or both of us will take
> care of it.
>
> Thanks for putting this together,
Excellent. We'll discuss details later (after I get back from
travelling this week and next).
g.
^ permalink raw reply
* Re: Linux Plumbers Embedded microconference
From: Tim Bird @ 2010-09-20 18:22 UTC (permalink / raw)
To: Grant Likely
Cc: Kevin Hilman, Mark Brown, Jeremy Kerr, Scott Wood, linux-embedded,
Liam Girdwood, Loïc Minier, John Linn, Becky Bruce,
Kumar Gala
In-Reply-To: <AANLkTinqm-EsovG8c1mfX2zuAgHt5OoRCcD+owBbndNc@mail.gmail.com>
On 09/17/2010 04:32 PM, Grant Likely wrote:
> 3) Common infrastructure beyond the kernel. Android has fastboot and
> other tools. Many folks use u-boot for development, but something
> custom (smaller) for deployment. Are there any other tools/techniques
> from Android/MeeGo/Linaro/WebOS/etc. that would be useful to a wider
> audience. Tim Bird has offered to lead this discussion.
..
> Tim, Jeremy and Kevin; I've accepted your micro-conference topics. As
> the conference gets closer I'll write up a draft of the actual agenda
> and your proposals can be massaged appropriately to reflect exactly
> what issues will be discussed.
>
> Thoughts?
Sounds good. I'm going to initiate discussion of this at the
embedded Linux summit coming up next week. That should help find
the possible areas of wider collaboration, that we can discuss
more at Plumbers.
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Network Entertainment
=============================
^ permalink raw reply
* Re: Linux Plumbers Embedded microconference
From: Kevin Hilman @ 2010-09-20 17:14 UTC (permalink / raw)
To: Grant Likely
Cc: Mark Brown, Jeremy Kerr, Tim Bird, Scott Wood, linux-embedded,
Liam Girdwood, Loïc Minier, John Linn, Becky Bruce,
Kumar Gala, Paul Walmsley
In-Reply-To: <AANLkTinqm-EsovG8c1mfX2zuAgHt5OoRCcD+owBbndNc@mail.gmail.com>
Grant Likely <grant.likely@secretlab.ca> writes:
> I'm now getting around to drafting the agenda for the embedded
> microconference. From looking at the proposals and some of the recent
> mailing list discussions, there are some topics that bubble up to the
> surface for me:
>
> 1) Device model usage - Support for runtime PM has been a hot topic,
> but the way the device model is populated and used on embedded
> platforms also has impact on correct initialization ordering, and how
> to instantiate 'system' devices composed of multiple discrete devices
> across the system. ie. connecting a codec and a DAI in ASoC.
>
> 2) Device Tree, HWMOD, static pdata, SFI, and other methods for
> teaching the kernel about the machine.
>
> 3) Common infrastructure beyond the kernel. Android has fastboot and
> other tools. Many folks use u-boot for development, but something
> custom (smaller) for deployment. Are there any other tools/techniques
> from Android/MeeGo/Linaro/WebOS/etc. that would be useful to a wider
> audience. Tim Bird has offered to lead this discussion.
>
> 4) Asymmetric multiprocessing (AMP) intercommunication. Cores are
> cheap, hardware is built with lots of them but how do they
> communicate? This is an issues for DSPs and for embedded
> virtualization. Syslink has been proposed. Freescale PowerPC has
> multicore chips that can be carved up for AMP. Patches have been
> circulated to repurpose virtio for interprocessor communication.
>
> ...
>
> 1 & 2 are somewhat interrelated as they are both aspects of embedded
> requirements on the device model. I'm not sure, but I may end up
> merging these two topics to a degree. My impression is that the same
> problems are being wrestled with in different problem domains. I'd
> like to schedule 3 or 4 people to give a brief (10-15min) overview of
> how they need devices registered, and how it fits in with the driver
> model, followed by discussion. Hopefully it will identify areas where
> common solution can/should be implemented. Or in other words; take
> our own blinders off for a bit and see how other people are solving
> the same problems. :-)
>
> Here is my draft list:
>
> Kevin: How HWMOD is used to describe interconnections between internal
> SoC devices.
For omap_hwmod, I would like Paul Walmsley (Cc'd) to lead this
discussion (or co-present) as he is the primary author and maintainer of
this for linux-omap.
Paul is planning to be at LPC already, so one or both of us will take
care of it.
Thanks for putting this together,
Kevin
^ permalink raw reply
* Re: Linux Plumbers Embedded microconference
From: Liam Girdwood @ 2010-09-20 8:19 UTC (permalink / raw)
To: Mark Brown
Cc: Grant Likely, Kevin Hilman, Jeremy Kerr, Tim Bird, Scott Wood,
linux-embedded, Loïc Minier, John Linn, Becky Bruce,
Kumar Gala
In-Reply-To: <20100918094743.GA22248@opensource.wolfsonmicro.com>
On Sat, 2010-09-18 at 10:47 +0100, Mark Brown wrote:
> On Fri, Sep 17, 2010 at 05:32:42PM -0600, Grant Likely wrote:
>
> > Mark or Liam: ASoC - How what needs to be done to collect disparate
> > devices (codecs, audio controllers, etc) into a single SoC device.
>
> > Mark and Liam, I know you haven't made a proposal to do this, but if
> > you'd be willing I think it would be valuable.
>
> I'd certainly be happy to do this, and I imagine Liam would too (he's on
> vacation at the minute so it might take him a while to respond).
Yep, that sounds good to me.
Thanks
Liam
--
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk
^ permalink raw reply
* [ANN] Squashfs tools 4.1 released
From: Phillip Lougher @ 2010-09-20 1:23 UTC (permalink / raw)
To: Linux Embedded Maillist
Hi,
I'm pleased to announce the release of Squashfs tools 4.1. This release
adds support for extended attributes (XATTRs), and LZMA and LZO compression.
There's also new pseudo file features and the usual bug fixes.
The release can be downloaded from http://sourceforge.net/projects/squashfs.
Compatibility
------------
Mksquashfs 4.1 generates 4.0 filesystems. These filesystems are fully
compatible/interchangable with filesystems generated by Mksquashfs 4.0 and are
mountable on 2.6.29 and later kernels.
Extended attributes (xattrs)
----------------------------
Squashfs file systems now have extended attribute support. The
extended attribute implementation has the following features:
1. Layout can store up to 248 bytes of compressed xattr data.
2. Number of xattrs per inode unlimited.
3. Total size of xattr data per inode 248 bytes of compressed data.
4. Up to 4 Gbytes of data per xattr value.
5. Inline and out-of-line xattr values supported for higher performance
in xattr scanning (listxattr & getxattr), and to allow xattr value
de-duplication.
6. Both whole inode xattr duplicate detection and individual xattr value
duplicate detection supported. These can obviously nest, file C's
xattrs can be a complete duplicate of file B, and file B's xattrs
can be a partial duplicate of file A.
7. Xattr name prefix types stored, allowing the redundant "user.", "trusted."
etc. characters to be eliminated and more concisely stored.
8. Support for files, directories, symbolic links, device nodes, fifos
and sockets.
Extended attribute support is in 2.6.35 and later kernels. File systems
with extended attributes can be mounted on 2.6.29 and later kernels, the
extended attributes will be ignored with a warning.
LZMA and LZO compression
------------------------
Squashfs now supports LZMA and LZO compression.
LZO support is in 2.6.36 and newer kernels. LZMA is not yet in mainline.
New pseudo file support
-----------------------
Mksquashfs supports pseudo files, these allow fake files, directories, character
and block devices to be specified and added to the Squashfs filesystem being
built, rather than requiring them to be present in the source directories.
This, for example, allows device nodes to be added to the filesystem without
requiring root access.
Mksquashfs 4.1 adds support for "dynamic pseudo files" and a modify operation.
Dynamic pseudo files allow files to be dynamically created when Mksquashfs
is run, their contents being the result of running a command or piece of
shell script. The modifiy operation allows the mode/uid/gid of an existing
file in the source filesystem to be modified.
Phillip
^ permalink raw reply
* Re: Linux Plumbers Embedded microconference
From: Mark Brown @ 2010-09-18 9:47 UTC (permalink / raw)
To: Grant Likely
Cc: Kevin Hilman, Jeremy Kerr, Tim Bird, Scott Wood, linux-embedded,
Liam Girdwood, Loïc Minier, John Linn, Becky Bruce,
Kumar Gala
In-Reply-To: <AANLkTinqm-EsovG8c1mfX2zuAgHt5OoRCcD+owBbndNc@mail.gmail.com>
On Fri, Sep 17, 2010 at 05:32:42PM -0600, Grant Likely wrote:
> Mark or Liam: ASoC - How what needs to be done to collect disparate
> devices (codecs, audio controllers, etc) into a single SoC device.
> Mark and Liam, I know you haven't made a proposal to do this, but if
> you'd be willing I think it would be valuable.
I'd certainly be happy to do this, and I imagine Liam would too (he's on
vacation at the minute so it might take him a while to respond).
^ permalink raw reply
* Linux Plumbers Embedded microconference
From: Grant Likely @ 2010-09-17 23:32 UTC (permalink / raw)
To: Kevin Hilman, Mark Brown, Jeremy Kerr, Tim Bird,
Scott Wood <sc>
I'm now getting around to drafting the agenda for the embedded
microconference. From looking at the proposals and some of the recent
mailing list discussions, there are some topics that bubble up to the
surface for me:
1) Device model usage - Support for runtime PM has been a hot topic,
but the way the device model is populated and used on embedded
platforms also has impact on correct initialization ordering, and how
to instantiate 'system' devices composed of multiple discrete devices
across the system. ie. connecting a codec and a DAI in ASoC.
2) Device Tree, HWMOD, static pdata, SFI, and other methods for
teaching the kernel about the machine.
3) Common infrastructure beyond the kernel. Android has fastboot and
other tools. Many folks use u-boot for development, but something
custom (smaller) for deployment. Are there any other tools/techniques
from Android/MeeGo/Linaro/WebOS/etc. that would be useful to a wider
audience. Tim Bird has offered to lead this discussion.
4) Asymmetric multiprocessing (AMP) intercommunication. Cores are
cheap, hardware is built with lots of them but how do they
communicate? This is an issues for DSPs and for embedded
virtualization. Syslink has been proposed. Freescale PowerPC has
multicore chips that can be carved up for AMP. Patches have been
circulated to repurpose virtio for interprocessor communication.
...
1 & 2 are somewhat interrelated as they are both aspects of embedded
requirements on the device model. I'm not sure, but I may end up
merging these two topics to a degree. My impression is that the same
problems are being wrestled with in different problem domains. I'd
like to schedule 3 or 4 people to give a brief (10-15min) overview of
how they need devices registered, and how it fits in with the driver
model, followed by discussion. Hopefully it will identify areas where
common solution can/should be implemented. Or in other words; take
our own blinders off for a bit and see how other people are solving
the same problems. :-)
Here is my draft list:
Kevin: How HWMOD is used to describe interconnections between internal
SoC devices.
Mark or Liam: ASoC - How what needs to be done to collect disparate
devices (codecs, audio controllers, etc) into a single SoC device.
Jeremy: Populating the device model with device tree external data (why and how)
(I'm also open to other suggestions)
Mark and Liam, I know you haven't made a proposal to do this, but if
you'd be willing I think it would be valuable.
...
The AMP IPC topic is interesting to me, but I'd like to get some
feedback before I commit to it. I would schedule it the same way that
the device model discussion is organized; 3-4 overviews 10-15 minutes
each followed by discussion. Right now I've got a proposal from the
TI folks to talk about Syslink. Freescalers, what say you? Could I
convince one of you to talk about AMP IPC on your powerpc multicore
SoCs? Multicore on Xilinx FPGAs would also be interesting, but I'm
not up to date on if anybody is actively working on that. Are there
any other AMP IPC mechanisms that should be discussed?
...
Tim, Jeremy and Kevin; I've accepted your micro-conference topics. As
the conference gets closer I'll write up a draft of the actual agenda
and your proposals can be massaged appropriately to reflect exactly
what issues will be discussed.
Thoughts?
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: ARM target not boot after remap memory
From: Robin Theunis @ 2010-09-14 5:32 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linux-kernel, linux-embedded
In-Reply-To: <20100913214132.0438615242D@gemini.denx.de>
Dear Wolfgang,
I messed up the buildroot and u-boot version!
u-boot = 2010.06
and
buildroot = 2010.08
Sorry all, my fault.
Best regards,
Robin Theunis
2010/9/13 Wolfgang Denk <wd@denx.de>:
> Dear Robin Theunis,
>
> In message <AANLkTi=tWwaFHB0DY=j0UaqbYdYJpGJpmWdGC4aMufSw@mail.gmail.com> you wrote:
>>
>> The U-boot version is 2010.08. I have build the whole system on a
>
> There is no such version of U-Boot.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
> What is tolerance? -- it is the consequence of humanity. We are all
> formed of frailty and error; let us pardon reciprocally each other's
> folly -- that is the first law of nature. - Voltaire
>
^ permalink raw reply
* Re: ARM target not boot after remap memory
From: Wolfgang Denk @ 2010-09-13 21:41 UTC (permalink / raw)
To: Robin Theunis; +Cc: Linux Kernel Mailing List, linux-embedded
In-Reply-To: <AANLkTi=tWwaFHB0DY=j0UaqbYdYJpGJpmWdGC4aMufSw@mail.gmail.com>
Dear Robin Theunis,
In message <AANLkTi=tWwaFHB0DY=j0UaqbYdYJpGJpmWdGC4aMufSw@mail.gmail.com> you wrote:
>
> The U-boot version is 2010.08. I have build the whole system on a
There is no such version of U-Boot.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
What is tolerance? -- it is the consequence of humanity. We are all
formed of frailty and error; let us pardon reciprocally each other's
folly -- that is the first law of nature. - Voltaire
^ permalink raw reply
* Re: ARM target not boot after remap memory
From: Robin Theunis @ 2010-09-13 19:12 UTC (permalink / raw)
To: Johannes Stezenbach; +Cc: linux-kernel, linux-embedded
In-Reply-To: <AANLkTinzchkOZ67+wVXejLb+UqLRCu+zrzVB4j5zG2_w@mail.gmail.com>
Solved that problem. Typo in my mach types.
Now the next problem:
<5>Linux version 2.6.34.1robin9200v1.0 (robin@pc-robin) (gcc version
4.3.5 (Buildroot 2010.08) ) #37 Mon Sep 13 20:57:43 CEST 2010
<4>CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c0007177
<4>CPU: VIVT data cache, VIVT instruction cache
<4>Machine: Robin9200
<6>bootconsole [earlycon0] enabled
<4>Memory policy: ECC disabled, Data cache writeback
<7>On node 0 totalpages: 16384
<7>free_area_init_node: node 0, pgdat c037f45c, node_mem_map c0394000
<7> Normal zone: 128 pages used for memmap
<7> Normal zone: 0 pages reserved
<7> Normal zone: 16256 pages, LIFO batch:3
<4>Clocks: CPU 179 MHz, master 59 MHz, main 18.432 MHz
<4>Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256
<1>Unable to handle kernel paging request at virtual address fefc4014
<1>pgd = c0004000
<1>[fefc4014] *pgd=20417051, *pte=00000000, *ppte=00000000
<0>Internal error: Oops: 27 [#1]
<0>last sysfs file:
<4>Modules linked in:
<4>CPU: 0 Not tainted (2.6.34.1robin9200v1.0 #37)
<4>PC is at printascii+0x14/0x50
<4>LR is at early_write+0x28/0x5c
<4>pc : [<c0026180>] lr : [<c0026218>] psr: 200000d3
<4>sp : c0361e88 ip : c0361ea4 fp : c0361ea0
<4>r10: fffffd3e r9 : c0366084 r8 : c0366084
<4>r7 : c0366080 r6 : 0000004b r5 : c03806b7 r4 : 00000001
<4>r3 : fefc4000 r2 : 0000004b r1 : 00000042 r0 : 00000000
<4>Flags: nzCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel
<4>Control: c000717f Table: 20004000 DAC: 00000017
<0>Process swapper (pid: 0, stack limit = 0xc03
What does it mean?
Robin
2010/9/13 Robin Theunis <robint91@gmail.com>:
> The __log_buf
>
> <5>Linux version 2.6.34.1robin9200v1.0 (robin@pc-robin) (gcc version
> 4.3.5 (Buildroot 2010.08) ) #36 Mon Sep 13 15:18:08 CEST 2010
> <4>CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c0007177
> <4>CPU: VIVT data cache, VIVT instruction cache
> <4>Machine configuration botched (nr 251), unable to continue.
>
> I don't understand it. What does it means? I have my mach types setup correctly.
>
> Robin
>
> 2010/9/13 Johannes Stezenbach <js@sig21.net>:
>> On Mon, Sep 13, 2010 at 04:30:17PM +0200, Robin Theunis wrote:
>>>
>>> I have compiled the kernel with early printk on and debug_LL, It still
>>> doesn't nothing after that line.
>>
>> Please don't top-post.
>>
>> Did you add "earlyprintk" to your kernel command line
>> like the EARLY_PRINTK menuconfig help text suggests?
>>
>> arch/arm/mach-at91/include/mach/debug-macro.S also suggests
>> the LL debug output goes to AT91 debug unit not to normal UART
>> (not sure about this, I don't know much about AT91).
>> Did you try to dump __log_buf using JTAG?
>>
>>
>> HTH
>> Johannes
>>
>
^ permalink raw reply
* Re: ARM target not boot after remap memory
From: Robin Theunis @ 2010-09-13 18:28 UTC (permalink / raw)
To: Johannes Stezenbach; +Cc: linux-kernel, linux-embedded
In-Reply-To: <20100913172606.GA14462@sig21.net>
The __log_buf
<5>Linux version 2.6.34.1robin9200v1.0 (robin@pc-robin) (gcc version
4.3.5 (Buildroot 2010.08) ) #36 Mon Sep 13 15:18:08 CEST 2010
<4>CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c0007177
<4>CPU: VIVT data cache, VIVT instruction cache
<4>Machine configuration botched (nr 251), unable to continue.
I don't understand it. What does it means? I have my mach types setup correctly.
Robin
2010/9/13 Johannes Stezenbach <js@sig21.net>:
> On Mon, Sep 13, 2010 at 04:30:17PM +0200, Robin Theunis wrote:
>>
>> I have compiled the kernel with early printk on and debug_LL, It still
>> doesn't nothing after that line.
>
> Please don't top-post.
>
> Did you add "earlyprintk" to your kernel command line
> like the EARLY_PRINTK menuconfig help text suggests?
>
> arch/arm/mach-at91/include/mach/debug-macro.S also suggests
> the LL debug output goes to AT91 debug unit not to normal UART
> (not sure about this, I don't know much about AT91).
> Did you try to dump __log_buf using JTAG?
>
>
> HTH
> Johannes
>
^ permalink raw reply
* Re: ARM target not boot after remap memory
From: Johannes Stezenbach @ 2010-09-13 17:26 UTC (permalink / raw)
To: Robin Theunis; +Cc: linux-kernel, linux-embedded
In-Reply-To: <AANLkTiksacwuOwqJGZ0F3M1jhZ6Srr88wbfBQodOGOAt@mail.gmail.com>
On Mon, Sep 13, 2010 at 04:30:17PM +0200, Robin Theunis wrote:
>
> I have compiled the kernel with early printk on and debug_LL, It still
> doesn't nothing after that line.
Please don't top-post.
Did you add "earlyprintk" to your kernel command line
like the EARLY_PRINTK menuconfig help text suggests?
arch/arm/mach-at91/include/mach/debug-macro.S also suggests
the LL debug output goes to AT91 debug unit not to normal UART
(not sure about this, I don't know much about AT91).
Did you try to dump __log_buf using JTAG?
HTH
Johannes
^ permalink raw reply
* Fwd: ARM target not boot after remap memory
From: Robin Theunis @ 2010-09-13 14:31 UTC (permalink / raw)
To: linux-kernel, linux-embedded
In-Reply-To: <AANLkTiksacwuOwqJGZ0F3M1jhZ6Srr88wbfBQodOGOAt@mail.gmail.com>
hi Johannes
I have compiled the kernel with early printk on and debug_LL, It
still doesn't nothing after that line.
Robin
2010/9/13 Johannes Stezenbach <js@sig21.net>:
> On Mon, Sep 13, 2010 at 01:25:26PM +0200, Robin Theunis wrote:
>>
>> Uncompressing Linux... done, booting the kernel.
>> ---
>>
>> Here is stalls. With my jtag probe I can locate the problem.
>>
>> ---
>> > halt
>> target state: halted
>> target halted in ARM state due to debug-request, current mode: Supervisor
>> cpsr: 0x600000d3 pc: 0xc000af3c
>> MMU: enabled, D-Cache: enabled, I-Cache: enabled
>> > arm disassemble 0xc000af3c
>> 0xc000af3c 0xeafffffe B 0xc000af3c
>> ---
>>
>> This just loops at that address. Why does it that?
>
> Maybe it panicked but you can't see the message since
> you have not enabled EARLY_PRINTK.
>
> Since you have JTAG, you could also dump the printk
> buffer __log_buf to see the message.
>
>
> HTH
> Johannes
>
^ permalink raw reply
* Re: ARM target not boot after remap memory
From: Robin Theunis @ 2010-09-13 13:11 UTC (permalink / raw)
To: Russell King - ARM Linux; +Cc: linux-kernel, linux-embedded
In-Reply-To: <20100913125140.GH30787@n2100.arm.linux.org.uk>
I have tested it.
When I compiled the kernel with debug_LL on the and triggered such an
error by changing r1 to
something different. And then I got an error of unsupport machine.
2010/9/13 Russell King - ARM Linux <linux@arm.linux.org.uk>
> On Mon, Sep 13, 2010 at 02:48:18PM +0200, Robin Theunis wrote:
>> Hi Russell,
>>
>> Yes I have tested it. I made a breakpoint at 0x2008000 and viewed that
>> the r1 register and there in I found the correct ID.
>
> Ensure that CONFIG_DEBUG_LL is enabled, and that it outputs to the correct
> UART. The kernel will produce some messages via the DEBUG_LL stuff prior
> to entering the __error loop.
>
^ permalink raw reply
* Generic PWM kernel driver (with support for OMAP3)
From: Kridner, Jason @ 2010-09-13 13:06 UTC (permalink / raw)
To: Bill Gatliff, Varun Jewalikar, soren, scott@jumpnowtek.com
Cc: beagleboard@googlegroups.com, linux-omap@vger.kernel.org,
linux-embedded@vger.kernel.org
Bill,
I was looking at your PWM patch set[1] and it seems this has been pending for a long time (since February). Do you know if this is any closer to being accepted, ie. have you done any additional work or has it been accepted to some maintainer's tree?
There was a Google Summer of Code project for BeagleBoard.org[2] to put PWM code into the kernel[3], but the student (Varun, copied) has not yet submitted his patches to the linux-embedded mailing list yet and he wasn't aware of your patch set when he began his work. His patch set[4] also misses some of the features from your patch set. The student's work seems to be based on Scott's work[5] and branched from his tree on github[6].
Have you released an updated patch series to address the feedback comments or shall we introduce a new set?
Regards,
Jason Kridner
http://beagleboard.org/twitter
[1] https://patchwork.kernel.org/patch/76229/
[2] http://beagleboard.org/gsoc
[3] http://elinux.org/BeagleBoard/GSoC/2010_Projects/Pulse_Width_Modulation
[4] http://github.com/neo01124/omap3-pwm
[5] http://www.jumpnowtek.com/index.php?option=com_content&view=article&id=56&Itemid=63
[6] http://github.com/scottellis/omap3-pwm
^ permalink raw reply
* Re: ARM target not boot after remap memory
From: Russell King - ARM Linux @ 2010-09-13 12:53 UTC (permalink / raw)
To: Robin Theunis; +Cc: linux-kernel, linux-arm-kernel, linux-embedded mailing list
In-Reply-To: <AANLkTi=dT1uMrRctB4=Hvh35zVc-DtReWmHj-18cd9XT@mail.gmail.com>
BTW, Please do not drop CCs.
On Mon, Sep 13, 2010 at 02:48:18PM +0200, Robin Theunis wrote:
> Hi Russell,
>
> Yes I have tested it. I made a breakpoint at 0x2008000 and viewed that
> the r1 register and there in I found the correct ID.
>
> Robin
>
> 2010/9/13 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> > On Mon, Sep 13, 2010 at 02:07:51PM +0200, Mike Rapoport wrote:
> >> (add LAKLM to CC)
> >
> >>> The problem is now when linux kernel is booting, nothing happens.
> >>>
> >>> ---
> >>> U-Boot> bootm
> >>> ## Booting kernel from Legacy Image at 21000000 ...
> >>> Image Name: Linux-2.6.34.1robin9200v1.0
> >>> Image Type: ARM Linux Kernel Image (uncompressed)
> >>> Data Size: 1811796 Bytes = 1.7 MiB
> >>> Load Address: 20008000
> >>> Entry Point: 20008000
> >>> Verifying Checksum ... OK
> >>> Loading Kernel Image ... OK
> >>> OK
> >>>
> >>> Starting kernel ...
> >>>
> >>> Uncompressing Linux... done, booting the kernel.
> >>> ---
> >>>
> >>> Here is stalls. With my jtag probe I can locate the problem.
> >>>
> >>> ---
> >>>> halt
> >>> target state: halted
> >>> target halted in ARM state due to debug-request, current mode: Supervisor
> >>> cpsr: 0x600000d3 pc: 0xc000af3c
> >>> MMU: enabled, D-Cache: enabled, I-Cache: enabled
> >>>> arm disassemble 0xc000af3c
> >>> 0xc000af3c 0xeafffffe B 0xc000af3c
> >
> > Probably __error. Either your machine isn't supported, or the kernel
> > doesn't recognise your processor.
> >
> > Is your version of uboot sufficiently recent that it passes the correct
> > machine ID in r1 ?
> >
^ permalink raw reply
* Re: ARM target not boot after remap memory
From: Russell King - ARM Linux @ 2010-09-13 12:40 UTC (permalink / raw)
To: Mike Rapoport
Cc: Robin Theunis, LAKML, Linux Kernel Mailing List,
linux-embedded mailing list
In-Reply-To: <4C8E1417.4060204@compulab.co.il>
On Mon, Sep 13, 2010 at 02:07:51PM +0200, Mike Rapoport wrote:
> (add LAKLM to CC)
>> The problem is now when linux kernel is booting, nothing happens.
>>
>> ---
>> U-Boot> bootm
>> ## Booting kernel from Legacy Image at 21000000 ...
>> Image Name: Linux-2.6.34.1robin9200v1.0
>> Image Type: ARM Linux Kernel Image (uncompressed)
>> Data Size: 1811796 Bytes = 1.7 MiB
>> Load Address: 20008000
>> Entry Point: 20008000
>> Verifying Checksum ... OK
>> Loading Kernel Image ... OK
>> OK
>>
>> Starting kernel ...
>>
>> Uncompressing Linux... done, booting the kernel.
>> ---
>>
>> Here is stalls. With my jtag probe I can locate the problem.
>>
>> ---
>>> halt
>> target state: halted
>> target halted in ARM state due to debug-request, current mode: Supervisor
>> cpsr: 0x600000d3 pc: 0xc000af3c
>> MMU: enabled, D-Cache: enabled, I-Cache: enabled
>>> arm disassemble 0xc000af3c
>> 0xc000af3c 0xeafffffe B 0xc000af3c
Probably __error. Either your machine isn't supported, or the kernel
doesn't recognise your processor.
Is your version of uboot sufficiently recent that it passes the correct
machine ID in r1 ?
^ permalink raw reply
* Re: ARM target not boot after remap memory
From: Johannes Stezenbach @ 2010-09-13 12:12 UTC (permalink / raw)
To: Robin Theunis; +Cc: Linux Kernel Mailing List, linux-embedded
In-Reply-To: <AANLkTi=tWwaFHB0DY=j0UaqbYdYJpGJpmWdGC4aMufSw@mail.gmail.com>
On Mon, Sep 13, 2010 at 01:25:26PM +0200, Robin Theunis wrote:
>
> Uncompressing Linux... done, booting the kernel.
> ---
>
> Here is stalls. With my jtag probe I can locate the problem.
>
> ---
> > halt
> target state: halted
> target halted in ARM state due to debug-request, current mode: Supervisor
> cpsr: 0x600000d3 pc: 0xc000af3c
> MMU: enabled, D-Cache: enabled, I-Cache: enabled
> > arm disassemble 0xc000af3c
> 0xc000af3c 0xeafffffe B 0xc000af3c
> ---
>
> This just loops at that address. Why does it that?
Maybe it panicked but you can't see the message since
you have not enabled EARLY_PRINTK.
Since you have JTAG, you could also dump the printk
buffer __log_buf to see the message.
HTH
Johannes
^ permalink raw reply
* Re: ARM target not boot after remap memory
From: Mike Rapoport @ 2010-09-13 12:07 UTC (permalink / raw)
To: Robin Theunis
Cc: Linux Kernel Mailing List, linux-embedded mailing list, LAKML
In-Reply-To: <AANLkTi=tWwaFHB0DY=j0UaqbYdYJpGJpmWdGC4aMufSw@mail.gmail.com>
(add LAKLM to CC)
Robin Theunis wrote:
> Dear (Embedded)-Kernel-Devs,
>
> I'm trying to build linux 2.6.34.1 for a AT91RM9200 target. The whole
> build process is successful because I get correct kernel images and
> also a uImage for U-boot.
> The U-boot version is 2010.08. I have build the whole system on a
> 64bit ubuntu machine. I use the latest buildroot to make the toolchain
> and etc. At this moment I have a
> openocd jtag dongle connected to my target for debug sessions.
> I have check that the machine id/type are correct. I have gotten those
> error messages of a unsupported target. I have resolved those errors.
> The target is self is a AT91RM9200 with 64MiB ram and 16MiB cfi flash.
> The boot args of u-boot are "console=ttyS0,115200n8
> root=/dev/mtdblock0 rootfstype=jffs2 mem=64M".
>
> The problem is now when linux kernel is booting, nothing happens.
>
> ---
> U-Boot> bootm
> ## Booting kernel from Legacy Image at 21000000 ...
> Image Name: Linux-2.6.34.1robin9200v1.0
> Image Type: ARM Linux Kernel Image (uncompressed)
> Data Size: 1811796 Bytes = 1.7 MiB
> Load Address: 20008000
> Entry Point: 20008000
> Verifying Checksum ... OK
> Loading Kernel Image ... OK
> OK
>
> Starting kernel ...
>
> Uncompressing Linux... done, booting the kernel.
> ---
>
> Here is stalls. With my jtag probe I can locate the problem.
>
> ---
>> halt
> target state: halted
> target halted in ARM state due to debug-request, current mode: Supervisor
> cpsr: 0x600000d3 pc: 0xc000af3c
> MMU: enabled, D-Cache: enabled, I-Cache: enabled
>> arm disassemble 0xc000af3c
> 0xc000af3c 0xeafffffe B 0xc000af3c
> ---
>
> This just loops at that address. Why does it that?
> You see that the mmu is enabled and the cpu has remapped the memory.
> Does someone have a clue what goes wrong?
>
> Here is the .config and board file.
> http://www.on8rth.be/wp-content/uploads/2010/09/dotconfig.txt
> http://www.on8rth.be/wp-content/uploads/2010/09/board-robin9200.c
>
> Thank you
>
> Robin Theunis
> ON8RTH
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Sincerely yours,
Mike.
^ permalink raw reply
* ARM target not boot after remap memory
From: Robin Theunis @ 2010-09-13 11:25 UTC (permalink / raw)
To: Linux Kernel Mailing List, linux-embedded
Dear (Embedded)-Kernel-Devs,
I'm trying to build linux 2.6.34.1 for a AT91RM9200 target. The whole
build process is successful because I get correct kernel images and
also a uImage for U-boot.
The U-boot version is 2010.08. I have build the whole system on a
64bit ubuntu machine. I use the latest buildroot to make the toolchain
and etc. At this moment I have a
openocd jtag dongle connected to my target for debug sessions.
I have check that the machine id/type are correct. I have gotten those
error messages of a unsupported target. I have resolved those errors.
The target is self is a AT91RM9200 with 64MiB ram and 16MiB cfi flash.
The boot args of u-boot are "console=ttyS0,115200n8
root=/dev/mtdblock0 rootfstype=jffs2 mem=64M".
The problem is now when linux kernel is booting, nothing happens.
---
U-Boot> bootm
## Booting kernel from Legacy Image at 21000000 ...
Image Name: Linux-2.6.34.1robin9200v1.0
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1811796 Bytes = 1.7 MiB
Load Address: 20008000
Entry Point: 20008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
---
Here is stalls. With my jtag probe I can locate the problem.
---
> halt
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x600000d3 pc: 0xc000af3c
MMU: enabled, D-Cache: enabled, I-Cache: enabled
> arm disassemble 0xc000af3c
0xc000af3c 0xeafffffe B 0xc000af3c
---
This just loops at that address. Why does it that?
You see that the mmu is enabled and the cpu has remapped the memory.
Does someone have a clue what goes wrong?
Here is the .config and board file.
http://www.on8rth.be/wp-content/uploads/2010/09/dotconfig.txt
http://www.on8rth.be/wp-content/uploads/2010/09/board-robin9200.c
Thank you
Robin Theunis
ON8RTH
^ permalink raw reply
* LCTES 2011: Submission site is now open!
From: Tomas Kalibera @ 2010-09-08 16:30 UTC (permalink / raw)
To: linux-embedded
Submission deadline: 8 October 2010
Extended scope includes implementation and design of embedded systems
Submission site now open: https://www.softconf.com/b/lctes2011/
*********************************************************
LCTES 2011 - FIRST CALL FOR PAPERS
ACM SIGPLAN/SIGBED Conference on
Languages, Compilers, Tools,
and Theory for Embedded Systems
(In conjunction with CPS Week 2011)
Chicago, Illinois, USA, April 12-14 2011
http://lctes2011.elis.ugent.be
*********************************************************
Embedded system design faces many challenges both with respect to
functional requirements and non-functional requirements, many of which
are conflicting. They are found in areas such as design and developer
productivity, verification, validation, maintainability, and meeting
performance goals and resource constraints. Novel design-time and
run-time approaches are needed to meet the demand of emerging
applications and to exploit new hardware paradigms, and in particular to
scale up to multicores and distributed systems built from
multicores. LCTES 2011 solicits papers presenting original work on
programming languages, compilers, tools, theory and architectures that
help in overcoming these challenges. Research papers on innovative
techniques are welcome, as well as experience papers on insights
obtained by experimenting with real-world systems and applications.
Papers are solicited on, but not limited to, the following topics in
embedded and cyber-physical systems:
* Programming language challenges, including:
Domain-specific languages
Features to exploit multicore, reconfigurable, and other emerging
architectures
Features for distributed, adaptive, and real-time control embedded
systems
Language capabilities for specification, composition, and
construction of embedded systems
Language features and techniques to enhance reliability,
verifiability, and security
Virtual machines, concurrency, inter-processor synchronization, and
memory management
* Compiler challenges, including:
Interaction between embedded/cyber-physical architectures,
operating systems, and compilers
Interpreters, binary translation, just-in-time compilation, and
split compilation
Support for enhanced programmer productivity
Support for enhanced debugging, profiling, and exception/interrupt
handling
Optimization for low power/energy, code and data size, and
best-effort and real-time performance
Parametrized and structural compiler design space exploration and
autotuning
* Tools for analysis, specification, design, and implementation, including:
Hardware, system software, and application software, and their
interfaces
Distributed real-time control, media players, and reconfigurable
architectures
System integration and testing
Performance estimation, monitoring, and tuning
Run-time system support for embedded and cyber-physical systems
Design space exploration tools
Support for system security and system-level reliability
Approaches for cross-layer system optimization
* Theory and foundations of embedded and cyber-physical systems, including:
Predictability of resource behavior: energy, space, time
Validation and verification, in particular of concurrent and
distributed systems
Formal foundations of model-based design as basis for code
generation, analysis, and verification
Mathematical foundations for embedded systems
Models of computations for embedded applications
* Novel embedded and cyber-physical architectures, including:
Design and implementation of novel architectures
Workload analysis and performance evaluation
Architecture support for new language features, virtualization,
compiler techniques, and debugging tools
Submission deadline: 8 October 2010. Page limit, format, blind review
and other Submission guidelines: see http://lctes2011.elis.ugent.be
The conference proceedings will be published by the ACM. The authors of
the best papers of the conference will be invited to submit an extended
version to a special issue on LCTES of ACM Transactions in Embedded
Computing Systems. The best paper and the best presentation will receive
an award.
*********************************************************
PROGRAM COMMITTEE
Abdoulaye Gamatié (CNRS, France)
Alastair Reid (ARM Ltd, United Kingdom)
Albert Cohen (INRIA, France)
Ann Gordon-Ross (University of Florida, USA)
Annie Liu (State University of New York at Stony Brook, USA)
Antony Hosking (Purdue University, USA)
Aviral Shrivastava (Arizona State University, USA)
Daniel Kästner (Absint, Germany)
David F. Bacon (IBM T.J. Watson Research Center, USA)
Florence Maraninchi (VERIMAG, France)
Frank Mueller (North Carolina State University, USA)
Jack Davidson (University of Virginia, USA)
Jaejin Lee (Seoul National University, Korea)
Jan Reineke (UC Berkeley, USA)
John Regher (University of Utah, USA)
Laura Pozzi (University of Lugano, Switzerland)
Peter Marwedel (Technische Universität Dortmund, Germany)
Philip Koopman (Carnegie Mellon University, USA)
Praveen Raghavan (IMEC, Belgium)
Rajeev Barua (University of Maryland, USA)
Rodric Rabbah (IBM T.J. Watson Research Center, USA)
Shangping Ren (Illinois Institute of Technology, USA)
Stephen A. Edwards (Columbia University, USA)
Tulika Mitra (National University of Singapore, Singapore)
Zili Shao (Hong Kong Polytechnic University, Hong Kong)
STEERING COMMITTEE
Bruce Childers (University of Pittsburgh, USA)
Christoph Kirsch (Salzburg University, Austria)
Jaejin Lee (Seoul National University, Korea)
John Regehr (University of Utah, USA)
Koen De Bosschere (Ghent University, Belgium)
Kristian Flautner (ARM Ltd., United Kingdom)
Mahmut Kandemir (Pennsylvania State University, USA)
Mary Jane Irwin (Pennsylvania State University, USA)
Santosh Pande (Georgia Institute of Technology, USA)
Zhiyuan Li (chair, Purdue University, USA)
AT-LARGE MEMBERS
David Whalley (University of Florida, USA)
Annie Liu (State University of New York at Stony Brook, USA)
Frank Mueller (North Carolina State University, USA)
Peter Marwedel (Technische Universität Dortmund, Germany)
Reinhard Wilhelm (Saarland University, Germany)
GENERAL CHAIR
Jan Vitek (Purdue University, USA)
PROGRAM CHAIR
Bjorn De Sutter (Ghent University, Belgium)
PUBLICITY CHAIR
Tomas Kalibera (Charles University, Czech Republic)
*********************************************************
^ permalink raw reply
* Embedded Linux Conference videos
From: Michael Opdenacker @ 2010-09-02 5:30 UTC (permalink / raw)
To: CE Linux Developers List, linux-embedded mailing list
Greetings,
The videos from the 2010 edition of the Embedded Linux Conference have
just been released:
http://free-electrons.com/blog/elc-2010-videos/
If you are interested in such talks, what about joining the European
edition of the conference? It will take place in Cambridge (UK), on
October 27-28, and will be colocated with the GStreamer conference
(October 26). See http://www.embeddedlinuxconference.com/elc_europe10/
and http://gstreamer.freedesktop.org/conference/ for details.
Cheers,
Michael.
--
Michael Opdenacker, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
+ 33 621 604 642
^ permalink raw reply
* patch "add ttyprintk driver" added to gregkh-2.6 tree
From: gregkh @ 2010-09-01 22:50 UTC (permalink / raw)
To: samo_pogacnik, alan, gregkh, kay.sievers, linux-embedded,
linux-kernel
In-Reply-To: <1282761847.5857.9.camel@itpsd6lap>
This is a note to let you know that I've just added the patch titled
add ttyprintk driver
to my gregkh-2.6 tree which can be found in directory form at:
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/
and in git form at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/patches.git
The filename of this patch is:
add-ttyprintk-driver.patch
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
If this patch meets the merge guidelines for a bugfix, it should be
merged into Linus's tree before the next major kernel release.
If not, it will be merged into Linus's tree during the next merge window.
Either way, you will probably be copied on the patch when it gets sent
to Linus for merging so that others can see what is happening in kernel
development.
If you have any questions about this process, please let me know.
From samo_pogacnik@t-2.net Wed Sep 1 15:35:26 2010
Subject: add ttyprintk driver
From: Samo Pogacnik <samo_pogacnik@t-2.net>
To: linux kernel <linux-kernel@vger.kernel.org>
Cc: linux-embedded <linux-embedded@vger.kernel.org>,
Greg KH <gregkh@suse.de>, Alan Cox <alan@lxorguk.ukuu.org.uk>,
Kay Sievers <kay.sievers@vrfy.org>
Date: Wed, 25 Aug 2010 20:44:07 +0200
Message-Id: <1282761847.5857.9.camel@itpsd6lap>
Ttyprintk is a pseudo TTY driver, which allows users to make printk
messages, via output to ttyprintk device. It is possible to store
"console" messages inline with kernel messages for better analyses of
the boot process, for example.
Signed-off-by: Samo Pogacnik <samo_pogacnik@t-2.net>
Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
Documentation/devices.txt | 1
drivers/char/Kconfig | 15 +++
drivers/char/Makefile | 1
drivers/char/ttyprintk.c | 225 ++++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 242 insertions(+)
--- a/Documentation/devices.txt
+++ b/Documentation/devices.txt
@@ -239,6 +239,7 @@ Your cooperation is appreciated.
0 = /dev/tty Current TTY device
1 = /dev/console System console
2 = /dev/ptmx PTY master multiplex
+ 3 = /dev/ttyprintk User messages via printk TTY device
64 = /dev/cua0 Callout device for ttyS0
...
255 = /dev/cua191 Callout device for ttyS191
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -493,6 +493,21 @@ config LEGACY_PTY_COUNT
When not in use, each legacy PTY occupies 12 bytes on 32-bit
architectures and 24 bytes on 64-bit architectures.
+config TTY_PRINTK
+ bool "TTY driver to output user messages via printk"
+ depends on EMBEDDED
+ default n
+ ---help---
+ If you say Y here, the support for writing user messages (i.e.
+ console messages) via printk is available.
+
+ The feature is useful to inline user messages with kernel
+ messages.
+ In order to use this feature, you should output user messages
+ to /dev/ttyprintk or redirect console to this TTY.
+
+ If unsure, say N.
+
config BRIQ_PANEL
tristate 'Total Impact briQ front panel driver'
depends on PPC_CHRP
--- a/drivers/char/Makefile
+++ b/drivers/char/Makefile
@@ -12,6 +12,7 @@ obj-y += mem.o random.o tty_io.o n_tty.
obj-y += tty_mutex.o
obj-$(CONFIG_LEGACY_PTYS) += pty.o
obj-$(CONFIG_UNIX98_PTYS) += pty.o
+obj-$(CONFIG_TTY_PRINTK) += ttyprintk.o
obj-y += misc.o
obj-$(CONFIG_VT) += vt_ioctl.o vc_screen.o selection.o keyboard.o
obj-$(CONFIG_BFIN_JTAG_COMM) += bfin_jtag_comm.o
--- /dev/null
+++ b/drivers/char/ttyprintk.c
@@ -0,0 +1,225 @@
+/*
+ * linux/drivers/char/ttyprintk.c
+ *
+ * Copyright (C) 2010 Samo Pogacnik
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the smems of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ */
+
+/*
+ * This pseudo device allows user to make printk messages. It is possible
+ * to store "console" messages inline with kernel messages for better analyses
+ * of the boot process, for example.
+ */
+
+#include <linux/device.h>
+#include <linux/serial.h>
+#include <linux/tty.h>
+
+struct ttyprintk_port {
+ struct tty_port port;
+ struct mutex port_write_mutex;
+};
+
+static struct ttyprintk_port tpk_port;
+
+/*
+ * Our simple preformatting supports transparent output of (time-stamped)
+ * printk messages (also suitable for logging service):
+ * - any cr is replaced by nl
+ * - adds a ttyprintk source tag in front of each line
+ * - too long message is fragmeted, with '\'nl between fragments
+ * - TPK_STR_SIZE isn't really the write_room limiting factor, bcause
+ * it is emptied on the fly during preformatting.
+ */
+#define TPK_STR_SIZE 508 /* should be bigger then max expected line length */
+#define TPK_MAX_ROOM 4096 /* we could assume 4K for instance */
+static const char *tpk_tag = "[U] "; /* U for User */
+static int tpk_curr;
+
+static int tpk_printk(const unsigned char *buf, int count)
+{
+ static char tmp[TPK_STR_SIZE + 4];
+ int i = tpk_curr;
+
+ if (buf == NULL) {
+ /* flush tmp[] */
+ if (tpk_curr > 0) {
+ /* non nl or cr terminated message - add nl */
+ tmp[tpk_curr + 0] = '\n';
+ tmp[tpk_curr + 1] = '\0';
+ printk(KERN_INFO "%s%s", tpk_tag, tmp);
+ tpk_curr = 0;
+ }
+ return i;
+ }
+
+ for (i = 0; i < count; i++) {
+ tmp[tpk_curr] = buf[i];
+ if (tpk_curr < TPK_STR_SIZE) {
+ switch (buf[i]) {
+ case '\r':
+ /* replace cr with nl */
+ tmp[tpk_curr + 0] = '\n';
+ tmp[tpk_curr + 1] = '\0';
+ printk(KERN_INFO "%s%s", tpk_tag, tmp);
+ tpk_curr = 0;
+ if (buf[i + 1] == '\n')
+ i++;
+ break;
+ case '\n':
+ tmp[tpk_curr + 1] = '\0';
+ printk(KERN_INFO "%s%s", tpk_tag, tmp);
+ tpk_curr = 0;
+ break;
+ default:
+ tpk_curr++;
+ }
+ } else {
+ /* end of tmp buffer reached: cut the message in two */
+ tmp[tpk_curr + 1] = '\\';
+ tmp[tpk_curr + 2] = '\n';
+ tmp[tpk_curr + 3] = '\0';
+ printk(KERN_INFO "%s%s", tpk_tag, tmp);
+ tpk_curr = 0;
+ }
+ }
+
+ return count;
+}
+
+/*
+ * TTY operations open function.
+ */
+static int tpk_open(struct tty_struct *tty, struct file *filp)
+{
+ tty->driver_data = &tpk_port;
+
+ return tty_port_open(&tpk_port.port, tty, filp);
+}
+
+/*
+ * TTY operations close function.
+ */
+static void tpk_close(struct tty_struct *tty, struct file *filp)
+{
+ struct ttyprintk_port *tpkp = tty->driver_data;
+
+ mutex_lock(&tpkp->port_write_mutex);
+ /* flush tpk_printk buffer */
+ tpk_printk(NULL, 0);
+ mutex_unlock(&tpkp->port_write_mutex);
+
+ tty_port_close(&tpkp->port, tty, filp);
+}
+
+/*
+ * TTY operations write function.
+ */
+static int tpk_write(struct tty_struct *tty,
+ const unsigned char *buf, int count)
+{
+ struct ttyprintk_port *tpkp = tty->driver_data;
+ int ret;
+
+
+ /* exclusive use of tpk_printk within this tty */
+ mutex_lock(&tpkp->port_write_mutex);
+ ret = tpk_printk(buf, count);
+ mutex_unlock(&tpkp->port_write_mutex);
+
+ return ret;
+}
+
+/*
+ * TTY operations write_room function.
+ */
+static int tpk_write_room(struct tty_struct *tty)
+{
+ return TPK_MAX_ROOM;
+}
+
+/*
+ * TTY operations ioctl function.
+ */
+static int tpk_ioctl(struct tty_struct *tty, struct file *file,
+ unsigned int cmd, unsigned long arg)
+{
+ struct ttyprintk_port *tpkp = tty->driver_data;
+
+ if (!tpkp)
+ return -EINVAL;
+
+ switch (cmd) {
+ /* Stop TIOCCONS */
+ case TIOCCONS:
+ return -EOPNOTSUPP;
+ default:
+ return -ENOIOCTLCMD;
+ }
+ return 0;
+}
+
+static const struct tty_operations ttyprintk_ops = {
+ .open = tpk_open,
+ .close = tpk_close,
+ .write = tpk_write,
+ .write_room = tpk_write_room,
+ .ioctl = tpk_ioctl,
+};
+
+struct tty_port_operations null_ops = { };
+
+static struct tty_driver *ttyprintk_driver;
+
+static int __init ttyprintk_init(void)
+{
+ int ret = -ENOMEM;
+ void *rp;
+
+ ttyprintk_driver = alloc_tty_driver(1);
+ if (!ttyprintk_driver)
+ return ret;
+
+ ttyprintk_driver->owner = THIS_MODULE;
+ ttyprintk_driver->driver_name = "ttyprintk";
+ ttyprintk_driver->name = "ttyprintk";
+ ttyprintk_driver->major = TTYAUX_MAJOR;
+ ttyprintk_driver->minor_start = 3;
+ ttyprintk_driver->num = 1;
+ ttyprintk_driver->type = TTY_DRIVER_TYPE_CONSOLE;
+ ttyprintk_driver->init_termios = tty_std_termios;
+ ttyprintk_driver->init_termios.c_oflag = OPOST | OCRNL | ONOCR | ONLRET;
+ ttyprintk_driver->flags = TTY_DRIVER_RESET_TERMIOS |
+ TTY_DRIVER_REAL_RAW | TTY_DRIVER_DYNAMIC_DEV;
+ tty_set_operations(ttyprintk_driver, &ttyprintk_ops);
+
+ ret = tty_register_driver(ttyprintk_driver);
+ if (ret < 0) {
+ printk(KERN_ERR "Couldn't register ttyprintk driver\n");
+ goto error;
+ }
+
+ /* create our unnumbered device */
+ rp = device_create(tty_class, NULL, MKDEV(TTYAUX_MAJOR, 3), NULL,
+ ttyprintk_driver->name);
+ if (IS_ERR(rp)) {
+ printk(KERN_ERR "Couldn't create ttyprintk device\n");
+ ret = PTR_ERR(rp);
+ goto error;
+ }
+
+ tty_port_init(&tpk_port.port);
+ tpk_port.port.ops = &null_ops;
+ mutex_init(&tpk_port.port_write_mutex);
+
+ return 0;
+
+error:
+ put_tty_driver(ttyprintk_driver);
+ ttyprintk_driver = NULL;
+ return ret;
+}
+module_init(ttyprintk_init);
^ 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