* Re: [PATCH 00/10] Updated ML300 & ML403 patches @ 2006-01-27 12:01 Paula Saameño 2006-01-27 16:37 ` Grant Likely 0 siblings, 1 reply; 22+ messages in thread From: Paula Saameño @ 2006-01-27 12:01 UTC (permalink / raw) To: linuxppc-embedded [-- Attachment #1: Type: text/plain, Size: 351 bytes --] Hi! I have tested the patches on the git kernel 2.6 and the reference design for the ml403, and it boot sucessfully. Thanks for the support! Have any of you tried to mount the root fs via NFS? I haven't been able to. I think that, as long as there is no driver for the Xilinx EMAC yet, I cannot do it, can I? Thanks one more time! Paula [-- Attachment #2: Type: text/html, Size: 401 bytes --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 00/10] Updated ML300 & ML403 patches 2006-01-27 12:01 [PATCH 00/10] Updated ML300 & ML403 patches Paula Saameño @ 2006-01-27 16:37 ` Grant Likely 0 siblings, 0 replies; 22+ messages in thread From: Grant Likely @ 2006-01-27 16:37 UTC (permalink / raw) To: Paula Saameño; +Cc: linuxppc-embedded On 27-Jan-06, at 5:01 AM, Paula Saame=F1o wrote: > Hi! > > I have tested the patches on the git kernel 2.6 and the reference =20 > design for the ml403, and it boot sucessfully. Thanks for the support! > > Have any of you tried to mount the root fs via NFS? I haven't been =20 > able to. I think that, as long as there is no driver for the Xilinx =20= > EMAC yet, I cannot do it, can I? That's right. I've ported the 2.4 EMAC driver to 2.6, but I don't =20 have permission from my client to release it yet. I think MontaVista =20= is also working on an updated driver; you could ping them > > Thanks one more time! No problem. ^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 00/10] Updated ML300 & ML403 patches
@ 2006-02-09 7:57 S. Egbert
2006-02-09 14:51 ` Grant Likely
0 siblings, 1 reply; 22+ messages in thread
From: S. Egbert @ 2006-02-09 7:57 UTC (permalink / raw)
To: linuxppc-embedded
> > Really, this isn't statically defined anyway. The bootloader
> > (u-boot or zImage) passes the memory size into the kernel; and in
> > fact the kernel command line; or the board setup code can restrict
> > the amount of mem used by the kernel. XPAR_MEM_* isn't used by the
> > kernel proper at all.
> >
> > - Peter
>
> Thanks for the comments.
>
> Another issue we need to discuss is if/how to support the xilinx
> generated BSP in the kernel proper; but I'll leave that for a
> different email.
>
> If there's enough interest; I'll setup another git tree for the virtex
> specific patches.
I, for one, am interested in helping with the Virtex specific patches.
Is there a URL for this? git://?
S. Egbert
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH 00/10] Updated ML300 & ML403 patches 2006-02-09 7:57 S. Egbert @ 2006-02-09 14:51 ` Grant Likely 0 siblings, 0 replies; 22+ messages in thread From: Grant Likely @ 2006-02-09 14:51 UTC (permalink / raw) To: S. Egbert; +Cc: linuxppc-embedded On 9-Feb-06, at 12:57 AM, S. Egbert wrote: >>> Really, this isn't statically defined anyway. The bootloader >>> (u-boot or zImage) passes the memory size into the kernel; and in >>> fact the kernel command line; or the board setup code can restrict >>> the amount of mem used by the kernel. XPAR_MEM_* isn't used by the >>> kernel proper at all. >>> >>> - Peter >> >> Thanks for the comments. >> >> Another issue we need to discuss is if/how to support the xilinx >> generated BSP in the kernel proper; but I'll leave that for a >> different email. >> >> If there's enough interest; I'll setup another git tree for the >> virtex >> specific patches. > > I, for one, am interested in helping with the Virtex specific patches. > Is there a URL for this? git://? The patches have now been accepted into paul's powerpt.git tree. http://www.kernel.org/git/?p=linux/kernel/git/paulus/ powerpc.git;a=summary ^ permalink raw reply [flat|nested] 22+ messages in thread
[parent not found: <mailman.134.1137523561.17753.linuxppc-embedded@ozlabs.org>]
* Re: [PATCH 00/10] Updated ML300 & ML403 patches [not found] <mailman.134.1137523561.17753.linuxppc-embedded@ozlabs.org> @ 2006-01-17 20:12 ` T Ziomek 2006-01-17 20:19 ` Grant Likely 0 siblings, 1 reply; 22+ messages in thread From: T Ziomek @ 2006-01-17 20:12 UTC (permalink / raw) To: linuxppc-embedded; +Cc: tomz Here's another lurker poking his head up... Grant Likely wrote: > > John Bonesio wrote: > > Hello, > > > > I work in the Xilinx software group. > > > > I'm replying to this email thread because Grant suggested there be a GIT > > tree for Virtex specific changes. > > I was told today that we may be able to use Paul's linuxppc tree. I'm > going to ask him later today. Probably a newbie question...my understanding is that kernel.org is the preferred repository for PPC-specific code these days, correct? So the a- bove is referring to Xilinx-specific PPC code? From what I can see on LXR and kernel.org neither has any Xilinx-related code... > > I am wondering if the open source community would prefer or see a > > benefit to Xilinx owning/hosting the source trees (CVS or GIT or > > whatever) for our drivers, and in particular the Linux adapter drivers. > > If we did this we would provide a web site with the information along > > with instructions on how to submit changes. > > > > We are exploring this idea and wanted to know what others thought of > > this. > > Let's just keep things on the mailing list; it's the natural place to > discuss issues. If the traffic gets too high, we can do something > different. Re keeping discussion on linuxppc-embedded, sure. Re the hosting of source trees, I'd definitely like to see Xilinx take that on if the stuff dis- cussed above doesn't come to pass. We need to have a relatively stable, long-term primary source for such code. Tom Ziomek -- /"\ ASCII Ribbon Campaign | \ / | Email to user 'CTZ001' X Against HTML | at 'email.mot.com' / \ in e-mail & news | ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 00/10] Updated ML300 & ML403 patches 2006-01-17 20:12 ` T Ziomek @ 2006-01-17 20:19 ` Grant Likely 2006-01-17 20:23 ` T Ziomek 0 siblings, 1 reply; 22+ messages in thread From: Grant Likely @ 2006-01-17 20:19 UTC (permalink / raw) To: T Ziomek; +Cc: linuxppc-embedded T Ziomek wrote: > Here's another lurker poking his head up... > > Grant Likely wrote: > >>John Bonesio wrote: >> >>>Hello, >>> >>>I work in the Xilinx software group. >>> >>>I'm replying to this email thread because Grant suggested there be a GIT >>>tree for Virtex specific changes. >> >>I was told today that we may be able to use Paul's linuxppc tree. I'm >>going to ask him later today. > > > Probably a newbie question...my understanding is that kernel.org is the > preferred repository for PPC-specific code these days, correct? So the a- > bove is referring to Xilinx-specific PPC code? From what I can see on LXR > and kernel.org neither has any Xilinx-related code... mainline linux-2.6 tree has ml300 support ml300 platform bus support is pending for the powerpc.git tree ml403 support is pending for the powerpc.git tree powerpc.git is periodically pulled into linux-2.6 both are on kernel.org -- Grant Likely, B.Sc. P.Eng. Secret Lab Technologies Ltd. (403) 663-0761 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 00/10] Updated ML300 & ML403 patches 2006-01-17 20:19 ` Grant Likely @ 2006-01-17 20:23 ` T Ziomek 2006-01-17 20:37 ` Grant Likely 0 siblings, 1 reply; 22+ messages in thread From: T Ziomek @ 2006-01-17 20:23 UTC (permalink / raw) To: Grant Likely; +Cc: T Ziomek, linuxppc-embedded On Tue, 17 Jan 2006, Grant Likely wrote: > > T Ziomek wrote: >> >> Grant Likely wrote: >> >>> John Bonesio wrote: . . . >>>> I'm replying to this email thread because Grant suggested there be a GIT >>>> tree for Virtex specific changes. >>> >>> I was told today that we may be able to use Paul's linuxppc tree. I'm >>> going to ask him later today. >> >> Probably a newbie question...my understanding is that kernel.org is the >> preferred repository for PPC-specific code these days, correct? So the a- >> bove is referring to Xilinx-specific PPC code? From what I can see on LXR >> and kernel.org neither has any Xilinx-related code... > > mainline linux-2.6 tree has ml300 support > > ml300 platform bus support is pending for the powerpc.git tree > ml403 support is pending for the powerpc.git tree > > powerpc.git is periodically pulled into linux-2.6 > > both are on kernel.org Meh, okay. But then what are the "Virtex specific changes" that would need to be in Paul's linuxppc tree or anywhere but kernel.org? Thanks, Tom -- /"\ ASCII Ribbon Campaign | \ / | Email to user 'CTZ001' X Against HTML | at 'email.mot.com' / \ in e-mail & news | ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 00/10] Updated ML300 & ML403 patches 2006-01-17 20:23 ` T Ziomek @ 2006-01-17 20:37 ` Grant Likely 0 siblings, 0 replies; 22+ messages in thread From: Grant Likely @ 2006-01-17 20:37 UTC (permalink / raw) To: T Ziomek; +Cc: T Ziomek, linuxppc-embedded T Ziomek wrote: > On Tue, 17 Jan 2006, Grant Likely wrote: >> T Ziomek wrote: >>> Grant Likely wrote: >>>> John Bonesio wrote: >>>>> Grant Likely wrote: >>>>> I'm replying to this email thread because Grant suggested there be >>>>> a GIT >>>>> tree for Virtex specific changes. <--- snip ---> >> >> mainline linux-2.6 tree has ml300 support >> >> ml300 platform bus support is pending for the powerpc.git tree >> ml403 support is pending for the powerpc.git tree >> >> powerpc.git is periodically pulled into linux-2.6 >> >> both are on kernel.org > > Meh, okay. But then what are the "Virtex specific changes" that would need > to be in Paul's linuxppc tree or anywhere but kernel.org? Basically, I was thinking about a 'development sandbox' that feeds into linux-2.6.git. However, if we can use Paul's powerpc tree, then I don't need to create yet-another-git-tree g. -- Grant Likely, B.Sc. P.Eng. Secret Lab Technologies Ltd. (403) 663-0761 ^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: [PATCH 00/10] Updated ML300 & ML403 patches @ 2006-01-17 18:10 John Bonesio 2006-01-17 18:31 ` Grant Likely 0 siblings, 1 reply; 22+ messages in thread From: John Bonesio @ 2006-01-17 18:10 UTC (permalink / raw) To: linuxppc-embedded; +Cc: Grant Likely, Andrei Konovalov, rick.moleres Hello, I work in the Xilinx software group. I'm replying to this email thread because Grant suggested there be a GIT tree for Virtex specific changes. I am wondering if the open source community would prefer or see a benefit to Xilinx owning/hosting the source trees (CVS or GIT or whatever) for our drivers, and in particular the Linux adapter drivers. If we did this we would provide a web site with the information along with instructions on how to submit changes. We are exploring this idea and wanted to know what others thought of this. - John -----Original Message----- From: linuxppc-embedded-bounces@ozlabs.org [mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of Grant Likely Sent: Tuesday, January 17, 2006 8:41 AM To: peter.ryser Cc: Grant Likely; Andrei Konovalov; rick.moleres; linuxppc-embedded Subject: Re: [PATCH 00/10] Updated ML300 & ML403 patches Peter Ryser wrote: >=20 >> Hmm, did you use the ml403 and ml300 def configs? What date did you=20 >> pull Linus' tree? Kumar and Paul were talking today about some serial=20 >> subsystem breakage on the linux-2.6 tree this weekend... I'll fast=20 >> forward tonight and try it on my board.=20 >=20 >=20 > Okay, please let me know how this works for you. >=20 >> Try seeking to commit: 67daf5f11f06b9b15f8320de1d237ccc2e74fe43 >> That's what I generated the latest patches against.=20 >=20 >=20 > Hmm, I only recently switched to using git. Is this number string some > kind of a tag that I can synchronize my local git tree to? If so, how? >=20 Yea, the number is kind of like a raw tag without a name associated with it. The cg-seek command can be used to get you there. (But you also=20 need to have cogito installed) >>> Anyway, there is another issue that I would like to bring up and it=20 >>> has to do with xparameters.h. The xparameters.h file, or more=20 >>> exactly, the xparameters_* file, is automatically generated by EDK=20 >>> and is then used to configure the devices in the Linux kernel at=20 >>> compile time. While I understand the desire to get away from a static=20 >>> device definition to device enumeration at run-time, the current set >>> of patches is a step backwards for users from a useability point of=20 >>> view. Users will now have to modify xparameters*.h by hand which is=20 >>> an error-prone process.=20 >> >> >> >> Actually, users should *never* modifiy generated files. The intent is=20 >> that board specific fixups go directly into the top level=20 >> xparameters.h so that newly generated files don't have to be touched. >> But yes, I understand what you mean.=20 >=20 >=20 > An EDK user is free to choose arbitrary names for his peripherals.=20 > Additionally, Base System Builder uses different names for various=20 > boards (historically). With that it is impossible to make static=20 > assignments in xparameters.h. If you go back to the 2.4 kernel and have=20 > a look at xparameters_ml300.h you can see that the assignment of boards=20 > specific parameters to Linux specific parameters is done in there and=20 > that xparameters.h is basically used to chose the proper xparameters_* > file for a given board. okay >=20 >>> Additionally, the original 'redefines' are now replaced with=20 >>> redefines in xparameters.h but differently for every board. I suggest=20 >>> we keep the 2.4 methodology until we can come up with a better=20 >>> approach to enumerate devices at run-time. >> >> >> >> Andrei & I are already discussing this. I'm going to change the=20 >> xparameters redefines to provide a default set of mappings that can be=20 >> used if xparameters_*.h has the linux specific mappings.=20 >=20 >=20 > Thanks. Why not just use the xparameters_ml300.h file created by the=20 > system_linux.xmp in the EDK reference design for the ML403 and rename it=20 > to xparameters_ml403.h for inclusion into the kernel tree? We could then=20 > make a change in EDK, add a parameter that lets the user specify the=20 > board he uses, and with that automatically create an xparameters_ml403.h=20 > (or any other board for that matter). I don't understand what you mean. It sounds like your suggesting I do=20 exactly opposite what you're arguing; hand modify one of the=20 xparameters_*.h files. Are you saying that edk can't generate Linux=20 redefines for the ml403 at the moment? I do *not* think I should replace the edk-generated xparameters_ml403.h=20 with a hacked xparameters_ml300.h file. I'd rather use the generated=20 _ml403 file and change the infrastructure when the Linux redefines are=20 ready. >=20 >> However, due to the fact that generated xparam files don't have the=20 >> Linux redefines if the FPGA engineer doesn't select a linux bsp. > >=20 > That's not a recommended flow. It's very easy to create an EDK design=20 > with the proper settings and since it is very likely that things change=20 > during the design process of the FPGA the small investment into making > the proper settings in the tool will save a lot of time in the end. I understand that it's not *recommended*; I'm just saying it's not=20 always *reality* :p >=20 >> I think it's important to allow user defined 'fixups' for their=20 >> board. (I've personally worked on a couple of projects where the FPGA >> engineer would not generate the Linux BSP). Design specific fixups=20 >> can go into the top level xparameters.h without touching the generated=20 >> file=20 >=20 >=20 > I strongly believe that this approach fixes things in the wrong place. > The correct thing to do is to use EDK to create a proper xparameters_*.h=20 > that matches the FPGA design. In your methodology, if the user decides > to change the peripheral names in EDK he will have to go back and change=20 > the defines in xparameters.h. With the 2.4 kernel methodology that is=20 > not necessary as such changes will be represented in a regenerated=20 > board-specific xparameters_*.h ??? Yes; but I already said that I'll change the patch to use the Xilinx=20 redefines. My argument is simply that *if* changes are required, there=20 is a way for the user to do it. In the normal (recommended) case;=20 nothing will need to be done. (think Larry Wall's quote: "easy things=20 easy; hard things possible) When it is needed; the fixups will be in xparameters.h; not=20 xparameters_*.h; and they'll be for a specific port. The fixups will=20 only need to be done once per project (most likely). >=20 >> <rant> BTW; it really bugs me that edk will generate different xparam >> files depending on the bsp; why isn't there a single standard set of=20 >> data that is loaded into all xparam files; regardless of software=20 >> target? Some no-OS targets need the same information that a Linux=20 >> port needs. </rant>=20 >=20 >=20 > EDK creates an xparameters.h that matches the names of the parameters in=20 > the hardware design. However, EDK is capable of assuming other=20 > personalities than 'standalone', for example Linux. My point is that the Linux redefines are useful to more than just Linux=20 ports. Don't you think standalone apps could also benefit from a=20 sane-set of defines for peripherals? In other words; shouldn't the=20 Linux redefines be always available (and called something more generic)? > With the Linux=20 > personality it creates the proper files AND directory structure for=20 > inclusion into the Linux kernel. Ideally, the source files that are used=20 > to create the Linux bsp for a given FPGA design should be included in=20 > the kernel tree and be maintained in there (maybe, in the xparameters=20 > directory). I'm not so sure though how well this would be accepted in=20 > the community. Opinions? I'll get back to you on this; I've got some thoughts; but they'll take a while to coallate. >=20 >> I've avoided using the same names as used by the Linux redefines=20 >> because I don't know how stable the linux bsp naming convention is,=20 >> and I want to avoid a naming conflict. If you can *guarantee* me that=20 >> those linux redefines are stable, then I have no problem using them=20 >> instead of the new defines that are currently in the patch. If they=20 >> are not; then I'll just do a one-to-one mapping into a non-conflicting=20 >> namespace, and users can provide custom definitions as needed.=20 >=20 >=20 > The names are stable. They have not changed since xparameters_ml300.h=20 > has been initially published to the 2.4 repository and there are no=20 > intentions on changing them. And again, we really want to move towards a=20 > structure that allows for detecting peripherals at run-time. That will > improve useability by a magnitude as no recompilation of the Linux=20 > kernel will be needed when the FPGA design changes. okay, I'll change the patch to use those names. >=20 >> This really isn't a big deal anyway; most of this discussion will=20 >> become moot in short order. Sometime in the next few releases,=20 >> linuxppc will flip over to using a flattened device tree to pass=20 >> device information from the boot loader to the kernel. xparameters=20 >> will drop out of the kernel proper entirely except for the=20 >> edk-generated device drivers (which is another issue entirely). All=20 >> the xparam stuff will be extracted into a device tree by u-boot or the=20 >> zImage wrapper. The kernel just won't care. :)=20 >=20 >=20 > I agree. That's the way to go. Let's work towards that goal and keep=20 > xparameters_* as they have been in 2.4 for the moment. >=20 >>> Specific to the patch: XPAR_DDR_SIZE is not the same as XPAR_MEM_*.=20 >>> XPAR_DDR_SIZE is specifically defined by the user as part of the BSP >>> generation and indicates how much memory is available for Linux. This=20 >>> can be (and typically is) the same as the physically available memory=20 >>> but can be less than that. On the other hand XPAR_MEM_* can be the=20 >>> same or a multiple of the physically available memory (aliasing for=20 >>> cached and non-cached accesses). Statically defining the memory size >>> in xparameters_ml403.h is not desirable. This is especially true for >>> the multi-processor FPGA devices that might want to share the=20 >>> physically available memory between themselves. >> >> >> >> As you can see in embed_config.c; I already discovered this the hard=20 >> way :(=20 >=20 >=20 > Right. Sorry, I was quoting the wrong file. The value should not be=20 > hard-coded in embed_config.c but instead XPAR_DDR_SIZE should be used=20 > which is defined in xparameters_ml403.h. ok >=20 >> Hmmm, I don't see any XPAR mem defines in xparameters_ml300.h. (I=20 >> don't have a copy of the linux xparams for ml403 in front of me at the=20 >> moment) Is this something new?=20 >=20 >=20 > I was referring to XPAR*MEM*, i.e. the base address and high address=20 > definition for the memory in EDK. >=20 >> Really, this isn't statically defined anyway. The bootloader (u-boot >> or zImage) passes the memory size into the kernel; and in fact the=20 >> kernel command line; or the board setup code can restrict the amount=20 >> of mem used by the kernel. XPAR_MEM_* isn't used by the kernel proper=20 >> at all.=20 >=20 >=20 > Agreed. >=20 >> Thanks for the comments.=20 >=20 >=20 > Thanks for making this patch available. I know how much hard work it is=20 > to get this done. >=20 >> >> >> Another issue we need to discuss is if/how to support the xilinx=20 >> generated BSP in the kernel proper; but I'll leave that for a=20 >> different email.=20 >=20 >=20 > Okay. >=20 >> If there's enough interest; I'll setup another git tree for the virtex=20 >> specific patches.=20 >=20 >=20 > Hmm, interesting idea. Let's see what others think. >=20 > - Peter cool, thanks. g. --=20 Grant Likely, B.Sc. P.Eng. Secret Lab Technologies Ltd. (403) 663-0761 _______________________________________________ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 00/10] Updated ML300 & ML403 patches 2006-01-17 18:10 John Bonesio @ 2006-01-17 18:31 ` Grant Likely 0 siblings, 0 replies; 22+ messages in thread From: Grant Likely @ 2006-01-17 18:31 UTC (permalink / raw) To: John Bonesio Cc: Grant Likely, Andrei Konovalov, rick.moleres, linuxppc-embedded John Bonesio wrote: > Hello, > > I work in the Xilinx software group. > > I'm replying to this email thread because Grant suggested there be a GIT > tree for Virtex specific changes. I was told today that we may be able to use Paul's linuxppc tree. I'm going to ask him later today. > > I am wondering if the open source community would prefer or see a > benefit to Xilinx owning/hosting the source trees (CVS or GIT or > whatever) for our drivers, and in particular the Linux adapter drivers. > If we did this we would provide a web site with the information along > with instructions on how to submit changes. > > We are exploring this idea and wanted to know what others thought of > this. Let's just keep things on the mailing list; it's the natural place to discuss issues. If the traffic gets too high, we can do something different. g. -- Grant Likely, B.Sc. P.Eng. Secret Lab Technologies Ltd. (403) 663-0761 ^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 00/10] Updated ML300 & ML403 patches
@ 2006-01-14 9:46 Grant Likely
[not found] ` <43CC5453.3060702@xilinx.com>
0 siblings, 1 reply; 22+ messages in thread
From: Grant Likely @ 2006-01-14 9:46 UTC (permalink / raw)
To: linuxppc-embedded, mporter
Here is the updated ML300 & ML403 patches to go into 2.6.16. Nothing
really has changed here other than a typo fix or two, and it is rebased
to the head of Linus' tree.
^ permalink raw reply [flat|nested] 22+ messages in thread[parent not found: <43CC5453.3060702@xilinx.com>]
* Re: [PATCH 00/10] Updated ML300 & ML403 patches [not found] ` <43CC5453.3060702@xilinx.com> @ 2006-01-17 7:39 ` Grant Likely 2006-01-17 12:52 ` Peter Ryser 2006-01-19 0:27 ` David H. Lynch Jr. 0 siblings, 2 replies; 22+ messages in thread From: Grant Likely @ 2006-01-17 7:39 UTC (permalink / raw) To: Peter Ryser Cc: Grant Likely, Andrei Konovalov, Rick Moleres, linuxppc-embedded Let's keep this conversation on the mailing list. Peter Ryser wrote: > Hi Grant and Andrei, > > I'm glad to see some activity on the linuxppc email alias for the MLxxx > boards and appreciate the work put into moving the 2.4 support to 2.6. > > I just tried to boot the 2.6 kernel with Grant's patches applied to > Linus' latest tree on both the ML300 and the ML403 and in both cases end > up with the PLB Error LED lit up. Both boards print the messages from > the bootloader, print "Now booting the kernel" and then nothing (but the > error LED). Anything you can think of that is going wrong? Hmm, did you use the ml403 and ml300 def configs? What date did you pull Linus' tree? Kumar and Paul were talking today about some serial subsystem breakage on the linux-2.6 tree this weekend... I'll fast forward tonight and try it on my board. Try seeking to commit: 67daf5f11f06b9b15f8320de1d237ccc2e74fe43 That's what I generated the latest patches against. > > Anyway, there is another issue that I would like to bring up and it has > to do with xparameters.h. The xparameters.h file, or more exactly, the > xparameters_* file, is automatically generated by EDK and is then used > to configure the devices in the Linux kernel at compile time. While I > understand the desire to get away from a static device definition to > device enumeration at run-time, the current set of patches is a step > backwards for users from a useability point of view. Users will now have > to modify xparameters*.h by hand which is an error-prone process. Actually, users should *never* modifiy generated files. The intent is that board specific fixups go directly into the top level xparameters.h so that newly generated files don't have to be touched. But yes, I understand what you mean. > Additionally, the original 'redefines' are now replaced with redefines > in xparameters.h but differently for every board. I suggest we keep the > 2.4 methodology until we can come up with a better approach to enumerate > devices at run-time. Andrei & I are already discussing this. I'm going to change the xparameters redefines to provide a default set of mappings that can be used if xparameters_*.h has the linux specific mappings. However, due to the fact that generated xparam files don't have the Linux redefines if the FPGA engineer doesn't select a linux bsp. I think it's important to allow user defined 'fixups' for their board. (I've personally worked on a couple of projects where the FPGA engineer would not generate the Linux BSP). Design specific fixups can go into the top level xparameters.h without touching the generated file <rant> BTW; it really bugs me that edk will generate different xparam files depending on the bsp; why isn't there a single standard set of data that is loaded into all xparam files; regardless of software target? Some no-OS targets need the same information that a Linux port needs. </rant> I've avoided using the same names as used by the Linux redefines because I don't know how stable the linux bsp naming convention is, and I want to avoid a naming conflict. If you can *guarantee* me that those linux redefines are stable, then I have no problem using them instead of the new defines that are currently in the patch. If they are not; then I'll just do a one-to-one mapping into a non-conflicting namespace, and users can provide custom definitions as needed. This really isn't a big deal anyway; most of this discussion will become moot in short order. Sometime in the next few releases, linuxppc will flip over to using a flattened device tree to pass device information from the boot loader to the kernel. xparameters will drop out of the kernel proper entirely except for the edk-generated device drivers (which is another issue entirely). All the xparam stuff will be extracted into a device tree by u-boot or the zImage wrapper. The kernel just won't care. :) > > Specific to the patch: XPAR_DDR_SIZE is not the same as XPAR_MEM_*. > XPAR_DDR_SIZE is specifically defined by the user as part of the BSP > generation and indicates how much memory is available for Linux. This > can be (and typically is) the same as the physically available memory > but can be less than that. On the other hand XPAR_MEM_* can be the same > or a multiple of the physically available memory (aliasing for cached > and non-cached accesses). Statically defining the memory size in > xparameters_ml403.h is not desirable. This is especially true for the > multi-processor FPGA devices that might want to share the physically > available memory between themselves. As you can see in embed_config.c; I already discovered this the hard way :( Hmmm, I don't see any XPAR mem defines in xparameters_ml300.h. (I don't have a copy of the linux xparams for ml403 in front of me at the moment) Is this something new? Really, this isn't statically defined anyway. The bootloader (u-boot or zImage) passes the memory size into the kernel; and in fact the kernel command line; or the board setup code can restrict the amount of mem used by the kernel. XPAR_MEM_* isn't used by the kernel proper at all. > > - Peter Thanks for the comments. Another issue we need to discuss is if/how to support the xilinx generated BSP in the kernel proper; but I'll leave that for a different email. If there's enough interest; I'll setup another git tree for the virtex specific patches. g. -- Grant Likely, B.Sc. P.Eng. Secret Lab Technologies Ltd. (403) 663-0761 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 00/10] Updated ML300 & ML403 patches 2006-01-17 7:39 ` Grant Likely @ 2006-01-17 12:52 ` Peter Ryser 2006-01-17 15:41 ` Grant Likely 2006-01-17 19:31 ` Grant Likely 2006-01-19 0:27 ` David H. Lynch Jr. 1 sibling, 2 replies; 22+ messages in thread From: Peter Ryser @ 2006-01-17 12:52 UTC (permalink / raw) To: Grant Likely Cc: Grant Likely, Andrei Konovalov, Rick Moleres, linuxppc-embedded > Hmm, did you use the ml403 and ml300 def configs? What date did you > pull Linus' tree? Kumar and Paul were talking today about some serial > subsystem breakage on the linux-2.6 tree this weekend... I'll fast > forward tonight and try it on my board. Okay, please let me know how this works for you. > Try seeking to commit: 67daf5f11f06b9b15f8320de1d237ccc2e74fe43 > That's what I generated the latest patches against. Hmm, I only recently switched to using git. Is this number string some kind of a tag that I can synchronize my local git tree to? If so, how? >> Anyway, there is another issue that I would like to bring up and it >> has to do with xparameters.h. The xparameters.h file, or more >> exactly, the xparameters_* file, is automatically generated by EDK >> and is then used to configure the devices in the Linux kernel at >> compile time. While I understand the desire to get away from a static >> device definition to device enumeration at run-time, the current set >> of patches is a step backwards for users from a useability point of >> view. Users will now have to modify xparameters*.h by hand which is >> an error-prone process. > > > Actually, users should *never* modifiy generated files. The intent is > that board specific fixups go directly into the top level > xparameters.h so that newly generated files don't have to be touched. > But yes, I understand what you mean. An EDK user is free to choose arbitrary names for his peripherals. Additionally, Base System Builder uses different names for various boards (historically). With that it is impossible to make static assignments in xparameters.h. If you go back to the 2.4 kernel and have a look at xparameters_ml300.h you can see that the assignment of boards specific parameters to Linux specific parameters is done in there and that xparameters.h is basically used to chose the proper xparameters_* file for a given board. >> Additionally, the original 'redefines' are now replaced with >> redefines in xparameters.h but differently for every board. I suggest >> we keep the 2.4 methodology until we can come up with a better >> approach to enumerate devices at run-time. > > > Andrei & I are already discussing this. I'm going to change the > xparameters redefines to provide a default set of mappings that can be > used if xparameters_*.h has the linux specific mappings. Thanks. Why not just use the xparameters_ml300.h file created by the system_linux.xmp in the EDK reference design for the ML403 and rename it to xparameters_ml403.h for inclusion into the kernel tree? We could then make a change in EDK, add a parameter that lets the user specify the board he uses, and with that automatically create an xparameters_ml403.h (or any other board for that matter). > However, due to the fact that generated xparam files don't have the > Linux redefines if the FPGA engineer doesn't select a linux bsp. That's not a recommended flow. It's very easy to create an EDK design with the proper settings and since it is very likely that things change during the design process of the FPGA the small investment into making the proper settings in the tool will save a lot of time in the end. > I think it's important to allow user defined 'fixups' for their > board. (I've personally worked on a couple of projects where the FPGA > engineer would not generate the Linux BSP). Design specific fixups > can go into the top level xparameters.h without touching the generated > file I strongly believe that this approach fixes things in the wrong place. The correct thing to do is to use EDK to create a proper xparameters_*.h that matches the FPGA design. In your methodology, if the user decides to change the peripheral names in EDK he will have to go back and change the defines in xparameters.h. With the 2.4 kernel methodology that is not necessary as such changes will be represented in a regenerated board-specific xparameters_*.h > <rant> BTW; it really bugs me that edk will generate different xparam > files depending on the bsp; why isn't there a single standard set of > data that is loaded into all xparam files; regardless of software > target? Some no-OS targets need the same information that a Linux > port needs. </rant> EDK creates an xparameters.h that matches the names of the parameters in the hardware design. However, EDK is capable of assuming other personalities than 'standalone', for example Linux. With the Linux personality it creates the proper files AND directory structure for inclusion into the Linux kernel. Ideally, the source files that are used to create the Linux bsp for a given FPGA design should be included in the kernel tree and be maintained in there (maybe, in the xparameters directory). I'm not so sure though how well this would be accepted in the community. Opinions? > I've avoided using the same names as used by the Linux redefines > because I don't know how stable the linux bsp naming convention is, > and I want to avoid a naming conflict. If you can *guarantee* me that > those linux redefines are stable, then I have no problem using them > instead of the new defines that are currently in the patch. If they > are not; then I'll just do a one-to-one mapping into a non-conflicting > namespace, and users can provide custom definitions as needed. The names are stable. They have not changed since xparameters_ml300.h has been initially published to the 2.4 repository and there are no intentions on changing them. And again, we really want to move towards a structure that allows for detecting peripherals at run-time. That will improve useability by a magnitude as no recompilation of the Linux kernel will be needed when the FPGA design changes. > This really isn't a big deal anyway; most of this discussion will > become moot in short order. Sometime in the next few releases, > linuxppc will flip over to using a flattened device tree to pass > device information from the boot loader to the kernel. xparameters > will drop out of the kernel proper entirely except for the > edk-generated device drivers (which is another issue entirely). All > the xparam stuff will be extracted into a device tree by u-boot or the > zImage wrapper. The kernel just won't care. :) I agree. That's the way to go. Let's work towards that goal and keep xparameters_* as they have been in 2.4 for the moment. >> Specific to the patch: XPAR_DDR_SIZE is not the same as XPAR_MEM_*. >> XPAR_DDR_SIZE is specifically defined by the user as part of the BSP >> generation and indicates how much memory is available for Linux. This >> can be (and typically is) the same as the physically available memory >> but can be less than that. On the other hand XPAR_MEM_* can be the >> same or a multiple of the physically available memory (aliasing for >> cached and non-cached accesses). Statically defining the memory size >> in xparameters_ml403.h is not desirable. This is especially true for >> the multi-processor FPGA devices that might want to share the >> physically available memory between themselves. > > > As you can see in embed_config.c; I already discovered this the hard > way :( Right. Sorry, I was quoting the wrong file. The value should not be hard-coded in embed_config.c but instead XPAR_DDR_SIZE should be used which is defined in xparameters_ml403.h. > Hmmm, I don't see any XPAR mem defines in xparameters_ml300.h. (I > don't have a copy of the linux xparams for ml403 in front of me at the > moment) Is this something new? I was referring to XPAR*MEM*, i.e. the base address and high address definition for the memory in EDK. > Really, this isn't statically defined anyway. The bootloader (u-boot > or zImage) passes the memory size into the kernel; and in fact the > kernel command line; or the board setup code can restrict the amount > of mem used by the kernel. XPAR_MEM_* isn't used by the kernel proper > at all. Agreed. > Thanks for the comments. Thanks for making this patch available. I know how much hard work it is to get this done. > > > Another issue we need to discuss is if/how to support the xilinx > generated BSP in the kernel proper; but I'll leave that for a > different email. Okay. > If there's enough interest; I'll setup another git tree for the virtex > specific patches. Hmm, interesting idea. Let's see what others think. - Peter ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 00/10] Updated ML300 & ML403 patches 2006-01-17 12:52 ` Peter Ryser @ 2006-01-17 15:41 ` Grant Likely 2006-01-17 17:06 ` Peter Ryser 2006-01-17 19:31 ` Grant Likely 1 sibling, 1 reply; 22+ messages in thread From: Grant Likely @ 2006-01-17 15:41 UTC (permalink / raw) To: Peter Ryser Cc: Grant Likely, Andrei Konovalov, Rick Moleres, linuxppc-embedded Peter Ryser wrote: > >> Hmm, did you use the ml403 and ml300 def configs? What date did you >> pull Linus' tree? Kumar and Paul were talking today about some serial >> subsystem breakage on the linux-2.6 tree this weekend... I'll fast >> forward tonight and try it on my board. > > > Okay, please let me know how this works for you. > >> Try seeking to commit: 67daf5f11f06b9b15f8320de1d237ccc2e74fe43 >> That's what I generated the latest patches against. > > > Hmm, I only recently switched to using git. Is this number string some > kind of a tag that I can synchronize my local git tree to? If so, how? > Yea, the number is kind of like a raw tag without a name associated with it. The cg-seek command can be used to get you there. (But you also need to have cogito installed) >>> Anyway, there is another issue that I would like to bring up and it >>> has to do with xparameters.h. The xparameters.h file, or more >>> exactly, the xparameters_* file, is automatically generated by EDK >>> and is then used to configure the devices in the Linux kernel at >>> compile time. While I understand the desire to get away from a static >>> device definition to device enumeration at run-time, the current set >>> of patches is a step backwards for users from a useability point of >>> view. Users will now have to modify xparameters*.h by hand which is >>> an error-prone process. >> >> >> >> Actually, users should *never* modifiy generated files. The intent is >> that board specific fixups go directly into the top level >> xparameters.h so that newly generated files don't have to be touched. >> But yes, I understand what you mean. > > > An EDK user is free to choose arbitrary names for his peripherals. > Additionally, Base System Builder uses different names for various > boards (historically). With that it is impossible to make static > assignments in xparameters.h. If you go back to the 2.4 kernel and have > a look at xparameters_ml300.h you can see that the assignment of boards > specific parameters to Linux specific parameters is done in there and > that xparameters.h is basically used to chose the proper xparameters_* > file for a given board. okay > >>> Additionally, the original 'redefines' are now replaced with >>> redefines in xparameters.h but differently for every board. I suggest >>> we keep the 2.4 methodology until we can come up with a better >>> approach to enumerate devices at run-time. >> >> >> >> Andrei & I are already discussing this. I'm going to change the >> xparameters redefines to provide a default set of mappings that can be >> used if xparameters_*.h has the linux specific mappings. > > > Thanks. Why not just use the xparameters_ml300.h file created by the > system_linux.xmp in the EDK reference design for the ML403 and rename it > to xparameters_ml403.h for inclusion into the kernel tree? We could then > make a change in EDK, add a parameter that lets the user specify the > board he uses, and with that automatically create an xparameters_ml403.h > (or any other board for that matter). I don't understand what you mean. It sounds like your suggesting I do exactly opposite what you're arguing; hand modify one of the xparameters_*.h files. Are you saying that edk can't generate Linux redefines for the ml403 at the moment? I do *not* think I should replace the edk-generated xparameters_ml403.h with a hacked xparameters_ml300.h file. I'd rather use the generated _ml403 file and change the infrastructure when the Linux redefines are ready. > >> However, due to the fact that generated xparam files don't have the >> Linux redefines if the FPGA engineer doesn't select a linux bsp. > > > That's not a recommended flow. It's very easy to create an EDK design > with the proper settings and since it is very likely that things change > during the design process of the FPGA the small investment into making > the proper settings in the tool will save a lot of time in the end. I understand that it's not *recommended*; I'm just saying it's not always *reality* :p > >> I think it's important to allow user defined 'fixups' for their >> board. (I've personally worked on a couple of projects where the FPGA >> engineer would not generate the Linux BSP). Design specific fixups >> can go into the top level xparameters.h without touching the generated >> file > > > I strongly believe that this approach fixes things in the wrong place. > The correct thing to do is to use EDK to create a proper xparameters_*.h > that matches the FPGA design. In your methodology, if the user decides > to change the peripheral names in EDK he will have to go back and change > the defines in xparameters.h. With the 2.4 kernel methodology that is > not necessary as such changes will be represented in a regenerated > board-specific xparameters_*.h ??? Yes; but I already said that I'll change the patch to use the Xilinx redefines. My argument is simply that *if* changes are required, there is a way for the user to do it. In the normal (recommended) case; nothing will need to be done. (think Larry Wall's quote: "easy things easy; hard things possible) When it is needed; the fixups will be in xparameters.h; not xparameters_*.h; and they'll be for a specific port. The fixups will only need to be done once per project (most likely). > >> <rant> BTW; it really bugs me that edk will generate different xparam >> files depending on the bsp; why isn't there a single standard set of >> data that is loaded into all xparam files; regardless of software >> target? Some no-OS targets need the same information that a Linux >> port needs. </rant> > > > EDK creates an xparameters.h that matches the names of the parameters in > the hardware design. However, EDK is capable of assuming other > personalities than 'standalone', for example Linux. My point is that the Linux redefines are useful to more than just Linux ports. Don't you think standalone apps could also benefit from a sane-set of defines for peripherals? In other words; shouldn't the Linux redefines be always available (and called something more generic)? > With the Linux > personality it creates the proper files AND directory structure for > inclusion into the Linux kernel. Ideally, the source files that are used > to create the Linux bsp for a given FPGA design should be included in > the kernel tree and be maintained in there (maybe, in the xparameters > directory). I'm not so sure though how well this would be accepted in > the community. Opinions? I'll get back to you on this; I've got some thoughts; but they'll take a while to coallate. > >> I've avoided using the same names as used by the Linux redefines >> because I don't know how stable the linux bsp naming convention is, >> and I want to avoid a naming conflict. If you can *guarantee* me that >> those linux redefines are stable, then I have no problem using them >> instead of the new defines that are currently in the patch. If they >> are not; then I'll just do a one-to-one mapping into a non-conflicting >> namespace, and users can provide custom definitions as needed. > > > The names are stable. They have not changed since xparameters_ml300.h > has been initially published to the 2.4 repository and there are no > intentions on changing them. And again, we really want to move towards a > structure that allows for detecting peripherals at run-time. That will > improve useability by a magnitude as no recompilation of the Linux > kernel will be needed when the FPGA design changes. okay, I'll change the patch to use those names. > >> This really isn't a big deal anyway; most of this discussion will >> become moot in short order. Sometime in the next few releases, >> linuxppc will flip over to using a flattened device tree to pass >> device information from the boot loader to the kernel. xparameters >> will drop out of the kernel proper entirely except for the >> edk-generated device drivers (which is another issue entirely). All >> the xparam stuff will be extracted into a device tree by u-boot or the >> zImage wrapper. The kernel just won't care. :) > > > I agree. That's the way to go. Let's work towards that goal and keep > xparameters_* as they have been in 2.4 for the moment. > >>> Specific to the patch: XPAR_DDR_SIZE is not the same as XPAR_MEM_*. >>> XPAR_DDR_SIZE is specifically defined by the user as part of the BSP >>> generation and indicates how much memory is available for Linux. This >>> can be (and typically is) the same as the physically available memory >>> but can be less than that. On the other hand XPAR_MEM_* can be the >>> same or a multiple of the physically available memory (aliasing for >>> cached and non-cached accesses). Statically defining the memory size >>> in xparameters_ml403.h is not desirable. This is especially true for >>> the multi-processor FPGA devices that might want to share the >>> physically available memory between themselves. >> >> >> >> As you can see in embed_config.c; I already discovered this the hard >> way :( > > > Right. Sorry, I was quoting the wrong file. The value should not be > hard-coded in embed_config.c but instead XPAR_DDR_SIZE should be used > which is defined in xparameters_ml403.h. ok > >> Hmmm, I don't see any XPAR mem defines in xparameters_ml300.h. (I >> don't have a copy of the linux xparams for ml403 in front of me at the >> moment) Is this something new? > > > I was referring to XPAR*MEM*, i.e. the base address and high address > definition for the memory in EDK. > >> Really, this isn't statically defined anyway. The bootloader (u-boot >> or zImage) passes the memory size into the kernel; and in fact the >> kernel command line; or the board setup code can restrict the amount >> of mem used by the kernel. XPAR_MEM_* isn't used by the kernel proper >> at all. > > > Agreed. > >> Thanks for the comments. > > > Thanks for making this patch available. I know how much hard work it is > to get this done. > >> >> >> Another issue we need to discuss is if/how to support the xilinx >> generated BSP in the kernel proper; but I'll leave that for a >> different email. > > > Okay. > >> If there's enough interest; I'll setup another git tree for the virtex >> specific patches. > > > Hmm, interesting idea. Let's see what others think. > > - Peter cool, thanks. g. -- Grant Likely, B.Sc. P.Eng. Secret Lab Technologies Ltd. (403) 663-0761 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 00/10] Updated ML300 & ML403 patches 2006-01-17 15:41 ` Grant Likely @ 2006-01-17 17:06 ` Peter Ryser 2006-01-17 17:30 ` Grant Likely 0 siblings, 1 reply; 22+ messages in thread From: Peter Ryser @ 2006-01-17 17:06 UTC (permalink / raw) To: Grant Likely Cc: Andrei Konovalov, Grant Likely, Rick Moleres, linuxppc-embedded > I don't understand what you mean. It sounds like your suggesting I do > exactly opposite what you're arguing; hand modify one of the > xparameters_*.h files. Are you saying that edk can't generate Linux > redefines for the ml403 at the moment? Yes, it can. It looks they are not present in the xparameters_ml403.h that you submitted as part of your patch. I'll send you the automatically generated file in a seperate email. > I do *not* think I should replace the edk-generated > xparameters_ml403.h with a hacked xparameters_ml300.h file. I'd > rather use the generated _ml403 file and change the infrastructure > when the Linux redefines are ready. See above. BTW, I'm not sure how familiar you are with the process in EDK. Let me know if I can help you step through it. >> That's not a recommended flow. It's very easy to create an EDK design >> with the proper settings and since it is very likely that things >> change during the design process of the FPGA the small investment >> into making the proper settings in the tool will save a lot of time >> in the end. > > > I understand that it's not *recommended*; I'm just saying it's not > always *reality* :p Yeah, that's true for user projects. However, I hope that we can get the default included in the Linux 2.6 kernel right. > Yes; but I already said that I'll change the patch to use the Xilinx > redefines. My argument is simply that *if* changes are required, > there is a way for the user to do it. In the normal (recommended) > case; nothing will need to be done. (think Larry Wall's quote: "easy > things easy; hard things possible) > > When it is needed; the fixups will be in xparameters.h; not > xparameters_*.h; and they'll be for a specific port. The fixups will > only need to be done once per project (most likely). I'm not sure that I follow your argument here. > My point is that the Linux redefines are useful to more than just > Linux ports. Don't you think standalone apps could also benefit from > a sane-set of defines for peripherals? In other words; shouldn't the > Linux redefines be always available (and called something more generic)? I see what you mean and I tend to agree. > okay, I'll change the patch to use those names. Great. Thanks. - Peter ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 00/10] Updated ML300 & ML403 patches 2006-01-17 17:06 ` Peter Ryser @ 2006-01-17 17:30 ` Grant Likely 0 siblings, 0 replies; 22+ messages in thread From: Grant Likely @ 2006-01-17 17:30 UTC (permalink / raw) To: Peter Ryser Cc: Andrei Konovalov, Grant Likely, Rick Moleres, linuxppc-embedded Peter Ryser wrote: > >> I don't understand what you mean. It sounds like your suggesting I do >> exactly opposite what you're arguing; hand modify one of the >> xparameters_*.h files. Are you saying that edk can't generate Linux >> redefines for the ml403 at the moment? > > > Yes, it can. It looks they are not present in the xparameters_ml403.h > that you submitted as part of your patch. I'll send you the > automatically generated file in a seperate email. okay good; I misunderstood what you were saying. I pulled xparameters_ml403.h out of the ref design w/ the standalone bsp. I just haven't bothered trying to generating the Linux bsp yet. > >> I do *not* think I should replace the edk-generated >> xparameters_ml403.h with a hacked xparameters_ml300.h file. I'd >> rather use the generated _ml403 file and change the infrastructure >> when the Linux redefines are ready. > > > See above. BTW, I'm not sure how familiar you are with the process in > EDK. Let me know if I can help you step through it. okay, I'll ping you when I've got questions. >> I understand that it's not *recommended*; I'm just saying it's not >> always *reality* :p > > > Yeah, that's true for user projects. However, I hope that we can get the > default included in the Linux 2.6 kernel right. yes, definately > >> Yes; but I already said that I'll change the patch to use the Xilinx >> redefines. My argument is simply that *if* changes are required, >> there is a way for the user to do it. In the normal (recommended) >> case; nothing will need to be done. (think Larry Wall's quote: "easy >> things easy; hard things possible) >> >> When it is needed; the fixups will be in xparameters.h; not >> xparameters_*.h; and they'll be for a specific port. The fixups will >> only need to be done once per project (most likely). > > > I'm not sure that I follow your argument here. I'll compose my answer in code; watch for patches. :) btw, once Linus closes the 2.6.16 merge window, it looks like we may be able to use the powerpc.git tree for tracking these changes. Cheers, g. -- Grant Likely, B.Sc. P.Eng. Secret Lab Technologies Ltd. (403) 663-0761 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 00/10] Updated ML300 & ML403 patches 2006-01-17 12:52 ` Peter Ryser 2006-01-17 15:41 ` Grant Likely @ 2006-01-17 19:31 ` Grant Likely 2006-01-18 23:26 ` Peter Ryser 1 sibling, 1 reply; 22+ messages in thread From: Grant Likely @ 2006-01-17 19:31 UTC (permalink / raw) To: Peter Ryser Cc: Grant Likely, Andrei Konovalov, Rick Moleres, linuxppc-embedded Peter Ryser wrote: > >> Hmm, did you use the ml403 and ml300 def configs? What date did you >> pull Linus' tree? Kumar and Paul were talking today about some serial >> subsystem breakage on the linux-2.6 tree this weekend... I'll fast >> forward tonight and try it on my board. > > > Okay, please let me know how this works for you. Yeah, the head of Linus' tree is busted. Doing a cg-seek 67daf5f11f06b9b15f8320de1d237ccc2e74fe43 will work, but you first need to remove the following line from arch/ppc/kernel/ppc_ksyms.c EXPORT_SYMBOL(get_wchan); The fix will be in post -rc1 Cheers, g. -- Grant Likely, B.Sc. P.Eng. Secret Lab Technologies Ltd. (403) 663-0761 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 00/10] Updated ML300 & ML403 patches 2006-01-17 19:31 ` Grant Likely @ 2006-01-18 23:26 ` Peter Ryser 2006-01-19 5:11 ` Grant Likely 0 siblings, 1 reply; 22+ messages in thread From: Peter Ryser @ 2006-01-18 23:26 UTC (permalink / raw) To: Grant Likely Cc: Grant Likely, Andrei Konovalov, Rick Moleres, linuxppc-embedded > Yeah, the head of Linus' tree is busted. Doing a cg-seek > 67daf5f11f06b9b15f8320de1d237ccc2e74fe43 will work, but you first need > to remove the following line from arch/ppc/kernel/ppc_ksyms.c > > EXPORT_SYMBOL(get_wchan); > After applying your patches to the branch-point you mention above, removing that symbol, and configuring for the ML403 I can get to a boot prompt. Good. Doing the same for the ML300, though, does not work, i.e. I get a single line saying: "Data machine check in kernel mode." Digging in the kernel configuration I don't seem to find a place where I can turn on more verbose output, i.e. a register dump at the time of the machine check exception. Any idea where I might find that? - Peter ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 00/10] Updated ML300 & ML403 patches 2006-01-18 23:26 ` Peter Ryser @ 2006-01-19 5:11 ` Grant Likely 0 siblings, 0 replies; 22+ messages in thread From: Grant Likely @ 2006-01-19 5:11 UTC (permalink / raw) To: Peter Ryser Cc: Grant Likely, Andrei Konovalov, Rick Moleres, linuxppc-embedded Peter Ryser wrote: > >> Yeah, the head of Linus' tree is busted. Doing a cg-seek >> 67daf5f11f06b9b15f8320de1d237ccc2e74fe43 will work, but you first need >> to remove the following line from arch/ppc/kernel/ppc_ksyms.c >> >> EXPORT_SYMBOL(get_wchan); >> > After applying your patches to the branch-point you mention above, > removing that symbol, and configuring for the ML403 I can get to a boot > prompt. Good. > > Doing the same for the ML300, though, does not work, i.e. I get a single > line saying: > "Data machine check in kernel mode." update you git to 2.6.16-rc1, and apply this patch: http://www.ussg.iu.edu/hypermail/linux/kernel/0601.2/0301.html Then apply the patches and try again. -- Grant Likely, B.Sc. P.Eng. Secret Lab Technologies Ltd. (403) 663-0761 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 00/10] Updated ML300 & ML403 patches 2006-01-17 7:39 ` Grant Likely 2006-01-17 12:52 ` Peter Ryser @ 2006-01-19 0:27 ` David H. Lynch Jr. 2006-01-19 7:14 ` jeffer 1 sibling, 1 reply; 22+ messages in thread From: David H. Lynch Jr. @ 2006-01-19 0:27 UTC (permalink / raw) To: linuxppc-embedded Grant Likely wrote: > Let's keep this conversation on the mailing list. > > Peter Ryser wrote: > >>Hi Grant and Andrei, >> >>I'm glad to see some activity on the linuxppc email alias for the MLxxx >>boards and appreciate the work put into moving the 2.4 support to 2.6. >> >>I just tried to boot the 2.6 kernel with Grant's patches applied to >>Linus' latest tree on both the ML300 and the ML403 and in both cases end >>up with the PLB Error LED lit up. Both boards print the messages from >>the bootloader, print "Now booting the kernel" and then nothing (but the >>error LED). Anything you can think of that is going wrong? I am getting the same problem when I use Grant's patches. In my instance I have isolated the problem to hanging in ppc_sys_get_pdata(VIRTEX_UART). This appears to be a fairly trivial routing, so my current assumption is that I either have VIRTEX_UART defined improperly or I have the ppc_sys data structure created wrong. >>Anyway, there is another issue that I would like to bring up and it has >>to do with xparameters.h. The xparameters.h file, or more exactly, the >>xparameters_* file, is automatically generated by EDK and is then used >>to configure the devices in the Linux kernel at compile time. While I >>understand the desire to get away from a static device definition to >>device enumeration at run-time, the current set of patches is a step >>backwards for users from a useability point of view. Users will now have >>to modify xparameters*.h by hand which is an error-prone process. > > > Actually, users should *never* modifiy generated files. The intent is > that board specific fixups go directly into the top level xparameters.h > so that newly generated files don't have to be touched. But yes, I > understand what you mean. > > It would be really nice if the was either some comments in xparameters.h or in the Documents directory explaining what the Linux xparameters values are so that it it would be easy to know what items from xparameters_xxx.h have to be mapped or redefined. > This really isn't a big deal anyway; most of this discussion will become > moot in short order. Sometime in the next few releases, linuxppc will > flip over to using a flattened device tree to pass device information > from the boot loader to the kernel. xparameters will drop out of the > kernel proper entirely except for the edk-generated device drivers > (which is another issue entirely). All the xparam stuff will be > extracted into a device tree by u-boot or the zImage wrapper. The > kernel just won't care. :) Where can we get more information on what is happening here ? I started the E12 port with most info in xparameters, but I have been moving towards getting things passed in board_info. I am not using u-boot as the E12 has a general purpose elf loader, and it was easier to add a fee lines for Linux. Regardless I would like to be compatible with whatever is coming - maybe even ahead fo the curve. The e12 is just the first of a family of products - the e14 already exists. There maybe revisions of each at different speeds with different memory. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 00/10] Updated ML300 & ML403 patches 2006-01-19 0:27 ` David H. Lynch Jr. @ 2006-01-19 7:14 ` jeffer 2006-01-19 7:29 ` Peter Ryser 0 siblings, 1 reply; 22+ messages in thread From: jeffer @ 2006-01-19 7:14 UTC (permalink / raw) To: David H. Lynch Jr.; +Cc: linuxppc-embedded [-- Attachment #1: Type: text/plain, Size: 2528 bytes --] Hi at all Since two week I have this Problem and can't solve it. I allready read DULG and search in Mailinglists but I can't run linux. Perhaps had the same problem and can help me. My Problem: After I load the uImage (uImage at 0x00400000 ) from server, I try to run in with command bootm. => bootm 00400000 Booting image at 00400000... Image Name: Linux-2.4.24-pre2 Created: 2006-01-19 6:25:03 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 700730 Bytes = 684.3 kB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK don't start kernel my board : sdram 16m 0----ffffff flash 4m ffc00000 ---fffffff > routing, so my current assumption is > that I either have VIRTEX_UART defined improperly or I have the ppc_sys > data structure created wrong. > > > > > > > > It would be really nice if the was either some comments in > xparameters.h or in the Documents directory explaining what the Linux > xparameters values are so that it it would be easy to know what items > from xparameters_xxx.h have to be mapped or redefined. > > > > > This really isn't a big deal anyway; most of this discussion will become > > moot in short order. Sometime in the next few releases, linuxppc will > > flip over to using a flattened device tree to pass device information > > from the boot loader to the kernel. xparameters will drop out of the > > kernel proper entirely except for the edk-generated device drivers > > (which is another issue entirely). All the xparam stuff will be > > extracted into a device tree by u-boot or the zImage wrapper. The > > kernel just won't care. :) > Where can we get more information on what is happening here ? > I started the E12 port with most info in xparameters, but I have been > moving towards getting things passed in board_info. I am not using > u-boot as the E12 has a general purpose elf loader, and it was easier to > add a fee lines for Linux. Regardless I would like to be compatible with > whatever is coming - maybe even ahead fo the curve. The e12 is just the > first of a family of products - the e14 already exists. There maybe > revisions of each at different speeds with different memory. > > > _______________________________________________ > Linuxppc-embedded mailing list > Linuxppc-embedded@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded > [-- Attachment #2: Type: text/html, Size: 3307 bytes --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 00/10] Updated ML300 & ML403 patches 2006-01-19 7:14 ` jeffer @ 2006-01-19 7:29 ` Peter Ryser 0 siblings, 0 replies; 22+ messages in thread From: Peter Ryser @ 2006-01-19 7:29 UTC (permalink / raw) To: jeffer; +Cc: David H. Lynch Jr., linuxppc-embedded You need to apply a patch to the 2.4 Linux kernel to make it work with U-Boot for the MLxxx boards. You can find that patch as part of Xilinx Application Note 542 (XAPP542, http://direct.xilinx.com/bvdocs/appnotes/xapp542.pdf, http://direct.xilinx.com/bvdocs/appnotes/xapp542.zip) The process on how to apply the patch is described in that application note. - Peter PS: The application note is out of date for EDK tools newer than 6.2. The patch still works, though. jeffer wrote: > Hi at all > > > Since two week I have this Problem and can't solve it. I allready read > DULG and search in > Mailinglists but I can't run linux. Perhaps had the same problem and > can help me. > My Problem: > After I load the uImage (uImage at 0x00400000 ) > from server, I try to run in with command bootm. > => bootm 00400000 > Booting image at 00400000... > Image Name: Linux-2.4.24-pre2 > Created: 2006-01-19 6:25:03 UTC > Image Type: PowerPC Linux Kernel Image (gzip compressed) > Data Size: 700730 Bytes = 684.3 kB > Load Address: 00000000 > Entry Point: 00000000 > Verifying Checksum ... OK > Uncompressing Kernel Image ... OK > > don't start kernel > my board : > sdram 16m 0----ffffff > flash 4m ffc00000 ---fffffff > > > routing, so my current assumption is > that I either have VIRTEX_UART defined improperly or I have the > ppc_sys > data structure created wrong. > > > > > > > > It would be really nice if the was either some comments in > xparameters.h or in the Documents directory explaining what the Linux > xparameters values are so that it it would be easy to know what items > from xparameters_xxx.h have to be mapped or redefined. > > > > > This really isn't a big deal anyway; most of this discussion > will become > > moot in short order. Sometime in the next few releases, > linuxppc will > > flip over to using a flattened device tree to pass device > information > > from the boot loader to the kernel. xparameters will drop out > of the > > kernel proper entirely except for the edk-generated device drivers > > (which is another issue entirely). All the xparam stuff will be > > extracted into a device tree by u-boot or the zImage wrapper. The > > kernel just won't care. :) > Where can we get more information on what is happening here ? > I started the E12 port with most info in xparameters, but I have been > moving towards getting things passed in board_info. I am not using > u-boot as the E12 has a general purpose elf loader, and it was > easier to > add a fee lines for Linux. Regardless I would like to be > compatible with > whatever is coming - maybe even ahead fo the curve. The e12 is > just the > first of a family of products - the e14 already exists. There maybe > revisions of each at different speeds with different memory. > > > _______________________________________________ > Linuxppc-embedded mailing list > Linuxppc-embedded@ozlabs.org <mailto:Linuxppc-embedded@ozlabs.org> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded > > >------------------------------------------------------------------------ > >_______________________________________________ >Linuxppc-embedded mailing list >Linuxppc-embedded@ozlabs.org >https://ozlabs.org/mailman/listinfo/linuxppc-embedded > ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2006-02-09 14:51 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-01-27 12:01 [PATCH 00/10] Updated ML300 & ML403 patches Paula Saameño
2006-01-27 16:37 ` Grant Likely
-- strict thread matches above, loose matches on Subject: below --
2006-02-09 7:57 S. Egbert
2006-02-09 14:51 ` Grant Likely
[not found] <mailman.134.1137523561.17753.linuxppc-embedded@ozlabs.org>
2006-01-17 20:12 ` T Ziomek
2006-01-17 20:19 ` Grant Likely
2006-01-17 20:23 ` T Ziomek
2006-01-17 20:37 ` Grant Likely
2006-01-17 18:10 John Bonesio
2006-01-17 18:31 ` Grant Likely
2006-01-14 9:46 Grant Likely
[not found] ` <43CC5453.3060702@xilinx.com>
2006-01-17 7:39 ` Grant Likely
2006-01-17 12:52 ` Peter Ryser
2006-01-17 15:41 ` Grant Likely
2006-01-17 17:06 ` Peter Ryser
2006-01-17 17:30 ` Grant Likely
2006-01-17 19:31 ` Grant Likely
2006-01-18 23:26 ` Peter Ryser
2006-01-19 5:11 ` Grant Likely
2006-01-19 0:27 ` David H. Lynch Jr.
2006-01-19 7:14 ` jeffer
2006-01-19 7:29 ` Peter Ryser
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).