* Re: Linux v2.6.16-rc5
From: Olaf Hering @ 2006-03-05 22:44 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Linus Torvalds, Linux Kernel Mailing List
In-Reply-To: <20060305222202.GA22450@suse.de>
On Sun, Mar 05, Olaf Hering wrote:
> 404849bbd2bfd62e05b36f4753f6e1af6050a824 + 3 buildfixes:
>
> 31df1678d7732b94178a6e457ed6666e4431212f
> 8dacaedf04467e32c50148751a96150e73323cdc
> d2dd482bc17c3bc240045f80a7c4b4d5cea5e29c
>
>
> This one has the syscall changes, but not the two fixes you mentioned.
> It gets far, but at the point where it locks up with the d4eb, it
> crashes in run_timer_softirq, branched to 0x1f4. Maybe its the result of
> the missing fixes. Will continue tomorrow.
Another try with that version, now I see the corruption before the
package where it locked up before (glibc-locale, rather large).
Will backout the syscall change and try again with 404849bbd2bfd62e05b36f4753f6e1af6050a824.
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234, item_len 25965, item_location 25972, free_space(entry_count) 24946
ReiserFS: hda11: warning: vs-5150: search_by_key: invalid format found in block 0. Fsck?
ReiserFS: hda11: warning: zam-7001: io error in reiserfs_find_entry
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234, item_len 25965, item_location 25972, free_space(entry_count) 24946
ReiserFS: hda11: warning: vs-5150: search_by_key: invalid format found in block 0. Fsck?
ReiserFS: hda11: warning: zam-7001: io error in reiserfs_find_entry
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234, item_len 25965, item_location 25972, free_space(entry_count) 24946
ReiserFS: hda11: warning: vs-5150: search_by_key: invalid format found in block 0. Fsck?
ReiserFS: hda11: warning: zam-7001: io error in reiserfs_find_entry
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234, item_len 25965, item_location 25972, free_space(entry_count) 24946
ReiserFS: hda11: warning: vs-5150: search_by_key: invalid format found in block 0. Fsck?
ReiserFS: hda11: warning: zam-7001: io error in reiserfs_find_entry
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234, item_len 25965, item_location 25972, free_space(entry_count) 24946
ReiserFS: hda11: warning: vs-5150: search_by_key: invalid format found in block 0. Fsck?
ReiserFS: hda11: warning: zam-7001: io error in reiserfs_find_entry
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234, item_len 25965, item_location 25972, free_space(entry_count) 24946
ReiserFS: hda11: warning: vs-5150: search_by_key: invalid format found in block 0. Fsck?
ReiserFS: hda11: warning: zam-7001: io error in reiserfs_find_entry
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234, item_len 25965, item_location 25972, free_space(entry_count) 24946
ReiserFS: hda11: warning: vs-5150: search_by_key: invalid format found in block 0. Fsck?
ReiserFS: hda11: warning: zam-7001: io error in reiserfs_find_entry
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234, item_len 25965, item_location 25972, free_space(entry_count) 24946
ReiserFS: hda11: warning: vs-5150: search_by_key: invalid format found in block 0. Fsck?
ReiserFS: hda11: warning: zam-7001: io error in reiserfs_find_entry
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234, item_len 25965, item_location 25972, free_space(entry_count) 24946
ReiserFS: hda11: warning: vs-5150: search_by_key: invalid format found in block 0. Fsck?
ReiserFS: hda11: warning: zam-7001: io error in reiserfs_find_entry
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234
ReiserFS: warning: vs-500: unknown uniqueness 1634738234, item_len 25965, item_location 25972, free_space(entry_count) 24946
ReiserFS: hda11: warning: vs-5150: search_by_key: invalid format found in block 0. Fsck?
ReiserFS: hda11: warning: zam-7001: io error in reiserfs_find_entry
^ permalink raw reply
* Re: [PATCH] return to OF via trap, not exit
From: Michael Ellerman @ 2006-03-06 1:12 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Olaf Hering
In-Reply-To: <20060304191026.GA9815@suse.de>
[-- Attachment #1: Type: text/plain, Size: 2849 bytes --]
On Sun, 5 Mar 2006 06:10, Olaf Hering wrote:
> Do not call prom exit prom_panic. It clears the screen and the exit message
> is lost. On some (or all?) pmacs it causes another crash when OF tries to
> print the date and time in its banner.
>
> Signed-off-by: Olaf Hering <olh@suse.de>
>
> arch/powerpc/kernel/prom_init.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletion(-)
>
> Index: linux-2.6.16-rc5-olh/arch/powerpc/kernel/prom_init.c
> ===================================================================
> --- linux-2.6.16-rc5-olh.orig/arch/powerpc/kernel/prom_init.c
> +++ linux-2.6.16-rc5-olh/arch/powerpc/kernel/prom_init.c
> @@ -398,7 +398,9 @@ static void __init __attribute__((noretu
> #endif
> prom_print(reason);
> /* ToDo: should put up an SRC here on p/iSeries */
> - call_prom("exit", 0, 0);
> + /* Do not call exit because it clears the screen on pmac
> + * it also causes some sort of double-fault on early pmacs */
> + asm("trap\n");
>
> for (;;) /* should never get here */
> ;
I don't think I like it, on IBM firmware it takes us from this:
Elapsed time since release of system processors: 26005 mins 51 secs
zImage starting: loaded at 0x00400000 (sp: 0x01a1ffe0)
Allocating 0x7edc50 bytes for kernel ...
OF version = 'IBM,SF230_126'
gunzipping (0x1c00000 <- 0x407000:0x6a04e4)...done 0x766880 bytes
OF stdout device is: /vdevice/vty@30000000
Error: You can't boot a kdump kernel from OF!
EXIT called ok
0 >
To this:
Elapsed time since release of system processors: 25995 mins 56 secs
zImage starting: loaded at 0x00400000 (sp: 0x01a1ffe0)
Allocating 0x7edc50 bytes for kernel ...
OF version = 'IBM,SF230_126'
gunzipping (0x1c00000 <- 0x407000:0x6a044b)...done 0x766880 bytes
OF stdout device is: /vdevice/vty@30000000
Error: You can't boot a kdump kernel from OF!
DEFAULT CATCH!, exception-handler=fff00700
at %SRR0: 00000000020eaf78 %SRR1: 8000000000023002
Open Firmware exception handler entered from non-OF code
Client's Fix Pt Regs:
00 00000000020eaf78 0000000001a1fe90 00000000023681d0 0000000000000002
04 0000000044000024 0000000000000000 0000000000000000 0000000002063e1e
08 0000000000000000 0000000001a1fc9c 0000000000003002 0000000000003002
0c 2000000000000000 0000000000000000 0000000000000000 0000000000000000
10 0000000000000000 0000000000000000 0000000000000000 0000000000000000
14 0000000000c00000 0000000000000008 0000000000000000 0000000000000000
18 0000000000000000 0000000000000000 0000000000000000 0000000000c39a48
1c c000000002453cc8 0000000002108938 0000000000000000 fffffffffffffffd
Special Regs:
%IV: 00000700 %CR: 44000022 %XER: 00000000 %DSISR: 00000000
%SRR0: 00000000020eaf78 %SRR1: 8000000000023002
%LR: 00000000020eaf78 %CTR: 0000000000000000
%DAR: 0000000000000000
Virtual PID = 0
PFW: Unable to send error log!
ok
0 >
cheers
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: linux DMA capabilities in MV64460
From: Phil Nitschke @ 2006-03-06 4:09 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20051220010136.GA31165@mag.az.mvista.com>
>>>>> "MAG" == Mark A Greer <mgreer@mvista.com> writes:
MAG> On Tue, Dec 20, 2005 at 10:49:58AM +1030, Phil Nitschke wrote:
>> ... if I wanted to suck the data into main memory using the mv64460
>> IDMA controller (assuming the device couldn't initiate its own
>> burst writes), is there a standard kernel interface to allow me to
>> do this?
MAG> Yes. You would make a "dma ctlr driver" for the dma ctlr(s). I
MAG> don't know what the best example would be but hopefully someone
MAG> else has a suggestion.
I'm following up to a thread started in December last year. The thread
was talking about this device:
http://www.marvell.com/products/communication/discoveryIII/index.jsp
http://www.marvell.com/products/communication/Discovery%20MV64460%20FINAL.pdf
Currently I've found the linux kernel has the following files relevant
to this hardware (2.6.15 kernel):
./arch/ppc/syslib/mv64360_pic.c
./arch/ppc/syslib/mv64x60.c
./arch/ppc/syslib/mv64x60_dbg.c
./arch/ppc/syslib/mv64x60_win.c
./drivers/char/watchdog/mv64x60_wdt.c
./drivers/i2c/busses/i2c-mv64xxx.c
./drivers/net/mv643xx_eth.c
I'm now looking seriously (and reluctantly!) at writing a DMA Controller
Driver to supplement these functions, and I've started the process of
getting an NDA from Marvell, so I can get their User Manual (and errata!).
Can someone point me in the right direction to get me started? I need
to come up the learning curve to find out where to start.
How is a DMA controlled (from a device driver writer's perspective) when
a third-party (i.e. in the bridge) DMA controller needs to do the work
to get the data from a PCI Target into main memory?
What kernel API should be provided by the DMA Controller Driver?
Any documentation, examples, similar device drivers, etc, would be
appreciated. TIA,
--
Phil
^ permalink raw reply
* Re: PQ2FADS_ZU: u-boot-1.1.4, eldk.3.1.1, linux-2.4.25 boots problem
From: KokHow Teh @ 2006-03-06 5:05 UTC (permalink / raw)
To: linuxppc-embedded
On Fri, 24 Feb 2006 18:03:21 +0800
"KokHow Teh" <KokHow.Teh@marconi.com> wrote:
>> Hi;
>> I use the above software, apply
linuxppc-2005-03-06-2006-02-15.patch
>> from http://mpc8260sar.sourceforge.net/, `make PQ2FADS_config`, not
using
>> devfs and never manage to boot the kernel:
>>
>> u-boot> printenv
>> ramboot=setenv bootargs root=/dev/ram rw;tftp $ramdiskaddr
$ramdiskfile;tftp $loadaddr $bootfile
>> ;bootm $loadaddr $ramdiskaddr
>> bootdelay=10
>> baudrate=115200
>> ethaddr=08:00:3E:33:44:56
>> ipaddr=147.128.28.44
>> serverip=147.128.28.42
>> rootpath="/fadsroot"
>> gatewayip=147.128.28.1
>> netmask=255.255.254.0
>> hostname=PQ2FADS-ZU
>> bootfile="uImage.linux"
>> netdev=eth0
>> ramdiskaddr=400000
>> ramdiskfile=uInitRD
>> ethact=FCC2 ETHERNET
>> testdramdata=y
>> testdramaddress=y
>> testdramwalk=n
>> x86_run_bios=on
>> bootcmd=run nfsboot
>> nfsargs=setenv bootargs $bootargs root=/dev/nfs rw
nfsroot=$serverip:$rootpath
>> setconsole=setenv bootargs $console
>> addip=setenv bootargs $bootargs
ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:off
>> loadaddr=0x1000000
>> nfsboot=tftp $loadaddr $bootfile; run setconsole nfsargs addip; echo
$bootargs; bootm
>> console=console=ttyS0,115200n8 console=tty0
>> stdin=serial
>> stdout=serial
>> stderr=serial
>>
>> Environment size: 891/262140 bytes
>> u-boot>
>> u-boot> boot
>> Using FCC2 ETHERNET device
>> TFTP from server 147.128.28.42; our IP address is 147.128.28.44
>> Filename 'uImage.linux'.
>> Load address: 0x1000000
>> Loading:
#################################################################
>>
#################################################################
>> ######################################################
>> done
>> Bytes transferred = 941606 (e5e26 hex)
>> console=ttyS0,115200n8 console=tty0 root=/dev/nfs rw
nfsroot=147.128.28.42:/fadsroot ip=147.128.
>> 28.44:147.128.28.42:147.128.28.1:255.255.254.0:PQ2FADS-ZU:eth0:off
>> ## Booting image at 01000000 ...
>> Image Name: Linux Kernel Image
>> Image Type: PowerPC Linux Kernel Image (gzip compressed)
>> Data Size: 941542 Bytes = 919.5 kB
>> Load Address: 00000000
>> Entry Point: 00000000
>> Verifying Checksum ... OK
>> Uncompressing Kernel Image ... OK
>>
>>
>> U-Boot 1.1.4 (Feb 15 2006 - 16:19:49)
>>
>> MPC8260 Reset Status: Check Stop, External Soft, External Hard
>>
>>
>> I have tried console=ttyCPM0,115200n8 console=tty0 and it makes no
difference. BTW, which one should be used for serial console in 2.4.x
kernel
>> for this PowerQUICC II 8280 platform? ttySx or ttyCPMx?
>> Any insight is appreciated.
>>
>The right thing is ttyS0 for 2.4.x...
>First, if that will not help, I suggest to comment out the PCI
initialization code, and to see if it will help.
>--
>Sincerely,
>Vitaly
I have taken out the PCI initialization code:
[root@ShrekII linux 4]# grep PCI .config
# CONFIG_PCI is not set
# CONFIG_DMA_NONPCI is not set
# CONFIG_NET_PCI is not set
[root@ShrekII linux 5]#
Here is the log_buf:
[root@ShrekII linux 3]# grep log_buf /fadsroot/boot/System.map
c01d40b4 b log_buf
[root@ShrekII linux 4]#
Here is what is in the log_buf after the system reboots when booting the linux kernel:
u-boot> md 0x1d40b4
001d40b4: 0007502d 0007502e 0007502f 00075030 ..P-..P...P/..P0
001d40c4: 00075031 00075032 00075033 00075034 ..P1..P2..P3..P4
001d40d4: 00075035 00075036 00075037 00075038 ..P5..P6..P7..P8
001d40e4: 00075039 0007503a 0007503b 0007503c ..P9..P:..P;..P<
001d4104: 00075041 00075042 00075043 00075044 ..PA..PB..PC..PD
001d4114: 00075045 00075046 00075047 00075048 ..PE..PF..PG..PH
001d4124: 00075049 0007504a 0007504b 0007504c ..PI..PJ..PK..PL
001d4134: 0007504d 0007504e 0007504f 00075050 ..PM..PN..PO..PP
001d4144: 00075051 00075052 00075053 00075054 ..PQ..PR..PS..PT
001d4154: 00075055 00075056 00075057 00075058 ..PU..PV..PW..PX
001d4164: 00075059 0007505a 0007505b 0007505c ..PY..PZ..P[..P\
001d4174: 0007505d 0007505e 0007505f 00075060 ..P]..P^..P_..P`
001d4184: 00075061 00075062 00075063 00075064 ..Pa..Pb..Pc..Pd
001d4194: 00075065 00075066 00075067 00075068 ..Pe..Pf..Pg..Ph
001d41a4: 00075069 0007506a 0007506b 0007506c ..Pi..Pj..Pk..Pl
u-boot>
I can't see any helpful information in this log_buf....:-<
Any insight is appreciated.
Regards,
TEH
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH] return to OF via trap, not exit
From: Olaf Hering @ 2006-03-06 7:38 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <200603061212.12815.michael@ellerman.id.au>
On Mon, Mar 06, Michael Ellerman wrote:
> I don't think I like it, on IBM firmware it takes us from this:
>
> Elapsed time since release of system processors: 26005 mins 51 secs
>
> zImage starting: loaded at 0x00400000 (sp: 0x01a1ffe0)
> Allocating 0x7edc50 bytes for kernel ...
> OF version = 'IBM,SF230_126'
> gunzipping (0x1c00000 <- 0x407000:0x6a04e4)...done 0x766880 bytes
> OF stdout device is: /vdevice/vty@30000000
> Error: You can't boot a kdump kernel from OF!
> EXIT called ok
> 0 >
>
>
> To this:
Which is likely ok because it saves us from typing .registers manually.
^ permalink raw reply
* Re: [PATCH] return to OF via trap, not exit
From: Segher Boessenkool @ 2006-03-06 7:41 UTC (permalink / raw)
To: Olaf Hering; +Cc: Michael Ellerman, linuxppc-dev
In-Reply-To: <20060306073834.GA24869@suse.de>
> Which is likely ok because it saves us from typing .registers
> manually.
I can't say that's a great argument. How about doing the trap thing
on "known-bad" platforms only?
Segher
^ permalink raw reply
* Re: INIT:
From: Paulinha @ 2006-03-06 7:41 UTC (permalink / raw)
To: Patil, Pankaj P., linuxppc-embedded
In-Reply-To: <9B832BEB407A774AA0520CCFC23221970663EA35@CXOEXC11.AMERICAS.CPQCORP.NET>
[-- Attachment #1: Type: text/plain, Size: 7576 bytes --]
Hi,
I had the same problem two weeks ago, and my error was that I forgot to add
PTY support on the linux kernel.
Hope this help!
Paula
On 3/3/06, Patil, Pankaj P. <Pankaj.Patil@hp.com> wrote:
>
> I do have /dev/console in my file system. In fact , i used ethereal on
> the host to see how far the INIT goes.
> I saw all the usual NFS Lookup calls like /lib, /ld-2.3.1.so ..... /libc-
> 2.31.so
> The last NFS lookup call looks like DH:0xbea72a4a/tty0
> There are bunch of read replys after that but no more NFS lookups. Is it
> normal to see a NFS Lookup that looks like 0xbea72a4a/tty0 ??
> What should be the next NFS Lookup call?
> I did some searching from previous posts but haven't found exactly what i
> am looking for. I am attaching a link to something that looks similar to my
> problem. Just in case, someone's having trouble understanding my issue.
> http://ozlabs.org/pipermail/linuxppc-embedded/2004-August/015250.html
>
> Thanks
> pankaj
>
> -----Original Message-----
> From: atul.sabharwal@exgate.tek.com
> [mailto:atul.sabharwal@exgate.tek.com]
> Sent: Tuesday, February 28, 2006 6:03 PM
> To: Patil, Pankaj P.
> Cc: linuxppc-embedded@ozlabs.org
> Subject: RE: INIT:
>
>
> Easy answer is do you have /dev/console in your file system. Glibc
> opens
> /dev/console and the kernel uses /dev/ttyS0 as specified on the command
> line. There should not be any app calling uart_close as the console
> deriver
> should be opening it.
>
> --
> Atul
>
> Hi,
> I am running u-boot & linux2.6.12 on a custom ppc board(functional HW).
> I can get to the point where u-boot loads the kernel, kernel does all
> the initialization, loads the Root File System over NFS & calls the
> Init process.
> Next, i am expecting to see a shell prompt. I am not sure where in the
> Init process i am failing. I have written my own serial driver(Philips
> SC28L194 Quad UART--under development-possible culprit). The printks
> work just fine.
> All i see is the kernel calling the Init process & after a minute or so
> i see uart_close call.
> The kernel runs just fine & responds to ping.
> What can trigger a uart_close??(tty_release calls release_dev calls
> uart_close) I have a JTAG debugger. What's the best way to debug once
> Init process is running??
>
>
>
> I am attaching a dump of my console:
> U-Boot 1.1.3 (Dec 16 2005 - 16:00:23), Build: 0.4.1
>
> SysClock = 120Mhz , TClock = 120Mhz
> CPU: MPC7447A v1.1 @ 960 MHz
> CPU bus mode : 60x
>
> DRAM: SPD Checksum ok!
> -- DIMM1 has 2 banks
> -- DIMM2 has 0 banks
> ECC Initialization of Bank 0: Done
> CAS Latency = 2 tRP = 3 tRAS = 6 tRCD=3
> Total SDRAM memory is 1024 MB
> Now running in RAM - U-Boot at: 00fc0000
> Remapped Internal SRAM to 0xf2000000
> Remapped Flash Card to 0xffc00000
> FLASH: 4 MB
> Addresses 32M - 0M are saved for the U-Boot usage.
> Mem malloc Initialization (32M - 16M): Done
>
> Internal SRAM ECC Initialization: Done
> ***Phy Reset***
> Phy Auto-Negotiation Bit ReEnabled in SW
> Net: , mv_enet1 [PRIME]
> Hit any key to stop autoboot: 0
> Ethernet status port 1: Link up, Full Duplex, Speed 100 Mbps
> Using mv_enet1 device
> TFTP from server 192.168.1.1; our IP address is 192.168.1.2
> Filename 'uImage'.
> Load address: 0x400000
> Loading:
> #################################################################
>
> #################################################################
>
> #################################################################
> ########################
> done
> Bytes transferred = 1119847 (111667 hex)
>
> ### Network statistics: ###
> --------------------------
> Packets received: 2192
> Packets send: 2191
> Received bytes: 2347583
> Send bytes: 100803
> ## Booting image at 00400000 ...
> Image Name: Linux-2.6.12
> Created: 2006-02-14 0:37:17 UTC
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 1119783 Bytes = 1.1 MB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
> ## cmdline at 0x007FFF00 ... 0x007FFF98
> memstart = 0x00000000
> memsize = 0x40000000
> flashstart = 0xFFC00000
> flashsize = 0x00400000
> flashoffset = 0x00000000
> sramstart = 0xF8000000
> sramsize = 0x00400000
> bootflags = 0x00000001
> intfreq = 960 MHz
> busfreq = 120 MHz
> ethaddr = 64:00:00:00:00:00
> IP addr = 192.168.1.2
> baudrate = 115200 bps
> tclk = 0 MHz
> uboot_ver = 0.4.1a
> L3 was init = 0
> Total memory = 768MB; using 2048kB for hash table (at c0400000)
> Linux version 2.6.12 (root@RHEL40) (gcc version 3.3.3 (DENX ELDK 3.1.1
> 3.3.3-10)) #154 Mon Feb 13 17:36:35 MST 2006
> System Identification:
> Freescale 74XX port
> Built 1 zonelists
> Kernel command line: console=ttyS0,115200 root=/dev/nfs rw
> nfsroot=192.168.1.1:/target/chestnut/rootfs
> ip=192.168.1.2:192.168.1.1:192.168.1.1:255.255.255.0:DB64xxx:eth0:non
> e
> PID hash table entries: 4096 (order: 12, 65536 bytes)
> time_init: decrementer frequency = 30.000000 MHz
> Console: colour dummy device 80x25
> Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
> Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
> Memory: 774400k available (1596k kernel code, 556k data, 344k init, 0k
> highmem)
> Mount-cache hash table entries: 512
>
> NET: Registered protocol family 16
> PCI: Probing PCI hardware
> JFFS2 version 2.2. (C) 2001-2003 Red Hat, Inc.
> Generic RTC Driver v1.07
> Serial: SC28L194 driver 4 ports
> ttyS0 at MMIO 0x0 (irq = 17) is a PHILIPS SC28L194
> ttyS1 at MMIO 0x0 (irq = 17) is a PHILIPS SC28L194
> ttyS2 at MMIO 0x0 (irq = 17) is a PHILIPS SC28L194
> ttyS3 at MMIO 0x0 (irq = 17) is a PHILIPS SC28L194
> io scheduler noop registered
> io scheduler anticipatory registered
> io scheduler deadline registered
> io scheduler cfq registered
> RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
> loop: loaded (max 8 devices)
> MV-643xx 10/100/1000 Ethernet Driver
> eth0: port 1 with MAC address 00:11:85:da:0b:02
> eth0: RX NAPI Enabled
> physmap flash device: 400000 at ffc00000
> mice: PS/2 mouse device common for all mice
> NET: Registered protocol family 2
> IP: routing cache hash table of 8192 buckets, 64Kbytes
> TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
> TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
> TCP: Hash tables configured (established 131072 bind 65536)
> NET: Registered protocol family 1
> NET: Registered protocol family 17
> IP-Config: Complete:
> device=eth0, addr=192.168.1.2, mask=255.255.255.0, gw=192.168.1.1,
> host=DB64xxx, domain=, nis-domain=(none),
> bootserver=192.168.1.1, rootserver=192.168.1.1, rootpath=
> Looking up port of RPC 100003/2 on 192.168.1.1
> Looking up port of RPC 100005/1 on 192.168.1.1
> VFS: Mounted root (nfs filesystem).
> Freeing unused kernel memory: 344k init
>
>
> Any help appreceated.
> Thanks
> pankaj
>
>
> _______________________________________________
> 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
>
[-- Attachment #2: Type: text/html, Size: 9937 bytes --]
^ permalink raw reply
* Re: [PATCH] return to OF via trap, not exit
From: Olaf Hering @ 2006-03-06 7:43 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Michael Ellerman, linuxppc-dev
In-Reply-To: <590CA2B3-AACE-4B69-930D-9A66A42FFC83@kernel.crashing.org>
On Mon, Mar 06, Segher Boessenkool wrote:
> >Which is likely ok because it saves us from typing .registers
> >manually.
>
> I can't say that's a great argument. How about doing the trap thing
> on "known-bad" platforms only?
Can you do anything at that time anyway? I mean, reset-all pending
either way.
^ permalink raw reply
* Re: [PATCH] return to OF via trap, not exit
From: Segher Boessenkool @ 2006-03-06 7:46 UTC (permalink / raw)
To: Olaf Hering; +Cc: Michael Ellerman, linuxppc-dev
In-Reply-To: <20060306074339.GC24869@suse.de>
>>> Which is likely ok because it saves us from typing .registers
>>> manually.
>>
>> I can't say that's a great argument. How about doing the trap thing
>> on "known-bad" platforms only?
>
> Can you do anything at that time anyway? I mean, reset-all pending
> either way.
You can boot a different kernel, or try to work out what went wrong.
Segher
^ permalink raw reply
* Re: Linux v2.6.16-rc5
From: Olaf Hering @ 2006-03-06 7:48 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Linus Torvalds, Linux Kernel Mailing List
In-Reply-To: <20060305224438.GA22580@suse.de>
On Sun, Mar 05, Olaf Hering wrote:
> On Sun, Mar 05, Olaf Hering wrote:
>
> > 404849bbd2bfd62e05b36f4753f6e1af6050a824 + 3 buildfixes:
> >
> > 31df1678d7732b94178a6e457ed6666e4431212f
> > 8dacaedf04467e32c50148751a96150e73323cdc
> > d2dd482bc17c3bc240045f80a7c4b4d5cea5e29c
> >
> >
> > This one has the syscall changes, but not the two fixes you mentioned.
> > It gets far, but at the point where it locks up with the d4eb, it
> > crashes in run_timer_softirq, branched to 0x1f4. Maybe its the result of
> > the missing fixes. Will continue tomorrow.
>
> Another try with that version, now I see the corruption before the
> package where it locked up before (glibc-locale, rather large).
> Will backout the syscall change and try again with 404849bbd2bfd62e05b36f4753f6e1af6050a824.
Its not the syscall change at least. Looking further.
^ permalink raw reply
* Re: [PATCH] return to OF via trap, not exit
From: Olaf Hering @ 2006-03-06 7:49 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Michael Ellerman, linuxppc-dev
In-Reply-To: <1912CD56-027C-491D-B2A2-EA44AB4DDD14@kernel.crashing.org>
On Mon, Mar 06, Segher Boessenkool wrote:
> >>> Which is likely ok because it saves us from typing .registers
> >>> manually.
> >>
> >> I can't say that's a great argument. How about doing the trap thing
> >> on "known-bad" platforms only?
> >
> > Can you do anything at that time anyway? I mean, reset-all pending
> > either way.
>
> You can boot a different kernel, or try to work out what went wrong.
No, I cant, all resources are possible busy. Either way, maybe checking
what type stdout is and trap or exit depending on that.
And I dont see whats bad about 'trap handler called', other than being
verbose.
^ permalink raw reply
* Re: INIT:
From: Paulinha @ 2006-03-06 7:55 UTC (permalink / raw)
To: Patil, Pankaj P., linuxppc-embedded
In-Reply-To: <259581790603052341s15f21579yb3870adbde1f075e@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 7871 bytes --]
... and TLB support!!
Paula
On 3/3/06, Patil, Pankaj P. <Pankaj.Patil@hp.com> wrote:
> >
> > I do have /dev/console in my file system. In fact , i used ethereal on
> > the host to see how far the INIT goes.
> > I saw all the usual NFS Lookup calls like /lib, /ld-2.3.1.so .....
> > /libc- 2.31.so
> > The last NFS lookup call looks like DH:0xbea72a4a/tty0
> > There are bunch of read replys after that but no more NFS lookups. Is it
> > normal to see a NFS Lookup that looks like 0xbea72a4a/tty0 ??
> > What should be the next NFS Lookup call?
> > I did some searching from previous posts but haven't found exactly what
> > i am looking for. I am attaching a link to something that looks similar to
> > my problem. Just in case, someone's having trouble understanding my issue.
> > http://ozlabs.org/pipermail/linuxppc-embedded/2004-August/015250.html
> >
> > Thanks
> > pankaj
> >
> > -----Original Message-----
> > From: atul.sabharwal@exgate.tek.com
> > [mailto:atul.sabharwal@exgate.tek.com]
> > Sent: Tuesday, February 28, 2006 6:03 PM
> > To: Patil, Pankaj P.
> > Cc: linuxppc-embedded@ozlabs.org
> > Subject: RE: INIT:
> >
> >
> > Easy answer is do you have /dev/console in your file system. Glibc
> > opens
> > /dev/console and the kernel uses /dev/ttyS0 as specified on the command
> > line. There should not be any app calling uart_close as the console
> > deriver
> > should be opening it.
> >
> > --
> > Atul
> >
> > Hi,
> > I am running u-boot & linux2.6.12 on a custom ppc board(functional HW).
> > I can get to the point where u-boot loads the kernel, kernel does all
> > the initialization, loads the Root File System over NFS & calls the
> > Init process.
> > Next, i am expecting to see a shell prompt. I am not sure where in the
> > Init process i am failing. I have written my own serial driver(Philips
> > SC28L194 Quad UART--under development-possible culprit). The printks
> > work just fine.
> > All i see is the kernel calling the Init process & after a minute or so
> > i see uart_close call.
> > The kernel runs just fine & responds to ping.
> > What can trigger a uart_close??(tty_release calls release_dev calls
> > uart_close) I have a JTAG debugger. What's the best way to debug once
> > Init process is running??
> >
> >
> >
> > I am attaching a dump of my console:
> > U-Boot 1.1.3 (Dec 16 2005 - 16:00:23), Build: 0.4.1
> >
> > SysClock = 120Mhz , TClock = 120Mhz
> > CPU: MPC7447A v1.1 @ 960 MHz
> > CPU bus mode : 60x
> >
> > DRAM: SPD Checksum ok!
> > -- DIMM1 has 2 banks
> > -- DIMM2 has 0 banks
> > ECC Initialization of Bank 0: Done
> > CAS Latency = 2 tRP = 3 tRAS = 6 tRCD=3
> > Total SDRAM memory is 1024 MB
> > Now running in RAM - U-Boot at: 00fc0000
> > Remapped Internal SRAM to 0xf2000000
> > Remapped Flash Card to 0xffc00000
> > FLASH: 4 MB
> > Addresses 32M - 0M are saved for the U-Boot usage.
> > Mem malloc Initialization (32M - 16M): Done
> >
> > Internal SRAM ECC Initialization: Done
> > ***Phy Reset***
> > Phy Auto-Negotiation Bit ReEnabled in SW
> > Net: , mv_enet1 [PRIME]
> > Hit any key to stop autoboot: 0
> > Ethernet status port 1: Link up, Full Duplex, Speed 100 Mbps
> > Using mv_enet1 device
> > TFTP from server 192.168.1.1; our IP address is 192.168.1.2
> > Filename 'uImage'.
> > Load address: 0x400000
> > Loading:
> > #################################################################
> >
> > #################################################################
> >
> > #################################################################
> > ########################
> > done
> > Bytes transferred = 1119847 (111667 hex)
> >
> > ### Network statistics: ###
> > --------------------------
> > Packets received: 2192
> > Packets send: 2191
> > Received bytes: 2347583
> > Send bytes: 100803
> > ## Booting image at 00400000 ...
> > Image Name: Linux-2.6.12
> > Created: 2006-02-14 0:37:17 UTC
> > Image Type: PowerPC Linux Kernel Image (gzip compressed)
> > Data Size: 1119783 Bytes = 1.1 MB
> > Load Address: 00000000
> > Entry Point: 00000000
> > Verifying Checksum ... OK
> > Uncompressing Kernel Image ... OK
> > ## cmdline at 0x007FFF00 ... 0x007FFF98
> > memstart = 0x00000000
> > memsize = 0x40000000
> > flashstart = 0xFFC00000
> > flashsize = 0x00400000
> > flashoffset = 0x00000000
> > sramstart = 0xF8000000
> > sramsize = 0x00400000
> > bootflags = 0x00000001
> > intfreq = 960 MHz
> > busfreq = 120 MHz
> > ethaddr = 64:00:00:00:00:00
> > IP addr = 192.168.1.2
> > baudrate = 115200 bps
> > tclk = 0 MHz
> > uboot_ver = 0.4.1a
> > L3 was init = 0
> > Total memory = 768MB; using 2048kB for hash table (at c0400000)
> > Linux version 2.6.12 (root@RHEL40) (gcc version 3.3.3 (DENX ELDK 3.1.1
> > 3.3.3-10)) #154 Mon Feb 13 17:36:35 MST 2006
> > System Identification:
> > Freescale 74XX port
> > Built 1 zonelists
> > Kernel command line: console=ttyS0,115200 root=/dev/nfs rw
> > nfsroot=192.168.1.1:/target/chestnut/rootfs
> > ip=192.168.1.2:192.168.1.1:192.168.1.1:255.255.255.0:DB64xxx:eth0:non
> > e
> > PID hash table entries: 4096 (order: 12, 65536 bytes)
> > time_init: decrementer frequency = 30.000000 MHz
> > Console: colour dummy device 80x25
> > Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
> > Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
> > Memory: 774400k available (1596k kernel code, 556k data, 344k init, 0k
> > highmem)
> > Mount-cache hash table entries: 512
> >
> > NET: Registered protocol family 16
> > PCI: Probing PCI hardware
> > JFFS2 version 2.2. (C) 2001-2003 Red Hat, Inc.
> > Generic RTC Driver v1.07
> > Serial: SC28L194 driver 4 ports
> > ttyS0 at MMIO 0x0 (irq = 17) is a PHILIPS SC28L194
> > ttyS1 at MMIO 0x0 (irq = 17) is a PHILIPS SC28L194
> > ttyS2 at MMIO 0x0 (irq = 17) is a PHILIPS SC28L194
> > ttyS3 at MMIO 0x0 (irq = 17) is a PHILIPS SC28L194
> > io scheduler noop registered
> > io scheduler anticipatory registered
> > io scheduler deadline registered
> > io scheduler cfq registered
> > RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
> > loop: loaded (max 8 devices)
> > MV-643xx 10/100/1000 Ethernet Driver
> > eth0: port 1 with MAC address 00:11:85:da:0b:02
> > eth0: RX NAPI Enabled
> > physmap flash device: 400000 at ffc00000
> > mice: PS/2 mouse device common for all mice
> > NET: Registered protocol family 2
> > IP: routing cache hash table of 8192 buckets, 64Kbytes
> > TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
> > TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
> > TCP: Hash tables configured (established 131072 bind 65536)
> > NET: Registered protocol family 1
> > NET: Registered protocol family 17
> > IP-Config: Complete:
> > device=eth0, addr=192.168.1.2 , mask=255.255.255.0, gw=192.168.1.1
> > ,
> > host=DB64xxx, domain=, nis-domain=(none),
> > bootserver=192.168.1.1 , rootserver=192.168.1.1, rootpath=
> > Looking up port of RPC 100003/2 on 192.168.1.1
> > Looking up port of RPC 100005/1 on 192.168.1.1
> > VFS: Mounted root (nfs filesystem).
> > Freeing unused kernel memory: 344k init
> >
> >
> > Any help appreceated.
> > Thanks
> > pankaj
> >
> >
> > _______________________________________________
> > 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
> >
>
>
[-- Attachment #2: Type: text/html, Size: 11736 bytes --]
^ permalink raw reply
* Re: [PATCH] return to OF via trap, not exit
From: Segher Boessenkool @ 2006-03-06 7:57 UTC (permalink / raw)
To: Olaf Hering; +Cc: Michael Ellerman, linuxppc-dev
In-Reply-To: <20060306074953.GE24869@suse.de>
>>> Can you do anything at that time anyway? I mean, reset-all pending
>>> either way.
>>
>> You can boot a different kernel, or try to work out what went wrong.
>
> No, I cant, all resources are possible busy.
That's a separate bug. What resources do you see busy? Allocated
memory, I/O devices?
> Either way, maybe checking
> what type stdout is and trap or exit depending on that.
That's better than always calling trap, sure. Is there any reason
you can't just do it on Macs though? Because the problem you're trying
to work around only happens there.
> And I dont see whats bad about 'trap handler called', other than being
> verbose.
Too verbose -- it prints useless information, and the actual error
message might scroll away. No biggie of course, but why do the
workaround when not needed?
Segher
^ permalink raw reply
* Re: How to quickly write cleanmarkers to jffs2 partitions?
From: Jaap-Jan Boor @ 2006-03-06 12:21 UTC (permalink / raw)
To: Mathieu Deschamps; +Cc: David Jander, linuxppc-embedded
In-Reply-To: <200603031008.20075.mathieu.deschamps@com2gether.net>
[-- Attachment #1: Type: text/plain, Size: 1070 bytes --]
On Fri, 2006-03-03 at 10:08 +0100, Mathieu Deschamps wrote:
> Hi,
>
> "When preparing a flash partition for JFFS2, it is recommended to put
> cleanmarkers to the erased blocks.
> This might be done my means of "-j" option of the "flash_eraseall" MTD
> utility. Otherwise, JFFS2 will re-erase the blocks
> which contain all 0xFF and have no cleanmarker. This is an unneeded wasting of
> time."
>
> Source : http://www.linux-mtd.infradead.org/faq/jffs2.html
>
> does this may be relevant ?
This is correct, however flash_eraseall does also (as it's
name suggests, erase all flash blocks, which takes
some time on NOR flash. If you 'know' the flash is erased,
it's not needed.
I used flash_eraseall to write the cleanmarkers, but without
erasing blocks (and called that utility cleanmark)
Jaap-Jan
>
>
>
> Best Regards,
>
>
> Mathieu Deschamps.
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 1513 bytes --]
^ permalink raw reply
* Re: linux DMA capabilities in MV64460
From: Brian Waite @ 2006-03-06 13:21 UTC (permalink / raw)
To: linuxppc-embedded, Phil.Nitschke
In-Reply-To: <kwlkvomcxp.fsf@lamorak.int.avalon.com.au>
> I'm now looking seriously (and reluctantly!) at writing a DMA Controller
> Driver to supplement these functions, and I've started the process of
> getting an NDA from Marvell, so I can get their User Manual (and errata!).
>
You won't get very far without the user manual, then I think you will find it
pretty easy to write the driver with the frameworks already in the kernel.
> Can someone point me in the right direction to get me started? I need
> to come up the learning curve to find out where to start.
>
> How is a DMA controlled (from a device driver writer's perspective) when
> a third-party (i.e. in the bridge) DMA controller needs to do the work
> to get the data from a PCI Target into main memory?
>
> What kernel API should be provided by the DMA Controller Driver?
>
My first guess would be to follow something like Documentation/DMA-API.txt and
Documentation/DMA-mapping.txt
> Any documentation, examples, similar device drivers, etc, would be
> appreciated. TIA,
You could look to followup that by groking arch/ppc/kernel/dma-mapping.c
Finally, arch/ppc/syslib ppc4xx_dma.c seems to show an example of a low level
driver.
I didn't notice any platform dma controllers like MAG reccommended, but that
should be a better way to go.
Thanks
Brian
^ permalink raw reply
* Anyone back-ported fs_enet to 2.4? Possible?
From: antonio.dibacco @ 2006-03-06 15:17 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
anyone back ported fs_enet to 2.4? Is it feasible in your high opinion?
Bye,
Antonio.
^ permalink raw reply
* [PATCH] enable CONFIG_BLK_DEV_SL82C105
From: Olaf Hering @ 2006-03-06 15:39 UTC (permalink / raw)
To: Paul Mackeras, linuxppc-dev
Enable the onboard IDE driver for p610, p615 and p630.
They have the CD connected to this card. All other RS/6000 systems with this
controller have no connectors and dont need this option.
Signed-off-by: Olaf Hering <olh@suse.de>
arch/powerpc/configs/ppc64_defconfig | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.16-rc5-olh/arch/powerpc/configs/ppc64_defconfig
===================================================================
--- linux-2.6.16-rc5-olh.orig/arch/powerpc/configs/ppc64_defconfig
+++ linux-2.6.16-rc5-olh/arch/powerpc/configs/ppc64_defconfig
@@ -407,7 +407,7 @@ CONFIG_IDEPCI_SHARE_IRQ=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_BLK_DEV_GENERIC=y
# CONFIG_BLK_DEV_OPTI621 is not set
-# CONFIG_BLK_DEV_SL82C105 is not set
+CONFIG_BLK_DEV_SL82C105=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
^ permalink raw reply
* Re: Anyone back-ported fs_enet to 2.4? Possible?
From: Pantelis Antoniou @ 2006-03-06 16:29 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060306151715.11926.qmail@mx1.aruba.it>
On Monday 06 March 2006 17:17, antonio.dibacco wrote:
> Hi,
>
> anyone back ported fs_enet to 2.4? Is it feasible in your high opinion?
>
> Bye,
> Antonio.
>
The original patches of fec_8xx did.
Try to get a hold of them.
Pantelis
^ permalink raw reply
* Re: Linux v2.6.16-rc5
From: Olaf Hering @ 2006-03-06 16:48 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Linus Torvalds, Linux Kernel Mailing List
In-Reply-To: <17419.23860.883220.80199@cargo.ozlabs.ibm.com>
On Mon, Mar 06, Paul Mackeras wrote:
> There are also commits from Ben H that change the way we parse
> addresses from the OF device tree. If you can bisect a bit further
> that would be good, although you may strike problems between the 401d
> and 6237 commits I mentioned above.
What I have right now is this, which got me in a non-compiling state.
I will pick the udbg stuff and apply the relevant changes to -git5.
==> .git/HEAD <==
463ce0e103f419f51b1769111e73fe8bb305d0ec
==> .git/refs/bisect/bad <==
51d3082fe6e55aecfa17113dbe98077c749f724c
==> .git/refs/bisect/good-5367f2d67c7d0bf1faae90e6e7b4e2ac3c9b5e0f <==
5367f2d67c7d0bf1faae90e6e7b4e2ac3c9b5e0f
==> .git/refs/bisect/good-d1405b869850982f05c7ec0d3f137ca27588192f <==
d1405b869850982f05c7ec0d3f137ca27588192f
==> .git/BISECT_LOG <==
git-bisect start
# good: [5367f2d67c7d0bf1faae90e6e7b4e2ac3c9b5e0f] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband
git-bisect good 5367f2d67c7d0bf1faae90e6e7b4e2ac3c9b5e0f
# bad: [977127174a7dff52d17faeeb4c4949a54221881f] Merge master.kernel.org:/pub/scm/linux/kernel/git/gregkh/pci-2.6
git-bisect bad 977127174a7dff52d17faeeb4c4949a54221881f
# bad: [93b47684f60cf25e8cefe19a21d94aa0257fdf36] drivers/*rest*: Replace pci_module_init() with pci_register_driver()
git-bisect bad 93b47684f60cf25e8cefe19a21d94aa0257fdf36
# bad: [03929c76f3e5af919fb762e9882a9c286d361e7d] ppc32: cpm_uart: fix xchar sending
git-bisect bad 03929c76f3e5af919fb762e9882a9c286d361e7d
# bad: [d4e4b3520c4df46cf1d15a56379a6fa57e267b7d] powerpc: fix for "Update OF address parsers"
git-bisect bad d4e4b3520c4df46cf1d15a56379a6fa57e267b7d
# bad: [404849bbd2bfd62e05b36f4753f6e1af6050a824] powerpc: Remove some unneeded fields from the paca
git-bisect bad 404849bbd2bfd62e05b36f4753f6e1af6050a824
# good: [d1405b869850982f05c7ec0d3f137ca27588192f] powerpc: Add OF address parsing code (#2)
git-bisect good d1405b869850982f05c7ec0d3f137ca27588192f
# bad: [e199500c6280aadf98c185db99fd24ab61ebe0c7] powerpc: partly merge iseries do_IRQ
git-bisect bad e199500c6280aadf98c185db99fd24ab61ebe0c7
# bad: [2c5bd01f8f5d7c655d9d1aa60b696d980947e3be] powerpc: convert macio_asic to use prom_parse
git-bisect bad 2c5bd01f8f5d7c655d9d1aa60b696d980947e3be
# bad: [51d3082fe6e55aecfa17113dbe98077c749f724c] powerpc: Unify udbg (#2)
git-bisect bad 51d3082fe6e55aecfa17113dbe98077c749f724c
^ permalink raw reply
* RE: INIT:
From: Patil, Pankaj P. @ 2006-03-06 17:19 UTC (permalink / raw)
To: Paulinha, linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 8161 bytes --]
I'll look into those config settings. While we are talking about config settings, i noticed i had CONFIG_VT turned on. I do the make ARCH=ppc xconfig but i cannot find the setting where CONFIG_VT gets turned on. I don't want to use the virtual terminal & i believe since the kernel is getting configured with CONFIG_VT=y, it is trying to mount tty0 which is not part of my root file system. Does that make sense??
Is CONFIG_VT dependent on some other config setting?? How do i get CONFIG_VT set to n??
thanks
pankaj
-----Original Message-----
From: Paulinha [mailto:gnathita@gmail.com]
Sent: Monday, March 06, 2006 12:55 AM
To: Patil, Pankaj P.; linuxppc-embedded@ozlabs.org
Subject: Re: INIT:
... and TLB support!!
Paula
On 3/3/06, Patil, Pankaj P. < Pankaj.Patil@hp.com> wrote:
I do have /dev/console in my file system. In fact , i used ethereal on the host to see how far the INIT goes.
I saw all the usual NFS Lookup calls like /lib, /ld- <http://2.3.1.so> 2.3.1.so ..... /libc- <http://2.31.so> 2.31.so
The last NFS lookup call looks like DH:0xbea72a4a/tty0
There are bunch of read replys after that but no more NFS lookups. Is it normal to see a NFS Lookup that looks like 0xbea72a4a/tty0 ??
What should be the next NFS Lookup call?
I did some searching from previous posts but haven't found exactly what i am looking for. I am attaching a link to something that looks similar to my problem. Just in case, someone's having trouble understanding my issue.
http://ozlabs.org/pipermail/linuxppc-embedded/2004-August/015250.html <http://ozlabs.org/pipermail/linuxppc-embedded/2004-August/015250.html>
Thanks
pankaj
-----Original Message-----
From: atul.sabharwal@exgate.tek.com
[mailto: <mailto:atul.sabharwal@exgate.tek.com> atul.sabharwal@exgate.tek.com]
Sent: Tuesday, February 28, 2006 6:03 PM
To: Patil, Pankaj P.
Cc: linuxppc-embedded@ozlabs.org
Subject: RE: INIT:
Easy answer is do you have /dev/console in your file system. Glibc
opens
/dev/console and the kernel uses /dev/ttyS0 as specified on the command
line. There should not be any app calling uart_close as the console
deriver
should be opening it.
--
Atul
Hi,
I am running u-boot & linux2.6.12 on a custom ppc board(functional HW).
I can get to the point where u-boot loads the kernel, kernel does all
the initialization, loads the Root File System over NFS & calls the
Init process.
Next, i am expecting to see a shell prompt. I am not sure where in the
Init process i am failing. I have written my own serial driver(Philips
SC28L194 Quad UART--under development-possible culprit). The printks
work just fine.
All i see is the kernel calling the Init process & after a minute or so
i see uart_close call.
The kernel runs just fine & responds to ping.
What can trigger a uart_close??(tty_release calls release_dev calls
uart_close) I have a JTAG debugger. What's the best way to debug once
Init process is running??
I am attaching a dump of my console:
U-Boot 1.1.3 (Dec 16 2005 - 16:00:23), Build: 0.4.1
SysClock = 120Mhz , TClock = 120Mhz
CPU: MPC7447A v1.1 @ 960 MHz
CPU bus mode : 60x
DRAM: SPD Checksum ok!
-- DIMM1 has 2 banks
-- DIMM2 has 0 banks
ECC Initialization of Bank 0: Done
CAS Latency = 2 tRP = 3 tRAS = 6 tRCD=3
Total SDRAM memory is 1024 MB
Now running in RAM - U-Boot at: 00fc0000
Remapped Internal SRAM to 0xf2000000
Remapped Flash Card to 0xffc00000
FLASH: 4 MB
Addresses 32M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (32M - 16M): Done
Internal SRAM ECC Initialization: Done
***Phy Reset***
Phy Auto-Negotiation Bit ReEnabled in SW
Net: , mv_enet1 [PRIME]
Hit any key to stop autoboot: 0
Ethernet status port 1: Link up, Full Duplex, Speed 100 Mbps
Using mv_enet1 device
TFTP from server 192.168.1.1; our IP address is 192.168.1.2
Filename 'uImage'.
Load address: 0x400000
Loading:
#################################################################
#################################################################
#################################################################
########################
done
Bytes transferred = 1119847 (111667 hex)
### Network statistics: ###
--------------------------
Packets received: 2192
Packets send: 2191
Received bytes: 2347583
Send bytes: 100803
## Booting image at 00400000 ...
Image Name: Linux-2.6.12
Created: 2006-02-14 0:37:17 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1119783 Bytes = 1.1 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## cmdline at 0x007FFF00 ... 0x007FFF98
memstart = 0x00000000
memsize = 0x40000000
flashstart = 0xFFC00000
flashsize = 0x00400000
flashoffset = 0x00000000
sramstart = 0xF8000000
sramsize = 0x00400000
bootflags = 0x00000001
intfreq = 960 MHz
busfreq = 120 MHz
ethaddr = 64:00:00:00:00:00
IP addr = 192.168.1.2
baudrate = 115200 bps
tclk = 0 MHz
uboot_ver = 0.4.1a
L3 was init = 0
Total memory = 768MB; using 2048kB for hash table (at c0400000)
Linux version 2.6.12 (root@RHEL40) (gcc version 3.3.3 (DENX ELDK 3.1.1
3.3.3-10)) #154 Mon Feb 13 17:36:35 MST 2006
System Identification:
Freescale 74XX port
Built 1 zonelists
Kernel command line: console=ttyS0,115200 root=/dev/nfs rw
nfsroot=192.168.1.1:/target/chestnut/rootfs
ip= 192.168.1.2:192.168.1.1: <http://192.168.1.1:255> 192.168.1.1:255.255.255.0:DB64xxx:eth0:non
e
PID hash table entries: 4096 (order: 12, 65536 bytes)
time_init: decrementer frequency = 30.000000 MHz
Console: colour dummy device 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 774400k available (1596k kernel code, 556k data, 344k init, 0k
highmem)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
PCI: Probing PCI hardware
JFFS2 version 2.2. (C) 2001-2003 Red Hat, Inc.
Generic RTC Driver v1.07
Serial: SC28L194 driver 4 ports
ttyS0 at MMIO 0x0 (irq = 17) is a PHILIPS SC28L194
ttyS1 at MMIO 0x0 (irq = 17) is a PHILIPS SC28L194
ttyS2 at MMIO 0x0 (irq = 17) is a PHILIPS SC28L194
ttyS3 at MMIO 0x0 (irq = 17) is a PHILIPS SC28L194
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
MV-643xx 10/100/1000 Ethernet Driver
eth0: port 1 with MAC address 00:11:85:da:0b:02
eth0: RX NAPI Enabled
physmap flash device: 400000 at ffc00000
mice: PS/2 mouse device common for all mice
NET: Registered protocol family 2
IP: routing cache hash table of 8192 buckets, 64Kbytes
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
NET: Registered protocol family 1
NET: Registered protocol family 17
IP-Config: Complete:
device=eth0, addr= <http://192.168.1.2> 192.168.1.2 , mask= 255.255.255.0, gw= <http://192.168.1.1> 192.168.1.1,
host=DB64xxx, domain=, nis-domain=(none),
bootserver= 192.168.1.1 , rootserver= 192.168.1.1, rootpath=
Looking up port of RPC 100003/2 on 192.168.1.1
Looking up port of RPC 100005/1 on 192.168.1.1 <http://192.168.1.1>
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 344k init
Any help appreceated.
Thanks
pankaj
_______________________________________________
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 <https://ozlabs.org/mailman/listinfo/linuxppc-embedded>
[-- Attachment #2: Type: text/html, Size: 14807 bytes --]
^ permalink raw reply
* Re: VLAN support on TSEC
From: Andy Fleming @ 2006-03-06 17:55 UTC (permalink / raw)
To: Bizhan Gholikhamseh; +Cc: linuxppc-embedded
In-Reply-To: <F795765B112E7344AF36AA9112796415019ECDC0@xmb-sjc-212.amer.cisco.com>
VLAN is supported by gianfar on 8541 the same way it is supported in
other ethernet devices without hardware VLAN support. The only
support it has is that it doesn't drop the frames. All the detection
is done by the software. You may need to change the MTU (by +4) to
make sure that full-size frames don't get dropped. I have tested
VLAN on 8540, and it worked just fine.
On Mar 3, 2006, at 13:27, Bizhan Gholikhamseh ((bgholikh)) wrote:
> Hi All,
> We are using custom board 8541 based processor, running Linux
> version 2.6.11.
> In our board, the TSEC interface is connected to a BCM switch chip.
> We need to configure the interface to support VLAN . The TSEC
> hardware has no VLAN support and the current driver, gianfar.c, has
> no support for VLAN either. Are there any implementation of
> gianfar.c which supports VLAN?
>
> Many thanks in advance,
> Bizhan
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: Anyone back-ported fs_enet to 2.4? Possible?
From: Antonio Di Bacco @ 2006-03-06 18:12 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: pantelis
In-Reply-To: <200603061829.30754.pantelis@embeddedalley.com>
On Monday 06 March 2006 17:29, Pantelis Antoniou wrote:
> On Monday 06 March 2006 17:17, antonio.dibacco wrote:
> > Hi,
> >
> > anyone back ported fs_enet to 2.4? Is it feasible in your high opinion?
> >
> > Bye,
> > Antonio.
>
> The original patches of fec_8xx did.
>
> Try to get a hold of them.
>
> Pantelis
I need this fs_enet to support both FECs on a MPC875, is fs_enet suitable? Do
you know if there is a different driver that can be used?
Bye,
Antonio.
^ permalink raw reply
* Re: Anyone back-ported fs_enet to 2.4? Possible?
From: Pantelis Antoniou @ 2006-03-06 18:22 UTC (permalink / raw)
To: Antonio Di Bacco; +Cc: linuxppc-embedded
In-Reply-To: <200603061912.50652.antonio.dibacco@aruba.it>
On Monday 06 March 2006 20:12, Antonio Di Bacco wrote:
> On Monday 06 March 2006 17:29, Pantelis Antoniou wrote:
> > On Monday 06 March 2006 17:17, antonio.dibacco wrote:
> > > Hi,
> > >
> > > anyone back ported fs_enet to 2.4? Is it feasible in your high opinion?
> > >
> > > Bye,
> > > Antonio.
> >
> > The original patches of fec_8xx did.
> >
> > Try to get a hold of them.
> >
> > Pantelis
>
> I need this fs_enet to support both FECs on a MPC875, is fs_enet suitable? Do
> you know if there is a different driver that can be used?
>
> Bye,
> Antonio.
>
fs_enet is the improved version of fec_8xx.
Pantelis
^ permalink raw reply
* Re: Anyone back-ported fs_enet to 2.4? Possible?
From: Antonio Di Bacco @ 2006-03-06 18:28 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: pantelis
In-Reply-To: <200603061829.30754.pantelis@embeddedalley.com>
On Monday 06 March 2006 17:29, Pantelis Antoniou wrote:
> On Monday 06 March 2006 17:17, antonio.dibacco wrote:
> > Hi,
> >
> > anyone back ported fs_enet to 2.4? Is it feasible in your high opinion?
> >
> > Bye,
> > Antonio.
>
> The original patches of fec_8xx did.
>
> Try to get a hold of them.
>
> Pantelis
Hi,
I saw a fec_8xx folder under drivers/net/, is this driver used by fs_enet or
is it a standalone driver for the FECs?
Thank you,
Antonio.
^ permalink raw reply
* Re: Anyone back-ported fs_enet to 2.4? Possible?
From: Vitaly Bordug @ 2006-03-06 18:36 UTC (permalink / raw)
To: Antonio Di Bacco; +Cc: linuxppc-embedded
In-Reply-To: <200603061928.03561.antonio.dibacco@aruba.it>
On Mon, 6 Mar 2006 19:28:03 +0100
Antonio Di Bacco <antonio.dibacco@aruba.it> wrote:
> On Monday 06 March 2006 17:29, Pantelis Antoniou wrote:
> > On Monday 06 March 2006 17:17, antonio.dibacco wrote:
> > > Hi,
> > >
> > > anyone back ported fs_enet to 2.4? Is it feasible in your high opinion?
> > >
> > > Bye,
> > > Antonio.
> >
> > The original patches of fec_8xx did.
> >
> > Try to get a hold of them.
> >
> > Pantelis
>
>
> Hi,
>
> I saw a fec_8xx folder under drivers/net/, is this driver used by fs_enet or
> is it a standalone driver for the FECs?
>
fs_enet is the replacement of the fec_8xx... Well iirc early versions of fs_enet were functional and support 2.4 - search them around the list
At least, those patches could make you a clue what needs to be done to keep 2.4 compatibility...
> Thank you,
> Antonio.
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
Sincerely,
Vitaly
^ 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