Re: [PATCH/RFC] Add Alternative Log Buffer Support for printk Messages
On 1/6/09 4:04 PM, Benjamin Herrenschmidt wrote: On Tue, 2008-11-25 at 10:34 -0800, Grant Erickson wrote: This merges support for the previously DENX-only kernel feature of specifying an alternative, external buffer for kernel printk messages and their associated metadata. In addition, this ports architecture support for this feature from arch/ppc to arch/powerpc. Signed-off-by: Grant Erickson gerick...@nuovations.com Considering the extensive changes to generic code, this patch will have to be submitted via the linux-kernel mailing list. I suggest you split the generic core change from the powerpc specific implementation. I'm not sure whether I like the idea myself or not there, so you'll have to convince the powers that be to take it. Ben: Thanks for the feedback. Matt Sealey had some good feedback http://ozlabs.org/pipermail/linuxppc-dev/2008-November/065594.html which I have on my to-do list to evaluate. In the interim, I'll hold off on pushing up to linux-kernel until I've done that. Regards, Grant -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] Add Alternative Log Buffer Support for printk Messages
On Tue, Nov 25, 2008 at 3:45 PM, David Brownell [EMAIL PROTECTED] wrote: No comment from me on $SUBJECT beyond it seems plausible, but ... On Tuesday 25 November 2008, David VomLehn wrote: The important point, though, is that device tree is the only thing approaching a standard on any non-x86-based platform for passing structured information from the bootloader to the kernel. The command line is just not sufficient for this. Me, I'll be happier if I don't have to try using that device tree. Having board-specific code in the kernel is a more complete solution, and makes it a lot easier to cope with all the hardware goofage. I disagree. Recall that the *original* notion behind OpenBoot (now OpenFirmware) was to have tables for the stuff that was table-friendly, and call out to FORTH code (possibly not just at boot time) for the rest. (Given the choice of FORTH vs ACPI bytecodes, I'd go for FORTH; but the better option is neither.) The problem really is that Linux never really cared to run Forth code or even keep the client interface for OF and 99% of the devices with real device trees and real client interfaces, have really bad hardware support or methods implemented that just don't work - not to mention the evil that happens on the difference between Linux ABI and the OF ABI, the client interface context switch, real-mode or virtual-mode firmwares. The most useful thing is the representation of the devices in the device-tree. I do however agree that sometimes FAR too much is being put into the device trees, the massive amount of overly verbose information about devices which do not need the information there is just redundant. Reading processor registers out of the device tree (such as the system version register on SoCs) is totally dumb, but this was suggested at one time. Once you match the driver with a compatible property, you're set; you know which driver you're on. You can read out quirks and make inferences from other parts of the tree (this is something that most drivers do NOT do since people think reading outside the node just matched is some evil) where these are truly board-level problems. For instance where the ATA DMA lines are not connected on a 5200B board, this must be described. Of course whether you decide this from the root model property and make a guess (all boards of fsl,broken5200 might have the bug) or specifically say in /soc/ata that dma-is-broken is the big question. In this event, Grant came up with a more fun solution which is to specify the maximum modes in the device tree therefore not bringing ANY board specific properties into it and making sure you do not clutter the driver with board specifics! This is exactly how device trees should be designed. Properties such as fsl5200-clocking in i2c nodes, is NOT. The compatible property of the node has fsl,mpc5200b-i2c, this implies 5200 clocking for the i2c bus anyway. I really don't get why this property even exists. It's not like there is some alternative way on the chip.. :D Right now I see an awful lot of work going into trying to force lots of stuff into table format. Even when it's the sort of one-off or board-specific quirkery that was an original motivation for having FORTH escapes (tasks that were not table-friendly). What about drivers where there is no binding for OF or Forth and never was and never would/will be? There is no Forth escape for that. Forth - and the client interface - should be used where necessary to bring the system up. This be modifying the device tree, implementing methods to boot (it makes some sense that if the ATA methods in the client interface work, then Linux could load it's own initrd without the help of Yaboot or GRUB, for example, right in the boot wrapper, and to the location it sees best to load it, and not what Yaboot decides for it, and there would be no need to maintain 4 different filesystem codes in 3 alternative loaders and the kernel). But unfortunately most systems have crap CIF support (ours included) which do not come up to the task. -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC] Add Alternative Log Buffer Support for printk Messages
This merges support for the previously DENX-only kernel feature of
specifying an alternative, external buffer for kernel printk
messages and their associated metadata. In addition, this ports
architecture support for this feature from arch/ppc to arch/powerpc.
Signed-off-by: Grant Erickson [EMAIL PROTECTED]
---
When this option is enabled, an architecture- or machine-specific log
buffer is used for all printk messages. This allows entities such as
boot loaders (e.g. U-Boot) to place printk-compatible messages into
this buffer and for the kernel to coalesce them with its normal
messages.
The code has historically been used and proven to work on the LWMON5
platform under arch/ppc and is now used (by me) successfully on the
AMCC Haleakala and Kilauea platforms.
As implemented for arch/powerpc, two suboptions for the alternative
log buffer are supported. The buffer may be contiguous with the
metadata and message data colocated or the metadata and message
storage may be in discontiguous regions of memory (e.g. a set of
scratch registers and an SRAM buffer). On Kilauea and Haleakala, I
have used the former; whereas LWMON5 has traditionally used the latter.
The code here is, more or less, as-is from the DENX GIT tree. Comments
welcome.
arch/powerpc/kernel/prom.c | 93 +++
include/linux/logbuff.h| 56
init/Kconfig | 25 +++
init/main.c|4 +
kernel/printk.c| 149 +++-
5 files changed, 324 insertions(+), 3 deletions(-)
create mode 100644 include/linux/logbuff.h
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 3a2dc7e..60282f1 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -32,6 +32,7 @@
#include linux/debugfs.h
#include linux/irq.h
#include linux/lmb.h
+#include linux/logbuff.h
#include asm/prom.h
#include asm/rtas.h
@@ -61,6 +62,15 @@
#define DBG(fmt...)
#endif
+#ifdef CONFIG_LOGBUFFER
+#ifdef CONFIG_ALT_LB_LOCATION
+# if !defined(BOARD_ALT_LH_ADDR) || !defined(BOARD_ALT_LB_ADDR)
+# error Please specify BOARD_ALT_LH_ADDR BOARD_ALT_LB_ADDR.
+# endif
+#else /* !CONFIG_ALT_LB_LOCATION */
+static phys_addr_t ext_logbuff;
+#endif /* CONFIG_ALT_LB_LOCATION */
+#endif /* CONFIG_LOGBUFFER */
static int __initdata dt_root_addr_cells;
static int __initdata dt_root_size_cells;
@@ -1018,6 +1028,85 @@ static int __init early_init_dt_scan_memory(unsigned
long node,
return 0;
}
+#ifdef CONFIG_LOGBUFFER
+#ifdef CONFIG_ALT_LB_LOCATION
+/* Alternative external log buffer mapping: log metadata header the
+ * character buffer are separated and allocated not in RAM but in some
+ * other memory-mapped I/O region (e.g. log head in unused registers,
+ * and log buffer in OCM memory)
+ */
+int __init setup_ext_logbuff_mem(volatile logbuff_t **lhead, char **lbuf)
+{
+ void *h, *b;
+
+ if (unlikely(!lhead) || unlikely(!lbuf))
+ return -EINVAL;
+
+ /* map log head */
+ h = ioremap(BOARD_ALT_LH_ADDR, sizeof(logbuff_t));
+ if (unlikely(!h))
+ return -EFAULT;
+
+ /* map log buffer */
+ b = ioremap(BOARD_ALT_LB_ADDR, LOGBUFF_LEN);
+ if (unlikely(!b)) {
+ iounmap(h);
+ return -EFAULT;
+ }
+
+ *lhead = h;
+ *lbuf = b;
+
+ return 0;
+}
+#else /* !CONFIG_ALT_LB_LOCATION */
+/* Usual external log-buffer mapping: log metadata header the character
+ * buffer are both contiguous in system RAM.
+ */
+int __init setup_ext_logbuff_mem(logbuff_t **lhead, char **lbuf)
+{
+ void *p;
+
+ if (unlikely(!lhead) || unlikely(!lbuf))
+ return -EINVAL;
+
+ if (unlikely(!ext_logbuff) || !lmb_is_reserved(ext_logbuff))
+ return -EFAULT;
+
+ p = ioremap(ext_logbuff, LOGBUFF_RESERVE);
+
+ if (unlikely(!p))
+ return -EFAULT;
+
+ *lhead = (logbuff_t *)(p + LOGBUFF_OVERHEAD -
+ sizeof(logbuff_t) +
+ sizeof(((logbuff_t *)0)-buf));
+ *lbuf = (*lhead)-buf;
+
+ return 0;
+}
+
+/* When the external log buffer configuration is used with the
+ * non-alternate location, the log head metadata and character buffer
+ * lie in the LOGBUFF_RESERVE bytes at the end of system RAM. Add this
+ * block of memory to the reserved memory pool so that it is not
+ * allocated for other purposes.
+ */
+static void __init reserve_ext_logbuff_mem(void)
+{
+ phys_addr_t top = lmb_end_of_DRAM();
+ phys_addr_t size = LOGBUFF_RESERVE;
+ phys_addr_t base = top - size;
+
+ if (top base) {
+ ext_logbuff = base;
+ DBG(reserving: %x - %x\n, base, size);
+ lmb_reserve(base, size);
+ }
+}
+#endif /* CONFIG_ALT_LB_LOCATION */
+#endif /* CONFIG_LOGBUFFER */
+
static void __init early_reserve_mem(void)
{
u64 base, size;
@@
Re: [PATCH/RFC] Add Alternative Log Buffer Support for printk Messages
On Tue, 25 Nov 2008 12:53:12 -0600 Matt Sealey [EMAIL PROTECTED] wrote: Nitpick, really.. shouldn't the logbuffer location(s) be some device tree property(ies), perhaps something in the /chosen node that U-Boot etc. can then fill out? I don't think that's a nitpick. It's a fundamental change in how this would all work. However, I do think you're generally right. Perhaps not /chosen, but maybe something like /rtas or /firmware, etc. josh -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] Add Alternative Log Buffer Support for printk Messages
On 11/25/08 10:55 AM, Josh Boyer wrote: On Tue, 25 Nov 2008 12:53:12 -0600 Matt Sealey [EMAIL PROTECTED] wrote: Nitpick, really.. shouldn't the logbuffer location(s) be some device tree property(ies), perhaps something in the /chosen node that U-Boot etc. can then fill out? I don't think that's a nitpick. It's a fundamental change in how this would all work. However, I do think you're generally right. Perhaps not /chosen, but maybe something like /rtas or /firmware, etc. I'm inclined to agree with you both; however, the submitted implementation was a choice of expediency given the existing DENX implementation and a customer that needed the feature yesterday. ARM, MIPS, et al have not yet adopted device trees, correct? If so, is there value in providing the submitted implementation and adding support for getting said information from the device tree as another option if such information exists? Regards, Grant -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] Add Alternative Log Buffer Support for printk Messages
. F On Tue, Nov 25, 2008 at 12:51 PM, Bill Gatliff [EMAIL PROTECTED] wrote: Matt Sealey wrote: I can think of a bunch of reasons why it's a good idea.. Can you point to a GPL/LGPL/BSD/etc. source code for an OpenFirmware implementation? In powerpc land using the Open Firmware device tree does not depend on also using Open Firmware. From that perspective the availability of an open sourced Open Firmware is irrelevant. But, both OpenFirmware and SmartFirmware have been open sourced: http://www.openfirmware.info/Open_Firmware http://www.openfirmware.info/SmartFirmware Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] Add Alternative Log Buffer Support for printk Messages
Matt Sealey wrote: Yes, there's FirmWorks, CodeGen SmartFirmware, IBM SLOF and OpenBIOS.. they're all linked from the OpenBIOS website (along with a bunch of the documentation from http://www.openfirmware.org in more-readable formats like PDF) http://www.openbios.org/ But here's the real question; why do you need an opensource implementation? Curiosity? That, and I prefer Free *ware whenever that's an option. :) Nothing against the commercial alternatives, of course. But I'm already doing my own heavy lifting, because my platforms are all full-custom with very limited production runs. Since I'm into the guts of all my code anyway, I'm not inclined to outsource a bootloader development effort. Just trying to figure out where the walls of this sandbox are. I've been aware of the concept of Open Firmware for a while, but haven't really looked into it before now--- mostly because my impression until now was that the available implementations were both closed-source, and not supporting embedded, non-PPC targets like ARM. b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] Add Alternative Log Buffer Support for printk Messages
On Tue, 2008-11-25 at 14:19 -0600, Bill Gatliff wrote: Just trying to figure out where the walls of this sandbox are. I've been aware of the concept of Open Firmware for a while, but haven't really looked into it before now--- mostly because my impression until now was that the available implementations were both closed-source, and not supporting embedded, non-PPC targets like ARM. FWIW, at the last OLS there was interest expressed by at least one ARM-based platform and I'm working on a set of patches to add the device tree for MIPS. It's going very slowly and is dependent on a patchset to add support for our platform, so it will take a while to make it available. The important point, though, is that device tree is the only thing approaching a standard on any non-x86-based platform for passing structured information from the bootloader to the kernel. The command line is just not sufficient for this. -- David VomLehn - - - - - Cisco- - - - - This e-mail and any attachments may contain information which is confidential, proprietary, privileged or otherwise protected by law. The information is solely intended for the named addressee (or a person responsible for delivering it to the addressee). If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete it from your computer. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] Add Alternative Log Buffer Support for printk Messages
Dear Matt, In message [EMAIL PROTECTED] you wrote: There is also no reason you can't hard-code the locations into the device tree, to support older U-Boots that don't know about /chosen/linux,log-metadata and /chosen/linux,log-buffer*. Actually there is such reason - U-Boot traditionally allocates the log buffer close to the upper end of system memory, so the start address depends on the memory size on the board, which may vary. 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: [EMAIL PROTECTED] The human mind ordinarily operates at only ten percent of its capacity. The rest is overhead for the operating system. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] Add Alternative Log Buffer Support for printk Messages
No comment from me on $SUBJECT beyond it seems plausible, but ... On Tuesday 25 November 2008, David VomLehn wrote: The important point, though, is that device tree is the only thing approaching a standard on any non-x86-based platform for passing structured information from the bootloader to the kernel. The command line is just not sufficient for this. Me, I'll be happier if I don't have to try using that device tree. Having board-specific code in the kernel is a more complete solution, and makes it a lot easier to cope with all the hardware goofage. Recall that the *original* notion behind OpenBoot (now OpenFirmware) was to have tables for the stuff that was table-friendly, and call out to FORTH code (possibly not just at boot time) for the rest. (Given the choice of FORTH vs ACPI bytecodes, I'd go for FORTH; but the better option is neither.) Right now I see an awful lot of work going into trying to force lots of stuff into table format. Even when it's the sort of one-off or board-specific quirkery that was an original motivation for having FORTH escapes (tasks that were not table-friendly). - Dave -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] Add Alternative Log Buffer Support for printk Messages
On Tue, Nov 25, 2008 at 13:34, Grant Erickson wrote: This merges support for the previously DENX-only kernel feature of specifying an alternative, external buffer for kernel printk messages and their associated metadata. In addition, this ports architecture support for this feature from arch/ppc to arch/powerpc. Signed-off-by: Grant Erickson [EMAIL PROTECTED] --- When this option is enabled, an architecture- or machine-specific log buffer is used for all printk messages. This allows entities such as boot loaders (e.g. U-Boot) to place printk-compatible messages into this buffer and for the kernel to coalesce them with its normal messages. snip this extended info should be part of the changelog and thus above the --- marker ... -mike -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
