* RE: LED heartbeat trigger - in_atomic() while allocs
From: Benedict, Michael @ 2007-11-27 1:02 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-embedded
In-Reply-To: <20071126203649.GD29155@localdomain>
Thanks, yeah I see that now. I just changed the alloc to be GPF_ATOMIC
for now, but I don't really know how this was intended to work.
-Michael=20
> -----Original Message-----
> From:=20
> linuxppc-embedded-bounces+mbenedict=3Dtwacs.com@ozlabs.org=20
> [mailto:linuxppc-embedded-bounces+mbenedict=3Dtwacs.com@ozlabs.o
rg] On Behalf Of Nathan Lynch
> Sent: Monday, November 26, 2007 2:37 PM
> To: Benedict, Michael
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: LED heartbeat trigger - in_atomic() while allocs
>=20
> Benedict, Michael wrote:
> > I was playing around with the LED heartbeat trigger and it=20
> caught the
> > BUG() code when trying to activate. Does anyone know why this call
> > stack would be in_atomic()? Or any ideas for a patch that=20
> would allow
> > the heartbeat trigger to allocate when it is not in atomic context?
> >=20
> > BUG: sleeping function called from invalid context at mm/slab.c:3024
> > in_atomic():1, irqs_disabled():0
> > Call Trace:
> > [def3dd90] [c0008e60] show_stack+0x48/0x194 (unreliable)
> > [def3ddc0] [c0014160] __might_sleep+0xd0/0xdc
> > [def3dde0] [c0063e60] kmem_cache_zalloc+0xdc/0x12c
> > [def3de00] [c01975c0] heartbeat_trig_activate+0x24/0x80
> > [def3de20] [c0196844] led_trigger_set+0x128/0x160
> > [def3de40] [c0196988] led_trigger_store+0x10c/0x1a8
> > [def3deb0] [c0162f40] class_device_attr_store+0x44/0x5c
> > [def3dec0] [c00ae614] sysfs_write_file+0x114/0x1dc
> > [def3def0] [c0068ea4] vfs_write+0x9c/0x110
> > [def3df10] [c0068ff4] sys_write+0x4c/0x90
> > [def3df40] [c000fc00] ret_from_syscall+0x0/0x38
> > --- Exception: c01 at 0xfe83818
> > LR =3D 0xfe35448
> >=20
> > Kernel 2.6.22-4, powerpc, targeting an MPC 8347.
>=20
> From a brief glance at the code, looks like led_trigger_store is
> holding a rwlock while calling led_trigger_set.
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
>=20
^ permalink raw reply
* Re: [PATCH] ehea: Add kdump support
From: Michael Neuling @ 2007-11-27 0:35 UTC (permalink / raw)
To: Christoph Raisch
Cc: Jeff Garzik, Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Paul Mackerras, Marcus Eder, tklein, Stefan Roscher
In-Reply-To: <OF94123F44.9DB75CE9-ONC125739F.00398E63-C125739F.003B2AFE@de.ibm.com>
In message <OF94123F44.9DB75CE9-ONC125739F.00398E63-C125739F.003B2AFE@de.ibm.com> you wrote:
> Michael Ellerman wrote on 26.11.2007 09:16:28:
> > Solutions that might be better:
> >
> > a) if there are a finite number of handles and we can predict their
> > values, just delete them all in the kdump kernel before the driver
> > loads.
>
> Guessing the values does not work, because of the handle structure
> defined by the hypervisor.
>
> > b) if there are a small & finite number of handles, save their values
> > in a device tree property and have the kdump kernel read them and
> > delete them before the driver loads.
>
> 5*16*nr_ports+1+1= >82. a ML16 has 4 adapters with up to 16 ports, so the
> number is not small anymore....
I assume this machine with a huge number of adapters has a huge amount
of memory too! :-)
> The device tree functions are currently not exported.
We can add this.
> If you crashdump to a new kernel, will it get the device tree
> representation of the crashed kernel or of the initial one of open
> firmware?
The kexec tools userspace control this. Normally it just takes the
current device tree plus some modifications (eg. initrd location
changes).
So provided the ehea driver export this info somewhere, it can be
grabbed by the kexec tools and stuffed in the device tree of the new
kernel.
That being said, the proper place to have this would be original device
tree.
>
> > c) if neither of those work, provide a minimal routine that _only_
> > deletes the handles in the crashed kernel.
>
> I would hope this has the highest chance to actually work.
> For this we would have to add a proper notifier chain.
> Do you agree?
>
> > d) <something else>
>
> Firmware change? But that's not something you will get very soon.
>
> Christoph R.
>
^ permalink raw reply
* Re: [patch 2/9] ps3: Use symbolic names for video modes
From: Stephen Rothwell @ 2007-11-27 0:05 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux/PPC Development, Linux Frame Buffer Device Development
In-Reply-To: <20071126172712.128301000@pademelon.sonytel.be>
[-- Attachment #1: Type: text/plain, Size: 1819 bytes --]
On Mon, 26 Nov 2007 18:24:57 +0100 Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
>
> @@ -594,20 +594,21 @@ static const struct {
> unsigned mask : 19;
> unsigned id : 4;
> } ps3av_preferred_modes[] = {
> - { .mask = PS3AV_RESBIT_WUXGA << SHIFT_VESA, .id = 13 },
> - { .mask = PS3AV_RESBIT_1920x1080P << SHIFT_60, .id = 5 },
> - { .mask = PS3AV_RESBIT_1920x1080P << SHIFT_50, .id = 10 },
> - { .mask = PS3AV_RESBIT_1920x1080I << SHIFT_60, .id = 4 },
> - { .mask = PS3AV_RESBIT_1920x1080I << SHIFT_50, .id = 9 },
> - { .mask = PS3AV_RESBIT_SXGA << SHIFT_VESA, .id = 12 },
> - { .mask = PS3AV_RESBIT_WXGA << SHIFT_VESA, .id = 11 },
> - { .mask = PS3AV_RESBIT_1280x720P << SHIFT_60, .id = 3 },
> - { .mask = PS3AV_RESBIT_1280x720P << SHIFT_50, .id = 8 },
> - { .mask = PS3AV_RESBIT_720x480P << SHIFT_60, .id = 2 },
> - { .mask = PS3AV_RESBIT_720x576P << SHIFT_50, .id = 7 },
> + { PS3AV_RESBIT_WUXGA << SHIFT_VESA, PS3AV_MODE_WUXGA },
> + { PS3AV_RESBIT_1920x1080P << SHIFT_60, PS3AV_MODE_1080P60 },
> + { PS3AV_RESBIT_1920x1080P << SHIFT_50, PS3AV_MODE_1080P50 },
> + { PS3AV_RESBIT_1920x1080I << SHIFT_60, PS3AV_MODE_1080I60 },
> + { PS3AV_RESBIT_1920x1080I << SHIFT_50, PS3AV_MODE_1080I50 },
> + { PS3AV_RESBIT_SXGA << SHIFT_VESA, PS3AV_MODE_SXGA },
> + { PS3AV_RESBIT_WXGA << SHIFT_VESA, PS3AV_MODE_WXGA },
> + { PS3AV_RESBIT_1280x720P << SHIFT_60, PS3AV_MODE_720P60 },
> + { PS3AV_RESBIT_1280x720P << SHIFT_50, PS3AV_MODE_720P50 },
> + { PS3AV_RESBIT_720x480P << SHIFT_60, PS3AV_MODE_480P },
> + { PS3AV_RESBIT_720x576P << SHIFT_50, PS3AV_MODE_576P },
Why did you remove the C99 style initialisers?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] [PPC 44x] enable L2-cache for ALPR, Katmai, Ocotea, and Taishan
From: Benjamin Herrenschmidt @ 2007-11-26 23:41 UTC (permalink / raw)
To: Yuri Tikhonov; +Cc: linuxppc-dev, sr, dzu
In-Reply-To: <1416528026.20071107014041@emcraft.com>
BTW... Do you know why we can't just enable HW snoop ? The 440SPe
documentation seems to indicate that this is supported by the L2 cache
via snooping on the PLB.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] e1000: Fix for 32 bits platforms with 64 bits resources
From: Kok, Auke @ 2007-11-26 23:15 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linuxppc-dev, auke-jan.h.kok, netdev
In-Reply-To: <474791D3.1090607@pobox.com>
Jeff Garzik wrote:
> Benjamin Herrenschmidt wrote:
>> The e1000 driver stores the content of the PCI resources into
>> unsigned long's before ioremapping. This breaks on 32 bits
>> platforms that support 64 bits MMIO resources such as ppc 44x.
>>
>> This fixes it by removing those temporary variables and passing
>> directly the result of pci_resource_start/len to ioremap.
>>
>> The side effect is that I removed the assignments to the netdev
>> fields mem_start, mem_end and base_addr, which are totally useless
>> for PCI devices.
>>
>> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> --
>>
>> drivers/net/e1000/e1000_main.c | 18 +++++-------------
>> 1 file changed, 5 insertions(+), 13 deletions(-)
>
> Looks good to me. auke?
yes, please apply.
Acked-by: Auke Kok <auke-jan.h.kok@intel.com>
Auke
^ permalink raw reply
* Re: LED heartbeat trigger - in_atomic() while allocs
From: Nathan Lynch @ 2007-11-26 20:36 UTC (permalink / raw)
To: Benedict, Michael; +Cc: linuxppc-embedded
In-Reply-To: <BAF8B1E0BB28024A90895E746A3B610D1C2DA2@twx-exch01.twacs.local>
Benedict, Michael wrote:
> I was playing around with the LED heartbeat trigger and it caught the
> BUG() code when trying to activate. Does anyone know why this call
> stack would be in_atomic()? Or any ideas for a patch that would allow
> the heartbeat trigger to allocate when it is not in atomic context?
>
> BUG: sleeping function called from invalid context at mm/slab.c:3024
> in_atomic():1, irqs_disabled():0
> Call Trace:
> [def3dd90] [c0008e60] show_stack+0x48/0x194 (unreliable)
> [def3ddc0] [c0014160] __might_sleep+0xd0/0xdc
> [def3dde0] [c0063e60] kmem_cache_zalloc+0xdc/0x12c
> [def3de00] [c01975c0] heartbeat_trig_activate+0x24/0x80
> [def3de20] [c0196844] led_trigger_set+0x128/0x160
> [def3de40] [c0196988] led_trigger_store+0x10c/0x1a8
> [def3deb0] [c0162f40] class_device_attr_store+0x44/0x5c
> [def3dec0] [c00ae614] sysfs_write_file+0x114/0x1dc
> [def3def0] [c0068ea4] vfs_write+0x9c/0x110
> [def3df10] [c0068ff4] sys_write+0x4c/0x90
> [def3df40] [c000fc00] ret_from_syscall+0x0/0x38
> --- Exception: c01 at 0xfe83818
> LR = 0xfe35448
>
> Kernel 2.6.22-4, powerpc, targeting an MPC 8347.
>From a brief glance at the code, looks like led_trigger_store is
holding a rwlock while calling led_trigger_set.
^ permalink raw reply
* Re: 2.6.24-rc3: High CPU load -- hardware interrupts
From: Elimar Riesebieter @ 2007-11-26 22:38 UTC (permalink / raw)
To: linuxppc-dev; +Cc: joerg
In-Reply-To: <slrnfk1d21.229.joerg@alea.gnuu.de>
[-- Attachment #1: Type: text/plain, Size: 184 bytes --]
Hi,
I can confirm this situation. But it seems, that no one takes care
of it ....
Elimar
--
Excellent day for drinking heavily.
Spike the office water cooler;-)
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Sequoia EMAC only works if u-boot initializes it?
From: Benjamin Herrenschmidt @ 2007-11-26 22:49 UTC (permalink / raw)
To: Steven A. Falco; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <474B4CA9.3070506@harris.com>
On Mon, 2007-11-26 at 17:46 -0500, Steven A. Falco wrote:
> With the following 15 patches on top of the DENX git tree, I have both emac ports working:
.../...
Good. All of these should go in 2.6.25 (not .24 at this stage though).
I suppose DENX will pick them up asap.
Cheers,
Ben.
^ permalink raw reply
* Re: Sequoia EMAC only works if u-boot initializes it?
From: Steven A. Falco @ 2007-11-26 22:46 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <1196107715.7195.107.camel@pasglop>
With the following 15 patches on top of the DENX git tree, I have both emac ports working:
1) [PATCH 2/2] PowerPC: Fix Sequoia MAL0 and EMAC dts entries.
2) [PATCH] PowerPC: Add RGMII support for Sequoia 440EPx
3) [PATCH] Fix typo in new EMAC driver.
4) PowerPC: Enable NEW EMAC support for Sequoia 440EPx.
5) [PATCH 1/8] ibm_newemac: Fix possible lockup on close
6) [PATCH 2/8] ibm_newemac: Add BCM5248 and Marvell 88E1111 PHY support
7) [PATCH 3/8] ibm_newemac: Add ET1011c PHY support
8) [PATCH 4/8] ibm_newemac: Fix ZMII refcounting bug
9) [PATCH 5/8] ibm_newemac: Workaround reset timeout when no link
10) [PATCH 6/8] ibm_newemac: Cleanup/Fix RGMII MDIO support detection
11) [PATCH 7/8] ibm_newemac: Cleanup/fix support for STACR register variants
12) [PATCH 8/8] ibm_newemac: Skip EMACs that are marked unused by the firmware
13) [PATCH 1/3] PowerPC: ibm_newemac correct opb_bus_freq value
14) [PATCH 2/3] PowerPC: ibm_newemac tah_ph typo fix
15) [PATCH 3/3] PowerPC: ibm_newemac call dev_set_drvdata() before tah_reset()
Steve
Benjamin Herrenschmidt wrote:
> On Mon, 2007-11-26 at 14:10 -0500, Steven A. Falco wrote:
>> I've attached a copy of my bootlog. I added in one patch to enable
>> rgmii but that didn't fix
>> it.(http://ozlabs.org/pipermail/linuxppc-dev/2007-October/043435.html)
>>
>> I am curious why the new emac driver is enabled in the DENX tree but
>> not in the upstream trees. Has DENX successfully used this driver on
>> the Sequoia board? Am I trying something that is known not to work?
>>
>> I'm interested in helping in whatever way I can. I need ARCH=powerpc
>> to use the current Xenomai patches, and I need both EMACs so I can
>> evaluate bonding (for high-availability).
>
> Have you tried adding the various patches I posted along with the
> patches Valentine posted ?
>
> I'll re-send a full serie later this week. Let us know if those help or
> if something is still broken.
>
> Cheers,
> Ben.
>
>
>
^ permalink raw reply
* PPC upstream kernel ignored DABR bug
From: Jan Kratochvil @ 2007-11-26 22:02 UTC (permalink / raw)
To: Paul Mackerras, linuxppc-dev; +Cc: Roland McGrath
Hi,
this testcase:
http://people.redhat.com/jkratoch/dabr-lost.c
reproduces a PPC DABR kernel bug. The variable `variable' should not get
modified as the thread modifying it should be caught by its DABR:
$ ./dabr-lost
TID 30914: DABR 0x10012a77 NIP 0x80f6ebb318
TID 30915: DABR 0x10012a77 NIP 0x80f6ebb318
TID 30916: DABR 0x10012a77 NIP 0x80f6ebb318
TID 30914: hitting the variable
TID 30915: hitting the variable
TID 30916: hitting the variable
variable found = 30916, caught TID = 30914
TID 30916: DABR 0x10012a77
Variable got modified by a thread which has DABR still set!
At the `variable found =' line the parent ptracer found the TID thread 30916
wrote the value into the variable - despite it had DABR alrady set before.
As the behavior is dependent on the current weather I expect the scheduling
matters there.
It is important the target thread is in the `nanosleep' syscall. If you define
WORKAROUND_SET_DABR_IN_SYSCALL in the testcase it busyloops in the userland and
the bug gets no longer reproduced.
I got it reproduced on a utrace-patched kernel on dual-CPU Power5 and Roland
McGrath reported it reproduced on the vanilla upstream kernel on a Mac G5.
Regards,
Jan Kratochvil
^ permalink raw reply
* Re: mmap on PPC removes file refcount?
From: Benjamin Herrenschmidt @ 2007-11-26 22:38 UTC (permalink / raw)
To: Dave Jiang; +Cc: linuxppc-dev
In-Reply-To: <474B4923.905@mvista.com>
On Mon, 2007-11-26 at 15:30 -0700, Dave Jiang wrote:
> NM, it was a bad test causing weird behavior on PPC. :(
Ah good, because I did spend some time looking at the code and didn't
see anything wrong :-)
Cheers,
Ben.
^ permalink raw reply
* Re: dtc: RFC: Fix some lexical problems with references
From: Jon Loeliger @ 2007-11-26 22:38 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071122061007.GA22888@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> The recent change to the lexer to only recognize property and node
> names in the appropriate context removed a number of lexical warts in
> our language that would have gotten ugly as we add expression support
> and so forth.
>
> But there's one nasty one remaining: references can contain a full
> path, including the various problematic node name characters (',', '+'
> and '-', for example). This would cause trouble with expressions, and
> it also causes trouble with the patch I'm working on to allow
> expanding references to paths rather than phandles. This patch
> therefore reworks the lexer to mitigate these problems.
>
> - References to labels cause no problems. These are now
> recognized separately from references to full paths. No syntax change
> here.
>
> - References to full paths, including problematic characters
> are allowed by "quoting" the path with braces
> e.g. &{/pci@10000/somedevice@3,8000}. The braces protect any internal
> problematic characters from being confused with operators or whatever.
>
> - For compatibility with existing dts files, in v0 dts files
> we allow bare references to paths as before &/foo/bar/whatever - but
> *only* if the path contains no troublesome characters. Specifically
> only [a-zA-Z0-9_@/] are allowed.
>
> This is an incompatible change to the dts-v1 format, but since AFAIK
> no-one has yet switched to dts-v1 files, I think we can get away with
> it. Better to make the transition when people to convert to v1, and
> get rid of the problematic old syntax.
>
> Strictly speaking, it's also an incompatible change to the v0 format,
> since some path references that were allowed before are no longer
> allowed. I suspect no-one has been using the no-longer-supported
> forms (certainly none of the kernel dts files will cause trouble). We
> might need to think about this harder, though.
This all sounds fine by me. We should take the incompatibility hit
once here and now; it shouldn't be a problem to eek in some more still.
Thanks,
jdl
^ permalink raw reply
* Re: mmap on PPC removes file refcount?
From: Dave Jiang @ 2007-11-26 22:30 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <47435338.2050107@mvista.com>
NM, it was a bad test causing weird behavior on PPC. :(
Dave Jiang wrote:
> It seems the mmap() userland call on PPC causes the kernel to lose the ref
> count for the mount point. This is what I did on a prpmc2800 board (74xx) with
> latest powerpc.git tree (but also seem to happen on 8548 as well).
>
> I mounted an IDE partition. The userland test app opens a file on the mounted
> partition and sits in a sleep loop while holding the file open. I call umount
> on the partition and I get "device is busy" which is suppose to happen.
> However, after the test app calls mmap on the file id for the opened file, I
> can successfully umount even though it should still say "device is busy". This
> does not happen on x86 so I'm assuming something is going on with just PPC.
>
> So using lsof I can list the opened files on a particular partition. When the
> file is opened, it lists 1 entry. When mmaped, on x86 it would list 2 entries,
> but on ppc it lists nothing. Not only did the mmaped entry not show up, the
> entry caused by open disappeared as well. Also, I put a printk in do_umount()
> to see what the refcount is. On x86, it would be 3 and thus causes device busy.
> On PPC it is 3 when the file is openend, however if mmap is called, the
> refcount becomes 2 and thus umount proceeds. It's almost as if the mmap call
> wiped out the opened file entry and decremented the mount count as well.
>
>
--
------------------------------------------------------
Dave Jiang
Software Engineer
MontaVista Software, Inc.
http://www.mvista.com
------------------------------------------------------
^ permalink raw reply
* RE: Xilinx devicetrees
From: Koss, Mike (Mission Systems) @ 2007-11-26 22:19 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: Stephen Neuendorffer, linuxppc-embedded
In-Reply-To: <474B37C9.8020405@dlasystems.com>
=20
>> I don't know if packaging the device tree with the bitstream is the=20
>> best way to go. It's possible that it could lead to headaches for=20
>> certain systems that have security restrictions.
> Make it an option. Where are the systems with security restrictions
going to get their hardware information ?
> Besides - though I am not aware off the top of my head of a
bitstream decompliler, still if you have access to the bitstream you
have access to
> the information about the device. We deal with alot of high security
applications. Security restrictions have to make sense.
> blocking devicetrees for security reasons is like telling somebody
they can have the manual in computer readable form, but not on paper.
> Further if you are going to boot an OS that requires devicetrees
then the devicetree must be somewhere - whether it is appended to the
bitstream,
> appended to the kernel, compiled into the kernel, in a separate file,
it still has to be present.
The devicetree itself is not the security concern, but the retrieval of
it from the bitstream. If it is stored in the FPGA, it may be that
accessing that stored information may not be probable at run-time.
>> The worst that one can say is:
>> SN> 1) I need several KB additional non volatile storage. Given the
>> size of the FPGA bitstream, this can't be a huge constraint.
>> =20
> Several KB is NOT happening. The bitstream is in flash. Flash is
not a limited reasorce for us.
> FPGA cells, and BRAM are precious as gold. The more we use the
less our clients have.
Which is why I'm proposing that it be an "extra" file that can be stored
however. For one system, it could be stored in the FPGA using BRAM and
it could be automatically available to kernel. For another system, it
could be stored in FLASH and the bootloader may have to copy the data
from FLASH to RAM.
>> I do agree that using more FPGA resources is not a solution to the=20
>> problem. I'm already hitting 80% usage on a FX60 and trying to
squeeze=20
>> more real estate for storage of the device tree seems silly.=20
>> Especially since that would require that every image have this extra=20
>> hardware built into it just to support booting a Linux kernel. Why=20
>> should I have to have different hardware to boot linux, versus=20
>> non-kernel, xilkernel, or other (GHS, LynxOS, etc..)?
>> =20
> One of the problems is that neither devicetrees, nor any of the
ways of tracking them are one size fits all solutions.
> I do GHS work, it would be nice if GHS supported devicetrees and
maybe it will.
> bound to the kernel, in a separate file, appended to the bitstream
and in the FPGA fabric all have pluses and minuses.
> One reason I am harping on version registers is they are extremely
cost cheap, can easily be made optional, and can be fairly easily
incorporated > into any OS (or no OS - we do that too). They are not a
replacement for devicetrees. But they still have very important uses in
many environments.
>
>> SN> Certainly.. But in a sense, these are all intermediate files on=20
>> SN> the
>> path to the image on the board.
> Unless we are going to teach linux to read and interpret .bit files
while loading, then devicetrees are intermediate in an entirely
different
> sense.
> The hardware works fine regardless of whether their is a
devicetree.
> But Linux may not boot.
You are correct, but I think a single self-contained file that has all
of the hardware descriptions is much preferred to many header files, and
#ifdef macro's to make sense of what is actually available at run-time.
> My objective is to get alot of software - linux, GHS, and
standalone apps, to all load - from a single executables, accross
multiple different
> bit images on several different (though deliberately
> similar) products. My Linux kernel needs to work regardless of the
Pico card and regardless of the bit image, as done my GHS kernel, and
....
> And I need to do that in a severly resource constrained environment.
> I would hope that should make sense of my harping about
version/capabilities registers. If I have maybe 10 possible peices of IP
that may/maynot
> be present in a given FPGA and I am trying to dynamically configure -
Linux/GHS/... to adapt to whatever it encounters and work as long as it
is a
> viable combination. At best devicetrees are an extremly complex way of
solving that - while version registers are a trivial way.
> As an example I know that if I have a UartLite, Keyhole, TEMAC,
PIC, ... they will always be at specific addresses. We never move them.
> But I do not know for sure it they are present. A version register
provides a fairly safe very efficient means of checking that a device is
> present (and establishing its version and maybe capabilites) - device
trees might do the same thing but have alot higher overhead to do so.
For your system, yes, you never move the location of the devices. But
for others, we may add other pieces or multiple pieces and require them
in multiple/different places. That's the beauty of the device tree. You
*can* create that one monolithic kernel that has support for ANY type of
hardware, and at boot-time a device tree is provided to the kernel that
defines all of the devices that are physically available in your FPGA.
I'm not trying to argue for/against the version registers. Just that a
version register is short-sighted with regards to the larger FPGA-based
view. Version registers work wonderfully when everything is staticly
located, like in your image builds or a SoC like 440GX. For general
usage for others creating their own FPGA images with varying hardware
setups, statically defined location version register checking is not
feasible.
The device tree approach can "easily" be adapted to other systems, such
as GHS, through adaptors in your corresponding BSP.
-- Mike
^ permalink raw reply
* [PATCH 3/3][RESEND] ucc_geth: handle passing of RX-only and TX-only internal delay PHY connection type parameters
From: Kim Phillips @ 2007-11-26 22:17 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, Li Yang, linuxppc-dev
Extend the RGMII-Internal Delay specification case to include
TX-only and RX-only variants.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Tested-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: Li Yang <leoli@freescale.com>
---
drivers/net/ucc_geth.c | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index a3ff270..7f68990 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -1460,6 +1460,8 @@ static int adjust_enet_interface(struct ucc_geth_private *ugeth)
if ((ugeth->phy_interface == PHY_INTERFACE_MODE_RMII) ||
(ugeth->phy_interface == PHY_INTERFACE_MODE_RGMII) ||
(ugeth->phy_interface == PHY_INTERFACE_MODE_RGMII_ID) ||
+ (ugeth->phy_interface == PHY_INTERFACE_MODE_RGMII_RXID) ||
+ (ugeth->phy_interface == PHY_INTERFACE_MODE_RGMII_TXID) ||
(ugeth->phy_interface == PHY_INTERFACE_MODE_RTBI)) {
upsmr |= UPSMR_RPM;
switch (ugeth->max_speed) {
@@ -1557,6 +1559,8 @@ static void adjust_link(struct net_device *dev)
if ((ugeth->phy_interface == PHY_INTERFACE_MODE_RMII) ||
(ugeth->phy_interface == PHY_INTERFACE_MODE_RGMII) ||
(ugeth->phy_interface == PHY_INTERFACE_MODE_RGMII_ID) ||
+ (ugeth->phy_interface == PHY_INTERFACE_MODE_RGMII_RXID) ||
+ (ugeth->phy_interface == PHY_INTERFACE_MODE_RGMII_TXID) ||
(ugeth->phy_interface == PHY_INTERFACE_MODE_RTBI)) {
if (phydev->speed == SPEED_10)
upsmr |= UPSMR_R10M;
@@ -3795,6 +3799,10 @@ static phy_interface_t to_phy_interface(const char *phy_connection_type)
return PHY_INTERFACE_MODE_RGMII;
if (strcasecmp(phy_connection_type, "rgmii-id") == 0)
return PHY_INTERFACE_MODE_RGMII_ID;
+ if (strcasecmp(phy_connection_type, "rgmii-txid") == 0)
+ return PHY_INTERFACE_MODE_RGMII_TXID;
+ if (strcasecmp(phy_connection_type, "rgmii-rxid") == 0)
+ return PHY_INTERFACE_MODE_RGMII_RXID;
if (strcasecmp(phy_connection_type, "rtbi") == 0)
return PHY_INTERFACE_MODE_RTBI;
@@ -3889,6 +3897,8 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
case PHY_INTERFACE_MODE_GMII:
case PHY_INTERFACE_MODE_RGMII:
case PHY_INTERFACE_MODE_RGMII_ID:
+ case PHY_INTERFACE_MODE_RGMII_RXID:
+ case PHY_INTERFACE_MODE_RGMII_TXID:
case PHY_INTERFACE_MODE_TBI:
case PHY_INTERFACE_MODE_RTBI:
max_speed = SPEED_1000;
--
1.5.2.2
^ permalink raw reply related
* [PATCH 2/3][RESEND] phylib: marvell: add support for TX-only and RX-only Internal Delay
From: Kim Phillips @ 2007-11-26 22:17 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, Li Yang, linuxppc-dev
Previously, Internal Delay specification implied the delay be
applied to both TX and RX. This patch allows for separate TX/RX-only
internal delay specification.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Tested-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: Li Yang <leoli@freescale.com>
---
drivers/net/phy/marvell.c | 26 +++++++++++++++++---------
1 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 035fd41..f057407 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -143,21 +143,29 @@ static int m88e1111_config_init(struct phy_device *phydev)
int err;
if ((phydev->interface == PHY_INTERFACE_MODE_RGMII) ||
- (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID)) {
+ (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) ||
+ (phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID) ||
+ (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID)) {
int temp;
- if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) {
- temp = phy_read(phydev, MII_M1111_PHY_EXT_CR);
- if (temp < 0)
- return temp;
+ temp = phy_read(phydev, MII_M1111_PHY_EXT_CR);
+ if (temp < 0)
+ return temp;
+ if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) {
temp |= (MII_M1111_RX_DELAY | MII_M1111_TX_DELAY);
-
- err = phy_write(phydev, MII_M1111_PHY_EXT_CR, temp);
- if (err < 0)
- return err;
+ } else if (phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID) {
+ temp &= ~MII_M1111_TX_DELAY;
+ temp |= MII_M1111_RX_DELAY;
+ } else if (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID) {
+ temp &= ~MII_M1111_RX_DELAY;
+ temp |= MII_M1111_TX_DELAY;
}
+ err = phy_write(phydev, MII_M1111_PHY_EXT_CR, temp);
+ if (err < 0)
+ return err;
+
temp = phy_read(phydev, MII_M1111_PHY_EXT_SR);
if (temp < 0)
return temp;
--
1.5.2.2
^ permalink raw reply related
* [PATCH 1/3][RESEND] phylib: add PHY interface modes for internal delay for tx and rx only
From: Kim Phillips @ 2007-11-26 22:17 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, Li Yang, linuxppc-dev
Allow phylib specification of cases where hardware needs to configure
PHYs for Internal Delay only on either RX or TX (not both).
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Tested-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: Li Yang <leoli@freescale.com>
---
include/linux/phy.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/linux/phy.h b/include/linux/phy.h
index f0742b6..e10763d 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -58,6 +58,8 @@ typedef enum {
PHY_INTERFACE_MODE_RMII,
PHY_INTERFACE_MODE_RGMII,
PHY_INTERFACE_MODE_RGMII_ID,
+ PHY_INTERFACE_MODE_RGMII_RXID,
+ PHY_INTERFACE_MODE_RGMII_TXID,
PHY_INTERFACE_MODE_RTBI
} phy_interface_t;
--
1.5.2.2
^ permalink raw reply related
* [PATCH 0/3][RESEND] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
From: Kim Phillips @ 2007-11-26 22:17 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, Li Yang, linuxppc-dev
these 3 patches are a resend of patches 2-4 (out of 5) that were
originally sent 2007-11-05* (patches 1 and 5 were picked up by Kumar
to go through powerpc).
Jeff, Leo has acked these, please consider for 2.6.24.
Thanks,
Kim
* http://marc.info/?l=linux-netdev&m=119428688804765&w=1
^ permalink raw reply
* Re: dtc: Flexible tree checking infrastructure (v2)
From: Jon Loeliger @ 2007-11-26 22:13 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071122033807.GH19445@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> dtc: Flexible tree checking infrastructure
>
> Here, at last, is a substantial start on revising dtc's infrastructure
> for checking the tree; this is the rework I've been saying was
> necessary practically since dtc was first release.
>
> In the new model, we have a table of "check" structures, each with a
> name, references to checking functions, and status variables. Each
> check can (in principle) be individually switched off or on (as either
> a warning or error). Checks have a list of prerequisites, so if
> checks need to rely on results from earlier checks to make sense (or
> even to avoid crashing) they just need to list the relevant other
> checks there.
>
> For now, only the "structural" checks and the fixups for phandle
> references are converted to the new mechanism. The rather more
> involved semantic checks (which is where this new mechanism will
> really be useful) will have to be converted in future patches.
>
> At present, there's no user interface for turning on/off the checks -
> the -f option now forces output even if "error" level checks fail.
> Again, future patches will be needed to add the fine-grained control,
> but that should be quite straightforward with the infrastructure
> implemented here.
>
> Also adds a testcase for the handling of bad references, which catches
> a bug encountered while developing this patch.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
While I've Applied this one, it has introduced this:
CC dtc.o
dtc.c: In function 'main':
dtc.c:199: warning: 'structure_ok' is used uninitialized in this function
Followup easy patch?
Thanks,
jdl
^ permalink raw reply
* Re: dtc: Merge refs and labels into single "markers" list
From: Jon Loeliger @ 2007-11-26 22:11 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071122003707.GF19445@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> Currently, every 'data' object, used to represent property values, has
> two lists of fixup structures - one for labels and one for references.
> Sometimes we want to look at them separately, but other times we need
> to consider both types of fixup.
>
> I'm planning to implement string references, where a full path rather
> than a phandle is substituted into a property value. Adding yet
> another list of fixups for that would start to get messy. So, this
> patch merges the "refs" and "labels" lists into a single list of
> "markers", each of which has a type field indicating if it represents
> a label or a phandle reference. String references or any other new
> type of in-data marker will then just need a new type value - merging
> data blocks and other common manipulations will just work.
>
> While I was at it I made some cleanups to the handling of fixups which
> simplify things further.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
Thanks,
jdl
^ permalink raw reply
* Re: dtc: Add valgrind support to testsuite
From: Jon Loeliger @ 2007-11-26 22:10 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071121005614.GD13156@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> This patch adds some options to the run_tests.sh script allowing it to
> run all the testcases under valgrind to check for pointer corruption
> bugs and memory leaks. Invoking "make checkm" will run the testsuite
> with valgrind.
>
> It include a mechanism for specifying valgrind errors to be suppressed
> on a per-testcase basis, and adds a couple of such suppression files
> for the mangle-layout and open_pack testcases which dump for use by
> other testcases a buffer which may contain uninitialized sections. We
> use suppressions rather than initializing the buffer so that valgrind
> will catch any internal access s to the uninitialized data, which
> would be a bug.
>
> The patch also fixes one genuine bug caught by valgrind -
> _packblocks() in fdt_rw.c was using memcpy() where it should have been
> using memmove().
>
> At present the valgrinding won't do anything useful for testcases
> invoked via a shell script - which includes all the dtc testcases. I
> plan to fix that later.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
Thanks,
jdl
PS -- Clearly, I'm going to have to break down and install valgrind now. :-)
^ permalink raw reply
* Please pull powerpc.git merge branch
From: Paul Mackerras @ 2007-11-26 22:09 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get another batch of fixes for powerpc, as listed below. Since the
pull request I sent last week while you were away, I have added four
more commits from Kumar.
Thanks,
Paul.
Documentation/powerpc/booting-without-of.txt | 5 +
arch/powerpc/boot/dts/mpc832x_mds.dts | 16 ++-
arch/powerpc/boot/dts/mpc834x_mds.dts | 9 ++
arch/powerpc/boot/dts/mpc836x_mds.dts | 9 ++
arch/powerpc/boot/dts/mpc8544ds.dts | 20 ++--
arch/powerpc/boot/dts/mpc8572ds.dts | 108 ++++++++++++++++++---
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 126 ++++++++++++++++++++----
arch/powerpc/configs/mpc832x_mds_defconfig | 48 +++++++++
arch/powerpc/configs/mpc832x_rdb_defconfig | 41 +++++++-
arch/powerpc/configs/mpc834x_itx_defconfig | 2
arch/powerpc/configs/mpc834x_itxgp_defconfig | 88 +++++++++++++++++
arch/powerpc/configs/mpc834x_mds_defconfig | 48 +++++++++
arch/powerpc/configs/mpc836x_mds_defconfig | 48 +++++++++
arch/powerpc/configs/mpc8568mds_defconfig | 48 +++++++++
arch/powerpc/kernel/asm-offsets.c | 4 +
arch/powerpc/kernel/rtas.c | 111 ++++++++++++---------
arch/powerpc/kernel/time.c | 5 +
arch/powerpc/kernel/vdso.c | 11 ++
arch/powerpc/kernel/vdso32/cacheflush.S | 41 ++++++--
arch/powerpc/kernel/vdso64/cacheflush.S | 41 ++++++--
arch/powerpc/mm/mem.c | 2
arch/powerpc/mm/mmu_decl.h | 2
arch/powerpc/mm/stab.c | 1
arch/powerpc/platforms/40x/walnut.c | 3 -
arch/powerpc/platforms/44x/bamboo.c | 3 -
arch/powerpc/platforms/44x/ebony.c | 3 -
arch/powerpc/platforms/44x/sequoia.c | 3 -
arch/powerpc/platforms/83xx/mpc832x_mds.c | 31 +-----
arch/powerpc/platforms/83xx/mpc832x_rdb.c | 14 ++-
arch/powerpc/platforms/83xx/mpc834x_mds.c | 24 -----
arch/powerpc/platforms/83xx/mpc836x_mds.c | 55 +++++-----
arch/powerpc/platforms/83xx/usb.c | 8 +-
arch/powerpc/platforms/cell/spufs/inode.c | 1
arch/powerpc/platforms/embedded6xx/prpmc2800.c | 1
arch/powerpc/platforms/pasemi/setup.c | 2
arch/powerpc/platforms/pseries/Kconfig | 2
arch/powerpc/platforms/pseries/setup.c | 3 -
arch/powerpc/sysdev/uic.c | 18 +++
arch/ppc/kernel/setup.c | 7 +
arch/ppc/mm/init.c | 2
arch/ppc/mm/mmu_decl.h | 2
arch/ppc/platforms/4xx/yucca.c | 1
arch/ppc/syslib/virtex_devices.c | 31 ++++++
include/asm-powerpc/page_32.h | 4 +
include/asm-powerpc/pci-bridge.h | 5 +
include/asm-powerpc/rtas.h | 3 -
include/asm-powerpc/vdso_datapage.h | 8 ++
47 files changed, 832 insertions(+), 236 deletions(-)
Anton Vorontsov (2):
[POWERPC] 83xx: MPC832x RDB - remove spidev stub, use mmc_spi
[POWERPC] 83xx: Update mpc832x_rdb_defconfig to enable MMC-over-SPI
Benjamin Herrenschmidt (3):
[POWERPC] Fix declaration of pcibios_free_controller
[POWERPC] Fix kmalloc alignment on non-coherent DMA platforms
[POWERPC] Fix 8xx build breakage due to _tlbie changes
Cyrill Gorcunov (1):
[POWERPC] Fix potential NULL dereference
Grant Likely (1):
[POWERPC] 83xx: Update mpc8349emitx(gp) defconfig for USB
Jeremy Kerr (1):
[POWERPC] spufs: Fix context destroy vs /spu readdir race
Joachim Foerster (1):
[POWERPC] Xilinx: Register AC97 Controller Reference with the platform bus
Jon Loeliger (1):
[POWERPC] 4xx: Replace #includes of asm/of_platform.h with linux/of_platform.h.
Josh Boyer (1):
[POWERPC] 4xx: Use virtual PVR value to init FPU on arch/ppc 440EP
Kamalesh Babulal (1):
[POWERPC] Fix build failure on legacy iSeries
Kim Phillips (5):
[POWERPC] 83xx: mpc832x mds: Fix board PHY reset code
[POWERPC] 83xx: Fix 2nd UCC entry in mpc832x_mds.dts
[POWERPC] Document rgmii-rxid and rgmii-txid phy-connection-types
[POWERPC] 83xx: Handle mpc8360 rev. 2.1 RGMII timing erratum
[POWERPC] 8xxx: MDS board RTC fixes
Kumar Gala (1):
[POWERPC] Fix device tree interrupt map for Freescale ULI1575 boards
Linas Vepstas (1):
[POWERPC] Fix RTAS os-term usage on kernel panic
Mark A. Greer (1):
[POWERPC] prpmc2800: Enable L2 cache
Michael Neuling (1):
[POWERPC] Fix possible division by zero in scaled time accounting
Nathan Lynch (1):
[POWERPC] Fix multiple bugs in rtas_ibm_suspend_me code
Olof Johansson (2):
[POWERPC] pasemi: Don't reset mpic at boot
[POWERPC] vdso: Fixes for cache block sizes
Roel Kluin (1):
[POWERPC] 4xx: balance ioremap/ioumap calls for Yucca
Stephen Rothwell (1):
[POWERPC] pSeries: make pseries_defconfig minus PCI build again
Valentine Barshak (1):
[POWERPC] 4xx: UIC add mask_ack callback
^ permalink raw reply
* Re: Xilinx devicetrees
From: Grant Likely @ 2007-11-26 22:09 UTC (permalink / raw)
To: Stephen Neuendorffer
Cc: Koss, Mike (Mission Systems), David H. Lynch Jr.,
linuxppc-embedded
In-Reply-To: <20071126215615.73F4B1138066@mail175-dub.bigfish.com>
On 11/26/07, Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> wrote:
>
>
> > -----Original Message-----
> > From: David H. Lynch Jr. [mailto:dhlii@dlasystems.com]
> > Sent: Monday, November 26, 2007 1:17 PM
> > To: Koss, Mike (Mission Systems)
> > Cc: Stephen Neuendorffer; Grant Likely; linuxppc-embedded
> > Subject: Re: Xilinx devicetrees
> >
> > My objective is to get alot of software - linux, GHS, and
> > standalone apps, to all load - from a single executables, accross
> > multiple different bit images on several different (though
> > deliberately
> > similar) products. My Linux kernel needs to work regardless
> > of the Pico
> > card and regardless of the bit image, as done my GHS kernel, and ....
> > And I need to do that in a severly resource constrained environment.
> > I would hope that should make sense of my harping about
> > version/capabilities registers. If I have maybe 10 possible
> > peices of IP
> > that may/maynot be present in a given FPGA and I am trying to
> > dynamically configure - Linux/GHS/... to adapt to whatever it
> > encounters
> > and work as long as it is a viable combination. At best
> > devicetrees are
> > an extremly complex way of solving that - while version
> > registers are a
> > trivial way.
I disagree. I'm not disputing that version registers are valuable.
But I *am* disputing their value for device detection. It may work in
your specific case of devices always in certain locations, but it does
not help the general case where devices can be instantiated anywhere
in the 4GB address space.
>
> It sounds like the real problem that you have is that even if you get
> device trees working for Linux, you still have the same problem for GHS,
> so from your perspective "device trees don't help"
In embedded power.org land, device trees are becoming the recommended
method for describing platform configuration for all embedded powerpc
software. Not just Linux. So from that perspective device trees
might help.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* RE: Xilinx devicetrees
From: Stephen Neuendorffer @ 2007-11-26 21:55 UTC (permalink / raw)
To: David H. Lynch Jr., Koss, Mike (Mission Systems); +Cc: linuxppc-embedded
In-Reply-To: <474B37C9.8020405@dlasystems.com>
=20
> -----Original Message-----
> From: David H. Lynch Jr. [mailto:dhlii@dlasystems.com]=20
> Sent: Monday, November 26, 2007 1:17 PM
> To: Koss, Mike (Mission Systems)
> Cc: Stephen Neuendorffer; Grant Likely; linuxppc-embedded
> Subject: Re: Xilinx devicetrees
>=20
> Koss, Mike (Mission Systems) wrote:
> > Time for my $.02, since I am heavily weighting my future=20
> designs on the
> > use of the device trees. :) (and b/c I don't check my work=20
> e-mail from
> > home ;P)
> >
> > ________________________________
> >
> > From: Stephen Neuendorffer [mailto:stephen.neuendorffer@xilinx.com]=20
> > Sent: Sunday, November 25, 2007 6:59 PM
> > To: David H. Lynch Jr.; Grant Likely; linuxppc-embedded
> > Subject: RE: Xilinx devicetrees
> >
> >
>=20
> >
> > SN> I don't understand the 'burden on software developers'.=20
> The code to
> > do this will just be standard code. =20
> I got 16K of RAM for my boot loader and that 16K has to=20
> do alot more
> than just manage device trees.
> I think we have 2K left. In that I have to fit scripting, and
> ethernet, so where am I supposed to fit the standard code ?
> If the devicetree is say at the end of the bit file I can probably
> copy it to ram and pass a pointer to linux in maybe a couple=20
> of hundred
> bytes.
> If I have to do much more it ain't happening.
Personally, It sounds like you're trying to do to much... The only
thing that that code really needs to do is to find the 'real' boot code:
Maybe Uboot stored in flash? :) I'm not naive enough to suggest that I
understand all the constraints of your system, but it is another
solution.
> > The worst that one can say is:
> > SN> 1) I need several KB additional non volatile storage. Given the
> > size of the FPGA bitstream, this can't be a huge constraint.
> > =20
> Several KB is NOT happening. The bitstream is in=20
> flash. Flash is
> not a limited reasorce for us.
> FPGA cells, and BRAM are precious as gold. The more we use the
> less our clients have.
Device tree should probably be stored in flash, in your case....
> >
> > SN> Certainly.. But in a sense, these are all intermediate=20
> files on the
> > path to the image on the board.
> Unless we are going to teach linux to read and interpret=20
> .bit files
> while loading, then devicetrees are intermediate in an entirely
> different sense.
> The hardware works fine regardless of whether their is a=20
> devicetree.
> But Linux may not boot.
I think this philosphy really minimized the value of software... The
hardware doesn't work unless the software that comes with it *also*
works. :)
> My objective is to get alot of software - linux, GHS, and
> standalone apps, to all load - from a single executables, accross
> multiple different bit images on several different (though=20
> deliberately
> similar) products. My Linux kernel needs to work regardless=20
> of the Pico
> card and regardless of the bit image, as done my GHS kernel, and ....
> And I need to do that in a severly resource constrained environment.
> I would hope that should make sense of my harping about
> version/capabilities registers. If I have maybe 10 possible=20
> peices of IP
> that may/maynot be present in a given FPGA and I am trying to
> dynamically configure - Linux/GHS/... to adapt to whatever it=20
> encounters
> and work as long as it is a viable combination. At best=20
> devicetrees are
> an extremly complex way of solving that - while version=20
> registers are a
> trivial way.
It sounds like the real problem that you have is that even if you get
device trees working for Linux, you still have the same problem for GHS,
so from your perspective "device trees don't help"
Steve
^ permalink raw reply
* RE: Xilinx EDK BSP generation of device trees for microblaze and PowerPC
From: Stephen Neuendorffer @ 2007-11-26 21:44 UTC (permalink / raw)
To: Grant Likely, Segher Boessenkool, David Gibson, Jon Loeliger
Cc: microblaze-uclinux, Michal Simek, git, linuxppc-dev
In-Reply-To: <fa686aa40711251447t57f96dd4iba51d68e1c9a9c5c@mail.gmail.com>
=20
I've pushed the current state up to
git://git.xilinx.com/gen-mhs-devtree.git for your perusing. Comments
below.
> -----Original Message-----
> From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On=20
> Behalf Of Grant Likely
> Sent: Sunday, November 25, 2007 2:47 PM
> To: Stephen Neuendorffer; Segher Boessenkool; David Gibson;=20
> Jon Loeliger
> Cc: microblaze-uclinux@itee.uq.edu.au;=20
> linuxppc-dev@ozlabs.org; Michal Simek; git
> Subject: Re: Xilinx EDK BSP generation of device trees for=20
> microblaze and PowerPC
>=20
> On 11/24/07, Stephen Neuendorffer=20
> <stephen.neuendorffer@xilinx.com> wrote:
> >
>=20
> Thanks for all this work; comments below.
>=20
> >
> > Here's what I've gotten so far:
> >
> > Hard_Ethernet_MAC: xps-ll-temac@81c00000 {
> > #address-cells =3D <1>;
> > #size-cells =3D <1>;
> > network@81c00000 {
> > compatible =3D=20
> "xlnx,xps-ll-temac-1.00.a",
> > "xlnx,xps-ll-temac";
>=20
> Drop "xlnx,xps-ll-temac"; it's 100% made up. This should be simply:
> compatible =3D "xlnx,xps-ll-temac-1.00.a" for version 1.00.a and
> compatible =3D
> "xlnx,xps-ll-temac-<version>","xlnx,xps-ll-temac-1.00.a" for a future
> version if it maintains register level compatibility.
>=20
> "xlnx,xps-ll-temac" is far to ambiguous.
What if it was: compatible =3D "xlnx,xps-ll-temac-1.00.a",
"xlnx,xps-ll-temac-1"?
Basically, I don't want to be responsible for declaring what versions of
IP are backward compatible with ll-temac-1.00.a, and I think it's bad
software design to put that list into the dts generator anyway. In
theory, at least, all ip with the same major version should be
compatible.
> > interrupt-parent =3D <&xps_intc_0>;
> > interrupts =3D < 3 0 >;
> > llink-connected =3D <&PIM3>;
>=20
> What's this property for?
So that the ll_temac knows whether to use dma or fifo code and where the
dma or fifo control/interrupts are.
>=20
> > reg =3D < 81c00000 40 >;
>=20
> If these registers are addressable, then the parent needs a=20
> 'ranges' property.
I thought ranges weren't necessary in a 1:1 mapping?
> > xlnx,bus2core-clk-ratio =3D <1>;
> > xlnx,phy-type =3D <1>;
> > xlnx,phyaddr =3D <1>;
> > xlnx,rxcsum =3D <0>;
> > xlnx,rxfifo =3D <1000>;
> > xlnx,temac-type =3D <0>;
> > xlnx,txcsum =3D <0>;
> > xlnx,txfifo =3D <1000>;
>=20
> Would be nice to have a 'phy-handle' property as that is what is being
> used on other platforms; but that's not something that EDK knows
> about. It would be nice to have a way to tell EDK what PHY device is
> on the board so it could generate the appropriate mdio and phy nodes.
Yeah, this is going to be a big issue, I think...
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox