* No subject
@ 2014-09-13 19:40 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2014-09-13 19:40 UTC (permalink / raw)
To: ath9k-devel
It doesn't appear to be present in the kernel and I don't think
ath3k would be loaded.
I have a patch to add this ID to ath3k, can you apply it in
backports-20141221 and check ?
http://msujith.org/dir/patches/wl/Jan-14-2015/0013-ath3k-Add-new-AR3012-device.patch
Inside backports:
patch -p1 < 0013-ath3k-Add-new-AR3012-device.patch
And then, do a "make menuconfig" to select ath9k/ath3k
and install.
Sujith
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2020-11-25 10:16 Manuel Reis
0 siblings, 0 replies; 732+ messages in thread
From: Manuel Reis @ 2020-11-25 10:16 UTC (permalink / raw)
To: u-boot
Hi,
thanks for feedback.
sending new squash commit with grouped variables and code, and
corrected git message for initial patch sent:
[PATCH] added check for ignored CONFIG_ENV_EXT4_DEVICE_AND_PART
hope this is better now.
regards,
manuel
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2020-05-08 9:43 Patrick Wildt
0 siblings, 0 replies; 732+ messages in thread
From: Patrick Wildt @ 2020-05-08 9:43 UTC (permalink / raw)
To: u-boot
Bcc:
Subject: Re: [PATCH 2/3] mksunxi_fit_atf.sh: Update FIT component descriptions
Reply-To:
In-Reply-To: <20200507232035.31892-2-samuel@sholland.org>
Hi,
now this really confuses me.
commit 0db0ba6141f402b1d496ef53d9fa69978f75ec61 has explicitly made
u-boot the firmware and moved atf into the loadables on NXP i.MX.
Here you do the complete opposite for sunxi.
Can people please make up their minds how it is *supposed* to work?
Oh, and your previous diff about the "minimal os parsing", I need that
too for my use-case, so I like that one!
Patrick
On Thu, May 07, 2020 at 06:20:34PM -0500, Samuel Holland wrote:
> Since commit d879616e9e64 ("spl: fit: simplify logic for FDT loading for
> non-OS boots"), the SPL looks at the "os" properties of FIT images to
> determine where to append the FDT.
>
> The "os" property of the "firmware" image also determines how to execute
> the next stage of the boot process, as in 1d3790905d9c ("spl: atf:
> introduce spl_invoke_atf and make bl31_entry private").
>
> To support this additional functionality, and to properly model the boot
> process, where ATF runs before U-Boot, add the "os" properties and swap
> the firmware/loadable images in the FIT image.
>
> Signed-off-by: Samuel Holland <samuel@sholland.org>
> ---
> board/sunxi/mksunxi_fit_atf.sh | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/board/sunxi/mksunxi_fit_atf.sh b/board/sunxi/mksunxi_fit_atf.sh
> index 88ad719747..4dfd22db78 100755
> --- a/board/sunxi/mksunxi_fit_atf.sh
> +++ b/board/sunxi/mksunxi_fit_atf.sh
> @@ -31,6 +31,7 @@ cat << __HEADER_EOF
> description = "U-Boot (64-bit)";
> data = /incbin/("u-boot-nodtb.bin");
> type = "standalone";
> + os = "u-boot";
> arch = "arm64";
> compression = "none";
> load = <0x4a000000>;
> @@ -39,6 +40,7 @@ cat << __HEADER_EOF
> description = "ARM Trusted Firmware";
> data = /incbin/("$BL31");
> type = "firmware";
> + os = "arm-trusted-firmware";
> arch = "arm64";
> compression = "none";
> load = <$BL31_ADDR>;
> @@ -73,8 +75,8 @@ do
> cat << __CONF_SECTION_EOF
> config_$cnt {
> description = "$(basename $dtname .dtb)";
> - firmware = "uboot";
> - loadables = "atf";
> + firmware = "atf";
> + loadables = "uboot";
> fdt = "fdt_$cnt";
> };
> __CONF_SECTION_EOF
> --
> 2.24.1
>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
2019-03-22 15:30 ` Keith Busch
@ 2019-03-25 15:44 ` Felipe Franciosi
0 siblings, 0 replies; 732+ messages in thread
From: Felipe Franciosi @ 2019-03-25 15:44 UTC (permalink / raw)
Hi Keith,
> On Mar 22, 2019,@3:30 PM, Keith Busch <kbusch@kernel.org> wrote:
>
> On Fri, Mar 22, 2019@07:54:50AM +0000, Felipe Franciosi wrote:
>>>
>>> Note though that SPDK doesn't support sharing the device between host and the
>>> guests, it takes over the nvme device, thus it makes the kernel nvme driver
>>> unbind from it.
>>
>> That is absolutely true. However, I find it not to be a problem in practice.
>>
>> Hypervisor products, specially those caring about performance, efficiency and fairness, will dedicate NVMe devices for a particular purpose (eg. vDisk storage, cache, metadata) and will not share these devices for other use cases. That's because these products want to deterministically control the performance aspects of the device, which you just cannot do if you are sharing the device with a subsystem you do not control.
>
> I don't know, it sounds like you've traded kernel syscalls for IPC,
> and I don't think one performs better than the other.
Sorry, I'm not sure I understand. My point is that if you are packaging a distro to be a hypervisor and you want to use a storage device for VM data, you _most likely_ won't be using that device for anything else. To that end, driving the device directly from your application definitely gives you more deterministic control.
>
>> For scenarios where the device must be shared and such fine grained control is not required, it looks like using the kernel driver with io_uring offers very good performance with flexibility.
>
> NVMe's IO Determinism features provide fine grained control for shared
> devices. It's still uncommon to find hardware supporting that, though.
Sure, but then your hypervisor needs to certify devices that support that. This will limit your HCL. Moreover, unless the feature is solid, well-established and works reliably on all devices you support, it's arguably preferable to have an architecture which gives you that control in software.
Cheers,
Felipe
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
2019-03-22 7:54 ` Felipe Franciosi
2019-03-22 10:32 ` Maxim Levitsky
@ 2019-03-22 15:30 ` Keith Busch
2019-03-25 15:44 ` Felipe Franciosi
1 sibling, 1 reply; 732+ messages in thread
From: Keith Busch @ 2019-03-22 15:30 UTC (permalink / raw)
On Fri, Mar 22, 2019@07:54:50AM +0000, Felipe Franciosi wrote:
> >
> > Note though that SPDK doesn't support sharing the device between host and the
> > guests, it takes over the nvme device, thus it makes the kernel nvme driver
> > unbind from it.
>
> That is absolutely true. However, I find it not to be a problem in practice.
>
> Hypervisor products, specially those caring about performance, efficiency and fairness, will dedicate NVMe devices for a particular purpose (eg. vDisk storage, cache, metadata) and will not share these devices for other use cases. That's because these products want to deterministically control the performance aspects of the device, which you just cannot do if you are sharing the device with a subsystem you do not control.
I don't know, it sounds like you've traded kernel syscalls for IPC,
and I don't think one performs better than the other.
> For scenarios where the device must be shared and such fine grained control is not required, it looks like using the kernel driver with io_uring offers very good performance with flexibility.
NVMe's IO Determinism features provide fine grained control for shared
devices. It's still uncommon to find hardware supporting that, though.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
2019-03-22 7:54 ` Felipe Franciosi
@ 2019-03-22 10:32 ` Maxim Levitsky
2019-03-22 15:30 ` Keith Busch
1 sibling, 0 replies; 732+ messages in thread
From: Maxim Levitsky @ 2019-03-22 10:32 UTC (permalink / raw)
On Fri, 2019-03-22@07:54 +0000, Felipe Franciosi wrote:
> > On Mar 21, 2019,@5:04 PM, Maxim Levitsky <mlevitsk@redhat.com> wrote:
> >
> > On Thu, 2019-03-21@16:41 +0000, Felipe Franciosi wrote:
> > > > On Mar 21, 2019,@4:21 PM, Keith Busch <kbusch@kernel.org> wrote:
> > > >
> > > > On Thu, Mar 21, 2019@04:12:39PM +0000, Stefan Hajnoczi wrote:
> > > > > mdev-nvme seems like a duplication of SPDK. The performance is not
> > > > > better and the features are more limited, so why focus on this
> > > > > approach?
> > > > >
> > > > > One argument might be that the kernel NVMe subsystem wants to offer
> > > > > this
> > > > > functionality and loading the kernel module is more convenient than
> > > > > managing SPDK to some users.
> > > > >
> > > > > Thoughts?
> > > >
> > > > Doesn't SPDK bind a controller to a single process? mdev binds to
> > > > namespaces (or their partitions), so you could have many mdev's assigned
> > > > to many VMs accessing a single controller.
> > >
> > > Yes, it binds to a single process which can drive the datapath of multiple
> > > virtual controllers for multiple VMs (similar to what you described for
> > > mdev).
> > > You can therefore efficiently poll multiple VM submission queues (and
> > > multiple
> > > device completion queues) from a single physical CPU.
> > >
> > > The same could be done in the kernel, but the code gets complicated as you
> > > add
> > > more functionality to it. As this is a direct interface with an untrusted
> > > front-end (the guest), it's also arguably safer to do in userspace.
> > >
> > > Worth noting: you can eventually have a single physical core polling all
> > > sorts
> > > of virtual devices (eg. virtual storage or network controllers) very
> > > efficiently. And this is quite configurable, too. In the interest of
> > > fairness,
> > > performance or efficiency, you can choose to dynamically add or remove
> > > queues
> > > to the poll thread or spawn more threads and redistribute the work.
> > >
> > > F.
> >
> > Note though that SPDK doesn't support sharing the device between host and
> > the
> > guests, it takes over the nvme device, thus it makes the kernel nvme driver
> > unbind from it.
>
> That is absolutely true. However, I find it not to be a problem in practice.
>
> Hypervisor products, specially those caring about performance, efficiency and
> fairness, will dedicate NVMe devices for a particular purpose (eg. vDisk
> storage, cache, metadata) and will not share these devices for other use
> cases. That's because these products want to deterministically control the
> performance aspects of the device, which you just cannot do if you are sharing
> the device with a subsystem you do not control.
>
> For scenarios where the device must be shared and such fine grained control is
> not required, it looks like using the kernel driver with io_uring offers very
> good performance with flexibility
I see the host/guest parition in the following way:
The guest assigned partitions are for guests that need lowest possible latency,
and in between these guests it is possible to guarantee good enough level of
fairness in my driver.
For example, in the current implementation of my driver, each guest gets its own
host submission queue.
On the other hand, the host assigned partitions are for significantly higher
latency IO, with no guarantees, and/or for guests that need all the more
advanced features of full IO virtualization, for instance snapshots, thin
provisioning, replication/backup over network, etc.
io_uring can be used here to speed things up but it won't reach the nvme-mdev
levels of latency.
Furthermore on NVME drives that support WRRU, its possible to let queues of
guest's assigned partitions to belong to the high priority class and let the
host queues use the regular medium/low priority class.
For drives that don't support WRRU, the IO throttling can be done in software on
the host queues.
Host assigned partitions also don't need polling, thus allowing polling to be
used only for guests that actually need low latency IO.
This reduces the number of cores that would be otherwise lost to polling,
because the less work the polling core does, the less latency it contributes to
overall latency, thus with less users, you could use less cores to achieve the
same levels of latency.
For Stefan's argument, we can look at it in a slightly different way too:
While the nvme-mdev can be seen as a duplication of SPDK, the SPDK can also be
seen as duplication of an existing kernel functionality which nvme-mdev can
reuse for free.
Best regards,
Maxim Levitsky
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
2019-03-21 17:04 ` Maxim Levitsky
@ 2019-03-22 7:54 ` Felipe Franciosi
2019-03-22 10:32 ` Maxim Levitsky
2019-03-22 15:30 ` Keith Busch
0 siblings, 2 replies; 732+ messages in thread
From: Felipe Franciosi @ 2019-03-22 7:54 UTC (permalink / raw)
> On Mar 21, 2019,@5:04 PM, Maxim Levitsky <mlevitsk@redhat.com> wrote:
>
> On Thu, 2019-03-21@16:41 +0000, Felipe Franciosi wrote:
>>> On Mar 21, 2019,@4:21 PM, Keith Busch <kbusch@kernel.org> wrote:
>>>
>>> On Thu, Mar 21, 2019@04:12:39PM +0000, Stefan Hajnoczi wrote:
>>>> mdev-nvme seems like a duplication of SPDK. The performance is not
>>>> better and the features are more limited, so why focus on this approach?
>>>>
>>>> One argument might be that the kernel NVMe subsystem wants to offer this
>>>> functionality and loading the kernel module is more convenient than
>>>> managing SPDK to some users.
>>>>
>>>> Thoughts?
>>>
>>> Doesn't SPDK bind a controller to a single process? mdev binds to
>>> namespaces (or their partitions), so you could have many mdev's assigned
>>> to many VMs accessing a single controller.
>>
>> Yes, it binds to a single process which can drive the datapath of multiple
>> virtual controllers for multiple VMs (similar to what you described for mdev).
>> You can therefore efficiently poll multiple VM submission queues (and multiple
>> device completion queues) from a single physical CPU.
>>
>> The same could be done in the kernel, but the code gets complicated as you add
>> more functionality to it. As this is a direct interface with an untrusted
>> front-end (the guest), it's also arguably safer to do in userspace.
>>
>> Worth noting: you can eventually have a single physical core polling all sorts
>> of virtual devices (eg. virtual storage or network controllers) very
>> efficiently. And this is quite configurable, too. In the interest of fairness,
>> performance or efficiency, you can choose to dynamically add or remove queues
>> to the poll thread or spawn more threads and redistribute the work.
>>
>> F.
>
> Note though that SPDK doesn't support sharing the device between host and the
> guests, it takes over the nvme device, thus it makes the kernel nvme driver
> unbind from it.
That is absolutely true. However, I find it not to be a problem in practice.
Hypervisor products, specially those caring about performance, efficiency and fairness, will dedicate NVMe devices for a particular purpose (eg. vDisk storage, cache, metadata) and will not share these devices for other use cases. That's because these products want to deterministically control the performance aspects of the device, which you just cannot do if you are sharing the device with a subsystem you do not control.
For scenarios where the device must be shared and such fine grained control is not required, it looks like using the kernel driver with io_uring offers very good performance with flexibility.
Cheers,
Felipe
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
2019-03-21 16:41 ` Felipe Franciosi
@ 2019-03-21 17:04 ` Maxim Levitsky
2019-03-22 7:54 ` Felipe Franciosi
0 siblings, 1 reply; 732+ messages in thread
From: Maxim Levitsky @ 2019-03-21 17:04 UTC (permalink / raw)
On Thu, 2019-03-21@16:41 +0000, Felipe Franciosi wrote:
> > On Mar 21, 2019,@4:21 PM, Keith Busch <kbusch@kernel.org> wrote:
> >
> > On Thu, Mar 21, 2019@04:12:39PM +0000, Stefan Hajnoczi wrote:
> > > mdev-nvme seems like a duplication of SPDK. The performance is not
> > > better and the features are more limited, so why focus on this approach?
> > >
> > > One argument might be that the kernel NVMe subsystem wants to offer this
> > > functionality and loading the kernel module is more convenient than
> > > managing SPDK to some users.
> > >
> > > Thoughts?
> >
> > Doesn't SPDK bind a controller to a single process? mdev binds to
> > namespaces (or their partitions), so you could have many mdev's assigned
> > to many VMs accessing a single controller.
>
> Yes, it binds to a single process which can drive the datapath of multiple
> virtual controllers for multiple VMs (similar to what you described for mdev).
> You can therefore efficiently poll multiple VM submission queues (and multiple
> device completion queues) from a single physical CPU.
>
> The same could be done in the kernel, but the code gets complicated as you add
> more functionality to it. As this is a direct interface with an untrusted
> front-end (the guest), it's also arguably safer to do in userspace.
>
> Worth noting: you can eventually have a single physical core polling all sorts
> of virtual devices (eg. virtual storage or network controllers) very
> efficiently. And this is quite configurable, too. In the interest of fairness,
> performance or efficiency, you can choose to dynamically add or remove queues
> to the poll thread or spawn more threads and redistribute the work.
>
> F.
Note though that SPDK doesn't support sharing the device between host and the
guests, it takes over the nvme device, thus it makes the kernel nvme driver
unbind from it.
My driver creates a polling thread per guest, but its trivial to add option to
use the same polling thread for many guests if there need for that.
Best regards,
Maxim Levitsky
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
2019-03-21 16:21 ` Keith Busch
@ 2019-03-21 16:41 ` Felipe Franciosi
2019-03-21 17:04 ` Maxim Levitsky
0 siblings, 1 reply; 732+ messages in thread
From: Felipe Franciosi @ 2019-03-21 16:41 UTC (permalink / raw)
> On Mar 21, 2019,@4:21 PM, Keith Busch <kbusch@kernel.org> wrote:
>
> On Thu, Mar 21, 2019@04:12:39PM +0000, Stefan Hajnoczi wrote:
>> mdev-nvme seems like a duplication of SPDK. The performance is not
>> better and the features are more limited, so why focus on this approach?
>>
>> One argument might be that the kernel NVMe subsystem wants to offer this
>> functionality and loading the kernel module is more convenient than
>> managing SPDK to some users.
>>
>> Thoughts?
>
> Doesn't SPDK bind a controller to a single process? mdev binds to
> namespaces (or their partitions), so you could have many mdev's assigned
> to many VMs accessing a single controller.
Yes, it binds to a single process which can drive the datapath of multiple virtual controllers for multiple VMs (similar to what you described for mdev). You can therefore efficiently poll multiple VM submission queues (and multiple device completion queues) from a single physical CPU.
The same could be done in the kernel, but the code gets complicated as you add more functionality to it. As this is a direct interface with an untrusted front-end (the guest), it's also arguably safer to do in userspace.
Worth noting: you can eventually have a single physical core polling all sorts of virtual devices (eg. virtual storage or network controllers) very efficiently. And this is quite configurable, too. In the interest of fairness, performance or efficiency, you can choose to dynamically add or remove queues to the poll thread or spawn more threads and redistribute the work.
F.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
2019-03-21 16:12 ` Stefan Hajnoczi
@ 2019-03-21 16:21 ` Keith Busch
2019-03-21 16:41 ` Felipe Franciosi
0 siblings, 1 reply; 732+ messages in thread
From: Keith Busch @ 2019-03-21 16:21 UTC (permalink / raw)
On Thu, Mar 21, 2019@04:12:39PM +0000, Stefan Hajnoczi wrote:
> mdev-nvme seems like a duplication of SPDK. The performance is not
> better and the features are more limited, so why focus on this approach?
>
> One argument might be that the kernel NVMe subsystem wants to offer this
> functionality and loading the kernel module is more convenient than
> managing SPDK to some users.
>
> Thoughts?
Doesn't SPDK bind a controller to a single process? mdev binds to
namespaces (or their partitions), so you could have many mdev's assigned
to many VMs accessing a single controller.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
2019-03-20 19:08 ` Maxim Levitsky
@ 2019-03-21 16:12 ` Stefan Hajnoczi
2019-03-21 16:21 ` Keith Busch
0 siblings, 1 reply; 732+ messages in thread
From: Stefan Hajnoczi @ 2019-03-21 16:12 UTC (permalink / raw)
On Wed, Mar 20, 2019@09:08:37PM +0200, Maxim Levitsky wrote:
> On Wed, 2019-03-20@11:03 +0000, Felipe Franciosi wrote:
> > > On Mar 19, 2019,@2:41 PM, Maxim Levitsky <mlevitsk@redhat.com> wrote:
> > >
> > > Date: Tue, 19 Mar 2019 14:45:45 +0200
> > > Subject: [PATCH 0/9] RFC: NVME VFIO mediated device
> > >
> > > Hi everyone!
> > >
> > > In this patch series, I would like to introduce my take on the problem of
> > > doing
> > > as fast as possible virtualization of storage with emphasis on low latency.
> > >
> > > In this patch series I implemented a kernel vfio based, mediated device
> > > that
> > > allows the user to pass through a partition and/or whole namespace to a
> > > guest.
> >
> > Hey Maxim!
> >
> > I'm really excited to see this series, as it aligns to some extent with what
> > we discussed in last year's KVM Forum VFIO BoF.
> >
> > There's no arguing that we need a better story to efficiently virtualise NVMe
> > devices. So far, for Qemu-based VMs, Changpeng's vhost-user-nvme is the best
> > attempt at that. However, I seem to recall there was some pushback from qemu-
> > devel in the sense that they would rather see investment in virtio-blk. I'm
> > not sure what's the latest on that work and what are the next steps.
> I agree with that. All my benchmarks were agains his vhost-user-nvme driver, and
> I am able to get pretty much the same througput and latency.
>
> The ssd I tested on died just recently (Murphy law), not due to bug in my driver
> but some internal fault (even though most of my tests were reads, plus
> occassional 'nvme format's.
> We are in process of buying an replacement.
>
> >
> > The pushback drove the discussion towards pursuing an mdev approach, which is
> > why I'm excited to see your patches.
> >
> > What I'm thinking is that passing through namespaces or partitions is very
> > restrictive. It leaves no room to implement more elaborate virtualisation
> > stacks like replicating data across multiple devices (local or remote),
> > storage migration, software-managed thin provisioning, encryption,
> > deduplication, compression, etc. In summary, anything that requires software
> > intervention in the datapath. (Worth noting: vhost-user-nvme allows all of
> > that to be easily done in SPDK's bdev layer.)
>
> Hi Felipe!
>
> I guess that my driver is not geared toward more complicated use cases like you
> mentioned, but instead it is focused to get as fast as possible performance for
> the common case.
>
> One thing that I can do which would solve several of the above problems is to
> accept an map betwent virtual and real logical blocks, pretty much in exactly
> the same way as EPT does it.
> Then userspace can map any portions of the device anywhere, while still keeping
> the dataplane in the kernel, and having minimal overhead.
>
> On top of that, note that the direction of IO virtualization is to do dataplane
> in hardware, which will probably give you even worse partition granuality /
> features but will be the fastest option aviable,
> like for instance SR-IOV which alrady exists and just allows to split by
> namespaces without any more fine grained control.
>
> Think of nvme-mdev as a very low level driver, which currntly uses polling, but
> eventually will use PASID based IOMMU to provide the guest with raw PCI device.
> The userspace / qemu can build on top of that with varios software layers.
>
> On top of that I am thinking to solve the problem of migration in Qemu, by
> creating a 'vfio-nvme' driver which would bind vfio to bind to device exposed by
> the kernel, and would pass through all the doorbells and queues to the guest,
> while intercepting the admin queue. Such driver I think can be made to support
> migration while beeing able to run on top both SR-IOV device, my vfio-nvme abit
> with double admin queue emulation (its a bit ugly but won't affect performance
> at all) and on top of even regular NVME device vfio assigned to guest.
mdev-nvme seems like a duplication of SPDK. The performance is not
better and the features are more limited, so why focus on this approach?
One argument might be that the kernel NVMe subsystem wants to offer this
functionality and loading the kernel module is more convenient than
managing SPDK to some users.
Thoughts?
Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-nvme/attachments/20190321/8b770a99/attachment.sig>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
2019-03-20 11:03 ` Felipe Franciosi
@ 2019-03-20 19:08 ` Maxim Levitsky
2019-03-21 16:12 ` Stefan Hajnoczi
0 siblings, 1 reply; 732+ messages in thread
From: Maxim Levitsky @ 2019-03-20 19:08 UTC (permalink / raw)
On Wed, 2019-03-20@11:03 +0000, Felipe Franciosi wrote:
> > On Mar 19, 2019,@2:41 PM, Maxim Levitsky <mlevitsk@redhat.com> wrote:
> >
> > Date: Tue, 19 Mar 2019 14:45:45 +0200
> > Subject: [PATCH 0/9] RFC: NVME VFIO mediated device
> >
> > Hi everyone!
> >
> > In this patch series, I would like to introduce my take on the problem of
> > doing
> > as fast as possible virtualization of storage with emphasis on low latency.
> >
> > In this patch series I implemented a kernel vfio based, mediated device
> > that
> > allows the user to pass through a partition and/or whole namespace to a
> > guest.
>
> Hey Maxim!
>
> I'm really excited to see this series, as it aligns to some extent with what
> we discussed in last year's KVM Forum VFIO BoF.
>
> There's no arguing that we need a better story to efficiently virtualise NVMe
> devices. So far, for Qemu-based VMs, Changpeng's vhost-user-nvme is the best
> attempt at that. However, I seem to recall there was some pushback from qemu-
> devel in the sense that they would rather see investment in virtio-blk. I'm
> not sure what's the latest on that work and what are the next steps.
I agree with that. All my benchmarks were agains his vhost-user-nvme driver, and
I am able to get pretty much the same througput and latency.
The ssd I tested on died just recently (Murphy law), not due to bug in my driver
but some internal fault (even though most of my tests were reads, plus
occassional 'nvme format's.
We are in process of buying an replacement.
>
> The pushback drove the discussion towards pursuing an mdev approach, which is
> why I'm excited to see your patches.
>
> What I'm thinking is that passing through namespaces or partitions is very
> restrictive. It leaves no room to implement more elaborate virtualisation
> stacks like replicating data across multiple devices (local or remote),
> storage migration, software-managed thin provisioning, encryption,
> deduplication, compression, etc. In summary, anything that requires software
> intervention in the datapath. (Worth noting: vhost-user-nvme allows all of
> that to be easily done in SPDK's bdev layer.)
Hi Felipe!
I guess that my driver is not geared toward more complicated use cases like you
mentioned, but instead it is focused to get as fast as possible performance for
the common case.
One thing that I can do which would solve several of the above problems is to
accept an map betwent virtual and real logical blocks, pretty much in exactly
the same way as EPT does it.
Then userspace can map any portions of the device anywhere, while still keeping
the dataplane in the kernel, and having minimal overhead.
On top of that, note that the direction of IO virtualization is to do dataplane
in hardware, which will probably give you even worse partition granuality /
features but will be the fastest option aviable,
like for instance SR-IOV which alrady exists and just allows to split by
namespaces without any more fine grained control.
Think of nvme-mdev as a very low level driver, which currntly uses polling, but
eventually will use PASID based IOMMU to provide the guest with raw PCI device.
The userspace / qemu can build on top of that with varios software layers.
On top of that I am thinking to solve the problem of migration in Qemu, by
creating a 'vfio-nvme' driver which would bind vfio to bind to device exposed by
the kernel, and would pass through all the doorbells and queues to the guest,
while intercepting the admin queue. Such driver I think can be made to support
migration while beeing able to run on top both SR-IOV device, my vfio-nvme abit
with double admin queue emulation (its a bit ugly but won't affect performance
at all) and on top of even regular NVME device vfio assigned to guest.
Best regards,
Maxim Levitsky
>
> These complicated stacks should probably not be implemented in the kernel,
> though. So I'm wondering whether we could talk about mechanisms to allow
> efficient and performant userspace datapath intervention in your approach or
> pursue a mechanism to completely offload the device emulation to userspace
> (and align with what SPDK has to offer).
>
> Thoughts welcome!
> Felipe
> _______________________________________________
> Linux-nvme mailing list
> Linux-nvme at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
2019-03-19 14:41 Maxim Levitsky
@ 2019-03-20 11:03 ` Felipe Franciosi
2019-03-20 19:08 ` Maxim Levitsky
0 siblings, 1 reply; 732+ messages in thread
From: Felipe Franciosi @ 2019-03-20 11:03 UTC (permalink / raw)
> On Mar 19, 2019,@2:41 PM, Maxim Levitsky <mlevitsk@redhat.com> wrote:
>
> Date: Tue, 19 Mar 2019 14:45:45 +0200
> Subject: [PATCH 0/9] RFC: NVME VFIO mediated device
>
> Hi everyone!
>
> In this patch series, I would like to introduce my take on the problem of doing
> as fast as possible virtualization of storage with emphasis on low latency.
>
> In this patch series I implemented a kernel vfio based, mediated device that
> allows the user to pass through a partition and/or whole namespace to a guest.
Hey Maxim!
I'm really excited to see this series, as it aligns to some extent with what we discussed in last year's KVM Forum VFIO BoF.
There's no arguing that we need a better story to efficiently virtualise NVMe devices. So far, for Qemu-based VMs, Changpeng's vhost-user-nvme is the best attempt at that. However, I seem to recall there was some pushback from qemu-devel in the sense that they would rather see investment in virtio-blk. I'm not sure what's the latest on that work and what are the next steps.
The pushback drove the discussion towards pursuing an mdev approach, which is why I'm excited to see your patches.
What I'm thinking is that passing through namespaces or partitions is very restrictive. It leaves no room to implement more elaborate virtualisation stacks like replicating data across multiple devices (local or remote), storage migration, software-managed thin provisioning, encryption, deduplication, compression, etc. In summary, anything that requires software intervention in the datapath. (Worth noting: vhost-user-nvme allows all of that to be easily done in SPDK's bdev layer.)
These complicated stacks should probably not be implemented in the kernel, though. So I'm wondering whether we could talk about mechanisms to allow efficient and performant userspace datapath intervention in your approach or pursue a mechanism to completely offload the device emulation to userspace (and align with what SPDK has to offer).
Thoughts welcome!
Felipe
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2019-03-19 14:41 Maxim Levitsky
2019-03-20 11:03 ` Felipe Franciosi
0 siblings, 1 reply; 732+ messages in thread
From: Maxim Levitsky @ 2019-03-19 14:41 UTC (permalink / raw)
Date: Tue, 19 Mar 2019 14:45:45 +0200
Subject: [PATCH 0/9] RFC: NVME VFIO mediated device
Hi everyone!
In this patch series, I would like to introduce my take on the problem of doing
as fast as possible virtualization of storage with emphasis on low latency.
In this patch series I implemented a kernel vfio based, mediated device that
allows the user to pass through a partition and/or whole namespace to a guest.
The idea behind this driver is based on paper you can find at
https://www.usenix.org/conference/atc18/presentation/peng,
Although note that I stared the development prior to reading this paper,
independently.
In addition to that implementation is not based on code used in the paper as
I wasn't being able at that time to make the source available to me.
***Key points about the implementation:***
* Polling kernel thread is used. The polling is stopped after a
predefined timeout (1/2 sec by default).
Support for all interrupt driven mode is planned, and it shows promising results.
* Guest sees a standard NVME device - this allows to run guest with
unmodified drivers, for example windows guests.
* The NVMe device is shared between host and guest.
That means that even a single namespace can be split between host
and guest based on different partitions.
* Simple configuration
*** Performance ***
Performance was tested on Intel DC P3700, With Xeon E5-2620 v2
and both latency and throughput is very similar to SPDK.
Soon I will test this on a better server and nvme device and provide
more formal performance numbers.
Latency numbers:
~80ms - spdk with fio plugin on the host.
~84ms - nvme driver on the host
~87ms - mdev-nvme + nvme driver in the guest
Throughput was following similar pattern as well.
* Configuration example
$ modprobe nvme mdev_queues=4
$ modprobe nvme-mdev
$ UUID=$(uuidgen)
$ DEVICE='device pci address'
$ echo $UUID > /sys/bus/pci/devices/$DEVICE/mdev_supported_types/nvme-2Q_V1/create
$ echo n1p3 > /sys/bus/mdev/devices/$UUID/namespaces/add_namespace #attach host namespace 1 parition 3
$ echo 11 > /sys/bus/mdev/devices/$UUID/settings/iothread_cpu #pin the io thread to cpu 11
Afterward boot qemu with
-device vfio-pci,sysfsdev=/sys/bus/mdev/devices/$UUID
Zero configuration on the guest.
*** FAQ ***
* Why to make this in the kernel? Why this is better that SPDK
-> Reuse the existing nvme kernel driver in the host. No new drivers in the guest.
-> Share the NVMe device between host and guest.
Even in fully virtualized configurations,
some partitions of nvme device could be used by guests as block devices
while others passed through with nvme-mdev to achieve balance between
all features of full IO stack emulation and performance.
-> NVME-MDEV is a bit faster due to the fact that in-kernel driver
can send interrupts to the guest directly without a context
switch that can be expensive due to meltdown mitigation.
-> Is able to utilize interrupts to get reasonable performance.
This is only implemented
as a proof of concept and not included in the patches,
but interrupt driven mode shows reasonable performance
-> This is a framework that later can be used to support NVMe devices
with more of the IO virtualization built-in
(IOMMU with PASID support coupled with device that supports it)
* Why to attach directly to nvme-pci driver and not use block layer IO
-> The direct attachment allows for better performance, but I will
check the possibility of using block IO, especially for fabrics drivers.
*** Implementation notes ***
* All guest memory is mapped into the physical nvme device
but not 1:1 as vfio-pci would do this.
This allows very efficient DMA.
To support this, patch 2 adds ability for a mdev device to listen on
guest's memory map events.
Any such memory is immediately pinned and then DMA mapped.
(Support for fabric drivers where this is not possible exits too,
in which case the fabric driver will do its own DMA mapping)
* nvme core driver is modified to announce the appearance
and disappearance of nvme controllers and namespaces,
to which the nvme-mdev driver is subscribed.
* nvme-pci driver is modified to expose raw interface of attaching to
and sending/polling the IO queues.
This allows the mdev driver very efficiently to submit/poll for the IO.
By default one host queue is used per each mediated device.
(support for other fabric based host drivers is planned)
* The nvme-mdev doesn't assume presence of KVM, thus any VFIO user, including
SPDK, a qemu running with tccg, ... can use this virtual device.
*** Testing ***
The device was tested with stock QEMU 3.0 on the host,
with host was using 5.0 kernel with nvme-mdev added and the following hardware:
* QEMU nvme virtual device (with nested guest)
* Intel DC P3700 on Xeon E5-2620 v2 server
* Samsung SM981 (in a Thunderbolt enclosure, with my laptop)
* Lenovo NVME device found in my laptop
The guest was tested with kernel 4.16, 4.18, 4.20 and
the same custom complied kernel 5.0
Windows 10 guest was tested too with both Microsoft's inbox driver and
open source community NVME driver
(https://lists.openfabrics.org/pipermail/nvmewin/2016-December/001420.html)
Testing was mostly done on x86_64, but 32 bit host/guest combination
was lightly tested too.
In addition to that, the virtual device was tested with nested guest,
by passing the virtual device to it,
using pci passthrough, qemu userspace nvme driver, and spdk
PS: I used to contribute to the kernel as a hobby using the
maximlevitsky at gmail.com address
Maxim Levitsky (9):
vfio/mdev: add .request callback
nvme/core: add some more values from the spec
nvme/core: add NVME_CTRL_SUSPENDED controller state
nvme/pci: use the NVME_CTRL_SUSPENDED state
nvme/pci: add known admin effects to augument admin effects log page
nvme/pci: init shadow doorbell after each reset
nvme/core: add mdev interfaces
nvme/core: add nvme-mdev core driver
nvme/pci: implement the mdev external queue allocation interface
MAINTAINERS | 5 +
drivers/nvme/Kconfig | 1 +
drivers/nvme/Makefile | 1 +
drivers/nvme/host/core.c | 149 +++++-
drivers/nvme/host/nvme.h | 55 ++-
drivers/nvme/host/pci.c | 385 ++++++++++++++-
drivers/nvme/mdev/Kconfig | 16 +
drivers/nvme/mdev/Makefile | 5 +
drivers/nvme/mdev/adm.c | 873 ++++++++++++++++++++++++++++++++++
drivers/nvme/mdev/events.c | 142 ++++++
drivers/nvme/mdev/host.c | 491 +++++++++++++++++++
drivers/nvme/mdev/instance.c | 802 +++++++++++++++++++++++++++++++
drivers/nvme/mdev/io.c | 563 ++++++++++++++++++++++
drivers/nvme/mdev/irq.c | 264 ++++++++++
drivers/nvme/mdev/mdev.h | 56 +++
drivers/nvme/mdev/mmio.c | 591 +++++++++++++++++++++++
drivers/nvme/mdev/pci.c | 247 ++++++++++
drivers/nvme/mdev/priv.h | 700 +++++++++++++++++++++++++++
drivers/nvme/mdev/udata.c | 390 +++++++++++++++
drivers/nvme/mdev/vcq.c | 207 ++++++++
drivers/nvme/mdev/vctrl.c | 514 ++++++++++++++++++++
drivers/nvme/mdev/viommu.c | 322 +++++++++++++
drivers/nvme/mdev/vns.c | 356 ++++++++++++++
drivers/nvme/mdev/vsq.c | 178 +++++++
drivers/vfio/mdev/vfio_mdev.c | 11 +
include/linux/mdev.h | 4 +
include/linux/nvme.h | 88 +++-
27 files changed, 7375 insertions(+), 41 deletions(-)
create mode 100644 drivers/nvme/mdev/Kconfig
create mode 100644 drivers/nvme/mdev/Makefile
create mode 100644 drivers/nvme/mdev/adm.c
create mode 100644 drivers/nvme/mdev/events.c
create mode 100644 drivers/nvme/mdev/host.c
create mode 100644 drivers/nvme/mdev/instance.c
create mode 100644 drivers/nvme/mdev/io.c
create mode 100644 drivers/nvme/mdev/irq.c
create mode 100644 drivers/nvme/mdev/mdev.h
create mode 100644 drivers/nvme/mdev/mmio.c
create mode 100644 drivers/nvme/mdev/pci.c
create mode 100644 drivers/nvme/mdev/priv.h
create mode 100644 drivers/nvme/mdev/udata.c
create mode 100644 drivers/nvme/mdev/vcq.c
create mode 100644 drivers/nvme/mdev/vctrl.c
create mode 100644 drivers/nvme/mdev/viommu.c
create mode 100644 drivers/nvme/mdev/vns.c
create mode 100644 drivers/nvme/mdev/vsq.c
--
2.17.2
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2019-03-16 11:17 Bharath Vedartham
0 siblings, 0 replies; 732+ messages in thread
From: Bharath Vedartham @ 2019-03-16 11:17 UTC (permalink / raw)
linux-kernel at vger.kernel.org
Bcc:
Subject: [PATCH] staging: erofs: Add whitespace after declaration
Reply-To:
Fix the checkpatch.pl warning to add a whitespace after declaration
statements.
Signed-off-by: Bharath Vedartham <linux.bhar at gmail.com>
---
drivers/staging/erofs/inode.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/erofs/inode.c b/drivers/staging/erofs/inode.c
index 924b8df..9a36a1f 100644
--- a/drivers/staging/erofs/inode.c
+++ b/drivers/staging/erofs/inode.c
@@ -270,8 +270,8 @@ struct inode *erofs_iget(struct super_block *sb,
if (inode->i_state & I_NEW) {
int err;
struct erofs_vnode *vi = EROFS_V(inode);
- vi->nid = nid;
+ vi->nid = nid;
err = fill_inode(inode, isdir);
if (likely(!err))
unlock_new_inode(inode);
@@ -305,4 +305,3 @@ const struct inode_operations erofs_fast_symlink_iops = {
#endif
.get_acl = erofs_get_acl,
};
-
--
2.7.4
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2018-10-05 13:39 Christoph Hellwig
0 siblings, 0 replies; 732+ messages in thread
From: Christoph Hellwig @ 2018-10-05 13:39 UTC (permalink / raw)
Bcc:
Subject: [GIT PULL] nvme updates for 4.20
Reply-To:
A relatively boring merge window:
- better AEN tracing (Chaitanya)
- NUMA aware PCIe multipathing (me)
- RDMA workqueue fixes (Sagi)
- better bio usage in the target (Sagi)
- FC rework for target removal (James)
- better multipath handling of ->queue_rq failures (James)
- various cleanups (Milan)
The following changes since commit c0aac682fa6590cb660cb083dbc09f55e799d2d2:
Merge tag 'v4.19-rc6' into for-4.20/block (2018-10-01 08:58:57 -0600)
are available in the Git repository at:
git://git.infradead.org/nvme.git nvme-4.20
for you to fetch changes up to 2acf70ade79d26b97611a8df52eb22aa33814cd4:
nvmet-rdma: use a private workqueue for delete (2018-10-05 09:25:18 +0200)
----------------------------------------------------------------
Chaitanya Kulkarni (2):
nvmet: remove redundant module prefix
nvme-core: add async event trace helper
Christoph Hellwig (1):
nvme: take node locality into account when selecting a path
James Smart (3):
nvmet_fc: support target port removal with nvmet layer
nvme_fc: add 'nvme_discovery' sysfs attribute to fc transport device
nvme: call nvme_complete_rq when nvmf_check_ready fails for mpath I/O
Milan P. Gandhi (2):
nvme: fix typo in nvme_identify_ns_descs
nvme-fc: fix for a minor typos
Sagi Grimberg (2):
nvmet: don't split large I/Os unconditionally
nvmet-rdma: use a private workqueue for delete
drivers/nvme/host/core.c | 20 ++++--
drivers/nvme/host/fabrics.c | 7 +-
drivers/nvme/host/fc.c | 108 +++++++++++++++++++++++++++----
drivers/nvme/host/multipath.c | 57 +++++++++++++----
drivers/nvme/host/nvme.h | 25 +++-----
drivers/nvme/host/trace.h | 28 ++++++++
drivers/nvme/target/admin-cmd.c | 2 +-
drivers/nvme/target/fc.c | 130 +++++++++++++++++++++++++++++++++++---
drivers/nvme/target/io-cmd-bdev.c | 9 ++-
drivers/nvme/target/nvmet.h | 1 +
drivers/nvme/target/rdma.c | 19 ++++--
include/linux/nvme.h | 1 +
12 files changed, 347 insertions(+), 60 deletions(-)
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2018-08-02 10:48 TU PHUNG VAN
0 siblings, 0 replies; 732+ messages in thread
From: TU PHUNG VAN @ 2018-08-02 10:48 UTC (permalink / raw)
To: kernelnewbies
S.?
www
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180802/20565816/attachment.html>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
2018-07-06 21:16 ` Santosh Shilimkar
@ 2018-07-06 21:18 ` Santosh Shilimkar
0 siblings, 0 replies; 732+ messages in thread
From: Santosh Shilimkar @ 2018-07-06 21:18 UTC (permalink / raw)
To: linux-arm-kernel
Ignore this.. Will send again with subjects fixed
On 7/6/2018 2:16 PM, Santosh Shilimkar wrote:
> Subject: [GIT PULL 3/3] SOC: Driver updates for v4.19
>
> The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
>
> Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git tags/soc_drivers_for_4.19
>
> for you to fetch changes up to 990c10091db318c7eb7e8935c86b6f7c01585015:
>
> soc: ti: wkup_m3_ipc: mark PM functions as __maybe_unused (2018-07-06 09:47:51 -0700)
>
> ----------------------------------------------------------------
> Keystone SOC driver update for 4.19
>
> - Add suspend/resume functionality to TI EMIF SRAM driver
> - Add wakeup M3 RTC self refresh support
> - Fix for the PM runtime ifdefs
>
> ----------------------------------------------------------------
> Arnd Bergmann (1):
> soc: ti: wkup_m3_ipc: mark PM functions as __maybe_unused
>
> Dave Gerlach (2):
> memory: ti-emif-sram: Add resume function to recopy sram code
> soc: ti: wkup_m3_ipc: Add wkup_m3_request_wake_src
>
> Keerthy (1):
> soc: ti: wkup_m3_ipc: Add rtc_only with ddr in self refresh mode support
>
> drivers/memory/ti-emif-pm.c | 33 +++++++++++++++++++
> drivers/soc/ti/wkup_m3_ipc.c | 76 ++++++++++++++++++++++++++++++++++++++++++++
> include/linux/wkup_m3_ipc.h | 9 ++++++
> 3 files changed, 118 insertions(+)
>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
2018-07-06 21:16 Santosh Shilimkar
2018-07-06 21:16 ` Santosh Shilimkar
@ 2018-07-06 21:16 ` Santosh Shilimkar
2018-07-06 21:18 ` Santosh Shilimkar
1 sibling, 1 reply; 732+ messages in thread
From: Santosh Shilimkar @ 2018-07-06 21:16 UTC (permalink / raw)
To: linux-arm-kernel
Subject: [GIT PULL 3/3] SOC: Driver updates for v4.19
The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git tags/soc_drivers_for_4.19
for you to fetch changes up to 990c10091db318c7eb7e8935c86b6f7c01585015:
soc: ti: wkup_m3_ipc: mark PM functions as __maybe_unused (2018-07-06 09:47:51 -0700)
----------------------------------------------------------------
Keystone SOC driver update for 4.19
- Add suspend/resume functionality to TI EMIF SRAM driver
- Add wakeup M3 RTC self refresh support
- Fix for the PM runtime ifdefs
----------------------------------------------------------------
Arnd Bergmann (1):
soc: ti: wkup_m3_ipc: mark PM functions as __maybe_unused
Dave Gerlach (2):
memory: ti-emif-sram: Add resume function to recopy sram code
soc: ti: wkup_m3_ipc: Add wkup_m3_request_wake_src
Keerthy (1):
soc: ti: wkup_m3_ipc: Add rtc_only with ddr in self refresh mode support
drivers/memory/ti-emif-pm.c | 33 +++++++++++++++++++
drivers/soc/ti/wkup_m3_ipc.c | 76 ++++++++++++++++++++++++++++++++++++++++++++
include/linux/wkup_m3_ipc.h | 9 ++++++
3 files changed, 118 insertions(+)
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
2018-07-06 21:16 Santosh Shilimkar
@ 2018-07-06 21:16 ` Santosh Shilimkar
2018-07-06 21:16 ` Santosh Shilimkar
1 sibling, 0 replies; 732+ messages in thread
From: Santosh Shilimkar @ 2018-07-06 21:16 UTC (permalink / raw)
To: linux-arm-kernel
Subject: [GIT PULL 2/3] ARM: Keystone config update for v4.19
The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git tags/keystone_config_for_4.19
for you to fetch changes up to 60e9343b355118e903a155135f0511918d69e3ac:
ARM: configs: keystone: Enable CONFIG_MMC_SDHCI_OMAP (2018-06-29 15:57:53 -0700)
----------------------------------------------------------------
ARM: Keystone config updates for 4.19
- Enable MMC support
- Enable Micrel and DP83867 phys
----------------------------------------------------------------
Kishon Vijay Abraham I (1):
ARM: configs: keystone: Enable CONFIG_MMC_SDHCI_OMAP
Murali Karicheri (1):
ARM: keystone: k2g: enable micrel and dp83867 phys
arch/arm/configs/keystone_defconfig | 5 +++++
1 file changed, 5 insertions(+)
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2018-07-06 21:16 Santosh Shilimkar
2018-07-06 21:16 ` Santosh Shilimkar
2018-07-06 21:16 ` Santosh Shilimkar
0 siblings, 2 replies; 732+ messages in thread
From: Santosh Shilimkar @ 2018-07-06 21:16 UTC (permalink / raw)
To: linux-arm-kernel
Subject: [GIT PULL 1/3] ARM: Keystone DTS update for v4.19
The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git tags/keystone_dts_for_4.19
for you to fetch changes up to f7e8a182a41e791cca3d7a9e25adddf2908bddde:
ARM: dts: keystone-k2g-evm: Use sdhci-omap programming model (2018-06-29 15:57:27 -0700)
----------------------------------------------------------------
ARM: Keystone DTS updates for 4.19
- K2G NIC drriver support
- Enbale network support for K2G ICE and EVM boards
- Hardware Ring driver support for k2hk, k2l and k2e socs
- Add MMC supply for k2g EVM
----------------------------------------------------------------
Kishon Vijay Abraham I (2):
ARM: dts: keystone-k2g-evm: Add "vqmmc-supply" property for mmc0/mmc1
ARM: dts: keystone-k2g-evm: Use sdhci-omap programming model
Murali Karicheri (3):
ARM: dts: k2g: add dt bindings to support network driver
ARM: dts: keystone-k2g-evm: Enable netcp network driver
ARM: dts: keystone-k2g-ice: Enable netcp network driver
Vitaly Andrianov (3):
ARM: dts: k2hk: add dts node for k2hk hw_rng driver
ARM: dts: k2l: add dts node for k2l hw_rng driver
ARM: dts: k2e: add dts node for k2e hw_rng driver
arch/arm/boot/dts/keystone-k2e-netcp.dtsi | 20 ++++
arch/arm/boot/dts/keystone-k2g-evm.dts | 63 +++++++++++++
arch/arm/boot/dts/keystone-k2g-ice.dts | 59 ++++++++++++
arch/arm/boot/dts/keystone-k2g-netcp.dtsi | 147 +++++++++++++++++++++++++++++
arch/arm/boot/dts/keystone-k2g.dtsi | 25 +++--
arch/arm/boot/dts/keystone-k2hk-netcp.dtsi | 20 ++++
arch/arm/boot/dts/keystone-k2l-netcp.dtsi | 20 ++++
7 files changed, 346 insertions(+), 8 deletions(-)
create mode 100644 arch/arm/boot/dts/keystone-k2g-netcp.dtsi
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2018-07-06 5:52 inventsekar
0 siblings, 0 replies; 732+ messages in thread
From: inventsekar @ 2018-07-06 5:52 UTC (permalink / raw)
To: kernelnewbies
Dear All,....
so I was reading on Quora....
https://www.quora.com/What-are-some-features-that-Linus-Torvalds-dismissed-from-the-Linux-kernel
Signing Linux kernel with Microsoft secure boot keys for UEFI. That was
suggested by RedHat developers and Linus flipped them off in his
character...
I went to that link and read two three times, but I could not understand.
Could you explain this above issue, on a newbies perspective.
Best regards, sekar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180706/6727e55a/attachment-0001.html>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2018-06-23 21:08 David Lechner
0 siblings, 0 replies; 732+ messages in thread
From: David Lechner @ 2018-06-23 21:08 UTC (permalink / raw)
To: linux-arm-kernel
Date: Sat, 23 Jun 2018 15:43:59 -0500
Subject: [PATCH 0/8] New remoteproc driver for TI PRU
This series adds a new remoteproc driver for the TI Programmable Runtime Unit
(PRU) that is present in some TI Sitara processors. This code has been tested
working on AM1808 (LEGO MINDSTORMS EV3) and AM3358 (BeagleBone Green).
There are a couple of quirks that had to be worked around in order to get this
working. The PRU units have multiple memory maps. Notably, both the instruction
RAM and data RAM are at address 0x0. This caused the da_to_va callback to not
work because the same address could refer to two different locations. To work
around this, the first two patches add a "map" parameter to the da_to_va
callbacks so that we have an extra bit of information to make this distinction.
Also, on AM38xx we have to use pdata for accessing a reset since there is not
a reset controller. There are several other devices doing this, so the seems
the best way for now.
For anyone else who would like to test, I used the rpmsg-client-sample driver.
Just enable it in your kernel config. Then grab the appropriate firmware[1]
and put in in /lib/firmware/. Use sysfs to start and stop the PRU:
echo start > /sys/class/remoteproc<n>/state
echo stop > /sys/class/remoteproc<n>/state
[1]: firmware downloads:
AM18XX: https://github.com/ev3dev/ev3dev-pru-firmware/releases/download/mainline-kernel-testing/AM18xx-PRU-rpmsg-client-sample.zip
AM335X: https://github.com/ev3dev/ev3dev-pru-firmware/releases/download/mainline-kernel-testing/AM335x-PRU-rpmsg-client-sample.zip
David Lechner (8):
remoteproc: add map parameter to da_to_va
remoteproc: add page lookup for TI PRU to ELF loader
ARM: OMAP2+: add pdata quirks for PRUSS reset
dt-bindings: add bindings for TI PRU as remoteproc
remoteproc: new driver for TI PRU
ARM: davinci_all_defconfig: enable PRU remoteproc module
ARM: dts: da850: add node for PRUSS
ARM: dts: am33xx: add node for PRU remoteproc
.../bindings/remoteproc/ti_pru_rproc.txt | 51 ++
MAINTAINERS | 5 +
arch/arm/boot/dts/am33xx.dtsi | 9 +
arch/arm/boot/dts/da850.dtsi | 8 +
arch/arm/configs/davinci_all_defconfig | 2 +
arch/arm/mach-omap2/pdata-quirks.c | 9 +
drivers/remoteproc/Kconfig | 7 +
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/imx_rproc.c | 2 +-
drivers/remoteproc/keystone_remoteproc.c | 3 +-
drivers/remoteproc/qcom_adsp_pil.c | 2 +-
drivers/remoteproc/qcom_q6v5_pil.c | 2 +-
drivers/remoteproc/qcom_wcnss.c | 2 +-
drivers/remoteproc/remoteproc_core.c | 10 +-
drivers/remoteproc/remoteproc_elf_loader.c | 117 +++-
drivers/remoteproc/remoteproc_internal.h | 2 +-
drivers/remoteproc/st_slim_rproc.c | 2 +-
drivers/remoteproc/ti_pru_rproc.c | 660 ++++++++++++++++++
drivers/remoteproc/wkup_m3_rproc.c | 3 +-
include/linux/platform_data/ti-pruss.h | 18 +
include/linux/remoteproc.h | 2 +-
include/uapi/linux/elf-em.h | 1 +
22 files changed, 899 insertions(+), 19 deletions(-)
create mode 100644 Documentation/devicetree/bindings/remoteproc/ti_pru_rproc.txt
create mode 100644 drivers/remoteproc/ti_pru_rproc.c
create mode 100644 include/linux/platform_data/ti-pruss.h
--
2.17.1
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2018-05-08 6:10 Vishnu Gopinath
0 siblings, 0 replies; 732+ messages in thread
From: Vishnu Gopinath @ 2018-05-08 6:10 UTC (permalink / raw)
To: kernelnewbies
new in the field of linux kernal... how to start..from where to start
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180508/10f1e928/attachment.html>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2018-05-04 20:06 Bjorn Helgaas
0 siblings, 0 replies; 732+ messages in thread
From: Bjorn Helgaas @ 2018-05-04 20:06 UTC (permalink / raw)
To: linux-arm-kernel
Bcc:
Subject: Re: [PATCH] PCI: Check whether bridges allow access to extended
config space
Reply-To:
In-Reply-To: <5AEC8002.5000309@kontron.com>
[+cc Fred, Sinan]
On Fri, May 04, 2018 at 03:45:07PM +0000, Gilles Buloz wrote:
> Le 04/05/2018 00:31, Bjorn Helgaas a ?crit :
> > [+cc LKML]
> >
> > On Thu, May 03, 2018 at 12:40:27PM +0000, Gilles Buloz wrote:
> >> Subject: [PATCH] For exception at PCI probe due to bridge reporting UR
> >>
> >> Even if a device supports extended config access, no such access must be
> >> done to this device If there's a bridge not supporting that in the path
> >> to this device. Doing such access with UR reporting enabled on the root
> >> bridge leads to an exception.
> >>
> >> This is the case on a LS1043A CPU (NXP QorIQ Layerscape) platform with
> >> the following bus topology :
> >> LS1043 PCIe root
> >> -> PEX8112 PCIe-to-PCI bridge (not supporting ext cfg on PCI side)
> >> -> PMC slot connector (for legacy PMC modules)
> >> With a PMC module topology as follows :
> >> PMC connector
> >> -> PCI-to-PCIe bridge
> >> -> PCIe switch (4 ports)
> >> -> 4 PCIe devices (one on each port)
> >> In this case all devices behind the PEX8112 are supporting extended config
> >> access but this is prohibited by the PEX8112. Without this patch, an
> >> exception (synchronous abort) occurs in pci_cfg_space_size_ext().
> >>
> >> This patch checks the parent bridge of each allocated child bus to know if
> >> extended config access is supported on the child bus, and sets a flag in
> >> child->bus_flags if not supported. This flag is inherited by all children
> >> buses of this child bus and then is checked to avoid this unsupported
> >> accesses to every device on these buses.
> > Hi Gilles,
> >
> > Thanks for the patch! I reworked it a little bit to simplify the code
> > in pci_alloc_child_bus(). Can you test it and make sure I didn't
> > break anything?
> >
> Hi Bjorn,
>
> Your rework works as expected. Tested on LS1043A platform with kernel 4.17-rc1, and with some backport on kernel 4.1.35
>
> Suggestion : maybe change the pci_info() string to have :
> pci_bus 0000:xx: extended config space not accessible
> instead of
> pci_bus 0000:xx: extended config space not accessible on secondary bus
> as xx is already the number of the secondary bus
Oops, when I wrote that I was thinking it would be printed for the
bridge device (not the bus). I changed it as you suggest.
Interesting, I didn't think about the fact that pci_info() would work
on a struct pci_bus * as well as on a struct pci_dev *, since it's a
macro and they both have a "dev" member.
> Info : with kernel 4.17-rc1, it turns out I need pcie_aspm=off to
> have the PMC devices behind the PCI-to-PCIe bridge of the PMC safely
> detected/configured. But this is not caused by the patch.
> Without pcie_aspm=off I saw this at one boot :
> "pci 0000:02:0e.0: ASPM: Could not configure common clock" for this bridge, but devices
> correctly detected/configured
> but at most boots I get :
> no ASPM message but "pci 0000:04:02.0: bridge configuration invalid ([bus ff-ff]), reconfiguring "
> instead, and some devices are missing. Also lspci show "rev ff" for some devices.
> I don't see this problem on 4.1.35 with the same backported patch.
This is interesting, especially since you have this unusual topology
of a path to the device that is PCIe, then conventional PCI, then PCIe
again. We *should* be able to use ASPM on the PCIe links, but it's
definitely not a well-tested scenario.
Can you tell if something is actually broken? Sinan's recent change,
04875177dbe0 ("PCI/ASPM: Don't warn if already in common clock mode"),
which appeared in v4.17-rc1, turns off the message in some cases.
The "bridge configuration invalid" message just means the firmware
didn't configure the bridge. We *should* still set it up correctly,
but please report a bug if we don't.
lspci showing "ff" for some devices might be a symptom of the devices
being powered off. In that case config reads normally return ~0 data
(though on your platform maybe it would cause exceptions). I've seen
this in other situations and wondered if it would be worth adding a
hint to lspci so it could say "device may be powered off".
Anyway, if you are seeing something broken (more than just the
messages), please start a new thread about each one. If you do, could
you please:
- open a report at https://bugzilla.kernel.org/, in the Drivers/PCI
component (open a separate bug for each issue you see)
- use kernel version 4.17-rc1 and mark it as a regression if
appropriate
- attach (don't paste inline) the complete dmesg log and "lspci -vv"
output (as root) to the bug
- post a note to linux-pci at vger.kernel.org, cc Fred, Sinan, and me,
and include the link to the bugzilla
Bjorn
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2018-04-20 8:02 ` Christoph Hellwig
0 siblings, 0 replies; 732+ messages in thread
From: Christoph Hellwig @ 2018-04-20 8:02 UTC (permalink / raw)
To: linux-snps-arc
To: iommu at lists.linux-foundation.org
Cc: linux-arch at vger.kernel.org
Cc: Michal Simek <monstr at monstr.eu>
Cc: Greentime Hu <green.hu at gmail.com>
Cc: Vincent Chen <deanbo422 at gmail.com>
Cc: linux-alpha at vger.kernel.org
Cc: linux-snps-arc at lists.infradead.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-c6x-dev at linux-c6x.org
Cc: linux-hexagon at vger.kernel.org
Cc: linux-m68k at lists.linux-m68k.org
Cc: nios2-dev at lists.rocketboards.org
Cc: openrisc at lists.librecores.org
Cc: linux-parisc at vger.kernel.org
Cc: linux-sh at vger.kernel.org
Cc: sparclinux at vger.kernel.org
Cc: linux-xtensa at linux-xtensa.org
Cc: linux-kernel at vger.kernel.org
Subject: [RFC] common non-cache coherent direct dma mapping ops
Hi all,
this series continues consolidating the dma-mapping code, with a focus
on architectures that do not (always) provide cache coherence for DMA.
Three architectures (arm, mips and powerpc) are still left to be
converted later due to complexity of their dma ops selection.
The dma-noncoherent ops calls the dma-direct ops for the actual
translation of streaming mappins and allow the architecture to provide
any cache flushing required for cpu to device and/or device to cpu
ownership transfers. The dma coherent allocator is for now still left
entirely to architecture supplied implementations due the amount of
variations. Hopefully we can do some consolidation for them later on
as well.
A lot of architectures are currently doing very questionable things
in their dma mapping routines, which are documented in the changelogs
for each patch. Please review them very careful and correct me on
incorrect assumptions.
Because this series sits on top of two previously submitted series
a git tree might be useful to actually test it. It is provided here:
git://git.infradead.org/users/hch/misc.git generic-dma-noncoherent
Gitweb:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/generic-dma-noncoherent
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2018-04-20 8:02 ` Christoph Hellwig
0 siblings, 0 replies; 732+ messages in thread
From: Christoph Hellwig @ 2018-04-20 8:02 UTC (permalink / raw)
To: linux-arm-kernel
To: iommu at lists.linux-foundation.org
Cc: linux-arch at vger.kernel.org
Cc: Michal Simek <monstr@monstr.eu>
Cc: Greentime Hu <green.hu@gmail.com>
Cc: Vincent Chen <deanbo422@gmail.com>
Cc: linux-alpha at vger.kernel.org
Cc: linux-snps-arc at lists.infradead.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-c6x-dev at linux-c6x.org
Cc: linux-hexagon at vger.kernel.org
Cc: linux-m68k at lists.linux-m68k.org
Cc: nios2-dev at lists.rocketboards.org
Cc: openrisc at lists.librecores.org
Cc: linux-parisc at vger.kernel.org
Cc: linux-sh at vger.kernel.org
Cc: sparclinux at vger.kernel.org
Cc: linux-xtensa at linux-xtensa.org
Cc: linux-kernel at vger.kernel.org
Subject: [RFC] common non-cache coherent direct dma mapping ops
Hi all,
this series continues consolidating the dma-mapping code, with a focus
on architectures that do not (always) provide cache coherence for DMA.
Three architectures (arm, mips and powerpc) are still left to be
converted later due to complexity of their dma ops selection.
The dma-noncoherent ops calls the dma-direct ops for the actual
translation of streaming mappins and allow the architecture to provide
any cache flushing required for cpu to device and/or device to cpu
ownership transfers. The dma coherent allocator is for now still left
entirely to architecture supplied implementations due the amount of
variations. Hopefully we can do some consolidation for them later on
as well.
A lot of architectures are currently doing very questionable things
in their dma mapping routines, which are documented in the changelogs
for each patch. Please review them very careful and correct me on
incorrect assumptions.
Because this series sits on top of two previously submitted series
a git tree might be useful to actually test it. It is provided here:
git://git.infradead.org/users/hch/misc.git generic-dma-noncoherent
Gitweb:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/generic-dma-noncoherent
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2018-04-16 1:22 Andrew Worsley
0 siblings, 0 replies; 732+ messages in thread
From: Andrew Worsley @ 2018-04-16 1:22 UTC (permalink / raw)
To: linux-arm-kernel
This patch clears the remaining i2c buffer overrun problems that I see in my
hardware. When run at 200kHz over 2 days and 17 hours there were *NO* faults seen
despite continously accessing the all the i2c devices. I feel the remaining issues
are related to the TPM not behaving properly at clock speeds of 285kHz or higher.
The other i2c hardware is fine up to maximum 400khz. At these higher clock speeds
the TPM appears to fall behind and I see SDA held low after the TPM read and the
driver report bus arbitration lost errors. Eventually the TPM completely stops
responding and SDA is held low. But accessing the other i2c hardware causes more
i2c clock pulses which lets the SDA go high again then the other i2c devices work
with out problems which further confirms our thinking that the TPM is source of the
remaining i2c problems.
With the additional i2c fixes in the attached patch the Xilinx i2c driver
is working with out problems on our hardware. I recommend you consider adding these
changes which apply on top of the previous fixes that I sent.
Thanks
Andrew Worsley
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2018-02-25 0:39 J Freyensee
0 siblings, 0 replies; 732+ messages in thread
From: J Freyensee @ 2018-02-25 0:39 UTC (permalink / raw)
To: linux-security-module
auth fc300131 subscribe linux-security-module \
why2jjj.linux at gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2018-02-02 6:54 Jianchao Wang
0 siblings, 0 replies; 732+ messages in thread
From: Jianchao Wang @ 2018-02-02 6:54 UTC (permalink / raw)
Hi Christoph, Keith and Sagi
Please consider and comment on the following patchset.
That's really appreciated.
There is a complicated relationship between nvme_timeout and nvme_dev_disable.
- nvme_timeout has to invoke nvme_dev_disable to stop the
controller doing DMA access before free the request.
- nvme_dev_disable has to depend on nvme_timeout to complete
adminq requests to set HMB or delete sq/cq when the controller
has no response.
- nvme_dev_disable will race with nvme_timeout when cancels the
outstanding requests.
We have found some issues introduced by them, please refer the following link
http://lists.infradead.org/pipermail/linux-nvme/2018-January/015053.html
http://lists.infradead.org/pipermail/linux-nvme/2018-January/015276.html
http://lists.infradead.org/pipermail/linux-nvme/2018-January/015328.html
Even we cannot ensure there is no other issue.
The best way to fix them is to break up the relationship between them.
With this patch, we could avoid nvme_dev_disable to be invoked
by nvme_timeout and eliminate the race between nvme_timeout and
nvme_dev_disable on outstanding requests.
There are 6 patches:
1st ~ 3th patches does some preparation for the 4th one.
4th is to avoid nvme_dev_disable to be invoked by nvme_timeout, and implement
the synchronization between them. More details, please refer to the comment of
this patch.
5th fixes a bug after 4th patch is introduced. It let nvme_delete_io_queues can
only be wakeup by completion path.
6th fixes a bug found when test, it is not related with 4th patch.
This patchset was tested under debug patch for some days.
And some bugfix have been done.
The debug patch and other patches are available in following it branch:
https://github.com/jianchwa/linux-blcok.git nvme_fixes_test
Jianchao Wang (6)
0001-nvme-pci-move-clearing-host-mem-behind-stopping-queu.patch
0002-nvme-pci-fix-the-freeze-and-quiesce-for-shutdown-and.patch
0003-blk-mq-make-blk_mq_rq_update_aborted_gstate-a-extern.patch
0004-nvme-pci-break-up-nvme_timeout-and-nvme_dev_disable.patch
0005-nvme-pci-discard-wait-timeout-when-delete-cq-sq.patch
0006-nvme-pci-suspend-queues-based-on-online_queues.patch
diff stat following:
block/blk-mq.c | 3 +-
drivers/nvme/host/pci.c | 225 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-----------------------------
include/linux/blk-mq.h | 1 +
3 files changed, 169 insertions(+), 60 deletions(-)
Thanks
Jianchao
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2017-11-30 10:25 Mary Cuevas
0 siblings, 0 replies; 732+ messages in thread
From: Mary Cuevas @ 2017-11-30 10:25 UTC (permalink / raw)
To: linux-arm-kernel
Open
Sent from my iPhone
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2017-09-13 18:15 unmesh rathi
0 siblings, 0 replies; 732+ messages in thread
From: unmesh rathi @ 2017-09-13 18:15 UTC (permalink / raw)
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2017-08-22 1:38 Nicholas Piggin
0 siblings, 0 replies; 732+ messages in thread
From: Nicholas Piggin @ 2017-08-22 1:38 UTC (permalink / raw)
To: linux-arm-kernel
Date: Sun, 20 Aug 2017 13:16:16 +1000
Subject: [PATCH] timers: Fix excessive granularity of new timers after a nohz
idle
When a timer base is idle, it is forwarded when a new timer is added
to ensure that granularity does not become excessive. When not idle,
the timer tick is expected to increment the base.
However there are several problems:
- If an existing timer is modified, the base is forwarded only after
the index is calculated.
- The base is not forwarded by add_timer_on.
- There is a window after a timer is restarted from a nohz ide, after
it is marked not-idle and before the timer tick on this CPU, where a
timer may be added but the ancient base does not get forwarded.
These result in excessive granularity (a 1 jiffy timeout can blow out
to 100s of jiffies), which cause the rcu lockup detector to trigger,
among other things.
Fix this by keeping track of whether the timer base has been idle
since it was last run or forwarded, and if so then forward it before
adding a new timer.
There is still a problem where the mod_timer optimization where it's
modified with the same expiry time can result in excessive granularity
relative to the new shorter interval. That is not addressed by this
patch because checking base->was_idle would increase overhead and it's
a rather special case (you could reason that the caller should not
expect change in absolute expiry time due to such an operation). So
that is noted as a comment.
As well as fixing the visible RCU softlockup failures, I tested an
idle system (with no lockup watchdogs running) and traced all
non-deferrable timer expiries for 1000s, and analysed wakeup latency
relative to requested latency. 1.0 means we slept for as many jiffies
as requested, 2.0 means we slept 2x the time (this suffers jiffies
round-up skew at low absolute times):
max avg std
upstream 506.0 1.20 4.68
patched 2.0 1.08 0.15
This was noticed due to the lockup detector Kconfig changes dropping it
out of people's .configs. When the lockup detectors are enabled, no CPU
can go idle for longer than 4 seconds, which limits the granularity
errors. Sub-optimal timer behaviour is observable on a smaller scale:
max avg std
upstream 9.0 1.05 0.19
patched 2.0 1.04 0.11
Tested-by: David Miller <davem@davemloft.net>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
Hi Andrew,
I would have preferred to get comments from the timer maintainers, but
they've been busy or away for the past copule of weeks. Perhaps you
would consider carrying it until then?
Thanks,
Nick
kernel/time/timer.c | 44 ++++++++++++++++++++++++++++++++++++--------
1 file changed, 36 insertions(+), 8 deletions(-)
diff --git a/kernel/time/timer.c b/kernel/time/timer.c
index 8f5d1bf18854..dd7be9fe6839 100644
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -203,6 +203,7 @@ struct timer_base {
bool migration_enabled;
bool nohz_active;
bool is_idle;
+ bool was_idle; /* was it idle since last run/fwded */
DECLARE_BITMAP(pending_map, WHEEL_SIZE);
struct hlist_head vectors[WHEEL_SIZE];
} ____cacheline_aligned;
@@ -856,13 +857,19 @@ get_target_base(struct timer_base *base, unsigned tflags)
static inline void forward_timer_base(struct timer_base *base)
{
- unsigned long jnow = READ_ONCE(jiffies);
+ unsigned long jnow;
/*
- * We only forward the base when it's idle and we have a delta between
- * base clock and jiffies.
+ * We only forward the base when we are idle or have just come out
+ * of idle (was_idle logic), and have a delta between base clock
+ * and jiffies. In the common case, run_timers will take care of it.
*/
- if (!base->is_idle || (long) (jnow - base->clk) < 2)
+ if (likely(!base->was_idle))
+ return;
+
+ jnow = READ_ONCE(jiffies);
+ base->was_idle = base->is_idle;
+ if ((long)(jnow - base->clk) < 2)
return;
/*
@@ -938,6 +945,13 @@ __mod_timer(struct timer_list *timer, unsigned long expires, bool pending_only)
* same array bucket then just return:
*/
if (timer_pending(timer)) {
+ /*
+ * The downside of this optimization is that it can result in
+ * larger granularity than you would get from adding a new
+ * timer with this expiry. Would a timer flag for networking
+ * be appropriate, then we can try to keep expiry of general
+ * timers within ~1/8th of their interval?
+ */
if (timer->expires == expires)
return 1;
@@ -948,6 +962,7 @@ __mod_timer(struct timer_list *timer, unsigned long expires, bool pending_only)
* dequeue/enqueue dance.
*/
base = lock_timer_base(timer, &flags);
+ forward_timer_base(base);
clk = base->clk;
idx = calc_wheel_index(expires, clk);
@@ -964,6 +979,7 @@ __mod_timer(struct timer_list *timer, unsigned long expires, bool pending_only)
}
} else {
base = lock_timer_base(timer, &flags);
+ forward_timer_base(base);
}
ret = detach_if_pending(timer, base, false);
@@ -991,12 +1007,10 @@ __mod_timer(struct timer_list *timer, unsigned long expires, bool pending_only)
raw_spin_lock(&base->lock);
WRITE_ONCE(timer->flags,
(timer->flags & ~TIMER_BASEMASK) | base->cpu);
+ forward_timer_base(base);
}
}
- /* Try to forward a stale timer base clock */
- forward_timer_base(base);
-
timer->expires = expires;
/*
* If 'idx' was calculated above and the base time did not advance
@@ -1112,6 +1126,7 @@ void add_timer_on(struct timer_list *timer, int cpu)
WRITE_ONCE(timer->flags,
(timer->flags & ~TIMER_BASEMASK) | cpu);
}
+ forward_timer_base(base);
debug_activate(timer, timer->expires);
internal_add_timer(base, timer);
@@ -1499,8 +1514,10 @@ u64 get_next_timer_interrupt(unsigned long basej, u64 basem)
/*
* If we expect to sleep more than a tick, mark the base idle:
*/
- if ((expires - basem) > TICK_NSEC)
+ if ((expires - basem) > TICK_NSEC) {
+ base->was_idle = true;
base->is_idle = true;
+ }
}
raw_spin_unlock(&base->lock);
@@ -1611,6 +1628,17 @@ static __latent_entropy void run_timer_softirq(struct softirq_action *h)
{
struct timer_base *base = this_cpu_ptr(&timer_bases[BASE_STD]);
+ /*
+ * was_idle must be cleared before running timers so that any timer
+ * functions that call mod_timer will not try to forward the base.
+ *
+ * The deferrable base does not do idle tracking at all, so we do
+ * not forward it. This can result in very large variations in
+ * granularity for deferrable timers, but they can be deferred for
+ * long periods due to idle.
+ */
+ base->was_idle = false;
+
__run_timers(base);
if (IS_ENABLED(CONFIG_NO_HZ_COMMON) && base->nohz_active)
__run_timers(this_cpu_ptr(&timer_bases[BASE_DEF]));
--
2.13.3
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
2017-06-26 13:16 [PATCH] arm64: use readq() instead of readl() to read 64bit entry_point Luc Van Oostenryck
@ 2017-07-03 23:46 ` Khuong Dinh
0 siblings, 0 replies; 732+ messages in thread
From: Khuong Dinh @ 2017-07-03 23:46 UTC (permalink / raw)
To: linux-arm-kernel
It is good with X-Gene 1/2.
Tested-by: Khuong Dinh <kdinh@apm.com>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2017-06-06 7:19 From Lori J. Robinson
0 siblings, 0 replies; 732+ messages in thread
From: From Lori J. Robinson @ 2017-06-06 7:19 UTC (permalink / raw)
To: linux-security-module
Hello,
I am General Lori J. Robinson, I am presently in Afghanistan serving
the UN/NATO military assignment here,i have an important discussion
with you kindly respond to me through my private box
lori_robinson.usa at hotmail.com so that we can know ourselves better. I
hope to read from you if your are also interested. Thanks and hoping
to hear from you soonest.
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2017-06-04 11:59 Yury Norov
0 siblings, 0 replies; 732+ messages in thread
From: Yury Norov @ 2017-06-04 11:59 UTC (permalink / raw)
To: linux-arm-kernel
Subject: [PATCH v7 resend 2 00/20] ILP32 for ARM64
Hi Catalin,
Here is a rebase of latest kernel patchset against next-20170602. There's almost
no changes, but there are some conflicts that are not trivial, and I'd like to
refresh the submission therefore.
How are your experiments with testing and benchmarking of ILP32 are going? In
my current tests I see 0 failures on LTP. Benchmarking on SPEC CPU2006 and
LMBench shows no difference for LP64 and expected performance boost for ILP32
(compared to LP64 results).
Steve Ellcey is handling upstream submission of Glibc patches. The patches are
ready and have been reviewed and reworked per community?s comments. There are
no outstanding userspace ABI issues from Glibc. Glibc submission is now waiting
on ILP32 kernel submission.
Catalin, regarding rootfs, is OpenSuSe?s build sufficient for your experiments?
I?ve also seen Wookey merging patches for ILP32 triplet to binutils and pushing
them to Debian.
One last thing I wanted to check with you about is ILP32 PCS - does, in your
view, ARM Ltd. needs to publish any additional docs for ABI to become official?
Below is the regular description.
Thanks.
Yury
--------
This series enables aarch64 with ilp32 mode.
As supporting work, it introduces ARCH_32BIT_OFF_T configuration
option that is enabled for existing 32-bit architectures but disabled
for new arches (so 64-bit off_t is is used by new userspace). Also it
deprecates getrlimit and setrlimit syscalls prior to prlimit64.
This version is based on linux-next from 2017-03-01. It works with
glibc-2.25, and tested with LTP, glibc testsuite, trinity, lmbench,
CPUSpec.
Patches 1, 2, 3 and 8 are general, and may be applied separately.
This is the rebase of v7 - still no major changes has been made.
Kernel and GLIBC trees:
https://github.com/norov/linux/tree/ilp32-20170602
https://github.com/norov/glibc/tree/dev9
(GLIBC patches are managed by Steve Ellcey, so my tree is only for
reference.)
Changes:
v3: https://lkml.org/lkml/2014/9/3/704
v4: https://lkml.org/lkml/2015/4/13/691
v5: https://lkml.org/lkml/2015/9/29/911
v6: https://lkml.org/lkml/2016/5/23/661
v7: RFC nowrap: https://lkml.org/lkml/2016/6/17/990
v7: RFC2 nowrap: https://lkml.org/lkml/2016/8/17/245
v7: RFC3 nowrap: https://lkml.org/lkml/2016/10/21/883
v7: https://lkml.org/lkml/2017/1/9/213
v7: Resend: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-March/490801.html
v7: Resend 2:
- vdso-ilp32 Makefile synced with lp64 Makefile (patch 19);
- rebased on next-20170602.
Andrew Pinski (6):
arm64: rename COMPAT to AARCH32_EL0 in Kconfig
arm64: ensure the kernel is compiled for LP64
arm64:uapi: set __BITS_PER_LONG correctly for ILP32 and LP64
arm64: ilp32: add sys_ilp32.c and a separate table (in entry.S) to use
it
arm64: ilp32: introduce ilp32-specific handlers for sigframe and
ucontext
arm64:ilp32: add ARM64_ILP32 to Kconfig
Philipp Tomsich (1):
arm64:ilp32: add vdso-ilp32 and use for signal return
Yury Norov (13):
compat ABI: use non-compat openat and open_by_handle_at variants
32-bit ABI: introduce ARCH_32BIT_OFF_T config option
asm-generic: Drop getrlimit and setrlimit syscalls from default list
arm64: ilp32: add documentation on the ILP32 ABI for ARM64
thread: move thread bits accessors to separated file
arm64: introduce is_a32_task and is_a32_thread (for AArch32 compat)
arm64: ilp32: add is_ilp32_compat_{task,thread} and TIF_32BIT_AARCH64
arm64: introduce binfmt_elf32.c
arm64: ilp32: introduce binfmt_ilp32.c
arm64: ilp32: share aarch32 syscall handlers
arm64: signal: share lp64 signal routines to ilp32
arm64: signal32: move ilp32 and aarch32 common code to separated file
arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32
Documentation/arm64/ilp32.txt | 45 +++++++
arch/Kconfig | 4 +
arch/arc/Kconfig | 1 +
arch/arc/include/uapi/asm/unistd.h | 1 +
arch/arm/Kconfig | 1 +
arch/arm64/Kconfig | 19 ++-
arch/arm64/Makefile | 8 ++
arch/arm64/include/asm/compat.h | 19 +--
arch/arm64/include/asm/elf.h | 37 ++----
arch/arm64/include/asm/fpsimd.h | 2 +-
arch/arm64/include/asm/ftrace.h | 2 +-
arch/arm64/include/asm/hwcap.h | 6 +-
arch/arm64/include/asm/is_compat.h | 90 ++++++++++++++
arch/arm64/include/asm/memory.h | 5 +-
arch/arm64/include/asm/processor.h | 11 +-
arch/arm64/include/asm/ptrace.h | 2 +-
arch/arm64/include/asm/seccomp.h | 2 +-
arch/arm64/include/asm/signal32.h | 9 +-
arch/arm64/include/asm/signal32_common.h | 27 ++++
arch/arm64/include/asm/signal_common.h | 33 +++++
arch/arm64/include/asm/signal_ilp32.h | 38 ++++++
arch/arm64/include/asm/syscall.h | 2 +-
arch/arm64/include/asm/thread_info.h | 4 +-
arch/arm64/include/asm/unistd.h | 6 +-
arch/arm64/include/asm/vdso.h | 6 +
arch/arm64/include/uapi/asm/bitsperlong.h | 9 +-
arch/arm64/include/uapi/asm/unistd.h | 13 ++
arch/arm64/kernel/Makefile | 8 +-
arch/arm64/kernel/asm-offsets.c | 9 +-
arch/arm64/kernel/binfmt_elf32.c | 38 ++++++
arch/arm64/kernel/binfmt_ilp32.c | 85 +++++++++++++
arch/arm64/kernel/cpufeature.c | 8 +-
arch/arm64/kernel/cpuinfo.c | 20 +--
arch/arm64/kernel/entry.S | 34 +++++-
arch/arm64/kernel/entry32.S | 80 ------------
arch/arm64/kernel/entry32_common.S | 107 ++++++++++++++++
arch/arm64/kernel/entry_ilp32.S | 22 ++++
arch/arm64/kernel/head.S | 2 +-
arch/arm64/kernel/hw_breakpoint.c | 8 +-
arch/arm64/kernel/perf_regs.c | 2 +-
arch/arm64/kernel/process.c | 7 +-
arch/arm64/kernel/ptrace.c | 80 ++++++++++--
arch/arm64/kernel/signal.c | 102 ++++++++++------
arch/arm64/kernel/signal32.c | 107 ----------------
arch/arm64/kernel/signal32_common.c | 135 ++++++++++++++++++++
arch/arm64/kernel/signal_ilp32.c | 170 ++++++++++++++++++++++++++
arch/arm64/kernel/sys_ilp32.c | 100 +++++++++++++++
arch/arm64/kernel/traps.c | 5 +-
arch/arm64/kernel/vdso-ilp32/.gitignore | 2 +
arch/arm64/kernel/vdso-ilp32/Makefile | 80 ++++++++++++
arch/arm64/kernel/vdso-ilp32/vdso-ilp32.S | 33 +++++
arch/arm64/kernel/vdso-ilp32/vdso-ilp32.lds.S | 95 ++++++++++++++
arch/arm64/kernel/vdso.c | 69 +++++++++--
arch/arm64/kernel/vdso/gettimeofday.S | 20 ++-
arch/arm64/kernel/vdso/vdso.S | 6 +-
arch/blackfin/Kconfig | 1 +
arch/c6x/include/uapi/asm/unistd.h | 1 +
arch/cris/Kconfig | 1 +
arch/frv/Kconfig | 1 +
arch/h8300/Kconfig | 1 +
arch/h8300/include/uapi/asm/unistd.h | 1 +
arch/hexagon/Kconfig | 1 +
arch/hexagon/include/uapi/asm/unistd.h | 1 +
arch/m32r/Kconfig | 1 +
arch/m68k/Kconfig | 1 +
arch/metag/Kconfig | 1 +
arch/metag/include/uapi/asm/unistd.h | 1 +
arch/microblaze/Kconfig | 1 +
arch/mips/Kconfig | 1 +
arch/mn10300/Kconfig | 1 +
arch/nios2/Kconfig | 1 +
arch/nios2/include/uapi/asm/unistd.h | 1 +
arch/openrisc/Kconfig | 1 +
arch/openrisc/include/uapi/asm/unistd.h | 1 +
arch/parisc/Kconfig | 1 +
arch/powerpc/Kconfig | 1 +
arch/score/Kconfig | 1 +
arch/score/include/uapi/asm/unistd.h | 1 +
arch/sh/Kconfig | 1 +
arch/sparc/Kconfig | 1 +
arch/tile/Kconfig | 1 +
arch/tile/include/uapi/asm/unistd.h | 1 +
arch/tile/kernel/compat.c | 3 +
arch/unicore32/Kconfig | 1 +
arch/unicore32/include/uapi/asm/unistd.h | 1 +
arch/x86/Kconfig | 1 +
arch/x86/um/Kconfig | 1 +
arch/xtensa/Kconfig | 1 +
drivers/clocksource/arm_arch_timer.c | 2 +-
include/linux/fcntl.h | 2 +-
include/linux/thread_bits.h | 63 ++++++++++
include/linux/thread_info.h | 66 ++--------
include/uapi/asm-generic/unistd.h | 10 +-
93 files changed, 1601 insertions(+), 413 deletions(-)
create mode 100644 Documentation/arm64/ilp32.txt
create mode 100644 arch/arm64/include/asm/is_compat.h
create mode 100644 arch/arm64/include/asm/signal32_common.h
create mode 100644 arch/arm64/include/asm/signal_common.h
create mode 100644 arch/arm64/include/asm/signal_ilp32.h
create mode 100644 arch/arm64/kernel/binfmt_elf32.c
create mode 100644 arch/arm64/kernel/binfmt_ilp32.c
create mode 100644 arch/arm64/kernel/entry32_common.S
create mode 100644 arch/arm64/kernel/entry_ilp32.S
create mode 100644 arch/arm64/kernel/signal32_common.c
create mode 100644 arch/arm64/kernel/signal_ilp32.c
create mode 100644 arch/arm64/kernel/sys_ilp32.c
create mode 100644 arch/arm64/kernel/vdso-ilp32/.gitignore
create mode 100644 arch/arm64/kernel/vdso-ilp32/Makefile
create mode 100644 arch/arm64/kernel/vdso-ilp32/vdso-ilp32.S
create mode 100644 arch/arm64/kernel/vdso-ilp32/vdso-ilp32.lds.S
create mode 100644 include/linux/thread_bits.h
--
2.11.0
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
[not found] <CAMj-D2DO_CfvD77izsGfggoKP45HSC9aD6auUPAYC9Yeq_aX7w@mail.gmail.com>
@ 2017-05-04 16:44 ` gengdongjiu
0 siblings, 0 replies; 732+ messages in thread
From: gengdongjiu @ 2017-05-04 16:44 UTC (permalink / raw)
To: linux-arm-kernel
Dear James,
Thanks a lot for your review and comments. I am very sorry for the
late response.
2017-05-04 23:42 GMT+08:00 gengdongjiu <gengdj.1984@gmail.com>:
> Hi Dongjiu Geng,
>
> On 30/04/17 06:37, Dongjiu Geng wrote:
>> when happen SEA, deliver signal bus and handle the ioctl that
>> inject SEA abort to guest, so that guest can handle the SEA error.
>
>> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
>> index 105b6ab..a96594f 100644
>> --- a/arch/arm/kvm/mmu.c
>> +++ b/arch/arm/kvm/mmu.c
>> @@ -20,8 +20,10 @@
>> @@ -1238,6 +1240,36 @@ static void coherent_cache_guest_page(struct kvm_vcpu *vcpu, kvm_pfn_t pfn,
>> __coherent_cache_guest_page(vcpu, pfn, size);
>> }
>>
>> +static void kvm_send_signal(unsigned long address, bool hugetlb, bool hwpoison)
>> +{
>> + siginfo_t info;
>> +
>> + info.si_signo = SIGBUS;
>> + info.si_errno = 0;
>> + if (hwpoison)
>> + info.si_code = BUS_MCEERR_AR;
>> + else
>> + info.si_code = 0;
>> +
>> + info.si_addr = (void __user *)address;
>> + if (hugetlb)
>> + info.si_addr_lsb = PMD_SHIFT;
>> + else
>> + info.si_addr_lsb = PAGE_SHIFT;
>> +
>> + send_sig_info(SIGBUS, &info, current);
>> +}
>> +
> ? [hide part of quote]
>
> Punit reviewed the other version of this patch, this PMD_SHIFT is not the right
> thing to do, it needs a more accurate set of calls and shifts as there may be
> hugetlbfs pages other than PMD_SIZE.
>
> https://www.spinics.net/lists/arm-kernel/msg568919.html
>
> I haven't posted a new version of that patch because I was still hunting a bug
> in the hugepage/hwpoison code, even with Punit's fixes series I see -EFAULT
> returned to userspace instead of this hwpoison code being invoked.
Ok, got it, thanks for your information.
>
> Please avoid duplicating functionality between patches, it wastes reviewers
> time, especially when we know there are problems with this approach.
>
>
>> +static void kvm_handle_bad_page(unsigned long address,
>> + bool hugetlb, bool hwpoison)
>> +{
>> + /* handle both hwpoison and other synchronous external Abort */
>> + if (hwpoison)
>> + kvm_send_signal(address, hugetlb, true);
>> + else
>> + kvm_send_signal(address, hugetlb, false);
>> +}
>
> Why the extra level of indirection? We only want to signal userspace like this
> from KVM for hwpoison. Signals for RAS related reasons should come from the bits
> of the kernel that decoded the error.
For the SEA, the are maily two types:
0b010000 Synchronous External Abort on memory access.
0b0101xx Synchronous External Abort on page table walk. DFSC[1:0]
encode the level.
hwpoison should belong to the "Synchronous External Abort on memory access"
if the SEA type is not hwpoison, such as page table walk, do you mean
KVM do not deliver the SIGBUS?
If so, how the KVM handle the SEA type other than hwpoison?
>
> (hwpoison for KVM is a corner case as Qemu's memory effectively has two users,
> Qemu and KVM. This isn't the example of how user-space gets signalled.)
>
>
>> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
>> index b37446a..780e3c4 100644
>> --- a/arch/arm64/kvm/guest.c
>> +++ b/arch/arm64/kvm/guest.c
>> @@ -277,6 +277,13 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
>> return -EINVAL;
>> }
>>
>> +int kvm_vcpu_ioctl_sea(struct kvm_vcpu *vcpu)
>> +{
>> + kvm_inject_dabt(vcpu, kvm_vcpu_get_hfar(vcpu));
>> +
>> + return 0;
>> +}
>
>> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
>> index bb02909..1d2e2e7 100644
>> --- a/include/uapi/linux/kvm.h
>> +++ b/include/uapi/linux/kvm.h
>> @@ -1306,6 +1306,7 @@ struct kvm_s390_ucas_mapping {
>> #define KVM_S390_GET_IRQ_STATE _IOW(KVMIO, 0xb6, struct kvm_s390_irq_state)
>> /* Available with KVM_CAP_X86_SMM */
>> #define KVM_SMI _IO(KVMIO, 0xb7)
>> +#define KVM_ARM_SEA _IO(KVMIO, 0xb8)
>>
>> #define KVM_DEV_ASSIGN_ENABLE_IOMMU (1 << 0)
>> #define KVM_DEV_ASSIGN_PCI_2_3 (1 << 1)
>>
>
> Why do we need a userspace API for SEA? It can also be done by using
> KVM_{G,S}ET_ONE_REG to change the vcpu registers. The advantage of doing it this
> way is you can choose which ESR value to use.
>
> Adding a new API call to do something you could do with an old one doesn't look
> right.
James, I considered your suggestion before that use the
KVM_{G,S}ET_ONE_REG to change the vcpu registers. but I found it does
not have difference to use the alread existed KVM API. so may be
changing the vcpu registers in qemu will duplicate with the KVM APIs.
injection a SEA is no more than setting some registers: elr_el1, PC,
PSTATE, SPSR_el1, far_el1, esr_el1
I seen this KVM API do the same thing as Qemu. do you found call this
API will have issue and necessary to choose another ESR value?
I pasted the alread existed KVM API code:
static void inject_abt64(struct kvm_vcpu *vcpu, bool is_iabt, unsigned
long addr)
{
unsigned long cpsr = *vcpu_cpsr(vcpu);
bool is_aarch32 = vcpu_mode_is_32bit(vcpu);
u32 esr = 0;
*vcpu_elr_el1(vcpu) = *vcpu_pc(vcpu);
*vcpu_pc(vcpu) = get_except_vector(vcpu, except_type_sync);
*vcpu_cpsr(vcpu) = PSTATE_FAULT_BITS_64;
*vcpu_spsr(vcpu) = cpsr;
vcpu_sys_reg(vcpu, FAR_EL1) = addr;
/*
* Build an {i,d}abort, depending on the level and the
* instruction set. Report an external synchronous abort.
*/
if (kvm_vcpu_trap_il_is32bit(vcpu))
esr |= ESR_ELx_IL;
/*
* Here, the guest runs in AArch64 mode when in EL1. If we get
* an AArch32 fault, it means we managed to trap an EL0 fault.
*/
if (is_aarch32 || (cpsr & PSR_MODE_MASK) == PSR_MODE_EL0t)
esr |= (ESR_ELx_EC_IABT_LOW << ESR_ELx_EC_SHIFT);
else
esr |= (ESR_ELx_EC_IABT_CUR << ESR_ELx_EC_SHIFT);
if (!is_iabt)
esr |= ESR_ELx_EC_DABT_LOW << ESR_ELx_EC_SHIFT;
vcpu_sys_reg(vcpu, ESR_EL1) = esr | ESR_ELx_FSC_EXTABT;
}
static void inject_abt32(struct kvm_vcpu *vcpu, bool is_pabt,
unsigned long addr)
{
u32 vect_offset;
u32 *far, *fsr;
bool is_lpae;
if (is_pabt) {
vect_offset = 12;
far = &vcpu_cp15(vcpu, c6_IFAR);
fsr = &vcpu_cp15(vcpu, c5_IFSR);
} else { /* !iabt */
vect_offset = 16;
far = &vcpu_cp15(vcpu, c6_DFAR);
fsr = &vcpu_cp15(vcpu, c5_DFSR);
}
prepare_fault32(vcpu, COMPAT_PSR_MODE_ABT | COMPAT_PSR_A_BIT, vect_offset);
*far = addr;
/* Give the guest an IMPLEMENTATION DEFINED exception */
is_lpae = (vcpu_cp15(vcpu, c2_TTBCR) >> 31);
if (is_lpae)
*fsr = 1 << 9 | 0x34;
else
*fsr = 0x14;
}
/**
* kvm_inject_dabt - inject a data abort into the guest
* @vcpu: The VCPU to receive the undefined exception
* @addr: The address to report in the DFAR
*
* It is assumed that this code is called from the VCPU thread and that the
* VCPU therefore is not currently executing guest code.
*/
void kvm_inject_dabt(struct kvm_vcpu *vcpu, unsigned long addr)
{
if (!(vcpu->arch.hcr_el2 & HCR_RW))
inject_abt32(vcpu, false, addr);
else
inject_abt64(vcpu, false, addr);
}
>
>
> Thanks,
>
> James
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2017-04-21 23:23 Sandeep Mann
0 siblings, 0 replies; 732+ messages in thread
From: Sandeep Mann @ 2017-04-21 23:23 UTC (permalink / raw)
Adding linux-nvme at lists.infradead.org
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2017-04-21 4:59 wendyqzx at gmail.com
0 siblings, 0 replies; 732+ messages in thread
From: wendyqzx at gmail.com @ 2017-04-21 4:59 UTC (permalink / raw)
To: linux-security-module
A non-text attachment was scrubbed...
Name: EMAIL_2700592_linux-security-module.zip
Type: application/zip
Size: 2164 bytes
Desc: not available
URL: <http://kernsec.org/pipermail/linux-security-module-archive/attachments/20170421/b9d2e23c/attachment.zip>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2017-04-16 15:11 wendyqzx at gmail.com
0 siblings, 0 replies; 732+ messages in thread
From: wendyqzx at gmail.com @ 2017-04-16 15:11 UTC (permalink / raw)
To: linux-security-module
A non-text attachment was scrubbed...
Name: EMAIL_8910011500_linux-security-module.zip
Type: application/zip
Size: 2039 bytes
Desc: not available
URL: <http://kernsec.org/pipermail/linux-security-module-archive/attachments/20170416/2cb101ce/attachment.zip>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2017-04-09 10:46 76564 at max.arc.nasa.gov
0 siblings, 0 replies; 732+ messages in thread
From: 76564 at max.arc.nasa.gov @ 2017-04-09 10:46 UTC (permalink / raw)
To: linux-security-module
A non-text attachment was scrubbed...
Name: REPORT_876578354678929_linux-security-module.zip
Type: application/zip
Size: 67873 bytes
Desc: not available
URL: <http://kernsec.org/pipermail/linux-security-module-archive/attachments/20170409/8f34a4d7/attachment.zip>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
2017-02-07 0:22 Scott Bauer
@ 2017-02-07 0:46 ` Jens Axboe
0 siblings, 0 replies; 732+ messages in thread
From: Jens Axboe @ 2017-02-07 0:46 UTC (permalink / raw)
On 02/06/2017 05:22 PM, Scott Bauer wrote:
> I screwed up and had size_t's in the uapi structures which of course
> differ in size on 32 and 64 bit platforms. This caused issues running
> 32 bit userland on a 64 bit kernel. We're hoping to sneak this
> patch in so we don't have to maintain a compat layer.
I'll apply it - you forgot to add a Fixes, always do that when a patch
fixes something that a specific commit introduced.
--
Jens Axboe
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2017-02-07 0:22 Scott Bauer
2017-02-07 0:46 ` Jens Axboe
0 siblings, 1 reply; 732+ messages in thread
From: Scott Bauer @ 2017-02-07 0:22 UTC (permalink / raw)
I screwed up and had size_t's in the uapi structures which of course
differ in size on 32 and 64 bit platforms. This caused issues running
32 bit userland on a 64 bit kernel. We're hoping to sneak this
patch in so we don't have to maintain a compat layer.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2017-01-31 7:58 Andy Gross
0 siblings, 0 replies; 732+ messages in thread
From: Andy Gross @ 2017-01-31 7:58 UTC (permalink / raw)
To: linux-arm-kernel
Subject: [Patch v5 0/2] Support ARM SMCC SoC vendor quirks
At least one SoC vendor (Qualcomm) requires additional processing done
during ARM SMCCC calls. As such, an additional parameter to the
arm_smccc_smc is required to be able to handle SoC specific quirks.
The Qualcomm quirk is necessary due to the fact that the scm call can
be interrupted on Qualcomm ARM64 platforms. When this occurs, the
call must be restarted using information that was passed back during
the original smc call.
The first patch in this series adds a quirk structure and also adds a
quirk parameter to arm_smccc_smc calls. I added macros to allow users
to choose the API they need. This keeps all of the current users who
do not need quirks from having to change anything.
The second patch adds the Qualcomm quirk and also implements the
Qualcomm firmware changes required to handle the restarting of the
interrupted SMC call.
The original patch set for the SMCCC session ID is located at:
https://lkml.org/lkml/2016/8/20/7
Changes from v4:
- Fix issue with hvc calls.
Changes from v3:
- Fix documentation
Changes from v2:
- Use variadic macros
Changes from v1:
- Add macros to handle both use cases per review comments
Andy Gross (2):
arm: kernel: Add SMC structure parameter
firmware: qcom: scm: Fix interrupted SCM calls
arch/arm/kernel/armksyms.c | 2 +-
arch/arm/kernel/smccc-call.S | 7 ++++---
arch/arm64/kernel/arm64ksyms.c | 2 +-
arch/arm64/kernel/asm-offsets.c | 7 +++++--
arch/arm64/kernel/smccc-call.S | 22 ++++++++++++++++------
drivers/firmware/qcom_scm-64.c | 13 ++++++++++---
include/linux/arm-smccc.h | 38 +++++++++++++++++++++++++++++++-------
7 files changed, 68 insertions(+), 23 deletions(-)
--
1.9.1
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
2017-01-13 10:46 ` [PATCH v3 0/8] " Nicolas Dichtel
2017-01-13 15:36 ` No subject David Howells
@ 2017-01-13 15:43 ` David Howells
1 sibling, 0 replies; 732+ messages in thread
From: David Howells @ 2017-01-13 15:43 UTC (permalink / raw)
To: linux-snps-arc
> -header-y += msr-index.h
I see it on my desktop as /usr/include/asm/msr-index.h and it's been there at
least four years - and as such it's part of the UAPI. I don't think you can
remove it unless you can guarantee there are no userspace users.
David
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
2017-01-13 10:46 ` [PATCH v3 0/8] " Nicolas Dichtel
@ 2017-01-13 15:36 ` David Howells
2017-01-13 15:43 ` David Howells
1 sibling, 0 replies; 732+ messages in thread
From: David Howells @ 2017-01-13 15:36 UTC (permalink / raw)
To: linux-snps-arc
Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
> This header file is exported, thus move it to uapi.
Exported how?
> +#ifdef __INT32_TYPE__
> +#undef __INT32_TYPE__
> +#define __INT32_TYPE__ int
> +#endif
> +
> +#ifdef __UINT32_TYPE__
> +#undef __UINT32_TYPE__
> +#define __UINT32_TYPE__ unsigned int
> +#endif
> +
> +#ifdef __UINTPTR_TYPE__
> +#undef __UINTPTR_TYPE__
> +#define __UINTPTR_TYPE__ unsigned long
> +#endif
These weren't defined by the kernel before, so why do we need to define them
now?
Will defining __UINTPTR_TYPE__ cause problems in compiling libboost by
changing the signature on C++ functions that use uintptr_t?
David
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2016-12-01 10:00 Ramana Radhakrishnan
0 siblings, 0 replies; 732+ messages in thread
From: Ramana Radhakrishnan @ 2016-12-01 10:00 UTC (permalink / raw)
To: linux-arm-kernel
>
> By the way, how is this implemented? Some of them overlap existing
> callee-saved registers.
The AArch64 PCS requires that only the bottom 64 bits of SIMD
registers (v8-v15) are callee-saved. The top 64 bits of the current
Advanced SIMD registers are the responsibility of the caller. This
naturally extends to SVE.
Ramana
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2016-11-19 18:31 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2016-11-19 18:31 UTC (permalink / raw)
To: ath9k-devel
80 /* Enable radar pulse detection if on a DFS channel. Spectral
81 * scanning and radar detection can not be used concurrently.
82 */
83 if (hw->conf.radar_enabled) {
84 u32 rxfilter;
85
86 rxfilter = ath9k_hw_getrxfilter(ah);
87 rxfilter |= ATH9K_RX_FILTER_PHYRADAR |
88 ATH9K_RX_FILTER_PHYERR;
89 ath9k_hw_setrxfilter(ah, rxfilter);
90 ath_dbg(common, DFS, "DFS enabled at freq %d\n",
91 chan->center_freq);
92 } else {
93 /* perform spectral scan if requested. */
94 if (test_bit(ATH_OP_SCANNING, &common->op_flags) &&
95 sc->spec_priv.spectral_mode == SPECTRAL_CHANSCAN)
96 ath9k_cmn_spectral_scan_trigger(common, &sc->spec_priv);
97 }
it seems that spectral can't ever be activated while operating on a DFS channel.
If you need to catch the opposite case, i.e. prevent feeding pseudo-radar pulses
into the pattern detector, you just need to ensure that they depend on
hw->conf.radar_enabled. A patch like the attached one should be enough.
Cheers,
Zefir
--------------81DB7B8680E9662AC7B071A0
Content-Type: text/x-patch;
name="0001-ath9k-feed-DFS-detector-only-if-operating-on-radar-c.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename*0="0001-ath9k-feed-DFS-detector-only-if-operating-on-radar-c.pa";
filename*1="tch"
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2016-11-19 18:31 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2016-11-19 18:31 UTC (permalink / raw)
To: ath9k-devel
behaviour. The biggest problem seems to be that the
ath9k_hw_set_sta_beacon_timers function is never called, so once the
hardware enters the PS mode there is no hardware trigger to wake up
the hardware. However, there is a mac80211 beacon loss software timer
is the one that wakes up the hardware after 7 lost beacon.
Could you provide me more details about the link between Power Save
Mode and the hardware triggers/sleep registers from
ath9k_hw_set_sta_beacon_timers?
The ath9k_hw_set_sta_beacon_timers should be called every time a
beacon is received, right?
[1] http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath9k/hw.c?v=4.3#L2269
[2] http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath9k/main.c#L486
[3] http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c?v=2.6.35#L639
> BR
> Janusz
>
>> Thanks,
>> Doru
>> _______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel at lists.ath9k.org
>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2016-11-19 18:31 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2016-11-19 18:31 UTC (permalink / raw)
To: ath9k-devel
"""
Since ADC was not designed to be a dedicated HW RNG, we do not want to
bind it to /dev/hwrng framework directly.
"""
> Where is the description of the RNG, where is the test implementation?
> >
> > Otherwise, your patch will cause high CPU load, as continuously read ADC
> > data if entropy bits under write_wakeup_threshold.
>
> The issue is that although you may have analyzed it, others are unable to
> measure the quality of the RNG and assess the design as well as the
> implementation of the RNG. This RNG is the only implementation of a hardware
> RNG that per default and without being able to change it at runtime injects
> data into the input_pool where the noise source cannot be audited. Note, even
> other respected RNG noise sources like the Intel RDRAND will not feed into /
> dev/random per default in a way that dominates all other noise sources.
>
> I would like to be able to deactivate that noise source to the extent that it
> does not cause /dev/random to unblock. The reason is that your noise source
> starts to dominate all other noise sources.
I think the short-term problem here is the config logic:
config ATH9K_HWRNG
bool "Random number generator support"
depends on ATH9K && (HW_RANDOM = y || HW_RANDOM = ATH9K)
default y
If you have *any* hwrngs you want to use and you have an ath9k card
(HW_RANDOM = y and ATH9K != n), you get the behavior Stephan is pointing
out.
Short term, we should just default no here.
> If you think that this patch is a challenge because your driver starts to
> spin, please help and offer another solution.
Well, I don't buy the reasoning listed above for not using the hwrng
framework. Interrupt timings were never designed to be a source of entropy
either. We need to grab it where ever we can find it, especially on
embedded systems. Documentation/hw_random.txt even says:
"""
This data is NOT CHECKED by any fitness tests, and could potentially be
bogus (if the hardware is faulty or has been tampered with).
"""
I really don't think there's a problem with adding these sorts of
sources under char/hw_random/. I think the only thing we would be
concerned about, other than the already addressed entropy estimation,
would be constraining the data rate.
Is ath9k the only wireless card that exposes ADC registers? What about
sound cards?
thx,
Jason.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2016-11-19 18:31 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2016-11-19 18:31 UTC (permalink / raw)
To: ath9k-devel
"""
Since ADC was not designed to be a dedicated HW RNG, we do not want to bind=
it to /dev/hwrng framework directly.
"""
> Where is the description of the RNG, where is the test implementation?=20
> >=20
> > Otherwise, your patch will cause high CPU load, as continuously=20
> > read ADC data if entropy bits under write_wakeup_threshold.
>=20
> The issue is that although you may have analyzed it, others are unable=20
> to measure the quality of the RNG and assess the design as well as the=20
> implementation of the RNG. This RNG is the only implementation of a=20
> hardware RNG that per default and without being able to change it at=20
> runtime injects data into the input_pool where the noise source cannot=20
> be audited. Note, even other respected RNG noise sources like the=20
> Intel RDRAND will not feed into / dev/random per default in a way that do=
minates all other noise sources.
>=20
> I would like to be able to deactivate that noise source to the extent=20
> that it does not cause /dev/random to unblock. The reason is that your=20
> noise source starts to dominate all other noise sources.
I think the short-term problem here is the config logic:
config ATH9K_HWRNG
bool "Random number generator support"
depends on ATH9K && (HW_RANDOM =3D y || HW_RANDOM =3D ATH9K)
default y
If you have *any* hwrngs you want to use and you have an ath9k card (HW_RAN=
DOM =3D y and ATH9K !=3D n), you get the behavior Stephan is pointing out.
Short term, we should just default no here.
> If you think that this patch is a challenge because your driver starts=20
> to spin, please help and offer another solution.
Well, I don't buy the reasoning listed above for not using the hwrng framew=
ork. Interrupt timings were never designed to be a source of entropy eithe=
r. We need to grab it where ever we can find it, especially on embedded sy=
stems. Documentation/hw_random.txt even says:
"""
This data is NOT CHECKED by any fitness tests, and could potentially be bog=
us (if the hardware is faulty or has been tampered with).
"""
I really don't think there's a problem with adding these sorts of sources u=
nder char/hw_random/. I think the only thing we would be concerned about, =
other than the already addressed entropy estimation, would be constraining =
the data rate.
Is ath9k the only wireless card that exposes ADC registers? What about sou=
nd cards?
thx,
Jason.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2016-11-11 3:38 Chunyan Zhang
0 siblings, 0 replies; 732+ messages in thread
From: Chunyan Zhang @ 2016-11-11 3:38 UTC (permalink / raw)
To: linux-arm-kernel
Hi Steven,
On 21 October 2016 at 20:13, Chunyan Zhang <zhang.chunyan@linaro.org> wrote:
> On 18 October 2016 at 23:44, Steven Rostedt <rostedt@goodmis.org> wrote:
>> On Tue, 18 Oct 2016 16:08:58 +0800
>> Chunyan Zhang <zhang.chunyan@linaro.org> wrote:
>>
>>> Currently Function traces can be only exported to ring buffer, this
>>> patch added trace_export concept which can process traces and export
>>> them to a registered destination as an addition to the current only
>>> one output of Ftrace - i.e. ring buffer.
>>>
>>> In this way, if we want Function traces to be sent to other destination
>>> rather than ring buffer only, we just need to register a new trace_export
>>> and implement its own .write() function for writing traces to storage.
>>>
>>> With this patch, only Function trace (trace type is TRACE_FN)
>>> is supported.
>>
>> This is getting better, but I still have some nits.
>>
>
> Thanks.
>
>>>
>>> Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org>
>>> ---
>>> include/linux/trace.h | 28 +++++++++++
>>> kernel/trace/trace.c | 132 +++++++++++++++++++++++++++++++++++++++++++++++++-
>>> 2 files changed, 159 insertions(+), 1 deletion(-)
>>> create mode 100644 include/linux/trace.h
>>>
>>> diff --git a/include/linux/trace.h b/include/linux/trace.h
>>> new file mode 100644
>>> index 0000000..eb1c5b8
>>> --- /dev/null
>>> +++ b/include/linux/trace.h
>>> @@ -0,0 +1,28 @@
>>> +#ifndef _LINUX_TRACE_H
>>> +#define _LINUX_TRACE_H
>>> +
>>> +#ifdef CONFIG_TRACING
>>> +/*
>>> + * The trace export - an export of Ftrace output. The trace_export
>>> + * can process traces and export them to a registered destination as
>>> + * an addition to the current only output of Ftrace - i.e. ring buffer.
>>> + *
>>> + * If you want traces to be sent to some other place rather than ring
>>> + * buffer only, just need to register a new trace_export and implement
>>> + * its own .write() function for writing traces to the storage.
>>> + *
>>> + * next - pointer to the next trace_export
>>> + * write - copy traces which have been delt with ->commit() to
>>> + * the destination
>>> + */
>>> +struct trace_export {
>>> + struct trace_export __rcu *next;
>>> + void (*write)(const char *, unsigned int);
>>
>> Why const char*? Why not const void *? This will never be a string.
>>
>
> Will revise this.
>
>>
>>> +};
>>> +
>>> +int register_ftrace_export(struct trace_export *export);
>>> +int unregister_ftrace_export(struct trace_export *export);
>>> +
>>> +#endif /* CONFIG_TRACING */
>>> +
>>> +#endif /* _LINUX_TRACE_H */
>>> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
>>> index 8696ce6..db94ec1 100644
>>> --- a/kernel/trace/trace.c
>>> +++ b/kernel/trace/trace.c
>>> @@ -40,6 +40,7 @@
>>> #include <linux/poll.h>
>>> #include <linux/nmi.h>
>>> #include <linux/fs.h>
>>> +#include <linux/trace.h>
>>> #include <linux/sched/rt.h>
>>>
>>> #include "trace.h"
>>> @@ -2128,6 +2129,132 @@ void trace_buffer_unlock_commit_regs(struct trace_array *tr,
>>> ftrace_trace_userstack(buffer, flags, pc);
>>> }
>>>
>>> +static void
>>> +trace_process_export(struct trace_export *export,
>>> + struct ring_buffer_event *event)
>>> +{
>>> + struct trace_entry *entry;
>>> + unsigned int size = 0;
>>> +
>>> + entry = ring_buffer_event_data(event);
>>> +
>>> + size = ring_buffer_event_length(event);
>>> +
>>> + if (export->write)
>>> + export->write((char *)entry, size);
>>
>> Is there ever going to be a time where export->write wont be set?
>
> There hasn't been since only one trace_export (i.e. stm_ftrace) was
> added in this patch-set , I just wanted to make sure the write() has
> been set before registering trace_export like what I added in 2/3 of
> this series.
>
>>
>> And if there is, this can be racy. As in
>>
>>
>> CPU 0: CPU 1:
>> ------ ------
>> if (export->write)
>>
>> export->write = NULL;
>
> Is there going to be this kind of use case? Why some one needs to
> change export->write() rather than register a new trace_export?
>
> I probably haven't understood your point thoroughly, please correct me
> if my guess was wrong.
>
Any further comments? :)
Thanks,
Chunyan
>
> Thanks for the review,
> Chunyan
>
>>
>> export->write(entry, size);
>>
>> BOOM!
>>
>>
>> -- Steve
>>
>>> +}
>>> +
>>> +static DEFINE_MUTEX(ftrace_export_lock);
>>> +
>>> +static struct trace_export __rcu *ftrace_exports_list __read_mostly;
>>> +
>>> +static DEFINE_STATIC_KEY_FALSE(ftrace_exports_enabled);
>>> +
>>> +static inline void ftrace_exports_enable(void)
>>> +{
>>> + static_branch_enable(&ftrace_exports_enabled);
>>> +}
>>> +
>>> +static inline void ftrace_exports_disable(void)
>>> +{
>>> + static_branch_disable(&ftrace_exports_enabled);
>>> +}
>>> +
>>> +void ftrace_exports(struct ring_buffer_event *event)
>>> +{
>>> + struct trace_export *export;
>>> +
>>> + preempt_disable_notrace();
>>> +
>>> + export = rcu_dereference_raw_notrace(ftrace_exports_list);
>>> + while (export) {
>>> + trace_process_export(export, event);
>>> + export = rcu_dereference_raw_notrace(export->next);
>>> + }
>>> +
>>> + preempt_enable_notrace();
>>> +}
>>> +
>>> +static inline void
>>> +add_trace_export(struct trace_export **list, struct trace_export *export)
>>> +{
>>> + rcu_assign_pointer(export->next, *list);
>>> + /*
>>> + * We are entering export into the list but another
>>> + * CPU might be walking that list. We need to make sure
>>> + * the export->next pointer is valid before another CPU sees
>>> + * the export pointer included into the list.
>>> + */
>>> + rcu_assign_pointer(*list, export);
>>> +}
>>> +
>>> +static inline int
>>> +rm_trace_export(struct trace_export **list, struct trace_export *export)
>>> +{
>>> + struct trace_export **p;
>>> +
>>> + for (p = list; *p != NULL; p = &(*p)->next)
>>> + if (*p == export)
>>> + break;
>>> +
>>> + if (*p != export)
>>> + return -1;
>>> +
>>> + rcu_assign_pointer(*p, (*p)->next);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static inline void
>>> +add_ftrace_export(struct trace_export **list, struct trace_export *export)
>>> +{
>>> + if (*list == NULL)
>>> + ftrace_exports_enable();
>>> +
>>> + add_trace_export(list, export);
>>> +}
>>> +
>>> +static inline int
>>> +rm_ftrace_export(struct trace_export **list, struct trace_export *export)
>>> +{
>>> + int ret;
>>> +
>>> + ret = rm_trace_export(list, export);
>>> + if (*list == NULL)
>>> + ftrace_exports_disable();
>>> +
>>> + return ret;
>>> +}
>>> +
>>> +int register_ftrace_export(struct trace_export *export)
>>> +{
>>> + if (WARN_ON_ONCE(!export->write))
>>> + return -1;
>>> +
>>> + mutex_lock(&ftrace_export_lock);
>>> +
>>> + add_ftrace_export(&ftrace_exports_list, export);
>>> +
>>> + mutex_unlock(&ftrace_export_lock);
>>> +
>>> + return 0;
>>> +}
>>> +EXPORT_SYMBOL_GPL(register_ftrace_export);
>>> +
>>> +int unregister_ftrace_export(struct trace_export *export)
>>> +{
>>> + int ret;
>>> +
>>> + mutex_lock(&ftrace_export_lock);
>>> +
>>> + ret = rm_ftrace_export(&ftrace_exports_list, export);
>>> +
>>> + mutex_unlock(&ftrace_export_lock);
>>> +
>>> + return ret;
>>> +}
>>> +EXPORT_SYMBOL_GPL(unregister_ftrace_export);
>>> +
>>> void
>>> trace_function(struct trace_array *tr,
>>> unsigned long ip, unsigned long parent_ip, unsigned long flags,
>>> @@ -2146,8 +2273,11 @@ trace_function(struct trace_array *tr,
>>> entry->ip = ip;
>>> entry->parent_ip = parent_ip;
>>>
>>> - if (!call_filter_check_discard(call, entry, buffer, event))
>>> + if (!call_filter_check_discard(call, entry, buffer, event)) {
>>> + if (static_branch_unlikely(&ftrace_exports_enabled))
>>> + ftrace_exports(event);
>>> __buffer_unlock_commit(buffer, event);
>>> + }
>>> }
>>>
>>> #ifdef CONFIG_STACKTRACE
>>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2016-09-30 14:37 Maxime Ripard
0 siblings, 0 replies; 732+ messages in thread
From: Maxime Ripard @ 2016-09-30 14:37 UTC (permalink / raw)
To: linux-arm-kernel
Subject: [PATCH v5 0/5] drm: Add Support for Passive RGB to VGA bridges
Hi,
This serie is about adding support for the RGB to VGA bridge found in
the A13-Olinuxino and the CHIP VGA adapter.
Both these boards rely on an entirely passive bridge made out of
resitor ladders that do not require any initialisation. The only thing
needed is to get the timings from the screen if available (and if not,
fall back on XGA standards), set up the display pipeline to output on
the RGB bus with the proper timings, and you're done.
This serie also fixes a bunch of bugs uncovered when trying to
increase the resolution, and hence the pixel clock, of our
pipeline. It also fixes a few bugs in the DRM driver itself that went
unnoticed before.
Let me know what you think,
Maxime
Changes from v4:
- Removed unused functions
Changes from v3:
- Depends on OF in Kconfig
- Fixed typos in the driver comments
- Removed the mention of a "passive" bridge in the bindings doc
- Made the strcuture const
- Removed the nops and best_encoders implementations
- Removed the call to drm_bridge_enable in the sun4i driver
Changes from v2:
- Changed the compatible as suggested
- Rebased on top 4.8
Changes from v1:
- Switch to using a vga-connector
- Use drm_encoder bridge pointer instead of doing our own
- Report the connector status as unknown instead of connected by
default, and as connected only if we can retrieve the EDID.
- Switch to of_i2c_get_adapter by node, and put the reference when done
- Rebased on linux-next
Maxime Ripard (5):
drm/sun4i: rgb: Remove the bridge enable/disable functions
drm/bridge: Add RGB to VGA bridge support
ARM: sun5i: a13-olinuxino: Enable VGA bridge
ARM: multi_v7: enable VGA bridge
ARM: sunxi: Enable VGA bridge
.../bindings/display/bridge/rgb-to-vga-bridge.txt | 48 +++++
arch/arm/boot/dts/sun5i-a13-olinuxino.dts | 54 +++++
arch/arm/configs/multi_v7_defconfig | 1 +
arch/arm/configs/sunxi_defconfig | 1 +
drivers/gpu/drm/bridge/Kconfig | 7 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/rgb-to-vga.c | 229 +++++++++++++++++++++
drivers/gpu/drm/sun4i/sun4i_rgb.c | 6 -
8 files changed, 341 insertions(+), 6 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt
create mode 100644 drivers/gpu/drm/bridge/rgb-to-vga.c
--
2.9.3
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2016-07-10 9:24 ` Neil Armstrong
0 siblings, 0 replies; 732+ messages in thread
From: Neil Armstrong @ 2016-07-10 9:24 UTC (permalink / raw)
To: linux-arm-kernel
Subject: [PATCH v2 0/4] pwm: Add Amlogic Meson SoC PWM Controller
Add support for the PWM controller found in Amlogic Meson SoCs.
This controller provides a dual PWM output with 4 selectable clock source
and a two level divider to achieve a better PWM range.
Currently Meson8b and GXBB SoCs are supported.
Changes since v1 at http://lkml.kernel.org/r/1466173784-15625-1-git-send-email-narmstrong at baylibre.com :
- fix meson8b dtsi
Neil Armstrong (4):
pwm: Add support for Meson PWM Controller
dt-bindings: pwm: Add bindings for Meson PWM Controller
ARM64: dts: meson-gxbb: Add Meson GXBB PWM Controller nodes
ARM: dts: meson8b: Add Meson8b PWM Controller nodes
.../devicetree/bindings/pwm/pwm-meson.txt | 21 +
arch/arm/boot/dts/meson8b.dtsi | 21 +
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 28 ++
drivers/pwm/Kconfig | 9 +
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-meson.c | 491 +++++++++++++++++++++
6 files changed, 571 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pwm/pwm-meson.txt
create mode 100644 drivers/pwm/pwm-meson.c
--
2.7.0
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2016-07-10 9:24 ` Neil Armstrong
0 siblings, 0 replies; 732+ messages in thread
From: Neil Armstrong @ 2016-07-10 9:24 UTC (permalink / raw)
To: linus-amlogic
Subject: [PATCH v2 0/4] pwm: Add Amlogic Meson SoC PWM Controller
Add support for the PWM controller found in Amlogic Meson SoCs.
This controller provides a dual PWM output with 4 selectable clock source
and a two level divider to achieve a better PWM range.
Currently Meson8b and GXBB SoCs are supported.
Changes since v1 at http://lkml.kernel.org/r/1466173784-15625-1-git-send-email-narmstrong at baylibre.com :
- fix meson8b dtsi
Neil Armstrong (4):
pwm: Add support for Meson PWM Controller
dt-bindings: pwm: Add bindings for Meson PWM Controller
ARM64: dts: meson-gxbb: Add Meson GXBB PWM Controller nodes
ARM: dts: meson8b: Add Meson8b PWM Controller nodes
.../devicetree/bindings/pwm/pwm-meson.txt | 21 +
arch/arm/boot/dts/meson8b.dtsi | 21 +
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 28 ++
drivers/pwm/Kconfig | 9 +
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-meson.c | 491 +++++++++++++++++++++
6 files changed, 571 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pwm/pwm-meson.txt
create mode 100644 drivers/pwm/pwm-meson.c
--
2.7.0
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2016-06-13 6:24 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2016-06-13 6:24 UTC (permalink / raw)
To: ath9k-devel
seems to be effective. But I'm not sure.
And sometimes, some phase measurement show large dispalcement along y-axis
even they are captured within very short duration.
Hence the question is,
Is ath9k reports CSI with those unwanted linear phase offset removed?
If it is not, should I look into Atheros CSI tool? As I look into it, it
just captures CSI from the kernel and does not modify it.
Or, Is CSI of Atheros different form that of Intel? I don't think so...
The final goal of extracting true phase from CSI of ath9k is to determine
angle of arrival (AoA) of signal.
Regards,
Jeon.
[1]: http://pdcc.ntu.edu.sg/wands/Atheros/ "Atheros CSI Extraction Tool"
[2] K. Qian, C. Wu, Z. Yang, Y. Liu, and Z. Zhou, =E2=80=9CPADS: Passive de=
tection
of moving targets with dynamic speed using PHY layer information,=E2=80=9D =
in 2014
20th IEEE International Conference on Parallel and Distributed Systems
(ICPADS), 2014, pp. 1=E2=80=938.
[3] M. Kotaru, K. Joshi, D. Bharadia, and S. Katti, =E2=80=9CSpotFi: Decime=
ter
Level Localization Using WiFi,=E2=80=9D SIGCOMM Comput. Commun. Rev., vol. =
45, no.
4, pp. 269=E2=80=93282, Aug. 2015.
[4] http://dhalperi.github.io/linux-80211n-csitool/ "Linux 802.11n CSI
Tool"
--001a113ff17008949005352bd33e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Dear ath9k developers,<br><br>I am currently working with =
Atheros CSI Extraction Tool [1] to get a true phase of each subcarrier.<br>=
<br>- Background<br><br>[2], [3] and many other papers claim that phase inf=
ormation from extracted CSI contains two components: true phase and unwante=
d phase offset due to subcarrier and time delay.<br>i.e., measured_phase =
=3D true_phase + time_delay * subcarrier_index + phase_offset_due_to_txrx_m=
ismatch<br>This equation can be visualized as below:<br><br><a href=3D"http=
://i.imgur.com/rk9Hh1M.png">http://i.imgur.com/rk9Hh1M.png</a><br><br>(Plea=
se note that this figure is based on CSI tool for Intel 5300 NIC.)<br><br>I=
t contains unwanted linear phase offset and constant phase offset. Since th=
e true phase is relatively small, it seems that phase is monotonically incr=
easing or decreasing in macro view due to the unwanted phase offsets. We ca=
nnot see a tiny true phase currently.<div><div><br>To remove phase offset d=
ue to subcarrier, the mentioned papers are attempting to remove it with lin=
ear fitting ax + b,<br>where a =3D slope of the figure, b =3D average of me=
asured phase, and x =3D subcarrier index.<br><br>After removing unwanted ph=
ase offset components, the true phase is estimated.<br>This estimated true =
phase seems steady and consistent across a time duration shorter than < =
100 - 1000 ms:<br><br><a href=3D"http://i.imgur.com/AO89vYV.png">http://i.i=
mgur.com/AO89vYV.png</a><br><br>Note that Y-axis scale is reduece from [-50=
, 10] to [5, -3]<br><br>- My question<br><br>I want to extract and manipula=
te CSI phase WITH ATH9K NIC.<br><br>After extracting CSI from my ath9k NIC =
(AR9580 @ 2.4 GHz) with Atheros CSI extraction tool,<br>I've tried vari=
ous fitting methods to eliminate unwanted components and stacked results fr=
om nearly 100 packets:<br><br><a href=3D"http://i.imgur.com/5r9eYwO.png">ht=
tp://i.imgur.com/5r9eYwO.png</a><br><br>From the result, in short, removing=
only constant offset across subcarrier seems to be effective. But I'm =
not sure.</div><div>And sometimes, some phase measurement show large dispal=
cement along y-axis even they are captured within very short duration.<br><=
br>Hence the question is,</div><div>Is ath9k reports CSI with those unwante=
d linear phase offset removed?</div><div>If it is not, should I look into A=
theros CSI tool? As I look into it, it just captures CSI from the kernel an=
d does not modify it.</div><div>Or, Is CSI of Atheros different form that o=
f Intel? I don't think so...</div><div><br></div><div>The final goal of=
extracting true phase from CSI of ath9k is to determine angle of arrival (=
AoA) of signal.<br><br>Regards,<br>Jeon.<br><br>[1]: <a href=3D"http://pdcc=
.ntu.edu.sg/wands/Atheros/">http://pdcc.ntu.edu.sg/wands/Atheros/</a> "=
;Atheros CSI Extraction Tool"<br>[2] K. Qian, C. Wu, Z. Yang, Y. Liu, =
and Z. Zhou, =E2=80=9CPADS: Passive detection of moving targets with dynami=
c speed using PHY layer information,=E2=80=9D in 2014 20th IEEE Internation=
al Conference on Parallel and Distributed Systems (ICPADS), 2014, pp. 1=E2=
=80=938.<br>[3] M. Kotaru, K. Joshi, D. Bharadia, and S. Katti, =E2=80=9CSp=
otFi: Decimeter Level Localization Using WiFi,=E2=80=9D SIGCOMM Comput. Com=
mun. Rev., vol. 45, no. 4, pp. 269=E2=80=93282, Aug. 2015.<br>[4] <a href=
=3D"http://dhalperi.github.io/linux-80211n-csitool/">http://dhalperi.github=
.io/linux-80211n-csitool/</a> "Linux 802.11n CSI Tool"
</div></div></div>
--001a113ff17008949005352bd33e--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2016-06-13 6:24 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2016-06-13 6:24 UTC (permalink / raw)
To: ath9k-devel
assumed the frequencies and numbers were correct, which is why I
picked it up.
> Is this trying to add 4.9 GHz channels in general for multiple different
> use cases? And if so, what are those use cases? Or is this only for some
> public safety cases? And if so, for which regulatory domains?
I believe he has a client that requires this support in a Linux kernel.
> To be frank, I really don't see how this would be even close to a state
> that should be accepted into the upstream tree.
Fair enough I'm dropping this.
Kalle, I've marked this as rejected and archived on Patchwork.
Thanks,
--
Julian Calaby
Email: julian.calaby at gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
2016-04-22 8:25 Daniel Lezcano
@ 2016-04-22 8:27 ` Daniel Lezcano
0 siblings, 0 replies; 732+ messages in thread
From: Daniel Lezcano @ 2016-04-22 8:27 UTC (permalink / raw)
To: linux-arm-kernel
On 04/22/2016 10:25 AM, Daniel Lezcano wrote:
> Hi Rafael,
>
> please pull the following changes for 4.7.
>
> * Constify the cpuidle_ops structure and the types returned by the
> * functions using it (Jisheng Zhang)
Please ignore this email. I did a wrong manipulation with mutt.
Sorry for the noise.
-- Daniel
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2016-04-22 8:25 Daniel Lezcano
2016-04-22 8:27 ` Daniel Lezcano
0 siblings, 1 reply; 732+ messages in thread
From: Daniel Lezcano @ 2016-04-22 8:25 UTC (permalink / raw)
To: linux-arm-kernel
Hi Rafael,
please pull the following changes for 4.7.
* Constify the cpuidle_ops structure and the types returned by the
* functions using it (Jisheng Zhang)
Thanks !
-- Daniel
The following changes since commit c3b46c73264b03000d1e18b22f5caf63332547c9:
Linux 4.6-rc4 (2016-04-17 19:13:32 -0700)
are available in the git repository at:
http://git.linaro.org/people/daniel.lezcano/linux.git cpuidle/4.7
for you to fetch changes up to 5e7c17df795e462c70a43f1b3b670e08efefe8fd:
drivers: firmware: psci: use const and __initconst for psci_cpuidle_ops
(2016-04-20 10:44:32 +0200)
----------------------------------------------------------------
Jisheng Zhang (4):
ARM: cpuidle: add const qualifier to cpuidle_ops member in structures
ARM: cpuidle: constify return value of arm_cpuidle_get_ops()
soc: qcom: spm: Use const and __initconst for qcom_cpuidle_ops
drivers: firmware: psci: use const and __initconst for
psci_cpuidle_ops
arch/arm/include/asm/cpuidle.h | 2 +-
arch/arm/kernel/cpuidle.c | 6 +++---
drivers/firmware/psci.c | 2 +-
drivers/soc/qcom/spm.c | 2 +-
4 files changed, 6 insertions(+), 6 deletions(-)
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2016-04-11 7:51 Paul Walmsley
0 siblings, 0 replies; 732+ messages in thread
From: Paul Walmsley @ 2016-04-11 7:51 UTC (permalink / raw)
To: linux-arm-kernel
OMAP baseline test results for v4.6-rc3
Here are some basic OMAP test results for Linux v4.6-rc3.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v4.6-rc3/20160411005353/
Test summary
------------
Build: uImage:
Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only,
omap1_defconfig_5912osk_only
Build: uImage+dtb:
Pass (13/13): omap2plus_defconfig_am33xx_only/am335x-bone,
omap2plus_defconfig/omap4-panda,
omap2plus_defconfig/omap4-panda-es,
omap2plus_defconfig/omap4-var-stk-om44,
omap2plus_defconfig/omap3-evm-37xx,
omap2plus_defconfig_n800_only_a/omap2420-n800,
omap2plus_defconfig/omap2430-sdp,
omap2plus_defconfig/am3517-evm,
omap2plus_defconfig/omap3-beagle,
omap2plus_defconfig/omap3-beagle-xm,
omap2plus_defconfig/omap3-sbc-t3517,
omap2plus_defconfig/omap5-uevm,
omap2plus_defconfig/omap5-sbc-t54
Build: zImage:
Pass (18/18): omap2plus_defconfig, omap2plus_defconfig_am33xx_only,
omap2plus_defconfig_n800_only_a,
omap2plus_defconfig_n800_multi_omap2xxx,
omap2plus_defconfig_2430sdp_only,
omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm,
omap2plus_defconfig_omap2_4_only,
omap2plus_defconfig_omap3_4_only,
omap2plus_defconfig_omap5_only,
omap2plus_defconfig_dra7xx_only,
omap2plus_defconfig_am43xx_only,
omap2plus_defconfig_ti81xx_only,
rmk_omap3430_ldp_oldconfig,
rmk_omap3430_ldp_allnoconfig,
rmk_omap4430_sdp_oldconfig,
rmk_omap4430_sdp_allnoconfig, multi_v7_defconfig
Build warnings from toolchain: uImage:
(none)
Build warnings from toolchain: uImage+dtb:
(none)
Build warnings from toolchain: zImage:
FAIL (16/18): omap2plus_defconfig, omap2plus_defconfig_am33xx_only,
omap2plus_defconfig_n800_only_a,
omap2plus_defconfig_n800_multi_omap2xxx,
omap2plus_defconfig_2430sdp_only,
omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm,
omap2plus_defconfig_omap2_4_only,
omap2plus_defconfig_omap3_4_only,
omap2plus_defconfig_omap5_only,
omap2plus_defconfig_dra7xx_only,
omap2plus_defconfig_am43xx_only,
omap2plus_defconfig_ti81xx_only,
rmk_omap3430_ldp_oldconfig,
rmk_omap4430_sdp_oldconfig, multi_v7_defconfig
Boot to userspace:
FAIL ( 1/18): 2430sdp
skip ( 3/18): 5912osk, 3517evm, 5430es2sbct54
Pass (14/18): am335xbonelt, am437xsk, am335xbone, 4430es2panda,
4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle,
3530es31beagle, 3730beaglexm, 3730es12beaglexm,
cmt3517, 5430es2uevm, 2420n800
Kernel warnings during boot to userspace:
FAIL ( 2/18): 4430es2panda, cmt3517
PM: chip retention via suspend:
FAIL ( 6/11): am335xbonelt, 4430es2panda, 4460varsomom, 37xxevm,
2430sdp, 5430es2uevm
Pass ( 5/11): 4460pandaes, 3530es3beagle, 3530es31beagle,
3730beaglexm, 3730es12beaglexm
PM: chip retention via dynamic idle:
FAIL ( 8/11): am335xbonelt, 4430es2panda, 4460varsomom, 37xxevm,
3530es3beagle, 3530es31beagle, 2430sdp, 5430es2uevm
Pass ( 3/11): 4460pandaes, 3730beaglexm, 3730es12beaglexm
PM: chip off (except CORE, due to errata) via suspend:
Pass ( 1/ 1): 3730beaglexm
PM: chip off (except CORE, due to errata) via dynamic idle:
Pass ( 1/ 1): 3730beaglexm
PM: chip off via suspend:
FAIL ( 2/ 4): 37xxevm, 3530es3beagle
Pass ( 2/ 4): 3530es31beagle, 3730es12beaglexm
PM: chip off via dynamic idle:
FAIL ( 3/ 4): 37xxevm, 3530es3beagle, 3530es31beagle
Pass ( 1/ 4): 3730es12beaglexm
Kernel warnings during PM test:
FAIL ( 1/18): 4430es2panda
Obsolete Kconfig symbols:
FAIL ( 3/21): omap1_defconfig, omap2plus_defconfig,
multi_v7_defconfig
vmlinux object size
(delta in bytes from test_v4.6-rc2 (9735a22799b9214d17d3c231fe377fc852f042e9)):
text data bss total kernel
+772 -896 0 -124 omap1_defconfig
+772 -920 0 -148 omap1_defconfig_1510innovator_only
+596 -928 0 -332 omap1_defconfig_5912osk_only
-108 +64 0 -44 multi_v7_defconfig
+236 0 0 +236 omap2plus_defconfig
+976 0 0 +976 omap2plus_defconfig_2430sdp_only
+300 0 0 +300 omap2plus_defconfig_am33xx_only
+300 0 0 +300 omap2plus_defconfig_am43xx_only
+236 0 0 +236 omap2plus_defconfig_cpupm
+236 0 0 +236 omap2plus_defconfig_dra7xx_only
+388 -8 0 +380 omap2plus_defconfig_n800_multi_omap2xxx
+420 0 0 +420 omap2plus_defconfig_n800_only_a
+164 0 0 +164 omap2plus_defconfig_no_pm
+172 0 0 +172 omap2plus_defconfig_omap2_4_only
+236 0 0 +236 omap2plus_defconfig_omap3_4_only
+300 0 0 +300 omap2plus_defconfig_omap5_only
+1004 0 0 +1004 omap2plus_defconfig_ti81xx_only
+244 0 -48 +196 rmk_omap3430_ldp_allnoconfig
+3896 0 0 +3896 rmk_omap3430_ldp_oldconfig
+228 0 -48 +180 rmk_omap4430_sdp_allnoconfig
+200 0 0 +200 rmk_omap4430_sdp_oldconfig
Boot-time memory difference
(delta in bytes from test_v4.6-rc2 (9735a22799b9214d17d3c231fe377fc852f042e9))
avail rsrvd high freed board kconfig
(no differences)
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2016-03-07 17:52 nunojsa
0 siblings, 0 replies; 732+ messages in thread
From: nunojsa @ 2016-03-07 17:52 UTC (permalink / raw)
To: kernelnewbies
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2016-02-09 7:29 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2016-02-09 7:29 UTC (permalink / raw)
To: ath9k-devel
CSI Tool->
- Gives 56 complex numbers which represent the mag and phase
of the ofdm subcarriers.
- The CSI tool is listening for HT20/HT40 packets with channel sounding
bit (or bits) set so is per packet and needs a transmitter node also
- CSI is also available on some intel (sorry to mention the dirty word) chips
but you need to have specialised firmware which the kernel
and userland CSI code accesses.
SpectralScan->
- Is easier to use
- give you the phase and mag (summed) in one figure.
- don't need specialised transmitters.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2015-12-13 21:57 何旦洁
0 siblings, 0 replies; 732+ messages in thread
From: 何旦洁 @ 2015-12-13 21:57 UTC (permalink / raw)
To: linux-arm-kernel
???? iPhone
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2015-11-16 16:13 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2015-11-16 16:13 UTC (permalink / raw)
To: ath9k-devel
anything over that is cause for great concern.
Is there any other metric that you would suggest we track that would
show some issues due to wifi interference?
Is there anyway to get AR9341 datasheet?
Cheers,
Valent.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2015-10-27 0:44 xuyiping
0 siblings, 0 replies; 732+ messages in thread
From: xuyiping @ 2015-10-27 0:44 UTC (permalink / raw)
To: linux-arm-kernel
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
[not found] <E1ZqY3A-0004Mt-KH@feisty.vs19.net>
@ 2015-10-26 3:21 ` Jiada Wang
0 siblings, 0 replies; 732+ messages in thread
From: Jiada Wang @ 2015-10-26 3:21 UTC (permalink / raw)
To: linux-arm-kernel
Hello
> Subject: [PATCH v2 4/8] spi: imx: add selection for iMX53 and iMX6
controller type
>
> ECSPI contorller for iMX53 and iMX6 has few hardware issues in slave
> mode and (32*n+1) SPI word size handling comparing to iMX51.
> The change add possibility to detect the SPI controller is use and apply
> workarounds/limitations.
> Documentation for device tree bindings updated
>
> Signed-off-by: Anton Bondarenko <anton_bondarenko@mentor.com>
> ---
> .../devicetree/bindings/spi/fsl-imx-cspi.txt | 2 ++
> drivers/spi/spi-imx.c | 36 ++++++++++++++++++++--
> 2 files changed, 35 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
> index 523341a..425485f 100644
> --- a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
> +++ b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
> @@ -9,6 +9,8 @@ Required properties:
> - "fsl,imx31-cspi" for SPI compatible with the one integrated on i.MX31
> - "fsl,imx35-cspi" for SPI compatible with the one integrated on i.MX35
> - "fsl,imx51-ecspi" for SPI compatible with the one integrated on i.MX51
> + - "fsl,imx53-ecspi" for SPI compatible with the one integrated on i.MX53
> + - "fsl,imx6q-ecspi" for SPI compatible with the one integrated on i.MX6 family
> - reg : Offset and length of the register set for the device
> - interrupts : Should contain CSPI/eCSPI interrupt
> - fsl,spi-num-chipselects : Contains the number of the chipselect
> diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
> index d9b730d..41c9cef 100644
> --- a/drivers/spi/spi-imx.c
> +++ b/drivers/spi/spi-imx.c
> @@ -72,7 +72,8 @@ enum spi_imx_devtype {
> IMX27_CSPI,
> IMX31_CSPI,
> IMX35_CSPI, /* CSPI on all i.mx except above */
> - IMX51_ECSPI, /* ECSPI on i.mx51 and later */
> + IMX51_ECSPI, /* ECSPI on i.mx51 */
> + IMX53_ECSPI, /* ECSPI on i.mx53 and later */
> };
>
> struct spi_imx_data;
> @@ -129,9 +130,20 @@ static inline int is_imx35_cspi(struct spi_imx_data *d)
> return d->devtype_data->devtype == IMX35_CSPI;
> }
>
> +static inline int is_imx53_ecspi(struct spi_imx_data *d)
> +{
> + return d->devtype_data->devtype == IMX53_ECSPI;
> +}
> +
> +static inline int is_imx5x_ecspi(struct spi_imx_data *d)
> +{
> + return d->devtype_data->devtype == IMX51_ECSPI ||
> + d->devtype_data->devtype == IMX53_ECSPI;
> +}
> +
> static inline unsigned spi_imx_get_fifosize(struct spi_imx_data *d)
> {
> - return (d->devtype_data->devtype == IMX51_ECSPI) ? 64 : 8;
> + return is_imx5x_ecspi(d) ? 64 : 8;
> }
>
> #define MXC_SPI_BUF_RX(type) \
> @@ -680,6 +692,16 @@ static struct spi_imx_devtype_data imx51_ecspi_devtype_data = {
> .devtype = IMX51_ECSPI,
> };
>
> +static struct spi_imx_devtype_data imx53_ecspi_devtype_data = {
> + /* i.mx53 and later ecspi shares the functions with i.mx51 one */
> + .intctrl = mx51_ecspi_intctrl,
> + .config = mx51_ecspi_config,
> + .trigger = mx51_ecspi_trigger,
> + .rx_available = mx51_ecspi_rx_available,
> + .reset = mx51_ecspi_reset,
> + .devtype = IMX53_ECSPI,
> +};
> +
> static const struct platform_device_id spi_imx_devtype[] = {
> {
> .name = "imx1-cspi",
> @@ -697,6 +719,12 @@ static const struct platform_device_id spi_imx_devtype[] = {
> .name = "imx35-cspi",
> .driver_data = (kernel_ulong_t) &imx35_cspi_devtype_data,
> }, {
> + .name = "imx53-ecspi",
> + .driver_data = (kernel_ulong_t)&imx53_ecspi_devtype_data,
> + }, {
> + .name = "imx6q-ecspi",
> + .driver_data = (kernel_ulong_t)&imx53_ecspi_devtype_data,
> + }, {
> .name = "imx51-ecspi",
> .driver_data = (kernel_ulong_t) &imx51_ecspi_devtype_data,
> }, {
> @@ -710,6 +738,8 @@ static const struct of_device_id spi_imx_dt_ids[] = {
> { .compatible = "fsl,imx27-cspi", .data = &imx27_cspi_devtype_data, },
> { .compatible = "fsl,imx31-cspi", .data = &imx31_cspi_devtype_data, },
> { .compatible = "fsl,imx35-cspi", .data = &imx35_cspi_devtype_data, },
> + { .compatible = "fsl,imx53-ecspi", .data = &imx53_ecspi_devtype_data, },
> + { .compatible = "fsl,imx6q-ecspi", .data = &imx53_ecspi_devtype_data, },
> { .compatible = "fsl,imx51-ecspi", .data = &imx51_ecspi_devtype_data, },
> { /* sentinel */ }
> };
> @@ -1299,7 +1329,7 @@ static int spi_imx_probe(struct platform_device *pdev)
> * Only validated on i.mx6 now, can remove the constrain if validated on
> * other chips.
> */
> - if (spi_imx->devtype_data == &imx51_ecspi_devtype_data &&
> + if (is_imx5x_ecspi(spi_imx) &&
> spi_imx_sdma_init(&pdev->dev, spi_imx, master))
> dev_err(&pdev->dev, "dma setup error,use pio instead\n");
>
>
With this patch, there will still be issues with SPI controller on imx6
soc other than imx6q,
for example SPI controller on imx6sl has compatibility
"compatible = "fsl,imx6sl-ecspi", "fsl,imx51-ecspi";"
So I would suggest to update device-tree file,
for example
imx53.dtsi
"fsl,imx53-ecspi", "fsl,imx51-ecspi"; -> "fsl,imx53-ecspi";
imx6qdl.dtsi
compatible = "fsl,imx6q-ecspi", "fsl,imx51-ecspi"; -> compatible =
"fsl,imx6q-ecspi", "fsl,imx53-ecspi";
imx6sl.dtsi
compatible = "fsl,imx6sl-ecspi", "fsl,imx51-ecspi"; -> compatible =
"fsl,imx6sl-ecspi", "fsl,imx53-ecspi";
etc...
by doing this, then only compatible string "fsl,imx53-ecspi" need to be
added in driver code.
Thanks,
Jiada
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2015-10-21 6:17 Rock Lee
0 siblings, 0 replies; 732+ messages in thread
From: Rock Lee @ 2015-10-21 6:17 UTC (permalink / raw)
To: kernelnewbies
unsubscribe kernelnewbies
Regards
----
Rock Lee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20151021/6fa4734a/attachment.html
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2015-10-12 17:26 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2015-10-12 17:26 UTC (permalink / raw)
To: ath9k-devel
div>Let me know if something is not clear.<br><br></div></div></blockquote>=
<div>I am interested if you reintroduce bug that Sujith already fix in comm=
it:</div><div>ath9k: Enable HW queue control only for MCC<br></div><div><br=
></div><div>While as I understand correctly this patch disable hw queues fo=
r non-mcc (also clear IEEE80211_HW_QUEUE_CONTROL) and your</div><div><span =
style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:1=
2.8px">+=C2=A0 =C2=A0 =C2=A0 =C2=A0if (ath9k_is_chanctx_enabled())</span><b=
r></div><div><span style=3D"font-size:12.8px">+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0q =3D fi->txq;</span><br style=3D"font-size:1=
2.8px"><span style=3D"font-size:12.8px">+=C2=A0 =C2=A0 =C2=A0 =C2=A0else</s=
pan><br style=3D"font-size:12.8px"><span style=3D"font-size:12.8px">+=C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0q =3D info->hw_queue;</=
span><br></div><div><span style=3D"font-size:12.8px"><br></span></div><div>=
<span style=3D"font-size:12.8px">Use again hw_queue for standard non-mcc op=
eration.</span></div><div><span style=3D"font-size:12.8px"><br></span></div=
><div><span style=3D"font-size:12.8px">Please check this, I am sure while d=
id only simple check :)</span></div><div><span style=3D"font-size:12.8px"><=
br></span></div><div><span style=3D"font-size:12.8px">BR<br>Janusz</span></=
div><div><span style=3D"font-size:12.8px"><br></span></div><div>=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;=
padding-left:1ex"><div dir=3D"ltr"><div></div>Regards,<br></div><div class=
=3D"gmail_extra"><br clear=3D"all"><div><div><div dir=3D"ltr"><table cellsp=
acing=3D"0" cellpadding=3D"0" border=3D"0" style=3D"font-family:'Times =
New Roman'"><tbody><tr><td style=3D"width:60px;height:37px"><a href=3D"=
http://www.fon.com/" target=3D"_blank"><img src=3D"http://corp.fon.com/site=
s/default/files/filelibrary/firmafon.png" width=3D"60" height=3D"37" title=
=3D"Fon" alt=3D"Fon" border=3D"0" style=3D"border: 0px none;"></a></td></tr=
><tr><td style=3D"border-bottom-width:1px;border-bottom-style:dotted;min-wi=
dth:100px;font-family:Arial;font-size:10pt;color:rgb(51,51,51);font-weight:=
bold;padding:15px 0px 3px">Borja Salazar</td></tr><tr><td style=3D"padding:=
5px 0px 1px;font-family:Arial;font-size:7.5pt;color:rgb(102,102,102)">Firmw=
are team</td></tr><tr><td style=3D"padding:1px 0px;font-family:Arial;font-s=
ize:7.5pt;color:rgb(102,102,102)"></td></tr><tr><td style=3D"padding:1px 0p=
x;font-family:Arial;font-size:7.5pt;color:rgb(102,102,102)"></td></tr><tr><=
td style=3D"padding:1px 0px;font-family:Arial;font-size:7.5pt;color:rgb(102=
,102,102)">All information in this email is=C2=A0<a href=3D"http://corp.fon=
.com/legal/email-disclaimer" style=3D"color:rgb(102,102,102)" target=3D"_bl=
ank">confidential</a></td></tr></tbody></table></div></div></div><div><div =
class=3D"h5">
<br><div class=3D"gmail_quote">On Fri, Nov 13, 2015 at 11:33 AM, Borja Sala=
zar <span dir=3D"ltr"><<a href=3D"mailto:borja.salazar@fon.com" target=
=3D"_blank">borja.salazar at fon.com</a>></span> wrote:<br><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;b=
order-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"=
><span>When channel context is enabled, we could be<br>
stopping/awakening an incorrect queue.<br>
<br>
</span>Signed-off-by: Borja Salazar <<a href=3D"mailto:borja.salazar@fon=
.com" target=3D"_blank">borja.salazar at fon.com</a>><br>
<div><div>---<br>
=C2=A0drivers/net/wireless/ath/ath9k/xmit.c | 22 ++++++++++++----------<br>
=C2=A01 file changed, 12 insertions(+), 10 deletions(-)<br>
<br>
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/a=
th/ath9k/xmit.c<br>
index 3e3dac3..9b17a59 100644<br>
--- a/drivers/net/wireless/ath/ath9k/xmit.c<br>
+++ b/drivers/net/wireless/ath/ath9k/xmit.c<br>
@@ -147,7 +147,12 @@ static void ath_txq_skb_done(struct ath_softc *sc, str=
uct ath_txq *txq,<br>
=C2=A0{<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 struct ieee80211_tx_info *info =3D IEEE80211_SK=
B_CB(skb);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 struct ath_frame_info *fi =3D get_frame_info(sk=
b);<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0int q =3D fi->txq;<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0int q;<br>
+<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0if (ath9k_is_chanctx_enabled())<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0q =3D fi->txq;<b=
r>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0else<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0q =3D info->hw_q=
ueue;<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (q < 0)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return;<br>
@@ -158,10 +163,7 @@ static void ath_txq_skb_done(struct ath_softc *sc, str=
uct ath_txq *txq,<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (txq->stopped &&<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 txq->pending_frames < sc-&g=
t;tx.txq_max_pending[q]) {<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (ath9k_is_chanct=
x_enabled())<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0ieee80211_wake_queue(sc->hw, info->hw_queue);<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0else<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0ieee80211_wake_queue(sc->hw, q);<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ieee80211_wake_queu=
e(sc->hw, q);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 txq->stopped =3D=
false;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }<br>
=C2=A0}<br>
@@ -2299,17 +2301,17 @@ int ath_tx_start(struct ieee80211_hw *hw, struct sk=
_buff *skb,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* info are no longer valid (overwritten b=
y the ath_frame_info data.<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*/<br>
<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0q =3D skb_get_queue_mapping(skb);<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0if (ath9k_is_chanctx_enabled())<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0q =3D skb_get_queue=
_mapping(skb);<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0else<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0q =3D info->hw_q=
ueue;<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ath_txq_lock(sc, txq);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (txq =3D=3D sc->tx.txq_map[q]) {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 fi->txq =3D q;<b=
r>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (++txq->pendi=
ng_frames > sc->tx.txq_max_pending[q] &&<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 !txq-=
>stopped) {<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0if (ath9k_is_chanctx_enabled())<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ieee80211_stop_queue(sc->hw, info-=
>hw_queue);<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0else<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ieee80211_stop_queue(sc->hw, q);<b=
r>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0ieee80211_stop_queue(sc->hw, q);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 txq->stopped =3D true;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }<br>
--<br>
2.3.6<br>
<br>
</div></div></blockquote></div><br></div></div></div>
</blockquote></div><br></div></div>
--001a11444ce011feae05246a36f0--
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2015-09-18 17:23 Shraddha Barke
0 siblings, 0 replies; 732+ messages in thread
From: Shraddha Barke @ 2015-09-18 17:23 UTC (permalink / raw)
To: kernelnewbies
By mistake I made some changes to staging-next branch
Now I've reverted those changes but I'm getting this message when I
checkout to staging-next
Your branch is ahead of 'origin/staging-next' by 4 commits.
(use "git push" to publish your local commits)
How do I fix this?
Thanks in advance
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150918/82c325ad/attachment.html
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2015-09-18 4:49 Shraddha Barke
0 siblings, 0 replies; 732+ messages in thread
From: Shraddha Barke @ 2015-09-18 4:49 UTC (permalink / raw)
To: kernelnewbies
I updated my local kernel repository with all recent commits using the
following commands-
git checkout staging-next
git pull
After that when I try to compile, I'm getting an error
scripts/sign-file.c:20:25: fatal error: openssl/bio.h: No such file or
directory
#include <openssl/bio.h>
^
compilation terminated.
scripts/Makefile.host:91: recipe for target 'scripts/sign-file' failed
make[1]: *** [scripts/sign-file] Error 1
Makefile:545: recipe for target 'scripts' failed
make: *** [scripts] Error 2
What should I do to fix it?
Thanks in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150918/0617fe64/attachment.html
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
2015-09-01 14:14 Mika Penttilä
@ 2015-09-01 15:22 ` Fabio Estevam
0 siblings, 0 replies; 732+ messages in thread
From: Fabio Estevam @ 2015-09-01 15:22 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Sep 1, 2015 at 11:14 AM, Mika Penttil?
<mika.j.penttila@gmail.com> wrote:
> This one causes imx6q with debug uart connected to "schedule while
> atomic" endlessly :
Yes, I have sent a revert patch for it:
http://www.spinics.net/lists/arm-kernel/msg439995.html
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2015-09-01 14:14 Mika Penttilä
2015-09-01 15:22 ` Fabio Estevam
0 siblings, 1 reply; 732+ messages in thread
From: Mika Penttilä @ 2015-09-01 14:14 UTC (permalink / raw)
To: linux-arm-kernel
This one causes imx6q with debug uart connected to "schedule while
atomic" endlessly :
9e7b399d6528eac33a6fbfceb2b92af209c3454d is the first bad commit
commit 9e7b399d6528eac33a6fbfceb2b92af209c3454d
Author: Eduardo Valentin <edubezval@gmail.com>
Date: Tue Aug 11 10:21:20 2015 -0700
serial: imx: remove unbalanced clk_prepare
The current code attempts to prepare clk_per and clk_ipg
before using the device. However, the result is an extra
prepare call on each clock. Here is the output of uart
clocks (only uart enabled and used as console):
$ grep uart /sys/kernel/debug/clk/clk_summary
uart_serial 1 2 80000000 0 0
uart 1 2 66000000 0 0
This patch balances the calls of prepares. The result is:
$ grep uart /sys/kernel/debug/clk/clk_summary
uart_serial 1 1 80000000 0 0
uart 1 1 66000000 0 0
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: linux-serial at vger.kernel.org
Cc: linux-pm at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2015-07-22 14:05 Chunfeng Yun
0 siblings, 0 replies; 732+ messages in thread
From: Chunfeng Yun @ 2015-07-22 14:05 UTC (permalink / raw)
To: linux-arm-kernel
>From ac1e8724bfa47494223bad0af450c1a63cd2fe0c Mon Sep 17 00:00:00 2001
From: Chunfeng Yun <chunfeng.yun@mediatek.com>
Date: Wed, 22 Jul 2015 21:15:15 +0800
Subject: [PATCH 0/5] *** SUBJECT HERE ***
The patch supports MediaTek's xHCI controller.
There are some differences from xHCI spec:
1. The interval is specified in 250 * 8ns increments for Interrupt Moderation
Interval(IMODI) of the Interrupter Moderation(IMOD) register, it is 8 times as
much as that defined in xHCI spec.
2. For the value of TD Size in Normal TRB, MTK's xHCI controller defines a
number of packets that remain to be transferred for a TD after processing all
Max packets in all previous TRBs,that means don't include the current TRB's,
but in xHCI spec it includes the current ones.
3. To minimize the scheduling effort for synchronous endpoints in xHC, the MTK
architecture defines some extra SW scheduling parameters for HW. According to
these parameters provided by SW, the xHC can easily decide whether a
synchronous endpoint should be scheduled in a specific uFrame. The extra SW
scheduling parameters are put into reserved DWs in Slot and Endpoint Context.
And a bandwidth scheduler algorithm is added to support such feature.
A usb3.0 phy driver is also added which used by mt65xx SoCs platform, it
supports two usb2.0 ports and one usb3.0 port.
Change in v3:
1. implement generic phy
2. move opperations for IPPC and wakeup from phy driver to xHCI driver
3. seperate quirk functions into a single C file to fix up dependence issue
Chunfeng Yun (5):
dt-bindings: Add usb3.0 phy binding for MT65xx SoCs
dt-bindings: Add a binding for Mediatek xHCI host controller
usb: phy: add usb3.0 phy driver for mt65xx SoCs
xhci: mediatek: support MTK xHCI host controller
arm64: dts: mediatek: add xHCI & usb phy for mt8173
.../devicetree/bindings/phy/phy-mt65xx-u3.txt | 21 +
.../devicetree/bindings/usb/mt8173-xhci.txt | 50 ++
arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 15 +
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 31 +
drivers/phy/Kconfig | 9 +
drivers/phy/Makefile | 1 +
drivers/phy/phy-mt65xx-usb3.c | 426 +++++++++++
drivers/usb/host/Kconfig | 9 +
drivers/usb/host/Makefile | 4 +
drivers/usb/host/xhci-mtk-sch.c | 436 +++++++++++
drivers/usb/host/xhci-mtk.c | 836 +++++++++++++++++++++
drivers/usb/host/xhci-mtk.h | 135 ++++
drivers/usb/host/xhci-ring.c | 35 +-
drivers/usb/host/xhci.c | 19 +-
drivers/usb/host/xhci.h | 1 +
15 files changed, 2021 insertions(+), 7 deletions(-)
create mode 100644 Documentation/devicetree/bindings/phy/phy-mt65xx-u3.txt
create mode 100644 Documentation/devicetree/bindings/usb/mt8173-xhci.txt
create mode 100644 drivers/phy/phy-mt65xx-usb3.c
create mode 100644 drivers/usb/host/xhci-mtk-sch.c
create mode 100644 drivers/usb/host/xhci-mtk.c
create mode 100644 drivers/usb/host/xhci-mtk.h
--
1.8.1.1.dirty
In-Reply-To:
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2015-07-15 9:32 Yuan Yao
0 siblings, 0 replies; 732+ messages in thread
From: Yuan Yao @ 2015-07-15 9:32 UTC (permalink / raw)
To: linux-arm-kernel
This patch has been tested on Fresscale LS-1 SOCs.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2015-05-18 20:00 raghu MG
0 siblings, 0 replies; 732+ messages in thread
From: raghu MG @ 2015-05-18 20:00 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This mail is regarding Linux smp boot on ARMADA-XP MV2860
.
CPU-1 doesnt boot/go through the boot sequence & it fails to come
online & dumps this message
CPU1:failed to come online .
The CPU-1 boot register is programmed with physical address of
-->armada_xp_secondary_startup function & then cpu-0 deasserts the CPU-1.
I am using armada-xp-gp.dts with armada-xp-mv78260.dts included in it.
Any help would be appreciated.
Regards
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2015-04-21 10:18 Ard Biesheuvel
0 siblings, 0 replies; 732+ messages in thread
From: Ard Biesheuvel @ 2015-04-21 10:18 UTC (permalink / raw)
To: linux-arm-kernel
On 21 April 2015 at 12:13, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Apr 21, 2015 at 12:08:51PM +0200, Ard Biesheuvel wrote:
>> This updates the PROCINFO offset-to-setup-function fields of the
>> Thumb2 capable CPU definitions to include the Thumb bit when building
>> a Thumb2 kernel. This ensures that these function are always called
>> in the correct mode.
>
> I don't think this is necessary, in fact, I think this is positively
> regression causing.
>
> The symbol 'initfunc' is known to the assembler to be a thumb symbol.
> As we have seen already from the kernel dumps from the V7M kernel, when
> it calculates initfunc - name in a T2 kernel, the resulting value is an
> _odd_ number.
>
OK, so BSYM() uses '+ 1' rather than ' | 1'? I wasn't expecting that, sorry.
But looking at proc-v7.S again, the problem may just be the missing
ENDPROC() declarations for a couple of the setup() functions, which
explains why they are lacking the Thumb annotations.
> Using BSYM() here will increment it to be the next _even_ number, which
> is wrong as this will potentially point at either half way through a
> 32-bit T2 instruction, or the second 16-bit T2 instruction.
>
Agreed.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2015-03-30 4:56 Woody Wu
0 siblings, 0 replies; 732+ messages in thread
From: Woody Wu @ 2015-03-30 4:56 UTC (permalink / raw)
To: kernelnewbies
Hi,
I have a kernel already run on production, but I then realized that I need
to add one or two driver to it. But I hope I can avoid to upgrade the
kernel image for those already running products, I hope I can only extend
the kernel by add the driver modules to the root file system. Is that
possible? The current kernel has already compiled with the loadable modules
options, but for the drivers that I want now the old config is 'no'.
Thanks in advance.
-woody
--
Sent from Gmail Mobile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150330/28819756/attachment.html
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2015-02-26 16:56 Jorge Ramirez-Ortiz
0 siblings, 0 replies; 732+ messages in thread
From: Jorge Ramirez-Ortiz @ 2015-02-26 16:56 UTC (permalink / raw)
To: linux-arm-kernel
From: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
Subject: [PATCH v5] drivers/tty: amba: defer probing DMA availability until hw_init
In-Reply-To: [PATCH v4] drivers/tty: amba: defer probing DMA availability until hw_init
checkpatch.pl didn't catch 'struct device * const uap_dev'
resending
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2015-02-18 16:14 Lee Jones
0 siblings, 0 replies; 732+ messages in thread
From: Lee Jones @ 2015-02-18 16:14 UTC (permalink / raw)
To: linux-arm-kernel
Subject: [PATCH v2 0/4] clk: st: New clock domain
v1 => v2:
- Turned the ST specific driver into a generic one
Hardware can have a bunch of clocks which must not be turned off.
If drivers a) fail to obtain a reference to any of these or b) give
up a previously obtained reference during suspend, the common clk
framework will attempt to turn them off and the hardware will
subsequently die. The only way to recover from this failure is to
restart.
To avoid either of these two scenarios from catastrophically
disabling the running system we have implemented a clock domain
where clocks are consumed and references are taken, thus preventing
them from being shut down by the framework.
Lee Jones (4):
ARM: sti: stih407-family: Supply defines for CLOCKGEN A0
ARM: sti: stih407-family: Provide Clock Domain information
clk: Provide an always-on clock domain framework
clk: dt: Introduce always-on clock domain documentation
.../devicetree/bindings/clock/clk-domain.txt | 35 ++++++++++++
arch/arm/boot/dts/stih407-family.dtsi | 13 +++++
drivers/clk/Makefile | 1 +
drivers/clk/clkdomain.c | 63 ++++++++++++++++++++++
include/dt-bindings/clock/stih407-clks.h | 4 ++
5 files changed, 116 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/clk-domain.txt
create mode 100644 drivers/clk/clkdomain.c
--
1.9.1
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2015-01-27 16:49 Grzegorz Dwornicki
0 siblings, 0 replies; 732+ messages in thread
From: Grzegorz Dwornicki @ 2015-01-27 16:49 UTC (permalink / raw)
To: kernelnewbies
Keepalive question
Hello
I am bothered with very simple situaction. Lets say we have a TCP connection:
S1 <----> S2
Lets assume that this connection is using blocking sockets. and that
both hosts: s1 and s2 are using SO_KEEPALIVE. If they both are not
using this connection then the kernel? is sending packets with no data
to keep connection alive.
I have marked "the kernel?" because I am not sure who does this. I
think its the kernel but I am not sure.
What would happen if only one of them would use keepalive? Could that
empty packet break the loop inside of sk_busy_loop function and return
empty data to the application layer? Or would that while loop body
just re-run?
Hehe is the code (the while loop starts on 128 line)
http://lxr.oss.org.cn/source/include/net/busy_poll.h?a=arm#L95
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2014-11-10 6:39 Libo Chen
0 siblings, 0 replies; 732+ messages in thread
From: Libo Chen @ 2014-11-10 6:39 UTC (permalink / raw)
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2014-11-10 3:11 Libo Chen
0 siblings, 0 replies; 732+ messages in thread
From: Libo Chen @ 2014-11-10 3:11 UTC (permalink / raw)
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2014-10-28 14:13 Mark Rutland
0 siblings, 0 replies; 732+ messages in thread
From: Mark Rutland @ 2014-10-28 14:13 UTC (permalink / raw)
To: linux-arm-kernel
Bcc:
Subject: Re: [PATCHv4 7/7] arm64: add better page protections to arm64
Reply-To:
In-Reply-To: <1414440752-9411-8-git-send-email-lauraa@codeaurora.org>
Hi Laura,
On Mon, Oct 27, 2014 at 08:12:32PM +0000, Laura Abbott wrote:
> Add page protections for arm64 similar to those in arm.
> This is for security reasons to prevent certain classes
> of exploits. The current method:
>
> - Map all memory as either RWX or RW. We round to the nearest
> section to avoid creating page tables before everything is mapped
> - Once everything is mapped, if either end of the RWX section should
> not be X, we split the PMD and remap as necessary
> - When initmem is to be freed, we change the permissions back to
> RW (using stop machine if necessary to flush the TLB)
> - If CONFIG_DEBUG_RODATA is set, the read only sections are set
> read only.
>
> Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
> ---
> v4: Combined the Kconfig options
> ---
> arch/arm64/Kconfig.debug | 23 +++
> arch/arm64/include/asm/cacheflush.h | 4 +
> arch/arm64/kernel/vmlinux.lds.S | 17 ++
> arch/arm64/mm/init.c | 1 +
> arch/arm64/mm/mm.h | 2 +
> arch/arm64/mm/mmu.c | 303 +++++++++++++++++++++++++++++++-----
> 6 files changed, 314 insertions(+), 36 deletions(-)
With this patch applied to v3.18-rc2, my board to blows up at boot when
using UEFI (without DEBUG_RODATA selected):
---->8----
EFI stub: Booting Linux Kernel...
Initializing cgroup subsys cpu
Linux version 3.18.0-rc2+ (mark at leverpostej) (gcc version 4.9.2 20140904 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.09) ) #112 SMP PREEMPT Tue Oct 28 13:58:41 GMT 2014
CPU: AArch64 Processor [410fd030] revision 0
Detected VIPT I-cache on CPU0
bootconsole [uart0] enabled
efi: Getting EFI parameters from FDT:
EFI v2.40 by ARM Juno EFI Oct 7 2014 15:05:42
efi: ACPI=0xfebdc000 ACPI 2.0=0xfebdc014
cma: Reserved 16 MiB at fd800000
BUG: failure at arch/arm64/mm/mmu.c:234/alloc_init_pmd()!
Kernel panic - not syncing: BUG!
CPU: 0 PID: 0 Comm: swapper Not tainted 3.18.0-rc2+ #112
Call trace:
[<ffffffc000087ec8>] dump_backtrace+0x0/0x124
[<ffffffc000087ffc>] show_stack+0x10/0x1c
[<ffffffc0004ebd58>] dump_stack+0x74/0xb8
[<ffffffc0004eb018>] panic+0xe0/0x220
[<ffffffc0004e8e08>] alloc_init_pmd+0x1cc/0x1dc
[<ffffffc0004e8e3c>] alloc_init_pud+0x24/0x6c
[<ffffffc0004e8f54>] __create_mapping+0xd0/0xf0
[<ffffffc00069a0a0>] create_id_mapping+0x5c/0x68
[<ffffffc00069964c>] efi_idmap_init+0x54/0xd8
[<ffffffc0006978a8>] setup_arch+0x408/0x5c0
[<ffffffc00069566c>] start_kernel+0x94/0x3a0
---[ end Kernel panic - not syncing: BUG!
---->8----
I've not yet figured out precisely why. I haven't tried a !EFI boot
because of the way my board is set up at the moment.
Mark.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2014-09-22 19:41 Santosh Shilimkar
0 siblings, 0 replies; 732+ messages in thread
From: Santosh Shilimkar @ 2014-09-22 19:41 UTC (permalink / raw)
To: linux-arm-kernel
Subject: [GIT PULL] ARM: dts: Keystone DTS updates for 3.18
Hi Arm-soc folks,
The following changes since commit 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9:
Linux 3.17-rc1 (2014-08-16 10:40:26 -0600)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git tags/keystone-dts
for you to fetch changes up to b2ed7d98e1c7098f452cf95ab69211a2f8e02ac8:
ARM: dts: keystone: fix bindings for pcie and usb clock nodes (2014-09-22 15:19:36 -0400)
----------------------------------------------------------------
Keystone DTS updates for v3.18
- Add IRQ and GPIO nodes
- Fix SPI chip select
- Fix usb and pcie clock nodes
----------------------------------------------------------------
Grygorii Strashko (2):
ARM: dts: keystone: add keystone irq controller node
ARM: dts: keystone: add dsp gpio controllers nodes
Karicheri Muralidharan (1):
ARM: dts: keystone: k2l: Fix chip selects for SPI devices
Karicheri, Muralidharan (1):
ARM: dts: keystone: fix bindings for pcie and usb clock nodes
arch/arm/boot/dts/k2e-clocks.dtsi | 6 ++--
arch/arm/boot/dts/k2e.dtsi | 7 +++++
arch/arm/boot/dts/k2hk.dtsi | 56 +++++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/k2l.dtsi | 42 ++++++++++++++++++++++++++++
arch/arm/boot/dts/keystone.dtsi | 8 ++++++
5 files changed, 116 insertions(+), 3 deletions(-)
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2014-09-22 7:45 Jingchang Lu
0 siblings, 0 replies; 732+ messages in thread
From: Jingchang Lu @ 2014-09-22 7:45 UTC (permalink / raw)
To: linux-arm-kernel
This series contain the support for Freescale LS1021A CPU and LS1021A-QDS
and LS1021A-TWR board.
The LS1021A SoC combines two ARM Cortex-A7 cores that have been optimized
for high reliability and pack the highest level of integration available
for sub-3W embedded communications processors and with a comprehensive
enablement model focused on ease of programmability.
The LS1021A SoC shares IPs with i.MX family, Vybrid family and Freescale
PowerPC platform.
For the detail information about LS1021A SoC, please refer to the RM doc.
---
changes in v4:
add "syscon" compatible to device tree scfg and dcfg node, and
remove uncompleted dcsr related node.
remove mxc_restart reference in DT_MACHINE_START.
remove dma_zone_size defination in DT_MACHINE_START.
changes in v3:
rewrite scfg and dcfg binding doc description.
remove sai related node leaving to the driver support.
changes in v2:
remove unused nodes.
wakeup the secondary core by IPI call to u-boot standby procedure.
add dt-bindings for LS1021A SoC and platform gerenal configuration nodes.
----------------------------------------------------------------
Jingchang Lu (6):
ARM: dts: Add SoC level device tree support for LS1021A
ARM: dts: Add initial LS1021A QDS board dts support
ARM: dts: Add initial LS1021A TWR board dts support
dt-bindings: arm: add Freescale LS1021A SoC device tree binding
ARM: imx: Add initial support for Freescale LS1021A
ARM: imx: Add Freescale LS1021A SMP support
Documentation/devicetree/bindings/arm/fsl.txt | 38 ++++
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/ls1021a-qds.dts | 285 ++++++++++++++++++++++++++
arch/arm/boot/dts/ls1021a-twr.dts | 117 +++++++++++
arch/arm/boot/dts/ls1021a.dtsi | 539 ++++++++++++++++++++++++++++++++++++++++++++++++++
arch/arm/mach-imx/Kconfig | 14 ++
arch/arm/mach-imx/Makefile | 4 +-
arch/arm/mach-imx/common.h | 1 +
arch/arm/mach-imx/mach-ls1021a.c | 22 +++
arch/arm/mach-imx/platsmp.c | 32 +++
10 files changed, 1053 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/ls1021a-qds.dts
create mode 100755 arch/arm/boot/dts/ls1021a-twr.dts
create mode 100644 arch/arm/boot/dts/ls1021a.dtsi
create mode 100644 arch/arm/mach-imx/mach-ls1021a.c
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2014-09-13 19:40 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2014-09-13 19:40 UTC (permalink / raw)
To: ath9k-devel
apply patches to the ath.git tree as before and handle the patches from
there.
For ath9k and wil6210 the change is that I will be commiting the patches
instead of John and I will apply them to my wireless-drivers trees:
https://git.kernel.org/cgit/linux/kernel/git/kvalo/wireless-drivers.git/
https://git.kernel.org/cgit/linux/kernel/git/kvalo/wireless-drivers-next.git/
For ath10k and ath6kl related work I will continue to use my QCA email
address but for wireless-drivers maintainer duties I will use CAF
address.
Please let me know if there any questions. Me and John try to make this
transition as smooth as possible.
Kalle
"John W. Linville" <linville@tuxdriver.com> writes:
> Greetings,
>
> Almost 9 years ago, Jeff Garzik wrote a message on LKML detailing
> the sad state of wireless LANs in the Linux world. The point of his
> message was "So... there it is. We suck. There's hope. No Luke
> Skywalker in sight.":
>
> https://lkml.org/lkml/2006/1/5/671
>
> Shortly thereafter, I became the maintainer for wireless LANs in the
> Linux kernel:
>
> https://lkml.org/lkml/2006/1/18/377
>
> Since then, we have had a number of wireless summit meetings all around
> the world. Items were discussed, patches were merged, and friendships
> were made. Over time, we garnered support from a large range of
> wireless networking vendors. Eventually even other technologies
> were sending their patches through my trees, and I was consistently
> ranked amongst the top 10 "gate keepers" for getting changes into the
> Linux kernel. In fact, a couple of years ago I even gave a talk on
> how Linux wireless got better. It has been quite a ride!
>
> https://events.linuxfoundation.org/images/stories/pdf/lfcs2012_linville.pdf
>
> Nevertheless, I think it is time for some changes. I have been
> the wireless maintainer for a long time, and I personally would
> like to develop in a different direction. Plus, I think that Linux
> will benefit from having some fresh blood involved in more of the
> maintenance duties. I will be stepping aside to let that happen.
>
> The mac80211, bluetooth, and nfc trees have fed through me for some
> time. I am now asking these trees to send pull request directly to
> David Miller. Since these trees are managed through git, my hope is
> that they will not place any significant burden on Dave.
>
> As for the wireless driver patches, I have asked Kalle Valo
> to handle patch review and merge duties for everything under the
> drivers/net/wireless directory. This will now include not only the ath
> patches he already manages, but other drivers that don't have trees
> such as mwifiex, rt2x00, rtlwifi, and others. For consistency, the
> iwlwifi tree will also be merged through Kalle's new tree. I expect
> that Kalle will announce any relevant details in a follow-up message.
>
> The wireless-testing tree is a resource that some people value.
> I will continue to provide a wireless-testing tree. Now that tree
> will feed from the various wireless trees managed by others, probably
> with some sort of regularly scheduled pulls. Details are still to be
> determined, but the tree will still exist and will be substantially
> similar to how it has been so far.
>
> I also receive notices of new bug reports for wireless LANs on
> bugzilla.kernel.org. For now I will continue to triage those reports,
> so don't ignore me!! :-)
>
> Some may ask what I will do now -- I wish I had a specific answer.
> Immediate plans are to enjoy the coming holidays and my traditional
> year-end time away from work. After that...well, I'm sure I will
> find something to do. If you have any suggestions for good uses of
> my talents, feel free to contact me -- I'm not hard to find!
>
> In closing, I hope everyone will support Kalle and the other wireless
> maintainers at least as much as you have supported me for the past
> several years. These are good, hard working folks. You are in
> good hands!
>
> Regards,
>
> John
>
> P.S. Bonus points for anyone that finds a way for me to become a
> professional retro-computing hobbyist... :-)
--
Kalle Valo
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2014-09-13 19:40 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2014-09-13 19:40 UTC (permalink / raw)
To: ath9k-devel
phyXtpt to blink like what it does.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Hong<br>
</font></span></blockquote></div><br><br clear=3D"all"><br>-- <br><div clas=
s=3D"gmail_signature">Met vriendelijk groeten,<br>Melroy van den Berg</div>
</div>
--001a113801d2d4fad5050c853d75--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2014-09-13 19:40 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2014-09-13 19:40 UTC (permalink / raw)
To: ath9k-devel
I think WOW-enabled cards require hardware changes from the
base reference design (in your case WB222/AR9462), to receive
power when suspended.
Sujith
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2014-09-13 19:40 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2014-09-13 19:40 UTC (permalink / raw)
To: ath9k-devel
but how does the device decide to wake up? Is it based on local TSF and
beacon interval being programmed in somewhere? Or do you give it an arbitrary
TSF wake-up time somehow as in the previous devices? I noticed that in ath9k
the various generic timer aliases (e.g. TIM_TIMER) aren't even supported in
ar9003_mac.c.
--
Bob Copeland %% http://bobcopeland.com/
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
2014-08-29 14:58 ` Ravi Raj
2014-08-29 15:32 ` No subject Valdis.Kletnieks at vt.edu
@ 2014-08-29 15:34 ` Valdis.Kletnieks at vt.edu
1 sibling, 0 replies; 732+ messages in thread
From: Valdis.Kletnieks at vt.edu @ 2014-08-29 15:34 UTC (permalink / raw)
To: kernelnewbies
On Fri, 29 Aug 2014 16:58:26 +0200, Ravi Raj said:
> Thank you for the response ,So the project is a
> communication between fpga and a imx6 Arm A9 processor using SPI protocol
> and we are making a custom board for this, so first step is to find an imx6
> Arm a9 board and port linux to it and then establish SPI.
Heck, these guys already have ANdroid Kitkat up and running:
http://www.wandboard.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140829/3da056d6/attachment.bin
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
2014-08-29 14:58 ` Ravi Raj
@ 2014-08-29 15:32 ` Valdis.Kletnieks at vt.edu
2014-08-29 15:34 ` Valdis.Kletnieks at vt.edu
1 sibling, 0 replies; 732+ messages in thread
From: Valdis.Kletnieks at vt.edu @ 2014-08-29 15:32 UTC (permalink / raw)
To: kernelnewbies
On Fri, 29 Aug 2014 16:58:26 +0200, Ravi Raj said:
> so first step is to find an imx6 Arm a9 board and port linux to it
Why not get an imx6 board that already *HAS* Linux for it?
Heck, Freescale will even give you a one day CLASS on it:
http://cache.freescale.com/files/training/doc/dwf/DWF_LINUX_LABWORKBOOK.pdf
(Did you bother trying to google 'imx6 arm a9 linux'? Lots of hits, lots
of providers. ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140829/d797759c/attachment.bin
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2014-08-29 14:22 Ravi Raj
2014-08-29 14:47 ` Valdis.Kletnieks at vt.edu
0 siblings, 1 reply; 732+ messages in thread
From: Ravi Raj @ 2014-08-29 14:22 UTC (permalink / raw)
To: kernelnewbies
Hii Guys,
I am an Embedded firmware Developer,I am looking for a
Development board to port the linux kernal from scratch, could you guys
please recommend me a good development board were i can port linux from
scratch.
Cheers,
Ravi.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140829/37cc0503/attachment.html
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2014-07-09 17:49 Sebastian Andrzej Siewior
0 siblings, 0 replies; 732+ messages in thread
From: Sebastian Andrzej Siewior @ 2014-07-09 17:49 UTC (permalink / raw)
To: linux-arm-kernel
This is version three of the patch set. Unless something serious comes up
I would drop the RFC on the next post.
So far I should have everything covered up comparing to the omap-serial
driver except for the throttle callbacks. And now I would slowly start
looking into DMA support?
Sebastian
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2014-06-27 8:01 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2014-06-27 8:01 UTC (permalink / raw)
To: u-boot
> > Well, it may be unset (00:00:...) or it may be invalid (b2:a3:...).
>
> The address being not set at all, and it being set to
> 00:00:00:00:00:00, are two totally different cases, In the former,
> it's, well, not set, and in the latter it is set to an invalid
> value.
Unfortunately, that's not how the code works now. it uses 00:00: as a
marker that address is not set. (And I don't think completely redoing
the code for sake of error message is sane.)
--- a/net/eth.c
+++ b/net/eth.c
@@ -10,6 +10,7 @@
#include <net.h>
#include <miiphy.h>
#include <phy.h>
+#include <asm/errno.h>
void eth_parse_enetaddr(const char *addr, uchar *enetaddr)
{
@@ -152,6 +153,11 @@ static void eth_current_changed(void)
setenv("ethact", NULL);
}
+int eth_address_set(unsigned char *addr)
+{
+ return memcmp(addr, "\0\0\0\0\0\0", 6);
+}
+
int eth_write_hwaddr(struct eth_device *dev, const char *base_name,
int eth_number)
{
@@ -160,8 +166,8 @@ int eth_write_hwaddr(struct eth_device *dev, const char *base_name,
eth_getenv_enetaddr_by_index(base_name, eth_number, env_enetaddr);
- if (memcmp(env_enetaddr, "\0\0\0\0\0\0", 6)) {
- if (memcmp(dev->enetaddr, "\0\0\0\0\0\0", 6) &&
+ if (eth_address_set(env_enetaddr)) {
+ if (eth_address_set(dev->enetaddr) &&
memcmp(dev->enetaddr, env_enetaddr, 6)) {
printf("\nWarning: %s MAC addresses don't match:\n",
dev->name);
@@ -177,14 +183,22 @@ int eth_write_hwaddr(struct eth_device *dev, const char *base_name,
dev->enetaddr);
printf("\nWarning: %s using MAC address from net device\n",
dev->name);
+ } else if (!(eth_address_set(dev->enetaddr))) {
+ printf("\nError: %s address not set.\n",
+ dev->name);
+ return -EINVAL;
}
- if (dev->write_hwaddr &&
- !eth_mac_skip(eth_number)) {
- if (!is_valid_ether_addr(dev->enetaddr))
- return -1;
+ if (dev->write_hwaddr && !eth_mac_skip(eth_number)) {
+ if (!is_valid_ether_addr(dev->enetaddr)) {
+ printf("\nError: %s address %pM illegal value\n",
+ dev->name, dev->enetaddr);
+ return -EINVAL;
+ }
ret = dev->write_hwaddr(dev);
+ if (ret)
+ printf("\nWarning: %s failed to set MAC address\n", dev->name);
}
return ret;
@@ -303,8 +317,7 @@ int eth_initialize(bd_t *bis)
puts("\nWarning: eth device name has a space!"
"\n");
- if (eth_write_hwaddr(dev, "eth", dev->index))
- puts("\nWarning: failed to set MAC address\n");
+ eth_write_hwaddr(dev, "eth", dev->index);
dev = dev->next;
num_devices++;
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2014-06-27 8:01 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2014-06-27 8:01 UTC (permalink / raw)
To: u-boot
then use the "Change state" drop down at the bottom of the page.
Regards,
Brian
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2014-06-27 8:01 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2014-06-27 8:01 UTC (permalink / raw)
To: u-boot
Are you planning to convert any more platforms during this merge window?
Hans & I would really like to see sunxi switch this time around, before
it gets more widely used (since v2014.10 will support loads more
platforms).
I'm AFK after today but Hans has offered to try and whip something up
ASAP.
Cheers,
Ian.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2014-06-27 8:01 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2014-06-27 8:01 UTC (permalink / raw)
To: u-boot
Acked-by: Simon Glass <sjg@chromium.org>
But please see a request below:
[snip]
> diff --git a/dts/Kconfig b/dts/Kconfig
> new file mode 100644
> index 0000000..20be556
> --- /dev/null
> +++ b/dts/Kconfig
> @@ -0,0 +1,48 @@
> +#
> +# Device Tree Control
> +#
> +# TODO:
> +# This feature is not currently supported for SPL,
> +# but this restriction should be removed in the future.
> +
> +config SUPPORT_OF_CONTROL
> + bool
> +
> +menu "Device Tree Control"
> + depends on !SPL_BUILD
> + depends on SUPPORT_OF_CONTROL
> +
> +config OF_CONTROL
> + bool "Run-time configuration via Device Tree"
> + help
> + This feature provides for run-time configuration of U-Boot
> + via a flattened device tree.
> +
> +choice
> + prompt "Provider of DTB for DT control"
> + depends on OF_CONTROL
> +
> +config OF_SEPARATE
> + bool "Separate DTB for DT control"
> + depends on !SANDBOX
> + help
> + If this option is enabled, the device tree will be built and
> + placed as a separate u-boot.dtb file alongside the U-Boot image.
> +
> +config OF_EMBED
> + bool "Embedded DTB for DT control"
> + help
> + If this option is enabled, the device tree will be picked up and
> + built into the U-Boot image.
Can you please add " This is suitable for debugging
and development only and is not recommended for production devices."
> +
> +config OF_HOSTFILE
> + bool "Host filed DTB for DT control"
> + depends on SANDBOX
> + help
> + If this option is enabled, DTB will be read from a file on startup.
> + This is only useful for Sandbox. Use the -d flag to U-Boot to
> + specify the file to read.
> +
> +endchoice
> +
> +endmenu
Regards,
Simon
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2014-05-30 7:51 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2014-05-30 7:51 UTC (permalink / raw)
To: u-boot
or wrong config GIC parameter to model .
Regards,
Sudeep
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2014-05-30 7:51 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2014-05-30 7:51 UTC (permalink / raw)
To: u-boot
aba27ac, we see that first parameter of FPGA_GET_REG() shall be the
FPGA index and not channel number. The re-factoring in commit aba27ac
accidentally changed that.
Signed-off-by: Vasili Galka <vvv444@gmail.com>
Cc: Dirk Eibach <dirk.eibach@gdsys.cc>, Stefan Roese <sr@denx.de>
---
board/gdsys/405ex/io64.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/gdsys/405ex/io64.c b/board/gdsys/405ex/io64.c
index 2f8e306..3a075c4 100644
--- a/board/gdsys/405ex/io64.c
+++ b/board/gdsys/405ex/io64.c
@@ -287,7 +287,7 @@ int last_stage_init(void)
for (fpga = 0; fpga < 2; ++fpga) {
for (k = 0; k < 32; ++k) {
u16 status;
- FPGA_GET_REG(k, ch[k].status_int, &status);
+ FPGA_GET_REG(fpga, ch[k].status_int, &status);
if (!(status & (1 << 4))) {
failed = 1;
printf("fpga %d channel %d: no serdes lock\n",
@@ -304,7 +304,7 @@ int last_stage_init(void)
for (fpga = 0; fpga < 2; ++fpga) {
for (k = 0; k < 32; ++k) {
u16 status;
- FPGA_GET_REG(k, hicb_ch[k].status_int, &status);
+ FPGA_GET_REG(fpga, hicb_ch[k].status_int, &status);
if (status)
printf("fpga %d hicb %d: hicb status %04x\n",
fpga, k, status);
--
1.7.9
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2014-05-30 7:51 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2014-05-30 7:51 UTC (permalink / raw)
To: u-boot
Setting FPGA register brdcfg9 EPHY2 bits to '0' to initialize EPHY2 clock to RGMII mode.
Signed-off-by: Vijay Rai <vijay.rai@freescale.com>
Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com>
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
---
board/freescale/t1040qds/eth.c | 4 +++-
board/freescale/t1040qds/t1040qds_qixis.h | 4 ++++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/board/freescale/t1040qds/eth.c b/board/freescale/t1040qds/eth.c
index 3077b4a..1929bba 100644
--- a/board/freescale/t1040qds/eth.c
+++ b/board/freescale/t1040qds/eth.c
@@ -355,7 +355,9 @@ static void set_brdcfg9_for_gtx_clk(void)
{
u8 brdcfg9;
brdcfg9 = QIXIS_READ(brdcfg[9]);
- brdcfg9 |= (1 << 5);
+/* Initializing EPHY2 clock to RGMII mode */
+ brdcfg9 &= ~(BRDCFG9_EPHY2_MASK);
+ brdcfg9 |= (BRDCFG9_EPHY2_VAL);
QIXIS_WRITE(brdcfg[9], brdcfg9);
}
diff --git a/board/freescale/t1040qds/t1040qds_qixis.h b/board/freescale/t1040qds/t1040qds_qixis.h
index 98d2d39..cef8ad0 100644
--- a/board/freescale/t1040qds/t1040qds_qixis.h
+++ b/board/freescale/t1040qds/t1040qds_qixis.h
@@ -17,6 +17,10 @@
#define BRDCFG5_IMX_MASK 0xC0
#define BRDCFG5_IMX_DIU 0x80
+/* BRDCFG9[2] controls EPHY2 Clock */
+#define BRDCFG9_EPHY2_MASK 0x20
+#define BRDCFG9_EPHY2_VAL 0x00
+
/* BRDCFG15[3] controls LCD Panel Powerdown*/
#define BRDCFG15_LCDPD_MASK 0x10
#define BRDCFG15_LCDPD_ENABLED 0x00
--
1.7.9.5
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2014-05-24 1:21 Loc Ho
0 siblings, 0 replies; 732+ messages in thread
From: Loc Ho @ 2014-05-24 1:21 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds support for the APM X-Gene SoC EDAC driver.
v2:
* Add EDAC entry in MAINTAINERS for APM EDAC driver
* Remove the MC scrub patch
* Remove the word 'Caches' from Kconfig
* Change all MASK defines to use BIT(x)
* Update comment or remove them
* Wrap error injection code around CONFIG_EDAC_DEBUG
* Change function name xgene_edac_mc_hw_init to xgene_edac_mc_irq_ctl
* Change all function XXX_hw_init to XXX_hw_ctl
* Fix typo 'activie'
* Move calling function edac_mc_alloc after resource retrieval
* Check for NULL on platform_get_resource return if reference directly
* Add documentation for struct xgene_edac_pmd_ctx
* Move L1 and L2 check out of function xgene_edac_pmd_check to its own
functions
* Use for loop for configure each CPU of an PMD
* Replace /2 by >> 1
* Remove unnecessary comment on edac_device_add_device failure
* Make mem_err_ip static const
* Unwind EDAC register correctly if failed
---
Loc Ho (4):
MAINTAINERS: Add entry for APM X-Gene SoC EDAC driver
Documentation: Add documentation for the APM X-Gene SoC EDAC DTS
binding
edac: Add APM X-Gene SoC EDAC driver
arm64: Add APM X-Gene SoC EDAC DTS entries
.../devicetree/bindings/edac/apm-xgene-edac.txt | 70 +
MAINTAINERS | 8 +
arch/arm64/boot/dts/apm-storm.dtsi | 89 +
drivers/edac/Kconfig | 9 +-
drivers/edac/Makefile | 3 +
drivers/edac/xgene_edac.c | 1993 ++++++++++++++++++++
6 files changed, 2171 insertions(+), 1 deletions(-)
create mode 100644 Documentation/devicetree/bindings/edac/apm-xgene-edac.txt
create mode 100644 drivers/edac/xgene_edac.c
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2014-05-12 16:40 Santosh Shilimkar
0 siblings, 0 replies; 732+ messages in thread
From: Santosh Shilimkar @ 2014-05-12 16:40 UTC (permalink / raw)
To: linux-arm-kernel
>From 14f3791439b5a6cf12127fb80204265533d92664 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
Date: Mon, 12 May 2014 12:28:23 -0400
Subject: [GIT PULL 1/2] ARM: Keystone SOC updates for 3.16
Hi Arm-soc folks,
Please pull below keystone SOC updates for 3.16. It merges cleanly with
arm-soc 'next/soc' head. As already discussed, the $subject pull request
has a depedency with DT dma-properties pull request [1] I sent last week
to be pulled into arm-soc.
The following changes since commit c9eaa447e77efe77b7fa4c953bd62de8297fd6c5:
Linux 3.15-rc1 (2014-04-13 14:18:35 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git tags/keystone-soc
for you to fetch changes up to 14f3791439b5a6cf12127fb80204265533d92664:
ARM: keystone: Update the dma offset for non-dt platform devices (2014-05-08 15:43:33 -0400)
----------------------------------------------------------------
Keystone SOC updates for 3.16
- Drop unused COMMON_CLK_DEBUG option
- Enable MTD_SPI_NOR config needed for M25P80
- Enable coherent higher address memory space
----------------------------------------------------------------
Brian Norris (1):
ARM: configs: keystone: add MTD_SPI_NOR (new dependency for M25P80)
Lad Prabhakar (1):
ARM: configs: keystone: drop CONFIG_COMMON_CLK_DEBUG
Santosh Shilimkar (2):
ARM: keystone: Switch over to coherent memory address space
ARM: keystone: Update the dma offset for non-dt platform devices
arch/arm/configs/integrator_defconfig | 1 -
arch/arm/configs/keystone_defconfig | 2 +-
arch/arm/configs/sunxi_defconfig | 1 -
arch/arm/configs/vt8500_v6_v7_defconfig | 1 -
arch/arm/mach-keystone/keystone.c | 74 +++++++++++++++++++++++++++++++
arch/arm/mach-keystone/memory.h | 24 ++++++++++
arch/arm/mach-keystone/platsmp.c | 18 +++++++-
7 files changed, 116 insertions(+), 5 deletions(-)
create mode 100644 arch/arm/mach-keystone/memory.h
Regards,
Santosh
[1] https://lkml.org/lkml/2014/5/7/368
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2014-05-12 16:38 Santosh Shilimkar
0 siblings, 0 replies; 732+ messages in thread
From: Santosh Shilimkar @ 2014-05-12 16:38 UTC (permalink / raw)
To: linux-arm-kernel
>From 14f3791439b5a6cf12127fb80204265533d92664 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
Date: Mon, 12 May 2014 12:28:23 -0400
Subject: [GIT PULL 1/2] ARM: Keystone SOC updates for 3.16
Hi Arm-soc folks,
Please pull below keystone SOC updates for 3.16. It merges cleanly with
arm-soc 'next/soc' head. As already discussed, the $subject pull request
has a depedency with DT dma-properties pull request [1] I sent last week
to be pulled into arm-soc.
The following changes since commit c9eaa447e77efe77b7fa4c953bd62de8297fd6c5:
Linux 3.15-rc1 (2014-04-13 14:18:35 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git tags/keystone-soc
for you to fetch changes up to 14f3791439b5a6cf12127fb80204265533d92664:
ARM: keystone: Update the dma offset for non-dt platform devices (2014-05-08 15:43:33 -0400)
----------------------------------------------------------------
Keystone SOC updates for 3.16
- Drop unused COMMON_CLK_DEBUG option
- Enable MTD_SPI_NOR config needed for M25P80
- Enable coherent higher address memory space
----------------------------------------------------------------
Brian Norris (1):
ARM: configs: keystone: add MTD_SPI_NOR (new dependency for M25P80)
Lad Prabhakar (1):
ARM: configs: keystone: drop CONFIG_COMMON_CLK_DEBUG
Santosh Shilimkar (2):
ARM: keystone: Switch over to coherent memory address space
ARM: keystone: Update the dma offset for non-dt platform devices
arch/arm/configs/integrator_defconfig | 1 -
arch/arm/configs/keystone_defconfig | 2 +-
arch/arm/configs/sunxi_defconfig | 1 -
arch/arm/configs/vt8500_v6_v7_defconfig | 1 -
arch/arm/mach-keystone/keystone.c | 74 +++++++++++++++++++++++++++++++
arch/arm/mach-keystone/memory.h | 24 ++++++++++
arch/arm/mach-keystone/platsmp.c | 18 +++++++-
7 files changed, 116 insertions(+), 5 deletions(-)
create mode 100644 arch/arm/mach-keystone/memory.h
Regards,
Santosh
[1] https://lkml.org/lkml/2014/5/7/368
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2014-05-12 4:37 Sivakumar V
0 siblings, 0 replies; 732+ messages in thread
From: Sivakumar V @ 2014-05-12 4:37 UTC (permalink / raw)
To: kernelnewbies
Hi All,
I am tried to compile and install (network file system)nfs module to
kernel i.e. modified nfs code(inserted printk's in kernel nfs code) without
compiling entire kernel .
It is inserted but when configuring nfs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140512/d8b76c77/attachment.html
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2014-04-21 2:59 Amber Thrall
0 siblings, 0 replies; 732+ messages in thread
From: Amber Thrall @ 2014-04-21 2:59 UTC (permalink / raw)
To: kernelnewbies
I recently built and installed kernel version 3.15.0-rc1 following the
KernelBuild article on kernelnewbies.org. Everything went smooth and my
system is running fine. However when performing an update via (sudo yum
update) the dependencies failed requiring
"kernel-devel-uname-r=3.13.10". uname-r returns "3.15.0-rc1" as
expected.
Is there a way to get yum to recognize the latest kernel I built? Or
does that require updating the kernel's source RPM?
I'm running Fedora 20 and am new to kernel building. Yum's error
message is included below:
Error: Package:
10:buildsys-build-rpmfusion-kerneldevpkgs-current-20-19.x86_64
(rpmfusion-free-updates)
Requires: kernel-devel-uname-r = 3.13.10-200.fc20.x86_64
Installed: kernel-devel-3.11.10-301.fc20.x86_64 (@anaconda)
kernel-devel-uname-r = 3.11.10-301.fc20.x86_64
Installed: kernel-devel-3.13.9-200.fc20.x86_64 (@updates)
kernel-devel-uname-r = 3.13.9-200.fc20.x86_64
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2014-03-03 8:42 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2014-03-03 8:42 UTC (permalink / raw)
To: u-boot
8bit ECC correction. So I am not sure this constrain might due to older
version controller. Wonder you have any insight on this?
>
> Denali's document says
> For 512B ECC sector size,
> ecc.bytes = Ceiling to next word (13 * ecc.strength)
> For 1024B ECC sector size,
> ecc.bytes = Ceiling to next word (14 * ecc.strength)
>
>
>
> And denali_setup_dma_sequence() function
> (Why did you rename this function?)
> did not work either.
> I needed to fix it locally.
>
>
> So bad news is this version itself does not work for me.
> Good news is I could adjust it locally and confirmed some features
> worked. (But I think I need more test.)
>
> So, how will this situation work?
> It turned out there are some differences between
> two Denali hardwares and this driver works only for yours.
>
> You merge it first, and (if you don't mind) shall I modify it
> in a more generic way to run on both hardwares?
>
Anyway will work for me. I can take your comments and change the driver
accordingly too.
> > If you want to run under SPL, there are some patches for that. Let me
> > know if you need that. While for U-Boot, they are working fine. Probably
>
> Thanks for your offering help.
> But I am not sure if SOCFPGA and UniPhier can share a SPL nand driver.
> (Actually I have locally our own Denali driver for SPL.
> And I have Denali driver for main U-Boot, which is adjusted for
> our SoCs, too.
> But I don't mind to switch onto your driver if it works for me.)
>
Oh for SPL, I can use the same driver too. Just that I would need to
update the nand_spl_simple.c. The main changes is to use the HW ECC
feature instead of getting software calculate and fix the ECC. FYI, the
patch I made for SPL is located at
http://rocketboards.org/gitweb/?p=u-boot-socfpga.git;a=commit;h=461a61b8f03d3b690de1f4ff007cd23fb80018a5
> > +#define CONFIG_SYS_NAND_USE_FLASH_BBT
> > +#define CONFIG_SYS_NAND_REGS_BASE SOCFPGA_NAND_REGS_ADDRESS
> > +#define CONFIG_SYS_NAND_DATA_BASE SOCFPGA_NAND_DATA_ADDRESS
> > +#define CONFIG_SYS_NAND_BASE CONFIG_SYS_NAND_REGS_BASE
>
> Maybe
> #define CONFIG_SYS_NAND_BASE (SOCFPGA_NAND_DATA_ADDRESS + 0x10)
> ?
>
For SOCFPGA, the register and data base address have large address space
in between them. End of day, it seems its tightly to hardware guys
implementation.
>
> BTW, you changed all denali->foo to denali.foo.
> It looks unnecessay to me.
>
Hmmm.. I suspect this changed when we declare denali as static global.
Thanks
Chin Liang
>
> Best Regards
> Masahiro Yamada
>
>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2014-03-03 8:42 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2014-03-03 8:42 UTC (permalink / raw)
To: u-boot
But inside my datasheet, its marked as reserved.
Wonder the version of Denali controller I have is older?
Probably we can probe the Cadence then.
At same time, I will send out new patch to capture the fix before
forget.
Thanks
Chin Liang
>
>
> Best Regards
> Masahiro Yamada
>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2014-03-03 8:42 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2014-03-03 8:42 UTC (permalink / raw)
To: u-boot
- CONFIG_SYS_CPM_POST_WORD_ADDR: (MPC8xx, MPC8260 only)
Offset of the bootmode word in DPRAM used by post
(Power On Self Tests). This definition overrides
#define'd default value in commproc.h resp.
cpm_8260.h.
I think you asked this question before. You should explain what you
want this feature to do, what board you are using, where you have
already looked for information, etc. People are much more likely to
respond if you provide a bit of context.
Also I think I did already reply and point to the bootstage feature
and show_boot_progress()?
Regards,
Simon
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2014-03-03 8:42 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2014-03-03 8:42 UTC (permalink / raw)
To: u-boot
a later version and see if that fixes my issue.
Thanks
Dang
-----Original Message-----
From: James Chargin [mailto:jimccrown at gmail.com]
Sent: Monday, April 14, 2014 2:10 PM
To: Tran, Dang; u-boot at lists.denx.de
Subject: Re: [U-Boot] U-Boot Loop
On 04/14/2014 01:11 PM, Tran, Dang wrote:
> Hi James,
>
> I'm using U-Boot 2010.06 (Jun 18 2013 - 14:03:16)
This is a version of U-Boot that is even older than the version I used for =
my demonstration that ctrl-c works. (I used 2010.12)
You should make efforts towards using a more recent version.
What information can you provide as to the settings of your serial terminal=
emulator? Is it known to send your ctrl-c to the target device?
Jim
--
Jim Chargin
AJA Video Systems jimc at aja.com
(530) 271-3334 http://www.aja.com
>
> Thanks
> Dang
>
> -----Original Message-----
> From: James Chargin [mailto:jimccrown at gmail.com]
> Sent: Friday, April 11, 2014 9:46 AM
> To: u-boot at lists.denx.de; Tran, Dang
> Subject: Re: [U-Boot] U-Boot Loop
>
> Greetings,
>
> On 04/11/2014 09:23 AM, Tran, Dang wrote:
>> Hi,
>>
>> I'm running a PowerPC board that uses U-Boot and I get into this loop (s=
ee terminal output below).
>> It doesn't matter how I get into this loop. What I really care about is =
how to break out of it without manually resetting the board.
>> Is there a way to break out of this loop and reset the system via the te=
rminal? Ctrl-X and Ctrl-C doesn't seem to do anything.
>>
>
> It might be helpful to know which version of U-Boot you are using.
>
>>
>>
>> TERMINAL OUTPUT
>> Waiting for PHY auto negotiation to complete...... TIMEOUT !
>> eTSEC1: No link.
>> Speed: 1000, full duplex
>> Using eTSEC2 device
>> TFTP from server 192.168.128.127; our IP address is 192.168.128.128 File=
name 'oe/bsp/mvme2500/vxWorks'.
>> Load address: 0x1000000
>> Loading: T T T T T T T T T T
>> Retry count exceeded; starting again
>> Waiting for PHY auto negotiation to complete...... TIMEOUT !
>
> For U-Boot builds made from official sources, ctrl-C works for me to term=
inate the retry TFTP, as shown
>
> =3D> # with no Ethernet connection...
> =3D> tftp 500000 test.txt
> Waiting for PHY auto negotiation to complete....user interrupt!
> eTSEC1: No link.
> show_boot_progress(-81) boot fail
> =3D> # in the above, "user interrupt!" was the response to ^C =3D> =3D> #=
10.10.0.10 is known to not exist =3D> setenv serverip 10.10.0.10 =3D> tftp=
500000 test.txt
> Speed: 1000, full duplex
> Using eTSEC1 device
> TFTP from server 10.10.0.10; our IP address is 10.10.0.15 Filename 'test.=
txt'.
> Load address: 0x500000
> Loading: T T
> Abort
> show_boot_progress(-81) boot fail
> =3D> # in the above, "Abort" was the response to ^C =3D>
>
>
> Please make sure your serial communication terminal emulator correctly tr=
ansmits the ctrl-C when you type it. To see if this works, get to a U-Boot =
prompt and type ctrl-C, you should see <INTERRUPT>
>
>> ...
>
>>
>>
>> Thanks
>> Dang
>>
>>
>> This email is non-binding, is subject to contract, and neither Kulicke &=
Soffa Industries Inc nor its subsidiaries shall have any obligation to you=
to consummate the transactions herein or to enter into any agreement, othe=
r than in accordance with the terms and conditions of a definitive agreemen=
t if and when negotiated, finalized and executed between the parties.
>
> This sort of disclaimer in email to the U-Boot mailing list is frowned up=
on. Please try to eliminate it for any future postings.
>
> Best regards,
> Jim
> ---
> Jim Chargin
> AJA Video Systems jimc at aja.com
> (530) 271-3334 http://www.aja.com
>
> This email is non-binding, is subject to contract, and neither Kulicke & =
Soffa Industries Inc nor its subsidiaries shall have any obligation to you =
to consummate the transactions herein or to enter into any agreement, other=
than in accordance with the terms and conditions of a definitive agreement=
if and when negotiated, finalized and executed between the parties.
>
This email is non-binding, is subject to contract, and neither Kulicke & So=
ffa Industries Inc nor its subsidiaries shall have any obligation to you to=
consummate the transactions herein or to enter into any agreement, other t=
han in accordance with the terms and conditions of a definitive agreement i=
f and when negotiated, finalized and executed between the parties.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2014-03-03 8:42 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2014-03-03 8:42 UTC (permalink / raw)
To: u-boot
- Return ARM_PSCI_RET_INVAL instead of ARM_PSCI_RET_NI when PSCI is
entered with an invalid function code.
- Fix !NONSEC compilation
- Rebased on top of adcdeac
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2014-03-03 8:42 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2014-03-03 8:42 UTC (permalink / raw)
To: u-boot
- Dropped the secure stack allocation from the generic PSCI code. There
was too little space there for it to be really useful, and the arch code
knows a lot better about its requirements anyway. It is now the
responsibility of the arch code to provide a stack. This allows it to
get rid of the silly game with the thread registers that was confusing
everyone...
- Added provision for FIQ handling in secure mode. Allwinner A20 is
going to require this for CPU_OFF.
- Better integration of the FDT injection code with the rest of the
code, fixing the truncated FDT issue that people have been reporting
(courtesy of Ma Haijun).
- Cleanup of the AW-specific code (stack allocation, timer macro).
- Rebased on mainline U-Boot (on top of 22a240c32c13).
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2014-03-03 8:42 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2014-03-03 8:42 UTC (permalink / raw)
To: u-boot
- Complete rewrite, now directly relocating the secure code withing
U-Boot, instead of having a separate psci blob.
Ma Haijun (1):
ARM: convert arch_fixup_memory_node to a generic FDT fixup function
Marc Zyngier (9):
ARM: HYP/non-sec: move switch to non-sec to the last boot phase
ARM: HYP/non-sec: add a barrier after setting SCR.NS==1
ARM: non-sec: reset CNTVOFF to zero
ARM: add missing HYP mode constant
ARM: HYP/non-sec: add separate section for secure code
ARM: HYP/non-sec: allow relocation to secure RAM
ARM: HYP/non-sec: add generic ARMv7 PSCI code
ARM: HYP/non-sec: add the option for a second-stage monitor
ARM: HYP/non-sec/PSCI: emit DT nodes
arch/arm/config.mk | 2 +-
arch/arm/cpu/armv7/Makefile | 5 +
arch/arm/cpu/armv7/nonsec_virt.S | 168 +++++++++++++++++---------------
arch/arm/cpu/armv7/psci.S | 102 +++++++++++++++++++
arch/arm/cpu/armv7/virt-dt.c | 100 +++++++++++++++++++
arch/arm/cpu/armv7/virt-v7.c | 59 ++++-------
arch/arm/cpu/u-boot.lds | 30 ++++++
arch/arm/include/asm/armv7.h | 11 ++-
arch/arm/include/asm/proc-armv/ptrace.h | 2 +
arch/arm/include/asm/psci.h | 35 +++++++
arch/arm/include/asm/secure.h | 26 +++++
arch/arm/lib/bootm-fdt.c | 14 ++-
arch/arm/lib/bootm.c | 27 +++--
arch/arm/lib/interrupts.c | 2 +-
arch/arm/lib/sections.c | 2 +
common/image-fdt.c | 7 +-
include/common.h | 6 +-
17 files changed, 451 insertions(+), 147 deletions(-)
create mode 100644 arch/arm/cpu/armv7/psci.S
create mode 100644 arch/arm/cpu/armv7/virt-dt.c
create mode 100644 arch/arm/include/asm/psci.h
create mode 100644 arch/arm/include/asm/secure.h
--
1.9.2
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2014-03-03 8:42 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2014-03-03 8:42 UTC (permalink / raw)
To: u-boot
When I build the code in u-boot-socfpga I get a healthy working
u-boot-spl.bin of approx 45kbytes.
When I build the mainline u-boot code I get a broken u-boot-spl.bin of
approx 3kbytes.
It seems the mainline u-boot is missing stuff, including the all-critical
sdram initialisation without which the SPL is useless.
So, I have a few related questions:
1. The SDRAM init code, like other SocFPGA "hand-off" files is generated by
the Altera tools. Since it is not hand written, and is not compliant with
u-boot coding style. Is it more important to preserve coding style and have
a broken SPL than it is to have a working SPL and broken code?
2. Is there a practical "half-way" compromise whereby the generated code is
run through lindent and we just accept that this is as good as it gets?
3. Can we get some sort of coding style waiver, considering that this code
is off in a board file and does not impact on anyone working on anything
other than socfpga (indeed nobody even working on socfpga even reads it).
Clearly significant hand editing generated code makes for a very broken
workflow, but running it through an automated step like lindent is Ok from
a workflow point of view.
Unless this can be resolved we end up with a situation where people working
on SocFPGA are forced to fork for practical reasons.
Regards
Charles
--047d7b6dcbf6a9e76404f8b03d47--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2014-03-03 8:42 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2014-03-03 8:42 UTC (permalink / raw)
To: u-boot
when CLKM is running. If we stop CLKM when sampling it the glitches
all go away, so we'll do that.
We also check the "is it locked" bits of PHY_CON13 and loop until they
show that the value sampled actually represents a locked value. It
doesn't appear that the glitching and "is it locked" are related, but
it seems wise to wait until the PHY tells us the value is good before
we use it. In practice we will not loop more than a couple times (and
usually won't loop at all).
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Akshay Saraswat <akshay.s@samsung.com>
---
arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c | 43 +++++++++++++++++++++++++++----
arch/arm/cpu/armv7/exynos/exynos5_setup.h | 1 +
2 files changed, 39 insertions(+), 5 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c b/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c
index 0822323..0654c6a 100644
--- a/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c
+++ b/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c
@@ -233,6 +233,7 @@ int ddr3_mem_ctrl_init(int reset)
struct exynos5420_tzasc *tzasc0, *tzasc1;
struct mem_timings *mem;
uint32_t val, n_lock_r, n_lock_w_phy0, n_lock_w_phy1;
+ uint32_t lock0_info, lock1_info;
int chip;
int i;
@@ -396,7 +397,41 @@ int ddr3_mem_ctrl_init(int reset)
*/
dmc_config_mrs(mem, &drex0->directcmd);
dmc_config_mrs(mem, &drex1->directcmd);
- } else {
+ }
+
+ /*
+ * Get PHY_CON13 from both phys. Gate CLKM around reading since
+ * PHY_CON13 is glitchy when CLKM is running. We're paranoid and
+ * wait until we get a "fine lock", though a coarse lock is probably
+ * OK (we only use the coarse numbers below). We try to gate the
+ * clock for as short a time as possible in case SDRAM is somehow
+ * sensitive. sdelay(10) in the loop is arbitrary to make sure
+ * there is some time for PHY_CON13 to get updated. In practice
+ * no delay appears to be needed.
+ */
+ val = readl(&clk->gate_bus_cdrex);
+ while (true) {
+ writel(val & ~0x1, &clk->gate_bus_cdrex);
+ lock0_info = readl(&phy0_ctrl->phy_con13);
+ writel(val, &clk->gate_bus_cdrex);
+
+ if ((lock0_info & CTRL_FINE_LOCKED) == CTRL_FINE_LOCKED)
+ break;
+
+ sdelay(10);
+ }
+ while (true) {
+ writel(val & ~0x2, &clk->gate_bus_cdrex);
+ lock1_info = readl(&phy1_ctrl->phy_con13);
+ writel(val, &clk->gate_bus_cdrex);
+
+ if ((lock1_info & CTRL_FINE_LOCKED) == CTRL_FINE_LOCKED)
+ break;
+
+ sdelay(10);
+ }
+
+ if (!reset) {
/*
* During Suspend-Resume & S/W-Reset, as soon as PMU releases
* pad retention, CKE goes high. This causes memory contents
@@ -447,15 +482,13 @@ int ddr3_mem_ctrl_init(int reset)
val |= (RDLVL_PASS_ADJ_VAL << RDLVL_PASS_ADJ_OFFSET);
writel(val, &phy1_ctrl->phy_con1);
- n_lock_r = readl(&phy0_ctrl->phy_con13);
- n_lock_w_phy0 = (n_lock_r & CTRL_LOCK_COARSE_MASK) >> 2;
+ n_lock_w_phy0 = (lock0_info & CTRL_LOCK_COARSE_MASK) >> 2;
n_lock_r = readl(&phy0_ctrl->phy_con12);
n_lock_r &= ~CTRL_DLL_ON;
n_lock_r |= n_lock_w_phy0;
writel(n_lock_r, &phy0_ctrl->phy_con12);
- n_lock_r = readl(&phy1_ctrl->phy_con13);
- n_lock_w_phy1 = (n_lock_r & CTRL_LOCK_COARSE_MASK) >> 2;
+ n_lock_w_phy1 = (lock1_info & CTRL_LOCK_COARSE_MASK) >> 2;
n_lock_r = readl(&phy1_ctrl->phy_con12);
n_lock_r &= ~CTRL_DLL_ON;
n_lock_r |= n_lock_w_phy1;
diff --git a/arch/arm/cpu/armv7/exynos/exynos5_setup.h b/arch/arm/cpu/armv7/exynos/exynos5_setup.h
index b50af2f..1cf9caf 100644
--- a/arch/arm/cpu/armv7/exynos/exynos5_setup.h
+++ b/arch/arm/cpu/armv7/exynos/exynos5_setup.h
@@ -284,6 +284,7 @@
#define CTRL_DLL_ON (1 << 5)
#define CTRL_FORCE_MASK (0x7F << 8)
#define CTRL_LOCK_COARSE_MASK (0x7F << 10)
+#define CTRL_FINE_LOCKED 0x7
#define CTRL_OFFSETD_RESET_VAL 0x8
#define CTRL_OFFSETD_VAL 0x7F
--
1.8.3.2
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2014-03-03 8:42 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2014-03-03 8:42 UTC (permalink / raw)
To: u-boot
work this way on the i.MX28 either. The VDDIO Linreg is sourced from the
5V rail. So if we run from battery only we can not deactivate VDDIO from
DCDC by setting DISABLE_FET.
> The BootROM never hands over to U-Boot, so this really makes no sense. Can you
> please explain ? The BootROM handles over to U-Boot SPL, which configures the
> power block.
>
Sorry I meant the U-Boot SPL.I not that familiar with U-Boot architecture.
> Also, I find it a very bad idea to depend on the BootROM to actually start the
> DCDC converter. I don't think we can universally say the DCDC converter is
> running when entering U-Boot SPL. I also don't think we can even depend on the
> power block configuration when exiting the BootROM -- for example in JTAG Boot
> Mode, the BootROM halts early in the boot process and will likely not configure
> anything with regards to the power block.
I am with you at the point that proper initialization is very important
and we should not rely on BootROM.
If the system is running on battery only, we should not switch the VDDIO
regulator to Linreg mode because there are no 5V to source it. In
mxs_power_enable_4p2() all Regulators get switched to Linreg mode and
that kills the power to hole system and there by is triggering an
brownout reset.
The mxs_power_enable_4p2() function can only work if we assume
there is 5V present.
I hope I got clearer way this will not work in a battery only scenario.
Best regards,
Peter Schumann
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2014-03-03 8:42 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2014-03-03 8:42 UTC (permalink / raw)
To: u-boot
when CLKM is running. If we stop CLKM when sampling it the glitches
all go away, so we'll do that as per Samsung suggestion.
We also check the "is it locked" bits of PHY_CON13 and loop until they
show the the value sampled actually represents a locked value. It
doesn't appear that the glitching and "is it locked" are related, but
it seems wise to wait until the PHY tells us the value is good before
we use it. In practice we will not loop more than a couple times (and
usually won't loop at all).
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Akshay Saraswat <akshay.s@samsung.com>
Acked-by: Simon Glass <sjg@chromium.org>
---
Changes since v1:
- Added "Acked-by".
arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c | 43 +++++++++++++++++++++++++++----
arch/arm/cpu/armv7/exynos/exynos5_setup.h | 1 +
2 files changed, 39 insertions(+), 5 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c b/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c
index 1d6048c..13003b8 100644
--- a/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c
+++ b/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c
@@ -230,6 +230,7 @@ int ddr3_mem_ctrl_init(struct mem_timings *mem, int reset)
struct exynos5420_dmc *drex0, *drex1;
struct exynos5420_tzasc *tzasc0, *tzasc1;
uint32_t val, n_lock_r, n_lock_w_phy0, n_lock_w_phy1;
+ uint32_t lock0_info, lock1_info;
int chip;
int i;
@@ -391,7 +392,41 @@ int ddr3_mem_ctrl_init(struct mem_timings *mem, int reset)
*/
dmc_config_mrs(mem, &drex0->directcmd);
dmc_config_mrs(mem, &drex1->directcmd);
- } else {
+ }
+
+ /*
+ * Get PHY_CON13 from both phys. Gate CLKM around reading since
+ * PHY_CON13 is glitchy when CLKM is running. We're paranoid and
+ * wait until we get a "fine lock", though a coarse lock is probably
+ * OK (we only use the coarse numbers below). We try to gate the
+ * clock for as short a time as possible in case SDRAM is somehow
+ * sensitive. sdelay(10) in the loop is arbitrary to make sure
+ * there is some time for PHY_CON13 to get updated. In practice
+ * no delay appears to be needed.
+ */
+ val = readl(&clk->gate_bus_cdrex);
+ while (true) {
+ writel(val & ~0x1, &clk->gate_bus_cdrex);
+ lock0_info = readl(&phy0_ctrl->phy_con13);
+ writel(val, &clk->gate_bus_cdrex);
+
+ if ((lock0_info & CTRL_FINE_LOCKED) == CTRL_FINE_LOCKED)
+ break;
+
+ sdelay(10);
+ }
+ while (true) {
+ writel(val & ~0x2, &clk->gate_bus_cdrex);
+ lock1_info = readl(&phy1_ctrl->phy_con13);
+ writel(val, &clk->gate_bus_cdrex);
+
+ if ((lock1_info & CTRL_FINE_LOCKED) == CTRL_FINE_LOCKED)
+ break;
+
+ sdelay(10);
+ }
+
+ if (!reset) {
/*
* During Suspend-Resume & S/W-Reset, as soon as PMU releases
* pad retention, CKE goes high. This causes memory contents
@@ -442,15 +477,13 @@ int ddr3_mem_ctrl_init(struct mem_timings *mem, int reset)
val |= (RDLVL_PASS_ADJ_VAL << RDLVL_PASS_ADJ_OFFSET);
writel(val, &phy1_ctrl->phy_con1);
- n_lock_r = readl(&phy0_ctrl->phy_con13);
- n_lock_w_phy0 = (n_lock_r & CTRL_LOCK_COARSE_MASK) >> 2;
+ n_lock_w_phy0 = (lock0_info & CTRL_LOCK_COARSE_MASK) >> 2;
n_lock_r = readl(&phy0_ctrl->phy_con12);
n_lock_r &= ~CTRL_DLL_ON;
n_lock_r |= n_lock_w_phy0;
writel(n_lock_r, &phy0_ctrl->phy_con12);
- n_lock_r = readl(&phy1_ctrl->phy_con13);
- n_lock_w_phy1 = (n_lock_r & CTRL_LOCK_COARSE_MASK) >> 2;
+ n_lock_w_phy1 = (lock1_info & CTRL_LOCK_COARSE_MASK) >> 2;
n_lock_r = readl(&phy1_ctrl->phy_con12);
n_lock_r &= ~CTRL_DLL_ON;
n_lock_r |= n_lock_w_phy1;
diff --git a/arch/arm/cpu/armv7/exynos/exynos5_setup.h b/arch/arm/cpu/armv7/exynos/exynos5_setup.h
index 4542bd1..583be27 100644
--- a/arch/arm/cpu/armv7/exynos/exynos5_setup.h
+++ b/arch/arm/cpu/armv7/exynos/exynos5_setup.h
@@ -284,6 +284,7 @@
#define CTRL_DLL_ON (1 << 5)
#define CTRL_FORCE_MASK (0x7F << 8)
#define CTRL_LOCK_COARSE_MASK (0x7F << 10)
+#define CTRL_FINE_LOCKED 0x7
#define CTRL_OFFSETD_RESET_VAL 0x8
#define CTRL_OFFSETD_VAL 0x7F
--
1.8.3.2
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2014-02-22 15:53 Hans de Goede
0 siblings, 0 replies; 732+ messages in thread
From: Hans de Goede @ 2014-02-22 15:53 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
Here is v7 of my patchset for adding ahci-sunxi support. This is hopefully
the final final version of this set :)
Note I'm going on vacation for a week starting Monday, so if I'm not responding
that is why. Tejun if you feel some small cleanups are still necessary and
you don't want to wait for me to get back feel free to squash in any cleanups
you deem necessary.
This has been tested with Allwinner A10, Allwinner A20 and Freeware imx6x SoCs,
including suspend / resume. Note that the ahci_imx driver now also has imx53
sata support, it would be good if someone could test that with this series.
History:
v1, by Olliver Schinagl:
This was using the approach of having a platform device which probe method
creates a new child platform device which gets driven by ahci_platform.c,
as done by ahci_imx.c .
v2, by Hans de Goede:
Stand-alone platform driver based on Olliver's work
v3, by Hans de Goede:
patch-series, with 4 different parts
a) Make ahci_platform.c more generic, handle more then 1 clk, target pwr
regulator
b) New ahci-sunxi code only populating ahci_platform_data, passed to
ahci_platform.c to of_device_id matching.
c) Refactor ahci-imx code to work the same as the new ahci-sunxi code, this
is the reason why v3 is an RFC, I'm waiting for the wandboard I ordered to
arrive so that I can actually test this.
d) dts bindings for the sunxi ahci parts
v4, by Hans de Goede:
patch-series, with 5 different parts:
a) Make ahci_platform.c more generic, handle more then 1 clk, target pwr
regulator
b) Turn parts of ahci_platform.c into a library for use by other drivers
c) New ahci-sunxi driver using the ahci_platform.c library functionality
d) Refactor ahci-imx code to work the same as the new ahci-sunxi code
e) dts bindings for the sunxi ahci parts
v5:
v4 + the following changes:
1) fsl,imx6q driver is now tested
2) fixed suspend / resume on fsl,imx6q
3) Modifed devicetree node naming to match dt spec
4) Reworked the busy waiting code in the sunxi-phy handling as suggested by
Russell King
v6:
v5 rebased on top of 3.14-rc3 + the following changes
1) Added Roger Quadros' generic phy support series
2) Added a "ARM: sun4i: dt: Remove grouping + simple-bus for regulators" dts
patch
v7:
v6 + the following changes:
1) Addressed all Tejun's review remarks:
* Added function header comments to all exported ahci_platform functions
* Added comments in some other places
* Removed use of 2 empty lines to separate functions in some cases
* Use devres to automatically call ahci_platform_put_resources on
get_resource failure, probe failure and regular device remove
2) Dropped patches to move ahci_host_priv struct declaration to include/linux,
this was a left-over from v3 and is no longer necessary
3) Updated Roger's "ata: ahci_platform: Manage SATA PHY" patch:
* Update function header comments for the changes this makes
* Drop the Kconfig PHY requires hack, my patch for the phy-core to always be
built-in has been queued in Greg KH's tree, so this is no longer necessary.
4) Dropped Roger's "ata: ahci_platform: Add 'struct device' argument to ahci_platform_put_resources()"
patch, ahci_platform_put_resources already has a device argument as result
of it being changed into a devres release function
Tejun, can you please add patches 1-12 to your ata tree for 3.15 ?
Maxime, can you please add patch 13-15 to your dts tree for 3.15 ?
Thanks & Regards,
Hans
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2014-01-21 4:09 John Tobias
0 siblings, 0 replies; 732+ messages in thread
From: John Tobias @ 2014-01-21 4:09 UTC (permalink / raw)
To: linux-arm-kernel
Hi Guys,
Just wondering if you encountered the error below and if there's any
existing patch?.
Regards,
john
[ 860.354231] Unable to handle kernel paging request at virtual
address eaffff9d
[ 860.361466] pgd = bf190000
[ 860.364177] [eaffff9d] *pgd=00000000
[ 860.367773] Internal error: Oops: 5 [#1] ARM
[ 860.372048] Modules linked in: bt8xxx(O) sd8xxx(O) mlan(O)
[ 860.377597] CPU: 0 PID: 82 Comm: ksdioirqd/mmc1 Tainted: G
O 3.13.0-rc1 #1
[ 860.385344] task: bf05c280 ti: bf01a000 task.ti: bf01a000
[ 860.390756] PC is at mmc_io_rw_extended+0x38/0x310
[ 860.395552] LR is at mmc_io_rw_extended+0x38/0x310
[ 860.400346] pc : [<80319b68>] lr : [<80319b68>] psr: 400f0013
[ 860.400346] sp : bf01bc90 ip : bf01bd60 fp : bf01bd8c
[ 860.411824] r10: 806f9748 r9 : bf9e7800 r8 : eb075fb4
[ 860.417051] r7 : eaffff9d r6 : 80327c24 r5 : 1a000009 r4 : 00000007
[ 860.423580] r3 : 00000000 r2 : ffffffc4 r1 : 00000000 r0 : bf01bd1c
[ 860.430112] Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM
Segment kernel
[ 860.437423] Control: 10c53c7d Table: bf190059 DAC: 00000015
[ 860.443172] Process ksdioirqd/mmc1 (pid: 82, stack limit = 0xbf01a238)
[ 860.449702] Stack: (0xbf01bc90 to 0xbf01c000)
[ 860.454065] bc80: 80319e04
00000440 00000139 00000000
[ 860.462246] bca0: 00000139 00000000 817de8c2 000000c0 00000700
beac60c0 3b9aca00 00000000
[ 860.470427] bcc0: 00000100 00000007 00000000 00000200 00000700
00000000 bf01bd1c 00000001
[ 860.478609] bce0: bf01bca8 00000000 00000035 1a001207 00002000
00000000 00000000 00000000
[ 860.486790] bd00: 000001b5 00000000 00000000 00000000 00000000
bf01bcb8 bf01bd1c 00000000
[ 860.494971] bd20: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 860.503153] bd40: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 860.511334] bd60: bf01bd94 bf01bd70 80324254 80327c24 bf01be04
bf9e7800 806f9748 b600003f
[ 860.519515] bd80: bf01bdd4 bf01bd90 8031ade8 80319b3c bf01be04
80327c24 00000007 1a000009
[ 860.527697] bda0: bf05c280 000001ff 00100100 bfb52000 00000100
00000007 beac60c0 00010009
[ 860.535878] bdc0: 7f03e578 c0adb000 bf01bdec bf01bdd8 8031aef8
8031ad10 beac60c0 00000700
[ 860.544059] bde0: bf01be14 bf01bdf0 7f08c2bc 8031aee0 00000000
00000009 00000700 7f03d328
[ 860.552240] be00: bfad9a00 00000000 bf01be24 bf01be18 7f0622f0
7f08c278 bf01be6c bf01be28
[ 860.560422] be20: 7f0137a8 7f0622ec bf01be44 bf01be38 8004efd4
00000001 bf01be5c 00000000
[ 860.568603] be40: 804fc960 c0adb000 c0adbce4 7f03d328 00000000
7f03e578 7f061dec bfb52000
[ 860.576784] be60: bf01beac bf01be70 7f001e68 7f0134f8 00000000
00000000 00000000 00000000
[ 860.584965] be80: 00000000 bfb52000 7f09a0d4 bfb51800 00000000
bf9e7800 bf01a000 00000001
[ 860.593146] bea0: bf01bec4 bf01beb0 7f05a138 7f001ce0 00000001
00000000 bf01bed4 bf01bec8
[ 860.601327] bec0: 7f08bfe4 7f05a0cc bf01bf24 bf01bed8 8031ba0c
7f08bfc4 00000000 bf01bef3
[ 860.609509] bee0: bfb51800 00000001 bf9e7bb4 7fffffff 0215d9c0
00000001 8031b874 00000000
[ 860.617690] bf00: bf15d9c0 bf9e7800 8031b874 00000000 00000000
00000000 bf01bfac bf01bf28
[ 860.625871] bf20: 8003c7e8 8031b880 bf01bf44 00000000 8004efd4
bf9e7800 00000000 00000001
[ 860.634052] bf40: dead4ead ffffffff ffffffff 80702208 00000000
00000000 80600be8 bf01bf5c
[ 860.642233] bf60: bf01bf5c 00000000 00000001 dead4ead ffffffff
ffffffff 80702208 00000000
[ 860.650415] bf80: 00000000 80600be8 bf01bf88 bf01bf88 bf15d9c0
8003c724 00000000 00000000
[ 860.658595] bfa0: 00000000 bf01bfb0 8000f308 8003c730 00000000
00000000 00000000 00000000
[ 860.666776] bfc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 860.674956] bfe0: 00000000 00000000 00000000 00000000 00000013
00000000 00000000 00000000
[ 860.683133] Backtrace:
[ 860.685607] [<80319b30>] (mmc_io_rw_extended+0x0/0x310) from
[<8031ade8>] (sdio_io_rw_ext_helper+0xe4/0x1a4)
[ 860.695442] [<8031ad04>] (sdio_io_rw_ext_helper+0x0/0x1a4) from
[<8031aef8>] (sdio_readsb+0x24/0x2c)
[ 860.704676] [<8031aed4>] (sdio_readsb+0x0/0x2c) from [<7f08c2bc>]
(woal_read_data_sync+0x50/0x8c [sd8xxx])
[ 860.714455] [<7f08c26c>] (woal_read_data_sync+0x0/0x8c [sd8xxx])
from [<7f0622f0>] (moal_read_data_sync+0x10/0x14 [sd8xxx])
[ 860.725586] r8:00000000 r7:bfad9a00 r6:7f03d328 r5:00000700 r4:00000009
r3:00000000
[ 860.733603] [<7f0622e0>] (moal_read_data_sync+0x0/0x14 [sd8xxx])
from [<7f0137a8>] (wlan_process_int_status+0x2bc/0x928 [mlan])
[ 860.745139] [<7f0134ec>] (wlan_process_int_status+0x0/0x928 [mlan])
from [<7f001e68>] (mlan_main_process+0x194/0x750 [mlan])
[ 860.756436] [<7f001cd4>] (mlan_main_process+0x0/0x750 [mlan]) from
[<7f05a138>] (woal_interrupt+0x78/0x94 [sd8xxx])
[ 860.766982] [<7f05a0c0>] (woal_interrupt+0x0/0x94 [sd8xxx]) from
[<7f08bfe4>] (woal_sdio_interrupt+0x2c/0x30 [sd8xxx])
[ 860.777677] r5:00000000 r4:00000001
[ 860.781351] [<7f08bfb8>] (woal_sdio_interrupt+0x0/0x30 [sd8xxx])
from [<8031ba0c>] (sdio_irq_thread+0x198/0x368)
[ 860.791537] [<8031b874>] (sdio_irq_thread+0x0/0x368) from
[<8003c7e8>] (kthread+0xc4/0xe0)
[ 860.799814] [<8003c724>] (kthread+0x0/0xe0) from [<8000f308>]
(ret_from_fork+0x14/0x2c)
[ 860.807818] r7:00000000 r6:00000000 r5:8003c724 r4:bf15d9c0
[ 860.813538] Code: e1a09003 e59b400c e59b5010 ebfc3a75 (e5973000)
[ 860.819646] ---[ end trace 1920724507aeb8b4 ]---
[ 860.824270] Kernel panic - not syncing: Fatal exception
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2014-01-16 16:11 Loc Ho
0 siblings, 0 replies; 732+ messages in thread
From: Loc Ho @ 2014-01-16 16:11 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds support for the APM X-Gene SoC SATA host controller. In
order for the host controller to work, the corresponding PHY driver
musts also be available.
v10:
* Update binding documentation
v9:
* Remove ACPI/EFI include files
* Remove the IO flush support, interrupt routine, and DTS resources
* Remove function xgene_rd, xgene_wr, and xgene_wr_flush
* Remove PMP support (function xgene_ahci_qc_issue, xgene_ahci_qc_prep,
xgene_ahci_qc_fill_rtf, xgene_ahci_softreset, and xgene_ahci_do_softreset)
* Rename function xgene_ahci_enable_phy to xgene_ahci_force_phy_rdy
* Clean up hardreset functions
* Require v7 of the PHY driver
v8:
* Remove _ADDR from defines
* Remove define MSTAWAUX_COHERENT_BYPASS_SET and
STARAUX_COHERENT_BYPASS_SET and use direct coding
* Remove the un-necessary check for DTS boot with built in ACPI table
* Switch to use dma_set_mask_and_coherent for setting DMA mask
* Remove ACPI table matching code
* Update clock-names for sata01clk, sata23clk, and sata45clk
v7:
* Update the clock code by toggle the clock
* Update the DTS clock mask values due to the clock spilt between host and
v5 of the PHY drivers
v6:
* Update binding documentation
* Change select PHY_XGENE_SATA to PHY_XGENE
* Add ULL to constants
* Change indentation and comments
* Clean up the probe functions a bit more
* Remove xgene_ahci_remove function
* Add the flush register to DTS
* Remove the interrupt-parent from DTS
v5:
* Sync up to v3 of the PHY driver
* Remove MSLIM wrapper functions
* Change the memory shutdown loop to use usleep_range
* Use devm_ioremap_resource instead devm_ioremap
* Remove suspend/resume functions as not needed
v4:
* Remove the ID property in DT
* Remove the temporary PHY direct function call and use PHY function
* Change printk to pr_debug
* Move the IOB flush addresses into the DT
* Remove the parameters retrieval function as no longer needed
* Remove the header file as no longer needed
* Require v2 patch of the SATA PHY driver. Require slightly modification
in the Kconfig as it is moved to folder driver/phy and use Kconfig
PHY_XGENE_SATA instead SATA_XGENE_PHY.
v3:
* Move out the SATA PHY to another driver
* Remove the clock-cells entry from DTS
* Remove debug wrapper
* Remove delay functions wrapper
* Clean up resource and IRQ query
* Remove query clock name
* Switch to use dma_set_mask/dma_coherent_mask
* Remove un-necessary devm_kfree
* Update GPL license header to v2
* Spilt up function xgene_ahci_hardreset
* Spilt up function xgene_ahci_probe
* Remove all reference of CONFIG_ARCH_MSLIM
* Clean up chip revision code
v2:
* Clean up file sata_xgene.c with Lindent and etc
* Clean up file sata_xgene_serdes.c with Lindent and etc
* Add description to each patch
v1:
* inital version
Signed-off-by: Loc Ho <lho@apm.com>
Signed-off-by: Tuan Phan <tphan@apm.com>
Signed-off-by: Suman Tripathi <stripathi@apm.com>
---
Loc Ho (4):
ata: Export required functions by APM X-Gene SATA driver
Documentation: Add documentation for APM X-Gene SoC SATA host
controller DTS binding
ata: Add APM X-Gene SoC SATA host controller driver
arm64: Add APM X-Gene SoC SATA host controller DTS entries
.../devicetree/bindings/ata/apm-xgene.txt | 70 +++
arch/arm64/boot/dts/apm-storm.dtsi | 75 +++
drivers/ata/Kconfig | 8 +
drivers/ata/Makefile | 1 +
drivers/ata/ahci.h | 9 +
drivers/ata/libahci.c | 16 +-
drivers/ata/sata_xgene.c | 630 ++++++++++++++++++++
7 files changed, 803 insertions(+), 6 deletions(-)
create mode 100644 Documentation/devicetree/bindings/ata/apm-xgene.txt
create mode 100644 drivers/ata/sata_xgene.c
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2014-01-16 16:09 Loc Ho
0 siblings, 0 replies; 732+ messages in thread
From: Loc Ho @ 2014-01-16 16:09 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds support for APM X-Gene SoC 15Gbps Multi-purpose PHY. This
is the physical layer interface for the corresponding host controller. This
driver uses the new PHY generic framework posted by Kishon Vijay Abrahm.
In addition, the new PHY generic framework is patched to provide an
function to set the speed of the PHY.
v8
* Update binding documentation
* Remove XGENE_PHY_DTS and XGENE_PHY_EXT_DTS defines
* Remove support for internal clock
* Remove support for external reference CMU
* Remove the need for external reference resource DTS entry and its related
code
v7
* Add/Update PHY CMU/lane parameters and its default values
* Rename variable enable_manual_cal to preA3Chip
* Remove function phy_rd, phy_wr, and phy_wr_flush
* Change function cmu_wr, cmu_rd, cmu_toggle1to0, cmu_clrbits, cmu_setbits,
serdes_wr, serdes_rd, serdes_clrbits, and serdes_setbits to take context
instead void *
* Remove function serdes_toggle1to0
* Decrease the polling time from 10ms to 1ms on CMU calibration complete
detection
* Move all SATA specify code in function xgene_phy_hw_initialize into
function xgene_phy_hw_init_sata
* Add usleep_range after starting summer/latch calibrations
* Add usleep_range between receiver reset (function xgene_phy_reset_rxd)
* Save and restore PHY register 31 instead writing 0 in function
xgene_phy_gen_avg_val
* Update function xgene_phy_sata_force_gen programming sequences
* Add support to reset the receiver lane in function xgene_phy_set_speed
if speed is 0
* Update PHY parameters in DTS per controller
* Some minor code clean up
v6
* Move PHY document to Documentation/devicetree/binding/phy
* Remove _ADDR from all register defines
* Update clock-names property for sataphy1clk, sataphy2clk, and sataphy3clk
v5
* Update DTS binding documentation
* Remove direct clock access and use clock interface instead
* Change override parameters to decimal instead hex values
* Change apm,tx-amplitude, apm,tx-pre-cursor1, apm,tx-pre-cursor2,
apm,tx-post-cursor to be unit of uV
v4
* Update documentation with 'apm,' instead 'apm-'
* Change DTS override parameter to have 'apm,'
* Add select GENERIC_PHY to Kconfig PHY_XGENE
* Make override parameters to be pair of three values instead one
* Some minor comment and indentation changes
* Remove error register addition offset
* Add ULL to constants
* Use module_init instead subsys_initcall
* Make DTS node based on first register address
* Update override setting values
v3
* Major re-write of the code based on various review comments
* Support external clock only at the moment
* Support SATA mode only at the moment
* No UEFI support at the moment
v2
* Remove port knowledge from functions
* Make all functions static
* Remove ID completely
* Make resource requirement based on compatible type
* Rename override PHY parameters with more descriptive name
* Add override PHY parameter for per controller, per port, and per speed
* Patch the generic PHY frame to expose set_speed operation
v1
* Initial version
Signed-off-by: Loc Ho <lho@apm.com>
Signed-off-by: Tuan Phan <tphan@apm.com>
Signed-off-by: Suman Tripathi <stripathi@apm.com>
---
Loc Ho (4):
PHY: Add function set_speed to generic PHY framework
Documentation: Add APM X-Gene SoC 15Gbps Multi-purpose PHY driver
binding documentation
PHY: add APM X-Gene SoC 15Gbps Multi-purpose PHY driver
arm64: Add APM X-Gene SoC 15Gbps Multi-purpose PHY DTS entries
.../devicetree/bindings/phy/apm-xgene-phy.txt | 79 +
arch/arm64/boot/dts/apm-storm.dtsi | 75 +
drivers/phy/Kconfig | 7 +
drivers/phy/Makefile | 2 +
drivers/phy/phy-core.c | 21 +
drivers/phy/phy-xgene.c | 1793 ++++++++++++++++++++
include/linux/phy/phy.h | 8 +
7 files changed, 1985 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/phy/apm-xgene-phy.txt
create mode 100644 drivers/phy/phy-xgene.c
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2014-01-13 10:32 Lothar Waßmann
0 siblings, 0 replies; 732+ messages in thread
From: Lothar Waßmann @ 2014-01-13 10:32 UTC (permalink / raw)
To: linux-arm-kernel
This patchset adds support for the Ka-Ro electronics i.MX53 based
modules.
The first patch adds a new pingroup for NAND pads that is used by the
modules.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2014-01-13 10:29 Lothar Waßmann
0 siblings, 0 replies; 732+ messages in thread
From: Lothar Waßmann @ 2014-01-13 10:29 UTC (permalink / raw)
To: linux-arm-kernel
This patchset adds support for inverting the PWM output in hardware by
setting the POUTC bit in the PWMCR register. This feature is
controlled via the standard DT flas for PWMs.
The first patch does a minor source cleanup without any functional
change.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-12-16 11:38 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-12-16 11:38 UTC (permalink / raw)
To: u-boot
suppport to the distro config, the result is /boot can be vfat or ext and will
just work.
I have fixed up the arch in pxe so taht it is only represented as armv7 on v7 builds
Left to go is to deal with memory addresses correctly in the most flexible way, and
Wolfgang's objections to the use of fdt_addr to have u-boot load a dtb automatically
without the need to pass in a fdt line in the extlinux.conf
the patches are all posted at http://fedorapeople.org/cgit/ausil/public_git/u-boot.git/ as well
Dennis
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-12-16 11:38 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-12-16 11:38 UTC (permalink / raw)
To: u-boot
>
>> Regards,
>> Rajeshwari.
>
> Amicalement,
>
Thanks,
Minkyu Kang.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-12-16 11:38 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-12-16 11:38 UTC (permalink / raw)
To: u-boot
the handler to be called for my peripheral interrupt.
If I don't install my handler, U-Boot executes default_isr successfully.
If I use my handler, when the interrupt occurs I am getting the prefetch
abort exception with the following dump
prefetch abort
pc : [<ebd78002>] lr : [<bff8f720>]
sp : bfeef200 ip : bfeef358 fp : bfef1d48
r10: bfef1d78 r9 : 00000002 r8 : bfeeff58
r7 : bffac284 r6 : 60000153 r5 : bffbb5c0 r4 : 00000000
r3 : bffab29c r2 : 00000000 r1 : 000003e8 r0 : 8500178c
Flags: nZCv IRQs off FIQs off Mode IRQ_32
Resetting CPU ...
resetting ...
U-Boot SPL 2013.01.-rc1-00003-g43ee87a-dirty (Jan 10 2014 - 16:04:35)
OMAP4460 ES1.1
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.img
Can any one please help me to solve this?
--047d7b5db814cda4e104efda125f--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-12-16 11:38 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-12-16 11:38 UTC (permalink / raw)
To: u-boot
other architecture will work for ARC. So did I - copied and it worked.
I would say that in U-Boot we need to unify lots of things - for example
unified init sequences is a good movement but even there I see tons of
ifdefs for each and other corner case.
So if I want to fix every flaw of existing U-Boot that I met during
implementation of my port I would spend many months on this work while
ARC port still won't be in upstream.
That's why I decided to fix non-ARC sources that block ARC port form
being useful (more than 10 patches were accepted) and then submit ARC
part which looks as much as possible similarly to existing
architectures. This similarity will allow even automatic batch fixing of
things. Otherwise each time you'll need to figure out what happen here
and there and why there're different implementations of similar or even
same things.
Saying all this I'm not withdrawing from doing all these fixes anytime
later. As an active user and contributor I'm interested in having U-boot
sources in good shape - it benefits me in the end.
> > > Note that checkpatch throws warnings here:
> > >=20
> > > WARNING: space prohibited between function name and open parenthesis =
'('
> > >=20
> > > Please make sure to run all your patches through checkpatch and fix
> > > such errors and warnings!
> >
> > As I mentioned I took this one from ARM so I left it as it is.
> > I might just add explicit mention that my file is a copy.
> > Will it work?
>=20
> No. Everybody can make mistakes. But to knowingly copy poor code
> would be... well, no.
Understood.
> > > > +#endif /* __ASM_ARC_POSIX_TYPES_H */
> > > > diff --git a/arch/arc/include/asm/ptrace.h b/arch/arc/include/asm/p=
trac> e.h
> > > > new file mode 100644
> > > > index 0000000..3b2df87
> > > > --- /dev/null
> > > > +++ b/arch/arc/include/asm/ptrace.h
> > > > @@ -0,0 +1,101 @@
> > > > +/*
> > > > + * Copyright (C) 2004, 2007-2010, 2011-2012 Synopsys, Inc. All rig=
hts > reserved.
> > > > + *
> > > > + * SPDX-License-Identifier: GPL-2.0+
> > > > + */
> > > > +
> > > > +#ifndef __ASM_ARC_PTRACE_H
> > > > +#define __ASM_ARC_PTRACE_H
> > > > +
> > > > +#ifndef __ASSEMBLY__
> > > > +
> > > > +/* THE pt_regs: Defines how regs are saved during entry into kerne=
l */
> > >=20
> > > Needed?
> > >=20
> > > > +/* return 1 if user mode or 0 if kernel mode */
> > > > +#define user_mode(regs) (regs->status32 & STATUS_U_MASK)
> > >=20
> > > Certainly not needed, right?
> > >=20
> > > etc. etc.
> >
> > This is another file taken from Linux kernel source that's why I didn't
> > touch it at all.
>=20
> Maybe we can take only the parts that are actually needed or useful?
As with "arcregs.h" I'll clean this one up heavily so it has only useful
pieces.
Regard,
Alexey
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-12-16 11:38 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-12-16 11:38 UTC (permalink / raw)
To: u-boot
comment style cleanup.
>
>> drivers/i2c/Makefile | 1 +
>> drivers/i2c/kona_i2c.c | 730
>> ++++++++++++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 731 insertions(+)
>> create mode 100644 drivers/i2c/kona_i2c.c
> [...]
>> diff --git a/drivers/i2c/kona_i2c.c b/drivers/i2c/kona_i2c.c
>> new file mode 100644
>> index 0000000..9f18b74
>> --- /dev/null
>> +++ b/drivers/i2c/kona_i2c.c
>> @@ -0,0 +1,730 @@
>> +/*
>> + * Copyright 2013 Broadcom Corporation. All rights reserved.
>> + *
>> + * SPDX-License-Identifier: GPL-2.0+
>> + */
>> +
>> +#include<common.h>
>> +#include<asm/io.h>
>> +#include<asm/errno.h>
>> +#include<asm/arch/sysmap.h>
>> +#include<asm/kona-common/clk.h>
>> +#include<i2c.h>
>> +
>> +/* Hardware register offsets and field defintions */
>> +#define CS_OFFSET 0x00000020
>> +#define CS_ACK_SHIFT 3
>> +#define CS_ACK_MASK 0x00000008
>> +#define CS_ACK_CMD_GEN_START 0x00000000
>> +#define CS_ACK_CMD_GEN_RESTART 0x00000001
>> +#define CS_CMD_SHIFT 1
>> +#define CS_CMD_CMD_NO_ACTION 0x00000000
>> +#define CS_CMD_CMD_START_RESTART 0x00000001
>> +#define CS_CMD_CMD_STOP 0x00000002
>> +#define CS_EN_SHIFT 0
>> +#define CS_EN_CMD_ENABLE_BSC 0x00000001
>> +
>> +#define TIM_OFFSET 0x00000024
>> +#define TIM_PRESCALE_SHIFT 6
>> +#define TIM_P_SHIFT 3
>> +#define TIM_NO_DIV_SHIFT 2
>> +#define TIM_DIV_SHIFT 0
>> +
>> +#define DAT_OFFSET 0x00000028
>> +
>> +#define TOUT_OFFSET 0x0000002c
>> +
>> +#define TXFCR_OFFSET 0x0000003c
>> +#define TXFCR_FIFO_FLUSH_MASK 0x00000080
>> +#define TXFCR_FIFO_EN_MASK 0x00000040
>> +
>> +#define IER_OFFSET 0x00000044
>> +#define IER_READ_COMPLETE_INT_MASK 0x00000010
>> +#define IER_I2C_INT_EN_MASK 0x00000008
>> +#define IER_FIFO_INT_EN_MASK 0x00000002
>> +#define IER_NOACK_EN_MASK 0x00000001
>> +
>> +#define ISR_OFFSET 0x00000048
>> +#define ISR_RESERVED_MASK 0xffffff60
>> +#define ISR_CMDBUSY_MASK 0x00000080
>> +#define ISR_READ_COMPLETE_MASK 0x00000010
>> +#define ISR_SES_DONE_MASK 0x00000008
>> +#define ISR_ERR_MASK 0x00000004
>> +#define ISR_TXFIFOEMPTY_MASK 0x00000002
>> +#define ISR_NOACK_MASK 0x00000001
>> +
>> +#define CLKEN_OFFSET 0x0000004c
>> +#define CLKEN_AUTOSENSE_OFF_MASK 0x00000080
>> +#define CLKEN_M_SHIFT 4
>> +#define CLKEN_N_SHIFT 1
>> +#define CLKEN_CLKEN_MASK 0x00000001
>> +
>> +#define FIFO_STATUS_OFFSET 0x00000054
>> +#define FIFO_STATUS_RXFIFO_EMPTY_MASK 0x00000004
>> +#define FIFO_STATUS_TXFIFO_EMPTY_MASK 0x00000010
>> +
>> +#define HSTIM_OFFSET 0x00000058
>> +#define HSTIM_HS_MODE_MASK 0x00008000
>> +#define HSTIM_HS_HOLD_SHIFT 10
>> +#define HSTIM_HS_HIGH_PHASE_SHIFT 5
>> +#define HSTIM_HS_SETUP_SHIFT 0
>> +
>> +#define PADCTL_OFFSET 0x0000005c
>> +#define PADCTL_PAD_OUT_EN_MASK 0x00000004
>> +
>> +#define RXFCR_OFFSET 0x00000068
>> +#define RXFCR_NACK_EN_SHIFT 7
>> +#define RXFCR_READ_COUNT_SHIFT 0
>> +#define RXFIFORDOUT_OFFSET 0x0000006c
>> +
>> +/* Locally used constants */
>> +#define MAX_RX_FIFO_SIZE 64U /* bytes */
>> +#define MAX_TX_FIFO_SIZE 64U /* bytes */
>> +
>> +#define I2C_TIMEOUT 100000 /* usecs */
>> +
>> +#define WAIT_INT_CHK 100 /* usecs */
>> +#if I2C_TIMEOUT % WAIT_INT_CHK
>> +#error I2C_TIMEOUT must be a multiple of WAIT_INT_CHK
>> +#endif
>> +
>> +/* Operations that can be commanded to the controller */
>> +enum bcm_kona_cmd_t {
>> + BCM_CMD_NOACTION = 0,
>> + BCM_CMD_START,
>> + BCM_CMD_RESTART,
>> + BCM_CMD_STOP,
>> +};
>> +
>> +enum bus_speed_index {
>> + BCM_SPD_100K = 0,
>> + BCM_SPD_400K,
>> + BCM_SPD_1MHZ,
>> +};
>> +
>> +/* Internal divider settings for standard mode, fast mode and fast
>> mode plus */
>> +struct bus_speed_cfg {
>> + uint8_t time_m; /* Number of cycles for setup time */
>> + uint8_t time_n; /* Number of cycles for hold time */
>> + uint8_t prescale; /* Prescale divider */
>> + uint8_t time_p; /* Timing coefficient */
>> + uint8_t no_div; /* Disable clock divider */
>> + uint8_t time_div; /* Post-prescale divider */
>> +};
>> +
>> +static const struct bus_speed_cfg std_cfg_table[] = {
>> + [BCM_SPD_100K] = {0x01, 0x01, 0x03, 0x06, 0x00, 0x02},
>> + [BCM_SPD_400K] = {0x05, 0x01, 0x03, 0x05, 0x01, 0x02},
>> + [BCM_SPD_1MHZ] = {0x01, 0x01, 0x03, 0x01, 0x01, 0x03},
>> +};
>> +
>> +struct bcm_kona_i2c_dev {
>> + void *base;
>> + uint speed;
>> + const struct bus_speed_cfg *std_cfg;
>> +};
>> +
>> +/* Keep these two defines in sync */
>> +#define DEF_SPD 100000
>> +#define DEF_SPD_ENUM BCM_SPD_100K
>> +
>> +#define DEF_DEVICE(num) \
>> +{(void *)CONFIG_SYS_I2C_BASE##num, DEF_SPD,&std_cfg_table[DEF_SPD_ENUM]}
>> +
>> +static struct bcm_kona_i2c_dev g_i2c_devs[CONFIG_SYS_MAX_I2C_BUS] = {
>> +#ifdef CONFIG_SYS_I2C_BASE0
>> + DEF_DEVICE(0),
>> +#endif
>> +#ifdef CONFIG_SYS_I2C_BASE1
>> + DEF_DEVICE(1),
>> +#endif
>> +#ifdef CONFIG_SYS_I2C_BASE2
>> + DEF_DEVICE(2),
>> +#endif
>> +#ifdef CONFIG_SYS_I2C_BASE3
>> + DEF_DEVICE(3),
>> +#endif
>> +#ifdef CONFIG_SYS_I2C_BASE4
>> + DEF_DEVICE(4),
>> +#endif
>> +#ifdef CONFIG_SYS_I2C_BASE5
>> + DEF_DEVICE(5),
>> +#endif
>> +};
>> +
>> +#define I2C_M_TEN 0x0010 /* ten bit address */
>> +#define I2C_M_RD 0x0001 /* read data */
>> +#define I2C_M_NOSTART 0x4000 /* no restart between msgs */
>> +
>> +struct i2c_msg {
>> + uint16_t addr;
>> + uint16_t flags;
>> + uint16_t len;
>> + uint8_t *buf;
>> +};
>> +
>> +static void bcm_kona_i2c_send_cmd_to_ctrl(struct bcm_kona_i2c_dev *dev,
>> + enum bcm_kona_cmd_t cmd)
>> +{
>> + debug("%s, %d\n", __func__, cmd);
>> +
>> + switch (cmd) {
>> + case BCM_CMD_NOACTION:
>> + writel((CS_CMD_CMD_NO_ACTION<< CS_CMD_SHIFT) |
>
> Nitpicking, should be:
> writel((CS_CMD_CMD_NO_ACTION << CS_CMD_SHIFT)
> ^ ^
Will fix this.
>
> Such formatting style seems to go through your complete patch ... maybe
> you got this source from somewhere, and you do not want to change this.
> But if so, please add such information in your commit message, see:
>
> http://www.denx.de/wiki/view/U-Boot/Patches#Attributing_Code_Copyrights_Sign
Thanks for the pointer.
>
>
> Thanks!
>
> Beside of this, your patch looks good to me.
Great, thanks for the review.
>
> bye,
> Heiko
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-12-16 11:38 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-12-16 11:38 UTC (permalink / raw)
To: u-boot
This is due to UDC driver optimizations.
Also a code cleanup for THOR gadget has been included.
Lukasz Majewski (6):
usb:gadget:ums: Replace malloc calls with memalign to fix cache
buffer alignment
usb:udc:samsung: Remove redundant cache operation from Samsung UDC
driver
usb:udc:samsung: Allow burst transfers for non EP0 endpints
usb:udc:samsung: Zero copy approach for data passed to Samsung's UDC
driver
usb:gadget:f_thor: Allocate request up to THOR_PACKET_SIZE not
ep->maxpacket
usb:gadget:f_thor: cosmetic: Remove debug memset
drivers/usb/gadget/f_mass_storage.c | 4 +-
drivers/usb/gadget/f_thor.c | 4 +-
drivers/usb/gadget/s3c_udc_otg.c | 19 +++----
drivers/usb/gadget/s3c_udc_otg_xfer_dma.c | 87 ++++++++++++-----------------
include/usb/s3c_udc.h | 5 +-
5 files changed, 49 insertions(+), 70 deletions(-)
--
1.7.10.4
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-12-16 11:38 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-12-16 11:38 UTC (permalink / raw)
To: u-boot
AT45DB041D spi flash.
>commit f4f51a8ff894d34eb332f0d11f6c73c7bf509848
>Author: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
>Date: Wed Oct 2 19:36:58 2013 +0530
>
> sf: probe: Add support for erase sector selection flag
>
> SECT_4K, SECT_32K and SECT_64K opeartions are performed to
> to specific flash by adding a SECT* flag on respective
> spi_flash_params.flag param.
>
>Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Prior to this patch erase size was same as sector size; which is 64 * 1024 (64k).
This 64K was replaced with 4k and timeout for erase started.
If following patch is applied write/erase works well (See bottom) on top of
above commit. But similar change on latest git head still has some problem
with spi erase.
Thanks
Yogi
diff --git a/drivers/mtd/spi/spi_flash_probe.c b/drivers/mtd/spi/spi_flash_probe.c
index 9c2e115..9e1c4c5 100644
--- a/drivers/mtd/spi/spi_flash_probe.c
+++ b/drivers/mtd/spi/spi_flash_probe.c
@@ -41,7 +41,7 @@ static const struct spi_flash_params spi_flash_params_table[] = {
#ifdef CONFIG_SPI_FLASH_ATMEL /* ATMEL */
{"AT45DB011D", 0x1f2200, 0x0, 64 * 1024, 4, SECT_4K},
{"AT45DB021D", 0x1f2300, 0x0, 64 * 1024, 8, SECT_4K},
- {"AT45DB041D", 0x1f2400, 0x0, 64 * 1024, 8, SECT_4K},
+ {"AT45DB041D", 0x1f2400, 0x0, 64 * 1024, 8, 0},
{"AT45DB081D", 0x1f2500, 0x0, 64 * 1024, 16, SECT_4K},
{"AT45DB161D", 0x1f2600, 0x0, 64 * 1024, 32, SECT_4K},
{"AT45DB321D", 0x1f2700, 0x0, 64 * 1024, 64, SECT_4K},
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2013-12-16 11:38 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-12-16 11:38 UTC (permalink / raw)
To: u-boot
Maybe you lost a step in the command line : "export ARCH=3Daarch64"
=20
I usually put it in batch file:
export ARCH=3Daarch64
export
CROSS_COMPILE=3D/home/lion/gcc-linaro-aarch64/bin/aarch64-linux-gnu-
make vexpress_aemv8a
=20
=20
Best wishes,
------_=_NextPart_001_01CF27C8.D70FA1D4--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-12-12 7:30 Loc Ho
0 siblings, 0 replies; 732+ messages in thread
From: Loc Ho @ 2013-12-12 7:30 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds support for APM X-Gene SoC 15Gbps Multi-purpose PHY. This
is the physical layer interface for the corresponding host controller. This
driver uses the new PHY generic framework posted by Kishon Vijay Abrahm.
In addition, the new PHY generic framework is patched to provide an
function to set the speed of the PHY.
v4
* Update documentation with 'apm,' instead 'apm-'
* Change DTS override parameter to have 'apm,'
* Add select GENERIC_PHY to Kconfig PHY_XGENE
* Make override parameters to be pair of three values instead one
* Some minor comment and indentation changes
* Remove error register addition offset
* Add ULL to constants
* Use module_init instead subsys_initcall
* Make DTS node based on first register address
* Update override setting values
v3
* Major re-write of the code based on various review comments
* Support external clock only at the moment
* Support SATA mode only at the moment
* No UEFI support at the moment
v2
* Remove port knowledge from functions
* Make all functions static
* Remove ID completely
* Make resource requirement based on compatible type
* Rename override PHY parameters with more descriptive name
* Add override PHY parameter for per controller, per port, and per speed
* Patch the generic PHY frame to expose set_speed operation
v1
* Initial version
Signed-off-by: Loc Ho <lho@apm.com>
Signed-off-by: Tuan Phan <tphan@apm.com>
Signed-off-by: Suman Tripathi <stripathi@apm.com>
---
Loc Ho (4):
PHY: Add function set_speed to generic PHY framework
Documentation: Add APM X-Gene SoC 15Gbps Multi-purpose PHY driver
binding documentation
PHY: add APM X-Gene SoC 15Gbps Multi-purpose PHY driver
arm64: Add APM X-Gene SoC 15Gbps Multi-purpose PHY DTS entries
.../devicetree/bindings/ata/apm-xgene-phy.txt | 89 +
arch/arm64/boot/dts/apm-storm.dtsi | 31 +
drivers/phy/Kconfig | 7 +
drivers/phy/Makefile | 2 +
drivers/phy/phy-core.c | 21 +
drivers/phy/phy-xgene.c | 1854 ++++++++++++++++++++
include/linux/phy/phy.h | 8 +
7 files changed, 2012 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/ata/apm-xgene-phy.txt
create mode 100644 drivers/phy/phy-xgene.c
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-11-01 7:04 Xiubo Li
0 siblings, 0 replies; 732+ messages in thread
From: Xiubo Li @ 2013-11-01 7:04 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
This patch series is mostly Freescale's SAI SoC Digital Audio Interface driver implementation. And the implementation is only compatible with device tree definition.
This patch series is based on linux-next and has been tested on Vybrid VF610 Tower board using device tree.
Changed in v2:
- Use default settings for the generic dmaengine PCM driver.
- Separate receive and transmit setting in most functions, but some couldn't for the HW limitation.
- Drop some not reduntant code.
- Use devm_snd_soc_register_component() instead of snd_soc_register_component().
- Use devm_snd_soc_register_card() instead of devm_snd_soc_register_card().
- Adjust the code sentences sequence.
- Make the namespacing consistent.
- Rename CONFIG_SND_SOC_FSL_SGTL5000 to CONFIG_SND_SOC_FSL_SGTL5000_VF610.
- Drop some meaningless lines.
- Rename the binding document file.
Added in v1:
- Add SAI SoC Digital Audio Interface driver.
- Add Freescale SAI ALSA SoC Digital Audio Interface node for VF610.
- Enables SAI ALSA SoC DAI device for Vybrid VF610 TOWER board.
- Add device tree bindings for Freescale SAI.
- Revise the bugs about the sgt15000 codec.
- Add SGT15000 based audio machine driver.
- Enable SGT15000 codec based audio driver node for VF610.
- Add device tree bindings for Freescale VF610 sound.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-10-15 19:54 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-10-15 19:54 UTC (permalink / raw)
To: u-boot
need it /before/ booting the board. So currently I need to patch the
environment files for it.
>> I will rework the environments as .env files but I don't want to hold
>> this change until this is accepted.
>
> Please be patient, like we all are. It's better to wait a bit now,
> then adding work now, and adding more work later to clean up the mess
> again.
The work has already been done.
>> My patch is fine and could go in now as is. Once Simon's patches get
>> in I will post another series reworking the environment to convert it
>> to the .env file format but please don't block on this.
>
> I agree with Stefano that we should not add more to the already
> existing amount of env settings but instead wait for a cleaner way.
> Please be patient - you lose nothing here.
I really see no point in holding it as the work has been done already;
it is Stefano call but I disagree with postpone it as work is done and
being in use.
I will comment on Simon's patch to clarify my understanding there.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-10-15 19:54 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-10-15 19:54 UTC (permalink / raw)
To: u-boot
At present U-Boot environment variables, and thus scripts, are defined
> by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text
> to this file and dealing with quoting and newlines is harder than it
> should be. It would be better if we could just type the script into a
> text file and have it included by U-Boot.
Well yes I could adjust 'env export -t' to use the same format - is that a
good idea, or not? I can see down-sides. We can of course convert existing
files brought in by 'env import -t' (by making the import flexible) but I
worry that there might be external tools that users have which expect the
format to be a certain way.
I agree creating a new format is not ideal - it's just that the existing C
header format is so painful...
Regards,
Simon
--485b3970d160c06fb304e9d48797--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-10-15 19:54 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-10-15 19:54 UTC (permalink / raw)
To: u-boot
if (!sig.clk_pol)
di_gen |= DI_GEN_POLARITY_DISP_CLK;
Applying the same logic into U-boot fixes the HDMI image stability.
[1] git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/drivers/mxc/ipu3/ipu_disp.c?h=imx_3.0.35_4.1.0
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
drivers/video/ipu_disp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/ipu_disp.c b/drivers/video/ipu_disp.c
index 2e91356..22ac142 100644
--- a/drivers/video/ipu_disp.c
+++ b/drivers/video/ipu_disp.c
@@ -1178,7 +1178,7 @@ int32_t ipu_init_sync_panel(int disp, uint32_t pixel_clk,
if (sig.Vsync_pol)
di_gen |= DI_GEN_POLARITY_3;
- if (sig.clk_pol)
+ if (!sig.clk_pol)
di_gen |= DI_GEN_POL_CLK;
}
--
1.8.1.2
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2013-10-15 19:54 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-10-15 19:54 UTC (permalink / raw)
To: u-boot
OTG -> SPL -> DFU -> U-Boot Image -> Jump to U-Boot ?
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-10-15 19:54 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-10-15 19:54 UTC (permalink / raw)
To: u-boot
used these registers to work around some bugs? This might end up
breaking those. Note that TI81xx DDR frequencies are much higher
compared to AM335x so issues related to this might not show up
right now.
Regards,
Vaibhav
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-10-15 19:54 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-10-15 19:54 UTC (permalink / raw)
To: u-boot
Best wishes,
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-10-15 19:54 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-10-15 19:54 UTC (permalink / raw)
To: u-boot
quality of and productivity of custodians/maintainers goes way up.
--vb
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-10-15 19:54 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-10-15 19:54 UTC (permalink / raw)
To: u-boot
things change across boards that go into production. I don't think it
makes sense to throw away all that knowledge and go ahead
assuming we will never make a change. The request for change is just
to future proof the current code and have the EEPROM actually help us
do our jobs. Why? Because life's too short to keep worrying about why a
board rev that a you pick up from a neighbor's desk doesn't boot, hooking
up the JTAG to trace the DDR setup code, figure out what needs to change
in the boot-loader, add in the appropriate check and then get to the task
at hand ;)
Regards,
Vaibhav
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-10-15 19:54 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-10-15 19:54 UTC (permalink / raw)
To: u-boot
>
/home/abraham/SPACE/BISQUARE/source/uboot_update/gcc-linaro-arm/bin/arm-linux-gnueabihf-gcc
--version
arm-linux-gnueabihf-gcc (crosstool-NG linaro-1.13.1-4.8-2013.07-1 - Linaro
GCC 2013.07) 4.8.2 20130624 (prerelease)
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-10-15 19:54 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-10-15 19:54 UTC (permalink / raw)
To: u-boot
>
/home/abraham/SPACE/BISQUARE/source/uboot_update/gcc-SourceryCodeBenchLite-arm/bin/arm-none-linux-gnueabi-gcc
--version
arm-none-linux-gnueabi-gcc (Sourcery CodeBench Lite 2013.05-24) 4.7.3
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
This is the second time I've had issues because of the toolchain. The last
time was because the utility omap4boot wouldn't work unless it was built
from MentorGraphics toolchain. Using Linaro's version, it would build
successfully, but the resulting image wouldn't run.
Has anyone else on this mailing list had trouble when using Linaro's
toolchain? Any theories on why it's not working as intended?
Really puzzled,
Abraham V.
--089e013c622030779a04ec350e47--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-10-15 19:54 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-10-15 19:54 UTC (permalink / raw)
To: u-boot
byte EEPROMs.
Regards,
Alexey
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-10-15 19:54 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-10-15 19:54 UTC (permalink / raw)
To: u-boot
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
If "CONFIG_SYS_I2C_EEPROM_ADDR_LEN =3D=3D 1":
addr[0] =3D offset >> 8;
If "CONFIG_SYS_I2C_EEPROM_ADDR_LEN > 1":
addr[0] =3D offset >> 16;
And in both cases then OR with "dev_addr":
addr[0] |=3D dev_addr;
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
In other words it gets both real I2S slave address + MSB bits of offset.
But note that "offset" value stays unchanged.
So if you pass both "addr[0]" (which already has MSB bits of "offset")
and "offset" itself then you'll get completely incorrect I2C command.
> @@ -339,7 +339,7 @@ int eeprom_write (unsigned dev_addr, unsigned offset,=
uchar *buffer, unsigned cn
> /* Write is enabled ... now write eeprom value.
> */
> #endif
> - if (i2c_write (addr[0], addr[1], alen-1, buffer, len) !=3D 0)
> + if (i2c_write(addr[0], offset, alen - 1, buffer, len))
> rcode =3D 1;
>=20
> #endif
Same goes to "eeprom_write".
Moreover I'd say that this address/offset tricks are very
EEPROM-specific and because of this we'd better keep it here and don't
modify generic I2C code.
Regards,
Alexey
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-09-24 3:13 Rohit Vaswani
0 siblings, 0 replies; 732+ messages in thread
From: Rohit Vaswani @ 2013-09-24 3:13 UTC (permalink / raw)
To: linux-arm-kernel
Date: Mon, 23 Sep 2013 19:51:25 -0700
Subject: [PATCH 1/3] ARM: debug: Create CONFIG_DEBUG_MSM_UART and re-organize
the selects for MSM
Create the hidden config DEBUG_MSM_UART and clean-up the default selection
for CONFIG_DEBUG_LL_INCLUDE.
Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
---
arch/arm/Kconfig.debug | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 9762c84..e18a6fc 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -318,6 +318,7 @@ choice
config DEBUG_MSM_UART1
bool "Kernel low-level debugging messages via MSM UART1"
depends on ARCH_MSM7X00A || ARCH_MSM7X30 || ARCH_QSD8X50
+ select DEBUG_MSM_UART
help
Say Y here if you want the debug print routines to direct
their output to the first serial port on MSM devices.
@@ -325,6 +326,7 @@ choice
config DEBUG_MSM_UART2
bool "Kernel low-level debugging messages via MSM UART2"
depends on ARCH_MSM7X00A || ARCH_MSM7X30 || ARCH_QSD8X50
+ select DEBUG_MSM_UART
help
Say Y here if you want the debug print routines to direct
their output to the second serial port on MSM devices.
@@ -332,6 +334,7 @@ choice
config DEBUG_MSM_UART3
bool "Kernel low-level debugging messages via MSM UART3"
depends on ARCH_MSM7X00A || ARCH_MSM7X30 || ARCH_QSD8X50
+ select DEBUG_MSM_UART
help
Say Y here if you want the debug print routines to direct
their output to the third serial port on MSM devices.
@@ -340,6 +343,7 @@ choice
bool "Kernel low-level debugging messages via MSM 8660 UART"
depends on ARCH_MSM8X60
select MSM_HAS_DEBUG_UART_HS
+ select DEBUG_MSM_UART
help
Say Y here if you want the debug print routines to direct
their output to the serial port on MSM 8660 devices.
@@ -348,6 +352,7 @@ choice
bool "Kernel low-level debugging messages via MSM 8960 UART"
depends on ARCH_MSM8960
select MSM_HAS_DEBUG_UART_HS
+ select DEBUG_MSM_UART
help
Say Y here if you want the debug print routines to direct
their output to the serial port on MSM 8960 devices.
@@ -880,6 +885,10 @@ config DEBUG_STI_UART
bool
depends on ARCH_STI
+config DEBUG_MSM_UART
+ bool
+ depends on ARCH_MSM
+
config DEBUG_LL_INCLUDE
string
default "debug/8250.S" if DEBUG_LL_UART_8250 || DEBUG_UART_8250
@@ -895,11 +904,7 @@ config DEBUG_LL_INCLUDE
DEBUG_IMX53_UART ||\
DEBUG_IMX6Q_UART || \
DEBUG_IMX6SL_UART
- default "debug/msm.S" if DEBUG_MSM_UART1 || \
- DEBUG_MSM_UART2 || \
- DEBUG_MSM_UART3 || \
- DEBUG_MSM8660_UART || \
- DEBUG_MSM8960_UART
+ default "debug/msm.S" if DEBUG_MSM_UART
default "debug/omap2plus.S" if DEBUG_OMAP2PLUS_UART
default "debug/sirf.S" if DEBUG_SIRFPRIMA2_UART1 || DEBUG_SIRFMARCO_UART1
default "debug/sti.S" if DEBUG_STI_UART
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2013-09-15 9:49 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-09-15 9:49 UTC (permalink / raw)
To: ath9k-devel
selection is just a few days away) -- but June would be better anyway.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-09-15 9:49 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-09-15 9:49 UTC (permalink / raw)
To: ath9k-devel
generated acks.
Enabling hw acks results in duplicate, identical acks being sent by the
access point on successful frame receipt.
The difference is just in timings: while hw acks is usually received in
less then 10 or 20 microseconds from a successful frame receipt, sw
generated acks arrive in 2-300 microseconds.
We suppose the problem is in Clear Channel Assessment: the hardware waits
the right (CSMA compliant) time to send the frame while we would like it to
send the ack frame ASAP (i.e. wait SIFS instead of AIFS).
Tried a few flags with no success (tested with or without such flags and no
apparent change happened).
Flags are:
AR_DIAG_FORCE_RX_CLEAR
AR_DIAG_FORCE_CH_IDLE_HIGH
AR_DIAG_IGNORE_VIRT_CS
AR_D_GBL_IFS_MISC_IGNORE_BACKOFF
Possible "next steps":
- choose the correct hw queue (now using queue skb->queue_mapping=3 and
skb->priority=7)
- find out the correct register values for disabling the virtual and
physical carrier sense (AR_DIAG_SW) for ath9k.
- find out if such values are "honored" in our card or if should be better
to simply change the atheros chipset family or card manufacturer
- disabling back-off setting the cwmin and cwmax to zero on the choosen
queue And also setting AIFS=1 (or zero?)
- disabling any debug code possibly inserted during coding phase (according
to
http://adrianchadd.blogspot.it/2012/11/be-careful-of-adding-debugging-as.html
)
Any suggestion?
Is anyone interested in collaborating in softMAC development? Right now we
are thinking about standard ack mechanism (i.e. a/g) but it could be
extended to blockAck (802.11e or "n" versions of a/g)?
Any feedback welcome...
Thnkz in advance!!!
Alex
--047d7b15ad979ce54c04edbbc6dc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hello everybody!<br>I's my first time writing to the l=
ist, while I'm following it with interest for some time.<br><br>We'=
re developing some MAC functions in software for testing purposes.<br><br>
The most challenging part seems to be generating Acks in software.<br><br>T=
hree main tasks:<br>1. Disabling Link Layer Acks in hardware<br>2. Generati=
ng Acks as "low" as possible in driver stack<br>3. sending such a=
cks as quickly as possible<br>
<br>Now, task 1 and 2 are done in ath9k: task 1 setting the appropriate fla=
g in the register and task 2 coding link layer ack generation in ath9k_rx t=
asklet.<br><br>We have a problem in task 3.<br>It seems that the ack frame =
is sent like regular frames, respecting CCA, while we would need the ack fr=
ames to be sent immediately, as soon as they've been put in the tx queu=
e.<br>
<br>Test environment<br>Access Point <br>Hardware: Alix 2d2 board, Compex W=
LM200NX MiniPCI network adapter (should be Chipset AR9220 according to vend=
or datasheet - kernel Dmesg says "ieee80211 phy0: Atheros AR9280 Rev:2=
mem=3D0xd0ca0000, irq=3D9") <br>
Software: OpenWRT REVISION r37112<br><br>Client<br>any WiFi compliant clien=
t such as smartphones and laptop<br><br>Sniffer<br>wireshark on a laptop wi=
th a mon interface<br><br><br>Results<br>From a sniffer perspective you can=
not distinguish between hw and sw generated acks.<br>
Enabling hw acks results in duplicate, identical acks being sent by the acc=
ess point on successful frame receipt.<br>The difference is just in timings=
: while hw acks is usually received in less then 10 or 20 microseconds from=
a successful frame receipt, sw generated acks arrive in 2-300 microseconds=
.<br>
<br>We suppose the problem is in Clear Channel Assessment: the hardware wai=
ts the right (CSMA compliant) time to send the frame while we would like it=
to send the ack frame ASAP (i.e. wait SIFS instead of AIFS).<br><br>Tried =
a few flags with no success (tested with or without such flags and no appar=
ent change happened).<br>
Flags are:<br><br>AR_DIAG_FORCE_RX_CLEAR<br>AR_DIAG_FORCE_CH_IDLE_HIGH<br>A=
R_DIAG_IGNORE_VIRT_CS<br>AR_D_GBL_IFS_MISC_IGNORE_BACKOFF<br><br><br>Possib=
le "next steps":<br><br>- choose the correct hw queue =A0(now usi=
ng queue skb->queue_mapping=3D3 and skb->priority=3D7)<br>
- find out the correct register values for disabling the virtual and physic=
al carrier sense (AR_DIAG_SW) for ath9k.<br>- find out if such values are &=
quot;honored" in our card or if should be better to simply change the =
atheros chipset family or card manufacturer<br>
- disabling back-off setting the cwmin and cwmax to zero on the choosen que=
ue And also setting AIFS=3D1 (or zero?)<br>- disabling any debug code possi=
bly inserted during coding phase (according to <a href=3D"http://adrianchad=
d.blogspot.it/2012/11/be-careful-of-adding-debugging-as.html">http://adrian=
chadd.blogspot.it/2012/11/be-careful-of-adding-debugging-as.html</a>)<br>
<br><br>Any suggestion?<br>Is anyone interested in collaborating in softMAC=
development? Right now we are thinking about standard ack mechanism (i.e. =
a/g) but it could be extended to blockAck (802.11e or "n" version=
s of a/g)?<div>
<br></div><div><br>Any feedback welcome...<br>Thnkz in advance!!!</div><div=
><br></div><div>Alex</div><div><br></div><div><br></div></div>
--047d7b15ad979ce54c04edbbc6dc--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-09-15 9:49 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-09-15 9:49 UTC (permalink / raw)
To: ath9k-devel
timestamp.
The question is, how accurated this timestamp is? The precision is in
nanoseconds, but what accuracy i can expect?
My main need is the implement a good precision TDOA algorithm.
I don't know jack about driver development, but is something that interests
me. If the accuracy is low, can i improve it in driver or firmware?
If its possible, i can even trade reception packet speed for a better
accuracy in timestamp.
The other question is, what is the difference between the ath9k_htc and
carl9170 drivers? Both support the AR9287 (from the debian wiki).
Thanks for all
Links:
Wireshark community:
http://ask.wireshark.org/questions/28683/recommended-wireless-adapter-usb-with-linux-wireshark-that-reports-mactime-in-radiotap-header
Debian Wiki ath9k_htc: https://wiki.debian.org/ath9k_htc
Debian Wiki carl9170: https://wiki.debian.org/carl9170
--001a11335f40ad0de604f2af55f8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi,<div><br></div><div>I have one question about hardware =
timestamp in Atheros chipsets.</div><div>From a post in Wireshark community=
, the chipset AR9287 can do hardware timestamp.</div><div><br></div><div>Th=
e question is, how accurated this timestamp is? The precision is in nanosec=
onds, but what accuracy i can expect?</div>
<div><br></div><div>My main need is the implement a good precision TDOA alg=
orithm.=A0</div><div><br></div><div>I don't know jack about driver deve=
lopment, but is something that=A0interests me. If the accuracy is low, can =
i improve it in driver or firmware?=A0</div>
<div>If its possible, i can even trade reception packet speed for a better =
accuracy in timestamp.</div><div><br></div><div>The other question is, what=
is the difference between the ath9k_htc and carl9170 drivers? Both support=
the AR9287 (from the debian wiki).</div>
<div><br></div><div>Thanks for all</div><div><br></div><div>Links:</div><di=
v><br></div><div>Wireshark community: <a href=3D"http://ask.wireshark.org/q=
uestions/28683/recommended-wireless-adapter-usb-with-linux-wireshark-that-r=
eports-mactime-in-radiotap-header">http://ask.wireshark.org/questions/28683=
/recommended-wireless-adapter-usb-with-linux-wireshark-that-reports-mactime=
-in-radiotap-header</a></div>
<div><br></div><div>Debian Wiki ath9k_htc:=A0<a href=3D"https://wiki.debian=
.org/ath9k_htc">https://wiki.debian.org/ath9k_htc</a></div><div><br></div><=
div>Debian Wiki carl9170:=A0<a href=3D"https://wiki.debian.org/carl9170">ht=
tps://wiki.debian.org/carl9170</a></div>
</div>
--001a11335f40ad0de604f2af55f8--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-09-02 17:01 Drasko DRASKOVIC
0 siblings, 0 replies; 732+ messages in thread
From: Drasko DRASKOVIC @ 2013-09-02 17:01 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
In socfpga.dts I can see following definitions :
/* Local timer */
timer at fffec600 {
compatible = "arm,cortex-a9-twd-timer";
reg = <0xfffec600 0x100>;
interrupts = <1 13 0xf04>;
};
timer0: timer0 at ffc08000 {
compatible = "snps,dw-apb-timer-sp";
interrupts = <0 167 4>;
reg = <0xffc08000 0x1000>;
};
timer1: timer1 at ffc09000 {
compatible = "snps,dw-apb-timer-sp";
interrupts = <0 168 4>;
reg = <0xffc09000 0x1000>;
};
timer2: timer2 at ffd00000 {
compatible = "snps,dw-apb-timer-osc";
interrupts = <0 169 4>;
reg = <0xffd00000 0x1000>;
};
timer3: timer3 at ffd01000 {
compatible = "snps,dw-apb-timer-osc";
interrupts = <0 170 4>;
reg = <0xffd01000 0x1000>;
};
However, from my board's shell :
root at socfpga_cyclone5:~# cat /proc/interrupts
CPU0 CPU1
525: 24935 24717 GIC twd
648: 801 0 GIC eth0
653: 0 0 GIC dwc_otg, dwc_otg_pcd, dwc_otg_hcd:usb1
656: 0 0 GIC dwc_otg, dwc_otg_pcd, dwc_otg_hcd:usb2
667: 163006 0 GIC dw-mci
679: 0 0 GIC ff705000.spi
682: 0 0 GIC dw_spi0
684: 0 0 GIC dw_spi1
686: 6 0 GIC ffc04000.i2c
687: 0 0 GIC ffc05000.i2c
690: 2390 0 GIC serial
697: 9 0 GIC timer2
IPI0: 0 0 CPU wakeup interrupts
IPI1: 0 0 Timer broadcast interrupts
IPI2: 1268 1289 Rescheduling interrupts
IPI3: 0 0 Function call interrupts
IPI4: 3 1 Single function call interrupts
IPI5: 0 0 CPU stop interrupts
Err: 0
So, I can see only timer2.
root at socfpga_cyclone5:~# find / -name "timer*"
/proc/timer_list
/proc/device-tree/soc/timer3 at ffd01000
/proc/device-tree/soc/timer2 at ffd00000
/proc/device-tree/soc/timer1 at ffc09000
/proc/device-tree/soc/timer0 at ffc08000
/proc/device-tree/soc/timer at fffec600
/proc/device-tree/aliases/timer3
/proc/device-tree/aliases/timer2
/proc/device-tree/aliases/timer1
/proc/device-tree/aliases/timer0
/sys/kernel/debug/tracing/events/timer
/sys/kernel/debug/tracing/events/timer/timer_cancel
/sys/kernel/debug/tracing/events/timer/timer_expire_exit
/sys/kernel/debug/tracing/events/timer/timer_expire_entry
/sys/kernel/debug/tracing/events/timer/timer_start
/sys/kernel/debug/tracing/events/timer/timer_init
/sys/module/oprofile/parameters/timer
root at socfpga_cyclone5:~#
Where is defined which timer will be present, activated and
initialized on the board - i.e. only timer2 is active in this case,
and I would like to use timer1.
BR,
Drasko
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-08-24 9:29 Haojian Zhuang
0 siblings, 0 replies; 732+ messages in thread
From: Haojian Zhuang @ 2013-08-24 9:29 UTC (permalink / raw)
To: linux-arm-kernel
Changelog:
v8:
1. Drop to support CLK_GATE_SEPERATED_REG in common clock gate driver.
Support this feature in hi3xxx clock driver.
2. Clean unnecessary device node in DTS.
3. Define all clocks in hi3620-clk.dtsi. And all clock nodes are defined
in the clocks node.
4. Fix the clock gate & clock mux for timer.
5. Rename timer0~4 to dual_timer0~4 in DTS file. It's used to make
name clearer.
v7:
1. Add hi3xxx_defconfig.
2. Use reg property in clock node.
3. Drop origin clock divider table.
4. Reuse clock divider register helper.
5. Reuse clock gate register helper.
6. Append CLK_GATE_SEPERATED_REG flag in order to support Hisilicon
Hi3620 SoC.
7. Rebase DEBUG_LL for Hi3xxx.
8. Add more clock node in DTS file.
v6:
1. Remove hisilicon string from properties in clock driver.
2. Replace array by pointer in clock driver. Since only sctrl parent
node exists at this time.
v5:
1. Remove HIWORD clk patches since they're merged into clk git tree.
2. Set hisilicon,clk-reset property of clkgate node is optional.
3. Update on commandline args in DTS file. Remove earlyprintk, mem, nfs.
4. Move gpio-keys out of amba node in DTS file.
v4:
1. Add clk gate with HIWORD mask for Rockchip.
2. Update comments and code of HIWORD flags for mux/divider.
3. Append a mux without HIWORD mask in Hisilicon 3620.
4. Fix the pinmux setting in Hi4511.
v3:
1. Use clk_register_mux_table().
v2:
1. Reuse mux & divider driver. So append CLK_MUX_HIWORD_MASK &
CLK_DIVIDER_HIWORD_MASK for Hi3620 SoC.
2. Fix system timer running too fast because wrong divider is choosen.
3. Remove .init_irq in DT machine descriptor.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-08-18 1:03 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-08-18 1:03 UTC (permalink / raw)
To: u-boot
improvement that wasn't possible before the sync.
-Scott
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-08-18 1:03 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-08-18 1:03 UTC (permalink / raw)
To: u-boot
overo/duovero_mux_data.h"
{UART4_RX, (PTU | IEN | M0)}, /* uart4_rx */
{UART4_TX, (M0)}, /* uart4_tx */
I changed "include/configs/omap4_common.h"
#define CONFIG_SYS_NS16550_COM3 UART3_BASE
to read
#define CONFIG_SYS_NS16550_COM3 UART4_BASE
and added the UART4_BASE definition to "arch/arm/include/asm/arch-omap4/oma=
p.h":
#define UART4_BASE (OMAP44XX_L4_PER_BASE + 0x6e000)
this should be the correct base address for uart4 from what i understand.
However, it doesn't work. I also tried UART2 which doesn't work either. Onl=
y one that works is UART3.
I'm probably missing something critical so I figured i would ask here if an=
yone can give me a hint on how it's supposed to be done?
Regards
Daniel Malmquist=
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-08-18 1:03 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-08-18 1:03 UTC (permalink / raw)
To: u-boot
overo/duovero_mux_data.h"
{UART4_RX, (PTU | IEN | M0)}, /* uart4_rx */
{UART4_TX, (M0)}, /* uart4_tx=
*/
I changed "include/configs/omap4_common.h"
#define CONFIG_SYS_NS16550_COM3 UART3_BASE
to read
#define CONFIG_SYS_NS16550_COM3 UART4_BASE
and added the UART4_BASE definition to "arch/arm/include/asm/arch-omap4/oma=
p.h":
#define UART4_BASE (OMAP44XX_L4_PER_BASE + 0x6e000)
this should be the correct base address for uart4 from what i understand.
However, it doesn't work. I also tried UART2 which doesn't work either. Onl=
y one that works is UART3.
I'm probably missing something critical so I figured i would ask here if an=
yone can give me a hint on how it's supposed to be done?
Regards
Daniel Malmquist
--_000_1D33A6D946BFEE4E99E977D33497B6D8A67E7B9CEXDB6ugkthse_--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-08-18 1:03 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-08-18 1:03 UTC (permalink / raw)
To: u-boot
zImage + board.dtb).
Best wishes,
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-08-18 1:03 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-08-18 1:03 UTC (permalink / raw)
To: u-boot
alphabetically)
** Lukasz Majewski
- DFU
** Simon Glass
- Driver model
- Kconfig
- Patman tutorial
- U-Boot configuration through device tree
** Tom Rini
- Redundant booting with U-Boot (or: Welcome to the redundancy theatre
playhouse)
** Marek Vasut
- Liberating the i.MX28
How long will these talks be? Twnty or thirty minutes?
>> Sounds good. I'm not sure how the organization side of the summit is
>> being setup, but I imagine we'll be able to talk about those things.
We should of course plan for an open discussion at the end.
> Is there any link for about discussed topics with covered speakers, if
> yes please pass.
No, we are just assembling it in this thread ;)
Thanks
Detlev
--
Science is a way of thinking
much more than it is a body of knowledge.
-- Carl Sagan
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-08-18 1:03 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-08-18 1:03 UTC (permalink / raw)
To: u-boot
instead of read status- hence added E_FSR flag on spectific
flash parts.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
---
Changes for v3:
- none
Changes for v2:
- none
drivers/mtd/spi/spi_flash_probe.c | 14 +++++++++-----
include/spi_flash.h | 1 +
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/spi/spi_flash_probe.c b/drivers/mtd/spi/spi_flash_probe.c
index 9d29a59..842b03a 100644
--- a/drivers/mtd/spi/spi_flash_probe.c
+++ b/drivers/mtd/spi/spi_flash_probe.c
@@ -94,10 +94,10 @@ static const struct spi_flash_params spi_flash_params_table[] = {
{"N25Q128A", 0x20bb18, 0x0, 64 * 1024, 256, SECT_4K},
{"N25Q256", 0x20ba19, 0x0, 64 * 1024, 512, SECT_4K},
{"N25Q256A", 0x20bb19, 0x0, 64 * 1024, 512, SECT_4K},
- {"N25Q512", 0x20ba20, 0x0, 64 * 1024, 1024, SECT_4K},
- {"N25Q512A", 0x20bb20, 0x0, 64 * 1024, 1024, SECT_4K},
- {"N25Q1024", 0x20ba21, 0x0, 64 * 1024, 2048, SECT_4K},
- {"N25Q1024A", 0x20bb21, 0x0, 64 * 1024, 2048, SECT_4K},
+ {"N25Q512", 0x20ba20, 0x0, 64 * 1024, 1024, E_FSR | SECT_4K},
+ {"N25Q512A", 0x20bb20, 0x0, 64 * 1024, 1024, E_FSR | SECT_4K},
+ {"N25Q1024", 0x20ba21, 0x0, 64 * 1024, 2048, E_FSR | SECT_4K},
+ {"N25Q1024A", 0x20bb21, 0x0, 64 * 1024, 2048, E_FSR | SECT_4K},
#endif
#ifdef CONFIG_SPI_FLASH_SST /* SST */
{"SST25VF040B", 0xbf258d, 0x0, 64 * 1024, 8, SECT_4K | SST_WP},
@@ -187,7 +187,6 @@ struct spi_flash *spi_flash_validate_ids(struct spi_slave *spi, u8 *idcode)
flash->spi = spi;
flash->name = params->name;
- flash->poll_cmd = CMD_READ_STATUS;
/* Assign spi_flash ops */
flash->write = spi_flash_cmd_write_multi;
@@ -215,6 +214,11 @@ struct spi_flash *spi_flash_validate_ids(struct spi_slave *spi, u8 *idcode)
flash->erase_size = flash->sector_size;
}
+ /* Poll cmd seclection */
+ flash->poll_cmd = CMD_READ_STATUS;
+ if (params->flags & E_FSR)
+ flash->poll_cmd = CMD_FLAG_STATUS;
+
/* Flash powers up read-only, so clear BP# bits */
if (((params->jedec >> 16) == SPI_FLASH_CFI_MFR_ATMEL) ||
((params->jedec >> 16) == SPI_FLASH_CFI_MFR_MACRONIX) ||
diff --git a/include/spi_flash.h b/include/spi_flash.h
index 387af86..3e60fdc 100644
--- a/include/spi_flash.h
+++ b/include/spi_flash.h
@@ -25,6 +25,7 @@
/* SECT flags */
#define SECT_4K (1 << 0)
#define SECT_32K (1 << 1)
+#define E_FSR (1 << 2)
/* SST specific macros */
#ifdef CONFIG_SPI_FLASH_SST
--
1.8.3
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2013-08-18 1:03 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-08-18 1:03 UTC (permalink / raw)
To: u-boot
But after running board_init_f() function, uboot will relocate u-boot
code base.
So, the boot stage record "board_init_f" would be abnormal ? !
Because i did not find any code to do relocation operation for boot
stage records.
2. how to understand "start_us" fiedld in bootstage_record struct ?
bootstage_start() function will init bootstage_record->start_us.
But not find which file will call bootstage_start() .
=20
Best wishes,
=20
------_=_NextPart_001_01CEB2AC.60C9029A--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-08-18 1:03 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-08-18 1:03 UTC (permalink / raw)
To: u-boot
LAN9730 and HSIC1 is connected to the USB3503A. I do not see anything
connected to the USB PHY, or I do not yet understand it fully.
While tracing thru ehci-hcd.c I can see that for root hub enumeration
all the submit_control_msg() are sent to ehci_submit_root() and these
seem to function - port enable, status change, get descriptor etc...
As soon as it does a "get descriptor" to the device on the port, the
submit_control_msg() calls ehci_submit_async(). This then builds the
QH, qTD structures, and starts the HCD to process async requests
(CMD_ASE). This is where, I have narrowed it down to the hcd getting
into a halt state.
I do not know why it gets halted, as I haven't debugged more. Is it
possible that the phy has not been set correctly, as you mention?
This is the ouput in the enumeration phase that I am referring to that
halts the HCD:
---- 8< ----
New Device 1
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0
length 0x40
EHCI timed out on TD - token=0x80008c80
---- 8< ----
Also, there is nothing connected to the PHY that I can test basic
operation of the phy as you had mentioned earlier.
This is the code that initializes the phy etc
int ehci_hcd_init(void)
{
u32 phypwr, phyclk, rstcon, a, con, dat, offset, value, pull;
unsigned char i2c_dat;
unsigned val = 0;
unsigned int tmp;
/*
set XuhostOVERCUR to in-active by controlling ET6PUD[15:14]
0x0 : pull-up/down disabled
0x1 : pull-down enabled
0x2 : reserved
0x3 : pull-up enabled
*/
#define ETC6PUD 0x11000228
writel((__raw_readl(ETC6PUD) & ~(0x3 << 14)) | (0x3 << 14), ETC6PUD);
rstcon = __raw_readl(ETC6PUD);
printf("[SURI] - after set - ETC6PUD has value: %x\n", rstcon);
#define S5P_USB_PHY_CONTROL 0x10020704
#define S5P_HSIC_1_PHY_CONTROL 0x10020708
#define S5P_HSIC_2_PHY_CONTROL 0x1002070C
a = 1;
writel(a, S5P_USB_PHY_CONTROL); // This is what gives us the right hcd
a = readl(S5P_USB_PHY_CONTROL);
printf("[SURI] - after set - read S5P_USB_PHY_CONTROL: %x\n", a);
writel(a, S5P_HSIC_1_PHY_CONTROL);
a = readl(S5P_HSIC_1_PHY_CONTROL);
printf("[SURI] - after set - read S5P_HSIC_1_PHY_CONTROL: %x\n", a);
writel(a, S5P_HSIC_2_PHY_CONTROL);
a = readl(S5P_HSIC_2_PHY_CONTROL);
printf("[SURI] - after set - read S5P_HSIC_2_PHY_CONTROL: %x\n", a);
#define EXYNOS4_USB20PHY_CFG 0x1001021C
a = 1;
writel(a, EXYNOS4_USB20PHY_CFG);
#define EXYNOS4_PHYPWR 0x125B0000
#define EXYNOS4_PHYCLK 0x125B0004
#define EXYNOS4_RSTCON 0x125B0008
phyclk = 5;
writel(phyclk, EXYNOS4_PHYCLK);
/* set to normal of Device */
#define PHY0_NORMAL_MASK (0x39 << 0)
phypwr = readl(EXYNOS4_PHYPWR) & ~PHY0_NORMAL_MASK;
writel(phypwr, EXYNOS4_PHYPWR);
/* set to normal of Host */
phypwr = readl(EXYNOS4_PHYPWR);
#define PHY1_STD_NORMAL_MASK (0x7 << 6)
#define EXYNOS4X12_HSIC0_NORMAL_MASK (0x7 << 9)
#define EXYNOS4X12_HSIC1_NORMAL_MASK (0x7 << 12)
phypwr &= ~(PHY1_STD_NORMAL_MASK
| EXYNOS4X12_HSIC0_NORMAL_MASK | EXYNOS4X12_HSIC1_NORMAL_MASK);
writel(phypwr, EXYNOS4_PHYPWR);
/* reset both PHY and Link of Device */
#define PHY0_SWRST_MASK (0x7 << 0)
rstcon = readl(EXYNOS4_RSTCON) | PHY0_SWRST_MASK;
writel(rstcon, EXYNOS4_RSTCON);
udelay(10);
rstcon &= ~PHY0_SWRST_MASK;
writel(rstcon, EXYNOS4_RSTCON);
/* reset both PHY and Link of Host */
#define EXYNOS4X12_HOST_LINK_PORT_SWRST_MASK (0xf << 7)
#define EXYNOS4X12_PHY1_SWRST_MASK (0xf << 3)
rstcon = readl(EXYNOS4_RSTCON)
| EXYNOS4X12_HOST_LINK_PORT_SWRST_MASK
| EXYNOS4X12_PHY1_SWRST_MASK;
writel(rstcon, EXYNOS4_RSTCON);
udelay(10);
rstcon &= ~(EXYNOS4X12_HOST_LINK_PORT_SWRST_MASK
| EXYNOS4X12_PHY1_SWRST_MASK);
writel(rstcon, EXYNOS4_RSTCON);
udelay(80);
hccr = (struct ehci_hccr *) 0x12580000;
hcor = (struct ehci_hcor *)((uint32_t) hccr
+ HC_LENGTH(ehci_readl(&hccr->cr_capbase)));
printf("Exynos4412-ehci: init hccr %x and hcor %x hc_length %x\n",
(uint32_t)hccr, (uint32_t)hcor,
(uint32_t)HC_LENGTH(ehci_readl(&hccr->cr_capbase)));
mdelay(100);
/* Here is where I reset the usb3503a */
/* GPX3_5 is NRESET, GPX3_4 is HUB_CONNECT and GPX3_0 is NINT */
/* The above is from the odroid-u2 schematics */
#define GPX3BASE ((void *) (0x11000C60))
/* Start */
gpio_direction_output(GPX3BASE, 5, 0);
gpio_set_value(GPX3BASE, 5, 0);
mdelay(100);
/* RefCLK 24MHz */
gpio_direction_output(GPX3BASE, 0, 0);
gpio_set_value(GPX3BASE, 0, 0);
mdelay(100);
gpio_direction_output(GPX3BASE, 4, 0);
gpio_set_value(GPX3BASE, 4, 0);
mdelay(100);
// RESET pin set to 1
gpio_set_value(GPX3BASE, 5, 1);
// Hub Wait RefClk stage
mdelay(10);
// Hub Configuration stage
a = usb3503_read(USB3503_SP_ILOCK, &i2c_dat, (unsigned char) 1);
val = i2c_dat;
printf("Read %x from USB3503 SP_ILOCK\n", i2c_dat); // Reads
32 which is default
// Other i2c can follow here if need be for configuring the usb3503a
// Set CONNECT to 1 to move to hub configure phase.
gpio_set_value(GPX3BASE, 4, 1);
mdelay(10);
// Make INT line as input.
gpio_direction_input(GPX3BASE, 0);
mdelay(10);
return 0;
}
>
>>
>> When it comes to starting up usb via usb start, I seem to hit the below
>> sequence - with debug on ... The u-boot is quite an older u-boot, but I
>> have ported most of the usb code over from the arndale port over at
>> insignal - which seems to have usb working (they too have a usb3503a but
>> with exynos5)
>>
>> My question is how do I debug this to get it working. Looks like the hcd
>> does not see the usb3503a, am I correct?
>> ---------------------------- 8< ----------------------------
>> (Re)start USB...
>> USB: Exynos4412-ehci: init hccr 12580000 and hcor 12580010 hc_length 10
>> Register 1313 NbrPorts 3
>> USB EHCI 1.00
>> samsung_gpiolib_4bit_output: base: 11000c60 offset: 5 value: 0
>> s3c_gpiolib_set: reg: 11000c64 offset: 5 value: 0
>> samsung_gpiolib_4bit_output: base: 11000c60 offset: 0 value: 0
>> s3c_gpiolib_set: reg: 11000c64 offset: 0 value: 0
>> samsung_gpiolib_4bit_output: base: 11000c60 offset: 4 value: 0
>> s3c_gpiolib_set: reg: 11000c64 offset: 4 value: 0
>> s3c_gpiolib_set: reg: 11000c64 offset: 5 value: 1
>> Read 32 from USB3503 SP_ILOCK
>> s3c_gpiolib_set: reg: 11000c64 offset: 4 value: 1
>> Wrote 33 to USB3503_SP_ILOCK
>> samsung_gpiolib_4bit_input: base: 11000c60 offset: 0
>> scanning bus for devices... New Device 0
>> usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0
>> length 0x40
>> set address 1
>> usb_control_msg: request: 0x5, requesttype: 0x0, value 0x1 index 0x0 length
>> 0x0
>> usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0
>> length 0x12
>> usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0
>> length 0x9
>> usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0
>> length 0x19
>> get_conf_no 0 Result 25, wLength 25
>> if 0, ep 0
>> ##EP epmaxpacketin[1] = 8
>> set configuration 1
>> usb_control_msg: request: 0x9, requesttype: 0x0, value 0x1 index 0x0 length
>> 0x0
>> new device strings: Mfr=1, Product=2, SerialNumber=0
>> usb_control_msg: request: 0x6, requesttype: 0x80, value 0x300 index 0x0
>> length 0xFF
>> USB device number 1 default language ID 0x1
>> usb_control_msg: request: 0x6, requesttype: 0x80, value 0x301 index 0x1
>> length 0xFF
>> usb_control_msg: request: 0x6, requesttype: 0x80, value 0x302 index 0x1
>> length 0xFF
>> Manufacturer u-boot
>> Product EHCI Host Controller
>> SerialNumber
>> Vendor: 0x0000 Product 0x0000 Version 1.0
>> USB hub found
>> usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0
>> length 0x4
>> usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0
>> length 0x8
>> 3 ports detected
>> individual port power switching
>> standalone hub
>> global over-current protection
>> power on to power good time: 20ms
>> hub controller current requirement: 0mA
>> port 1 is removable
>> port 2 is removable
>> port 3 is removable
>> usb_control_msg: request: 0x0, requesttype: 0xA0, value 0x0 index 0x0
>> length 0x4
>> get_hub_status returned status 1, change 103
>> local power source is lost (inactive)
>> no over-current condition exists
>> enabling power on all ports
>> usb_control_msg: request: 0x1, requesttype: 0x23, value 0x8 index 0x1
>> length 0x0
>> port 1 returns 0
>> usb_control_msg: request: 0x1, requesttype: 0x23, value 0x8 index 0x2
>> length 0x0
>> port 2 returns 0
>> usb_control_msg: request: 0x1, requesttype: 0x23, value 0x8 index 0x3
>> length 0x0
>> The request port(2) is not configured
>> port 3 returns 80000000
>> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1
>> length 0x4
>> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2
>> length 0x4
>> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x3
>> length 0x4
>> The request port(2) is not configured
>> port 3: get_port_status failed
>> usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x1
>> length 0x0
>> port 1 returns 0
>> usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x2
>> length 0x0
>> port 2 returns 0
>> usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x3
>> length 0x0
>> The request port(2) is not configured
>> port 3 returns 80000000
>> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1
>> length 0x4
>> Port 1 Status 500 Change 0
>> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2
>> length 0x4
>> Port 2 Status 501 Change 1
>> port 2 connection change
>> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2
>> length 0x4
>> portstatus 501, change 1, 480 Mb/s
>> usb_control_msg: request: 0x1, requesttype: 0x23, value 0x10 index 0x2
>> length 0x0
>> hub_port_reset: resetting port 1...
>> usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x2
>> length 0x0
>> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2
>> length 0x4
>> portstatus 503, change 10, 480 Mb/s
>> STAT_C_CONNECTION = 0 STAT_CONNECTION = 1 USB_PORT_STAT_ENABLE 1
>> usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x2
>> length 0x0
>> New Device 1
>> usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0
>> length 0x40
>> EHCI timed out on TD - token=0x80008c80
>> hub_port_reset: resetting port 1...
>> usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x2
>> length 0x0
>> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2
>> length 0x4
>> portstatus 503, change 10, 480 Mb/s
>> STAT_C_CONNECTION = 0 STAT_CONNECTION = 1 USB_PORT_STAT_ENABLE 1
>> usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x2
>> length 0x0
>> set address 2
>> usb_control_msg: request: 0x5, requesttype: 0x0, value 0x2 index 0x0 length
>> 0x0
>> EHCI fail timeout STS_ASS set
>>
>> USB device not accepting new address (error=80000000)
>> hub: disabling port 2
>> usb_control_msg: request: 0x1, requesttype: 0x23, value 0x1 index 0x2
>> length 0x0
>> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x3
>> length 0x4
>> The request port(2) is not configured
>> get_port_status failed
>> 2 USB Device(s) found
>> scan end
>> scanning bus for storage devices... 0 Storage Device(s) found
>> scanning bus for ethernet devices... [0] IntIdVendor: 1060
>> IntIdProdcut: 60416 IdVendor: 0 IdProduct: 0
>> [1] IntIdVendor: 1060 IntIdProdcut: 38144 IdVendor: 0 IdProduct: 0
>> [0] IntIdVendor: 1060 IntIdProdcut: 60416 IdVendor: 0 IdProduct: 0
>> [1] IntIdVendor: 1060 IntIdProdcut: 38144 IdVendor: 0 IdProduct: 0
>> 0 Ethernet Device(s) found
>> -----------------------------------------------------------------
>>
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot at lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>>
>
>
>
> --
> Best Regards
> Vivek
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-08-18 1:03 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-08-18 1:03 UTC (permalink / raw)
To: u-boot
instead of read status- hence added E_FSR flag on spectific
flash parts.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
---
Changes for v4:
- none
Changes for v3:
- none
Changes for v2:
- none
drivers/mtd/spi/spi_flash_probe.c | 14 +++++++++-----
include/spi_flash.h | 1 +
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/spi/spi_flash_probe.c b/drivers/mtd/spi/spi_flash_probe.c
index 9b5a055..c62a1ee 100644
--- a/drivers/mtd/spi/spi_flash_probe.c
+++ b/drivers/mtd/spi/spi_flash_probe.c
@@ -94,10 +94,10 @@ static const struct spi_flash_params spi_flash_params_table[] = {
{"N25Q128A", 0x20bb18, 0x0, 64 * 1024, 256, SECT_4K},
{"N25Q256", 0x20ba19, 0x0, 64 * 1024, 512, SECT_4K},
{"N25Q256A", 0x20bb19, 0x0, 64 * 1024, 512, SECT_4K},
- {"N25Q512", 0x20ba20, 0x0, 64 * 1024, 1024, SECT_4K},
- {"N25Q512A", 0x20bb20, 0x0, 64 * 1024, 1024, SECT_4K},
- {"N25Q1024", 0x20ba21, 0x0, 64 * 1024, 2048, SECT_4K},
- {"N25Q1024A", 0x20bb21, 0x0, 64 * 1024, 2048, SECT_4K},
+ {"N25Q512", 0x20ba20, 0x0, 64 * 1024, 1024, E_FSR | SECT_4K},
+ {"N25Q512A", 0x20bb20, 0x0, 64 * 1024, 1024, E_FSR | SECT_4K},
+ {"N25Q1024", 0x20ba21, 0x0, 64 * 1024, 2048, E_FSR | SECT_4K},
+ {"N25Q1024A", 0x20bb21, 0x0, 64 * 1024, 2048, E_FSR | SECT_4K},
#endif
#ifdef CONFIG_SPI_FLASH_SST /* SST */
{"SST25VF040B", 0xbf258d, 0x0, 64 * 1024, 8, SECT_4K | SST_WP},
@@ -187,7 +187,6 @@ struct spi_flash *spi_flash_validate_ids(struct spi_slave *spi, u8 *idcode)
flash->spi = spi;
flash->name = params->name;
- flash->poll_cmd = CMD_READ_STATUS;
/* Assign spi_flash ops */
flash->write = spi_flash_cmd_write_multi;
@@ -215,6 +214,11 @@ struct spi_flash *spi_flash_validate_ids(struct spi_slave *spi, u8 *idcode)
flash->erase_size = flash->sector_size;
}
+ /* Poll cmd seclection */
+ flash->poll_cmd = CMD_READ_STATUS;
+ if (params->flags & E_FSR)
+ flash->poll_cmd = CMD_FLAG_STATUS;
+
/* Flash powers up read-only, so clear BP# bits */
if (((params->jedec >> 16) == SPI_FLASH_CFI_MFR_ATMEL) ||
((params->jedec >> 16) == SPI_FLASH_CFI_MFR_MACRONIX) ||
diff --git a/include/spi_flash.h b/include/spi_flash.h
index 387af86..3e60fdc 100644
--- a/include/spi_flash.h
+++ b/include/spi_flash.h
@@ -25,6 +25,7 @@
/* SECT flags */
#define SECT_4K (1 << 0)
#define SECT_32K (1 << 1)
+#define E_FSR (1 << 2)
/* SST specific macros */
#ifdef CONFIG_SPI_FLASH_SST
--
1.8.3
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2013-08-18 1:03 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-08-18 1:03 UTC (permalink / raw)
To: u-boot
----------------------------
spi_setup_slave() {
spi = spi_alloc_slave(struct zynq_spi_slave, bus, cs);
spi->slave.rd_cmd = RD_CMD_FULL;
spi->slave.wr_cmd = WR_CMD_FULL;
}
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-08-18 1:03 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-08-18 1:03 UTC (permalink / raw)
To: u-boot
-----------------------------------------------------------------------------
/* Look for the fastest read cmd */
cmd = fls(params->rd_cmd & flash->spi->rd_cmd);
if (cmd) {
cmd = spi_read_cmds_array[cmd - 1];
flash->read_cmd = cmd;
} else {
/* Go for controller supported command */
flash->read_cmd = CMD_READ_ARRAY_FAST;
}
/* Look for the fastest write cmd */
cmd = fls(params->wr_cmd & flash->spi->wr_cmd);
if (cmd) {
cmd = spi_write_cmds_array[cmd - 1];
flash->write_cmd = cmd;
} else {
/* Go for controller supported command */
flash->write_cmd = CMD_PAGE_PROGRAM;
}
include/spi_flash.h:
---------------------------
/* Supported write cmds enum list */
enum spi_write_cmds {
PAGE_PROGRAM = 1 << 0,
QUAD_PAGE_PROGRAM = 1 << 1,
};
#define WR_CMD_FULL PAGE_PROGRAM | QUAD_PAGE_PROGRAM
/* Supported read cmds enum list */
enum spi_read_cmds {
ARRAY_SLOW = 1 << 0,
ARRAY_FAST = 1 << 1,
DUAL_OUTPUT_FAST = 1 << 2,
DUAL_IO_FAST = 1 << 3,
QUAD_OUTPUT_FAST = 1 << 4,
};
#define RD_CMD_FULL ARRAY_SLOW | ARRAY_FAST | DUAL_OUTPUT_FAST | \
DUAL_IO_FAST | QUAD_OUTPUT_FAST
If the controller is not filling slave.rd_cmd and slave.wr_cmd if it's
not supporting even if connected flash
supports, fill the read/write commands to default ones.
Controller is a master to decide which command is to use, and flash is
slave to transfer the discovered command
through spi_xfer(), so the controller will take care of the command processing.
This is well detailed explanation, I hope you understand.
>
> Maybe your specific controller behaves in another way, but this is not the standard
> and you should not force this into the interface.
>
> And another doubt: The might be different commands for dual/quad read/write,
> depending on the flash manufacturer. With your solution, the controller drivers
> would need these details in advance! Or at least need to be updated on each new
> command, which needs to be supported.
>
>> --
>> Thanks,
>> Jagan.
>
> Best Regards,
> Thomas
>
>
--
Thanks,
Jagan.
--------
Jagannadha Sutradharudu Teki,
E: jagannadh.teki at gmail.com, P: +91-9676773388
Engineer - System Software Hacker
U-boot - SPI Custodian and Zynq APSOC
Ln: http://www.linkedin.com/in/jaganteki
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-08-18 1:03 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-08-18 1:03 UTC (permalink / raw)
To: u-boot
river!
There you know details of manufacturer, supported opcodes and so on.
And there you can decide, if you switch a flash to a "full quad" mode,
that the same opcode now needs to be send on 4 lines!
In the controller driver you don't know these details!
>=20
> spi_flash layer should send any commands based on the respective
> supported, but it is supported by respective spi controller that should
> controller driver must aware.
>=20
> This is more generic solution as we discussed so-many months ago.
> http://u-boot.10912.n7.nabble.com/PATCH-00-12-cmd-sf-Add-support-for-
> read-and-write-instructions-td143749.html
Yes, I agree that this a huge step forward!
But I think, we still have not reached a state which everyone can accept.
>=20
> We tried to discover the supported commands runtime from respective
> flashes, but ie. going to be a huge
> code to decode all these. Instead filling params, like sectors and
> idcodes should be an code driven task as per as
> u-boot code is concern.
As I already said, this is very specific to your controller!
>=20
>> By decoding the cmd itself again? But the data should be a transparent b=
yte
>> stream to the controller!
>> Otherwise you need a table of commands for decoding also inside the
>> controller
>> driver, which I consider a bad idea, as you need to update them (in each
>> driver)
>> for new cmds added to the serial-flash driver!
>>=20
>> In the linux kernel, the solution in the spi layer was to add new
>> elements to
>> the transfer structure (struct spi_transfer -> bitwidth), which can be s=
et
>> for each part of a message.
>> In u-boot we have the spi_xfer function, which has a "flags" parameter
>> we could
>> use for this.
>>=20
>> As long as the details for this (including a spi controller driver,
>> which can handle dual/quad-io transfers) are not fixed, I would suggest
>> to leave the patches regarding the extended cmds out of the series of
>> sf-cleanup (which really looks good!) and fix the issues until the next
>> merge window!
>=20
> I am planning to push this series, as we started this since long months b=
ack.
> We discussed many threads, and tested this approach on read hw as well.
>=20
> Please let me know for any thoughts.
I already said: Please leave some room for more discussions on the extended=
/ quad read topic!
And don't let the rest of the improvements be delayed by this!
>=20
>>=20
>>> Testing repo branch:
>>> -------------------
>>> $ git clone git://git.denx.de/u-boot-spi.git
>>> $ cd u-boot-spi
>>> $ git checkout -b master-next-test origin/master-next-test
>>>=20
>>> REQUEST FOR ALL SPI CODE CONTRIBUTORS/USERS, PLEASE TEST THESE CHANGES
>>> W.R.T YOUR HW IF POSSIBLE.
>>>=20
>>> Please let me know for any issues/concerns/questions.
>>>=20
>>> --
>>> Thanks,
>>> Jagan.
>> Best Regards,
>> Thomas
>>=20
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot at lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>
Best Regards,
Thomas
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-08-18 1:03 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-08-18 1:03 UTC (permalink / raw)
To: u-boot
It can be just one line patch but it worth to have it
in connection to bisecting.
>=20
> Tested:
> Xilinx ZC702 eval board.
> Write and read registers with addresses of length 0 and 1.
This could go below "---"
Thanks,
Michal
--=20
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-08-18 1:03 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-08-18 1:03 UTC (permalink / raw)
To: u-boot
instead of read status- hence added E_FSR flag on spectific
flash parts.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
---
Changes for v5:
- none
Changes for v4:
- none
Changes for v3:
- none
Changes for v2:
- none
drivers/mtd/spi/spi_flash_probe.c | 16 +++++++++++-----
include/spi_flash.h | 1 +
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/spi/spi_flash_probe.c b/drivers/mtd/spi/spi_flash_probe.c
index 9c2e115..8ea6915 100644
--- a/drivers/mtd/spi/spi_flash_probe.c
+++ b/drivers/mtd/spi/spi_flash_probe.c
@@ -94,10 +94,10 @@ static const struct spi_flash_params spi_flash_params_table[] = {
{"N25Q128A", 0x20bb18, 0x0, 64 * 1024, 256, SECT_4K},
{"N25Q256", 0x20ba19, 0x0, 64 * 1024, 512, SECT_4K},
{"N25Q256A", 0x20bb19, 0x0, 64 * 1024, 512, SECT_4K},
- {"N25Q512", 0x20ba20, 0x0, 64 * 1024, 1024, SECT_4K},
- {"N25Q512A", 0x20bb20, 0x0, 64 * 1024, 1024, SECT_4K},
- {"N25Q1024", 0x20ba21, 0x0, 64 * 1024, 2048, SECT_4K},
- {"N25Q1024A", 0x20bb21, 0x0, 64 * 1024, 2048, SECT_4K},
+ {"N25Q512", 0x20ba20, 0x0, 64 * 1024, 1024, E_FSR | SECT_4K},
+ {"N25Q512A", 0x20bb20, 0x0, 64 * 1024, 1024, E_FSR | SECT_4K},
+ {"N25Q1024", 0x20ba21, 0x0, 64 * 1024, 2048, E_FSR | SECT_4K},
+ {"N25Q1024A", 0x20bb21, 0x0, 64 * 1024, 2048, E_FSR | SECT_4K},
#endif
#ifdef CONFIG_SPI_FLASH_SST /* SST */
{"SST25VF040B", 0xbf258d, 0x0, 64 * 1024, 8, SECT_4K | SST_WP},
@@ -187,7 +187,6 @@ struct spi_flash *spi_flash_validate_ids(struct spi_slave *spi, u8 *idcode)
flash->spi = spi;
flash->name = params->name;
- flash->poll_cmd = CMD_READ_STATUS;
/* Assign spi_flash ops */
flash->write = spi_flash_cmd_write_multi;
@@ -215,6 +214,13 @@ struct spi_flash *spi_flash_validate_ids(struct spi_slave *spi, u8 *idcode)
flash->erase_size = flash->sector_size;
}
+ /* Poll cmd seclection */
+ flash->poll_cmd = CMD_READ_STATUS;
+#ifdef CONFIG_SPI_FLASH_STMICRO
+ if (params->flags & E_FSR)
+ flash->poll_cmd = CMD_FLAG_STATUS;
+#endif
+
/* Flash powers up read-only, so clear BP# bits */
#if defined(CONFIG_SPI_FLASH_ATMEL) || \
defined(CONFIG_SPI_FLASH_MACRONIX) || \
diff --git a/include/spi_flash.h b/include/spi_flash.h
index 0d40e6c..09af55d 100644
--- a/include/spi_flash.h
+++ b/include/spi_flash.h
@@ -20,6 +20,7 @@
/* SECT flags */
#define SECT_4K (1 << 1)
#define SECT_32K (1 << 2)
+#define E_FSR (1 << 3)
/* SST specific macros */
#ifdef CONFIG_SPI_FLASH_SST
--
1.8.3
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2013-07-30 4:09 PV Juliet
0 siblings, 0 replies; 732+ messages in thread
From: PV Juliet @ 2013-07-30 4:09 UTC (permalink / raw)
To: kernelnewbies
HI ,
I am new to kernel . I got some stuff on notifier chains from net.
Where i can more elaborated documents on notifier chains ? Can i get the
module out put to user space(eg usb disk added) ? I don't want to get it
from dmesg.
Thanks and Regards
Juliet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130730/6f3de789/attachment.html
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-07-26 10:05 Haojian Zhuang
0 siblings, 0 replies; 732+ messages in thread
From: Haojian Zhuang @ 2013-07-26 10:05 UTC (permalink / raw)
To: linux-arm-kernel
Changelog:
v6:
1. Merge clk apbc & apbcp together.
2. Add DT binding document of clock driver.
3. Remove marvell string in properties of clock driver.
v5:
1. Use clk mux table.
v4:
1. Remove .init_irq in mmp & mmp2 DT machine descriptor.
2. Use an argument to replace TIMER_PHYS_BASE. Now transfer virtual
address directly.
3. Merge 10th & 11th patches together. Remove the redundant changes
on drivers/clocksource/Kconfig & drivers/clocksource/Makefile.
v3:
1. Don't use include/linux/irqchip/mmp.h since we don't need to
move <mach/irqs.h> to <include/linux/irqchip/mmp.h>.
2. Move timer-mmp driver into clocksource directory & support
clocksource.
3. Support clksrc in mmp & parse all clock from DTS.
v2:
1. Avoid to include <mach/irqs.h>. Move the head file into
include/linux/irqchip directory.
2. Avoid to include <mach/pm-pxa910.h> & <mach/pm-mmp2.h>.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-06-28 5:49 Wang, Yalin
0 siblings, 0 replies; 732+ messages in thread
From: Wang, Yalin @ 2013-06-28 5:49 UTC (permalink / raw)
To: linux-arm-kernel
Hi Sboy,
I don't know who should I send this mail to .
If you are not the right person, please forward
To the right responsible person , Thank you !
I have a question about msm kernel code :
File: Arch/arm/msm/memory.c
reserve_memory_for_mempools()
it call memblock_remove() directly,
I think it's not safe sometimes ,
Should use arm_memblock_steal() function or some other similar
Function to make sure the removed memory is not reserved by memblock driver,
In case the removed memory is reserved by some driver.
Thanks
Yalin.Wang
Software Engineer
OS Kernel&Graphics
?
Sony Mobile Communications
Tel: +86 10 5966 9819
Phone: 18610323092
Address: No.16 Guangshun South Street, Chaoyang, Beijing, P.R.C.
sonymobile.com
??
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-06-19 10:57 Ben Dooks
0 siblings, 0 replies; 732+ messages in thread
From: Ben Dooks @ 2013-06-19 10:57 UTC (permalink / raw)
To: linux-arm-kernel
I found this one whilst testing versatile-express with a -rc kernel
and was considering if this is the correct way to fix this.
[PATCH] atags_to_fdt: take into account root's #size and #cells
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-04-24 18:07 Viral Mehta
0 siblings, 0 replies; 732+ messages in thread
From: Viral Mehta @ 2013-04-24 18:07 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
I am using Marvell's ARMADA XP platform in my development environment.
Recently, I faced DMA related issue. While moving data from memory to
the device, I found that sometimes I am getting Junk data. I looked
further to see if this is related to DMA Sync problem. So, basically,
I have following questions,
1. As per [1] ARMADA has Coherency Fabric that sits between CPU and
other devices and takes care of hardware based I/O cache coherency. Do
we need to enable any support for the same in software ? I am running
3.0.29 based linux kernel. How do I verify that I have all the things
enabled in Linux Kernel.
2. Do I still need to use dma_[map,unamp]_* APIs while copying data to
and from device ?
[1] http://www.marvell.com/embedded-processors/armada-xp/assets/Marvell-ArmadaXP-SoC-product%20brief.pdf
--
Thanks,
Viral Mehta
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-04-12 7:08 Callum Hutchinson
0 siblings, 0 replies; 732+ messages in thread
From: Callum Hutchinson @ 2013-04-12 7:08 UTC (permalink / raw)
To: b43-dev, linux-wireless
Hi Kernel Maintainers,
Tried to report this properly via email but got some formatting issues
coming back, I've attached the content of the original email report as
'Report.txt'.
It is the same file as found on comment 12 on Launchpad bug.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1142385
Apologies for any missing information or lack of reporting experience :)
-------------- next part --------------
B43 Wireless Autoconnect Failure
I installed raring to test whether this bug existed in it and quantal too.
In the 3.8+ kernels there seems to be an issue with the b43 drivers, my
wireless works however it won't automatically connect to my hidden wireless
network. I have to go into network manager on each login and manually
select the option to connect, it takes a while but then the connection
works fine.
I know this didn't exist in 3.7.x because I was using those kernels
absolutely fine, it's only when I tried 3.8 on both quantal and raring that
the issue arose.
Note: I can't edit the wireless settings on my network as I am not the
administrator in my house.
ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: linux-image-3.8.0-9-generic 3.8.0-9.18
ProcVersionSignature: Ubuntu 3.8.0-9.18-generic 3.8.1
Uname: Linux 3.8.0-9-generic x86_64
ApportVersion: 2.9-0ubuntu2
Architecture: amd64
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/controlC0: callum 1770 F.... pulseaudio
callum 3234 F.... pulseaudio
CRDA:
country GB:
(2402 - 2482 @ 40), (N/A, 20)
(5170 - 5250 @ 40), (N/A, 20)
(5250 - 5330 @ 40), (N/A, 20), DFS
(5490 - 5710 @ 40), (N/A, 27), DFS
Date: Sun Mar 3 16:13:52 2013
HibernationDevice: RESUME=UUID=53b96653-3e0d-426b-a911-9c34d8657655
InstallationDate: Installed on 2013-03-02 (1 days ago)
InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Alpha amd64 (20130301)
MachineType: Apple Inc. Macmini5,1
MarkForUpload: True
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.8.0-9-generic
root=UUID=b4faf392-19de-4749-bd48-bbda7a7519b3 ro quiet splash vt.handoff=7
RelatedPackageVersions:
linux-restricted-modules-3.8.0-9-generic N/A
linux-backports-modules-3.8.0-9-generic N/A
linux-firmware 1.103
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 01/24/2012
dmi.bios.vendor: Apple Inc.
dmi.bios.version: MM51.88Z.0077.B10.1201241549
dmi.board.asset.tag: Base Board Asset Tag#
dmi.board.name: Mac-8ED6AF5B48C039E1
dmi.board.vendor: Apple Inc.
dmi.board.version: Macmini5,1
dmi.chassis.type: 16
dmi.chassis.vendor: Apple Inc.
dmi.chassis.version: Mac-8ED6AF5B48C039E1
dmi.modalias:
dmi:bvnAppleInc.:bvrMM51.88Z.0077.B10.1201241549:bd01/24/2012:svnAppleInc.:pnMacmini5,1:pvr1.0:rvnAppleInc.:rnMac-8ED6AF5B48C039E1:rvrMacmini5,1:cvnAppleInc.:ct16:cvrMac-8ED6AF5B48C039E1:
dmi.product.name: Macmini5,1
dmi.product.version: 1.0
dmi.sys.vendor: Apple Inc.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1142385
amd64, mac, b43, networking, wireless, kernel
Linux version 3.9.0-030900rc4-generic (apw at gomeisa) (gcc version 4.6.3
(Ubuntu/Linaro 4.6.3-1ubuntu5) ) #201303232035 SMP Sun Mar 24 00:36:21 UTC
2013
Description: Ubuntu Raring Ringtail (development branch)
Release: 13.04
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
Linux callum-Macmini 3.9.0-030900rc4-generic #201303232035 SMP Sun Mar 24
00:36:21 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Gnu C 4.7
Gnu make 3.81
binutils 2.23.2
util-linux 2.20.1
mount support
module-init-tools 9
e2fsprogs 1.42.5
pcmciautils 018
PPP 2.4.5
Linux C Library 2.17
Dynamic linker (ldd) 2.17
Procps 3.3.3
Net-tools 1.60
Kbd 1.15.5
Sh-utils 8.20
wireless-tools 30
Modules Loaded btrfs raid6_pq zlib_deflate xor ufs qnx4 hfsplus hfs
minix ntfs msdos jfs xfs libcrc32c reiserfs ext2 hid_magicmouse joydev hidp
parport_pc ppdev bnep rfcomm coretemp kvm_intel arc4 kvm snd_hda_codec_hdmi
snd_hda_codec_cirrus snd_hda_intel b43 btusb ghash_clmulni_intel
snd_hda_codec aesni_intel bluetooth aes_x86_64 snd_hwdep xts snd_pcm lrw
gf128mul binfmt_misc ablk_helper mac80211 i915 snd_page_alloc cryptd
snd_seq_midi snd_seq_midi_event snd_rawmidi cfg80211 snd_seq drm_kms_helper
snd_seq_device drm snd_timer ssb snd apple_gmux i2c_algo_bit soundcore
microcode shpchp applesmc mei apple_bl mac_hid input_polldev lpc_ich bcma
video lp parport hid_generic hid_apple usbhid hid firewire_ohci sdhci_pci
sdhci firewire_core tg3 crc_itu_t ptp pps_core
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel(R) Core(TM) i5-2415M CPU @ 2.30GHz
stepping : 7
microcode : 0x1a
cpu MHz : 800.000
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc
aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3
cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes
xsave avx lahf_lm ida arat xsaveopt pln pts dtherm tpr_shadow vnmi
flexpriority ept vpid
bogomips : 4589.47
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel(R) Core(TM) i5-2415M CPU @ 2.30GHz
stepping : 7
microcode : 0x1a
cpu MHz : 800.000
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 2
apicid : 2
initial apicid : 2
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc
aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3
cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes
xsave avx lahf_lm ida arat xsaveopt pln pts dtherm tpr_shadow vnmi
flexpriority ept vpid
bogomips : 4589.47
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel(R) Core(TM) i5-2415M CPU @ 2.30GHz
stepping : 7
microcode : 0x1a
cpu MHz : 800.000
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 2
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc
aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3
cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes
xsave avx lahf_lm ida arat xsaveopt pln pts dtherm tpr_shadow vnmi
flexpriority ept vpid
bogomips : 4589.47
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel(R) Core(TM) i5-2415M CPU @ 2.30GHz
stepping : 7
microcode : 0x1a
cpu MHz : 800.000
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 2
apicid : 3
initial apicid : 3
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc
aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3
cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes
xsave avx lahf_lm ida arat xsaveopt pln pts dtherm tpr_shadow vnmi
flexpriority ept vpid
bogomips : 4589.47
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
btrfs 843910 0 - Live 0x0000000000000000
raid6_pq 97812 1 btrfs, Live 0x0000000000000000
zlib_deflate 27110 1 btrfs, Live 0x0000000000000000
xor 21411 1 btrfs, Live 0x0000000000000000
ufs 75149 0 - Live 0x0000000000000000
qnx4 13396 0 - Live 0x0000000000000000
hfsplus 103443 0 - Live 0x0000000000000000
hfs 54780 0 - Live 0x0000000000000000
minix 36387 0 - Live 0x0000000000000000
ntfs 101633 0 - Live 0x0000000000000000
msdos 17332 0 - Live 0x0000000000000000
jfs 186589 0 - Live 0x0000000000000000
xfs 888928 0 - Live 0x0000000000000000
libcrc32c 12615 2 btrfs,xfs, Live 0x0000000000000000
reiserfs 248298 0 - Live 0x0000000000000000
ext2 73755 0 - Live 0x0000000000000000
hid_magicmouse 13712 0 - Live 0x0000000000000000
joydev 17613 0 - Live 0x0000000000000000
hidp 22599 2 - Live 0x0000000000000000
parport_pc 32866 0 - Live 0x0000000000000000
ppdev 17106 0 - Live 0x0000000000000000
bnep 18258 2 - Live 0x0000000000000000
rfcomm 47863 12 - Live 0x0000000000000000
coretemp 13596 0 - Live 0x0000000000000000
kvm_intel 138733 0 - Live 0x0000000000000000
arc4 12573 2 - Live 0x0000000000000000
kvm 452835 1 kvm_intel, Live 0x0000000000000000
snd_hda_codec_hdmi 37407 1 - Live 0x0000000000000000
snd_hda_codec_cirrus 14090 1 - Live 0x0000000000000000
snd_hda_intel 44397 3 - Live 0x0000000000000000
b43 391985 0 - Live 0x0000000000000000
btusb 18291 0 - Live 0x0000000000000000
ghash_clmulni_intel 13259 0 - Live 0x0000000000000000
snd_hda_codec 190010 3
snd_hda_codec_hdmi,snd_hda_codec_cirrus,snd_hda_intel, Live
0x0000000000000000
aesni_intel 55449 2 - Live 0x0000000000000000
bluetooth 251354 31 hidp,bnep,rfcomm,btusb, Live 0x0000000000000000
aes_x86_64 17131 1 aesni_intel, Live 0x0000000000000000
snd_hwdep 13613 1 snd_hda_codec, Live 0x0000000000000000
xts 12922 1 aesni_intel, Live 0x0000000000000000
snd_pcm 102477 3 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec, Live
0x0000000000000000
lrw 13294 1 aesni_intel, Live 0x0000000000000000
gf128mul 14951 2 xts,lrw, Live 0x0000000000000000
binfmt_misc 17540 1 - Live 0x0000000000000000
ablk_helper 13597 1 aesni_intel, Live 0x0000000000000000
mac80211 656112 1 b43, Live 0x0000000000000000
i915 631460 4 - Live 0x0000000000000000
snd_page_alloc 18798 2 snd_hda_intel,snd_pcm, Live 0x0000000000000000
cryptd 20501 3 ghash_clmulni_intel,aesni_intel,ablk_helper, Live
0x0000000000000000
snd_seq_midi 13324 0 - Live 0x0000000000000000
snd_seq_midi_event 14899 1 snd_seq_midi, Live 0x0000000000000000
snd_rawmidi 30417 1 snd_seq_midi, Live 0x0000000000000000
cfg80211 547072 2 b43,mac80211, Live 0x0000000000000000
snd_seq 61930 2 snd_seq_midi,snd_seq_midi_event, Live 0x0000000000000000
drm_kms_helper 49082 1 i915, Live 0x0000000000000000
snd_seq_device 14497 3 snd_seq_midi,snd_rawmidi,snd_seq, Live
0x0000000000000000
drm 295908 5 i915,drm_kms_helper, Live 0x0000000000000000
snd_timer 29989 2 snd_pcm,snd_seq, Live 0x0000000000000000
ssb 57592 1 b43, Live 0x0000000000000000
snd 69533 16
snd_hda_codec_hdmi,snd_hda_codec_cirrus,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_rawmidi,snd_seq,snd_seq_device,snd_timer,
Live 0x0000000000000000
apple_gmux 13406 0 - Live 0x0000000000000000
i2c_algo_bit 13564 1 i915, Live 0x0000000000000000
soundcore 12680 1 snd, Live 0x0000000000000000
microcode 22923 0 - Live 0x0000000000000000
shpchp 37201 0 - Live 0x0000000000000000
applesmc 19564 0 - Live 0x0000000000000000
mei 46555 0 - Live 0x0000000000000000
apple_bl 13673 1 apple_gmux, Live 0x0000000000000000
mac_hid 13253 0 - Live 0x0000000000000000
input_polldev 13896 1 applesmc, Live 0x0000000000000000
lpc_ich 17060 0 - Live 0x0000000000000000
bcma 41434 1 b43, Live 0x0000000000000000
video 19467 2 i915,apple_gmux, Live 0x0000000000000000
lp 17799 0 - Live 0x0000000000000000
parport 46562 3 parport_pc,ppdev,lp, Live 0x0000000000000000
hid_generic 12548 0 - Live 0x0000000000000000
hid_apple 13389 0 - Live 0x0000000000000000
usbhid 47346 0 - Live 0x0000000000000000
hid 101248 5 hid_magicmouse,hidp,hid_generic,hid_apple,usbhid, Live
0x0000000000000000
firewire_ohci 44864 0 - Live 0x0000000000000000
sdhci_pci 18720 0 - Live 0x0000000000000000
sdhci 33227 1 sdhci_pci, Live 0x0000000000000000
firewire_core 64836 1 firewire_ohci, Live 0x0000000000000000
tg3 165632 0 - Live 0x0000000000000000
crc_itu_t 12707 1 firewire_core, Live 0x0000000000000000
ptp 18668 1 tg3, Live 0x0000000000000000
pps_core 14080 1 ptp, Live 0x0000000000000000
0000-0cf7 : PCI Bus 0000:00
0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-0060 : keyboard
0062-0062 : EC data
0064-0064 : keyboard
0066-0066 : EC cmd
0070-0077 : rtc0
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0300-031f : applesmc
0400-047f : pnp 00:04
0400-0403 : ACPI PM1a_EVT_BLK
0404-0405 : ACPI PM1a_CNT_BLK
0408-040b : ACPI PM_TMR
0410-0415 : ACPI CPU throttle
0420-042f : ACPI GPE0_BLK
0430-0433 : iTCO_wdt
0450-0450 : ACPI PM2_CNT_BLK
0460-047f : iTCO_wdt
0500-057f : pnp 00:04
0cf8-0cff : PCI conf1
0d00-ffff : PCI Bus 0000:00
1000-100f : pnp 00:04
2000-203f : 0000:00:02.0
2060-206f : 0000:00:1f.2
2060-206f : ata_piix
20c0-20df : 0000:00:1d.0
20c0-20df : uhci_hcd
2120-213f : 0000:00:1a.0
2120-213f : uhci_hcd
2140-2147 : 0000:00:1f.2
2140-2147 : ata_piix
2148-214f : 0000:00:1f.2
2148-214f : ata_piix
2158-215b : 0000:00:1f.2
2158-215b : ata_piix
215c-215f : 0000:00:1f.2
215c-215f : ata_piix
3000-3fff : PCI Bus 0000:06
efa0-efbf : 0000:00:1f.3
ffe0-ffef : 0000:00:1f.2
ffe0-ffef : ata_piix
00000000-00000fff : reserved
00001000-0008efff : System RAM
0008f000-0008ffff : reserved
00090000-0009fbff : System RAM
0009fc00-000fffff : reserved
000a0000-000bffff : PCI Bus 0000:00
000c0000-000cedff : Video ROM
000f0000-000fffff : System ROM
00100000-1fffffff : System RAM
01000000-01710dd0 : Kernel code
01710dd1-01cf3b7f : Kernel data
01e3c000-01f75fff : Kernel bss
20000000-201fffff : reserved
20000000-201fffff : pnp 00:09
20200000-3fffffff : System RAM
40000000-401fffff : reserved
40000000-401fffff : pnp 00:09
40200000-8ad33fff : System RAM
8ad34000-8ad5efff : ACPI Non-volatile Storage
8ad5f000-8afa1fff : ACPI Tables
8afa2000-8affefff : reserved
8afff000-8affffff : ACPI Tables
8b000000-8f9fffff : reserved
8fa00000-feafffff : PCI Bus 0000:00
90000000-9fffffff : 0000:00:02.0
a0000000-a03fffff : 0000:00:02.0
a0400000-a04fffff : PCI Bus 0000:02
a0400000-a040ffff : 0000:02:00.0
a0400000-a040ffff : tg3
a0410000-a041ffff : 0000:02:00.0
a0410000-a041ffff : tg3
a0420000-a042ffff : 0000:02:00.1
a0420000-a042ffff : mmc0
a0500000-a05fffff : PCI Bus 0000:04
a0500000-a05fffff : PCI Bus 0000:05
a0500000-a0503fff : 0000:05:00.0
a0504000-a05047ff : 0000:05:00.0
a0504000-a05047ff : firewire_ohci
a0600000-a06fffff : PCI Bus 0000:03
a0600000-a0603fff : 0000:03:00.0
a0600000-a0603fff : bcma-pci-bridge
a0700000-a07fffff : PCI Bus 0000:02
a0800000-a08fffff : PCI Bus 0000:01
a0900000-a0903fff : 0000:00:1b.0
a0900000-a0903fff : ICH HD audio
a0906800-a0906bff : 0000:00:1d.7
a0906800-a0906bff : ehci_hcd
a0906c00-a0906fff : 0000:00:1a.7
a0906c00-a0906fff : ehci_hcd
a0907000-a09070ff : 0000:00:1f.3
a0907100-a090710f : 0000:00:16.0
a0907100-a090710f : mei
a0a00000-a4efffff : PCI Bus 0000:06
a4f00000-a8efffff : PCI Bus 0000:06
e0000000-efffffff : reserved
e0000000-efffffff : pnp 00:08
e0000000-e9cfffff : PCI MMCONFIG 0000 [bus 00-9c]
fec00000-fec00fff : reserved
fec00000-fec003ff : IOAPIC 0
fed00000-fed03fff : reserved
fed00000-fed003ff : HPET 0
fed00000-fed003ff : pnp 00:02
fed10000-fed13fff : reserved
fed18000-fed19fff : reserved
fed18000-fed18fff : pnp 00:08
fed19000-fed19fff : pnp 00:08
fed1c000-fed1ffff : reserved
fed1c000-fed1ffff : pnp 00:08
fed1f410-fed1f414 : iTCO_wdt
fed20000-fed3ffff : pnp 00:08
fed40000-fed44fff : PCI Bus 0000:00
fed45000-fed8ffff : pnp 00:08
fed90000-fed93fff : pnp 00:08
fee00000-fee00fff : Local APIC
fee00000-fee00fff : reserved
ff800000-ffffffff : reserved
100000000-26fdfffff : System RAM
26fe00000-26fffffff : RAM buffer
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: ehci-pci
00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family
High Definition Audio Controller (rev 05)
Subsystem: Intel Corporation Apple MacBookPro8,2 [Core i7, 15", 2011]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 256 bytes
Interrupt: pin A routed to IRQ 47
Region 0: Memory@a0900000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee0f00c Data: 4162
Capabilities: [70] Express (v1) Root Complex Integrated Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- RBE- FLReset+
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #0, Speed unknown, Width x0, ASPM unknown, Latency L0 <64ns,
L1 <1us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; Disabled- Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed unknown, Width x0, TrErr- Train- SlotClk- DLActive- BWMgmt-
ABWMgmt-
Capabilities: [100 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
Status: NegoPending- InProgress-
VC1: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=1 ArbSelect=Fixed TC/VC=22
Status: NegoPending- InProgress-
Capabilities: [130 v1] Root Complex Link
Desc: PortNumber=0f ComponentID=00 EltType=Config
Link0: Desc: TargetPort=00 TargetComponent=00 AssocRCRB-
LinkType=MemMapped LinkValid+
Addr: 00000000fed1c000
Kernel driver in use: snd_hda_intel
00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family
PCI Express Root Port 1 (rev b5) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 256 bytes
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: a0700000-a07fffff
Prefetchable memory behind bridge: 00000000a0400000-00000000a04fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal+ Fatal+ Unsupported+
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #1, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, L1
<16us
ClockPM- Surprise- LLActRep+ BwNot-
LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+
ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
Slot #0, PowerLimit 10.000W; Interlock- NoCompl+
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
Changed: MRL- PresDet- LinkState+
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
DevCap2: Completion Timeout: Range BC, TimeoutDis+ ARIFwd-
DevCtl2: Completion Timeout: 260ms to 900ms, TimeoutDis- ARIFwd-
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-, Selectable
De-emphasis: -6dB
Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-,
EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0f00c Data: 41d1
Capabilities: [90] Subsystem: Intel Corporation Apple MacBookPro8,2 [Core
i7, 15", 2011]
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: pcieport
00:1c.1 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family
PCI Express Root Port 2 (rev b5) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 256 bytes
Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: a0600000-a06fffff
Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal+ Fatal+ Unsupported+
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #2, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, L1
<16us
ClockPM- Surprise- LLActRep+ BwNot-
LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+
ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
Slot #0, PowerLimit 10.000W; Interlock- NoCompl+
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
Changed: MRL- PresDet- LinkState+
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
DevCap2: Completion Timeout: Range BC, TimeoutDis+ ARIFwd-
DevCtl2: Completion Timeout: 260ms to 900ms, TimeoutDis- ARIFwd-
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-, Selectable
De-emphasis: -6dB
Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-,
EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0f00c Data: 41e1
Capabilities: [90] Subsystem: Intel Corporation Apple MacBookPro8,2 [Core
i7, 15", 2011]
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: pcieport
00:1c.2 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family
PCI Express Root Port 3 (rev b5) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 256 bytes
Bus: primary=00, secondary=04, subordinate=05, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: a0500000-a05fffff
Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal+ Fatal+ Unsupported+
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #3, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 <1us, L1
<16us
ClockPM- Surprise- LLActRep+ BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+
ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
Slot #0, PowerLimit 10.000W; Interlock- NoCompl+
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
Changed: MRL- PresDet- LinkState+
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
DevCap2: Completion Timeout: Range BC, TimeoutDis+ ARIFwd-
DevCtl2: Completion Timeout: 260ms to 900ms, TimeoutDis- ARIFwd-
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-, Selectable
De-emphasis: -6dB
Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-,
EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0f00c Data: 4122
Capabilities: [90] Subsystem: Intel Corporation Apple MacBookPro8,2 [Core
i7, 15", 2011]
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: pcieport
00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset
Family USB Universal Host Controller #1 (rev 05) (prog-if 00 [UHCI])
Subsystem: Intel Corporation Apple MacBookPro8,2 [Core i7, 15", 2011]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin B routed to IRQ 19
Region 4: I/O ports@20c0 [size=32]
Capabilities: [50] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: uhci_hcd
00:1d.7 USB controller: Intel Corporation 6 Series/C200 Series Chipset
Family USB Enhanced Host Controller #1 (rev 05) (prog-if 20 [EHCI])
Subsystem: Intel Corporation Apple MacBookPro8,2 [Core i7, 15", 2011]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 22
Region 0: Memory@a0906800 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Debug port: BAR=1 offset=00a0
Capabilities: [98] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: ehci-pci
00:1f.0 ISA bridge: Intel Corporation HM65 Express Chipset Family LPC
Controller (rev 05)
Subsystem: Intel Corporation Apple MacBookPro8,2 [Core i7, 15", 2011]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0
Capabilities: [e0] Vendor Specific Information: Len=0c <?>
Kernel driver in use: lpc_ich
00:1f.2 IDE interface: Intel Corporation 6 Series/C200 Series Chipset
Family 4 port SATA IDE Controller (rev 05) (prog-if 8f [Master SecP SecO
PriP PriO])
Subsystem: Intel Corporation Device 7270
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin B routed to IRQ 19
Region 0: I/O ports at 2148 [size=8]
Region 1: I/O ports at 215c [size=4]
Region 2: I/O ports at 2140 [size=8]
Region 3: I/O ports at 2158 [size=4]
Region 4: I/O ports at 2060 [size=16]
Region 5: I/O ports@ffe0 [size=16]
Capabilities: [70] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [b0] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: ata_piix
00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus
Controller (rev 05)
Subsystem: Intel Corporation Apple MacBookPro8,2 [Core i7, 15", 2011]
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Interrupt: pin C routed to IRQ 11
Region 0: Memory at a0907000 (64-bit, non-prefetchable) [size=256]
Region 4: I/O ports@efa0 [size=32]
02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM57765
Gigabit Ethernet PCIe (rev 10)
Subsystem: Broadcom Corporation NetXtreme BCM57765 Gigabit Ethernet PCIe
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 256 bytes
Interrupt: pin A routed to IRQ 16
Region 0: Memory at a0400000 (64-bit, prefetchable) [size=64K]
Region 2: Memory@a0410000 (64-bit, prefetchable) [size=64K]
Capabilities: [48] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [58] MSI: Enable- Count=1/8 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [a0] MSI-X: Enable+ Count=6 Masked-
Vector table: BAR=2 offset=00000000
PBA: BAR=2 offset=00000120
Capabilities: [ac] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <4us, L1 <64us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr+ NoSnoop-
MaxPayload 128 bytes, MaxReadReq 4096 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <2us, L1
<64us
ClockPM+ Surprise- LLActRep- BwNot-
LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt-
ABWMgmt-
DevCap2: Completion Timeout: Range ABCD, TimeoutDis+
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-, Selectable
De-emphasis: -6dB
Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-,
EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP-
ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP-
ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+
ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [13c v1] Device Serial Number 00-00-3c-07-54-52-c0-d1
Capabilities: [150 v1] Power Budgeting <?>
Capabilities: [160 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
Status: NegoPending- InProgress-
Kernel driver in use: tg3
02:00.1 SD Host controller: Broadcom Corporation NetXtreme BCM57765 Memory
Card Reader (rev 10) (prog-if 01)
Subsystem: Broadcom Corporation Device 0000
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 256 bytes
Interrupt: pin B routed to IRQ 17
Region 0: Memory@a0420000 (64-bit, prefetchable) [size=64K]
Capabilities: [48] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [58] MSI: Enable- Count=1/1 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [ac] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <4us, L1 <64us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr+ NoSnoop+
MaxPayload 128 bytes, MaxReadReq 4096 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <2us, L1
<64us
ClockPM+ Surprise- LLActRep- BwNot-
LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt-
ABWMgmt-
DevCap2: Completion Timeout: Range ABCD, TimeoutDis+
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-, Selectable
De-emphasis: -6dB
Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-,
EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP-
ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP-
ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+
ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [150 v1] Power Budgeting <?>
Capabilities: [160 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
Status: NegoPending- InProgress-
Kernel driver in use: sdhci-pci
03:00.0 Network controller: Broadcom Corporation BCM4331 802.11a/b/g/n (rev
02)
Subsystem: Apple Inc. Device 00e4
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 256 bytes
Interrupt: pin A routed to IRQ 17
Region 0: Memory@a0600000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=2 PME-
Capabilities: [58] Vendor Specific Information: Len=78 <?>
Capabilities: [48] MSI: Enable- Count=1/1 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [d0] Express (v1) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited
ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <4us, L1
<64us
ClockPM+ Surprise- LLActRep+ BwNot-
LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt-
ABWMgmt-
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP-
ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP-
ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+
ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 14, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [13c v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
Status: NegoPending- InProgress-
Capabilities: [160 v1] Device Serial Number 87-7d-6d-ff-ff-57-68-a8
Capabilities: [16c v1] Power Budgeting <?>
Kernel driver in use: bcma-pci-bridge
04:00.0 PCI bridge: Texas Instruments XIO2213A/B/XIO2221 PCI Express to PCI
Bridge [Cheetah Express] (rev 01) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 256 bytes
Bus: primary=04, secondary=05, subordinate=05, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: a0500000-a05fffff
Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
Secondary status: 66MHz+ FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Bridge: PM- B3+
Capabilities: [60] MSI: Enable- Count=1/16 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [80] Subsystem: Device 0000:0000
Capabilities: [90] Express (v1) PCI/PCI-X Bridge, MSI 00
DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ BrConfRtry-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns,
L1 <16us
ClockPM+ Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; Disabled- Retrain- CommClk+
ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt-
ABWMgmt-
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP-
ECRC- UnsupReq+ ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP-
ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+
ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 14, GenCap+ CGenEn- ChkCap+ ChkEn-
05:00.0 FireWire (IEEE 1394): Texas Instruments XIO2213A/B/XIO2221
IEEE-1394b OHCI Controller [Cheetah Express] (rev 01) (prog-if 10 [OHCI])
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 248 (500ns min, 1000ns max), Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 18
Region 0: Memory at a0504000 (32-bit, non-prefetchable) [size=2K]
Region 1: Memory at a0500000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [44] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME+
Kernel driver in use: firewire_ohci
callum@callum-Macmini:~$ sudo lspci -vvv
00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family
DRAM Controller (rev 09)
Subsystem: Apple Inc. Device 00e6
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort+ >SERR- <PERR- INTx-
Latency: 0
Capabilities: [e0] Vendor Specific Information: Len=0c <?>
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core
Processor Family PCI Express Root Port (rev 09) (prog-if 00 [Normal decode])
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 256 bytes
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: a0800000-a08fffff
Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [88] Subsystem: Apple Inc. Device 00e6
Capabilities: [80] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0f00c Data: 41b1
Capabilities: [a0] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
LnkCap: Port #2, Speed 5GT/s, Width x8, ASPM L0s L1, Latency L0 <1us, L1
<4us
ClockPM- Surprise- LLActRep- BwNot+
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled+ Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk+ DLActive- BWMgmt-
ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
Slot #1, PowerLimit 75.000W; Interlock- NoCompl+
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- Interlock-
Changed: MRL- PresDet- LinkState-
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
DevCap2: Completion Timeout: Not Supported, TimeoutDis- ARIFwd-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- ARIFwd-
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-, Selectable
De-emphasis: -3.5dB
Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-,
EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [100 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed+ WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
Status: NegoPending- InProgress-
Capabilities: [140 v1] Root Complex Link
Desc: PortNumber=02 ComponentID=01 EltType=Config
Link0: Desc: TargetPort=00 TargetComponent=01 AssocRCRB- LinkType=MemMapped
LinkValid+
Addr: 00000000fed19000
Kernel driver in use: pcieport
00:01.1 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core
Processor Family PCI Express Root Port (rev 09) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 256 bytes
Bus: primary=00, secondary=06, subordinate=9c, sec-latency=0
I/O behind bridge: 00003000-00003fff
Memory behind bridge: a0a00000-a4efffff
Prefetchable memory behind bridge: 00000000a4f00000-00000000a8efffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [88] Subsystem: Apple Inc. Device 00e6
Capabilities: [80] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0f00c Data: 41c1
Capabilities: [a0] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
LnkCap: Port #3, Speed 5GT/s, Width x8, ASPM L0s L1, Latency L0 <256ns, L1
<4us
ClockPM- Surprise- LLActRep- BwNot+
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled+ Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 5GT/s, Width x4, TrErr- Train- SlotClk+ DLActive- BWMgmt+
ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
Slot #2, PowerLimit 75.000W; Interlock- NoCompl+
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
Changed: MRL- PresDet+ LinkState-
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
DevCap2: Completion Timeout: Not Supported, TimeoutDis- ARIFwd-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- ARIFwd-
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-, Selectable
De-emphasis: -3.5dB
Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-,
EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [100 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed+ WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
Status: NegoPending- InProgress-
Capabilities: [140 v1] Root Complex Link
Desc: PortNumber=03 ComponentID=01 EltType=Config
Link0: Desc: TargetPort=00 TargetComponent=01 AssocRCRB- LinkType=MemMapped
LinkValid+
Addr: 00000000fed19000
Kernel driver in use: pcieport
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core
Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 [VGA
controller])
Subsystem: Apple Inc. Device 00e6
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 46
Region 0: Memory at a0000000 (64-bit, non-prefetchable) [size=4M]
Region 2: Memory at 90000000 (64-bit, prefetchable) [size=256M]
Region 4: I/O ports at 2000 [size=64]
Expansion ROM@<unassigned> [disabled]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0f00c Data: 4152
Capabilities: [d0] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [a4] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: i915
00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series
Chipset Family MEI Controller #1 (rev 04)
Subsystem: Intel Corporation Apple MacBookPro8,2 [Core i7, 15", 2011]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 45
Region 0: Memory@a0907100 (64-bit, non-prefetchable) [size=16]
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [8c] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee0f00c Data: 4142
Kernel driver in use: mei
00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset
Family USB Universal Host Controller #5 (rev 05) (prog-if 00 [UHCI])
Subsystem: Intel Corporation Apple MacBookPro8,2 [Core i7, 15", 2011]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin B routed to IRQ 21
Region 4: I/O ports@2120 [size=32]
Capabilities: [50] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: uhci_hcd
00:1a.7 USB controller: Intel Corporation 6 Series/C200 Series Chipset
Family USB Enhanced Host Controller #2 (rev 05) (prog-if 20 [EHCI])
Subsystem: Intel Corporation Apple MacBookPro8,2 [Core i7, 15", 2011]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 23
Region 0: Memory@a0906c00 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Debug port: BAR=1 offset=00a0
Capabilities: [98] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: ehci-pci
00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family
High Definition Audio Controller (rev 05)
Subsystem: Intel Corporation Apple MacBookPro8,2 [Core i7, 15", 2011]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 256 bytes
Interrupt: pin A routed to IRQ 47
Region 0: Memory@a0900000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee0f00c Data: 4162
Capabilities: [70] Express (v1) Root Complex Integrated Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- RBE- FLReset+
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #0, Speed unknown, Width x0, ASPM unknown, Latency L0 <64ns,
L1 <1us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; Disabled- Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed unknown, Width x0, TrErr- Train- SlotClk- DLActive- BWMgmt-
ABWMgmt-
Capabilities: [100 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
Status: NegoPending- InProgress-
VC1: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=1 ArbSelect=Fixed TC/VC=22
Status: NegoPending- InProgress-
Capabilities: [130 v1] Root Complex Link
Desc: PortNumber=0f ComponentID=00 EltType=Config
Link0: Desc: TargetPort=00 TargetComponent=00 AssocRCRB-
LinkType=MemMapped LinkValid+
Addr: 00000000fed1c000
Kernel driver in use: snd_hda_intel
00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family
PCI Express Root Port 1 (rev b5) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 256 bytes
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: a0700000-a07fffff
Prefetchable memory behind bridge: 00000000a0400000-00000000a04fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal+ Fatal+ Unsupported+
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #1, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, L1
<16us
ClockPM- Surprise- LLActRep+ BwNot-
LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+
ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
Slot #0, PowerLimit 10.000W; Interlock- NoCompl+
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
Changed: MRL- PresDet- LinkState+
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
DevCap2: Completion Timeout: Range BC, TimeoutDis+ ARIFwd-
DevCtl2: Completion Timeout: 260ms to 900ms, TimeoutDis- ARIFwd-
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-, Selectable
De-emphasis: -6dB
Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-,
EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0f00c Data: 41d1
Capabilities: [90] Subsystem: Intel Corporation Apple MacBookPro8,2 [Core
i7, 15", 2011]
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: pcieport
00:1c.1 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family
PCI Express Root Port 2 (rev b5) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 256 bytes
Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: a0600000-a06fffff
Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal+ Fatal+ Unsupported+
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #2, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, L1
<16us
ClockPM- Surprise- LLActRep+ BwNot-
LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+
ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
Slot #0, PowerLimit 10.000W; Interlock- NoCompl+
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
Changed: MRL- PresDet- LinkState+
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
DevCap2: Completion Timeout: Range BC, TimeoutDis+ ARIFwd-
DevCtl2: Completion Timeout: 260ms to 900ms, TimeoutDis- ARIFwd-
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-, Selectable
De-emphasis: -6dB
Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-,
EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0f00c Data: 41e1
Capabilities: [90] Subsystem: Intel Corporation Apple MacBookPro8,2 [Core
i7, 15", 2011]
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: pcieport
00:1c.2 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family
PCI Express Root Port 3 (rev b5) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 256 bytes
Bus: primary=00, secondary=04, subordinate=05, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: a0500000-a05fffff
Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal+ Fatal+ Unsupported+
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #3, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 <1us, L1
<16us
ClockPM- Surprise- LLActRep+ BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+
ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
Slot #0, PowerLimit 10.000W; Interlock- NoCompl+
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
Changed: MRL- PresDet- LinkState+
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
DevCap2: Completion Timeout: Range BC, TimeoutDis+ ARIFwd-
DevCtl2: Completion Timeout: 260ms to 900ms, TimeoutDis- ARIFwd-
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-, Selectable
De-emphasis: -6dB
Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-,
EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0f00c Data: 4122
Capabilities: [90] Subsystem: Intel Corporation Apple MacBookPro8,2 [Core
i7, 15", 2011]
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: pcieport
00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset
Family USB Universal Host Controller #1 (rev 05) (prog-if 00 [UHCI])
Subsystem: Intel Corporation Apple MacBookPro8,2 [Core i7, 15", 2011]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin B routed to IRQ 19
Region 4: I/O ports@20c0 [size=32]
Capabilities: [50] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: uhci_hcd
00:1d.7 USB controller: Intel Corporation 6 Series/C200 Series Chipset
Family USB Enhanced Host Controller #1 (rev 05) (prog-if 20 [EHCI])
Subsystem: Intel Corporation Apple MacBookPro8,2 [Core i7, 15", 2011]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 22
Region 0: Memory@a0906800 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Debug port: BAR=1 offset=00a0
Capabilities: [98] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: ehci-pci
00:1f.0 ISA bridge: Intel Corporation HM65 Express Chipset Family LPC
Controller (rev 05)
Subsystem: Intel Corporation Apple MacBookPro8,2 [Core i7, 15", 2011]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0
Capabilities: [e0] Vendor Specific Information: Len=0c <?>
Kernel driver in use: lpc_ich
00:1f.2 IDE interface: Intel Corporation 6 Series/C200 Series Chipset
Family 4 port SATA IDE Controller (rev 05) (prog-if 8f [Master SecP SecO
PriP PriO])
Subsystem: Intel Corporation Device 7270
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin B routed to IRQ 19
Region 0: I/O ports at 2148 [size=8]
Region 1: I/O ports at 215c [size=4]
Region 2: I/O ports at 2140 [size=8]
Region 3: I/O ports at 2158 [size=4]
Region 4: I/O ports at 2060 [size=16]
Region 5: I/O ports@ffe0 [size=16]
Capabilities: [70] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [b0] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: ata_piix
00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus
Controller (rev 05)
Subsystem: Intel Corporation Apple MacBookPro8,2 [Core i7, 15", 2011]
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Interrupt: pin C routed to IRQ 11
Region 0: Memory at a0907000 (64-bit, non-prefetchable) [size=256]
Region 4: I/O ports@efa0 [size=32]
02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM57765
Gigabit Ethernet PCIe (rev 10)
Subsystem: Broadcom Corporation NetXtreme BCM57765 Gigabit Ethernet PCIe
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 256 bytes
Interrupt: pin A routed to IRQ 16
Region 0: Memory at a0400000 (64-bit, prefetchable) [size=64K]
Region 2: Memory@a0410000 (64-bit, prefetchable) [size=64K]
Capabilities: [48] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [58] MSI: Enable- Count=1/8 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [a0] MSI-X: Enable+ Count=6 Masked-
Vector table: BAR=2 offset=00000000
PBA: BAR=2 offset=00000120
Capabilities: [ac] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <4us, L1 <64us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr+ NoSnoop-
MaxPayload 128 bytes, MaxReadReq 4096 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <2us, L1
<64us
ClockPM+ Surprise- LLActRep- BwNot-
LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt-
ABWMgmt-
DevCap2: Completion Timeout: Range ABCD, TimeoutDis+
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-, Selectable
De-emphasis: -6dB
Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-,
EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP-
ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP-
ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+
ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [13c v1] Device Serial Number 00-00-3c-07-54-52-c0-d1
Capabilities: [150 v1] Power Budgeting <?>
Capabilities: [160 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
Status: NegoPending- InProgress-
Kernel driver in use: tg3
02:00.1 SD Host controller: Broadcom Corporation NetXtreme BCM57765 Memory
Card Reader (rev 10) (prog-if 01)
Subsystem: Broadcom Corporation Device 0000
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 256 bytes
Interrupt: pin B routed to IRQ 17
Region 0: Memory@a0420000 (64-bit, prefetchable) [size=64K]
Capabilities: [48] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [58] MSI: Enable- Count=1/1 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [ac] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <4us, L1 <64us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr+ NoSnoop+
MaxPayload 128 bytes, MaxReadReq 4096 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <2us, L1
<64us
ClockPM+ Surprise- LLActRep- BwNot-
LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt-
ABWMgmt-
DevCap2: Completion Timeout: Range ABCD, TimeoutDis+
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-, Selectable
De-emphasis: -6dB
Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-,
EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP-
ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP-
ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+
ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [150 v1] Power Budgeting <?>
Capabilities: [160 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
Status: NegoPending- InProgress-
Kernel driver in use: sdhci-pci
03:00.0 Network controller: Broadcom Corporation BCM4331 802.11a/b/g/n (rev
02)
Subsystem: Apple Inc. Device 00e4
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 256 bytes
Interrupt: pin A routed to IRQ 17
Region 0: Memory@a0600000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=2 PME-
Capabilities: [58] Vendor Specific Information: Len=78 <?>
Capabilities: [48] MSI: Enable- Count=1/1 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [d0] Express (v1) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited
ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <4us, L1
<64us
ClockPM+ Surprise- LLActRep+ BwNot-
LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt-
ABWMgmt-
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP-
ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP-
ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+
ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 14, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [13c v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
Status: NegoPending- InProgress-
Capabilities: [160 v1] Device Serial Number 87-7d-6d-ff-ff-57-68-a8
Capabilities: [16c v1] Power Budgeting <?>
Kernel driver in use: bcma-pci-bridge
04:00.0 PCI bridge: Texas Instruments XIO2213A/B/XIO2221 PCI Express to PCI
Bridge [Cheetah Express] (rev 01) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 256 bytes
Bus: primary=04, secondary=05, subordinate=05, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: a0500000-a05fffff
Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
Secondary status: 66MHz+ FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Bridge: PM- B3+
Capabilities: [60] MSI: Enable- Count=1/16 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [80] Subsystem: Device 0000:0000
Capabilities: [90] Express (v1) PCI/PCI-X Bridge, MSI 00
DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ BrConfRtry-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns,
L1 <16us
ClockPM+ Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; Disabled- Retrain- CommClk+
ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt-
ABWMgmt-
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP-
ECRC- UnsupReq+ ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP-
ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+
ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 14, GenCap+ CGenEn- ChkCap+ ChkEn-
05:00.0 FireWire (IEEE 1394): Texas Instruments XIO2213A/B/XIO2221
IEEE-1394b OHCI Controller [Cheetah Express] (rev 01) (prog-if 10 [OHCI])
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 248 (500ns min, 1000ns max), Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 18
Region 0: Memory at a0504000 (32-bit, non-prefetchable) [size=2K]
Region 1: Memory at a0500000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [44] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME+
Kernel driver in use: firewire_ohci
callum at callum-Macmini:~$ clear
callum@callum-Macmini:~$ sudo lspci -vvv
00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family
DRAM Controller (rev 09)
Subsystem: Apple Inc. Device 00e6
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort+ >SERR- <PERR- INTx-
Latency: 0
Capabilities: [e0] Vendor Specific Information: Len=0c <?>
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core
Processor Family PCI Express Root Port (rev 09) (prog-if 00 [Normal decode])
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 256 bytes
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: a0800000-a08fffff
Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [88] Subsystem: Apple Inc. Device 00e6
Capabilities: [80] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0f00c Data: 41b1
Capabilities: [a0] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
LnkCap: Port #2, Speed 5GT/s, Width x8, ASPM L0s L1, Latency L0 <1us, L1
<4us
ClockPM- Surprise- LLActRep- BwNot+
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled+ Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk+ DLActive- BWMgmt-
ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
Slot #1, PowerLimit 75.000W; Interlock- NoCompl+
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- Interlock-
Changed: MRL- PresDet- LinkState-
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
DevCap2: Completion Timeout: Not Supported, TimeoutDis- ARIFwd-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- ARIFwd-
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-, Selectable
De-emphasis: -3.5dB
Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-,
EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [100 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed+ WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
Status: NegoPending- InProgress-
Capabilities: [140 v1] Root Complex Link
Desc: PortNumber=02 ComponentID=01 EltType=Config
Link0: Desc: TargetPort=00 TargetComponent=01 AssocRCRB- LinkType=MemMapped
LinkValid+
Addr: 00000000fed19000
Kernel driver in use: pcieport
00:01.1 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core
Processor Family PCI Express Root Port (rev 09) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 256 bytes
Bus: primary=00, secondary=06, subordinate=9c, sec-latency=0
I/O behind bridge: 00003000-00003fff
Memory behind bridge: a0a00000-a4efffff
Prefetchable memory behind bridge: 00000000a4f00000-00000000a8efffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [88] Subsystem: Apple Inc. Device 00e6
Capabilities: [80] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0f00c Data: 41c1
Capabilities: [a0] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
LnkCap: Port #3, Speed 5GT/s, Width x8, ASPM L0s L1, Latency L0 <256ns, L1
<4us
ClockPM- Surprise- LLActRep- BwNot+
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled+ Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 5GT/s, Width x4, TrErr- Train- SlotClk+ DLActive- BWMgmt+
ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
Slot #2, PowerLimit 75.000W; Interlock- NoCompl+
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
Changed: MRL- PresDet+ LinkState-
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
DevCap2: Completion Timeout: Not Supported, TimeoutDis- ARIFwd-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- ARIFwd-
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-, Selectable
De-emphasis: -3.5dB
Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-,
EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [100 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed+ WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
Status: NegoPending- InProgress-
Capabilities: [140 v1] Root Complex Link
Desc: PortNumber=03 ComponentID=01 EltType=Config
Link0: Desc: TargetPort=00 TargetComponent=01 AssocRCRB- LinkType=MemMapped
LinkValid+
Addr: 00000000fed19000
Kernel driver in use: pcieport
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core
Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 [VGA
controller])
Subsystem: Apple Inc. Device 00e6
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 46
Region 0: Memory at a0000000 (64-bit, non-prefetchable) [size=4M]
Region 2: Memory at 90000000 (64-bit, prefetchable) [size=256M]
Region 4: I/O ports at 2000 [size=64]
Expansion ROM@<unassigned> [disabled]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0f00c Data: 4152
Capabilities: [d0] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [a4] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: i915
00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series
Chipset Family MEI Controller #1 (rev 04)
Subsystem: Intel Corporation Apple MacBookPro8,2 [Core i7, 15", 2011]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 45
Region 0: Memory@a0907100 (64-bit, non-prefetchable) [size=16]
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [8c] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee0f00c Data: 4142
Kernel driver in use: mei
00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset
Family USB Universal Host Controller #5 (rev 05) (prog-if 00 [UHCI])
Subsystem: Intel Corporation Apple MacBookPro8,2 [Core i7, 15", 2011]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin B routed to IRQ 21
Region 4: I/O ports@2120 [size=32]
Capabilities: [50] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: uhci_hcd
00:1a.7 USB controller: Intel Corporation 6 Series/C200 Series Chipset
Family USB Enhanced Host Controller #2 (rev 05) (prog-if 20 [EHCI])
Subsystem: Intel Corporation Apple MacBookPro8,2 [Core i7, 15", 2011]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 23
Region 0: Memory@a0906c00 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Debug port: BAR=1 offset=00a0
Capabilities: [98] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP+
Kernel driver in use: ehci-pci
00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family
High Definition Audio Controller (rev 05)
Subsystem: Intel Corporation Apple MacBookPro8,2 [Core i7, 15", 2011]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 256 bytes
Interrupt: pin A routed to IRQ 47
Region 0: Memory@a0900000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee0f00c Data: 4162
Capabilities: [70] Express (v1) Root Complex Integrated Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- RBE- FLReset+
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #0, Speed unknown, Width x0, ASPM unknown, Latency L0 <64ns,
L1 <1us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; Disabled- Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed unknown, Width x0, TrErr- Train- SlotClk- DLActive- BWMgmt-
ABWMgmt-
Capabilities: [100 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
Status: NegoPending- InProgress-
VC1: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=1 ArbSelect=Fixed TC/VC=22
Status: NegoPending- InProgress-
Capabilities: [130 v1] Root Complex Link
Desc: PortNumber=0f ComponentID=00 EltType=Config
Link0: Desc: TargetPort=00 TargetComponent=00 AssocRCRB-
LinkType=MemMapped LinkValid+
Addr: 00000000fed1c000
Kernel driver in use: snd_hda_intel
00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family
PCI Express Root Port 1 (rev b5) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 256 bytes
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: a0700000-a07fffff
Prefetchable memory behind bridge: 00000000a0400000-00000000a04fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal+ Fatal+ Unsupported+
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #1, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, L1
<16us
ClockPM- Surprise- LLActRep+ BwNot-
LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+
ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
Slot #0, PowerLimit 10.000W; Interlock- NoCompl+
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
Changed: MRL- PresDet- LinkState+
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
DevCap2: Completion Timeout: Range BC, TimeoutDis+ ARIFwd-
DevCtl2: Completion Timeout: 260ms to 900ms, TimeoutDis- ARIFwd-
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-, Selectable
De-emphasis: -6dB
Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-,
EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0f00c Data: 41d1
Capabilities: [90] Subsystem: Intel Corporation Apple MacBookPro8,2 [Core
i7, 15", 2011]
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: pcieport
00:1c.1 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family
PCI Express Root Port 2 (rev b5) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 256 bytes
Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: a0600000-a06fffff
Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal+ Fatal+ Unsupported+
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #2, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, L1
<16us
ClockPM- Surprise- LLActRep+ BwNot-
LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+
ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
Slot #0, PowerLimit 10.000W; Interlock- NoCompl+
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
Changed: MRL- PresDet- LinkState+
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
DevCap2: Completion Timeout: Range BC, TimeoutDis+ ARIFwd-
DevCtl2: Completion Timeout: 260ms to 900ms, TimeoutDis- ARIFwd-
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-, Selectable
De-emphasis: -6dB
Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-,
EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0f00c Data: 41e1
Capabilities: [90] Subsystem: Intel Corporation Apple MacBookPro8,2 [Core
i7, 15", 2011]
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: pcieport
00:1c.2 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family
PCI Express Root Port 3 (rev b5) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 256 bytes
Bus: primary=00, secondary=04, subordinate=05, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: a0500000-a05fffff
Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal+ Fatal+ Unsupported+
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #3, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 <1us, L1
<16us
ClockPM- Surprise- LLActRep+ BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+
ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
Slot #0, PowerLimit 10.000W; Interlock- NoCompl+
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
Changed: MRL- PresDet- LinkState+
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
DevCap2: Completion Timeout: Range BC, TimeoutDis+ ARIFwd-
DevCtl2: Completion Timeout: 260ms to 900ms, TimeoutDis- ARIFwd-
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-, Selectable
De-emphasis: -6dB
Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-,
EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0f00c Data: 4122
Capabilities: [90] Subsystem: Intel Corporation Apple MacBookPro8,2 [Core
i7, 15", 2011]
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: pcieport
00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset
Family USB Universal Host Controller #1 (rev 05) (prog-if 00 [UHCI])
Subsystem: Intel Corporation Apple MacBookPro8,2 [Core i7, 15", 2011]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin B routed to IRQ 19
Region 4: I/O ports@20c0 [size=32]
Capabilities: [50] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: uhci_hcd
00:1d.7 USB controller: Intel Corporation 6 Series/C200 Series Chipset
Family USB Enhanced Host Controller #1 (rev 05) (prog-if 20 [EHCI])
Subsystem: Intel Corporation Apple MacBookPro8,2 [Core i7, 15", 2011]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 22
Region 0: Memory@a0906800 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Debug port: BAR=1 offset=00a0
Capabilities: [98] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: ehci-pci
00:1f.0 ISA bridge: Intel Corporation HM65 Express Chipset Family LPC
Controller (rev 05)
Subsystem: Intel Corporation Apple MacBookPro8,2 [Core i7, 15", 2011]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0
Capabilities: [e0] Vendor Specific Information: Len=0c <?>
Kernel driver in use: lpc_ich
00:1f.2 IDE interface: Intel Corporation 6 Series/C200 Series Chipset
Family 4 port SATA IDE Controller (rev 05) (prog-if 8f [Master SecP SecO
PriP PriO])
Subsystem: Intel Corporation Device 7270
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin B routed to IRQ 19
Region 0: I/O ports at 2148 [size=8]
Region 1: I/O ports at 215c [size=4]
Region 2: I/O ports at 2140 [size=8]
Region 3: I/O ports at 2158 [size=4]
Region 4: I/O ports at 2060 [size=16]
Region 5: I/O ports@ffe0 [size=16]
Capabilities: [70] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [b0] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: ata_piix
00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus
Controller (rev 05)
Subsystem: Intel Corporation Apple MacBookPro8,2 [Core i7, 15", 2011]
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Interrupt: pin C routed to IRQ 11
Region 0: Memory at a0907000 (64-bit, non-prefetchable) [size=256]
Region 4: I/O ports@efa0 [size=32]
02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM57765
Gigabit Ethernet PCIe (rev 10)
Subsystem: Broadcom Corporation NetXtreme BCM57765 Gigabit Ethernet PCIe
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 256 bytes
Interrupt: pin A routed to IRQ 16
Region 0: Memory at a0400000 (64-bit, prefetchable) [size=64K]
Region 2: Memory@a0410000 (64-bit, prefetchable) [size=64K]
Capabilities: [48] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [58] MSI: Enable- Count=1/8 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [a0] MSI-X: Enable+ Count=6 Masked-
Vector table: BAR=2 offset=00000000
PBA: BAR=2 offset=00000120
Capabilities: [ac] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <4us, L1 <64us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr+ NoSnoop-
MaxPayload 128 bytes, MaxReadReq 4096 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <2us, L1
<64us
ClockPM+ Surprise- LLActRep- BwNot-
LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt-
ABWMgmt-
DevCap2: Completion Timeout: Range ABCD, TimeoutDis+
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-, Selectable
De-emphasis: -6dB
Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-,
EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP-
ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP-
ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+
ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [13c v1] Device Serial Number 00-00-3c-07-54-52-c0-d1
Capabilities: [150 v1] Power Budgeting <?>
Capabilities: [160 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
Status: NegoPending- InProgress-
Kernel driver in use: tg3
02:00.1 SD Host controller: Broadcom Corporation NetXtreme BCM57765 Memory
Card Reader (rev 10) (prog-if 01)
Subsystem: Broadcom Corporation Device 0000
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 256 bytes
Interrupt: pin B routed to IRQ 17
Region 0: Memory@a0420000 (64-bit, prefetchable) [size=64K]
Capabilities: [48] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [58] MSI: Enable- Count=1/1 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [ac] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <4us, L1 <64us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr+ NoSnoop+
MaxPayload 128 bytes, MaxReadReq 4096 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <2us, L1
<64us
ClockPM+ Surprise- LLActRep- BwNot-
LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt-
ABWMgmt-
DevCap2: Completion Timeout: Range ABCD, TimeoutDis+
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-, Selectable
De-emphasis: -6dB
Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-,
EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP-
ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP-
ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+
ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [150 v1] Power Budgeting <?>
Capabilities: [160 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
Status: NegoPending- InProgress-
Kernel driver in use: sdhci-pci
03:00.0 Network controller: Broadcom Corporation BCM4331 802.11a/b/g/n (rev
02)
Subsystem: Apple Inc. Device 00e4
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 256 bytes
Interrupt: pin A routed to IRQ 17
Region 0: Memory@a0600000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=2 PME-
Capabilities: [58] Vendor Specific Information: Len=78 <?>
Capabilities: [48] MSI: Enable- Count=1/1 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [d0] Express (v1) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited
ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <4us, L1
<64us
ClockPM+ Surprise- LLActRep+ BwNot-
LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt-
ABWMgmt-
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP-
ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP-
ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+
ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 14, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [13c v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
Status: NegoPending- InProgress-
Capabilities: [160 v1] Device Serial Number 87-7d-6d-ff-ff-57-68-a8
Capabilities: [16c v1] Power Budgeting <?>
Kernel driver in use: bcma-pci-bridge
04:00.0 PCI bridge: Texas Instruments XIO2213A/B/XIO2221 PCI Express to PCI
Bridge [Cheetah Express] (rev 01) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 256 bytes
Bus: primary=04, secondary=05, subordinate=05, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: a0500000-a05fffff
Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
Secondary status: 66MHz+ FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Bridge: PM- B3+
Capabilities: [60] MSI: Enable- Count=1/16 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [80] Subsystem: Device 0000:0000
Capabilities: [90] Express (v1) PCI/PCI-X Bridge, MSI 00
DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ BrConfRtry-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns,
L1 <16us
ClockPM+ Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; Disabled- Retrain- CommClk+
ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt-
ABWMgmt-
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP-
ECRC- UnsupReq+ ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP-
ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+
ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 14, GenCap+ CGenEn- ChkCap+ ChkEn-
05:00.0 FireWire (IEEE 1394): Texas Instruments XIO2213A/B/XIO2221
IEEE-1394b OHCI Controller [Cheetah Express] (rev 01) (prog-if 10 [OHCI])
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 248 (500ns min, 1000ns max), Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 18
Region 0: Memory at a0504000 (32-bit, non-prefetchable) [size=2K]
Region 1: Memory@a0500000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [44] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME+
Kernel driver in use: firewire_ohci
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: ATA Model: Hitachi HTS54505 Rev: PB4A
Type: Direct-Access ANSI SCSI revision: 05
(Apologies to the kernel devs for any useless crap/long reading, I'm just
following the guide to reporting a proper bug for you from
https://wiki.ubuntu.com/Bugs/Upstream/kernel )
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-04-09 14:12 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-04-09 14:12 UTC (permalink / raw)
To: u-boot
Even if I add this patch, no any defect, right?
>
>Best Regards,
>Bo Shen
>
>>
>> Best Regards,
>> Alex
>>
>>
>
------=_Part_125741_1342606970.1366262863555--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-04-09 14:12 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-04-09 14:12 UTC (permalink / raw)
To: u-boot
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-04-09 14:12 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-04-09 14:12 UTC (permalink / raw)
To: u-boot
The code was written at 4 years ago.
I'll see if there is a better way, and it'll be updated at next version
when I got luck.
>> + /* page read */
>> + for (off = 0; len > 0; len -= 4, off += 4) {
>> + while (!(NAND_READ(®s->ior) & IOR_READY))
>> + ;
>> + *(uint32_t *)(buf + off) = NAND_READ(®s->dr);
>> + }
>
>
> Why do you need to check IOR_READY here but not in read_byte?
>
>
Because there is no any hardware access in 'read_byte'.
The FTNANDC021 simplily does not support byte access by default.
(I mean it's possible to update hardware RTL code,
but it's not the case to A369)
So I add some tricks to READ_ID, READ_OOB and READ_STATUS.
The actual hardware access is performed at ftnandc021_cmdfunc(),
The ftnandc021_read_byte() simpily access the cached data buffer.
>> +static void
>> +ftnandc021_cmdfunc(struct mtd_info *mtd, unsigned cmd, int column, int
>> pgidx)
>> +{
>> + struct nand_chip *chip = mtd->priv;
>> + struct ftnandc021_chip *priv = chip->priv;
>> + struct ftnandc021_regs *regs = priv->iobase;
>> +
>> + priv->cmd = cmd;
>> + priv->pgidx = pgidx;
>> +
>> + switch (cmd) {
>> + case NAND_CMD_READID: /* 0x90 */
>> + if (ftnandc021_command(priv, FTNANDC021_CMD_RDID)) {
>> + printf("ftnandc021: RDID failed.\n");
>> + } else {
>> + put_unaligned_le32(NAND_READ(®s->idr[0]),
>> + priv->buf);
>> + put_unaligned_le32(NAND_READ(®s->idr[1]),
>> + priv->buf + 4);
>> + priv->off = 0;
>> + }
>> + break;
>
>
> Do error handling like this:
>
> if (ftnandc021_command(priv, FTNANDC021_CMD_RDID)) {
> printf(...);
> break;
> }
>
> put_unaligned...
> ...
>
> Why would it be unaligned?
> Why _le32?
It's a historic issue, I think.
It's too long (4 years..) to me to recall the reason,
and it's obviously not necessary right now, so it would be
updated at next version.
> Can you not read a byte at a time here?
>
>
No, the FTNANDC021 does not support byte access.
>> +/**
>> + * hardware specific access to control-lines
>> + * @mtd: MTD device structure
>> + * @cmd: command to device
>> + * @ctrl:
>> + * NAND_NCE: bit 0 -> don't care
>> + * NAND_CLE: bit 1 -> Command Latch
>> + * NAND_ALE: bit 2 -> Address Latch
>> + *
>> + * NOTE: boards may use different bits for these!!
>> + */
>> +static void
>> +ftnandc021_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int ctrl)
>> +{
>> +}
>
>
> Just leave the function pointer NULL.
>
>
Got it, thanks
>> + chip->ecc.mode = NAND_ECC_NONE;
>
>
> Really, no ECC at all? That is quite broken. There is absolutely no way
> to get access to the full OOB in order to do software ECC?
>
> Or is it doing hardware ECC in a way that is transparent? You should
> still use NAND_ECC_HARD in that case.
>
>
>> + chip->ecc.layout = &ftnandc021_oob_2k;
>
>
> What if it's not 2K NAND?
>
>
Please see the comments above.
And it would be clean up at next version.
>> diff --git a/include/faraday/nand.h b/include/faraday/nand.h
>> new file mode 100644
>> index 0000000..6d8efb2
>> --- /dev/null
>> +++ b/include/faraday/nand.h
>> @@ -0,0 +1,16 @@
>> +/*
>> + * Faraday NAND Flash Controller
>> + *
>> + * (C) Copyright 2010 Faraday Technology
>> + * Dante Su <dantesu@faraday-tech.com>
>> + *
>> + * This file is released under the terms of GPL v2 and any later version.
>> + * See the file COPYING in the root directory of the source tree for
>> details.
>> + */
>> +
>> +#ifndef _FARADAY_NAND_H
>> +#define _FARADAY_NAND_H
>> +
>> +int ftnandc021_probe(struct nand_chip *chip);
>
>
> New drivers should use CONFIG_SYS_NAND_SELF_INIT
>
> -Scott
--
Best wishes,
Kuo-Jung Su
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-04-09 14:12 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-04-09 14:12 UTC (permalink / raw)
To: u-boot
VF platform, but we can consider changing the code to make it fit for both.=
=0A=
=0A=
But I do not strongly insist that we must use the same code. If you find it=
's=0A=
Ugly to support both with the same code, I'm fine with the current code.=0A=
=0A=
[Alison Wang] I will change the code to make it fit for both in the next pa=
tch version. Thanks.=0A=
=0A=
>=0A=
>Jason Liu=0A=
>>+=0A=
>>+#endif /* __ASSEMBLY__ */=0A=
>>+#endif /* __ASM_ARCH_VYBRID_PINS_H__ */=0A=
>>diff --git a/arch/arm/include/asm/arch-vybrid/vybrid-regs.h=0A=
>>b/arch/arm/include/asm/arch-vybrid/vybrid-regs.h=0A=
>>new file mode 100644=0A=
>>index 0000000..51cfba5=0A=
>=0A=
>[..]=0A=
>=0A=
>Thanks!=0A=
>=0A=
>Best Regards,=0A=
>Alison Wang=0A=
>=0A=
>=0A=
=0A=
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-04-09 14:12 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-04-09 14:12 UTC (permalink / raw)
To: u-boot
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Gravitation cannot be held responsible for people falling in love."
- Albert Einstein
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-04-09 14:12 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-04-09 14:12 UTC (permalink / raw)
To: u-boot
wakeup" patch is missing.
Regards,
Rajeshwari Shinde.
On Sun, May 12, 2013 at 12:09 AM, Simon Glass <sjg@chromium.org> wrote:
> Hi Rajeshwari,
>
> On Wed, Apr 24, 2013 at 11:57 PM, Rajeshwari Shinde
> <rajeshwari.s@samsung.com> wrote:
>> This patch performs the following:
>>
>> 1) Convert the assembly code for memory and clock initialization to C co=
de.
>> 2) Move the memory and clock init codes from board/samsung to arch/arm
>> 3) Creat a common lowlevel_init file across Exynos4 and Exynos5. Convert=
ed
>> the common lowlevel_init from assembly to C-code
>> 4) Made spl_boot.c and tzpc_init.c common for both exynos4 and exynos5.
>> 5) Enable CONFIG_SKIP_LOWLEVEL_INIT as stack pointer initialisation is a=
lready
>> done in _main.
>> 6) exynos-uboot-spl.lds made common across SMDKV310, Origen and SMDK5250=
.
>>
>> TEST: Tested SD-MMC boot on SMDK5250 and Origen.
>> Tested USB and SPI boot on SMDK5250
>> Compile tested for SMDKV310.
>>
>> Signed-off-by: Hatim Ali <hatim.rv@samsung.com>
>> Signed-off-by: Rajeshwari Shinde <rajeshwari.s@samsung.com>
>
> Congratulations on getting this patch together.
>
> It looks correct, but I had some problems getting it to build.
> Probably I am missing some other patch.
>
> Configuring for smdk5250 board...
> lowlevel_init.c: In function =91do_lowlevel_init=92:
> lowlevel_init.c:50:2: warning: implicit declaration of function
> =91get_reset_status=92 [-Wimplicit-function-declaration]
> spl_boot.c: In function =91board_init_f=92:
> spl_boot.c:141:3: warning: implicit declaration of function
> =91power_exit_wakeup=92 [-Wimplicit-function-declaration]
> arch/arm/cpu/armv7/exynos/libexynos.o: In function `board_init_f':
> /mnt/host/source/src/third_party/u-boot/files/arch/arm/cpu/armv7/exynos/s=
pl_boot.c:141:
> undefined reference to `power_exit_wakeup'
> arch/arm/cpu/armv7/exynos/libexynos.o: In function `do_lowlevel_init':
> /mnt/host/source/src/third_party/u-boot/files/arch/arm/cpu/armv7/exynos/l=
owlevel_init.c:50:
> undefined reference to `get_reset_status'
> make[1]: *** [/mnt/host/source/src/third_party/u-boot/files/spl/u-boot-sp=
l]
> Error 1
>
> I will send a separate email about the patch situation. Here are the
> patches I applied in reverse order - please let me know if I missed
> any.
>
> d3858f7 (HEAD, snow2) EXYNOS: Move files from board/samsung to arch/arm.
> e666035 hack: Remove TPM definitions from exysno5-dt.h so that next
> patch applies cleanly
> c9ec2d1 EXYNOS4210: Configure GPIO for uart
> cf6e500 EXYNOS: LDS file move to common
> a40665b EXYNOS: Add API for power reset and shutdown
>
>
> Regards,
> Simon
>
>> ---
>> arch/arm/cpu/armv7/exynos/Makefile | 14 +-
>> .../arm/cpu/armv7/exynos}/clock_init.h | 0
>> arch/arm/cpu/armv7/exynos/clock_init_exynos4.c | 63 +++
>> .../arm/cpu/armv7/exynos/clock_init_exynos5.c | 26 +-
>> arch/arm/cpu/armv7/exynos/common_setup.h | 44 ++
>> .../arm/cpu/armv7/exynos}/dmc_common.c | 7 +-
>> .../arm/cpu/armv7/exynos}/dmc_init_ddr3.c | 17 +-
>> arch/arm/cpu/armv7/exynos/dmc_init_exynos4.c | 294 ++++++++++++
>> .../arm/cpu/armv7/exynos/exynos4_setup.h | 72 +++-
>> .../arm/cpu/armv7/exynos/exynos5_setup.h | 53 +--
>> arch/arm/cpu/armv7/exynos/lowlevel_init.c | 72 +++
>> .../arm/cpu/armv7/exynos}/spl_boot.c | 90 +++-
>> .../arm/cpu/armv7/exynos}/tzpc_init.c | 17 +-
>> arch/arm/include/asm/arch-exynos/spl.h | 1 +
>> arch/arm/include/asm/arch-exynos/tzpc.h | 28 ++
>> board/samsung/origen/Makefile | 7 -
>> board/samsung/origen/lowlevel_init.S | 397 -------------=
----
>> board/samsung/origen/mem_setup.S | 421 -------------=
-----
>> board/samsung/origen/mmc_boot.c | 58 ---
>> board/samsung/smdk5250/Makefile | 9 -
>> board/samsung/smdk5250/lowlevel_init.S | 2 +
>> board/samsung/smdkv310/Makefile | 10 +-
>> board/samsung/smdkv310/lowlevel_init.S | 470 -------------=
-------
>> board/samsung/smdkv310/mem_setup.S | 365 -------------=
--
>> board/samsung/smdkv310/mmc_boot.c | 60 ---
>> include/configs/exynos5250-dt.h | 12 +-
>> include/configs/origen.h | 9 +-
>> include/configs/smdkv310.h | 8 +-
>> spl/Makefile | 4 +
>> 29 files changed, 728 insertions(+), 1902 deletions(-)
>> rename {board/samsung/smdk5250 =3D> arch/arm/cpu/armv7/exynos}/clock_in=
it.h (100%)
>> create mode 100644 arch/arm/cpu/armv7/exynos/clock_init_exynos4.c
>> rename board/samsung/smdk5250/clock_init.c =3D> arch/arm/cpu/armv7/exyn=
os/clock_init_exynos5.c (97%)
>> create mode 100644 arch/arm/cpu/armv7/exynos/common_setup.h
>> rename {board/samsung/smdk5250 =3D> arch/arm/cpu/armv7/exynos}/dmc_comm=
on.c (97%)
>> rename {board/samsung/smdk5250 =3D> arch/arm/cpu/armv7/exynos}/dmc_init=
_ddr3.c (96%)
>> create mode 100644 arch/arm/cpu/armv7/exynos/dmc_init_exynos4.c
>> rename board/samsung/origen/origen_setup.h =3D> arch/arm/cpu/armv7/exyn=
os/exynos4_setup.h (89%)
>> rename board/samsung/smdk5250/setup.h =3D> arch/arm/cpu/armv7/exynos/ex=
ynos5_setup.h (93%)
>> create mode 100644 arch/arm/cpu/armv7/exynos/lowlevel_init.c
>> rename {board/samsung/smdk5250 =3D> arch/arm/cpu/armv7/exynos}/spl_boot=
.c (61%)
>> rename {board/samsung/smdk5250 =3D> arch/arm/cpu/armv7/exynos}/tzpc_ini=
t.c (81%)
>> delete mode 100644 board/samsung/origen/lowlevel_init.S
>> delete mode 100644 board/samsung/origen/mem_setup.S
>> delete mode 100644 board/samsung/origen/mmc_boot.c
>> delete mode 100644 board/samsung/smdkv310/lowlevel_init.S
>> delete mode 100644 board/samsung/smdkv310/mem_setup.S
>> delete mode 100644 board/samsung/smdkv310/mmc_boot.c
>>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
--=20
Regards,
Rajeshwari Shinde
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-04-09 14:12 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-04-09 14:12 UTC (permalink / raw)
To: u-boot
always safe to call invalidate_icache_all().
So it's back to use the compiler define for ARMv7.
> The only problem I see for now is that, while ARM has a default
> icache_status(), apparently the targets that need the invalidate above
> do not have their own version of icache_status(); they'll need to
> provide one for this code to work.
And also an invalidate_icache_all(). That only exists on armv7 today.
m68k have icache_invalid() which seems to be the same.
Regards
Henrik
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-04-09 14:12 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-04-09 14:12 UTC (permalink / raw)
To: u-boot
Thanks,
Minkyu Kang.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-04-09 14:12 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-04-09 14:12 UTC (permalink / raw)
To: u-boot
"icache flush" calls icache_invalidate_all().
"dcache flush" calls flush_dcache_all().
but imho the user shouldn't really need to care for these and is why I
hooked into the go command.
I don't see much of a performance problem with a automatic full cache
flush when using the go command on platforms with incoherent caches. In
most use cases it's not very different from the bootm command which also
needs to do the same (and using a similar hooking mechanism as what I
used for go, but not saying that is a good thing)
Platforms with coherent caches likely do not need to care and can keep
the cache as-is.
And I do not think there needs to be commands for flushing specific
regions other than for testing. Region based flushing is better done by
code which knows what is needed. It's hard for users to get this right
as most times it works anyway.
Regards
Henrik
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-04-09 14:12 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-04-09 14:12 UTC (permalink / raw)
To: u-boot
active when the fec_send is called, and then no ARP message is sent.
Could you try setting #define CONFIG_ARP_TIMEOUT to some high value
(when it is set, the value is often 200mS) to check if the issue
disappears ?
Best regards,
Stefano Babic
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-04-09 14:12 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-04-09 14:12 UTC (permalink / raw)
To: u-boot
configuration and does not affects other boards but only the nitrogen. I
had merged this in u-boot-imx, but it is too late for PR. If it is not
too late, please merge it for release.
Many thanks,
Stefano
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-04-09 14:12 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-04-09 14:12 UTC (permalink / raw)
To: u-boot
for(i=3D1;i<10;i++)
do
echo "lion-0722"
done
Then, i used mkimage tool to produce a script.
Then, i load it to dram, and run it with autoscr cmd.
But failed, the log message is:
LION # fatload mmc 0:1 0 scriptcmd0722
reading scriptcmd0722
120 bytes read
LION # autoscr 0
## Executing script@00000000
Unknown command 'for(i=3D1' - try 'help'
Unknown command 'i<10' - try 'help'
Unknown command 'i++)' - try 'help'
syntax error
syntax error
... ...
Best wishes,
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-04-09 14:12 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-04-09 14:12 UTC (permalink / raw)
To: u-boot
set everything up in order to do a full non-falcon boot, and then simply
save a serialized version of the zImage/DTB/bootargs/... using a special
U-Boot command.
As such, in order to use falcon mode, we still have to solve all the
same problems that Dennis mentioned here so that the distro can set up
falcon mode, and falcon mode is just an optimization that you can use
once you've done that.
If we don't solve the problems Dennis mentioned, how would a distro be
able to automatically script the initial setup of the serialized data
that falcon mode boots?
And also, if a distro installs an updated kernel, how does it tell
U-Boot to invalidate the previously serialized data that falcon mode
uses to boot, and re-create it using the new kernel image?
So to me, falcon mode seems like a somewhat unrelated topic, and purely
an optimization.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-04-09 14:12 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-04-09 14:12 UTC (permalink / raw)
To: u-boot
instead of read status- hence added E_FSR flag on spectific
flash parts.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
---
Changes for v2:
- none
drivers/mtd/spi/spi_flash_probe.c | 14 +++++++++-----
include/spi_flash.h | 1 +
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/spi/spi_flash_probe.c b/drivers/mtd/spi/spi_flash_probe.c
index 0d005a1..acccee0 100644
--- a/drivers/mtd/spi/spi_flash_probe.c
+++ b/drivers/mtd/spi/spi_flash_probe.c
@@ -94,10 +94,10 @@ static const struct spi_flash_params spi_flash_params_table[] = {
{"N25Q128A", 0x20bb18, 0x0, 64 * 1024, 256, SECT_4K},
{"N25Q256", 0x20ba19, 0x0, 64 * 1024, 512, SECT_4K},
{"N25Q256A", 0x20bb19, 0x0, 64 * 1024, 512, SECT_4K},
- {"N25Q512", 0x20ba20, 0x0, 64 * 1024, 1024, SECT_4K},
- {"N25Q512A", 0x20bb20, 0x0, 64 * 1024, 1024, SECT_4K},
- {"N25Q1024", 0x20ba21, 0x0, 64 * 1024, 2048, SECT_4K},
- {"N25Q1024A", 0x20bb21, 0x0, 64 * 1024, 2048, SECT_4K},
+ {"N25Q512", 0x20ba20, 0x0, 64 * 1024, 1024, E_FSR | SECT_4K},
+ {"N25Q512A", 0x20bb20, 0x0, 64 * 1024, 1024, E_FSR | SECT_4K},
+ {"N25Q1024", 0x20ba21, 0x0, 64 * 1024, 2048, E_FSR | SECT_4K},
+ {"N25Q1024A", 0x20bb21, 0x0, 64 * 1024, 2048, E_FSR | SECT_4K},
#endif
#ifdef CONFIG_SPI_FLASH_SST /* SST */
{"SST25VF040B", 0xbf258d, 0x0, 64 * 1024, 8, SECT_4K | SST_WP},
@@ -186,7 +186,6 @@ struct spi_flash *spi_flash_validate_ids(struct spi_slave *spi, u8 *idcode)
flash->spi = spi;
flash->name = params->name;
- flash->poll_cmd = CMD_READ_STATUS;
/* Assign spi_flash ops */
flash->write = spi_flash_cmd_write_multi;
@@ -214,6 +213,11 @@ struct spi_flash *spi_flash_validate_ids(struct spi_slave *spi, u8 *idcode)
flash->erase_size = flash->sector_size;
}
+ /* Poll cmd seclection */
+ flash->poll_cmd = CMD_READ_STATUS;
+ if (params->flags & E_FSR)
+ flash->poll_cmd = CMD_FLAG_STATUS;
+
/* Flash powers up read-only, so clear BP# bits */
if (((params->jedec >> 16) == SPI_FLASH_CFI_MFR_ATMEL) ||
((params->jedec >> 16) == SPI_FLASH_CFI_MFR_MACRONIX) ||
diff --git a/include/spi_flash.h b/include/spi_flash.h
index 387af86..3e60fdc 100644
--- a/include/spi_flash.h
+++ b/include/spi_flash.h
@@ -25,6 +25,7 @@
/* SECT flags */
#define SECT_4K (1 << 0)
#define SECT_32K (1 << 1)
+#define E_FSR (1 << 2)
/* SST specific macros */
#ifdef CONFIG_SPI_FLASH_SST
--
1.8.3
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2013-04-09 14:12 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-04-09 14:12 UTC (permalink / raw)
To: u-boot
To keep this maintainable a PHY setup machine was implemented that can
execute commands from initialization arrays.
Signed-off-by: Dirk Eibach <dirk.eibach@gdsys.cc>
---
board/gdsys/405ep/iocon.c | 220 ++++++++++++++++++++++++++++++++++++----------
1 file changed, 172 insertions(+), 48 deletions(-)
diff --git a/board/gdsys/405ep/iocon.c b/board/gdsys/405ep/iocon.c
index 664b1e1..7a98e41 100644
--- a/board/gdsys/405ep/iocon.c
+++ b/board/gdsys/405ep/iocon.c
@@ -99,7 +99,6 @@ unsigned int mclink_fpgacount;
struct ihs_fpga *fpga_ptr[] = CONFIG_SYS_FPGA_PTR;
static int setup_88e1518(const char *bus, unsigned char addr);
-static int verify_88e1518(const char *bus, unsigned char addr);
int fpga_set_reg(u32 fpga, u16 *reg, off_t regoff, u16 data)
{
@@ -405,11 +404,7 @@ int last_stage_init(void)
if ((mux_ch == 1) && !ch0_rgmii2_present)
continue;
- if (!verify_88e1518(bb_miiphy_buses[0].name, mux_ch)) {
- printf("Fixup 88e1518 erratum on %s phy %u\n",
- bb_miiphy_buses[0].name, mux_ch);
- setup_88e1518(bb_miiphy_buses[0].name, mux_ch);
- }
+ setup_88e1518(bb_miiphy_buses[0].name, mux_ch);
}
}
@@ -434,11 +429,7 @@ int last_stage_init(void)
if (feature_carrier_speed == CARRIER_SPEED_1G) {
miiphy_register(bb_miiphy_buses[k].name,
bb_miiphy_read, bb_miiphy_write);
- if (!verify_88e1518(bb_miiphy_buses[k].name, 0)) {
- printf("Fixup 88e1518 erratum on %s\n",
- bb_miiphy_buses[k].name);
- setup_88e1518(bb_miiphy_buses[k].name, 0);
- }
+ setup_88e1518(bb_miiphy_buses[k].name, 0);
}
}
@@ -652,56 +643,189 @@ struct bb_miiphy_bus bb_miiphy_buses[] = {
int bb_miiphy_buses_num = sizeof(bb_miiphy_buses) /
sizeof(bb_miiphy_buses[0]);
+enum {
+ MIICMD_SET,
+ MIICMD_MODIFY,
+ MIICMD_VERIFY_VALUE,
+ MIICMD_WAIT_FOR_VALUE,
+};
+
+struct mii_setupcmd {
+ u8 token;
+ u8 reg;
+ u16 data;
+ u16 mask;
+ u32 timeout;
+};
+
/*
- * Workaround for erratum mentioned in 88E1518 release notes
+ * verify we are talking to a 88e1518
*/
+struct mii_setupcmd verify_88e1518[] = {
+ { MIICMD_SET, 22, 0x0000 },
+ { MIICMD_VERIFY_VALUE, 2, 0x0141, 0xffff },
+ { MIICMD_VERIFY_VALUE, 3, 0x0dd0, 0xfff0 },
+};
-static int verify_88e1518(const char *bus, unsigned char addr)
-{
- u16 phy_id1, phy_id2;
-
- if (miiphy_read(bus, addr, 2, &phy_id1) ||
- miiphy_read(bus, addr, 3, &phy_id2)) {
- printf("Error reading from the PHY addr=%02x\n", addr);
- return -EIO;
- }
+/*
+ * workaround for erratum mentioned in 88E1518 release notes
+ */
+struct mii_setupcmd fixup_88e1518[] = {
+ { MIICMD_SET, 22, 0x00ff },
+ { MIICMD_SET, 17, 0x214b },
+ { MIICMD_SET, 16, 0x2144 },
+ { MIICMD_SET, 17, 0x0c28 },
+ { MIICMD_SET, 16, 0x2146 },
+ { MIICMD_SET, 17, 0xb233 },
+ { MIICMD_SET, 16, 0x214d },
+ { MIICMD_SET, 17, 0xcc0c },
+ { MIICMD_SET, 16, 0x2159 },
+ { MIICMD_SET, 22, 0x00fb },
+ { MIICMD_SET, 7, 0xc00d },
+ { MIICMD_SET, 22, 0x0000 },
+};
- if ((phy_id1 != 0x0141) || ((phy_id2 & 0xfff0) != 0x0dd0))
- return -EINVAL;
+/*
+ * default initialization:
+ * - set RGMII receive timing to "receive clock transition when data stable"
+ * - set RGMII transmit timing to "transmit clock internally delayed"
+ * - set RGMII output impedance target to 78,8 Ohm
+ * - run output impedance calibration
+ * - set autonegotiation advertise to 1000FD only
+ */
+struct mii_setupcmd default_88e1518[] = {
+ { MIICMD_SET, 22, 0x0002 },
+ { MIICMD_MODIFY, 21, 0x0030, 0x0030 },
+ { MIICMD_MODIFY, 25, 0x0000, 0x0003 },
+ { MIICMD_MODIFY, 24, 0x8000, 0x8000 },
+ { MIICMD_WAIT_FOR_VALUE, 24, 0x4000, 0x4000, 2000 },
+ { MIICMD_SET, 22, 0x0000 },
+ { MIICMD_MODIFY, 4, 0x0000, 0x01e0 },
+ { MIICMD_MODIFY, 9, 0x0200, 0x0300 },
+};
- return 0;
-}
+/*
+ * turn off CLK125 for PHY daughterboard
+ */
+struct mii_setupcmd ch1fix_88e1518[] = {
+ { MIICMD_SET, 22, 0x0002 },
+ { MIICMD_MODIFY, 16, 0x0006, 0x0006 },
+ { MIICMD_SET, 22, 0x0000 },
+};
-struct regfix_88e1518 {
- u8 reg;
- u16 data;
-} regfix_88e1518[] = {
- { 22, 0x00ff },
- { 17, 0x214b },
- { 16, 0x2144 },
- { 17, 0x0c28 },
- { 16, 0x2146 },
- { 17, 0xb233 },
- { 16, 0x214d },
- { 17, 0xcc0c },
- { 16, 0x2159 },
- { 22, 0x00fb },
- { 7, 0xc00d },
- { 22, 0x0000 },
+/*
+ * perform copper software reset
+ */
+struct mii_setupcmd swreset_88e1518[] = {
+ { MIICMD_SET, 22, 0x0000 },
+ { MIICMD_MODIFY, 0, 0x8000, 0x8000 },
+ { MIICMD_WAIT_FOR_VALUE, 0, 0x0000, 0x8000, 2000 },
};
-static int setup_88e1518(const char *bus, unsigned char addr)
+static int process_setupcmd(const char *bus, unsigned char addr,
+ struct mii_setupcmd *setupcmd)
{
+ int res;
+ u8 reg = setupcmd->reg;
+ u16 data = setupcmd->data;
+ u16 mask = setupcmd->mask;
+ u32 timeout = setupcmd->timeout;
+ u16 orig_data;
+ unsigned long start;
+
+ debug("mii %s:%u reg %2u ", bus, addr, reg);
+
+ switch (setupcmd->token) {
+ case MIICMD_MODIFY:
+ res = miiphy_read(bus, addr, reg, &orig_data);
+ if (res)
+ break;
+ debug("is %04x. (value %04x mask %04x) ", orig_data, data,
+ mask);
+ data = (orig_data & ~mask) | (data & mask);
+ case MIICMD_SET:
+ debug("=> %04x\n", data);
+ res = miiphy_write(bus, addr, reg, data);
+ break;
+ case MIICMD_VERIFY_VALUE:
+ res = miiphy_read(bus, addr, reg, &orig_data);
+ if (res)
+ break;
+ if ((orig_data & mask) != (data & mask))
+ res = -1;
+ debug("(value %04x mask %04x) == %04x? %s\n", data, mask,
+ orig_data, res ? "FAIL" : "PASS");
+ break;
+ case MIICMD_WAIT_FOR_VALUE:
+ res = -1;
+ start = get_timer(0);
+ while ((res != 0) && (get_timer(start) < timeout)) {
+ res = miiphy_read(bus, addr, reg, &orig_data);
+ if (res)
+ continue;
+ if ((orig_data & mask) != (data & mask))
+ res = -1;
+ }
+ debug("(value %04x mask %04x) == %04x? %s after %lu ms\n", data,
+ mask, orig_data, res ? "FAIL" : "PASS",
+ get_timer(start));
+ break;
+ default:
+ res = -1;
+ break;
+ }
+
+ return res;
+}
+
+static int process_setup(const char *bus, unsigned char addr,
+ struct mii_setupcmd *setupcmd, unsigned int count)
+{
+ int res = 0;
unsigned int k;
- for (k = 0; k < ARRAY_SIZE(regfix_88e1518); ++k) {
- if (miiphy_write(bus, addr,
- regfix_88e1518[k].reg,
- regfix_88e1518[k].data)) {
- printf("Error writing to the PHY addr=%02x\n", addr);
- return -1;
+ for (k = 0; k < count; ++k) {
+ res = process_setupcmd(bus, addr, &setupcmd[k]);
+ if (res) {
+ printf("mii cmd %u on bus %s addr %u failed, aborting setup",
+ setupcmd[k].token, bus, addr);
+ break;
}
}
+ return res;
+}
+
+static int setup_88e1518(const char *bus, unsigned char addr)
+{
+ int res;
+
+ res = process_setup(bus, addr,
+ verify_88e1518, ARRAY_SIZE(verify_88e1518));
+ if (res)
+ return res;
+
+ res = process_setup(bus, addr,
+ fixup_88e1518, ARRAY_SIZE(fixup_88e1518));
+ if (res)
+ return res;
+
+ res = process_setup(bus, addr,
+ default_88e1518, ARRAY_SIZE(default_88e1518));
+ if (res)
+ return res;
+
+ if (addr) {
+ res = process_setup(bus, addr,
+ ch1fix_88e1518, ARRAY_SIZE(ch1fix_88e1518));
+ if (res)
+ return res;
+ }
+
+ res = process_setup(bus, addr,
+ swreset_88e1518, ARRAY_SIZE(swreset_88e1518));
+ if (res)
+ return res;
+
return 0;
}
--
1.8.3
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2013-04-09 14:12 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-04-09 14:12 UTC (permalink / raw)
To: u-boot
adhere to the formatting and ordering described in the file
header.
The reformatting script tools/reformat.py is provided to
facilitate keeping boards.cfg formatted and ordered.
Signed-off-by: Albert ARIBAUD <albert.u.boot@aribaud.net>
---
This patch is a squash of the RFC v2 patch previously posted,
plus removal of the tools/merge.py and MAINTAINERS files which
were overlooked so far.
MAINTAINERS | 1391 ----------------------------
MAKEALL | 20 +-
Makefile | 2 +-
boards.cfg | 2312 +++++++++++++++++++++++------------------------
mkconfig | 31 +-
tools/buildman/board.py | 2 +-
tools/reformat.py | 132 +++
7 files changed, 1316 insertions(+), 2574 deletions(-)
delete mode 100644 MAINTAINERS
create mode 100755 tools/reformat.py
diff --git a/MAINTAINERS b/MAINTAINERS
deleted file mode 100644
index 081cf96..0000000
--- a/MAINTAINERS
+++ /dev/null
@@ -1,1391 +0,0 @@
-#########################################################################
-# #
-# Regular Maintainers for U-Boot board support: #
-# #
-# For any board without permanent maintainer, please contact #
-# Wolfgang Denk <wd@denx.de> #
-# and Cc: the <u-boot@lists.denx.de> mailing list. #
-# #
-# Note: lists sorted by Maintainer Name #
-# Note: These are the maintainers for specific *boards*. The #
-# custodians for general architectures and subsystems can #
-# be found here -- http://www.denx.de/wiki/U-Boot/Custodians #
-# #
-#########################################################################
-
-
-#########################################################################
-# PowerPC Systems: #
-# #
-# Maintainer Name, Email Address #
-# Board CPU #
-#########################################################################
-
-Poonam Aggrwal <poonam.aggrwal@freescale.com>
-
- P2020RDB P2020
-
- BSC9131RDB BSC9131
-
-Naveen Burmi <NaveenBurmi@freescale.com>
-
- BSC9132QDS BSC9132
-
-Greg Allen <gallen@arlut.utexas.edu>
-
- UTX8245 MPC8245
-
-Pantelis Antoniou <panto@intracom.gr>
-
- NETVIA MPC8xx
-
-Reinhard Arlt <reinhard.arlt@esd-electronics.com>
-
- cpci5200 MPC5200
- mecp5123 MPC5121
- mecp5200 MPC5200
- pf5200 MPC5200
-
- caddy2 MPC8349
- vme8349 MPC8349
-
- CPCI750 PPC750FX/GX
-
-Peter Barada <peter.barada@logicpd.com>
-
- omap3_logic ARM ARMV7 (Logic OMAP35xx/DM37xx)
-
-Yuli Barcohen <yuli@arabellasw.com>
-
- Adder MPC87x/MPC852T
- ep8248 MPC8248
- ISPAN MPC8260
- MPC8260ADS MPC826x/MPC827x/MPC8280
- Rattler MPC8248
- ZPC1900 MPC8265
-
-Michael Barkowski <michael.barkowski@freescale.com>
-
- MPC8323ERDB MPC8323
-
-Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com>
-
- sacsng MPC8260
-
-Oliver Brown <obrown@adventnetworks.com>
-
- gw8260 MPC8260
-
-Holger Brunck <holger.brunck@keymile.com>
-
- kmeter1 MPC8360
- kmcoge5ne MPC8360
- mgcoge MPC8247
- mgcoge3ne MPC8247
- suvd3 MPC8321
- tuge1 MPC8321
- tuxx1 MPC8321
-
-Conn Clark <clark@esteem.com>
-
- ESTEEM192E MPC8xx
-
-Jason Cooper <u-boot@lakedaemon.net>
-
- dreamplug ARM926EJS (Kirkwood SoC)
-
-Joe D'Abbraccio <ljd015@freescale.com>
-
- MPC837xERDB MPC837x
-
-K??ri Dav????sson <kd@flaga.is>
-
- FLAGADM MPC823
-
-Torsten Demke <torsten.demke@fci.com>
-
- eXalion MPC824x
-
-Wolfgang Denk <wd@denx.de>
-
- IceCube_5200 MPC5200
-
- ARIA MPC5121e
-
- FPS850L MPC850
- FPS860L MPC860
- ICU862 MPC862
- IP860 MPC860
- IVML24 MPC860
- IVML24_128 MPC860
- IVML24_256 MPC860
- IVMS8 MPC860
- IVMS8_128 MPC860
- IVMS8_256 MPC860
- LWMON MPC823
- R360MPI MPC823
- RRvision MPC823
- SM850 MPC850
- SPD823TS MPC823
- TQM823L MPC823
- TQM823L_LCD MPC823
- TQM850L MPC850
- TQM855L MPC855
- TQM860L MPC860
- TQM860L_FEC MPC860
- hermes MPC860
- lwmon MPC823
-
- CU824 MPC8240
- Sandpoint8240 MPC8240
-
- ATC MPC8250
- PM825 MPC8250
-
- TQM8255 MPC8255
-
- CPU86 MPC8260
- PM826 MPC8260
- TQM8260 MPC8260
-
- P3G4 MPC7410
-
-Phil Edworthy <phil.edworthy@renesas.com>
-
- rsk7264 SH7264
-
-egnite GmbH <info@egnite.de>
-
- ethernut5 ARM926EJS (AT91SAM9XE SoC)
-
-Dirk Eibach <eibach@gdsys.de>
-
- controlcenterd P1022
- devconcenter PPC460EX
- dlvision PPC405EP
- dlvision-10g PPC405EP
- gdppc440etx PPC440EP/GR
- intip PPC460EX
- io PPC405EP
- io64 PPC405EX
- iocon PPC405EP
- neo PPC405EP
-
-Dave Ellis <DGE@sixnetio.com>
-
- SXNI855T MPC8xx
-
-Thomas Frieden <ThomasF@hyperion-entertainment.com>
-
- AmigaOneG3SE MPC7xx
-
-Matthias Fuchs <matthias.fuchs@esd-electronics.com>
-
- APC405 PPC405GP
- AR405 PPC405GP
- ASH405 PPC405EP
- CANBT PPC405CR
- CPCI2DP PPC405GP
- CPCI405 PPC405GP
- CPCI4052 PPC405GP
- CPCI405AB PPC405GP
- CPCI405DT PPC405GP
- CPCIISER4 PPC405GP
- DP405 PPC405EP
- DU405 PPC405GP
- DU440 PPC440EPx
- G2000 PPC405EP
- HH405 PPC405EP
- HUB405 PPC405EP
- OCRTC PPC405GP
- ORSG PPC405GP
- PCI405 PPC405GP
- PLU405 PPC405EP
- PMC405 PPC405GP
- PMC405DE PPC405EP
- PMC440 PPC440EPx
- VOH405 PPC405EP
- VOM405 PPC405EP
- WUH405 PPC405EP
- CMS700 PPC405EP
-
-Siddarth Gore <gores@marvell.com>
-
- guruplug ARM926EJS (Kirkwood SoC)
-
-Paul Gortmaker <paul.gortmaker@windriver.com>
-
- sbc8349 MPC8349
- sbc8548 MPC8548
- sbc8641d MPC8641D
-
-Frank Gottschling <fgottschling@eltec.de>
-
- MHPC MPC8xx
-
-Wolfgang Grandegger <wg@denx.de>
-
- ipek01 MPC5200
-
- PN62 MPC8240
- IPHASE4539 MPC8260
-
-Anatolij Gustschin <agust@denx.de>
-
- ac14xx MPC5121e
- O2D MPC5200
- O2D300 MPC5200
- O2DNT2 MPC5200
- O2I MPC5200
- O2MNT MPC5200
- O3DNT MPC5200
-
-Rob Herring <rob.herring@calxeda.com>
-
- highbank highbank
-
-Klaus Heydeck <heydeck@kieback-peter.de>
-
- KUP4K MPC855
- KUP4X MPC859
-
-Gabriel Huau <contact@huau-gabriel.fr>
-
- mini2440 s3c2440
-
-Gary Jennejohn <garyj@denx.de>
-
- quad100hd PPC405EP
-
-Murray Jensen <Murray.Jensen@csiro.au>
-
- cogent_mpc8xx MPC8xx
-
- cogent_mpc8260 MPC8260
- hymod MPC8260
-
-Larry Johnson <lrj@acm.org>
-
- korat PPC440EPx
-
-Feng Kan <fkan@amcc.com>
-
- redwood PPC4xx
-
-Brad Kemp <Brad.Kemp@seranoa.com>
-
- ppmc8260 MPC8260
-
-Sangmoon Kim <dogoil@etinsys.com>
-
- debris MPC8245
- KVME080 MPC8245
-
-The LEOX team <team@leox.org>
-
- ELPT860 MPC860T
-
-Guennadi Liakhovetski <g.liakhovetski@gmx.de>
-
- linkstation MPC8241
-
-Dave Liu <daveliu@freescale.com>
-
- MPC8315ERDB MPC8315
- MPC832XEMDS MPC832x
- MPC8360EMDS MPC8360
- MPC837XEMDS MPC837x
-
-Nye Liu <nyet@zumanetworks.com>
-
- ZUMA MPC7xx_74xx
-
-Kumar Gala <kumar.gala@freescale.com>
-
- MPC8540ADS MPC8540
- MPC8560ADS MPC8560
- MPC8541CDS MPC8541
- MPC8555CDS MPC8555
-
- MPC8641HPCN MPC8641D
-
-Ron Madrid <info@sheldoninst.com>
-
- SIMPC8313 MPC8313
-
-Dan Malek <dan@embeddedalley.com>
-
- stxgp3 MPC85xx
- stxssa MPC85xx
- stxxtc MPC8xx
-
-Ryan Mallon <ryan@bluewatersys.com>
-
- snapper9260 ARM926EJS (AT91SAM9260 SoC)
- snapper9g20 ARM926EJS (AT91SAM9G20 SoC)
-
-Andrea "llandre" Marson <andrea.marson@dave-tech.it>
-
- PPChameleonEVB PPC405EP
-
-Tirumala Marri <tmarri@apm.com>
-
- bluestone APM821XX
-
-Reinhard Meyer <reinhard.meyer@emk-elektronik.de>
-
- TOP860 MPC860T
- TOP5200 MPC5200
- TOP9000 ARM926EJS (AT91SAM9xxx SoC)
-
-Kyle Moffett <Kyle.D.Moffett@boeing.com>
-
- HWW1U1A P2020
-
-Tolunay Orkun <torkun@nextio.com>
-
- csb272 PPC405GP
- csb472 PPC405GP
-
-John Otken <jotken@softadvances.com>
-
- luan PPC440SP
- taihu PPC405EP
-
-Keith Outwater <Keith_Outwater@mvis.com>
-
- GEN860T MPC860T
- GEN860T_SC MPC860T
-
-Frank Panno <fpanno@delphintech.com>
-
- ep8260 MPC8260
-
-Chan-Taek Park <c-park@ti.com>
-
- tnetv107x_evm tnetv107x
-
-Denis Peter <d.peter@mpl.ch>
-
- MIP405 PPC4xx
- PIP405 PPC4xx
-
-Werner Pfister <Pfister_Werner@intercontrol.de>
- digsy_mtc mpc5200
- digsy_mtc_rev5 mpc5200
-
-Kim Phillips <kim.phillips@freescale.com>
-
- MPC8349EMDS MPC8349
-
-Sergei Poselenov <sposelenov@emcraft.com>
-
- a4m072 MPC5200
-
-Sudhakar Rajashekhara <sudhakar.raj@ti.com>
-
- da850evm ARM926EJS (DA850/OMAP-L138)
-
-Ricardo Ribalda <ricardo.ribalda@uam.es>
-
- ml507 PPC440x5
- v5fx30teval PPC440x5
- xilinx-ppc405-generic PPC405
- xilinx-ppc440-generic PPC440x5
-
-Stefan Roese <sr@denx.de>
-
- a3m071 MPC5200
- a4m2k MPC5200
-
- P3M7448 MPC7448
-
- uc100 MPC857
-
- acadia PPC405EZ
- alpr PPC440GX
- bamboo PPC440EP
- bunbinga PPC405EP
- canyonlands PPC460EX
- ebony PPC440GP
- glacier PPC460GT
- haleakala PPC405EXr
- icon PPC440SPe
- katmai PPC440SPe
- kilauea PPC405EX
- lwmon5 PPC440EPx
- makalu PPC405EX
- ocotea PPC440GX
- p3p440 PPC440GP
- pcs440ep PPC440EP
- rainier PPC440GRx
- sequoia PPC440EPx
- sycamore PPC405GPr
- t3corp PPC460GT
- taishan PPC440GX
- walnut PPC405GP
- yellowstone PPC440GR
- yosemite PPC440EP
- zeus PPC405EP
-
- P3M750 PPC750FX/GX/GL
-
-Yusdi Santoso <yusdi_santoso@adaptec.com>
-
- HIDDEN_DRAGON MPC8241/MPC8245
-
-Travis Sawyer (travis.sawyer at sandburst.com>
-
- KAREF PPC440GX
- METROBOX PPC440GX
-
-Georg Schardt <schardt@team-ctech.de>
-
- fx12mm PPC405
-
-Heiko Schocher <hs@denx.de>
-
- cam_enc_4xx davinci/ARM926EJS
- charon MPC5200
- ids8247 MPC8247
- jupiter MPC5200
- kmsupx5 MPC8321
- mucmc52 MPC5200
- muas3001 MPC8270
- municse MPC5200
- sc3 PPC405GP
- uc101 MPC5200
- ve8313 MPC8313
-
-Andre Schwarz <andre.schwarz@matrix-vision.de>
-
- mergerbox MPC8377
- mvbc_p MPC5200
- mvblm7 MPC8343
- mvsmr MPC5200
-
-Jon Smirl <jonsmirl@gmail.com>
-
- pcm030 MPC5200
-
-Ira W. Snyder <iws@ovro.caltech.edu>
-
- P2020COME P2020
-
-Timur Tabi <timur@freescale.com>
-
- MPC8349E-mITX MPC8349
- MPC8349E-mITX-GP MPC8349
- P1022DS P1022
-
-Erik Theisen <etheisen@mindspring.com>
-
- W7OLMC PPC4xx
- W7OLMG PPC4xx
-
-Jim Thompson <jim@musenki.com>
-
- MUSENKI MPC8245/8241
- Sandpoint8245 MPC8245
-
-Rune Torgersen <runet@innovsys.com>
-
- MPC8266ADS MPC8266
-
-Peter Tyser <ptyser@xes-inc.com>
-
- xpedite1000 PPC440GX
- xpedite5170 MPC8640
- xpedite5200 MPC8548
- xpedite5370 MPC8572
- xpedite5500 P2020
-
-David Updegraff <dave@cray.com>
-
- CRAYL1 PPC4xx
-
-Anton Vorontsov <avorontsov@ru.mvista.com>
-
- MPC8360ERDK MPC8360
-
-Josef Wagner <Wagner@Microsys.de>
-
- CPC45 MPC8245
- PM520 MPC5200
-
-Michael Weiss <michael.weiss@ifm.com>
-
- PDM360NG MPC5121e
-
-Stephen Williams <steve@icarus.com>
-
- JSE PPC405GPr
-
-Ilya Yanok <yanok@emcraft.com>
-
- mpc8308_p1m MPC8308
- MPC8308RDB MPC8308
-
-Roy Zang <tie-fei.zang@freescale.com>
-
- mpc7448hpc2 MPC7448
- P1023RDS P1023
-
-John Zhan <zhanz@sinovee.com>
-
- svm_sc8xx MPC8xx
-
-Detlev Zundel <dzu@denx.de>
-
- inka4x0 MPC5200
-
--------------------------------------------------------------------------
-
-Unknown / orphaned boards:
-
- ADS860 MPC8xx
- FADS823 MPC8xx
- FADS850SAR MPC8xx
- FADS860T MPC8xx
- GENIETV MPC8xx
- MBX MPC8xx
- MBX860T MPC8xx
- NX823 MPC8xx
- RPXClassic MPC8xx
- RPXlite MPC8xx
-
- MOUSSE MPC824x
-
- RPXsuper MPC8260
- rsdproto MPC8260
-
- EVB64260 MPC7xx_74xx
- EVB64260_750CX MPC750CX [Eran Man <eran@nbase.co.il>]
-
- versatile ARM926EJ-S
-
-#########################################################################
-# ARM Systems: #
-# #
-# Maintainer Name, Email Address #
-# Board CPU #
-#########################################################################
-
-Albert ARIBAUD <albert.u.boot@aribaud.net>
-
- edminiv2 ARM926EJS (Orion5x SoC)
-
-Raphael Assenat <raph@8d.com>
-
- eco5pk ARM ARMV7 (AM35x SoC)
-
-Stefano Babic <sbabic@denx.de>
-
- ea20 davinci
- flea3 i.MX35
- mt_ventoux omap3
- mx35pdk i.MX35
- mx51evk i.MX51
- polaris xscale/pxa
- trizepsiv xscale/pxa
- twister omap3
- vision2 i.MX51
- woodburn i.MX35
-
-Lukasz Dalek <luk0104@gmail.com>
-
- h2200 xscale/pxa
-
-Jason Liu <r64343@freescale.com>
-
- mx53evk i.MX53
- mx53loco i.MX53
- mx6qarm2 i.MX6Q
- mx6qsabrelite i.MX6Q
-
-Enric Balletbo i Serra <eballetbo@iseebcn.com>
-
- igep0020 ARM ARMV7 (OMAP3xx SoC)
- igep0030 ARM ARMV7 (OMAP3xx SoC)
- igep0032 ARM ARMV7 (OMAP3xx SoC)
- igep0033 ARM ARMV7 (AM33xx Soc)
-
-Eric Benard <eric@eukrea.com>
-
- cpuat91 ARM920T
- cpu9260 ARM926EJS (AT91SAM9260 SoC)
- cpu9G20 ARM926EJS (AT91SAM9G20 SoC)
-
-Ajay Bhargav <ajay.bhargav@einfochips.com>
-
- gplugd ARM926EJS (ARMADA100 88AP168 SoC)
-
-Rishi Bhattacharya <rishi@ti.com>
-
- omap5912osk ARM926EJS
-
-Andreas Bie??mann <andreas.devel@gmail.com>
-
- at91rm9200ek at91rm9200
-
-Cliff Brake <cliff.brake@gmail.com>
-
- pxa255_idp xscale/pxa
-
-Rick Bronson <rick@efn.org>
-
- AT91RM9200DK at91rm9200
-
-Luca Ceresoli <luca.ceresoli@comelit.it>
-
- dig297 ARM ARMV7 (OMAP3530 SoC)
-
-Po-Yu Chuang <ratbert@faraday-tech.com>
-
- a320evb FA526 (ARM920T-like) (a320 SoC)
-
-Eric Cooper <ecc@cmu.edu>
-
- dockstar ARM926EJS (Kirkwood SoC)
-
-Wolfgang Denk <wd@denx.de>
- imx27lite i.MX27
- qong i.MX31
-
-Mike Dunn <mikedunn@newsguy.com>
- palmtreo680 pxa270
-
-Kristoffer Ericson <kristoffer.ericson@gmail.com>
-
- jornada SA1110
-
-Fabio Estevam <fabio.estevam@freescale.com>
-
- mx25pdk i.MX25
- mx28evk i.MX28
- mx31pdk i.MX31
- mx53ard i.MX53
- mx53smd i.MX53
- mx6sabresd i.MX6Q/DL
- mx6qsabreauto i.MX6Q
- wandboard i.MX6DL/S/Q
- mx6slevk i.MX6SL
-
-Daniel Gorsulowski <daniel.gorsulowski@esd.eu>
-
- meesc ARM926EJS (AT91SAM9263 SoC)
- otc570 ARM926EJS (AT91SAM9263 SoC)
-
-Bo Shen<voice.shen@atmel.com>
- at91sam9g10ek ARM926EJS (AT91SAM9G10 SoC)
- at91sam9m10g45ek ARM926EJS (AT91SAM9G45 SoC)
-
-Simon Guinot <simon.guinot@sequanux.org>
-
- inetspace_v2 ARM926EJS (Kirkwood SoC)
- netspace_v2 ARM926EJS (Kirkwood SoC)
- netspace_max_v2 ARM926EJS (Kirkwood SoC)
- net2big_v2 ARM926EJS (Kirkwood SoC)
-
-Igor Grinberg <grinberg@compulab.co.il>
-
- cm_t35 ARM ARMV7 (OMAP3xx Soc)
-
-Stefan Herbrechtsmeier <stefan@code.herbrechtsmeier.net>
-
- dns325 ARM926EJS (Kirkwood SoC)
-
-Lauri Hintsala <lauri.hintsala@bluegiga.com>
-
- apx4devkit i.MX28
-
-Vaibhav Hiremath <hvaibhav@ti.com>
-
- am3517_evm ARM ARMV7 (AM35x SoC)
-
-Markus Hubig <mhubig@imko.de>
-
- STAMP9G20 ARM926EJS
-
-Grazvydas Ignotas <notasas@gmail.com>
-
- omap3_pandora ARM ARMV7 (OMAP3xx SoC)
-
-Ilko Iliev <iliev@ronetix.at>
-
- PM9261 AT91SAM9261
- PM9263 AT91SAM9263
- PM9G45 ARM926EJS (AT91SAM9G45 SoC)
-
-Michael Jones <michael.jones@matrix-vision.de>
-
- omap3_mvblx ARM ARMV7 (OMAP3xx SoC)
-
-Matthias Kaehlcke <matthias@kaehlcke.net>
- edb9301 ARM920T (EP9301)
- edb9302 ARM920T (EP9302)
- edb9302a ARM920T (EP9302)
- edb9307 ARM920T (EP9307)
- edb9307a ARM920T (EP9307)
- edb9312 ARM920T (EP9312)
- edb9315 ARM920T (EP9315)
- edb9315a ARM920T (EP9315)
-
-Nishant Kamat <nskamat@ti.com>
-
- omap1610h2 ARM926EJS
-
-Minkyu Kang <mk7.kang@samsung.com>
-
- SMDKC100 ARM ARMV7 (S5PC100 SoC)
- s5p_goni ARM ARMV7 (S5PC110 SoC)
- s5pc210_universal ARM ARMV7 (EXYNOS4210 SoC)
-
-Chander Kashyap <k.chander@samsung.com>
-
- origen ARM ARMV7 (EXYNOS4210 SoC)
- SMDKV310 ARM ARMV7 (EXYNOS4210 SoC)
- SMDK5250 ARM ARMV7 (EXYNOS5250 SoC)
-
-Lukasz Majewski <l.majewski@samsung.com>
-
- trats ARM ARMV7 (EXYNOS4210 SoC)
-
-Torsten Koschorrek <koschorrek@synertronixx.de>
- scb9328 ARM920T (i.MXL)
-
-Sergey Kubushyn <ksi@koi8.net>
-
- DV-EVM ARM926EJS
- SONATA ARM926EJS
- SCHMOOGIE ARM926EJS
-
-Vipin Kumar <vipin.kumar@st.com>
-
- spear300 ARM926EJS (spear300 Soc)
- spear310 ARM926EJS (spear310 Soc)
- spear320 ARM926EJS (spear320 Soc)
- spear600 ARM926EJS (spear600 Soc)
-
-Sergey Lapin <slapin@ossfans.org>
-
- afeb9260 ARM926EJS (AT91SAM9260 SoC)
-
-Valentin Longchamp <valentin.longchamp@keymile.com>
-
- km_kirkwood ARM926EJS (Kirkwood SoC)
- kmnusa ARM926EJS (Kirkwood SoC)
- mgcoge3un ARM926EJS (Kirkwood SoC)
- kmcoge5un ARM926EJS (Kirkwood SoC)
- portl2 ARM926EJS (Kirkwood SoC)
-
-Nishanth Menon <nm@ti.com>
-
- omap3_sdp3430 ARM ARMV7 (OMAP3xx SoC)
- omap3_zoom1 ARM ARMV7 (OMAP3xx SoC)
-
-David M??ller <d.mueller@elsoft.ch>
-
- smdk2410 ARM920T
- VCMA9 ARM920T
-
-Eric Millbrandt <emillbrandt@dekaresearch.com>
-
- galaxy5200 mpc5200
-
-Nagendra T S <nagendra@mistralsolutions.com>
-
- am3517_crane ARM ARMV7 (AM35x SoC)
-
-Dinh Nguyen <dinguyen@altera.com>
-Chin Liang See <clsee@altera.com>
-
- socfpga socfpga_cyclone5
-
-Sandeep Paulraj <s-paulraj@ti.com>
-
- davinci_dm355evm ARM926EJS
- davinci_dm355leopard ARM926EJS
- davinci_dm365evm ARM926EJS
- davinci_dm6467evm ARM926EJS
-
-Helmut Raiger <helmut.raiger@hale.at>
-
- tt01 i.MX31
-
-Linus Walleij <linus.walleij@linaro.org>
- integratorap various
- integratorcp various
-
-Luka Perkov <luka@openwrt.org>
-
- ib62x0 ARM926EJS
- iconnect ARM926EJS
-
-Dave Peverley <dpeverley@mpc-data.co.uk>
-
- omap730p2 ARM926EJS
-
-Lars Poeschel <poeschel@lemonage.de>
- pcm051 ARM ARMV7 (AM33xx Soc)
-
-Mathieu Poirier <mathieu.poirier@linaro.org>
-
- snowball ARM ARMV7 (u8500 SoC)
-
-Stelian Pop <stelian@popies.net>
-
- at91sam9260ek ARM926EJS (AT91SAM9260 SoC)
- at91sam9261ek ARM926EJS (AT91SAM9261 SoC)
- at91sam9263ek ARM926EJS (AT91SAM9263 SoC)
- at91sam9rlek ARM926EJS (AT91SAM9RL SoC)
-
-Matt Porter <mporter@ti.com>
-
- ti814x_evm ARM ARMV7 (TI814x Soc)
-
-Dave Purdy <david.c.purdy@gmail.com>
-
- pogo_e02 ARM926EJS (Kirkwood SoC)
-
-Sricharan R <r.sricharan@ti.com>
-
- omap4_panda ARM ARMV7 (OMAP4xx SoC)
- omap4_sdp4430 ARM ARMV7 (OMAP4xx SoC)
- omap5_evm ARM ARMV7 (OMAP5xx Soc)
-
-Suriyan Ramasami <suriyan.r@gmail.com>
-
- goflexhome ARM926EJS (Kirkwood SoC)
-
-Thierry Reding <thierry.reding@avionic-design.de>
-
- plutux Tegra20 (ARM7 & A9 Dual Core)
- medcom-wide Tegra20 (ARM7 & A9 Dual Core)
- tec Tegra20 (ARM7 & A9 Dual Core)
-
-Christian Riesch <christian.riesch@omicron.at>
-Manfred Rudigier <manfred.rudigier@omicron.at>
-
- calimain ARM926EJS (AM1808 SoC)
-
-Tom Rini <trini@ti.com>
-
- am335x_evm ARM ARMV7 (AM33xx Soc)
- omap3_beagle ARM ARMV7 (OMAP3xx SoC)
- omap3_evm ARM ARMV7 (OMAP3xx SoC)
-
-Tom Rix <Tom.Rix@windriver.com>
-
- omap3_zoom2 ARM ARMV7 (OMAP3xx SoC)
-
-John Rigby <jcrigby@gmail.com>
-
- tx25 i.MX25
-
-Stefan Roese <sr@denx.de>
-
- x600 ARM926EJS (spear600 Soc)
-
- titanium i.MX6Q
-
- pdnb3 xscale/ixp
- scpu xscale/ixp
-
-Alessandro Rubini <rubini@unipv.it>
-Nomadik Linux Team <STN_WMM_nomadik_linux@list.st.com>
-
- nhk8815 ARM926EJS (Nomadik 8815 Soc)
-
-Steve Sakoman <sakoman@gmail.com>
-
- omap3_overo ARM ARMV7 (OMAP3xx SoC)
-
-Leo Sartre <lsartre@adeneo-embedded.com>
-
- cgtqmx6qeval i.MX6Q
-
-Jens Scharsig <esw@bus-elektronik.de>
-
- eb_cpux9k2 ARM920T (AT91RM9200 SoC)
- vl_ma2sc ARM926EJS (AT91SAM9263 SoC)
-
-Heiko Schocher <hs@denx.de>
-
- enbw_cmc ARM926EJS (AM1808 SoC)
- magnesium i.MX27
-
-Michael Schwingen <michael@schwingen.org>
-
- actux1 xscale/ixp
- actux2 xscale/ixp
- actux3 xscale/ixp
- actux4 xscale/ixp
- dvlhost xscale/ixp
-
-Matt Sealey <matt@genesi-usa.com>
-
- efikamx i.MX51
- efikasb i.MX51
-
-Bo Shen <voice.shen@atmel.com>
- at91sam9x5ek ARM926EJS (AT91SAM9G15,G25,G35,X25,X35 SoC)
- sama5d3xek ARMV7 (SAMA5D31, D33, D34, D35 SoC)
-
-Rajeshwari Shinde <rajeshwari.s@samsung.com>
-
- snow ARM ARMV7 (EXYNOS5250 SoC)
-
-Michal Simek <monstr@monstr.eu>
-
- zynq ARM ARMV7 (Zynq SoC)
-
-Lucas Stach <dev@lynxeye.de>
-
- colibri_t20_iris Tegra20 (ARM7 & A9 Dual Core)
-
-Nick Thompson <nick.thompson@gefanuc.com>
-
- da830evm ARM926EJS (DA830/OMAP-L137)
-
-Albin Tonnerre <albin.tonnerre@free-electrons.com>
-
- sbc35_a9g20 ARM926EJS (AT91SAM9G20 SoC)
- tny_a9260 ARM926EJS (AT91SAM9260 SoC)
- tny_a9g20 ARM926EJS (AT91SAM9G20 SoC)
-
-Greg Ungerer <greg.ungerer@opengear.com>
-
- cm4008 ks8695p
- cm4116 ks8695p
- cm4148 ks8695p
-
-Marek Vasut <marek.vasut@gmail.com>
-
- balloon3 xscale/pxa
- colibri_pxa270 xscale/pxa
- palmld xscale/pxa
- palmtc xscale/pxa
- vpac270 xscale/pxa
- zipitz2 xscale/pxa
- mx23_olinuxino i.MX23
- m28evk i.MX28
- sc_sps_1 i.MX28
- m53evk i.MX53
-
-Hugo Villeneuve <hugo.villeneuve@lyrtech.com>
-
- SFFSDR ARM926EJS
-
-Lokesh Vutla <lokeshvutla@ti.com>
-
- dra7xx_evm ARM ARMV7 (DRA7xx Soc)
-
-Matt Waddel <matt.waddel@linaro.org>
-
- vexpress_ca9x4 ARM ARMV7 (Quad Core)
- vexpress_ca5x2 ARM ARMV7 (Dual Core)
-
-Otavio Salvador <otavio@ossystems.com.br>
-
- mx23evk i.MX23
-
-Prafulla Wadaskar <prafulla@marvell.com>
-
- aspenite ARM926EJS (ARMADA100 88AP168 SoC)
- mv88f6281gtw_ge ARM926EJS (Kirkwood SoC)
- openrd_base ARM926EJS (Kirkwood SoC)
- rd6281a ARM926EJS (Kirkwood SoC)
- sheevaplug ARM926EJS (Kirkwood SoC)
-
-Michael Walle <michael@walle.cc>
-
- lschlv2 ARM926EJS (Kirkwood SoC)
- lsxhl ARM926EJS (Kirkwood SoC)
-
-Tom Warren <twarren@nvidia.com>
-
- harmony Tegra20 (ARM7 & A9 Dual Core)
- seaboard Tegra20 (ARM7 & A9 Dual Core)
- cardhu Tegra30 (ARM7 & A9 Quad Core)
- dalmore Tegra114 (ARM7 & A15 Quad Core)
-
-Tom Warren <twarren@nvidia.com>
-Stephen Warren <swarren@nvidia.com>
-
- ventana Tegra20 (ARM7 & A9 Dual Core)
- paz00 Tegra20 (ARM7 & A9 Dual Core)
- trimslice Tegra20 (ARM7 & A9 Dual Core)
- whistler Tegra20 (ARM7 & A9 Dual Core)
- beaver Tegra30 (ARM7 & A9 Quad Core)
-
-Stephen Warren <swarren@wwwdotorg.org>
-
- rpi_b BCM2835 (ARM1176)
-
-Thomas Weber <weber@corscience.de>
-
- devkit8000 ARM ARMV7 (OMAP3530 SoC)
- tricorder ARM ARMV7 (OMAP3503 SoC)
-
-Lei Wen <leiwen@marvell.com>
-
- dkb ARM926EJS (PANTHEON 88AP920 SOC)
-
-Matthias Weisser <weisserm@arcor.de>
-
- jadecpu ARM926EJS (MB86R01 SoC)
- zmx25 ARM926EJS (imx25 SoC)
-
-Josh Wu <josh.wu@atmel.com>
- at91sam9n12ek ARM926EJS (AT91SAM9N12 SoC)
-
-Ilya Yanok <yanok@emcraft.com>
-
- mcx ARM ARMV7 (AM35x SoC)
-
-Syed Mohammed Khasim <sm.khasim@gmail.com>
-Sughosh Ganu <urwithsughosh@gmail.com>
-
- hawkboard ARM926EJS (OMAP-L138)
-
-Vladimir Zapolskiy <vz@mleia.com>
-
- devkit3250 lpc32xx
-
-Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
-Tetsuyuki Kobayashi <koba@kmckk.co.jp>
-
- kzm9g SH73A0 (RMOBILE SoC)
-
-Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
-
- armadillo-800eva R8A7740 (RMOBILE SoC)
-
-Pali Roh??r <pali.rohar@gmail.com>
-
- nokia_rx51 ARM ARMV7 (OMAP34xx SoC)
-
-Eric Nelson <eric.nelson@boundarydevices.com>
- nitrogen6dl i.MX6DL 1GB
- nitrogen6dl2g i.MX6DL 2GB
- nitrogen6q i.MX6Q/6D 1GB
- nitrogen6q2g i.MX6Q/6D 2GB
- nitrogen6s i.MX6S 512MB
- nitrogen6s1g i.MX6S 1GB
-
-Alison Wang <b18965@freescale.com>
-
- vf610twr VF610
-
-Sergey Yanovich <ynvich@gmail.com>
-
- lp8x4x xscale/pxa
-
--------------------------------------------------------------------------
-
-Unknown / orphaned boards:
- Board CPU Last known maintainer / Comment
-.........................................................................
-
- omap1510inn ARM925T Kshitij Gupta <kshitij@ti.com>
-
- lubbock xscale/pxa Kyle Harris <kharris@nexus-tech.net> / dead address
-
- imx31_phycore_eet i.MX31 Guennadi Liakhovetski <g.liakhovetski@gmx.de> / resigned
- mx31ads i.MX31 Guennadi Liakhovetski <g.liakhovetski@gmx.de> / resigned
-
-#########################################################################
-# x86 Systems: #
-# #
-# Maintainer Name, Email Address #
-# Board CPU #
-#########################################################################
-
-Simon Glass <sjg@chromium.org>
-
- chromebook-x86 Coreboot runs first, then U-Boot
- Supports Intel Sandy Bridge / Ivy Bridge so far
-
- Chromebooks for x86, including:
- Samsung Series 5 Chromebook
- Acer AC700 Chromebook
- Acer C7 Chromebook
- Samsung Chromebook 550
- HP Pavillion Chromebook
- Acer C710 Chromebook
- Chromebook Pixel
-
-#########################################################################
-# MIPS Systems: #
-# #
-# Maintainer Name, Email Address #
-# Board CPU #
-#########################################################################
-
-Wolfgang Denk <wd@denx.de>
-
- incaip MIPS32 4Kc
-
-Vlad Lungu <vlad.lungu@windriver.com>
- qemu_mips MIPS32
-
-Stefan Roese <sr@denx.de>
-
- vct_xxx MIPS32 4Kc
-
--------------------------------------------------------------------------
-
-Unknown / orphaned boards:
- Board CPU Last known maintainer / Comment
-.........................................................................
-
- dbau1x00 MIPS32 Au1000 Thomas Lange <thomas@corelatus.se>
-
-#########################################################################
-# Nios-II Systems: #
-# #
-# Maintainer Name, Email Address #
-# Board CPU #
-#########################################################################
-
-Scott McNutt <smcnutt@psyent.com>
-
- PCI5441 Nios-II
- PK1C20 Nios-II
- nios2-generic Nios-II
-
-#########################################################################
-# MicroBlaze Systems: #
-# #
-# Maintainer Name, Email Address #
-# Board CPU #
-#########################################################################
-
-Michal Simek <monstr@monstr.eu>
-
- microblaze-generic MicroBlaze
-
-#########################################################################
-# Coldfire Systems: #
-# #
-# Maintainer Name, Email Address #
-# Board CPU #
-#########################################################################
-
-Hayden Fraser <Hayden.Fraser@freescale.com>
-
- M5253EVBE mcf52x2
-
-Matthias Fuchs <matthias.fuchs@esd-electronics.com>
-
- TASREG MCF5249
-
-Jens Scharsig <esw@bus-elektronik.de>
-
- eb_cpu5282 mfc5282
-
-TsiChung Liew <Tsi-Chung.Liew@freescale.com>
-
- M52277EVB mcf5227x
- M5235EVB mcf52x2
- M5253DEMO mcf52x2
- M53017EVB mcf532x
- M5329EVB mcf532x
- M5373EVB mcf532x
- M54455EVB mcf5445x
- M5475EVB mcf547x_8x
- M5485EVB mcf547x_8x
-
-Wolfgang Wegner <w.wegner@astro-kom.de>
-
- astro_mcf5373l MCF5373L
-
-#########################################################################
-# AVR32 Systems: #
-# #
-# Maintainer Name, Email Address #
-# Board CPU #
-#########################################################################
-
-Andreas Bie??mann <andreas.devel@googlemail.com>
- grasshopper AT32AP7000
- atngw100mkii AT32AP7000
-
-Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com>
-
- FAVR-32-EZKIT AT32AP7000
-
-Mark Jackson <mpfj@mimc.co.uk>
-
- MIMC200 AT32AP7000
-
-Alex Raimondi <alex.raimondi@miromico.ch>
-Julien May <julien.may@miromico.ch>
-
- HAMMERHEAD AT32AP7000
-
-Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
-
- ATSTK1000 AT32AP7xxx
- ATSTK1002 AT32AP7000
- ATSTK1003 AT32AP7001
- ATSTK1004 AT32AP7002
- ATSTK1006 AT32AP7000
- ATNGW100 AT32AP7000
-
-#########################################################################
-# SuperH Systems: #
-# #
-# Maintainer Name, Email Address #
-# Board CPU #
-#########################################################################
-
-Yusuke Goda <goda.yusuke@renesas.com>
-
- MIGO-R SH7722
-
-Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
- <iwamatsu.nobuhiro@renesas.com>
-
- MS7750SE SH7750
- MS7722SE SH7722
- R7780MP SH7780
- R2DPlus SH7751R
- SH7763RDP SH7763
- RSK7203 SH7203
- AP325RXA SH7723
- SHMIN SH7706
- ECOVEC SH7724
- R0P7734 SH7734
- AP_SH4A_4A SH7734
-
-Mark Jonas <mark.jonas@de.bosch.com>
-
- mpr2 SH7720
-
-Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
-
- MS7720SE SH7720
- R0P77520000RZ SH7752
- R0P77570030RL SH7757
- R0P77850011RL SH7785
-
-#########################################################################
-# Blackfin Systems: #
-# #
-# Maintainer Name, Email Address #
-# Board CPU #
-#########################################################################
-
-Sonic Zhang <sonic.adi@gmail.com>
-Blackfin Team <u-boot-devel@blackfin.uclinux.org>
-
- BF506F-EZKIT BF506
- BF518F-EZBRD BF518
- BF526-EZBRD BF526
- BF527-AD7160-EVAL BF527
- BF527-EZKIT BF527
- BF527-EZKIT-V2 BF527
- BF527-SDP BF527
- BF533-EZKIT BF533
- BF533-STAMP BF533
- BF537-PNAV BF537
- BF537-STAMP BF537
- BF538F-EZKIT BF538
- BF548-EZKIT BF548
- BF561-EZKIT BF561
- BF609-EZKIT BF609
-
-M.Hasewinkel (MHA) <info@ssv-embedded.de>
-
- dnp5370 BF537
-
-Brent Kandetzki <brentk@teleco.com>
-
- IP04 BF532
-
-Peter Meerwald <devel@bct-electronic.com>
-
- bct-brettl2 BF536
-
-I-SYST Micromodule <support@i-syst.com>
-
- IBF-DSP561 BF561
-
-Wojtek Skulski <skulski@pas.rochester.edu>
-Wojtek Skulski <info@skutek.com>
-Benjamin Matthews <mben12@gmail.com>
-
- BlackStamp BF533
- BlackVME BF561
-
-Martin Strubel <strubel@section5.ch>
-
- BF537-minotaur BF537
- BF537-srv1 BF537
-
-Bluetechnix Tinyboards <bluetechnix@blackfin.uclinux.org>
-
- CM-BF527 BF527
- CM-BF533 BF533
- CM-BF537E BF537
- CM-BF537U BF537
- CM-BF548 BF548
- CM-BF561 BF561
- TCM-BF518 BF518
- TCM-BF537 BF537
-
-Valentin Yakovenkov <yakovenkov@niistt.ru>
-Anton Shurpin <shurpin.aa@niistt.ru>
-
- BF561-ACVILON BF561
-
-Haitao Zhang <hzhang@ucrobotics.com>
-Chong Huang <chuang@ucrobotics.com>
-
- bf525-ucr2 BF525
-
-Dimitar Penev <dpn@switchfin.org>
-
- BR4 Appliance BF537
- PR1 Appliance BF537
-
-#########################################################################
-# NDS32 Systems: #
-# #
-# Maintainer Name, Email Address #
-# Board CPU #
-#########################################################################
-
-Macpaul Lin <macpaul@andestech.com>
-
- ADP-AG101 N1213 (AG101 SoC)
- ADP-AG101P N1213 (AG101P XC5 FPGA)
- ADP-AG102 N1213f (AG102 SoC with FPU)
-
-#########################################################################
-# OpenRISC Systems: #
-# #
-# Maintainer Name, Email Address #
-# Board CPU #
-#########################################################################
-
-Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
-
- openrisc-generic OpenRISC
-
-#########################################################################
-# Sandbox: #
-# #
-# Maintainer Name, Email Address #
-# Board CPU #
-#########################################################################
-
-Simon Glass <sjg@chromium.org>
-
- sandbox sandbox
-
-#########################################################################
-# End of MAINTAINERS list #
-#########################################################################
diff --git a/MAKEALL b/MAKEALL
index bed99de..3e895f6 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -160,7 +160,7 @@ FILTER="\$1 !~ /^#/"
[ "$opt_v" ] && FILTER="${FILTER} && $opt_v"
if [ "$SELECTED" ] ; then
- SELECTED=$(awk '('"$FILTER"') { print $1 }' boards.cfg)
+ SELECTED=$(awk '('"$FILTER"') { print $7 }' boards.cfg)
# Make sure some boards from boards.cfg are actually found
if [ -z "$SELECTED" ] ; then
@@ -237,7 +237,7 @@ boards_by_field()
}
boards_by_arch() { boards_by_field 2 "$@" ; }
boards_by_cpu() { boards_by_field 3 "$@" "[: \t]+" ; }
-boards_by_soc() { boards_by_field 6 "$@" ; }
+boards_by_soc() { boards_by_field 4 "$@" ; }
#########################################################################
## MPC5xx Systems
@@ -519,7 +519,7 @@ get_target_location() {
local vendor=""
# Automatic mode
- local line=`egrep -i "^[[:space:]]*${target}[[:space:]]" boards.cfg`
+ local line=`egrep -i "[[:space:]]*${target}[[:space:]]" boards.cfg`
if [ -z "${line}" ] ; then echo "" ; return ; fi
@@ -532,15 +532,17 @@ get_target_location() {
[ "${BOARD_NAME}" ] || BOARD_NAME="${1%_config}"
- if [ "$4" = "-" ] ; then
- board=${BOARD_NAME}
- else
- board="$4"
+ if [ $# -gt 5 ]; then
+ if [ "$6" = "-" ] ; then
+ board=${BOARD_NAME}
+ else
+ board="$4"
+ fi
fi
[ $# -gt 4 ] && [ "$5" != "-" ] && vendor="$5"
- [ $# -gt 6 ] && [ "$7" != "-" ] && {
- tmp="${7%:*}"
+ [ $# -gt 6 ] && [ "$8" != "-" ] && {
+ tmp="${8%:*}"
if [ "$tmp" ] ; then
CONFIG_NAME="$tmp"
fi
diff --git a/Makefile b/Makefile
index 7206aba..4d24cfa 100644
--- a/Makefile
+++ b/Makefile
@@ -784,7 +784,7 @@ unconfig:
sinclude $(obj).boards.depend
$(obj).boards.depend: boards.cfg
- @awk '(NF && $$1 !~ /^#/) { print $$1 ": " $$1 "_config; $$(MAKE)" }' $< > $@
+ @awk '(NF && $$1 !~ /^#/) { print $$7 ": " $$7 "_config; $$(MAKE) -d" }' $< > $@
#
# Functions to generate common board directory names
diff --git a/boards.cfg b/boards.cfg
index 211ed58..6ce6b7b 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -26,1164 +26,1162 @@
# #define CONFIG_HAS_BAR 1
# #define CONFIG_BAZ 64
#
-# The list should be ordered according to the following fields,
-# from most to least significant:
-#
-# ARCH, CPU, SoC, Vendor, Target
-#
-# To keep the list sorted, use something like
-# :.,$! sort -bdf -k2,2 -k3,3 -k6,6 -k5,5 -k1,1
+# The maintainers field lists the e-mail addresses of the board's
+# maintainers, separated by colons. NOTE: there are spaces in this field!
+# For any board without permanent maintainer, please contact
+# Wolfgang Denk <wd@denx.de>
+# And Cc: the <u-boot@lists.denx.de> mailing list.
+
+# The list should be ordered according to the C locale.
#
-# To reformat the list, use something like
-# :.,$! column -t
+# To keep the list formatted and sorted, script tools/reformat.py is available.
+# It can be used from a shell:
+# tools/reformat.py -i -d '-' -s 8 <boards.cfg >boards0.cfg && mv boards0.cfg boards.cfg
+# It can directly be invoked from vim:
+# :%tools/reformat.py -i -d '-' -s 8
#
-# Target ARCH CPU Board name Vendor SoC Options
+# Status, Arch, CPU:SPLCPU, SoC, Vendor, Board name, Target, Options, Maintainers
###########################################################################################################
-integratorcp_cm1136 arm arm1136 integrator armltd - integratorcp:CM1136
-imx31_phycore arm arm1136 - - mx31
-imx31_phycore_eet arm arm1136 imx31_phycore - mx31 imx31_phycore:IMX31_PHYCORE_EET
-qong arm arm1136 - davedenx mx31
-mx31ads arm arm1136 - freescale mx31
-mx31pdk arm arm1136 - freescale mx31
-tt01 arm arm1136 - hale mx31
-imx31_litekit arm arm1136 - logicpd mx31
-flea3 arm arm1136 - CarMediaLab mx35
-mx35pdk arm arm1136 - freescale mx35
-woodburn arm arm1136 - - mx35
-woodburn_sd arm arm1136 woodburn - mx35 woodburn_sd:IMX_CONFIG=board/woodburn/imximage.cfg
-tnetv107x_evm arm arm1176 tnetv107xevm ti tnetv107x
-rpi_b arm arm1176 rpi_b raspberrypi bcm2835
-integratorap_cm720t arm arm720t integrator armltd - integratorap:CM720T
-integratorap_cm920t arm arm920t integrator armltd - integratorap:CM920T
-integratorcp_cm920t arm arm920t integrator armltd - integratorcp:CM920T
-a320evb arm arm920t - faraday a320
-at91rm9200ek arm arm920t at91rm9200ek atmel at91 at91rm9200ek
-at91rm9200ek_ram arm arm920t at91rm9200ek atmel at91 at91rm9200ek:RAMBOOT
-eb_cpux9k2 arm arm920t eb_cpux9k2 BuS at91 eb_cpux9k2
-eb_cpux9k2_ram arm arm920t eb_cpux9k2 BuS at91 eb_cpux9k2:RAMBOOT
-cpuat91 arm arm920t cpuat91 eukrea at91 cpuat91
-cpuat91_ram arm arm920t cpuat91 eukrea at91 cpuat91:RAMBOOT
-mx1ads arm arm920t - - imx
-scb9328 arm arm920t - - imx
-cm4008 arm arm920t - - ks8695
-cm41xx arm arm920t - - ks8695
-mini2440 arm arm920t mini2440 friendlyarm s3c24x0
-VCMA9 arm arm920t vcma9 mpl s3c24x0
-smdk2410 arm arm920t - samsung s3c24x0
-omap1510inn arm arm925t - ti
-integratorap_cm926ejs arm arm926ejs integrator armltd - integratorap:CM926EJ_S
-integratorcp_cm926ejs arm arm926ejs integrator armltd - integratorcp:CM924EJ_S
-aspenite arm arm926ejs - Marvell armada100
-gplugd arm arm926ejs - Marvell armada100
-afeb9260 arm arm926ejs - - at91
-at91sam9260ek_dataflash_cs0 arm arm926ejs at91sam9260ek atmel at91 at91sam9260ek:AT91SAM9260,SYS_USE_DATAFLASH_CS0
-at91sam9260ek_dataflash_cs1 arm arm926ejs at91sam9260ek atmel at91 at91sam9260ek:AT91SAM9260,SYS_USE_DATAFLASH_CS1
-at91sam9260ek_nandflash arm arm926ejs at91sam9260ek atmel at91 at91sam9260ek:AT91SAM9260,SYS_USE_NANDFLASH
-at91sam9261ek_dataflash_cs0 arm arm926ejs at91sam9261ek atmel at91 at91sam9261ek:AT91SAM9261,SYS_USE_DATAFLASH_CS0
-at91sam9261ek_dataflash_cs3 arm arm926ejs at91sam9261ek atmel at91 at91sam9261ek:AT91SAM9261,SYS_USE_DATAFLASH_CS3
-at91sam9261ek_nandflash arm arm926ejs at91sam9261ek atmel at91 at91sam9261ek:AT91SAM9261,SYS_USE_NANDFLASH
-at91sam9263ek_dataflash arm arm926ejs at91sam9263ek atmel at91 at91sam9263ek:AT91SAM9263,SYS_USE_DATAFLASH
-at91sam9263ek_dataflash_cs0 arm arm926ejs at91sam9263ek atmel at91 at91sam9263ek:AT91SAM9263,SYS_USE_DATAFLASH
-at91sam9263ek_nandflash arm arm926ejs at91sam9263ek atmel at91 at91sam9263ek:AT91SAM9263,SYS_USE_NANDFLASH
-at91sam9263ek_norflash arm arm926ejs at91sam9263ek atmel at91 at91sam9263ek:AT91SAM9263,SYS_USE_NORFLASH
-at91sam9263ek_norflash_boot arm arm926ejs at91sam9263ek atmel at91 at91sam9263ek:AT91SAM9263,SYS_USE_BOOT_NORFLASH
-at91sam9g10ek_dataflash_cs0 arm arm926ejs at91sam9261ek atmel at91 at91sam9261ek:AT91SAM9G10,SYS_USE_DATAFLASH_CS0
-at91sam9g10ek_dataflash_cs3 arm arm926ejs at91sam9261ek atmel at91 at91sam9261ek:AT91SAM9G10,SYS_USE_DATAFLASH_CS3
-at91sam9g10ek_nandflash arm arm926ejs at91sam9261ek atmel at91 at91sam9261ek:AT91SAM9G10,SYS_USE_NANDFLASH
-at91sam9g20ek_dataflash_cs0 arm arm926ejs at91sam9260ek atmel at91 at91sam9260ek:AT91SAM9G20,SYS_USE_DATAFLASH_CS0
-at91sam9g20ek_dataflash_cs1 arm arm926ejs at91sam9260ek atmel at91 at91sam9260ek:AT91SAM9G20,SYS_USE_DATAFLASH_CS1
-at91sam9g20ek_mmc arm arm926ejs at91sam9260ek atmel at91 at91sam9260ek:AT91SAM9G20,SYS_USE_MMC
-at91sam9g20ek_nandflash arm arm926ejs at91sam9260ek atmel at91 at91sam9260ek:AT91SAM9G20,SYS_USE_NANDFLASH
-at91sam9g20ek_2mmc_nandflash arm arm926ejs at91sam9260ek atmel at91 at91sam9260ek:AT91SAM9G20,AT91SAM9G20EK_2MMC,SYS_USE_NANDFLASH
-at91sam9m10g45ek_nandflash arm arm926ejs at91sam9m10g45ek atmel at91 at91sam9m10g45ek:AT91SAM9M10G45,SYS_USE_NANDFLASH
-at91sam9rlek_dataflash arm arm926ejs at91sam9rlek atmel at91 at91sam9rlek:AT91SAM9RL,SYS_USE_DATAFLASH
-at91sam9rlek_nandflash arm arm926ejs at91sam9rlek atmel at91 at91sam9rlek:AT91SAM9RL,SYS_USE_NANDFLASH
-at91sam9x5ek_nandflash arm arm926ejs at91sam9x5ek atmel at91 at91sam9x5ek:AT91SAM9X5,SYS_USE_NANDFLASH
-at91sam9x5ek_dataflash arm arm926ejs at91sam9x5ek atmel at91 at91sam9x5ek:AT91SAM9X5,SYS_USE_DATAFLASH
-at91sam9x5ek_spiflash arm arm926ejs at91sam9x5ek atmel at91 at91sam9x5ek:AT91SAM9X5,SYS_USE_SPIFLASH
-at91sam9x5ek_mmc arm arm926ejs at91sam9x5ek atmel at91 at91sam9x5ek:AT91SAM9X5,SYS_USE_MMC
-at91sam9xeek_dataflash_cs0 arm arm926ejs at91sam9260ek atmel at91 at91sam9260ek:AT91SAM9XE,SYS_USE_DATAFLASH_CS0
-at91sam9xeek_dataflash_cs1 arm arm926ejs at91sam9260ek atmel at91 at91sam9260ek:AT91SAM9XE,SYS_USE_DATAFLASH_CS1
-at91sam9xeek_nandflash arm arm926ejs at91sam9260ek atmel at91 at91sam9260ek:AT91SAM9XE,SYS_USE_NANDFLASH
-at91sam9n12ek_nandflash arm arm926ejs at91sam9n12ek atmel at91 at91sam9n12ek:AT91SAM9N12,SYS_USE_NANDFLASH
-at91sam9n12ek_spiflash arm arm926ejs at91sam9n12ek atmel at91 at91sam9n12ek:AT91SAM9N12,SYS_USE_SPIFLASH
-at91sam9n12ek_mmc arm arm926ejs at91sam9n12ek atmel at91 at91sam9n12ek:AT91SAM9N12,SYS_USE_MMC
-snapper9260 arm arm926ejs - bluewater at91 snapper9260:AT91SAM9260
-snapper9g20 arm arm926ejs snapper9260 bluewater at91 snapper9260:AT91SAM9G20
-vl_ma2sc arm arm926ejs vl_ma2sc BuS at91
-vl_ma2sc_ram arm arm926ejs vl_ma2sc BuS at91 vl_ma2sc:RAMLOAD
-sbc35_a9g20_eeprom arm arm926ejs sbc35_a9g20 calao at91 sbc35_a9g20:AT91SAM9G20,SYS_USE_EEPROM
-sbc35_a9g20_nandflash arm arm926ejs sbc35_a9g20 calao at91 sbc35_a9g20:AT91SAM9G20,SYS_USE_NANDFLASH
-tny_a9260_eeprom arm arm926ejs tny_a9260 calao at91 tny_a9260:AT91SAM9260,SYS_USE_EEPROM
-tny_a9260_nandflash arm arm926ejs tny_a9260 calao at91 tny_a9260:AT91SAM9260,SYS_USE_NANDFLASH
-tny_a9g20_eeprom arm arm926ejs tny_a9260 calao at91 tny_a9260:AT91SAM9G20,SYS_USE_EEPROM
-tny_a9g20_nandflash arm arm926ejs tny_a9260 calao at91 tny_a9260:AT91SAM9G20,SYS_USE_NANDFLASH
-ethernut5 arm arm926ejs ethernut5 egnite at91 ethernut5:AT91SAM9XE
-top9000eval_xe arm arm926ejs top9000 emk at91 top9000:EVAL9000
-top9000su_xe arm arm926ejs top9000 emk at91 top9000:SU9000
-meesc arm arm926ejs meesc esd at91 meesc:AT91SAM9263,SYS_USE_NANDFLASH
-meesc_dataflash arm arm926ejs meesc esd at91 meesc:AT91SAM9263,SYS_USE_DATAFLASH
-otc570 arm arm926ejs otc570 esd at91 otc570:AT91SAM9263,SYS_USE_NANDFLASH
-otc570_dataflash arm arm926ejs otc570 esd at91 otc570:AT91SAM9263,SYS_USE_DATAFLASH
-cpu9260 arm arm926ejs cpu9260 eukrea at91 cpu9260:CPU9260
-cpu9260_128M arm arm926ejs cpu9260 eukrea at91 cpu9260:CPU9260,CPU9260_128M
-cpu9260_nand arm arm926ejs cpu9260 eukrea at91 cpu9260:CPU9260,NANDBOOT
-cpu9260_nand_128M arm arm926ejs cpu9260 eukrea at91 cpu9260:CPU9260,CPU9260_128M,NANDBOOT
-cpu9G20 arm arm926ejs cpu9260 eukrea at91 cpu9260:CPU9G20
-cpu9G20_128M arm arm926ejs cpu9260 eukrea at91 cpu9260:CPU9G20,CPU9G20_128M
-cpu9G20_nand arm arm926ejs cpu9260 eukrea at91 cpu9260:CPU9G20,NANDBOOT
-cpu9G20_nand_128M arm arm926ejs cpu9260 eukrea at91 cpu9260:CPU9G20,CPU9G20_128M,NANDBOOT
-pm9261 arm arm926ejs pm9261 ronetix at91 pm9261:AT91SAM9261
-pm9263 arm arm926ejs pm9263 ronetix at91 pm9263:AT91SAM9263
-pm9g45 arm arm926ejs pm9g45 ronetix at91 pm9g45:AT91SAM9G45
-portuxg20 arm arm926ejs stamp9g20 taskit at91 stamp9g20:AT91SAM9G20,PORTUXG20
-stamp9g20 arm arm926ejs stamp9g20 taskit at91 stamp9g20:AT91SAM9G20
-cam_enc_4xx arm arm926ejs cam_enc_4xx ait davinci cam_enc_4xx
-da830evm arm arm926ejs da8xxevm davinci davinci
-da850_am18xxevm arm arm926ejs da8xxevm davinci davinci da850evm:DA850_AM18X_EVM,MAC_ADDR_IN_EEPROM,SYS_I2C_EEPROM_ADDR_LEN=2,SYS_I2C_EEPROM_ADDR=0x50
-da850evm arm arm926ejs da8xxevm davinci davinci da850evm:MAC_ADDR_IN_SPIFLASH
-da850evm_direct_nor arm arm926ejs da8xxevm davinci davinci da850evm:MAC_ADDR_IN_SPIFLASH,USE_NOR,DIRECT_NOR_BOOT
-davinci_dm355evm arm arm926ejs dm355evm davinci davinci
-davinci_dm355leopard arm arm926ejs dm355leopard davinci davinci
-davinci_dm365evm arm arm926ejs dm365evm davinci davinci
-davinci_dm6467evm arm arm926ejs dm6467evm davinci davinci davinci_dm6467evm:REFCLK_FREQ=27000000
-davinci_dm6467Tevm arm arm926ejs dm6467evm davinci davinci davinci_dm6467evm:DAVINCI_DM6467TEVM,REFCLK_FREQ=33000000
-davinci_dvevm arm arm926ejs dvevm davinci davinci
-davinci_schmoogie arm arm926ejs schmoogie davinci davinci
-davinci_sffsdr arm arm926ejs sffsdr davinci davinci
-davinci_sonata arm arm926ejs sonata davinci davinci
-ea20 arm arm926ejs ea20 davinci davinci
-hawkboard arm arm926ejs da8xxevm davinci davinci
-hawkboard_uart arm arm926ejs da8xxevm davinci davinci hawkboard:UART_U_BOOT
-enbw_cmc arm arm926ejs enbw_cmc enbw davinci
-calimain arm arm926ejs calimain omicron davinci
-pogo_e02 arm arm926ejs - cloudengines kirkwood
-dns325 arm arm926ejs - d-link kirkwood
-iconnect arm arm926ejs - iomega kirkwood
-lschlv2 arm arm926ejs lsxl buffalo kirkwood lsxl:LSCHLV2
-lsxhl arm arm926ejs lsxl buffalo kirkwood lsxl:LSXHL
-km_kirkwood arm arm926ejs km_arm keymile kirkwood km_kirkwood:KM_KIRKWOOD
-km_kirkwood_pci arm arm926ejs km_arm keymile kirkwood km_kirkwood:KM_KIRKWOOD_PCI
-kmnusa arm arm926ejs km_arm keymile kirkwood km_kirkwood:KM_NUSA
-kmsuv31 arm arm926ejs km_arm keymile kirkwood km_kirkwood:KM_SUV31
-mgcoge3un arm arm926ejs km_arm keymile kirkwood km_kirkwood:KM_MGCOGE3UN
-kmcoge5un arm arm926ejs km_arm keymile kirkwood km_kirkwood:KM_COGE5UN
-portl2 arm arm926ejs km_arm keymile kirkwood km_kirkwood:KM_PORTL2
-d2net_v2 arm arm926ejs net2big_v2 LaCie kirkwood lacie_kw:D2NET_V2
-inetspace_v2 arm arm926ejs netspace_v2 LaCie kirkwood lacie_kw:INETSPACE_V2
-net2big_v2 arm arm926ejs net2big_v2 LaCie kirkwood lacie_kw:NET2BIG_V2
-netspace_lite_v2 arm arm926ejs netspace_v2 LaCie kirkwood lacie_kw:NETSPACE_LITE_V2
-netspace_max_v2 arm arm926ejs netspace_v2 LaCie kirkwood lacie_kw:NETSPACE_MAX_V2
-netspace_mini_v2 arm arm926ejs netspace_v2 LaCie kirkwood lacie_kw:NETSPACE_MINI_V2
-netspace_v2 arm arm926ejs netspace_v2 LaCie kirkwood lacie_kw:NETSPACE_V2
-wireless_space arm arm926ejs wireless_space LaCie kirkwood
-dreamplug arm arm926ejs - Marvell kirkwood
-guruplug arm arm926ejs - Marvell kirkwood
-mv88f6281gtw_ge arm arm926ejs - Marvell kirkwood
-openrd_base arm arm926ejs openrd Marvell kirkwood openrd:BOARD_IS_OPENRD_BASE
-openrd_client arm arm926ejs openrd Marvell kirkwood openrd:BOARD_IS_OPENRD_CLIENT
-openrd_ultimate arm arm926ejs openrd Marvell kirkwood openrd:BOARD_IS_OPENRD_ULTIMATE
-rd6281a arm arm926ejs - Marvell kirkwood
-sheevaplug arm arm926ejs - Marvell kirkwood
-ib62x0 arm arm926ejs ib62x0 raidsonic kirkwood
-dockstar arm arm926ejs - Seagate kirkwood
-goflexhome arm arm926ejs - Seagate kirkwood
-tk71 arm arm926ejs tk71 karo kirkwood
-devkit3250 arm arm926ejs devkit3250 timll lpc32xx
-jadecpu arm arm926ejs jadecpu syteco mb86r0x
-mx25pdk arm arm926ejs mx25pdk freescale mx25 mx25pdk:IMX_CONFIG=board/freescale/mx25pdk/imximage.cfg
-tx25 arm arm926ejs tx25 karo mx25
-zmx25 arm arm926ejs zmx25 syteco mx25
-imx27lite arm arm926ejs imx27lite logicpd mx27
-magnesium arm arm926ejs imx27lite logicpd mx27
-mx23_olinuxino arm arm926ejs mx23_olinuxino olimex mxs mx23_olinuxino
-apx4devkit arm arm926ejs apx4devkit bluegiga mxs apx4devkit
-mx23evk arm arm926ejs mx23evk freescale mxs mx23evk
-m28evk arm arm926ejs m28evk denx mxs m28evk
-mx28evk arm arm926ejs mx28evk freescale mxs mx28evk:ENV_IS_IN_MMC
-mx28evk_nand arm arm926ejs mx28evk freescale mxs mx28evk:ENV_IS_IN_NAND
-sc_sps_1 arm arm926ejs sc_sps_1 schulercontrol mxs
-nhk8815 arm arm926ejs nhk8815 st nomadik
-nhk8815_onenand arm arm926ejs nhk8815 st nomadik nhk8815:BOOT_ONENAND
-omap5912osk arm arm926ejs - ti omap
-omap730p2 arm arm926ejs omap730p2 ti omap omap730p2:CS3_BOOT
-omap730p2_cs0boot arm arm926ejs omap730p2 ti omap omap730p2:CS0_BOOT
-omap730p2_cs3boot arm arm926ejs omap730p2 ti omap omap730p2:CS3_BOOT
-edminiv2 arm arm926ejs - LaCie orion5x
-dkb arm arm926ejs - Marvell pantheon
-spear300 arm arm926ejs spear300 spear spear spear3xx_evb:spear300
-spear300_nand arm arm926ejs spear300 spear spear spear3xx_evb:spear300,nand
-spear300_usbtty arm arm926ejs spear300 spear spear spear3xx_evb:spear300,usbtty
-spear300_usbtty_nand arm arm926ejs spear300 spear spear spear3xx_evb:spear300,usbtty,nand
-spear310 arm arm926ejs spear310 spear spear spear3xx_evb:spear310
-spear310_pnor arm arm926ejs spear310 spear spear spear3xx_evb:spear310,FLASH_PNOR
-spear310_nand arm arm926ejs spear310 spear spear spear3xx_evb:spear310,nand
-spear310_usbtty arm arm926ejs spear310 spear spear spear3xx_evb:spear310,usbtty
-spear310_usbtty_pnor arm arm926ejs spear310 spear spear spear3xx_evb:spear310,usbtty,FLASH_PNOR
-spear310_usbtty_nand arm arm926ejs spear310 spear spear spear3xx_evb:spear310,usbtty,nand
-spear320 arm arm926ejs spear320 spear spear spear3xx_evb:spear320
-spear320_pnor arm arm926ejs spear320 spear spear spear3xx_evb:spear320,FLASH_PNOR
-spear320_nand arm arm926ejs spear320 spear spear spear3xx_evb:spear320,nand
-spear320_usbtty arm arm926ejs spear320 spear spear spear3xx_evb:spear320,usbtty
-spear320_usbtty_pnor arm arm926ejs spear320 spear spear spear3xx_evb:spear320,usbtty,FLASH_PNOR
-spear320_usbtty_nand arm arm926ejs spear320 spear spear spear3xx_evb:spear320,usbtty,nand
-spear600 arm arm926ejs spear600 spear spear spear6xx_evb:spear600
-spear600_nand arm arm926ejs spear600 spear spear spear6xx_evb:spear600,nand
-spear600_usbtty arm arm926ejs spear600 spear spear spear6xx_evb:spear600,usbtty
-spear600_usbtty_nand arm arm926ejs spear600 spear spear spear6xx_evb:spear600,usbtty,nand
-x600 arm arm926ejs - spear spear x600
-versatileab arm arm926ejs versatile armltd versatile versatile:ARCH_VERSATILE_AB
-versatilepb arm arm926ejs versatile armltd versatile versatile:ARCH_VERSATILE_PB
-versatileqemu arm arm926ejs versatile armltd versatile versatile:ARCH_VERSATILE_QEMU,ARCH_VERSATILE_PB
-integratorap_cm946es arm arm946es integrator armltd - integratorap:CM946ES
-integratorcp_cm946es arm arm946es integrator armltd - integratorcp:CM946ES
-vexpress_ca15_tc2 arm armv7 vexpress armltd
-vexpress_ca5x2 arm armv7 vexpress armltd
-vexpress_ca9x4 arm armv7 vexpress armltd
-am335x_evm arm armv7 am335x ti am33xx am335x_evm:SERIAL1,CONS_INDEX=1,NAND
-am335x_evm_nor arm armv7 am335x ti am33xx am335x_evm:SERIAL1,CONS_INDEX=1,NAND,NOR
-am335x_evm_norboot arm armv7 am335x ti am33xx am335x_evm:SERIAL1,CONS_INDEX=1,NOR,NOR_BOOT
-am335x_evm_spiboot arm armv7 am335x ti am33xx am335x_evm:SERIAL1,CONS_INDEX=1,SPI_BOOT
-am335x_evm_uart1 arm armv7 am335x ti am33xx am335x_evm:SERIAL2,CONS_INDEX=1,NAND
-am335x_evm_uart2 arm armv7 am335x ti am33xx am335x_evm:SERIAL3,CONS_INDEX=1,NAND
-am335x_evm_uart3 arm armv7 am335x ti am33xx am335x_evm:SERIAL4,CONS_INDEX=1,NAND
-am335x_evm_uart4 arm armv7 am335x ti am33xx am335x_evm:SERIAL5,CONS_INDEX=1,NAND
-am335x_evm_uart5 arm armv7 am335x ti am33xx am335x_evm:SERIAL6,CONS_INDEX=1,NAND
-am335x_evm_usbspl arm armv7 am335x ti am33xx am335x_evm:SERIAL1,CONS_INDEX=1,NAND,SPL_USBETH_SUPPORT
-am335x_boneblack arm armv7 am335x ti am33xx am335x_evm:SERIAL1,CONS_INDEX=1,EMMC_BOOT
-ti814x_evm arm armv7 ti814x ti am33xx
-pcm051 arm armv7 pcm051 phytec am33xx pcm051
-sama5d3xek_mmc arm armv7 sama5d3xek atmel at91 sama5d3xek:SAMA5D3,SYS_USE_MMC
-sama5d3xek_nandflash arm armv7 sama5d3xek atmel at91 sama5d3xek:SAMA5D3,SYS_USE_NANDFLASH
-sama5d3xek_spiflash arm armv7 sama5d3xek atmel at91 sama5d3xek:SAMA5D3,SYS_USE_SERIALFLASH
-highbank arm armv7 highbank - highbank
-m53evk arm armv7 m53evk denx mx5 m53evk:IMX_CONFIG=board/denx/m53evk/imximage.cfg
-mx51_efikamx arm armv7 mx51_efikamx genesi mx5 mx51_efikamx:MACH_TYPE=MACH_TYPE_MX51_EFIKAMX,IMX_CONFIG=board/genesi/mx51_efikamx/imximage_mx.cfg
-mx51_efikasb arm armv7 mx51_efikamx genesi mx5 mx51_efikamx:MACH_TYPE=MACH_TYPE_MX51_EFIKASB,IMX_CONFIG=board/genesi/mx51_efikamx/imximage_sb.cfg
-mx51evk arm armv7 mx51evk freescale mx5 mx51evk:IMX_CONFIG=board/freescale/mx51evk/imximage.cfg
-mx53ard arm armv7 mx53ard freescale mx5 mx53ard:IMX_CONFIG=board/freescale/mx53ard/imximage_dd3.cfg
-mx53evk arm armv7 mx53evk freescale mx5 mx53evk:IMX_CONFIG=board/freescale/mx53evk/imximage.cfg
-mx53loco arm armv7 mx53loco freescale mx5 mx53loco:IMX_CONFIG=board/freescale/mx53loco/imximage.cfg
-mx53smd arm armv7 mx53smd freescale mx5 mx53smd:IMX_CONFIG=board/freescale/mx53smd/imximage.cfg
-ima3-mx53 arm armv7 ima3-mx53 esg mx5 ima3-mx53:IMX_CONFIG=board/esg/ima3-mx53/imximage.cfg
-vision2 arm armv7 vision2 ttcontrol mx5 vision2:IMX_CONFIG=board/ttcontrol/vision2/imximage_hynix.cfg
-cgtqmx6qeval arm armv7 cgtqmx6eval congatec mx6 cgtqmx6eval:IMX_CONFIG=board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg,MX6Q
-mx6qarm2 arm armv7 mx6qarm2 freescale mx6 mx6qarm2:IMX_CONFIG=board/freescale/mx6qarm2/imximage.cfg
-mx6qsabreauto arm armv7 mx6qsabreauto freescale mx6 mx6qsabreauto:IMX_CONFIG=board/freescale/mx6qsabreauto/imximage.cfg,MX6Q
-mx6qsabrelite arm armv7 mx6qsabrelite freescale mx6 mx6qsabrelite:IMX_CONFIG=board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg
-mx6dlsabresd arm armv7 mx6sabresd freescale mx6 mx6sabresd:IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6dl.cfg,MX6DL
-mx6qsabresd arm armv7 mx6sabresd freescale mx6 mx6sabresd:IMX_CONFIG=board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg,MX6Q
-mx6slevk arm armv7 mx6slevk freescale mx6 mx6slevk:IMX_CONFIG=board/freescale/mx6slevk/imximage.cfg,MX6SL
-titanium arm armv7 titanium freescale mx6 titanium:IMX_CONFIG=board/freescale/titanium/imximage.cfg
-vf610twr arm armv7 vf610twr freescale vf610 vf610twr:IMX_CONFIG=board/freescale/vf610twr/imximage.cfg
-eco5pk arm armv7 eco5pk 8dtech omap3
-nitrogen6dl arm armv7 nitrogen6x boundary mx6 nitrogen6x:IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6dl.cfg,MX6DL,DDR_MB=1024
-nitrogen6dl2g arm armv7 nitrogen6x boundary mx6 nitrogen6x:IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6dl2g.cfg,MX6DL,DDR_MB=2048
-nitrogen6q arm armv7 nitrogen6x boundary mx6 nitrogen6x:IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6q.cfg,MX6Q,DDR_MB=1024
-nitrogen6q2g arm armv7 nitrogen6x boundary mx6 nitrogen6x:IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6q2g.cfg,MX6Q,DDR_MB=2048
-nitrogen6s arm armv7 nitrogen6x boundary mx6 nitrogen6x:IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6s.cfg,MX6S,DDR_MB=512
-nitrogen6s1g arm armv7 nitrogen6x boundary mx6 nitrogen6x:IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6s1g.cfg,MX6S,DDR_MB=1024
-wandboard_dl arm armv7 wandboard - mx6 wandboard:IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6dl.cfg,MX6DL,DDR_MB=1024
-wandboard_quad arm armv7 wandboard - mx6 wandboard:IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6q2g.cfg,MX6Q,DDR_MB=2048
-wandboard_solo arm armv7 wandboard - mx6 wandboard:IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6s.cfg,MX6S,DDR_MB=512
-omap3_overo arm armv7 overo - omap3
-omap3_pandora arm armv7 pandora - omap3
-dig297 arm armv7 dig297 comelit omap3
-cm_t35 arm armv7 cm_t35 compulab omap3
-igep0020 arm armv7 igep00x0 isee omap3 igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_ONENAND
-igep0020_nand arm armv7 igep00x0 isee omap3 igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_NAND
-igep0030 arm armv7 igep00x0 isee omap3 igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND
-igep0030_nand arm armv7 igep00x0 isee omap3 igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_NAND
-igep0032 arm armv7 igep00x0 isee omap3 igep00x0:MACH_TYPE=MACH_TYPE_IGEP0032,BOOT_ONENAND
-igep0033 arm armv7 igep0033 isee am33xx
-am3517_evm arm armv7 am3517evm logicpd omap3
-mt_ventoux arm armv7 mt_ventoux teejet omap3
-omap3_zoom1 arm armv7 zoom1 logicpd omap3
-omap3_zoom2 arm armv7 zoom2 logicpd omap3
-omap3_logic arm armv7 omap3som logicpd omap3
-omap3_mvblx arm armv7 mvblx matrix_vision omap3
-am3517_crane arm armv7 am3517crane ti omap3
-omap3_beagle arm armv7 beagle ti omap3
-omap3_evm arm armv7 evm ti omap3
-omap3_evm_quick_mmc arm armv7 evm ti omap3
-omap3_evm_quick_nand arm armv7 evm ti omap3
-omap3_sdp3430 arm armv7 sdp3430 ti omap3
-devkit8000 arm armv7 devkit8000 timll omap3
-mcx arm armv7 mcx htkw omap3
-tricorder arm armv7 tricorder corscience omap3
-twister arm armv7 twister technexion omap3
-nokia_rx51 arm armv7 rx51 nokia omap3
-omap4_panda arm armv7 panda ti omap4
-omap4_sdp4430 arm armv7 sdp4430 ti omap4
-omap5_uevm arm armv7 omap5_uevm ti omap5
-dra7xx_evm arm armv7 dra7xx ti omap5
-s5p_goni arm armv7 goni samsung s5pc1xx
-smdkc100 arm armv7 smdkc100 samsung s5pc1xx
-origen arm armv7 origen samsung exynos
-s5pc210_universal arm armv7 universal_c210 samsung exynos
-snow arm armv7 smdk5250 samsung exynos
-smdk5250 arm armv7 smdk5250 samsung exynos
-smdkv310 arm armv7 smdkv310 samsung exynos
-trats arm armv7 trats samsung exynos
-harmony arm armv7:arm720t harmony nvidia tegra20
-seaboard arm armv7:arm720t seaboard nvidia tegra20
-ventana arm armv7:arm720t ventana nvidia tegra20
-whistler arm armv7:arm720t whistler nvidia tegra20
-cardhu arm armv7:arm720t cardhu nvidia tegra30
-beaver arm armv7:arm720t beaver nvidia tegra30
-dalmore arm armv7:arm720t dalmore nvidia tegra114
-colibri_t20_iris arm armv7:arm720t colibri_t20_iris toradex tegra20
-u8500_href arm armv7 u8500 st-ericsson u8500
-snowball arm armv7 snowball st-ericsson u8500
-kzm9g arm armv7 kzm9g kmc rmobile
-armadillo-800eva arm armv7 armadillo-800eva atmark-techno rmobile
-zynq arm armv7 zynq xilinx zynq
-zynq_dcc arm armv7 zynq xilinx zynq zynq:ZYNQ_DCC
-socfpga_cyclone5 arm armv7 socfpga altera socfpga
-actux1_4_16 arm ixp actux1 - - actux1:FLASH2X2
-actux1_4_32 arm ixp actux1 - - actux1:FLASH2X2,RAM_32MB
-actux1_8_16 arm ixp actux1 - - actux1:FLASH1X8
-actux1_8_32 arm ixp actux1 - - actux1:FLASH1X8,RAM_32MB
-actux2 arm ixp
-actux3 arm ixp
-actux4 arm ixp
-dvlhost arm ixp
-pdnb3 arm ixp pdnb3 prodrive
-scpu arm ixp pdnb3 prodrive - pdnb3:SCPU
-balloon3 arm pxa
-h2200 arm pxa
-lp8x4x arm pxa lp8x4x icpdas
-lubbock arm pxa
-palmld arm pxa
-palmtc arm pxa
-palmtreo680 arm pxa
-polaris arm pxa trizepsiv - - trizepsiv:POLARIS
-pxa255_idp arm pxa
-trizepsiv arm pxa
-vpac270_nor_128 arm pxa vpac270 - - vpac270:NOR,RAM_128M
-vpac270_nor_256 arm pxa vpac270 - - vpac270:NOR,RAM_256M
-vpac270_ond_256 arm pxa vpac270 - - vpac270:ONENAND,RAM_256M
-xaeniax arm pxa
-zipitz2 arm pxa
-colibri_pxa270 arm pxa - toradex
-jornada arm sa1100
-plutux arm armv7:arm720t plutux avionic-design tegra20
-medcom-wide arm armv7:arm720t medcom-wide avionic-design tegra20
-tec arm armv7:arm720t tec avionic-design tegra20
-paz00 arm armv7:arm720t paz00 compal tegra20
-trimslice arm armv7:arm720t trimslice compulab tegra20
-atngw100 avr32 at32ap - atmel at32ap700x
-atngw100mkii avr32 at32ap - atmel at32ap700x
-atstk1002 avr32 at32ap atstk1000 atmel at32ap700x
-atstk1003 avr32 at32ap atstk1000 atmel at32ap700x
-atstk1004 avr32 at32ap atstk1000 atmel at32ap700x
-atstk1006 avr32 at32ap atstk1000 atmel at32ap700x
-favr-32-ezkit avr32 at32ap - earthlcd at32ap700x
-grasshopper avr32 at32ap - in-circuit at32ap700x
-mimc200 avr32 at32ap - mimc at32ap700x
-hammerhead avr32 at32ap - miromico at32ap700x
-bct-brettl2 blackfin blackfin
-bf506f-ezkit blackfin blackfin
-bf518f-ezbrd blackfin blackfin
-bf525-ucr2 blackfin blackfin
-bf526-ezbrd blackfin blackfin
-bf527-ad7160-eval blackfin blackfin
-bf527-ezkit blackfin blackfin
-bf527-ezkit-v2 blackfin blackfin bf527-ezkit - - bf527-ezkit:BF527_EZKIT_REV_2_1
-bf527-sdp blackfin blackfin
-bf533-ezkit blackfin blackfin
-bf533-stamp blackfin blackfin
-bf537-minotaur blackfin blackfin
-bf537-pnav blackfin blackfin
-bf537-srv1 blackfin blackfin
-bf537-stamp blackfin blackfin
-bf538f-ezkit blackfin blackfin
-bf548-ezkit blackfin blackfin
-bf561-acvilon blackfin blackfin
-bf561-ezkit blackfin blackfin
-bf609-ezkit blackfin blackfin
-blackstamp blackfin blackfin
-blackvme blackfin blackfin
-br4 blackfin blackfin
-cm-bf527 blackfin blackfin
-cm-bf533 blackfin blackfin
-cm-bf537e blackfin blackfin
-cm-bf537u blackfin blackfin
-cm-bf548 blackfin blackfin
-cm-bf561 blackfin blackfin
-dnp5370 blackfin blackfin
-ibf-dsp561 blackfin blackfin
-ip04 blackfin blackfin
-pr1 blackfin blackfin
-tcm-bf518 blackfin blackfin
-tcm-bf537 blackfin blackfin
-M52277EVB m68k mcf5227x m52277evb freescale - M52277EVB:SYS_SPANSION_BOOT,SYS_TEXT_BASE=0x00000000
-M52277EVB_stmicro m68k mcf5227x m52277evb freescale - M52277EVB:CF_SBF,SYS_STMICRO_BOOT,SYS_TEXT_BASE=0x43E00000
-M5235EVB m68k mcf523x m5235evb freescale - M5235EVB:SYS_TEXT_BASE=0xFFE00000
-M5235EVB_Flash32 m68k mcf523x m5235evb freescale - M5235EVB:NORFLASH_PS32BIT,SYS_TEXT_BASE=0xFFC00000
-cobra5272 m68k mcf52x2 cobra5272 -
-idmr m68k mcf52x2
-eb_cpu5282 m68k mcf52x2 eb_cpu5282 BuS - eb_cpu5282:SYS_TEXT_BASE=0xFF000000,SYS_MONITOR_BASE=0xFF000400
-eb_cpu5282_internal m68k mcf52x2 eb_cpu5282 BuS - eb_cpu5282:SYS_TEXT_BASE=0xF0000000,SYS_MONITOR_BASE=0xF0000418
-TASREG m68k mcf52x2 tasreg esd
-M5208EVBE m68k mcf52x2 m5208evbe freescale
-M5249EVB m68k mcf52x2 m5249evb freescale
-M5253DEMO m68k mcf52x2 m5253demo freescale
-M5253EVBE m68k mcf52x2 m5253evbe freescale
-M5271EVB m68k mcf52x2 m5271evb freescale
-M5272C3 m68k mcf52x2 m5272c3 freescale
-M5275EVB m68k mcf52x2 m5275evb freescale
-M5282EVB m68k mcf52x2 m5282evb freescale
-astro_mcf5373l m68k mcf532x mcf5373l astro
-M53017EVB m68k mcf532x m53017evb freescale
-M5329AFEE m68k mcf532x m5329evb freescale - M5329EVB:NANDFLASH_SIZE=0
-M5329BFEE m68k mcf532x m5329evb freescale - M5329EVB:NANDFLASH_SIZE=16
-M5373EVB m68k mcf532x m5373evb freescale - M5373EVB:NANDFLASH_SIZE=16
-M54418TWR m68k mcf5445x m54418twr freescale - M54418TWR:CF_SBF,SYS_SERIAL_BOOT,SYS_TEXT_BASE=0x47E00000,SYS_INPUT_CLKSRC=50000000
-M54418TWR_nand_mii m68k mcf5445x m54418twr freescale - M54418TWR:SYS_NAND_BOOT,SYS_TEXT_BASE=0x47E00000,SYS_INPUT_CLKSRC=25000000
-M54418TWR_nand_rmii m68k mcf5445x m54418twr freescale - M54418TWR:SYS_NAND_BOOT,SYS_TEXT_BASE=0x47E00000,SYS_INPUT_CLKSRC=50000000
-M54418TWR_nand_rmii_lowfreq m68k mcf5445x m54418twr freescale - M54418TWR:SYS_NAND_BOOT,LOW_MCFCLK,SYS_TEXT_BASE=0x47E00000,SYS_INPUT_CLKSRC=50000000
-M54418TWR_serial_mii m68k mcf5445x m54418twr freescale - M54418TWR:CF_SBF,SYS_SERIAL_BOOT,SYS_TEXT_BASE=0x47E00000,SYS_INPUT_CLKSRC=25000000
-M54418TWR_serial_rmii m68k mcf5445x m54418twr freescale - M54418TWR:CF_SBF,SYS_SERIAL_BOOT,SYS_TEXT_BASE=0x47E00000,SYS_INPUT_CLKSRC=50000000
-M54451EVB m68k mcf5445x m54451evb freescale - M54451EVB:SYS_TEXT_BASE=0x00000000,SYS_INPUT_CLKSRC=24000000
-M54451EVB_stmicro m68k mcf5445x m54451evb freescale - M54451EVB:CF_SBF,SYS_STMICRO_BOOT,SYS_TEXT_BASE=0x47e00000,SYS_INPUT_CLKSRC=24000000
-M54455EVB m68k mcf5445x m54455evb freescale - M54455EVB:SYS_ATMEL_BOOT,SYS_TEXT_BASE=0x04000000,SYS_INPUT_CLKSRC=33333333
-M54455EVB_a66 m68k mcf5445x m54455evb freescale - M54455EVB:SYS_ATMEL_BOOT,SYS_TEXT_BASE=0x04000000,SYS_INPUT_CLKSRC=66666666
-M54455EVB_i66 m68k mcf5445x m54455evb freescale - M54455EVB:SYS_INTEL_BOOT,SYS_TEXT_BASE=0x00000000,SYS_INPUT_CLKSRC=66666666
-M54455EVB_intel m68k mcf5445x m54455evb freescale - M54455EVB:SYS_INTEL_BOOT,SYS_TEXT_BASE=0x00000000,SYS_INPUT_CLKSRC=33333333
-M54455EVB_stm33 m68k mcf5445x m54455evb freescale - M54455EVB:SYS_STMICRO_BOOT,CF_SBF,SYS_TEXT_BASE=0x4FE00000,SYS_INPUT_CLKSRC=33333333
-M5475AFE m68k mcf547x_8x m547xevb freescale - M5475EVB:SYS_BUSCLK=133333333,SYS_BOOTSZ=2,SYS_DRAMSZ=64
-M5475BFE m68k mcf547x_8x m547xevb freescale - M5475EVB:SYS_BUSCLK=133333333,SYS_BOOTSZ=2,SYS_DRAMSZ=64,SYS_NOR1SZ=16
-M5475CFE m68k mcf547x_8x m547xevb freescale - M5475EVB:SYS_BUSCLK=133333333,SYS_BOOTSZ=2,SYS_DRAMSZ=64,SYS_NOR1SZ=16,SYS_VIDEO,SYS_USBCTRL
-M5475DFE m68k mcf547x_8x m547xevb freescale - M5475EVB:SYS_BUSCLK=133333333,SYS_BOOTSZ=2,SYS_DRAMSZ=64,SYS_USBCTRL
-M5475EFE m68k mcf547x_8x m547xevb freescale - M5475EVB:SYS_BUSCLK=133333333,SYS_BOOTSZ=2,SYS_DRAMSZ=64,SYS_VIDEO,SYS_USBCTRL
-M5475FFE m68k mcf547x_8x m547xevb freescale - M5475EVB:SYS_BUSCLK=133333333,SYS_BOOTSZ=2,SYS_DRAMSZ=64,SYS_NOR1SZ=32,SYS_VIDEO,SYS_USBCTRL,SYS_DRAMSZ1=64
-M5475GFE m68k mcf547x_8x m547xevb freescale - M5475EVB:SYS_BUSCLK=133333333,SYS_BOOTSZ=4,SYS_DRAMSZ=64
-M5485AFE m68k mcf547x_8x m548xevb freescale - M5485EVB:SYS_BUSCLK=100000000,SYS_BOOTSZ=2,SYS_DRAMSZ=64
-M5485BFE m68k mcf547x_8x m548xevb freescale - M5485EVB:SYS_BUSCLK=100000000,SYS_BOOTSZ=2,SYS_DRAMSZ=64,SYS_NOR1SZ=16
-M5485CFE m68k mcf547x_8x m548xevb freescale - M5485EVB:SYS_BUSCLK=100000000,SYS_BOOTSZ=2,SYS_DRAMSZ=64,SYS_NOR1SZ=16,SYS_VIDEO,SYS_USBCTRL
-M5485DFE m68k mcf547x_8x m548xevb freescale - M5485EVB:SYS_BUSCLK=100000000,SYS_BOOTSZ=2,SYS_DRAMSZ=64,SYS_USBCTRL
-M5485EFE m68k mcf547x_8x m548xevb freescale - M5485EVB:SYS_BUSCLK=100000000,SYS_BOOTSZ=2,SYS_DRAMSZ=64,SYS_VIDEO,SYS_USBCTRL
-M5485FFE m68k mcf547x_8x m548xevb freescale - M5485EVB:SYS_BUSCLK=100000000,SYS_BOOTSZ=2,SYS_DRAMSZ=64,SYS_NOR1SZ=32,SYS_VIDEO,SYS_USBCTRL,SYS_DRAMSZ1=64
-M5485GFE m68k mcf547x_8x m548xevb freescale - M5485EVB:SYS_BUSCLK=100000000,SYS_BOOTSZ=4,SYS_DRAMSZ=64
-M5485HFE m68k mcf547x_8x m548xevb freescale - M5485EVB:SYS_BUSCLK=100000000,SYS_BOOTSZ=2,SYS_DRAMSZ=64,SYS_NOR1SZ=16,SYS_VIDEO
-microblaze-generic microblaze microblaze microblaze-generic xilinx
-qemu_mips mips mips32 qemu-mips - - qemu-mips:SYS_BIG_ENDIAN
-qemu_mipsel mips mips32 qemu-mips - - qemu-mips:SYS_LITTLE_ENDIAN
-qemu_mips64 mips mips64 qemu-mips - - qemu-mips64:SYS_BIG_ENDIAN
-qemu_mips64el mips mips64 qemu-mips - - qemu-mips64:SYS_LITTLE_ENDIAN
-qemu_malta mips mips32 qemu-malta - - qemu-malta:MIPS32,SYS_BIG_ENDIAN
-qemu_maltael mips mips32 qemu-malta - - qemu-malta:MIPS32,SYS_LITTLE_ENDIAN
-vct_platinum mips mips32 vct micronas - vct:VCT_PLATINUM
-vct_platinumavc mips mips32 vct micronas - vct:VCT_PLATINUMAVC
-vct_platinumavc_onenand mips mips32 vct micronas - vct:VCT_PLATINUMAVC,VCT_ONENAND
-vct_platinumavc_onenand_small mips mips32 vct micronas - vct:VCT_PLATINUMAVC,VCT_ONENAND,VCT_SMALL_IMAGE
-vct_platinumavc_small mips mips32 vct micronas - vct:VCT_PLATINUMAVC,VCT_SMALL_IMAGE
-vct_platinum_onenand mips mips32 vct micronas - vct:VCT_PLATINUM,VCT_ONENAND
-vct_platinum_onenand_small mips mips32 vct micronas - vct:VCT_PLATINUM,VCT_ONENAND,VCT_SMALL_IMAGE
-vct_platinum_small mips mips32 vct micronas - vct:VCT_PLATINUM,VCT_SMALL_IMAGE
-vct_premium mips mips32 vct micronas - vct:VCT_PREMIUM
-vct_premium_onenand mips mips32 vct micronas - vct:VCT_PREMIUM,VCT_ONENAND
-vct_premium_onenand_small mips mips32 vct micronas - vct:VCT_PREMIUM,VCT_ONENAND,VCT_SMALL_IMAGE
-vct_premium_small mips mips32 vct micronas - vct:VCT_PREMIUM,VCT_SMALL_IMAGE
-dbau1000 mips mips32 dbau1x00 - au1x00 dbau1x00:DBAU1000
-dbau1100 mips mips32 dbau1x00 - au1x00 dbau1x00:DBAU1100
-dbau1500 mips mips32 dbau1x00 - au1x00 dbau1x00:DBAU1500
-dbau1550 mips mips32 dbau1x00 - au1x00 dbau1x00:DBAU1550
-dbau1550_el mips mips32 dbau1x00 - au1x00 dbau1x00:DBAU1550,SYS_LITTLE_ENDIAN
-pb1000 mips mips32 pb1x00 - au1x00 pb1x00:PB1000
-incaip mips mips32 incaip - incaip
-incaip_100MHz mips mips32 incaip - incaip incaip:CPU_CLOCK_RATE=100000000
-incaip_133MHz mips mips32 incaip - incaip incaip:CPU_CLOCK_RATE=133000000
-incaip_150MHz mips mips32 incaip - incaip incaip:CPU_CLOCK_RATE=150000000
-adp-ag101 nds32 n1213 adp-ag101 AndesTech ag101
-adp-ag101p nds32 n1213 adp-ag101p AndesTech ag101
-adp-ag102 nds32 n1213 adp-ag102 AndesTech ag102
-nios2-generic nios2 nios2 nios2-generic altera
-PCI5441 nios2 nios2 pci5441 psyent
-PK1C20 nios2 nios2 pk1c20 psyent
-openrisc-generic openrisc or1200 openrisc-generic openrisc -
-EVB64260 powerpc 74xx_7xx evb64260 - - EVB64260
-EVB64260_750CX powerpc 74xx_7xx evb64260 - - EVB64260
-P3G4 powerpc 74xx_7xx evb64260
-ppmc7xx powerpc 74xx_7xx
-ZUMA powerpc 74xx_7xx evb64260
-ELPPC powerpc 74xx_7xx elppc eltec
-CPCI750 powerpc 74xx_7xx cpci750 esd
-mpc7448hpc2 powerpc 74xx_7xx mpc7448hpc2 freescale
-DB64360 powerpc 74xx_7xx db64360 Marvell
-DB64460 powerpc 74xx_7xx db64460 Marvell
-p3m7448 powerpc 74xx_7xx p3mx prodrive - p3mx:P3M7448
-p3m750 powerpc 74xx_7xx p3mx prodrive - p3mx:P3M750
-pdm360ng powerpc mpc512x
-aria powerpc mpc512x - davedenx
-mecp5123 powerpc mpc512x - esd
-mpc5121ads powerpc mpc512x mpc5121ads freescale
-mpc5121ads_rev2 powerpc mpc512x mpc5121ads freescale - mpc5121ads:MPC5121ADS_REV2
-ac14xx powerpc mpc512x ac14xx ifm
-cmi_mpc5xx powerpc mpc5xx cmi
-PATI powerpc mpc5xx pati mpl
-a3m071 powerpc mpc5xxx a3m071
-a4m072 powerpc mpc5xxx a4m072
-a4m2k powerpc mpc5xxx a3m071 - - a3m071:A4M2K
-BC3450 powerpc mpc5xxx bc3450
-canmb powerpc mpc5xxx
-cm5200 powerpc mpc5xxx
-galaxy5200 powerpc mpc5xxx galaxy5200 - - galaxy5200:galaxy5200
-galaxy5200_LOWBOOT powerpc mpc5xxx galaxy5200 - - galaxy5200:galaxy5200_LOWBOOT
-icecube_5200 powerpc mpc5xxx icecube - - IceCube
-icecube_5200_DDR powerpc mpc5xxx icecube - - IceCube:MPC5200_DDR
-icecube_5200_DDR_LOWBOOT powerpc mpc5xxx icecube - - IceCube:SYS_TEXT_BASE=0xFF800000,MPC5200_DDR
-icecube_5200_DDR_LOWBOOT08 powerpc mpc5xxx icecube - - IceCube:SYS_TEXT_BASE=0xFF800000,MPC5200_DDR
-icecube_5200_LOWBOOT powerpc mpc5xxx icecube - - IceCube:SYS_TEXT_BASE=0xFF000000
-icecube_5200_LOWBOOT08 powerpc mpc5xxx icecube - - IceCube:SYS_TEXT_BASE=0xFF800000
-inka4x0 powerpc mpc5xxx
-ipek01 powerpc mpc5xxx
-jupiter powerpc mpc5xxx
-Lite5200 powerpc mpc5xxx icecube - - IceCube
-lite5200b powerpc mpc5xxx icecube - - IceCube:MPC5200_DDR,LITE5200B
-lite5200b_LOWBOOT powerpc mpc5xxx icecube - - IceCube:MPC5200_DDR,LITE5200B,SYS_TEXT_BASE=0xFF000000
-lite5200b_PM powerpc mpc5xxx icecube - - IceCube:MPC5200_DDR,LITE5200B,LITE5200B_PM
-Lite5200_LOWBOOT powerpc mpc5xxx icecube - - IceCube:SYS_TEXT_BASE=0xFF000000
-Lite5200_LOWBOOT08 powerpc mpc5xxx icecube - - IceCube:SYS_TEXT_BASE=0xFF800000
-mcc200 powerpc mpc5xxx mcc200 - - mcc200
-mcc200_COM12 powerpc mpc5xxx mcc200 - - mcc200:CONSOLE_COM12
-mcc200_COM12_highboot powerpc mpc5xxx mcc200 - - mcc200:CONSOLE_COM12,SYS_TEXT_BASE=0xFFF00000
-mcc200_COM12_highboot_SDRAM powerpc mpc5xxx mcc200 - - mcc200:CONSOLE_COM12,SYS_TEXT_BASE=0xFFF00000,MCC200_SDRAM
-mcc200_COM12_SDRAM powerpc mpc5xxx mcc200 - - mcc200:CONSOLE_COM12,MCC200_SDRAM
-mcc200_highboot powerpc mpc5xxx mcc200 - - mcc200:SYS_TEXT_BASE=0xFFF00000
-mcc200_highboot_SDRAM powerpc mpc5xxx mcc200 - - mcc200:SYS_TEXT_BASE=0xFFF00000,MCC200_SDRAM
-mcc200_SDRAM powerpc mpc5xxx mcc200 - - mcc200:MCC200_SDRAM
-motionpro powerpc mpc5xxx
-munices powerpc mpc5xxx
-PM520 powerpc mpc5xxx pm520
-PM520_DDR powerpc mpc5xxx pm520 - - PM520:MPC5200_DDR
-PM520_ROMBOOT powerpc mpc5xxx pm520 - - PM520:BOOT_ROM
-PM520_ROMBOOT_DDR powerpc mpc5xxx pm520 - - PM520:MPC5200_DDR,BOOT_ROM
-prs200 powerpc mpc5xxx mcc200 - - mcc200:PRS200,MCC200_SDRAM
-prs200_DDR powerpc mpc5xxx mcc200 - - mcc200:PRS200
-prs200_highboot powerpc mpc5xxx mcc200 - - mcc200:PRS200,SYS_TEXT_BASE=0xFFF00000,MCC200_SDRAM
-prs200_highboot_DDR powerpc mpc5xxx mcc200 - - mcc200:PRS200,SYS_TEXT_BASE=0xFFF00000
-Total5200 powerpc mpc5xxx total5200 - - Total5200:TOTAL5200_REV=1
-Total5200_lowboot powerpc mpc5xxx total5200 - - Total5200:TOTAL5200_REV=1,SYS_TEXT_BASE=0xFE000000
-Total5200_Rev2 powerpc mpc5xxx total5200 - - Total5200:TOTAL5200_REV=2
-Total5200_Rev2_lowboot powerpc mpc5xxx total5200 - - Total5200:TOTAL5200_REV=2,SYS_TEXT_BASE=0xFE000000
-v38b powerpc mpc5xxx
-EVAL5200 powerpc mpc5xxx top5200 emk - TOP5200:EVAL5200
-MINI5200 powerpc mpc5xxx top5200 emk - TOP5200:MINI5200
-TOP5200 powerpc mpc5xxx top5200 emk - TOP5200:TOP5200
-cpci5200 powerpc mpc5xxx - esd
-mecp5200 powerpc mpc5xxx - esd
-pf5200 powerpc mpc5xxx - esd
-O2D powerpc mpc5xxx o2dnt2 ifm - o2d
-O2D300 powerpc mpc5xxx o2dnt2 ifm - o2d300
-O2DNT2 powerpc mpc5xxx o2dnt2 ifm - o2dnt2
-O2DNT2_RAMBOOT powerpc mpc5xxx o2dnt2 ifm - o2dnt2:SYS_TEXT_BASE=0x00100000
-O2I powerpc mpc5xxx o2dnt2 ifm - o2i
-O2MNT powerpc mpc5xxx o2dnt2 ifm - o2mnt
-O2MNT_O2M110 powerpc mpc5xxx o2dnt2 ifm - o2mnt:IFM_SENSOR_TYPE="O2M110"
-O2MNT_O2M112 powerpc mpc5xxx o2dnt2 ifm - o2mnt:IFM_SENSOR_TYPE="O2M112"
-O2MNT_O2M113 powerpc mpc5xxx o2dnt2 ifm - o2mnt:IFM_SENSOR_TYPE="O2M113"
-O3DNT powerpc mpc5xxx o2dnt2 ifm - o3dnt
-digsy_mtc powerpc mpc5xxx digsy_mtc intercontrol
-digsy_mtc_RAMBOOT powerpc mpc5xxx digsy_mtc intercontrol - digsy_mtc:SYS_TEXT_BASE=0x00100000
-digsy_mtc_rev5 powerpc mpc5xxx digsy_mtc intercontrol - digsy_mtc:DIGSY_REV5
-digsy_mtc_rev5_RAMBOOT powerpc mpc5xxx digsy_mtc intercontrol - digsy_mtc:SYS_TEXT_BASE=0x00100000,DIGSY_REV5
-hmi1001 powerpc mpc5xxx - manroland
-mucmc52 powerpc mpc5xxx - manroland
-uc101 powerpc mpc5xxx - manroland
-MVBC_P powerpc mpc5xxx mvbc_p matrix_vision - MVBC_P:MVBC_P
-MVSMR powerpc mpc5xxx mvsmr matrix_vision
-pcm030 powerpc mpc5xxx pcm030 phytec - pcm030
-pcm030_LOWBOOT powerpc mpc5xxx pcm030 phytec - pcm030:SYS_TEXT_BASE=0xFF000000
-aev powerpc mpc5xxx tqm5200 tqc
-cam5200 powerpc mpc5xxx tqm5200 tqc - TQM5200:CAM5200,TQM5200S,TQM5200_B
-cam5200_niosflash powerpc mpc5xxx tqm5200 tqc - TQM5200:CAM5200,TQM5200S,TQM5200_B,CAM5200_NIOSFLASH
-charon powerpc mpc5xxx tqm5200 tqc - charon
-fo300 powerpc mpc5xxx tqm5200 tqc - TQM5200:FO300
-MiniFAP powerpc mpc5xxx tqm5200 tqc - TQM5200:MINIFAP
-TB5200 powerpc mpc5xxx tqm5200 tqc
-TB5200_B powerpc mpc5xxx tqm5200 tqc - TB5200:TQM5200_B
-TQM5200 powerpc mpc5xxx tqm5200 tqc - TQM5200:
-TQM5200_B powerpc mpc5xxx tqm5200 tqc - TQM5200:TQM5200_B
-TQM5200_B_HIGHBOOT powerpc mpc5xxx tqm5200 tqc - TQM5200:TQM5200_B,SYS_TEXT_BASE=0xFFF00000
-TQM5200S powerpc mpc5xxx tqm5200 tqc - TQM5200:TQM5200_B,TQM5200S
-TQM5200S_HIGHBOOT powerpc mpc5xxx tqm5200 tqc - TQM5200:TQM5200_B,TQM5200S,SYS_TEXT_BASE=0xFFF00000
-TQM5200_STK100 powerpc mpc5xxx tqm5200 tqc - TQM5200:STK52XX_REV100
-A3000 powerpc mpc824x a3000
-CPC45 powerpc mpc824x cpc45 - - CPC45
-CPC45_ROMBOOT powerpc mpc824x cpc45 - - CPC45:BOOT_ROM
-CU824 powerpc mpc824x cu824
-eXalion powerpc mpc824x eXalion
-HIDDEN_DRAGON powerpc mpc824x hidden_dragon
-linkstation_HGLAN powerpc mpc824x linkstation - - linkstation:HGLAN=1
-MOUSSE powerpc mpc824x mousse
-MUSENKI powerpc mpc824x musenki
-MVBLUE powerpc mpc824x mvblue
-PN62 powerpc mpc824x pn62
-Sandpoint8240 powerpc mpc824x sandpoint
-Sandpoint8245 powerpc mpc824x sandpoint
-utx8245 powerpc mpc824x
-debris powerpc mpc824x - etin
-kvme080 powerpc mpc824x - etin
-atc powerpc mpc8260
-cogent_mpc8260 powerpc mpc8260 cogent
-CPU86 powerpc mpc8260 cpu86 - - CPU86
-CPU86_ROMBOOT powerpc mpc8260 cpu86 - - CPU86:BOOT_ROM
-CPU87 powerpc mpc8260 cpu87 - - CPU87
-CPU87_ROMBOOT powerpc mpc8260 cpu87 - - CPU87:BOOT_ROM
-ep8248 powerpc mpc8260 ep8248
-ep8248E powerpc mpc8260 ep8248 - - ep8248
-ep8260 powerpc mpc8260
-ep82xxm powerpc mpc8260
-gw8260 powerpc mpc8260
-hymod powerpc mpc8260
-IDS8247 powerpc mpc8260 ids8247
-IPHASE4539 powerpc mpc8260 iphase4539
-ISPAN powerpc mpc8260 ispan
-ISPAN_REVB powerpc mpc8260 ispan - - ISPAN:SYS_REV_B
-muas3001 powerpc mpc8260 muas3001
-muas3001_dev powerpc mpc8260 muas3001 - - muas3001:MUAS_DEV_BOARD
-PM825 powerpc mpc8260 pm826 - - PM826:PCI,SYS_TEXT_BASE=0xFF000000
-PM825_BIGFLASH powerpc mpc8260 pm826 - - PM826:PCI,FLASH_32MB,SYS_TEXT_BASE=0x40000000
-PM825_ROMBOOT powerpc mpc8260 pm826 - - PM826:PCI,BOOT_ROM,SYS_TEXT_BASE=0xFF800000
-PM825_ROMBOOT_BIGFLASH powerpc mpc8260 pm826 - - PM826:PCI,BOOT_ROM,FLASH_32MB,SYS_TEXT_BASE=0xFF800000
-PM826 powerpc mpc8260 pm826 - - PM826:SYS_TEXT_BASE=0xFF000000
-PM826_BIGFLASH powerpc mpc8260 pm826 - - PM826:FLASH_32MB,SYS_TEXT_BASE=0x40000000
-PM826_ROMBOOT powerpc mpc8260 pm826 - - PM826:BOOT_ROM,SYS_TEXT_BASE=0xFF800000
-PM826_ROMBOOT_BIGFLASH powerpc mpc8260 pm826 - - PM826:BOOT_ROM,FLASH_32MB,SYS_TEXT_BASE=0xFF800000
-PM828 powerpc mpc8260 pm828 - - PM828
-PM828_PCI powerpc mpc8260 pm828 - - PM828:PCI
-PM828_ROMBOOT powerpc mpc8260 pm828 - - PM828:BOOT_ROM,SYS_TEXT_BASE=0xFF800000
-PM828_ROMBOOT_PCI powerpc mpc8260 pm828 - - PM828:PCI,BOOT_ROM,SYS_TEXT_BASE=0xFF800000
-ppmc8260 powerpc mpc8260
-Rattler powerpc mpc8260 rattler - - Rattler
-Rattler8248 powerpc mpc8260 rattler - - Rattler:MPC8248
-RPXsuper powerpc mpc8260 rpxsuper
-rsdproto powerpc mpc8260
-sacsng powerpc mpc8260
-ZPC1900 powerpc mpc8260 zpc1900
-MPC8260ADS powerpc mpc8260 mpc8260ads freescale - MPC8260ADS:ADSTYPE=CONFIG_SYS_8260ADS
-MPC8260ADS_33MHz powerpc mpc8260 mpc8260ads freescale - MPC8260ADS:ADSTYPE=CONFIG_SYS_8260ADS,8260_CLKIN=33000000
-MPC8260ADS_33MHz_lowboot powerpc mpc8260 mpc8260ads freescale - MPC8260ADS:ADSTYPE=CONFIG_SYS_8260ADS,8260_CLKIN=33000000,SYS_TEXT_BASE=0xFF800000
-MPC8260ADS_40MHz powerpc mpc8260 mpc8260ads freescale - MPC8260ADS:ADSTYPE=CONFIG_SYS_8260ADS,8260_CLKIN=40000000
-MPC8260ADS_40MHz_lowboot powerpc mpc8260 mpc8260ads freescale - MPC8260ADS:ADSTYPE=CONFIG_SYS_8260ADS,8260_CLKIN=40000000,SYS_TEXT_BASE=0xFF800000
-MPC8260ADS_lowboot powerpc mpc8260 mpc8260ads freescale - MPC8260ADS:ADSTYPE=CONFIG_SYS_8260ADS,SYS_TEXT_BASE=0xFF800000
-MPC8266ADS powerpc mpc8260 mpc8266ads freescale
-MPC8272ADS powerpc mpc8260 mpc8260ads freescale - MPC8260ADS:ADSTYPE=CONFIG_SYS_8272ADS
-MPC8272ADS_lowboot powerpc mpc8260 mpc8260ads freescale - MPC8260ADS:ADSTYPE=CONFIG_SYS_8272ADS,SYS_TEXT_BASE=0xFF800000
-PQ2FADS powerpc mpc8260 mpc8260ads freescale - MPC8260ADS:ADSTYPE=CONFIG_SYS_PQ2FADS
-PQ2FADS_lowboot powerpc mpc8260 mpc8260ads freescale - MPC8260ADS:ADSTYPE=CONFIG_SYS_PQ2FADS,SYS_TEXT_BASE=0xFF800000
-PQ2FADS-VR powerpc mpc8260 mpc8260ads freescale - MPC8260ADS:ADSTYPE=CONFIG_SYS_PQ2FADS,8260_CLKIN=66000000
-PQ2FADS-VR_lowboot powerpc mpc8260 mpc8260ads freescale - MPC8260ADS:ADSTYPE=CONFIG_SYS_PQ2FADS,8260_CLKIN=66000000,SYS_TEXT_BASE=0xFF800000
-PQ2FADS-ZU powerpc mpc8260 mpc8260ads freescale - MPC8260ADS:ADSTYPE=CONFIG_SYS_PQ2FADS
-PQ2FADS-ZU_66MHz powerpc mpc8260 mpc8260ads freescale - MPC8260ADS:ADSTYPE=CONFIG_SYS_PQ2FADS,8260_CLKIN=66000000
-PQ2FADS-ZU_66MHz_lowboot powerpc mpc8260 mpc8260ads freescale - MPC8260ADS:ADSTYPE=CONFIG_SYS_PQ2FADS,8260_CLKIN=66000000,SYS_TEXT_BASE=0xFF800000
-PQ2FADS-ZU_lowboot powerpc mpc8260 mpc8260ads freescale - MPC8260ADS:ADSTYPE=CONFIG_SYS_PQ2FADS,SYS_TEXT_BASE=0xFF800000
-VoVPN-GW_66MHz powerpc mpc8260 vovpn-gw funkwerk - VoVPN-GW:CLKIN_66MHz
-mgcoge powerpc mpc8260 km82xx keymile - km82xx:MGCOGE
-mgcoge3ne powerpc mpc8260 km82xx keymile - km82xx:MGCOGE3NE
-TQM8255_AA powerpc mpc8260 tqm8260 tqc - TQM8260:MPC8255,300MHz
-TQM8260_AA powerpc mpc8260 tqm8260 tqc - TQM8260:MPC8260,200MHz
-TQM8260_AB powerpc mpc8260 tqm8260 tqc - TQM8260:MPC8260,200MHz,L2_CACHE,BUSMODE_60x
-TQM8260_AC powerpc mpc8260 tqm8260 tqc - TQM8260:MPC8260,200MHz,L2_CACHE,BUSMODE_60x
-TQM8260_AD powerpc mpc8260 tqm8260 tqc - TQM8260:MPC8260,300MHz,BUSMODE_60x
-TQM8260_AE powerpc mpc8260 tqm8260 tqc - TQM8260:MPC8260,266MHz
-TQM8260_AF powerpc mpc8260 tqm8260 tqc - TQM8260:MPC8260,300MHz,BUSMODE_60x
-TQM8260_AG powerpc mpc8260 tqm8260 tqc - TQM8260:MPC8260,300MHz
-TQM8260_AH powerpc mpc8260 tqm8260 tqc - TQM8260:MPC8260,300MHz,L2_CACHE,BUSMODE_60x
-TQM8260_AI powerpc mpc8260 tqm8260 tqc - TQM8260:MPC8260,300MHz,BUSMODE_60x
-TQM8265_AA powerpc mpc8260 tqm8260 tqc - TQM8260:MPC8265,300MHz,BUSMODE_60x
-TQM8272 powerpc mpc8260 tqm8272 tqc
-mpc8308_p1m powerpc mpc83xx
-sbc8349 powerpc mpc83xx sbc8349 - - sbc8349
-sbc8349_PCI_33 powerpc mpc83xx sbc8349 - - sbc8349:PCI,PCI_33M
-sbc8349_PCI_66 powerpc mpc83xx sbc8349 - - sbc8349:PCI,PCI_66M
-ve8313 powerpc mpc83xx ve8313
-caddy2 powerpc mpc83xx vme8349 esd - vme8349:CADDY2
-vme8349 powerpc mpc83xx vme8349 esd - vme8349
-MPC8308RDB powerpc mpc83xx mpc8308rdb freescale
-MPC8313ERDB_33 powerpc mpc83xx mpc8313erdb freescale - MPC8313ERDB:SYS_33MHZ
-MPC8313ERDB_66 powerpc mpc83xx mpc8313erdb freescale - MPC8313ERDB:SYS_66MHZ
-MPC8313ERDB_NAND_33 powerpc mpc83xx mpc8313erdb freescale - MPC8313ERDB:SYS_33MHZ,NAND
-MPC8313ERDB_NAND_66 powerpc mpc83xx mpc8313erdb freescale - MPC8313ERDB:SYS_66MHZ,NAND
-MPC8315ERDB powerpc mpc83xx mpc8315erdb freescale - MPC8315ERDB
-MPC8315ERDB_NAND powerpc mpc83xx mpc8315erdb freescale - MPC8315ERDB:NAND_U_BOOT
-MPC8323ERDB powerpc mpc83xx mpc8323erdb freescale
-MPC832XEMDS powerpc mpc83xx mpc832xemds freescale - MPC832XEMDS:
-MPC832XEMDS_ATM powerpc mpc83xx mpc832xemds freescale - MPC832XEMDS:PQ_MDS_PIB=1,PQ_MDS_PIB_ATM=1
-MPC832XEMDS_HOST_33 powerpc mpc83xx mpc832xemds freescale - MPC832XEMDS:PCI,PCI_33M,PQ_MDS_PIB=1
-MPC832XEMDS_HOST_66 powerpc mpc83xx mpc832xemds freescale - MPC832XEMDS:PCI,PCI_66M,PQ_MDS_PIB=1
-MPC832XEMDS_SLAVE powerpc mpc83xx mpc832xemds freescale - MPC832XEMDS:PCI,PCISLAVE
-MPC8349EMDS powerpc mpc83xx mpc8349emds freescale
-MPC8349ITX powerpc mpc83xx mpc8349itx freescale - MPC8349ITX:MPC8349ITX
-MPC8349ITXGP powerpc mpc83xx mpc8349itx freescale - MPC8349ITX:MPC8349ITXGP,SYS_TEXT_BASE=0xFE000000
-MPC8349ITX_LOWBOOT powerpc mpc83xx mpc8349itx freescale - MPC8349ITX:MPC8349ITX,SYS_TEXT_BASE=0xFE000000
-MPC8360EMDS_33 powerpc mpc83xx mpc8360emds freescale - MPC8360EMDS:CLKIN_33MHZ
-MPC8360EMDS_33_ATM powerpc mpc83xx mpc8360emds freescale - MPC8360EMDS:CLKIN_33MHZ,PQ_MDS_PIB=1,PQ_MDS_PIB_ATM=1
-MPC8360EMDS_33_HOST_33 powerpc mpc83xx mpc8360emds freescale - MPC8360EMDS:CLKIN_33MHZ,PCI,PCI_33M,PQ_MDS_PIB=1
-MPC8360EMDS_33_HOST_66 powerpc mpc83xx mpc8360emds freescale - MPC8360EMDS:CLKIN_33MHZ,PCI,PCI_66M,PQ_MDS_PIB=1
-MPC8360EMDS_33_SLAVE powerpc mpc83xx mpc8360emds freescale - MPC8360EMDS:CLKIN_33MHZ,PCI,PCISLAVE
-MPC8360EMDS_66 powerpc mpc83xx mpc8360emds freescale - MPC8360EMDS:CLKIN_66MHZ
-MPC8360EMDS_66_ATM powerpc mpc83xx mpc8360emds freescale - MPC8360EMDS:CLKIN_66MHZ,PQ_MDS_PIB=1,PQ_MDS_PIB_ATM=1
-MPC8360EMDS_66_HOST_33 powerpc mpc83xx mpc8360emds freescale - MPC8360EMDS:CLKIN_66MHZ,PCI,PCI_33M,PQ_MDS_PIB=1
-MPC8360EMDS_66_HOST_66 powerpc mpc83xx mpc8360emds freescale - MPC8360EMDS:CLKIN_66MHZ,PCI,PCI_66M,PQ_MDS_PIB=1
-MPC8360EMDS_66_SLAVE powerpc mpc83xx mpc8360emds freescale - MPC8360EMDS:CLKIN_66MHZ,PCI,PCISLAVE
-MPC8360ERDK powerpc mpc83xx mpc8360erdk freescale - MPC8360ERDK
-MPC8360ERDK_33 powerpc mpc83xx mpc8360erdk freescale - MPC8360ERDK:CLKIN_33MHZ
-MPC8360ERDK_66 powerpc mpc83xx mpc8360erdk freescale - MPC8360ERDK
-MPC837XEMDS powerpc mpc83xx mpc837xemds freescale - MPC837XEMDS
-MPC837XEMDS_HOST powerpc mpc83xx mpc837xemds freescale - MPC837XEMDS:PCI
-MPC837XERDB powerpc mpc83xx mpc837xerdb freescale
-kmcoge5ne powerpc mpc83xx km83xx keymile - km8360:KMCOGE5NE
-kmeter1 powerpc mpc83xx km83xx keymile - km8360:KMETER1
-MERGERBOX powerpc mpc83xx mergerbox matrix_vision
-MVBLM7 powerpc mpc83xx mvblm7 matrix_vision
-SIMPC8313_LP powerpc mpc83xx simpc8313 sheldon - SIMPC8313:NAND_LP
-SIMPC8313_SP powerpc mpc83xx simpc8313 sheldon - SIMPC8313:NAND_SP
-TQM834x powerpc mpc83xx tqm834x tqc
-suvd3 powerpc mpc83xx km83xx keymile - suvd3:SUVD3
-kmvect1 powerpc mpc83xx km83xx keymile - suvd3:KMVECT1
-tuge1 powerpc mpc83xx km83xx keymile - tuxx1:TUGE1
-tuxx1 powerpc mpc83xx km83xx keymile - tuxx1:TUXX1
-kmopti2 powerpc mpc83xx km83xx keymile - tuxx1:KMOPTI2
-kmsupx5 powerpc mpc83xx km83xx keymile - tuxx1:KMSUPX5
-sbc8548 powerpc mpc85xx sbc8548 - - sbc8548
-sbc8548_PCI_33 powerpc mpc85xx sbc8548 - - sbc8548:PCI,33
-sbc8548_PCI_33_PCIE powerpc mpc85xx sbc8548 - - sbc8548:PCI,33,PCIE
-sbc8548_PCI_66 powerpc mpc85xx sbc8548 - - sbc8548:PCI,66
-sbc8548_PCI_66_PCIE powerpc mpc85xx sbc8548 - - sbc8548:PCI,66,PCIE
-socrates powerpc mpc85xx socrates
-HWW1U1A powerpc mpc85xx hww1u1a exmeritus
-MPC8536DS powerpc mpc85xx mpc8536ds freescale - MPC8536DS
-MPC8536DS_36BIT powerpc mpc85xx mpc8536ds freescale - MPC8536DS:36BIT
-MPC8536DS_NAND powerpc mpc85xx mpc8536ds freescale - MPC8536DS:NAND
-MPC8536DS_SDCARD powerpc mpc85xx mpc8536ds freescale - MPC8536DS:SDCARD
-MPC8536DS_SPIFLASH powerpc mpc85xx mpc8536ds freescale - MPC8536DS:SPIFLASH
-MPC8540ADS powerpc mpc85xx mpc8540ads freescale
-MPC8541CDS powerpc mpc85xx mpc8541cds freescale - MPC8541CDS
-MPC8541CDS_legacy powerpc mpc85xx mpc8541cds freescale - MPC8541CDS:LEGACY
-MPC8544DS powerpc mpc85xx mpc8544ds freescale
-MPC8548CDS powerpc mpc85xx mpc8548cds freescale - MPC8548CDS
-MPC8548CDS_36BIT powerpc mpc85xx mpc8548cds freescale - MPC8548CDS:36BIT
-MPC8548CDS_legacy powerpc mpc85xx mpc8548cds freescale - MPC8548CDS:LEGACY
-MPC8555CDS powerpc mpc85xx mpc8555cds freescale - MPC8555CDS
-MPC8555CDS_legacy powerpc mpc85xx mpc8555cds freescale - MPC8555CDS:LEGACY
-MPC8560ADS powerpc mpc85xx mpc8560ads freescale
-MPC8568MDS powerpc mpc85xx mpc8568mds freescale
-MPC8569MDS powerpc mpc85xx mpc8569mds freescale - MPC8569MDS
-MPC8569MDS_ATM powerpc mpc85xx mpc8569mds freescale - MPC8569MDS:ATM
-MPC8569MDS_NAND powerpc mpc85xx mpc8569mds freescale - MPC8569MDS:NAND
-MPC8572DS powerpc mpc85xx mpc8572ds freescale - MPC8572DS
-MPC8572DS_36BIT powerpc mpc85xx mpc8572ds freescale - MPC8572DS:36BIT
-MPC8572DS_NAND powerpc mpc85xx mpc8572ds freescale - MPC8572DS:NAND
-P1010RDB_36BIT_NAND powerpc mpc85xx p1010rdb freescale - P1010RDB:P1010RDB,36BIT,NAND
-P1010RDB_36BIT_NAND_SECBOOT powerpc mpc85xx p1010rdb freescale - P1010RDB:P1010RDB,36BIT,NAND_SECBOOT,SECURE_BOOT
-P1010RDB_36BIT_NOR powerpc mpc85xx p1010rdb freescale - P1010RDB:P1010RDB,36BIT
-P1010RDB_36BIT_NOR_SECBOOT powerpc mpc85xx p1010rdb freescale - P1010RDB:P1010RDB,36BIT,SECURE_BOOT
-P1010RDB_36BIT_SDCARD powerpc mpc85xx p1010rdb freescale - P1010RDB:P1010RDB,36BIT,SDCARD
-P1010RDB_36BIT_SPIFLASH powerpc mpc85xx p1010rdb freescale - P1010RDB:P1010RDB,36BIT,SPIFLASH
-P1010RDB_36BIT_SPIFLASH_SECBOOT powerpc mpc85xx p1010rdb freescale - P1010RDB:P1010RDB,36BIT,SPIFLASH,SECURE_BOOT
-P1010RDB_NAND powerpc mpc85xx p1010rdb freescale - P1010RDB:P1010RDB,NAND
-P1010RDB_NAND_SECBOOT powerpc mpc85xx p1010rdb freescale - P1010RDB:P1010RDB,NAND_SECBOOT,SECURE_BOOT
-P1010RDB_NOR powerpc mpc85xx p1010rdb freescale - P1010RDB:P1010RDB
-P1010RDB_NOR_SECBOOT powerpc mpc85xx p1010rdb freescale - P1010RDB:P1010RDB,SECURE_BOOT
-P1010RDB_SDCARD powerpc mpc85xx p1010rdb freescale - P1010RDB:P1010RDB,SDCARD
-P1010RDB_SPIFLASH powerpc mpc85xx p1010rdb freescale - P1010RDB:P1010RDB,SPIFLASH
-P1010RDB_SPIFLASH_SECBOOT powerpc mpc85xx p1010rdb freescale - P1010RDB:P1010RDB,SPIFLASH,SECURE_BOOT
-P1011RDB powerpc mpc85xx p1_p2_rdb freescale - P1_P2_RDB:P1011RDB
-P1011RDB_36BIT powerpc mpc85xx p1_p2_rdb freescale - P1_P2_RDB:P1011RDB,36BIT
-P1011RDB_36BIT_SDCARD powerpc mpc85xx p1_p2_rdb freescale - P1_P2_RDB:P1011RDB,36BIT,SDCARD
-P1011RDB_36BIT_SPIFLASH powerpc mpc85xx p1_p2_rdb freescale - P1_P2_RDB:P1011RDB,36BIT,SPIFLASH
-P1011RDB_NAND powerpc mpc85xx p1_p2_rdb freescale - P1_P2_RDB:P1011RDB,NAND
-P1011RDB_SDCARD powerpc mpc85xx p1_p2_rdb freescale - P1_P2_RDB:P1011RDB,SDCARD
-P1011RDB_SPIFLASH powerpc mpc85xx p1_p2_rdb freescale - P1_P2_RDB:P1011RDB,SPIFLASH
-P1020MBG-PC powerpc mpc85xx p1_p2_rdb_pc freescale - p1_p2_rdb_pc:P1020MBG
-P1020MBG-PC_36BIT powerpc mpc85xx p1_p2_rdb_pc freescale - p1_p2_rdb_pc:P1020MBG,36BIT
-P1020MBG-PC_36BIT_SDCARD powerpc mpc85xx p1_p2_rdb_pc freescale - p1_p2_rdb_pc:P1020MBG,SDCARD,36BIT
-P1020MBG-PC_SDCARD powerpc mpc85xx p1_p2_rdb_pc freescale - p1_p2_rdb_pc:P1020MBG,SDCARD
-P1020RDB powerpc mpc85xx p1_p2_rdb freescale - P1_P2_RDB:P1020RDB
-P1020RDB_36BIT powerpc mpc85xx p1_p2_rdb freescale - P1_P2_RDB:P1020RDB,36BIT
-P1020RDB_36BIT_SDCARD powerpc mpc85xx p1_p2_rdb freescale - P1_P2_RDB:P1020RDB,36BIT,SDCARD
-P1020RDB_36BIT_SPIFLASH powerpc mpc85xx p1_p2_rdb freescale - P1_P2_RDB:P1020RDB,36BIT,SPIFLASH
-P1020RDB_NAND powerpc mpc85xx p1_p2_rdb freescale - P1_P2_RDB:P1020RDB,NAND
-P1020RDB-PC powerpc mpc85xx p1_p2_rdb_pc freescale - p1_p2_rdb_pc:P1020RDB
-P1020RDB-PC_36BIT powerpc mpc85xx p1_p2_rdb_pc freescale - p1_p2_rdb_pc:P1020RDB,36BIT
-P1020RDB-PC_36BIT_NAND powerpc mpc85xx p1_p2_rdb_pc freescale - p1_p2_rdb_pc:P1020RDB,36BIT,NAND
-P1020RDB-PC_36BIT_SDCARD powerpc mpc85xx p1_p2_rdb_pc freescale - p1_p2_rdb_pc:P1020RDB,36BIT,SDCARD
-P1020RDB-PC_36BIT_SPIFLASH powerpc mpc85xx p1_p2_rdb_pc freescale - p1_p2_rdb_pc:P1020RDB,36BIT,SPIFLASH
-P1020RDB-PC_NAND powerpc mpc85xx p1_p2_rdb_pc freescale - p1_p2_rdb_pc:P1020RDB,NAND
-P1020RDB-PC_SDCARD powerpc mpc85xx p1_p2_rdb_pc freescale - p1_p2_rdb_pc:P1020RDB,SDCARD
-P1020RDB-PC_SPIFLASH powerpc mpc85xx p1_p2_rdb_pc freescale - p1_p2_rdb_pc:P1020RDB,SPIFLASH
-P1020RDB_SDCARD powerpc mpc85xx p1_p2_rdb freescale - P1_P2_RDB:P1020RDB,SDCARD
-P1020RDB_SPIFLASH powerpc mpc85xx p1_p2_rdb freescale - P1_P2_RDB:P1020RDB,SPIFLASH
-P1020UTM-PC powerpc mpc85xx p1_p2_rdb_pc freescale - p1_p2_rdb_pc:P1020UTM
-P1020UTM-PC_36BIT powerpc mpc85xx p1_p2_rdb_pc freescale - p1_p2_rdb_pc:P1020UTM,36BIT
-P1020UTM-PC_36BIT_SDCARD powerpc mpc85xx p1_p2_rdb_pc freescale - p1_p2_rdb_pc:P1020UTM,36BIT,SDCARD
-P1020UTM-PC_SDCARD powerpc mpc85xx p1_p2_rdb_pc freescale - p1_p2_rdb_pc:P1020UTM,SDCARD
-P1021RDB-PC powerpc mpc85xx p1_p2_rdb_pc freescale - p1_p2_rdb_pc:P1021RDB
-P1021RDB-PC_36BIT powerpc mpc85xx p1_p2_rdb_pc freescale - p1_p2_rdb_pc:P1021RDB,36BIT
-P1021RDB-PC_36BIT_NAND powerpc mpc85xx p1_p2_rdb_pc freescale - p1_p2_rdb_pc:P1021RDB,36BIT,NAND
-P1021RDB-PC_36BIT_SDCARD powerpc mpc85xx p1_p2_rdb_pc freescale - p1_p2_rdb_pc:P1021RDB,36BIT,SDCARD
-P1021RDB-PC_36BIT_SPIFLASH powerpc mpc85xx p1_p2_rdb_pc freescale - p1_p2_rdb_pc:P1021RDB,36BIT,SPIFLASH
-P1021RDB-PC_NAND powerpc mpc85xx p1_p2_rdb_pc freescale - p1_p2_rdb_pc:P1021RDB,NAND
-P1021RDB-PC_SDCARD powerpc mpc85xx p1_p2_rdb_pc freescale - p1_p2_rdb_pc:P1021RDB,SDCARD
-P1021RDB-PC_SPIFLASH powerpc mpc85xx p1_p2_rdb_pc freescale - p1_p2_rdb_pc:P1021RDB,SPIFLASH
-P1022DS powerpc mpc85xx p1022ds freescale
-P1022DS_NAND powerpc mpc85xx p1022ds freescale - P1022DS:NAND
-P1022DS_36BIT_NAND powerpc mpc85xx p1022ds freescale - P1022DS:36BIT,NAND
-P1022DS_SPIFLASH powerpc mpc85xx p1022ds freescale - P1022DS:SPIFLASH
-P1022DS_36BIT_SPIFLASH powerpc mpc85xx p1022ds freescale - P1022DS:36BIT,SPIFLASH
-P1022DS_SDCARD powerpc mpc85xx p1022ds freescale - P1022DS:SDCARD
-P1022DS_36BIT_SDCARD powerpc mpc85xx p1022ds freescale - P1022DS:36BIT,SDCARD
-P1022DS_36BIT powerpc mpc85xx p1022ds freescale - P1022DS:36BIT
-P1023RDB powerpc mpc85xx p1023rdb freescale - P1023RDB
-P1023RDS powerpc mpc85xx p1023rds freescale - P1023RDS
-P1023RDS_NAND powerpc mpc85xx p1023rds freescale - P1023RDS:NAND
-P1024RDB powerpc mpc85xx p1_p2_rdb_pc freescale - p1_p2_rdb_pc:P1024RDB
-P1024RDB_36BIT powerpc mpc85xx p1_p2_rdb_pc freescale - p1_p2_rdb_pc:P1024RDB,36BIT
-P1024RDB_NAND powerpc mpc85xx p1_p2_rdb_pc freescale - p1_p2_rdb_pc:P1024RDB,NAND
-P1024RDB_SDCARD powerpc mpc85xx p1_p2_rdb_pc freescale - p1_p2_rdb_pc:P1024RDB,SDCARD
-P1024RDB_SPIFLASH powerpc mpc85xx p1_p2_rdb_pc freescale - p1_p2_rdb_pc:P1024RDB,SPIFLASH
-P1025RDB powerpc mpc85xx p1_p2_rdb_pc freescale - p1_p2_rdb_pc:P1025RDB
-P1025RDB_36BIT powerpc mpc85xx p1_p2_rdb_pc freescale - p1_p2_rdb_pc:P1025RDB,36BIT
-P1025RDB_NAND powerpc mpc85xx p1_p2_rdb_pc freescale - p1_p2_rdb_pc:P1025RDB,NAND
-P1025RDB_SDCARD powerpc mpc85xx p1_p2_rdb_pc freescale - p1_p2_rdb_pc:P1025RDB,SDCARD
-P1025RDB_SPIFLASH powerpc mpc85xx p1_p2_rdb_pc freescale - p1_p2_rdb_pc:P1025RDB,SPIFLASH
-P2010RDB powerpc mpc85xx p1_p2_rdb freescale - P1_P2_RDB:P2010RDB
-P2010RDB_36BIT powerpc mpc85xx p1_p2_rdb freescale - P1_P2_RDB:P2010RDB,36BIT
-P2010RDB_36BIT_SDCARD powerpc mpc85xx p1_p2_rdb freescale - P1_P2_RDB:P2010RDB,36BIT,SDCARD
-P2010RDB_36BIT_SPIFLASH powerpc mpc85xx p1_p2_rdb freescale - P1_P2_RDB:P2010RDB,36BIT,SPIFLASH
-P2010RDB_NAND powerpc mpc85xx p1_p2_rdb freescale - P1_P2_RDB:P2010RDB,NAND
-P2010RDB_SDCARD powerpc mpc85xx p1_p2_rdb freescale - P1_P2_RDB:P2010RDB,SDCARD
-P2010RDB_SPIFLASH powerpc mpc85xx p1_p2_rdb freescale - P1_P2_RDB:P2010RDB,SPIFLASH
-P2020COME_SDCARD powerpc mpc85xx p2020come freescale - P2020COME:SDCARD
-P2020COME_SPIFLASH powerpc mpc85xx p2020come freescale - P2020COME:SPIFLASH
-P2020DS powerpc mpc85xx p2020ds freescale
-P2020DS_36BIT powerpc mpc85xx p2020ds freescale - P2020DS:36BIT
-P2020DS_DDR2 powerpc mpc85xx p2020ds freescale - P2020DS:DDR2
-P2020DS_SDCARD powerpc mpc85xx p2020ds freescale - P2020DS:SDCARD
-P2020DS_SPIFLASH powerpc mpc85xx p2020ds freescale - P2020DS:SPIFLASH
-P2020RDB powerpc mpc85xx p1_p2_rdb freescale - P1_P2_RDB:P2020RDB
-P2020RDB_36BIT powerpc mpc85xx p1_p2_rdb freescale - P1_P2_RDB:P2020RDB,36BIT
-P2020RDB_36BIT_SDCARD powerpc mpc85xx p1_p2_rdb freescale - P1_P2_RDB:P2020RDB,36BIT,SDCARD
-P2020RDB_36BIT_SPIFLASH powerpc mpc85xx p1_p2_rdb freescale - P1_P2_RDB:P2020RDB,36BIT,SPIFLASH
-P2020RDB_NAND powerpc mpc85xx p1_p2_rdb freescale - P1_P2_RDB:P2020RDB,NAND
-P2020RDB-PC powerpc mpc85xx p1_p2_rdb_pc freescale - p1_p2_rdb_pc:P2020RDB
-P2020RDB-PC_36BIT powerpc mpc85xx p1_p2_rdb_pc freescale - p1_p2_rdb_pc:P2020RDB,36BIT
-P2020RDB-PC_36BIT_NAND powerpc mpc85xx p1_p2_rdb_pc freescale - p1_p2_rdb_pc:P2020RDB,36BIT,NAND
-P2020RDB-PC_36BIT_SDCARD powerpc mpc85xx p1_p2_rdb_pc freescale - p1_p2_rdb_pc:P2020RDB,36BIT,SDCARD
-P2020RDB-PC_36BIT_SPIFLASH powerpc mpc85xx p1_p2_rdb_pc freescale - p1_p2_rdb_pc:P2020RDB,36BIT,SPIFLASH
-P2020RDB-PC_NAND powerpc mpc85xx p1_p2_rdb_pc freescale - p1_p2_rdb_pc:P2020RDB,NAND
-P2020RDB-PC_SDCARD powerpc mpc85xx p1_p2_rdb_pc freescale - p1_p2_rdb_pc:P2020RDB,SDCARD
-P2020RDB-PC_SPIFLASH powerpc mpc85xx p1_p2_rdb_pc freescale - p1_p2_rdb_pc:P2020RDB,SPIFLASH
-P2020RDB_SDCARD powerpc mpc85xx p1_p2_rdb freescale - P1_P2_RDB:P2020RDB,SDCARD
-P2020RDB_SPIFLASH powerpc mpc85xx p1_p2_rdb freescale - P1_P2_RDB:P2020RDB,SPIFLASH
-P2041RDB powerpc mpc85xx p2041rdb freescale
-P2041RDB_NAND powerpc mpc85xx p2041rdb freescale - P2041RDB:RAMBOOT_PBL,NAND,SYS_TEXT_BASE=0xFFF80000
-P2041RDB_SDCARD powerpc mpc85xx p2041rdb freescale - P2041RDB:RAMBOOT_PBL,SDCARD,SYS_TEXT_BASE=0xFFF80000
-P2041RDB_SECURE_BOOT powerpc mpc85xx p2041rdb freescale - P2041RDB:SECURE_BOOT
-P2041RDB_SPIFLASH powerpc mpc85xx p2041rdb freescale - P2041RDB:RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF80000
-P2041RDB_SRIO_PCIE_BOOT powerpc mpc85xx p2041rdb freescale - P2041RDB:SRIO_PCIE_BOOT_SLAVE,SYS_TEXT_BASE=0xFFF80000
-P3041DS powerpc mpc85xx corenet_ds freescale
-P3041DS_NAND powerpc mpc85xx corenet_ds freescale - P3041DS:RAMBOOT_PBL,NAND,SYS_TEXT_BASE=0xFFF80000
-P3041DS_SDCARD powerpc mpc85xx corenet_ds freescale - P3041DS:RAMBOOT_PBL,SDCARD,SYS_TEXT_BASE=0xFFF80000
-P3041DS_SECURE_BOOT powerpc mpc85xx corenet_ds freescale - P3041DS:SECURE_BOOT
-P3041DS_SPIFLASH powerpc mpc85xx corenet_ds freescale - P3041DS:RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF80000
-P3041DS_SRIO_PCIE_BOOT powerpc mpc85xx corenet_ds freescale - P3041DS:SRIO_PCIE_BOOT_SLAVE,SYS_TEXT_BASE=0xFFF80000
-P4080DS powerpc mpc85xx corenet_ds freescale
-P4080DS_SDCARD powerpc mpc85xx corenet_ds freescale - P4080DS:RAMBOOT_PBL,SDCARD,SYS_TEXT_BASE=0xFFF80000
-P4080DS_SECURE_BOOT powerpc mpc85xx corenet_ds freescale - P4080DS:SECURE_BOOT
-P4080DS_SPIFLASH powerpc mpc85xx corenet_ds freescale - P4080DS:RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF80000
-P4080DS_SRIO_PCIE_BOOT powerpc mpc85xx corenet_ds freescale - P4080DS:SRIO_PCIE_BOOT_SLAVE,SYS_TEXT_BASE=0xFFF80000
-P5020DS powerpc mpc85xx corenet_ds freescale
-P5020DS_NAND powerpc mpc85xx corenet_ds freescale - P5020DS:RAMBOOT_PBL,NAND,SYS_TEXT_BASE=0xFFF80000
-P5020DS_SDCARD powerpc mpc85xx corenet_ds freescale - P5020DS:RAMBOOT_PBL,SDCARD,SYS_TEXT_BASE=0xFFF80000
-P5020DS_SECURE_BOOT powerpc mpc85xx corenet_ds freescale - P5020DS:SECURE_BOOT
-P5020DS_SPIFLASH powerpc mpc85xx corenet_ds freescale - P5020DS:RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF80000
-P5020DS_SRIO_PCIE_BOOT powerpc mpc85xx corenet_ds freescale - P5020DS:SRIO_PCIE_BOOT_SLAVE,SYS_TEXT_BASE=0xFFF80000
-P5040DS powerpc mpc85xx corenet_ds freescale
-P5040DS_NAND powerpc mpc85xx corenet_ds freescale - P5040DS:RAMBOOT_PBL,NAND,SYS_TEXT_BASE=0xFFF80000
-P5040DS_SDCARD powerpc mpc85xx corenet_ds freescale - P5040DS:RAMBOOT_PBL,SDCARD,SYS_TEXT_BASE=0xFFF80000
-P5040DS_SPIFLASH powerpc mpc85xx corenet_ds freescale - P5040DS:RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF80000
-BSC9131RDB_SPIFLASH powerpc mpc85xx bsc9131rdb freescale - BSC9131RDB:BSC9131RDB,SPIFLASH
-BSC9131RDB_SPIFLASH_SYSCLK100 powerpc mpc85xx bsc9131rdb freescale - BSC9131RDB:BSC9131RDB,SPIFLASH,SYS_CLK_100
-BSC9131RDB_NAND powerpc mpc85xx bsc9131rdb freescale - BSC9131RDB:BSC9131RDB,NAND
-BSC9131RDB_NAND_SYSCLK100 powerpc mpc85xx bsc9131rdb freescale - BSC9131RDB:BSC9131RDB,NAND,SYS_CLK_100
-BSC9132QDS_NOR_DDRCLK100 powerpc mpc85xx bsc9132qds freescale - BSC9132QDS:BSC9132QDS,SYS_CLK_100_DDR_100
-BSC9132QDS_NOR_DDRCLK133 powerpc mpc85xx bsc9132qds freescale - BSC9132QDS:BSC9132QDS,SYS_CLK_100_DDR_133
-BSC9132QDS_NAND_DDRCLK100 powerpc mpc85xx bsc9132qds freescale - BSC9132QDS:BSC9132QDS,NAND,SYS_CLK_100_DDR_100
-BSC9132QDS_NAND_DDRCLK133 powerpc mpc85xx bsc9132qds freescale - BSC9132QDS:BSC9132QDS,NAND,SYS_CLK_100_DDR_133
-BSC9132QDS_SDCARD_DDRCLK100 powerpc mpc85xx bsc9132qds freescale - BSC9132QDS:BSC9132QDS,SDCARD,SYS_CLK_100_DDR_100
-BSC9132QDS_SDCARD_DDRCLK133 powerpc mpc85xx bsc9132qds freescale - BSC9132QDS:BSC9132QDS,SDCARD,SYS_CLK_100_DDR_133
-BSC9132QDS_SPIFLASH_DDRCLK100 powerpc mpc85xx bsc9132qds freescale - BSC9132QDS:BSC9132QDS,SPIFLASH,SYS_CLK_100_DDR_100
-BSC9132QDS_SPIFLASH_DDRCLK133 powerpc mpc85xx bsc9132qds freescale - BSC9132QDS:BSC9132QDS,SPIFLASH,SYS_CLK_100_DDR_133
-controlcenterd_36BIT_SDCARD powerpc mpc85xx p1022 gdsys - controlcenterd:36BIT,SDCARD
-controlcenterd_36BIT_SDCARD_DEVELOP powerpc mpc85xx p1022 gdsys - controlcenterd:36BIT,SDCARD,DEVELOP
-controlcenterd_TRAILBLAZER powerpc mpc85xx p1022 gdsys - controlcenterd:TRAILBLAZER,SPIFLASH
-controlcenterd_TRAILBLAZER_DEVELOP powerpc mpc85xx p1022 gdsys - controlcenterd:TRAILBLAZER,SPIFLASH,DEVELOP
-stxgp3 powerpc mpc85xx stxgp3 stx
-stxssa powerpc mpc85xx stxssa stx - stxssa
-stxssa_4M powerpc mpc85xx stxssa stx - stxssa:STXSSA_4M
-T4240QDS powerpc mpc85xx t4qds freescale - T4240QDS:PPC_T4240
-T4240QDS_SDCARD powerpc mpc85xx t4qds freescale - T4240QDS:PPC_T4240,RAMBOOT_PBL,SDCARD,SYS_TEXT_BASE=0xFFF80000
-T4240QDS_SPIFLASH powerpc mpc85xx t4qds freescale - T4240QDS:PPC_T4240,RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF80000
-T4240QDS_SRIO_PCIE_BOOT powerpc mpc85xx t4qds freescale - T4240QDS:PPC_T4240,SRIO_PCIE_BOOT_SLAVE,SYS_TEXT_BASE=0xFFF80000
-T4160QDS powerpc mpc85xx t4qds freescale - T4240QDS:PPC_T4160
-T4160QDS_SDCARD powerpc mpc85xx t4qds freescale - T4240QDS:PPC_T4160,RAMBOOT_PBL,SDCARD,SYS_TEXT_BASE=0xFFF80000
-T4160QDS_SPIFLASH powerpc mpc85xx t4qds freescale - T4240QDS:PPC_T4160,RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF80000
-B4860QDS powerpc mpc85xx b4860qds freescale - B4860QDS:PPC_B4860
-B4860QDS_NAND powerpc mpc85xx b4860qds freescale - B4860QDS:PPC_B4860,RAMBOOT_PBL,NAND,SYS_TEXT_BASE=0xFFF80000
-B4860QDS_SPIFLASH powerpc mpc85xx b4860qds freescale - B4860QDS:PPC_B4860,RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF80000
-B4860QDS_SRIO_PCIE_BOOT powerpc mpc85xx b4860qds freescale - B4860QDS:PPC_B4860,SRIO_PCIE_BOOT_SLAVE,SYS_TEXT_BASE=0xFFF80000
-B4420QDS powerpc mpc85xx b4860qds freescale - B4860QDS:PPC_B4420
-B4420QDS_NAND powerpc mpc85xx b4860qds freescale - B4860QDS:PPC_B4420,RAMBOOT_PBL,NAND,SYS_TEXT_BASE=0xFFF80000
-B4420QDS_SPIFLASH powerpc mpc85xx b4860qds freescale - B4860QDS:PPC_B4420,RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF80000
-xpedite520x powerpc mpc85xx - xes
-xpedite537x powerpc mpc85xx - xes
-xpedite550x powerpc mpc85xx - xes
-sbc8641d powerpc mpc86xx
-MPC8610HPCD powerpc mpc86xx mpc8610hpcd freescale
-MPC8641HPCN powerpc mpc86xx mpc8641hpcn freescale - MPC8641HPCN
-MPC8641HPCN_36BIT powerpc mpc86xx mpc8641hpcn freescale - MPC8641HPCN:PHYS_64BIT
-xpedite517x powerpc mpc86xx - xes
-Adder powerpc mpc8xx adder
-Adder87x powerpc mpc8xx adder - - Adder
-AdderII powerpc mpc8xx adder - - Adder:MPC852T
-AdderUSB powerpc mpc8xx adder - - Adder
-ADS860 powerpc mpc8xx fads
-cogent_mpc8xx powerpc mpc8xx cogent
-ESTEEM192E powerpc mpc8xx esteem192e
-FADS823 powerpc mpc8xx fads
-FADS850SAR powerpc mpc8xx fads
-FADS860T powerpc mpc8xx fads
-FLAGADM powerpc mpc8xx flagadm
-GEN860T powerpc mpc8xx gen860t
-GEN860T_SC powerpc mpc8xx gen860t - - GEN860T:SC
-GENIETV powerpc mpc8xx genietv
-hermes powerpc mpc8xx
-ICU862 powerpc mpc8xx icu862
-ICU862_100MHz powerpc mpc8xx icu862 - - ICU862:100MHz
-IP860 powerpc mpc8xx ip860
-IVML24 powerpc mpc8xx ivm - - IVML24:IVML24_16M
-IVML24_128 powerpc mpc8xx ivm - - IVML24:IVML24_32M
-IVML24_256 powerpc mpc8xx ivm - - IVML24:IVML24_64M
-IVMS8 powerpc mpc8xx ivm - - IVMS8:IVMS8_16M
-IVMS8_128 powerpc mpc8xx ivm - - IVMS8:IVMS8_32M
-IVMS8_256 powerpc mpc8xx ivm - - IVMS8:IVMS8_64M
-lwmon powerpc mpc8xx
-MBX powerpc mpc8xx mbx8xx
-MBX860T powerpc mpc8xx mbx8xx
-MPC86xADS powerpc mpc8xx fads
-MPC885ADS powerpc mpc8xx fads
-NETPHONE powerpc mpc8xx netphone - - NETPHONE:NETPHONE_VERSION=1
-NETPHONE_V2 powerpc mpc8xx netphone - - NETPHONE:NETPHONE_VERSION=2
-NETTA powerpc mpc8xx netta - - NETTA
-NETTA2 powerpc mpc8xx netta2 - - NETTA2:NETTA2_VERSION=1
-NETTA2_V2 powerpc mpc8xx netta2 - - NETTA2:NETTA2_VERSION=2
-NETTA_6412 powerpc mpc8xx netta - - NETTA:NETTA_6412=1
-NETTA_6412_SWAPHOOK powerpc mpc8xx netta - - NETTA:NETTA_6412=1,NETTA_SWAPHOOK=1
-NETTA_ISDN powerpc mpc8xx netta - - NETTA:NETTA_ISDN=1
-NETTA_ISDN_6412 powerpc mpc8xx netta - - NETTA:NETTA_ISDN=1,NETTA_6412=1
-NETTA_ISDN_6412_SWAPHOOK powerpc mpc8xx netta - - NETTA:NETTA_ISDN=1,NETTA_6412=1,NETTA_SWAPHOOK=1
-NETTA_ISDN_SWAPHOOK powerpc mpc8xx netta - - NETTA:NETTA_ISDN=1,NETTA_SWAPHOOK=1
-NETTA_SWAPHOOK powerpc mpc8xx netta - - NETTA:NETTA_SWAPHOOK=1
-NETVIA powerpc mpc8xx netvia - - NETVIA:NETVIA_VERSION=1
-NETVIA_V2 powerpc mpc8xx netvia - - NETVIA:NETVIA_VERSION=2
-NX823 powerpc mpc8xx nx823
-quantum powerpc mpc8xx
-R360MPI powerpc mpc8xx r360mpi
-RBC823 powerpc mpc8xx rbc823
-RPXClassic powerpc mpc8xx
-RPXlite powerpc mpc8xx
-RPXlite_DW powerpc mpc8xx RPXlite_dw - - RPXlite_DW
-RPXlite_DW_64 powerpc mpc8xx RPXlite_dw - - RPXlite_DW:RPXlite_64MHz
-RPXlite_DW_64_LCD powerpc mpc8xx RPXlite_dw - - RPXlite_DW:RPXlite_64MHz,LCD,NEC_NL6448BC20
-RPXlite_DW_LCD powerpc mpc8xx RPXlite_dw - - RPXlite_DW:LCD,NEC_NL6448BC20
-RPXlite_DW_NVRAM powerpc mpc8xx RPXlite_dw - - RPXlite_DW:ENV_IS_IN_NVRAM
-RPXlite_DW_NVRAM_64 powerpc mpc8xx RPXlite_dw - - RPXlite_DW:RPXlite_64MHz,ENV_IS_IN_NVRAM
-RPXlite_DW_NVRAM_64_LCD powerpc mpc8xx RPXlite_dw - - RPXlite_DW:RPXlite_64MHz,LCD,NEC_NL6448BC20,ENV_IS_IN_NVRAM
-RPXlite_DW_NVRAM_LCD powerpc mpc8xx RPXlite_dw - - RPXlite_DW:LCD,NEC_NL6448BC20,ENV_IS_IN_NVRAM
-RRvision powerpc mpc8xx
-RRvision_LCD powerpc mpc8xx RRvision - - RRvision:LCD,SHARP_LQ104V7DS01
-spc1920 powerpc mpc8xx
-SPD823TS powerpc mpc8xx spd8xx
-svm_sc8xx powerpc mpc8xx
-SXNI855T powerpc mpc8xx sixnet
-v37 powerpc mpc8xx
-MHPC powerpc mpc8xx mhpc eltec
-TOP860 powerpc mpc8xx top860 emk
-KUP4K powerpc mpc8xx kup4k kup
-KUP4X powerpc mpc8xx kup4x kup
-ELPT860 powerpc mpc8xx elpt860 LEOX
-uc100 powerpc mpc8xx - manroland
-QS823 powerpc mpc8xx qs850 snmc
-QS850 powerpc mpc8xx qs850 snmc
-QS860T powerpc mpc8xx qs860t snmc
-stxxtc powerpc mpc8xx stxxtc stx
-FPS850L powerpc mpc8xx tqm8xx tqc
-FPS860L powerpc mpc8xx tqm8xx tqc
-NSCU powerpc mpc8xx tqm8xx tqc
-SM850 powerpc mpc8xx tqm8xx tqc
-TK885D powerpc mpc8xx tqm8xx tqc
-TQM823L powerpc mpc8xx tqm8xx tqc
-TQM823L_LCD powerpc mpc8xx tqm8xx tqc - TQM823L:LCD,NEC_NL6448BC20
-TQM823M powerpc mpc8xx tqm8xx tqc
-TQM850L powerpc mpc8xx tqm8xx tqc
-TQM850M powerpc mpc8xx tqm8xx tqc
-TQM855L powerpc mpc8xx tqm8xx tqc
-TQM855M powerpc mpc8xx tqm8xx tqc
-TQM860L powerpc mpc8xx tqm8xx tqc
-TQM860M powerpc mpc8xx tqm8xx tqc
-TQM862L powerpc mpc8xx tqm8xx tqc
-TQM862M powerpc mpc8xx tqm8xx tqc
-TQM866M powerpc mpc8xx tqm8xx tqc
-TQM885D powerpc mpc8xx tqm8xx tqc
-TTTech powerpc mpc8xx tqm8xx tqc - TQM823L:LCD,SHARP_LQ104V7DS01
-virtlab2 powerpc mpc8xx tqm8xx tqc
-wtk powerpc mpc8xx tqm8xx tqc - TQM823L:LCD,SHARP_LQ065T9DR51U
-csb272 powerpc ppc4xx
-csb472 powerpc ppc4xx
-G2000 powerpc ppc4xx g2000
-JSE powerpc ppc4xx jse
-korat powerpc ppc4xx
-korat_perm powerpc ppc4xx korat - - korat:KORAT_PERMANENT
-lwmon5 powerpc ppc4xx
-lcd4_lwmon5 powerpc ppc4xx lwmon5 - - lwmon5:LCD4_LWMON5
-pcs440ep powerpc ppc4xx
-quad100hd powerpc ppc4xx
-sbc405 powerpc ppc4xx
-sc3 powerpc ppc4xx
-t3corp powerpc ppc4xx
-W7OLMC powerpc ppc4xx w7o
-W7OLMG powerpc ppc4xx w7o
-zeus powerpc ppc4xx
-acadia powerpc ppc4xx - amcc
-acadia_nand powerpc ppc4xx acadia amcc - acadia:NAND_U_BOOT,SYS_TEXT_BASE=0x01000000
-arches powerpc ppc4xx canyonlands amcc - canyonlands:ARCHES
-bamboo powerpc ppc4xx - amcc
-bamboo_nand powerpc ppc4xx bamboo amcc - bamboo:NAND_U_BOOT,SYS_TEXT_BASE=0x01000000
-bluestone powerpc ppc4xx - amcc
-bubinga powerpc ppc4xx - amcc
-canyonlands powerpc ppc4xx canyonlands amcc - canyonlands:CANYONLANDS
-canyonlands_nand powerpc ppc4xx canyonlands amcc - canyonlands:CANYONLANDS,NAND_U_BOOT,SYS_TEXT_BASE=0x01000000
-ebony powerpc ppc4xx - amcc
-glacier powerpc ppc4xx canyonlands amcc - canyonlands:GLACIER
-glacier_nand powerpc ppc4xx canyonlands amcc - canyonlands:GLACIER,NAND_U_BOOT,SYS_TEXT_BASE=0x01000000
-haleakala powerpc ppc4xx kilauea amcc - kilauea:HALEAKALA
-haleakala_nand powerpc ppc4xx kilauea amcc - kilauea:NAND_U_BOOT,SYS_TEXT_BASE=0x01000000
-katmai powerpc ppc4xx - amcc
-kilauea powerpc ppc4xx kilauea amcc - kilauea:KILAUEA
-kilauea_nand powerpc ppc4xx kilauea amcc - kilauea:NAND_U_BOOT,SYS_TEXT_BASE=0x01000000
-luan powerpc ppc4xx - amcc
-makalu powerpc ppc4xx - amcc
-ocotea powerpc ppc4xx - amcc
-rainier powerpc ppc4xx sequoia amcc - sequoia:RAINIER
-rainier_nand powerpc ppc4xx sequoia amcc - sequoia:RAINIER,NAND_U_BOOT,SYS_TEXT_BASE=0x01000000
-rainier_ramboot powerpc ppc4xx sequoia amcc - sequoia:RAINIER,SYS_RAMBOOT,SYS_TEXT_BASE=0x01000000,SYS_LDSCRIPT=board/amcc/sequoia/u-boot-ram.lds
-redwood powerpc ppc4xx - amcc
-sequoia powerpc ppc4xx sequoia amcc - sequoia:SEQUOIA
-sequoia_nand powerpc ppc4xx sequoia amcc - sequoia:SEQUOIA,NAND_U_BOOT,SYS_TEXT_BASE=0x01000000
-sequoia_ramboot powerpc ppc4xx sequoia amcc - sequoia:SEQUOIA,SYS_RAMBOOT,SYS_TEXT_BASE=0x01000000,SYS_LDSCRIPT=board/amcc/sequoia/u-boot-ram.lds
-sycamore powerpc ppc4xx walnut amcc - walnut
-taihu powerpc ppc4xx - amcc
-taishan powerpc ppc4xx - amcc
-walnut powerpc ppc4xx walnut amcc
-yellowstone powerpc ppc4xx yosemite amcc - yosemite:YELLOWSTONE
-yosemite powerpc ppc4xx yosemite amcc - yosemite:YOSEMITE
-yucca powerpc ppc4xx - amcc
-fx12mm powerpc ppc4xx fx12mm avnet - fx12mm:SYS_TEXT_BASE=0x04000000,RESET_VECTOR_ADDRESS=0x04100000,INIT_TLB=board/xilinx/ppc405-generic/init.o
-fx12mm_flash powerpc ppc4xx fx12mm avnet - fx12mm:SYS_TEXT_BASE=0xF7F60000,RESET_VECTOR_ADDRESS=0xF7FFFFFC,INIT_TLB=board/xilinx/ppc405-generic/init.o
-v5fx30teval powerpc ppc4xx v5fx30teval avnet - v5fx30teval:SYS_TEXT_BASE=0x04000000,RESET_VECTOR_ADDRESS=0x04100000,BOOT_FROM_XMD=1,INIT_TLB=board/xilinx/ppc440-generic/init.o
-v5fx30teval_flash powerpc ppc4xx v5fx30teval avnet - v5fx30teval:SYS_TEXT_BASE=0xF7F60000,RESET_VECTOR_ADDRESS=0xF7FFFFFC,INIT_TLB=board/xilinx/ppc440-generic/init.o
-CRAYL1 powerpc ppc4xx L1 cray
-CATcenter powerpc ppc4xx PPChameleonEVB dave - CATcenter:PPCHAMELEON_MODULE_MODEL=1
-CATcenter_25 powerpc ppc4xx PPChameleonEVB dave - CATcenter:PPCHAMELEON_MODULE_MODEL=1,PPCHAMELEON_CLK_25
-CATcenter_33 powerpc ppc4xx PPChameleonEVB dave - CATcenter:PPCHAMELEON_MODULE_MODEL=1,PPCHAMELEON_CLK_33
-PPChameleonEVB powerpc ppc4xx PPChameleonEVB dave
-PPChameleonEVB_BA_25 powerpc ppc4xx PPChameleonEVB dave - PPChameleonEVB:PPCHAMELEON_MODULE_MODEL=0,PPCHAMELEON_CLK_25
-PPChameleonEVB_BA_33 powerpc ppc4xx PPChameleonEVB dave - PPChameleonEVB:PPCHAMELEON_MODULE_MODEL=0,PPCHAMELEON_CLK_33
-PPChameleonEVB_HI_25 powerpc ppc4xx PPChameleonEVB dave - PPChameleonEVB:PPCHAMELEON_MODULE_MODEL=2,PPCHAMELEON_CLK_25
-PPChameleonEVB_HI_33 powerpc ppc4xx PPChameleonEVB dave - PPChameleonEVB:PPCHAMELEON_MODULE_MODEL=2,PPCHAMELEON_CLK_33
-PPChameleonEVB_ME_25 powerpc ppc4xx PPChameleonEVB dave - PPChameleonEVB:PPCHAMELEON_MODULE_MODEL=1,PPCHAMELEON_CLK_25
-PPChameleonEVB_ME_33 powerpc ppc4xx PPChameleonEVB dave - PPChameleonEVB:PPCHAMELEON_MODULE_MODEL=1,PPCHAMELEON_CLK_33
-APC405 powerpc ppc4xx apc405 esd
-AR405 powerpc ppc4xx ar405 esd
-ASH405 powerpc ppc4xx ash405 esd
-CANBT powerpc ppc4xx canbt esd
-CMS700 powerpc ppc4xx cms700 esd
-CPCI2DP powerpc ppc4xx cpci2dp esd
-CPCI405 powerpc ppc4xx cpci405 esd
-CPCI4052 powerpc ppc4xx cpci405 esd
-CPCI405AB powerpc ppc4xx cpci405 esd
-CPCI405DT powerpc ppc4xx cpci405 esd
-CPCIISER4 powerpc ppc4xx cpciiser4 esd
-DP405 powerpc ppc4xx dp405 esd
-DU405 powerpc ppc4xx du405 esd
-DU440 powerpc ppc4xx du440 esd
-HH405 powerpc ppc4xx hh405 esd
-HUB405 powerpc ppc4xx hub405 esd
-OCRTC powerpc ppc4xx ocrtc esd
-PCI405 powerpc ppc4xx pci405 esd
-PLU405 powerpc ppc4xx plu405 esd
-PMC405 powerpc ppc4xx pmc405 esd
-PMC405DE powerpc ppc4xx pmc405de esd
-PMC440 powerpc ppc4xx pmc440 esd
-VOH405 powerpc ppc4xx voh405 esd
-VOM405 powerpc ppc4xx vom405 esd
-WUH405 powerpc ppc4xx wuh405 esd
-devconcenter powerpc ppc4xx intip gdsys - intip:DEVCONCENTER
-dlvision powerpc ppc4xx - gdsys
-dlvision-10g powerpc ppc4xx 405ep gdsys
-gdppc440etx powerpc ppc4xx - gdsys
-intip powerpc ppc4xx intip gdsys - intip:INTIB
-io powerpc ppc4xx 405ep gdsys
-io64 powerpc ppc4xx 405ex gdsys
-iocon powerpc ppc4xx 405ep gdsys
-neo powerpc ppc4xx 405ep gdsys
-icon powerpc ppc4xx - mosaixtech
-MIP405 powerpc ppc4xx mip405 mpl
-MIP405T powerpc ppc4xx mip405 mpl - MIP405:MIP405T
-PIP405 powerpc ppc4xx pip405 mpl
-alpr powerpc ppc4xx - prodrive
-p3p440 powerpc ppc4xx - prodrive
-KAREF powerpc ppc4xx karef sandburst
-METROBOX powerpc ppc4xx metrobox sandburst
-xpedite1000 powerpc ppc4xx - xes
-ml507 powerpc ppc4xx ml507 xilinx - ml507:SYS_TEXT_BASE=0x04000000,RESET_VECTOR_ADDRESS=0x04100000,BOOT_FROM_XMD=1,INIT_TLB=board/xilinx/ppc440-generic/init.o
-ml507_flash powerpc ppc4xx ml507 xilinx - ml507:SYS_TEXT_BASE=0xF7F60000,RESET_VECTOR_ADDRESS=0xF7FFFFFC,INIT_TLB=board/xilinx/ppc440-generic/init.o
-xilinx-ppc405-generic powerpc ppc4xx ppc405-generic xilinx - xilinx-ppc405-generic:SYS_TEXT_BASE=0x04000000,RESET_VECTOR_ADDRESS=0x04100000
-xilinx-ppc405-generic_flash powerpc ppc4xx ppc405-generic xilinx - xilinx-ppc405-generic:SYS_TEXT_BASE=0xF7F60000,RESET_VECTOR_ADDRESS=0xF7FFFFFC
-xilinx-ppc440-generic powerpc ppc4xx ppc440-generic xilinx - xilinx-ppc440-generic:SYS_TEXT_BASE=0x04000000,RESET_VECTOR_ADDRESS=0x04100000,BOOT_FROM_XMD=1
-xilinx-ppc440-generic_flash powerpc ppc4xx ppc440-generic xilinx - xilinx-ppc440-generic:SYS_TEXT_BASE=0xF7F60000,RESET_VECTOR_ADDRESS=0xF7FFFFFC
-sandbox sandbox sandbox sandbox sandbox -
-rsk7203 sh sh2 rsk7203 renesas -
-rsk7264 sh sh2 rsk7264 renesas -
-rsk7269 sh sh2 rsk7269 renesas -
-mpr2 sh sh3 mpr2 - -
-ms7720se sh sh3 ms7720se - -
-shmin sh sh3 shmin - -
-espt sh sh4 espt - -
-ms7722se sh sh4 ms7722se - -
-ms7750se sh sh4 ms7750se - -
-ap325rxa sh sh4 ap325rxa renesas -
-ecovec sh sh4 ecovec renesas -
-MigoR sh sh4 MigoR renesas -
-r2dplus sh sh4 r2dplus renesas -
-r7780mp sh sh4 r7780mp renesas -
-sh7752evb sh sh4 sh7752evb renesas -
-sh7757lcr sh sh4 sh7757lcr renesas -
-sh7763rdp sh sh4 sh7763rdp renesas -
-sh7785lcr sh sh4 sh7785lcr renesas -
-sh7785lcr_32bit sh sh4 sh7785lcr renesas - sh7785lcr:SH_32BIT=1
-r0p7734 sh sh4 r0p7734 renesas -
-ap_sh4a_4a sh sh4 ap_sh4a_4a alphaproject -
-grsim_leon2 sparc leon2 - gaisler
-gr_cpci_ax2000 sparc leon3 - gaisler
-gr_ep2s60 sparc leon3 - gaisler
-grsim sparc leon3 - gaisler
-gr_xc3s_1500 sparc leon3 - gaisler
-coreboot-x86 x86 x86 coreboot chromebook-x86 coreboot coreboot:SYS_TEXT_BASE=0x01110000
-# Target ARCH CPU Board name Vendor SoC Options
-########################################################################################################################
+Active arm arm1136 - armltd integrator integratorcp_cm1136 integratorcp:CM1136 Linus Walleij <linus.walleij@linaro.org>
+Active arm arm1136 mx31 - - imx31_phycore - -
+Active arm arm1136 mx31 davedenx - qong - Wolfgang Denk <wd@denx.de>
+Active arm arm1136 mx31 freescale - mx31pdk - Fabio Estevam <fabio.estevam@freescale.com>
+Active arm arm1136 mx31 hale - tt01 - Helmut Raiger <helmut.raiger@hale.at>
+Active arm arm1136 mx31 logicpd - imx31_litekit - -
+Active arm arm1136 mx35 - - woodburn - Stefano Babic <sbabic@denx.de>
+Active arm arm1136 mx35 - woodburn woodburn_sd woodburn_sd:IMX_CONFIG=board/woodburn/imximage.cfg Stefano Babic <sbabic@denx.de>
+Active arm arm1136 mx35 CarMediaLab - flea3 - Stefano Babic <sbabic@denx.de>
+Active arm arm1136 mx35 freescale - mx35pdk - Stefano Babic <sbabic@denx.de>
+Active arm arm1176 bcm2835 raspberrypi rpi_b rpi_b - Stephen Warren <swarren@wwwdotorg.org>
+Active arm arm1176 tnetv107x ti tnetv107xevm tnetv107x_evm - Chan-Taek Park <c-park@ti.com>
+Active arm arm720t - armltd integrator integratorap_cm720t integratorap:CM720T Linus Walleij <linus.walleij@linaro.org>
+Active arm arm920t - armltd integrator integratorap_cm920t integratorap:CM920T Linus Walleij <linus.walleij@linaro.org>
+Active arm arm920t - armltd integrator integratorcp_cm920t integratorcp:CM920T Linus Walleij <linus.walleij@linaro.org>
+Active arm arm920t a320 faraday - a320evb - Po-Yu Chuang <ratbert@faraday-tech.com>
+Active arm arm920t at91 atmel at91rm9200ek at91rm9200ek at91rm9200ek Andreas Bie??mann <andreas.devel@gmail.com>
+Active arm arm920t at91 atmel at91rm9200ek at91rm9200ek_ram at91rm9200ek:RAMBOOT Andreas Bie??mann <andreas.devel@gmail.com>
+Active arm arm920t at91 BuS eb_cpux9k2 eb_cpux9k2 eb_cpux9k2 Jens Scharsig <esw@bus-elektronik.de>
+Active arm arm920t at91 BuS eb_cpux9k2 eb_cpux9k2_ram eb_cpux9k2:RAMBOOT Jens Scharsig <esw@bus-elektronik.de>
+Active arm arm920t at91 eukrea cpuat91 cpuat91 cpuat91 Eric Benard <eric@eukrea.com>
+Active arm arm920t at91 eukrea cpuat91 cpuat91_ram cpuat91:RAMBOOT Eric Benard <eric@eukrea.com>
+Active arm arm920t imx - - mx1ads - -
+Active arm arm920t imx - - scb9328 - Torsten Koschorrek <koschorrek@synertronixx.de>
+Active arm arm920t ks8695 - - cm4008 - Greg Ungerer <greg.ungerer@opengear.com>
+Active arm arm920t ks8695 - - cm41xx - -
+Active arm arm920t s3c24x0 friendlyarm mini2440 mini2440 - Gabriel Huau <contact@huau-gabriel.fr>
+Active arm arm920t s3c24x0 mpl vcma9 VCMA9 - David M??ller <d.mueller@elsoft.ch>
+Active arm arm920t s3c24x0 samsung - smdk2410 - David M??ller <d.mueller@elsoft.ch>
+Active arm arm926ejs - armltd integrator integratorap_cm926ejs integratorap:CM926EJ_S Linus Walleij <linus.walleij@linaro.org>
+Active arm arm926ejs - armltd integrator integratorcp_cm926ejs integratorcp:CM924EJ_S Linus Walleij <linus.walleij@linaro.org>
+Active arm arm926ejs armada100 Marvell - aspenite - Prafulla Wadaskar <prafulla@marvell.com>
+Active arm arm926ejs armada100 Marvell - gplugd - Ajay Bhargav <ajay.bhargav@einfochips.com>
+Active arm arm926ejs at91 - - afeb9260 - Sergey Lapin <slapin@ossfans.org>
+Active arm arm926ejs at91 atmel at91sam9260ek at91sam9260ek_dataflash_cs0 at91sam9260ek:AT91SAM9260,SYS_USE_DATAFLASH_CS0 Stelian Pop <stelian@popies.net>
+Active arm arm926ejs at91 atmel at91sam9260ek at91sam9260ek_dataflash_cs1 at91sam9260ek:AT91SAM9260,SYS_USE_DATAFLASH_CS1 Stelian Pop <stelian@popies.net>
+Active arm arm926ejs at91 atmel at91sam9260ek at91sam9260ek_nandflash at91sam9260ek:AT91SAM9260,SYS_USE_NANDFLASH Stelian Pop <stelian@popies.net>
+Active arm arm926ejs at91 atmel at91sam9260ek at91sam9g20ek_2mmc_nandflash at91sam9260ek:AT91SAM9G20,AT91SAM9G20EK_2MMC,SYS_USE_NANDFLASH Stelian Pop <stelian@popies.net>
+Active arm arm926ejs at91 atmel at91sam9260ek at91sam9g20ek_dataflash_cs0 at91sam9260ek:AT91SAM9G20,SYS_USE_DATAFLASH_CS0 Stelian Pop <stelian@popies.net>
+Active arm arm926ejs at91 atmel at91sam9260ek at91sam9g20ek_dataflash_cs1 at91sam9260ek:AT91SAM9G20,SYS_USE_DATAFLASH_CS1 Stelian Pop <stelian@popies.net>
+Active arm arm926ejs at91 atmel at91sam9260ek at91sam9g20ek_mmc at91sam9260ek:AT91SAM9G20,SYS_USE_MMC Stelian Pop <stelian@popies.net>
+Active arm arm926ejs at91 atmel at91sam9260ek at91sam9g20ek_nandflash at91sam9260ek:AT91SAM9G20,SYS_USE_NANDFLASH Stelian Pop <stelian@popies.net>
+Active arm arm926ejs at91 atmel at91sam9260ek at91sam9xeek_dataflash_cs0 at91sam9260ek:AT91SAM9XE,SYS_USE_DATAFLASH_CS0 Stelian Pop <stelian@popies.net>
+Active arm arm926ejs at91 atmel at91sam9260ek at91sam9xeek_dataflash_cs1 at91sam9260ek:AT91SAM9XE,SYS_USE_DATAFLASH_CS1 Stelian Pop <stelian@popies.net>
+Active arm arm926ejs at91 atmel at91sam9260ek at91sam9xeek_nandflash at91sam9260ek:AT91SAM9XE,SYS_USE_NANDFLASH Stelian Pop <stelian@popies.net>
+Active arm arm926ejs at91 atmel at91sam9261ek at91sam9261ek_dataflash_cs0 at91sam9261ek:AT91SAM9261,SYS_USE_DATAFLASH_CS0 Stelian Pop <stelian@popies.net>
+Active arm arm926ejs at91 atmel at91sam9261ek at91sam9261ek_dataflash_cs3 at91sam9261ek:AT91SAM9261,SYS_USE_DATAFLASH_CS3 Stelian Pop <stelian@popies.net>
+Active arm arm926ejs at91 atmel at91sam9261ek at91sam9261ek_nandflash at91sam9261ek:AT91SAM9261,SYS_USE_NANDFLASH Stelian Pop <stelian@popies.net>
+Active arm arm926ejs at91 atmel at91sam9261ek at91sam9g10ek_dataflash_cs0 at91sam9261ek:AT91SAM9G10,SYS_USE_DATAFLASH_CS0 Stelian Pop <stelian@popies.net>
+Active arm arm926ejs at91 atmel at91sam9261ek at91sam9g10ek_dataflash_cs3 at91sam9261ek:AT91SAM9G10,SYS_USE_DATAFLASH_CS3 Stelian Pop <stelian@popies.net>
+Active arm arm926ejs at91 atmel at91sam9261ek at91sam9g10ek_nandflash at91sam9261ek:AT91SAM9G10,SYS_USE_NANDFLASH Stelian Pop <stelian@popies.net>
+Active arm arm926ejs at91 atmel at91sam9263ek at91sam9263ek_dataflash at91sam9263ek:AT91SAM9263,SYS_USE_DATAFLASH Stelian Pop <stelian@popies.net>
+Active arm arm926ejs at91 atmel at91sam9263ek at91sam9263ek_dataflash_cs0 at91sam9263ek:AT91SAM9263,SYS_USE_DATAFLASH Stelian Pop <stelian@popies.net>
+Active arm arm926ejs at91 atmel at91sam9263ek at91sam9263ek_nandflash at91sam9263ek:AT91SAM9263,SYS_USE_NANDFLASH Stelian Pop <stelian@popies.net>
+Active arm arm926ejs at91 atmel at91sam9263ek at91sam9263ek_norflash at91sam9263ek:AT91SAM9263,SYS_USE_NORFLASH Stelian Pop <stelian@popies.net>
+Active arm arm926ejs at91 atmel at91sam9263ek at91sam9263ek_norflash_boot at91sam9263ek:AT91SAM9263,SYS_USE_BOOT_NORFLASH Stelian Pop <stelian@popies.net>
+Active arm arm926ejs at91 atmel at91sam9m10g45ek at91sam9m10g45ek_nandflash at91sam9m10g45ek:AT91SAM9M10G45,SYS_USE_NANDFLASH Bo Shen<voice.shen@atmel.com>
+Active arm arm926ejs at91 atmel at91sam9n12ek at91sam9n12ek_mmc at91sam9n12ek:AT91SAM9N12,SYS_USE_MMC Josh Wu <josh.wu@atmel.com>
+Active arm arm926ejs at91 atmel at91sam9n12ek at91sam9n12ek_nandflash at91sam9n12ek:AT91SAM9N12,SYS_USE_NANDFLASH Josh Wu <josh.wu@atmel.com>
+Active arm arm926ejs at91 atmel at91sam9n12ek at91sam9n12ek_spiflash at91sam9n12ek:AT91SAM9N12,SYS_USE_SPIFLASH Josh Wu <josh.wu@atmel.com>
+Active arm arm926ejs at91 atmel at91sam9rlek at91sam9rlek_dataflash at91sam9rlek:AT91SAM9RL,SYS_USE_DATAFLASH Stelian Pop <stelian@popies.net>
+Active arm arm926ejs at91 atmel at91sam9rlek at91sam9rlek_nandflash at91sam9rlek:AT91SAM9RL,SYS_USE_NANDFLASH Stelian Pop <stelian@popies.net>
+Active arm arm926ejs at91 atmel at91sam9x5ek at91sam9x5ek_dataflash at91sam9x5ek:AT91SAM9X5,SYS_USE_DATAFLASH Bo Shen <voice.shen@atmel.com>
+Active arm arm926ejs at91 atmel at91sam9x5ek at91sam9x5ek_mmc at91sam9x5ek:AT91SAM9X5,SYS_USE_MMC Bo Shen <voice.shen@atmel.com>
+Active arm arm926ejs at91 atmel at91sam9x5ek at91sam9x5ek_nandflash at91sam9x5ek:AT91SAM9X5,SYS_USE_NANDFLASH Bo Shen <voice.shen@atmel.com>
+Active arm arm926ejs at91 atmel at91sam9x5ek at91sam9x5ek_spiflash at91sam9x5ek:AT91SAM9X5,SYS_USE_SPIFLASH Bo Shen <voice.shen@atmel.com>
+Active arm arm926ejs at91 bluewater - snapper9260 snapper9260:AT91SAM9260 Ryan Mallon <ryan@bluewatersys.com>
+Active arm arm926ejs at91 bluewater snapper9260 snapper9g20 snapper9260:AT91SAM9G20 Ryan Mallon <ryan@bluewatersys.com>
+Active arm arm926ejs at91 BuS vl_ma2sc vl_ma2sc - Jens Scharsig <esw@bus-elektronik.de>
+Active arm arm926ejs at91 BuS vl_ma2sc vl_ma2sc_ram vl_ma2sc:RAMLOAD Jens Scharsig <esw@bus-elektronik.de>
+Active arm arm926ejs at91 calao sbc35_a9g20 sbc35_a9g20_eeprom sbc35_a9g20:AT91SAM9G20,SYS_USE_EEPROM Albin Tonnerre <albin.tonnerre@free-electrons.com>
+Active arm arm926ejs at91 calao sbc35_a9g20 sbc35_a9g20_nandflash sbc35_a9g20:AT91SAM9G20,SYS_USE_NANDFLASH Albin Tonnerre <albin.tonnerre@free-electrons.com>
+Active arm arm926ejs at91 calao tny_a9260 tny_a9260_eeprom tny_a9260:AT91SAM9260,SYS_USE_EEPROM Albin Tonnerre <albin.tonnerre@free-electrons.com>
+Active arm arm926ejs at91 calao tny_a9260 tny_a9260_nandflash tny_a9260:AT91SAM9260,SYS_USE_NANDFLASH Albin Tonnerre <albin.tonnerre@free-electrons.com>
+Active arm arm926ejs at91 calao tny_a9260 tny_a9g20_eeprom tny_a9260:AT91SAM9G20,SYS_USE_EEPROM Albin Tonnerre <albin.tonnerre@free-electrons.com>
+Active arm arm926ejs at91 calao tny_a9260 tny_a9g20_nandflash tny_a9260:AT91SAM9G20,SYS_USE_NANDFLASH Albin Tonnerre <albin.tonnerre@free-electrons.com>
+Active arm arm926ejs at91 egnite ethernut5 ethernut5 ethernut5:AT91SAM9XE egnite GmbH <info@egnite.de>
+Active arm arm926ejs at91 emk top9000 top9000eval_xe top9000:EVAL9000 Reinhard Meyer <reinhard.meyer@emk-elektronik.de>
+Active arm arm926ejs at91 emk top9000 top9000su_xe top9000:SU9000 Reinhard Meyer <reinhard.meyer@emk-elektronik.de>
+Active arm arm926ejs at91 esd meesc meesc meesc:AT91SAM9263,SYS_USE_NANDFLASH Daniel Gorsulowski <daniel.gorsulowski@esd.eu>
+Active arm arm926ejs at91 esd meesc meesc_dataflash meesc:AT91SAM9263,SYS_USE_DATAFLASH Daniel Gorsulowski <daniel.gorsulowski@esd.eu>
+Active arm arm926ejs at91 esd otc570 otc570 otc570:AT91SAM9263,SYS_USE_NANDFLASH Daniel Gorsulowski <daniel.gorsulowski@esd.eu>
+Active arm arm926ejs at91 esd otc570 otc570_dataflash otc570:AT91SAM9263,SYS_USE_DATAFLASH Daniel Gorsulowski <daniel.gorsulowski@esd.eu>
+Active arm arm926ejs at91 eukrea cpu9260 cpu9260 cpu9260:CPU9260 Eric Benard <eric@eukrea.com>
+Active arm arm926ejs at91 eukrea cpu9260 cpu9260_128M cpu9260:CPU9260,CPU9260_128M Eric Benard <eric@eukrea.com>
+Active arm arm926ejs at91 eukrea cpu9260 cpu9260_nand cpu9260:CPU9260,NANDBOOT Eric Benard <eric@eukrea.com>
+Active arm arm926ejs at91 eukrea cpu9260 cpu9260_nand_128M cpu9260:CPU9260,CPU9260_128M,NANDBOOT Eric Benard <eric@eukrea.com>
+Active arm arm926ejs at91 eukrea cpu9260 cpu9G20 cpu9260:CPU9G20 Eric Benard <eric@eukrea.com>
+Active arm arm926ejs at91 eukrea cpu9260 cpu9G20_128M cpu9260:CPU9G20,CPU9G20_128M Eric Benard <eric@eukrea.com>
+Active arm arm926ejs at91 eukrea cpu9260 cpu9G20_nand cpu9260:CPU9G20,NANDBOOT Eric Benard <eric@eukrea.com>
+Active arm arm926ejs at91 eukrea cpu9260 cpu9G20_nand_128M cpu9260:CPU9G20,CPU9G20_128M,NANDBOOT Eric Benard <eric@eukrea.com>
+Active arm arm926ejs at91 ronetix pm9261 pm9261 pm9261:AT91SAM9261 Ilko Iliev <iliev@ronetix.at>
+Active arm arm926ejs at91 ronetix pm9263 pm9263 pm9263:AT91SAM9263 Ilko Iliev <iliev@ronetix.at>
+Active arm arm926ejs at91 ronetix pm9g45 pm9g45 pm9g45:AT91SAM9G45 Ilko Iliev <iliev@ronetix.at>
+Active arm arm926ejs at91 taskit stamp9g20 portuxg20 stamp9g20:AT91SAM9G20,PORTUXG20 Markus Hubig <mhubig@imko.de>
+Active arm arm926ejs at91 taskit stamp9g20 stamp9g20 stamp9g20:AT91SAM9G20 Markus Hubig <mhubig@imko.de>
+Active arm arm926ejs davinci ait cam_enc_4xx cam_enc_4xx cam_enc_4xx Heiko Schocher <hs@denx.de>
+Active arm arm926ejs davinci davinci da8xxevm da830evm - Nick Thompson <nick.thompson@gefanuc.com>
+Active arm arm926ejs davinci davinci da8xxevm da850_am18xxevm da850evm:DA850_AM18X_EVM,MAC_ADDR_IN_EEPROM,SYS_I2C_EEPROM_ADDR_LEN=2,SYS_I2C_EEPROM_ADDR=0x50 Sudhakar Rajashekhara <sudhakar.raj@ti.com>
+Active arm arm926ejs davinci davinci da8xxevm da850evm da850evm:MAC_ADDR_IN_SPIFLASH Sudhakar Rajashekhara <sudhakar.raj@ti.com>
+Active arm arm926ejs davinci davinci da8xxevm da850evm_direct_nor da850evm:MAC_ADDR_IN_SPIFLASH,USE_NOR,DIRECT_NOR_BOOT Sudhakar Rajashekhara <sudhakar.raj@ti.com>
+Active arm arm926ejs davinci davinci da8xxevm hawkboard - Syed Mohammed Khasim <sm.khasim@gmail.com>:Sughosh Ganu <urwithsughosh@gmail.com>
+Active arm arm926ejs davinci davinci da8xxevm hawkboard_uart hawkboard:UART_U_BOOT Syed Mohammed Khasim <sm.khasim@gmail.com>:Sughosh Ganu <urwithsughosh@gmail.com>
+Active arm arm926ejs davinci davinci dm355evm davinci_dm355evm - Sandeep Paulraj <s-paulraj@ti.com>
+Active arm arm926ejs davinci davinci dm355leopard davinci_dm355leopard - Sandeep Paulraj <s-paulraj@ti.com>
+Active arm arm926ejs davinci davinci dm365evm davinci_dm365evm - Sandeep Paulraj <s-paulraj@ti.com>
+Active arm arm926ejs davinci davinci dm6467evm davinci_dm6467evm davinci_dm6467evm:REFCLK_FREQ=27000000 Sandeep Paulraj <s-paulraj@ti.com>
+Active arm arm926ejs davinci davinci dm6467evm davinci_dm6467Tevm davinci_dm6467evm:DAVINCI_DM6467TEVM,REFCLK_FREQ=33000000 Sandeep Paulraj <s-paulraj@ti.com>
+Active arm arm926ejs davinci davinci dvevm davinci_dvevm - -
+Active arm arm926ejs davinci davinci ea20 ea20 - Stefano Babic <sbabic@denx.de>
+Active arm arm926ejs davinci davinci schmoogie davinci_schmoogie - Sergey Kubushyn <ksi@koi8.net>
+Active arm arm926ejs davinci davinci sffsdr davinci_sffsdr - Hugo Villeneuve <hugo.villeneuve@lyrtech.com>
+Active arm arm926ejs davinci davinci sonata davinci_sonata - Sergey Kubushyn <ksi@koi8.net>
+Active arm arm926ejs davinci enbw enbw_cmc enbw_cmc - Heiko Schocher <hs@denx.de>
+Active arm arm926ejs davinci omicron calimain calimain - Manfred Rudigier <manfred.rudigier@omicron.at>:Christian Riesch <christian.riesch@omicron.at>
+Active arm arm926ejs kirkwood buffalo lsxl lschlv2 lsxl:LSCHLV2 Michael Walle <michael@walle.cc>
+Active arm arm926ejs kirkwood buffalo lsxl lsxhl lsxl:LSXHL Michael Walle <michael@walle.cc>
+Active arm arm926ejs kirkwood cloudengines - pogo_e02 - Dave Purdy <david.c.purdy@gmail.com>
+Active arm arm926ejs kirkwood d-link - dns325 - Stefan Herbrechtsmeier <stefan@code.herbrechtsmeier.net>
+Active arm arm926ejs kirkwood iomega - iconnect - Luka Perkov <luka@openwrt.org>
+Active arm arm926ejs kirkwood karo tk71 tk71 - -
+Active arm arm926ejs kirkwood keymile km_arm km_kirkwood km_kirkwood:KM_KIRKWOOD Valentin Longchamp <valentin.longchamp@keymile.com>
+Active arm arm926ejs kirkwood keymile km_arm km_kirkwood_pci km_kirkwood:KM_KIRKWOOD_PCI Valentin Longchamp <valentin.longchamp@keymile.com>
+Active arm arm926ejs kirkwood keymile km_arm kmcoge5un km_kirkwood:KM_COGE5UN Valentin Longchamp <valentin.longchamp@keymile.com>
+Active arm arm926ejs kirkwood keymile km_arm kmnusa km_kirkwood:KM_NUSA Valentin Longchamp <valentin.longchamp@keymile.com>
+Active arm arm926ejs kirkwood keymile km_arm kmsuv31 km_kirkwood:KM_SUV31 Valentin Longchamp <valentin.longchamp@keymile.com>
+Active arm arm926ejs kirkwood keymile km_arm mgcoge3un km_kirkwood:KM_MGCOGE3UN Valentin Longchamp <valentin.longchamp@keymile.com>
+Active arm arm926ejs kirkwood keymile km_arm portl2 km_kirkwood:KM_PORTL2 Valentin Longchamp <valentin.longchamp@keymile.com>
+Active arm arm926ejs kirkwood LaCie net2big_v2 d2net_v2 lacie_kw:D2NET_V2 Simon Guinot <simon.guinot@sequanux.org>
+Active arm arm926ejs kirkwood LaCie net2big_v2 net2big_v2 lacie_kw:NET2BIG_V2 Simon Guinot <simon.guinot@sequanux.org>
+Active arm arm926ejs kirkwood LaCie netspace_v2 inetspace_v2 lacie_kw:INETSPACE_V2 Simon Guinot <simon.guinot@sequanux.org>
+Active arm arm926ejs kirkwood LaCie netspace_v2 netspace_lite_v2 lacie_kw:NETSPACE_LITE_V2 Simon Guinot <simon.guinot@sequanux.org>
+Active arm arm926ejs kirkwood LaCie netspace_v2 netspace_max_v2 lacie_kw:NETSPACE_MAX_V2 Simon Guinot <simon.guinot@sequanux.org>
+Active arm arm926ejs kirkwood LaCie netspace_v2 netspace_mini_v2 lacie_kw:NETSPACE_MINI_V2 Simon Guinot <simon.guinot@sequanux.org>
+Active arm arm926ejs kirkwood LaCie netspace_v2 netspace_v2 lacie_kw:NETSPACE_V2 Simon Guinot <simon.guinot@sequanux.org>
+Active arm arm926ejs kirkwood LaCie wireless_space wireless_space - -
+Active arm arm926ejs kirkwood Marvell - dreamplug - Jason Cooper <u-boot@lakedaemon.net>
+Active arm arm926ejs kirkwood Marvell - guruplug - Siddarth Gore <gores@marvell.com>
+Active arm arm926ejs kirkwood Marvell - mv88f6281gtw_ge - Prafulla Wadaskar <prafulla@marvell.com>
+Active arm arm926ejs kirkwood Marvell - rd6281a - Prafulla Wadaskar <prafulla@marvell.com>
+Active arm arm926ejs kirkwood Marvell - sheevaplug - Prafulla Wadaskar <prafulla@marvell.com>
+Active arm arm926ejs kirkwood Marvell openrd openrd_base openrd:BOARD_IS_OPENRD_BASE Prafulla Wadaskar <prafulla@marvell.com>
+Active arm arm926ejs kirkwood Marvell openrd openrd_client openrd:BOARD_IS_OPENRD_CLIENT -
+Active arm arm926ejs kirkwood Marvell openrd openrd_ultimate openrd:BOARD_IS_OPENRD_ULTIMATE -
+Active arm arm926ejs kirkwood raidsonic ib62x0 ib62x0 - Luka Perkov <luka@openwrt.org>
+Active arm arm926ejs kirkwood Seagate - dockstar - Eric Cooper <ecc@cmu.edu>
+Active arm arm926ejs kirkwood Seagate - goflexhome - Suriyan Ramasami <suriyan.r@gmail.com>
+Active arm arm926ejs lpc32xx timll devkit3250 devkit3250 - Vladimir Zapolskiy <vz@mleia.com>
+Active arm arm926ejs mb86r0x syteco jadecpu jadecpu - Matthias Weisser <weisserm@arcor.de>
+Active arm arm926ejs mx25 freescale mx25pdk mx25pdk mx25pdk:IMX_CONFIG=board/freescale/mx25pdk/imximage.cfg Fabio Estevam <fabio.estevam@freescale.com>
+Active arm arm926ejs mx25 karo tx25 tx25 - John Rigby <jcrigby@gmail.com>
+Active arm arm926ejs mx25 syteco zmx25 zmx25 - Matthias Weisser <weisserm@arcor.de>
+Active arm arm926ejs mx27 logicpd imx27lite imx27lite - Wolfgang Denk <wd@denx.de>
+Active arm arm926ejs mx27 logicpd imx27lite magnesium - Wolfgang Denk <wd@denx.de>:Heiko Schocher <hs@denx.de>
+Active arm arm926ejs mxs bluegiga apx4devkit apx4devkit apx4devkit Lauri Hintsala <lauri.hintsala@bluegiga.com>
+Active arm arm926ejs mxs denx m28evk m28evk m28evk Marek Vasut <marek.vasut@gmail.com>
+Active arm arm926ejs mxs freescale mx23evk mx23evk mx23evk Otavio Salvador <otavio@ossystems.com.br>
+Active arm arm926ejs mxs freescale mx28evk mx28evk mx28evk:ENV_IS_IN_MMC Fabio Estevam <fabio.estevam@freescale.com>
+Active arm arm926ejs mxs freescale mx28evk mx28evk_nand mx28evk:ENV_IS_IN_NAND Fabio Estevam <fabio.estevam@freescale.com>
+Active arm arm926ejs mxs olimex mx23_olinuxino mx23_olinuxino mx23_olinuxino Marek Vasut <marek.vasut@gmail.com>
+Active arm arm926ejs mxs schulercontrol sc_sps_1 sc_sps_1 - Marek Vasut <marek.vasut@gmail.com>
+Active arm arm926ejs nomadik st nhk8815 nhk8815 - Nomadik Linux Team <STN_WMM_nomadik_linux@list.st.com>:Alessandro Rubini <rubini@unipv.it>
+Active arm arm926ejs nomadik st nhk8815 nhk8815_onenand nhk8815:BOOT_ONENAND Nomadik Linux Team <STN_WMM_nomadik_linux@list.st.com>:Alessandro Rubini <rubini@unipv.it>
+Active arm arm926ejs omap ti - omap5912osk - Rishi Bhattacharya <rishi@ti.com>
+Active arm arm926ejs omap ti omap730p2 omap730p2 omap730p2:CS3_BOOT Dave Peverley <dpeverley@mpc-data.co.uk>
+Active arm arm926ejs omap ti omap730p2 omap730p2_cs0boot omap730p2:CS0_BOOT Dave Peverley <dpeverley@mpc-data.co.uk>
+Active arm arm926ejs omap ti omap730p2 omap730p2_cs3boot omap730p2:CS3_BOOT Dave Peverley <dpeverley@mpc-data.co.uk>
+Active arm arm926ejs orion5x LaCie - edminiv2 - Albert ARIBAUD <albert.u.boot@aribaud.net>
+Active arm arm926ejs pantheon Marvell - dkb - Lei Wen <leiwen@marvell.com>
+Active arm arm926ejs spear spear - x600 x600 Stefan Roese <sr@denx.de>
+Active arm arm926ejs spear spear spear300 spear300 spear3xx_evb:spear300 Vipin Kumar <vipin.kumar@st.com>
+Active arm arm926ejs spear spear spear300 spear300_nand spear3xx_evb:spear300,nand Vipin Kumar <vipin.kumar@st.com>
+Active arm arm926ejs spear spear spear300 spear300_usbtty spear3xx_evb:spear300,usbtty Vipin Kumar <vipin.kumar@st.com>
+Active arm arm926ejs spear spear spear300 spear300_usbtty_nand spear3xx_evb:spear300,usbtty,nand Vipin Kumar <vipin.kumar@st.com>
+Active arm arm926ejs spear spear spear310 spear310 spear3xx_evb:spear310 Vipin Kumar <vipin.kumar@st.com>
+Active arm arm926ejs spear spear spear310 spear310_nand spear3xx_evb:spear310,nand Vipin Kumar <vipin.kumar@st.com>
+Active arm arm926ejs spear spear spear310 spear310_pnor spear3xx_evb:spear310,FLASH_PNOR Vipin Kumar <vipin.kumar@st.com>
+Active arm arm926ejs spear spear spear310 spear310_usbtty spear3xx_evb:spear310,usbtty Vipin Kumar <vipin.kumar@st.com>
+Active arm arm926ejs spear spear spear310 spear310_usbtty_nand spear3xx_evb:spear310,usbtty,nand Vipin Kumar <vipin.kumar@st.com>
+Active arm arm926ejs spear spear spear310 spear310_usbtty_pnor spear3xx_evb:spear310,usbtty,FLASH_PNOR Vipin Kumar <vipin.kumar@st.com>
+Active arm arm926ejs spear spear spear320 spear320 spear3xx_evb:spear320 Vipin Kumar <vipin.kumar@st.com>
+Active arm arm926ejs spear spear spear320 spear320_nand spear3xx_evb:spear320,nand Vipin Kumar <vipin.kumar@st.com>
+Active arm arm926ejs spear spear spear320 spear320_pnor spear3xx_evb:spear320,FLASH_PNOR Vipin Kumar <vipin.kumar@st.com>
+Active arm arm926ejs spear spear spear320 spear320_usbtty spear3xx_evb:spear320,usbtty Vipin Kumar <vipin.kumar@st.com>
+Active arm arm926ejs spear spear spear320 spear320_usbtty_nand spear3xx_evb:spear320,usbtty,nand Vipin Kumar <vipin.kumar@st.com>
+Active arm arm926ejs spear spear spear320 spear320_usbtty_pnor spear3xx_evb:spear320,usbtty,FLASH_PNOR Vipin Kumar <vipin.kumar@st.com>
+Active arm arm926ejs spear spear spear600 spear600 spear6xx_evb:spear600 Vipin Kumar <vipin.kumar@st.com>
+Active arm arm926ejs spear spear spear600 spear600_nand spear6xx_evb:spear600,nand Vipin Kumar <vipin.kumar@st.com>
+Active arm arm926ejs spear spear spear600 spear600_usbtty spear6xx_evb:spear600,usbtty Vipin Kumar <vipin.kumar@st.com>
+Active arm arm926ejs spear spear spear600 spear600_usbtty_nand spear6xx_evb:spear600,usbtty,nand Vipin Kumar <vipin.kumar@st.com>
+Active arm arm946es - armltd integrator integratorap_cm946es integratorap:CM946ES Linus Walleij <linus.walleij@linaro.org>
+Active arm arm946es - armltd integrator integratorcp_cm946es integratorcp:CM946ES Linus Walleij <linus.walleij@linaro.org>
+Active arm armv7 - armltd vexpress vexpress_ca15_tc2 - -
+Active arm armv7 - armltd vexpress vexpress_ca5x2 - Matt Waddel <matt.waddel@linaro.org>
+Active arm armv7 - armltd vexpress vexpress_ca9x4 - Matt Waddel <matt.waddel@linaro.org>
+Active arm armv7 am33xx isee igep0033 igep0033 - Enric Balletbo i Serra <eballetbo@iseebcn.com>
+Active arm armv7 am33xx phytec pcm051 pcm051 pcm051 Lars Poeschel <poeschel@lemonage.de>
+Active arm armv7 am33xx ti am335x am335x_evm am335x_evm:SERIAL1,CONS_INDEX=1 Tom Rini <trini@ti.com>
+Active arm armv7 am33xx ti am335x am335x_evm_spiboot am335x_evm:SERIAL1,CONS_INDEX=1,SPI_BOOT Tom Rini <trini@ti.com>
+Active arm armv7 am33xx ti am335x am335x_evm_uart1 am335x_evm:SERIAL2,CONS_INDEX=2 Tom Rini <trini@ti.com>
+Active arm armv7 am33xx ti am335x am335x_evm_uart2 am335x_evm:SERIAL3,CONS_INDEX=3 Tom Rini <trini@ti.com>
+Active arm armv7 am33xx ti am335x am335x_evm_uart3 am335x_evm:SERIAL4,CONS_INDEX=4 Tom Rini <trini@ti.com>
+Active arm armv7 am33xx ti am335x am335x_evm_uart4 am335x_evm:SERIAL5,CONS_INDEX=5 Tom Rini <trini@ti.com>
+Active arm armv7 am33xx ti am335x am335x_evm_uart5 am335x_evm:SERIAL6,CONS_INDEX=6 Tom Rini <trini@ti.com>
+Active arm armv7 am33xx ti am335x am335x_evm_usbspl am335x_evm:SERIAL1,CONS_INDEX=1,SPL_USBETH_SUPPORT Tom Rini <trini@ti.com>
+Active arm armv7 am33xx ti ti814x ti814x_evm - Matt Porter <mporter@ti.com>
+Active arm armv7 at91 atmel sama5d3xek sama5d3xek_mmc sama5d3xek:SAMA5D3,SYS_USE_MMC Bo Shen <voice.shen@atmel.com>
+Active arm armv7 at91 atmel sama5d3xek sama5d3xek_nandflash sama5d3xek:SAMA5D3,SYS_USE_NANDFLASH Bo Shen <voice.shen@atmel.com>
+Active arm armv7 at91 atmel sama5d3xek sama5d3xek_spiflash sama5d3xek:SAMA5D3,SYS_USE_SERIALFLASH Bo Shen <voice.shen@atmel.com>
+Active arm armv7 exynos samsung origen origen - Chander Kashyap <k.chander@samsung.com>
+Active arm armv7 exynos samsung smdk5250 smdk5250 - Chander Kashyap <k.chander@samsung.com>
+Active arm armv7 exynos samsung smdk5250 snow - Rajeshwari Shinde <rajeshwari.s@samsung.com>:Chander Kashyap <k.chander@samsung.com>
+Active arm armv7 exynos samsung smdkv310 smdkv310 - Chander Kashyap <k.chander@samsung.com>
+Active arm armv7 exynos samsung trats trats - Lukasz Majewski <l.majewski@samsung.com>
+Active arm armv7 exynos samsung universal_c210 s5pc210_universal - Minkyu Kang <mk7.kang@samsung.com>
+Active arm armv7 highbank - highbank highbank - Rob Herring <rob.herring@calxeda.com>
+Active arm armv7 mx5 denx m53evk m53evk m53evk:IMX_CONFIG=board/denx/m53evk/imximage.cfg Marek Vasut <marek.vasut@gmail.com>
+Active arm armv7 mx5 esg ima3-mx53 ima3-mx53 ima3-mx53:IMX_CONFIG=board/esg/ima3-mx53/imximage.cfg -
+Active arm armv7 mx5 freescale mx51evk mx51evk mx51evk:IMX_CONFIG=board/freescale/mx51evk/imximage.cfg Stefano Babic <sbabic@denx.de>
+Active arm armv7 mx5 freescale mx53ard mx53ard mx53ard:IMX_CONFIG=board/freescale/mx53ard/imximage_dd3.cfg Fabio Estevam <fabio.estevam@freescale.com>
+Active arm armv7 mx5 freescale mx53evk mx53evk mx53evk:IMX_CONFIG=board/freescale/mx53evk/imximage.cfg Jason Liu <r64343@freescale.com>
+Active arm armv7 mx5 freescale mx53loco mx53loco mx53loco:IMX_CONFIG=board/freescale/mx53loco/imximage.cfg Jason Liu <r64343@freescale.com>
+Active arm armv7 mx5 freescale mx53smd mx53smd mx53smd:IMX_CONFIG=board/freescale/mx53smd/imximage.cfg Fabio Estevam <fabio.estevam@freescale.com>
+Active arm armv7 mx5 genesi mx51_efikamx mx51_efikamx mx51_efikamx:MACH_TYPE=MACH_TYPE_MX51_EFIKAMX,IMX_CONFIG=board/genesi/mx51_efikamx/imximage_mx.cfg -
+Active arm armv7 mx5 genesi mx51_efikamx mx51_efikasb mx51_efikamx:MACH_TYPE=MACH_TYPE_MX51_EFIKASB,IMX_CONFIG=board/genesi/mx51_efikamx/imximage_sb.cfg -
+Active arm armv7 mx5 ttcontrol vision2 vision2 vision2:IMX_CONFIG=board/ttcontrol/vision2/imximage_hynix.cfg Stefano Babic <sbabic@denx.de>
+Active arm armv7 mx6 - wandboard wandboard_dl wandboard:IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6dl.cfg,MX6DL,DDR_MB=1024 Fabio Estevam <fabio.estevam@freescale.com>
+Active arm armv7 mx6 - wandboard wandboard_quad wandboard:IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6q2g.cfg,MX6Q,DDR_MB=2048 Fabio Estevam <fabio.estevam@freescale.com>
+Active arm armv7 mx6 - wandboard wandboard_solo wandboard:IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6s.cfg,MX6S,DDR_MB=512 Fabio Estevam <fabio.estevam@freescale.com>
+Active arm armv7 mx6 boundary nitrogen6x nitrogen6dl nitrogen6x:IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6dl.cfg,MX6DL,DDR_MB=1024 Eric Nelson <eric.nelson@boundarydevices.com>
+Active arm armv7 mx6 boundary nitrogen6x nitrogen6dl2g nitrogen6x:IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6dl2g.cfg,MX6DL,DDR_MB=2048 Eric Nelson <eric.nelson@boundarydevices.com>
+Active arm armv7 mx6 boundary nitrogen6x nitrogen6q nitrogen6x:IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6q.cfg,MX6Q,DDR_MB=1024 Eric Nelson <eric.nelson@boundarydevices.com>
+Active arm armv7 mx6 boundary nitrogen6x nitrogen6q2g nitrogen6x:IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6q2g.cfg,MX6Q,DDR_MB=2048 Eric Nelson <eric.nelson@boundarydevices.com>
+Active arm armv7 mx6 boundary nitrogen6x nitrogen6s nitrogen6x:IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6s.cfg,MX6S,DDR_MB=512 Eric Nelson <eric.nelson@boundarydevices.com>
+Active arm armv7 mx6 boundary nitrogen6x nitrogen6s1g nitrogen6x:IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6s1g.cfg,MX6S,DDR_MB=1024 Eric Nelson <eric.nelson@boundarydevices.com>
+Active arm armv7 mx6 congatec cgtqmx6eval cgtqmx6qeval cgtqmx6eval:IMX_CONFIG=board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg,MX6Q Leo Sartre <lsartre@adeneo-embedded.com>
+Active arm armv7 mx6 freescale mx6qarm2 mx6qarm2 mx6qarm2:IMX_CONFIG=board/freescale/mx6qarm2/imximage.cfg Jason Liu <r64343@freescale.com>
+Active arm armv7 mx6 freescale mx6qsabreauto mx6qsabreauto mx6qsabreauto:IMX_CONFIG=board/freescale/mx6qsabreauto/imximage.cfg,MX6Q Fabio Estevam <fabio.estevam@freescale.com>
+Active arm armv7 mx6 freescale mx6qsabrelite mx6qsabrelite mx6qsabrelite:IMX_CONFIG=board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg Jason Liu <r64343@freescale.com>
+Active arm armv7 mx6 freescale mx6sabresd mx6dlsabresd mx6sabresd:IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6dl.cfg,MX6DL Fabio Estevam <fabio.estevam@freescale.com>
+Active arm armv7 mx6 freescale mx6sabresd mx6qsabresd mx6sabresd:IMX_CONFIG=board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg,MX6Q Fabio Estevam <fabio.estevam@freescale.com>
+Active arm armv7 mx6 freescale mx6slevk mx6slevk mx6slevk:IMX_CONFIG=board/freescale/mx6slevk/imximage.cfg,MX6SL Fabio Estevam <fabio.estevam@freescale.com>
+Active arm armv7 mx6 freescale titanium titanium titanium:IMX_CONFIG=board/freescale/titanium/imximage.cfg Stefan Roese <sr@denx.de>
+Active arm armv7 omap3 - overo omap3_overo - Steve Sakoman <sakoman@gmail.com>
+Active arm armv7 omap3 - pandora omap3_pandora - Grazvydas Ignotas <notasas@gmail.com>
+Active arm armv7 omap3 8dtech eco5pk eco5pk - Raphael Assenat <raph@8d.com>
+Active arm armv7 omap3 comelit dig297 dig297 - Luca Ceresoli <luca.ceresoli@comelit.it>
+Active arm armv7 omap3 compulab cm_t35 cm_t35 - Igor Grinberg <grinberg@compulab.co.il>
+Active arm armv7 omap3 corscience tricorder tricorder - Thomas Weber <weber@corscience.de>
+Active arm armv7 omap3 htkw mcx mcx - Ilya Yanok <yanok@emcraft.com>
+Active arm armv7 omap3 isee igep00x0 igep0020 igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_ONENAND Enric Balletbo i Serra <eballetbo@iseebcn.com>
+Active arm armv7 omap3 isee igep00x0 igep0020_nand igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_NAND -
+Active arm armv7 omap3 isee igep00x0 igep0030 igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND Enric Balletbo i Serra <eballetbo@iseebcn.com>
+Active arm armv7 omap3 isee igep00x0 igep0030_nand igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_NAND -
+Active arm armv7 omap3 isee igep00x0 igep0032 igep00x0:MACH_TYPE=MACH_TYPE_IGEP0032,BOOT_ONENAND Enric Balletbo i Serra <eballetbo@iseebcn.com>
+Active arm armv7 omap3 logicpd am3517evm am3517_evm - Vaibhav Hiremath <hvaibhav@ti.com>
+Active arm armv7 omap3 logicpd omap3som omap3_logic - Peter Barada <peter.barada@logicpd.com>
+Active arm armv7 omap3 logicpd zoom1 omap3_zoom1 - Nishanth Menon <nm@ti.com>
+Active arm armv7 omap3 logicpd zoom2 omap3_zoom2 - Tom Rix <Tom.Rix@windriver.com>
+Active arm armv7 omap3 matrix_vision mvblx omap3_mvblx - Michael Jones <michael.jones@matrix-vision.de>
+Active arm armv7 omap3 nokia rx51 nokia_rx51 - Pali Roh??r <pali.rohar@gmail.com>
+Active arm armv7 omap3 technexion twister twister - Stefano Babic <sbabic@denx.de>
+Active arm armv7 omap3 teejet mt_ventoux mt_ventoux - Stefano Babic <sbabic@denx.de>
+Active arm armv7 omap3 ti am3517crane am3517_crane - Nagendra T S <nagendra@mistralsolutions.com>
+Active arm armv7 omap3 ti beagle omap3_beagle - Tom Rini <trini@ti.com>
+Active arm armv7 omap3 ti evm omap3_evm - Tom Rini <trini@ti.com>
+Active arm armv7 omap3 ti evm omap3_evm_quick_mmc - -
+Active arm armv7 omap3 ti evm omap3_evm_quick_nand - -
+Active arm armv7 omap3 ti sdp3430 omap3_sdp3430 - Nishanth Menon <nm@ti.com>
+Active arm armv7 omap3 timll devkit8000 devkit8000 - Thomas Weber <weber@corscience.de>
+Active arm armv7 omap4 ti panda omap4_panda - Sricharan R <r.sricharan@ti.com>
+Active arm armv7 omap4 ti sdp4430 omap4_sdp4430 - Sricharan R <r.sricharan@ti.com>
+Active arm armv7 omap5 ti dra7xx dra7xx_evm - Lokesh Vutla <lokeshvutla@ti.com>
+Active arm armv7 omap5 ti omap5_uevm omap5_uevm - -
+Active arm armv7 rmobile atmark-techno armadillo-800eva armadillo-800eva - Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
+Active arm armv7 rmobile kmc kzm9g kzm9g - Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>:Tetsuyuki Kobayashi <koba@kmckk.co.jp>
+Active arm armv7 s5pc1xx samsung goni s5p_goni - Minkyu Kang <mk7.kang@samsung.com>
+Active arm armv7 s5pc1xx samsung smdkc100 smdkc100 - Minkyu Kang <mk7.kang@samsung.com>
+Active arm armv7 socfpga altera socfpga socfpga_cyclone5 - Chin Liang See <clsee@altera.com>:Dinh Nguyen <dinguyen@altera.com>
+Active arm armv7 u8500 st-ericsson snowball snowball - Mathieu Poirier <mathieu.poirier@linaro.org>
+Active arm armv7 u8500 st-ericsson u8500 u8500_href - -
+Active arm armv7 vf610 freescale vf610twr vf610twr vf610twr:IMX_CONFIG=board/freescale/vf610twr/imximage.cfg Alison Wang <b18965@freescale.com>
+Active arm armv7 zynq xilinx zynq zynq - Michal Simek <monstr@monstr.eu>
+Active arm armv7 zynq xilinx zynq zynq_dcc zynq:ZYNQ_DCC Michal Simek <monstr@monstr.eu>
+Active arm armv7:arm720t tegra114 nvidia dalmore dalmore - Tom Warren <twarren@nvidia.com>
+Active arm armv7:arm720t tegra20 avionic-design medcom-wide medcom-wide - Thierry Reding <thierry.reding@avionic-design.de>
+Active arm armv7:arm720t tegra20 avionic-design plutux plutux - Thierry Reding <thierry.reding@avionic-design.de>
+Active arm armv7:arm720t tegra20 avionic-design tec tec - Thierry Reding <thierry.reding@avionic-design.de>
+Active arm armv7:arm720t tegra20 compal paz00 paz00 - Tom Warren <twarren@nvidia.com>:Stephen Warren <swarren@nvidia.com>
+Active arm armv7:arm720t tegra20 compulab trimslice trimslice - Tom Warren <twarren@nvidia.com>:Stephen Warren <swarren@nvidia.com>
+Active arm armv7:arm720t tegra20 nvidia harmony harmony - Tom Warren <twarren@nvidia.com>
+Active arm armv7:arm720t tegra20 nvidia seaboard seaboard - Tom Warren <twarren@nvidia.com>
+Active arm armv7:arm720t tegra20 nvidia ventana ventana - Tom Warren <twarren@nvidia.com>:Stephen Warren <swarren@nvidia.com>
+Active arm armv7:arm720t tegra20 nvidia whistler whistler - Tom Warren <twarren@nvidia.com>:Stephen Warren <swarren@nvidia.com>
+Active arm armv7:arm720t tegra20 toradex colibri_t20_iris colibri_t20_iris - Lucas Stach <dev@lynxeye.de>
+Active arm armv7:arm720t tegra30 nvidia beaver beaver - Tom Warren <twarren@nvidia.com>:Stephen Warren <swarren@nvidia.com>
+Active arm armv7:arm720t tegra30 nvidia cardhu cardhu - Tom Warren <twarren@nvidia.com>
+Active arm ixp - - - actux2 - Michael Schwingen <michael@schwingen.org>
+Active arm ixp - - - actux3 - Michael Schwingen <michael@schwingen.org>
+Active arm ixp - - - actux4 - Michael Schwingen <michael@schwingen.org>
+Active arm ixp - - - dvlhost - Michael Schwingen <michael@schwingen.org>
+Active arm ixp - - actux1 actux1_4_16 actux1:FLASH2X2 Michael Schwingen <michael@schwingen.org>
+Active arm ixp - - actux1 actux1_4_32 actux1:FLASH2X2,RAM_32MB Michael Schwingen <michael@schwingen.org>
+Active arm ixp - - actux1 actux1_8_16 actux1:FLASH1X8 Michael Schwingen <michael@schwingen.org>
+Active arm ixp - - actux1 actux1_8_32 actux1:FLASH1X8,RAM_32MB Michael Schwingen <michael@schwingen.org>
+Active arm ixp - prodrive pdnb3 pdnb3 - Stefan Roese <sr@denx.de>
+Active arm ixp - prodrive pdnb3 scpu pdnb3:SCPU Stefan Roese <sr@denx.de>
+Active arm pxa - - - balloon3 - Marek Vasut <marek.vasut@gmail.com>
+Active arm pxa - - - h2200 - Lukasz Dalek <luk0104@gmail.com>
+Active arm pxa - - - palmld - Marek Vasut <marek.vasut@gmail.com>
+Active arm pxa - - - palmtc - Marek Vasut <marek.vasut@gmail.com>
+Active arm pxa - - - palmtreo680 - Mike Dunn <mikedunn@newsguy.com>
+Active arm pxa - - - pxa255_idp - Cliff Brake <cliff.brake@gmail.com>
+Active arm pxa - - - trizepsiv - Stefano Babic <sbabic@denx.de>
+Active arm pxa - - - xaeniax - -
+Active arm pxa - - - zipitz2 - Marek Vasut <marek.vasut@gmail.com>
+Active arm pxa - - trizepsiv polaris trizepsiv:POLARIS Stefano Babic <sbabic@denx.de>
+Active arm pxa - - vpac270 vpac270_nor_128 vpac270:NOR,RAM_128M Marek Vasut <marek.vasut@gmail.com>
+Active arm pxa - - vpac270 vpac270_nor_256 vpac270:NOR,RAM_256M Marek Vasut <marek.vasut@gmail.com>
+Active arm pxa - - vpac270 vpac270_ond_256 vpac270:ONENAND,RAM_256M Marek Vasut <marek.vasut@gmail.com>
+Active arm pxa - icpdas lp8x4x lp8x4x - Sergey Yanovich <ynvich@gmail.com>
+Active arm pxa - toradex - colibri_pxa270 - Marek Vasut <marek.vasut@gmail.com>
+Active arm sa1100 - - - jornada - Kristoffer Ericson <kristoffer.ericson@gmail.com>
+Active avr32 at32ap at32ap700x atmel - atngw100 - Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
+Active avr32 at32ap at32ap700x atmel - atngw100mkii - Andreas Bie??mann <andreas.devel@googlemail.com>
+Active avr32 at32ap at32ap700x atmel atstk1000 atstk1002 - Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
+Active avr32 at32ap at32ap700x atmel atstk1000 atstk1003 - Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
+Active avr32 at32ap at32ap700x atmel atstk1000 atstk1004 - Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
+Active avr32 at32ap at32ap700x atmel atstk1000 atstk1006 - Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
+Active avr32 at32ap at32ap700x earthlcd - favr-32-ezkit - Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com>
+Active avr32 at32ap at32ap700x in-circuit - grasshopper - Andreas Bie??mann <andreas.devel@googlemail.com>
+Active avr32 at32ap at32ap700x mimc - mimc200 - Mark Jackson <mpfj@mimc.co.uk>
+Active avr32 at32ap at32ap700x miromico - hammerhead - Julien May <julien.may@miromico.ch>:Alex Raimondi <alex.raimondi@miromico.ch>
+Active blackfin blackfin - - - bct-brettl2 - Peter Meerwald <devel@bct-electronic.com>
+Active blackfin blackfin - - - bf506f-ezkit - Sonic Zhang <sonic.adi@gmail.com>:Blackfin Team <u-boot-devel@blackfin.uclinux.org>
+Active blackfin blackfin - - - bf518f-ezbrd - Sonic Zhang <sonic.adi@gmail.com>:Blackfin Team <u-boot-devel@blackfin.uclinux.org>
+Active blackfin blackfin - - - bf525-ucr2 - Haitao Zhang <hzhang@ucrobotics.com>:Chong Huang <chuang@ucrobotics.com>
+Active blackfin blackfin - - - bf526-ezbrd - Sonic Zhang <sonic.adi@gmail.com>:Blackfin Team <u-boot-devel@blackfin.uclinux.org>
+Active blackfin blackfin - - - bf527-ad7160-eval - Sonic Zhang <sonic.adi@gmail.com>:Blackfin Team <u-boot-devel@blackfin.uclinux.org>
+Active blackfin blackfin - - - bf527-ezkit - Sonic Zhang <sonic.adi@gmail.com>:Blackfin Team <u-boot-devel@blackfin.uclinux.org>
+Active blackfin blackfin - - - bf527-sdp - Sonic Zhang <sonic.adi@gmail.com>:Blackfin Team <u-boot-devel@blackfin.uclinux.org>
+Active blackfin blackfin - - - bf533-ezkit - Sonic Zhang <sonic.adi@gmail.com>:Blackfin Team <u-boot-devel@blackfin.uclinux.org>
+Active blackfin blackfin - - - bf533-stamp - Sonic Zhang <sonic.adi@gmail.com>:Blackfin Team <u-boot-devel@blackfin.uclinux.org>
+Active blackfin blackfin - - - bf537-minotaur - Martin Strubel <strubel@section5.ch>
+Active blackfin blackfin - - - bf537-pnav - Sonic Zhang <sonic.adi@gmail.com>:Blackfin Team <u-boot-devel@blackfin.uclinux.org>
+Active blackfin blackfin - - - bf537-srv1 - Martin Strubel <strubel@section5.ch>
+Active blackfin blackfin - - - bf537-stamp - Sonic Zhang <sonic.adi@gmail.com>:Blackfin Team <u-boot-devel@blackfin.uclinux.org>
+Active blackfin blackfin - - - bf538f-ezkit - Sonic Zhang <sonic.adi@gmail.com>:Blackfin Team <u-boot-devel@blackfin.uclinux.org>
+Active blackfin blackfin - - - bf548-ezkit - Sonic Zhang <sonic.adi@gmail.com>:Blackfin Team <u-boot-devel@blackfin.uclinux.org>
+Active blackfin blackfin - - - bf561-acvilon - Anton Shurpin <shurpin.aa@niistt.ru>:Valentin Yakovenkov <yakovenkov@niistt.ru>
+Active blackfin blackfin - - - bf561-ezkit - Sonic Zhang <sonic.adi@gmail.com>:Blackfin Team <u-boot-devel@blackfin.uclinux.org>
+Active blackfin blackfin - - - bf609-ezkit - Sonic Zhang <sonic.adi@gmail.com>:Blackfin Team <u-boot-devel@blackfin.uclinux.org>
+Active blackfin blackfin - - - blackstamp - Wojtek Skulski <skulski@pas.rochester.edu>:Wojtek Skulski <info@skutek.com>:Benjamin Matthews <mben12@gmail.com>
+Active blackfin blackfin - - - blackvme - Wojtek Skulski <skulski@pas.rochester.edu>:Wojtek Skulski <info@skutek.com>:Benjamin Matthews <mben12@gmail.com>
+Active blackfin blackfin - - - br4 - Dimitar Penev <dpn@switchfin.org>
+Active blackfin blackfin - - - cm-bf527 - Bluetechnix Tinyboards <bluetechnix@blackfin.uclinux.org>
+Active blackfin blackfin - - - cm-bf533 - Bluetechnix Tinyboards <bluetechnix@blackfin.uclinux.org>
+Active blackfin blackfin - - - cm-bf537e - Bluetechnix Tinyboards <bluetechnix@blackfin.uclinux.org>
+Active blackfin blackfin - - - cm-bf537u - Bluetechnix Tinyboards <bluetechnix@blackfin.uclinux.org>
+Active blackfin blackfin - - - cm-bf548 - Bluetechnix Tinyboards <bluetechnix@blackfin.uclinux.org>
+Active blackfin blackfin - - - cm-bf561 - Bluetechnix Tinyboards <bluetechnix@blackfin.uclinux.org>
+Active blackfin blackfin - - - dnp5370 - M.Hasewinkel <info@ssv-embedded.de>
+Active blackfin blackfin - - - ibf-dsp561 - I-SYST Micromodule <support@i-syst.com>
+Active blackfin blackfin - - - ip04 - Brent Kandetzki <brentk@teleco.com>
+Active blackfin blackfin - - - pr1 - Dimitar Penev <dpn@switchfin.org>
+Active blackfin blackfin - - - tcm-bf518 - Bluetechnix Tinyboards <bluetechnix@blackfin.uclinux.org>
+Active blackfin blackfin - - - tcm-bf537 - Bluetechnix Tinyboards <bluetechnix@blackfin.uclinux.org>
+Active blackfin blackfin - - bf527-ezkit bf527-ezkit-v2 bf527-ezkit:BF527_EZKIT_REV_2_1 Sonic Zhang <sonic.adi@gmail.com>:Blackfin Team <u-boot-devel@blackfin.uclinux.org>
+Active m68k mcf5227x - freescale m52277evb M52277EVB M52277EVB:SYS_SPANSION_BOOT,SYS_TEXT_BASE=0x00000000 TsiChung Liew <Tsi-Chung.Liew@freescale.com>
+Active m68k mcf5227x - freescale m52277evb M52277EVB_stmicro M52277EVB:CF_SBF,SYS_STMICRO_BOOT,SYS_TEXT_BASE=0x43E00000 TsiChung Liew <Tsi-Chung.Liew@freescale.com>
+Active m68k mcf523x - freescale m5235evb M5235EVB M5235EVB:SYS_TEXT_BASE=0xFFE00000 TsiChung Liew <Tsi-Chung.Liew@freescale.com>
+Active m68k mcf523x - freescale m5235evb M5235EVB_Flash32 M5235EVB:NORFLASH_PS32BIT,SYS_TEXT_BASE=0xFFC00000 TsiChung Liew <Tsi-Chung.Liew@freescale.com>
+Active m68k mcf52x2 - - - idmr - -
+Active m68k mcf52x2 - - cobra5272 cobra5272 - -
+Active m68k mcf52x2 - BuS eb_cpu5282 eb_cpu5282 eb_cpu5282:SYS_TEXT_BASE=0xFF000000,SYS_MONITOR_BASE=0xFF000400 Jens Scharsig <esw@bus-elektronik.de>
+Active m68k mcf52x2 - BuS eb_cpu5282 eb_cpu5282_internal eb_cpu5282:SYS_TEXT_BASE=0xF0000000,SYS_MONITOR_BASE=0xF0000418 Jens Scharsig <esw@bus-elektronik.de>
+Active m68k mcf52x2 - esd tasreg TASREG - Matthias Fuchs <matthias.fuchs@esd-electronics.com>
+Active m68k mcf52x2 - freescale m5208evbe M5208EVBE - -
+Active m68k mcf52x2 - freescale m5249evb M5249EVB - -
+Active m68k mcf52x2 - freescale m5253demo M5253DEMO - TsiChung Liew <Tsi-Chung.Liew@freescale.com>
+Active m68k mcf52x2 - freescale m5253evbe M5253EVBE - Hayden Fraser <Hayden.Fraser@freescale.com>
+Active m68k mcf52x2 - freescale m5271evb M5271EVB - -
+Active m68k mcf52x2 - freescale m5272c3 M5272C3 - -
+Active m68k mcf52x2 - freescale m5275evb M5275EVB - -
+Active m68k mcf52x2 - freescale m5282evb M5282EVB - -
+Active m68k mcf532x - astro mcf5373l astro_mcf5373l - Wolfgang Wegner <w.wegner@astro-kom.de>
+Active m68k mcf532x - freescale m53017evb M53017EVB - TsiChung Liew <Tsi-Chung.Liew@freescale.com>
+Active m68k mcf532x - freescale m5329evb M5329AFEE M5329EVB:NANDFLASH_SIZE=0 TsiChung Liew <Tsi-Chung.Liew@freescale.com>
+Active m68k mcf532x - freescale m5329evb M5329BFEE M5329EVB:NANDFLASH_SIZE=16 TsiChung Liew <Tsi-Chung.Liew@freescale.com>
+Active m68k mcf532x - freescale m5373evb M5373EVB M5373EVB:NANDFLASH_SIZE=16 TsiChung Liew <Tsi-Chung.Liew@freescale.com>
+Active m68k mcf5445x - freescale m54418twr M54418TWR M54418TWR:CF_SBF,SYS_SERIAL_BOOT,SYS_TEXT_BASE=0x47E00000,SYS_INPUT_CLKSRC=50000000 -
+Active m68k mcf5445x - freescale m54418twr M54418TWR_nand_mii M54418TWR:SYS_NAND_BOOT,SYS_TEXT_BASE=0x47E00000,SYS_INPUT_CLKSRC=25000000 -
+Active m68k mcf5445x - freescale m54418twr M54418TWR_nand_rmii M54418TWR:SYS_NAND_BOOT,SYS_TEXT_BASE=0x47E00000,SYS_INPUT_CLKSRC=50000000 -
+Active m68k mcf5445x - freescale m54418twr M54418TWR_nand_rmii_lowfreq M54418TWR:SYS_NAND_BOOT,LOW_MCFCLK,SYS_TEXT_BASE=0x47E00000,SYS_INPUT_CLKSRC=50000000 -
+Active m68k mcf5445x - freescale m54418twr M54418TWR_serial_mii M54418TWR:CF_SBF,SYS_SERIAL_BOOT,SYS_TEXT_BASE=0x47E00000,SYS_INPUT_CLKSRC=25000000 -
+Active m68k mcf5445x - freescale m54418twr M54418TWR_serial_rmii M54418TWR:CF_SBF,SYS_SERIAL_BOOT,SYS_TEXT_BASE=0x47E00000,SYS_INPUT_CLKSRC=50000000 -
+Active m68k mcf5445x - freescale m54451evb M54451EVB M54451EVB:SYS_TEXT_BASE=0x00000000,SYS_INPUT_CLKSRC=24000000 -
+Active m68k mcf5445x - freescale m54451evb M54451EVB_stmicro M54451EVB:CF_SBF,SYS_STMICRO_BOOT,SYS_TEXT_BASE=0x47e00000,SYS_INPUT_CLKSRC=24000000 -
+Active m68k mcf5445x - freescale m54455evb M54455EVB M54455EVB:SYS_ATMEL_BOOT,SYS_TEXT_BASE=0x04000000,SYS_INPUT_CLKSRC=33333333 TsiChung Liew <Tsi-Chung.Liew@freescale.com>
+Active m68k mcf5445x - freescale m54455evb M54455EVB_a66 M54455EVB:SYS_ATMEL_BOOT,SYS_TEXT_BASE=0x04000000,SYS_INPUT_CLKSRC=66666666 TsiChung Liew <Tsi-Chung.Liew@freescale.com>
+Active m68k mcf5445x - freescale m54455evb M54455EVB_i66 M54455EVB:SYS_INTEL_BOOT,SYS_TEXT_BASE=0x00000000,SYS_INPUT_CLKSRC=66666666 TsiChung Liew <Tsi-Chung.Liew@freescale.com>
+Active m68k mcf5445x - freescale m54455evb M54455EVB_intel M54455EVB:SYS_INTEL_BOOT,SYS_TEXT_BASE=0x00000000,SYS_INPUT_CLKSRC=33333333 TsiChung Liew <Tsi-Chung.Liew@freescale.com>
+Active m68k mcf5445x - freescale m54455evb M54455EVB_stm33 M54455EVB:SYS_STMICRO_BOOT,CF_SBF,SYS_TEXT_BASE=0x4FE00000,SYS_INPUT_CLKSRC=33333333 TsiChung Liew <Tsi-Chung.Liew@freescale.com>
+Active m68k mcf547x_8x - freescale m547xevb M5475AFE M5475EVB:SYS_BUSCLK=133333333,SYS_BOOTSZ=2,SYS_DRAMSZ=64 TsiChung Liew <Tsi-Chung.Liew@freescale.com>
+Active m68k mcf547x_8x - freescale m547xevb M5475BFE M5475EVB:SYS_BUSCLK=133333333,SYS_BOOTSZ=2,SYS_DRAMSZ=64,SYS_NOR1SZ=16 TsiChung Liew <Tsi-Chung.Liew@freescale.com>
+Active m68k mcf547x_8x - freescale m547xevb M5475CFE M5475EVB:SYS_BUSCLK=133333333,SYS_BOOTSZ=2,SYS_DRAMSZ=64,SYS_NOR1SZ=16,SYS_VIDEO,SYS_USBCTRL TsiChung Liew <Tsi-Chung.Liew@freescale.com>
+Active m68k mcf547x_8x - freescale m547xevb M5475DFE M5475EVB:SYS_BUSCLK=133333333,SYS_BOOTSZ=2,SYS_DRAMSZ=64,SYS_USBCTRL TsiChung Liew <Tsi-Chung.Liew@freescale.com>
+Active m68k mcf547x_8x - freescale m547xevb M5475EFE M5475EVB:SYS_BUSCLK=133333333,SYS_BOOTSZ=2,SYS_DRAMSZ=64,SYS_VIDEO,SYS_USBCTRL TsiChung Liew <Tsi-Chung.Liew@freescale.com>
+Active m68k mcf547x_8x - freescale m547xevb M5475FFE M5475EVB:SYS_BUSCLK=133333333,SYS_BOOTSZ=2,SYS_DRAMSZ=64,SYS_NOR1SZ=32,SYS_VIDEO,SYS_USBCTRL,SYS_DRAMSZ1=64 TsiChung Liew <Tsi-Chung.Liew@freescale.com>
+Active m68k mcf547x_8x - freescale m547xevb M5475GFE M5475EVB:SYS_BUSCLK=133333333,SYS_BOOTSZ=4,SYS_DRAMSZ=64 TsiChung Liew <Tsi-Chung.Liew@freescale.com>
+Active m68k mcf547x_8x - freescale m548xevb M5485AFE M5485EVB:SYS_BUSCLK=100000000,SYS_BOOTSZ=2,SYS_DRAMSZ=64 TsiChung Liew <Tsi-Chung.Liew@freescale.com>
+Active m68k mcf547x_8x - freescale m548xevb M5485BFE M5485EVB:SYS_BUSCLK=100000000,SYS_BOOTSZ=2,SYS_DRAMSZ=64,SYS_NOR1SZ=16 TsiChung Liew <Tsi-Chung.Liew@freescale.com>
+Active m68k mcf547x_8x - freescale m548xevb M5485CFE M5485EVB:SYS_BUSCLK=100000000,SYS_BOOTSZ=2,SYS_DRAMSZ=64,SYS_NOR1SZ=16,SYS_VIDEO,SYS_USBCTRL TsiChung Liew <Tsi-Chung.Liew@freescale.com>
+Active m68k mcf547x_8x - freescale m548xevb M5485DFE M5485EVB:SYS_BUSCLK=100000000,SYS_BOOTSZ=2,SYS_DRAMSZ=64,SYS_USBCTRL TsiChung Liew <Tsi-Chung.Liew@freescale.com>
+Active m68k mcf547x_8x - freescale m548xevb M5485EFE M5485EVB:SYS_BUSCLK=100000000,SYS_BOOTSZ=2,SYS_DRAMSZ=64,SYS_VIDEO,SYS_USBCTRL TsiChung Liew <Tsi-Chung.Liew@freescale.com>
+Active m68k mcf547x_8x - freescale m548xevb M5485FFE M5485EVB:SYS_BUSCLK=100000000,SYS_BOOTSZ=2,SYS_DRAMSZ=64,SYS_NOR1SZ=32,SYS_VIDEO,SYS_USBCTRL,SYS_DRAMSZ1=64 TsiChung Liew <Tsi-Chung.Liew@freescale.com>
+Active m68k mcf547x_8x - freescale m548xevb M5485GFE M5485EVB:SYS_BUSCLK=100000000,SYS_BOOTSZ=4,SYS_DRAMSZ=64 TsiChung Liew <Tsi-Chung.Liew@freescale.com>
+Active m68k mcf547x_8x - freescale m548xevb M5485HFE M5485EVB:SYS_BUSCLK=100000000,SYS_BOOTSZ=2,SYS_DRAMSZ=64,SYS_NOR1SZ=16,SYS_VIDEO TsiChung Liew <Tsi-Chung.Liew@freescale.com>
+Active microblaze microblaze - xilinx microblaze-generic microblaze-generic - Michal Simek <monstr@monstr.eu>
+Active mips mips32 - - qemu-malta qemu_malta qemu-malta:MIPS32,SYS_BIG_ENDIAN -
+Active mips mips32 - - qemu-malta qemu_maltael qemu-malta:MIPS32,SYS_LITTLE_ENDIAN -
+Active mips mips32 - - qemu-mips qemu_mips qemu-mips:SYS_BIG_ENDIAN Vlad Lungu <vlad.lungu@windriver.com>
+Active mips mips32 - - qemu-mips qemu_mipsel qemu-mips:SYS_LITTLE_ENDIAN -
+Active mips mips32 - micronas vct vct_platinum vct:VCT_PLATINUM -
+Active mips mips32 - micronas vct vct_platinum_onenand vct:VCT_PLATINUM,VCT_ONENAND -
+Active mips mips32 - micronas vct vct_platinum_onenand_small vct:VCT_PLATINUM,VCT_ONENAND,VCT_SMALL_IMAGE -
+Active mips mips32 - micronas vct vct_platinum_small vct:VCT_PLATINUM,VCT_SMALL_IMAGE -
+Active mips mips32 - micronas vct vct_platinumavc vct:VCT_PLATINUMAVC -
+Active mips mips32 - micronas vct vct_platinumavc_onenand vct:VCT_PLATINUMAVC,VCT_ONENAND -
+Active mips mips32 - micronas vct vct_platinumavc_onenand_small vct:VCT_PLATINUMAVC,VCT_ONENAND,VCT_SMALL_IMAGE -
+Active mips mips32 - micronas vct vct_platinumavc_small vct:VCT_PLATINUMAVC,VCT_SMALL_IMAGE -
+Active mips mips32 - micronas vct vct_premium vct:VCT_PREMIUM -
+Active mips mips32 - micronas vct vct_premium_onenand vct:VCT_PREMIUM,VCT_ONENAND -
+Active mips mips32 - micronas vct vct_premium_onenand_small vct:VCT_PREMIUM,VCT_ONENAND,VCT_SMALL_IMAGE -
+Active mips mips32 - micronas vct vct_premium_small vct:VCT_PREMIUM,VCT_SMALL_IMAGE -
+Active mips mips32 au1x00 - pb1x00 pb1000 pb1x00:PB1000 -
+Active mips mips32 incaip - incaip incaip - Wolfgang Denk <wd@denx.de>
+Active mips mips32 incaip - incaip incaip_100MHz incaip:CPU_CLOCK_RATE=100000000 Wolfgang Denk <wd@denx.de>
+Active mips mips32 incaip - incaip incaip_133MHz incaip:CPU_CLOCK_RATE=133000000 Wolfgang Denk <wd@denx.de>
+Active mips mips32 incaip - incaip incaip_150MHz incaip:CPU_CLOCK_RATE=150000000 Wolfgang Denk <wd@denx.de>
+Active mips mips64 - - qemu-mips qemu_mips64 qemu-mips64:SYS_BIG_ENDIAN -
+Active mips mips64 - - qemu-mips qemu_mips64el qemu-mips64:SYS_LITTLE_ENDIAN -
+Active nds32 n1213 ag101 AndesTech adp-ag101 adp-ag101 - Macpaul Lin <macpaul@andestech.com>
+Active nds32 n1213 ag101 AndesTech adp-ag101p adp-ag101p - Macpaul Lin <macpaul@andestech.com>
+Active nds32 n1213 ag102 AndesTech adp-ag102 adp-ag102 - Macpaul Lin <macpaul@andestech.com>
+Active nios2 nios2 - altera nios2-generic nios2-generic - Scott McNutt <smcnutt@psyent.com>
+Active nios2 nios2 - psyent pci5441 PCI5441 - Scott McNutt <smcnutt@psyent.com>
+Active nios2 nios2 - psyent pk1c20 PK1C20 - Scott McNutt <smcnutt@psyent.com>
+Active openrisc or1200 - openrisc openrisc-generic openrisc-generic - Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
+Active powerpc 74xx_7xx - - - ppmc7xx - -
+Active powerpc 74xx_7xx - - evb64260 P3G4 - Wolfgang Denk <wd@denx.de>:-
+Active powerpc 74xx_7xx - - evb64260 ZUMA - Nye Liu <nyet@zumanetworks.com>:-
+Active powerpc 74xx_7xx - eltec elppc ELPPC - -
+Active powerpc 74xx_7xx - esd cpci750 CPCI750 - Reinhard Arlt <reinhard.arlt@esd-electronics.com>
+Active powerpc 74xx_7xx - freescale mpc7448hpc2 mpc7448hpc2 - Roy Zang <tie-fei.zang@freescale.com>
+Active powerpc 74xx_7xx - Marvell db64360 DB64360 - -
+Active powerpc 74xx_7xx - Marvell db64460 DB64460 - -
+Active powerpc 74xx_7xx - prodrive p3mx p3m7448 p3mx:P3M7448 Stefan Roese <sr@denx.de>
+Active powerpc 74xx_7xx - prodrive p3mx p3m750 p3mx:P3M750 Stefan Roese <sr@denx.de>
+Active powerpc mpc512x - - - pdm360ng - Michael Weiss <michael.weiss@ifm.com>
+Active powerpc mpc512x - davedenx - aria - Wolfgang Denk <wd@denx.de>
+Active powerpc mpc512x - esd - mecp5123 - Reinhard Arlt <reinhard.arlt@esd-electronics.com>
+Active powerpc mpc512x - freescale mpc5121ads mpc5121ads - -
+Active powerpc mpc512x - freescale mpc5121ads mpc5121ads_rev2 mpc5121ads:MPC5121ADS_REV2 -
+Active powerpc mpc512x - ifm ac14xx ac14xx - Anatolij Gustschin <agust@denx.de>
+Active powerpc mpc5xx - - cmi cmi_mpc5xx - -
+Active powerpc mpc5xx - mpl pati PATI - -
+Active powerpc mpc5xxx - - - canmb - -
+Active powerpc mpc5xxx - - - cm5200 - -
+Active powerpc mpc5xxx - - - inka4x0 - Detlev Zundel <dzu@denx.de>
+Active powerpc mpc5xxx - - - ipek01 - Wolfgang Grandegger <wg@denx.de>
+Active powerpc mpc5xxx - - - jupiter - Heiko Schocher <hs@denx.de>
+Active powerpc mpc5xxx - - - motionpro - -
+Active powerpc mpc5xxx - - - munices - -
+Active powerpc mpc5xxx - - - v38b - -
+Active powerpc mpc5xxx - - a3m071 a3m071 - Stefan Roese <sr@denx.de>
+Active powerpc mpc5xxx - - a3m071 a4m2k a3m071:A4M2K Stefan Roese <sr@denx.de>
+Active powerpc mpc5xxx - - a4m072 a4m072 - Sergei Poselenov <sposelenov@emcraft.com>
+Active powerpc mpc5xxx - - bc3450 BC3450 - -
+Active powerpc mpc5xxx - - galaxy5200 galaxy5200 galaxy5200:galaxy5200 Eric Millbrandt <emillbrandt@dekaresearch.com>
+Active powerpc mpc5xxx - - galaxy5200 galaxy5200_LOWBOOT galaxy5200:galaxy5200_LOWBOOT Eric Millbrandt <emillbrandt@dekaresearch.com>
+Active powerpc mpc5xxx - - icecube icecube_5200 IceCube Wolfgang Denk <wd@denx.de>
+Active powerpc mpc5xxx - - icecube icecube_5200_DDR IceCube:MPC5200_DDR -
+Active powerpc mpc5xxx - - icecube icecube_5200_DDR_LOWBOOT IceCube:SYS_TEXT_BASE=0xFF800000,MPC5200_DDR -
+Active powerpc mpc5xxx - - icecube icecube_5200_DDR_LOWBOOT08 IceCube:SYS_TEXT_BASE=0xFF800000,MPC5200_DDR -
+Active powerpc mpc5xxx - - icecube icecube_5200_LOWBOOT IceCube:SYS_TEXT_BASE=0xFF000000 -
+Active powerpc mpc5xxx - - icecube icecube_5200_LOWBOOT08 IceCube:SYS_TEXT_BASE=0xFF800000 -
+Active powerpc mpc5xxx - - icecube Lite5200 IceCube -
+Active powerpc mpc5xxx - - icecube Lite5200_LOWBOOT IceCube:SYS_TEXT_BASE=0xFF000000 -
+Active powerpc mpc5xxx - - icecube Lite5200_LOWBOOT08 IceCube:SYS_TEXT_BASE=0xFF800000 -
+Active powerpc mpc5xxx - - icecube lite5200b IceCube:MPC5200_DDR,LITE5200B -
+Active powerpc mpc5xxx - - icecube lite5200b_LOWBOOT IceCube:MPC5200_DDR,LITE5200B,SYS_TEXT_BASE=0xFF000000 -
+Active powerpc mpc5xxx - - icecube lite5200b_PM IceCube:MPC5200_DDR,LITE5200B,LITE5200B_PM -
+Active powerpc mpc5xxx - - mcc200 mcc200 mcc200 -
+Active powerpc mpc5xxx - - mcc200 mcc200_COM12 mcc200:CONSOLE_COM12 -
+Active powerpc mpc5xxx - - mcc200 mcc200_COM12_highboot mcc200:CONSOLE_COM12,SYS_TEXT_BASE=0xFFF00000 -
+Active powerpc mpc5xxx - - mcc200 mcc200_COM12_highboot_SDRAM mcc200:CONSOLE_COM12,SYS_TEXT_BASE=0xFFF00000,MCC200_SDRAM -
+Active powerpc mpc5xxx - - mcc200 mcc200_COM12_SDRAM mcc200:CONSOLE_COM12,MCC200_SDRAM -
+Active powerpc mpc5xxx - - mcc200 mcc200_highboot mcc200:SYS_TEXT_BASE=0xFFF00000 -
+Active powerpc mpc5xxx - - mcc200 mcc200_highboot_SDRAM mcc200:SYS_TEXT_BASE=0xFFF00000,MCC200_SDRAM -
+Active powerpc mpc5xxx - - mcc200 mcc200_SDRAM mcc200:MCC200_SDRAM -
+Active powerpc mpc5xxx - - mcc200 prs200 mcc200:PRS200,MCC200_SDRAM -
+Active powerpc mpc5xxx - - mcc200 prs200_DDR mcc200:PRS200 -
+Active powerpc mpc5xxx - - mcc200 prs200_highboot mcc200:PRS200,SYS_TEXT_BASE=0xFFF00000,MCC200_SDRAM -
+Active powerpc mpc5xxx - - mcc200 prs200_highboot_DDR mcc200:PRS200,SYS_TEXT_BASE=0xFFF00000 -
+Active powerpc mpc5xxx - - pm520 PM520 - Josef Wagner <Wagner@Microsys.de>
+Active powerpc mpc5xxx - - pm520 PM520_DDR PM520:MPC5200_DDR Josef Wagner <Wagner@Microsys.de>
+Active powerpc mpc5xxx - - pm520 PM520_ROMBOOT PM520:BOOT_ROM Josef Wagner <Wagner@Microsys.de>
+Active powerpc mpc5xxx - - pm520 PM520_ROMBOOT_DDR PM520:MPC5200_DDR,BOOT_ROM Josef Wagner <Wagner@Microsys.de>
+Active powerpc mpc5xxx - - total5200 Total5200 Total5200:TOTAL5200_REV=1 -
+Active powerpc mpc5xxx - - total5200 Total5200_lowboot Total5200:TOTAL5200_REV=1,SYS_TEXT_BASE=0xFE000000 -
+Active powerpc mpc5xxx - - total5200 Total5200_Rev2 Total5200:TOTAL5200_REV=2 -
+Active powerpc mpc5xxx - - total5200 Total5200_Rev2_lowboot Total5200:TOTAL5200_REV=2,SYS_TEXT_BASE=0xFE000000 -
+Active powerpc mpc5xxx - emk top5200 EVAL5200 TOP5200:EVAL5200 Reinhard Meyer <reinhard.meyer@emk-elektronik.de>
+Active powerpc mpc5xxx - emk top5200 MINI5200 TOP5200:MINI5200 Reinhard Meyer <reinhard.meyer@emk-elektronik.de>
+Active powerpc mpc5xxx - emk top5200 TOP5200 TOP5200:TOP5200 Reinhard Meyer <reinhard.meyer@emk-elektronik.de>
+Active powerpc mpc5xxx - esd - cpci5200 - Reinhard Arlt <reinhard.arlt@esd-electronics.com>
+Active powerpc mpc5xxx - esd - mecp5200 - Reinhard Arlt <reinhard.arlt@esd-electronics.com>
+Active powerpc mpc5xxx - esd - pf5200 - Reinhard Arlt <reinhard.arlt@esd-electronics.com>
+Active powerpc mpc5xxx - ifm o2dnt2 O2D o2d Anatolij Gustschin <agust@denx.de>
+Active powerpc mpc5xxx - ifm o2dnt2 O2D300 o2d300 Anatolij Gustschin <agust@denx.de>
+Active powerpc mpc5xxx - ifm o2dnt2 O2DNT2 o2dnt2 Anatolij Gustschin <agust@denx.de>
+Active powerpc mpc5xxx - ifm o2dnt2 O2DNT2_RAMBOOT o2dnt2:SYS_TEXT_BASE=0x00100000 Anatolij Gustschin <agust@denx.de>
+Active powerpc mpc5xxx - ifm o2dnt2 O2I o2i Anatolij Gustschin <agust@denx.de>
+Active powerpc mpc5xxx - ifm o2dnt2 O2MNT o2mnt Anatolij Gustschin <agust@denx.de>
+Active powerpc mpc5xxx - ifm o2dnt2 O2MNT_O2M110 o2mnt:IFM_SENSOR_TYPE="O2M110" Anatolij Gustschin <agust@denx.de>
+Active powerpc mpc5xxx - ifm o2dnt2 O2MNT_O2M112 o2mnt:IFM_SENSOR_TYPE="O2M112" Anatolij Gustschin <agust@denx.de>
+Active powerpc mpc5xxx - ifm o2dnt2 O2MNT_O2M113 o2mnt:IFM_SENSOR_TYPE="O2M113" Anatolij Gustschin <agust@denx.de>
+Active powerpc mpc5xxx - ifm o2dnt2 O3DNT o3dnt Anatolij Gustschin <agust@denx.de>
+Active powerpc mpc5xxx - intercontrol digsy_mtc digsy_mtc - Werner Pfister <Pfister_Werner@intercontrol.de>
+Active powerpc mpc5xxx - intercontrol digsy_mtc digsy_mtc_RAMBOOT digsy_mtc:SYS_TEXT_BASE=0x00100000 Werner Pfister <Pfister_Werner@intercontrol.de>
+Active powerpc mpc5xxx - intercontrol digsy_mtc digsy_mtc_rev5 digsy_mtc:DIGSY_REV5 Werner Pfister <Pfister_Werner@intercontrol.de>
+Active powerpc mpc5xxx - intercontrol digsy_mtc digsy_mtc_rev5_RAMBOOT digsy_mtc:SYS_TEXT_BASE=0x00100000,DIGSY_REV5 Werner Pfister <Pfister_Werner@intercontrol.de>
+Active powerpc mpc5xxx - manroland - hmi1001 - -
+Active powerpc mpc5xxx - manroland - mucmc52 - Heiko Schocher <hs@denx.de>
+Active powerpc mpc5xxx - manroland - uc101 - Heiko Schocher <hs@denx.de>
+Active powerpc mpc5xxx - matrix_vision mvbc_p MVBC_P MVBC_P:MVBC_P Andre Schwarz <andre.schwarz@matrix-vision.de>
+Active powerpc mpc5xxx - matrix_vision mvsmr MVSMR - Andre Schwarz <andre.schwarz@matrix-vision.de>
+Active powerpc mpc5xxx - phytec pcm030 pcm030 pcm030 Jon Smirl <jonsmirl@gmail.com>
+Active powerpc mpc5xxx - phytec pcm030 pcm030_LOWBOOT pcm030:SYS_TEXT_BASE=0xFF000000 Jon Smirl <jonsmirl@gmail.com>
+Active powerpc mpc5xxx - tqc tqm5200 aev - -
+Active powerpc mpc5xxx - tqc tqm5200 cam5200 TQM5200:CAM5200,TQM5200S,TQM5200_B -
+Active powerpc mpc5xxx - tqc tqm5200 cam5200_niosflash TQM5200:CAM5200,TQM5200S,TQM5200_B,CAM5200_NIOSFLASH -
+Active powerpc mpc5xxx - tqc tqm5200 charon charon Heiko Schocher <hs@denx.de>
+Active powerpc mpc5xxx - tqc tqm5200 fo300 TQM5200:FO300 -
+Active powerpc mpc5xxx - tqc tqm5200 MiniFAP TQM5200:MINIFAP -
+Active powerpc mpc5xxx - tqc tqm5200 TB5200 - -
+Active powerpc mpc5xxx - tqc tqm5200 TB5200_B TB5200:TQM5200_B -
+Active powerpc mpc5xxx - tqc tqm5200 TQM5200 TQM5200: -
+Active powerpc mpc5xxx - tqc tqm5200 TQM5200_B TQM5200:TQM5200_B -
+Active powerpc mpc5xxx - tqc tqm5200 TQM5200_B_HIGHBOOT TQM5200:TQM5200_B,SYS_TEXT_BASE=0xFFF00000 -
+Active powerpc mpc5xxx - tqc tqm5200 TQM5200_STK100 TQM5200:STK52XX_REV100 -
+Active powerpc mpc5xxx - tqc tqm5200 TQM5200S TQM5200:TQM5200_B,TQM5200S -
+Active powerpc mpc5xxx - tqc tqm5200 TQM5200S_HIGHBOOT TQM5200:TQM5200_B,TQM5200S,SYS_TEXT_BASE=0xFFF00000 -
+Active powerpc mpc824x - - - utx8245 - Greg Allen <gallen@arlut.utexas.edu>
+Active powerpc mpc824x - - a3000 A3000 - -
+Active powerpc mpc824x - - cpc45 CPC45 CPC45 Josef Wagner <Wagner@Microsys.de>
+Active powerpc mpc824x - - cpc45 CPC45_ROMBOOT CPC45:BOOT_ROM Josef Wagner <Wagner@Microsys.de>
+Active powerpc mpc824x - - cu824 CU824 - Wolfgang Denk <wd@denx.de>
+Active powerpc mpc824x - - eXalion eXalion - Torsten Demke <torsten.demke@fci.com>
+Active powerpc mpc824x - - hidden_dragon HIDDEN_DRAGON - Yusdi Santoso <yusdi_santoso@adaptec.com>
+Active powerpc mpc824x - - linkstation linkstation_HGLAN linkstation:HGLAN=1 Guennadi Liakhovetski <g.liakhovetski@gmx.de>
+Active powerpc mpc824x - - musenki MUSENKI - Jim Thompson <jim@musenki.com>
+Active powerpc mpc824x - - mvblue MVBLUE - -
+Active powerpc mpc824x - - pn62 PN62 - Wolfgang Grandegger <wg@denx.de>
+Active powerpc mpc824x - - sandpoint Sandpoint8240 - Wolfgang Denk <wd@denx.de>
+Active powerpc mpc824x - - sandpoint Sandpoint8245 - Jim Thompson <jim@musenki.com>
+Active powerpc mpc824x - etin - debris - Sangmoon Kim <dogoil@etinsys.com>
+Active powerpc mpc824x - etin - kvme080 - Sangmoon Kim <dogoil@etinsys.com>
+Active powerpc mpc8260 - - - atc - Wolfgang Denk <wd@denx.de>
+Active powerpc mpc8260 - - - ep8260 - Frank Panno <fpanno@delphintech.com>
+Active powerpc mpc8260 - - - ep82xxm - -
+Active powerpc mpc8260 - - - gw8260 - Oliver Brown <obrown@adventnetworks.com>
+Active powerpc mpc8260 - - - hymod - Murray Jensen <Murray.Jensen@csiro.au>
+Active powerpc mpc8260 - - - ppmc8260 - Brad Kemp <Brad.Kemp@seranoa.com>
+Active powerpc mpc8260 - - - sacsng - Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com>
+Active powerpc mpc8260 - - cogent cogent_mpc8260 - Murray Jensen <Murray.Jensen@csiro.au>
+Active powerpc mpc8260 - - cpu86 CPU86 CPU86 Wolfgang Denk <wd@denx.de>
+Active powerpc mpc8260 - - cpu86 CPU86_ROMBOOT CPU86:BOOT_ROM Wolfgang Denk <wd@denx.de>
+Active powerpc mpc8260 - - cpu87 CPU87 CPU87 -
+Active powerpc mpc8260 - - cpu87 CPU87_ROMBOOT CPU87:BOOT_ROM -
+Active powerpc mpc8260 - - ep8248 ep8248 - Yuli Barcohen <yuli@arabellasw.com>
+Active powerpc mpc8260 - - ep8248 ep8248E ep8248 Yuli Barcohen <yuli@arabellasw.com>
+Active powerpc mpc8260 - - ids8247 IDS8247 - Heiko Schocher <hs@denx.de>
+Active powerpc mpc8260 - - iphase4539 IPHASE4539 - Wolfgang Grandegger <wg@denx.de>
+Active powerpc mpc8260 - - ispan ISPAN - Yuli Barcohen <yuli@arabellasw.com>
+Active powerpc mpc8260 - - ispan ISPAN_REVB ISPAN:SYS_REV_B Yuli Barcohen <yuli@arabellasw.com>
+Active powerpc mpc8260 - - muas3001 muas3001 - Heiko Schocher <hs@denx.de>
+Active powerpc mpc8260 - - muas3001 muas3001_dev muas3001:MUAS_DEV_BOARD Heiko Schocher <hs@denx.de>
+Active powerpc mpc8260 - - pm826 PM825 PM826:PCI,SYS_TEXT_BASE=0xFF000000 Wolfgang Denk <wd@denx.de>
+Active powerpc mpc8260 - - pm826 PM825_BIGFLASH PM826:PCI,FLASH_32MB,SYS_TEXT_BASE=0x40000000 Wolfgang Denk <wd@denx.de>
+Active powerpc mpc8260 - - pm826 PM825_ROMBOOT PM826:PCI,BOOT_ROM,SYS_TEXT_BASE=0xFF800000 Wolfgang Denk <wd@denx.de>
+Active powerpc mpc8260 - - pm826 PM825_ROMBOOT_BIGFLASH PM826:PCI,BOOT_ROM,FLASH_32MB,SYS_TEXT_BASE=0xFF800000 Wolfgang Denk <wd@denx.de>
+Active powerpc mpc8260 - - pm826 PM826 PM826:SYS_TEXT_BASE=0xFF000000 Wolfgang Denk <wd@denx.de>
+Active powerpc mpc8260 - - pm826 PM826_BIGFLASH PM826:FLASH_32MB,SYS_TEXT_BASE=0x40000000 Wolfgang Denk <wd@denx.de>
+Active powerpc mpc8260 - - pm826 PM826_ROMBOOT PM826:BOOT_ROM,SYS_TEXT_BASE=0xFF800000 Wolfgang Denk <wd@denx.de>
+Active powerpc mpc8260 - - pm826 PM826_ROMBOOT_BIGFLASH PM826:BOOT_ROM,FLASH_32MB,SYS_TEXT_BASE=0xFF800000 Wolfgang Denk <wd@denx.de>
+Active powerpc mpc8260 - - pm828 PM828 PM828 -
+Active powerpc mpc8260 - - pm828 PM828_PCI PM828:PCI -
+Active powerpc mpc8260 - - pm828 PM828_ROMBOOT PM828:BOOT_ROM,SYS_TEXT_BASE=0xFF800000 -
+Active powerpc mpc8260 - - pm828 PM828_ROMBOOT_PCI PM828:PCI,BOOT_ROM,SYS_TEXT_BASE=0xFF800000 -
+Active powerpc mpc8260 - - rattler Rattler Rattler Yuli Barcohen <yuli@arabellasw.com>
+Active powerpc mpc8260 - - rattler Rattler8248 Rattler:MPC8248 Yuli Barcohen <yuli@arabellasw.com>
+Active powerpc mpc8260 - - zpc1900 ZPC1900 - Yuli Barcohen <yuli@arabellasw.com>
+Active powerpc mpc8260 - freescale mpc8260ads MPC8260ADS MPC8260ADS:ADSTYPE=CONFIG_SYS_8260ADS Yuli Barcohen <yuli@arabellasw.com>
+Active powerpc mpc8260 - freescale mpc8260ads MPC8260ADS_33MHz MPC8260ADS:ADSTYPE=CONFIG_SYS_8260ADS,8260_CLKIN=33000000 Yuli Barcohen <yuli@arabellasw.com>
+Active powerpc mpc8260 - freescale mpc8260ads MPC8260ADS_33MHz_lowboot MPC8260ADS:ADSTYPE=CONFIG_SYS_8260ADS,8260_CLKIN=33000000,SYS_TEXT_BASE=0xFF800000 Yuli Barcohen <yuli@arabellasw.com>
+Active powerpc mpc8260 - freescale mpc8260ads MPC8260ADS_40MHz MPC8260ADS:ADSTYPE=CONFIG_SYS_8260ADS,8260_CLKIN=40000000 Yuli Barcohen <yuli@arabellasw.com>
+Active powerpc mpc8260 - freescale mpc8260ads MPC8260ADS_40MHz_lowboot MPC8260ADS:ADSTYPE=CONFIG_SYS_8260ADS,8260_CLKIN=40000000,SYS_TEXT_BASE=0xFF800000 Yuli Barcohen <yuli@arabellasw.com>
+Active powerpc mpc8260 - freescale mpc8260ads MPC8260ADS_lowboot MPC8260ADS:ADSTYPE=CONFIG_SYS_8260ADS,SYS_TEXT_BASE=0xFF800000 Yuli Barcohen <yuli@arabellasw.com>
+Active powerpc mpc8260 - freescale mpc8260ads MPC8272ADS MPC8260ADS:ADSTYPE=CONFIG_SYS_8272ADS Yuli Barcohen <yuli@arabellasw.com>
+Active powerpc mpc8260 - freescale mpc8260ads MPC8272ADS_lowboot MPC8260ADS:ADSTYPE=CONFIG_SYS_8272ADS,SYS_TEXT_BASE=0xFF800000 Yuli Barcohen <yuli@arabellasw.com>
+Active powerpc mpc8260 - freescale mpc8260ads PQ2FADS MPC8260ADS:ADSTYPE=CONFIG_SYS_PQ2FADS Yuli Barcohen <yuli@arabellasw.com>
+Active powerpc mpc8260 - freescale mpc8260ads PQ2FADS-VR MPC8260ADS:ADSTYPE=CONFIG_SYS_PQ2FADS,8260_CLKIN=66000000 Yuli Barcohen <yuli@arabellasw.com>
+Active powerpc mpc8260 - freescale mpc8260ads PQ2FADS-VR_lowboot MPC8260ADS:ADSTYPE=CONFIG_SYS_PQ2FADS,8260_CLKIN=66000000,SYS_TEXT_BASE=0xFF800000 Yuli Barcohen <yuli@arabellasw.com>
+Active powerpc mpc8260 - freescale mpc8260ads PQ2FADS-ZU MPC8260ADS:ADSTYPE=CONFIG_SYS_PQ2FADS Yuli Barcohen <yuli@arabellasw.com>
+Active powerpc mpc8260 - freescale mpc8260ads PQ2FADS-ZU_66MHz MPC8260ADS:ADSTYPE=CONFIG_SYS_PQ2FADS,8260_CLKIN=66000000 Yuli Barcohen <yuli@arabellasw.com>
+Active powerpc mpc8260 - freescale mpc8260ads PQ2FADS-ZU_66MHz_lowboot MPC8260ADS:ADSTYPE=CONFIG_SYS_PQ2FADS,8260_CLKIN=66000000,SYS_TEXT_BASE=0xFF800000 Yuli Barcohen <yuli@arabellasw.com>
+Active powerpc mpc8260 - freescale mpc8260ads PQ2FADS-ZU_lowboot MPC8260ADS:ADSTYPE=CONFIG_SYS_PQ2FADS,SYS_TEXT_BASE=0xFF800000 Yuli Barcohen <yuli@arabellasw.com>
+Active powerpc mpc8260 - freescale mpc8260ads PQ2FADS_lowboot MPC8260ADS:ADSTYPE=CONFIG_SYS_PQ2FADS,SYS_TEXT_BASE=0xFF800000 Yuli Barcohen <yuli@arabellasw.com>
+Active powerpc mpc8260 - freescale mpc8266ads MPC8266ADS - Rune Torgersen <runet@innovsys.com>
+Active powerpc mpc8260 - funkwerk vovpn-gw VoVPN-GW_66MHz VoVPN-GW:CLKIN_66MHz -
+Active powerpc mpc8260 - keymile km82xx mgcoge km82xx:MGCOGE Holger Brunck <holger.brunck@keymile.com>
+Active powerpc mpc8260 - keymile km82xx mgcoge3ne km82xx:MGCOGE3NE Holger Brunck <holger.brunck@keymile.com>
+Active powerpc mpc8260 - tqc tqm8260 TQM8255_AA TQM8260:MPC8255,300MHz Wolfgang Denk <wd@denx.de>
+Active powerpc mpc8260 - tqc tqm8260 TQM8260_AA TQM8260:MPC8260,200MHz Wolfgang Denk <wd@denx.de>
+Active powerpc mpc8260 - tqc tqm8260 TQM8260_AB TQM8260:MPC8260,200MHz,L2_CACHE,BUSMODE_60x Wolfgang Denk <wd@denx.de>
+Active powerpc mpc8260 - tqc tqm8260 TQM8260_AC TQM8260:MPC8260,200MHz,L2_CACHE,BUSMODE_60x Wolfgang Denk <wd@denx.de>
+Active powerpc mpc8260 - tqc tqm8260 TQM8260_AD TQM8260:MPC8260,300MHz,BUSMODE_60x Wolfgang Denk <wd@denx.de>
+Active powerpc mpc8260 - tqc tqm8260 TQM8260_AE TQM8260:MPC8260,266MHz Wolfgang Denk <wd@denx.de>
+Active powerpc mpc8260 - tqc tqm8260 TQM8260_AF TQM8260:MPC8260,300MHz,BUSMODE_60x Wolfgang Denk <wd@denx.de>
+Active powerpc mpc8260 - tqc tqm8260 TQM8260_AG TQM8260:MPC8260,300MHz Wolfgang Denk <wd@denx.de>
+Active powerpc mpc8260 - tqc tqm8260 TQM8260_AH TQM8260:MPC8260,300MHz,L2_CACHE,BUSMODE_60x Wolfgang Denk <wd@denx.de>
+Active powerpc mpc8260 - tqc tqm8260 TQM8260_AI TQM8260:MPC8260,300MHz,BUSMODE_60x Wolfgang Denk <wd@denx.de>
+Active powerpc mpc8260 - tqc tqm8260 TQM8265_AA TQM8260:MPC8265,300MHz,BUSMODE_60x Wolfgang Denk <wd@denx.de>
+Active powerpc mpc8260 - tqc tqm8272 TQM8272 - -
+Active powerpc mpc83xx - - - mpc8308_p1m - Ilya Yanok <yanok@emcraft.com>
+Active powerpc mpc83xx - - sbc8349 sbc8349 sbc8349 Paul Gortmaker <paul.gortmaker@windriver.com>
+Active powerpc mpc83xx - - sbc8349 sbc8349_PCI_33 sbc8349:PCI,PCI_33M Paul Gortmaker <paul.gortmaker@windriver.com>
+Active powerpc mpc83xx - - sbc8349 sbc8349_PCI_66 sbc8349:PCI,PCI_66M Paul Gortmaker <paul.gortmaker@windriver.com>
+Active powerpc mpc83xx - - ve8313 ve8313 - Heiko Schocher <hs@denx.de>
+Active powerpc mpc83xx - esd vme8349 caddy2 vme8349:CADDY2 Reinhard Arlt <reinhard.arlt@esd-electronics.com>
+Active powerpc mpc83xx - esd vme8349 vme8349 vme8349 Reinhard Arlt <reinhard.arlt@esd-electronics.com>
+Active powerpc mpc83xx - freescale mpc8308rdb MPC8308RDB - Ilya Yanok <yanok@emcraft.com>
+Active powerpc mpc83xx - freescale mpc8313erdb MPC8313ERDB_33 MPC8313ERDB:SYS_33MHZ -
+Active powerpc mpc83xx - freescale mpc8313erdb MPC8313ERDB_66 MPC8313ERDB:SYS_66MHZ -
+Active powerpc mpc83xx - freescale mpc8313erdb MPC8313ERDB_NAND_33 MPC8313ERDB:SYS_33MHZ,NAND -
+Active powerpc mpc83xx - freescale mpc8313erdb MPC8313ERDB_NAND_66 MPC8313ERDB:SYS_66MHZ,NAND -
+Active powerpc mpc83xx - freescale mpc8315erdb MPC8315ERDB MPC8315ERDB Dave Liu <daveliu@freescale.com>
+Active powerpc mpc83xx - freescale mpc8315erdb MPC8315ERDB_NAND MPC8315ERDB:NAND_U_BOOT Dave Liu <daveliu@freescale.com>
+Active powerpc mpc83xx - freescale mpc8323erdb MPC8323ERDB - Michael Barkowski <michael.barkowski@freescale.com>
+Active powerpc mpc83xx - freescale mpc832xemds MPC832XEMDS MPC832XEMDS: Dave Liu <daveliu@freescale.com>
+Active powerpc mpc83xx - freescale mpc832xemds MPC832XEMDS_ATM MPC832XEMDS:PQ_MDS_PIB=1,PQ_MDS_PIB_ATM=1 Dave Liu <daveliu@freescale.com>
+Active powerpc mpc83xx - freescale mpc832xemds MPC832XEMDS_HOST_33 MPC832XEMDS:PCI,PCI_33M,PQ_MDS_PIB=1 Dave Liu <daveliu@freescale.com>
+Active powerpc mpc83xx - freescale mpc832xemds MPC832XEMDS_HOST_66 MPC832XEMDS:PCI,PCI_66M,PQ_MDS_PIB=1 Dave Liu <daveliu@freescale.com>
+Active powerpc mpc83xx - freescale mpc832xemds MPC832XEMDS_SLAVE MPC832XEMDS:PCI,PCISLAVE Dave Liu <daveliu@freescale.com>
+Active powerpc mpc83xx - freescale mpc8349emds MPC8349EMDS - Kim Phillips <kim.phillips@freescale.com>
+Active powerpc mpc83xx - freescale mpc8349itx MPC8349ITX MPC8349ITX:MPC8349ITX -
+Active powerpc mpc83xx - freescale mpc8349itx MPC8349ITX_LOWBOOT MPC8349ITX:MPC8349ITX,SYS_TEXT_BASE=0xFE000000 -
+Active powerpc mpc83xx - freescale mpc8349itx MPC8349ITXGP MPC8349ITX:MPC8349ITXGP,SYS_TEXT_BASE=0xFE000000 -
+Active powerpc mpc83xx - freescale mpc8360emds MPC8360EMDS_33 MPC8360EMDS:CLKIN_33MHZ Dave Liu <daveliu@freescale.com>
+Active powerpc mpc83xx - freescale mpc8360emds MPC8360EMDS_33_ATM MPC8360EMDS:CLKIN_33MHZ,PQ_MDS_PIB=1,PQ_MDS_PIB_ATM=1 Dave Liu <daveliu@freescale.com>
+Active powerpc mpc83xx - freescale mpc8360emds MPC8360EMDS_33_HOST_33 MPC8360EMDS:CLKIN_33MHZ,PCI,PCI_33M,PQ_MDS_PIB=1 Dave Liu <daveliu@freescale.com>
+Active powerpc mpc83xx - freescale mpc8360emds MPC8360EMDS_33_HOST_66 MPC8360EMDS:CLKIN_33MHZ,PCI,PCI_66M,PQ_MDS_PIB=1 Dave Liu <daveliu@freescale.com>
+Active powerpc mpc83xx - freescale mpc8360emds MPC8360EMDS_33_SLAVE MPC8360EMDS:CLKIN_33MHZ,PCI,PCISLAVE Dave Liu <daveliu@freescale.com>
+Active powerpc mpc83xx - freescale mpc8360emds MPC8360EMDS_66 MPC8360EMDS:CLKIN_66MHZ Dave Liu <daveliu@freescale.com>
+Active powerpc mpc83xx - freescale mpc8360emds MPC8360EMDS_66_ATM MPC8360EMDS:CLKIN_66MHZ,PQ_MDS_PIB=1,PQ_MDS_PIB_ATM=1 Dave Liu <daveliu@freescale.com>
+Active powerpc mpc83xx - freescale mpc8360emds MPC8360EMDS_66_HOST_33 MPC8360EMDS:CLKIN_66MHZ,PCI,PCI_33M,PQ_MDS_PIB=1 Dave Liu <daveliu@freescale.com>
+Active powerpc mpc83xx - freescale mpc8360emds MPC8360EMDS_66_HOST_66 MPC8360EMDS:CLKIN_66MHZ,PCI,PCI_66M,PQ_MDS_PIB=1 Dave Liu <daveliu@freescale.com>
+Active powerpc mpc83xx - freescale mpc8360emds MPC8360EMDS_66_SLAVE MPC8360EMDS:CLKIN_66MHZ,PCI,PCISLAVE Dave Liu <daveliu@freescale.com>
+Active powerpc mpc83xx - freescale mpc8360erdk MPC8360ERDK MPC8360ERDK Anton Vorontsov <avorontsov@ru.mvista.com>
+Active powerpc mpc83xx - freescale mpc8360erdk MPC8360ERDK_33 MPC8360ERDK:CLKIN_33MHZ Anton Vorontsov <avorontsov@ru.mvista.com>
+Active powerpc mpc83xx - freescale mpc8360erdk MPC8360ERDK_66 MPC8360ERDK Anton Vorontsov <avorontsov@ru.mvista.com>
+Active powerpc mpc83xx - freescale mpc837xemds MPC837XEMDS MPC837XEMDS Dave Liu <daveliu@freescale.com>
+Active powerpc mpc83xx - freescale mpc837xemds MPC837XEMDS_HOST MPC837XEMDS:PCI Dave Liu <daveliu@freescale.com>
+Active powerpc mpc83xx - freescale mpc837xerdb MPC837XERDB - Joe D'Abbraccio <ljd015@freescale.com>
+Active powerpc mpc83xx - keymile km83xx kmcoge5ne km8360:KMCOGE5NE Holger Brunck <holger.brunck@keymile.com>
+Active powerpc mpc83xx - keymile km83xx kmeter1 km8360:KMETER1 Holger Brunck <holger.brunck@keymile.com>
+Active powerpc mpc83xx - keymile km83xx kmopti2 tuxx1:KMOPTI2 Holger Brunck <holger.brunck@keymile.com>
+Active powerpc mpc83xx - keymile km83xx kmsupx5 tuxx1:KMSUPX5 Holger Brunck <holger.brunck@keymile.com>:Heiko Schocher <hs@denx.de>
+Active powerpc mpc83xx - keymile km83xx kmvect1 suvd3:KMVECT1 Holger Brunck <holger.brunck@keymile.com>
+Active powerpc mpc83xx - keymile km83xx suvd3 suvd3:SUVD3 Holger Brunck <holger.brunck@keymile.com>
+Active powerpc mpc83xx - keymile km83xx tuge1 tuxx1:TUGE1 Holger Brunck <holger.brunck@keymile.com>
+Active powerpc mpc83xx - keymile km83xx tuxx1 tuxx1:TUXX1 Holger Brunck <holger.brunck@keymile.com>
+Active powerpc mpc83xx - matrix_vision mergerbox MERGERBOX - Andre Schwarz <andre.schwarz@matrix-vision.de>
+Active powerpc mpc83xx - matrix_vision mvblm7 MVBLM7 - Andre Schwarz <andre.schwarz@matrix-vision.de>
+Active powerpc mpc83xx - sheldon simpc8313 SIMPC8313_LP SIMPC8313:NAND_LP Ron Madrid <info@sheldoninst.com>
+Active powerpc mpc83xx - sheldon simpc8313 SIMPC8313_SP SIMPC8313:NAND_SP Ron Madrid <info@sheldoninst.com>
+Active powerpc mpc83xx - tqc tqm834x TQM834x - -
+Active powerpc mpc85xx - - sbc8548 sbc8548 sbc8548 Paul Gortmaker <paul.gortmaker@windriver.com>
+Active powerpc mpc85xx - - sbc8548 sbc8548_PCI_33 sbc8548:PCI,33 Paul Gortmaker <paul.gortmaker@windriver.com>
+Active powerpc mpc85xx - - sbc8548 sbc8548_PCI_33_PCIE sbc8548:PCI,33,PCIE Paul Gortmaker <paul.gortmaker@windriver.com>
+Active powerpc mpc85xx - - sbc8548 sbc8548_PCI_66 sbc8548:PCI,66 Paul Gortmaker <paul.gortmaker@windriver.com>
+Active powerpc mpc85xx - - sbc8548 sbc8548_PCI_66_PCIE sbc8548:PCI,66,PCIE Paul Gortmaker <paul.gortmaker@windriver.com>
+Active powerpc mpc85xx - - socrates socrates - -
+Active powerpc mpc85xx - exmeritus hww1u1a HWW1U1A - Kyle Moffett <Kyle.D.Moffett@boeing.com>
+Active powerpc mpc85xx - freescale b4860qds B4420QDS B4860QDS:PPC_B4420 -
+Active powerpc mpc85xx - freescale b4860qds B4420QDS_NAND B4860QDS:PPC_B4420,RAMBOOT_PBL,NAND,SYS_TEXT_BASE=0xFFF80000 -
+Active powerpc mpc85xx - freescale b4860qds B4420QDS_SPIFLASH B4860QDS:PPC_B4420,RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF80000 -
+Active powerpc mpc85xx - freescale b4860qds B4860QDS B4860QDS:PPC_B4860 -
+Active powerpc mpc85xx - freescale b4860qds B4860QDS_NAND B4860QDS:PPC_B4860,RAMBOOT_PBL,NAND,SYS_TEXT_BASE=0xFFF80000 -
+Active powerpc mpc85xx - freescale b4860qds B4860QDS_SPIFLASH B4860QDS:PPC_B4860,RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF80000 -
+Active powerpc mpc85xx - freescale b4860qds B4860QDS_SRIO_PCIE_BOOT B4860QDS:PPC_B4860,SRIO_PCIE_BOOT_SLAVE,SYS_TEXT_BASE=0xFFF80000 -
+Active powerpc mpc85xx - freescale bsc9131rdb BSC9131RDB_NAND BSC9131RDB:BSC9131RDB,NAND Poonam Aggrwal <poonam.aggrwal@freescale.com>
+Active powerpc mpc85xx - freescale bsc9131rdb BSC9131RDB_NAND_SYSCLK100 BSC9131RDB:BSC9131RDB,NAND,SYS_CLK_100 Poonam Aggrwal <poonam.aggrwal@freescale.com>
+Active powerpc mpc85xx - freescale bsc9131rdb BSC9131RDB_SPIFLASH BSC9131RDB:BSC9131RDB,SPIFLASH Poonam Aggrwal <poonam.aggrwal@freescale.com>
+Active powerpc mpc85xx - freescale bsc9131rdb BSC9131RDB_SPIFLASH_SYSCLK100 BSC9131RDB:BSC9131RDB,SPIFLASH,SYS_CLK_100 Poonam Aggrwal <poonam.aggrwal@freescale.com>
+Active powerpc mpc85xx - freescale bsc9132qds BSC9132QDS_NAND_DDRCLK100 BSC9132QDS:BSC9132QDS,NAND,SYS_CLK_100_DDR_100 Naveen Burmi <NaveenBurmi@freescale.com>
+Active powerpc mpc85xx - freescale bsc9132qds BSC9132QDS_NAND_DDRCLK133 BSC9132QDS:BSC9132QDS,NAND,SYS_CLK_100_DDR_133 Naveen Burmi <NaveenBurmi@freescale.com>
+Active powerpc mpc85xx - freescale bsc9132qds BSC9132QDS_NOR_DDRCLK100 BSC9132QDS:BSC9132QDS,SYS_CLK_100_DDR_100 Naveen Burmi <NaveenBurmi@freescale.com>
+Active powerpc mpc85xx - freescale bsc9132qds BSC9132QDS_NOR_DDRCLK133 BSC9132QDS:BSC9132QDS,SYS_CLK_100_DDR_133 Naveen Burmi <NaveenBurmi@freescale.com>
+Active powerpc mpc85xx - freescale bsc9132qds BSC9132QDS_SDCARD_DDRCLK100 BSC9132QDS:BSC9132QDS,SDCARD,SYS_CLK_100_DDR_100 Naveen Burmi <NaveenBurmi@freescale.com>
+Active powerpc mpc85xx - freescale bsc9132qds BSC9132QDS_SDCARD_DDRCLK133 BSC9132QDS:BSC9132QDS,SDCARD,SYS_CLK_100_DDR_133 Naveen Burmi <NaveenBurmi@freescale.com>
+Active powerpc mpc85xx - freescale bsc9132qds BSC9132QDS_SPIFLASH_DDRCLK100 BSC9132QDS:BSC9132QDS,SPIFLASH,SYS_CLK_100_DDR_100 Naveen Burmi <NaveenBurmi@freescale.com>
+Active powerpc mpc85xx - freescale bsc9132qds BSC9132QDS_SPIFLASH_DDRCLK133 BSC9132QDS:BSC9132QDS,SPIFLASH,SYS_CLK_100_DDR_133 Naveen Burmi <NaveenBurmi@freescale.com>
+Active powerpc mpc85xx - freescale corenet_ds P3041DS - -
+Active powerpc mpc85xx - freescale corenet_ds P3041DS_NAND P3041DS:RAMBOOT_PBL,NAND,SYS_TEXT_BASE=0xFFF80000 -
+Active powerpc mpc85xx - freescale corenet_ds P3041DS_SDCARD P3041DS:RAMBOOT_PBL,SDCARD,SYS_TEXT_BASE=0xFFF80000 -
+Active powerpc mpc85xx - freescale corenet_ds P3041DS_SECURE_BOOT P3041DS:SECURE_BOOT -
+Active powerpc mpc85xx - freescale corenet_ds P3041DS_SPIFLASH P3041DS:RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF80000 -
+Active powerpc mpc85xx - freescale corenet_ds P3041DS_SRIO_PCIE_BOOT P3041DS:SRIO_PCIE_BOOT_SLAVE,SYS_TEXT_BASE=0xFFF80000 -
+Active powerpc mpc85xx - freescale corenet_ds P4080DS - -
+Active powerpc mpc85xx - freescale corenet_ds P4080DS_SDCARD P4080DS:RAMBOOT_PBL,SDCARD,SYS_TEXT_BASE=0xFFF80000 -
+Active powerpc mpc85xx - freescale corenet_ds P4080DS_SECURE_BOOT P4080DS:SECURE_BOOT -
+Active powerpc mpc85xx - freescale corenet_ds P4080DS_SPIFLASH P4080DS:RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF80000 -
+Active powerpc mpc85xx - freescale corenet_ds P4080DS_SRIO_PCIE_BOOT P4080DS:SRIO_PCIE_BOOT_SLAVE,SYS_TEXT_BASE=0xFFF80000 -
+Active powerpc mpc85xx - freescale corenet_ds P5020DS - -
+Active powerpc mpc85xx - freescale corenet_ds P5020DS_NAND P5020DS:RAMBOOT_PBL,NAND,SYS_TEXT_BASE=0xFFF80000 -
+Active powerpc mpc85xx - freescale corenet_ds P5020DS_SDCARD P5020DS:RAMBOOT_PBL,SDCARD,SYS_TEXT_BASE=0xFFF80000 -
+Active powerpc mpc85xx - freescale corenet_ds P5020DS_SECURE_BOOT P5020DS:SECURE_BOOT -
+Active powerpc mpc85xx - freescale corenet_ds P5020DS_SPIFLASH P5020DS:RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF80000 -
+Active powerpc mpc85xx - freescale corenet_ds P5020DS_SRIO_PCIE_BOOT P5020DS:SRIO_PCIE_BOOT_SLAVE,SYS_TEXT_BASE=0xFFF80000 -
+Active powerpc mpc85xx - freescale corenet_ds P5040DS - -
+Active powerpc mpc85xx - freescale corenet_ds P5040DS_NAND P5040DS:RAMBOOT_PBL,NAND,SYS_TEXT_BASE=0xFFF80000 -
+Active powerpc mpc85xx - freescale corenet_ds P5040DS_SDCARD P5040DS:RAMBOOT_PBL,SDCARD,SYS_TEXT_BASE=0xFFF80000 -
+Active powerpc mpc85xx - freescale corenet_ds P5040DS_SPIFLASH P5040DS:RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF80000 -
+Active powerpc mpc85xx - freescale mpc8536ds MPC8536DS MPC8536DS -
+Active powerpc mpc85xx - freescale mpc8536ds MPC8536DS_36BIT MPC8536DS:36BIT -
+Active powerpc mpc85xx - freescale mpc8536ds MPC8536DS_NAND MPC8536DS:NAND -
+Active powerpc mpc85xx - freescale mpc8536ds MPC8536DS_SDCARD MPC8536DS:SDCARD -
+Active powerpc mpc85xx - freescale mpc8536ds MPC8536DS_SPIFLASH MPC8536DS:SPIFLASH -
+Active powerpc mpc85xx - freescale mpc8540ads MPC8540ADS - Kumar Gala <kumar.gala@freescale.com>
+Active powerpc mpc85xx - freescale mpc8541cds MPC8541CDS MPC8541CDS Kumar Gala <kumar.gala@freescale.com>
+Active powerpc mpc85xx - freescale mpc8541cds MPC8541CDS_legacy MPC8541CDS:LEGACY Kumar Gala <kumar.gala@freescale.com>
+Active powerpc mpc85xx - freescale mpc8544ds MPC8544DS - -
+Active powerpc mpc85xx - freescale mpc8548cds MPC8548CDS MPC8548CDS -
+Active powerpc mpc85xx - freescale mpc8548cds MPC8548CDS_36BIT MPC8548CDS:36BIT -
+Active powerpc mpc85xx - freescale mpc8548cds MPC8548CDS_legacy MPC8548CDS:LEGACY -
+Active powerpc mpc85xx - freescale mpc8555cds MPC8555CDS MPC8555CDS Kumar Gala <kumar.gala@freescale.com>
+Active powerpc mpc85xx - freescale mpc8555cds MPC8555CDS_legacy MPC8555CDS:LEGACY Kumar Gala <kumar.gala@freescale.com>
+Active powerpc mpc85xx - freescale mpc8560ads MPC8560ADS - Kumar Gala <kumar.gala@freescale.com>
+Active powerpc mpc85xx - freescale mpc8568mds MPC8568MDS - -
+Active powerpc mpc85xx - freescale mpc8569mds MPC8569MDS MPC8569MDS -
+Active powerpc mpc85xx - freescale mpc8569mds MPC8569MDS_ATM MPC8569MDS:ATM -
+Active powerpc mpc85xx - freescale mpc8569mds MPC8569MDS_NAND MPC8569MDS:NAND -
+Active powerpc mpc85xx - freescale mpc8572ds MPC8572DS MPC8572DS -
+Active powerpc mpc85xx - freescale mpc8572ds MPC8572DS_36BIT MPC8572DS:36BIT -
+Active powerpc mpc85xx - freescale mpc8572ds MPC8572DS_NAND MPC8572DS:NAND -
+Active powerpc mpc85xx - freescale p1010rdb P1010RDB_36BIT_NAND P1010RDB:P1010RDB,36BIT,NAND -
+Active powerpc mpc85xx - freescale p1010rdb P1010RDB_36BIT_NAND_SECBOOT P1010RDB:P1010RDB,36BIT,NAND_SECBOOT,SECURE_BOOT -
+Active powerpc mpc85xx - freescale p1010rdb P1010RDB_36BIT_NOR P1010RDB:P1010RDB,36BIT -
+Active powerpc mpc85xx - freescale p1010rdb P1010RDB_36BIT_NOR_SECBOOT P1010RDB:P1010RDB,36BIT,SECURE_BOOT -
+Active powerpc mpc85xx - freescale p1010rdb P1010RDB_36BIT_SDCARD P1010RDB:P1010RDB,36BIT,SDCARD -
+Active powerpc mpc85xx - freescale p1010rdb P1010RDB_36BIT_SPIFLASH P1010RDB:P1010RDB,36BIT,SPIFLASH -
+Active powerpc mpc85xx - freescale p1010rdb P1010RDB_36BIT_SPIFLASH_SECBOOT P1010RDB:P1010RDB,36BIT,SPIFLASH,SECURE_BOOT -
+Active powerpc mpc85xx - freescale p1010rdb P1010RDB_NAND P1010RDB:P1010RDB,NAND -
+Active powerpc mpc85xx - freescale p1010rdb P1010RDB_NAND_SECBOOT P1010RDB:P1010RDB,NAND_SECBOOT,SECURE_BOOT -
+Active powerpc mpc85xx - freescale p1010rdb P1010RDB_NOR P1010RDB:P1010RDB -
+Active powerpc mpc85xx - freescale p1010rdb P1010RDB_NOR_SECBOOT P1010RDB:P1010RDB,SECURE_BOOT -
+Active powerpc mpc85xx - freescale p1010rdb P1010RDB_SDCARD P1010RDB:P1010RDB,SDCARD -
+Active powerpc mpc85xx - freescale p1010rdb P1010RDB_SPIFLASH P1010RDB:P1010RDB,SPIFLASH -
+Active powerpc mpc85xx - freescale p1010rdb P1010RDB_SPIFLASH_SECBOOT P1010RDB:P1010RDB,SPIFLASH,SECURE_BOOT -
+Active powerpc mpc85xx - freescale p1022ds P1022DS - Timur Tabi <timur@freescale.com>
+Active powerpc mpc85xx - freescale p1022ds P1022DS_36BIT P1022DS:36BIT Timur Tabi <timur@freescale.com>
+Active powerpc mpc85xx - freescale p1022ds P1022DS_36BIT_NAND P1022DS:36BIT,NAND Timur Tabi <timur@freescale.com>
+Active powerpc mpc85xx - freescale p1022ds P1022DS_36BIT_SDCARD P1022DS:36BIT,SDCARD Timur Tabi <timur@freescale.com>
+Active powerpc mpc85xx - freescale p1022ds P1022DS_36BIT_SPIFLASH P1022DS:36BIT,SPIFLASH Timur Tabi <timur@freescale.com>
+Active powerpc mpc85xx - freescale p1022ds P1022DS_NAND P1022DS:NAND Timur Tabi <timur@freescale.com>
+Active powerpc mpc85xx - freescale p1022ds P1022DS_SDCARD P1022DS:SDCARD Timur Tabi <timur@freescale.com>
+Active powerpc mpc85xx - freescale p1022ds P1022DS_SPIFLASH P1022DS:SPIFLASH Timur Tabi <timur@freescale.com>
+Active powerpc mpc85xx - freescale p1023rdb P1023RDB P1023RDB -
+Active powerpc mpc85xx - freescale p1023rds P1023RDS P1023RDS Roy Zang <tie-fei.zang@freescale.com>
+Active powerpc mpc85xx - freescale p1023rds P1023RDS_NAND P1023RDS:NAND Roy Zang <tie-fei.zang@freescale.com>
+Active powerpc mpc85xx - freescale p1_p2_rdb P1011RDB P1_P2_RDB:P1011RDB -
+Active powerpc mpc85xx - freescale p1_p2_rdb P1011RDB_36BIT P1_P2_RDB:P1011RDB,36BIT -
+Active powerpc mpc85xx - freescale p1_p2_rdb P1011RDB_36BIT_SDCARD P1_P2_RDB:P1011RDB,36BIT,SDCARD -
+Active powerpc mpc85xx - freescale p1_p2_rdb P1011RDB_36BIT_SPIFLASH P1_P2_RDB:P1011RDB,36BIT,SPIFLASH -
+Active powerpc mpc85xx - freescale p1_p2_rdb P1011RDB_NAND P1_P2_RDB:P1011RDB,NAND -
+Active powerpc mpc85xx - freescale p1_p2_rdb P1011RDB_SDCARD P1_P2_RDB:P1011RDB,SDCARD -
+Active powerpc mpc85xx - freescale p1_p2_rdb P1011RDB_SPIFLASH P1_P2_RDB:P1011RDB,SPIFLASH -
+Active powerpc mpc85xx - freescale p1_p2_rdb P1020RDB P1_P2_RDB:P1020RDB -
+Active powerpc mpc85xx - freescale p1_p2_rdb P1020RDB_36BIT P1_P2_RDB:P1020RDB,36BIT -
+Active powerpc mpc85xx - freescale p1_p2_rdb P1020RDB_36BIT_SDCARD P1_P2_RDB:P1020RDB,36BIT,SDCARD -
+Active powerpc mpc85xx - freescale p1_p2_rdb P1020RDB_36BIT_SPIFLASH P1_P2_RDB:P1020RDB,36BIT,SPIFLASH -
+Active powerpc mpc85xx - freescale p1_p2_rdb P1020RDB_NAND P1_P2_RDB:P1020RDB,NAND -
+Active powerpc mpc85xx - freescale p1_p2_rdb P1020RDB_SDCARD P1_P2_RDB:P1020RDB,SDCARD -
+Active powerpc mpc85xx - freescale p1_p2_rdb P1020RDB_SPIFLASH P1_P2_RDB:P1020RDB,SPIFLASH -
+Active powerpc mpc85xx - freescale p1_p2_rdb P2010RDB P1_P2_RDB:P2010RDB -
+Active powerpc mpc85xx - freescale p1_p2_rdb P2010RDB_36BIT P1_P2_RDB:P2010RDB,36BIT -
+Active powerpc mpc85xx - freescale p1_p2_rdb P2010RDB_36BIT_SDCARD P1_P2_RDB:P2010RDB,36BIT,SDCARD -
+Active powerpc mpc85xx - freescale p1_p2_rdb P2010RDB_36BIT_SPIFLASH P1_P2_RDB:P2010RDB,36BIT,SPIFLASH -
+Active powerpc mpc85xx - freescale p1_p2_rdb P2010RDB_NAND P1_P2_RDB:P2010RDB,NAND -
+Active powerpc mpc85xx - freescale p1_p2_rdb P2010RDB_SDCARD P1_P2_RDB:P2010RDB,SDCARD -
+Active powerpc mpc85xx - freescale p1_p2_rdb P2010RDB_SPIFLASH P1_P2_RDB:P2010RDB,SPIFLASH -
+Active powerpc mpc85xx - freescale p1_p2_rdb P2020RDB P1_P2_RDB:P2020RDB Poonam Aggrwal <poonam.aggrwal@freescale.com>
+Active powerpc mpc85xx - freescale p1_p2_rdb P2020RDB_36BIT P1_P2_RDB:P2020RDB,36BIT -
+Active powerpc mpc85xx - freescale p1_p2_rdb P2020RDB_36BIT_SDCARD P1_P2_RDB:P2020RDB,36BIT,SDCARD -
+Active powerpc mpc85xx - freescale p1_p2_rdb P2020RDB_36BIT_SPIFLASH P1_P2_RDB:P2020RDB,36BIT,SPIFLASH -
+Active powerpc mpc85xx - freescale p1_p2_rdb P2020RDB_NAND P1_P2_RDB:P2020RDB,NAND -
+Active powerpc mpc85xx - freescale p1_p2_rdb P2020RDB_SDCARD P1_P2_RDB:P2020RDB,SDCARD -
+Active powerpc mpc85xx - freescale p1_p2_rdb P2020RDB_SPIFLASH P1_P2_RDB:P2020RDB,SPIFLASH -
+Active powerpc mpc85xx - freescale p1_p2_rdb_pc P1020MBG-PC p1_p2_rdb_pc:P1020MBG -
+Active powerpc mpc85xx - freescale p1_p2_rdb_pc P1020MBG-PC_36BIT p1_p2_rdb_pc:P1020MBG,36BIT -
+Active powerpc mpc85xx - freescale p1_p2_rdb_pc P1020MBG-PC_36BIT_SDCARD p1_p2_rdb_pc:P1020MBG,SDCARD,36BIT -
+Active powerpc mpc85xx - freescale p1_p2_rdb_pc P1020MBG-PC_SDCARD p1_p2_rdb_pc:P1020MBG,SDCARD -
+Active powerpc mpc85xx - freescale p1_p2_rdb_pc P1020RDB-PC p1_p2_rdb_pc:P1020RDB -
+Active powerpc mpc85xx - freescale p1_p2_rdb_pc P1020RDB-PC_36BIT p1_p2_rdb_pc:P1020RDB,36BIT -
+Active powerpc mpc85xx - freescale p1_p2_rdb_pc P1020RDB-PC_36BIT_NAND p1_p2_rdb_pc:P1020RDB,36BIT,NAND -
+Active powerpc mpc85xx - freescale p1_p2_rdb_pc P1020RDB-PC_36BIT_SDCARD p1_p2_rdb_pc:P1020RDB,36BIT,SDCARD -
+Active powerpc mpc85xx - freescale p1_p2_rdb_pc P1020RDB-PC_36BIT_SPIFLASH p1_p2_rdb_pc:P1020RDB,36BIT,SPIFLASH -
+Active powerpc mpc85xx - freescale p1_p2_rdb_pc P1020RDB-PC_NAND p1_p2_rdb_pc:P1020RDB,NAND -
+Active powerpc mpc85xx - freescale p1_p2_rdb_pc P1020RDB-PC_SDCARD p1_p2_rdb_pc:P1020RDB,SDCARD -
+Active powerpc mpc85xx - freescale p1_p2_rdb_pc P1020RDB-PC_SPIFLASH p1_p2_rdb_pc:P1020RDB,SPIFLASH -
+Active powerpc mpc85xx - freescale p1_p2_rdb_pc P1020UTM-PC p1_p2_rdb_pc:P1020UTM -
+Active powerpc mpc85xx - freescale p1_p2_rdb_pc P1020UTM-PC_36BIT p1_p2_rdb_pc:P1020UTM,36BIT -
+Active powerpc mpc85xx - freescale p1_p2_rdb_pc P1020UTM-PC_36BIT_SDCARD p1_p2_rdb_pc:P1020UTM,36BIT,SDCARD -
+Active powerpc mpc85xx - freescale p1_p2_rdb_pc P1020UTM-PC_SDCARD p1_p2_rdb_pc:P1020UTM,SDCARD -
+Active powerpc mpc85xx - freescale p1_p2_rdb_pc P1021RDB-PC p1_p2_rdb_pc:P1021RDB -
+Active powerpc mpc85xx - freescale p1_p2_rdb_pc P1021RDB-PC_36BIT p1_p2_rdb_pc:P1021RDB,36BIT -
+Active powerpc mpc85xx - freescale p1_p2_rdb_pc P1021RDB-PC_36BIT_NAND p1_p2_rdb_pc:P1021RDB,36BIT,NAND -
+Active powerpc mpc85xx - freescale p1_p2_rdb_pc P1021RDB-PC_36BIT_SDCARD p1_p2_rdb_pc:P1021RDB,36BIT,SDCARD -
+Active powerpc mpc85xx - freescale p1_p2_rdb_pc P1021RDB-PC_36BIT_SPIFLASH p1_p2_rdb_pc:P1021RDB,36BIT,SPIFLASH -
+Active powerpc mpc85xx - freescale p1_p2_rdb_pc P1021RDB-PC_NAND p1_p2_rdb_pc:P1021RDB,NAND -
+Active powerpc mpc85xx - freescale p1_p2_rdb_pc P1021RDB-PC_SDCARD p1_p2_rdb_pc:P1021RDB,SDCARD -
+Active powerpc mpc85xx - freescale p1_p2_rdb_pc P1021RDB-PC_SPIFLASH p1_p2_rdb_pc:P1021RDB,SPIFLASH -
+Active powerpc mpc85xx - freescale p1_p2_rdb_pc P1024RDB p1_p2_rdb_pc:P1024RDB -
+Active powerpc mpc85xx - freescale p1_p2_rdb_pc P1024RDB_36BIT p1_p2_rdb_pc:P1024RDB,36BIT -
+Active powerpc mpc85xx - freescale p1_p2_rdb_pc P1024RDB_NAND p1_p2_rdb_pc:P1024RDB,NAND -
+Active powerpc mpc85xx - freescale p1_p2_rdb_pc P1024RDB_SDCARD p1_p2_rdb_pc:P1024RDB,SDCARD -
+Active powerpc mpc85xx - freescale p1_p2_rdb_pc P1024RDB_SPIFLASH p1_p2_rdb_pc:P1024RDB,SPIFLASH -
+Active powerpc mpc85xx - freescale p1_p2_rdb_pc P1025RDB p1_p2_rdb_pc:P1025RDB -
+Active powerpc mpc85xx - freescale p1_p2_rdb_pc P1025RDB_36BIT p1_p2_rdb_pc:P1025RDB,36BIT -
+Active powerpc mpc85xx - freescale p1_p2_rdb_pc P1025RDB_NAND p1_p2_rdb_pc:P1025RDB,NAND -
+Active powerpc mpc85xx - freescale p1_p2_rdb_pc P1025RDB_SDCARD p1_p2_rdb_pc:P1025RDB,SDCARD -
+Active powerpc mpc85xx - freescale p1_p2_rdb_pc P1025RDB_SPIFLASH p1_p2_rdb_pc:P1025RDB,SPIFLASH -
+Active powerpc mpc85xx - freescale p1_p2_rdb_pc P2020RDB-PC p1_p2_rdb_pc:P2020RDB -
+Active powerpc mpc85xx - freescale p1_p2_rdb_pc P2020RDB-PC_36BIT p1_p2_rdb_pc:P2020RDB,36BIT -
+Active powerpc mpc85xx - freescale p1_p2_rdb_pc P2020RDB-PC_36BIT_NAND p1_p2_rdb_pc:P2020RDB,36BIT,NAND -
+Active powerpc mpc85xx - freescale p1_p2_rdb_pc P2020RDB-PC_36BIT_SDCARD p1_p2_rdb_pc:P2020RDB,36BIT,SDCARD -
+Active powerpc mpc85xx - freescale p1_p2_rdb_pc P2020RDB-PC_36BIT_SPIFLASH p1_p2_rdb_pc:P2020RDB,36BIT,SPIFLASH -
+Active powerpc mpc85xx - freescale p1_p2_rdb_pc P2020RDB-PC_NAND p1_p2_rdb_pc:P2020RDB,NAND -
+Active powerpc mpc85xx - freescale p1_p2_rdb_pc P2020RDB-PC_SDCARD p1_p2_rdb_pc:P2020RDB,SDCARD -
+Active powerpc mpc85xx - freescale p1_p2_rdb_pc P2020RDB-PC_SPIFLASH p1_p2_rdb_pc:P2020RDB,SPIFLASH -
+Active powerpc mpc85xx - freescale p2020come P2020COME_SDCARD P2020COME:SDCARD Ira W. Snyder <iws@ovro.caltech.edu>
+Active powerpc mpc85xx - freescale p2020come P2020COME_SPIFLASH P2020COME:SPIFLASH Ira W. Snyder <iws@ovro.caltech.edu>
+Active powerpc mpc85xx - freescale p2020ds P2020DS - -
+Active powerpc mpc85xx - freescale p2020ds P2020DS_36BIT P2020DS:36BIT -
+Active powerpc mpc85xx - freescale p2020ds P2020DS_DDR2 P2020DS:DDR2 -
+Active powerpc mpc85xx - freescale p2020ds P2020DS_SDCARD P2020DS:SDCARD -
+Active powerpc mpc85xx - freescale p2020ds P2020DS_SPIFLASH P2020DS:SPIFLASH -
+Active powerpc mpc85xx - freescale p2041rdb P2041RDB - -
+Active powerpc mpc85xx - freescale p2041rdb P2041RDB_NAND P2041RDB:RAMBOOT_PBL,NAND,SYS_TEXT_BASE=0xFFF80000 -
+Active powerpc mpc85xx - freescale p2041rdb P2041RDB_SDCARD P2041RDB:RAMBOOT_PBL,SDCARD,SYS_TEXT_BASE=0xFFF80000 -
+Active powerpc mpc85xx - freescale p2041rdb P2041RDB_SECURE_BOOT P2041RDB:SECURE_BOOT -
+Active powerpc mpc85xx - freescale p2041rdb P2041RDB_SPIFLASH P2041RDB:RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF80000 -
+Active powerpc mpc85xx - freescale p2041rdb P2041RDB_SRIO_PCIE_BOOT P2041RDB:SRIO_PCIE_BOOT_SLAVE,SYS_TEXT_BASE=0xFFF80000 -
+Active powerpc mpc85xx - freescale t4qds T4160QDS T4240QDS:PPC_T4160 -
+Active powerpc mpc85xx - freescale t4qds T4160QDS_SDCARD T4240QDS:PPC_T4160,RAMBOOT_PBL,SDCARD,SYS_TEXT_BASE=0xFFF80000 -
+Active powerpc mpc85xx - freescale t4qds T4160QDS_SPIFLASH T4240QDS:PPC_T4160,RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF80000 -
+Active powerpc mpc85xx - freescale t4qds T4240QDS T4240QDS:PPC_T4240 -
+Active powerpc mpc85xx - freescale t4qds T4240QDS_SDCARD T4240QDS:PPC_T4240,RAMBOOT_PBL,SDCARD,SYS_TEXT_BASE=0xFFF80000 -
+Active powerpc mpc85xx - freescale t4qds T4240QDS_SPIFLASH T4240QDS:PPC_T4240,RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF80000 -
+Active powerpc mpc85xx - freescale t4qds T4240QDS_SRIO_PCIE_BOOT T4240QDS:PPC_T4240,SRIO_PCIE_BOOT_SLAVE,SYS_TEXT_BASE=0xFFF80000 -
+Active powerpc mpc85xx - gdsys p1022 controlcenterd_36BIT_SDCARD controlcenterd:36BIT,SDCARD Dirk Eibach <eibach@gdsys.de>
+Active powerpc mpc85xx - gdsys p1022 controlcenterd_36BIT_SDCARD_DEVELOP controlcenterd:36BIT,SDCARD,DEVELOP Dirk Eibach <eibach@gdsys.de>
+Active powerpc mpc85xx - gdsys p1022 controlcenterd_TRAILBLAZER controlcenterd:TRAILBLAZER,SPIFLASH Dirk Eibach <eibach@gdsys.de>
+Active powerpc mpc85xx - gdsys p1022 controlcenterd_TRAILBLAZER_DEVELOP controlcenterd:TRAILBLAZER,SPIFLASH,DEVELOP Dirk Eibach <eibach@gdsys.de>
+Active powerpc mpc85xx - stx stxgp3 stxgp3 - Dan Malek <dan@embeddedalley.com>
+Active powerpc mpc85xx - stx stxssa stxssa stxssa Dan Malek <dan@embeddedalley.com>
+Active powerpc mpc85xx - stx stxssa stxssa_4M stxssa:STXSSA_4M Dan Malek <dan@embeddedalley.com>
+Active powerpc mpc85xx - xes - xpedite520x - -
+Active powerpc mpc85xx - xes - xpedite537x - -
+Active powerpc mpc85xx - xes - xpedite550x - -
+Active powerpc mpc86xx - - - sbc8641d - Paul Gortmaker <paul.gortmaker@windriver.com>
+Active powerpc mpc86xx - freescale mpc8610hpcd MPC8610HPCD - -
+Active powerpc mpc86xx - freescale mpc8641hpcn MPC8641HPCN MPC8641HPCN Kumar Gala <kumar.gala@freescale.com>
+Active powerpc mpc86xx - freescale mpc8641hpcn MPC8641HPCN_36BIT MPC8641HPCN:PHYS_64BIT Kumar Gala <kumar.gala@freescale.com>
+Active powerpc mpc86xx - xes - xpedite517x - -
+Active powerpc mpc8xx - - - hermes - Wolfgang Denk <wd@denx.de>
+Active powerpc mpc8xx - - - lwmon - Wolfgang Denk <wd@denx.de>
+Active powerpc mpc8xx - - - quantum - -
+Active powerpc mpc8xx - - - RRvision - Wolfgang Denk <wd@denx.de>
+Active powerpc mpc8xx - - - spc1920 - -
+Active powerpc mpc8xx - - - svm_sc8xx - John Zhan <zhanz@sinovee.com>
+Active powerpc mpc8xx - - - v37 - -
+Active powerpc mpc8xx - - adder Adder - Yuli Barcohen <yuli@arabellasw.com>
+Active powerpc mpc8xx - - adder Adder87x Adder Yuli Barcohen <yuli@arabellasw.com>
+Active powerpc mpc8xx - - adder AdderII Adder:MPC852T Yuli Barcohen <yuli@arabellasw.com>
+Active powerpc mpc8xx - - adder AdderUSB Adder Yuli Barcohen <yuli@arabellasw.com>
+Active powerpc mpc8xx - - cogent cogent_mpc8xx - Murray Jensen <Murray.Jensen@csiro.au>
+Active powerpc mpc8xx - - esteem192e ESTEEM192E - Conn Clark <clark@esteem.com>
+Active powerpc mpc8xx - - fads MPC86xADS - -
+Active powerpc mpc8xx - - fads MPC885ADS - -
+Active powerpc mpc8xx - - flagadm FLAGADM - K??ri Dav????sson <kd@flaga.is>
+Active powerpc mpc8xx - - gen860t GEN860T - Keith Outwater <Keith_Outwater@mvis.com>
+Active powerpc mpc8xx - - gen860t GEN860T_SC GEN860T:SC Keith Outwater <Keith_Outwater@mvis.com>
+Active powerpc mpc8xx - - icu862 ICU862 - Wolfgang Denk <wd@denx.de>
+Active powerpc mpc8xx - - icu862 ICU862_100MHz ICU862:100MHz Wolfgang Denk <wd@denx.de>
+Active powerpc mpc8xx - - ip860 IP860 - Wolfgang Denk <wd@denx.de>
+Active powerpc mpc8xx - - ivm IVML24 IVML24:IVML24_16M Wolfgang Denk <wd@denx.de>
+Active powerpc mpc8xx - - ivm IVML24_128 IVML24:IVML24_32M Wolfgang Denk <wd@denx.de>
+Active powerpc mpc8xx - - ivm IVML24_256 IVML24:IVML24_64M Wolfgang Denk <wd@denx.de>
+Active powerpc mpc8xx - - ivm IVMS8 IVMS8:IVMS8_16M Wolfgang Denk <wd@denx.de>
+Active powerpc mpc8xx - - ivm IVMS8_128 IVMS8:IVMS8_32M Wolfgang Denk <wd@denx.de>
+Active powerpc mpc8xx - - ivm IVMS8_256 IVMS8:IVMS8_64M Wolfgang Denk <wd@denx.de>
+Active powerpc mpc8xx - - netphone NETPHONE NETPHONE:NETPHONE_VERSION=1 -
+Active powerpc mpc8xx - - netphone NETPHONE_V2 NETPHONE:NETPHONE_VERSION=2 -
+Active powerpc mpc8xx - - netta NETTA NETTA -
+Active powerpc mpc8xx - - netta NETTA_6412 NETTA:NETTA_6412=1 -
+Active powerpc mpc8xx - - netta NETTA_6412_SWAPHOOK NETTA:NETTA_6412=1,NETTA_SWAPHOOK=1 -
+Active powerpc mpc8xx - - netta NETTA_ISDN NETTA:NETTA_ISDN=1 -
+Active powerpc mpc8xx - - netta NETTA_ISDN_6412 NETTA:NETTA_ISDN=1,NETTA_6412=1 -
+Active powerpc mpc8xx - - netta NETTA_ISDN_6412_SWAPHOOK NETTA:NETTA_ISDN=1,NETTA_6412=1,NETTA_SWAPHOOK=1 -
+Active powerpc mpc8xx - - netta NETTA_ISDN_SWAPHOOK NETTA:NETTA_ISDN=1,NETTA_SWAPHOOK=1 -
+Active powerpc mpc8xx - - netta NETTA_SWAPHOOK NETTA:NETTA_SWAPHOOK=1 -
+Active powerpc mpc8xx - - netta2 NETTA2 NETTA2:NETTA2_VERSION=1 -
+Active powerpc mpc8xx - - netta2 NETTA2_V2 NETTA2:NETTA2_VERSION=2 -
+Active powerpc mpc8xx - - netvia NETVIA NETVIA:NETVIA_VERSION=1 Pantelis Antoniou <panto@intracom.gr>
+Active powerpc mpc8xx - - netvia NETVIA_V2 NETVIA:NETVIA_VERSION=2 Pantelis Antoniou <panto@intracom.gr>
+Active powerpc mpc8xx - - r360mpi R360MPI - Wolfgang Denk <wd@denx.de>
+Active powerpc mpc8xx - - rbc823 RBC823 - -
+Active powerpc mpc8xx - - RPXlite_dw RPXlite_DW RPXlite_DW -
+Active powerpc mpc8xx - - RPXlite_dw RPXlite_DW_64 RPXlite_DW:RPXlite_64MHz -
+Active powerpc mpc8xx - - RPXlite_dw RPXlite_DW_64_LCD RPXlite_DW:RPXlite_64MHz,LCD,NEC_NL6448BC20 -
+Active powerpc mpc8xx - - RPXlite_dw RPXlite_DW_LCD RPXlite_DW:LCD,NEC_NL6448BC20 -
+Active powerpc mpc8xx - - RPXlite_dw RPXlite_DW_NVRAM RPXlite_DW:ENV_IS_IN_NVRAM -
+Active powerpc mpc8xx - - RPXlite_dw RPXlite_DW_NVRAM_64 RPXlite_DW:RPXlite_64MHz,ENV_IS_IN_NVRAM -
+Active powerpc mpc8xx - - RPXlite_dw RPXlite_DW_NVRAM_64_LCD RPXlite_DW:RPXlite_64MHz,LCD,NEC_NL6448BC20,ENV_IS_IN_NVRAM -
+Active powerpc mpc8xx - - RPXlite_dw RPXlite_DW_NVRAM_LCD RPXlite_DW:LCD,NEC_NL6448BC20,ENV_IS_IN_NVRAM -
+Active powerpc mpc8xx - - RRvision RRvision_LCD RRvision:LCD,SHARP_LQ104V7DS01 Wolfgang Denk <wd@denx.de>
+Active powerpc mpc8xx - - sixnet SXNI855T - Dave Ellis <DGE@sixnetio.com>
+Active powerpc mpc8xx - - spd8xx SPD823TS - Wolfgang Denk <wd@denx.de>
+Active powerpc mpc8xx - eltec mhpc MHPC - Frank Gottschling <fgottschling@eltec.de>
+Active powerpc mpc8xx - emk top860 TOP860 - Reinhard Meyer <reinhard.meyer@emk-elektronik.de>
+Active powerpc mpc8xx - kup kup4k KUP4K - Klaus Heydeck <heydeck@kieback-peter.de>
+Active powerpc mpc8xx - kup kup4x KUP4X - Klaus Heydeck <heydeck@kieback-peter.de>
+Active powerpc mpc8xx - LEOX elpt860 ELPT860 - The LEOX team <team@leox.org>
+Active powerpc mpc8xx - manroland - uc100 - Stefan Roese <sr@denx.de>
+Active powerpc mpc8xx - snmc qs850 QS823 - -
+Active powerpc mpc8xx - snmc qs850 QS850 - -
+Active powerpc mpc8xx - snmc qs860t QS860T - -
+Active powerpc mpc8xx - stx stxxtc stxxtc - Dan Malek <dan@embeddedalley.com>
+Active powerpc mpc8xx - tqc tqm8xx FPS850L - Wolfgang Denk <wd@denx.de>
+Active powerpc mpc8xx - tqc tqm8xx FPS860L - Wolfgang Denk <wd@denx.de>
+Active powerpc mpc8xx - tqc tqm8xx NSCU - -
+Active powerpc mpc8xx - tqc tqm8xx SM850 - Wolfgang Denk <wd@denx.de>
+Active powerpc mpc8xx - tqc tqm8xx TK885D - -
+Active powerpc mpc8xx - tqc tqm8xx TQM823L - Wolfgang Denk <wd@denx.de>
+Active powerpc mpc8xx - tqc tqm8xx TQM823L_LCD TQM823L:LCD,NEC_NL6448BC20 Wolfgang Denk <wd@denx.de>
+Active powerpc mpc8xx - tqc tqm8xx TQM823M - -
+Active powerpc mpc8xx - tqc tqm8xx TQM850L - Wolfgang Denk <wd@denx.de>
+Active powerpc mpc8xx - tqc tqm8xx TQM850M - -
+Active powerpc mpc8xx - tqc tqm8xx TQM855L - Wolfgang Denk <wd@denx.de>
+Active powerpc mpc8xx - tqc tqm8xx TQM855M - -
+Active powerpc mpc8xx - tqc tqm8xx TQM860L - Wolfgang Denk <wd@denx.de>
+Active powerpc mpc8xx - tqc tqm8xx TQM860M - -
+Active powerpc mpc8xx - tqc tqm8xx TQM862L - -
+Active powerpc mpc8xx - tqc tqm8xx TQM862M - -
+Active powerpc mpc8xx - tqc tqm8xx TQM866M - -
+Active powerpc mpc8xx - tqc tqm8xx TQM885D - -
+Active powerpc mpc8xx - tqc tqm8xx TTTech TQM823L:LCD,SHARP_LQ104V7DS01 Wolfgang Denk <wd@denx.de>
+Active powerpc mpc8xx - tqc tqm8xx virtlab2 - -
+Active powerpc mpc8xx - tqc tqm8xx wtk TQM823L:LCD,SHARP_LQ065T9DR51U Wolfgang Denk <wd@denx.de>
+Active powerpc ppc4xx - - - csb272 - Tolunay Orkun <torkun@nextio.com>
+Active powerpc ppc4xx - - - csb472 - Tolunay Orkun <torkun@nextio.com>
+Active powerpc ppc4xx - - - korat - Larry Johnson <lrj@acm.org>
+Active powerpc ppc4xx - - - lwmon5 - Stefan Roese <sr@denx.de>
+Active powerpc ppc4xx - - - pcs440ep - Stefan Roese <sr@denx.de>
+Active powerpc ppc4xx - - - quad100hd - Gary Jennejohn <garyj@denx.de>
+Active powerpc ppc4xx - - - sbc405 - -
+Active powerpc ppc4xx - - - sc3 - Heiko Schocher <hs@denx.de>
+Active powerpc ppc4xx - - - t3corp - Stefan Roese <sr@denx.de>
+Active powerpc ppc4xx - - - zeus - Stefan Roese <sr@denx.de>
+Active powerpc ppc4xx - - g2000 G2000 - Matthias Fuchs <matthias.fuchs@esd-electronics.com>
+Active powerpc ppc4xx - - jse JSE - Stephen Williams <steve@icarus.com>
+Active powerpc ppc4xx - - korat korat_perm korat:KORAT_PERMANENT Larry Johnson <lrj@acm.org>
+Active powerpc ppc4xx - - lwmon5 lcd4_lwmon5 lwmon5:LCD4_LWMON5 Stefan Roese <sr@denx.de>
+Active powerpc ppc4xx - - w7o W7OLMC - Erik Theisen <etheisen@mindspring.com>
+Active powerpc ppc4xx - - w7o W7OLMG - Erik Theisen <etheisen@mindspring.com>
+Active powerpc ppc4xx - amcc - acadia - Stefan Roese <sr@denx.de>
+Active powerpc ppc4xx - amcc - bamboo - Stefan Roese <sr@denx.de>
+Active powerpc ppc4xx - amcc - bluestone - Tirumala Marri <tmarri@apm.com>
+Active powerpc ppc4xx - amcc - bubinga - -
+Active powerpc ppc4xx - amcc - ebony - Stefan Roese <sr@denx.de>
+Active powerpc ppc4xx - amcc - katmai - Stefan Roese <sr@denx.de>
+Active powerpc ppc4xx - amcc - luan - John Otken <jotken@softadvances.com>
+Active powerpc ppc4xx - amcc - makalu - Stefan Roese <sr@denx.de>
+Active powerpc ppc4xx - amcc - ocotea - Stefan Roese <sr@denx.de>
+Active powerpc ppc4xx - amcc - redwood - Feng Kan <fkan@amcc.com>
+Active powerpc ppc4xx - amcc - taihu - John Otken <jotken@softadvances.com>
+Active powerpc ppc4xx - amcc - taishan - Stefan Roese <sr@denx.de>
+Active powerpc ppc4xx - amcc - yucca - -
+Active powerpc ppc4xx - amcc acadia acadia_nand acadia:NAND_U_BOOT,SYS_TEXT_BASE=0x01000000 Stefan Roese <sr@denx.de>
+Active powerpc ppc4xx - amcc bamboo bamboo_nand bamboo:NAND_U_BOOT,SYS_TEXT_BASE=0x01000000 Stefan Roese <sr@denx.de>
+Active powerpc ppc4xx - amcc canyonlands arches canyonlands:ARCHES Stefan Roese <sr@denx.de>
+Active powerpc ppc4xx - amcc canyonlands canyonlands canyonlands:CANYONLANDS Stefan Roese <sr@denx.de>
+Active powerpc ppc4xx - amcc canyonlands canyonlands_nand canyonlands:CANYONLANDS,NAND_U_BOOT,SYS_TEXT_BASE=0x01000000 Stefan Roese <sr@denx.de>
+Active powerpc ppc4xx - amcc canyonlands glacier canyonlands:GLACIER Stefan Roese <sr@denx.de>
+Active powerpc ppc4xx - amcc canyonlands glacier_nand canyonlands:GLACIER,NAND_U_BOOT,SYS_TEXT_BASE=0x01000000 Stefan Roese <sr@denx.de>
+Active powerpc ppc4xx - amcc kilauea haleakala kilauea:HALEAKALA Stefan Roese <sr@denx.de>
+Active powerpc ppc4xx - amcc kilauea haleakala_nand kilauea:NAND_U_BOOT,SYS_TEXT_BASE=0x01000000 Stefan Roese <sr@denx.de>
+Active powerpc ppc4xx - amcc kilauea kilauea kilauea:KILAUEA Stefan Roese <sr@denx.de>
+Active powerpc ppc4xx - amcc kilauea kilauea_nand kilauea:NAND_U_BOOT,SYS_TEXT_BASE=0x01000000 Stefan Roese <sr@denx.de>
+Active powerpc ppc4xx - amcc sequoia rainier sequoia:RAINIER Stefan Roese <sr@denx.de>
+Active powerpc ppc4xx - amcc sequoia rainier_nand sequoia:RAINIER,NAND_U_BOOT,SYS_TEXT_BASE=0x01000000 Stefan Roese <sr@denx.de>
+Active powerpc ppc4xx - amcc sequoia rainier_ramboot sequoia:RAINIER,SYS_RAMBOOT,SYS_TEXT_BASE=0x01000000,SYS_LDSCRIPT=board/amcc/sequoia/u-boot-ram.lds Stefan Roese <sr@denx.de>
+Active powerpc ppc4xx - amcc sequoia sequoia sequoia:SEQUOIA Stefan Roese <sr@denx.de>
+Active powerpc ppc4xx - amcc sequoia sequoia_nand sequoia:SEQUOIA,NAND_U_BOOT,SYS_TEXT_BASE=0x01000000 Stefan Roese <sr@denx.de>
+Active powerpc ppc4xx - amcc sequoia sequoia_ramboot sequoia:SEQUOIA,SYS_RAMBOOT,SYS_TEXT_BASE=0x01000000,SYS_LDSCRIPT=board/amcc/sequoia/u-boot-ram.lds Stefan Roese <sr@denx.de>
+Active powerpc ppc4xx - amcc walnut sycamore walnut Stefan Roese <sr@denx.de>
+Active powerpc ppc4xx - amcc walnut walnut - Stefan Roese <sr@denx.de>
+Active powerpc ppc4xx - amcc yosemite yellowstone yosemite:YELLOWSTONE Stefan Roese <sr@denx.de>
+Active powerpc ppc4xx - amcc yosemite yosemite yosemite:YOSEMITE Stefan Roese <sr@denx.de>
+Active powerpc ppc4xx - avnet fx12mm fx12mm fx12mm:SYS_TEXT_BASE=0x04000000,RESET_VECTOR_ADDRESS=0x04100000,INIT_TLB=board/xilinx/ppc405-generic/init.o Georg Schardt <schardt@team-ctech.de>
+Active powerpc ppc4xx - avnet fx12mm fx12mm_flash fx12mm:SYS_TEXT_BASE=0xF7F60000,RESET_VECTOR_ADDRESS=0xF7FFFFFC,INIT_TLB=board/xilinx/ppc405-generic/init.o Georg Schardt <schardt@team-ctech.de>
+Active powerpc ppc4xx - avnet v5fx30teval v5fx30teval v5fx30teval:SYS_TEXT_BASE=0x04000000,RESET_VECTOR_ADDRESS=0x04100000,BOOT_FROM_XMD=1,INIT_TLB=board/xilinx/ppc440-generic/init.o Ricardo Ribalda <ricardo.ribalda@uam.es>
+Active powerpc ppc4xx - avnet v5fx30teval v5fx30teval_flash v5fx30teval:SYS_TEXT_BASE=0xF7F60000,RESET_VECTOR_ADDRESS=0xF7FFFFFC,INIT_TLB=board/xilinx/ppc440-generic/init.o Ricardo Ribalda <ricardo.ribalda@uam.es>
+Active powerpc ppc4xx - cray L1 CRAYL1 - David Updegraff <dave@cray.com>
+Active powerpc ppc4xx - dave PPChameleonEVB CATcenter CATcenter:PPCHAMELEON_MODULE_MODEL=1 Andrea "llandre" Marson <andrea.marson@dave-tech.it>
+Active powerpc ppc4xx - dave PPChameleonEVB CATcenter_25 CATcenter:PPCHAMELEON_MODULE_MODEL=1,PPCHAMELEON_CLK_25 Andrea "llandre" Marson <andrea.marson@dave-tech.it>
+Active powerpc ppc4xx - dave PPChameleonEVB CATcenter_33 CATcenter:PPCHAMELEON_MODULE_MODEL=1,PPCHAMELEON_CLK_33 Andrea "llandre" Marson <andrea.marson@dave-tech.it>
+Active powerpc ppc4xx - dave PPChameleonEVB PPChameleonEVB - Andrea "llandre" Marson <andrea.marson@dave-tech.it>
+Active powerpc ppc4xx - dave PPChameleonEVB PPChameleonEVB_BA_25 PPChameleonEVB:PPCHAMELEON_MODULE_MODEL=0,PPCHAMELEON_CLK_25 Andrea "llandre" Marson <andrea.marson@dave-tech.it>
+Active powerpc ppc4xx - dave PPChameleonEVB PPChameleonEVB_BA_33 PPChameleonEVB:PPCHAMELEON_MODULE_MODEL=0,PPCHAMELEON_CLK_33 Andrea "llandre" Marson <andrea.marson@dave-tech.it>
+Active powerpc ppc4xx - dave PPChameleonEVB PPChameleonEVB_HI_25 PPChameleonEVB:PPCHAMELEON_MODULE_MODEL=2,PPCHAMELEON_CLK_25 Andrea "llandre" Marson <andrea.marson@dave-tech.it>
+Active powerpc ppc4xx - dave PPChameleonEVB PPChameleonEVB_HI_33 PPChameleonEVB:PPCHAMELEON_MODULE_MODEL=2,PPCHAMELEON_CLK_33 Andrea "llandre" Marson <andrea.marson@dave-tech.it>
+Active powerpc ppc4xx - dave PPChameleonEVB PPChameleonEVB_ME_25 PPChameleonEVB:PPCHAMELEON_MODULE_MODEL=1,PPCHAMELEON_CLK_25 Andrea "llandre" Marson <andrea.marson@dave-tech.it>
+Active powerpc ppc4xx - dave PPChameleonEVB PPChameleonEVB_ME_33 PPChameleonEVB:PPCHAMELEON_MODULE_MODEL=1,PPCHAMELEON_CLK_33 Andrea "llandre" Marson <andrea.marson@dave-tech.it>
+Active powerpc ppc4xx - esd apc405 APC405 - Matthias Fuchs <matthias.fuchs@esd-electronics.com>
+Active powerpc ppc4xx - esd ar405 AR405 - Matthias Fuchs <matthias.fuchs@esd-electronics.com>
+Active powerpc ppc4xx - esd ash405 ASH405 - Matthias Fuchs <matthias.fuchs@esd-electronics.com>
+Active powerpc ppc4xx - esd canbt CANBT - Matthias Fuchs <matthias.fuchs@esd-electronics.com>
+Active powerpc ppc4xx - esd cms700 CMS700 - Matthias Fuchs <matthias.fuchs@esd-electronics.com>
+Active powerpc ppc4xx - esd cpci2dp CPCI2DP - Matthias Fuchs <matthias.fuchs@esd-electronics.com>
+Active powerpc ppc4xx - esd cpci405 CPCI405 - Matthias Fuchs <matthias.fuchs@esd-electronics.com>
+Active powerpc ppc4xx - esd cpci405 CPCI4052 - Matthias Fuchs <matthias.fuchs@esd-electronics.com>
+Active powerpc ppc4xx - esd cpci405 CPCI405AB - Matthias Fuchs <matthias.fuchs@esd-electronics.com>
+Active powerpc ppc4xx - esd cpci405 CPCI405DT - Matthias Fuchs <matthias.fuchs@esd-electronics.com>
+Active powerpc ppc4xx - esd cpciiser4 CPCIISER4 - Matthias Fuchs <matthias.fuchs@esd-electronics.com>
+Active powerpc ppc4xx - esd dp405 DP405 - Matthias Fuchs <matthias.fuchs@esd-electronics.com>
+Active powerpc ppc4xx - esd du405 DU405 - Matthias Fuchs <matthias.fuchs@esd-electronics.com>
+Active powerpc ppc4xx - esd du440 DU440 - Matthias Fuchs <matthias.fuchs@esd-electronics.com>
+Active powerpc ppc4xx - esd hh405 HH405 - Matthias Fuchs <matthias.fuchs@esd-electronics.com>
+Active powerpc ppc4xx - esd hub405 HUB405 - Matthias Fuchs <matthias.fuchs@esd-electronics.com>
+Active powerpc ppc4xx - esd ocrtc OCRTC - Matthias Fuchs <matthias.fuchs@esd-electronics.com>
+Active powerpc ppc4xx - esd pci405 PCI405 - Matthias Fuchs <matthias.fuchs@esd-electronics.com>
+Active powerpc ppc4xx - esd plu405 PLU405 - Matthias Fuchs <matthias.fuchs@esd-electronics.com>
+Active powerpc ppc4xx - esd pmc405 PMC405 - Matthias Fuchs <matthias.fuchs@esd-electronics.com>
+Active powerpc ppc4xx - esd pmc405de PMC405DE - Matthias Fuchs <matthias.fuchs@esd-electronics.com>
+Active powerpc ppc4xx - esd pmc440 PMC440 - Matthias Fuchs <matthias.fuchs@esd-electronics.com>
+Active powerpc ppc4xx - esd voh405 VOH405 - Matthias Fuchs <matthias.fuchs@esd-electronics.com>
+Active powerpc ppc4xx - esd vom405 VOM405 - Matthias Fuchs <matthias.fuchs@esd-electronics.com>
+Active powerpc ppc4xx - esd wuh405 WUH405 - Matthias Fuchs <matthias.fuchs@esd-electronics.com>
+Active powerpc ppc4xx - gdsys - dlvision - Dirk Eibach <eibach@gdsys.de>
+Active powerpc ppc4xx - gdsys - gdppc440etx - Dirk Eibach <eibach@gdsys.de>
+Active powerpc ppc4xx - gdsys 405ep dlvision-10g - Dirk Eibach <eibach@gdsys.de>
+Active powerpc ppc4xx - gdsys 405ep io - Dirk Eibach <eibach@gdsys.de>
+Active powerpc ppc4xx - gdsys 405ep iocon - Dirk Eibach <eibach@gdsys.de>
+Active powerpc ppc4xx - gdsys 405ep neo - Dirk Eibach <eibach@gdsys.de>
+Active powerpc ppc4xx - gdsys 405ex io64 - Dirk Eibach <eibach@gdsys.de>
+Active powerpc ppc4xx - gdsys intip devconcenter intip:DEVCONCENTER Dirk Eibach <eibach@gdsys.de>
+Active powerpc ppc4xx - gdsys intip intip intip:INTIB Dirk Eibach <eibach@gdsys.de>
+Active powerpc ppc4xx - mosaixtech - icon - Stefan Roese <sr@denx.de>
+Active powerpc ppc4xx - mpl mip405 MIP405 - Denis Peter <d.peter@mpl.ch>
+Active powerpc ppc4xx - mpl mip405 MIP405T MIP405:MIP405T Denis Peter <d.peter@mpl.ch>
+Active powerpc ppc4xx - mpl pip405 PIP405 - Denis Peter <d.peter@mpl.ch>
+Active powerpc ppc4xx - prodrive - alpr - Stefan Roese <sr@denx.de>
+Active powerpc ppc4xx - prodrive - p3p440 - Stefan Roese <sr@denx.de>
+Active powerpc ppc4xx - sandburst karef KAREF - Travis Sawyer (travis.sawyer at sandburst.com>
+Active powerpc ppc4xx - sandburst metrobox METROBOX - Travis Sawyer (travis.sawyer at sandburst.com>
+Active powerpc ppc4xx - xes - xpedite1000 - Peter Tyser <ptyser@xes-inc.com>
+Active powerpc ppc4xx - xilinx ml507 ml507 ml507:SYS_TEXT_BASE=0x04000000,RESET_VECTOR_ADDRESS=0x04100000,BOOT_FROM_XMD=1,INIT_TLB=board/xilinx/ppc440-generic/init.o Ricardo Ribalda <ricardo.ribalda@uam.es>
+Active powerpc ppc4xx - xilinx ml507 ml507_flash ml507:SYS_TEXT_BASE=0xF7F60000,RESET_VECTOR_ADDRESS=0xF7FFFFFC,INIT_TLB=board/xilinx/ppc440-generic/init.o Ricardo Ribalda <ricardo.ribalda@uam.es>
+Active powerpc ppc4xx - xilinx ppc405-generic xilinx-ppc405-generic xilinx-ppc405-generic:SYS_TEXT_BASE=0x04000000,RESET_VECTOR_ADDRESS=0x04100000 Ricardo Ribalda <ricardo.ribalda@uam.es>
+Active powerpc ppc4xx - xilinx ppc405-generic xilinx-ppc405-generic_flash xilinx-ppc405-generic:SYS_TEXT_BASE=0xF7F60000,RESET_VECTOR_ADDRESS=0xF7FFFFFC Ricardo Ribalda <ricardo.ribalda@uam.es>
+Active powerpc ppc4xx - xilinx ppc440-generic xilinx-ppc440-generic xilinx-ppc440-generic:SYS_TEXT_BASE=0x04000000,RESET_VECTOR_ADDRESS=0x04100000,BOOT_FROM_XMD=1 Ricardo Ribalda <ricardo.ribalda@uam.es>
+Active powerpc ppc4xx - xilinx ppc440-generic xilinx-ppc440-generic_flash xilinx-ppc440-generic:SYS_TEXT_BASE=0xF7F60000,RESET_VECTOR_ADDRESS=0xF7FFFFFC Ricardo Ribalda <ricardo.ribalda@uam.es>
+Active sandbox sandbox - sandbox sandbox sandbox - Simon Glass <sjg@chromium.org>
+Active sh sh2 - renesas rsk7203 rsk7203 - Nobuhiro Iwamatsu <iwamatsu.nobuhiro@renesas.com>:Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
+Active sh sh2 - renesas rsk7264 rsk7264 - Phil Edworthy <phil.edworthy@renesas.com>
+Active sh sh2 - renesas rsk7269 rsk7269 - -
+Active sh sh3 - - mpr2 mpr2 - Mark Jonas <mark.jonas@de.bosch.com>
+Active sh sh3 - - ms7720se ms7720se - Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
+Active sh sh3 - - shmin shmin - Nobuhiro Iwamatsu <iwamatsu.nobuhiro@renesas.com>:Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
+Active sh sh4 - - espt espt - -
+Active sh sh4 - - ms7722se ms7722se - Nobuhiro Iwamatsu <iwamatsu.nobuhiro@renesas.com>:Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
+Active sh sh4 - - ms7750se ms7750se - Nobuhiro Iwamatsu <iwamatsu.nobuhiro@renesas.com>:Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
+Active sh sh4 - alphaproject ap_sh4a_4a ap_sh4a_4a - Nobuhiro Iwamatsu <iwamatsu.nobuhiro@renesas.com>:Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
+Active sh sh4 - renesas ap325rxa ap325rxa - Nobuhiro Iwamatsu <iwamatsu.nobuhiro@renesas.com>:Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
+Active sh sh4 - renesas ecovec ecovec - Nobuhiro Iwamatsu <iwamatsu.nobuhiro@renesas.com>:Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
+Active sh sh4 - renesas MigoR MigoR - -
+Active sh sh4 - renesas r0p7734 r0p7734 - Nobuhiro Iwamatsu <iwamatsu.nobuhiro@renesas.com>:Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
+Active sh sh4 - renesas r2dplus r2dplus - Nobuhiro Iwamatsu <iwamatsu.nobuhiro@renesas.com>:Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
+Active sh sh4 - renesas r7780mp r7780mp - Nobuhiro Iwamatsu <iwamatsu.nobuhiro@renesas.com>:Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
+Active sh sh4 - renesas sh7752evb sh7752evb - -
+Active sh sh4 - renesas sh7757lcr sh7757lcr - -
+Active sh sh4 - renesas sh7763rdp sh7763rdp - Nobuhiro Iwamatsu <iwamatsu.nobuhiro@renesas.com>:Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
+Active sh sh4 - renesas sh7785lcr sh7785lcr - -
+Active sh sh4 - renesas sh7785lcr sh7785lcr_32bit sh7785lcr:SH_32BIT=1 -
+Active sparc leon2 - gaisler - grsim_leon2 - -
+Active sparc leon3 - gaisler - gr_cpci_ax2000 - -
+Active sparc leon3 - gaisler - gr_ep2s60 - -
+Active sparc leon3 - gaisler - gr_xc3s_1500 - -
+Active sparc leon3 - gaisler - grsim - -
+Active x86 x86 coreboot chromebook-x86 coreboot coreboot-x86 coreboot:SYS_TEXT_BASE=0x01110000 -
+Orphan arm arm1136 mx31 - imx31_phycore imx31_phycore_eet imx31_phycore:IMX31_PHYCORE_EET Kshitij Gupta <kshitij@ti.com>
+Orphan arm arm1136 mx31 freescale - mx31ads - Kshitij Gupta <kshitij@ti.com>
+Orphan arm arm925t - ti - omap1510inn - Kshitij Gupta <kshitij@ti.com>
+Orphan arm arm926ejs versatile armltd versatile versatileab versatile:ARCH_VERSATILE_AB -
+Orphan arm arm926ejs versatile armltd versatile versatilepb versatile:ARCH_VERSATILE_PB -
+Orphan arm arm926ejs versatile armltd versatile versatileqemu versatile:ARCH_VERSATILE_QEMU,ARCH_VERSATILE_PB -
+Orphan arm pxa - - - lubbock - Kshitij Gupta <kshitij@ti.com>
+Orphan mips mips32 au1x00 - dbau1x00 dbau1000 dbau1x00:DBAU1000 Thomas Lange <thomas@corelatus.se>
+Orphan mips mips32 au1x00 - dbau1x00 dbau1100 dbau1x00:DBAU1100 Thomas Lange <thomas@corelatus.se>
+Orphan mips mips32 au1x00 - dbau1x00 dbau1500 dbau1x00:DBAU1500 Thomas Lange <thomas@corelatus.se>
+Orphan mips mips32 au1x00 - dbau1x00 dbau1550 dbau1x00:DBAU1550 Thomas Lange <thomas@corelatus.se>
+Orphan mips mips32 au1x00 - dbau1x00 dbau1550_el dbau1x00:DBAU1550,SYS_LITTLE_ENDIAN Thomas Lange <thomas@corelatus.se>
+Orphan powerpc 74xx_7xx - - evb64260 EVB64260 EVB64260 -
+Orphan powerpc 74xx_7xx - - evb64260 EVB64260_750CX EVB64260 Eran Man <eran@nbase.co.il>:-
+Orphan powerpc mpc824x - - mousse MOUSSE - -
+Orphan powerpc mpc8260 - - - rsdproto - -
+Orphan powerpc mpc8260 - - rpxsuper RPXsuper - -
+Orphan powerpc mpc8xx - - - RPXClassic - -
+Orphan powerpc mpc8xx - - - RPXlite - -
+Orphan powerpc mpc8xx - - fads ADS860 - -
+Orphan powerpc mpc8xx - - fads FADS823 - -
+Orphan powerpc mpc8xx - - fads FADS850SAR - -
+Orphan powerpc mpc8xx - - fads FADS860T - -
+Orphan powerpc mpc8xx - - genietv GENIETV - -
+Orphan powerpc mpc8xx - - mbx8xx MBX - -
+Orphan powerpc mpc8xx - - mbx8xx MBX860T - -
+Orphan powerpc mpc8xx - - nx823 NX823 - -
diff --git a/mkconfig b/mkconfig
index 816ae3d..1d06c8e 100755
--- a/mkconfig
+++ b/mkconfig
@@ -23,10 +23,11 @@ options=""
if [ \( $# -eq 2 \) -a \( "$1" = "-A" \) ] ; then
# Automatic mode
- line=`egrep -i "^[[:space:]]*${2}[[:space:]]" boards.cfg` || {
+ line=`awk '($0 !~ /^#/ && $7 ~ /^'"$2"'$/) { print $1, $2, $3, $4, $5, $6, $7, $8 }' boards.cfg`
+ if [ -z "$line" ] ; then
echo "make: *** No rule to make target \`$2_config'. Stop." >&2
exit 1
- }
+ fi
set ${line}
# add default board name if needed
@@ -37,44 +38,44 @@ while [ $# -gt 0 ] ; do
case "$1" in
--) shift ; break ;;
-a) shift ; APPEND=yes ;;
- -n) shift ; BOARD_NAME="${1%_config}" ; shift ;;
+ -n) shift ; BOARD_NAME="${7%_config}" ; shift ;;
-t) shift ; TARGETS="`echo $1 | sed 's:_: :g'` ${TARGETS}" ; shift ;;
*) break ;;
esac
done
-[ $# -lt 4 ] && exit 1
-[ $# -gt 7 ] && exit 1
+[ $# -lt 7 ] && exit 1
+[ $# -gt 8 ] && exit 1
# Strip all options and/or _config suffixes
-CONFIG_NAME="${1%_config}"
+CONFIG_NAME="${7%_config}"
-[ "${BOARD_NAME}" ] || BOARD_NAME="${1%_config}"
+[ "${BOARD_NAME}" ] || BOARD_NAME="${7%_config}"
arch="$2"
cpu=`echo $3 | awk 'BEGIN {FS = ":"} ; {print $1}'`
spl_cpu=`echo $3 | awk 'BEGIN {FS = ":"} ; {print $2}'`
-if [ "$4" = "-" ] ; then
+if [ "$6" = "-" ] ; then
board=${BOARD_NAME}
else
- board="$4"
+ board="$6"
fi
-[ $# -gt 4 ] && [ "$5" != "-" ] && vendor="$5"
-[ $# -gt 5 ] && [ "$6" != "-" ] && soc="$6"
-[ $# -gt 6 ] && [ "$7" != "-" ] && {
+[ "$5" != "-" ] && vendor="$5"
+[ "$4" != "-" ] && soc="$4"
+[ $# -gt 7 ] && [ "$8" != "-" ] && {
# check if we have a board config name in the options field
# the options field mave have a board config name and a list
# of options, both separated by a colon (':'); the options are
# separated by commas (',').
#
# Check for board name
- tmp="${7%:*}"
+ tmp="${8%:*}"
if [ "$tmp" ] ; then
CONFIG_NAME="$tmp"
fi
# Check if we only have a colon...
- if [ "${tmp}" != "$7" ] ; then
- options=${7#*:}
+ if [ "${tmp}" != "$8" ] ; then
+ options=${8#*:}
TARGETS="`echo ${options} | sed 's:,: :g'` ${TARGETS}"
fi
}
diff --git a/tools/buildman/board.py b/tools/buildman/board.py
index cc7b5d0..a388896 100644
--- a/tools/buildman/board.py
+++ b/tools/buildman/board.py
@@ -63,7 +63,7 @@ class Boards:
for upto in range(len(fields)):
if fields[upto] == '-':
fields[upto] = ''
- while len(fields) < 7:
+ while len(fields) < 9:
fields.append('')
board = Board(*fields)
diff --git a/tools/reformat.py b/tools/reformat.py
new file mode 100755
index 0000000..ff6633f
--- /dev/null
+++ b/tools/reformat.py
@@ -0,0 +1,132 @@
+#! /usr/bin/python
+########################################################################
+#
+# reorder and reformat a file in columns
+#
+# this utility takes lines from its standard input and reproduces them,
+# partially reordered and reformatted, on its standard output.
+#
+# It has the same effect as a 'sort | column -t', with the exception
+# that empty lines, as well as lines which start with a '#' sign, are
+# not affected, i.e. they keep their position and formatting, and act
+# as separators, i.e. the parts before and after them are each sorted
+# separately (but overall field widths are computed across the whole
+# input).
+#
+# Options:
+# -i:
+# --ignore-case:
+# Do not consider case when sorting.
+# -d:
+# --default:
+# What to chage empty fields to.
+# -s <N>:
+# --split=<N>:
+# Treat only the first N whitespace sequences as separators.
+# line content after the Nth separator will count as only one
+# field even if it contains whitespace.
+# Example : '-s 2' causes input 'a b c d e' to be split into
+# three fields, 'a', 'b', and 'c d e'.
+#
+# boards.cfg requires -ids 6.
+#
+########################################################################
+
+import sys, getopt, locale
+
+# ensure we sort using the C locale.
+
+locale.setlocale(locale.LC_ALL, 'C')
+
+# check options
+
+maxsplit = 0
+ignore_case = 0
+default_field =''
+
+try:
+ opts, args = getopt.getopt(sys.argv[1:], "id:s:",
+ ["ignore-case","default","split="])
+except getopt.GetoptError as err:
+ print str(err) # will print something like "option -a not recognized"
+ sys.exit(2)
+
+for o, a in opts:
+ if o in ("-s", "--split"):
+ maxsplit = eval(a)
+ elif o in ("-i", "--ignore-case"):
+ ignore_case = 1
+ elif o in ("-d", "--default"):
+ default_field = a
+ else:
+ assert False, "unhandled option"
+
+# collect all lines from standard input and, for the ones which must be
+# reformatted and sorted, count their fields and compute each field's
+# maximum size
+
+input_lines = []
+field_width = []
+
+for line in sys.stdin:
+ # remove final end of line
+ input_line = line.strip('\n')
+ if (len(input_line)>0) and (input_line[0] != '#'):
+ # sortable line: split into fields
+ fields = input_line.split(None,maxsplit)
+ # if there are new fields, top up field_widths
+ for f in range(len(field_width), len(fields)):
+ field_width.append(0)
+ # compute the maximum witdh of each field
+ for f in range(len(fields)):
+ field_width[f] = max(field_width[f],len(fields[f]))
+ # collect the line for next stage
+ input_lines.append(input_line)
+
+# run through collected input lines, collect the ones which must be
+# reformatted and sorted, and whenever a non-reformattable, non-sortable
+# line is met, sort the collected lines before it and append them to the
+# output lines, then add the non-sortable line too.
+
+output_lines = []
+sortable_lines = []
+for input_line in input_lines:
+ if (len(input_line)>0) and (input_line[0] != '#'):
+ # this line should be reformatted and sorted
+ input_fields = input_line.split(None,maxsplit)
+ output_fields = [];
+ # reformat each field to this field's column width
+ for f in range(len(input_fields)):
+ output_field = input_fields[f];
+ output_fields.append(output_field.ljust(field_width[f]))
+ # any missing field is set to default if it exists
+ if default_field != '':
+ for f in range(len(input_fields),len(field_width)):
+ output_fields.append(default_field.ljust(field_width[f]))
+ # join fields using two spaces, like column -t would
+ output_line = ' '.join(output_fields);
+ # collect line for later
+ sortable_lines.append(output_line)
+ else:
+ # this line is non-sortable
+ # sort collected sortable lines
+ if ignore_case!=0:
+ sortable_lines.sort(key=lambda x: str.lower(locale.strxfrm(x)))
+ else:
+ sortable_lines.sort(key=lambda x: locale.strxfrm(x))
+ # append sortable lines to the final output
+ output_lines.extend(sortable_lines)
+ sortable_lines = []
+ # append non-sortable line to the final output
+ output_lines.append(input_line)
+# maybe we had sortable lines pending, so append them to the final output
+if ignore_case!=0:
+ sortable_lines.sort(key=lambda x: str.lower(locale.strxfrm(x)))
+else:
+ sortable_lines.sort(key=lambda x: locale.strxfrm(x))
+output_lines.extend(sortable_lines)
+
+# run through output lines and print them, except rightmost whitespace
+
+for output_line in output_lines:
+ print output_line.rstrip()
--
1.8.1.2
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2013-04-09 14:12 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-04-09 14:12 UTC (permalink / raw)
To: u-boot
--=20
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-04-03 10:31 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-04-03 10:31 UTC (permalink / raw)
To: ath9k-devel
monitor mode (non promiscuous) are corrupted. They
have the QoS Control stripped, with LLC header
finding itself in the QoS Control. Wireshark shows
such packets as A-MSDU corrupted frames. I tried
restoring the QoS Control but it didn't fix that.
I think we'll need to make a copy of skb, work on
that copy and keep the original skbuff pointer as
a "cookie" to use with mac80211 functions
(tx_status, free_txskb). I'm hoping this won't
degrade tx performance (well, we already do a
memmove()).
Yuck. Any comments?
Michal Kazior (2):
ath10k: make more space in ath10k_skb_cb
ath10k: copy skb during tx
drivers/net/wireless/ath/ath10k/core.h | 32 ++++++++++++++++++++------------
drivers/net/wireless/ath/ath10k/mac.c | 21 +++++++++++++++++++--
drivers/net/wireless/ath/ath10k/txrx.c | 8 +++++---
3 files changed, 44 insertions(+), 17 deletions(-)
--
1.7.9.5
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-04-03 10:31 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-04-03 10:31 UTC (permalink / raw)
To: ath9k-devel
priority feature. For me most important is to support the real monitor
mode (iw wlan0 set type monitor), anything else is just nice to have.
I haven't even looked at your patches, but I'm worried that if a very
low priority feature jeopardizes normal functionality. What if we just
don't support the monitor mode while associated feature? Can we do that?
Disclaimer: I haven't looked at your patches
--
Kalle Valo
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-04-03 10:31 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-04-03 10:31 UTC (permalink / raw)
To: ath9k-devel
Bartosz
On 9 May 2013 12:33, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> Bartosz Markowski <bartosz.markowski@tieto.com> writes:
>
> > Kalle, could you please submit/review these?
>
> I will not commit any patches which have either RFC or RFT tag. And I
> also review them in lower priority.
>
> So if you want me to commit something I recommend to use only PATCH.
>
> --
> Kalle Valo
>
--f46d04388e55778a4404dc43abee
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div>Michal, could you please address Kalle's comments.</div>
<div>=A0</div>
<div>From me ACK for the series (tested OK)</div>
<div>=A0</div>
<div>Bartosz<br><br></div>
<div class=3D"gmail_quote">On 9 May 2013 12:33, Kalle Valo <span dir=3D"ltr=
"><<a href=3D"mailto:kvalo@qca.qualcomm.com" target=3D"_blank">kvalo at qca=
.qualcomm.com</a>></span> wrote:<br>
<blockquote style=3D"BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PA=
DDING-LEFT:1ex" class=3D"gmail_quote">
<div class=3D"im">Bartosz Markowski <<a href=3D"mailto:bartosz.markowski=
@tieto.com">bartosz.markowski at tieto.com</a>> writes:<br><br>> Kalle, =
could you please submit/review these?<br><br></div>I will not commit any pa=
tches which have either RFC or RFT tag. And I<br>
also review them in lower priority.<br><br>So if you want me to commit some=
thing I recommend to use only PATCH.<br><span class=3D"HOEnZb"><font color=
=3D"#888888"><br>--<br>Kalle Valo<br></font></span></blockquote></div><br>
--f46d04388e55778a4404dc43abee--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-04-03 10:31 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-04-03 10:31 UTC (permalink / raw)
To: ath9k-devel
supposed to be prepared for reception of the firmware code from the driver.
This normally happens when the device boots up and passes the first stage of
the bootloader. I suppose (I'm really totally guessing) that the driver
somehow doesn't do something to prepare the device for firmware upload if the
device is already past stage 2.
I would love to have the UART pins connected to some terminal, but I don't
have the soldering tools for such small-scale work...
--
A person is shit's way of making more shit.
-- S. Barnett, anthropologist.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-02-25 7:24 Prasad Lakshman
0 siblings, 0 replies; 732+ messages in thread
From: Prasad Lakshman @ 2013-02-25 7:24 UTC (permalink / raw)
To: kernelnewbies
Hi ,
I am trying to implement own system call in Linux. Kernel version I
chose is 3.5.7
I am following the steps from Linux Kernel Development 3rd edition.
I got two problems with the implementation.
1.while trying to modify the code in kernel , there is no entry.S file
for Intel x86 32 bit architecture. (my be i am missing some thing.)
2.while I am compiling user application with gcc I am getting
error: unknown type name ?helloworld?
my application is as follows
#define __NR_helloworld 367
__syscall0(long, helloworld)
int main ()
{
printf("The helloworld system call is\n";
helloworld();
return 0;
}
I looked at Link [blog.163.com] which is given by Wanny but i could
not find the solution,I could not locate syscall_table_32.s in my
Linux source.
Please help me in identifying the entry.S file for Intel x86 32 bit
architecture in 3.5.7 kernel version sources,where i can make an entry
for my system call into system call table.
Help me in resolving error: unknown type name ?helloworld? in my application.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-02-15 5:48 Kaushal Billore
0 siblings, 0 replies; 732+ messages in thread
From: Kaushal Billore @ 2013-02-15 5:48 UTC (permalink / raw)
To: kernelnewbies
I have some doubt regarding Linux kernel V4l2 API's.
When capture application calls Reqbuff ioctl to allocate n no of buffer which would belongs to v4l2 layer and display application calls the Reqbuff ioctl to allocate N no of buffer which would also belongs to device memory.
Question:
1. V4l2 maintains the generic layer for all devices in which buffers can be allocated by any device and can be handle by any device?
2. If not then while capturing the data from capture device can capture device allocated buffer gets filled and while displaying the same data there memory copy happens between capture buffer and output buffers?
3. If not then I want to capture data from capture device and display onto display device through the v4l2 framework layer.
Awaiting for responce!
Thanks in advance
Kaushal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130215/f203090c/attachment.html
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-02-06 22:30 Jimmy Pan
0 siblings, 0 replies; 732+ messages in thread
From: Jimmy Pan @ 2013-02-06 22:30 UTC (permalink / raw)
To: kernelnewbies
unsuscribe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130207/884e7ffe/attachment.html
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-01-16 21:46 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-01-16 21:46 UTC (permalink / raw)
To: ath9k-devel
driver isn't doing something stupid like running multiple copies of
the reset / setup path on different CPUs/threads, it should be
reliable.
HTH,
Adrian
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2013-01-16 21:46 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2013-01-16 21:46 UTC (permalink / raw)
To: ath9k-devel
limitation in that it must not be reset more than once. That seems
like not so reliable PCIe IP, as long as the issue really is well
understood, but I'm not sure?
I would really like to hear the exact details about what the hardware
requires.
//Peter
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-12-29 9:17 steve.zhan
0 siblings, 0 replies; 732+ messages in thread
From: steve.zhan @ 2012-12-29 9:17 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
It is good idea add this feature.
1: Can we let the "ret = hwspin_lock_tests(ops, hwlock);" add after
hwspin_lock_register_single have return
succeed, that can avoid test duplicated Or error lockid. Of course, If
this interface is intend to test soc hardware capability only, we can
put it in the arch module not this core framework. For driver hardware
sanity check, i would add it after software have register it.
2:Is it possible that interface add configs that choose which locks
will be test? Because the hwspinlock module is init late in
postcore_initcall phase, Maybe MACH/ARCH code(for example: code in
early_initcall) need use private other interfaces to lock some
hwspinlocks and then register hw locks to hwspinlock framework, Maybe
some hw locks is in lock status but which test failed.
--
Steve Zhan
> From: Ido Yariv <ido@wizery.com>
> To: Ohad Ben-Cohen <ohad@wizery.com>, linux-kernel at vger.kernel.org,
> linux-arm-kernel at lists.infradead.org, linux-omap at vger.kernel.org
> Cc: Ido Yariv <ido@wizery.com>
> Subject: [PATCH] hwspinlock/core: Add testing capabilities
> Message-ID: <1355344026-17222-1-git-send-email-ido@wizery.com>
>
> Add testing capabilities for verifying correctness of the underlying
> hwspinlock layers. This can be handy especially during development.
> These tests are performed only once as part of the hwspinlock
> registration.
>
> Signed-off-by: Ido Yariv <ido@wizery.com>
> ---
> drivers/hwspinlock/Kconfig | 9 +++++
> drivers/hwspinlock/hwspinlock_core.c | 54
> ++++++++++++++++++++++++++++++++++
> 2 files changed, 63 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/hwspinlock/Kconfig b/drivers/hwspinlock/Kconfig
> index c7c3128..ad632cd 100644
> --- a/drivers/hwspinlock/Kconfig
> +++ b/drivers/hwspinlock/Kconfig
> @@ -8,6 +8,15 @@ config HWSPINLOCK
>
> menu "Hardware Spinlock drivers"
>
> +config HWSPINLOCK_TEST
> + bool "Verify underlying hwspinlock implementation"
> + depends on HWSPINLOCK
> + help
> + Say Y here to perform tests on the underlying hwspinlock
> + implementation. The tests are only performed once per implementation.
> +
> + Say N, unless you absolutely know what you are doing.
> +
> config HWSPINLOCK_OMAP
> tristate "OMAP Hardware Spinlock device"
> depends on ARCH_OMAP4
> diff --git a/drivers/hwspinlock/hwspinlock_core.c
> b/drivers/hwspinlock/hwspinlock_core.c
> index 085e28e..1874e85 100644
> --- a/drivers/hwspinlock/hwspinlock_core.c
> +++ b/drivers/hwspinlock/hwspinlock_core.c
> @@ -307,6 +307,53 @@ out:
> return hwlock;
> }
>
> +#ifdef CONFIG_HWSPINLOCK_TEST
> +#define NUM_OF_TEST_ITERATIONS 100
> +static int hwspin_lock_tests(const struct hwspinlock_ops *ops,
> + struct hwspinlock *hwlock)
> +{
> + int i;
> + int ret;
> +
> + for (i = 0; i < NUM_OF_TEST_ITERATIONS; i++) {
> + ret = ops->trylock(hwlock);
> + if (!ret) {
> + pr_err("%s: Initial lock failed\n", __func__);
> + return -EFAULT;
> + }
> +
> + /* Verify lock actually works - re-acquiring it should fail */
> + ret = ops->trylock(hwlock);
> + if (ret) {
> + /* Keep locks balanced even in failure cases */
> + ops->unlock(hwlock);
> + ops->unlock(hwlock);
> + pr_err("%s: Recursive lock succeeded unexpectedly\n",
> + __func__);
> + return -EFAULT;
> + }
> +
> + /* Verify unlock by re-acquiring the lock after releasing it */
> + ops->unlock(hwlock);
> + ret = ops->trylock(hwlock);
> + if (!ret) {
> + pr_err("%s: Unlock failed\n", __func__);
> + return -EINVAL;
> + }
> +
> + ops->unlock(hwlock);
> + }
> +
> + return 0;
> +}
> +#else /* CONFIG_HWSPINLOCK_TEST*/
> +static int hwspin_lock_tests(const struct hwspinlock_ops *ops,
> + struct hwspinlock *hwlock)
> +{
> + return 0;
> +}
> +#endif
> +
> /**
> * hwspin_lock_register() - register a new hw spinlock device
> * @bank: the hwspinlock device, which usually provides numerous hw locks
> @@ -345,6 +392,13 @@ int hwspin_lock_register(struct hwspinlock_device
> *bank, struct device *dev,
> spin_lock_init(&hwlock->lock);
> hwlock->bank = bank;
>
> + ret = hwspin_lock_tests(ops, hwlock);
> + if (ret) {
> + pr_err("hwspinlock tests failed on lock %d\n",
> + base_id + i);
> + goto reg_failed;
> + }
> +
> ret = hwspin_lock_register_single(hwlock, base_id + i);
> if (ret)
> goto reg_failed;
> --
> 1.7.7.6
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-12-05 13:48 Niroj Pokhrel
0 siblings, 0 replies; 732+ messages in thread
From: Niroj Pokhrel @ 2012-12-05 13:48 UTC (permalink / raw)
To: kernelnewbies
Hi,
I'm trying to work on android audio (pcm_native.c) but got stuck in some
parameters like start threshold, stop threshold, silence zone, silence
threshold. Can anybody please elaborate on what they are each used for ??
--
Niroj Pokhrel
Software Engineer,
Samsung India Software Operations
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20121205/9b5d1739/attachment.html
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-11-19 11:41 唐忠诚
0 siblings, 0 replies; 732+ messages in thread
From: 唐忠诚 @ 2012-11-19 11:41 UTC (permalink / raw)
To: kernelnewbies
thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20121119/5b84e70c/attachment.html
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-11-11 14:16 Sammy Chan
0 siblings, 0 replies; 732+ messages in thread
From: Sammy Chan @ 2012-11-11 14:16 UTC (permalink / raw)
To: linux-arm-kernel
http://ncompass1.altervista.org/wp-content/plugins/zgstplauaao/ugoogle.html
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-11-08 9:33 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2012-11-08 9:33 UTC (permalink / raw)
To: ath9k-devel
timestamp (first frame?).
Thomas
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-11-08 8:07 Abhimanyu Kapur
0 siblings, 0 replies; 732+ messages in thread
From: Abhimanyu Kapur @ 2012-11-08 8:07 UTC (permalink / raw)
To: linux-arm-kernel
subscribe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121108/ea49c32b/attachment-0001.html>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-11-02 10:46 Pritam Bankar
0 siblings, 0 replies; 732+ messages in thread
From: Pritam Bankar @ 2012-11-02 10:46 UTC (permalink / raw)
To: kernelnewbies
Hi,
I know very well that memory on 32-bit Linux system is normally split
in following way
First 3GB = user space (High memory)
Last 1GB = kernel space (Low memory)
But I have some questions,
1. How is memory split up on 64-bit architecture
2. Can we override this 3:1 split ?
3. If yes, who can do that user or kernel?
Thanks,
Pritam Bankar
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-10-15 9:24 Niroj Pokhrel
0 siblings, 0 replies; 732+ messages in thread
From: Niroj Pokhrel @ 2012-10-15 9:24 UTC (permalink / raw)
To: kernelnewbies
Hi,
I'm new to linux and kernel . I'm ongoing with the linux device drivers.
I've followed the the book LDD but i'm lost about how to call my driver's
specific method from the user space.
Eg: if have developed a character device and inserted the module then how
can i make sure that when I read or write that it implement the functions
via the methods i have implemented in my module.
--
Niroj Pokhrel
NIT Jamshedpur,
B.Tech,Electronics and Communication
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20121015/5d90dec4/attachment.html
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-10-14 10:05 Alexey Dobriyan
0 siblings, 0 replies; 732+ messages in thread
From: Alexey Dobriyan @ 2012-10-14 10:05 UTC (permalink / raw)
To: linux-arm-kernel
http://www.hzsonic.com/en/wp-content/themes/twentyten/career.html
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-10-11 5:38 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2012-10-11 5:38 UTC (permalink / raw)
To: u-boot
vvvvvvvvvvvvvvvvv
SCSI: AHCI 0001.0300 32 slots 6 ports ? Gbps 0xf impl SATA mode
flags: 64bit ilck stag led pmp pio
...
Magic signature found
Kernel command line: "cros_secure quiet loglevel=1 console=tty2...
^^^^^^^^^^^^^^^^^
Note that the entire u-boot output fits into the buffer only if
the coreboot log level is reduced from the most verbose. Ether
the buffer size will have to be increased, or the coreboot
verbosity permanently reduced.
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
---
common/stdio.c | 4 ++-
drivers/misc/Makefile | 1 +
drivers/misc/cbmem_console.c | 67 ++++++++++++++++++++++++++++++++++++++++++
include/stdio_dev.h | 3 ++
4 files changed, 74 insertions(+), 1 deletions(-)
create mode 100644 drivers/misc/cbmem_console.c
diff --git a/common/stdio.c b/common/stdio.c
index 605ff3f..9f48e5f 100644
--- a/common/stdio.c
+++ b/common/stdio.c
@@ -237,6 +237,8 @@ int stdio_init (void)
#ifdef CONFIG_JTAG_CONSOLE
drv_jtag_console_init ();
#endif
-
+#ifdef CONFIG_CBMEM_CONSOLE
+ cbmemc_init();
+#endif
return (0);
}
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 271463c..a77db3d 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -27,6 +27,7 @@ LIB := $(obj)libmisc.o
COBJS-$(CONFIG_ALI152X) += ali512x.o
COBJS-$(CONFIG_DS4510) += ds4510.o
+COBJS-$(CONFIG_CBMEM_CONSOLE) += cbmem_console.o
COBJS-$(CONFIG_FSL_LAW) += fsl_law.o
COBJS-$(CONFIG_GPIO_LED) += gpio_led.o
COBJS-$(CONFIG_FSL_MC9SDZ60) += mc9sdz60.o
diff --git a/drivers/misc/cbmem_console.c b/drivers/misc/cbmem_console.c
new file mode 100644
index 0000000..80a84fd
--- /dev/null
+++ b/drivers/misc/cbmem_console.c
@@ -0,0 +1,67 @@
+/*
+ * Copyright (C) 2011 The ChromiumOS Authors. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA, 02110-1301 USA
+ */
+
+#include <common.h>
+
+#ifndef CONFIG_SYS_COREBOOT
+#error This driver requires coreboot
+#endif
+
+#include <asm/arch/sysinfo.h>
+
+struct cbmem_console {
+ u32 buffer_size;
+ u32 buffer_cursor;
+ u8 buffer_body[0];
+} __attribute__ ((__packed__));
+
+static struct cbmem_console *cbmem_console_p;
+
+void cbmemc_putc(char data)
+{
+ int cursor;
+
+ cursor = cbmem_console_p->buffer_cursor++;
+ if (cursor < cbmem_console_p->buffer_size)
+ cbmem_console_p->buffer_body[cursor] = data;
+}
+
+void cbmemc_puts(const char *str)
+{
+ char c;
+
+ while ((c = *str++) != 0)
+ cbmemc_putc(c);
+}
+
+int cbmemc_init(void)
+{
+ int rc;
+ struct stdio_dev cons_dev;
+ cbmem_console_p = lib_sysinfo.cbmem_cons;
+
+ memset(&cons_dev, 0, sizeof(cons_dev));
+
+ strcpy(cons_dev.name, "cbmem");
+ cons_dev.flags = DEV_FLAGS_OUTPUT; /* Output only */
+ cons_dev.putc = cbmemc_putc;
+ cons_dev.puts = cbmemc_puts;
+
+ rc = stdio_register(&cons_dev);
+
+ return (rc == 0) ? 1 : rc;
+}
diff --git a/include/stdio_dev.h b/include/stdio_dev.h
index 23e0ee1..932d093 100644
--- a/include/stdio_dev.h
+++ b/include/stdio_dev.h
@@ -120,5 +120,8 @@ int drv_nc_init (void);
#ifdef CONFIG_JTAG_CONSOLE
int drv_jtag_console_init (void);
#endif
+#ifdef CONFIG_CBMEM_CONSOLE
+int cbmemc_init(void);
+#endif
#endif
--
1.7.7.3
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2012-10-11 5:38 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2012-10-11 5:38 UTC (permalink / raw)
To: u-boot
adaptations to include/libfdt.h and lib/libfdt/Makefile for the U-Boot
environment.
Signed-off-by: Gerald Van Baren <vanbaren@cideas.com>
---
This comes from the upstream libfdt (dtc) git repository, added
to stay in sync.
include/libfdt.h | 1 +
lib/libfdt/Makefile | 2 +-
lib/libfdt/fdt_empty_tree.c | 84 +++++++++++++++++++++++++++++++++++++++++++
3 files changed, 86 insertions(+), 1 deletion(-)
create mode 100644 lib/libfdt/fdt_empty_tree.c
diff --git a/include/libfdt.h b/include/libfdt.h
index 4589c5f..c93ae28 100644
--- a/include/libfdt.h
+++ b/include/libfdt.h
@@ -1014,6 +1014,7 @@ int fdt_finish(void *fdt);
/* Read-write functions */
/**********************************************************************/
+int fdt_create_empty_tree(void *buf, int bufsize);
int fdt_open_into(const void *fdt, void *buf, int bufsize);
int fdt_pack(void *fdt);
diff --git a/lib/libfdt/Makefile b/lib/libfdt/Makefile
index c965577..0693d4b 100644
--- a/lib/libfdt/Makefile
+++ b/lib/libfdt/Makefile
@@ -27,7 +27,7 @@ LIB = $(obj)libfdt.o
SOBJS =
-COBJS-libfdt += fdt.o fdt_ro.o fdt_rw.o fdt_strerror.o fdt_sw.o fdt_wip.o
+COBJS-libfdt += fdt.o fdt_ro.o fdt_rw.o fdt_strerror.o fdt_sw.o
fdt_wip.o fdt_empty_tree.o
COBJS-$(CONFIG_OF_LIBFDT) += $(COBJS-libfdt)
COBJS-$(CONFIG_FIT) += $(COBJS-libfdt)
diff --git a/lib/libfdt/fdt_empty_tree.c b/lib/libfdt/fdt_empty_tree.c
new file mode 100644
index 0000000..f72d13b
--- /dev/null
+++ b/lib/libfdt/fdt_empty_tree.c
@@ -0,0 +1,84 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2012 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ * a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this library; if not, write to the Free
+ * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ * b) Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * 1. Redistributions of source code must retain the above
+ * copyright notice, this list of conditions and the following
+ * disclaimer.
+ * 2. Redistributions in binary form must reproduce the above
+ * copyright notice, this list of conditions and the following
+ * disclaimer in the documentation and/or other materials
+ * provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ * CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include "libfdt_env.h"
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "libfdt_internal.h"
+
+int fdt_create_empty_tree(void *buf, int bufsize)
+{
+ int err;
+
+ err = fdt_create(buf, bufsize);
+ if (err)
+ return err;
+
+ err = fdt_finish_reservemap(buf);
+ if (err)
+ return err;
+
+ err = fdt_begin_node(buf, "");
+ if (err)
+ return err;
+
+ err = fdt_end_node(buf);
+ if (err)
+ return err;
+
+ err = fdt_finish(buf);
+ if (err)
+ return err;
+
+ return fdt_open_into(buf, buf, bufsize);
+}
+
-- 1.7.9.5
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2012-10-11 5:38 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2012-10-11 5:38 UTC (permalink / raw)
To: u-boot
#ifdef CONFIG_LCD
/* reserve memory for LCD display (always full pages) */
addr = lcd_setmem (addr);
gd->fb_base = addr;
#endif /* CONFIG_LCD */
This makes difficult to reserve the correct amount of memory because at
this point we cannot evaluate the environment. With CONFIG_VIDEO, memory
is allocated with malloc(), and in any case after relocation.
Best regards,
Stefano
>
> Thanks,
>
> Fabio Estevam
>
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-10-11 5:38 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2012-10-11 5:38 UTC (permalink / raw)
To: u-boot
SD-Card however this is not truth. Please rework this so it is clear what
is already working and what needs to be done.
--
Otavio Salvador O.S. Systems
E-mail: otavio at ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
--f46d042de5793c1ab404ced662d8--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-10-11 5:38 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2012-10-11 5:38 UTC (permalink / raw)
To: u-boot
t configures the DRAM controller, and a few other necessary things, copies =
itself into DRAM, then transfers execution to the copy that resides in DRAM=
to continue the next step in U-Boot execution.
I have tried to copy the part in DRAM from the working device to the non wo=
rking device, but I might not have something configured correctly. If I kn=
ew what I was looking for, it must be contained in the initial few bytes in=
the U-Boot loader, the DRAM configuration, etc. Technically I think I sho=
uld be able to execute this directly in DRAM if I know what to copy over.
> >
> > I have attempted to halt the running board in the bootup, copy the ram
> contents from one board to the other, and resume the processor, but it se=
ems
> I am missing something.
>=20
> maybe there are cache coherency problems or the memory controller is
> not initialized correctly
I think this might be the case, but it executes one loader correctly (I thi=
nk) because it turns on the DIAG LED on the device when loaded into DRAM an=
d executed. But, that does not mean it is not getting stuck somewhere afte=
r the LED turns on...
I guess I need a deeper understanding of what is going on during the boot p=
rocess...
Generally I think the following happens, but I might be missing something, =
or over simplified something...
1. Processor starts up and looks to a predetermined address for initial ins=
tructions
2. The initial U-Boot bootstrap is loaded
3. This initializes some things such as the UART (for debug), DRAM controll=
er, etc
4. U-Boot is copied to DRAM then executed from there
5. The main U-Boot is executed and initializes the remaining devices
6. Control is (usually) then transferred to a Linux kernel which is loaded =
into DRAM by U-Boot then executed
I am going to attempt to get my toolchain working for building U-Boot, mayb=
e I just need to build a clean image, however, I can't find support for the=
AR7161 in the mainline, so I might have to piece together parts from vario=
us sources to get a complete working build.
In reality though, I would rather just use the existing working U-Boot on t=
he working device to start up the non-working device to be able to rewrite =
the bootloader, however, I might need to compile a new U-Boot to get this f=
ar.
I have done work with ARM based (SheevaPlug, GuruPlug, DreamPlug) devices b=
efore, and they were easier to work with than this MIPS based device, for o=
ne I could access the flash directly through JTAG (with exception of the Dr=
eamPlug).
I can provide a copy of the working devices boot loader if this helps to fi=
gure out load addresses and such, I am not sure how the file is build, so l=
ooking at the instructions might not make much sense to me. I am assuming =
it is not compressed in any way since the processor has no way to decompres=
s it until after loading it.
>=20
> > I am going to paste below the contents of the openocd file that I am us=
ing,
> along with the initial startup of the working board. I can also provide
> any other details that are helpful.
> >
> > If I can build a working RAM startup image, that would be great, I can
> then use that to rewrite the onboard flash memory, or if I can directly
> access the flash memory through the JTAG, but so far, I have not been
> successful with that either.
> >
> > I believe I have a working toolchain to build U-Boot, but keep running
> into odd errors when building possibly due to different toolchain version=
s.
> > Any help or assistance would be greatly appreciated.
> >
> > Thanks,
> > Allan Drassal
> >
> > ar71xx.cfg
> >
> > # Atheros AR71xx MIPS 24Kc SoC.
> > # tested on PB44 refererence board
> >
> > adapter_nsrst_delay 100
> > jtag_ntrst_delay 100
> >
> > reset_config trst_and_srst
> >
> > set CHIPNAME ar71xx
> >
> > jtag newtap $CHIPNAME cpu -irlen 5 -ircapture 0x1 -irmask 0x1f
> -expected-id 1
> >
> > set TARGETNAME $CHIPNAME.cpu
> > target create $TARGETNAME mips_m4k -endian big -chain-position
> $TARGETNAME
> >
> > $TARGETNAME configure -event reset-halt-post {
> > #setup PLL to lowest common denominator 300/300/150 setting
> > #mww 0xb8050000 0x000f40a3 ;# reset val + CPU:3 DDR:3 AHB:=
0
> > #mww 0xb8050000 0x800f40a3 ;# send to PLL
> > mww 0xb8050000 0x40140180 ;# reset val + CPU:3 DDR:3 AHB:=
0
> > mww 0xb8050000 0xc0140180 ;# send to PLL
> >
> > #next command will reset for PLL changes to take effect
> > mww 0xb8050008 3 ;# set reset_switch and
> clock_switch (resets SoC)
> > }
> >
> > $TARGETNAME configure -event reset-init {
> > #complete pll initialization
> > mww 0xb8050000 0x800f0080 ;# set sw_update bit
> > mww 0xb8050008 0 ;# clear reset_switch bit
> > mww 0xb8050000 0x800f00e8 ;# clr pwrdwn & bypass
> > mww 0xb8050008 1 ;# set clock_switch bit
> > sleep 1 ;# wait for lock
> >
> > # Setup DDR config and flash mapping
> > mww 0xb8000000 0x77b8884e ;# DDR cfg cdl val (rst:
> 0x5bfc8d0)
> > mww 0xb8000004 0x812cd6a8 ;# DDR cfg2 cdl val (rst:
> 0x80d106a8)
> > #mww 0xb8000000 0xefbc8cd0 ;# DDR cfg cdl val (rst:
> 0x5bfc8d0)
> > #mww 0xb8000004 0x8e7156a2 ;# DDR cfg2 cdl val (rst:
> 0x80d106a8)
> >
> > mww 0xb8000010 8 ;# force precharge all banks
> > mww 0xb8000010 1 ;# force EMRS update cycle
> > mww 0xb800000c 0 ;# clr ext. mode register
> > mww 0xb8000010 2 ;# force auto refresh all banks
> > mww 0xb8000010 8 ;# force precharge all banks
> > #mww 0xb8000008 0x31 ;# set DDR mode value CAS=3D3
> > mww 0xb8000008 0x33 ;# set DDR mode value CAS=3D3
> > mww 0xb8000010 1 ;# force EMRS update cycle
> > #mww 0xb8000014 0x461b ;# DDR refresh value
> > #mww 0xb8000018 0xffff ;# DDR Read Data This Cycle
> value (16bit: 0xffff)
> > mww 0xb8000014 0x44a6 ;# DDR refresh value
> > mww 0xb8000018 0x00ff ;# DDR Read Data This Cycle val=
ue
> (16bit: 0xffff)
> > mww 0xb800001c 0x7 ;# delay added to the DQS line
> (normal =3D 7)
> > mww 0xb8000020 7
> > mww 0xb8000024 7
> > mww 0xb8000028 7
> > }
>=20
> are there no registers for enabling/disabling the memory controller?
> Usually you need to disable
> a memory controller when changing its configuration and to enable it
> to start the
> initialization sequence for the DRAM device.
>=20
> >
> > # setup working area somewhere in RAM
> > $TARGETNAME configure -work-area-phys 0xa0600000 -work-area-size
> 0x20000
> >
> > # serial SPI capable flash
> > # flash bank <driver> <base> <size> <chip_width> <bus_width>
> >
> >
> >
> >
> > commands used in openocd through a telnet connection to 127.0.0.1 4444:
> > reset
> > halt
> > reset
> > mww 0xb8060008 3
> > mww 0xb806000c 0x12c
> > halt
> > mww 0xb8050000 0x00090828
> > mww 0xb8050000 0x00050828
> > mww 0xb8050000 0x00040828
> > mww 0xb8050008 2
> > mww 0xb8050008 3
> > halt
> > reset init
> > load_image 8Muboot_RAM_version.bin 0x80000000
> > resume 0x80000000
> >
>=20
> are you sure that 0x80000000 is the real text base address? The
> mainline U-Boot code
> uses 0x80000000 + CONFIG_SYS_INIT_SP_OFFSET as initial stack area
> before relocation.
>=20
>=20
> --
> Best regards,
> Daniel
Thanks,
Allan=
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-10-11 5:38 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2012-10-11 5:38 UTC (permalink / raw)
To: u-boot
architecture.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
common/main.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/common/main.c b/common/main.c
index 8052d42..4734820 100644
--- a/common/main.c
+++ b/common/main.c
@@ -53,7 +53,8 @@
#include <linux/ctype.h>
#include <menu.h>
-#if defined(CONFIG_SILENT_CONSOLE) || defined(CONFIG_POST) || defined(CONFIG_CMDLINE_EDITING)
+#if defined(CONFIG_SILENT_CONSOLE) || defined(CONFIG_POST) || \
+ defined(CONFIG_CMDLINE_EDITING) || defined(CONFIG_OF_CONTROL)
DECLARE_GLOBAL_DATA_PTR;
#endif
--
1.7.7.3
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2012-10-11 5:38 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2012-10-11 5:38 UTC (permalink / raw)
To: u-boot
simply be run of the mill global variables. I think most of what is
under gd->arch may just 'fall out'
Regards,
Graeme
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-10-11 5:38 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2012-10-11 5:38 UTC (permalink / raw)
To: u-boot
is not a "real" *driver*. Thats my main reasoning why its a bit
misplaced in "drivers/*".
But I have no strong feelings here. Perhaps others have
thought/ideas/comments as well. Let's wait for further input a bit...
Thanks,
Stefan
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-10-11 5:38 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2012-10-11 5:38 UTC (permalink / raw)
To: u-boot
configure the PLL speed at run time, because we we using both speeds.
Since T30 now apparently only uses 408MHz, it should be ok to set it
once and hard-code it.
Regards,
Simon
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-10-11 5:38 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2012-10-11 5:38 UTC (permalink / raw)
To: u-boot
function for mmc" commit codes are removed.
It seems to be removed by manual merge with "exynos:pinmux: Add pinmux
support for i2c" commit.
Thanks.
>
> Allen Martin (2):
> tegra: add CONSOLE_MUX support to tegra-kbc
> Merge remote-tracking branch 'u-boot/master' into
> u-boot-arm-merged
>
> Ashok Kumar Reddy (1):
> ARM: arm1176: Define arch_cpu_init() for s3c64xx
>
> Beno=C3=AEt Th=C3=A9baudeau (17):
> arm1136: Fix enable_caches()
> mx31: Move EHCI definitions to ehci-fsl.h
> ehci-mxc: Clean up
> ehci-mx5: Clean up
> ehci-mx5: Fix OC_DIS usage
> ehci-mx5: Fix OPM usage
> ehci-mx5: Fix *PM usage for i.MX53
> ehci-mx5: Add missing OC_DIS for i.MX53
> ehci-mxc: Make EHCI power/oc polarities configurable
> ehci-mxc: Make i.MX25 EHCI configurable
> ehci-mxc: Define host offsets
> ehci-mxc: Add support for i.MX35
> mx35pdk: Add support for OTG
> ehci-mx5/6: Make board_ehci_hcd_init() optional
> ehci-mxc: Fix host power mask bit for i.MX35
> ehci-mxc: Fix host power mask bit for i.MX25
> mx5: Mark lowlevel_init board-specific code
>
> Chander Kashyap (1):
> Exynos5250: Enable PXE Support
>
> Fabio Estevam (28):
> mx25pdk: Include CONFIG_MX25
> mx25pdk: Add esdhc support
> pmic_fsl: Introduce FSL_PMIC_I2C_LENGTH
> mx25: Place common functions into sys_proto.h
> pmic: Add support for mc34704
> mx25pdk: Add Ethernet support
> mx53loco: Allow booting a zImage kernel
> mx25pdk: Allow booting a zImage kernel
> mx51evk: Allow booting a zImage kernel
> mx35pdk: Allow booting a zImage kernel
> mx6qsabre_common: Allow booting a zImage kernel
> mx5: Align SPI CS naming with i.MX53 reference manual
> mx5: Print CSPI clock in 'clock' command
> spi: mxc_spi: Fix handling of chip select
> spi: mxc_spi: Fix spi clock glitch durant reset
> mx6: clock: Only show CSPI clock if CSPI is enabled
> mx28evk: Configure CONFIG_BOOTDELAY to one second
> mx53loco: Configure CONFIG_BOOTDELAY to one second
> mx6qsabrelite: Configure CONFIG_BOOTDELAY to one second
> mx6qsabre_common: Configure CONFIG_BOOTDELAY to one second
> mx51evk: Configure CONFIG_BOOTDELAY to one second
> mx25pdk: Configure CONFIG_BOOTDELAY to one second
> mx31pdk: Configure CONFIG_BOOTDELAY to one second
> mx35pdk: Configure CONFIG_BOOTDELAY to one second
> mx25pdk: Adapt it for the new PMIC framework
> woodburn: Set gpio value in gpio_direction_output()
> mx53loco: Fix PMIC name
> mx25pdk: Allow booting a device tree kernel
>
> Hatim RV (3):
> EXYNOS: Add clock for SPI
> EXYNOS5: Add base address for SPI
> EXYNOS5: Enable SPI
>
> Marek Vasut (9):
> dm: wdt: Move s5p watchdog timer to drivers/watchdog/
> mx28: Fix typo in POWER_MINPWR_VBG_OFF
> mx28: Fix typo in POWER_DCLIMITS_NEGLIMIT_OFFSET
> mx28: Remove SET, CLR, TOG ops from PLLxCTRL1 registers
> mx28: Rename regs-power.h to regs-power-mx28.h
> mxs: Silence elftosb
> mxs: Implement common function to setup VDDx
> mxs: Properly setup VDDD in power supply setup code
> mxs: Staticize SPL functions
>
> Mayuresh Kulkarni (1):
> tegra: Enable display/lcd support on Seaboard
>
> Minkyu Kang (6):
> ARCH: EXYNOS: add support to match product id
> EXYNOS: Clock: Add common function for pll rate calculation
> s3c64xx: fix the compiler error and warning
> Merge branch 'master' of git://git.denx.de/u-boot into resolve
> universal_c210: fix compiler error and compiler warning
> universal_c210: check the NULL pointer when get the PMIC
>
> Otavio Salvador (1):
> mxs: SPL: Generalize memory initialization
>
> Piotr Wilczek (12):
> arm:exynos4:trats: Correct SDRAM configuration for trats
> arm:exynos4:trats: Fix SDRAM size
> arm:exynos4:pinmux: Modify the gpio function for mmc
> arm:exynos4:trats: Use pinmux for mmc configuration
> arm:exynos4:universal: Use pinmux for mmc configuration
> arm:exynos4:universal: Eliminated low level init
> arm: trats: Power down core 1
> exynos4: universal_C210: use software SPI
> misc:max8998 Add LDO macros
> drivers: video: Add ld9040 video driver
> drivers: video: fix image position
> exynos4: universal_C210: add display support
>
> Rajeshwari Shinde (16):
> PMIC: MAX77686: Add support for MAX77686
> SMDK5250: Config: Enable MAX77686 pmic chip
> SOUND: SAMSUNG: Add I2S driver
> SOUND: Add WM8994 codec
> Sound: Add command for audio playback
> EXYNOS: Add I2S registers
> EXYNOS: Add parameters required by I2S
> EXYNOS: Add pinmux for I2S
> EXYNOS: Add I2S base address
> EXYNOS: Add clock for I2S
> SMDK5250: Enable Sound
> EXYNOS5: Add pinmux support for SPI
> SPI: Add SPI Driver for EXYNOS.
> EXYNOS5: Enable SPI booting.
> POWER: MAX77686: Modified as per the latest Implementation
> SMDK5250: Enable pmic MAX77686
>
> Simon Glass (17):
> pxa: Disable dcache on palmld, palmtc, zipitz2
> tegra: Use const for pinmux_config_pingroup/table()
> tegra: Add display support to funcmux
> tegra: fdt: Add pwm binding and node
> tegra: fdt: Add LCD definitions for Tegra
> tegra: Add support for PWM
> tegra: Add LCD driver
> tegra: Add LCD support to Nvidia boards
> arm: Add control over cachability of memory regions
> lcd: Add CONFIG_LCD_ALIGNMENT to select frame buffer alignment
> lcd: Add support for flushing LCD fb from dcache after update
> tegra: Align LCD frame buffer to section boundary
> tegra: Support control of cache settings for LCD
> tegra: fdt: Add LCD definitions for Seaboard
> lcd: Add CONFIG_CONSOLE_SCROLL_LINES option to speed console
> tegra: Remove unnecessary CONFIG_SYS_NAND_BASE
> tegra: config: seaboard: Move tegra-common-post to correct place
>
> Stefano Babic (9):
> ARM: Fix start.S when used with SPL in arm1136
> MX35: add LOW_LEVEL_SRAM_STACK to use SPL_FRAMEWORK
> MX35: Add soc_boot_mode and soc_boot_device to MX35
> SPL: Added SPL target for mx35 SOC to SPL Makefile
> ARM: Add SPL target to arm1136
> MX35: add support for woodburn board
> MX5: added CONFIG_PMIC_FSL_MC13892 to mx53evk
> Merge git://git.denx.de/u-boot
> Merge branch 'master' of git://git.denx.de/u-boot into master
>
> Stephen Warren (4):
> ARM: tegra: TrimSlice: add support for USB1 port
> mmc: tegra: support 4-bit operation too on 8-bit slots
> ARM: tegra: enable 8-bit SD slots in board files
> tegra: use generic fs commands in BOOTCOMMAND
>
> Troy Kisky (4):
> mx6: soc: update get_cpu_rev and get_imx_type for mx6solo/sololite
> mx6: use CONFIG_MX6 instead of CONFIG_MX6Q
> imx-common: cpu: add imx_ddr_size
> arch-mx6: add mx6dl_pins.h
>
> Wei Ni (1):
> tegra: Add SOC support for display/lcd
>
> =C5=81ukasz Majewski (1):
> gpio:fix: Proper handling of GPIO subsystem parts at Samsung
> devices
>
> MAINTAINERS |
> 1 + Makefile
> | 4 +-
> README |
> 16 ++-
> arch/arm/cpu/arm1136/config.mk |
> 3 + arch/arm/cpu/arm1136/cpu.c
> | 22 ++--
> arch/arm/cpu/arm1136/mx35/Makefile |
> 1 + arch/arm/cpu/arm1136/mx35/generic.c
> | 75 +++++++++++
> arch/arm/cpu/arm1136/mx35/mx35_sdram.c |
> 137 ++++++++++++++++++++
> arch/arm/cpu/arm1136/start.S |
> 31 +++--
> arch/arm/cpu/arm1136/u-boot-spl.lds |
> 62 +++++++++
> arch/arm/cpu/arm1176/s3c64xx/Makefile |
> 2 +- arch/arm/cpu/arm1176/s3c64xx/init.c
> | 26 ++++
> arch/arm/cpu/arm926ejs/mxs/spl_boot.c |
> 4 +- arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
> | 38 +++---
> arch/arm/cpu/arm926ejs/mxs/spl_power_init.c |
> 305 ++++++++++++++++----------------------------
> arch/arm/cpu/armv7/cache_v7.c |
> 11 ++
> arch/arm/cpu/armv7/exynos/clock.c |
> 350 +++++++++++++++++++++++++++++++++++++++++----------
> arch/arm/cpu/armv7/exynos/pinmux.c |
> 64 ++++++++++
> arch/arm/cpu/armv7/mx5/clock.c |
> 4 +- arch/arm/cpu/armv7/mx5/lowlevel_init.S
> | 2 +-
> arch/arm/cpu/armv7/mx6/clock.c |
> 2 + arch/arm/cpu/armv7/mx6/soc.c
> | 32 +++--
> arch/arm/cpu/armv7/s5p-common/Makefile |
> 1 - arch/arm/cpu/armv7/tegra20/Makefile
> | 2 +
> arch/arm/cpu/armv7/tegra20/display.c |
> 409 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> arch/arm/cpu/armv7/tegra20/pwm.c |
> 101 +++++++++++++++
> arch/arm/cpu/tegra20-common/funcmux.c |
> 37 ++++++
> arch/arm/cpu/tegra20-common/pinmux.c |
> 4 +- arch/arm/dts/tegra20.dtsi
> | 105 ++++++++++++++++
> arch/arm/imx-common/cpu.c |
> 66 ++++++++--
> arch/arm/include/asm/arch-exynos/clk.h |
> 4 + arch/arm/include/asm/arch-exynos/clock.h
> | 29 +++++
> arch/arm/include/asm/arch-exynos/cpu.h |
> 18 +++
> arch/arm/include/asm/arch-exynos/gpio.h |
> 19 +++
> arch/arm/include/asm/arch-exynos/i2s-regs.h |
> 66 ++++++++++
> arch/arm/include/asm/arch-exynos/periph.h |
> 7 ++ arch/arm/include/asm/arch-exynos/sound.h
> | 44 +++++++
> arch/arm/include/asm/arch-exynos/spi.h |
> 78 ++++++++++++
> arch/arm/include/asm/arch-mx25/imx-regs.h |
> 5 +- arch/arm/include/asm/arch-mx25/sys_proto.h
> | 3 +
> arch/arm/include/asm/arch-mx31/imx-regs.h |
> 27 +---
> arch/arm/include/asm/arch-mx35/imx-regs.h |
> 4 + arch/arm/include/asm/arch-mx35/mmc_host_def.h
> | 31 +++++
> arch/arm/include/asm/arch-mx35/spl.h |
> 38 ++++++
> arch/arm/include/asm/arch-mx35/sys_proto.h |
> 2 + arch/arm/include/asm/arch-mx5/mx5x_pins.h
> | 6 +-
> arch/arm/include/asm/arch-mx5/sys_proto.h |
> 10 +-
> arch/arm/include/asm/arch-mx6/imx-regs.h |
> 2 + arch/arm/include/asm/arch-mx6/mx6dl_pins.h
> | 149 ++++++++++++++++++++++
> arch/arm/include/asm/arch-mx6/sys_proto.h |
> 10 +-
> arch/arm/include/asm/arch-mxs/imx-regs.h |
> 7 +- arch/arm/include/asm/arch-mxs/regs-clkctrl-mx28.h
> | 6 +- arch/arm/include/asm/arch-mxs/{regs-power.h =3D>
> regs-power-mx28.h} | 4 +-
> arch/arm/include/asm/arch-s5pc1xx/gpio.h |
> 7 +- arch/arm/include/asm/arch-tegra20/dc.h
> | 545
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++=
+++++++
> arch/arm/include/asm/arch-tegra20/display.h |
> 152 ++++++++++++++++++++++
> arch/arm/include/asm/arch-tegra20/pinmux.h |
> 4 +- arch/arm/include/asm/arch-tegra20/pwm.h
> | 75 +++++++++++
> arch/arm/include/asm/system.h |
> 31 +++++
> arch/arm/lib/cache-cp15.c --
> Albert.
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de <javascript:;>
> http://lists.denx.de/mailman/listinfo/u-boot
>
--=20
- Joonyoung Shim
--485b397dd6ff5a241204d25ca841--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-10-11 5:38 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2012-10-11 5:38 UTC (permalink / raw)
To: u-boot
consecutive MMC operations (i.e. many reads), and the 10ms timeout
might be too short when eMMC firmware is forced to do some internal
time consuming operations (e.g. flash blocks management, wear
leveling).
In this situation, the SDHCI_CMD_INHIBIT bit is set, which means that
SDHCI controller didn't received response from eMMC.
One proposition would be to define the per device/per memory chip
specific timeouts, to replace those defined at ./drivers/mmc/sdhci.c
file.
I also assume, that timeouts cannot be removed, since we must detect
if user pulls out a SD card or transmission has been broken.
I'm also wondering if we can tune the sdhci code to improve cooperation
with eMMC devices (despite of the fact that this is NOT really needed at
u-boot :-) ).
Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Cc: Andy Fleming <afleming@gmail.com>
---
drivers/mmc/sdhci.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index b9cbe34..0fd1337 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -137,8 +137,8 @@ int sdhci_send_command(struct mmc *mmc, struct mmc_cmd *cmd,
unsigned int timeout, start_addr = 0;
unsigned int retry = 10000;
- /* Wait max 10 ms */
- timeout = 10;
+ /* Wait max 100 ms */
+ timeout = 100;
sdhci_writel(host, SDHCI_INT_ALL_MASK, SDHCI_INT_STATUS);
mask = SDHCI_CMD_INHIBIT | SDHCI_DATA_INHIBIT;
--
1.7.2.3
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2012-10-11 5:38 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2012-10-11 5:38 UTC (permalink / raw)
To: u-boot
sent.
But the function you mentioned detect that flash is not erased.
Are you using a 16bit port for data connection to the flash ?
First check i would do is an "erase" test.
Try to erase some sectors with "erase" command, something like
# erase 40000 4ffff
Then dump the memory, (to be sure also with BDM eventually), to see
if it has really been erased.
Also, these are some settings i am using in my config, maybe they can
be useful:
/*
* Start addresses for the final memory configuration
* (Set up by the startup code)
* Please note that CONFIG_SYS_SDRAM_BASE _must_ start at 0
*/
#define CONFIG_SYS_SDRAM_BASE 0x00000000
#define CONFIG_SYS_SDRAM_SIZE 16 /* in MB */
#define CONFIG_SYS_FLASH_BASE 0xffc00000
#define CONFIG_SYS_TEXT_BASE 0xffc00000
#define CONFIG_SYS_MAX_FLASH_BANKS 1
#define CONFIG_SYS_MAX_FLASH_SECT 1024
#define CONFIG_SYS_FLASH_ERASE_TOUT 1000
/*
* CFI FLASH driver setup
*/
#define CONFIG_SYS_FLASH_CFI
#define CONFIG_FLASH_CFI_DRIVER
#define CONFIG_SYS_FLASH_USE_BUFFER_WRITE
...
Let us know if you find something.
Regards,
Angelo
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-10-11 5:38 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2012-10-11 5:38 UTC (permalink / raw)
To: u-boot
sent.
But the function you mentioned detect that flash is not erased.
Are you using a 16bit port for data connection to the flash ?
First check i would do is an "erase" test.
=
Try to erase some sectors with "erase" command, something like
# erase 40000 4ffff
Then dump the memory, (to be sure also with BDM eventually), to see
if it has really been erased.
Also, these are some settings i am using in my config, maybe they can =
be useful:
/*
* Start addresses for the final memory configuration
* (Set up by the startup code)
* Please note that CONFIG_SYS_SDRAM_BASE _must_ start at 0
*/
#define CONFIG_SYS_SDRAM_BASE 0x00000000
#define CONFIG_SYS_SDRAM_SIZE 16 /* in MB */
#define CONFIG_SYS_FLASH_BASE 0xffc00000
#define CONFIG_SYS_TEXT_BASE 0xffc00000
#define CONFIG_SYS_MAX_FLASH_BANKS 1
#define CONFIG_SYS_MAX_FLASH_SECT 1024
#define CONFIG_SYS_FLASH_ERASE_TOUT 1000
/*
* CFI FLASH driver setup
*/
#define CONFIG_SYS_FLASH_CFI
#define CONFIG_FLASH_CFI_DRIVER
#define CONFIG_SYS_FLASH_USE_BUFFER_WRITE
...
Let us know if you find something.
Regards,
Angelo
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Disclaimer~~~~~~~=
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Information contained and transmitted by this e-mail is confidential and pr=
oprietary to iGATE and its affiliates and is intended for use only by the r=
ecipient. If you are not the intended recipient, you are hereby notified th=
at any dissemination, distribution, copying or use of this e-mail is strict=
ly prohibited and you are requested to delete this e-mail immediately and n=
otify the originator or mailadmin at igate.com <mailto:mailadmin@igate.com>. i=
GATE does not enter into any agreement with any party by e-mail. Any views =
expressed by an individual do not necessarily reflect the view of iGATE. iG=
ATE is not responsible for the consequences of any actions taken on the bas=
is of information provided, through this email. The contents of an attachme=
nt to this e-mail may contain software viruses, which could damage your own=
computer system. While iGATE has taken every reasonable precaution to mini=
mise this risk, we cannot accept liability for any damage which you sustain=
as a result of software viruses. You should carry out your own virus check=
s before opening an attachment. To know more about iGATE please visit www.i=
gate.com <http://www.igate.com>.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-10-11 5:38 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2012-10-11 5:38 UTC (permalink / raw)
To: u-boot
so it won't stay dead.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-10-11 5:38 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2012-10-11 5:38 UTC (permalink / raw)
To: u-boot
sent.
But the function you mentioned detect that flash is not erased.
Are you using a 16bit port for data connection to the flash ?
First check i would do is an "erase" test.
=
Try to erase some sectors with "erase" command, something like
# erase 40000 4ffff
Then dump the memory, (to be sure also with BDM eventually), to see
if it has really been erased.
Also, these are some settings i am using in my config, maybe they can =
be useful:
/*
* Start addresses for the final memory configuration
* (Set up by the startup code)
* Please note that CONFIG_SYS_SDRAM_BASE _must_ start at 0
*/
#define CONFIG_SYS_SDRAM_BASE 0x00000000
#define CONFIG_SYS_SDRAM_SIZE 16 /* in MB */
#define CONFIG_SYS_FLASH_BASE 0xffc00000
#define CONFIG_SYS_TEXT_BASE 0xffc00000
#define CONFIG_SYS_MAX_FLASH_BANKS 1
#define CONFIG_SYS_MAX_FLASH_SECT 1024
#define CONFIG_SYS_FLASH_ERASE_TOUT 1000
/*
* CFI FLASH driver setup
*/
#define CONFIG_SYS_FLASH_CFI
#define CONFIG_FLASH_CFI_DRIVER
#define CONFIG_SYS_FLASH_USE_BUFFER_WRITE
...
Let us know if you find something.
Regards,
Angelo
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Disclaimer~~~~~~~=
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Information contained and transmitted by this e-mail is confidential and pr=
oprietary to iGATE and its affiliates and is intended for use only by the r=
ecipient. If you are not the intended recipient, you are hereby notified th=
at any dissemination, distribution, copying or use of this e-mail is strict=
ly prohibited and you are requested to delete this e-mail immediately and n=
otify the originator or mailadmin at igate.com <mailto:mailadmin@igate.com>. i=
GATE does not enter into any agreement with any party by e-mail. Any views =
expressed by an individual do not necessarily reflect the view of iGATE. iG=
ATE is not responsible for the consequences of any actions taken on the bas=
is of information provided, through this email. The contents of an attachme=
nt to this e-mail may contain software viruses, which could damage your own=
computer system. While iGATE has taken every reasonable precaution to mini=
mise this risk, we cannot accept liability for any damage which you sustain=
as a result of software viruses. You should carry out your own virus check=
s before opening an attachment. To know more about iGATE please visit www.i=
gate.com <http://www.igate.com>.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-10-11 5:38 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2012-10-11 5:38 UTC (permalink / raw)
To: u-boot
does for an already-configured port, so this seems fine.
> ---
> v2:
> - remember if port is already initialized and skip init in that case
> ---
> arch/arm/cpu/armv7/tegra20/usb.c | 57 ++++++++++++++++++++--------------------
> 1 file changed, 29 insertions(+), 28 deletions(-)
>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-10-11 5:38 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2012-10-11 5:38 UTC (permalink / raw)
To: u-boot
would be appreciated.
drivers/mtd/nand/mxc_nand.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/nand/mxc_nand.c b/drivers/mtd/nand/mxc_nand.c
index d0ded48..32ba340 100644
--- a/drivers/mtd/nand/mxc_nand.c
+++ b/drivers/mtd/nand/mxc_nand.c
@@ -1021,6 +1021,7 @@ void mxc_nand_command(struct mtd_info *mtd, unsigned command,
break;
case NAND_CMD_READOOB:
+ host->page_addr = page_addr;
host->col_addr = column;
host->spare_only = true;
if (host->pagesize_2k)
--
1.7.9.5
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2012-10-11 5:38 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2012-10-11 5:38 UTC (permalink / raw)
To: u-boot
U-Boot> md.b 0x20000000 0x200
I see the new environment in memory (which includes the CRC).
Example:
20000000: 00 00 00 00 00 65 74 68 61 64 64 72 3d 33 61 3a .....ethaddr=3a:
20000010: 31 66 3a 33 34 3a 30 38 3a 35 34 3a 35 34 00 74 1f:34:08:54:54.t
20000020: 69 6d 65 73 74 61 6d 70 3d 31 32 33 35 00 62 6f imestamp=1235.bo
20000030: 6f 74 64 65 6c 61 79 3d 33 00 62 61 75 64 72 61 otdelay=3.baudra
...
200001f0: 30 20 30 78 30 30 32 30 30 30 30 30 20 30 78 30 0 0x00200000 0x0
I can also see the default environment with:
U-Boot> env print
I try to load the environment from RAM:
U-Boot> env import -t 0x20000000 0x200
<no errors/warnings>
However, when I try to print the environment again, I see the default
values, and the new imported environment has no effect on the
environment.
U-Boot> env print
What am I doing wrong.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-10-11 5:38 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2012-10-11 5:38 UTC (permalink / raw)
To: u-boot
fine if it's used memory mapped, however it makes it unsuitable for
passing values in the SPL. So at first glance I would extend
config_ddr() with an additional register value, because guessing the
ddr type from the values of the other parameters is, in addition
to being hackish, not guaranteed to work with every weired ram configuration.
However might it be possible, that the second value of config_ddr()
should not hold the value for config_io_ctrl(), but the value of my
desired ddrctrl->ddrioctrl?
The wiki [1] from TI says that the first should _always_ be 0x18B,
whereas the second needs to be set depending on the mem type.
We are talking about a set of registers named DDR_*_IOCTRL and a
single register called DDR_IO_CTRL, so easy to mix up.
Ragards,
Markus
[1] http://processors.wiki.ti.com/index.php/AM335x_EMIF_Configuration_tips
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-10-11 5:38 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2012-10-11 5:38 UTC (permalink / raw)
To: u-boot
serial port (0x84000000)
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
NS16550_putc (com_port=0x84000000, c=13 '\r') at ns16550.c:91
91 while ((serial_in(&com_port->lsr) & UART_LSR_THRE) == 0)
(gdb)
In your opinion, is your patch providing everything that I need to boot
with XMD? Can you suggest what I might be doing wrong?
Thanks for any insight you may have,
Frank
--f46d04426ccc85c7d304d503b860--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-10-11 5:38 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2012-10-11 5:38 UTC (permalink / raw)
To: u-boot
for the eMMC case we are probing for an SD card, and when that fails,
trying eMMC. If we can specify which it is (which we can in the case
of a soldered-down device) then we might save that wasted time.
Regards,
Simon
>
> Thanks & Regards
> Amarendra Reddy
>
> On 23 January 2013 05:39, Simon Glass <sjg@chromium.org> wrote:
>>
>> Hi Amar,
>>
>> On Mon, Jan 21, 2013 at 3:43 AM, Amar <amarendra.xt@samsung.com> wrote:
>> > This patch adds DWMMC device node data for exynos5.
>> > This patch also adds binding file for DWMMC device node.
>> >
>> > Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
>> > Signed-off-by: Amar <amarendra.xt@samsung.com>
>>
>> Acked-by: Simon Glass <sjg@chromium.org>
>>
>> Can I suggest in a later patch you add a removable flag, so we can
>> mark devices which cannot be removed (and can be assumed to be
>> present). I believe that there is some overhead involved in detecting
>> an MMC (we have to try SD first, and fail).
>>
>> > ---
>> > Changes since V1:
>> > 1)Added binding file for DWMMC device node at the location
>> > "doc/device-tree-bindings/exynos/dwmmc.txt".
>> > 2)Removed the propname 'index' from device node.
>> > 3)Prefixed the vendor name 'samsung' before propname in device
>> > node.
>> >
>> > Changes since V2:
>> > 1)Updation of commit message and resubmition of proper patch
>> > set.
>> >
>> > Changes since V3:
>> > No change.
>> >
>> > Changes since V4:
>> > 1)Updated the doc/device-tree-bindings/exynos/dwmmc.txt with
>> > more
>> > information regarding the property 'samsung,timing'.
>> > 2)Replaced the name 'dwmmc' with 'mmc'.
>> >
>> > arch/arm/dts/exynos5250.dtsi | 31 +++++++++++++++++++
>> > board/samsung/dts/exynos5250-smdk5250.dts | 22 ++++++++++++++
>> > doc/device-tree-bindings/exynos/dwmmc.txt | 49
>> > +++++++++++++++++++++++++++++++
>> > 3 files changed, 102 insertions(+)
>> > create mode 100644 doc/device-tree-bindings/exynos/dwmmc.txt
>> >
>> > diff --git a/arch/arm/dts/exynos5250.dtsi b/arch/arm/dts/exynos5250.dtsi
>> > index ed8c8dd..6c08eb7 100644
>> > --- a/arch/arm/dts/exynos5250.dtsi
>> > +++ b/arch/arm/dts/exynos5250.dtsi
>> > @@ -151,4 +151,35 @@
>> > };
>> > };
>> >
>> > + mmc at 12200000 {
>> > + #address-cells = <1>;
>> > + #size-cells = <0>;
>> > + compatible = "samsung,exynos5250-dwmmc";
>> > + reg = <0x12200000 0x1000>;
>> > + interrupts = <0 75 0>;
>> > + };
>> > +
>> > + mmc at 12210000 {
>> > + #address-cells = <1>;
>> > + #size-cells = <0>;
>> > + compatible = "samsung,exynos5250-dwmmc";
>> > + reg = <0x12210000 0x1000>;
>> > + interrupts = <0 76 0>;
>> > + };
>> > +
>> > + mmc at 12220000 {
>> > + #address-cells = <1>;
>> > + #size-cells = <0>;
>> > + compatible = "samsung,exynos5250-dwmmc";
>> > + reg = <0x12220000 0x1000>;
>> > + interrupts = <0 77 0>;
>> > + };
>> > +
>> > + mmc at 12230000 {
>> > + #address-cells = <1>;
>> > + #size-cells = <0>;
>> > + compatible = "samsung,exynos5250-dwmmc";
>> > + reg = <0x12230000 0x1000>;
>> > + interrupts = <0 78 0>;
>> > + };
>> > };
>> > diff --git a/board/samsung/dts/exynos5250-smdk5250.dts
>> > b/board/samsung/dts/exynos5250-smdk5250.dts
>> > index cbfab6f..1d3e42b 100644
>> > --- a/board/samsung/dts/exynos5250-smdk5250.dts
>> > +++ b/board/samsung/dts/exynos5250-smdk5250.dts
>> > @@ -30,6 +30,10 @@
>> > spi2 = "/spi at 12d40000";
>> > spi3 = "/spi at 131a0000";
>> > spi4 = "/spi at 131b0000";
>> > + mmc0 = "/mmc at 12200000";
>> > + mmc1 = "/mmc at 12210000";
>> > + mmc2 = "/mmc at 12220000";
>> > + mmc3 = "/mmc at 12230000";
>> > };
>> >
>> > sromc at 12250000 {
>> > @@ -66,4 +70,22 @@
>> > compatible = "maxim,max77686_pmic";
>> > };
>> > };
>> > +
>> > + mmc at 12200000 {
>> > + samsung,bus-width = <8>;
>> > + samsung,timing = <1 3 3>;
>> > + };
>> > +
>> > + mmc at 12210000 {
>> > + status = "disabled";
>> > + };
>> > +
>> > + mmc at 12220000 {
>> > + samsung,bus-width = <4>;
>> > + samsung,timing = <1 2 3>;
>> > + };
>> > +
>> > + mmc at 12230000 {
>> > + status = "disabled";
>> > + };
>> > };
>> > diff --git a/doc/device-tree-bindings/exynos/dwmmc.txt
>> > b/doc/device-tree-bindings/exynos/dwmmc.txt
>> > new file mode 100644
>> > index 0000000..0054ace
>> > --- /dev/null
>> > +++ b/doc/device-tree-bindings/exynos/dwmmc.txt
>> > @@ -0,0 +1,49 @@
>> > +* Exynos 5250 DWC_mobile_storage
>> > +
>> > +The Exynos 5250 provides DWC_mobile_storage interface which supports
>> > +. Embedded Multimedia Cards (EMMC-version 4.5)
>> > +. Secure Digital memory (SD mem-version 2.0)
>> > +. Secure Digital I/O (SDIO-version 3.0)
>> > +. Consumer Electronics Advanced Transport Architecture (CE-ATA-version
>> > 1.1)
>> > +
>> > +The Exynos 5250 DWC_mobile_storage provides four channels.
>> > +SOC specific and Board specific properties are channel specific.
>> > +
>> > +Required SoC Specific Properties:
>> > +
>> > +- compatible: should be
>> > + - samsung,exynos5250-dwmmc: for exynos5250 platforms
>> > +
>> > +- reg: physical base address of the controller and length of memory
>> > mapped
>> > + region.
>> > +
>> > +- interrupts: The interrupt number to the cpu.
>> > +
>> > +Required Board Specific Properties:
>> > +
>> > +- #address-cells: should be 1.
>> > +- #size-cells: should be 0.
>> > +- samsung,bus-width: The width of the bus used to interface the devices
>> > + supported by DWC_mobile_storage (SD-MMC/EMMC/SDIO).
>> > + . Typically the bus width is 4 or 8.
>> > +- samsung,timing: The timing values to be written into the
>> > + Drv/sample clock selection register of corresponding channel.
>> > + . It is comprised of 3 values corresponding to the 3 fileds
>> > + 'SelClk_sample', 'SelClk_drv' and 'DIVRATIO' of CLKSEL
>> > register.
>> > + . SelClk_sample: Select sample clock among 8 shifted clocks.
>> > + . SelClk_drv: Select drv clock among 8 shifted clocks.
>> > + . DIVRATIO: Clock Divide ratio select.
>> > + . The above 3 values are used by the clock phase shifter.
>> > +
>> > +Example:
>> > +
>> > +mmc at 12200000 {
>> > + samsung,bus-width = <8>;
>> > + samsung,timing = <1 3 3>;
>> > +}
>> > +In the above example,
>> > + . The bus width is 8
>> > + . Timing is comprised of 3 values as explained below
>> > + 1 - SelClk_sample
>> > + 3 - SelClk_drv
>> > + 3 - DIVRATIO
>> > --
>> > 1.8.0
>> >
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot at lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>
>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-10-11 5:38 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2012-10-11 5:38 UTC (permalink / raw)
To: u-boot
The DRAM control register change has been kept specific to mx23evk as
it breaks mx23_olinuxino (as it than reads only 16MB)
--
Otavio Salvador O.S. Systems
E-mail: otavio at ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-10-11 5:38 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2012-10-11 5:38 UTC (permalink / raw)
To: u-boot
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
---
drivers/video/exynos_dp.c | 2 ++
drivers/video/exynos_dp_lowlevel.c | 52 +++++---------------------------------
drivers/video/exynos_dp_lowlevel.h | 1 +
3 files changed, 10 insertions(+), 45 deletions(-)
diff --git a/drivers/video/exynos_dp.c b/drivers/video/exynos_dp.c
index b2accc7..5f4f25e 100644
--- a/drivers/video/exynos_dp.c
+++ b/drivers/video/exynos_dp.c
@@ -876,6 +876,8 @@ unsigned int exynos_init_dp(void)
return -EFAULT;
}
+ exynos_dp_set_base_addr();
+
exynos_dp_disp_info(&edp_info->disp_info);
exynos_set_dp_phy(1);
diff --git a/drivers/video/exynos_dp_lowlevel.c b/drivers/video/exynos_dp_lowlevel.c
index 7b54c80..0be91a5 100644
--- a/drivers/video/exynos_dp_lowlevel.c
+++ b/drivers/video/exynos_dp_lowlevel.c
@@ -26,10 +26,16 @@
#include <asm/arch/dp_info.h>
#include <asm/arch/dp.h>
+struct exynos_dp *dp_regs;
+
+void exynos_dp_set_base_addr(void)
+{
+ dp_regs = (struct exynos_dp *)samsung_get_base_dp();
+}
+
static void exynos_dp_enable_video_input(unsigned int enable)
{
unsigned int reg;
- struct exynos_dp *dp_regs = (struct exynos_dp *)samsung_get_base_dp();
reg = readl(&dp_regs->video_ctl1);
reg &= ~VIDEO_EN_MASK;
@@ -47,7 +53,6 @@ void exynos_dp_enable_video_bist(unsigned int enable)
{
/*enable video bist*/
unsigned int reg;
- struct exynos_dp *dp_regs = (struct exynos_dp *)samsung_get_base_dp();
reg = readl(&dp_regs->video_ctl4);
reg &= ~VIDEO_BIST_MASK;
@@ -64,7 +69,6 @@ void exynos_dp_enable_video_bist(unsigned int enable)
void exynos_dp_enable_video_mute(unsigned int enable)
{
unsigned int reg;
- struct exynos_dp *dp_regs = (struct exynos_dp *)samsung_get_base_dp();
reg = readl(&dp_regs->video_ctl1);
reg &= ~(VIDEO_MUTE_MASK);
@@ -80,7 +84,6 @@ void exynos_dp_enable_video_mute(unsigned int enable)
static void exynos_dp_init_analog_param(void)
{
unsigned int reg;
- struct exynos_dp *dp_regs = (struct exynos_dp *)samsung_get_base_dp();
/*
* Set termination
@@ -129,7 +132,6 @@ static void exynos_dp_init_analog_param(void)
static void exynos_dp_init_interrupt(void)
{
- struct exynos_dp *dp_regs = (struct exynos_dp *)samsung_get_base_dp();
/* Set interrupt registers to initial states */
/*
@@ -158,7 +160,6 @@ static void exynos_dp_init_interrupt(void)
void exynos_dp_reset(void)
{
unsigned int reg_func_1;
- struct exynos_dp *dp_regs = (struct exynos_dp *)samsung_get_base_dp();
/*dp tx sw reset*/
writel(RESET_DP_TX, &dp_regs->tx_sw_reset);
@@ -186,7 +187,6 @@ void exynos_dp_reset(void)
void exynos_dp_enable_sw_func(unsigned int enable)
{
unsigned int reg;
- struct exynos_dp *dp_regs = (struct exynos_dp *)samsung_get_base_dp();
reg = readl(&dp_regs->func_en1);
reg &= ~(SW_FUNC_EN_N);
@@ -202,7 +202,6 @@ void exynos_dp_enable_sw_func(unsigned int enable)
unsigned int exynos_dp_set_analog_power_down(unsigned int block, u32 enable)
{
unsigned int reg;
- struct exynos_dp *dp_regs = (struct exynos_dp *)samsung_get_base_dp();
reg = readl(&dp_regs->phy_pd);
switch (block) {
@@ -256,7 +255,6 @@ unsigned int exynos_dp_set_analog_power_down(unsigned int block, u32 enable)
unsigned int exynos_dp_get_pll_lock_status(void)
{
unsigned int reg;
- struct exynos_dp *dp_regs = (struct exynos_dp *)samsung_get_base_dp();
reg = readl(&dp_regs->debug_ctl);
@@ -269,7 +267,6 @@ unsigned int exynos_dp_get_pll_lock_status(void)
static void exynos_dp_set_pll_power(unsigned int enable)
{
unsigned int reg;
- struct exynos_dp *dp_regs = (struct exynos_dp *)samsung_get_base_dp();
reg = readl(&dp_regs->pll_ctl);
reg &= ~(DP_PLL_PD);
@@ -285,7 +282,6 @@ int exynos_dp_init_analog_func(void)
int ret = EXYNOS_DP_SUCCESS;
unsigned int retry_cnt = 10;
unsigned int reg;
- struct exynos_dp *dp_regs = (struct exynos_dp *)samsung_get_base_dp();
/*Power On All Analog block */
exynos_dp_set_analog_power_down(POWER_ALL, DP_DISABLE);
@@ -335,7 +331,6 @@ int exynos_dp_init_analog_func(void)
void exynos_dp_init_hpd(void)
{
unsigned int reg;
- struct exynos_dp *dp_regs = (struct exynos_dp *)samsung_get_base_dp();
/* Clear interrupts releated to Hot Plug Dectect */
reg = HOTPLUG_CHG | HPD_LOST | PLUG;
@@ -354,7 +349,6 @@ void exynos_dp_init_hpd(void)
static inline void exynos_dp_reset_aux(void)
{
unsigned int reg;
- struct exynos_dp *dp_regs = (struct exynos_dp *)samsung_get_base_dp();
/* Disable AUX channel module */
reg = readl(&dp_regs->func_en2);
@@ -367,7 +361,6 @@ static inline void exynos_dp_reset_aux(void)
void exynos_dp_init_aux(void)
{
unsigned int reg;
- struct exynos_dp *dp_regs = (struct exynos_dp *)samsung_get_base_dp();
/* Clear inerrupts related to AUX channel */
reg = RPLY_RECEIV | AUX_ERR;
@@ -395,7 +388,6 @@ void exynos_dp_init_aux(void)
void exynos_dp_config_interrupt(void)
{
unsigned int reg;
- struct exynos_dp *dp_regs = (struct exynos_dp *)samsung_get_base_dp();
/* 0: mask, 1: unmask */
reg = COMMON_INT_MASK_1;
@@ -419,7 +411,6 @@ void exynos_dp_config_interrupt(void)
unsigned int exynos_dp_get_plug_in_status(void)
{
unsigned int reg;
- struct exynos_dp *dp_regs = (struct exynos_dp *)samsung_get_base_dp();
reg = readl(&dp_regs->sys_ctl3);
if (reg & HPD_STATUS)
@@ -449,7 +440,6 @@ unsigned int exynos_dp_start_aux_transaction(void)
unsigned int reg;
unsigned int ret = 0;
unsigned int retry_cnt;
- struct exynos_dp *dp_regs = (struct exynos_dp *)samsung_get_base_dp();
/* Enable AUX CH operation */
reg = readl(&dp_regs->aux_ch_ctl2);
@@ -498,7 +488,6 @@ unsigned int exynos_dp_write_byte_to_dpcd(unsigned int reg_addr,
unsigned char data)
{
unsigned int reg, ret;
- struct exynos_dp *dp_regs = (struct exynos_dp *)samsung_get_base_dp();
/* Clear AUX CH data buffer */
reg = BUF_CLR;
@@ -539,7 +528,6 @@ unsigned int exynos_dp_read_byte_from_dpcd(unsigned int reg_addr,
{
unsigned int reg;
int retval;
- struct exynos_dp *dp_regs = (struct exynos_dp *)samsung_get_base_dp();
/* Clear AUX CH data buffer */
reg = BUF_CLR;
@@ -583,7 +571,6 @@ unsigned int exynos_dp_write_bytes_to_dpcd(unsigned int reg_addr,
unsigned int cur_data_idx;
unsigned int retry_cnt;
unsigned int ret = 0;
- struct exynos_dp *dp_regs = (struct exynos_dp *)samsung_get_base_dp();
/* Clear AUX CH data buffer */
reg = BUF_CLR;
@@ -649,7 +636,6 @@ unsigned int exynos_dp_read_bytes_from_dpcd(unsigned int reg_addr,
unsigned int cur_data_idx;
unsigned int retry_cnt;
unsigned int ret = 0;
- struct exynos_dp *dp_regs = (struct exynos_dp *)samsung_get_base_dp();
/* Clear AUX CH data buffer */
reg = BUF_CLR;
@@ -711,7 +697,6 @@ int exynos_dp_select_i2c_device(unsigned int device_addr,
{
unsigned int reg;
int retval;
- struct exynos_dp *dp_regs = (struct exynos_dp *)samsung_get_base_dp();
/* Set EDID device address */
reg = device_addr;
@@ -746,7 +731,6 @@ int exynos_dp_read_byte_from_i2c(unsigned int device_addr,
unsigned int reg;
int i;
int retval;
- struct exynos_dp *dp_regs = (struct exynos_dp *)samsung_get_base_dp();
for (i = 0; i < 10; i++) {
/* Clear AUX CH data buffer */
@@ -790,7 +774,6 @@ int exynos_dp_read_bytes_from_i2c(unsigned int device_addr,
unsigned int cur_data_idx;
unsigned int defer = 0;
int retval = 0;
- struct exynos_dp *dp_regs = (struct exynos_dp *)samsung_get_base_dp();
for (i = 0; i < count; i += 16) { /* use 16 burst */
for (j = 0; j < 100; j++) {
@@ -854,7 +837,6 @@ int exynos_dp_read_bytes_from_i2c(unsigned int device_addr,
void exynos_dp_reset_macro(void)
{
unsigned int reg;
- struct exynos_dp *dp_regs = (struct exynos_dp *)samsung_get_base_dp();
reg = readl(&dp_regs->phy_test);
reg |= MACRO_RST;
@@ -870,7 +852,6 @@ void exynos_dp_reset_macro(void)
void exynos_dp_set_link_bandwidth(unsigned char bwtype)
{
unsigned int reg;
- struct exynos_dp *dp_regs = (struct exynos_dp *)samsung_get_base_dp();
reg = (unsigned int)bwtype;
@@ -883,7 +864,6 @@ unsigned char exynos_dp_get_link_bandwidth(void)
{
unsigned char ret;
unsigned int reg;
- struct exynos_dp *dp_regs = (struct exynos_dp *)samsung_get_base_dp();
reg = readl(&dp_regs->link_bw_set);
ret = (unsigned char)reg;
@@ -894,7 +874,6 @@ unsigned char exynos_dp_get_link_bandwidth(void)
void exynos_dp_set_lane_count(unsigned char count)
{
unsigned int reg;
- struct exynos_dp *dp_regs = (struct exynos_dp *)samsung_get_base_dp();
reg = (unsigned int)count;
@@ -906,7 +885,6 @@ void exynos_dp_set_lane_count(unsigned char count)
unsigned int exynos_dp_get_lane_count(void)
{
unsigned int reg;
- struct exynos_dp *dp_regs = (struct exynos_dp *)samsung_get_base_dp();
reg = readl(&dp_regs->lane_count_set);
@@ -915,7 +893,6 @@ unsigned int exynos_dp_get_lane_count(void)
unsigned char exynos_dp_get_lanex_pre_emphasis(unsigned char lanecnt)
{
- struct exynos_dp *dp_regs = (struct exynos_dp *)samsung_get_base_dp();
unsigned int reg_list[DP_LANE_CNT_4] = {
(unsigned int)&dp_regs->ln0_link_training_ctl,
(unsigned int)&dp_regs->ln1_link_training_ctl,
@@ -929,7 +906,6 @@ unsigned char exynos_dp_get_lanex_pre_emphasis(unsigned char lanecnt)
void exynos_dp_set_lanex_pre_emphasis(unsigned char request_val,
unsigned char lanecnt)
{
- struct exynos_dp *dp_regs = (struct exynos_dp *)samsung_get_base_dp();
unsigned int reg_list[DP_LANE_CNT_4] = {
(unsigned int)&dp_regs->ln0_link_training_ctl,
(unsigned int)&dp_regs->ln1_link_training_ctl,
@@ -944,7 +920,6 @@ void exynos_dp_set_lane_pre_emphasis(unsigned int level, unsigned char lanecnt)
{
unsigned char i;
unsigned int reg;
- struct exynos_dp *dp_regs = (struct exynos_dp *)samsung_get_base_dp();
unsigned int reg_list[DP_LANE_CNT_4] = {
(unsigned int)&dp_regs->ln0_link_training_ctl,
(unsigned int)&dp_regs->ln1_link_training_ctl,
@@ -967,7 +942,6 @@ void exynos_dp_set_lane_pre_emphasis(unsigned int level, unsigned char lanecnt)
void exynos_dp_set_training_pattern(unsigned int pattern)
{
unsigned int reg = 0;
- struct exynos_dp *dp_regs = (struct exynos_dp *)samsung_get_base_dp();
switch (pattern) {
case PRBS7:
@@ -996,7 +970,6 @@ void exynos_dp_set_training_pattern(unsigned int pattern)
void exynos_dp_enable_enhanced_mode(unsigned char enable)
{
unsigned int reg;
- struct exynos_dp *dp_regs = (struct exynos_dp *)samsung_get_base_dp();
reg = readl(&dp_regs->sys_ctl4);
reg &= ~ENHANCED;
@@ -1010,7 +983,6 @@ void exynos_dp_enable_enhanced_mode(unsigned char enable)
void exynos_dp_enable_scrambling(unsigned int enable)
{
unsigned int reg;
- struct exynos_dp *dp_regs = (struct exynos_dp *)samsung_get_base_dp();
reg = readl(&dp_regs->training_ptn_set);
reg &= ~(SCRAMBLING_DISABLE);
@@ -1024,7 +996,6 @@ void exynos_dp_enable_scrambling(unsigned int enable)
int exynos_dp_init_video(void)
{
unsigned int reg;
- struct exynos_dp *dp_regs = (struct exynos_dp *)samsung_get_base_dp();
/* Clear VID_CLK_CHG[1] and VID_FORMAT_CHG[3] and VSYNC_DET[7] */
reg = VSYNC_DET | VID_FORMAT_CHG | VID_CLK_CHG;
@@ -1040,7 +1011,6 @@ int exynos_dp_init_video(void)
void exynos_dp_config_video_slave_mode(struct edp_video_info *video_info)
{
unsigned int reg;
- struct exynos_dp *dp_regs = (struct exynos_dp *)samsung_get_base_dp();
/* Video Slave mode setting */
reg = readl(&dp_regs->func_en1);
@@ -1074,7 +1044,6 @@ void exynos_dp_config_video_slave_mode(struct edp_video_info *video_info)
void exynos_dp_set_video_color_format(struct edp_video_info *video_info)
{
unsigned int reg;
- struct exynos_dp *dp_regs = (struct exynos_dp *)samsung_get_base_dp();
/* Configure the input color depth, color space, dynamic range */
reg = (video_info->dynamic_range << IN_D_RANGE_SHIFT) |
@@ -1097,7 +1066,6 @@ int exynos_dp_config_video_bist(struct edp_device_info *edp_info)
unsigned int reg;
unsigned int bist_type = 0;
struct edp_video_info video_info = edp_info->video_info;
- struct exynos_dp *dp_regs = (struct exynos_dp *)samsung_get_base_dp();
/* For master mode, you don't need to set the video format */
if (video_info.master_mode == 0) {
@@ -1186,7 +1154,6 @@ int exynos_dp_config_video_bist(struct edp_device_info *edp_info)
unsigned int exynos_dp_is_slave_video_stream_clock_on(void)
{
unsigned int reg;
- struct exynos_dp *dp_regs = (struct exynos_dp *)samsung_get_base_dp();
/* Update Video stream clk detect status */
reg = readl(&dp_regs->sys_ctl1);
@@ -1206,7 +1173,6 @@ void exynos_dp_set_video_cr_mn(unsigned int type, unsigned int m_value,
unsigned int n_value)
{
unsigned int reg;
- struct exynos_dp *dp_regs = (struct exynos_dp *)samsung_get_base_dp();
if (type == REGISTER_M) {
reg = readl(&dp_regs->sys_ctl4);
@@ -1235,7 +1201,6 @@ void exynos_dp_set_video_cr_mn(unsigned int type, unsigned int m_value,
void exynos_dp_set_video_timing_mode(unsigned int type)
{
unsigned int reg;
- struct exynos_dp *dp_regs = (struct exynos_dp *)samsung_get_base_dp();
reg = readl(&dp_regs->video_ctl10);
reg &= ~FORMAT_SEL;
@@ -1249,7 +1214,6 @@ void exynos_dp_set_video_timing_mode(unsigned int type)
void exynos_dp_enable_video_master(unsigned int enable)
{
unsigned int reg;
- struct exynos_dp *dp_regs = (struct exynos_dp *)samsung_get_base_dp();
reg = readl(&dp_regs->soc_general_ctl);
if (enable) {
@@ -1266,7 +1230,6 @@ void exynos_dp_enable_video_master(unsigned int enable)
void exynos_dp_start_video(void)
{
unsigned int reg;
- struct exynos_dp *dp_regs = (struct exynos_dp *)samsung_get_base_dp();
/* Enable Video input and disable Mute */
reg = readl(&dp_regs->video_ctl1);
@@ -1277,7 +1240,6 @@ void exynos_dp_start_video(void)
unsigned int exynos_dp_is_video_stream_on(void)
{
unsigned int reg;
- struct exynos_dp *dp_regs = (struct exynos_dp *)samsung_get_base_dp();
/* Update STRM_VALID */
reg = readl(&dp_regs->sys_ctl3);
diff --git a/drivers/video/exynos_dp_lowlevel.h b/drivers/video/exynos_dp_lowlevel.h
index a041a7a..2c0ae12 100644
--- a/drivers/video/exynos_dp_lowlevel.h
+++ b/drivers/video/exynos_dp_lowlevel.h
@@ -76,5 +76,6 @@ void exynos_dp_set_video_timing_mode(unsigned int type);
void exynos_dp_enable_video_master(unsigned int enable);
void exynos_dp_start_video(void);
unsigned int exynos_dp_is_video_stream_on(void);
+void exynos_dp_set_base_addr(void);
#endif /* _EXYNOS_DP_LOWLEVEL_H */
--
1.8.0
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2012-10-11 5:38 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2012-10-11 5:38 UTC (permalink / raw)
To: u-boot
interpreting wrong) it lists all things NOT enabled. But I guess you
are wanting exact text with which to prune the -all.tmp. Could you
craft it such that you can use .tmp directly to prune -all.tmp instead
of having to generate this -enable.tmp file (which is misleading and
potentially a waste of sed time)? Please rename define2list.sed and
define2conf.sed to something which has meaning. This is quite hard to
read as it.
> + set -e ; \
> + : Find CONFIGs that are not enabled ; \
> + comm -13 $@-enabled.tmp $@-all.tmp >>$@.tmp && \
> + mv $@.tmp $@
> +
> $(obj)include/generated/generic-asm-offsets.h: $(obj)include/autoconf.mk.dep \
> $(obj)lib/asm-offsets.s
> @$(XECHO) Generating $@
> @@ -770,7 +809,8 @@ include/license.h: tools/bin2header COPYING
> unconfig:
> @rm -f $(obj)include/config.h $(obj)include/config.mk \
> $(obj)board/*/config.tmp $(obj)board/*/*/config.tmp \
> - $(obj)include/autoconf.mk $(obj)include/autoconf.mk.dep
> + $(obj)include/autoconf.mk $(obj)include/autoconf.mk.dep \
> + $(obj)include/generated/autoconf.h
>
> %_config:: unconfig
> @$(MKCONFIG) -A $(@:_config=)
> diff --git a/README b/README
> index d8cb394..3e89551 100644
> --- a/README
> +++ b/README
> @@ -5434,11 +5434,92 @@ Notes:
> * If you modify existing code, make sure that your new code does not
> add to the memory footprint of the code ;-) Small is beautiful!
> When adding new features, these should compile conditionally only
> - (using #ifdef), and the resulting code with the new feature
> - disabled must not need more memory than the old code without your
> - modification.
> + (avoiding #ifdef where at all possible), and the resulting code with
> + the new feature disabled must not need more memory than the old code
> + without your modification.
>
> * Remember that there is a size limit of 100 kB per message on the
> u-boot mailing list. Bigger patches will be moderated. If they are
> reasonable and not too big, they will be acknowledged. But patches
> bigger than the size limit should be avoided.
> +
> +
> +Use of #ifdef:
> +--------------
> +Many parts of the U-Boot code base are sprinkled with #ifdefs. This makes
> +different boards compile different versions of the source code, meaning
> +that we must build all boards to check for failures. It is easy to misspell
> +an #ifdef and there is not as much checking of this by the compiler. For
> +someone coming new into the code base, #ifdefs are a big turn-off. Multiple
> +dependent #ifdefs are harder to do than with if..then..else. Variable
> +declarations must be #idefed as well as the code that uses them, often much
Isn't it true that dead code stripping doesn't strip variables only
used by that dead code? So stack usage is wasted everywhere in this
new model?
> +later in the file/function. #ifdef indents don't match code indents and
> +have their own separate indent feature. Overall, excessive use of #idef
> +hurts readability and makes the code harder to modify and refactor.
> +
> +In an effort to reduce the use of #ifdef in U-Boot, without requiring lots
> +of special static inlines all over the header files, a single autoconf.h
> +header file with lower-case function-type macros has been made available.
> +
> +This file has either:
> +
> +# #define config_xxx() value
Use the new names here...
> +
> +for enabled options, or:
> +
> +# #define config_xxx() 0
> +
> +for disabled options. You can therefore generally change code like this:
> +
> + #ifdef CONFIG_XXX
> + do_something
> + #else
> + do_something_else
> + #endif
> +
> +to this:
> +
> + if (config_xxx())
> + do_something;
> + else
> + do_something_else;
> +
> +The compiler will see that config_xxx() evalutes to a constant and will
> +eliminate the dead code. The resulting code (and code size) is the same.
> +
> +Multiple #ifdefs can be converted also:
> +
> + #if defined(CONFIG_XXX) && !defined(CONFIG_YYY)
> + do_something
> + #endif
> +
> + if (config_xxx() && !config_yyy())
> + do_something;
> +
> +Where the macro evaluates to a string, it will be non-NULL, so the above
> +will work whether the macro is a string or a number.
> +
> +This takes care of almost all CONFIG macros. Unfortunately there are a few
> +cases where a value of 0 does not mean the option is disabled. For example
> +CONFIG_BOOTDELAY can be defined to 0, which means that the bootdelay
> +code should be used, but with a value of 0. To get around this and other
> +sticky cases, an addition macro with an '_enabled' suffix is provided, where
> +the value is always either 0 or 1:
> +
> + // Will work even if boaard config has '#define CONFIG_BOOTDELAY 0'
> + if (config_bootdelay_enabled())
> + do_something;
> +
> +(Probably such config options should be deprecated and then we can remove
> +this feature)
> +
> +U-Boot already has a Makefile scheme to permit files to be easily included
> +based on CONFIG. This can be used where the code to be compiled exists in
> +its own source file. So the following rules apply:
> +
> + 1. Use #ifdef to conditionally compile an exported function or variable
> + 2. Use ordinary C code with config_xxx() everywhere else
> + 3. Mark your functions and data structures static where possible
> + 4. Use the config_xxx_enabled() variants only if essential
Fix names here.
> + 5. When changing existing code, first create a new patch to replace
> + #ifdefs in the surrounding area
> diff --git a/include/common.h b/include/common.h
> index 4ad17ea..491783b 100644
> --- a/include/common.h
> +++ b/include/common.h
> @@ -35,6 +35,9 @@ typedef volatile unsigned short vu_short;
> typedef volatile unsigned char vu_char;
>
> #include <config.h>
> +#ifndef DO_DEPS_ONLY
> +#include <generated/autoconf.h>
> +#endif
> #include <asm-offsets.h>
> #include <linux/bitops.h>
> #include <linux/types.h>
> diff --git a/include/config_drop.h b/include/config_drop.h
> new file mode 100644
> index 0000000..bf2beaa
> --- /dev/null
> +++ b/include/config_drop.h
> @@ -0,0 +1,17 @@
> +/*
> + * Copyright 2013 Google, Inc
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License Version 2. This file is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#ifndef _CONFIG_DROP_H
> +#define _CONFIG_DROP_H
> +
> +/* Options which don't seem to be referred to anywhere in U-Boot */
You mean not referred to by any config header?
> +#define CONFIG_MENUPROMPT "Auto-boot prompt"
> +#define CONFIG_MENUKEY
> +#define CONFIG_UPDATE_TFTP
> +
> +#endif
> diff --git a/tools/scripts/define2conf.sed b/tools/scripts/define2conf.sed
> new file mode 100644
> index 0000000..2c4a2ef
> --- /dev/null
> +++ b/tools/scripts/define2conf.sed
> @@ -0,0 +1,37 @@
> +#
> +# Sed script to parse CPP macros and generate a list of CONFIG macros
> +#
> +# This converts:
> +# #define CONFIG_XXX value
> +#into:
> +# #define config_xxx() value
> +# #define config_xxx_enabled() 1
Fix the names here.
> +#
> +
> +# Macros with parameters are ignored.
> +/^#define CONFIG_[A-Za-z0-9_][A-Za-z0-9_]*(/ {
> + d
Any reason not to use "[A-Za-z0-9_]+" instead of "[A-Za-z0-9_][A-Za-z0-9_]*"?
> +}
> +
> +# Only process values prefixed with #define CONFIG_
> +/^#define CONFIG_[A-Za-z0-9_][A-Za-z0-9_]*/ {
> + # Strip the #define prefix
> + s/#define[ \t]*CONFIG_/autoconf_/;
> + # Change to form CONFIG_*=VALUE
> + s/[\t ][\t ]*/=/;
> + # Handle lines with no value
> + s/^\([^=]*\)$/\1=/;
> + # Drop trailing spaces
> + s/ *$//;
> + # Change empty values to '1'
> + s/=$/=1/;
> + # Add #define at the start
> + s/^\([^=]*\)=/#define \L\1() /
> + # print the line
> + p
> + # Create autoconf_has_...(), value 1
> + s/().*/() 1/
> + s/\(autoconf_\)/\1has_/
> + # print the line
> + p
> +}
> diff --git a/tools/scripts/define2list.sed b/tools/scripts/define2list.sed
Please change the name to be more clear as to its purpose. "list"
doesn't convey to me that it is all configs that should be set as
undefined.
> new file mode 100644
> index 0000000..152280d
> --- /dev/null
> +++ b/tools/scripts/define2list.sed
> @@ -0,0 +1,31 @@
> +#
> +# Sed script to parse CPP macros and generate a list of CONFIG macros
> +#
> +# This converts:
> +# #define CONFIG_XXX value
> +#into:
> +# #define config_xxx() 0
> +# #define config_xxx_enabled() 0
Fix names here.
> +
> +# Macros with parameters are ignored.
> +/^#define CONFIG_[A-Za-z0-9_][A-Za-z0-9_]*(/ {
> + s/.*//
> +}
> +
> +# Only process values prefixed with #define CONFIG_
> +/^#define CONFIG_[A-Za-z0-9_][A-Za-z0-9_]*/ {
> + # Strip the #define prefix
> + s/#define *//;
> + # Remove the value
> + s/[ \t].*//;
> + # Convert to lower case, prepend #define
> + s/CONFIG_\(.*\)/#define autoconf_\L\1/
> + # Append 0
> + s/$/() 0/
> + # print the line
> + p
> + # Create autoconf_has_...(), value 0
> + s/\(autoconf_\)/\1has_/
> + # print the line
> + p
> +}
> --
> 1.8.1.3
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-10-11 5:38 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2012-10-11 5:38 UTC (permalink / raw)
To: u-boot
see your position about it being beyond the scope of this patch. It
would be great if someone who cares about this modem code would clean
up the mess.
>>
>>> + debug("DEBUG: main_loop: do_mdm_init=%d\n", do_mdm_init);
>>> + if (do_mdm_init) {
>>> + char *str = strdup(getenv("mdm_cmd"));
>>> +
>>> + setenv("preboot", str); /* set or delete definition */
>>> + if (str != NULL)
>>> + free(str);
>>> + mdm_init(); /* wait for modem connection */
>>> + }
>>> }
>>> -#endif /* CONFIG_MODEM_SUPPORT */
>>>
>>> -#ifdef CONFIG_VERSION_VARIABLE
>>> - {
>>> + if (autoconf_version_variable())
>>> setenv("ver", version_string); /* set version variable */
>>> - }
>>> -#endif /* CONFIG_VERSION_VARIABLE */
>>>
>>> -#ifdef CONFIG_SYS_HUSH_PARSER
>>> - u_boot_hush_start();
>>> -#endif
>>> + if (autoconf_sys_hush_parser())
>>> + u_boot_hush_start();
>>>
>>> -#if defined(CONFIG_HUSH_INIT_VAR)
>>> - hush_init_var();
>>> -#endif
>>> + if (autoconf_hush_init_var())
>>> + hush_init_var();
>>> +
>>> + if (autoconf_preboot()) {
>>> + char *p = getenv("preboot");
>>> +
>>> + if (p) {
>>> + int prev;
>>>
>>> -#ifdef CONFIG_PREBOOT
>>> - p = getenv("preboot");
>>> - if (p) {
>>> -# ifdef CONFIG_AUTOBOOT_KEYED
>>> - int prev = disable_ctrlc(1); /* disable Control C checking */
>>> -# endif
>>> + /* disable Control C checking */
>>> + if (autoconf_autoboot_keyed())
>>> + prev = disable_ctrlc(1);
>>>
>>> - run_command_list(p, -1, 0);
>>> + run_command_list(p, -1, 0);
>>>
>>> -# ifdef CONFIG_AUTOBOOT_KEYED
>>> - disable_ctrlc(prev); /* restore Control C checking */
>>> -# endif
>>> + /* restore Control C checking */
>>> + if (autoconf_autoboot_keyed())
>>> + disable_ctrlc(prev);
>>> + }
>>> }
>>> -#endif /* CONFIG_PREBOOT */
>>>
>>> if (autoconf_update_tftp())
>>> update_tftp(0UL);
>>> @@ -435,9 +428,8 @@ void main_loop(void)
>>> if (autoconf_has_bootdelay() && autoconf_bootdelay() >= 0)
>>> process_boot_delay();
>>>
>>> -#if defined CONFIG_OF_CONTROL
>>> - set_working_fdt_addr((void *)gd->fdt_blob);
>>> -#endif /* CONFIG_OF_CONTROL */
>>> + if (autoconf_of_control() && autoconf_of_libfdt())
>>
>> Why are you adding an additional condition on autoconf_of_libfdt()?
>
> I think I had a build warning somewhere - I will take another look,
> and then add a comment if it is still needed.
I guess you determined this to be superfluous.
<snip>
Cheers,
-Joe
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-10-11 5:38 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2012-10-11 5:38 UTC (permalink / raw)
To: u-boot
are able to access
only up to 16MB--> means 0 to 0x FFFFFF
If the flash has 32MB, if the user is giving an offset 0x1000000 it will ag=
ain pointing to 0x0.
Because we have 3-byte addressing able to access only first 16MB of flash b=
ut the actual flash size is 32MB.
So, from my implementation if user is giving an offset of 0x1000000 then we=
have enable the bank register
for pointing to second 16MB area on 32 MB flash and we must subtract the of=
fset from 16MB as we are using 3-byte
addressing. Means we are accessing 4-byte addressing in 3-byte address mode=
. Ie is the reason I am subtracting it from16MB.
Please comment and let me know if you're not clear.
>
> > + } else {
> > + ret =3D spi_flash_extaddr_access(flash,
> STATUS_EXTADDR_DISABLE);
> > + if (ret) {
> > + debug("SF: fail to %s ext addr bit\n",
> > + STATUS_EXTADDR_DISABLE ? "set" : "reset");
> > + return ret;
> > + }
> > + }
> > +
> > + return ret;
> > +}
> > +
> > static int spi_flash_read_write(struct spi_slave *spi,
> > const u8 *cmd, size_t cmd_len,
> > const u8 *data_out, u8 *data_in, @@ -73,6
> +97,14 @@ int
> > spi_flash_cmd_write_multi(struct spi_flash *flash, u32 offset,
> > int ret;
> > u8 cmd[4];
> >
> > + if (flash->size > 0x1000000) {
>
> As already said in my comments to patch 1/4, this check (and the check fo=
r
> manufacturer ID) should be done only once once during probing of the flas=
h.
> Then, if necessary, adapted functions for read, write and erase should be=
> assigned to the function-pointers.
> Or use an additional function-pointer, which can be set to this or a simi=
lar
> function.
> Then the call of this function should be included in the loops, which all=
these
> functions have.
> Otherwise, as with your current code, you have a problem if the current
> accessed block crosses the boundary at 16M. Have you ever tried this?
Means this check should be in probe call, by adding one member in spi_flash=
structure, is it?.
I am not understanding extra function pointers concept, will you please exp=
lain.
>
> > + ret =3D spi_flash_check_extaddr_access(flash, &offset);
> > + if (ret) {
> > + debug("SF: fail to acess ext_addr\n");
> > + return ret;
> > + }
> > + }
> > +
> > page_size =3D flash->page_size;
> > page_addr =3D offset / page_size;
> > byte_addr =3D offset % page_size;
> > @@ -139,6 +171,15 @@ int spi_flash_cmd_read_fast(struct spi_flash
> *flash, u32 offset,
> > size_t len, void *data)
> > {
> > u8 cmd[5];
> > + int ret;
> > +
> > + if (flash->size > 0x1000000) {
> > + ret =3D spi_flash_check_extaddr_access(flash, &offset);
> > + if (ret) {
> > + debug("SF: fail to acess ext_addr\n");
> > + return ret;
> > + }
> > + }
> >
> > cmd[0] =3D CMD_READ_ARRAY_FAST;
> > spi_flash_addr(offset, cmd);
> > @@ -196,6 +237,14 @@ int spi_flash_cmd_erase(struct spi_flash *flash,
> u32 offset, size_t len)
> > int ret;
> > u8 cmd[4];
> >
> > + if (flash->size > 0x1000000) {
> > + ret =3D spi_flash_check_extaddr_access(flash, &offset);
> > + if (ret) {
> > + debug("SF: fail to acess ext_addr\n");
> > + return ret;
> > + }
> > + }
> > +
> > erase_size =3D flash->sector_size;
> > if (offset % erase_size || len % erase_size) {
> > debug("SF: Erase offset/length not multiple of erase size\n=
");
> @@
> > -333,6 +382,38 @@ int spi_flash_cmd_extaddr_read(struct spi_flash *flas=
h,
> void *data)
> > return spi_flash_read_common(flash, &cmd, 1, data, 1);
> > }
> >
> > +int spi_flash_extaddr_access(struct spi_flash *flash, u8 status) {
> > + int ret, pass;
> > + u8 data =3D 0, write_done =3D 0;
> > +
> > + for (pass =3D 0; pass < 2; pass++) {
> Why this is required??
>
> > + ret =3D spi_flash_cmd_extaddr_read(flash, (void *)&data);
> > + if (ret < 0) {
> > + debug("SF: fail to read ext addr register\n");
> > + return ret;
> > + }
> > +
> > + if ((data !=3D status) & !write_done) {
> > + debug("SF: need to %s ext addr bit\n",
> > + status ? "set" : "reset");
> > +
> > + write_done =3D 1;
> > + ret =3D spi_flash_cmd_extaddr_write(flash, status);=
> > + if (ret < 0) {
> > + debug("SF: fail to write ext addr bit\n");
> > + return ret;
> > + }
> > + } else {
> > + debug("SF: ext addr bit is %s.\n",
> > + status ? "set" : "reset");
> Instead of reading and writing this register each time (which will happen=
> often, if this function is called in the loops as suggested above), plea=
se
> cache the actual value inside struct spi_flash.
> Initial read should be done during probing and then writing only if the v=
alue
> needs to change.
> This is something depending on this design rule:
> http://www.denx.de/wiki/U-Boot/DesignPrinciples#2_Keep_it_Fast
But reading is also required a/f writing, whether the particular write is h=
appened properly or not?
The reason for 2 times loop is for code reduction.
The actual flow is first need to read the value and then write and finally =
read back whether the written
value is fine or not. So this entire flow requires 2 reads and 1 write.
I am adding loop for reduce the extra read code.
Any suggestions.
Thanks,
Jagan.
>
>
> > + return ret;
> > + }
> > + }
> > +
> > + return -1;
> > +}
> > +
> > /*
> > * The following table holds all device probe functions
> > *
> > diff --git a/drivers/mtd/spi/spi_flash_internal.h
> > b/drivers/mtd/spi/spi_flash_internal.h
> > index 65960ad..a6b04d7 100644
> > --- a/drivers/mtd/spi/spi_flash_internal.h
> > +++ b/drivers/mtd/spi/spi_flash_internal.h
> > @@ -34,6 +34,8 @@
> >
> > /* Common status */
> > #define STATUS_WIP 0x01
> > +#define STATUS_EXTADDR_ENABLE 0x01
> > +#define STATUS_EXTADDR_DISABLE 0x00
> As said above, don't restrict to a single bit!
>
> >
> > /* Send a single-byte command to the device and read the response */
> > int spi_flash_cmd(struct spi_slave *spi, u8 cmd, void *response,
> > size_t len); @@ -86,6 +88,12 @@ int spi_flash_cmd_extaddr_write(struct
> > spi_flash *flash, u8 ear);
> >
> > /* Read the extended address register */
> > int spi_flash_cmd_extaddr_read(struct spi_flash *flash, void *data);
> > +/*
> > + * Extended address access
> > + * access 4th byte address in 3-byte addessing mode for flashes
> > + * which has an actual size of > 16MB.
> > + */
> > +int spi_flash_extaddr_access(struct spi_flash *flash, u8 status);
> >
> > /*
> > * Same as spi_flash_cmd_read() except it also claims/releases the
> > SPI
> >
>
> Best Regards,
> Thomas
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-10-11 5:38 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2012-10-11 5:38 UTC (permalink / raw)
To: u-boot
force
make to use SHELL from the environment, even with export. The note about SH=
ELL
in "5.7.2 Communicating Variables to a Sub-make" can be misleading however.
Without "export SHELL", the recipes are executed with the set SHELL, but th=
e
default value of SHELL is in their environment.
With "export SHELL", the recipes are executed with the set SHELL, which is =
also
in their environment. But since the sub-make ignores its environment for SH=
ELL,
it does not help. That's probably why Linux uses CONFIG_SHELL (which means
nothing special to make) instead of SHELL.
So 1) is not a solution, and 4) also does not work. So we are left with 2),=
3)
or 5).
Best regards,
Beno=C3=AEt
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-10-11 5:38 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2012-10-11 5:38 UTC (permalink / raw)
To: u-boot
From: Simon Vanveerdeghem <simon.vanveerdeghem@barco.com>
Date: Mon, 4 Mar 2013 16:27:02 +0100
Subject: [PATCH] Add support for D-Link DUB-E100 h/w-rev C1
=20
=20
Signed-off-by: Simon Vanveerdeghem <simon.vanveerdeghem@barco.com>
---
drivers/usb/eth/asix.c | 2 ++
1 file changed, 2 insertions(+)
=20
diff --git a/drivers/usb/eth/asix.c b/drivers/usb/eth/asix.c
index 75ec8f7..ac22e59 100644
--- a/drivers/usb/eth/asix.c
+++ b/drivers/usb/eth/asix.c
@@ -602,6 +602,8 @@ static const struct asix_dongle const asix_dongles[]
=3D {
{ 0x2001, 0x3c05, FLAG_TYPE_AX88772 },
/* ASIX 88772B */
{ 0x0b95, 0x772b, FLAG_TYPE_AX88772B | FLAG_EEPROM_MAC },
+ /* DLink DUB-E100 H/W Ver C1 Alternate */
+ { 0x2001, 0x1a02, FLAG_TYPE_AX88772 },
{ 0x0000, 0x0000, FLAG_NONE } /* END - Do
not remove */
};
--=20
1.7.10.4
=20
DISCLAIMER:
Unless indicated otherwise, the information contained in this message is =
privileged and confidential, and is intended only for the use of the =
addressee(s) named above and others who have been specifically =
authorized to receive it. If you are not the intended recipient, you are =
hereby notified that any dissemination, distribution or copying of this =
message and/or attachments is strictly prohibited. The company accepts =
no liability for any damage caused by any virus transmitted by this =
email. Furthermore, the company does not warrant a proper and complete =
transmission of this information, nor does it accept liability for any =
delays. If you have received this message in error, please contact the =
sender and delete the message. Thank you.
------_=_NextPart_001_01CE1971.D9BC3630--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-10-11 5:38 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2012-10-11 5:38 UTC (permalink / raw)
To: u-boot
Acked-by: Simon Glass <sjg@chomium.org>
> ---
> Changes since v1:
> - Added sha256 support to "hash" command instead of new sha256 command.
>
> Changes sice v2:
> - Added new nodes for SHA1 and SHA256 in struct hash_algo for the case when ACE is enabled.
> - Added new declaration for function pointer hash_func_ws with different return type.
>
> Changes sice v3:
> - Changed command names to lower case in algo struct.
> - Added generic ace_sha config.
>
> Changes sice v4:
> - Changed function names in struct algo.
> - Replaced ACE_SHA_TYPE to CHUNSZ in struct algo.
>
> common/hash.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-10-11 5:38 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2012-10-11 5:38 UTC (permalink / raw)
To: u-boot
1. >dir/powerpc-440-linux-gnu-gdb
2. (gdb) set arch powerpc:common
3. (gdb) file u-boot
4. (gdb) target remote ipaddr:2001
(reset via BDI)
5. s or si
My initial step through will get me to "tlbtab_start" in board/dir/init.S.
and fail like this:
tlbnxt () at start.S:483
483 tlbnxt: addi r4,r4,1 /* Next TLB */
(gdb) s
484 bdnz rsttlb
(gdb) s
504 bl tlbtab /* Get tlbtab pointer */
(gdb) s
Cannot access memory at address 0x3f
(gdb) s
tlbtab () at init.S:43
43 tlbtab_start
Cannot access memory at address 0xfffff1f8
If I reset via BDI and step through again I'll receive the "Cannot access
memory at address " at what seems to be random spots.
I'm new to software development, especially at such a low level. Any advice
you may have would be greatly appreciated, I feel like I'm just spinning my
wheels at this point.
Thanks,
Greg
--e89a8ff249dd4b12ed04d7d3f8f6--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-10-11 5:38 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2012-10-11 5:38 UTC (permalink / raw)
To: u-boot
This patch adds support for Plan 9 to image.c; primarily a cosmetic change
when booting Plan 9 kernels using U-Boot.
---
common/image.c | 1 +
include/image.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/common/image.c b/common/image.c
index 6afbb40..60c2127 100644
--- a/common/image.c
+++ b/common/image.c
@@ -108,6 +108,7 @@ static const table_entry_t uimage_os[] = {
#endif
{ IH_OS_NETBSD, "netbsd", "NetBSD", },
{ IH_OS_OSE, "ose", "Enea OSE", },
+ { IH_OS_PLAN9, "plan9", "Plan 9", },
{ IH_OS_RTEMS, "rtems", "RTEMS", },
{ IH_OS_U_BOOT, "u-boot", "U-Boot", },
#if defined(CONFIG_CMD_ELF) || defined(USE_HOSTCC)
diff --git a/include/image.h b/include/image.h
index 8e285f9..4ad0e6b 100644
--- a/include/image.h
+++ b/include/image.h
@@ -84,6 +84,7 @@
#define IH_OS_UNITY 20 /* Unity OS */
#define IH_OS_INTEGRITY 21 /* INTEGRITY */
#define IH_OS_OSE 22 /* OSE */
+#define IH_OS_PLAN9 23 /* Plan 9 */
/*
* CPU Architecture Codes (supported by Linux)
--
1.8.2
--e89a8f92191c536a1f04d81a7088--
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2012-10-11 5:38 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2012-10-11 5:38 UTC (permalink / raw)
To: u-boot
Apologies for the second patch; I did not realize at the time that
modifications were needed for bootm to function correctly.
---
common/cmd_bootm.c | 39 +++++++++++++++++++++++++++++++++++++++
include/config_defaults.h | 1 +
2 files changed, 40 insertions(+)
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 5d2ce00..7438469 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -128,6 +128,9 @@ static boot_os_fn do_bootm_rtems;
#if defined(CONFIG_BOOTM_OSE)
static boot_os_fn do_bootm_ose;
#endif
+#if defined(CONFIG_BOOTM_PLAN9)
+static boot_os_fn do_bootm_plan9;
+#endif
#if defined(CONFIG_CMD_ELF)
static boot_os_fn do_bootm_vxworks;
static boot_os_fn do_bootm_qnxelf;
@@ -154,6 +157,9 @@ static boot_os_fn *boot_os[] = {
#if defined(CONFIG_BOOTM_OSE)
[IH_OS_OSE] = do_bootm_ose,
#endif
+#if defined(CONFIG_BOOTM_PLAN9)
+ [IH_OS_PLAN9] = do_bootm_plan9,
+#endif
#if defined(CONFIG_CMD_ELF)
[IH_OS_VXWORKS] = do_bootm_vxworks,
[IH_OS_QNX] = do_bootm_qnxelf,
@@ -1628,6 +1634,39 @@ static int do_bootm_ose(int flag, int argc, char *
const argv[],
}
#endif /* CONFIG_BOOTM_OSE */
+#if defined(CONFIG_BOOTM_PLAN9)
+static int do_bootm_plan9(int flag, int argc, char * const argv[],
+ bootm_headers_t *images)
+{
+ void (*entry_point)(void);
+
+ if ((flag != 0) && (flag != BOOTM_STATE_OS_GO))
+ return 1;
+
+#if defined(CONFIG_FIT)
+ if (!images->legacy_hdr_valid) {
+ fit_unsupported_reset("Plan 9");
+ return 1;
+ }
+#endif
+
+ entry_point = (void (*)(void))images->ep;
+
+ printf("## Transferring control to Plan 9 (at address %08lx) ...\n",
+ (ulong)entry_point);
+
+ bootstage_mark(BOOTSTAGE_ID_RUN_OS);
+
+ /*
+ * Plan 9 Parameters:
+ * None
+ */
+ (*entry_point)();
+
+ return 1;
+}
+#endif /* CONFIG_BOOTM_PLAN9 */
+
#if defined(CONFIG_CMD_ELF)
static int do_bootm_vxworks(int flag, int argc, char * const argv[],
bootm_headers_t *images)
diff --git a/include/config_defaults.h b/include/config_defaults.h
index d023c63..567b46c 100644
--- a/include/config_defaults.h
+++ b/include/config_defaults.h
@@ -12,6 +12,7 @@
/* Support bootm-ing different OSes */
#define CONFIG_BOOTM_LINUX 1
#define CONFIG_BOOTM_NETBSD 1
+#define CONFIG_BOOTM_PLAN9 1
#define CONFIG_BOOTM_RTEMS 1
#define CONFIG_GZIP 1
--
1.8.2
--047d7b86f76aa7765d04d82ce09c--
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2012-08-27 6:40 Simon Horman
0 siblings, 0 replies; 732+ messages in thread
From: Simon Horman @ 2012-08-27 6:40 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Hi Olaf,
please consider the following enhancements for the Armadillo800EVA board
from Laurent Pinchart for inclusion in 3.7.
I am currently in the processes of taking over maintenance
of shmoble from Rafael Wysocki and this my the first pull request
in that role.
----------------------------------------------------------------
The following changes since commit fea7a08acb13524b47711625eebea40a0ede69a0:
Linux 3.6-rc3 (2012-08-22 13:29:06 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git armadillo800eva
for you to fetch changes up to 5c1d2d16772e2d7d4e2e8da99a92d6f50b9102f0:
ARM: mach-shmobile: armadillo800eva: Enable power button as wakeup source (2012-08-25 15:44:53 +0900)
----------------------------------------------------------------
Laurent Pinchart (2):
ARM: mach-shmobile: armadillo800eva: Fix GPIO buttons descriptions
ARM: mach-shmobile: armadillo800eva: Enable power button as wakeup source
arch/arm/mach-shmobile/board-armadillo800eva.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-08-13 10:09 Vivek Panwar
0 siblings, 0 replies; 732+ messages in thread
From: Vivek Panwar @ 2012-08-13 10:09 UTC (permalink / raw)
To: kernelnewbies
HI,
How KGDB works internally or how a gdb stub works internally with source
code for x86_64 arch. Can some one please suggest me the good docs for the
same.I am very new to this so want know whole detailed internally working
procedure for KGDB.
Thanks
Vivek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120813/60e980ea/attachment.html
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-08-06 10:43 =?gb18030?B?wObC5A==?=
0 siblings, 0 replies; 732+ messages in thread
From: =?gb18030?B?wObC5A==?= @ 2012-08-06 10:43 UTC (permalink / raw)
To: kernelnewbies
hello i want to sabrit the mailist
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120806/8156c302/attachment.html
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-07-30 19:04 siddhesh phadke
0 siblings, 0 replies; 732+ messages in thread
From: siddhesh phadke @ 2012-07-30 19:04 UTC (permalink / raw)
To: kernelnewbies
I am newbie in nested KVM virtualization and I am trying to understand
the code for nested virtualization. I am not able to understand how
nested guest's ioctl calls are intercepted by KVM.Does each ioctl of
nested guest is intercepted by L0 or it is passed to L1?
Can anyone please help me with this or correct me if I am totally off the track?
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-06-21 18:26 Paul Walmsley
0 siblings, 0 replies; 732+ messages in thread
From: Paul Walmsley @ 2012-06-21 18:26 UTC (permalink / raw)
To: linux-arm-kernel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Tony
The following changes since commit 485802a6c524e62b5924849dd727ddbb1497cc71:
Linux 3.5-rc3 (2012-06-16 17:25:17 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-cleanup-a-for-3.6
for you to fetch changes up to 07b3a13957aa250ff5b5409b8ed756b113544112:
Merge branches 'clock_cleanup_misc_3.6', 'control_clean_dspbridge_writes_cleanup_3.6', 'hwmod_soc_conditional_cleanup_3.6', 'mcbsp_clock_aliases_cleanup_3.6' and 'remove_clkdm_requirement_from_hwmod_3.6' into omap_cleanup_a_3.6 (2012-06-20 20:11:36 -0600)
- ----------------------------------------------------------------
Some OMAP hwmod, clock, and System Control Module cleanup patches for 3.6.
- ----------------------------------------------------------------
Testing logs are available at
http://www.pwsan.com/omap/bootlogs/20120620/omap_cleanup_a_3.6__07b3a13957aa250ff5b5409b8ed756b113544112/
The summary is that 5912OSK NFS root and N800 MMC don't boot to
userspace; this broke between v3.4-rc2 and v3.5-rc3. 3517 boards are
still broken with NFS root and also several stack tracebacks during
boot. In terms of PM, core isn't entering idle on OMAP3 or OMAP4.
These problems all exist in v3.5-rc3 - they aren't caused by this
series.
object size (delta in bytes from v3.5-rc3 (485802a6c524e62b5924849dd727ddbb1497cc71)):
text data bss total kernel
0 0 0 0 5912osk_testconfig/vmlinux
+4636 -400 0 +4236 am33xx_testconfig/vmlinux
+440 -408 +32 +64 n800_multi_omap2xxx/vmlinux
+416 -192 +32 +256 n800_testconfig/vmlinux
0 0 0 0 omap1510_defconfig/vmlinux
0 0 0 0 omap1_defconfig/vmlinux
+732 -456 0 +276 omap2_4_testconfig/vmlinux
+4776 -624 0 +4152 omap2plus_defconfig/vmlinux
+684 -664 0 +20 omap2plus_no_pm/vmlinux
+616 -336 +64 +344 omap3_4_testconfig/vmlinux
+360 -384 0 -24 omap3_testconfig/vmlinux
+580 -120 +64 +524 omap4_testconfig/vmlinux
Kevin Hilman (7):
ARM: OMAP4: hwmod: rename _enable_module to _omap4_enable_module()
ARM: OMAP2+: hwmod: use init-time function ptrs for enable/disable module
ARM: OMAP4: hwmod: drop extra cpu_is check from _wait_target_disable()
ARM: OMAP2+: hwmod: use init-time function pointer for wait_target_ready
ARM: OMAP2+: hwmod: use init-time function pointer for hardreset
ARM: OMAP2+: hwmod: use init-time function pointer for _init_clkdm
ARM: OMAP2+: CLEANUP: Remove ARCH_OMAPx ifdef from struct dpll_data
Omar Ramirez Luna (2):
ARM: OMAP2+: control: new APIs to configure boot address and mode
ARM: OMAP: dsp: interface to control module functions
Paul Walmsley (2):
ARM: OMAP2+: hwmod: remove prm_clkdm, cm_clkdm; allow hwmods to have no clockdomain
Merge branches 'clock_cleanup_misc_3.6', 'control_clean_dspbridge_writes_cleanup_3.6', 'hwmod_soc_conditional_cleanup_3.6', 'mcbsp_clock_aliases_cleanup_3.6' and 'remove_clkdm_requirement_from_hwmod_3.6' into omap_cleanup_a_3.6
Peter Ujfalusi (3):
ARM: OMAP2: Move McBSP fck clock alias to hwmod data for OMAP2420
ARM: OMAP2: Move McBSP fck clock alias to hwmod data for OMAP2430
ARM: OMAP3: Move McBSP fck clock alias to hwmod data
arch/arm/mach-omap2/Makefile | 1 -
arch/arm/mach-omap2/clock2420_data.c | 4 -
arch/arm/mach-omap2/clock2430_data.c | 10 -
arch/arm/mach-omap2/clock3xxx_data.c | 10 -
arch/arm/mach-omap2/clockdomain.h | 2 -
arch/arm/mach-omap2/clockdomains2420_data.c | 2 -
arch/arm/mach-omap2/clockdomains2430_data.c | 2 -
arch/arm/mach-omap2/clockdomains3xxx_data.c | 2 -
arch/arm/mach-omap2/clockdomains44xx_data.c | 2 -
arch/arm/mach-omap2/clockdomains_common_data.c | 24 --
arch/arm/mach-omap2/control.c | 43 ++
arch/arm/mach-omap2/control.h | 2 +
arch/arm/mach-omap2/dsp.c | 4 +
.../include/mach/ctrl_module_core_44xx.h | 1 +
arch/arm/mach-omap2/omap_hwmod.c | 427 ++++++++++++++------
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 10 +
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 16 +
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 23 ++
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 4 +-
arch/arm/plat-omap/include/plat/clock.h | 2 -
arch/arm/plat-omap/include/plat/dsp.h | 3 +
arch/arm/plat-omap/include/plat/omap_hwmod.h | 2 +
22 files changed, 409 insertions(+), 187 deletions(-)
delete mode 100644 arch/arm/mach-omap2/clockdomains_common_data.c
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAEBAgAGBQJP42cFAAoJEMePsQ0LvSpLmMAP/06LRRSFBPklr2hDmFPKBfBD
guF3rAN5zimEyknXp1RhoHJjcH0YCkUdQgD24w51yVwVB9zVW0M6G9hVi91cJj9X
1StRIwTbtb08yPdOlpywEXzHpjXz3AauCMRRxYJHi0FjajwHNKWWv+A/iolM0p8P
5o5ZY+D3AzJqfX/+A0FK2YKn2Z7X9kxg8uTTukhXhe38ldZJ2pHqA4ND2n2F+GnD
DUGqpnYu+QLTmw0x0NbpTNDarnmUEa/tH1NRny5Fh+ujYxH5NPTVvxHTW8tbm5bl
qkleWJaDc+D2pCnD3ch3cUlLgIfTZbo4KUg+Y4uv4QLrLx/QTu6TpyJaP+ZJw3sY
amakgmv3vzYzHMOf/0gxIe6xDZl6YFVXiOdJex4kQ5qodXRgmh82gYUrEKLLHuWn
+EKwIBM8xV5zYzA60vZ05ul7QqeNfwD5D6dd5As96QweVJFMGiIDWINGfxOtI/mH
ygXD6sSZvYhqGk2EVb+hje971urmI4aIrolt/xB4anOATiehaJuwhLjtp+5ZO7tL
5w3bybiUqKh+CN0DlpL/Srw0jaVp/pjZE8+4tzw/Mvm5T8wSVZL2ysJfmX4WffKl
k7RI46jiiQfFLJbSF5pgXUEm00/Ut3g7otp2F+iZLuAplJwoojl7cgezTSAgRc9E
Rhv07SsL5AAZ5OyCOdeQ
=rQK5
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-06-06 10:33 Sascha Hauer
0 siblings, 0 replies; 732+ messages in thread
From: Sascha Hauer @ 2012-06-06 10:33 UTC (permalink / raw)
To: linux-arm-kernel
The following adds i.MX53 nand support and generally devicetree
based probing for i.MX5 boards. The first three patches should go
via mtd, the last patch optionally aswell if all agree.
Sascha
The following changes since commit f8f5701bdaf9134b1f90e5044a82c66324d2073f:
Linux 3.5-rc1 (2012-06-02 18:29:26 -0700)
are available in the git repository at:
git://git.pengutronix.de/git/imx/linux-2.6.git imx/nand-mx53
for you to fetch changes up to d55d1479a3bfaedbb9f0c6c956f4dff6bb6d6d61:
ARM i.MX5: Add nand oftree support (2012-06-06 12:20:24 +0200)
----------------------------------------------------------------
Sascha Hauer (4):
mtd nand mxc_nand: Use managed resources
mtd nand mxc_nand: swap iomem resource order
mtd nand mxc_nand: add i.MX53 support
ARM i.MX5: Add nand oftree support
arch/arm/boot/dts/imx51.dtsi | 7 ++
arch/arm/boot/dts/imx53.dtsi | 7 ++
arch/arm/mach-imx/clk-imx51-imx53.c | 2 +
arch/arm/plat-mxc/devices/platform-mxc_nand.c | 11 +-
drivers/mtd/nand/mxc_nand.c | 137 ++++++++++++++-----------
5 files changed, 97 insertions(+), 67 deletions(-)
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-05-25 15:26 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2012-05-25 15:26 UTC (permalink / raw)
To: ath9k-devel
"enabled" in the device driver. I will scour the ath9k source code for
this config.
=20
Thank you for your input.
=20
Hasan R.
=20
=20
From: adrian.chadd@gmail.com [mailto:adrian.chadd at gmail.com] On Behalf
Of Adrian Chadd
Sent: Sunday, May 27, 2012 7:18 PM
To: Hasan Rashid
Cc: ath9k-devel at lists.ath9k.org
Subject: Re: [ath9k-devel] Atheros AR9382 W_DISABLE_L PIN 20 Mini-PCIe
=20
Hi,
=20
So the 30 second version of rfkill is this:
=20
* it can be software driven (ie, the driver implements rfkill by
stopping TX/RX and baseband activity, possibly shutting down the NIC)
* it can be hardware driven (ie, there's an RFKill line to the NIC via=
a
GPIO pin)
=20
The pin itself can be controlled by:
=20
* hardware - ie, a physical switch to the rfkill pin;
* software - ie, some ACPI controlled function maps to the rfkill pin.
=20
What you have above seems to be (2) and (1) respectively - ie, that pin
is mapped to GPIO7 on the NIC, and now you need to program GPIO7 to be
an RFkill pin. There's code in ath9k somewhere to configure the GPIO pin
correctly to implement hardware rfkill.
=20
Good luck!
=20
=20
Adrian
This communication contains information that may be confidential or priv=
ileged. The information is solely intended for the use of the addressee.=
If you are not the intended recipient, be advised that any disclosure,=
copy, distribution, or use of the contents of this communication is pro=
hibited. If you have received this communication in
error, please immediately notify the sender by telephone or by electroni=
c mail.
------_=_NextPart_001_01CD3DB5.D3C19EF1
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-m=
icrosoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:=
word" xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=
=3D"http://www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-Ty=
pe content=3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator cont=
ent=3D"Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue=
vlink=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span sty=
le=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'=
From your email I gather I have a RFKILL switch but it needs to be R=
20;enabled” in the device driver. I will scour the ath9k sou=
rce code for this config.<o:p></o:p></span></p><p class=3DMsoNormal><spa=
n style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F=
497D'><o:p> </o:p></span></p><p class=3DMsoNormal><span style=3D'fo=
nt-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Thank=
you for your input.<o:p></o:p></span></p><p class=3DMsoNormal><span sty=
le=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D'><=
o:p> </o:p></span></p><p class=3DMsoNormal><span style=3D'font-size=
:10.0pt;font-family:"Arial","sans-serif";color:#1F497D'>Hasan R.<o:p></o=
:p></span></p><p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-=
family:"Arial","sans-serif";color:#1F497D'> <o:p></o:p></span></p><=
p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial",=
"sans-serif";color:#1F497D'> </span><span style=3D'font-size:11.0pt=
;font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p=
><p class=3DMsoNormal style=3D'margin-left:.5in'><b><span style=3D'font-=
size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span sty=
le=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> adrian.chadd@=
gmail.com [mailto:adrian.chadd at gmail.com] <b>On Behalf Of </b>Adrian Cha=
dd<br><b>Sent:</b> Sunday, May 27, 2012 7:18 PM<br><b>To:</b> Hasan Rash=
id<br><b>Cc:</b> ath9k-devel at lists.ath9k.org<br><b>Subject:</b> Re: [ath=
9k-devel] Atheros AR9382 W_DISABLE_L PIN 20 Mini-PCIe<o:p></o:p></span><=
/p><p class=3DMsoNormal style=3D'margin-left:.5in'><o:p> </o:p></p>=
<p class=3DMsoNormal style=3D'margin-left:.5in'>Hi,<o:p></o:p></p><div><=
p class=3DMsoNormal style=3D'margin-left:.5in'><o:p> </o:p></p></di=
v><div><p class=3DMsoNormal style=3D'margin-left:.5in'>So the 30 second=
version of rfkill is this:<o:p></o:p></p></div><div><p class=3DMsoNorma=
l style=3D'margin-left:.5in'><o:p> </o:p></p></div><div><p class=3D=
MsoNormal style=3D'margin-left:.5in'>* it can be software driven (ie,=
the driver implements rfkill by stopping TX/RX and baseband activity,=
possibly shutting down the NIC)<o:p></o:p></p></div><div><p class=3DMso=
Normal style=3D'margin-left:.5in'>* it can be hardware driven (ie, there=
's an RFKill line to the NIC via a GPIO pin)<o:p></o:p></p></div><div><p=
class=3DMsoNormal style=3D'margin-left:.5in'><o:p> </o:p></p></div=
><div><p class=3DMsoNormal style=3D'margin-left:.5in'>The pin itself can=
be controlled by:<o:p></o:p></p></div><div><p class=3DMsoNormal style=
=3D'margin-left:.5in'><o:p> </o:p></p></div><div><p class=3DMsoNorm=
al style=3D'margin-left:.5in'>* hardware - ie, a physical switch to the=
rfkill pin;<o:p></o:p></p></div><div><p class=3DMsoNormal style=3D'marg=
in-left:.5in'>* software - ie, some ACPI controlled function maps to the=
rfkill pin.<o:p></o:p></p></div><div><p class=3DMsoNormal style=3D'marg=
in-left:.5in'><o:p> </o:p></p></div><div><p class=3DMsoNormal style=
=3D'margin-left:.5in'>What you have above seems to be (2) and (1) respec=
tively - ie, that pin is mapped to GPIO7 on the NIC, and now you need=
to program GPIO7 to be an RFkill pin. There's code in ath9k somewhere=
to configure the GPIO pin correctly to implement hardware rfkill.<o:p><=
/o:p></p></div><div><p class=3DMsoNormal style=3D'margin-left:.5in'><o:p=
> </o:p></p></div><div><p class=3DMsoNormal style=3D'margin-left:.5=
in'>Good luck!<o:p></o:p></p></div><div><p class=3DMsoNormal style=3D'ma=
rgin-left:.5in'><o:p> </o:p></p></div><div><p class=3DMsoNormal sty=
le=3D'margin-left:.5in'><o:p> </o:p></p></div><div><p class=3DMsoNo=
rmal style=3D'margin-left:.5in'>Adrian<o:p></o:p></p></div></div>
<!-- Begin Ninja Disclaimer ID 06d1f63c-a7f2-4bdd-9832-359e6e93159e -->
<P>This communication contains information that may be confidential or=
privileged. The information is solely intended for the use of the addre=
ssee. If you are not the intended recipient, be advised that any disclos=
ure, copy, distribution, or use of the contents of this communication=
is prohibited. If you have received this communication in<BR>error, ple=
ase immediately notify the sender by telephone or by electronic mail.</P>
<P>Export Notice: This email may contain technical data controlled under=
the International Traffic in Arms Regulations (ITAR) by the U.S.=
Department of State (22 CFR 120-130) or under the U.S Export Administra=
tion Regulations (EAR) by the Department of Commerce (15 CFR 730-744).&n=
bsp; Violations of these export laws are subject to severe criminal pena=
lties. <BR></P>
</body></html>
------_=_NextPart_001_01CD3DB5.D3C19EF1--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-05-25 15:26 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2012-05-25 15:26 UTC (permalink / raw)
To: ath9k-devel
it being NULL along the way"
I guess you refer to the comment in mac80211.h, struct tx_info that I
removed:
- * The TX control's sta pointer is only valid during the ->tx call,
- * it may be NULL.
I am not sure what you want me to keep here as comment. As the sta
pointer is moved into the new struct tx_control and the remaining
pointers in the tx_info->control structure (vif, hw_key) are ALL only
valid during the ->tx call and may be NULL. So I could think of adding a
comment to tx_control about the sta been NULL, but anything more ?
>> The tx-path of all affected drivers is restructured to respect the
chaneged
>> layout of struct ieee80211_tx_info. List of modified drivers:
>> ath9k
>
> Please also remove the driver list. git can tell you the modified files
> very easily.
Will do so in v2.
Greetings Thomas
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-05-18 12:27 Sascha Hauer
0 siblings, 0 replies; 732+ messages in thread
From: Sascha Hauer @ 2012-05-18 12:27 UTC (permalink / raw)
To: linux-arm-kernel
Hi All,
The following adds a drm/kms driver for the Freescale i.MX LCDC
controller. Most notable change to the last SDRM based version is that
the SDRM layer has been removed and the driver now is purely i.MX
specific. I hope that this is more acceptable now.
Another change is that the probe is now devicetree based. For now I
took the easy way out and only put an edid blob into the devicetree.
I haven't documented the binding yet, I would add that when the rest
is considered ok.
Comments very welcome.
Thanks
Sascha
----------------------------------------------------------------
Sascha Hauer (2):
DRM: add Freescale i.MX LCDC driver
pcm038 lcdc support
arch/arm/boot/dts/imx27-phytec-phycore.dts | 39 ++
arch/arm/boot/dts/imx27.dtsi | 7 +
arch/arm/mach-imx/clock-imx27.c | 1 +
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/imx/Kconfig | 18 +
drivers/gpu/drm/imx/Makefile | 8 +
drivers/gpu/drm/imx/imx-drm-core.c | 745 ++++++++++++++++++++++++++++
drivers/gpu/drm/imx/imx-fb.c | 179 +++++++
drivers/gpu/drm/imx/imx-fbdev.c | 275 ++++++++++
drivers/gpu/drm/imx/imx-gem.c | 343 +++++++++++++
drivers/gpu/drm/imx/imx-lcdc-crtc.c | 517 +++++++++++++++++++
drivers/gpu/drm/imx/imx-parallel-display.c | 228 +++++++++
13 files changed, 2363 insertions(+)
create mode 100644 drivers/gpu/drm/imx/Kconfig
create mode 100644 drivers/gpu/drm/imx/Makefile
create mode 100644 drivers/gpu/drm/imx/imx-drm-core.c
create mode 100644 drivers/gpu/drm/imx/imx-fb.c
create mode 100644 drivers/gpu/drm/imx/imx-fbdev.c
create mode 100644 drivers/gpu/drm/imx/imx-gem.c
create mode 100644 drivers/gpu/drm/imx/imx-lcdc-crtc.c
create mode 100644 drivers/gpu/drm/imx/imx-parallel-display.c
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
2012-04-10 16:08 ` Vladimir Murzin
@ 2012-04-10 17:00 ` Semen Martynov
0 siblings, 0 replies; 732+ messages in thread
From: Semen Martynov @ 2012-04-10 17:00 UTC (permalink / raw)
To: kernelnewbies
Yes, this is it! Thank you!
10.04.2012, 20:08, "Vladimir Murzin" <murzin.v@gmail.com>:
> On Tue, Apr 10, 2012 at 10:48:14AM +0600, Martynov Semen wrote:
>
>> ?<one more time in plain text>
>>
>> ?Yes, of course.
>> ?It contains only one line:
>>
>> ?obj-$(CONFIG_MY_PROCLISTOUTPUT) += proclistoutput.o
>>
>> ?and works with Kconfig
>>
>> ?config MY_PROCLISTOUTPUT
>> ?????tristate "Display a list of processes"
>> ?????default y
>> ?????---help---
>> ??????This module prints a list of processes
>>
>> ?But I'm sure that the reason is not in my file, because:
>> ?- If I put my code in a folder /drivers (and include my Makefile and Kconfig) then everything works perfectly (I can build kernel object and I can built-in my code to the kernel)
>> ?- If I put my code in a folder /samples (and include my Makefile and Kconfig) then build-in the code I can't, but with .ko it works fine...
>>
>> ?I suppose that the reason in the kernel Makefile. The root Makefile contains this code (http://lxr.free-electrons.com/source/Makefile#L914)
>>
>> ?ifdef CONFIG_SAMPLES
>> ??????????$(Q)$(MAKE) $(build)=samples
>> ?endif
>>
>> ?where
>> ?$(Q) = @
>> ?$(build) = -f scripts/Makefile.build obj
>>
>> ?and further I lose understanding of the events...
>>
>> ?10.04.2012, 08:26, "Vladimir Murzin" <murzin.v@gmail.com>:
>>> ?Hi Semen
>>>
>>> ?Could you share a Makefile for your module?
>>>
>>> ?Best wishes,
>>> ?Vladimir Murzin
>>>
>>> ?-----Original Message-----
>>> ?From: Martynov Semen <semen-martynov@yandex.ru>
>>> ?Sender: kernelnewbies-bounces at kernelnewbies.org
>>> ?Date: Mon, 09 Apr 2012 23:56:15
>>> ?To: kernelnewbies at kernelnewbies.org<kernelnewbies@kernelnewbies.org>
>>> ?Subject: No subject
>>>
>>> ?Good afternoon,
>>>
>>> ?I would like to understand, why I can't make the built-in object, when my code is in a folder /samples...
>>>
>>> ?I have my module-code and if I put it in a folder /samples, I can receive only loadable module (.ko) but if I want to receive the built-in object - it turns out nothing (.?-file is created, but my code doesn't get in a kernel). When I allocate my module-code in any other folder (for example, /drivers) it works normally - I can receive .ko and I can make the built-in object.
>>>
>>> ?Question - why I can't receive the built-in object when my code is in the folder /samples? What instruction in a make-file restricts it, and how?
>>>
>>> ?P.S.: Sorry for my english.
>>> ?--
>>> ?Best regards,
>>> ?Semen A Martynov.
>>>
>>> ?Saint Petersburg, Russia.
>>> ?https://www.facebook.com/semen.martynov
>>>
>>> ?_______________________________________________
>>> ?Kernelnewbies mailing list
>>> ?Kernelnewbies at kernelnewbies.org
>>> ?http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>> ?--
>>
>> ?? ?? Facebook: http://www.facebook.com/profile.php?id=1095131825
>
> Hi Semen
>
> It happens because ./script isn't listed as a subdir for visiting and
> linking objects into vmlinux. Please, refer to [1] for details.
>
> [1] http://lxr.linux.no/linux+*/Makefile#L508
>
> Best wishes,
> Vladimir Murzin
--
Best regards,
Semen A Martynov.
Saint Petersburg, Russia.
https://www.facebook.com/semen.martynov
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
2012-04-10 4:48 ` Martynov Semen
@ 2012-04-10 16:08 ` Vladimir Murzin
2012-04-10 17:00 ` Semen Martynov
0 siblings, 1 reply; 732+ messages in thread
From: Vladimir Murzin @ 2012-04-10 16:08 UTC (permalink / raw)
To: kernelnewbies
On Tue, Apr 10, 2012 at 10:48:14AM +0600, Martynov Semen wrote:
> <one more time in plain text>
>
> Yes, of course.
> It contains only one line:
>
> obj-$(CONFIG_MY_PROCLISTOUTPUT) += proclistoutput.o
>
> and works with Kconfig
>
> config MY_PROCLISTOUTPUT
> tristate "Display a list of processes"
> default y
> ---help---
> This module prints a list of processes
>
>
> But I'm sure that the reason is not in my file, because:
> - If I put my code in a folder /drivers (and include my Makefile and Kconfig) then everything works perfectly (I can build kernel object and I can built-in my code to the kernel)
> - If I put my code in a folder /samples (and include my Makefile and Kconfig) then build-in the code I can't, but with .ko it works fine...
>
> I suppose that the reason in the kernel Makefile. The root Makefile contains this code (http://lxr.free-electrons.com/source/Makefile#L914)
>
> ifdef CONFIG_SAMPLES
> $(Q)$(MAKE) $(build)=samples
> endif
>
> where
> $(Q) = @
> $(build) = -f scripts/Makefile.build obj
>
> and further I lose understanding of the events...
>
>
> 10.04.2012, 08:26, "Vladimir Murzin" <murzin.v@gmail.com>:
> > Hi Semen
> >
> > Could you share a Makefile for your module?
> >
> > Best wishes,
> > Vladimir Murzin
> >
> > -----Original Message-----
> > From: Martynov Semen <semen-martynov@yandex.ru>
> > Sender: kernelnewbies-bounces at kernelnewbies.org
> > Date: Mon, 09 Apr 2012 23:56:15
> > To: kernelnewbies at kernelnewbies.org<kernelnewbies@kernelnewbies.org>
> > Subject: No subject
> >
> > Good afternoon,
> >
> > I would like to understand, why I can't make the built-in object, when my code is in a folder /samples...
> >
> > I have my module-code and if I put it in a folder /samples, I can receive only loadable module (.ko) but if I want to receive the built-in object - it turns out nothing (.?-file is created, but my code doesn't get in a kernel). When I allocate my module-code in any other folder (for example, /drivers) it works normally - I can receive .ko and I can make the built-in object.
> >
> > Question - why I can't receive the built-in object when my code is in the folder /samples? What instruction in a make-file restricts it, and how?
> >
> > P.S.: Sorry for my english.
> > --
> > Best regards,
> > Semen A Martynov.
> >
> > Saint Petersburg, Russia.
> > https://www.facebook.com/semen.martynov
> >
> > _______________________________________________
> > Kernelnewbies mailing list
> > Kernelnewbies at kernelnewbies.org
> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> --
>
>
> ? ?? Facebook: http://www.facebook.com/profile.php?id=1095131825
Hi Semen
It happens because ./script isn't listed as a subdir for visiting and
linking objects into vmlinux. Please, refer to [1] for details.
[1] http://lxr.linux.no/linux+*/Makefile#L508
Best wishes,
Vladimir Murzin
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
2012-04-10 2:26 ` Vladimir Murzin
2012-04-10 4:03 ` Martynov Semen
@ 2012-04-10 4:48 ` Martynov Semen
2012-04-10 16:08 ` Vladimir Murzin
1 sibling, 1 reply; 732+ messages in thread
From: Martynov Semen @ 2012-04-10 4:48 UTC (permalink / raw)
To: kernelnewbies
<one more time in plain text>
Yes, of course.
It contains only one line:
obj-$(CONFIG_MY_PROCLISTOUTPUT) += proclistoutput.o
and works with Kconfig
config MY_PROCLISTOUTPUT
tristate "Display a list of processes"
default y
---help---
This module prints a list of processes
But I'm sure that the reason is not in my file, because:
- If I put my code in a folder /drivers (and include my Makefile and Kconfig) then everything works perfectly (I can build kernel object and I can built-in my code to the kernel)
- If I put my code in a folder /samples (and include my Makefile and Kconfig) then build-in the code I can't, but with .ko it works fine...
I suppose that the reason in the kernel Makefile. The root Makefile contains this code (http://lxr.free-electrons.com/source/Makefile#L914)
ifdef CONFIG_SAMPLES
$(Q)$(MAKE) $(build)=samples
endif
where
$(Q) = @
$(build) = -f scripts/Makefile.build obj
and further I lose understanding of the events...
10.04.2012, 08:26, "Vladimir Murzin" <murzin.v@gmail.com>:
> Hi Semen
>
> Could you share a Makefile for your module?
>
> Best wishes,
> Vladimir Murzin
>
> -----Original Message-----
> From: Martynov Semen <semen-martynov@yandex.ru>
> Sender: kernelnewbies-bounces at kernelnewbies.org
> Date: Mon, 09 Apr 2012 23:56:15
> To: kernelnewbies at kernelnewbies.org<kernelnewbies@kernelnewbies.org>
> Subject: No subject
>
> Good afternoon,
>
> I would like to understand, why I can't make the built-in object, when my code is in a folder /samples...
>
> I have my module-code and if I put it in a folder /samples, I can receive only loadable module (.ko) but if I want to receive the built-in object - it turns out nothing (.?-file is created, but my code doesn't get in a kernel). When I allocate my module-code in any other folder (for example, /drivers) it works normally - I can receive .ko and I can make the built-in object.
>
> Question - why I can't receive the built-in object when my code is in the folder /samples? What instruction in a make-file restricts it, and how?
>
> P.S.: Sorry for my english.
> --
> Best regards,
> Semen A Martynov.
>
> Saint Petersburg, Russia.
> https://www.facebook.com/semen.martynov
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
--
? ?? Facebook: http://www.facebook.com/profile.php?id=1095131825
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
2012-04-10 2:26 ` Vladimir Murzin
@ 2012-04-10 4:03 ` Martynov Semen
2012-04-10 4:48 ` Martynov Semen
1 sibling, 0 replies; 732+ messages in thread
From: Martynov Semen @ 2012-04-10 4:03 UTC (permalink / raw)
To: kernelnewbies
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120410/f5f9ee0c/attachment.html
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
2012-04-09 17:56 Martynov Semen
@ 2012-04-10 2:26 ` Vladimir Murzin
2012-04-10 4:03 ` Martynov Semen
2012-04-10 4:48 ` Martynov Semen
0 siblings, 2 replies; 732+ messages in thread
From: Vladimir Murzin @ 2012-04-10 2:26 UTC (permalink / raw)
To: kernelnewbies
Hi Semen
Could you share a Makefile for your module?
Best wishes,
Vladimir Murzin
-----Original Message-----
From: Martynov Semen <semen-martynov@yandex.ru>
Sender: kernelnewbies-bounces at kernelnewbies.org
Date: Mon, 09 Apr 2012 23:56:15
To: kernelnewbies at kernelnewbies.org<kernelnewbies@kernelnewbies.org>
Subject: No subject
Good afternoon,
I would like to understand, why I can't make the built-in object, when my code is in a folder /samples...
I have my module-code and if I put it in a folder /samples, I can receive only loadable module (.ko) but if I want to receive the built-in object - it turns out nothing (.?-file is created, but my code doesn't get in a kernel). When I allocate my module-code in any other folder (for example, /drivers) it works normally - I can receive .ko and I can make the built-in object.
Question - why I can't receive the built-in object when my code is in the folder /samples? What instruction in a make-file restricts it, and how?
P.S.: Sorry for my english.
--
Best regards,
Semen A Martynov.
Saint Petersburg, Russia.
https://www.facebook.com/semen.martynov
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies at kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-04-09 17:56 Martynov Semen
2012-04-10 2:26 ` Vladimir Murzin
0 siblings, 1 reply; 732+ messages in thread
From: Martynov Semen @ 2012-04-09 17:56 UTC (permalink / raw)
To: kernelnewbies
Good afternoon,
I would like to understand, why I can't make the built-in object, when my code is in a folder /samples...
I have my module-code and if I put it in a folder /samples, I can receive only loadable module (.ko) but if I want to receive the built-in object - it turns out nothing (.?-file is created, but my code doesn't get in a kernel). When I allocate my module-code in any other folder (for example, /drivers) it works normally - I can receive .ko and I can make the built-in object.
Question - why I can't receive the built-in object when my code is in the folder /samples? What instruction in a make-file restricts it, and how?
P.S.: Sorry for my english.
--
Best regards,
Semen A Martynov.
Saint Petersburg, Russia.
https://www.facebook.com/semen.martynov
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-04-05 7:54 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2012-04-05 7:54 UTC (permalink / raw)
To: ath9k-devel
relative to noise floor in dB."
Adrian
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-04-05 7:54 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2012-04-05 7:54 UTC (permalink / raw)
To: ath9k-devel
relative to noise floor in dB."<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
<br>
Adrian<br>
</font></span></blockquote></div><br></div>
--bcaec52be6d10f215404c0d1b26d--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-03-20 18:28 John Szakmeister
0 siblings, 0 replies; 732+ messages in thread
From: John Szakmeister @ 2012-03-20 18:28 UTC (permalink / raw)
To: linux-arm-kernel
We've been running into several issues on the cache flushing front,
and I'm hoping that someone here can help clarify what should be
happening from a kernel perspective.
Late last year we discovered a few interesting problems. One of them
is definitely our fault: we weren't flushing the cache after we read
data from a block device a wrote it into the page. However, there was
another issue we noticed that made less sense: we had to flush a page
before writing it to our block device, otherwise we end up writing
some stale data. The brd device ran into this issue before, and fixed
it in commit c2572f2b[1]. In that commit Nick Pidgin says:
"brd is missing a flush_dcache_page. On 2nd thoughts, perhaps it is the
pagecache's responsibility to flush user virtual aliases (the driver of
course should flush kernel virtual mappings)... but anyway, there
already exists cache flushing for one direction of transfer, so we
should add the other."
I can't help but to feel he's right. It was very surprising to me
that I had to flush the user virtual aliases before writing the data
to the device. Is it expected that we (as device driver writers) have
to do that for block device drivers? I love Linux, but one of the
aspects I find most frustrating is that I don't know what I can safely
assume at interface boundaries. Even modeling my work after existing
code yields problems, because a number of drivers in the tree seem to
be broken in this regard.
But it leads to another concern. Since I do have to flush on writes,
it got me thinking about whether it's necessary to flush user mode
aliases before conducting a read. Consider the fact that a page can
span multiple blocks. Is it possible that:
* we're asked to read a block of data
* a user app has scribbled on the page (so it's dirty, but not flushed)
* we read the requested data from the device
* load it into the page
* do a flush_dcache_page()
* then the data read from the device becomes corrupt because cached user data
is written to RAM?
Or, instead of that, the cached data gets dropped entirely because it
was on the page, but shouldn't have been because we didn't read new
data into that area, and now that user data is lost? I confess this
may all be my lack of understanding about Linux's block i/o subsystem,
but I'm thoroughly confused at this point. What I do know is that
other device drivers are not flushing the page before writing the data
to a device. For instance, the mmc driver for the at91 architecture
suffers from this problem, and I've been able to see that problem
using mmap. My concern is that many other drivers also suffer from
this problem, so I'm not sure what the fix needs to be: fix the page
cache, fix the driver, or both.
Also, is there somewhere that says what's guaranteed on entry into my
block device driver? I've scoured everything I could find... the
Documentation area (including cachetlb.txt), Linux sites, books...
I've yet to find anything mentioning the need to call
flush_dcache_page() much less talk about what the assumptions are.
Thanks in advance for the help.
-John
[1]: <http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=c2572f2b4ffc27ba79211aceee3bef53a59bb5cd>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-02-27 5:00 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2012-02-27 5:00 UTC (permalink / raw)
To: ath9k-devel
actually useful for narrowing down the source of this issue...
- Felix
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-02-27 5:00 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2012-02-27 5:00 UTC (permalink / raw)
To: ath9k-devel
The lower you go on the level of abstraction, the more data any kind of
debugging approach generates, meaning way more effort to analyze the
data and make sense of it.
I don't typically start with the part that's hardest to analyze. High
level states are easier to look into and make sense of, so they're also
easier to rule out.
Code review is also a very good starting point. I actually found and
fixed more user visible bugs through code review than any other
debugging method.
>> > but hardware development information in the community is not
>> > really available.
>>
>> I found that people that have shown enough interest in improving ath9k
>> and have proven to be experienced in working on such drivers tend to get
>> access to documentation.
>
> Well, let's say that in my experience the threshold for "approval"
> was set too high. As I said, and as you may remember, I was
> repeatedly shot down or ignored, offering to try to get to the bottom
> of the issues. I understand now that it may not really be legally
> possible for Atheros to provide the information that is actually
> required to get to the bottom of the issues, but that makes working
> on the driver too inefficient.
Most issues can be fixed with a good understanding of the code alone,
detailed hardware knowledge is often not as important.
This isn't unique to ath9k. I've fixed bugs in other drivers as well
without having any form of hardware documentation, because I'm able to
read and understand code and my brain can handle a bit of complexity.
>> > Being told to try to reverse engineer the hardware using the
>> > driver source code or any other source code does not qualify.
>>
>> Your definition of 'reverse engineering' is quite funny.
>
> There's not just one type of reverse engineering.
>
> Suggesting hardware reverse engineering in an open source driver
> development effort is, well, not what I expect.
>
>
>> To me it looks somewhat ridiculous that you claim to know better what's
>> required to debug this issue than people working with the hardware on a
>> daily basis (Adrian, Mohammed, me).
>
> I've developed both hardware and software for more than 20 years, and
> neither problems nor solutions have changed much, so I think I still
> have a clue.
OK, so let me get this straight: You can't imagine how the test result
from disabling PS could be useful for tracking down the problem, so you
automatically assume that it *must* be a lame workaround suggestion?
That seems rather narrow-minded of you.
Of course I can see multiple ways in which this information would be
useful, but I guess that may not matter to you.
- Felix
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-02-27 5:00 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2012-02-27 5:00 UTC (permalink / raw)
To: ath9k-devel
;f=3Dhostapd/hostapd.conf), I
cannot find what wme_enabled is.
=20
- What does wme_enabled do ? Is it needed in conjunction with =
ht_capab ?
Another question, I live in CH, a reboot shows=20
[ 9.201363] ath: Country alpha2 being used: AU
And changed it to CH.=20
=20
- Which limitation can I expect, for not being a European Card, =
as it propagates AU ?
=20
Below I added lspci, iw list, hostapd.conf, dmesg output.
http://www.tp-link.com/en/products/details/?model=3DTL-WDN4800#spec
=20
Thanks for your help
Angela
=20
# lspci -vvd 168c:
02:00.0 Network controller: Atheros Communications Inc. AR9300 Wireless =
LAN adaptor (rev 01)
Subsystem: Atheros Communications Inc. Device 3112
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- =
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfast >TAbort- =
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 17
Region 0: Memory at fbe00000 (64-bit, non-prefetchable) =
[size=3D128K]
Expansion ROM at fbe20000 [disabled] [size=3D64K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1+ D2- AuxCurrent=3D375mA =
PME(D0+,D1+,D2-,D3hot+,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=3D0 DScale=3D0 =
PME-
Capabilities: [50] MSI: Enable- Count=3D1/4 Maskable+ 64bit+
Address: 0000000000000000 Data: 0000
Masking: 00000000 Pending: 00000000
Capabilities: [70] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s =
<1us, L1 <8us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- =
Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- =
TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, =
Latency L0 <2us, L1 <64us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- =
CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ =
DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Not Supported, TimeoutDis+
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- =
SpeedDis-, Selectable De-emphasis: -6dB
Transmit Margin: Normal Operating Range, =
EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- =
UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- =
UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- =
UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- =
NonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- =
NonFatalErr+
AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- =
ChkEn-
Capabilities: [140 v1] Virtual Channel
Caps: LPEVC=3D0 RefClk=3D100ns PATEntryBits=3D1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=3DFixed
Status: InProgress-
VC0: Caps: PATOffset=3D00 MaxTimeSlots=3D1 =
RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- =
WRR256-
Ctrl: Enable+ ID=3D0 ArbSelect=3DFixed =
TC/VC=3D01
Status: NegoPending- InProgress-
Capabilities: [300 v1] Device Serial Number =
00-00-00-00-00-00-00-00
Kernel driver in use: ath9k
Kernel modules: ath9k
=20
=20
# iw list
Wiphy phy0
Band 1:
Capabilities: 0x11ef
RX LDCP
HT20/HT40
SM Power Save disabled
RX HT20 SGI
RX HT40 SGI
TX STBC
RX STBC 1-stream
Max AMSDU length: 7935 bytes
DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 8 usec (0x06)
HT TX/RX MCS rate indexes supported: 0-23
Frequencies:
* 2412 MHz [1] (20.0 dBm)
* 2417 MHz [2] (20.0 dBm)
* 2422 MHz [3] (20.0 dBm)
* 2427 MHz [4] (20.0 dBm)
* 2432 MHz [5] (20.0 dBm)
* 2437 MHz [6] (20.0 dBm)
* 2442 MHz [7] (20.0 dBm)
* 2447 MHz [8] (20.0 dBm)
* 2452 MHz [9] (20.0 dBm)
* 2457 MHz [10] (20.0 dBm)
* 2462 MHz [11] (20.0 dBm)
* 2467 MHz [12] (20.0 dBm)
* 2472 MHz [13] (20.0 dBm)
* 2484 MHz [14] (disabled)
Bitrates (non-HT):
* 1.0 Mbps
* 2.0 Mbps (short preamble supported)
* 5.5 Mbps (short preamble supported)
* 11.0 Mbps (short preamble supported)
* 6.0 Mbps
* 9.0 Mbps
* 12.0 Mbps
* 18.0 Mbps
* 24.0 Mbps
* 36.0 Mbps
* 48.0 Mbps
* 54.0 Mbps
Band 2:
Capabilities: 0x11ef
RX LDCP
HT20/HT40
SM Power Save disabled
RX HT20 SGI
RX HT40 SGI
TX STBC
RX STBC 1-stream
Max AMSDU length: 7935 bytes
DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 8 usec (0x06)
HT TX/RX MCS rate indexes supported: 0-23
Frequencies:
* 5180 MHz [36] (20.0 dBm)
* 5200 MHz [40] (20.0 dBm)
* 5220 MHz [44] (20.0 dBm)
* 5240 MHz [48] (20.0 dBm)
* 5260 MHz [52] (20.0 dBm) (passive scanning, no =
IBSS, radar detection)
* 5280 MHz [56] (20.0 dBm) (passive scanning, no =
IBSS, radar detection)
* 5300 MHz [60] (20.0 dBm) (passive scanning, no =
IBSS, radar detection)
* 5320 MHz [64] (20.0 dBm) (passive scanning, no =
IBSS, radar detection)
* 5500 MHz [100] (disabled)
* 5520 MHz [104] (disabled)
* 5540 MHz [108] (disabled)
* 5560 MHz [112] (disabled)
* 5580 MHz [116] (disabled)
* 5600 MHz [120] (disabled)
* 5620 MHz [124] (disabled)
* 5640 MHz [128] (disabled)
* 5660 MHz [132] (disabled)
* 5680 MHz [136] (disabled)
* 5700 MHz [140] (disabled)
* 5745 MHz [149] (disabled)
* 5765 MHz [153] (disabled)
* 5785 MHz [157] (disabled)
* 5805 MHz [161] (disabled)
* 5825 MHz [165] (disabled)
Bitrates (non-HT):
* 6.0 Mbps
* 9.0 Mbps
* 12.0 Mbps
* 18.0 Mbps
* 24.0 Mbps
* 36.0 Mbps
* 48.0 Mbps
* 54.0 Mbps
max # scan SSIDs: 4
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* WDS
* monitor
* mesh point
* Unknown mode (8)
* Unknown mode (9)
Supported commands:
* new_interface
* set_interface
* new_key
* new_beacon
* new_station
* new_mpath
* set_mesh_params
* set_bss
* authenticate
* associate
* deauthenticate
* disassociate
* join_ibss
* Unknown command (68)
* Unknown command (55)
* Unknown command (57)
* Unknown command (59)
* Unknown command (67)
* set_wiphy_netns
* Unknown command (65)
* Unknown command (66)
* Unknown command (82)
* Unknown command (81)
* Unknown command (84)
* Unknown command (87)
* Unknown command (85)
* testmode
* connect
* disconnect
=20
=20
# cat /etc/hostapd.conf
# Schnittstelle und Treiber
interface=3Dwlan0
driver=3Dnl80211
=20
# WLAN-Konfiguration
ssid=3Dxxxx
channel=3D6
=20
# ESSID sichtbar
ignore_broadcast_ssid=3D0
=20
# L=E4ndereinstellungen
country_code=3DCH
ieee80211d=3D1
=20
# =DCbertragungsmodus
hw_mode=3Dg
# Optionale Einstellungen
# supported_rates=3D10 20 55 110 60 90 120 180 240 360 480 540
=20
# Draft-N Modus aktivieren / optional nur f=FCr entsprechende Karten
# ieee80211n=3D1
ieee80211n=3D1
=20
# Beacons
beacon_int=3D100
dtim_period=3D2
=20
# MAC-Authentifizierung
macaddr_acl=3D0
=20
# max. Anzahl der Clients
max_num_sta=3D255
=20
# Gr=F6=DFe der Datenpakete/Begrenzung
rts_threshold=3D2347
fragm_threshold=3D2346
=20
# hostapd Log Einstellungen
logger_syslog=3D-1
logger_syslog_level=3D2
logger_stdout=3D-1
logger_stdout_level=3D2
=20
# tempor=E4re Konfigurationsdateien
dump_file=3D/tmp/hostapd.dump
ctrl_interface=3D/var/run/hostapd
ctrl_interface_group=3D0
=20
# Authentifizierungsoptionen
auth_algs=3D1
=20
# wmm-Funktionalit=E4t
wmm_enabled=3D0
=20
# Verschl=FCsselung / hier rein WPA2
macaddr_acl=3D0
wpa=3D2
rsn_preauth=3D1
rsn_preauth_interfaces=3Dwlan0
wpa_key_mgmt=3DWPA-PSK
wpa_pairwise=3DTKIP
rsn_pairwise=3DCCMP
=20
# Schl=FCsselintervalle / Standardkonfiguration
wpa_group_rekey=3D600
wpa_ptk_rekey=3D600
wpa_gmk_rekey=3D86400
=20
# Zugangsschl=FCssel (PSK) / hier in Klartext (ASCII)
wpa_passphrase=3Dxxxx
=20
=20
[ 0.000000] Linux version 3.3.0-rc2-1+ (root@linux) (gcc version =
4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) ) #1 SMP Tue Feb 14
13:17:34 CET 2012
[ 0.000000] Command line: BOOT_IMAGE=3D/vmlinuz-3.3.0-rc2-1+ =
root=3DUUID=3Dcfc15d9c-2cd1-4bad-9e9d-f2fa1ded76e2 ro
[ 9.201360] ath: EEPROM regdomain: 0x21
[ 9.201362] ath: EEPROM indicates we should expect a direct regpair =
map
[ 9.201363] ath: Country alpha2 being used: AU
[ 9.201364] ath: Regpair used: 0x21
[ 9.531824] ieee80211 phy0: Selected rate control algorithm =
'ath9k_rate_control'
[ 9.532132] Registered led device: ath9k-phy0
[ 7.594696] cfg80211: Calling CRDA to update world regulatory domain
[ 8.966680] cfg80211: World regulatory domain updated:
[ 8.966682] cfg80211: (start_freq - end_freq @ bandwidth), =
(max_antenna_gain, max_eirp)
[ 8.966684] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 =
mBi, 2000 mBm)
[ 8.966686] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 =
mBi, 2000 mBm)
[ 8.966687] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 =
mBi, 2000 mBm)
[ 8.966688] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 =
mBi, 2000 mBm)
[ 8.966689] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 =
mBi, 2000 mBm)
[ 9.201366] cfg80211: Updating information on frequency 2412 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201368] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.201369] cfg80211: Updating information on frequency 2417 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201370] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.201371] cfg80211: Updating information on frequency 2422 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201373] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.201374] cfg80211: Updating information on frequency 2427 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201375] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.201376] cfg80211: Updating information on frequency 2432 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201378] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.201379] cfg80211: Updating information on frequency 2437 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201380] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.201381] cfg80211: Updating information on frequency 2442 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201383] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.201384] cfg80211: Updating information on frequency 2447 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201385] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.201386] cfg80211: Updating information on frequency 2452 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201388] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.201389] cfg80211: Updating information on frequency 2457 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201390] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.201391] cfg80211: Updating information on frequency 2462 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201393] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.201394] cfg80211: Disabling freq 2467 MHz as custom regd has no =
rule that fits a 20 MHz wide channel
[ 9.201395] cfg80211: Disabling freq 2472 MHz as custom regd has no =
rule that fits a 20 MHz wide channel
[ 9.201396] cfg80211: Disabling freq 2484 MHz as custom regd has no =
rule that fits a 20 MHz wide channel
[ 9.201398] cfg80211: Updating information on frequency 5180 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201399] cfg80211: 5140000 KHz - 5360000 KHz @ 40000 KHz), (N/A =
mBi, 3000 mBm)
[ 9.201400] cfg80211: Updating information on frequency 5200 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201402] cfg80211: 5140000 KHz - 5360000 KHz @ 40000 KHz), (N/A =
mBi, 3000 mBm)
[ 9.201403] cfg80211: Updating information on frequency 5220 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201404] cfg80211: 5140000 KHz - 5360000 KHz @ 40000 KHz), (N/A =
mBi, 3000 mBm)
[ 9.201405] cfg80211: Updating information on frequency 5240 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201407] cfg80211: 5140000 KHz - 5360000 KHz @ 40000 KHz), (N/A =
mBi, 3000 mBm)
[ 9.201408] cfg80211: Updating information on frequency 5260 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201409] cfg80211: 5140000 KHz - 5360000 KHz @ 40000 KHz), (N/A =
mBi, 3000 mBm)
[ 9.201410] cfg80211: Updating information on frequency 5280 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201412] cfg80211: 5140000 KHz - 5360000 KHz @ 40000 KHz), (N/A =
mBi, 3000 mBm)
[ 9.201413] cfg80211: Updating information on frequency 5300 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201414] cfg80211: 5140000 KHz - 5360000 KHz @ 40000 KHz), (N/A =
mBi, 3000 mBm)
[ 9.201415] cfg80211: Updating information on frequency 5320 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201417] cfg80211: 5140000 KHz - 5360000 KHz @ 40000 KHz), (N/A =
mBi, 3000 mBm)
[ 9.201418] cfg80211: Disabling freq 5500 MHz as custom regd has no =
rule that fits a 20 MHz wide channel
[ 9.201419] cfg80211: Disabling freq 5520 MHz as custom regd has no =
rule that fits a 20 MHz wide channel
[ 9.201420] cfg80211: Disabling freq 5540 MHz as custom regd has no =
rule that fits a 20 MHz wide channel
[ 9.201422] cfg80211: Disabling freq 5560 MHz as custom regd has no =
rule that fits a 20 MHz wide channel
[ 9.201423] cfg80211: Disabling freq 5580 MHz as custom regd has no =
rule that fits a 20 MHz wide channel
[ 9.201424] cfg80211: Disabling freq 5600 MHz as custom regd has no =
rule that fits a 20 MHz wide channel
[ 9.201425] cfg80211: Disabling freq 5620 MHz as custom regd has no =
rule that fits a 20 MHz wide channel
[ 9.201426] cfg80211: Disabling freq 5640 MHz as custom regd has no =
rule that fits a 20 MHz wide channel
[ 9.201428] cfg80211: Disabling freq 5660 MHz as custom regd has no =
rule that fits a 20 MHz wide channel
[ 9.201429] cfg80211: Disabling freq 5680 MHz as custom regd has no =
rule that fits a 20 MHz wide channel
[ 9.201430] cfg80211: Disabling freq 5700 MHz as custom regd has no =
rule that fits a 20 MHz wide channel
[ 9.201431] cfg80211: Updating information on frequency 5745 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201433] cfg80211: 5715000 KHz - 5860000 KHz @ 40000 KHz), (N/A =
mBi, 3000 mBm)
[ 9.201434] cfg80211: Updating information on frequency 5765 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201435] cfg80211: 5715000 KHz - 5860000 KHz @ 40000 KHz), (N/A =
mBi, 3000 mBm)
[ 9.201436] cfg80211: Updating information on frequency 5785 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201438] cfg80211: 5715000 KHz - 5860000 KHz @ 40000 KHz), (N/A =
mBi, 3000 mBm)
[ 9.201439] cfg80211: Updating information on frequency 5805 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201440] cfg80211: 5715000 KHz - 5860000 KHz @ 40000 KHz), (N/A =
mBi, 3000 mBm)
[ 9.201441] cfg80211: Updating information on frequency 5825 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201443] cfg80211: 5715000 KHz - 5860000 KHz @ 40000 KHz), (N/A =
mBi, 3000 mBm)
[ 9.202827] cfg80211: Updating information on frequency 2412 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.202829] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (300 =
mBi, 2000 mBm)
[ 9.202830] cfg80211: Updating information on frequency 2417 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.202831] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (300 =
mBi, 2000 mBm)
[ 9.202833] cfg80211: Updating information on frequency 2422 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.202834] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (300 =
mBi, 2000 mBm)
[ 9.202845] cfg80211: Updating information on frequency 2427 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.202847] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (300 =
mBi, 2000 mBm)
[ 9.202848] cfg80211: Updating information on frequency 2432 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.202849] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (300 =
mBi, 2000 mBm)
[ 9.202851] cfg80211: Updating information on frequency 2437 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.202852] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (300 =
mBi, 2000 mBm)
[ 9.202853] cfg80211: Updating information on frequency 2442 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.202855] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (300 =
mBi, 2000 mBm)
[ 9.202856] cfg80211: Updating information on frequency 2447 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.202857] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (300 =
mBi, 2000 mBm)
[ 9.202859] cfg80211: Updating information on frequency 2452 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.202860] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (300 =
mBi, 2000 mBm)
[ 9.202861] cfg80211: Updating information on frequency 2457 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.202863] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (300 =
mBi, 2000 mBm)
[ 9.202864] cfg80211: Updating information on frequency 2462 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.202865] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (300 =
mBi, 2000 mBm)
[ 9.202867] cfg80211: Updating information on frequency 2467 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.202868] cfg80211: 2457000 KHz - 2482000 KHz @ 20000 KHz), (300 =
mBi, 2000 mBm)
[ 9.202869] cfg80211: Updating information on frequency 2472 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.202871] cfg80211: 2457000 KHz - 2482000 KHz @ 20000 KHz), (300 =
mBi, 2000 mBm)
[ 9.202872] cfg80211: Updating information on frequency 2484 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.202874] cfg80211: 2474000 KHz - 2494000 KHz @ 20000 KHz), (300 =
mBi, 2000 mBm)
[ 9.202875] cfg80211: Updating information on frequency 5180 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.202877] cfg80211: 5170000 KHz - 5250000 KHz @ 40000 KHz), (300 =
mBi, 2000 mBm)
[ 9.202878] cfg80211: Updating information on frequency 5200 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.202879] cfg80211: 5170000 KHz - 5250000 KHz @ 40000 KHz), (300 =
mBi, 2000 mBm)
[ 9.202881] cfg80211: Updating information on frequency 5220 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.202882] cfg80211: 5170000 KHz - 5250000 KHz @ 40000 KHz), (300 =
mBi, 2000 mBm)
[ 9.202884] cfg80211: Updating information on frequency 5240 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.202885] cfg80211: 5170000 KHz - 5250000 KHz @ 40000 KHz), (300 =
mBi, 2000 mBm)
[ 9.202887] cfg80211: Disabling freq 5260 MHz
[ 9.202897] cfg80211: Disabling freq 5280 MHz
[ 9.202898] cfg80211: Disabling freq 5300 MHz
[ 9.202899] cfg80211: Disabling freq 5320 MHz
[ 9.202900] cfg80211: Disabling freq 5500 MHz
[ 9.202901] cfg80211: Disabling freq 5520 MHz
[ 9.202901] cfg80211: Disabling freq 5540 MHz
[ 9.202902] cfg80211: Disabling freq 5560 MHz
[ 9.202903] cfg80211: Disabling freq 5580 MHz
[ 9.202904] cfg80211: Disabling freq 5600 MHz
[ 9.202905] cfg80211: Disabling freq 5620 MHz
[ 9.202905] cfg80211: Disabling freq 5640 MHz
[ 9.202916] cfg80211: Disabling freq 5660 MHz
[ 9.202917] cfg80211: Disabling freq 5680 MHz
[ 9.202918] cfg80211: Disabling freq 5700 MHz
[ 9.202919] cfg80211: Updating information on frequency 5745 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.202920] cfg80211: 5735000 KHz - 5835000 KHz @ 40000 KHz), (300 =
mBi, 2000 mBm)
[ 9.202921] cfg80211: Updating information on frequency 5765 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.202923] cfg80211: 5735000 KHz - 5835000 KHz @ 40000 KHz), (300 =
mBi, 2000 mBm)
[ 9.202924] cfg80211: Updating information on frequency 5785 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.202925] cfg80211: 5735000 KHz - 5835000 KHz @ 40000 KHz), (300 =
mBi, 2000 mBm)
[ 9.202926] cfg80211: Updating information on frequency 5805 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.202928] cfg80211: 5735000 KHz - 5835000 KHz @ 40000 KHz), (300 =
mBi, 2000 mBm)
[ 9.202929] cfg80211: Updating information on frequency 5825 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.202930] cfg80211: 5735000 KHz - 5835000 KHz @ 40000 KHz), (300 =
mBi, 2000 mBm)
[ 9.532113] cfg80211: Calling CRDA for country: AU
[ 9.533522] cfg80211: Updating information on frequency 2412 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533524] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.533525] cfg80211: Updating information on frequency 2417 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533527] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.533528] cfg80211: Updating information on frequency 2422 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533530] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.533531] cfg80211: Updating information on frequency 2427 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533533] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.533534] cfg80211: Updating information on frequency 2432 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533535] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.533537] cfg80211: Updating information on frequency 2437 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533538] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.533539] cfg80211: Updating information on frequency 2442 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533541] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.533542] cfg80211: Updating information on frequency 2447 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533544] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.533545] cfg80211: Updating information on frequency 2452 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533546] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.533547] cfg80211: Updating information on frequency 2457 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533549] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.533550] cfg80211: Updating information on frequency 2462 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533552] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.533553] cfg80211: Updating information on frequency 2467 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533554] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.533556] cfg80211: Updating information on frequency 2472 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533557] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.533558] cfg80211: Disabling freq 2484 MHz
[ 9.533559] cfg80211: Updating information on frequency 5180 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533561] cfg80211: 5170000 KHz - 5250000 KHz @ 40000 KHz), (300 =
mBi, 2300 mBm)
[ 9.533562] cfg80211: Updating information on frequency 5200 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533564] cfg80211: 5170000 KHz - 5250000 KHz @ 40000 KHz), (300 =
mBi, 2300 mBm)
[ 9.533565] cfg80211: Updating information on frequency 5220 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533566] cfg80211: 5170000 KHz - 5250000 KHz @ 40000 KHz), (300 =
mBi, 2300 mBm)
[ 9.533568] cfg80211: Updating information on frequency 5240 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533569] cfg80211: 5170000 KHz - 5250000 KHz @ 40000 KHz), (300 =
mBi, 2300 mBm)
[ 9.533570] cfg80211: Updating information on frequency 5260 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533572] cfg80211: 5250000 KHz - 5330000 KHz @ 40000 KHz), (300 =
mBi, 2300 mBm)
[ 9.533573] cfg80211: Updating information on frequency 5280 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533575] cfg80211: 5250000 KHz - 5330000 KHz @ 40000 KHz), (300 =
mBi, 2300 mBm)
[ 9.533576] cfg80211: Updating information on frequency 5300 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533577] cfg80211: 5250000 KHz - 5330000 KHz @ 40000 KHz), (300 =
mBi, 2300 mBm)
[ 9.533579] cfg80211: Updating information on frequency 5320 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533580] cfg80211: 5250000 KHz - 5330000 KHz @ 40000 KHz), (300 =
mBi, 2300 mBm)
[ 9.533581] cfg80211: Disabling freq 5500 MHz
[ 9.533582] cfg80211: Disabling freq 5520 MHz
[ 9.533583] cfg80211: Disabling freq 5540 MHz
[ 9.533584] cfg80211: Disabling freq 5560 MHz
[ 9.533585] cfg80211: Disabling freq 5580 MHz
[ 9.533585] cfg80211: Disabling freq 5600 MHz
[ 9.533586] cfg80211: Disabling freq 5620 MHz
[ 9.533587] cfg80211: Disabling freq 5640 MHz
[ 9.533588] cfg80211: Disabling freq 5660 MHz
[ 9.533589] cfg80211: Disabling freq 5680 MHz
[ 9.533590] cfg80211: Disabling freq 5700 MHz
[ 9.533591] cfg80211: Updating information on frequency 5745 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533592] cfg80211: 5735000 KHz - 5835000 KHz @ 40000 KHz), (300 =
mBi, 3000 mBm)
[ 9.533593] cfg80211: Updating information on frequency 5765 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533595] cfg80211: 5735000 KHz - 5835000 KHz @ 40000 KHz), (300 =
mBi, 3000 mBm)
[ 9.533596] cfg80211: Updating information on frequency 5785 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533597] cfg80211: 5735000 KHz - 5835000 KHz @ 40000 KHz), (300 =
mBi, 3000 mBm)
[ 9.533599] cfg80211: Updating information on frequency 5805 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533600] cfg80211: 5735000 KHz - 5835000 KHz @ 40000 KHz), (300 =
mBi, 3000 mBm)
[ 9.533601] cfg80211: Updating information on frequency 5825 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533603] cfg80211: 5735000 KHz - 5835000 KHz @ 40000 KHz), (300 =
mBi, 3000 mBm)
[ 9.533606] cfg80211: Regulatory domain changed to country: AU
[ 9.533607] cfg80211: (start_freq - end_freq @ bandwidth), =
(max_antenna_gain, max_eirp)
[ 9.533608] cfg80211: (2402000 KHz - 2482000 KHz @ 40000 KHz), =
(N/A, 2000 mBm)
[ 9.533609] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 =
mBi, 2300 mBm)
[ 9.533611] cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 =
mBi, 2300 mBm)
[ 9.533612] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 =
mBi, 3000 mBm)
------=_NextPart_000_0CFF_01CD01BB.A7359070
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta =
http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1"><meta name=3DGenerator content=3D"Microsoft Word =
12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1667975767;
mso-list-type:hybrid;
mso-list-template-ids:1557444888 -1730749342 67698691 67698693 67698689 =
67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-start-at:2012;
mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Calibri","sans-serif";
mso-fareast-font-family:Calibri;
mso-bidi-font-family:"Times New Roman";}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue =
vlink=3Dpurple><div class=3DWordSection1><p =
class=3DMsoNormal>Hello<o:p></o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>I have a TP =
Link WDN4800 (ar9380). A Windows 802.11n client showed 72Mb connection, =
150Mb should be possible. inSSIDer showed 195Mb. I want to have it =
optimized for 2.4Ghz. <o:p></o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>iw =
list:<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 RX LDCP<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
=A0=A0=A0=A0=A0=A0=A0=A0HT20/HT40<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 SM Power Save disabled<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 RX HT20 SGI<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 RX HT40 SGI<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 TX STBC<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 RX STBC 1-stream<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 Max AMSDU length: 7935 bytes<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 DSSS/CCK HT40<o:p></o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>I =
haven’t found a complete guide (<a =
href=3D"http://linuxwireless.org/en/users/Documentation/hostapd">http://l=
inuxwireless.org/en/users/Documentation/hostapd</a>) for the ht_capab =
settings or some guidance to map them from iw list. Iw list shows HT20, =
what should/can be used, HT20, or HT20- or HT20+, with or without HT40*. =
Mapping to much seems also not to good.<o:p></o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoListParagraph =
style=3D'text-indent:-18.0pt;mso-list:l0 level1 lfo1'><![if =
!supportLists]><span style=3D'mso-list:Ignore'>-<span =
style=3D'font:7.0pt "Times New =
Roman"'> =
</span></span><![endif]>What are the most optimized settings for =
ht_capab ?<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p =
class=3DMsoNormal>From the guide and hostapd.conf (<a =
href=3D"http://hostap.epitest.fi/gitweb/gitweb.cgi?p=3Dhostap.git;a=3Dblo=
b_plain;f=3Dhostapd/hostapd.conf">http://hostap.epitest.fi/gitweb/gitweb.=
cgi?p=3Dhostap.git;a=3Dblob_plain;f=3Dhostapd/hostapd.conf</a>), =A0I =
cannot find what wme_enabled is.<o:p></o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoListParagraph =
style=3D'text-indent:-18.0pt;mso-list:l0 level1 lfo1'><![if =
!supportLists]><span style=3D'mso-list:Ignore'>-<span =
style=3D'font:7.0pt "Times New =
Roman"'> =
</span></span><![endif]>What does wme_enabled do ? Is it needed in =
conjunction with ht_capab ?<o:p></o:p></p><p class=3DMsoNormal> =
<o:p></o:p></p><p class=3DMsoNormal>Another question, I live in CH, a =
reboot shows <o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201363] =
ath: Country alpha2 being used: AU<o:p></o:p></p><p =
class=3DMsoNormal>And changed it to CH. <o:p></o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoListParagraph =
style=3D'text-indent:-18.0pt;mso-list:l0 level1 lfo1'><![if =
!supportLists]><span style=3D'mso-list:Ignore'>-<span =
style=3D'font:7.0pt "Times New =
Roman"'> =
</span></span><![endif]>Which limitation can I expect, for not being a =
European Card, as it propagates AU ?<o:p></o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>Below I =
added lspci, iw list, hostapd.conf, dmesg output.<o:p></o:p></p><p =
class=3DMsoNormal><a =
href=3D"http://www.tp-link.com/en/products/details/?model=3DTL-WDN4800#sp=
ec">http://www.tp-link.com/en/products/details/?model=3DTL-WDN4800#spec</=
a><o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p =
class=3DMsoNormal>Thanks for your help<o:p></o:p></p><p =
class=3DMsoNormal>Angela<o:p></o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal># lspci -vvd =
168c:<o:p></o:p></p><p class=3DMsoNormal>02:00.0 Network controller: =
Atheros Communications Inc. AR9300 Wireless LAN adaptor (rev =
01)<o:p></o:p></p><p class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0 Subsystem: =
Atheros Communications Inc. Device 3112<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0 Control: I/O+ Mem+ BusMaster+ =
SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- =
DisINTx-<o:p></o:p></p><p class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0 <span =
lang=3DDE-CH>Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfast =
>TAbort- <TAbort- <MAbort- >SERR- <PERR- =
INTx-<o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DDE-CH>=A0=A0=A0=A0=A0=A0=A0 </span>Latency: 0, Cache Line Size: =
64 bytes<o:p></o:p></p><p class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0 =
Interrupt: pin A routed to IRQ 17<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0 Region 0: Memory at fbe00000 =
(64-bit, non-prefetchable) [size=3D128K]<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0 Expansion ROM at fbe20000 =
[disabled] [size=3D64K]<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0 Capabilities: [40] Power =
Management version 3<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Flags: =
PMEClk- DSI- D1+ D2- AuxCurrent=3D375mA =
PME(D0+,D1+,D2-,D3hot+,D3cold-)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Status: =
D0 NoSoftRst- PME-Enable- DSel=3D0 DScale=3D0 PME-<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0 Capabilities: [50] MSI: Enable- =
Count=3D1/4 Maskable+ 64bit+<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Address: =
0000000000000000=A0 Data: 0000<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Masking: =
00000000=A0 Pending: 00000000<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0 Capabilities: [70] Express (v2) =
Endpoint, MSI 00<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 DevCap: =
MaxPayload 128 bytes, PhantFunc 0, Latency L0s <1us, L1 =
<8us<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 <span lang=3DDE-CH>ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ =
FLReset-<o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DDE-CH>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
</span>DevCtl: Report errors: Correctable- Non-Fatal- Fatal- =
Unsupported-<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 RlxdOrd- ExtTag- PhantFunc- AuxPwr- =
NoSnoop-<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 MaxPayload 128 bytes, MaxReadReq 512 bytes<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 DevSta: =
CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- =
TransPend-<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 LnkCap: =
Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <2us, L1 =
<64us<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 ClockPM- Surprise- LLActRep- BwNot-<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 LnkCtl: =
ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 ExtSynch- ClockPM- AutWidDis- BWInt- =
AutBWInt-<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 LnkSta: =
Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- =
ABWMgmt-<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 DevCap2: =
Completion Timeout: Not Supported, TimeoutDis+<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 DevCtl2: =
Completion Timeout: 50us to 50ms, TimeoutDis-<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 LnkCtl2: =
Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-, Selectable =
De-emphasis: -6dB<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0 Transmit Margin: Normal Operating Range, =
EnterModifiedCompliance- ComplianceSOS-<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0 Compliance De-emphasis: -6dB<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 LnkSta2: =
Current De-emphasis Level: -6dB<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0 Capabilities: [100 v1] Advanced =
Error Reporting<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
UESta:=A0 DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- =
MalfTLP- ECRC- UnsupReq- ACSViol-<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
=A0=A0UEMsk:=A0 DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- =
MalfTLP- ECRC- UnsupReq- ACSViol-<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 UESvrt: =
DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- =
UnsupReq- ACSViol-<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
CESta:=A0 RxErr- BadTLP- BadDLLP- Rollover- Timeout- =
NonFatalErr-<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
CEMsk:=A0 RxErr- BadTLP- BadDLLP- Rollover- Timeout- =
NonFatalErr+<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 AERCap: =
First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0 Capabilities: [140 v1] Virtual =
Channel<o:p></o:p></p><p class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0 =
=A0=A0=A0=A0=A0=A0=A0Caps:=A0=A0 LPEVC=3D0 RefClk=3D100ns =
PATEntryBits=3D1<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
Arb:=A0=A0=A0 Fixed- WRR32- WRR64- WRR128-<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
Ctrl:=A0=A0 ArbSelect=3DFixed<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Status: =
InProgress-<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
VC0:=A0=A0=A0 Caps:=A0=A0 PATOffset=3D00 MaxTimeSlots=3D1 =
RejSnoopTrans-<o:p></o:p></p><p class=3DMsoNormal> =
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Arb:=
=A0=A0=A0 Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 Ctrl:=A0=A0 Enable+ ID=3D0 ArbSelect=3DFixed =
TC/VC=3D01<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 Status: NegoPending- InProgress-<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0 Capabilities: [300 v1] Device =
Serial Number 00-00-00-00-00-00-00-00<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0 Kernel driver in use: =
ath9k<o:p></o:p></p><p class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0 Kernel =
modules: ath9k<o:p></o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal># iw =
list<o:p></o:p></p><p class=3DMsoNormal>Wiphy phy0<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0 Band 1:<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
Capabilities: 0x11ef<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 RX LDCP<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 HT20/HT40<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 SM Power Save disabled<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 RX HT20 SGI<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 RX HT40 SGI<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 TX STBC<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 RX STBC 1-stream<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 Max AMSDU length: 7935 bytes<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 DSSS/CCK HT40<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Maximum =
RX AMPDU length 65535 bytes (exponent: 0x003)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Minimum =
RX AMPDU time spacing: 8 usec (0x06)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 HT TX/RX =
MCS rate indexes supported: 0-23<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
Frequencies:<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 2412 MHz [1] (20.0 dBm)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 2417 MHz [2] (20.0 dBm)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 2422 MHz [3] (20.0 dBm)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 2427 MHz [4] (20.0 dBm)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 2432 MHz [5] (20.0 dBm)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 2437 MHz [6] (20.0 dBm)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 2442 MHz [7] (20.0 dBm)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 2447 MHz [8] (20.0 dBm)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 2452 MHz [9] (20.0 dBm)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 2457 MHz [10] (20.0 dBm)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 2462 MHz [11] (20.0 dBm)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 2467 MHz [12] (20.0 dBm)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0 =
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0* 2472 =
MHz [13] (20.0 dBm)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 2484 MHz [14] (disabled)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Bitrates =
(non-HT):<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 1.0 Mbps<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 2.0 Mbps (short preamble supported)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 5.5 Mbps (short preamble supported)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 11.0 Mbps (short preamble supported)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 6.0 Mbps<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 9.0 Mbps<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 12.0 Mbps<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 18.0 Mbps<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 24.0 Mbps<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 36.0 Mbps<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 48.0 Mbps<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 54.0 Mbps<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0 Band 2:<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
Capabilities: 0x11ef<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 RX LDCP<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
=A0=A0=A0=A0=A0=A0=A0=A0HT20/HT40<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 SM Power Save disabled<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 <span lang=3DDE-CH>RX HT20 SGI<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
lang=3DDE-CH>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0 RX HT40 SGI<o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DDE-CH>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0 </span>TX STBC<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 RX STBC 1-stream<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 Max AMSDU length: 7935 bytes<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 DSSS/CCK HT40<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Maximum =
RX AMPDU length 65535 bytes (exponent: 0x003)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Minimum =
RX AMPDU time spacing: 8 usec (0x06)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 HT TX/RX =
MCS rate indexes supported: 0-23<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
Frequencies:<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 5180 MHz [36] (20.0 dBm)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 5200 MHz [40] (20.0 dBm)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 5220 MHz [44] (20.0 dBm)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 5240 MHz [48] (20.0 dBm)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 5260 MHz [52] (20.0 dBm) (passive scanning, no IBSS, =
radar detection)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 5280 MHz [56] (20.0 dBm) (passive scanning, no IBSS, =
radar detection)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 5300 MHz [60] (20.0 dBm) (passive scanning, no IBSS, =
radar detection)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 5320 MHz [64] (20.0 dBm) (passive scanning, no IBSS, =
radar detection)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 5500 MHz [100] (disabled)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 5520 MHz [104] (disabled)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 5540 MHz [108] (disabled)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 5560 MHz [112] (disabled)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 5580 MHz [116] (disabled)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 5600 MHz [120] (disabled)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 5620 MHz [124] (disabled)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0* 5640 MHz [128] (disabled)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 5660 MHz [132] (disabled)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 5680 MHz [136] (disabled)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 5700 MHz [140] (disabled)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 5745 MHz [149] (disabled)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
=A0=A0=A0=A0=A0=A0=A0=A0* 5765 MHz [153] (disabled)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 5785 MHz [157] (disabled)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 5805 MHz [161] (disabled)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 5825 MHz [165] (disabled)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Bitrates =
(non-HT):<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 6.0 Mbps<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 9.0 Mbps<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 12.0 Mbps<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 18.0 Mbps<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 24.0 Mbps<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 36.0 Mbps<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 48.0 Mbps<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 54.0 Mbps<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0 max # scan SSIDs: =
4<o:p></o:p></p><p class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0 Supported =
interface modes:<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
IBSS<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
managed<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
AP<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
AP/VLAN<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
WDS<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
monitor<o:p></o:p></p><p class=3DMsoNormal>=A0=A0=A0=A0=A0=A0 =
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0* mesh point<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
Unknown mode (8)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
Unknown mode (9)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0 Supported =
commands:<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
new_interface<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
set_interface<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
new_key<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
new_beacon<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0* =
new_station<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
new_mpath<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
set_mesh_params<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
set_bss<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
authenticate<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
associate<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
deauthenticate<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
disassociate<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
join_ibss<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
Unknown command (68)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
Unknown command (55)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
Unknown command (57)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
Unknown command (59)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
Unknown command (67)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
set_wiphy_netns<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
Unknown command (65)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
Unknown command (66)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
Unknown command (82)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
Unknown command (81)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
Unknown command (84)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
Unknown command (87)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0* =
Unknown command (85)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
testmode<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
connect<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
disconnect<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal><span =
lang=3DDE-CH># cat /etc/hostapd.conf<o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DDE-CH># Schnittstelle und =
Treiber<o:p></o:p></span></p><p =
class=3DMsoNormal>interface=3Dwlan0<o:p></o:p></p><p =
class=3DMsoNormal>driver=3Dnl80211<o:p></o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal># =
WLAN-Konfiguration<o:p></o:p></p><p =
class=3DMsoNormal>ssid=3Dxxxx<o:p></o:p></p><p =
class=3DMsoNormal>channel=3D6<o:p></o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal># ESSID =
sichtbar<o:p></o:p></p><p =
class=3DMsoNormal>ignore_broadcast_ssid=3D0<o:p></o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal><span =
lang=3DDE-CH># L=E4ndereinstellungen<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
lang=3DDE-CH>country_code=3DCH<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
lang=3DDE-CH>ieee80211d=3D1<o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DDE-CH><o:p> </o:p></span></p><p =
class=3DMsoNormal><span lang=3DDE-CH># =
=DCbertragungsmodus<o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DDE-CH>hw_mode=3Dg<o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DDE-CH># Optionale Einstellungen<o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DDE-CH># supported_rates=3D10 20 55 110 60 =
90 120 180 240 360 480 540<o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DDE-CH><o:p> </o:p></span></p><p =
class=3DMsoNormal><span lang=3DDE-CH># Draft-N Modus aktivieren / =
optional nur f=FCr entsprechende Karten<o:p></o:p></span></p><p =
class=3DMsoNormal># ieee80211n=3D1<o:p></o:p></p><p =
class=3DMsoNormal>ieee80211n=3D1<o:p></o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal># =
Beacons<o:p></o:p></p><p =
class=3DMsoNormal>beacon_int=3D100<o:p></o:p></p><p =
class=3DMsoNormal><span =
lang=3DDE-CH>dtim_period=3D2<o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DDE-CH><o:p> </o:p></span></p><p =
class=3DMsoNormal><span lang=3DDE-CH># =
MAC-Authentifizierung<o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DDE-CH>macaddr_acl=3D0<o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DDE-CH><o:p> </o:p></span></p><p =
class=3DMsoNormal><span lang=3DDE-CH># max. Anzahl der =
Clients<o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DDE-CH>max_num_sta=3D255<o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DDE-CH><o:p> </o:p></span></p><p =
class=3DMsoNormal><span lang=3DDE-CH># Gr=F6=DFe der =
Datenpakete/Begrenzung<o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DDE-CH>rts_threshold=3D2347<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
lang=3DDE-CH>fragm_threshold=3D2346<o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DDE-CH><o:p> </o:p></span></p><p =
class=3DMsoNormal><span lang=3DDE-CH># hostapd Log =
Einstellungen<o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DDE-CH>logger_syslog=3D-1<o:p></o:p></span></p><p =
class=3DMsoNormal>logger_syslog_level=3D2<o:p></o:p></p><p =
class=3DMsoNormal>logger_stdout=3D-1<o:p></o:p></p><p =
class=3DMsoNormal>logger_stdout_level=3D2<o:p></o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal># =
tempor=E4re Konfigurationsdateien<o:p></o:p></p><p =
class=3DMsoNormal>dump_file=3D/tmp/hostapd.dump<o:p></o:p></p><p =
class=3DMsoNormal>ctrl_interface=3D/var/run/hostapd<o:p></o:p></p><p =
class=3DMsoNormal>ctrl_interface_group=3D0<o:p></o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal><span =
lang=3DDE-CH># Authentifizierungsoptionen<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
lang=3DDE-CH>auth_algs=3D1<o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DDE-CH><o:p> </o:p></span></p><p =
class=3DMsoNormal><span lang=3DDE-CH># =
wmm-Funktionalit=E4t<o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DDE-CH>wmm_enabled=3D0<o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DDE-CH><o:p> </o:p></span></p><p =
class=3DMsoNormal><span lang=3DDE-CH># Verschl=FCsselung / hier rein =
WPA2<o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DDE-CH>macaddr_acl=3D0<o:p></o:p></span></p><p =
class=3DMsoNormal>wpa=3D2<o:p></o:p></p><p =
class=3DMsoNormal>rsn_preauth=3D1<o:p></o:p></p><p =
class=3DMsoNormal>rsn_preauth_interfaces=3Dwlan0<o:p></o:p></p><p =
class=3DMsoNormal>wpa_key_mgmt=3DWPA-PSK<o:p></o:p></p><p =
class=3DMsoNormal>wpa_pairwise=3DTKIP<o:p></o:p></p><p =
class=3DMsoNormal>rsn_pairwise=3DCCMP<o:p></o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal># =
Schl=FCsselintervalle / Standardkonfiguration<o:p></o:p></p><p =
class=3DMsoNormal>wpa_group_rekey=3D600<o:p></o:p></p><p =
class=3DMsoNormal>wpa_ptk_rekey=3D600<o:p></o:p></p><p =
class=3DMsoNormal><span =
lang=3DDE-CH>wpa_gmk_rekey=3D86400<o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DDE-CH><o:p> </o:p></span></p><p =
class=3DMsoNormal><span lang=3DDE-CH># Zugangsschl=FCssel (PSK) / hier =
in Klartext (ASCII)<o:p></o:p></span></p><p =
class=3DMsoNormal>wpa_passphrase=3Dxxxx<o:p></o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
0.000000] Linux version 3.3.0-rc2-1+ (root at linux) (gcc version 4.6.1 =
(Ubuntu/Linaro 4.6.1-9ubuntu3) ) #1 SMP Tue Feb 14 13:17:34 CET =
2012<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 0.000000] Command =
line: BOOT_IMAGE=3D/vmlinuz-3.3.0-rc2-1+ =
root=3DUUID=3Dcfc15d9c-2cd1-4bad-9e9d-f2fa1ded76e2 ro<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.201360] ath: EEPROM regdomain: =
0x21<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201362] ath: EEPROM =
indicates we should expect a direct regpair map<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.201363] ath: Country alpha2 being used: =
AU<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201364] ath: Regpair =
used: 0x21<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.531824] =
ieee80211 phy0: Selected rate control algorithm =
'ath9k_rate_control'<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.532132] Registered led device: ath9k-phy0<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 7.594696] cfg80211: Calling CRDA to update =
world regulatory domain<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
8.966680] cfg80211: World regulatory domain updated:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 8.966682] cfg80211:=A0=A0 (start_freq - =
end_freq @ bandwidth), (max_antenna_gain, max_eirp)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 8.966684] cfg80211:=A0=A0 (2402000 KHz - =
2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 8.966686] cfg80211:=A0=A0 (2457000 KHz - =
2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 8.966687] cfg80211:=A0=A0 (2474000 KHz - =
2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 8.966688] cfg80211:=A0=A0 (5170000 KHz - =
5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 8.966689] cfg80211:=A0=A0 (5735000 KHz - =
5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.201366] cfg80211: Updating information on =
frequency 2412 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201368] cfg80211: =
2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 2000 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201369] cfg80211: =
Updating information on frequency 2417 MHz for a 20 MHz width channel =
with regulatory rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.201370] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, =
2000 mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201371] =
cfg80211: Updating information on frequency 2422 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.201373] cfg80211: 2402000 KHz - 2472000 =
KHz @ 40000 KHz), (N/A mBi, 2000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.201374] cfg80211: Updating information on =
frequency 2427 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201375] cfg80211: =
2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 2000 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201376] cfg80211: =
Updating information on frequency 2432 MHz for a 20 MHz width channel =
with regulatory rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0 =
=A0=A09.201378] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201379] =
cfg80211: Updating information on frequency 2437 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.201380] cfg80211: 2402000 KHz - 2472000 =
KHz @ 40000 KHz), (N/A mBi, 2000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.201381] cfg80211: Updating information on =
frequency 2442 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201383] cfg80211: =
2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 2000 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201384] cfg80211: =
Updating information on frequency 2447 MHz for a 20 MHz width channel =
with regulatory rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.201385] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, =
2000 mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201386] =
cfg80211: Updating information on frequency 2452 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.201388] cfg80211: 2402000 KHz - 2472000 =
KHz @ 40000 KHz), (N/A mBi, 2000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.201389] cfg80211: Updating information on =
frequency 2457 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201390] cfg80211: =
2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 2000 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201391] cfg80211: =
Updating information on frequency 2462 MHz for a 20 MHz width channel =
with regulatory rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.201393] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, =
2000 mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201394] =
cfg80211: Disabling freq 2467 MHz as custom regd has no rule that fits a =
20 MHz wide channel<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.201395] cfg80211: Disabling freq 2472 MHz as custom regd has no rule =
that fits a 20 MHz wide channel<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.201396] cfg80211: Disabling freq 2484 MHz =
as custom regd has no rule that fits a 20 MHz wide =
channel<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201398] =
cfg80211: Updating information on frequency 5180 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.201399] cfg80211: 5140000 KHz - 5360000 =
KHz @ 40000 KHz), (N/A mBi, 3000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.201400] cfg80211: Updating information on =
frequency 5200 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201402] cfg80211: =
5140000 KHz - 5360000 KHz @ 40000 KHz), (N/A mBi, 3000 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201403] cfg80211: =
Updating information on frequency 5220 MHz for a 20 MHz width channel =
with regulatory rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.201404] cfg80211: 5140000 KHz - 5360000 KHz @ 40000 KHz), (N/A mBi, =
3000 mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201405] =
cfg80211: Updating information on frequency 5240 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.201407] cfg80211: 5140000 KHz - 5360000 =
KHz @ 40000 KHz), (N/A mBi, 3000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.201408] cfg80211: Updating information on =
frequency 5260 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201409] cfg80211: =
5140000 KHz - 5360000 KHz @ 40000 KHz), (N/A mBi, 3000 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201410] cfg80211: =
Updating information on frequency 5280 MHz for a 20 MHz width channel =
with regulatory rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.201412] cfg80211: 5140000 KHz - 5360000 KHz @ 40000 KHz), (N/A mBi, =
3000 mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201413] =
cfg80211: Updating information on frequency 5300 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.201414] cfg80211: 5140000 KHz - 5360000 =
KHz @ 40000 KHz), (N/A mBi, 3000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.201415] cfg80211: Updating information on =
frequency 5320 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201417] cfg80211: =
5140000 KHz - 5360000 KHz @ 40000 KHz), (N/A mBi, 3000 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201418] cfg80211: =
Disabling freq 5500 MHz as custom regd has no rule that fits a 20 MHz =
wide channel<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201419] =
cfg80211: Disabling freq 5520 MHz as custom regd has no rule that fits a =
20 MHz wide channel<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.201420] cfg80211: Disabling freq 5540 MHz as custom regd has no rule =
that fits a 20 MHz wide channel<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.201422] cfg80211: Disabling freq 5560 MHz =
as custom regd has no rule that fits a 20 MHz wide =
channel<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201423] =
cfg80211: Disabling freq 5580 MHz as custom regd has no rule that fits a =
20 MHz wide channel<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.201424] cfg80211: Disabling freq 5600 MHz as custom regd has no rule =
that fits a 20 MHz wide channel<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.201425] cfg80211: Disabling freq 5620 MHz =
as custom regd has no rule that fits a 20 MHz wide =
channel<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201426] =
cfg80211: Disabling freq 5640 MHz as custom regd has no rule that fits a =
20 MHz wide channel<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.201428] cfg80211: Disabling freq 5660 MHz as custom regd has no rule =
that fits a 20 MHz wide channel<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.201429] cfg80211: Disabling freq 5680 MHz =
as custom regd has no rule that fits a 20 MHz wide =
channel<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201430] =
cfg80211: Disabling freq 5700 MHz as custom regd has no rule that fits a =
20 MHz wide channel<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.201431] cfg80211: Updating information on frequency 5745 MHz for a 20 =
MHz width channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.201433] cfg80211: 5715000 KHz - 5860000 =
KHz @ 40000 KHz), (N/A mBi, 3000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.201434] cfg80211: Updating information on =
frequency 5765 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201435] cfg80211: =
5715000 KHz - 5860000 KHz @ 40000 KHz), (N/A mBi, 3000 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201436] cfg80211: =
Updating information on frequency 5785 MHz for a 20 MHz width channel =
with regulatory rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.201438] cfg80211: 5715000 KHz - 5860000 KHz @ 40000 KHz), (N/A mBi, =
3000 mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201439] =
cfg80211: Updating information on frequency 5805 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.201440] cfg80211: 5715000 KHz - 5860000 =
KHz @ 40000 KHz), (N/A mBi, 3000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.201441] cfg80211: Updating information on =
frequency 5825 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201443] cfg80211: =
5715000 KHz - 5860000 KHz @ 40000 KHz), (N/A mBi, 3000 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202827] cfg80211: =
Updating information on frequency 2412 MHz for a 20 MHz width channel =
with regulatory rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.202829] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, =
2000 mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202830] =
cfg80211: Updating information on frequency 2417 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.202831] cfg80211: 2402000 KHz - 2472000 =
KHz @ 40000 KHz), (300 mBi, 2000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.202833] cfg80211: Updating information on =
frequency 2422 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202834] cfg80211: =
2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202845] cfg80211: =
Updating information on frequency 2427 MHz for a 20 MHz width channel =
with regulatory rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.202847] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, =
2000 mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202848] =
cfg80211: Updating information on frequency 2432 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.202849] cfg80211: 2402000 KHz - 2472000 =
KHz @ 40000 KHz), (300 mBi, 2000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.202851] cfg80211: Updating information on =
frequency 2437 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202852] cfg80211: =
2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202853] cfg80211: =
Updating information on frequency 2442 MHz for a 20 MHz width channel =
with regulatory rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.202855] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, =
2000 mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202856] =
cfg80211: Updating information on frequency 2447 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.202857] cfg80211: 2402000 KHz - 2472000 =
KHz @ 40000 KHz), (300 mBi, 2000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.202859] cfg80211: Updating information on =
frequency 2452 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202860] cfg80211: =
2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202861] cfg80211: =
Updating information on frequency 2457 MHz for a 20 MHz width channel =
with regulatory rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.202863] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, =
2000 mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202864] =
cfg80211: Updating information on frequency 2462 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.202865] cfg80211: 2402000 KHz - 2472000 =
KHz @ 40000 KHz), (300 mBi, 2000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.202867] cfg80211: Updating information on =
frequency 2467 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202868] cfg80211: =
2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202869] cfg80211: =
Updating information on frequency 2472 MHz for a 20 MHz width channel =
with regulatory rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.202871] cfg80211: 2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, =
2000 mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202872] =
cfg80211: Updating information on frequency 2484 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.202874] cfg80211: 2474000 KHz - 2494000 =
KHz @ 20000 KHz), (300 mBi, 2000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.202875] cfg80211: Updating information on =
frequency 5180 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202877] cfg80211: =
5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202878] cfg80211: =
Updating information on frequency 5200 MHz for a 20 MHz width channel =
with regulatory rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.202879] cfg80211: 5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, =
2000 mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202881] =
cfg80211: Updating information on frequency 5220 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.202882] cfg80211: 5170000 KHz - 5250000 =
KHz @ 40000 KHz), (300 mBi, 2000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.202884] cfg80211: Updating information on =
frequency 5240 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202885] cfg80211: =
5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202887] cfg80211: =
Disabling freq 5260 MHz<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.202897] cfg80211: Disabling freq 5280 MHz<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.202898] cfg80211: Disabling freq 5300 =
MHz<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202899] cfg80211: =
Disabling freq 5320 MHz<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.202900] cfg80211: Disabling freq 5500 MHz<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.202901] cfg80211: Disabling freq 5520 =
MHz<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202901] cfg80211: =
Disabling freq 5540 MHz<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.202902] cfg80211: Disabling freq 5560 MHz<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.202903] cfg80211: Disabling freq 5580 =
MHz<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202904] cfg80211: =
Disabling freq 5600 MHz<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.202905] cfg80211: Disabling freq 5620 MHz<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.202905] cfg80211: Disabling freq 5640 =
MHz<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202916] cfg80211: =
Disabling freq 5660 MHz<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.202917] cfg80211: Disabling freq 5680 MHz<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.202918] cfg80211: Disabling freq 5700 =
MHz<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202919] cfg80211: =
Updating information on frequency 5745 MHz for a 20 MHz width channel =
with regulatory rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.202920] cfg80211: 5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, =
2000 mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202921] =
cfg80211: Updating information on frequency 5765 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.202923] cfg80211: 5735000 KHz - 5835000 =
KHz @ 40000 KHz), (300 mBi, 2000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.202924] cfg80211: Updating information on =
frequency 5785 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202925] cfg80211: =
5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202926] cfg80211: =
Updating information on frequency 5805 MHz for a 20 MHz width channel =
with regulatory rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.202928] cfg80211: 5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, =
2000 mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202929] =
cfg80211: Updating information on frequency 5825 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.202930] cfg80211: 5735000 KHz - 5835000 =
KHz @ 40000 KHz), (300 mBi, 2000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.532113] cfg80211: Calling CRDA for =
country: AU<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533522] =
cfg80211: Updating information on frequency 2412 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533524] cfg80211: 2402000 KHz - 2482000 =
KHz @ 40000 KHz), (N/A mBi, 2000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533525] cfg80211: Updating information on =
frequency 2417 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533527] cfg80211: =
2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A mBi, 2000 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533528] cfg80211: =
Updating information on frequency 2422 MHz for a 20 MHz width channel =
with regulatory rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.533530] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A mBi, =
2000 mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533531] =
cfg80211: Updating information on frequency 2427 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533533] cfg80211: 2402000 KHz - 2482000 =
KHz @ 40000 KHz), (N/A mBi, 2000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533534] cfg80211: Updating information on =
frequency 2432 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533535] cfg80211: =
2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A mBi, 2000 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533537] cfg80211: =
Updating information on frequency 2437 MHz for a 20 MHz width channel =
with regulatory rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.533538] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A mBi, =
2000 mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533539] =
cfg80211: Updating information on frequency 2442 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533541] cfg80211: 2402000 KHz - 2482000 =
KHz @ 40000 KHz), (N/A mBi, 2000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533542] cfg80211: Updating information on =
frequency 2447 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533544] cfg80211: =
2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A mBi, 2000 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533545] cfg80211: =
Updating information on frequency 2452 MHz for a 20 MHz width channel =
with regulatory rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.533546] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A mBi, =
2000 mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533547] =
cfg80211: Updating information on frequency 2457 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533549] cfg80211: 2402000 KHz - 2482000 =
KHz @ 40000 KHz), (N/A mBi, 2000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533550] cfg80211: Updating information on =
frequency 2462 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533552] cfg80211: =
2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A mBi, 2000 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533553] cfg80211: =
Updating information on frequency 2467 MHz for a 20 MHz width channel =
with regulatory rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.533554] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A mBi, =
2000 mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533556] =
cfg80211: Updating information on frequency 2472 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533557] cfg80211: 2402000 KHz - 2482000 =
KHz @ 40000 KHz), (N/A mBi, 2000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533558] cfg80211: Disabling freq 2484 =
MHz<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533559] cfg80211: =
Updating information on frequency 5180 MHz for a 20 MHz width channel =
with regulatory rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.533561] cfg80211: 5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, =
2300 mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533562] =
cfg80211: Updating information on frequency 5200 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533564] cfg80211: 5170000 KHz - 5250000 =
KHz @ 40000 KHz), (300 mBi, 2300 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533565] cfg80211: Updating information on =
frequency 5220 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533566] cfg80211: =
5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2300 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533568] cfg80211: =
Updating information on frequency 5240 MHz for a 20 MHz width channel =
with regulatory rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.533569] cfg80211: 5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, =
2300 mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533570] =
cfg80211: Updating information on frequency 5260 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533572] cfg80211: 5250000 KHz - 5330000 =
KHz @ 40000 KHz), (300 mBi, 2300 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533573] cfg80211: Updating information on =
frequency 5280 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533575] cfg80211: =
5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2300 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533576] cfg80211: =
Updating information on frequency 5300 MHz for a 20 MHz width channel =
with regulatory rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.533577] cfg80211: 5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, =
2300 mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533579] =
cfg80211: Updating information on frequency 5320 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533580] cfg80211: 5250000 KHz - 5330000 =
KHz @ 40000 KHz), (300 mBi, 2300 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[ =A0=A0=A09.533581] cfg80211: Disabling freq 5500 =
MHz<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533582] cfg80211: =
Disabling freq 5520 MHz<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.533583] cfg80211: Disabling freq 5540 MHz<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533584] cfg80211: Disabling freq 5560 =
MHz<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533585] cfg80211: =
Disabling freq 5580 MHz<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.533585] cfg80211: Disabling freq 5600 MHz<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533586] cfg80211: Disabling freq 5620 =
MHz<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533587] cfg80211: =
Disabling freq 5640 MHz<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.533588] cfg80211: Disabling freq 5660 MHz<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533589] cfg80211: Disabling freq 5680 =
MHz<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533590] cfg80211: =
Disabling freq 5700 MHz<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.533591] cfg80211: Updating information on frequency 5745 MHz for a 20 =
MHz width channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533592] cfg80211: 5735000 KHz - 5835000 =
KHz @ 40000 KHz), (300 mBi, 3000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533593] cfg80211: Updating information on =
frequency 5765 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533595] cfg80211: =
5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533596] cfg80211: =
Updating information on frequency 5785 MHz for a 20 MHz width channel =
with regulatory rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.533597] cfg80211: 5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, =
3000 mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533599] =
cfg80211: Updating information on frequency 5805 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533600] cfg80211: 5735000 KHz - 5835000 =
KHz @ 40000 KHz), (300 mBi, 3000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533601] cfg80211: Updating information on =
frequency 5825 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533603] cfg80211: =
5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533606] cfg80211: =
Regulatory domain changed to country: AU<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533607] cfg80211:=A0=A0 (start_freq - =
end_freq @ bandwidth), (max_antenna_gain, max_eirp)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533608] cfg80211:=A0=A0 (2402000 KHz - =
2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533609] cfg80211:=A0=A0 (5170000 KHz - =
5250000 KHz @ 40000 KHz), (300 mBi, 2300 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533611] cfg80211:=A0=A0 (5250000 KHz - =
5330000 KHz @ 40000 KHz), (300 mBi, 2300 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533612] cfg80211:=A0=A0 (5735000 KHz - =
5835000 KHz @ 40000 KHz), (300 mBi, 3000 =
mBm)<o:p></o:p></p></div></body></html>
------=_NextPart_000_0CFF_01CD01BB.A7359070--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2012-01-15 8:24 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2012-01-15 8:24 UTC (permalink / raw)
To: ath9k-devel
=A0=A0=A0 /* Only use status info from the last fragment */
=A0=A0=A0 if (rx_stats->rs_more)
=A0=A0=A0 =A0=A0=A0 return 0=3B
rs_more is set from the receive descriptor in ath9k_hw_rxprocdesc=2C so if =
"fragment" is an A-MPDU subframe=2C each subframe gets its own descriptor. =
This looks promising.
=
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-30 17:16 Philip Anil-QBW348
0 siblings, 0 replies; 732+ messages in thread
From: Philip Anil-QBW348 @ 2011-12-30 17:16 UTC (permalink / raw)
To: kernelnewbies
I want the drivers to be owned by a user, Foo. Whenever the drivers are
called by application Duh, I want a program Bar to run after the driver
has done its work, since Foo is now running the driver. Is it possible?
Anil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20111230/30642c9f/attachment.html
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-28 14:01 Shawn Guo
0 siblings, 0 replies; 732+ messages in thread
From: Shawn Guo @ 2011-12-28 14:01 UTC (permalink / raw)
To: linux-arm-kernel
[Resend to cc LAKML. Sorry.]
Hi Arnd, Olof,
Please consider to pull mxs/clk-prepare for 3.3. I have not collected
the ack tag from every single subsystem maintainer, but I do not want
to hold this any longer, since it's close to merge window now.
Hi Sascha,
I send a couple of Richard's patch you have collected here for
completeness.
Regards,
Shawn
The following changes since commit 384703b8e6cd4c8ef08512e596024e028c91c339:
Linux 3.2-rc6 (2011-12-16 18:36:26 -0800)
are available in the git repository at:
git://git.linaro.org/people/shawnguo/linux-2.6.git mxs/clk-prepare
Richard Zhao (2):
clk: add helper functions clk_prepare_enable and clk_disable_unprepare
net: fec: add clk_prepare/clk_unprepare
Shawn Guo (10):
ARM: mxs: convert platform code to clk_prepare/clk_unprepare
dma: mxs-dma: convert to clk_prepare/clk_unprepare
mmc: mxs-mmc: convert to clk_prepare/clk_unprepare
mtd: gpmi-lib: convert to clk_prepare/clk_unprepare
net: flexcan: convert to clk_prepare/clk_unprepare
serial: mxs-auart: convert to clk_prepare/clk_unprepare
video: mxsfb: convert to clk_prepare/clk_unprepare
ASoC: mxs-saif: convert to clk_prepare/clk_unprepare
clk: add config option HAVE_CLK_PREPARE into Kconfig
ARM: mxs: select HAVE_CLK_PREPARE for clock
arch/arm/Kconfig | 1 +
arch/arm/mach-mxs/clock-mx23.c | 10 +++++-----
arch/arm/mach-mxs/clock-mx28.c | 10 +++++-----
arch/arm/mach-mxs/clock.c | 33 +++++++++++++++++++++++----------
arch/arm/mach-mxs/mach-mx28evk.c | 2 +-
arch/arm/mach-mxs/system.c | 2 +-
arch/arm/mach-mxs/timer.c | 2 +-
drivers/clk/Kconfig | 3 +++
drivers/dma/mxs-dma.c | 8 ++++----
drivers/mmc/host/mxs-mmc.c | 10 +++++-----
drivers/mtd/nand/gpmi-nand/gpmi-lib.c | 12 ++++++------
drivers/net/can/flexcan.c | 10 +++++-----
drivers/net/ethernet/freescale/fec.c | 10 +++++-----
drivers/tty/serial/mxs-auart.c | 8 ++++----
drivers/video/mxsfb.c | 8 ++++----
include/linux/clk.h | 22 ++++++++++++++++++++++
sound/soc/mxs/mxs-saif.c | 4 ++--
17 files changed, 97 insertions(+), 58 deletions(-)
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-16 2:18 Swapnil Gaikwad
0 siblings, 0 replies; 732+ messages in thread
From: Swapnil Gaikwad @ 2011-12-16 2:18 UTC (permalink / raw)
To: kernelnewbies
Hi ,
Tell me procedure or system call for-
How to copy metadata of all files in a ext4 filesystem.
--
Regards,
Swapnil Gaikwad.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
snprintf() series is still there.
http://patchwork.ozlabs.org/patch/123328/
(happy to do some more work on this before or after if required)
There is a tegra pull request in the works (which will go through arm)
and I have an ARM series still pending - I will email Albert about
that.
Regards,
Simon
>
>
> Thanks.
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, =A0 =A0 MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> Always borrow money from a pessimist; they don't expect =A0to =A0be =A0pa=
id
> back.
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
mapping from (row, col) to keycode. I believe that's all the KBC
driver's binding should define.
I'll amend that slightly: keyboards commonly implement the Fn key
internally in HW, since it causes keys to emit completely different raw
codes, so I can see this driver wanting both keycode-plain and keycode-fn.
However, keycode-shift and keycode-ctrl are purely SW concepts. As such,
they shouldn't be part of the KBC's own mapping table. Witness how the
kernel's Tegra KBC driver only contains the plain and fn tables (albeit
merged into a single array for ease of use), and the input core is what
interpets e.g. KEY_LEFTSHIFT as a modifier.
So specifically what I'd like to see changed in this binding is:
a) We need binding documentation for the Tegra KBC binding, in the same
style as found in the kernel's Documentation/devicetree/bindings.
b) The Tegra KBC binding should include only the keycode-plain and
keycode-fn properties; nothing to do with shift/ctrl/alt/.... (Well,
also any standardized properties such as compatible, reg, interrupts).
c) We need binding documentation for the data that is/could-be common
across multiple keyboards: i.e. what does each key code value represent;
which is KEY_A, KEY_LEFTSHIFT, etc.? These values should be common
across (1) all keyboards (2) some standardized meaning for DT that can
be used by U-Boot, the Linux kernel, etc. Perhaps there is already such
a standard?
d) Shift/Ctrl/Alt/... modifier mapping tables should be specified by a
separate binding that can be common to any/all keyboards (probably the
same document as (b) above). The input to this table should be the raw
codes from keycode-plain/keycode-fn. The output would be the values sent
to whatever consumes keyboard input. The naming of these properties
should make it obvious that it's something not specific to Tegra's KBC,
and SW oriented. Perhaps something semantically similar to loadkeys' or
xkbcomp's input, although I haven't looked at those in detail.
Linux probably wouldn't use (d), since it already has its own
SW-oriented methods of setting up such mapping tables. Although perhaps
in the future the default mappings could be set up from these properties.
U-Boot would need (d), since AIUI, there is no handling of such a higher
layer of mapping tables there right now.
Initially, the code to parse and implement the mappings in (d) could be
part of the Tegra KBC driver, if there's nowhere else to put it. I
simply want to ensure that the structure of the mapping table bindings
doesn't require them to be specific to Tegra KBC, or perpetually
implemented by the Tegra KBC driver even when/if U-Boot does acquire a
higher layer that deals with this kind of thing. That's because they're
SW concepts not part of the HW/HW-binding.
--
nvpublic
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
be to copy-paste much of "include/spi.h" (including the structure and
most of the constants) into "include/exports.h".
Basically, if those SPI functions should be usable from outside code
then the structure definition and the flags to be passed in all need to
be available to the outside code as well.
Locally I just reverted the patch, but I'm not sure what the desired
long-term fix should be, since it seems silly to have to duplicate
spi.h in exports.h
Cheers,
Kyle Moffett
--
Kyle Moffett
eXMeritus Software
Integrated Intelligence
The Boeing Company
(703) 764-0925
(703) 812-1146 [FAX]
Kyle.D.Moffett at boeing.com
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
- drivers/input/keyboard.c has a translation table
- drivers/input/i8042.c has a translation table also, and supports
German and English
- this driver which has a translation table in the fdt, which seems
like a step forward
We can certainly have a discussion about shift key translation and how
it should work. The same discussion probably applies to un-shifted
keys though, since they may well be printed differently in other
languages. At least with the scheme in this series you can support any
keyboard you like and have complete control over how it behaves.
I think asking for a new input layer in U-Boot. But this does not
exist at present. Don't you think this is taking things a little far?
I am trying to upstream a hardware driver :-)
My reading of the Tegra keyboard driver in the kernel is that it
*could* use the keycode-plain and keycode-fn properties as given in
this series. They would replace the tegra_kbc_default_keymap[] array.
However, code would need to be added to create that array for use by
the upper layers of linux keyboard input, since presumably it will be
a while before the kernel's drivers/input/keyboard/matrix_keypad.c
supports an fdt-based mapping. It certainly will not use a shift or
ctrl mapping, since these are handled by upper layers of Linux input.
So after all this musing I see two options:
1. Modify this series to remove 'shift' support and make 'ctrl' use a
calculated value (i.e. unlike the other two existing U-Boot drivers).
We lose access to a number of symbols but I could hard-code a mapping
in for the keyboard on Seaboard, say.
2. a. Go with what we have, put a 'u-boot,' prefix on the
keycode-shift property and don't expect the kernel to ever use it. b.
Start talking on the U-Boot list about the need for a middle input
translation layer and a generic header file which defines key codes in
a standardized way. Then write this layer, get it accepted and
refactor the 3 keyboard drivers to use it.
Thoughts?
Regards,
Simon
>
> --
> nvpublic
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
entry/return, assignment of the args to registers (say 8 instructions
all up), and perhaps take advantage of already-calculated partial
expressions. Actually it took a bit of messing around to reduce the
overhead of this patch to that level.
>
>
>>>> - Make relocation symbols global so we can use them outside start.S
>>>
>>>
>>> Why should they relocation symbols ever be used outside of actually
>>> relocating?
>>
>>
>> Well since relocation is moving out of start.S to a generic library
>> which is not architecture-specific, we must make these symbols
>> available to it. Otherwise the generic code doesn't know what it is
>> relocating.
>
>
> Understood. My point is that they should not be made available to code ot=
her
> than the relocation code.
Oh I see. Yes of course.
Regards,
Simon
>
>> Regards,
>> Simon
>
>
> Amicalement,
> --
> Albert.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
not return from function, code goes on and loads u-boot, too. As result,
u-boot instead of linux is always started.
If I am not overseeing something, I'll fix in next version.
> + } else {
> + printf("The Expected Linux image was not"
> + "found. Please check your NAND"
> + "configuration.\n");
> + printf("Trying to start u-boot now...\n");
> + }
> + }
> #endif
> {
in fact we have not anymore the "else" branch, and now u-boot is loaded.
Regards,
Stefano
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
Regards,
Simon
>
> Kind regards,
>
> Remy
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
will never happen. The code you are talking about is sometimes
identical, sometimes slightly different. In some cases the order is
different. I see many ways of introducing breakages. I do agree that
doing one architecture at a time is best - with the proviso that we
need to pick archs that have the most features (so ARM and PowerPC I
suppose) to make sure we are not deluding ourselves as to the
simplicity of the task.
So perhaps a generic board init that is the default can be switched
off on board-by-board basic would be the right approach. Then we can
flick the switch while providing for those affected to still get work
done until bugs are reported and found?
>
>> Generic relocation is used (see previous series) but now rather than
>> calling relocate_code() to do everything, we call the individual
>> relocation steps one by one. Again this makes it easier to leave things
>> out, particularly for SPL.
>
> Note that not all arches need and/or use ELF relocation - Attacking this
> first does not move towards unity of board.c
It is a feature used by about half, and it does include the complexity
of jumping from pre-reloc to post-reloc init. I think it was a
reasonable first target.
>
>> ARM is a relatively large board.c file and one which I can test, therefo=
re
>> I think it is a good target for this series. On the other hand, x86 is
>> relatively small and simple, but different enough that it introduces a
>> few issues to be solved. So I have chosen both ARM and x86 for this seri=
es.
>>
>> The next target should probably be PowerPC, since it is large and has
>> some additional features. I suspect we may want to leave some of these
>> very architecture-specific functions in arch/powerpc/lib/board.c, taking
>> out only the generic code. I haven't felt a strong need to do this for
>> ARM/x86, but we could even go as far as putting the initcall list into
>> the architecture-specific board file if the architecture adds a lot of
>> unusual calls.
>>
>> A generic global_data structure is also required. This might upset a few
>> people. Here is my basic reasoning: most fields are the same, all
>> architectures include and need it, most global_data.h files already have
>> =A0#ifdefs to select fields for a particular SOC, so it is hard to
>> see why architecures are different in this area. We can perhaps add a
>> way to put architecture-specific fields into a separate header file, but
>> for now I have judged that to be counter-productive.
>>
>> There was dicussion on the list about passing gd_t around as a parameter
>> to pre-relocation init functions. I think this makes sense, but it can
>> be done as a separate change, and this series does not require it.
>
> This has been raised quite some time ago - The resulting code size increa=
se
> is not worth it. x86 can now emulate the 'gd is a register' so gd is now
> available and writtable always on every arch. As I said before, gd access
> is slightly more expensive (one instruction) and initialising the gd
> pointer is _very_ expensive (rebuilding the Global Descriptor Table) but
> this only happens three times in total, so I am happy to accept the penal=
ty
> for a unified architecture.
OK, well it is a separate change as I said. I see a small code size
increase also. Let's worry about that later.
>
>> While this series needs to stand on its own (as with the link script
>> cleanup series and the generic relocation series) the goal is the
>> unification of the board init code. So I hope we can address issues with
>> this in mind, rather than focusing too narrowly on particular ARM or x86
>> issues.
>>
>> Comments welcome. Note that the x86 side of this still needs a fair bit
>> of work, sorry.
>
> The big issue I have is that we now have two RFC's which have major impac=
ts
> on x86 and one of us is going to have to give way to the other :)
Well I posted my x86 patches so they are not just sitting in the long
grass on my machine. They are not complete, and I would likely need
your input on these anyway.
>
> My patch set is mostly re-factoring and has no impact on anybody else and
> is practically complete - I'll do one last RFC, but I think it's already
> close to 'PATCH' status
That's a separate series from my point of view. I can't comment on the
wierd x96-isms in the series, but I did read through each patch and it
all seems sensible to me.
>
>> Simon Glass (19):
>> =A0 Introduce generic global_data
>> =A0 Make relocation functions global
>> =A0 Add basic initcall implementation
>> =A0 define CONFIG_SYS_LEGACY_BOARD everywhere
>> =A0 Add generic post-relocation board_r.c
>> =A0 Add generic pre-relocation board_f.c
>> =A0 Add spl load feature
>> =A0 switch ARM over to generic board
>> =A0 arm: Remove unused code in board.c, global_data.h
>> =A0 Add CONFIG_SYS_SYM_OFFSETS to support offset symbols
>> =A0 x86: Remove compiler warning in sc520_timer.c
>> =A0 x86: Remove dead code in eNET
>> =A0 x86: Add processor library and relocation functions
>> =A0 Tidy up asm/generic sections.h to include x86 symbols
>> =A0 Add fields required by x86 to global_data
>> =A0 x86: Change stub example to use asm-generic/sections.h
>> =A0 x86: Add initial memory barrier macros
>> =A0 Bring in x86 to unified board architecture
>> =A0 x86: Remove unused board/global_data code
>
> There are several x86 patches which simply do not belong in this series
> (and some of which already have non-RFC patches submitted)
OK, these are the warnings I think. Probably I should build without
-Werrors and try to ignore them!
>
> I honestly think we should get the x86 init sequence patches finalised
> first for several reasons:
>
> =A0- Because x86 is so small, it provides a good test-bed - ELF relocatio=
n
> =A0 was first finalised on x86 (it came and went with varying levels of
> =A0 success previously)
> =A0- They bring x86 in line with other arches re: global data
> =A0- They are now fully run-tested
No disagreement there, and anyway as you can see the relocation stuff
mostly came from your x86 code. It will provide a good template for
getting x86 working properly with the generic board init.
What do you need from me to get that through?
Per Wolfgang's request to go with PPC as an early-adopter, this is
somewhat in conflict, since as you say, x86 is less feature-full than
ARM and much less than PowerPC.
Can anyone recommend a PowerPC board with a quick U-Boot program-run
cycle that I can easily get that will let me try out things there?
Regards,
Simon
>
> Regards,
>
> Graeme
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
to the appropriate property and read out the codes based on
(row,column) position.
If we have something like this, then in order for the keyboard to work
in U-Boot, vendors would need to create a completely separate ASCII
mapping. Yes I agree this is a bit of a pain, but the above map is
fairly easy to type in, and quite compact.
Given the push-back on the U-Boot list from Linux people about my
bindings, I would like to work out the U-Boot side in this thread if
possible, since it seems to be dependent on what Linux does. But I
hope what is created is efficient enough not to bloat U-Boot or
require an new input layer to be added just to use fdt.
Regards,
Simon
> +
> +Optional properties:
> +- linux,fn-keymap: A separate array of packed 1-cell entries similar to
> + =A0linux,keymap but only to be used when the function key modifier is
> + =A0active. This is used for keyboards that have a software-based modifi=
er
> + =A0key for 'Fn' but that need to describe the custom layout that should
> + =A0be used when said modifier key is active.
> +
> +- linux,fn-key: a 2-cell entry containing the < row column > of the
> + =A0function modifier key used to switch to the above linux,fn-keymap
> + =A0layout.
> +
> +Example:
> + =A0 =A0 =A0 linux,keymap =3D < 0x00030012
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00x0102003a >;
> + =A0 =A0 =A0 linux,fn-key =3D < 2 1 >;
> + =A0 =A0 =A0 linux,fn-keymap =3D < 0x0002004a >;
[snip]
Regards,
Simon
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
http://dev.gentoo.org/~vapier/u-boot/
>
> Also, at least one for the "mpc5xxx: Fix strict-aliasing warnings in
> usb_ohci.c" and "ppc4xx: Fix strict-aliasing warnings in usb_ohci.c"
> patches?
powerpc BC3450
powerpc cm5200
powerpc EVAL5200
powerpc galaxy5200
powerpc galaxy5200_LOWBOOT
powerpc galaxy5200_LOWBOOT
powerpc inka4x0
powerpc mcc200_COM12
powerpc mcc200_COM12_highboot
powerpc mcc200_COM12_highboot_SDRAM
powerpc mcc200_COM12_SDRAM
powerpc mcc200_COM12_highboot
powerpc mcc200_COM12_highboot_SDRAM
powerpc mcc200_COM12_highboot_SDRAM
powerpc mcc200_COM12_SDRAM
powerpc mcc200
powerpc mcc200_COM12
powerpc mcc200_COM12_highboot
powerpc mcc200_COM12_highboot_SDRAM
powerpc mcc200_COM12_SDRAM
powerpc mcc200_highboot
powerpc mcc200_highboot_SDRAM
powerpc mcc200_SDRAM
powerpc prs200
powerpc prs200_DDR
powerpc prs200_highboot
powerpc prs200_highboot_DDR
powerpc mcc200_highboot
powerpc mcc200_highboot_SDRAM
powerpc mcc200_highboot_SDRAM
powerpc mcc200_SDRAM
powerpc PM520_DDR
powerpc PM520
powerpc PM520_DDR
powerpc PM520_ROMBOOT
powerpc PM520_ROMBOOT_DDR
powerpc PM520_ROMBOOT_DDR
powerpc PM520_ROMBOOT
powerpc PM520_ROMBOOT_DDR
powerpc prs200_DDR
powerpc prs200
powerpc prs200_DDR
powerpc prs200_highboot
powerpc prs200_highboot_DDR
powerpc prs200_highboot_DDR
powerpc prs200_highboot
powerpc prs200_highboot_DDR
powerpc TB5200_B
powerpc TB5200
powerpc TB5200_B
powerpc Total5200
powerpc Total5200_lowboot
powerpc Total5200_Rev2
powerpc Total5200_Rev2_lowboot
powerpc Total5200_lowboot
powerpc Total5200_Rev2
powerpc Total5200_Rev2_lowboot
powerpc Total5200_Rev2_lowboot
powerpc v38b
and
powerpc acadia
powerpc acadia_nand
powerpc acadia_nand
powerpc bamboo
powerpc bamboo_nand
powerpc bamboo_nand
powerpc korat
powerpc korat_perm
powerpc korat_perm
powerpc pcs440ep
>
> I wonder why I don't see any such warnings. =A0Which exact commit ID are
> you building?
I was building with this :
commit 9a420986cccc9bd2c37affd931d627b3c3e72952
Author: Rob Herring <rob.herring@calxeda.com>
Date: Thu Dec 15 11:15:50 2011 +0000
ARM: highbank: enable networking and pxe
(so before all the common.h problems).
Regards,
Simon
>
> Thanks.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, =A0 =A0 MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> Make it right before you make it faster.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
"IGNORE_CRC bit: In SPI/SSI modes: When set to 1, deassert the chip
select (SSn) pin after the command is executed."
Then I tought that mxs_spi_end_xfer should be also called in the case
where bitlen==0. In current code this does not happen.
> It seems that the mainline linux only implements a GPIO based SPI driver.
> So we cannot take it for reference.
There is no mxs spi driver in the mainline kernel yet.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
apparently in the code
the env is default to MMC, which mismatch. please fix it.
> +
> +#if defined(CONFIG_ENV_IS_IN_MMC)
> +#define CONFIG_ENV_OFFSET =A0 =A0 =A0 =A0 =A0 =A0 =A0(6 * 64 * 1024)
> =A0#define CONFIG_SYS_MMC_ENV_DEV =A0 =A0 =A0 =A0 0
> +#elif defined(CONFIG_ENV_IS_IN_SPI_FLASH)
> +#define CONFIG_ENV_OFFSET =A0 =A0 =A0 =A0 =A0 =A0 =A0(768 * 1024)
> +#define CONFIG_ENV_SECT_SIZE =A0 =A0 =A0 =A0 =A0 (8 * 1024)
> +#define CONFIG_ENV_SPI_CS =A0 =A0 =A0 =A0 =A0 =A0 =A00x5300
I'm wondering how the CONFIG_ENV_SPI_CS could be 0x5300? Vague?
> +#define CONFIG_ENV_SPI_MODE =A0 =A0 =A0 =A0 =A0 =A0SPI_MODE_0
> +#endif
>
> =A0#define CONFIG_OF_LIBFDT
>
> --
> 1.7.1
>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
not just check for that and error (not silently continue) if it's
anything else?
> +}
> +
> +/**
> + * Page read/write function
> + *
> + * @param mtd mtd info structure
> + * @param chip nand chip info structure
> + * @param buf data buffer
> + * @param page page number
> + * @param with_ecc 1 to enable ECC, 0 to disable ECC
> + * @param is_writing 0 for read, 1 for write
> + * @return 0 when successfully completed
> + * -EIO when command timeout
> + */
> +static int nand_rw_page(struct mtd_info *mtd, struct nand_chip *chip,
> + uint8_t *buf, int page, int with_ecc, int is_writing)
> +{
> + u32 reg_val;
> + int tag_size;
> + struct nand_oobfree *free = chip->ecc.layout->oobfree;
> + /* 128 is larger than the value that our HW can support. */
> + u32 tag_buf[128];
> + char *tag_ptr;
> + struct nand_info *info;
> + struct fdt_nand *config;
> +
> + if (((int) buf) & 0x03) {
s/int/uintptr_t/ (or unsigned long)
> + printf("buf 0x%X has to be 4-byte aligned\n", (u32) buf);
%p
> + set_bus_width_page_size(&info->config, ®_val);
You need to set up the bus width and page size on every page transfer?
Why not figure out the value to write in the register at init time (thus
making it a good place to reject unsupported configurations)?
> + /* Set ECC selection, configure ECC settings */
> + if (with_ecc) {
> + tag_size = config->tag_bytes + config->tag_ecc_bytes;
> + reg_val |= (CFG_SKIP_SPARE_SEL_4
> + | CFG_SKIP_SPARE_ENABLE
> + | CFG_HW_ECC_CORRECTION_ENABLE
> + | CFG_ECC_EN_TAG_DISABLE
> + | CFG_HW_ECC_SEL_RS
> + | CFG_HW_ECC_ENABLE
> + | CFG_TVAL4
> + | (tag_size - 1));
> +
> + if (!is_writing) {
> + tag_size += config->skipped_spare_bytes;
> + invalidate_dcache_range((unsigned long) tag_ptr,
> + ((unsigned long) tag_ptr) + tag_size);
> + } else
> + flush_dcache_range((unsigned long) tag_ptr,
> + ((unsigned long) tag_ptr) + tag_size);
> + } else {
> + tag_size = mtd->oobsize;
> + reg_val |= (CFG_SKIP_SPARE_DISABLE
> + | CFG_HW_ECC_CORRECTION_DISABLE
> + | CFG_ECC_EN_TAG_DISABLE
> + | CFG_HW_ECC_DISABLE
> + | (tag_size - 1));
> + if (!is_writing) {
> + invalidate_dcache_range((unsigned long) chip->oob_poi,
> + ((unsigned long) chip->oob_poi) + tag_size);
> + } else {
> + flush_dcache_range((unsigned long) chip->oob_poi,
> + ((unsigned long) chip->oob_poi) + tag_size);
> + }
> + }
> + writel(reg_val, &info->reg->config);
> +
> + if (!is_writing) {
> + invalidate_dcache_range((unsigned long) buf,
> + ((unsigned long) buf) +
> + (1 << chip->page_shift));
> + } else {
> + flush_dcache_range((unsigned long) buf,
> + ((unsigned long) buf) +
> + (1 << chip->page_shift));
> + }
Please factor out all this cache stuff into a dma prepare function that
takes start, length, and is_writing. Is it even really needed to
invalidate rather than flush in the read case? It doesn't look like
these buffers are even going to be cacheline-aligned...
> +int fdt_decode_nand(const void *blob, int node, struct fdt_nand *config)
> +{
> + int err;
> +
> + config->reg = (struct nand_ctlr *)fdtdec_get_addr(blob, node, "reg");
> + config->enabled = fdtdec_get_is_enabled(blob, node);
> + config->width = fdtdec_get_int(blob, node, "width", 8);
> + err = fdtdec_decode_gpio(blob, node, "wp-gpios", &config->wp_gpio);
> + if (err)
> + return err;
> + err = fdtdec_get_int_array(blob, node, "nvidia,timing",
> + config->timing, FDT_NAND_TIMING_COUNT);
> + if (err < 0)
> + return err;
> +
> + /* Now look up the controller and decode that */
> + node = fdt_next_node(blob, node, NULL);
> + if (node < 0)
> + return node;
> +
> + config->page_data_bytes = fdtdec_get_int(blob, node,
> + "page-data-bytes", -1);
> + config->tag_ecc_bytes = fdtdec_get_int(blob, node,
> + "tag-ecc-bytes", -1);
> + config->tag_bytes = fdtdec_get_int(blob, node, "tag-bytes", -1);
> + config->data_ecc_bytes = fdtdec_get_int(blob, node,
> + "data-ecc-bytes", -1);
> + config->skipped_spare_bytes = fdtdec_get_int(blob, node,
> + "skipped-spare-bytes", -1);
> + config->page_spare_bytes = fdtdec_get_int(blob, node,
> + "page-spare-bytes", -1);
Has this binding been accepted into Linux's documentation or another
canonical source?
Usually vendor prefixes are asked for on such properties (similar to
"nvidia,timing").
> +/* Oh dear I suspect no one will like these Bit values? */
Indeed.
> +enum {
> + Bit0 = 1 << 0,
> + Bit1 = 1 << 1,
> + Bit2 = 1 << 2,
Please just open code this in the functional definitions.
> +enum {
> + CMD_TRANS_SIZE_BYTES1 = 0,
> + CMD_TRANS_SIZE_BYTES2,
> + CMD_TRANS_SIZE_BYTES3,
> + CMD_TRANS_SIZE_BYTES4,
> + CMD_TRANS_SIZE_BYTES5,
> + CMD_TRANS_SIZE_BYTES6,
> + CMD_TRANS_SIZE_BYTES7,
> + CMD_TRANS_SIZE_BYTES8,
> + CMD_TRANS_SIZE_BYTES_PAGE_SIZE_SEL
> +};
Why not just use the number of bytes directly, minus one?
-Scott
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
first time working on UBOOT thing. kindly direct me to the appropriate link
where I can download this for SPEAr1310.
Thanks in advance.
Regards,
Zeeshan Aslam
--e0cb4efe3248e3910004b7686d4a--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
with the case where malloc cannot fit below the text area.
I find any sort of messing with the ICE startup a pain - although I
have often been able to script it. But for me I need to attach the
device tree to the binary and a few other things so I might as well
disable relocation at the same time. It also allows me to debug
seamlessly in board_init_f() as well as afterwards.
I will send a patch.
It would be good to get something in mainline despite the
protestations, if only to avoid all the work that people have to do to
figure out this problem.
Regards,
Simon
>
> br,
> Aneesh
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
becoming hung by bad code or corrupted memory or files. By automatically
feeding them the code has circumvented this important feature.
So some examples of where I would expect the watchdog to recover from but
with the current code it will not. If u-boot loads a corrupted OS image,
when the code starts but before it gets to the point that it has replaced
u-boots exception handler it falls into an infinite loop it will hang and
the uboot exception handler will continue to keep the system "running".
Another example and how we actually discovered this bug due to a leak in
a network driver that after many loops would run u-boot out of memory.
Once this occurs the hush parser drops into a "for ;;" loop again this is
not recovered by the watchdog.
So while I understand that some users may want to have the cpu
automatically reset the watchdog, We don't. I believe that setting the
default value of CONFIG_SYS_WATCHDOG_FREQ if it was not defined is a
serious bug. The feature should not be enabled if I did not define this
variable.
I have attached what we believe is a patch to address our concerns and
still allow this to be set by a target that wishes to do so.
Comments are appreciated.
--eric
---------------------------------
Eric Olsen
Staff Software Engineer
Google, Inc.
650-253-2767
On Mon, Feb 13, 2012 at 12:36 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Eric,
>
> In message <CAOzkcmEydTOcGQ7=
> LL9NHkyuUtJJbE73DYceOsffphtrGU7ZYg at mail.gmail.com> you wrote:
> >
> > Today we discovered an issue with the implementation of watchdog on the
> > PowerPc. In the file arch/powerpc/lib/interrupt.c, the code currently
> > automatically feeds the watchdog via the timer interrupt handler if
> either
> > CONFIG_WATCHDOG or CONFIG_HW_WATCHDOG are defined. I am not exactly sure
> > when this got added or why, but I'd guess that for most systems this is
> not
> > a good feature. For us it is exactly the opposite of what we want.
> Would
> > either of you object to a patch that uses a different config flag to
> enable
> > this.
>
> You don't mention it, but I assume you are referring to U-Boot code
> here.
>
> Please always poost U-Boot related questions to the U-Boot mailing
> list only (unless you are asking for commercial support from DENX).
>
>
> I do not exactly understand why you think the current implementation
> is not OK as it - my guess is that your expectations are higher than
> what U-Boot offers. U-Boot is a boot loader, not an OS, and we use a
> lot of simplistic concepts - trading complexity and features which
> you can expect from a full-flavored OS for small code size and
> simple, easily maintainable code. U-Boot is capable to triggering a
> hardware watchdog (which is nevessary, as there are systems where
> this cannot be switched off or suspended), but we make no attempts to
> implement watchdog monitoring of the U-Boot code itself. If U-Boot
> should hang or crash, this is not expected to be detected or
> recovered by the watchdog.
>
> As such, the existing code does what it is supposed to do.
>
>
> Patches to add additional, new features to U-Boot (like full watchdog
> monitoring) are of course welcome. Please post these on the mailing
> list, then.
>
> Thanks.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> Is a computer language with goto's totally Wirth-less?
>
--20cf3071d0cebd882804b8e180df--
--20cf3071d0cebd882b04b8e180e1
Content-Type: application/octet-stream; name=patch
Content-Disposition: attachment; filename=patch
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gym52aj71
TWFrZSBhdXRvbWF0aWMgd2F0Y2hkb2cgcmVzZXQgb3B0aW9uYWwuCiBCYXNlZCB1cG9uIGRlZmlu
aW5nIENPTkZJR19TWVNfV0FUQ0hET0dfRlJFUQoKU2lnbmVkLW9mZi1ieTogRXJpYyBPbHNlbiA8
ZW9sc2VuQGdvb2dsZS5jb20+CgotLS0gdS1ib290L2FyY2gvcG93ZXJwYy9saWIvaW50ZXJydXB0
cy5jLm9yaWcJMjAxMi0wMi0xMiAwMToxMTozMy4wMDAwMDAwMDAgLTA4MDAKKysrIHUtYm9vdC9h
cmNoL3Bvd2VycGMvbGliL2ludGVycnVwdHMuYwkyMDEyLTAyLTEzIDE1OjExOjQwLjg5MDc1ODQy
NiAtMDgwMApAQCAtNDAsMTAgKzQwLDYgQEAgdm9pZCBfX2JvYXJkX3Nob3dfYWN0aXZpdHkgKHVs
b25nIGR1bW15KQogfQogI2VuZGlmIC8qIENPTkZJR19TSE9XX0FDVElWSVRZICovCiAKLSNpZm5k
ZWYgQ09ORklHX1NZU19XQVRDSERPR19GUkVRCi0jZGVmaW5lIENPTkZJR19TWVNfV0FUQ0hET0df
RlJFUSAoQ09ORklHX1NZU19IWiAvIDIpCi0jZW5kaWYKLQogZXh0ZXJuIGludCBpbnRlcnJ1cHRf
aW5pdF9jcHUgKHVuc2lnbmVkICopOwogZXh0ZXJuIHZvaWQgdGltZXJfaW50ZXJydXB0X2NwdSAo
c3RydWN0IHB0X3JlZ3MgKik7CiAKQEAgLTEyMywxMCArMTE5LDEyIEBAIHZvaWQgdGltZXJfaW50
ZXJydXB0IChzdHJ1Y3QgcHRfcmVncyAqcmUKIAogCXRpbWVzdGFtcCsrOwogCisjaWZkZWYgQ09O
RklHX1NZU19XQVRDSERPR19GUkVRCiAjaWYgZGVmaW5lZChDT05GSUdfV0FUQ0hET0cpIHx8IGRl
ZmluZWQgKENPTkZJR19IV19XQVRDSERPRykKIAlpZiAoKHRpbWVzdGFtcCAlIChDT05GSUdfU1lT
X1dBVENIRE9HX0ZSRVEpKSA9PSAwKQogCQlXQVRDSERPR19SRVNFVCAoKTsKICNlbmRpZiAgICAv
KiBDT05GSUdfV0FUQ0hET0cgfHwgQ09ORklHX0hXX1dBVENIRE9HICovCisjZW5kaWYgICAgLyog
Q09ORklHX1NZU19XQVRDSERPR19GUkVRICovCiAKICNpZmRlZiBDT05GSUdfU1RBVFVTX0xFRAog
CXN0YXR1c19sZWRfdGljayAodGltZXN0YW1wKTsK
--20cf3071d0cebd882b04b8e180e1--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
Can you increase the timeout and check if this scenario persists.
Regards,
Rachna.
>=20
> Regards,
> Thomas
>=20
<SNIP>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
Add support for dataflash to U-boot environment settings tool.
author Remy Bohmer <linux@bohmer.net>
Sat, 12 Feb 2011 18:06:2=
6 +0000 (19:06 +0100)
committer Wolfgang Denk <wd@denx.de>
Tue, 12 Apr 2011 20:58:3=
4 +0000 (22:58 +0200)
Viel spas !
________________________________
This e-mail and any attachments may contain confidential and/or privileged =
information and is intended solely for the addressee. Any unauthorised use,=
review, retransmissions, dissemination, copying or other use of this infor=
mation by persons or entities other than the intended recipient is strictly=
prohibited.
To elektronsko sporo?ilo in vse morebitne priloge lahko vsebujejo informaci=
je zaupne narave in so namenjene izklju?no naslovniku. Fizi?ni ali pravni o=
sebi, ki ni naslovnik, je kakr?nakoli nepoobla??ena uporaba, pregledovanje,=
po?iljanje, raz?irjanje, kopiranje ali drug na?in razpolaganja z vsebino s=
poro?ila strogo prepovedana.
--_000_F3420A72FC49F64FA9558E3C3BC4DD8B19CF4907A8NTMAILKRiskra_--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
can't really remember why it worked.
Given your efforts on the cmdline parsing I'm beginning to think we
should perhaps add os_printf() and os_printf_stderr() and provide an
explicit interface. It might only be useful prior to main(), then
again I'm not so sure.
> -mike
Regards,
Simon
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
and it would be nice to have in the commit message an explanation of
what this register is, what you are changing and why.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
s5pc2xx and exynos4 and exynos5.. etc.
>
>> number of tzpc. It can be covered one exynos_tzpc. or =A0we can define
>> it for each SoC.
> One structure is enough as fields are same.
>
Thanks
Minkyu Kang.
--=20
from. prom.
www.promsoft.net
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
>>
>>> number of tzpc. It can be covered one exynos_tzpc. or we can define
>>> it for each SoC.
>> One structure is enough as fields are same.
>>
>
> Thanks
> Minkyu Kang.
--
Tushar Behera
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
not returning NULL.
Your argument seems to boil down to "relying on malloc(0) returning something sane is messed up"
so therefore u-boot malloc should take the easy route and just return NULL for malloc(0).
Jocke
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
#define CONFIG_ENV_OFFSET 0x60000
#define CONFIG_ENV_SIZE 0x20000
root:/> fw_printenv
Cannot read bad block mark: Invalid argument
root:/> strace fw_printenv
ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
{B57600 opost isig icanon echo ...}) =3D 0
ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
{B57600 opost isig icanon echo ...}) =3D 0
open("/etc/fw_env.config", O_RDONLY) =3D 3
ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
0x2decca8) =3D -1 ENOTTY (Inappropriate ioctl for device)
mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_SHARED|MAP_ANONYMOUS|0x4000000, 0, 0) =3D 0x203b000
read(3, "# Configuration file for fw_(pri"..., 256) =3D 256
read(3, "Flash sector size\tNumber of sect"..., 256) =3D 163
read(3, "", 256) =3D 0
close(3) =3D 0
stat("/dev/mtd0", {st_mode=3DS_IFCHR|0660, st_rdev=3Dmakedev(90, 0), =
...}) =3D
0
mmap2(NULL, 135168, PROT_READ|PROT_WRITE,
MAP_SHARED|MAP_ANONYMOUS|0x4000000, 0, 0) =3D 0x2e00000
open("/dev/mtd0", O_RDONLY) =3D 3
ioctl(3, MEMGETINFO or MFB_SET_CHROMA_KEY, {type=3DMTD_NANDFLASH,
flags=3DMTD_WRITEABLE, size=3D0x80000, erasesize=3D0x20000, =
writesize=3D0x800,
oobsize=3D0x40, padding=3D0xffffffff}) =3D 0
ioctl(3, MEMGETBADBLOCK, [393216]) =3D 1
ioctl(3, MEMGETBADBLOCK, [524288]) =3D -1 EINVAL (Invalid argument)
write(2, "Cannot read bad block mark", 26Cannot read bad block mark) =3D
26
write(2, ": ", 2: ) =3D 2
write(2, "Invalid argument", 16Invalid argument) =3D 16
write(2, "\n", 1
) =3D 1
close(3) =3D 0
_exit(1) =3D ?
root:/>
I've been dealing with Mike Frysinger on the linux-mtd list and he
recommended that I shoot this up to you guys.
His comment was "your config though says you only have 1 block starting
at 0x60000 with a length of 0x20000. so there's no reason it should be
testing 0x80000 -- after all, you only care about bytes 0x60000 -
0x7ffff."
I am hoping there is something that I am doing that is causing this. I
would appreciate some info.
Thank you.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
kernel as part of the boot, it can house an initrd so that extending
the utilities of the bootloader will be easier to handle, etc. If this
is in error, please correct me.
As for 1 & 2, these I just don't know about. I'm guessing that anything
supported in either the Linux kernel or already in u-boot should be
fairly easy to port into Barebox. Here, however, I have to define for
Mgt clearly what does "fairly" mean.
Thanks in advance for any help you can provide.
Andy
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
it's board specific. I added a new patch for s3c440 gpio driver. Now in the
board file we have no more magic bloat.
>> +/*
>> + * When booting from NAND, it is impossible to access the lowest addresses
>> + * due to the SteppingStone being in the way. Luckily the NOR doesn't really
>> + * care about the highest 16 bits of address, so we set the controlers
>> + * registers to go and poke over there, instead.
>> + */
>> +#define PHYS_FLASH_1 0x0
>> +#define CONFIG_SYS_FLASH_BASE 0x0
>
>Urghh... this sounds very much like a serious design issue?
About this point, I ported it from the old version uboot as well. It may need
some investigation, but I remember it was a big problem with this board. In the
case of a NAND boot, we don't have access to NOR because the SteppingStone
(SRAM) is mapped at the same range.
Gabriel Huau (2):
Add GPIO Driver and IOMUX definition for S3C2440
Add support for MINI2440 (s3c2440).
MAINTAINERS | 4 +
arch/arm/include/asm/arch-s3c24x0/gpio.h | 183 +++++++++++++++++++++++++
arch/arm/include/asm/arch-s3c24x0/iomux.h | 197 +++++++++++++++++++++++++++
board/friendlyarm/mini2440/Makefile | 44 ++++++
board/friendlyarm/mini2440/mini2440.c | 135 +++++++++++++++++++
board/friendlyarm/mini2440/mini2440.h | 144 ++++++++++++++++++++
boards.cfg | 1 +
doc/README.mini2440 | 28 ++++
drivers/gpio/Makefile | 1 +
drivers/gpio/s3c2440_gpio.c | 74 ++++++++++
include/configs/mini2440.h | 209 +++++++++++++++++++++++++++++
11 files changed, 1020 insertions(+)
create mode 100644 arch/arm/include/asm/arch-s3c24x0/gpio.h
create mode 100644 arch/arm/include/asm/arch-s3c24x0/iomux.h
create mode 100644 board/friendlyarm/mini2440/Makefile
create mode 100644 board/friendlyarm/mini2440/mini2440.c
create mode 100644 board/friendlyarm/mini2440/mini2440.h
create mode 100644 doc/README.mini2440
create mode 100644 drivers/gpio/s3c2440_gpio.c
create mode 100644 include/configs/mini2440.h
--
1.7.9.5
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
--=20
Otavio Salvador=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0O=
.S. Systems
E-mail: otavio at ossystems.com.br=A0 http://www.ossystems.com.br
Mobile: +55 53 9981-7854=A0 =A0 =A0 =A0=A0 =A0 =A0 =A0http://projetos.ossys=
tems.com.br
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
access the data is the same. So it ought to be easy to handle.
--=20
Otavio Salvador=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0O=
.S. Systems
E-mail: otavio at ossystems.com.br=A0 http://www.ossystems.com.br
Mobile: +55 53 9981-7854=A0 =A0 =A0 =A0=A0 =A0 =A0 =A0http://projetos.ossys=
tems.com.br
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
age" it would be able to package a raw
image into a blob understood by u-boot. I have discovered a few "mkimage" f=
iles=2C such as mkimage.o=2C mkimage=2C other
than mkimage.c=2C mkimage.h and mkimage.l. But=2C I soon found out that I c=
ould not execute the command: mkimage.
What should I do in order to execute the command? There isn't a file called=
mkimage.bin generated!!
=20
Any comment or suggestions would be greatly appreciated.
=20
=20
Thanks=2C
=20
Ivan
=
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
> +/* CONFIG_SYS_TCLK is 200000000 by default */
> +#else
> +#error "unknown board"
> +#endif
> +
> +/*
> + * General configuration options
> + */
> +#define CONFIG_FEROCEON_88FR131 /* CPU Core subversion */
> +#define CONFIG_KIRKWOOD /* SOC Family Name */
> +#define CONFIG_KW88F6281 /* SOC Name */
> +
> +#define CONFIG_SKIP_LOWLEVEL_INIT /* disable board lowlevel_init */
> +#define CONFIG_MISC_INIT_R
> +#define CONFIG_SHOW_BOOT_PROGRESS
> +
> +#define CONFIG_RANDOM_MACADDR
> +#define CONFIG_SETENV_ENETADDR_BY_INDEX
> +#define CONFIG_KIRKWOOD_GPIO
> +#define CONFIG_OF_LIBFDT
> +
> +#define CONFIG_SYS_NO_FLASH
> +#define CONFIG_SYS_HUSH_PARSER
> +#define CONFIG_SYS_CONSOLE_IS_IN_ENV
> +#define CONFIG_SYS_CONSOLE_INFO_QUIET
> +
> +/*
> + * Enable u-boot API for standalone programs.
> + */
> +#define CONFIG_API
> +
> +/*
> + * Commands configuration
> + */
> +#include <config_cmd_default.h>
> +#define CONFIG_CMD_DHCP
> +#define CONFIG_CMD_ELF
> +#define CONFIG_CMD_ENV
> +#define CONFIG_CMD_EXT2
> +#define CONFIG_CMD_FAT
> +#define CONFIG_CMD_IDE
> +#define CONFIG_CMD_PING
> +#define CONFIG_CMD_PING
> +#define CONFIG_CMD_SF
> +#define CONFIG_CMD_SPI
> +#define CONFIG_CMD_USB
> +
> +#define CONFIG_DOS_PARTITION
> +#define CONFIG_EFI_PARTITION
> +
> +/*
> + * mv-common.h should be defined after CMD configs since it used them
> + * to enable certain macros
> + */
> +#include "mv-common.h"
> +
> +/* ST M25P40 */
> +#undef CONFIG_SPI_FLASH_MACRONIX
> +#define CONFIG_SPI_FLASH_STMICRO
> +#undef CONFIG_ENV_SPI_MAX_HZ
> +#define CONFIG_ENV_SPI_MAX_HZ 25000000
> +#undef CONFIG_SF_DEFAULT_SPEED
> +#define CONFIG_SF_DEFAULT_SPEED 25000000
> +
> +
> +#undef CONFIG_SYS_PROMPT
> +#define CONFIG_SYS_PROMPT "=3D> "
> +#define CONFIG_SYS_PROMPT_HUSH_PS2 "> "
> +
> +/*
> + * Environment variables configurations
> + */
> +#ifdef CONFIG_SPI_FLASH
> +#define CONFIG_SYS_MAX_FLASH_BANKS 1
> +#define CONFIG_SYS_MAX_FLASH_SECT 8
> +#define CONFIG_ENV_IS_IN_SPI_FLASH 1
> +#define CONFIG_ENV_SECT_SIZE 0x10000 /* 64K */
> +#else
> +#define CONFIG_ENV_IS_NOWHERE
> +#endif
> +
> +#define CONFIG_ENV_SIZE 0x10000 /* 64k */
> +#define CONFIG_ENV_OFFSET 0x70000 /* env starts here */
Why this is too far, what it u-boot.bin size?
Regards.
Prafulla . . .
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
And this four were squshed to one:
[PATCH 01/20] arm/km: enable spi claim bus
[PATCH 02/20] arm/km: use correct kw_gpio function for NAND/SPI switching
[PATCH 18/20] arm/km: implement weak function board_spi_clam_bus/release
[PATCH 19/20] arm/km: remove spi toggle command
see:
http://lists.denx.de/pipermail/u-boot/2012-June/126139.html
Additionaly
[PATCH 17/20] arm/km: fix testpin detection for kmcoge5un
was squashed to kmcoge5un board support, which makes logically
sense.
cc: Holger Brunck <holger.brunck@keymile.com>
cc: Valentin Longchamp <valentin.longchamp@keymile.com>
cc: Prafulla Wadaskar <prafulla@marvell.com>
Holger Brunck (6):
arm/km: add kmnusa board support
arm/km: add kmcoge5un board support
arm/km: convert mgcoge3un target to km_kirkwood
arm/km: remove portl2.h and use km_kirkwood instead
arm/km: cleanup km_kirkwood boards
arm/km: remove calls to kw_gpio_* in board_early_init_f
Thomas Herzmann (1):
arm/km: add implementation for read_dip_switch
Valentin Longchamp (7):
arm/km: correct init of 88e6352 switch in the reset_phy function
arm/km: enable BOCO2 FPGA download support
arm/km: redefine piggy 4 reg names to avoid conflicts
arm/km: add support for external switch configuration
arm/km: enable external switch configuration for kmnusa
arm/km: skip FPGA config when already configured
arm/km: support the 2 PCIe fpga resets
MAINTAINERS | 2 +
board/keymile/common/common.h | 5 +
board/keymile/km_arm/Makefile | 8 +
board/keymile/km_arm/fpga_config.c | 256 ++++++++++++++++++++++
board/keymile/km_arm/km_arm.c | 127 ++++++++---
board/keymile/km_arm/kwbimage_128M16_1.cfg | 296 ++++++++++++++++++++++++++
board/keymile/km_arm/kwbimage_256M8_1.cfg | 296 ++++++++++++++++++++++++++
board/keymile/km_arm/managed_switch.c | 316 ++++++++++++++++++++++++++++
board/keymile/km_arm/managed_switch.h | 106 ++++++++++
boards.cfg | 10 +-
include/configs/km/km_arm.h | 48 ++++-
include/configs/km_kirkwood.h | 154 +++++++++++++--
include/configs/mgcoge3un.h | 87 --------
include/configs/portl2.h | 85 --------
14 files changed, 1565 insertions(+), 231 deletions(-)
create mode 100644 board/keymile/km_arm/fpga_config.c
create mode 100644 board/keymile/km_arm/kwbimage_128M16_1.cfg
create mode 100644 board/keymile/km_arm/kwbimage_256M8_1.cfg
create mode 100644 board/keymile/km_arm/managed_switch.c
create mode 100644 board/keymile/km_arm/managed_switch.h
delete mode 100644 include/configs/mgcoge3un.h
delete mode 100644 include/configs/portl2.h
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
happens, due to
that board_init_r not been called.
Could you please help me, Do I need to change any TEXT_BASE or liker script
for this.?
I have analyzed and understood the code and seems to be some wired thing on
start code.
I found some hack for this, but does it a valid issue or did I make any
mistake.
Request for your help.
Regards,
Jagan.
--bcaec517a7a604ed5504c2d50d57--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
> +#define CONFIG_SPL_MAX_SIZE 0x00004000
That's nice!
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
Regards..
Prafulla . . .
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
(without dtsi)
because it is much cleaner then using 3 dts files.
Thanks,
Michal
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
=09/*
=09 * The meaning of MO_C bit varies by the chip type.
=09 * From PCF8563 datasheet: this bit is toggled when the years
=09 * register overflows from 99 to 00
=09 * 0 indicates the century is 20xx
=09 * 1 indicates the century is 19xx
=09 * From RTC8564 datasheet: this bit indicates change of
=09 * century. When the year digit data overflows from 99 to 00,
=09 * this bit is set. By presetting it to 0 while still in the
=09 * 20th century, it will be set in year 2000, ...
=09 * There seems no reliable way to know how the system use this
=09 * bit. So let's do it heuristically, assuming we are live in
=09 * 1970...2069.
=09 */
As U-Boot's PCF8563 driver does not say it is supposed to support the RTC85=
64,
make this driver compatible with Linux's by giving the opposite meaning to =
the
century bit.
Signed-off-by: Beno=C3=AEt Th=C3=A9baudeau <benoit.thebaudeau@advansee.com>
Cc: Wolfgang Denk <wd@denx.de>
---
.../drivers/rtc/pcf8563.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git u-boot-66714b1.orig/drivers/rtc/pcf8563.c u-boot-66714b1/drivers=
/rtc/pcf8563.c
index 339e5f6..a028533 100644
--- u-boot-66714b1.orig/drivers/rtc/pcf8563.c
+++ u-boot-66714b1/drivers/rtc/pcf8563.c
@@ -72,7 +72,7 @@ int rtc_get (struct rtc_time *tmp)
=09tmp->tm_hour =3D bcd2bin (hour & 0x3F);
=09tmp->tm_mday =3D bcd2bin (mday & 0x3F);
=09tmp->tm_mon =3D bcd2bin (mon_cent & 0x1F);
-=09tmp->tm_year =3D bcd2bin (year) + ((mon_cent & 0x80) ? 2000 : 1900);
+=09tmp->tm_year =3D bcd2bin (year) + ((mon_cent & 0x80) ? 1900 : 2000);
=09tmp->tm_wday =3D bcd2bin (wday & 0x07);
=09tmp->tm_yday =3D 0;
=09tmp->tm_isdst=3D 0;
@@ -94,7 +94,7 @@ int rtc_set (struct rtc_time *tmp)
=20
=09rtc_write (0x08, bin2bcd(tmp->tm_year % 100));
=20
-=09century =3D (tmp->tm_year >=3D 2000) ? 0x80 : 0;
+=09century =3D (tmp->tm_year >=3D 2000) ? 0 : 0x80;
=09rtc_write (0x07, bin2bcd(tmp->tm_mon) | century);
=20
=09rtc_write (0x06, bin2bcd(tmp->tm_wday));
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
struct qTD {
=09/* this part defined by EHCI spec */
=09uint32_t qt_next;=09=09/* see EHCI 3.5.1 */
#define=09QT_NEXT_TERMINATE=091
=09uint32_t qt_altnext;=09=09/* see EHCI 3.5.2 */
=09uint32_t qt_token;=09=09/* see EHCI 3.5.3 */
=09uint32_t qt_buffer[5];=09=09/* see EHCI 3.5.4 */
=09uint32_t qt_buffer_hi[5];=09/* Appendix B */
=09/* pad struct for 32 byte alignment */
=09uint32_t unused[3];
};
So sizeof(struct qTD) is 16 * 32 bits =3D 64 bytes. For the worst alignment=
case,
the number of qTDs to allocate for 65535 blocks of 512 bytes (worst MSC cas=
e
with 512-byte sectors) is DIV_ROUND_UP(65535 * 512, 4 * 4096) =3D 2048 qTDs=
, i.e.
128 kiB. For the same transfer size with the best alignment case, it is
DIV_ROUND_UP(65535 * 512, 5 * 4096) =3D 1639 qTDs, i.e. 104896 B.
But if we consider extreme cases, these figures can get even larger, e.g. w=
ith
4-kiB storage sectors.
So we could perhaps issue a #error in ehci-hcd or in usb_storage if
CONFIG_SYS_MALLOC_LEN is not large enough, but I don't think it's a good id=
ea
because:
- the threshold value would have to depend on runtime block sizes or somet=
hing,
which could lead to a big worst worst case that would almost never happe=
n in
real life, so giving such an unrealistic heap size constraint would be
cumbersome,
- reaching the top sizes would mean reading a huge file or something to a =
large
buffer (much larger than the qTDs this transfer requires), which would v=
ery
likely be heap-allocated (except for commands like fatload), so
CONFIG_SYS_MALLOC_LEN would already have to be large for the application=
,
- for command line operations like fatload, transfers of uncontrolled leng=
ths
could simply crash U-Boot if they go too far in memory, which means that
users of such commands need to know what they are doing anyway, so they =
have
to control transfer sizes,
- there is already a runtime error displayed in case of allocation failure=
.
Marek, what do you think?
Best regards,
Beno=C3=AEt
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
negotiation is enabled in RMII mode. Some boards based on da850 need
to suppress this procedure.
CC: Rajashekhara, Sudhakar <sudhakar.raj@ti.com>
CC: Lad, Prabhakar <prabhakar.lad@ti.com>
CC: Hadli, Manjunath <manjunath.hadli@ti.com>
CC: sbabic at denx.de
CC: Tom Rini <trini@ti.com>
Signed-off-by: Bastian Ruppert <Bastian.Ruppert@Sewerin.de>
---
drivers/net/davinci_emac.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index b2516d1..fe988d7 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -897,7 +897,8 @@ int davinci_emac_initialize(void)
}
#if defined(CONFIG_DRIVER_TI_EMAC_USE_RMII) && \
- defined(CONFIG_MACH_DAVINCI_DA850_EVM)
+ defined(CONFIG_MACH_DAVINCI_DA850_EVM) && \
+ !defined(CONFIG_DRIVER_TI_EMAC_RMII_NONEG)
for (i = 0; i < num_phy; i++) {
if (phy[i].is_phy_connected(i))
phy[i].auto_negotiate(i);
--
1.7.0.4
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
the ITB as a single blob with no options. I'm looking at the dtc
1.2.0 source.
-Joe
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
I guess I will have to change back as I won't remember to switch this
feature off before generating patches.
Jocke
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
and has been already done by you. I did send a v2 which enables DMA
for SPI and rewords the commit log for the same used by you in m28evk
change. This way we are clear about the change.
--
Otavio Salvador O.S. Systems
E-mail: otavio at ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
negotiation is enabled in RMII mode. Some boards based on da850 need
to suppress this procedure.
CC: Rajashekhara, Sudhakar <sudhakar.raj@ti.com>
CC: Lad, Prabhakar <prabhakar.lad@ti.com>
CC: Hadli, Manjunath <manjunath.hadli@ti.com>
CC: sbabic at denx.de
Acked-by: Stefano Babic <sbabic@denx.de>
CC: Tom Rini <trini@ti.com>
Signed-off-by: Bastian Ruppert <Bastian.Ruppert@Sewerin.de>
---
drivers/net/davinci_emac.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index b2516d1..fe988d7 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -897,7 +897,8 @@ int davinci_emac_initialize(void)
}
#if defined(CONFIG_DRIVER_TI_EMAC_USE_RMII) && \
- defined(CONFIG_MACH_DAVINCI_DA850_EVM)
+ defined(CONFIG_MACH_DAVINCI_DA850_EVM) && \
+ !defined(CONFIG_DRIVER_TI_EMAC_RMII_NONEG)
for (i = 0; i < num_phy; i++) {
if (phy[i].is_phy_connected(i))
phy[i].auto_negotiate(i);
--
1.7.0.4
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
negotiation is enabled in RMII mode. Some boards based on da850 need
to suppress this procedure.
CC: Rajashekhara, Sudhakar <sudhakar.raj@ti.com>
CC: Lad, Prabhakar <prabhakar.lad@ti.com>
CC: Hadli, Manjunath <manjunath.hadli@ti.com>
CC: sbabic at denx.de
Acked-by: Stefano Babic <sbabic@denx.de>
CC: Tom Rini <trini@ti.com>
Signed-off-by: Bastian Ruppert <Bastian.Ruppert@Sewerin.de>
---
v4:
- use more expressive CONFIG name
v3:
v2:
- related to other patches of this series
---
drivers/net/davinci_emac.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index b2516d1..1db586d 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -897,7 +897,8 @@ int davinci_emac_initialize(void)
}
#if defined(CONFIG_DRIVER_TI_EMAC_USE_RMII) && \
- defined(CONFIG_MACH_DAVINCI_DA850_EVM)
+ defined(CONFIG_MACH_DAVINCI_DA850_EVM) && \
+ !defined(CONFIG_DRIVER_TI_EMAC_RMII_NO_NEGOTIATE)
for (i = 0; i < num_phy; i++) {
if (phy[i].is_phy_connected(i))
phy[i].auto_negotiate(i);
--
1.7.0.4
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
> + response[resp_indx] =3D SDIO_REG_READ16(SDIO_RSP(resp_indx)=
);
> +
> + /* Copy the response to the response buffer */
> + if (cmd->resp_type & MMC_RSP_PRESENT) {
> + cmd->response[0] =3D ((response[2] & 0x3f) << (8 - 8)) |
> + ((response[1] & 0xffff) << (14 - 8)) |
> + ((response[0] & 0x3ff) << (30 - 8));
> + if (cmd->resp_type & MMC_RSP_136) {
> + cmd->response[3] =3D ((response[7] & 0x3fff) << 8) =
|
> + ((response[6] & 0x3ff) << 22);
> + cmd->response[2] =3D ((response[6] & 0xfc00) >> 10)=
|
> + ((response[5] & 0xffff) << 6) |
> + ((response[4] & 0x3ff) << 22);
> + cmd->response[1] =3D ((response[4] & 0xfc00) >> 10)=
|
> + ((response[3] & 0xffff) << 6) |
> + ((response[2] & 0x3ff) << 22);
> + cmd->response[0] =3D ((response[2] & 0xfc00) >> 10)=
|
> + ((response[1] & 0xffff) << 6) |
> + ((response[0] & 0x3ff) << 22);
> + }
> + }
> +
> +#ifdef DEBUG
> + printf("resp index[0x%x] ", response[0] >> 10);
> + printf("[0x%x] ", cmd->response[0]);
> + printf("[0x%x] ", cmd->response[1]);
> + printf("[0x%x] ", cmd->response[2]);
> + printf("[0x%x] ", cmd->response[3]);
> + printf("\n");
> +#endif
> +
> + return 0;
> +}
> +
> +static void mrvl_mmc_set_clk(unsigned long clk)
> +{
> + unsigned int m;
> +
> + m =3D MRVL_MMC_BASE_FAST_CLOCK/(2*clk) - 1;
Provide some reference for this calculation?
> +#ifdef DEBUG
> + printf("mrvl_mmc_set_clk: dividor =3D 0x%x clock=3D%d\n", m, clk);
> +#endif
> + SDIO_REG_WRITE32(SDIO_CLK_DIV, m & 0x7ff);
> + udelay(10*1000);
Instead of delays, may you check certain status bit?
> +}
> +
> +static void mrvl_mmc_set_bus(unsigned int bus)
> +{
> + ushort reg;
> +
> +#ifdef DEBUG
> + printf("mrvl_mmc_set_bus: bus =3D 0x%d\n", bus);
> +#endif
> + reg =3D SDIO_REG_READ16(SDIO_HOST_CTRL);
> + reg &=3D ~(1 << 9);
> + switch (bus) {
> + case 4:
> + reg |=3D SDIO_HOST_CTRL_DATA_WIDTH_4_BITS;
> + break;
> + case 1:
> + default:
> + reg |=3D SDIO_HOST_CTRL_DATA_WIDTH_1_BIT;
> + }
> + SDIO_REG_WRITE16(SDIO_HOST_CTRL, reg);
> + udelay(10*1000);
Ditto
> +}
Insert a line here
> +static void mrvl_mmc_set_ios(struct mmc *mmc)
> +{
> +#ifdef DEBUG
> + printf("bus[%d] clock[%d]\n", mmc->bus_width, mmc->clock);
> +#endif
> + mrvl_mmc_set_bus(mmc->bus_width);
> + mrvl_mmc_set_clk(mmc->clock);
> +}
> +
> +static int mrvl_mmc_init(struct mmc *mmc)
> +{
> +#ifdef DEBUG
> + printf("mrvl_mmc_init\n");
> +#endif
> +
> + /* Setting host parameters */
> + SDIO_REG_WRITE16(SDIO_HOST_CTRL,
> + SDIO_HOST_CTRL_TMOUT(0xf) |
> + SDIO_HOST_CTRL_DATA_WIDTH_4_BITS |
> + SDIO_HOST_CTRL_BIG_ENDIAN |
> + SDIO_HOST_CTRL_PUSH_PULL_EN |
> + SDIO_HOST_CTRL_CARD_TYPE_MEM_ONLY )=
;
> + SDIO_REG_WRITE16(SDIO_CLK_CTRL, 0);
> +
> + /* enable status */
> + SDIO_REG_WRITE16(SDIO_NOR_STATUS_EN, 0xffff);
> + SDIO_REG_WRITE16(SDIO_ERR_STATUS_EN, 0xffff);
> +
> + /* disable interrupts */
> + SDIO_REG_WRITE16(SDIO_NOR_INTR_EN, 0);
> + SDIO_REG_WRITE16(SDIO_ERR_INTR_EN, 0);
> +
> + /* SW reset */
> + SDIO_REG_WRITE16(SDIO_SW_RESET,0x100);
> + udelay(10000);
> + return 0;
> +}
> +
> +int mrvl_mmc_initialize(bd_t *bis)
> +{
> + struct mmc *mmc =3D NULL;
> +
> + mmc =3D malloc(sizeof(struct mmc));
> + if (!mmc)
> + return -1;
> +
> + sprintf(mmc->name, "MRVL_MMC");
> + mmc->send_cmd =3D mrvl_mmc_send_cmd;
> + mmc->set_ios =3D mrvl_mmc_set_ios;
> + mmc->init =3D mrvl_mmc_init;
> +
> + mmc->host_caps =3D MMC_MODE_4BIT | MMC_MODE_HS;
> + mmc->voltages =3D MMC_VDD_32_33 | MMC_VDD_33_34;
> + mmc->f_max =3D MRVL_MMC_CLOCKRATE_MAX;
> + mmc->f_min =3D MRVL_MMC_CLOCKRATE_MIN;
> + mmc->block_dev.part_type =3D PART_TYPE_DOS;
> +
> + mmc_register(mmc);
> +
> + return 0;
> +}
> diff --git a/include/mrvl_mmc.h b/include/mrvl_mmc.h
> new file mode 100644
> index 0000000..db3a15a
> --- /dev/null
> +++ b/include/mrvl_mmc.h
> @@ -0,0 +1,191 @@
> +/*
> + * (C) Copyright 2012
> + * Marvell Semiconductor <www.marvell.com>
> + * Written-by: Lior Amsalem <alior@marvell.com>
> + * See file CREDITS for list of people who contributed to this
> + * project.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + */
> +#ifndef __MRVL_MMC_H__
> +#define __MRVL_MMC_H__
> +
> +/* General definitions */
> +#define P(x) (CONFIG_SYS_MMC_BASE + (x))
> +#define SDIO_REG_WRITE32(addr,val) (*(volatile unsigned
> long*)(P(addr)) =3D val)
> +#define SDIO_REG_WRITE16(addr,val) (*(volatile unsigned
> short*)(P(addr)) =3D val)
> +#define SDIO_REG_READ16(addr) (*(volatile unsigned short*)(P(addr)))
> +#define SDIO_REG_READ32(addr) (*(volatile unsigned long*)(P(addr)))
> +
> +//#define MVSDMMC_DMA_SIZE 65536
> +//#define MVSDMMC_CMD_TIMEOUT 2 /* 100 usec*/
Don't use c++ style of comments
> +
> +/* The base MMC clock rate */
> +#define MRVL_MMC_CLOCKRATE_MIN 250000
> +#define MRVL_MMC_CLOCKRATE_MAX 50000000
Make this configurable if not defined then use default values
> +#define MRVL_MMC_BASE_FAST_CLOCK 200000000//100000000
> +
> +/* SDIO register */
NACK, please use c-struct for register definition
Ref: line 30 arch/arm/include/arch-kirkwood/spi.h, create similar mmc.h ins=
tead of include/Kirkwood_mmc.h
> +#define SDIO_SYS_ADDR_LOW 0x000
> +#define SDIO_SYS_ADDR_HI 0x004
> +#define SDIO_BLK_SIZE 0x008
> +#define SDIO_BLK_COUNT 0x00c
> +#define SDIO_ARG_LOW 0x010
> +#define SDIO_ARG_HI 0x014
> +#define SDIO_XFER_MODE 0x018
> +#define SDIO_CMD 0x01c
> +#define SDIO_RSP(i) (0x020 + ((i)<<2))
> +#define SDIO_RSP0 0x020
> +#define SDIO_RSP1 0x024
> +#define SDIO_RSP2 0x028
> +#define SDIO_RSP3 0x02c
> +#define SDIO_RSP4 0x030
> +#define SDIO_RSP5 0x034
> +#define SDIO_RSP6 0x038
> +#define SDIO_RSP7 0x03c
> +#define SDIO_BUF_DATA_PORT 0x040
> +#define SDIO_RSVED 0x044
> +#define SDIO_PRESENT_STATE0 0x048
> +#define SDIO_PRESENT_STATE1 0x04c
> +#define SDIO_HOST_CTRL 0x050
> +#define SDIO_BLK_GAP_CTRL 0x054
> +#define SDIO_CLK_CTRL 0x058
> +#define SDIO_SW_RESET 0x05c
> +#define SDIO_NOR_INTR_STATUS 0x060
> +#define SDIO_ERR_INTR_STATUS 0x064
> +#define SDIO_NOR_STATUS_EN 0x068
> +#define SDIO_ERR_STATUS_EN 0x06c
> +#define SDIO_NOR_INTR_EN 0x070
> +#define SDIO_ERR_INTR_EN 0x074
> +#define SDIO_AUTOCMD12_ERR_STATUS 0x078
> +#define SDIO_CURR_BYTE_LEFT 0x07c
> +#define SDIO_CURR_BLK_LEFT 0x080
> +#define SDIO_AUTOCMD12_ARG_LOW 0x084
> +#define SDIO_AUTOCMD12_ARG_HI 0x088
> +#define SDIO_AUTOCMD12_INDEX 0x08c
> +#define SDIO_AUTO_RSP(i) (0x090 + ((i)<<2))
> +#define SDIO_AUTO_RSP0 0x090
> +#define SDIO_AUTO_RSP1 0x094
> +#define SDIO_AUTO_RSP2 0x098
> +#define SDIO_CLK_DIV 0x128
> +
> +#define WINDOW_CTRL(i) (0x108 + ((i) << 3)=
)
> +#define WINDOW_BASE(i) (0x10c + ((i) << 3)=
)
> +
> +/* SDIO_PRESENT_STATE */
> +#define CARD_BUSY (1 << 1)
> +#define CMD_INHIBIT (1 << 0)
> +#define CMD_TXACTIVE (1 << 8)
> +#define CMD_RXACTIVE (1 << 9)
> +#define CMD_AUTOCMD12ACTIVE (1 << 14)
> +#define CMD_BUS_BUSY (CMD_AUTOCMD12ACTIVE | \
> + CMD_RXACTIV=
E | \
> + CMD_TXACTIV=
E | \
> + CMD_INHIBIT=
| \
> + CARD_BUSY)
> +
> +/* SDIO_CMD */
> +#define SDIO_CMD_RSP_NONE (0 << 0)
> +#define SDIO_CMD_RSP_136 (1 << 0)
> +#define SDIO_CMD_RSP_48 (2 << 0)
> +#define SDIO_CMD_RSP_48BUSY (3 << 0)
> +#define SDIO_CMD_CHECK_DATACRC16 (1 << 2)
> +#define SDIO_CMD_CHECK_CMDCRC (1 << 3)
> +#define SDIO_CMD_INDX_CHECK (1 << 4)
> +#define SDIO_CMD_DATA_PRESENT (1 << 5)
> +#define SDIO_UNEXPECTED_RESP (1 << 7)
> +
> +/* SDIO_XFER_MODE */
> +#define SDIO_XFER_MODE_STOP_CLK (1 << 5)
> +#define SDIO_XFER_MODE_HW_WR_DATA_EN (1 << 1)
> +#define SDIO_XFER_MODE_AUTO_CMD12 (1 << 2)
> +#define SDIO_XFER_MODE_INT_CHK_EN (1 << 3)
> +#define SDIO_XFER_MODE_TO_HOST (1 << 4)
> +#define SDIO_XFER_MODE_DMA (0 << 6)
> +
> +/* SDIO_HOST_CTRL */
> +#define SDIO_HOST_CTRL_PUSH_PULL_EN (1 << 0)
> +#define SDIO_HOST_CTRL_CARD_TYPE_MEM_ONLY (0 << 1)
> +#define SDIO_HOST_CTRL_CARD_TYPE_IO_ONLY (1 << 1)
> +#define SDIO_HOST_CTRL_CARD_TYPE_IO_MEM_COMBO (2 << 1)
> +#define SDIO_HOST_CTRL_CARD_TYPE_MMC (3 << 1)
> +#define SDIO_HOST_CTRL_CARD_TYPE_MASK (3 << 1)
> +#define SDIO_HOST_CTRL_BIG_ENDIAN (1 << 3)
> +#define SDIO_HOST_CTRL_LSB_FIRST (1 << 4)
> +#define SDIO_HOST_CTRL_ID_MODE_LOW_FREQ (1 << 5)
> +#define SDIO_HOST_CTRL_HALF_SPEED (1 << 6)
> +#define SDIO_HOST_CTRL_DATA_WIDTH_1_BIT (0 << 9)
> +#define SDIO_HOST_CTRL_DATA_WIDTH_4_BITS (1 << 9)
> +#define SDIO_HOST_CTRL_HI_SPEED_EN (1 << 10)
> +#define SDIO_HOST_CTRL_TMOUT_MASK (0xf << 11)
> +#define SDIO_HOST_CTRL_TMOUT_MAX (0xf << 11)
> +#define SDIO_HOST_CTRL_TMOUT(x) ((x) << 11)
> +#define SDIO_HOST_CTRL_TMOUT_EN (1 << 15)
> +#define SDIO_HOST_CTRL_DFAULT_OPEN_DRAIN
> (SDIO_HOST_CTRL_TMOUT(x)(0xf))
> +#define SDIO_HOST_CTRL_DFAULT_PUSH_PULL
> (SDIO_HOST_CTRL_TMOUT(x)(0xf) | SDIO_HOST_CTRL_PUSH_PULL_EN)
> +
> +/* NOR status bits */
> +#define SDIO_NOR_ERROR (1 << 15)
> +#define SDIO_NOR_UNEXP_RSP (1 << 14)
> +#define SDIO_NOR_AUTOCMD12_DONE (1 << 13)
> +#define SDIO_NOR_SUSPEND_ON (1 << 12)
> +#define SDIO_NOR_LMB_FF_8W_AVAIL (1 << 11)
> +#define SDIO_NOR_LMB_FF_8W_FILLED (1 << 10)
> +#define SDIO_NOR_READ_WAIT_ON (1 << 9)
> +#define SDIO_NOR_CARD_INT (1 << 8)
> +#define SDIO_NOR_READ_READY (1 << 5)
> +#define SDIO_NOR_WRITE_READY (1 << 4)
> +#define SDIO_NOR_DMA_INI (1 << 3)
> +#define SDIO_NOR_BLK_GAP_EVT (1 << 2)
> +#define SDIO_NOR_XFER_DONE (1 << 1)
> +#define SDIO_NOR_CMD_DONE (1 << 0)
> +
> +/* ERR status bits */
> +#define SDIO_ERR_CRC_STATUS (1 << 14)
> +#define SDIO_ERR_CRC_STARTBIT (1 << 13)
> +#define SDIO_ERR_CRC_ENDBIT (1 << 12)
> +#define SDIO_ERR_RESP_TBIT (1 << 11)
> +#define SDIO_ERR_SIZE (1 << 10)
> +#define SDIO_ERR_CMD_STARTBIT (1 << 9)
> +#define SDIO_ERR_AUTOCMD12 (1 << 8)
> +#define SDIO_ERR_DATA_ENDBIT (1 << 6)
> +#define SDIO_ERR_DATA_CRC (1 << 5)
> +#define SDIO_ERR_DATA_TIMEOUT (1 << 4)
> +#define SDIO_ERR_CMD_INDEX (1 << 3)
> +#define SDIO_ERR_CMD_ENDBIT (1 << 2)
> +#define SDIO_ERR_CMD_CRC (1 << 1)
> +#define SDIO_ERR_CMD_TIMEOUT (1 << 0)
> +#define SDIO_POLL_MASK 0xffff /* enable al=
l for polling
> */
> +
> +/* MMC commands */
> +#define MMC_BLOCK_SIZE 512
> +#define MMC_CMD_RESET 0
> +#define MMC_CMD_SEND_OP_COND 1
> +#define MMC_CMD_ALL_SEND_CID 2
> +#define MMC_CMD_SET_RCA 3
> +#define MMC_CMD_SELECT_CARD 7
> +#define MMC_CMD_SEND_CSD 9
> +#define MMC_CMD_SEND_CID 10
> +#define MMC_CMD_SEND_STATUS 13
> +#define MMC_CMD_SET_BLOCKLEN 16
> +#define MMC_CMD_READ_BLOCK 17
> +#define MMC_CMD_RD_BLK_MULTI 18
> +#define MMC_CMD_WRITE_BLOCK 24
> +#define MMC_MAX_BLOCK_SIZE 512
> +
> +#endif /* __MRVL_MMC_H__ */
> +
> +int mrvl_mmc_initialize(bd_t *bis);
No need to define this, use mmc_initialize() directly
Ref: line 390 arch/arm/.../kirkwood/cpu.c
Regards...
Prafulla . . .
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
"The realloc() function returns a pointer to the newly allocated
memory, which is suitably aligned for any kind of variable and may be
different from ptr, or NULL if the request fails. "
So all you need to do is allocate a new block and memcpy() the old
data. Note also:
"If realloc() fails the original block is left untouched; it is not
freed or moved."
"If the new size is larger than the old size, the added memory will
not be initialized"
"If ptr is NULL, then the call is equivalent to malloc(size)"
"if size is equal to zero, and ptr is not NULL, then the call is
equivalent to free(ptr)"
"If the area pointed to was moved, a free(ptr) is done."
The last two are NOPs for early heap as we have no way to track free'd blocks
Keep in mind that 'real' realloc() has access to information providing
the size of the source block of allocated memory, so it can do a
memcpy using (at least a good guess of) the size of the source block.
In the early heap case, we do not have that data, so we would need to
memcpy the entire size of the destination block - this will likely
bring in garbage (no problem as we there is nothing in the spec to
forbid that) and _might_ have some interesting boundary conditions
(what happens if we memcpy past the end of an early heap block into
ga-ga land?)
Regards,
Graeme
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
reboots okay. But creating a uImage file containing the same
code, loading it with fatload at 0x82000000 and doing a "go"
there fails (ie. the device does not reboot). Why? I can see
that it is loaded okay. So why jumping there fails. To be
correct, in fact it sometimes works, but most of the time fails.
Very random and strange behavior.
So, I ask for some help. Where to look from that point?
Is the MUX thing an issue? Or maybe the uImage code runs
fine but the reboot it is supposed to do is not done for
whatever reason?
So it could be:
1 - problem with how I hacked U-Boot
2 - problem with the payload (uImage simply does a warm reboot
for now)
The ultimate goal is to load the linux kernel.
I apologize by advance if I describe things badly, but I
don't really know what to do now...
Thanks for your help,
C=C3=A9dric.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
version. IMO the number of cpus can just be the result of
get_num_cpus(), most of the clocks are the same, and differences can
either be in this file or behind a conditional check for the family.
Otherwise we have duplicated code here.
Regards,
Simon
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-05 12:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-12-05 12:53 UTC (permalink / raw)
To: u-boot
http://lists.denx.de/pipermail/u-boot/2012-April/122684.html
http://lists.denx.de/pipermail/u-boot/2012-June/125658.html
It would be nice if this patch would enter v2012.10 release. At least
someone could pull it into his repo so it can find it's way into master
eventually.
Regards,
Luka
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-12-02 16:01 Will Deacon
0 siblings, 0 replies; 732+ messages in thread
From: Will Deacon @ 2011-12-02 16:01 UTC (permalink / raw)
To: linux-arm-kernel
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-11-28 2:35 Jett.Zhou
0 siblings, 0 replies; 732+ messages in thread
From: Jett.Zhou @ 2011-11-28 2:35 UTC (permalink / raw)
To: linux-arm-kernel
1 remove unnecesary spinlock when release
2 remove change id
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-11-21 15:22 Jimmy Pan
0 siblings, 0 replies; 732+ messages in thread
From: Jimmy Pan @ 2011-11-21 15:22 UTC (permalink / raw)
To: kernelnewbies
..Do you want to feel something new? Do you want to feel new
unforgettable sensations? This is for you!
http://un-ocean.fr/p.g.php?wellink_friend_id=14ox0
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-11-17 20:02 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-11-17 20:02 UTC (permalink / raw)
To: u-boot
I think
so I am not sure why we will have no issue if it is observed in BF537-STAMP.
Removing board_reset() for now
-----------------------------------------------------------------------------------------------
>> +#define CONFIG_SYS_NO_FLASH /* we have only NAND */
>not true ... you have SPI too ;)
I am not sure if I understand properly.
As far as I understand the above macro enables/disables the parallel NOR
flashes.
If removed it I get building errors like
'CONFIG_SYS_MAX_FLASH_SECT' undeclared
'CONFIG_SYS_FLASH_BASE' undeclared
All those are parallel flash related I think.
Or do you refer to my comment only? Fixed.
-----------------------------------------------------------------------------------------------
>> +#define CONFIG_NET_MULTI 1
>no longer needed -> delete
The included patch is with the above line removed as per your advice.
If I test with the 2011R1-RC3 from the ADI repository I still need it
however.
Note that I have tested the patch (with CONFIG_NET_MULTI ) against the ADI
repository
(not the mainstream) and this is what I can confirm as working on PR1
Appliance.
-----------------------------------------------------------------------------------------------
Signed-off-by: Dimitar Penev <dpn@switchfin dot org>
Cc: Mike Frysinger <vapier {AT} gentoo {DOT} org>
www.switchfin.org/patches/uBoot-pr1-v2.patch
Best Regards
Dimitar Penev
----- Original Message -----
From: "Mike Frysinger" <vapier@gentoo.org>
To: "Dimitar Penev" <dpn@switchfin.org>
Cc: <u-boot@lists.denx.de>
Sent: Saturday, November 19, 2011 7:42 AM
Subject: Re: [U-Boot] [PATCH] Add PR1 Appliance - ISDN PRI board
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-11-17 20:02 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-11-17 20:02 UTC (permalink / raw)
To: u-boot
* Configuration _OPTIONS_:
These are selectable by the user and have names beginning with
"CONFIG_".
* Configuration _SETTINGS_:
These depend on the hardware etc. and should not be meddled with if
you don't know what you're doing; they have names beginning with
"CONFIG_SYS_".
It's better to use #define CONFIG_SYS_MXC_UART_BASE =A0 UART1_BASE
[...]
Best Regards,
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-11-17 20:02 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-11-17 20:02 UTC (permalink / raw)
To: u-boot
Acked-by: Stefano Babic <sbabic@denx.de>
Best regards,
Stefano Babic
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-11-17 20:02 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-11-17 20:02 UTC (permalink / raw)
To: u-boot
The WAIT instruction forces the core into low power mode. The pipeline
is stalled and when all external requests are
completed, the processor=E2=80=99s main clock is stopped. The processor wil=
l
restart when reset (SI_Reset) is signaled, or a
non-masked interrupt is taken (SI_NMI, SI_Int, or EJ_DINT). Note that
the core does not use the code field in this
instruction.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-11-17 20:02 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-11-17 20:02 UTC (permalink / raw)
To: u-boot
to add it
and there is no chance we miss to update the MAC to the correct value.
Anyway I am OK with your version of the patch
Thank you
Dimitar
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-11-12 14:39 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-11-12 14:39 UTC (permalink / raw)
To: ath9k-devel
and/or experimental. Am I right?
Either way I would be more than happy to help with debugging this and
maybe get this chipset working
sometime soon! The only problem us that my expertise only stretches so
far. Even though I know C
I've never done any kernel or driver work.
So what can I do? I'll see if I can get my hands on one (or two) of
those usb-to-serial adapters and see what happens, but I live on a
very tight budget so I can't hope for too much.
// Kim
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-11-12 14:39 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-11-12 14:39 UTC (permalink / raw)
To: ath9k-devel
masked out and then unmasked. So I bet ath_rx_tasklet() is actually
running somehow and not doing anything useful.
Kim - can you please add a debug statement inside ath_rx_tasklet() -
at the beginning, then at the end of the function where it's
re-enabling RXEOL. Just to confirm that it _is_ running and causing
the RXEOL bit to be re-enabled.
Thanks,
Adrian
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-09-23 3:42 毕春雷
0 siblings, 0 replies; 732+ messages in thread
From: 毕春雷 @ 2011-09-23 3:42 UTC (permalink / raw)
To: kernelnewbies
nirvanacn2011 at hotmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110923/b0ee862a/attachment.html
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-09-19 1:45 Saleem Abdulrasool
0 siblings, 0 replies; 732+ messages in thread
From: Saleem Abdulrasool @ 2011-09-19 1:45 UTC (permalink / raw)
To: linux-arm-kernel
Hi.
The attached patch adds polled io methods for the mxcuart. I needed them in
order to use kgdb during the early boot. The changes have been sitting in (my
and) Genesi's tree for quite some time now. I believe that the changes are
generally useful and would like you to consider merging them in the "upstream"
repository.
Thanks.
--
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-09-15 2:03 Jongpill Lee
0 siblings, 0 replies; 732+ messages in thread
From: Jongpill Lee @ 2011-09-15 2:03 UTC (permalink / raw)
To: linux-arm-kernel
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-08-05 3:08 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-08-05 3:08 UTC (permalink / raw)
To: ath9k-devel
users on debugging issues like this, even if end users happen to be
competent. The prefered modus operandi is to attempt to reproduce
issues internally, and if that is successful then some time later
there usually comes a patch into wireless-testing.git. This is of
course useless for corner case problems.
This mailing list is a lot like first-line support. You usually don't
get quality engineer time from Atheros here. I can understand that,
because remote debugging is a tremendous pain. But it's also the only
way to resolve odd problems.
I would recommend that you try to reproduce using FreeBSD. I'm unsure
if the driver there supports AR9287, but if it does I think you will
be able to get good help thanks to Adrian, the main fbsd driver
developer, who is also active on this list, but he's obviously not
working on the Linux driver. :)
//Peter
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-08-05 3:08 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-08-05 3:08 UTC (permalink / raw)
To: ath9k-devel
1. ASPM is disabled on my machine wherever possible (in fact I think
my mainboard doesn't even support it and this is detected correctly,
at least there I couldn't find any related setting in bios)
2. My wireless card is PCI not PCIe, and if I don't confuse something
here, ASPM is a feature of PCIe and PCIe only.
Power-saving I might check by disabling all the related options, I'll
let you know if it changes anything.
Thanks,
Philipp
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-08-05 3:08 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-08-05 3:08 UTC (permalink / raw)
To: ath9k-devel
that'd occur with the NIC awake or having something being written to
it) the NIC shouldn't be generating interrupts if:
* sync/async cause are 0;
* ier is 0;
* imr is 0.
Now maybe some part of ath9k is still trying to write to the NIC when
it's asleep, but it would set some bits in sync_cause/async_cause.
At this point I'd really suggest whacking other devices into the slot
to see if they generate the same kind of behaviour.
Adrian
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-08-05 3:08 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-08-05 3:08 UTC (permalink / raw)
To: ath9k-devel
explained in the wireshark documentation.
Cheers,
Julien
--
.''`. Julien Valroff ~ <julien@kirya.net> ~ <julien@debian.org>
: :' : Debian Developer & Free software contributor
`. `'` http://www.kirya.net/
`- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-08-05 3:08 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-08-05 3:08 UTC (permalink / raw)
To: ath9k-devel
so the user should only be allowed to change the value to anything else than
what is stored in the eeprom if we know it's a valid setting.
As far as I understand the EEPROM only stores a single value for the
antenna-switch setting, i.e. if there multiple valid values these must come from
somewhere else.
I don't know the exact electronic details of the implementation, so I'd go with
a list of known-to-be-good values (passed to the driver via platform-data)
instead of a causal check (e.g. don't allow to set the TX and RX to the same
antenna or whatever you imagine to possibly be an invalid setting).
Cheers
Daniel
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-07-21 11:12 Padmavathi Venna
0 siblings, 0 replies; 732+ messages in thread
From: Padmavathi Venna @ 2011-07-21 11:12 UTC (permalink / raw)
To: linux-arm-kernel
Add external interrupt support for S5P64X0.The external interrupt
group 0(0 to 15) is used for wake-up source in stop and sleep mode.
Add generic irq chip support
Signed-off-by: Padmavathi Venna <padma.v@samsung.com>
---
Please ignore my previous patch due to wrong return value.
arch/arm/mach-s5p64x0/Makefile | 2 +-
arch/arm/mach-s5p64x0/include/mach/regs-gpio.h | 10 ++
arch/arm/mach-s5p64x0/irq-eint.c | 152 ++++++++++++++++++++++++
3 files changed, 163 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-s5p64x0/irq-eint.c
diff --git a/arch/arm/mach-s5p64x0/Makefile b/arch/arm/mach-s5p64x0/Makefile
index ae6bf6f..5f6afdf 100644
--- a/arch/arm/mach-s5p64x0/Makefile
+++ b/arch/arm/mach-s5p64x0/Makefile
@@ -13,7 +13,7 @@ obj- :=
# Core support for S5P64X0 system
obj-$(CONFIG_ARCH_S5P64X0) += cpu.o init.o clock.o dma.o gpiolib.o
-obj-$(CONFIG_ARCH_S5P64X0) += setup-i2c0.o
+obj-$(CONFIG_ARCH_S5P64X0) += setup-i2c0.o irq-eint.o
obj-$(CONFIG_CPU_S5P6440) += clock-s5p6440.o
obj-$(CONFIG_CPU_S5P6450) += clock-s5p6450.o
diff --git a/arch/arm/mach-s5p64x0/include/mach/regs-gpio.h b/arch/arm/mach-s5p64x0/include/mach/regs-gpio.h
index 0953ef6..6ce2547 100644
--- a/arch/arm/mach-s5p64x0/include/mach/regs-gpio.h
+++ b/arch/arm/mach-s5p64x0/include/mach/regs-gpio.h
@@ -34,4 +34,14 @@
#define S5P6450_GPQ_BASE (S5P_VA_GPIO + 0x0180)
#define S5P6450_GPS_BASE (S5P_VA_GPIO + 0x0300)
+/* External interrupt control registers for group0 */
+
+#define EINT0CON0_OFFSET (0x900)
+#define EINT0MASK_OFFSET (0x920)
+#define EINT0PEND_OFFSET (0x924)
+
+#define S5P64X0_EINT0CON0 (S5P_VA_GPIO + EINT0CON0_OFFSET)
+#define S5P64X0_EINT0MASK (S5P_VA_GPIO + EINT0MASK_OFFSET)
+#define S5P64X0_EINT0PEND (S5P_VA_GPIO + EINT0PEND_OFFSET)
+
#endif /* __ASM_ARCH_REGS_GPIO_H */
diff --git a/arch/arm/mach-s5p64x0/irq-eint.c b/arch/arm/mach-s5p64x0/irq-eint.c
new file mode 100644
index 0000000..69ed454
--- /dev/null
+++ b/arch/arm/mach-s5p64x0/irq-eint.c
@@ -0,0 +1,152 @@
+/* arch/arm/mach-s5p64x0/irq-eint.c
+ *
+ * Copyright (c) 2011 Samsung Electronics Co., Ltd
+ * http://www.samsung.com/
+ *
+ * Based on linux/arch/arm/mach-s3c64xx/irq-eint.c
+ *
+ * S5P64X0 - Interrupt handling for External Interrupts.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/kernel.h>
+#include <linux/gpio.h>
+#include <linux/irq.h>
+#include <linux/io.h>
+
+#include <plat/regs-irqtype.h>
+#include <plat/gpio-cfg.h>
+
+#include <mach/regs-gpio.h>
+#include <mach/regs-clock.h>
+
+#define eint_offset(irq) ((irq) - IRQ_EINT(0))
+
+static int s5p64x0_irq_eint_set_type(struct irq_data *data, unsigned int type)
+{
+ int offs = eint_offset(data->irq);
+ int shift;
+ u32 ctrl, mask;
+ u32 newvalue = 0;
+
+ if (offs > 15)
+ return -EINVAL;
+
+ switch (type) {
+ case IRQ_TYPE_NONE:
+ printk(KERN_WARNING "No edge setting!\n");
+ break;
+ case IRQ_TYPE_EDGE_RISING:
+ newvalue = S3C2410_EXTINT_RISEEDGE;
+ break;
+ case IRQ_TYPE_EDGE_FALLING:
+ newvalue = S3C2410_EXTINT_FALLEDGE;
+ break;
+ case IRQ_TYPE_EDGE_BOTH:
+ newvalue = S3C2410_EXTINT_BOTHEDGE;
+ break;
+ case IRQ_TYPE_LEVEL_LOW:
+ newvalue = S3C2410_EXTINT_LOWLEV;
+ break;
+ case IRQ_TYPE_LEVEL_HIGH:
+ newvalue = S3C2410_EXTINT_HILEV;
+ break;
+ default:
+ printk(KERN_ERR "No such irq type %d", type);
+ return -EINVAL;
+ }
+
+ shift = (offs / 2) * 4;
+ mask = 0x7 << shift;
+
+ ctrl = __raw_readl(S5P64X0_EINT0CON0) & ~mask;
+ ctrl |= newvalue << shift;
+ __raw_writel(ctrl, S5P64X0_EINT0CON0);
+
+ /* Configure the GPIO pin for 6450 or 6440 based on CPU ID */
+ if (0x50000 == (__raw_readl(S5P64X0_SYS_ID) & 0xFF000))
+ s3c_gpio_cfgpin(S5P6450_GPN(offs), S3C_GPIO_SFN(2));
+ else
+ s3c_gpio_cfgpin(S5P6440_GPN(offs), S3C_GPIO_SFN(2));
+
+ return 0;
+}
+
+/*
+ * s5p64x0_irq_demux_eint
+ *
+ * This function demuxes the IRQ from the group0 external interrupts,
+ * from IRQ_EINT(0) to IRQ_EINT(15). It is designed to be inlined into
+ * the specific handlers s5p64x0_irq_demux_eintX_Y.
+ */
+static inline void s5p64x0_irq_demux_eint(unsigned int start, unsigned int end)
+{
+ u32 status = __raw_readl(S5P64X0_EINT0PEND);
+ u32 mask = __raw_readl(S5P64X0_EINT0MASK);
+ unsigned int irq;
+
+ status &= ~mask;
+ status >>= start;
+ status &= (1 << (end - start + 1)) - 1;
+
+ for (irq = IRQ_EINT(start); irq <= IRQ_EINT(end); irq++) {
+ if (status & 1)
+ generic_handle_irq(irq);
+ status >>= 1;
+ }
+}
+
+static void s5p64x0_irq_demux_eint0_3(unsigned int irq, struct irq_desc *desc)
+{
+ s5p64x0_irq_demux_eint(0, 3);
+}
+
+static void s5p64x0_irq_demux_eint4_11(unsigned int irq, struct irq_desc *desc)
+{
+ s5p64x0_irq_demux_eint(4, 11);
+}
+
+static void s5p64x0_irq_demux_eint12_15(unsigned int irq,
+ struct irq_desc *desc)
+{
+ s5p64x0_irq_demux_eint(12, 15);
+}
+
+static int s5p64x0_alloc_gc(void)
+{
+ struct irq_chip_generic *gc;
+ struct irq_chip_type *ct;
+
+ gc = irq_alloc_generic_chip("s5p64x0-eint", 1, S5P_IRQ_EINT_BASE,
+ S5P_VA_GPIO, handle_level_irq);
+ if (!gc) {
+ printk(KERN_ERR "%s: irq_alloc_generic_chip for group 0"
+ "external interrupts failed\n", __func__);
+ return -EINVAL;
+ }
+
+ ct = gc->chip_types;
+ ct->chip.irq_ack = irq_gc_ack;
+ ct->chip.irq_mask = irq_gc_mask_set_bit;
+ ct->chip.irq_unmask = irq_gc_mask_clr_bit;
+ ct->chip.irq_set_type = s5p64x0_irq_eint_set_type;
+ ct->regs.ack = EINT0PEND_OFFSET;
+ ct->regs.mask = EINT0MASK_OFFSET;
+ irq_setup_generic_chip(gc, IRQ_MSK(16), IRQ_GC_INIT_MASK_CACHE,
+ IRQ_NOREQUEST | IRQ_NOPROBE, 0);
+ return 0;
+}
+
+static int __init s5p64x0_init_irq_eint(void)
+{
+ int ret = s5p64x0_alloc_gc();
+ irq_set_chained_handler(IRQ_EINT0_3, s5p64x0_irq_demux_eint0_3);
+ irq_set_chained_handler(IRQ_EINT4_11, s5p64x0_irq_demux_eint4_11);
+ irq_set_chained_handler(IRQ_EINT12_15, s5p64x0_irq_demux_eint12_15);
+
+ return ret;
+}
+arch_initcall(s5p64x0_init_irq_eint);
--
1.7.0.4
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2011-06-27 20:47 John Ogness
0 siblings, 0 replies; 732+ messages in thread
From: John Ogness @ 2011-06-27 20:47 UTC (permalink / raw)
To: linux-arm-kernel
The alignment exception handler is setup fairly late in
the boot process (fs_initcall). However, with newer gcc
versions and the compiler option -fconserve-stack, code
accessing unaligned data is generated in functions that
are called earlier, for example pcpu_dump_alloc_info().
This results in unhandled alignment exceptions during
boot. By setting up the exception handler sooner, we
reduce the window where a compiler may generate code
accessing unaligned data.
Here is a minimal example that shows the issue seen with
pcpu_dump_alloc_info():
=========== begin align_test.c ==========
extern void exfunc(char *str);
void somefunc(void)
{
char mystr[] = "--------"; /* 9 bytes */
exfunc(mystr);
}
============ end align_test.c ===========
Using the cross toolchain:
arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2011.03-41) 4.5.2
$ arm-none-linux-gnueabi-gcc \
-march=armv6 \
-mtune=arm1136j-s \
-marm \
-Os \
-fconserve-stack \
-c align_test.c
The object dump of align_test.o shows:
00000000 <somefunc>:
0: e92d401f push {r0, r1, r2, r3, r4, lr}
4: e28d0007 add r0, sp, #7
8: e59f3020 ldr r3, [pc, #32] ; 30 <somefunc+0x30>
c: e5932000 ldr r2, [r3]
10: e58d2007 str r2, [sp, #7]
...
...
At address 0x10 there is unaligned access.
Signed-off-by: John Ogness <john.ogness@linutronix.de>
---
Patch against linux-next-20110831.
arch/arm/include/asm/setup.h | 1 +
arch/arm/kernel/setup.c | 2 ++
arch/arm/mm/alignment.c | 10 +++++++---
3 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/setup.h b/arch/arm/include/asm/setup.h
index a3ca303..b3e18f8 100644
--- a/arch/arm/include/asm/setup.h
+++ b/arch/arm/include/asm/setup.h
@@ -232,6 +232,7 @@ extern struct meminfo meminfo;
extern int arm_add_memory(phys_addr_t start, unsigned long size);
extern void early_print(const char *str, ...);
extern void dump_machine_table(void);
+extern int __init alignment_init(void);
#endif /* __KERNEL__ */
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 0ca06f7..0f1b2b5 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -950,6 +950,8 @@ void __init setup_arch(char **cmdline_p)
#endif
early_trap_init();
+ alignment_init();
+
if (mdesc->init_early)
mdesc->init_early();
}
diff --git a/arch/arm/mm/alignment.c b/arch/arm/mm/alignment.c
index 715eb1d..5f013cb 100644
--- a/arch/arm/mm/alignment.c
+++ b/arch/arm/mm/alignment.c
@@ -950,7 +950,7 @@ do_alignment(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
* it isn't a sysctl, and it doesn't contain sysctl information.
* We now locate it in /proc/cpu/alignment instead.
*/
-static int __init alignment_init(void)
+static int __init alignment_sysfs_init(void)
{
#ifdef CONFIG_PROC_FS
struct proc_dir_entry *res;
@@ -960,7 +960,13 @@ static int __init alignment_init(void)
if (!res)
return -ENOMEM;
#endif
+ return 0;
+}
+
+fs_initcall(alignment_sysfs_init);
+int __init alignment_init(void)
+{
if (cpu_is_v6_unaligned()) {
cr_alignment &= ~CR_A;
cr_no_alignment &= ~CR_A;
@@ -985,5 +991,3 @@ static int __init alignment_init(void)
return 0;
}
-
-fs_initcall(alignment_init);
--
1.7.2.5
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2011-06-27 20:47 Jongpill Lee
0 siblings, 0 replies; 732+ messages in thread
From: Jongpill Lee @ 2011-06-27 20:47 UTC (permalink / raw)
To: linux-arm-kernel
>From bogus@does.not.exist.com Mon Jun 27 16:47:34 2011
From: bogus@does.not.exist.com ()
Date: Mon, 27 Jun 2011 20:47:34 -0000
Subject: No subject
Message-ID: <mailman.139.1316181028.20020.linux-arm-kernel@lists.infradead.org>
- General tidy-up after Thomas' review. I've kept the config option
for the time being until we can sort out the anonymous union
problem.
Marc Zyngier (3):
genirq: add support for per-cpu dev_id interrupts
ARM: gic: consolidate PPI handling
ARM: gic, local timers: use the request_percpu_irq() interface
arch/arm/common/Kconfig | 1 +
arch/arm/common/gic.c | 38 +++-
arch/arm/include/asm/entry-macro-multi.S | 7 -
arch/arm/include/asm/hardirq.h | 3 -
arch/arm/include/asm/hardware/entry-macro-gic.S | 19 +--
arch/arm/include/asm/hardware/gic.h | 1 -
arch/arm/include/asm/localtimer.h | 19 +-
arch/arm/include/asm/smp.h | 5 -
arch/arm/include/asm/smp_twd.h | 2 +-
arch/arm/kernel/irq.c | 3 -
arch/arm/kernel/smp.c | 33 +---
arch/arm/kernel/smp_twd.c | 47 +++++-
arch/arm/mach-exynos4/include/mach/entry-macro.S | 6 +-
arch/arm/mach-exynos4/mct.c | 5 -
arch/arm/mach-msm/board-msm8x60.c | 11 -
arch/arm/mach-msm/include/mach/entry-macro-qgic.S | 73 +-------
arch/arm/mach-msm/timer.c | 69 ++++---
arch/arm/mach-omap2/include/mach/entry-macro.S | 14 +--
arch/arm/mach-shmobile/entry-intc.S | 3 -
arch/arm/mach-shmobile/include/mach/entry-macro.S | 3 -
include/linux/interrupt.h | 40 +++-
include/linux/irq.h | 16 ++-
include/linux/irqdesc.h | 1 +
kernel/irq/Kconfig | 4 +
kernel/irq/chip.c | 54 ++++++
kernel/irq/internals.h | 2 +
kernel/irq/irqdesc.c | 25 +++
kernel/irq/manage.c | 209 +++++++++++++++++=
+++-
kernel/irq/settings.h | 7 +
29 files changed, 471 insertions(+), 249 deletions(-)
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-06-16 11:41 Venkateswarlu P
0 siblings, 0 replies; 732+ messages in thread
From: Venkateswarlu P @ 2011-06-16 11:41 UTC (permalink / raw)
To: kernelnewbies
how to understand the kernerl source files in a simple way
what header files i have to understand first
for example to understand do_fork() function for process
creation which is defined in kernel/fork.c
--
**
P VENKATESWARLU
M.Tech (CSE) II year
NIT Calicut ,Kerala* **
*+91-9995115752
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110616/e52d0718/attachment.html
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-06-14 12:20 Venkateswarlu P
0 siblings, 0 replies; 732+ messages in thread
From: Venkateswarlu P @ 2011-06-14 12:20 UTC (permalink / raw)
To: kernelnewbies
anyone can send
implementation of *fork()* library call in the library
i want to know how it is get connected to the system call.
**
P VENKATESWARLU
M.Tech (CSE) II year
NIT Calicut ,Kerala* **
*+91-9995115752
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110614/e1414a9f/attachment.html
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-06-13 17:29 Andre Silva
0 siblings, 0 replies; 732+ messages in thread
From: Andre Silva @ 2011-06-13 17:29 UTC (permalink / raw)
To: linux-arm-kernel
Subject: [PATCH 1/2] ARM:mach-mx5/mx53_ard: Add ESDHC support
Signed-off-by: Andre Silva <andre.silva@freescale.com>
---
arch/arm/mach-mx5/Kconfig | 1 +
arch/arm/mach-mx5/board-mx53_ard.c | 22 ++++++++++++++++++++++
2 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-mx5/Kconfig b/arch/arm/mach-mx5/Kconfig
index 695cdf0..9a8e6f8 100644
--- a/arch/arm/mach-mx5/Kconfig
+++ b/arch/arm/mach-mx5/Kconfig
@@ -213,6 +213,7 @@ config MACH_MX53_ARD
bool "Support MX53 ARD platforms"
select SOC_IMX53
select IMX_HAVE_PLATFORM_IMX_UART
+ select IMX_HAVE_PLATFORM_SDHCI_ESDHC_IMX
help
Include support for MX53 ARD platform. This includes specific
configurations for the board and its peripherals.
diff --git a/arch/arm/mach-mx5/board-mx53_ard.c b/arch/arm/mach-mx5/board-mx53_ard.c
index 7e1859b..6049fda 100644
--- a/arch/arm/mach-mx5/board-mx53_ard.c
+++ b/arch/arm/mach-mx5/board-mx53_ard.c
@@ -36,6 +36,8 @@
#include "devices-imx53.h"
#define ARD_ETHERNET_INT_B IMX_GPIO_NR(2, 31)
+#define ARD_SD1_CD IMX_GPIO_NR(1, 1)
+#define ARD_SD1_WP IMX_GPIO_NR(1, 9)
static iomux_v3_cfg_t mx53_ard_pads[] = {
/* UART1 */
@@ -69,6 +71,19 @@ static iomux_v3_cfg_t mx53_ard_pads[] = {
MX53_PAD_EIM_OE__EMI_WEIM_OE,
MX53_PAD_EIM_RW__EMI_WEIM_RW,
MX53_PAD_EIM_CS1__EMI_WEIM_CS_1,
+ /* SDHC1 */
+ MX53_PAD_SD1_CMD__ESDHC1_CMD,
+ MX53_PAD_SD1_CLK__ESDHC1_CLK,
+ MX53_PAD_SD1_DATA0__ESDHC1_DAT0,
+ MX53_PAD_SD1_DATA1__ESDHC1_DAT1,
+ MX53_PAD_SD1_DATA2__ESDHC1_DAT2,
+ MX53_PAD_SD1_DATA3__ESDHC1_DAT3,
+ MX53_PAD_PATA_DATA8__ESDHC1_DAT4,
+ MX53_PAD_PATA_DATA9__ESDHC1_DAT5,
+ MX53_PAD_PATA_DATA10__ESDHC1_DAT6,
+ MX53_PAD_PATA_DATA11__ESDHC1_DAT7,
+ MX53_PAD_GPIO_1__GPIO1_1,
+ MX53_PAD_GPIO_9__GPIO1_9,
};
static struct resource ard_smsc911x_resources[] = {
@@ -100,6 +115,11 @@ static struct platform_device ard_smsc_lan9220_device = {
},
};
+static const struct esdhc_platform_data mx53_ard_sd1_data __initconst = {
+ .cd_gpio = ARD_SD1_CD,
+ .wp_gpio = ARD_SD1_WP,
+};
+
static void __init mx53_ard_io_init(void)
{
mxc_iomux_v3_setup_multiple_pads(mx53_ard_pads,
@@ -156,6 +176,8 @@ static void __init mx53_ard_board_init(void)
mx53_ard_io_init();
weim_cs_config();
platform_add_devices(devices, ARRAY_SIZE(devices));
+
+ imx53_add_sdhci_esdhc_imx(0, &mx53_ard_sd1_data);
}
static void __init mx53_ard_timer_init(void)
--
1.7.1
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2011-06-05 18:33 Hector Oron
0 siblings, 0 replies; 732+ messages in thread
From: Hector Oron @ 2011-06-05 18:33 UTC (permalink / raw)
To: linux-arm-kernel
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-06-04 23:16 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-06-04 23:16 UTC (permalink / raw)
To: ath9k-devel
"Evidently, some BIOSes have their ASPM support misconfigured and thus
problems can arise if the PCI-E link power mode is dropped on an
unsupported device. There are a few mentions of hangs and other issues
under Linux associated with this power management feature. It's not
really a surprise though that the BIOSes would be misconfigured given
all of the other BIOS-related problems under Linux and the once very
poor suspend-and-resume support due to all of the workarounds and
hacks that BIOS/hardware vendors have done to cater towards Microsoft
Windows power management. In this case, it seems a large number of
mobile systems are supporting ASPM but not properly advertising the
support via the standard BIOS ACPI FADT (Fixed ACPI Description
Table). Some Linux drivers even forcibly disable ASPM on Linux (e.g.
this kernel patch)."
Would someone please take charge of testing an unmodified ath9k (ie,
without my APSM disable fix) and try reverting this kernel patch?
Thanks,
Adrian
On 25 February 2011 04:02, Jonathan Nieder <jrnieder@gmail.com> wrote:
> (just cc-ing some people listed in MAINTAINERS)
> Hi,
>
> Tony Houghton wrote:
>
>> With 2.6.37 I can not use suspend on my Compaq/HP 311c (Intel Atom
>> N270/NVidia Ion LE). Originally the machine just kept locking up without
>> even blanking the display when I tried to suspend (using the GNOME menu
>> or by shutting the lid). I upgraded upower and gnome-power-manager etc
>> to experimental and after that the machine suspended OK but could not
>> resume. The backlight came on but the screen stayed blank and I could
>> not get to a console or anything with Alt+Fn.
> [...]
>> I tried replacing network-manager with wicd but that crashed the system
>> when it connected instead of when disconnected.
> [...]
>> While testing different kernels I found it would crash at different
>> times, usually before the screen turned off for suspending, but
>> sometimes it would crash on resuming and occasionally it locked up while
>> booting, but it's always a complete lock-up ie the keyboard is
>> completely responsive, including caps lock, the mouse won't move if the
>> display is still on, and the only way out is to hold down the power
>> button.
> [...]
>> I haven't tried looking in logs because the crashes are so severe I
>> don't think they'd be able to record anything useful. But using git
>> bisect I think I have tracked down the change that started causing this
>> problem:
>>
>> 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f is the first bad commit
>> commit 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f
>> Author: Vivek Natarajan <vnatarajan@atheros.com>
>> Date: =A0 Mon Apr 5 14:48:04 2010 +0530
>>
>> =A0 =A0 ath9k: Add support for newer AR9285 chipsets.
>>
>> =A0 =A0 This patch adds support for a modified newer version of AR9285
>> =A0 =A0 chipsets.
>>
>> =A0 =A0 Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
>> =A0 =A0 Signed-off-by: John W. Linville <linville@tuxdriver.com>
>
> The adaptor is an AR9285[1].
>
> That commit is based against v2.6.33 and was merged in v2.6.35-rc1
>
> $ git describe 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f
> v2.6.33-3523-g53bc7aa
> $ git name-rev --tags 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f
> 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f tags/v2.6.35-rc1~473^2~167^2~346
>
> Any ideas for tracking this down?
>
> Thanks,
> Jonathan
>
> [1]
>> 84: udi =3D '/org/freedesktop/Hal/devices/pci_168c_2b'
>> =A0 pci.device_protocol =3D 0 =A0(0x0) =A0(int)
>> =A0 pci.vendor =3D 'Atheros Communications Inc.' =A0(string)
>> =A0 info.vendor =3D 'Atheros Communications Inc.' =A0(string)
>> =A0 pci.product =3D 'AR9285 Wireless Network Adapter
>> (PCI-Express)' =A0(string) linux.sysfs_path =3D
>> '/sys/devices/pci0000:00/0000:00:15.0/0000:03:00.0' =A0(strin g)
>> =A0 info.parent =3D '/org/freedesktop/Hal/devices/pci_10de_ac6' =A0(stri=
ng)
>> =A0 info.linux.driver =3D 'ath9k' =A0(string)
>> =A0 pci.subsys_vendor =3D 'Hewlett-Packard Company' =A0(string)
>> =A0 linux.hotplug_type =3D 2 =A0(0x2) =A0(int)
>> =A0 linux.subsystem =3D 'pci' =A0(string)
>> =A0 info.subsystem =3D 'pci' =A0(string)
>> =A0 info.product =3D 'AR9285 Wireless Network Adapter
>> (PCI-Express)' =A0(string) info.udi =3D
>> '/org/freedesktop/Hal/devices/pci_168c_2b' =A0(string)
>> pci.linux.sysfs_path =3D
>> '/sys/devices/pci0000:00/0000:00:15.0/0000:03:00.0' =A0(string)
>> pci.product_id =3D 43 =A0(0x2b) =A0(int) pci.vendor_id =3D 5772 =A0(0x16=
8c)
>> (int) pci.subsys_product_id =3D 12352 =A0(0x3040) =A0(int)
>> pci.subsys_vendor_id =3D 4156 =A0(0x103c) =A0(int) pci.device_class =3D =
2
>> (0x2) =A0(int) pci.device_subclass =3D 128 =A0(0x80) =A0(int)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless"=
in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-06-04 23:16 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-06-04 23:16 UTC (permalink / raw)
To: ath9k-devel
not even used an AR9300 yet, let alone tinkered with the TPC stuff) it
looks all very straightforward. Unless some other chip functionality
is required that hasn't been ported to ath9k, it "should just work".
Sorry, I can't be more helpful than that.
(Also, it'd be nice if someone contributed per-packet TPC support -
proper support at that! - to ath9k. :)
adrian
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-05-17 9:28 Javier Martin
0 siblings, 0 replies; 732+ messages in thread
From: Javier Martin @ 2011-05-17 9:28 UTC (permalink / raw)
To: linux-arm-kernel
This series of patches provides support for Aptina mt9p031 sensor on Beagleboard xM.
It has been tested using media-ctl and yavta.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-05-13 19:35 Vadim Bendebury
0 siblings, 0 replies; 732+ messages in thread
From: Vadim Bendebury @ 2011-05-13 19:35 UTC (permalink / raw)
To: linux-arm-kernel
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-04-07 5:55 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-04-07 5:55 UTC (permalink / raw)
To: ath9k-devel
the silicon itself at power-on. 'abcd' sounds a bit too convenient to be
what's in EEPROM/OTP; so maybe it's a default value in the silicon?
(All just conjecture here at this point.)
Adrian
On 10 April 2011 23:17, Mohammed Shafi <shafi.ath9k@gmail.com> wrote:
> On Sun, Apr 10, 2011 at 8:41 PM, Peter Stuge <peter@stuge.se> wrote:
> > Mohammed Shafi wrote:
> >> > Is this a serious proposal from Atheros, or just your attempt at
> >> > a quick fix?
> >>
> >> No! its purely a personal idea (am completely responsible for the
> >> mistake),and I will take a look at it carefully to fix this.
> >
> > Sorry, I didn't mean that you made a mistake, just that the
> > suggestion probably would not get us closer to the actual issue.
> >
> > Bus level issues are indeed difficult. :\
>
> thanks, i did not know that. thought simple as adding another device id.
> >
> >
> >> > A device having an unexpected PCI id means that something is really
> >> > wrong in the device or on the bus, and the solution is rarely to
> >> > pretend that it didn't happen.]
> >>
> >> Yeah I can see that, hoping that I may get a correct Device ID from
> >> the reporter. I dont think 'abcd' is a proper vendor id.
> >
> > Yes, it's easy to spot. The question is how we can find out *why*
> > this happened, so that this error case can be prevented.
>
> Yes sure.
> >
> >
> >> > Since this card should work fine in principle, maybe it's some issue
> >> > with missing, or wrong, firmware stored on the Linux system.
> >>
> >> AR9382 does not seems to have firmware
> >
> > Aha! That's only for the USB devices maybe. I don't know much detail
> > for these latest devices.
> >
> currently only ath9k_htc needs firmware.
>
> >
> >> and you have any idea what might went wrong.
> >
> > Sorry, I don't understand what you mean here.
>
> Your suggestions about what might have went wrong, as you had already
> told it might be a bus level issue.
>
> >
> >
> >> Also why its detected as Ethernet Controller rather than
> >> Network controller.
> >
> > This string comes from the pciutils package and could easily have
> > changed. Better look at the numerical device class code, which is
> > what is read from hardware.
>
> thanks, I will look into that.
>
> >
> > But I expect that when one thing in config space (device id) is bogus
> > then the rest of config space is also quite possibly bogus, for the
> > same reason, whatever it is.
> >
> >
> > //Peter
> > _______________________________________________
> > ath9k-devel mailing list
> > ath9k-devel at lists.ath9k.org
> > https://lists.ath9k.org/mailman/listinfo/ath9k-devel
> >
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
--20cf300256ecb39f7b04a09232d4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Incorrect or misplaced EEPROM/OTP data, perhaps?<div><br></div><div>From wh=
at I gather, the PCI ID on earlier devices is loaded out of EEPROM by the s=
ilicon itself at power-on. 'abcd' sounds a bit too convenient to be=
what's in EEPROM/OTP; so maybe it's a default value in the silicon=
?</div>
<div><br></div><div>(All just conjecture here at this point.)</div><div><br=
></div><div><br></div><div>Adrian</div><div><br><div class=3D"gmail_quote">=
On 10 April 2011 23:17, Mohammed Shafi <span dir=3D"ltr"><<a href=3D"mai=
lto:shafi.ath9k@gmail.com">shafi.ath9k at gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><div class=3D"im">On Sun, Apr 10, 2011 at 8=
:41 PM, Peter Stuge <<a href=3D"mailto:peter@stuge.se">peter at stuge.se</a=
>> wrote:<br>
> Mohammed Shafi wrote:<br>
>> > Is this a serious proposal from Atheros, or just your attempt=
at<br>
>> > a quick fix?<br>
>><br>
>> No! its purely a personal idea (am completely responsible for the<=
br>
>> mistake),and I will take a look at it carefully to fix this.<br>
><br>
> Sorry, I didn't mean that you made a mistake, just that the<br>
> suggestion probably would not get us closer to the actual issue.<br>
><br>
> Bus level issues are indeed difficult. :\<br>
<br>
</div>thanks, i did not know that. thought simple as adding another device =
id.<br>
<div class=3D"im">><br>
><br>
>> > A device having an unexpected PCI id means that something is =
really<br>
>> > wrong in the device or on the bus, and the solution is rarely=
to<br>
>> > pretend that it didn't happen.]<br>
>><br>
>> Yeah I can see that, hoping that I may get a correct Device ID fro=
m<br>
>> the reporter. I dont think 'abcd' is a proper vendor id.<b=
r>
><br>
> Yes, it's easy to spot. The question is how we can find out *why*<=
br>
> this happened, so that this error case can be prevented.<br>
<br>
</div>Yes sure.<br>
<div class=3D"im">><br>
><br>
>> > Since this card should work fine in principle, maybe it's=
some issue<br>
>> > with missing, or wrong, firmware stored on the Linux system.<=
br>
>><br>
>> AR9382 does not seems to have firmware<br>
><br>
> Aha! That's only for the USB devices maybe. I don't know much =
detail<br>
> for these latest devices.<br>
><br>
</div>currently only =A0ath9k_htc needs firmware.<br>
<div class=3D"im"><br>
><br>
>> and you have any idea what might went wrong.<br>
><br>
> Sorry, I don't understand what you mean here.<br>
<br>
</div>Your suggestions about what might have went wrong, as you had already=
<br>
told it might be a bus level issue.<br>
<div class=3D"im"><br>
><br>
><br>
>> Also why its detected as Ethernet Controller rather than<br>
>> Network controller.<br>
><br>
> This string comes from the pciutils package and could easily have<br>
> changed. Better look at the numerical device class code, which is<br>
> what is read from hardware.<br>
<br>
</div>thanks, I will look into that.<br>
<div><div></div><div class=3D"h5"><br>
><br>
> But I expect that when one thing in config space (device id) is bogus<=
br>
> then the rest of config space is also quite possibly bogus, for the<br=
>
> same reason, whatever it is.<br>
><br>
><br>
> //Peter<br>
> _______________________________________________<br>
> ath9k-devel mailing list<br>
> <a href=3D"mailto:ath9k-devel@lists.ath9k.org">ath9k-devel at lists.ath9k=
.org</a><br>
> <a href=3D"https://lists.ath9k.org/mailman/listinfo/ath9k-devel" targe=
t=3D"_blank">https://lists.ath9k.org/mailman/listinfo/ath9k-devel</a><br>
><br>
_______________________________________________<br>
ath9k-devel mailing list<br>
<a href=3D"mailto:ath9k-devel@lists.ath9k.org">ath9k-devel at lists.ath9k.org<=
/a><br>
<a href=3D"https://lists.ath9k.org/mailman/listinfo/ath9k-devel" target=3D"=
_blank">https://lists.ath9k.org/mailman/listinfo/ath9k-devel</a><br>
</div></div></blockquote></div><br></div>
--20cf300256ecb39f7b04a09232d4--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-04-07 5:55 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-04-07 5:55 UTC (permalink / raw)
To: ath9k-devel
ATTITUDE ADJUSTMENT (bleeding edge, r26358) ----------
root at jv-2400-ap1:~# uptime
16:57:14 up 3 days, 14:15, load average: 0.00, 0.01, 0.04
root at jv-2400-ap1:~# iw wlan0 station dump | grep -i failed
tx failed: 0
tx failed: 0
tx failed: 0
tx failed: 0
tx failed: 0
tx failed: 0
tx failed: 7
tx failed: 0
tx failed: 0
root at jv-2400-ap1:~#
--
Larry Vaden, CoFounder
Internet Texoma, Inc.
Serving Rural Texomaland Since 1995
We Care About Your Connection!
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-04-07 5:55 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-04-07 5:55 UTC (permalink / raw)
To: ath9k-devel
-------------------------------
Device Instance Id:
PCI\VEN_168C&DEV_0030&SUBSYS_3116168C&REV_01\4&492937F&0&00E2
Hardware Ids:
PCI\VEN_168C&DEV_0030&SUBSYS_3116168C&REV_01
PCI\VEN_168C&DEV_0030&SUBSYS_3116168C
PCI\VEN_168C&DEV_0030&CC_028000
PCI\VEN_168C&DEV_0030&CC_0280
Compatible Ids:
PCI\VEN_168C&DEV_0030&REV_01
PCI\VEN_168C&DEV_0030
PCI\VEN_168C&CC_028000
PCI\VEN_168C&CC_0280
PCI\VEN_168C
PCI\CC_028000
PCI\CC_0280
Matching Device Id:
pci\ven_168c&dev_0030&subsys_3116168c
Here is the interesting bit, when I first hooked this card I booted my=
machine in Ubuntu I saw the same 168c:ABCD. After using it under Window=
s, I booted in to Linux today and found that it is reporting the expecte=
d IDs. Now ath9k works right out of the box, no Vendor ID hacking requir=
ed. I am using it as station right now. The other card is in a different=
machine. I will try to swap the cards to verify my theory. I am thinkin=
g the Windows driver applied a firmware update to the card. Or, the othe=
r card skipped quality checks and has bogus EEPROM data. Any thoughts?
0e:00.0 Network controller [0280]: Atheros Communications Inc. AR9300=
Wireless LAN adaptor [168c:0030] (rev 01)
lspci -vvvnn returns
0e:00.0 Network controller [0280]: Atheros Communications Inc. AR9300=
Wireless LAN adaptor [168c:0030] (rev 01)
Subsystem: Atheros Communications Inc. Device [168c:3116]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Ste=
pping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfast >TAbort- <TAbor=
t- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 18
Region 0: Memory at fa000000 (64-bit, non-prefetchable) [size=3D128K]
[virtual] Expansion ROM@f2000000 [disabled] [size=3D64K]
Capabilities: <access denied>
Kernel driver in use: ath9k
Kernel modules: ath9k
Hasan R.
-----Original Message-----
From: Mohammed Shafi [mailto:shafi.ath9k at gmail.com]=20
Sent: Tuesday, April 12, 2011 7:47 AM
To: Hasan Rashid
Cc: ath9k-devel at lists.ath9k.org
Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
On Mon, Apr 11, 2011 at 11:24 PM, Hasan Rashid <hrashad@avionica.com>=
wrote:
>
> I have attached the driver load output in dmesg.
>
> By the way why does AR9382 require Kernel 2.6.36 or higher? Can you=20
> list the major requirements?
because the hardware code(HAL) will be present from that kernel version=
only.
>
> Hasan R.
>
> -----Original Message-----
> From: ath9k-devel-bounces at lists.ath9k.org
> [mailto:ath9k-devel-bounces at lists.ath9k.org] On Behalf Of Peter Stuge
> Sent: Monday, April 11, 2011 12:20 PM
> To: ath9k-devel at lists.ath9k.org
> Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
>
> Mohammed Shafi wrote:
>> to make sure that HT is configured in driver please do this
>>
>> diff --git a/drivers/net/wireless/ath/ath9k/hw.c
>> b/drivers/net/wireless/ath/ath9k/hw.c
>> index 1b5bd13..720a866 100644
>> --- a/drivers/net/wireless/ath/ath9k/hw.c
>> +++ b/drivers/net/wireless/ath/ath9k/hw.c
>> @@ -1855,6 +1855,8 @@ int ath9k_hw_fill_cap_info(struct ath_hw *ah)
>> =A0 =A0 =A0 =A0 else
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pCap->hw_caps &=3D ~ATH9K_HW_CAP_HT;
>>
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 pCap->hw_caps |=3D ATH9K_HW_CAP_HT;
>> +
>
> The indentation is off, or do you mean to include the added line only=20
> within the else block? If so, remember to add braces.
>
>
> //Peter
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
> This communication contains information that may be confidential or=20
> privileged. The information is solely intended for the use of the addr=
essee. If you are not the intended recipient, be advised that any disclo=
sure, copy, distribution, or use of the contents of this communication=
is prohibited. If you have received this communication in error, please=
immediately notify the sender by telephone or by electronic mail.
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
>
This communication contains information that may be confidential or priv=
ileged. The information is solely intended for the use of the addressee.=
If you are not the intended recipient, be advised that any disclosure,=
copy, distribution, or use of the contents of this communication is pro=
hibited. If you have received this communication in
error, please immediately notify the sender by telephone or by electroni=
c mail.
------_=_NextPart_001_01CBF922.E6EB9838
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Diso-88=
59-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version 6.5.7654.=
12">
<TITLE>RE: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=3D2>I put another Sparklan card in a Windows XP machine=
and following are the device ids reported by the Atheros driver on Wind=
ows. It seems it is reporting the correct 0x168c, and 0x0030.<BR>
<BR>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-04-07 5:55 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-04-07 5:55 UTC (permalink / raw)
To: ath9k-devel
-------------------------------<BR>
Device Instance Id:<BR>
PCI\VEN_168C&DEV_0030&SUBSYS_3116168C&REV_01\4&492937F&a=
mp;0&00E2<BR>
<BR>
Hardware Ids:<BR>
PCI\VEN_168C&DEV_0030&SUBSYS_3116168C&REV_01<BR>
PCI\VEN_168C&DEV_0030&SUBSYS_3116168C<BR>
PCI\VEN_168C&DEV_0030&CC_028000<BR>
PCI\VEN_168C&DEV_0030&CC_0280<BR>
<BR>
Compatible Ids:<BR>
PCI\VEN_168C&DEV_0030&REV_01<BR>
PCI\VEN_168C&DEV_0030<BR>
PCI\VEN_168C&CC_028000<BR>
PCI\VEN_168C&CC_0280<BR>
PCI\VEN_168C<BR>
PCI\CC_028000<BR>
PCI\CC_0280<BR>
<BR>
Matching Device Id:<BR>
pci\ven_168c&dev_0030&subsys_3116168c<BR>
<BR>
<BR>
Here is the interesting bit, when I first hooked this card I booted my=
machine in Ubuntu I saw the same 168c:ABCD. After using it under Window=
s, I booted in to Linux today and found that it is reporting the expecte=
d IDs. Now ath9k works right out of the box, no Vendor ID hacking requir=
ed. I am using it as station right now. The other card is in a different=
machine. I will try to swap the cards to verify my theory. I am thinkin=
g the Windows driver applied a firmware update to the card. Or, the othe=
r card skipped quality checks and has bogus EEPROM data. Any thoughts?<B=
R>
<BR>
0e:00.0 Network controller [0280]: Atheros Communications Inc. AR9300=
Wireless LAN adaptor [168c:0030] (rev 01)<BR>
<BR>
lspci -vvvnn returns<BR>
<BR>
0e:00.0 Network controller [0280]: Atheros Communications Inc. AR9300=
Wireless LAN adaptor [168c:0030] (rev 01)<BR>
Subsystem: Atheros Communicat=
ions Inc. Device [168c:3116]<BR>
Control: I/O+ Mem+ BusMaster+=
SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-=
<BR>
Status: Cap+ 66MHz- UDF- Fast=
B2B- ParErr- DEVSEL=3Dfast >TAbort- <TAbort- <MAbort- >SERR-=
<PERR- INTx-<BR>
Latency: 0, Cache Line Size:=
64 bytes<BR>
Interrupt: pin A routed to=
IRQ 18<BR>
Region 0: Memory at fa000000=
(64-bit, non-prefetchable) [size=3D128K]<BR>
[virtual] Expansion ROM at=
f2000000 [disabled] [size=3D64K]<BR>
Capabilities: <access deni=
ed><BR>
Kernel driver in use: ath9k<B=
R>
Kernel modules: ath9k<BR>
<BR>
<BR>
Hasan R.<BR>
<BR>
-----Original Message-----<BR>
From: Mohammed Shafi [<A HREF=3D"mailto:shafi.ath9k@gmail.com">mailto:sh=
afi.ath9k at gmail.com</A>]<BR>
Sent: Tuesday, April 12, 2011 7:47 AM<BR>
To: Hasan Rashid<BR>
Cc: ath9k-devel at lists.ath9k.org<BR>
Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd<BR>
<BR>
On Mon, Apr 11, 2011 at 11:24 PM, Hasan Rashid <hrashad at avionica.com&=
gt; wrote:<BR>
><BR>
> I have attached the driver load output in dmesg.<BR>
><BR>
> By the way why does AR9382 require Kernel 2.6.36 or higher? Can you=
<BR>
> list the major requirements?<BR>
<BR>
because the hardware code(HAL) will be present from that kernel version=
only.<BR>
><BR>
> Hasan R.<BR>
><BR>
> -----Original Message-----<BR>
> From: ath9k-devel-bounces at lists.ath9k.org<BR>
> [<A HREF=3D"mailto:ath9k-devel-bounces@lists.ath9k.org">mailto:ath9=
k-devel-bounces at lists.ath9k.org</A>] On Behalf Of Peter Stuge<BR>
> Sent: Monday, April 11, 2011 12:20 PM<BR>
> To: ath9k-devel at lists.ath9k.org<BR>
> Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd<BR>
><BR>
> Mohammed Shafi wrote:<BR>
>> to make sure that HT is configured in driver please do this<BR>
>><BR>
>> diff --git a/drivers/net/wireless/ath/ath9k/hw.c<BR>
>> b/drivers/net/wireless/ath/ath9k/hw.c<BR>
>> index 1b5bd13..720a866 100644<BR>
>> --- a/drivers/net/wireless/ath/ath9k/hw.c<BR>
>> +++ b/drivers/net/wireless/ath/ath9k/hw.c<BR>
>> @@ -1855,6 +1855,8 @@ int ath9k_hw_fill_cap_info(struct ath_hw=
*ah)<BR>
>> =A0 =A0 =A0 =A0 else<BR>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pCap->hw_caps &=3D ~ATH9=
K_HW_CAP_HT;<BR>
>><BR>
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 pCap->hw_caps |=3D ATH9K_HW_CA=
P_HT;<BR>
>> +<BR>
><BR>
> The indentation is off, or do you mean to include the added line=
only<BR>
> within the else block? If so, remember to add braces.<BR>
><BR>
><BR>
> //Peter<BR>
> _______________________________________________<BR>
> ath9k-devel mailing list<BR>
> ath9k-devel at lists.ath9k.org<BR>
> <A HREF=3D"https://lists.ath9k.org/mailman/listinfo/ath9k-devel">ht=
tps://lists.ath9k.org/mailman/listinfo/ath9k-devel</A><BR>
><BR>
> This communication contains information that may be confidential=
or<BR>
> privileged. The information is solely intended for the use of the=
addressee. If you are not the intended recipient, be advised that any=
disclosure, copy, distribution, or use of the contents of this communic=
ation is prohibited. If you have received this communication in error,=
please immediately notify the sender by telephone or by electronic mail=
.<BR>
> _______________________________________________<BR>
> ath9k-devel mailing list<BR>
> ath9k-devel at lists.ath9k.org<BR>
> <A HREF=3D"https://lists.ath9k.org/mailman/listinfo/ath9k-devel">ht=
tps://lists.ath9k.org/mailman/listinfo/ath9k-devel</A><BR>
><BR>
><BR>
<BR>
</FONT>
</P>
<!-- Begin Ninja Disclaimer ID 06d1f63c-a7f2-4bdd-9832-359e6e93159e -->
This communication contains information that may be confidential or priv=
ileged. The information is solely intended for the use of the addressee.=
If you are not the intended recipient, be advised that any disclosure,=
copy, distribution, or use of the contents of this communication is pro=
hibited. If you have received this communication in<BR>error, please imm=
ediately notify the sender by telephone or by electronic mail.
</BODY>
</HTML>
------_=_NextPart_001_01CBF922.E6EB9838--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-04-07 5:55 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2011-04-07 5:55 UTC (permalink / raw)
To: ath9k-devel
-------------------------------<br>
Device Instance Id:<br>
PCI\VEN_168C&DEV_0030&SUBSYS_3116168C&REV_01\4&492937F&=
0&00E2<br>
<br>
Hardware Ids:<br>
PCI\VEN_168C&DEV_0030&SUBSYS_3116168C&REV_01<br>
PCI\VEN_168C&DEV_0030&SUBSYS_3116168C<br>
PCI\VEN_168C&DEV_0030&CC_028000<br>
PCI\VEN_168C&DEV_0030&CC_0280<br>
<br>
Compatible Ids:<br>
PCI\VEN_168C&DEV_0030&REV_01<br>
PCI\VEN_168C&DEV_0030<br>
PCI\VEN_168C&CC_028000<br>
PCI\VEN_168C&CC_0280<br>
PCI\VEN_168C<br>
PCI\CC_028000<br>
PCI\CC_0280<br>
<br>
Matching Device Id:<br>
pci\ven_168c&dev_0030&subsys_3116168c<br>
<br>
<br>
Here is the interesting bit, when I first hooked this card I booted my mach=
ine in Ubuntu I saw the same 168c:ABCD. After using it under Windows, I boo=
ted in to Linux today and found that it is reporting the expected IDs. Now =
ath9k works right out of the box, no Vendor ID hacking required. I am using=
it as station right now. The other card is in a different machine. I will =
try to swap the cards to verify my theory. I am thinking the Windows driver=
applied a firmware update to the card. Or, the other card skipped quality =
checks and has bogus EEPROM data. Any thoughts?<br>
<br>
0e:00.0 Network controller [0280]: Atheros Communications Inc. AR9300 Wirel=
ess LAN adaptor [168c:0030] (rev 01)<br>
<br>
lspci -vvvnn returns<br>
<br>
0e:00.0 Network controller [0280]: Atheros Communications Inc. AR9300 Wirel=
ess LAN adaptor [168c:0030] (rev 01)<br>
=A0=A0=A0=A0=A0=A0=A0 Subsystem: Atheros Communications Inc. Device [168c:3=
116]</font></p><div class=3D"im"><font size=3D"2"><br>
=A0=A0=A0=A0=A0=A0=A0 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGA=
Snoop- ParErr- Stepping- SERR- FastB2B- DisINTx-<br>
=A0=A0=A0=A0=A0=A0=A0 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfa=
st >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-<br></font>=
</div><font size=3D"2">
=A0=A0=A0=A0=A0=A0=A0 Latency: 0, Cache Line Size: 64 bytes<br>
=A0=A0=A0=A0=A0=A0=A0 Interrupt: pin A routed to IRQ 18<br>
=A0=A0=A0=A0=A0=A0=A0 Region 0: Memory at fa000000 (64-bit, non-prefetchabl=
e) [size=3D128K]<br>
=A0=A0=A0=A0=A0=A0=A0 [virtual] Expansion ROM at f2000000 [disabled] [size=
=3D64K]<br>
=A0=A0=A0=A0=A0=A0=A0 Capabilities: <access denied><br>
=A0=A0=A0=A0=A0=A0=A0 Kernel driver in use: ath9k<br>
=A0=A0=A0=A0=A0=A0=A0 Kernel modules: ath9k<br>
<br>
<br>
Hasan R.<div class=3D"im"><br>
<br>
-----Original Message-----<br>
From: Mohammed Shafi [<a href=3D"mailto:shafi.ath9k@gmail.com" target=3D"_b=
lank">mailto:shafi.ath9k at gmail.com</a>]<br></div><div class=3D"im">
Sent: Tuesday, April 12, 2011 7:47 AM<br>
To: Hasan Rashid<br></div><div><div></div><div class=3D"h5">
Cc: <a href=3D"mailto:ath9k-devel@lists.ath9k.org" target=3D"_blank">ath9k-=
devel at lists.ath9k.org</a><br>
Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd<br>
<br>
On Mon, Apr 11, 2011 at 11:24 PM, Hasan Rashid <<a href=3D"mailto:hrasha=
d@avionica.com" target=3D"_blank">hrashad at avionica.com</a>> wrote:<br>
><br>
> I have attached the driver load output in dmesg.<br>
><br>
> By the way why does AR9382 require Kernel 2.6.36 or higher? Can you<br=
>
> list the major requirements?<br>
<br>
because the hardware code(HAL) will be present from that kernel version onl=
y.<br>
><br>
> Hasan R.<br>
><br>
> -----Original Message-----<br>
> From: <a href=3D"mailto:ath9k-devel-bounces@lists.ath9k.org" target=3D=
"_blank">ath9k-devel-bounces at lists.ath9k.org</a><br>
> [<a href=3D"mailto:ath9k-devel-bounces@lists.ath9k.org" target=3D"_bla=
nk">mailto:ath9k-devel-bounces at lists.ath9k.org</a>] On Behalf Of Peter Stug=
e<br>
> Sent: Monday, April 11, 2011 12:20 PM<br>
> To: <a href=3D"mailto:ath9k-devel@lists.ath9k.org" target=3D"_blank">a=
th9k-devel at lists.ath9k.org</a><br>
> Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd<br>
><br>
> Mohammed Shafi wrote:<br>
>> to make sure that HT is configured in driver please do this<br>
>><br>
>> diff --git a/drivers/net/wireless/ath/ath9k/hw.c<br>
>> b/drivers/net/wireless/ath/ath9k/hw.c<br>
>> index 1b5bd13..720a866 100644<br>
>> --- a/drivers/net/wireless/ath/ath9k/hw.c<br>
>> +++ b/drivers/net/wireless/ath/ath9k/hw.c<br>
>> @@ -1855,6 +1855,8 @@ int ath9k_hw_fill_cap_info(struct ath_hw *ah=
)<br>
>> =A0 =A0 =A0 =A0 else<br>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pCap->hw_caps &=3D ~ATH9K_H=
W_CAP_HT;<br>
>><br>
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 pCap->hw_caps |=3D ATH9K_HW_CAP_H=
T;<br>
>> +<br>
><br>
> The indentation is off, or do you mean to include the added line only<=
br>
> within the else block? If so, remember to add braces.<br>
><br>
><br>
> //Peter<br>
> _______________________________________________<br>
> ath9k-devel mailing list<br>
> <a href=3D"mailto:ath9k-devel@lists.ath9k.org" target=3D"_blank">ath9k=
-devel at lists.ath9k.org</a><br>
> <a href=3D"https://lists.ath9k.org/mailman/listinfo/ath9k-devel" targe=
t=3D"_blank">https://lists.ath9k.org/mailman/listinfo/ath9k-devel</a><br>
><br>
> This communication contains information that may be confidential or<br=
>
> privileged. The information is solely intended for the use of the addr=
essee. If you are not the intended recipient, be advised that any disclosur=
e, copy, distribution, or use of the contents of this communication is proh=
ibited. If you have received this communication in error, please immediatel=
y notify the sender by telephone or by electronic mail.<br>
> _______________________________________________<br>
> ath9k-devel mailing list<br>
> <a href=3D"mailto:ath9k-devel@lists.ath9k.org" target=3D"_blank">ath9k=
-devel at lists.ath9k.org</a><br>
> <a href=3D"https://lists.ath9k.org/mailman/listinfo/ath9k-devel" targe=
t=3D"_blank">https://lists.ath9k.org/mailman/listinfo/ath9k-devel</a><br>
><br>
><br>
<br>
</div></div></font>
<p></p><div><div></div><div class=3D"h5">
This communication contains information that may be confidential or privile=
ged. The information is solely intended for the use of the addressee. If yo=
u are not the intended recipient, be advised that any disclosure, copy, dis=
tribution, or use of the contents of this communication is prohibited. If y=
ou have received this communication in<br>
error, please immediately notify the sender by telephone or by electronic m=
ail.
</div></div></div>
<br>_______________________________________________<br>
ath9k-devel mailing list<br>
<a href=3D"mailto:ath9k-devel@lists.ath9k.org">ath9k-devel at lists.ath9k.org<=
/a><br>
<a href=3D"https://lists.ath9k.org/mailman/listinfo/ath9k-devel" target=3D"=
_blank">https://lists.ath9k.org/mailman/listinfo/ath9k-devel</a><br>
<br></blockquote></div><br>
--002215b031060bfd5704a0c0a00c--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-03-22 18:13 nijil yes
0 siblings, 0 replies; 732+ messages in thread
From: nijil yes @ 2011-03-22 18:13 UTC (permalink / raw)
To: kernelnewbies
Hi,
could anyone mention what are the projects available for beginners to do in gsoc
this time from kernel newbies.I am comfortable with c/c++.I would be glad if
someone could suggest a few
Regards,
Nijil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110322/1858b878/attachment.html
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-03-01 14:02 Javier Martin
0 siblings, 0 replies; 732+ messages in thread
From: Javier Martin @ 2011-03-01 14:02 UTC (permalink / raw)
To: linux-arm-kernel
This series of patches provides support for audio in Visstrim_M10 boards.
This second version has some fixes in the aic32x4 codec driver as asked by
Mark Brown.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-02-26 6:20 Aldyth Maharsha
0 siblings, 0 replies; 732+ messages in thread
From: Aldyth Maharsha @ 2011-02-26 6:20 UTC (permalink / raw)
To: kernelnewbies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110226/cfa13c75/attachment.html
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-01-13 9:13 Uwe Kleine-König
0 siblings, 0 replies; 732+ messages in thread
From: Uwe Kleine-König @ 2011-01-13 9:13 UTC (permalink / raw)
To: linux-arm-kernel
<jason77.wang@gmail.com>
Bcc:
Subject: Re: i.MX & IRQF_ONESHOT
Reply-To:
In-Reply-To: <4D2EB6EF.7030608@eukrea.com>
Hello,
[adding tglx who AFAIK invented threaded irqs and the people involved
in 2991a1ca6e9b to Cc]
On Thu, Jan 13, 2011 at 09:25:19AM +0100, Eric B?nard wrote:
> while testing 2.6.37 on our i.MX27 based board - code in
> arch/arm/mach-imx/eukrea_mbimx27-baseboard.c - I noticed the
> touchscreen controller (ADS7846) doesn't work anymore.
>
> A few IRQ are generated when probing for the chipset and starting
> calibration (usually first point works), then nothing more (even if
> the IRQ signals is generated as seen on the scope, the irq count
> doesn't increase anymore and stays <= 4 and no data is reported to
> the input layer).
>
> drivers/input/touchscreen/ads7846.c was switched to threaded IRQ in
> commit 2991a1ca6e9b13b639a82c0eec0cbc191bf1f42f where was added :
> irq_flags |= IRQF_ONESHOT;
AFAIK this is how threaded irq usually work. The irq should get
reenabled by irq_thread -> irq_finalize_oneshot then.
> Commenting out this line in the ads7846 driver makes it work again.
> Am I missing something obvious or is there a reason for IRQF_ONESHOT
> creating trouble with gpio irq or SPI on i.MX ?
I don't know. Is the irq masked? pending?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2011-01-05 11:39 davidgg
0 siblings, 0 replies; 732+ messages in thread
From: davidgg @ 2011-01-05 11:39 UTC (permalink / raw)
To: kvm
Hi all
I'm a computer science student from germany interested in
virtualization technologies and given I have some free time I'd
like to dig into kvm modding, maybe even actual development ;-)
I've been trying to understand the kvm mmu, with a special regard
to paging structures.
I'm having a hard time finding the code that is responsible for
creating the tdp (epml4, epdpt, epd and ept on intel i.e.)
structures, any
hint(s)?
Using some debug output I'm getting tdp_page_faul(s) where the
paging level is 1, how can this be? does this mean all pages are
2MB pages and there are no page tables with 4 kbyte pages at all?
thanks a lot in advance and kind regards,
David
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2010-12-19 23:59 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2010-12-19 23:59 UTC (permalink / raw)
To: ath9k-devel
chip haven't been woken up.
The AR9280 support works (for values of "work") in FreeBSD, so I'm
thinking the local code is missing a couple of relevant register
settings to enable the thing.
Does anyone know off-hand what I may need to glimpse at to make it
work? What's different between the AR9280 and AR9220 initialisation
sequences? I couldn't see anything AR9220 specific in ath9k.
Thanks,
Adrian
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2010-12-19 23:59 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2010-12-19 23:59 UTC (permalink / raw)
To: ath9k-devel
* If your RX chainmask has >1 radio enabled, you'll always be doing
receive-side "diversity" (which is really "combining" (MRC) if I
understand the technology correctly on multi-radio atheros 11n cards);
* If your TX chainmask has >1 radio enabled and the TX descriptor has
the relevant chainmask bits set, you should be transmitting on both
antennas regardless of the rate. I honestly haven't verified it (I've
only verified that behaviour for transmitting legacy rates out of the
11n chips);
* For rates < MCS8 (and legacy rates) there's further TX-side trickery
that can be going on which I'm not too up-to-date on. For example,
some (all?) of the 11n chips allow you to optionally transmit MCS0-7
using STBC. But iirc, STBC is only enabled for 1-stream TX.
In short, if you've got all the radios enabled for RX and ath9k is
enabling both/all radio chains when TX'ing, I think the answer is
"yes" for you. :)
Adrian
On 16 February 2011 22:47, Baldomero Coll <baldo.ath9k@gmail.com> wrote:
> I'm not sure, but I've read somewhere that by default the two antennas are
> used.
> It is true that I'm not interested in selecting the number of antennas, what
> I really want is that the MIMO capability is exploited if I'm using 802.11n
> HT IBSS operation mode.
> Can someone confirm that by default the two antennas (spatial diversity) are
> being used when we create the HT IBSS network?
>
> 2011/2/16 Mohammed Shafi <shafi.ath9k@gmail.com>
>>
>> On Tue, Feb 15, 2011 at 2:35 PM, Baldomero Coll <baldo.ath9k@gmail.com>
>> wrote:
>> > Hello,
>> >
>> > Can you please tell me how do you select one o two antennas?
>>
>> I don't know why you should do that. I guess changing the tx/rx
>> chainmask will do after it was read from eeprom.
>>
>> >
>> > I'm using a similar setting than you:
>> > Linux kernel: 2.6.32-28-generic-pae.
>> > Driver: compat-wireless-2011-01-17 and iw-0.9.21 with the patch
>> > suggested by
>> > Alex.
>> > Radio card: Ubiquiti SR71x
>> >
>> > Thanks in advance,
>> > Baldomero
>> >>
>> >> Hi all,
>> >>
>> >> I would like to confirm my findings. My test platform configurations
>> >> are
>> >> follow.
>> >> Board: pcengine alix3d2
>> >> Linux kernel: 2.6.35 from linux-wireless git
>> >> Driver: compat-wireless-2011-01-17 and iw-0.9.21 with the patch
>> >> suggested by Alex.
>> >> Radio card: Ubiqiti SR71a on channel 36 with HT40+
>> >> Measurement tool and settings: Iperf, UDP, 100Mb offered load
>> >>
>> >> Recored throughput: 50-54Mbps (one antenna); 78-80Mbps (two or three
>> >> antennas).
>> >
>> >
>> > _______________________________________________
>> > ath9k-devel mailing list
>> > ath9k-devel at lists.ath9k.org
>> > https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>> >
>> >
>
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2010-12-19 23:59 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2010-12-19 23:59 UTC (permalink / raw)
To: ath9k-devel
<br>
* If your RX chainmask has >1 radio enabled, you'll always be doing<=
br>
receive-side "diversity" (which is really "combining" (=
MRC) if I<br>
understand the technology correctly on multi-radio atheros 11n cards);<br>
* If your TX chainmask has >1 radio enabled and the TX descriptor has<br=
>
the relevant chainmask bits set, you should be transmitting on both<br>
antennas regardless of the rate. I honestly haven't verified it (I'=
ve<br>
only verified that behaviour for transmitting legacy rates out of the<br>
11n chips);<br>
<br>
* For rates < MCS8 (and legacy rates) there's further TX-side tricke=
ry<br>
that can be going on which I'm not too up-to-date on. For example,<br>
some (all?) of the 11n chips allow you to optionally transmit MCS0-7<br>
using STBC. But iirc, STBC is only enabled for 1-stream TX.<br>
<br>
In short, if you've got all the radios enabled =C2=A0for RX and ath9k i=
s<br>
enabling both/all radio chains when TX'ing, I think the answer is<br>
"yes" for you. :)<br>
<br>
Adrian<br>
<br>
On 16 February 2011 22:47, Baldomero Coll <<a href=3D"mailto:baldo.ath9k=
@gmail.com">baldo.ath9k at gmail.com</a>> wrote:<br>
> I'm not sure, but I've read somewhere that by default the two =
antennas are<br>
> used.<br>
> It is true that I'm not interested in selecting the number of ante=
nnas, what<br>
> I really want is that the MIMO capability is exploited if I'm usin=
g 802.11n<br>
> HT IBSS operation mode.<br>
> Can someone confirm that by default the two antennas (spatial diversit=
y) are<br>
> being used when we create the HT IBSS network?<br>
><br>
> 2011/2/16 Mohammed Shafi <<a href=3D"mailto:shafi.ath9k@gmail.com">=
shafi.ath9k at gmail.com</a>><br>
>><br>
>> On Tue, Feb 15, 2011 at 2:35 PM, Baldomero Coll <<a href=3D"mai=
lto:baldo.ath9k@gmail.com">baldo.ath9k at gmail.com</a>><br>
>> wrote:<br>
>> > Hello,<br>
>> ><br>
>> > Can you please tell me how do you select one o two antennas?<=
br>
>><br>
>> I don't know why you should do that. I guess changing the tx/r=
x<br>
>> chainmask will do after it was read from eeprom.<br>
>><br>
>> ><br>
>> > I'm using a similar setting than you:<br>
>> > Linux kernel: 2.6.32-28-generic-pae.<br>
>> > Driver: compat-wireless-2011-01-17 and iw-0.9.21 with the pat=
ch<br>
>> > suggested by<br>
>> > Alex.<br>
>> > Radio card: Ubiquiti SR71x<br>
>> ><br>
>> > Thanks in advance,<br>
>> > Baldomero<br>
>> >><br>
>> >> Hi all,<br>
>> >><br>
>> >> I would like to confirm my findings. My test platform con=
figurations<br>
>> >> are<br>
>> >> follow.<br>
>> >> Board: pcengine alix3d2<br>
>> >> Linux kernel: 2.6.35 from linux-wireless git<br>
>> >> Driver: compat-wireless-2011-01-17 and iw-0.9.21 with the=
patch<br>
>> >> suggested by Alex.<br>
>> >> Radio card: Ubiqiti SR71a on channel 36 with HT40+<br>
>> >> Measurement tool and settings: Iperf, UDP, 100Mb offered =
load<br>
>> >><br>
>> >> Recored throughput: 50-54Mbps (one antenna); 78-80Mbps (t=
wo or three<br>
>> >> antennas).<br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > ath9k-devel mailing list<br>
>> > <a href=3D"mailto:ath9k-devel@lists.ath9k.org">ath9k-devel at li=
sts.ath9k.org</a><br>
>> > <a href=3D"https://lists.ath9k.org/mailman/listinfo/ath9k-dev=
el" target=3D"_blank">https://lists.ath9k.org/mailman/listinfo/ath9k-devel<=
/a><br>
>> ><br>
>> ><br>
><br>
><br>
> _______________________________________________<br>
> ath9k-devel mailing list<br>
> <a href=3D"mailto:ath9k-devel@lists.ath9k.org">ath9k-devel at lists.ath9k=
.org</a><br>
> <a href=3D"https://lists.ath9k.org/mailman/listinfo/ath9k-devel" targe=
t=3D"_blank">https://lists.ath9k.org/mailman/listinfo/ath9k-devel</a><br>
><br>
><br>
</blockquote></div><br>
--002215048f672c1ad2049c7703f8--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2010-12-19 23:59 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2010-12-19 23:59 UTC (permalink / raw)
To: ath9k-devel
<br>
* If your RX chainmask has >1 radio enabled, you'll always be doing<=
br>
receive-side "diversity" (which is really "combining" (=
MRC) if I<br>
understand the technology correctly on multi-radio atheros 11n cards);<br>
* If your TX chainmask has >1 radio enabled and the TX descriptor has<br=
>
the relevant chainmask bits set, you should be transmitting on both<br>
antennas regardless of the rate. I honestly haven't verified it (I'=
ve<br>
only verified that behaviour for transmitting legacy rates out of the<br>
11n chips);<br>
<br>
* For rates < MCS8 (and legacy rates) there's further TX-side tricke=
ry<br>
that can be going on which I'm not too up-to-date on. For example,<br>
some (all?) of the 11n chips allow you to optionally transmit MCS0-7<br>
using STBC. But iirc, STBC is only enabled for 1-stream TX.<br>
<br>
In short, if you've got all the radios enabled =A0for RX and ath9k is<b=
r>
enabling both/all radio chains when TX'ing, I think the answer is<br>
"yes" for you. :)<br>
<br>
Adrian<br>
<br>
On 16 February 2011 22:47, Baldomero Coll <<a href=3D"mailto:baldo.ath9k=
@gmail.com" target=3D"_blank">baldo.ath9k at gmail.com</a>> wrote:<br>
> I'm not sure, but I've read somewhere that by default the two =
antennas are<br>
> used.<br>
> It is true that I'm not interested in selecting the number of ante=
nnas, what<br>
> I really want is that the MIMO capability is exploited if I'm usin=
g 802.11n<br>
> HT IBSS operation mode.<br>
> Can someone confirm that by default the two antennas (spatial diversit=
y) are<br>
> being used when we create the HT IBSS network?<br>
><br>
> 2011/2/16 Mohammed Shafi <<a href=3D"mailto:shafi.ath9k@gmail.com" =
target=3D"_blank">shafi.ath9k at gmail.com</a>><br>
>><br>
>> On Tue, Feb 15, 2011 at 2:35 PM, Baldomero Coll <<a href=3D"mai=
lto:baldo.ath9k@gmail.com" target=3D"_blank">baldo.ath9k at gmail.com</a>><=
br>
>> wrote:<br>
>> > Hello,<br>
>> ><br>
>> > Can you please tell me how do you select one o two antennas?<=
br>
>><br>
>> I don't know why you should do that. I guess changing the tx/r=
x<br>
>> chainmask will do after it was read from eeprom.<br>
>><br>
>> ><br>
>> > I'm using a similar setting than you:<br>
>> > Linux kernel: 2.6.32-28-generic-pae.<br>
>> > Driver: compat-wireless-2011-01-17 and iw-0.9.21 with the pat=
ch<br>
>> > suggested by<br>
>> > Alex.<br>
>> > Radio card: Ubiquiti SR71x<br>
>> ><br>
>> > Thanks in advance,<br>
>> > Baldomero<br>
>> >><br>
>> >> Hi all,<br>
>> >><br>
>> >> I would like to confirm my findings. My test platform con=
figurations<br>
>> >> are<br>
>> >> follow.<br>
>> >> Board: pcengine alix3d2<br>
>> >> Linux kernel: 2.6.35 from linux-wireless git<br>
>> >> Driver: compat-wireless-2011-01-17 and iw-0.9.21 with the=
patch<br>
>> >> suggested by Alex.<br>
>> >> Radio card: Ubiqiti SR71a on channel 36 with HT40+<br>
>> >> Measurement tool and settings: Iperf, UDP, 100Mb offered =
load<br>
>> >><br>
>> >> Recored throughput: 50-54Mbps (one antenna); 78-80Mbps (t=
wo or three<br>
>> >> antennas).<br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > ath9k-devel mailing list<br>
>> > <a href=3D"mailto:ath9k-devel@lists.ath9k.org" target=3D"_bla=
nk">ath9k-devel at lists.ath9k.org</a><br>
>> > <a href=3D"https://lists.ath9k.org/mailman/listinfo/ath9k-dev=
el" target=3D"_blank">https://lists.ath9k.org/mailman/listinfo/ath9k-devel<=
/a><br>
>> ><br>
>> ><br>
><br>
><br>
> _______________________________________________<br>
> ath9k-devel mailing list<br>
> <a href=3D"mailto:ath9k-devel@lists.ath9k.org" target=3D"_blank">ath9k=
-devel at lists.ath9k.org</a><br>
> <a href=3D"https://lists.ath9k.org/mailman/listinfo/ath9k-devel" targe=
t=3D"_blank">https://lists.ath9k.org/mailman/listinfo/ath9k-devel</a><br>
><br>
><br>
</blockquote></div></div></div><br>
</blockquote></div><br></div>
--0016362847b84c7571049c7ca7bc--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2010-12-19 23:59 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2010-12-19 23:59 UTC (permalink / raw)
To: ath9k-devel
interrupt earlier. For example, I send 1st frame with rate MCS 1 and 2nd
frame with MCS 2, but some time I can get hw tx interrupt for second frame
ealier than the first. I think this may relate to the aggregation. So I have
tried set ATH_AMPDU_SUBFRAME_DEFAULT to 1, but that doesn't help. Then I
tried substitute ath_tx_send_ampdu with ath_tx_send_normal in
ath_tx_start_dma, and I find that disorder issue doesn't happen again. Also,
I find that
in the disorder case, it looks like that transmitter triggers
ath_tx_txqaddbuf for 1st then for 2nd, however, immediately ath_tx_txqaddbuf
is triggered again and for 2nd first, and 1st. But from tx_info.status, I
find that both 1st and 2nd frame is transmitted once and successfully
received.
Moreover, the transmitter may send 1st aggregation frame with sequence from
0-31, and send 2nd aggregation frame with sequence 32-63 immediately, and
then based on the tx_info.status, transmitter send the un-acked frame in the
later frame. In this case, I mean, transmitter can send the 2nd aggregation
frame without knowing the result for the first one, is this right?
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2010-12-19 23:59 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2010-12-19 23:59 UTC (permalink / raw)
To: ath9k-devel
when the transmitter receive the hw tx interrupt, is there anything wrong or
missing? Actually, I don't quite understand how aggregation works in ath9k,
could you give some information?
Thank you for your time on this.
Best regards,
Jerry Zhao
--0016e649cdb2575291049ce47042
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Dear all,<br>Good day.<br>I have got a question about disorder of hw tx int=
erupt. I am looking for your helps. Thanks in advance.<br>I am using D-link=
652 and ubuntu 10.04 as my platform.<br>I am running some tests, I set fra=
mes with an cyclic increasing rate from MCS 0 - MCS 15, it's done per f=
rame. After the transmitter sends the frame, it gets a hw tx interrupt afte=
r successful transmission or no ack.<br>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2010-12-19 23:59 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2010-12-19 23:59 UTC (permalink / raw)
To: ath9k-devel
rupt earlier. For example, I send 1st frame=A0 with rate MCS 1 and 2nd fram=
e with MCS 2, but some time I can get hw tx interrupt for second frame eali=
er than the first. I think this may relate to the aggregation. So I have tr=
ied set ATH_AMPDU_SUBFRAME_DEFAULT to 1, but that doesn't help. Then I =
tried substitute ath_tx_send_ampdu with ath_tx_send_normal in ath_tx_start_=
dma, and I find that disorder issue doesn't happen again. Also, I find =
that <br>
in the disorder case, it looks like that transmitter triggers ath_tx_txqadd=
buf for 1st then for 2nd, however, immediately ath_tx_txqaddbuf is triggere=
d again and for 2nd first, and 1st. But from tx_info.status, I find that bo=
th 1st and 2nd frame is transmitted once and successfully received.<br>
<br>Moreover, the transmitter may send 1st aggregation frame with sequence =
from 0-31, and send 2nd aggregation frame with sequence 32-63 immediately, =
and then based on the tx_info.status, transmitter send the un-acked frame i=
n the later frame. In this case, I mean, transmitter can send the 2nd aggre=
gation frame without knowing the result for the first one, is this right?<b=
r>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2010-12-19 23:59 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2010-12-19 23:59 UTC (permalink / raw)
To: ath9k-devel
hen the transmitter receive the hw tx interrupt, is there anything wrong or=
missing? Actually, I don't quite understand how aggregation works in a=
th9k, could you give some information? <br>
<br>Thank you for your time on this.<br><br>Best regards,<br>Jerry Zhao<br>
--0016e649cdb2575291049ce47042--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2010-12-19 23:59 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2010-12-19 23:59 UTC (permalink / raw)
To: ath9k-devel
rupt earlier. For example, I send 1st frame=A0 with rate MCS 1 and 2nd fram=
e with MCS 2, but some time I can get hw tx interrupt for second frame eali=
er than the first. I think this may relate to the aggregation. So I have tr=
ied set ATH_AMPDU_SUBFRAME_DEFAULT to 1, but that doesn't help. Then I =
tried substitute ath_tx_send_ampdu with ath_tx_send_normal in ath_tx_start_=
dma, and I find that disorder issue doesn't happen again. Also, I find =
that <br>
in the disorder case, it looks like that transmitter triggers ath_tx_txqadd=
buf for 1st then for 2nd, however, immediately ath_tx_txqaddbuf is triggere=
d again and for 2nd first, and 1st. But from tx_info.status, I find that bo=
th 1st and 2nd frame is transmitted once and successfully received.<br>
<br>Moreover, the transmitter may send 1st aggregation frame with sequence =
from 0-31, and send 2nd aggregation frame with sequence 32-63 immediately, =
and then based on the tx_info.status, transmitter send the un-acked frame i=
n the later frame. In this case, I mean, transmitter can send the 2nd aggre=
gation frame without knowing the result for the first one, is this right?<b=
r>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2010-12-19 23:59 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2010-12-19 23:59 UTC (permalink / raw)
To: ath9k-devel
hen the transmitter receive the hw tx interrupt, is there anything wrong or=
missing? Actually, I don't quite understand how aggregation works in a=
th9k, could you give some information? <br>
<br>Thank you for your time on this.<br><br>Best regards,<br>Jerry Zhao<br>
<br>_______________________________________________<br>
ath9k-devel mailing list<br>
<a href=3D"mailto:ath9k-devel@lists.ath9k.org">ath9k-devel at lists.ath9k.org<=
/a><br>
<a href=3D"https://lists.ath9k.org/mailman/listinfo/ath9k-devel" target=3D"=
_blank">https://lists.ath9k.org/mailman/listinfo/ath9k-devel</a><br>
<br></blockquote></div><br></div></div>
--bcaec53f8e215e2cfc049ce55219--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2010-12-19 23:59 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2010-12-19 23:59 UTC (permalink / raw)
To: ath9k-devel
rupt earlier. For example, I send 1st frame=A0 with rate MCS 1 and 2nd fram=
e with MCS 2, but some time I can get hw tx interrupt for second frame eali=
er than the first. I think this may relate to the aggregation. So I have tr=
ied set ATH_AMPDU_SUBFRAME_DEFAULT to 1, but that doesn't help. Then I =
tried substitute ath_tx_send_ampdu with ath_tx_send_normal in ath_tx_start_=
dma, and I find that disorder issue doesn't happen again. Also, I find =
that <br>
in the disorder case, it looks like that transmitter triggers ath_tx_txqadd=
buf for 1st then for 2nd, however, immediately ath_tx_txqaddbuf is triggere=
d again and for 2nd first, and 1st. But from tx_info.status, I find that bo=
th 1st and 2nd frame is transmitted once and successfully received.<br>
<br>Moreover, the transmitter may send 1st aggregation frame with sequence =
from 0-31, and send 2nd aggregation frame with sequence 32-63 immediately, =
and then based on the tx_info.status, transmitter send the un-acked frame i=
n the later frame. In this case, I mean, transmitter can send the 2nd aggre=
gation frame without knowing the result for the first one, is this right?<b=
r>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2010-12-19 23:59 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2010-12-19 23:59 UTC (permalink / raw)
To: ath9k-devel
hen the transmitter receive the hw tx interrupt, is there anything wrong or=
missing? Actually, I don't quite understand how aggregation works in a=
th9k, could you give some information? <br>
<br>Thank you for your time on this.<br><br>Best regards,<br>Jerry Zhao<br>
</blockquote></div><br>
--0016e659f780473917049cfe2f87--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2010-12-19 23:59 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2010-12-19 23:59 UTC (permalink / raw)
To: ath9k-devel
discarded. But for ping packet __ieee80211_parse_tx_radiotap function
returns false. Surprisingly radtap_hdr_len is getting printed to be 65535,
which I assumed will be 0 at this point.
So in function ieee80211_monitor_start_xmit(), i tried following
approaches:
1) pulling radio tap header from skb and disabling RADIOTAP flag and send
rest of skb as it is.
2) allocate a new skb of size ieee80211_hdr and assigning first 2 bytes of
skb->data to 0x08 and 0x02 and pass this skb to the called functions.
However i could not see any activity over the air. :(.
I am not using packetspammer like utlity to send packets to driver, but just
ping packets.
Any suggestion over this will be appreciated.
Thanks
-Sagar
--20cf3079bdf4c2e5cd049d932c1c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hi, <br>For my research, I want to send the packet at a specified time. I g=
uess monitor mode is suitable for this. <br>From code it looks like in moni=
tor mode the radiotap header is parsed and discarded. But for ping packet _=
_ieee80211_parse_tx_radiotap function returns false. Surprisingly radtap_hd=
r_len is getting printed to be 65535, which I assumed will be 0 at this poi=
nt.<br>
<br>So in function=A0 ieee80211_monitor_start_xmit(), i tried following app=
roaches:<br>1) pulling radio tap header from skb and disabling RADIOTAP fla=
g and send rest of skb as it is. <br>2) allocate a new skb of size=A0 ieee8=
0211_hdr and assigning=A0 first 2 bytes of skb->data to=A0 0x08 and 0x02=
and pass this skb to the called functions.<br>
However i could not see any activity over the air. :(. <br>I am not using p=
acketspammer like utlity to send packets to driver, but just ping packets.<=
br>Any suggestion over this will be appreciated. <br><br>Thanks<br>-Sagar<b=
r>
--20cf3079bdf4c2e5cd049d932c1c--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2010-12-19 23:59 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2010-12-19 23:59 UTC (permalink / raw)
To: ath9k-devel
MIMO, but with only two spatial streams, so it should handle MCS0
through MCS15. Check the output of "iw list" for a line like the
following:
HT TX/RX MCS rate indexes supported: 0-15
It is possible for a card to support multiple spatial streams without
having support for space-time block coding.
-Brian
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2010-12-03 1:08 tarek attia
0 siblings, 0 replies; 732+ messages in thread
From: tarek attia @ 2010-12-03 1:08 UTC (permalink / raw)
To: linux-arm-kernel
register
--
tarek
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2010-10-08 6:02 Daein Moon
0 siblings, 0 replies; 732+ messages in thread
From: Daein Moon @ 2010-10-08 6:02 UTC (permalink / raw)
To: linux-arm-kernel
Hi Ben Dooks and Kukjin,
I found an issue about s3c_gpio_getpull API.
The 'plat-samsung' provides 's3c_gpio_setpull' and 's3c_gpio_getpull'
to set and get pull-{none|up|down} of GPIO. But there is no
's3c_gpio_getpull' definition in 'arch/arm/plat-samsung/gpio-config.c',
and there is only declaration in the corresponding header file.
's3c_gpio_getpull' isn't supported/used. So if providing this api, its
definition should be inserted.
Otherwise, code that is used to provide s3c_gpio_getpull including
following code should be removed.
arch/arm/plat-samsung/include/plat/gpio-cfg.h:
extern s3c_gpio_pull_t s3c_gpio_getpull(unsigned int pin);
arch/arm/mach-{s3c*|s5p*}/gpiolib.c:
.get_pull = s3c_gpio_getpull_updown,
What do you think about that?
Best Regards,
Daein Moon
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2010-09-24 14:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2010-09-24 14:53 UTC (permalink / raw)
To: ath9k-devel
possible with the driver at this point.
As a side note, no, iwconfig should not be used for anything anymore.
//Peter
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2010-09-24 14:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2010-09-24 14:53 UTC (permalink / raw)
To: ath9k-devel
when ath_draintxq() is called. From ath_draintxq() point of view that
looks like a bad idea (race between CPU and DMA).
Also, that looking around "cabq_depth =3D cabq->axq_depth;" looks very
peculiar. I believe it's correct (because nobody else puts anything
into this queue and we don't care if it's shorter later on when we
drain it) but I think it would be nice with a comment.
Any thoughts? I can whip up and test a patch if there are no objections.
/Bj=F6rn
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2010-09-24 14:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2010-09-24 14:53 UTC (permalink / raw)
To: ath9k-devel
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2010-09-24 14:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2010-09-24 14:53 UTC (permalink / raw)
To: ath9k-devel
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2010-09-24 14:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2010-09-24 14:53 UTC (permalink / raw)
To: ath9k-devel
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2010-09-24 14:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2010-09-24 14:53 UTC (permalink / raw)
To: ath9k-devel
Like you said, it is low because both interfaces share the medium but if I don??t change the rate using iwconfig, this values or at least the first one goes down until 1,5 MBits. That??s way I wonder if there is something that keeps the rate low by the time a virtual interface is created.
Thanks for your response
Best regards
Lorna
-------- Original-Nachricht --------
> Datum: Thu, 11 Nov 2010 09:00:45 -0800
> Von: Ben Greear <greearb@candelatech.com>
> An: "Lorna Gonz??lez" <lorna.glez@gmx.net>
> CC: Jouni Malinen <jouni.malinen@atheros.com>, ath9k-devel at venema.h4ckr.net
> Betreff: Re: [ath9k-devel] ath9k: Virtual interface as AP
> On 11/11/2010 07:06 AM, "Lorna Gonz??lez" wrote:
> >
> > Hello
> >
> > I finally got a station an a virtual AP working on the same channel
> using the setup below. I made some test sending TCP through iperf between the
> AP and the station and the VAP to a station associated with it.
> > Using an AP operating with Ieee802.11n, an atheros AR928X and without
> virtual interfaces I get a max throughput of 50 MBits/s.
> > As soon as I start using my desired setup, the thoughput of the station
> is about 15 MBits/s... I actually need to make the rate fixed using
> iwconfig to get this max. Otherwise the traffic is sent at 1 MBit/s.
> >
> > Can someone please tell me how is the behaviour of the rate control in
> case of virtual interfaces on mac80211?
>
> Can you give a more detailed description/diagram of your virtual AP setup
> and
> network throughput test? It sounds like you are using the same radio as
> AP
> and STA? If so, then of course you are going to get less bandwidth on the
> VIFS because they have to share the radio.
>
> I'm not sure it should drop all the way to 15Mbps, though. We haven't
> done a lot of throughput
> testing yet, but if we use two STA vifs on the ath9k box connected to an
> 80211n AP (trendnet),
> then we can set a max of about 9Mbps tx + rx across each STA (the STAs are
> sending to each other).
> That is around 40Mbps total tx + rx across the radio.
>
> Thanks,
> Ben
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc http://www.candelatech.com
>
--
Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!
Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2010-09-24 14:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2010-09-24 14:53 UTC (permalink / raw)
To: ath9k-devel
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2010-09-24 14:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2010-09-24 14:53 UTC (permalink / raw)
To: ath9k-devel
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2010-09-24 14:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2010-09-24 14:53 UTC (permalink / raw)
To: ath9k-devel
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2010-09-24 14:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2010-09-24 14:53 UTC (permalink / raw)
To: ath9k-devel
Like you said, it is low because both interfaces share the medium but if I don??t change the rate using iwconfig, this values or at least the first one goes down until 1,5 MBits. That??s way I wonder if there is something that keeps the rate low by the time a virtual interface is created.
Thanks for your response
Best regards
Lorna
-------- Original-Nachricht --------
> Datum: Thu, 11 Nov 2010 09:00:45 -0800
> Von: Ben Greear <greearb@candelatech.com>
> An: "Lorna Gonz??lez" <lorna.glez@gmx.net>
> CC: Jouni Malinen <jouni.malinen@atheros.com>, ath9k-devel at venema.h4ckr.net
> Betreff: Re: [ath9k-devel] ath9k: Virtual interface as AP
> On 11/11/2010 07:06 AM, "Lorna Gonz??lez" wrote:
> >
> > Hello
> >
> > I finally got a station an a virtual AP working on the same channel
> using the setup below. I made some test sending TCP through iperf between the
> AP and the station and the VAP to a station associated with it.
> > Using an AP operating with Ieee802.11n, an atheros AR928X and without
> virtual interfaces I get a max throughput of 50 MBits/s.
> > As soon as I start using my desired setup, the thoughput of the station
> is about 15 MBits/s... I actually need to make the rate fixed using
> iwconfig to get this max. Otherwise the traffic is sent at 1 MBit/s.
> >
> > Can someone please tell me how is the behaviour of the rate control in
> case of virtual interfaces on mac80211?
>
> Can you give a more detailed description/diagram of your virtual AP setup
> and
> network throughput test? It sounds like you are using the same radio as
> AP
> and STA? If so, then of course you are going to get less bandwidth on the
> VIFS because they have to share the radio.
>
> I'm not sure it should drop all the way to 15Mbps, though. We haven't
> done a lot of throughput
> testing yet, but if we use two STA vifs on the ath9k box connected to an
> 80211n AP (trendnet),
> then we can set a max of about 9Mbps tx + rx across each STA (the STAs are
> sending to each other).
> That is around 40Mbps total tx + rx across the radio.
>
> Thanks,
> Ben
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc http://www.candelatech.com
>
--
Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!
Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2010-09-24 14:53 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2010-09-24 14:53 UTC (permalink / raw)
To: ath9k-devel
ath9k, I read.
The mac filtering has not implemented at ath9k or not?
I would like to know how it is about the status.
Any comments will be very appreciated of..
-
mason
--0016e68e92891791f80497724c8a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div>From the openwrt site, mac address filtering has not implemented yet a=
t ath9k, I read.</div>
<div>The mac filtering has not implemented at ath9k or not? </div>
<div>=A0</div>
<div>I would like to know how it is about the status.</div>
<div>=A0</div>
<div>Any comments will be very appreciated of..</div>
<div>-</div>
<div>mason</div>
<div><br clear=3D"all"><br>=A0</div>
--0016e68e92891791f80497724c8a--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2010-09-09 3:33 tarek attia
0 siblings, 0 replies; 732+ messages in thread
From: tarek attia @ 2010-09-09 3:33 UTC (permalink / raw)
To: linux-arm-kernel
register
--
tarek
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2010-08-30 5:02 auto595907
0 siblings, 0 replies; 732+ messages in thread
From: auto595907 @ 2010-08-30 5:02 UTC (permalink / raw)
To: rjw; +Cc: linux-kernel
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16423
Subject : netfilter/iptables stopped logging 2.6.35-rc
Submitter : auto401300@hushmail.com
Date : 2010-07-17 10:20 (44 days old)
Message-ID : <20100717072036.1BBE52804B@smtp.hushmail.com>
References :
http://lkml.indiana.edu/hypermail/linux/kernel/1007.2/00440.html
this patch fixes the bug above:
(http://marc.info/?l=netfilter-devel&m=128116762801769&w=2)
fixed in 2.6.36-rc3
thanks
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2010-08-23 14:32 auto595907
0 siblings, 0 replies; 732+ messages in thread
From: auto595907 @ 2010-08-23 14:32 UTC (permalink / raw)
To: maciej.rutecki; +Cc: netdev, linux-kernel
>I created a Bugzilla entry at
>https://bugzilla.kernel.org/show_bug.cgi?id=16423
>for your bug report, please add your address to the CC list in
>there, thanks!
>
>--
>Maciej Rutecki
>http://www.maciek.unixy.pl
this patch fixes the bug above
(http://marc.info/?l=netfilter-devel&m=128116762801769&w=2)
thanks.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2010-07-23 10:05 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2010-07-23 10:05 UTC (permalink / raw)
To: ath9k-devel
mesh point. We have not yet figured out why the mesh interface is removed a=
nd reset to an interface of type NL80211_IFTYPE_STATION.
Regards
Abhijeet
-----Original Message-----
From: Luis R. Rodriguez [mailto:mcgrof at gmail.com]
Sent: Wednesday, July 28, 2010 9:23 PM
To: Abhijeet Chandran
Cc: ath9k-devel at lists.ath9k.org
Subject: Re: [ath9k-devel] ath9k mesh point not emitting beacons
On Wed, Jul 28, 2010 at 7:19 AM, Abhijeet Chandran <Abhijeet.Chandran@arice=
nt.com> wrote:
> Hi
> We have a problem that we have configured a mesh point for the first
> time and it does not seem to start emitting beacons as soon as it comes=
up.
> The card we are using is ath 9220
> We brought mesh point up , ex:
> # iw phy phy0 interface add mesh type mp mesh_id mymesh # ifconfig
> mesh up
>
> Through tracing in the kernel module mac80211 it appears that a
> callback function ieee80211_open is called with type mesh point as
> soon as the above commands are executed.
> However it is immediately followed by the callback function
> ieee80211_stop (usually called when the mesh point is brought down) ,
> following which the meshpoint related sdata is flushed .
> Another question that we have is that do we need to enable scanning
> for the mesh point to emit beacons/probes?
>
> We have used the simulator mac80211_hwsim before in which beacons are
> emitted as soon as the mesh point comes up.In the simulator don't need
> to start scanning on the mesh point.
> We'd really appreciate if somone can help us out here.
Known issue no one has yet looked into:
https://bugzilla.kernel.org/show_bug.cgi?id=3D14187
It should start beaconing if you issue a scan.
Luis
"DISCLAIMER: This message is proprietary to Aricent and is intended solely =
for the use of the individual to whom it is addressed. It may contain privi=
leged or confidential information and should not be circulated or used for =
any purpose other than for what it is intended. If you have received this m=
essage in error, please notify the originator immediately. If you are not t=
he intended recipient, you are notified that you are strictly prohibited fr=
om using, copying, altering, or disclosing the contents of this message. Ar=
icent accepts no responsibility for loss or damage arising from the use of =
the information transmitted by this email including damage from virus."
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2010-06-24 13:48 Uwe Kleine-König
0 siblings, 0 replies; 732+ messages in thread
From: Uwe Kleine-König @ 2010-06-24 13:48 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
this is the next step in the project "clean up the imx port" targeting
2.6.36. The highlights this time are:
- Unification of mach-mx2 and mach-mx1 into mach-imx
- start allocating devices dynamically
This should reduce the memory footprint because (in the end) no
unused struct platform_device, struct resource or struct
$platformdatafordriverX are kept in memory. This also cleans up
with naming conflicts.
This is intermixed with various fixes and simplifications.
I have to admit that some patches could have squashed but squashing them
now would be more work that it's worth so I kept them as they are now.
The patches are based on 67a3e12b05e055c0415c556a315a3d3eb637e29e
Linux 2.6.35-rc1 (2010-05-30 13:21:02 -0700)
and are available in the git repository at:
git://git.pengutronix.de/git/ukl/linux-2.6.git imx/for-2.6.36
plus sent as a reply to this mail. Shortlog and diffstat are to be
found below.
Have fun
Uwe
Uwe Kleine-K?nig (61):
ARM: mx3: rename mach-mx35pdk.c to mach-mx35_3ds.c matching its arch number
ARM: mx25: rename mach-mx25pdk.c to mach-mx25_3ds.c matching its arch number
ARM: mx1: don't use deprecated symbol names
ARM: mx1/scb9328: fix type of uart1_mxc_exit to make compiler happy
ARM: mx2/mx27_3ds: document alternative names and remove empty header
ARM: imx: remove empty and unused board headers
ARM: mx3/kzm_arm11_01: fold board header in its only user
ARM: mx2/mx21ads: fold board header in its only user
ARM: mx2/mx27ads: fold board header in its only user
ARM: mx3/qong: get rid of nearly empty header
ARM: mx3/mx31_3ds: fold board header in its only user
ARM: mx3/mx31ads: fold board header in its only user
ARM: mxc: grammar fix
ARM: imx: rename mach dir for mx21 and mx27 to mach-imx
ARM: imx/mx1: fold crm_regs.h into its only consumer
ARM: imx: get rid of mxc_gpio_init
ARM: imx: fold serial.c into devices.c
ARM: imx1: rename imx_csi_device to match its .name
ARM: imx1: rename imx_i2c_device to follow a common naming scheme
ARM: imx1: rename imx_uart[12]_device to follow a common naming scheme
ARM: mx3: mx31lilly: fix build error for !CONFIG_USB_ULPI
ARM: imx: rename mxc_uart_devicex to follow a common naming scheme
ARM: imx: move mx1 support to mach-imx
ARM: imx: Kconfig: use an if block instead of a depend for many symbols
ARM: imx: prepare deprecating ARCH_MX1, MACH_MX2, MACH_MX21 and MACH_MX27
ARM: imx: prepare deprecating ARCH_MX1, MACH_MX2, MACH_MX21 and MACH_MX27
ARM: imx: new Kconfig symbol and feature test macro for DMA on mx1 and mx2
ARM: imx: new helper function imx_add_platform_device
MTD: mxc_nand: make bit fields unsigned to please sparse
ARM: imx: remove paragraphs with old address of the FSF
ARM: mx25: remove paragraphs with old address of the FSF
ARM: mx3: remove paragraphs with old address of the FSF
ARM: mxc91231: remove paragraphs with old address of the FSF
ARM: mxc: remove paragraphs with old address of the FSF
ARM: imx: Change the way nand devices are registered (generic part)
ARM: imx: Change the way nand devices are registered (imx21)
ARM: imx: Change the way nand devices are registered (imx25)
ARM: imx: Change the way nand devices are registered (imx27)
ARM: imx: Change the way nand devices are registered (imx31)
ARM: imx: Change the way nand devices are registered (imx35)
ARM: imx: dynamically register imx-i2c devices (generic part)
ARM: imx: dynamically register imx-i2c devices (imx1)
ARM: imx: dynamically register imx-i2c devices (imx21)
ARM: imx: dynamically register imx-i2c devices (imx25)
ARM: imx: dynamically register imx-i2c devices (imx27)
ARM: imx: dynamically register imx-i2c devices (imx31)
ARM: imx: dynamically register imx-i2c devices (imx35)
ARM: imx: dynamically register spi_imx devices (generic part)
ARM: imx: dynamically register spi_imx devices (imx21)
ARM: imx: dynamically register spi_imx devices (imx25)
ARM: imx: dynamically register spi_imx devices (imx27)
ARM: imx: dynamically register spi_imx devices (imx31)
ARM: imx: dynamically register spi_imx devices (imx35)
ARM: imx: dynamically register imx-uart devices (generic part)
ARM: imx: dynamically register imx-uart devices (imx1)
ARM: imx: dynamically register imx-uart devices (imx21)
ARM: imx: dynamically register imx-uart devices (imx25)
ARM: imx: dynamically register imx-uart devices (imx27)
ARM: imx: dynamically register imx-uart devices (imx31)
ARM: imx: dynamically register imx-uart devices (imx35)
ARM: mx3: complement uart init routine with an exit routine
arch/arm/Makefile | 4 +-
arch/arm/mach-imx/Kconfig | 186 +++++++++++
arch/arm/{mach-mx2 => mach-imx}/Makefile | 18 +-
arch/arm/{mach-mx2 => mach-imx}/Makefile.boot | 4 +
.../{mach-mx1/clock.c => mach-imx/clock-imx1.c} | 50 +++-
.../clock_imx21.c => mach-imx/clock-imx21.c} | 0
.../clock_imx27.c => mach-imx/clock-imx27.c} | 0
.../{mach-mx2/cpu_imx27.c => mach-imx/cpu-imx27.c} | 0
arch/arm/mach-imx/devices-imx1.h | 18 +
arch/arm/mach-imx/devices-imx21.h | 30 ++
arch/arm/mach-imx/devices-imx27.h | 38 +++
arch/arm/{mach-mx2 => mach-imx}/devices.c | 250 +++++++++------
arch/arm/{mach-mx2 => mach-imx}/devices.h | 30 +--
.../{plat-mxc/dma-mx1-mx2.c => mach-imx/dma-v1.c} | 4 +-
.../eukrea_mbimx27-baseboard.c | 19 +-
arch/arm/mach-imx/include/mach/dma-mx1-mx2.h | 10 +
.../include/mach/dma-v1.h} | 10 +-
arch/arm/{mach-mx2 => mach-imx}/mach-cpuimx27.c | 25 +-
arch/arm/{mach-mx2 => mach-imx}/mach-imx27lite.c | 11 +-
arch/arm/{mach-mx1 => mach-imx}/mach-mx1ads.c | 34 +-
arch/arm/{mach-mx2 => mach-imx}/mach-mx21ads.c | 58 +++-
arch/arm/{mach-mx2 => mach-imx}/mach-mx27_3ds.c | 17 +-
arch/arm/{mach-mx2 => mach-imx}/mach-mx27ads.c | 76 +++--
arch/arm/{mach-mx2 => mach-imx}/mach-mxt_td60.c | 36 +--
arch/arm/{mach-mx2 => mach-imx}/mach-pca100.c | 23 +-
arch/arm/{mach-mx2 => mach-imx}/mach-pcm038.c | 33 +--
arch/arm/{mach-mx1 => mach-imx}/mach-scb9328.c | 21 +-
.../arm/{mach-mx1/generic.c => mach-imx/mm-imx1.c} | 23 +-
arch/arm/{mach-mx2 => mach-imx}/mm-imx21.c | 5 +-
arch/arm/{mach-mx2 => mach-imx}/mm-imx27.c | 5 +-
.../ksym_mx1.c => mach-imx/mx1-camera-fiq-ksym.c} | 0
.../mx1_camera_fiq.S => mach-imx/mx1-camera-fiq.S} | 0
arch/arm/{mach-mx2 => mach-imx}/pcm970-baseboard.c | 0
arch/arm/mach-mx1/Kconfig | 19 -
arch/arm/mach-mx1/Makefile | 15 -
arch/arm/mach-mx1/Makefile.boot | 4 -
arch/arm/mach-mx1/crm_regs.h | 55 ---
arch/arm/mach-mx1/devices.c | 242 --------------
arch/arm/mach-mx1/devices.h | 7 -
arch/arm/mach-mx2/Kconfig | 116 -------
arch/arm/mach-mx2/serial.c | 141 --------
arch/arm/mach-mx25/Kconfig | 2 +
arch/arm/mach-mx25/Makefile | 2 +-
arch/arm/mach-mx25/devices-imx25.h | 38 +++
arch/arm/mach-mx25/devices.c | 231 +-------------
arch/arm/mach-mx25/devices.h | 12 -
.../mach-mx25/{mach-mx25pdk.c => mach-mx25_3ds.c} | 21 +-
arch/arm/mach-mx25/mm.c | 7 +-
arch/arm/mach-mx3/Kconfig | 26 ++
arch/arm/mach-mx3/Makefile | 2 +-
arch/arm/mach-mx3/devices-imx31.h | 38 +++
arch/arm/mach-mx3/devices-imx35.h | 32 ++
arch/arm/mach-mx3/devices.c | 247 +--------------
arch/arm/mach-mx3/devices.h | 13 -
arch/arm/mach-mx3/mach-armadillo5x0.c | 17 +-
arch/arm/mach-mx3/mach-kzm_arm11_01.c | 31 ++-
arch/arm/mach-mx3/mach-mx31_3ds.c | 64 +++--
arch/arm/mach-mx3/mach-mx31ads.c | 55 +++-
arch/arm/mach-mx3/mach-mx31lilly.c | 47 ++--
arch/arm/mach-mx3/mach-mx31lite.c | 17 +-
arch/arm/mach-mx3/mach-mx31moboard.c | 50 ++--
.../mach-mx3/{mach-mx35pdk.c => mach-mx35_3ds.c} | 16 +-
arch/arm/mach-mx3/mach-pcm037.c | 31 +-
arch/arm/mach-mx3/mach-pcm037_eet.c | 7 +-
arch/arm/mach-mx3/mach-pcm043.c | 25 +-
arch/arm/mach-mx3/mach-qong.c | 16 +-
arch/arm/mach-mx3/mm.c | 7 +-
arch/arm/mach-mx3/mx31lilly-db.c | 14 +-
arch/arm/mach-mx3/mx31lite-db.c | 15 +-
arch/arm/mach-mx3/mx31moboard-devboard.c | 10 +-
arch/arm/mach-mx3/mx31moboard-marxbot.c | 4 -
arch/arm/mach-mx3/mx31moboard-smartbot.c | 11 +-
arch/arm/mach-mx5/devices.c | 2 +-
arch/arm/mach-mx5/mm.c | 3 +
arch/arm/mach-mxc91231/crm_regs.h | 5 -
arch/arm/mach-mxc91231/devices.c | 2 +-
arch/arm/mach-mxc91231/mm.c | 8 +-
arch/arm/plat-mxc/Kconfig | 10 +-
arch/arm/plat-mxc/Makefile | 4 +-
arch/arm/plat-mxc/audmux-v1.c | 4 -
arch/arm/plat-mxc/audmux-v2.c | 4 -
arch/arm/plat-mxc/devices.c | 33 ++
arch/arm/plat-mxc/devices/Kconfig | 11 +
arch/arm/plat-mxc/devices/Makefile | 4 +
arch/arm/plat-mxc/devices/platform-imx-i2c.c | 29 ++
arch/arm/plat-mxc/devices/platform-imx-uart.c | 60 ++++
arch/arm/plat-mxc/devices/platform-mxc_nand.c | 44 +++
arch/arm/plat-mxc/devices/platform-spi_imx.c | 30 ++
arch/arm/plat-mxc/ehci.c | 4 -
.../arm/plat-mxc/include/mach/board-armadillo5x0.h | 15 -
.../plat-mxc/include/mach/board-eukrea_cpuimx27.h | 2 +-
arch/arm/plat-mxc/include/mach/board-kzmarm11.h | 39 ---
arch/arm/plat-mxc/include/mach/board-mx21ads.h | 52 ---
arch/arm/plat-mxc/include/mach/board-mx27ads.h | 344 --------------------
arch/arm/plat-mxc/include/mach/board-mx27lite.h | 14 -
arch/arm/plat-mxc/include/mach/board-mx27pdk.h | 14 -
arch/arm/plat-mxc/include/mach/board-mx31_3ds.h | 59 ----
arch/arm/plat-mxc/include/mach/board-mx31ads.h | 117 -------
arch/arm/plat-mxc/include/mach/board-mx31lilly.h | 2 +-
arch/arm/plat-mxc/include/mach/board-mx31lite.h | 2 +-
arch/arm/plat-mxc/include/mach/board-mx31moboard.h | 2 +-
arch/arm/plat-mxc/include/mach/board-mx35pdk.h | 22 --
arch/arm/plat-mxc/include/mach/board-pcm037.h | 22 --
arch/arm/plat-mxc/include/mach/board-pcm038.h | 2 +-
arch/arm/plat-mxc/include/mach/board-pcm043.h | 22 --
arch/arm/plat-mxc/include/mach/board-qong.h | 17 -
arch/arm/plat-mxc/include/mach/devices-common.h | 42 +++
arch/arm/plat-mxc/include/mach/iomux-mxc91231.h | 4 -
arch/arm/plat-mxc/include/mach/mx1.h | 28 +-
arch/arm/plat-mxc/include/mach/mx25.h | 28 ++-
arch/arm/plat-mxc/include/mach/mx27.h | 4 +-
arch/arm/plat-mxc/include/mach/mx31.h | 4 +-
arch/arm/plat-mxc/include/mach/mx35.h | 4 +-
arch/arm/plat-mxc/include/mach/mx3_camera.h | 4 -
arch/arm/plat-mxc/include/mach/mxc91231.h | 4 -
arch/arm/plat-mxc/include/mach/mxc_nand.h | 6 +-
arch/arm/plat-mxc/include/mach/system.h | 4 -
arch/arm/plat-mxc/include/mach/timex.h | 4 -
arch/arm/plat-mxc/include/mach/uncompress.h | 4 -
arch/arm/plat-mxc/include/mach/vmalloc.h | 4 -
arch/arm/plat-mxc/irq.c | 3 -
arch/arm/plat-mxc/system.c | 4 -
arch/arm/plat-mxc/tzic.c | 2 -
123 files changed, 1424 insertions(+), 2478 deletions(-)
create mode 100644 arch/arm/mach-imx/Kconfig
rename arch/arm/{mach-mx2 => mach-imx}/Makefile (55%)
rename arch/arm/{mach-mx2 => mach-imx}/Makefile.boot (67%)
rename arch/arm/{mach-mx1/clock.c => mach-imx/clock-imx1.c} (90%)
rename arch/arm/{mach-mx2/clock_imx21.c => mach-imx/clock-imx21.c} (100%)
rename arch/arm/{mach-mx2/clock_imx27.c => mach-imx/clock-imx27.c} (100%)
rename arch/arm/{mach-mx2/cpu_imx27.c => mach-imx/cpu-imx27.c} (100%)
create mode 100644 arch/arm/mach-imx/devices-imx1.h
create mode 100644 arch/arm/mach-imx/devices-imx21.h
create mode 100644 arch/arm/mach-imx/devices-imx27.h
rename arch/arm/{mach-mx2 => mach-imx}/devices.c (73%)
rename arch/arm/{mach-mx2 => mach-imx}/devices.h (54%)
rename arch/arm/{plat-mxc/dma-mx1-mx2.c => mach-imx/dma-v1.c} (99%)
rename arch/arm/{mach-mx2 => mach-imx}/eukrea_mbimx27-baseboard.c (93%)
create mode 100644 arch/arm/mach-imx/include/mach/dma-mx1-mx2.h
rename arch/arm/{plat-mxc/include/mach/dma-mx1-mx2.h => mach-imx/include/mach/dma-v1.h} (93%)
rename arch/arm/{mach-mx2 => mach-imx}/mach-cpuimx27.c (90%)
rename arch/arm/{mach-mx2 => mach-imx}/mach-imx27lite.c (86%)
rename arch/arm/{mach-mx1 => mach-imx}/mach-mx1ads.c (81%)
rename arch/arm/{mach-mx2 => mach-imx}/mach-mx21ads.c (77%)
rename arch/arm/{mach-mx2 => mach-imx}/mach-mx27_3ds.c (85%)
rename arch/arm/{mach-mx2 => mach-imx}/mach-mx27ads.c (82%)
rename arch/arm/{mach-mx2 => mach-imx}/mach-mxt_td60.c (86%)
rename arch/arm/{mach-mx2 => mach-imx}/mach-pca100.c (93%)
rename arch/arm/{mach-mx2 => mach-imx}/mach-pcm038.c (91%)
rename arch/arm/{mach-mx1 => mach-imx}/mach-scb9328.c (89%)
rename arch/arm/{mach-mx1/generic.c => mach-imx/mm-imx1.c} (68%)
rename arch/arm/{mach-mx2 => mach-imx}/mm-imx21.c (95%)
rename arch/arm/{mach-mx2 => mach-imx}/mm-imx27.c (95%)
rename arch/arm/{mach-mx1/ksym_mx1.c => mach-imx/mx1-camera-fiq-ksym.c} (100%)
rename arch/arm/{mach-mx1/mx1_camera_fiq.S => mach-imx/mx1-camera-fiq.S} (100%)
rename arch/arm/{mach-mx2 => mach-imx}/pcm970-baseboard.c (100%)
delete mode 100644 arch/arm/mach-mx1/Kconfig
delete mode 100644 arch/arm/mach-mx1/Makefile
delete mode 100644 arch/arm/mach-mx1/Makefile.boot
delete mode 100644 arch/arm/mach-mx1/crm_regs.h
delete mode 100644 arch/arm/mach-mx1/devices.c
delete mode 100644 arch/arm/mach-mx1/devices.h
delete mode 100644 arch/arm/mach-mx2/Kconfig
delete mode 100644 arch/arm/mach-mx2/serial.c
create mode 100644 arch/arm/mach-mx25/devices-imx25.h
rename arch/arm/mach-mx25/{mach-mx25pdk.c => mach-mx25_3ds.c} (91%)
create mode 100644 arch/arm/mach-mx3/devices-imx31.h
create mode 100644 arch/arm/mach-mx3/devices-imx35.h
rename arch/arm/mach-mx3/{mach-mx35pdk.c => mach-mx35_3ds.c} (89%)
create mode 100644 arch/arm/plat-mxc/devices/Kconfig
create mode 100644 arch/arm/plat-mxc/devices/Makefile
create mode 100644 arch/arm/plat-mxc/devices/platform-imx-i2c.c
create mode 100644 arch/arm/plat-mxc/devices/platform-imx-uart.c
create mode 100644 arch/arm/plat-mxc/devices/platform-mxc_nand.c
create mode 100644 arch/arm/plat-mxc/devices/platform-spi_imx.c
delete mode 100644 arch/arm/plat-mxc/include/mach/board-armadillo5x0.h
delete mode 100644 arch/arm/plat-mxc/include/mach/board-kzmarm11.h
delete mode 100644 arch/arm/plat-mxc/include/mach/board-mx21ads.h
delete mode 100644 arch/arm/plat-mxc/include/mach/board-mx27ads.h
delete mode 100644 arch/arm/plat-mxc/include/mach/board-mx27lite.h
delete mode 100644 arch/arm/plat-mxc/include/mach/board-mx27pdk.h
delete mode 100644 arch/arm/plat-mxc/include/mach/board-mx31_3ds.h
delete mode 100644 arch/arm/plat-mxc/include/mach/board-mx31ads.h
delete mode 100644 arch/arm/plat-mxc/include/mach/board-mx35pdk.h
delete mode 100644 arch/arm/plat-mxc/include/mach/board-pcm037.h
delete mode 100644 arch/arm/plat-mxc/include/mach/board-pcm043.h
delete mode 100644 arch/arm/plat-mxc/include/mach/board-qong.h
create mode 100644 arch/arm/plat-mxc/include/mach/devices-common.h
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2010-06-07 17:58 Dave Hylands
0 siblings, 0 replies; 732+ messages in thread
From: Dave Hylands @ 2010-06-07 17:58 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
I'm trying to understand what I need to be concerned about with SMP
processors and sharing global data (in particular a dual Cortex-A9)
I'm familiar with spinlocks, but in this case I'm trying to work with
some lockless data structures.
What I'm not sure is whether the following would work. Suppose I have
a couple of 8-bit get/put indicies which are in adjacent memory
locations (within the same 32-bit word).
If I have an ISR and a thread running on an SMP core, and the ISR is
running on one core and the thread is running on a second core, if the
ISR were to only write to the put pointer and the thread were only to
write to the get pointer, does the cache maintain consistency? Or do
the get and put pointers need to be in separate cache lines?
Another way of asking this: If both cores are writing to the same
32-bit word (but different bytes) do the writes collide?
--
Dave Hylands
Shuswap, BC, Canada
http://www.DaveHylands.com/
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2010-05-18 10:38 Marek Szyprowski
0 siblings, 0 replies; 732+ messages in thread
From: Marek Szyprowski @ 2010-05-18 10:38 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
This patch series perform a general cleanup in Samsung S5PC100 SoC support.
This chip is moved from custom s5pc1xx platform framework to new plat-s5p
framework, so more common code can be easily reused in upcomming extensions
for S5PV210/S5PC110 SoCs.
This patch series is prepared against next-samsung tree, with assumption
that the "[PATCH v3] ARM: S5PC100: Pre-requisite clock patch for
plat-s5pc1xx to plat-s5p" has been applied as well as the '[PATCH v6]
ARM: S5PV210: Add Ext interrupt support' (with additional bug fixes).
I've tried to split my changes as much as possible to clearly show how the
transition from plat-s5pc1xx to plat-s5p is being done.
Changes since v2:
- fixed some whitespace/tabs errors
- removed external interrupt code, a common code from plat-s5p will be used
- moved SMDKC100 fixes to separate patch series
Changes since v1:
- bases on completely new clock code provided by Kukjin Kim
- added some plat-s5p fixes required for transition
- removed custom functions from gpiolib implementation (now uses common
code from plat-samsung)
- restructured the changes to avoid breaking the functionality beteen the
patches
- some other minor cleanups (mainly c1xx to c100 renames)
This patch series includes:
[PATCH 01/11] drivers: serial: S5PC100 serial driver cleanup
[PATCH 02/11] ARM: S5PC100: Use common functions for gpiolib implementation
[PATCH 03/11] ARM: S5PC100: Move gpio support from plat-s5pc1xx to mach-s5pc100
[PATCH 04/11] ARM: S5PC100: gpio.h cleanup
[PATCH 05/11] ARM: S5PC100: Move frame buffer helpers from plat-s5pc1xx to mach-s5pc100
[PATCH 06/11] ARM: S5PC100: Move i2c helpers from plat-s5pc1xx to mach-s5pc100
[PATCH 07/11] ARM: S5PC100: Move sdhci helpers from plat-s5pc1xx to mach-s5pc100
[PATCH 08/11] ARM: Samsung: move S5PC100 support from plat-s5pc1xx to plat-s5p framework
[PATCH 09/11] ARM: S5PC100: Add support for gpio interrupt
[PATCH 10/11] ARM: S5PC100: use common plat-s5p external interrupt code
[PATCH 11/11] ARM: remove obsolete plat-s5pc1xx directory
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2010-04-17 21:43 nelakurthi koteswararao
0 siblings, 0 replies; 732+ messages in thread
From: nelakurthi koteswararao @ 2010-04-17 21:43 UTC (permalink / raw)
To: linux-arm-kernel
http://ColleenKitts2530.co.cc
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2010-03-25 17:02 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2010-03-25 17:02 UTC (permalink / raw)
To: ath9k-devel
the production level yet, although my chipset is AR9160.
One issue is after a long time running the traffic maybe stopped
occasionally. Another one is it seems have some compatibility issue
with Intel chipset. They have troubled me a lot.
-Daniel
2010/5/6 Alan <lameventanas@gmail.com>:
> Can anybody give me a status report on the current state of ath9k?
> I know the one shipped with kernel 2.6.33.2 is working without major
> issues with 802.11g because I'm using it.
> But what is the status of 802.11n?
> What is the status of multiple ssids? Can I configure more than one in
> master mode?
>
> I'm asking because I'm about to set up an AP to be considered
> production level, and having 802.11n and two ssids (one open for
> guests, one encrypted for intended users) would be great.
> Should I stick to the version provided with the current kernel or
> should I use compat-wireless?
> Should I wait for the next kernel to be released with a major
> breakthrough in ath9k? (judging by the mailing list activity, it seems
> so).
> Hardware is AR5008 (dual band, 3 antennas).
>
> Thanks a lot!
>
> Alan
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2010-03-25 17:02 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2010-03-25 17:02 UTC (permalink / raw)
To: ath9k-devel
different behaviour and if the ls and error message were done on the same
machine the file is actually there.
I have not read the code, so I am more speculating, but could some other error
in the firmware loading be falsely evaluated as fw not found?
-Stefan
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2010-02-25 9:36 Thomas Weber
0 siblings, 0 replies; 732+ messages in thread
From: Thomas Weber @ 2010-02-25 9:36 UTC (permalink / raw)
To: linux-arm-kernel
Subject: [PATCH/RFC] OMAP2: serial.c: Fix number of uarts in early_init
The omap_serial_early_init prints the following errors:
Could not get uart4_ick
Could not get uart4_fck
because all the uarts available in omap_uart[] will be initialized.
Only omap4430 and omap3630 have 4 uarts at the moment.
This patch reduces the number of uarts when cpu is not omap4430 or
omap3630.
Signed-off-by: Thomas Weber <weber@corscience.de>
---
arch/arm/mach-omap2/serial.c | 15 ++++++++++-----
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index b79bc89..da77930 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -644,16 +644,21 @@ static void serial_out_override(struct uart_port *up, int offset, int value)
}
void __init omap_serial_early_init(void)
{
- int i;
+ int i, nr_ports;
char name[16];
+ if (!(cpu_is_omap3630() || cpu_is_omap4430()))
+ nr_ports = 3;
+ else
+ nr_ports = ARRAY_SIZE(omap_uart);
+
/*
* Make sure the serial ports are muxed on at this point.
* You have to mux them off in device drivers later on
* if not needed.
*/
- for (i = 0; i < ARRAY_SIZE(omap_uart); i++) {
+ for (i = 0; i < nr_ports; i++) {
struct omap_uart_state *uart = &omap_uart[i];
struct platform_device *pdev = &uart->pdev;
struct device *dev = &pdev->dev;
@@ -669,17 +674,17 @@ void __init omap_serial_early_init(void)
continue;
}
- sprintf(name, "uart%d_ick", i+1);
+ sprintf(name, "uart%d_ick", i + 1);
uart->ick = clk_get(NULL, name);
if (IS_ERR(uart->ick)) {
- printk(KERN_ERR "Could not get uart%d_ick\n", i+1);
+ printk(KERN_ERR "Could not get uart%d_ick\n", i + 1);
uart->ick = NULL;
}
sprintf(name, "uart%d_fck", i+1);
uart->fck = clk_get(NULL, name);
if (IS_ERR(uart->fck)) {
- printk(KERN_ERR "Could not get uart%d_fck\n", i+1);
+ printk(KERN_ERR "Could not get uart%d_fck\n", i + 1);
uart->fck = NULL;
}
--
1.6.4.4
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2009-11-19 13:58 Vimal Singh
0 siblings, 0 replies; 732+ messages in thread
From: Vimal Singh @ 2009-11-19 13:58 UTC (permalink / raw)
To: linux-mtd
This patch series adds flash support for NAND (in sdp, zoom and ldp),
OneNAND and NOR (in sdp)
Tested on Zoom2 and 3430SDP
Vimal Singh (4):
[PATCH-v6 1/4] OMAP2/3: Add support for flash on SDP boards
[PATCH-v6 2/4] OMAP3: Add support for NAND on ZOOM/LDP boards
[PATCH-v6 3/4] OMAP: Zoom2: Enable NAND and JFFS2 support in defconfig
[PATCH-v6 4/4] OMAP: 3430SDP: Enable NAND in defconfig
v6 :
1. Implemented Tony's comments on below threads:
[PATCH-v5 1/4] OMAP2/3: Add support for flash on SDP boards
http://marc.info/?l=linux-omap&m=125805845217778&w=2
[PATCH-v5 2/4] OMAP3: Add support for NAND on ZOOM2/LDP boards
http://marc.info/?l=linux-omap&m=125805867318269&w=2
[PATCH 2/3]NAND: OMAP: Fixing omap nand driver, compiled as module
http://marc.info/?l=linux-omap&m=125787938923028&w=2
2. Creating 'mach-omap2/gpmc-nand.c' to handle GPMC related setups for
the driver.
3. Removed all 'gpmc_cs_read_reg' and 'gpmc_cs_write_reg' calls from
'nand/omap2.c'
4. Corrected macro 'GPMC_CONFIG1_DEVICETYPE_NAND' for NAND
5. Removed 'nand unlock' routine in patch 2/4, will take this
discussion to mtd list.
v4-v5:
[PATCH-v5 1/4] OMAP2/3: Add support for flash on SDP boards:
Implemented Tony's comments.
--
Regards,
Vimal Singh
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-09-17 9:37 Marc Kleine-Budde
0 siblings, 0 replies; 732+ messages in thread
From: Marc Kleine-Budde @ 2009-09-17 9:37 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This patch series adds support for the Atmel CAN controller as found
on the AT91SAM9263.
It adds the at91_can to the generic device definition, activates the CAN
controller on the at91sam9263ek and adds the driver itself.
Changes since V1:
- let Kconfig depend on CAN_DEV
- add example how driver is used in baord file
Please review and consider for inclusion.
cheers, Marc
Marc Kleine-Budde (3):
at91sam9263: add at91_can device to generic device definition
at91sam9263ek: activate at91 CAN controller
at91_can: add driver for Atmel's CAN controller on AT91SAM9263
arch/arm/mach-at91/at91sam9263_devices.c | 36 +
arch/arm/mach-at91/board-sam9263ek.c | 19 +
arch/arm/mach-at91/include/mach/board.h | 6 +
drivers/net/can/Kconfig | 6 +
drivers/net/can/Makefile | 1 +
drivers/net/can/at91_can.c | 1186 ++++++++++++++++++++++++++++++
6 files changed, 1254 insertions(+), 0 deletions(-)
create mode 100644 drivers/net/can/at91_can.c
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-09-07 14:07 Somshekar ChandrashekarKadam
0 siblings, 0 replies; 732+ messages in thread
From: Somshekar ChandrashekarKadam @ 2009-09-07 14:07 UTC (permalink / raw)
To: linux-arm-kernel
Hi Catalin Marinas,
I am working on ARM1176 Realview board.
Kernel stable arm 2.6.28
My first query
I think reboot command is not implemented. ?
Work done locally here.
Implemented reboot by setting 8th bit of SYS_RESETCTL (reset control register 0x10000040). It works fine when given command reboot.
Issue Faced
ASLA works fine when done hard poweroff and poweron. ALSA detected properly and works fine.When I do a soft reboot using reboot command. when kernel boots up it doesn't detect ALSA device itself with the
following messages. It is not able to read AC97 Register failing
because of timeout. I tried increasing the timeout and udelay still the
same case. Messages are shown below a the end.I also tried setting the various depth of a soft reset like
(1=SYSRST rest logic tile, 2=PLLLOCK reset PLL, 4=PBRESET board reset,
same as pressing reset button). still ALSA does not work.Now I am confused on this. Please throw some light on this or any pointer will be useful.It is not able to read AC97 Register failing
because of timeout. routine (/*
* Read an AC'97 register.
*/
static unsigned short aaci_ac97_read(struct snd_ac97 *ac97, unsigned short reg))
I hope i have made myself clear.
Thanks In Advance
Messages when ALSA not detected
====================================================
When sound doesn't work I see following in boot log:
Advanced Linux Sound Architecture Driver Version 1.0.18rc3.
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: wrong ac97 register read back (0 != 7c)
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: wrong ac97 register read back (0 != 7e)
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: wrong ac97 register read back (0 != 7c)
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: wrong ac97 register read back (0 != 7e)
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: wrong ac97 register read back (0 != 1c)
port 1 high speed
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: wrong ac97 register read back (0 != 7c)
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: wrong ac97 register read back (0 != 7e)
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: wrong ac97 register read back (0 != 1c)
usb 1-1: new high speed USB device using isp1760 and address 2
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: wrong ac97 register read back
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20090907/092b9ae9/attachment-0001.htm>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-08-25 10:34 Syed Rafiuddin
0 siblings, 0 replies; 732+ messages in thread
From: Syed Rafiuddin @ 2009-08-25 10:34 UTC (permalink / raw)
To: linux-arm-kernel
From: Syed Rafiuddin <rafiuddin.syed@ti.com>
This patch Adds Keypad support on OMAP4.And adds
OMAP4 register addresses and configures them for OMAP4.
This patch has been updated as per the comments received from
Trilok Soni to remove GPIO based omap2 keypad logic from omap_keypad.c
(http://www.mail-archive.com/linux-omap at vger.kernel.org/msg14570.html)
Matrix_keypad.c (gpio based keypad driver) can be used in OMAP2,
which is not tested on OMAP2 since unavailability of omap2 target's.
Signed-off-by: Syed Rafiuddin <rafiuddin.syed@ti.com>
---
drivers/input/keyboard/omap-keypad.c | 247 ++++++++++++++++-------------------
1 files changed, 115 insertions(+), 132 deletions(-)
Index: kernel-omap4-base/drivers/input/keyboard/omap-keypad.c
===================================================================
--- kernel-omap4-base.orig/drivers/input/keyboard/omap-keypad.c 2009-08-19 12:23:14.000000000 +0530
+++ kernel-omap4-base/drivers/input/keyboard/omap-keypad.c 2009-08-19 18:25:17.000000000 +0530
@@ -44,6 +44,36 @@
#undef NEW_BOARD_LEARNING_MODE
+#define OMAP4_KBDOCP_BASE 0x4A31C000
+#define OMAP4_KBD_REVISION 0x00
+#define OMAP4_KBD_SYSCONFIG 0x10
+#define OMAP4_KBD_SYSSTATUS 0x14
+#define OMAP4_KBD_IRQSTATUS 0x18
+#define OMAP4_KBD_IRQENABLE 0x1C
+#define OMAP4_KBD_WAKEUPENABLE 0x20
+#define OMAP4_KBD_PENDING 0x24
+#define OMAP4_KBD_CTRL 0x28
+#define OMAP4_KBD_DEBOUNCINGTIME 0x2C
+#define OMAP4_KBD_LONGKEYTIME 0x30
+#define OMAP4_KBD_TIMEOUT 0x34
+#define OMAP4_KBD_STATEMACHINE 0x38
+#define OMAP4_KBD_ROWINPUTS 0x3C
+#define OMAP4_KBD_COLUMNOUTPUTS 0x40
+#define OMAP4_KBD_FULLCODE31_0 0x44
+#define OMAP4_KBD_FULLCODE63_32 0x48
+
+#define OMAP4_KBD_SYSCONFIG_SOFTRST (1 << 1)
+#define OMAP4_KBD_SYSCONFIG_ENAWKUP (1 << 2)
+#define OMAP4_KBD_IRQENABLE_EVENTEN (1 << 0)
+#define OMAP4_KBD_IRQENABLE_LONGKEY (1 << 1)
+#define OMAP4_KBD_IRQENABLE_TIMEOUTEN (1 << 2)
+#define OMAP4_KBD_CTRL_NOSOFTMODE (1 << 1)
+#define OMAP4_KBD_CTRLPTVVALUE (1 << 2)
+#define OMAP4_KBD_CTRLPTV (1 << 1)
+#define OMAP4_KBD_IRQDISABLE 0x00
+
+#define OMAP4_KBD_IRQSTATUSDISABLE 0xffff
+
static void omap_kp_tasklet(unsigned long);
static void omap_kp_timer(unsigned long);
@@ -65,55 +95,16 @@ struct omap_kp {
static DECLARE_TASKLET_DISABLED(kp_tasklet, omap_kp_tasklet, 0);
static int *keymap;
-static unsigned int *row_gpios;
-static unsigned int *col_gpios;
-
-#ifdef CONFIG_ARCH_OMAP2
-static void set_col_gpio_val(struct omap_kp *omap_kp, u8 value)
-{
- int col;
-
- for (col = 0; col < omap_kp->cols; col++)
- gpio_set_value(col_gpios[col], value & (1 << col));
-}
-
-static u8 get_row_gpio_val(struct omap_kp *omap_kp)
-{
- int row;
- u8 value = 0;
-
- for (row = 0; row < omap_kp->rows; row++) {
- if (gpio_get_value(row_gpios[row]))
- value |= (1 << row);
- }
- return value;
-}
-#else
-#define set_col_gpio_val(x, y) do {} while (0)
-#define get_row_gpio_val(x) 0
-#endif
static irqreturn_t omap_kp_interrupt(int irq, void *dev_id)
{
- struct omap_kp *omap_kp = dev_id;
+ if (cpu_is_omap44xx()) {
+ /* disable keyboard interrupt and schedule for handling */
+ omap_writel(OMAP4_KBD_IRQDISABLE, OMAP4_KBDOCP_BASE +
+ OMAP4_KBD_IRQENABLE);
- /* disable keyboard interrupt and schedule for handling */
- if (cpu_is_omap24xx()) {
- int i;
-
- for (i = 0; i < omap_kp->rows; i++) {
- int gpio_irq = gpio_to_irq(row_gpios[i]);
- /*
- * The interrupt which we're currently handling should
- * be disabled _nosync() to avoid deadlocks waiting
- * for this handler to complete. All others should
- * be disabled the regular way for SMP safety.
- */
- if (gpio_irq == irq)
- disable_irq_nosync(gpio_irq);
- else
- disable_irq(gpio_irq);
- }
+ omap_writel(omap_readl(OMAP4_KBDOCP_BASE + OMAP4_KBD_IRQSTATUS),
+ OMAP4_KBDOCP_BASE + OMAP4_KBD_IRQSTATUS);
} else
/* disable keyboard interrupt and schedule for handling */
omap_writew(1, OMAP_MPUIO_BASE + OMAP_MPUIO_KBD_MASKIT);
@@ -132,14 +123,13 @@ static void omap_kp_scan_keypad(struct o
{
int col = 0;
+ u32 *p = (u32 *) state;
/* read the keypad status */
- if (cpu_is_omap24xx()) {
- /* read the keypad status */
- for (col = 0; col < omap_kp->cols; col++) {
- set_col_gpio_val(omap_kp, ~(1 << col));
- state[col] = ~(get_row_gpio_val(omap_kp)) & 0xff;
- }
- set_col_gpio_val(omap_kp, 0);
+ if (cpu_is_omap44xx()) {
+
+ *p = omap_readl(OMAP4_KBDOCP_BASE + OMAP4_KBD_FULLCODE31_0);
+ *(p + 1) = omap_readl(OMAP4_KBDOCP_BASE +
+ OMAP4_KBD_FULLCODE63_32);
} else {
/* disable keyboard interrupt and schedule for handling */
@@ -198,7 +188,13 @@ static void omap_kp_tasklet(unsigned lon
row, (new_state[col] & (1 << row)) ?
"pressed" : "released");
#else
- key = omap_kp_find_key(col, row);
+
+ /* Keymappings have changed in omap4.*/
+ if (cpu_is_omap44xx())
+ key = omap_kp_find_key(row, col);
+ else
+ key = omap_kp_find_key(col, row);
+
if (key < 0) {
printk(KERN_WARNING
"omap-keypad: Spurious key event %d-%d\n",
@@ -213,8 +209,16 @@ static void omap_kp_tasklet(unsigned lon
continue;
kp_cur_group = key & GROUP_MASK;
- input_report_key(omap_kp_data->input, key & ~GROUP_MASK,
- new_state[col] & (1 << row));
+
+ if (cpu_is_omap44xx())
+ input_report_key(omap_kp_data->input,
+ key & ~GROUP_MASK, new_state[row]
+ & (1 << col));
+ else
+ input_report_key(omap_kp_data->input,
+ key & ~GROUP_MASK, new_state[col]
+ & (1 << row));
+
#endif
}
}
@@ -229,14 +233,18 @@ static void omap_kp_tasklet(unsigned lon
mod_timer(&omap_kp_data->timer, jiffies + delay);
} else {
/* enable interrupts */
- if (cpu_is_omap24xx()) {
- int i;
- for (i = 0; i < omap_kp_data->rows; i++)
- enable_irq(gpio_to_irq(row_gpios[i]));
- } else {
- omap_writew(0, OMAP_MPUIO_BASE + OMAP_MPUIO_KBD_MASKIT);
+ if (cpu_is_omap44xx()) {
+ omap_writew(OMAP4_KBD_IRQENABLE_EVENTEN |
+ OMAP4_KBD_IRQENABLE_LONGKEY,
+ OMAP4_KBDOCP_BASE +
+ OMAP4_KBD_IRQENABLE);
kp_cur_group = -1;
- }
+ } else {
+ omap_writew(0, OMAP_MPUIO_BASE +
+ OMAP_MPUIO_KBD_MASKIT);
+ kp_cur_group = -1;
+ }
+
}
}
@@ -296,7 +304,7 @@ static int __devinit omap_kp_probe(struc
struct omap_kp *omap_kp;
struct input_dev *input_dev;
struct omap_kp_platform_data *pdata = pdev->dev.platform_data;
- int i, col_idx, row_idx, irq_idx, ret;
+ int i, col_idx, row_idx, ret;
if (!pdata->rows || !pdata->cols || !pdata->keymap) {
printk(KERN_ERR "No rows, cols or keymap from pdata\n");
@@ -316,7 +324,7 @@ static int __devinit omap_kp_probe(struc
omap_kp->input = input_dev;
/* Disable the interrupt for the MPUIO keyboard */
- if (!cpu_is_omap24xx())
+ if (!cpu_is_omap44xx())
omap_writew(1, OMAP_MPUIO_BASE + OMAP_MPUIO_KBD_MASKIT);
keymap = pdata->keymap;
@@ -327,39 +335,11 @@ static int __devinit omap_kp_probe(struc
if (pdata->delay)
omap_kp->delay = pdata->delay;
- if (pdata->row_gpios && pdata->col_gpios) {
- row_gpios = pdata->row_gpios;
- col_gpios = pdata->col_gpios;
- }
-
omap_kp->rows = pdata->rows;
omap_kp->cols = pdata->cols;
- if (cpu_is_omap24xx()) {
- /* Cols: outputs */
- for (col_idx = 0; col_idx < omap_kp->cols; col_idx++) {
- if (gpio_request(col_gpios[col_idx], "omap_kp_col") < 0) {
- printk(KERN_ERR "Failed to request"
- "GPIO%d for keypad\n",
- col_gpios[col_idx]);
- goto err1;
- }
- gpio_direction_output(col_gpios[col_idx], 0);
- }
- /* Rows: inputs */
- for (row_idx = 0; row_idx < omap_kp->rows; row_idx++) {
- if (gpio_request(row_gpios[row_idx], "omap_kp_row") < 0) {
- printk(KERN_ERR "Failed to request"
- "GPIO%d for keypad\n",
- row_gpios[row_idx]);
- goto err2;
- }
- gpio_direction_input(row_gpios[row_idx]);
- }
- } else {
- col_idx = 0;
- row_idx = 0;
- }
+ col_idx = 0;
+ row_idx = 0;
setup_timer(&omap_kp->timer, omap_kp_timer, (unsigned long)omap_kp);
@@ -369,7 +349,7 @@ static int __devinit omap_kp_probe(struc
ret = device_create_file(&pdev->dev, &dev_attr_enable);
if (ret < 0)
- goto err2;
+ goto err1;
/* setup input device */
__set_bit(EV_KEY, input_dev->evbit);
@@ -387,47 +367,54 @@ static int __devinit omap_kp_probe(struc
ret = input_register_device(omap_kp->input);
if (ret < 0) {
printk(KERN_ERR "Unable to register omap-keypad input device\n");
- goto err3;
+ goto err2;
}
- if (pdata->dbounce)
- omap_writew(0xff, OMAP_MPUIO_BASE + OMAP_MPUIO_GPIO_DEBOUNCING);
+ if (pdata->dbounce) {
+ if (cpu_is_omap44xx())
+ omap_writew(0xff, OMAP_MPUIO_BASE +
+ OMAP4_KBD_DEBOUNCINGTIME);
+ else
+ omap_writew(0xff, OMAP_MPUIO_BASE +
+ OMAP_MPUIO_GPIO_DEBOUNCING);
+ }
/* scan current status and enable interrupt */
omap_kp_scan_keypad(omap_kp, keypad_state);
- if (!cpu_is_omap24xx()) {
- omap_kp->irq = platform_get_irq(pdev, 0);
- if (omap_kp->irq >= 0) {
- if (request_irq(omap_kp->irq, omap_kp_interrupt, 0,
- "omap-keypad", omap_kp) < 0)
- goto err4;
- }
+
+ /* Configuring OMAP4 keypad registers */
+ if (cpu_is_omap44xx()) {
+ omap_writew(OMAP4_KBD_SYSCONFIG_SOFTRST |
+ OMAP4_KBD_SYSCONFIG_ENAWKUP, OMAP4_KBDOCP_BASE
+ + OMAP4_KBD_SYSCONFIG);
+ omap_writew((OMAP4_KBD_CTRLPTVVALUE << OMAP4_KBD_CTRLPTV) |
+ OMAP4_KBD_CTRL_NOSOFTMODE,
+ OMAP4_KBDOCP_BASE + OMAP4_KBD_CTRL);
+ }
+
+ omap_kp->irq = platform_get_irq(pdev, 0);
+
+ if (omap_kp->irq >= 0) {
+ if (request_irq(omap_kp->irq, omap_kp_interrupt, 0,
+ "omap-keypad", omap_kp) < 0)
+ goto err3;
+ }
+
+ if (!cpu_is_omap44xx())
omap_writew(0, OMAP_MPUIO_BASE + OMAP_MPUIO_KBD_MASKIT);
- } else {
- for (irq_idx = 0; irq_idx < omap_kp->rows; irq_idx++) {
- if (request_irq(gpio_to_irq(row_gpios[irq_idx]),
- omap_kp_interrupt,
- IRQF_TRIGGER_FALLING,
- "omap-keypad", omap_kp) < 0)
- goto err5;
- }
+
+ if (cpu_is_omap44xx()) {
+ omap_writew(OMAP4_KBD_IRQENABLE_EVENTEN |
+ OMAP4_KBD_IRQENABLE_LONGKEY, OMAP4_KBDOCP_BASE +
+ OMAP4_KBD_IRQENABLE);
}
return 0;
-err5:
- for (i = irq_idx - 1; i >=0; i--)
- free_irq(row_gpios[i], 0);
-err4:
+err3:
input_unregister_device(omap_kp->input);
input_dev = NULL;
-err3:
- device_remove_file(&pdev->dev, &dev_attr_enable);
err2:
- for (i = row_idx - 1; i >=0; i--)
- gpio_free(row_gpios[i]);
+ device_remove_file(&pdev->dev, &dev_attr_enable);
err1:
- for (i = col_idx - 1; i >=0; i--)
- gpio_free(col_gpios[i]);
-
kfree(omap_kp);
input_free_device(input_dev);
@@ -440,14 +427,10 @@ static int __devexit omap_kp_remove(stru
/* disable keypad interrupt handling */
tasklet_disable(&kp_tasklet);
- if (cpu_is_omap24xx()) {
- int i;
- for (i = 0; i < omap_kp->cols; i++)
- gpio_free(col_gpios[i]);
- for (i = 0; i < omap_kp->rows; i++) {
- gpio_free(row_gpios[i]);
- free_irq(gpio_to_irq(row_gpios[i]), 0);
- }
+ if (cpu_is_omap44xx()) {
+ omap_writel(OMAP4_KBD_IRQDISABLE, OMAP4_KBDOCP_BASE +
+ OMAP4_KBD_IRQENABLE);
+ free_irq(omap_kp->irq, 0);
} else {
omap_writew(1, OMAP_MPUIO_BASE + OMAP_MPUIO_KBD_MASKIT);
free_irq(omap_kp->irq, 0);
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-02-27 19:01 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-02-27 19:01 UTC (permalink / raw)
To: ath9k-devel
wlan0: STA 00:23:4d:b7:98:e8 IEEE 802.11: authenticated
MGMT
mgmt::assoc_req
association request: STA=00:23:4d:b7:98:e8 capab_info=0x431 listen_interval=10
handle_assoc STA 00:23:4d:b7:98:e8 - no HT, num of non-HT stations 1
hostapd_ht_operation_update current operation mode=0x0
hostapd_ht_operation_update new operation mode=0x13 changes=2
new AID 1
wlan0: STA 00:23:4d:b7:98:e8 IEEE 802.11: association OK (aid 1)
This is weird, since it chooses non-HT mode for the STA.
Am not sure why this is happening. Are you running the latest git
code for all 3 cases ?
* hostapd
* ath9k - AP side
* ath9k - STA side
Also, can you paste your hostapd.conf and wpa_supplicant's configuration file here ?
Sujith
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-02-27 19:01 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-02-27 19:01 UTC (permalink / raw)
To: ath9k-devel
required. You can think of my previous phrase as possible feature
request, or a question of "how to?" type. I know that borh SLI nvidia
cards are sharing IRQ 16 as well as atheros based dlink wireless card.
(if it's not difficult, please look into my previous emails, they will
have dmesg and lspci -vv details, otherwise just ask me for more
details, i shall provide them)
>> Obviously, there is not much point of asking Nvidia to do it, since
>> those behemoth's won't do anything for sure, since their current driver
>> (i dont use it for that matter)release is pretty banged up...
>>
>
> If you do most of the work finding how to work around the problem, and
> it turns out that something could be improved in free software, then
> maybe your patch will be applied.
>
> If you expect others to question you about the symptoms, then suggest
> patches and push them to the kernel, that's not going to happen.
>
Symptoms are simple with nvidia module and ath9k loaded at the same time
connection degrades over short period of time and after several minutes
disappears all together. I suspect it could be IRQ sharing or other I/O
or similar hardware conflict, since both of them work pretty well while
other devices driver is not loaded. no unusual messages in dmesg.
Machine may hang and even if in terminal(not in X), machine hangs
completely without providing a bit of information, not even oops message.
>
>> Another question, my Access Point and PCI wifi card are from same
>> manufacturer. AP is set to B,G,N auto mode, but my card only connects to
>> it using G mode, which is not why i bought it in the first place. Why is
>> this happening? i am pretty much only user to network myself 99% of
>> time. i tried to force it to use N mode, it could detect it, but it
>> couldn't connect.
>>
>
> I suggest that you actually show what commands you run and what they
> return, not just your interpretation.
>
> In case you are hitting the stuck scan bug, try setting the channel with
> iwconfig instead of loading and unloading modules.
>
>
Commands are simple as well.
ip link set wlan0 up
iwconfig wlan0 essid dlink
they don't give any errors and don't show any unusual messages in dmesg
thats pretty much it. (no wireless security used at all)
N.B.
What i really don't want is any kind of aggression towards to me.
Coding something for a community, even advanced one requires certain
amount of tolerance, as ANY normal communication.
I am not perfect tester(i just attempt to become better one), i
understand that, but i am not coming after difficult day, working with
difficult people to submit difficult issues(which other people may
prefer to ignore all together or for those reasons abandon Linux and go
to MS products, i have seeing enough of those). I am not going to become
more enthusiastic by being referred to "RTFM noob" like documents, who
nearly imply my stupidity.
So far I was very happy in this list, and even my lack of technical
knowledge did not spoil my attitude towards this list. I want it to stay
that way. Ignoring problems of people who lack technical knowledge on
matter is path to nowhere. I seriously, don't want to start flame wars,
i am not naive and I don't ask for apologies. I just ask one thing,
please be tolerant, everyone can have a shi*** day, that includes you
and me!
Dmitri
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-02-27 19:01 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-02-27 19:01 UTC (permalink / raw)
To: ath9k-devel
rev. 2.1 now), a single function device may _only_ provide an interrupt
request on pin A and no others. Pins B-D only have meaning for multi-
function devices.
> > There seems to be some kind of race. If I have both the AR5416 and
> > HPT371N, loaded, and after the board has booted(everything is
> > configured), the "IRQ X Nobody cared" never occurs. If i remove
> > AR5416 mini-pci, I also never get the "IRQ X Nobody cared".
>
> You would have to investigate a) which chip generates the bogus IRQ,
> and b) how to clear it. Then you can clear the IRQ in the platform code,
> or using a PCI quirk code if it's not related to the platform.
It sounds to me like the driver is prodding the chip, and it's generating
an interrupt but the driver hasn't yet registered its handler. If so,
that's really a driver bug needing to be fixed.
Normally you get a backtrace when a "nobody cared" message is issued -
this should tell you which driver is probably the cause.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-02-27 19:01 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-02-27 19:01 UTC (permalink / raw)
To: ath9k-devel
(usually link quality warries between 60-70)
Machine started to suffer with disconnects.
Below is fuller log.
1249488753.366831: wlan0 (phy #0): deauth 00:22:b0:bc:1e:1e ->
00:1e:58:b4:f6:83 reason 4: Disassociated due to inactivity
1249488753.366985: wlan0 (phy #0): disconnected (local request)
1249488848.660029: wlan0 (phy #0): auth 00:1e:58:b4:f6:83 ->
00:22:b0:bc:1e:1e status: 0: Successful
1249488848.668387: wlan0 (phy #0): assoc 00:1e:58:b4:f6:83 ->
00:22:b0:bc:1e:1e status: 0: Successful
1249488848.668489: wlan0 (phy #0): connected to 00:1e:58:b4:f6:83
1249488918.365949: wlan0 (phy #0): deauth 00:22:b0:bc:1e:1e ->
00:1e:58:b4:f6:83 reason 4: Disassociated due to inactivity
1249488918.365996: wlan0 (phy #0): disconnected (local request)
1249489968.542997: wlan0 (phy #0): auth 00:1e:58:b4:f6:83 ->
00:22:b0:bc:1e:1e status: 0: Successful
1249489968.551472: wlan0 (phy #0): assoc 00:1e:58:b4:f6:83 ->
00:22:b0:bc:1e:1e status: 0: Successful
1249489968.551576: wlan0 (phy #0): connected to 00:1e:58:b4:f6:83
1249489985.366774: wlan0 (phy #0): deauth 00:22:b0:bc:1e:1e ->
00:1e:58:b4:f6:83 reason 4: Disassociated due to inactivity
1249489985.366850: wlan0 (phy #0): disconnected (local request)
1249490017.023313: wlan0 (phy #0): auth 00:1e:58:b4:f6:83 ->
00:22:b0:bc:1e:1e status: 0: Successful
1249490017.031578: wlan0 (phy #0): assoc 00:1e:58:b4:f6:83 ->
00:22:b0:bc:1e:1e status: 0: Successful
1249490017.031616: wlan0 (phy #0): connected to 00:1e:58:b4:f6:83
1249490039.365052: wlan0 (phy #0): deauth 00:22:b0:bc:1e:1e ->
00:1e:58:b4:f6:83 reason 4: Disassociated due to inactivity
1249490039.365096: wlan0 (phy #0): disconnected (local request)
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-02-27 19:01 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-02-27 19:01 UTC (permalink / raw)
To: ath9k-devel
// ?? nice pointer arithmetic... should use PTR_ALIGN here?
off = ((unsigned long) skb->data) % sc->cachelsz;
if (off != 0)
skb_reserve(skb, sc->cachelsz);
in other words, when we allocate, round up to the next cache line
greater than IEEE80211_MAX_LEN, then add an extra cache_line-1
bytes so we can map starting from it.
dev_alloc_skb already does some padding and alignment, and it's
configurable on a per-arch basis (though looks like only powerpc
sets it to L1 cache size, everywhere else it's 32 bytes.)
I guess if someone is bored some benchmarking would be useful.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-02-27 19:01 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-02-27 19:01 UTC (permalink / raw)
To: ath9k-devel
is=20
yet, but I wonder if anyone else has solved this with a vendor extension?
--=20
Tim Smith <Tim.Smith@csr.com>
Member of the CSR plc group of companies. CSR plc registered in England and=
Wales, registered number 4187346, registered office Churchill House, Cambr=
idge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-02-27 19:01 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-02-27 19:01 UTC (permalink / raw)
To: ath9k-devel
should be automagically functional on the kernel I'm on, assuming the
hardware is compatible?
So that's where I stand now. I'm probably not asking the right
questions or providing enough information - please let me know any
tests you'd like me to run or further information I can give.
Thanks!
Andrew
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-02-15 8:49 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-02-15 8:49 UTC (permalink / raw)
To: ath9k-devel
am not sure if this is related to AP mode in ath9k.
Sujith
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
headers), the structs should be declared explicitly as __packed__. The
correctness of the object code should be independent from the compiler
optimizations and we should always remember that the offset of a
struct field is not necessarily the sum of the sizes of the fields
that precede it.
struct {
type1 a;
type2 b;
type3 c;
} mystruct
offset(mystruct.c) != sizeof(type1) + sizeof(type2).
Regarding the CFLAGS used by me... I haven't set any CFLAGS and I just
do a make qemu_mips_config CROSS_COMPILE=mips-linux- && make
CROSS_COMPILE=mips-linux... and a boundary alignment is not an alien
choice for a good compiler (a standard gcc4.2.4 in my case).
Furthermore I expect a correct object always... with any -Ox flag (a
apart bugs... of course).
My idea should be to declare a define like this
#define PKT_HEADER __attribute__((__packed__))
my 2EuroCents.
best regards,
luigi
2009/1/28 Ben Warren <biggerbadderben@gmail.com>:
> Jerry Van Baren wrote:
>>
>> Ben Warren wrote:
>>>
>>> Luigi 'Comio' Mantellini wrote:
>>>>
>>>> Hi ML,
>>>>
>>>> I'm working on a mips target and I used qemu_mips target to simulate my
>>>> target (that I hope to have in the next week...)
>>>>
>>>> Following my activities I noticed that IP_t structure is no defined with
>>>> attribute "packed". I noticed this issue because using a self-made toolchain
>>>> (gcc4.2.4+binutils2.8+uclibc0.9.30) the compiler has aligned all bytes to
>>>> 32bit boundary. This is not ok, because the packets IP_t can be non aligned
>>>> (see the /net/net.c PingSend function, for an example).
>>>>
>>>>
>>>
>>> Why is your compiler aligning all bytes to 32-bit boundary? Seems like
>>> an awful waste of space. This struct should pack itself nicely, and does on
>>> the small sample of toolchains I've tried (gcc 4.3.2 x86_64 and gcc 4.0.0
>>> ppc_4xx).
>>
>> The compiler is optimizing for speed and/or execution size at the expense
>> of larger data structures either by command (e.g. a -O option) or as part of
>> the compiler writer's choice. CPUs almost always execute code significantly
>> faster when the data is properly aligned. Many CPUs require software to
>> deal with the misalignment which costs code space and execution time.
>>
>> Since the compiler wasn't instructed that the IP headers needed to be
>> packed, it is within the compiler's right to not pack them.
>>
> Sure. In this case, though, the optimization's not necessarily going to
> gain anything since we never use a raw struct IP_t, only pointers that
> overlay other char arrays through casting. Of course there's no point
> discussing this much further here, but I suspect that this packing problem
> will exist in many more places than the protocol headers.
>>
>> [snip]
>>
>> Best regards,
>> gvb
>>
> regards,
> Ben
>
--
Luigi 'Comio' Mantellini
R&D - Software
Industrie Dial Face S.p.A.
Via Canzo, 4
20068 Peschiera Borromeo (MI), Italy
Tel.: +39 02 5167 2813
Fax: +39 02 5167 2459
web: www.idf-hit.com
mail: luigi.mantellini at idf-hit.com
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
with driver name. I mean if the config is CONFIG_PPC4xx_EMAC the filename should
be ppc4xx_emac.c or in second case CONFIG_4XX_ENET for current 4xx_enet.c file.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
>>
>>
>>> COBJS-$(CONFIG_BFIN_MAC) += bfin_mac.o
>>> @@ -54,11 +55,11 @@ COBJS-$(CONFIG_NS8382X) += ns8382x.o
>>> COBJS-$(CONFIG_DRIVER_NS9750_ETHERNET) += ns9750_eth.o
>>> COBJS-$(CONFIG_PCNET) += pcnet.o
>>> COBJS-$(CONFIG_PLB2800_ETHER) += plb2800_eth.o
>>> -COBJS-$(CONFIG_PPC4xx_EMAC) += 4xx_enet.o
>>>
>>
>> that was ok here.
>>
>>
>>> COBJS-$(CONFIG_DRIVER_RTL8019) += rtl8019.o
>>>
>>
>> ...while this isn't.
>>
>>
>>> COBJS-$(CONFIG_RTL8139) += rtl8139.o
>>> COBJS-$(CONFIG_RTL8169) += rtl8169.o
>>> COBJS-$(CONFIG_DRIVER_S3C4510_ETH) += s3c4510b_eth.o
>>> +COBJS-$(CONFIG_SH_ETHER) += sh_eth.o
>>> COBJS-$(CONFIG_DRIVER_SMC91111) += smc91111.o
>>> COBJS-$(CONFIG_DRIVER_SMC911X) += smc911x.o
>>> COBJS-$(CONFIG_TIGON3) += tigon3.o bcm570x_autoneg.o 5701rls.o
>>> @@ -68,7 +69,6 @@ COBJS-$(CONFIG_ULI526X) += uli526x.o
>>> COBJS-$(CONFIG_VSC7385_ENET) += vsc7385.o
>>> COBJS-$(CONFIG_XILINX_EMAC) += xilinx_emac.o
>>> COBJS-$(CONFIG_XILINX_EMACLITE) += xilinx_emaclite.o
>>> -COBJS-$(CONFIG_SH_ETHER) += sh_eth.o
>>>
>>
>> Actually we should perform a global s/CONFIG_DRIVER_/CONFIG_/, me
>> thinks.
>>
>>
> Agreed. Can you do it Michal, or should I (for net, anyway)?
I would like to describe what happen. I sent to mailing list two patches. One
with Makefile sort and second with LL_TEMAC. First patch just sort some labels
in drivers/net/Makefile. Wolfgang sent that he don't like it and he reject this
patch. I haven't wanted to sort any Makefile labels I just wanted to add
LL_TEMAC driver. Makefile sort was not my point.
Then Ben add only Makefile sort patch (because of some small drivers violations)
to net repo and send pull request to Wolfgang and he merged it to his repo.
My point was and is only add LL_TEMAC driver to u-boot not sorting labels in net
repo.
BEN: Could you please add that driver to your repo? and if you can please sort
labels to correct way.
Thanks,
Michal
>> Best regards,
>>
>> Wolfgang Denk
>>
>>
> regards,
> Ben
>
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
If you use from actual 2.6 Linux the drivers/i2c/algos/i2c-algo-bit.c
bitbang driver with gpio support (drivers/i2c/busses/i2c-gpio.c)
you get called your gpio_get/set_value (pin, state) function in your
board code (or gpio code)!
And in this function you have to switch dependent on the pin, and
then again to switch dependent on the state, before you can do
any action ... so tell me, where we are worser, when we making
#define I2C_SDA(bit) \
switch(cur_adap_nr->hw_adapnr) { \
case 0: \
if (bit) { \
/* set pin for adapter 0 = 1*/ \
} else { \
/* set pin for adapter 0 = 0*/ \
} \
[...] \
} \
} \
in board config file ... OK, we are worser against your approach, because
we have for all I2C_SDA, I2C_SCL accesses + 1 switch, but I don;t think
this is such a problem.
> That means that implementation is much worse than _EXISTING_ one. And out of
> decent and much worse one which one would you choose?
>
>>> The soft_i2c.c is _NOT_ a driver _SOURCE_. It is a _TEMPLATE_ that makes a
>> This is your implementation. It is not the only possible implemen-
>> tation. Please try and open your mind to discuss alternative
>> possibilities as well.
>
> No, it is NOT my implementation. It is _EXISTING_ driver in the main tree. I
> did _NOT_ change the driver, I just made several copies of it.
>
> And, BTW, you can see something very similar in Linux kernel
> (i2c-algo-bit.c.)
Please have a deeper look in it, see above comment.
> I'm open to any alternative possibilities but I can not see anything better.
> That _EXISTING_ soft_i2c.c we have in the current tree is a little miracle
> that was there since the start of times so I can't see any reason to throw
> it away and reinvent the wheel.
Nobody wants to throw it away!
>>> The former does not require additional adapter struct member, hwadap_no.
>>> And, unlike the latter, it is self-contained, it doesn't require any
>>> external global variable to decide what to do. One can initialize all
>>> adapters by:
>>>
>>> for (i = 0; i < NUM_I2C_ADAPTERS; i++)
>>> i2c_adap[i]->init(...);
>> Most probably we never *want* to initialize all adapters...
>
> It is easier that way and wouldn't do any harm in most cases...
But it is not needed when doing this in i2c_set_bus_num() !!
It is sufficent to init a hardwareadapter, when switching to it.
bye
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
t being the timeout value
and the second one being the function to be invoked when timeout expires.
The issue is now the NetSetTimeout() takes timeout in milliseconds only i.e=
the first parameter has
to be a count in milliseconds.
The NetSetTimeout() invokes get_timer() to do its operations. The get_timer=
() should return the
counter value. It's not always true that the counter runs at millisecond cl=
ock. I believe the earlier
versions of the NetSetTimeout calls in u-boot/net directory used to have a =
multiple of
CONFIG_SYS_HZ for timeout that could easily be used to get required timeout=
for different platforms.
Regards
Manikandan
--_000_19F8576C6E063C45BE387C64729E739403FA90441Bdbde02enttico_--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
enable RMII support for the uboot and it should detect the chip. Is this
correct? If it is how do we go about enabling RMII support for the device,
and is there anything else we need to do in order to get this chip supported
by the u-boot?
We compiled our version of u-boot by using the LTIB software that came with
the MPC8315E-RDB BSP which automatically generated our u-boot version.
Regards,
Louis
--0015174bdfecb27c53046435f7aa--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
other patch would have come earlier in the sequence. As is, it is
really difficult to see if the lines above are included in your other
patch, or if they might have been missed. Keep in mind that reviewing
is a sequential process...
But OK, from the end result it makes no difference.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Yes, it is written. Good shall always destroy evil.
-- Sirah the Yang, "The Omega Glory", stardate unknown
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
only used by apollon
that can be changed by Apollon users independently. we will
check othe rissue of white space and release patch.
Amit
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
boot on imx31 pdk. Please correct me if i am wrong.
I was told that if that the mx31 phycore patch should work just fine
for most things on the PDK and hence can be used as a base for a port
to the PDK.
I am ignorant of the hardware details on MX31 Phycore but when i had
a look at the low level init code (lowlevelinit.S) for Phycore and
compared it to the existing lowlevelinit.S for the MX31 3stack board,
i realized that they are a lot different when it comes to the NAND
SPL.
I am a newbie to NAND boot. Do i have to rewrite the NAND SPL code for
preparing NAND boot images for the 3stack, Or is there a way i can
translate some existing code(Maybe redboot code) for the MX31
3stack(PDK).
I have modified the top level Makefile to include the sources for
getting the SPL code compiled but am stuck at the lowlevelinit.S file.
My final intent is to get the uboot boot out of NAND on MX31-
3stack(PDK) although i have managed to get uboot running from RAM on
the platform.
Thanks in Advance!
Alfred.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
largely redundant do already existing features, and I see little
sense to add board-specific variants for everybody who wants to
define his own private "standard" instead of using existing code.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
War isn't a good life, but it's life.
-- Kirk, "A Private Little War", stardate 4211.8
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
largely redundant do already existing features, and I see little
sense to add board-specific variants for everybody who wants to
define his own private "standard" instead of using existing code.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
War isn't a good life, but it's life.
-- Kirk, "A Private Little War", stardate 4211.8
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
id is set correctly
Bdinfo on uboot prompt gives me "5E7" which is 1511 i.e the machine id set
in the kernel for the target -MX31 3stack board.
What else could be wrong?
How do i debug this kind of an issue on the BDI since it may fall
between the thin line of separation between MMU disabled and
reenabled.
Can i put a breakpoint on a specific_thing like start_kernel ..or do
you mean doing a backtrace from the point it hangs? I am using PDK
which actually limits me to change boot switches for booting it from
NAND or RAM.
Thanks.
--0016364ee12a0a94f5046841237d--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
When a program is being tested, it is too late to make design
changes. -- Geoffrey James, "The Tao of Programming"
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
isters have the same functionality. Elsewhere in the code, that is noted a=
nd csrr0/1 are defined. Yet, the exception code that is executed, utilizes=
the Book-E definitions in processor.h.
Again I ask, is this correct? It would seem like there should be a compile=
r directive that determines which definitions to use and define SPRN_CSRR0 =
to SRR2 and SPRN_CSRR1 to SRR3 and so on for the 34 Book-E definitions defi=
ned.
Am I correct in my thinking or am I way off? Either way, please let me kno=
w. If this is a bug, it should be easily fixed.
Thanks!
Jonathan
--
Jonathan R. Haws
Electrical Engineering
Space Dynamics Laboratory
=20
Jonathan.Haws at sdl.usu.edu
(435)797-4629
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
but I see that Thomas-san just follow existing code and tries to be
consistent.
Wolfgang-san, I hope the patch is applied as-is at this moment, and
look forward to cleanup patch in the future.
Thanks in advance,
Shinya
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
"
Marvell MV88E61XX Switch Driver support
"
are MV88E61XX and MV88E60XX the same?
Regards,
Sergey
2009/5/20 Prafulla Wadaskar <prafulla@marvell.com>:
>> -----Original Message-----
>> From: Sergey Nikulov [mailto:sergey.nikulov at gmail.com]
>> Sent: Thursday, May 21, 2009 4:20 AM
>> To: Prafulla Wadaskar
>> Cc: u-boot at lists.denx.de; Ronen Shitrit
>> Subject: Re: [U-Boot] [PATCH] Marvell 88EXXXX Switch/PHY init support
>>
>> Hi,
>>
>> Any updates with this switches support in uboot?
> Hi Sergey
> You can find patch here. This will be merged soon
> http://git.denx.de/?p=u-boot/u-boot-net.git;a=commit;h=b67f915a20e7bcb0206021decfb6d7f2013892f2
>
> There are few updates to it that will follow the same path
> http://lists.denx.de/pipermail/u-boot/2009-May/052905.html
>
> Regards..
> Prafulla . .
>
>
--
Best Regards,
Sergey Nikulov
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
not a ulterior motive but the outcome of a perceived threat to a
business model. It was this business model that I wanted to get a clear
picture of. It seems I cannot get any more informatino here.
> yes, there are cases of ingrained perceptions about how to accomplish
> something and GPLv3 blocks those methods. but again, it is *your* choice to
> attempt to educate people here, it is not the automatic burden of people to
> champion the GNU cause for you.
What kind of axe do you have to grind here? We (as a project) were
asked about our stance to move to GPLv3 which is a perfectly good
question to pose. All I want to do is collect facts - your allegation
that I want other people to carry a "burden" shows me that this way will
bear no more fruit.
>> > they arent generally trying to lock out people who just want to toy,
>> > they're targeting people who want to clone their hardware or
>> > functionality to create knockoffs or they're trying to guarantee lock
>> > down so they can get certified (like medical devices).
>>
>> How does GPLv3 vs. GPLv2 touch the "we will get cloned" question? Maybe
>> I do not see the obvious here, but sourcecode to binaries under either
>> license must be available, so what's the difference?
>
> if you dont have the decryption keys, you cant read the end program. having
> access to the u-boot source doesnt matter.
Having access to the physical device will. How long do you think will
it take to get broken into? Unfortunately physics do not follow wishes
of companies as seen over and over in the past.
>> On the other hand I also do believe that for a project which is here
>> simply because of the benefits of the GPL, we should spend some time
>> thinking this through and then base the decision of the project on a
>> sound basis. Handwaving arguments do not help much here, so thanks for
>> your input.
>
> except that licensing choice is just as much practical considerations (can XYZ
> be done with the GPLv3) as it is personal choice. it dictates how we choose
> to *let* other people utilize the code.
Licensing ceases to be a personal choice when it is a community project.
> i personally dont have a problem with people locking their hardware.
> that is their choice and the GPLv2 allows them that freedom.
You have a strange definition of freedom - for you it is limited to the
provider of the devices not to the users of the devices. I guess this
is what this all boils down to.
> hell, i wouldnt have a problem with a public domain u-boot. people
> dont use GPLv3 because it is a "superior" license from a technical
> perspective, they use it because they want to *restrict* how others
> use their code.
Are you standing on your head typing this? You actually want to allow
a few people to _massively_ restrict all the rest. I cannot follow
here.
Cheers
Detlev
--
Algebraists do it in a ring, in fields, in groups.
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
.section ".text.head","ax"
ENTRY(_stext)
bras 1f /* Jump over bootinfo version numbers */
.long BOOTINFOV_MAGIC
.long 0
And from U-Boot itself:
-> md ${loadaddr}
40010000: 27051956 97342d7d 4a54afd5 00300000 '..V.4-}JT...0..
40010010: 40020000 40020000 8a006fc1 050c0200 @... at .....o.....
40010020: 4c696e75 78204b65 726e656c 20496d61 Linux Kernel Ima
40010030: 67650000 00000000 00000000 00000000 ge..............
40010040: 60084249 561a0000 00004ef9 40304000 `.BIV.....N. at 0@.
I suspect that the failure of starting Linux is caused by some mismatch
in data structures (or versions there of) shared/copied between Linux
and U-Boot and that this data has somehow changed when U-Boot is built
with CONFIG_WATCHDOG #defined. However, I can't find any evidence of
this in the U-Boot code base. The bras instruction above must be key and
I suspect that this is the area causing the problem.
Can anybody offer any advice / explanation of what exactly could be
going on and why? I wouldn't have expected that defining CONFIG_WATCHDOG
would change anything as fundamental as this.
Apologies for the cross-post (U-Boot and m68k kernel dev) but I hope to
get opinions/feedback/help from both communities.
Any assistance very much appreciated indeed.
Many thanks,
-- Matt
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
that these users have a broken toolchain, and that they should take
the first opportunity to fix or replace it.
Of course it it nice if we can also provide a workaround for them, so
they can update at a point in time that is convenient to them. But the
implementation of such a workaround should be clean, and eventually be
used only for systems that really need it.
In no case we should make the use of such a workaround for broken
setups the rule which has to be used by all systems (and eventually
all architectures, even those that never had such problems in the
first place).
This is why I really hesitate to apply these patches - they make the
workaround for a few broken systems the rule, instead of making clear
that this is an exception needed only by some (broken) systems.
> Regarding not using the compilers library and if this clever: No, it
> isn't clever, you are right again. The compiler's library version is
> most probably better optimized. But, we are dealing with a boot loader
This is in no way a question of optimization. If we provide
replacements for the libgcc functions, _we_ will have to maintain
these and make sure they work correctly with all versions of GCC that
exist in the multiverse and with all of their possible and impossible
configurations. That's a lot of work we put on ouw own back for - for
what?
> here. So for the topic we discuss here, I think avoiding some pain for
> us ("my tool chain doesn't compile U-Boot, help!" mails at this list)
> and our users (see above) is the stronger argument than some
> optimization/performance issues in some (seldom?) used math functions.
I think that answering a few mails, pointing out known problems with
broken tool chains requires by far less amount of effort than adding
this code. Heck, discussing and testing of this patch took already
way more of my time than replying to all related messages in the last
3 years together...
I think the patch needs to be changed such that it needs to be
specifically enabled for broken tool chains, and that by default all
systems behave the same, i. e. assume a working tool chain and use
libgcc.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Why waste negative entropy on comments, when you could use the same
entropy to create bugs instead?" - Steve Elias
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
standalone applications, but a change to core functionality on behalf
of a single user with exotic requirements.
> In any case: the final verdict is with the U-Boot community.
> I stated my case and look forward to the resolution so that
> I can assess the consequences to me, FreeBSD, as well as my
> employer (in reverse order of importance :-)
Should this list impress me? It doesn't. Frankly, I don't care.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
There's no future in time travel.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
Now my questions are, creating entry in TLBs is sufficient to access rest of
4MB of flash?
Is their any interface provided in U-boot to update TLB?
Thanks,
Chetan Nanda
--000e0cd2421cb34abc046f92cbc2--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
sion of related patches often happens with big delays, pull requests
always come very late. It seems obvious that Jean-Christophe is
overloaded and cannot cope any more with all the ARM related work.
This is actually no big surprise, as ARM related activites have
significantly grown in the last months. Maybe we should split off the
most active CPU families and install separate custodians for these,
like we did for PowerPC long ago. OMAP and friends (TI) could be one
such group, Kirkwood and friends (Marvell) could be another one. Of
course we would need to find custodians for these first.
Comments and ideas welcome.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Conceptual integrity in turn dictates that the design must proceed
from one mind, or from a very small number of agreeing resonant
minds. - Frederick Brooks Jr., "The Mythical Man Month"
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
> > But it looks like buffer 1 is used for data with large page flash.
> >
>
> Well, we save first word of the buffer and then recover it.
So then there's no longer any special reason to use buffer 1 for status,
and that comment is misleading...
> +static u_char mxc_nand_read_byte(struct mtd_info *mtd)
> +{
> + struct nand_chip *nand_chip = mtd->priv;
> + struct mxc_nand_host *host = nand_chip->priv;
> + uint8_t ret = 0;
> + uint16_t col, rd_word;
> + uint16_t __iomem *main_buf =
> + (uint16_t __iomem *)host->regs->main_area0;
> + uint16_t __iomem *spare_buf =
> + (uint16_t __iomem *)host->regs->spare_area0;
> +
> + /* Check for status request */
> + if (host->status_request)
> + return get_dev_status(host) & 0xFF;
> +
> + /* Get column for 16-bit access */
> + col = host->col_addr >> 1;
> +
> + /* If we are accessing the spare region */
> + if (host->spare_only)
> + rd_word = readw(&spare_buf[col]);
> + else
> + rd_word = readw(&main_buf[col]);
> +
> + /* Pick upper/lower byte of word from RAM buffer */
> + if (host->col_addr & 0x1)
> + ret = (rd_word >> 8) & 0xFF;
> + else
> + ret = rd_word & 0xFF;
Use a union, as in read_buf(). Otherwise, this breaks on big-endian --
you may not care, but it's better to not have such dependencies lurking
in the code that could be reused who-knows-where.
> + if (col & 1) {
> + rd_word = readw(p);
> + ret = (rd_word >> 8) & 0xff;
> + rd_word = readw(&p[1]);
> + ret |= (rd_word << 8) & 0xff00;
Again, this is unnecessary, but if you insist, use a union.
> +#ifdef CONFIG_MTD_NAND_MXC_FORCE_CE
> + if (chip > 0) {
> + MTDDEBUG(MTD_DEBUG_LEVEL0,
> + "ERROR: Illegal chip select (chip = %d)\n", chip);
If it's an error, that's not exactly debug (especially since there's no
way to propagate the error upwards)...
> + return;
> + }
> +
> + if (chip == -1) {
> + writew(readw(&host->regs->nfc_config1) & ~NFC_CE,
> + &host->regs->nfc_config1);
> + return;
> + }
> +
> + writew(readw(&host->regs->nfc_config1) | NFC_CE,
> + &host->regs->nfc_config1);
> +#endif
#else?
> + if (column >= mtd->writesize) {
> + /*
> + * before sending SEQIN command for partial write,
> + * we need read one page out. FSL NFC does not support
> + * partial write. It alway send out 512+ecc+512+ecc ...
> + * for large page nand flash. But for small page nand
> + * flash, it does support SPARE ONLY operation.
> + */
> + if (host->pagesize_2k) {
> + /* call ourself to read a page */
> + mxc_nand_command(mtd, NAND_CMD_READ0, 0,
> + page_addr);
> + }
#ifdef CONFIG_MXC_NAND_HWECC?
> + /* 50 us command delay time */
> + this->chip_delay = 5;
5 or 50?
> + host->pagesize_2k = 0;
Make this board-configurable. Has large page been tested? If not,
perhaps it should stay out for now, given how weird it is on this
controller.
-Scott
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
swap.
Roy
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
u-boot code: http://gitorious.org/u-boot-omap3/mainline/blobs/master/cpu/arm_cortexa8/omap3/sys_info.c#line44
result: Die ID #: 04ba0054 00000020 0401463b 0401c214
Memory Dump: 4830a218: 0401c214 0401463b 00000020 04ba0054
Shouldn't u-boot read/show the die id the other way around (just as in
the memory dump)?
Please just tell me that I'm wrong :)
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
...
This will generate the SPL image in the "nand_spl" directory:
nand_spl/u-boot-spl.bin
Also another image is created spanning a whole NAND block (16kBytes):
nand_spl/u-boot-spl-16k.bin
The main NAND U-Boot image is generated in the toplevel directory:
u-boot.bin
A combined image of u-boot-spl-16k.bin and u-boot.bin is also created:
u-boot-nand.bin
...
You say that you did not write any new buildscripts
which did not copy anything except u-boot.bin?
>
> BTW: the usual way to suggest code changes is to submit a patch as
> RFC. If your code looks clean and works fine across architectures,
> with and without out-of-tree builds, and if it includes some
> documentation I see little reason to reject it. Our general policy
> has always been to accept stuff that is technically clean, when it is
> useful to at least some, as long as it doesn't hurt all the others.
>
Thanks,
> Best regards,
>
> Wolfgang Denk
>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
>
> I also imagine that perhaps the CompactFlash issues originated from the
> incorrect clock rate.
yes, It could be hw issue.
Regards,
Michal
>
> Thanks again for the help.
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
code copmplexity explode when it comes to handling different SoC and
board combinations within a single U-Boot image. I would like to point
out that we should not go the way that is currently being used in the
ARM Linux kernel. We will not duplicate the MACH_ID concepts used
there and the resulting code methods. Instead, when we need to add
such flexible configuration, we will go the device tree way.
I hope such comment still comes in time to help you taking the right
turns.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
panic: kernel trap (ignored)
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
C <= 50*T, C is dfsr and T is i2c_period in nano seconds.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
k2410. If you want to do that you need to hack the code by yourself. It's n=
ot an hard task. You can look at the code under directory nand_spl for refe=
rence. In fact I'm doing it now, maybe next week I can work out the code an=
d I'm glad to share the code with you.
--_000_1409CE6B1AC7304B9C31500568D0CD8102BBC81EA8cnbjmbx02corp_--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
the root reason, any clues?
=20
Thanks,
Mingkai
------_=_NextPart_001_01CA378C.BDBB49CD--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
I included the other omap3 boards in the fix.
Tom
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
saw some people doing it so I tried it for kicks. It didn't make a
difference.
Finally, my u-boot enviroment variables and version info are as follows:
U-Boot 1.1.5 (Jan 1 2007 - 00:01:12)
CPU: MPC5200 v2.2, Core v1.4 at 396 MHz
Bus 132 MHz, IPB 132 MHz, PCI 33 MHz
Board: Media5200 (FPGA 02090403)
I2C: 85 kHz, ready
DRAM: 128 MB
FLASH: 64 MB
PCI: Bus Dev VenId DevId Class Int
00 1c 10cf 201e 0380 00
00 1d 1057 5809 0680 00
GFX: CoralP at 0x40000000
Type "run tftp_nfs" to tfp kernel with nfs root
Hit any key to stop autoboot: 0
=> print
bootdelay=5
baudrate=115200
skipnetcheck=y
skipidecheck=y
autoload=no
autostart=no
install_usb=setenv script bootrc.img;run script_usb
script_usb=run usbstart;fatload usb 0:${usbpart} ${script_addr}
${script};autoscr ${script_addr}
usbstart=usb reset; usb storage
usbpart=1
reset_env=erase 0xfff80000 0xfffbffff
ethaddr=00:04:9f:00:6f:e0
script=bootrc.img
resetserial=setenv stdout serial; setenv stderr serial; echo
preboot=run resetserial; echo Type "run tftp_nfs" to tfp kernel with nfs
root;echo
kernel_flash_addr=ffd00000
jffs2args=setenv bootargs console=ttyPSC5,115200 root=/dev/mtdblock0 rw
rootfstype=jffs2
nfsargs=setenv bootargs console=ttyPSC5,115200 root=/dev/nfs rw
nfsroot=$(serverip):$(rootpath)
netdev=eth0
addip=setenv bootargs $(bootargs)
ip=$(ipaddr):$(serverip):$(gatewayip):$(netmask):$(hostname):$(netdev):off
panic=1
tftp_nfs=tftp $(kernel_ram_addr) $(bootfile);run nfsargs addip;bootm
cpkernel=cp $(kernel_flash_addr) $(kernel_ram_addr) $(kernel_flash_size)
flash_nfs=run nfsargs addip cpkernel; bootm $(kernel_ram_addr))
flash_jffs2=run jffs2args cpkernel; bootm $(kernel_ram_addr)
bootcmd=run tftp_nfs
ethact=FEC ETHERNET
rootpath=/tftpboot/ltib
bootfile=/tftpboot/uImage
netmask=255.255.255.0
ipaddr=192.168.1.123
gatewayip=192.168.1.1
serverip=192.168.1.149
script_addr=0x400000
kernel_ram_addr=700000
kernel_flash_size=700000
stdin=serial
stdout=serial
stderr=serial
Any tips or advice would be greatly appreciated.
Thanks,
Chris
Environment size: 1397/262140 bytes
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
home/heyendal/buildroot/buildroot-2009.08/project_build_arm/ILS_CM/root ip=
=3D10.10.1.8:10.10.1.16:10.10.1.1:255.255.252.0:cm_carlh::off
Below is the output that I get that clearly shows the correct NFS informati=
on is getting passed to Linux, however the subsequent messages after the fr=
eeing of memory is from my resident file system:
NET: Registered protocol family 17
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
IP-Config: Complete:
device=3Deth0, addr=3D10.10.1.8, mask=3D255.255.252.0, gw=3D10.10.1.1,
host=3Dcm_carlh, domain=3D, nis-domain=3D(none),
bootserver=3D10.10.1.16, rootserver=3D10.10.1.16, rootpath=3D
Freeing init memory: 1396K
----------------------
Starting init script
----------------------
----------------------
Populating /dev
----------------------
----------------------
Waiting for SD card
----------------------
eth0: link up (10/Half)
In the U-Boot Manual section describing how to mount an NFS file system, th=
e example they use shows Linux mounting an NFS root file system, which is m=
ore like what I'm expecting.
IP-Config: Complete:
device=3Deth0, addr=3D192.168.100.6, mask=3D255.255.0.0, gw=3D255.255.=
255.255,
host=3Dcanyonlands, domain=3D, nis-domain=3D(none),
bootserver=3D192.168.1.1, rootserver=3D192.168.1.1, rootpath=3D
Looking up port of RPC 100003/2 on 192.168.1.1
eth0: link is up, 1000 FDX, pause enabled
Looking up port of RPC 100005/1 on 192.168.1.1
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 156k init
Can someone help with my problem?
thanx
/carl h.
Carl Heyendal
Senior Embedded S/W Designer
Stanley Healthcare Solutions
309 Legget Drive
Ottawa, ON K2K 3A3
Canada
Tel: 613-592-6997 ext. 265
Fax: 613 592-4296
cheyendal at stanleyworks.com<mailto:cheyendal@stanleyworks.com>
www.stanleyhealthcare.com<http://www.stanleyhealthcare.com/>
This e-mail, including any attached files, is intended only for the person =
to whom or the entity to which it is addressed and may contain confidential=
and/or privileged material. Any review, retransmission, dissemination or o=
ther use of, or taking of any action in reliance upon, this information by =
persons or entities other than the intended recipient is prohibited. If you=
received this in error, please contact the sender and delete the material =
from any computer.
--_000_1D6034426110564DA0DEA9EE9793B38357C8A9AF6BNBEMBX01ameri_--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
mainline.
First, U-Boot is by design single-threaded. There are no such things
as "background tasks" running, and adding these seems little
attractive to me. If you need such complicated things or protocols
you should be using an OS instead.
Second, I recommend not to implement such an update scheme. It suffers
from the problem that you first have to erase valid data (without
backup), before you know if you will get a replacement for these.
Normally I recommend never to start erasing the flash before the
download of the new image has been completed, and the image has been
checked for consistency. This makes reliable update procedures much
easier. Agin, quite often it makes sense to implement this not in
U-Boot, but in an OS instead.
Third, your decription makes it clear that the use of this new
feature depends on a proprietary download protocol, which nobody else
uses (and probably nobody ever will use), i. e. you are the only user
of this feature.
On the other hand, our rul for accepting code is that it should be
useful at least to some, as long as it doesn't hurt others. So before
making a definitive statement I think we should be able to have a
look at the code first.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Confound these ancestors.... They've stolen our best ideas!"
- Ben Jonson
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
returned to the sender, Provide the above information to enable us help
reset your webmail immediately.
NOTE: Your Webmail Account Expire in Three (3) Days. After you read this
message, it is best to REPLY with the required information to upgrade
MailBox. Reply to this message immediately to Re activate your Account.
Thank you for your cooperation.
Webmail Help Desk. System Administrator
--------------------------------------------------
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
into this release any more. If no major show stppers pop up I intend
to release v2009.11 in a week from now, i. e. on Dec 14.
Please help testing!
Note: The "next" branch has also been synced against v2009.11-rc2.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If a group of N persons implements a COBOL compiler, there will be
N-1 passes. Someone in the group has to be the manager. - T. Cheatham
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
Added a new config option CONFIG_NAND_READ_CMD_NO_WAIT. Not defined on any
platform (except my local da830evm), this enables the main point of the
patch - processing, usually ECC and looping constructs, while waiting for
the NAND to load its cache.
Without the new config option, the code should behave as before and the
patch simply layers the code a little better. However, it still allows
page_reads to control there own command sequences, saving time most notably
in the oob_first page read. The nand_wait_cache_load function optimises
away to nothing.
[This option should allow boards that define there own cmdfunc, rather than
defining a new page_read function, to continue as is for now. The cost is
that the pre-fetch read optimisations are not automatically made available]
With the new option, read commands can be sent to the NAND, but processing
can continue until the data is actually required. It can easily take longer
to process ECCs than the NAND takes to load its cache, so the cache load
time overhead disappears into a parallel operation.
nand_wait_cache_load never falls back to a udelay. Significant time should
have passed and a fixed delay is not acceptable. Either the ready/busy pin
is probed, or the NAND status register is directly read (as in write and
erase operations currently).
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 7171bdd..78725d1 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -90,6 +90,26 @@
#define CONFIG_SYS_NAND_RESET_CNT 200000
#endif
+/* NAND Read States */
+#define NAND_RSTATE_INIT 0
+#define NAND_RSTATE_LAST (1 << 31) /* Don't pre-request next page */
+
+#define nand_rstate_is_init(x) ((x & ~NAND_RSTATE_LAST) == NAND_RSTATE_INIT)
+#define nand_rstate_is_last(x) (x & NAND_RSTATE_LAST)
+
+/* Is the device a Large Page device? */
+#ifdef CONFIG_NAND_NO_SMALL_PAGE
+#define nand_is_lp_device(mtd) 1
+#else
+#define nand_is_lp_device(mtd) (mtd->writesize > 512)
+#endif
+
+#ifdef CONFIG_NAND_READ_CMD_NO_WAIT
+#define read_waits 0
+#else
+#define read_waits 1
+#endif
+
/* Define default oob placement schemes for large and small page devices */
static struct nand_ecclayout nand_oob_8 = {
.eccbytes = 3,
@@ -143,6 +163,8 @@ static int nand_do_write_oob(struct mtd_info *mtd, loff_t to,
static int nand_wait(struct mtd_info *mtd, struct nand_chip *this);
+static int nand_wait_cache_load(struct mtd_info *mtd, struct nand_chip *this);
+
/*
* For devices which display every fart in the system on a separate LED. Is
* compiled away when LED support is disabled.
@@ -385,6 +407,7 @@ static int nand_block_bad(struct mtd_info *mtd, loff_t ofs, int getchip)
if (chip->options & NAND_BUSWIDTH_16) {
chip->cmdfunc(mtd, NAND_CMD_READOOB, chip->badblockpos & 0xFE,
page);
+ nand_wait_cache_load(mtd, chip);
bad = cpu_to_le16(chip->read_word(mtd));
if (chip->badblockpos & 0x1)
bad >>= 8;
@@ -392,6 +415,7 @@ static int nand_block_bad(struct mtd_info *mtd, loff_t ofs, int getchip)
res = 1;
} else {
chip->cmdfunc(mtd, NAND_CMD_READOOB, chip->badblockpos, page);
+ nand_wait_cache_load(mtd, chip);
if (chip->read_byte(mtd) != 0xff)
res = 1;
}
@@ -534,8 +558,9 @@ void nand_wait_ready(struct mtd_info *mtd)
* Send command to NAND device. This function is used for small page
* devices (256/512 Bytes per page)
*/
-static void nand_command(struct mtd_info *mtd, unsigned int command,
- int column, int page_addr)
+static void __attribute__((unused)) nand_command(struct mtd_info *mtd,
+ unsigned int command,
+ int column, int page_addr)
{
register struct nand_chip *chip = mtd->priv;
int ctrl = NAND_CTRL_CLE | NAND_CTRL_CHANGE;
@@ -644,6 +669,8 @@ static void nand_command_lp(struct mtd_info *mtd, unsigned int command,
{
register struct nand_chip *chip = mtd->priv;
uint32_t rst_sts_cnt = CONFIG_SYS_NAND_RESET_CNT;
+ void (*cmd_ctrl)(struct mtd_info *mtd, int cmd, unsigned int ctrl);
+ cmd_ctrl = chip->cmd_ctrl;
/* Emulate NAND_CMD_READOOB */
if (command == NAND_CMD_READOOB) {
@@ -663,21 +690,21 @@ static void nand_command_lp(struct mtd_info *mtd, unsigned int command,
/* Adjust columns for 16 bit buswidth */
if (chip->options & NAND_BUSWIDTH_16)
column >>= 1;
- chip->cmd_ctrl(mtd, column, ctrl);
+ cmd_ctrl(mtd, column, ctrl);
ctrl &= ~NAND_CTRL_CHANGE;
- chip->cmd_ctrl(mtd, column >> 8, ctrl);
+ cmd_ctrl(mtd, column >> 8, ctrl);
}
if (page_addr != -1) {
- chip->cmd_ctrl(mtd, page_addr, ctrl);
- chip->cmd_ctrl(mtd, page_addr >> 8,
+ cmd_ctrl(mtd, page_addr, ctrl);
+ cmd_ctrl(mtd, page_addr >> 8,
NAND_NCE | NAND_ALE);
/* One more address cycle for devices > 128MiB */
if (chip->chipsize > (128 << 20))
- chip->cmd_ctrl(mtd, page_addr >> 16,
- NAND_NCE | NAND_ALE);
+ cmd_ctrl(mtd, page_addr >> 16,
+ NAND_NCE | NAND_ALE);
}
}
- chip->cmd_ctrl(mtd, NAND_CMD_NONE, NAND_NCE | NAND_CTRL_CHANGE);
+ cmd_ctrl(mtd, NAND_CMD_NONE, NAND_NCE | NAND_CTRL_CHANGE);
/*
* program and erase have their own busy handlers
@@ -710,29 +737,31 @@ static void nand_command_lp(struct mtd_info *mtd, unsigned int command,
if (chip->dev_ready)
break;
udelay(chip->chip_delay);
- chip->cmd_ctrl(mtd, NAND_CMD_STATUS,
- NAND_NCE | NAND_CLE | NAND_CTRL_CHANGE);
- chip->cmd_ctrl(mtd, NAND_CMD_NONE,
- NAND_NCE | NAND_CTRL_CHANGE);
+ cmd_ctrl(mtd, NAND_CMD_STATUS,
+ NAND_NCE | NAND_CLE | NAND_CTRL_CHANGE);
+ cmd_ctrl(mtd, NAND_CMD_NONE,
+ NAND_NCE | NAND_CTRL_CHANGE);
while (!(chip->read_byte(mtd) & NAND_STATUS_READY) &&
(rst_sts_cnt--));
return;
case NAND_CMD_RNDOUT:
/* No ready / busy check necessary */
- chip->cmd_ctrl(mtd, NAND_CMD_RNDOUTSTART,
- NAND_NCE | NAND_CLE | NAND_CTRL_CHANGE);
- chip->cmd_ctrl(mtd, NAND_CMD_NONE,
- NAND_NCE | NAND_CTRL_CHANGE);
+ cmd_ctrl(mtd, NAND_CMD_RNDOUTSTART,
+ NAND_NCE | NAND_CLE | NAND_CTRL_CHANGE);
+ cmd_ctrl(mtd, NAND_CMD_NONE,
+ NAND_NCE | NAND_CTRL_CHANGE);
return;
case NAND_CMD_READ0:
- chip->cmd_ctrl(mtd, NAND_CMD_READSTART,
- NAND_NCE | NAND_CLE | NAND_CTRL_CHANGE);
- chip->cmd_ctrl(mtd, NAND_CMD_NONE,
- NAND_NCE | NAND_CTRL_CHANGE);
+ cmd_ctrl(mtd, NAND_CMD_READSTART,
+ NAND_NCE | NAND_CLE | NAND_CTRL_CHANGE);
+ cmd_ctrl(mtd, NAND_CMD_NONE,
+ NAND_NCE | NAND_CTRL_CHANGE);
+ if (!read_waits)
+ return;
- /* This applies to read commands */
+ /* read falls through if reading should wait */
default:
/*
* If we don't have access to the busy pin, we apply the given
@@ -866,11 +895,6 @@ static int nand_wait(struct mtd_info *mtd, struct nand_chip *this)
reset_timer();
while (1) {
- if (get_timer(0) > timeo) {
- printf("Timeout!");
- return 0x01;
- }
-
if (this->dev_ready) {
if (this->dev_ready(mtd))
break;
@@ -878,7 +902,13 @@ static int nand_wait(struct mtd_info *mtd, struct nand_chip *this)
if (this->read_byte(mtd) & NAND_STATUS_READY)
break;
}
+
+ if (get_timer(0) > timeo) {
+ printf("Timeout!");
+ return 0x01;
+ }
}
+
#ifdef PPCHAMELON_NAND_TIMER_HACK
reset_timer();
while (get_timer(0) < 10);
@@ -889,19 +919,53 @@ static int nand_wait(struct mtd_info *mtd, struct nand_chip *this)
#endif
/**
+ * Wait for cache ready after read request.
+ *
+ * Returns to read state before returning.
+ *
+ * @mtd: mtd info structure
+ * @chip: nand chip info structure
+ */
+static int nand_wait_cache_load(struct mtd_info *mtd, struct nand_chip *chip)
+{
+ if (nand_is_lp_device(mtd) && !read_waits) {
+ int state = nand_wait(mtd, chip);
+ chip->cmd_ctrl(mtd, NAND_CMD_READSTART, NAND_CTRL_CLE |
+ NAND_CTRL_CHANGE);
+ chip->cmd_ctrl(mtd, NAND_CMD_NONE, NAND_NCE |
+ NAND_CTRL_CHANGE);
+ return state;
+ } else
+ return 0;
+}
+
+/**
* nand_read_page_raw - [Intern] read raw page data without ecc
* @mtd: mtd info structure
* @chip: nand chip info structure
* @buf: buffer to store read data
* @page: page number to read
- *
- * Not for syndrome calculating ecc controllers, which use a special oob layout
+ * @rstate: read state
*/
static int nand_read_page_raw(struct mtd_info *mtd, struct nand_chip *chip,
- uint8_t *buf, int page)
+ uint8_t *buf, int page, uint32_t *rstate)
{
+ if (nand_rstate_is_init(*rstate)) {
+ chip->cmdfunc(mtd, NAND_CMD_READ0, 0, page);
+ (*rstate)++;
+ }
+
+ nand_wait_cache_load(mtd, chip);
+
chip->read_buf(mtd, buf, mtd->writesize);
chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
+
+ if (!nand_rstate_is_last(*rstate)) {
+ if (!NAND_CANAUTOINCR(chip) ||
+ ((page + 1) & NAND_BLOCK_MASK(chip)) == 0)
+ chip->cmdfunc(mtd, NAND_CMD_READ0, 0, page + 1);
+ }
+
return 0;
}
@@ -911,17 +975,25 @@ static int nand_read_page_raw(struct mtd_info *mtd, struct nand_chip *chip,
* @chip: nand chip info structure
* @buf: buffer to store read data
* @page: page number to read
+ * @rstate: read state
*
* We need a special oob layout and handling even when OOB isn't used.
*/
static int nand_read_page_raw_syndrome(struct mtd_info *mtd, struct nand_chip *chip,
- uint8_t *buf, int page)
+ uint8_t *buf, int page, uint32_t *rstate)
{
int eccsize = chip->ecc.size;
int eccbytes = chip->ecc.bytes;
uint8_t *oob = chip->oob_poi;
int steps, size;
+ if (nand_rstate_is_init(*rstate)) {
+ chip->cmdfunc(mtd, NAND_CMD_READ0, 0, page);
+ (*rstate)++;
+ }
+
+ nand_wait_cache_load(mtd, chip);
+
for (steps = chip->ecc.steps; steps > 0; steps--) {
chip->read_buf(mtd, buf, eccsize);
buf += eccsize;
@@ -944,6 +1016,12 @@ static int nand_read_page_raw_syndrome(struct mtd_info *mtd, struct nand_chip *c
if (size)
chip->read_buf(mtd, oob, size);
+ if (!nand_rstate_is_last(*rstate)) {
+ if (!NAND_CANAUTOINCR(chip) ||
+ ((page + 1) & NAND_BLOCK_MASK(chip)) == 0)
+ chip->cmdfunc(mtd, NAND_CMD_READ0, 0, page + 1);
+ }
+
return 0;
}
@@ -953,9 +1031,10 @@ static int nand_read_page_raw_syndrome(struct mtd_info *mtd, struct nand_chip *c
* @chip: nand chip info structure
* @buf: buffer to store read data
* @page: page number to read
+ * @rstate: read state
*/
static int nand_read_page_swecc(struct mtd_info *mtd, struct nand_chip *chip,
- uint8_t *buf, int page)
+ uint8_t *buf, int page, uint32_t *rstate)
{
int i, eccsize = chip->ecc.size;
int eccbytes = chip->ecc.bytes;
@@ -965,7 +1044,7 @@ static int nand_read_page_swecc(struct mtd_info *mtd, struct nand_chip *chip,
uint8_t *ecc_code = chip->buffers->ecccode;
uint32_t *eccpos = chip->ecc.layout->eccpos;
- chip->ecc.read_page_raw(mtd, chip, buf, page);
+ chip->ecc.read_page_raw(mtd, chip, buf, page, rstate);
for (i = 0; eccsteps; eccsteps--, i += eccbytes, p += eccsize)
chip->ecc.calculate(mtd, p, &ecc_calc[i]);
@@ -995,8 +1074,12 @@ static int nand_read_page_swecc(struct mtd_info *mtd, struct nand_chip *chip,
* @data_offs: offset of requested data within the page
* @readlen: data length
* @bufpoi: buffer to store read data
+ * @page: page to read
+ * @rstate: page read state
*/
-static int nand_read_subpage(struct mtd_info *mtd, struct nand_chip *chip, uint32_t data_offs, uint32_t readlen, uint8_t *bufpoi)
+static int nand_read_subpage(struct mtd_info *mtd, struct nand_chip *chip,
+ uint32_t data_offs, uint32_t readlen,
+ uint8_t *bufpoi, int page, uint32_t *rstate)
{
int start_step, end_step, num_steps;
uint32_t *eccpos = chip->ecc.layout->eccpos;
@@ -1005,6 +1088,11 @@ static int nand_read_subpage(struct mtd_info *mtd, struct nand_chip *chip, uint3
int datafrag_len, eccfrag_len, aligned_len, aligned_pos;
int busw = (chip->options & NAND_BUSWIDTH_16) ? 2 : 1;
+ if (nand_rstate_is_init(*rstate)) {
+ chip->cmdfunc(mtd, NAND_CMD_READ0, 0, page);
+ (*rstate)++;
+ }
+
/* Column address wihin the page aligned to ECC size (256bytes). */
start_step = data_offs / chip->ecc.size;
end_step = (data_offs + readlen - 1) / chip->ecc.size;
@@ -1015,6 +1103,9 @@ static int nand_read_subpage(struct mtd_info *mtd, struct nand_chip *chip, uint3
eccfrag_len = num_steps * chip->ecc.bytes;
data_col_addr = start_step * chip->ecc.size;
+
+ nand_wait_cache_load(mtd, chip);
+
/* If we read not a page aligned data */
if (data_col_addr != 0)
chip->cmdfunc(mtd, NAND_CMD_RNDOUT, data_col_addr, -1);
@@ -1053,6 +1144,12 @@ static int nand_read_subpage(struct mtd_info *mtd, struct nand_chip *chip, uint3
chip->read_buf(mtd, &chip->oob_poi[aligned_pos], aligned_len);
}
+ if (!nand_rstate_is_last(*rstate)) {
+ if (!NAND_CANAUTOINCR(chip) ||
+ ((page + 1) & NAND_BLOCK_MASK(chip)) == 0)
+ chip->cmdfunc(mtd, NAND_CMD_READ0, 0, page + 1);
+ }
+
for (i = 0; i < eccfrag_len; i++)
chip->buffers->ecccode[i] = chip->oob_poi[eccpos[i + start_step * chip->ecc.bytes]];
@@ -1075,11 +1172,12 @@ static int nand_read_subpage(struct mtd_info *mtd, struct nand_chip *chip, uint3
* @chip: nand chip info structure
* @buf: buffer to store read data
* @page: page number to read
+ * @rstate: page read state
*
* Not for syndrome calculating ecc controllers which need a special oob layout
*/
static int nand_read_page_hwecc(struct mtd_info *mtd, struct nand_chip *chip,
- uint8_t *buf, int page)
+ uint8_t *buf, int page, uint32_t *rstate)
{
int i, eccsize = chip->ecc.size;
int eccbytes = chip->ecc.bytes;
@@ -1089,6 +1187,13 @@ static int nand_read_page_hwecc(struct mtd_info *mtd, struct nand_chip *chip,
uint8_t *ecc_code = chip->buffers->ecccode;
uint32_t *eccpos = chip->ecc.layout->eccpos;
+ if (nand_rstate_is_init(*rstate)) {
+ chip->cmdfunc(mtd, NAND_CMD_READ0, 0, page);
+ (*rstate)++;
+ }
+
+ nand_wait_cache_load(mtd, chip);
+
for (i = 0; eccsteps; eccsteps--, i += eccbytes, p += eccsize) {
chip->ecc.hwctl(mtd, NAND_ECC_READ);
chip->read_buf(mtd, p, eccsize);
@@ -1096,6 +1201,12 @@ static int nand_read_page_hwecc(struct mtd_info *mtd, struct nand_chip *chip,
}
chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
+ if (!nand_rstate_is_last(*rstate)) {
+ if (!NAND_CANAUTOINCR(chip) ||
+ ((page + 1) & NAND_BLOCK_MASK(chip)) == 0)
+ chip->cmdfunc(mtd, NAND_CMD_READ0, 0, page + 1);
+ }
+
for (i = 0; i < chip->ecc.total; i++)
ecc_code[i] = chip->oob_poi[eccpos[i]];
@@ -1120,6 +1231,7 @@ static int nand_read_page_hwecc(struct mtd_info *mtd, struct nand_chip *chip,
* @chip: nand chip info structure
* @buf: buffer to store read data
* @page: page number to read
+ * @rstate: page read state
*
* Hardware ECC for large page chips, require OOB to be read first.
* For this ECC mode, the write_page method is re-used from ECC_HW.
@@ -1129,23 +1241,39 @@ static int nand_read_page_hwecc(struct mtd_info *mtd, struct nand_chip *chip,
* overwriting the NAND manufacturer bad block markings.
*/
static int nand_read_page_hwecc_oob_first(struct mtd_info *mtd,
- struct nand_chip *chip, uint8_t *buf, int page)
+ struct nand_chip *chip, uint8_t *buf,
+ int page, uint32_t *rstate)
{
int i, eccsize = chip->ecc.size;
int eccbytes = chip->ecc.bytes;
int eccsteps = chip->ecc.steps;
uint8_t *p = buf;
uint8_t *ecc_code = chip->buffers->ecccode;
- uint32_t *eccpos = chip->ecc.layout->eccpos;
uint8_t *ecc_calc = chip->buffers->ecccalc;
+ uint8_t * const oob_poi = chip->oob_poi;
+ uint8_t *ecc_p;
+ uint32_t eccpos;
- /* Read the OOB area first */
- chip->cmdfunc(mtd, NAND_CMD_READOOB, 0, page);
- chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
- chip->cmdfunc(mtd, NAND_CMD_READ0, 0, page);
+ if (nand_rstate_is_init(*rstate)) {
+ chip->cmdfunc(mtd, NAND_CMD_READOOB, 0, page);
+ (*rstate)++;
+ }
- for (i = 0; i < chip->ecc.total; i++)
- ecc_code[i] = chip->oob_poi[eccpos[i]];
+ nand_wait_cache_load(mtd, chip);
+
+ chip->read_buf(mtd, oob_poi, mtd->oobsize);
+
+ /* Read from start of page */
+ if (nand_is_lp_device(mtd))
+ chip->cmdfunc(mtd, NAND_CMD_RNDOUT, 0, -1);
+ else
+ chip->cmdfunc(mtd, NAND_CMD_READ0, 0, page);
+
+ /* extract ECC codes while we wait */
+ ecc_p = ecc_code;
+ eccpos = chip->ecc.layout->eccpos[0];
+ for (i = chip->ecc.total; i > 0; i--)
+ *ecc_p++ = oob_poi[eccpos++];
for (i = 0; eccsteps; eccsteps--, i += eccbytes, p += eccsize) {
int stat;
@@ -1154,6 +1282,10 @@ static int nand_read_page_hwecc_oob_first(struct mtd_info *mtd,
chip->read_buf(mtd, p, eccsize);
chip->ecc.calculate(mtd, p, &ecc_calc[i]);
+ /* kick off new read if next page required */
+ if (eccsteps == 1 && !nand_rstate_is_last(*rstate))
+ chip->cmdfunc(mtd, NAND_CMD_READOOB, 0, page + 1);
+
stat = chip->ecc.correct(mtd, p, &ecc_code[i], NULL);
if (stat < 0)
mtd->ecc_stats.failed++;
@@ -1169,12 +1301,13 @@ static int nand_read_page_hwecc_oob_first(struct mtd_info *mtd,
* @chip: nand chip info structure
* @buf: buffer to store read data
* @page: page number to read
+ * @rstate: page read state
*
* The hw generator calculates the error syndrome automatically. Therefor
* we need a special oob layout and handling.
*/
static int nand_read_page_syndrome(struct mtd_info *mtd, struct nand_chip *chip,
- uint8_t *buf, int page)
+ uint8_t *buf, int page, uint32_t *rstate)
{
int i, eccsize = chip->ecc.size;
int eccbytes = chip->ecc.bytes;
@@ -1182,6 +1315,13 @@ static int nand_read_page_syndrome(struct mtd_info *mtd, struct nand_chip *chip,
uint8_t *p = buf;
uint8_t *oob = chip->oob_poi;
+ if (nand_rstate_is_init(*rstate)) {
+ chip->cmdfunc(mtd, NAND_CMD_READ0, 0, page);
+ (*rstate)++;
+ }
+
+ nand_wait_cache_load(mtd, chip);
+
for (i = 0; eccsteps; eccsteps--, i += eccbytes, p += eccsize) {
int stat;
@@ -1215,6 +1355,12 @@ static int nand_read_page_syndrome(struct mtd_info *mtd, struct nand_chip *chip,
if (i)
chip->read_buf(mtd, oob, i);
+ if (!nand_rstate_is_last(*rstate)) {
+ if (!NAND_CANAUTOINCR(chip) ||
+ ((page + 1) & NAND_BLOCK_MASK(chip)) == 0)
+ chip->cmdfunc(mtd, NAND_CMD_READ0, 0, page + 1);
+ }
+
return 0;
}
@@ -1281,12 +1427,11 @@ static int nand_do_read_ops(struct mtd_info *mtd, loff_t from,
int chipnr, page, realpage, col, bytes, aligned;
struct nand_chip *chip = mtd->priv;
struct mtd_ecc_stats stats;
- int blkcheck = (1 << (chip->phys_erase_shift - chip->page_shift)) - 1;
- int sndcmd = 1;
int ret = 0;
uint32_t readlen = ops->len;
uint32_t oobreadlen = ops->ooblen;
uint8_t *bufpoi, *oob, *buf;
+ uint32_t rstate = NAND_RSTATE_INIT;
stats = mtd->ecc_stats;
@@ -1309,20 +1454,22 @@ static int nand_do_read_ops(struct mtd_info *mtd, loff_t from,
if (realpage != chip->pagebuf || oob) {
bufpoi = aligned ? buf : chip->buffers->databuf;
- if (likely(sndcmd)) {
- chip->cmdfunc(mtd, NAND_CMD_READ0, 0x00, page);
- sndcmd = 0;
- }
+ /* Last read from this chip? */
+ if (((readlen - bytes) == 0) ||
+ (((realpage + 1) & (chip->pagemask)) == 0))
+ rstate |= NAND_RSTATE_LAST;
/* Now read the page into the buffer */
if (unlikely(ops->mode == MTD_OOB_RAW))
ret = chip->ecc.read_page_raw(mtd, chip,
- bufpoi, page);
+ bufpoi, page, &rstate);
else if (!aligned && NAND_SUBPAGE_READ(chip) && !oob)
- ret = chip->ecc.read_subpage(mtd, chip, col, bytes, bufpoi);
+ ret = chip->ecc.read_subpage(mtd, chip, col,
+ bytes, bufpoi,
+ page, &rstate);
else
ret = chip->ecc.read_page(mtd, chip, bufpoi,
- page);
+ page, &rstate);
if (ret < 0)
break;
@@ -1385,12 +1532,6 @@ static int nand_do_read_ops(struct mtd_info *mtd, loff_t from,
chip->select_chip(mtd, -1);
chip->select_chip(mtd, chipnr);
}
-
- /* Check, if the chip supports auto page increment
- * or if we have hit a block boundary.
- */
- if (!NAND_CANAUTOINCR(chip) || !(page & blkcheck))
- sndcmd = 1;
}
ops->retlen = ops->len - (size_t) readlen;
@@ -1455,6 +1596,7 @@ static int nand_read_oob_std(struct mtd_info *mtd, struct nand_chip *chip,
{
if (sndcmd) {
chip->cmdfunc(mtd, NAND_CMD_READOOB, 0, page);
+ nand_wait_cache_load(mtd, chip);
sndcmd = 0;
}
chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
@@ -1480,13 +1622,16 @@ static int nand_read_oob_syndrome(struct mtd_info *mtd, struct nand_chip *chip,
int i, toread, sndrnd = 0, pos;
chip->cmdfunc(mtd, NAND_CMD_READ0, chip->ecc.size, page);
+ nand_wait_cache_load(mtd, chip);
for (i = 0; i < chip->ecc.steps; i++) {
if (sndrnd) {
pos = eccsize + i * (eccsize + chunk);
- if (mtd->writesize > 512)
+ if (nand_is_lp_device(mtd))
chip->cmdfunc(mtd, NAND_CMD_RNDOUT, pos, -1);
- else
+ else {
chip->cmdfunc(mtd, NAND_CMD_READ0, pos, page);
+ nand_wait_cache_load(mtd, chip);
+ }
} else
sndrnd = 1;
toread = min_t(int, length, chunk);
@@ -1552,7 +1697,7 @@ static int nand_write_oob_syndrome(struct mtd_info *mtd,
chip->cmdfunc(mtd, NAND_CMD_SEQIN, pos, page);
for (i = 0; i < steps; i++) {
if (sndcmd) {
- if (mtd->writesize <= 512) {
+ if (!nand_is_lp_device(mtd)) {
uint32_t fill = 0xFFFFFFFF;
len = eccsize;
@@ -1921,6 +2066,7 @@ static int nand_write_page(struct mtd_info *mtd, struct nand_chip *chip,
#ifdef CONFIG_MTD_NAND_VERIFY_WRITE
/* Send command to read back the data */
chip->cmdfunc(mtd, NAND_CMD_READ0, 0, page);
+ nand_wait_cache_load(mtd, chip);
if (chip->verify_buf(mtd, buf, mtd->writesize))
return -EIO;
@@ -2560,7 +2706,11 @@ static void nand_set_defaults(struct nand_chip *chip, int busw)
/* check, if a user supplied command function given */
if (chip->cmdfunc == NULL)
+#ifdef CONFIG_NAND_NO_SMALL_PAGE
+ chip->cmdfunc = nand_command_lp;
+#else
chip->cmdfunc = nand_command;
+#endif
/* check, if a user supplied wait function given */
if (chip->waitfunc == NULL)
@@ -2722,7 +2872,7 @@ static struct nand_flash_dev *nand_get_flash_type(struct mtd_info *mtd,
chip->chip_shift = ffs((unsigned)(chip->chipsize >> 32)) + 31;
/* Set the bad block position */
- chip->badblockpos = mtd->writesize > 512 ?
+ chip->badblockpos = nand_is_lp_device(mtd) ?
NAND_LARGE_BADBLOCK_POS : NAND_SMALL_BADBLOCK_POS;
/* Get chip options, preserve non chip based options */
@@ -2746,9 +2896,15 @@ static struct nand_flash_dev *nand_get_flash_type(struct mtd_info *mtd,
else
chip->erase_cmd = single_erase_cmd;
+#ifdef CONFIG_NAND_NO_SMALL_PAGE
+ if (mtd->writesize <= 512)
+ /* no support for small page devices */
+ return ERR_PTR(-ENODEV);
+#else
/* Do not replace user supplied command function ! */
- if (mtd->writesize > 512 && chip->cmdfunc == nand_command)
+ if (nand_is_lp_device(mtd) && chip->cmdfunc == nand_command)
chip->cmdfunc = nand_command_lp;
+#endif
MTDDEBUG (MTD_DEBUG_LEVEL0, "NAND device: Manufacturer ID:"
" 0x%02x, Chip ID: 0x%02x (%s %s)\n", *maf_id, dev_id,
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 94ad0c0..3d632ee 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -181,7 +181,13 @@ typedef enum {
(NAND_NO_PADDING | NAND_CACHEPRG | NAND_COPYBACK)
/* Macros to identify the above */
+#ifdef CONFIG_NAND_NO_SMALL_PAGE
+#define NAND_CANAUTOINCR(chip) 0
+#else
#define NAND_CANAUTOINCR(chip) (!(chip->options & NAND_NO_AUTOINCR))
+#endif
+#define NAND_BLOCK_MASK(chip) \
+ ((1 << (chip->phys_erase_shift - chip->page_shift)) - 1)
#define NAND_MUST_PAD(chip) (!(chip->options & NAND_NO_PADDING))
#define NAND_HAS_CACHEPROG(chip) ((chip->options & NAND_CACHEPRG))
#define NAND_HAS_COPYBACK(chip) ((chip->options & NAND_COPYBACK))
@@ -269,17 +275,20 @@ struct nand_ecc_ctrl {
uint8_t *calc_ecc);
int (*read_page_raw)(struct mtd_info *mtd,
struct nand_chip *chip,
- uint8_t *buf, int page);
+ uint8_t *buf, int page,
+ uint32_t *rstate);
void (*write_page_raw)(struct mtd_info *mtd,
struct nand_chip *chip,
const uint8_t *buf);
int (*read_page)(struct mtd_info *mtd,
struct nand_chip *chip,
- uint8_t *buf, int page);
+ uint8_t *buf, int page,
+ uint32_t *rstate);
int (*read_subpage)(struct mtd_info *mtd,
struct nand_chip *chip,
uint32_t offs, uint32_t len,
- uint8_t *buf);
+ uint8_t *buf, int page,
+ uint32_t *rstate);
void (*write_page)(struct mtd_info *mtd,
struct nand_chip *chip,
const uint8_t *buf);
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
program, one needs to define where the program will be=20
executed since function calls are using absolute addresses.
The example/Makefile LOAD_ADDR for the selected architecture
should be set to the program's load address.
The steps for running a standalone application using=20
the go command in U-Boot are:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
1- Compile the standalone Hello World Demo with the
"make examples" command from the U-Boot top directory.
This step will run the following commands:
$ avr32-linux-gcc (compile hello_world.c)
$ avr32-linux-ld (link against the linux-uclibc library)
. This is also where the start address is defined
$ avr32-linux-objcopy (to copy to binary or srec format)
2- Load U-Boot program in memory
http://www.denx.de/wiki/DULG/UBootStandalone
According to the LOAD_ADDR, the program should be loaded
at 0x00000000 (in Flash, over U-Boot). This would
overwrite the U-Boot in Flash, already residing in this
sector of memory. I would need to load it in RAM.
$ tftpboot 0x10300000 hello_world.bin
3- Run using the U-Boot "go" command
$ go 0x10300004 This is a test
Problem 1:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
When I change the LOAD_ADDR to 0x10300000, I get a linker error:
avr32-linux-ld: hello_world: Not enough room for program headers =
(allocated 2, need 3)
Segment Sections...
00: LOAD: .rela.dyn
01: LOAD: .text .rodata
02: LOAD: .got
avr32-linux-ld: final link failed: Bad value
(?) Does anyone have an idea what I can do for this?
Steps for running a standalone program using bootm:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Let's assume I was able to run the standalone program usinng the
go command. My next step is to create an image that can be
started using bootm.
1- Compile the standalone Demo with "make examples"
2- Create an image (.img) using mkimage
I assume the address (-a) needs to be the same as the
Makefile LOAD_ADDR and the entry point (-e) will be 4 bytes
after that.
$ mkimage -A avr32 -O u-boot -T standalone -C none \
-a 0x10300000 -e 0x10300004 -n "Hello World" \
-d hello_world.bin hello_world.img
3- Load the image in memory (not the execution place)
$ tftpboot 0x11000000 hello_world.img
4- Run the application
$ bootm
(autostart is set to yes and bootm works when I start linux)
=20
(?) Anything wrong in there?
------=_NextPart_000_0076_01CA823B.73578F80--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
(and the potential number of users of this new feature) don't justify
to apply this patch.
Stefan, what do you think?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Perfection is reached, not when there is no longer anything to add,
but when there is no longer anything to take away.
- Antoine de Saint-Exupery
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
All this is documented on the home page:
http://www.denx.de/wiki/U-Boot/SourceCode
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Confound these ancestors.... They've stolen our best ideas!"
- Ben Jonson
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
#define CONFIG_ENV_ADDR_REDUND (CONFIG_ENV_ADDR + CONFIG_ENV_SECT_SIZE)
above it seems as if the redundant sector was immediately following
the primary one. And
#define CONFIG_ENV_ADDR (CFG_FLASH_BASE + 0x000c0000)
means the offset is 0x000c0000. In this case try the following entries:
/dev/mtd2 0x000C0000 0x20000 0x20000
/dev/mtd2 0x000E0000 0x20000 0x20000
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Never face facts; if you do, you'll never get up in the morning."
- Marlo Thomas
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
to write down your flash layout somewhere and check all your settings -
including the linux mtd partitioning - again, then do some basic
calculations to arrive at the correct parameters. It is not _that_
hard.
Cheers
Detlev
--
System going down at 1:45 this afternoon for disk crashing.
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
#define CONFIG_SYS_FLASH_BASE 0xa0000000
I understand that this is the version where the end user has to deal
with two different address ranges (i. e. "md 10000" would be used
to dump the 2nd 64kB-sector, while "era A0010000" would be needed to
erase the same sector.
Such behaviour is seems unacceptable to me. If my understanding is
corrent, I tend to reject this patch. [Please see explanations in
previous messages for other options to solve this issue.]
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The IQ of the group is the lowest IQ of a member of the group divided
by the number of people in the group.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
write_hwaddr() - it should be made clear that this should be be done
only when absolutely necessary, and then best in board specific code,
The patch should add such a description to the documentation.
Also, we should remove / adapt existing code that performs basicly the
same action.
Thanks.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
That's their goal, remember, a goal that's really contrary to that of
the programmer or administrator. We just want to get our jobs done.
$Bill just wants to become $$Bill. These aren't even marginallly
congruent.
-- Tom Christiansen in <6jhtqk$qls$1@csnews.cs.colorado.edu>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
opt-out. This may seem pragmatic, but it also follows the KISS
principle.
>> The patch should add such a description to the documentation.
>>
> Absolutely. This is an RFC and if we can reach agreement that it's a
> good thing, all the appropriate documentation will be revised.
>> Also, we should remove / adapt existing code that performs basicly the
>> same action.
>>
> Most if not all drivers currently have a private function for
> programming MAC addresses. We can either modify them as time goes by,
> or I'll take on the effort of fixing them all up with the obvious caveat
> that very little testing will be performed by me.
While looking at all this, I came to the conclusion that this is quite a
lot to fix, so I would vote for incremental changes on a per-driver
level. Maybe provide a deprecated #warning or something comparable to
NET_MULTI.
In any case -
Acked-by: Detlev Zundel <dzu@denx.de>
And I will surely help you transform drivers that I can test!
Cheers
Detlev
--
Shin: a device for finding furniture in the dark.
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
reprsent a bit set 1 saying it is a 16 bit device.
Now is this flash chipwidth or flash portwidth?
To my flash chip 16 data lines and 26 address lines are connected.
>> Perhaps a problem of incorrect unlocking addresses (byte vs. word
address)?
Does it mean that unlocking addresses are not correct?
Supoose if chip is in word mode then what should be the portwidth and
chipwidth? What will be the ublocking address then?
I am using an utilty to erase flash and to load uboot image and it is
working fine, only that it copies data at multple locations.
Thanks & regards,
Prakash
On Tue, Apr 13, 2010 at 2:04 PM, Stefan Roese <sr@denx.de> wrote:
> On Tuesday 13 April 2010 08:31:59 prakash bedge wrote:
> > I did it. :)
>
> Good. But what did you change to make it work?
>
> > I am now able to detect the flash. So now I can run the uboot commnads
> i.e
> > flinfo to check the flash information.
> > For this I make use of ST fixup code for M29W128GH in which I changed the
> > codition for chekcing chipwidth.
>
> Are you not using the mainline version of cfi_flash.c? If not, which "fixup
> code" are you referring to (link)?
>
> > To detect the flash I used chipwidth 16 Bits and Portwidth 8 Bits.
>
> Just checking to be sure: Are you using the Spansion chip in byte (8bit) or
> word (16bit) mode? All configurations I have used till now use the word
> mode
> with this chip.
>
> And you really use 8 bit portwidth to access this chip in your SoC?
>
> > But now I am getting the problem in erasing on flash. I gave the erase
> > command to erase the sector but then the sector is not getting erased and
> I
> > am getting the message as flash erased. Same is for chip erase command.
> See
> > the log below
>
> <snip>
>
> > U-Boot $ *saveenv*
> > Saving Environment to Flash...
> > copy old content: sect_addr: FFFA0000 env_addr: FFFA0000 offset:
> 00000000
> > Protect off FFFA0000 ... FFFBFFFF
> > Un-Protecting sectors 509..509 in bank 1
> > Un-Protected 1 sectors
> > *Erasing Flash...Erase Flash from 0xfffa0000 to 0xfffbffff in Bank # 1*
> > fwc addr fffa0aaa cmd aa aa 8bit x 8 bit
> > fwc addr fffa0555 cmd 55 55 8bit x 8 bit
> > fwc addr fffa0aaa cmd 80 80 8bit x 8 bit
> > fwc addr fffa0aaa cmd aa aa 8bit x 8 bit
> > fwc addr fffa0555 cmd 55 55 8bit x 8 bit
> > fwc addr fffa0000 cmd 30 30 8bit x 8 bit
> > *flash_is_busy: 0
> > done*
> > *Erased 1 sectors
> > Writing to Flash... Flash not Erased*
> > Protecting sectors 509..509 in bank 1
> > Protected 1 sectors
> > U-Boot $
> >
> > Also, even by using BDI 3000 Debugger, I am not able to erase the flash
> by
> > giving the proper CFI erase command.
> >
> > mmb 0xfc000000 0xf0
> > mmb 0xfc000aaa 0xaa
> > mmb 0xfc000555 0x55
> > mmb 0xfc000aaa 0x80
> > mmb 0xfc000aaa 0xaa
> > mmb 0xfc000555 0x55
> > mmb 0xff7c0000 0x30
> >
> > But the data is still present.
> >
> > What may be the reason that flash in not getting erased using U-boot as
> > well as BDI debugger?
>
> Hard to tell. Perhaps still a problem of a misconfigured external bus?
> Perhaps
> a problem of incorrect unlocking addresses (byte vs. word address)?
>
> How did you program the U-Boot image into FLASH? Via the BDI3000 "prog"
> command? Is this working correctly?
>
> Cheers,
> Stefan
>
> --
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office at denx.de
>
--000e0cd17992e0906c04841cce50--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
# error Define one of CONFIG_ENV_IS_IN_{EEPROM|FLASH|DATAFLASH|ONENAND|\
-SPI_FLASH|MG_DISK|NVRAM|NOWHERE}
+SPI_FLASH|MG_DISK|NVRAM|MMC|NOWHERE}
I know it is only an error message, but the change seems correct. I have
not found a comment against it ;)
> +#else /* ! ENV_IS_EMBEDDED */
> +env_t *env_ptr;
> +#endif /* ENV_IS_EMBEDDED */
You missed Andy's comment. You have to initialize env_ptr.
> + if (read_env(mmc, CONFIG_ENV_SIZE, CONFIG_ENV_OFFSET, env_ptr))
> + return use_default();
This is still broken, as found by Andy. I cannot find a line where
env_ptr is initialized and then you pass the pointer to the mmc read
function.
Best regards,
Stefano
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
# error Define one of =
CONFIG_ENV_IS_IN_{EEPROM|FLASH|DATAFLASH|ONENAND|\
-SPI_FLASH|MG_DISK|NVRAM|NOWHERE}
+SPI_FLASH|MG_DISK|NVRAM|MMC|NOWHERE}
I know it is only an error message, but the change seems correct. I have =
not found a comment against it ;)
[Ty]: I will add this.
> +#else /* ! ENV_IS_EMBEDDED */
> +env_t *env_ptr;
> +#endif /* ENV_IS_EMBEDDED */
You missed Andy's comment. You have to initialize env_ptr.
[Ty]: This is a global variable. I think that compiler will set it to =
zero for me. Correct me if I'm wrong. Anyway, I will set it to NULL.
> + if (read_env(mmc, CONFIG_ENV_SIZE, CONFIG_ENV_OFFSET, env_ptr))
> + return use_default();
This is still broken, as found by Andy. I cannot find a line where =
env_ptr is initialized and then you pass the pointer to the mmc read =
function.
[Ty]: env_ptr is defined in env_mmc.c and the value is assigned in =
env_common.c. Correct me if I'm wrong.
Best regards,
Stefano
--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
IDE registers within the CF chip
My question is, how do I access such a custom address range within Linux?
I'm looking at the 'OF-platform PATA driver' which appears to be what I
want (a very basic IDE driver) but I am a bit lost on how to set up a
specific base address.
Where should I look for examples of CF cards mapped to specific address spaces?
TIA
Graeme
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
PTBASE is only important, if I load and start the kernel directly, without
the initialization from U-Boot. Am I right?
For information I attach the log I read out of memory at __log_buf
location... although I already posted that on the linuxppc-dev list...
Do you think, that there's maybe a hardware issue because of the timing
errors in the call trace?
Is this the reason for the strange behaviour of the gdb when trying to step
thru the code?
I mean - assuming that the hardware is correct - I should be able to do
"state-of-the-art" code stepping even at early stage like in
early_init_devtree, right?
Thanks!
Matthias
------_=_NextPart_000_01CAEC31.32D0FC70
Content-Type: application/octet-stream;
name="kernel-log.008"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="kernel-log.008"
<4>Invalid tag 0 scanning flattened device tree !=0A=
<4>Invalid tag 0 scanning flattened device tree !=0A=
<4>Invalid tag 0 scanning flattened device tree !=0A=
<4>PHYSICAL_START=3D0x00000000 =0A=
<4>klimit=3D0xc0442000 =0A=
<4>__pa(klimit)=3D0x00442000 =0A=
<4>First lmb_reserved passed!=0A=
<0>------------[ cut here ]------------=0A=
<2>Kernel BUG at c039b3ec [verbose debug info unavailable]=0A=
<4>Oops: Exception in kernel mode, sig: 5 [#1]=0A=
<4>PREEMPT =0A=
<4>Modules linked in:=0A=
<4>NIP: c039b3ec LR: c038a308 CTR: c02e14ac=0A=
<4>REGS: c03ddef0 TRAP: 0700 Not tainted (2.6.29.6-rt23-svn20)=0A=
<4>MSR: 00021000 <ME,CE> CR: 28044024 XER: 00000000=0A=
<4>TASK =3D c03b1508[0] 'swapper' THREAD: c03dc000=0A=
<6>GPR00: 00000001 c03ddfa0 c03b1508 00000000 00400000 00000000 =
00400000 00000000 =0A=
<6>GPR08: 00000000 c0400000 00000104 c03ddfb0 28044022 00000000 =
7ff78e00 00000000 =0A=
<6>GPR16: 7ff494ec 7ff6d648 00000000 00000000 00000000 00000000 =
00000000 00000000 =0A=
<6>GPR24: 00000000 00000000 c03e0000 00000000 00400000 c03e0000 =
c0400000 c03ddfa0 =0A=
<4>NIP [c039b3ec] lmb_reserve+0x30/0x5c=0A=
<4>LR [c038a308] early_init_devtree+0x104/0x2e8=0A=
<4>Call Trace:=0A=
<4>[c03ddfa0] [000000e6] 0xe6 (unreliable)=0A=
<4>[c03ddfb0] [c038a308] early_init_devtree+0x104/0x2e8=0A=
<4>[c03ddfd0] [c038b1dc] machine_init+0x24/0x64=0A=
<4>[c03ddff0] [c000039c] skpinv+0x2c4/0x304=0A=
<4>Instruction dump:=0A=
<4>9421fff0 7c0802a6 93e1000c 90010014 7c3f0b78 7ca03379 7cc83378 =
7ca72b78 =0A=
<4>7c862378 7c651b78 7c000026 54001ffe <0f000000> 3c60c043 38635698 =
38630830 =0A=
<4>---[ end trace 31fd0ba7d8756001 ]---=0A=
<0>Kernel panic - not syncing: Attempted to kill the idle task!=0A=
<1>Unable to handle kernel paging request for data at address =
0x00000010=0A=
<1>Faulting instruction address: 0xc0068824=0A=
<4>Oops: Kernel access of bad area, sig: 11 [#2]=0A=
<4>PREEMPT =0A=
<4>Modules linked in:=0A=
<4>NIP: c0068824 LR: c006d9e8 CTR: c00687c0=0A=
<4>REGS: c03ddad0 TRAP: 0300 Tainted: G D =
(2.6.29.6-rt23-svn20)=0A=
<4>MSR: 00021000 <ME,CE> CR: 28044024 XER: 00000000=0A=
<4>DEAR: 00000010, ESR: 00000000=0A=
<4>TASK =3D c03b1508[0] 'swapper' THREAD: c03dc000=0A=
<6>GPR00: 00000000 c03ddb80 c03b1508 c03ddbd8 00000000 00000000 =
00000000 00000000 =0A=
<6>GPR08: 59bbe120 00000000 00000000 00000000 00000000 00000000 =
7ff78e00 00000000 =0A=
<6>GPR16: 7ff494ec c03ddbd8 c03e31a0 c03e3190 c03e0000 c03e0000 =
00021000 c03ddbd8 =0A=
<6>GPR24: c03e0000 c03e0000 c03ddef0 00000000 00000000 c03b24c8 =
00000000 c03ddb80 =0A=
<4>NIP [c0068824] ktime_get+0x70/0x15c=0A=
<4>LR [c006d9e8] tick_nohz_stop_sched_tick+0x40/0x414=0A=
<4>Call Trace:=0A=
<4>[c03ddb80] [c033282d] 0xc033282d (unreliable)=0A=
<4>[c03ddbd0] [c006d9e8] tick_nohz_stop_sched_tick+0x40/0x414=0A=
<4>[c03ddc20] [c0048000] irq_exit+0x80/0xac=0A=
<4>[c03ddc30] [c000d760] timer_interrupt+0xb8/0x110=0A=
<4>[c03ddc50] [c0011c88] ret_from_except+0x0/0x18=0A=
<4>[c03ddd10] [c0041148] panic+0xb8/0x178=0A=
<4>[c03ddd60] [c004571c] do_exit+0x63c/0x6f8=0A=
<4>[c03ddda0] [c000e65c] die+0x1c0/0x1fc=0A=
<4>[c03dddd0] [c000ea08] _exception+0x168/0x194=0A=
<4>[c03ddec0] [c000efb4] program_check_exception+0x94/0x630=0A=
<4>[c03ddee0] [c0011c3c] ret_from_except_full+0x0/0x4c=0A=
<4>[c03ddfa0] [000000e6] 0xe6=0A=
<4>[c03ddfb0] [c038a308] early_init_devtree+0x104/0x2e8=0A=
<4>[c03ddfd0] [c038b1dc] machine_init+0x24/0x64=0A=
<4>[c03ddff0] [c000039c] skpinv+0x2c4/0x304=0A=
<4>Instruction dump:=0A=
<4>3f20c03e 3e80c03e 3ea0c03e 83d93180 3a5431a0 3a753190 3f00c03e =
73db0001 =0A=
<4>408200bc 813831a8 815431a0 81753190 <81290010> 80130004 83920004 =
7f4a5a14 =0A=
<4>---[ end trace 31fd0ba7d8756002 ]---=0A=
<0>Kernel panic - not syncing: Attempted to kill the idle task!=0A=
------_=_NextPart_000_01CAEC31.32D0FC70--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
somebody else but the original author doing the final checking of the
code.
I would therefore like to continue working as we do now, with Scott as
custodian, at least for the time being. And I will try to keep an eye
on the state of affairs for the NIOS patches.
Please let me know if there are any problems.
Thanks.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Looks clean and obviously correct to me, but then _everything_ I
write always looks obviously correct to me. - Linus Torvalds in
<Pine.LNX.4.10.10012090054360.791-100000@penguin.transmeta.com>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
INCLUDE filename
Include the linker script filename at this point. The file will be
searched for in the current directory, and in any directory specified with
the -L option. You can nest calls to INCLUDE up to 10 levels deep.
and the additional PLATFORM_LIBS does add -L
/home/graeme/Source/U-Boot/x86/board/eNET to the link command. I even tried
PLATFORM_LDFLAGS += -L $(SRCTREE)/board/$(BOARDDIR) which changes the
location of the addition -L in the link command with no luck.
Back to binutils documentation:
-T scriptfile
--script=scriptfile
Use scriptfile as the linker script. This script replaces ld's default
linker script (rather than adding to it), so commandfile must specify
everything necessary to describe the output file. See Scripts. If
scriptfile does not exist in the current directory, ld looks for it in the
directories specified by any preceding `-L' options. Multiple `-T' options
accumulate.
Note the last sentence "Multiple `-T' options accumulate."
Now if I change $(SRCTREE)/config.mk slightly at around line 205 to add an
Implicit Linker Script...
AFLAGS := $(AFLAGS_DEBUG) -D__ASSEMBLY__ $(CPPFLAGS)
LDFLAGS += -T $(SRCTREE)/board/$(BOARDDIR)/board_defs.lds
LDFLAGS += -Bstatic -T $(obj)u-boot.lds $(PLATFORM_LDFLAGS)
ifneq ($(TEXT_BASE),)
LDFLAGS += -Ttext $(TEXT_BASE)
endif
Everything works perfectly fine. But this is a horrible hack. Alas, there
is no mechanism right now to add ld flags before the ones explicitly
defined in config.mk.
Unless I can find out why -L is not working, I'm thinking of adding a new
$(PLATFORM_PRE_LDFLAGS) and changing $(SRCTREE)/config.mk to:
LDFLAGS += $(PLATFORM_PRE_LDFLAGS) -Bstatic -T $(obj)u-boot.lds
$(PLATFORM_LDFLAGS)
I could also but some hacks into the $(BOARD)_config in the Makefile to
patch the linker script but I think that is a bad idea.
Or maybe there is an easier way?
Anyone have any thoughts on this?
Regards,
Graeme
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
mesages, without even reading them.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Conscious is when you are aware of something, and conscience is when
you wish you weren't.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
enable/disable Nand Controller, and bit 6 is used for enable/disable usb
host controller.
so, I guess, this is why "usb start"+"usb stop" will cause "nand xxx" to
failure. because "usb stop" disable the Nand Controll Clock.
the following patch was tested on a s3c2440 board. and It seems work.
Is this correct ? I saw these piece of code been there for so a long time
(from u-boot-1.1.5). I am not very sure now.
Thank you and sorry for my poor english.
/WX
===============================================================================
diff --git a/cpu/arm920t/s3c24x0/usb.c b/cpu/arm920t/s3c24x0/usb.c
index e468ed0..abae409 100644
--- a/cpu/arm920t/s3c24x0/usb.c
+++ b/cpu/arm920t/s3c24x0/usb.c
@@ -46,7 +46,7 @@ int usb_cpu_init(void)
/*
* Enable USB host clock.
*/
- writel(readl(&clk_power->CLKCON) | (1 << 4), &clk_power->CLKCON);
+ writel(readl(&clk_power->CLKCON) | (1 << 6), &clk_power->CLKCON);
return 0;
}
@@ -54,15 +54,14 @@ int usb_cpu_init(void)
int usb_cpu_stop(void)
{
struct s3c24x0_clock_power *clk_power = s3c24x0_get_base_clock_power();
- /* may not want to do this */
- writel(readl(&clk_power->CLKCON) & ~(1 << 4), &clk_power->CLKCON);
+ writel(readl(&clk_power->CLKCON) & ~(1 << 6), &clk_power->CLKCON);
return 0;
}
int usb_cpu_init_fail(void)
{
struct s3c24x0_clock_power *clk_power = s3c24x0_get_base_clock_power();
- writel(readl(&clk_power->CLKCON) & ~(1 << 4), &clk_power->CLKCON);
+ writel(readl(&clk_power->CLKCON) & ~(1 << 6), &clk_power->CLKCON);
return 0;
}
diff --git a/cpu/arm920t/s3c24x0/usb_ohci.c b/cpu/arm920t/s3c24x0/usb_ohci.c
index 5aa8d64..2e6818d 100644
--- a/cpu/arm920t/s3c24x0/usb_ohci.c
+++ b/cpu/arm920t/s3c24x0/usb_ohci.c
@@ -55,14 +55,14 @@
#define min_t(type, x, y) \
({ type __x = (x); type __y = (y); __x < __y ? __x : __y; })
-#undef DEBUG
+#define DEBUG
#ifdef DEBUG
#define dbg(format, arg...) printf("DEBUG: " format "\n", ## arg)
#else
#define dbg(format, arg...) do {} while(0)
#endif /* DEBUG */
#define err(format, arg...) printf("ERROR: " format "\n", ## arg)
-#undef SHOW_INFO
+#define SHOW_INFO
#ifdef SHOW_INFO
#define info(format, arg...) printf("INFO: " format "\n", ## arg)
#else
@@ -1672,7 +1672,7 @@ int usb_lowlevel_init(void)
/*
* Enable USB host clock.
*/
- clk_power->CLKCON |= (1 << 4);
+ clk_power->CLKCON |= (1 << 6);
memset(&gohci, 0, sizeof(struct ohci));
memset(&urb_priv, 0, sizeof(struct urb_priv));
@@ -1709,7 +1709,7 @@ int usb_lowlevel_init(void)
if (hc_reset(&gohci) < 0) {
hc_release_ohci(&gohci);
/* Initialization failed */
- clk_power->CLKCON &= ~(1 << 4);
+ clk_power->CLKCON &= ~(1 << 6);
return -1;
}
@@ -1722,7 +1722,7 @@ int usb_lowlevel_init(void)
err("can't start usb-%s", gohci.slot_name);
hc_release_ohci(&gohci);
/* Initialization failed */
- clk_power->CLKCON &= ~(1 << 4);
+ clk_power->CLKCON &= ~(1 << 6);
return -1;
}
#ifdef DEBUG
@@ -1748,7 +1748,7 @@ int usb_lowlevel_stop(void)
/* call hc_release_ohci() here ? */
hc_reset(&gohci);
/* may not want to do this */
- clk_power->CLKCON &= ~(1 << 4);
+ clk_power->CLKCON &= ~(1 << 6);
return 0;
}
======================================================================================
--0016364179a51b7d66048bae03c8--
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
linux driver, but it was implemented from scratch (ok, maybe not
entirely...) for u-boot. And I see also that musb_core.c in u-boot
contains a small subsets of the functions we can find in the
corresponding file in the linux tree.
After checking the linux driver that supports the ethernet gadget
(musb_gadget.c), it seemed to me that the less effort approach should be
to implements the missing things in the musb_udc.c driver, compared to
port musb_gadget.c from linux. I really started to port it, but I
recognize that I have to change a lot of things even in other files (in
core and so on), and probably this is the best way to break a lot of
boards ;(
So I decided (but it could be not the best solution...any thoughts about
this ?) to take the way to update the current UDC musb_udc.c driver to
support the gadget framework. I am really unsure about this, because the
drawback is to have a completely different implementation from what we
currently see under linux.
As I see, there is support in this driver only for the ep0 endpoint, and
this should be not enough for the ether gadget. I assume we need at
least one bulk endpoint (or two, one for each directions) and then I
should add the missing functions for TX/RX fo all endpoints. But again,
I need also wrapping functions (or rewriting some of them..) for the ep0
endpoints, because the functions in the ops field of the gadget
structure looks like different as what is already implemented.
Probably I used a bad approach to reach my goal. What do you think about
it ?
Regards,
Stefano
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
to "tradbigmips", then even add "-EL" to gcc we still get
EB format.
Signed-off-by: Xiangfu Liu <xiangfu@openmobilefree.net>
---
board/dbau1x00/u-boot.lds | 2 +-
board/gth2/u-boot.lds | 2 +-
board/incaip/u-boot.lds | 2 +-
board/pb1x00/u-boot.lds | 2 +-
board/purple/u-boot.lds | 2 +-
board/qemu-mips/u-boot.lds | 2 +-
examples/standalone/mips.lds | 2 +-
7 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/board/dbau1x00/u-boot.lds b/board/dbau1x00/u-boot.lds
index 9a6cd1b..3c4fbe3 100644
--- a/board/dbau1x00/u-boot.lds
+++ b/board/dbau1x00/u-boot.lds
@@ -24,7 +24,7 @@
/*
OUTPUT_FORMAT("elf32-bigmips", "elf32-bigmips", "elf32-bigmips")
*/
-OUTPUT_FORMAT("elf32-tradbigmips", "elf32-tradbigmips", "elf32-tradbigmips")
+OUTPUT_FORMAT("elf32-tradbigmips", "elf32-tradbigmips", "elf32-tradlittlemips")
OUTPUT_ARCH(mips)
ENTRY(_start)
SECTIONS
diff --git a/board/gth2/u-boot.lds b/board/gth2/u-boot.lds
index e6eee9b..aeb0fcc 100644
--- a/board/gth2/u-boot.lds
+++ b/board/gth2/u-boot.lds
@@ -24,7 +24,7 @@
/*
OUTPUT_FORMAT("elf32-bigmips", "elf32-bigmips", "elf32-bigmips")
*/
-OUTPUT_FORMAT("elf32-tradbigmips", "elf32-tradbigmips", "elf32-tradbigmips")
+OUTPUT_FORMAT("elf32-tradbigmips", "elf32-tradbigmips", "elf32-tradlittlemips")
OUTPUT_ARCH(mips)
ENTRY(_start)
SECTIONS
diff --git a/board/incaip/u-boot.lds b/board/incaip/u-boot.lds
index 9a6cd1b..3c4fbe3 100644
--- a/board/incaip/u-boot.lds
+++ b/board/incaip/u-boot.lds
@@ -24,7 +24,7 @@
/*
OUTPUT_FORMAT("elf32-bigmips", "elf32-bigmips", "elf32-bigmips")
*/
-OUTPUT_FORMAT("elf32-tradbigmips", "elf32-tradbigmips", "elf32-tradbigmips")
+OUTPUT_FORMAT("elf32-tradbigmips", "elf32-tradbigmips", "elf32-tradlittlemips")
OUTPUT_ARCH(mips)
ENTRY(_start)
SECTIONS
diff --git a/board/pb1x00/u-boot.lds b/board/pb1x00/u-boot.lds
index 9a6cd1b..3c4fbe3 100644
--- a/board/pb1x00/u-boot.lds
+++ b/board/pb1x00/u-boot.lds
@@ -24,7 +24,7 @@
/*
OUTPUT_FORMAT("elf32-bigmips", "elf32-bigmips", "elf32-bigmips")
*/
-OUTPUT_FORMAT("elf32-tradbigmips", "elf32-tradbigmips", "elf32-tradbigmips")
+OUTPUT_FORMAT("elf32-tradbigmips", "elf32-tradbigmips", "elf32-tradlittlemips")
OUTPUT_ARCH(mips)
ENTRY(_start)
SECTIONS
diff --git a/board/purple/u-boot.lds b/board/purple/u-boot.lds
index 1881e65..542601a 100644
--- a/board/purple/u-boot.lds
+++ b/board/purple/u-boot.lds
@@ -24,7 +24,7 @@
/*
OUTPUT_FORMAT("elf32-bigmips", "elf32-bigmips", "elf32-bigmips")
*/
-OUTPUT_FORMAT("elf32-tradbigmips", "elf32-tradbigmips", "elf32-tradbigmips")
+OUTPUT_FORMAT("elf32-tradbigmips", "elf32-tradbigmips", "elf32-tradlittlemips")
OUTPUT_ARCH(mips)
ENTRY(_start)
SECTIONS
diff --git a/board/qemu-mips/u-boot.lds b/board/qemu-mips/u-boot.lds
index ad058ca..bd16786 100644
--- a/board/qemu-mips/u-boot.lds
+++ b/board/qemu-mips/u-boot.lds
@@ -24,7 +24,7 @@
/*
OUTPUT_FORMAT("elf32-bigmips", "elf32-bigmips", "elf32-bigmips")
*/
-OUTPUT_FORMAT("elf32-tradbigmips", "elf32-tradbigmips", "elf32-tradbigmips")
+OUTPUT_FORMAT("elf32-tradbigmips", "elf32-tradbigmips", "elf32-tradlittlemips")
OUTPUT_ARCH(mips)
ENTRY(_start)
SECTIONS
diff --git a/examples/standalone/mips.lds b/examples/standalone/mips.lds
index 717b201..63a1c92 100644
--- a/examples/standalone/mips.lds
+++ b/examples/standalone/mips.lds
@@ -24,7 +24,7 @@
/*
OUTPUT_FORMAT("elf32-bigmips", "elf32-bigmips", "elf32-bigmips")
*/
-OUTPUT_FORMAT("elf32-tradbigmips", "elf32-tradbigmips", "elf32-tradbigmips")
+OUTPUT_FORMAT("elf32-tradbigmips", "elf32-tradbigmips", "elf32-tradlittlemips")
OUTPUT_ARCH(mips)
SECTIONS
{
--
1.7.0.4
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
to "tradbigmips", then even add "-EL" to gcc we still get
EB format.
pb1x00 is only used in Little-endian,
so its default endian should be set to LE as well
Signed-off-by: Xiangfu Liu <xiangfu@openmobilefree.net>
Acked-by: Shinya Kuribayashi <skuribay@pobox.com>
</longlog>
---
Hi Wolfgang, ....
v1: ...
v2: ...
board/dbau1x00/u-boot.lds | 2 +-
board/gth2/u-boot.lds | 2 +-
board/incaip/u-boot.lds | 2 +-
board/pb1x00/u-boot.lds | 2 +-
board/purple/u-boot.lds | 2 +-
board/qemu-mips/u-boot.lds | 2 +-
examples/standalone/mips.lds | 2 +-
7 files changed, 7 insertions(+), 7 deletions(-)
:
:
_
I recommend you to read the patch submission guide first.
http://www.denx.de/wiki/U-Boot/Patches
>> With fixing above nits, feel free to add:
>>
>> Acked-by: Shinya Kuribayashi<skuribay@pobox.com>
>>
> (by the way. I manually added this line to email.
> is the another way to add "Acked-by" like "Signed-off-by" is "-s")
Git doesn't support such feature itself, so edit commitlog manually.
As an alternative, StackedGit can append those tags by "stg refresh
--sign/--ack". Just for your information.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
to "tradbigmips", then even add "-EL" to gcc we still get
EB format.
pb1x00 is only used in Little-endian,
so its default endian should be set to LE as well
Signed-off-by: Xiangfu Liu <xiangfu@openmobilefree.net>
Acked-by: Shinya Kuribayashi <skuribay@pobox.com>
---
Hi Wolfgang
sorry, please ignore the my last email about this patch.
Hi Shinya
thanks for your patient on teach me patch stuff.
I will never stop learning :).
v1:
From the document, if set all arguments in "OUTPUT_FORMAT"
to "tradbigmips", then even add "-EL" to gcc we still get
EB format.
v2:
pb1x00 is only used in Little-endian,
so its default endian should be set to LE as well
v3:
only fix the patch format issue.
board/dbau1x00/u-boot.lds | 2 +-
board/gth2/u-boot.lds | 2 +-
board/incaip/u-boot.lds | 2 +-
board/pb1x00/u-boot.lds | 2 +-
board/purple/u-boot.lds | 2 +-
board/qemu-mips/u-boot.lds | 2 +-
examples/standalone/mips.lds | 2 +-
7 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/board/dbau1x00/u-boot.lds b/board/dbau1x00/u-boot.lds
index 9a6cd1b..3c4fbe3 100644
--- a/board/dbau1x00/u-boot.lds
+++ b/board/dbau1x00/u-boot.lds
@@ -24,7 +24,7 @@
/*
OUTPUT_FORMAT("elf32-bigmips", "elf32-bigmips", "elf32-bigmips")
*/
-OUTPUT_FORMAT("elf32-tradbigmips", "elf32-tradbigmips", "elf32-tradbigmips")
+OUTPUT_FORMAT("elf32-tradbigmips", "elf32-tradbigmips", "elf32-tradlittlemips")
OUTPUT_ARCH(mips)
ENTRY(_start)
SECTIONS
diff --git a/board/gth2/u-boot.lds b/board/gth2/u-boot.lds
index e6eee9b..aeb0fcc 100644
--- a/board/gth2/u-boot.lds
+++ b/board/gth2/u-boot.lds
@@ -24,7 +24,7 @@
/*
OUTPUT_FORMAT("elf32-bigmips", "elf32-bigmips", "elf32-bigmips")
*/
-OUTPUT_FORMAT("elf32-tradbigmips", "elf32-tradbigmips", "elf32-tradbigmips")
+OUTPUT_FORMAT("elf32-tradbigmips", "elf32-tradbigmips", "elf32-tradlittlemips")
OUTPUT_ARCH(mips)
ENTRY(_start)
SECTIONS
diff --git a/board/incaip/u-boot.lds b/board/incaip/u-boot.lds
index 9a6cd1b..3c4fbe3 100644
--- a/board/incaip/u-boot.lds
+++ b/board/incaip/u-boot.lds
@@ -24,7 +24,7 @@
/*
OUTPUT_FORMAT("elf32-bigmips", "elf32-bigmips", "elf32-bigmips")
*/
-OUTPUT_FORMAT("elf32-tradbigmips", "elf32-tradbigmips", "elf32-tradbigmips")
+OUTPUT_FORMAT("elf32-tradbigmips", "elf32-tradbigmips", "elf32-tradlittlemips")
OUTPUT_ARCH(mips)
ENTRY(_start)
SECTIONS
diff --git a/board/pb1x00/u-boot.lds b/board/pb1x00/u-boot.lds
index 9a6cd1b..358cc54 100644
--- a/board/pb1x00/u-boot.lds
+++ b/board/pb1x00/u-boot.lds
@@ -24,7 +24,7 @@
/*
OUTPUT_FORMAT("elf32-bigmips", "elf32-bigmips", "elf32-bigmips")
*/
-OUTPUT_FORMAT("elf32-tradbigmips", "elf32-tradbigmips", "elf32-tradbigmips")
+OUTPUT_FORMAT("elf32-tradlittlemips", "elf32-tradbigmips", "elf32-tradlittlemips")
OUTPUT_ARCH(mips)
ENTRY(_start)
SECTIONS
diff --git a/board/purple/u-boot.lds b/board/purple/u-boot.lds
index 1881e65..542601a 100644
--- a/board/purple/u-boot.lds
+++ b/board/purple/u-boot.lds
@@ -24,7 +24,7 @@
/*
OUTPUT_FORMAT("elf32-bigmips", "elf32-bigmips", "elf32-bigmips")
*/
-OUTPUT_FORMAT("elf32-tradbigmips", "elf32-tradbigmips", "elf32-tradbigmips")
+OUTPUT_FORMAT("elf32-tradbigmips", "elf32-tradbigmips", "elf32-tradlittlemips")
OUTPUT_ARCH(mips)
ENTRY(_start)
SECTIONS
diff --git a/board/qemu-mips/u-boot.lds b/board/qemu-mips/u-boot.lds
index ad058ca..bd16786 100644
--- a/board/qemu-mips/u-boot.lds
+++ b/board/qemu-mips/u-boot.lds
@@ -24,7 +24,7 @@
/*
OUTPUT_FORMAT("elf32-bigmips", "elf32-bigmips", "elf32-bigmips")
*/
-OUTPUT_FORMAT("elf32-tradbigmips", "elf32-tradbigmips", "elf32-tradbigmips")
+OUTPUT_FORMAT("elf32-tradbigmips", "elf32-tradbigmips", "elf32-tradlittlemips")
OUTPUT_ARCH(mips)
ENTRY(_start)
SECTIONS
diff --git a/examples/standalone/mips.lds b/examples/standalone/mips.lds
index 717b201..63a1c92 100644
--- a/examples/standalone/mips.lds
+++ b/examples/standalone/mips.lds
@@ -24,7 +24,7 @@
/*
OUTPUT_FORMAT("elf32-bigmips", "elf32-bigmips", "elf32-bigmips")
*/
-OUTPUT_FORMAT("elf32-tradbigmips", "elf32-tradbigmips", "elf32-tradbigmips")
+OUTPUT_FORMAT("elf32-tradbigmips", "elf32-tradbigmips", "elf32-tradlittlemips")
OUTPUT_ARCH(mips)
SECTIONS
{
--
1.7.0.4
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
to "tradbigmips", then even add "-EL" to gcc we still get
EB format.
pb1x00 is only used in Little-endian,
so its default endian should be set to LE as well.
Signed-off-by: Xiangfu Liu <xiangfu@openmobilefree.net>
Acked-by: Shinya Kuribayashi <skuribay@pobox.com>
---
board/dbau1x00/u-boot.lds | 2 +-
board/gth2/u-boot.lds | 2 +-
board/incaip/u-boot.lds | 2 +-
board/pb1x00/u-boot.lds | 2 +-
board/purple/u-boot.lds | 2 +-
board/qemu-mips/u-boot.lds | 2 +-
examples/standalone/mips.lds | 2 +-
7 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/board/dbau1x00/u-boot.lds b/board/dbau1x00/u-boot.lds
index 9a6cd1b..3c4fbe3 100644
--- a/board/dbau1x00/u-boot.lds
+++ b/board/dbau1x00/u-boot.lds
@@ -24,7 +24,7 @@
/*
OUTPUT_FORMAT("elf32-bigmips", "elf32-bigmips", "elf32-bigmips")
*/
-OUTPUT_FORMAT("elf32-tradbigmips", "elf32-tradbigmips", "elf32-tradbigmips")
+OUTPUT_FORMAT("elf32-tradbigmips", "elf32-tradbigmips", "elf32-tradlittlemips")
OUTPUT_ARCH(mips)
ENTRY(_start)
SECTIONS
diff --git a/board/gth2/u-boot.lds b/board/gth2/u-boot.lds
index e6eee9b..aeb0fcc 100644
--- a/board/gth2/u-boot.lds
+++ b/board/gth2/u-boot.lds
@@ -24,7 +24,7 @@
/*
OUTPUT_FORMAT("elf32-bigmips", "elf32-bigmips", "elf32-bigmips")
*/
-OUTPUT_FORMAT("elf32-tradbigmips", "elf32-tradbigmips", "elf32-tradbigmips")
+OUTPUT_FORMAT("elf32-tradbigmips", "elf32-tradbigmips", "elf32-tradlittlemips")
OUTPUT_ARCH(mips)
ENTRY(_start)
SECTIONS
diff --git a/board/incaip/u-boot.lds b/board/incaip/u-boot.lds
index 9a6cd1b..3c4fbe3 100644
--- a/board/incaip/u-boot.lds
+++ b/board/incaip/u-boot.lds
@@ -24,7 +24,7 @@
/*
OUTPUT_FORMAT("elf32-bigmips", "elf32-bigmips", "elf32-bigmips")
*/
-OUTPUT_FORMAT("elf32-tradbigmips", "elf32-tradbigmips", "elf32-tradbigmips")
+OUTPUT_FORMAT("elf32-tradbigmips", "elf32-tradbigmips", "elf32-tradlittlemips")
OUTPUT_ARCH(mips)
ENTRY(_start)
SECTIONS
diff --git a/board/pb1x00/u-boot.lds b/board/pb1x00/u-boot.lds
index 9a6cd1b..358cc54 100644
--- a/board/pb1x00/u-boot.lds
+++ b/board/pb1x00/u-boot.lds
@@ -24,7 +24,7 @@
/*
OUTPUT_FORMAT("elf32-bigmips", "elf32-bigmips", "elf32-bigmips")
*/
-OUTPUT_FORMAT("elf32-tradbigmips", "elf32-tradbigmips", "elf32-tradbigmips")
+OUTPUT_FORMAT("elf32-tradlittlemips", "elf32-tradbigmips", "elf32-tradlittlemips")
OUTPUT_ARCH(mips)
ENTRY(_start)
SECTIONS
diff --git a/board/purple/u-boot.lds b/board/purple/u-boot.lds
index 1881e65..542601a 100644
--- a/board/purple/u-boot.lds
+++ b/board/purple/u-boot.lds
@@ -24,7 +24,7 @@
/*
OUTPUT_FORMAT("elf32-bigmips", "elf32-bigmips", "elf32-bigmips")
*/
-OUTPUT_FORMAT("elf32-tradbigmips", "elf32-tradbigmips", "elf32-tradbigmips")
+OUTPUT_FORMAT("elf32-tradbigmips", "elf32-tradbigmips", "elf32-tradlittlemips")
OUTPUT_ARCH(mips)
ENTRY(_start)
SECTIONS
diff --git a/board/qemu-mips/u-boot.lds b/board/qemu-mips/u-boot.lds
index ad058ca..bd16786 100644
--- a/board/qemu-mips/u-boot.lds
+++ b/board/qemu-mips/u-boot.lds
@@ -24,7 +24,7 @@
/*
OUTPUT_FORMAT("elf32-bigmips", "elf32-bigmips", "elf32-bigmips")
*/
-OUTPUT_FORMAT("elf32-tradbigmips", "elf32-tradbigmips", "elf32-tradbigmips")
+OUTPUT_FORMAT("elf32-tradbigmips", "elf32-tradbigmips", "elf32-tradlittlemips")
OUTPUT_ARCH(mips)
ENTRY(_start)
SECTIONS
diff --git a/examples/standalone/mips.lds b/examples/standalone/mips.lds
index 717b201..63a1c92 100644
--- a/examples/standalone/mips.lds
+++ b/examples/standalone/mips.lds
@@ -24,7 +24,7 @@
/*
OUTPUT_FORMAT("elf32-bigmips", "elf32-bigmips", "elf32-bigmips")
*/
-OUTPUT_FORMAT("elf32-tradbigmips", "elf32-tradbigmips", "elf32-tradbigmips")
+OUTPUT_FORMAT("elf32-tradbigmips", "elf32-tradbigmips", "elf32-tradlittlemips")
OUTPUT_ARCH(mips)
SECTIONS
{
--
1.7.0.4
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
the maximum speed reachable using cpufreq"
> As far as I understand you, it is a maximum frequency, correct? The
> absolute limit is given by the labeling of individual parts - but for
> whatever reason - maybe the user also wants to influence that.
The user does not "influence" this rating. Do you call it influenced by
user because there is an environment variable to set this? The way
the patch is written it can also be specified in the board configuration
header file. The environment variable is just a convenience option. The
expectation is that the user will rebuild U-Boot based on which silicon
he is using so he doesn't have to set the environment variable at all.
So, the user is just "configuring" the software according to the
hardware. There no user "influence" on the silicon speed grade.
> So why
> not call it "maximum operating frequency"?
Yes, that's a correct description. Where do you want to call it such?
> If you really do have to pass the informatino to the kernel (why does no
> other SoC in ARM use such a aconcept yet? How do they handle multiple
> frequencies?) and because I'm not too familiar with the ATAGs (flat
> device trees are far superior), let's see what the current Linux kernel
> declares. [Studying the code] Ah, in arch/avr32/include/asm/setup.h
> someone came up with the idea to create a generic ATAG_CLOCK tag. That
> does look promising - it scales, i.e. one can specify multiple "clocks"
> (i.e. core, bus, whatever) and it uses long long so it will not overflow
> in the near future.
>
> Why not reuse such an existing concept which matches your usage much
> better (arch/arm/include/asm/setup.h comments ATAG_REVISION as "board
> revision")?
Note again that we are not trying to pass information regarding the
current clock speed here. We are passing information regarding a silicon
characteristic. The DA850 kernel reads the system registers directly to
find out the clock speed. Even in the avr32 platform this ATAG is unused.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
static int __init parse_tag_clock(struct tag *tag)
{
/*
* We'll figure out the clocks by peeking at the system
* manager regs directly.
*/
return 0;
}
__tagtable(ATAG_CLOCK, parse_tag_clock);
Anyway, I can see the talk of "speed" and board "revision" has created
some confusion.
What if instead of "maxspeed", I named the variable as "soctype" and had
values like "am18x-300", "am18x-375", "am18x-450" passed to it?
It means the same thing, but will probably create a different perception?
I wanted to avoid taking this route since the same code supports
different SoC part numbers and passing part number specific values
can cause some confusion for users of other parts. That is all.
The question is why should a new ARM ATAG be introduced if an existing
one is good enough for the purpose?
> >> Using HZ would probably settle the "which unit is used" question, but
> >> the code would overflow at ~4.2 GHz and the numbers will be large and
> >> entry errors have to be expected. As Hz is too fine for CPU frequenci=
es
> >> this would lead me to use either kilo or megaherz but I would express =
it
> >> in the variable name.
> >
> > I don't have a very strong inclination on this so I will go with
> > your suggestion.
>
> Did you check if we can learn from other code already present in U-Boot?
>
> Let's see - in arch/mips/cpu/incaip_clock.c there is an environment
> variable "cpuclk" which is in MHz. Aha, the 8xx parts also use a
> "cpuclk" environment variable which is even documented in
> doc/README.MPC866.
Yes, U-Boot online documentation also has a reference to it:
http://www.denx.de/wiki/view/DULG/UBootEnvVariables.
>
> Ah, now I'm in a tight spot - contrary to my previous writings when I
> belived we did not have a comparably construct - I would now vote to use
> exactly the same name and thus unfortunately not use a "_mhz" suffix but
> still specify the clock in mhz.
You mean replace "maxspeed" by "cpuclk"? As I have noted a number of times
before, we are not passing the cpu clock speed here. That information kerne=
l
directly reads from system registers. No need to pass it from U-Boot. The
example you are giving is not the right comparison.
The cpuclk variable in MPC866 is used to set the current cpu speed and pass=
that
information to kernel. I had a feeling this confusion is going to arise and
that is why I noted in my patch description:
"
Note that U-Boot itself does not set the CPU rate. The CPU
speed is setup by a primary bootloader ("UBL"). The rate setup
by UBL could be different from the maximum speed grade of the
device.
"
Thanks,
Sekhar
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
## Loading Ramdisk Image at ff9a0000 ...
Image Name: Ramdisk
Image Type: ARM Linux RAMDisk Image (gzip compressed)
Data Size: 5240600 Bytes = 5 MB
Load Address: 00800000
Entry Point: 00800000
Verifying Checksum ... OK
And from mine:
DNS323B1> setenv verify no
DNS323B1> run bootcmd
## Booting kernel from Legacy Image at ff820000 ...
Image Name: Linux-2.6.12.6-arm1
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1490204 Bytes = 1.4 MiB
Load Address: 00008000
Entry Point: 00008000
## Loading init Ramdisk from Legacy Image at ff9a0000 ...
Image Name: Ramdisk
Image Type: ARM Linux RAMDisk Image (gzip compressed)
Data Size: 5240600 Bytes = 5 MiB
Load Address: 00800000
Entry Point: 00800000
Loading Kernel Image ... OK
OK
0x800000 is well within the 64MB that the device has.
Regards,
Rogan
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
^^^^^^^this is already odd
X-Mozilla-Status: 0003
X-Mozilla-Status2: 00000000
Return-Path: <u-boot-bounces@lists.denx.de>
Delivery-Date: Sun, 29 Aug 2010 13:54:56 +0200
Received: from theia.denx.de (theia.denx.de [85.214.87.163])
...
Received: from andreas-mbp.erlangen.biessmann.tld ([188.110.235.134])
by mx.google.com with ESMTPS id a48sm9995891eei.12.2010.08.29.04.54.33
(version=SSLv3 cipher=RC4-MD5); Sun, 29 Aug 2010 04:54:36 -0700 (PDT)
From: =?UTF-8?q?Andreas=20Bie=C3=9Fmann?= <andreas.devel@googlemail.com>
To: js_at_ng at scharsoft.de
Date: Sun, 29 Aug 2010 13:54:16 +0200
Message-Id: <1283082856-82859-1-git-send-email-andreas.devel@googlemail.com>
X-Mailer: git-send-email 1.7.2.2
MIME-Version: 1.0
Cc: u-boot at lists.denx.de
Subject: [U-Boot] [PATCH] at91_emac.h: fix typo in register definition
X-BeenThere: u-boot at lists.denx.de
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: U-Boot discussion <u-boot.lists.denx.de>
List-Unsubscribe: <http://lists.denx.de/mailman/listinfo/u-boot>,
<mailto:u-boot-request@lists.denx.de?subject=unsubscribe>
List-Archive: <http://lists.denx.de/pipermail/u-boot>
List-Post: <mailto:u-boot@lists.denx.de>
List-Help: <mailto:u-boot-request@lists.denx.de?subject=help>
List-Subscribe: <http://lists.denx.de/mailman/listinfo/u-boot>,
<mailto:u-boot-request@lists.denx.de?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
^^^^^^ SOMEWHERE this got added..??!!??
Sender: u-boot-bounces at lists.denx.de
Errors-To: u-boot-bounces at lists.denx.de
X-UI-Junk: AutoNotJunk -999 (UWL);
V01:kVTWu2o7:n/dRKR8q2mLw2neqNYB2VOEAdY83mL/SkCvDJaRkwqv7AuJgS9D
iO6n89pJE08XJIzZqsh8dZK2kR6Wh8Jax0XeN5TcTMPzHZTn3ZIVPDRBGu39Mxkx
P4ycvYG1SNPQi7ipoUxr+k8c1oHU3c43T71YwisN4qJddFx1xspcjGea82oy2oth
ip3NFogITh6Q8qOnogrv7trspflWXycC0CLad3ubw8O6wkwuyK6Je6EbyYlYIdwx
M2jg4v+NBrzG8qiUXS32idBDWs4eBggIWlRSFytJEv+/5gomLi+JIEyB8s8Y+jAs
NwoIBbsdXhE9C
X-Nemesis-Spam: whitelist
Envelope-To: u-boot at emk-elektronik.de
U2lnbmVkLW9mZi1ieTogQW5kcmVhcyBCaWXDn21hbm4gPGFuZHJlYXMuZGV2ZWxAZ29vZ2xlbWFp
bC5jb20+Ci0tLQogYXJjaC9hcm0vaW5jbHVkZS9hc20vYXJjaC1hdDkxL2F0OTFfZW1hYy5oIHwg
ICAgMiArLQogMSBmaWxlcyBjaGFuZ2VkLCAxIGluc2VydGlvbnMoKyksIDEgZGVsZXRpb25zKC0p
CgpkaWZmIC0tZ2l0IGEvYXJjaC9hcm0vaW5jbHVkZS9hc20vYXJjaC1hdDkxL2F0OTFfZW1hYy5o
IGIvYXJjaC9hcm0vaW5jbHVkZS9hc20vYXJjaC1hdDkxL2F0OTFfZW1hYy5oCmluZGV4IDQ1YWUz
MzMuLjBlMmZmNzggMTAwNjQ0Ci0tLSBhL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2FyY2gtYXQ5MS9h
dDkxX2VtYWMuaAorKysgYi9hcmNoL2FybS9pbmNsdWRlL2FzbS9hcmNoLWF0OTEvYXQ5MV9lbWFj
LmgKQEAgLTYxLDcgKzYxLDcgQEAgdHlwZWRlZiBzdHJ1Y3QgYXQ5MV9lbWFjIHsKIAl1MzIJIHJl
c2VydmVkMlszXTsKIAl1MzIJIGhzaDsKIAl1MzIJIGhzbDsKLQl1MzIJIHNoMWw7CisJdTMyCSBz
YTFsOwogCXUzMgkgc2ExaDsKIAl1MzIJIHNhMmw7CiAJdTMyCSBzYTJoOwotLSAKMS43LjIuMgoK
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KVS1Cb290IG1h
aWxpbmcgbGlzdApVLUJvb3RAbGlzdHMuZGVueC5kZQpodHRwOi8vbGlzdHMuZGVueC5kZS9tYWls
bWFuL2xpc3RpbmZvL3UtYm9vdAo=
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
resetvec address points to 0xefff_fffc.
For all 85xx processor except(MPC8572) the resetvec = 0xffff_fffc,
Text_Base = 0xfff8_0000
For p4080 the resetvec = 0xefff_fffc,Text_Base = 0xeff8_0000
For p4080 why the resetvec and Text_Base address is different from the other
85xx processor ?.
Kumar Gala-3 wrote:
>
>
> On Sep 8, 2010, at 8:48 AM, MArunKumar wrote:
>
>>
>> Hi
>> Im new to u-boot. Right now im in the process of customizing P4080DS(RDB)
>> to
>> my board.
>> My doubt is, for P4080 the reset vec address is 0x0_ffff_fffc.
>> 1) But in the config.mk file it is mentioned as 0xefff_fffc wat it mean?.
>
> This is because the link address is 0xeff80000. We end up running at this
> address after the initial boot.
>
> - k
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
>
--
View this message in context: http://old.nabble.com/P4080-Reset-Vector-tp29641685p29706386.html
Sent from the Uboot - Users mailing list archive at Nabble.com.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
Sorry, I don't have more time right now for real debugging :-(
Note: when setting TEXT_BASE = 0, the board does not print any
messages at all. I can't really tell where it's going kaboom.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Superior ability breeds superior ambition.
-- Spock, "Space Seed", stardate 3141.9
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
but cpu and fpga interface has nothing in common (though I must admit
the names are similar and might lead to some confusion ;)).
> Please factor out such common code. Eventually, a single
> board entry with two configurations is sufficient?
Nice idea. Is there a way to do this with boards.cfg?
> Best regards,
>
> Wolfgang Denk
Cheers
Dirk
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
At the end we should have a clean "atmel_usart" that works for "RM", too.
Maybe we can make it happen that the "init" function gets the address of
the USART to use, similar to other (lan) interfaces, instead of odd defines
and #ifdef cascades that hardcode addresses.
For testing purposes it would be "nice" if u-boot could have several uarts
initialized and a simple "talk" command that patches serial data bidirectionally
from console to any usart available (for example to simply check a connected
GPS receiver or modem for function. "talk usart3 4800n81 0x1a" or alike ;)
> Eg. at91rm9200ek and at91sam9260ek (i can get one from time to time) or
> your at91sam9263 based boards. I also think a lot of avr32 stuff could
> merge into the same drivers ... will have a look for that in future.
My board (top9000) is AT91SAM9XE based (thats a flavout of the 9260, notice
that it uses at91sam9260.h in where "*XE*" changes a few defines.
Thats probably the only AT91SAM9 board that works with relocation. The port is in the
"WIP" branch of "u-boot-atmel", if you want to have a look at it. I don't think
the top9000 port is ready for mainline yet (there are still going to be small changes),
but I could provide a patch if Wolfgang agrees to a premature version.
> I do all of this in spare time at home therefore I go only little steps
So do I (not being paid for extra work beyond getting the top9000 working).
> ... But currently are all arm boards broken (relocation), therefore is
> now the time to introduce new interfaces. Do you think the same way?
Of course. Its just alot of work. And we should plan that to avoid double work ;)
regards
Reinhard
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
to the official repository at denx.de. "git request-pull" generates this ou=
tput in this case.
You are right Stefan
For me, I pull from internal mirror repository whereas push to original rep=
ository.
Regards..
Prafulla . .
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
needs to visit an external website to even _compile_ the code. Let
alone copying stuff to and from, hex dumping it etc. This is not
acceptable.
>> > + make P4080DS_PBL_BOOT_INDIRECT_config
>> > + make CROSS_COMPILE=powerpc-none-linux-gnuspe- all
>> > + xxd u-boot.bin > u-boot.xxd
>>
>> > +3. Producing PBI commands
>> > +Switch to tab "PBI" and paste commands below into text field
> (please note these
>> > +commands are for CPC1 used as SRAM only, change corresponding
> register setting
>> > +if CPC2 need to be used as SRAM), then choose "ACS File (XXD Object
> Dump)",
>> > +change Offset to "f80000", and click "Browse" to select the
> u-boot.xxd file
>> > +produced in step 2, and click "Add PBI Data", after it finished,
> paste
>> > +"09138000 00000000" and "091380c0 00000000" at the end.
>>
>> This must be a bad joke.
>>
>> Can you not provide a plain and simple AUTOMATIC way to get this
>> result? some plain stupid command line tool? Something that works as
>> a simple "make XXX" ? So it can be scripted / automatized / used?
>
> Yes, a simple C tool to take an existing PBL or RCW dump and "espi-ize"
> it into a PBL dump would be nice. The user will still need to acquire
> the existing RCW manually. This only needs to be done once on a board;
> it's not part of building a U-Boot image.
@Scott: What is meant by "acquiring the existing RCW"? Can't we have a
tool that is fed with a value for RCW?
> [Xie Shaohui] A simple C tool will make things more complex, the
> pbl_image_tool does the same thing and it is irreplaceable, something
No tool is irreplaceable, ever.
> like RCW has to be produced manually, and because there is no
> near-universal default RCW, this README took a basic assumption that
> user already can boot from NOR flash, so user can reuse the RCW dump of
> NOR u-boot with change "PBI_SRC" and "BOOT_LOC" only.
>
> This README describes how to build an Image can be used by PBL (pre-boot
> loader), building u-boot image is the first step, then RCW, PBI
> commands, XXD dump of u-boot.bin, the tool will combine the RCW and PBI
> and XXD dump together to produce the PBL XXD file, suppose the PBL XXD
> file is saved as x.xxd, we need to run "xxd -r x.xxd > pbl_image.bin" to
> produce the final PBL Image. Take a look at the whole process, I see no
> way it can be scripted / automatized.
I said it once before, look at how kwbimage wraps up u-boot.bin into
such an "augmented" image. If the Marvell guys can do this for their
platform, I see no reason why this cannot be done for your platform.
Cheers
Detlev
--
coding notes: the en/decryption routines each use 6 necessary register
variables, with 4 being actively used at once during the inner
iterations. if you don't have 4 register variables get a new machine.
-- Dana L. How (descore-readme.txt)
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
can't be used.
Actually we need the auto-negotiation enabled for almost all Freescale =
reference boards such as P2020DS, MPC8572DS and P1/P2 RDB boards. If we =
disable the auto-negotiation on these boards, the SGMII link won't work. =
So I guess it might be more common to use auto-negotiation, and a fixed =
1000M link is more like a special case. I'm not sure what's the =
recommended way for SGMII PHY interconnect though.
- Leo
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
finds the (first) active ethernet device - active in a sense of connected o=
r usable or whatever.
Although eTSEC0 is the only connected port on our device, it comes up with =
UEC0 - so, even if this interface in "on" in some way, this does not help h=
ere.
How can I force ethact to be eTSEC0 (or whichever I want), without tamperin=
g U-Boot base files?
Thanks
Matthias
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
disassembling the executable code to make sure of what the assembler
did.
The answer depends on what mode the assembler is in. For MIPS
assembler there is a 'reorder mode' where the assembler will fill in
the branch delay slot for you or place a nop if necessary, and the
next instruction in the source is really the one after the delay slot,
or there is noreorder mode where the next instruction after the branch
is what is put in the delay slot.
Normally the assembler runs in reorder mode, and you use a '.set
reorder' and '.set noreorder' to switch between them. Noreorder mode
is commonly used in code that requires precise control of where
instructions get executed (cache & tlb handling)
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
--gc-sections
--no-gc-sections
Enable garbage collection of unused input sections. It is ignored on targets that do not support this option. The default behaviour (of not performing this garbage collection) can be restored by specifying --no-gc-sections on the command line.
--gc-sections decides which input sections are used by examining symbols and relocations. The section containing the entry symbol and all sections containing symbols undefined on the command-line will be kept, as will sections containing symbols referenced by dynamic objects. Note that when building shared libraries, the linker must assume that any visible symbol is referenced. Once this initial set of sections has been determined, the linker recursively marks as used any section referenced by their relocations. See --entry and --undefined.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
-ffunction-sections
-fdata-sections
Place each function or data item into its own section in the output file if the target supports arbitrary sections. The name of the function or the name of the data item determines the section's name in the output file.
Use these options on systems where the linker can perform optimizations to improve locality of reference in the instruction space. Most systems using the ELF object format and SPARC processors running Solaris 2 have linkers with such optimizations. AIX may have these optimizations in the future.
Only use these options when there are significant benefits from doing so. When you specify these options, the assembler and linker will create larger object and executable files and will also be slower. You will not be able to use "gprof" on all systems if you specify this option and you may have problems with debugging if you specify both this option and -g.
Signed-off-by: Luigi 'Comio' Mantellini <luigi.mantellini@idf-hit.com>
---
config.mk | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/config.mk b/config.mk
index c6d6f7b..591b490 100644
--- a/config.mk
+++ b/config.mk
@@ -23,6 +23,10 @@
#########################################################################
+comma := ,
+empty :=
+space := $(empty) $(empty)
+
ifneq ($(OBJTREE),$(SRCTREE))
ifeq ($(CURDIR),$(SRCTREE))
dir :=
@@ -97,6 +101,8 @@ HOSTCFLAGS += -pedantic
#
cc-option = $(shell if $(CC) $(CFLAGS) $(1) -S -o /dev/null -xc /dev/null \
> /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi ;)
+ld-option = $(shell if $(CC) -Wl$(comma)$(1) -nostdlib -xc /dev/null -o /dev/null \
+ > /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi ;)
#
# Include the make variables (CC, etc...)
@@ -191,6 +197,13 @@ endif
CFLAGS += $(call cc-option,-fno-stack-protector)
+# Create a section for each function or data (useful for sections garbage collector)
+CFLAGS += $(call cc-option,-ffunction-sections)
+CFLAGS += $(call cc-option,-fdata-sections)
+
+# Sections garbage collector
+LDFLAGS += $(call ld-option,--gc-sections)
+
# $(CPPFLAGS) sets -g, which causes gcc to pass a suitable -g<format>
# option to the assembler.
AFLAGS_DEBUG :=
--
1.7.3
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
--gc-sections
--no-gc-sections
Enable garbage collection of unused input sections. It is ignored on targets
that do not support this option. The default behaviour (of not performing this
garbage collection) can be restored by specifying --no-gc-sections on the
command line.
--gc-sections decides which input sections are used by examining symbols and
relocations. The section containing the entry symbol and all sections
containing symbols undefined on the command-line will be kept, as will sections
containing symbols referenced by dynamic objects. Note that when building shared
libraries, the linker must assume that any visible symbol is referenced. Once
this initial set of sections has been determined, the linker recursively marks
as used any section referenced by their relocations. See --entry and --undefined.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
-ffunction-sections
-fdata-sections
Place each function or data item into its own section in the output file if the
target supports arbitrary sections. The name of the function or the name of the
data item determines the section's name in the output file.
Use these options on systems where the linker can perform optimizations to
improve locality of reference in the instruction space. Most systems using the
ELF object format and SPARC processors running Solaris 2 have linkers with such
optimizations. AIX may have these optimizations in the future.
Only use these options when there are significant benefits from doing so. When
you specify these options, the assembler and linker will create larger object
and executable files and will also be slower. You will not be able to use "gprof"
on all systems if you specify this option and you may have problems with
debugging if you specify both this option and -g.
Signed-off-by: Luigi 'Comio' Mantellini <luigi.mantellini@idf-hit.com>
---
config.mk | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/config.mk b/config.mk
index c6d6f7b..94ca033 100644
--- a/config.mk
+++ b/config.mk
@@ -97,6 +97,8 @@ HOSTCFLAGS += -pedantic
#
cc-option = $(shell if $(CC) $(CFLAGS) $(1) -S -o /dev/null -xc /dev/null \
> /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi ;)
+ld-option = $(shell if $(CC) -Wl,$(1) -nostdlib -xc /dev/null -o /dev/null \
+ > /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi ;)
#
# Include the make variables (CC, etc...)
@@ -191,6 +193,13 @@ endif
CFLAGS += $(call cc-option,-fno-stack-protector)
+# Create a section for each function or data (useful for sections garbage collector)
+CFLAGS += $(call cc-option,-ffunction-sections)
+CFLAGS += $(call cc-option,-fdata-sections)
+
+# Enable sections garbage collector
+LDFLAGS += $(call ld-option,--gc-sections)
+
# $(CPPFLAGS) sets -g, which causes gcc to pass a suitable -g<format>
# option to the assembler.
AFLAGS_DEBUG :=
--
1.7.3
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
=0A
=0ADear God=E2=80=99s elect,
=0A
=0AI am writing this mail wishing it to meet you in good health, for myself=
is in a very bad health condition in which I wake up every morning with ey=
es full of tears. I am Mrs. Nadia Faruk. Am contacting you from a hospital =
bed here in Tunisia. I am telling you this as I am left with no option but =
to be open to you. Am married to late Mr. Usman Faruk who until his death i=
n October 2005 was a solid mineral engineer with the Burkina Faso mining co=
-operation. We were married for thirteen years without any child until the =
day he collapse and died in his office due to heart related problem and sin=
ce then I decided not to marry again.
=0A
=0AWhen my husband was alive he deposited the sum of five million five hund=
red thousand euro (=E2=82=AC5.5 million) with the African development bank =
in Ouagadougou the capital city of Burkina Faso. He made this deposit for e=
xportation of gold from the Burkina Faso mining co-operation before his unt=
imely death.
=0A
=0ANow I will die of cancer for my doctor has made it clear that I will not=
last another six months and For reasons which I do not know, my husband re=
latives never supported my marriage with their brother and now they wish th=
at I die sooner and keep pestering me with questions to know if I have any =
assets so they can take it and share among themselves.
=0A
=0AThe cancer is not the main problem but the partial stroke that sometimes=
hinders me from reading, but to god be the glory. Having considered my pos=
ition, I have decided to hand the money over to you with instruction that y=
ou take 30% for yourself and your family and use 70% and build an orphanage=
home for the motherless babies because I am an orphan and have no relative=
s.
=0A
=0APlease you must follow this instruction or we will forget about it for a=
m doing it so that heaven will receive my soul where I know my husband is a=
lready waiting for me.
=0A
=0AOnce I hear from you then I will direct you on what to do to get all the=
help you may need.
=0A
=0AI will be waiting for your response and do have a nice day.
=0A
=0AMrs. Nadia faruk=0A=0A=0A
--0-646423091-1292745836=:91863--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
/INCLUDE directory to be the first in list to search for header files
while preprocessing and -isystem flag asks the compiler to consider the
cross compiler's as the system directory or search for system headers.
=20
Now I went make to common.h file which is throwing the error given above
and observed that config.h is defined in angle brackets:=20
=20
i.e. #include <config.h>
=20
So what I feel is happening here is that the compiler only searches its
own include directory for headers since the files are in < > brackets.
When I copy all the files in the uboot /include directory to the
compiler's include the build process starts while fails at some point
since some autogenerated header files are created in the u-boot/include
by default and needs to be moved to the compiler's include each time
proceed. =20
=20
I could go about changing the #include <config.h> to #include "config.h"
but this is going to be very tedious and time consuming as the entire
u-boot code needs to be changed for this.
=20
I tried various combinations of gcc flags for the variable CPPFLAGS, all
failed for reasons which I was able to trace back.=20
=20
Has this condition been observed before and is there any work around for
it? Also, please correct me if my understanding is wrong. I am at
crucial point in my project would be delighted to have support at the
earliest.=20
=20
Regards,
Shyama
=20
------_=_NextPart_001_01CBA7FE.140E35D3--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
/INCLUDE directory to be the first in list to search for header files
while preprocessing and -isystem flag asks the compiler to consider the
cross compiler's as the system directory or search for system headers.
=20
Now I went make to common.h file which is throwing the error given above
and observed that config.h is defined in angle brackets:=20
=20
i.e. #include <config.h>
=20
So what I feel is happening here is that the compiler only searches its
own include directory for headers since the files are in < > brackets.
When I copy all the files in the uboot /include directory to the
compiler's include the build process starts while fails at some point
since some autogenerated header files are created in the u-boot/include
by default and needs to be moved to the compiler's include each time
proceed. =20
=20
I could go about changing the #include <config.h> to #include "config.h"
but this is going to be very tedious and time consuming as the entire
u-boot code needs to be changed for this.
=20
I tried various combinations of gcc flags for the variable CPPFLAGS, all
failed for reasons which I was able to trace back.=20
=20
Has this condition been observed before and is there any work around for
it? Also, please correct me if my understanding is wrong. I am at
crucial point in my project would be delighted to have support at the
earliest.=20
=20
Regards,
Shyama
=20
=20
------_=_NextPart_001_01CBA7FC.91DDF527--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
/INCLUDE directory to be the first in list to search for header files
while preprocessing and -isystem flag asks the compiler to consider the
cross compiler's as the system directory or search for system headers.
Now I went make to common.h file which is throwing the error given above
and observed that config.h is defined in angle brackets:=20
i.e. #include <config.h>
So what I feel is happening here is that the compiler only searches its
own include directory for headers since the files are in < > brackets.
When I copy all the files in the uboot /include directory to the
compiler's include the build process starts while fails at some point
since some autogenerated header files are created in the u-boot/include
by default and needs to be moved to the compiler's include each time
proceed. =20
I could go about changing the #include <config.h> to #include "config.h"
but this is going to be very tedious and time consuming as the entire
u-boot code needs to be changed for this.
I tried various combinations of gcc flags for the variable CPPFLAGS, all
failed for reasons which I was able to trace back.=20
Has this condition been observed before and is there any work around for
it? Also, please correct me if my understanding is wrong. I am at
crucial point in my project would be delighted to have support at the
earliest.=20
Regards,
Shyama
=20
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
ient, but I am still missing/needing something.
Cheers
Matthias
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
ed=A0and my <pc> is stopping at=A030008010 address. But I was not able to l=
ocate this address in System.map. My System.map starts from=A033d80000 and =
ends in=A033de3918.=A0
Is there any software package tool for JTAG debugging.=A0
thanks & regardsGIGIN
--- On Fri, 7/1/11, Pankaj Pandey <pankaj.embedded@gmail.com> wrote:
From: Pankaj Pandey <pankaj.embedded@gmail.com>
Subject: Re: [U-Boot] Entry point for uncompressed kernel image
To: "Gigin Jose" <gigin_jose@yahoo.co.in>
Date: Friday, 7 January, 2011, 11:58 AM
hi...can you please share me ur bootargs plz...for debugging=A0 this issue =
u need to connect ur board with hardware debugger through=20
JTAG and start debugging from kernel entry point which at ./arch/arm/kernel=
/head.S
=0ARegards,
Pankaj Pandey
On Fri, Jan 7, 2011 at 3:15 PM, Gigin Jose <gigin_jose@yahoo.co.in> wrote:
=0AHi ,=A0
=0AI am getting an exception once I try to boot the image with bootm comman=
d. =A0
=0ABoardcon> bootm 30008000
=0A## Booting image at 30008000 ...
=0A=A0=A0 Image Name:
=0A=A0=A0=A0
=0A=A0=A0 Created: =A0 =A0 =A02011-01-07 =A0 6:04:55 UTC
=0A=A0=A0 Image Type: =A0 ARM Linux Kernel Image (uncompressed)
=0A=A0=A0 Data Size: =A0 =A03035360 Bytes =3D =A02.9 MB
=0A=A0=A0 Load Address: 30008000
=0A=A0=A0 Entry Point: =A030008000
=0A=A0=A0 Verifying Checksum ... OK
=0A=A0=A0 XIP Kernel Image ... OK
=0A
=0A=A0initrd_start:0 ,initrd_end : 0 ## Transferring control to Linux (at a=
ddress 30008000) ...
=0A
=0AStarting kernel ...30008000
=0A
=0A
=0A=A0bd->bi_arch_number:168 , bd->bi_boot_params:805306624data abort
=0Apc : [<30008010>] =A0 =A0lr : [<33d9f098>]
=0Asp : 33d3da98 =A0ip : ffffffff =A0fp : 00000000
=0Ar10:
=0A=A000000001 =A0r9 : 00000000 =A0r8 : 33d3ffdc
=0Ar7 : 00000000 =A0r6 : 33de2f84 =A0r5 : 33d409e2 =A0r4 : 00000000
=0Ar3 : 30008000 =A0r2 : 30000100 =A0r1 : 000000a8 =A0r0 : ea000016
=0AFlags: nZCv =A0IRQs off =A0FIQs off =A0Mode SVC_32
=0AResetting CPU ...
=0A
=0A
=0AThe above is an uncompressed kernel image with load and entry point as 3=
0008000.=A0Can you suggest with how I can debug the issue.=A0
=0Athanks & regardsGIGIN
=0A--- On Fri, 7/1/11, Pankaj Pandey <pankaj.embedded@gmail.com> wrote:
=0A
=0AFrom: Pankaj Pandey <pankaj.embedded@gmail.com>
=0ASubject: Re: [U-Boot] Entry point for uncompressed kernel image
=0ATo: "Gigin Jose"
=0A=A0<gigin_jose@yahoo.co.in>
=0ADate: Friday, 7 January, 2011, 10:52 AM
=0A
=0Ahi ....u can define same 0x30008000 as entry and load address.
=0A
=0ARegards,
=0APankaj Pandey
=0A
=0AOn Fri, Jan 7, 2011 at 2:07 PM, Gigin Jose <gigin_jose@yahoo.co.in> wrot=
e:
=0A
=0AHi ,=A0
=0A
=0AI am trying to put uncompressed kernel image to SDRAM for my s3c2440 dev=
elopment board. The uncompressed kernel image is made from 'Image' inside a=
rch/arm/boot folder using the mkimage tool.
=0A
=0A=A0What should be the entry point and load address for the uncompressed =
kernel image ?=A0
=0A
=0AThe physical address of my RAM is 0x30000000 and the zImage is loaded to=
the address 0x30008000.=A0
=0A
=0Athanks & regardsGIGIN
=0A
=0A
=0A
=0A
=0A_______________________________________________
=0A
=0AU-Boot mailing list
=0A
=0AU-Boot at lists.denx.de
=0A
=0Ahttp://lists.denx.de/mailman/listinfo/u-boot
=0A
=0A
=0A
=0A
=0A
=0A
=0A
_______________________________________________
=0AU-Boot mailing list
=0AU-Boot at lists.denx.de
=0Ahttp://lists.denx.de/mailman/listinfo/u-boot
=0A
=0A=0A=0A
--0-722258477-1294383490=:99590--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
Involve the __udelay() may not suitable for the timer functions...
>
> ...
>> --- /dev/null
>> +++ b/arch/arm/include/asm/arch-pantheon/config.h
>> @@ -0,0 +1,44 @@
> ...
>> +/*
>> + * There is no internal RAM in ARMADA100, using DRAM
>> + * TBD: dcache to be used for this
>> + */
>> +#define CONFIG_SYS_INIT_SP_ADDR =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0(CONFIG_SYS_TEXT_BASE - 0x00200000)
>> +#define CONFIG_NR_DRAM_BANKS_MAX =C2=A0 =C2=A0 2
>
> This looks like board specific code that should not be here.
Yep... I would update the patch for it. For V7...
>
> ...
>> +struct panthmpmu_registers {
>> + =C2=A0 =C2=A0 u8 pad0[0x0024];
>> + =C2=A0 =C2=A0 u32 ccgr; =C2=A0 =C2=A0 =C2=A0 /*0x0024*/
>> + =C2=A0 =C2=A0 u8 pad1[0x0200 - 0x024 - 4];
>> + =C2=A0 =C2=A0 u32 wdtpcr; =C2=A0 =C2=A0 /*0x0200*/
>> + =C2=A0 =C2=A0 u8 pad2[0x1020 - 0x200 - 4];
>> + =C2=A0 =C2=A0 u32 aprr; =C2=A0 =C2=A0 =C2=A0 /*0x1020*/
>> + =C2=A0 =C2=A0 u32 acgr; =C2=A0 =C2=A0 =C2=A0 /*0x1024*/
>> +};
>
> Please use TAB for vertical alignment of variable names. =C2=A0Please fix
> globally.
In V6 patch , I think I already do like using tab. :)
Best regards,
Lei
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
independent of the TPL stuff and could be handles separately. The
second part should be mergeed into the patch that first uses these
variables. Note that I do not insist on splitting the README changes.
It's OK with me to keep this together.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It is a good thing for an uneducated man to read books of quotations.
- Sir Winston Churchill _My Early Life_ ch. 9
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
disabling it. Is it correct ?
> +
> + res = eth_getenv_enetaddr("ethaddr", dev->enetaddr);
> + if (!res) {
> + puts("Please set your MAC address!");
> + free(dev);
> + return 0;
> + }
This is wrong. A network driver should not call directly
eth_getenv_enetaddr, and you do not need. If you want to check the mac
addrsss, use is_valid_ether_addr() inside ax88783_init() before copying
the mac to the hardware.
> +
> + res = ax88183_phy_initial(dev);
Name must be changed.
> diff --git a/drivers/net/ax88783.h b/drivers/net/ax88783.h
> new file mode 100644
> index 0000000..09ac9ed
> --- /dev/null
> +++ b/drivers/net/ax88783.h
> @@ -0,0 +1,100 @@
> +/*
> + *
As explained, all headers start with copyright on the second line. Drop
this line.
Best regards,
Stefano Babic
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
this, then there is little danger. We will not remove a board that is
visibly actively being maintained,
> Otherwise, I could leave out the whole PCI area and only provide patches
> for the boards without PCI, leaving IXP PCI in its current broken state.
Even that would be OK, as it's still an improvemnt over the status
quo.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The most exciting phrase to hear in science, the one that heralds new
discoveries, is not "Eureka!" (I found it!) but "That's funny ..."
-- Isaac Asimov
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
"CE connection depends on the NAND Flash. For standard NAND Flash devices, it must be connected to any free PIO line.
For ?CE don?t care? NAND Flash devices, it can be connected to either NCS3/NANDCS or to any free PIO line."
Hope that is more clear now. Linux use an hook to do it and u-boot a #define
>> diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
>> index ab8bbb3..bda117a 100644
>> --- a/drivers/mtd/nand/atmel_nand.c
>> +++ b/drivers/mtd/nand/atmel_nand.c
>> @@ -249,8 +249,13 @@ static void at91_nand_hwcontrol(struct mtd_info *mtd,
>> if (ctrl & NAND_ALE)
>> IO_ADDR_W |= CONFIG_SYS_NAND_MASK_ALE;
>>
>> + /*
>> + * Nand CS don't care doesn't need the enable pin
>> + */
>> +#ifdef CONFIG_SYS_NAND_ENABLE_PIN
>> at91_set_gpio_value(CONFIG_SYS_NAND_ENABLE_PIN,
>> !(ctrl & NAND_NCE));
>> +#endif
> New CONFIG symbols need to be documented, and this particular one should
> probably be less generic.
There is not a new CONFIG symbol, I just skip that code that is not necessary
for this type of NAND
> -Scott
>
I will resend it
Michael
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
argument for spi flash erase, which will round up the length to the
nearest [sector|page|block]_size.
This is done by adding a new member to
struct spi_flash::u32 block_size
The name 'block_size' is chosen to mean:
"the smallest unit erase commands will check against".
If "block_size" is considered a kludgy name, please propose another.
Most of the driver (excluding atmel) will now only calculate this
unit once during probe and will be able to use it directly.
For atmel, I added code to populate the block_size structure member
but felt too ignorant to actually modify the erase unit check.
Code compiles cleanly. fo all drivers, but I can only test
stmicro (M25P40 and M25P16).
---
common/cmd_sf.c | 63 +++++++++++++++++++++++++++++++++++++++++--
drivers/mtd/spi/atmel.c | 1 +
drivers/mtd/spi/macronix.c | 4 +-
drivers/mtd/spi/spansion.c | 3 +-
drivers/mtd/spi/sst.c | 3 +-
drivers/mtd/spi/stmicro.c | 3 +-
drivers/mtd/spi/winbond.c | 6 ++--
include/spi_flash.h | 3 +-
8 files changed, 74 insertions(+), 12 deletions(-)
diff --git a/common/cmd_sf.c b/common/cmd_sf.c
index 6e7be81..b1fed6e 100644
--- a/common/cmd_sf.c
+++ b/common/cmd_sf.c
@@ -19,6 +19,59 @@
static struct spi_flash *flash;
+
+/*
+ * This function computes the length argument for the erase command.
+ * The length on which the command is to operate can be given in two forms:
+ * 1. <cmd> offset len - operate on <'offset', 'len')
+ * 2. <cmd> offset +len - operate on <'offset', 'round_up(len)')
+ * If the second form is used and the length doesn't fall on the
+ * sector boundary, than it will be adjusted to the next sector boundary.
+ * If it isn't in the flash, the function will fail (return -1).
+ * Input:
+ * arg: length specification (i.e. both command arguments)
+ * Output:
+ * len: computed length for operation
+ * Return:
+ * 1: success
+ * -1: failure (bad format, bad address).
+*/
+static int sf_parse_len_arg(char *arg, ulong *len)
+{
+ char *ep;
+ char round_up_len; /* indicates if the "+length" form used */
+ ulong sector_size;
+ ulong len_arg;
+
+
+ round_up_len = 0;
+ if (arg && *arg == '+'){
+ round_up_len = 1;
+ ++arg;
+ }
+
+ len_arg = simple_strtoul(arg, &ep, 16);
+ if (ep == arg || *ep != '\0')
+ return -1;
+
+ if (round_up_len) {
+ /* Get sector size from flash and round up */
+ sector_size = flash->block_size;
+ if (sector_size > 0) {
+ *len = ((((len_arg -1)/sector_size) + 1) * sector_size);
+ if (*len > flash->size) {
+ return -1;
+ }
+ } else {
+ return -1;
+ }
+ } else {
+ *len = len_arg;
+ }
+
+ return 1;
+}
+
static int do_spi_flash_probe(int argc, char * const argv[])
{
unsigned int bus = 0;
@@ -135,9 +188,11 @@ static int do_spi_flash_erase(int argc, char * const argv[])
offset = simple_strtoul(argv[1], &endp, 16);
if (*argv[1] == 0 || *endp != 0)
goto usage;
- len = simple_strtoul(argv[2], &endp, 16);
- if (*argv[2] == 0 || *endp != 0)
+
+ ret = sf_parse_len_arg(argv[2], &len);
+ if (ret != 1) {
goto usage;
+ }
ret = spi_flash_erase(flash, offset, len);
if (ret) {
@@ -149,6 +204,7 @@ static int do_spi_flash_erase(int argc, char * const argv[])
usage:
puts("Usage: sf erase offset len\n");
+ puts(" sf erase offset +len\n");
return 1;
}
@@ -189,5 +245,6 @@ U_BOOT_CMD(
" `offset' to memory at `addr'\n"
"sf write addr offset len - write `len' bytes from memory\n"
" at `addr' to flash at `offset'\n"
- "sf erase offset len - erase `len' bytes from `offset'"
+ "sf erase offset [+]len - erase `len' bytes from `offset'\n"
+ " - `+len' round up `len' to block size"
);
diff --git a/drivers/mtd/spi/atmel.c b/drivers/mtd/spi/atmel.c
index 8d02169..ec1a7b7 100644
--- a/drivers/mtd/spi/atmel.c
+++ b/drivers/mtd/spi/atmel.c
@@ -539,6 +539,7 @@ struct spi_flash *spi_flash_probe_atmel(struct spi_slave *spi, u8 *idcode)
asf->flash.size = page_size * params->pages_per_block
* params->blocks_per_sector
* params->nr_sectors;
+ asf->flash.block_size = page_size;
printf("SF: Detected %s with page size %u, total ",
params->name, page_size);
diff --git a/drivers/mtd/spi/macronix.c b/drivers/mtd/spi/macronix.c
index 76d5284..98e553b 100644
--- a/drivers/mtd/spi/macronix.c
+++ b/drivers/mtd/spi/macronix.c
@@ -247,8 +247,7 @@ int macronix_erase(struct spi_flash *flash, u32 offset, size_t len)
* when possible.
*/
- sector_size = mcx->params->page_size * mcx->params->pages_per_sector
- * mcx->params->sectors_per_block;
+ sector_size = mcx->flash.block_size;
if (offset % sector_size || len % sector_size) {
debug("SF: Erase offset/length not multiple of sector size\n");
@@ -329,6 +328,7 @@ struct spi_flash *spi_flash_probe_macronix(struct spi_slave *spi, u8 *idcode)
mcx->flash.read = macronix_read_fast;
mcx->flash.size = params->page_size * params->pages_per_sector
* params->sectors_per_block * params->nr_blocks;
+ mcx->flash.block_size = mcx->flash.size/params->nr_blocks;
printf("SF: Detected %s with page size %u, total ",
params->name, params->page_size);
diff --git a/drivers/mtd/spi/spansion.c b/drivers/mtd/spi/spansion.c
index d6c1a5f..e5ba4f4 100644
--- a/drivers/mtd/spi/spansion.c
+++ b/drivers/mtd/spi/spansion.c
@@ -255,7 +255,7 @@ int spansion_erase(struct spi_flash *flash, u32 offset, size_t len)
* when possible.
*/
- sector_size = spsn->params->page_size * spsn->params->pages_per_sector;
+ sector_size = spsn->flash.block_size;
if (offset % sector_size || len % sector_size) {
debug("SF: Erase offset/length not multiple of sector size\n");
@@ -342,6 +342,7 @@ struct spi_flash *spi_flash_probe_spansion(struct spi_slave *spi, u8 *idcode)
spsn->flash.read = spansion_read_fast;
spsn->flash.size = params->page_size * params->pages_per_sector
* params->nr_sectors;
+ spsn->flash.block_size = spsn->flash.size/params->nr_sectors;
printf("SF: Detected %s with page size %u, total ",
params->name, params->page_size);
diff --git a/drivers/mtd/spi/sst.c b/drivers/mtd/spi/sst.c
index 2557891..4ac6783 100644
--- a/drivers/mtd/spi/sst.c
+++ b/drivers/mtd/spi/sst.c
@@ -261,7 +261,7 @@ sst_erase(struct spi_flash *flash, u32 offset, size_t len)
* when possible.
*/
- sector_size = SST_SECTOR_SIZE;
+ sector_size = flash->block_size;
if (offset % sector_size) {
debug("SF: Erase offset not multiple of sector size\n");
@@ -363,6 +363,7 @@ spi_flash_probe_sst(struct spi_slave *spi, u8 *idcode)
stm->flash.erase = sst_erase;
stm->flash.read = sst_read_fast;
stm->flash.size = SST_SECTOR_SIZE * params->nr_sectors;
+ stm->flash.block_size = SST_SECTOR_SIZE;
printf("SF: Detected %s with page size %u, total ",
params->name, SST_SECTOR_SIZE);
diff --git a/drivers/mtd/spi/stmicro.c b/drivers/mtd/spi/stmicro.c
index 3134027..8b44fb9 100644
--- a/drivers/mtd/spi/stmicro.c
+++ b/drivers/mtd/spi/stmicro.c
@@ -269,7 +269,7 @@ int stmicro_erase(struct spi_flash *flash, u32 offset, size_t len)
* when possible.
*/
- sector_size = stm->params->page_size * stm->params->pages_per_sector;
+ sector_size = stm->flash.block_size;
if (offset % sector_size || len % sector_size) {
debug("SF: Erase offset/length not multiple of sector size\n");
@@ -364,6 +364,7 @@ struct spi_flash *spi_flash_probe_stmicro(struct spi_slave *spi, u8 * idcode)
stm->flash.read = stmicro_read_fast;
stm->flash.size = params->page_size * params->pages_per_sector
* params->nr_sectors;
+ stm->flash.block_size = stm->flash.size/params->nr_sectors;
printf("SF: Detected %s with page size %u, total ",
params->name, params->page_size);
diff --git a/drivers/mtd/spi/winbond.c b/drivers/mtd/spi/winbond.c
index ff1df25..f760bc2 100644
--- a/drivers/mtd/spi/winbond.c
+++ b/drivers/mtd/spi/winbond.c
@@ -225,7 +225,6 @@ int winbond_erase(struct spi_flash *flash, u32 offset, size_t len)
{
struct winbond_spi_flash *stm = to_winbond_spi_flash(flash);
unsigned long sector_size;
- unsigned int page_shift;
size_t actual;
int ret;
u8 cmd[4];
@@ -236,8 +235,7 @@ int winbond_erase(struct spi_flash *flash, u32 offset, size_t len)
* when possible.
*/
- page_shift = stm->params->l2_page_size;
- sector_size = (1 << page_shift) * stm->params->pages_per_sector;
+ sector_size = stm->flash.block_size;
if (offset % sector_size || len % sector_size) {
debug("SF: Erase offset/length not multiple of sector size\n");
@@ -324,6 +322,8 @@ struct spi_flash *spi_flash_probe_winbond(struct spi_slave *spi, u8 *idcode)
stm->flash.size = page_size * params->pages_per_sector
* params->sectors_per_block
* params->nr_blocks;
+ stm->flash.block_size = (1 << stm->params->l2_page_size) *
+ stm->params->pages_per_sector;
printf("SF: Detected %s with page size %u, total ",
params->name, page_size);
diff --git a/include/spi_flash.h b/include/spi_flash.h
index 1f8ba29..462bef6 100644
--- a/include/spi_flash.h
+++ b/include/spi_flash.h
@@ -38,6 +38,8 @@ struct spi_flash {
u32 size;
+ u32 block_size;
+
int (*read)(struct spi_flash *flash, u32 offset,
size_t len, void *buf);
int (*write)(struct spi_flash *flash, u32 offset,
@@ -67,5 +69,4 @@ static inline int spi_flash_erase(struct spi_flash *flash, u32 offset,
{
return flash->erase(flash, offset, len);
}
-
#endif /* _SPI_FLASH_H_ */
--
1.7.2.3
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
=A0
How Are You? I Know That This Mail May Come To You Almost A Surprise As We =
Never Met Before And Please Before You Proceed Reading This mail, This Is T=
rue and not A Joke, Well I Saw Your Contact Email From Burkina Faso Chamber=
s Of Commerce, After Much Consideration I Decided To Write You Since I Cann=
ot Be Able To See You Face To Face For Now, At First I Strongly Believed Th=
at Any Information Received From The Chambers Of Commerce Office Is Correct=
And Must Be Trusted. But Never Mind, I Am from (Burkina Faso West Africa) =
Mr. Hammoud Aziz by Name, an Auditing Debt Manager in Our Bank Here (Bank o=
f Africa).
=A0
I Have An Opportunity To The Sum Of Two Million, Five Hundred Thousand Unit=
ed States Dollars (US$2.500, 000.00), To Transfer Into Your Nominated Bank =
Account (The Owner Of The Money) Is An. IRAQ. Who Died A Long With His Enti=
re Family During The Iraq War, Upon Your Reply And Interest To Receive This=
Fund On My Behalf, I Will Kindly Send You More Details On The Execution Of=
This Transaction Will Commence, Now I Urge You To Take This Message Seriou=
sly And With An Open Mind. So Please Give It A Benefit Of Doubt, And With G=
ood Faith And Trust Join Me And I am Assuring You Now That You Will Never B=
e Disappointed. Now My Questions Are: Can You Handle This Project With Me? =
Can I Give You This Trust? Respond Back To Me Or Delete It Off If You Are N=
ot Interested.
=A0
You May View The Website:
http://www.cnn.com/2006/WORLD/meast/10/11/iraq.deaths/
=A0
If You Accept This Offer To Work With Me, And You Find This Proposal Suitab=
le For You Do Furnish Me With The Following Information.
=A0
Your Full Name...................
Your Country................
Your Private Telephone.........
Your Age and Sex..................
Your Occupation................
=A0
I Will Appreciate It Very Much, If This Proposal Is Acceptable By You, Do N=
ot Make Undue Advantage Of The Trust I Have Bestowed On You, And I Assure Y=
ou We Can Achieve It Successfully.
=A0
This Is My Private Phone Number =A0+226 75 55 15 29.=A0 Call Me for More Ex=
planation.=A0=20
=A0
Respectfully
Mr. Hammoud Aziz.=0A=0A
--0-1831948727-1298869466=:16158--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
set to the video display, regardless as to what the "stdout" environment
variable says.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
#define in include/configs/aria.h for example)
So my RFC is twofold:
1) Should we start to systematically remove unused options
2) Should we centralise all options in a single README (or two, one for
standard CONFIG options and one for CONFIG_SYS options)?
Regards,
Graeme
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
MMC drivers Andy Fleming afleming {AT} gmail {DOT} com u-boot-mmc
So, Andy, could you please pick this patch up. Thanks,
>
> Maybe you should put the responsible custodian on Cc.
Yes, Thanks,
BR,
Jason
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, =A0 =A0 MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> All men should freely use those seven words which have the =A0power =A0to
> make any marriage run smoothly: You know dear, you may be right.
>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
however manage to get this accepted for mainline Linux, then maybe I
reconsider.
Sorry.
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Many companies that have made themselves dependent on [the equipment
of a certain major manufacturer] (and in doing so have sold their
soul to the devil) will collapse under the sheer weight of the un-
mastered complexity of their data processing systems.
-- Edsger W. Dijkstra, SIGPLAN Notices, Volume 17, Number 5
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
mmc command applied device, like ide and usb...
Signed-off-by: Lei Wen <leiwen@marvell.com>
---
Changelog:
V2: use the "mmc_cur_dev" to replace explicitly specify the dev num
in mmc command.
common/cmd_mmc.c | 173 +++++++++++++++++++++++++++-------------------------
drivers/mmc/mmc.c | 16 ++++-
include/mmc.h | 3 +
3 files changed, 105 insertions(+), 87 deletions(-)
diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c
index 4323f76..dd4ee23 100644
--- a/common/cmd_mmc.c
+++ b/common/cmd_mmc.c
@@ -112,14 +112,13 @@ static void print_mmcinfo(struct mmc *mmc)
int do_mmcinfo (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
struct mmc *mmc;
- int dev_num;
- if (argc < 2)
- dev_num = 0;
- else
- dev_num = simple_strtoul(argv[1], NULL, 0);
+ if (mmc_cur_dev < 0) {
+ puts("No MMC card found\n");
+ return 1;
+ }
- mmc = find_mmc_device(dev_num);
+ mmc = find_mmc_device(mmc_cur_dev);
if (mmc) {
mmc_init(mmc);
@@ -131,121 +130,129 @@ int do_mmcinfo (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
}
U_BOOT_CMD(
- mmcinfo, 2, 0, do_mmcinfo,
+ mmcinfo, 1, 0, do_mmcinfo,
"display MMC info",
- "<dev num>\n"
" - device number of the device to dislay info of\n"
""
);
int do_mmcops(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
- int rc = 0;
+ if (argc < 2)
+ return cmd_usage(cmdtp);
- switch (argc) {
- case 3:
- if (strcmp(argv[1], "rescan") == 0) {
- int dev = simple_strtoul(argv[2], NULL, 10);
- struct mmc *mmc = find_mmc_device(dev);
+ if (strcmp(argv[1], "rescan") == 0) {
+ struct mmc *mmc = find_mmc_device(mmc_cur_dev);
- if (!mmc)
- return 1;
+ if (!mmc)
+ return 1;
+
+ mmc_init(mmc);
- mmc_init(mmc);
+ return 0;
+ } else if (strncmp(argv[1], "part", 4) == 0) {
+ block_dev_desc_t *mmc_dev;
+ struct mmc *mmc = find_mmc_device(mmc_cur_dev);
+ if (!mmc) {
+ puts("no mmc devices available\n");
+ return 1;
+ }
+ mmc_init(mmc);
+ mmc_dev = mmc_get_dev(mmc_cur_dev);
+ if (mmc_dev != NULL &&
+ mmc_dev->type != DEV_TYPE_UNKNOWN) {
+ print_part(mmc_dev);
return 0;
- } else if (strncmp(argv[1], "part", 4) == 0) {
- int dev = simple_strtoul(argv[2], NULL, 10);
- block_dev_desc_t *mmc_dev;
- struct mmc *mmc = find_mmc_device(dev);
+ }
- if (!mmc) {
- puts("no mmc devices available\n");
+ puts("get mmc type error!\n");
+ return 1;
+ } else if (strcmp(argv[1], "list") == 0) {
+ print_mmc_devices('\n');
+ return 0;
+ } else if (strcmp(argv[1], "dev") == 0) {
+ int dev = mmc_cur_dev;
+ struct mmc *mmc;
+
+ if (argc == 2) {
+ if (mmc_cur_dev < 0) {
+ puts("No MMC device available\n");
return 1;
}
- mmc_init(mmc);
- mmc_dev = mmc_get_dev(dev);
- if (mmc_dev != NULL &&
- mmc_dev->type != DEV_TYPE_UNKNOWN) {
- print_part(mmc_dev);
- return 0;
- }
+ } else if (argc == 3) {
+ dev = simple_strtoul(argv[2], NULL, 10);
+
+ } else {
+ return cmd_usage(cmdtp);
+ }
- puts("get mmc type error!\n");
+ mmc = find_mmc_device(dev);
+ if (!mmc) {
+ printf("There is no MMC device on slot %d\n", dev);
return 1;
}
- case 0:
- case 1:
- case 4:
- return cmd_usage(cmdtp);
+ mmc_cur_dev = dev;
+ printf("mmc%d is current device\n", mmc_cur_dev);
- case 2:
- if (!strcmp(argv[1], "list")) {
- print_mmc_devices('\n');
- return 0;
- }
- return 1;
- default: /* at least 5 args */
- if (strcmp(argv[1], "read") == 0) {
- int dev = simple_strtoul(argv[2], NULL, 10);
- void *addr = (void *)simple_strtoul(argv[3], NULL, 16);
- u32 cnt = simple_strtoul(argv[5], NULL, 16);
- u32 n;
- u32 blk = simple_strtoul(argv[4], NULL, 16);
- struct mmc *mmc = find_mmc_device(dev);
-
- if (!mmc)
- return 1;
+ return 0;
+ } else if (strcmp(argv[1], "read") == 0) {
+ void *addr = (void *)simple_strtoul(argv[2], NULL, 16);
+ u32 cnt = simple_strtoul(argv[4], NULL, 16);
+ u32 n;
+ u32 blk = simple_strtoul(argv[3], NULL, 16);
+ struct mmc *mmc = find_mmc_device(mmc_cur_dev);
- printf("\nMMC read: dev # %d, block # %d, count %d ... ",
- dev, blk, cnt);
+ if (!mmc)
+ return 1;
- mmc_init(mmc);
+ printf("\nMMC read: dev # %d, block # %d, count %d ... ",
+ mmc_cur_dev, blk, cnt);
- n = mmc->block_dev.block_read(dev, blk, cnt, addr);
+ mmc_init(mmc);
- /* flush cache after read */
- flush_cache((ulong)addr, cnt * 512); /* FIXME */
+ n = mmc->block_dev.block_read(mmc_cur_dev, blk, cnt, addr);
- printf("%d blocks read: %s\n",
+ /* flush cache after read */
+ flush_cache((ulong)addr, cnt * 512); /* FIXME */
+
+ printf("%d blocks read: %s\n",
n, (n==cnt) ? "OK" : "ERROR");
- return (n == cnt) ? 0 : 1;
- } else if (strcmp(argv[1], "write") == 0) {
- int dev = simple_strtoul(argv[2], NULL, 10);
- void *addr = (void *)simple_strtoul(argv[3], NULL, 16);
- u32 cnt = simple_strtoul(argv[5], NULL, 16);
- u32 n;
- struct mmc *mmc = find_mmc_device(dev);
+ return (n == cnt) ? 0 : 1;
+ } else if (strcmp(argv[1], "write") == 0) {
+ void *addr = (void *)simple_strtoul(argv[2], NULL, 16);
+ u32 cnt = simple_strtoul(argv[4], NULL, 16);
+ u32 n;
+ struct mmc *mmc = find_mmc_device(mmc_cur_dev);
- int blk = simple_strtoul(argv[4], NULL, 16);
+ int blk = simple_strtoul(argv[3], NULL, 16);
- if (!mmc)
- return 1;
+ if (!mmc)
+ return 1;
- printf("\nMMC write: dev # %d, block # %d, count %d ... ",
- dev, blk, cnt);
+ printf("\nMMC write: dev # %d, block # %d, count %d ... ",
+ mmc_cur_dev, blk, cnt);
- mmc_init(mmc);
+ mmc_init(mmc);
- n = mmc->block_dev.block_write(dev, blk, cnt, addr);
+ n = mmc->block_dev.block_write(mmc_cur_dev, blk, cnt, addr);
- printf("%d blocks written: %s\n",
+ printf("%d blocks written: %s\n",
n, (n == cnt) ? "OK" : "ERROR");
- return (n == cnt) ? 0 : 1;
- } else
- rc = cmd_usage(cmdtp);
-
- return rc;
+ return (n == cnt) ? 0 : 1;
}
+
+ return cmd_usage(cmdtp);
}
U_BOOT_CMD(
mmc, 6, 1, do_mmcops,
"MMC sub system",
- "read <device num> addr blk# cnt\n"
- "mmc write <device num> addr blk# cnt\n"
- "mmc rescan <device num>\n"
- "mmc part <device num> - lists available partition on mmc\n"
+ "read addr blk# cnt\n"
+ "mmc write addr blk# cnt\n"
+ "mmc rescan\n"
+ "mmc part - lists available partition on current mmc device\n"
+ "mmc dev [dev] - show or set current mmc device\n"
"mmc list - lists available devices");
#endif
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 6805b33..377f13a 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -34,7 +34,7 @@
#include <div64.h>
static struct list_head mmc_devices;
-static int cur_dev_num = -1;
+int mmc_cur_dev = -1;
int __board_mmc_getcd(u8 *cd, struct mmc *mmc) {
return -1;
@@ -849,7 +849,7 @@ int mmc_register(struct mmc *mmc)
{
/* Setup the universal parts of the block interface just once */
mmc->block_dev.if_type = IF_TYPE_MMC;
- mmc->block_dev.dev = cur_dev_num++;
+ mmc->block_dev.dev = mmc_cur_dev++;
mmc->block_dev.removable = 1;
mmc->block_dev.block_read = mmc_bread;
mmc->block_dev.block_write = mmc_bwrite;
@@ -936,12 +936,20 @@ void print_mmc_devices(char separator)
int mmc_initialize(bd_t *bis)
{
+ int ret = -1;
INIT_LIST_HEAD (&mmc_devices);
- cur_dev_num = 0;
+ mmc_cur_dev = 0;
if (board_mmc_init(bis) < 0)
- cpu_mmc_init(bis);
+ ret = cpu_mmc_init(bis);
+ else
+ ret = 0;
+ /* Put the device 0 as the default */
+ if (ret < 0)
+ mmc_cur_dev = -1;
+ else
+ mmc_cur_dev = 0;
print_mmc_devices(',');
return 0;
diff --git a/include/mmc.h b/include/mmc.h
index fcd0fd1..dd9bf15 100644
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -295,4 +295,7 @@ int atmel_mci_init(void *regs);
int mmc_legacy_init(int verbose);
#endif
+#ifdef CONFIG_GENERIC_MMC
+extern int mmc_cur_dev;
+#endif
#endif /* _MMC_H_ */
--
1.7.0.4
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
checkpatch. Maybe we can require 0 _errors_?
Moreover, it's only recently that I saw checkpatch warning about lines
that are not even changed in a patch but are only in the context, as for
exmaple here:
WARNING: unnecessary whitespace before a quoted newline
#293: FILE: net/net.c:1604:
debug("Got ICMP ECHO REQUEST, return %d bytes \n",
Now when this is "fixed", the new patch will then contain a cosmetic
change only intermixed with the "real" changes. Personally I think this
is problematic and contrary to the intention of checking a _patch_, but
it's the way it is.
I think we all agree that we should make reviews as easy as possible.
In order for that, we need to separate cosmetic from functional changes.
Otherwise in large patches it is very difficult to find the meat of a
patch. Only recently this exact problem made Andy Fleming resplit a
large commit[2] into functional and cosmetic[3] changes (ironically the
cosmetic changes were added as a followup to my request of fixing
checkpatch problems). As much as this is appreciated, it is clear that
it takes some effort to do. Ideally we should prevent such work right
from the start.
So what exact wording should we use in our CodingStyle to prevent such
problems, or should we even start our own version of checkpatch tailored
to our project?
As a base for discussion, what about this:
Use common sense in interpreting the results of checkpatch. Warnings
that clearly only make sense in the Linux kernel can be ignored. Also
warnings produced for _context lines_ rather than actual changes can
also be ignored.
Thanks
Detlev
[1] http://www.denx.de/wiki/view/U-Boot/CodingStyle
[2] http://article.gmane.org/gmane.comp.boot-loaders.u-boot/97068
[3] http://article.gmane.org/gmane.comp.boot-loaders.u-boot/97129
--
config LGUEST
If unsure, say N. If curious, say M. If masochistic, say Y.
-- linux/drivers/lguest/Kconfig
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
board.c file, and optionally disabling the -pie position-independent
executable option to reduce size. It is pretty trivial:
arch/arm/config.mk | 2 ++
arch/arm/lib/board.c | 5 +++++
2 files changed, 7 insertions(+), 0 deletions(-)
Regards,
Simon
>
> Amicalement,
> --
> Albert.
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
mmc command applied device, like ide and usb...
Signed-off-by: Lei Wen <leiwen@marvell.com>
---
Changelog:
V2: use the "mmc_cur_dev" to replace explicitly specify the dev num
in mmc command.
V3:
reuse "curr_device" in hte cmd_mmc.c
Modify notification message
common/cmd_mmc.c | 198 +++++++++++++++++++++++++++++-----------------------
drivers/mmc/mmc.c | 5 ++
include/mmc.h | 1 +
3 files changed, 116 insertions(+), 88 deletions(-)
diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c
index 6166749..e266d4f 100644
--- a/common/cmd_mmc.c
+++ b/common/cmd_mmc.c
@@ -25,9 +25,8 @@
#include <command.h>
#include <mmc.h>
-#ifndef CONFIG_GENERIC_MMC
static int curr_device = -1;
-
+#ifndef CONFIG_GENERIC_MMC
int do_mmc (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
int dev;
@@ -113,140 +112,163 @@ static void print_mmcinfo(struct mmc *mmc)
int do_mmcinfo (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
struct mmc *mmc;
- int dev_num;
- if (argc < 2)
- dev_num = 0;
- else
- dev_num = simple_strtoul(argv[1], NULL, 0);
+ if (curr_device < 0) {
+ if (get_mmc_num() > 0)
+ curr_device = 0;
+ else {
+ puts("No MMC device available\n");
+ return 1;
+ }
+ }
- mmc = find_mmc_device(dev_num);
+ mmc = find_mmc_device(curr_device);
if (mmc) {
mmc_init(mmc);
print_mmcinfo(mmc);
+ return 0;
+ } else {
+ printf("no mmc device at slot %x\n", curr_device);
+ return 1;
}
-
- return 0;
}
U_BOOT_CMD(
- mmcinfo, 2, 0, do_mmcinfo,
+ mmcinfo, 1, 0, do_mmcinfo,
"display MMC info",
- "<dev num>\n"
" - device number of the device to dislay info of\n"
""
);
int do_mmcops(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
- int rc = 0;
+ if (argc < 2)
+ return cmd_usage(cmdtp);
- switch (argc) {
- case 3:
- if (strcmp(argv[1], "rescan") == 0) {
- int dev = simple_strtoul(argv[2], NULL, 10);
- struct mmc *mmc = find_mmc_device(dev);
+ if (curr_device < 0) {
+ if (get_mmc_num() > 0)
+ curr_device = 0;
+ else {
+ puts("No MMC device available\n");
+ return 1;
+ }
+ }
- if (!mmc)
- return 1;
+ if (strcmp(argv[1], "rescan") == 0) {
+ struct mmc *mmc = find_mmc_device(curr_device);
- mmc_init(mmc);
+ if (!mmc) {
+ printf("no mmc device at slot %x\n", curr_device);
+ return 1;
+ }
+
+ mmc_init(mmc);
+ return 0;
+ } else if (strncmp(argv[1], "part", 4) == 0) {
+ block_dev_desc_t *mmc_dev;
+ struct mmc *mmc = find_mmc_device(curr_device);
+
+ if (!mmc) {
+ printf("no mmc device at slot %x\n", curr_device);
+ return 1;
+ }
+ mmc_init(mmc);
+ mmc_dev = mmc_get_dev(curr_device);
+ if (mmc_dev != NULL &&
+ mmc_dev->type != DEV_TYPE_UNKNOWN) {
+ print_part(mmc_dev);
return 0;
- } else if (strncmp(argv[1], "part", 4) == 0) {
- int dev = simple_strtoul(argv[2], NULL, 10);
- block_dev_desc_t *mmc_dev;
- struct mmc *mmc = find_mmc_device(dev);
+ }
- if (!mmc) {
- puts("no mmc devices available\n");
- return 1;
- }
- mmc_init(mmc);
- mmc_dev = mmc_get_dev(dev);
- if (mmc_dev != NULL &&
- mmc_dev->type != DEV_TYPE_UNKNOWN) {
- print_part(mmc_dev);
- return 0;
- }
+ puts("get mmc type error!\n");
+ return 1;
+ } else if (strcmp(argv[1], "list") == 0) {
+ print_mmc_devices('\n');
+ return 0;
+ } else if (strcmp(argv[1], "dev") == 0) {
+ int dev;
+ struct mmc *mmc;
+
+ if (argc == 2)
+ dev = curr_device;
+ else if (argc == 3)
+ dev = simple_strtoul(argv[2], NULL, 10);
+ else
+ return cmd_usage(cmdtp);
- puts("get mmc type error!\n");
+ mmc = find_mmc_device(dev);
+ if (!mmc) {
+ printf("no mmc device at slot %x\n", dev);
return 1;
}
- case 0:
- case 1:
- case 4:
- return cmd_usage(cmdtp);
+ curr_device = dev;
+ printf("mmc%d is current device\n", curr_device);
- case 2:
- if (!strcmp(argv[1], "list")) {
- print_mmc_devices('\n');
- return 0;
+ return 0;
+ } else if (strcmp(argv[1], "read") == 0) {
+ void *addr = (void *)simple_strtoul(argv[2], NULL, 16);
+ u32 cnt = simple_strtoul(argv[4], NULL, 16);
+ u32 n;
+ u32 blk = simple_strtoul(argv[3], NULL, 16);
+ struct mmc *mmc = find_mmc_device(curr_device);
+
+ if (!mmc) {
+ printf("no mmc device at slot %x\n", curr_device);
+ return 1;
}
- return 1;
- default: /* at least 5 args */
- if (strcmp(argv[1], "read") == 0) {
- int dev = simple_strtoul(argv[2], NULL, 10);
- void *addr = (void *)simple_strtoul(argv[3], NULL, 16);
- u32 cnt = simple_strtoul(argv[5], NULL, 16);
- u32 n;
- u32 blk = simple_strtoul(argv[4], NULL, 16);
- struct mmc *mmc = find_mmc_device(dev);
-
- if (!mmc)
- return 1;
- printf("\nMMC read: dev # %d, block # %d, count %d ... ",
- dev, blk, cnt);
+ printf("\nMMC read: dev # %d, block # %d, count %d ... ",
+ curr_device, blk, cnt);
- mmc_init(mmc);
+ mmc_init(mmc);
- n = mmc->block_dev.block_read(dev, blk, cnt, addr);
+ n = mmc->block_dev.block_read(curr_device, blk, cnt, addr);
- /* flush cache after read */
- flush_cache((ulong)addr, cnt * 512); /* FIXME */
+ /* flush cache after read */
+ flush_cache((ulong)addr, cnt * 512); /* FIXME */
- printf("%d blocks read: %s\n",
+ printf("%d blocks read: %s\n",
n, (n==cnt) ? "OK" : "ERROR");
- return (n == cnt) ? 0 : 1;
- } else if (strcmp(argv[1], "write") == 0) {
- int dev = simple_strtoul(argv[2], NULL, 10);
- void *addr = (void *)simple_strtoul(argv[3], NULL, 16);
- u32 cnt = simple_strtoul(argv[5], NULL, 16);
- u32 n;
- struct mmc *mmc = find_mmc_device(dev);
+ return (n == cnt) ? 0 : 1;
+ } else if (strcmp(argv[1], "write") == 0) {
+ void *addr = (void *)simple_strtoul(argv[2], NULL, 16);
+ u32 cnt = simple_strtoul(argv[4], NULL, 16);
+ u32 n;
+ struct mmc *mmc = find_mmc_device(curr_device);
- int blk = simple_strtoul(argv[4], NULL, 16);
+ int blk = simple_strtoul(argv[3], NULL, 16);
- if (!mmc)
- return 1;
+ if (!mmc) {
+ printf("no mmc device at slot %x\n", curr_device);
+ return 1;
+ }
- printf("\nMMC write: dev # %d, block # %d, count %d ... ",
- dev, blk, cnt);
+ printf("\nMMC write: dev # %d, block # %d, count %d ... ",
+ curr_device, blk, cnt);
- mmc_init(mmc);
+ mmc_init(mmc);
- n = mmc->block_dev.block_write(dev, blk, cnt, addr);
+ n = mmc->block_dev.block_write(curr_device, blk, cnt, addr);
- printf("%d blocks written: %s\n",
+ printf("%d blocks written: %s\n",
n, (n == cnt) ? "OK" : "ERROR");
- return (n == cnt) ? 0 : 1;
- } else
- rc = cmd_usage(cmdtp);
-
- return rc;
+ return (n == cnt) ? 0 : 1;
}
+
+ return cmd_usage(cmdtp);
}
U_BOOT_CMD(
mmc, 6, 1, do_mmcops,
"MMC sub system",
- "read <device num> addr blk# cnt\n"
- "mmc write <device num> addr blk# cnt\n"
- "mmc rescan <device num>\n"
- "mmc part <device num> - lists available partition on mmc\n"
+ "read addr blk# cnt\n"
+ "mmc write addr blk# cnt\n"
+ "mmc rescan\n"
+ "mmc part - lists available partition on current mmc device\n"
+ "mmc dev [dev] - show or set current mmc device\n"
"mmc list - lists available devices");
#endif
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index f6d31f5..cdf2713 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -1110,6 +1110,11 @@ void print_mmc_devices(char separator)
printf("\n");
}
+int get_mmc_num(void)
+{
+ return cur_dev_num;
+}
+
int mmc_initialize(bd_t *bis)
{
INIT_LIST_HEAD (&mmc_devices);
diff --git a/include/mmc.h b/include/mmc.h
index f7f2286..b1ad086 100644
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -294,6 +294,7 @@ void mmc_set_clock(struct mmc *mmc, uint clock);
struct mmc *find_mmc_device(int dev_num);
int mmc_set_dev(int dev_num);
void print_mmc_devices(char separator);
+int get_mmc_num(void);
int board_mmc_getcd(u8 *cd, struct mmc *mmc);
#ifdef CONFIG_GENERIC_MMC
--
1.7.0.4
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
git since they have standalone Kirkwood related fixes.
You may exclude them from your next patch series
> netconsole: remove `serverip' check
> Add support for Network Space v2
Whereas, mainly your board support patch have dependency with
1. "sf: disable write protection for Macronix flash" to be mainlined by Mik=
e and
2. "netconsole: remove `serverip' check" to be mainlined by net maintainer.
Regards..
Prafulla . .
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
Please Kindly Open the Attachment File
Thanks
--0-650646552-1304768131=:72930--
--0-502185102-1304768131=:72930
Content-Type: application/msword; name="INVESTMENT PROPOSAL OF $20MILLION.doc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="INVESTMENT PROPOSAL OF $20MILLION.doc"
0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAB
AAAAJwAAAAAAAAAAEAAAKQAAAAEAAAD+////AAAAACYAAAD/////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
///////////////////////spcEAcWAJBAAA8BK/AAAAAAAAEAAAAAAABgAA
ExIAAA4AYmpianFQcVAAAAAAAAAAAAAAAAAAAAAAAAAJBBYANBoAABM6AQAT
OgEAEwoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAAAAAA
AAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAKQAAAAAAOYDAAAA
AAAA5gMAAOYDAAAAAAAA5gMAAAAAAADmAwAAAAAAAOYDAAAAAAAA5gMAABQA
AAAAAAAAAAAAAPoDAAAAAAAA3gUAAAAAAADeBQAAAAAAAN4FAAAAAAAA3gUA
AAwAAADqBQAADAAAAPoDAAAAAAAAlwsAAAwBAAACBgAAFgAAABgGAAAAAAAA
GAYAAAAAAAAYBgAAAAAAABgGAAAAAAAA8wYAAAAAAADzBgAAAAAAAPMGAAAA
AAAAFgsAAAIAAAAYCwAAAAAAABgLAAAAAAAAGAsAAAAAAAAYCwAAAAAAABgL
AAAAAAAAGAsAACQAAACjDAAAaAIAAAsPAACiAAAAPAsAABUAAAAAAAAAAAAA
AAAAAAAAAAAA5gMAAAAAAADqCAAAAAAAAAAAAAAAAAAAAAAAAAAAAADzBgAA
AAAAAPMGAAAAAAAA6ggAAAAAAADqCAAAAAAAADwLAAAAAAAAAAAAAAAAAADm
AwAAAAAAAOYDAAAAAAAAGAYAAAAAAAAAAAAAAAAAABgGAADbAAAAUQsAABYA
AACeCgAAAAAAAJ4KAAAAAAAAngoAAAAAAADqCAAAXgAAAOYDAAAAAAAAGAYA
AAAAAADmAwAAAAAAABgGAAAAAAAAFgsAAAAAAAAAAAAAAAAAAJ4KAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAA6ggAAAAAAAAWCwAAAAAAAAAAAAAAAAAAngoAAAAAAAAAAAAAAAAAAJ4K
AAAAAAAA5gMAAAAAAADmAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAngoAAAAAAAAYBgAA
AAAAAPYFAAAMAAAAcFiywULqqAEAAAAAAAAAAN4FAAAAAAAASAkAABwAAACe
CgAAAAAAAAAAAAAAAAAACgsAAAwAAABnCwAAMAAAAJcLAAAAAAAAngoAAAAA
AACtDwAAAAAAAGQJAAAYAQAArQ8AAAAAAACeCgAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAK0PAAAAAAAAAAAAAAAAAADmAwAAAAAAAJ4KAABs
AAAA8wYAAIQAAAB3BwAAXgAAAJ4KAAAAAAAA1QcAAEwAAAAhCAAAyQAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8wYAAAAAAADzBgAAAAAA
APMGAAAAAAAAPAsAAAAAAAA8CwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAfAoAACIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAPMGAAAAAAAA8wYAAAAAAADzBgAAAAAAAJcLAAAAAAAA6ggAAAAA
AADqCAAAAAAAAOoIAAAAAAAA6ggAAAAAAAAAAAAAAAAAAPoDAAAAAAAA+gMA
AAAAAAD6AwAA5AEAAN4FAAAAAAAA+gMAAAAAAAD6AwAAAAAAAPoDAAAAAAAA
3gUAAAAAAAD6AwAAAAAAAPoDAAAAAAAA+gMAAAAAAADmAwAAAAAAAOYDAAAA
AAAA5gMAAAAAAADmAwAAAAAAAOYDAAAAAAAA5gMAAAAAAAD/////AAAAAAIA
DAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgU1RSSUNUTFkgQ09ORklERU5USUFM
IA0gRlJPTSBNUlMuIExFUkFUTyBNVVRBU0EgL0lOVkVTVE1FTlQgUFJPUE9T
QUwgDUF0dGVudGlvbjogRGVhciBTaXIvTWFkYW0gDVlvdSBtYXkgYmUgc3Vy
cHJpc2VkIHRvIHJlY2VpdmUgdGhpcyBzdHJhbmdlIGxldHRlciBmcm9tIG1l
LiBJIGFtIE1ycy4gTGVyYXRvIE11dGFzYTsgdGhlIHdpZmUgb2YgTXIuIEpl
cnJ5IE11dGFzYSBvZiBaaW1iYWJ3ZS4gSSBnb3QgeW91ciBhZGRyZXNzIGZy
b20gdGhlIHdvcmxkIHdlYiB5ZWxsb3cgYWRkcmVzcyBwYWdlLiBBZnRlciBk
dWUgY29uc2lkZXJhdGlvbiBmcm9tIHlvdXIgcHJvZmlsZSwgSSBiZWNhbWUg
YXdhcmUgYW5kIGFzc3VyZWQgb2YgeW91ciBjcmVkaWJpbGl0eSB0byBoZWxw
IG1lLiANTXkgaHVzYmFuZCB3YXMgYW1vbmcgdGhlIHJpY2ggZmFybWVycyBp
biBaaW1iYWJ3ZSB3aG8gd2VyZSBtdXJkZXJlZCBpbiBjb2xkIGJsb29kIGJ5
IHRoZSBhZ2VudCBvZiB0aGUgcnVsaW5nIGdvdmVybm1lbnQgb2YgUHJlc2lk
ZW50IFJvYmVydCBNdWdhYmUgYmVjYXVzZSBteSBodXNiYW5kIHdhcyBhZ2Fp
bnN0IHRoZSBtZXRob2QgYWRvcHRlZCBieSB0aGUgZ292ZXJubWVudCBvbiBu
ZXcgbGFuZCByZWZvcm0gYWN0IHRoYXQgd2hvbGx5IGFmZmVjdGVkIHRoZSBm
YXJtZXJzIGluIFppbWJhYndlLiBCZWZvcmUgdGhlIEludmFzaW9uLCBteSBo
dXNiYW5kIHRvb2sgbWUgdG8gU291dGggQWZyaWNhIGFzIGlmIGhlIGZvcmVz
YXcgdGhlIGxvb21pbmcgZGFuZ2VyIGluIFppbWJhYndlIGFuZCBkZXBvc2l0
ZWQgVVNEJDIwTWlsbGlvbihUd2VudHkgTWlsbGlvbiBVbml0ZWQgU3RhdGVz
IERvbGxhcnMpIHdpdGggYSBzZWN1cml0eSBhbmQgZmluYW5jZSBjb21wYW55
IGluIFNvdXRoIEFmcmljYSBhcyBhIEZhbWlseSBWYWx1YWJsZXMuIA1UaGlz
IG1vbmV5IHdhcyBmb3IgYnV5aW5nIGZhcm0gbGFuZHMgaW4gTGVzb3Robywg
U3dhemlsYW5kLCBhbmQgYWxzbyBtYWNoaW5lcnkgZm9yIHRoZSBmYXJtLiBI
ZWFkcyBvZiBnb3Zlcm5tZW50IGZyb20gd2VzdGVybiB3b3JsZCwgZXNwZWNp
YWxseSBCcml0YWluIGFuZCBUaGUgVS5TLkEsIGhhdmUgdm9pY2VkIHRoZWly
IGNvbmRlbW5hdGlvbiBhZ2FpbnN0IE11Z2FiZSdzIG5ldyBsYW5kIHJlZm9y
bSBhY3QuIEl0IGlzIGFnYWluc3QgdGhpcyBiYWNrZ3JvdW5kIHRoYXQgbXkg
b25seSBzb24gUmljaGFyZCBNdXRhc2EgaGFzIG1hbmRhdGVkIG1lIHRvIHNl
ZWsgZm9yZWlnbiBhc3Npc3RhbmNlIGFzIG15IGxhdGUgSHVzYmFuZCBpbmRp
Y2F0ZWQgdGhhdCB0aGUgY29uc2lnbm1lbnQgaXMgZm9yIG9ud2FyZCBzaGlw
bWVudCB0byBoaXMgZm9yZWlnbiBwYXJ0bmVyIGZvciBpbnZlc3RtZW50IHB1
cnBvc2VzLiANUHJlc2VudGx5LCBJIGFtIHJlc2lkaW5nIGluIFNvdXRoIEFm
cmljYSBhcyBhIHJlZnVnZWUuIEl0IGlzIGNsZWFybHkgaW5kaWNhdGVkIG9u
IGRlcG9zaXQgY2VydGlmaWNhdGUgdGhhdCB0aGUgY29uc2lnbm1lbnQgaXMg
bWVhbnQgZm9yIG9ud2FyZCBzaGlwbWVudCB0byBteSBsYXRlIGh1c2JhbmQg
Zm9yZWlnbiBwYXJ0bmVyIHdoaWNoIEkgd2FudCB0byBwcmVzZW50IHlvdSB0
byB0aGUgc2VjdXJpdHkgY29tcGFueS4gS2luZGx5IHNlbmQgbWUgdGhlIGJl
bG93IGluZm9ybWF0aW9uLip5b3VyIHByaXZhdGUgcGhvbmUgbnVtYmVyLiAN
UGxlYXNlIG5vdGUgdGhhdCB0aGVyZSBpcyBubyByaXNrIGludm9sdmVkIGlu
IHRoaXMgYnVzaW5lc3MsIGFuZCBmb3IgeW91ciBlZmZvcnQsIEkgYW0gcHJl
cGFyZWQgdG8gb2ZmZXIgeW91IDMwJSBvZiB0aGUgdG90YWwgc3VtIHdoZW4g
dGhlIG1vbmV5IGlzIHJldHJpZXZlZCBmcm9tIHRoZSBzZWN1cml0eSBhbmQg
ZmluYW5jZSBjb21wYW55IGFuZCB0cmFuc2ZlcnJlZCB0byB5b3VyIGJhbmsg
YWNjb3VudCBpbiB5b3VyIGNvdW50cnkuIA1JZiB0aGlzIHByb3Bvc2FsIGlz
IGFjY2VwdGVkIGJ5IHlvdSwgZ2V0IGluIHRvdWNoIHdpdGggbXkgb25seSBz
b24gTXIuIFJpY2hhcmQgTXV0YXNhIGJ5IHBob25lIG9uICsyNzgyNDI0NTQ0
NSBzbyB0aGF0IGhlIHdpbGwgZnVybmlzaCB5b3Ugd2l0aCBtb3JlIGRldGFp
bHMuIEkgd2lsbCBhcHByZWNpYXRlIGlmIHlvdSBtYWludGFpbiB0aGUgY29u
ZmlkZW50aWFsaXR5IG9mIHRoaXMgbWF0dGVyIGJlY2F1c2Ugb2YgdGhlIGhh
cHBlbmluZ3MgaW4gbXkgY291bnRyeS4gRW1haWwgYWRkcmVzczogbXJzbGVy
YXRvbXV0YXNhMjAxMEBsaXZlLmNvbQ1Zb3UgYXJlIGZ1cnRoZXIgYWR2aWNl
IHRvIGNsaWNrIHRoZSBiZWxvdyB3ZWJzaXRlIGFuZCByZWFkIHRoZSBjdXJy
ZW50IGNyaXNpcyBpbiBteSBjb3VudHJ5LiANEyBIWVBFUkxJTksgImh0dHA6
Ly9uZXdzLmJiYy5jby51ay8xL2hpL3dvcmxkL2FmcmljYS85MTg3ODEuc3Rt
IiAUaHR0cDovL25ld3MuYmJjLmNvLnVrLzEvaGkvd29ybGQvYWZyaWNhLzkx
ODc4MS5zdG0VDWh0dHA6Ly9uZXdzLmJiYy5jby51ay8xL2hpL3dvcmxkL2Fm
cmljYS83MTUwMDEuc3RtDVlvdXJzIHNpbmNlcmVseSANTVJTLkxFUkFUTyBN
VVRBU0EgDSANAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAGAAA2CwAANwsAAEELAABGCwAAyRAAAMwQAADYEAAA3BAAAOUQ
AABEEQAARREAAIURAACGEQAAuBEAALkRAAASEgAAExIAAPz4/Pj88OXw5fzd
/N3U3fzNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAADBVos3dXABZo8jvvAAAQFWiNdEoAFmizd1cAMEoPAAAP
A2oAAAAAFmizd1cAVQgBFRVos3dXABZos3dXAEIqD3BoT4G9AA8WaBwjTQBC
Kg9waE+BvQAGFmi+J24AAAYWaLN3VwARAAYAADQIAABjCAAAfggAAKAJAACy
CwAAgQ0AALMOAACuDwAA5hAAAEQRAAC6EQAA7REAAP4RAAAREgAAExIAAPoA
AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA
AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6
AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA
AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA
+gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAZ2Szd1cAAA8ABgAA
ExIAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAQEAAEBATIAMZBoATpw8jvvAB+w0C8gsOA9IbCgBSKwoAUjkKAF
JJCgBSWwAAAXsNACGLDQAgyQ0AIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhgIQABIAAQCcAA8ABAAD
AAMAAwAAAAQACAAAAJgAAACeAAAAngAAAJ4AAACeAAAAngAAAJ4AAACeAAAA
ngAAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAAHYCAAB2
AgAAdgIAAHYCAAB2AgAAdgIAAHYCAAB2AgAAdgIAADYGAAA2BgAANgYAADYG
AAA2BgAANgYAAD4CAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYA
ADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAA
NgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAACoAAAANgYAADYGAAAW
AAAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAC4AAAANgYAADYG
AAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAAaAEA
AEgBAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAA
NgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2
BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYG
AAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYA
ADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAA
NgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAALADAAA2
BgAASgAAQPH/AgBKAAwQAADyO+8AAAAGAE4AbwByAG0AYQBsAAAADAAAABJk
FAEBABSkyAAYAENKFgBfSAEEYUoWAG1ICQRzSAkEdEgJBAAAAAAAAAAAAAAA
AAAAAAAAAEQAQUDy/6EARAAMDQAAAAAAABAAFgBEAGUAZgBhAHUAbAB0ACAA
UABhAHIAYQBnAHIAYQBwAGgAIABGAG8AbgB0AAAAAABSAGkA8/+zAFIADB0A
AAAAAAAwBgwAVABhAGIAbABlACAATgBvAHIAbQBhAGwAAAAcABf2AwAANNYG
AAEKA2wANNYGAAEFAwAAYfYDAAACAAsAAAAoAGsA9P/BACgAAA0AAAAAAAAw
BgcATgBvACAATABpAHMAdAAAAAIADAAAAAAANgBVQKIA8QA2AAwMAACzd1cA
MAYJAEgAeQBwAGUAcgBsAGkAbgBrAAAADAA+KgFCKgdwaAAA/wAAAAAAEwoA
AAUAABoAAAAA/////wAAAAA0AAAAYwAAAH4AAACgAQAAsgMAAIEFAACzBgAA
rgcAAOYIAABECQAAugkAAO0JAAD+CQAAEQoAABUKAABJiAAwAAAAAAAAAAAB
AAAAAAAAAAAAAAAAAAABSYgAMAAAAAAAAAAAAQAAAAAAAAAAAAAAAACAAUmI
ADAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAgAFJiAAwAAAAAAAAAAABAAAAAAAA
AAAAAAAAAIABSYgAMAAAAAAAAAAAAQAAAAAAAAAAAAAAAACAAUmIADAAAAAA
AAAAAAEAAAAAAAAAAAAAAAAAgAFJiAAwAAAAAAAAAAABAAAAAAAAAAAAAAAA
AIABSYgAMAAAAAAAAAAAAQAAAAAAAAAAAAAAAACAAUmIADAAAAAAAAAAAAEA
AAAAAAAAAAAAAAAAgAFJiAAwAAAAAAAAAAABAAAAAAAAAAAAAAAAAIABSYgA
MAAAAAAAAAAAAQAAAAAAAAAAAAAAAACAAZgAAAAAMAAAAAAAAACAAAAAgAAA
AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAA
AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA
AAAABgAAExIAAAoAAAAABgAAExIAAAsAAAAABgAAExIAAAwAAABECQAAhQkA
ALgJAAATCgAAE1gU/xWADwAA8DgAAAAAAAbwGAAAAAIIAAACAAAAAQAAAAEA
AAABAAAAAgAAAEAAHvEQAAAA//8AAAAA/wCAgIAA9wAAEAAPAALwkgAAABAA
CPAIAAAAAQAAAAEEAAAPAAPwMAAAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAA
AAAAAAAAAAAAAgAK8AgAAAAABAAABQAAAA8ABPBCAAAAEgAK8AgAAAABBAAA
AA4AAFMAC/AeAAAAvwEAABAAywEAAAAA/wEAAAgABAMJAAAAPwMBAAEAAAAR
8AQAAAABAAAA//8JAAAABgCbrhgAEAABADyjIQAGAJyuGAARAAEAdDEhAAYA
na4YABEAAQB0QSIABgCerhgAEAABAHyjIQAGAJ+uGAARAAEAFK0gAAYAoK4Y
ABAAAQB8AyEABgChrhgAEQABAHxOwgIGAKKuGAAQAAEAzE/CAgYAo64YABEA
AQAc/CAA9AAAAPQAAADaAwAA4wMAAOMDAABCBAAAQgQAAJ0FAACdBQAAFQoA
AAAAAAACAAEAAAACAAIAAAABAAMAAAACAAQAAAACAAUAAAACAAYAAAACAAcA
AAACAAgAAAACAPwAAAD8AAAA4QMAAOwDAADsAwAASQQAAEkEAACpBQAAqQUA
ABUKAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAACAAAA
OQAAAAkAAAAqgHVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNt
YXJ0dGFncwWAcGxhY2UAgEIAAAAIAAAAKoB1cm46c2NoZW1hcy1taWNyb3Nv
ZnQtY29tOm9mZmljZTpzbWFydHRhZ3MOgGNvdW50cnktcmVnaW9uAIAMAAAB
wAOCAgAAAAAJAAAAAAAIAAAAAAAIAAAAAAAJAAAAAAAIAAAAAAAJAAAAAAAI
AAAAAAAJAAAAAAAIAAAAAAAAAAAAMgMAAEYDAABHAwAATgMAAE8DAABVAwAA
/QcAAAMIAABECQAAuQkAALoJAADsCQAA7QkAAPIJAAAVCgAABwADAAcAAwAH
AAMABwAcAAcABAAHAAMABwADAAcAAAAAAEQJAAC5CQAAEgoAABUKAAADAAQA
AwAHAAAAAAA0AAAANAAAAGMAAABjAAAAfQAAAH4AAADMAAAA0wAAAOoAAADz
AAAAoAEAAKABAAA2AwAANwMAAEEDAABGAwAAsgMAALIDAADVBAAA3AQAAIEF
AACBBQAAlwYAAJsGAACzBgAAswYAAK4HAACuBwAADwgAAA8IAAAQCAAAEQgA
AB8IAADMCAAAzAgAANgIAADcCAAA5ggAAOYIAABECQAAugkAAO0JAADuCQAA
EgoAABIKAAAVCgAAAwAEAAMABAADAAQAAwAHAAMABwADAAQAAwAEAAMABAAD
AAQAAwAEAAMABAADAAcAAwAEAAMABAADAAQAAwAEAAcAAwAEAAMABAADAAQA
AwAEAAMABAADAAQABwAAAAAAMgMAAEYDAABECQAAuQkAABUKAAAHAAQABwAE
AAcAFQAAAAQAAAAIAAAA5QAAAAAAAAAUAAAA+DACAFECBQCFAAkAmCxAABwj
TQAcX04As3dXAOJJXABuP18AFk9qAL4nbgAJSW8ALwxzADkGewAnRn0Ax06r
AL80vgCjMeEAlAboAOww6gDyO+8AAAAAABUKAAABAAAA/0AAgAEAAAAAAAAA
AADsJzMBAQAAAAAAAAAAAAAAAAAAAAAAAAACEAAAAAAAAAATCgAAUAAAEABA
AAD//wEAAAAHAFUAbgBrAG4AbwB3AG4A//8BAAgAAAAAAAAAAAAAAP//AQAA
AAAA//8AAAIA//8AAAAA//8AAAIA//8AAAAABAAAAEcWkAEAAAICBgMFBAUC
AwSHegAgAAAAgAgAAAAAAAAA/wEAAAAAAABUAGkAbQBlAHMAIABOAGUAdwAg
AFIAbwBtAGEAbgAAADUWkAECAAUFAQIBBwYCBQcAAAAAAAAAEAAAAAAAAAAA
AAAAgAAAAABTAHkAbQBiAG8AbAAAADMmkAEAAAILBgQCAgICAgSHegAgAAAA
gAgAAAAAAAAA/wEAAAAAAABBAHIAaQBhAGwAAABVLpABAAgCDwUCAgIEAwIE
7wIAoHsgAEAAAAAAAAAAAJ8AAAAAAAAAQwBhAGwAaQBiAHIAaQAAAEMAZQBu
AHQAdQByAHkAIABHAG8AdABoAGkAYwAAACIABAAxCIgYAPDQAgAAaAEAAAAA
HiABpR4gAaUAAAAAAgAAAAAAgAEAAJMIAAABAAUAAAAEAAOQEgAAAIABAACT
CAAAAQAFAAAAEgAAAAAAAAAhAwDwEAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAACgBaAFtAC0AIGBEjQAAAAAAAAAAAAAAAAA
AA4KAAAOCgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAygxEA8BAACAD8
/QEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAS1gAAAAACfD/DwEAJFAAAOQE
AAD///9/////f////3////9/////f////3////9/s3dXAAAEAAAyAAAAAAAA
AAAAAAAAAAAAAAD//xIAAAAAAAAAMwAgACAAIAAgACAAIAAgACAAIAAgACAA
IAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAUwBUAFIASQBD
AFQATABZACAAQwBPAE4ARgBJAEQARQBOAFQASQBBAEwAIAAAAAAAAAAGAHQA
aQBtAC0AMwAyAAMAcABjADIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAQIAAAAAAAAA
AAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAJQBAAARAAAAAQAA
AJAAAAACAAAAmAAAAAMAAADUAAAABAAAAOAAAAAFAAAA8AAAAAYAAAD8AAAA
BwAAAAgBAAAIAAAAGAEAAAkAAAAkAQAAEgAAADABAAAKAAAAUAEAAAwAAABc
AQAADQAAAGgBAAAOAAAAdAEAAA8AAAB8AQAAEAAAAIQBAAATAAAAjAEAAAIA
AADkBAAAHgAAADQAAAAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFNU
UklDVExZIENPTkZJREVOVElBTCAAHgAAAAQAAAAAAAAAHgAAAAgAAAB0aW0t
MzIAAB4AAAAEAAAAAAAAAB4AAAAEAAAAAAAAAB4AAAAIAAAATm9ybWFsAAAe
AAAABAAAAHBjMgAeAAAABAAAADIAAAAeAAAAGAAAAE1pY3Jvc29mdCBPZmZp
Y2UgV29yZAAAAEAAAAAAAAAAAAAAAEAAAAAANBigQuqoAUAAAAAANBigQuqo
AQMAAAABAAAAAwAAAIABAAADAAAAkwgAAAMAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABQECAAAAAAAA
AAAAAAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3VnC4bEJOX
CAArLPmuYAEAABwBAAAMAAAAAQAAAGgAAAAPAAAAcAAAAAUAAAB8AAAABgAA
AIQAAAARAAAAjAAAABcAAACUAAAACwAAAJwAAAAQAAAApAAAABMAAACsAAAA
FgAAALQAAAANAAAAvAAAAAwAAAD8AAAAAgAAAOQEAAAeAAAABAAAAAAAAAAD
AAAAEgAAAAMAAAAFAAAAAwAAAA4KAAADAAAA5hULAAsAAAAAAAAACwAAAAAA
AAALAAAAAAAAAAsAAAAAAAAAHhAAAAEAAAA0AAAAICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBTVFJJQ1RMWSBDT05GSURFTlRJQUwgAAwQAAACAAAA
HgAAAAYAAABUaXRsZQADAAAAAQAAAAAA6AAAAAMAAAAAAAAAIAAAAAEAAAA4
AAAAAgAAAEAAAAABAAAAAgAAAAwAAABfUElEX0hMSU5LUwACAAAA5AQAAEEA
AACgAAAABgAAAAMAAABvADQAAwAAAAAAAAADAAAAAAAAAAMAAAAFAAAAHwAA
ADMAAABoAHQAdABwADoALwAvAG4AZQB3AHMALgBiAGIAYwAuAGMAbwAuAHUA
awAvADEALwBoAGkALwB3AG8AcgBsAGQALwBhAGYAcgBpAGMAYQAvADkAMQA4
ADcAOAAxAC4AcwB0AG0AAAAAAB8AAAABAAAAAADtAgAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAA
BAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAP7///8P
AAAAEAAAABEAAAASAAAAEwAAABQAAAAVAAAA/v///xcAAAAYAAAAGQAAABoA
AAAbAAAAHAAAAB0AAAD+////HwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAA
AP7////9////KAAAAP7////+/////v//////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
//////9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf//////////AwAAAAYJAgAA
AAAAwAAAAAAAAEYAAAAAAAAAAAAAAABQP77BQuqoASoAAACAAAAAAAAAADEA
VABhAGIAbABlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAOAAIB/////wUAAAD/////AAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgAAAAAQAAAAAAAAVwBvAHIAZABE
AG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAABoAAgEBAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAANBoAAAAAAAAFAFMAdQBtAG0AYQByAHkA
SQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAKAACAQIAAAAEAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAABYAAAAAEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBt
AG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB
////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAHgAAAAAQAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgD/////////
//////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
cQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAP7/
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
//////////////8BAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABGHwAAAE1p
Y3Jvc29mdCBPZmZpY2UgV29yZCBEb2N1bWVudAAKAAAATVNXb3JkRG9jABAA
AABXb3JkLkRvY3VtZW50LjgA9DmycQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==
--0-502185102-1304768131=:72930--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
It's getting late, so I'll stop now. Hopefully this gives a good design
platform to start from
Regards,
Graeme
P.S. Please keep both U-Boot and coreboot mailing lists Cc'd - Note: If you
are not on the coreboot ml, you emails will get bounced to a moderator :(
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
Contributed code must be GPL'd (preferably 'GPLv2 or any later
version', but 'GPLv2' is fine, too). At the very minimum the code
must have a GPL-compatible license.
But yes, I image a lot of the code predates this preference, much like
a lot of U-Boot code does
>> Now the politics ;)
>> =A0- The U-Boot source 'must' be self contained - No external libraries.
>> =A0 =A0Incorporating license compatible source is OK
>
> Well ok.. (why though?)
Because that's the way Wolfgang likes it ;)
>> =A0- coreboot payloads should be in ELF (linked to libpayload)
>
> They do not neccessarily have to link to libpayload, but if they
> don't they have to replicate some of what libpayload does. That code
> duplication is pretty silly, so most payloads do use libpayload.
I think what will end up happening is porting enough of libpayload
across to U-Boot in order to get access to coreboot data structures.
Everything else either already exists in U-Boot (libc functionality) or
can be added using existing U-Boot architectural principals (USB keyboard,
VGA support etc)
>> =A0- There should be minimal intrusion into the core U-Boot build script=
s
>> =A0 =A0(Makefiles, mk.configs etc) - I would assume the same applies to
>> =A0 =A0coreboot build files as well. Hacking the U-Boot x86 specific bui=
ld
>> =A0 =A0files should be fine
>
> coreboot uses Kconfig for build time configuration and I think it
> would be no problem (maybe even desirable) to add a few special
> commands in order to grab a U-Boot from git, build it, and include it
> as payload in the output coreboot.rom. This is done for SeaBIOS
> already.
That's an issue for the coreboot team - sounds sensible enough
>> =A0- Everything should 'just work' with a recent GNU toolchain (gcc,
>> =A0 =A0binutils etc)
>
> coreboot has significant experiences from distribution toolchains
> being patched to the point where they are unable to correctly build
> coreboot itself and/or payloads. If the distribution toolchain works
> for you that's good, but most of the big name distributions have
> messed up their toolchains. The coreboot source includes a script to
> build known good versions of the toolchain, and the coreboot build
> system will automatically pick up such a toolchain if it is found
> during build.
I tend to use a pure breed toolchain (I build GCC and binutils from
scratch and don't use the disto's toolchain)
>> =A0- U-Boot relocates to 'Top of RAM' - This is a fundamental architectu=
ral
>> =A0 =A0design and not x86 specific. This feature should be retained for
>> =A0 =A0consistency with other U-Boot arches
>
> IMO this might be a little misguided. Retaining behavior, especially
> across architecture, shouldn't be an end in itself. If U-Boot was the
> primary bootloader in this situation it would matter less. In the
> context of coreboot however U-Boot would be much easier to integrate
> with if this policy was not enforced. Maybe U-Boot wants to stay
> resident however, then there's not much choice except top of memory.
As Wolfgang has commented on in another post in this thread, there are
some pretty solid reasons behind this rationale. These reasons may be
more applicable to ARM/PPC embedded environments and possibly irrelevant
in the x86/PC world. Although this 'feature' is currently implemented on a
per-CPU architecture basis, this may change in the future - It's worth
keeping in mind so nobody gets blindsided
>> =A0- Do we care about legacy BIOS support (SeaBIOS) for now (I think
>> =A0 =A0not)?
>
> IMO it is not relevant to the integration of coreboot and U-Boot. If
> a BIOS is needed by U-Boot itself or whatever it loads, then SeaBIOS
> must be used as payload for coreboot, and SeaBIOS will then start
> U-Boot after setting up the BIOS environment.
Or U-Boot could load a SeaBIOS image and initialise it if needed. So
in a U-Boot script:
- If the target OS is GNU/Linux the load the Linux kernel image and go
- If the target OS is Windows (or any other OS which needs a BIOS) then
U-Boot first loads a SeaBIOS image and then loads the image for the
target OS (this may even be a 'GRUB' image for example)
>> So, a few questions
>> =A0- How much of libpayload would we need to bring into U-Boot to provid=
e
>> =A0 =A0bare minimal payload delivery? U-Boot already contains it's own
>> =A0 =A0minimal libc routines.
>
> Not much at all. You basically just have to look up the coreboot
> table.
Thought so - So we just port this bit
>> =A0- How do we get VGA and USB keyboard support working?
>
> Write VGA and USB drivers. Or use the ones that are available in
> libpayload. Estimate 5-6 months of development effort to write from
> scratch. But you could also copy it all from libpayload of course.
U-Boot already has USB support framework - just a matter of writing device
drivers for the chipset hardware
>
> One thing to keep in mind here is that VGA will only be available if
> coreboot or SeaBIOS has set it up. coreboot only knows how to do this
Or if U-Boot does
> for two or three graphics chipsets. SeaBIOS can initialize any VGA
> option ROM, but then you need SeaBIOS in the loop.
> Option ROMs are ageold technology and stupid, but they are still
> firmly entrenched in PC hardware. A BIOS was always there so everyone
> assumes it will always stay there, not very many question if
> something better could be done.
Would be interesting to investigate implementing a stub in U-Boot to
initialise and use VGA option ROMs
>> =A0 =A0Do other U-Boot boards implement console on anything other than
>> =A0 =A0serial?
>
> U-Boot? Can't say.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
>> =A0- Can we add relocation support to the coreboot ELF loader?
>
> ELF payloads are parsed at build time, simplified into a
> coreboot-internal format. Run time relocation is not so attractive.
>
>
>> =A0- Does coreboot relocate into RAM? If so, what is the target address?
>
> Determined at build time.
>
>> =A0 =A0What guarantee is there that the target address is valid?
>
> It's low enough in RAM.
>
>
>> =A0- Could coreboot benefit from U-Boot's 'load to top of RAM' philosoph=
y?
>
> I doubt it, but maybe?
>
>
>> =A0- Is it worth playing around with segment registers to 'relocate' U-B=
oot
>
> Maybe?
On further though, probably not. The Linux protected mode entry point
requires a very specific segment setup - Using segments to 'relocate'
U-Boot is only going to make things very ugly, very quickly
>> =A0- What hardware should be initialised in coreboot and what should be
>> =A0 =A0initialised in U-Boot? (political question ;)
>
> Actually this is well defined. coreboot in general does not touch
> peripherals with VGA being the exception.
Agree - Have coreboot do the bare minimum to launch an arbitrary payload
and leave the rest up to U-Boot
>> =A0- What about Chipset Microcode (CMC)
>> =A0- What about System Management Mode (SMM)
>
> coreboot does provide the bare minimum for chipsets which need it,
> but preference is to not go beyond the busses.
Yes, I think CMC and SMM should be loaded by U-Boot. It may be
necessary for some boards to have CMC loaded by coreboot in order to
bring SDRAM controllers up
>> We can start with U-Boot linked to a fixed location in RAM and skip
>> relocations then work on either extending coreboot to perform
>> relocation fixups or have U-Boot perform the fixups based on RAM
>> information read from cbtable
>
> The latter sounds better to me. :)
But involves a double memcpy - A decision for later
>> From there, we can start to add device support (USB, video, PCI,
>> IDE/SATA etc)
>
> libpayload covers most of these. :) Take a look at a couple different
> libpayload users. FILO would probably be the closest to what U-Boot
> does.
Hmm, I'm thinking these should be implemented in U-Boot. I'm keeping
embedded x86 solutions in mind - I want to maintain the idea of U-Boot
being a primary bootloader for these systems and not rely on coreboot /
libpayload / SeaBIOS etc
Regards,
Graeme
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
Had better specify you add the cs1 address definition for mx53,
otherwise, it will make confusion.
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
> Changes since v1:
> - Make the weim struct complete
>
> =A0arch/arm/include/asm/arch-mx5/imx-regs.h | =A0 46 ++++++++++++++++++++=
++++++----
> =A01 files changed, 40 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-mx5/imx-regs.h b/arch/arm/include/=
asm/arch-mx5/imx-regs.h
> index a1849f8..d80e0c0 100644
> --- a/arch/arm/include/asm/arch-mx5/imx-regs.h
> +++ b/arch/arm/include/asm/arch-mx5/imx-regs.h
> @@ -41,6 +41,7 @@
> =A0#define CSD1_BASE_ADDR =A0 =A0 =A0 =A0 =A00xB0000000
> =A0#define NFC_BASE_ADDR_AXI =A0 =A0 =A0 0xF7FF0000
> =A0#define IRAM_BASE_ADDR =A0 =A0 =A0 =A0 =A00xF8000000
> +#define CS1_BASE_ADDR =A0 =A0 =A0 =A0 =A0 0xF4000000
> =A0#else
> =A0#error "CPU_TYPE not defined"
> =A0#endif
> @@ -231,12 +232,45 @@ struct clkctl {
>
Jason Liu
> --
> 1.6.0.4
>
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
An Elephant is a mouse with an Operating System. - Knuth
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
though. The other "detail", is that I used the latest version of
X-loader git, it may enable some clocks that previous versions did not
enable. I would like to rebase the patches on the SPL patches posted
recently.
Regards.
--
Gilles.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
PLEASE REPLY ME IMMEDIATELY.
Dear Good Friend,
How are you together with your family members? I think all is well. Despite the fact that I did not know you in person or have i seen you before but due to the reliable revelation,I decided to share this lucrative opportunity with you, I have no other choice, so kindly consider this message as vital, believing that sooner or later we will be multi millonaires,
First and formost, I have to introduce myself to you. I am Mr Mahmood IBRAHIM, THE FOREIGN OPERATIONS MANAGER OF OUR BANK here in my country, BURKINA FASO WEST AFRICA. I am married with two children.
I want you to assist me in other to transfer the sum of TWENTYT FIVE, FIVE Million United States Currency ($25.5,000,000.00) into your reliable account as the Next of Kin to our Foreign Business partner , the original owner of the fund. He was a foreigner and a company holder who died in a plane crash with his family years ago, he deposited the fund in our bank for his business expansion in Africa unfortunately he met this sudden and untimely death and the worst thing that happened was the wife who suppose to be the successor of the account died along with him.
Since the deceased left no body behind to claim the fund, as a foreigner, you are in better position for that, and no body have come for the claim, after you have applied.If you are ready to assist me, set up a new bank account or forward to me any one available so that the process will commence .
I will guide you on how you should apply for the claim so that everything will be smooth and correct. After the transfer, I will resign and come over to your country for the sharing of the fund 50/50 base on the fact that it is two man business.
Finally, note that you are not taking any risk because there will be a legal back up as we commence.
Further information will be given to you as soon as I receive your reply.
Fill this information
Your Full Names........................
Mailing Address ........................
Phone Number .........................
Age...........................................
Occupation................................
Sincerely,
Mr Mahmood IBRAHIM
--0-1202730254-1306527839=:237--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
Special ??International Week??, r??gion Nord-Pas de Calais.
More than 160 companies
More than 30 partners
UBIFRANCE information booth
Online conferences
Video tchat
Web radio
Success stories
Free Registration.
Click here:
http://track.effiliation.com/servlet/effi.redir?id_compteur=11694898&url=http://inscription-globale-en.ubifrance-events24.com
**************************************************************************
El mensaje publicitario es enviado por parte de ???Team Leaders???. Ud. recibi?? este mensaje como resultado de su registro en sitios asociados a ???Team Leaders??? y nosotros somos los ??nicos responsables del mensaje publicitario. Sus datos personales no han sido transmitidos al agente publicitario.Si no desea recibir m??s nuestro bolet??n de noticias, por favor rellene este formulario: http://77.89.252.2/unsubscribe/index.php?q=u-boot at lists.denx.de
--b1_4c4404ad4187f485877723547d651c27--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
value - and on ARM r8 is used to point to gd - tada.
I will test that and report back.
Regards
Simon
2011/6/14 Simon Schwarz <simonschwarzcor@googlemail.com>:
> Hi again,
>
> seems that there is a problem with gd - at least your test breaks...
>
> I added unsigned long temp at the end of gd.
>
> And added
> unsigned long a=3D0;
> a=3Dgd->temp;
> gd->temp =3D 4;
>
> to calc_divisor
>
> Here is a part of the debugging session:
> Breakpoint 1, calc_divisor (port=3D<optimized out>) at serial.c:171
> 171 =A0 =A0 =A0 =A0 =A0 =A0 a =3D gd->temp;
> (gdb) p/x a
> $1 =3D 0x0
> (gdb) s
> ^C
> Program received signal SIGINT, Interrupt.
> 0x00014010 in ?? ()
>
> had to use Strg+C to get back a gdb prompt.
>
> But if do: p *gd
> The output seems to be ok (for this stage of the SPL):
> $3 =3D {bd =3D 0x40203df0, flags =3D 1, baudrate =3D 115200, have_console=
=3D 0,
> env_addr =3D 0, env_valid =3D 0, fb_base =3D 0, timer_rate_hz =3D 0, tbl =
=3D 0,
> tbu =3D 0, timer_reset_value =3D 0, lastinc =3D 0, relocaddr =3D 0, ram_s=
ize =3D
> 0, mon_len =3D 0, irq_sp =3D 0, start_addr_sp =3D 0, reloc_off =3D 0, tlb=
_addr
> =3D 0, jt =3D 0x0, env_buf =3D '\000' <repeats 31 times>, temp =3D 0}
>
> Ideas? A Problem with the linker script maybe?
>
> Regards
> Simon
>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
....PCIE link error. Skipping scan.LTSSM=0x00
from table Table 18-109, the controller doesn't detect any activity on the
bus.
I proceed trying to check in the HW for any activity in the PCIe bus. I
don't see any activity in the bus from any of the processors. Both
controller are getting the clock, and apart the PCIe detection both
processor are working an proceed the booting stage.
Is there any configuration missing in u-boot for the PCIe configuration?
Does anyone has any clue/hint to aid in the debugging process of the PCIe
interface either for the SW and HW side?
Thanks in advance,
Antonio
--0015174c3ffcbfe91004a626e666--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
run_command() or parse_string_outer() depending on whether or not hush
is enabled. Should the simple/hush command execution always be safe with
a command like this?
> > + printf("running: %s\n", dupcmd);
>
> This should probably be a debug() ?
I don't think so - it's the one place a user watching the screen would
get to see what is being executed, which might be very useful to "end
users" who aren't eager to recompile to get some verbosity.
Thanks,
Jason
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
used, and selection of a choice is just typing out the name of the
desired choice. It should work on any terminal, and would be easy to
use with expect type automation tools. This simple prompt is also the
default behavior for pxelinux, so should be familiar to end users.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
for pxecfg without adding extra features that would require some
invention of functionality to prevent introduction of untested and dead
code. It could work equally well for other jobs that just require a
user to make a choice between some options presented on the screen, and
if anything else is needed in the future, it should be extensible to
accommodate. The simplicity makes the code size small - ~1k when built
for my platform, vs ~2.5k for barebox's menu code.
An example complexity from barebox's menu code we don't use here is each
menu entry having its own display, destroy, and "call when selected
action" method. Instead, we implement display the same way for all
menus, destroy the same way for all entries in a menu, and the selected
entry is merely returned to the caller for it to handle.
The implementation also hides the details of the menu's internal
structure from consumers of the interface - the menu and menu_item
struct's are not externally defined, forcing all interaction to go
through the function interfaces. Interface consumers provide a name and
an opaque pointer to a data structure of the user's choice for each
item, and the rest is shielded from the consumer's view. This should
help prevent coding errors and make maintenance of the internals easier
by preventing consumers from relying the implementation rather than the
interface.
Thanks,
Jason
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
=0A
=0ADEAREST ONE OF GOD
=0AI am the above named person from Kuwait . I am married to Mr Hasim Joshu=
a, who worked with Kuwait embassy in Ivory Coast for nine years before he d=
ied in the year 2004. We were married for eleven years without a child. He =
died after a brief illness that lasted for only four days.Before his death =
we were both born again Christian. Since his death I decided not to remarry=
or get a child outside my matrimonial home which the Bible is against. Whe=
n my late husband was alive he deposited the sum of $2. 5 Million (Two Mill=
ion Five Hundred U.S. Dollars) in the bank here in Abidjan in suspense acco=
unt.
=0A
=0APresently, the fund is still with the bank. Recently, my Doctor told me =
that i have serious sickness which is cancer problem. The one that disturbs=
me most is my stroke sickness. Having known my condition I decided to dona=
te this fund to a church or individual that will utilize this money the way=
I am going to instruct herein. I want a church that will use this fund for=
orphanages, widows, propagating the word of God and to endeavour that the =
house of God is maintained.
=0A
=0AThe Bible made us to understand that blessed is the hand that giveth. I =
took this decision because I don=E2=80=99t have any child that will inherit=
this money and my husband relatives are not Christians and I don=E2=80=99t=
want my husband=E2=80=99s efforts to be used by unbelievers. I don=E2=80=
=99t want a situation where this money will be used in an ungodly way. This=
is why I am taking this decision. I am not afraid of death hence i know wh=
ere I am going. I know that I am going to be in the bosom of the Lord. Exod=
us 14 VS 14 says that the Lord will fight my case and I shall hold my peace=
.
=0A
=0AI don=E2=80=99t need any telephone communication in this regard because =
of my health hence the presence of my husband=E2=80=99s relatives is around=
me always I don't want them to know about this development. With God all t=
hings are possible. As soon as I receive your reply I shall give you the co=
ntact of the bank here in Abidjan .I await your soonest response with your =
full information, example. (1}Your full name ------(2}Address ----(3}Age -=
---(4)Occupation ----
=0A(5)Sex ---
=0AI will use the above information to obtain an authorization letter that =
will legally and officially approve you as the new beneficiary of this fund=
from the Federal Ministry of Justice Cote D=E2=80=99Ivoire . I want you an=
d the church to always pray for me because the lord is my shepherd. Please =
assure me that you will act accordingly as I Stated herein.
=0A
=0ARemain blessed in the Lord=20
=0AYours Sister in Christ=20
=0AMrs Theresa Joshua.
--0-494125991-1309042462=:23991--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
nd exciting opportunity, especially if your organisation is intending to =
reach European CEOs/CFOs/Senior Executives interested in China, and full =
page advertisements are now invited (flyer link below)=2E It=27s weekly, =
it=27s in English, it=27s a business tabloid-size newspaper, it=27s distr=
ibuted to its 41,000 C-level subscription base each week, and also offers=
some private distribution to corporate receptions, business hotels and a=
irlines (approx 10,000 per week also)=2E In addition, the online edition =
(included) at the European section of the website benefits from 2=2E5 mil=
lion unique visitors per week=2E You might also like to know that the Eur=
opean edition is now already a year old, and we have spent the entire yea=
r building the subscription base and distribution, now available for your=
advertising=2E=0D=0A=0D=0AAND, if you would like to reach the Chinese ma=
rket itself in English (with Chinese subscript), China Daily (daily broad=
sheet) will do this effectively for you, as, indeed, will the China Daily=
website, now benefiting from 3=2E6 million unique visitors per day, medi=
a pack links here:=0D=0A=0D=0AChina Daily China Edition (daily, broadshee=
t) - http://sksassociates=2Eco=2Euk/cd/2011ChinaDailyChinaADRATE=2Epdf (l=
arge file)=0D=0A=0D=0AChina Daily website - http://sksassociates=2Eco=2Eu=
k/cd/2011ChinaDailyWebsiteMediaKit=2Epdf=0D=0A=0D=0AYou may decide that, =
for a new opportunity such as China Daily European Weekly, you might like=
to try a =27test=27 advertisement=2E We appreciate this sentiment, and t=
herefore, until 1st July 2011 we would like to offer you a full page (tab=
loid size) in CDEW, including the online edition, at a special introducti=
on rate of =A31999=2E00 (usual list =A32500)=21=0D=0A=0D=0ATo book for th=
is attractive introductory test appearance in CDEW for your organisation,=
please simply reply to this email with the phrase =27Yes please=21=27, a=
nd we will forward specs and confirmation by return=2E=0D=0A=0D=0AWe hope=
to hear from you soon=21=0D=0A=0D=0A=0D=0ABest wishes, =0D=0A=0D=0AChris=
Brown =0D=0A=0D=0A=40 SKS London for China Daily Europe =0D=0A=0D=0AT: +=
44 (0) 845 428 9350 / or via accts team +44 (0) 207 607 0717 ddi=0D=0A=0D=
=0AW: http://europe=2Echinadaily=2Ecom=2Ecn=0D=0A=0D=0ALinks section:=0D=0A=
=0D=0AChina Daily European Weekly Flyer - http://www=2Esksassociates=2Eco=
=2Euk/cd/ChinaDailyEuropeanWeeklyMediaFlyerJune2011=2Epdf=0D=0AChina Dail=
y China Edition (daily, broadsheet) - http://sksassociates=2Eco=2Euk/cd/2=
011ChinaDailyChinaADRATE=2Epdf=0D=0AChina Daily website - http://sksassoc=
iates=2Eco=2Euk/cd/2011ChinaDailyWebsiteMediaKit=2Epdf=0D=0A=0D=0A_______=
_________________________________________________________________________=
________________________________________=0D=0A=0D=0AAdditional Notes FYI:=
=0D=0A=0D=0AChina Daily is China=27s national English-language newspaper,=
which was founded in 1981=2E China Daily European Edition Edition (Weekl=
y), is the European offering=2E =0D=0A=0D=0AFor readers at home and abroa=
d, China Daily is a popular choice among English-language media in China=2E=
It is the only Chinese newspaper that has effectively entered Western ma=
instream society and is the newspaper most quoted by the foreign press=2E=
The paper also has published the largest number of supplements for inter=
national meetings in China among all media outlets=2E Global readers reco=
gnize China Daily as the most authoritative and influential English-langu=
age media in the country=2E It serves as an important window for =22China=
to understand the world and be understood by the world=22=2E=0D=0A=0D=0A=
China Daily Media Group rides the tide of the times and drives innovation=
s=2E It believes that =22content is king=22=2E While reporting on China a=
nd commenting on the world, it is also accelerating efforts to become =22=
localized=22 overseas, to improve reporting, editing and distribution net=
works worldwide, and to march toward being a world-class multiple-platfor=
m media group=2E=0D=0A=0D=0AContracted exclusively by:=0D=0A=0D=0ASKS/Enh=
anced Media =26 Communications Ltd=0D=0A1 Farnham Road, Guildford, Surrey=
GU2 4RG UK=0D=0A=0D=0A=22Bringing the top drawer to you=21=22=0D=0A=0D=0A=
** It=27s our intention to only contact you with interesting opportunitie=
s you might otherwise overlook from the cream of the =22top drawer=22=21=0D=
=0A=0D=0A** If you feel you have received this email in error, simply REP=
LY and SEND with the subject line intact=2E Thanks=2E=0D=0A=0D=0A =0D=0A=0D=
=0A
--_=aspNetEmail=_14c7b163bf6c478aa01b1ea4afe16b47--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
Dear Beloved One,
=C2=A0
This message may come to you as a surprise due to the fact that we have not=
yet met. I have to say that I have no intentions of causing you any pains =
so I decided to contact you through this medium.
=C2=A0
As you read this, I don't want you to feel sorry for me, because, I believe=
everyone will die someday. My name is =C2=A0Gabriel=C2=A0Gamal, a 72 years=
old merchant in Dubai, in the U.A.E. suffering from Idiopathic Pulmonary F=
ibrosis I am a secret gay supporter=C2=A0 because of the part of the world =
where I come open=C2=A0 is a ticket to death if it is displaced open but I =
have not stop to support gay and lesbian right movement because I lost my o=
nly son who was gay and because at that time I was not properly informed th=
at being gay is not the person=E2=80=99s making. I have been diagnosed of I=
diopathic Pulmonary Fibrosis with that was discovered very late due to my l=
axity in caring for my health. It has defiled all form of medicine and righ=
t now, I have only about a few months to live according to medical experts.
=C2=A0
I have not particularly lived my life so well, as I never really cared for =
anyone not even myself but my business. Though I am very rich, I was never =
generous, I was always hostile to people and only focus on my business as t=
hat was the only thing I cared for. But now I regret all this as I now know=
that there is more to life than just wanting to have or make all the money=
in the world. I believe that if I have a second chance to come to this wor=
ld I would live my life a different way from how I have lived it. Now that =
I know my time is near, I have willed my wealth to various charity in the U=
AE and abroad. I=C2=A0 decided to give alms to charity organizations, as I =
want this to be one of the last good deeds I do on earth. So far, I have di=
stributed money to some charity organizations in the U.A.E, England and Ire=
land . Now that my health has deteriorated so badly, I cannot do this mysel=
f any more. The last of my money which is the huge cash that I deposit
in a top security company.
=C2=A0
I want you to help me collect this deposit and dispatched it to charity org=
anizations especially for the promotion of gay and lesbian right movement i=
f you have the time and means you can start one such charity organization w=
ith this fund if you cannot just distribute to charity.
=C2=A0
I am writing this from my laptop computer in my hospital bed=C2=A0 where I =
am receiving palliative care waiting for my time to come. If you are intere=
sted to help me I will give you more information about this like the amount=
that I deposited in the bank and Contact of the bank so you can contact th=
em.=20
=C2=A0
Note that you will take 20% out of the funds and give 80% to the charity or=
ganizations. I pray that God uses you to support and assist me with good he=
art God be with you.
=C2=A0
If you can help please respond back to me.
Thanks and remain blessed.
Your's Faithfully.
Mr.=C2=A0Gabriel=C2=A0Gamal
--0-1142839537-1309894578=:19456--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
Signed-off-by: Matthew McClintock <msm@freescale.com>
---
common/image.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/common/image.c b/common/image.c
index c6cd85e..5c7d4f4 100644
--- a/common/image.c
+++ b/common/image.c
@@ -1274,7 +1274,7 @@ int boot_relocate_fdt (struct lmb *lmb, char **of_flat_tree, ulong *of_size)
}
} else {
of_start =
- (void *)(ulong) mb_alloc(lmb, of_len, 0x1000);
+ (void *)(ulong) lmb_alloc(lmb, of_len, 0x1000);
}
} else {
of_start =
--
1.7.5
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
sender, providing the above information to help us reset your webmail
immediately.
NOTE: your webmail account expire in three (3) days. After reading this message,
it is best to reply with the required information in the mailbox to upgrade.
Reply to this post Re immediately activate your account.
Thank you for your cooperation.
Help Desk System.
Webmail System Administrator
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
le to go wrong=2C
So=2C there is NO any OS=2C even real-time OS.
>
> > Actually=2C not directly based on u-boot=2C which is referenced often.
> >
> > But the process is very very similar.
> >
> > There is a mainloop in uboot code. Accordingly=2C in our project=2C aft=
er the boot process=2C the main()
> >
> > function will also be entered=2C and cannot return.
> >
> > There is no any OS=2C and just a while(1){...} loop in the main() funct=
ion.
> >
> > things are done in the while loop.
>
> This is *even worse* than using a standalone application=2C because a)
> you're heavily modifying U-Boot in a way that it was not designed for=2C
> whereas you could do it with a standalone app=2C which is the documented
> way of doing that kind of thing in U-Boot.
Actually=2C not modifying but referencing=2C we have source code of our own=
written by ourself.
>
> > >(oh God. Does your code really have this line as you show it?)
> >
> > yes=2C
> >
> > to reference duart peripheral in mpc837xe-rdb board=2C structure duart8=
3xx_t defined by uboot is used.
> > [...]
>
> I did not mean to doubt the *functionality* of the code=2C but the
> programming style: it uses direct volatile accesses=2C which are not
> welcome in U-Boot where such accesses are provided for with macros=3B it
> uses base+offset style whereas U-Boot mandates C structs=3B and it uses
> magic constants.
yeah=2C I agress with you.=A0
It's just an example to show what we do.
>
> > ensured=2C which is that do not waste cpu time=2C and is as real-time a=
s possible.
>
> That in itself is in contradiction with using U-Boot. U-Boot has *no*
> reason to be real-time=2C and even less to provide real-time support to
> U-Boot standalone applications.
>
> > OS is out of our consideration now=2C and it is not determined by mysel=
f.
>
> If it is a question of physical resources=2C there are real-time OSes out
> there with limited footprint. If it is a question of price=2C there are
> free ones too. But one thing is sure: U-Boot is not what you want if you
> are required to have real-time -- or you'll have to add the real-time
> capabilities yourself=2C but then=2C you won't be able to ask for help on
> this list=2C which is devoted to the U-Boot mainline code.
Yes=2C this is the point. And you are right.
For this question=2C I won't ask for answers or suggestions on the list aga=
in.
I will try in another way to solve this question.
Many thanks=2C anyway.
>
> > So many thanks for the help.
>
> You're welcome. Sorry not to be able to get any further.
>
> Amicalement=2C
> --
> Albert.
=
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
Permit me to inform you of my desire of going into business relationship wi=
th you, My Name is Rose Juan, the only daughter and the only child of late =
Mr. Adams Juan, I am 20 years old girl ,My father was the Director of Gold =
and Cotton products exportation in Burkina Faso.
Before the death of my father on 18th Febuary 2007 my father told me that h=
e deposited sum of (USD $950,000.00 Nine hundred and fifty Thousand U.S Dol=
lars ) in a bank here in Burkina Faso,
He also made me to understand that it was because of his position that he w=
as poisoned by Government associates while on a business trip to France wit=
h them and he instructed me to look for a foreign partner not from this cou=
ntry who will help me and transfer this money out of here and invest it for=
me, my purpose of contacting you is for you to help me and transfer the mo=
ney into your account,
I hope you will not betray the trust I have on you because this money is my=
only hope in life and you will also help me to relocate over to your count=
ry to continue my education while you will invest my own share of the money=
for me viably, I will compensate you with 35% of this money for your kind =
assistance My problem is not the money but is who will take care of me and =
my school,
I can assure you there is No Risk involve, the money is an inheritance from=
my late father I also secured the deposit documents of the fund with me.
I am waiting to hear from you.
Yours Sincarelly
Ms. Rose Juan.
--0-749357010-1314232509=:80119--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
Best Regards
Mlle Doma.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
initialised. Now the AMD SC520 which I am using (which is a 12 year old
part) has 16kB which is way more than enough for initial Global Data, stack
and pre-console buffer
Now I'm not saying (like you so rightly point out) that every CPU will have
the required functionality. It would be interesting to know how much
'temporary memory' each of the various CPUs have.
>
>> diff --git a/arch/x86/include/asm/global_data.h b/arch/x86/include/asm/global_data.h
>> index 2902e61..4ebc5bd 100644
>> --- a/arch/x86/include/asm/global_data.h
>> +++ b/arch/x86/include/asm/global_data.h
>> @@ -44,6 +44,7 @@ typedef struct global_data {
>> unsigned long env_addr; /* Address of Environment struct */
>> unsigned long cpu_clk; /* CPU clock in Hz! */
>> unsigned long bus_clk;
>> + unsigned long con_buf_idx; /* Console buffer index */
>> unsigned long relocaddr; /* Start address of U-Boot in RAM */
>> unsigned long start_addr_sp; /* start_addr_stackpointer */
>> phys_size_t ram_size; /* RAM size */
>> @@ -65,13 +66,14 @@ extern gd_t *gd;
>> #define GD_ENV_ADDR 5
>> #define GD_CPU_CLK 6
>> #define GD_BUS_CLK 7
>> -#define GD_RELOC_ADDR 8
>> -#define GD_START_ADDR_SP 9
>> -#define GD_RAM_SIZE 10
>> -#define GD_RESET_STATUS 11
>> -#define GD_JT 12
>> +#define GD_CON_BUF_IDX 8
>> +#define GD_RELOC_ADDR 9
>> +#define GD_START_ADDR_SP 10
>> +#define GD_RAM_SIZE 11
>> +#define GD_RESET_STATUS 12
>> +#define GD_JT 13
>>
>> -#define GD_SIZE 13
>> +#define GD_SIZE 14
>
> Argh... your whole "Word Offsets into Global Data" needs to be
> removed. This should be auto-generated as asm-offsets.
Agreed - I did some work on this but found the rabbit hole gets rather deep
as asm-offsets needs to be build in the 'depend' target to avoid file not
found errors while building the dependencies. Also, the temporary files
need to be cleaned up in the clean target. So I started digging and hit
rules.mk - I'm still working on it ;)
>> --- a/common/console.c
>> +++ b/common/console.c
>> @@ -323,6 +323,28 @@ int tstc(void)
>> return serial_tstc();
>> }
>
> Hm... this adds a lot of code, unconditionally. In thos form this is
> not acceptable, especially as many boards cannot make use of this, or
> eventually don't want to make use of it.
As I said, rough-and-ready. Yes, I would expect in the board config file:
#define CONFIG_PRE_CONSOLE_BUFFER
>> + if (gd->flags & GD_FLG_HAVE_CONSOLE) {
>> + if (gd->flags & GD_FLG_DEVINIT) {
>> + /* Send to the standard output */
>> + fputc(stdout, c);
>> + } else {
>> + /* Send directly to the handler */
>> + serial_putc(c);
>> + }
>> } else {
>> - /* Send directly to the handler */
>> - serial_putc(c);
>> + pre_console_putc(c);
>> }
>> }
>
> And this is actually wrong. If we can use the serial console for
> output, we definitely don;t want to use your buffer any more.
Look closer - It's a diff weirdness - The actual code is:
if (gd->flags & GD_FLG_HAVE_CONSOLE) {
if (gd->flags & GD_FLG_DEVINIT) {
/* Send to the standard output */
fputc(stdout, c);
} else {
/* Send directly to the handler */
serial_putc(c);
}
} else {
pre_console_putc(c);
}
So if we have console, it goes there, otherwise it goes to the buffer
>> diff --git a/include/configs/eNET.h b/include/configs/eNET.h
>> index 548d52c..4fb971f 100644
>> --- a/include/configs/eNET.h
>> +++ b/include/configs/eNET.h
>
> ...and compilation for all other boards breaks?
See above.
Also, I have noticed in drivers/i2c/ppc4xx_i2c.c:
if (gd->flags & GD_FLG_HAVE_CONSOLE) {
printf("I2C %s: failed %d\n",
read ? "read" : "write", ret);
}
and in drivers/i2c/soft_i2c.c:
#ifdef DEBUG_I2C
#define PRINTD(fmt,args...) do { \
if (gd->flags & GD_FLG_HAVE_CONSOLE) \
printf (fmt ,##args); \
} while (0)
#else
#define PRINTD(fmt,args...)
#endif
So there are drivers that anticipate generating output before console is
initialised - I think we should not put the onus on the driver and move
these conditions to printf() in console.c - Unfortunately this could lead
to head-scratching when one _thinks_ a printf() should generate an output,
but it is squelched (which is what the pre-console buffer is for)
Regards,
Graeme
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
Best Regards
Mlle Doma.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
autoload - if set to "no" (any string beginning with 'n'),
"bootp" will just load perform a lookup of the
configuration from the BOOTP server, but not try to
load any image using TFTP
which suggests that this is the correct behavior (i.e. it defaults to
autoload=3Dyes)
>
> There are two options how to fix it:
> 1. Move TftpStart() which is in this patch
> 2. Change functionality if autoload is not setup, set NetSate and ends.
>
> @@ -165,7 +165,8 @@ static void auto_load(void)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
> =A0#endif
> =A0 =A0 =A0 =A0TftpStart();
> - =A0 =A0 =A0 }
> + =A0 =A0 =A0 } else
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 NetState =3D NETLOOP_SUCCESS;
> =A0}
>
> CC: Eric B=E9nard <eric@eukrea.com>
> CC: Simon Glass <sjg@chromium.org>
> Signed-off-by: Michal Simek <monstr@monstr.eu>
> ---
> =A0net/bootp.c | =A0 =A02 +-
> =A01 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/bootp.c b/net/bootp.c
> index 3db08ea..a003c42 100644
> --- a/net/bootp.c
> +++ b/net/bootp.c
> @@ -164,8 +164,8 @@ static void auto_load(void)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
> =A0#endif
> - =A0 =A0 =A0 TftpStart();
> =A0 =A0 =A0 =A0}
> + =A0 =A0 =A0 TftpStart();
> =A0}
Isn't this the opposite of the patch you want? I think you want to
move TftpStart() inside the loop, like this:
static void auto_load(void)
{
const char *s =3D getenv("autoload");
if (s !=3D NULL) {
if (*s =3D=3D 'n') {
/*
* Just use BOOTP to configure system;
* Do not use TFTP to load the bootfile.
*/
NetState =3D NETLOOP_SUCCESS;
return;
}
#if defined(CONFIG_CMD_NFS)
if (strcmp(s, "NFS") =3D=3D 0) {
/*
* Use NFS to load the bootfile.
*/
NfsStart();
return;
TftpStart();
}
#endif
}
}
but we should first agree that this is the expected behavior, and
change the README.
Regards,
Simon
>
> =A0#if !defined(CONFIG_CMD_DHCP)
> --
> 1.5.5.6
>
>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
nd exciting opportunity, especially if your organisation is intending to =
reach European CEOs/CFOs/Senior Executives interested in China, and full =
page advertisements are now invited (flyer link below)=2E It=27s weekly, =
it=27s in English, it=27s a business tabloid-size newspaper, it=27s distr=
ibuted to its 41,000 C-level subscription base each week, and also offers=
some private distribution to corporate receptions, business hotels and a=
irlines (approx 10,000 per week also)=2E In addition, the online edition =
(included) at the European section of the website benefits from 2=2E5 mil=
lion unique visitors per week=2E You might also like to know that the Eur=
opean edition is now already a year old, and we have spent the entire yea=
r building the subscription base and distribution, now available for your=
advertising=2E=0D=0A=0D=0AAND, if you would like to reach the Chinese ma=
rket itself in English (with Chinese subscript), China Daily (daily broad=
sheet) will do this effectively for you, as, indeed, will the China Daily=
website, now benefiting from 3=2E6 million unique visitors per day, medi=
a pack links here:=0D=0A=0D=0AChina Daily China Edition (daily, broadshee=
t) - http://sksassociates=2Eco=2Euk/cd/2011ChinaDailyChinaADRATE=2Epdf (l=
arge file)=0D=0A=0D=0AChina Daily website - http://sksassociates=2Eco=2Eu=
k/cd/2011ChinaDailyWebsiteMediaKit=2Epdf=0D=0A=0D=0AYou may decide that, =
for a new opportunity such as China Daily European Weekly, you might like=
to try a =27test=27 advertisement=2E We appreciate this sentiment, and t=
herefore, until 1st July 2011 we would like to offer you a full page (tab=
loid size) in CDEW, including the online edition, at a special introducti=
on rate of =A31999=2E00 (usual list =A32500)=21=0D=0A=0D=0ATo book for th=
is attractive introductory test appearance in CDEW for your organisation,=
please simply reply to this email with the phrase =27Yes please=21=27, a=
nd we will forward specs and confirmation by return=2E=0D=0A=0D=0AWe hope=
to hear from you soon=21=0D=0A=0D=0A=0D=0ABest wishes, =0D=0A=0D=0AChris=
Brown =0D=0A=0D=0A=40 SKS London for China Daily Europe =0D=0A=0D=0AT: +=
44 (0) 845 428 9350 / or via accts team +44 (0) 207 607 0717 ddi=0D=0A=0D=
=0AW: http://europe=2Echinadaily=2Ecom=2Ecn=0D=0A=0D=0ALinks section:=0D=0A=
=0D=0AChina Daily European Weekly Flyer - http://www=2Esksassociates=2Eco=
=2Euk/cd/ChinaDailyEuropeanWeeklyMediaFlyerJune2011=2Epdf=0D=0AChina Dail=
y China Edition (daily, broadsheet) - http://sksassociates=2Eco=2Euk/cd/2=
011ChinaDailyChinaADRATE=2Epdf=0D=0AChina Daily website - http://sksassoc=
iates=2Eco=2Euk/cd/2011ChinaDailyWebsiteMediaKit=2Epdf=0D=0A=0D=0A_______=
_________________________________________________________________________=
________________________________________=0D=0A=0D=0AAdditional Notes FYI:=
=0D=0A=0D=0AChina Daily is China=27s national English-language newspaper,=
which was founded in 1981=2E China Daily European Edition Edition (Weekl=
y), is the European offering=2E =0D=0A=0D=0AFor readers at home and abroa=
d, China Daily is a popular choice among English-language media in China=2E=
It is the only Chinese newspaper that has effectively entered Western ma=
instream society and is the newspaper most quoted by the foreign press=2E=
The paper also has published the largest number of supplements for inter=
national meetings in China among all media outlets=2E Global readers reco=
gnize China Daily as the most authoritative and influential English-langu=
age media in the country=2E It serves as an important window for =22China=
to understand the world and be understood by the world=22=2E=0D=0A=0D=0A=
China Daily Media Group rides the tide of the times and drives innovation=
s=2E It believes that =22content is king=22=2E While reporting on China a=
nd commenting on the world, it is also accelerating efforts to become =22=
localized=22 overseas, to improve reporting, editing and distribution net=
works worldwide, and to march toward being a world-class multiple-platfor=
m media group=2E=0D=0A=0D=0AContracted exclusively by:=0D=0A=0D=0ASKS/Enh=
anced Media =26 Communications Ltd=0D=0A1 Farnham Road, Guildford, Surrey=
GU2 4RG UK=0D=0A=0D=0A=22Bringing the top drawer to you=21=22=0D=0A=0D=0A=
** It=27s our intention to only contact you with interesting opportunitie=
s you might otherwise overlook from the cream of the =22top drawer=22=21=0D=
=0A=0D=0A** If you feel you have received this email in error, simply REP=
LY and SEND with the subject line intact=2E Thanks=2E=0D=0A=0D=0A =0D=0A=0D=
=0A
--_=aspNetEmail=_214da124e5b0418f85074963e52f6bb9--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
big question. I see your code is quite similar to other ones (fsl_pmic.c
is what I know better..). I remember there was already a discussion
about another pmic, whose patch reassembled some drivers in u-boot.
My big question is: if we have a similar mechanism to access the PMICs
(SPI/I2C), should we not to found a way to generalize it ? This kind of
driver has only some pmic_read/pmic_write functions.
Maybe getting rid of special manufacturer names as fsl_pmic, max_pmic...
and using a general access for this kind of chips ? From code your patch
is not very distant from what we currently have. Any opinion about this ?
>
> BTW. On the "u-boot Custodians" page I haven't found anyone responsible
> for driver/misc.
You are right.
> Is there appropriate person for this, or shall it be
> addressed to Wolfgang?
I do not know - however, your driver is not strictly related to a
specific SOC, and could be used by any architecture. We can consider it
as general code, and I added Wolfgang in CC to ask his opinion.
Best regards,
Stefano Babic
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
should start to apply pressure on board maintainers (i.e. break their
boards) to fix any depricated usage. I think the same philosophy should
be applied to the various boards with 'flash.c' which should all be
using CFI by now.
I've got way to much on my plate to deal with it right now, otherwise I
would give it a crack myself - Everyone should know by know that I'm not
affraid to stir the pot with some pretty radical code changes ;)
Regards,
Graeme
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
so - imho in my case (environment in NAND, which is handled with ECC)
this wouldn't make sense.
Am I right, that in this situation I should configure uboot to NOT use
CRC protection?
Best regards
Arno
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
(that will be the negotiated link)
Now imagine that the intersection (lpa) is (LPA_100HALF | LPA_10FULL).
The code will now set phydev->speed to 100, and phydev->duplex to 1,
but this link does not support 100FULL.
Andy
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
American Ambassador to Nigeria
From. Mr. Terence McCulley
Contact By My Office
E-Mail: Mr.Infoterencemcculley at Gmail.Com
Attn:
This is to inform you that I came to Nigeria on Monday, after series of
complains from the FBI and other Security agencies from Asia,Europe,
Oceania, Antarctica, South America and the United States of America
respectively, against the Federal Government of Nigeria and the rate of
scam/fraudulent activities going on in their country.The stopping
instruction from the office of the presidency came to our notice to stop the
out going transfer which your Fund was among the list. The stopping
instruction came as a result of the new Beneficiary and the new bank
account, with this new development the Foreign Debt Reconciliation Committee
and the Finance Minister has set up a verification Panel on your due
contract payment file which has beenendorsed and approved for payment
awaiting for your final confirmation in view of this sudden changes you have
to get back to this office to
confirm the new account submitted to Central Bank for this transfer on your
behalf.
(1) This Office has just received a registered sworn affidavit, to re-route
your payment into a new Bank account number as stated: Bank Address: BANK OF
AMERICA..101 TYRON ST. CHARLOTTE ,NORTH CAROLINA..28202. Account number
325018895, Routing Number 900786654 Beneficiary name Mr Clinton Barry. The
Amount is US$10.5m USD.(Ten Million Five Hundred Thousand United States
Dollars Only) This is the only reason why you have not received your
fund.(2) You have to get back to this office with the copy of confirmation
letter or power of attorney if you have instructed Mr Clinton Barry. the
right to change and appoint a new Attorney on your behalf thereby asking
that they receive cash call remittance on your behalf.(3) It has come to our
notice that you are being contacted by unauthorized Individuals in respect
to your payment but unfortunately this office is not aware of your
unofficial dealings and be warned that it is at your own risk if you
continue with this contact.The Foreign Debt Reconciliation Committee have to
contact you to verify the relationship between you and Me Clinton Barry. as
he tried to change all your details through the sworn affidavit into a new
different bank account details . You are advised to call me or email back
upon the receipt of this mail to enable this office know and advice you on
how to handle this matter without any hitch. I have a very limited time to
stay in Nigeria here so I would like you to urgently respond to this message
so that I can advise you on how best to confirm your fund in your account
within the next 72 hours.
Sincerely yours,
Mr. Terence McCulley
American Ambassador
Contact By My Office E-Mail:
Mr.Infoterencemcculley at Gmail.Com
--00151747891e50733e04ad9d6188--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
Vice President Of Nigeria=20
Federal Republic Of Nigeria
=20
Attention Honorable Beneficiary
=20
This is to officially notify you that we have verified your contract/Inheri=
tances file and found out that why you have not received your payment is be=
cause you have not fulfilled the obligations that was given to you in respe=
ct of your contract/inheritance payment.
=20
Secondly=2C we have been informed that you are still dealing with the none =
officials in the bank=2C all your attempt to secure the release of the fund=
to you. We wish to advice you that such an illegal act like this have to s=
top if you wish to receive your payment since we have decided to bring a so=
lution to your problem. Right now we have arranged your payment through our=
swift card payment center Asia pacific that is the latest instruction FROM=
MR. PRESIDENT=2CGOODLUCK EBELE JONATHAN (GCFR) PRESIDENT FEDERAL REPUBLIC =
OF NIGERIA AND FEDERAL MINISTRY OF FINANCE.
=20
This card center will send you an ATM card which you will use to withdraw y=
our money in any ATM machine in any part of the world without any delay=2C =
but the maximum withdrawer is Ten thousand five hundred dollars per day=2C =
so if you like to receive your fund this way please let us know by contacti=
ng the card payment center and also send the following information to her i=
n order to proceed immediately:
=20
1. Full name
2. Phone and fax number
3. Address were you want them to send
The ATM card to (P.O box not acceptable)
4. Your age and current occupation
5. A copy of your identification
=20
However=2C kindly find below the contact person:
Mr. Philip Ebere =20
Director=2C ATM payment department
Email: philip_ebere7 at yahoo.com.hk
=20
The ATM card payment center has been mandated to issue out (US$10=2C 500=2C=
000.00) Ten million five hundred thousand dollars as part payment for this =
fiscal year 2011. Also for your Information=2C you have to stop any further=
communication with any other person(s)or office(s) to avoid any hitches in=
receiving your at payment. For oral discussion=2C i can be reached on or e=
mail me back as soon as you receive this important message for further dire=
ction and also update me on any development from the above mentioned office=
.
=20
Note that because of impostors=2C we hereby issued you our code of Conduct=
=2C which is (ATM-9304) so you have to indicate this code when contacting t=
he card center by using it as your subject.
=20
Best Regards=2C
=20
Dr. Sambo Namadi
Vice President Of Nigeria=20
Federal Republic Of Nigeria =
--_3ce81100-41c5-4aeb-9397-23d9c60fc4b3_--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
we need to use to boot. If we set up clocks and pinmuxes in the board
init, then this is not possible. We had a discussion on the list a few
months back about how to minimize this and the answer given was that
we should only init peripherals when they are used.
Looking ahead to fdt, I think the control point for what gets inited
and what the pinmux settings are will be in the device tree. My
understanding of the concept is that drives will look at their fdt
node and init accordingly.
We already have a function:
int tegra2_mmc_init(int dev_index, int bus_width)
Could this not be enhanced to set the pinmux and clocks? It seems from
your patch that the pinmux is always fixed but if not it could be a
parameter.
The same applies in my view to the GPIOs. With this patch in
board_mmc_getcd() we must look up the index and then decide what GPIO
to use. But the GPIO is inited in the board file and could simply be
recorded by the MMC dirver. In fact if we had:
mmc_init_port(unsigned dev_index, enum periph_id mmc_id,
struct tegra2_mmc *reg, int bus_width,
int cd_gpio, int wp_gpio)
or similar, then the GPIO setup and access could be handled by the MMC driv=
er.
> ---
> =A0board/nvidia/common/board.c =A0 =A0 =A0| =A0 77 ++++++++++++++++++++++=
++--------------
> =A0board/nvidia/common/board.h =A0 =A0 =A0| =A0 =A08 +++-
> =A0board/nvidia/harmony/harmony.c =A0 | =A0 56 +++++++++++++++++++++++++-=
-
> =A0board/nvidia/seaboard/seaboard.c | =A0 23 +++++++++++
> =A0drivers/mmc/tegra2_mmc.c =A0 =A0 =A0 =A0 | =A0 18 +++++++++
> =A05 files changed, 148 insertions(+), 34 deletions(-)
>
> diff --git a/board/nvidia/common/board.c b/board/nvidia/common/board.c
> index 8033612..6c09a4c 100644
> --- a/board/nvidia/common/board.c
> +++ b/board/nvidia/common/board.c
> @@ -102,20 +102,37 @@ static void pin_mux_uart(void)
>
> =A0#ifdef CONFIG_TEGRA2_MMC
> =A0/*
> - * Routine: clock_init_mmc
> - * Description: init the PLL and clocks for the SDMMC controllers
> + * Routine: clock_init_mmc4
> + * Description: init the PLL and clocks for SDMMC4 controller
> =A0*/
> -static void clock_init_mmc(void)
> +void clock_init_mmc4(void)
> =A0{
> =A0 =A0 =A0 =A0clock_start_periph_pll(PERIPH_ID_SDMMC4, CLOCK_ID_PERIPH, =
20000000);
> +}
> +
> +/*
> + * Routine: clock_init_mmc3
> + * Description: init the PLL and clocks for SDMMC3 controller
> + */
> +void clock_init_mmc3(void)
> +{
> =A0 =A0 =A0 =A0clock_start_periph_pll(PERIPH_ID_SDMMC3, CLOCK_ID_PERIPH, =
20000000);
> =A0}
>
> =A0/*
> - * Routine: pin_mux_mmc
> - * Description: setup the pin muxes/tristate values for the SDMMC(s)
> + * Routine: clock_init_mmc2
> + * Description: init the PLL and clocks for SDMMC2 controller
> =A0*/
> -static void pin_mux_mmc(void)
> +void clock_init_mmc2(void)
> +{
> + =A0 =A0 =A0 clock_start_periph_pll(PERIPH_ID_SDMMC2, CLOCK_ID_PERIPH, 2=
0000000);
> +}
> +
> +/*
> + * Routine: pin_mux_mmc4
> + * Description: setup the pin muxes/tristate values for SDMMC4
> + */
> +void pin_mux_mmc4(void)
> =A0{
> =A0 =A0 =A0 =A0/* SDMMC4: config 3, x8 on 2nd set of pins */
> =A0 =A0 =A0 =A0pinmux_set_func(PINGRP_ATB, PMUX_FUNC_SDIO4);
> @@ -125,7 +142,14 @@ static void pin_mux_mmc(void)
> =A0 =A0 =A0 =A0pinmux_tristate_disable(PINGRP_ATB);
> =A0 =A0 =A0 =A0pinmux_tristate_disable(PINGRP_GMA);
> =A0 =A0 =A0 =A0pinmux_tristate_disable(PINGRP_GME);
> +}
>
> +/*
> + * Routine: pin_mux_mmc3
> + * Description: setup the pin muxes/tristate values for SDMMC3
> + */
> +void pin_mux_mmc3(void)
> +{
> =A0 =A0 =A0 =A0/* SDMMC3: SDIO3_CLK, SDIO3_CMD, SDIO3_DAT[3:0] */
> =A0 =A0 =A0 =A0pinmux_set_func(PINGRP_SDB, PMUX_FUNC_SDIO3);
> =A0 =A0 =A0 =A0pinmux_set_func(PINGRP_SDC, PMUX_FUNC_SDIO3);
> @@ -135,6 +159,25 @@ static void pin_mux_mmc(void)
> =A0 =A0 =A0 =A0pinmux_tristate_disable(PINGRP_SDD);
> =A0 =A0 =A0 =A0pinmux_tristate_disable(PINGRP_SDB);
> =A0}
> +
> +/*
> + * Routine: pin_mux_mmc2
> + * Description: setup the pin muxes/tristate values for SDMMC2
> + */
> +void pin_mux_mmc2(void)
> +{
> + =A0 =A0 =A0 /* SDMMC2: SDIO2_CLK, SDIO2_CMD, SDIO2_DAT[7:0] */
> + =A0 =A0 =A0 pinmux_set_func(PINGRP_DTA, PMUX_FUNC_SDIO2);
> + =A0 =A0 =A0 pinmux_set_func(PINGRP_DTD, PMUX_FUNC_SDIO2);
> +
> + =A0 =A0 =A0 pinmux_tristate_disable(PINGRP_DTA);
> + =A0 =A0 =A0 pinmux_tristate_disable(PINGRP_DTD);
> +
> + =A0 =A0 =A0 /* For power GPIO PI6 */
> + =A0 =A0 =A0 pinmux_tristate_disable(PINGRP_ATA);
> + =A0 =A0 =A0 /* For power GPIO PT3 */
> + =A0 =A0 =A0 pinmux_tristate_disable(PINGRP_DTB);
> +}
> =A0#endif
>
> =A0/*
> @@ -152,28 +195,6 @@ int board_init(void)
> =A0 =A0 =A0 =A0return 0;
> =A0}
>
> -#ifdef CONFIG_TEGRA2_MMC
> -/* this is a weak define that we are overriding */
> -int board_mmc_init(bd_t *bd)
> -{
> - =A0 =A0 =A0 debug("board_mmc_init called\n");
> - =A0 =A0 =A0 /* Enable clocks, muxes, etc. for SDMMC controllers */
> - =A0 =A0 =A0 clock_init_mmc();
> - =A0 =A0 =A0 pin_mux_mmc();
> - =A0 =A0 =A0 gpio_config_mmc();
> -
> - =A0 =A0 =A0 debug("board_mmc_init: init eMMC\n");
> - =A0 =A0 =A0 /* init dev 0, eMMC chip, with 8-bit bus */
> - =A0 =A0 =A0 tegra2_mmc_init(0, 8);
You could pass the GPIOs to these functions. They could init the
clocks also. For pinmux, are there actually any options?
> -
> - =A0 =A0 =A0 debug("board_mmc_init: init SD slot\n");
> - =A0 =A0 =A0 /* init dev 1, SD slot, with 4-bit bus */
> - =A0 =A0 =A0 tegra2_mmc_init(1, 4);
> -
> - =A0 =A0 =A0 return 0;
> -}
> -#endif
> -
> =A0#ifdef CONFIG_BOARD_EARLY_INIT_F
> =A0int board_early_init_f(void)
> =A0{
> diff --git a/board/nvidia/common/board.h b/board/nvidia/common/board.h
> index 344e702..eee475d 100644
> --- a/board/nvidia/common/board.h
> +++ b/board/nvidia/common/board.h
> @@ -26,7 +26,13 @@
>
> =A0void tegra2_start(void);
> =A0void gpio_config_uart(void);
> -void gpio_config_mmc(void);
> +void clock_init_mmc4(void);
> +void clock_init_mmc3(void);
> +void clock_init_mmc2(void);
> +void pin_mux_mmc4(void);
> +void pin_mux_mmc3(void);
> +void pin_mux_mmc2(void);
> =A0int tegra2_mmc_init(int dev_index, int bus_width);
> +int tegra2_mmc_index(struct mmc *mmc);
>
> =A0#endif /* BOARD_H */
> diff --git a/board/nvidia/harmony/harmony.c b/board/nvidia/harmony/harmon=
y.c
> index cbb30d6..228ae2e 100644
> --- a/board/nvidia/harmony/harmony.c
> +++ b/board/nvidia/harmony/harmony.c
> @@ -23,10 +23,13 @@
>
> =A0#include <common.h>
> =A0#include <asm/io.h>
> +#include <asm/arch/clock.h>
> =A0#include <asm/arch/tegra2.h>
> +#include <asm/gpio.h>
> =A0#ifdef CONFIG_TEGRA2_MMC
> =A0#include <mmc.h>
> =A0#endif
> +#include "../common/board.h"
>
> =A0/*
> =A0* Routine: gpio_config_uart
> @@ -43,18 +46,61 @@ void gpio_config_uart(void)
> =A0*/
> =A0void gpio_config_mmc(void)
> =A0{
> - =A0 =A0 =A0 /* Not implemented for now */
> + =A0 =A0 =A0 /* Set SDMMC4 power (GPIO I6) */
> + =A0 =A0 =A0 gpio_request(GPIO_PI6, "SDMMC4 power");
> + =A0 =A0 =A0 gpio_direction_output(GPIO_PI6, 1);
> +
> + =A0 =A0 =A0 /* Config pin as GPI for SDMMC4 Card Detect (GPIO H2) */
> + =A0 =A0 =A0 gpio_request(GPIO_PH2, "SDMMC4 card detect");
> + =A0 =A0 =A0 gpio_direction_input(GPIO_PH2);
> +
> + =A0 =A0 =A0 /* Set SDMMC2 power (GPIO T3) */
> + =A0 =A0 =A0 gpio_request(GPIO_PT3, "SDMMC2 power");
> + =A0 =A0 =A0 gpio_direction_output(GPIO_PT3, 1);
> +
> + =A0 =A0 =A0 /* Config pin as GPI for SDMMC2 Card Detect (GPIO I5) */
> + =A0 =A0 =A0 gpio_request(GPIO_PI5, "SDMMC2 card detect");
> + =A0 =A0 =A0 gpio_direction_input(GPIO_PI5);
> +}
> +
> +/* this is a weak define that we are overriding */
> +int board_mmc_init(bd_t *bd)
> +{
> + =A0 =A0 =A0 debug("board_mmc_init called\n");
> + =A0 =A0 =A0 /* Enable clocks, muxes, etc. for SDMMC controllers */
> + =A0 =A0 =A0 clock_init_mmc4();
> + =A0 =A0 =A0 clock_init_mmc2();
> + =A0 =A0 =A0 pin_mux_mmc4();
> + =A0 =A0 =A0 pin_mux_mmc2();
> + =A0 =A0 =A0 gpio_config_mmc();
> +
> + =A0 =A0 =A0 debug("board_mmc_init: init SD slot J26\n");
> + =A0 =A0 =A0 /* init dev 0, SD slot J26, with 8-bit bus */
> + =A0 =A0 =A0 tegra2_mmc_init(0, 8);
> +
> + =A0 =A0 =A0 debug("board_mmc_init: init SD slot J5\n");
> + =A0 =A0 =A0 /* init dev 2, SD slot J5, with 8-bit bus */
> + =A0 =A0 =A0 tegra2_mmc_init(2, 4);
> +
> + =A0 =A0 =A0 return 0;
> =A0}
>
> =A0/* this is a weak define that we are overriding */
> =A0int board_mmc_getcd(u8 *cd, struct mmc *mmc)
> =A0{
> =A0 =A0 =A0 =A0debug("board_mmc_getcd called\n");
> - =A0 =A0 =A0 /*
> - =A0 =A0 =A0 =A0* Hard-code CD presence for now. Need to add GPIO inputs
> - =A0 =A0 =A0 =A0* for Harmony
> - =A0 =A0 =A0 =A0*/
> =A0 =A0 =A0 =A0*cd =3D 1;
> +
> + =A0 =A0 =A0 if (tegra2_mmc_index(mmc) =3D=3D 0) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Harmony SDMMC4 =3D SDIO4_CD =3D GPIO_PH2=
*/
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (gpio_get_value(GPIO_PH2))
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 *cd =3D 0;
> + =A0 =A0 =A0 } else {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Harmony SDMMC2 =3D SDIO2_CD =3D GPIO_PI5=
*/
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (gpio_get_value(GPIO_PI5))
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 *cd =3D 0;
> + =A0 =A0 =A0 }
This doesn't seem very nice - it has to 'reverse calculate' the GPIO -
it means that the GPIO is referenced in gpio_config_mmc() and here,
but in different ways. Better to pass the GPIOs to the driver?
> +
> =A0 =A0 =A0 =A0return 0;
> =A0}
> =A0#endif
> diff --git a/board/nvidia/seaboard/seaboard.c b/board/nvidia/seaboard/sea=
board.c
> index 1310e3d..0667eaa 100644
> --- a/board/nvidia/seaboard/seaboard.c
> +++ b/board/nvidia/seaboard/seaboard.c
> @@ -28,6 +28,7 @@
> =A0#ifdef CONFIG_TEGRA2_MMC
> =A0#include <mmc.h>
> =A0#endif
> +#include "../common/board.h"
>
> =A0/*
> =A0* Routine: gpio_config_uart
> @@ -71,6 +72,28 @@ void gpio_config_mmc(void)
> =A0}
>
> =A0/* this is a weak define that we are overriding */
> +int board_mmc_init(bd_t *bd)
> +{
> + =A0 =A0 =A0 debug("board_mmc_init called\n");
> + =A0 =A0 =A0 /* Enable clocks, muxes, etc. for SDMMC controllers */
> + =A0 =A0 =A0 clock_init_mmc4();
> + =A0 =A0 =A0 clock_init_mmc3();
> + =A0 =A0 =A0 pin_mux_mmc4();
> + =A0 =A0 =A0 pin_mux_mmc3();
> + =A0 =A0 =A0 gpio_config_mmc();
> +
> + =A0 =A0 =A0 debug("board_mmc_init: init eMMC\n");
> + =A0 =A0 =A0 /* init dev 0, eMMC chip, with 8-bit bus */
> + =A0 =A0 =A0 tegra2_mmc_init(0, 8);
> +
> + =A0 =A0 =A0 debug("board_mmc_init: init SD slot\n");
> + =A0 =A0 =A0 /* init dev 1, SD slot, with 4-bit bus */
> + =A0 =A0 =A0 tegra2_mmc_init(1, 4);
> +
> + =A0 =A0 =A0 return 0;
> +}
> +
> +/* this is a weak define that we are overriding */
> =A0int board_mmc_getcd(u8 *cd, struct mmc *mmc)
> =A0{
> =A0 =A0 =A0 =A0debug("board_mmc_getcd called\n");
> diff --git a/drivers/mmc/tegra2_mmc.c b/drivers/mmc/tegra2_mmc.c
> index 9e741f2..223dbf3 100644
> --- a/drivers/mmc/tegra2_mmc.c
> +++ b/drivers/mmc/tegra2_mmc.c
> @@ -478,3 +478,21 @@ int tegra2_mmc_init(int dev_index, int bus_width)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dev_index, bus_width);
> =A0 =A0 =A0 =A0return tegra2_mmc_initialize(dev_index, bus_width);
> =A0}
> +
> +int tegra2_mmc_index(struct mmc *mmc)
> +{
> + =A0 =A0 =A0 struct mmc_host *host =3D (struct mmc_host *)mmc->priv;
> +
> + =A0 =A0 =A0 switch (host->base) {
> + =A0 =A0 =A0 case TEGRA2_SDMMC3_BASE:
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return 1;
> + =A0 =A0 =A0 case TEGRA2_SDMMC2_BASE:
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return 2;
> + =A0 =A0 =A0 case TEGRA2_SDMMC1_BASE:
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return 3;
> + =A0 =A0 =A0 case TEGRA2_SDMMC4_BASE:
> + =A0 =A0 =A0 default:
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return 0;
> + =A0 =A0 =A0 }
> +}
It seems odd to have to look up the index based on the peripheral
address - can we not store this information?
At the top of the file there is a function:
static inline struct tegra2_mmc *tegra2_get_base_mmc(int dev_index)
which seems to go the other way!
Regards,
Simon
> +
> --
> 1.7.0.4
>
>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
>
>> Last commit seen on this driver used as base
>> for porting is 1db41e032d563eb47deab40dc5595be306b143ba
>> (video: da8xx-fb: fix section mismatch warning)
>
> Which repository is this commit ID from? I cannot find it in the
> U-Boot tree...
This is the commit-id in the kernel tree. It states the last changes on
this driver that I took as base for porting to U-Boot.
commit 1db41e032d563eb47deab40dc5595be306b143ba
Author: axel lin <axel.lin@gmail.com>
Date: Tue Feb 22 01:52:42 2011 +0000
video: da8xx-fb: fix section mismatch warning
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Best regards,
Stefano Babic
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
automatically by looking at the global flags.
>
> And why do you mention getenv_int but implement getenv_long?
This is a mistake, sorry.
Regards,
Simon
>
> Best Regards,
> Reinhard
>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
Acked-by: WOlfgang Denk <wd@denx.de>
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
There's no honorable way to kill, no gentle way to destroy. There is
nothing good in war. Except its ending.
-- Abraham Lincoln, "The Savage Curtain", stardate 5906.5
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
could perhaps move the last ones up into the main area, to avoid the
new code in image_check_image_types().
Also I don't think the #ifdef really helps here, except perhaps for
testing that you haven't left something bad in the code. It might be
better to display an error like 'relative images not supported' when
CONFIG_SYS_RELATIVE_IMAGES is not defined.
> @@ -372,10 +384,25 @@ image_get_hdr_l(magic) =A0 =A0 =A0 =A0 =A0 =A0/* im=
age_get_magic */
> =A0image_get_hdr_l(hcrc) =A0 =A0 =A0 =A0 =A0/* image_get_hcrc */
> =A0image_get_hdr_l(time) =A0 =A0 =A0 =A0 =A0/* image_get_time */
> =A0image_get_hdr_l(size) =A0 =A0 =A0 =A0 =A0/* image_get_size */
> -image_get_hdr_l(load) =A0 =A0 =A0 =A0 =A0/* image_get_load */
> -image_get_hdr_l(ep) =A0 =A0 =A0 =A0 =A0 =A0/* image_get_ep */
> +image_get_hdr_l(load_raw) =A0 =A0 =A0/* image_get_load_raw */
> +image_get_hdr_l(ep_raw) =A0 =A0 =A0 =A0/* image_get_ep_raw */
might need another tab here (although it isn't visible on email)
> @@ -430,8 +457,8 @@ image_set_hdr_l(magic) =A0 =A0 =A0 =A0 =A0 =A0 =A0/* =
image_set_magic */
> =A0image_set_hdr_l(hcrc) =A0 =A0 =A0 =A0 =A0/* image_set_hcrc */
> =A0image_set_hdr_l(time) =A0 =A0 =A0 =A0 =A0/* image_set_time */
> =A0image_set_hdr_l(size) =A0 =A0 =A0 =A0 =A0/* image_set_size */
> -image_set_hdr_l(load) =A0 =A0 =A0 =A0 =A0/* image_set_load */
> -image_set_hdr_l(ep) =A0 =A0 =A0 =A0 =A0 =A0/* image_set_ep */
> +image_set_hdr_l(load_raw) =A0 =A0 =A0/* image_set_load_raw */
> +image_set_hdr_l(ep_raw) =A0 =A0 =A0 =A0/* image_set_ep_raw */
might need another tab here (although it isn't visible on email)
Regards,
Simon
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
The AVP does not have a CP15.
As this thread speculates, it is an ARM7TDMI which is a basic ARM V4 core=
=20with no ARM co-processors or MMU.
Also, ARM app note 99 (DAI0099C_core_type_rev_id.pdf) says the same thing=
.
HTH,
Tom
> -----Original Message-----
> From: sjg at google.com [mailto:sjg at google.com] On Behalf Of Simon Glass
> Sent: Monday, October 31, 2011 2:44 PM
> To: Albert ARIBAUD
> Cc: U-Boot Mailing List; Tom Warren; Stephen Warren
> Subject: Re: [PATCH 3/9] arm: Move CP15 init out of cpu_init_crit()
>=20
> Hi Albert,
>=20
> On Sun, Oct 30, 2011 at 3:16 AM, Albert ARIBAUD
> <albert.u.boot@aribaud.net> wrote:
> > Hi Simon,
> >
> > Le 29/10/2011 02:36, Simon Glass a =E9crit :
> >>
> >> Hi Albert,
> >>
> >> On Thu, Oct 27, 2011 at 10:09 PM, Albert ARIBAUD
> >> <albert.u.boot@aribaud.net> =A0wrote:
> >>>
> >>> Le 28/10/2011 03:43, Simon Glass a =E9crit :
> >>>
> >>>> The test was
> >>>>
> >>>> =A0 =A0 =A0 =A0mrc =A0 =A0 p15, 0, r0, c0, c0, 0 =A0 @ get ID regi=
ster
> >>>> =A0 =A0 =A0 =A0and =A0 =A0 r0, r0, #0xf0000 =A0 =A0 =A0 =A0@ get a=
rchitecture
> >>>> =A0 =A0 =A0 =A0cmp =A0 =A0 r0, #0xf0000 =A0 =A0 =A0 =A0 =A0 =A0@ c=
heck for> =A0 =A0ARMv6
> >>>> =A0 =A0 =A0 =A0movne =A0 pc, lr =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
@ else skip cache init
> >>>>
> >>>> Unfortunately I think it is a plain ARM7TDMI with no CP15.
> >>>
> >>> What about other fields in r0 right after mrc?
> >>
> >> I don't really understand that sentence, sorry.
> >>
> >> The ARM7TDMI does not have a CP15 and aborts if I try to access it.
> >> Just in case there is something odd going on I checked with DSTREAM =
/
> >> RVdebug and it definitely doesn't have a CP15. [as Ford Prefect woul=
d
> >> say, I counted them twice]
> >
> > Ok, so debug tools do not show cp15. But tools can be tailored to wha=
t
> tool
> > makes think is needed -- I could tell about some debugging tools that=
=20will
> > not let me see all I want a core because the debug designers had fini=
te
> > resources and what I wanted was not a priority to them.
>=20
> Ye of little faith...
>=20
> >
> > OTOH, according to ARM, ARM7DTMI is an ARMv4T architecture, and indee=
d
> cp15
> > is mandatory only for ARMv6 and up, but ARM also states cp15 support =
was a
> > de facto standard already for ARMv4.
>=20
> Yes it is de facto when you have a core with that support - typically
> an MMU and caches. But in that case it would have three digits, as in
> ARM720T, rather than ARM7TDMI. It is definitely an ARM7TDMI (actually
> -S) core in the datasheet, and there is no external CP15 block shown,
> etc. (Although I can see a cache!)
>=20
> >
> > So I am left with the question: would the Tegra2 AVP be the only ARM
> > implementation supported by U-Boot that does not have a cp15? That is=
> > possible, but I want direct testimony from Nividia.
>=20
> No there are lots and lots of ARM7TDMIs out there, just not that many
> that run U-Boot - and Linux is hard without an MMU. But even in the
> U-Boot tree we have the s3c44b0 cpu which seems to be a plain
> ARM7TDMI.
>=20
> In terms of direct testimony, two engineers are on this thread and may
> wish to chime in. The datasheet is pretty clear to me...
>=20
> >
> > This is why I asked about the Tegra2 TRM, or whatever Nvidia calls it=
, in
> > case it would explicitely state if AVP has cp15 support or not. Faili=
ng
>=20
> See above, it clearly states ARM7TDMI-S.
>=20
> > that, I'd be ok with experimenting but through the AVP, not through
> > debugging tools -- encoding a cp15 MIDR read in the U-Boot startup co=
de,
> > step through it with the debugger and see if it causes an UND or not,=
=20and
> if
> > not, what is the hex value of r0 -- maybe that is exactly what you di=
d,
> but
> > I am not 100% sure it is, hence my insistence.
>=20
> OK I have done this, and yes the AVP definitely takes the undef
> exception when you execute:
>=20
> mrc p15, 0, r0, c0, c0, 0
>=20
> >
> > I am especially surprised that a recent core be synthesized without a=
> means
> > for run-time core identification, especially in a design with two ARM=
> cores.
>=20
> The -S means synthesized. It does have its own method of
> identification as I mentioned. There is a Tegra-specific register that
> I can read.
>=20
> >
> >> The simplest thing I have been able to think of that does not involv=
e
> >> exceptions, differing instruction behaviour, doing the init later or=
> >> putting in some Tegra-specific code is to check for the existence of=
> >> the Q bit in the CPSR (actually APSR on ARMv7). This does seem to wo=
rk
> >> and I have verified both in my old 1996 ARM ARM DDI 0100B and the
> >> ARMv7-A one (DDI 0406B) that from an architecture point of view this=
> >> should work. The Q bit is RAZ on ARMv4T.
> >
> > This could hep if we really cannot access the Main ID Register on the=
=20AVP.
>=20
> OK, well I will send a patch set up with this change.
>=20
> >
> >> I believe this will cope with the Cortex-A7 / A-15 combinations and
> >> possibly even Cortex-R4 / A-15 although I have not tested this. I
> >> suppose we can deal with this when it becomes an issue.
> >>
> >> So I have redone this one patch with that in mind, and adjusted the
> >> series slightly to fit with this. I will resend it when it completes=
> >> MAKEALL.
> >>
> >> I hope that this resolves the matter, but if not(!), I would very mu=
ch
> >> appreciate it if you could send through some actual pseudo code
> >> showing what you are looking for, to avoid any confusion.
> >
> > Well, I just want to see if the MIDR is accessible and what its value=
=20is,
> so
> > I want the AVP to execute
> >
> > =A0 =A0 =A0 =A0mrc =A0 =A0 p15, 0, r0, c0, c0, 0
> >
> > The ending 0 is what selects MIDR rather than other cp15 registers --=
> other
> > values can cause UND (and I would gladly understand that AVP goes UND=
=20for
> > reading cp15 CTR for instance).
> >
> > The simplest test would be to insert the exact instruction above in t=
he
> > reset sequence in start.S right after SVC32 switch, debug the reset
> > execution path, see if the mrc above goes UND or else check r0's cont=
ents
> > after mrc is done.
>=20
> OK see above, I have done this. What I meant was for you to provide a
> code sequence that you want in start.S. Hopefully my patch will fit
> the bill.
>=20
> I am very happy for this to be rewritten/changed down the track. But
> for now, and assuming you don't want to call a function to find out
> whether or not CP15 exists, I have created something which seems to
> solve the problem. There are many other problems to solve. I feel that
> this one has had its fair share of attention!
>=20
> Regards,
> Simon
>=20
> >
> >> Thanks,
> >> Simon
> >
> > Amicalement,
> > --
> > Albert.
> >
-------------------------------------------------------------------------=
----------
This email message is for the sole use of the intended recipient(s) and m=
ay contain
confidential information. Any unauthorized review, use, disclosure or di=
stribution
is prohibited. If you are not the intended recipient, please contact the=
=20sender by
reply email and destroy all copies of the original message.
-------------------------------------------------------------------------=
----------
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
Bill & Exchange Manager.
email: toddwilliams2007 at yahoo.fr
Dear friend
=A0
I am Todd William am the manager of auditing and accounting department BANK=
OF AFRICA (B.O.A). in Benin. I would like you to indicate your interest to=
receive the transfer of$10.5 Million. I will like you to stand as the next=
of kin to my late client whose account is presently dormant, for claims.
(1) Full names:.......
(2) Private phone number: ........
(3) Current residential address:......
(4) Occupation:...........
(5) Age and Sex:.......
Yours faithful
BILL & EXCHANGE=A0 MANAGER
Dr Todd Williams
+229 96 30 63 17
--2042583127-626361114-1320137822=:23825--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
the board information.
So, there is no way to check the board revision at runtime.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
is working in mine so there is some ground for working together on
this. The main question is which of both implementation to use to
build up from. I will give you some feedback on the design high level
aspects further below. A complete review of the code and testing on
the beagleboard will hopefully happen over the next days. Testing
might be problematic as you flashing part is forced to be rewritten
for every board here it seems. Need to investigate further before I
can really comment on this. More comment inline.
On Wed, 2011-11-02 at 11:00, Andrzej Pietrasiewicz wrote:
> http://www.usb.org/developers/devclass_docs/DFU_1.1.pdf
Have you fully implemented 1.1? With the detahc logic inside the
device implementation?
> The aim of DFU is to allow transferring data to/from selected areas of
> interest within a compliant device. In the DFU nomenclature the host->device
> direction is called download and the device->host direction is called
> upload. The areas are defined by the compliant device. In the DFU
> nomenclature the area of interest within the device is called an altsetting.
> The device is connected to the host through USB. On the host side compliant
> software must be used to initiate the data transfer. Example piece of such
> software is dfu-util package from the OpenMoko project:
>
> http://wiki.openmoko.org/wiki/Dfu-util.
Better to use the official homepage here:
http://dfu-util.gnumonks.org/
It misses some examples but has the current informations while the
wiki is outdated.
> The DFU implementation on the device side remains in one of the two modes:
> the Run-Time mode and the DFU mode. The USB descriptor sets exported by
> the device depend on which mode is in force. While in DFU mode the device
> exports the descriptors corresponding to each available altsetting. An
> example dfu-util session when the device is in the DFU mode looks similar
> to this:
>
> # dfu-util -l
> dfu-util - (C) 2007-2008 by OpenMoko Inc.
> This program is Free Software and has ABSOLUTELY NO WARRANTY
>
> Found DFU: [0x0525:0xffff] devnum=46, cfg=0, intf=0, alt=0, name="bootldr"
> Found DFU: [0x0525:0xffff] devnum=46, cfg=0, intf=0, alt=1, name="kernel"
Just curious. What version of dfu-util your are using for your tests?
I released 0.5 earlier today.
> This u-boot implementation introduces a parameter-less dfu command.
> After the user finishes with dfu they can Ctrl-C to return to u-boot main
> menu.
Hmm, that sounds like you only implemented the DFU mode but not the
run-time mode yet? No addtional DFU descripto in the normal run-time
operation mode like usbtty? If yes this is a real limitation as the
update would only be possible when the user has serial access to start
the dfu command and then flash the device. While the original purpose
of DFU was to make updating USB device easy enough for end-users as
well. The implementation from OpenMoko i forward ported and cleanup
has this functionality and it works well enough. Did so on the
Freerunner from OM already.
In the end I would like to see different options available:
1) Entering DFU mode directly when a button is pressed on startup. An
update mode if you want to call it like this.
2) Normal startup, but with DFU descripton to allow dfu-util detaching
and entering the DFU mode for flashing.
3) Starting dfu mode form the command line as you did implement it.
> The implementation is split into two parts: the dfu gadget implementation
> and a "flashing backend", the interface between the two being the
> struct flash_entity. The "flashing backend"'s implementation is
> board-specific and is implemented on the Goni target.
What is your reasoning behind this split? I have it working here with
the normal nand_flashing routines taking care of bad blocks, etc.
I agree that there are several aspects that are board specific.
Partions can be read out dynamically and the alt setting generated
though. Soemthing what bothers me is the different underlaying medias
that can be flashed. Right now I only cover nand, but eMMC, USB and
other are valid as well. That is not covered in my implementation at
all right now.
To make it clear, I'm happy to see somebody else working on this as
well as my primary goal is to have good DFU support in U-Boot here not
if my implementation is merged or yours. I will clean up my patches a
bit more and send them in the next days. Also will go through your
code to understand what and how you are doing things. From there we
can go and decide how we merge our work and bring it into U-Boot
mainline. Comment from Scott for nand and Remy for USB related parts
will be helpful here.
Looking forward to work with you on this until we have good DFU
support in U-Boot.
regards
Stefan Schmidt
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
Vice President Of Nigeria=20
Federal Republic Of Nigeria
Attention Honorable Beneficiary
=A0
This is to officially notify you that we have verified your contract/Inheri=
tances file and found out that why you have not received your payment is be=
cause you have not fulfilled the obligations that was given to you in respe=
ct of your contract/inheritance payment.
=A0
Secondly, we have been informed that you are still dealing with the none of=
ficials in the bank, all your attempt to secure the release of the fund to =
you. We wish to advice you that such an illegal act like this have to stop =
if you wish to receive your payment since we have decided to bring a soluti=
on to your problem. Right now we have arranged your payment through our swi=
ft card payment center Asia pacific that is the latest instruction FROM MR.=
PRESIDENT,GOODLUCK EBELE JONATHAN (GCFR) PRESIDENT FEDERAL REPUBLIC OF NIG=
ERIA AND FEDERAL MINISTRY OF FINANCE.
=A0
This card center will send you an ATM card which you will use to withdraw y=
our money in any ATM machine in any part of the world without any delay, bu=
t the maximum withdrawer is Ten thousand five hundred dollars per day, so i=
f you like to receive your fund this way please let us know by contacting t=
he card payment center and also send the following information to her in or=
der to proceed immediately:
=A0
1. Full name
2. Phone and fax number
3. Address were you want them to send
The ATM card to (P.O box not acceptable)
4. Your age and current occupation
5. A copy of your identification
However, kindly find below the contact person:
Mr. Philip Ebere =A0
Director, ATM payment department
Email: philip_ebere1 at yahoo.com.hk
=A0
The ATM card payment center has been mandated to issue out (US$10, 500,000.=
00) Ten million five hundred thousand dollars as part payment for this fisc=
al year 2011. Also for your Information, you have to stop any further commu=
nication with any other person(s)or office(s) to avoid any hitches in recei=
ving your at payment. For oral discussion, i can be reached on or email me =
back as soon as you receive this important message for further direction an=
d also update me on any development from the above mentioned office.
Note that because of impostors, we hereby issued you our code of Conduct, w=
hich is (ATM-9304) so you have to indicate this code when contacting the ca=
rd center by using it as your subject.
=A0
Best Regards,
Dr. Sambo Namadi
Vice President Of Nigeria=20
Federal Republic Of Nigeria
--2138131439-603150615-1320391245=:49738--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
that exposes an unusual command set, but still for the most part
provides the same operations. Several of our existing NAND-subsystem
drivers have to fake the command set for the generic layer as well.
Initialization/identification might be a problem area that current
drivers don't have to deal with, though. Actually integrating OneNAND
with NAND would likely involve an already-needed restructuring of the
subsystem.
If the answer really is that it makes sense to consider OneNAND to be a
totally different thing from NAND, then it's outside my jurisdiction as
NAND custodian -- which is fine with me. Frankly, even if it does make
sense to merge them, I'd rather not be custodian of the OneNAND stuff
unless someone is actually willing to do the merge. I don't have access
to hardware or documentation, and it's an entirely separate codebase.
People just started sending me the patches a few years back.
>> This is not a new complaint -- I've asked for this before but nobody's
>> put the time into sorting out the mess (and I have neither time nor
>> hardware nor documentation). The SPL load_image function is a simple
>> enough interface to start with, though. :-)
>
> Well, it seems what you are proposing is way beyond the scope of this patchset.
>>
>> In fact, it should probably just be spl_load_image() with whatever boot
>> source has been configured into this SPL build.
>
> What if you have two boot sources?
Traditionally SPL has been small and purpose-built to do exactly one
thing -- so we decide at compile-time things that we might otherwise
decide at runtime.
If there's a requirement for multiple boot sources decided at runtime,
then we'll obviously need a runtime mechanism. -- but it seems a bit
hackish to why does it matter whether it's two different types of
device, or two of the same type of device (possibly with different
controller types)? If the answer is that, for example, NAND versus USB
versus MMC is a likely use case, but two different NANDs is not likely,
is NAND versus OneNAND any more likely?
Maybe spl_load_image should be a function pointer that board code sets,
with each implementation being distinctly named (in which case
nand_spl_load_image would become nand_spl_simple_load_image, unless we
move it to nand_spl_load.c and make nand_read_page a function pointer).
If needed to save a few bytes, we could use #defines to eliminate the
function pointers in a single-target SPL build.
For now, until we decide to do something SPL-wide, call it what you want.
-Scott
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
loaded by coreboot on the chromebook, and it's likely that other coreboot
motherboards may want to do the same. Therefore can you change:
board/chromebook-x86/coreboot
to:
board/coreboot/chromebook-x86/
Regarding the empty functions, I know they are required to keep the linker
happy. I see two options:
1) #ifdef the call sites
2) create weak stubs
I'm open to debate on the preferred approach
Regards,
Graeme
>
> Gabe
>
> On Fri, Nov 4, 2011 at 3:24 PM, Mike Frysinger <vapier@gentoo.org
> <mailto:vapier@gentoo.org>> wrote:
>
> i'm not terribly familiar with what it takes to make an x86 board, but
> i don't
> see anything jumping out of this patch.
>
> i would note however that you should merge the boards.cfg update into this
> patch. merging one or the other doesn't make much sense, and there's no
> reason to keep them split.
>
> > +void setup_pcat_compatibility()
>
> should be "(void)"
> -mike
>
>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
Good Day, My Dear Good Friend,
My name is Mr. Younes Amadou I'm the bill and exchange manager in the=A0=A0=
Bank=A0 of Africa (BOA)Ouagadougou Burkina Faso.
I have a business proposal in the tune of $8.2m, (Eight Million two hundred=
Thousand only) after the successful transfer; we shall share in ratio of 4=
0% for you and 60% for me.
I want to front you in the bank so that you can apply for the claim of fund=
as the next of kin to our late customer Mr. Andreas Schranner from Munich,=
Germany=A0 who died years ago with his entire family while on holidays and=
several attempt has being made to locate his family without success.
You should understand that as an insider in the bank i will do every thing =
possible to protect your interest and to make sure that i follow things up =
as soon as you are willing to work this out with me because i will not want=
this money to go into the government purse.
So we can commence on all arrangements and I Will give you more information=
on how we would handle this project.
Please treat this business with utmost confidentiality and send me the Foll=
owing information:
FOR MORE INFORMATION VISIT THIS SITE BELLOW
http://news.bbc.co.uk/1/hi/world/europe/859479.stm.
you should contact me on my private email addres:(mr_yous1960 at voila.fr) .
Thanks
Yours Faithfully,.
Mr.Younes Amadou .
--1345022803-1937920273-1320605649=:44022--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
compilers/linkers have ABI compatibility issue (someone more familiar with
the history may be able to correct me) - This sounds _exactly_ what we
have here with x86 - x86 has an ABI incompatibility by using reparm(3).
I think reparm was used to simplify some asm/C interfaces - maybe these
can be re-coded and we can drop regparm and we can drop the wrappers.
Alternatively, I think I would prefer to use USE_PRIVATE_LIBGCC instead of
the wrappers as this highlights that U-Boot is _not_ ABI compliant and
therefore cannot link to libgcc. I can just see someone in the future
using a libgcc function and not implementing a wrapper and doing a lot of
head scratching when things wrong...
Regards,
Graeme
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
device is already in *normal* (D0) mode => it doesn't need to be wake-up.
With this patch, we only wake-up (writing on TEST_BYTE register) if PM_MODE
bits of PM_CTRL register is in D1/D2 mode.
Signed-off-by: Bertrand Cachet <bertrand.cachet@heig-vd.ch>
---
drivers/net/smc911x.h | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/smc911x.h b/drivers/net/smc911x.h
index 8ce08a9..258b9b6 100644
--- a/drivers/net/smc911x.h
+++ b/drivers/net/smc911x.h
@@ -471,8 +471,10 @@ static void smc911x_reset(struct eth_device *dev)
{
int timeout;
- /* Take out of PM setting first */
- if (smc911x_reg_read(dev, PMT_CTRL) & PMT_CTRL_READY) {
+ /* Take out of PM setting first */
+ /* If PMT_CTRL_READY bit is set to 1b => power management is
+ already ready */
+ if ((smc911x_reg_read(dev, PMT_CTRL) & PMT_CTRL_READY) == 0) {
/* Write to the bytetest will take out of powerdown */
smc911x_reg_write(dev, BYTE_TEST, 0x0);
--
1.7.5.4
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
device is already in *normal* (D0) mode => it doesn't need to be wake-up.
With this patch, we only wake-up (writing on TEST_BYTE register) if PM_MODE
bits of PM_CTRL register is in D1/D2 mode.
Signed-off-by: Bertrand Cachet <bertrand.cachet@heig-vd.ch>
---
drivers/net/smc911x.h | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/smc911x.h b/drivers/net/smc911x.h
index 8ce08a9..258b9b6 100644
--- a/drivers/net/smc911x.h
+++ b/drivers/net/smc911x.h
@@ -471,8 +471,10 @@ static void smc911x_reset(struct eth_device *dev)
{
int timeout;
- /* Take out of PM setting first */
- if (smc911x_reg_read(dev, PMT_CTRL) & PMT_CTRL_READY) {
+ /* Take out of PM setting first */
+ /* If PMT_CTRL_READY bit is set to 1b => power management is
+ already ready */
+ if ((smc911x_reg_read(dev, PMT_CTRL) & PMT_CTRL_READY) == 0) {
/* Write to the bytetest will take out of powerdown */
smc911x_reg_write(dev, BYTE_TEST, 0x0);
--
1.7.5.4
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
device is already in *normal* (D0) mode => it doesn't need to be wake-up.
With this patch, we only wake-up (writing on TEST_BYTE register) if PM_MODE
bits of PM_CTRL register is in D1/D2 mode.
Signed-off-by: Bertrand Cachet <bertrand.cachet@heig-vd.ch>
---
drivers/net/smc911x.h | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/smc911x.h b/drivers/net/smc911x.h
index 8ce08a9..61f7669 100644
--- a/drivers/net/smc911x.h
+++ b/drivers/net/smc911x.h
@@ -471,8 +471,12 @@ static void smc911x_reset(struct eth_device *dev)
{
int timeout;
- /* Take out of PM setting first */
- if (smc911x_reg_read(dev, PMT_CTRL) & PMT_CTRL_READY) {
+ /* Take out of PM setting first */
+ /*
+ * If PMT_CTRL_READY bit is set to 1b => power management is
+ * already ready
+ */
+ if ((smc911x_reg_read(dev, PMT_CTRL) & PMT_CTRL_READY) == 0) {
/* Write to the bytetest will take out of powerdown */
smc911x_reg_write(dev, BYTE_TEST, 0x0);
--
1.7.5.4
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
device is already in *normal* (D0) mode => it doesn't need to be wake-up.
With this patch, we only wake-up (writing on TEST_BYTE register) if PM_MODE
bits of PM_CTRL register is in sleep (D1/D2) mode.
Improve code styling by grouping two narrow comments.
Signed-off-by: Bertrand Cachet <bertrand.cachet@heig-vd.ch>
---
drivers/net/smc911x.h | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/smc911x.h b/drivers/net/smc911x.h
index 8ce08a9..7f4156e 100644
--- a/drivers/net/smc911x.h
+++ b/drivers/net/smc911x.h
@@ -471,8 +471,11 @@ static void smc911x_reset(struct eth_device *dev)
{
int timeout;
- /* Take out of PM setting first */
- if (smc911x_reg_read(dev, PMT_CTRL) & PMT_CTRL_READY) {
+ /*
+ * Take out of PM setting first
+ * Device is already wake up if PMT_CTRL_READY bit is set
+ */
+ if ((smc911x_reg_read(dev, PMT_CTRL) & PMT_CTRL_READY) == 0) {
/* Write to the bytetest will take out of powerdown */
smc911x_reg_write(dev, BYTE_TEST, 0x0);
--
1.7.5.4
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
device is already in *normal* (D0) mode => it doesn't need to be wake-up.
With this patch, we only wake-up (writing on TEST_BYTE register) if PM_MODE
bits of PM_CTRL register is in sleep (D1/D2) mode.
Signed-off-by: Bertrand Cachet <bertrand.cachet@heig-vd.ch>
---
v2: Improve code styling by grouping two narrow comments.
v3: Place versions information under scissors line.
drivers/net/smc911x.h | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/smc911x.h b/drivers/net/smc911x.h
index 8ce08a9..00e5b2e 100644
--- a/drivers/net/smc911x.h
+++ b/drivers/net/smc911x.h
@@ -471,8 +471,11 @@ static void smc911x_reset(struct eth_device *dev)
{
int timeout;
- /* Take out of PM setting first */
- if (smc911x_reg_read(dev, PMT_CTRL) & PMT_CTRL_READY) {
+ /*
+ * Take out of PM setting first
+ * Device is already wake up if PMT_CTRL_READY bit is set
+ */
+ if ((smc911x_reg_read(dev, PMT_CTRL) & PMT_CTRL_READY) == 0) {
/* Write to the bytetest will take out of powerdown */
smc911x_reg_write(dev, BYTE_TEST, 0x0);
--
1.7.5.4
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-23 10:48 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-23 10:48 UTC (permalink / raw)
To: u-boot
device is already in *normal* (D0) mode => it doesn't need to be wake-up.
With this patch, we only wake-up (writing on TEST_BYTE register) if PM_MODE
bits of PM_CTRL register is in sleep (D1/D2) mode.
Signed-off-by: Bertrand Cachet <bertrand.cachet@heig-vd.ch>
---
v2: Improve code styling by grouping two narrow comments.
v3: Place versions information under scissors line.
v4: Use tabs instead of spaces (vimrc problem)
drivers/net/smc911x.h | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/smc911x.h b/drivers/net/smc911x.h
index 8ce08a9..a290073 100644
--- a/drivers/net/smc911x.h
+++ b/drivers/net/smc911x.h
@@ -471,8 +471,11 @@ static void smc911x_reset(struct eth_device *dev)
{
int timeout;
- /* Take out of PM setting first */
- if (smc911x_reg_read(dev, PMT_CTRL) & PMT_CTRL_READY) {
+ /*
+ * Take out of PM setting first
+ * Device is already wake up if PMT_CTRL_READY bit is set
+ */
+ if ((smc911x_reg_read(dev, PMT_CTRL) & PMT_CTRL_READY) == 0) {
/* Write to the bytetest will take out of powerdown */
smc911x_reg_write(dev, BYTE_TEST, 0x0);
--
1.7.5.4
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-04 17:33 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-04 17:33 UTC (permalink / raw)
To: ath9k-devel
---------------------------------------------------------------------------=
------------------------
Reason Meaning
0 Reserved
1 Unspecified reason
2 Previous authentication no longer valid
3 Deauthenticated because sending STA is leaving (or has left) IBSS or ESS
4 Disassociated due to inactivity
5 Disassociated because AP is unable to handle all currently associated STA=
s
6 Class 2 frame received from nonauthenticated STA
7 Class 3 frame received from nonassociated STA
8 Disassociated because sending STA is leaving (or has left) BSS
9 STA requesting (re)association is not authenticated with responding STA
10 Disassociated because the information in the Power Capability element is=
unacceptable
11 Disassociated because the information in the Supported Channels element =
is unacceptable
12 Reserved
13 Invalid information element, i.e., an information element defined in thi=
s standard for
which the content does not meet the specifications in Clause 7
14 Message integrity code (MIC) failure
15 4-Way Handshake timeout
16 Group Key Handshake timeout
17 Information element in 4-Way Handshake different from (Re)Association Re=
quest/Probe
Response/Beacon frame
18 Invalid group cipher
19 Invalid pairwise cipher
20 Invalid AKMP
21 Unsupported RSN information element version
22 Invalid RSN information element capabilities
23 IEEE 802.1X authentication failed
24 Cipher suite rejected because of the security policy
25=E2=80=9331 Reserved
32 Disassociated for unspecified, QoS-related reason
33 Disassociated because QoS AP lacks sufficient bandwidth for this QoS STA
34 Disassociated because excessive number of frames need to be acknowledged=
, but are not
acknowledged due to AP transmissions and/or poor channel conditions
35 Disassociated because STA is transmitting outside the limits of its TXOP=
s
36 Requested from peer STA as the STA is leaving the BSS (or resetting)
37 Requested from peer STA as it does not want to use the mechanism
38 Requested from peer STA as the STA received frames using the mechanism f=
or which a
setup is required
39 Requested from peer STA due to timeout
45 Peer STA does not support the requested cipher suite
46=E2=80=9365 Reserved
535 Reserved
---------------------------------------------------------------------------=
------------------------
> Jan 30 23:31:37 ws1 dhcpcd[23630]: wlan0: carrier lost
> Jan 30 23:31:37 ws1 wpa_cli: interface wlan0 DISCONNECTED
> Jan 30 23:31:38 ws1 [ 9444.502016] wlan0: associate with AP f51a5ea8
> Jan 30 23:31:38 ws1 dhcpcd[23630]: wlan0: received SIGTERM, stopping
> Jan 30 23:31:38 ws1 [ 9444.703019] wlan0: associate with AP f51a5ea8
> Jan 30 23:31:38 ws1 [ 9444.902015] wlan0: associate with AP f51a5ea8
> Jan 30 23:31:39 ws1 [ 9445.102013] wlan0: association with AP f51a5ea8 ti=
med out
> Jan 30 23:31:40 ws1 [ 9445.990865] wlan0: authenticate with AP f51a5ea8
> Jan 30 23:31:40 ws1 [ 9445.998616] wlan0: authenticate with AP f51a5ea8
> Jan 30 23:31:40 ws1 [ 9446.000416] wlan0: authenticated
> Jan 30 23:31:40 ws1 [ 9446.000421] wlan0: associate with AP f51a5ea8
> Jan 30 23:31:40 ws1 [ 9446.003209] wlan0: RX AssocResp from f029002a (cap=
ab=3D0x411 status=3D0 aid=3D2)
> Jan 30 23:31:40 ws1 [ 9446.003214] wlan0: associated
> Jan 30 23:31:40 ws1 wpa_cli: interface wlan0 CONNECTED
> Jan 30 23:31:41 ws1 dhcpcd[24556]: wlan0: dhcpcd 4.0.7 starting
> Jan 30 23:31:41 ws1 dhcpcd[24556]: wlan0: broadcasting for a lease
> Jan 30 23:31:42 ws1 dhcpcd[24556]: wlan0: offered 192.168.1.100 from 192.=
168.1.1
> Jan 30 23:31:42 ws1 dhcpcd[24556]: wlan0: checking 192.168.1.100 is avail=
able on attached networks
> Jan 30 23:31:47 ws1 dhcpcd[24556]: wlan0: acknowledged 192.168.1.100 from=
192.168.1.1
Yeap everything looks good except your AP doesn't seem to like you to be id=
le
for more than 8 minutes, that is if no traffic was going on in between your
dhcp negotiation and your disassoc.
> Used Hardware :
> My Router: Linksys WRT 160v2 Standard: 80211N. maybe a broadcom Chip
> My Wlan Card: Linksys WMP 300N v2 Standard: 80211N. AR5416 Chip
>=20
> But at all it works. Today i have set the router that he only uses the 80=
211N Standard and it works with my Wireless Card.
I don't see any issues above. Please see:
http://wireless.kernel.org/en/users/Documentation/Reporting_bugs
> !!!!!!!!!!!!!!Big Thanks for your great drivers and packages!!!!!!!!!!!!!=
!
>=20
> Well night
>=20
> kind regards
>=20
> Alexander Bartha
Luis
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2009-01-04 17:33 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2009-01-04 17:33 UTC (permalink / raw)
To: ath9k-devel
802.11n chips. Is any one has ath9k or similar driver for linux 2.6.21? I
saw the ath9k driver in 2.6.28. It is higly dependent on linux 2.6.28
kernel. Anyone has PCI/PCIe driver supporting any 802.11n chips for 2.6.21?
any sugestions welcome!!
thanks,
MB.
--000e0cd15718164b2c0462176409
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div>Hi All,</div>
<div> </div>
<div>From Linux 2.6.28 onwards ath9k driver is part of the linux and suppor=
ts 802.11n chips. Is any one has ath9k or similar driver for linux 2.6.21? =
I saw the ath9k driver in 2.6.28. It is higly dependent on linux 2.6.28 ker=
nel. Anyone has PCI/PCIe driver supporting any 802.11n chips for 2.6.21?</d=
iv>
<div> </div>
<div>any sugestions welcome!!</div>
<div> </div>
<div>thanks,</div>
<div>MB.</div>
--000e0cd15718164b2c0462176409--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-12-07 21:22 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-12-07 21:22 UTC (permalink / raw)
To: buildroot
Author: ulf <ulf@69ca8d6d-28ef-0310-b511-8ec308f3f277>
Date: Thu Aug 16 21:54:48 2007 +0000
Add further documentation for BSP patch
I'm also not completely happy about that section.
Thomas> Is the author of this section on the list ? If so, could he
Thomas> mention what the intention was ?
He posted on the list a few days ago.
--=20
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-11-21 1:22 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-11-21 1:22 UTC (permalink / raw)
To: buildroot
DEPMOD=$(STAGING_DIR)/bin/$(GNU_TARGET_NAME)-depmod26
And 4 lines further down this is even used directly.
This tool is pulled through this dependency:
linux26-modules: cross-depmod26 $(LINUX26_DIR)/.modules_installed
And this cross-depmod26 is provided by module-init-tools.
Nicolas
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-10-23 17:17 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-10-23 17:17 UTC (permalink / raw)
To: buildroot
config BR2_TARGET_ROOTFS_EXT2_BLOCKS
int "size in blocks (leave at 0 for auto calculation)"
depends on BR2_TARGET_ROOTFS_EXT2
default 0
config BR2_TARGET_ROOTFS_EXT2_INODES
int "inodes (leave at 0 for auto calculation)"
depends on BR2_TARGET_ROOTFS_EXT2
default 0
Adam> Strangely, when I mount/chroot into one of the pre-built root
Adam> filesystems available from the uclibc website, I can create files
Adam> without any problems.
The really old ones? They were afaik padded to 128MB.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-10-23 17:17 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-10-23 17:17 UTC (permalink / raw)
To: buildroot
at91sam9260ek MACH_AT91SAM9260EK AT91SAM9260EK
1099
It appears you have the 9G20 suppost in u-boot but still have a kernel
for the 9260.
Hartley
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-10-23 17:17 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-10-23 17:17 UTC (permalink / raw)
To: buildroot
build 3.7x, so I have so far just fixed the 3.61 URL.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-10-14 11:50 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-10-14 11:50 UTC (permalink / raw)
To: ath9k-devel
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-10-14 11:50 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-10-14 11:50 UTC (permalink / raw)
To: ath9k-devel
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-10-14 11:50 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-10-14 11:50 UTC (permalink / raw)
To: ath9k-devel
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-10-14 11:50 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-10-14 11:50 UTC (permalink / raw)
To: ath9k-devel
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-10-14 11:50 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-10-14 11:50 UTC (permalink / raw)
To: ath9k-devel
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-10-14 11:50 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-10-14 11:50 UTC (permalink / raw)
To: ath9k-devel
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-10-14 11:50 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-10-14 11:50 UTC (permalink / raw)
To: ath9k-devel
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-10-14 11:50 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-10-14 11:50 UTC (permalink / raw)
To: ath9k-devel
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-10-14 11:50 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-10-14 11:50 UTC (permalink / raw)
To: ath9k-devel
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-10-14 11:50 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-10-14 11:50 UTC (permalink / raw)
To: ath9k-devel
how can i else monitor the problem?
On Mon, 13 Oct 2008 15:14:37 -0700
"Luis R. Rodriguez" <mcgrof@gmail.com> wrote:
> On Sat, Oct 11, 2008 at 6:46 AM, Alexander Petukhov <al_petukhov@mail.ru> wrote:
> > Hello,
> >
> > first of all - many thanks to you guys for developing this driver!
> > i'm owning D-Link DWA-547 card (Atheros Communications Inc. AR5416 802.11abgn Wireless PCI Adapter (rev 01)), and i'm on Debian Lenny\Sid.
> > My current kernel is 2.6.27 released not long ago, and i have one problem - connection periodicly losts, i.e. i can't even ping router i'm associated with. After some time (5-40 seconds) all becomes fine again. This happents one time for an hour or so on. Interface is not down when this problem occures, gnome applet shows it is up and have a normal(~90%) signal strength. Now i'm using wpa on router and wpasupplicant package on debian box(without any network-managers), but this still happents even without any encryption used.
> > Would be glad to help in testing.
>
> Can you do this:
>
> sudo dmesg -c > /dev/null
>
> Then connect to the AP, every now and then do this:
>
> sudo dmesg -c | tee log
>
> Keep doing this routinely, it'll keep overwriting the data from the
> kernel ring buffer to the log but you will also be able to see it on
> the screen. Once you see the strange disconnect issue appear please
> play more careful attention to what comes up and send us the log. To
> be safe you can just use 'tee -a' to append to the log all the
> information.
>
> Anyway please send us the log.
>
> Luis
>
--
Best regards,
Alexander Petukhov <al_petukhov@mail.ru>
--Multipart=_Wed__15_Oct_2008_01_31_40_+0400_4IyuS81Mmz9KfB9=
Content-Type: application/octet-stream;
name="log"
Content-Disposition: attachment;
filename="log"
Content-Transfer-Encoding: base64
WzEzNzIxLjMxNjg1Ml0gd2xhbjA6IGF1dGhlbnRpY2F0ZSB3aXRoIEFQIDAwOjIxOjkxOjA5OmY5
OjNiClsxMzcyMS4zMTgyODJdIHdsYW4wOiBhdXRoZW50aWNhdGVkClsxMzcyMS4zMTgzMjJdIHds
YW4wOiBhc3NvY2lhdGUgd2l0aCBBUCAwMDoyMTo5MTowOTpmOTozYgpbMTM3MjEuMzIxODU5XSB3
bGFuMDogUlggQXNzb2NSZXNwIGZyb20gMDA6MjE6OTE6MDk6Zjk6M2IgKGNhcGFiPTB4NDMxIHN0
YXR1cz0wIGFpZD0xKQpbMTM3MjEuMzIxODk3XSB3bGFuMDogYXNzb2NpYXRlZApbMTM3MjEuMzIy
MDgzXSB3bGFuMCAoV0UpIDogV2lyZWxlc3MgRXZlbnQgdG9vIGJpZyAoMzIwKQpbMTk0MjQuNDc3
OTU5XSBzZCA0OjA6MDowOiBbc2RhXSAxMDAzNTIwIDUxMi1ieXRlIGhhcmR3YXJlIHNlY3RvcnMg
KDUxNCBNQikKWzE5NDI0LjQ3ODgzMV0gc2QgNDowOjA6MDogW3NkYV0gV3JpdGUgUHJvdGVjdCBp
cyBvZmYKWzE5NDI0LjQ3ODgzNF0gc2QgNDowOjA6MDogW3NkYV0gTW9kZSBTZW5zZTogMDMgMDAg
MDAgMDAKWzE5NDI0LjQ3ODgzNV0gc2QgNDowOjA6MDogW3NkYV0gQXNzdW1pbmcgZHJpdmUgY2Fj
aGU6IHdyaXRlIHRocm91Z2gKWzE5NDI0LjQ3OTcwMF0gc2QgNDowOjA6MDogW3NkYV0gMTAwMzUy
MCA1MTItYnl0ZSBoYXJkd2FyZSBzZWN0b3JzICg1MTQgTUIpClsxOTQyNC40ODA3MDBdIHNkIDQ6
MDowOjA6IFtzZGFdIFdyaXRlIFByb3RlY3QgaXMgb2ZmClsxOTQyNC40ODA3MDJdIHNkIDQ6MDow
OjA6IFtzZGFdIE1vZGUgU2Vuc2U6IDAzIDAwIDAwIDAwClsxOTQyNC40ODA3MDRdIHNkIDQ6MDow
OjA6IFtzZGFdIEFzc3VtaW5nIGRyaXZlIGNhY2hlOiB3cml0ZSB0aHJvdWdoClsxOTQyNC40ODA3
MDVdICBzZGE6IHNkYTEKWzE5NDI0Ljg1Njc4Nl0gRkFUOiB1dGY4IGlzIG5vdCBhIHJlY29tbWVu
ZGVkIElPIGNoYXJzZXQgZm9yIEZBVCBmaWxlc3lzdGVtcywgZmlsZXN5c3RlbSB3aWxsIGJlIGNh
c2Ugc2Vuc2l0aXZlIQpbMTk1MjguMDE4MDczXSBCdWZmZXIgSS9PIGVycm9yIG9uIGRldmljZSBz
ZGExLCBsb2dpY2FsIGJsb2NrIDUyMwpbMTk1MjguMDE4MDc3XSBsb3N0IHBhZ2Ugd3JpdGUgZHVl
IHRvIEkvTyBlcnJvciBvbiBzZGExClsxOTUyOC4wMTgwNzldIEJ1ZmZlciBJL08gZXJyb3Igb24g
ZGV2aWNlIHNkYTEsIGxvZ2ljYWwgYmxvY2sgNTI0ClsxOTUyOC4wMTgwODBdIGxvc3QgcGFnZSB3
cml0ZSBkdWUgdG8gSS9PIGVycm9yIG9uIHNkYTEKWzE5NTI4LjAxODA4Ml0gQnVmZmVyIEkvTyBl
cnJvciBvbiBkZXZpY2Ugc2RhMSwgbG9naWNhbCBibG9jayA1MjUKWzE5NTI4LjAxODA4M10gbG9z
dCBwYWdlIHdyaXRlIGR1ZSB0byBJL08gZXJyb3Igb24gc2RhMQpbMTk1MjguMDE4MDg0XSBCdWZm
ZXIgSS9PIGVycm9yIG9uIGRldmljZSBzZGExLCBsb2dpY2FsIGJsb2NrIDUyNgpbMTk1MjguMDE4
MDg2XSBsb3N0IHBhZ2Ugd3JpdGUgZHVlIHRvIEkvTyBlcnJvciBvbiBzZGExClsxOTUyOC4wMTgw
ODddIEJ1ZmZlciBJL08gZXJyb3Igb24gZGV2aWNlIHNkYTEsIGxvZ2ljYWwgYmxvY2sgNTI3Clsx
OTUyOC4wMTgwODhdIGxvc3QgcGFnZSB3cml0ZSBkdWUgdG8gSS9PIGVycm9yIG9uIHNkYTEKWzE5
NTI4LjAxODA5MV0gQnVmZmVyIEkvTyBlcnJvciBvbiBkZXZpY2Ugc2RhMSwgbG9naWNhbCBibG9j
ayA1MjgKWzE5NTI4LjAxODA5Ml0gbG9zdCBwYWdlIHdyaXRlIGR1ZSB0byBJL08gZXJyb3Igb24g
c2RhMQpbMTk1MjguMDE4MDk0XSBCdWZmZXIgSS9PIGVycm9yIG9uIGRldmljZSBzZGExLCBsb2dp
Y2FsIGJsb2NrIDUyOQpbMTk1MjguMDE4MDk1XSBsb3N0IHBhZ2Ugd3JpdGUgZHVlIHRvIEkvTyBl
cnJvciBvbiBzZGExClsxOTUyOC4wMTgwOTZdIEJ1ZmZlciBJL08gZXJyb3Igb24gZGV2aWNlIHNk
YTEsIGxvZ2ljYWwgYmxvY2sgNTMwClsxOTUyOC4wMTgwOTddIGxvc3QgcGFnZSB3cml0ZSBkdWUg
dG8gSS9PIGVycm9yIG9uIHNkYTEK
--Multipart=_Wed__15_Oct_2008_01_31_40_+0400_4IyuS81Mmz9KfB9=--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-10-14 11:50 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-10-14 11:50 UTC (permalink / raw)
To: ath9k-devel
computer) I get a stable stream at >4MBps.
Eirik
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-09-15 17:22 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-09-15 17:22 UTC (permalink / raw)
To: buildroot
>>>>>>>
And add uClibc-0.9.29-cygwin_host_loadlibes.patch
for solved identical problem during build uClibc
Issue History
Date Modified Username Field Change
======================================================================
10-24-07 08:28 AndyI New Issue
10-24-07 08:28 AndyI Status new => assigned
10-24-07 08:28 AndyI Assigned To => buildroot
10-24-07 08:28 AndyI File Added: fix_cygwin_HOST_LOADLIBES.patch
10-24-07 08:28 AndyI File Added:
uClibc-0.9.29-cygwin_host_loadlibes.patch
10-24-07 08:29 AndyI Issue Monitored: AndyI
09-17-08 05:42 AndyI Note Added: 0011544
======================================================================
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-09-15 17:22 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-09-15 17:22 UTC (permalink / raw)
To: buildroot
>>>>>>>
And add uClibc-0.9.29-cygwin_host_loadlibes.patch
for solved identical problem during build uClibc
Issue History
Date Modified Username Field Change
======================================================================
10-24-07 08:28 AndyI New Issue
10-24-07 08:28 AndyI Status new => assigned
10-24-07 08:28 AndyI Assigned To => buildroot
10-24-07 08:28 AndyI File Added: fix_cygwin_HOST_LOADLIBES.patch
10-24-07 08:28 AndyI File Added:
uClibc-0.9.29-cygwin_host_loadlibes.patch
10-24-07 08:29 AndyI Issue Monitored: AndyI
09-17-08 05:42 AndyI Note Added: 0011544
09-17-08 06:30 bernhardf Status assigned => closed
======================================================================
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
talented programmers, but I definitely would not want to give CVS
write permissions to more maybe 10% of them.
That does NOT mean that there is any discrimination, or that any con-
tributions will be igrnored or turned down - if you want, ask if
any of the people who contributed to PPCBoot has reason to complain.
Please start for now by sending patches like anybody else. Normally
there will be no significant delay introduced by my moderation. You
can be pretty sure that I'll want to add you as developer rather
sooner or later. But I think fairness requires to apply the same
rules to everybody.
> Also, to be honest, it appears a bit rude to me to take our ARMboot
> sources, and then just cut us off. It seems only natural to me that we
Umm, calm down. On the same base I could argument that you cut us
(the PPCBoot guys off) by taking "our" PPCBoot sources and creating
an incompatible ARMBoot. But I don't intend to start such a fruitless
discussion.
Let's focus on what what we'll have to do in the future.
> both continue doing what we have done all along, only with more
> benefit for all of us.
Definitely.
> Please let's keep this an _open_ project, not one where only one
> member has the power.
Umm... please don't misinterpret my role as a moderator.
It does NOT require write permission in the CVS to contribute to a
project, or to get credited for your work.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
See us @ electronica 2002 in Munich, Nov 12-15, Hall A3, Booth A3.325
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
was only able to display the logo included in the file logo_linux.h. The
MPC8xx LCD driver use the logo
included in bmp_logo.h. This file is very easy to create because the
tool bmp_logo is included in U-boot.
I saw that the video driver for the MPC8xx use another logo created by
easy_logo. I think that it would be nie to use
only one file format in all the graphic drivers.
To use the BMP logo with the cfb_console driver, add #define
CONFIG_VIDEO_BMP_LOGO in the board config
file (see RPXClassic.h).
This patch fixes also a warning in mkimage.c.
CHANGELOG:
* Patch by Pierre Aubert , 20 Nov 2002
Add driver for Epson SED13806 graphic controller.
Add support for BMP logos in cfb_console driver.
Best regards
--------------0B1BBA13D4BCDB8F61B9A1AC
Content-Type: application/octet-stream; name="sed13806.patch.gz"
Content-Disposition: attachment; filename="sed13806.patch.gz"
Content-Transfer-Encoding: base64
H4sICL7F2z0AA3NlZDEzODA2LnBhdGNoAOw9a3fayJKfx7+iz9zMDBiwJV7GduIzvOywiw0HcJzs
zF0dIRqsjZC0krDNZPJv94dsVbfeEiAy8ey5ZyE5Ruquqq6uqq5+VHczU+dzUjJX1h0xTWVqGE6p
fCKcCCXlyT6dGrI1Ox0NP7Y12bZV5fRW/kznqkZjsJoy2wx7VCqV9qH9Q1kQyiVRLJUFIp5dCPWL
cuNE8D6kIIiCcFQoFPbhIU7z7KJ6lqD566+kVK4Vz0iB/YVXVVe01YySN7nJYNjpjfKniqHP1cXJ
8vMROSL9XuuHd0RTp29yrUFz1MmfyJBcGrT+bQzpfqJB5sDO44lxVNiYRaiivAAEUH2TA7r5ix9O
ZtSk+gzeESt/RH54k2uO8kSxnsibX8mb/zya7aU7VoKSRWocMqveOPQP4vmZUBJE+E8E8UIQ4P+3
as2lmFVnQhHexGKlVgGdHRVOj48K5Jjk2nnSNsy1pS4eHYK0WPLY+Z/VVFPJtfxErQW1SYm8fX5+
PrEdGdNPFGN5xQCHKrUsSpr3re5oQoh5AvnUcn4NASIcJ0opYc2iPep2epMxmRsW2IXtEGNOTGqY
kPX8aBCwHsdSpyuHzohjEOdRtRm+aRn/RRXnxCc4gRxMXVjyksDj3IISbGPuPMsWvSRrY0UUWScW
nUEhnCJRHSLrs1PDYhSWBljHGhNX+oxaUBYlDrWWNrKELzd39+SG6tSSNTLEGimkrypUtymRXa4w
1X4EXqdrhnKNXIxdLsi1AZRlRzX0S0JVyLcIiNSGd1KGQhgJxHKpFgnIJCc7yLxFDBMR88Dxmmiy
E+BulkFQ1Rk0TEb60TChVo9AFOr5rGoamVKysul8pRUZDYAmD73J+8H9hDTvPpGH5mjUvJt8ugRo
59GAXPpEOS11aWoqkIa6WbLurL0q3HZH7feA02z1+r3JJ6zFdW9y1x2PyfVgRJpk2BxNeu37fnNE
hvej4WDcPSHMIoAqo7BF0mgnSwOEOaOOrGp2UPtPoGIbONRm5BFMFVStUPUJ+JPBisz1bi0yKrJm
6AtWV2ZsnjgviTonuuEUybOlgukwW4zpl+EHOi6Snq6cFEntnEzoEg16qMkKaHW8QgqVilAkLcN2
AJKLrUmEsgitV6wIZ+R+3MTUU2yd5IM6owaxV6ZpWA4TARbebbc/kpm8gtYK1sB8Atn1QYL47x+e
o34LrXIJRvR4FU1kThsTMXk+o3PSHtxd926kD71OdyCNux2x0hDqYSSbzliai4b/gPexAjLSCae4
spho7AtuQLrqqLKm/sESPQWNOWXCnTm0Ph0EQYjN6UCDhRQ0bVOT19ho6Ql5AMOGDBCxoWtr0pia
JgMU6wQfEciOywBYYwLkcgNNo3i5PaPyZXLXbZO7fr1abbTa4FDd8jeLNSomwJYCbMiFPFWnpNMb
D/vNT9JDrzN5D5j1akrm+27v5j240GpD2KUAqdEaDo8K4GMdsGSQMrjQsdiRRt2bMROwZNGFTX77
J3lHjgpfmCjJF+EFOgSxiF9fi5BwekpuVVuhmibr1FjZZEQX4DyoFcCL1+0IfMfVwC0INwVcEKoA
Lk49cK/J9QbQT+g2dDQhe/DxiRCmUIsUmJGCGKbQAAq0toWCYxnahtLPkf95ZtxwuaKAnJd90VLw
WGvS1gzl8wa2w8hMcH61++0OlPhCtcz4jUjh7dHkdPJhTxLtGP8zVR5qq0Vm/C7iiz4Lw3syMTwx
PMjQ9YzBXqGpUw068TQKZWacVd/YRs1bAINO3X4kI0RNw2lGDRRxJupS1Rc7VF1uRdjdjhjWcxn1
3BDiet4lngqilX2zHEKb08hkbabWqhJrpoPORgFUygBavQ5bznvDUv+AKoDleg32QZ2Bf0tDZ4ZX
2YB+Z+glj8SQWqoxS6VRi4hycj0h18N+766LGoe+a2jY6kax1BG3lYI7XGnQ9W9mHC2+E6n3Bxh4
qkqo1u8pG9Wm6r9yHmE6E37YDCpoeOV2Kn5GsbUiSuZVvwY7zCS3dorMOfIOwVWZn4pofJdbr4oR
14Aou3oOoVqO1C5cDK9dczaDlm2na6da2Rc7rJtqdV/schgbTbIawXYbuYc2mM9tusGuqmcJu9qB
HeG8keCcO3HwFzr4plRJNzfW9rp3PSDvwYhhmoBu1IBxcty5hSm1tlPqG8/ZCNWEiFNyu6N9/FKt
HPFLSQrZ2litEu2UXDKjSTtDG6tVI74pjLyjjdXqEefkYu7ln2pnaZzv5aJqaEzlOP97eqka85Pn
cSIZJdhMrUQWCcac4wcyWDkmzES3WF096tnc0nY5t3rUUcWwMviqeuUbCIT1VK9+A4Gwx6pHPZZL
YA+nVU81tj38Vr2RVoWdrqve3FbzPb1XvbWTWGYHdiYkPGFP/3zaXlk2TMS3IYrbENN1GUZP9pou
6sdkQ4uo8CzZY27BDOvuLNlbupifdpVZ2wczUmZ9m5ha2oqCkDV4FFKldLYN+4bN2behJzvZEPqI
zrYio8mK17s5F1Ox0UYrm7DDnKejt7cVHnCejtzdVm3WPoK2kYLfENLaV7Zm0RB34O5sGY1UN52x
cTRSXXTG9tFIdc8Zm0ijtidypOT6DqntaiiNsx0EdraVRqpjz95cGtHmsrUKqVbbiLaY7VVIp9De
wcKOdtPo7hDBzqYjCtGm01KdlpYcyoQNR4yt1G1CEcMo5TSU0WAIaDN6yqvYfTFl3U4fr4lCJY3C
wKQb1zVEoZqGMjZWlkIzjJ7E2IJfJvxIpev745fD+I00/A61HVXnlc5SifNvJBKpSfMbiUSq004j
kn0oKAqdbyAQroaYauvRgX6kRDHV0mMIkRJS7XzLZEoUU+16y9xJFFPNuiUrnxcWRntch5FeWqpJ
b8aNlJtqjteGRTOUm2qFm3HD5XZjA17D+Fy6N8lEnmp009RJ7Ja3IG3uy8VudQteR3bk1FCEEFki
HxrPUIUxBv12rb2K11ELC6HikvSGyEes1x/elxyj5LUDRcGqPciO8jgzFrhwTK1UKtFluq1z0SIR
vh4Vvl4eFf5B9Zk6J6fHW8I/bkRra5hIrLM40SFSdIgUBfiHSNEhUnSIFB0iRVkjRbUw44dIUSJS
1Ihg7x0pKu+BfYgUHSJFh0jRd4sU1WKl/X+JFDXiBPaOFMWHj4dI0SFSdIgUHSJFh0jRZuRDpOgQ
KTpEig6RokOkyCNwiBT960aKguWwQ6To/zBStDtWxGJA/KxSHDJ6XMk/JhYPKsHXeNDvSt2Pk1FT
6t1dD/hRqtL3/BzhabgnPPImLagjqfrckGzHIqUSAf+xMonsHtrC04364oI4a5MWiW1SOisS6ijs
TCDRVJ1K+mo5pdY7ohkKV7RjEBOP4REk61IgU2pDcQC0MBgq5r0j09V8DgrC43YhYAT47tUFcT8Z
6iyt1jlVd8J1KRLlUbbIMQLk/TgdKDMXAiLv3hExT9xM/AApxVwjtblRJD+S4PAwF+aP+UsO/JV/
UVxoCeEzCfwmYHDwl9+FXwJgMD7Pnl7LFhiDEpcNBirREtg36uyX7nA8uCu6BwzJbEXa49fS0QrG
QAudnaZ1klzlUIWBSp4MDUxOw3OyS9mUHCbGY/ZCQIo5L/k4376+kXq3t6PLGOKSLhVHa7y8IBR/
AcSfGWLpSl1KPI21fUSE5jx0T/+yo42W6ytCZx+zfbCu7DuHdKT2eCSW8+TPd4ys1KgLl/H8RpDd
6pI/iZte3gbYvWOqc0H4X16j0hV+S4ZVhvr67mvgCSgCNI0Cjbo3UrPTGQEPflqz3e6OfSlZ4EMs
neQSKNgCvr6yDcuaOpMdKrmnScGQX9WfpJeai9qxbNPAasGGmoqjPmHgEE/jmizkOFVlm5isB9zf
hnx79ovlHiyfw6JJgaACboa9gdSejPp50CauS3JlvJ4q0MmyDQ+vqIPYJovjWMkxh+EZpr8XI/93
yOCZDZlfUQiBrwyK21DzyOHov6E5IkOPfDz/twnALW+HBPgJcF8EO0Z2WMzWq034If/TGX1SYQya
eqdJHGTDZSZxsMidIw28e6YmZrzFZCupswvh/EJMksLrS8SzMt45w7/YpTM4FGBUIj0xiQ5e++3O
EflhZj1JULoLCBIm7uCllLJ/io1/CT+dP8uFc6Ab+zOe0b5ueSPkvFtSeHgQKivG2UNfqg6Ht9K/
dz+xa262K3NmqXj1x7arheIgG5QZB4troHJRyXolzS5SZxe15J1EqMyKiLpkf+HVve6notQa5ycG
qZ0JoqXZ8DRVlvDy4j2BeAlR5lMJXayhUUhX7Ma5IMDDTCnDTBxBKTUtQ2SJvzMMtSFUy/Cmy45N
lyo+2WK9VhPYU6PSKL/wp7OK0PCxTAUh4a8krxzDfVRBkRZeQYNQJQalU3yzqaXKGksuRJLd2zEi
EEjeXirnInwwZ6n21/pL9xaf18taRYHRnw/oqAtDr8DrcwMEVKvMsdZOHWotsIuQMllNWGhpfiAV
bof9RGCTRpTZI2ShVxMuykmjREuq14p1Uqjzm6iOSHzOOunddv3RScm/QcSBWfgpjo7wipyVacIQ
h1+ApBiWDtOto10DHR2mnTbBMXz7tiN1mpMuu3skVnr7fjQejAKuuAPvD24GIVIBV31VX72QPkxI
A7Y0Ove4gk4jQqd1OwzTKuGVPmS6NCWNU4BZgDzDC1Y0pMtSkwIKJvURVuTZjEUbZM27KwWmgtaS
T6f5nNjeKSR25ZCOaNqaLAxq40SctwOCl9qc8MuLuEPdSc2i/72CxmcHKwEmVdQ5zGXnK11Bxi6Y
RZxX0CLOq8UG+paIxN4/uCq58ER2byNXMOTFK8Viyx6BY4fM0JU3UB3NUPiFN9A7f8/P6RHr7nkr
cLs3Vz42v6JmfNsjMNkzH6Heuz8uwaa+Jga7espDXa5gjAojcn1B+ZVHNmUizECQdcZiHYWM64hi
fT8xe53h9xcd3u7TcWXlXZfkD5a4l8kgslBNC9+dw+23KgV3AvEcMMB+bzLBVnrX6TXv4vkg51G3
Pbnu9fspWa3epNWfRJdpvm910LR6bqvgY5759OSRyHNcMmbsMB/C7lJLcIxrdim2+p05DFptwOAV
v8JQPEMTLleEolhFE2ZzZ/i4fZCk8JAdW4rD/fM0GMqRxKDcN3lWDd+VJB2/bwPpvjzsZzxXzq/p
iqgXQf3bpNjHI8BTU+G9C6ai8Dw1FaF/P5EG19fj7iSMwFNSEdqD/mA0jpfAU4/YjAYXGJPS83sy
pjKXbr93d/8xpaYNIRUmUrsNMBH+ymKVG0K5VhQrYAnVelGsZbcEX09B94qaIrs0Fa9XKkakNola
HpV26yuEFKTv1lpCWv48NJvWeBaOJ6SP4dadi4sjn4rzKQXnenA3cSt+Ws7DlA2taLMxbWApqQhh
t+QFLI27z01S8IuLUwPxjUnkw9M/9Ma9Fg4OIT+OMxo8bMXBfGa01XqlKIqkUG3U+RzKPeGj6hgQ
IKG4wsySn/mAjdkv8unChoDMlYPLcwzi5aXIJtfrdTG2eKeAzr6kTpm572IMB6Uijk1ySG+9JoWk
kIvkZ6VIRGhNrk5LWwhEgPkQ4utrjCLYpOKsXmyAS6ifg2sQznyf4AsLuOLLfHxR004sO4SlwlDR
PUimZrjrFIDDlmW5qNn6GH/0hM9FjfJgXuezamL4wF23S/iQPDl2xTvsfez2pXHvP7rFI3ftO41A
ojWmEvCt8EUxVroDrBU5T/hZszQgmnBPl0EEyQdKKP+SU49YWED82ObbMt6FJi/FgKybHeLweEZt
jLa8Cy10uyvO3i2OBZLLraGeXAbJ+uYB4iUfqqFVJIsimYaq46YUyTHTp4WxR/441VbUe15gcZd8
0pA0iqCrR4p+Pb3eXpqqzlI2IwESHMJrLJqJt9MuYe4kW2uY/2BIE0e6irEEo8SgpoJxexZsSv14
6/Me91Aun82QXKy79iKDQYUywqIgdoOyWQ4yTTnLZDPP2z9ejeasg8YwwiVRydtk/wbJhUIkOuoL
4TcVI5w5XwOmrFEHOMP0n4nwIswFIU+urkj1MobNBbMTHwjk46hMTrsxhXmevH3rl/zV7fdixhM0
ksuEgoM8TEhTawjCNd2EOkMgmHIZTCuYlbJqYTiai73TnDSh2x7dNicYlL7pXEtSA+Yj0Md3uh/z
HPxL0NDiyksMQrjyAglm1HbgHkKF4cdK+Il8VEwEVXAZRVpsRWKSSyJNtyJ5RhBD4v2MTR1JW0GH
kTqUA2elFj2HFLauFAJqtPcNiBSjaLFPuIEUYwZfjFpx/jKQ9dcj74s/PD/ienWOdwWlUlT9Lym9
COuRXJG4yC8+cimmziyq9HqTUvqoOCz+LEreg1wW9WcgFxC0n1UYqqU0tHwAE5KOgsHWWPu7iBob
7znfeX1q3H4tKn++3EiwUimPblobKOZy1tVVLf/2bS1P/oS3BX8rs7fp1VU9n7UwsYaF1Wq1lMIC
8dqPeFP2cZ4XHwUbPzSHYj0XA87nGI8V4EoUfCYrPstTfMlnZ7PO2Ky/Jpuiz2b5W9mslJHNj41G
Yyuf7FL0LXxWyrkoMLBpAYd1xtPi7Vvc9gG+KTNf5Sry5bHle6aXlDGk6yJ8mISb8HO+RF0cuovA
rwVNL9U9/jPmVhcesusG90Sfeujxdp8JO/q2xQ9E4GLVT/cHiU4g4RMSEK4StxH3fMNG6ln8w34F
R/1EsuCNjTC1G/yLPmNP1iO+4/VZ3+pH9mM95k+28R7zKRt538O37Mdr1Md4s/YN6+0Rt4Us872Q
08uUHBFzFmk5ZcyxooscSaLWNxCdptQ+wmZ6rkc1PddjNzzR2MjyNxcwDe3BCEOkKW9T+teYS2S+
qlCIQTFTK7xLTPcjI9ZSkkhpN4FSCNmDwpWWEAfRZI/t3esC7Kdscl5P5Zl5KJV1QSnp2Lfkg/kZ
G4aXXiGyEl1GPOYzDhZ59jbifOHVZaswGD7+TSw3vE6NvjjU0nme+5M2El+lvPSmDeEVMzd2I8n8
pEAxtMRaJLgdHucfXA+2CVScub/n+Seb5H7C3y/6yc7/WCT3UmswmEgfuqNxD3cQSyx4L0n4hJsF
JMmTaZIQoP8cZdab9sSXWr1+ma+DFyMr3EUmDMZwPOKc3GifaXeHv8tk29aOAGjHvo4A8C/8WFUK
seiesXL9Qihv/Z0qoX74narD71QdfqfqX+93qrqmjUcQva0XyqNq4hnAnR/vRruUX6nKsHUiNdK/
+ZeqvMAbjCtmrbVDc6ZjjegiH2fq99072n3Kqi23+O52l1i4IKabUEnFJxm76r9WAIykGJlEQQ+G
NUsvKJdWkjen2F5ULsdI4VJ4g+TZCvV8zucRPOPtW9Lw0gUhz+p/VLjhm446fDuTVwI7m/Ea27yZ
+Y2pM3rljf7h8U+kzNg271PuOLG3oLrjNXWvVXjndUI/fcby+R63nIJX6sGA5+TkJO/FOuInDEyg
gUPq2EEDbyDjro0wqNIVNPwZfYkEQnzLjAEViff6QXZHlR4Ky/CH2l/ZjnV8es1zgY/P/kGwVz0/
cxwtLqbNyDGa46clDOf8U0ZLukSV5n72bJwNTm31DwpKz0WaAZu5+vbRS/1RPJmfHXXdubd1zzUc
Xxcj6ljYl7AzPcQdIceszAeG9u2aVvKXRBOub6ujxm+M+CQ9xruUU3L5PAaChP9t70p/E8mV+OfO
X+G3TzuChCjdDSEkbFbizCABiYDMJtKTEASSQUMAcWQSad///lzlo301EHJopTf9YQ5cLl9lV9mu
+lkTOxH+0Lyu15VARG59C673VMENC4P5gvJ1LE4IZNctXlerlRY/OMsbHH6OJm06BDfaFOEhKckY
4luNWIRvsDGLiw7Q8VmTBuOHwT1OKmLdh5lVoJQwGRdXV5Q2kBfBdDu+sWAM9t1QsnrQtLbokMcX
c2+b+Zyq9usJV/R0AkgFjyCzkZuhxpFOCehPdfDkeOw7un3fVRl1qtSnPSx690BHVYL1dVubk+6p
Ev1zuwkjCooJyjMlWqtBaTyE7THaV48snFzOPLVDeR8fiUvip0ft1gkXqqQ9oVT1kBhph+Z0XaPb
OrheVd0Q9rSoJbnIfWDEGg5P92dvtOyO4KVPuvQjPixYmdQ2GuDOha6P/SG1FanRT2k+Tdsr1TJU
BFe4wrIkiWK9g2GOPrONcr42zC1w0++Rn9O53AkBIEO9IwadNrKHrvPfV8vB9KdGMpw8gM23PvRy
nXUHdaNmxIcG3kmF2h8t++OP1+BmeQmH6u7PZiltptKR6MNyQyDsYoZ4dKJPtYyL+V33OaVn5Dc5
s+mCPMfneonP9eLONVgsrbLwRHFNSZDHLEnmiStn9GiVg+uEcJaKy/RCXJm4vhS51IhHbuzqW4L9
2UUZlizj1+QXZa+gFQ/7YI92KSCHpKDF8A+TiLnrzgHk4RyfBN4nUA41Z4UGkrOQs4I64ECBGsKc
4BOGPz3D8cNsJuwFXiRkwP7WM+CwRRkUVaMuGkltcY22hzgjL68ADqSUzHtHR1xQXHSMLEzmKdXj
FIzAMV0e6SoyQ7gw+gMLWAOrEs8NKGOFD+4SgU+j0gDrCaxV1mNHJBT1AyuPd1xkSthePc4dhVz6
GK7KBryJmGyBZR3qlcfLYD+VQCkmhySQ10I6HXM85IQvGqFcjMF+X81YN+5uYQjJ1xvUbpUQc8BP
cXnTqmmRBYLszz9zybxTTARpGJEGWUnrylFud3gduAi76yDIAkEWXwdBGkakVh3g3e3JQ++BwQvA
kiz11m4dSxmCWPcmD6sxtZFgpKiEg1lAOwJD8QaLLU6c4kYKlXXK0tQween6soSjybvVfA7beZCU
BYFYFzxbfUWRzgXhgwwpqRGh1+6h/p+mg2WJ76qF//ma0ZnJ0IxaLuYIa+RCUcMEkeej1Onbteh7
KcVPWYw/cyH8IKWlE1Yv0PXVT6G4RP3oMhioXcEtULofZUL2yn60LQfdcPgHmg7eL10UW2ScLvpI
bSTckz9HE0lnaMf6NmKn3dFH+5ctuhxZzVqv8WZmrqsuJgiDGOIHm5h5EbrJ+8QiR69Be08VSQtA
KoH/ICxCKdYoYq9qggp8BlPEsezpBA+bCPpcVFwXdDIs9qPliNoZPErz86QpKjOhR25ZI0MS9VKZ
90T3pp4iiWdxeWb1rk7bQFq4b9tAeQtcX7bjettAWsn1g+c5Qlt99gAZheII3U8n/OCfDRX+n1lk
DgQ/4xZ2trRMI0yY9ZbgyiT2yrCayD2lXKzhfofwqvB7QKm6ODQ03BKBX0Q285zNMMt3IWkYnK+4
02EZ+OGgcm3IYNsAGJNaWysA2cAf4OpQW+zx2gZOkKMTSkU62p1Cq+O6r6E94AqvSziuag5IuVIt
XFPtxdYBaiRctm7Ra45aMF//YkVh0N16tf5uZdL27pNccBomrcMEOj5V0KLQt/ej+YIhb6Lijn4a
Ps6WLzwB8Q34KKifHYuWEuIRhSplM3YkGgwIpEUCmjQdt1GInoZzgO6T6MCv+eT2QfQsr9jfgLyX
jvU1V3wszbHh1SruVp9tqhXmnRXh8vuFpFFK01Zn7TOx0aemTAS3CCotyuynogGexVBkr2eQI7Hp
U6qOqrOKguCPP9g9Gk+WAldezcYjFs8JjjzjXexPh8AFTMaUptnCBgCaAArL45CTtIEpEZScxL45
hN5IwR95fSYe0BKy+oRVKhAv32aRfASwFK0aG4uUHcjfBhRrIaAkv6ED3Xqy1OzUWci5CnfL/17r
mcmdjo4YPu1CvTX87vCWXEce4625LosNz5feFoxra7YnZ34uDt0tc4KAGvSvkKFy/RucFu89bhoC
ti24unabl81KhIDAU4uF63Kr0Kl43mnW9z20xBkcUr+3GsxhypwTSOrPFh46IqN3M0f+EVyqlRJA
zXbg2gxgsao9WMPBq3EyXKrYWPI38FgrlQImFIesxia3yMfKTDA8eZXfRYbqRbdca5cuv1Va3auv
EucisHg2ajVdSAMJOxNhT8j2YQ9EbniirxLcW+TMdMaj/0aYYLyPTpHJlPwYvjBfI3VSgI+DXTXT
685I1vHEN+SOHqc1yFTcLTcLDpTjSlJwdAyuDhBzk8NFoVtoU4OheUEJy5VvtVJcDdrRvkb6PYAI
qJgiQp4vLzvlSr1w6x0GIM2AJgiTDhxgAcV+4KEUMzcLxNbK5hDoMhdyTDvO0AMRasPro3SOtOn8
wPBw/HQxq9YL7a+Mxn+uVgUJAndI/5FypXh9gXiWEsjystEoNMttqlcFrh1ta1L3d4my8V+I2xNl
G85Eb1rjslnr0FW3Xml6XiI8zoI3YeAnPbwiXwznT0MCv/4oorppTKlNPZ0rnbeGWxDmHNzgV5sb
jsEpwKochIGPKHLm2GIJlea3bq1NRYl1uBfYycwfCUYqhDGAsol4EYPA6lOZPI3m08kjHN60qT4D
gxKXH4MRGLHAJsO5dKbwsCE61sRzOVCFArlUSh1mD7MPzpT8aJ5apeVeU5oxCETvouY3eDVXrGYG
CUJ3Kx/dwvbgAWoBFnqMiH5pOi8yOWtGFFuZ7lWrUq81QNoL8LK0H3hQbSzzSxsKVuGAINOllqla
zfmnJz5fSHF5LLXh8HmJb/zu/KljoACaazRQfAnamsP/0vIPSYaKo25vbvkdkuIKNiujyfdRf7Tc
kQeLzaEj3ilsbo6EXhfN6Yk1yaZFSHa16Tk/UPgfgRVO+hD4wBwfzcLZMQW5GE/7tHYqwJyA+4tU
21ZtVVsksOpNaUyANN5hk5I2dS4C3BLUOQdZEOh0lKzoIgstspLmQy6LJWSNu7jelAOrss4K7sJQ
NsvZlp04hhFHteEaWjwCo+S4NJQNMWC9s8tnSQN/q0ClAZmFv2HfSwXVd0S7rvn8c6H18XRhPgRF
wKZH9lWMgnMynCAfntvZGF7J4IwVLUhHE/rzA13HB6PeZOutE2eoVkFhOB4tl7Q2w1fwtLq7XrFo
QOMZVEUXFSw3sr1hKn3G94dbIJpu0166uzmHF3nQXnsXhgFlWGqHcOBHtycDA6/UHs5NDAMfGR6/
H8MAzwfRUHpTk411ITRp4KUmi+rYpgr9+AkfWFx3q16tbNGAd5VBlcv6DqpgD9GA9whES7GjWfZU
8uiOP/p0RbvzrjcezvfIRux+sQ8XOPnrTg0kzYajAklnbuQzZ+nTV54PxPLKuc4aEJb5FCxq/JOh
9xug/OhCm7dw9KrlPUn8dG8RfwyKvyzQfOfnncD8RS9GIWlrujoi2jC+EeEbAncdzKwRDo/XBe6e
5n7F7f6K2/0Vt/v/FreLCy6emkZnfF+7ke7UfxV7Od5p6mZut09V5o6gsEhTh2zdgg9u/tAtj7/6
N2VHMyqrzmWnUO+2rwqlinp0wlhl+E43Io+/ggRDJ6OWzPqfmwp4uMLjnzkr9ZaUeB4BIy/MiNzi
NIbfAgtLbactP4z917/4Xcr+EeFjww+qaCFmrOprx0jpUE+6NHkJ9t5x0k4LeFqg7Cu5V7zHk0Ij
W5SSNjJJr2uenjFySndrnn4ckx7y9KyRLh0JeXrOKF96EPL005j8gn/ByC8c7HhyyZ0suJeNZOZm
yBID35XIcwZmZ3PHQ54aOlNF3rTRpiL3ReTJZpfzZJHb7PGqntvs0Kqe+1Q7IeHhTFL0ErC/4Ic3
KNXwhOxqRpa4e35zDKF6PiFcr2CmD0M7DdylMC3Dq8I8P45qkx9vq4heFeMCU+0J3z9RRcB0+tAp
AzflTV0pl1GGMZQNizLtpry1eWZiKG2ex25KKiN+t6hRZtdQXmiUJ2soWxplLpYyMEovrKHUSy+u
odRLL7kp8Zl5vZcqKP/gGwQamppwq7ulHdPOAgXxQ2ddp8cT+xASAG7GJRBBfu9A6vWi+4WeHcR7
2ydY8699/TK/5VON+XWvGVqJ2kt/PIBa3N2qFtDGE4DldDpeHD3+GD32HtyPdhkUMbtDg8qEYTo+
C0+23Bpu4JQ5S9uc8IGNYx8v0/Av+kPzhi42F2eel4cHzuBqxgOPnuf7ce8B3EaosQP/H87Iv84R
z4AccAyFBBZN+7hH91LdZRKoDz3Pu2dQXSSxWNKEeYr89vviDJ4zJze1qxQa1UO65XshsymMFj5+
1Gf+32MIJ+eF/D74z+Q3aje/I8fxClnSJnne3eNgQo3NVFxj8kg2fAaRrtzUqKIr1OrXrQpL+O/e
/wC+J0xthLgAAA==
--------------0B1BBA13D4BCDB8F61B9A1AC--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
was only able to display the logo included in the file logo_linux.h. The
MPC8xx LCD driver use the logo
included in bmp_logo.h. This file is very easy to create because the
tool bmp_logo is included in U-boot.
I saw that the video driver for the MPC8xx use another logo created by
easy_logo. I think that it would be nie to use
only one file format in all the graphic drivers.
To use the BMP logo with the cfb_console driver, add #define
CONFIG_VIDEO_BMP_LOGO in the board config
file (see RPXClassic.h).
This patch fixes also a warning in mkimage.c.
CHANGELOG:
* Patch by Pierre Aubert , 20 Nov 2002
Add driver for Epson SED13806 graphic controller.
Add support for BMP logos in cfb_console driver.
Best regards
--------------3E16665E1CF41E464E400FD0
Content-Type: application/octet-stream; name="sed13806.patch"
Content-Disposition: attachment; filename="sed13806.patch"
Content-Transfer-Encoding: base64
ZGlmZiAtcHVyTiBwcGNib290LTIuMC4wLWN2cy9ib2FyZC9SUFhDbGFzc2ljL01ha2VmaWxlIHBw
Y2Jvb3QtMi4wLjAtbGNkL2JvYXJkL1JQWENsYXNzaWMvTWFrZWZpbGUKLS0tIHBwY2Jvb3QtMi4w
LjAtY3ZzL2JvYXJkL1JQWENsYXNzaWMvTWFrZWZpbGUJMjAwMi0xMS0yMCAxNzowNjoyOC4wMDAw
MDAwMDAgKzAxMDAKKysrIHBwY2Jvb3QtMi4wLjAtbGNkL2JvYXJkL1JQWENsYXNzaWMvTWFrZWZp
bGUJMjAwMi0xMS0yMCAxNzowNzo0Ny4wMDAwMDAwMDAgKzAxMDAKQEAgLTI1LDcgKzI1LDcgQEAg
aW5jbHVkZSAkKFRPUERJUikvY29uZmlnLm1rCiAKIExJQgk9IGxpYiQoQk9BUkQpLmEKIAotT0JK
Uwk9ICQoQk9BUkQpLm8gZmxhc2gubworT0JKUwk9ICQoQk9BUkQpLm8gZmxhc2gubyBlY2N4Lm8K
IAogJChMSUIpOgkuZGVwZW5kICQoT0JKUykKIAkkKEFSKSBjcnYgJEAgJF4KZGlmZiAtcHVyTiBw
cGNib290LTIuMC4wLWN2cy9ib2FyZC9SUFhDbGFzc2ljL2VjY3guYyBwcGNib290LTIuMC4wLWxj
ZC9ib2FyZC9SUFhDbGFzc2ljL2VjY3guYwotLS0gcHBjYm9vdC0yLjAuMC1jdnMvYm9hcmQvUlBY
Q2xhc3NpYy9lY2N4LmMJMTk3MC0wMS0wMSAwMTowMDowMC4wMDAwMDAwMDAgKzAxMDAKKysrIHBw
Y2Jvb3QtMi4wLjAtbGNkL2JvYXJkL1JQWENsYXNzaWMvZWNjeC5jCTIwMDItMTEtMjAgMTc6MDc6
NDcuMDAwMDAwMDAwICswMTAwCkBAIC0wLDAgKzEsMzUzIEBACisvKgorICogKEMpIENvcHlyaWdo
dCAyMDAyCisgKiBTdOR1YmxpIEZhdmVyZ2VzIC0gPHd3dy5zdGF1YmxpLmNvbT4KKyAqIFBpZXJy
ZSBBVUJFUlQgIHAuYXViZXJ0QHN0YXVibGkuY29tCisgKgorICogU2VlIGZpbGUgQ1JFRElUUyBm
b3IgbGlzdCBvZiBwZW9wbGUgd2hvIGNvbnRyaWJ1dGVkIHRvIHRoaXMKKyAqIHByb2plY3QuCisg
KgorICogVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRl
IGl0IGFuZC9vcgorICogbW9kaWZ5IGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVy
YWwgUHVibGljIExpY2Vuc2UgYXMKKyAqIHB1Ymxpc2hlZCBieSB0aGUgRnJlZSBTb2Z0d2FyZSBG
b3VuZGF0aW9uOyBlaXRoZXIgdmVyc2lvbiAyIG9mCisgKiB0aGUgTGljZW5zZSwgb3IgKGF0IHlv
dXIgb3B0aW9uKSBhbnkgbGF0ZXIgdmVyc2lvbi4KKyAqCisgKiBUaGlzIHByb2dyYW0gaXMgZGlz
dHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwKKyAqIGJ1dCBXSVRI
T1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mCisg
KiBNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuICBT
ZWUgdGhlCisgKiBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBkZXRhaWxzLgor
ICoKKyAqIFlvdSBzaG91bGQgaGF2ZSByZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5lcmFs
IFB1YmxpYyBMaWNlbnNlCisgKiBhbG9uZyB3aXRoIHRoaXMgcHJvZ3JhbTsgaWYgbm90LCB3cml0
ZSB0byB0aGUgRnJlZSBTb2Z0d2FyZQorICogRm91bmRhdGlvbiwgSW5jLiwgNTkgVGVtcGxlIFBs
YWNlLCBTdWl0ZSAzMzAsIEJvc3RvbiwKKyAqIE1BIDAyMTExLTEzMDcgVVNBCisgKi8KKy8qIFZp
ZGVvIHN1cHBvcnQgZm9yIHRoZSBFQ0NYIGRhdWdodGVyIGJvYXJkICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgKi8KKworCisjaW5jbHVkZSA8Y29tbW9uLmg+CisjaW5jbHVkZSA8Y29u
ZmlnLmg+CisKKyNpZmRlZiBDT05GSUdfVklERU9fU0VEMTM4MDYKKyNpbmNsdWRlIDxzZWQxMzgw
Ni5oPgorCisKKworLyogU2NyZWVuIGNvbmZpZ3VyYXRpb25zOiB0aGUgaW5pdGlhbGl6YXRpb24g
b2YgdGhlIFNEMTM4MDYgZGVwZW5kcyBvbgorICAgc2NyZWVuIGFuZCBvbiBkaXNwbGF5IG1vZGUu
IFdlIGhhbmRsZSBvbmx5IDhicHAgYW5kIDE2IGJwcCBtb2RlcyAgICAgICAgICAqLworCisvKiBF
Q0NYIGJvYXJkIGlzIHN1cHBsaWVkIHdpdGggYSBORUMgTkw2NDQ4QkMyMCBzY3JlZW4gICAgICAg
ICAgICAgICAgICAgICAgICovCisjaWZkZWYgQ09ORklHX05FQ19OTDY0NDhCQzIwCisjZGVmaW5l
IERJU1BMQVlfV0lEVEggICA2NDAKKyNkZWZpbmUgRElTUExBWV9IRUlHSFQgIDQ4MAorCisjaWZk
ZWYgQ09ORklHX1ZJREVPX1NFRDEzODA2XzhCUFAKK3N0YXRpYyBjb25zdCBTMURfUkVHUyBpbml0
X3JlZ3MgW10gPSAKK3sKKyAgICB7MHgwMDAxLDB4MDB9LCAgIC8vIE1pc2NlbGxhbmVvdXMgUmVn
aXN0ZXIKKyAgICB7MHgwMUZDLDB4MDB9LCAgIC8vIERpc3BsYXkgTW9kZSBSZWdpc3RlcgorICAg
IHsweDAwMDQsMHgxYn0sICAgLy8gR2VuZXJhbCBJTyBQaW5zIENvbmZpZ3VyYXRpb24gUmVnaXN0
ZXIgMAorICAgIHsweDAwMDUsMHgwMH0sICAgLy8gR2VuZXJhbCBJTyBQaW5zIENvbmZpZ3VyYXRp
b24gUmVnaXN0ZXIgMQorICAgIHsweDAwMDgsMHhlNX0sICAgLy8gR2VuZXJhbCBJTyBQaW5zIENv
bnRyb2wgUmVnaXN0ZXIgMAorICAgIHsweDAwMDksMHgxZn0sICAgLy8gR2VuZXJhbCBJTyBQaW5z
IENvbnRyb2wgUmVnaXN0ZXIgMQorICAgIHsweDAwMTAsMHgwMn0sICAgLy8gTWVtb3J5IENsb2Nr
IENvbmZpZ3VyYXRpb24gUmVnaXN0ZXIKKyAgICB7MHgwMDE0LDB4MTB9LCAgIC8vIExDRCBQaXhl
bCBDbG9jayBDb25maWd1cmF0aW9uIFJlZ2lzdGVyCisgICAgezB4MDAxOCwweDAyfSwgICAvLyBD
UlQvVFYgUGl4ZWwgQ2xvY2sgQ29uZmlndXJhdGlvbiBSZWdpc3RlcgorICAgIHsweDAwMUMsMHgw
Mn0sICAgLy8gTWVkaWFQbHVnIENsb2NrIENvbmZpZ3VyYXRpb24gUmVnaXN0ZXIKKyAgICB7MHgw
MDFFLDB4MDF9LCAgIC8vIENQVSBUbyBNZW1vcnkgV2FpdCBTdGF0ZSBTZWxlY3QgUmVnaXN0ZXIK
KyAgICB7MHgwMDIxLDB4MDR9LCAgIC8vIERSQU0gUmVmcmVzaCBSYXRlIFJlZ2lzdGVyCisgICAg
ezB4MDAyQSwweDAwfSwgICAvLyBEUkFNIFRpbWluZ3MgQ29udHJvbCBSZWdpc3RlciAwCisgICAg
ezB4MDAyQiwweDAxfSwgICAvLyBEUkFNIFRpbWluZ3MgQ29udHJvbCBSZWdpc3RlciAxCisgICAg
ezB4MDAyMCwweDgwfSwgICAvLyBNZW1vcnkgQ29uZmlndXJhdGlvbiBSZWdpc3RlcgorICAgIHsw
eDAwMzAsMHgyNX0sICAgLy8gUGFuZWwgVHlwZSBSZWdpc3RlcgorICAgIHsweDAwMzEsMHgwMH0s
ICAgLy8gTU9EIFJhdGUgUmVnaXN0ZXIKKyAgICB7MHgwMDMyLDB4NEZ9LCAgIC8vIExDRCBIb3Jp
em9udGFsIERpc3BsYXkgV2lkdGggUmVnaXN0ZXIKKyAgICB7MHgwMDM0LDB4MTN9LCAgIC8vIExD
RCBIb3Jpem9udGFsIE5vbi1EaXNwbGF5IFBlcmlvZCBSZWdpc3RlcgorICAgIHsweDAwMzUsMHgw
MX0sICAgLy8gVEZUIEZQTElORSBTdGFydCBQb3NpdGlvbiBSZWdpc3RlcgorICAgIHsweDAwMzYs
MHgwQn0sICAgLy8gVEZUIEZQTElORSBQdWxzZSBXaWR0aCBSZWdpc3RlcgorICAgIHsweDAwMzgs
MHhERn0sICAgLy8gTENEIFZlcnRpY2FsIERpc3BsYXkgSGVpZ2h0IFJlZ2lzdGVyIDAKKyAgICB7
MHgwMDM5LDB4MDF9LCAgIC8vIExDRCBWZXJ0aWNhbCBEaXNwbGF5IEhlaWdodCBSZWdpc3RlciAx
CisgICAgezB4MDAzQSwweDJDfSwgICAvLyBMQ0QgVmVydGljYWwgTm9uLURpc3BsYXkgUGVyaW9k
IFJlZ2lzdGVyCisgICAgezB4MDAzQiwweDAwfSwgICAvLyBURlQgRlBGUkFNRSBTdGFydCBQb3Np
dGlvbiBSZWdpc3RlcgorICAgIHsweDAwM0MsMHgwMX0sICAgLy8gVEZUIEZQRlJBTUUgUHVsc2Ug
V2lkdGggUmVnaXN0ZXIKKyAgICB7MHgwMDQwLDB4MDN9LCAgIC8vIExDRCBEaXNwbGF5IE1vZGUg
UmVnaXN0ZXIKKyAgICB7MHgwMDQxLDB4MDJ9LCAgIC8vIExDRCBNaXNjZWxsYW5lb3VzIFJlZ2lz
dGVyCisgICAgezB4MDA0MiwweDAwfSwgICAvLyBMQ0QgRGlzcGxheSBTdGFydCBBZGRyZXNzIFJl
Z2lzdGVyIDAKKyAgICB7MHgwMDQzLDB4MDB9LCAgIC8vIExDRCBEaXNwbGF5IFN0YXJ0IEFkZHJl
c3MgUmVnaXN0ZXIgMQorICAgIHsweDAwNDQsMHgwMH0sICAgLy8gTENEIERpc3BsYXkgU3RhcnQg
QWRkcmVzcyBSZWdpc3RlciAyCisgICAgezB4MDA0NiwweDQwfSwgICAvLyBMQ0QgTWVtb3J5IEFk
ZHJlc3MgT2Zmc2V0IFJlZ2lzdGVyIDAKKyAgICB7MHgwMDQ3LDB4MDF9LCAgIC8vIExDRCBNZW1v
cnkgQWRkcmVzcyBPZmZzZXQgUmVnaXN0ZXIgMQorICAgIHsweDAwNDgsMHgwMH0sICAgLy8gTENE
IFBpeGVsIFBhbm5pbmcgUmVnaXN0ZXIKKyAgICB7MHgwMDRBLDB4MDB9LCAgIC8vIExDRCBEaXNw
bGF5IEZJRk8gSGlnaCBUaHJlc2hvbGQgQ29udHJvbCBSZWdpc3RlcgorICAgIHsweDAwNEIsMHgw
MH0sICAgLy8gTENEIERpc3BsYXkgRklGTyBMb3cgVGhyZXNob2xkIENvbnRyb2wgUmVnaXN0ZXIK
KyAgICB7MHgwMDUwLDB4NEZ9LCAgIC8vIENSVC9UViBIb3Jpem9udGFsIERpc3BsYXkgV2lkdGgg
UmVnaXN0ZXIKKyAgICB7MHgwMDUyLDB4MTN9LCAgIC8vIENSVC9UViBIb3Jpem9udGFsIE5vbi1E
aXNwbGF5IFBlcmlvZCBSZWdpc3RlcgorICAgIHsweDAwNTMsMHgwMX0sICAgLy8gQ1JUL1RWIEhS
VEMgU3RhcnQgUG9zaXRpb24gUmVnaXN0ZXIKKyAgICB7MHgwMDU0LDB4MEJ9LCAgIC8vIENSVC9U
ViBIUlRDIFB1bHNlIFdpZHRoIFJlZ2lzdGVyCisgICAgezB4MDA1NiwweERGfSwgICAvLyBDUlQv
VFYgVmVydGljYWwgRGlzcGxheSBIZWlnaHQgUmVnaXN0ZXIgMAorICAgIHsweDAwNTcsMHgwMX0s
ICAgLy8gQ1JUL1RWIFZlcnRpY2FsIERpc3BsYXkgSGVpZ2h0IFJlZ2lzdGVyIDEKKyAgICB7MHgw
MDU4LDB4MkJ9LCAgIC8vIENSVC9UViBWZXJ0aWNhbCBOb24tRGlzcGxheSBQZXJpb2QgUmVnaXN0
ZXIKKyAgICB7MHgwMDU5LDB4MDl9LCAgIC8vIENSVC9UViBWUlRDIFN0YXJ0IFBvc2l0aW9uIFJl
Z2lzdGVyCisgICAgezB4MDA1QSwweDAxfSwgICAvLyBDUlQvVFYgVlJUQyBQdWxzZSBXaWR0aCBS
ZWdpc3RlcgorICAgIHsweDAwNUIsMHgwMH0sICAgLy8gVFYgT3V0cHV0IENvbnRyb2wgUmVnaXN0
ZXIKKyAgICB7MHgwMDYwLDB4MDN9LCAgIC8vIENSVC9UViBEaXNwbGF5IE1vZGUgUmVnaXN0ZXIK
KyAgICB7MHgwMDYyLDB4MDB9LCAgIC8vIENSVC9UViBEaXNwbGF5IFN0YXJ0IEFkZHJlc3MgUmVn
aXN0ZXIgMAorICAgIHsweDAwNjMsMHgwMH0sICAgLy8gQ1JUL1RWIERpc3BsYXkgU3RhcnQgQWRk
cmVzcyBSZWdpc3RlciAxCisgICAgezB4MDA2NCwweDAwfSwgICAvLyBDUlQvVFYgRGlzcGxheSBT
dGFydCBBZGRyZXNzIFJlZ2lzdGVyIDIKKyAgICB7MHgwMDY2LDB4NDB9LCAgIC8vIENSVC9UViBN
ZW1vcnkgQWRkcmVzcyBPZmZzZXQgUmVnaXN0ZXIgMAorICAgIHsweDAwNjcsMHgwMX0sICAgLy8g
Q1JUL1RWIE1lbW9yeSBBZGRyZXNzIE9mZnNldCBSZWdpc3RlciAxCisgICAgezB4MDA2OCwweDAw
fSwgICAvLyBDUlQvVFYgUGl4ZWwgUGFubmluZyBSZWdpc3RlcgorICAgIHsweDAwNkEsMHgwMH0s
ICAgLy8gQ1JUL1RWIERpc3BsYXkgRklGTyBIaWdoIFRocmVzaG9sZCBDb250cm9sIFJlZ2lzdGVy
CisgICAgezB4MDA2QiwweDAwfSwgICAvLyBDUlQvVFYgRGlzcGxheSBGSUZPIExvdyBUaHJlc2hv
bGQgQ29udHJvbCBSZWdpc3RlcgorICAgIHsweDAwNzAsMHgwMH0sICAgLy8gTENEIEluay9DdXJz
b3IgQ29udHJvbCBSZWdpc3RlcgorICAgIHsweDAwNzEsMHgwMH0sICAgLy8gTENEIEluay9DdXJz
b3IgU3RhcnQgQWRkcmVzcyBSZWdpc3RlcgorICAgIHsweDAwNzIsMHgwMH0sICAgLy8gTENEIEN1
cnNvciBYIFBvc2l0aW9uIFJlZ2lzdGVyIDAKKyAgICB7MHgwMDczLDB4MDB9LCAgIC8vIExDRCBD
dXJzb3IgWCBQb3NpdGlvbiBSZWdpc3RlciAxCisgICAgezB4MDA3NCwweDAwfSwgICAvLyBMQ0Qg
Q3Vyc29yIFkgUG9zaXRpb24gUmVnaXN0ZXIgMAorICAgIHsweDAwNzUsMHgwMH0sICAgLy8gTENE
IEN1cnNvciBZIFBvc2l0aW9uIFJlZ2lzdGVyIDEKKyAgICB7MHgwMDc2LDB4MDB9LCAgIC8vIExD
RCBJbmsvQ3Vyc29yIEJsdWUgQ29sb3IgMCBSZWdpc3RlcgorICAgIHsweDAwNzcsMHgwMH0sICAg
Ly8gTENEIEluay9DdXJzb3IgR3JlZW4gQ29sb3IgMCBSZWdpc3RlcgorICAgIHsweDAwNzgsMHgw
MH0sICAgLy8gTENEIEluay9DdXJzb3IgUmVkIENvbG9yIDAgUmVnaXN0ZXIKKyAgICB7MHgwMDdB
LDB4MUZ9LCAgIC8vIExDRCBJbmsvQ3Vyc29yIEJsdWUgQ29sb3IgMSBSZWdpc3RlcgorICAgIHsw
eDAwN0IsMHgzRn0sICAgLy8gTENEIEluay9DdXJzb3IgR3JlZW4gQ29sb3IgMSBSZWdpc3Rlcgor
ICAgIHsweDAwN0MsMHgxRn0sICAgLy8gTENEIEluay9DdXJzb3IgUmVkIENvbG9yIDEgUmVnaXN0
ZXIKKyAgICB7MHgwMDdFLDB4MDB9LCAgIC8vIExDRCBJbmsvQ3Vyc29yIEZJRk8gVGhyZXNob2xk
IFJlZ2lzdGVyCisgICAgezB4MDA4MCwweDAwfSwgICAvLyBDUlQvVFYgSW5rL0N1cnNvciBDb250
cm9sIFJlZ2lzdGVyCisgICAgezB4MDA4MSwweDAwfSwgICAvLyBDUlQvVFYgSW5rL0N1cnNvciBT
dGFydCBBZGRyZXNzIFJlZ2lzdGVyCisgICAgezB4MDA4MiwweDAwfSwgICAvLyBDUlQvVFYgQ3Vy
c29yIFggUG9zaXRpb24gUmVnaXN0ZXIgMAorICAgIHsweDAwODMsMHgwMH0sICAgLy8gQ1JUL1RW
IEN1cnNvciBYIFBvc2l0aW9uIFJlZ2lzdGVyIDEKKyAgICB7MHgwMDg0LDB4MDB9LCAgIC8vIENS
VC9UViBDdXJzb3IgWSBQb3NpdGlvbiBSZWdpc3RlciAwCisgICAgezB4MDA4NSwweDAwfSwgICAv
LyBDUlQvVFYgQ3Vyc29yIFkgUG9zaXRpb24gUmVnaXN0ZXIgMQorICAgIHsweDAwODYsMHgwMH0s
ICAgLy8gQ1JUL1RWIEluay9DdXJzb3IgQmx1ZSBDb2xvciAwIFJlZ2lzdGVyCisgICAgezB4MDA4
NywweDAwfSwgICAvLyBDUlQvVFYgSW5rL0N1cnNvciBHcmVlbiBDb2xvciAwIFJlZ2lzdGVyCisg
ICAgezB4MDA4OCwweDAwfSwgICAvLyBDUlQvVFYgSW5rL0N1cnNvciBSZWQgQ29sb3IgMCBSZWdp
c3RlcgorICAgIHsweDAwOEEsMHgxRn0sICAgLy8gQ1JUL1RWIEluay9DdXJzb3IgQmx1ZSBDb2xv
ciAxIFJlZ2lzdGVyCisgICAgezB4MDA4QiwweDNGfSwgICAvLyBDUlQvVFYgSW5rL0N1cnNvciBH
cmVlbiBDb2xvciAxIFJlZ2lzdGVyCisgICAgezB4MDA4QywweDFGfSwgICAvLyBDUlQvVFYgSW5r
L0N1cnNvciBSZWQgQ29sb3IgMSBSZWdpc3RlcgorICAgIHsweDAwOEUsMHgwMH0sICAgLy8gQ1JU
L1RWIEluay9DdXJzb3IgRklGTyBUaHJlc2hvbGQgUmVnaXN0ZXIKKyAgICB7MHgwMTAwLDB4MDB9
LCAgIC8vIEJpdEJsdCBDb250cm9sIFJlZ2lzdGVyIDAKKyAgICB7MHgwMTAxLDB4MDB9LCAgIC8v
IEJpdEJsdCBDb250cm9sIFJlZ2lzdGVyIDEKKyAgICB7MHgwMTAyLDB4MDB9LCAgIC8vIEJpdEJs
dCBST1AgQ29kZS9Db2xvciBFeHBhbnNpb24gUmVnaXN0ZXIKKyAgICB7MHgwMTAzLDB4MDB9LCAg
IC8vIEJpdEJsdCBPcGVyYXRpb24gUmVnaXN0ZXIKKyAgICB7MHgwMTA0LDB4MDB9LCAgIC8vIEJp
dEJsdCBTb3VyY2UgU3RhcnQgQWRkcmVzcyBSZWdpc3RlciAwCisgICAgezB4MDEwNSwweDAwfSwg
ICAvLyBCaXRCbHQgU291cmNlIFN0YXJ0IEFkZHJlc3MgUmVnaXN0ZXIgMQorICAgIHsweDAxMDYs
MHgwMH0sICAgLy8gQml0Qmx0IFNvdXJjZSBTdGFydCBBZGRyZXNzIFJlZ2lzdGVyIDIKKyAgICB7
MHgwMTA4LDB4MDB9LCAgIC8vIEJpdEJsdCBEZXN0aW5hdGlvbiBTdGFydCBBZGRyZXNzIFJlZ2lz
dGVyIDAKKyAgICB7MHgwMTA5LDB4MDB9LCAgIC8vIEJpdEJsdCBEZXN0aW5hdGlvbiBTdGFydCBB
ZGRyZXNzIFJlZ2lzdGVyIDEKKyAgICB7MHgwMTBBLDB4MDB9LCAgIC8vIEJpdEJsdCBEZXN0aW5h
dGlvbiBTdGFydCBBZGRyZXNzIFJlZ2lzdGVyIDIKKyAgICB7MHgwMTBDLDB4MDB9LCAgIC8vIEJp
dEJsdCBNZW1vcnkgQWRkcmVzcyBPZmZzZXQgUmVnaXN0ZXIgMAorICAgIHsweDAxMEQsMHgwMH0s
ICAgLy8gQml0Qmx0IE1lbW9yeSBBZGRyZXNzIE9mZnNldCBSZWdpc3RlciAxCisgICAgezB4MDEx
MCwweDAwfSwgICAvLyBCaXRCbHQgV2lkdGggUmVnaXN0ZXIgMAorICAgIHsweDAxMTEsMHgwMH0s
ICAgLy8gQml0Qmx0IFdpZHRoIFJlZ2lzdGVyIDEKKyAgICB7MHgwMTEyLDB4MDB9LCAgIC8vIEJp
dEJsdCBIZWlnaHQgUmVnaXN0ZXIgMAorICAgIHsweDAxMTMsMHgwMH0sICAgLy8gQml0Qmx0IEhl
aWdodCBSZWdpc3RlciAxCisgICAgezB4MDExNCwweDAwfSwgICAvLyBCaXRCbHQgQmFja2dyb3Vu
ZCBDb2xvciBSZWdpc3RlciAwCisgICAgezB4MDExNSwweDAwfSwgICAvLyBCaXRCbHQgQmFja2dy
b3VuZCBDb2xvciBSZWdpc3RlciAxCisgICAgezB4MDExOCwweDAwfSwgICAvLyBCaXRCbHQgRm9y
ZWdyb3VuZCBDb2xvciBSZWdpc3RlciAwCisgICAgezB4MDExOSwweDAwfSwgICAvLyBCaXRCbHQg
Rm9yZWdyb3VuZCBDb2xvciBSZWdpc3RlciAxCisgICAgezB4MDFFMCwweDAwfSwgICAvLyBMb29r
LVVwIFRhYmxlIE1vZGUgUmVnaXN0ZXIKKyAgICB7MHgwMUUyLDB4MDB9LCAgIC8vIExvb2stVXAg
VGFibGUgQWRkcmVzcyBSZWdpc3RlcgorICAgIHsweDAxRTQsMHgwMH0sICAgLy8gTG9vay1VcCBU
YWJsZSBEYXRhIFJlZ2lzdGVyCisgICAgezB4MDFGMCwweDEwfSwgICAvLyBQb3dlciBTYXZlIENv
bmZpZ3VyYXRpb24gUmVnaXN0ZXIKKyAgICB7MHgwMUYxLDB4MDB9LCAgIC8vIFBvd2VyIFNhdmUg
U3RhdHVzIFJlZ2lzdGVyCisgICAgezB4MDFGNCwweDAwfSwgICAvLyBDUFUtdG8tTWVtb3J5IEFj
Y2VzcyBXYXRjaGRvZyBUaW1lciBSZWdpc3RlcgorICAgIHsweDAxRkMsMHgwMX0sICAgLy8gRGlz
cGxheSBNb2RlIFJlZ2lzdGVyCisgICAgezAsIDB9Cit9OworI2VuZGlmIC8qIENPTkZJR19WSURF
T19TRUQxMzgwNl84QlBQICovCisKKyNpZmRlZiBDT05GSUdfVklERU9fU0VEMTM4MDZfMTZCUFAK
Kworc3RhdGljIGNvbnN0IFMxRF9SRUdTIGluaXRfcmVncyBbXSA9IAoreworICAgIHsweDAwMDEs
MHgwMH0sICAgLy8gTWlzY2VsbGFuZW91cyBSZWdpc3RlcgorICAgIHsweDAxRkMsMHgwMH0sICAg
Ly8gRGlzcGxheSBNb2RlIFJlZ2lzdGVyCisgICAgezB4MDAwNCwweDFifSwgICAvLyBHZW5lcmFs
IElPIFBpbnMgQ29uZmlndXJhdGlvbiBSZWdpc3RlciAwCisgICAgezB4MDAwNSwweDAwfSwgICAv
LyBHZW5lcmFsIElPIFBpbnMgQ29uZmlndXJhdGlvbiBSZWdpc3RlciAxCisgICAgezB4MDAwOCww
eGU1fSwgICAvLyBHZW5lcmFsIElPIFBpbnMgQ29udHJvbCBSZWdpc3RlciAwCisgICAgezB4MDAw
OSwweDFmfSwgICAvLyBHZW5lcmFsIElPIFBpbnMgQ29udHJvbCBSZWdpc3RlciAxCisgICAgezB4
MDAxMCwweDAyfSwgICAvLyBNZW1vcnkgQ2xvY2sgQ29uZmlndXJhdGlvbiBSZWdpc3RlcgorICAg
IHsweDAwMTQsMHgxMH0sICAgLy8gTENEIFBpeGVsIENsb2NrIENvbmZpZ3VyYXRpb24gUmVnaXN0
ZXIKKyAgICB7MHgwMDE4LDB4MDJ9LCAgIC8vIENSVC9UViBQaXhlbCBDbG9jayBDb25maWd1cmF0
aW9uIFJlZ2lzdGVyCisgICAgezB4MDAxQywweDAyfSwgICAvLyBNZWRpYVBsdWcgQ2xvY2sgQ29u
ZmlndXJhdGlvbiBSZWdpc3RlcgorICAgIHsweDAwMUUsMHgwMX0sICAgLy8gQ1BVIFRvIE1lbW9y
eSBXYWl0IFN0YXRlIFNlbGVjdCBSZWdpc3RlcgorICAgIHsweDAwMjEsMHgwNH0sICAgLy8gRFJB
TSBSZWZyZXNoIFJhdGUgUmVnaXN0ZXIKKyAgICB7MHgwMDJBLDB4MDB9LCAgIC8vIERSQU0gVGlt
aW5ncyBDb250cm9sIFJlZ2lzdGVyIDAKKyAgICB7MHgwMDJCLDB4MDF9LCAgIC8vIERSQU0gVGlt
aW5ncyBDb250cm9sIFJlZ2lzdGVyIDEKKyAgICB7MHgwMDIwLDB4ODB9LCAgIC8vIE1lbW9yeSBD
b25maWd1cmF0aW9uIFJlZ2lzdGVyCisgICAgezB4MDAzMCwweDI1fSwgICAvLyBQYW5lbCBUeXBl
IFJlZ2lzdGVyCisgICAgezB4MDAzMSwweDAwfSwgICAvLyBNT0QgUmF0ZSBSZWdpc3RlcgorICAg
IHsweDAwMzIsMHg0Rn0sICAgLy8gTENEIEhvcml6b250YWwgRGlzcGxheSBXaWR0aCBSZWdpc3Rl
cgorICAgIHsweDAwMzQsMHgxM30sICAgLy8gTENEIEhvcml6b250YWwgTm9uLURpc3BsYXkgUGVy
aW9kIFJlZ2lzdGVyCisgICAgezB4MDAzNSwweDAxfSwgICAvLyBURlQgRlBMSU5FIFN0YXJ0IFBv
c2l0aW9uIFJlZ2lzdGVyCisgICAgezB4MDAzNiwweDBCfSwgICAvLyBURlQgRlBMSU5FIFB1bHNl
IFdpZHRoIFJlZ2lzdGVyCisgICAgezB4MDAzOCwweERGfSwgICAvLyBMQ0QgVmVydGljYWwgRGlz
cGxheSBIZWlnaHQgUmVnaXN0ZXIgMAorICAgIHsweDAwMzksMHgwMX0sICAgLy8gTENEIFZlcnRp
Y2FsIERpc3BsYXkgSGVpZ2h0IFJlZ2lzdGVyIDEKKyAgICB7MHgwMDNBLDB4MkN9LCAgIC8vIExD
RCBWZXJ0aWNhbCBOb24tRGlzcGxheSBQZXJpb2QgUmVnaXN0ZXIKKyAgICB7MHgwMDNCLDB4MDB9
LCAgIC8vIFRGVCBGUEZSQU1FIFN0YXJ0IFBvc2l0aW9uIFJlZ2lzdGVyCisgICAgezB4MDAzQyww
eDAxfSwgICAvLyBURlQgRlBGUkFNRSBQdWxzZSBXaWR0aCBSZWdpc3RlcgorICAgIHsweDAwNDAs
MHgwNX0sICAgLy8gTENEIERpc3BsYXkgTW9kZSBSZWdpc3RlcgorICAgIHsweDAwNDEsMHgwMn0s
ICAgLy8gTENEIE1pc2NlbGxhbmVvdXMgUmVnaXN0ZXIKKyAgICB7MHgwMDQyLDB4MDB9LCAgIC8v
IExDRCBEaXNwbGF5IFN0YXJ0IEFkZHJlc3MgUmVnaXN0ZXIgMAorICAgIHsweDAwNDMsMHgwMH0s
ICAgLy8gTENEIERpc3BsYXkgU3RhcnQgQWRkcmVzcyBSZWdpc3RlciAxCisgICAgezB4MDA0NCww
eDAwfSwgICAvLyBMQ0QgRGlzcGxheSBTdGFydCBBZGRyZXNzIFJlZ2lzdGVyIDIKKyAgICB7MHgw
MDQ2LDB4ODB9LCAgIC8vIExDRCBNZW1vcnkgQWRkcmVzcyBPZmZzZXQgUmVnaXN0ZXIgMAorICAg
IHsweDAwNDcsMHgwMn0sICAgLy8gTENEIE1lbW9yeSBBZGRyZXNzIE9mZnNldCBSZWdpc3RlciAx
CisgICAgezB4MDA0OCwweDAwfSwgICAvLyBMQ0QgUGl4ZWwgUGFubmluZyBSZWdpc3RlcgorICAg
IHsweDAwNEEsMHgwMH0sICAgLy8gTENEIERpc3BsYXkgRklGTyBIaWdoIFRocmVzaG9sZCBDb250
cm9sIFJlZ2lzdGVyCisgICAgezB4MDA0QiwweDAwfSwgICAvLyBMQ0QgRGlzcGxheSBGSUZPIExv
dyBUaHJlc2hvbGQgQ29udHJvbCBSZWdpc3RlcgorICAgIHsweDAwNTAsMHg0Rn0sICAgLy8gQ1JU
L1RWIEhvcml6b250YWwgRGlzcGxheSBXaWR0aCBSZWdpc3RlcgorICAgIHsweDAwNTIsMHgxM30s
ICAgLy8gQ1JUL1RWIEhvcml6b250YWwgTm9uLURpc3BsYXkgUGVyaW9kIFJlZ2lzdGVyCisgICAg
ezB4MDA1MywweDAxfSwgICAvLyBDUlQvVFYgSFJUQyBTdGFydCBQb3NpdGlvbiBSZWdpc3Rlcgor
ICAgIHsweDAwNTQsMHgwQn0sICAgLy8gQ1JUL1RWIEhSVEMgUHVsc2UgV2lkdGggUmVnaXN0ZXIK
KyAgICB7MHgwMDU2LDB4REZ9LCAgIC8vIENSVC9UViBWZXJ0aWNhbCBEaXNwbGF5IEhlaWdodCBS
ZWdpc3RlciAwCisgICAgezB4MDA1NywweDAxfSwgICAvLyBDUlQvVFYgVmVydGljYWwgRGlzcGxh
eSBIZWlnaHQgUmVnaXN0ZXIgMQorICAgIHsweDAwNTgsMHgyQn0sICAgLy8gQ1JUL1RWIFZlcnRp
Y2FsIE5vbi1EaXNwbGF5IFBlcmlvZCBSZWdpc3RlcgorICAgIHsweDAwNTksMHgwOX0sICAgLy8g
Q1JUL1RWIFZSVEMgU3RhcnQgUG9zaXRpb24gUmVnaXN0ZXIKKyAgICB7MHgwMDVBLDB4MDF9LCAg
IC8vIENSVC9UViBWUlRDIFB1bHNlIFdpZHRoIFJlZ2lzdGVyCisgICAgezB4MDA1QiwweDAwfSwg
ICAvLyBUViBPdXRwdXQgQ29udHJvbCBSZWdpc3RlcgorICAgIHsweDAwNjAsMHgwNX0sICAgLy8g
Q1JUL1RWIERpc3BsYXkgTW9kZSBSZWdpc3RlcgorICAgIHsweDAwNjIsMHgwMH0sICAgLy8gQ1JU
L1RWIERpc3BsYXkgU3RhcnQgQWRkcmVzcyBSZWdpc3RlciAwCisgICAgezB4MDA2MywweDAwfSwg
ICAvLyBDUlQvVFYgRGlzcGxheSBTdGFydCBBZGRyZXNzIFJlZ2lzdGVyIDEKKyAgICB7MHgwMDY0
LDB4MDB9LCAgIC8vIENSVC9UViBEaXNwbGF5IFN0YXJ0IEFkZHJlc3MgUmVnaXN0ZXIgMgorICAg
IHsweDAwNjYsMHg4MH0sICAgLy8gQ1JUL1RWIE1lbW9yeSBBZGRyZXNzIE9mZnNldCBSZWdpc3Rl
ciAwCisgICAgezB4MDA2NywweDAyfSwgICAvLyBDUlQvVFYgTWVtb3J5IEFkZHJlc3MgT2Zmc2V0
IFJlZ2lzdGVyIDEKKyAgICB7MHgwMDY4LDB4MDB9LCAgIC8vIENSVC9UViBQaXhlbCBQYW5uaW5n
IFJlZ2lzdGVyCisgICAgezB4MDA2QSwweDAwfSwgICAvLyBDUlQvVFYgRGlzcGxheSBGSUZPIEhp
Z2ggVGhyZXNob2xkIENvbnRyb2wgUmVnaXN0ZXIKKyAgICB7MHgwMDZCLDB4MDB9LCAgIC8vIENS
VC9UViBEaXNwbGF5IEZJRk8gTG93IFRocmVzaG9sZCBDb250cm9sIFJlZ2lzdGVyCisgICAgezB4
MDA3MCwweDAwfSwgICAvLyBMQ0QgSW5rL0N1cnNvciBDb250cm9sIFJlZ2lzdGVyCisgICAgezB4
MDA3MSwweDAwfSwgICAvLyBMQ0QgSW5rL0N1cnNvciBTdGFydCBBZGRyZXNzIFJlZ2lzdGVyCisg
ICAgezB4MDA3MiwweDAwfSwgICAvLyBMQ0QgQ3Vyc29yIFggUG9zaXRpb24gUmVnaXN0ZXIgMAor
ICAgIHsweDAwNzMsMHgwMH0sICAgLy8gTENEIEN1cnNvciBYIFBvc2l0aW9uIFJlZ2lzdGVyIDEK
KyAgICB7MHgwMDc0LDB4MDB9LCAgIC8vIExDRCBDdXJzb3IgWSBQb3NpdGlvbiBSZWdpc3RlciAw
CisgICAgezB4MDA3NSwweDAwfSwgICAvLyBMQ0QgQ3Vyc29yIFkgUG9zaXRpb24gUmVnaXN0ZXIg
MQorICAgIHsweDAwNzYsMHgwMH0sICAgLy8gTENEIEluay9DdXJzb3IgQmx1ZSBDb2xvciAwIFJl
Z2lzdGVyCisgICAgezB4MDA3NywweDAwfSwgICAvLyBMQ0QgSW5rL0N1cnNvciBHcmVlbiBDb2xv
ciAwIFJlZ2lzdGVyCisgICAgezB4MDA3OCwweDAwfSwgICAvLyBMQ0QgSW5rL0N1cnNvciBSZWQg
Q29sb3IgMCBSZWdpc3RlcgorICAgIHsweDAwN0EsMHgxRn0sICAgLy8gTENEIEluay9DdXJzb3Ig
Qmx1ZSBDb2xvciAxIFJlZ2lzdGVyCisgICAgezB4MDA3QiwweDNGfSwgICAvLyBMQ0QgSW5rL0N1
cnNvciBHcmVlbiBDb2xvciAxIFJlZ2lzdGVyCisgICAgezB4MDA3QywweDFGfSwgICAvLyBMQ0Qg
SW5rL0N1cnNvciBSZWQgQ29sb3IgMSBSZWdpc3RlcgorICAgIHsweDAwN0UsMHgwMH0sICAgLy8g
TENEIEluay9DdXJzb3IgRklGTyBUaHJlc2hvbGQgUmVnaXN0ZXIKKyAgICB7MHgwMDgwLDB4MDB9
LCAgIC8vIENSVC9UViBJbmsvQ3Vyc29yIENvbnRyb2wgUmVnaXN0ZXIKKyAgICB7MHgwMDgxLDB4
MDB9LCAgIC8vIENSVC9UViBJbmsvQ3Vyc29yIFN0YXJ0IEFkZHJlc3MgUmVnaXN0ZXIKKyAgICB7
MHgwMDgyLDB4MDB9LCAgIC8vIENSVC9UViBDdXJzb3IgWCBQb3NpdGlvbiBSZWdpc3RlciAwCisg
ICAgezB4MDA4MywweDAwfSwgICAvLyBDUlQvVFYgQ3Vyc29yIFggUG9zaXRpb24gUmVnaXN0ZXIg
MQorICAgIHsweDAwODQsMHgwMH0sICAgLy8gQ1JUL1RWIEN1cnNvciBZIFBvc2l0aW9uIFJlZ2lz
dGVyIDAKKyAgICB7MHgwMDg1LDB4MDB9LCAgIC8vIENSVC9UViBDdXJzb3IgWSBQb3NpdGlvbiBS
ZWdpc3RlciAxCisgICAgezB4MDA4NiwweDAwfSwgICAvLyBDUlQvVFYgSW5rL0N1cnNvciBCbHVl
IENvbG9yIDAgUmVnaXN0ZXIKKyAgICB7MHgwMDg3LDB4MDB9LCAgIC8vIENSVC9UViBJbmsvQ3Vy
c29yIEdyZWVuIENvbG9yIDAgUmVnaXN0ZXIKKyAgICB7MHgwMDg4LDB4MDB9LCAgIC8vIENSVC9U
ViBJbmsvQ3Vyc29yIFJlZCBDb2xvciAwIFJlZ2lzdGVyCisgICAgezB4MDA4QSwweDFGfSwgICAv
LyBDUlQvVFYgSW5rL0N1cnNvciBCbHVlIENvbG9yIDEgUmVnaXN0ZXIKKyAgICB7MHgwMDhCLDB4
M0Z9LCAgIC8vIENSVC9UViBJbmsvQ3Vyc29yIEdyZWVuIENvbG9yIDEgUmVnaXN0ZXIKKyAgICB7
MHgwMDhDLDB4MUZ9LCAgIC8vIENSVC9UViBJbmsvQ3Vyc29yIFJlZCBDb2xvciAxIFJlZ2lzdGVy
CisgICAgezB4MDA4RSwweDAwfSwgICAvLyBDUlQvVFYgSW5rL0N1cnNvciBGSUZPIFRocmVzaG9s
ZCBSZWdpc3RlcgorICAgIHsweDAxMDAsMHgwMH0sICAgLy8gQml0Qmx0IENvbnRyb2wgUmVnaXN0
ZXIgMAorICAgIHsweDAxMDEsMHgwMH0sICAgLy8gQml0Qmx0IENvbnRyb2wgUmVnaXN0ZXIgMQor
ICAgIHsweDAxMDIsMHgwMH0sICAgLy8gQml0Qmx0IFJPUCBDb2RlL0NvbG9yIEV4cGFuc2lvbiBS
ZWdpc3RlcgorICAgIHsweDAxMDMsMHgwMH0sICAgLy8gQml0Qmx0IE9wZXJhdGlvbiBSZWdpc3Rl
cgorICAgIHsweDAxMDQsMHgwMH0sICAgLy8gQml0Qmx0IFNvdXJjZSBTdGFydCBBZGRyZXNzIFJl
Z2lzdGVyIDAKKyAgICB7MHgwMTA1LDB4MDB9LCAgIC8vIEJpdEJsdCBTb3VyY2UgU3RhcnQgQWRk
cmVzcyBSZWdpc3RlciAxCisgICAgezB4MDEwNiwweDAwfSwgICAvLyBCaXRCbHQgU291cmNlIFN0
YXJ0IEFkZHJlc3MgUmVnaXN0ZXIgMgorICAgIHsweDAxMDgsMHgwMH0sICAgLy8gQml0Qmx0IERl
c3RpbmF0aW9uIFN0YXJ0IEFkZHJlc3MgUmVnaXN0ZXIgMAorICAgIHsweDAxMDksMHgwMH0sICAg
Ly8gQml0Qmx0IERlc3RpbmF0aW9uIFN0YXJ0IEFkZHJlc3MgUmVnaXN0ZXIgMQorICAgIHsweDAx
MEEsMHgwMH0sICAgLy8gQml0Qmx0IERlc3RpbmF0aW9uIFN0YXJ0IEFkZHJlc3MgUmVnaXN0ZXIg
MgorICAgIHsweDAxMEMsMHgwMH0sICAgLy8gQml0Qmx0IE1lbW9yeSBBZGRyZXNzIE9mZnNldCBS
ZWdpc3RlciAwCisgICAgezB4MDEwRCwweDAwfSwgICAvLyBCaXRCbHQgTWVtb3J5IEFkZHJlc3Mg
T2Zmc2V0IFJlZ2lzdGVyIDEKKyAgICB7MHgwMTEwLDB4MDB9LCAgIC8vIEJpdEJsdCBXaWR0aCBS
ZWdpc3RlciAwCisgICAgezB4MDExMSwweDAwfSwgICAvLyBCaXRCbHQgV2lkdGggUmVnaXN0ZXIg
MQorICAgIHsweDAxMTIsMHgwMH0sICAgLy8gQml0Qmx0IEhlaWdodCBSZWdpc3RlciAwCisgICAg
ezB4MDExMywweDAwfSwgICAvLyBCaXRCbHQgSGVpZ2h0IFJlZ2lzdGVyIDEKKyAgICB7MHgwMTE0
LDB4MDB9LCAgIC8vIEJpdEJsdCBCYWNrZ3JvdW5kIENvbG9yIFJlZ2lzdGVyIDAKKyAgICB7MHgw
MTE1LDB4MDB9LCAgIC8vIEJpdEJsdCBCYWNrZ3JvdW5kIENvbG9yIFJlZ2lzdGVyIDEKKyAgICB7
MHgwMTE4LDB4MDB9LCAgIC8vIEJpdEJsdCBGb3JlZ3JvdW5kIENvbG9yIFJlZ2lzdGVyIDAKKyAg
ICB7MHgwMTE5LDB4MDB9LCAgIC8vIEJpdEJsdCBGb3JlZ3JvdW5kIENvbG9yIFJlZ2lzdGVyIDEK
KyAgICB7MHgwMUUwLDB4MDF9LCAgIC8vIExvb2stVXAgVGFibGUgTW9kZSBSZWdpc3RlcgorICAg
IHsweDAxRTIsMHgwMH0sICAgLy8gTG9vay1VcCBUYWJsZSBBZGRyZXNzIFJlZ2lzdGVyCisgICAg
ezB4MDFFNCwweDAwfSwgICAvLyBMb29rLVVwIFRhYmxlIERhdGEgUmVnaXN0ZXIKKyAgICB7MHgw
MUYwLDB4MTB9LCAgIC8vIFBvd2VyIFNhdmUgQ29uZmlndXJhdGlvbiBSZWdpc3RlcgorICAgIHsw
eDAxRjEsMHgwMH0sICAgLy8gUG93ZXIgU2F2ZSBTdGF0dXMgUmVnaXN0ZXIKKyAgICB7MHgwMUY0
LDB4MDB9LCAgIC8vIENQVS10by1NZW1vcnkgQWNjZXNzIFdhdGNoZG9nIFRpbWVyIFJlZ2lzdGVy
CisgICAgezB4MDFGQywweDAxfSwgICAvLyBEaXNwbGF5IE1vZGUgUmVnaXN0ZXIKKyAgICB7MCwg
MH0KK307CisKKyNlbmRpZiAvKiBDT05GSUdfVklERU9fU0VEMTM4MDZfMTZCUFAgKi8KKyNlbmRp
ZiAvKiBDT05GSUdfTkVDX05MNjQ0OEJDMjAgKi8KKworCisKKyNpZmRlZiBDT05GSUdfQ09OU09M
RV9FWFRSQV9JTkZPCisKKy8qLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyAqIHZpZGVvX2dldF9pbmZv
X3N0ciAtLSBzZXR1cCBhIGJvYXJkIHN0cmluZzogdHlwZSwgc3BlZWQsIGV0Yy4KKyAqIGxpbmVf
bnVtYmVyPSBsb2NhdGlvbiB0byBwbGFjZSBpbmZvIHN0cmluZyBiZXNpZGUgbG9nbworICogaW5m
bz0gYnVmZmVyIGZvciBpbmZvIHN0cmluZworICotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQorICovCit2
b2lkIHZpZGVvX2dldF9pbmZvX3N0ciAoaW50IGxpbmVfbnVtYmVyLCBjaGFyICppbmZvKQorewor
ICAgIGlmIChsaW5lX251bWJlciA9PSAxKSB7CisgICAgICAgIHN0cmNweSAoaW5mbywgIiBSUFhD
bGFzc2ljIGJvYXJkIik7CisgICAgfQorICAgIGVsc2UgeworICAgICAgICBpbmZvIFswXSA9ICdc
MCc7CisgICAgfQorCit9CisjZW5kaWYKKworLyotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQorICogYm9h
cmRfdmlkZW9faW5pdCAtLSBpbml0IGRlIGwnRVBTT04sIGNvbmZpZyBkdSBDUworICotLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLQorICovCit1bnNpZ25lZCBpbnQgYm9hcmRfdmlkZW9faW5pdCAodm9pZCkK
K3sKKyAgICB2b2xhdGlsZSBpbW1hcF90ICAgICAqaW1tYXAgID0gKGltbWFwX3QgKilDRkdfSU1N
UjsKKyAgICB2b2xhdGlsZSBtZW1jdGw4eHhfdCAqbWVtY3RsID0gJmltbWFwLT5pbV9tZW1jdGw7
CisKKyAgICAvKiBQcm9ncmFtIEVDQ1ggcmVnaXN0ZXJzICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgKi8KKyAgICAqKEVDQ1hfQ1NSMTIpIHw9IEVDQ1hfODYw
OworICAgICooRUNDWF9DU1I4KSB8PSBFQ0NYX0JFIHwgRUNDWF9DUzI7CisgICAgKihFQ0NYX0NT
UjgpIHw9IEVDQ1hfRU5FUFNPTjsKKyAgICAKKyAgICBtZW1jdGwtPm1lbWNfb3IyID0gU0VEMTM4
MDZfT1I7CisgICAgbWVtY3RsLT5tZW1jX2JyMiA9IFNFRDEzODA2X1JFR19BRERSIHwgU0VEMTM4
MDZfQUNDRVM7CisKKyAgICByZXR1cm4gKFNFRDEzODA2X1JFR19BRERSKTsKK30KKworLyotLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLQorICogYm9hcmRfdmFsaWRhdGVfc2NyZWVuIC0tIAorICotLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLQorICovCit2b2lkIGJvYXJkX3ZhbGlkYXRlX3NjcmVlbiAodW5zaWduZWQg
aW50IGJhc2UpCit7CisgICAgLyogQWN0aXZhdGUgdGhlIHBhbmVsIGJpYXMgcG93ZXIgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICovCisgICAgKih2b2xhdGlsZSB1bnNp
Z25lZCBjaGFyICopKGJhc2UgKyBSRUdfR1BJT19DVFJMKSA9IDB4ODA7Cit9CisvKi0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tCisgKiBib2FyZF9nZXRfcmVncyAtLSAKKyAqLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0KKyAqLworY29uc3QgUzFEX1JFR1MgKmJvYXJkX2dldF9yZWdzICh2b2lkKQoreworICAgIHJl
dHVybiAoaW5pdF9yZWdzKTsKK30KKy8qLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyAqIGJvYXJkX2dl
dF93aWR0aCAtLSAKKyAqLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyAqLworaW50IGJvYXJkX2dldF93
aWR0aCAodm9pZCkKK3sKKyAgICByZXR1cm4gKERJU1BMQVlfV0lEVEgpOworfQorCisvKi0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tCisgKiBib2FyZF9nZXRfaGVpZ2h0IC0tIAorICotLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLQorICovCitpbnQgYm9hcmRfZ2V0X2hlaWdodCAodm9pZCkKK3sKKyAgICByZXR1cm4g
KERJU1BMQVlfSEVJR0hUKTsKK30KKworI2VuZGlmIC8qIENPTkZJR19WSURFT19TRUQxMzgwNiAq
LwpkaWZmIC1wdXJOIHBwY2Jvb3QtMi4wLjAtY3ZzL2NvbW1vbi9kZXZpY2VzLmMgcHBjYm9vdC0y
LjAuMC1sY2QvY29tbW9uL2RldmljZXMuYwotLS0gcHBjYm9vdC0yLjAuMC1jdnMvY29tbW9uL2Rl
dmljZXMuYwkyMDAyLTExLTIwIDE4OjA2OjUxLjAwMDAwMDAwMCArMDEwMAorKysgcHBjYm9vdC0y
LjAuMC1sY2QvY29tbW9uL2RldmljZXMuYwkyMDAyLTExLTIwIDE3OjA5OjExLjAwMDAwMDAwMCAr
MDEwMApAQCAtMTcyLDcgKzE3Miw3IEBAIGludCBkZXZpY2VzX2luaXQgKHZvaWQpCiAjaWZkZWYg
Q09ORklHX0xDRAogCWRydl9sY2RfaW5pdCAoKTsKICNlbmRpZgotI2lmZGVmIENPTkZJR19WSURF
TworI2lmIGRlZmluZWQoQ09ORklHX1ZJREVPKSB8fCBkZWZpbmVkKENPTkZJR19DRkJfQ09OU09M
RSkKIAlkcnZfdmlkZW9faW5pdCAoKTsKICNlbmRpZgogI2lmZGVmIENPTkZJR19XTF80UFBNX0tF
WUJPQVJECmRpZmYgLXB1ck4gcHBjYm9vdC0yLjAuMC1jdnMvZHJpdmVycy9NYWtlZmlsZSBwcGNi
b290LTIuMC4wLWxjZC9kcml2ZXJzL01ha2VmaWxlCi0tLSBwcGNib290LTIuMC4wLWN2cy9kcml2
ZXJzL01ha2VmaWxlCTIwMDItMTEtMjAgMTc6MDM6MzAuMDAwMDAwMDAwICswMTAwCisrKyBwcGNi
b290LTIuMC4wLWxjZC9kcml2ZXJzL01ha2VmaWxlCTIwMDItMTEtMjAgMTc6MDc6NTguMDAwMDAw
MDAwICswMTAwCkBAIC0zMSw3ICszMSw3IEBAIE9CSlMJPSAzYzU4OS5vIDU3MDFybHMubyBiY201
NzB4Lm8gYmNtNTcKIAkgIGNmYl9jb25zb2xlLm8gY3M4OTAwLm8gZGMyMTE0eC5vIGVlcHJvMTAw
Lm8gXAogCSAgaTgwNDIubyBuYXRzZW1pLm8gbnMxNjU1MC5vIG5zODM4MngubyBuczg3MzA4Lm8g
XAogCSAgcGNpLm8gcGNpX2F1dG8ubyBwY2lfaW5kaXJlY3QubyBcCi0JICBwY25ldC5vIHNlcmlh
bC5vIFwKKwkgIHBjbmV0Lm8gc2VkMTM4MDYubyBzZXJpYWwubyBcCiAJICBzbWM5MTExMS5vIHNt
aUx5bnhFTS5vIHN5bTUzYzh4eC5vIFwKIAkgIHRpZ29uMy5vIHc4M2M1NTNmLm8gY3Q2OTAwMC5v
CiAKZGlmZiAtcHVyTiBwcGNib290LTIuMC4wLWN2cy9kcml2ZXJzL2NmYl9jb25zb2xlLmMgcHBj
Ym9vdC0yLjAuMC1sY2QvZHJpdmVycy9jZmJfY29uc29sZS5jCi0tLSBwcGNib290LTIuMC4wLWN2
cy9kcml2ZXJzL2NmYl9jb25zb2xlLmMJMjAwMi0xMS0yMCAxNzowMzo1MS4wMDAwMDAwMDAgKzAx
MDAKKysrIHBwY2Jvb3QtMi4wLjAtbGNkL2RyaXZlcnMvY2ZiX2NvbnNvbGUuYwkyMDAyLTExLTIw
IDE3OjUwOjIwLjAwMDAwMDAwMCArMDEwMApAQCAtNjUsNiArNjUsNyBAQAogIENPTkZJR19DT05T
T0xFX1RJTUUgICAgICAgICAtIGRpc3BsYXkgdGltZS9kYXRlIGluIHVwcGVyIHJpZ2h0IGNvcm5l
ciwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBuZWVkcyBDRkdfQ01EX0RBVEUgYW5k
IENPTkZJR19DT05TT0xFX0NVUlNPUgogIENPTkZJR19WSURFT19MT0dPICAgICAgICAgICAtIGRp
c3BsYXkgTGludXggTG9nbyBpbiB1cHBlciBsZWZ0IGNvcm5lcgorIENPTkZJR19WSURFT19CTVBf
TE9HTyAgICAgICAtIHVzZSBibXBfbG9nbyBpbnN0ZWFkIG9mIGxpbnV4X2xvZ28KICBDT05GSUdf
Q09OU09MRV9FWFRSQV9JTkZPICAgLSBkaXNwbGF5IGFkZGl0aW9uYWwgYm9hcmQgaW5mb3JtYXRp
b24gc3RyaW5ncwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoYXQgbm9ybWFseSBn
b2VzIHRvIHNlcmlhbCBwb3J0LiBUaGlzIGRlZmluZQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHJlcXVpcmVzIGEgYm9hcmQgc3BlY2lmaWMgZnVuY3Rpb246CkBAIC05Myw2ICs5NCw4
IEBAIENPTkZJR19WSURFT19IV19DVVJTT1I6ICAgICAgLSBVc2VzIHRoZSAKIAogI2lmZGVmIENP
TkZJR19DRkJfQ09OU09MRQogCisjaW5jbHVkZSA8bWFsbG9jLmg+CisKIC8qKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKi8KIC8qIENvbnNvbGUgZGV2aWNlIGRlZmluZXMgd2l0aCBTTUkgZ3JhcGhpYyAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKi8KIC8qIEFueSBvdGhlciBncmFwaGljIG11
c3QgY2hhbmdlIHRoaXMgc2VjdGlvbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKi8K
QEAgLTExNiw2ICsxMTksMTYgQEAgQ09ORklHX1ZJREVPX0hXX0NVUlNPUjogICAgICAtIFVzZXMg
dGhlIAogI2VuZGlmCiAKIC8qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKi8KKy8qIERlZmluZXMgZm9yIHRo
ZSBTRUQxMzgwNiBkcml2ZXIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgKi8KKy8qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKi8KKyNpZmRlZiBDT05GSUdfVklERU9fU0VEMTM4
MDYKKworI2RlZmluZSBWSURFT19GQl9MSVRUTEVfRU5ESUFOCisjZGVmaW5lIFZJREVPX0hXX1JF
Q1RGSUxMCisjZGVmaW5lIFZJREVPX0hXX0JJVEJMVAorI2VuZGlmCisKKy8qKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKi8KIC8qIEluY2x1ZGUgdmlkZW9fZmIuaCBhZnRlciBkZWZpbml0aW9ucyBvZiBWSURF
T19IV19SRUNURklMTCBldGMgICAgICAgICAgICAgKi8KIC8qKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKi8K
ICNpbmNsdWRlIDx2aWRlb19mYi5oPgpAQCAtMjE3LDYgKzIzMCwxNCBAQCB2b2lkICAgIGNvbnNv
bGVfY3Vyc29yIChpbnQgc3RhdGUpOwogI2VuZGlmICAvKiBDT05GSUdfVklERU9fSFdfQ1VSU09S
ICovCiAKICNpZmRlZiAgQ09ORklHX1ZJREVPX0xPR08KKyNpZmRlZiAgQ09ORklHX1ZJREVPX0JN
UF9MT0dPCisjaW5jbHVkZSA8Ym1wX2xvZ28uaD4KKyNkZWZpbmUgVklERU9fTE9HT19XSURUSCAg
ICAgICAgQk1QX0xPR09fV0lEVEgKKyNkZWZpbmUgVklERU9fTE9HT19IRUlHSFQgICAgICAgQk1Q
X0xPR09fSEVJR0hUCisjZGVmaW5lIFZJREVPX0xPR09fTFVUX09GRlNFVCAgIEJNUF9MT0dPX09G
RlNFVAorI2RlZmluZSBWSURFT19MT0dPX0NPTE9SUyAgICAgICBCTVBfTE9HT19DT0xPUlMKKwor
I2Vsc2UgICAvKiBDT05GSUdfVklERU9fQk1QX0xPR08gKi8KICNkZWZpbmUgTElOVVhfTE9HT19X
SURUSCAgICAgICAgODAKICNkZWZpbmUgTElOVVhfTE9HT19IRUlHSFQgICAgICAgODAKICNkZWZp
bmUgTElOVVhfTE9HT19DT0xPUlMgICAgICAgMjE0CkBAIC0yMjUsMTMgKzI0NiwxNSBAQCB2b2lk
ICAgIGNvbnNvbGVfY3Vyc29yIChpbnQgc3RhdGUpOwogI2luY2x1ZGUgPGxpbnV4X2xvZ28uaD4K
ICNkZWZpbmUgVklERU9fTE9HT19XSURUSCAgICAgICAgTElOVVhfTE9HT19XSURUSAogI2RlZmlu
ZSBWSURFT19MT0dPX0hFSUdIVCAgICAgICBMSU5VWF9MT0dPX0hFSUdIVAotCisjZGVmaW5lIFZJ
REVPX0xPR09fTFVUX09GRlNFVCAgIExJTlVYX0xPR09fTFVUX09GRlNFVAorI2RlZmluZSBWSURF
T19MT0dPX0NPTE9SUyAgICAgICBMSU5VWF9MT0dPX0NPTE9SUworI2VuZGlmICAvKiBDT05GSUdf
VklERU9fQk1QX0xPR08gKi8KICNkZWZpbmUgVklERU9fSU5GT19YICAgICAgICAgICAgKFZJREVP
X0xPR09fV0lEVEgpCiAjZGVmaW5lIFZJREVPX0lORk9fWSAgICAgICAgICAgIChWSURFT19GT05U
X0hFSUdIVC8yKQotI2Vsc2UKKyNlbHNlICAgLyogQ09ORklHX1ZJREVPX0xPR08gKi8KICNkZWZp
bmUgVklERU9fTE9HT19XSURUSCAgICAgICAgMAogI2RlZmluZSBWSURFT19MT0dPX0hFSUdIVCAg
ICAgICAwCi0jZW5kaWYKKyNlbmRpZiAgLyogQ09ORklHX1ZJREVPX0xPR08gKi8KIAogI2RlZmlu
ZSBWSURFT19DT0xTICAgICAgICAgICAgICBWSURFT19WSVNJQkxFX0NPTFMKICNkZWZpbmUgVklE
RU9fUk9XUyAgICAgICAgICAgICAgVklERU9fVklTSUJMRV9ST1dTCkBAIC00NjMsMTEgKzQ4Niw3
IEBAIHN0YXRpYyBpbmxpbmUgdm9pZCB2aWRlb19kcmF3c3RyaW5nKGludCAKIAogc3RhdGljIHZv
aWQgdmlkZW9fcHV0Y2hhcihpbnQgeHgsIGludCB5eSwgdW5zaWduZWQgY2hhciBjKQogewotI2lm
ZGVmIENPTkZJR19WSURFT19MT0dPCiAgICAgdmlkZW9fZHJhd2NoYXJzICh4eCwgeXkgKyBWSURF
T19MT0dPX0hFSUdIVCwgJmMsIDEpOwotI2Vsc2UKLSAgICB2aWRlb19kcmF3Y2hhcnMgKHh4LCB5
eSwgJmMsIDEpOwotI2VuZGlmCiB9CiAKIC8qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKi8KQEAgLTY3Niw4
MyArNjk1LDEwNyBAQCB2b2lkIHZpZGVvX3B1dHMgKGNvbnN0IGNoYXIgKnMpCiAjaWZkZWYgQ09O
RklHX1ZJREVPX0xPR08KIHZvaWQgbG9nb19wbG90ICh2b2lkICpzY3JlZW4sIGludCB3aWR0aCwg
aW50IHgsIGludCB5KQogewotICAgIGludCBza2lwID0gKHdpZHRoIC0gTElOVVhfTE9HT19XSURU
SCkgKiBWSURFT19QSVhFTF9TSVpFLAorCisgICAgaW50IHNraXAgPSAod2lkdGggLSBWSURFT19M
T0dPX1dJRFRIKSAqIFZJREVPX1BJWEVMX1NJWkUsCiAgICAgICAgIHhjb3VudCwgaSwKLSAgICAg
ICAgeWNvdW50ID0gTElOVVhfTE9HT19IRUlHSFQ7CisgICAgICAgIHljb3VudCA9IFZJREVPX0xP
R09fSEVJR0hUOwogICAgIHVuc2lnbmVkIGNoYXIKLSAgICAgICAgKnNvdXJjZSA9IGxpbnV4X2xv
Z28sCisgICAgICAgICpzb3VyY2UsCiAgICAgICAgICpkZXN0ICAgPSAodW5zaWduZWQgY2hhciAq
KSBzY3JlZW4gKyAoKHkgKiB3aWR0aCAqIFZJREVPX1BJWEVMX1NJWkUpICsgeCksCi0gICAgICAg
IHIsIGcsIGI7CisgICAgICAgIHIsIGcsIGIsICpsb2dvX3JlZCwgKmxvZ29fYmx1ZSwgKmxvZ29f
Z3JlZW47CiAKKyNpZmRlZiBDT05GSUdfVklERU9fQk1QX0xPR08KKyAgICBzb3VyY2UgPSBibXBf
bG9nb19iaXRtYXA7CisgICAgCisgICAgLyogQWxsb2NhdGUgdGVtcG9yYXJ5IHNwYWNlIGZvciBj
b21wdXRpbmcgY29sb3JtYXAgICAgICAgICAgICAgICAgICAgICAgICovCisgICAgbG9nb19yZWQg
PSBtYWxsb2MgKEJNUF9MT0dPX0NPTE9SUyk7CisgICAgbG9nb19ncmVlbiA9IG1hbGxvYyAoQk1Q
X0xPR09fQ09MT1JTKTsKKyAgICBsb2dvX2JsdWUgPSBtYWxsb2MgKEJNUF9MT0dPX0NPTE9SUyk7
CisgICAgLyogQ29tcHV0ZSBjb2xvciBtYXAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICovCisgICAgZm9yIChpID0gMDsgaSA8IFZJREVPX0xPR09f
Q09MT1JTOyBpKyspIHsKKyAgICAgICAgbG9nb19yZWQgW2ldID0gKGJtcF9sb2dvX3BhbGV0dGUg
W2ldICYgMHgwZjAwKSA+PiA0OworICAgICAgICBsb2dvX2dyZWVuIFtpXSA9IChibXBfbG9nb19w
YWxldHRlIFtpXSAmIDB4MDBmMCk7CisgICAgICAgIGxvZ29fYmx1ZSBbaV0gPSAoYm1wX2xvZ29f
cGFsZXR0ZSBbaV0gJiAweDAwMGYpIDw8IDQ7CisgICAgfQorI2Vsc2UKKyAgICBzb3VyY2UgPSBs
aW51eF9sb2dvOworICAgIGxvZ29fcmVkID0gbGludXhfbG9nb19yZWQ7CisgICAgbG9nb19ncmVl
biA9IGxpbnV4X2xvZ29fZ3JlZW47CisgICAgbG9nb19ibHVlID0gbGludXhfbG9nb19ibHVlOwor
I2VuZGlmCisgICAgCiAgICAgaWYgKFZJREVPX0RBVEFfRk9STUFUID09IEdERl9fOEJJVF9JTkRF
WCkKICAgICB7Ci0gICAgICAgIGZvciAoaSA9IDA7IGkgPCBMSU5VWF9MT0dPX0NPTE9SUzsgaSsr
KQorICAgICAgICBmb3IgKGkgPSAwOyBpIDwgVklERU9fTE9HT19DT0xPUlM7IGkrKykKICAgICAg
ICAgewotICAgICAgICAgICAgciA9ICh1bnNpZ25lZCBjaGFyKWxpbnV4X2xvZ29fcmVkICBbaV07
Ci0gICAgICAgICAgICBnID0gKHVuc2lnbmVkIGNoYXIpbGludXhfbG9nb19ncmVlbltpXTsKLSAg
ICAgICAgICAgIGIgPSAodW5zaWduZWQgY2hhcilsaW51eF9sb2dvX2JsdWUgW2ldOwotICAgICAg
ICAgICAgdmlkZW9fc2V0X2x1dCAoTElOVVhfTE9HT19MVVRfT0ZGU0VUICsgaSwgciwgZywgYik7
CisgICAgICAgICAgICB2aWRlb19zZXRfbHV0IChpICsgVklERU9fTE9HT19MVVRfT0ZGU0VULAor
ICAgICAgICAgICAgICAgICAgICAgICAgICAgbG9nb19yZWQgW2ldLCBsb2dvX2dyZWVuIFtpXSwg
bG9nb19ibHVlIFtpXSk7CiAgICAgICAgIH0KICAgICB9CiAKICAgICB3aGlsZSAoeWNvdW50LS0p
CiAgICAgewotICAgIHhjb3VudCA9IExJTlVYX0xPR09fV0lEVEg7Ci0gICAgd2hpbGUgKHhjb3Vu
dC0tKQotICAgIHsKLSAgICAgICAgciA9ICh1bnNpZ25lZCBjaGFyKWxpbnV4X2xvZ29fcmVkICBb
KnNvdXJjZSAtIExJTlVYX0xPR09fTFVUX09GRlNFVF07Ci0gICAgICAgIGcgPSAodW5zaWduZWQg
Y2hhcilsaW51eF9sb2dvX2dyZWVuWypzb3VyY2UgLSBMSU5VWF9MT0dPX0xVVF9PRkZTRVRdOwot
ICAgICAgICBiID0gKHVuc2lnbmVkIGNoYXIpbGludXhfbG9nb19ibHVlIFsqc291cmNlIC0gTElO
VVhfTE9HT19MVVRfT0ZGU0VUXTsKLQotICAgICAgICBzd2l0Y2ggKFZJREVPX0RBVEFfRk9STUFU
KQotICAgICAgICB7Ci0gICAgICAgIGNhc2UgR0RGX184QklUX0lOREVYOgotICAgICAgICAgICAg
KmRlc3QgPSAqc291cmNlOwotICAgICAgICAgICAgYnJlYWs7Ci0gICAgICAgIGNhc2UgR0RGX184
QklUXzMzMlJHQjoKLSAgICAgICAgICAgICpkZXN0ID0gKChyPj41KTw8NSkgfCAoKGc+PjUpPDwy
KSB8IChiPj42KTsKLSAgICAgICAgICAgIGJyZWFrOwotICAgICAgICBjYXNlIEdERl8xNUJJVF81
NTVSR0I6Ci0gICAgICAgICAgICAqKHVuc2lnbmVkIHNob3J0ICopZGVzdCA9Ci0gICAgICAgICAg
ICBTV0FQMTYoKHVuc2lnbmVkIHNob3J0KSgoKHI+PjMpPDwxMCkgfCAoKGc+PjMpPDw1KSB8IChi
Pj4zKSkpOwotICAgICAgICAgICAgYnJlYWs7Ci0gICAgICAgIGNhc2UgR0RGXzE2QklUXzU2NVJH
QjoKLSAgICAgICAgICAgICoodW5zaWduZWQgc2hvcnQgKilkZXN0ID0KLSAgICAgICAgICAgIFNX
QVAxNigodW5zaWduZWQgc2hvcnQpKCgocj4+Myk8PDExKSB8ICgoZz4+Mik8PDUpIHwgKGI+PjMp
KSk7Ci0gICAgICAgICAgICBicmVhazsKLSAgICAgICAgY2FzZSBHREZfMzJCSVRfWDg4OFJHQjoK
LSAgICAgICAgICAgICoodW5zaWduZWQgbG9uZyAgKilkZXN0ID0KLSAgICAgICAgICAgIFNXQVAz
MigodW5zaWduZWQgbG9uZykoKHI8PDE2KSB8IChnPDw4KSB8IGIpKTsKLSAgICAgICAgICAgIGJy
ZWFrOwotICAgICAgICBjYXNlIEdERl8yNEJJVF84ODhSR0I6CisgICAgICAgIHhjb3VudCA9IFZJ
REVPX0xPR09fV0lEVEg7CisgICAgICAgIHdoaWxlICh4Y291bnQtLSkKKyAgICAgICAgeworICAg
ICAgICAgICAgciA9IGxvZ29fcmVkIFsqc291cmNlIC0gVklERU9fTE9HT19MVVRfT0ZGU0VUXTsK
KyAgICAgICAgICAgIGcgPSBsb2dvX2dyZWVuIFsqc291cmNlIC0gVklERU9fTE9HT19MVVRfT0ZG
U0VUXTsKKyAgICAgICAgICAgIGIgPSBsb2dvX2JsdWUgWypzb3VyY2UgLSBWSURFT19MT0dPX0xV
VF9PRkZTRVRdOworICAgICAgICAgICAgCisgICAgICAgICAgICBzd2l0Y2ggKFZJREVPX0RBVEFf
Rk9STUFUKQorICAgICAgICAgICAgeworICAgICAgICAgICAgY2FzZSBHREZfXzhCSVRfSU5ERVg6
CisgICAgICAgICAgICAgICAgKmRlc3QgPSAqc291cmNlOworICAgICAgICAgICAgICAgIGJyZWFr
OworICAgICAgICAgICAgY2FzZSBHREZfXzhCSVRfMzMyUkdCOgorICAgICAgICAgICAgICAgICpk
ZXN0ID0gKChyPj41KTw8NSkgfCAoKGc+PjUpPDwyKSB8IChiPj42KTsKKyAgICAgICAgICAgICAg
ICBicmVhazsKKyAgICAgICAgICAgIGNhc2UgR0RGXzE1QklUXzU1NVJHQjoKKyAgICAgICAgICAg
ICAgICAqKHVuc2lnbmVkIHNob3J0ICopZGVzdCA9CisgICAgICAgICAgICAgICAgICAgIFNXQVAx
NigodW5zaWduZWQgc2hvcnQpKCgocj4+Myk8PDEwKSB8ICgoZz4+Myk8PDUpIHwgKGI+PjMpKSk7
CisgICAgICAgICAgICAgICAgYnJlYWs7CisgICAgICAgICAgICBjYXNlIEdERl8xNkJJVF81NjVS
R0I6CisgICAgICAgICAgICAgICAgKih1bnNpZ25lZCBzaG9ydCAqKWRlc3QgPQorICAgICAgICAg
ICAgICAgICAgICBTV0FQMTYoKHVuc2lnbmVkIHNob3J0KSgoKHI+PjMpPDwxMSkgfCAoKGc+PjIp
PDw1KSB8IChiPj4zKSkpOworICAgICAgICAgICAgICAgIGJyZWFrOworICAgICAgICAgICAgY2Fz
ZSBHREZfMzJCSVRfWDg4OFJHQjoKKyAgICAgICAgICAgICAgICAqKHVuc2lnbmVkIGxvbmcgICop
ZGVzdCA9CisgICAgICAgICAgICAgICAgICAgIFNXQVAzMigodW5zaWduZWQgbG9uZykoKHI8PDE2
KSB8IChnPDw4KSB8IGIpKTsKKyAgICAgICAgICAgICAgICBicmVhazsKKyAgICAgICAgICAgIGNh
c2UgR0RGXzI0QklUXzg4OFJHQjoKICNpZmRlZiBWSURFT19GQl9MSVRUTEVfRU5ESUFOCi0gICAg
ICAgICAgICBkZXN0WzBdID0gYjsKLSAgICAgICAgICAgIGRlc3RbMV0gPSBnOwotICAgICAgICAg
ICAgZGVzdFsyXSA9IHI7Ci0jZWxzZQotICAgICAgICAgICAgZGVzdFswXSA9IHI7Ci0gICAgICAg
ICAgICBkZXN0WzFdID0gZzsKLSAgICAgICAgICAgIGRlc3RbMl0gPSBiOworICAgICAgICAgICAg
ICAgIGRlc3RbMF0gPSBiOworICAgICAgICAgICAgICAgIGRlc3RbMV0gPSBnOworICAgICAgICAg
ICAgICAgIGRlc3RbMl0gPSByOworI2Vsc2UKKyAgICAgICAgICAgICAgICBkZXN0WzBdID0gcjsK
KyAgICAgICAgICAgICAgICBkZXN0WzFdID0gZzsKKyAgICAgICAgICAgICAgICBkZXN0WzJdID0g
YjsKICNlbmRpZgotICAgICAgICAgICAgYnJlYWs7CisgICAgICAgICAgICAgICAgYnJlYWs7Cisg
ICAgICAgICAgICB9CisgICAgICAgICAgICBzb3VyY2UrKzsKKyAgICAgICAgICAgIGRlc3QgKz0g
VklERU9fUElYRUxfU0laRTsKICAgICAgICAgfQotICAgICAgICBzb3VyY2UrKzsKLSAgICAgICAg
ZGVzdCArPSBWSURFT19QSVhFTF9TSVpFOwotICAgIH0KLSAgICBkZXN0ICs9IHNraXA7CisgICAg
ICAgIGRlc3QgKz0gc2tpcDsKICAgICB9CisjaWZkZWYgQ09ORklHX1ZJREVPX0JNUF9MT0dPCisg
ICAgZnJlZSAobG9nb19yZWQpOworICAgIGZyZWUgKGxvZ29fZ3JlZW4pOworICAgIGZyZWUgKGxv
Z29fYmx1ZSk7CisjZW5kaWYKIH0KIAotCiAvKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiovCiAKIHN0YXRp
YyB2b2lkICp2aWRlb19sb2dvICh2b2lkKQogewogICAgIGNoYXIgaW5mb1sxMjhdOworICAgIGV4
dGVybiBjaGFyIHZlcnNpb25fc3RyaW5nOwogCiAgICAgbG9nb19wbG90ICh2aWRlb19mYl9hZGRy
ZXNzLCBWSURFT19DT0xTLCAwLCAwKTsKIAotICAgIHNwcmludGYoaW5mbywgIiAlcyAoJXMgLSAl
cykiLCBVX0JPT1RfVkVSU0lPTiwgX19EQVRFX18sIF9fVElNRV9fKTsKKyAgICBzcHJpbnRmKGlu
Zm8sICIgJXMiLCAmdmVyc2lvbl9zdHJpbmcpOwogICAgIHZpZGVvX2RyYXdzdHJpbmcgKFZJREVP
X0lORk9fWCwgVklERU9fSU5GT19ZLCBpbmZvKTsKIAogI2lmZGVmIENPTkZJR19DT05TT0xFX0VY
VFJBX0lORk8KZGlmZiAtcHVyTiBwcGNib290LTIuMC4wLWN2cy9kcml2ZXJzL3NlZDEzODA2LmMg
cHBjYm9vdC0yLjAuMC1sY2QvZHJpdmVycy9zZWQxMzgwNi5jCi0tLSBwcGNib290LTIuMC4wLWN2
cy9kcml2ZXJzL3NlZDEzODA2LmMJMTk3MC0wMS0wMSAwMTowMDowMC4wMDAwMDAwMDAgKzAxMDAK
KysrIHBwY2Jvb3QtMi4wLjAtbGNkL2RyaXZlcnMvc2VkMTM4MDYuYwkyMDAyLTExLTIwIDE4OjI2
OjAyLjAwMDAwMDAwMCArMDEwMApAQCAtMCwwICsxLDMwNiBAQAorLyoKKyAqIChDKSBDb3B5cmln
aHQgMjAwMgorICogU3TkdWJsaSBGYXZlcmdlcyAtIDx3d3cuc3RhdWJsaS5jb20+CisgKiBQaWVy
cmUgQVVCRVJUICBwLmF1YmVydEBzdGF1YmxpLmNvbQorICoKKyAqIFNlZSBmaWxlIENSRURJVFMg
Zm9yIGxpc3Qgb2YgcGVvcGxlIHdobyBjb250cmlidXRlZCB0byB0aGlzCisgKiBwcm9qZWN0Lgor
ICoKKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0
ZSBpdCBhbmQvb3IKKyAqIG1vZGlmeSBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5l
cmFsIFB1YmxpYyBMaWNlbnNlIGFzCisgKiBwdWJsaXNoZWQgYnkgdGhlIEZyZWUgU29mdHdhcmUg
Rm91bmRhdGlvbjsgZWl0aGVyIHZlcnNpb24gMiBvZgorICogdGhlIExpY2Vuc2UsIG9yIChhdCB5
b3VyIG9wdGlvbikgYW55IGxhdGVyIHZlcnNpb24uCisgKgorICogVGhpcyBwcm9ncmFtIGlzIGRp
c3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsCisgKiBidXQgV0lU
SE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZgor
ICogTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAg
U2VlIHRoZQorICogR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4K
KyAqCisgKiBZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJh
bCBQdWJsaWMgTGljZW5zZQorICogYWxvbmcgd2l0aCB0aGlzIHByb2dyYW07IGlmIG5vdCwgd3Jp
dGUgdG8gdGhlIEZyZWUgU29mdHdhcmUKKyAqIEZvdW5kYXRpb24sIEluYy4sIDU5IFRlbXBsZSBQ
bGFjZSwgU3VpdGUgMzMwLCBCb3N0b24sCisgKiBNQSAwMjExMS0xMzA3IFVTQQorICovCisvKiBW
aWRlbyBzdXBwb3J0IGZvciBFcHNvbiBTRUQxMzgwNiBjaGlwc2V0ICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICovCisKKyNpbmNsdWRlIDxjb21tb24uaD4KKworI2lmZGVmIENPTkZJ
R19WSURFT19TRUQxMzgwNgorCisjaW5jbHVkZSA8dmlkZW9fZmIuaD4KKyNpbmNsdWRlIDxzZWQx
MzgwNi5oPgorCisjZGVmaW5lIHJlYWRCeXRlKHB0clJlZykgICAgICAgICAgICAgICAgXAorICAg
ICoodm9sYXRpbGUgdW5zaWduZWQgY2hhciAqKShzZWQxMzgwNi5pc2FCYXNlICsgcHRyUmVnKQor
CisjZGVmaW5lIHdyaXRlQnl0ZShwdHJSZWcsdmFsdWUpIFwKKyAgICAqKHZvbGF0aWxlIHVuc2ln
bmVkIGNoYXIgKikoc2VkMTM4MDYuaXNhQmFzZSArIHB0clJlZykgPSB2YWx1ZQorCisjZGVmaW5l
IHdyaXRlV29yZChwdHJSZWcsdmFsdWUpIFwKKyAgICAoKih2b2xhdGlsZSB1bnNpZ25lZCBzaG9y
dCAqKShzZWQxMzgwNi5pc2FCYXNlICsgcHRyUmVnKSA9ICgodmFsdWUgPj4gOCApICYgMHhmZikg
fCAoKHZhbHVlIDw8IDgpICYgMHhmZjAwKSkKKworCitHcmFwaGljRGV2aWNlIHNlZDEzODA2Owor
CisvKi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCisgKiBFcHNvblNldFJlZ3MgLS0gCisgKi0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tCisgKi8KK3N0YXRpYyB2b2lkIEVwc29uU2V0UmVncyAodm9pZCkKK3sKKyAg
ICAvKiB0aGUgY29udGVudCBvZiB0aGUgY2hpcHNldCByZWdpc3RlciBkZXBlbmRzIG9uIHRoZSBi
b2FyZCAoY2xvY2tzLCAuLi4pKi8KKyAgICBjb25zdCBTMURfUkVHUyAqcHJlZyA9IGJvYXJkX2dl
dF9yZWdzICgpOworICAgIHdoaWxlIChwcmVnIC0+IEluZGV4KSB7CisgICAgICAgIHdyaXRlQnl0
ZSAocHJlZyAtPiBJbmRleCwgcHJlZyAtPiBWYWx1ZSk7CisgICAgICAgIHByZWcgKys7CisgICAg
fQorfQorICAgIAorLyotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQorICogdmlkZW9faHdfaW5pdCAtLSAK
KyAqLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyAqLwordm9pZCAqdmlkZW9faHdfaW5pdCAodm9pZCkK
K3sKKyAgICB1bnNpZ25lZCBpbnQgKnZtLCBpOworCisgICAgbWVtc2V0ICgmc2VkMTM4MDYsIDAs
IHNpemVvZiAoR3JhcGhpY0RldmljZSkpOworCisgICAgLyogSW5pdGlhbGl6YXRpb24gb2YgdGhl
IGFjY2VzcyB0byB0aGUgZ3JhcGhpYyBjaGlwc2V0CisgICAgICAgUmV0cmVpdmUgYmFzZSBhZGRy
ZXNzIG9mIHRoZSBjaGlwc2V0CisgICAgICAgKHNlZSBib2FyZC9SUFhDbGFzc2ljL2VjY3guYykg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICovCisgICAgaWYgKChzZWQx
MzgwNi5pc2FCYXNlID0gYm9hcmRfdmlkZW9faW5pdCAoKSkgPT0gMCkgeworICAgICAgICByZXR1
cm4gKE5VTEwpOworICAgIH0KKworICAgIHNlZDEzODA2LmZyYW1lQWRycyA9IHNlZDEzODA2Lmlz
YUJhc2UgKyBGUkFNRV9CVUZGRVJfT0ZGU0VUOworICAgIHNlZDEzODA2LndpblNpemVYID0gYm9h
cmRfZ2V0X3dpZHRoICgpOworICAgIHNlZDEzODA2LndpblNpemVZID0gYm9hcmRfZ2V0X2hlaWdo
dCAoKTsKKworI2lmIGRlZmluZWQoQ09ORklHX1ZJREVPX1NFRDEzODA2XzhCUFApCisgICAgc2Vk
MTM4MDYuZ2RmSW5kZXggPSBHREZfXzhCSVRfSU5ERVg7CisgICAgc2VkMTM4MDYuZ2RmQnl0ZXNQ
UCA9IDE7CisgICAgCisjZWxpZiBkZWZpbmVkKENPTkZJR19WSURFT19TRUQxMzgwNl8xNkJQUCkK
KyAgICBzZWQxMzgwNi5nZGZJbmRleCA9IEdERl8xNkJJVF81NjVSR0I7CisgICAgc2VkMTM4MDYu
Z2RmQnl0ZXNQUCA9IDI7CisKKyNlbHNlCisjZXJyb3IgVW5zdXBwb3J0ZWQgU0VEMTM4MDYgQlBQ
CisjZW5kaWYKKworICAgIHNlZDEzODA2Lm1lbVNpemUgPSBzZWQxMzgwNi53aW5TaXplWCAqIHNl
ZDEzODA2LndpblNpemVZICogc2VkMTM4MDYuZ2RmQnl0ZXNQUDsKKworICAgIC8qIExvYWQgU0VE
IHJlZ2lzdGVycyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAqLworICAgIEVwc29uU2V0UmVncyAoKTsKKworICAgIC8qIChzZWUgYm9hcmQvUlBYQ2xh
c3NpYy9SUFhDbGFzc2ljLmMpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAqLwor
ICAgIGJvYXJkX3ZhbGlkYXRlX3NjcmVlbiAoc2VkMTM4MDYuaXNhQmFzZSk7CisKKyAgICAvKiBD
bGVhciB2aWRlbyBtZW1vcnkgKi8KKyAgICBpID0gc2VkMTM4MDYubWVtU2l6ZS80OworICAgIHZt
ID0gKHVuc2lnbmVkIGludCAqKXNlZDEzODA2LmZyYW1lQWRyczsKKyAgICB3aGlsZShpLS0pCisg
ICAgICAgICp2bSsrID0gMDsKKyAgICAKKyAgICAKKyAgICByZXR1cm4gKCZzZWQxMzgwNik7Cit9
CisvKi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCisgKiBFcHNvbl93YWl0X2lkbGUgLS0gV2FpdCBmb3Ig
aGFyZHdhcmUgdG8gYmVjb21lIGlkbGUKKyAqLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyAqLworc3Rh
dGljIHZvaWQgRXBzb25fd2FpdF9pZGxlICh2b2lkKQoreworICAgIHdoaWxlIChyZWFkQnl0ZSAo
QkxUX0NUUkwwKSAmIDB4ODApOworCisgICAgLyogUmVhZCBhIHdvcmQgaW4gdGhlIEJpdEJMVCBt
ZW1vcnkgYXJlYSB0byBzaHV0ZG93biB0aGUgQml0QkxUIGVuZ2luZSAgICovCisgICAgKih2b2xh
dGlsZSB1bnNpZ25lZCBzaG9ydCAqKShzZWQxMzgwNi5pc2FCYXNlICsgQkxUX1JFRyk7Cit9CisK
Ky8qLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyAqIHZpZGVvX2h3X2JpdGJsdCAtLSAKKyAqLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0KKyAqLwordm9pZCB2aWRlb19od19iaXRibHQgKAorICAgIHVuc2lnbmVk
IGludCBicHAsICAgICAgICAgICAgIC8qIGJ5dGVzIHBlciBwaXhlbCAqLworICAgIHVuc2lnbmVk
IGludCBzcmNfeCwgICAgICAgICAgIC8qIHNvdXJjZSBwb3MgeCAqLworICAgIHVuc2lnbmVkIGlu
dCBzcmNfeSwgICAgICAgICAgIC8qIHNvdXJjZSBwb3MgeSAqLworICAgIHVuc2lnbmVkIGludCBk
c3RfeCwgICAgICAgICAgIC8qIGRlc3QgcG9zIHggKi8KKyAgICB1bnNpZ25lZCBpbnQgZHN0X3ks
ICAgICAgICAgICAvKiBkZXN0IHBvcyB5ICovCisgICAgdW5zaWduZWQgaW50IGRpbV94LCAgICAg
ICAgICAgLyogZnJhbWUgd2lkdGggKi8KKyAgICB1bnNpZ25lZCBpbnQgZGltX3kgICAgICAgICAg
ICAvKiBmcmFtZSBoZWlnaHQgKi8KKyAgICApCit7CisgICAgcmVnaXN0ZXIgR3JhcGhpY0Rldmlj
ZSAqcEdEID0gKEdyYXBoaWNEZXZpY2UgKikmc2VkMTM4MDY7CisgICAgdW5zaWduZWQgbG9uZwlz
cmNBZGRyLCBkc3RBZGRyOworICAgIHVuc2lnbmVkIGludCBzdHJpZGUgPSBicHAgKiBwR0QgLT4g
d2luU2l6ZVg7CisKKyAgICBzcmNBZGRyID0gKHNyY195ICogc3RyaWRlKSArIChzcmNfeCAqIGJw
cCk7CisgICAgZHN0QWRkciA9IChkc3RfeSAqIHN0cmlkZSkgKyAoZHN0X3ggKiBicHApOworCisg
ICAgRXBzb25fd2FpdF9pZGxlICgpOworICAgIAorICAgIHdyaXRlQnl0ZShCTFRfUk9QLDB4MEMp
OwkvLyBzb3VyY2UKKyAgICB3cml0ZUJ5dGUoQkxUX09QLDB4MDIpOy8vIG1vdmUgYmxpdCBpbiBw
b3NpdGl2ZSBkaXJlY3Rpb24gd2l0aCBST1AKKyAgICB3cml0ZVdvcmQoQkxUX01FTV9PRkYwLCBz
dHJpZGUgLyAyKTsKKyAgICBpZiAocEdEIC0+IGdkZkluZGV4ID09IEdERl9fOEJJVF9JTkRFWCkg
eworICAgICAgICB3cml0ZUJ5dGUoQkxUX0NUUkwxLDB4MDApOworICAgIH0KKyAgICBlbHNlIHsK
KyAgICAgICAgd3JpdGVCeXRlKEJMVF9DVFJMMSwweDAxKTsKKyAgICB9CisKKyAgICB3cml0ZVdv
cmQoQkxUX1dJRFRIMCwoZGltX3ggLSAxKSk7CisgICAgd3JpdGVXb3JkKEJMVF9IRUlHSFQwLChk
aW1feSAtIDEpKTsKKyAgICAKKyAgICAvKiBzZXQgdXAgYmxpdCByZWdpc3RlcnMgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKi8KKyAgICB3cml0ZUJ5dGUo
QkxUX1NSQ19BRERSMCxzcmNBZGRyKTsKKyAgICB3cml0ZUJ5dGUoQkxUX1NSQ19BRERSMSxzcmNB
ZGRyPj44KTsgCisgICAgd3JpdGVCeXRlKEJMVF9TUkNfQUREUjIsc3JjQWRkcj4+MTYpOyAKKyAg
ICAKKyAgICB3cml0ZUJ5dGUoQkxUX0RTVF9BRERSMCxkc3RBZGRyKTsKKyAgICB3cml0ZUJ5dGUo
QkxUX0RTVF9BRERSMSxkc3RBZGRyPj44KTsgCisgICAgd3JpdGVCeXRlKEJMVF9EU1RfQUREUjIs
ZHN0QWRkcj4+MTYpOyAKKyAgICAKKyAgICAvKiBFbmdhZ2UgdGhlIGJsdCBlbmdpbmUgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKi8KKyAgICAvKiByZWN0
YW5ndWxhciByZWdpb24gZm9yIHNyYyBhbmQgZHN0ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgKi8KKyAgICB3cml0ZUJ5dGUoQkxUX0NUUkwwLDB4ODApOworCisgICAgLyogd2Fp
dCB1bnRpbGwgY3VycmVudCBibGl0cyBmaW5pc2hlZCAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICovCisgICAgRXBzb25fd2FpdF9pZGxlICgpOworfQorLyotLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLQorICogdmlkZW9faHdfcmVjdGZpbGwgLS0gCisgKi0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
CisgKi8KK3ZvaWQgdmlkZW9faHdfcmVjdGZpbGwgKAorICAgIHVuc2lnbmVkIGludCBicHAsICAg
ICAgICAgICAgIC8qIGJ5dGVzIHBlciBwaXhlbCAqLworICAgIHVuc2lnbmVkIGludCBkc3RfeCwg
ICAgICAgICAgIC8qIGRlc3QgcG9zIHggKi8KKyAgICB1bnNpZ25lZCBpbnQgZHN0X3ksICAgICAg
ICAgICAvKiBkZXN0IHBvcyB5ICovCisgICAgdW5zaWduZWQgaW50IGRpbV94LCAgICAgICAgICAg
LyogZnJhbWUgd2lkdGggKi8KKyAgICB1bnNpZ25lZCBpbnQgZGltX3ksICAgICAgICAgICAvKiBm
cmFtZSBoZWlnaHQgKi8KKyAgICB1bnNpZ25lZCBpbnQgY29sb3IgICAgICAgICAgICAvKiBmaWxs
IGNvbG9yICovCisgICAgICkKK3sKKyAgICByZWdpc3RlciBHcmFwaGljRGV2aWNlICpwR0QgPSAo
R3JhcGhpY0RldmljZSAqKSZzZWQxMzgwNjsKKyAgICB1bnNpZ25lZCBsb25nCWRzdEFkZHI7Cisg
ICAgdW5zaWduZWQgaW50IHN0cmlkZSA9IGJwcCAqIHBHRCAtPiB3aW5TaXplWDsKKworICAgIGRz
dEFkZHIgPSAoZHN0X3kgKiBzdHJpZGUpICsgKGRzdF94ICogYnBwKTsKKworICAgIEVwc29uX3dh
aXRfaWRsZSAoKTsKKworICAgIC8qIHNldCB1cCBibGl0IHJlZ2lzdGVycyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAqLworICAgIHdyaXRlQnl0ZShCTFRf
RFNUX0FERFIwLGRzdEFkZHIpOworICAgIHdyaXRlQnl0ZShCTFRfRFNUX0FERFIxLGRzdEFkZHI+
PjgpOyAKKyAgICB3cml0ZUJ5dGUoQkxUX0RTVF9BRERSMixkc3RBZGRyPj4xNik7IAorCisgICAg
d3JpdGVXb3JkKEJMVF9XSURUSDAsKGRpbV94IC0gMSkpOworICAgIHdyaXRlV29yZChCTFRfSEVJ
R0hUMCwoZGltX3kgLSAxKSk7CisgICAgd3JpdGVXb3JkKEJMVF9GR0NPTE9SMCxjb2xvcik7CisK
KyAgICB3cml0ZUJ5dGUoQkxUX09QLDB4MEMpOyAgLyogc29saWQgZmlsbCAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgKi8KKyAgICB3cml0ZVdvcmQoQkxUX01FTV9PRkYwLHN0cmlk
ZSAvIDIpOworCisgICAgaWYgKHBHRCAtPiBnZGZJbmRleCA9PSBHREZfXzhCSVRfSU5ERVgpIHsK
KyAgICAgICAgd3JpdGVCeXRlKEJMVF9DVFJMMSwweDAwKTsKKyAgICB9CisgICAgZWxzZSB7Cisg
ICAgICAgIHdyaXRlQnl0ZShCTFRfQ1RSTDEsMHgwMSk7CisgICAgfQorCQorICAgIC8qIEVuZ2Fn
ZSB0aGUgYmx0IGVuZ2luZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAqLworICAgIC8qIHJlY3Rhbmd1bGFyIHJlZ2lvbiBmb3Igc3JjIGFuZCBkc3QgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAqLworICAgIHdyaXRlQnl0ZShCTFRfQ1RS
TDAsMHg4MCk7CisKKyAgICAvKiB3YWl0IHVudGlsbCBjdXJyZW50IGJsaXRzIGZpbmlzaGVkICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKi8KKyAgICBFcHNvbl93YWl0X2lkbGUg
KCk7Cit9CisKKy8qLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyAqIHZpZGVvX3NldF9sdXQgLS0gCisg
Ki0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tCisgKi8KK3ZvaWQgdmlkZW9fc2V0X2x1dCAoCisgICAgdW5z
aWduZWQgaW50IGluZGV4LCAgICAgICAgICAgLyogY29sb3IgbnVtYmVyICovCisgICAgdW5zaWdu
ZWQgY2hhciByLCAgICAgICAgICAgICAgLyogcmVkICovCisgICAgdW5zaWduZWQgY2hhciBnLCAg
ICAgICAgICAgICAgLyogZ3JlZW4gKi8KKyAgICB1bnNpZ25lZCBjaGFyIGIgICAgICAgICAgICAg
ICAvKiBibHVlICovCisgICAgKQoreworICAgIHdyaXRlQnl0ZShSRUdfTFVUX0FERFIsIGluZGV4
ICk7CisgICAgd3JpdGVCeXRlKFJFR19MVVRfREFUQSwgcik7CisgICAgd3JpdGVCeXRlKFJFR19M
VVRfREFUQSwgZyk7CisgICAgd3JpdGVCeXRlKFJFR19MVVRfREFUQSwgYik7Cit9CisjaWZkZWYg
Q09ORklHX1ZJREVPX0hXX0NVUlNPUgorLyotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQorICogdmlkZW9f
c2V0X2h3X2N1cnNvciAtLSAKKyAqLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyAqLwordm9pZCB2aWRl
b19zZXRfaHdfY3Vyc29yIChpbnQgeCwgaW50IHkpCit7CisgICAgd3JpdGVCeXRlIChMQ0RfQ1VS
U09SX1hMLCAoeCAmIDB4ZmYpKTsKKyAgICB3cml0ZUJ5dGUgKExDRF9DVVJTT1JfWE0sICh4ID4+
IDgpKTsKKyAgICB3cml0ZUJ5dGUgKExDRF9DVVJTT1JfWUwsICh5ICYgMHhmZikpOworICAgIHdy
aXRlQnl0ZSAoTENEX0NVUlNPUl9ZTSwgKHkgPj4gOCkpOworfQorCisvKi0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tCisgKiB2aWRlb19pbml0X2h3X2N1cnNvciAtLSAKKyAqLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0KKyAqLwordm9pZCB2aWRlb19pbml0X2h3X2N1cnNvciAoaW50IGZvbnRfd2lkdGgsIGludCBm
b250X2hlaWdodCkKK3sKKyAgICB2b2xhdGlsZSB1bnNpZ25lZCBjaGFyICpwdHI7CisgICAgdW5z
aWduZWQgY2hhciBwYXR0ZXJuOworICAgIGludCBpOworICAgIAorCisgICAgLyogSW5pdCBjdXJz
b3IgY29udGVudAorICAgICAgIEN1cnNvciBzaXplIGlzIDY0eDY0IHBpeGVscworICAgICAgIFN0
YXJ0IG9mIHRoZSBjdXJzb3IgbWVtb3J5IGRlcGVuZHMgb24gcGFuZWwgdHlwZSAoZHVhbCBwYW5l
bCAuLi4pICAgICAqLworICAgIGlmICgoaSA9IHJlYWRCeXRlIChMQ0RfQ1VSU09SX1NUQVJUKSkg
PT0gMCkgeworICAgICAgICBwdHIgPSAodW5zaWduZWQgY2hhciAqKShzZWQxMzgwNi5mcmFtZUFk
cnMgKyBERUZBVUxUX1ZJREVPX01FTU9SWV9TSVpFIC0gSFdDVVJTT1JTSVpFKTsKKyAgICB9Cisg
ICAgZWxzZSB7CisgICAgICAgIHB0ciA9ICh1bnNpZ25lZCBjaGFyICopKHNlZDEzODA2LmZyYW1l
QWRycyArIERFRkFVTFRfVklERU9fTUVNT1JZX1NJWkUgLSAoaSAqIDgxOTIpKTsKKyAgICB9CisK
KyAgICAvKiBGaWxsIHRoZSBmaXJzdCBsaW5lIGFuZCB0aGUgZmlyc3QgZW1wdHkgbGluZSBhZnRl
ciBjdXJzb3IgICAgICAgICAgICAgKi8KKyAgICBmb3IgKGkgPSAwLCBwYXR0ZXJuID0gMDsgaSA8
IDY0OyBpKyspIHsKKyAgICAgICAgaWYgKGkgPCBmb250X3dpZHRoKSB7CisgICAgICAgICAgICAv
KiBJbnZlcnQgYmFja2dyb3VuZCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICovCisgICAgICAgICAgICBwYXR0ZXJuIHw9IDB4MzsKKyAgICAgICAgICAgIAorICAg
ICAgICB9CisgICAgICAgIGVsc2UgeworICAgICAgICAgICAgLyogQmFja2dyb3VuZCAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAqLworICAgICAgICAg
ICAgcGF0dGVybiB8PSAweDI7CisgICAgICAgIH0KKyAgICAgICAgaWYgKChpICYgMykgPT0gMykg
eworICAgICAgICAgICAgKnB0ciA9IHBhdHRlcm47CisgICAgICAgICAgICAqKHB0ciArIGZvbnRf
aGVpZ2h0ICogMTYpID0gMHhhYTsKKyAgICAgICAgICAgIHB0ciArKzsKKyAgICAgICAgICAgIHBh
dHRlcm4gPSAwOworICAgICAgICB9CisgICAgICAgIHBhdHRlcm4gPDw9IDI7CisgICAgfQorCisg
ICAgLyogRHVwbGljYXRlIHRoaXMgbGluZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICovCisgICAgZm9yIChpID0gMTsgaSA8IGZvbnRfaGVpZ2h0OyBp
KyspIHsKKyAgICAgICAgbWVtY3B5ICgodm9pZCAqKXB0ciwgKHZvaWQgKikocHRyIC0gMTYpLCAx
Nik7CisgICAgICAgIHB0ciArPSAxNjsKKyAgICB9CisgICAgCisgICAgZm9yICg7IGkgPCA2NDsg
aSsrKSB7CisgICAgICAgIG1lbWNweSAoKHZvaWQgKikocHRyICsgMTYpLCAodm9pZCAqKXB0ciwg
MTYpOworICAgICAgICBwdHIgKz0gMTY7CisgICAgfQorCisgICAgLyogU2VsZWN0IGN1cnNvciBt
b2RlICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICov
CisgICAgd3JpdGVCeXRlIChMQ0RfQ1VSU09SX0NOVEwsIDEpOworfQorI2VuZGlmCisjZW5kaWYK
ZGlmZiAtcHVyTiBwcGNib290LTIuMC4wLWN2cy9pbmNsdWRlL2NvbmZpZ3MvUlBYQ2xhc3NpYy5o
IHBwY2Jvb3QtMi4wLjAtbGNkL2luY2x1ZGUvY29uZmlncy9SUFhDbGFzc2ljLmgKLS0tIHBwY2Jv
b3QtMi4wLjAtY3ZzL2luY2x1ZGUvY29uZmlncy9SUFhDbGFzc2ljLmgJMjAwMi0xMS0yMCAxODow
NjozMS4wMDAwMDAwMDAgKzAxMDAKKysrIHBwY2Jvb3QtMi4wLjAtbGNkL2luY2x1ZGUvY29uZmln
cy9SUFhDbGFzc2ljLmgJMjAwMi0xMS0yMCAxNzowODo1OC4wMDAwMDAwMDAgKzAxMDAKQEAgLTQ3
LDEzICs0NywyNyBAQAogI3VuZGVmCUNPTkZJR184eHhfQ09OU19OT05FCiAjZGVmaW5lIENPTkZJ
R19CQVVEUkFURQkJOTYwMAkvKiBjb25zb2xlIGJhdWRyYXRlID0gOTYwMGJwcwkqLwogCi0KIC8q
IERlZmluZSBDT05GSUdfRkVDX0VORVQgdG8gdXNlIEZhc3QgZXRoZXJuZXQgaW5zdGVhZCBvZiBl
dGhlcm5ldCBvbiBTQ0MxICAgKi8KLSN1bmRlZiBDT05GSUdfRkVDX0VORVQKKyNkZWZpbmUgQ09O
RklHX0ZFQ19FTkVUCiAjaWZkZWYgQ09ORklHX0ZFQ19FTkVUCiAjZGVmaW5lIENGR19ESVNDT1ZF
Ul9QSFkgICAgICAgIDEKKyNkZWZpbmUgQ09ORklHX01JSSAgICAgICAgICAgICAgMQogI2VuZGlm
IC8qIENPTkZJR19GRUNfRU5FVCAqLwogCisvKiBWaWRlbyBjb25zb2xlIChncmFwaGljOiBFcHNv
biBTRUQxMzgwNiBvbiBFQ0NYIGJvYXJkLCBubyBrZXlib2FyZCAgICAgICAgICovCisjaWYgMQor
I2RlZmluZSBDT05GSUdfVklERU9fU0VEMTM4MDYKKyNkZWZpbmUgQ09ORklHX05FQ19OTDY0NDhC
QzIwCisjZGVmaW5lIENPTkZJR19WSURFT19TRUQxMzgwNl8xNkJQUAorCisjZGVmaW5lIENPTkZJ
R19DRkJfQ09OU09MRQorI2RlZmluZSBDT05GSUdfVklERU9fTE9HTworI2RlZmluZSBDT05GSUdf
VklERU9fQk1QX0xPR08KKyNkZWZpbmUgQ09ORklHX0NPTlNPTEVfRVhUUkFfSU5GTworI2RlZmlu
ZSBDT05GSUdfVkdBX0FTX1NJTkdMRV9ERVZJQ0UKKyNkZWZpbmUgQ09ORklHX1ZJREVPX1NXX0NV
UlNPUgorI2VuZGlmCisKICNpZiAwCiAjZGVmaW5lIENPTkZJR19CT09UREVMQVkJLTEJLyogYXV0
b2Jvb3QgZGlzYWJsZWQJCSovCiAjZWxzZQpAQCAtMTY4LDcgKzE4Miw3IEBACiAjZGVmaW5lCUNG
R19TRFJBTV9CQVNFCQkweDAwMDAwMDAwCiAjZGVmaW5lIENGR19GTEFTSF9CQVNFCTB4RkYwMDAw
MDAKIAotI2lmIGRlZmluZWQoREVCVUcpIHx8IChDT05GSUdfQ09NTUFORFMgJiBDRkdfQ01EX0lE
RSkKKyNpZiBkZWZpbmVkKERFQlVHKSB8fCBkZWZpbmVkIChDT05GSUdfVklERU9fU0VEMTM4MDYp
IHx8IChDT05GSUdfQ09NTUFORFMgJiBDRkdfQ01EX0lERSkgCiAjZGVmaW5lCUNGR19NT05JVE9S
X0xFTgkJKDI1NiA8PCAxMCkJLyogUmVzZXJ2ZSAyNTYga0IgZm9yIE1vbml0b3IJKi8KICNlbHNl
CiAjZGVmaW5lCUNGR19NT05JVE9SX0xFTgkJKDEyOCA8PCAxMCkJLyogUmVzZXJ2ZSAxMjgga0Ig
Zm9yIE1vbml0b3IJKi8KQEAgLTE5Niw3ICsyMTAsOCBAQAogI2lmIDAKICNkZWZpbmUJQ0ZHX0VO
Vl9JU19JTl9GTEFTSAkxCiAjZGVmaW5lCUNGR19FTlZfT0ZGU0VUCQkweDIwMDAwCS8qICAgT2Zm
c2V0ICAgb2YgRW52aXJvbm1lbnQgU2VjdG9yICAqLwotI2RlZmluZQlDRkdfRU5WX1NJWkUJCTB4
NDAwMAkvKiBUb3RhbCBTaXplIG9mIEVudmlyb25tZW50IFNlY3RvciAgKi8KKyNkZWZpbmUgQ0ZH
X0VOVl9TRUNUX1NJWkUgICAgICAgMHg4MDAwCisjZGVmaW5lCUNGR19FTlZfU0laRQkJMHg4MDAw
CS8qIFRvdGFsIFNpemUgb2YgRW52aXJvbm1lbnQgU2VjdG9yICAqLwogI2Vsc2UKICNkZWZpbmUg
Q0ZHX0VOVl9JU19JTl9OVlJBTSAgICAgMQogI2RlZmluZSBDRkdfRU5WX0FERFIgICAgICAgICAg
ICAweGZhMDAwMTAwCkBAIC0zNTMsNiArMzY4LDQ4IEBACiAjZGVmaW5lCUNGR19CUjRfUFJFTElN
CTB4RkEwMDA0MDEJCS8qIE5WUkFNJlNSQU0gKi8KICNkZWZpbmUgQ0ZHX09SNF9QUkVMSU0JMHhG
RkY4MDk3MAogCisvKiBFQ0NYIENTIHNldHRpbmdzICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICovCisjZGVmaW5lIFNFRDEzODA2X09SICAg
ICAgICAgICAgIDB4RkZDMDAxMDggICAgIC8qIC0gNCBNbworICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLSBCdXJzdCBpbmhpYml0CisgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtIGV4dGVybmFsIFRBICAg
ICAgICAgICAgICovCisjZGVmaW5lIFNFRDEzODA2X1JFR19BRERSICAgICAgIDB4YTAwMDAwMDAK
KyNkZWZpbmUgU0VEMTM4MDZfQUNDRVMgICAgICAgICAgMHg4MDEgICAgICAgICAgIC8qIDE2IGJp
dCBhY2Nlc3MgICAgICAgICAgICAgKi8KKworCisvKiBHbG9iYWwgZGVmaW5pdGlvbnMgZm9yIHRo
ZSBFQ0NYIGJvYXJkICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICovCisjZGVm
aW5lIEVDQ1hfQ1NSX0FERFIgICAgICAgICAgICgweGZhYzAwMDAwKQorI2RlZmluZSBFQ0NYX0NT
UjhfT0ZGU0VUICAgICAgICAoMHg4KQorI2RlZmluZSBFQ0NYX0NTUjExX09GRlNFVCAgICAgICAo
MHhCKQorI2RlZmluZSBFQ0NYX0NTUjEyX09GRlNFVCAgICAgICAoMHhDKQorCisjZGVmaW5lIEVD
Q1hfQ1NSOCAgKHZvbGF0aWxlIHVuc2lnbmVkIGNoYXIgKikoRUNDWF9DU1JfQUREUiArIEVDQ1hf
Q1NSOF9PRkZTRVQpCisjZGVmaW5lIEVDQ1hfQ1NSMTEgKHZvbGF0aWxlIHVuc2lnbmVkIGNoYXIg
KikoRUNDWF9DU1JfQUREUiArIEVDQ1hfQ1NSMTFfT0ZGU0VUKQorI2RlZmluZSBFQ0NYX0NTUjEy
ICh2b2xhdGlsZSB1bnNpZ25lZCBjaGFyICopKEVDQ1hfQ1NSX0FERFIgKyBFQ0NYX0NTUjEyX09G
RlNFVCkKKworCisjZGVmaW5lIFJFR19HUElPX0NUUkwgMHgwMDgKKworLyogRGVmaW5pdGlvbnMg
Zm9yIENTUjggICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAqLworI2RlZmluZSBFQ0NYX0VORVBTT04gICAgICAgICAgICAweDgwICAgIC8qIEJpdCAw
OgorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDA9IGRpc2FibGUg
YW5kIHJlc2V0IFNFRDEzODYKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAxPSBlbmFibGUgU0VEMTM4NiAgICAgICAgICAgICAgICAgKi8KKy8qIEJpdCAxOiAgIDA9
IFNFRDEzODYgaW4gQmlnIEVuZGlhbiBtb2RlICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgKi8KKy8qICAgICAgICAgIDE9IFNFRDEzODYgaW4gbGl0dGxlIGVuZGlhbiBtb2RlICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKi8KKyNkZWZpbmUgRUNDWF9MRSAgICAgICAg
ICAgICAgICAgMHg0MAorI2RlZmluZSBFQ0NYX0JFICAgICAgICAgICAgICAgICAweDAwCisKKy8q
IEJpdCAyLDM6IFNlbGVjdGlvbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgKi8KKy8qICAgICAgMDAgPSBEaXNhYmxlZCAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKi8KKy8qICAgICAgMDEg
PSBDUzIgaXMgdXNlZCBmb3IgdGhlIFNFRDEzODYgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgKi8KKy8qICAgICAgMTAgPSBDUzUgaXMgdXNlZCBmb3IgdGhlIFNFRDEzODYgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKi8KKy8qICAgICAgMTEgPSByZXNlcnZl
ZCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
Ki8KKyNkZWZpbmUgRUNDWF9DUzIgICAgICAgICAgICAgICAgMHgxMAorI2RlZmluZSBFQ0NYX0NT
NSAgICAgICAgICAgICAgICAweDIwCisKKy8qIERlZmluaXRpb25zIGZvciBDU1IxMiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKi8KKyNkZWZpbmUg
RUNDWF9JRCAgICAgICAgICAgICAgICAgMHgwMgorI2RlZmluZSBFQ0NYXzg2MCAgICAgICAgICAg
ICAgICAweDAxCisKIC8qCiAgKiBNZW1vcnkgUGVyaW9kaWMgVGltZXIgUHJlc2NhbGVyCiAgKi8K
ZGlmZiAtcHVyTiBwcGNib290LTIuMC4wLWN2cy9pbmNsdWRlL2RldmljZXMuaCBwcGNib290LTIu
MC4wLWxjZC9pbmNsdWRlL2RldmljZXMuaAotLS0gcHBjYm9vdC0yLjAuMC1jdnMvaW5jbHVkZS9k
ZXZpY2VzLmgJMjAwMi0xMS0yMCAxNzowNDozOS4wMDAwMDAwMDAgKzAxMDAKKysrIHBwY2Jvb3Qt
Mi4wLjAtbGNkL2luY2x1ZGUvZGV2aWNlcy5oCTIwMDItMTEtMjAgMTc6MDg6MzEuMDAwMDAwMDAw
ICswMTAwCkBAIC05OSw3ICs5OSw3IEBAIGludAlkcnZfbGNkX2luaXQgKHZvaWQpOwogI2lmZGVm
IENPTkZJR19WRkQKIGludAlkcnZfdmZkX2luaXQgKHZvaWQpOwogI2VuZGlmCi0jaWZkZWYgQ09O
RklHX1ZJREVPCisjaWYgZGVmaW5lZChDT05GSUdfVklERU8pIHx8IGRlZmluZWQoQ09ORklHX0NG
Ql9DT05TT0xFKQogaW50CWRydl92aWRlb19pbml0ICh2b2lkKTsKICNlbmRpZgogI2lmZGVmIENP
TkZJR19XTF80UFBNX0tFWUJPQVJECmRpZmYgLXB1ck4gcHBjYm9vdC0yLjAuMC1jdnMvaW5jbHVk
ZS9zZWQxMzgwNi5oIHBwY2Jvb3QtMi4wLjAtbGNkL2luY2x1ZGUvc2VkMTM4MDYuaAotLS0gcHBj
Ym9vdC0yLjAuMC1jdnMvaW5jbHVkZS9zZWQxMzgwNi5oCTE5NzAtMDEtMDEgMDE6MDA6MDAuMDAw
MDAwMDAwICswMTAwCisrKyBwcGNib290LTIuMC4wLWxjZC9pbmNsdWRlL3NlZDEzODA2LmgJMjAw
Mi0xMS0yMCAxNzowODoyNS4wMDAwMDAwMDAgKzAxMDAKQEAgLTAsMCArMSw5OCBAQAorLyoKKyAq
IChDKSBDb3B5cmlnaHQgMjAwMgorICogU3TkdWJsaSBGYXZlcmdlcyAtIDx3d3cuc3RhdWJsaS5j
b20+CisgKiBQaWVycmUgQVVCRVJUICBwLmF1YmVydEBzdGF1YmxpLmNvbQorICoKKyAqIFNlZSBm
aWxlIENSRURJVFMgZm9yIGxpc3Qgb2YgcGVvcGxlIHdobyBjb250cmlidXRlZCB0byB0aGlzCisg
KiBwcm9qZWN0LgorICoKKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2Fu
IHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IKKyAqIG1vZGlmeSBpdCB1bmRlciB0aGUgdGVybXMgb2Yg
dGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFzCisgKiBwdWJsaXNoZWQgYnkgdGhlIEZy
ZWUgU29mdHdhcmUgRm91bmRhdGlvbjsgZWl0aGVyIHZlcnNpb24gMiBvZgorICogdGhlIExpY2Vu
c2UsIG9yIChhdCB5b3VyIG9wdGlvbikgYW55IGxhdGVyIHZlcnNpb24uCisgKgorICogVGhpcyBw
cm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWws
CisgKiBidXQgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3
YXJyYW50eSBvZgorICogTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxB
UiBQVVJQT1NFLiAgU2VlIHRoZQorICogR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9yIG1v
cmUgZGV0YWlscy4KKyAqCisgKiBZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5IG9mIHRo
ZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZQorICogYWxvbmcgd2l0aCB0aGlzIHByb2dyYW07
IGlmIG5vdCwgd3JpdGUgdG8gdGhlIEZyZWUgU29mdHdhcmUKKyAqIEZvdW5kYXRpb24sIEluYy4s
IDU5IFRlbXBsZSBQbGFjZSwgU3VpdGUgMzMwLCBCb3N0b24sCisgKiBNQSAwMjExMS0xMzA3IFVT
QQorICovCisvKiBWaWRlbyBzdXBwb3J0IGZvciBFcHNvbiBTRUQxMzgwNiBjaGlwc2V0ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICovCisKKworI2lmbmRlZiBfU0VEMTM4MDZfSF8K
KyNkZWZpbmUgX1NFRDEzODA2X0hfCisKKworLyogR2VuZXJhbCBkZWZpbml0aW9ucyAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAqLworI2RlZmlu
ZSBGUkFNRV9CVUZGRVJfT0ZGU0VUICAgICAgICAweDIwMDAwMCAgICAgLyogRnJhbWUgYnVmZmVy
IG9mZnNldCAqLworI2RlZmluZSBUT1RBTF9TUEFDRV9TSVpFICAgICAgICAgICAweDQwMDAwMAor
CisjZGVmaW5lIERFRkFVTFRfVklERU9fTUVNT1JZX1NJWkUgIDB4MTQwMDAwICAgICAvKiBWaWRl
byBNZW1vcnkgU2l6ZSAqLworCisjZGVmaW5lIEhXQ1VSU09SU0laRSAJCSAgIDEwMjQgICAgIC8q
IFNpemUgb2YgbWVtb3J5IHJlc2VydmVkCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBmb3IgSFcgY3Vyc29yKi8gCisKKy8qIE9mZnNldCBvZiBjaGlw
c2V0IHJlZ2lzdGVycyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgKi8KKyNkZWZpbmUJQkxUX0NUUkwwCSgweDAxMDApCisjZGVmaW5lCUJMVF9DVFJMMQkoMHgw
MTAxKQorI2RlZmluZSBCTFRfUk9QCQkoMHgwMTAyKQorI2RlZmluZQlCTFRfT1AJCSgweDAxMDMp
CisjZGVmaW5lIEJMVF9TUkNfQUREUjAJKDB4MDEwNCkKKyNkZWZpbmUJQkxUX1NSQ19BRERSMQko
MHgwMTA1KQorI2RlZmluZQlCTFRfU1JDX0FERFIyCSgweDAxMDYpCisjZGVmaW5lCUJMVF9EU1Rf
QUREUjAJKDB4MDEwOCkKKyNkZWZpbmUgQkxUX0RTVF9BRERSMQkoMHgwMTA5KQorI2RlZmluZQlC
TFRfRFNUX0FERFIyCSgweDAxMEEpCisjZGVmaW5lIEJMVF9NRU1fT0ZGMAkoMHgwMTBDKQorI2Rl
ZmluZSBCTFRfTUVNX09GRjEJKDB4MDEwRCkKKyNkZWZpbmUgQkxUX1dJRFRIMAkoMHgwMTEwKQor
I2RlZmluZSBCTFRfV0lEVEgxCSgweDAxMTEpCisjZGVmaW5lIEJMVF9IRUlHSFQwCSgweDAxMTIp
CisjZGVmaW5lIEJMVF9IRUlHSFQxCSgweDAxMTMpCisjZGVmaW5lCUJMVF9CR0NPTE9SMAkoMHgw
MTE0KQorI2RlZmluZQlCTFRfQkdDT0xPUjEJKDB4MDExNSkKKyNkZWZpbmUJQkxUX0ZHQ09MT1Iw
CSgweDAxMTgpCisjZGVmaW5lIEJMVF9GR0NPTE9SMQkoMHgwMTE5KQorCisjZGVmaW5lIEJMVF9S
RUcgICAgICAgICAoMHgxMDAwMDApCisKKy8qIExvb2t1cCB0YWJsZSByZWdpc3RlcnMgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKi8KKyNkZWZpbmUg
UkVHX0xVVF9BRERSIDB4MWUyCisjZGVmaW5lIFJFR19MVVRfREFUQSAweDFlNAorCisvKiBDdXJz
b3IvSW5rIHJlZ2lzdGVycyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICovCisjZGVmaW5lIExDRF9DVVJTT1JfQ05UTCAgICAgICAgICgweDAwNzAp
CisjZGVmaW5lIExDRF9DVVJTT1JfU1RBUlQgICAgICAgICgweDAwNzEpCisjZGVmaW5lIExDRF9D
VVJTT1JfWEwgICAgICAgICAgICgweDAwNzIpCisjZGVmaW5lIExDRF9DVVJTT1JfWE0gICAgICAg
ICAgICgweDAwNzMpCisjZGVmaW5lIExDRF9DVVJTT1JfWUwgICAgICAgICAgICgweDAwNzQpCisj
ZGVmaW5lIExDRF9DVVJTT1JfWU0gICAgICAgICAgICgweDAwNzUpCisjZGVmaW5lIExDRF9DVVJT
T1JfQ09MMF9CICAgICAgICgweDAwNzYpCisjZGVmaW5lIExDRF9DVVJTT1JfQ09MMF9HICAgICAg
ICgweDAwNzcpCisjZGVmaW5lIExDRF9DVVJTT1JfQ09MMF9SICAgICAgICgweDAwNzgpCisjZGVm
aW5lIExDRF9DVVJTT1JfQ09MMV9CICAgICAgICgweDAwN0EpCisjZGVmaW5lIExDRF9DVVJTT1Jf
Q09MMV9HICAgICAgICgweDAwN0IpCisjZGVmaW5lIExDRF9DVVJTT1JfQ09MMV9SICAgICAgICgw
eDAwN0MpCisjZGVmaW5lIExDRF9DVVJTT1JfRklGTyAgICAgICAgICgweDAwN0UpCisKK3R5cGVk
ZWYgc3RydWN0Cit7CisgICAgdW5zaWduZWQgc2hvcnQgICAgICBJbmRleDsKKyAgICB1bnNpZ25l
ZCBjaGFyICAgICAgIFZhbHVlOworfSBTMURfUkVHUzsKKworCisKKy8qIEJvYXJkIHNwZWNpZmlj
IGZ1bmN0aW9ucyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgKi8KK3Vuc2lnbmVkIGludCBib2FyZF92aWRlb19pbml0ICh2b2lkKTsKK3ZvaWQgYm9hcmRf
dmFsaWRhdGVfc2NyZWVuICh1bnNpZ25lZCBpbnQgYmFzZSk7Citjb25zdCBTMURfUkVHUyAqYm9h
cmRfZ2V0X3JlZ3MgKHZvaWQpOworaW50IGJvYXJkX2dldF93aWR0aCAodm9pZCk7CitpbnQgYm9h
cmRfZ2V0X2hlaWdodCAodm9pZCk7CisKKyNlbmRpZiAvKiBfU0VEMTM4MDZfSF8gKi8KZGlmZiAt
cHVyTiBwcGNib290LTIuMC4wLWN2cy90b29scy9ta2ltYWdlLmMgcHBjYm9vdC0yLjAuMC1sY2Qv
dG9vbHMvbWtpbWFnZS5jCi0tLSBwcGNib290LTIuMC4wLWN2cy90b29scy9ta2ltYWdlLmMJMjAw
Mi0xMS0yMCAxODoyNToyNy4wMDAwMDAwMDAgKzAxMDAKKysrIHBwY2Jvb3QtMi4wLjAtbGNkL3Rv
b2xzL21raW1hZ2UuYwkyMDAyLTExLTIwIDE4OjI0OjM3LjAwMDAwMDAwMCArMDEwMApAQCAtMjUw
LDcgKzI1MCw3IEBAIE5YVEFSRzoJCTsKIAkgKi8KIAlpZiAoeGZsYWcpIHsKIAkJaWYgKGVwICE9
IGFkZHIgKyBzaXplb2YoaW1hZ2VfaGVhZGVyX3QpKSB7Ci0JCQlmcHJpbnRmIChzdGRlcnIsICIl
czogRm9yIFhJUCwgdGhlIGVudHJ5IHBvaW50IG11c3QgYmUgdGhlIGxvYWQgYWRkciArICVkXG4i
LAorCQkJZnByaW50ZiAoc3RkZXJyLCAiJXM6IEZvciBYSVAsIHRoZSBlbnRyeSBwb2ludCBtdXN0
IGJlIHRoZSBsb2FkIGFkZHIgKyAlbHVcbiIsCiAJCQkJY21kbmFtZSwgc2l6ZW9mKGltYWdlX2hl
YWRlcl90KSk7CiAJCQlleGl0IChFWElUX0ZBSUxVUkUpOwogCQl9Cg==
--------------3E16665E1CF41E464E400FD0--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
Note that I added a ".1" (default) or ".2" modifier to the chip internal
address (offset). This allows you to use one byte addresses or two byte
addresses in the same system and without the _X mess.
----------
Examples:
Dumping 256 bytes from the SPD on a DIMM:
=> imd 57 0 100
0000: 12 00 00 00 00 00 00 00 00 00 00 11 00 00 00 22 ..............."
0010: 00 00 00 05 00 00 00 06 00 00 00 07 00 00 00 08 ................
0020: 00 00 00 09 00 00 00 00 00 00 00 01 00 00 00 02 ................
0030: 00 00 00 03 00 00 00 04 00 00 00 05 00 00 00 06 ................
0040: 00 00 00 07 00 00 00 08 00 00 00 09 00 00 00 00 ................
0050: 00 00 00 01 00 00 00 02 00 00 00 03 00 00 00 04 ................
0060: 00 00 00 05 00 00 00 06 00 00 00 07 00 00 00 08 ................
0070: 00 00 00 09 00 00 00 00 ff ff ff ff 00 00 00 01 ................
0080: 00 00 00 02 00 00 00 03 00 00 00 04 00 00 00 05 ................
0090: 00 00 00 06 00 00 00 07 00 00 00 08 00 00 00 09 ................
00a0: 00 00 00 00 00 00 00 01 00 00 00 02 00 00 00 03 ................
00b0: 00 00 00 04 00 00 00 05 00 00 00 06 00 00 00 07 ................
00c0: 00 00 00 08 00 00 00 09 00 00 00 00 00 00 00 01 ................
00d0: 00 00 00 02 00 00 00 03 00 00 00 04 00 00 00 05 ................
00e0: 00 00 00 06 00 00 00 07 00 00 00 08 00 00 00 09 ................
00f0: 00 00 00 00 00 00 00 01 00 00 00 02 00 00 00 03 ................
Changing a few bytes...
=> imm 80
Usage:
imm - i2c memory modify (auto-incrementing)
=> imm 50 80
00000080: ff ? 12
00000081: ff ? 34
00000082: ff ? 56
00000083: ff ? 78
00000084: ff ? .
Dumping byte data:
imd.b e 81 e
imd.b f 81 e
imd.b 11 81 5
Old emails that might help...
To: ppcboot-users at lists.sourceforge.net
From: Jerry Van Baren <vanbaren_gerald@si.com>
Date: Wed, 23 Jan 2002 07:07:50 -0500
Good morning everybody,
This message is being sent in two parts to (hopefully) squeeze it under the
40K limit of the list server. I sent it yesterday in one part: the
moderator (Wolfgang?) has not released the oversize message. Wolfgang is
out of town and I'm impatient :-/.
----------------------------------------------------------------
Attached are some I2C patches that I've been working on. This set of
patches does two things:
1) Rationalize the i2c interface for the 8260, 8xx, and 4xx CPUs: all of
them get the same interface, eliminating the horrible #ifdef cancer that
was growing.
2) Create a generic soft_i2c.c in the /common directory that is configured
by changing #defines in the board configuration file. This replaces the
soft_i2c.c in the cpu/8xx and cpu/8260 subdirectories.
3) Creates a new set of commands that imitate the regular memory peek/poke
commands: imd for I2C memory display, imm for I2C mem mod, imw, etc. IMHO
this alone is worth the price of admission. The syntax of the commands is:
imd {i2c_chip} {addr}{.1, .2} {len}
imw {i2c_chip} {addr}{.1, .2} {data} [{count}]
icrc32 {i2c_chip} {addr}{.1, .2} {count}
imm {i2c_chip} {addr}{.1, .2}
inm {i2c_chip} {addr}{.1, .2}
iloop {i2c_chip} {addr}{.1, .2} [{length}] [{delay}]
Note that I added a ".1" (default) or ".2" modifier to the chip internal
address (offset). This allows you to use one byte addresses or two byte
addresses in the same system and without the _X mess.
4) New I2C commands:
iprobe {addr} - goes through all chip addresses, prints all chips
that respond
isdram {i2c_chip} - Dumps the SDRAM SPD memory in human readable form
5) Improved the hardware 8260 I2C driver, especially with respect to
timeouts. The hardware 8xx I2C driver could probably benefit from this as
well, but I don't have a 8xx system to test on.
6) The imd & friends really obsolete cmd_eeprom.c, but I patched it over
for backwards compatibility. I thought about putting a pester printf in it
for the I2C branch ("This command is obsolete, please use imd/imm/imw,
etc.\n") but didn't. Discussion and advice on how to handle command
obsolescence would be welcome.
--------
This should be a clean patch against the latest PPCBoot, although I did not
test that.
What I need help with is:
1) Testing the 8xx code (should be OK, but it is untested)
2) Testing the 4xx code (a little shakier, I'm less familiar with the 4xx)
3) Figure out what to do with the ICU862 with its Xicor X40430 I2C EEPROM:
I downloaded the X40430 spec sheet but had problems reconciling the spec
sheet to the code and ended up not doing anything with the memory
lock/unlock code. This is currently BROKEN.
Notes:
------
Attachment: ppcboot/common/soft_i2c.c.gz - new file.
Part 2 attachment: patch.gz - patches against latest PPCBoot.
* The "soft_i2c.c" routines under the 8xx and 8260 cpu subdirectories are
made obsolete by the new one in common. The new one is generic, configured
by #defines in the board configuration.
gvb
To: Wolfgang Denk <wd@denx.de>, andrew may <acmay@acmay.homeip.net>
From: Jerry Van Baren <vanbaren_gerald@si.com>
Date: Wed, 30 Jan 2002 07:38:11 -0500
Attached are my latest i2c patches. I added in some of Andrews
suggestions, primarily the [.bwl] attribute on the imm and inm commands. I
also removed the gratuitous calls to i2c_init() in some of the i2c read
(transfer) routines. Hopefully start up routines call i2c_init() properly
before trying to read i2c -- if they don't, I would consider that to be a
bug and should be fixed.
I did _not_ include Andrew's patch reading the environment variable to
determine the I2C speed.
In the tarball, I included common/soft_i2c.c which is new and a clean copy
of common/cmd_i2c.c which is totally different from the original (current
PPCBoot version), making the patch file for it pretty tough to read :-).
gvb
**********************************************************************
This e-mail and any files transmitted with it are confidential and may
be legally privileged or otherwise exempt from disclosure under
applicable law. This e-mail and its files are intended solely for
the individual or entity to whom they are addressed and their content
is the property of Smiths Aerospace. If you are not the intended
recipient, please do not read, copy, use or disclose this communication.
If you have received this e-mail in error please notify the e-mail
administrator at postmaster at si.com and then delete this e-mail, its
files and any copies.
This footnote also confirms that this e-mail message has been scanned
for the presence of known computer viruses.
***********************************************************************
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
"The instruction side and data side can share a 64MB address space, or each
can have its own 64MB address space. The address spaces are fully
relocatable on 64MB boundaries within the 4GB address space of the
PPC405GPr, but the programmer must assign OCM address space to avoid
conflicts with other assigned addresses."
My address map shows space from 0000 0000 to E7FF FFFF as 'General Use.'
This space is where most relocatable devices can be placed.
The DCU (Data Cache Unit) is controllable; but not directly addressable.
So if I read correctly, the OCM for the 405GP is not a function of how the
board is "wired", but how I set it up programmatically. However it seems
that you are indicating that it depends on the design of my board. Can
you please help provide clarification.
Thanks
Jerry
-----Original Message-----
From: wd@denx.de [mailto:wd at denx.de]
Sent: Sunday, January 05, 2003 3:46 PM
To: jwalden at digitalatlantic.com
Cc: u-boot-users at lists.sourceforge.net
Subject: Re: [U-Boot-Users] PPC405GP - uboot - can't get past stackloop
In message <EGEGIJHKDKJGAJMGIDPNMEAHCEAA.jwalden@digitalatlantic.com> you
wrote:
> Yes - you are absolutly correct.
Been there myself often enough before ;-)
> Somewhere after about 1000 iterations of placing 0xdeaddead into what is
> supposed to be the temporary stack frame, I get a machine exception.
>
> So - now I know my memory is not configured correctly. My hardware guy is
Probably not your _memory_.
> not
> here, however I see that he has defined 64MB starting at 0x70000000.
Ignore that. RAM should always start at 0x0000.
> However if
> I change the value in my config file (CFG_INIT_RAM_ADDR) from 0x4000000 to
> 0x7000000
Be careful! The initial memory is NOT in RAM!!! It used the data
cache or OCM - don't know the design of your board. If in doubt, use
the data cache.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
This all sounds complicated, but it mostly does excatly what you ex-
pect. It's just difficult for us to explain what you expect...
- L. Wall & R. L. Schwartz, _Programming Perl_
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
file send options. On the u-boot side I first get the recieve side
ready, and then I do a kermit send.
If I were like Wolfgang I would strongly admonish you
to read the README file in the u-boot source under /tools/scripts/readme -
however I'm not Wolfgang ;-)
Jerry Walden
-----Original Message-----
From: u-boot-users-admin@lists.sourceforge.net
[mailto:u-boot-users-admin at lists.sourceforge.net]On Behalf Of Robert
Schwebel
Sent: Tuesday, March 18, 2003 3:26 PM
To: U-Boot Mailing List
Subject: [U-Boot-Users] Minicom for image download
Hi,
does anybody use minicom for serial image downloads? If yes, how?
Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Braunschweiger Str. 79, 31134 Hildesheim, Germany
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Phone: +49-5121-28619-0 | Fax: +49-5121-28619-4
-------------------------------------------------------
This SF.net email is sponsored by: Does your code think in ink?
You could win a Tablet PC. Get a free Tablet PC hat just for playing.
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
that the generic code in common/cmd_pcmia.c relies on types which
are only defined in asm_ppc headers and that the code makes use
of m8xx functions directly which would kind of suggest that the
pcmcia code has never been compiled for arm? Is this right?
I'd thought that u-boot was derived from ppc-boot and arm-boot and
arm boot claims to support booting from compact flash on it's
sourceforge homepage. So was arm functionality dropped when
u-boot was formed or do I misunderstand the lineage of u-boot
entirely???
_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
Thanks,
Frank.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
Configuration depends on the combination of board and CPU type; all
such information is kept in a configuration file
"include/configs/<board_name>.h".
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
Have any of you got the Abatron tftpsrv to work with u-boot. If yes, how
did you do it? If no, do you know of any other tftp servers that run
under Windows and work with u-boot?
Best regards
Rune Raknerud
Cargoscan AS
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
rarp 0xc0008000
bootm
The trouble is that it starts executing at 0xc0008000 which is the
image header.
Based on reading the README, I'm suspicious that I've misconstrued the
load addresses and that the loader doesn't support uncompressed
images.
Any tips?
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
memory commands like "md" should accept (optional) data size parameter
(.b/.w/.l) as the first parameter.
How do you enable this? In my environment they don't work: 1) argv[0] is
the command itself (like "md"), not the data size parameter from where the
source tries to read it and 2) if I give the data size parameter, the
upper framework counts the amount of parameters to be illegal and
therefore certain commands give me an error message (the short usage).
I suppose there is a #define missing? What is it? I could not quickly find
it grepping the source, googling the net / mailing list archives.
Best Regards,
Pasi Huhtiniemi
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
moderating, and likely applies similar logic for submission. He is probably
is a bit more stringent in certain areas as the code would become more
difficult to maintain with out some control.
Regards,
Richard W.
> -----Original Message-----
> From: wd at denx.de [mailto:wd at denx.de]
> Sent: Monday, November 03, 2003 9:40 AM
> To: Stephan Linz
> Cc: Woodruff, Richard; u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] [PATCH-1/2] LAN91C111
>
>
> Dear Stephan,
>
> in message <0311031553480Q.02205@pcj86> you wrote:
> >
> > I'm curious about it. When your test phase / cross check
> has success
> > what is
> > the next step to put in this patch into U-Boot CVS
> repository? I need a time
> > line to plan my further jobs.
>
> Please allow for a couple of days - Richard needs some
> time for testing, and I won;t find time to check anything
> in before Thursday anyway. If by then nobody complained I
> will check in your patches - thanks for it.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> Software Engineering: Embedded and Realtime Systems, Embedded Linux
> Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email:
> wd at denx.de Remember, there's a big difference between
> kneeling down and bending
> over. - Frank Zappa
>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
wouldn't complain if it isn't as the code is correct.
Regards,
Richard W.
> -----Original Message-----
> From: u-boot-users-admin at lists.sourceforge.net
> [mailto:u-boot-users-admin at lists.sourceforge.net] On Behalf
> Of George G. Davis
> Sent: Wednesday, December 03, 2003 9:33 AM
> To: Cam
> Cc: u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] tiny patch for examples/Makefile
> (objcopy related)
>
>
>
>
> Cam wrote:
> > Hello u-boot-users,
> >
> > Here is a short patch for the examples/Makefile. This improves
> > reliability in the case of a deficient toolchain.
> >
> > For example the MontaVista (pro 3.0) ppc_82xx objcopy does
> not accept
> > srec input, and produces an empty output file which can
> confuse make.
>
> Yep, I had noticed this long ago too. Why not just add "-I
> srec" as in the attached?
>
> --
> Regards,
> George
>
> >
> > This patch ensures that the binary image is produced from
> the elf file
> > and not the srec file, which allows a clean build.
> >
> > -Cam
> >
> > PS. MontaVista have 'no general interest in supporting srec input'
> > because of 'how little information srec files contain'.
> >
> >
> >
> ----------------------------------------------------------------------
> > --
> >
> > diff -urN u-boot-1.0.0.orig/examples/Makefile
> u-boot-1.0.0/examples/Makefile
> > --- u-boot-1.0.0.orig/examples/Makefile 2003-10-14
> 20:43:56.000000000 +0100
> > +++ u-boot-1.0.0/examples/Makefile 2003-12-03
> 11:21:04.000000000 +0000
> > @@ -104,7 +104,7 @@
> > $(OBJCOPY) -O srec $(<:.o=) $@
> >
> > %.bin: %.srec
> > - $(OBJCOPY) -O binary $< $@ 2>/dev/null
> > + $(OBJCOPY) -O binary $(<:.srec=) $@ 2>/dev/null
> >
> >
> >
> ##############################################################
> ###########
> >
>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
not responding to anything
I have what i believe to be the correct environment.
baudrate=38400
ethaddr=00:a0:13:00:0a:8c
preboot=echo;echo
clocks_in_mhz=1
kernel_addr=a0100000
bootargs=root=/dev/nfs rw nfsroot=$(serverip):$(rootpath)
ip=$(ipaddr):$(serveri
p):$(gatewayip):$(netmask):$(hostname)::off
bootcmd=bootm a0100000
filesize=9b949
ipaddr=168.10.10.6
serverip=168.10.1.240
stdin=serial
stdout=serial
stderr=serial
Environment size: 340/4092 bytes
I have a number of questions about the interaction with u-boot and the
kernel, which i am hoping can be answered.
Does the kernel require configuration for custom hardware ? By custom
hardware i mean not an off shelf the standard development board.
How does the kernel find out the flash base address. serial port is running
at 38k4 on smc1, the FEC is to be used. IP address etc etc ?
Thanks in Advance
Steve Gray
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
working.
and so far ive spent 2days trying to hand control from u-boot to the linux
kernel.
In my opinion you should not use your vxWorks BSPs. the features in u-boot
are far better
than those we have in our vxWorks BSP.
You use alot of the values from your vxWorks for example the UPM tables.
The chip selects etc etc.
Just plug in those values from your vxWorks bsp into custom board u-boot
"bsp"
you should find you can get it running very quickly.
-----Original Message-----
From: David Aldrich [mailto:david.aldrich at t-modus.nec.co.uk]
Sent: 10 December 2003 11:00
To: 'u-boot-users at lists.sourceforge.net'
Subject: [U-Boot-Users] Linux port for MPC855T
Hi
I have newly subscribed to this mailing list. I notice that neither the
ppcboot nor the uboot lists are presently archived on Sourceforge, so I
cannot see how active the lists are. I wish to discuss Linux BSPs for
MPC855T. Is the uboot list appropriate for such discussion?
I am evaluating the use of Embedded Linux on MPC860 PowerPC,
specifically the MPC855T. I am currently requesting quotations from
Linux suppliers to port Linux to our 855T card. Currently, we run
VxWorks on this card so a VxWorks BSP is fully tested.
I know that a major part of the port will be programming the 855T's UPM
(User Programmable Machine) that is responsible for setting up memory
controller, CPU core etc. I would like advice on how to handle this.
- Should such setup be already available in an open source Linux MPC860
BSP?
- Should I try to make use of our existing BSP?
- Is it reasonable for the supplier to quote for BSP development or
should they be using open source code?
I will be grateful for any advice, as this is a very new area for me.
Best regards
David
Telecom MODUS is an ISO9001/TickIT approved Company.
LRQA Certificate of Approval reference 0965133
************************************************************
THIS MESSAGE IS INTENDED ONLY FOR THE USE OF THE INDIVIDUAL TO WHOM IT IS
ADDRESSED AND CONTAINS INFORMATION THAT IS PRIVATE AND/OR PROPRIETARY.
If the reader of this message is not the intended recipient, or the employee
or agent responsible for delivering the message to the intended recipient,
you are hereby notified that any dissemination, distribution or copying of
this communication is strictly prohibited.
If you have received this communication in error, please forward the whole
message to admin at t-modus.nec.co.uk
Company Registration No.3493954
Telephone Number +44 (0) 1372 381880
Fax Number +44 (0) 1372 381804
Email general at t-modus.nec.co.uk
************************************************************
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
total_size = vmlinux.gz size + ramdisk.image.gz size + sizeof(image_header_t)
----- Forwarded message from tguilliams at synergy.synergymicro.com -----
Sender: u-boot-users-admin at lists.sourceforge.net
Message-ID: <20040217234810.GA3573@raptor.synergymicro.com>
User-Agent: Mutt/1.5.6i
Date: Tue, 17 Feb 2004 15:48:10 -0800
From: tguilliams@synergy.synergymicro.com
To: u-boot-users at lists.sourceforge.net
Subject: [U-Boot-Users] mkimage file size extraction?
I'm trying to retrieve a U-Boot multi-image from a Linux MTD flash partition. I'm not sure, without knowing the file size of the image there, how to make sure I retrieve the image alone and not the entire partition.
My U-Boot question is -
Is there a way I can extract _just_ the data size from the U-Boot wrapper header info?
i.e.,
make[2]: Leaving directory `/home/tomg/eldk/eldk-sbs/0.2/work/linux/linuxsbs-2.4.20/arch/ppc/boot/images'
./utils/mkimage.wrapper -A ppc -O linux -T multi -C gzip -a 00000000 -e 00000000 \
-n 'Linux-2.4.20 w/ ramdisk' \
-d images/vmlinux.gz:images/ramdisk.image.gz images/vmlinux.initrd.UBoot
Image Name: Linux-2.4.20 w/ ramdisk
Created: Tue Feb 17 15:33:45 2004
Image Type: PowerPC Linux Multi-File Image (gzip compressed)
Data Size: 4524955 Bytes = 4418.90 kB = 4.32 MB
Load Address: 0x00000000
Entry Point: 0x00000000
Contents:
Image 0: 823267 Bytes = 803 kB = 0 MB
Image 1: 3701675 Bytes = 3614 kB = 3 MB
I'm thinking of some operations using "dd" to seek and copy the data size to a file or something.
If this is not possible, I will quickly try and write a Linux NVRAM driver for U-Boot environmentals so that I can set a variable to retain the file image size.
Any ideas are greatly appreciated.
--
Tom G.
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
----- End forwarded message -----
--
Tom Guilliams
tguilliams at synergymicro.com
858.452.0020 x471
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
Thanks again,
Dave
Wolfgang Denk <wd@denx.de> wrote:
<
< In message <1077551762.4835.50.camel@nios> you wrote:
< > I'm far from an expert on the matter ;)
< > But I would try to set the addresses to 0x30000000 then. The kernel will
<
< This depends on how the kernel was linked.
<
< > be expanded to RAM first and then a jump will be made to the address in
< > the RAM to start executing the kernel.
< >
< > In my situation, I used 0x0 as start/entry. RAM starts on that address
< > too.
<
< This is correct on PowerPC, but wrong on all other systems.
<
< The address to be used is defined in the Linux kernel's linker
< commands / scripts; seach which value of PTEXTADDR gets defined in
< "arch/arm/Makefile" for your board; in your "arch/arm/boot/Makefile"
< you should then have a build target like this:
<
< uImage: compressed/piggy.gz
< mkimage -A arm -O linux -T kernel -C gzip \
< -a $(PTEXTADDR) -e $(PTEXTADDR) \
< -n 'ARM Linux-$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)' \
< -d compressed/piggy.gz $@
<
<
< Best regards,
<
< Wolfgang Denk
<
< --
< Software Engineering: Embedded and Realtime Systems, Embedded Linux
< Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
< It may be that your whole purpose in life is simply to serve as a
< warning to others.
<
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
one.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
God may be subtle, but He isn't plain mean. - Albert Einstein
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
until the IDE support was added. May be that was just a coincidence,
but it seems obvious to me that something changed in U-Boot recently
that broke the FEC driver. It is possible that "something" was not
the IDE support in fact, but yet something else.
The MII initialization code used to work fine for us, as far as we
were able to tell. Without having investigated this more closely, I
will not check in this patch as I feel it might just fix some
symptoms.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
Mirrors should reflect a little before throwing back images.
- Jean Cocteau
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
c0162030 D init_task_union
Without fully understanding this, this sounds like my stack isn't getting
set up correctly. Is that U-Boot's responsibility? Any pointers as to where
I'd start looking at that?
Thanks
Jeff
--
Jeff Tucker
jeff at jltnet.com
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
ethernet dirver.
If I do a ping, all netRxPackets are inited to proper
values, and everything works fine.
Thanks
Dave.
--- Wolfgang Denk <wd@denx.de> wrote:
> Dear Dave,
>
> in message
> <20040412213638.57633.qmail@web21412.mail.yahoo.com>
> you wrote:
> >
> > I have 8260 based board and am using u-boot for
> that.
> > I boot kernel from the flash. All works fine
> however
> > sometimes Linux Kernel does not boot after
> > uncompressing, further investigation found that as
> the
> > kernel entry point is address 0, and that is also
> > address of netRxPackets, if a packet is received
> after
>
> You are wrong here. NetRxPackets[] is definitely
> NOT located at
> address 0.
>
> > the kernel is unzipped by u-boot, ethernet driver
> > corrupts data at address 0 thinking it as its
> buffer
> > pointer. Hence kernel does not boot up in that
> case.
>
> No, no, no.
>
> > My first question is that why we dont initialize
> > netRxPackets in net.c?? (these are only
> initialized
> > once a network related operation (like ping) is
> done).
>
> U-Boot uses the network only when a network related
> operation is in
> progress, so why should we waste memory for buffers
> when they are not
> needed?
>
> > Is this the corect behaviour?? has anyone
> observed
> > this problem??
>
> This is correct behaviour. It works perfectly find
> on all boards I
> was able to test.
>
> You are on the wrong track.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> Software Engineering: Embedded and Realtime
> Systems, Embedded Linux
> Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88
> Email: wd at denx.de
> You got to learn three things. What's real, what's
> not real, and
> what's the difference." - Terry Pratchett,
> _Witches Abroad_
>
>
>
-------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux
> Tutorials
> Free Linux tutorial presented by Daniel Robbins,
> President and CEO of
> GenToo technologies. Learn everything from
> fundamentals to system
>
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
>
https://lists.sourceforge.net/lists/listinfo/u-boot-users
__________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online by April 15th
http://taxes.yahoo.com/filing.html
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
problem with your tools and options.
> /opt/work/fw/bootloader/u-boot-1.0.0.work/cpu/mips/start.S: Assembler
> messages:
> /opt/work/fw/bootloader/u-boot-1.0.0.work/cpu/mips/start.S:242: Error:
> Cannot branch to undefined symbol.
> /opt/work/fw/bootloader/u-boot-1.0.0.work/cpu/mips/start.S:247: Error:
> Cannot branch to undefined symbol.
> /opt/work/fw/bootloader/u-boot-1.0.0.work/cpu/mips/start.S:259: Error:
> Cannot branch to undefined symbol.
>
> I guess gcc 3.3.1 doesn't like the option "-mcpu=" nor branch-and-link to
> undefined symbols anymore. AFAIK the toolchain Masami recommended is
> verson
> 2.96.x
there should be no undefined symbols in the start.S file in the first
place; at least there are none for the boards and tools we use for
testing.
> Wonder if anyone out there has ever tried gcc 3.3.x for compiling a
> MIPS U-Boot (big or little-endian)?
We (DENX) didn't.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
Real computer scientists don't comment their code. The identifiers
are so long they can't afford the disk space.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
- What CPU Architecture is being targeted?
(ARM, MIPS, PPC, Xscale, etc)
- Given the CPU Architecture is now known, which processor
is being selected? This might involve an intermediate step
in which a "family" of processors might be selected to help
narrow the selection. For example, maybe it is OK to just
offer the 7 XSCALE processors directly (ixdp425, xm250, etc),
while the prolific PPC might do a PPC4xx, 82xx, 85xx, etc
selection for family in order to get to a specific cpu
such as the mpc8540.
- What board is being targeted?
(ADS, CDS, IceCube, etc)
Basically anything in u-boot/boards that is appropriate
for the given target CPU Arch or specific CPU.
I think that one of the key factors where a new configuration
system could win, in general, is in "enforcing bad combinations".
One component that would get encoded into the config files would
be, for example, the knowledge of what CPUs are supported on
which boards.
> For me, the following topics are important:
>
> * clearness and readability of the resulting code / config files;
> this includes having all relevant information for one board
> concentrated in very few well known files.
Could I ask you to clarify this point a bit, please? I'd like to
understand what your concern here is. In particular, I think that
there is a bit more of a "cross product of features" available and
that some degree of horizontal slicing rather than vertical slicing
of the options might be needed. In that way, it is not so much tied
to a particular board.
Thinking out loud still.
Thanks,
jdl
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
goose bumps all over my neck - this is something I will not accept.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
Any sufficiently advanced technology is indistinguishable from magic.
- Arthur C. Clarke
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
the DIP switch that swaps the boot mode from flash=CS3 to flash=CS0. It's
not a very good name, and on other boards that do the same it is also
referred to as "fast boot" and "arm boot" none of which are terribly
descriptive or useful...
Best Wishes,
~Pev
---------------------------------------------------------------------------
Dave Peverley, Software Engineer, MPC Data Limited.
Phone : [+44] (0) 1225 868 228 Web : http://www.mpc-data.co.uk
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
one installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
------_=_NextPart_000_01C450BD.2736A470
Content-Type: application/octet-stream;
name="CLLF_CREDITCARDS.cfg"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="CLLF_CREDITCARDS.cfg"
; CLLF BW31, credit cards=0A=
; -----------------------=0A=
;written by Steven Blakeslee 2002=0A=
;=0A=
[INIT]=0A=
; init core register=0A=
WSPR 638 0xfa200000 ;;IMMR: internal memory at =
0xFA200000=0A=
;=0A=
; init SIU register=0A=
WM32 0xFA200004 0xffff0689 ;;SYPCR: enable bus monitor, =
disable software watchdog=0A=
WM32 0xFA200280 0x62000000 ;;SCCR: disable clock output=0A=
WM32 0xFA200284 0x0050d000 ;;PLPRCR: clear flags=0A=
;=0A=
; init UPM=0A=
SUPM 0xFA200168 0xFA20017C ;Set address for MCR and MDR=0A=
;=0A=
WUPM 0x00000000 0xcfffcc24 ;UPM: singel read=0A=
WUPM 0x00000001 0x0fffcc04 ;UPM: singel read=0A=
WUPM 0x00000002 0x0cafcc04 ;UPM: singel read=0A=
WUPM 0x00000003 0x03afcc08 ;UPM: singel read=0A=
WUPM 0x00000004 0x3fbfcc27 ;UPM: singel read=0A=
WUPM 0x00000005 0xffffcc25 ;UPM: singel read=0A=
WUPM 0x00000006 0xffffcc25 ;UPM: singel read=0A=
WUPM 0x00000007 0xffffcc25 ;UPM: singel read=0A=
;=0A=
WUPM 0x00000008 0xcfffcc24 ;UPMA burst read=0A=
WUPM 0x00000009 0x0fffcc04 ;UPMA burst read=0A=
WUPM 0x0000000A 0x0cafcc84 ;UPMA burst read=0A=
WUPM 0x0000000B 0x03afcc88 ;UPMA burst read=0A=
WUPM 0x0000000C 0x3fbfcc27 ;UPMA burst read=0A=
WUPM 0x0000000D 0xffffcc25 ;UPMA burst read=0A=
WUPM 0x0000000E 0xffffcc25 ;UPMA burst read=0A=
WUPM 0x0000000F 0xffffcc25 ;UPMA burst read=0A=
WUPM 0x00000010 0xffffcc25 ;UPMA burst read=0A=
WUPM 0x00000011 0xffffcc25 ;UPMA burst read=0A=
WUPM 0x00000012 0xffffcc25 ;UPMA burst read=0A=
WUPM 0x00000013 0xffffcc25 ;UPMA burst read=0A=
WUPM 0x00000014 0xffffcc25 ;UPMA burst read=0A=
WUPM 0x00000015 0xffffcc25 ;UPMA burst read=0A=
WUPM 0x00000016 0xffffcc25 ;UPMA burst read=0A=
WUPM 0x00000017 0xffffcc25 ;UPMA burst read=0A=
;=0A=
WUPM 0x00000018 0xcfffcc24 ;UPMA single write=0A=
WUPM 0x00000019 0x0fffcc04 ;UPMA single write=0A=
WUPM 0x0000001A 0x0cffcc04 ;UPMA single write=0A=
WUPM 0x0000001B 0x03ffcc08 ;UPMA single write=0A=
WUPM 0x0000001C 0x3fffcc27 ;UPMA single write=0A=
WUPM 0x0000001D 0xffffcc25 ;UPMA single write=0A=
WUPM 0x0000001E 0xffffcc25 ;UPMA single write=0A=
WUPM 0x0000001F 0xffffcc25 ;UPMA single write=0A=
;=0A=
WUPM 0x00000020 0xcfffcc24 ;UPMA burst write=0A=
WUPM 0x00000021 0x0fffcc04 ;UPMA burst write=0A=
WUPM 0x00000022 0x0cffcc80 ;UPMA burst write=0A=
WUPM 0x00000023 0x03ffcc8C ;UPMA burst write=0A=
WUPM 0x00000024 0x0cffcc00 ;UPMA burst write=0A=
WUPM 0x00000025 0x33ffcc27 ;UPMA burst write=0A=
WUPM 0x00000026 0xffffcc25 ;UPMA burst write=0A=
WUPM 0x00000027 0xffffcc25 ;UPMA burst write=0A=
WUPM 0x00000028 0xffffcc25 ;UPMA burst write=0A=
WUPM 0x00000029 0xffffcc25 ;UPMA burst write=0A=
WUPM 0x0000002A 0xffffcc25 ;UPMA burst write=0A=
WUPM 0x0000002B 0xffffcc25 ;UPMA burst write=0A=
WUPM 0x0000002C 0xffffcc25 ;UPMA burst write=0A=
WUPM 0x0000002D 0xffffcc25 ;UPMA burst write=0A=
WUPM 0x0000002E 0xffffcc25 ;UPMA burst write=0A=
WUPM 0x0000002F 0xffffcc25 ;UPMA burst write=0A=
;=0A=
WUPM 0x00000030 0xc0ffcc24 ;UPMA refresh=0A=
WUPM 0x00000031 0x03ffcc24 ;UPMA refresh=0A=
WUPM 0x00000032 0x0fffcc24 ;UPMA refresh=0A=
WUPM 0x00000033 0x0fffcc24 ;UPMA refresh=0A=
WUPM 0x00000034 0x3fffcc27 ;UPMA refresh=0A=
WUPM 0x00000035 0xffffcc25 ;UPMA refresh=0A=
WUPM 0x00000036 0xffffcc25 ;UPMA refresh=0A=
WUPM 0x00000037 0xffffcc25 ;UPMA refresh=0A=
WUPM 0x00000038 0xffffcc25 ;UPMA refresh=0A=
WUPM 0x00000039 0xffffcc25 ;UPMA refresh=0A=
WUPM 0x0000003A 0xffffcc25 ;UPMA refresh=0A=
WUPM 0x0000003B 0xffffcc25 ;UPMA refresh=0A=
;=0A=
WUPM 0x0000003C 0xffffcc25 ;UPMA exception=0A=
WUPM 0x0000003D 0xffffcc25 ;UPMA exception=0A=
WUPM 0x0000003E 0xffffcc25 ;UPMA exception=0A=
WUPM 0x0000003F 0xffffcc25 ;UPMA exception=0A=
;=0A=
; init memory controller=0A=
WM32 0xFA200104 0xff800140 ;;OR0: Flash 2MB, all accesses, =
CS early negate, 4ws=0A=
WM32 0xFA200100 0xfe000001 ;;BR0: Flash at 0xFE000000, 32bit, =
R/W, no parity, use GPCM=0A=
WM32 0xFA20010C 0xff000e00 ;;OR1: DRAM 4MB, all =
accesses=0A=
WM32 0xFA200108 0x00000081 ;;BR1: DRAM at 0x00000000, =
32bit, R/W, no parity, use UPMA=0A=
WM32 0xfa20011c 0xff7f8910 ;;OR3=0A=
WM32 0xfa200118 0xfa400001 ;;BR3 BCSR=0A=
WM32 0xFA200124 0xffff8970 ;;OR4: NVRAM=0A=
WM32 0xFA200120 0xfa000401 ;;BR4: NVRAM=0A=
;=0A=
WM16 0xFA20017A 0x0800 ;;MPTPR : divide by 32=0A=
WM32 0xFA200170 0x5fa01430 ;;MAMR : PTA=3D24 (15.36us @ =
50MHz)=0A=
;=0A=
[TARGET]=0A=
CPUCLOCK 50000000 ;the CPU clock rate after processing the init =
list=0A=
WORKSPACE 0x00000000 ;workspace in target RAM for fast download=0A=
BDIMODE AGENT ;the BDI working mode (LOADONLY | AGENT)=0A=
BREAKMODE SOFT ;SOFT or HARD, HARD uses PPC hardware =
breakpoints=0A=
;=0A=
[HOST]=0A=
IP 10.0.0.161=0A=
FILE PCL200.mot=0A=
FORMAT SREC=0A=
LOAD MANUAL ;load code MANUAL or AUTO after reset=0A=
;=0A=
[REGS]=0A=
DMM1 0xFA200000=0A=
FILE reg860.def=0A=
------_=_NextPart_000_01C450BD.2736A470--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
one installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
and to me it seems you have at least a valid argument. But before
doing this I would like to have an agreement between you (resp.
Sascha Hauer) and Ming-Len Wu.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
You can fool some of the people all of the time, and You can fool all
of the people some of the time, but You can't fool mom.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
--set-section-flags SECTION=FLAGS'
Set the flags for the named section. The FLAGS argument is a
comma separated string of flag names. The recognized names are
`alloc', `contents', `load', `noload', `readonly', `code', `data',
`rom', `share', and `debug'. You can set the `contents' flag for
a section which does not have contents, but it is not meaningful
to clear the `contents' flag of a section which does have
contents-just remove the section instead. Not all flags are
meaningful for all object file formats.
Since we build ELF files by default, you can look these up in any
documentation about the ELF file format.
See for example http://www.cs.ucdavis.edu/~haungs/paper/node14.html
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
I am an atheist, thank God!
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
Powered by Outblaze
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
Powered by Outblaze
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
Powered by Outblaze
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
Software Developer Manual", it seems compatible.
"This document is intended for use as a software technical reference
manual for the Intel? 10/100 Mbps Fast Ethernet controller family, which
includes the 82557, 82558, 82559, 82550, and 82551, as well as the 82562
Platform LAN Connect device. It also contains information for several PCI
LAN adapters based on these devices: Intel? EtherExpress? PRO/100+,
Intel? EtherExpress? PRO/100B Wake on LAN (WOL), Intel? EtherExpress?
PRO/100B, and Intel? EtherExpress? PRO/10+."
Thanks,
-Shawn.
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
<br>
To : 'SYLee'(<a href="javascript:location='/kr/writemail.html?to=dobest03@empal.com'" target=_top>dobest03 at empal.com</a>), <a href="javascript:location='/kr/writemail.html?to=u-boot-users@lists.sourceforge.net'" target=_top>u-boot-users at lists.sourceforge.net</a>
<br>
Sent : Friday, Jul 16, 2004 05:42 PM
<br>
Subject : RE: [U-Boot-Users] [PATCH] cpu/ppc4xx/sdram.c
<br>
<br>
<br>
> SYLee!
<br>
>
<br>
>I checked a rewritten version of this code in yesterday! Please take a
<br>
>look at the version from the current cvs tree.
<br>
>
<br>
>By the way: I am still pretty sure that the old version is OK! Did you
<br>
>experience any problems with it?
<br>
>
<br>
>Best regards,
<br>
>Stefan Roese
<br>
>
<br>
>-----Original Message-----
<br>
>From: <a href="javascript:location='/kr/writemail.html?to=u-boot-users-admin@lists.sourceforge.net'" target=_top>u-boot-users-admin at lists.sourceforge.net</a>
<br>
>[mailto:<a href="javascript:location='/kr/writemail.html?to=u-boot-users-admin@lists.sourceforge.net'" target=_top>u-boot-users-admin at lists.sourceforge.net</a>] On Behalf Of SYLee
<br>
>Sent: Friday, July 16, 2004 10:08 AM
<br>
>To: <a href="javascript:location='/kr/writemail.html?to=u-boot-users@lists.sourceforge.net'" target=_top>u-boot-users at lists.sourceforge.net</a>
<br>
>Subject: [U-Boot-Users] [PATCH] cpu/ppc4xx/sdram.c
<br>
>
<br>
>
<br>
>
<br>
>Hi all,
<br>
>
<br>
>This is a patch for cpu/ppc4xx/sdram.c for auto sdram size detection:
<br>
>
<br>
>--- u-boot-1.1.1/cpu/ppc4xx/sdram.c 2003-09-12 17:49:58.000000000 +0900
<br>
>+++ u-boot-patched/cpu/ppc4xx/sdram.c 2004-07-16 16:23:44.000000000
<br>
>+0900
<br>
>@@ -122,7 +122,8 @@
<br>
>if ((*(volatile ulong *)ADDR_ZERO == MAGIC0) &&
<br>
> (*(volatile ulong *)ADDR_08MB == MAGIC1) &&
<br>
> (*(volatile ulong *)ADDR_16MB == MAGIC2) &&
<br>
>- (*(volatile ulong *)ADDR_32MB == MAGIC3)) {
<br>
>+ (*(volatile ulong *)ADDR_32MB == MAGIC3) &&
<br>
>+ (*(volatile ulong *)ADDR_64MB == MAGIC4)) {
<br>
>/*
<br>
>* OK, 128MB detected -> all done
<br>
>*/
<br>
>@@ -173,7 +174,8 @@
<br>
>
<br>
>if ((*(volatile ulong *)ADDR_ZERO == MAGIC0) &&
<br>
> (*(volatile ulong *)ADDR_08MB == MAGIC1) &&
<br>
>- (*(volatile ulong *)ADDR_16MB == MAGIC2)) {
<br>
>+ (*(volatile ulong *)ADDR_16MB == MAGIC2) &&
<br>
>+ (*(volatile ulong *)ADDR_32MB == MAGIC3)) {
<br>
>/*
<br>
>* OK, 64MB detected -> all done
<br>
>*/
<br>
>@@ -216,7 +218,8 @@
<br>
>
<br>
>if ((*(volatile ulong *)ADDR_ZERO == MAGIC0) &&
<br>
> (*(volatile ulong *)ADDR_400 == MAGIC1) &&
<br>
>- (*(volatile ulong *)ADDR_08MB == MAGIC2)) {
<br>
>+ (*(volatile ulong *)ADDR_08MB == MAGIC2) &&
<br>
>+ (*(volatile ulong *)ADDR_16MB == MAGIC3)) {
<br>
>/*
<br>
>* OK, 32MB detected -> all done
<br>
>*/
<br>
>
<br>
>
<br>
>Get your own 200MB free email at <a href="http://www.empal.com">http://www.empal.com</a>
<br>
>------------------------------------------------------- This SF.Net
<br>
>email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE
<br>
>developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today.
<br>
><a href="http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click">http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click</a>
<br>
>_______________________________________________ U-Boot-Users mailing
<br>
>list <a href="javascript:location='/kr/writemail.html?to=U-Boot-Users@lists.sourceforge.net'" target=_top>U-Boot-Users at lists.sourceforge.net</a>
<br>
><a href="https://lists.sourceforge.net/lists/listinfo/u-boot-users">https://lists.sourceforge.net/lists/listinfo/u-boot-users</a>
<br>
>
<br>
>
<br>
>
<br>
>-------------------------------------------------------
<br>
>This SF.Net email is sponsored by BEA Weblogic Workshop
<br>
>FREE Java Enterprise J2EE developer tools!
<br>
>Get your free copy of BEA WebLogic Workshop 8.1 today.
<br>
><a href="http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click">http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click</a>
<br>
>_______________________________________________
<br>
>U-Boot-Users mailing list
<br>
><a href="javascript:location='/kr/writemail.html?to=U-Boot-Users@lists.sourceforge.net'" target=_top>U-Boot-Users at lists.sourceforge.net</a>
<br>
><a href="https://lists.sourceforge.net/lists/listinfo/u-boot-users">https://lists.sourceforge.net/lists/listinfo/u-boot-users</a>
<!-- Empal Slogan Start -->
<hr noshade size=1 width=590 align=left>
<font style="font-size:9pt">Get your own 200MB free email at <a href="http://mail.empas.com" target="new_win1">http://www.empal.com</a><br>
<!-- Empal Slogan End -->
</body>
</html>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
Thanks & Regards,
Rakesh Jagota
----- Original Message -----
From: <u-boot-users-request@lists.sourceforge.net>
To: <u-boot-users@lists.sourceforge.net>
Sent: Tuesday, July 13, 2004 5:49 AM
Subject: U-Boot-Users digest, Vol 1 #861 - 14 msgs
> Send U-Boot-Users mailing list submissions to
> u-boot-users at lists.sourceforge.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
> or, via email, send a message with subject or body 'help' to
> u-boot-users-request at lists.sourceforge.net
>
> You can reach the person managing the list at
> u-boot-users-admin at lists.sourceforge.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of U-Boot-Users digest..."
>
>
> Today's Topics:
>
> 1. Re: More 8540/8560 ADS Patches Soon (Jon Loeliger)
> 2. ppc4xx/serial.c (=?iso-8859-1?Q?Seingier_Fran=E7ois-Xavier?=)
> 3. RE: [u-boot-users]: Relocation code on Nios (Scott McNutt)
> 4. Debugging U-Boot Under DDD (Talib Alim)
> 5. Re: Debugging U-Boot Under DDD (Wolfgang Denk)
> 6. Re: Debugging U-Boot Under DDD (Matthew McClintock)
> 7. RE: Debugging U-Boot Under DDD (VanBaren, Gerald (AGRE))
> 8. Re: Debugging U-Boot Under DDD (Talib Alim)
> 9. Re: Debugging U-Boot Under DDD (Wolfgang Denk)
> 10. Help with serial port set-up for PPC 8540 (Junita Ajith)
> 11. Errant Tab in drivers/cfi_flash.c (Michael Bendzick)
> 12. Re: Help with serial port set-up for PPC 8540 (Wolfgang Denk)
> 13. Re: Errant Tab in drivers/cfi_flash.c (Wolfgang Denk)
> 14. Re: Debugging U-Boot Under DDD (Talib Alim)
>
> --__--__--
>
> Message: 1
> Subject: Re: [U-Boot-Users] More 8540/8560 ADS Patches Soon
> From: Jon Loeliger <jdl@freescale.com>
> To: u-boot-users <u-boot-users@lists.sourceforge.net>
> Organization:
> Date: 12 Jul 2004 11:20:42 -0500
>
>
> On Sun, 2004-07-11 at 17:26, Wolfgang Denk wrote:
> >
> > I reject the following parts:
> >
> > cpu/mpc85xx/spd_sdram.c:
> >
> > ...
> >
> > All the rest: added & checked in.
>
> Cool. Thanks.
>
> > ...
> >
> > Please feel free to go on now.
>
> Will do. No problem about the spd_sdram.c as essentially
> the entire purpose of the next patch is to improve large
> portions of that code.
>
> Thanks,
> jdl
>
>
>
> --__--__--
>
> Message: 2
> Date: Mon, 12 Jul 2004 18:23:16 +0200
> From: =?iso-8859-1?Q?Seingier_Fran=E7ois-Xavier?=
<Francois-Xavier.Seingier@thomson.net>
> To: "U-Boot-Users \(E-mail\)" <u-boot-users@lists.sourceforge.net>
> Subject: [U-Boot-Users] ppc4xx/serial.c
>
> hello,
> I've been going through the code of the function serial_init because I =
> couldn't get the proper baudrate divisor. I must admit I don't =
> understand the operations made to calculate udiv and bdiv... According =
> to the 405gp user manual, these are the meanings of a few parameters.
>
> CFG_BASE_BAUD =3D SerClk / 16
>
> bdiv =3D SerClk / (16 * baudrate)
>
> SerClk =3D cpu_freq / udiv
>
>
>
> As a result, udiv and bdiv should be generated as follows in =
> serail_init:
>
> if external_clock:
>
> SerClk =3D CFG_EXT_SERIAL_CLK
> udiv =3D 1
>
> else:
>
> SerClk =3D CFG_BASE_BAUD * 16
> udiv =3D cpu_freq / serClk
>
> endif
>
> bdiv =3D SerClk / (16 * baudrate)
>
> Am I missing something?
>
> regards,
>
> Fran=E7ois-Xavier SEINGIER
>
>
> --__--__--
>
> Message: 3
> From: Scott McNutt <ScottM@orbacom.com>
> To: u-boot-users at lists.sourceforge.net
> Date: Mon, 12 Jul 2004 13:01:26 -0400
> Subject: [U-Boot-Users] RE: [u-boot-users]: Relocation code on Nios
>
>
> >> I don"t understand this particular line of code:
> >>
> >> ld %g7, [%g7]
>
> This moves the value pointed to by %g7 into register
> %g7. %g7 points to the location that stores the address
> of _start. This is the address where u-boot is to be
> copied (the destination address).
>
> >> Per my understanding, %g7 keeps the return address.
> >> This address should point to the next instruction
> >> of code just after the delay slot of CALL or BSR
> >> used to call u-boot.
>
> Yes, you are correct. %g7 points to where the (link time)
> address of _start is stored (not the current execution
> address of _start).
>
> >> later this value (instruction bytes) is compared with
> >> %g5 that keeps the end of data segment according to
> >> u-boot.lds. I can"t understand why code address is
> >> being compared with instruction bytes. Please
> >> explain if possible - what does [%g7] keep and where
> >> am I wrong?
>
> This just lets you store u-boot in memory at any address.
> When you being execution, the code is simply copied to
> TEXT_BASE, that's all. This initial bsr just lets us
> know where we begin execution, the value in %g7 after
> the bsr is the target address plus 4.
>
> Currently, for convenience and simplicity, the u-boot
> code, data, and command table are currently located
> contiguously.
>
> There's no magic here ... just load the binary to
> some arbitrary address, then single step through the
> code -- it'll help you understand :-)
>
> Best Regards,
> --Scott
>
>
>
> --__--__--
>
> Message: 4
> Date: Mon, 12 Jul 2004 12:08:24 -0700 (PDT)
> From: Talib Alim <talibalm@hotmail.com>
> Reply-To: talibalm at hotmail.com
> To: U-Boot List <u-boot-users@lists.sourceforge.net>
> Subject: [U-Boot-Users] Debugging U-Boot Under DDD
>
> This may be a trivial question, but I hope that someone can answer me.
> I am bring up u-boot on 8xx.
>
> While doing source level debugging under ddd, whenever I do step,
> stepi, next or nexti I see green instruction pointer jump all over the
> code. e.g. it would go to first line, than third line, than 7 line. If
> I look at machine code window, it is running in normal predictable way.
>
>
> --__--__--
>
> Message: 5
> To: talibalm at hotmail.com
> Cc: U-Boot List <u-boot-users@lists.sourceforge.net>
> Subject: Re: [U-Boot-Users] Debugging U-Boot Under DDD
> From: Wolfgang Denk <wd@denx.de>
> Date: Mon, 12 Jul 2004 21:17:58 +0200
>
> In message <20040712190824.57774.qmail@web50510.mail.yahoo.com> you wrote=
> :
> > This may be a trivial question, but I hope that someone can answer me.
>
> It's not a trivial question, but a FAQ.
>
> > While doing source level debugging under ddd, whenever I do step,
> > stepi, next or nexti I see green instruction pointer jump all over the
> > code. e.g. it would go to first line, than third line, than 7 line. If
> > I look at machine code window, it is running in normal predictable way.
>
> See http://www.denx.de/twiki/bin/view/DULG/DebuggingTricks
>
> Best regards,
>
> Wolfgang Denk
>
> --=20
> Software Engineering: Embedded and Realtime Systems, Embedded Linux
> Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
> When it is incorrect, it is, at least *authoritatively* incorrect.
> - Hitchiker's Guide To The Galaxy
>
>
> --__--__--
>
> Message: 6
> Subject: Re: [U-Boot-Users] Debugging U-Boot Under DDD
> From: Matthew McClintock <mcclintock@freescale.com>
> Reply-To: mcclintock at freescale.com
> To: talibalm at hotmail.com
> Cc: U-Boot List <u-boot-users@lists.sourceforge.net>
> Date: Mon, 12 Jul 2004 14:18:08 +0000
>
> See: http://www.denx.de/twiki/bin/view/DULG/DebuggingTricks
>
> Matthew
>
> On Mon, 2004-07-12 at 19:08, Talib Alim wrote:
> > This may be a trivial question, but I hope that someone can answer me.
> > I am bring up u-boot on 8xx.
> >
> > While doing source level debugging under ddd, whenever I do step,
> > stepi, next or nexti I see green instruction pointer jump all over the
> > code. e.g. it would go to first line, than third line, than 7 line. If
> > I look at machine code window, it is running in normal predictable way.
> >
> >
> > -------------------------------------------------------
> > This SF.Net email sponsored by Black Hat Briefings & Training.
> > Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> > digital self defense, top technical experts, no vendor pitches,
> > unmatched networking opportunities. Visit www.blackhat.com
> > _______________________________________________
> > U-Boot-Users mailing list
> > U-Boot-Users at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/u-boot-users
> --
> Matthew McClintock <mcclintock@freescale.com>
>
>
>
> --__--__--
>
> Message: 7
> Subject: RE: [U-Boot-Users] Debugging U-Boot Under DDD
> Date: Mon, 12 Jul 2004 13:21:43 -0600
> From: "VanBaren, Gerald (AGRE)" <Gerald.VanBaren@smiths-aerospace.com>
> To: "U-Boot List" <u-boot-users@lists.sourceforge.net>
>
>
> > -----Original Message-----
> > From: u-boot-users-admin at lists.sourceforge.net
> > [mailto:u-boot-users-admin at lists.sourceforge.net]On Behalf Of=0D
> > Talib Alim
> > Sent: Monday, July 12, 2004 3:08 PM
> > To: U-Boot List
> > Subject: [U-Boot-Users] Debugging U-Boot Under DDD
> >=0D
> >=0D
> > This may be a trivial question, but I hope that someone can answer me.
> > I am bring up u-boot on 8xx.
> >=0D
> > While doing source level debugging under ddd, whenever I do step,
> > stepi, next or nexti I see green instruction pointer jump all over the
> > code. e.g. it would go to first line, than third line, than 7 line. If
> > I look at machine code window, it is running in normal=0D
> > predictable way.
>
>
> That is typically because the compiler optimizer has re-ordered your=
> program. ddd is showing you which line is being executed and the
machine=
> code window shows sequential instructions, but those instructions are=
> _not_ for sequential source lines.
>
> gvb
>
>
>
>
> ******************************************
> The information contained in, or attached to, this e-mail, may contain=
> confidential information and is intended solely for the use of the=
> individual or entity to whom they are addressed and may be subject to=
> legal privilege. If you have received this e-mail in error you should=
> notify the sender immediately by reply e-mail, delete the message from=
> your system and notify your system manager. Please do not copy it for
any=
> purpose, or disclose its contents to any other person. The views or=
> opinions presented in this e-mail are solely those of the author and do=
> not necessarily represent those of the company. The recipient should=
> check this e-mail and any attachments for the presence of viruses. The=
> company accepts no liability for any damage caused, directly or=
> indirectly, by any virus transmitted in this email.
> ******************************************
>
>
> --__--__--
>
> Message: 8
> Date: Mon, 12 Jul 2004 12:43:03 -0700 (PDT)
> From: Talib Alim <talibalm@hotmail.com>
> Reply-To: talibalm at hotmail.com
> Subject: Re: [U-Boot-Users] Debugging U-Boot Under DDD
> To: Wolfgang Denk <wd@denx.de>, talibalm at hotmail.com
> Cc: U-Boot List <u-boot-users@lists.sourceforge.net>
>
> Thanks for the link.
>
> I have debugged u-boot to a point, it has relocated code, setup
> execptions / interrrupts etc and in main_loop().
>
> At this point if I "Cont", I get pop-up from ddd
>
> /.../u-boot-1.1.1/serial.c: No such file or directory.
>
> There are 23 serial.c files in the tree. Those possibly relavent to me
> are
>
> ./cpu/mpc8xx/serial.c
> ./tools/gdb/serial.c
> ./drivers/serial.c
>
> Just before relocating the code, I typed following statements
>
> (gdb) symbol-file
> (gdb) add-symbol-file u-boot 0xbda000
> (gdb) dir cpu/mpc8xx
> (gdb) dir board/fads
> (gdb) dir tools/gdb/serial.c
> (gdb) dir drivers/serial.c
>
> Well, my question is why I am getting "No such file or directory" from
> ddd and how can I fix this problem.
>
> Usman
>
> --- Wolfgang Denk <wd@denx.de> wrote:
> > In message <20040712190824.57774.qmail@web50510.mail.yahoo.com> you
> > wrote:
> > > This may be a trivial question, but I hope that someone can answer
> > > me.
> >
> > It's not a trivial question, but a FAQ.
> >
> > > While doing source level debugging under ddd, whenever I do step,
> > > stepi, next or nexti I see green instruction pointer jump all over
> > > the code. e.g. it would go to first line, than third line, than 7
> > > line. If I look at machine code window, it is running in normal
> > > predictable way.
> >
> > See http://www.denx.de/twiki/bin/view/DULG/DebuggingTricks
> >
> > Best regards,
> >
> > Wolfgang Denk
> >
> > --
> > Software Engineering: Embedded and Realtime Systems, Embedded
> > Linux
> > Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email:
> > wd at denx.de
> > When it is incorrect, it is, at least *authoritatively* incorrect.
> > - Hitchiker's Guide To The
> > Galaxy
>
>
> --__--__--
>
> Message: 9
> To: talibalm at hotmail.com
> Cc: U-Boot List <u-boot-users@lists.sourceforge.net>
> Subject: Re: [U-Boot-Users] Debugging U-Boot Under DDD
> From: Wolfgang Denk <wd@denx.de>
> Date: Mon, 12 Jul 2004 21:59:33 +0200
>
> In message <20040712194303.3117.qmail@web50504.mail.yahoo.com> you wrote:
> >=20
> > At this point if I "Cont", I get pop-up from ddd
> > /.../u-boot-1.1.1/serial.c: No such file or directory.
>
> Sounds like a toolchain or user problem to me.
>
> > Just before relocating the code, I typed following statements
> >=20
> > (gdb) symbol-file
> > (gdb) add-symbol-file u-boot 0xbda000
>
> How did you start gdb / DDD? Did you really load "u-boot" (i. e. the
> ELF file)?
>
> > (gdb) dir cpu/mpc8xx
> > (gdb) dir board/fads
> > (gdb) dir tools/gdb/serial.c
> > (gdb) dir drivers/serial.c
>
> None of these should be necessary. Which toolchain are you using?
>
>
> Best regards,
>
> Wolfgang Denk
>
> --=20
> Software Engineering: Embedded and Realtime Systems, Embedded Linux
> Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
> Old programmers never die, they just become managers.
>
>
> --__--__--
>
> Message: 10
> Date: Mon, 12 Jul 2004 14:29:57 -0700 (PDT)
> From: Junita Ajith <junita_ppc@yahoo.com>
> To: u-boot-users at lists.sourceforge.net
> Subject: [U-Boot-Users] Help with serial port set-up for PPC 8540
>
> Hi
> I am trying to write an Assembly code , just to
> set-up the UART , so as to send a few characters via
> the serial port.
>
> I am working on a 8540 Motorola PowerPC . As I am
> starting right from the scratch I dont have the boot
> -loader doing the board initializations for me and so
> have to have my own start.S file to do those .
>
> I just have set-up the necessary registers for
> UART and as I am not doing any high level coding I
> havent set up the MMU , TLB etc. But my code doesnt
> seem to work !!!
>
> I assumed that that CPU would direclty read from
> the Flash .I am new to this and so I need some advise
> of what all have to be done during board bring up, or
> where should I look for such documentation.
>
> Any help would be appreciated .
>
> Thanks
> Junita
>
>
>
> __________________________________
> Do you Yahoo!?
> Take Yahoo! Mail with you! Get it on your mobile phone.
> http://mobile.yahoo.com/maildemo
>
>
> --__--__--
>
> Message: 11
> From: Michael Bendzick <michaelb@logicpd.com>
> To: "'u-boot-users at lists.sourceforge.net'"
> <u-boot-users@lists.sourceforge.net>
> Date: Mon, 12 Jul 2004 16:59:45 -0500
> Subject: [U-Boot-Users] Errant Tab in drivers/cfi_flash.c
>
> I noticed in the drivers/cfi_flash.c file, there's a minor error in text
> formatting that makes for an ugly display when running 'flinfo'.
>
> I tracked it down to line 465, where either "(RO)" or blank space is
> displayed, depending on the sector status. An errant tab is in there that
> looked like the two spaces that ought to be there, which caused my
terminal
> program (Tera Term) to make the spacing between numbered sectors
excessively
> wide, and also cause a blank line between every data-bearing line.
>
> The fix (note that I'm using [tab] and [space] here for clarity):
>
> Line 465...
>
> info->start[i], info->protect[i] ? "[space](RO)" :
> "[tab][space][space][space]");
>
> ...should become...
>
> info->start[i], info->protect[i] ? "[space](RO)" :
> "[space][space][space][space][space]");
>
> -Michael Bendzick
> Systems and Software Engineering
> Logic Product Development
> michael.b at logicpd.com
> 612-436-5122
> www.logicpd.com
>
>
>
> --__--__--
>
> Message: 12
> To: Junita Ajith <junita_ppc@yahoo.com>
> Cc: u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] Help with serial port set-up for PPC 8540
> From: Wolfgang Denk <wd@denx.de>
> Date: Tue, 13 Jul 2004 00:30:31 +0200
>
> In message <20040712212957.88820.qmail@web90006.mail.scd.yahoo.com> you w=
> rote:
> >
> > I am trying to write an Assembly code , just to
> > set-up the UART , so as to send a few characters via
> > the serial port.
>
> Why? There is a full-blown serial driver available written in C? Is
> this intended as a replacement for a missing BDI2000? Save your time,
> abd buy the BDI2000 _now_. Other wise your time is just wasted, as
> you will buy the BDI2000 later anyway.
>
> > I just have set-up the necessary registers for
> > UART and as I am not doing any high level coding I
> > havent set up the MMU , TLB etc. But my code doesnt
> > seem to work !!!
>
> Forget it. U-Boot was explicitely designed to bring up a serial
> console port as early as possible during initialization. OK, there
> are a few things that could be saved before running the serial
> driver, but this is just a tiny piece of the code you need to get
> right before you will see the first character on the serial line.
>
> Don't try to re-invent the wheel.
>
> > I assumed that that CPU would direclty read from
> > the Flash .I am new to this and so I need some advise
> > of what all have to be done during board bring up, or
> > where should I look for such documentation.
>
> Use the existing U-Boot code. Attach a BDI2000 and just type "ti" at
> the telnet prompt, or "d/i $pc" + "si" in GDB...
>
> Best regards,
>
> Wolfgang Denk
>
> --=20
> Software Engineering: Embedded and Realtime Systems, Embedded Linux
> Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
> "The good Christian should beware of mathematicians and all those who
> make empty prophecies. The danger already exists that mathematicians
> have made a covenant with the devil to darken the spirit and confine
> man in the bonds of Hell." - Saint Augustine
>
>
> --__--__--
>
> Message: 13
> To: Michael Bendzick <michaelb@logicpd.com>
> Cc: "'u-boot-users at lists.sourceforge.net'"
<u-boot-users@lists.sourceforge.net>
> Subject: Re: [U-Boot-Users] Errant Tab in drivers/cfi_flash.c
> From: Wolfgang Denk <wd@denx.de>
> Date: Tue, 13 Jul 2004 00:35:55 +0200
>
> In message <31ADFA827355984B9E2A161514595B561C32C0@lpdsrv04.logicpd.com> =
> you wrote:
> > I noticed in the drivers/cfi_flash.c file, there's a minor error in tex=
> t
> > formatting that makes for an ugly display when running 'flinfo'.
>
> Thanks for pointing out (mea culpa).
>
> > The fix (note that I'm using [tab] and [space] here for clarity):
>
> It would have been much more useful (and less work for me) if you had
> just included a patch (see README for instructions).
>
> Fixed in CVS tree.
>
> Best regards,
>
> Wolfgang Denk
>
> --=20
> Software Engineering: Embedded and Realtime Systems, Embedded Linux
> Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
> We call our dog Egypt, because in every room he leaves a pyramid.
>
>
> --__--__--
>
> Message: 14
> Date: Mon, 12 Jul 2004 17:18:16 -0700 (PDT)
> From: Talib Alim <talibalm@hotmail.com>
> Reply-To: talibalm at hotmail.com
> Subject: Re: [U-Boot-Users] Debugging U-Boot Under DDD
> To: Wolfgang Denk <wd@denx.de>, talibalm at hotmail.com
> Cc: U-Boot List <u-boot-users@lists.sourceforge.net>
>
> I am using eldk
>
> [root at lab1 eldk]# cat version
> ELDK version 3.0
> ppc_8xx: Build 2004-02-16
>
> I am starting ddd with following command line
>
> ddd --debugger /opt/eldk/usr/bin/ppc_8xx-gdb
> target remote bdi:2001
> symbol u-boot
> set $pc = 0x02000100 # my flash is mapped @ 0x02000000
> I am using bin {& not elf}, apart from this problem, it seems to be
> doing fine.
>
> TA
>
> --- Wolfgang Denk <wd@denx.de> wrote:
> > In message <20040712194303.3117.qmail@web50504.mail.yahoo.com> you
> > wrote:
> > >
> > > At this point if I "Cont", I get pop-up from ddd
> > > /.../u-boot-1.1.1/serial.c: No such file or directory.
> >
> > Sounds like a toolchain or user problem to me.
> >
> > > Just before relocating the code, I typed following statements
> > >
> > > (gdb) symbol-file
> > > (gdb) add-symbol-file u-boot 0xbda000
> >
> > How did you start gdb / DDD? Did you really load "u-boot" (i. e.
> > the
> > ELF file)?
> >
> > > (gdb) dir cpu/mpc8xx
> > > (gdb) dir board/fads
> > > (gdb) dir tools/gdb/serial.c
> > > (gdb) dir drivers/serial.c
> >
> > None of these should be necessary. Which toolchain are you using?
> >
> >
> > Best regards,
> >
> > Wolfgang Denk
> >
> > --
> > Software Engineering: Embedded and Realtime Systems, Embedded
> > Linux
> > Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email:
> > wd at denx.de
> > Old programmers never die, they just become managers.
> >
> >
> > -------------------------------------------------------
> > This SF.Net email sponsored by Black Hat Briefings & Training.
> > Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> > digital self defense, top technical experts, no vendor pitches,
> > unmatched networking opportunities. Visit www.blackhat.com
> > _______________________________________________
> > U-Boot-Users mailing list
> > U-Boot-Users at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/u-boot-users
> >
>
>
>
>
> --__--__--
>
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>
>
> End of U-Boot-Users Digest
>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
ap
go to 1, so a return of -1 is made bacause NetState assume the NETLOOP_FA=
IL
value.
This is exactly all I wanted.
Thank's for all
Regards,
Enzo
>
> Best regards,
>
> Wolfgang Denk
>
> --
> Software Engineering: Embedded and Realtime Systems, Embedded Linux
> Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
> How many hardware guys does it take to change a light bulb? "Well the
> diagnostics say it's fine buddy, so it's a software problem."
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
At last I check the data in exactly the exception handler offset, like "md 0x700; md 0x900; md 0x500;". I can find the last two addresses embedded.
One is like UnknownException() or timer_interrupt() or external_interrupt(). The other is like int_return. Simply "go" the first address, I retained normal result -- UnknownException() or timer_interrupt() or external_interrupt() print their origin msg on the console. But why they can't work in the exception handling -- even they won't really run in the exception handling, :)
Thanks to your patiently reading out the above long text.
Any help or advice is appreciated.
Thank you.
--Boundary_(ID_Wi3WBd41UM4KkI/R7iGBFA)
Content-type: text/html; charset=gb2312
Content-transfer-encoding: 7BIT
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=gb2312" http-equiv=Content-Type>
<META content="MSHTML 5.00.2919.6307" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT size=2>My target platform is with 750FX and MPC107, 256M ram, a
NS16c552 serial and also a Intel 82559 compatiable ethernet
controller.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=2>I can get Program Exeption(0x700) printing msg when I "go" a
program from an arbitary address within U-Boot's shell.</FONT></DIV>
<DIV><FONT size=2>But when I set EE bit in MSR register, U-Boot seems to hang
there, nothing </FONT></DIV>
<DIV><FONT size=2>output.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=2>I guess the exception handling have problem. But I really
didn't change any codes in Start.s or ppc_asm.tmpl.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=2>Additonal, when I write a dword to a address outside my
BAT-Array covered range, DSI Exception(0x300) also seems hanging, nothing
output. I originally image that the UnknownException() funciton can print
something on my console.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=2>In any case Program Exception handling does work. And it
seems when I set IP bit in MSR register, the higher Exception handler which is
borned in flash can go up to the address { hdlr - _start + EXC_OFF_SYS_RESET;
(refer to ppc_asm.tmpl Line 304) }. There is a number such as 0x3688. Maybe
CPU turned to that address to fetch next instruction. Unfortunately, that
address is dull, so program exception occured. And then I got something on the
console just like that after I "go 0x3688".</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=2>From above, I can image STD_EXCEPTION(...) works well, even
transfer_to_handler has no problem, but next to that, UnknownException() or
timer_interrupt() or external_interrupt() don't work -- at least they can't
output the strings to console.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=2>At last I check the data in exactly the exception handler
offset, like "md 0x700; md 0x900; md 0x500;". I can find the last
two addresses embedded.</FONT></DIV>
<DIV><FONT size=2>One is like UnknownException() or timer_interrupt() or
external_interrupt(). The other is like int_return. Simply "go" the
first address, I retained normal result -- UnknownException() or
timer_interrupt() or external_interrupt() print their origin msg on the console.
But why they can't work in the exception handling -- even they won't really run
in the exception handling, :)</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=2>Thanks to your patiently reading out the above long
text.</FONT></DIV>
<DIV><FONT size=2>Any help or advice is appreciated.</FONT></DIV>
<DIV><FONT size=2>Thank you.</FONT></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV></BODY></HTML>
--Boundary_(ID_Wi3WBd41UM4KkI/R7iGBFA)--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
OMAP1510 Innovator # dhcp
Using MAC Address 00:0B:36:00:03:FB
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
BOOTP broadcast 5
Retry count exceeded; starting again
BOOTP broadcast 6
...
Retry count exceeded; starting again
BOOTP broadcast 13
...
This lasts for at least a minute for sure. This becomes a problem if 'dhcp'
never exits when it is used in bootcmd.
-Michael Bendzick
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
I think you could only use U-Boot to load a (non-GPL) loader that uses the DoC.
It this a correct assumption?
Wasn't there a section in the manual (U-Boot) about this, using U-Boot to load
non-GPL applications [i.e. Whatever happened to Chapter 8]
Also, what's the status for "standalone applications", i.e the U-Boot resources
mentioned in 5.12 (console I/O, memory allocation, ...)?
My two cents.
Philip
>On Thu, 02 Sep 2004 07:37:27 -0400, Herb Radford <herbr@magma.ca> wrote:
>> We're looking at using a DoC on our next product and I was wondering how
>> the drivers (obviously supplied by M-Systems) are merged into U-Boot code?
>
>Please be cautious with merging drivers supplied my M-Systems into
>U-Boot code. I have not seen thrie drivers, but I am not 100% sure
>they are GPL. Including non-GPL code into U-Boot even locally can be
>the cause of leagal headaches down the road. You may have to see if
>you can reverse engineer the driver, or base the U-Boot driver off of
>the kernel driver instead of using the vendor supplied driver. I would
>be a bit cautious with this as there is no loadable module interface
>loophole in U-Boot to help you avoid the GPL.
>Sorry I couldn't be more help technically but I had a few spare cents
>here to use.
>Thanks
>Brian
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
linuxppc-dev has moved http://ozlabs.org/mailman/listinfo/linuxppc-dev
--
Eugene
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
and people are willing to develop it now.
Regards,
Marius
--
Marius Groeger <mgroeger@sysgo.com>
SYSGO AG Embedded and Real-Time Software
Voice: +49 6136 9948 0 FAX: +49 6136 9948 10
www.sysgo.com | www.elinos.com | www.osek.de | www.imerva.com
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
Powered by Outblaze
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
commands. Check your addresses with objdump.
--Scott
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
/* used to re-map FLASH both when starting from SRAM or FLASH:
* restrict access enough to keep SRAM working (if any)
* but not too much to meddle with FLASH accesses
*/
#define CFG_REMAP_OR_AM 0x80000000 /* OR addr mask */
#define CFG_PRELIM_OR_AM 0xE0000000 /* OR addr mask */
I can see the above hash-defines being used in file=20
./cpu/mpc8xx/cpu_init.c
as follows (lines 176 to 178).
/* now restrict to preliminary range */
memctl->memc_br0 =3D CFG_BR0_PRELIM;
memctl->memc_or0 =3D CFG_OR0_PRELIM;
where CFG_PRELIM_OR_AM is used in the definition of CFG_OR0_PRELIM,
also in TQML860L.h (line 337).
I read Table 15.4 of the Motorola MPC860 Family Users Manual=20
which explains the format of the OR registers. If I understand it=20
correctly, the definition of CFG_PRELIM_OR_AM limits the size of
the Flash address range by masking out bits 0,1 and 2.
Why are only three bits removed ?=20
Also, what puzzles me is the comment:
restrict access enough to keep SRAM working (if any)
but not too much to meddle with FLASH accesses
Why do we have to restrict access to keep SRAM working ?
Any explanations would be appreciated.
Thanks,
Charles.
Dr Charles J Gillan
The Institute of Electronics, Communications and Information Technology
(ECIT),
Queen's University Belfast,
Titanic Quarter
Queen=92s Road, Queen=92s Island,=20
Belfast, BT3 9DT
Northern Ireland, UK
=A0
Tel: +44 (0) 2890 971847
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
from 0xFFFF.FF64 to 0xFFFF.FF9C are mentionned as Reserved!
However memsetup.S uses a lot the following addresses:
SDRC_CR 0xFFFF.FF98
SDRC_MR 0xFFFF.FF90
SDRC_TR 0xFFFF.FF94
Where did Gary Jennejohn got this infos?
Regards - Luc
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
BDI>info
Target CPU : MPC8280/8220/5200 (Zeppo)
Target state : debug mode
Debug entry cause : trace
Current PC : 0x03f85428
Current CR : 0x24000004
Current MSR : 0x00003002
Current LR : 0x03f85428
BDI>
We are now running <in_ram>. Its address before relocation is 0x23428.
After relocation, it is 0x03f85428. Delta is 0x3F62000, and that matches
the address I was expecting to find (0x3F82000 is the new destination address
provided to the function <relocate_code>)
Then I reload the symbol table within gdb:
(gdb) symbol-file
(gdb) add-symbol-file u-boot 0x3F82000
add symbol table from file "u-boot" at
.text_addr = 0x3f82000
(gdb) p in_ram
$1 = {<text variable, no debug info>} 0x3f85428 <in_ram>
(gdb) bt
#0 <signal handler called>
Cannot access memory at address 0x206d6ff5
(gdb) break board_init_r
Breakpoint 3 at 0x3f86680: file board.c, line 566.
(gdb) c
Breakpoint 3, <signal handler called>
(gdb) bt
#0 <signal handler called>
Cannot access memory at address 0x313135b2
I stop on the function, but can't see the source, as I would expect...
(please note that I use HW breakpoints
Any idea what I am doing wrong or missing ?
TIA and Best Regards, Olivier
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
means don't have any undefined command.
Here is my question:
If content in flash and RAM are totally different, does it mean my RAM not
initialized correctly? Or they are supposed to be different?
The stop address is
ldr pc, _data_abort
in start.S
What's the possible reason to stuck at data_abort?
----- Original Message -----
From: "Sam Song" <samsongshu@yahoo.com.cn>
To: "Zhu Yong" <zhu.mm.yong@gmail.com>; <u-boot-users@lists.sourceforge.net>
Sent: Friday, January 14, 2005 12:36 PM
Subject: Re: [U-Boot-Users] starting with u-boot
> Zhu Yong <zhu.mm.yong@gmail.com> wrote??
> > After compilation, I download the u-boot.bin to
> > 0x08000000 with Trace32
> > Then set PC to 0x08000000 and run
>
> Pls try to program your u-booot.bin into FLASH and
> debug from there. The method of loading the image into
>
> RAM to debug isn't recommonded to a newbie of U-Boot.
>
> > But how can I know it running ok? The serial port
> > doesn't have any data ( I monitored with
> > oscilloscope)
>
> Well, the method you used made yourself on your own.
> It shouldn't be surprised.
>
> Pls try to avoid posting HTML message to this list.
> Only PLAIN TEXT is welcome.
>
> =====
> Best regards,
>
> Sam
>
> _________________________________________________________
> Do You Yahoo!?
> 150????MP3????????????????????????
> http://music.yisou.com/
> ??????????????????????????????????????
> http://image.yisou.com
> 1G????1000??????????????????????
>
http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_1
g/
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
ing=20
of the command. It's trying to compile a file called 0xFFF00000, which
is actually part of "-Ttext 0xFFF00000" flag towards the end of the comman=
d.
Can anyone please tell me how to solve this problem, and get the u-boot to =
compile?
Regards,
Nishant
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
cache makes life much simpler than write-back one.
So, currently I have two possible paths:
1) Remove cache locking for 4kc (e.g. put #ifdef CONFIG_PURPLE) or
maybe add CONFIG_WRITE_THROUGH_CACHE and use it.
2) Call dcache_disable instead.
Option 1) seems more clean, although potentially more dangerous.
Option 2) looks safe and keeps current *behavior* while making it
explicit.
Wolfgang, what do you think is the best way to go? Or maybe there is
an option 3) I haven't thought of.
--
Eugene
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
SoC. Somehow the UART will the last component available for firmware
development."
I don't think that is the situation that Shawn is describing. To me
it sounded like he is starting firmware development before all of the
functionality is delivered by the hardware engineers. I don't think
that he is refering to initialization order. Shawn, could you please
clarify?
Cheers,
g.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
summary one Golen Rule for firmware debug as follows.
If u-boot can boot sucessfully once and then sth
unexpected happened on a board with the same image,
in most cases, perhaps X% more, the problem is
related to Hardware.
I prefer X equal to 99. Agree?
Any exception and comment is warmly welcome.
Thanks for all your feedback,
Sam
_________________________________________________________
Do You Yahoo!?
150????MP3????????????????????????
http://cn.rd.yahoo.com/mail_cn/tag/yisou/music/*http://music.yisou.com/
??????????????????????????????????????
http://cn.rd.yahoo.com/mail_cn/tag/yisou/image/*http://image.yisou.com
1G????1000??????????????????????
http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_1g/
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
rpxlite board. Actually, there are at least five
different combination boards known as RPXlite CW.
So your changelog on FLASH size could use update
rather than correct.
> Sam> I cannot understand why CFG_RESET_ADDRESS
> > should be set as 0x09900000.
>
> It can be set to any illegal address so that memory
> access at this address will cause checkstop and
> then reset. 0x09900000 was used on
> some other boards, it has no special meaning.
Thanks for your notes,
Sam
___________________________________________________________
????????G????????????????????????????????????
http://cn.mail.yahoo.com/?id=77072
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
Nishant> Is it already included in u-boot 1.1.2?
No AFAIK. It's probably on Wolfgang's list.
Nishant> Once I have all the necessary source code (with the patch
Nishant> incorporated), what command(s) do I give to compile u-boot
Nishant> 1.1.2 for the EP8248 board?
Nishant> Will the following work:
Should be OK.
Nishant> $ export CROSS_COMPILE=ppc_82xx-
Nishant> $ export PATH=[path_to_ELDK]:$PATH
Nishant> $ make EP8248_config
Nishant> $ make
--
========================================================================
Yuli Barcohen | Phone +972-9-765-1788 | Software Project Leader
yuli at arabellasw.com | Fax +972-9-765-7494 | Arabella Software, Israel
========================================================================
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
Nishant> Is it already included in u-boot 1.1.2?
No AFAIK. It's probably on Wolfgang's list.
Nishant> Once I have all the necessary source code (with the patch
Nishant> incorporated), what command(s) do I give to compile u-boot
Nishant> 1.1.2 for the EP8248 board?
Nishant> Will the following work:
Should be OK.
Nishant> $ export CROSS_COMPILE=3Dppc_82xx-
Nishant> $ export PATH=3D[path_to_ELDK]:$PATH
Nishant> $ make EP8248_config
Nishant> $ make
--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Yuli Barcohen | Phone +972-9-765-1788 | Software Project Leader
yuli at arabellasw.com | Fax +972-9-765-7494 | Arabella Software, Israel
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
Nishant> Is it already included in u-boot 1.1.2?
No AFAIK. It's probably on Wolfgang's list.
Nishant> Once I have all the necessary source code (with the patch
Nishant> incorporated), what command(s) do I give to compile u-boot
Nishant> 1.1.2 for the EP8248 board?
Nishant> Will the following work:
Should be OK.
Nishant> $ export CROSS_COMPILE=3Dppc_82xx-
Nishant> $ export PATH=3D[path_to_ELDK]:$PATH
Nishant> $ make EP8248_config
Nishant> $ make
--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Yuli Barcohen | Phone +972-9-765-1788 | Software Project Leader
yuli at arabellasw.com | Fax +972-9-765-7494 | Arabella Software, Israel
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
=20
Note: Don't enable the "icache" and "dcache" commands
(configuration option CFG_CMD_CACHE) unless you know
what you (and your U-Boot users) are doing. Data
cache cannot be enabled on systems like the 8xx or
8260 (where accesses to the IMMR region must be
uncached), and it cannot be disabled on all other
systems where we (mis-) use the data cache to hold an
initial stack and some data.
=20
-----Original Message-----
From: u-boot-users-admin@lists.sourceforge.net =
[mailto:u-boot-users-admin at lists.sourceforge.net]On Behalf Of =
Dipen_Patel
Sent: Wednesday, August 03, 2005 8:24 AM
To: u-boot-users at lists.sourceforge.net
Cc: Lochana_Lingegowda
Subject: [U-Boot-Users] Problem while Enabling Data Cache for MPC8260 =
based custom board
Dear Mailing List,
=20
We have designed MPC8260 based custom board. I enabled I-Cache and =
u-boot still works. But as soon as I enabled D-Cache nothing comes up on =
Hyper Terminal.
=20
Can anyone suggest regarding this problem?=20
=20
Regards,
Dipen Patel
=20
DISCLAIMER:
This email (including any attachments) is intended for the sole use of =
the intended recipient/s and may contain material that is CONFIDENTIAL =
AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or =
copying or distribution or forwarding of any or all of the contents in =
this message is STRICTLY PROHIBITED. If you are not the intended =
recipient, please contact the sender by email and delete all copies; =
your cooperation in this regard is appreciated..=20
------_=_NextPart_001_01C5982E.35283978
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word"><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1505" name=3DGENERATOR>
<STYLE>@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in =
1.25in; }
P.MsoNormal {
FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
COLOR: purple; TEXT-DECORATION: underline
}
SPAN.EmailStyle17 {
COLOR: windowtext; FONT-FAMILY: Arial; mso-style-type: personal-compose
}
DIV.Section1 {
page: Section1
}
</STYLE>
</HEAD>
<BODY lang=3DEN-US vLink=3Dpurple link=3Dblue>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D664211913-03082005>From=20
the README file:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D664211913-03082005></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D664211913-03082005><FONT=20
face=3D"Courier New" color=3D#000080 size=3D1>
<P><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT face=3DArial =
color=3D#0000ff=20
size=3D2> Note: =
Don't enable=20
the "icache" and "dcache"=20
commands<BR> &=
nbsp; =20
(configuration option CFG_CMD_CACHE) unless you=20
know<BR>  =
; =20
what you (and your U-Boot users) are doing.=20
Data<BR>  =
; =20
cache cannot be enabled on systems like the 8xx=20
or<BR> &=
nbsp; =20
8260 (where accesses to the IMMR region must=20
be<BR> &=
nbsp; =20
uncached), and it cannot be disabled on all=20
other<BR> &nbs=
p; =20
systems where we (mis-) use the data cache to hold=20
an<BR> &=
nbsp; =20
initial stack and some data.</FONT></P>
<P><FONT face=3DArial color=3D#0000ff size=3D2></FONT></FONT><FONT =
face=3D"Courier New"=20
color=3D#000080 size=3D1> </P></FONT></SPAN></FONT></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
<DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
size=3D2>-----Original Message-----<BR><B>From:</B>=20
u-boot-users-admin at lists.sourceforge.net=20
[mailto:u-boot-users-admin at lists.sourceforge.net]<B>On Behalf Of=20
</B>Dipen_Patel<BR><B>Sent:</B> Wednesday, August 03, 2005 8:24=20
AM<BR><B>To:</B> u-boot-users at lists.sourceforge.net<BR><B>Cc:</B>=20
Lochana_Lingegowda<BR><B>Subject:</B> [U-Boot-Users] Problem while =
Enabling=20
Data Cache for MPC8260 based custom board<BR><BR></FONT></DIV>
<DIV class=3DSection1>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Dear Mailing=20
List,<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">We have designed MPC8260 =
based=20
custom board. I enabled I-Cache and u-boot still works. But as soon as =
I=20
enabled D-Cache nothing comes up on Hyper=20
Terminal.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Can anyone suggest =
regarding this=20
problem? <o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">Regards,</SPAN></FONT><o:p></o:p></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Dipen=20
Patel</SPAN></FONT><o:p></o:p></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p> </o:p></SPAN></FONT></P></DIV>
<P></P>
<P>DISCLAIMER:<BR>This email (including any attachments) is intended =
for the=20
sole use of the intended recipient/s and may contain material that is=20
CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance =
by others=20
or copying or distribution or forwarding of any or all of the contents =
in this=20
message is STRICTLY PROHIBITED. If you are not the intended recipient, =
please=20
contact the sender by email and delete all copies; your cooperation in =
this=20
regard is appreciated.. </P></BLOCKQUOTE></BODY></HTML>
------_=_NextPart_001_01C5982E.35283978--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
metal of the board connector does not match the metal of the contact
area on your SIMMs. I saw similar problems before with self-built SDRAM
SIMMs. The only way to get it working reliably was to use a board
connector with gold plated contacts and to use a SIMM with a gold plated
PCB. I am not a chemist or physicist but I think else the two different
materials after a while build up some strange alloy / oxide that ruins
the contact.
What's the plating of your board connector and what's the plating of the
SIMM contact area?
Regards
Mark
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
code. Please read the following carefully when you are working with
U-Boot and want to send your modifications back to the public source
tree:
(1) Comply with the coding standards:
All contributions to U-Boot must conform to the Linux kernel
coding style; see the file "Documentation/CodingStyle" in your
Linux kernel source directory.
Please note that U-Boot is implemented in C (and to some small
parts in Assembler); no C++ is used, so please do not use C++
style comments (//) in your code.
Please also comply with the following formatting rules:
- remove any trailing white space
- use TAB characters for indentation, not spaces
- make sure NOT to use DOS '\r\n' line feeds
- do not use more than 2 consecutive empty lines in source files
- do not add trailing empty lines to source files
Submissions which do not conform to the standards will be rejected
with a request to reformat the changes.
(2) Make separate commits for logically separate changes.
Unless your patch is really trivial, you should not be sending
out a patch that was generated between your working tree and your
local commit head. Instead, always make a commit with complete
commit message and generate a series of patches from your
repository. It is a good discipline.
Describe the technical details of the change(s).
If your description starts to get long, that's a sign that you
probably need to split up your commit to finer grained pieces.
Make sure to update the CHANGELOG file appropriately.
Don't forget to register yourself in the MAINTAINERS file if you
add new processor or board support.
(3) Use branches for sets of modifications that belong together
logically.
If you're adding support for a new processor or a new board or a
bigger new feature (like re-writing all code that deals with NAND
flash) then we strongly recommend to keep all this work in a
separate branch. This may not be strictly necessary for your own
work, but it will make your own life easier in the long term, and
if you ever intend to allow direct pulling from your tree this
will be mandatory.
See http://source.denx.net/en/view/Documents/GitAdvancedUse#Linux_subsystem_maintenance_usin
for some excellent advice.
(4) Always send plain patches only.
Do not send complete source files or tarballs with sources or
tarballs with patches. Do not send compressed or encoded files.
Anything that cannot be applied directly as a patch may be
rejected.
(5) Generate your patch using git/cogito out of your commits.
git diff tools generate unidiff which is the preferred format.
You do not have to be afraid to use -M option to "git diff" or
"git format-patch", if your patch involves file renames. The
receiving end can handle them just fine.
Please make sure your patch does not include any extra files
which do not belong in a patch submission. Make sure to review
your patch after generating it, to ensure accuracy. Before
sending out, please make sure it cleanly applies to the "master"
branch head.
(6) Sending your patches.
People on the U-Boot mailing list needs to be able to read and
comment on the changes you are submitting. It is important for a
developer to be able to "quote" your changes, using standard
e-mail tools, so that they may comment on specific portions of
your code. For this reason, all patches should be submitting
e-mail "inline". WARNING: Be wary of your MUAs word-wrap
corrupting your patch. Do not cut-n-paste your patch.
Plain text(!) MIME attachments are acceptable, too.
Remember that there is a size limit of 40 kB for postings on the
mailing list. If you find yourself running into this limit this is
an indication that you probably need to split up your commit into
smaller pieces.
It is common convention to prefix your subject line with [PATCH].
This lets people easily distinguish patches from other e-mail
discussions.
"git format-patch" command follows the best current practice to
format the body of an e-mail message. At the beginning of the
patch should come your commit message, ending with the
Signed-off-by: lines, and a line that consists of three dashes,
followed by the diffstat information and the patch itself. If you
are forwarding a patch from somebody else, optionally, at the
beginning of the e-mail message just before the commit message
starts, you can put a "From: " line to name that person.
You often want to add additional explanation about the patch,
other than the commit message itself. Place such "cover letter"
material between the three dash lines and the diffstat.
Never send compressed or encoded messages. Do not let your e-mail
client send quoted-printable. Many popular e-mail applications
will not always transmit a MIME attachment as plain text, making
it impossible to comment on your code. A MIME attachment also
takes a bit more time to process. This does not decrease the
likelihood of your MIME-attached change being accepted, but it
makes it more likely that it will be postponed.
Exception: If your mailer is mangling patches then someone may
ask you to re-send them using MIME.
NEVER SEND HTML MESSAGES TO THE LIST. NEVER!!!
Note that your maintainer is subscribed to the U-Boot mailing
list so there is no need to put him on separate Cc:
(7) Sign your work
To improve tracking of who did what, we've borrowed the
"sign-off" procedure from the Linux kernel project on patches
that are being emailed around. Although U-Boot is a lot smaller
project it is a good discipline to follow it.
The sign-off is a simple line at the end of the explanation for
the patch, which certifies that you wrote it or otherwise have
the right to pass it on as a open-source patch (more precisely:
as Free Software under GPL). The rules are pretty simple: if you
can certify the below:
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me
and I have the right to submit it under the open source
license indicated in the file; or
(b) The contribution is based upon previous work that, to the
best of my knowledge, is covered under an appropriate
open source license and I have the right under that
license to submit that work with modifications, whether
created in whole or in part by me, under the same open
source license (unless I am permitted to submit under a
different license), as indicated in the file; or
(c) The contribution was provided directly to me by some
other person who certified (a), (b) or (c) and I have not
modified it.
(d) I understand and agree that this project and the
contribution are public and that a record of the
contribution (including all personal information I submit
with it, including my sign-off) is maintained
indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
then you just add a line saying
Signed-off-by: Random J Developer <random@developer.example.org>
Releases:
=========
Our intention is to produce "releases" of U-Boot much more frequently
now. We will use the following numbering scheme for U-Boot releases:
version.patchlevel.sublevel
Releases where "sublevel" is zero will be called "stable". The
previous release was 1.1.3, and we're working on 1.1.4 now, so the
next "stable" release might be called "1.2.0".
That's it for now. Hope you git along with all this Great New Stuff :-)
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
By the way, ALL software projects are done by iterative prototyping.
Some companies call their prototypes "releases", that's all.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
#define CFG_MALLOC_LEN=09=09(CFG_ENV_SIZE + 10240*1024)
Size of uncompressed:
romfs image: 4965376 bytes,
kernel image: 1044480 bytes.
But the problem disappears when I remove "bootm" from autoscript.
And run:
"bootm 5100000 5400000"
by hand in console after downloading images by the script.
The kernel boots and mounts romfs.
Below I put autoscript and log of deflating images.
Best Regards,
Maciej Witaszek
-------------------- autoscript --------------------------
echo =3D=3D=3D U-boot sets =3D=3D=3D
setenv kernel_img 5100000
setenv romfs_img 5400000
echo =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Load uClinux kernel image =3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
tftpboot $(kernel_img) uClinux
echo =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Load ROMfs image =3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
tftpboot $(romfs_img) uClinux_romfs
iminfo $(kernel_img)
iminfo $(romfs_img)
bootm $(kernel_img) $(romfs_img)
--------------------------------------------------------------
--------------- u-boot downloading images ---------------
U-Boot 1.1.2 (Aug 29 2005 - 20:18:29)
CPU: Nios-32 Rev. 3.3 (0x3038)
Reg file size: 256 LO_LIMIT/HI_LIMIT: 1/14
Board: Altera Nios 20K200E Development Kit
In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0
eth_init
eth_reset
CS8900 Ethernet chip found!
BOOTP broadcast 1
DHCPHandler: got packet: (src=3D67, dst=3D68, len=3D300) state: 3
Filtering pkt =3D 0
DHCPHandler: got DHCP packet: (src=3D67, dst=3D68, len=3D300) state: 3
DHCP: state=3DSELECTING bp_file: ""
TRANSITIONING TO REQUESTING STATE
Bootfile:
DhcpSendRequestPkt: Sending DHCPREQUEST
Transmitting DHCPREQUEST packet: len =3D 343
DHCPHandler: got packet: (src=3D67, dst=3D68, len=3D300) state: 4
Filtering pkt =3D 0
DHCPHandler: got DHCP packet: (src=3D67, dst=3D68, len=3D300) state: 4
DHCP State: REQUESTING
DHCP_ACK
Bootfile:
DHCP client bound to address 10.0.0.99
*** Warning: no boot file name; using '6300000A.img'
TFTP from server 10.0.0.5; our IP address is 10.0.0.99
Filename '6300000A.img'.
Load address: 0x40000
Loading: #
done
Bytes transferred =3D 405 (195 hex)
## Executing script at 00040000
** Script length: 333
** exec: "echo =3D=3D=3D U-boot sets =3D=3D=3D"
=3D=3D=3D U-boot sets =3D=3D=3D
** exec: "setenv kernel_img 5100000"
** exec: "setenv romfs_img 5400000"
** exec: "echo =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Load uClinux kernel =
image =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D"
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Load uClinux kernel image =3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
** exec: "tftpboot $(kernel_img) uClinux"
eth_init
eth_reset
CS8900 Ethernet chip found!
Interrupt vector 17: handler 0x3f81920 replacing 0x3f81920
TFTP from server 10.0.0.5; our IP address is 10.0.0.99
Filename 'uClinux'.
Load address: 0x5100000
Loading: #################################################################
##################
done
Bytes transferred =3D 423246 (6754e hex)
** exec: "echo =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Load ROMfs image =3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D"
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Load ROMfs image =3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
** exec: "tftpboot $(romfs_img) uClinux_romfs"
eth_init
eth_reset
CS8900 Ethernet chip found!
Interrupt vector 17: handler 0x3f81920 replacing 0x3f81920
TFTP from server 10.0.0.5; our IP address is 10.0.0.99
Filename 'uClinux_romfs'.
Load address: 0x5400000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
#################################################################
done
Bytes transferred =3D 1662981 (196005 hex)
** exec: "iminfo $(kernel_img)"
## Checking Image at 05100000 ...
Image Name: uCLinux Kernel Image for NIOS32
Image Type: Unknown Architecture Linux Kernel Image (gzip compressed)
Data Size: 423182 Bytes =3D 413.3 kB
Load Address: 04000000
Entry Point: 04000000
Verifying Checksum ... OK
** exec: "iminfo $(romfs_img)"
## Checking Image at 05400000 ...
Image Name: uClinux ROM disk
Image Type: Unknown Architecture Linux RAMDisk Image (gzip compressed)
Data Size: 1662917 Bytes =3D 1.6 MB
Load Address: 06000000
Entry Point: 06000000
Verifying Checksum ... OK
** exec: "bootm $(kernel_img) $(romfs_img)"
Boot reached stage 1
## Booting image at 05100000 ...
Boot reached stage 2
Boot reached stage 3
Image Name: uCLinux Kernel Image for NIOS32
Image Type: Unknown Architecture Linux Kernel Image (gzip compressed)
Data Size: 423182 Bytes =3D 413.3 kB
Load Address: 04000000
Entry Point: 04000000
Verifying Checksum ... OK
Boot reached stage 4
Boot reached stage 5
Boot reached stage 6
Uncompressing Kernel Image ... Error: inflate() returned -4
GUNZIP ERROR - must RESET board to recover
Boot reached stage -6
####### REBOOT is needed #######
Press reset button on your board
FIXME - on production board do sth better
Unhandled interrupt: 0x0
OK
Boot reached stage 7
Boot reached stage 8
Boot reached stage 9
## Loading Ramdisk Image at 05400000 ...
Boot reached stage 10
Image Name: uClinux ROM disk
Image Type: Unknown Architecture Linux RAMDisk Image (gzip compressed)
Data Size: 1662917 Bytes =3D 1.6 MB
Load Address: 06000000
Entry Point: 06000000
Verifying Checksum ... OK
Boot reached stage 11
Uncompressing ROM image ...Error: inflateInit2() returned -4
GUNZIP ERROR - must RESET board to recover
Boot reached stage -6
####### REBOOT is needed #######
Press reset button on your board
FIXME - on production board do sth better
Unhandled interrupt: 0x0
OK
Boot reached stage 15
Starting kernel at 0x04000000...
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
And the in_ram label. Somehow, on my BDI, it sees an exception and goes
to the reset vector i.e 0x100.
My approach is to avoid the GOT stuff and write a test routine which is
Position dependant and copy the function to address 0x0 in RAM. After
Executing the code in RAM, jump back to flash. People over here think
That since the I-cache is enabled, the processor may burst but we are
Fixing some bugs with that. The CS has BI flag set.
Does someone have some sample code for putting embedded C/assembly code ?
My approach was to copy the memset routine from flash to RAM at address 0x0.
Then do a memset from address 0x0 + sizeof(memset) to user given input of
End of RAM. This way, I run memset from RAM and verify that it actually
works with my peek/poke routine from flash.
My first cut at it is here but it is complaining about GOT. Not enough
experience with ld... Help/tips ??
__asm__ __volatile__( \
" lis r10, 0x0 at h\n" \
" eieio\n" \
" lis r3, address at l\n" \
" ori r3, r3, address at h\n" \
" lis r4, fillpattern at l\n" \
" ori r4, r4, fillpattern at h\n" \
" lis r5, bytecount at l\n" \
" ori r5, r5, bytecount at h\n" \
" b 0x0\n" \
);
Thanks,
Atul
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
But, when I am booting the system now, its hanging after displaying
the RAM configuration.
I have just begun to trace down on what could be wrong,but it looks
from initial traces to be in flash_init.
Anything I am missing / doing wrong ??
2) Read somewhere on net, that by deault all sectors are locked after
reboo t ? true ? does J3 Intel strata flash does it also automatically
?
3) Remember to do so after relocation to RAM. :: Can you please help
me to correct place, code path / function to do so ? I am very new to
u-boot.
Regards,
Alfred
On 1/8/06, Wolfgang Denk <wd@denx.de> wrote:
> In message <29f916510601080721vd20b512u819ee9bce7ad1408@mail.gmail.com> y=
ou wrote:
> >
> > 1) Does u-boot lock the block on which it resides by default ?
>
> Not by default, but you can inplement in your flah driver whichever
> features you like.
>
> > I mean the sector /erase block on which u-boot is there, it will be
> > locked using the block lock bit by default ?
>
> Remember that only few flash chips provide such hardware locking, and
> that some boards implement even other ways of write protection of
> parts of or of the whole flash device.
>
> > 2) The flash content changing has to work in block sizes erase -
> > modify - write cyecles only ??
>
> No. You can write single bytes (as long as you are only changing '1'
> bits to '0').
>
> > Reason for all this is that we have few boards on which u-boot is
> > getting corrupted (on flash image corruption itself).
> > And so am wondering even if its a noise issue, how can it first cause
> > an unlock of sector before write.
>
> Normally the flash is not hardare write protected, and if your
> hardware designer used flash chips which can be corrupted for example
> by just writing arbitrary data to a sequential address range you may
> easily see such corruption. There is a very good reason why AMD flash
> chips require a specific programming sequence which must be written
> in a certain sequence to certain non-consequitive addresses.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> Software Engineering: Embedded and Realtime Systems, Embedded Linux
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> PoB =3D "Prisoner of Bill" -- those held captive, unwillingly or other-
> wise, by the contemptible Microsoft monopoly.
> -- Tom Christiansen in <6abo45$3lc$2@csnews.cs.colorado.edu>
>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
loaded into ram and then using the "eeprom write"
command we should be able to program the eeprom.
=> tftp 100000 eeprom.bin
=> md 100000
=> eeprom write 100000 0 100
=> eeprom read 150000 0 100
=> md 150000
However, when I try the above and check the eeprom
content only the last few bytes are programmed. Any
idea? How to generate this bin file? Also, the "imd"
command is not working properly on my set up.
I am using u-boot version 1.1.2 on a custom board with
mpc8541 cpu.
Thanks much for any help!
Regards,
Rahmat
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
====================
=> print ncip;print nc;print ipaddr;print serverip
ncip=192.168.1.1
nc=setenv stdin nc;setenv stdout nc
ipaddr=192.168.1.2
serverip=192.168.1.1
=> run nc
on the host net console:
========================
$ ./ncip.bash 192.168.1.2
=> <INTERRUPT>
=>
=>
=>
Best regards,
Rahmat
--- Wolfgang Denk <wd@denx.de> wrote:
> In message
>
<20060315034908.2096.qmail@web30512.mail.mud.yahoo.com>
> you wrote:
> >
> > 1-Not having access to DUART header at test side,
> is
> > there a way to get a console to u-boot through
> TSEC
> > interface. If so may I get a pointer to the
> > patch/code?
>
> See doc/README.NetConsole
>
> > 2-Has anyone done a menu based diagnostics tool in
>
> Menu based? That's a different reality system.
>
> > u-boot/kernel to test hardware interfaces(CPU,
> > memory,pci & etc...) for PPC/MPC cpu families that
> I
> > may be able to leverage from. This is normally
>
> See the post/ directory; parts will need adaption /
> porting for 85xx.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> Software Engineering: Embedded and Realtime
> Systems, Embedded Linux
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80
> Email: wd at denx.de
> Of course there's no reason for it, it's just our
> policy.
>
>
>
-------------------------------------------------------
> This SF.Net email is sponsored by xPML, a
> groundbreaking scripting language
> that extends applications into web and mobile media.
> Attend the live webcast
> and join the prime developer group breaking into
> this new coding territory!
>
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x110944&bid$1720&dat\x121642
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
>
https://lists.sourceforge.net/lists/listinfo/u-boot-users
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-08-19 20:18 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-08-19 20:18 UTC (permalink / raw)
To: u-boot
up register wise to the ATA comand registers, so it seems to mee that it
should be possible to use the ATA driver with some minimal local
controller setup.
=20
> -----Original Message-----
> From: u-boot-users-admin at lists.sourceforge.net=20
> [mailto:u-boot-users-admin at lists.sourceforge.net] On Behalf=20
> Of jack zhao
> Sent: Wednesday, April 12, 2006 04:16
> To: u-boot-users at lists.sourceforge.net
> Subject: [U-Boot-Users] SATA disk support in u-boot
>=20
> Hi,
>=20
> Could someone tell me if U-boot supports SATA disk?=20
> How to support? The current SATA chip I am using is sil3114.=20
>=20
> =20
>=20
> Best Wishes
>=20
> Jack Zhao
>=20
> USI SH R&D Center 86-021-58966996-1122
>=20
>=20
>=20
> =20
>=20
>=20
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-07-29 0:03 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-07-29 0:03 UTC (permalink / raw)
To: u-boot
I would remove this level, and use the third level for stable branch
bugfixes releases instead.
It is very unlikely to release feature-upgrade releases within one month/
Leon.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-07-29 0:03 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-07-29 0:03 UTC (permalink / raw)
To: u-boot
BMW-related configuration bits and verify all the clock settings,
memory settings, etc for your exact version of the board. IIRC the
vendor was a bit prone to changing such things between different
versions.
Good luck!
John
--
John W. Linville
linville at tuxdriver.com
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-07-29 0:03 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-07-29 0:03 UTC (permalink / raw)
To: u-boot
"99% relocation problems come from burst mode" issue.
But I don't really know where to investigate. From the manual of my SDRAM
(MT48LC16M16A2), the init sequence is very similar to eg. ep82xxm's one.
Could this be a timing issue ? I don't see much timing in ep82xxm code for
example. Or perhaps the MRW configuration is not enough to correctly
configure burst mode ? (Of course I'm also new in SDRAM init...)
Thanks for ELDK and U-Boot, they are really great.
Best regards,
R=E9mi Lefevre
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-07-29 0:03 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-07-29 0:03 UTC (permalink / raw)
To: u-boot
drivers/mtd/nand/fsl_elbc_nand.c | 17 ++++++++++++++++-
1 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index 674c542..b8bc143 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -122,6 +122,20 @@ static struct nand_ecclayout fsl_elbc_oob_lp_eccm1 = {
.oobavail = 48,
};
+/*
+ * fsl_elbc_oob_lp_eccm* specify that LP NAND's OOB free area starts at offset
+ * 1, so we have to adjust bad block pattern. This pattern should be used for
+ * x8 chips only. So far hardware does not support x16 chips anyway.
+ */
+static u8 scan_ff_pattern[] = { 0xff, };
+
+static struct nand_bbt_descr largepage_memorybased = {
+ .options = 0,
+ .offs = 0,
+ .len = 1,
+ .pattern = scan_ff_pattern,
+};
+
/*=================================*/
/*
@@ -750,9 +764,10 @@ int board_nand_init(struct nand_chip *nand)
priv->fmr = (15 << FMR_CWTO_SHIFT) | (2 << FMR_AL_SHIFT);
- /* adjust Option Register and ECC to match Flash page size */
+ /* Large-page-specific setup */
if (or & OR_FCM_PGS) {
priv->page_size = 1;
+ nand->badblock_pattern = &largepage_memorybased;
/* adjust ecc setup if needed */
if ((br & BR_DECC) == BR_DECC_CHK_GEN) {
--
1.5.6.rc1.6.gc53ad
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2008-07-29 0:03 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-07-29 0:03 UTC (permalink / raw)
To: u-boot
drivers/mtd/nand/fsl_elbc_nand.c | 35 ++++++++++++++++++++++++++++++++++-
1 files changed, 34 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index b8bc143..e4e4de0 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -136,6 +136,34 @@ static struct nand_bbt_descr largepage_memorybased = {
.pattern = scan_ff_pattern,
};
+/*
+ * ELBC may use HW ECC, so that OOB offsets, that NAND core uses for bbt,
+ * interfere with ECC positions, that's why we implement our own descriptors.
+ * OOB {11, 5}, works for both SP and LP chips, with ECCM = 1 and ECCM = 0.
+ */
+static u8 bbt_pattern[] = {'B', 'b', 't', '0' };
+static u8 mirror_pattern[] = {'1', 't', 'b', 'B' };
+
+static struct nand_bbt_descr bbt_main_descr = {
+ .options = NAND_BBT_LASTBLOCK | NAND_BBT_CREATE | NAND_BBT_WRITE |
+ NAND_BBT_2BIT | NAND_BBT_VERSION,
+ .offs = 11,
+ .len = 4,
+ .veroffs = 15,
+ .maxblocks = 4,
+ .pattern = bbt_pattern,
+};
+
+static struct nand_bbt_descr bbt_mirror_descr = {
+ .options = NAND_BBT_LASTBLOCK | NAND_BBT_CREATE | NAND_BBT_WRITE |
+ NAND_BBT_2BIT | NAND_BBT_VERSION,
+ .offs = 11,
+ .len = 4,
+ .veroffs = 15,
+ .maxblocks = 4,
+ .pattern = mirror_pattern,
+};
+
/*=================================*/
/*
@@ -738,7 +766,12 @@ int board_nand_init(struct nand_chip *nand)
nand->waitfunc = fsl_elbc_wait;
/* set up nand options */
- nand->options = NAND_NO_READRDY | NAND_NO_AUTOINCR;
+ nand->bbt_td = &bbt_main_descr;
+ nand->bbt_md = &bbt_mirror_descr;
+
+ /* set up nand options */
+ nand->options = NAND_NO_READRDY | NAND_NO_AUTOINCR |
+ NAND_USE_FLASH_BBT;
nand->controller = &elbc_ctrl->controller;
nand->priv = priv;
--
1.5.6.rc1.6.gc53ad
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2008-07-29 0:03 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-07-29 0:03 UTC (permalink / raw)
To: u-boot
drivers/mtd/nand/fsl_elbc_nand.c | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index e4e4de0..4351824 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -95,7 +95,6 @@ static struct nand_ecclayout fsl_elbc_oob_sp_eccm0 = {
.eccbytes = 3,
.eccpos = {6, 7, 8},
.oobfree = { {0, 5}, {9, 7} },
- .oobavail = 12,
};
/* Small Page FLASH with FMR[ECCM] = 1 */
@@ -103,7 +102,6 @@ static struct nand_ecclayout fsl_elbc_oob_sp_eccm1 = {
.eccbytes = 3,
.eccpos = {8, 9, 10},
.oobfree = { {0, 5}, {6, 2}, {11, 5} },
- .oobavail = 12,
};
/* Large Page FLASH with FMR[ECCM] = 0 */
@@ -111,7 +109,6 @@ static struct nand_ecclayout fsl_elbc_oob_lp_eccm0 = {
.eccbytes = 12,
.eccpos = {6, 7, 8, 22, 23, 24, 38, 39, 40, 54, 55, 56},
.oobfree = { {1, 5}, {9, 13}, {25, 13}, {41, 13}, {57, 7} },
- .oobavail = 48,
};
/* Large Page FLASH with FMR[ECCM] = 1 */
@@ -119,7 +116,6 @@ static struct nand_ecclayout fsl_elbc_oob_lp_eccm1 = {
.eccbytes = 12,
.eccpos = {8, 9, 10, 24, 25, 26, 40, 41, 42, 56, 57, 58},
.oobfree = { {1, 7}, {11, 13}, {27, 13}, {43, 13}, {59, 5} },
- .oobavail = 48,
};
/*
--
1.5.6.rc1.6.gc53ad
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2008-07-29 0:03 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-07-29 0:03 UTC (permalink / raw)
To: u-boot
i386 port ever worked. u-boot.lds sets up a real mode trampoline
at 0x000007c0 and some BIOS emulation at 0x0000 - 0x053e. The next
4-byte alignment (0x0540) is where __u_boot_cmd_start is supposed to
end up in memory. Going by u-boot.map, the load address of .bios is
0x3805214e - Add 0x540 gives 0x3805268e which is 0x1268e into
u-boot.bin which is exactly where I found found the command table.
BUT - The command table is never, as far as I can tell, copied into
RAM - .bios is by bios_setup () in /lib_i386/bios_setup.c
So, it looks like I could add:
_i386boot__u_boot_cmd_start = LOADADDR(.u_boot_cmd);
and
_i386boot__u_boot_cmd_size = SIZEOF(.u_boot_cmd);
and copy the command table into RAM at 0x0540 and all should be well.
At the same time, I could copy .text into RAM and adjust the target
addresses in the command table (I can grab this code from other
platforms)
QUESTIONS:
- Where should I relocate to? I have 128MB to play with - should I
relocate to the highest possible location in RAM and if so,
should I change to setup of the stack, bss and data segments to
be high in RAM as well? Is there any advantages, especially when
loading the linux kernel, in locating U-Boot at any particular
location in RAM?
- Should I shuffle the link script a little to that the order of
segments is .data, .got, .u_boot_cmd then .bss, .realmode and
.bios and set:
_i386boot_romdata_size = SIZEOF(.data) + SIZEOF(.got) +
SIZEOF(.u_boot_cmd)
This would have the advantage that I could use a single copy
operation to copy .data, .got and .u_boot_cmd
- Is the code in .text natively relocatable or do I need to do
something (gcc or ld options) to make it relocatable?
Thanks for your patience
Regards,
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-07-29 0:03 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-07-29 0:03 UTC (permalink / raw)
To: u-boot
i386 port ever worked. u-boot.lds sets up a real mode trampoline
at 0x000007c0 and some BIOS emulation at 0x0000 - 0x053e. The next
4-byte alignment (0x0540) is where __u_boot_cmd_start is supposed to
end up in memory. Going by u-boot.map, the load address of .bios is
0x3805214e - Add 0x540 gives 0x3805268e which is 0x1268e into
u-boot.bin which is exactly where I found found the command table.
BUT - The command table is never, as far as I can tell, copied into
RAM - .bios is by bios_setup () in /lib_i386/bios_setup.c
So, it looks like I could add:
_i386boot__u_boot_cmd_start = LOADADDR(.u_boot_cmd);
and
_i386boot__u_boot_cmd_size = SIZEOF(.u_boot_cmd);
and copy the command table into RAM at 0x0540 and all should be well.
At the same time, I could copy .text into RAM and adjust the target
addresses in the command table (I can grab this code from other
platforms)
QUESTIONS:
- Where should I relocate to? I have 128MB to play with - should I
relocate to the highest possible location in RAM and if so,
should I change to setup of the stack, bss and data segments to
be high in RAM as well? Is there any advantages, especially when
loading the linux kernel, in locating U-Boot at any particular
location in RAM?
- Should I shuffle the link script a little to that the order of
segments is .data, .got, .u_boot_cmd then .bss, .realmode and
.bios and set:
_i386boot_romdata_size = SIZEOF(.data) + SIZEOF(.got) + SIZEOF(.u_boot_cmd)
This would have the advantage that I could use a single copy
operation to copy .data, .got and .u_boot_cmd
- Is the code in .text natively relocatable or do I need to do
something (gcc or ld options) to make it relocatable?
Thanks for your patience
Regards,
Graeme
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-07-29 0:03 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-07-29 0:03 UTC (permalink / raw)
To: u-boot
i386 port ever worked. u-boot.lds sets up a real mode trampoline
at 0x000007c0 and some BIOS emulation at 0x0000 - 0x053e. The next
4-byte alignment (0x0540) is where __u_boot_cmd_start is supposed to
end up in memory. Going by u-boot.map, the load address of .bios is
0x3805214e - Add 0x540 gives 0x3805268e which is 0x1268e into
u-boot.bin which is exactly where I found found the command table.
BUT - The command table is never, as far as I can tell, copied into
RAM - .bios is by bios_setup () in /lib_i386/bios_setup.c
So, it looks like I could add:
_i386boot__u_boot_cmd_start = LOADADDR(.u_boot_cmd);
and
_i386boot__u_boot_cmd_size = SIZEOF(.u_boot_cmd);
and copy the command table into RAM at 0x0540 and all should be well.
At the same time, I could copy .text into RAM and adjust the target
addresses in the command table (I can grab this code from other
platforms)
QUESTIONS:
- Where should I relocate to? I have 128MB to play with - should I
relocate to the highest possible location in RAM and if so,
should I change to setup of the stack, bss and data segments to
be high in RAM as well? Is there any advantages, especially when
loading the linux kernel, in locating U-Boot at any particular
location in RAM?
- Should I shuffle the link script a little to that the order of
segments is .data, .got, .u_boot_cmd then .bss, .realmode and
.bios and set:
_i386boot_romdata_size = SIZEOF(.data) + SIZEOF(.got) + SIZEOF(.u_boot_cmd)
This would have the advantage that I could use a single copy
operation to copy .data, .got and .u_boot_cmd
- Is the code in .text natively relocatable or do I need to do
something (gcc or ld options) to make it relocatable?
Thanks for your patience
Regards,
Graeme
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-07-29 0:03 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-07-29 0:03 UTC (permalink / raw)
To: u-boot
lead to MMU init failures inside Linux ?
Particularly, my Linux kernel fails during the first Data Cache Block Store
instruction (dcbst) of the MMU init and I ask myself if this cannot be link=
ed
to my cache initialization inside U-Boot (HID0 for my MPC8270 board).
See http://ozlabs.org/pipermail/linuxppc-embedded/2008-September/031398.htm=
l
for more details.
Regards,
R=E9mi
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-07-29 0:03 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-07-29 0:03 UTC (permalink / raw)
To: u-boot
starts, is that something we want to look into?
If you are not familiar with this board it is supposed to be very similar t=
o
the AT91SAM9260EK.
Please help us figure this one out!
Regards
Bj=F6rn Sal=E4ng & Andreas Gising
------=_Part_11424_30783184.1222855385454--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-07-29 0:03 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-07-29 0:03 UTC (permalink / raw)
To: u-boot
boot loader.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The only person who always got his work done by Friday
was Robinson Crusoe.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-07-29 0:03 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-07-29 0:03 UTC (permalink / raw)
To: u-boot
care about guaranteeing any deterministic behaviour in case both
input channels transfer data at the same time. If such a simultaneous
transaction happens, your input data stream (for both channels) is
likely to get corrupted (without any error indication).
I interpret the fact that your code does not care about this as an
indication that such situations are very untypical for your mode of
usage - but then why do we need to provide code that focuses on such
a case?
So my question is: does it really make sense to continue polling the
network console while a serial data transfer is in progress? [*]
I do not think so.
[*] Of course the same is true for the other direction - but there
situation is much easier becahuse (a) the serial driver is very
fast and (b) the nc code already handles multi-byte data packets.
My suggestion is to make the multiplexing more intelligent instead of
making the serial driver more complex. The nice thing with this is
that you probably still get the same results (actually even better
ones as the artificial 128 byte line lengt limit can be avoided), and
the changes are only in the new code, i. e. users who do not need
such I/O multiplexing will not be affected.
I think it should be fairly simple to implement something similar to
the VTIME feature for non-canonical reads in the Unix serial drivers
(see "man tcsetattr"):
- In idle mode, all configured input devices are polled in a
round-robin manner (as it is done now).
- As soon as a character is received on the serial line, a timestamp
is taken. As you calculated, one character at 115 kbps takes about
100 us on the wire. Within a window of (for exmaple) 500 us (or
about 5 character times) now polling of all other I/O ports will be
skipped.
This should give you raw serial driver performacne while a serial
data transfer is running, while keeping functionality for all other
use cases.
What do you think?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
In general, they do what you want, unless you want consistency.
- Larry Wall in the perl man page
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-07-29 0:03 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-07-29 0:03 UTC (permalink / raw)
To: u-boot
> The patch is against u-boot commit 055b12f2ffd7c34eea7e983a0588b24f2e69e0e3
> (Date: Sun Oct 19 21:54:30 2008 +0200) but should apply to newer commits as
> well, because the code is mostly seperated.
>
> If you have any comments please email to me.
>
> Is is possible to include that patch in the new version of u-boot?
>
> Regards
>
> J?rgen Sch?w
>
> --
> Dipl.-Ing. J?rgen Sch?w, emlix GmbH, http://www.emlix.com, mailto:js at emlix.com
> Fon +49 551 30664-0, Fax -11, Bahnhofsallee 1b, 37081 G?ttingen, Germany
> Gesch?ftsf?hrung: Dr. Uwe Kracke, Dr. Cord Seele, Ust-IdNr.: DE 205 198 055
> Sitz der Gesellschaft: G?ttingen, Amtsgericht G?ttingen HR B 3160
>
> emlix - your embedded linux partner
to here is supposed to be after ---
> -----
>
> Signed-off-by: J?rgen Sch?w <js@emlix.com>
> Signed-off-by: Sebastian Hess <sh@emlix.com>
> Signed-off-by: Matthias Mwenzel <nxp@mazzoo.de>
> Signed-off-by: Dirk H?rner <dirk.hoerner@dspg.com>
> Signed-off-by: Andreas Wei?el <andreas.weissel@dspg.com>
>
and sob before
first a question
who build this board?
> Diffstat:
> MAKEALL | 1 +
> Makefile | 7 +
> board/firetux/Makefile | 62 +++
> board/firetux/config.mk | 45 ++
> board/firetux/ethernet.c | 970 +++++++++++++++++++++++++++++++++++++++++
> board/firetux/ethernet.h | 234 ++++++++++
> board/firetux/firetux.c | 554 +++++++++++++++++++++++
> board/firetux/firetux.h | 118 +++++
> board/firetux/lowlevel_init.S | 413 ++++++++++++++++++
> board/firetux/memsetup.S | 366 ++++++++++++++++
> board/firetux/nand.c | 74 ++++
> board/firetux/relocate.S | 246 +++++++++++
> board/firetux/u-boot.lds | 57 +++
> drivers/i2c/Makefile | 1 +
> drivers/i2c/pnx8181_i2c.c | 302 +++++++++++++
> include/configs/firetux.h | 455 +++++++++++++++++++
> net/bootp.c | 11 +
> net/eth.c | 7 +
> 18 files changed, 3923 insertions(+), 0 deletions(-)
>
>
> diff --git a/MAKEALL b/MAKEALL
> index 9ccb9ac..0ba8e4d 100755
> --- a/MAKEALL
> +++ b/MAKEALL
> @@ -480,6 +480,7 @@ LIST_ARM9=" \
> cp926ejs \
> cp946es \
> cp966 \
> + firetux \
> lpd7a400 \
> mx1ads \
> mx1fs2 \
> diff --git a/Makefile b/Makefile
> index 9a132f7..8c3b076 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -2683,6 +2683,13 @@ voiceblue_config: unconfig
> @$(MKCONFIG) $(@:_config=) arm arm925t voiceblue
>
> #########################################################################
> +## NXP PNX8181 "firetux"
> +#########################################################################
> +
> +firetux_config:unconfig
> + @$(MKCONFIG) $(@:_config=) arm arm926ejs firetux # manufacturer SOC
^^^^^^^^^^^^^^^^^^
please remove
> +
> +#########################################################################
> ## S3C44B0 Systems
> #########################################################################
>
> diff --git a/board/firetux/Makefile b/board/firetux/Makefile
> new file mode 100644
> index 0000000..a643a5e
> --- /dev/null
> +++ b/board/firetux/Makefile
> @@ -0,0 +1,62 @@
> +# firetux makefile
> +#
> +# (C) Copyright 2007-2008, emlix GmbH, Germany
> +# Juergen Schoew <js@emlix.com>
> +#
> +# (C) Copyright 2008, DSPG Technologies GmbH, Germany
> +# (C) Copyright 2007, NXP Semiconductors Germany GmbH
> +# Matthias Wenzel, <nxp@mazzoo.de>
> +#
> +# See file CREDITS for list of people who contributed to this
> +# project.
> +#
> +# This program is free software; you can redistribute it and/or
> +# modify it under the terms of the GNU General Public License as
> +# published by the Free Software Foundation; either version 2 of
> +# the License, or (at your option) any later version.
> +#
> +# This program is distributed in the hope that it will be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> +# GNU General Public License for more details.
> +#
> +# You should have received a copy of the GNU General Public License
> +# along with this program; if not, write to the Free Software
> +# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> +# MA 02111-1307 USA
> +#
> +
> +include $(TOPDIR)/config.mk
> +
> +LIB = $(obj)lib$(BOARD).a
> +
> +COBJS := firetux.o ethernet.o
> +SOBJS := lowlevel_init.o memsetup.o relocate.o
> +
> +#ifdef CONFIG_CMD_NAND
> +COBJS += nand.o
> +#endif
please use COBJS-$(CONFIG_CMD_NAND)
> +
> +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
> +OBJS := $(addprefix $(obj),$(COBJS))
> +SOBJS := $(addprefix $(obj),$(SOBJS))
> +
> +all: $(LIB)
> +
> +$(LIB): $(obj).depend $(OBJS) $(SOBJS)
> + $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS)
> +
> +clean:
> + rm -f $(SOBJS) $(OBJS)
> +
> +distclean: clean
> + rm -f $(LIB) core *.bak .depend
> +
> +#########################################################################
> +
> +# defines $(obj).depend target
> +include $(SRCTREE)/rules.mk
> +
> +sinclude $(obj).depend
> +
> +#########################################################################
> diff --git a/board/firetux/config.mk b/board/firetux/config.mk
> new file mode 100644
> index 0000000..bcdd671
> --- /dev/null
> +++ b/board/firetux/config.mk
> @@ -0,0 +1,45 @@
> +# firetux compiler config
> +#
> +# (C) Copyright 2007-2008, emlix GmbH, Germany
> +# Juergen Schoew <js@emlix.com>
> +#
> +# (C) Copyright 2008, DSPG Technologies GmbH, Germany
> +# (C) Copyright 2007, NXP Semiconductors Germany GmbH
> +# Matthias Wenzel, <nxp@mazzoo.de>
> +#
> +# See file CREDITS for list of people who contributed to this
> +# project.
> +#
> +# This program is free software; you can redistribute it and/or
> +# modify it under the terms of the GNU General Public License as
> +# published by the Free Software Foundation; either version 2 of
> +# the License, or (at your option) any later version.
> +#
> +# This program is distributed in the hope that it will be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> +# GNU General Public License for more details.
> +#
> +# You should have received a copy of the GNU General Public License
> +# along with this program; if not, write to the Free Software
> +# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> +# MA 02111-1307 USA
> +#
> +
> +
> +#
> +# image should be loaded at 0x01000000
> +#
> +
> +# SDRAM
> +TEXT_BASE = 0x20780000
> +# mobile pSRAM
> +#TEXT_BASE = 0x90700000
> +
could you use a condition
> +PLATFORM_CPPFLAGS += -fPIC -fPIE -fno-jump-tables # -msingle-pic-base
> +
> +ifneq ($(OBJTREE),$(SRCTREE))
> +# We are building u-boot in a separate directory, use generated
> +# .lds script from OBJTREE directory.
> +LDSCRIPT := $(OBJTREE)/board/$(BOARDDIR)/u-boot.lds
> +endif
> diff --git a/board/firetux/ethernet.c b/board/firetux/ethernet.c
please move to drivers/net/
> new file mode 100644
> index 0000000..866d578
> --- /dev/null
> +++ b/board/firetux/ethernet.c
> @@ -0,0 +1,970 @@
> +/*
> + * pnx8181 ethernet driver (ip3912)
> + *
> + * (C) Copyright 2007-2008, emlix GmbH, Germany
> + * Juergen Schoew <js@emlix.com>
> + *
> + * (C) Copyright 2008, DSPG Technologies GmbH, Germany
> + * (C) Copyright 2007, NXP Semiconductors Germany GmbH
> + * Matthias Wenzel, <nxp@mazzoo.de>
> + *
> + * See file CREDITS for list of people who contributed to this
> + * project.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + */
> +
> +#include <common.h>
> +#include <net.h>
> +#include <malloc.h>
> +
> +#include "ethernet.h"
> +#include <miiphy.h>
> +
> +extern unsigned int boardrevision;
> +uint16_t ETN1_MADR_PHY_ADDR, ETN2_MADR_PHY_ADDR;
please do not use uppercase for var name
> +
> +int firetux_miiphy_initialize(bd_t *bis);
> +int mii_discover_phy(void);
> +int mii_negotiate_phy(void);
> +
> +#define ALIGN8 static __attribute__ ((aligned(8)))
> +#define ALIGN4 static __attribute__ ((aligned(4)))
why static? it should be strange to assume it's static when we read the code
> +
please use tab instead of space
> +#define PNX8181_SCON_SYSPAD0 0xc2204034
> +#define PNX8181_SCON_SYSPAD4 0xc2204044
> +#define PNX8181_SCON_SYSMUX0 0xc220400c
> +#define PNX8181_GPIOA_PINS 0xc2104000
> +#define PNX8181_GPIOA_OR 0xc2104004
> +#define PNX8181_GPIOA_DR 0xc2104008
> +
> +/* globals */
> +/* ETN1 rx */
> +ALIGN8 rx_descriptor_t etn1_rxdescriptor[ETN_RX_DESCRIPTOR_NUMBER];
> +ALIGN8 rx_status_t etn1_rxstatus [ETN_RX_DESCRIPTOR_NUMBER];
> +
> +/* ETN1 tx */
> +ALIGN8 tx_descriptor_t etn1_txdescriptor[ETN_TX_DESCRIPTOR_NUMBER];
> +ALIGN4 tx_status_t etn1_txstatus [ETN_TX_DESCRIPTOR_NUMBER];
> +
> +/* ETN2 rx */
> +ALIGN8 rx_descriptor_t etn2_rxdescriptor[ETN_RX_DESCRIPTOR_NUMBER];
> +ALIGN8 rx_status_t etn2_rxstatus [ETN_RX_DESCRIPTOR_NUMBER];
> +
> +/* ETN2 tx */
> +ALIGN8 tx_descriptor_t etn2_txdescriptor[ETN_TX_DESCRIPTOR_NUMBER];
> +ALIGN4 tx_status_t etn2_txstatus [ETN_TX_DESCRIPTOR_NUMBER];
> +
> +
> +/* which interface to be currently work on */
> +/* default can be set by environment variable ethact */
> +static int firetux_eth = 0;
> +
> +/* in the code we use the following descriptors which are either */
> +/* set to the etn1 or the etn2 descriptors, depending on ethact */
> +ALIGN8 rx_descriptor_t *etn_rxdescriptor = etn1_rxdescriptor;
> +ALIGN8 rx_status_t *etn_rxstatus = etn1_rxstatus;
> +ALIGN8 tx_descriptor_t *etn_txdescriptor = etn1_txdescriptor;
> +ALIGN8 tx_status_t *etn_txstatus = etn1_txstatus;
> +
> +/* also the base address is switched for etn1 and etn2, */
> +/* except for the MII registers etn1_m* which are only available */
> +/* on etn1 */
please use this style of comment
/*
*
*/
> +uint32_t etn_base = ETN1;
> +/* we first try Vega Platform III-a settings */
> +uint16_t firetux_phy_addr = 0x0100;
> +
is it not better to do all of this init in an init function?
and why not use a struct to save all parameter?
> +
> +static void firetux_set_ethact(int act, int hardwarerevision)
> +{
> + switch (hardwarerevision) {
> + /* EZ_MCP, Vega_pnx8181_basestation Platform III-a */
> + case 1:
> + case 2:
> + ETN1_MADR_PHY_ADDR = 0x00000100;
> + ETN2_MADR_PHY_ADDR = 0x00000200;
please use macro instead
> + break;
> + /* Vega_pnx8181_basestation Platform III-b, III-c */
> + case 3:
> + case 4:
> + default:
> + ETN1_MADR_PHY_ADDR = 0x00001E00;
> + ETN2_MADR_PHY_ADDR = 0x00001D00;
> + break;
> + }
> + if (act) {
> + etn_rxdescriptor = etn2_rxdescriptor;
> + etn_rxstatus = etn2_rxstatus;
> + etn_txdescriptor = etn2_txdescriptor;
> + etn_txstatus = etn2_txstatus;
> + etn_base = ETN2;
> + firetux_phy_addr = (uint16_t) ETN2_MADR_PHY_ADDR;
> + } else {
> + etn_rxdescriptor = etn1_rxdescriptor;
> + etn_rxstatus = etn1_rxstatus;
> + etn_txdescriptor = etn1_txdescriptor;
> + etn_txstatus = etn1_txstatus;
> + etn_base = ETN1;
> + firetux_phy_addr = (uint16_t) ETN1_MADR_PHY_ADDR;
> + }
> +}
> +
> +static void firetux_reset_phy(int hardwareversion)
> +{
> + switch (hardwareversion) {
> + case 1:
> + case 2:
> + case 3:
please use readx and writex
it will be better to create a gpiolib support
> + /* set GPIOa12 direction to output */
> + *(vu_long *)(PNX8181_GPIOA_DR) = (((*(vu_long *)
> + (PNX8181_GPIOA_DR)) & 0xffffefff) | 0x00001000);
> + /* ETH_RESET_N */
> + *(vu_long *)(PNX8181_GPIOA_OR) = ((*(vu_long *)
> + (PNX8181_GPIOA_OR)) & 0xffffefff);
> + udelay(256000);
> + *(vu_long *)(PNX8181_GPIOA_OR) = (((*(vu_long *)
> + (PNX8181_GPIOA_OR)) & 0xffffefff) | 0x00001000);
> + udelay(100000);
why 100ms of delay?
> + break;
> + case 4:
> + *(vu_long *) (PNX8181_SCON_SYSPAD4) = (((*(vu_long *)
> + (PNX8181_SCON_SYSPAD4)) & 0xf7f5755f) | 0x080a8aa0);
> + *(vu_long *) (PNX8181_SCON_SYSMUX0) = ((*(vu_long *)
> + (PNX8181_SCON_SYSMUX0)) & 0xffffff3f);
> + /* set GPIOa3 direction to output */
> + *(vu_long *) (PNX8181_GPIOA_DR) = (((*(vu_long *)
> + (PNX8181_GPIOA_DR)) & 0xfffffff7) | 0x00000008);
> + /* ETH_RESET_N */
> + *(vu_long *) (PNX8181_GPIOA_OR) = ((*(vu_long *)
> + (PNX8181_GPIOA_OR)) & 0xfffffff7);
> + udelay(256000);
why 256ms of delay?
> + *(vu_long *) (PNX8181_GPIOA_OR) = (((*(vu_long *)
> + (PNX8181_GPIOA_OR)) & 0xfffffff7) | 0x00000008);
> + udelay(100000);
why 100ms of delay?
> + break;
> + default:
> + puts("Unknown Board, can't reset network phy\n");
> + break;
> + }
> +}
> +
> +static int firetux_eth_init_clocks(void)
> +{
> + /* first things first, release the RSTEXT signal,
> + * which keeps the PHYs in reset */
> + *(vu_long *) (WDRU + WDRUCON) |= 0x0001;
> +
> + /* init ETN clocks */
> +
> + /* set ETNREFCLK to internal CGU clock, assuming a 13.824MHz crystal */
> + /* for other xtals see NXP's validation tests,
> + * lib/tools/source/swift_tools.c */
> + *(vu_long *) CGU_PER2CON = (15<<9) | (62<<3) | 3;
please ad space between "<<"
> +
> + /* turn on PLL */
> + *(vu_long *) CGU_PER2CON |= 0x00010000;
> + /* wait for PLL lock */
> + while (!(*(vu_long *) CGU_PER2CON & 0x00020000));
> +
> + /* ungate ETN clocks */
> + *(vu_long *) CGU_PER2CON |= 0x00802000;
> +
> + return 0;
> +}
> +
> +static int firetux_eth_init_rxdescriptor(void)
> +{
> + *(vu_long *) (etn_base + ETN_RXDESCRIPTOR) = (vu_long) etn_rxdescriptor;
> + *(vu_long *) (etn_base + ETN_RXSTATUS) = (vu_long) etn_rxstatus;
> + *(vu_long *) (etn_base + ETN_RXCONSUMEINDEX) = 0x00000000;
> + *(vu_long *) (etn_base + ETN_RXDESCRIPTORNUMBER) =
> + ETN_RX_DESCRIPTOR_NUMBER - 1;
> +
> + /* allocate rx-buffers, but only once, we're called multiple times! */
> + static void *rxbuf = 0;
> + if (!rxbuf)
> + rxbuf = malloc(MAX_ETH_FRAME_SIZE * ETN_RX_DESCRIPTOR_NUMBER);
> + if (!rxbuf) {
> + puts("ERROR: couldn't allocate rx buffers!\n");
> + return -1;
> + }
> +
> + int i;
please declare var at begining
> + for (i = 0; i < ETN_RX_DESCRIPTOR_NUMBER; i++) {
> + etn_rxdescriptor[i].packet = rxbuf + i * MAX_ETH_FRAME_SIZE;
> + etn_rxdescriptor[i].control =
> + MAX_ETH_FRAME_SIZE - sizeof(vu_long);
> + etn_rxstatus[i].info = 0;
> + etn_rxstatus[i].hashCRC = 0;
> + }
> + return 0;
> +}
> +
> +static int firetux_eth_init_txdescriptor(void)
> +{
> + *(vu_long *) (etn_base + ETN_TXDESCRIPTOR) =
> + (vu_long) etn_txdescriptor;
> + *(vu_long *) (etn_base + ETN_TXSTATUS) = (vu_long) etn_txstatus;
> + *(vu_long *) (etn_base + ETN_TXPRODUCEINDEX) = 0x00000000;
> + *(vu_long *) (etn_base + ETN_TXDESCRIPTORNUMBER) =
> + ETN_TX_DESCRIPTOR_NUMBER - 1;
> +
> + int i;
> + for (i = 0; i < ETN_TX_DESCRIPTOR_NUMBER; i++) {
> + etn_txdescriptor[i].packet = 0;
> + etn_txdescriptor[i].control = 0;
> + etn_txstatus[i].info = 0;
> + }
> + return 0;
> +}
> +
> +static void PHY_write(uint16_t a, uint16_t d)
please no uppercase in function name
> +{
> + uint32_t status;
> + int i = 0;
> +
> + a &= 0x001f; /* 5 bit PHY register address */
> +
> + *(vu_long *) (ETN1 + ETN_MADR) = firetux_phy_addr | a;
> + *(vu_long *) (ETN1 + ETN_MWTD) = d;
> +
> + /* poll for done */
> + while ((status = *(vu_long *) (ETN1 + ETN_MIND)) && i < 1000000)
> + i++;
> + if (status) {
> + printf("ERROR: PHY_write(%d) = 0x%x [eth=%d, phy_addr=%x]\n",
> + a, status, firetux_eth, firetux_phy_addr);
> + } else {
> +#ifdef ET_DEBUG
> + printf("### PHY_write(%2.d, 0x%4.4x) success after %d cycles "
> + "[eth=%d, phy_addr=%x]\n", a, d, i, firetux_eth,
> + firetux_phy_addr);
please use debug()
> +#endif
> + }
> +}
> +
> +static uint16_t PHY_read(uint16_t a)
> +{
> + uint32_t status;
> + int i = 0;
> +
> + a &= 0x001f; /* 5 bit PHY register address */
> + *(vu_long *) (ETN1 + ETN_MADR) = firetux_phy_addr | a;
> + *(vu_long *) (ETN1 + ETN_MCMD) = 0x00000001;
> +
> + /* poll for done */
> + while ((status = ((*(vu_long *)
> + (ETN1 + ETN_MIND))) & 0x7) && i < 1000000)
> + i++;
> +
> + uint16_t d = *(vu_long *) (ETN1 + ETN_MRDD);
please declare var at the beggening
> +
> + if (status) {
> + printf("ERROR: PHY_read(%d) = 0x%x after %d cycles [eth=%d, "
> + "phy_addr=%x]\n", a, status, i, firetux_eth,
> + firetux_phy_addr);
> + } else {
> +#ifdef ET_DEBUG
> + printf("### PHY_read(%2.d)=0x%4.4x success after %d cycles "
> + "[eth=%d, phy_addr=%x]\n", a, d, i, firetux_eth,
> + firetux_phy_addr);
> +#endif
> + }
> +
> + *(vu_long *) (ETN1 + ETN_MCMD) = 0x00000000;
> +
> + return d;
> +}
> +
Their is too much fix to do to.
Please fix first.
Best Regards,
J.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-07-29 0:03 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-07-29 0:03 UTC (permalink / raw)
To: u-boot
=A0
=A0
=3D>diag run cpu =A0
=A0
By log I verfied that this TRAP is generated from the post/cpu.c because of=
printf
=A0
NIP: 00000000 XER: 00000000 LR: FFF25C40 REGS: 3feed878 TRAP: 0700 DAR: 000=
00004
MSR: 00029200 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 00
=A0
GPR00: 00000004 3FEED968 00000200 3FEEDA18 3FEEDA18 3FEEDA08 FFFFFFF4 00000=
007
GPR08: 00000000 00000000 FFFFFFFF 3FEED918 44028042 00000000 3FFBBC00 00000=
000
GPR16: 00000000 00000000 00000000 00000000 00000000 3FEF0378 00000003 00000=
00C
GPR24: 3FEF0350 00000600 00000002 00000600 3FEEDA18 3FEEDF90 FFF4D3BC 00000=
000
** Illegal Instruction **
Call backtrace:
3FF73310 FFF25DB8 FFF25E38 FFF338A0 3FFA2FAC 3FFA3564 3FF8D620
3FF98820 3FF98E98 3FF99000 3FF8AE44 3FF81DA8 3FF72628
Program Check Exception
NIP=DE
=A0
=A0
=A0
CASE 2 Experiment:
=A0
Post/cpu.c=20
=A0
int cpu_post_test (int flags)
{
=A0=A0=A0=A0=A0=A0=A0 int ic =3D icache_status ();
=A0=A0=A0=A0=A0=A0=A0 int=A0 ret =3D 0;
=A0=A0=A0=A0=A0=A0=A0 int c;
=A0=A0=A0=A0=A0=A0=A0 post_result_cpu =3D 0;
=A0=A0=A0=A0=A0=A0=A0 cpu_dbg =3D 0;
=A0=A0=A0=A0=A0=A0=A0 boot_flag_post =3D 0;
=A0
=A0=A0=A0=A0 < Removed or commented =A0the printf statement =A0>
=A0=A0=A0=A0=A0=A0=A0=A0 return 0;=A0=A0=A0 NO TRAP=A0 is Generated.
=A0
=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0.
}
=A0
=A0
Another approach to validate the post/cpu.c fuction. Is working correctly o=
r not.
=A0
=A0
In file post.c=20
=A0
Declared this API and directly called cpu_post_test(flags) before the funct=
ion pointers. This API executed correctly with out a TRAP and results were =
displayed correctly.=20
extern int cpu_post_test (int flags);
=A0
static int post_run_single (struct post_test *test,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0 int test_flags, int flags, unsigned int i) {
=A0
ret =3D=A0 cpu_post_test(flags);
=A0
#if 0
if ((*test->test) (flags) !=3D 0) {=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20
=A0 post_log ("FAILED\n")
} else {
post_log ("PASSED\n")
}
#iendif=20
=A0
=A0
Could u please let me know how do I avoid this TRAP when I am using the fun=
ction pointers.. CASE 1 Experiment:
=A0
=A0
=A0
=A0
Regards,
Rajshekar
=A0
=A0
=A0
=A0
=A0=0A=0A=0A
--0-1028163133-1227441595=:38644--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-07-29 0:03 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-07-29 0:03 UTC (permalink / raw)
To: u-boot
=A0=20
=A0=20
=3D>diag run cpu =A0=20
=A0=20
By log I verfied that this TRAP is generated from the post/cpu.c because of=
printf=20
=A0=20
NIP: 00000000 XER: 00000000 LR: FFF25C40 REGS: 3feed878 TRAP: 0700 DAR: 000=
00004=20
MSR: 00029200 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 00=20
=A0=20
GPR00: 00000004 3FEED968 00000200 3FEEDA18 3FEEDA18 3FEEDA08 FFFFFFF4 00000=
007=20
GPR08: 00000000 00000000 FFFFFFFF 3FEED918 44028042 00000000 3FFBBC00 00000=
000=20
GPR16: 00000000 00000000 00000000 00000000 00000000 3FEF0378 00000003 00000=
00C=20
GPR24: 3FEF0350 00000600 00000002 00000600 3FEEDA18 3FEEDF90 FFF4D3BC 00000=
000=20
** Illegal Instruction **=20
Call backtrace:=20
3FF73310 FFF25DB8 FFF25E38 FFF338A0 3FFA2FAC 3FFA3564 3FF8D620=20
3FF98820 3FF98E98 3FF99000 3FF8AE44 3FF81DA8 3FF72628=20
Program Check Exception=20
NIP=DE=20
=A0=20
=A0=20
=A0=20
CASE 2 Experiment:=20
=A0=20
Post/cpu.c=20
=A0=20
int cpu_post_test (int flags)=20
{=20
=A0=A0=A0=A0=A0=A0=A0 int ic =3D icache_status ();=20
=A0=A0=A0=A0=A0=A0=A0 int=A0 ret =3D 0;=20
=A0=A0=A0=A0=A0=A0=A0 int c;=20
=A0=A0=A0=A0=A0=A0=A0 post_result_cpu =3D 0;=20
=A0=A0=A0=A0=A0=A0=A0 cpu_dbg =3D 0;=20
=A0=A0=A0=A0=A0=A0=A0 boot_flag_post =3D 0;=20
=A0=20
=A0=A0=A0=A0 < Removed or commented =A0the printf statement =A0>=20
=A0=A0=A0=A0=A0=A0=A0=A0 return 0;=A0=A0=A0 NO TRAP=A0 is Generated.=20
=A0=20
=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0.=20
}=20
=A0=20
=A0=20
Another approach to validate the post/cpu.c fuction. Is working correctly o=
r not.=20
=A0=20
=A0=20
In file post.c=20
=A0=20
Declared this API and directly called cpu_post_test(flags) before the funct=
ion pointers. This API executed correctly with out a TRAP and results were =
displayed correctly.=20
extern int cpu_post_test (int flags);=20
=A0=20
static int post_run_single (struct post_test *test,=20
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0 int test_flags, int flags, unsigned int i) {=20
=A0=20
ret =3D=A0 cpu_post_test(flags);=20
=A0=20
#if 0=20
if ((*test->test) (flags) !=3D 0) {=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20
=A0 post_log ("FAILED\n")=20
} else {=20
post_log ("PASSED\n")=20
}=20
#iendif=20
=A0=20
=A0=20
Could u please let me know how do I avoid this TRAP when I am using the fun=
ction pointers.. CASE 1 Experiment:=20
=A0=20
=A0=20
=A0=20
=A0=20
Regards,=20
Rajshekar=20
=A0=20
=A0=20
=A0=20
=A0=20
=A0
=0A=0A=0A
--0-1167558799-1227498958=:70215--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-07-29 0:03 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-07-29 0:03 UTC (permalink / raw)
To: u-boot
xlat 1234
or
xlat 0x1234
are taken as VA's (see discussion about default address
interpretation), so "xlat" will print the PA.
xlat 1234.p
or
xlat 0x1234.p
has a PA as argument, so it prints the VA.
Multiple arguments (even mixed) might be allowed, too, for example:
xlat 1234 1234.p 5678 5678.p
> Thoughts:
> vtop(virtual) returns physical
> ptov(physical) returns virtual
> or (see below thought on 0v / 0p)
> xlat(0p1234) returns virtual
> xlat(0v1234) returns physical
> xlat(0x1234) returns physical (per convention from snipped discussion)
Seems too complex for a simple mind like mine ;-)
> Question: Do we need a translation function?
Define "need". It is certainly very useful, especially if things don;t
work as expected and you want to check address translation.
See the "xlat" command in the BDI2000 - how often did you use that?
[Right, I didn't invent that name. I'm recycling used bits. Hope this
is OK.]
> Thought:
> 0v6789ABCD is a virtual address (the value is interpreted as hex)
> 0p6789ABCD is a physical address
>
> Of course "v" and "p" should be accepted in either case.
>
> Kinda ugly, but fits into the 0x style conventions.
I tend to allow for suffixes, i. e. "6789ABCD" or "6789ABCD.v" are
VAs, while "6789ABCD.p" is a PA.
To me, that is easier to read.
> I haven't looked at the number parsing code to see how hard it would be
> to squeeze this into it.
Not really difficult.
> Stuff face, write code. Does it get any better than that? ;-)
I'm an optimist, to yes, of course it does. The amount of code that
needs to get written grows and grows. Enough work for all of us :-)
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
NOTE: The Most Fundamental Particles in This Product Are Held
Together by a "Gluing" Force About Which Little is Currently Known
and Whose Adhesive Power Can Therefore Not Be Permanently Guaranteed.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-07-29 0:03 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-07-29 0:03 UTC (permalink / raw)
To: u-boot
Previous versions of CPP implemented the comma-deletion
extension much more generally. We have restricted it in this
release to minimize the differences from C99. To get the same
effect with both this and previous versions of GCC, the token
preceding the special `##' must be a comma, and there must be
^^^^^^^^^^^^^
white space between that comma and whatever comes immediately
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
before it:
^^^^^^^^^^
#define eprintf(format, args...) fprintf (stderr, format , ##args)
So the white space before the comma is actually intentional and
essential. Do not remove it.
Also, please never mix actual changes and such "cleanup" into one
patch. If you think a cleanup is necessary, then split it into a
sepparate patch.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
There's an old story about the person who wished his computer were as
easy to use as his telephone. That wish has come true, since I no
longer know how to use my telephone.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-07-29 0:03 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-07-29 0:03 UTC (permalink / raw)
To: u-boot
0x12 but not others.
2. We connected LAN cable to the PORT 0x12, still its not getting pinged.
We have connected in RGMII mode (TSEC0)
During POR the POR register are getting configured for default (GMII) mode,
how can we change the PORT to RGMII, after Boot.
1. in Marvel - MDIO is selected in Configuration, and also in Four
Independented Serial Management Mode.
Please help me in this regard.
Thanks,
Ajeesh Kumar
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments contained in it.
------=_NextPart_000_0061_01C96F41.BBA10860--
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-07-29 0:03 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-07-29 0:03 UTC (permalink / raw)
To: u-boot
for MPC83xx. Is it correct?
Best regards,
Valeriy Glushkov
----- Original Message -----
From: "Scott Wood" <scottwood@freescale.com>
To: "Valeriy Glushkov" <gvv@lstec.com>
Cc: <u-boot@lists.denx.de>
Sent: 30 ??????? 2008 ?. 18:45
Subject: Re: [U-Boot] Is it possible to use 2GB or DDR on MPC834x?
> Valeriy Glushkov wrote:
>> Hi Guys!
>>
>> On my mpc8347 based board I can access 1GB of DDR with mapping 4 of 256MB
>> ranges via IBAT\DBAT registers.
>>
>> But with the 2 GB of DDR it's impossible to map them with BATs (there are
>> only 8 BATs in the e300 core and the rest 4 of them are already used).
>>
>> All the mpc83xx examples in the U-boot tree seem to use <=1GB of SDRAM,
>> so they use BATs to map them.
>>
>> Any suggestions are highly appreciated.
>
> Why do you need to access all 2GB from u-boot?
>
> -Scott
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-07-29 0:03 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-07-29 0:03 UTC (permalink / raw)
To: u-boot
CPUs. And try to learn more on your on-board peripherals and devices.
Probably you can find some boards that have similar device
configuration, thus you can reuse some codes, esp. in case that you
should be not familiar with these devices.
Best Regards
Dinny
On Wed, Jan 7, 2009 at 5:25 PM, Naveen Kumar GADDIPATI
<naveen.gaddipati@stnwireless.com> wrote:
> Hi dinny,
>
> At the uboot level,we will confgiure only one core to boot up the image but we use two cores.For this usecase, could we use the single cortex-A8 uboot source code?
>
> Regards,
> Naveen
> -----Original Message-----
> From: dinny [mailto:dinny.wu at gmail.com]
> Sent: Wednesday, January 07, 2009 2:41 PM
> To: Naveen Kumar GADDIPATI
> Cc: u-boot at lists.denx.de
> Subject: Re: [U-Boot] help
>
> For SoCs, it depends on how the system design intends to make use of the two processors.
>
> If the design intends to use them as AMP, you should run u-boot for each processor in sequence to init their peripherals. In this case, you can adapt u-boot deriving from the openzoom source. If as SMP, you can run u-boot on one core and make the other core regardless for U-Boot, and make the other working when linux boots.
>
> Anyway, you have to read through the chapters of the SoC spec on how the two processors are intended to co-work to make this more clear. I can't get the SPECs, and I cannot give you more information. Denk could give more details, for MPC85xx multi processor implementation:-)
>
> Best Regards
> Dinny
>
> On Wed, Jan 7, 2009 at 1:27 PM, Naveen Kumar GADDIPATI <naveen.gaddipati@stnwireless.com> wrote:
>>
>> Hi dinny,
>>
>> Thanks for your reply.
>> We are working on arm-cortex A9(single core).The product has two such single cores.
>> Could we start using this coretex A8 uboot source code?
>>
>> Regards,
>> Naveen
>> -----Original Message-----
>> From: dinny [mailto:dinny.wu at gmail.com]
>> Sent: Wednesday, January 07, 2009 7:20 AM
>> To: Naveen Kumar GADDIPATI
>> Cc: u-boot at lists.denx.de
>> Subject: Re: [U-Boot] help
>>
>> Hi Naveen,
>>
>> Do you use a cortex A9 single core or multicore product? If you are
>> using a cortex A9 single core, you can have a look at omap zoom u-boot
>> implementation as a reference. It's based on TI's omap3430, a Cortex
>> A8 core. Although there should be some difference on the internal architecture design, I don't think it makes much difference for software implementation.
>>
>> Best Regards
>> Dinny
>>
>> On Tue, Jan 6, 2009 at 4:28 PM, Naveen Kumar GADDIPATI <naveen.gaddipati@stnwireless.com> wrote:
>>> Hi,
>>>
>>> I'm working for arm cortex A9 processor.Do we have any uboot source
>>> code support for cortex A9 processor?
>>>
>>> eMMC
>>> Do we have any patch or source code for eMMC in uboot?
>>>
>>> Thanks and Regards,
>>> Naveen
>>>
>>> _______________________________________________
>>> U-Boot mailing list
>>> U-Boot at lists.denx.de
>>> http://lists.denx.de/mailman/listinfo/u-boot
>>>
>>
>>
>>
>> --
>> what we need is passion, chance, and companions.
>>
>>
>
>
>
> --
> what we need is passion, chance, and companions.
>
>
--
what we need is passion, chance, and companions.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-07-28 4:41 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-07-28 4:41 UTC (permalink / raw)
To: ath9k-devel
Connectivtiy is lost after Group rekeying is done. The keytype
maintained by ath9k is reset when group key is updated. Though
sc_keytype can be reset only for broadcast key the proper fix
would be to use mac80211 provided key type from txinfo during
xmit and get rid of sc_keytype from ath9k ath_softc.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com>
---
drivers/net/wireless/ath9k/core.h | 1 -
drivers/net/wireless/ath9k/main.c | 3 ---
drivers/net/wireless/ath9k/xmit.c | 6 +++---
3 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/ath9k/core.h b/drivers/net/wireless/ath9k=
/core.h
index b66de29..e8ccbe4 100644
--- a/drivers/net/wireless/ath9k/core.h
+++ b/drivers/net/wireless/ath9k/core.h
@@ -976,7 +976,6 @@ struct ath_softc {
u32 sc_keymax; /* size of key cache */
DECLARE_BITMAP(sc_keymap, ATH_KEYMAX); /* key use bit map */
u8 sc_splitmic; /* split TKIP MIC keys */
- int sc_keytype;
/* RX */
struct list_head sc_rxbuf;
diff --git a/drivers/net/wireless/ath9k/main.c b/drivers/net/wireless/ath9k=
/main.c
index 1ba1800..aca893a 100644
--- a/drivers/net/wireless/ath9k/main.c
+++ b/drivers/net/wireless/ath9k/main.c
@@ -204,8 +204,6 @@ static int ath_key_config(struct ath_softc *sc,
if (!ret)
return -EIO;
- if (mac)
- sc->sc_keytype =3D hk.kv_type;
return 0;
}
@@ -1507,7 +1505,6 @@ static int ath9k_set_key(struct ieee80211_hw *hw,
case DISABLE_KEY:
ath_key_delete(sc, key);
clear_bit(key->keyidx, sc->sc_keymap);
- sc->sc_keytype =3D ATH9K_CIPHER_CLR;
break;
default:
ret =3D -EINVAL;
diff --git a/drivers/net/wireless/ath9k/xmit.c b/drivers/net/wireless/ath9k=
/xmit.c
index 3fc6641..2592905 100644
--- a/drivers/net/wireless/ath9k/xmit.c
+++ b/drivers/net/wireless/ath9k/xmit.c
@@ -239,11 +239,11 @@ static int ath_tx_prepare(struct ath_softc *sc,
txctl->keyix =3D tx_info->control.hw_key->hw_key_idx;
txctl->frmlen +=3D tx_info->control.icv_len;
- if (sc->sc_keytype =3D=3D ATH9K_CIPHER_WEP)
+ if (tx_info->control.hw_key->alg =3D=3D ALG_WEP)
txctl->keytype =3D ATH9K_KEY_TYPE_WEP;
- else if (sc->sc_keytype =3D=3D ATH9K_CIPHER_TKIP)
+ else if (tx_info->control.hw_key->alg =3D=3D ALG_TKIP)
txctl->keytype =3D ATH9K_KEY_TYPE_TKIP;
- else if (sc->sc_keytype =3D=3D ATH9K_CIPHER_AES_CCM)
+ else if (tx_info->control.hw_key->alg =3D=3D ALG_CCMP)
txctl->keytype =3D ATH9K_KEY_TYPE_AES;
}
--
1.5.5
--opJtzjQTFsWo+cga
Content-Type: text/x-diff; charset="us-ascii"
Content-Disposition: attachment; filename="connectivity.patch"
^ permalink raw reply related [flat|nested] 732+ messages in thread
* No subject
@ 2008-07-14 13:16 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-07-14 13:16 UTC (permalink / raw)
To: buildroot
make[1]: Entering directory
`/media/EkstraDisk/buildroot/build_i686/dnsmasq-2.41'
cd src && /usr/bin/make \
DBUS_MINOR=" `echo -DNO_IPV6 | ../bld/pkg-wrapper pkg-config --modversion
dbus-1 | nawk -F . -- '{ if ($(NF-1)) print \"-DDBUS_MINOR=\"$(NF-1) }'`"
\
DBUS_CFLAGS="`echo -DNO_IPV6 | ../bld/pkg-wrapper pkg-config --cflags
dbus-1`" \
DBUS_LIBS=" `echo -DNO_IPV6 | ../bld/pkg-wrapper pkg-config --libs
dbus-1`" \
SUNOS_LIBS=" `if uname | grep SunOS 2>&1 >/dev/null; then echo -lsocket
-lnsl -lposix4; fi `" \
SUNOS_VER=" `if uname | grep SunOS 2>&1 >/dev/null; then uname -r | nawk
-F . -- '{ print \"-DSUNOS_VER=\"$2 }'; fi`" \
-f ../bld/Makefile dnsmasq
/bin/sh: line 1: nawk: command not found
Don't you have nawk installed? On my system, nawk is a link to gawk.
Seems like we don't currently check for awk in dependencies.sh, will fix
----------------------------------------------------------------------
jacmet - 06-18-08 06:17
----------------------------------------------------------------------
I have now added an awk check to dependencies.sh and forced dnsmasq to use
awk rather than nawk, so closing issue.
Issue History
Date Modified Username Field Change
======================================================================
06-14-08 17:01 KHAksnes New Issue
06-14-08 17:01 KHAksnes Status new => assigned
06-14-08 17:01 KHAksnes Assigned To => buildroot
06-15-08 13:40 jacmet Note Added: 0008264
06-15-08 14:07 KHAksnes Note Added: 0008274
06-15-08 14:08 KHAksnes File Added: compilelog
06-18-08 06:06 jacmet Note Added: 0008384
06-18-08 06:17 jacmet Status assigned => resolved
06-18-08 06:17 jacmet Resolution open => fixed
06-18-08 06:17 jacmet Note Added: 0008394
07-16-08 08:02 bernhardf Status resolved => new
07-17-08 03:39 bernhardf Status new => closed
======================================================================
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-07-14 13:16 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-07-14 13:16 UTC (permalink / raw)
To: buildroot
PrBoom is a version of Doom using the Simple Direct Media
layer (SDL) library, which enables it to use XFree86, OpenGL,
Linux framebuffer console, GGI, SVGALib or even color or
monochrome text consoles as display. There is an additional
OpenGL renderer as well.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-07-14 13:16 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-07-14 13:16 UTC (permalink / raw)
To: buildroot
ttymxc0 device. If so, then the reason why you cannot login is that
you don't have ttymxc0 listed in /etc/securetty.
The file comes from target/generic/target_skeleton/etc, but you can
simply edit it under project_build_arm/uclibc/root/etc and rerun make
to regenerate your filesystem image.
I don't see any mention of /dev/ttymxcN in Documentation/devices.txt
in the kernel sources? I take it that the serial driver isn't in the
mainline kernel?
> THe other thing I tried to do was pass init=/dev/sh and
> init=/dev/bash to try to get a direct shell prompt. I don't think
> it was connecting to the MX31's serial port because I never saw any
> outputs after the filesystem was mounted. Is there a recommended
> way to force /dev/sh to appear on a ttyS0 (or actually ttymxc0 for
> the MX31)
I take it you mean /bin/sh not /dev/sh?
Strange. And you do get output from init and login with the same
filesystem if you boot without init=/bin/sh?
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-07-14 13:16 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-07-14 13:16 UTC (permalink / raw)
To: buildroot
Modified:
trunk/buildroot/package/config/lex.zconf.c_shipped
trunk/buildroot/package/config/zconf.l
Changeset:
Modified: trunk/buildroot/package/config/lex.zconf.c_shipped
===================================================================
--- trunk/buildroot/package/config/lex.zconf.c_shipped 2008-08-27 15:06:41 UTC (rev 23246)
+++ trunk/buildroot/package/config/lex.zconf.c_shipped 2008-08-27 20:18:33 UTC (rev 23247)
@@ -815,6 +815,11 @@
void append_string(const char *str, int size)
{
int new_size = text_size + size + 1;
+ if (size > 70) {
+ fprintf (stderr, "%s:%d warning: Overlong line\n",
+ current_file->name, current_file->lineno);
+ }
+
if (new_size > text_asize) {
new_size += START_STRSIZE - 1;
new_size &= -START_STRSIZE;
Modified: trunk/buildroot/package/config/zconf.l
===================================================================
--- trunk/buildroot/package/config/zconf.l 2008-08-27 15:06:41 UTC (rev 23246)
+++ trunk/buildroot/package/config/zconf.l 2008-08-27 20:18:33 UTC (rev 23247)
@@ -49,6 +49,10 @@
void append_string(const char *str, int size)
{
int new_size = text_size + size + 1;
+ if (size > 70) {
+ fprintf (stderr, "%s:%d warning: Overlong line\n",
+ current_file->name, current_file->lineno);
+ }
if (new_size > text_asize) {
new_size += START_STRSIZE - 1;
new_size &= -START_STRSIZE;
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-04-23 14:39 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-04-23 14:39 UTC (permalink / raw)
To: buildroot
0x40000930 0x40003f50 Yes
/home/osingla/buildroot-9260/buildroot/build_arm/staging_dir/lib/ld-uClibc.so.0
0x40011dd0 0x40018380 Yes
/home/osingla/buildroot-9260/buildroot/build_arm/staging_dir/lib/libpthread.so.0
0x40033800 0x40071e60 Yes
/home/osingla/buildroot-9260/buildroot/build_arm/staging_dir/lib/libc.so.0
(gdb) q
~$
When the thread has been created, it is not visible from the debugger.
It runs, but I can't put a breakpoint.
A few notes:
- I do not like the message "warning: Remote failure reply: E01", it
might mean that gdb host and gdbserver are not in sync for whatever
reason.
- If I put a breakpoint on the thread function, before 'cont', the
program terminates as soon the thread is created.
- the shared library 'thread_db' is not loaded (I think it should):
# cat /proc/2298/maps
00008000-00009000 r-xp 00000000 00:0c 4339 /tmp/test
00010000-00011000 rw-p 00000000 00:0c 4339 /tmp/test
00011000-00012000 rwxp 00011000 00:00 0 [heap]
40000000-40005000 r-xp 00000000 00:01 398 /lib/ld-uClibc-0.9.29.so
40005000-40006000 rw-p 40005000 00:00 0
4000c000-4000d000 r--p 00004000 00:01 398 /lib/ld-uClibc-0.9.29.so
4000d000-4000e000 rw-p 00005000 00:01 398 /lib/ld-uClibc-0.9.29.so
4000e000-40019000 r-xp 00000000 00:01 406 /lib/libpthread-0.9.29.so
40019000-40020000 ---p 40019000 00:00 0
40020000-40021000 r--p 0000a000 00:01 406 /lib/libpthread-0.9.29.so
40021000-40026000 rw-p 0000b000 00:01 406 /lib/libpthread-0.9.29.so
40026000-40028000 rw-p 40026000 00:00 0
40028000-400b5000 r-xp 00000000 00:01 414 /lib/libuClibc-0.9.29.so
400b5000-400bc000 ---p 400b5000 00:00 0
400bc000-400bd000 r--p 0008c000 00:01 414 /lib/libuClibc-0.9.29.so
400bd000-400be000 rw-p 0008d000 00:01 414 /lib/libuClibc-0.9.29.so
400be000-400c3000 rw-p 400be000 00:00 0
bebde000-bebf3000 rwxp befeb000 00:00 0 [stack]
I used linuxthreads (stable/old), and I checked 'pthreads debugging
support ' within uclibc menuconfig.
Any idea what I am missing?
TIA,
~Olivier
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-04-23 14:39 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-04-23 14:39 UTC (permalink / raw)
To: buildroot
./arch-arm/kernel-patches-2.6.24/linux-2.6.24-at91.patch
./arch-arm/kernel-patches-2.6.20.4/linux-2.6.20.4-atmel.patch
./arch-arm/kernel-patches-2.6.21.1/linux-2.6.21.1-at91.patch
./arch-arm/kernel-patches-2.6.21.1/linux-2.6.21.1-at91-1-update.patch
./arch-arm/kernel-patches-2.6.21.5/linux-2.6.21.5-at91-1-update.patch
./arch-arm/kernel-patches-2.6.21.5/linux-2.6.21.5-at91.patch
Not to mention having a separate u-boot, just because the Atmel ARM
didn't get to get their patches upstream, while AVR32 did.
> > On top of that, external toolchain tries to download prepatched
> > toochain from a site that you control, but that has no such files to
> > download from.
>
> BR2_ATMEL_MIRROR should be ftp://www.at91.com/pub/buildroot/
> I see the files in this location.
There is no gcc 4.2.2 in there. There is no gdb-4.7.1 in there.
> > Please revert your changes asap.
> >
>
> No, if there are problems, it should be fixed within the external toolchain
> to avoid adding those megabytes, which are of no interest to AVR32 users.
> There are hooks to patch the external toolchain if neccessary.
Then I guess we will all be getting FTP user accounts to your server
now? So that we can fix things within the external toolchain?
I'm interested in those few kb (namely 915826 bytes). Last time I
checked, I was in the universe of AVR32 users.
You didn't even care to test your changes, and despite protests
removed the toolchain support anyway. You are taking away our freedom
to update, fix, do whatever with the toolchain from within buildroot.
Not to mention breaking things up and making me and a hell lot of
other people lose their day's or week's work.
Please revert your changes asap.
Regards,
Thiago A. Correa
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-04-23 14:39 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-04-23 14:39 UTC (permalink / raw)
To: buildroot
make[1]: Entering directory
`/media/EkstraDisk/buildroot/build_i686/dnsmasq-2.41'
cd src && /usr/bin/make \
DBUS_MINOR=" `echo -DNO_IPV6 | ../bld/pkg-wrapper pkg-config --modversion
dbus-1 | nawk -F . -- '{ if ($(NF-1)) print \"-DDBUS_MINOR=\"$(NF-1) }'`"
\
DBUS_CFLAGS="`echo -DNO_IPV6 | ../bld/pkg-wrapper pkg-config --cflags
dbus-1`" \
DBUS_LIBS=" `echo -DNO_IPV6 | ../bld/pkg-wrapper pkg-config --libs
dbus-1`" \
SUNOS_LIBS=" `if uname | grep SunOS 2>&1 >/dev/null; then echo -lsocket
-lnsl -lposix4; fi `" \
SUNOS_VER=" `if uname | grep SunOS 2>&1 >/dev/null; then uname -r | nawk
-F . -- '{ print \"-DSUNOS_VER=\"$2 }'; fi`" \
-f ../bld/Makefile dnsmasq
/bin/sh: line 1: nawk: command not found
Don't you have nawk installed? On my system, nawk is a link to gawk.
Seems like we don't currently check for awk in dependencies.sh, will fix
Issue History
Date Modified Username Field Change
======================================================================
06-14-08 17:01 KHAksnes New Issue
06-14-08 17:01 KHAksnes Status new => assigned
06-14-08 17:01 KHAksnes Assigned To => buildroot
06-15-08 13:40 jacmet Note Added: 0008264
06-15-08 14:07 KHAksnes Note Added: 0008274
06-15-08 14:08 KHAksnes File Added: compilelog
06-18-08 06:06 jacmet Note Added: 0008384
======================================================================
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-04-23 14:39 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-04-23 14:39 UTC (permalink / raw)
To: buildroot
make[1]: Entering directory
`/media/EkstraDisk/buildroot/build_i686/dnsmasq-2.41'
cd src && /usr/bin/make \
DBUS_MINOR=" `echo -DNO_IPV6 | ../bld/pkg-wrapper pkg-config --modversion
dbus-1 | nawk -F . -- '{ if ($(NF-1)) print \"-DDBUS_MINOR=\"$(NF-1) }'`"
\
DBUS_CFLAGS="`echo -DNO_IPV6 | ../bld/pkg-wrapper pkg-config --cflags
dbus-1`" \
DBUS_LIBS=" `echo -DNO_IPV6 | ../bld/pkg-wrapper pkg-config --libs
dbus-1`" \
SUNOS_LIBS=" `if uname | grep SunOS 2>&1 >/dev/null; then echo -lsocket
-lnsl -lposix4; fi `" \
SUNOS_VER=" `if uname | grep SunOS 2>&1 >/dev/null; then uname -r | nawk
-F . -- '{ print \"-DSUNOS_VER=\"$2 }'; fi`" \
-f ../bld/Makefile dnsmasq
/bin/sh: line 1: nawk: command not found
Don't you have nawk installed? On my system, nawk is a link to gawk.
Seems like we don't currently check for awk in dependencies.sh, will fix
----------------------------------------------------------------------
jacmet - 06-18-08 06:17
----------------------------------------------------------------------
I have now added an awk check to dependencies.sh and forced dnsmasq to use
awk rather than nawk, so closing issue.
Issue History
Date Modified Username Field Change
======================================================================
06-14-08 17:01 KHAksnes New Issue
06-14-08 17:01 KHAksnes Status new => assigned
06-14-08 17:01 KHAksnes Assigned To => buildroot
06-15-08 13:40 jacmet Note Added: 0008264
06-15-08 14:07 KHAksnes Note Added: 0008274
06-15-08 14:08 KHAksnes File Added: compilelog
06-18-08 06:06 jacmet Note Added: 0008384
06-18-08 06:17 jacmet Status assigned => resolved
06-18-08 06:17 jacmet Resolution open => fixed
06-18-08 06:17 jacmet Note Added: 0008394
======================================================================
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-04-23 14:39 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-04-23 14:39 UTC (permalink / raw)
To: buildroot
Modified:
trunk/buildroot/Makefile
trunk/buildroot/package/config/Makefile
Changeset:
Modified: trunk/buildroot/Makefile
===================================================================
--- trunk/buildroot/Makefile 2008-06-19 07:24:59 UTC (rev 22448)
+++ trunk/buildroot/Makefile 2008-06-19 08:11:35 UTC (rev 22449)
@@ -170,6 +170,8 @@
HOST_EXEEXT:=.exe
HOST_LIBEXT:=.lib
HOST_SHREXT:=.dll
+HOST_LOADLIBES="-lcurses -lintl"
+export HOST_LOADLIBES
endif
ifneq ($(findstring mingw,$(BR2_GNU_BUILD_SUFFIX)),)
HOST_EXEEXT:=.exe
Modified: trunk/buildroot/package/config/Makefile
===================================================================
--- trunk/buildroot/package/config/Makefile 2008-06-19 07:24:59 UTC (rev 22448)
+++ trunk/buildroot/package/config/Makefile 2008-06-19 08:11:35 UTC (rev 22449)
@@ -17,10 +17,10 @@
host-cobjs := $(sort $(foreach m,$(__hostprogs),$($(m)-objs)))
$(host-csingle): %: %.c
- $(HOSTCC) $(HOST_EXTRACFLAGS) $(HOSTCFLAGS) $(HOSTCFLAGS_$@) $(HOST_LOADLIBES) $< -o $@
+ $(HOSTCC) $(HOST_EXTRACFLAGS) $(HOSTCFLAGS) $(HOSTCFLAGS_$@) $< $(HOST_LOADLIBES) -o $@
$(host-cmulti): %: $(host-cobjs) $(host-cshlib)
- $(HOSTCC) $(HOST_EXTRACFLAGS) $(HOSTCFLAGS) $(HOSTCFLAGS_$@) $(HOST_LOADLIBES) $($@-objs) -o $@
+ $(HOSTCC) $(HOST_EXTRACFLAGS) $(HOSTCFLAGS) $(HOSTCFLAGS_$@) $($@-objs) $(HOST_LOADLIBES) -o $@
$(host-cobjs): %.o: %.c
$(HOSTCC) $(HOST_EXTRACFLAGS) $(HOSTCFLAGS) $(HOSTCFLAGS_$@) -c $< -o $@
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-04-23 14:39 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-04-23 14:39 UTC (permalink / raw)
To: buildroot
Modified:
trunk/buildroot/package/config/Makefile.kconfig
trunk/buildroot/package/config/README.buildroot2
trunk/buildroot/package/config/conf.c
trunk/buildroot/package/config/confdata.c
trunk/buildroot/package/config/expr.h
trunk/buildroot/package/config/gconf.c
trunk/buildroot/package/config/kconfig-language.txt
trunk/buildroot/package/config/kconfig-to-buildroot2.patch
trunk/buildroot/package/config/kxgettext.c
trunk/buildroot/package/config/lkc_proto.h
trunk/buildroot/package/config/lxdialog/check-lxdialog.sh
trunk/buildroot/package/config/mconf.c
trunk/buildroot/package/config/menu.c
trunk/buildroot/package/config/qconf.cc
trunk/buildroot/package/config/zconf.tab.c_shipped
trunk/buildroot/package/config/zconf.y
Changeset:
Modified: trunk/buildroot/package/config/Makefile.kconfig
===================================================================
--- trunk/buildroot/package/config/Makefile.kconfig 2008-06-19 08:11:35 UTC (rev 22449)
+++ trunk/buildroot/package/config/Makefile.kconfig 2008-06-19 08:11:43 UTC (rev 22450)
@@ -22,24 +22,25 @@
silentoldconfig: $(obj)/conf
$< -s arch/$(ARCH)/Kconfig
+# Create new linux.po file
+# Adjust charset to UTF-8 in .po file to accept UTF-8 in Kconfig files
+# The symlink is used to repair a deficiency in arch/um
update-po-config: $(obj)/kxgettext
- xgettext --default-domain=linux \
- --add-comments --keyword=_ --keyword=N_ \
- --files-from=scripts/kconfig/POTFILES.in \
- --output scripts/kconfig/config.pot
- $(Q)ln -fs Kconfig_i386 arch/um/Kconfig_arch
- $(Q)for i in `ls arch/`; \
- do \
- scripts/kconfig/kxgettext arch/$$i/Kconfig \
- | msguniq -o scripts/kconfig/linux_$${i}.pot; \
- done
- $(Q)msgcat scripts/kconfig/config.pot \
- `find scripts/kconfig/ -type f -name linux_*.pot` \
- --output scripts/kconfig/linux_raw.pot
- $(Q)msguniq --sort-by-file scripts/kconfig/linux_raw.pot \
- --output scripts/kconfig/linux.pot
- $(Q)rm -f arch/um/Kconfig_arch
- $(Q)rm -f scripts/kconfig/linux_*.pot scripts/kconfig/config.pot
+ xgettext --default-domain=linux \
+ --add-comments --keyword=_ --keyword=N_ \
+ --from-code=UTF-8 \
+ --files-from=scripts/kconfig/POTFILES.in \
+ --output $(obj)/config.pot
+ $(Q)sed -i s/CHARSET/UTF-8/ $(obj)/config.pot
+ $(Q)ln -fs Kconfig.i386 arch/um/Kconfig.arch
+ (for i in `ls arch/`; \
+ do \
+ $(obj)/kxgettext arch/$$i/Kconfig; \
+ done ) >> $(obj)/config.pot
+ msguniq --sort-by-file --to-code=UTF-8 $(obj)/config.pot \
+ --output $(obj)/linux.pot
+ $(Q)rm -f arch/um/Kconfig.arch
+ $(Q)rm -f $(obj)/config.pot
PHONY += randconfig allyesconfig allnoconfig allmodconfig defconfig
Modified: trunk/buildroot/package/config/README.buildroot2
===================================================================
--- trunk/buildroot/package/config/README.buildroot2 2008-06-19 08:11:35 UTC (rev 22449)
+++ trunk/buildroot/package/config/README.buildroot2 2008-06-19 08:11:43 UTC (rev 22450)
@@ -1,15 +1,16 @@
-This is a copy of the kconfig code in the kernel (currently 2.6.22.7) tweaked to
-suit Buildroot.
+This is a copy of the kconfig code in the kernel (currently 2.6.23.14) tweaked
+to suit Buildroot.
To update:
cp -r /usr/src/linux/scripts/kconfig package/config.new
cd package/config.new
cp /usr/src/linux/Documentation/kbuild/kconfig-language.txt .
+ patch -p1 < ../config/kconfig-to-buildroot2.patch
mv Makefile Makefile.kconfig
- patch -p1 < ../config/kconfig-to-buildroot2.patch
cp ../config/README.buildroot2 .
cp ../config/foo.h .
cp ../config/Makefile .
+ cp ../config/kconfig-to-buildroot2.patch .
cd ..
rm -rf config
mv config.new config
Modified: trunk/buildroot/package/config/conf.c
===================================================================
--- trunk/buildroot/package/config/conf.c 2008-06-19 08:11:35 UTC (rev 22449)
+++ trunk/buildroot/package/config/conf.c 2008-06-19 08:11:43 UTC (rev 22450)
@@ -37,6 +37,14 @@
static char nohelp_text[] = N_("Sorry, no help available for this option yet.\n");
+static const char *get_help(struct menu *menu)
+{
+ if (menu_has_help(menu))
+ return menu_get_help(menu);
+ else
+ return nohelp_text;
+}
+
static void strip(char *str)
{
char *p = str;
@@ -172,7 +180,7 @@
int conf_string(struct menu *menu)
{
struct symbol *sym = menu->sym;
- const char *def, *help;
+ const char *def;
while (1) {
printf("%*s%s ", indent - 1, "", menu->prompt->text);
@@ -188,10 +196,7 @@
case '?':
/* print help */
if (line[1] == '\n') {
- help = nohelp_text;
- if (menu->sym->help)
- help = menu->sym->help;
- printf("\n%s\n", menu->sym->help);
+ printf("\n%s\n", get_help(menu));
def = NULL;
break;
}
@@ -209,7 +214,6 @@
struct symbol *sym = menu->sym;
int type;
tristate oldval, newval;
- const char *help;
while (1) {
printf("%*s%s ", indent - 1, "", menu->prompt->text);
@@ -235,7 +239,7 @@
printf("/m");
if (oldval != yes && sym_tristate_within_range(sym, yes))
printf("/y");
- if (sym->help)
+ if (menu_has_help(menu))
printf("/?");
printf("] ");
if (!conf_askvalue(sym, sym_get_string_value(sym)))
@@ -272,10 +276,7 @@
if (sym_set_tristate_value(sym, newval))
return 0;
help:
- help = nohelp_text;
- if (sym->help)
- help = sym->help;
- printf("\n%s\n", help);
+ printf("\n%s\n", get_help(menu));
}
}
@@ -345,7 +346,7 @@
goto conf_childs;
}
printf("[1-%d", cnt);
- if (sym->help)
+ if (menu_has_help(menu))
printf("?");
printf("]: ");
switch (input_mode) {
@@ -362,8 +363,7 @@
fgets(line, 128, stdin);
strip(line);
if (line[0] == '?') {
- printf("\n%s\n", menu->sym->help ?
- menu->sym->help : nohelp_text);
+ printf("\n%s\n", get_help(menu));
continue;
}
if (!line[0])
@@ -394,8 +394,7 @@
if (!child)
continue;
if (line[strlen(line) - 1] == '?') {
- printf("\n%s\n", child->sym->help ?
- child->sym->help : nohelp_text);
+ printf("\n%s\n", get_help(child));
continue;
}
sym_set_choice_value(sym, child->sym);
Modified: trunk/buildroot/package/config/confdata.c
===================================================================
--- trunk/buildroot/package/config/confdata.c 2008-06-19 08:11:35 UTC (rev 22449)
+++ trunk/buildroot/package/config/confdata.c 2008-06-19 08:11:43 UTC (rev 22450)
@@ -338,27 +338,42 @@
conf_unsaved++;
/* maybe print value in verbose mode... */
sym_ok:
+ if (!sym_is_choice(sym))
+ continue;
+ /* The choice symbol only has a set value (and thus is not new)
+ * if all its visible childs have values.
+ */
+ prop = sym_get_choice_prop(sym);
+ flags = sym->flags;
+ for (e = prop->expr; e; e = e->left.expr)
+ if (e->right.sym->visible != no)
+ flags &= e->right.sym->flags;
+ sym->flags &= flags | ~SYMBOL_DEF_USER;
+ }
+
+ for_all_symbols(i, sym) {
if (sym_has_value(sym) && !sym_is_choice_value(sym)) {
- if (sym->visible == no)
+ /* Reset values of generates values, so they'll appear
+ * as new, if they should become visible, but that
+ * doesn't quite work if the Kconfig and the saved
+ * configuration disagree.
+ */
+ if (sym->visible == no && !conf_unsaved)
sym->flags &= ~SYMBOL_DEF_USER;
switch (sym->type) {
case S_STRING:
case S_INT:
case S_HEX:
- if (!sym_string_within_range(sym, sym->def[S_DEF_USER].val))
- sym->flags &= ~(SYMBOL_VALID|SYMBOL_DEF_USER);
+ /* Reset a string value if it's out of range */
+ if (sym_string_within_range(sym, sym->def[S_DEF_USER].val))
+ break;
+ sym->flags &= ~(SYMBOL_VALID|SYMBOL_DEF_USER);
+ conf_unsaved++;
+ break;
default:
break;
}
}
- if (!sym_is_choice(sym))
- continue;
- prop = sym_get_choice_prop(sym);
- flags = sym->flags;
- for (e = prop->expr; e; e = e->left.expr)
- if (e->right.sym->visible != no)
- flags &= e->right.sym->flags;
- sym->flags &= flags | ~SYMBOL_DEF_USER;
}
sym_add_change_count(conf_warnings || conf_unsaved);
Modified: trunk/buildroot/package/config/expr.h
===================================================================
--- trunk/buildroot/package/config/expr.h 2008-06-19 08:11:35 UTC (rev 22449)
+++ trunk/buildroot/package/config/expr.h 2008-06-19 08:11:43 UTC (rev 22450)
@@ -71,14 +71,12 @@
struct symbol {
struct symbol *next;
char *name;
- char *help;
enum symbol_type type;
struct symbol_value curr;
struct symbol_value def[4];
tristate visible;
int flags;
struct property *prop;
- struct expr *dep, *dep2;
struct expr_value rev_dep;
};
@@ -139,7 +137,7 @@
struct property *prompt;
struct expr *dep;
unsigned int flags;
- /*char *help; */
+ char *help;
struct file *file;
int lineno;
void *data;
Modified: trunk/buildroot/package/config/gconf.c
===================================================================
--- trunk/buildroot/package/config/gconf.c 2008-06-19 08:11:35 UTC (rev 22449)
+++ trunk/buildroot/package/config/gconf.c 2008-06-19 08:11:43 UTC (rev 22450)
@@ -38,9 +38,6 @@
static gboolean show_debug = FALSE;
static gboolean resizeable = FALSE;
-static char nohelp_text[] =
- N_("Sorry, no help available for this option yet.\n");
-
GtkWidget *main_wnd = NULL;
GtkWidget *tree1_w = NULL; // left frame
GtkWidget *tree2_w = NULL; // right frame
@@ -462,12 +459,9 @@
GtkTextIter start, end;
const char *prompt = menu_get_prompt(menu);
gchar *name;
- const char *help = _(nohelp_text);
+ const char *help;
- if (!menu->sym)
- help = "";
- else if (menu->sym->help)
- help = _(menu->sym->help);
+ help = _(menu_get_help(menu));
if (menu->sym && menu->sym->name)
name = g_strdup_printf(_(menu->sym->name));
Modified: trunk/buildroot/package/config/kconfig-language.txt
===================================================================
--- trunk/buildroot/package/config/kconfig-language.txt 2008-06-19 08:11:35 UTC (rev 22449)
+++ trunk/buildroot/package/config/kconfig-language.txt 2008-06-19 08:11:43 UTC (rev 22450)
@@ -98,6 +98,15 @@
times, the limit is set to the largest selection.
Reverse dependencies can only be used with boolean or tristate
symbols.
+ Note:
+ select is evil.... select will by brute force set a symbol
+ equal to 'y' without visiting the dependencies. So abusing
+ select you are able to select a symbol FOO even if FOO depends
+ on BAR that is not set. In general use select only for
+ non-visible symbols (no promts anywhere) and for symbols with
+ no dependencies. That will limit the usefulness but on the
+ other hand avoid the illegal configurations all over. kconfig
+ should one day warn about such things.
- numerical ranges: "range" <symbol> <symbol> ["if" <expr>]
This allows to limit the range of possible input values for int
Modified: trunk/buildroot/package/config/kconfig-to-buildroot2.patch
===================================================================
--- trunk/buildroot/package/config/kconfig-to-buildroot2.patch 2008-06-19 08:11:35 UTC (rev 22449)
+++ trunk/buildroot/package/config/kconfig-to-buildroot2.patch 2008-06-19 08:11:43 UTC (rev 22450)
@@ -501,15 +501,6 @@
};
struct symbol {
-@@ -139,7 +139,7 @@ struct menu {
- struct property *prompt;
- struct expr *dep;
- unsigned int flags;
-- //char *help;
-+ /*char *help; */
- struct file *file;
- int lineno;
- void *data;
diff -rdup kernel-config/gconf.c config/gconf.c
--- kernel-config/gconf.c 2007-09-22 00:38:23.000000000 +0200
+++ config/gconf.c 2007-09-23 15:33:26.000000000 +0200
Modified: trunk/buildroot/package/config/kxgettext.c
===================================================================
--- trunk/buildroot/package/config/kxgettext.c 2008-06-19 08:11:35 UTC (rev 22449)
+++ trunk/buildroot/package/config/kxgettext.c 2008-06-19 08:11:43 UTC (rev 22450)
@@ -170,8 +170,8 @@
menu->file == NULL ? "Root Menu" : menu->file->name,
menu->lineno);
- if (menu->sym != NULL && menu->sym->help != NULL)
- message__add(menu->sym->help, menu->sym->name,
+ if (menu->sym != NULL && menu_has_help(menu))
+ message__add(menu_get_help(menu), menu->sym->name,
menu->file == NULL ? "Root Menu" : menu->file->name,
menu->lineno);
@@ -212,7 +212,9 @@
struct message *m = message__list;
while (m != NULL) {
- message__print_gettext_msgid_msgstr(m);
+ /* skip empty lines ("") */
+ if (strlen(m->msg) > sizeof("\"\""))
+ message__print_gettext_msgid_msgstr(m);
m = m->next;
}
}
Modified: trunk/buildroot/package/config/lkc_proto.h
===================================================================
--- trunk/buildroot/package/config/lkc_proto.h 2008-06-19 08:11:35 UTC (rev 22449)
+++ trunk/buildroot/package/config/lkc_proto.h 2008-06-19 08:11:43 UTC (rev 22450)
@@ -15,6 +15,8 @@
P(menu_get_prompt,const char *,(struct menu *menu));
P(menu_get_root_menu,struct menu *,(struct menu *menu));
P(menu_get_parent_menu,struct menu *,(struct menu *menu));
+P(menu_has_help,bool,(struct menu *menu));
+P(menu_get_help,const char *,(struct menu *menu));
/* symbol.c */
P(symbol_hash,struct symbol *,[SYMBOL_HASHSIZE]);
Modified: trunk/buildroot/package/config/lxdialog/check-lxdialog.sh
===================================================================
--- trunk/buildroot/package/config/lxdialog/check-lxdialog.sh 2008-06-19 08:11:35 UTC (rev 22449)
+++ trunk/buildroot/package/config/lxdialog/check-lxdialog.sh 2008-06-19 08:11:43 UTC (rev 22450)
@@ -51,7 +51,7 @@
printf "Usage: $0 [-check compiler options|-header|-library]\n"
}
-if [ $# == 0 ]; then
+if [ $# -eq 0 ]; then
usage
exit 1
fi
Modified: trunk/buildroot/package/config/mconf.c
===================================================================
--- trunk/buildroot/package/config/mconf.c 2008-06-19 08:11:35 UTC (rev 22449)
+++ trunk/buildroot/package/config/mconf.c 2008-06-19 08:11:43 UTC (rev 22450)
@@ -417,11 +417,13 @@
{
struct symbol **sym_arr;
struct gstr res;
+ char *dialog_input;
int dres;
again:
dialog_clear();
dres = dialog_inputbox(_("Search Configuration Parameter"),
- _("Enter CONFIG_ (sub)string to search for (omit CONFIG_)"),
+ _("Enter CONFIG_ (sub)string to search for "
+ "(with or without \"CONFIG\")"),
10, 75, "");
switch (dres) {
case 0:
@@ -433,7 +435,12 @@
return;
}
- sym_arr = sym_re_search(dialog_input_result);
+ /* strip CONFIG_ if necessary */
+ dialog_input = dialog_input_result;
+ if (strncasecmp(dialog_input_result, "CONFIG_", 7) == 0)
+ dialog_input += 7;
+
+ sym_arr = sym_re_search(dialog_input);
res = get_relations_str(sym_arr);
free(sym_arr);
show_textbox(_("Search Results"), str_get(&res), 0, 0);
@@ -716,11 +723,11 @@
struct gstr help = str_new();
struct symbol *sym = menu->sym;
- if (sym->help)
+ if (menu_has_help(menu))
{
if (sym->name) {
str_printf(&help, "CONFIG_%s:\n\n", sym->name);
- str_append(&help, _(sym->help));
+ str_append(&help, _(menu_get_help(menu)));
str_append(&help, "\n");
}
} else {
Modified: trunk/buildroot/package/config/menu.c
===================================================================
--- trunk/buildroot/package/config/menu.c 2008-06-19 08:11:35 UTC (rev 22449)
+++ trunk/buildroot/package/config/menu.c 2008-06-19 08:11:43 UTC (rev 22450)
@@ -417,3 +417,15 @@
return menu;
}
+bool menu_has_help(struct menu *menu)
+{
+ return menu->help != NULL;
+}
+
+const char *menu_get_help(struct menu *menu)
+{
+ if (menu->help)
+ return menu->help;
+ else
+ return "";
+}
Modified: trunk/buildroot/package/config/qconf.cc
===================================================================
--- trunk/buildroot/package/config/qconf.cc 2008-06-19 08:11:35 UTC (rev 22449)
+++ trunk/buildroot/package/config/qconf.cc 2008-06-19 08:11:43 UTC (rev 22450)
@@ -1041,7 +1041,7 @@
if (showDebug())
debug = debug_info(sym);
- help = print_filter(_(sym->help));
+ help = print_filter(_(menu_get_help(menu)));
} else if (menu->prompt) {
head += "<big><b>";
head += print_filter(_(menu->prompt->text));
Modified: trunk/buildroot/package/config/zconf.tab.c_shipped
===================================================================
--- trunk/buildroot/package/config/zconf.tab.c_shipped 2008-06-19 08:11:35 UTC (rev 22449)
+++ trunk/buildroot/package/config/zconf.tab.c_shipped 2008-06-19 08:11:43 UTC (rev 22450)
@@ -1722,7 +1722,7 @@
case 83:
{
- current_entry->sym->help = (yyvsp[0].string);
+ current_entry->help = (yyvsp[0].string);
;}
break;
@@ -2280,11 +2280,11 @@
break;
}
}
- if (sym->help) {
- int len = strlen(sym->help);
- while (sym->help[--len] == '\n')
- sym->help[len] = 0;
- fprintf(out, " help\n%s\n", sym->help);
+ if (menu->help) {
+ int len = strlen(menu->help);
+ while (menu->help[--len] == '\n')
+ menu->help[len] = 0;
+ fprintf(out, " help\n%s\n", menu->help);
}
fputc('\n', out);
}
Modified: trunk/buildroot/package/config/zconf.y
===================================================================
--- trunk/buildroot/package/config/zconf.y 2008-06-19 08:11:35 UTC (rev 22449)
+++ trunk/buildroot/package/config/zconf.y 2008-06-19 08:11:43 UTC (rev 22450)
@@ -402,7 +402,7 @@
help: help_start T_HELPTEXT
{
- current_entry->sym->help = $2;
+ current_entry->help = $2;
};
/* depends option */
@@ -649,11 +649,11 @@
break;
}
}
- if (sym->help) {
- int len = strlen(sym->help);
- while (sym->help[--len] == '\n')
- sym->help[len] = 0;
- fprintf(out, " help\n%s\n", sym->help);
+ if (menu->help) {
+ int len = strlen(menu->help);
+ while (menu->help[--len] == '\n')
+ menu->help[len] = 0;
+ fprintf(out, " help\n%s\n", menu->help);
}
fputc('\n', out);
}
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-04-23 14:39 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-04-23 14:39 UTC (permalink / raw)
To: buildroot
Modified:
trunk/buildroot/package/config/Makefile.kconfig
trunk/buildroot/package/config/README.buildroot2
trunk/buildroot/package/config/conf.c
trunk/buildroot/package/config/confdata.c
trunk/buildroot/package/config/kconfig-language.txt
trunk/buildroot/package/config/kconfig-to-buildroot2.patch
trunk/buildroot/package/config/lex.zconf.c_shipped
trunk/buildroot/package/config/mconf.c
trunk/buildroot/package/config/qconf.cc
trunk/buildroot/package/config/util.c
trunk/buildroot/package/config/zconf.gperf
trunk/buildroot/package/config/zconf.hash.c_shipped
trunk/buildroot/package/config/zconf.tab.c_shipped
trunk/buildroot/package/config/zconf.y
Changeset:
Sorry, the patch is too large to include (4155 lines).
Please use ViewCVS to see it!
http://uclibc.org/cgi-bin/viewcvs.cgi?view=rev&root=svn&rev=22451
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-04-23 14:39 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-04-23 14:39 UTC (permalink / raw)
To: buildroot
Modified:
trunk/buildroot/package/config/Makefile.kconfig
trunk/buildroot/package/config/README.buildroot2
trunk/buildroot/package/config/conf.c
trunk/buildroot/package/config/confdata.c
trunk/buildroot/package/config/kconfig-language.txt
trunk/buildroot/package/config/kconfig-to-buildroot2.patch
trunk/buildroot/package/config/lex.zconf.c_shipped
trunk/buildroot/package/config/mconf.c
trunk/buildroot/package/config/qconf.cc
trunk/buildroot/package/config/util.c
trunk/buildroot/package/config/zconf.gperf
trunk/buildroot/package/config/zconf.hash.c_shipped
trunk/buildroot/package/config/zconf.tab.c_shipped
trunk/buildroot/package/config/zconf.y
Changeset:
Sorry, the patch is too large to include (4155 lines).
Please use ViewCVS to see it!
http://uclibc.org/cgi-bin/viewcvs.cgi?view=3Drev&root=3Dsvn&rev=3D22451
_______________________________________________
buildroot mailing list
buildroot at uclibc.org
http://busybox.net/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-04-23 14:39 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-04-23 14:39 UTC (permalink / raw)
To: buildroot
Added:
trunk/buildroot/package/config/check.sh
Changeset:
Added: trunk/buildroot/package/config/check.sh
===================================================================
--- trunk/buildroot/package/config/check.sh (rev 0)
+++ trunk/buildroot/package/config/check.sh 2008-06-19 19:06:08 UTC (rev 22454)
@@ -0,0 +1,14 @@
+#!/bin/sh
+# Needed for systems without gettext
+$* -xc -o /dev/null - > /dev/null 2>&1 << EOF
+#include <libintl.h>
+int main()
+{
+ gettext("");
+ return 0;
+}
+EOF
+if [ ! "$?" -eq "0" ]; then
+ echo -DKBUILD_NO_NLS;
+fi
+
Property changes on: trunk/buildroot/package/config/check.sh
___________________________________________________________________
Name: svn:executable
+ *
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2008-03-17 22:01 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2008-03-17 22:01 UTC (permalink / raw)
To: buildroot
There is a dependency on buildroot's gcc 3.4.6 that probably should be
added.
As for mapping buildroot's target architectures to uMon ports, that
may be unnecessary. However, the following ports are available in
uMon:
adse_imx21
as3dev
csb250
csb335
csb360
csb472
csb625
csb655
fads860
ads_imx21
bf537
csb272
csb337
csb431
csb535fs
csb637
csb726
mpc852t
v4
altep2c35
csb226
csb281
csb350
csb437tl
csb536fs
csb650
evalsh2
m68en302
walnut
I'm not the best candidate to limit uMon selection to buildroot
architectures that cover those ports.
Josh
On Mon, Mar 31, 2008 at 10:55 PM, Ulf Samuelsson <ulf@atmel.com> wrote:
>
>
> > The following patch adds support for the Microcross Micromonitor
> > (uMon) bootloader.
> > Josh
> >
> >
>
> Does this work for all targets, or do we want to only
> enable the configuration for those targets which
> actually can build uMon?
>
> Best Regards
> Ulf Samuelsson
>
>
>
>
> > diff -purN buildroot/target/Config.in buildroot-umon/target/Config.in
> > --- buildroot/target/Config.in 2008-03-31 00:15:26.000000000 -0700
> > +++ buildroot-umon/target/Config.in 2008-03-31 22:22:09.000000000 -0700
> > @@ -19,6 +19,7 @@ source "target/x86/grub/Config.in"
> > source "target/x86/syslinux/Config.in"
> > source "target/powerpc/yaboot/Config.in"
> > source "target/u-boot/Config.in"
> > +source "target/umon/Config.in"
> > endmenu
> >
> > menu "Kernel"
> > diff -purN buildroot/target/Makefile.in buildroot-umon/target/Makefile.in
> > --- buildroot/target/Makefile.in 2008-03-31 00:15:26.000000000 -0700
> > +++ buildroot-umon/target/Makefile.in 2008-03-31 22:22:30.000000000 -0700
> > @@ -15,6 +15,10 @@ ifeq ($(strip $(BR2_TARGET_UBOOT)),y)
> > include target/u-boot/Makefile.in
> > endif
> >
> > +ifeq ($(strip $(BR2_TARGET_UMON)),y)
> > +include target/umon/Makefile.in
> > +endif
> > +
> > # and finally build the filesystems/tarballs
> > include target/*/*.mk
> >
> > diff -purN buildroot/target/umon/Config.in buildroot-umon/target/umon/Config.in
> > --- buildroot/target/umon/Config.in 1969-12-31 16:00:00.000000000 -0800
> > +++ buildroot-umon/target/umon/Config.in 2008-03-31 22:18:49.000000000 -0700
> > @@ -0,0 +1,20 @@
> > +config BR2_TARGET_UMON
> > + bool "Micromonitor Boot Loader"
> > + default n
> > + help
> > + Build uMon bootloader.
> > +
> > +config BR2_TARGET_UMON_PORT
> > + string "port name"
> > + depends on BR2_TARGET_UMON
> > + default "$(BOARD_NAME)"
> > + help
> > + uMon port name. This is the name of the directory under umon_ports.
> > +
> > +config BR2_TARGET_UMON_CUSTOM_PATCH
> > + string "custom patch"
> > + depends on BR2_TARGET_UMON
> > + help
> > + If your board requires a custom patch, add the path to the file here.
> > + Most users may leave this empty.
> > +
> > diff -purN buildroot/target/umon/Makefile.in
> > buildroot-umon/target/umon/Makefile.in
> > --- buildroot/target/umon/Makefile.in 1969-12-31 16:00:00.000000000 -0800
> > +++ buildroot-umon/target/umon/Makefile.in 2008-03-31 22:18:49.000000000 -0700
> > @@ -0,0 +1,66 @@
> > +#############################################################
> > +#
> > +# umon
> > +#
> > +#############################################################
> > +UMON_VERSION:=sep8_2007
> > +UMON_SOURCE:=umon_$(UMON_VERSION).tgz
> > +UMON_SITE:=http://microcross.com
> > +UMON_PORT:=$(strip $(subst ",,$(BR2_TARGET_UMON_PORT)))
> > +UMON_DIR:=$(PROJECT_BUILD_DIR)/umon/umon_ports/$(UMON_PORT)
> > +UMON_HOST_DIR:=$(PROJECT_BUILD_DIR)/umon/umon_main/host
> > +UMON_PATCH_DIR:=$(PROJECT_BUILD_DIR)/umon-patches
> > +UMON_CAT:=$(ZCAT)
> > +UMON_BIN:=boot.bin
> > +UMON_TOP:=$(PROJECT_BUILD_DIR)/umon/umon_main
> > +# this is a nasty hack to get the PLATFORM variable from the makefile
> > +UMON_PLATFORM:=$$(grep '^PLATFORM.*=' $(UMON_DIR)/makefile | sed
> > 's@^PLATFORM.*=@@')
> > +
> > +$(DL_DIR)/$(UMON_SOURCE):
> > + $(WGET) -P $(DL_DIR) $(UMON_SITE)/$(UMON_SOURCE)
> > +
> > +$(UMON_DIR)/.unpacked: $(DL_DIR)/$(UMON_SOURCE)
> > + $(UMON_CAT) $(DL_DIR)/$(UMON_SOURCE) \
> > + | tar -C $(PROJECT_BUILD_DIR) $(TAR_OPTIONS) -
> > + touch $@
> > +
> > +$(UMON_DIR)/.patched: $(UMON_DIR)/.unpacked
> > +ifneq ($(strip $(BR2_TARGET_UMON_CUSTOM_PATCH)),"")
> > + @mkdir -p $(UMON_PATCH_DIR)
> > + cp -dpr $(BR2_TARGET_UMON_CUSTOM_PATCH) $(UMON_PATCH_DIR)
> > + toolchain/patch-kernel.sh $(PROJECT_BUILD_DIR)/umon $(UMON_PATCH_DIR) *.patch
> > +endif
> > + touch $@
> > +
> > +$(UMON_DIR)/build_$(UMON_PLATFORM)/$(UMON_BIN): $(UMON_DIR)/.patched
> > + $(MAKE) -C $(UMON_HOST_DIR) UMON_TOP=$(UMON_TOP) OSTYPE=linux install
> > + $(MAKE) $(TARGET_CONFIGURE_OPTS) -C $(UMON_DIR) UMONTOP=$(UMON_TOP)
> > +
> > +$(BINARIES_DIR)/$(UMON_BIN): $(UMON_DIR)/build_$(UMON_PLATFORM)/$(UMON_BIN)
> > + cp $(UMON_DIR)/build_$(UMON_PLATFORM)/$(UMON_BIN) $(BINARIES_DIR)/$(UMON_BIN)
> > +
> > +umon: $(BINARIES_DIR)/$(UMON_BIN)
> > +
> > +umon-clean:
> > + $(MAKE) -C $(UMON_DIR) clean
> > +
> > +umon-dirclean:
> > + rm -rf $(UMON_DIR)
> > +
> > +umon-source: $(DL_DIR)/$(UMON_SOURCE)
> > +
> > +#############################################################
> > +#
> > +# Toplevel Makefile options
> > +#
> > +#############################################################
> > +ifeq ($(strip $(BR2_TARGET_UMON)),y)
> > +TARGETS+=umon
> > +endif
> > +
> > +umon-status:
> > + @echo
> > + @echo BR2_TARGET_UMON_PORT = $(BR2_TARGET_UMON_PORT)
> > + @echo BR2_TARGET_UMON_CUSTOM_PATCH = $(BR2_TARGET_UMON_CUSTOM_PATCH)
> > + @echo
> > + @exit 0
> > _______________________________________________
> > buildroot mailing list
> > buildroot at uclibc.org
> > http://busybox.net/mailman/listinfo/buildroot
> >
>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2007-12-01 7:52 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2007-12-01 7:52 UTC (permalink / raw)
To: buildroot
native gcc (not the cross-compiler), which is using headers from
/usr. That looks like a bug, either in the configure script or in the
relevant .mk files for programs that use OpenSSL.
I've got OpenSSL enabled with python linking against it and no such
issues.
Hamish
--
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2007-12-01 7:52 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2007-12-01 7:52 UTC (permalink / raw)
To: buildroot
default "package/busybox/busybox-1.6.0.config" if BR2_BUSYBOX_VERSION_1_9_X
Will> I have fixed it by just going back to the 1.6.0 file - is that correct?
Yes.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2007-10-06 20:13 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2007-10-06 20:13 UTC (permalink / raw)
To: buildroot
I assume make allconfig will give tons of errors.
Today I just tried to make all packages except "Graphic libraries and applications"
and it gave me about 40 errors related with wrong URLs and versions! I'm not talking
about even correctness of installing into staging dir and rootfs packaging.
Best regards,
Ivan
--------------------------------
Embedded Linux engineer,
Promwad Company: http://www.promwad.com/
Homepage : http://www.ivankuten.com/
--------------------------------
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2007-10-06 20:13 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2007-10-06 20:13 UTC (permalink / raw)
To: buildroot
May be strace does not provide correct output?
Regards,
Ivan
ing. Federico Fuga wrote:
> Hi Ivan,
>
> which kernel version and kernel headers are you using? Mine are 2.6.23.1
> and 2.6.23, but now I am trying to move the kernel headers to 2.6.21
> (Angstrom linux works without problems, but are based on different
> kernel headers).
> uclibc I am using are 0.9.29, alsa 1.0.14.
> The failing ioctl is identical both in the working (Angstrom) and not
> working versions, and since the kernel is the same (really the same!) I
> am thinking that is only a problem between the "glue" of uclibc and
> kernel...
> I'll keep you informed.
>
> Regards,
>
> ing. Federico Fuga
>
> Ivan Kuten ha scritto:
>> Hi Federico!
>>
>> I'm observing the same problem with ALSA as you.
>>
>>
>>> ioctl(4, USBDEVFS_CONTROL, 0xbef809cc) = 0
>>> ioctl(4, UI_DEV_CREATE, 0xbef80ab0) = 0
>>> ioctl(4, USBDEVFS_CONNECTINFO, 0xbef80634) = 0
>>> ioctl(4, USBDEVFS_HUB_PORTINFO, 0xbef80748) = -1 ENOTTY (Inappropriate
>>> ioctl for device)
>>>
>> Think these lines are key to understanding what the problem is.
>>
>> Regards,
>> Ivan
>>
>>
>>
>
--------------------------------
Embedded Linux engineer,
Promwad Company: http://www.promwad.com/
Homepage : http://www.ivankuten.com/
--------------------------------
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2007-10-06 20:13 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2007-10-06 20:13 UTC (permalink / raw)
To: buildroot
Regards,
Ivan
--
--------------------------------
Embedded Linux engineer,
Promwad Company: http://www.promwad.com/
Homepage : http://www.ivankuten.com/
--------------------------------
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2007-07-23 18:04 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2007-07-23 18:04 UTC (permalink / raw)
To: buildroot
the extra path arguments to configure at all.
Care to remove those and send a tested, updated patch?
TIA && cheers,
Bernhard
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2007-07-23 18:04 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2007-07-23 18:04 UTC (permalink / raw)
To: buildroot
>
> I Think we should modify this so that the Makefile
> checks for the existance of the source file in $(DL_DIR)
> like most other packages.
> Tried, (see patch below), but the rule:
>
> +$(DL_DIR)/$$($(PKG)_SOURCE):
> $(call MESSAGE,"Downloading")
> test -e $(DL_DIR)/$($(PKG)_SOURCE) || $(WGET) -P $(DL_DIR)
> $($(PKG)_SITE)/$($(PKG)_SOURCE)
> mkdir -p $(@D)
Mainly because of the way, make handles variables. They get
expanded,when the makefile is parsed. Even the doubled dollarsign can't
help you here.
>
> fails (is not found) so I had to add
>
> +$$($(2)_TARGET_SOURCE):
> + $(WGET) -P $(DL_DIR) $$($(2)_SITE)/$$($(2)_SOURCE)
> +
>
In the macro it gets evaluated every time any package wants it to use.
Does that really pays the one unneeded stamp-file?
> to make it work.
> Anyone got a clue why the first rule fails?
>
>
> Maybe we should also consider building x11r7 in $(BUILD_DIR)/x11r7
> due to crowding.
You even get afraid of crowding, aren't you?
>
>
> Index: package/Makefile.autotools.in
> ===================================================================
> --- package/Makefile.autotools.in (revision 19425)
> +++ package/Makefile.autotools.in (arbetskopia)
> @@ -127,7 +127,7 @@
>
> ################################################################################
>
> # Retrieve and unpack the archive
> -$(BUILD_DIR)/%/.stamp_downloaded:
> +$(DL_DIR)/$$($(PKG)_SOURCE):
> $(call MESSAGE,"Downloading")
> test -e $(DL_DIR)/$($(PKG)_SOURCE) || $(WGET) -P $(DL_DIR)
> $($(PKG)_SITE)/$($(PKG)_SOURCE)
> mkdir -p $(@D)
> @@ -279,7 +279,7 @@
> $(2)_TARGET_AUTORECONF = $$($(2)_DIR)/.stamp_autoconfigured
> $(2)_TARGET_PATCH = $$($(2)_DIR)/.stamp_patched
> $(2)_TARGET_EXTRACT = $$($(2)_DIR)/.stamp_extracted
> -$(2)_TARGET_SOURCE = $$($(2)_DIR)/.stamp_downloaded
> +$(2)_TARGET_SOURCE = $$(DL_DIR)/$$($(2)_SOURCE)
> $(2)_TARGET_UNINSTALL = $$($(2)_DIR)/.stamp_uninstalled
> $(2)_TARGET_CLEAN = $$($(2)_DIR)/.stamp_cleaned
> $(2)_TARGET_DIRCLEAN = $$($(2)_DIR)/.stamp_dircleaned
> @@ -322,6 +322,9 @@
>
> $(1)-depends: $(1)-source $$($(2)_DEPENDANCIES)
>
> +$$($(2)_TARGET_SOURCE):
> + $(WGET) -P $(DL_DIR) $$($(2)_SITE)/$$($(2)_SOURCE)
> +
> $(1)-source: $$($(2)_TARGET_SOURCE)
>
> # non-build targets
>
>
> Best Regards
> Ulf Samuelsson
>
>
>
>
>
>
>
> _______________________________________________
> buildroot mailing list
> buildroot at uclibc.org
> http://busybox.net/mailman/listinfo/buildroot
>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2007-06-23 20:07 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2007-06-23 20:07 UTC (permalink / raw)
To: buildroot
* under $(STAGING_DIR)/{bin,lib,include} and $(STAGING_DIR)/{bin,lib}
for the toolchain (e.g. uclibc)
* under $(STAGING_DIR)/usr/{bin,lib,include} and
$(STAGING_DIR)/usr/{bin,lib} for other packages (e.g. gtk)
Is this correct?
If so, we have a problem.
Half the of the package/*/*.mk use one option, half use the other.
As I "svn uped" today, the fontconfig package I had a hard time
patching broke, because expat decided AGAIN to install directly under
/lib.
Please, please establish a clear policy on this, so we can start
submiting patches
--
Julien Letessier
<julien.letessier@technosens.fr>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2007-02-14 8:32 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2007-02-14 8:32 UTC (permalink / raw)
To: buildroot
make[1]: Leaving directory `/tmp/buildroot/package/config'
package/Config.in:33: can't open file "package/config/Config.in"
make: *** [menuconfig] Error 1
Adding Config.h fomr a cvs ckeckout fixed it.
======================================================================
----------------------------------------------------------------------
vapier - 03-20-05 18:38
----------------------------------------------------------------------
works fine for me ...
i turned on these options under packages:
[*] DHCP support
[*] dhcp server
[*] dhcp relay
[*] dhcp client
----------------------------------------------------------------------
thomasez - 03-31-05 11:22
----------------------------------------------------------------------
It has obviously been fixed. This bug should be closed (Yes, I tested this
now aswell).
----------------------------------------------------------------------
vapier - 03-31-05 12:02
----------------------------------------------------------------------
sounds good
Issue History
Date Modified Username Field Change
======================================================================
02-10-05 13:53 thomasez New Issue
03-16-05 12:13 andersen Status new => assigned
03-16-05 12:13 andersen Assigned To => uClibc
03-20-05 18:38 vapier Note Added: 0000109
03-31-05 11:22 thomasez Note Added: 0000121
03-31-05 12:02 vapier Status assigned => closed
03-31-05 12:02 vapier Note Added: 0000122
02-12-07 05:51 vapier Status closed => assigned
02-12-07 05:51 vapier Assigned To uClibc => buildroot
03-08-07 00:13 bernhardf Status assigned => closed
======================================================================
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2007-02-14 8:32 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2007-02-14 8:32 UTC (permalink / raw)
To: buildroot
the build_i386/staging_dir. It seems to be creating a full usr/include,
usr/lib, etc directory hierarchy under inside build_i386/staging_dir,
rather than integrating with the include/lib/etc dirs that exist at the
staging_dir level (ie. the installation of gettext files occurs at one
level too deep)
This means that libintl.h and the shared libraries aren't where other apps
expect it and compilation errors can occur.
The attached patch fixes this - hope it's ok.
Cheers,
Marcus
======================================================================
----------------------------------------------------------------------
prpplague - 05-24-06 07:49
----------------------------------------------------------------------
fixed as of revision 15160
----------------------------------------------------------------------
bernhardf - 03-20-07 11:02
----------------------------------------------------------------------
This was apparently fixed back in r15160. Closing (again).
Issue History
Date Modified Username Field Change
======================================================================
11-29-05 07:56 crafterm New Issue
11-29-05 07:56 crafterm Status new => assigned
11-29-05 07:56 crafterm Assigned To => uClibc
11-29-05 07:56 crafterm File Added: gettext-stagingfix.patch
05-24-06 07:49 prpplague Note Added: 0001377
05-24-06 07:49 prpplague Status assigned => closed
02-12-07 05:45 vapier Status closed => assigned
02-12-07 05:45 vapier Assigned To uClibc => buildroot
03-20-07 11:02 bernhardf Status assigned => closed
03-20-07 11:02 bernhardf Note Added: 0002256
======================================================================
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2007-02-14 8:32 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2007-02-14 8:32 UTC (permalink / raw)
To: buildroot
Does this handle multiple patch-files ?
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2007-02-14 8:32 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2007-02-14 8:32 UTC (permalink / raw)
To: buildroot
people think about this, though.
HTH,
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2007-02-06 7:08 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2007-02-06 7:08 UTC (permalink / raw)
To: buildroot
-e 's/^.*(.CC) \([0-9\.]\)/\1/g' -e "s/[-\ ].*//g"
What do you think?
----------------------------------------------------------------------
bernhardf - 11-28-06 02:08
----------------------------------------------------------------------
fixed in r16703
Issue History
Date Modified Username Field Change
======================================================================
11-20-06 17:47 alchemar New Issue
11-20-06 17:47 alchemar Status new => assigned
11-20-06 17:47 alchemar Assigned To => uClibc
11-20-06 17:47 alchemar File Added: dependencies.sh
11-22-06 13:16 bernhardf Note Added: 0001770
11-22-06 15:41 alchemar Note Added: 0001788
11-22-06 16:14 bernhardf Note Added: 0001789
11-28-06 01:48 bernhardf Note Added: 0001820
11-28-06 02:07 bernhardf Relationship added duplicate of 0000961
11-28-06 02:08 bernhardf Status assigned => closed
11-28-06 02:08 bernhardf Note Added: 0001824
11-28-06 02:08 bernhardf Resolution open => fixed
02-12-07 05:43 vapier Status closed => assigned
02-12-07 05:43 vapier Assigned To uClibc => buildroot
======================================================================
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2007-02-06 7:08 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2007-02-06 7:08 UTC (permalink / raw)
To: buildroot
the build_i386/staging_dir. It seems to be creating a full usr/include,
usr/lib, etc directory hierarchy under inside build_i386/staging_dir,
rather than integrating with the include/lib/etc dirs that exist at the
staging_dir level (ie. the installation of gettext files occurs at one
level too deep)
This means that libintl.h and the shared libraries aren't where other apps
expect it and compilation errors can occur.
The attached patch fixes this - hope it's ok.
Cheers,
Marcus
======================================================================
----------------------------------------------------------------------
prpplague - 05-24-06 07:49
----------------------------------------------------------------------
fixed as of revision 15160
Issue History
Date Modified Username Field Change
======================================================================
11-29-05 07:56 crafterm New Issue
11-29-05 07:56 crafterm Status new => assigned
11-29-05 07:56 crafterm Assigned To => uClibc
11-29-05 07:56 crafterm File Added: gettext-stagingfix.patch
05-24-06 07:49 prpplague Note Added: 0001377
05-24-06 07:49 prpplague Status assigned => closed
02-12-07 05:45 vapier Status closed => assigned
02-12-07 05:45 vapier Assigned To uClibc => buildroot
======================================================================
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2007-02-06 7:08 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2007-02-06 7:08 UTC (permalink / raw)
To: buildroot
targets clean and distclean are to have different effects, depending on
whether or not a .config file is present in the top-level directory.
This is because 'clean' and 'distclean' are part of the noconfig_targets
list.
The attached patch removes clean and distclean from the noconfig_targets
list, allowing the behavior of clean and distclean to vary depending on
whether or not a .config file is present.
======================================================================
Issue History
Date Modified Username Field Change
======================================================================
04-22-05 19:31 samrobb New Issue
04-22-05 19:31 samrobb File Added: noconfig_targets.patch
01-25-06 05:37 prpplague Status assigned => resolved
01-25-06 05:37 prpplague Resolution open => fixed
01-25-06 05:37 prpplague Additional Information Updated
03-08-06 16:53 vapier Status resolved => closed
02-12-07 05:47 vapier Status closed => assigned
02-12-07 05:47 vapier Assigned To uClibc => buildroot
======================================================================
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2007-02-06 7:08 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2007-02-06 7:08 UTC (permalink / raw)
To: buildroot
make[1]: Leaving directory `/tmp/buildroot/package/config'
package/Config.in:33: can't open file "package/config/Config.in"
make: *** [menuconfig] Error 1
Adding Config.h fomr a cvs ckeckout fixed it.
======================================================================
----------------------------------------------------------------------
vapier - 03-20-05 18:38
----------------------------------------------------------------------
works fine for me ...
i turned on these options under packages:
[*] DHCP support
[*] dhcp server
[*] dhcp relay
[*] dhcp client
----------------------------------------------------------------------
thomasez - 03-31-05 11:22
----------------------------------------------------------------------
It has obviously been fixed. This bug should be closed (Yes, I tested this
now aswell).
----------------------------------------------------------------------
vapier - 03-31-05 12:02
----------------------------------------------------------------------
sounds good
Issue History
Date Modified Username Field Change
======================================================================
02-10-05 13:53 thomasez New Issue
03-16-05 12:13 andersen Status new => assigned
03-16-05 12:13 andersen Assigned To => uClibc
03-20-05 18:38 vapier Note Added: 0000109
03-31-05 11:22 thomasez Note Added: 0000121
03-31-05 12:02 vapier Status assigned => closed
03-31-05 12:02 vapier Note Added: 0000122
02-12-07 05:51 vapier Status closed => assigned
02-12-07 05:51 vapier Assigned To uClibc => buildroot
======================================================================
^ permalink raw reply [flat|nested] 732+ messages in thread
* Re: No Subject
2007-02-01 7:54 (unknown) kou.ishizaki
@ 2007-02-04 4:37 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 732+ messages in thread
From: Benjamin Herrenschmidt @ 2007-02-04 4:37 UTC (permalink / raw)
To: kou.ishizaki; +Cc: jens, linuxppc-dev, netdev
> We need to use different auto-neg initial settings between
> for 10/100Mbps ethernet switches and for Gbps ethernet switches.
That is strange ! What PHY chip are you using ? Are you sure it's not
just you not properly configuring the PHY ? Is the datasheet for the PHY
available somewhere ?
> Driver don't know which type of network switch is connected to
> network card, so we try both settings alternately in auto negtiation
> sequences by using a variable "is1000".
sungem has an autoneg sequence that falls back to forced speeds but it's
not useful on any modern setup. Your PHY should be perfectly capable to
autoneg on both 1000bT and 10/100bT...
> Furthermore, we have a problem that poll_link() may succeed even when
> the auto-neg initial setting is for different network switch type,
> and the network card does not work on this case. We retry auto-neg
> with the another initial setting on this case.
Ugh ? What is that initial setting bit exactly ? If the link is up, it
should work.
> >- spider_net_write_reg(card, SPIDER_NET_GMACST,
> >- spider_net_read_reg(card, SPIDER_NET_GMACST));
> >- spider_net_write_reg(card, SPIDER_NET_GMACINTEN, 0x4);
>
> These codes are enabling LINK status interrupt which is disabled
> at the beginning of auto-neg.
> Without this operation, auto negotiation works only when a connection
> detected for the first time, and auto negotiation will not work
> when an ethernet cable is unpluged or pluged.
Most drivers poll the link rather than use an interrupt as those are
often unreliable.
> (3)
> >- mii_phy_probe(phy, phy->mii_id);
> It seems that PHY reset is necessary before auto negotiation,
> after a link once went down.
It shouldn't be... again, what PHY are you using ?
> We can't call directly reset routine from driver, so we call
> mii_phy_probe().
If you really need to reset it, then change sungem_phy.c to export the
reset function. But I'm surprised you need that. Another option is to
reset the PHY in your PHY's setup_aneg() function.
> We are still developping the patch as we noted, and we are considering
> to call mii_phy_probe() from spider_net_setup_aneg(), or to call
> reset_one_mii_phy() from bcm54xx_setup_aneg().
>
> We think these (1)-(3) are necessary, but we are afraid that you removed
> them
> by a reason that they causes some trouble in Cell Blade. If so please
> tell us.
You might want to borrow the link state machine from sungem.c instead...
it tends to just work :-)
Ben.
^ permalink raw reply [flat|nested] 732+ messages in thread
* Re: No Subject
@ 2007-02-04 4:37 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 732+ messages in thread
From: Benjamin Herrenschmidt @ 2007-02-04 4:37 UTC (permalink / raw)
To: kou.ishizaki; +Cc: netdev, linuxppc-dev
> We need to use different auto-neg initial settings between
> for 10/100Mbps ethernet switches and for Gbps ethernet switches.
That is strange ! What PHY chip are you using ? Are you sure it's not
just you not properly configuring the PHY ? Is the datasheet for the PHY
available somewhere ?
> Driver don't know which type of network switch is connected to
> network card, so we try both settings alternately in auto negtiation
> sequences by using a variable "is1000".
sungem has an autoneg sequence that falls back to forced speeds but it's
not useful on any modern setup. Your PHY should be perfectly capable to
autoneg on both 1000bT and 10/100bT...
> Furthermore, we have a problem that poll_link() may succeed even when
> the auto-neg initial setting is for different network switch type,
> and the network card does not work on this case. We retry auto-neg
> with the another initial setting on this case.
Ugh ? What is that initial setting bit exactly ? If the link is up, it
should work.
> >- spider_net_write_reg(card, SPIDER_NET_GMACST,
> >- spider_net_read_reg(card, SPIDER_NET_GMACST));
> >- spider_net_write_reg(card, SPIDER_NET_GMACINTEN, 0x4);
>
> These codes are enabling LINK status interrupt which is disabled
> at the beginning of auto-neg.
> Without this operation, auto negotiation works only when a connection
> detected for the first time, and auto negotiation will not work
> when an ethernet cable is unpluged or pluged.
Most drivers poll the link rather than use an interrupt as those are
often unreliable.
> (3)
> >- mii_phy_probe(phy, phy->mii_id);
> It seems that PHY reset is necessary before auto negotiation,
> after a link once went down.
It shouldn't be... again, what PHY are you using ?
> We can't call directly reset routine from driver, so we call
> mii_phy_probe().
If you really need to reset it, then change sungem_phy.c to export the
reset function. But I'm surprised you need that. Another option is to
reset the PHY in your PHY's setup_aneg() function.
> We are still developping the patch as we noted, and we are considering
> to call mii_phy_probe() from spider_net_setup_aneg(), or to call
> reset_one_mii_phy() from bcm54xx_setup_aneg().
>
> We think these (1)-(3) are necessary, but we are afraid that you removed
> them
> by a reason that they causes some trouble in Cell Blade. If so please
> tell us.
You might want to borrow the link state machine from sungem.c instead...
it tends to just work :-)
Ben.
^ permalink raw reply [flat|nested] 732+ messages in thread
* Re: No Subject
2006-10-09 23:13 (no subject) albox
@ 2006-10-09 23:31 ` Tobin Davis
0 siblings, 0 replies; 732+ messages in thread
From: Tobin Davis @ 2006-10-09 23:31 UTC (permalink / raw)
To: albox; +Cc: alsa-devel
[-- Attachment #1.1: Type: text/plain, Size: 11989 bytes --]
Ok, here is a slightly different approach. If this one works, then
there is an undocumented register in the 883 that is being used (well,
at least it's listed as vendor defined).
I also corrected the subdevice ID.
Tobin
On Tue, 2006-10-10 at 01:13 +0200, albox@free.fr wrote:
>
> It doesn't work for me either (at least, I can load the driver after using the
> patch from Takashi).
>
> Here are some details :
>
> lspci -nv says:
> 0000:00:1b.0 0403: 8086:27d8 (rev 02)
> Subsystem: 161f:2054
> Flags: bus master, fast devsel, latency 0, IRQ 82
> Memory at d5300000 (64-bit, non-prefetchable) [size=16K]
> Capabilities: [50] Power Management version 2
> Capabilities: [60] Message Signalled Interrupts: 64bit+ Queue=0/0
> Enable+
> Capabilities: [70] #10 [0091]
>
> $ dmesg | grep ALSA
> [17179588.696000] ALSA
> /home/albuntu/install/realtek-linux-audiopack-4.05b/alsa-driver-1.0.13/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:680:
> codec_mask = 0x3
> [17179588.876000] ALSA
> /home/albuntu/install/realtek-linux-audiopack-4.05b/alsa-driver-1.0.13/pci/hda/hda_codec.c:1741:
> hda_codec: model 'medion' is selected
> [17179589.604000] ALSA
> /home/albuntu/install/realtek-linux-audiopack-4.05b/alsa-driver-1.0.13/pci/hda/../../alsa-kernel/pci/hda/patch_si3054.c:245:
> si3054: cannot initialize. EXT MID = 0000
> [17179589.612000] ALSA
> /home/albuntu/install/realtek-linux-audiopack-4.05b/alsa-driver-1.0.13/pci/hda/../../alsa-kernel/pci/hda/patch_si3054.c:257:
> Link Frame Detect(FDT) is not ready (line status: 0000)
> [17179635.900000] ALSA
> /home/albuntu/install/realtek-linux-audiopack-4.05b/alsa-driver-1.0.13/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:1142:
> azx_pcm_prepare: bufsize=0x10000, fragsize=0x1000, format=0x11
> [17179635.900000] ALSA
> /home/albuntu/install/realtek-linux-audiopack-4.05b/alsa-driver-1.0.13/pci/hda/hda_codec.c:630:
> hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x11
> [17179635.908000] ALSA
> /home/albuntu/install/realtek-linux-audiopack-4.05b/alsa-driver-1.0.13/pci/hda/hda_codec.c:630:
> hda_codec_setup_stream: NID=0x4, stream=0x5, channel=0, format=0x11
> [17179635.916000] ALSA
> /home/albuntu/install/realtek-linux-audiopack-4.05b/alsa-driver-1.0.13/pci/hda/hda_codec.c:630:
> hda_codec_setup_stream: NID=0x3, stream=0x5, channel=0, format=0x11
> [17179635.924000] ALSA
> /home/albuntu/install/realtek-linux-audiopack-4.05b/alsa-driver-1.0.13/pci/hda/hda_codec.c:630:
> hda_codec_setup_stream: NID=0x5, stream=0x5, channel=0, format=0x11
>
> $ cat /proc/asound/card0/codec#0
> Codec: Realtek ALC883
> Address: 0
> Vendor Id: 0x10ec0883
> Subsystem Id: 0x161fd82b
> Revision Id: 0x100002
> Default PCM: rates 0x560, bits 0x0e, types 0x1
> Default Amp-In caps: N/A
> Default Amp-Out caps: N/A
> Node 0x02 [Audio Output] wcaps 0x11: Stereo
> PCM: rates 0x560, bits 0x0e, types 0x1
> Node 0x03 [Audio Output] wcaps 0x11: Stereo
> PCM: rates 0x560, bits 0x0e, types 0x1
> Node 0x04 [Audio Output] wcaps 0x11: Stereo
> PCM: rates 0x560, bits 0x0e, types 0x1
> Node 0x05 [Audio Output] wcaps 0x11: Stereo
> PCM: rates 0x560, bits 0x0e, types 0x1
> Node 0x06 [Audio Output] wcaps 0x211: Stereo Digital
> PCM: rates 0x560, bits 0x1e, types 0x1
> Node 0x07 [Vendor Defined Widget] wcaps 0xf00000: Mono
> Node 0x08 [Audio Input] wcaps 0x10011b: Stereo Amp-In
> Amp-In caps: ofs=0x08, nsteps=0x1f, stepsize=0x05, mute=1
> Amp-In vals: [0x80 0x80]
> PCM: rates 0x160, bits 0x06, types 0x1
> Connection: 1
> 0x23
> Node 0x09 [Audio Input] wcaps 0x10011b: Stereo Amp-In
> Amp-In caps: ofs=0x08, nsteps=0x1f, stepsize=0x05, mute=1
> Amp-In vals: [0x80 0x80]
> PCM: rates 0x160, bits 0x06, types 0x1
> Connection: 1
> 0x22
> Node 0x0a [Audio Input] wcaps 0x100391: Stereo Digital
> PCM: rates 0x560, bits 0x1e, types 0x1
> Connection: 1
> 0x1f
> Node 0x0b [Audio Mixer] wcaps 0x20010b: Stereo Amp-In
> Amp-In caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1
> Amp-In vals: [0x00 0x00] [0x1f 0x1f] [0x00 0x00] [0x00 0x00] [0x00 0x00]
> [0x00 0x00] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80]
> Connection: 10
> 0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x14 0x15 0x16 0x17
> Node 0x0c [Audio Mixer] wcaps 0x20010f: Stereo Amp-In Amp-Out
> Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
> Amp-In vals: [0x00 0x00] [0x00 0x00]
> Amp-Out caps: ofs=0x1f, nsteps=0x1f, stepsize=0x05, mute=0
> Amp-Out vals: [0x1f 0x1f]
> Connection: 2
> 0x02 0x0b
> Node 0x0d [Audio Mixer] wcaps 0x20010f: Stereo Amp-In Amp-Out
> Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
> Amp-In vals: [0x00 0x00] [0x00 0x00]
> Amp-Out caps: ofs=0x1f, nsteps=0x1f, stepsize=0x05, mute=0
> Amp-Out vals: [0x06 0x06]
> Connection: 2
> 0x03 0x0b
> Node 0x0e [Audio Mixer] wcaps 0x20010f: Stereo Amp-In Amp-Out
> Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
> Amp-In vals: [0x00 0x00] [0x00 0x00]
> Amp-Out caps: ofs=0x1f, nsteps=0x1f, stepsize=0x05, mute=0
> Amp-Out vals: [0x0b 0x07]
> Connection: 2
> 0x04 0x0b
> Node 0x0f [Audio Mixer] wcaps 0x20010f: Stereo Amp-In Amp-Out
> Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
> Amp-In vals: [0x00 0x00] [0x00 0x00]
> Amp-Out caps: ofs=0x1f, nsteps=0x1f, stepsize=0x05, mute=0
> Amp-Out vals: [0x06 0x06]
> Connection: 2
> 0x05 0x0b
> Node 0x10 [Vendor Defined Widget] wcaps 0xf00000: Mono
> Node 0x11 [Vendor Defined Widget] wcaps 0xf00000: Mono
> Node 0x12 [Vendor Defined Widget] wcaps 0xf00000: Mono
> Node 0x13 [Vendor Defined Widget] wcaps 0xf00000: Mono
> Node 0x14 [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out
> Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
> Amp-In vals: [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x00 0x00]
> Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
> Amp-Out vals: [0x00 0x00]
> Pincap 0x083e: IN OUT HP Detect
> Pin Default 0x01011110: [Jack] Line Out at Ext Rear
> Conn = 1/8, Color = Black
> Pin-ctls: 0x40: OUT
> Connection: 5
> 0x0c* 0x0d 0x0e 0x0f 0x26
> Node 0x15 [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out
> Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
> Amp-In vals: [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x00 0x00]
> Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
> Amp-Out vals: [0x00 0x00]
> Pincap 0x083e: IN OUT HP Detect
> Pin Default 0x01011112: [Jack] Line Out at Ext Rear
> Conn = 1/8, Color = Black
> Pin-ctls: 0x40: OUT
> Connection: 5
> 0x0c 0x0d* 0x0e 0x0f 0x26
> Node 0x16 [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out
> Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
> Amp-In vals: [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x00 0x00]
> Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
> Amp-Out vals: [0x00 0x00]
> Pincap 0x083e: IN OUT HP Detect
> Pin Default 0x01011111: [Jack] Line Out at Ext Rear
> Conn = 1/8, Color = Black
> Pin-ctls: 0x40: OUT
> Connection: 5
> 0x0c 0x0d 0x0e* 0x0f 0x26
> Node 0x17 [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out
> Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
> Amp-In vals: [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x00 0x00]
> Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
> Amp-Out vals: [0x00 0x00]
> Pincap 0x083e: IN OUT HP Detect
> Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
> Conn = 1/8, Color = Black
> Pin-ctls: 0x40: OUT
> Connection: 5
> 0x0c 0x0d 0x0e 0x0f* 0x26
> Node 0x18 [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out
> Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
> Amp-In vals: [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x00 0x00]
> Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
> Amp-Out vals: [0x80 0x80]
> Pincap 0x08173e: IN OUT HP Detect
> Pin Default 0x02a11c3f: [Jack] Mic at Ext Front
> Conn = 1/8, Color = Black
> Pin-ctls: 0x24: IN
> Connection: 5
> 0x0c* 0x0d 0x0e 0x0f 0x26
> Node 0x19 [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out
> Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
> Amp-In vals: [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x00 0x00]
> Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
> Amp-Out vals: [0x80 0x80]
> Pincap 0x08173e: IN OUT HP Detect
> Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
> Conn = 1/8, Color = Black
> Pin-ctls: 0x24: IN
> Connection: 5
> 0x0c* 0x0d 0x0e 0x0f 0x26
> Node 0x1a [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out
> Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
> Amp-In vals: [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x00 0x00]
> Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
> Amp-Out vals: [0x80 0x80]
> Pincap 0x08173e: IN OUT HP Detect
> Pin Default 0x99830130: [Fixed] Line In at Int ATAPI
> Conn = ATAPI, Color = Unknown
> Pin-ctls: 0x20: IN
> Connection: 5
> 0x0c* 0x0d 0x0e 0x0f 0x26
> Node 0x1b [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out
> Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
> Amp-In vals: [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x00 0x00]
> Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
> Amp-Out vals: [0x00 0x00]
> Pincap 0x08173e: IN OUT HP Detect
> Pin Default 0x0221111f: [Jack] HP Out at Ext Front
> Conn = 1/8, Color = Black
> Pin-ctls: 0xc0: OUT HP
> Connection: 5
> 0x0c* 0x0d 0x0e 0x0f 0x26
> Node 0x1c [Pin Complex] wcaps 0x400001: Stereo
> Pincap 0x0820: IN
> Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
> Conn = 1/8, Color = Black
> Pin-ctls: 0x00:
> Node 0x1d [Pin Complex] wcaps 0x400000: Mono
> Pincap 0x0820: IN
> Pin Default 0x99830131: [Fixed] Line In at Int ATAPI
> Conn = ATAPI, Color = Unknown
> Pin-ctls: 0x00:
> Node 0x1e [Pin Complex] wcaps 0x400300: Mono Digital
> Pincap 0x0810: OUT
> Pin Default 0x01451120: [Jack] SPDIF Out at Ext Rear
> Conn = Optical, Color = Black
> Pin-ctls: 0x00:
> Connection: 1
> 0x06
> Node 0x1f [Pin Complex] wcaps 0x400200: Mono Digital
> Pincap 0x0820: IN
> Pin Default 0x01c46160: [Jack] SPDIF In at Ext Rear
> Conn = RCA, Color = Orange
> Pin-ctls: 0x00:
> Node 0x20 [Vendor Defined Widget] wcaps 0xf00040: Mono
> Node 0x21 [Vendor Defined Widget] wcaps 0xf00000: Mono
> Node 0x22 [Audio Mixer] wcaps 0x20010f: Stereo Amp-In Amp-Out
> Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
> Amp-In vals: [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x80 0x80] [0x00 0x00]
> [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80]
> Amp-Out caps: N/A
> Amp-Out vals: [0x00 0x00]
> Connection: 11
> 0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x14 0x15 0x16 0x17 0x0b
> Node 0x23 [Audio Mixer] wcaps 0x20010f: Stereo Amp-In Amp-Out
> Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
> Amp-In vals: [0x00 0x00] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80]
> [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80]
> Amp-Out caps: N/A
> Amp-Out vals: [0x00 0x00]
> Connection: 11
> 0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x14 0x15 0x16 0x17 0x0b
> Node 0x24 [Vendor Defined Widget] wcaps 0xf00000: Mono
> Node 0x25 [Audio Output] wcaps 0x11: Stereo
> PCM: rates 0x560, bits 0x0e, types 0x1
> Node 0x26 [Audio Mixer] wcaps 0x20010f: Stereo Amp-In Amp-Out
> Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
> Amp-In vals: [0x00 0x00] [0x80 0x80]
> Amp-Out caps: ofs=0x1f, nsteps=0x1f, stepsize=0x05, mute=0
> Amp-Out vals: [0x00 0x00]
> Connection: 2
> 0x25 0x0b
>
>
> I also tried speaker-test but nothing happened. I'll now try the tarball that
> Remy posted last weekend and I'll let you know if it works...
>
> Cheers,
> AL
--
Tobin Davis <tdavis@dsl-only.net>
[-- Attachment #1.2: Type: text/html, Size: 19325 bytes --]
[-- Attachment #2: medion-test.patch --]
[-- Type: text/x-patch, Size: 1182 bytes --]
--- alsa-driver/alsa-kernel/pci/hda/patch_realtek.c.orig 2006-10-08 10:58:28.000000000 -0700
+++ alsa-driver/alsa-kernel/pci/hda/patch_realtek.c 2006-10-09 10:50:03.000000000 -0700
@@ -112,6 +112,7 @@
ALC883_6ST_DIG,
ALC888_DEMO_BOARD,
ALC883_ACER,
+ ALC883_MEDION,
ALC883_AUTO,
ALC883_MODEL_LAST,
};
@@ -5080,6 +5081,8 @@
.config = ALC883_ACER },
{ .pci_subvendor = 0x1025, .pci_subdevice = 0x009f,
.config = ALC883_ACER },
+ { .pci_subvendor = 0x161f, .pci_subdevice = 0x2054,
+ .modelname = "medion", .config = ALC883_MEDION }
{ .modelname = "auto", .config = ALC883_AUTO },
{}
};
@@ -5167,6 +5170,20 @@
.channel_mode = alc883_3ST_2ch_modes,
.input_mux = &alc883_capture_source,
},
+ [ALC883_MEDION] = {
+ .mixers = { alc883_base_mixer,
+ alc883_chmode_mixer },
+ .init_verbs = { alc882_init_verbs,
+ alc882_eapd_verbs },
+ .num_dacs = ARRAY_SIZE(alc883_dac_nids),
+ .dac_nids = alc883_dac_nids,
+ .num_adc_nids = ARRAY_SIZE(alc883_adc_nids),
+ .adc_nids = alc883_adc_nids,
+ .num_channel_mode = ARRAY_SIZE(alc883_sixstack_modes),
+ .channel_mode = alc883_sixstack_modes,
+ .input_mux = &alc883_capture_source,
+ }
+
};
[-- Attachment #3: Type: text/plain, Size: 348 bytes --]
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
[-- Attachment #4: Type: text/plain, Size: 161 bytes --]
_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2006-08-17 1:58 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2006-08-17 1:58 UTC (permalink / raw)
To: buildroot
gcc-4.x.x
Latest stable GNU config usable for armeb is: binutils-2.16.1 +
gcc-3.4.6
I am wondering if anybody worked on the build of armeb gnu toolchain
with gcc-4.x.x?
gcc-4.x.x provides new interesting cpu types: arm966, arm1176, ...etc
Many thanks for your answers.
Regards - Luc
-----Original Message-----
From: buildroot-bounces@uclibc.org [mailto:buildroot-bounces at uclibc.org]
On Behalf Of Tor Krill
Sent: vendredi 27 octobre 2006 08:07
To: Philippe Ney
Cc: buildroot at uclibc.org
Subject: Re: [Buildroot] Error building arm toolchain: undefined
referenceto `raise'
Quoting Philippe Ney <philippe.ney@pardes.ws>:
> > Hi,
> >
> > I'm trying to build an up to date toolchain for our arm920t board,
> at91rm9200.
> > However compilation fails with a:
> [...]
> >
>
/home/tor/tmp/buildroot/toolchain_build_arm/gcc-4.1.1/gcc/config/arm/lib
1funcs.asm:1000:
> > undefined reference to `raise'
> [...]
> > Am i missing something here?
>
> Have a look at the gumstix buildroot (www.gumstix.org) for a patch=20
> called uClibc-gcc-41-raise-error.patch, I think this will do the
trick.
Thanks Philippe, this solved the compilation error.
/Tor
_______________________________________________
buildroot mailing list
buildroot at uclibc.org
http://busybox.net/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2006-08-17 1:58 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2006-08-17 1:58 UTC (permalink / raw)
To: buildroot
target types), but the usual reponse is 'get the latest version' which seems a
bit of
a cop-out, plus I am currently required to use 3.4.3 so this does not apply.
a) any ideas to defeat this problem (not involving 3.4.x, x>3 !)
b) if it's frequent, how come it's not been resolved once & for all
Thanks,
MikeW
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2006-08-17 1:58 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2006-08-17 1:58 UTC (permalink / raw)
To: buildroot
ccache is a fast compiler cache. It is used as a front end to your compiler to safely cache compilation output. When the same code is compiled again the cached output is used giving a significant speedup (typically 5x).
Is this 5x speedup overstated, or why do you have no need for it?
-------- Original-Nachricht --------
Datum: Fri, 24 Nov 2006 15:10:47 +0100
Von: Bernhard Fischer <rep.nop@aon.at>
An: "Matthias G?lck" <Real.Magic@gmx.de>
Betreff: Re: [Buildroot] problem with absolute paths to tools in ccache
> On Fri, Nov 24, 2006 at 03:06:43PM +0100, "Matthias G?lck" wrote:
> >Thanks for your quick response.
>
> Well, it was not really helpful, i think.
>
> >Could you please tell me, why you do not use ccache?
>
> I simply have no need for it.
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal f?r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2006-08-17 1:58 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2006-08-17 1:58 UTC (permalink / raw)
To: buildroot
ccache is a fast compiler cache. It is used as a front end to your compiler to safely cache compilation output. When the same code is compiled again the cached output is used giving a significant speedup (typically 5x).
Is this 5x speedup overstated, or why do you have no need for it?
-------- Original-Nachricht --------
Datum: Fri, 24 Nov 2006 15:10:47 +0100
Von: Bernhard Fischer <rep.nop@aon.at>
An: "Matthias G?lck" <Real.Magic@gmx.de>
Betreff: Re: [Buildroot] problem with absolute paths to tools in ccache
> On Fri, Nov 24, 2006 at 03:06:43PM +0100, "Matthias G?lck" wrote:
> >Thanks for your quick response.
>
> Well, it was not really helpful, i think.
>
> >Could you please tell me, why you do not use ccache?
>
> I simply have no need for it.
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal f?r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal f?r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2006-08-17 1:58 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2006-08-17 1:58 UTC (permalink / raw)
To: buildroot
ccache is a fast compiler cache. It is used as a front end to your compiler to safely cache compilation output. When the same code is compiled again the cached output is used giving a significant speedup (typically 5x).
Is this 5x speedup overstated, or why do you have no need for it?
--
"Ein Herz f?r Kinder" - Ihre Spende hilft! Aktion: www.deutschlandsegelt.de
Unser Dankesch?n: Ihr Name auf dem Segel der 1. deutschen America's Cup-Yacht!
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2006-08-17 1:58 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2006-08-17 1:58 UTC (permalink / raw)
To: buildroot
ccache is a fast compiler cache. It is used as a front end to your compiler to safely cache compilation output.
When the same code is compiled again the cached output is used giving a significant speedup (typically 5x).
Is this 5x speedup overstated, or why do you have no need for it?
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal f?r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
@ 2006-08-17 1:58 bogus
0 siblings, 0 replies; 732+ messages in thread
From: bogus @ 2006-08-17 1:58 UTC (permalink / raw)
To: buildroot
>>
This seems to be due to an incompatibility between:
1) toolchain.../gcc-x.x.x/config/arm/linux-elf.h
2) toolchain.../binutils-x.x.x/ld/earmelf_linux_eabi.c
In 1) there is a setting TARGET_LINKER_EMULATION "armelf_linux"
In 2) there is a string (part of a struct initialiser) "armelf_linux_eabi"
so unless I can find matching strings in a version of gcc and ld,
buildroot will never be able to build a toolchain.
But 2) says the file is generated by a shell script, so maybe it's
that script which is to blame !
Or maybe I could just hack 1) to have the correct string.
<<
Don't know enough about how this works to fix the discrepancy ...
is there a missing setting (or patch) which should tell
gcc/config/arm/linux-elf.h to append 'eabi' onto the end
of its 'armelf-linux' string ?
Regards,
MikeW
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
[not found] <Pine.LNX.4.33.0111200151170.1364-100000@home.apu.edu>
` (12 preceding siblings ...)
2005-05-19 6:25 ` Rudolf Marek
@ 2005-05-19 6:25 ` Tomáš Thiemel
13 siblings, 0 replies; 732+ messages in thread
From: Tomáš Thiemel @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
Hi.
I have this problem:
==
i2c-piix4.o: IBM Laptop detected; this module may corrupt your serial
eeprom! Refusing to load module!
==
And I have read this message:
####
http://archives.andrew.net.au/lm-sensors/msg01833.html
####
Is my PC on your "whitelist", please?
Thanks a lot
Tomas Thiemel
ICQ #170438916
http://www.wifizabreh.net
PS: What means "serial eeprom" - is it "BIOS chip"?
------------------------------
See information listed below:
***lspci -v ***
..
00:02.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 02)
Flags: medium devsel, IRQ 9
..
***lspci -n***
00:00.0 Class 0600: 8086:7190 (rev 03)
00:01.0 Class 0604: 8086:7191 (rev 03)
00:02.0 Class 0601: 8086:7110 (rev 02)
00:02.1 Class 0101: 8086:7111 (rev 01)
00:02.2 Class 0c03: 8086:7112 (rev 01)
00:02.3 Class 0680: 8086:7113 (rev 02)
00:03.0 Class 0200: 8086:1229 (rev 05)
00:12.0 Class 0280: 1260:3873 (rev 01)
00:14.0 Class 0280: 1260:3873 (rev 01)
01:01.0 Class 0300: 5333:8904 (rev 01)
***cat /var/log/dmesg***
Linux version 2.4.29 (root@wifizabreh2) (gcc version 3.2.2 20030222 (Red
Hat Linux 3.2.2-5)) #12 22:57:14 CEST 07-04-2005
127MB LOWMEM available.
..
IBM machine detected. Enabling interrupts during APM calls.
Kernel command line: ro root=/dev/hda1
No local APIC present or hardware disabled
Initializing CPU#0
Detected 398.272 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 794.62 BogoMIPS
Memory: 126864k/131060k available (1508k kernel code, 3808k reserved,
541k data, 100k init, 0k highmem)
..
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 512K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: After generic, caps: 0183f9ff 00000000 00000000 00000000
CPU: Common caps: 0183f9ff 00000000 00000000 00000000
CPU: Intel Pentium II (Deschutes) stepping 02
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au)
mtrr: detected mtrr type: Intel
PCI: PCI BIOS revision 2.10 entry at 0xfd85c, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
PCI: Using IRQ router PIIX/ICH [8086/7110] at 00:02.0
Limiting direct PCI/PCI transfers.
isapnp: Scanning for PnP cards...
isapnp: Card 'Crystal Audio'
isapnp: 1 Plug & Play card detected total
Linux NET4.0 for Linux 2.4
..
Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
PIIX4: IDE controller at PCI slot 00:02.1
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xfff0-0xfff7, BIOS settings: hda:DMA, hdb:pio
hda: Maxtor 90644D3, ATA DISK drive
blk: queue c0346500, I/O limit 4095Mb (mask 0xffffffff)
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
..
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
[not found] <Pine.LNX.4.33.0111200151170.1364-100000@home.apu.edu>
` (11 preceding siblings ...)
2005-05-19 6:25 ` No subject andreas
@ 2005-05-19 6:25 ` Rudolf Marek
2005-05-19 6:25 ` Tomáš Thiemel
13 siblings, 0 replies; 732+ messages in thread
From: Rudolf Marek @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
Hello,
> I can understand your feelings and complaint absolutely, I'm sorry for
> the trouble and obstacles brought you. I will discuss with my managers
> about it and express your meaning, I think we may improve it in our
> future cooperation.
> Thank you!
Thank you too for good coorporation.
I created some paper for your "responsible manager" staff.
Please forward it to them.
Needs of opensource software development model
on fields of system monitoring
-----------------------------------------------
Most of motherboard manufacturers do not support the hardware monitoring
capabilities of their products in free operating systems (or simply
other than Windows). Thus, open projects were created to build
support of the hardware monitoring chips "on their own".
On the Linux platform project lm-sensors created unified infrastructure and
framework to support different hardware monitoring chips and busses. In mean
time new chips or busses support is handled by members of lm-sensors project.
They are working for free, or sometimes someone supports their work by
donating the hardware, in many cases not the chip makers but frustrated
third parties that are willing to support this project. Cooperation with
manufactures was limited to evaluation board donations or datasheet
support.
We are glad that Winbond decided to work on support of new chips with us,
directly supporting our project with new driver. However to enhance our
future cooperation it is essential to understand specific needs of
open source development.
* Free access to documentation
Our source code is not proprietary, under license conditions anyone can fix
or modify the source code. Chip driver maintenance implies access to chip
documentation. Without that future maintenance of driver is not possible.
* Free access to SMBus host documentation
Our drivers are build upon transport layer provided by other drivers for
SMBus (System Management Bus). It is essential that documentation to this SMBus
host chip is also accessible. We do not need whole southbridge documentation
we just need to know the way how to speak with SMBUS host. Please try to
convince some chipset makers about this, specially NVIDIA, SiS and ALI. Most
of registers is done same way in all chipset following ACPI standart, but
it is essential to know what is done differently.
* Support from motherboard manufacturers
This is very crucial and anticipatory point. There is no cooperation these
days. When motherboard manufacturers follows recommended values of resistors
nets, conversion formulas can be gained from datasheet. End users are happy
that our project is supporting their workstations or company servers instead
of "no support" from motherboard manufacturer. But from time to time
motherboard maker decides to use other components resulting in unknown
conversion formulas. Motherboard manufacturers do not want to disclose
information about the formulas or simply do not respond. This is very
strange behavior, we created our project to support different kind of
hardware and indirectly we are supporting motherboard manufacturers products
by our work. We can't understand that this simple thing is not understood.
* Additional obstacles set by motherboard manufactures
Some created proprietary monitoring interfaces or their own ASIC and they
do not want to disclose documentation to this chips. Some are playing hide
and seek.
Infamous examples:
Abit created their uGuru (in fact programmed Winbond IC), they do not want to
disclose information even to "closed source" companies. Bad luck, we can
only tell to growing Linux userbase - avoid them
ASUS created their own proprietary ASIC chips, however their programming
interface is very very close to Winbond so our driver was developed on
"guesswork". We do not support new chips with no documentation today.
Unfortunately we can't drop support for already supported ones even if
it's a pain.
ASUS is even more creative, they started to hide SMBUS host, later they
start to hide "well known" monitoring chips, result is that we cannot
help much with this to end users. Complaints to ASUS do not work.
Summary
-------
Please try to explain the motherboard companies that they have unique
opportunity to have support of their monitoring chips in Linux with no
additional cost to them, when they will communicate with us and provide
documentation that is essential to support their motherboard.
Please try to explain to chipset makers that we really need parts of
documentation of their southbridge to be able to implement SMBUS host
driver. We do not need full datasheet only small part of it.
When it is not possible to disclose the chip documentation to public we
would like to have a possibility to members of our project to have
shared access to the documentation.
Thank you,
Lm-sensors team.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
[not found] <Pine.LNX.4.33.0111200151170.1364-100000@home.apu.edu>
` (10 preceding siblings ...)
2005-05-19 6:25 ` no subject firase kaled
@ 2005-05-19 6:25 ` andreas
2005-05-19 6:25 ` Rudolf Marek
2005-05-19 6:25 ` Tomáš Thiemel
13 siblings, 0 replies; 732+ messages in thread
From: andreas @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
Hello!
I'm trying to use lm-sensors to drive external equip. for a
meas/control-server for estates. My idea is to use the parallel-port to
hook up some i2c-chips for input/output. If I have understood the docs.
right, my simplest way of doing that will be through the pport driver (no
hardware required, or?). I currently use SuSE 9.2 and the included
lm-sensor package. Maybe I am lost, but how do I get the pport driver? I
have searched everywhere for the driver and info. on how to do it... but
alas. Please give me a hint on how to do, or where to find info. on this
subject.
Thank you in advance.
/Andreas
^ permalink raw reply [flat|nested] 732+ messages in thread
* no subject
[not found] <Pine.LNX.4.33.0111200151170.1364-100000@home.apu.edu>
` (9 preceding siblings ...)
2005-05-19 6:24 ` jmp
@ 2005-05-19 6:25 ` firase kaled
2005-05-19 6:25 ` No subject andreas
` (2 subsequent siblings)
13 siblings, 0 replies; 732+ messages in thread
From: firase kaled @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
hi i have asus motherboard (p4s133-vm) and intel ( D845GVSR) I want to know if
chip driver and bus driver supported or not
thanks
_________________________________________________
See cool party pictures from clubs and restaurants in Jordan, Lebanon, and Dubai. GO to Shuftek Parties now
http://www.shuftak.com
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
[not found] <Pine.LNX.4.33.0111200151170.1364-100000@home.apu.edu>
` (8 preceding siblings ...)
2005-05-19 6:24 ` spreckel
@ 2005-05-19 6:24 ` jmp
2005-05-19 6:25 ` no subject firase kaled
` (3 subsequent siblings)
13 siblings, 0 replies; 732+ messages in thread
From: jmp @ 2005-05-19 6:24 UTC (permalink / raw)
To: lm-sensors
-The dmesg or syslog output if applicable:
______________________________________________
i2c-dev.o: i2c /dev entries driver module
i2c-core.o: driver i2c-dev dummy driver registered.
i2c-dev.o: Registered 'SMBus Via Pro adapter at 0400' as minor 0
i2c-algo-pcf.o: i2c pcf8584 algorithm module
i2c-elektor.o: i2c pcf8584-isa adapter module
i2c-elektor.o: requested I/O region (0x330:2) is in use.
i2c-algo-bit.o: i2c bit algorithm module
i2c-elv.o: i2c ELV parallel port adapter module
i2c-dev.o: Registered 'ELV Parallel port adaptor' as minor 1
i2c-core.o: adapter ELV Parallel port adaptor registered as adapter 1.
i2c-elv.o: found device at 0x378.
i2c-algo-pcf.o: i2c pcf8584 algorithm module
i2c-elektor.o: i2c pcf8584-isa adapter module
i2c-elektor.o: requested I/O region (0x330:2) is in use.
i2c-algo-pcf.o: i2c pcf8584 algorithm module
i2c-elektor.o: i2c pcf8584-isa adapter module
i2c-elektor.o: requested I/O region (0x330:2) is in use.
i2c-philips-par.o: i2c Philips parallel port adapter module
i2c-velleman.o: i2c Velleman K8000 adapter module
i2c-velleman.o: Port 0x378 already in use.
____________________________
* The output of (as root) prog/detect/sensors-detect
______________________________________
[root@flaptop root]# sensors-detect
This program will help you determine which I2C/SMBus modules you need to
load to use lm_sensors most effectively. You need to have i2c and
lm_sensors installed before running this program.
Also, you need to be `root', or at least have access to the /dev/i2c-*
files, for most things.
If you have patched your kernel and have some drivers built-in, you can
safely answer NO if asked to load some modules. In this case, things may
seem a bit confusing, but they will still work.
BIOS vendor (ACPI): AMI
System vendor (DMI): FUJITSU SIEMENS
BIOS version (DMI): 0.28
We can start with probing for (PCI) I2C or SMBus adapters.
You do not need any special privileges for this.
Do you want to probe now? (YES/no): y
Probing for PCI bus adapters...
Use driver `i2c-viapro' for device 00:11.0: VIA Technologies
VT8233A/8235 South Bridge
Probe succesfully concluded.
We will now try to load each adapter module in turn.
Module `i2c-viapro' already loaded.
Do you now want to be prompted for non-detectable adapters? (yes/NO): y
Load `i2c-elektor' (say NO if built into your kernel)? (YES/no): y
/lib/modules/2.4.22-1.2149.nptl/unsupported/drivers/i2c/i2c-elektor.o:
init_module: No such device
Hint: insmod errors can be caused by incorrect module parameters,
including invalid IO or IRQ parameters.
You may find more information in syslog or the output from dmesg
/lib/modules/2.4.22-1.2149.nptl/unsupported/drivers/i2c/i2c-elektor.o:
insmod
/lib/modules/2.4.22-1.2149.nptl/unsupported/drivers/i2c/i2c-elektor.o
failed
/lib/modules/2.4.22-1.2149.nptl/unsupported/drivers/i2c/i2c-elektor.o:
insmod i2c-elektor failed
Loading failed... skipping.
Load `i2c-elv' (say NO if built into your kernel)? (YES/no): y
Module loaded succesfully.
Load `i2c-philips-par' (say NO if built into your kernel)? (YES/no): y
Module loaded succesfully.
Load `i2c-velleman' (say NO if built into your kernel)? (YES/no): y
/lib/modules/2.4.22-1.2149.nptl/unsupported/drivers/i2c/i2c-velleman.o:
init_module: No such device
Hint: insmod errors can be caused by incorrect module parameters,
including invalid IO or IRQ parameters.
You may find more information in syslog or the output from dmesg
/lib/modules/2.4.22-1.2149.nptl/unsupported/drivers/i2c/i2c-velleman.o:
insmod
/lib/modules/2.4.22-1.2149.nptl/unsupported/drivers/i2c/i2c-velleman.o
failed
/lib/modules/2.4.22-1.2149.nptl/unsupported/drivers/i2c/i2c-velleman.o:
insmod i2c-velleman failed
Loading failed... skipping.
To continue, we need module `i2c-dev' to be loaded.
If it is built-in into your kernel, you can safely skip this.
i2c-dev is already loaded.
We are now going to do the adapter probings. Some adapters may hang
halfway
through; we can't really help that. Also, some chips will be double
detected;
we choose the one with the highest confidence value in that case.
If you found that the adapter hung after probing a certain address, you
can
specify that address to remain unprobed. That often
includes address 0x69 (clock chip).
Next adapter: SMBus Via Pro adapter at 0400 (Non-I2C SMBus adapter)
Do you want to scan it? (YES/no/selectively): y
Client at address 0x51 can not be probed - unload all client drivers
first!
Client found at address 0x69
Next adapter: ELV Parallel port adaptor (Bit-shift algorithm)
Do you want to scan it? (YES/no/selectively): y
^X^X^X^X
[root@flaptop root]#
_______________________________
* The output of lsmodIf a PCI chip problem:
* The output of lspci -n
* If an I2C sensor chip problem:
* The output of (as root) prog/detect/i2cdetect X where X = the
bus number (run i2cdetect with no arguments to list the busses)
(please send this only if it's not all XX)
* The output of (as root) prog/dump/i2cdump X 0xXX where XX = the
address of each chip you see in the output of i2cdetect. (run
once for each chip) (please send this only if it's not all ff)
* If an ISA sensor chip problem:
* The output of (as root) prog/dump/isadump 0x295 0x296 (only if
it's not all XX)
* Part numbers of chips on your motherboard you think are the sensor
chips (look at your motherboard)
* Motherboard type
* Sensors version
* Kernel version
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
[not found] <Pine.LNX.4.33.0111200151170.1364-100000@home.apu.edu>
` (7 preceding siblings ...)
2005-05-19 6:24 ` cst01074
@ 2005-05-19 6:24 ` spreckel
2005-05-19 6:24 ` jmp
` (4 subsequent siblings)
13 siblings, 0 replies; 732+ messages in thread
From: spreckel @ 2005-05-19 6:24 UTC (permalink / raw)
To: lm-sensors
[-- Attachment #1: Type: multipart/signed, Size: 0 bytes --]
[-- Attachment #2: Type: text/plain, Size: 766 bytes --]
BIOS vendor (ACPI): PTLTD
System vendor (DMI): IBM
BIOS version (DMI): IYET59WW (1.20 )
Sorry, we won't let you go on. IBM systems are known to have
serious problems with lm_sensors, resulting in hardware failures.
For more information, see README.thinkpad or
http://www2.lm-sensors.nu/~lm78/cvs/lm_sensors2/README.thinkpad.
We used two methods to determine your system's vendor, and they led
to different results. We'd appreciate to have feedback about such
systems. Please, take some time and contact the lm_sensors mailing
list at <sensors@stimpy.netroedge.com>.
We need the following information:
* The brand and model of your system
* The BIOS vendor (ACPI) displayed above
* The System vendor (DMI) displayed above
Thanks!
[-- Attachment #3: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
[not found] <Pine.LNX.4.33.0111200151170.1364-100000@home.apu.edu>
` (6 preceding siblings ...)
2005-05-19 6:24 ` Zaffar Khalid
@ 2005-05-19 6:24 ` cst01074
2005-05-19 6:24 ` spreckel
` (5 subsequent siblings)
13 siblings, 0 replies; 732+ messages in thread
From: cst01074 @ 2005-05-19 6:24 UTC (permalink / raw)
To: lm-sensors
To whom it may concern,
I am a student at Camosun College in Victoria, B.C.. As a project for a RedHat Linux System Admin
course that I am currently taking, my partner and I were given the task of installing (or trying
to install) "lmsensors". Our instructor had made a previous attempt without success, and was not
really expecting us to succeed, but to gain experience in the process. Our instructor has
"lmsensors" running on a few of his own (non-IBM) machines successfully. He was aware of the
obstacles that we would encounter as well. Although we would have liked to have proven him wrong,
we too were unsuccessful.We are running an IBM Xseries 305 server, with multiple IBM NetVista Type
6794-11U subservers all running on Redhat 9 platforms. We encountered the following message during
our installation attempt, and were forced to resign our attempt. Unfortunately, we will also have
to make the focus of our oral report on hardware compatibility issues and the effect that they
have on future purchasing decisions. Are you aware of a patch for IBM machines that can be used
with "lmsensors" so that future students may be more successful than we were? If so, we would be
happy to pass this on to our instructor. The Open Source Community has suggested that they would
be willing to write the patches if the necessary API's were made available.Is that a possibility
for the future?
Thanks in advance for any assistance that you may be able to provide.
This is a printout of the fail message that we encountered.
BIOS vendor (ACPI): PTLTD
System vendor (DMI): IBM
BIOS version (DMI): 20KT34AUS
Sorry, we won't let you go on. IBM systems are known to have
serious problems with lm_sensors, resulting in hardware failures.
For more information, see README.thinkpad or
http://www2.lm-sensors.nu/~lm78/cvs/lm_sensors2/README.thinkpad.
We used two methods to determine your system's vendor, and they led
to different results. We'd appreciate to have feedback about such
systems. Please, take some time and contact the lm_sensors mailing
list at <sensors@stimpy.netroedge.com>.
We need the following information:
* The brand and model of your system
* The BIOS vendor (ACPI) displayed above
* The System vendor (DMI) displayed above
Thanks!
Thanks again,
Brad and Tim
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
[not found] <Pine.LNX.4.33.0111200151170.1364-100000@home.apu.edu>
` (5 preceding siblings ...)
2005-05-19 6:24 ` Kirby Dotson
@ 2005-05-19 6:24 ` Zaffar Khalid
2005-05-19 6:24 ` cst01074
` (6 subsequent siblings)
13 siblings, 0 replies; 732+ messages in thread
From: Zaffar Khalid @ 2005-05-19 6:24 UTC (permalink / raw)
To: lm-sensors
Hello there,
I've got a question for you. I have a system running the Redhat 7.3
operating system and i've tried to run lmsensors on it but i get bogus
values when i run sensors. The chip on the motherboard is the Winbond
w83627hf and i'm using the embedded lmsensors rpm package that comes with
the redhat distribution.
Can you tell me if there is a fix for this problem? Are there any updated
rpms available?
Thanks for your help.
Regards
Zaffar
Systems Engineer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20031121/3635266b/attachment.html
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
[not found] <Pine.LNX.4.33.0111200151170.1364-100000@home.apu.edu>
` (4 preceding siblings ...)
2005-05-19 6:24 ` Bryan Call
@ 2005-05-19 6:24 ` Kirby Dotson
2005-05-19 6:24 ` Zaffar Khalid
` (7 subsequent siblings)
13 siblings, 0 replies; 732+ messages in thread
From: Kirby Dotson @ 2005-05-19 6:24 UTC (permalink / raw)
To: lm-sensors
I', getting compile errors. I've tried what was in
the documentation. Any clues on the following.
Kirby
[root@alpha lm_sensors-2.8.1]#
kernel/busses/i2c-nforce2.c:387: warning: implicit
declaration of function `__devexit_p'
> kernel/busses/i2c-nforce2.c:387: initializer element
is not constant
> kernel/busses/i2c-nforce2.c:387: (near
initialization for `nforce2_driver.remove')
> kernel/busses/i2c-nforce2.c:388: initializer element
is not constant
> kernel/busses/i2c-nforce2.c:388: (near
initialization for `nforce2_driver')
bash: syntax error near unexpected token
``nforce2_driver')'
[root@alpha lm_sensors-2.8.1]# make: ***
[kernel/busses/i2c-nforce2.o] Error 1
bash: make:: command not found
[root@alpha lm_sensors-2.8.1]#
[root@alpha lm_sensors-2.8.1]#
__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
[not found] <Pine.LNX.4.33.0111200151170.1364-100000@home.apu.edu>
` (3 preceding siblings ...)
2005-05-19 6:23 ` Minesh Khatri
@ 2005-05-19 6:24 ` Bryan Call
2005-05-19 6:24 ` Kirby Dotson
` (8 subsequent siblings)
13 siblings, 0 replies; 732+ messages in thread
From: Bryan Call @ 2005-05-19 6:24 UTC (permalink / raw)
To: lm-sensors
I am interested in helping out this project to add support for the Linux
2.5/2.6 kernel.
I am a software developer/manager at yahoo and have many years of software
development experience. I have written system calls and other kernel mods
years ago and would like to get back into that type of programming.
-Bryan Call
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
[not found] <Pine.LNX.4.33.0111200151170.1364-100000@home.apu.edu>
` (2 preceding siblings ...)
2005-05-19 6:23 ` Gyimesi Attila
@ 2005-05-19 6:23 ` Minesh Khatri
2005-05-19 6:24 ` Bryan Call
` (9 subsequent siblings)
13 siblings, 0 replies; 732+ messages in thread
From: Minesh Khatri @ 2005-05-19 6:23 UTC (permalink / raw)
To: lm-sensors
Hi,
I ran your program, sensors-detect, on Red Hat 7.3, and now it has screwed up my
computer (IBM Intellistation). Linux will no longer boot. I was wondering if you
had any solutions or reasons as to why this is happening?
Thanks,
Minesh
__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
[not found] <Pine.LNX.4.33.0111200151170.1364-100000@home.apu.edu>
2005-05-19 6:23 ` SACAH
2005-05-19 6:23 ` Chen, Zhen Y (Zhen)
@ 2005-05-19 6:23 ` Gyimesi Attila
2005-05-19 6:23 ` Minesh Khatri
` (10 subsequent siblings)
13 siblings, 0 replies; 732+ messages in thread
From: Gyimesi Attila @ 2005-05-19 6:23 UTC (permalink / raw)
To: lm-sensors
Hi!
I got this message in every 10 minutes but I don`t know why.
Can you help me?
Jul 9 05:56:15 jam kernel: i2c-ali1535.o: Resetting entire SMB Bus to clear busy condition (08)
Jul 9 05:56:15 jam kernel: i2c-ali1535.o: SMBus reset failed! (0x08) - controller or device on bus is probably hung
JiM
My E-MAIL address :
jim@ond.vein.hu
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
[not found] <Pine.LNX.4.33.0111200151170.1364-100000@home.apu.edu>
2005-05-19 6:23 ` SACAH
@ 2005-05-19 6:23 ` Chen, Zhen Y (Zhen)
2005-05-19 6:23 ` Gyimesi Attila
` (11 subsequent siblings)
13 siblings, 0 replies; 732+ messages in thread
From: Chen, Zhen Y (Zhen) @ 2005-05-19 6:23 UTC (permalink / raw)
To: lm-sensors
hi,
I ran the sensor package on my redhat 6.2, IBM xserver systems.
It has a sensor chip somewhere. But the tool couldn't find a match.
Looks like: 0x30, 0x31, 0x64 are the chips that can't be determined by
the tool.
0x50, 0x53. 0x57 are eeprom chips.
I don't know for sure if the sensor is on the i2c bus, neither i could
identify the chip name and model.
I wonder if you can help me out.
thanks
zhen
OUTPUT from SENSORS_DETECTY:
[root@definity1 detect]# ./sensors-detect
This program will help you to determine which I2C/SMBus modules you
need to
load to use lm_sensors most effectively.
You need to have done a `make install', issued a `depmod -a' and made
sure
`/etc/conf.modules' (or `/etc/modules.conf') contains the appropriate
module path before you can use some functions of this utility. Read
doc/modules for more information.
Also, you need to be `root', or at least have access to the /dev/i2c-*
files
for some things. You can use prog/mkdev/mkdev.sh to create these /dev
files
if you do not have them already.
If you have patched your kernel and have some drivers built-in you can
safely answer NO if asked to load some modules. In this case, things
may
seem a bit confusing, but they will still work.
We can start with probing for (PCI) I2C or SMBus adapters.
You do not need any special privileges for this.
Do you want to probe now? (YES/no): y
Probing for PCI bus adapters...
Sorry, no PCI bus adapters found.
We will now try to load each adapter module in turn.
Do you now want to be prompted for non-detectable adapters? (yes/NO): y
Load `i2c-elektor' (say NO if built into your kernel)? (YES/no): y
Module loaded succesfully.
Load `i2c-elv' (say NO if built into your kernel)? (YES/no): y
/lib/modules/2.2.17-14.1s13smp/misc/i2c-elv.o: init_module: Device or
resource busy
/lib/modules/2.2.17-14.1s13smp/misc/i2c-elv.o: insmod
/lib/modules/2.2.17-14.1s13smp/
misc/i2c-elv.o failed
/lib/modules/2.2.17-14.1s13smp/misc/i2c-elv.o: insmod i2c-elv failed
Loading failed ()... skipping.
Load `i2c-philips-par' (say NO if built into your kernel)? (YES/no): y
Module loaded succesfully.
Load `i2c-velleman' (say NO if built into your kernel)? (YES/no): n
To continue, we need module `i2c-dev' to be loaded.
If it is built-in into your kernel, you can safely skip this.
i2c-dev is already loaded.
We are now going to do the adapter probings. Some adapters may hang
halfway
through; we can't really help that. Also, some chips will be double
detected;
we choose the one with the highest confidence value in that case.
If you found that the adapter hung after probing a certain address, you
can
specify that address to remain unprobed. If you have a PIIX4, that
often
includes addresses 0x69 and/or 0x6a.
Next adapter: SMBus OSB4 adapter at 0440 (Non-I2C SMBus adapter)
Do you want to scan it? (YES/no/selectively): y
Client found at address 0x00
Probing for `National Semiconductor LM78'... Failed!
Probing for `National Semiconductor LM78-J'... Failed!
Probing for `National Semiconductor LM79'... Failed!
Probing for `Winbond W83781D'... Failed!
Probing for `Winbond W83781D'... Failed!
Probing for `Winbond W83782D'... Failed!
Probing for `Winbond W83783S'... Failed!
Probing for `Winbond W83627HF'... Failed!
Probing for `Asus AS99127F'... Failed!
Client found at address 0x30
Probing for `National Semiconductor LM78'... Failed!
Probing for `National Semiconductor LM78-J'... Failed!
Probing for `National Semiconductor LM79'... Failed!
Probing for `Winbond W83781D'... Failed!
Probing for `Winbond W83782D'... Failed!
Probing for `Winbond W83783S'... Failed!
Probing for `Winbond W83627HF'... Failed!
Probing for `Asus AS99127F'... Failed!
Client found at address 0x31
Probing for `National Semiconductor LM78'... Failed!
Probing for `National Semiconductor LM78-J'... Failed!
Probing for `National Semiconductor LM79'... Failed!
Probing for `Winbond W83781D'... Failed!
Probing for `Winbond W83782D'... Failed!
Probing for `Winbond W83783S'... Failed!
Probing for `Winbond W83627HF'... Failed!
Probing for `Asus AS99127F'... Failed!
Client found at address 0x50
Probing for `National Semiconductor LM78'... Failed!
Probing for `National Semiconductor LM78-J'... Failed!
Probing for `National Semiconductor LM79'... Failed!
Probing for `Winbond W83781D'... Failed!
Probing for `Winbond W83782D'... Failed!
Probing for `Winbond W83783S'... Failed!
Probing for `Winbond W83627HF'... Failed!
Probing for `Asus AS99127F'... Failed!
Probing for `Serial EEPROM (PC-100 DIMM)'... Success!
(confidence 8, driver `eeprom')
Probing for `DDC monitor'... Failed!
Client found at address 0x53
Probing for `National Semiconductor LM78'... Failed!
Probing for `National Semiconductor LM78-J'... Failed!
Probing for `National Semiconductor LM79'... Failed!
Probing for `Winbond W83781D'... Failed!
Probing for `Winbond W83782D'... Failed!
Probing for `Winbond W83783S'... Failed!
Probing for `Winbond W83627HF'... Failed!
Probing for `Asus AS99127F'... Failed!
Probing for `Serial EEPROM (PC-100 DIMM)'... Success!
(confidence 8, driver `eeprom')
Client found at address 0x57
Probing for `National Semiconductor LM78'... Failed!
Probing for `National Semiconductor LM78-J'... Failed!
Probing for `National Semiconductor LM78'... Failed!
Probing for `National Semiconductor LM78-J'... Failed!
Probing for `National Semiconductor LM79'... Failed!
Probing for `Winbond W83781D'... Failed!
Probing for `Winbond W83782D'... Failed!
Probing for `Winbond W83783S'... Failed!
Probing for `Winbond W83627HF'... Failed!
Probing for `Asus AS99127F'... Failed!
Probing for `Serial EEPROM (PC-100 DIMM)'... Success!
(confidence 1, driver `eeprom')
Client found at address 0x64
Probing for `National Semiconductor LM78'... Failed!
Probing for `National Semiconductor LM78-J'... Failed!
Probing for `National Semiconductor LM79'... Failed!
Probing for `Winbond W83781D'... Failed!
Probing for `Winbond W83782D'... Failed!
Probing for `Winbond W83783S'... Failed!
Probing for `Winbond W83627HF'... Failed!
Probing for `Asus AS99127F'... Failed!
Next adapter: PCF8584 ISA adapter (PCF8584 algorithm)
Do you want to scan it? (YES/no/selectively): y
Next adapter: Velleman K8000 (Bit-shift algorithm)
Do you want to scan it? (YES/no/selectively): y
Next adapter: PCF8584 ISA adapter (PCF8584 algorithm)
Do you want to scan it? (YES/no/selectively): y
Next adapter: Velleman K8000 (Bit-shift algorithm)
Do you want to scan it? (YES/no/selectively): n
Some chips are also accessible through the ISA bus. ISA probes are
typically a bit more dangerous, as we have to write to I/O ports to do
this. Do you want to scan the ISA bus? (YES/no): y
Probing for `National Semiconductor LM78'
Trying address 0x0290... Failed!
Probing for `National Semiconductor LM78-J'
Trying address 0x0290... Failed!
Probing for `National Semiconductor LM79'
Trying address 0x0290... Failed!
Probing for `Winbond W83781D'
Trying address 0x0290... Failed!
Probing for `Winbond W83782D'
Trying address 0x0290... Failed!
Probing for `Winbond W83627HF'
Trying address 0x0290... Failed!
Probing for `Silicon Integrated Systems SIS5595'
Trying general detect... Failed!
Driver `eeprom' (should be inserted):
Detects correctly:
* Bus `SMBus OSB4 adapter at 0440' (Non-I2C SMBus adapter)
Busdriver `?????', I2C address 0x50
Chip `Serial EEPROM (PC-100 DIMM)' (confidence: 8)
* Bus `SMBus OSB4 adapter at 0440' (Non-I2C SMBus adapter)
Busdriver `?????', I2C address 0x53
Chip `Serial EEPROM (PC-100 DIMM)' (confidence: 8)
* Bus `SMBus OSB4 adapter at 0440' (Non-I2C SMBus adapter)
Busdriver `?????', I2C address 0x57
Chip `Serial EEPROM (PC-100 DIMM)' (confidence: 1)
out put from i2c_detect. i2c dump:
Error: No i2c-bus specified!
Syntax: i2cdetect I2CBUS
I2CBUS is an integer
Installed I2C busses:
i2c-0 smbus SMBus OSB4 adapter at 0440
Non-I2C SMBus
adapter
i2c-1 i2c PCF8584 ISA adapter
PCF8584 algor
ithm
i2c-2 i2c Velleman K8000
Bit-shift alg
orithm
[root@definity1 detect]# ./i2cdetect 0
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: 00 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
30: 30 31 XX XX XX XX XX XX XX XX XX XX XX XX XX XX
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
50: 50 XX XX 53 XX XX XX 57 XX XX XX XX XX XX XX XX
60: XX XX XX XX 64 XX XX XX XX XX XX XX XX XX XX XX
70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
[root@definity1 dump]# ./i2cdump 0 0x30
Warning: no size specified (using byte-data access)
WARNING! This program can confuse your I2C bus, cause data loss and
worse!
I will probe file /dev/i2c-0, address 0x30, mode byte
You have five seconds to reconsider and press CTRL-C!
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: XX ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
20: ff ff ff ff ff XX XX XX XX XX XX XX XX XX XX XX
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
50: XX XX XX ff XX ff ff XX XX XX XX XX XX XX XX XX
60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
80: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
90: XX XX XX XX XX XX XX XX XX XX XX XX ff XX XX XX
a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
f0: XX XX XX XX XX XX ff XX XX XX XX XX XX XX XX XX
[root@definity1 dump]# ./i2cdump 0 0x31
Warning: no size specified (using byte-data access)
WARNING! This program can confuse your I2C bus, cause data loss and
worse!
I will probe file /dev/i2c-0, address 0x31, mode byte
You have five seconds to reconsider and press CTRL-C!
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: 00 00 00 00 02 00 01 07 03 00 00 02 00 01 00 01
10: 03 00 02 00 01 00 03 03 00 02 00 01 07 03 03 00
20: 00 00 05 00 05 04 00 05 04 05 00 06 04 00 00 00
30: 01 07 03 00 00 08 08 00 0a 06 00 00 09 09 00 0a
40: 06 00 00 00 00 00 00 06 00 00 06 06 06 06 06 06
50: 00 07 00 01 01 07 00 05 02 00 06 00 06 02 05 02
60: 00 01 00 07 00 05 07 00 01 01 07 00 05 00 00 03
70: 00 03 00 05 03 04 03 00 00 00 05 00 05 01 01 07
80: 05 05 08 08 00 0a 00 00 05 09 09 00 0b 00 00 05
90: 00 00 00 00 00 00 05 05 05 05 05 05 05 05 32 55
a0: 25 55 6a 45 04 d0 23 5c 3f 44 5a 07 80 e0 13 a0
b0: 04 d8 fb 5c 01 ff 01 51 00 f9 00 b3 00 b5 00 03
c0: 00 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
d0: 55 55 55 55 55 55 55 55 55 55 18 02 03 01 0d 80
e0: 00 00 00 00 00 00 00 55 55 55 55 55 55 55 55 55
f0: 55 55 55 55 01 01 00 00 00 00 01 00 55 55 30 55
[root@definity1 dump]#
[root@definity1 dump]# ./i2cdump 0 0x50
Warning: no size specified (using byte-data access)
WARNING! This program can confuse your I2C bus, cause data loss and
worse!
I will probe file /dev/i2c-0, address 0x50, mode byte
You have five seconds to reconsider and press CTRL-C!
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: 80 08 04 0c 0a 01 48 00 01 75 54 02 80 08 08 01
10: 8f 04 06 01 01 1f 0e a0 60 00 00 14 0f 14 2c 20
20: 15 08 15 08 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 12 df
40: 2c ff ff ff ff ff ff ff 08 39 4c 53 44 54 31 36
50: 37 32 47 2d 31 33 33 45 31 20 20 01 00 01 2c 5b
60: 18 66 ee 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 64 8f
80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[root@definity1 dump]# ./i2cdump 0 0x53
Warning: no size specified (using byte-data access)
WARNING! This program can confuse your I2C bus, cause data loss and
worse!
I will probe file /dev/i2c-0, address 0x53, mode byte
You have five seconds to reconsider and press CTRL-C!
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: 80 08 04 0c 0a 01 48 00 01 75 54 02 80 08 08 01
10: 8f 04 06 01 01 1f 0e a0 60 00 00 14 0f 14 2c 20
20: 15 08 15 08 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 12 df
40: 2c ff ff ff ff ff ff ff 08 39 4c 53 44 54 31 36
50: 37 32 47 2d 31 33 33 45 31 20 20 01 00 01 2c 5b
60: 18 66 e9 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 64 8f
80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[root@definity1 dump]# ./i2cdump 0 0x57
Warning: no size specified (using byte-data access)
WARNING! This program can confuse your I2C bus, cause data loss and
worse!
I will probe file /dev/i2c-0, address 0x57, mode byte
You have five seconds to reconsider and press CTRL-C!
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: 6e d7 00 00 00 00 00 00 00 00 00 00 00 00 34 fa
10: 31 42 36 31 54 37 20 4b 31 30 47 54 53 4c 52 4d
20: 00 00 00 00 32 35 50 33 33 34 37 20 20 20 20 20
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 7f 7f 7f 7f 7f 7f 7f 7f
50: 00 00 42 4f 58 20 53 45 52 49 41 4c 4e 55 4d 42
60: 45 52 00 00 32 35 50 32 31 32 37 20 20 20 20 20
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[root@definity1 dump]# ./i2cdump 0 0x64
Warning: no size specified (using byte-data access)
WARNING! This program can confuse your I2C bus, cause data loss and
worse!
I will probe file /dev/i2c-0, address 0x64, mode byte
You have five seconds to reconsider and press CTRL-C!
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: e0 00 00 00 00 0f 00 00 02 fe 02 01 00 00 00 00
10: 00 00 40 20 00 02 00 00 00 00 ff ff ff ff 00 00
20: e0 00 00 00 00 0f 00 00 02 fe 02 01 00 00 00 00
30: 00 00 40 20 00 02 00 00 00 00 ff ff ff ff 00 00
40: e0 00 00 00 00 0f 00 00 02 fe 02 01 00 00 00 00
50: 00 00 40 20 00 02 00 00 00 00 ff ff ff ff 00 00
60: e0 00 00 00 00 0f 00 00 02 fe 02 01 00 00 00 00
70: 00 00 40 20 00 02 00 00 00 00 ff ff ff ff 00 00
80: e0 00 00 00 00 0f 00 00 02 fe 02 01 00 00 00 00
90: 00 00 40 20 00 02 00 00 00 00 ff ff ff ff 00 00
a0: e0 00 00 00 00 0f 00 00 02 fe 02 01 00 00 00 00
b0: 00 00 40 20 00 02 00 00 00 00 ff ff ff ff 00 00
c0: e0 00 00 00 00 0f 00 00 02 fe 02 01 00 00 00 00
d0: 00 00 40 20 00 02 00 00 00 00 ff ff ff ff 00 00
e0: e0 00 00 00 00 0f 00 00 02 fe 02 01 00 00 00 00
f0: 00 00 40 20 00 02 00 00 00 00 ff ff ff ff 00 00
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20020219/5d6f8b47/attachment.html
^ permalink raw reply [flat|nested] 732+ messages in thread
* No subject
[not found] <Pine.LNX.4.33.0111200151170.1364-100000@home.apu.edu>
@ 2005-05-19 6:23 ` SACAH
2005-05-19 6:23 ` Chen, Zhen Y (Zhen)
` (12 subsequent siblings)
13 siblings, 0 replies; 732+ messages in thread
From: SACAH @ 2005-05-19 6:23 UTC (permalink / raw)
To: lm-sensors
Giday, I am tring to write a little program is Assembly, that will get my CPU's temperature, I have read a lot of documents about SMBus, and how to access it, the address etc, but I can get my programs to work, I have an Asus A7V, running SMBProbe reveals my chip set being VIA VT82C686A. I would like to later expand my program to do my motherboard temp too, and fan speed etc, so if you know of any urls that would help me find those things that would also be greatly apprechiated. I dont understand C at all, and I dont have Linux to be able to play with your source and work it out from that,
Any help you may have would be greatly apprechiated.
Thanks
?ACAH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20011207/54c6eb50/attachment.html
^ permalink raw reply [flat|nested] 732+ messages in thread
* Re: No Subject
2004-12-14 16:49 Andi Kleen
@ 2004-12-15 23:50 ` Alan Cox
0 siblings, 0 replies; 732+ messages in thread
From: Alan Cox @ 2004-12-15 23:50 UTC (permalink / raw)
To: Andi Kleen
Cc: Keir.Fraser, Christian.Limpach, Steven.Hand, Ian.Pratt, akpm,
Linux Kernel Mailing List, riel
The Xen interface seems to me better described that most of the kernel
interfaces and has more papers written on it. I would rather see
arch/xen and public exposure and use of the platform before considering
major redesigns. The s390 people have proved we can remove/fold arch
directories effectively and after original implementation without
problems.
I'm not convinced by your arguments about arch/xen although I am long
term in favour because I'd like see it easy to build a kernel which can
be used without Xen and can switch into Xen guest mode on Xen loading.
Alan
^ permalink raw reply [flat|nested] 732+ messages in thread
* Re: No Subject
2004-07-16 16:54 Hermann Gottschalk
@ 2004-07-16 16:59 ` Jesse Stockall
0 siblings, 0 replies; 732+ messages in thread
From: Jesse Stockall @ 2004-07-16 16:59 UTC (permalink / raw)
To: Hermann Gottschalk; +Cc: linux-kernel
On Fri, 2004-07-16 at 12:54, Hermann Gottschalk wrote:
> unsubscribe
Please follow the instructions at the bottom of every message.
Jesse
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 732+ messages in thread
* Re: No Subject
2004-02-22 17:51 redzic fadil
@ 2004-02-22 20:54 ` Ludootje
0 siblings, 0 replies; 732+ messages in thread
From: Ludootje @ 2004-02-22 20:54 UTC (permalink / raw)
To: redzic fadil; +Cc: linux-kernel
On Sun, 2004-02-22 at 17:51, redzic fadil wrote:
> hello
>
>
> I hope I don't disturb,
>
>
> I have tried to compile the hello.c module under kernel 2.6.3.
> And I'd like to insert the hello.o module in the kernel.
> But this doesn't work with kernel 2.6.3 .
>
> I have compiled this module with kernel 2.4.* and it is well.
See http://lwn.net/Articles/21817 for porting hello world.
(or http://lwn.net/Articles/driver-porting for the entire article)
Ludootje
^ permalink raw reply [flat|nested] 732+ messages in thread
* Re: No Subject
[not found] <Pine.GSO.4.58.0401251223440.20527@waterleaf.sonytel.be>
@ 2004-01-25 13:02 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 732+ messages in thread
From: Benjamin Herrenschmidt @ 2004-01-25 13:02 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Paul Mackerras, Tom Rini, Linux/PPC Development
On Sun, 2004-01-25 at 22:31, Geert Uytterhoeven wrote:
> Hi,
>
> This patch converts <asm/hydra.h> to use explicit-sized types.
> It also applies to 2.4.
Don't you want to port the Hydra code to use the macio infrastructure ?
It would probably require defining the LongTrail as a _MACH_Pmac or
hacking enough of pmac_feature to grok it, but that doesn't seem to
bad actually...
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 732+ messages in thread
* Re: No Subject
2003-02-21 13:43 News Admin
@ 2003-02-21 15:01 ` Alan Cox
0 siblings, 0 replies; 732+ messages in thread
From: Alan Cox @ 2003-02-21 15:01 UTC (permalink / raw)
To: News Admin; +Cc: Linux Kernel Mailing List
On Fri, 2003-02-21 at 13:43, News Admin wrote:
> $ gcc -v
> Reading specs from /usr/lib/gcc-lib/i386-linux/3.2.3/specs
> Configured with: ../src/configure -v
> --enable-languages=c,c++,java,f77,proto,pascal,objc,ada --prefix=/usr
> --mandir=/usr/share/man --infodir=/usr/share/info
> --with-gxx-include-dir=/usr/include/c++/3.2 --enable-shared
> --with-system-zlib --enable-nls --without-included-gettext
> --enable-__cxa_atexit --enable-clocale=gnu --enable-java-gc=boehm
> --enable-objc-gc i386-linux
> Thread model: posix
> gcc version 3.2.3 20030210 (Debian prerelease)
How about using a released gcc compiler not a snapshot. gcc 3.2.1
and 3.2.2 appear to work fine. According to the FSF there is no
gcc 3.2.3 yet, so it isn't suprising a snapshot would have bugs
^ permalink raw reply [flat|nested] 732+ messages in thread
* Re: No Subject
2002-08-05 13:08 Christos Kartsaklis
@ 2002-08-05 14:53 ` Alan Cox
0 siblings, 0 replies; 732+ messages in thread
From: Alan Cox @ 2002-08-05 14:53 UTC (permalink / raw)
To: Christos Kartsaklis; +Cc: linux-kernel
Red Hat put out an errata for the 2.4.7-10 kernel a long time ago. It
fixes numerous problems and indirect bugs as a result. Can you try that
first of all
^ permalink raw reply [flat|nested] 732+ messages in thread
* Re: No Subject
2002-08-04 13:28 ` Henning P. Schmiedehausen
@ 2002-08-04 15:40 ` Daniela Engert
0 siblings, 0 replies; 732+ messages in thread
From: Daniela Engert @ 2002-08-04 15:40 UTC (permalink / raw)
To: hps, linux-kernel
On Sun, 4 Aug 2002 13:28:46 +0000 (UTC), Henning P. Schmiedehausen
wrote:
>Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl> writes:
>>On 4 Aug 2002, Alan Cox wrote:
>>> On Sat, 2002-08-03 at 23:16, Bartlomiej Zolnierkiewicz wrote:
>>> > Just rethough it. What if chipset is in compatibility mode?
>>> > Like VIA with base addresses set to 0?
>>>
>>> If we found a register that was marked as unassigned with a size then we
>>> would map it to a PCI address. That would go for BAR0-3 on any PCI IDE
>>> device attached to the south bridge.
>
>>In compatibility mode IDE chipsets have IO at legacy ISA ports and
>>PCI_BASE_ADDRESS0-3 are set to them or to zero (at least on VIA).
>>And they can't be programmed to any other ports (unless native mode).
>this sounds like a problem that I have with the ServerWorks OSB5
>chipset. I actually have PCI_BASE_ADDRESS0-3 at 0 and
>PCI_BASE_ADDRESS4 = 0x3a0.
>
>Does this hold true here, too? Or is this VIA specific?
PCI IDE controller chips in compatibility mode may exhibit the
following BAR0-3 values (sorted by likelihood of occurance):
most likely: BAR0-3 are all zero
rare : BAR0-3 show the legacy IDE port values
very rare : BAR0-3 contain garbage
In fact, the best strategy is to *ignore* BAR0-3 in compatibility mode
because they have no meaning then!
Ciao,
Dani
^ permalink raw reply [flat|nested] 732+ messages in thread
* Re: No Subject
2002-08-03 22:53 ` Bartlomiej Zolnierkiewicz
@ 2002-08-04 13:28 ` Henning P. Schmiedehausen
2002-08-04 15:40 ` Daniela Engert
0 siblings, 1 reply; 732+ messages in thread
From: Henning P. Schmiedehausen @ 2002-08-04 13:28 UTC (permalink / raw)
To: linux-kernel
Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl> writes:
>On 4 Aug 2002, Alan Cox wrote:
>> On Sat, 2002-08-03 at 23:16, Bartlomiej Zolnierkiewicz wrote:
>> > Just rethough it. What if chipset is in compatibility mode?
>> > Like VIA with base addresses set to 0?
>>
>> If we found a register that was marked as unassigned with a size then we
>> would map it to a PCI address. That would go for BAR0-3 on any PCI IDE
>> device attached to the south bridge.
>>
>> What problems does that cause for the VIA stuff ?
>In compatibility mode IDE chipsets have IO at legacy ISA ports and
>PCI_BASE_ADDRESS0-3 are set to them or to zero (at least on VIA).
>And they can't be programmed to any other ports (unless native mode).
Hi,
this sounds like a problem that I have with the ServerWorks OSB5
chipset. I actually have PCI_BASE_ADDRESS0-3 at 0 and
PCI_BASE_ADDRESS4 = 0x3a0.
Does this hold true here, too? Or is this VIA specific?
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.de
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20
^ permalink raw reply [flat|nested] 732+ messages in thread
* Re: No Subject
2002-08-03 22:16 ` Bartlomiej Zolnierkiewicz
@ 2002-08-03 23:38 ` Alan Cox
2002-08-03 22:53 ` Bartlomiej Zolnierkiewicz
2002-08-03 23:27 ` Petr Vandrovec
0 siblings, 2 replies; 732+ messages in thread
From: Alan Cox @ 2002-08-03 23:38 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Pawel Kot, Marcelo Tosatti, Andre Hedrick, Linux Kernel Mailing List
On Sat, 2002-08-03 at 23:16, Bartlomiej Zolnierkiewicz wrote:
> Just rethough it. What if chipset is in compatibility mode?
> Like VIA with base addresses set to 0?
If we found a register that was marked as unassigned with a size then we
would map it to a PCI address. That would go for BAR0-3 on any PCI IDE
device attached to the south bridge.
What problems does that cause for the VIA stuff ?
^ permalink raw reply [flat|nested] 732+ messages in thread
* Re: No Subject
2002-08-03 23:38 ` Alan Cox
2002-08-03 22:53 ` Bartlomiej Zolnierkiewicz
@ 2002-08-03 23:27 ` Petr Vandrovec
1 sibling, 0 replies; 732+ messages in thread
From: Petr Vandrovec @ 2002-08-03 23:27 UTC (permalink / raw)
To: Alan Cox
Cc: Bartlomiej Zolnierkiewicz, Pawel Kot, Marcelo Tosatti,
Andre Hedrick, Linux Kernel Mailing List
On Sun, Aug 04, 2002 at 12:38:00AM +0100, Alan Cox wrote:
> On Sat, 2002-08-03 at 23:16, Bartlomiej Zolnierkiewicz wrote:
> > Just rethough it. What if chipset is in compatibility mode?
> > Like VIA with base addresses set to 0?
>
> If we found a register that was marked as unassigned with a size then we
> would map it to a PCI address. That would go for BAR0-3 on any PCI IDE
> device attached to the south bridge.
>
> What problems does that cause for the VIA stuff ?
We must read PCI config register 9 (programming interface), and check its value.
If r9 & 0x05 == 0x05, we can program BARs.
Otherwise if r9 & 0x0A != 0x0A, we must not touch hardware: it supports
only legacy 0x1F0/0x170 assignment (PCI-IDE spec says that BAR0-BAR3
can be either hardwired to zero, or it can be writeable, but written
value must be ignored).
If r9 & 0x0A == 0x0A, we must write r9 | 0x05 to PCI config register 9,
and then (after verifying that write suceeded... it does not suceed
in VMware, for example...) we must (re)program BARs.
Worst problem is that (some) VIA chips have BAR0-BAR3 writeable,
but are programmed to ignore them by BIOS (as IRQ14/IRQ15 routing is
not available when in native mode). Current kernel code will believe
that device was relocated, but reality will be different, because of device
ignores BAR0-BAR3 value until programming interface is modified.
Best regards,
Petr Vandrovec
vandrove@vc.cvut.cz
^ permalink raw reply [flat|nested] 732+ messages in thread
* Re: No Subject
2002-08-03 23:38 ` Alan Cox
@ 2002-08-03 22:53 ` Bartlomiej Zolnierkiewicz
2002-08-04 13:28 ` Henning P. Schmiedehausen
2002-08-03 23:27 ` Petr Vandrovec
1 sibling, 1 reply; 732+ messages in thread
From: Bartlomiej Zolnierkiewicz @ 2002-08-03 22:53 UTC (permalink / raw)
To: Alan Cox
Cc: Pawel Kot, Marcelo Tosatti, Andre Hedrick, Linux Kernel Mailing List
On 4 Aug 2002, Alan Cox wrote:
> On Sat, 2002-08-03 at 23:16, Bartlomiej Zolnierkiewicz wrote:
> > Just rethough it. What if chipset is in compatibility mode?
> > Like VIA with base addresses set to 0?
>
> If we found a register that was marked as unassigned with a size then we
> would map it to a PCI address. That would go for BAR0-3 on any PCI IDE
> device attached to the south bridge.
>
> What problems does that cause for the VIA stuff ?
In compatibility mode IDE chipsets have IO at legacy ISA ports and
PCI_BASE_ADDRESS0-3 are set to them or to zero (at least on VIA).
And they can't be programmed to any other ports (unless native mode).
I am just asking if it can cause some problems.
--
Bartlomiej
^ permalink raw reply [flat|nested] 732+ messages in thread
* Re: No Subject
2002-08-03 21:58 ` Bartlomiej Zolnierkiewicz
@ 2002-08-03 22:16 ` Bartlomiej Zolnierkiewicz
2002-08-03 23:38 ` Alan Cox
0 siblings, 1 reply; 732+ messages in thread
From: Bartlomiej Zolnierkiewicz @ 2002-08-03 22:16 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Alan Cox, Pawel Kot, Marcelo Tosatti, andre, Linux Kernel Mailing List
On Sat, 3 Aug 2002, Bartlomiej Zolnierkiewicz wrote:
>
> On 3 Aug 2002, Alan Cox wrote:
>
> > On Sat, 2002-08-03 at 20:26, Pawel Kot wrote:
> > > What helped me was using fixup_device_piix() from -ac in
> > > ide_scan_pcidev(). My controler's ID is DEVID_ICH3M.
> > > It is used in a different, more generic way in -ac, so I don't post the
> > > patch.
> > >
> > > Alan, Marcelo: is there any chance that this change will be ported from
> > > -ac in 2.4.20?
> >
> > I plan to send Marcelo all the IDE updates. Note btw the checking of the
> > return value on pci_enable_device is critical - some old kernels hang on
> > boot with crappy bioses through not checking.
>
> Of course it is critical :-).
>
> > What I begin to the think the right answer is, is to relax the IDE fixup
> > block in the i386 kernel boot up. Right now we avoid assigning
> > unassigned resources for IDE controllers. Clearly we should be doing so.
>
> I think so.
> Andre what do you think?
Just rethough it. What if chipset is in compatibility mode?
Like VIA with base addresses set to 0?
(please note I am not a PCI resource menagament expert ;-)
> And one more thing in ide-pci.c:ide_setup_pci_device() after explicitly
> enabling device's IOs we may need to update dev->resource and we don't
> do this (we place chipset in native mode so i.e. on VIA base addresses
> are just showing up). How to update them?
>
> Regards
> --
> Bartlomiej
^ permalink raw reply [flat|nested] 732+ messages in thread
* Re: No Subject
2002-08-03 21:45 ` No Subject Alan Cox
@ 2002-08-03 21:58 ` Bartlomiej Zolnierkiewicz
2002-08-03 22:16 ` Bartlomiej Zolnierkiewicz
0 siblings, 1 reply; 732+ messages in thread
From: Bartlomiej Zolnierkiewicz @ 2002-08-03 21:58 UTC (permalink / raw)
To: Alan Cox; +Cc: Pawel Kot, Marcelo Tosatti, andre, Linux Kernel Mailing List
On 3 Aug 2002, Alan Cox wrote:
> On Sat, 2002-08-03 at 20:26, Pawel Kot wrote:
> > What helped me was using fixup_device_piix() from -ac in
> > ide_scan_pcidev(). My controler's ID is DEVID_ICH3M.
> > It is used in a different, more generic way in -ac, so I don't post the
> > patch.
> >
> > Alan, Marcelo: is there any chance that this change will be ported from
> > -ac in 2.4.20?
>
> I plan to send Marcelo all the IDE updates. Note btw the checking of the
> return value on pci_enable_device is critical - some old kernels hang on
> boot with crappy bioses through not checking.
Of course it is critical :-).
> What I begin to the think the right answer is, is to relax the IDE fixup
> block in the i386 kernel boot up. Right now we avoid assigning
> unassigned resources for IDE controllers. Clearly we should be doing so.
I think so.
Andre what do you think?
And one more thing in ide-pci.c:ide_setup_pci_device() after explicitly
enabling device's IOs we may need to update dev->resource and we don't
do this (we place chipset in native mode so i.e. on VIA base addresses
are just showing up). How to update them?
Regards
--
Bartlomiej
^ permalink raw reply [flat|nested] 732+ messages in thread
* Re: No Subject
2002-08-03 19:26 Pawel Kot
@ 2002-08-03 21:45 ` Alan Cox
2002-08-03 21:58 ` Bartlomiej Zolnierkiewicz
0 siblings, 1 reply; 732+ messages in thread
From: Alan Cox @ 2002-08-03 21:45 UTC (permalink / raw)
To: Pawel Kot
Cc: Marcelo Tosatti, Linux Kernel Mailing List, Bartlomiej Zolnierkiewicz
On Sat, 2002-08-03 at 20:26, Pawel Kot wrote:
> What helped me was using fixup_device_piix() from -ac in
> ide_scan_pcidev(). My controler's ID is DEVID_ICH3M.
> It is used in a different, more generic way in -ac, so I don't post the
> patch.
>
> Alan, Marcelo: is there any chance that this change will be ported from
> -ac in 2.4.20?
I plan to send Marcelo all the IDE updates. Note btw the checking of the
return value on pci_enable_device is critical - some old kernels hang on
boot with crappy bioses through not checking.
What I begin to the think the right answer is, is to relax the IDE fixup
block in the i386 kernel boot up. Right now we avoid assigning
unassigned resources for IDE controllers. Clearly we should be doing so.
^ permalink raw reply [flat|nested] 732+ messages in thread
* No Subject
@ 2001-08-24 22:16 abraxas2
0 siblings, 0 replies; 732+ messages in thread
From: abraxas2 @ 2001-08-24 22:16 UTC (permalink / raw)
To: linux-kernel
hi everybody,
i have implemented an improved linux ntfs driver.
the following changes have been done :
- full deletion support
- full hardlink support
- support for multiple mft records
- support for chmod, rename, truncate, df, du, ...
- implemented new tools ntchmod, ntlink, ntrm, ntundel (undeletion)
there is a NT port of the tools, too
- fixed a bunch of FIXME's and another bunch of bugs
the kernel part of the sources increased almost to the double.
one of the performed tests was a complete linux kernel build on a
ntfs volume. without any complaints by chkdsk.
this is currently for kernel 2.2.x.
work is in progress for the following items :
- support for kernel 2.4.x
- support for symlinks, device files and chown/chgrp
- full support for compressed files
if you are interested, please send me an email. please indicate if you
want only the kernel part or the complete sources.
Abraxas
<abraxas2@findhere.com>
^ permalink raw reply [flat|nested] 732+ messages in thread
* No Subject
@ 2000-11-19 20:02 jingai
0 siblings, 0 replies; 732+ messages in thread
From: jingai @ 2000-11-19 20:02 UTC (permalink / raw)
To: linuxppc-dev
This may not be the appropriate list to post this on, but since it
does work on my x86 box at work, here goes...
I'm having trouble burning multisession discs with cdrdao. My
TOC file is as follows:
CD_ROM_XA
TRACK AUDIO
FILE "audio.raw" 0
TRACK MODE2_FORM1
DATAFILE "data.raw"
And the command line:
cdrdao write --multi --device 1,4,0 my.toc
Here is the output from cdrdao:
Cdrdao version 1.1.3 - (C) Andreas Mueller <mueller@daneb.ping.de>
SCSI interface library - (C) Joerg Schilling
L-EC encoding library - (C) Heiko Eissfeldt
Paranoia DAE library - (C) Monty
1,4,0: YAMAHA CRW6416S Rev: 1.0c
Using driver: Generic SCSI-3/MMC - Version 1.0 (data) (options 0x0000)
Starting write simulation at speed 6...
Pausing 10 seconds - hit CTRL-C to abort.
Process can be aborted with QUIT signal (usually CTRL-\).
Using POSIX real time scheduling.
Executing power calibration...
cdrdao: No such device or address. Cannot set SG_SET_TIMEOUT.
It is apparently failing on the power calibration, but with the same
CD writer at work, it does not fail here.
My second problem happens both on x86 and PowerPC. If I
specify the --multi option to cdrdao, it fails shortly after the
burn begins (it does write some data to the disc though) with
a buffer underrun. If I omit the --multi option, it burns fine
on x86. Seeing as I am trying to burn a multisession disc,
it's kind of necessary (I think?) to specify the --multi
option.
Both boxes are running Debian woody and kernel 2.2.18pre21.
Any help would be greatly appreciated.
Regards,
Jonathan
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 732+ messages in thread
end of thread, other threads:[~2020-11-25 10:16 UTC | newest]
Thread overview: 732+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-09-13 19:40 No subject bogus
-- strict thread matches above, loose matches on Subject: below --
2020-11-25 10:16 Manuel Reis
2020-05-08 9:43 Patrick Wildt
2019-03-19 14:41 Maxim Levitsky
2019-03-20 11:03 ` Felipe Franciosi
2019-03-20 19:08 ` Maxim Levitsky
2019-03-21 16:12 ` Stefan Hajnoczi
2019-03-21 16:21 ` Keith Busch
2019-03-21 16:41 ` Felipe Franciosi
2019-03-21 17:04 ` Maxim Levitsky
2019-03-22 7:54 ` Felipe Franciosi
2019-03-22 10:32 ` Maxim Levitsky
2019-03-22 15:30 ` Keith Busch
2019-03-25 15:44 ` Felipe Franciosi
2019-03-16 11:17 Bharath Vedartham
2018-10-05 13:39 Christoph Hellwig
2018-08-02 10:48 TU PHUNG VAN
2018-07-06 21:16 Santosh Shilimkar
2018-07-06 21:16 ` Santosh Shilimkar
2018-07-06 21:16 ` Santosh Shilimkar
2018-07-06 21:18 ` Santosh Shilimkar
2018-07-06 5:52 inventsekar
2018-06-23 21:08 David Lechner
2018-05-08 6:10 Vishnu Gopinath
2018-05-04 20:06 Bjorn Helgaas
2018-04-20 8:02 Christoph Hellwig
2018-04-20 8:02 ` Christoph Hellwig
2018-04-16 1:22 Andrew Worsley
2018-02-25 0:39 J Freyensee
2018-02-02 6:54 Jianchao Wang
2017-11-30 10:25 Mary Cuevas
2017-09-13 18:15 unmesh rathi
2017-08-22 1:38 Nicholas Piggin
2017-06-26 13:16 [PATCH] arm64: use readq() instead of readl() to read 64bit entry_point Luc Van Oostenryck
2017-07-03 23:46 ` No subject Khuong Dinh
2017-06-06 7:19 From Lori J. Robinson
2017-06-04 11:59 Yury Norov
[not found] <CAMj-D2DO_CfvD77izsGfggoKP45HSC9aD6auUPAYC9Yeq_aX7w@mail.gmail.com>
2017-05-04 16:44 ` gengdongjiu
2017-04-21 23:23 Sandeep Mann
2017-04-21 4:59 wendyqzx at gmail.com
2017-04-16 15:11 wendyqzx at gmail.com
2017-04-09 10:46 76564 at max.arc.nasa.gov
2017-02-07 0:22 Scott Bauer
2017-02-07 0:46 ` Jens Axboe
2017-01-31 7:58 Andy Gross
2017-01-13 10:46 [PATCH v3 4/8] x86: stop exporting msr-index.h to userland Nicolas Dichtel
2017-01-13 10:46 [PATCH v3 1/8] arm: put types.h in uapi Nicolas Dichtel
2017-01-09 11:33 ` [PATCH v2 0/7] uapi: export all headers under uapi directories Arnd Bergmann
2017-01-13 10:46 ` [PATCH v3 0/8] " Nicolas Dichtel
2017-01-13 15:36 ` No subject David Howells
2017-01-13 15:43 ` David Howells
2016-12-01 10:00 Ramana Radhakrishnan
2016-11-19 18:31 bogus
2016-11-19 18:31 bogus
2016-11-19 18:31 bogus
2016-11-19 18:31 bogus
2016-11-11 3:38 Chunyan Zhang
2016-09-30 14:37 Maxime Ripard
2016-07-10 9:24 Neil Armstrong
2016-07-10 9:24 ` Neil Armstrong
2016-06-13 6:24 bogus
2016-06-13 6:24 bogus
2016-04-22 8:25 Daniel Lezcano
2016-04-22 8:27 ` Daniel Lezcano
2016-04-11 7:51 Paul Walmsley
2016-03-07 17:52 nunojsa
2016-02-09 7:29 bogus
2015-12-13 21:57 何旦洁
2015-11-16 16:13 bogus
2015-10-27 0:44 xuyiping
[not found] <E1ZqY3A-0004Mt-KH@feisty.vs19.net>
2015-10-26 3:21 ` Jiada Wang
2015-10-21 6:17 Rock Lee
2015-10-12 17:26 bogus
2015-09-18 17:23 Shraddha Barke
2015-09-18 4:49 Shraddha Barke
2015-09-01 14:14 Mika Penttilä
2015-09-01 15:22 ` Fabio Estevam
2015-07-22 14:05 Chunfeng Yun
2015-07-15 9:32 Yuan Yao
2015-05-18 20:00 raghu MG
2015-04-21 10:18 Ard Biesheuvel
2015-03-30 4:56 Woody Wu
2015-02-26 16:56 Jorge Ramirez-Ortiz
2015-02-18 16:14 Lee Jones
2015-01-27 16:49 Grzegorz Dwornicki
2014-11-10 6:39 Libo Chen
2014-11-10 3:11 Libo Chen
2014-10-28 14:13 Mark Rutland
2014-09-22 19:41 Santosh Shilimkar
2014-09-22 7:45 Jingchang Lu
2014-09-13 19:40 bogus
2014-09-13 19:40 bogus
2014-09-13 19:40 bogus
2014-09-13 19:40 bogus
2014-08-29 14:22 Ravi Raj
2014-08-29 14:47 ` Valdis.Kletnieks at vt.edu
2014-08-29 14:58 ` Ravi Raj
2014-08-29 15:32 ` No subject Valdis.Kletnieks at vt.edu
2014-08-29 15:34 ` Valdis.Kletnieks at vt.edu
2014-07-09 17:49 Sebastian Andrzej Siewior
2014-06-27 8:01 bogus
2014-06-27 8:01 bogus
2014-06-27 8:01 bogus
2014-06-27 8:01 bogus
2014-05-30 7:51 bogus
2014-05-30 7:51 bogus
2014-05-30 7:51 bogus
2014-05-24 1:21 Loc Ho
2014-05-12 16:40 Santosh Shilimkar
2014-05-12 16:38 Santosh Shilimkar
2014-05-12 4:37 Sivakumar V
2014-04-21 2:59 Amber Thrall
2014-03-03 8:42 bogus
2014-03-03 8:42 bogus
2014-03-03 8:42 bogus
2014-03-03 8:42 bogus
2014-03-03 8:42 bogus
2014-03-03 8:42 bogus
2014-03-03 8:42 bogus
2014-03-03 8:42 bogus
2014-03-03 8:42 bogus
2014-03-03 8:42 bogus
2014-03-03 8:42 bogus
2014-02-22 15:53 Hans de Goede
2014-01-21 4:09 John Tobias
2014-01-16 16:11 Loc Ho
2014-01-16 16:09 Loc Ho
2014-01-13 10:32 Lothar Waßmann
2014-01-13 10:29 Lothar Waßmann
2013-12-16 11:38 bogus
2013-12-16 11:38 bogus
2013-12-16 11:38 bogus
2013-12-16 11:38 bogus
2013-12-16 11:38 bogus
2013-12-16 11:38 bogus
2013-12-16 11:38 bogus
2013-12-16 11:38 bogus
2013-12-12 7:30 Loc Ho
2013-11-01 7:04 Xiubo Li
2013-10-15 19:54 bogus
2013-10-15 19:54 bogus
2013-10-15 19:54 bogus
2013-10-15 19:54 bogus
2013-10-15 19:54 bogus
2013-10-15 19:54 bogus
2013-10-15 19:54 bogus
2013-10-15 19:54 bogus
2013-10-15 19:54 bogus
2013-10-15 19:54 bogus
2013-10-15 19:54 bogus
2013-10-15 19:54 bogus
2013-09-24 3:13 Rohit Vaswani
2013-09-15 9:49 bogus
2013-09-15 9:49 bogus
2013-09-15 9:49 bogus
2013-09-02 17:01 Drasko DRASKOVIC
2013-08-24 9:29 Haojian Zhuang
2013-08-18 1:03 bogus
2013-08-18 1:03 bogus
2013-08-18 1:03 bogus
2013-08-18 1:03 bogus
2013-08-18 1:03 bogus
2013-08-18 1:03 bogus
2013-08-18 1:03 bogus
2013-08-18 1:03 bogus
2013-08-18 1:03 bogus
2013-08-18 1:03 bogus
2013-08-18 1:03 bogus
2013-08-18 1:03 bogus
2013-08-18 1:03 bogus
2013-08-18 1:03 bogus
2013-07-30 4:09 PV Juliet
2013-07-26 10:05 Haojian Zhuang
2013-06-28 5:49 Wang, Yalin
2013-06-19 10:57 Ben Dooks
2013-04-24 18:07 Viral Mehta
2013-04-12 7:08 Callum Hutchinson
2013-04-09 14:12 bogus
2013-04-09 14:12 bogus
2013-04-09 14:12 bogus
2013-04-09 14:12 bogus
2013-04-09 14:12 bogus
2013-04-09 14:12 bogus
2013-04-09 14:12 bogus
2013-04-09 14:12 bogus
2013-04-09 14:12 bogus
2013-04-09 14:12 bogus
2013-04-09 14:12 bogus
2013-04-09 14:12 bogus
2013-04-09 14:12 bogus
2013-04-09 14:12 bogus
2013-04-09 14:12 bogus
2013-04-09 14:12 bogus
2013-04-09 14:12 bogus
2013-04-03 10:31 bogus
2013-04-03 10:31 bogus
2013-04-03 10:31 bogus
2013-04-03 10:31 bogus
2013-02-25 7:24 Prasad Lakshman
2013-02-15 5:48 Kaushal Billore
2013-02-06 22:30 Jimmy Pan
2013-01-16 21:46 bogus
2013-01-16 21:46 bogus
2012-12-29 9:17 steve.zhan
2012-12-05 13:48 Niroj Pokhrel
2012-11-19 11:41 唐忠诚
2012-11-11 14:16 Sammy Chan
2012-11-08 9:33 bogus
2012-11-08 8:07 Abhimanyu Kapur
2012-11-02 10:46 Pritam Bankar
2012-10-15 9:24 Niroj Pokhrel
2012-10-14 10:05 Alexey Dobriyan
2012-10-11 5:38 bogus
2012-10-11 5:38 bogus
2012-10-11 5:38 bogus
2012-10-11 5:38 bogus
2012-10-11 5:38 bogus
2012-10-11 5:38 bogus
2012-10-11 5:38 bogus
2012-10-11 5:38 bogus
2012-10-11 5:38 bogus
2012-10-11 5:38 bogus
2012-10-11 5:38 bogus
2012-10-11 5:38 bogus
2012-10-11 5:38 bogus
2012-10-11 5:38 bogus
2012-10-11 5:38 bogus
2012-10-11 5:38 bogus
2012-10-11 5:38 bogus
2012-10-11 5:38 bogus
2012-10-11 5:38 bogus
2012-10-11 5:38 bogus
2012-10-11 5:38 bogus
2012-10-11 5:38 bogus
2012-10-11 5:38 bogus
2012-10-11 5:38 bogus
2012-10-11 5:38 bogus
2012-10-11 5:38 bogus
2012-10-11 5:38 bogus
2012-10-11 5:38 bogus
2012-10-11 5:38 bogus
2012-10-11 5:38 bogus
2012-10-11 5:38 bogus
2012-10-11 5:38 bogus
2012-08-27 6:40 Simon Horman
2012-08-13 10:09 Vivek Panwar
2012-08-06 10:43 =?gb18030?B?wObC5A==?=
2012-07-30 19:04 siddhesh phadke
2012-06-21 18:26 Paul Walmsley
2012-06-06 10:33 Sascha Hauer
2012-05-25 15:26 bogus
2012-05-25 15:26 bogus
2012-05-18 12:27 Sascha Hauer
2012-04-09 17:56 Martynov Semen
2012-04-10 2:26 ` Vladimir Murzin
2012-04-10 4:03 ` Martynov Semen
2012-04-10 4:48 ` Martynov Semen
2012-04-10 16:08 ` Vladimir Murzin
2012-04-10 17:00 ` Semen Martynov
2012-04-05 7:54 bogus
2012-04-05 7:54 bogus
2012-03-20 18:28 John Szakmeister
2012-02-27 5:00 bogus
2012-02-27 5:00 bogus
2012-02-27 5:00 bogus
2012-01-15 8:24 bogus
2011-12-30 17:16 Philip Anil-QBW348
2011-12-28 14:01 Shawn Guo
2011-12-16 2:18 Swapnil Gaikwad
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-05 12:53 bogus
2011-12-02 16:01 Will Deacon
2011-11-28 2:35 Jett.Zhou
2011-11-21 15:22 Jimmy Pan
2011-11-17 20:02 bogus
2011-11-17 20:02 bogus
2011-11-17 20:02 bogus
2011-11-17 20:02 bogus
2011-11-17 20:02 bogus
2011-11-12 14:39 bogus
2011-11-12 14:39 bogus
2011-09-23 3:42 毕春雷
2011-09-19 1:45 Saleem Abdulrasool
2011-09-15 2:03 Jongpill Lee
2011-08-05 3:08 bogus
2011-08-05 3:08 bogus
2011-08-05 3:08 bogus
2011-08-05 3:08 bogus
2011-08-05 3:08 bogus
2011-07-21 11:12 Padmavathi Venna
2011-06-27 20:47 John Ogness
2011-06-27 20:47 Jongpill Lee
2011-06-16 11:41 Venkateswarlu P
2011-06-14 12:20 Venkateswarlu P
2011-06-13 17:29 Andre Silva
2011-06-05 18:33 Hector Oron
2011-06-04 23:16 bogus
2011-06-04 23:16 bogus
2011-05-17 9:28 Javier Martin
2011-05-13 19:35 Vadim Bendebury
2011-04-07 5:55 bogus
2011-04-07 5:55 bogus
2011-04-07 5:55 bogus
2011-04-07 5:55 bogus
2011-04-07 5:55 bogus
2011-03-22 18:13 nijil yes
2011-03-01 14:02 Javier Martin
2011-02-26 6:20 Aldyth Maharsha
2011-01-13 9:13 Uwe Kleine-König
2011-01-05 11:39 davidgg
2010-12-19 23:59 bogus
2010-12-19 23:59 bogus
2010-12-19 23:59 bogus
2010-12-19 23:59 bogus
2010-12-19 23:59 bogus
2010-12-19 23:59 bogus
2010-12-19 23:59 bogus
2010-12-19 23:59 bogus
2010-12-19 23:59 bogus
2010-12-19 23:59 bogus
2010-12-19 23:59 bogus
2010-12-19 23:59 bogus
2010-12-19 23:59 bogus
2010-12-19 23:59 bogus
2010-12-03 1:08 tarek attia
2010-10-08 6:02 Daein Moon
2010-09-24 14:53 bogus
2010-09-24 14:53 bogus
2010-09-24 14:53 bogus
2010-09-24 14:53 bogus
2010-09-24 14:53 bogus
2010-09-24 14:53 bogus
2010-09-24 14:53 bogus
2010-09-24 14:53 bogus
2010-09-24 14:53 bogus
2010-09-24 14:53 bogus
2010-09-24 14:53 bogus
2010-09-09 3:33 tarek attia
2010-08-30 5:02 auto595907
2010-08-23 14:32 auto595907
2010-07-23 10:05 bogus
2010-06-24 13:48 Uwe Kleine-König
2010-06-07 17:58 Dave Hylands
2010-05-18 10:38 Marek Szyprowski
2010-04-17 21:43 nelakurthi koteswararao
2010-03-25 17:02 bogus
2010-03-25 17:02 bogus
2010-02-25 9:36 Thomas Weber
2009-11-19 13:58 Vimal Singh
2009-09-17 9:37 Marc Kleine-Budde
2009-09-07 14:07 Somshekar ChandrashekarKadam
2009-08-25 10:34 Syed Rafiuddin
2009-02-27 19:01 bogus
2009-02-27 19:01 bogus
2009-02-27 19:01 bogus
2009-02-27 19:01 bogus
2009-02-27 19:01 bogus
2009-02-27 19:01 bogus
2009-02-27 19:01 bogus
2009-02-15 8:49 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-23 10:48 bogus
2009-01-04 17:33 bogus
2009-01-04 17:33 bogus
2008-12-07 21:22 bogus
2008-11-21 1:22 bogus
2008-10-23 17:17 bogus
2008-10-23 17:17 bogus
2008-10-23 17:17 bogus
2008-10-14 11:50 bogus
2008-10-14 11:50 bogus
2008-10-14 11:50 bogus
2008-10-14 11:50 bogus
2008-10-14 11:50 bogus
2008-10-14 11:50 bogus
2008-10-14 11:50 bogus
2008-10-14 11:50 bogus
2008-10-14 11:50 bogus
2008-10-14 11:50 bogus
2008-10-14 11:50 bogus
2008-09-15 17:22 bogus
2008-09-15 17:22 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-08-19 20:18 bogus
2008-07-29 0:03 bogus
2008-07-29 0:03 bogus
2008-07-29 0:03 bogus
2008-07-29 0:03 bogus
2008-07-29 0:03 bogus
2008-07-29 0:03 bogus
2008-07-29 0:03 bogus
2008-07-29 0:03 bogus
2008-07-29 0:03 bogus
2008-07-29 0:03 bogus
2008-07-29 0:03 bogus
2008-07-29 0:03 bogus
2008-07-29 0:03 bogus
2008-07-29 0:03 bogus
2008-07-29 0:03 bogus
2008-07-29 0:03 bogus
2008-07-29 0:03 bogus
2008-07-29 0:03 bogus
2008-07-29 0:03 bogus
2008-07-29 0:03 bogus
2008-07-29 0:03 bogus
2008-07-28 4:41 bogus
2008-07-14 13:16 bogus
2008-07-14 13:16 bogus
2008-07-14 13:16 bogus
2008-07-14 13:16 bogus
2008-04-23 14:39 bogus
2008-04-23 14:39 bogus
2008-04-23 14:39 bogus
2008-04-23 14:39 bogus
2008-04-23 14:39 bogus
2008-04-23 14:39 bogus
2008-04-23 14:39 bogus
2008-04-23 14:39 bogus
2008-04-23 14:39 bogus
2008-03-17 22:01 bogus
2007-12-01 7:52 bogus
2007-12-01 7:52 bogus
2007-10-06 20:13 bogus
2007-10-06 20:13 bogus
2007-10-06 20:13 bogus
2007-07-23 18:04 bogus
2007-07-23 18:04 bogus
2007-06-23 20:07 bogus
2007-02-14 8:32 bogus
2007-02-14 8:32 bogus
2007-02-14 8:32 bogus
2007-02-14 8:32 bogus
2007-02-06 7:08 bogus
2007-02-06 7:08 bogus
2007-02-06 7:08 bogus
2007-02-06 7:08 bogus
2007-02-01 7:54 (unknown) kou.ishizaki
2007-02-04 4:37 ` No Subject Benjamin Herrenschmidt
2007-02-04 4:37 ` Benjamin Herrenschmidt
2006-10-09 23:13 (no subject) albox
2006-10-09 23:31 ` No Subject Tobin Davis
2006-08-17 1:58 No subject bogus
2006-08-17 1:58 bogus
2006-08-17 1:58 bogus
2006-08-17 1:58 bogus
2006-08-17 1:58 bogus
2006-08-17 1:58 bogus
2006-08-17 1:58 bogus
[not found] <Pine.LNX.4.33.0111200151170.1364-100000@home.apu.edu>
2005-05-19 6:23 ` SACAH
2005-05-19 6:23 ` Chen, Zhen Y (Zhen)
2005-05-19 6:23 ` Gyimesi Attila
2005-05-19 6:23 ` Minesh Khatri
2005-05-19 6:24 ` Bryan Call
2005-05-19 6:24 ` Kirby Dotson
2005-05-19 6:24 ` Zaffar Khalid
2005-05-19 6:24 ` cst01074
2005-05-19 6:24 ` spreckel
2005-05-19 6:24 ` jmp
2005-05-19 6:25 ` no subject firase kaled
2005-05-19 6:25 ` No subject andreas
2005-05-19 6:25 ` Rudolf Marek
2005-05-19 6:25 ` Tomáš Thiemel
2004-12-14 16:49 Andi Kleen
2004-12-15 23:50 ` No Subject Alan Cox
2004-07-16 16:54 Hermann Gottschalk
2004-07-16 16:59 ` No Subject Jesse Stockall
2004-02-22 17:51 redzic fadil
2004-02-22 20:54 ` No Subject Ludootje
[not found] <Pine.GSO.4.58.0401251223440.20527@waterleaf.sonytel.be>
2004-01-25 13:02 ` Benjamin Herrenschmidt
2003-02-21 13:43 News Admin
2003-02-21 15:01 ` No Subject Alan Cox
2002-08-05 13:08 Christos Kartsaklis
2002-08-05 14:53 ` No Subject Alan Cox
2002-08-03 19:26 Pawel Kot
2002-08-03 21:45 ` No Subject Alan Cox
2002-08-03 21:58 ` Bartlomiej Zolnierkiewicz
2002-08-03 22:16 ` Bartlomiej Zolnierkiewicz
2002-08-03 23:38 ` Alan Cox
2002-08-03 22:53 ` Bartlomiej Zolnierkiewicz
2002-08-04 13:28 ` Henning P. Schmiedehausen
2002-08-04 15:40 ` Daniela Engert
2002-08-03 23:27 ` Petr Vandrovec
2001-08-24 22:16 abraxas2
2000-11-19 20:02 jingai
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.