* [PATCH 4/5 V2] Build hugetlb backed process stacks
From: Eric Munson @ 2008-07-28 19:17 UTC (permalink / raw)
To: linux-mm; +Cc: linuxppc-dev, libhugetlbfs-devel, linux-kernel, Eric Munson
In-Reply-To: <cover.1216928613.git.ebmunson@us.ibm.com>
This patch allows a processes stack to be backed by huge pages on request.
The personality flag defined in a previous patch should be set before
exec is called for the target process to use a huge page backed stack.
When the hugetlb file is setup to back the stack it is sized to fit the
ulimit for stack size or 256 MB if ulimit is unlimited. The GROWSUP and
GROWSDOWN VM flags are turned off because a hugetlb backed vma is not
resizable so it will be appropriately sized when created. When a process
exceeds stack size it recieves a segfault as it would if it exceeded the
ulimit.
Also certain architectures require special setup for a memory region before
huge pages can be used in that region. This patch defines a function with
__attribute__ ((weak)) set that can be defined by these architectures to
do any necessary setup. If it exists, it will be called right before the
hugetlb file is mmapped.
Signed-off-by: Eric Munson <ebmunson@us.ibm.com>
---
Based on 2.6.26-rc8-mm1
Changes from V1:
Add comment about not padding huge stacks
Break personality_page_align helper and personality flag into separate patch
Add move_to_huge_pages function that moves the stack onto huge pages
Add hugetlb_mm_setup weak function for archs that require special setup to
use hugetlb pages
Rebase to 2.6.26-rc8-mm1
fs/exec.c | 194 ++++++++++++++++++++++++++++++++++++++++++++---
include/linux/hugetlb.h | 5 +
2 files changed, 187 insertions(+), 12 deletions(-)
diff --git a/fs/exec.c b/fs/exec.c
index c99ba24..bf9ead2 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -50,6 +50,7 @@
#include <linux/cn_proc.h>
#include <linux/audit.h>
#include <linux/hugetlb.h>
+#include <linux/mman.h>
#include <asm/uaccess.h>
#include <asm/mmu_context.h>
@@ -59,6 +60,8 @@
#include <linux/kmod.h>
#endif
+#define HUGE_STACK_MAX (256*1024*1024)
+
#ifdef __alpha__
/* for /sbin/loader handling in search_binary_handler() */
#include <linux/a.out.h>
@@ -189,7 +192,12 @@ static struct page *get_arg_page(struct linux_binprm *bprm, unsigned long pos,
return NULL;
if (write) {
- unsigned long size = bprm->vma->vm_end - bprm->vma->vm_start;
+ /*
+ * Args are always placed at the high end of the stack space
+ * so this calculation will give the proper size and it is
+ * compatible with huge page stacks.
+ */
+ unsigned long size = bprm->vma->vm_end - pos;
struct rlimit *rlim;
/*
@@ -255,7 +263,10 @@ static int __bprm_mm_init(struct linux_binprm *bprm)
* configured yet.
*/
vma->vm_end = STACK_TOP_MAX;
- vma->vm_start = vma->vm_end - PAGE_SIZE;
+ if (current->personality & HUGETLB_STACK)
+ vma->vm_start = vma->vm_end - HPAGE_SIZE;
+ else
+ vma->vm_start = vma->vm_end - PAGE_SIZE;
vma->vm_flags = VM_STACK_FLAGS;
vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
@@ -574,6 +585,156 @@ static int shift_arg_pages(struct vm_area_struct *vma, unsigned long shift)
return 0;
}
+static struct file *hugetlb_stack_file(int stack_hpages)
+{
+ struct file *hugefile = NULL;
+
+ if (!stack_hpages) {
+ set_personality(current->personality & (~HUGETLB_STACK));
+ printk(KERN_DEBUG
+ "Stack rlimit set too low for huge page backed stack.\n");
+ return NULL;
+ }
+
+ hugefile = hugetlb_file_setup(HUGETLB_STACK_FILE,
+ HPAGE_SIZE * stack_hpages,
+ HUGETLB_PRIVATE_INODE);
+ if (unlikely(IS_ERR(hugefile))) {
+ /*
+ * If huge pages are not available for this stack fall
+ * fall back to normal pages for execution instead of
+ * failing.
+ */
+ printk(KERN_DEBUG
+ "Huge page backed stack unavailable for process %lu.\n",
+ (unsigned long)current->pid);
+ set_personality(current->personality & (~HUGETLB_STACK));
+ return NULL;
+ }
+ return hugefile;
+}
+
+static int move_to_huge_pages(struct linux_binprm *bprm,
+ struct vm_area_struct *vma, unsigned long shift)
+{
+ struct mm_struct *mm = vma->vm_mm;
+ struct vm_area_struct *new_vma;
+ unsigned long old_end = vma->vm_end;
+ unsigned long old_start = vma->vm_start;
+ unsigned long new_end = old_end - shift;
+ unsigned long new_start, length;
+ unsigned long arg_size = new_end - bprm->p;
+ unsigned long flags = vma->vm_flags;
+ struct file *hugefile = NULL;
+ unsigned int stack_hpages = 0;
+ struct page **from_pages = NULL;
+ struct page **to_pages = NULL;
+ unsigned long num_pages = (arg_size / PAGE_SIZE) + 1;
+ int ret;
+ int i;
+
+#ifdef CONFIG_STACK_GROWSUP
+ /*
+ * Huge page stacks are not currently supported on GROWSUP
+ * archs.
+ */
+ set_personality(current->personality & (~HUGETLB_STACK));
+#else
+ if (current->signal->rlim[RLIMIT_STACK].rlim_cur == _STK_LIM_MAX)
+ stack_hpages = HUGE_STACK_MAX / HPAGE_SIZE;
+ else
+ stack_hpages = current->signal->rlim[RLIMIT_STACK].rlim_cur /
+ HPAGE_SIZE;
+ hugefile = hugetlb_stack_file(stack_hpages);
+ if (!hugefile)
+ goto out_small_stack;
+
+ length = stack_hpages * HPAGE_SIZE;
+ new_start = new_end - length;
+
+ from_pages = kmalloc(num_pages * sizeof(struct page*), GFP_KERNEL);
+ to_pages = kmalloc(num_pages * sizeof(struct page*), GFP_KERNEL);
+ if (!from_pages || !to_pages)
+ goto out_small_stack;
+
+ ret = get_user_pages(current, mm, (old_end - arg_size) & PAGE_MASK,
+ num_pages, 0, 0, from_pages, NULL);
+ if (ret <= 0)
+ goto out_small_stack;
+
+ /*
+ * __do_munmap is used here because the boundary checking done in
+ * do_munmap will fail out every time where the kernel is 64 bit and the
+ * target program is 32 bit as the stack will start at TASK_SIZE for the
+ * 64 bit address space.
+ */
+ ret = __do_munmap(mm, old_start, old_end - old_start);
+ if (ret)
+ goto out_small_stack;
+
+ ret = -EINVAL;
+ if (hugetlb_mm_setup)
+ hugetlb_mm_setup(mm, new_start, length);
+ if (IS_ERR_VALUE(do_mmap(hugefile, new_start, length,
+ PROT_READ | PROT_WRITE, MAP_FIXED | MAP_PRIVATE, 0)))
+ goto out_error;
+ /* We don't want to fput this if the mmap succeeded */
+ hugefile = NULL;
+
+ ret = get_user_pages(current, mm, (new_end - arg_size) & PAGE_MASK,
+ num_pages, 0, 0, to_pages, NULL);
+ if (ret <= 0) {
+ ret = -ENOMEM;
+ goto out_error;
+ }
+
+ for (i = 0; i < num_pages; i++) {
+ char *vfrom, *vto;
+ vfrom = kmap(from_pages[i]);
+ vto = kmap(to_pages[i]);
+ memcpy(vto, vfrom, PAGE_SIZE);
+ kunmap(from_pages[i]);
+ kunmap(to_pages[i]);
+ put_page(from_pages[i]);
+ put_page(to_pages[i]);
+ }
+
+ kfree(from_pages);
+ kfree(to_pages);
+ new_vma = find_vma(current->mm, new_start);
+ if (!new_vma)
+ return -ENOSPC;
+ new_vma->vm_flags |= flags;
+ new_vma->vm_flags &= ~(VM_GROWSUP|VM_GROWSDOWN);
+ new_vma->vm_page_prot = vm_get_page_prot(new_vma->vm_flags);
+
+ bprm->vma = new_vma;
+ return 0;
+
+out_error:
+ for (i = 0; i < num_pages; i++)
+ put_page(from_pages[i]);
+ if (hugefile)
+ fput(hugefile);
+ if (from_pages)
+ kfree(from_pages);
+ if (to_pages)
+ kfree(to_pages);
+ return ret;
+
+out_small_stack:
+ if (hugefile)
+ fput(hugefile);
+ if (from_pages)
+ kfree(from_pages);
+ if (to_pages)
+ kfree(to_pages);
+#endif /* !CONFIG_STACK_GROWSUP */
+ if (shift)
+ return shift_arg_pages(vma, shift);
+ return 0;
+}
+
#define EXTRA_STACK_VM_PAGES 20 /* random */
/*
@@ -640,23 +801,32 @@ int setup_arg_pages(struct linux_binprm *bprm,
goto out_unlock;
BUG_ON(prev != vma);
+ /* Move stack to hugetlb pages if requested */
+ if (current->personality & HUGETLB_STACK)
+ ret = move_to_huge_pages(bprm, vma, stack_shift);
/* Move stack pages down in memory. */
- if (stack_shift) {
+ else if (stack_shift)
ret = shift_arg_pages(vma, stack_shift);
- if (ret) {
- up_write(&mm->mmap_sem);
- return ret;
- }
+
+ if (ret) {
+ up_write(&mm->mmap_sem);
+ return ret;
}
+ /*
+ * Stack padding code is skipped for huge stacks because the vma
+ * is not expandable when backed by a hugetlb file.
+ */
+ if (!(current->personality & HUGETLB_STACK)) {
#ifdef CONFIG_STACK_GROWSUP
- stack_base = vma->vm_end + EXTRA_STACK_VM_PAGES * PAGE_SIZE;
+ stack_base = vma->vm_end + EXTRA_STACK_VM_PAGES * PAGE_SIZE;
#else
- stack_base = vma->vm_start - EXTRA_STACK_VM_PAGES * PAGE_SIZE;
+ stack_base = vma->vm_start - EXTRA_STACK_VM_PAGES * PAGE_SIZE;
#endif
- ret = expand_stack(vma, stack_base);
- if (ret)
- ret = -EFAULT;
+ ret = expand_stack(vma, stack_base);
+ if (ret)
+ ret = -EFAULT;
+ }
out_unlock:
up_write(&mm->mmap_sem);
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 26ffed9..b4c88bb 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -110,6 +110,11 @@ static inline unsigned long hugetlb_total_pages(void)
#define HUGETLB_RESERVE 0x00000002UL /* Reserve the huge pages backed by the
* new file */
+#define HUGETLB_STACK_FILE "hugetlb-stack"
+
+extern void hugetlb_mm_setup(struct mm_struct *mm, unsigned long addr,
+ unsigned long len) __attribute__ ((weak));
+
#ifdef CONFIG_HUGETLBFS
struct hugetlbfs_config {
uid_t uid;
--
1.5.6.1
^ permalink raw reply related
* [RFC] [PATCH 0/5 V2] Huge page backed user-space stacks
From: Eric Munson @ 2008-07-28 19:17 UTC (permalink / raw)
To: linux-mm; +Cc: linuxppc-dev, libhugetlbfs-devel, linux-kernel, Eric Munson
Certain workloads benefit if their data or text segments are backed by
huge pages. The stack is no exception to this rule but there is no
mechanism currently that allows the backing of a stack reliably with
huge pages. Doing this from userspace is excessively messy and has some
awkward restrictions. Particularly on POWER where 256MB of address space
gets wasted if the stack is setup there.
This patch stack introduces a personality flag that indicates the kernel
should setup the stack as a hugetlbfs-backed region. A userspace utility
may set this flag then exec a process whose stack is to be backed by
hugetlb pages.
Eric Munson (5):
Align stack boundaries based on personality
Add shared and reservation control to hugetlb_file_setup
Split boundary checking from body of do_munmap
Build hugetlb backed process stacks
[PPC] Setup stack memory segment for hugetlb pages
arch/powerpc/mm/hugetlbpage.c | 6 +
arch/powerpc/mm/slice.c | 11 ++
fs/exec.c | 209 ++++++++++++++++++++++++++++++++++++++---
fs/hugetlbfs/inode.c | 52 +++++++----
include/asm-powerpc/hugetlb.h | 3 +
include/linux/hugetlb.h | 22 ++++-
include/linux/mm.h | 1 +
include/linux/personality.h | 3 +
ipc/shm.c | 2 +-
mm/mmap.c | 11 ++-
10 files changed, 284 insertions(+), 36 deletions(-)
^ permalink raw reply
* Re: [PATCH 2/2] leds: Support OpenFirmware led bindings
From: Trent Piepho @ 2008-07-28 19:11 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Stephen Rothwell, linux-kernel, linuxppc-dev, Richard Purdie
In-Reply-To: <20080728185103.GA25343@polina.dev.rtsoft.ru>
On Mon, 28 Jul 2008, Anton Vorontsov wrote:
> On Mon, Jul 28, 2008 at 11:26:28AM -0700, Trent Piepho wrote:
>> On Mon, 28 Jul 2008, Anton Vorontsov wrote:
>>> On Mon, Jul 28, 2008 at 11:09:14AM -0600, Grant Likely wrote:
>>> [...]
>>>>>>> +- function : (optional) This parameter, if present, is a string
>>>>>>> + defining the function of the LED. It can be used to put the LED
>>>>>>> + under software control, e.g. Linux LED triggers like "heartbeat",
>>>>>>> + "ide-disk", and "timer". Or it could be used to attach a hardware
>>>>>>> + signal to the LED, e.g. a SoC that can configured to put a SATA
>>>>>>> + activity signal on a GPIO line.
>>>>>>
>>>>>> This makes me nervous. It exposes Linux internal implementation details
>>>>>> into the device tree data. If you want to have a property that
>>>>>> describes the LED usage, then the possible values and meanings should be
>>>>>> documented here.
>>>>>
>>>>> Should it be a linux specific property then? I could list all the current
>>>>> linux triggers, but enumerating every possible function someone might want
>>>>> to assign to an LED seems hopeless.
>>>>
>>>> I'd rather see the device tree provide 'hints' toward the expected usage
>>>> and if a platform needs something specific, then the platform specific
>>>> code should setup the trigger.
>>>>
>>> Maybe we can encode leds into devices themselves, via phandles?
>>
>> How will this work for anything besides ide activity? For example, flashing,
>> heartbeat, default on, overheat, fan failed, kernel panic, etc.
>
> Everything is possible, but will look weird. For example,
>
> Default on (power led) could be encoded in the root node.
> fan and overheat in a PM controller's node.
> Kernel panic in the chosen node.
What about flashing? What if the sensor chip isn't an OF device?
>>> And then the OF GPIO LEDs driver could do something like:
>>>
>>> char *ide_disk_trigger_compatibles[] = {
>>> "fsl,sata",
>>> "ide-generic",
>>> ...
>>> };
>>
>> Everytime someone added a new ide driver, this table would have to be updated.
>
> Yes. device_type would be helpful here. :-)
>
>
> Well, otherwise, we could provide a trigger map in the chosen node:
>
> chosen {
> /* leds map: default-on, ide-disk, nand-disk, panic */
> linux,leds = <&green_led &red_led 0 0>;
> };
What if you have multiple leds that you want to be default on? What happens
when new functions are added?
^ permalink raw reply
* Re: MPC8323RDB BSP on Kernel2.4
From: Paul Gortmaker @ 2008-07-28 19:05 UTC (permalink / raw)
To: mike zheng; +Cc: linuxppc-dev
In-Reply-To: <5c9cd53b0807281144y72c0bb2bre69db29288c8e5a8@mail.gmail.com>
On Mon, Jul 28, 2008 at 2:44 PM, mike zheng <mail4mz@gmail.com> wrote:
> Hi All,
>
> Is the any MPC8323RDB BSP on Kernel 2.4? I have the BSP on Kernel 2.6
> provided by Freescale. Unfortunate we are using Kernel2.4. Is there
> any exist BSP of this board on Kernel2.4? Or a BSP of similar board on
> Kernel2.4?
Generally speaking, most of these more modern eval boards from
Freescale have been supported only since post 2.6.15 or so, and as
such are implemented as arch/powerpc and not the older/obsolete
arch/ppc (as what was used in 2.4). Trying to graft them onto a
2.4 kernel sounds like a lot of wasted cycles to me. You may have
to revisit your reasoning for requiring a 2.4 kernel.
Paul.
>
> Thanks in advance,
>
> Mike
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* linux kernel for ppc as elf relocatable
From: mihaela elena grigore @ 2008-07-28 18:34 UTC (permalink / raw)
To: linuxppc-dev
Can somebody help me with a few indications regarding how to obtain a
relocatable vmlinux when compiling the linux kernel for ppc32 ?
For powerpc, by default, the building process results in an ELF 32-bit
MSB executable statically linked. I saw that for other architectures it
builds, by default, a relocatable elf file.
Why is it statically linked for some architectures and relocatable for
others ? How to make it relocatable for ppc32? I assume that changing
LDFLAGS_vmlinux to '-r' in the Makefile for ppc is not enough... (i'm
using 2.6.11)
p.s. any comments/answers to my posting, please add me in CC, as i
didn't subscribe, thank you.
^ permalink raw reply
* Re: [PATCH 2/2] leds: Support OpenFirmware led bindings
From: Anton Vorontsov @ 2008-07-28 18:51 UTC (permalink / raw)
To: Trent Piepho; +Cc: Stephen Rothwell, linux-kernel, linuxppc-dev, Richard Purdie
In-Reply-To: <Pine.LNX.4.64.0807281120150.26456@t2.domain.actdsltmp>
On Mon, Jul 28, 2008 at 11:26:28AM -0700, Trent Piepho wrote:
> On Mon, 28 Jul 2008, Anton Vorontsov wrote:
> > On Mon, Jul 28, 2008 at 11:09:14AM -0600, Grant Likely wrote:
> > [...]
> >>>>> +- function : (optional) This parameter, if present, is a string
> >>>>> + defining the function of the LED. It can be used to put the LED
> >>>>> + under software control, e.g. Linux LED triggers like "heartbeat",
> >>>>> + "ide-disk", and "timer". Or it could be used to attach a hardware
> >>>>> + signal to the LED, e.g. a SoC that can configured to put a SATA
> >>>>> + activity signal on a GPIO line.
> >>>>
> >>>> This makes me nervous. It exposes Linux internal implementation details
> >>>> into the device tree data. If you want to have a property that
> >>>> describes the LED usage, then the possible values and meanings should be
> >>>> documented here.
> >>>
> >>> Should it be a linux specific property then? I could list all the current
> >>> linux triggers, but enumerating every possible function someone might want
> >>> to assign to an LED seems hopeless.
> >>
> >> I'd rather see the device tree provide 'hints' toward the expected usage
> >> and if a platform needs something specific, then the platform specific
> >> code should setup the trigger.
> >>
> > Maybe we can encode leds into devices themselves, via phandles?
>
> How will this work for anything besides ide activity? For example, flashing,
> heartbeat, default on, overheat, fan failed, kernel panic, etc.
Everything is possible, but will look weird. For example,
Default on (power led) could be encoded in the root node.
fan and overheat in a PM controller's node.
Kernel panic in the chosen node.
> > And then the OF GPIO LEDs driver could do something like:
> >
> > char *ide_disk_trigger_compatibles[] = {
> > "fsl,sata",
> > "ide-generic",
> > ...
> > };
>
> Everytime someone added a new ide driver, this table would have to be updated.
Yes. device_type would be helpful here. :-)
Well, otherwise, we could provide a trigger map in the chosen node:
chosen {
/* leds map: default-on, ide-disk, nand-disk, panic */
linux,leds = <&green_led &red_led 0 0>;
};
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 2/2] leds: Support OpenFirmware led bindings
From: Grant Likely @ 2008-07-28 18:49 UTC (permalink / raw)
To: Trent Piepho; +Cc: Stephen Rothwell, linux-kernel, linuxppc-dev, Richard Purdie
In-Reply-To: <Pine.LNX.4.64.0807281120150.26456@t2.domain.actdsltmp>
On Mon, Jul 28, 2008 at 11:26:28AM -0700, Trent Piepho wrote:
> On Mon, 28 Jul 2008, Anton Vorontsov wrote:
> > On Mon, Jul 28, 2008 at 11:09:14AM -0600, Grant Likely wrote:
> > [...]
> >>>>> +- function : (optional) This parameter, if present, is a string
> >>>>> + defining the function of the LED. It can be used to put the LED
> >>>>> + under software control, e.g. Linux LED triggers like "heartbeat",
> >>>>> + "ide-disk", and "timer". Or it could be used to attach a hardware
> >>>>> + signal to the LED, e.g. a SoC that can configured to put a SATA
> >>>>> + activity signal on a GPIO line.
> >>>>
> >>>> This makes me nervous. It exposes Linux internal implementation details
> >>>> into the device tree data. If you want to have a property that
> >>>> describes the LED usage, then the possible values and meanings should be
> >>>> documented here.
> >>>
> >>> Should it be a linux specific property then? I could list all the current
> >>> linux triggers, but enumerating every possible function someone might want
> >>> to assign to an LED seems hopeless.
> >>
> >> I'd rather see the device tree provide 'hints' toward the expected usage
> >> and if a platform needs something specific, then the platform specific
> >> code should setup the trigger.
> >>
> > Maybe we can encode leds into devices themselves, via phandles?
>
> How will this work for anything besides ide activity? For example, flashing,
> heartbeat, default on, overheat, fan failed, kernel panic, etc.
It certainly doesn't work for everything; but where it does work it
makes a lot of sense because the property position provides a lot of
context.
>
> > And then the OF GPIO LEDs driver could do something like:
> >
> > char *ide_disk_trigger_compatibles[] = {
> > "fsl,sata",
> > "ide-generic",
> > ...
> > };
>
> Everytime someone added a new ide driver, this table would have to be updated.
Yes, the implementation needs thought.
g.
^ permalink raw reply
* [PATCH] Documentation: remove old sbc8260 board specific information
From: Paul Gortmaker @ 2008-07-28 18:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Gortmaker, rob
This file contains 8 yr. old board specific information that was for
the now gone ppc implementation, and it pre-dates widespread u-boot
support. Any of the technical details of the board memory map would be
more appropriately captured in a dts if I revive it as powerpc anyway.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: Jason Wessel <jason.wessel@windriver.com>
---
Documentation/powerpc/00-INDEX | 2 -
Documentation/powerpc/SBC8260_memory_mapping.txt | 197 ----------------------
2 files changed, 0 insertions(+), 199 deletions(-)
delete mode 100644 Documentation/powerpc/SBC8260_memory_mapping.txt
diff --git a/Documentation/powerpc/00-INDEX b/Documentation/powerpc/00-INDEX
index 3be84aa..29d839c 100644
--- a/Documentation/powerpc/00-INDEX
+++ b/Documentation/powerpc/00-INDEX
@@ -20,8 +20,6 @@ mpc52xx-device-tree-bindings.txt
- MPC5200 Device Tree Bindings
ppc_htab.txt
- info about the Linux/PPC /proc/ppc_htab entry
-SBC8260_memory_mapping.txt
- - EST SBC8260 board info
smp.txt
- use and state info about Linux/PPC on MP machines
sound.txt
diff --git a/Documentation/powerpc/SBC8260_memory_mapping.txt b/Documentation/powerpc/SBC8260_memory_mapping.txt
deleted file mode 100644
index e6e9ee0..0000000
--- a/Documentation/powerpc/SBC8260_memory_mapping.txt
+++ /dev/null
@@ -1,197 +0,0 @@
-Please mail me (Jon Diekema, diekema_jon@si.com or diekema@cideas.com)
-if you have questions, comments or corrections.
-
- * EST SBC8260 Linux memory mapping rules
-
- http://www.estc.com/
- http://www.estc.com/products/boards/SBC8260-8240_ds.html
-
- Initial conditions:
- -------------------
-
- Tasks that need to be perform by the boot ROM before control is
- transferred to zImage (compressed Linux kernel):
-
- - Define the IMMR to 0xf0000000
-
- - Initialize the memory controller so that RAM is available at
- physical address 0x00000000. On the SBC8260 is this 16M (64M)
- SDRAM.
-
- - The boot ROM should only clear the RAM that it is using.
-
- The reason for doing this is to enhances the chances of a
- successful post mortem on a Linux panic. One of the first
- items to examine is the 16k (LOG_BUF_LEN) circular console
- buffer called log_buf which is defined in kernel/printk.c.
-
- - To enhance boot ROM performance, the I-cache can be enabled.
-
- Date: Mon, 22 May 2000 14:21:10 -0700
- From: Neil Russell <caret@c-side.com>
-
- LiMon (LInux MONitor) runs with and starts Linux with MMU
- off, I-cache enabled, D-cache disabled. The I-cache doesn't
- need hints from the MMU to work correctly as the D-cache
- does. No D-cache means no special code to handle devices in
- the presence of cache (no snooping, etc). The use of the
- I-cache means that the monitor can run acceptably fast
- directly from ROM, rather than having to copy it to RAM.
-
- - Build the board information structure (see
- include/asm-ppc/est8260.h for its definition)
-
- - The compressed Linux kernel (zImage) contains a bootstrap loader
- that is position independent; you can load it into any RAM,
- ROM or FLASH memory address >= 0x00500000 (above 5 MB), or
- at its link address of 0x00400000 (4 MB).
-
- Note: If zImage is loaded at its link address of 0x00400000 (4 MB),
- then zImage will skip the step of moving itself to
- its link address.
-
- - Load R3 with the address of the board information structure
-
- - Transfer control to zImage
-
- - The Linux console port is SMC1, and the baud rate is controlled
- from the bi_baudrate field of the board information structure.
- On thing to keep in mind when picking the baud rate, is that
- there is no flow control on the SMC ports. I would stick
- with something safe and standard like 19200.
-
- On the EST SBC8260, the SMC1 port is on the COM1 connector of
- the board.
-
-
- EST SBC8260 defaults:
- ---------------------
-
- Chip
- Memory Sel Bus Use
- --------------------- --- --- ----------------------------------
- 0x00000000-0x03FFFFFF CS2 60x (16M or 64M)/64M SDRAM
- 0x04000000-0x04FFFFFF CS4 local 4M/16M SDRAM (soldered to the board)
- 0x21000000-0x21000000 CS7 60x 1B/64K Flash present detect (from the flash SIMM)
- 0x21000001-0x21000001 CS7 60x 1B/64K Switches (read) and LEDs (write)
- 0x22000000-0x2200FFFF CS5 60x 8K/64K EEPROM
- 0xFC000000-0xFCFFFFFF CS6 60x 2M/16M flash (8 bits wide, soldered to the board)
- 0xFE000000-0xFFFFFFFF CS0 60x 4M/16M flash (SIMM)
-
- Notes:
- ------
-
- - The chip selects can map 32K blocks and up (powers of 2)
-
- - The SDRAM machine can handled up to 128Mbytes per chip select
-
- - Linux uses the 60x bus memory (the SDRAM DIMM) for the
- communications buffers.
-
- - BATs can map 128K-256Mbytes each. There are four data BATs and
- four instruction BATs. Generally the data and instruction BATs
- are mapped the same.
-
- - The IMMR must be set above the kernel virtual memory addresses,
- which start at 0xC0000000. Otherwise, the kernel may crash as
- soon as you start any threads or processes due to VM collisions
- in the kernel or user process space.
-
-
- Details from Dan Malek <dan_malek@mvista.com> on 10/29/1999:
-
- The user application virtual space consumes the first 2 Gbytes
- (0x00000000 to 0x7FFFFFFF). The kernel virtual text starts at
- 0xC0000000, with data following. There is a "protection hole"
- between the end of kernel data and the start of the kernel
- dynamically allocated space, but this space is still within
- 0xCxxxxxxx.
-
- Obviously the kernel can't map any physical addresses 1:1 in
- these ranges.
-
-
- Details from Dan Malek <dan_malek@mvista.com> on 5/19/2000:
-
- During the early kernel initialization, the kernel virtual
- memory allocator is not operational. Prior to this KVM
- initialization, we choose to map virtual to physical addresses
- 1:1. That is, the kernel virtual address exactly matches the
- physical address on the bus. These mappings are typically done
- in arch/ppc/kernel/head.S, or arch/ppc/mm/init.c. Only
- absolutely necessary mappings should be done at this time, for
- example board control registers or a serial uart. Normal device
- driver initialization should map resources later when necessary.
-
- Although platform dependent, and certainly the case for embedded
- 8xx, traditionally memory is mapped at physical address zero,
- and I/O devices above physical address 0x80000000. The lowest
- and highest (above 0xf0000000) I/O addresses are traditionally
- used for devices or registers we need to map during kernel
- initialization and prior to KVM operation. For this reason,
- and since it followed prior PowerPC platform examples, I chose
- to map the embedded 8xx kernel to the 0xc0000000 virtual address.
- This way, we can enable the MMU to map the kernel for proper
- operation, and still map a few windows before the KVM is operational.
-
- On some systems, you could possibly run the kernel at the
- 0x80000000 or any other virtual address. It just depends upon
- mapping that must be done prior to KVM operational. You can never
- map devices or kernel spaces that overlap with the user virtual
- space. This is why default IMMR mapping used by most BDM tools
- won't work. They put the IMMR at something like 0x10000000 or
- 0x02000000 for example. You simply can't map these addresses early
- in the kernel, and continue proper system operation.
-
- The embedded 8xx/82xx kernel is mature enough that all you should
- need to do is map the IMMR someplace at or above 0xf0000000 and it
- should boot far enough to get serial console messages and KGDB
- connected on any platform. There are lots of other subtle memory
- management design features that you simply don't need to worry
- about. If you are changing functions related to MMU initialization,
- you are likely breaking things that are known to work and are
- heading down a path of disaster and frustration. Your changes
- should be to make the flexibility of the processor fit Linux,
- not force arbitrary and non-workable memory mappings into Linux.
-
- - You don't want to change KERNELLOAD or KERNELBASE, otherwise the
- virtual memory and MMU code will get confused.
-
- arch/ppc/Makefile:KERNELLOAD = 0xc0000000
-
- include/asm-ppc/page.h:#define PAGE_OFFSET 0xc0000000
- include/asm-ppc/page.h:#define KERNELBASE PAGE_OFFSET
-
- - RAM is at physical address 0x00000000, and gets mapped to
- virtual address 0xC0000000 for the kernel.
-
-
- Physical addresses used by the Linux kernel:
- --------------------------------------------
-
- 0x00000000-0x3FFFFFFF 1GB reserved for RAM
- 0xF0000000-0xF001FFFF 128K IMMR 64K used for dual port memory,
- 64K for 8260 registers
-
-
- Logical addresses used by the Linux kernel:
- -------------------------------------------
-
- 0xF0000000-0xFFFFFFFF 256M BAT0 (IMMR: dual port RAM, registers)
- 0xE0000000-0xEFFFFFFF 256M BAT1 (I/O space for custom boards)
- 0xC0000000-0xCFFFFFFF 256M BAT2 (RAM)
- 0xD0000000-0xDFFFFFFF 256M BAT3 (if RAM > 256MByte)
-
-
- EST SBC8260 Linux mapping:
- --------------------------
-
- DBAT0, IBAT0, cache inhibited:
-
- Chip
- Memory Sel Use
- --------------------- --- ---------------------------------
- 0xF0000000-0xF001FFFF n/a IMMR: dual port RAM, registers
-
- DBAT1, IBAT1, cache inhibited:
-
--
1.5.6.2
^ permalink raw reply related
* MPC8323RDB BSP on Kernel2.4
From: mike zheng @ 2008-07-28 18:44 UTC (permalink / raw)
To: linuxppc-dev
Hi All,
Is the any MPC8323RDB BSP on Kernel 2.4? I have the BSP on Kernel 2.6
provided by Freescale. Unfortunate we are using Kernel2.4. Is there
any exist BSP of this board on Kernel2.4? Or a BSP of similar board on
Kernel2.4?
Thanks in advance,
Mike
^ permalink raw reply
* Re: [PATCH 2/2] leds: Support OpenFirmware led bindings
From: Trent Piepho @ 2008-07-28 18:26 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Stephen Rothwell, linux-kernel, linuxppc-dev, Richard Purdie
In-Reply-To: <20080728180204.GA13190@polina.dev.rtsoft.ru>
On Mon, 28 Jul 2008, Anton Vorontsov wrote:
> On Mon, Jul 28, 2008 at 11:09:14AM -0600, Grant Likely wrote:
> [...]
>>>>> +- function : (optional) This parameter, if present, is a string
>>>>> + defining the function of the LED. It can be used to put the LED
>>>>> + under software control, e.g. Linux LED triggers like "heartbeat",
>>>>> + "ide-disk", and "timer". Or it could be used to attach a hardware
>>>>> + signal to the LED, e.g. a SoC that can configured to put a SATA
>>>>> + activity signal on a GPIO line.
>>>>
>>>> This makes me nervous. It exposes Linux internal implementation details
>>>> into the device tree data. If you want to have a property that
>>>> describes the LED usage, then the possible values and meanings should be
>>>> documented here.
>>>
>>> Should it be a linux specific property then? I could list all the current
>>> linux triggers, but enumerating every possible function someone might want
>>> to assign to an LED seems hopeless.
>>
>> I'd rather see the device tree provide 'hints' toward the expected usage
>> and if a platform needs something specific, then the platform specific
>> code should setup the trigger.
>>
> Maybe we can encode leds into devices themselves, via phandles?
How will this work for anything besides ide activity? For example, flashing,
heartbeat, default on, overheat, fan failed, kernel panic, etc.
> And then the OF GPIO LEDs driver could do something like:
>
> char *ide_disk_trigger_compatibles[] = {
> "fsl,sata",
> "ide-generic",
> ...
> };
Everytime someone added a new ide driver, this table would have to be updated.
^ permalink raw reply
* Re: mpc8349-mITX DTB load failure
From: Kim Phillips @ 2008-07-28 18:30 UTC (permalink / raw)
To: Sparks, Sam; +Cc: linuxppc-dev
In-Reply-To: <6011A7C9CD0EE74792C3ED2A8355608634213E@mail.twacs.com>
On Mon, 28 Jul 2008 11:10:47 -0500
"Sparks, Sam" <SSparks@aclaratech.com> wrote:
> ## Booting kernel from Legacy Image at 01001000 ...
> ## Flattened Device Tree blob at 01000000
so the dtb is being loaded only 0x1000 bytes from the kernel, yet it's
probably bigger than that. Can you try different load addresses,
preferably with the two images at least 0x3000 bytes apart?
Kim
^ permalink raw reply
* RE: mpc8349-mITX DTB load failure
From: Sparks, Sam @ 2008-07-28 18:16 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <20080728180241.GD21534@secretlab.ca>
> From: Grant Likely
> Sent: Monday, July 28, 2008 1:03 PM
> Does your dts source file already have a chosen node? There=20
> had been an issue where u-boot cacks if chosen was pre-created.
Nope, there is no reference to "chosen" in the dts
--Sam
^ permalink raw reply
* Re: [PATCH 2/2] leds: Support OpenFirmware led bindings
From: Grant Likely @ 2008-07-28 18:06 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Stephen Rothwell, linux-kernel, linuxppc-dev, Richard Purdie,
Trent Piepho
In-Reply-To: <20080728180204.GA13190@polina.dev.rtsoft.ru>
On Mon, Jul 28, 2008 at 10:02:04PM +0400, Anton Vorontsov wrote:
> On Mon, Jul 28, 2008 at 11:09:14AM -0600, Grant Likely wrote:
> > I'd rather see the device tree provide 'hints' toward the expected usage
> > and if a platform needs something specific, then the platform specific
> > code should setup the trigger.
> >
> > Regardless, any hints provided by the binding must be documented. In
> > most cases the gpio-leds driver should be able to figure out which trigger
> > to bind without platform code intervention.
>
> Maybe we can encode leds into devices themselves, via phandles?
>
> E.g.
>
> sata@101 {
> compatible = "fsl,sata";
> leds = <&red_led>;
> };
I like that idea! That neatly solves the problem for many use cases.
> And then the OF GPIO LEDs driver could do something like:
>
> char *ide_disk_trigger_compatibles[] = {
> "fsl,sata",
> "ide-generic",
> ...
> };
>
> for_each_node_with_leds_property(node, led_phandle) {
> if (if_ide_disk_compatible(node)) {
> struct gpio_led *led = phandle_to_led(led_phandle);
>
> led->default_trigger = "ide-disk";
> }
> }
I'm not sure what would be best for implementation details, but
implementation details can easily be changed.
>
> --
> Anton Vorontsov
> email: cbouatmailru@gmail.com
> irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: mpc8349-mITX DTB load failure
From: Grant Likely @ 2008-07-28 18:02 UTC (permalink / raw)
To: Sparks, Sam; +Cc: linuxppc-dev
In-Reply-To: <6011A7C9CD0EE74792C3ED2A8355608634214C@mail.twacs.com>
On Mon, Jul 28, 2008 at 12:49:19PM -0500, Sparks, Sam wrote:
> No luck there, either. I ran into a issue with space a year ago, and was
> getting the FDT_ERR_NOSPACE error until I added the -S 0x3000 option.
> This looks like something completely different.
Does your dts source file already have a chosen node? There had been an
issue where u-boot cacks if chosen was pre-created.
g.
^ permalink raw reply
* Re: [PATCH 2/2] leds: Support OpenFirmware led bindings
From: Anton Vorontsov @ 2008-07-28 18:02 UTC (permalink / raw)
To: Grant Likely
Cc: Stephen Rothwell, linux-kernel, linuxppc-dev, Richard Purdie,
Trent Piepho
In-Reply-To: <20080728170914.GA21265@secretlab.ca>
On Mon, Jul 28, 2008 at 11:09:14AM -0600, Grant Likely wrote:
[...]
> > >> +- function : (optional) This parameter, if present, is a string
> > >> + defining the function of the LED. It can be used to put the LED
> > >> + under software control, e.g. Linux LED triggers like "heartbeat",
> > >> + "ide-disk", and "timer". Or it could be used to attach a hardware
> > >> + signal to the LED, e.g. a SoC that can configured to put a SATA
> > >> + activity signal on a GPIO line.
> > >
> > > This makes me nervous. It exposes Linux internal implementation details
> > > into the device tree data. If you want to have a property that
> > > describes the LED usage, then the possible values and meanings should be
> > > documented here.
> >
> > Should it be a linux specific property then? I could list all the current
> > linux triggers, but enumerating every possible function someone might want
> > to assign to an LED seems hopeless.
>
> I don't like adding Linux specific properties to the device tree if at
> all possible, and I really don't like encoding Linux internal details
> (like trigger names). They can change between kernel versions and
> breaking compatibility with older device trees is strongly avoided.
> That's why so much effort goes into getting bindings correct the first
> time.
>
> I'd rather see the device tree provide 'hints' toward the expected usage
> and if a platform needs something specific, then the platform specific
> code should setup the trigger.
>
> Regardless, any hints provided by the binding must be documented. In
> most cases the gpio-leds driver should be able to figure out which trigger
> to bind without platform code intervention.
Maybe we can encode leds into devices themselves, via phandles?
E.g.
sata@101 {
compatible = "fsl,sata";
leds = <&red_led>;
};
And then the OF GPIO LEDs driver could do something like:
char *ide_disk_trigger_compatibles[] = {
"fsl,sata",
"ide-generic",
...
};
for_each_node_with_leds_property(node, led_phandle) {
if (if_ide_disk_compatible(node)) {
struct gpio_led *led = phandle_to_led(led_phandle);
led->default_trigger = "ide-disk";
}
}
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* RE: mpc8349-mITX DTB load failure
From: Sparks, Sam @ 2008-07-28 17:49 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <20080728171634.GB21265@secretlab.ca>
> From: Grant Likely
> Sent: Monday, July 28, 2008 12:17 PM
>=20
> On Mon, Jul 28, 2008 at 11:10:47AM -0500, Sparks, Sam wrote:
> > Hello All,
> >=20
> > I am trying to boot the mpc8349-mITX board with Compact=20
> flash support,=20
> > and am unable to boot the Linux kernel. Here is the pertinant=20
> > versioning
> > information:
> > DTC 1.2.0-rc2-g17773b0e
> > U-Boot 1.3.4-rc1-00012-g1953d12
> > Linux-2.6.26-05752-g93ded9b
> >=20
> > I've built the DTB using the following two commands -=20
> neither change=20
> > the error I get during boot-up.
> > $ ../dtc/dtc -b 0 -I dts -O dtb -R 4 -S 0x3000 -o=20
> > /tftproot/ssparks/itx/cf2/itx.dtb -V 17=20
> > arch/powerpc/boot/dts/mpc8349emitx.dts
> > $ ../dtc/dtc -I dts -O dtb -o /tftproot/ssparks/itx/cf2/itx2.dtb
> > arch/powerpc/boot/dts/mpc8349emitx.dts
>=20
> Try adding "-p 0x3000" to ensure that you get padding to the blob.
>=20
> g.
>=20
No luck there, either. I ran into a issue with space a year ago, and was
getting the FDT_ERR_NOSPACE error until I added the -S 0x3000 option.
This looks like something completely different.
Thanks tho,
Sam
^ permalink raw reply
* Re: mpc744x, Marvell mv6446x kernel guidance please
From: Mark A. Greer @ 2008-07-28 16:51 UTC (permalink / raw)
To: Stephen Horton; +Cc: linuxppc-embedded
In-Reply-To: <295C5089A56CE143B316E5F67CA99CB001C9E4BD@cowboy.inovate.inovate.com>
On Thu, Jul 10, 2008 at 10:46:49PM -0500, Stephen Horton wrote:
> Hello folks,
>
> In a current work project, I have inherited a compactPCI board that has
> an mpc7447/7448 powerpc processor as well as a Marvell system
> controller, model mv64462 (stripped down mv64460). The board has a
> somewhat working Gentoo Linux port running on it from long ago and a
> company far far away (kernel version 2.6.9 built using arch/ppc). To
> prepare for an upcoming deployment, I would like to bring the OS
> up-to-date on this board with a newer kernel (targeting Gentoo 2008),
> but I am unsure of the approach to take. I am a software developer, but
> normally do not work on kernel porting / board integration. I have
> researched the arch/ppc to arch/powerpc migration, but I'm a bit
> intimidated by the 'new' device tree symantics and other changes to the
> stream. Here are some questions:
>
> 1. Is it possible with the 2.6.24 (Gentoo 2008) kernel to still use
> arch/ppc for this platform architecture? I've tried to get this to
> compile, but am having trouble with files from arch/powerpc getting
> pulled in; then I read some comments (from I believe this forum) that
> indicated that arch/ppc is not longer supposed to compile
arch/ppc is gone now. You should spend you effort working in
arch/powerpc.
> 2. Does anyone have example code for this platform architecture?
> Any freebees I could use for creating my device tree?
You can use prpmc2800 as an example.
> 3. Any advice of any kind?
Its not as bad as it looks. Just dig into it and don't give up.
Mark
^ permalink raw reply
* Re: mpc8349-mITX DTB load failure
From: Grant Likely @ 2008-07-28 17:16 UTC (permalink / raw)
To: Sparks, Sam; +Cc: linuxppc-dev
In-Reply-To: <6011A7C9CD0EE74792C3ED2A8355608634213E@mail.twacs.com>
On Mon, Jul 28, 2008 at 11:10:47AM -0500, Sparks, Sam wrote:
> Hello All,
>
> I am trying to boot the mpc8349-mITX board with Compact flash support,
> and am unable to boot the Linux kernel. Here is the pertinant versioning
> information:
> DTC 1.2.0-rc2-g17773b0e
> U-Boot 1.3.4-rc1-00012-g1953d12
> Linux-2.6.26-05752-g93ded9b
>
> I've built the DTB using the following two commands - neither change the
> error I get during boot-up.
> $ ../dtc/dtc -b 0 -I dts -O dtb -R 4 -S 0x3000 -o
> /tftproot/ssparks/itx/cf2/itx.dtb -V 17
> arch/powerpc/boot/dts/mpc8349emitx.dts
> $ ../dtc/dtc -I dts -O dtb -o /tftproot/ssparks/itx/cf2/itx2.dtb
> arch/powerpc/boot/dts/mpc8349emitx.dts
Try adding "-p 0x3000" to ensure that you get padding to the blob.
g.
^ permalink raw reply
* Re: [PATCH 2/2] leds: Support OpenFirmware led bindings
From: Grant Likely @ 2008-07-28 17:09 UTC (permalink / raw)
To: Trent Piepho; +Cc: Stephen Rothwell, linux-kernel, linuxppc-dev, Richard Purdie
In-Reply-To: <Pine.LNX.4.64.0807272159500.26456@t2.domain.actdsltmp>
On Mon, Jul 28, 2008 at 01:31:47AM -0700, Trent Piepho wrote:
> On Sat, 26 Jul 2008, Grant Likely wrote:
> > On Fri, Jul 25, 2008 at 02:01:45PM -0700, Trent Piepho wrote:
> >> Add bindings to support LEDs defined as of_platform devices in addition to
> >> the existing bindings for platform devices.
> >
> >> +- gpios : Should specify the LED GPIO.
> >
> > Question: it is possible/desirable for a single LED to be assigned
> > multiple GPIO pins? Say, for a tri-color LED? (I'm fishing for
> > opinions; I really don't know if it would be a good idea or not)
>
> Good question. The Linux LED layer has no concept of multi-color LEDs, so
> it's more difficult that just adding support to the gpio led driver. I have
> a device with a tri-color red/green/orange LED and this posed some
> difficulty. It's defined as independent red and greed LEDs, which is mostly
> fine, except I wanted it to flash orange. I can make both the red LED and
> green LED flash, but there is nothing to insure their flashing remains in
> sync.
>
> Other OF bindings allow multiple GPIOs to be listed in a gpios property, so
> that's not a problem if someone wants to do that. There would need to be a
> way to define what the gpios mean. I don't think it's worthwhile to come up
> with a binding for that until there is a real user.
True. The binding can be extended at a later date anyway. It might be
as simple as adding an array of strings that define what each gpio value
means. ie. if 2 gpio lines are used for a led, then that maps to
numbers in the range [0, 1, 2, 3]. It could be encoded thus:
led-states = "off", "green", "red", "orange";
The driver would then need to interpret/adapt these strings to something
useful in the LED driver. Just a thought.
> >> +- function : (optional) This parameter, if present, is a string
> >> + defining the function of the LED. It can be used to put the LED
> >> + under software control, e.g. Linux LED triggers like "heartbeat",
> >> + "ide-disk", and "timer". Or it could be used to attach a hardware
> >> + signal to the LED, e.g. a SoC that can configured to put a SATA
> >> + activity signal on a GPIO line.
> >
> > This makes me nervous. It exposes Linux internal implementation details
> > into the device tree data. If you want to have a property that
> > describes the LED usage, then the possible values and meanings should be
> > documented here.
>
> Should it be a linux specific property then? I could list all the current
> linux triggers, but enumerating every possible function someone might want
> to assign to an LED seems hopeless.
I don't like adding Linux specific properties to the device tree if at
all possible, and I really don't like encoding Linux internal details
(like trigger names). They can change between kernel versions and
breaking compatibility with older device trees is strongly avoided.
That's why so much effort goes into getting bindings correct the first
time.
I'd rather see the device tree provide 'hints' toward the expected usage
and if a platform needs something specific, then the platform specific
code should setup the trigger.
Regardless, any hints provided by the binding must be documented. In
most cases the gpio-leds driver should be able to figure out which trigger
to bind without platform code intervention.
g.
^ permalink raw reply
* Re: [RFC,PATCH] scripts/package: add powerpc images to tarball
From: Grant Likely @ 2008-07-28 16:49 UTC (permalink / raw)
To: T Ziomek; +Cc: linuxppc-dev, linux-kernel, Milton Miller, Jeremy Kerr
In-Reply-To: <20080728163435.GE27068@email.mot.com>
On Mon, Jul 28, 2008 at 11:34:35AM -0500, T Ziomek wrote:
> On Sat, Jul 26, 2008 at 01:53:57PM -0400, Grant Likely wrote:
> . . .
> > Come to think of it, I'd support just removing the zImage symlink
> > entirely to eliminate confusion so that everyone knows that 'make
> > zImage' is the 'make all' for default image targets.
>
> That ("zImage" means all default image targets) seems pretty non-intui-
> tive; why not something like 'make all_def_images'?
It is purely historical. zImage and modules have been the default
make targets for a long time. I'm not opposed to changing it, but it is
a change that affects almost everyone. I'd like to see some consensus
before going down this path.
g.
^ permalink raw reply
* Re: [PATCH v3 0/4 REPOST] OF infrastructure for SPI devices
From: Grant Likely @ 2008-07-28 16:39 UTC (permalink / raw)
To: David Brownell; +Cc: spi-devel-general, akpm, linux-kernel, linuxppc-dev
In-Reply-To: <200807271449.28472.david-b@pacbell.net>
On Sun, Jul 27, 2008 at 02:49:28PM -0700, David Brownell wrote:
> On Friday 25 July 2008, Grant Likely wrote:
> > I don't know what to do with these patches. I'd really like to see them
> > in .27, and now that akpm has cleared his queue, the prerequisite patch
> > has been merged so they are ready to go in. However, even though there
> > has been favourable reception on the SPI and linuxppc lists for these
> > changes I don't have any acks from anybody yet.
> >
> > David, can you please reply on if you are okay with these patches
> > getting merged? If so, do you want me to merge them via my tree, or
> > do you want to pick them up?
>
> OK ... to recap, #1 and #3 are OF-specific, I'll be agnostic.
> If other OF folk think it's OK, great.
>
> Some cleanup was needed for #2, but it was basically ok ...
> I'd like to see the final version, and if it goes via an
> OF push that's OK by me. (Though I'd like to see that change
> make it into 2.6.27 regardless, so let me know.)
Thanks for the review. 1-3 is already merged into my git tree and Ben
has pulled them. I hope that's okay. Here's a link to the commit:
http://git.kernel.org/?p=linux/kernel/git/benh/powerpc.git;a=commitdiff;h=dc87c98e8f635a718f1abb2c3e15fc77c0001651
Let me know if you see anything else that needs to be changed and I'll
submit a fixup patch.
> And #4 isn't quite cooked yet.
Okay, I'll hack on this more and post v4.
Thanks again,
g.
^ permalink raw reply
* Re: [RFC,PATCH] scripts/package: add powerpc images to tarball
From: T Ziomek @ 2008-07-28 16:34 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, linux-kernel, Milton Miller, Jeremy Kerr
In-Reply-To: <fa686aa40807261053r5a8ebe40l7e8061f926f185f9@mail.gmail.com>
On Sat, Jul 26, 2008 at 01:53:57PM -0400, Grant Likely wrote:
. . .
> Come to think of it, I'd support just removing the zImage symlink
> entirely to eliminate confusion so that everyone knows that 'make
> zImage' is the 'make all' for default image targets.
That ("zImage" means all default image targets) seems pretty non-intui-
tive; why not something like 'make all_def_images'?
Tom
--
/"\ ASCII Ribbon Campaign |
\ / | Email to user 'CTZ001'
X Against HTML | at 'email.mot.com'
/ \ in e-mail & news |
^ permalink raw reply
* Re: Changing Mac address
From: Grant Likely @ 2008-07-28 16:24 UTC (permalink / raw)
To: Guillaume Dargaud; +Cc: linuxppc-dev
In-Reply-To: <106201c8f0bd$dda4f640$ad289e86@LPSC0173W>
On Mon, Jul 28, 2008 at 04:25:54PM +0200, Guillaume Dargaud wrote:
> Hello all,
> there's something I miss here. I'd like to setup a MAC address in
> software at the start of the boot process. I'm trying to figure out where
> this is done in the kernel code.
> I'm on a custom variant of a Xilinx ML405 card, still in PPC arch.
> So it appears to be going in the arch/ppc/boot/simple/embed_config.c
Yes, this is the correct location to set it. Do whatever you need to
set a different MAC address.
In arch/powerpc this all goes away and you can just set it in the device
tree.
g.
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git merge branch
From: Grant Likely @ 2008-07-28 16:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev, Stephen Rothwell, akpm, Linux Kernel list
In-Reply-To: <alpine.LFD.1.10.0807280905500.3486@nehalem.linux-foundation.org>
On Mon, Jul 28, 2008 at 09:06:35AM -0700, Linus Torvalds wrote:
>
>
> On Tue, 29 Jul 2008, Stephen Rothwell wrote:
> >
> > It should be
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
> >
> > Ben seems to have copied from one of Paul's pull requests.
>
> Ok, that one worked for me.
>
> Ben, I'm sure some day you'll get it right on the first try. We're all
> cheering for you!
Ben! Ben! He's our man! If he can't grok it, no-one can! :-)
git-request-pull has saved me from many a bogus pull request.
g.
^ permalink raw reply
* mpc8349-mITX DTB load failure
From: Sparks, Sam @ 2008-07-28 16:10 UTC (permalink / raw)
To: linuxppc-dev
Hello All,
I am trying to boot the mpc8349-mITX board with Compact flash support,
and am unable to boot the Linux kernel. Here is the pertinant versioning
information:
DTC 1.2.0-rc2-g17773b0e
U-Boot 1.3.4-rc1-00012-g1953d12
Linux-2.6.26-05752-g93ded9b
I've built the DTB using the following two commands - neither change the
error I get during boot-up.
$ ../dtc/dtc -b 0 -I dts -O dtb -R 4 -S 0x3000 -o
/tftproot/ssparks/itx/cf2/itx.dtb -V 17
arch/powerpc/boot/dts/mpc8349emitx.dts
$ ../dtc/dtc -I dts -O dtb -o /tftproot/ssparks/itx/cf2/itx2.dtb
arch/powerpc/boot/dts/mpc8349emitx.dts
Can anyone shed any light onto what I am doing to cause the following
error? I haven't been able to find this error message in the mailing
list or by asking google...
## Booting kernel from Legacy Image at 01001000 ...
Image Name: Linux-2.6.26-05752-g93ded9b
Created: 2008-07-24 20:40:59 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1708661 Bytes =3D 1.6 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Flattened Device Tree blob at 01000000
Booting using the fdt blob at 0x1000000
Loading Device Tree to 007fb000, end 007ff526 ... OK
WARNING: could not create /chosen FDT_ERR_BADSTRUCTURE.
ERROR: /chosen node create failed - must RESET the board to recover.
Resetting the board.
Thanks for the help,
Sam
^ 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