* Cannot mount root file system using nfs.
From: rakesh bk @ 2008-02-13 10:56 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 4165 bytes --]
Hi EveryOne,
I am new to Xenomai , I have ported linux-2.6.14 to our custom board
based on IBM750Cxe Iam unable to boot my kernel cross compiled with eldk-3.0with
enabled xenomai support.If i remove xenomai and ipipe support the kernel
boots correctly , but if i enable CONFIG_IPIPE I get stuck in the before
mounting the root file system .
The following patches are applied and arguements of scripts/prepare-
kernel.sh is mentioned as follows
adeos-ipipe-2.6.14-ppc-1.3-05.patch,
Target architecture [default i686]: ppc
Adeos patch[default linux-2.6.14/xenomai-2.2.0
/ksrc/arch/powerpc/patches/adeos-ipipe-2.6.14-ppc64-1.2-03.patch]:
adeos-ipipe-2.6.14-ppc-1.3-05.patch,
## Booting image at 00800000 ...
Image Name: Linux-2.6.14
Created: 2008-02-13 8:23:56 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1568257 Bytes = 1.5 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
initrd != NULL ea100000
outside initrd
root=/dev/nfs rw nfsroot=192.168.50.92:/home/eldk/ppc_7xx ip=
192.168.50.39:192.168.50.92:192.168.50.92::ATSLinux:eth0:none c
onsole=ttyS0,9600 ip1=off
## Transferring control to Linux (at address 00000000) ...
Total memory = 128MB; using 256kB for hash table (at a03c0000)
Linux version 2.6.14 (root@localhost.localdomain) (gcc version
3.2.220030217 (Yellow Dog Linux
3.0 3.2.2-2a_1)) #38 PREEMPT
Wed Feb 13 13:53:52 IST 2008
Kernel command line: root=/dev/nfs rw nfsroot=
192.168.50.92:/home/eldk/ppc_7xx ip=192.168.50.39:192.168.50.92:
192.168.50.92:
:ATSLinux:eth0:none console=ttyS0,9600 ip1=off
Initializing init_irq
PID hash table entries: 1024 (order: 10, 16384 bytes)
time_init: decrementer frequency = 17.000000 MHz
Warning: real time clock seems stuck!
I-pipe 1.3-05: pipeline enabled.
Console: colour dummy device 80x25
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 125696k available (2588k kernel code, 960k data, 156k init, 0k
highmem)
Mount-cache hash table entries: 512
softlockup thread 0 started up.
NET: Registered protocol family 16
PCI: Probing PCI hardware
Xenomai: ALTIVEC support enabled in kernel but no hardware found.
Disable CONFIG_ALTIVEC in the kernel configuration.
Xenomai: system init failed, code -19.
Xenomai: native skin init failed, code -19.
Xenomai: starting POSIX services.
Xenomai: POSIX skin init failed, code -19.
Xenomai: RTDM skin init failed, code -19.
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
Initializing Cryptographic API
Generic RTC Driver v1.07
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
ttyS0 at MMIO 0x0 (irq = 85) is a 16550A
ttyS1 at MMIO 0x0 (irq = 86) is a 16550A
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
nbd: registered device at major 43
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
mice: PS/2 mouse device common for all mice
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 3, 32768 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 15
gt64260_eth_open : Assigned IRQ 32 to gt64260_eth0
eth0: MII said 3, GT said 9, restarting autoneg
eth0: link state:
GT:100: Link:HD:nFC
mii:100: Link:FD: FC ANc:AN
IP-Config: Guessing netmask 255.255.255.0
IP-Config: Complete:
device=eth0, addr=192.168.50.39, mask=255.255.255.0, gw=192.168.50.92,
host=ATSLinux, domain=, nis-domain=(none),
bootserver=192.168.50.92, rootserver=192.168.50.92, rootpath=
Looking up port of RPC 100003/2 on 192.168.50.92
[-- Attachment #2: Type: text/html, Size: 5360 bytes --]
^ permalink raw reply
* Re: [PATCH 00/18] ide: warm-plug support for IDE devices and other goodies
From: Gabriel Paubert @ 2008-02-13 10:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-ide, linux-kernel, Bartlomiej Zolnierkiewicz, linuxppc-dev
In-Reply-To: <20080212123002.GA11000@iram.es>
On Tue, Feb 12, 2008 at 01:30:03PM +0100, Gabriel Paubert wrote:
> On Tue, Feb 12, 2008 at 12:49:05PM +0100, Gabriel Paubert wrote:
> > On Fri, Feb 08, 2008 at 07:40:43PM +1100, Benjamin Herrenschmidt wrote:
> > >
> > > On Fri, 2008-02-08 at 01:44 +0100, Bartlomiej Zolnierkiewicz wrote:
> > > > - couple of fixes and preparatory patches
> > > >
> > > > - rework of PowerMac media-bay support ([un]register IDE devices instead of
> > > > [un]registering IDE interface) [ it is the main reason for spamming PPC ML ]
> > >
> > > Interesting... I was thinking about doing a full remove of the device at
> > > a higher level instead but I suppose what you propose is easier.
> >
> > Well, I have serious problem on a Pegasos which appeared some time
> > between 2.6.24 and 2.6.25-rc1: at boot I get an infinite string of
> >
> > hdb: empty DMA table?
> >
> > I'm trying to bisect it right now.
>
> Argh, the first bisect point ended up with timeouts on hdb...
>
> Flagged as bad, to try to see when the problems started, but
> I suspect that there are several.
Well, it's worse than this. After 7 or 8 bisections (all flagged
bad) the symptoms changed: the system boots up to the point where
it does not recognize LVM volumes. So there are at least 3 bugs:
1) the timeout on interrupts (only seen on hdb)
2) the empty DMA table messages (seen on hda and hdb)
3) the inability to see logical volumes ("pvs" does not find them,
they are back when rebooting into 2.6.24). This is the apparently
the earliest introduced bug (no problems with the disks with that
version).
I am away from that machine until next Tuesday. IIRC the last git
bisect was something like 160 revisions left.
Gabriel
>
> Gabriel
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* V4 FX12 and PLB TEMAC: no space for user logic?
From: llandre @ 2008-02-13 9:32 UTC (permalink / raw)
To: mamsadegh; +Cc: linuxppc-embedded
Hi Mohammad,
I've just had a look at the messages you generously posted in the ml
about your experience with linux on V4 FX12 FPGA.
I'd like to ask your opinion about FX12 practical usability in this
context (gigabit PLB TEMAC/linux).
In this message
http://article.gmane.org/gmane.linux.ports.ppc.embedded/16816
you say the device is completely full. If I understand correctly your
system provides just the devices required to run the bandwidth test so
it seems there is no room for user logic (I think you did not even add
the memory controller required to access the NOR Flash containing
bootloader, kernel image and root fs that is clearly mandatory for
standalone product). Is that true? If it is, this limits a lot the
flexibility of this architecture in this configuration. What do you think?
Regards,
llandre
DAVE Electronics System House - R&D Department
web: http://www.dave.eu
email: r&d2@dave-tech.it
^ permalink raw reply
* Re: [GIT]: Make LMB code sharable with sparc64.
From: David Miller @ 2008-02-13 9:05 UTC (permalink / raw)
To: sam; +Cc: sparclinux, linuxppc-dev, linux-kernel
In-Reply-To: <20080213085735.GB8091@uranus.ravnborg.org>
From: Sam Ravnborg <sam@ravnborg.org>
Date: Wed, 13 Feb 2008 09:57:35 +0100
> Review had been easier if the patch was inlined.
Sorry :)
> Can we plase have this changed to use:
>
> config SPARC64
> + select HAVE_LMB
>
> And then in lib/Kconfig have
> +config HAVE_LMB
> + bool
>
> So we avoid creating a new variable each time we introdce LMB support.
> You would need to update powerpc Kconfig too of course.
Sure, I'll rework this in the next day or so to do things
that way.
Thanks for the review.
^ permalink raw reply
* Re: [GIT]: Make LMB code sharable with sparc64.
From: Sam Ravnborg @ 2008-02-13 8:57 UTC (permalink / raw)
To: David Miller; +Cc: sparclinux, linuxppc-dev, linux-kernel
In-Reply-To: <20080213.004120.22092044.davem@davemloft.net>
On Wed, Feb 13, 2008 at 12:41:20AM -0800, David Miller wrote:
>
> As I mentioned to a few ppc folks at LCA08 I plan to use
> the LMB code from powerpc as a basis for NUMA support on
> sparc64.
>
> There are two changes.
>
> 1) Move arch/powerpc/mm/lmb.c to lib/lmb.c, put the main
> interface bits in include/linux/lmb.h, put arch-specific
> bits in asm/lmb.h and add Kconfig machinery to build this
> stuff on sparc64.
>
> 2) Fix a bug in lmb_alloc() wherein the size was not aligned
> so we could easily run out of reserve blocks because
> every aligned allocation would create a tiny hole, and
> secondly the lmb_reserve() call there did not have it's
> return value checked.
>
> Powerpc folks, if there are no objections please pull, thanks!
>
> The following changes since commit 96b5a46e2a72dc1829370c87053e0cd558d58bc0:
> Linus Torvalds (1):
> WMI: initialize wmi_blocks.list even if ACPI is disabled
>
> are available in the git repository at:
>
> master.kernel.org:/pub/scm/linux/kernel/git/davem/lmb-2.6.git master
Review had been easier if the patch was inlined.
Took a quick look at the small Kconfig bits.
>From arch/sparc64/Kconfig:
+config LMB
+ def_bool y
+
Can we plase have this changed to use:
config SPARC64
+ select HAVE_LMB
And then in lib/Kconfig have
+config HAVE_LMB
+ bool
So we avoid creating a new variable each time we introdce LMB support.
You would need to update powerpc Kconfig too of course.
This way of doing it is documented in:
Documenation/kbuild/kconfig.language.txt
Thanks,
Sam
^ permalink raw reply
* [GIT]: Make LMB code sharable with sparc64.
From: David Miller @ 2008-02-13 8:41 UTC (permalink / raw)
To: linuxppc-dev; +Cc: sparclinux, linux-kernel
As I mentioned to a few ppc folks at LCA08 I plan to use
the LMB code from powerpc as a basis for NUMA support on
sparc64.
There are two changes.
1) Move arch/powerpc/mm/lmb.c to lib/lmb.c, put the main
interface bits in include/linux/lmb.h, put arch-specific
bits in asm/lmb.h and add Kconfig machinery to build this
stuff on sparc64.
2) Fix a bug in lmb_alloc() wherein the size was not aligned
so we could easily run out of reserve blocks because
every aligned allocation would create a tiny hole, and
secondly the lmb_reserve() call there did not have it's
return value checked.
Powerpc folks, if there are no objections please pull, thanks!
The following changes since commit 96b5a46e2a72dc1829370c87053e0cd558d58bc0:
Linus Torvalds (1):
WMI: initialize wmi_blocks.list even if ACPI is disabled
are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/davem/lmb-2.6.git master
David S. Miller (2):
[LIB]: Make PowerPC LMB code generic so sparc64 can use it too.
[LMB]: Fix bug in __lmb_alloc_base().
arch/powerpc/Kconfig | 3 +
arch/powerpc/kernel/btext.c | 2 +-
arch/powerpc/kernel/crash.c | 2 +-
arch/powerpc/kernel/crash_dump.c | 2 +-
arch/powerpc/kernel/machine_kexec.c | 2 +-
arch/powerpc/kernel/prom.c | 2 +-
arch/powerpc/kernel/rtas.c | 2 +-
arch/powerpc/kernel/setup-common.c | 2 +-
arch/powerpc/kernel/setup_64.c | 2 +-
arch/powerpc/kernel/vdso.c | 2 +-
arch/powerpc/mm/Makefile | 2 +-
arch/powerpc/mm/hash_utils_64.c | 2 +-
arch/powerpc/mm/init_32.c | 2 +-
arch/powerpc/mm/init_64.c | 2 +-
arch/powerpc/mm/mem.c | 2 +-
arch/powerpc/mm/numa.c | 2 +-
arch/powerpc/mm/ppc_mmu_32.c | 2 +-
arch/powerpc/mm/stab.c | 2 +-
arch/powerpc/platforms/cell/iommu.c | 2 +-
arch/powerpc/platforms/maple/setup.c | 2 +-
arch/powerpc/platforms/powermac/setup.c | 2 +-
arch/powerpc/platforms/ps3/htab.c | 2 +-
arch/powerpc/platforms/ps3/mm.c | 2 +-
arch/powerpc/platforms/ps3/os-area.c | 2 +-
arch/powerpc/sysdev/dart_iommu.c | 2 +-
arch/sparc64/Kconfig | 3 +
include/asm-powerpc/abs_addr.h | 2 +-
include/asm-powerpc/lmb.h | 82 +++---------------------------
include/asm-sparc64/lmb.h | 10 ++++
include/linux/lmb.h | 83 +++++++++++++++++++++++++++++++
lib/Makefile | 2 +
{arch/powerpc/mm => lib}/lmb.c | 39 ++++++++-------
32 files changed, 155 insertions(+), 117 deletions(-)
create mode 100644 include/asm-sparc64/lmb.h
create mode 100644 include/linux/lmb.h
rename {arch/powerpc/mm => lib}/lmb.c (92%)
^ permalink raw reply
* TEMAC on Virtex FX12: device occupation
From: llandre @ 2008-02-13 8:36 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I'd like to hear some opinions about this post by Massimiliano:
http://article.gmane.org/gmane.linux.ports.ppc.embedded/17568
The results he got are quite impressive. It seems that everybody here
can hardly fit a design with just one hard TEMAC in FX12 while he was
able to fit two! Unfortunately Massimiliano did not say precisely how he
did it. I'd like to hear someone from Xilinx sharing his/her opinion
about this outstanding result. Maybe he used 3rd-party synthesizer or he
discovered some magical command-line parameters for Xilinx synthesizer ...
Any comment will be appreciated.
Regards,
llandre
DAVE Electronics System House - R&D Department
web: http://www.dave.eu
email: r&d2@dave-tech.it
^ permalink raw reply
* Quit the mailling list
From: 조은상 @ 2008-02-13 7:30 UTC (permalink / raw)
To: Linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 56 bytes --]
Thanks for help
Please Let me quit the list
Thank you
[-- Attachment #2: Type: text/html, Size: 301 bytes --]
^ permalink raw reply
* Re: [PATCH 09/18] ide: rework PowerMac media-bay support
From: Michael Ellerman @ 2008-02-13 7:29 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: linux-ide, linux-kernel, linuxppc-dev
In-Reply-To: <20080208004523.17746.24578.sendpatchset@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 2599 bytes --]
On Fri, 2008-02-08 at 01:45 +0100, Bartlomiej Zolnierkiewicz wrote:
> Rework PowerMac media-bay support in such way that instead of
> un/registering the IDE interface we un/register IDE devices:
>
> * Add ide_port_scan() helper for probing+registerering devices on a port.
>
> * Rename ide_port_unregister_devices() to __ide_port_unregister_devices().
>
> * Add ide_port_unregister_devices() helper for unregistering devices on a port.
>
> * Add 'ide_hwif_t *cd_port' to 'struct media_bay_info', pass 'hwif' instead
> of hwif->index to media_bay_set_ide_infos() and use it to setup 'cd_port'.
>
> * Use ide_port_unregister_devices() instead of ide_unregister()
> and ide_port_scan() instead of ide_register_hw() in media_bay_step().
>
> * Unexport ide_register_hw() and make it static.
>
> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> ---
> drivers/ide/ide-probe.c | 18 ++++++++++++++++++
> drivers/ide/ide.c | 22 ++++++++++++++++------
> drivers/ide/ppc/pmac.c | 3 ++-
> drivers/macintosh/mediabay.c | 17 +++++++----------
> include/asm-powerpc/mediabay.h | 4 +++-
> include/linux/ide.h | 6 ++----
> 6 files changed, 48 insertions(+), 22 deletions(-)
> Index: b/include/asm-powerpc/mediabay.h
> ===================================================================
> --- a/include/asm-powerpc/mediabay.h
> +++ b/include/asm-powerpc/mediabay.h
> @@ -22,10 +22,12 @@ int check_media_bay(struct device_node *
> /* Number of bays in the machine or 0 */
> extern int media_bay_count;
>
> +#ifdef CONFIG_BLK_DEV_IDE_PMAC
> int check_media_bay_by_base(unsigned long base, int what);
> /* called by IDE PMAC host driver to register IDE controller for media bay */
> int media_bay_set_ide_infos(struct device_node *which_bay, unsigned long base,
> - int irq, int index);
> + int irq, ide_hwif_t *hwif);
> +#endif
>
> #endif /* __KERNEL__ */
> #endif /* _PPC_MEDIABAY_H */
This hunk breaks pmac32_defconfig for me.
include2/asm/mediabay.h:29: error: syntax error before 'ide_hwif_t'
make[3]: *** [arch/powerpc/platforms/powermac/setup.o] Error 1
make[2]: *** [arch/powerpc/platforms/powermac] Error 2
make[1]: *** [arch/powerpc/platforms] Error 2
make: *** [sub-make] Error 2
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] FIx compile of swim3 as module
From: Benjamin Herrenschmidt @ 2008-02-13 6:03 UTC (permalink / raw)
To: Josh Boyer
Cc: Bartlomiej Zolnierkiewicz, kyle, LinuxPPC-dev, Paul Mackerras,
Andrew Morton, Linus Torvalds
In-Reply-To: <20080212204802.18a7a868@zod.rchland.ibm.com>
On Tue, 2008-02-12 at 20:48 -0600, Josh Boyer wrote:
> > The current pmac32_defconfig fails to build with the following
> error:
> >
> > Building modules, stage 2.
> > ERROR: "check_media_bay" [drivers/block/swim3.ko] undefined!
> > WARNING: modpost: Found 23 section mismatch(es).
> > To see full details build your kernel with:
> > 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
> > make[2]: *** [__modpost] Error 1
> >
> > This patch fixes that.
>
> Kyle posted a slightly different patch that seemed to still keep
> the original intention of ifdefery in tact. I've no idea which is
> better, but the three of you might want to compare notes.
Just remove the bloody ifdef's, they are just a useless pain.
Ben.
^ permalink raw reply
* Re: [PATCH] FIx compile of swim3 as module
From: Benjamin Herrenschmidt @ 2008-02-13 3:26 UTC (permalink / raw)
To: Tony Breeds
Cc: LinuxPPC-dev, Andrew Morton, Linus Torvalds,
Bartlomiej Zolnierkiewicz, Paul Mackerras
In-Reply-To: <20080213024019.GX6887@bakeyournoodle.com>
On Wed, 2008-02-13 at 13:40 +1100, Tony Breeds wrote:
> The current pmac32_defconfig fails to build with the following error:
>
> Building modules, stage 2.
> ERROR: "check_media_bay" [drivers/block/swim3.ko] undefined!
> WARNING: modpost: Found 23 section mismatch(es).
> To see full details build your kernel with:
> 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
> make[2]: *** [__modpost] Error 1
Bart, I told you I didn't want those ifdef's in mediabay ... they are
just cluttering things and causing trouble.
> This patch fixes that.
>
> Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> drivers/block/swim3.c | 4 ----
> drivers/macintosh/mediabay.c | 2 --
> 2 files changed, 0 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/block/swim3.c b/drivers/block/swim3.c
> index b4e462f..730ccea 100644
> --- a/drivers/block/swim3.c
> +++ b/drivers/block/swim3.c
> @@ -251,10 +251,6 @@ static int floppy_release(struct inode *inode, struct file *filp);
> static int floppy_check_change(struct gendisk *disk);
> static int floppy_revalidate(struct gendisk *disk);
>
> -#ifndef CONFIG_PMAC_MEDIABAY
> -#define check_media_bay(which, what) 1
> -#endif
> -
> static void swim3_select(struct floppy_state *fs, int sel)
> {
> struct swim3 __iomem *sw = fs->swim3;
> diff --git a/drivers/macintosh/mediabay.c b/drivers/macintosh/mediabay.c
> index 9367882..51a1128 100644
> --- a/drivers/macintosh/mediabay.c
> +++ b/drivers/macintosh/mediabay.c
> @@ -416,7 +416,6 @@ static void poll_media_bay(struct media_bay_info* bay)
> }
> }
>
> -#ifdef CONFIG_MAC_FLOPPY
> int check_media_bay(struct device_node *which_bay, int what)
> {
> int i;
> @@ -431,7 +430,6 @@ int check_media_bay(struct device_node *which_bay, int what)
> return -ENODEV;
> }
> EXPORT_SYMBOL(check_media_bay);
> -#endif /* CONFIG_MAC_FLOPPY */
>
> #ifdef CONFIG_BLK_DEV_IDE_PMAC
> int check_media_bay_by_base(unsigned long base, int what)
>
> Yours Tony
>
> linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
> Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply
* Re: [PATCH] FIx compile of swim3 as module
From: Tony Breeds @ 2008-02-13 2:51 UTC (permalink / raw)
To: Josh Boyer
Cc: Bartlomiej Zolnierkiewicz, kyle, LinuxPPC-dev, Paul Mackerras,
Andrew Morton, Linus Torvalds
In-Reply-To: <20080212204802.18a7a868@zod.rchland.ibm.com>
On Tue, Feb 12, 2008 at 08:48:02PM -0600, Josh Boyer wrote:
> Kyle posted a slightly different patch that seemed to still keep
> the original intention of ifdefery in tact. I've no idea which is
> better, but the three of you might want to compare notes.
/me checks ....
Hmm Kyle's seem the leave the:
#ifndef CONFIG_PMAC_MEDIABAY
#define check_media_bay(which, what) 1
#endif
in swim3.c, which doesn't seem right.
But I'm easy as long as it gets fixed. :)
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply
* Re: [PATCH] FIx compile of swim3 as module
From: Josh Boyer @ 2008-02-13 2:48 UTC (permalink / raw)
To: Tony Breeds
Cc: Bartlomiej Zolnierkiewicz, kyle, LinuxPPC-dev, Paul Mackerras,
Andrew Morton, Linus Torvalds
In-Reply-To: <20080213024019.GX6887@bakeyournoodle.com>
On Wed, 13 Feb 2008 13:40:20 +1100
tony@bakeyournoodle.com (Tony Breeds) wrote:
> The current pmac32_defconfig fails to build with the following error:
>
> Building modules, stage 2.
> ERROR: "check_media_bay" [drivers/block/swim3.ko] undefined!
> WARNING: modpost: Found 23 section mismatch(es).
> To see full details build your kernel with:
> 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
> make[2]: *** [__modpost] Error 1
>
> This patch fixes that.
Kyle posted a slightly different patch that seemed to still keep
the original intention of ifdefery in tact. I've no idea which is
better, but the three of you might want to compare notes.
josh
^ permalink raw reply
* [PATCH] FIx compile of swim3 as module
From: Tony Breeds @ 2008-02-13 2:40 UTC (permalink / raw)
To: Andrew Morton, Linus Torvalds, LinuxPPC-dev
Cc: Paul Mackerras, Bartlomiej Zolnierkiewicz
The current pmac32_defconfig fails to build with the following error:
Building modules, stage 2.
ERROR: "check_media_bay" [drivers/block/swim3.ko] undefined!
WARNING: modpost: Found 23 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'
make[2]: *** [__modpost] Error 1
This patch fixes that.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
drivers/block/swim3.c | 4 ----
drivers/macintosh/mediabay.c | 2 --
2 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/block/swim3.c b/drivers/block/swim3.c
index b4e462f..730ccea 100644
--- a/drivers/block/swim3.c
+++ b/drivers/block/swim3.c
@@ -251,10 +251,6 @@ static int floppy_release(struct inode *inode, struct file *filp);
static int floppy_check_change(struct gendisk *disk);
static int floppy_revalidate(struct gendisk *disk);
-#ifndef CONFIG_PMAC_MEDIABAY
-#define check_media_bay(which, what) 1
-#endif
-
static void swim3_select(struct floppy_state *fs, int sel)
{
struct swim3 __iomem *sw = fs->swim3;
diff --git a/drivers/macintosh/mediabay.c b/drivers/macintosh/mediabay.c
index 9367882..51a1128 100644
--- a/drivers/macintosh/mediabay.c
+++ b/drivers/macintosh/mediabay.c
@@ -416,7 +416,6 @@ static void poll_media_bay(struct media_bay_info* bay)
}
}
-#ifdef CONFIG_MAC_FLOPPY
int check_media_bay(struct device_node *which_bay, int what)
{
int i;
@@ -431,7 +430,6 @@ int check_media_bay(struct device_node *which_bay, int what)
return -ENODEV;
}
EXPORT_SYMBOL(check_media_bay);
-#endif /* CONFIG_MAC_FLOPPY */
#ifdef CONFIG_BLK_DEV_IDE_PMAC
int check_media_bay_by_base(unsigned long base, int what)
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply related
* RE: [Spam Mail] Re: populate_rootfs fail (This message should be blocked: bkdh372119)
From: jay_chen @ 2008-02-13 1:52 UTC (permalink / raw)
To: linuxppc-embedded-bounces+jay_chen=alphanetworks.com; +Cc: linuxppc-embedded
In-Reply-To: <47B19543.70808@coritel.it>
-----Original Message-----
From: linuxppc-embedded-bounces+jay_chen=alphanetworks.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+jay_chen=alphanetworks.com@ozlabs.org]
Sent: Tuesday, February 12, 2008 8:47 PM
To: jay_chen
Cc: linuxppc-embedded@ozlabs.org
Subject: [Spam Mail] Re: populate_rootfs fail (This message should be
blocked: bkdh372119)
jay_chen ha scritto:
> Hello all:
>
> I am using mpc8548, kernel 2.6.14.5, and uboot as boot loader.
> When I upgrade ram from 512MB to 2G, my kernel can't boot anymore.
> (I pass mem=2048M to kernel in uboot now)
>
> It always dies in exec sys_write( ) in populate_rootfs( ).
> I did more tests about this and I found that sys_write( ) could write
> only about 4MB in 2G ram case.
> (My initrd is about 19MB, initrd_start : 0xCE7C7000, initrd_end :
> 0xCFAAF289, initrd_end - initrd_start : 0x012E8289 ==> about 19MB)
> Could anybody give me some hints?
> Is this issue related to the location of "/initrd.image"? Could I
> control it?
> Is there any size limit in ppc arch about ramdisk/initrd?
>
> Thanks for help.
>
> Jay...
>
> void __init populate_rootfs(void)
> {
> char *err;
> ...
> #ifdef CONFIG_BLK_DEV_INITRD
> if (initrd_start) {
> ...
> printk("it isn't (%s); looks like an initrd\n", err);
> fd = sys_open("/initrd.image", O_WRONLY|O_CREAT, 700);
> if (fd >= 0) {
> sys_write(fd, (char *)initrd_start,
> initrd_end - initrd_start);
> sys_close(fd);
> free_initrd();
> }
> }
> #endif
> }
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
I think can be a problem with the u-boot initrd_high option. Have you been
enabled the highmem support to use 2G of ram, right? You can try to set this
option to 0x30000000.
Marco
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
0x30000000 doesn't work in my system, but 0x08000000 does.
I am not quiet understand the function of initrd_high and how to set it.
Since it may helps, I will try to figure out the whole story.
Thanks for your help.
Jay...
^ permalink raw reply
* Re: Could the DTS experts look at this?
From: Grant Likely @ 2008-02-13 0:15 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <47B2300B.4060101@freescale.com>
On Feb 12, 2008 4:47 PM, Timur Tabi <timur@freescale.com> wrote:
> David Gibson wrote:
>
> > I can pretty much guarantee you that someone will find that
> > insufficient and want to expand the conditional representation. This
> > way madness lies.
>
> Then let them. We can have version numbers associated with the conditional
> expressions. If they want to make more complex condition expressions, they can
> bump the version number and define a spec and write code to parse it.
You say that as if bumping the version number is cheap to do.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Could the DTS experts look at this?
From: Grant Likely @ 2008-02-13 0:10 UTC (permalink / raw)
To: Timur Tabi, Grant Likely, linuxppc-dev, Arnd Bergmann
In-Reply-To: <20080212233548.GE21230@localhost.localdomain>
On Feb 12, 2008 4:35 PM, David Gibson <david@gibson.dropbear.id.au> wrote:
> In fact, in one way of looking at it that's always what happens: the
> dtb format is defined for passing hardware information from the
> bootloader to the kernel; nothing else. Passing a dtb *into* the
> bootloader is just a bootloader implementation convenience, because
> the possible variations on an output tree are small, so it's useful to
> have a skeleton tree built-in. But in order for the bootloader to
> process those variations correctly, the skeleton *must* be in the
> right format. dtb input to a bootloader must match the bootloaders
> expectations. This has always been true, and will continue to be
> true.
Well said.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH rev2] powerpc: Marvell 64x60 EDAC platform devices setup
From: Dave Jiang @ 2008-02-13 0:11 UTC (permalink / raw)
To: paulus; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <20080212105113.553659b0.sfr@canb.auug.org.au>
Creating platform devices (memory controller, sram error registers, cpu
error registers, PCI error registers) for Error Detection and Correction
(EDAC) driver.
The platform devices allow the mv64x60 EDAC driver to detect errors from
the memory controller (ECC erorrs), SRAM controller, CPU data path error
registers, and PCI error registers. The errors are reported to syslog.
Software ECC scrubbing is provided. These replace the mv64x60 error handlers
in the ppc branch. They are being moved to EDAC subsystem in order to
centralize error reporting.
The error reporting can be triggered via interrupts from the mv64x60 bridge
chip or via polling mechanism provided by the EDAC core code.
Signed-off-by: Dave Jiang <djiang@mvista.com>
Acked-by: Dale Farnsworth <dale@farnsworth.org>
---
Updated with changes from Stephen Rothwell
mv64x60_dev.c | 88 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 88 insertions(+)
diff --git a/arch/powerpc/sysdev/mv64x60_dev.c b/arch/powerpc/sysdev/mv64x60_dev.c
index efda002..21bb791 100644
--- a/arch/powerpc/sysdev/mv64x60_dev.c
+++ b/arch/powerpc/sysdev/mv64x60_dev.c
@@ -17,6 +17,7 @@
#include <linux/platform_device.h>
#include <asm/prom.h>
+#include <asm/io.h>
/*
* These functions provide the necessary setup for the mv64x60 drivers.
@@ -439,6 +440,63 @@ error:
return err;
}
+static int __init mv64x60_edac_pdev_init(struct device_node *np,
+ int id,
+ int num_addr,
+ const char *pdev_name)
+{
+ struct resource *r;
+ struct platform_device *pdev;
+ int i, ret;
+
+ r = kzalloc(num_addr * sizeof(*r) + sizeof(*r), GFP_KERNEL);
+ if (!r)
+ return -ENOMEM;
+
+ for (i = 0; i < num_addr; i++) {
+ ret = of_address_to_resource(np, i, &r[i]);
+ if (ret) {
+ kfree(r);
+ return ret;
+ }
+ }
+
+ of_irq_to_resource(np, 0, &r[i]);
+
+ pdev = platform_device_register_simple(pdev_name, id, r, num_addr + 1);
+
+ kfree(r);
+
+ if (IS_ERR(pdev))
+ return PTR_ERR(pdev);
+
+ return 0;
+}
+
+#ifdef CONFIG_PCI
+/*
+ * Bit 0 of MV64x60_PCIx_ERR_MASK does not exist on the 64360 and because of
+ * errata FEr-#11 and FEr-##16 for the 64460, it should be 0 on that chip as
+ * well. IOW, don't set bit 0.
+ */
+#define MV64X60_PCIx_ERR_MASK_VAL 0x00a50c24
+
+/* Erratum FEr PCI-#16: clear bit 0 of PCI SERRn Mask reg. */
+static int __init mv64x60_pci_fixup(struct device_node *np)
+{
+ void __iomem *pci_serr;
+
+ pci_serr = of_iomap(np, 1);
+ if (!pci_serr)
+ return -ENOMEM;
+
+ out_le32(pci_serr, in_le32(pci_serr) & ~0x1);
+ iounmap(pci_serr);
+
+ return 0;
+}
+#endif /* CONFIG_PCI */
+
static int __init mv64x60_device_setup(void)
{
struct device_node *np = NULL;
@@ -460,6 +518,36 @@ static int __init mv64x60_device_setup(void)
if ((err = mv64x60_i2c_device_setup(np, id++)))
goto error;
+ id = 0;
+ for_each_compatible_node(np, NULL, "marvell,mv64x60-mem-ctrl")
+ if ((err = mv64x60_edac_pdev_init(np, id++, 1,
+ "mv64x60_mc_err")))
+ goto error;
+
+ id = 0;
+ for_each_compatible_node(np, NULL, "marvell,mv64x60-cpu-error")
+ if ((err = mv64x60_edac_pdev_init(np, id++, 2,
+ "mv64x60_cpu_err")))
+ goto error;
+
+ id = 0;
+ for_each_compatible_node(np, NULL, "marvell,mv64x60-sram-ctrl")
+ if ((err = mv64x60_edac_pdev_init(np, id++, 1,
+ "mv64x60_sram_err")))
+ goto error;
+
+#ifdef CONFIG_PCI
+ id = 0;
+ for_each_compatible_node(np, NULL, "marvell,mv64x60-pci-error") {
+ if ((err = mv64x60_pci_fixup(np)))
+ goto error;
+
+ if ((err = mv64x60_edac_pdev_init(np, id++, 1,
+ "mv64x60_pci_err")))
+ goto error;
+ }
+#endif
+
/* support up to one watchdog timer */
np = of_find_compatible_node(np, NULL, "marvell,mv64x60-wdt");
if (np) {
^ permalink raw reply related
* Re: Could the DTS experts look at this?
From: David Gibson @ 2008-02-13 0:08 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <47B2300B.4060101@freescale.com>
On Tue, Feb 12, 2008 at 05:47:23PM -0600, Timur Tabi wrote:
> David Gibson wrote:
>
> > I can pretty much guarantee you that someone will find that
> > insufficient and want to expand the conditional representation. This
> > way madness lies.
>
> Then let them. We can have version numbers associated with the conditional
> expressions. If they want to make more complex condition expressions, they can
> bump the version number and define a spec and write code to parse it.
>
> > No. As Grant says, that's not what the version number is for. It
> > represents the version of the encoding, not the content. If you must
> > version the content (which you should try really hard to avoid) the
> > correct way is to add versioning properties to the root node.
>
> And that's why I prefer updating the DTB format to allow attaching
> conditional expressions to nodes. This would then necessitate
> bumping the version number. Older U-Boots will reject this new DTB.
> We can also modify DTC to support conditional nodes, so that if a
> customer has an older U-Boot he can't update, he can use DTC to
> generate a V17 DTB that has the conditionals already processed.
Well, yes, folding conditionals into the format would mean a version
bump. But I am *not* going to put conditionals into a dtb version,
and I'm pretty sure BenH and Paulus would also reject this notion.
It's simply not what the format is for. dtbs are for parsing by the
kernel, giving a complete device representation. If bootloaders and
other things also find them a useful input format, that's great, but
I'm not going to significantly extend the semantics just to support
other uses.
Now, if you want to define a new binary-level "meta-dtb" format,
designed for representing various conditionals or whatnot, which can
be processed into a final true dtb, go for it. But a) if you base it
on the dtb format, make sure you use a different magic number so as
not to interfere with the actual dtbs version progression and b) I
think you'll find it's more trouble than it's worth, at least at this
stage (feel free to try to prove me wrong on this point, of course).
At present, I think the "meta-dtb" format which makes the most sense,
based on a balance between simplicity and flexibility is C, with one
or more dtb fragments embedded. This can be done now (though if there
are libfdt extensions which would make this usage easier, please
suggest them - fdt_graft() is an obvious one).
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: Could the DTS experts look at this?
From: David Gibson @ 2008-02-12 23:50 UTC (permalink / raw)
To: Timur Tabi; +Cc: Scott Wood, linuxppc-dev, Arnd Bergmann
In-Reply-To: <47B22E98.8040900@freescale.com>
On Tue, Feb 12, 2008 at 05:41:12PM -0600, Timur Tabi wrote:
> David Gibson wrote:
>
> > I'm not sure I'm entirely happy about storing the fragments under a
> > special node - but certainly u-boot could do that if it wants. What
> > would certainly be ok is to store various fragments as separate blobs
> > and fold them together as necessary. Which reminds me, I meant to
> > implement a "graft" function in libfdt.
>
> Most likely, U-Boot would strip out the special node after
> processing it. The idea is for the boot loader to customize the
> device tree based before sending it to the kernel.
Of course. U-boot can use whatever representation it likes
internally, as long as it's all fixed up by the time it reaches the
kernel. I just think using sepa`rate "device tree fragment" blobs
might be a better way of doing it.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: Could the DTS experts look at this?
From: Timur Tabi @ 2008-02-12 23:50 UTC (permalink / raw)
To: Timur Tabi, Grant Likely, linuxppc-dev, Arnd Bergmann
In-Reply-To: <20080212233548.GE21230@localhost.localdomain>
David Gibson wrote:
> You don't. If your agent takes a dtb, dtb layout and agent must
> match.
So what I would like to see is a way for the agent to validate the dtb. U-Boot
could currently validate the SOC's compatible field. However, if we add a
special node that contains rules for modifying the rest of the tree, the only
possible way to block older, incompatible U-Boots from accepting the tree is to
bump the version number. Since that is not the right thing to do, the best
approach is to define a new node type that has conditional expression attached
to it. Then we can bump the version.
> In fact, in one way of looking at it that's always what happens: the
> dtb format is defined for passing hardware information from the
> bootloader to the kernel; nothing else. Passing a dtb *into* the
> bootloader is just a bootloader implementation convenience, because
> the possible variations on an output tree are small, so it's useful to
> have a skeleton tree built-in. But in order for the bootloader to
> process those variations correctly, the skeleton *must* be in the
> right format. dtb input to a bootloader must match the bootloaders
> expectations. This has always been true, and will continue to be
> true.
The problem with this approach is that you're replacing data with code, and that
always makes things more difficult.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: Could the DTS experts look at this?
From: Timur Tabi @ 2008-02-12 23:47 UTC (permalink / raw)
To: Timur Tabi, Grant Likely, linuxppc-dev, Arnd Bergmann
In-Reply-To: <20080212232639.GD21230@localhost.localdomain>
David Gibson wrote:
> I can pretty much guarantee you that someone will find that
> insufficient and want to expand the conditional representation. This
> way madness lies.
Then let them. We can have version numbers associated with the conditional
expressions. If they want to make more complex condition expressions, they can
bump the version number and define a spec and write code to parse it.
> No. As Grant says, that's not what the version number is for. It
> represents the version of the encoding, not the content. If you must
> version the content (which you should try really hard to avoid) the
> correct way is to add versioning properties to the root node.
And that's why I prefer updating the DTB format to allow attaching conditional
expressions to nodes. This would then necessitate bumping the version number.
Older U-Boots will reject this new DTB. We can also modify DTC to support
conditional nodes, so that if a customer has an older U-Boot he can't update, he
can use DTC to generate a V17 DTB that has the conditionals already processed.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: Could the DTS experts look at this?
From: Timur Tabi @ 2008-02-12 23:41 UTC (permalink / raw)
To: Scott Wood, Arnd Bergmann, Timur Tabi, linuxppc-dev
In-Reply-To: <20080212231702.GB21230@localhost.localdomain>
David Gibson wrote:
> I'm not sure I'm entirely happy about storing the fragments under a
> special node - but certainly u-boot could do that if it wants. What
> would certainly be ok is to store various fragments as separate blobs
> and fold them together as necessary. Which reminds me, I meant to
> implement a "graft" function in libfdt.
Most likely, U-Boot would strip out the special node after processing it. The
idea is for the boot loader to customize the device tree based before sending it
to the kernel.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: Could the DTS experts look at this?
From: David Gibson @ 2008-02-12 23:35 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <47B1F763.9000404@freescale.com>
On Tue, Feb 12, 2008 at 01:45:39PM -0600, Timur Tabi wrote:
> Grant Likely wrote:
[snip]
> > That's not a dtb version issue. That is a dtb content issue.
>
> Technically, that's true, but ...
>
> > It does
> > not warrant changing the dtb version number.
>
> Then how do you solve the problem of passing a device tree to a boot
> loader that does not know how to parse it properly? A device tree
> with these additional nodes *must* be parsed by a boot loader that
> is aware of them.
Correct. Just as you must give a dtb with the information to the
correct board to a bootloader or things won't work. Changing this is
not within the reasonable scope of what dtbs will do.
> Otherwise, it will pass the device tree as-is to
> the kernel without warning. This is a bad thing, and steps should
> be taken to prevent that. If you can think of a way to make this
> happen without changing the version number, I'd love to hear. All
> I'm hearing from you now is denial that this is a problem.
>
> >>> We've already got that issue. If you pass the device tree for the
> >>> wrong board it will still validate correctly, but the board is not
> >>> going to boot.
> >> There's nothing stopping U-Boot today from scanning the device tree and making
> >> sure the SOC's compatible node is correct. That's not currently done, but it
> >> could be.
> >
> > Fair enough, and it is also reasonable for the boot loader to look for
> > a specific property name to decide how to massage the data structure.
> > This alone does not require a dtb version change.
>
> Current versions of U-Boot do not know how to do this. So again,
> I'm asking you: how do you solve the problem of passing a device
> tree with additional nodes to a boot loader that does not know how
> to parse them properly? How do you prevent that old U-Boot from
> ignoring those nodes?
You don't. If your agent takes a dtb, dtb layout and agent must
match.
> > I'm not missing the point because I disagree entirely with the
> > addition of conditional expressions to the device tree. Instead, I
> > think properties can be added to the device tree that a bootloader can
> > look for and decide to apply conditions against them which means the
> > conditions are encoded in the boot loader, not the device tree. (the
> > device tree simply contains data which supports the boot loaders
> > decision; a rather different thing).
>
> Then why bother passing a DTB to the boot loader at all? Why not
> just have the boot loader create the device tree from scratch?
That's a perfectly acceptable option - and it's what I'd expect if a
real OF decided to add support for flattened device trees (which might
happen with ePAPR). libfdt's serial-write functions are designed for
exactly this use case.
In fact, in one way of looking at it that's always what happens: the
dtb format is defined for passing hardware information from the
bootloader to the kernel; nothing else. Passing a dtb *into* the
bootloader is just a bootloader implementation convenience, because
the possible variations on an output tree are small, so it's useful to
have a skeleton tree built-in. But in order for the bootloader to
process those variations correctly, the skeleton *must* be in the
right format. dtb input to a bootloader must match the bootloaders
expectations. This has always been true, and will continue to be
true.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: Could the DTS experts look at this?
From: David Gibson @ 2008-02-12 23:26 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <47B1EEA8.4040904@freescale.com>
[snip]
On Tue, Feb 12, 2008 at 01:08:24PM -0600, Timur Tabi wrote:
> Grant Likely wrote:
> > On Feb 12, 2008 8:44 AM, Timur Tabi <timur@freescale.com> wrote:
> >> Arnd Bergmann wrote:
> > I think it
> > is a slippery slope to try and encode conditionals into the structure;
>
> Perhaps, which is why I said it should be simple conditionals - two
> values and a comparison.
I can pretty much guarantee you that someone will find that
insufficient and want to expand the conditional representation. This
way madness lies.
> > but it is entirely reasonable to encode *data* into the dt that helps
> > make those conditional decisions.
>
> That's okay too, except that if we just add additional nodes that
> describe conditions, then we need to make sure that whatever parses
> that DTB must also parse those additional nodes. The only way to do
> that is create a new version number, like 18, which is marked as
> being incompatible with the current version (17). Otherwise, a
> person could pass that DTB to an old version of U-Boot, and U-boot
> will just pass it on to the kernel as-is.
No. As Grant says, that's not what the version number is for. It
represents the version of the encoding, not the content. If you must
version the content (which you should try really hard to avoid) the
correct way is to add versioning properties to the root node.
> > We've already got that issue. If you pass the device tree for the
> > wrong board it will still validate correctly, but the board is not
> > going to boot.
>
> There's nothing stopping U-Boot today from scanning the device tree
> and making sure the SOC's compatible node is correct. That's not
> currently done, but it could be.
>
> > The device tree must match what the bootloader
> > expects. Changing the version number will do nothing to help this.
> > The version number ensures that the tree is parsable. It does not
> > ensure that it is correct.
>
> I think you're missing the point. If we add conditional expressions
> to the device tree (whether attached to a node or as part of a
> separate node or whatever), we must also add a mechanism to ensure
> that these conditions are parsed by the boot loader. As far as I
> know, the only mechanism that can do this is the version identifier.
No. a) the version identifier is not a mechanism for doing that and b)
the conditional mechanism is inherently agent-specific, therefore in
any case you *must* match an input incomplete tree (by which I mean
*anything* that requires processing before it's ready for consumption
by the kernel) to the specific bootloader or agent that will process
it and pass to the kernel.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ 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