* Re: [PATCH] net: Add 405EX support to new EMAC driver
From: Benjamin Herrenschmidt @ 2007-11-01 20:37 UTC (permalink / raw)
To: Stefan Roese; +Cc: netdev, linuxppc-dev
In-Reply-To: <200711011554.04935.sr@denx.de>
On Thu, 2007-11-01 at 15:54 +0100, Stefan Roese wrote:
> This patch adds support for the 405EX to the new EMAC driver.
>
> Tested on AMCC Kilauea.
.../...
> diff --git a/drivers/net/ibm_newemac/rgmii.c b/drivers/net/ibm_newemac/rgmii.c
> index de41695..e393f68 100644
> --- a/drivers/net/ibm_newemac/rgmii.c
> +++ b/drivers/net/ibm_newemac/rgmii.c
> @@ -140,9 +140,6 @@ void rgmii_get_mdio(struct of_device *ofdev, int input)
>
> RGMII_DBG2(dev, "get_mdio(%d)" NL, input);
>
> - if (dev->type != RGMII_AXON)
> - return;
> -
> mutex_lock(&dev->lock);
That will break 440GX boards that need to use the RGMII for data and the
ZMII for MDIO.
You may want to change the name RGMII_AXON something like RGMII_HAS_MDIO
instead and set that for 405EX as well instead.
Ben.
^ permalink raw reply
* Kernel malloc buffers how to make contiguous in user space?
From: Dave Cogley @ 2007-11-01 21:03 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1974 bytes --]
Hello,
I am using a scatter gather DMA operation provided on the PPC44EPx to handle
a large data move of 2MB from sixteen 128k kmalloc buffers. I have sixteen
scatter / gather descriptors pointing to the allocated memory which will be
transferred to a peripheral on the EBC. This all appears to be setup and
working correctly. Now I want to provide these 16 kmalloc buffers to a user
space process and make them all appear as a contiguous 2MB buffer.
When the handler is called pageptr appears to be a valid page but the kernel
traps with "Bad page state" "Trying to fix it up, but a reboot is needed"
when returned from the handler. Am I missing something required to modify
the page state for the requested page? Am I even handling the nopage
request correctly? I notice the nopage handler gets called for every 4096
byte page it is trying to map. How do I map my 128k memory area into the 4k
page requests? Is there example code somewhere that demonstrates using a
contiguous memory buffer in user space when it is comprised of multiple
buffers in the kernel space?
First I am allocating 16 buffers using kmalloc:
#define DMABLOCKSIZE 1024 * 128
for (I = 0; I < 16; i++)
{
device->dma_buf[i] = kmalloc(DMABLOCKSIZE, GFP_DMA |
GFP_KERNEL);
sgl->phyaddress = virt_to_phys(device->dma_buf[i]);
}
Then I am doing the following in the nopage handler:
page* nopage_handler(struct vma, ul address, int* type)
{
unsigned long physaddr = address - vma->start;
int index = physaddr / DMABLOCKSIZE;
int off = physaddr % DMABLOCKSIZE;
struct page* pageptr = virt_to_page(device->dma_buf[index] +
off);
get_page(pageptr);
if (type)
*type = VM_FAULT_MINOR;
return pageptr;
}
Dave Cogley
Software Engineer
Ultra Stereo Labs, Inc.
(805) 549-0161
mailto:dcogley@uslinc.com
[-- Attachment #2: Type: text/html, Size: 8883 bytes --]
^ permalink raw reply
* Re: [PATCH] net: Add 405EX support to new EMAC driver
From: Josh Boyer @ 2007-11-01 21:07 UTC (permalink / raw)
To: benh; +Cc: netdev, Stefan Roese, linuxppc-dev
In-Reply-To: <1193949421.6541.10.camel@pasglop>
On Fri, 02 Nov 2007 07:37:01 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> On Thu, 2007-11-01 at 15:54 +0100, Stefan Roese wrote:
> > This patch adds support for the 405EX to the new EMAC driver.
> >
> > Tested on AMCC Kilauea.
>
> .../...
>
> > diff --git a/drivers/net/ibm_newemac/rgmii.c b/drivers/net/ibm_newemac/rgmii.c
> > index de41695..e393f68 100644
> > --- a/drivers/net/ibm_newemac/rgmii.c
> > +++ b/drivers/net/ibm_newemac/rgmii.c
> > @@ -140,9 +140,6 @@ void rgmii_get_mdio(struct of_device *ofdev, int input)
> >
> > RGMII_DBG2(dev, "get_mdio(%d)" NL, input);
> >
> > - if (dev->type != RGMII_AXON)
> > - return;
> > -
> > mutex_lock(&dev->lock);
>
> That will break 440GX boards that need to use the RGMII for data and the
> ZMII for MDIO.
>
> You may want to change the name RGMII_AXON something like RGMII_HAS_MDIO
> instead and set that for 405EX as well instead.
And perhaps adding a comment about that since the meaning of that code
isn't very obvious. That way people that aren't the original author
of the driver don't get confused again.
josh
^ permalink raw reply
* Re: [PATCH] net: Add 405EX support to new EMAC driver
From: Stefan Roese @ 2007-11-01 21:31 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, netdev
In-Reply-To: <20071101160709.7e7c0181@weaponx.rchland.ibm.com>
On Thursday 01 November 2007, Josh Boyer wrote:
> > > - if (dev->type != RGMII_AXON)
> > > - return;
> > > -
> > > mutex_lock(&dev->lock);
> >
> > That will break 440GX boards that need to use the RGMII for data and the
> > ZMII for MDIO.
> >
> > You may want to change the name RGMII_AXON something like RGMII_HAS_MDIO
> > instead and set that for 405EX as well instead.
>
> And perhaps adding a comment about that since the meaning of that code
> isn't very obvious. That way people that aren't the original author
> of the driver don't get confused again.
Will do. I'll send a fixed version tomorrow.
Best regards,
Stefan
^ permalink raw reply
* Module with 36K relocation entries
From: Medve Emilian-EMMEDVE1 @ 2007-11-01 23:34 UTC (permalink / raw)
To: linuxppc-dev
Hello,
I have module with 36K relocation entries (I know, I know, how could
that be...) and the count_relocs() function takes ~17 seconds to crunch
through the relocation table from the .rela.text section. I don't think
I can reduce the number of entries in the relocation table (can I?) so
I'm thinking at improving the performance of count_relocs() (currently
O(n^2)). Does anybody have a simpler idea? Does anyone have any
constructive suggestion on how to improve the situation?
Thank you,
Emil.
^ permalink raw reply
* Re: Module with 36K relocation entries
From: Nathan Lynch @ 2007-11-01 23:57 UTC (permalink / raw)
To: Medve Emilian-EMMEDVE1; +Cc: linuxppc-dev
In-Reply-To: <598D5675D34BE349929AF5EDE9B03E270174CC98@az33exm24.fsl.freescale.net>
Medve Emilian-EMMEDVE1 wrote:
>
> I have module with 36K relocation entries (I know, I know, how could
> that be...) and the count_relocs() function takes ~17 seconds to crunch
> through the relocation table from the .rela.text section. I don't think
> I can reduce the number of entries in the relocation table (can I?) so
> I'm thinking at improving the performance of count_relocs() (currently
> O(n^2)). Does anybody have a simpler idea? Does anyone have any
> constructive suggestion on how to improve the situation?
This seems to come up every few months. There was a patch submitted
here:
http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037641.html
^ permalink raw reply
* Re: libfdt as its own repo and submodule of dtc?
From: David Gibson @ 2007-11-02 0:34 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linux-ppc list, Jerry Van Baren
In-Reply-To: <1193925881.15380.8.camel@ld0161-tx32>
On Thu, Nov 01, 2007 at 09:04:42AM -0500, Jon Loeliger wrote:
> On Wed, 2007-10-31 at 17:56, David Gibson wrote:
>
> > I'm not too keen on using a git feature that's more recent than the
> > git in most distros.
>
> I'm going to consider this argument null and void on two fronts:
>
> You don't use git for patch generation and submission anyway.
True. It wasn't clear to me whether using this git-submodule thing
would also affect pulling.
> The Linux Community happily embraced and used early
> versions of git, installing it themselves if needed,
> long before it was available in _any_ distro.
I don't think this is a comparable situation. For one, dtc does not
have the clout of Linux. For another, at the time there was hardly
anything in the way of suitable solutions that were out there in
distros. That's not the case now - we can do nearly everything we
want with the git in recent distros, I don't think there's call to
require a newer version for one extra feature.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: serial GDBServer PPC405 problems
From: Wang, Baojun @ 2007-11-02 1:44 UTC (permalink / raw)
To: khollan; +Cc: linuxppc-embedded
In-Reply-To: <393936343.10887@lzu.edu.cn>
[-- Attachment #1: Type: text/plain, Size: 1245 bytes --]
On Friday 02 November 2007 00:49:16, khollan wrote：
> Hi everyone
> I want to thank everyone for helping with all of my problems so far, you
> have been a great help.
>
> Im trying to get a debug session with gdbserver over a serial connection on
> my Xilinx ML410 using a uartlite set at Baud 115200. When I issue the
> command on the target "./gdbserver /dev/ttyUL1 test" I get this error:
> Remote debugging using /dev/ttyUL1
> readchar: Socet operation on non-socket
> Remote Side has terminated connection. GDBserver will reopen connection.
>
> This error just repeats until I kill the process. I know that gdbserver
> works because debugging over TCP works fine.
> Thanks for your help
Your kernel don't have kgdb support? then you need a debugger like bdi2000 to
debug the kernel.
Wang
--
Wang, Baojun Lanzhou University
Distributed & Embedded System Lab http://dslab.lzu.edu.cn
School of Information Science and Engeneering wangbj@lzu.edu.cn
Tianshui South Road 222. Lanzhou 730000 .P.R.China
Tel:+86-931-8912025 Fax:+86-931-8912022
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Freescale I2C support and CONFIG_I2C_BOARDINFO
From: Jon Smirl @ 2007-11-02 2:01 UTC (permalink / raw)
To: PowerPC dev list
Freescale I2C support is being constructed as a platform driver in
arch/powerpc/sysdev/fsl_soc.c and protected with #ifdef
CONFIG_I2C_BOARDINFO. Could the I2C support instead be initialized in
drivers/i2c/busses/i2c-mpc.c as an of_platform driver instead? I'm
find it confusing that half my drivers are platform drivers and half
are of_platform drivers. It would also eliminate the need for the
ifdef.
I'll trying coding it up and see if it works.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* NETDEV WATCHDOG: eth1: transmit timed out on MPC8360?
From: 郭劲 @ 2007-11-02 2:35 UTC (permalink / raw)
To: linuxppc-embedded
Hi,friends,
I had a problem about the eth1 on MPC8360E, I used the eth0 to connect the
88E1111 phy chip, the eth0 is OK always,I can download the kernel uImage and
ramdisk from eth0 by TFTP. I connected the eth1 to the BCM5387 switch chip, there
are series resistor between the MPC8360E and BCM5387 on all GMII signal, I
installed those series resistor and uninstalled them, follow error are both
happened.
Follow is the uboot information:
U-Boot 1.2.0 (Oct 26 2007 - 18:22:13) MPC83XX
Clock configuration:
Coherent System Bus: 264 MHz
Core: 528 MHz
QE: 198 MHz
Local Bus Controller: 264 MHz
Local Bus: 66 MHz
DDR: 264 MHz
DDR Secondary: 264 MHz
SEC: 88 MHz
I2C1: 264 MHz
I2C2: 264 MHz
CPU: MPC8360E, Rev: 20 at 528 MHz
Board: Freescale MPC8360EMDS
I2C: ready
DRAM: now begin spd_sdram .......
SDRAM on Local Bus: 64 MB
DDR RAM: 256 MB
DDR test phase 1:
DDR test phase 2:
DDR test passed.
FLASH: 16 MB
PCI clock is 33MHz
PCI 32bit bus on PMC1 & PMC2 & PMC3
In: serial
Out: serial
Err: serial
Net: UEC: PHY is Marvell 88E11x1 (1410cc1)
FSL UEC0: Full Duplex
FSL UEC0: Speed 1000BT
FSL UEC0: Link is up
UEC: PHY is Marvell 88E11x1 (1410cc1)
FSL UEC1: Full Duplex
FSL UEC1: Speed 1000BT
FSL UEC1: Link is up
FSL UEC0, FSL UEC1
Hit any key to stop autoboot: 0
Follow is the linux kernel loading information:
=> run bootcmd
Using FSL UEC0 device
TFTP from server 192.168.0.2; our IP address is 192.168.0.100
Filename 'uImage'.
Load address: 0xd000000
Loading: *\b#################################################################
#################################################################
###############
done
Bytes transferred = 738275 (b43e3 hex)
Using FSL UEC0 device
TFTP from server 192.168.0.2; our IP address is 192.168.0.100
Filename 'ramdisk_ppc'.
Load address: 0xe000000
Loading: *\b#################################################################
#################################################################
############################################################
done
Bytes transferred = 971744 (ed3e0 hex)
## Booting image at 0d000000 ...
Image Name: Linux-2.6.11
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 738211 Bytes = 720.9 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at 0e000000 ...
Image Name: ramdisk
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 971680 Bytes = 948.9 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Ramdisk to 0febe000, end 0ffab3a0 ... OK
Follow is the random output from begin of kernel,why the kernel output those
random character?
LZw|´ttwϱƒÏ>4·Ì\x044»yG»\x11£Å{O?„÷/?¯ó"7{¾®ûÏ"7·M¼1#¿ÝL7?L?7´Ì“?4^ÌŒ7\x14’„?,Ó‡ÿ/1\x04¿Ï\x1d
£‡ct\x1fO?£‡roÛ{?»µ:\x04¿ÏÑç¿uG¿M\x1d§Ç0t7M=»Ï\x7fLØÏ\x17÷O0\Ì’71:Òt?/š´?k¯vL®»óc?O$‡T|¼{>;6z[Gs
´|\x16?4¼’?s´vl?3vN5£Ï\x7fw?}îу¿t7¼Ì†·"v´ü\x1d&sLfn7L'·ŒD770l?\x7f$wO1§‡wN?/ô·\x13²Ç?$´rd[> v1,
?¤³?D?×÷k?¿¿rO? ?~O?v·|\x7f?\x17÷{w\x04¼Ì?DÙÑç‡sG?tD´|¯c&¶}ä¶r={>'¶³º¾ÿ0{tG?7/\x13´÷164´¾wO+
ãv=·õ?'z>?/c7´Lw¶ƒ·~t¿z??4ÿ8D´rDX> t?5?¦·1bßþ}î[Œü\x1d?r}½L¦·9;?¦wl?ƒ?6ÜÓ\x11~·rNX\x7f„ô
g?\x04?”÷?´ÜLvÏk¼ï?=¿‡|gÛì‡Yún4[¾Œ6\x1e\x1f$;O1£õcF?„´r-[>'v12$ôp´{.77?§Ç84´¼÷ï;?/ô÷/1¿‡
{F´~\x1d¿·0O‡{NZ\x7fŽvïc·ÛÑ£ùs.?,?'ü~\x13»g?O'6Ïo{1L?\x17?z»‡vv¶°Dí·wO?O·ü?/??r=½LGn\x7f?\x04¶õg41?w
:\x04?×û÷ôp??¿tO÷\x11»‡ýk¼|7·ì4”Ïùc?¶÷0?ºÆ‡vvZwv´ÏŒ´åsm?$^ÚÄ 5"¼Ô<?r´ô7ÿxG¿ü\x1d£µ{wZ>\x1d£}
ÑãÇS4´|\x17vŒ·<?xÙÌ7?4´Ìw?$^N¤{0G´lÓsÇSÃõt?Ì„4…Ý\x7f\x1c“Ä?2¼ï\x137 ‡xtÜÌ"Ç8D??²Œ?cãÛšŸ‡tD?\x17?
ÿ?ã‡rG?ctY?49?rwVz§Ïyt?=;?§·{~Xÿ
ôý"vRw\x04ì¼®7Íd´l?÷ZD‡zG´ÌD71b,OkwOgãLûñ£·~G?\x174¯q|´Ì\x04èÏ{'[¾Gºügt´L'¶G±»?g4ùt¼Ä5c
0D?4¯fÃG¼ü\x04 ÓwN·~\x1d?{t´L??‡rG?\x16?üNSw ¶Wg-õgv[\x7f\x04n?v/½~$·|4·ù"¿ÅüO?\x04÷¯fO?GZ>?c7ôLw¶
g´Ï\x11ûÇ4<?×ì»Ý£?6Ì{t?
ùt4Ò?pD´üº¯",z>6ñb¼{´»rO?'?3<¾L‡Úýwt¿Ì\x12/šŒ?4´õ~W?Òt?Ïf$ô|.;?»·wDÙѧ·s>´Ì?=",Ïf%?
dn¢Ž?4??;Ãt4?
Ås,´}6sd=~&z߇w?<{>w¶½ß‡tD´Ì??&Zf$~??(Ó~?duÏk7õp?~÷½Ÿ¿|\x04·|=£Ç07‡çLPw'hÔgMõgv[\x7fD
n?v/Ï~\x04·|5³ù"5t\x11Ó{>´º´Çóg7?\x1f6v¯cv"¿÷~D´ü\x174??¿‡"ÃïÝ·‡Ýo5÷}\x166M½¿?Øü\x177ÿ/1§Í{w?=7-}ÿß
r%{~?n?}6÷¯Ñ»µ~D?=ûÅ:d¼L-?½ã7\x1dinit started: BusyBox v1.5.1 (2007-10-26 20:04:50
CST) multi-call binary
starting pid 13, tty '': '/etc/init.d/rcS'
dzy XLU Build20070605
================================XLU================================
================================XLU================================
Please press Enter to activate this console.
starting pid 18, tty '': '/bin/sh'
BusyBox v1.5.1 (2007-10-26 20:04:50 CST) Built-in shell (ash)
Enter 'help' for a list of built-in commands.
Follow is the dmesg output:
/ # dmesg
Linux version 2.6.11 (ticket@dpim4307) (gcc version 3.4.3) #22 Thu Nov 1 14:18:49
CST 2007
On node 0 totalpages: 65536
DMA zone: 65536 pages, LIFO batch:16
Normal zone: 0 pages, LIFO batch:1
HighMem zone: 0 pages, LIFO batch:1
Built 1 zonelists
Kernel command line: root=/dev/ram0 rw console=ttyS0,115200
IPIC (128 IRQ sources, 8 External IRQs) at fe000700
QE IC (64 IRQ sources) at fe100080, phy: E0100080
PID hash table entries: 2048 (order: 11, 32768 bytes)
Console: colour dummy device 80x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 256896k available (1216k kernel code, 304k data, 80k init, 0k highmem)
Calibrating delay loop... 351.23 BogoMIPS (lpj=175616)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
Freeing initrd memory: 948k freed
NET: Registered protocol family 16
Registering ipic with sysfs...
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
ttyS0 at MMIO 0xe0004500 (irq = 9) is a 16550A
ttyS1 at MMIO 0xe0004600 (irq = 10) is a 16550A
io scheduler noop registered
RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
loop: loaded (max 8 devices)
eth0: Running with NAPI disabled
eth1: Running with NAPI disabled
NET: Registered protocol family 2
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP established hash table entries: 16384 (order: 5, 131072 bytes)
TCP bind hash table entries: 16384 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 16384 bind 16384)
NET: Registered protocol family 1
NET: Registered protocol family 17
RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 80k init
/ # lsmod
Module Size Used by
Follow is the ifconfig output:
/ # ifconfig eth1 192.168.0.20
read wrong value : mii_id 1,mii_reg 2, base fe103120
read wrong value : mii_id 1,mii_reg 3, base fe103120
eth1: PHY is Generic MII (ffffffff)
/ # read wrong value : mii_id 1,mii_reg 4, base fe103120
read wrong value : mii_id 1,mii_reg 0, base fe103120
Follow is the ping output:
/ # ping 192.168.0.100
PING 192.168.0.100 (192.168.0.100): 56 data bytes
Follow is the ping NETDEV WATCHDOG error,why we are failed here?
NETDEV WATCHDOG: eth1: transmit timed out
UCC1 Fast registers:
Base address: 0xfe103000
gumr : addr - 0xfe103000, val - 0x0000003c
upsmr : addr - 0xfe103004, val - 0x02002000
utodr : addr - 0xfe103008, val - 0x0000
udsr : addr - 0xfe10300c, val - 0x7e7e
ucce : addr - 0xfe103010, val - 0x00000000
uccm : addr - 0xfe103014, val - 0x7f010001
uccs : addr - 0xfe103018, val - 0x00
urfb : addr - 0xfe103020, val - 0x00002c00
urfs : addr - 0xfe103024, val - 0x1000
urfet : addr - 0xfe103028, val - 0x0800
urfset: addr - 0xfe10302a, val - 0x0c00
utfb : addr - 0xfe10302c, val - 0x00000c00
utfs : addr - 0xfe103030, val - 0x2000
utfet : addr - 0xfe103034, val - 0x1000
utftt : addr - 0xfe103038, val - 0x0400
utpt : addr - 0xfe10303c, val - 0x0100
urtry : addr - 0xfe103040, val - 0x00000000
guemr : addr - 0xfe103090, val - 0x13
UCC1 Geth registers:
Base address: 0xfe103000
maccfg1 : addr - 0xfe103100, val - 0x00000035
maccfg2 : addr - 0xfe103104, val - 0x00007205
ipgifg : addr - 0xfe103108, val - 0x40605060
hafdup : addr - 0xfe10310c, val - 0x00a1f037
miimcfg : addr - 0xfe103120, val - 0x00000005
miimcom : addr - 0xfe103124, val - 0x00000000
miimadd : addr - 0xfe103128, val - 0x00000100
miimcon : addr - 0xfe10312c, val - 0x0000ffff
miimstat : addr - 0xfe103130, val - 0x0000ffff
miimmind : addr - 0xfe103134, val - 0x00000000
ifctl : addr - 0xfe103138, val - 0x01000000
ifstat : addr - 0xfe10313c, val - 0x00000000
macstnaddr1: addr - 0xfe103140, val - 0x00000000
macstnaddr2: addr - 0xfe103144, val - 0x00000000
uempr : addr - 0xfe103150, val - 0x00000000
utbipar : addr - 0xfe103154, val - 0x00000011
uescr : addr - 0xfe103158, val - 0x0804
tx64 : addr - 0xfe103180, val - 0x00000000
tx127 : addr - 0xfe103184, val - 0x00000000
tx255 : addr - 0xfe103188, val - 0x00000000
rx64 : addr - 0xfe10318c, val - 0x00000000
rx127 : addr - 0xfe103190, val - 0x00000000
rx255 : addr - 0xfe103194, val - 0x00000000
txok : addr - 0xfe103198, val - 0x00000000
txcf : addr - 0xfe10319c, val - 0x0000
tmca : addr - 0xfe1031a0, val - 0x00000000
tbca : addr - 0xfe1031a4, val - 0x00000000
rxfok : addr - 0xfe1031a8, val - 0x00000000
rxbok : addr - 0xfe1031ac, val - 0x00000000
rbyt : addr - 0xfe1031b0, val - 0x00000000
rmca : addr - 0xfe1031b4, val - 0x00000000
rbca : addr - 0xfe1031b8, val - 0x00000000
scar : addr - 0xfe1031bc, val - 0x00000000
scam : addr - 0xfe1031c0, val - 0xffff0000
Thread data TXs:
Base address: 0xfe113d00
Thread data TX[0]:
Base address: 0xfe113d00
0xfe113d00: 00000000 00003e00 0f003e60 83003e80
0xfe113d10: 0f003e60 00e00001 00000000 0000e0c0
0xfe113d20: 0c000001 00000000 0000000c 0000000c
0xfe113d30: 00000000 00003004 00000000 00000000
0xfe113d40: 00000000 00000600 00003f00 05ee0040
0xfe113d50: 05f005f0 00000000 00000000 00000000
0xfe113d60: 00000000 00000000
Thread data TX[1]:
Base address: 0xfe113d68
0xfe113d68: 00000000 00000000 00000000 00000000
0xfe113d78: 00000000 81000000 00000000 00000000
0xfe113d88: 00000000 00000000 00000000 00000000
0xfe113d98: 00000000 00000000 00000000 00000000
0xfe113da8: 00000000 00000000 00000000 00000000
0xfe113db8: 81000000 00000000 00000000 00000000
0xfe113dc8: 00000000 00000000
Thread data TX[2]:
Base address: 0xfe113dd0
0xfe113dd0: 00000000 00000000 00000000 00000000
0xfe113de0: 00000000 00000000 00000000 00000000
0xfe113df0: 00000000 00000000 00000000 00000000
0xfe113e00: 00000000 02000000 00000000 0000807f
0xfe113e10: 00000000 0000807f 00000000 0000807f
0xfe113e20: 00000000 0000807f 00000000 08009031
0xfe113e30: 00000000 02000000
Thread data TX[3]:
Base address: 0xfe113e38
0xfe113e38: 00000000 0000807f 00000000 0000807f
0xfe113e48: 00000000 0000807f 00000000 0000807f
0xfe113e58: 00000000 08009011 00000000 02000000
0xfe113e68: 00000000 0000807f 00000000 0000807f
0xfe113e78: 00000000 08009031 15004300 00000000
0xfe113e88: 1c004340 00000001 1d004380 00000002
0xfe113e98: 240043c0 00000003
Thread data RX:
Base address: 0xfe114000
Thread data RX[0]:
Base address: 0xfe114000
0xfe114000: 00000000 00000000 00000000 00000000
0xfe114010: 00000000 00000000 00000000 00000000
0xfe114020: 00000000 00000000
Thread data RX[1]:
Base address: 0xfe114028
0xfe114028: 00000000 00000000 00000000 00000000
0xfe114038: 00000000 00000000 00000000 00000000
0xfe114048: 00000000 00000000
Thread data RX[2]:
Base address: 0xfe114050
0xfe114050: 00000000 00000000 00000000 00000000
0xfe114060: 00000000 00000000 00000000 00000000
0xfe114070: 00000000 00000000
Thread data RX[3]:
Base address: 0xfe114078
0xfe114078: 00000000 00000000 00004100 00000005
0xfe114088: 00004180 0000000c 00004200 0000000d
0xfe114098: 00004280 00000014
TX global param:
Base address: 0xfe113c80
temoder : addr - 0xfe113c80, val - 0xc100
sqptr : addr - 0xfe113cb8, val - 0x00003c20
schedulerbasepointer: addr - 0xfe113cbc, val - 0x00000000
txrmonbaseptr: addr - 0xfe113cc0, val - 0x00003ea0
tstate : addr - 0xfe113cc4, val - 0x30000000
iphoffset[0] : addr - 0xfe113cc8, val - 0x00
iphoffset[1] : addr - 0xfe113cc9, val - 0x00
iphoffset[2] : addr - 0xfe113cca, val - 0x00
iphoffset[3] : addr - 0xfe113ccb, val - 0x00
iphoffset[4] : addr - 0xfe113ccc, val - 0x00
iphoffset[5] : addr - 0xfe113ccd, val - 0x00
iphoffset[6] : addr - 0xfe113cce, val - 0x00
iphoffset[7] : addr - 0xfe113ccf, val - 0x00
vtagtable[0] : addr - 0xfe113cd0, val - 0x00000000
vtagtable[1] : addr - 0xfe113cd4, val - 0x00000000
vtagtable[2] : addr - 0xfe113cd8, val - 0x00000000
vtagtable[3] : addr - 0xfe113cdc, val - 0x00000000
vtagtable[4] : addr - 0xfe113ce0, val - 0x00000000
vtagtable[5] : addr - 0xfe113ce4, val - 0x00000000
vtagtable[6] : addr - 0xfe113ce8, val - 0x00000000
vtagtable[7] : addr - 0xfe113cec, val - 0x00000000
tqptr : addr - 0xfe113cf0, val - 0x00003d00
RX global param:
Base address: 0xfe113f00
remoder : addr - 0xfe113f00, val - 0x00001000
rqptr : addr - 0xfe113f04, val - 0x00004000
typeorlen : addr - 0xfe113f20, val - 0x0c00
rxgstpack : addr - 0xfe113f23, val - 0x00
rxrmonbaseptr : addr - 0xfe113f24, val - 0x000040a0
intcoalescingptr: addr - 0xfe113f30, val - 0x00003c08
rstate : addr - 0xfe113f36, val - 0x30
mrblr : addr - 0xfe113f46, val - 0x0600
rbdqptr : addr - 0xfe113f48, val - 0x00003ed0
mflr : addr - 0xfe113f4c, val - 0x05ee
minflr : addr - 0xfe113f4e, val - 0x0040
maxd1 : addr - 0xfe113f50, val - 0x05f0
maxd2 : addr - 0xfe113f52, val - 0x05f0
ecamptr : addr - 0xfe113f54, val - 0x00000000
l2qt : addr - 0xfe113f58, val - 0x00000000
l3qt[0] : addr - 0xfe113f5c, val - 0x00000000
l3qt[1] : addr - 0xfe113f60, val - 0x00000000
l3qt[2] : addr - 0xfe113f64, val - 0x00000000
l3qt[3] : addr - 0xfe113f68, val - 0x00000000
l3qt[4] : addr - 0xfe113f6c, val - 0x00000000
l3qt[5] : addr - 0xfe113f70, val - 0x00000000
l3qt[6] : addr - 0xfe113f74, val - 0x00000000
l3qt[7] : addr - 0xfe113f78, val - 0x00000000
vlantype : addr - 0xfe113f7c, val - 0x8100
vlantci : addr - 0xfe113f7e, val - 0x0000
addressfiltering[0]: addr - 0xfe113f80, val - 0x00
addressfiltering[1]: addr - 0xfe113f81, val - 0x00
addressfiltering[2]: addr - 0xfe113f82, val - 0x00
addressfiltering[3]: addr - 0xfe113f83, val - 0x00
addressfiltering[4]: addr - 0xfe113f84, val - 0x00
addressfiltering[5]: addr - 0xfe113f85, val - 0x00
addressfiltering[6]: addr - 0xfe113f86, val - 0x00
addressfiltering[7]: addr - 0xfe113f87, val - 0x00
addressfiltering[8]: addr - 0xfe113f88, val - 0x00
addressfiltering[9]: addr - 0xfe113f89, val - 0x00
addressfiltering[10]: addr - 0xfe113f8a, val - 0x00
addressfiltering[11]: addr - 0xfe113f8b, val - 0x00
addressfiltering[12]: addr - 0xfe113f8c, val - 0x00
addressfiltering[13]: addr - 0xfe113f8d, val - 0x00
addressfiltering[14]: addr - 0xfe113f8e, val - 0x02
addressfiltering[15]: addr - 0xfe113f8f, val - 0x00
addressfiltering[16]: addr - 0xfe113f90, val - 0x00
addressfiltering[17]: addr - 0xfe113f91, val - 0x00
addressfiltering[18]: addr - 0xfe113f92, val - 0x01
addressfiltering[19]: addr - 0xfe113f93, val - 0x00
addressfiltering[20]: addr - 0xfe113f94, val - 0x5e
addressfiltering[21]: addr - 0xfe113f95, val - 0x00
addressfiltering[22]: addr - 0xfe113f96, val - 0x00
addressfiltering[23]: addr - 0xfe113f97, val - 0x01
addressfiltering[24]: addr - 0xfe113f98, val - 0x00
addressfiltering[25]: addr - 0xfe113f99, val - 0x00
addressfiltering[26]: addr - 0xfe113f9a, val - 0xff
addressfiltering[27]: addr - 0xfe113f9b, val - 0xff
addressfiltering[28]: addr - 0xfe113f9c, val - 0xff
addressfiltering[29]: addr - 0xfe113f9d, val - 0xff
addressfiltering[30]: addr - 0xfe113f9e, val - 0xff
addressfiltering[31]: addr - 0xfe113f9f, val - 0xff
addressfiltering[32]: addr - 0xfe113fa0, val - 0x00
addressfiltering[33]: addr - 0xfe113fa1, val - 0x00
addressfiltering[34]: addr - 0xfe113fa2, val - 0xff
addressfiltering[35]: addr - 0xfe113fa3, val - 0xff
addressfiltering[36]: addr - 0xfe113fa4, val - 0xff
addressfiltering[37]: addr - 0xfe113fa5, val - 0xff
addressfiltering[38]: addr - 0xfe113fa6, val - 0xff
addressfiltering[39]: addr - 0xfe113fa7, val - 0xff
addressfiltering[40]: addr - 0xfe113fa8, val - 0x00
addressfiltering[41]: addr - 0xfe113fa9, val - 0x00
addressfiltering[42]: addr - 0xfe113faa, val - 0xff
addressfiltering[43]: addr - 0xfe113fab, val - 0xff
addressfiltering[44]: addr - 0xfe113fac, val - 0xff
addressfiltering[45]: addr - 0xfe113fad, val - 0xff
addressfiltering[46]: addr - 0xfe113fae, val - 0xff
addressfiltering[47]: addr - 0xfe113faf, val - 0xff
addressfiltering[48]: addr - 0xfe113fb0, val - 0x00
addressfiltering[49]: addr - 0xfe113fb1, val - 0x00
addressfiltering[50]: addr - 0xfe113fb2, val - 0xff
addressfiltering[51]: addr - 0xfe113fb3, val - 0xff
addressfiltering[52]: addr - 0xfe113fb4, val - 0xff
addressfiltering[53]: addr - 0xfe113fb5, val - 0xff
addressfiltering[54]: addr - 0xfe113fb6, val - 0xff
addressfiltering[55]: addr - 0xfe113fb7, val - 0xff
addressfiltering[56]: addr - 0xfe113fb8, val - 0x81
addressfiltering[57]: addr - 0xfe113fb9, val - 0x00
addressfiltering[58]: addr - 0xfe113fba, val - 0x00
addressfiltering[59]: addr - 0xfe113fbb, val - 0x00
addressfiltering[60]: addr - 0xfe113fbc, val - 0x00
addressfiltering[61]: addr - 0xfe113fbd, val - 0x00
addressfiltering[62]: addr - 0xfe113fbe, val - 0x00
addressfiltering[63]: addr - 0xfe113fbf, val - 0x00
exfGlobalParam : addr - 0xfe113fc0, val - 0x00000000
Send Q memory registers:
Base address: 0xfe113c20
SQQD[0]:
Base address: 0xfe113c20
0xfe113c20: 0feb6ca0 00003c40 0feb6ca0 0feb6d18
0xfe113c30: 00000000 00000000 0feb6ca0 0feb6d18
0xfe113c40: 00000000 00000000 00000000 00000000
0xfe113c50: 00000000 00000000 00000000 00000000
TX FW statistics pram:
Base address: 0xfe113ea0
0xfe113ea0: 00000000 00000000 00000000 00000000
0xfe113eb0: 00000000 00000000 00000000 00000000
0xfe113ec0: 00000000 00000000 00000000 00000000
RX FW statistics pram:
Base address: 0xfe1140a0
0xfe1140a0: 00000000 00000000 00000000 00000000
0xfe1140b0: 00000000 00000000 00000000 00000000
0xfe1140c0: 00000000 00000000 00000000 00000000
0xfe1140d0: 00000000 00000000 00000000 00000000
0xfe1140e0: 00000000 00000000 00000000 00000000
0xfe1140f0: 00000000 00000000 00000000
RX IRQ coalescing tables:
Base address: 0xfe113c08
RX IRQ coalescing table entry[0]:
Base address: 0xfe113c08
interruptcoalescingmaxvalue: addr - 0xfe113c08, val - 0x00000001
interruptcoalescingcounter : addr - 0xfe113c0c, val - 0x00000001
RX BD QS tables:
Base address: 0xfe113ed0
RX BD QS table[0]:
Base address: 0xfe113ed0
bdbaseptr : addr - 0xfe113ed0, val - 0x00003ee0
bdptr : addr - 0xfe113ed4, val - 0x00003ee0
externalbdbaseptr: addr - 0xfe113ed8, val - 0x0feb6d60
externalbdptr : addr - 0xfe113edc, val - 0x0feb6d60
ucode RX Prefetched BDs:
Base address: 0xfe113ee0
0xfe113ee0: 90000000 0fe5b040 90000000 0fe4d840
0xfe113ef0: 90000000 0fe4d040 90000000 0fe4e840
Init enet param shadow:
Base address: 0xcfe49ea0
0xcfe49ea0: 0630ff00 04000000 00003f03 04000003
0xcfe49eb0: 05004103 0c004183 0d004203 14004283
0xcfe49ec0: 00000000 00000000 00000000 00000000
0xcfe49ed0: 00000000 00000000 00003c83 15004303
0xcfe49ee0: 1c004343 1d004383 240043c3 00000000
0xcfe49ef0: 00000000 00000000 00000000 00
Init enet entry 0:
Base address: 0xfe114300
0xfe114300: 00003c80 00000000 00000000 00000015
0xfe114310: 00000000 00000000 00000000 00000000
0xfe114320: 00000000 00000010 06003d80 06003d80
0xfe114330: 00000000 00000000 00000000 00000000
Init enet entry 1:
Base address: 0xfe114340
0xfe114340: 00003c80 00000000 00000000 0001001c
0xfe114350: 00000000 00000000 00000000 00000000
0xfe114360: 00000000 00000010 06003dc0 06003dc0
0xfe114370: 00000000 00000000 00000000 00000000
Init enet entry 2:
Base address: 0xfe114380
0xfe114380: 00003c80 00000000 00000000 0002001d
0xfe114390: 00000000 00000000 00000000 00000000
0xfe1143a0: 00000000 00000010 06003e00 06003e00
0xfe1143b0: 00000000 00000000 00000000 00000000
Init enet entry 3:
Base address: 0xfe1143c0
0xfe1143c0: 40003c80 00000000 00000000 00030024
0xfe1143d0: 00000000 00000000 00000000 00000000
0xfe1143e0: 00000000 00000010 06003e40 06003e40
0xfe1143f0: 00000000 00000000 00000000 00000000
Init enet entry 1:
Base address: 0xfe114100
0xfe114100: 00003f00 00000000 00000000 30000000
0xfe114110: 00000000 000040c0 00000000 00000000
0xfe114120: 00000000 00000000 00000000 00000000
0xfe114130: 00000000 00000000 00000000 00000000
0xfe114140: 00000000 00000000 00000000 00000000
0xfe114150: 00000000 00000000 00000005 0000000c
0xfe114160: 00001000 81000000 00000000 00000000
0xfe114170: 00000000 00000000 00000000 00000000
Init enet entry 2:
Base address: 0xfe114180
0xfe114180: 00003f00 00000000 00000000 30000000
0xfe114190: 00000000 00004140 02000049 08009011
0xfe1141a0: 0c000212 0ffb3240 05f00000 00003f00
0xfe1141b0: 0ffb3440 00000000 00000000 00000000
0xfe1141c0: 00000000 00000000 00000000 00000000
0xfe1141d0: 00000000 0ffae3c8 0000000c 0000000d
0xfe1141e0: 00001000 81000000 00000000 00000000
0xfe1141f0: 00000000 00000000 00000400 00000212
Init enet entry 3:
Base address: 0xfe114200
0xfe114200: 00003f00 00000000 80000000 30000000
0xfe114210: 00000000 000041c0 00000000 00000000
0xfe114220: 00000000 00000000 86003a80 86003a80
0xfe114230: 00000000 00000000 00000000 00000000
0xfe114240: 000038c0 06003af0 00000000 0001001c
0xfe114250: 00000000 00000000 0000000d 00000014
0xfe114260: 00001000 81000000 86003ac0 86003ac0
0xfe114270: 00000000 00000000 00000000 00000000
Init enet entry 4:
Base address: 0xfe114280
0xfe114280: 00003f00 00000000 80000000 30000000
0xfe114290: 00000000 00004240 00000000 00000000
0xfe1142a0: 00000000 00000000 86003b00 86003b00
0xfe1142b0: 00000000 00000000 00000000 00000000
0xfe1142c0: 400038c0 06003b70 80000000 00030024
0xfe1142d0: 00000000 00000000 00000014 00000005
0xfe1142e0: 00001000 81000000 86003b40 86003b40
0xfe1142f0: 00000000 00000000 00000000 00000000
TX BDs[0]
0xcfeb6ca0: 9800002a 0fe4b0c2 9800002a 0fe4b1c2
0xcfeb6cb0: 9800002a 0fe4b2c2 9800002a 0fe4b3c2
0xcfeb6cc0: 9800002a 0fe4b4c2 9800002a 0fe4b5c2
0xcfeb6cd0: 9800002a 0fe4b6c2 9800002a 0fe4b7c2
0xcfeb6ce0: 9800002a 0fe4b8c2 9800002a 0fe4b9c2
0xcfeb6cf0: 9800002a 0fe4bac2 9800002a 0fe4bbc2
0xcfeb6d00: 9800002a 0fe4bcc2 9800002a 0fe4bdc2
0xcfeb6d10: 9800002a 0fe47ee2 b800002a 0fe47de2
RX BDs[0]
0xcfeb6d60: 90000000 0fe5b040 90000000 0fe4d840
0xcfeb6d70: 90000000 0fe4d040 90000000 0fe4e840
0xcfeb6d80: 90000000 0fe4e040 90000000 0fe4f840
0xcfeb6d90: 90000000 0fe4f040 90000000 0fe50840
0xcfeb6da0: 90000000 0fe50040 90000000 0fe51840
0xcfeb6db0: 90000000 0fe51040 90000000 0fe52840
0xcfeb6dc0: 90000000 0fe52040 90000000 0fe37840
0xcfeb6dd0: 90000000 0fe37040 b0000000 0fe38840
^ permalink raw reply
* Re: serial GDBServer PPC405 problems
From: Grant Likely @ 2007-11-02 3:01 UTC (permalink / raw)
To: Wang, Baojun; +Cc: khollan, linuxppc-embedded
In-Reply-To: <394030244.20640@eyou.net>
On 11/1/07, Wang, Baojun <wangbj@lzu.edu.cn> wrote:
> On Friday 02 November 2007 00:49:16, khollan wrote：
> > Hi everyone
> > I want to thank everyone for helping with all of my problems so far, you
> > have been a great help.
> >
> > Im trying to get a debug session with gdbserver over a serial connection on
> > my Xilinx ML410 using a uartlite set at Baud 115200. When I issue the
> > command on the target "./gdbserver /dev/ttyUL1 test" I get this error:
> > Remote debugging using /dev/ttyUL1
> > readchar: Socet operation on non-socket
> > Remote Side has terminated connection. GDBserver will reopen connection.
> >
> > This error just repeats until I kill the process. I know that gdbserver
> > works because debugging over TCP works fine.
> > Thanks for your help
>
> Your kernel don't have kgdb support? then you need a debugger like bdi2000 to
> debug the kernel.
It sounds like he is trying to debug userspace. Neither kgdb nor the
bdi2000 are the best tool for that.
Khollan; I haven't seen that problem before. I don't know what could
be the issue there, but I'm not a gdbserver expert either.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* The question about the fail at the begin of linux on MPC8360E.
From: 郭劲 @ 2007-11-02 3:08 UTC (permalink / raw)
To: linuxppc-embedded
Hi,friends,
Thanks.
We boot the linux-2.6.22 on MPC8360 board, it failed, follow is the output
information. we just only success on linux-2.6.11, but fail on linux-2.6.19 and
linux-2.6.22. Both 2.6.19 and 2.6.22 are failed on same position,please see follow
information. linux-2.6.19 and linux-2.6.22 are come from BSP of freescale. I used
the u-boot-1.2.0 that compiled by myself. We guess that maybe we did not setup the
bootargs parameter on u-boot rightly or maybe the DDR-I hardware circuit design is
not good enough.
If the reason is the bootargs parameter, could you tell me what is the right
bootargs for linux-2.6.19 and linux-2.6.22?
If the reason is the DDR, I want to boot the linux on my SDRAM chip,kick off the
DDR, my SDRAM located on the address of F0000000~F3FFFFFF, total 64MB. How can I
modify the source code of linux to re-map it and ramdisk and others to my SDRAM
chip space?
Follow is the fail information:
=> bootm 0c000000 0e000000
## Booting image at 0c000000 ...
Image Name: Linux-2.6.22
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1333681 Bytes = 1.3 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at 0e000000 ...
Image Name: uboot ext2 ramdisk rootfs
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 3589813 Bytes = 3.4 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Ramdisk to 0fc3e000, end 0ffaa6b5 ... OK
^ permalink raw reply
* dtc: Further Makefile cleanups
From: David Gibson @ 2007-11-02 3:40 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
Informed by the experience attempting to embed dtc into the kernel
tree, make further simplification of the Makefiles. In particular
make the Makefile.dtc and Makefile.libfdt fragments truly minimal.
This change also stops linking dtc with libfdt, which it does not
need.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
Makefile | 13 +++++++------
Makefile.dtc | 20 ++------------------
libfdt/Makefile.libfdt | 6 ------
tests/Makefile.tests | 49 ++++++++++++++++++++++---------------------------
4 files changed, 31 insertions(+), 57 deletions(-)
Index: dtc/Makefile
===================================================================
--- dtc.orig/Makefile 2007-11-02 14:36:22.000000000 +1100
+++ dtc/Makefile 2007-11-02 14:36:43.000000000 +1100
@@ -17,7 +17,6 @@ CONFIG_LOCALVERSION =
CPPFLAGS = -I libfdt
CFLAGS = -Wall -g -Os
-LDFLAGS = -Llibfdt
BISON = bison
LEX = flex
@@ -138,15 +137,16 @@ LIBFDT_objdir = libfdt
LIBFDT_srcdir = libfdt
include libfdt/Makefile.libfdt
+LIBFDT_lib = $(LIBFDT_objdir)/libfdt.a
+
.PHONY: libfdt
-libfdt: $(LIBFDT_LIB)
+libfdt: $(LIBFDT_lib)
-$(LIBFDT_LIB): $(addprefix libfdt/,$(LIBFDT_OBJS))
+$(LIBFDT_lib): $(addprefix $(LIBFDT_objdir)/,$(LIBFDT_OBJS))
libfdt_clean:
@$(VECHO) CLEAN "(libfdt)"
rm -f $(addprefix libfdt/,$(STD_CLEANFILES))
- rm -f $(addprefix libfdt/,$(LIBFDT_CLEANFILES))
ifneq ($(DEPTARGETS),)
-include $(LIBFDT_OBJS:%.o=$(LIBFDT_objdir)/%.d)
@@ -155,7 +155,8 @@ endif
#
# Testsuite rules
#
-TESTS_PREFIX=tests/
+TESTS_srcdir = tests
+TESTS_objdir = tests
include tests/Makefile.tests
#
@@ -166,7 +167,7 @@ STD_CLEANFILES = *~ *.o *.d *.a *.i *.s
clean: libfdt_clean tests_clean
@$(VECHO) CLEAN
- rm -f $(STD_CLEANFILES) $(DTC_CLEANFILES)
+ rm -f $(STD_CLEANFILES)
rm -f $(VERSION_FILE)
rm -f $(BIN)
Index: dtc/libfdt/Makefile.libfdt
===================================================================
--- dtc.orig/libfdt/Makefile.libfdt 2007-11-02 14:36:16.000000000 +1100
+++ dtc/libfdt/Makefile.libfdt 2007-11-02 14:36:24.000000000 +1100
@@ -4,11 +4,5 @@
# be easily embeddable into other systems of Makefiles.
#
LIBFDT_SRCS = fdt.c fdt_ro.c fdt_wip.c fdt_sw.c fdt_rw.c fdt_strerror.c
-LIBFDT_INCLUDES = fdt.h libfdt.h
-LIBFDT_EXTRA = libfdt_internal.h
-LIBFDT_LIB = libfdt/libfdt.a
-
LIBFDT_OBJS = $(LIBFDT_SRCS:%.c=%.o)
-$(LIBFDT_objdir)/$(LIBFDT_LIB): $(addprefix $(LIBFDT_objdir)/,$(LIBFDT_OBJS))
-
Index: dtc/tests/Makefile.tests
===================================================================
--- dtc.orig/tests/Makefile.tests 2007-11-02 14:36:16.000000000 +1100
+++ dtc/tests/Makefile.tests 2007-11-02 14:36:24.000000000 +1100
@@ -1,4 +1,4 @@
-LIB_TESTS_L = get_mem_rsv \
+LIB_TESTS = get_mem_rsv \
root_node find_property subnode_offset path_offset \
get_name getprop get_path supernode_atdepth_offset parent_offset \
node_offset_by_prop_value \
@@ -9,50 +9,45 @@ LIB_TESTS_L = get_mem_rsv \
move_and_save mangle-layout \
open_pack rw_tree1 setprop del_property del_node \
string_escapes dtbs_equal_ordered
-LIB_TESTS = $(LIB_TESTS_L:%=$(TESTS_PREFIX)%)
+LIBTREE_TESTS = truncated_property
+ASM_DTBS = test_tree1.dtb
-LIBTREE_TESTS_L = truncated_property
-LIBTREE_TESTS = $(LIBTREE_TESTS_L:%=$(TESTS_PREFIX)%)
+TESTS_util_obj = $(TESTS_objdir)/testutils.o
+TESTS_tree_obj = $(TESTS_objdir)/trees.o
-TESTS = $(LIB_TESTS) $(LIBTREE_TESTS)
+TESTS_lib_exec = $(LIB_TESTS:%=$(TESTS_objdir)/%)
+TESTS_libtree_exec = $(LIBTREE_TESTS:%=$(TESTS_objdir)/%)
+TESTS_dumptrees_exec = $(TEST_objdir)/dumptrees
+TESTS_exec = $(TESTS_lib_exec) $(TESTS_libtree_exec) $(TESTS_dumptrees_exec)
-TESTS_TREES_L = test_tree1.dtb
-TESTS_TREES = $(TESTS_TREES_L:%=$(TESTS_PREFIX)%)
+TESTS_dtb = $(ASM_DTBS:%=$(TESTS_objdir)/%)
-TESTS_TARGETS = $(TESTS) $(TESTS_TREES)
-
-TESTS_DEPFILES = $(TESTS:%=%.d) $(TESTS_PREFIX)testutils.d
-
-TESTS_CLEANFILES_L = *.output vgcore.* *.dtb
-TESTS_CLEANFILES = $(TESTS_CLEANFILES_L:%=$(TESTS_PREFIX)%)
-
-BIN += $(TESTS) $(TESTS_PREFIX)dumptrees
+BIN += $(TESTS_exec)
.PHONY: tests
-tests: $(TESTS) $(TESTS_TREES)
+tests: $(TESTS_exec) $(TESTS_dtb)
-$(LIB_TESTS): %: $(TESTS_PREFIX)testutils.o $(LIBFDT_LIB)
+$(TESTS_lib_exec): %: $(TESTS_util_obj) $(LIBFDT_lib)
-$(LIBTREE_TESTS): %: $(TESTS_PREFIX)testutils.o $(TESTS_PREFIX)trees.o $(LIBFDT_LIB)
+$(TESTS_libtree_exec): %: $(TESTS_util_obj) $(TESTS_tree_obj) $(LIBFDT_lib)
-$(TESTS_PREFIX)dumptrees: $(TESTS_PREFIX)trees.o
+$(TESTS_dumptrees_exec): $(TESTS_tree_obj)
-$(TESTS_TREES): $(TESTS_PREFIX)dumptrees
+$(TESTS_dtb): $(TESTS_dumptrees_exec)
@$(VECHO) DUMPTREES
- cd $(TESTS_PREFIX); ./dumptrees >/dev/null
+ cd $(TESTS_objdir); ./dumptrees >/dev/null
tests_clean:
@$(VECHO) CLEAN "(tests)"
- rm -f $(STD_CLEANFILES:%=$(TESTS_PREFIX)%)
- rm -f $(TESTS_CLEANFILES)
+ rm -f $(STD_CLEANFILES:%=$(TESTS_objdir)/%)
+ rm -f $(TESTS_objdir)/*.dtb
check: tests dtc
- cd $(TESTS_PREFIX); ./run_tests.sh
+ cd $(TESTS_objdir); ./run_tests.sh
checkv: tests dtc
- cd $(TESTS_PREFIX); ./run_tests.sh -v
+ cd $(TESTS_objdir); ./run_tests.sh -v
ifneq ($(DEPTARGETS),)
--include $(TESTS_DEPFILES)
+-include $(TESTS_exec:%=%.d) $(TESTS_util_obj:%.o=%.d) $(TESTS_tree_obj:%.o=%.d)
endif
-
Index: dtc/Makefile.dtc
===================================================================
--- dtc.orig/Makefile.dtc 2007-11-02 14:36:16.000000000 +1100
+++ dtc/Makefile.dtc 2007-11-02 14:36:24.000000000 +1100
@@ -5,21 +5,5 @@
#
DTC_SRCS = dtc.c flattree.c fstree.c data.c livetree.c treesource.c srcpos.c \
checks.c
-DTC_EXTRA = dtc.h srcpos.h
-DTC_LEXFILES = dtc-lexer.l
-DTC_BISONFILES = dtc-parser.y
-
-DTC_LEX_SRCS = $(DTC_LEXFILES:%.l=%.lex.c)
-DTC_BISON_SRCS = $(DTC_BISONFILES:%.y=%.tab.c)
-DTC_BISON_INCLUDES = $(DTC_BISONFILES:%.y=%.tab.h)
-
-DTC_GEN_SRCS = $(DTC_LEX_SRCS) $(DTC_BISON_SRCS)
-DTC_GEN_ALL = $(DTC_GEN_SRCS) $(DTC_BISON_INCLUDES)
-DTC_OBJS = $(DTC_SRCS:%.c=%.o) $(DTC_GEN_SRCS:%.c=%.o)
-
-DTC_CLEANFILES = $(DTC_GEN_ALL)
-
-# We assume the containing Makefile system can do auto-dependencies for most
-# things, but we supply the dependencies on generated header files explicitly
-
-$(addprefix $(DTC_objdir)/,$(DTC_GEN_SRCS:%.c=%.o)): $(addprefix $(DTC_objdir)/,$(DTC_BISON_INCLUDES))
+DTC_GEN_SRCS = dtc-lexer.lex.c dtc-parser.tab.[ch]
+DTC_OBJS = $(DTC_SRCS:%.c=%.o) dtc-lexer.lex.o dtc-parser.tab.o
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: dtc: Further Makefile cleanups
From: David Gibson @ 2007-11-02 3:58 UTC (permalink / raw)
To: Jon Loeliger, linuxppc-dev
In-Reply-To: <20071102034016.GH19839@localhost.localdomain>
On Fri, Nov 02, 2007 at 02:40:16PM +1100, David Gibson wrote:
> Informed by the experience attempting to embed dtc into the kernel
> tree, make further simplification of the Makefiles. In particular
> make the Makefile.dtc and Makefile.libfdt fragments truly minimal.
>
> This change also stops linking dtc with libfdt, which it does not
> need.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Sod. Don't apply, I screwed this one up somewhere along the line.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* dtc: Don't include libfdt in global LDFLAGS
From: David Gibson @ 2007-11-02 4:15 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
Remove the uneccessary LDFLAGS from the top-level makefile. It only
added libfdt/ to the link path. dtc doesn't need libfdt at all, and
the testcases which do, already link libfdt.a by explicit path.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/Makefile
===================================================================
--- dtc.orig/Makefile 2007-11-02 15:06:24.000000000 +1100
+++ dtc/Makefile 2007-11-02 15:06:30.000000000 +1100
@@ -17,7 +17,6 @@ CONFIG_LOCALVERSION =
CPPFLAGS = -I libfdt
CFLAGS = -Wall -g -Os
-LDFLAGS = -Llibfdt
BISON = bison
LEX = flex
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* libfdt: Add more documentation (patch the third)
From: David Gibson @ 2007-11-02 4:47 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
This patch adds documentation in libfdt.h for a few more libfdt
functions. It also makes a slight update to the documentation of
fdt_get_name().
Index: dtc/libfdt/libfdt.h
===================================================================
--- dtc.orig/libfdt/libfdt.h 2007-11-02 15:44:58.000000000 +1100
+++ dtc/libfdt/libfdt.h 2007-11-02 15:46:37.000000000 +1100
@@ -319,28 +319,54 @@ int fdt_path_offset(const void *fdt, con
* fdt_get_name - retreive the name of a given node
* @fdt: pointer to the device tree blob
* @nodeoffset: structure block offset of the starting node
- * @len: pointer to an intger variable (will be overwritten) or NULL
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
*
* fdt_get_name() retrieves the name (including unit address) of the
- * device tree node at structure block offset nodeoffset. If len is
+ * device tree node at structure block offset nodeoffset. If lenp is
* non-NULL, the length of this name is also returned, in the integer
- * pointed to by len.
+ * pointed to by lenp.
*
* returns:
* pointer to the node's name, on success
- * *len contains the length of that name (>=0)
+ * If lenp is non-NULL, *lenp contains the length of that name (>=0)
* NULL, on error
- * *len contains an error code (<0):
+ * if lenp is non-NULL *lenp contains an error code (<0):
* -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
* -FDT_ERR_BADMAGIC,
* -FDT_ERR_BADVERSION,
* -FDT_ERR_BADSTATE, standard meanings
*/
-const char *fdt_get_name(const void *fdt, int nodeoffset, int *len);
+const char *fdt_get_name(const void *fdt, int nodeoffset, int *lenp);
+/**
+ * fdt_get_property - find a given property in a given node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to find
+ * @name: name of the property to find
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * fdt_get_property() retrieves a pointer to the fdt_property
+ * structure within the device tree blob corresponding to the property
+ * named 'name' of the node at offset nodeoffset. If lenp is
+ * non-NULL, the length of the property value also returned, in the
+ * integer pointed to by lenp.
+ *
+ * returns:
+ * pointer to the structure representing the property
+ * if lenp is non-NULL, *lenp contains the length of the property
+ * value (>=0)
+ * NULL, on error
+ * if lenp is non-NULL, *lenp contains an error code (<0):
+ * -FDT_ERR_NOTFOUND, node does not have named property
+ * -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ * -FDT_ERR_BADMAGIC,
+ * -FDT_ERR_BADVERSION,
+ * -FDT_ERR_BADSTATE,
+ * -FDT_ERR_BADSTRUCTURE,
+ * -FDT_ERR_TRUNCATED, standard meanings
+ */
const struct fdt_property *fdt_get_property(const void *fdt, int nodeoffset,
const char *name, int *lenp);
-
static inline struct fdt_property *fdt_get_property_w(void *fdt, int nodeoffset,
const char *name,
int *lenp)
@@ -349,6 +375,33 @@ static inline struct fdt_property *fdt_g
name, lenp);
}
+/**
+ * fdt_getprop - retrieve the value of a given property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to find
+ * @name: name of the property to find
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * fdt_getprop() retrieves a pointer to the value of the property
+ * named 'name' of the node at offset nodeoffset (this will be a
+ * pointer to within the device blob itself, not a copy of the value).
+ * If lenp is non-NULL, the length of the property value also
+ * returned, in the integer pointed to by lenp.
+ *
+ * returns:
+ * pointer to the property's value
+ * if lenp is non-NULL, *lenp contains the length of the property
+ * value (>=0)
+ * NULL, on error
+ * if lenp is non-NULL, *lenp contains an error code (<0):
+ * -FDT_ERR_NOTFOUND, node does not have named property
+ * -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ * -FDT_ERR_BADMAGIC,
+ * -FDT_ERR_BADVERSION,
+ * -FDT_ERR_BADSTATE,
+ * -FDT_ERR_BADSTRUCTURE,
+ * -FDT_ERR_TRUNCATED, standard meanings
+ */
const void *fdt_getprop(const void *fdt, int nodeoffset,
const char *name, int *lenp);
static inline void *fdt_getprop_w(void *fdt, int nodeoffset,
@@ -357,6 +410,31 @@ static inline void *fdt_getprop_w(void *
return (void *)fdt_getprop(fdt, nodeoffset, name, lenp);
}
+/**
+ * fdt_get_path - determine the full path of a node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose path to find
+ * @buf: character buffer to contain the returned path (will be overwritten)
+ * @buflen: size of the character buffer at buf
+ *
+ * fdt_get_path() computes the full path of the node at offset
+ * nodeoffset, and records that path in the buffer at buf.
+ *
+ * NOTE: This function is expensive, as it must scan the device tree
+ * structure from the start to nodeoffset.
+ *
+ * returns:
+ * 0, on success
+ * buf contains the absolute path of the node at
+ * nodeoffset, as a NUL-terminated string.
+ * -FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
+ * -FDT_ERR_NOSPACE, the path of the given node is longer than (bufsize-1)
+ * characters and will not fit in the given buffer.
+ * -FDT_ERR_BADMAGIC,
+ * -FDT_ERR_BADVERSION,
+ * -FDT_ERR_BADSTATE,
+ * -FDT_ERR_BADSTRUCTURE, standard meanings
+ */
int fdt_get_path(const void *fdt, int nodeoffset, char *buf, int buflen);
int fdt_supernode_atdepth_offset(const void *fdt, int nodeoffset,
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [PATCH] Restore deterministic CPU accounting on powerpc
From: Paul Mackerras @ 2007-11-02 4:48 UTC (permalink / raw)
To: Ingo Molnar, Peter Zijlstra, Thomas Gleixner
Cc: Martin Schwidefsky, Christian Borntraeger, linux-kernel,
linuxppc-dev
Since powerpc started using CONFIG_GENERIC_CLOCKEVENTS, the
deterministic CPU accounting (CONFIG_VIRT_CPU_ACCOUNTING) has been
broken on powerpc, because we end up counting user time twice: once in
timer_interrupt() and once in update_process_times().
This fixes the problem by pulling the code in update_process_times
that updates utime and stime into a separate function called
account_process_tick. If CONFIG_VIRT_CPU_ACCOUNTING is not defined,
there is a version of account_process_tick in kernel/timer.c that
simply accounts a whole tick to either utime or stime as before. If
CONFIG_VIRT_CPU_ACCOUNTING is defined, then arch code gets to
implement account_process_tick.
This also lets us simplify the s390 code a bit; it means that the s390
timer interrupt can now call update_process_times even when
CONFIG_VIRT_CPU_ACCOUNTING is turned on, and can just implement a
suitable account_process_tick().
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
I don't know who maintains kernel/timer.c, but I assume it's one of
Ingo, Peter Z. or Thomas.
In fact the arch bits here don't need to go in at the same time as the
changes to include/linux/sched.h and kernel/timer.c, but could go in
later. I have included them here so people can see how these changes
help in the VIRT_CPU_ACCOUNTING=y case. The powerpc changes are
tested, but the s390 changes aren't.
In case it's not obvious, I'd like this (or at least the generic and
powerpc bits) to go in 2.6.24 since it fixes a regression.
arch/powerpc/kernel/process.c | 4 +++-
arch/powerpc/kernel/time.c | 29 +++--------------------------
arch/s390/kernel/time.c | 4 ----
arch/s390/kernel/vtime.c | 9 ++-------
include/asm-powerpc/time.h | 6 ------
include/asm-ppc/time.h | 2 --
include/asm-s390/system.h | 1 -
include/linux/sched.h | 1 +
kernel/timer.c | 21 ++++++++++++++-------
9 files changed, 23 insertions(+), 54 deletions(-)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index b9d8837..eba9332 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -349,9 +349,11 @@ struct task_struct *__switch_to(struct task_struct *prev,
local_irq_save(flags);
+#ifdef CONFIG_VIRT_CPU_ACCOUNTING
account_system_vtime(current);
- account_process_vtime(current);
+ account_process_tick(0);
calculate_steal_time();
+#endif
last = _switch(old_thread, new_thread);
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 9eb3284..f950336 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -259,31 +259,19 @@ void account_system_vtime(struct task_struct *tsk)
* user and system time records.
* Must be called with interrupts disabled.
*/
-void account_process_vtime(struct task_struct *tsk)
+void account_process_tick(int user_tick)
{
cputime_t utime, utimescaled;
utime = get_paca()->user_time;
get_paca()->user_time = 0;
- account_user_time(tsk, utime);
+ account_user_time(current, utime);
/* Estimate the scaled utime by scaling the real utime based
* on the last spurr to purr ratio */
utimescaled = utime * get_paca()->spurrdelta / get_paca()->purrdelta;
get_paca()->spurrdelta = get_paca()->purrdelta = 0;
- account_user_time_scaled(tsk, utimescaled);
-}
-
-static void account_process_time(struct pt_regs *regs)
-{
- int cpu = smp_processor_id();
-
- account_process_vtime(current);
- run_local_timers();
- if (rcu_pending(cpu))
- rcu_check_callbacks(cpu, user_mode(regs));
- scheduler_tick();
- run_posix_cpu_timers(current);
+ account_user_time_scaled(current, utimescaled);
}
/*
@@ -375,7 +363,6 @@ static void snapshot_purr(void)
#else /* ! CONFIG_VIRT_CPU_ACCOUNTING */
#define calc_cputime_factors()
-#define account_process_time(regs) update_process_times(user_mode(regs))
#define calculate_steal_time() do { } while (0)
#endif
@@ -599,16 +586,6 @@ void timer_interrupt(struct pt_regs * regs)
get_lppaca()->int_dword.fields.decr_int = 0;
#endif
- /*
- * We cannot disable the decrementer, so in the period
- * between this cpu's being marked offline in cpu_online_map
- * and calling stop-self, it is taking timer interrupts.
- * Avoid calling into the scheduler rebalancing code if this
- * is the case.
- */
- if (!cpu_is_offline(cpu))
- account_process_time(regs);
-
if (evt->event_handler)
evt->event_handler(evt);
else
diff --git a/arch/s390/kernel/time.c b/arch/s390/kernel/time.c
index 48dae49..6c6be1f 100644
--- a/arch/s390/kernel/time.c
+++ b/arch/s390/kernel/time.c
@@ -145,12 +145,8 @@ void account_ticks(u64 time)
do_timer(ticks);
#endif
-#ifdef CONFIG_VIRT_CPU_ACCOUNTING
- account_tick_vtime(current);
-#else
while (ticks--)
update_process_times(user_mode(get_irq_regs()));
-#endif
s390_do_profile();
}
diff --git a/arch/s390/kernel/vtime.c b/arch/s390/kernel/vtime.c
index 84ff78d..4251de8 100644
--- a/arch/s390/kernel/vtime.c
+++ b/arch/s390/kernel/vtime.c
@@ -32,11 +32,12 @@ static DEFINE_PER_CPU(struct vtimer_queue, virt_cpu_timer);
* Update process times based on virtual cpu times stored by entry.S
* to the lowcore fields user_timer, system_timer & steal_clock.
*/
-void account_tick_vtime(struct task_struct *tsk)
+void account_process_tick(int user_tick)
{
cputime_t cputime;
__u64 timer, clock;
int rcu_user_flag;
+ struct task_struct *tsk = current;
timer = S390_lowcore.last_update_timer;
clock = S390_lowcore.last_update_clock;
@@ -64,12 +65,6 @@ void account_tick_vtime(struct task_struct *tsk)
S390_lowcore.steal_clock -= cputime << 12;
account_steal_time(tsk, cputime);
}
-
- run_local_timers();
- if (rcu_pending(smp_processor_id()))
- rcu_check_callbacks(smp_processor_id(), rcu_user_flag);
- scheduler_tick();
- run_posix_cpu_timers(tsk);
}
/*
diff --git a/include/asm-powerpc/time.h b/include/asm-powerpc/time.h
index f058955..0ff93bf 100644
--- a/include/asm-powerpc/time.h
+++ b/include/asm-powerpc/time.h
@@ -231,12 +231,6 @@ struct cpu_usage {
DECLARE_PER_CPU(struct cpu_usage, cpu_usage_array);
-#ifdef CONFIG_VIRT_CPU_ACCOUNTING
-extern void account_process_vtime(struct task_struct *tsk);
-#else
-#define account_process_vtime(tsk) do { } while (0)
-#endif
-
#if defined(CONFIG_VIRT_CPU_ACCOUNTING)
extern void calculate_steal_time(void);
extern void snapshot_timebases(void);
diff --git a/include/asm-ppc/time.h b/include/asm-ppc/time.h
index 81dbcd4..3715490 100644
--- a/include/asm-ppc/time.h
+++ b/include/asm-ppc/time.h
@@ -153,8 +153,6 @@ extern __inline__ unsigned binary_tbl(void) {
unsigned mulhwu_scale_factor(unsigned, unsigned);
-#define account_process_vtime(tsk) do { } while (0)
-#define calculate_steal_time() do { } while (0)
#define snapshot_timebases() do { } while (0)
#endif /* __ASM_TIME_H__ */
diff --git a/include/asm-s390/system.h b/include/asm-s390/system.h
index d866d33..3e39db1 100644
--- a/include/asm-s390/system.h
+++ b/include/asm-s390/system.h
@@ -99,7 +99,6 @@ static inline void restore_access_regs(unsigned int *acrs)
#ifdef CONFIG_VIRT_CPU_ACCOUNTING
extern void account_vtime(struct task_struct *);
-extern void account_tick_vtime(struct task_struct *);
extern void account_system_vtime(struct task_struct *);
#else
#define account_vtime(x) do { /* empty */ } while (0)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 155d743..4d87b21 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -254,6 +254,7 @@ long io_schedule_timeout(long timeout);
extern void cpu_init (void);
extern void trap_init(void);
+extern void account_process_tick(int user);
extern void update_process_times(int user);
extern void scheduler_tick(void);
diff --git a/kernel/timer.c b/kernel/timer.c
index fb4e67d..8054f6d 100644
--- a/kernel/timer.c
+++ b/kernel/timer.c
@@ -817,6 +817,19 @@ unsigned long next_timer_interrupt(void)
#endif
+#ifndef CONFIG_VIRT_CPU_ACCOUNTING
+void account_process_tick(int user_tick)
+{
+ if (user_tick) {
+ account_user_time(p, jiffies_to_cputime(1));
+ account_user_time_scaled(p, jiffies_to_cputime(1));
+ } else {
+ account_system_time(p, HARDIRQ_OFFSET, jiffies_to_cputime(1));
+ account_system_time_scaled(p, jiffies_to_cputime(1));
+ }
+}
+#endif
+
/*
* Called from the timer interrupt handler to charge one tick to the current
* process. user_tick is 1 if the tick is user time, 0 for system.
@@ -827,13 +840,7 @@ void update_process_times(int user_tick)
int cpu = smp_processor_id();
/* Note: this timer irq context must be accounted for as well. */
- if (user_tick) {
- account_user_time(p, jiffies_to_cputime(1));
- account_user_time_scaled(p, jiffies_to_cputime(1));
- } else {
- account_system_time(p, HARDIRQ_OFFSET, jiffies_to_cputime(1));
- account_system_time_scaled(p, jiffies_to_cputime(1));
- }
+ account_process_tick(user_tick);
run_local_timers();
if (rcu_pending(cpu))
rcu_check_callbacks(cpu, user_tick);
^ permalink raw reply related
* dtc: Make -Idts -Odts preserve node/property labels
From: David Gibson @ 2007-11-02 5:10 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
This patch changes -Odts mode output so that labels on properties,
nodes and memreserve entries in input source are preserved in the
output.
Preserving labels within property values is trickier - another patch
coming later.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/treesource.c
===================================================================
--- dtc.orig/treesource.c 2007-11-02 16:00:19.000000000 +1100
+++ dtc/treesource.c 2007-11-02 16:02:33.000000000 +1100
@@ -176,6 +176,8 @@ static void write_tree_source_node(FILE
struct node *child;
write_prefix(f, level);
+ if (tree->label)
+ fprintf(f, "%s: ", tree->label);
if (tree->name && (*tree->name))
fprintf(f, "%s {\n", tree->name);
else
@@ -184,8 +186,10 @@ static void write_tree_source_node(FILE
for_each_property(tree, prop) {
enum proptype type;
- write_prefix(f, level);
- fprintf(f, "\t%s", prop->name);
+ write_prefix(f, level+1);
+ if (prop->label)
+ fprintf(f, "%s: ", prop->label);
+ fprintf(f, "%s", prop->name);
type = guess_type(prop);
switch (type) {
@@ -220,6 +224,8 @@ void dt_to_source(FILE *f, struct boot_i
struct reserve_info *re;
for (re = bi->reservelist; re; re = re->next) {
+ if (re->label)
+ fprintf(f, "%s: ", re->label);
fprintf(f, "/memreserve/\t%016llx-%016llx;\n",
(unsigned long long)re->re.address,
(unsigned long long)(re->re.address + re->re.size - 1));
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* dtc: Don't force alignment of cell list data
From: David Gibson @ 2007-11-02 5:54 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
At present, defining a property as, say:
foo = [abcd], <ffffffff>;
Will cause dtc to insert 2 bytes of zeros between the abcd and the
ffffffff, to align the cell form data.
Doing so seemed like a good idea at the time, but I don't believe
there are any users who actually rely on this behaviour. Segher
claims that OF has some defined bindings which include properties an
unaligned subsection of which is interpreted as 32-bit ints (i.e. like
cell data).
Worse, this alignment will cause nothing but pain when we add
expression support to dtc (when celldata is included in a larger
bytestring expession, we won't know the size of the preceding chunk of
the expression until it's evaluated, so we would have to carry
alignment fixup information right through the expression evaluation
process).
Therefore, this patch kills off this alignment behaviour.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/dtc-parser.y
===================================================================
--- dtc.orig/dtc-parser.y 2007-11-02 16:45:00.000000000 +1100
+++ dtc/dtc-parser.y 2007-11-02 16:45:42.000000000 +1100
@@ -149,8 +149,7 @@ propdata:
}
| propdataprefix '<' celllist '>'
{
- $$ = data_merge(data_append_align($1,
- sizeof(cell_t)), $3);
+ $$ = data_merge($1, $3);
}
| propdataprefix '[' bytestring ']'
{
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* what is difference between interrupt context and process context?
From: Barisa Kisku @ 2007-11-02 6:11 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 332 bytes --]
Hi,
What is difference between interrupt context and process
context.Fromhardware(register context) view
how they are different.In linux-2.6 interrupt stack is separate from kernel
stack.How interrupt stack pointer
is retrieved?How is the implementation in freescale ppc/powerpc.
please comment.
thanks in advance.
Barisa Kisku
[-- Attachment #2: Type: text/html, Size: 379 bytes --]
^ permalink raw reply
* Re: [PATCH] ehea: add kexec support
From: Michael Ellerman @ 2007-11-02 6:30 UTC (permalink / raw)
To: Christoph Raisch
Cc: Thomas Q Klein, ossthema, Jeff Garzik, Jan-Bernd Themann, netdev,
linux-kernel, linux-ppc, Marcus Eder, Stefan Roscher
In-Reply-To: <OF59B5FFD2.0294206F-ONC1257385.006A802D-C1257385.006CB6BB@de.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1548 bytes --]
On Wed, 2007-10-31 at 20:48 +0100, Christoph Raisch wrote:
> Michael Ellerman <michael@ellerman.id.au> wrote on 30.10.2007 23:50:36:
> >
> > On Tue, 2007-10-30 at 09:39 +0100, Christoph Raisch wrote:
> > >
> > > Michael Ellerman <michael@ellerman.id.au> wrote on 28.10.2007 23:32:17:
> > > Hope I didn't miss anything here...
> >
> > Perhaps. When we kdump the kernel does not call the reboot notifiers, so
> > the code Jan-Bernd just added won't get called. So the eHEA resources
> > won't be freed. When the kdump kernel tries to load the eHEA driver what
> > will happen?
> >
> Good point.
>
> If the device driver tries to allocate resources again (in the kdump
> kernel),
> which have been allocated before (in the crashed kernel) the hcalls will
> fail because from the hypervisor view the resources are still in use.
> Currently there's no method to find out the resource handles for these
> HEA resources allocated by the crashed kernel within the hypervisor...
So the hypervisor can't allocate more resources, because they're already
allocated, but it can't free the ones that are allocated because it
doesn't know what they are? I don't think I understand.
If that's really the way it works then eHEA is more or less broken for
kdump I'm afraid.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] net: Add 405EX support to new EMAC driver
From: Stefan Roese @ 2007-11-02 7:14 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev
This patch adds support for the 405EX to the new EMAC driver. Some as on
AXON, the 405EX handles the MDIO via the RGMII bridge.
Tested on AMCC Kilauea.
Signed-off-by: Stefan Roese <sr@denx.de>
---
drivers/net/ibm_newemac/core.c | 3 ++-
drivers/net/ibm_newemac/rgmii.c | 16 +++++++++++-----
drivers/net/ibm_newemac/rgmii.h | 2 +-
3 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
index 0de3aa2..fd0a585 100644
--- a/drivers/net/ibm_newemac/core.c
+++ b/drivers/net/ibm_newemac/core.c
@@ -2466,7 +2466,8 @@ static int __devinit emac_init_config(struct emac_instance *dev)
if (of_device_is_compatible(np, "ibm,emac4"))
dev->features |= EMAC_FTR_EMAC4;
if (of_device_is_compatible(np, "ibm,emac-axon")
- || of_device_is_compatible(np, "ibm,emac-440epx"))
+ || of_device_is_compatible(np, "ibm,emac-440epx")
+ || of_device_is_compatible(np, "ibm,emac-405ex"))
dev->features |= EMAC_FTR_HAS_AXON_STACR
| EMAC_FTR_STACR_OC_INVERT;
if (of_device_is_compatible(np, "ibm,emac-440spe"))
diff --git a/drivers/net/ibm_newemac/rgmii.c b/drivers/net/ibm_newemac/rgmii.c
index de41695..b9a4ce7 100644
--- a/drivers/net/ibm_newemac/rgmii.c
+++ b/drivers/net/ibm_newemac/rgmii.c
@@ -140,7 +140,12 @@ void rgmii_get_mdio(struct of_device *ofdev, int input)
RGMII_DBG2(dev, "get_mdio(%d)" NL, input);
- if (dev->type != RGMII_AXON)
+ /*
+ * Some platforms (e.g. 440GX) have RGMII support but don't use it for
+ * MDIO access. Only continue if platforms is using MDIO over the RGMII
+ * interface (e.g. AXON, 405EX).
+ */
+ if (dev->type != RGMII_HAS_MDIO)
return;
mutex_lock(&dev->lock);
@@ -161,7 +166,7 @@ void rgmii_put_mdio(struct of_device *ofdev, int input)
RGMII_DBG2(dev, "put_mdio(%d)" NL, input);
- if (dev->type != RGMII_AXON)
+ if (dev->type != RGMII_HAS_MDIO)
return;
fer = in_be32(&p->fer);
@@ -251,8 +256,9 @@ static int __devinit rgmii_probe(struct of_device *ofdev,
}
/* Check for RGMII type */
- if (of_device_is_compatible(ofdev->node, "ibm,rgmii-axon"))
- dev->type = RGMII_AXON;
+ if (of_device_is_compatible(ofdev->node, "ibm,rgmii-axon") ||
+ of_device_is_compatible(ofdev->node, "ibm,rgmii-405ex"))
+ dev->type = RGMII_HAS_MDIO;
else
dev->type = RGMII_STANDARD;
@@ -264,7 +270,7 @@ static int __devinit rgmii_probe(struct of_device *ofdev,
printk(KERN_INFO
"RGMII %s %s initialized\n",
- dev->type == RGMII_STANDARD ? "standard" : "axon",
+ dev->type == RGMII_STANDARD ? "standard" : "has-mdio",
ofdev->node->full_name);
wmb();
diff --git a/drivers/net/ibm_newemac/rgmii.h b/drivers/net/ibm_newemac/rgmii.h
index 5780683..f1b0ef5 100644
--- a/drivers/net/ibm_newemac/rgmii.h
+++ b/drivers/net/ibm_newemac/rgmii.h
@@ -23,7 +23,7 @@
/* RGMII bridge type */
#define RGMII_STANDARD 0
-#define RGMII_AXON 1
+#define RGMII_HAS_MDIO 1
/* RGMII bridge */
struct rgmii_regs {
--
1.5.3.4.498.g9c514
^ permalink raw reply related
* Re: [PATCH] Restore deterministic CPU accounting on powerpc
From: Martin Schwidefsky @ 2007-11-02 7:49 UTC (permalink / raw)
To: Paul Mackerras
Cc: Peter Zijlstra, Christian Borntraeger, linux-kernel, linuxppc-dev,
Ingo Molnar, Thomas Gleixner
In-Reply-To: <18218.44089.274628.680088@cargo.ozlabs.ibm.com>
On Fri, 2007-11-02 at 15:48 +1100, Paul Mackerras wrote:
> This also lets us simplify the s390 code a bit; it means that the s390
> timer interrupt can now call update_process_times even when
> CONFIG_VIRT_CPU_ACCOUNTING is turned on, and can just implement a
> suitable account_process_tick().
Just tested on s390 with CONFIG_VIRT_CPU_ACCOUNTING=y. Works fine and it
is a nice cleanup of the s390 timer code. Thanks Paul.
Acked-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
^ permalink raw reply
* RE:
From: MingLiu @ 2007-11-02 9:35 UTC (permalink / raw)
To: Mead, Joseph, linuxppc-embedded
In-Reply-To: <D1AFFAE2CC4BD54CA4C1543CFF4A4FCC59788F@exchangemb3.bnl.gov>
[-- Attachment #1: Type: text/plain, Size: 743 bytes --]
Hi Joe,
I don't think you can do 64 bit transfer at once because ppc405 is a 32-bit CPU. So we have to the transfer in twice.
BR
Ming
Date: Thu, 1 Nov 2007 14:18:07 -0400From: mead@bnl.govTo: linuxppc-embedded@ozlabs.orgSubject:
I am using a Xilinx ML403 board and created a custom IP that connects to the PLB bus. The PLB bus is 64 bits wide. To communicate with the custom IP I have been using iowrite32() and ioread32() function calls to grab 32 bits at a time. Is it possible to grab the full 64 bits in one transfer? I don’t see an iowrite64() or ioread64() function…
Thanks,Joe
_________________________________________________________________
用 Live Search 搜尽天下资讯！
http://www.live.com/?searchOnly=true
[-- Attachment #2: Type: text/html, Size: 2235 bytes --]
^ permalink raw reply
* Re: [PATCH] ehea: add kexec support
From: Christoph Raisch @ 2007-11-02 10:19 UTC (permalink / raw)
To: michael
Cc: Thomas Q Klein, ossthema, Jeff Garzik, Jan-Bernd Themann, netdev,
linux-kernel, linux-ppc, Marcus Eder, Stefan Roscher
In-Reply-To: <1193985008.1782.7.camel@concordia>
Michael Ellerman <michael@ellerman.id.au> wrote on 02.11.2007 07:30:08:
> On Wed, 2007-10-31 at 20:48 +0100, Christoph Raisch wrote:
> > Michael Ellerman <michael@ellerman.id.au> wrote on 30.10.2007 23:50:36:
> If that's really the way it works then eHEA is more or less broken for
> kdump I'm afraid.
We think we have a way to workaround this, but let me first try to
explain the base problem.
DD allocates HEA resources and gets firmware_handles for these resources.
To free the resources DD needs to use exactly these handles.
There's no generic firmware call "clean out all resources".
Allocating the same resources twice does not work.
So a new kernel can't free the resources allocated by an old kernel,
because the numeric values of the handles aren't known anymore.
Potential Solution:
Hea driver cleanup function hooks into ppc_md.machine_crash_shutdown
and frees all firmware resources at shutdown time of the crashed kernel.
crash_kexec continues and loads new kernel.
The new kernel restarts the HEA driver within kdump kernel, which will work
because resources have been freed before.
Michael, would this work?
Gruss / Regards
Christoph R.
^ 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