Is there any documentation which provided details about Linux Kernel Memory map (before and after decompression - assumption is a compressed Linux Kernel Image) with Ram Disk image, Root File system or can anybody provide me some insight onto the Kernel Memory map (Not talking about the process memory layout).
I am using PowerQuicc II processor. With Best Regards, C.R.Srivatsan -----Original Message----- From: [EMAIL PROTECTED] [mailto:linuxppc-embedded-bounces at ozlabs.org] On Behalf Of linuxppc-embedded-request at ozlabs.org Sent: Saturday, November 20, 2004 6:30 AM To: linuxppc-embedded at ozlabs.org Subject: Linuxppc-embedded Digest, Vol 3, Issue 30 Send Linuxppc-embedded mailing list submissions to linuxppc-embedded at ozlabs.org To subscribe or unsubscribe via the World Wide Web, visit https://ozlabs.org/mailman/listinfo/linuxppc-embedded or, via email, send a message with subject or body 'help' to linuxppc-embedded-request at ozlabs.org You can reach the person managing the list at linuxppc-embedded-owner at ozlabs.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Linuxppc-embedded digest..." Today's Topics: 1. [PATCH 2.6.10-rc2] ppc32: Have the 8260 board-hook happen a bit later (Tom Rini) 2. [PATCH 2.6.10-rc2] ppc32: Fix __iomem warnings in TODC code (Tom Rini) 3. [PATCH][PPC32] Marvell host bridge support (mv64x60) (Mark A. Greer) 4. [PATCH][PPC32] Support for Marvell EV-64260[ab]-BP eval platform (Mark A. Greer) 5. [PATCH][PPC32] Support for Artesyn Katana cPCI boards (Mark A. Greer) 6. Re: [PATCH][PPC32] Marvell host bridge support (mv64x60) (Andrew Morton) ---------------------------------------------------------------------- Message: 1 Date: Fri, 19 Nov 2004 11:06:53 -0700 From: Tom Rini <[EMAIL PROTECTED]> Subject: [PATCH 2.6.10-rc2] ppc32: Have the 8260 board-hook happen a bit later To: Andrew Morton <akpm at osdl.org>, linuxppc-embedded at ozlabs.org Cc: Borut Lukic <borutlukic at email.si> Message-ID: <20041119180653.GF16043 at smtp.west.cox.net> Content-Type: text/plain; charset=us-ascii Borut Lukic <borutlukic at email.si> brought to my attention that in platform_init() on 8260 the board hook was being called too early to allow for overrides (e.g. different memory sizings functions or rtc, or anything else). This moves the call to the end of platform_init() and I suspect fixes some unnoticed yet bugs in a number of 8260 platforms. Signed-off-by: Tom Rini <trini at kernel.crashing.org> --- 1.26/arch/ppc/syslib/m8260_setup.c 2004-08-24 08:31:20 -07:00 +++ edited/arch/ppc/syslib/m8260_setup.c 2004-11-19 11:03:35 -07:00 @@ -241,9 +241,6 @@ strcpy(cmd_line, (char *)(r6+KERNELBASE)); } - /* Call back for board-specific settings. */ - m82xx_board_init(); - ppc_md.setup_arch = m8260_setup_arch; ppc_md.show_cpuinfo = m8260_show_cpuinfo; ppc_md.init_IRQ = m8260_init_IRQ; @@ -259,4 +256,7 @@ ppc_md.find_end_of_memory = m8260_find_end_of_memory; ppc_md.setup_io_mappings = m8260_map_io; + + /* Call back for board-specific settings and overrides. */ + m82xx_board_init(); } -- Tom Rini http://gate.crashing.org/~trini/ ------------------------------ Message: 2 Date: Fri, 19 Nov 2004 11:15:25 -0700 From: Tom Rini <[EMAIL PROTECTED]> Subject: [PATCH 2.6.10-rc2] ppc32: Fix __iomem warnings in TODC code To: Andrew Morton <akpm at osdl.org>, linuxppc-embedded at ozlabs.org Message-ID: <20041119181525.GG16043 at smtp.west.cox.net> Content-Type: text/plain; charset=us-ascii A trivial fix for the __iomem warnings in arch/ppc/syslib/todc_time.c Signed-off-by: Randy Vinson <rvinson at mvista.com> Signed-off-by: Tom Rini <trini at kernel.crashing.org> --- a/arch/ppc/syslib/todc_time.c 2004-10-29 18:29:54.000000000 -0700 +++ b/arch/ppc/syslib/todc_time.c 2004-10-29 18:40:10.000000000 -0700 @@ -82,13 +82,13 @@ extern spinlock_t rtc_lock; u_char todc_direct_read_val(int addr) { - return readb(todc_info->nvram_data + addr); + return readb((void __iomem *)(todc_info->nvram_data + addr)); } void todc_direct_write_val(int addr, unsigned char val) { - writeb(val, todc_info->nvram_data + addr); + writeb(val, (void __iomem *)(todc_info->nvram_data + addr)); return; } -- Tom Rini http://gate.crashing.org/~trini/ ------------------------------ Message: 3 Date: Fri, 19 Nov 2004 14:43:28 -0700 From: "Mark A. Greer" <[EMAIL PROTECTED]> Subject: [PATCH][PPC32] Marvell host bridge support (mv64x60) To: akpm <akpm at osdl.org> Cc: lkml <linux-kernel at vger.kernel.org>, linuxppc-embedded at ozlabs.org Message-ID: <419E6900.5070001 at mvista.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed This patch adds core support for a line of host bridges from Marvell (formerly Galileo). This code has been tested with a GT64260a, GT64260b, MV64360, and MV64460. Patches for platforms that use these bridges will be sent separately. The patch is rather large so a link is provided. Signed-off-by: Mark A. Greer <mgreer at mvista.com> -- ftp://source.mvista.com/pub/mgreer/mv64x60.patch ------------------------------ Message: 4 Date: Fri, 19 Nov 2004 14:49:04 -0700 From: "Mark A. Greer" <[EMAIL PROTECTED]> Subject: [PATCH][PPC32] Support for Marvell EV-64260[ab]-BP eval platform To: akpm <akpm at osdl.org> Cc: lkml <linux-kernel at vger.kernel.org>, linuxppc-embedded at ozlabs.org Message-ID: <419E6A50.5060107 at mvista.com> Content-Type: text/plain; charset=us-ascii; format=flowed This patch adds support for a line of evaluation platforms from Marvell that use the Marvell GT64260[ab] host bridges. This patch depends on the Marvell host bridge support patch (mv64x60). This patch is larger than 40KB so a link is provided (as per instructions in SubmittingPatches). Signed-off-by: Mark A. Greer <mgreer at mvista.com> -- ftp://source.mvista.com/pub/mgreer/ev64260.patch ------------------------------ Message: 5 Date: Fri, 19 Nov 2004 15:29:59 -0700 From: "Mark A. Greer" <[EMAIL PROTECTED]> Subject: [PATCH][PPC32] Support for Artesyn Katana cPCI boards To: akpm <akpm at osdl.org> Cc: lkml <linux-kernel at vger.kernel.org>, linuxppc-embedded at ozlabs.org Message-ID: <419E73E7.8080703 at mvista.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed This patch adds support for the Artesyn Katana 750i, 752i, and 3750. This patch depends on the Marvell host bridge support patch (mv64x60) [and the ev64260 platform support patch because the 2 patches touch the same Makefiles and Kconfig file but there are no code dependencies]. Note that the patch itself does not depend on the previously submitted MPSC driver but the platform does. That is, to use the serial ports on those boards, the MPSC driver patch is required. This patch is larger that 40KB so a link is provided (as per instructions in SubmittingPatches). Signed-off-by: Mark A. Greer <mgreer at mvista.com> -- ftp://source.mvista.com/pub/mgreer/katana.patch ------------------------------ Message: 6 Date: Fri, 19 Nov 2004 15:58:54 -0800 From: Andrew Morton <[EMAIL PROTECTED]> Subject: Re: [PATCH][PPC32] Marvell host bridge support (mv64x60) To: "Mark A. Greer" <mgreer at mvista.com> Cc: linux-kernel at vger.kernel.org, linuxppc-embedded at ozlabs.org Message-ID: <20041119155854.02af2174.akpm at osdl.org> Content-Type: text/plain; charset=US-ASCII "Mark A. Greer" <mgreer at mvista.com> wrote: > > This patch adds core support for a line of host bridges from Marvell > (formerly Galileo). This code has been tested with a GT64260a, > GT64260b, MV64360, and MV64460. Patches for platforms that use these > bridges will be sent separately. > Shouldn't these guys: + u32 cpu2mem_tab[MV64x60_CPU2MEM_WINDOWS][2] = { + { MV64x60_CPU2MEM_0_BASE, MV64x60_CPU2MEM_0_SIZE }, + { MV64x60_CPU2MEM_1_BASE, MV64x60_CPU2MEM_1_SIZE }, + { MV64x60_CPU2MEM_2_BASE, MV64x60_CPU2MEM_2_SIZE }, + { MV64x60_CPU2MEM_3_BASE, MV64x60_CPU2MEM_3_SIZE } + }; + u32 com2mem_tab[MV64x60_CPU2MEM_WINDOWS][2] = { + { MV64360_MPSC2MEM_0_BASE, MV64360_MPSC2MEM_0_SIZE }, + { MV64360_MPSC2MEM_1_BASE, MV64360_MPSC2MEM_1_SIZE }, + { MV64360_MPSC2MEM_2_BASE, MV64360_MPSC2MEM_2_SIZE }, + { MV64360_MPSC2MEM_3_BASE, MV64360_MPSC2MEM_3_SIZE } + }; + u32 dram_selects[MV64x60_CPU2MEM_WINDOWS] = { 0xe, 0xd, 0xb, 0x7 }; be static, and maybe __devinitdata? Right now, the CPU has to populate them by hand at runtime. +wait_for_ownership(int chan) +{ + int i; + + for (i=0; i<MAX_TX_WAIT; i++) { + if ((MV64x60_REG_READ(sdma_regs[chan].sdcm) & + SDMA_SDCM_TXD) == 0) + break; + + udelay(1000); ow, big busywait. Can't use a sleep in here? I guess not :( + * arch/ppc/boot/simple/mv64x60_tty.c hm. Normally we put arch-specific drivers like this into drivers/serial and do the appropriate Kconfig work. Is there a reason why this serial driver is buried under arch/ppc? +#include "../../../../drivers/serial/mpsc_defs.h" erk. +struct mv64x60_rx_desc { + volatile u16 bufsize; + volatile u16 bytecnt; + volatile u32 cmd_stat; + volatile u32 next_desc_ptr; + volatile u32 buffer; +}; + +struct mv64x60_tx_desc { + volatile u16 bytecnt; + volatile u16 shadow; + volatile u32 cmd_stat; + volatile u32 next_desc_ptr; + volatile u32 buffer; +}; Do these need to be volatile? If so, it indicates that the driver is doing something wrong. +gt64260_register_hdlrs(void) +{ + /* Register CPU interface error interrupt handler */ + request_irq(MV64x60_IRQ_CPU_ERR, gt64260_cpu_error_int_handler, + SA_INTERRUPT, CPU_INTR_STR, 0); request_irq() can fail. +int +mv64360_get_irq(struct pt_regs *regs) +{ + int irq; + int irq_gpp; + +#ifdef CONFIG_SMP + /* + * Second CPU gets only doorbell (message) interrupts. + * The doorbell interrupt is BIT28 in the main interrupt low cause reg. + */ + int cpu_nr = smp_processor_id(); This function has no callers, so I am unable to determine whether it is called from non-preemptible code. If it is called from preemptible code then that smp_processor_id() is buggy, because you can switch CPUs at any time. +static struct platform_device mpsc_shared_device = { /* Shared device */ + .name = MPSC_SHARED_NAME, + .id = 0, + .num_resources = ARRAY_SIZE(mv64x60_mpsc_shared_resources), + .resource = mv64x60_mpsc_shared_resources, + .dev = { + .driver_data = (void *)&mv64x60_mpsc_shared_pd_dd, + }, +}; The cast to void* is unnecessary. + (void)mv64x60_setup_for_chip(&bh); how come you always stick that (void) in there? +mv64x60_config_cpu2mem_windows(struct mv64x60_handle *bh, + struct mv64x60_setup_info *si, + u32 mem_windows[MV64x60_CPU2MEM_WINDOWS][2]) +{ + u32 i, win; + u32 prot_tab[] = { + MV64x60_CPU_PROT_0_WIN, MV64x60_CPU_PROT_1_WIN, + MV64x60_CPU_PROT_2_WIN, MV64x60_CPU_PROT_3_WIN + }; + u32 cpu_snoop_tab[] = { + MV64x60_CPU_SNOOP_0_WIN, MV64x60_CPU_SNOOP_1_WIN, + MV64x60_CPU_SNOOP_2_WIN, MV64x60_CPU_SNOOP_3_WIN + }; static initialisation? +mv64x60_config_cpu2pci_windows(struct mv64x60_handle *bh, + struct mv64x60_pci_info *pi, u32 bus) +{ + int i; + u32 win_tab[2][4] = { + { MV64x60_CPU2PCI0_IO_WIN, MV64x60_CPU2PCI0_MEM_0_WIN, + MV64x60_CPU2PCI0_MEM_1_WIN, + MV64x60_CPU2PCI0_MEM_2_WIN }, + { MV64x60_CPU2PCI1_IO_WIN, MV64x60_CPU2PCI1_MEM_0_WIN, + MV64x60_CPU2PCI1_MEM_1_WIN, + MV64x60_CPU2PCI1_MEM_2_WIN }, + }; + u32 remap_tab[2][4] = { + { MV64x60_CPU2PCI0_IO_REMAP_WIN, + MV64x60_CPU2PCI0_MEM_0_REMAP_WIN, + MV64x60_CPU2PCI0_MEM_1_REMAP_WIN, + MV64x60_CPU2PCI0_MEM_2_REMAP_WIN }, + { MV64x60_CPU2PCI1_IO_REMAP_WIN, + MV64x60_CPU2PCI1_MEM_0_REMAP_WIN, + MV64x60_CPU2PCI1_MEM_1_REMAP_WIN, + MV64x60_CPU2PCI1_MEM_2_REMAP_WIN } + }; + ditto +mv64x60_config_pci2mem_windows(struct mv64x60_handle *bh, and here +mv64360_set_pci2mem_window(struct pci_controller *hose, u32 bus, u32 window, and here +mv64360_config_io2mem_windows(struct mv64x60_handle *bh, and here Anyway, I'll stick this as-is in -mm. Feel free to send an incremental patch, or a replacement. ------------------------------ _______________________________________________ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded End of Linuxppc-embedded Digest, Vol 3, Issue 30 ************************************************ ********************************DISCLAIMER********************************** This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege of Deccanet Designs Ltd. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from retaining, using, copying, altering or disclosing the contents of this message. ****************************************************************************
