Need help Understanding initial memory conditions.
David H. Lynch Jr. wrote: > Kalle Pokki wrote: > >> 1. Put RAM to 0x000 and flash to some location it mirrors to your >> boot vector. Linux always expects your physical memory to be at zero. >> It is then mapped to virtual address 0xC000. > >In both this list and elsewhere I have seen several references to > the difficulty setting up Linux with a physical RAM base other than > 0x0. I was hoping that I could bypass that by re-arranging physical > memory using the BAT's or MMU. > I am gathering that while this is possible, that it not sufficient. > That if memory is re-arranged after power-on it has to be done by > something Linux is not aware of. I'm afraid you cannot fool Linux that way... it will take control of the BATs and MMU. Even as a concept, you cannot re-arrange physical memory with the MMU at all - it's virtual memory when you do the address translation. The only way to arrange physical memory is to program the memory controller. I don't know how flexible the OCM controller in ppc405 is, but I'd be surprised if one couldn't freely set the addresses to whatever suits best.
[PATCH] ppc32: replace use of _GLOBAL with .globl for ppc32
The _GLOBAL() macro is for text symbols only. Changed to using .globl for .data symbols. This is also needed in ppc32 land to allow FSL Book-E, 40x, and 44x to work. Signed-off-by: Kumar K. Gala --- commit ca6e6d7a599f8e8a5976c044910b98ef30258e30 tree d220cd916c8bdb6bb9c5ddbdfc2ecbfa5004cf89 parent a2084dccc9e9b0ccc5c40ed2f1273c82b23369d2 author Kumar K. Gala Tue, 18 Oct 2005 17:40:56 -0500 committer Kumar K. Gala Tue, 18 Oct 2005 17:40:56 -0500 arch/ppc/kernel/head_44x.S | 18 +++--- arch/ppc/kernel/head_4xx.S | 16 +++- arch/ppc/kernel/head_fsl_booke.S | 17 +++-- 3 files changed, 33 insertions(+), 18 deletions(-) diff --git a/arch/ppc/kernel/head_44x.S b/arch/ppc/kernel/head_44x.S --- a/arch/ppc/kernel/head_44x.S +++ b/arch/ppc/kernel/head_44x.S @@ -743,14 +743,18 @@ _GLOBAL(set_context) * goes at the beginning of the data segment, which is page-aligned. */ .data -_GLOBAL(sdata) -_GLOBAL(empty_zero_page) + .align 12 + .globl sdata +sdata: + .globl empty_zero_page +empty_zero_page: .space 4096 /* * To support >32-bit physical addresses, we use an 8KB pgdir. */ -_GLOBAL(swapper_pg_dir) + .globl swapper_pg_dir +swapper_pg_dir: .space 8192 /* Reserved 4k for the critical exception stack & 4k for the machine @@ -759,13 +763,15 @@ _GLOBAL(swapper_pg_dir) .align 12 exception_stack_bottom: .space BOOKE_EXCEPTION_STACK_SIZE -_GLOBAL(exception_stack_top) + .globl exception_stack_top +exception_stack_top: /* * This space gets a copy of optional info passed to us by the bootstrap * which is used to pass parameters into the kernel like root=/dev/sda1, etc. */ -_GLOBAL(cmd_line) + .globl cmd_line +cmd_line: .space 512 /* @@ -774,5 +780,3 @@ _GLOBAL(cmd_line) */ abatron_pteptrs: .space 8 - - diff --git a/arch/ppc/kernel/head_4xx.S b/arch/ppc/kernel/head_4xx.S --- a/arch/ppc/kernel/head_4xx.S +++ b/arch/ppc/kernel/head_4xx.S @@ -988,10 +988,14 @@ _GLOBAL(set_context) * goes at the beginning of the data segment, which is page-aligned. */ .data -_GLOBAL(sdata) -_GLOBAL(empty_zero_page) + .align 12 + .globl sdata +sdata: + .globl empty_zero_page +empty_zero_page: .space 4096 -_GLOBAL(swapper_pg_dir) + .globl swapper_pg_dir +swapper_pg_dir: .space 4096 @@ -1001,12 +1005,14 @@ _GLOBAL(swapper_pg_dir) exception_stack_bottom: .space 4096 critical_stack_top: -_GLOBAL(exception_stack_top) + .globl exception_stack_top +exception_stack_top: /* This space gets a copy of optional info passed to us by the bootstrap * which is used to pass parameters into the kernel like root=/dev/sda1, etc. */ -_GLOBAL(cmd_line) + .globl cmd_line +cmd_line: .space 512 /* Room for two PTE pointers, usually the kernel and current user pointers diff --git a/arch/ppc/kernel/head_fsl_booke.S b/arch/ppc/kernel/head_fsl_booke.S --- a/arch/ppc/kernel/head_fsl_booke.S +++ b/arch/ppc/kernel/head_fsl_booke.S @@ -1028,10 +1028,14 @@ _GLOBAL(set_context) * goes at the beginning of the data segment, which is page-aligned. */ .data -_GLOBAL(sdata) -_GLOBAL(empty_zero_page) + .align 12 + .globl sdata +sdata: + .globl empty_zero_page +empty_zero_page: .space 4096 -_GLOBAL(swapper_pg_dir) + .globl swapper_pg_dir +swapper_pg_dir: .space 4096 /* Reserved 4k for the critical exception stack & 4k for the machine @@ -1040,13 +1044,15 @@ _GLOBAL(swapper_pg_dir) .align 12 exception_stack_bottom: .space BOOKE_EXCEPTION_STACK_SIZE * NR_CPUS -_GLOBAL(exception_stack_top) + .globl exception_stack_top +exception_stack_top: /* * This space gets a copy of optional info passed to us by the bootstrap * which is used to pass parameters into the kernel like root=/dev/sda1, etc. */ -_GLOBAL(cmd_line) + .globl cmd_line +cmd_line: .space 512 /* @@ -1055,4 +1061,3 @@ _GLOBAL(cmd_line) */ abatron_pteptrs: .space 8 -
flash for lite5200
The Lite5200 has an official Port to 2.6 by Sylvain Munaut There is an Mapping MTD driver ready. if it's not in vanilla, you found a patchset on Mailign archive or on Sylvain's HP. Am Mon, 17 Oct 2005 18:42:53 +0200 schrieb Alessandro Rubini : > > Hello. > > I'm using linux-2.6.14-rc3-g4c234921 from denx, and I need to access > the flash device. While in 2.4 there is drivers/mtd/maps/icecube.c > (by Wolfgang Denk himself, it seems), I managed to see the flash > using the physmap driver and cmdline partitions. > > Does it make sense to add the correct MTD settings to > arch/ppc/configs/lite5200_defconfig (and some hints in > Documentation/powerpc/mpc52xx.txt) without porting the whole of > maps/icecube.c or is there a specific advantage in add a file in maps? > -- well, besides having sensible partitions already ported from 2.4? > > In either case, I'm willing to contribute the patch. > > These are the winning settings for me, but it doesn't cope with > lite5200 speciments with 8MBi of flash (are there any still around?) > [there's more than strictly needed, actually] > > CONFIG_MTD=y > CONFIG_MTD_PARTITIONS=y > CONFIG_MTD_CMDLINE_PARTS=y > CONFIG_MTD_CHAR=y > CONFIG_MTD_CFI=y > CONFIG_MTD_GEN_PROBE=y > CONFIG_MTD_MAP_BANK_WIDTH_1=y > CONFIG_MTD_MAP_BANK_WIDTH_2=y > CONFIG_MTD_MAP_BANK_WIDTH_4=y > CONFIG_MTD_CFI_I1=y > CONFIG_MTD_CFI_I2=y > CONFIG_MTD_CFI_INTELEXT=y > CONFIG_MTD_CFI_AMDSTD=y > CONFIG_MTD_CFI_AMDSTD_RETRY=0 > CONFIG_MTD_CFI_UTIL=y > > CONFIG_MTD_PHYSMAP=y > CONFIG_MTD_PHYSMAP_START=0xff00 > CONFIG_MTD_PHYSMAP_LEN=0x100 > CONFIG_MTD_PHYSMAP_BANKWIDTH=1 > > > /alessandro > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded at ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded >
[PATCH] ppc32: ppc_sys fixes for 8xx and 82xx
On Oct 18, 2005, at 10:24 AM, Marcelo Tosatti wrote: > For 8xx, I was wondering if the PARTNUM field of the IMMR > (section 10.4.1 of MPC860UM.pdf) does have meaningful > information which could be used to identify the CPU. It has meaningful information, but not the way you want to use it :-) The PARTNUM/MASKNUM is only useful once you know the type of processor (like 823, 850, 885, etc) The PARTNUM is only useful within the "family." For example, the 860 and 880 are two different families, and will contain the similar PARTNUM values through their life. I believe it's tied to the fabrication process. You may as well stop looking for an easy (or possibly any) way to differentiate these parts in software, but due to they way they are fabricated, I don't think that's ever going to happen. :-) -- Dan
Need help Understanding initial memory conditions.
Kalle Pokki wrote: > David H. Lynch Jr wrote: > >>What exactly is the minimal startup system state the Linux 2.6.13 >> Kernel expects ? > > > It's pretty hard to describe the system state fully, as there are so > many registers it may depend on. However, I can point out a few things > from your setup: > > 1. Put RAM to 0x000 and flash to some location it mirrors to your > boot vector. Linux always expects your physical memory to be at zero. > It is then mapped to virtual address 0xC000. In both this list and elsewhere I have seen several references to the difficulty setting up Linux with a physical RAM base other than 0x0. I was hoping that I could bypass that by re-arranging physical memory using the BAT's or MMU. I am gathering that while this is possible, that it not sufficient. That if memory is re-arranged after power-on it has to be done by something Linux is not aware of. > > 2. You don't need to have MMU enabled. There is a god. I am a compitent developer with lots of low level experience, but I have thus far completely missed out on both PPC assembler and memory management. > > 3. Make sure your boot arguments are passed properly to the kernel. > This includes the settings in registers r3 ... r7 and the bd_info > structure . There are many variants of that structure, make sure you > use the same ones in the boot loader and in Linux. That I should have no problem with. > > Thank You very much
[PATCH] ppc32: ppc_sys fixes for 8xx and 82xx
Hi Vitaly, > This patch fixes a numbers of issues regarding to that both 8xx and 82xx > began to use ppc_sys model: > - Platform is now identified by default deviceless SOC, if no > BOARD_CHIP_NAME is specified in the bard-specific header. For the list > of supported names refer to (arch/ppc/syslib/) mpc8xx_sys.c and > mpc82xx_sys.c for 8xx and 82xx respectively. > - Fixed a bug in identification by name - if the name was not found, > it returned -1 instead of default deviceless ppc_spec. > - fixed devices amount in the 8xx platform system descriptions Patch looks good. For 8xx, I was wondering if the PARTNUM field of the IMMR (section 10.4.1 of MPC860UM.pdf) does have meaningful information which could be used to identify the CPU.
Announce: MPC8272ADS platform support added to mpc8260sar project.
On Tue, Oct 18, 2005 at 09:47:30AM +0100, Alex Zeffertt wrote: > On Mon, 17 Oct 2005 11:44:41 -0700 > "Mark A. Greer" wrote: > > > On Mon, Oct 17, 2005 at 12:35:43PM +0100, Alex Zeffertt wrote: > > > Hi lists, > > > > > > I'm writing to let anybody (who may be interested) know that I've > > > added support for the MPC8272ADS platform to the mpc8260sar ATM > > > device driver: > > > > > > http://mpc8260sar.sourceforge.net > > > > There is already an ads8272_defconfig in the kernel.org tree and > > AFAIK it works. Did you add some functionality or change something? > > Or am I missing something? > > > > I've added support for this platform to the ATM driver. > ^ Oh, duh. Sorry 'bout that. Mark
Need help Understanding initial memory conditions.
David H. Lynch Jr wrote: >What exactly is the minimal startup system state the Linux 2.6.13 > Kernel expects ? It's pretty hard to describe the system state fully, as there are so many registers it may depend on. However, I can point out a few things from your setup: 1. Put RAM to 0x000 and flash to some location it mirrors to your boot vector. Linux always expects your physical memory to be at zero. It is then mapped to virtual address 0xC000. 2. You don't need to have MMU enabled. 3. Make sure your boot arguments are passed properly to the kernel. This includes the settings in registers r3 ... r7 and the bd_info structure . There are many variants of that structure, make sure you use the same ones in the boot loader and in Linux.
fs_enet driver - me too
Rune Torgersen wrote: > Does anybody have a working patchset for fs_enet for 2.6.12? > > The patches I've found on this list (and on ozlab's patch list) I > cannot get to compile. Any news? Regards, Peter
Announce: MPC8272ADS platform support added to mpc8260sar project.
On Mon, 17 Oct 2005 11:44:41 -0700 "Mark A. Greer" wrote: > On Mon, Oct 17, 2005 at 12:35:43PM +0100, Alex Zeffertt wrote: > > Hi lists, > > > > I'm writing to let anybody (who may be interested) know that I've > > added support for the MPC8272ADS platform to the mpc8260sar ATM > > device driver: > > > > http://mpc8260sar.sourceforge.net > > There is already an ads8272_defconfig in the kernel.org tree and > AFAIK it works. Did you add some functionality or change something? > Or am I missing something? > I've added support for this platform to the ATM driver. ^ Alex
Newbie... in mailing lists...
On Mon, 2005-10-17 at 14:24 +0200, Nathael PAJANI wrote: > I tried to reply to this thread: > http://ozlabs.org/pipermail/linuxppc-embedded/2005-October/020555.html > But it created a new one. not good. That's a problem with the archives; it's not your fault. If you look at the mailto: link at the top of that page, you see it looks like this: mailto:linuxppc-embedded%40ozlabs.org?Subject=eldk%203.1.1%20ramdisk%20image%20problem&In-Reply-To= Although it _attempts_ to set the In-Reply-To: header which would make your message appear to be a reply to the mail in the archive, it seems to be missing the actual message-id of that mail; it's just empty. > I tried to look for advices on posting and replying on the mailling list... > but the links given there: > https://ozlabs.org/mailman/listinfo/linuxppc-embedded > for the rules (http://lists.linuxppc.org/rules.html) and posting > guidlines (http://lists.linuxppc.org/guidelines.html) are down. The rules are fairly much the same everywhere -- not only for mailing lists but for email in general. Try http://david.woodhou.se/email.html if you think you need to read about it, perhaps. -- dwmw2
Need help Understanding initial memory conditions.
What exactly is the minimal startup system state the Linux 2.6.13 Kernel expects ? I am trying to bring up a xilinx V4 ppc 405 board. It has flash based at 0x0 and DRAM based at ox9800. I already have a working monitor/program loader and a filesystem of the flash. I can fairly easily compile and load onto the filesystem and run standalone PPC apps on the board. All memory is as configured by the base hardware. The MMU, BAT, ... are all at their powerup state. I have put together a Linux config based heavily on an abbreviated version of the Xilinx ML-300 config. If I try to load it it just goes bye-bye. I am trying to decipher the initial machine state Linux 2.6.13 expects. u-boot seems to completely setup the MMU, but also seems to expect to start execution from flash or ROM. scanning the Linux code seems to indicate that the only entry that needs to be setup for the MMU is the one for block Linux starts executing out of. I am also being somewhat confused by references to physical address 0 and virtual address 0xc00. I thought Linux executed from virtual address 0, and the actual physical address was a function of the hardware.
