* Re: stupid linker question.... to remove unused functions in the object file.
From: Becky Bruce @ 2006-07-24 20:54 UTC (permalink / raw)
To: Parav Pandit; +Cc: linuxppc-embedded
In-Reply-To: <20060724120712.15709.qmail@web36606.mail.mud.yahoo.com>
I believe you can use -ffunction-sections -Wl,--gc-sections when you
compile and link. If you have binutils prior to 2.16, this only
works with -static.
-B
On Jul 24, 2006, at 7:07 AM, Parav Pandit wrote:
> Hi,
>
> I have few functions in a C file but those are not
> called at present. Even though those function
> definitions are part of the object file.
> Those will be called later on.
>
> What CFLAGS should I pass to remove unused functions?
> I cannot enable -Ox at present to have any
> unpredictable behaviour.
>
> Regards,
> Parav Pandit
>
>
> --- Wade Maxfield <wmaxfield@gmail.com> wrote:
>
>> gcc -Wa,-alhs -g main.c >main.cs
>>
>> will put interleaved code/assembly into main.cs
>> file.
>>
>> wade
>>
>>
>>
>> On 7/21/06, Steve Iribarne (GMail)
>> <netstv@gmail.com> wrote:
>>>
>>> I forgot the flag that generates a list file that
>> has both assembly
>>> and c mixed in.
>>>
>>> Anyone?
>>>
>>> Thanks...
>>>
>>> -stv
>>> _______________________________________________
>>> Linuxppc-embedded mailing list
>>> Linuxppc-embedded@ozlabs.org
>>>
>>
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>
>>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>>
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: mpic discovery on JS20
From: Amos Waterland @ 2006-07-24 21:07 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <1153726896.12748.0.camel@localhost.localdomain>
On Mon, Jul 24, 2006 at 05:41:36PM +1000, Michael Ellerman wrote:
> On Thu, 2006-07-20 at 19:16 -0400, Amos Waterland wrote:
> > Current Linus and Paulus trees do this on JS20 blades with SLOF:
> >
> > Failed to locate the MPIC interrupt controller
> > PID hash table entries: 4096 (order: 12, 32768 bytes)
> > Maple: Found RTC at IO 0x1070
> > cpu 0x0: Vector: 700 (Program Check) at [c00000007ef83ab0]
> > pc: c00000000002e0c8: .mpic_request_ipis+0x34/0xc8
> > lr: c00000000036b484: .smp_mpic_probe+0x3c/0x58
> > sp: c00000007ef83d30
> > msr: 9000000000029032
> > current = 0xc00000000194d610
> > paca = 0xc00000000038f180
> > pid = 1, comm = swapper
> > kernel BUG in mpic_request_ipis at arch/powerpc/sysdev/mpic.c:1132!
>
> Does this help?
Yes, it does to some degree. Current paulus tree with your patch applied:
Built 1 zonelists. Total pages: 524288
Kernel command line:
mpic: Setting up MPIC " MPIC " version <unknown> at f8040000, max 28 CPUs
mpic: ISU size: 516, shift: 10, mask: 3ff
Badness in mpic_init at arch/powerpc/sysdev/mpic.c:875
Call Trace:
[C0000000004D3880] [C00000000000EEB8] .show_stack+0x68/0x1b0 (unreliable)
[C0000000004D3920] [C00000000001D558] .program_check_exception+0x1cc/0x598
[C0000000004D39F0] [C0000000000044EC] program_check_common+0xec/0x100
--- Exception: 700 at .mpic_init+0x5c/0x784
LR = .maple_init_IRQ+0x204/0x290
[C0000000004D3CE0] [C0000000004D3DB0] init_thread_union+0x3db0/0x4000
[C0000000004D3DB0] [C00000000036C130] .maple_init_IRQ+0x204/0x290
[C0000000004D3E80] [C000000000361A88] .init_IRQ+0x34/0x48
[C0000000004D3EF0] [C00000000035B6E0] .start_kernel+0x154/0x2b8
[C0000000004D3F90] [C0000000000084FC] .start_here_common+0x50/0x54
mpic: Initializing for 251 sources
mpic: Setting up HT PICs workarounds for U3/U4
mpic: - HT:01.0 [0xb8] vendor 1022 device 7450 has 4 irqs
mpic: - HT:02.0 [0xb8] vendor 1022 device 7450 has 4 irqs
mpic: - HT:03.0 [0xf0] vendor 1022 device 7460 has 24 irqs
PID hash table entries: 4096 (order: 12, 32768 bytes)
Maple: Found RTC at IO 0x1070
cpu 0x0: Vector: 0 at [c00000007ef83940]
pc: c0000000000216bc: .smp_call_function+0x18c/0x1e4
lr: c0000000000216bc: .smp_call_function+0x18c/0x1e4
sp: c00000007ef83ab0
msr: 9000000000009032
current = 0xc00000000194d610
paca = 0xc00000000038c180
pid = 1, comm = swapper
The warning is this:
WARN_ON(mpic->num_sources > MPIC_VEC_IPI_0);
^ permalink raw reply
* Re: mpic discovery on JS20
From: Amos Waterland @ 2006-07-24 21:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1153503476.16159.13.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 548 bytes --]
***********************
Warning: Your file, js20-devtree.tar.gz, contains more than 32 files after decompression and cannot be scanned.
***********************
On Fri, Jul 21, 2006 at 01:37:56PM -0400, Benjamin Herrenschmidt wrote:
> On Thu, 2006-07-20 at 19:16 -0400, Amos Waterland wrote:
> > Current Linus and Paulus trees do this on JS20 blades with SLOF:
>
> I need a tarball of /proc/device-tree on these.
I booted 2.6.17-rc2 and tarred up /proc/device-tree. Since the
compressed tarball is only 4KB I have attached it to this email.
[-- Attachment #2: js20-devtree.tar.gz --]
[-- Type: application/octet-stream, Size: 4747 bytes --]
^ permalink raw reply
* Re: mpic discovery on JS20
From: Michael Ellerman @ 2006-07-25 1:54 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <F6DE334F-39D9-4302-B21C-3701BB78C8F0@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 499 bytes --]
On Mon, 2006-07-24 at 20:20 +0200, Segher Boessenkool wrote:
> > Does this help?
>
> Yes it does. I thought that went upstream already though?
Doh, pays to read the mailing list huh :)
It's probably sitting in Paul's inbox, waiting for him to merge it.
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: Why the "opd" section?
From: Alan Modra @ 2006-07-25 2:15 UTC (permalink / raw)
To: Jonathan Bartlett; +Cc: linuxppc-dev
In-Reply-To: <Pine.SUN.4.58.0607232059070.699@eskimo.com>
On Sun, Jul 23, 2006 at 09:01:38PM -0700, Jonathan Bartlett wrote:
> I'm learning PPC64 assembly language, and I found the existence of the
> "opd" sections containing function descriptors quite odd. What is the use
> of these? Are they used by the linker? Why are they needed in the 64-bit
> ELF platforms and not the 32-bit ones?
OPD is an array of function pointers. Function pointers on powerpc64
are not just simple pointers to some code; They specify the code entry
point, the TOC pointer, and the static chain pointer (unused by C).
To call a function, you need to know all these values because functions
do not initialise their own TOC pointer. This allows for more efficient
code. The compiler/linker can omit the TOC pointer load when both
caller and callee are known to share the same TOC. (In many ways, the
TOC is like the powerpc32 GOT. powerpc32 -fpic/PIC code initialises the
GOT pointer on entry to every function, even when caller and callee are
known to have the same GOT pointer.)
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply
* Re: powermac: More powermac backlight fixes
From: Andrew Morton @ 2006-07-25 3:03 UTC (permalink / raw)
To: Michael Hanselmann; +Cc: linuxppc-dev, johannes, aris, linux-kernel
In-Reply-To: <20060715130900.GA29287@hansmi.ch>
On Sat, 15 Jul 2006 15:09:00 +0200
Michael Hanselmann <linux-kernel@hansmi.ch> wrote:
> This patch fixes several problems:
> - The legacy backlight value might be set at interrupt time. Introduced
> a worker to prevent it from directly calling the backlight code.
> - via-pmu allows the backlight to be grabbed, in which case we need to
> prevent other kernel code from changing the brightness.
> - Don't send PMU requests in via-pmu-backlight when the machine is about
> to sleep or waking up.
> - More Kconfig fixes.
>
> ...
>
> static void pmac_backlight_key_worker(void *data);
> +static void pmac_backlight_set_legacy_worker(void *data);
> +
> static DECLARE_WORK(pmac_backlight_key_work, pmac_backlight_key_worker, NULL);
> +static DECLARE_WORK(pmac_backlight_set_legacy_work, pmac_backlight_set_legacy_worker, NULL);
I see schedule_work()s in there, but no flush_scheduled_work()s or anything
like that. Generally, this means there are races against rmmod, close(),
etc.
>
> +void pmac_backlight_disable()
> +{
> + atomic_inc(&kernel_backlight_disabled);
> +}
> +
> +void pmac_backlight_enable()
> +{
> + atomic_dec(&kernel_backlight_disabled);
> +}
> +
So if userspace calls ioctl(PMU_IOC_GRAB_BACKLIGHT) eleven times, eleven
enables are needed? (Actually, eleven open()/close() sequences, I think).
Methinks you wanted just
kernel_backlight_disabled = 1;
?
^ permalink raw reply
* Re: mpic discovery on JS20
From: Segher Boessenkool @ 2006-07-25 3:41 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev
In-Reply-To: <1153792498.7557.1.camel@localhost.localdomain>
>>> Does this help?
>>
>> Yes it does. I thought that went upstream already though?
>
> Doh, pays to read the mailing list huh :)
>
> It's probably sitting in Paul's inbox, waiting for him to merge it.
I could have sworn it went in, I don't see it anymore though.
More patches are needed anyway, I'll take care of it ASAP.
Segher
^ permalink raw reply
* Re: Reg. virtual address space in embedded linux
From: David H. Lynch Jr. @ 2006-07-25 4:03 UTC (permalink / raw)
To: jagannathanjay, linuxppc-embedded
In-Reply-To: <8C87B6A995C6521-1C74-11273@FWM-M25.sysops.aol.com>
[-- Attachment #1: Type: text/plain, Size: 3255 bytes --]
Is there a reason you need to map and unmap physical/virtual memory
every time you do a read or write ?
I think the norm is to map the physical region in your device driver
in its initialization code and unmap it if the driver exits.
After that you should be able to read and write your chip as you
wish. If the registers are RW then you should be able to "dump" them by
reading them at whatever later time you choose.
jagannathanjay@aim.com wrote:
> Hi all
>
> We are porting third party driver code from vxworks to Embedded linux
> in MPC 8260 under a evaluation platform from Embedded Planet in linux
> kernel space.
>
> The first step we carried out was reading the chip id and we were able
> to read the chip id correctly.
>
> For reading the chip id we used the routine ChipReadMemory in the
> attached text and we were able to retrive the chip id successfully.
>
> Subsequently when we write and read from Chip Specific Control Status
> registers ,it didn't work.
>
> I checked the manual and the Chip Specific Control Status registers
> have RW access.
>
> Any inputs on how to check if the write we made to virtual address
> succeeds?
>
> Is there a way to dump the linux virtual address and examine the write
> we made ?
>
> Regards
> Jay
>
>
> ------------------------------------------------------------------------
> *Check Out the new free AIM(R) Mail*
> <http://pr.atwola.com/promoclk/100122638x1081283466x1074645346/aol?redir=http%3A%2F%2Fwww%2Eaim%2Ecom%2Ffun%2Fmail%2F>
> -- 2 GB of storage and industry-leading spam and email virus protection.
> ------------------------------------------------------------------------
>
> int ChipReadMemory(unsigned int arg_phys_addr,unsigned int *memValue)
> {
> void *virt_addr = NULL;
> unsigned int phys_addr = 0;
>
> phys_addr = DEVICE_BASE_ADDRESS + arg_phys_addr;
> virt_addr = ioremap(phys_addr, 4);
> if(virt_addr == NULL)
> {
> printk("ChipReadMemory: unable to perform ioremap \n");
> return -1;
> }
> *memValue = readl(virt_addr);
> iounmap(virt_addr);
> return 0;
> }
>
>
> int ChipWriteMemory(unsigned int arg_phys_addr, unsigned int arg_val)
> {
> void *virt_addr = NULL;
> unsigned int phys_addr = 0;
> phys_addr = DEVICE_BASE_ADDRESS + arg_phys_addr;
> virt_addr = ioremap(phys_addr, 4);
> if(virt_addr == NULL)
> {
> printk("ChipWriteMemory : unable to perform ioremap \n");
> return -1;
> }
> writel(arg_val,virt_addr);
> iounmap(virt_addr);
> return 0;
> }
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
--
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: 4965 bytes --]
^ permalink raw reply
* Re: PHY Howto ?
From: David H. Lynch Jr. @ 2006-07-25 4:05 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded
In-Reply-To: <20060720220136.29326857@vitb.ru.mvista.com>
[-- Attachment #1: Type: text/plain, Size: 2125 bytes --]
Vitaly Bordug wrote:
> On Thu, 20 Jul 2006 13:52:47 -0400
> "David H. Lynch Jr." <dhlii@dlasys.net> wrote:
>
>
>> If I am writing a network MAC driver, for hardware that has a phy
>> that is already supported, if I provide the appropriate mdio_read() and
>> mdio_write() calls to access the phy registers, and setup my config to
>> include phylib and drivers for my specific phy, what else do I have to
>> take care of with respect to the phy within my driver ?
>>
>> Are there some resources, howto's, examples, ... demonstrating
>> how to use phylib ?
>>
> There is pretty good writeup in Documentation about your concern, find it at
> Documentation/networking/phy.txt . Live example is obviously drivers/net/gianfar*
>
>
>
Thanks that proved useful. I am already using gianfar as a reference
- but it is not a NIC I am familiar with.
And I still have some questions:
What is the distinction/interaction between phylib and MII
support ?
Are they independent ways of doing something similar ? Or do
they work together.
To get MII working I need to provide/populate an mii_if_info
structure and supply register read/write routines.
Since communicating with the PHY is MAC dependent shouldn't I
need to do the same for PHYLIB ?
As I understand it although PHY's are similar, and the same
PHY may be used on different NIC's
Communications to the PHY typically go through the NIC.
So my Network driver has to provide routines to read/write the
registers of the PHY, which phylib and the phy driver then use.
--
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: 3352 bytes --]
^ permalink raw reply
* unsubscribe
From: umesh k @ 2006-07-25 4:32 UTC (permalink / raw)
To: Linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 105 bytes --]
---------------------------------
Find out what India is talking about on Yahoo! Answers India.
[-- Attachment #2: Type: text/html, Size: 190 bytes --]
^ permalink raw reply
* Re: [PATCH] reorg RTAS delay code
From: Haren Myneni @ 2006-07-25 4:39 UTC (permalink / raw)
To: Nathan Lynch; +Cc: External List, Paul Mackerras, Milton Miller II
In-Reply-To: <20060713182016.GH19076@localdomain>
Nathan Lynch wrote:
>Hi folks-
>
>John Rose wrote:
>
>
>>This patch attempts to handle RTAS "busy" return codes in a more simple
>>and consistent manner. Typical callers of RTAS shouldn't have to
>>manage wait times and delay calls.
>>
>>This patch also changes the kernel to use msleep() rather than udelay()
>>when a runtime delay is necessary. This will avoid CPU soft lockups
>>for extended delay conditions.
>>
>>
>
>...
>
>
>
>>+/* For an RTAS busy status code, perform the hinted delay. */
>>+unsigned int rtas_busy_delay(int status)
>>+{
>>+ unsigned int ms;
>>
>>- /* Use microseconds for reasonable accuracy */
>>- for (ms = 1; order > 0; order--)
>>- ms *= 10;
>>+ might_sleep();
>>+ ms = rtas_busy_delay_time(status);
>>+ if (ms)
>>+ msleep(ms);
>>
>>- return ms;
>>+ return ms;
>> }
>>
>>
>
>So I managed to test this with cpu hotplug recently and the
>might_sleep warning triggers in the cpu offline path (I had to
>reconstruct this from xmon due to the kernel crashing later on for a
>different reason, so it might be a little off):
>
>BUG: sleeping function called from invalid context at arch/powerpc/kernel/rtas.c:463.
>in_atomic():1, irqs_disabled():1.
>Call Trace:
>[C0000000AAD379A0] [C000000000010ADC] .show_stack+0x68/0x1b4 (unreliable)
>[C0000000AAD37A50] [C000000000050C98] .__might_sleep+0xd0/0xec
>[C0000000AAD37AE0] [C00000000001DF5C] .rtas_busy_delay+0x20/0x54
>[C0000000AAD37B70] [C00000000001E2D0] .rtas_set_indicator+0x70/0xd4
>[C0000000AAD37C10] [C0000000000491C8] .xics_migrate_irqs_away+0x78/0x228
>[C0000000AAD37CD0] [C000000000047C14] .pSeries_cpu_disable+0x98/0xb4
>[C0000000AAD37D50] [C000000000029A5C] .__cpu_disable+0x4c/0x60
>[C0000000AAD37DC0] [C000000000080834] .take_cpu_down+0x10/0x38
>[C0000000AAD37E40] [C00000000008D1C0] .do_stop+0x198/0x248
>[C0000000AAD37EE0] [C000000000078124] .kthread+0x124/0x174
>[C0000000AAD37F90] [C000000000026568] .kernel_thread+0x4c/0x68
>
>
>As it turns out, set-indicator is not allowed to return a busy delay
>in this context, so we're actually safe here. Maybe we need an
>rtas_set_indicator_fast which could take that into account, e.g.
>
>int rtas_set_indicator_fast(int indicator, int index, int new_value)
>{
> int token = rtas_token("set-indicator");
> int rc;
>
> rc = rtas_call(token, 3, 1, NULL, indicator, index, new_value);
>
> WARN_ON(rc == -2 || rc >= 9000 || rc <= 9005);
>
> if (rc < 0)
> return rtas_error_rc(rc);
> return rc;
>}
>
>
>
>
Hi, I am also noticing the similar stack trace from __might_sleep() for
kdump boot. Before attempts kexec boot, kdump code calls
rtas_set_indicator() from xics_teardown_cpu(). Also, might_sleep()
calls might_resched() -> cond_resched(). What about when the preemption
is enabled? will the CPU get scheduled on another task?
Can we have separate function rtas_set_indicator_fast() as mentioned
above or
int rtas_set_indicator(int indicator, int index, int new_value, int
sleep_on_delay)
{
int token = rtas_token("set-indicator");
int rc;
if (token == RTAS_UNKNOWN_SERVICE)
return -ENOENT;
rc = rtas_call(token, 3, 1, NULL, indicator, index, new_value);
if (!sleep_on_delay)
WARN_ON(rc == -2 || rc >= 9000 || rc <= 9005);
else
while (rtas_busy_delay(rc))
rc = rtas_call(token, 3, 1, NULL, indicator, index,
new_value);
if (rc < 0)
return rtas_error_rc(rc);
return rc;
}
Thanks
Haren
>_______________________________________________
>Linuxppc-dev mailing list
>Linuxppc-dev@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
^ permalink raw reply
* DMA buffer synchronisation
From: Phil Nitschke @ 2006-07-25 9:09 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I'm transferring data using DMA from a custom PCI device memory into
RAM. Can someone advise me on the correct buffer synchronisation
strategy for the following 3 scenarios:
Assuming I have three buffers, buf_A, and buf_B, both created using
dma_alloc_noncoherent(NULL, 32 * PAGE_SIZE, ...), and buf_C (much
larger), remapped into the processor's virtual address space using
ioremap(), and 'n' is the number of bytes to copy using DMA channel
'dmanr', ...
1/. DMA copy from PCI device memory into buf_B:
/* ...prepare DMA engine, then: */
WARN_ON(buf_B != L1_CACHE_ALIGN(buf_B));
dma_sync_single_range_for_device(NULL, buf_B, 0, n, DMA_FROM_DEVICE);
mv64x6x_enable_dma(dmanr);
wait_for_completion_interruptible_timeout(...)
dma_sync_single_range_for_cpu(NULL, buf_B, 0, n, DMA_FROM_DEVICE);
2/. DMA copy from buf_A to buf_B (same as above, except now sync the src
buffer prior to DMA):
/* ...prepare DMA engine, check buffer alignment (x2), then: */
dma_sync_single_range_for_device(NULL, buf_A, 0, n, DMA_TO_DEVICE);
dma_sync_single_range_for_device(NULL, buf_B, 0, n, DMA_FROM_DEVICE);
mv64x6x_enable_dma(dmanr);
wait_for_completion_interruptible_timeout(...)
dma_sync_single_range_for_cpu(NULL, buf_B, 0, n, DMA_FROM_DEVICE);
3/. DMA from PCI device memory into ioremap()'ed buffer, buf_C:
/* ...prepare DMA engine, check buffer alignment, then: */
/* No buffer sync-ing is required? */
mv64x6x_enable_dma(dmanr);
wait_for_completion_interruptible_timeout(...)
/* No buffer sync'ing is required? */
Will this approach work (particularly case 3/.)? I tried dma_sync-ing
the region, but got an 'oops' (kernel access of bad area).
I'm using the 2.6.16 kernel (compiled with CONFIG_NOT_COHERENT_CACHE
defined) on an Artesyn PmPPC7448 processor. The processor utilises its
Marvell MV64460 as the DMA controller for the transaction.
Thanks,
--
Phil
^ permalink raw reply
* implementing errata for ML403 board / PPC405F6 core
From: Yogi Rajpal @ 2006-07-25 12:39 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 561 bytes --]
Hi,
I am following the errata at the following location and need to implement CPU_162, CPU_197 & CPU_212 for PPC405F6X1 core on Xilinx Ml403 board
( ftp://ftp.xilinx.com/pub/documentation/misc/ppc405f6v5_2_0.pdf )
Can anyone suggest the instructions needed to be implemented for these errata.
CPU_162 : When in Real Mode , the 405 core may errantly make speculative instruction fetches from guarded storage.
CPU_197 : Incorrect Real mode attributes may be used when accessing the last instruction in a 128 MB region.
CPU_212
thanks
yogi
[-- Attachment #2: Type: text/html, Size: 1098 bytes --]
^ permalink raw reply
* Re: Why the "opd" section?
From: Jonathan Bartlett @ 2006-07-25 13:23 UTC (permalink / raw)
To: Alan Modra; +Cc: linuxppc-dev
In-Reply-To: <20060725021558.GG6872@bubble.grove.modra.org>
> OPD is an array of function pointers. Function pointers on powerpc64
> are not just simple pointers to some code; They specify the code entry
> point, the TOC pointer, and the static chain pointer (unused by C).
> To call a function, you need to know all these values because functions
> do not initialise their own TOC pointer. This allows for more efficient
> code. The compiler/linker can omit the TOC pointer load when both
> caller and callee are known to share the same TOC. (In many ways, the
> TOC is like the powerpc32 GOT. powerpc32 -fpic/PIC code initialises the
> GOT pointer on entry to every function, even when caller and callee are
> known to have the same GOT pointer.)
So, why is it only in the 64-bit ELF? Is it just because it's a newer
idea?
Also, I tried compiling this piece of code in its own file:
int addtwo(int a)
{
int b = addone(a);
return addone(b);
}
I compiled it with "gcc -m64 -shared -fPIC -O3 -S tmp.c"
The resulting code had the following as it's compilation:
mflr 0
std 0,16(1)
stdu 1,-112(1)
bl addone
nop
bl addone
nop
addi 1,1,112
ld 0,16(1)
mtlr 0
blr
It seems to be branching _directly_ to the opd entry, instead of the
address pointed to by the opd entry. Also, the TOC pointer is never used,
despite the fact that these were separately compiled. Or is this taken
care of by the linker? Under what conditions would the TOC pointer be
different?
I'm new to PPC assembly, and a little confused. So any help would be
appreciated.
Thanks for your time,
Jon
^ permalink raw reply
* Re: Why the "opd" section?
From: Alan Modra @ 2006-07-25 14:06 UTC (permalink / raw)
To: Jonathan Bartlett; +Cc: linuxppc-dev
In-Reply-To: <Pine.SUN.4.58.0607250612510.14690@eskimo.com>
On Tue, Jul 25, 2006 at 06:23:30AM -0700, Jonathan Bartlett wrote:
> > OPD is an array of function pointers. Function pointers on powerpc64
> > are not just simple pointers to some code; They specify the code entry
> > point, the TOC pointer, and the static chain pointer (unused by C).
> > To call a function, you need to know all these values because functions
> > do not initialise their own TOC pointer. This allows for more efficient
> > code. The compiler/linker can omit the TOC pointer load when both
> > caller and callee are known to share the same TOC. (In many ways, the
> > TOC is like the powerpc32 GOT. powerpc32 -fpic/PIC code initialises the
> > GOT pointer on entry to every function, even when caller and callee are
> > known to have the same GOT pointer.)
>
> So, why is it only in the 64-bit ELF? Is it just because it's a newer
> idea?
The idea isn't exactly new. It's more the case that the powerpc32 ABI
is so old.
> Also, I tried compiling this piece of code in its own file:
>
> int addtwo(int a)
> {
> int b = addone(a);
> return addone(b);
> }
>
> I compiled it with "gcc -m64 -shared -fPIC -O3 -S tmp.c"
>
> The resulting code had the following as it's compilation:
>
> mflr 0
> std 0,16(1)
> stdu 1,-112(1)
> bl addone
> nop
> bl addone
> nop
> addi 1,1,112
> ld 0,16(1)
> mtlr 0
> blr
>
> It seems to be branching _directly_ to the opd entry, instead of the
> address pointed to by the opd entry. Also, the TOC pointer is never used,
> despite the fact that these were separately compiled. Or is this taken
> care of by the linker? Under what conditions would the TOC pointer be
> different?
Yes, you're right. It does look to be branching directly to the opd
entry at the assembly level. It of course won't do that because
powerpc64-ld is clever enough to realise that doing so would never make
any sense. Instead, ld does the OPD lookup and modifies the "bl" insns
to go directly to the function's code entry if the TOC vallue of caller
and callee is identical, or to go via a linker generated stub if they
are different.
A number of different stubs might be used. For a large statically
linked program where TOC size exceeds 64k, ld groups functions such that
each group uses a TOC of less than 64k, and inserts r2 adjusting stubs
between calls from one group to another. For calls to shared library
functions, ld inserts plt call stubs that load an opd entry from the
plt. See binutils bfd/elf64-ppc.c if you want all the gory details on
stubs.
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply
* Re: [Alsa-devel] [PATCH 0/5] powerpc sound, some more patches
From: Takashi Iwai @ 2006-07-25 14:17 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <20060718172841.046446000@sipsolutions.net>
At Tue, 18 Jul 2006 19:28:41 +0200,
Johannes Berg wrote:
>
> Here's a new and hopefully final round of patches fixing problems with my
> new snd-aoa driver. There are fixes for the PPC Mac Mini as well as for a
> problem with snd-powermac that I had noticed.
Thanks, now all patches are on ALSA tree.
Takashi
^ permalink raw reply
* Re: [PATCH] clean up pseries hcall interfaces
From: Anton Blanchard @ 2006-07-25 14:41 UTC (permalink / raw)
To: Levand, Geoffrey; +Cc: linuxppc-dev, paulus
In-Reply-To: <591B6A09961C354991CD653B274DC8C2023662CB@ussdixms03.am.sony.com>
Hi Geoff,
> Seems like this in needed too... Untested.
Looks good but the patch appears to be line wrapped in a few places.
Anton
> Change the scope of some pSeries routines now called through
> ppc_md to static.
>
> Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
>
> --
> Index: a/arch/powerpc/platforms/pseries/lpar.c
> ===================================================================
> --- a.orig/arch/powerpc/platforms/pseries/lpar.c 2006-07-18
> 12:37:47.000000000 -0700
> +++ a/arch/powerpc/platforms/pseries/lpar.c 2006-07-20
> 05:18:59.000000000 -0700
> @@ -268,7 +268,7 @@
> cpu, hwcpu, vpa, ret);
> }
>
> -long pSeries_lpar_hpte_insert(unsigned long hpte_group,
> +static long pSeries_lpar_hpte_insert(unsigned long hpte_group,
> unsigned long va, unsigned long pa,
> unsigned long rflags, unsigned long
> vflags,
> int psize)
> @@ -494,7 +494,7 @@
> * Take a spinlock around flushes to avoid bouncing the hypervisor
> tlbie
> * lock.
> */
> -void pSeries_lpar_flush_hash_range(unsigned long number, int local)
> +static void pSeries_lpar_flush_hash_range(unsigned long number, int
> local)
> {
> int i;
> unsigned long flags = 0;
^ permalink raw reply
* Re: [Alsa-devel] [PATCH 0/5] powerpc sound, some more patches
From: Johannes Berg @ 2006-07-25 15:13 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <s5hy7uhsra7.wl%tiwai@suse.de>
Takashi Iwai wrote:
> Thanks, now all patches are on ALSA tree.
Thanks.
These should still go into 2.6.18, will that be possible?
johannes
^ permalink raw reply
* Re: [Alsa-devel] [PATCH 0/5] powerpc sound, some more patches
From: Takashi Iwai @ 2006-07-25 15:21 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <7015.131.234.232.48.1153840399.squirrel@secure.sipsolutions.net>
At Tue, 25 Jul 2006 17:13:19 +0200 (CEST),
Johannes Berg wrote:
>
> Takashi Iwai wrote:
>
> > Thanks, now all patches are on ALSA tree.
>
> Thanks.
> These should still go into 2.6.18, will that be possible?
Agreed.
Jaroslav, could you update alsa git tree for pushing?
We have ca. 20 pending fixes including these ppc-patches.
Takashi
^ permalink raw reply
* Slow boot with NFS, server not responding
From: Edward Jubenville @ 2006-07-25 16:27 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 4824 bytes --]
I am having trouble booting the kernel with a root file system over NFS.
Once the kernel has mounted the file system, it cycles through this pair of
messages, endlessly:
nfs: server 192.168.0.39 not responding, still trying
nfs: server 192.168.0.39 OK
I can't figure out if this is a configuration problem or a hardware problem
with our new board. Booting in EXTREMELY slow, but manages to make some
progress. At first, I thought that I had an NFS server configuration or
firewall problem. But eventually, I discovered that the kernel had some
success mounting the root file system because I started seeing messages from
the init scripts. Neither the BDI2000 or u-boot had any problem using the
network hardware, so I suspect something must be misconfigured in the
kernel. While these messages are appearing, I can ping the board without
any dropped packets.
The board is modeled after the Freescale Lite5200 (IceCube), but uses an
MPC5200B processor. The development environment is ELDK 3.1.1 with the
ELDK's CVS development tree of Linux 2.4.25.
Here is the console log during kernel startup...
I've also attached our kernel .config file.
****************************************
==> bootm 0xff100000
bootm 0xff100000
## Booting image at ff100000 ...
Image Name: Linux PPC MPC5200 2.4
Created: 2006-07-19 22:31:09 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 884063 Bytes = 863.3 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Memory BAT mapping: BAT2=64Mb, BAT3=0Mb, residual: 0Mb
Linux version 2.4.25 (ejubenville@cvs) (gcc version 3.3.3 (DENX ELDK 3.1.1
3.3.3-9)) #3 Wed Jul 19 15:30:56 PDT 2006
On node 0 totalpages: 16384
zone(0): 16384 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/nfs rw nfsroot=192.168.0.39:/opt/eldk/ppc_6xx
ip=192.168.0.73:192.168.0.39:192.168.0.3:255.255.255.0:mmt1::off
Calibrating delay loop... 307.20 BogoMIPS
Memory: 62176k available (1496k kernel code, 504k data, 76k init, 0k
highmem)
Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)
Inode cache hash table entries: 4096 (order: 3, 32768 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
POSIX conformance testing by UNIFIX
PCI: Probing PCI hardware
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
Journalled Block Device driver loaded
devfs: v1.12c (20020818) Richard Gooch (rgooch@atnf.csiro.au)
devfs: devfs_debug: 0x0
devfs: boot_options: 0x1
JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc.
pty: 256 Unix98 ptys configured
devfs_register(cua): could not append to parent, err: -17
devfs_register(cua): could not append to parent, err: -17
ttyS0 on PSC1
ttyS1 on PSC2
ttyS2 on PSC3
RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
loop: loaded (max 8 devices)
Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
Port Config is: 0x11050004
ipb=132MHz, set clock period to 7
GPIO config: 11050004
ATA invalid: 01000000
ATA hostcnf: 03000000
ATA pio1 : 100a0a00
ATA pio2 : 02040600
XLB Arb cnf: 0000a366
mpc5xxx_ide: Setting up IDE interface ide0...
ATA DMA task: 5
Probing IDE interface ide0...
hda: SanDisk SDCFB-4096, CFA DISK drive
hda: Setting MDMA 2 timings
hda: Setting PIO 4 timings
ide0 at 0xf0003a60-0xf0003a67,0xf0003a5c on irq 45
hda: attached ide-disk driver.
hda: 8005536 sectors (4099 MB) w/1KiB Cache, CHS=7942/16/63, DMA
Partition check:
/dev/ide/host0/bus0/target0/lun0:<7>Unhandled interrupt 1a, disabled
[PTBL] [992/128/63] p1
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind 8192)
eth0: Phy @ 0x0, type LXT971 (0x001378e2)
IP-Config: Complete:
device=eth0, addr=192.168.0.73, mask=255.255.255.0, gw=192.168.0.3,
host=mmt1, domain=, nis-domain=(none),
bootserver=192.168.0.39, rootserver=192.168.0.39, rootpath=
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Looking up port of RPC 100003/2 on 192.168.0.39
Looking up port of RPC 100005/1 on 192.168.0.39
VFS: Mounted root (nfs filesystem).
Mounted devfs on /dev
Freeing unused kernel memory: 76k init
nfs: server 192.168.0.39 not responding, still trying
nfs: server 192.168.0.39 OK
****************************************
The "not responding" and "OK" keep repeating at a slow rate,
eventually interspersed with messages from the init process.
Any help would be appreciated. Thanks.
Ed Jubenville
[-- Attachment #2: config.txt --]
[-- Type: text/plain, Size: 20312 bytes --]
#
# Automatically generated by make menuconfig: don't edit
#
# CONFIG_UID16 is not set
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_HAVE_DEC_LOCK=y
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_ADVANCED_OPTIONS=y
#
# Loadable module support
#
CONFIG_MODULES=y
# CONFIG_MODVERSIONS is not set
# CONFIG_KMOD is not set
#
# Platform support
#
CONFIG_PPC=y
CONFIG_PPC32=y
CONFIG_6xx=y
# CONFIG_40x is not set
# CONFIG_44x is not set
# CONFIG_E500 is not set
# CONFIG_POWER3 is not set
# CONFIG_POWER4 is not set
# CONFIG_8xx is not set
# CONFIG_8260 is not set
# CONFIG_83xx is not set
CONFIG_PPC_STD_MMU=y
# CONFIG_ALL_PPC is not set
# CONFIG_APUS is not set
# CONFIG_INKA4X0 is not set
# CONFIG_WILLOW is not set
# CONFIG_TOP5200 is not set
# CONFIG_CPCI690 is not set
# CONFIG_PCORE is not set
# CONFIG_POWERPMC250 is not set
# CONFIG_PPMC260 is not set
# CONFIG_EV64260 is not set
# CONFIG_SPRUCE is not set
# CONFIG_HMI1001 is not set
# CONFIG_PP01 is not set
# CONFIG_CPC45 is not set
# CONFIG_CU824 is not set
# CONFIG_PM520 is not set
# CONFIG_MCC200 is not set
# CONFIG_PUMA_A is not set
# CONFIG_ALASKA is not set
# CONFIG_GLACIER is not set
CONFIG_ICECUBE=y
# CONFIG_LITE5200B is not set
# CONFIG_HXEB100 is not set
# CONFIG_LOPEC is not set
# CONFIG_MCPN765 is not set
# CONFIG_MVME5100 is not set
# CONFIG_PPLUS is not set
# CONFIG_PRPMC750 is not set
# CONFIG_PRPMC800 is not set
# CONFIG_SANDPOINT is not set
# CONFIG_P3G4 is not set
# CONFIG_ADIR is not set
# CONFIG_K2 is not set
# CONFIG_PAL4 is not set
# CONFIG_SL8245 is not set
# CONFIG_SMMACO4 is not set
# CONFIG_GEMINI is not set
# CONFIG_TQM5200 is not set
# CONFIG_O2DNT is not set
# CONFIG_SORCERY is not set
CONFIG_PPC_5xxx=y
# CONFIG_SMP is not set
# CONFIG_ALTIVEC is not set
# CONFIG_TAU is not set
CONFIG_PPC_ISATIMER=y
# CONFIG_MPC5100 is not set
CONFIG_MPC5200=y
CONFIG_PPC_5xxx_PSC_CONSOLE_BAUD=115200
CONFIG_UBOOT=y
CONFIG_PPC_5xxx_PSC_CONSOLE_PORT=0
#
# General setup
#
# CONFIG_BIGPHYS_AREA is not set
# CONFIG_HIGHMEM is not set
# CONFIG_LOWMEM_SIZE_BOOL is not set
# CONFIG_KERNEL_START_BOOL is not set
# CONFIG_TASK_SIZE_BOOL is not set
CONFIG_HIGHMEM_START=0xfe000000
CONFIG_LOWMEM_SIZE=0x30000000
CONFIG_KERNEL_START=0xc0000000
CONFIG_TASK_SIZE=0x80000000
# CONFIG_ISA is not set
# CONFIG_EISA is not set
# CONFIG_SBUS is not set
# CONFIG_MCA is not set
CONFIG_PCI=y
CONFIG_NET=y
CONFIG_SYSCTL=y
CONFIG_SYSVIPC=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_KCORE_ELF=y
CONFIG_BINFMT_ELF=y
CONFIG_KERNEL_ELF=y
# CONFIG_BINFMT_MISC is not set
# CONFIG_OOM_KILLER is not set
# CONFIG_PCI_NAMES is not set
# CONFIG_HOTPLUG is not set
# CONFIG_PCMCIA is not set
#
# Parallel port support
#
# CONFIG_PARPORT is not set
# CONFIG_GEN_RTC is not set
CONFIG_PPC_RTC=y
CONFIG_CMDLINE_BOOL=y
CONFIG_CMDLINE="ip=off"
#
# Embedded options
#
# CONFIG_EMBEDDED is not set
#
# Memory Technology Devices (MTD)
#
CONFIG_MTD=y
# CONFIG_MTD_DEBUG is not set
CONFIG_MTD_PARTITIONS=y
# CONFIG_MTD_CONCAT is not set
# CONFIG_MTD_REDBOOT_PARTS is not set
# CONFIG_MTD_CMDLINE_PARTS is not set
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLOCK=y
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set
#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_GEN_PROBE=y
# CONFIG_MTD_CFI_ADV_OPTIONS is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_INTELEXT is not set
CONFIG_MTD_CFI_AMDSTD=y
# CONFIG_MTD_CFI_STAA is not set
CONFIG_MTD_CFI_UTIL=y
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set
# CONFIG_MTD_OBSOLETE_CHIPS is not set
# CONFIG_MTD_AMDSTD is not set
# CONFIG_MTD_SHARP is not set
# CONFIG_MTD_JEDEC is not set
#
# Mapping drivers for chip access
#
CONFIG_MTD_COMPLEX_MAPPINGS=y
# CONFIG_MTD_PHYSMAP is not set
# CONFIG_MTD_PUMA_A is not set
# CONFIG_MTD_CHESTNUT is not set
# CONFIG_MTD_K2 is not set
# CONFIG_MTD_HXEB100 is not set
# CONFIG_MTD_PPMC260 is not set
# CONFIG_MTD_CU824 is not set
# CONFIG_MTD_CPC45 is not set
# CONFIG_MTD_HMI1001 is not set
# CONFIG_MTD_ICECUBE is not set
# CONFIG_MTD_ICECUBE is not set
# CONFIG_MTD_INKA4X0 is not set
# CONFIG_MTD_O2DNT is not set
# CONFIG_MTD_P3G4 is not set
# CONFIG_MTD_PP01 is not set
# CONFIG_MTD_MCC200 is not set
# CONFIG_MTD_PM520 is not set
# CONFIG_MTD_SL8245 is not set
# CONFIG_MTD_SMMACO4 is not set
# CONFIG_MTD_SORCERY is not set
# CONFIG_MTD_TQM5200 is not set
# CONFIG_MTD_PCI is not set
# CONFIG_MTD_PCMCIA is not set
#
# Self-contained MTD device drivers
#
# CONFIG_MTD_PMC551 is not set
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLKMTD is not set
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOC2001PLUS is not set
# CONFIG_MTD_DOCPROBE is not set
# CONFIG_MTD_DOCECC is not set
#
# NAND Flash Device Drivers
#
# CONFIG_MTD_NAND is not set
# CONFIG_MTD_NAND_DISKONCHIP is not set
# CONFIG_MTD_NAND_NANDSIM is not set
#
# Plug and Play configuration
#
# CONFIG_PNP is not set
# CONFIG_ISAPNP is not set
#
# Block devices
#
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_DEV_XD is not set
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_CISS_SCSI_TAPE is not set
# CONFIG_CISS_MONITOR_THREAD is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_NBD is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=16384
CONFIG_BLK_DEV_INITRD=y
# CONFIG_BLK_STATS is not set
#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set
# CONFIG_BLK_DEV_MD is not set
# CONFIG_MD_LINEAR is not set
# CONFIG_MD_RAID0 is not set
# CONFIG_MD_RAID1 is not set
# CONFIG_MD_RAID5 is not set
# CONFIG_MD_MULTIPATH is not set
# CONFIG_BLK_DEV_LVM is not set
#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
# CONFIG_NETLINK_DEV is not set
# CONFIG_NETFILTER is not set
# CONFIG_FILTER is not set
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
# CONFIG_IP_PNP_BOOTP is not set
# CONFIG_IP_PNP_RARP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
# CONFIG_INET_ECN is not set
CONFIG_SYN_COOKIES=y
# CONFIG_IPV6 is not set
# CONFIG_KHTTPD is not set
#
# SCTP Configuration (EXPERIMENTAL)
#
CONFIG_IPV6_SCTP__=y
# CONFIG_IP_SCTP is not set
# CONFIG_ATM is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
#
# Appletalk devices
#
# CONFIG_DEV_APPLETALK is not set
# CONFIG_DECNET is not set
# CONFIG_BRIDGE is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_LLC is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_FASTROUTE is not set
# CONFIG_NET_HW_FLOWCONTROL is not set
#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
#
# ATA/IDE/MFM/RLL support
#
CONFIG_IDE=y
#
# IDE, ATA and ATAPI Block devices
#
CONFIG_BLK_DEV_IDE=y
# CONFIG_BLK_DEV_HD_IDE is not set
# CONFIG_BLK_DEV_HD is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_IDEDISK_STROKE=y
# CONFIG_BLK_DEV_IDECS is not set
CONFIG_BLK_DEV_IDECD=y
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
# CONFIG_BLK_DEV_IDESCSI is not set
# CONFIG_IDE_TASK_IOCTL is not set
# CONFIG_BLK_DEV_CMD640 is not set
# CONFIG_BLK_DEV_CMD640_ENHANCED is not set
# CONFIG_BLK_DEV_ISAPNP is not set
CONFIG_BLK_DEV_IDEPCI=y
# CONFIG_BLK_DEV_GENERIC is not set
# CONFIG_IDEPCI_SHARE_IRQ is not set
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_OFFBOARD is not set
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
# CONFIG_IDEDMA_PCI_AUTO is not set
# CONFIG_IDEDMA_ONLYDISK is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_PCI_WIP is not set
# CONFIG_BLK_DEV_ADMA100 is not set
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_WDC_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_AMD74XX_OVERRIDE is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_HPT34X_AUTODMA is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_PIIX is not set
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
# CONFIG_PDC202XX_BURST is not set
# CONFIG_BLK_DEV_PDC202XX_NEW is not set
# CONFIG_BLK_DEV_RZ1000 is not set
# CONFIG_BLK_DEV_SC1200 is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_VIA82CXXX is not set
# CONFIG_BLK_DEV_SL82C105 is not set
CONFIG_BLK_DEV_IDE_MPC5xxx=y
CONFIG_BLK_DEV_IDE_MPC5xxx_MDMA=y
CONFIG_BLK_DEV_IDE_MPC5xxx_UDMA=y
# CONFIG_IDE_CHIPSETS is not set
# CONFIG_IDEDMA_AUTO is not set
# CONFIG_IDEDMA_IVB is not set
# CONFIG_DMA_NONPCI is not set
# CONFIG_BLK_DEV_ATARAID is not set
# CONFIG_BLK_DEV_ATARAID_PDC is not set
# CONFIG_BLK_DEV_ATARAID_HPT is not set
# CONFIG_BLK_DEV_ATARAID_SII is not set
#
# SCSI support
#
# CONFIG_SCSI is not set
#
# Fusion MPT device support
#
# CONFIG_FUSION is not set
# CONFIG_FUSION_BOOT is not set
# CONFIG_FUSION_ISENSE is not set
# CONFIG_FUSION_CTL is not set
# CONFIG_FUSION_LAN is not set
#
# IEEE 1394 (FireWire) support (EXPERIMENTAL)
#
# CONFIG_IEEE1394 is not set
#
# I2O device support
#
# CONFIG_I2O is not set
# CONFIG_I2O_PCI is not set
# CONFIG_I2O_BLOCK is not set
# CONFIG_I2O_LAN is not set
# CONFIG_I2O_SCSI is not set
# CONFIG_I2O_PROC is not set
#
# Network device support
#
CONFIG_NETDEVICES=y
#
# ARCnet devices
#
# CONFIG_ARCNET is not set
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_ETHERTAP is not set
#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
# CONFIG_MACE is not set
# CONFIG_BMAC is not set
# CONFIG_GMAC is not set
# CONFIG_SUNLANCE is not set
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNBMAC is not set
# CONFIG_SUNQE is not set
# CONFIG_SUNGEM is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_LANCE is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set
# CONFIG_HP100 is not set
# CONFIG_NET_ISA is not set
# CONFIG_NET_PCI is not set
# CONFIG_NET_POCKET is not set
#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_MYRI_SBUS is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SK98LIN is not set
# CONFIG_TIGON3 is not set
# CONFIG_GIANFAR is not set
# CONFIG_GFAR_NAPI is not set
# CONFIG_GFAR_BDSTASH is not set
# CONFIG_GFAR_BUFSTASH is not set
# CONFIG_FDDI is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_HIPPI is not set
# CONFIG_PLIP is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set
#
# Token Ring devices
#
# CONFIG_TR is not set
# CONFIG_NET_FC is not set
# CONFIG_RCPCI is not set
# CONFIG_SHAPER is not set
#
# Wan interfaces
#
# CONFIG_WAN is not set
#
# Amateur Radio support
#
# CONFIG_HAMRADIO is not set
#
# IrDA (infrared) support
#
# CONFIG_IRDA is not set
#
# ISDN subsystem
#
# CONFIG_ISDN is not set
#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set
#
# Console drivers
#
# CONFIG_VGA_CONSOLE is not set
#
# Frame-buffer support
#
# CONFIG_FB is not set
#
# Input core support
#
# CONFIG_INPUT is not set
# CONFIG_INPUT_KEYBDEV is not set
# CONFIG_INPUT_MOUSEDEV is not set
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_UINPUT is not set
#
# Macintosh device drivers
#
#
# Character devices
#
# CONFIG_VT is not set
# CONFIG_SERIAL is not set
# CONFIG_SERIAL_EXTENDED is not set
CONFIG_SERIAL_NONSTANDARD=y
# CONFIG_COMPUTONE is not set
# CONFIG_ROCKETPORT is not set
# CONFIG_CYCLADES is not set
# CONFIG_DIGIEPCA is not set
# CONFIG_DIGI is not set
# CONFIG_ESPSERIAL is not set
# CONFIG_MOXA_INTELLIO is not set
# CONFIG_MOXA_SMARTIO is not set
# CONFIG_ISI is not set
# CONFIG_SYNCLINK is not set
# CONFIG_SYNCLINKMP is not set
# CONFIG_N_HDLC is not set
# CONFIG_RISCOM8 is not set
# CONFIG_SPECIALIX is not set
# CONFIG_SX is not set
# CONFIG_RIO is not set
# CONFIG_STALDRV is not set
# CONFIG_PS2MULT is not set
# CONFIG_KEYMAP_DE_LATIN1 is not set
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256
#
# I2C support
#
# CONFIG_I2C is not set
#
# SPI support
#
# CONFIG_SPI is not set
#
# Mice
#
# CONFIG_BUSMOUSE is not set
# CONFIG_MOUSE is not set
#
# Joysticks
#
# CONFIG_INPUT_GAMEPORT is not set
# CONFIG_QIC02_TAPE is not set
# CONFIG_IPMI_HANDLER is not set
# CONFIG_IPMI_PANIC_EVENT is not set
# CONFIG_IPMI_DEVICE_INTERFACE is not set
# CONFIG_IPMI_KCS is not set
# CONFIG_IPMI_WATCHDOG is not set
#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_SCx200 is not set
# CONFIG_SCx200_GPIO is not set
# CONFIG_AMD_PM768 is not set
# CONFIG_NVRAM is not set
# CONFIG_RTC is not set
# CONFIG_RTC_11_MINUTE_MODE is not set
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_FLASH is not set
#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
# CONFIG_AGP is not set
#
# Direct Rendering Manager (XFree86 DRI support)
#
# CONFIG_DRM is not set
#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
#
# File systems
#
# CONFIG_QUOTA is not set
# CONFIG_QFMT_V2 is not set
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_REISERFS_CHECK is not set
# CONFIG_REISERFS_PROC_INFO is not set
# CONFIG_ADFS_FS is not set
# CONFIG_ADFS_FS_RW 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_BEFS_DEBUG is not set
# CONFIG_BFS_FS is not set
CONFIG_EXT3_FS=y
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
# CONFIG_UMSDOS_FS is not set
CONFIG_VFAT_FS=y
# CONFIG_EFS_FS is not set
# CONFIG_JFFS_FS is not set
CONFIG_JFFS2_FS=y
CONFIG_JFFS2_FS_DEBUG=0
CONFIG_JFFS2_FS_WRITEBUFFER=y
CONFIG_JFFS2_ZLIB=y
CONFIG_JFFS2_RTIME=y
# CONFIG_JFFS2_RUBIN is not set
# CONFIG_JFFS2_LZO is not set
# CONFIG_JFFS2_LZARI is not set
# CONFIG_JFFS2_CMODE_NONE is not set
CONFIG_JFFS2_CMODE_PRIORITY=y
# CONFIG_JFFS2_CMODE_SIZE is not set
CONFIG_JFFS2_PROC=y
CONFIG_CRAMFS=y
CONFIG_TMPFS=y
CONFIG_RAMFS=y
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
# CONFIG_ZISOFS is not set
# CONFIG_JFS_FS is not set
# CONFIG_JFS_DEBUG is not set
# CONFIG_JFS_STATISTICS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_NTFS_FS is not set
# CONFIG_NTFS_RW is not set
# CONFIG_HPFS_FS is not set
CONFIG_PROC_FS=y
CONFIG_DEVFS_FS=y
CONFIG_DEVFS_MOUNT=y
CONFIG_DEVFS_DEBUG=y
CONFIG_DEVPTS_FS=y
# CONFIG_QNX4FS_FS is not set
# CONFIG_QNX4FS_RW is not set
CONFIG_ROMFS_FS=y
CONFIG_EXT2_FS=y
# CONFIG_SYSV_FS is not set
# CONFIG_UDF_FS is not set
# CONFIG_UDF_RW is not set
# CONFIG_UFS_FS is not set
# CONFIG_UFS_FS_WRITE is not set
# CONFIG_XFS_FS is not set
# CONFIG_XFS_QUOTA is not set
# CONFIG_XFS_RT is not set
# CONFIG_XFS_TRACE is not set
# CONFIG_XFS_DEBUG is not set
#
# Network File Systems
#
# CONFIG_CODA_FS is not set
# CONFIG_INTERMEZZO_FS is not set
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_NFS_DIRECTIO is not set
CONFIG_ROOT_NFS=y
# CONFIG_NFSD is not set
# CONFIG_NFSD_V3 is not set
# CONFIG_NFSD_TCP is not set
CONFIG_SUNRPC=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
# CONFIG_SMB_FS is not set
# CONFIG_NCP_FS is not set
# CONFIG_NCPFS_PACKET_SIGNING is not set
# CONFIG_NCPFS_IOCTL_LOCKING is not set
# CONFIG_NCPFS_STRONG is not set
# CONFIG_NCPFS_NFS_NS is not set
# CONFIG_NCPFS_OS2_NS is not set
# CONFIG_NCPFS_SMALLDOS is not set
# CONFIG_NCPFS_NLS is not set
# CONFIG_NCPFS_EXTRAS is not set
# CONFIG_ZISOFS_FS is not set
#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_EFI_PARTITION is not set
# CONFIG_SMB_NLS is not set
CONFIG_NLS=y
#
# Native Language Support
#
CONFIG_NLS_DEFAULT="iso8859-1"
# CONFIG_NLS_CODEPAGE_437 is not set
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=y
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set
#
# Sound
#
# CONFIG_SOUND is not set
#
# MPC5xxx I/O Options
#
CONFIG_BESTCOMM_API=y
CONFIG_PPC_5xxx_FEC=y
CONFIG_USE_MDIO=y
CONFIG_FEC_GENERIC_PHY=y
CONFIG_FEC_LXT971=y
# CONFIG_FEC_DP83847 is not set
# CONFIG_USB_USEBOTH is not set
CONFIG_PPC_5xxx_PSC=y
CONFIG_PPC_5xxx_PSC_CONSOLE=y
CONFIG_SERIAL_CONSOLE=y
# CONFIG_5200_I2S is not set
# CONFIG_5200_I2S_RING is not set
#
# USB support
#
# CONFIG_USB is not set
#
# Support for USB gadgets
#
# CONFIG_USB_GADGET is not set
#
# Bluetooth support
#
# CONFIG_BLUEZ is not set
#
# Cryptographic options
#
# CONFIG_CRYPTO is not set
#
# Library routines
#
# CONFIG_CRC32 is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
# CONFIG_REED_SOLOMON is not set
#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
# CONFIG_MAGIC_SYSRQ is not set
# CONFIG_DEBUG_HIGHMEM is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_IOVIRT is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_WAITQ is not set
# CONFIG_KGDB is not set
# CONFIG_XMON is not set
CONFIG_BDI_SWITCH=y
CONFIG_MORE_COMPILE_OPTIONS=y
CONFIG_COMPILE_OPTIONS="-g -ggdb"
# CONFIG_SERIAL_TEXT_DEBUG is not set
CONFIG_LOG_BUF_SHIFT=0
^ permalink raw reply
* Re: Slow boot with NFS, server not responding
From: Andrei Konovalov @ 2006-07-25 17:10 UTC (permalink / raw)
To: Edward Jubenville; +Cc: linuxppc-embedded
In-Reply-To: <GPECLCIGPLHEOMGPMCPAOEIIDNAA.edjubenville@adelphia.net>
Hi Edward,
Did you try using ethereal or tcpdump to see what is going on the wire?
I doubt this is your case, but once I've seen a similar behaviour (different
board and CPU!) when an ethernet controller had small Rx FIFO and no DMA, and the
driver was not able to read the first 1.5kB packet of the 4kB NFS read reply
out of the FIFO before the next portion of the same read reply overflows
the FIFO. This led to endless retransmissions etc.
pings are 56-byte + some overhead by default, so they worked OK.
Thanks,
Andrei
Edward Jubenville wrote:
> I am having trouble booting the kernel with a root file system over NFS.
> Once the kernel has mounted the file system, it cycles through this pair of
> messages, endlessly:
>
> nfs: server 192.168.0.39 not responding, still trying
> nfs: server 192.168.0.39 OK
>
> I can't figure out if this is a configuration problem or a hardware problem
> with our new board. Booting in EXTREMELY slow, but manages to make some
> progress. At first, I thought that I had an NFS server configuration or
> firewall problem. But eventually, I discovered that the kernel had some
> success mounting the root file system because I started seeing messages from
> the init scripts. Neither the BDI2000 or u-boot had any problem using the
> network hardware, so I suspect something must be misconfigured in the
> kernel. While these messages are appearing, I can ping the board without
> any dropped packets.
>
> The board is modeled after the Freescale Lite5200 (IceCube), but uses an
> MPC5200B processor. The development environment is ELDK 3.1.1 with the
> ELDK's CVS development tree of Linux 2.4.25.
>
> Here is the console log during kernel startup...
> I've also attached our kernel .config file.
>
> ****************************************
> ==> bootm 0xff100000
> bootm 0xff100000
> ## Booting image at ff100000 ...
> Image Name: Linux PPC MPC5200 2.4
> Created: 2006-07-19 22:31:09 UTC
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 884063 Bytes = 863.3 kB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
> Memory BAT mapping: BAT2=64Mb, BAT3=0Mb, residual: 0Mb
> Linux version 2.4.25 (ejubenville@cvs) (gcc version 3.3.3 (DENX ELDK 3.1.1
> 3.3.3-9)) #3 Wed Jul 19 15:30:56 PDT 2006
> On node 0 totalpages: 16384
> zone(0): 16384 pages.
> zone(1): 0 pages.
> zone(2): 0 pages.
> Kernel command line: root=/dev/nfs rw nfsroot=192.168.0.39:/opt/eldk/ppc_6xx
> ip=192.168.0.73:192.168.0.39:192.168.0.3:255.255.255.0:mmt1::off
> Calibrating delay loop... 307.20 BogoMIPS
> Memory: 62176k available (1496k kernel code, 504k data, 76k init, 0k
> highmem)
> Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)
> Inode cache hash table entries: 4096 (order: 3, 32768 bytes)
> Mount cache hash table entries: 512 (order: 0, 4096 bytes)
> Buffer cache hash table entries: 4096 (order: 2, 16384 bytes)
> Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
> POSIX conformance testing by UNIFIX
> PCI: Probing PCI hardware
> Linux NET4.0 for Linux 2.4
> Based upon Swansea University Computer Society NET3.039
> Initializing RT netlink socket
> Starting kswapd
> Journalled Block Device driver loaded
> devfs: v1.12c (20020818) Richard Gooch (rgooch@atnf.csiro.au)
> devfs: devfs_debug: 0x0
> devfs: boot_options: 0x1
> JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc.
> pty: 256 Unix98 ptys configured
> devfs_register(cua): could not append to parent, err: -17
> devfs_register(cua): could not append to parent, err: -17
> ttyS0 on PSC1
> ttyS1 on PSC2
> ttyS2 on PSC3
> RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
> loop: loaded (max 8 devices)
> Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> Port Config is: 0x11050004
> ipb=132MHz, set clock period to 7
> GPIO config: 11050004
> ATA invalid: 01000000
> ATA hostcnf: 03000000
> ATA pio1 : 100a0a00
> ATA pio2 : 02040600
> XLB Arb cnf: 0000a366
> mpc5xxx_ide: Setting up IDE interface ide0...
> ATA DMA task: 5
> Probing IDE interface ide0...
> hda: SanDisk SDCFB-4096, CFA DISK drive
> hda: Setting MDMA 2 timings
> hda: Setting PIO 4 timings
> ide0 at 0xf0003a60-0xf0003a67,0xf0003a5c on irq 45
> hda: attached ide-disk driver.
> hda: 8005536 sectors (4099 MB) w/1KiB Cache, CHS=7942/16/63, DMA
> Partition check:
> /dev/ide/host0/bus0/target0/lun0:<7>Unhandled interrupt 1a, disabled
> [PTBL] [992/128/63] p1
> NET4: Linux TCP/IP 1.0 for NET4.0
> IP Protocols: ICMP, UDP, TCP, IGMP
> IP: routing cache hash table of 512 buckets, 4Kbytes
> TCP: Hash tables configured (established 4096 bind 8192)
> eth0: Phy @ 0x0, type LXT971 (0x001378e2)
> IP-Config: Complete:
> device=eth0, addr=192.168.0.73, mask=255.255.255.0, gw=192.168.0.3,
> host=mmt1, domain=, nis-domain=(none),
> bootserver=192.168.0.39, rootserver=192.168.0.39, rootpath=
> NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
> Looking up port of RPC 100003/2 on 192.168.0.39
> Looking up port of RPC 100005/1 on 192.168.0.39
> VFS: Mounted root (nfs filesystem).
> Mounted devfs on /dev
> Freeing unused kernel memory: 76k init
> nfs: server 192.168.0.39 not responding, still trying
> nfs: server 192.168.0.39 OK
> ****************************************
>
> The "not responding" and "OK" keep repeating at a slow rate,
> eventually interspersed with messages from the init process.
>
> Any help would be appreciated. Thanks.
>
> Ed Jubenville
>
^ permalink raw reply
* Re: powermac: More powermac backlight fixes
From: Michael Hanselmann @ 2006-07-25 18:44 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, johannes, aris, linux-kernel
In-Reply-To: <20060724200315.d3c80ed0.akpm@osdl.org>
Hello Andrew
On Mon, Jul 24, 2006 at 08:03:15PM -0700, Andrew Morton wrote:
> I see schedule_work()s in there, but no flush_scheduled_work()s or anything
> like that. Generally, this means there are races against rmmod, close(),
> etc.
I'll check that. Another patch is in the work already.
> > +void pmac_backlight_disable()
> > +{
> > + atomic_inc(&kernel_backlight_disabled);
> > +}
> > +
> > +void pmac_backlight_enable()
> > +{
> > + atomic_dec(&kernel_backlight_disabled);
> > +}
> > +
> So if userspace calls ioctl(PMU_IOC_GRAB_BACKLIGHT) eleven times, eleven
> enables are needed? (Actually, eleven open()/close() sequences, I think).
> Methinks you wanted just
> kernel_backlight_disabled = 1;
> ?
Aristeu already asked me that, and no, the disabling is meant to be
recursive. The old code did something like "spin_lock(...); disable++;
spin_unlock(...);". It then checked for "if (disable) return;". My code
basically moves the code from the via-pmu driver and removes the
spinlocks.
Thanks,
Michael
^ permalink raw reply
* Re: Endless "Trying 100/HALF" messages using FCC ethernet on MPC8248
From: Andy Fleming @ 2006-07-25 18:46 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-embedded
In-Reply-To: <200607241139.02128.laurent.pinchart@tbox.biz>
On Jul 24, 2006, at 04:39, Laurent Pinchart wrote:
> Hi everybody,
>
> I'm not sure if this issue is ppc-specific, so forgive me if it
> should have
> been reported to the drivers/net/phy maintainer.
>
> When using the MPC8248 FCC ethernet ports, the following messages
> are printed
> by the kernel on the console when a link is down (ethernet cable
> unplugged):
>
> Trying 100/FULL
> Trying 100/HALF
> Trying 100/HALF
> Trying 100/HALF
> ...
>
> This goes on forever, with a new message every 5 or 10 seconds. The
> message is
> printed by drivers/net/phy/phy.c at line 463.
>
> Those messages are pretty annoying. Commenting the pr_info() call
> gave me some
> rest, but a proper fix is probably needed.
>
> For the record, I'm using FCC1 and FCC2 with an LXT973 phy in bit-
> banging
> mode.
There are two bugs at play, here. One of which has been solved by a
patch, which hasn't been accepted yet. However, there's still a bug,
in that the PHY layer assumes that autonegotiation will complete if
the link is down. I believe you only see the message if you bring
up the interface while the link is down.
I'm working on a fix for this.
Andy
^ permalink raw reply
* Re: PHY Howto ?
From: Andy Fleming @ 2006-07-25 19:19 UTC (permalink / raw)
To: dhlii; +Cc: linuxppc-embedded
In-Reply-To: <44C59875.4000309@dlasys.net>
On Jul 24, 2006, at 23:05, David H. Lynch Jr. wrote:
> Vitaly Bordug wrote:
>> On Thu, 20 Jul 2006 13:52:47 -0400 "David H. Lynch Jr."
>> <dhlii@dlasys.net> wrote:
>>> If I am writing a network MAC driver, for hardware that has a phy
>>> that is already supported, if I provide the appropriate mdio_read
>>> () and mdio_write() calls to access the phy registers, and setup
>>> my config to include phylib and drivers for my specific phy, what
>>> else do I have to take care of with respect to the phy within my
>>> driver ? Are there some resources, howto's, examples, ...
>>> demonstrating how to use phylib ?
>> There is pretty good writeup in Documentation about your concern,
>> find it at Documentation/networking/phy.txt . Live example is
>> obviously drivers/net/gianfar*
> Thanks that proved useful. I am already using gianfar as a
> reference - but it is not a NIC I am familiar with.
> And I still have some questions:
>
> What is the distinction/interaction between phylib and
> MII support ?
>
> Are they independent ways of doing something similar ? Or
> do they work together.
>
The MII code is an older interface to PHYs which provided some, but
not all of the PHY layer's capabilities. I don't anticipate its
going away anytime soon, but the PHY layer was designed to replace
it. I don't currently know of any reason for a driver to support the
MII interface, other than legacy reasons (that's not to say there are
none, but I don't know of them). The mii_if_info structure is only
needed if you invoke one of the mii_* functions, the functionalities
of which are provided by the PHY library. So I guess my answer is
that they are independent ways of doing something similar.
There are functions in phy.c to replace the generic mii functions for
getting and setting speed/duplex values:
phy_ethtool_sset
phy_ethtool_gset
And a function to perform the mii_ioctl commands, which is highly
discouraged. It messes around with the PHY behind the scenes,
leaving the PHY layer out of the loop.
>
> To get MII working I need to provide/populate an
> mii_if_info structure and supply register read/write routines.
>
> Since communicating with the PHY is MAC dependent
> shouldn't I need to do the same for PHYLIB ?
Look at drivers/net/gianfar_mii.c. You need to provide an mii_bus
structure, which has pointers to read, write, and reset functions.
It also has power/suspend functions. Basically, the MDIO hardware on
your NIC gets treated as a separate device. It's fairly
straightforward for your NIC to treat it as part of itself, though.
>
> As I understand it although PHY's are similar, and the
> same PHY may be used on different NIC's
> Communications to the PHY typically go through the NIC.
> So my Network driver has to provide routines to read/
> write the registers of the PHY, which phylib and the phy driver
> then use.
That's pretty much it. The same PHY type will be used on different
NICs. Hopefully, you don't want to share a PHY between two NICs.
That's not currently supported. And I'm not really sure how it would
work, in truth. But the driver can be shared for each PHY device.
And the NIC exposes the MDIO bus as a full bus device.
Andy
^ permalink raw reply
* Re: powermac: More powermac backlight fixes
From: Michael Hanselmann @ 2006-07-25 20:06 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, johannes, aris, linux-kernel
In-Reply-To: <20060725184406.GA12226@hansmi.ch>
On Tue, Jul 25, 2006 at 08:44:06PM +0200, Michael Hanselmann wrote:
> On Mon, Jul 24, 2006 at 08:03:15PM -0700, Andrew Morton wrote:
> > I see schedule_work()s in there, but no flush_scheduled_work()s or anything
> > like that. Generally, this means there are races against rmmod, close(),
> > etc.
After discussing it with Aristeu, we came to the conclusion that it's
not dangerous. The generic backlight code can not be compiled as a
module. If a framebuffer driver unloads, it'll set pmac_backlight to
NULL. The workers check for it and don't do anything if true. So, if the
worker is called after unloading the module, it won't do anything.
Here's the other patch which fixes a little error in the patch you just
added to your tree. Without the patch, pbbuttonsd and other applications
changing the backlight will fail.
---
diff -Nrup --exclude-from linux-exclude-from linux-2.6.18-rc2-git4.orig/arch/powerpc/platforms/powermac/backlight.c linux-2.6.18-rc2-git4/arch/powerpc/platforms/powermac/backlight.c
--- linux-2.6.18-rc2-git4.orig/arch/powerpc/platforms/powermac/backlight.c 2006-07-25 20:51:05.000000000 +0200
+++ linux-2.6.18-rc2-git4/arch/powerpc/platforms/powermac/backlight.c 2006-07-25 20:52:02.000000000 +0200
@@ -140,9 +140,6 @@ static int __pmac_backlight_set_legacy_b
{
int error = -ENXIO;
- if (atomic_read(&kernel_backlight_disabled))
- return -EBUSY;
-
mutex_lock(&pmac_backlight_mutex);
if (pmac_backlight) {
struct backlight_properties *props;
@@ -170,11 +167,17 @@ static int __pmac_backlight_set_legacy_b
static void pmac_backlight_set_legacy_worker(void *data)
{
+ if (atomic_read(&kernel_backlight_disabled))
+ return;
+
__pmac_backlight_set_legacy_brightness(pmac_backlight_set_legacy_queued);
}
/* This function is called in interrupt context */
void pmac_backlight_set_legacy_brightness_pmu(int brightness) {
+ if (atomic_read(&kernel_backlight_disabled))
+ return;
+
pmac_backlight_set_legacy_queued = brightness;
schedule_work(&pmac_backlight_set_legacy_work);
}
^ 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