* Re: Linux on PPC
From: Adrian Cox @ 2006-03-03 9:33 UTC (permalink / raw)
To: David Hawkins; +Cc: linuxppc-embedded
In-Reply-To: <4407CFD3.4060206@ovro.caltech.edu>
On Thu, 2006-03-02 at 21:10 -0800, David Hawkins wrote:
> Step 2. Find a PPC 750 port in the Linux source.
>
> For example, in the 2.6 series kernel, the place to start
> looking is under arch/ppc/platforms. grep -Ie 750 shows
> up some of the PPC 750 based systems.
>
> chestnut.c 750FX/GX evaluation board
> katana.c Looks like one too
> prpmc750.c Looks like a Motorola board
>
> Look at the comments in the code, look at the memory map
> of the reference board versus your custom board. There is
> a very good chance that the custom board is based on a
> reference design - thats the whole point of them.
I'd add the caution that within the 6xx, 7xx, and 7xxx family of
processors, the north-bridge makes a much greater difference than the
processor core. Within that family of processors Linux will auto-detect
the processor specific features at boot time. It will be easier to port
from a board using a 7450 with the same north-bridge, than from a board
using a 750 with a different north-bridge.
--
Adrian Cox <adrian@humboldt.co.uk>
^ permalink raw reply
* Re: How to quickly write cleanmarkers to jffs2 partitions?
From: Mathieu Deschamps @ 2006-03-03 9:08 UTC (permalink / raw)
To: David Jander; +Cc: linuxppc-embedded
In-Reply-To: <200603021706.14618.david.jander@protonic.nl>
On Thursday 02 March 2006 17:06, David Jander wrote:
> Hi,
>
> I was wondering if there is a trick or common technique I am ignoring to
> make this more efficient:
>
> This is for a 2.4 kernel based system.
> In production we use either u-boot or a NFS mounted linux system to erase
> flash and write jffs2 partitions to it. The jffs2 images are small (not
> padded to full partition size to save programming time), but the partitions
> are rather big (12 Mbyte in one case). Problem is that when booting for the
> first time, one has to wait several minutes (during which the system is
> more or less useless and busy) to get all cleanmarkers written to flash by
> the jffs2 gc thread. This huge delay is rather unacceptable for production,
> so we are looking for a work-around.
>
> One option would be to make jffs2 images that are padded to full partition
> size, but that also isn't very efficient, considering the image is only
> about 100k in beginning and the partition is 12 Mbyte in size. That would
> take a lot of time programming flash (less time than having the jffs2
> driver fix this nevertheless).
>
> Another option is making a little program that writes cleanmarkers in every
> eraseblock starting from the first completely empty one in a partition
> before mounting that partition for the very first time after flashing.
>
> Since this seems to me like a common situation, I'd like to know if anybody
> knows about a better solution, or if anybody has already dealt with this
> before.
>
> Greetings,
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 ?
Best Regards,
Mathieu Deschamps.
^ permalink raw reply
* RE: boot failure on lite5200b board
From: #LI JIANGGAN# @ 2006-03-03 8:06 UTC (permalink / raw)
To: John Rigby; +Cc: haidong_feng, linuxppc-embedded
In-Reply-To: <4b73d43f0603011652w39fb4393x8879891b7538f0b1@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 22566 bytes --]
Thanks John, the Kernel now boots well. However it gives a kernel panic while mounting the root file sysem over NFS:
Looking up port of RPC 100003/2 on 10.190.3.103
RPC: sendmsg returned error 101
portmap: RPC call returned error 101
Root-NFS: Unable to get nfsd port number from server, using default
I couldn't figure out why error 101 /* Network is unreachable */ is given. Below is my current U-boot settings and a snapshot of the booting:
=> printenv
baudrate=115200
autoload=no
ethact=FEC ETHERNET
ethaddr=00:01:9F:00:27:2F
preboot=echo; echo Autostarting. Press any key to abort..; echo
bootdelay=5
hostname=icecube
bootfile=MPC5200/uImage
nv=nfsroot root=/dev/nfs rw nfsroot=10.190.3.113:/opt/eldk/rootfs
netmask=255.255.240.0
ipaddr=10.190.3.144
serverip=10.190.3.103
bootcmd=run net_nfs
netdev=eth0
rootpath=/opt/eldk-4-0/rootfs
ramargs=setenv bootargs root=/dev/ram rw
addip=setenv bootargs ip=10.190.3.144:10.190.3.103:10.190.3.103:255.255.240.0:icecube:eth0:off panic=1
ip=10.190.3.144:10.190.3.103:10.190.3.103:255.255.240.0:icecube:eth0:off
net_nfs=tftp 200000 MPC5200/uImage;run nfsargs;bootm
nfsroot=10.190.3.103:/opt/eldk-4-0/rootfs
rootfs=10.190.3.103:/opt/eldk-4-0/rootfs
nfsargs=setenv bootargs console=ttyS0,115200 nfsroot=10.190.3.103:/opt/eldk-4-0/nfs root=/dev/nfs rw
stdin=serial
stdout=serial
stderr=serial
Environment size: 882/65532 bytes
=> boot
Using FEC ETHERNET device
TFTP from server 10.190.3.103; our IP address is 10.190.3.144
Filename 'MPC5200/uImage'.
Load address: 0x200000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
###################################
done
Bytes transferred = 1510143 (170aff hex)
## Booting image at 00200000 ...
Image Name: Linux-2.6.11.7
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1510079 Bytes = 1.4 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
id mach(): done
MMU:enter
MMU:hw init
MMU:mapin
MMU:setio
MMU:exit
setup_arch: enter
setup_arch: bootmem
ocp: exit
arch: exit
Linux version 2.6.11.7 (root@bob) (gcc version 3.3.2) #1 Tue Sep 6 22:40:03 UTC 2005
Real-Time Preemption Support (c) Ingo Molnar
Built 1 zonelists
Kernel command line: console=ttyS0,115200 nfsroot=10.190.3.103:/opt/eldk-4-0/nfs root=/dev/nfs rw
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: 256268k available (2336k kernel code, 896k data, 140k init, 0k highmem)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
BUG: scheduling while atomic: swapper/0x00000001/0
caller is schedule+0x50/0xe8
Call trace:
[c0006bd8] dump_stack+0x18/0x28
[c0242818] __sched_text_start+0x69c/0x6a0
[c024286c] schedule+0x50/0xe8
[c0003f00] syscall_exit_work+0x108/0x10c
[c030c578] proc_root_init+0x144/0x150
[c0320000] 0xc0320000
[c02fe624] start_kernel+0x180/0x1b8
[000035fc] 0x35fc
spawn_desched_task(00000000)
desched cpu_callback 3/00000000
ksoftirqd started up.
softirq RT prio: 24.
desched cpu_callback 2/00000000
desched thread 0 started up.
NET: Registered protocol family 16
PCI: Probing PCI hardware
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
JFFS2 version 2.2. (C) 2001-2003 Red Hat, Inc.
ppdev: user-space parallel port driver
Serial: MPC52xx PSC driver
ttyS0 at MMIO 0xf0002000 (irq = 39) is a MPC52xx PSC
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
loop: loaded (max 8 devices)
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ipb=132MHz, set clock period to 7
GPIO config: 91051024
ATA invalid: 01000000
ATA hostcnf: 03000000
ATA pio1 : 100a0a00
ATA pio2 : 02040600
XLB Arb cnf: 0000a366
mpc52xx_ide: Setting up IDE interface ide0...
flash chip on the Lite5200/Lite5200B: Found 1 x16 devices at 0x0 in 8-bit bank
flash chip on the Lite5200/Lite5200B: Found 1 x16 devices at 0x1000000 in 8-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
flash chip on the Lite5200/Lite5200B: CFI does not contain boot bank location. Assuming top.
number of CFI chips: 2
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
Creating 7 MTD partitions on "flash chip on the Lite5200/Lite5200B":
0x00000000-0x01000000 : "Filesystem"
0x01000000-0x01040000 : "BootLOW"
0x01040000-0x01060000 : "EnvLOW"
0x01060000-0x01d00000 : "Spare"
0x01d00000-0x01f00000 : "Kernel"
0x01f00000-0x01f40000 : "BootHIGH"
0x01f40000-0x01f60000 : "EnvHIGH"
ocp-ohci 02: new USB bus registered, assigned bus number 1
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.0:USB HID core driver
mice: PS/2 mouse device common for all mice
i2c /dev entries driver
i2c-algo-52xx.o: scanning bus Lite5200 I2C module #1 interface...
................................................................................................................................
i2c-lite5200.o: I2C module #1 installed
i2c-algo-52xx.o: scanning bus Lite5200 I2C module #2 interface...
................................................................................(0x50)..............................................(0x7f)
i2c-lite5200.o: I2C module #2 installed
Advanced Linux Sound Architecture Driver Version 1.0.8 (Thu Jan 13 09:39:32 2005 UTC).
ALSA device list:
No soundcards found.
NET: Registered protocol family 2
IP: routing cache hash table of 256 buckets, 16Kbytes
TCP established hash table entries: 16384 (order: 8, 1048576 bytes)
TCP bind hash table entries: 16384 (order: 7, 917504 bytes)
TCP: Hash tables configured (established 16384 bind 16384)
NET: Registered protocol family 1
NET: Registered protocol family 17
Looking up port of RPC 100003/2 on 10.190.3.103
RPC: sendmsg returned error 101
portmap: RPC call returned error 101
Root-NFS: Unable to get nfsd port number from server, using default
Looking up port of RPC 100005/1 on 10.190.3.103
RPC: sendmsg returned error 101
portmap: RPC call returned error 101
Root-NFS: Unable to get mountd port number from server, using default
RPC: sendmsg returned error 101
mount: RPC call returned error 101
Root-NFS: Server returned error -101 while mounting /opt/eldk-4-0/nfs
VFS: Unable to mount root fs via NFS, trying floppy.
VFS: Cannot open root device "nfs" or unknown-block(2,0)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)
<0>Rebooting in 180 seconds..
regards,
Jianggan
-----Original Message-----
From: John Rigby [mailto:jcrigby@gmail.com]
Sent: Thu 3/2/2006 8:52
To: #LI JIANGGAN#
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: boot failure on lite5200b board
Here is a uboot setup that works with a freescale kernel:
bootdelay=5
baudrate=115200
preboot=echo;echo Type "run flash_nfs" to mount root filesystem over NFS;echo
autoload=no
ethact=FEC ETHERNET
ramargs=setenv bootargs root=/dev/ram rw
jffs2args=setenv bootargs root=/dev/mtdblock0 rw rootfstype=jffs2
addip=setenv bootargs $(bootargs)
ip=$(ipaddr):$(serverip):$(gatewayip):$(netmask):$(hostname):$(netdev):off
panic=1
flash_nfs=run nfsargs addip;bootm $(kernel_addr)
flash_self=run ramargs addip;bootm $(kernel_addr) $(ramdisk_addr)
flash_jffs2=run jffs2args;bootm $(kernel_addr)
net_nfs=tftp 200000 $(bootfile);run nfsargs addip;bootm
netdev=eth0
ethaddr=00:04:9f:22:33:44
bootfile=/tftpboot/uImage
kernel_addr=ffd00000
rootpath=/tftpboot/ltib
filesize=c9d700
fileaddr=1000000
gatewayip=172.27.255.254
netmask=255.255.0.0
ipaddr=172.27.152.99
serverip=172.27.152.5
bootcmd=run net_nfs
nfsargs=setenv bootargs console=ttyS0,115200 root=/dev/nfs rw
nfsroot=$(serverip):$(rootpath)
stdin=serial
stdout=serial
stderr=serial
Change ip info, bootfile, rootpath etc to fit you config.
If you want it to work with Sylvain's kernel then you need to change
ttyS0 to ttyPSC0.
Also add a printenv just before the bootm so you can verify that your
bootargs really are getting set correctly.
On 3/1/06, #LI JIANGGAN# <lijianggan@pmail.ntu.edu.sg> wrote:
>
>
> how about the following U-boot settings:
>
> ..............................
>
>
> Hit any key to stop autoboot: 0
> => printenv
> baudrate=115200
> autoload=no
> ethact=FEC ETHERNET
> ethaddr=00:01:9F:00:27:2F
> preboot=echo; echo Autostarting. Press any key to abort..; echo
> bootdelay=5
> hostname=icecube
> bootfile=MPC5200/uImage
> nv=nfsroot root=/dev/nfs rw nfsroot=10.190.3.113:/opt/eldk/rootfs
> netmask=255.255.240.0
> ipaddr=10.190.3.144
> serverip=10.190.3.103
> bootcmd=run net_nfs
>
> rootfs=root=/dev/nfs rw
> netdev=eth0
> rootpath=/opt/eldk-4-0/rootfs
> nfsargs=setenv bootargs root=/dev/nfs rw
> nfsroot=10.190.3.103:/opt/eldk-4-0/rootfs
>
> ramargs=setenv bootargs root=/dev/ram rw
> addip=setenv bootargs
> ip=10.190.3.144:10.190.3.103:10.190.3.103:255.255.240.0:icecube:eth0:off
> panic=1
> net_nfs=tftp 200000 MPC5200/uImage;run nfsargs addip;bootm
>
> stdin=serial
> stdout=serial
> stderr=serial
>
> Environment size: 738/65532 bytes
> => .
> ................................
>
>
>
> The output is still the same, it hangs after displaying arch:exit
>
> I have also tried the above settings with console set, it gives the same
> output
>
> I am really wondering whether the problem is with the kernel. Sylvain's
> kernel uImage is only around 600k while the one from freescale is 1.4M,
> anybody knows where the difference is?
>
> .....................................
>
> Autostarting. Press any key to abort..
>
> Hit any key to stop autoboot: 0
> Using FEC ETHERNET device
> TFTP from server 10.190.3.103; our IP address is 10.190.3.144
> Filename 'MPC5200/uImage'.
> Load address: 0x200000
>
> Loading:
> #################################################################
>
> #################################################################
>
> #################################################################
>
> #################################################################
> ###################################
> done
> Bytes transferred = 1510143 (170aff hex)
> ## Booting image at 00200000 ...
>
> Image Name: Linux-2.6.11.7
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 1510079 Bytes = 1.4 MB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
> id mach(): done
> MMU:enter
> MMU:hw init
> MMU:mapin
> MMU:setio
> MMU:exit
> setup_arch: enter
> setup_arch: bootmem
> ocp: exit
> arch: exit
>
>
>
>
>
> .....................
>
> Regards,
>
> Jianggan LI
>
> ________________________________
>
> From: John Rigby [mailto:jcrigby@gmail.com]
> Sent: Sat 2/25/2006 1:17
> To: #LI JIANGGAN#
> Cc: tnt@246tnt.com; linuxppc-embedded@ozlabs.org
>
> Subject: Re: boot failure on lite5200b board
>
>
>
>
> I don't think your syntax for appending to an env variable is correct:
>
> try:
> set bootargs $(bootargs) ...appended stuff...
> instead of:
> set bootargs env bootargs ...appended stuff....
>
> Also to see what bootargs is actually set to after all the nested
> commands, add a printenv just before the bootm
>
> On 2/23/06, #LI JIANGGAN# <lijianggan@pmail.ntu.edu.sg> wrote:
> >
> >
> > I have actually tried both kernel with both console configurations. It
> gave
> > the same output, thus I presume that the problem lies somewhere else. I
> > attached the log to this email.
> >
> > the board is Lite5200B Version 1.0. Which .config file do you want?
> >
> > Sylvain, we have ordered a debugging set but we are still waiting for
> > delivery, the leaking time is said to be one month, tant pis. And the log
> I
> > attached here are booting from a higher address (0x500000).
> >
> > My current u-boot args:
> > Autostarting. Press any key to abort..
> >
> > Hit any key to stop autoboot: 0
> > => printenv
> > baudrate=115200
> > autoload=no
> > ethact=FEC ETHERNET
> > flshroot=root=/dev/mtdblock2 rw
> > ethaddr=00:01:9F:00:27:2F
> > preboot=echo; echo Autostarting. Press any key to abort..; echo
> > bootdelay=5
> > hostname=icecube
> > bootfile=MPC5200/uImage
> > nv=nfsroot root=/dev/nfs rw nfsroot=10.190.3.113:/opt/eldk/rootfs
> > ip=ip=10.190.3.144:10.190.3.103:10.190.3.103:255.255.240.0:icecube::off
> > nfsroot=root=/dev/nfs rw
> nfsroot=10.190.3.103:/opt/eldk-4-0/rootfs
> > bootcmd=run net_nfs
> > filesize=546
> > fileaddr=500000
> > netmask=255.255.240.0
> > ipaddr=10.190.3.144
> > serverip=10.190.3.103
> > setconsole=setenv bootargs console=ttyPSC0, 115200n8 console=tty1
> > rootfs=root=/dev/nfs rw
> nfsroot=10.190.3.103:/opt/eldk-4-0/rootfs
> > bootargs=env bootargs root=/dev/nfs rw
> > nfsroot=10.190.3.103:/opt/eldk-4-0/rootfs
> > ip=10.190.3.144:10.190.3.103:10.190.3.103:255.255.240.0:icecube::off
> > flash_nfs=run setconsole nfsargs addip;bootm
> > net_nfs=tftp 500000 MPC5200/uImage;run setconsole nfsargs addip;bootm
> > nfsargs=setenv bootargs env bootargs root=/dev/nfs rw
> > nfsroot=10.190.3.103:/opt/eldk-4-0/rootfs
> >
> ip=10.190.3.144:10.190.3.103:10.190.3.103:255.255.240.0:icecube::offroot=/dev/nfs
> > rw
> > addip=setenv bootargs env bootargs root=/dev/nfs rw
> > nfsroot=10.190.3.103:/opt/eldk-4-0/rootfs
> > ip=10.190.3.144:10.190.3.103:10.190.3.103:255.255.240.0:icecube::off
> > ramargs=setenv bootargs root=/dev/ram rw
> > console=console=ttyS0,115200n8 console=tty1
> > stdin=serial
> > stdout=serial
> > stderr=serial
> >
> > Environment size: 1472/65532 bytes
> > =>
> >
> >
> >
> >
> > USING Sylvain's KERNEL:
> >
> > U-Boot 1.1.3 (Feb 6 2006 - 09:56:46)
> >
> > CPU: MPC5200 v2.2 at 462 MHz
> > Bus 132 MHz, IPB 132 MHz, PCI 33 MHz
> > Board: Freescale MPC5200 (Lite5200B)
> > I2C: 85 kHz, ready
> > DRAM: 256 MB
> > FLASH: 32 MB
> > PCI: Bus Dev VenId DevId Class Int
> > 00 1a 1057 5809 0680 00
> > In: serial
> > Out: serial
> > Err: serial
> > Net: FEC ETHERNET
> > IDE: Bus 0: OK
> > Device 0: not available
> > Device 1: not available
> >
> > Autostarting. Press any key to abort..
> >
> > Hit any key to stop autoboot: 0
> > Using FEC ETHERNET device
> > TFTP from server 10.190.3.103; our IP address is 10.190.3.144
> > Filename 'MPC5200/uImage'.
> > Load address: 0x500000
> > Loading:
> #################################################################
> >
> ################################################################
> > done
> > Bytes transferred = 658114 (a0ac2 hex)
> > ## Booting image at 00500000 ...
> > Image Name: Linux-2.6.16-rc1
> > Image Type: PowerPC Linux Kernel Image (gzip compressed)
> > Data Size: 658050 Bytes = 642.6 kB
> > Load Address: 00000000
> > Entry Point: 00000000
> > Verifying Checksum ... OK
> > Uncompressing Kernel Image ... OK
> > id mach(): done
> > MMU:enter
> > MMU:hw init
> > MMU:mapin
> > MMU:setio
> > MMU:exit
> > setup_arch: enter
> > setup_arch: bootmem
> > arch: exit
> >
> >
> >
> > USING KERNEL FROM Freescale:
> >
> > U-Boot 1.1.3 (Feb 6 2006 - 09:56:46)
> >
> > CPU: MPC5200 v2.2 at 462 MHz
> > Bus 132 MHz, IPB 132 MHz, PCI 33 MHz
> > Board: Freescale MPC5200 (Lite5200B)
> > I2C: 85 kHz, ready
> > DRAM: 256 MB
> > FLASH: 32 MB
> > PCI: Bus Dev VenId DevId Class Int
> > 00 1a 1057 5809 0680 00
> > In: serial
> > Out: serial
> > Err: serial
> > Net: FEC ETHERNET
> > IDE: Bus 0: OK
> > Device 0: not available
> > Device 1: not available
> >
> > Autostarting. Press any key to abort..
> >
> > Hit any key to stop autoboot: 0
> > Using FEC ETHERNET device
> > TFTP from server 10.190.3.103; our IP address is 10.190.3.144
> > Filename 'MPC5200/uImage'.
> > Load address: 0x500000
> > Loading:
> #################################################################
> >
> #################################################################
> >
> #################################################################
> >
> #################################################################
> > ###################################
> > done
> > Bytes transferred = 1510143 (170aff hex)
> > ## Booting image at 00500000 ...
> > Image Name: Linux-2.6.11.7
> > Image Type: PowerPC Linux Kernel Image (gzip compressed)
> > Data Size: 1510079 Bytes = 1.4 MB
> > Load Address: 00000000
> > Entry Point: 00000000
> > Verifying Checksum ... OK
> > Uncompressing Kernel Image ... OK
> > id mach(): done
> > MMU:enter
> > MMU:hw init
> > MMU:mapin
> > MMU:setio
> > MMU:exit
> > setup_arch: enter
> > setup_arch: bootmem
> > ocp: exit
> > arch: exit
> >
> >
> >
> >
> > -----Original Message-----
> > From: John Rigby [mailto:jcrigby@gmail.com]
> > Sent: Fri 2/24/2006 0:18
> > To: #LI JIANGGAN#
> > Subject: Re: boot failure on lite5200b board
> >
> > If you are using Sylvain's kernel you need to set console=ttyPSC0. If
> you
> > are
> > using a kernel from Freescale then you need to set console=ttyS0.
> >
> > Also what rev of the board do you have?
> >
> >
> >
> > On 2/23/06, #LI JIANGGAN# <lijianggan@pmail.ntu.edu.sg> wrote:
> > >
> > >
> > > Thank you Jos? Mar?a and Andrey for your advices, however the problem
>
> > > remains. I've tried setting the console (though I remember that our
> > previous
> > > lite5200 board was working fine on kernel 2.4 without setting the
> > console);
> > > meantime, I've set the booting image to 0x500000; I have also tried
> using
> > > the kernel image come together with the BSP, it's always the same
> error.
> > >
> > > Sylvain, I've actually using your kernel source, the compiled image is
> > > around 700k (compared to the 1.4M image from the BSP), but it doesn't
> > solve
> > > the problem. So I presume that the problem is lying somewhere else.
> > >
> > > A SNAPSHOT OF THE BOOTING MESSAGES:
> > >
> > >
> > > U-Boot 1.1.3 (Feb 6 2006 - 09:56:46)
> > >
> > > CPU: MPC5200 v2.2 at 462 MHz
> > > Bus 132 MHz, IPB 132 MHz, PCI 33 MHz
> > > Board: Freescale MPC5200 (Lite5200B)
> > > I2C: 85 kHz, ready
> > > DRAM: 256 MB
> > > FLASH: 32 MB
> > > PCI: Bus Dev VenId DevId Class Int
> > > 00 1a 1057 5809 0680 00
> > > In: serial
> > > Out: serial
> > > Err: serial
> > > Net: FEC ETHERNET
> > > IDE: Bus 0: OK
> > > Device 0: not available
> > > Device 1: not available
> > >
> > > Autostarting. Press any key to abort..
> > >
> > > Hit any key to stop autoboot: 0
> > > Using FEC ETHERNET device
> > > TFTP from server 10.190.3.103; our IP address is 10.190.3.144
> > > Filename 'MPC5200/uImage'.
> > > Load address: 0x100000
> > > Loading:
> > >
> #################################################################
> > >
> > >
> ################################################################
> > > done
> > > Bytes transferred = 658114 (a0ac2 hex)
> > > ## Booting image at 00100000 ...
> > > Image Name: Linux-2.6.16-rc1
> > > Image Type: PowerPC Linux Kernel Image (gzip compressed)
> > > Data Size: 658050 Bytes = 642.6 kB
> > > Load Address: 00000000
> > > Entry Point: 00000000
> > > Verifying Checksum ... OK
> > > Uncompressing Kernel Image ... OK
> > > id mach(): done
> > > MMU:enter
> > > MMU:hw init
> > > MMU:mapin
> > > MMU:setio
> > > MMU:exit
> > > setup_arch: enter
> > > setup_arch: bootmem
> > > arch: exit
> > >
> > >
> > > I am wondering whether it's a kernel problem or more likely to be a
> > problem
> > > lying with the U-boot. It seems to hang when executing setup_arch()
> > > function, or maybe there is sth else behind the wall?
> > >
> > > Regards,
> > > Jianggan LI
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Sylvain Munaut [mailto:tnt@246tNt.com]
> > > Sent: Thu 2/23/2006 15:38
> > > To: #LI JIANGGAN#
> > > Cc: linuxppc-embedded@ozlabs.org
> > > Subject: Re: boot failure on lite5200b board
> > >
> > > #LI JIANGGAN# wrote:
> > > > Hello all,
> > > >
> > > > For my end-of-study project, I am working on an embedded system with
> > > > reference of freescale's lite5200b reference board. I was trying to
> > boot
> > > > Linux 2.6.15 on the board (with the fec and bestcomm corrected).
> > however
> > > > the booting was stuck at the following stage:
> > >
> > > In addition to what has already been said (use a higher address for
> the
> > > image and don't forget console=ttyPSC0 in kernel command line), make
> > > sure you use the kernel from my git tree, it contains a few patches
> from
> > > John Rigby to add support for the lite5200b.
> > >
> > > Please report if it works, I've not been able to test those myself
> since
> > > i'm still on lite5200.
> > >
> > >
> > > Sylvain
> > >
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Linuxppc-embedded mailing list
> > > Linuxppc-embedded@ozlabs.org
> > > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> > >
> > >
> >
> >
> >
> >
> >
>
>
>
[-- Attachment #2: Type: text/html, Size: 32295 bytes --]
^ permalink raw reply
* [PATCH] powerpc: Fix windfarm_pm112 not starting all control loops
From: Benjamin Herrenschmidt @ 2006-03-03 6:13 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list, Linux Kernel list
This adds a couple of printk's to windfarm_pm112 to display which
control loops are actually starting and fixes a bug where it would not
start all loops.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-work/drivers/macintosh/windfarm_pm112.c
===================================================================
--- linux-work.orig/drivers/macintosh/windfarm_pm112.c 2006-03-03 16:24:44.000000000 +1100
+++ linux-work/drivers/macintosh/windfarm_pm112.c 2006-03-03 17:04:53.000000000 +1100
@@ -358,6 +358,7 @@ static void backside_fan_tick(void)
return;
if (!backside_tick) {
/* first time; initialize things */
+ printk(KERN_INFO "windfarm: Backside control loop started.\n");
backside_param.min = backside_fan->ops->get_min(backside_fan);
backside_param.max = backside_fan->ops->get_max(backside_fan);
wf_pid_init(&backside_pid, &backside_param);
@@ -407,6 +408,7 @@ static void drive_bay_fan_tick(void)
return;
if (!drive_bay_tick) {
/* first time; initialize things */
+ printk(KERN_INFO "windfarm: Drive bay control loop started.\n");
drive_bay_prm.min = drive_bay_fan->ops->get_min(drive_bay_fan);
drive_bay_prm.max = drive_bay_fan->ops->get_max(drive_bay_fan);
wf_pid_init(&drive_bay_pid, &drive_bay_prm);
@@ -458,6 +460,7 @@ static void slots_fan_tick(void)
return;
if (!slots_started) {
/* first time; initialize things */
+ printk(KERN_INFO "windfarm: Slots control loop started.\n");
wf_pid_init(&slots_pid, &slots_param);
slots_started = 1;
}
@@ -504,6 +507,7 @@ static void pm112_tick(void)
if (!started) {
started = 1;
+ printk(KERN_INFO "windfarm: CPUs control loops started.\n");
for (i = 0; i < nr_cores; ++i) {
if (create_cpu_loop(i) < 0) {
failure_state = FAILURE_PERM;
@@ -594,8 +598,6 @@ static void pm112_new_sensor(struct wf_s
{
unsigned int i;
- if (have_all_sensors)
- return;
if (!strncmp(sr->name, "cpu-temp-", 9)) {
i = sr->name[9] - '0';
if (sr->name[10] == 0 && i < NR_CORES &&
^ permalink raw reply
* [PATCH] powerpc: Fix old g5 issues with windfarm
From: Benjamin Herrenschmidt @ 2006-03-03 6:03 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list, Linux Kernel list
Some of the windfarm sensor modules can initialize on old machines that
don't have full windfarm support like non-dual core desktop G5s.
Unfortunately, by doing so, they would trigger a bug in their matching
algorithm causing them to attach to the wrong bus, thus triggering
issues with the i2c core and breaking the thermal driver.
This patch fixes the probing issue (so that they will work when a
windfarm port is done to these machines) and also prevents for now
windfarm to load at all on these machines that still use therm_pm72 to
avoid wasting resources.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-work/drivers/macintosh/windfarm_lm75_sensor.c
===================================================================
--- linux-work.orig/drivers/macintosh/windfarm_lm75_sensor.c 2006-03-03 16:02:56.000000000 +1100
+++ linux-work/drivers/macintosh/windfarm_lm75_sensor.c 2006-03-03 16:41:01.000000000 +1100
@@ -25,9 +25,9 @@
#include "windfarm.h"
-#define VERSION "0.1"
+#define VERSION "0.2"
-#define DEBUG
+#undef DEBUG
#ifdef DEBUG
#define DBG(args...) printk(args)
@@ -113,6 +113,7 @@ static struct wf_lm75_sensor *wf_lm75_cr
const char *loc)
{
struct wf_lm75_sensor *lm;
+ int rc;
DBG("wf_lm75: creating %s device at address 0x%02x\n",
ds1775 ? "ds1775" : "lm75", addr);
@@ -139,9 +140,11 @@ static struct wf_lm75_sensor *wf_lm75_cr
lm->i2c.driver = &wf_lm75_driver;
strncpy(lm->i2c.name, lm->sens.name, I2C_NAME_SIZE-1);
- if (i2c_attach_client(&lm->i2c)) {
- printk(KERN_ERR "windfarm: failed to attach %s %s to i2c\n",
- ds1775 ? "ds1775" : "lm75", lm->i2c.name);
+ rc = i2c_attach_client(&lm->i2c);
+ if (rc) {
+ printk(KERN_ERR "windfarm: failed to attach %s %s to i2c,"
+ " err %d\n", ds1775 ? "ds1775" : "lm75",
+ lm->i2c.name, rc);
goto fail;
}
@@ -175,16 +178,22 @@ static int wf_lm75_attach(struct i2c_ada
(dev = of_get_next_child(busnode, dev)) != NULL;) {
const char *loc =
get_property(dev, "hwsensor-location", NULL);
- u32 *reg = (u32 *)get_property(dev, "reg", NULL);
- DBG(" dev: %s... (loc: %p, reg: %p)\n", dev->name, loc, reg);
- if (loc == NULL || reg == NULL)
+ u8 addr;
+
+ /* We must re-match the adapter in order to properly check
+ * the channel on multibus setups
+ */
+ if (!pmac_i2c_match_adapter(dev, adapter))
+ continue;
+ addr = pmac_i2c_get_dev_addr(dev);
+ if (loc == NULL || addr == 0)
continue;
/* real lm75 */
if (device_is_compatible(dev, "lm75"))
- wf_lm75_create(adapter, *reg, 0, loc);
+ wf_lm75_create(adapter, addr, 0, loc);
/* ds1775 (compatible, better resolution */
else if (device_is_compatible(dev, "ds1775"))
- wf_lm75_create(adapter, *reg, 1, loc);
+ wf_lm75_create(adapter, addr, 1, loc);
}
return 0;
}
@@ -206,6 +215,11 @@ static int wf_lm75_detach(struct i2c_cli
static int __init wf_lm75_sensor_init(void)
{
+ /* Don't register on old machines that use therm_pm72 for now */
+ if (machine_is_compatible("PowerMac7,2") ||
+ machine_is_compatible("PowerMac7,3") ||
+ machine_is_compatible("RackMac3,1"))
+ return -ENODEV;
return i2c_add_driver(&wf_lm75_driver);
}
Index: linux-work/drivers/macintosh/windfarm_max6690_sensor.c
===================================================================
--- linux-work.orig/drivers/macintosh/windfarm_max6690_sensor.c 2006-02-17 14:38:40.000000000 +1100
+++ linux-work/drivers/macintosh/windfarm_max6690_sensor.c 2006-03-03 16:40:05.000000000 +1100
@@ -17,7 +17,7 @@
#include "windfarm.h"
-#define VERSION "0.1"
+#define VERSION "0.2"
/* This currently only exports the external temperature sensor,
since that's all the control loops need. */
@@ -81,7 +81,7 @@ static struct wf_sensor_ops wf_max6690_o
static void wf_max6690_create(struct i2c_adapter *adapter, u8 addr)
{
struct wf_6690_sensor *max;
- char *name = "u4-temp";
+ char *name = "backside-temp";
max = kzalloc(sizeof(struct wf_6690_sensor), GFP_KERNEL);
if (max == NULL) {
@@ -118,7 +118,6 @@ static int wf_max6690_attach(struct i2c_
struct device_node *busnode, *dev = NULL;
struct pmac_i2c_bus *bus;
const char *loc;
- u32 *reg;
bus = pmac_i2c_adapter_to_bus(adapter);
if (bus == NULL)
@@ -126,16 +125,23 @@ static int wf_max6690_attach(struct i2c_
busnode = pmac_i2c_get_bus_node(bus);
while ((dev = of_get_next_child(busnode, dev)) != NULL) {
+ u8 addr;
+
+ /* We must re-match the adapter in order to properly check
+ * the channel on multibus setups
+ */
+ if (!pmac_i2c_match_adapter(dev, adapter))
+ continue;
if (!device_is_compatible(dev, "max6690"))
continue;
+ addr = pmac_i2c_get_dev_addr(dev);
loc = get_property(dev, "hwsensor-location", NULL);
- reg = (u32 *) get_property(dev, "reg", NULL);
- if (!loc || !reg)
+ if (loc == NULL || addr == 0)
continue;
- printk("found max6690, loc=%s reg=%x\n", loc, *reg);
+ printk("found max6690, loc=%s addr=0x%02x\n", loc, addr);
if (strcmp(loc, "BACKSIDE"))
continue;
- wf_max6690_create(adapter, *reg);
+ wf_max6690_create(adapter, addr);
}
return 0;
@@ -153,6 +159,11 @@ static int wf_max6690_detach(struct i2c_
static int __init wf_max6690_sensor_init(void)
{
+ /* Don't register on old machines that use therm_pm72 for now */
+ if (machine_is_compatible("PowerMac7,2") ||
+ machine_is_compatible("PowerMac7,3") ||
+ machine_is_compatible("RackMac3,1"))
+ return -ENODEV;
return i2c_add_driver(&wf_max6690_driver);
}
Index: linux-work/drivers/macintosh/windfarm_pm112.c
===================================================================
--- linux-work.orig/drivers/macintosh/windfarm_pm112.c 2006-02-17 14:38:40.000000000 +1100
+++ linux-work/drivers/macintosh/windfarm_pm112.c 2006-03-03 16:24:44.000000000 +1100
@@ -613,7 +613,7 @@ static void pm112_new_sensor(struct wf_s
} else if (!strcmp(sr->name, "slots-power")) {
if (slots_power == NULL && wf_get_sensor(sr) == 0)
slots_power = sr;
- } else if (!strcmp(sr->name, "u4-temp")) {
+ } else if (!strcmp(sr->name, "backside-temp")) {
if (u4_temp == NULL && wf_get_sensor(sr) == 0)
u4_temp = sr;
} else
Index: linux-work/drivers/macintosh/windfarm_cpufreq_clamp.c
===================================================================
--- linux-work.orig/drivers/macintosh/windfarm_cpufreq_clamp.c 2005-11-09 11:49:03.000000000 +1100
+++ linux-work/drivers/macintosh/windfarm_cpufreq_clamp.c 2006-03-03 16:42:36.000000000 +1100
@@ -8,6 +8,8 @@
#include <linux/wait.h>
#include <linux/cpufreq.h>
+#include <asm/prom.h>
+
#include "windfarm.h"
#define VERSION "0.3"
@@ -74,6 +76,12 @@ static int __init wf_cpufreq_clamp_init(
{
struct wf_control *clamp;
+ /* Don't register on old machines that use therm_pm72 for now */
+ if (machine_is_compatible("PowerMac7,2") ||
+ machine_is_compatible("PowerMac7,3") ||
+ machine_is_compatible("RackMac3,1"))
+ return -ENODEV;
+
clamp = kmalloc(sizeof(struct wf_control), GFP_KERNEL);
if (clamp == NULL)
return -ENOMEM;
Index: linux-work/drivers/macintosh/windfarm_core.c
===================================================================
--- linux-work.orig/drivers/macintosh/windfarm_core.c 2006-02-17 14:38:40.000000000 +1100
+++ linux-work/drivers/macintosh/windfarm_core.c 2006-03-03 16:43:06.000000000 +1100
@@ -35,6 +35,8 @@
#include <linux/platform_device.h>
#include <linux/mutex.h>
+#include <asm/prom.h>
+
#include "windfarm.h"
#define VERSION "0.2"
@@ -465,6 +467,11 @@ static int __init windfarm_core_init(voi
{
DBG("wf: core loaded\n");
+ /* Don't register on old machines that use therm_pm72 for now */
+ if (machine_is_compatible("PowerMac7,2") ||
+ machine_is_compatible("PowerMac7,3") ||
+ machine_is_compatible("RackMac3,1"))
+ return -ENODEV;
platform_device_register(&wf_platform_device);
return 0;
}
^ permalink raw reply
* Re: Linux on PPC
From: David Hawkins @ 2006-03-03 5:10 UTC (permalink / raw)
To: rtos; +Cc: linuxppc-embedded
In-Reply-To: <190edfbd0603021801g5505cab9h8e285fdc7bf476d1@mail.gmail.com>
Hiya,
I'm no expert in this, but here's the basics;
> We have a customized board running on IBM PPC 750. The customer boot
> loader is provided by the vendor. Also, the vendor has provided
> the BSP on vxworks.
The PPC 750 is a fairly old processor, so there will be Linux
support for it. For example, I picked up a couple of Artesyn
PrPMC boards that contain a PPC 750, and this board can run
Linux, though I have not had time to try booting it yet.
If the vendor provided the VxWorks BSP, then hopefully they
also provided you with the physical memory map of the board.
This is what you really need to get another bootloader (eg. U-Boot)
and Linux up-and-running. If the vendor will provide schematics
for the board, that would also help (hey, it never hurts to
ask for them).
> We are planning to use linux on this processor. What are the steps
> involved in booting the board with linux.
> Which linux to be used and what are the procedures involved. I dint come
> across a documents which had these details.
>
> I am new to the linux front. So any help is highly appreciated.
>
Step 1. Get the memory map of the board.
Step 2. Find a PPC 750 port in the Linux source.
For example, in the 2.6 series kernel, the place to start
looking is under arch/ppc/platforms. grep -Ie 750 shows
up some of the PPC 750 based systems.
chestnut.c 750FX/GX evaluation board
katana.c Looks like one too
prpmc750.c Looks like a Motorola board
Look at the comments in the code, look at the memory map
of the reference board versus your custom board. There is
a very good chance that the custom board is based on a
reference design - thats the whole point of them.
Step 3. Build a minimal kernel
Step 4. Boot
Step 5. Purchase a BDI2000 JTAG debugger and use it to figure
out why Step 4 didn't work.
Repeat at Step 3.
When I get time to play with my Artesyn board, I'll go back to
the katana.c file, the grep above had some comments about Artesyn
boards. If it fails to boot, I'll use the BDI2000 to see where it
dies and go from there.
Once you can boot Linux, you might decide that the custom bootloader
on the board is inflexible. The U-Boot bootloader is very nice
and will have support for other 750-based boards, it shouldn't
take too much to port that too. But first, try to get a Linux
kernel booted, even if it has a hard-wired command line.
Also take a look over on the Freescale web site, search for
'porting linux', it'll show up AN2145, AN2222, AN2579, and
a bunch of other application notes. They'll give you an idea
of what it takes to port to a new processor.
> I am new to the linux front. So any help is highly appreciated.
So it depends how much time you have versus how much you
want to spend.
There are also commercial companies that will do the job for you.
If you can come up with the memory map and hardware details of
the board, you could always post a request on this list, and
I am sure there are people reading this list that would
respond. (I'm not one of them though, so I'm not trying to
drum up business ok)
Regards,
Dave
^ permalink raw reply
* Re: Linux on PPC
From: nreddy @ 2006-03-03 5:09 UTC (permalink / raw)
To: rtos; +Cc: linuxppc-embedded
In-Reply-To: <190edfbd0603021801g5505cab9h8e285fdc7bf476d1@mail.gmail.com>
You can easily migrate to linux environment.
1. You can use u-boot as a boot loader.
2. You can choose any standard linux kernel but you may have to do some
R&D on it to port to your board.
Insted you can buy Montavista Linux, so that you can get support also.
And also there are many mailing lists where yo ucan get tremendous help
on linux.
Thanks,
Nagi
> Hi,
>
> We have a customized board running on IBM PPC 750. The customer boot
> loader
> is provided by the vendor.
> Also, the vendor has provided the BSP on vxworks.
>
> We are planning to use linux on this processor. What are the steps
> involved
> in booting the board with linux.
> Which linux to be used and what are the procedures involved. I dint come
> across a documents which had these details.
>
> I am new to the linux front. So any help is highly appreciated.
>
> thanks
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: Unsafe pte_update() in do_page_fault() (4xx and Book-E)
From: Eugene Surovegin @ 2006-03-03 3:55 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Kumar Gala
In-Reply-To: <1141357383.3888.19.camel@localhost.localdomain>
On Fri, Mar 03, 2006 at 02:43:02PM +1100, Benjamin Herrenschmidt wrote:
>
> > If this happens, pte_update() sets _PAGE_HWEXEC bit in just cleared
> > PTE. Sometime later, another page fault happens for this page, but
> > because of that set bit, pte_none() test in handle_pte_fault() fails,
> > and we continue along the wrong path, thinking that this PTE was
> > swapped out to the swap file, and this triggers swap_dup error I
> > mentioned at the beginning.
>
> Can we preempt at that point ? As tehre is no SMP 4xx that I know of
> preempt would be the only cause for such a race ...
Yes, as I mentioned in the original post, I'm running preempt enabled
kernel.
--
Eugene
^ permalink raw reply
* Re: Unsafe pte_update() in do_page_fault() (4xx and Book-E)
From: Benjamin Herrenschmidt @ 2006-03-03 3:43 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-dev, Kumar Gala
In-Reply-To: <20060302202634.GA14387@gate.ebshome.net>
> If this happens, pte_update() sets _PAGE_HWEXEC bit in just cleared
> PTE. Sometime later, another page fault happens for this page, but
> because of that set bit, pte_none() test in handle_pte_fault() fails,
> and we continue along the wrong path, thinking that this PTE was
> swapped out to the swap file, and this triggers swap_dup error I
> mentioned at the beginning.
Can we preempt at that point ? As tehre is no SMP 4xx that I know of
preempt would be the only cause for such a race ...
Ben.
^ permalink raw reply
* Re: Linux on PPC
From: Frank @ 2006-03-03 2:23 UTC (permalink / raw)
To: rtos, linuxppc-embedded
In-Reply-To: <190edfbd0603021801g5505cab9h8e285fdc7bf476d1@mail.gmail.com>
--- rtosrtososrtosgmaigmail> wrote:
> Hi,
>
> We have a customized board running on IBM PPC PPC. The
> customer boot loader
> is provided by the vendor.
> Also, the vendor has provided the BSP BSPvxwovxworks
> We are planning to use linulinuxthis processor. What are the
> steps involved
> in booting the board with linulinux Which linulinuxbe used and
what are the procedures involved. I
> dint come
> across a documents which had these details.
>
> I am new to the linulinuxnt. So any help is highly
> appreciated.
>
> thanks
I recommend using u-boot and the ELDK from denx.de
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Linux on PPC
From: rtos @ 2006-03-03 2:01 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 472 bytes --]
Hi,
We have a customized board running on IBM PPC 750. The customer boot loader
is provided by the vendor.
Also, the vendor has provided the BSP on vxworks.
We are planning to use linux on this processor. What are the steps involved
in booting the board with linux.
Which linux to be used and what are the procedures involved. I dint come
across a documents which had these details.
I am new to the linux front. So any help is highly appreciated.
thanks
[-- Attachment #2: Type: text/html, Size: 615 bytes --]
^ permalink raw reply
* [PATCH] macintosh: tidy-up driver_register() return values
From: Bjorn Helgaas @ 2006-03-02 23:18 UTC (permalink / raw)
To: Paul Mackerras, Benjamin Herrenschmidt; +Cc: Andrew Morton, linuxppc-dev
Remove the assumption that driver_register() returns the number of
devices bound to the driver. In fact, it returns zero for success
or a negative error value.
All callers of macio_register_driver() either ignore the return value
or return it as the return value of a module_init() function.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Index: work-mm4/drivers/macintosh/macio_asic.c
===================================================================
--- work-mm4.orig/drivers/macintosh/macio_asic.c 2006-03-01 15:37:15.000000000 -0700
+++ work-mm4/drivers/macintosh/macio_asic.c 2006-03-02 12:57:05.000000000 -0700
@@ -550,15 +550,12 @@
*/
int macio_register_driver(struct macio_driver *drv)
{
- int count = 0;
-
/* initialize common driver fields */
drv->driver.name = drv->name;
drv->driver.bus = &macio_bus_type;
/* register with core */
- count = driver_register(&drv->driver);
- return count ? count : 1;
+ return driver_register(&drv->driver);
}
/**
^ permalink raw reply
* Re: incorrect rmo_top handling in prom_init
From: Benjamin Herrenschmidt @ 2006-03-02 23:35 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20060302185509.GA14235@suse.de>
On Thu, 2006-03-02 at 19:55 +0100, Olaf Hering wrote:
> My iBook1 has 2 memory regions in reg. Depending on how I boot it
> (vmlinux+initrd) or zImage.initrd, it will not boot with current Linus
> tree.
> rmo_top should be 160MB instead of 32MB.
Does that fix it ?
Index: linux-work/arch/powerpc/kernel/prom_init.c
===================================================================
--- linux-work.orig/arch/powerpc/kernel/prom_init.c 2006-03-01 11:48:27.000000000 +1100
+++ linux-work/arch/powerpc/kernel/prom_init.c 2006-03-03 10:34:30.000000000 +1100
@@ -978,7 +978,7 @@
if (size == 0)
continue;
prom_debug(" %x %x\n", base, size);
- if (base == 0)
+ if (base == 0 && (RELOC(of_platform) & PLATFORM_LPAR))
RELOC(rmo_top) = size;
if ((base + size) > RELOC(ram_top))
RELOC(ram_top) = base + size;
^ permalink raw reply
* [PATCH] powerpc: tidy-up of_register_driver()/driver_register() return values
From: Bjorn Helgaas @ 2006-03-02 23:16 UTC (permalink / raw)
To: Paul Mackerras, Benjamin Herrenschmidt; +Cc: Andrew Morton, linuxppc-dev
Remove the assumption that driver_register() returns the number of
devices bound to the driver. In fact, it returns zero for success
or a negative error value.
Nobody uses the return value of of_register_driver() anyway.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Index: work-mm4/arch/powerpc/kernel/of_device.c
===================================================================
--- work-mm4.orig/arch/powerpc/kernel/of_device.c 2006-03-01 15:37:13.000000000 -0700
+++ work-mm4/arch/powerpc/kernel/of_device.c 2006-03-02 10:46:58.000000000 -0700
@@ -147,15 +147,12 @@
int of_register_driver(struct of_platform_driver *drv)
{
- int count = 0;
-
/* initialize common driver fields */
drv->driver.name = drv->name;
drv->driver.bus = &of_platform_bus_type;
/* register with core */
- count = driver_register(&drv->driver);
- return count ? count : 1;
+ return driver_register(&drv->driver);
}
void of_unregister_driver(struct of_platform_driver *drv)
Index: work-mm4/drivers/macintosh/smu.c
===================================================================
--- work-mm4.orig/drivers/macintosh/smu.c 2006-03-01 15:37:41.000000000 -0700
+++ work-mm4/drivers/macintosh/smu.c 2006-03-02 10:47:30.000000000 -0700
@@ -630,8 +630,6 @@
static int __init smu_init_sysfs(void)
{
- int rc;
-
/*
* Due to sysfs bogosity, a sysdev is not a real device, so
* we should in fact create both if we want sysdev semantics
@@ -640,7 +638,7 @@
* I'm a bit too far from figuring out how that works with those
* new chipsets, but that will come back and bite us
*/
- rc = of_register_driver(&smu_of_platform_driver);
+ of_register_driver(&smu_of_platform_driver);
return 0;
}
^ permalink raw reply
* Unsafe pte_update() in do_page_fault() (4xx and Book-E)
From: Eugene Surovegin @ 2006-03-02 20:26 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Kumar Gala
Hi!
For the last couple of days I was debugging rare
swap_dup: Bad swap file entry 0x00000080
errors in my custom 2.4 kernel running on 405GPr system.
My current theory is that this error is caused by the special lazy
dcache/icache flush handling on 4xx and BookE. Because this code in my
2.4 was actually a backport from 2.6, I think we have a problem in
current 2.6 as well.
Here is what I think happens. On 4xx/BookE we use execute bit to
deffer dcache to icache flush, in do_page_fault() we flush page when
execute trap triggers and enable _PAGE_HWEXEC bit in PTE.
Unfortunately, we don't lock this PTE and it's possible that after
pte_present() check but _before_ pte_update() call this particular
page was purged from the memory, e.g. because of extreme memory
pressure (of course, I'm assuming enabled preempt).
If this happens, pte_update() sets _PAGE_HWEXEC bit in just cleared
PTE. Sometime later, another page fault happens for this page, but
because of that set bit, pte_none() test in handle_pte_fault() fails,
and we continue along the wrong path, thinking that this PTE was
swapped out to the swap file, and this triggers swap_dup error I
mentioned at the beginning.
_PAGE_HWXEC is 0x200 on 405GPr, and because swap entry is PTE shifted
2 bits to the right, we get that "0x00000080" value.
Paul, does my theory make any sense? I cannot test 2.6 on our hw. So
far, after I added additional page_table_lock locking to my 2.4 in
do_page_fault(), I haven't seen these errors, but it's too early to be
100% sure :).
I'll make a patch for 2.6 if you think my analysis is correct.
--
Eugene
^ permalink raw reply
* incorrect rmo_top handling in prom_init
From: Olaf Hering @ 2006-03-02 18:55 UTC (permalink / raw)
To: linuxppc-dev
My iBook1 has 2 memory regions in reg. Depending on how I boot it
(vmlinux+initrd) or zImage.initrd, it will not boot with current Linus
tree.
rmo_top should be 160MB instead of 32MB.
0 > dev /memory .properties
name memory
device_type memory
reg 00000000 02000000
02000000 08000000
slot-names 00000003
DIMM0/BUILT-IN
DIMM1/J12
available 00003000 09bfd000
dimm-info 8000040c 08040000 00000000 00000000 0000bc00 00000000 000000be 00bdbf00
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
8008040c 0a014000 01a08000 80080001 8f040601 01000fa0 60000014 14143220
20102010 00000000 00000000 00000000 00000000 00000000 00000000 00001237
7fd50000 00000000 01373634 56313641 33445434 44444700 00000001 00519900
00000001 01020105 09030701 02020000 00000000 00000000 00000000 000064c7
dimm-types SDRAM
SDRAM
dimm-speeds
PC100-222S
ok
0 > boot enet:1.1.1.3,yaboot
CLIENT: 000a27aa0f20 1.1.1.1
SERVER: 0003938574cc 1.1.1.3
Transfer FILE: yaboot \
TFTP-actual=406ff TFTP-adler32=e64fd05f load-size=406ff adler32=e64fd05f
Loading ELF
yaboot starting: loaded at 0x00200000-0x00235ed8 (0x0/0x200000/0xff80a290;sp: 0x0023eb14)
CLIENT: 000a27aa0f20 1.1.1.1
SERVER: 0003938574cc 1.1.1.3
Transfer FILE: yaboot.conf
TFTP-actual=333 TFTP-adler32=1af6149c Config file 'yaboot.conf' read, 819 bytes
fooo xxx yaboot.conf
Welcome to yaboot version 1.3.13.SuSE
booted from '/pci@f4000000/ethernet:1.1.1.3,yaboot'
Enter "help" to get some basic usage information
boot: i
Please wait, loading kernel...
CLIENT: 000a27aa0f20 1.1.1.1
SERVER: 0003938574cc 1.1.1.3
Transfer FILE: inst32
TFTP-actual=798ffb TFTP-adler32=aaf3b8f5 Allocated 0x00900000 bytes for executable @ 0x00400000
Elf32 kernel loaded...
SuSE Linux zImage starting: loaded at 0x00400000-0x00b93cbc (0x1000000/0x0/0xff80a290; sp: 0x0023e9a4)
uncompressing ELF header done. (0x00000100 bytes)
Allocated 0x0078dfb0 bytes for kernel @ 0x02000000
Allocated 0x005aacd6 bytes for initrd @ 0x0278e000
uncompressing kernel done. (0x00431788 bytes)
entering kernel at 0x02010000(278e000/5aacd6/ff80a290)
OF stdout device is: /packages/telnet
initrd_start=0x0278e000
initrd_end=0x02d38cd6
command line:
root_addr_cells: 00000001
root_size_cells: 00000001
scanning memory:
node /memory@0 :
00000000 02000000
02000000 08000000
memory layout at init:
memory_limit : 00000000 (16 MB aligned)
alloc_bottom : 02d39000
alloc_top : 02000000
alloc_top_hi : 0a000000
rmo_top : 02000000
ram_top : 0a000000
Booting CPU hw index = 0x00000000
copying OF device tree ...
foo
starting device tree allocs at 02d39000
alloc_up(00100000, 00001000)
Can't allocate initial device-tree chunk
DEFAULT CATCH!, code=900 at %SRR0: 024017a4 %SRR1: 00083030
ok
0 >
^ permalink raw reply
* Re: How to quickly write cleanmarkers to jffs2 partitions?
From: Jaap-Jan Boor @ 2006-03-02 17:07 UTC (permalink / raw)
To: David Jander; +Cc: linuxppc-embedded@ozlabs.org
In-Reply-To: <200603021706.14618.david.jander@protonic.nl>
Hi David,
I indeed did write a small program that only writes the cleanmarkers
in all flash blocks used for jffs2. We assume (and check) all flash
sectors
are erased already.
Jaap-Jan
On 2-mrt-2006, at 17:06, David Jander wrote:
>
> Hi,
>
> I was wondering if there is a trick or common technique I am
> ignoring to make
> this more efficient:
>
> This is for a 2.4 kernel based system.
> In production we use either u-boot or a NFS mounted linux system to
> erase
> flash and write jffs2 partitions to it. The jffs2 images are small
> (not
> padded to full partition size to save programming time), but the
> partitions
> are rather big (12 Mbyte in one case). Problem is that when booting
> for the
> first time, one has to wait several minutes (during which the
> system is more
> or less useless and busy) to get all cleanmarkers written to flash
> by the
> jffs2 gc thread. This huge delay is rather unacceptable for
> production, so we
> are looking for a work-around.
>
> One option would be to make jffs2 images that are padded to full
> partition
> size, but that also isn't very efficient, considering the image is
> only about
> 100k in beginning and the partition is 12 Mbyte in size. That would
> take a
> lot of time programming flash (less time than having the jffs2
> driver fix
> this nevertheless).
>
> Another option is making a little program that writes cleanmarkers
> in every
> eraseblock starting from the first completely empty one in a
> partition before
> mounting that partition for the very first time after flashing.
>
> Since this seems to me like a common situation, I'd like to know if
> anybody
> knows about a better solution, or if anybody has already dealt with
> this
> before.
>
> Greetings,
>
> --
> David Jander
> Protonic Holland.
> tel.: +31 (0) 229 212928
> fax.: +31 (0) 229 210930
> Factorij 36 / 1689 AL Zwaag
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
> --
> This message has been scanned for viruses and is believed to be clean
>
____
J.G.J. Boor Anton Philipsweg 1
Software Engineer 1223 KZ Hilversum
AimSys bv tel. +31 35 689 1941
Postbus 2194, 1200 CD Hilversum jjboor at aimsys dot nl
^ permalink raw reply
* How to quickly write cleanmarkers to jffs2 partitions?
From: David Jander @ 2006-03-02 16:06 UTC (permalink / raw)
To: linuxppc-embedded@ozlabs.org
Hi,
I was wondering if there is a trick or common technique I am ignoring to make
this more efficient:
This is for a 2.4 kernel based system.
In production we use either u-boot or a NFS mounted linux system to erase
flash and write jffs2 partitions to it. The jffs2 images are small (not
padded to full partition size to save programming time), but the partitions
are rather big (12 Mbyte in one case). Problem is that when booting for the
first time, one has to wait several minutes (during which the system is more
or less useless and busy) to get all cleanmarkers written to flash by the
jffs2 gc thread. This huge delay is rather unacceptable for production, so we
are looking for a work-around.
One option would be to make jffs2 images that are padded to full partition
size, but that also isn't very efficient, considering the image is only about
100k in beginning and the partition is 12 Mbyte in size. That would take a
lot of time programming flash (less time than having the jffs2 driver fix
this nevertheless).
Another option is making a little program that writes cleanmarkers in every
eraseblock starting from the first completely empty one in a partition before
mounting that partition for the very first time after flashing.
Since this seems to me like a common situation, I'd like to know if anybody
knows about a better solution, or if anybody has already dealt with this
before.
Greetings,
--
David Jander
Protonic Holland.
tel.: +31 (0) 229 212928
fax.: +31 (0) 229 210930
Factorij 36 / 1689 AL Zwaag
^ permalink raw reply
* Re: [Fastboot] Re: Kexec for booke PPC processors
From: Kumar Gala @ 2006-03-02 15:26 UTC (permalink / raw)
To: dagriego; +Cc: Michael Ellerman, linuxppc-dev, fastboot
In-Reply-To: <3d42041d0603020632o2d75bd7ao99c7b006042a88d9@mail.gmail.com>
On Mar 2, 2006, at 8:32 AM, dagriego wrote:
> I'm working on the E500 core, particularly the mpc8540/8560ADS boards
> - David
There are patches to u-boot that have been posted to allow mpc8540
ADS to boot with a flat device tree (needed by kexec). In addition
the powerpc.git tree has support in arch/powerpc for building a
kernel that uses that flat device tree for mpc8540 ads.
I'd recommend you start with getting that going on your system.
- kumar
^ permalink raw reply
* Re: [Fastboot] Re: Kexec for booke PPC processors
From: dagriego @ 2006-03-02 14:32 UTC (permalink / raw)
To: Kumar Gala; +Cc: Michael Ellerman, linuxppc-dev, fastboot
In-Reply-To: <Pine.LNX.4.44.0603011746320.10931-100000@gate.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 703 bytes --]
I'm working on the E500 core, particularly the mpc8540/8560ADS boards
- David
On 3/1/06, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> > On Thu, 2 Mar 2006 09:43, dagriego wrote:
> > > I'm finishing my first pass on getting kexec to work on PPC booke
> > > processor, and needed some insight into how to pass information from
> the
> > > first kernel to the kexec'ed kernel. This information is the board
> > > information that the first kernel is given in r3 from the board
> firmware.
> > > Is there a standard convention for passing this information?
> >
> > Yep, it's called the flat device tree.
>
> Which PPC booke are you trying to get this to work on?
>
> - kumar
>
>
[-- Attachment #2: Type: text/html, Size: 1034 bytes --]
^ permalink raw reply
* Wolfgang's updates
From: Tony @ 2006-03-02 13:20 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 178 bytes --]
Dear Mr.WolfGang,
Can u do me a favor,I need U_boot 1.1.4, I am trying to download it from internet,but I am failed! I am very appreciate your help!thx!
your Tony
[-- Attachment #2: Type: text/html, Size: 718 bytes --]
^ permalink raw reply
* 802.3ah OAM
From: feng @ 2006-03-02 7:08 UTC (permalink / raw)
To: linuxppc-embedded@ozlabs.org
DQpISTsNCiAgDQogICAgICAgd2hvIGhhcyA4MDIuM2FoIE9BTSAgY29kZSAoQyBsYW5ndWFnZSAg
aW4gdGhlIGxpbnV4KSAgPz8/Pw0KDQogICAgICAgVGhhbmtzISEhIQ0KDQoNCg0KoaGhoaGhoaGh
oaGhoaGhoWZlbmcNCqGhoaGhoaGhoaGhoaGhoaFjaGluYWZlbmcyMDA4QDE2My5jb20NCqGhoaGh
oaGhoaGhoaGhoaGhoaGhMjAwNi0wMy0wMg0K
^ permalink raw reply
* Re: boot failure on lite5200b board
From: John Rigby @ 2006-03-02 0:52 UTC (permalink / raw)
To: #LI JIANGGAN#; +Cc: linuxppc-embedded
In-Reply-To: <84A109BF918D934CB46ACF33BCE187C002D54D94@mail02.student.main.ntu.edu.sg>
SGVyZSBpcyBhIHVib290IHNldHVwIHRoYXQgd29ya3Mgd2l0aCBhIGZyZWVzY2FsZSBrZXJuZWw6
CmJvb3RkZWxheT01CmJhdWRyYXRlPTExNTIwMApwcmVib290PWVjaG87ZWNobyBUeXBlICJydW4g
Zmxhc2hfbmZzIiB0byBtb3VudCByb290IGZpbGVzeXN0ZW0gb3ZlciBORlM7ZWNobwphdXRvbG9h
ZD1ubwpldGhhY3Q9RkVDIEVUSEVSTkVUCnJhbWFyZ3M9c2V0ZW52IGJvb3RhcmdzIHJvb3Q9L2Rl
di9yYW0gcncKamZmczJhcmdzPXNldGVudiBib290YXJncyByb290PS9kZXYvbXRkYmxvY2swIHJ3
IHJvb3Rmc3R5cGU9amZmczIKYWRkaXA9c2V0ZW52IGJvb3RhcmdzICQoYm9vdGFyZ3MpCmlwPSQo
aXBhZGRyKTokKHNlcnZlcmlwKTokKGdhdGV3YXlpcCk6JChuZXRtYXNrKTokKGhvc3RuYW1lKTok
KG5ldGRldik6b2ZmCnBhbmljPTEKZmxhc2hfbmZzPXJ1biBuZnNhcmdzIGFkZGlwO2Jvb3RtICQo
a2VybmVsX2FkZHIpCmZsYXNoX3NlbGY9cnVuIHJhbWFyZ3MgYWRkaXA7Ym9vdG0gJChrZXJuZWxf
YWRkcikgJChyYW1kaXNrX2FkZHIpCmZsYXNoX2pmZnMyPXJ1biBqZmZzMmFyZ3M7Ym9vdG0gJChr
ZXJuZWxfYWRkcikKbmV0X25mcz10ZnRwIDIwMDAwMCAkKGJvb3RmaWxlKTtydW4gbmZzYXJncyBh
ZGRpcDtib290bQpuZXRkZXY9ZXRoMApldGhhZGRyPTAwOjA0OjlmOjIyOjMzOjQ0CmJvb3RmaWxl
PS90ZnRwYm9vdC91SW1hZ2UKa2VybmVsX2FkZHI9ZmZkMDAwMDAKcm9vdHBhdGg9L3RmdHBib290
L2x0aWIKZmlsZXNpemU9YzlkNzAwCmZpbGVhZGRyPTEwMDAwMDAKZ2F0ZXdheWlwPTE3Mi4yNy4y
NTUuMjU0Cm5ldG1hc2s9MjU1LjI1NS4wLjAKaXBhZGRyPTE3Mi4yNy4xNTIuOTkKc2VydmVyaXA9
MTcyLjI3LjE1Mi41CmJvb3RjbWQ9cnVuIG5ldF9uZnMKbmZzYXJncz1zZXRlbnYgYm9vdGFyZ3Mg
Y29uc29sZT10dHlTMCwxMTUyMDAgcm9vdD0vZGV2L25mcyBydwpuZnNyb290PSQoc2VydmVyaXAp
OiQocm9vdHBhdGgpCnN0ZGluPXNlcmlhbApzdGRvdXQ9c2VyaWFsCnN0ZGVycj1zZXJpYWwKCkNo
YW5nZSBpcCBpbmZvLCBib290ZmlsZSwgcm9vdHBhdGggZXRjIHRvIGZpdCB5b3UgY29uZmlnLgpJ
ZiB5b3Ugd2FudCBpdCB0byB3b3JrIHdpdGggU3lsdmFpbidzIGtlcm5lbCB0aGVuIHlvdSBuZWVk
IHRvIGNoYW5nZQp0dHlTMCB0byB0dHlQU0MwLgoKQWxzbyBhZGQgYSBwcmludGVudiBqdXN0IGJl
Zm9yZSB0aGUgYm9vdG0gc28geW91IGNhbiB2ZXJpZnkgdGhhdCB5b3VyCmJvb3RhcmdzIHJlYWxs
eSBhcmUgZ2V0dGluZyBzZXQgY29ycmVjdGx5LgoKT24gMy8xLzA2LCAjTEkgSklBTkdHQU4jIDxs
aWppYW5nZ2FuQHBtYWlsLm50dS5lZHUuc2c+IHdyb3RlOgo+Cj4KPiBob3cgYWJvdXQgdGhlIGZv
bGxvd2luZyBVLWJvb3Qgc2V0dGluZ3M6Cj4KPiAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4KPgo+Cj4gSGl0IGFueSBrZXkgdG8gc3RvcCBhdXRvYm9vdDogIDAKPiA9PiBwcmludGVudgo+
IGJhdWRyYXRlPTExNTIwMAo+IGF1dG9sb2FkPW5vCj4gZXRoYWN0PUZFQyBFVEhFUk5FVAo+IGV0
aGFkZHI9MDA6MDE6OUY6MDA6Mjc6MkYKPiBwcmVib290PWVjaG87IGVjaG8gQXV0b3N0YXJ0aW5n
LiBQcmVzcyBhbnkga2V5IHRvIGFib3J0Li47IGVjaG8KPiBib290ZGVsYXk9NQo+IGhvc3RuYW1l
PWljZWN1YmUKPiBib290ZmlsZT1NUEM1MjAwL3VJbWFnZQo+IG52PW5mc3Jvb3Qgcm9vdD0vZGV2
L25mcyBydyBuZnNyb290PTEwLjE5MC4zLjExMzovb3B0L2VsZGsvcm9vdGZzCj4gbmV0bWFzaz0y
NTUuMjU1LjI0MC4wCj4gaXBhZGRyPTEwLjE5MC4zLjE0NAo+IHNlcnZlcmlwPTEwLjE5MC4zLjEw
Mwo+IGJvb3RjbWQ9cnVuIG5ldF9uZnMKPgo+IHJvb3Rmcz1yb290PS9kZXYvbmZzIHJ3Cj4gbmV0
ZGV2PWV0aDAKPiByb290cGF0aD0vb3B0L2VsZGstNC0wL3Jvb3Rmcwo+IG5mc2FyZ3M9c2V0ZW52
IGJvb3RhcmdzIHJvb3Q9L2Rldi9uZnMgcncKPiBuZnNyb290PTEwLjE5MC4zLjEwMzovb3B0L2Vs
ZGstNC0wL3Jvb3Rmcwo+Cj4gcmFtYXJncz1zZXRlbnYgYm9vdGFyZ3Mgcm9vdD0vZGV2L3JhbSBy
dwo+IGFkZGlwPXNldGVudiBib290YXJncwo+IGlwPTEwLjE5MC4zLjE0NDoxMC4xOTAuMy4xMDM6
MTAuMTkwLjMuMTAzOjI1NS4yNTUuMjQwLjA6aWNlY3ViZTpldGgwOm9mZgo+IHBhbmljPTEKPiBu
ZXRfbmZzPXRmdHAgMjAwMDAwIE1QQzUyMDAvdUltYWdlO3J1biBuZnNhcmdzIGFkZGlwO2Jvb3Rt
Cj4KPiBzdGRpbj1zZXJpYWwKPiBzdGRvdXQ9c2VyaWFsCj4gc3RkZXJyPXNlcmlhbAo+Cj4gRW52
aXJvbm1lbnQgc2l6ZTogNzM4LzY1NTMyIGJ5dGVzCj4gPT4gICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIC4KPiAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLgo+Cj4KPgo+IFRo
ZSBvdXRwdXQgaXMgc3RpbGwgdGhlIHNhbWUsIGl0IGhhbmdzIGFmdGVyIGRpc3BsYXlpbmcgYXJj
aDpleGl0Cj4KPiBJIGhhdmUgYWxzbyB0cmllZCB0aGUgYWJvdmUgc2V0dGluZ3Mgd2l0aCBjb25z
b2xlIHNldCwgaXQgZ2l2ZXMgdGhlIHNhbWUKPiBvdXRwdXQKPgo+IEkgYW0gcmVhbGx5IHdvbmRl
cmluZyB3aGV0aGVyIHRoZSBwcm9ibGVtIGlzIHdpdGggdGhlIGtlcm5lbC4gU3lsdmFpbidzCj4g
a2VybmVsIHVJbWFnZSBpcyBvbmx5IGFyb3VuZCA2MDBrIHdoaWxlIHRoZSBvbmUgZnJvbSBmcmVl
c2NhbGUgaXMgMS40TSwKPiBhbnlib2R5IGtub3dzIHdoZXJlIHRoZSBkaWZmZXJlbmNlIGlzPwo+
Cj4gLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLgo+Cj4gQXV0b3N0YXJ0aW5n
LiBQcmVzcyBhbnkga2V5IHRvIGFib3J0Li4KPgo+IEhpdCBhbnkga2V5IHRvIHN0b3AgYXV0b2Jv
b3Q6ICAwCj4gVXNpbmcgRkVDIEVUSEVSTkVUIGRldmljZQo+IFRGVFAgZnJvbSBzZXJ2ZXIgMTAu
MTkwLjMuMTAzOyBvdXIgSVAgYWRkcmVzcyBpcyAxMC4xOTAuMy4xNDQKPiBGaWxlbmFtZSAnTVBD
NTIwMC91SW1hZ2UnLgo+IExvYWQgYWRkcmVzczogMHgyMDAwMDAKPgo+IExvYWRpbmc6Cj4gIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMKPgo+ICMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjCj4KPiAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwo+Cj4gIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMKPiAgICAgICAgICAj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwo+IGRvbmUKPiBCeXRlcyB0cmFuc2Zl
cnJlZCA9IDE1MTAxNDMgKDE3MGFmZiBoZXgpCj4gIyMgQm9vdGluZyBpbWFnZSBhdCAwMDIwMDAw
MCAuLi4KPgo+ICAgIEltYWdlIE5hbWU6ICAgTGludXgtMi42LjExLjcKPiAgICBJbWFnZSBUeXBl
OiAgIFBvd2VyUEMgTGludXggS2VybmVsIEltYWdlIChnemlwIGNvbXByZXNzZWQpCj4gICAgRGF0
YSBTaXplOiAgICAxNTEwMDc5IEJ5dGVzID0gIDEuNCBNQgo+ICAgIExvYWQgQWRkcmVzczogMDAw
MDAwMDAKPiAgICBFbnRyeSBQb2ludDogIDAwMDAwMDAwCj4gICAgVmVyaWZ5aW5nIENoZWNrc3Vt
IC4uLiBPSwo+ICAgIFVuY29tcHJlc3NpbmcgS2VybmVsIEltYWdlIC4uLiBPSwo+IGlkIG1hY2go
KTogZG9uZQo+IE1NVTplbnRlcgo+IE1NVTpodyBpbml0Cj4gTU1VOm1hcGluCj4gTU1VOnNldGlv
Cj4gTU1VOmV4aXQKPiBzZXR1cF9hcmNoOiBlbnRlcgo+IHNldHVwX2FyY2g6IGJvb3RtZW0KPiBv
Y3A6IGV4aXQKPiBhcmNoOiBleGl0Cj4KPgo+Cj4KPgo+IC4uLi4uLi4uLi4uLi4uLi4uLi4uLgo+
Cj4gUmVnYXJkcywKPgo+IEppYW5nZ2FuIExJCj4KPiAgX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18KPgo+IEZyb206IEpvaG4gUmlnYnkgW21haWx0bzpqY3JpZ2J5QGdtYWlsLmNvbV0K
PiBTZW50OiBTYXQgMi8yNS8yMDA2IDE6MTcKPiBUbzogI0xJIEpJQU5HR0FOIwo+IENjOiB0bnRA
MjQ2dG50LmNvbTsgbGludXhwcGMtZW1iZWRkZWRAb3psYWJzLm9yZwo+Cj4gU3ViamVjdDogUmU6
IGJvb3QgZmFpbHVyZSBvbiBsaXRlNTIwMGIgYm9hcmQKPgo+Cj4KPgo+IEkgZG9uJ3QgdGhpbmsg
eW91ciBzeW50YXggZm9yIGFwcGVuZGluZyB0byBhbiBlbnYgdmFyaWFibGUgaXMgY29ycmVjdDoK
Pgo+IHRyeToKPiBzZXQgYm9vdGFyZ3MgJChib290YXJncykgLi4uYXBwZW5kZWQgc3R1ZmYuLi4K
PiBpbnN0ZWFkIG9mOgo+IHNldCBib290YXJncyBlbnYgYm9vdGFyZ3MgLi4uYXBwZW5kZWQgc3R1
ZmYuLi4uCj4KPiBBbHNvIHRvIHNlZSB3aGF0IGJvb3RhcmdzIGlzIGFjdHVhbGx5IHNldCB0byBh
ZnRlciBhbGwgdGhlIG5lc3RlZAo+IGNvbW1hbmRzLCBhZGQgYSBwcmludGVudiBqdXN0IGJlZm9y
ZSB0aGUgYm9vdG0KPgo+IE9uIDIvMjMvMDYsICNMSSBKSUFOR0dBTiMgPGxpamlhbmdnYW5AcG1h
aWwubnR1LmVkdS5zZz4gd3JvdGU6Cj4gPgo+ID4KPiA+IEkgaGF2ZSBhY3R1YWxseSB0cmllZCBi
b3RoIGtlcm5lbCB3aXRoIGJvdGggY29uc29sZSBjb25maWd1cmF0aW9ucy4gSXQKPiBnYXZlCj4g
PiB0aGUgc2FtZSBvdXRwdXQsIHRodXMgSSBwcmVzdW1lIHRoYXQgdGhlIHByb2JsZW0gbGllcyBz
b21ld2hlcmUgZWxzZS4gSQo+ID4gYXR0YWNoZWQgdGhlIGxvZyB0byB0aGlzIGVtYWlsLgo+ID4K
PiA+ICB0aGUgYm9hcmQgaXMgTGl0ZTUyMDBCIFZlcnNpb24gMS4wLiBXaGljaCAuY29uZmlnIGZp
bGUgZG8geW91IHdhbnQ/Cj4gPgo+ID4gIFN5bHZhaW4sIHdlIGhhdmUgb3JkZXJlZCBhIGRlYnVn
Z2luZyBzZXQgYnV0IHdlIGFyZSBzdGlsbCB3YWl0aW5nIGZvcgo+ID4gZGVsaXZlcnksIHRoZSBs
ZWFraW5nIHRpbWUgaXMgc2FpZCB0byBiZSBvbmUgbW9udGgsIHRhbnQgcGlzLiBBbmQgdGhlIGxv
Zwo+IEkKPiA+IGF0dGFjaGVkIGhlcmUgYXJlIGJvb3RpbmcgZnJvbSBhIGhpZ2hlciBhZGRyZXNz
ICgweDUwMDAwMCkuCj4gPgo+ID4gIE15IGN1cnJlbnQgdS1ib290IGFyZ3M6Cj4gPiAgQXV0b3N0
YXJ0aW5nLiBQcmVzcyBhbnkga2V5IHRvIGFib3J0Li4KPiA+Cj4gPiAgSGl0IGFueSBrZXkgdG8g
c3RvcCBhdXRvYm9vdDogIDAKPiA+ICA9PiBwcmludGVudgo+ID4gIGJhdWRyYXRlPTExNTIwMAo+
ID4gIGF1dG9sb2FkPW5vCj4gPiAgZXRoYWN0PUZFQyBFVEhFUk5FVAo+ID4gIGZsc2hyb290PXJv
b3Q9L2Rldi9tdGRibG9jazIgcncKPiA+ICBldGhhZGRyPTAwOjAxOjlGOjAwOjI3OjJGCj4gPiAg
cHJlYm9vdD1lY2hvOyBlY2hvIEF1dG9zdGFydGluZy4gUHJlc3MgYW55IGtleSB0byBhYm9ydC4u
OyBlY2hvCj4gPiAgYm9vdGRlbGF5PTUKPiA+ICBob3N0bmFtZT1pY2VjdWJlCj4gPiAgYm9vdGZp
bGU9TVBDNTIwMC91SW1hZ2UKPiA+ICBudj1uZnNyb290IHJvb3Q9L2Rldi9uZnMgcncgbmZzcm9v
dD0xMC4xOTAuMy4xMTM6L29wdC9lbGRrL3Jvb3Rmcwo+ID4gIGlwPWlwPTEwLjE5MC4zLjE0NDox
MC4xOTAuMy4xMDM6MTAuMTkwLjMuMTAzOjI1NS4yNTUuMjQwLjA6aWNlY3ViZTo6b2ZmCj4gPiAg
bmZzcm9vdD1yb290PS9kZXYvbmZzIHJ3Cj4gbmZzcm9vdD0xMC4xOTAuMy4xMDM6L29wdC9lbGRr
LTQtMC9yb290ZnMKPiA+ICBib290Y21kPXJ1biBuZXRfbmZzCj4gPiAgZmlsZXNpemU9NTQ2Cj4g
PiAgZmlsZWFkZHI9NTAwMDAwCj4gPiAgbmV0bWFzaz0yNTUuMjU1LjI0MC4wCj4gPiAgaXBhZGRy
PTEwLjE5MC4zLjE0NAo+ID4gIHNlcnZlcmlwPTEwLjE5MC4zLjEwMwo+ID4gIHNldGNvbnNvbGU9
c2V0ZW52IGJvb3RhcmdzIGNvbnNvbGU9dHR5UFNDMCwgMTE1MjAwbjggY29uc29sZT10dHkxCj4g
PiAgcm9vdGZzPXJvb3Q9L2Rldi9uZnMgcncKPiBuZnNyb290PTEwLjE5MC4zLjEwMzovb3B0L2Vs
ZGstNC0wL3Jvb3Rmcwo+ID4gIGJvb3RhcmdzPWVudiBib290YXJncyByb290PS9kZXYvbmZzIHJ3
Cj4gPiBuZnNyb290PTEwLjE5MC4zLjEwMzovb3B0L2VsZGstNC0wL3Jvb3Rmcwo+ID4gaXA9MTAu
MTkwLjMuMTQ0OjEwLjE5MC4zLjEwMzoxMC4xOTAuMy4xMDM6MjU1LjI1NS4yNDAuMDppY2VjdWJl
OjpvZmYKPiA+ICBmbGFzaF9uZnM9cnVuIHNldGNvbnNvbGUgbmZzYXJncyBhZGRpcDtib290bQo+
ID4gIG5ldF9uZnM9dGZ0cCA1MDAwMDAgTVBDNTIwMC91SW1hZ2U7cnVuIHNldGNvbnNvbGUgbmZz
YXJncyBhZGRpcDtib290bQo+ID4gIG5mc2FyZ3M9c2V0ZW52IGJvb3RhcmdzIGVudiBib290YXJn
cyByb290PS9kZXYvbmZzIHJ3Cj4gPiBuZnNyb290PTEwLjE5MC4zLjEwMzovb3B0L2VsZGstNC0w
L3Jvb3Rmcwo+ID4KPiBpcD0xMC4xOTAuMy4xNDQ6MTAuMTkwLjMuMTAzOjEwLjE5MC4zLjEwMzoy
NTUuMjU1LjI0MC4wOmljZWN1YmU6Om9mZnJvb3Q9L2Rldi9uZnMKPiA+IHJ3Cj4gPiAgYWRkaXA9
c2V0ZW52IGJvb3RhcmdzIGVudiBib290YXJncyByb290PS9kZXYvbmZzIHJ3Cj4gPiBuZnNyb290
PTEwLjE5MC4zLjEwMzovb3B0L2VsZGstNC0wL3Jvb3Rmcwo+ID4gaXA9MTAuMTkwLjMuMTQ0OjEw
LjE5MC4zLjEwMzoxMC4xOTAuMy4xMDM6MjU1LjI1NS4yNDAuMDppY2VjdWJlOjpvZmYKPiA+ICBy
YW1hcmdzPXNldGVudiBib290YXJncyByb290PS9kZXYvcmFtIHJ3Cj4gPiAgY29uc29sZT1jb25z
b2xlPXR0eVMwLDExNTIwMG44IGNvbnNvbGU9dHR5MQo+ID4gIHN0ZGluPXNlcmlhbAo+ID4gIHN0
ZG91dD1zZXJpYWwKPiA+ICBzdGRlcnI9c2VyaWFsCj4gPgo+ID4gIEVudmlyb25tZW50IHNpemU6
IDE0NzIvNjU1MzIgYnl0ZXMKPiA+ICA9Pgo+ID4KPiA+Cj4gPgo+ID4KPiA+ICBVU0lORyBTeWx2
YWluJ3MgS0VSTkVMOgo+ID4KPiA+ICBVLUJvb3QgMS4xLjMgKEZlYiAgNiAyMDA2IC0gMDk6NTY6
NDYpCj4gPgo+ID4gIENQVTogICBNUEM1MjAwIHYyLjIgYXQgNDYyIE1Iego+ID4gICAgICAgICBC
dXMgMTMyIE1IeiwgSVBCIDEzMiBNSHosIFBDSSAzMyBNSHoKPiA+ICBCb2FyZDogRnJlZXNjYWxl
IE1QQzUyMDAgKExpdGU1MjAwQikKPiA+ICBJMkM6ICAgODUga0h6LCByZWFkeQo+ID4gIERSQU06
ICAyNTYgTUIKPiA+ICBGTEFTSDogMzIgTUIKPiA+ICBQQ0k6ICAgQnVzIERldiBWZW5JZCBEZXZJ
ZCBDbGFzcyBJbnQKPiA+ICAgICAgICAgIDAwICAxYSAgMTA1NyAgNTgwOSAgMDY4MCAgMDAKPiA+
ICBJbjogICAgc2VyaWFsCj4gPiAgT3V0OiAgIHNlcmlhbAo+ID4gIEVycjogICBzZXJpYWwKPiA+
ICBOZXQ6ICAgRkVDIEVUSEVSTkVUCj4gPiAgSURFOiAgIEJ1cyAwOiBPSwo+ID4gICAgRGV2aWNl
IDA6IG5vdCBhdmFpbGFibGUKPiA+ICAgIERldmljZSAxOiBub3QgYXZhaWxhYmxlCj4gPgo+ID4g
IEF1dG9zdGFydGluZy4gUHJlc3MgYW55IGtleSB0byBhYm9ydC4uCj4gPgo+ID4gIEhpdCBhbnkg
a2V5IHRvIHN0b3AgYXV0b2Jvb3Q6ICAwCj4gPiAgVXNpbmcgRkVDIEVUSEVSTkVUIGRldmljZQo+
ID4gIFRGVFAgZnJvbSBzZXJ2ZXIgMTAuMTkwLjMuMTAzOyBvdXIgSVAgYWRkcmVzcyBpcyAxMC4x
OTAuMy4xNDQKPiA+ICBGaWxlbmFtZSAnTVBDNTIwMC91SW1hZ2UnLgo+ID4gIExvYWQgYWRkcmVz
czogMHg1MDAwMDAKPiA+ICBMb2FkaW5nOgo+ICMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjCj4gPgo+ICMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMKPiA+ICBk
b25lCj4gPiAgQnl0ZXMgdHJhbnNmZXJyZWQgPSA2NTgxMTQgKGEwYWMyIGhleCkKPiA+ICAjIyBC
b290aW5nIGltYWdlIGF0IDAwNTAwMDAwIC4uLgo+ID4gICAgIEltYWdlIE5hbWU6ICAgTGludXgt
Mi42LjE2LXJjMQo+ID4gICAgIEltYWdlIFR5cGU6ICAgUG93ZXJQQyBMaW51eCBLZXJuZWwgSW1h
Z2UgKGd6aXAgY29tcHJlc3NlZCkKPiA+ICAgICBEYXRhIFNpemU6ICAgIDY1ODA1MCBCeXRlcyA9
IDY0Mi42IGtCCj4gPiAgICAgTG9hZCBBZGRyZXNzOiAwMDAwMDAwMAo+ID4gICAgIEVudHJ5IFBv
aW50OiAgMDAwMDAwMDAKPiA+ICAgICBWZXJpZnlpbmcgQ2hlY2tzdW0gLi4uIE9LCj4gPiAgICAg
VW5jb21wcmVzc2luZyBLZXJuZWwgSW1hZ2UgLi4uIE9LCj4gPiAgaWQgbWFjaCgpOiBkb25lCj4g
PiAgTU1VOmVudGVyCj4gPiAgTU1VOmh3IGluaXQKPiA+ICBNTVU6bWFwaW4KPiA+ICBNTVU6c2V0
aW8KPiA+ICBNTVU6ZXhpdAo+ID4gIHNldHVwX2FyY2g6IGVudGVyCj4gPiAgc2V0dXBfYXJjaDog
Ym9vdG1lbQo+ID4gIGFyY2g6IGV4aXQKPiA+Cj4gPgo+ID4KPiA+ICBVU0lORyBLRVJORUwgRlJP
TSBGcmVlc2NhbGU6Cj4gPgo+ID4gIFUtQm9vdCAxLjEuMyAoRmViICA2IDIwMDYgLSAwOTo1Njo0
NikKPiA+Cj4gPiAgQ1BVOiAgIE1QQzUyMDAgdjIuMiBhdCA0NjIgTUh6Cj4gPiAgICAgICAgIEJ1
cyAxMzIgTUh6LCBJUEIgMTMyIE1IeiwgUENJIDMzIE1Iego+ID4gIEJvYXJkOiBGcmVlc2NhbGUg
TVBDNTIwMCAoTGl0ZTUyMDBCKQo+ID4gIEkyQzogICA4NSBrSHosIHJlYWR5Cj4gPiAgRFJBTTog
IDI1NiBNQgo+ID4gIEZMQVNIOiAzMiBNQgo+ID4gIFBDSTogICBCdXMgRGV2IFZlbklkIERldklk
IENsYXNzIEludAo+ID4gICAgICAgICAgMDAgIDFhICAxMDU3ICA1ODA5ICAwNjgwICAwMAo+ID4g
IEluOiAgICBzZXJpYWwKPiA+ICBPdXQ6ICAgc2VyaWFsCj4gPiAgRXJyOiAgIHNlcmlhbAo+ID4g
IE5ldDogICBGRUMgRVRIRVJORVQKPiA+ICBJREU6ICAgQnVzIDA6IE9LCj4gPiAgICBEZXZpY2Ug
MDogbm90IGF2YWlsYWJsZQo+ID4gICAgRGV2aWNlIDE6IG5vdCBhdmFpbGFibGUKPiA+Cj4gPiAg
QXV0b3N0YXJ0aW5nLiBQcmVzcyBhbnkga2V5IHRvIGFib3J0Li4KPiA+Cj4gPiAgSGl0IGFueSBr
ZXkgdG8gc3RvcCBhdXRvYm9vdDogIDAKPiA+ICBVc2luZyBGRUMgRVRIRVJORVQgZGV2aWNlCj4g
PiAgVEZUUCBmcm9tIHNlcnZlciAxMC4xOTAuMy4xMDM7IG91ciBJUCBhZGRyZXNzIGlzIDEwLjE5
MC4zLjE0NAo+ID4gIEZpbGVuYW1lICdNUEM1MjAwL3VJbWFnZScuCj4gPiAgTG9hZCBhZGRyZXNz
OiAweDUwMDAwMAo+ID4gIExvYWRpbmc6Cj4gIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMKPiA+Cj4gIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMKPiA+Cj4g
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMKPiA+Cj4gIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMKPiA+ICAgICAgICAgICAjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIwo+ID4gIGRvbmUKPiA+ICBCeXRlcyB0cmFuc2ZlcnJlZCA9IDE1MTAx
NDMgKDE3MGFmZiBoZXgpCj4gPiAgIyMgQm9vdGluZyBpbWFnZSBhdCAwMDUwMDAwMCAuLi4KPiA+
ICAgICBJbWFnZSBOYW1lOiAgIExpbnV4LTIuNi4xMS43Cj4gPiAgICAgSW1hZ2UgVHlwZTogICBQ
b3dlclBDIExpbnV4IEtlcm5lbCBJbWFnZSAoZ3ppcCBjb21wcmVzc2VkKQo+ID4gICAgIERhdGEg
U2l6ZTogICAgMTUxMDA3OSBCeXRlcyA9ICAxLjQgTUIKPiA+ICAgICBMb2FkIEFkZHJlc3M6IDAw
MDAwMDAwCj4gPiAgICAgRW50cnkgUG9pbnQ6ICAwMDAwMDAwMAo+ID4gICAgIFZlcmlmeWluZyBD
aGVja3N1bSAuLi4gT0sKPiA+ICAgICBVbmNvbXByZXNzaW5nIEtlcm5lbCBJbWFnZSAuLi4gT0sK
PiA+ICBpZCBtYWNoKCk6IGRvbmUKPiA+ICBNTVU6ZW50ZXIKPiA+ICBNTVU6aHcgaW5pdAo+ID4g
IE1NVTptYXBpbgo+ID4gIE1NVTpzZXRpbwo+ID4gIE1NVTpleGl0Cj4gPiAgc2V0dXBfYXJjaDog
ZW50ZXIKPiA+ICBzZXR1cF9hcmNoOiBib290bWVtCj4gPiAgb2NwOiBleGl0Cj4gPiAgYXJjaDog
ZXhpdAo+ID4KPiA+Cj4gPgo+ID4KPiA+ICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+ID4g
IEZyb206IEpvaG4gUmlnYnkgW21haWx0bzpqY3JpZ2J5QGdtYWlsLmNvbV0KPiA+ICBTZW50OiBG
cmkgMi8yNC8yMDA2IDA6MTgKPiA+ICBUbzogI0xJIEpJQU5HR0FOIwo+ID4gIFN1YmplY3Q6IFJl
OiBib290IGZhaWx1cmUgb24gbGl0ZTUyMDBiIGJvYXJkCj4gPgo+ID4gIElmIHlvdSBhcmUgdXNp
bmcgU3lsdmFpbidzIGtlcm5lbCB5b3UgbmVlZCB0byBzZXQgY29uc29sZT10dHlQU0MwLiAgSWYK
PiB5b3UKPiA+IGFyZQo+ID4gIHVzaW5nIGEga2VybmVsIGZyb20gRnJlZXNjYWxlIHRoZW4geW91
IG5lZWQgdG8gc2V0IGNvbnNvbGU9dHR5UzAuCj4gPgo+ID4gIEFsc28gd2hhdCByZXYgb2YgdGhl
IGJvYXJkIGRvIHlvdSBoYXZlPwo+ID4KPiA+Cj4gPgo+ID4gIE9uIDIvMjMvMDYsICNMSSBKSUFO
R0dBTiMgPGxpamlhbmdnYW5AcG1haWwubnR1LmVkdS5zZz4gd3JvdGU6Cj4gPiAgPgo+ID4gID4K
PiA+ICA+IFRoYW5rIHlvdSBKb3Pvv70gTWFy77+9YSBhbmQgQW5kcmV5IGZvciB5b3VyIGFkdmlj
ZXMsIGhvd2V2ZXIgdGhlIHByb2JsZW0KPgo+ID4gID4gcmVtYWlucy4gSSd2ZSB0cmllZCBzZXR0
aW5nIHRoZSBjb25zb2xlICh0aG91Z2ggSSByZW1lbWJlciB0aGF0IG91cgo+ID4gcHJldmlvdXMK
PiA+ICA+IGxpdGU1MjAwIGJvYXJkIHdhcyB3b3JraW5nIGZpbmUgb24ga2VybmVsIDIuNCB3aXRo
b3V0IHNldHRpbmcgdGhlCj4gPiBjb25zb2xlKTsKPiA+ICA+IG1lYW50aW1lLCBJJ3ZlIHNldCB0
aGUgYm9vdGluZyBpbWFnZSB0byAweDUwMDAwMDsgSSBoYXZlIGFsc28gdHJpZWQKPiB1c2luZwo+
ID4gID4gdGhlIGtlcm5lbCBpbWFnZSBjb21lIHRvZ2V0aGVyIHdpdGggdGhlIEJTUCwgaXQncyBh
bHdheXMgdGhlIHNhbWUKPiBlcnJvci4KPiA+ICA+Cj4gPiAgPiAgU3lsdmFpbiwgSSd2ZSBhY3R1
YWxseSB1c2luZyB5b3VyIGtlcm5lbCBzb3VyY2UsIHRoZSBjb21waWxlZCBpbWFnZSBpcwo+ID4g
ID4gYXJvdW5kIDcwMGsgKGNvbXBhcmVkIHRvIHRoZSAxLjRNIGltYWdlIGZyb20gdGhlIEJTUCks
IGJ1dCBpdCBkb2Vzbid0Cj4gPiBzb2x2ZQo+ID4gID4gdGhlIHByb2JsZW0uIFNvIEkgcHJlc3Vt
ZSB0aGF0IHRoZSBwcm9ibGVtIGlzIGx5aW5nIHNvbWV3aGVyZSBlbHNlLgo+ID4gID4KPiA+ICA+
ICBBIFNOQVBTSE9UIE9GIFRIRSBCT09USU5HIE1FU1NBR0VTOgo+ID4gID4KPiA+ICA+Cj4gPiAg
PiAgVS1Cb290IDEuMS4zIChGZWIgIDYgMjAwNiAtIDA5OjU2OjQ2KQo+ID4gID4KPiA+ICA+ICBD
UFU6ICAgTVBDNTIwMCB2Mi4yIGF0IDQ2MiBNSHoKPiA+ICA+ICAgICAgICAgQnVzIDEzMiBNSHos
IElQQiAxMzIgTUh6LCBQQ0kgMzMgTUh6Cj4gPiAgPiAgQm9hcmQ6IEZyZWVzY2FsZSBNUEM1MjAw
IChMaXRlNTIwMEIpCj4gPiAgPiAgSTJDOiAgIDg1IGtIeiwgcmVhZHkKPiA+ICA+ICBEUkFNOiAg
MjU2IE1CCj4gPiAgPiAgRkxBU0g6IDMyIE1CCj4gPiAgPiAgUENJOiAgIEJ1cyBEZXYgVmVuSWQg
RGV2SWQgQ2xhc3MgSW50Cj4gPiAgPiAgICAgICAgICAwMCAgMWEgIDEwNTcgIDU4MDkgIDA2ODAg
IDAwCj4gPiAgPiAgSW46ICAgIHNlcmlhbAo+ID4gID4gIE91dDogICBzZXJpYWwKPiA+ICA+ICBF
cnI6ICAgc2VyaWFsCj4gPiAgPiAgTmV0OiAgIEZFQyBFVEhFUk5FVAo+ID4gID4gIElERTogICBC
dXMgMDogT0sKPiA+ICA+ICAgIERldmljZSAwOiBub3QgYXZhaWxhYmxlCj4gPiAgPiAgICBEZXZp
Y2UgMTogbm90IGF2YWlsYWJsZQo+ID4gID4KPiA+ICA+ICBBdXRvc3RhcnRpbmcuIFByZXNzIGFu
eSBrZXkgdG8gYWJvcnQuLgo+ID4gID4KPiA+ICA+ICBIaXQgYW55IGtleSB0byBzdG9wIGF1dG9i
b290OiAgMAo+ID4gID4gIFVzaW5nIEZFQyBFVEhFUk5FVCBkZXZpY2UKPiA+ICA+ICBURlRQIGZy
b20gc2VydmVyIDEwLjE5MC4zLjEwMzsgb3VyIElQIGFkZHJlc3MgaXMgMTAuMTkwLjMuMTQ0Cj4g
PiAgPiAgRmlsZW5hbWUgJ01QQzUyMDAvdUltYWdlJy4KPiA+ICA+ICBMb2FkIGFkZHJlc3M6IDB4
MTAwMDAwCj4gPiAgPiAgTG9hZGluZzoKPiA+ICA+Cj4gIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMKPiA+ICA+Cj4gPiAgPgo+
ICMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMKPiA+ICA+ICBkb25lCj4gPiAgPiAgQnl0ZXMgdHJhbnNmZXJyZWQgPSA2NTgxMTQg
KGEwYWMyIGhleCkKPiA+ICA+ICAjIyBCb290aW5nIGltYWdlIGF0IDAwMTAwMDAwIC4uLgo+ID4g
ID4gICAgIEltYWdlIE5hbWU6ICAgTGludXgtMi42LjE2LXJjMQo+ID4gID4gICAgIEltYWdlIFR5
cGU6ICAgUG93ZXJQQyBMaW51eCBLZXJuZWwgSW1hZ2UgKGd6aXAgY29tcHJlc3NlZCkKPiA+ICA+
ICAgICBEYXRhIFNpemU6ICAgIDY1ODA1MCBCeXRlcyA9IDY0Mi42IGtCCj4gPiAgPiAgICAgTG9h
ZCBBZGRyZXNzOiAwMDAwMDAwMAo+ID4gID4gICAgIEVudHJ5IFBvaW50OiAgMDAwMDAwMDAKPiA+
ICA+ICAgICBWZXJpZnlpbmcgQ2hlY2tzdW0gLi4uIE9LCj4gPiAgPiAgICAgVW5jb21wcmVzc2lu
ZyBLZXJuZWwgSW1hZ2UgLi4uIE9LCj4gPiAgPiAgaWQgbWFjaCgpOiBkb25lCj4gPiAgPiAgTU1V
OmVudGVyCj4gPiAgPiAgTU1VOmh3IGluaXQKPiA+ICA+ICBNTVU6bWFwaW4KPiA+ICA+ICBNTVU6
c2V0aW8KPiA+ICA+ICBNTVU6ZXhpdAo+ID4gID4gIHNldHVwX2FyY2g6IGVudGVyCj4gPiAgPiAg
c2V0dXBfYXJjaDogYm9vdG1lbQo+ID4gID4gIGFyY2g6IGV4aXQKPiA+ICA+Cj4gPiAgPgo+ID4g
ID4gIEkgYW0gd29uZGVyaW5nIHdoZXRoZXIgaXQncyBhIGtlcm5lbCBwcm9ibGVtIG9yIG1vcmUg
bGlrZWx5IHRvIGJlIGEKPiA+IHByb2JsZW0KPiA+ICA+IGx5aW5nIHdpdGggdGhlIFUtYm9vdC4g
SXQgc2VlbXMgdG8gaGFuZyB3aGVuIGV4ZWN1dGluZyBzZXR1cF9hcmNoKCkKPiA+ICA+IGZ1bmN0
aW9uLCBvciBtYXliZSB0aGVyZSBpcyBzdGggZWxzZSBiZWhpbmQgdGhlIHdhbGw/Cj4gPiAgPgo+
ID4gID4gIFJlZ2FyZHMsCj4gPiAgPiAgSmlhbmdnYW4gTEkKPiA+ICA+Cj4gPiAgPgo+ID4gID4K
PiA+ICA+Cj4gPiAgPiAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KPiA+ICA+ICBGcm9tOiBT
eWx2YWluIE11bmF1dCBbbWFpbHRvOnRudEAyNDZ0TnQuY29tXQo+ID4gID4gIFNlbnQ6IFRodSAy
LzIzLzIwMDYgMTU6MzgKPiA+ICA+ICBUbzogI0xJIEpJQU5HR0FOIwo+ID4gID4gIENjOiBsaW51
eHBwYy1lbWJlZGRlZEBvemxhYnMub3JnCj4gPiAgPiAgU3ViamVjdDogUmU6IGJvb3QgZmFpbHVy
ZSBvbiBsaXRlNTIwMGIgYm9hcmQKPiA+ICA+Cj4gPiAgPiAgI0xJIEpJQU5HR0FOIyB3cm90ZToK
PiA+ICA+ICA+IEhlbGxvIGFsbCwKPiA+ICA+ICA+Cj4gPiAgPiAgPiBGb3IgbXkgZW5kLW9mLXN0
dWR5IHByb2plY3QsIEkgYW0gd29ya2luZyBvbiBhbiBlbWJlZGRlZCBzeXN0ZW0gd2l0aAo+ID4g
ID4gID4gcmVmZXJlbmNlIG9mIGZyZWVzY2FsZSdzIGxpdGU1MjAwYiByZWZlcmVuY2UgYm9hcmQu
IEkgd2FzIHRyeWluZyB0bwo+ID4gYm9vdAo+ID4gID4gID4gTGludXggMi42LjE1IG9uIHRoZSBi
b2FyZCAod2l0aCB0aGUgZmVjIGFuZCBiZXN0Y29tbSBjb3JyZWN0ZWQpLgo+ID4gaG93ZXZlcgo+
ID4gID4gID4gdGhlIGJvb3Rpbmcgd2FzIHN0dWNrIGF0IHRoZSBmb2xsb3dpbmcgc3RhZ2U6Cj4g
PiAgPgo+ID4gID4gIEluIGFkZGl0aW9uIHRvIHdoYXQgaGFzIGFscmVhZHkgYmVlbiBzYWlkICh1
c2UgYSBoaWdoZXIgYWRkcmVzcyBmb3IKPiB0aGUKPiA+ICA+ICBpbWFnZSBhbmQgZG9uJ3QgZm9y
Z2V0IGNvbnNvbGU9dHR5UFNDMCBpbiBrZXJuZWwgY29tbWFuZCBsaW5lKSwgbWFrZQo+ID4gID4g
IHN1cmUgeW91IHVzZSB0aGUga2VybmVsIGZyb20gbXkgZ2l0IHRyZWUsIGl0IGNvbnRhaW5zIGEg
ZmV3IHBhdGNoZXMKPiBmcm9tCj4gPiAgPiAgSm9obiBSaWdieSB0byBhZGQgc3VwcG9ydCBmb3Ig
dGhlIGxpdGU1MjAwYi4KPiA+ICA+Cj4gPiAgPiAgUGxlYXNlIHJlcG9ydCBpZiBpdCB3b3Jrcywg
SSd2ZSBub3QgYmVlbiBhYmxlIHRvIHRlc3QgdGhvc2UgbXlzZWxmCj4gc2luY2UKPiA+ICA+ICBp
J20gc3RpbGwgb24gbGl0ZTUyMDAuCj4gPiAgPgo+ID4gID4KPiA+ICA+ICAgICAgICAgIFN5bHZh
aW4KPiA+ICA+Cj4gPiAgPgo+ID4gID4KPiA+ICA+Cj4gPiAgPgo+ID4gID4KPiA+ICA+IF9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gPiAgPiBMaW51eHBw
Yy1lbWJlZGRlZCBtYWlsaW5nIGxpc3QKPiA+ICA+IExpbnV4cHBjLWVtYmVkZGVkQG96bGFicy5v
cmcKPiA+ICA+IGh0dHBzOi8vb3psYWJzLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4cHBjLWVt
YmVkZGVkCj4gPiAgPgo+ID4gID4KPiA+Cj4gPgo+ID4KPiA+Cj4gPgo+Cj4KPgo=
^ permalink raw reply
* Re: [PPC,SOUND] Fix audio gpio state detection
From: Benjamin Herrenschmidt @ 2006-03-02 0:04 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, alsa-devel, Ben Collins
In-Reply-To: <20060302000019.GB6792@suse.de>
On Thu, 2006-03-02 at 01:00 +0100, Olaf Hering wrote:
> On Wed, Mar 01, Ben Collins wrote:
>
> > I'm rediffing now. However, I may not include my tumbler changes
> > immediately. For some reason, those are the ones causing problems. I
> > need to review the diff and see if I can find the problem (which I
> > cannot reproduce).
>
> Can you make individual patches, each one fixing one thing, going from A
> to B. You know that hch song...
In that case, it's difficult as it's more like a rewrite of the GPIO
handling from scratch (well... almost)
Ben.
^ permalink raw reply
* Re: [PPC,SOUND] Fix audio gpio state detection
From: Benjamin Herrenschmidt @ 2006-03-02 0:04 UTC (permalink / raw)
To: Ben Collins; +Cc: linuxppc-dev, alsa-devel, Ben Collins, Olaf Hering
In-Reply-To: <1141256965.4378.145.camel@grayson>
On Wed, 2006-03-01 at 18:49 -0500, Ben Collins wrote:
> On Thu, 2006-03-02 at 10:09 +1100, Benjamin Herrenschmidt wrote:
> > > > This (sort of) breaks PowerMac3,4 (69 (PowerMac G4 Silver)). I have to
> > > > force it on up to now, but with this patch the internal speaker will not
> > > > work with or without my patch to force it on.
> > >
> > > But the patch fixes also my PowerBook4,1, I dont have to toggle the headphone
> > > once to get the built-in speakers enabled.
> > > Looks like 2.6.16 stuff, but its been broken for so long now...
> >
> > What is the status of Ben's latest stuff ?
>
> I'm rediffing now. However, I may not include my tumbler changes
> immediately. For some reason, those are the ones causing problems. I
> need to review the diff and see if I can find the problem (which I
> cannot reproduce).
>
> The toonie stuff is great. Been working really well for all the folks
> I've heard from, and for me on my PowerBook5,9.
There is an issue with some models where asserting both mutes will reset
the codec, so you have to be careful with that. Then, there is the
old-style GPIOs where you can read the polarity from the device-tree and
the new style ones...
I _think_ apple uses the GPIO platform functions only on machines that
have "include-k2-support" property in macio too, so maybe you are trying
to use them on earlier machines and they are bogus...
Send me the complete patch and I'll see if I spot something. Olaf, can
you give me quick summary of the machines that have problems with Ben's
code ?
Ben.
^ 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