Hello,
Is there a recommended tool chain for building U-Boot on a PowerPC host? I've
used ELDK on x86 hosts in the past for this purpose, and it worked fine, but
now I need to perform it on a PowerPC host. As far as I could see, ELDK wasn't
supported on PowerPC hosts.
My target boards are the M
> >>
> >> Anyway, I'll wait for Kim's ACK before pushing it up into my dev-
> 1.3.4 branch
> >
> > see:
> >
> > http://article.gmane.org/gmane.comp.boot-loaders.u-boot/38991
>
>
> David, I'm still waiting for a response to Kim's comments before I can
> apply this. The window for 1.3.5 will open so
> >> >> < more than one DDR module?
> >>
> >> I'm not sure I follow exactly what you are asking? Do you mean using
> >> different DDR modules on different chip selects of the same
> >> controller? or something else?
> >>
> >> - k
> > Kumar - the current SPD DDR code assumes a single DIMM with
> < more than one DDR module?
>
> I'm not sure I follow exactly what you are asking? Do you mean using
> different DDR modules on different chip selects of the same
> controller? or something else?
>
> - k
Kumar - the current SPD DDR code assumes a single DIMM with a single fixed I2C
address.
Kumar Gala-3 wrote:
>
>> This is a series of patches that are a work-in-progress towards a new
>> DDR initialization for the Freescale 8{3,5,6}xxx devices that have a
>> common DDR controller.
>
(Sorry for the previous "no subject" message - hit the "send" too soon...)
Kumar,
Does this RFC also i
Kumar Gala-3 wrote:
>
> This is a series of patches that are a work-in-progress towards a new
> DDR initialization for the Freescale 8{3,5,6}xxx devices that have a
> common DDR controller.
>
Kumar,
Does this RFC also include support for identifying and initializing more than
one DDR module?
Davi
> David, I think this patch has been accomplished by some other patches
> which came in. Could you take a look at the recent patches to
> cpu/mpc85xx/cpu.c and see if those changes reflect everything you
> wanted? If not, please submit a patch on top of those changes.
Andy - these patched seem
> Can we merge the register definition files and have a single upm_config
> for mpc8[356]xx instead of duplicating it as being done here?
Not sure that I'm the right person for this job, as I don't have an 86xx based
board. Also, I'm not sure this would be a good idea: There are some differences
> Bad news, David, I think I mislead you with my Option #1 - it looks
> sorta OK, but it still is full of bad stuff, including line wraps, when
> you look at the actual text of the email.
.
.
.
> Sorry for getting your hopes up. Try finding an open port 25. :-/
>
That's pretty strange, as I manag
Add support for UPM configuration on the 85xx platform.
In addition, on the MPC83xx, remove MPC834x precompiler condition, in order to
support all MPC83xx processors.
Signed-off-by: David Saada <[EMAIL PROTECTED]>
cpu/mpc83xx/cpu.c |5
cpu/mpc85xx/cpu.c
> Option 1:
> -
> I've been playing with sending patches using Outlook. "Properly
> formatted" patches can be done by changing to a monospace font. This
> can be done either before or after pasting in the patch:
>
> Before pasting in the patch, you can change the format using a monospace
>> As you may have noticed, I've been trying to post some patches, but sending
>> most of them failed due to line wrapping problems. This is a problem with the
>> mailer we use here (outlook). Messing with the mailer didn't help, and so was
>> posting via the Nabble forum or my gmail account in tex
Hi,
As you may have noticed, I've been trying to post some patches, but sending
most of them failed due to line wrapping problems. This is a problem with the
mailer we use here (outlook). Messing with the mailer didn't help, and so was
posting via the Nabble forum or my gmail account in text mod
> I have been scouring the code (u-boot) to see evidence of using SPI to
> configure the ethernet PHY. I do not find anything that is obvious. The
> board uses BMC54XX ethernet transciever. I will appreciate any insight from
> you .
> I was able to locate and use QE configuration of IO pins. Many
> I'm aware of this. Changing register contents seems a useful extension
> to me, too. That's why I wrote "add such code". I think something like
> Print all (or a predefined set of) registers:
< => reg
> Print a specific register:
< => reg name
>Set a specific register to "value":
> Any chance you could split out the command code from this? That's
> really a separate piece of functionality.
Already separated it, as you may have noticed. Will try to resubmit in a
non wrapped way...
-
Check out the new S
> I don't think is a good idea. The code as presented is actually not
> suited for such an extension. And I definitly don't want to plan for
> another #ifdef maze.
> Are you aware of the "reginfo" command? Few people seem to know it.
> Maybe you should add such code there.
As far as I manage
> This sounds line a very general feature, but having a close look it
> seems that it is highly specialized on QE only.
> As such, it does not qualify for such a generic command name.
Wolfgang,
It is indeed a general feature, whose first implementation is for the
QE. It can (and should) be exte
> David, I ran into difficulties applying your QE IO patch, due to
> mailer mangling again, I'm afraid. It looked like there weren't *too*
> many, so I may manage to do it by hand, but if you can find some way
> to send me the 85xx-related patches in a non-mangled format, I would
> definitely g
This patch fragment includes commands for reading and writing parallel
I/O ports (pario command).
Signed-off-by: David Saada <[EMAIL PROTECTED]>
common/cmd_pario.c | 85
+++
common/Makefile |1
2 files changed, 86 insertions(+)
This patch fragment modifies the QE I/O pin configuration tables of all
relevant boards to include initial data.
Signed-off-by: David Saada <[EMAIL PROTECTED]>
mpc8323erdb/mpc8323erdb.c | 74 ++--
mpc832xemds/mpc832xemds.c | 74 ++--
mpc8360emds/mpc8360emds.c
d-off-by: David Saada <[EMAIL PROTECTED]>
cpu/mpc83xx/cpu_init.c |7 ++---
cpu/mpc83xx/qe_io.c| 59
-
cpu/mpc85xx/cpu_init.c |7 ++---
cpu/mpc85xx/qe_io.c| 58
++--
include/ioports.h |
Add MII commands to the UEC driver. Note that once a UEC device is selected,
any device on its MDIO bus can be addressed.
Signed-off-by: David Saada <[EMAIL PROTECTED]>
uec.c | 53 +
1 file changed, 53 insertions(+)
--- a/drivers/qe
Add support for UPM configuration on the 85xx platform.
In addition, on the MPC83xx, remove MPC834x precompiler condition, in order
to support all MPC83xx processors.
Signed-off-by: David Saada <[EMAIL PROTECTED]>
cpu/mpc83xx/cpu.c |5
cpu/mpc85xx/cpu.c
aced.
In addition, add IO pin read & write functions.
This patch also includes commands for reading and writing parallel I/O ports
(pario command).
Signed-off-by: David Saada <[EMAIL PROTECTED]>
b/common/cmd_pario.c | 85 +
board/freescale/mpc8323erdb/mpc832
> David, I ran into difficulties applying your QE IO patch, due to
> mailer mangling again, I'm afraid. It looked like there weren't *too*
> many, so I may manage to do it by hand, but if you can find some way
> to send me the 85xx-related patches in a non-mangled format, I would
> definitely get
Wolfgang Denk wrote:
> Hi everybody,
>
> as you are probably aware of, we have only 4 more days with an open
> merge window left (the merge window for 1.3.3 is open until Mar 31,
> 23:59:59 MET).
>
> I think I have now applied (or rejected) all patches I felt
> responsible for myself, i
> David Saada wrote:
> > On the MPC83xx & MPC85xx architectures that have QE, add initial
data to
> the
> > pin configuration table (qe_iop_conf_tab). This is relevant for GPIO
> pins
> > defined as output. One can setup a value of -1 to leave the value
> uncha
> > Definitely true, but that's a delicate change. For instance, this
UPM
> > patch has the same logics for the 83xx & 85xx platforms, but the
> > registers are different. Unifying this code should result in lots of
> > ugly ifdefs.
>
> which registers are different?
Well, not quite the register
> ack on the 83xx change, but the 85xx code looks identical to the 83xx
> version, and 86xx bits should be identical, too, so we would be better
> off refraining from triplicating code again and find a more common
> place to put this. Jon? Andy?
Definitely true, but that's a delicate change. For
Add support for UPM configuration on the 85xx platform.
In addition, on the MPC83xx, remove MPC834x precompiler condition, in order
to support all MPC83xx processors.
Signed-off-by: David Saada <[EMAIL PROTECTED]>
--- a/include/mpc85xx.h 2008-02-07 12:11:35.873966000 +0200
+++ b/i
aced.
In addition, add IO pin read & write functions.
This patch also includes commands for reading and writing parallel I/O ports
(pario command).
Signed-off-by: David Saada <[EMAIL PROTECTED]>
--- a/include/ioports.h 2008-02-07 12:11:35.717049000 +0200
+++ b/include/ioports.h 20
> > +void qe_read_iopin(u8 port, u8 pin, int *data)
> > +{
> > + u32 pin_1bit_mask;
> > + u32 tmp_val;
> > + volatile immap_t*im = (volatile immap_t *)CFG_IMMR;
> > + volatile qepio83xx_t*par_io = (volatile qepio83xx_t
>
> Don't use volat
Add support for UPM configuration on the 85xx platform.
In addition, on the MPC83xx, remove MPC834x precompiler condition, in
order to support all MPC83xx processors.
Signed-off-by: David Saada <[EMAIL PROTECTED]>
--- a/include/mpc85xx.h 2008-02-07 12:11:35.873966000 +0200
+++ b/i
.
In addition, add IO pin read & write functions.
This patch also includes commands for reading and writing parallel I/O
ports (pario command).
Signed-off-by: David Saada <[EMAIL PROTECTED]>
--- a/include/ioports.h 2008-01-23 15:41:38.0 +0200
+++ b/include/ioports.h 20
> David, any word on this? I'm trying to aggressively stay on top of
> patches for 1.3.3
>
> Andy
Sorry - had loads of work here, will try to squeeze it in today.
David.
-
This SF.net email is sponsored by: Microsoft
Defy a
> > No problem. If there's nothing else, I'll repost the patch with this
> > change (hopefully the last time).
>
> No, I think that's the only issue I have. Well, that and the fact
that I
> can
> never apply your patches because git-am doesn't like them.
Yes, sorry about that. Wasn't too well i
> It looks okay, but I haven't had a chance to review it thoroughly.
>
> I don't like the value of "2" for "ignore". Since that type is an
'int',
> how
> about using "-1" instead?
No problem. If there's nothing else, I'll repost the patch with this
change (hopefully the last time).
I also imple
Any feedback on this patch? Timur?
Regards,
David.
> -Original Message-
> From: David Saada
> Sent: Sunday, January 20, 2008 11:37 AM
> To: u-boot-users@lists.sourceforge.net
> Cc: 'Timur Tabi'
> Subject: [PATCH v3] QE IO: Add initial data to pin configurat
.
In addition, add IO pin read & write functions.
Signed-off-by: David Saada <[EMAIL PROTECTED]>
diff -purN a/include/ioports.h b/include/ioports.h
--- a/include/ioports.h 2008-01-02 13:39:04.0 +0200
+++ b/include/ioports.h 2008-01-06 10:20:40.342453000 +0200
@@ -60,6 +60,7 @@
> I see that qe_config_iopin() will always write a 0 or 1 now, ignoring the
> current value. Are you sure this is a good idea? What if I don't want U-Boot
> to change the current pin value?
Well, not sure how important this is, as this function is typically used
for port initialization. This was
On the MPC83xx & MPC85xx architectures that have QE, add initial data to
the pin configuration table (qe_iop_conf_tab). QE initialization tables
in all relevant boards were also replaced.
In addition, add IO pin read & write functions.
Signed-off-by: David Saada <[EMAIL PROTECTED]>
> I was able to apply this with a little manual tweaking. I had to
remove
> the '>' from in front
> of each "diff -purN", and change the following patterns:
>
> --- /file.orig
> +++ /file
>
> becomes:
>
> --- a/file
> +++ b/file
>
> I'll send a pull request tomorrow to pick this up.
>
> thank
> Hi David,
>
> On Wed, Jan 16, 2008 at 10:35:51AM +0200, David Saada wrote:
> >
> > Add MII commands to the UEC driver. Note that once a UEC device is
> > selected, any device on its MDIO bus can be addressed.
>
> Long ago I did something like that too (qu
> Andy,
> You are generally right. The good practice would be to modify the QE
> initialization tables for all relevant boards. There are 4 such
boards,
> and I can resubmit the patch to include them. Just please note that
this
> value is only relevant for general purpose I/O pins (defined as
outpu
Add MII commands to the UEC driver. Note that once a UEC device is
selected, any device on its MDIO bus can be addressed.
Signed-off-by: David Saada <[EMAIL PROTECTED]>
diff -purN a/drivers/qe/uec.c b/drivers/qe/uec.c
--- a/drivers/qe/uec.c 2008-01-14 11:48:28.0 +0200
+++ b/driv
> Does the lack of comments on this mean that people are happy with it,
> or that they haven't had a chance to consider it yet?
>
> Thanks
>
> Michael
Thumbs up on my end. Was going to implement it the same way...
David.
-
> > We have another source code repository (Synergy), and managing the
> > source code with git is just not possible. I have posted many
> > patches in
> > the past using diff -purN, and there was never any problem.
>
> Ok, maybe problem occur in my site.
>
> If Kim or Ben can apply it successful
have posted many patches in
the past using diff -purN, and there was never any problem.
> On Tue, 2008-01-15 at 10:40 +0200, David Saada wrote:
> > This patch extends the number of supported UECs to 4. Note that the
> > problem of QE thread resources exhaustion is resolved by setti
This patch extends the number of supported UECs to 4. Note that the
problem of QE thread resources exhaustion is resolved by setting the
correct number of QE threads according to Ethernet type (GBE or FE).
Signed-off-by: David Saada <[EMAIL PROTECTED]>
> diff -purN drivers/qe/uec.c.ori
Signed-off-by: David Saada <[EMAIL PROTECTED]>
> diff -purN drivers/qe/uec.c.orig drivers/qe/uec.c
--- drivers/qe/uec.c.orig 2008-01-14 11:48:28.0 +0200
+++ drivers/qe/uec.c2008-01-15 09:42:59.11887 +0200
@@ -40,8 +40,13 @@ static uec_info_t eth1
Description:
This patch extends the number of supported UECs to 4. Note that the
problem of QE thread resources exhaustion is resolved by setting the
correct number of QE threads according to Ethernet type (GBE or FE).
Signed-off-by: David Saada <[EMAIL PROTECTED]>
> diff -purN d
> David, I prefer to have two patch for this.
> One is the CMD_MII support
> The second is the extend UEC to 4.
No problem. Will split the patch. Merging is on you though :)
Regarding the MII support: This will include also a fix in the TSEC
driver to enable it to address all MII addresses on the
53 matches
Mail list logo
