* Re: crash in aty128_set_lcd_enable on PowerBook
From: Benjamin Herrenschmidt @ 2006-07-16 19:19 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20060716165004.GA16369@suse.de>
On Sun, 2006-07-16 at 18:50 +0200, Olaf Hering wrote:
> On Sun, Jul 16, Olaf Hering wrote:
>
> >
> > Current Linus tree crashes in aty128_set_lcd_enable() because par->pdev
> > is NULL. This happens since at least a week. Call trace is:
> >
> > aty128_set_lcd_enable
> > aty128fb_set_par
> > fbcon_init
> > visual_init
> > take_over_console
> > fbcon_takeover
> > notifier_call_chain
> > blocking_notifier_call_chain
> > register_framebuffer
> > aty128fb_probe
>
> aty128_init calls register_framebuffer() before it assigns pdev.
Yeah, that looks like some serious bogosity in that code. Care to send a
patch ?
> 2028 if (register_framebuffer(info) < 0)
> 2029 return 0;
> 2030
> 2031 par->pm_reg = pci_find_capability(pdev, PCI_CAP_ID_PM);
> 2032 par->pdev = pdev;
> 2033 par->asleep = 0;
> 2034 par->lock_blank = 0;
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: crash in aty128_set_lcd_enable on PowerBook
From: Benjamin Herrenschmidt @ 2006-07-16 19:25 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1153077550.5905.33.camel@localhost.localdomain>
> Yeah, that looks like some serious bogosity in that code. Care to send a
> patch ?
(I'm in a hotel room in Ottawa with no r128 at hand to test so I'm not
doing it myself just now :)
Ben.
^ permalink raw reply
* Re: crash in aty128_set_lcd_enable on PowerBook
From: Olaf Hering @ 2006-07-16 19:27 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1153077953.5905.37.camel@localhost.localdomain>
On Sun, Jul 16, Benjamin Herrenschmidt wrote:
>
> > Yeah, that looks like some serious bogosity in that code. Care to send a
> > patch ?
>
> (I'm in a hotel room in Ottawa with no r128 at hand to test so I'm not
> doing it myself just now :)
It crashes later for different reasons. The whole init process works by
luck it seems.
^ permalink raw reply
* Re: crash in aty128_set_lcd_enable on PowerBook
From: Benjamin Herrenschmidt @ 2006-07-16 19:43 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20060716192727.GA17387@suse.de>
On Sun, 2006-07-16 at 21:27 +0200, Olaf Hering wrote:
> On Sun, Jul 16, Benjamin Herrenschmidt wrote:
>
> >
> > > Yeah, that looks like some serious bogosity in that code. Care to send a
> > > patch ?
> >
> > (I'm in a hotel room in Ottawa with no r128 at hand to test so I'm not
> > doing it myself just now :)
>
> It crashes later for different reasons. The whole init process works by
> luck it seems.
I've been having weird things happening with latest linus trees and
really no time to debug ... do you have a backtrace for the "other"
crash ?
Ben.
^ permalink raw reply
* Re: crash in aty128_set_lcd_enable on PowerBook
From: Olaf Hering @ 2006-07-16 19:50 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1153079015.5905.39.camel@localhost.localdomain>
On Sun, Jul 16, Benjamin Herrenschmidt wrote:
> > It crashes later for different reasons. The whole init process works by
> > luck it seems.
>
> I've been having weird things happening with latest linus trees and
> really no time to debug ... do you have a backtrace for the "other"
> crash ?
It was in aty128_bl_set_power(), cant remember the trace.
^ permalink raw reply
* [PATCH] aoa: fix feature-call GPIO layer
From: Johannes Berg @ 2006-07-16 20:19 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Per Christian Henden, paulus, linuxppc-dev
In-Reply-To: <1153065707.5905.8.camel@localhost.localdomain>
I hope this isn't too badly mangled... I'm without a proper mail client
right now because my ~ is corrupted enough to be put offline once I access
it a lot :/ I intend to repair this tomorrow, so if it is mangled I can
resend Tuesday.
---
This fixes the feature-call GPIO layer in snd-aoa which is used on
machines without platform functions so that it doesn't try to look up an
interrupt property for detect device nodes that don't exist.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Index: linux-2.6-fetch/sound/aoa/core/snd-aoa-gpio-feature.c
===================================================================
--- linux-2.6-fetch.orig/sound/aoa/core/snd-aoa-gpio-feature.c 2006-07-16
22:10:02.467630929 +0200
+++ linux-2.6-fetch/sound/aoa/core/snd-aoa-gpio-feature.c 2006-07-16
22:13:41.891630929 +0200
@@ -112,7 +112,10 @@ static struct device_node *get_gpio(char
static void get_irq(struct device_node * np, int *irqptr)
{
- *irqptr = irq_of_parse_and_map(np, 0);
+ if (np)
+ *irqptr = irq_of_parse_and_map(np, 0);
+ else
+ *irqptr = NO_IRQ;
}
/* 0x4 is outenable, 0x1 is out, thus 4 or 5 */
@@ -322,7 +325,7 @@ static int ftr_set_notify(struct gpio_ru
return -EINVAL;
}
- if (irq == -1)
+ if (irq == NO_IRQ)
return -ENODEV;
mutex_lock(¬if->mutex);
^ permalink raw reply
* Re: [PATCH 0/3] powerpc: Instrument Hypervisor Calls
From: Luke Browning @ 2006-07-16 22:53 UTC (permalink / raw)
To: Olof Johansson
Cc: linuxppc-dev-bounces+lukebrowning=us.ibm.com, Arnd Bergmann,
Bryan S Rosenburg, linuxppc-dev, Nathan Lynch, Christopher Yeoh,
Paul Mackerras
In-Reply-To: <20060716035353.GA5266@pb15.lixom.net>
[-- Attachment #1: Type: text/plain, Size: 910 bytes --]
linuxppc-dev-bounces+lukebrowning=us.ibm.com@ozlabs.org wrote on
07/16/2006 12:53:54 AM:
> On Sat, Jul 15, 2006 at 02:00:02AM +0200, Arnd Bergmann wrote:
>
> > What happened to the question whether to use PURR values for also
measuring
> > cycles spent executing the hcall as opposed to cycles that passed
before
> > the hcall returns. Did that turn out not giving extra information
after all
> > or was there a different reason to drop that idea?
>
> Just so people don't forget: this can't be done on all processors. For
> example, PPC970 and POWER4 don't implement the PURR SPR. And it doesn't
> make sense to use H_PURR to get the software emulated ones there. Not
> really an issue on POWER4 since they don't do shared processor LPAR, but
> on JS21 I think they might do?
>
Isn't there someway to do a platform specific processor overlay, where you
get PURR if it exists and TB otherwise.
Luke
[-- Attachment #2: Type: text/html, Size: 1129 bytes --]
^ permalink raw reply
* Re: [PATCH 0/3] powerpc: Instrument Hypervisor Calls
From: Luke Browning @ 2006-07-16 23:02 UTC (permalink / raw)
To: Anton Blanchard
Cc: linuxppc-dev-bounces+lukebrowning=us.ibm.com, Arnd Bergmann,
Bryan S Rosenburg, linuxppc-dev, Nathan Lynch, Christopher Yeoh,
Paul Mackerras
In-Reply-To: <20060715220757.GA31511@krispykreme>
[-- Attachment #1: Type: text/plain, Size: 986 bytes --]
linuxppc-dev-bounces+lukebrowning=us.ibm.com@ozlabs.org wrote on
07/15/2006 07:07:58 PM:
>
> > Not sure I follow you. I would expect the PURR value to be restored
after
> > a context switch, even if we continue on a different physical CPU.
> >
> > The idea behind monitoring both PURR and timebase is that the
difference
> > between the two tells you how long the partition was suspended during
> > the hcall.
>
> Sounds good, last time I looked at the patch I thought it was gathering
> the PURR only. That on its own would make for some confusing results.
>
It would be more efficient to have a separate trace log for PHYP
dispatches as
there are many more hypervisor calls than PHYP dispatches. I believe PHYP
provides
a trace records for dispatches, which could be seperately written. Perf
tools can
assemble the information from multiple records. It would be nice to have
processor
specific time function that reads either PURR or TB based on the platform.
Luke
[-- Attachment #2: Type: text/html, Size: 1376 bytes --]
^ permalink raw reply
* Re: [PATCH 0/3] powerpc: Instrument Hypervisor Calls
From: Olof Johansson @ 2006-07-16 23:09 UTC (permalink / raw)
To: Luke Browning
Cc: Arnd Bergmann, Bryan S Rosenburg, linuxppc-dev, Paul Mackerras,
Christopher Yeoh, Nathan Lynch
In-Reply-To: <OFFBAD5953.E17A24C8-ON832571AD.007DA01D-832571AD.007DBBB5@us.ibm.com>
On Sun, Jul 16, 2006 at 08:53:21PM -0200, Luke Browning wrote:
> > Just so people don't forget: this can't be done on all processors. For
> > example, PPC970 and POWER4 don't implement the PURR SPR. And it doesn't
> > make sense to use H_PURR to get the software emulated ones there. Not
> > really an issue on POWER4 since they don't do shared processor LPAR, but
> > on JS21 I think they might do?
> >
> Isn't there someway to do a platform specific processor overlay, where you
> get PURR if it exists and TB otherwise.
Sure, it's what we have cpu feature bits for. It's not a difficult
problem to solve, I was just reminding of the lack of SPRN_PURR on some
processors that can run hypervisors.
-Olof
^ permalink raw reply
* Re: [JOB] Senior Embedded Linux Video Engineer
From: David H. Lynch Jr. @ 2006-07-17 1:12 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060716151246.94C9C352681@atlas.denx.de>
[-- Attachment #1: Type: text/plain, Size: 3233 bytes --]
Wolfgang Denk wrote:
> In message <44B7E508.7020700@freescale.com> you wrote:
>
>> otherwise unnoticed). Hell, if the subject header was appropriately
>> keyworded - Wolfgang could even procmail it to /dev/null ;-)
>>
>
> Please don't try to reinvent Usenet netiquette, poorly. Commercial
> ads, job ofers and the like have always been banned. It's just lately
> that nobody remembers the good old days any more and everybody thinks
> he can force his ideas over everybody else.
>
Atleast where I am reading it this is a mailing list not Usenet.
Each group/list has always had its own acceptable use policies.
I can trivially think of several with vastly different ones than
linuxppc-embedded.
And there are still flamewars over minor issues of netiquette.
There are many many things wrong with the internet today - but as
with everything else - the good old days often look better after the fact.
I do not know how long linuxppc-embedded has been arround, but I am
certain if you go back far enough there were not enough people with
internet access and the appropriate skills to form many of the focused
lists we have today.
5 years ago, I got much less spam than today. But 5 years ago, I
could not throw away all my reference books and just use google and
other search engines to look up virtually anything.
Today, the problem is not so much getting an answer to a question,
but finding the answer in the noise.
I do not want to dwell on this - I am prone to pine for the good old
days myself. I can rant about plenty of modern evils in the internet and
elsewhere. But I do nto trully want to go back. I want what I have now
AND some of what I had then.
One of the things I want out of the internet NOW, is tools to help
me persue my dreams and my lifestyle.
Wolfgang, seems to have gotten there before me, built the skills,
contacts, and reputation and I hope he is doing well. I had been doing
other things with my life and they did nto work out.
Now I am trying to parlay my skills into consulting work that lets
me do the work I want and keep the lifestyle I want.
Only I do not have the 25 years of industry contacts I would have
had I taken a different route, and I want to use the internet as a means
to mitigate that.
I have no problems banning job posting from this list.
But I do beleive there needs to be some place for them.
Personally I would like to see separate lists for traditional "jobs"
and consulting - with recruiters and contract employment postings banned
from the latter.
But I will live with whatever comes about.
> If there is demand for job offer postings, then these should be
> handled on a separate mailing list.
>
>
>
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
[-- Attachment #2: Type: text/html, Size: 4427 bytes --]
^ permalink raw reply
* Re: Kexec initial registers
From: Michael Ellerman @ 2006-07-17 1:22 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: linuxppc-dev
In-Reply-To: <28C15305-BE9F-4EE7-93A2-437EAEA7B886@watson.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1364 bytes --]
On Sat, 2006-07-15 at 22:10 -0400, Jimi Xenidis wrote:
> On Jul 14, 2006, at 5:08 PM, Benjamin Herrenschmidt wrote:
>
> > On Fri, 2006-07-14 at 12:02 -0400, Jimi Xenidis wrote:
> >> This is what I have so far:
> >>
> >> r3: address of device tree blob
> >> r4: address that kernel was loaded
> >> r5: not OF (=0)
> >
> > Correct and that's all that should be needed
> >
> >> r13: local_paca address (0?)
> >
> > You shouldn't have to care about r13 at all, it should be set by the
> > kernel before it's used. If not, please let us know as that means
> > there
> > is a bug :)
>
> Not! 99.99% :)
> When loading a kernel under Xen using kexec we set r1-r5 and set all
> other GPRS to all 5's (cuz we can) with CONFIG_PPC_EARLY_DEBUG=y and
> all hell breaks loose in the first printk()/DBG() from early_setup()
> for:
> kernel/printk.c:506
> 506 spin_lock_irqsave(&logbuf_lock, flags);
>
> where is access local_paca.
There should be a call to setup_paca(0) in early_setup() _before_ the
first printk/DBG. That patch is pretty new though, so you might not have
it yet.
cheers
--
Michael Ellerman
IBM OzLabs
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: 191 bytes --]
^ permalink raw reply
* Re: [PATCH 0/3] powerpc: Instrument Hypervisor Calls
From: Luke Browning @ 2006-07-17 2:02 UTC (permalink / raw)
To: Anton Blanchard
Cc: linuxppc-dev-bounces+lukebrowning=us.ibm.com, Arnd Bergmann,
Bryan S Rosenburg, linuxppc-dev, Nathan Lynch, Christopher Yeoh,
Paul Mackerras
In-Reply-To: <20060715153053.GK31081@krispykreme>
[-- Attachment #1: Type: text/plain, Size: 602 bytes --]
linuxppc-dev-bounces+lukebrowning=us.ibm.com@ozlabs.org wrote on
07/15/2006 12:30:54 PM:
>
> > What happened to the question whether to use PURR values for also
measuring
> > cycles spent executing the hcall as opposed to cycles that passed
before
> > the hcall returns. Did that turn out not giving extra information
after all
> > or was there a different reason to drop that idea?
>
> You have to be careful with PURR since it may be context switched
> between partitions.
>
That shouldn't be an issue as the PURR is supposed to be virtualized by
PHYP at
the virtual processor level.
Luke
[-- Attachment #2: Type: text/html, Size: 828 bytes --]
^ permalink raw reply
* Re: [JOB] Senior Embedded Linux Video Engineer
From: Geoff Thorpe @ 2006-07-17 3:28 UTC (permalink / raw)
To: Wolfgang Denk
Cc: Olof Johansson, linuxppc-dev, Stephen Rothwell, linuxppc-embedded
In-Reply-To: <20060716151246.94C9C352681@atlas.denx.de>
Wolfgang Denk wrote:
>Please don't try to reinvent Usenet netiquette, poorly.
>
Begging your pardon, sire. Thanks for the adverb too btw, quite a bonus
- amusing, albeit poorly.
And speaking of which...
>Commercial
>ads, job ofers and the like have always been banned. It's just lately
>that nobody remembers the good old days any more and everybody thinks
>he can force his ideas over everybody else.
>
>
?! Whoah, if that's the nature of the discussion, fine - count me out.
Oh, and FYI - the good old days also involved rock musicians in spandex,
and ... well ... whatever. If you were referring to me, then I retract
any such "force" without hesitation - because until you told me
otherwise, I was entirely ignorant to its existence. To be honest, I'm
still not sure *what* force you're talking about, but I'll take your
word for it.
And while I'm at it, the next time you throw a dart, I sure hope it at
least hits the dart-board - there's nothing more uncomfortable than
having to apologise to an unknown, uninterested, and uninvolved
bystander who has a dart sticking out of his forehead just for having
been in the room. But for what it's worth, "oh don't be silly, no
apology necessary". :-)
>If there is demand for job offer postings, then these should be
>handled on a separate mailing list.
>
>
If you say so, I never really liked playing darts anyway, stupid game -
too many people holding sharp instruments they have too little control over.
Cheers,
Geoff
^ permalink raw reply
* Re: how to get individual patches
From: David H. Lynch Jr. @ 2006-07-17 3:46 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <528646bc0607141122t53adeb30h8c2acb4e26ba0ddf@mail.gmail.com>
Grant Likely wrote:
> On 7/14/06, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
>
> AFAIK, yes you will have to repatch every time; I typically write a
> little helper script to lessen the pain:
>
> git bisect good|bad # depends on whether it works or not
> patch < [patchfile]
> compile, test, etc
> cg restore -f # Remove the patches
> git bisect good|bad # lather, rinse, repeate
>
Alright, I have bisected my way down to the problem.
Well sort of.
I think the real problem I started looking for eventually got fixed
in the kernel tree on its own.
But I did find a real problem. I have found my own work around - but
this problem may effect others.
The zlib library was updated within the past month.
The new zlib code does not work in my environment.
I have guesses as to why, but I am not a zlib expert and not looking
to be one.
I have solved my personal problem by reverting to the older zlib code.
With that I have 2.6.18-rc4 or whatever is in the linux-2.6 git tree
as of today working for me.
I was stuck at 2.6.16.21 before.
So my questions:
How/where do I report a problem ? I would be perfectly happy to help
whoever is responsible for zlib to work this out.
But I am not up to doing it myself.
git bisect got me down to a good/bad scenario. But I could not
provoke git to either pull the offending patch or export the change as a
patch so that I could back it out myself.
Now that the final git bisect screen is gone all I have (besides a
fixed 2.6.18-xx kernel) is I guess the sha has number for the particular
commit.
I suspect that would have been enough to yank just that patch but I
googled every permutation of git backout or similar things I could think
of and browsed the git tutorials etc.
and could not seem to decipher how to do anything usefull with the
sha id of a single patch.
I am sure that is a knowledge problem.
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Re: [PATCH] powerpc: simplify dma_ops bug conditions
From: Jeremy Kerr @ 2006-07-17 3:55 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20060713063947.GD5096@rhun.ibm.com>
Muli,
> Is the BUG_ON() necessary? the next line just goes and deref's it,
> which should lead to a shiny NULL pointer deref.
No, it's not really necessary, more a style thing. The BUG_ON only adds
an extra 3 instructions (subfic, addi and tdnei), which should be tiny
compared to the indirect branch.
Also, it makes it a little easier for a user to understand: "there's a
bug in the kernel" vs. "invalid memory access".
Jeremy
^ permalink raw reply
* uboot environment variables size for Yosemite board.
From: Leonid @ 2006-07-17 5:09 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 619 bytes --]
Hi:
I'm using uboot-1.1.4 for AMCC PPC440E Yosemite board. I've downloaded
this uboot from DENX site. It uses EEPROM to store environment
variables. Since EEPROM on Yosemite board is only 512 bytes, there can
not be more environment variables which is not very convenient.
There is theoretical possibility to save these variables on flash (64M
from which I use only part) and yosemite.h header file even has defines,
allowing this option. But is it going work in reality? What is simplest
way for Yosemite board to increase environment variables storage space?
Thanks,
Leonid.
[-- Attachment #2: Type: text/html, Size: 3286 bytes --]
^ permalink raw reply
* Re: how to get individual patches
From: Grant Likely @ 2006-07-17 5:30 UTC (permalink / raw)
To: dhlii; +Cc: linuxppc-embedded
In-Reply-To: <44BB080E.6060107@dlasys.net>
On 7/16/06, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
> The zlib library was updated within the past month.
> The new zlib code does not work in my environment.
> I have guesses as to why, but I am not a zlib expert and not looking
> to be one.
> I have solved my personal problem by reverting to the older zlib code.
> With that I have 2.6.18-rc4 or whatever is in the linux-2.6 git tree
> as of today working for me.
> I was stuck at 2.6.16.21 before.
>
> So my questions:
>
> How/where do I report a problem ? I would be perfectly happy to help
> whoever is responsible for zlib to work this out.
> But I am not up to doing it myself.
Once you've got the patch extracted (see below); post it to the lkml
with a description of your symptoms and what you are trying to do.
(or post it here, and if nobody knows; then move over to the lkml)
>
> git bisect got me down to a good/bad scenario. But I could not
> provoke git to either pull the offending patch or export the change as a
> patch so that I could back it out myself.
> Now that the final git bisect screen is gone all I have (besides a
> fixed 2.6.18-xx kernel) is I guess the sha has number for the particular
> commit.
git-format-patch <good_sha1>..<bad_sha1>
for example:
$ git-format-patch
0ce030395b92270567423d57d9d432eb77df32f2..8d92bc2270d67a43b1d7e94a8cb6f81f1435fe9a
0001-PCI-Error-handling-on-PCI-device-resume.txt
extracts a single patch file for the
PCI-Error-handling-on-PCI-device-resume.txt commit. If there are more
than one commits between <good_sha1> and <bad_sha1>, then you'll get
more than one patch file extracted.
Then, you can apply the patch reversed to backout the change.
> I suspect that would have been enough to yank just that patch but I
> googled every permutation of git backout or similar things I could think
> of and browsed the git tutorials etc.
> and could not seem to decipher how to do anything usefull with the
> sha id of a single patch.
"git-log <sha1>" will give you the history starting at a particular
commit, which is useful for finding the next commit after it for doing
the git-format-patch command.
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] powerpc: simplify dma_ops bug conditions
From: Muli Ben-Yehuda @ 2006-07-17 6:31 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: linuxppc-dev
In-Reply-To: <20060717062825.GA18291@rhun.ibm.com>
On Mon, Jul 17, 2006 at 01:55:09PM +1000, Jeremy Kerr wrote:
> No, it's not really necessary, more a style thing. The BUG_ON only adds
> an extra 3 instructions (subfic, addi and tdnei), which should be tiny
> compared to the indirect branch.
When we were submitting a patch to add a
BUG_ON(!valid_dma_data_direction(dir)) to x86-64's DMA-API, Jeff
Garzik was vehemently opposed to adding a few instructions to "one of
the hottest paths in the kernel".
Cheers,
Muli
^ permalink raw reply
* Re: uboot environment variables size for Yosemite board.
From: Wolfgang Denk @ 2006-07-17 7:00 UTC (permalink / raw)
To: Leonid; +Cc: linuxppc-embedded
In-Reply-To: <FAB00A8DC59FAB42B13C2B3B0F6877010D14478B@ehost011-3.exch011.intermedia.net>
In message <FAB00A8DC59FAB42B13C2B3B0F6877010D14478B@ehost011-3.exch011.intermedia.net> you wrote:
>
> I'm using uboot-1.1.4 for AMCC PPC440E Yosemite board. I've downloaded
Note that this is off topic here. You should have posted this on the
U-Boot-Users mailing list instead.
> this uboot from DENX site. It uses EEPROM to store environment
> variables. Since EEPROM on Yosemite board is only 512 bytes, there can
> not be more environment variables which is not very convenient.
Thisi s wrong. The Yosemite configuration uses (like most (all?) AMCC
eval boards - two redundand flash sectors to store the environment.
And available environment size is 8 kB:
=> print
...
Environment size: 1355/8187 bytes
> There is theoretical possibility to save these variables on flash (64M
> from which I use only part) and yosemite.h header file even has defines,
> allowing this option. But is it going work in reality? What is simplest
> way for Yosemite board to increase environment variables storage space?
I have no idea where you got your board configuration from, but it is
definitely not current code, nor the binary image at
ftp://ftp.denx.de/pub/u-boot/images/amcc/yosemite/u-boot.bin
The current code does use (redundand) flash for environment storage.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
The idea of male and female are universal constants.
-- Kirk, "Metamorphosis", stardate 3219.8
^ permalink raw reply
* Re: setup arch
From: Robin H. Johnson @ 2006-07-17 7:19 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20060709170909.90774.qmail@web35812.mail.mud.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 1268 bytes --]
(I tried to sent this before, but my mailserver wasn't playing nice).
On Sun, Jul 09, 2006 at 10:09:09AM -0700, Paul Smith wrote:
> I hesitate to lay this one out here because you all
> are way over my head. The regular forums have not
> responded to this in any meaningful way.
> Hi,
>
>
> Box:
> Quad 2.5 PPC
> 4.5 GB non ecc 533 Ram
> RocketRaid2320
> Nvida 6600 256mb
>
>
> software resources:
[snip the wrong iso files]
Look in the experimental directory of your local Gentoo mirror for
install-ppc64-minimal-dual-core-2006.0-32ul.iso
I believe this was because the dual-core patches aren't available in time for
the actual release media creation, and this was created later to make the newer
systems usable.
Additionally, unless you're planning on contributing the the Noveau driver for
accelerated 2D/3D support on the Nvidia cards, you won't be getting far with
the nvidia card.
Getting an ATI card will give you working 3D in most cases. See this list for
what's supported at the bleeding edge:
http://dri.freedesktop.org/wiki/ATIRadeon#head-298bd23baafb9c2fad1774d1d2fa54bd2aa55e7d
--
Robin Hugh Johnson
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply
* What is "request_module: runaway loop modprobe binfmt-4c46"?
From: Zhou Rui @ 2006-07-17 8:10 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 14686 bytes --]
Hi,
I tried to compile kernel for PowerPC405EP Octobus board with ELDK4.0. I used the kernel source 2.6.15 contained in ELDK4.0. I cross-compiled the kernel with "ARCH=ppc CROSS_COMPILE=ppc_4xx-". The filesystem was based on NFS. I tried to boot the image from ram in u-boot, but the boot procedure stopped at
"VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 100k init
request_module: runaway loop modprobe binfmt-4c46
request_module: runaway loop modprobe binfmt-4c46
request_module: runaway loop modprobe binfmt-4c46
request_module: runaway loop modprobe binfmt-4c46
request_module: runaway loop modprobe binfmt-4c46"
So would you like to tell me what the matter is with this? Thanks a lot.
My .config file for 2.6.15 kernel is like this:
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.15
# Wed Aug 23 14:58:08 2006
#
CONFIG_MMU=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_PPC=y
CONFIG_PPC32=y
CONFIG_GENERIC_NVRAM=y
CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
#
# General setup
#
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
# CONFIG_HOTPLUG is not set
CONFIG_KOBJECT_UEVENT=y
# CONFIG_IKCONFIG is not set
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_EMBEDDED=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_OBSOLETE_MODPARM=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
#
# Block layer
#
# CONFIG_LBD is not set
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_AS is not set
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
CONFIG_DEFAULT_NOOP=y
CONFIG_DEFAULT_IOSCHED="noop"
#
# Processor
#
# CONFIG_6xx is not set
CONFIG_40x=y
# CONFIG_44x is not set
# CONFIG_POWER3 is not set
# CONFIG_POWER4 is not set
# CONFIG_8xx is not set
# CONFIG_E200 is not set
# CONFIG_E500 is not set
CONFIG_MATH_EMULATION=y
# CONFIG_KEXEC is not set
# CONFIG_CPU_FREQ is not set
CONFIG_4xx=y
# CONFIG_WANT_EARLY_SERIAL is not set
#
# IBM 4xx options
#
# CONFIG_BUBINGA is not set
# CONFIG_CPCI405 is not set
# CONFIG_EP405 is not set
CONFIG_PPChameleonEVB=y
# CONFIG_REDWOOD_5 is not set
# CONFIG_REDWOOD_6 is not set
# CONFIG_SYCAMORE is not set
# CONFIG_WALNUT is not set
# CONFIG_XILINX_ML300 is not set
CONFIG_IBM_OCP=y
CONFIG_405EP=y
CONFIG_PPC4xx_DMA=y
CONFIG_PPC4xx_EDMA=y
CONFIG_PPC_GEN550=y
CONFIG_UART0_TTYS0=y
# CONFIG_UART0_TTYS1 is not set
CONFIG_NOT_COHERENT_CACHE=y
#
# Platform options
#
# CONFIG_PC_KEYBOARD is not set
# CONFIG_HIGHMEM is not set
CONFIG_HZ_100=y
# CONFIG_HZ_250 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=100
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
# CONFIG_SPARSEMEM_STATIC is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_BINFMT_ELF is not set
# CONFIG_BINFMT_MISC is not set
CONFIG_CMDLINE_BOOL=y
CONFIG_CMDLINE="console=ttyS0,115200 console=tty0 root=/dev/nfs"
# CONFIG_PM is not set
# CONFIG_SOFTWARE_SUSPEND is not set
# CONFIG_SECCOMP is not set
CONFIG_ISA_DMA_API=y
#
# Bus options
#
# CONFIG_PPC_I8259 is not set
# CONFIG_PCI is not set
# CONFIG_PCI_DOMAINS is not set
#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set
#
# Advanced setup
#
CONFIG_ADVANCED_OPTIONS=y
CONFIG_HIGHMEM_START=0xfe000000
# CONFIG_LOWMEM_SIZE_BOOL is not set
CONFIG_LOWMEM_SIZE=0x30000000
# CONFIG_KERNEL_START_BOOL is not set
CONFIG_KERNEL_START=0xc0000000
# CONFIG_TASK_SIZE_BOOL is not set
CONFIG_TASK_SIZE=0x80000000
# CONFIG_CONSISTENT_START_BOOL is not set
CONFIG_CONSISTENT_START=0xff100000
# CONFIG_CONSISTENT_SIZE_BOOL is not set
CONFIG_CONSISTENT_SIZE=0x00200000
# CONFIG_BOOT_LOAD_BOOL is not set
CONFIG_BOOT_LOAD=0x00400000
#
# Networking
#
CONFIG_NET=y
#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
CONFIG_IP_PNP_RARP=y
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_TUNNEL is not set
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_BIC=y
# CONFIG_IPV6 is not set
# CONFIG_NETFILTER is not set
#
# DCCP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_DCCP is not set
#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_IEEE80211 is not set
#
# Device Drivers
#
#
# Generic Driver Options
#
# CONFIG_STANDALONE is not set
# CONFIG_PREVENT_FIRMWARE_BUILD is not set
# CONFIG_FW_LOADER is not set
# CONFIG_DEBUG_DRIVER is not set
#
# Connector - unified userspace <-> kernelspace linker
#
# CONFIG_CONNECTOR is not set
#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set
#
# Parallel port support
#
# CONFIG_PARPORT is not set
#
# Plug and Play support
#
#
# Block devices
#
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
CONFIG_BLK_DEV_NBD=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
#
# ATA/ATAPI/MFM/RLL support
#
# CONFIG_IDE is not set
#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
# CONFIG_SCSI is not set
#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set
#
# Fusion MPT device support
#
# CONFIG_FUSION is not set
#
# IEEE 1394 (FireWire) support
#
#
# I2O device support
#
#
# Macintosh device drivers
#
# CONFIG_WINDFARM is not set
#
# Network device support
#
CONFIG_NETDEVICES=y
CONFIG_DUMMY=y
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
#
# PHY device support
#
# CONFIG_PHYLIB is not set
#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
# CONFIG_MII is not set
CONFIG_IBM_EMAC=y
CONFIG_IBM_EMAC_RXB=128
CONFIG_IBM_EMAC_TXB=64
CONFIG_IBM_EMAC_POLL_WEIGHT=32
CONFIG_IBM_EMAC_RX_COPY_THRESHOLD=256
CONFIG_IBM_EMAC_RX_SKB_HEADROOM=0
# CONFIG_IBM_EMAC_PHY_RX_CLK_FIX is not set
# CONFIG_IBM_EMAC_DEBUG is not set
#
# Ethernet (1000 Mbit)
#
#
# Ethernet (10000 Mbit)
#
#
# Token Ring devices
#
#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set
#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_SHAPER is not set
CONFIG_NETCONSOLE=y
CONFIG_NETPOLL=y
# CONFIG_NETPOLL_RX is not set
# CONFIG_NETPOLL_TRAP is not set
CONFIG_NET_POLL_CONTROLLER=y
#
# ISDN subsystem
#
# CONFIG_ISDN is not set
#
# Telephony Support
#
# CONFIG_PHONE is not set
#
# Input device support
#
CONFIG_INPUT=y
#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set
#
# Input Device Drivers
#
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set
#
# Hardware I/O ports
#
CONFIG_SERIO=y
# CONFIG_SERIO_I8042 is not set
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_LIBPS2 is not set
CONFIG_SERIO_RAW=y
# CONFIG_GAMEPORT is not set
#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_SERIAL_NONSTANDARD is not set
#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
# CONFIG_SERIAL_8250_MANY_PORTS is not set
# CONFIG_SERIAL_8250_SHARE_IRQ is not set
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
# CONFIG_SERIAL_8250_RSA is not set
#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set
#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_NVRAM is not set
# CONFIG_GEN_RTC is not set
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
#
# Ftape, the floppy tape device driver
#
# CONFIG_AGP is not set
# CONFIG_RAW_DRIVER is not set
#
# TPM devices
#
# CONFIG_TCG_TPM is not set
# CONFIG_TELCLOCK is not set
#
# I2C support
#
# CONFIG_I2C is not set
#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set
#
# Hardware Monitoring support
#
# CONFIG_HWMON is not set
# CONFIG_HWMON_VID is not set
#
# Misc devices
#
#
# Multimedia Capabilities Port drivers
#
#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set
#
# Graphics support
#
# CONFIG_FB is not set
#
# Console display driver support
#
CONFIG_DUMMY_CONSOLE=y
#
# Sound
#
# CONFIG_SOUND is not set
#
# USB support
#
# CONFIG_USB_ARCH_HAS_HCD is not set
# CONFIG_USB_ARCH_HAS_OHCI is not set
#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
#
#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set
#
# MMC/SD Card support
#
# CONFIG_MMC is not set
#
# InfiniBand support
#
#
# SN Devices
#
#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
# CONFIG_EXT2_FS_SECURITY is not set
CONFIG_EXT2_FS_XIP=y
CONFIG_FS_XIP=y
# CONFIG_EXT3_FS is not set
# CONFIG_JBD is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_INOTIFY is not set
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
CONFIG_AUTOFS_FS=y
CONFIG_AUTOFS4_FS=y
# CONFIG_FUSE_FS is not set
#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set
#
# DOS/FAT/NT Filesystems
#
# CONFIG_MSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_NTFS_FS is not set
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
# CONFIG_PROC_KCORE is not set
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
# CONFIG_RELAYFS_FS is not set
#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
#
# Network File Systems
#
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=y
CONFIG_NFS_DIRECTIO=y
# CONFIG_NFSD is not set
CONFIG_ROOT_NFS=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_ACL_SUPPORT=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
CONFIG_SUNRPC_GSS=y
CONFIG_RPCSEC_GSS_KRB5=y
# CONFIG_RPCSEC_GSS_SPKM3 is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
# CONFIG_9P_FS is not set
#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
#
# Native Language Support
#
# CONFIG_NLS is not set
#
# IBM 40x options
#
#
# Library routines
#
# CONFIG_CRC_CCITT is not set
# CONFIG_CRC16 is not set
CONFIG_CRC32=y
# CONFIG_LIBCRC32C is not set
# CONFIG_PROFILING is not set
#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_MAGIC_SYSRQ is not set
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_DETECT_SOFTLOCKUP is not set
# CONFIG_SCHEDSTATS is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_FS is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_KGDB is not set
# CONFIG_XMON is not set
CONFIG_BDI_SWITCH=y
CONFIG_SERIAL_TEXT_DEBUG=y
CONFIG_PPC_OCP=y
#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set
#
# Cryptographic options
#
CONFIG_CRYPTO=y
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=y
# CONFIG_CRYPTO_SHA1 is not set
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_WP512 is not set
# CONFIG_CRYPTO_TGR192 is not set
CONFIG_CRYPTO_DES=y
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_AES is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_DEFLATE is not set
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_TEST is not set
#
# Hardware crypto devices
#
Zhou Rui
Distributed & Embedded System Lab
School of Information Science & Engineering
Lanzhou University, P. R. China
http://dslab.lzu.edu.cn/~zr/
---------------------------------
抢注雅虎免费邮箱-3.5G容量，20M附件！
[-- Attachment #2: Type: text/html, Size: 17050 bytes --]
^ permalink raw reply
* Re: uboot environment variables size for Yosemite board.
From: John Otken @ 2006-07-17 11:02 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Leonid, linuxppc-embedded
In-Reply-To: <20060717070018.21ED1353C61@atlas.denx.de>
Wolfgang Denk wrote:
> In message <FAB00A8DC59FAB42B13C2B3B0F6877010D14478B@ehost011-3.exch011.intermedia.net> you wrote:
>> I'm using uboot-1.1.4 for AMCC PPC440E Yosemite board. I've downloaded
>
> Note that this is off topic here. You should have posted this on the
> U-Boot-Users mailing list instead.
>
>> this uboot from DENX site. It uses EEPROM to store environment
>> variables. Since EEPROM on Yosemite board is only 512 bytes, there can
>> not be more environment variables which is not very convenient.
>
> Thisi s wrong. The Yosemite configuration uses (like most (all?) AMCC
> eval boards - two redundand flash sectors to store the environment.
> And available environment size is 8 kB:
He has an older Yosemite. The original Yosemite U-Boot used the EEPROM
for environment variables.
> => print
> ...
> Environment size: 1355/8187 bytes
>
>> There is theoretical possibility to save these variables on flash (64M
>> from which I use only part) and yosemite.h header file even has defines,
>> allowing this option. But is it going work in reality? What is simplest
>> way for Yosemite board to increase environment variables storage space?
>
> I have no idea where you got your board configuration from, but it is
> definitely not current code, nor the binary image at
> ftp://ftp.denx.de/pub/u-boot/images/amcc/yosemite/u-boot.bin
>
> The current code does use (redundand) flash for environment storage.
>
> Best regards,
>
> Wolfgang Denk
>
^ permalink raw reply
* [PATCH] panic_on_oops: remove ssleep()
From: Horms @ 2006-07-17 16:17 UTC (permalink / raw)
To: Russell King, Tony Luck, Paul Mackerras, Anton Blanchard,
Andi Kleen, Chris Zankel, Andrew Morton
Cc: linuxppc-dev, linux-ia64, linux-kernel, discuss
This patch is part of an effort to unify the panic_on_oops behaviour
across all architectures that implement it.
It was pointed out to me by Andi Kleen that if an oops has occured
in interrupt context, then calling sleep() in the oops path will only cause
a panic, and that it would be really better for it not to be in the path at
all.
This patch removes the ssleep() call and reworks the console message
accordinly. I have a slght concern that the resulting console message is
too long, feedback welcome.
For powerpc it also unifies the 32bit and 64bit behaviour.
Fror x86_64, this patch only updates the console message, as
ssleep() is already not present.
Signed-Off-By: Horms <horms@verge.net.au>
arch/arm/kernel/traps.c | 7 ++-----
arch/i386/kernel/traps.c | 8 +++-----
arch/ia64/kernel/traps.c | 7 ++-----
arch/powerpc/kernel/traps.c | 10 +++-------
arch/x86_64/kernel/traps.c | 2 +-
arch/xtensa/kernel/traps.c | 8 +++-----
6 files changed, 14 insertions(+), 28 deletions(-)
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -232,11 +232,8 @@ NORET_TYPE void die(const char *str, str
bust_spinlocks(0);
spin_unlock_irq(&die_lock);
- if (panic_on_oops) {
- printk(KERN_EMERG "Fatal exception: panic in 5 seconds\n");
- ssleep(5);
- panic("Fatal exception");
- }
+ if (panic_on_oops)
+ panic("Fatal exception: panic_on_oops");
do_exit(SIGSEGV);
}
--- a/arch/i386/kernel/traps.c
+++ b/arch/i386/kernel/traps.c
@@ -442,11 +442,9 @@ #endif
if (in_interrupt())
panic("Fatal exception in interrupt");
- if (panic_on_oops) {
- printk(KERN_EMERG "Fatal exception: panic in 5 seconds\n");
- ssleep(5);
- panic("Fatal exception");
- }
+ if (panic_on_oops)
+ panic("Fatal exception: panic_on_oops");
+
oops_exit();
do_exit(SIGSEGV);
}
--- a/arch/ia64/kernel/traps.c
+++ b/arch/ia64/kernel/traps.c
@@ -117,11 +117,8 @@ die (const char *str, struct pt_regs *re
die.lock_owner = -1;
spin_unlock_irq(&die.lock);
- if (panic_on_oops) {
- printk(KERN_EMERG "Fatal exception: panic in 5 seconds\n");
- ssleep(5);
- panic("Fatal exception");
- }
+ if (panic_on_oops)
+ panic("Fatal exception: panic_on_oops");
do_exit(SIGSEGV);
}
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -150,13 +150,9 @@ #endif
if (in_interrupt())
panic("Fatal exception in interrupt");
- if (panic_on_oops) {
-#ifdef CONFIG_PPC64
- printk(KERN_EMERG "Fatal exception: panic in 5 seconds\n");
- ssleep(5);
-#endif
- panic("Fatal exception");
- }
+ if (panic_on_oops)
+ panic("Fatal exception: panic_on_oops");
+
do_exit(err);
return 0;
--- a/arch/x86_64/kernel/traps.c
+++ b/arch/x86_64/kernel/traps.c
@@ -521,7 +521,7 @@ void __kprobes oops_end(unsigned long fl
/* Nest count reaches zero, release the lock. */
spin_unlock_irqrestore(&die_lock, flags);
if (panic_on_oops)
- panic("Oops");
+ panic("Fatal exception: panic_on_oops");
}
void __kprobes __die(const char * str, struct pt_regs * regs, long err)
--- a/arch/xtensa/kernel/traps.c
+++ b/arch/xtensa/kernel/traps.c
@@ -487,11 +487,9 @@ #endif
if (in_interrupt())
panic("Fatal exception in interrupt");
- if (panic_on_oops) {
- printk(KERN_EMERG "Fatal exception: panic in 5 seconds\n");
- ssleep(5);
- panic("Fatal exception");
- }
+ if (panic_on_oops)
+ panic("Fatal exception: panic_on_oops");
+
do_exit(err);
}
^ permalink raw reply
* XUP Linux Envirnment, Hi Everyone!
From: scott @ 2006-07-17 16:52 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2310 bytes --]
Hey list, I'm new here so I thought I'd introduce myself a bit. I'm a grad student at the University of Colorado Boulder, and am researching novel FPGA reconfiguration techniques this summer. Our focus is on Xilinx parts and their partial reconfiguration features. Our goal is to use active reconfiguration to move functional blocks around an FPGA as needed for space-based mission survivability.
Anyway, in order to do this I first need to get a Linux envirnment up and running on my Xilinx XUP board. This board has a Virtex II Pro FPGA with dual PPC405 cores built-in. I have a basic Linux install built up using the EMPART tutorial (http://www.cs.washington.edu/research/lis/empart/xup_ppc_linux.shtml) and other pages it references. I have followed these instructions exactly, including busybox and Linux kernel versions (1.1.0 and 2.4.26, respectively) and everything looks swell EXCEPT: I can't manage to communicate with my custom IP hanging off the OPB bus. Actually, I can't manage to communicate with any peripherals at all off the OPB bus.
As per the EMPART tutorial's recommendations, here's how I attempt IP access:
fd = open("/dev/mem", O_RDWR);
ptr = MAP_FAILED; // Initialize to bad value
ptr = (int *) mmap(0, 256, PROT_READ|PROT_WRITE, MAP_SHARED, fd, USER_LOGIC_BASEADDR);
if(ptr==MAP_FAILED) {
printf("Err: cannot access address!\n");
return -1;
}
*ptr = 0xA;
The mmap call appears to work, and returns a pointer to virtual memory that supposedly references the physical address my IP is located at. However, when I try to read or write to this pointer I just get a rather ambiguous "bus error".
Some random things I have tried:
- setting dugging for devfs
- returns no unusual messages
- numerous scans through kernel config params looking for some sort of MMU settings or something
- setting a pointer directly to the physical address of the peripheral
- yeah, right...
- mapping a pointer to another established IP, in this case UART
- same problem
Anyone have any experience with this topic? Any suggestions at all? Do you think it has something to do w/ the MMU of the PPC405, or am I way off base here? I know this isn't an FPGA forum, but then I don't think there exists a forum which exactly meets my needs. :)
Thanks much, --scott
[-- Attachment #2: Type: text/html, Size: 3989 bytes --]
^ permalink raw reply
* where is the kernel source for ppc embedded?(may sound stupid)
From: Lei Sun @ 2006-07-17 15:44 UTC (permalink / raw)
To: linuxppc-embedded
Hi:
I am taking another guys porting work, he downloaded 2.4.30 for ppc.
I was looking at http://www.denx.de/, and kernel.org, didn't feel like
it was from there, since the current source tree only have arch/ppc
directory, no other arch specific tree.
So where i should download 2.4.30 with all patch applied?
Thanks
ls
^ 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