* Xilinx ML403 support in mainline u-boot
From: John Hahn @ 2007-09-27 8:16 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 806 bytes --]
Hello, I am a newbie about to start sw/hw development on ML403 based
systems.
I apologize if I am repeating a question already addressed in the forum, but
I have gone through past months of the archives without finding the answer.
Based on searching the archived posts
I have downloaded from Xilinx an older version of u-boot (1.1.4)
http://www.xilinx.com/ml410-p/designs/
<http://www.xilinx.com/ml410-p/designs/u-boot.zip> u-boot.zip
which appears to have the ml403 support.
I also cloned the latest u-boot repository from denx (1.3.0-rc2+)
git://www.denx.de/git/u-boot.git
However this tree does not appear to have the ml403 support.
If possible I would prefer to use the latest u-boot tree .
Its there another branch which I need to pull the ml403 support changes?
Thanks
John
[-- Attachment #2: Type: text/html, Size: 3996 bytes --]
^ permalink raw reply
* Re: [PATCH 4/7] Celleb: New HTAB Guest OS Interface on Beat
From: Arnd Bergmann @ 2007-09-27 8:51 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
In-Reply-To: <20070927.165326.-1300536104.kouish@swc.toshiba.co.jp>
On Thursday 27 September 2007, Ishizaki Kou wrote:
> This is a patch kit to work with new Guest OS Interface
> to tweak HTAB on Beat. It detects old and new Guest OS Interfaces
> automatically.
>
> Signed-off-by: Kou Ishizaki <Kou.Ishizaki@toshiba.co.jp>
Acked-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
The code looks good. One possible optimization I can imagine is
to split the v3 functions and the older versions into separate
source files, and then use configuration options to decide if
you want to build a kernel just for one of the two, or for
both variants. You could even have two separate machine descriptions,
while still sharing most of the platform code in common files.
Arnd <><
^ permalink raw reply
* Re: [PATCH 5/7] Celleb: Supports VFD on Celleb 2
From: Arnd Bergmann @ 2007-09-27 9:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
In-Reply-To: <20070927.165631.-1300533671.kouish@swc.toshiba.co.jp>
On Thursday 27 September 2007, Ishizaki Kou wrote:
> This is a patch to support VFD on Celleb 2.
> VFD is a small LCD to show miscellaneous messages.
>
> Signed-off-by: Kou Ishizaki <Kou.Ishizaki@toshiba.co.jp>
The implementation looks fine, but I'm not sure if /proc/ppc64/rtas is the
right way to do it. The two problems I have with this are:
* /proc files are generally not a good idea for new stuff. We carry around
the existing /proc/ppc64/rtas files because we can't change the interface
for existing stuff. My feeling is that your interface should better be
implemented as a character device, or be integrating into some other
existing message interface, if we can find one.
* The firmware seems to implement the generic rtas interface for
display-character and set-indicator, but your driver is celleb specific.
I'd be feel more comfortable if we could come up with a driver that also
works on other systems that implement the same rtas calls.
Arnd <><
^ permalink raw reply
* Linux 2.6.22 Serial Core
From: Deepak Gaur @ 2007-09-27 9:39 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
Just a small question! The serial core driver file located in drivers/serial directory
(drivers/serial/serial_core.c) does not have module_init() and module_exit() function
called though CONFIG_SERIAL_CORE flag is seperately defined in Kconfig and is used in
makefile. Any idea why these functions are not called in this particular file??
with regards,
Deepak Gaur
^ permalink raw reply
* Re: [PATCH] add Altivec/VMX state to coredumps
From: Kumar Gala @ 2007-09-27 10:10 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Carlos Eduardo Seo
In-Reply-To: <1190861310.6502.10.camel@concordia>
>>> You're probably right :)
>>>
>>> What cores have SPE at the moment? Also, perhaps more importantly,
>>> are there any plans to have Altivec and SPE in the same core?
>>
>> The e500 cores's from Freescale.
>>
>> No, they are pretty much mutually exclusive.
>>
>>> I've been working with Carlos Eduardo Seo (Cc'ed on this mail) on
>>> the GDB side of this.
>>
>> From comments it looks like the expectation is that the combination
>> of note type and name which is expected to be unique.
>>
>> I'm wondering if we should handle this via
>> elf_coredump_extra_notes_size() & elf_coredump_extra_notes_write().
>> Does GDB care about the order it sees the various sections in?
>
> I don't think those callbacks will work in this case, they're only
> called for the primary thread that's doing the coredump, not for each
> thread. Perhaps there's a way to adapt it though.
>
> I think the easiest solution for now is just to make the note type a
> #define and create a new value for Altivec.
Oh, well. It shouldn't be too difficult to abstract vector handler
similar to how we do GPRs today to the core dump code.
- k
^ permalink raw reply
* Re: really old glibc on 8xx or 403 with bleeding-edge kernel - anyone care?
From: Kumar Gala @ 2007-09-27 10:12 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <18170.60026.917774.234504@cargo.ozlabs.ibm.com>
On Sep 26, 2007, at 6:25 PM, Paul Mackerras wrote:
> Since about May 2001, we have put two AT_IGNOREPPC entries at the
> beginning of the ELF auxiliary vector. The reason for this is that
> glibc prior to April 2001 rounded up the address of the base of the
> aux vector to a multiple of 16. I think we can now get rid of the
> AT_IGNOREPPC entries.
>
> Well, in fact what old glibc did was a little more complex than that.
> It worked out the standard aux vector base (i.e. the address of the
> word after the end of the environment pointers), and then chose either
> that or that address rounded up to a multiple of 16 bytes. The way it
> chose was by checking the word at the rounded address - if it was more
> than 16 it used the standard base address, otherwise it used the
> rounded address.
>
> So the way the AT_IGNOREPPC hack worked was by putting 4 words (two
> aux vector entries) at the beginning of the aux vector that all
> contained the value 22 (AT_IGNOREPPC). That made the old glibc code
> choose the standard aux vector base address.
>
> However, what comes after that is an AT_DCACHEBSIZE (19) entry and an
> AT_ICACHEBSIZE (20) entry. Thus, as long as the data cache blocksize
> and the instruction cache blocksize are greater than 16, these two
> entries will serve just as well as the AT_IGNOREPPC entries at making
> old glibc choose the standard aux vector base address.
>
> The only CPUs that we support with cache line sizes of 16 bytes or
> less are the 8xx family and the 403 family. So my question is, does
> anyone care about running ancient userland binaries (from 2001 or
> earlier) on 8xx or 403 with future kernels (2.6.x for x >= 24)?
>
> If not then we can remove the AT_IGNOREPPC aux vector entries.
What's the benefit to removing them?
- k
^ permalink raw reply
* Re: [PATCH 1/7] PowerPC64: Not to insert EA=0 entry at
From: Ishizaki Kou @ 2007-09-27 11:22 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, paulus, arnd
In-Reply-To: <1190881132.6158.4.camel@pasglop>
Ben-san,
> On Thu, 2007-09-27 at 17:01 +0900, kou.ishizaki@toshiba.co.jp wrote:
>
> > Celleb does not set get_paca()->kstack properly (I don't know which
> > function should set it up), so we need to workaround.
>
> paca->kstack is set in asm (via the PACAKSAVE macro), from either
> __secondary_start for non-boot CPUs or from start_here_common for the
> boot CPU.
>
> slb_flush_and_rebolt() should not be called before that happens.
>
> How do you end up with kstack set to 0 ?
I found r13 is not set before entering start_here_common for boot cpu.
For non-boot threads, __secondary_start will set r13 properly.
So the problem is to set r13 correct PACA address before entering
start_here_common. Should it set before entering kernel or will some
patch make sense?
Best regards,
Kou Ishizaki
^ permalink raw reply
* Re: [PATCH 3/5] ibmebus: Add device creation and bus probing based on of_device
From: Arnd Bergmann @ 2007-09-27 11:27 UTC (permalink / raw)
To: linuxppc-dev
Cc: Thomas Klein, Jan-Bernd Themann, Joachim Fenkes, LKML,
Paul Mackerras, Christoph Raisch, Paul Mackerras, Stefan Roscher
In-Reply-To: <200709261145.22278.fenkes@de.ibm.com>
On Wednesday 26 September 2007, Joachim Fenkes wrote:
> The devtree root is now searched for devices matching a built-in whitelist
> during boot, so these devices appear on the bus from the beginning. It is
> still possible to manually add/remove devices to/from the bus by using the
> probe/remove sysfs interface. Also, when a device driver registers itself,
> the devtree is matched against its matchlist.
>
> Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [PATCH 1/5] PowerPC: Move of_device allocation into of_device.[ch]
From: Arnd Bergmann @ 2007-09-27 11:27 UTC (permalink / raw)
To: linuxppc-dev
Cc: Thomas Klein, Jan-Bernd Themann, Joachim Fenkes, LKML,
Paul Mackerras, Christoph Raisch, Paul Mackerras, Stefan Roscher
In-Reply-To: <200709261144.14282.fenkes@de.ibm.com>
On Wednesday 26 September 2007, Joachim Fenkes wrote:
> Extract generic of_device allocation code from of_platform_device_create()
> and move it into of_device.[ch], called of_device_alloc(). Also, there's now
> of_device_free() which puts the device node.
>
> This way, bus drivers that build on of_platform (like ibmebus will) can
> build upon this code instead of reinventing the wheel.
>
> Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [PATCH 4/5] ibmebus: Move to of_device and of_platform_driver, match eHCA and eHEA drivers
From: Arnd Bergmann @ 2007-09-27 11:31 UTC (permalink / raw)
To: linuxppc-dev
Cc: Thomas Klein, Jan-Bernd Themann, Joachim Fenkes, LKML,
Paul Mackerras, Christoph Raisch, Paul Mackerras, Stefan Roscher
In-Reply-To: <200709261145.51926.fenkes@de.ibm.com>
On Wednesday 26 September 2007, Joachim Fenkes wrote:
> Replace struct ibmebus_dev and struct ibmebus_driver with struct of_device
> and struct of_platform_driver, respectively. Match the external ibmebus
> interface and drivers using it.
>
> Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [PATCH 2/5] ibmebus: Remove bus match/probe/remove functions
From: Arnd Bergmann @ 2007-09-27 11:30 UTC (permalink / raw)
To: linuxppc-dev
Cc: Thomas Klein, Jan-Bernd Themann, Joachim Fenkes, LKML,
Paul Mackerras, Christoph Raisch, Paul Mackerras, Stefan Roscher
In-Reply-To: <200709261144.57606.fenkes@de.ibm.com>
On Wednesday 26 September 2007, Joachim Fenkes wrote:
> Remove old code that will be replaced by rewritten and shorter functions in
> the next patch. Keep struct ibmebus_dev and struct ibmebus_driver for now,
> but replace ibmebus_{,un}register_driver() by dummy functions. This way, the
> kernel will still compile and run during the transition and git bisect will
> be happy.
>
> Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [Cbe-oss-dev] [patch 0/8] PS3 AV Settings Driver patches for 2.6.24
From: Geert Uytterhoeven @ 2007-09-27 11:53 UTC (permalink / raw)
To: Michael Ellerman
Cc: linuxppc-dev, linux-fbdev-devel, cbe-oss-dev, Antonino A. Daplas
In-Reply-To: <1190860285.6502.6.camel@concordia>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2811 bytes --]
On Thu, 27 Sep 2007, Michael Ellerman wrote:
> On Wed, 2007-09-26 at 18:33 +0200, Geert Uytterhoeven wrote:
> > Here are some new patches for the PS3 AV Settings Driver (ps3av), which is
> > used in close collaboration with the PS3 Virtual Frame Buffer Device Driver
> > (ps3fb):
> > [1] ps3av: eliminate unneeded temporary variables
> > [2] ps3av: eliminate PS3AV_DEBUG
> > [3] ps3av: use PS3 video mode ids in autodetect code
> > [4] ps3av: treat DVI-D like HDMI in autodetect
> > [5] ps3av: add autodetection for VESA modes
> > [6] ps3av: add quirk database for broken monitors
> > [7] ps3av: remove unused ps3av_set_mode()
> > [8] ps3av: don't distinguish between `boot' and `non-boot' autodetection
> >
> > Please review, and queue for 2.6.24 if they're ok. Thanks!
> >
> > Question: As several DVI-D displays advertise they support 1080i modes while
> > they actually don't (cfr. the quirk database), perhaps I should drop 1080i
> > modes completely from the ps3av_preferred_modes[] table? Usually 720p looks
> > better than 1080i anyway. What do you think?
>
> Definitely. If the autodetection fails Linux is basically unusable on
> PS3 unless you hack the kernel sources and build your own kboot and
> otheros.bld - not entirely trivial for novice users. So it's pretty
> important that it works 100%.
Well, this code has been in Geoff's git tree for a while, and it's been several
weeks ago I got complaints (which have been adressed by adding displays to the
quirk database). The new kboot (from Distro Kit 1.4.1) also uses it.
The only 100% (sic) mode is 480p (actual usable resolution is 576x384), which
is quite limited due to the very low resolution. This is what the current
mainline kernel uses by default, causing complaints from people who don't like
their shiny expensive full-HD displays being driven by 480p by default.
Furthermore Geoff is working on a way to configure the video mode for
otheros.bld (cfr. the tool to change the default kernel command line on an
ia32 kernel image ages ago), and petitboot (which is intended to replace the
current kboot boot loader environment) allows to change the video mode using
a simple key press if you get a blank screen.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: dtc: Use libfdt/fdt.h instead of flat_dt.h
From: Jon Loeliger @ 2007-09-27 13:26 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070926031105.GA26512@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> In the dtc tree, both flat_dt.h and libfdt/fdt.h have structures and
> constants relating to the flattened device tree format derived from
> asm-powerpc/prom.h in the kernel. The former is used in dtc, the
> latter in libfdt.
>
> libfdt/fdt.h is the more recent, revised version, so use that
> throughout, removing flat_dt.h.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
As instructed, I also ignored this patch:
dtc: Use a custom name for lexer output
Thanks,
jdl
^ permalink raw reply
* Help! Debian ppc64
From: Cesar Bello @ 2007-09-27 13:57 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 257 bytes --]
Hi, I'm writing from Venezuela. I have to prepair a presentation about
Debian on IBM pSerires Servers with Power 5+ processors. My first question
is what are the advantages of use Debian GNU/Linux on pSeries Servers?
Thanks for your help
Regards
Cesar B
[-- Attachment #2: Type: text/html, Size: 363 bytes --]
^ permalink raw reply
* Re: dtc: Use libfdt/fdt.h instead of flat_dt.h
From: David Gibson @ 2007-09-27 14:17 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1IatNe-0007Yv-Aw@jdl.com>
On Thu, Sep 27, 2007 at 08:26:14AM -0500, Jon Loeliger wrote:
> So, like, the other day David Gibson mumbled:
> > In the dtc tree, both flat_dt.h and libfdt/fdt.h have structures and
> > constants relating to the flattened device tree format derived from
> > asm-powerpc/prom.h in the kernel. The former is used in dtc, the
> > latter in libfdt.
> >
> > libfdt/fdt.h is the more recent, revised version, so use that
> > throughout, removing flat_dt.h.
> >
> > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>
> Applied.
>
> As instructed, I also ignored this patch:
> dtc: Use a custom name for lexer output
Ta.
In not too long, I expect to have a series of patches getting libfdt
ready for use in the kernel. A new patch with various makefile
cleanups including the lexer name patch will be part of that.
--
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: changing the EDLK components
From: Murat Artun @ 2007-09-27 14:34 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20070926232020.AD2B12405D@gemini.denx.de>
Ok, I have built my library from its source RPM as you have stated.
Specifically, I have followed the procedure in section "3.7.
Rebuilding ELDK Components". First I have installed source RPMs and
then rebuilt the binary target RPM. However, as I have followed the
compiler messages I recognized that host gcc is called instead of
cross gcc.
Considering that my PATH was set following the advice in section "3.7.
Rebuilding ELDK Components" as "<ELDK_root>/usr/ppc-linux/bin"
directory is before "/usr/bin" what could be the problem?
Thanks and regards...
On 9/27/07, Wolfgang Denk <wd@denx.de> wrote:
> In message <4e5a3720709260725x6d2e9faemc6a6053379610df8@mail.gmail.com> you wrote:
> >
> > I want to learn the way of building a GNU Automake project and adding
> > it into ELDK. This could be needed because the current version of an
> > ELDK component is old to meet the requirements or a library which is
> > not an ELDK component is to be used in our ppc system.
>
> In principle, this is a pretty straightforward procedure: you
> download the source RPM (for example, from the Fedora 7
> distribution), and use the "rpmbuild" command on the native syustem
> (running with root file system mounted over NFS or on a local
> harddisk) to build the stuff. For example:
>
> $ rpmbuild --rebuild automake17-1.7.9-8.src.rpm
>
> That's in proinciple. In reality, you will soon learn that the
> package has a lot of build dependencies, which are not exactly
> trivial to resolve, as some of them are circular. You can try and find
> what's really needed (and not included with the ELDK) by running
>
> $ rpmbuild --rebuild --nodeps automake17-1.7.9-8.src.rpm
>
> but this is just tof ind out how many othe rpackages youw ill need to
> build before...
>
> > As now, I need to upgrade an ELDK component. Namely, I need version
> > 0.9.8 of OpenSSL, where latest ELDK release has OpenSSL with version
> > 0.9.7f. I want to learn if it is necessary for me to follow the same
>
> You don't need a native version of automake for this, as builing is
> done in the cross environment, and we assume you have automake
> installed on your build host.
>
> > procedure stated in documentation in section "3.7. Rebuilding ELDK
> > Components". If this is the case, could anyone point me to resources
> > about how to prepare source rpms from an Automake project to prepare
>
> I don't understand why you mention automake here. It is completely
> unrelated.
>
> > the source rpm of version 0.9.8 of OpenSSL? Of course building the new
> > version of the component and placing everything by hand is always a
> > solution, but I want to understand the clean way of doing this.
>
> The clean way is to adjust the ELDK buld system for the new version.
> This is usually a non-trivial job. By doing it you will start to
> admire what ELDK gives you and understand at least a bit of how much
> effort is built into it - and you get it all completely for free...
>
>
>
> Alternatively, you can just wait for ELDK 4.2, which will include
> openssl-0.9.8b-12
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
> That Microsoft, the Trabant of the operating system world, may be
> glancing over the Berlin Wall at the Audis and BMWs and Mercedes. In
> their own universe Trabants and Ladas were mainstream too...
> -- Evan Leibovitch
>
--
M u r at A r t u n, MSc.
Design Engineer
"be conservative in what you do, be liberal in what you accept from others"
^ permalink raw reply
* Re: Help! Debian ppc64
From: Olof Johansson @ 2007-09-27 14:42 UTC (permalink / raw)
To: Cesar Bello; +Cc: linuxppc-dev
In-Reply-To: <4d1254690709270657l7e3b4cdbhee90eef97b37f77@mail.gmail.com>
Hi,
On Thu, Sep 27, 2007 at 09:57:02AM -0400, Cesar Bello wrote:
> Hi, I'm writing from Venezuela. I have to prepair a presentation about
> Debian on IBM pSerires Servers with Power 5+ processors. My first question
> is what are the advantages of use Debian GNU/Linux on pSeries Servers?
Sounds like a question better suited for debian's ppc list at
debian-powerpc@lists.debian.org.
-Olof
^ permalink raw reply
* Re: Help! Debian ppc64
From: Linas Vepstas @ 2007-09-27 15:34 UTC (permalink / raw)
To: Cesar Bello; +Cc: linuxppc-dev
In-Reply-To: <4d1254690709270657l7e3b4cdbhee90eef97b37f77@mail.gmail.com>
On Thu, Sep 27, 2007 at 09:57:02AM -0400, Cesar Bello wrote:
> Hi, I'm writing from Venezuela. I have to prepair a presentation about
> Debian on IBM pSerires Servers with Power 5+ processors. My first question
> is what are the advantages of use Debian GNU/Linux on pSeries Servers?
Advantages as compared to what?
-- Debian on Intel?
+++ powerpc has better RAS features than Intel, for example,
my favorite, PCI error handling and recovery, or hotplug cpu,
dynamic LPAR configuration, etc.
-- SuSE/RedHat on PowerPC?
+++ SuSE/RedHat offer formal support, for $$$, which debian/ubuntu do not
-- AIX on pSeries?
+++ AIX has various "enterprise" features that Debian does not.
You might try talking to RedHat/SuSE product support, and also to IBM
pSeries sales.
Linas Vepstas
^ permalink raw reply
* Re: [PATCH 8/15] bootwrapper: convert flatdevtree to version 16
From: Milton Miller @ 2007-09-27 15:44 UTC (permalink / raw)
To: David Gibson; +Cc: ppcdev
In-Reply-To: <20070927024535.GC14030@localhost.localdomain>
On Sep 26, 2007, at 9:45 PM, David Gibson wrote:
> On Wed, Sep 26, 2007 at 11:19:47AM -0500, Milton Miller wrote:
>> On Sep 24, 2007, at 10:46 PM, David Gibson wrote:
>>> On Mon, Sep 24, 2007 at 01:54:32AM -0500, Milton Miller wrote:
>>>> On Sep 23, 2007, at 10:36 PM, David Gibson wrote:
>>>>> On Fri, Sep 21, 2007 at 06:05:06PM -0500, Milton Miller wrote:
>>> [snip]
>>>>>> +#define MIN_VERSION 2
>>>>>> +#define OUT_VERSION 16z
>>>> Actually the v1 trees has
>>>> some other differences such as initrd addresses were kernel linear
>>>> not
>>>> real, cpus were assigned logical numbers ... so while the structure
>>>> didn't change except for the header field, the contents did.
>>>
>>> !? what's your source for this. v2 and v3 were absolutely supposed
>>> to
>>> be backwards compatible with v1 which would not be the case with
>>> silent semantic changes such as this.
>>
>> What's your souce for saying the were supposed to be backwards
>> compatable? That dtc fills out the struct header so?
>
> Sitting next to BenH and knowing he always intended them to be so.
>
>> My source is my involvment when v2 was defined (they were discovered
>> while writing my device tree generation code):
>>
>> The actual binary structure is compatable, just not the contents of
>> the
>> properties nor how any slave cpus wait (for some trees it doesn't
>> matter).
>>
>> http://git.kernel.org/?p=linux/kernel/git/horms/kexec-tools-
>> testing.git;a=blob;f=kexec/arch/ppc64/fs2dt.c;
>> hb=b84b87747a16f0afbef6f6802bb794a94f4961d9
>
> An old version of fs2dt is hardly definitive. It could just be Plain
> Wrong, nothing to do with the dt version.
Sorry, copy and paste error. I was tring to point out this changelog
in 2.6.10:
http://git.kernel.org/?p=linux/kernel/git/torvalds/old-2.6-bkcvs.git;
a=commitdiff;h=e1b47549d1588ccea1fa5726eb430aae4e80f8ed
>
>> And some more changes just before that:
>>
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/old-2.6-bkcvs.git;
>> a=history;f=arch/ppc64/kernel/prom_init.c;
>> h=e570799a84cc5328e9f0fd44592cb0b828d8c13a;
>> hb=4ae24c4e8a8f68950a7774ca1cdfe69bfe4e2ffc
>
> I don't know what bit you're referring to in that batch of commits.
The following properties changed semantics and no heuristics are
employed to check for the old vs new:
(1) tces changed from virtual to real
(2) cpus spin on physical (hw id) not logical (0-n)
Other changes in that series
(3) 0->klimit is not a memreserve in the tree (we now allow overlapping
reserves, but not at the time)
(4) rtas properties are in a different location (but both could exist)
>
>> So its mostly when the kernel generated and required v1 trees, it was
>> ppc64 only and had these other content and handoff semantics. If it
>> were to get a v1 tree, it only copes for the boot cpu determination
>> I'm not aware of any code other than the kernel that would actually
>> generate a v1 tree (other than dtc, which always supporteed v2, and
>> doesn't care about these differences).
So trying to boot 2.6.9 (2004-10-18 cutoff) kernel from a tree for
2.6.10 would fail, and vice versa. But a 2.6.10 kernel can boot a v1
tree with properties, memreserves, and cpu ids that it expects, getting
the boot-cpuid from the extra property in the tree.
Is that compatible? If you only are talking about parsing the tree it
is.
milton
^ permalink raw reply
* Re: Is it safe to use these Linux function (test_bit(), set_bit(), clear_bit()) in character device driver for 2.6.10 ppc kernel.
From: Scott Wood @ 2007-09-27 16:04 UTC (permalink / raw)
To: Misbah khan; +Cc: linuxppc-embedded
In-Reply-To: <12916782.post@talk.nabble.com>
Misbah khan wrote:
> Hi all I am using "test_bit(),set_bit(),clear_bit() etc" API functions
> provided by the Linux kernel. I want to know that if anybody is used it
> and have full faith in its operation then please let me know. Driver in
> the while loop is calling these API's hence i want to make sure that its
> operation will remain stable.
They're used all over the place. Is there anything about them that you
find suspect?
-Scott
^ permalink raw reply
* Re: jffs2 file system on MPC8272ADS
From: Scott Wood @ 2007-09-27 16:19 UTC (permalink / raw)
To: Nethra; +Cc: linuxppc-embedded
In-Reply-To: <12914822.post@talk.nabble.com>
Nethra wrote:
>>> They are errors.
>
> which are all the most possible reasons for these errors ?
Most common is making a jffs2 filesystem with the wrong block size. It
could also be an incorrect flash mapping.
>>> Was it the physmap driver or the pq2fads driver that found the flash?
>
> Flash is cfi compatible.
That's not what I meant... you have two mapping drivers enabled, and
the pq2fads driver might be doing something other that what you
specified to physmap. I'd just disable it.
>>> Which kernel are you using, and are you using arch/ppc or arch/powerpc?
>>> -Scott
>
> KERNEL: linux-2.6.10 and we r using arc/ppc
That's pretty old... If all else fails, you may want to see if never
kernels still have the problem.
-Scott
^ permalink raw reply
* Re: [PATCH 5/7] Celleb: Supports VFD on Celleb 2
From: Linas Vepstas @ 2007-09-27 16:54 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, paulus
In-Reply-To: <200709271107.33696.arnd@arndb.de>
On Thu, Sep 27, 2007 at 11:07:33AM +0200, Arnd Bergmann wrote:
> On Thursday 27 September 2007, Ishizaki Kou wrote:
> > This is a patch to support VFD on Celleb 2.
> > VFD is a small LCD to show miscellaneous messages.
> >
> > Signed-off-by: Kou Ishizaki <Kou.Ishizaki@toshiba.co.jp>
>
> My feeling is that your interface should better be
> implemented as a character device, or be integrating into some other
> existing message interface, if we can find one.
>
> * The firmware seems to implement the generic rtas interface for
> display-character and set-indicator, but your driver is celleb specific.
> I'd be feel more comfortable if we could come up with a driver that also
> works on other systems that implement the same rtas calls.
Yep, I think I agree. Most pseries systems have a small two-line
LCD display. Right now, the code that talks to it is implemented in
rtas_progress(). It has this name because its used only for printing
out boot progress messages. This is great for debugging hangs, but
its not othrewise used.
I suppose it would be nice to have a "geeric" interface to the thing,
and, after a quickie skim of the code, the celleb display looks similar
enogh that this abstraction could be made.
--linas
^ permalink raw reply
* Re: [RFC PATCH v0.1] net driver: mpc52xx fec
From: Juergen Beisert @ 2007-09-27 17:07 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20070810095153.GC13994@moe.telargo.com>
On Friday 10 August 2007 11:51, Domen Puncer wrote:
> Not for merge (yet)! But please do review.
>
> fec_mpc52xx driver (not in-tree, but floating around) isn't in very
> good shape, so I tried to change that.
> Diff against original is quite big (fec_phy.c is completely rewritten)
> and confuzing, so I'm including whole drivers/net/fec_mpc52xx/ .
>
> I still have 'make CONFIG_FEC_MPC52xx_MDIO=3Dn compile and work' on my
> TODO, maybe even ethtool support.
Currently I'm trying with your fec driver and Sylvain Munaut's bestcomm dri=
ver=20
*and* rt-preemt 2.6.23-rc8-rt1 and now I'm getting this error while stress=
=20
test the network:
BUG: scheduling while atomic: softirq-timer/0/0x00000002/5, CPU#0
Call Trace:
[c0309e00] [c0007ddc] show_stack+0x3c/0x194 (unreliable)
[c0309e30] [c0017934] __schedule_bug+0x38/0x48
[c0309e40] [c01c8f24] __schedule+0x3e8/0x428
[c0309e70] [c01c96d4] schedule+0x54/0xf0
[c0309e80] [c01c9e8c] schedule_timeout+0x68/0xe4
[c0309ec0] [c00282dc] msleep+0x1c/0x34
[c0309ed0] [c0125fb8] fec_stop+0xbc/0x1a8
[c0309ef0] [c0126530] fec_reset+0x20/0xb0
[c0309f10] [c0127840] fec_tx_timeout+0x3c/0xa4
[c0309f30] [c016b5dc] dev_watchdog+0x13c/0x14c
[c0309f50] [c0027c90] run_timer_softirq+0x2e4/0x444
[c0309f90] [c00239a4] ksoftirqd+0x134/0x214
[c0309fd0] [c0034d94] kthread+0x48/0x84
[c0309ff0] [c000f828] kernel_thread+0x44/0x60
Do you have an idea what happens?
Juergen
=2D-=20
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
=A0Pengutronix - Linux Solutions for Science and Industry
=A0 Handelsregister: Amtsgericht Hildesheim, HRA 2686
=A0 =A0 =A0 Vertretung Sued/Muenchen, Germany
Phone: +49-8766-939 228 | Fax: +49-5121-206917-9
^ permalink raw reply
* Re: [Cbe-oss-dev] [patch 0/8] PS3 AV Settings Driver patches for 2.6.24
From: Geoff Levand @ 2007-09-27 17:23 UTC (permalink / raw)
To: michael
Cc: Geert Uytterhoeven, linuxppc-dev, linux-fbdev-devel, cbe-oss-dev,
Antonino A. Daplas
In-Reply-To: <1190860285.6502.6.camel@concordia>
Michael Ellerman wrote:
> On Wed, 2007-09-26 at 18:33 +0200, Geert Uytterhoeven wrote:
>> Hi,
>>
>> Here are some new patches for the PS3 AV Settings Driver (ps3av), which is
>> used in close collaboration with the PS3 Virtual Frame Buffer Device Driver
>> (ps3fb):
>> [1] ps3av: eliminate unneeded temporary variables
>> [2] ps3av: eliminate PS3AV_DEBUG
>> [3] ps3av: use PS3 video mode ids in autodetect code
>> [4] ps3av: treat DVI-D like HDMI in autodetect
>> [5] ps3av: add autodetection for VESA modes
>> [6] ps3av: add quirk database for broken monitors
>> [7] ps3av: remove unused ps3av_set_mode()
>> [8] ps3av: don't distinguish between `boot' and `non-boot' autodetection
>>
>> Please review, and queue for 2.6.24 if they're ok. Thanks!
>>
>> Question: As several DVI-D displays advertise they support 1080i modes while
>> they actually don't (cfr. the quirk database), perhaps I should drop 1080i
>> modes completely from the ps3av_preferred_modes[] table? Usually 720p looks
>> better than 1080i anyway. What do you think?
>
> Definitely. If the autodetection fails Linux is basically unusable on
> PS3 unless you hack the kernel sources and build your own kboot and
> otheros.bld - not entirely trivial for novice users. So it's pretty
> important that it works 100%.
It is not that bad. If a bootloader is configued to use autodetection
so that it is shown at best video mode, then it should have advertised
key sequences to default to known video modes, with at least a 480p 'safe'
mode.
Second stage kerenls can be booted with a videomode appended on the
command line, and all kboot.conf's should have a 480p 'safe' mode
entry.
-Geoff
^ permalink raw reply
* Re: tg3: PCI error recovery
From: Linas Vepstas @ 2007-09-27 17:56 UTC (permalink / raw)
To: Michael Chan, linux-pci, linuxppc-dev; +Cc: Matt Carlson
In-Reply-To: <1190850518.25892.5.camel@dell>
During a private conversation about how to save and restore
device state after a pci error is detected, and the device is reset,
the following came up:
On Wed, Sep 26, 2007 at 04:48:38PM -0700, Michael Chan wrote:
> >
> > > 1b) If so, is it safe to call pci_save_state() in
> > > tg3_io_error_detected(), or are we to assume they've been corrupted?
> >
> > My conservative approach is to assume that anything and everything has
> > been corrupted. (e.g. temporary undervoltage on the bus might scramble
> > multiple registers)
>
> In that case, we should call pci_restore_msi_state() to restore the MSI
> state, but this call is only defined if CONFIG_PM is defined.
There seem to be two choices:
1) enable CONFIG_PM in those arches that care about recovering from PCI
errors. (Yuck)
2) remove the ifdef CONFIG_PM from around pci_restore_msi_state() in
rivers/pci/msi.c
I'd go for choice 2, but I thought I'd ask first ...
--linas
^ 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