Re: Linux issues on Xilinx XUPV2P board

[Jon Loeliger]

John Linn wrote:

Ah I see, sorry about that, misunderstood what was needed.

So there may be other ways as I'm not a Git expert, but I clone the
repository, then reset to the a Git tag.


git reset --hard 


We're working on a new frame buffer driver for a new core, but the old
frame buffer has not been high priority for us.

Thanks,
John 


While this "Works" in the sense that it makes your working
directory look like the contents of the given tag, you are
now using a "detached HEAD" -- ie, no real branch.

If you think you will ever want to make a change or check
in something, you might be better to create a branch based
on the original tag, perhaps something like:

   $ git checkout -b my-v2.6.24 v2.6.24

HTH,
jdl


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: [PATCH] RE: Some memory (DDR2 ECC Dual Rank) just doesn't work! Can anyone pointme to how to debug this hang?

[Jon Loeliger]

Vince Asbridge wrote:

Stephane,

Thanks so much for your prompt reply.

We will pursue your suggestions, and let the forum know what we find.  We're
at 1.3.0 uboot version.

Vince


-Original Message-
From: Fillod Stephane [mailto:[EMAIL PROTECTED] 
Sent: Thursday, August 14, 2008 8:06 AM

To: Vince Asbridge; linuxppc-embedded
Cc: [EMAIL PROTECTED]
Subject: [PATCH] RE: Some memory (DDR2 ECC Dual Rank) just 
doesn't work! Can anyone pointme to how to debug this hang?


Vince Asbridge wrote:
We have an 8548 design, which implements a DDR2 on a SODIMM 
We have an 
issue with dual rank memory (specific part number Viking 
VR5DR287218EBSS1), which is a 1G ECC Registered SODIMM part, 
with two ranks.
Our platform wires CS0 and CS1 to the SODIMM slot. 
At uBoot, all is well.  Memory is discovered as ECC 533, 1G 
DDR2 64Bit 4 beat bursts, and mtest can read and write all 1G 
of the SODIMM.

[...]
Other DDR2s (identical except for vendor and # of ranks), 
work perfectly! 
Anyone got a clue what I could look at to try to figure this out? 
We've tried enable / disable ECC at uboot We've tried 
enable / disable 
Interleaving at uboot uboot always works (and can read/write entire 
DDR), Linux always hangs on boot!
U-Boot is too gentle when testing SDRAM. Make sure the caches 
are enabled under U-Boot, and put on heavy stress with DMA, 
pipelined prefetch's, etc.
This is what your CPU is enduring under Linux. 


Your question is definitely a question for the U-Boot mailing list.
BTW, what is the version of U-Boot in use? U-Boot is still 
missing the following patch:


MPC85xx BA bits not set for 3-bit bank address DIMM of CS1

The current implementation set the number of bank address bits
(BA) in the processor for CS0 but not for CS1. 


Signed-off-by: Stephane Fillod <[EMAIL PROTECTED]>

--- u-boot/cpu/mpc85xx/spd_sdram.c
+++ u-boot/cpu/mpc85xx/spd_sdram.c
@@ -365,6 +365,7 @@
ddr->cs1_config = ( 1<<31
| (odt_rd_cfg << 20)
| (odt_wr_cfg << 16)
+   | (ba_bits << 14)
| (spd.nrow_addr - 12) << 8
| (spd.ncol_addr - 8) );
debug("DDR: cs1_bnds   = 0x%08x\n", ddr->cs1_bnds);



Otherwise, recompile with -DDEBUG and CFG_CMD_SDRAM, grab the 
Viking datasheet and a scope, and a full cup of coffee/tea 
much needed during cross-checking :-)





That bug fix, along with many, many others, as well as some
new support for multiple controllers and such are all present
in the DDR re-write patch set that Kumar just posted.  You may
want to try that code too.  It will be replacing the entire
85xx/86xx and eventually the 83xx line of memory controller
initialization.  It also contains some support for a pretty
useful interactive DDR configuration setup mechanism too.

jdl
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: Help: Kernel BUG with U-boot 1.1.4 and kernel 2.6.23 scanning PCIe on a MPC8641D board

[Jon Loeliger]

[EMAIL PROTECTED] wrote:


Hello folks,

we run a proprietary board with Freescale MPC8641D using U-boot 1.1.4 
and Linux kernel 2.6.23




I read in the logs some messages that 2.6.23 does contain some bugs 
related to PCIe


Correct.

and it would be a good choice to upgrade to 2.6.25. Is 
this one of that cases?


Almost certainly.  You should pick up top of tree if you can.


Currently we would like to prevent switching the kernel version.


You could back-port the PCIe bug fixes and rewrite if you wanted.
My guess is that a _trial_ run of the current top of tree,
or at least 2.6.26 might Just Work and fix your issues.

It would be less work to try it than do discover-n-back-port...

jdl
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: [PATCH] Add AMCC Arches DTS

[Jon Loeliger]

Victor Gallardo wrote:

 I used the glacier.dts file as a base line. Is the
glacier.dts file in dts-v1 format?


Does it start with a /dts-v1/ declaration?

jdl
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: [PATCH] fs_enet: restore promiscuous and multicast settings in restart()

[Jon Loeliger]

Vitaly Bordug wrote:

On Wed, 18 Jun 2008 22:45:57 +0400
"Matvejchikov Ilya" <[EMAIL PROTECTED]> wrote:


I'm glad that you have corrected it. Half a year ago I pointed out
that there was such a mistake:
http://patchwork.ozlabs.org/linuxppc/patch?id=10700

You've used -embedded ML, and patch wasn't noticed... 


*sigh*

We should merge the -embedded list into -dev
and retire the -embedded list finally.

jdl


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: Device tree for powerpc boards.

[Jon Loeliger]

Leonid wrote:

Hi:


Hi.


1) Is the usage of device tree absolutely mandatory for powerpc boards
or just recommended and by combining appropriate defines in u-boot and
linux it can be avoided? 


Consider it mandatory.


2) I understood that I can add my proprietary drivers without creating
nodes for them in the tree, is it correct?


Maybe, maybe not.  Device Trees describe _hardware_, not drivers.


3) In order to compile DT blob from DT source, DT compiler (dtc) is
required. I have installed one on my ubuntu machine and successfully
compiled source, creating a blob. Is this the only way to go? Perhaps
there is some target in Linux or u-boot Makefiles which does this job? 


Install the DTC anyway you want.  I recommend grabbing
it from jdl.com and building it.

jdl


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: PPC to PowerPC Migration

[Jon Loeliger]

vb wrote:

I recently ported two platforms (8245 and 8541) from ppc tree in
earlier 2.6 versions into powerpc tree in 2.6.25. It is amazing how
little the device tree contents are described, a lot of things
required reverse engineering of the kernel code to understand the
meaning of some numbers in the  tree.

I am also willing to contribute into a document describing this
transition, please keep me in the loop,

regards,
Vadim



Well, perhaps as a starting point you could tell us
which things required reverse engineering or what you
were not able to find in a document?

Thanks,
jdl
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: FP and signal 4

[Jon Loeliger]

Also sprach Zarathustra und Stefan Roese:
>
> I hope "-b 0" is set by default in recent dtc versions.

Und Git antwortete:

commit 548767f42eb00a2bac6f2a1361b7fd49f7b76908
Author: David Gibson <[EMAIL PROTECTED]>
Date:   Fri May 16 13:22:57 2008 +1000

dtc: Rework handling of boot_cpuid_phys

Currently, dtc will put the nonsense value 0xfeedbeef into the
boot_cpuid_phys field of an output blob, unless explicitly given
another value with the -b command line option.  As well as being a
totally unuseful default value, this also means that dtc won't
properly preserve the boot_cpuid_phys field in -I dtb -O dtb mode.

This patch reworks things to improve the boot_cpuid handling.  The new
semantics are that the output's boot_cpuid_phys value is:
the value given on the command line if -b is used
otherwise
the value from the input, if in -I dtb mode
otherwise
0

Implementation-wise we do the following:
- boot_cpuid_phys is added to struct boot_info, so that
structure now contains all of the blob's semantic information.
- dt_to_blob() and dt_to_asm() output the cpuid given in
boot_info
- dt_from_blob() fills in boot_info based on the input blob
- The other dt_from_*() functions just record 0, but we can
change this easily if e.g. we invent a way of specifying the boot cpu
in the source format.
- main() overrides the cpuid in the boot_info between input
and output if -b is given

We add some testcases to check this new behaviour.

Signed-off-by: David Gibson <[EMAIL PROTECTED]>
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: Sequoia build with KDBG

[Jon Loeliger]

Scott Wood wrote:

> There are ways of debugging that don't involve a debugger.

I suppose we could get all tautological and start claiming
that anything that helped one debug something might be, by
definition, a debugger. :-)

(de-)buggering off,
jdl

___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: MPC8641D PCI-Express error

[Jon Loeliger]

Marco Stornelli wrote:
> 
> When I try to read some register from my FPGA (virtex5) I have this bus
> error:


Hmmm  OK, so if we've eliminated PCI-E as a source
for this issue, it really must be in the Virtex support
somewhere then.  Unfortunately, I know nothing about those,
and am not going to be much direct help there.

Sorry.

jdl


> Machine check in kernel mode.
> Caused by (from SRR1=149030): Transfer error ack signal
> Oops: Machine check, sig: 7 [#1]
> PREEMPT SMP NR_CPUS=2
> Modules linked in: virtex5
> LTT NESTING LEVEL : 0
> NIP: F108019C LR: F1080198 CTR: 0001
> REGS: c044dd60 TRAP: 0200   Not tainted  (2.6.18-mpc8641d_hpcn)
> MSR: 00149030   CR: 22000222  XER: 
> TASK = c20e9990[568] 'insmod' THREAD: c044c000 CPU: 0
> GPR00: F1080198 C044DE10 C20E9990 002E 8000  8000
> 2EA3
> GPR08: C20E9990  C04C0220 C044C000 22000222 1001956C 
> 
> GPR16:       
> 
> GPR24: 3000EAA0 7FD6FDC0  C045FCC0 F107E594 F10A 
> C2036000
> NIP [F108019C] virtex5_probe+0x130/0x1c4 [virtex5]
> LR [F1080198] virtex5_probe+0x12c/0x1c4 [virtex5]
> Call Trace:
> [C044DE10] [F1080198] virtex5_probe+0x12c/0x1c4 [virtex5] (unreliable)
> [C044DE30] [C01D2A58] pci_device_probe+0x84/0xbc
> [C044DE50] [C0213754] driver_probe_device+0x60/0x118
> [C044DE70] [C0213890] __driver_attach+0x84/0x88
> [C044DE90] [C02130F4] bus_for_each_dev+0x58/0x94
> [C044DEC0] [C02135D4] driver_attach+0x24/0x34
> [C044DED0] [C0212AC8] bus_add_driver+0x88/0x164
> [C044DEF0] [C021397C] driver_register+0x70/0xb8
> [C044DF00] [C01D284C] __pci_register_driver+0x64/0x98
> [C044DF10] [F1080030] init_module+0x30/0x6c [virtex5]
> [C044DF20] [C004CBFC] sys_init_module+0xc8/0x25c
> [C044DF40] [C0011358] ret_from_syscall+0x0/0x38
> --- Exception: c00 at 0xff6de0c
> LR = 0x1de4
> Instruction dump:
> 40820060 3c60f108 3863cea0 48000311 807f0238 3c81 48000395 7c7d1b78
> 3c60f108 3863ced4 480002f5 809d <3c60f108> 3863cf04 480002e5 3c60f108

___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: MPC8641D PCI-Express error

[Jon Loeliger]

Timur Tabi wrote:
> Marco Stornelli wrote:
> 
>> No, it didn't. I have the same problem even with the 2.6.18 plus the
>> 2.6.24 PCI-Express code. I performed this action because I can't change
>> kernel version but I can modify it.
> 
> Please try 2.6.24 (or even better, 2.6.25-rc2).  You may have done something 
> wrong in back-porting the code to 2.6.18.  There's no reason why you can't at 
> least try the latest version of the code for testing purposes, even if you 
> can't 
> use it in production.
> 

Also, once you back-ported it and all the DTS changes, and all
the fsl_soc.c changes needed and , and, and otherwise made it
look _like_, 2.6.24 but still called it 2.6.18, after all that,
can you remind us what was the error or failure mode that you saw?

jdl

___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: mpc8548amc vs mpc8548cds

[Jon Loeliger]

maxime louvel wrote:
> Hi,
> 
> first of all I am sorry if this is not the good place to ask that but I 
> don't know where else ...
> My question is:
> 
> Does anyone knows the difference between the mpc8548amc and mpc8548cds 
> platforms ?

Sorry, no knowledge of the AMC board here.

> I am working on an amc one but the 2.6.24 kernel is supporting only the 
> cds one.
> Do you know if I can use the dts file form the mpc8548cds for the 
> mpc8548amc ?

They will be similar, but I doubt you can use it directly.

jdl
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: MPC8641D PCI-Express error

[Jon Loeliger]

Marco Stornelli wrote:

> No, but I can try to backport the PCI-E code from 2.6.24 to 2.6.18 if it
> could help. What do you think about it? Do you think this problem could
> be not present in 2.6.24?

I have no idea there, honestly.  Sorry.

jdl
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: MPC8641D PCI-Express error

[Jon Loeliger]

Marco Stornelli wrote:
> 
> Board: MPC8641D HPCN
> SoC: MPC8641D rev. 2

OK, this is good.

> Kernel: 2.6.18

And this is really old.  Any chance of up-rev'ing
that to something modern like 2.6.24?  You may find
that your PCI-E issues are Just Fixed there.  Dunno.

HTH,
jdl
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: 2.6.24 for mpc8458amc

[Jon Loeliger]

maxime louvel wrote:
> Thanks for your answer,
> 
> I am going to check this ppc / powerpc things.
> I should use the architecture powerpc, don't I?

ARCH == ppc is scheduled for _removal_ from the
entire Kernel source base is just about 4 months.
Feel free to move the deck chairs around. :-)

> I'm not really sure I have understand what do you want to do with a 
> BDI-2000.

Perhaps, for starters, you read "Building Embedded Linux Systems"
as found here:
http://www.oreilly.com/catalog/belinuxsys/

> I access the cards through a serial line directly.

Of course.  But when you get no information there,
you might try a different interface.

jdl
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: 2.6.24 for mpc8458amc

[Jon Loeliger]

maxime louvel wrote:
> Hi,
> 
> I am trying to make a 2.6.24 vanilla kernel boot (an work fine in a 
> second time) on a mpc8548amc board.
> I have add the platform specific stuff from the sources of the current 
> kernel running on the cards.
> What I have basically add is:
> - a folder mpc8548amc, in the config/platform directory, which allow to 
> select the mpc8548amc as the supported platform
> - add the following files:
>   - arch/ppc/configs/mpc8548amc_defconfig
>   - arch/ppc/configs/platforms/85xx/mpc_8548_amc.h and .c
> - I have used the dts of an another platform (mpc8548cds) which seems 
> quite the same, but I haven't got any confirmation of that yet.

Uh, let's clear up minor confusion here.  Are you using
ARCH=ppc or ARCH=powerpc?  I'm surprised to see that there
is mention of arch/ppc/... above.  Are you sure this is an
ARCH=ppc build?  You won't need a DTS file at all then.

But if you are using a DTS file, and I suspect you should,
then this is ARCH=powerpc.

> When I am booting the kernel image I get:
> 
> AMC=> dhcp 0x100 uImage.amc.2.6.24
> Speed: 1000, full duplex
> BOOTP broadcast 1
> DHCP client bound to address 10.255.255.2 
> Using eTSEC0 device
> TFTP from server 0.0.0.0 ; our IP address is 
> 10.255.255.2 ; sending through gateway 10.1.1.1 
> 
> Filename 'uImage.amc.2.6.24'.
> Load address: 0x100
> Loading: ##
> ###
> #
> #
> #
> #
> ###
> done
> Bytes transferred = 1802102 (1b7f76 hex)
> AMC=> bootm 0x100
> ## Booting image at 0100 ...
>   Image Name:   Linux-2.6.24
>   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>   Data Size:1802038 Bytes =  1.7 MB
>   Load Address: 
>   Entry Point:  
>   Verifying Checksum ... OK
>   Uncompressing Kernel Image ... OK
> 
> No further messages...
> 
> Does someone has an idea ?
> 
> thanks,
> Maxime
> 

Did you download a DTB file and use it on the bootm
command?  Nope.

This is really a FAQ failure mode.  Are you sure
you have the console set up properly?  Any chance
you can get to the __log_buf with a BDI-2000?

Thanks,
jdl
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: MPC8641D PCI-Express error

[Jon Loeliger]

Marco Stornelli wrote:
> Hi,
> 
> I'm working with the Freescale evaluation board MPC8641DHPCN and the
> VIRTEX5 evaluation board ML555 connected with the PCI-Express. When I
> try to read some register I have this problem:
> 
> Machine check in kernel mode.


Any chance you can tell us what rev anything is?
SoC, Board, Kernel?

Significant improvement went into the 2.6.24 kernel
development effort for many FSL PCI/PCI-E parts.

Thanks,
jdl
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: Moving from 2.6.14 (ppc) to 2.6.20 (powerpc): problems with PCI-PCI bridge

[Jon Loeliger]

Johan Borkhuis wrote:
> Hello,
> 
> I was using kernel version 2.6.14 (ppc) on a  MVME3100 board (MPC8540 
> processor). We are planning to move to 2.6.20 (powerpc), but I have some 
> problems with the initialization of a PCI-PCI bridge.
> Connected to the MVME3100 board is a PCI-PCI bridge (HiNT, PCI6150, 
> 3388:0022). When using the 2.6.14 kernel this bridge is initialized 
> correctly:  it is setup as bus-master, memory and IO are configured, and 
> the memory allocation on the PCI-bus is correct.
> When I use 2.6.20 (powerpc) the device is not configured correctly: 
> bus-master, memory and IO are not set, and the memory space of the 
> bridge on the PCI bus is set to the minimum value (0xf).
> I can correct these settings by modifying the PCI_COMMAND register to 
> set the bus-master, memory and IO. I change the size of the memory space 
> in pci_32.c, by forcing the size to the required setting in 
> pci_relocate_bridge_resource. But to be honest, I don't like this very 
> much: modifying registers like this should not be needed, so I guess 
> there is something wrong in my configuration or setup.
> 
> How can I fix this problem in a better way? What could be wrong with my 
> configuration?


There has been a fair amount of PCI setup reworking done
somewhat recently.  (.22 and .23, IIRC, and even .24).
It might be best if you can try 2.6.24.

jdl

___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: External Interrupt

[Jon Loeliger]

On Fri, 2008-02-01 at 13:43, Scott Wood wrote:
> Marco Stornelli wrote:
> > Yes you are right. The local bus is like i2c, but I've never seen a
> > device connected with i2c and described with a sub-node of i2c node in
> > the dts file,
> 
> Grep the dts directory for "[EMAIL PROTECTED]".

But be sure to inspect /dts-v1/-ness too.

Yes, yes, yes. I have a typo fix coming... :-)

jdl


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: Configuring Freecale ucc_geth without a PHY

[Jon Loeliger]

Steven Hein wrote:


> Is there a document anywhere that describes how to submit
> patches for the powerpc kernel?Or do I just create the patch
> (I'm learning about git right now...) again the paulus/powerpc.git
> tree, and send it to this list?
> 

Correct.  Don't just lean toward git, actually use it.
And paulus/powerpc.git is the right basis.

Send it to the [EMAIL PROTECTED] list, not here.

jdl
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: PPC vs POWERPC

[Jon Loeliger]

On Tue, 2008-01-15 at 11:07, Scott Wood wrote:
> On Tue, Jan 15, 2008 at 11:01:33AM -0600, Jon Loeliger wrote:
> > If it is the former group, 824x, perhaps some of the parts
> > in embedded6xx/ are usable?  
> 
> Not all 824x fall into that category; for example, 8248 is pq2.

Gah.  Of course.

>   Someone in marketing should be shot.

Photos, bullets or heroin? :-)

jdl


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: PPC vs POWERPC

[Jon Loeliger]

On Tue, 2008-01-15 at 04:38, Matias Sundman wrote:
>  >>Documentation/powerpc/booting-without-of.txt to find out what is
>  >>expected in the device tree.
> 
> Is there any more information on how the "of_*" ( e.g. of_node_put ,  
> of_find_node_by_type ) functions should be implemented in  the 
> "arch/powerpc/platforms/myplatform/myboard_setup.c" file
> or is the documentation the existing "*.c" c files under 
> arch/powerpc/platforms ?
> 
> Since I have a 82xx board I assume that "myboard_setup.c" file shall be 
> put under arch/powerpc/platforms/82xx.

Maybe.  Which 82xx is it?  There is a notable difference
between, say, the 824x boards and the 827x boards.  If it
is the latter, perhaps the existing 82xx/ pq2 or mpc8272
parts are already sufficient?

If it is the former group, 824x, perhaps some of the parts
in embedded6xx/ are usable?  Also note that I am working on
publishing an 824x StorCenter port under embedded6xx/ at
this time as well.  First patches were posted to linuxppc-dev
list at ozlabs.org.

HTH,
jdl


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: Differences between git tree

[Jon Loeliger]

On Thu, 2007-12-20 at 07:11, Bizhan Gholikhamseh (bgholikh) wrote:
> Hi,
> Could someone let me know what is the each of these git tree are?
> 
> http://opensource.freescale.com/pub/scm/linux-2.6-jdl.git
> AND
> http://www.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git

Hrm.  I suppose I should answer that one...

Use Paul's tree from kernel.org.

My tree on opensource.freescale.com was my random patches
and crud, being published so others could get a hold of them.
Anything of value there has been moved or integrated into
Paul or Linus' tree by now.

HTH,
jdl



___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: Xilinx devicetrees

[Jon Loeliger]

John Williams wrote:

> Well, copying multiple configuration files into the kernel is not ideal. 

Well, some advances in the DTC are being developed to help
mitigate the proliferation of DTS files there.  It's still
slow going, but we're working on it...

>   Surely a little perl or python script would do the trick?  DTS syntax 
> is pretty clean, 

Are you looking at the same DTS I am? :-)


> Another thing I suggested to Michal recently, perhaps we need 
> kernel/lib/libof to store common OF / DT handling code.  Much better 
> than duplicating it accross microblaze and PPC, and maybe other arch's 
> would also see the light..

Not sure exactly what you mean here, but there are libfdt
efforts in the DTC source repo already.  That code is being
used in U-Boot.  There is also already a shared library  of
OF/DT handling code in the kernel that is being used by
both PowerPC and SPARC today.  I believe there are plans to
head it towards the same libfdt as well.

>  That would also add a claim for the DTC to 
> go in scripts/

Which, for the record, I'm not really convinced is the
right thing to do yet.

> John

Thanks,
jdl

___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: use of fsl, in lite5200b.dts in git current

[Jon Loeliger]

Matt Sealey wrote:

> The orderable part numbers add 3 or 4 characters to the front and about
> 8 after. There is a difference between MPC7400 and PPC7400, and the
> low voltage versions, and the different clock speeds. Orderable part
> number for a recent G4 might be PPC7448B1333NL -

Yeah, part, stepping, variant, speed, etc.

> this is a ridiculous
> amount of specificity in a device tree, 

Except that some of that information _is_ specified
elsewhere in other properties.  Speed, for example.

> and it also does not match the
> datasheet (MPC7448 is the name of the chip).

Because the data sheets are _s_ reliable. :-)



> Indeed, so.. at some point we should all sit down and hammer out the
> major issues in describing something like the MPC5121E because right
> now Genesi has a vested interest in that.

You understand that _that_ is being worked on as we, er, speak?


> If we could all agree on how it should be mapped out, with an example
> tree which shows *every damn thing available* so platform developers
> can pick and choose and OF developers can use it as a reference, it
> would make a much happier process.

Right.  It's being nailed down, but it is a slow, community process...

> And then we can fix up the Efika to fit some definition of the new
> MPC5200 tree too.

*gasp*

> By the way while I was poking around the tree today I noticed that
> there is a PCI errata fixup handled by a Kconfig in there. Why?

Happens occasionally.  And other places as well.

> Surely
> this is something you check the PVR/SVR for and switch on that for
> a runtime solution, 

That's not always fine-grained enough to base a decision on it.

> and not trick users with the possibility of
> forgetting to enable some obscure "PCI errata fix" configuration
> item? (CONFIG_PPC_MPC5200_BUGFIX)

It should be in the defconfig. :-)

jdl


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: Problem booting linux with device tree table

[Jon Loeliger]

On Tue, 2007-09-18 at 03:06, Bartlomiej Sieka wrote:

> The following switches to dtc taken from
> http://www.denx.de/wiki/UBoot/UBootFdtInfo work for me:
> 
> dtc -b 0 -V 17 -R 4 -S 0x3000 -I dts -O dtb -f tqm5200.dts > tqm5200.dtb

-V 17 is the current default, btw.

jdl


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: version control for dts/dtb?

[Jon Loeliger]

On Sat, 2007-06-16 at 12:44, marty wrote:
> Is there a  wy to figure out the version of the dtb file I'm  using?
> At a minimum, it would be useful to have a node with the conversion time 
> stuck somewhere...
> 
> I ran dtc to convert binary to source, but that isn't necessarily what I 
> wanted to look at -- just a single date
> code would be sufficient...
> 
> marty


There is currently no direct version stamp in the
DTS or DTB files.  You may be able to derive some
knowledge by running a DTB file through the DTC
with the input file as "dtb" and looking at an
output file of DTS, though.  That is, "-I dtb -O dts"
and looking at it.

HTH,
jdl


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: [U-Boot-Users] Where do you find *.dtb files?

[Jon Loeliger]

On Thu, 2007-05-03 at 08:55, Alex Zeffertt wrote:

> ... but when I try to compile it I get an error:
> 
>   $ /opt/freescale/ltib/usr/bin/dtc -I dts -O dtb 
> powerpc/arch/powerpc/boot/dts/mpc832x_mds.dts
>   DTC: dts->dtb  on file "powerpc/arch/powerpc/boot/dts/mpc832x_mds.dts"
>   syntax error at line 14
>   FATAL ERROR: Couldn't read input tree
> 
> Perhaps my dtc is out of date - it came with the BSP from freescale which uses
> the 2.6.11 kernel.
> 
> Do you know where I can find an up to date dtc?  Is there any documentation 
> regarding its use?

Read:

linux-2.6/Documentation/powerpc/booting-without-of.txt

Get current DTC from:

www.jdl.com/git_repos

HTH,
jdl


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: How do external irq's get mapped?

[Jon Loeliger]

On Fri, 2007-04-27 at 12:03, Sergei Shtylyov wrote:
> Hello.
> 
> Charles Krinke wrote:
> 
> > Let me try a more simplified IRQ question a different way by only
> > referring to the 8541.
> 
> > There are 12 external interrupt sources, irq[0..11] and as I understand
> > it, they all go through one vector, ExternalInput set in
> > head_fsl_booke.S and this vector resolves to "do_IRQ()", which I believe
> > is in arch/powerpc/kernel/irq.c (not arch/ppc/kernel/...).
> 
> > I am striving to understand how mapping of these external pins
> > irq[0..11] gets to IRQ numbers as shown with "cat /proc/interrupts".
> 
> IIUC, the external IRQ #'s should follow those occupied by 32 internal 
> IRQs.
> But those shown in that file are "virtual" numbers, i.e. they got 
> re-mapped by the kernel as it sees fit (basically, it tries to assign the 
> same # to IRQs above 15 and remaps those below)

And remember, Ben distorted the IRQ World right about
somewhere in that time frame too.

Kumar, can you remind us?

> > Could someone point me at some references I can read to understand this
> > nuance of the 8541 in a linux-2.6.17.11 kernel, please.
> 
>I'm not sure arch/powerpc/ in 2.6.17 had the complete MPC8541 support...

Which might be a different way of saying "You should try the
current top of git or 2.6.21." :-)

jdl


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: IRQ questions & puzzles

[Jon Loeliger]

On Thu, 2007-04-26 at 13:36, Charles Krinke wrote:
> I have a linux-2.6.17.11 source tree that has configs for two boards.
> One has an 8241 and the other has an 8541. The kernel code works fine on
> the 8241, but appears to lock up in my custom driver in the 8541 when
> interrupts are enabled.

OK, let's back up a step.  The 8241 and the 8541 are
two very different parts.  Different PPC cores with very
different peripherals placed on two very likely different
boards as well.  So I am at a bit of a loss to understand
how you are comparing these two parts in casual comparison
like this.  You aren't suggesting that you are expecting
these to be the same in some way are you?

> What I see happening, based on using a BDI to go/halt after the apparent
> lockup is that the kernel is spinning around in routines like
> kernel/irq/handle.c:__do_IRQ and an associated
> arch/powerpc/kernel/irq.c.
> 
> It looks like the interrupt, which should be level triggered and at this
> point, is probably continuously asserted is causing the kernel to spin
> in a tight loop and be incapable of doing printk's out the serial port
> at 115200.
> 
> This leads to a few questions:

It certainly does! :-)

> 1. I can see most everything comes from arch/ppc, but do_IRQ comes from
> arch/powerpc. Is that OK?

"Most everything" for _which_ board?  The 8241 or the 8541?
Specifically, the former would easily still be arch/ppc based
while the latter _should_  be arch/powerpc based by now.
When compling arch/powerpc, only legacy #include files should
be being used during the build.

> 2. What is the most straightforward way to slow down a tight loop like
> this slow enough so I can printk what is happening.

Your BDI-2000, likely. :-)

> 3. What might be the likely scenarios leading to such a despicable
> state.

Initial PEBCAK, perhaps?  But yea, there may be a level difinition
problem on an line here.  Dunno yet, because the scenario seems a
bit strained or ill-described yet...

Any chance for a bit more clarity on what your situation is?

It seems to me that it is quite possible that many of these
issues might vanish with a 2.6.21 build straight up too.

HTH,
jdl


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: Powerpc newbie help

[Jon Loeliger]

On Fri, 2007-04-06 at 08:33, Gary Schumacher wrote:
>  
> 
> I am in the process of upgrading a Linux kernel from 2.4,20 to 2.6.20 on
> a proprietary board that uses the PPC 750Fx (without Open Firmware) and
> am having the following problems:

I'm afraid I can't speak to the 750.

> 1.  Is there more information on Device Trees so I can construct one
> myself?

Use emacs. :-)

>   I have been reading "Device trees everywhere" and
> "booting-without-of".  Also, there are a number of *.dts files in
> /arch/powerpc/boot/dts that I have been looking at but more
> examples/HowTo information would be helpful.

This is really about the extent of the documentation that
is available without going to the official Open Firmware
spec as well.  I recommend a large Cabernet Franc if you
go that route. :-)  It is a known deficiency and it is being
worked on, just not fast enough for some.  Please feel free
to post proposals or questions to the linuxppc-dev list too!

> 2.  I have downloaded dtc-2006419.tar and was wondering if there is a
> newer version or do I need patches for this and if so where would I
> look?

Please use git to obtain a current repository from jdl.com:

http://www.jdl.com/git_repos

git clone git://www.jdl.com/software/dtc.git

There is a newer tar file (dtc-20070216.tgz) in www.jdl.com/software
if you are unable to git clone the repo directly.

> 3.  Where do I find glr_parser which is required to build dtc?

Please update your flex and bison in particular.  If you do
not have a glr parser, your version is, like, years old now.

HTH,
jdl


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: U-boot with flat device tree

[Jon Loeliger]

On Wed, 2007-03-14 at 16:42, Benedict, Michael wrote:

> dtc- development snapshot "dtc-20060419.tar.gz" and recent git
> sources
> U-boot - 1.2.0, git sources from denx.de, and git sources from freescale
> Kernel - 2.6.20.1, 2.6.20.2, and freescale git sources

Do yourself a favor and get an updated DTC at some point:

http://www.jdl.com/git_repos/
http://www.jdl.com/software/dtc-20070216.tgz

Though the latter should have its Maintainer update it too. :-)

Thanks,
jdl


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: [PATCH] ppc: Add support for AMCC Taishan 440GX eval board

[Jon Loeliger]

So, like, the other day Benjamin Herrenschmidt mumbled:
> 
> Note that there are still things that we might want to change. For
> example, I think we really should look into adding a macro mecanism
> and/or an include mecanism to dtc so that we can do things like #include
>  to get the base processor/SoC definition and then
> "overlay" some properties on top of it (like emac phy mode etc...)

What do people prefer here?  Straight CPP pre-run?
Direct support built into dtc to do file-inclusion, macros?

Thoughts, opinions, suggestions, pre-NACKs, Cabernet Franc bribes?

jdl
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: How to use the device tree for lite5200

[Jon Loeliger]

On Wed, 2006-12-06 at 10:21, Grant Likely wrote:
> >
> > Add the -f flag to dtc to ignore the missing /chosen node error
> >
> > Use the "-O dtb" flag to output a fdt blob
> 
> Oh, and like Kumar said, you need the -V 0x10 flag to generate the
> correct blob version.

Oh, and, -V 0x10 is the default now with a current
top-of-git DTC too.  :-)

jdl


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: [RFC] Current Lite5200b patchset

[Jon Loeliger]

On Wed, 2006-11-01 at 02:39, Grant Likely wrote:

> You'll also need to get the lite5200 device tree patch for u-boot off the
> u-boot-users mailing list, and the device tree compiler from www.jdl.com.
> 
> Device tree is compiled w/:
> $ dtc -V 0x10 -f -O dtb arch/powerpc/boot/dts/lite5200b.dts > lite5200b.dtb

And note that I just made -V 0x10 the default!

jdl


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: [PATCH] General CHRP/MPC5K2 platform support patch

[Jon Loeliger]

On Fri, 2006-10-27 at 10:04, Nicolas DET wrote:

> > diff -uprN a/include/asm-powerpc/mpc52xx.h b/include/asm-powerpc/mpc52xx.h
> > --- a/include/asm-powerpc/mpc52xx.h 1970-01-01 01:00:00.0 +0100
> > +++ b/include/asm-powerpc/mpc52xx.h 2006-10-27 15:51:55.0 +0200
> > @@ -0,0 +1,414 @@
> > +/*
> > + * include/asm-ppc/mpc52xx.h
> > + * 
> 
> 
> Fixed to powerpc

I thought we were removing the names of files from
within the file itself, right?

Thanks,
jdl


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: How to move from /ppc/ to /powerpc/

[Jon Loeliger]

On Wed, 2006-09-13 at 08:28, Fredrik Roubert wrote:
> On Tue 12 Sep 17:58 CEST 2006, Kim Phillips wrote:
> 
> > The 8349EMDS device tree source is now in linux/arch/powerpc/boot/dts.
> 
> Is that the right dts to use for a MPC8349SYS board?
> 
> I tried compiling it like this:
> 
> $ dtc -f -I dts -O dtb mpc8349emds.dts > devices.dtb
> DTC: dts->dtb  on file "mpc8349emds.dts"
> Warning: No cpu has "linux,boot-cpu" property
> ERROR: Missing /chosen node
> Input tree has errors
> 
> Is that really correct? Should I invoke dtc in some other way or modify
> the dts or use some other dts file?

You must use the -V 16 flag too.  Likely, -b 0 as well.

jdl


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

How to move from /ppc/ to /powerpc/

[Jon Loeliger]

On Tue, 2006-09-12 at 10:58, Kim Phillips wrote:

> > I boot the board with U-Boot (version 1.1.4, customized), and I assume
> > that I need to add some stuff for this new device tree thing, but I
> > can't figure out exactly what the kernel will expect.
> 
> the kernel expects a pointer to a device tree instead of a bd_t.
> The 8349EMDS device tree source is now in linux/arch/powerpc/boot/dts.
> You'll need the device tree compiler (dtc) from jdl.com to build
> your flat device tree binary (dtb; what the kernel expects).

And you should read:

linux-2.6/Documentation/powerpc/booting-without-of.txt

jdl

Re: How to move from /ppc/ to /powerpc/

[Jon Loeliger]

On Tue, 2006-09-12 at 10:58, Kim Phillips wrote:

> > I boot the board with U-Boot (version 1.1.4, customized), and I assume
> > that I need to add some stuff for this new device tree thing, but I
> > can't figure out exactly what the kernel will expect.
> 
> the kernel expects a pointer to a device tree instead of a bd_t.
> The 8349EMDS device tree source is now in linux/arch/powerpc/boot/dts.
> You'll need the device tree compiler (dtc) from jdl.com to build
> your flat device tree binary (dtb; what the kernel expects).

And you should read:

linux-2.6/Documentation/powerpc/booting-without-of.txt

jdl


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

[RFC] consolidated libdt proposal

[Jon Loeliger]

On Tue, 2006-08-08 at 14:12, Matthew McClintock wrote:
> This is a patch to u-boot with the changes.
> 
> * Patch to modify ft_build.c to update flat device trees in place
>   Patch by Matthew McClintock 26-June-2006
> 
> Signed-off-by: Matthew McClintock 

Also FYI, I have assembled all Matt's 85xx related U-Boot patches,
along with the corresponding 86xx updates, into the u-boot-86xx.git
tree on:

http://jdl.com/git_repos/

This U-Boot separates out the DTS files, but allows the DTB
to be downloaded.  It can then update it and hand it off to
either an 85xx or 86xx linux kernel.

I use these commands, roughly:

# build U-boot and Linux as usual

$ dtc -f -V 0x10 -I dts -O dtb \
linux-2.6-86xx/arch/powerpc/boot/dts/mpc8641_hpcn.dts \
mpc8641_hpcn.dtb

In U-boot now:

> tftp 100 loeliger/uImage.8641
> tftp 90 loeliger/mpc8641_hpcn.dtb

> bootm 100 - 90

Enjoy,
jdl

Compilation error in fsl_soc.c

[Jon Loeliger]

On Mon, 2006-07-31 at 08:39, Vitaly Bordug wrote:
> On Mon, 31 Jul 2006 08:37:56 +0100
> "Demke Torsten-atd012"  wrote:
> 
> > Hi all,
> > 
> > with a recent versions from Paulus merge-tree the compilation
> > of MPC85xx CDS failed with following output:
> > ...

> 
> No, since it is just going to be out.
> 
> I'll submit some patches addressing that this week...

Vitaly,

I have just posted some patches on linuxppc-dev
for the 86xx that cover the fsl_soc.c breakage here.

Thanks,
jdl

Anybody applied the patch "Add 85xx CDS to arch/powerpc" on the 2.6.16. I failed to apply it:-(

[Jon Loeliger]

So, like, the other day "fengcheng lu" mumbled:
> 
> I downloaded this patch from
> http://patchwork.ozlabs.org/linuxppc/patch?id=3D4910. But I failed to apply
> it. The following is the output:
> debian:/usr/src/linux-2.6.16# patch -p1  patching file arch/powerpc/config/mpc85xx_cds_deconfig
> patching file arch/powerpc/platforms/85xx/Kconfig
> Hunk #1 FAILED at 11
> 1 out of 1 hunk FAILED -- saving rejects to file
> arch/powerpc/platforms/85xx/Kconfig.rej
> patching file arch/powerpc/platforms/85xx/Makefile
> Hunk #1 FAILED at 3
> 1 out of 1 hunk FAILED -- saving rejects to file
> arch/powerpc/platforms/85xx/Makefile.rej
> patching file arch/powerpc/platforms/85xx/mpc85xx_cds.c
> patching file arch/powerpc/platforms/85xx/mpc85xx_cds.h
> patching file include/asm-ppc/mpc85xx.h
> 
> It looks seem the Makefile and Kconfig don't match yours.

What was the repository against which you applied this patch?
Was it Linus' or Paul's?  I suspect it needs to be Paul's
powerpc.git repository.

HTH,
jdl

[PATCH] Add 85xx CDS to arch/powerpc

[Jon Loeliger]

So, like, the other day Arnd Bergmann mumbled:
> [MPIC]
> 
> Shouldn't all this come from the device tree?
> 
> ...
>
> > +/* PCI interrupt controller */
> > +#define PIRQ0A MPC85xx_IRQ_EXT0
> > +#define PIRQ0B MPC85xx_IRQ_EXT1
> > +#define PIRQ0C MPC85xx_IRQ_EXT2
> > +#define PIRQ0D MPC85xx_IRQ_EXT3
> > +#define PIRQ1A MPC85xx_IRQ_EXT11
> 
> And these as well, more importantly?

Yep.  In time they will.  However, the parsing of the
PIC nodes hasn't been added to the 85xx (uh, nor 83xx)
as of yet.

It is on "the list".

We should defer to Kumar to accepting these at this stage
or not.

jdl

[RFC] arch/ppc/boot/simple/embed_boot.c : Merging all keyvals parsing code

[Jon Loeliger]

On Tue, 2006-01-31 at 14:31, Peter Korsgaard wrote:
> > "Tom" == Tom Rini  writes:
> 
>  Tom> I would suggest either Linus' current git tree or 2.6.16-rc1 if
>  Tom> you don't use git.  But please bear in mind that since this is a
>  Tom> new feature (a new board) it won't be submitted to Linus' tree
>  Tom> until 2.6.17-rc1 opens up (and if in that time, it becomes much
>  Tom> easier to put this board under arch/powerpc it should be done
>  Tom> under there, instead).
> 
> I only recently moved from 2.4 to 2.6, so this may be a FAQ, but a
> quick googling around didn't find anything.
> 
> What is this arch/ppc -> arch/powerpc about? Some kind of
> consolidation of ppc and ppc64?

Exactly.

> What's the reason behind it

Eliminate duplicate code.  Share good code.
Improved modularity.  Leverage.  All the Good Stuff (tm).
Eliminate the bd_t mess.  You know.

> and what kind of time frame are we talking about?

In progress now.  All of the PPC64 ports are now officially
part of the "powerpc" arch.  There are two published PPC32
ports (MPC8349SYS and MPC8540ADS) that have been posted to
the list as being "merged" into the powerpc arch.  They are
still evolving a bit, though.

>  Is it related to the bd_t ->
> flattened OF tree change?

Yes.  New World Order says all arch/powerpc ports will 
use a common flat dev tree interface from boot loaders
unless honest OF is available.  The bd_t is obsolete.

> Could someone post a few pointers to more information? 

Read the "booting without open firmware" spec recently
patched from the DTC code tree to the linux doc directory
on the PPC64 list by Dave Gibson.

Read the Device Tree Compiler code itself too.

jdl

[PATCH] PPC32 mem_pieces interface cleanup

[Jon Loeliger]

Guys,

As an initial step towards getting the OF Flat Dev tree
handled in the PPC32 tree, this patch cleans up some of
the interface parts of the very early mem_pieces manager
and adds some PPC64-LMB-like routines as well.

It has been built and booted on 85xx and pmac boards.

Thanks,
jdl


Signed-off-by: Jon Loeliger 
Signed-off-by: Kumar Gala 


-- next part --
A non-text attachment was scrubbed...
Name: mem_pieces_cleanup.patch
Type: text/x-patch
Size: 9638 bytes
Desc: not available
Url : 
http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050627/ac4ea497/attachment.bin
 

More dtc changes

[Jon Loeliger]

On Thu, 2005-06-16 at 16:15, Jerry Van Baren wrote:

> > And, um, rats.  So, I'm the victim of an aggressive
> > and anti-social IT Firewall poo-poolicy  Or maybe I
> > am just being dumb and haven't Googled up the Right Magic.

Door number 3, I am dumb.

> > Is there a way to set an HTTP Proxy definition, flag,
> > parameter, environment variable, or other doo-dad that
> > will help me cg-pull/git-http-pull through my firewall?


> It ain't efficient and it is pull-only, but it works:

Good enough

> $ cg-clone http://www.ozlabs.org/~dgibson/dtc/dtc.git
> defaulting to local storage area
> 17:13:12 
> URL:http://www.ozlabs.org/%7Edgibson/dtc/dtc.git/refs/heads/master
> [41/41] -> "refs/heads/origin" [1]
> progress: 40 objects, 59841 bytes

Hmmm... So, I tested this mess again.  This time, I did
NOT use our stupid SOCKS proxy, but rather the built-in
HTTP proxy foo sort of like this in an environment variable
sort of like this:

setenv http_proxy http://$user:[EMAIL PROTECTED]:$proxy_port

cashmere.sps.mot.com 894 % socksify cg-pull origin
loeliger at 192.88.158.50.1090 sockspassword: 
cg-pull: objects pull failed

cashmere.sps.mot.com 895 % cg-pull origin
16:24:36 
URL:http://www.ozlabs.org/%7Edgibson/dtc/dtc.git/refs/heads/master [41/41] -> 
"refs/heads/origin" [1]
FINISHED --16:24:48--

And then it just stupidly worked.

Pay no attention to my questions,
jdl

More dtc changes

[Jon Loeliger]

On Thu, 2005-06-16 at 02:08, David Gibson wrote:
> I now have a git tree for the device tree compiler up at
> http://www.ozlabs.org/~dgibson/dtc/dtc.git

Very Cool!

And, um, rats.  So, I'm the victim of an aggressive
and anti-social IT Firewall poo-poolicy  Or maybe I
am just being dumb and haven't Googled up the Right Magic.

Is there a way to set an HTTP Proxy definition, flag,
parameter, environment variable, or other doo-dad that
will help me cg-pull/git-http-pull through my firewall?

Alternatively, any chance we can convert it to, or add,
an rsync tree?

> There's a tarball release as well
> http://www.ozlabs.org/~dgibson/dtc/dtc.tar.gz

If not, I'll have to be doing the tarball thing...

Thanks,
jdl

Discuss: Adding OF Flat Dev Tree to ppc32

[Jon Loeliger]

On Tue, 2005-06-07 at 22:06, Benjamin Herrenschmidt wrote:

> It's basically used to extract some infos directly from the flattened
> tree in order to construct the LMB list (list of memory blocks,
> equivalent of ppc32's mem_pieces), 


OK.  So the unflattenting process requires a small amount
of memory allocation which is currently implemented using
the lmb mechanism in PPC64 land.

As you indicate, there is also the mem_pieces implementation
over in ppc32 land.  I think it is currently only used by
arch/ppc/platforms/pmac_setup.c.


In porting this code over to PPC32 land, there are roughly
three choices:

   1) Copy the LMB implementation from ppc64 over to PPC32 land,

   2) Change the unflattening code in PPC32 to use mem_pieces,
  or rewrite it to allow a configurable choice between
  LMB and mem_pieces,
or
   3) Make up something new, yet very similar to LMB and
  mem_pieces.

Does anyone have suggestions or advice on route 1) or 2)?
Anyone?  Kumar?  Ben?  Bueller?

Thanks,
jdl

Discuss: Adding OF Flat Dev Tree to ppc32

[Jon Loeliger]

Ben and Folks,

I've read through ppc64/kernel/prom.c and done some minor
call-chain analysis rooted at the two functions:
early_init_devtree()
unflatten_device_tree()
as they are apparently the only two referenced in the
initial early boot up process.

My notion was to take the portion of prom.c rooted at
these two functions and add them to the ppc32 line.

First, what portions of pp64/kernel/prom.c are obsolete?
Anything?  You alluded to cleaning this up some, but I
am not too familiar with it to know where that was headed.

Second, there is already a fairly similar prom.c file
hanging out over in ppc32 land.  I _think_ it houses
roughly the complementary code out of ppc64's prom.c
that is NOT derived from the call chain derived from
the above two functions.

Which leads me to the questions:  Is there, or should
we create, a plan to factor the flat-dev-tree handling
code into common or shared ppc code?  I am reluctant
to just outright clone and copy that code if it will
ultimately "be the same" or even "mostly the same".
It seems that the early_init_devtree() might then need
to be refactored or duplicated for ppc32-land.

Are you anticipating the same r3,r4,r5 interface outlined
in your 0.4 rev of the ppc4 OF spec to be used by the
ppc32 world as well?  Seems like it just might...

Naturally, I'm willing to jump in here, just looking
for a bit of global-direction from you. :-)

jdl

Booting the linux-ppc64 kernel & flattened device tree v0.4

[Jon Loeliger]

On Wed, 2005-06-01 at 03:26, Benjamin Herrenschmidt wrote:
> DO NOT REPLY TO ALL LISTS PLEASE ! (and CC me on replies).
> 
> Here's the fourth version of my document along with new kernel patches
> for the new improved flattened format, and the first release of the
> device-tree "compiler" tool. The patches will be posted as a reply to
> this email. The compiler, dtc, can be downloaded, the URL is in the
> document.
> 
> ---

> 
> dtc source code can be found at 

Ben,

Here are diffs to:

- Fix multi-line C-style comments.

- Adjust the output of write_tree_source() such that it
  separates properties and nodes a bit better.

Thanks,
jdl


diff -u dtc.orig/dtc-lexer.l dtc/dtc-lexer.l
--- dtc.orig/dtc-lexer.l2005-06-01 11:44:29.02000 -0500
+++ dtc/dtc-lexer.l 2005-06-01 13:39:56.01000 -0500
@@ -34,8 +34,6 @@
 
 #include "y.tab.h"
 
-#undef LEXDEBUG1
-
 %}
 
 \"[^"]*\"  {
@@ -102,7 +100,7 @@
 
 <*>{WS}+   /* eat whitespace */
 
-<*>\/\*[^*]*(\*[^/][^*])*\*\/  /* eat comments */
+<*>\/\*([^*]|\**[^*/])*\*+\/   /* eat C comments */
 
 <*>\/\/.*\n/* eat line comments */
 
diff -u dtc.orig/treesource.c dtc/treesource.c
--- dtc.orig/treesource.c   2005-06-01 11:44:29.02000 -0500
+++ dtc/treesource.c2005-06-01 13:58:33.01000 -0500
@@ -131,10 +131,16 @@
break;
}
}
-   fprintf(f, "\n");
+   if (tree->children) {
+   fprintf(f, "\n");
+   }
for_each_child(tree, child) {
write_tree_source(f, child, level+1);
}
write_prefix(f, level);
fprintf(f, "};\n");
+
+   if (tree->next_sibling) {
+   fprintf(f, "\n");
+   }
 }

Booting the linux-ppc64 kernel & flattened device tree v0.4

[Jon Loeliger]

On Wed, 2005-06-01 at 03:26, Benjamin Herrenschmidt wrote:
> Here's the fourth version of my document along with new kernel patches
> for the new improved flattened format, and the first release of the
> device-tree "compiler" tool. The patches will be posted as a reply to
> this email. The compiler, dtc, can be downloaded, the URL is in the
> document.

Ben,

Does it make sense to do this as well?

Thanks,
jdl


diff -Nur dtc.orig/lsprop.c dtc/lsprop.c
--- dtc.orig/lsprop.c   1969-12-31 18:00:00.0 -0600
+++ dtc/lsprop.c2005-06-01 11:43:01.02000 -0500
@@ -0,0 +1,221 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+int recurse;
+int maxbytes = 128;
+int words_per_line = 0;
+char *buf;
+
+void lsprop(FILE *f, char *name);
+void lsdir(char *name);
+
+main(int ac, char **av)
+{
+FILE *f;
+int i;
+struct stat sb;
+char *endp;
+
+while ((i = getopt(ac, av, "Rm:w:")) != EOF) {
+   switch (i) {
+   case 'R':
+   recurse = 1;
+   break;
+   case 'm':
+   maxbytes = strtol(optarg, &endp, 0);
+   if (endp == optarg) {
+   fprintf(stderr, "%s: bad argument (%s) to -m option\n", av[0],
+   optarg);
+   exit(1);
+   }
+   maxbytes = (maxbytes + 15) & -16;
+   break;
+   case 'w':
+   words_per_line = strtol(optarg, &endp, 0);
+   if (endp == optarg) {
+   fprintf(stderr, "%s: bad argument (%s) to -w option\n",
+   av[0], optarg);
+   exit(1);
+   }
+   break;
+   }
+}
+
+buf = malloc(maxbytes);
+if (buf == 0) {
+   fprintf(stderr, "%s: virtual memory exhausted\n", av[0]);
+   exit(1);
+}
+
+if (optind == ac)
+   lsdir(".");
+else
+   for (i = optind; i < ac; ++i) {
+   if (stat(av[i], &sb) < 0) {
+   perror(av[i]);
+   continue;
+   }
+   if (S_ISREG(sb.st_mode)) {
+   f = fopen(av[i], "r");
+   if (f == NULL) {
+   perror(av[i]);
+   continue;
+   }
+   lsprop(f, av[i]);
+   fclose(f);
+   } else if (S_ISDIR(sb.st_mode)) {
+   lsdir(av[i]);
+   }
+   }
+exit(0);
+}
+
+void lsdir(char *name)
+{
+DIR *d;
+struct dirent *de;
+char *p, *q;
+struct stat sb;
+FILE *f;
+int np = 0;
+
+d = opendir(name);
+if (d == NULL) {
+   perror(name);
+   return;
+}
+
+p = malloc(strlen(name) + 520);
+if (p == 0) {
+   fprintf(stderr, "%s: virtual memory exhausted\n", name);
+   closedir(d);
+   return;
+}
+strcpy(p, name);
+q = p + strlen(p);
+while (q > p && q[-1] == '/')
+   --q;
+if (q == p + 1 && p[0] == '.')
+   q = p;
+else
+   *q++ = '/';
+
+while ((de = readdir(d)) != NULL) {
+   if (strcmp(de->d_name, ".") == 0 || strcmp(de->d_name, "..") == 0)
+   continue;
+   strcpy(q, de->d_name);
+   if (stat(p, &sb) < 0) {
+   perror(p);
+   continue;
+   }
+   if (S_ISREG(sb.st_mode)) {
+   f = fopen(p, "r");
+   if (f == NULL) {
+   perror(p);
+   } else {
+   lsprop(f, de->d_name);
+   fclose(f);
+   ++np;
+   }
+   }
+}
+rewinddir(d);
+while ((de = readdir(d)) != NULL) {
+   if (strcmp(de->d_name, ".") == 0 || strcmp(de->d_name, "..") == 0)
+   continue;
+   strcpy(q, de->d_name);
+   if (lstat(p, &sb) < 0) {
+   perror(p);
+   continue;
+   }
+   if (S_ISDIR(sb.st_mode)) {
+   if (np)
+   printf("\n");
+   printf("%s:\n", p);
+   lsdir(p);
+   ++np;
+   }
+}
+free(p);
+closedir(d);
+}
+
+void lsprop(FILE *f, char *name)
+{
+int n, nw, npl, i, j;
+
+n = fread(buf, 1, maxbytes, f);
+if (n < 0) {
+   printf("%s: read error\n", name);
+   return;
+}
+printf("%-16s", name);
+if (strlen(name) > 16)
+   printf("\n\t\t");
+for (i = 0; i < n; ++i)
+   if (buf[i] >= 0x7f ||
+   (buf[i] < 0x20 && buf[i] != '\r' && buf[i] != '\n'
+&& buf[i] != '\t' && buf[i] != 0))
+   break;
+if (i == n && n != 0 && (n == 1 || buf[0] != 0) && buf[n-1] == 0) {
+   printf(" \"");
+   for (i = 0; i < n - 1; ++i)
+   if (buf[i] == 0)
+   printf("\"\n\t\t \"");
+   else if (buf[i] == '\r' || buf[i] == '\n')
+   printf("\n\t\t ");
+   else
+   putchar(buf[i]);
+   putchar('"');
+} else if ((n & 3) == 0) {
+   nw = n >> 2;
+   if (nw == 1) {
+   i = *(int *)buf;
+   printf(" %.8x", i);
+   if (i > -0x1 && !(i >= 0 && i <= 9))
+   printf(" (%d)", i);
+   } else {

bd_t Cleaning: Interface Part

[Jon Loeliger]

On Mon, 2005-05-30 at 05:13, Clemens Koller wrote:
> Hello, Jon!
> 
> I guess there is a little typo:
> spped -> speed?

Rats.

Thanks for looking into the mess, and catching that!

jdl

bd_t Cleaning: System Parts

[Jon Loeliger]

On Thu, 2005-05-26 at 18:08, Kumar Gala wrote:
> Jon,
> 
> Can you break the patch up into a few pieces, it will be easier to 
> review that way.  Here are the following pieces that make sense to me:
> 
> 0. New firmware interface (fw_bdt*, Kconfig, ...)
> 1. board code changes (everything in arch/ppc/platforms/*)
> 2. driver changes (things in *_io, ide, net, serial dirs -- try to give 
> a better list below)
> 3. System changes (files in arch/ppc/syslib and include/asm-ppc)

And the final quarter, the System Bits:

 ppc/syslib/cpm2_common.c|3 
 ppc/syslib/m8260_pci.h  |6 
 ppc/syslib/m8260_setup.c|   31 -
 ppc/syslib/m8xx_setup.c |   27 -
 ppc/syslib/m8xx_wdt.c   |8 
 ppc/syslib/m8xx_wdt.h   |2 
 ppc/syslib/mpc52xx_setup.c  |   15 
 ppc/syslib/ppc4xx_setup.c   |   18 
 ppc/syslib/ppc83xx_setup.c  |   28 -
 ppc/syslib/ppc83xx_setup.h  |1 
 ppc/syslib/ppc85xx_setup.c  |   56 +-
 ppc/syslib/ppc85xx_setup.h  |1 
 asm-ppc/bseip.h |   13 
 asm-ppc/ibm4xx.h|   17 
 asm-ppc/ibm_ocp.h   |3 
 asm-ppc/mpc52xx.h   |4 
 asm-ppc/mpc8260.h   |7 
 asm-ppc/mpc83xx.h   |5 
 asm-ppc/mpc85xx.h   |5 
 asm-ppc/mpc8xx.h|7 

Index: arch/ppc/syslib/cpm2_common.c
===
--- c7d7a187a2125518e655dfeadffd38156239ffc3/arch/ppc/syslib/cpm2_common.c  
(mode:100644)
+++ eb4292a8874abcc926f536de90af0bdb001cf12e/arch/ppc/syslib/cpm2_common.c  
(mode:100644)
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static void cpm2_dpinit(void);
 cpm_cpm2_t *cpmp;  /* Pointer to comm processor space */
@@ -67,7 +68,7 @@
  * Baud rate clocks are zero-based in the driver code (as that maps
  * to port numbers).  Documentation uses 1-based numbering.
  */
-#define BRG_INT_CLK(((bd_t *)__res)->bi_brgfreq)
+#define BRG_INT_CLK(fw_get_brgfreq())
 #define BRG_UART_CLK   (BRG_INT_CLK/16)
 
 /* This function is used by UARTS, or anything else that uses a 16x
Index: arch/ppc/syslib/m8260_pci.h
===
--- c7d7a187a2125518e655dfeadffd38156239ffc3/arch/ppc/syslib/m8260_pci.h  
(mode:100644)
+++ eb4292a8874abcc926f536de90af0bdb001cf12e/arch/ppc/syslib/m8260_pci.h  
(mode:100644)
@@ -26,9 +26,9 @@
  */
 
 #ifndef MPC826x_PCI_SLAVE_MEM_LOCAL
-#define MPC826x_PCI_SLAVE_MEM_LOCAL(((struct bd_info *)__res)->bi_memstart)
-#define MPC826x_PCI_SLAVE_MEM_BUS  (((struct bd_info *)__res)->bi_memstart)
-#define MPC826x_PCI_SLAVE_MEM_SIZE (((struct bd_info *)__res)->bi_memsize)
+#define MPC826x_PCI_SLAVE_MEM_LOCAL(fw_get_memory_start())
+#define MPC826x_PCI_SLAVE_MEM_BUS  (fw_get_memory_start())
+#define MPC826x_PCI_SLAVE_MEM_SIZE (fw_get_memory_size())
 #endif
 
 /* 
Index: arch/ppc/syslib/m8260_setup.c
===
--- c7d7a187a2125518e655dfeadffd38156239ffc3/arch/ppc/syslib/m8260_setup.c  
(mode:100644)
+++ eb4292a8874abcc926f536de90af0bdb001cf12e/arch/ppc/syslib/m8260_setup.c  
(mode:100644)
@@ -28,11 +28,10 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "cpm2_pic.h"
 
-unsigned char __res[sizeof(bd_t)];
-
 extern void cpm2_reset(void);
 extern void m8260_find_bridges(void);
 extern void idma_pci9_init(void);
@@ -71,10 +70,9 @@
 static void __init
 m8260_calibrate_decr(void)
 {
-   bd_t *binfo = (bd_t *)__res;
int freq, divisor;
 
-   freq = binfo->bi_busfreq;
+   freq = fw_get_busfreq();
 divisor = 4;
 tb_ticks_per_jiffy = freq / HZ / divisor;
tb_to_us = mulhwu_scale_factor(freq / divisor, 100);
@@ -109,7 +107,7 @@
 static void
 m8260_restart(char *cmd)
 {
-   extern void m8260_gorom(bd_t *bi, uint addr);
+   extern void m8260_gorom(void *bi, uint addr);
uintstartaddr;
 
/* Most boot roms have a warmstart as the second instruction
@@ -122,7 +120,7 @@
startaddr = simple_strtoul(&cmd[10], NULL, 0);
}
 
-   m8260_gorom((void*)__pa(__res), startaddr);
+   m8260_gorom((void*)__pa(fw_get_init_data()), startaddr);
 }
 
 static void
@@ -141,9 +139,8 @@
 static int
 m8260_show_cpuinfo(struct seq_file *m)
 {
-   bd_t *bp = (bd_t *)__res;
-
-   seq_printf(m, "vendor\t\t: %s\n"
+   seq_printf(m,
+  "vendor\t\t: %s\n"
   "machine\t\t: %s\n"
   "\n"
   "mem size\t\t: 0x%08x\n"
@@ -152,9 +149,13 @@
   "core clock\t: %u MHz\n"
   "CPM  clock\t: %u MHz\n"
   "bus  clock\t: %u MHz\n",
-  CPUINFO_VENDOR, CPUINFO_

bd_t Cleaning: Driver Bits

[Jon Loeliger]

On Thu, 2005-05-26 at 18:08, Kumar Gala wrote:
> Jon,
> 
> Can you break the patch up into a few pieces, it will be easier to 
> review that way.  Here are the following pieces that make sense to me:
> 
> 0. New firmware interface (fw_bdt*, Kconfig, ...)
> 1. board code changes (everything in arch/ppc/platforms/*)
> 2. driver changes (things in *_io, ide, net, serial dirs -- try to give 
> a better list below)
> 3. System changes (files in arch/ppc/syslib and include/asm-ppc)

And Part 3 of 4 is the Driver Bits:


 ppc/8260_io/enet.c  |9 
 ppc/8260_io/fcc_enet.c  |   15 
 ppc/8xx_io/commproc.c   |3 
 ppc/8xx_io/enet.c   |   10 
 ppc/8xx_io/fec.c|8 
 ide/ppc/mpc8xx.c|   14 
 mtd/maps/tqm8xxl.c  |7 
 net/fec.c   |6 
 net/fec_8xx/fec_8xx-netta.c |5 
 net/oaknet.c|6 
 serial/68360serial.c|3 
 serial/cpm_uart/cpm_uart_core.c |8 
 serial/cpm_uart/cpm_uart_cpm1.c |   13 
 serial/cpm_uart/cpm_uart_cpm2.c |   13 
 serial/mpc52xx_uart.c   |   11 

Index: arch/ppc/8260_io/enet.c
===
--- c7d7a187a2125518e655dfeadffd38156239ffc3/arch/ppc/8260_io/enet.c  
(mode:100644)
+++ eb4292a8874abcc926f536de90af0bdb001cf12e/arch/ppc/8260_io/enet.c  
(mode:100644)
@@ -47,6 +47,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * Theory of Operation
@@ -614,9 +615,8 @@
struct scc_enet_private *cep;
int i, j, err;
uint dp_offset;
-   unsigned char   *eap;
+   unsigned char   *eap, *p_addr;
unsigned long   mem_addr;
-   bd_t*bd;
volatilecbd_t   *bdp;
volatilecpm_cpm2_t  *cp;
volatilescc_t   *sccp;
@@ -629,8 +629,6 @@
immap = (cpm2_map_t *)CPM_MAP_ADDR; /* and to internal registers */
io = &immap->im_ioport;
 
-   bd = (bd_t *)__res;
-
/* Create an Ethernet device instance.
*/
dev = alloc_etherdev(sizeof(*cep));
@@ -735,9 +733,10 @@
 * This is supplied in the board information structure, so we
 * copy that into the controller.
 */
+   p_addr = fw_get_enetaddr(0);
eap = (unsigned char *)&(ep->sen_paddrh);
for (i=5; i>=0; i--)
-   *eap++ = dev->dev_addr[i] = bd->bi_enetaddr[i];
+   *eap++ = dev->dev_addr[i] = p_addr[i];
 
ep->sen_pper = 0;   /* 'cause the book says so */
ep->sen_taddrl = 0; /* temp address (LSB) */
Index: arch/ppc/8260_io/fcc_enet.c
===
--- c7d7a187a2125518e655dfeadffd38156239ffc3/arch/ppc/8260_io/fcc_enet.c  
(mode:100644)
+++ eb4292a8874abcc926f536de90af0bdb001cf12e/arch/ppc/8260_io/fcc_enet.c  
(mode:100644)
@@ -47,6 +47,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* We can't use the PHY interrupt if we aren't using MDIO. */
 #if !defined(CONFIG_USE_MDIO)
@@ -1866,9 +1867,8 @@
 init_fcc_param(fcc_info_t *fip, struct net_device *dev,
volatile cpm2_map_t *immap)
 {
-   unsigned char   *eap;
+   unsigned char   *eap, *p_addr;
unsigned long   mem_addr;
-   bd_t*bd;
int i, j;
struct  fcc_enet_private *cep;
volatilefcc_enet_t  *ep;
@@ -1879,8 +1879,6 @@
ep = cep->ep;
cp = cpmp;
 
-   bd = (bd_t *)__res;
-
/* Zero the whole thing.I must have missed some individually.
 * It works when I do this.
 */
@@ -1962,6 +1960,7 @@
 * it unique by setting a few bits in the upper byte of the
 * non-static part of the address.
 */
+   p_addr = fw_get_enetaddr(0);
eap = (unsigned char *)&(ep->fen_paddrh);
for (i=5; i>=0; i--) {
 
@@ -1971,22 +1970,22 @@
  */
 #ifdef CONFIG_SBC82xx
if (i == 5) {
-   /* bd->bi_enetaddr holds the SCC0 address; the FCC
+   /* p_addr holds the SCC0 address; the FCC
   devices count up from there */
-   dev->dev_addr[i] = bd->bi_enetaddr[i] & ~3;
+   dev->dev_addr[i] = p_addr[i] & ~3;
dev->dev_addr[i] += 1 + fip->fc_fccnum;
*eap++ = dev->dev_addr[i];
}
 #else
 #ifndef CONFIG_RPX8260
if (i == 3) {
-   dev->dev_addr[i] = bd->bi_enetaddr[i];
+   dev->dev_addr[i] = p_addr[i];
dev->dev_addr[i] |= (1 << (7 - fip->fc_fccnum));
*eap++ = dev->dev_addr[i];
} else
 #endif
 

bd_t Cleaning: Board Changes

[Jon Loeliger]

On Thu, 2005-05-26 at 18:08, Kumar Gala wrote:
> Jon,
> 
> Can you break the patch up into a few pieces, it will be easier to 
> review that way.  Here are the following pieces that make sense to me:
> 
> 0. New firmware interface (fw_bdt*, Kconfig, ...)
> 1. board code changes (everything in arch/ppc/platforms/*)
> 2. driver changes (things in *_io, ide, net, serial dirs -- try to give 
> a better list below)
> 3. System changes (files in arch/ppc/syslib and include/asm-ppc)

Part Two of Four, the Board Changes.

 ppc/platforms/4xx/ash.h |   21 -
 ppc/platforms/4xx/bubinga.c |4 
 ppc/platforms/4xx/bubinga.h |   23 -
 ppc/platforms/4xx/cpci405.h |2 
 ppc/platforms/4xx/ebony.c   |9 
 ppc/platforms/4xx/ep405.c   |   12 
 ppc/platforms/4xx/ep405.h   |   13 
 ppc/platforms/4xx/luan.c|7 
 ppc/platforms/4xx/oak.c |   15 
 ppc/platforms/4xx/oak.h |   19 -
 ppc/platforms/4xx/oak_setup.h   |2 
 ppc/platforms/4xx/ocotea.c  |   13 
 ppc/platforms/4xx/redwood5.h|   13 
 ppc/platforms/4xx/redwood6.c|   27 -
 ppc/platforms/4xx/redwood6.h|   13 
 ppc/platforms/4xx/sycamore.h|   22 -
 ppc/platforms/4xx/walnut.h  |   22 -
 ppc/platforms/4xx/xilinx_ml300.h|   12 
 ppc/platforms/83xx/mpc834x_sys.c|   49 +-
 ppc/platforms/83xx/mpc834x_sys.h|1 
 ppc/platforms/85xx/mpc8540_ads.c|   57 ++-
 ppc/platforms/85xx/mpc8560_ads.c|   21 -
 ppc/platforms/85xx/mpc85xx_ads_common.c |   10 
 ppc/platforms/85xx/mpc85xx_ads_common.h |1 
 ppc/platforms/85xx/mpc85xx_cds_common.c |   48 +-
 ppc/platforms/85xx/mpc85xx_cds_common.h |1 
 ppc/platforms/85xx/sbc8560.c|   19 -
 ppc/platforms/85xx/sbc85xx.c|   14 
 ppc/platforms/85xx/sbc85xx.h|1 
 ppc/platforms/85xx/stx_gp3.c|   34 -
 ppc/platforms/85xx/stx_gp3.h|1 
 ppc/platforms/bseip.h   |   13 
 ppc/platforms/ccm.h |2 
 ppc/platforms/cpci690.h |   10 
 ppc/platforms/est8260.h |   18 
 ppc/platforms/fads.h|2 
 ppc/platforms/hdpu.c|   13 
 ppc/platforms/hermes.h  |2 
 ppc/platforms/ip860.h   |2 
 ppc/platforms/ivms8.h   |2 
 ppc/platforms/katana.c  |6 
 ppc/platforms/lantec.h  |2 
 ppc/platforms/lite5200.c|9 
 ppc/platforms/lwmon.h   |2 
 ppc/platforms/mbx.h |   22 -
 ppc/platforms/pcu_e.h   |2 
 ppc/platforms/pq2ads.c  |1 
 ppc/platforms/pq2ads.h  |2 
 ppc/platforms/radstone_ppc7d.c  |   32 -
 ppc/platforms/radstone_ppc7d.h  |2 
 ppc/platforms/rpx8260.h |   19 -
 ppc/platforms/rpxclassic.h  |   13 
 ppc/platforms/rpxlite.h |   13 
 ppc/platforms/sandpoint.c   |   11 
 ppc/platforms/sandpoint.h   |2 
 ppc/platforms/sbc82xx.c |6 
 ppc/platforms/sbc82xx.h |2 
 ppc/platforms/sbs8260.h |   18 
 ppc/platforms/spd8xx.h  |2 
 ppc/platforms/tqm8260.h |2 
 ppc/platforms/tqm8260_setup.c   |1 
 ppc/platforms/tqm8xx.h  |2 

Index: arch/ppc/platforms/4xx/ash.h
===
--- c7d7a187a2125518e655dfeadffd38156239ffc3/arch/ppc/platforms/4xx/ash.h  
(mode:100644)
+++ eb4292a8874abcc926f536de90af0bdb001cf12e/arch/ppc/platforms/4xx/ash.h  
(mode:100644)
@@ -18,27 +18,6 @@
 #include 
 
 #ifndef __ASSEMBLY__
-/*
- * Data structure defining board information maintained by the boot
- * ROM on IBM's "Ash" evaluation board. An effort has been made to
- * keep the field names consistent with the 8xx 'bd_t' board info
- * structures.
- */
-
-typedef struct board_info {
-   unsigned charbi_s_version[4];   /* Version of this structure */
-   unsigned charbi_r_version[30];  /* Version of the IBM ROM */
-   unsigned int bi_memsize;/* DRAM installed, in bytes */
-   unsigned charbi_enetaddr[4][6]; /* Local Ethernet MAC address */
-   unsigned charbi_pci_enetaddr[6];
-   unsigned int bi_intfreq;/* Processor speed, in Hz */
-   unsigned int bi_busfreq;/* PLB Bus speed, in Hz */
-   unsigned int bi_pci_busfreq;/* PCI speed in Hz */
-} bd_t;
-
-/* Some 4xx parts use a different timebase frequency from the internal clock.
-*/
-#define bi_tbfreq bi_intfreq
 
 /* Memory map for the IBM "Ash" NP405H evaluation board.
  */
Index: arch/ppc/platforms/4xx/bubinga.c
==

bd_t Cleaning: Interface Part

[Jon Loeliger]

On Thu, 2005-05-26 at 18:08, Kumar Gala wrote:
> Jon,
> 
> Can you break the patch up into a few pieces, it will be easier to 
> review that way.  Here are the following pieces that make sense to me:
> 
> 0. New firmware interface (fw_bdt*, Kconfig, ...)
> 1. board code changes (everything in arch/ppc/platforms/*)
> 2. driver changes (things in *_io, ide, net, serial dirs -- try to give 
> a better list below)
> 3. System changes (files in arch/ppc/syslib and include/asm-ppc)


OK.

Here's the first of the same patch in four part harmony.

 ppc/Kconfig |   29 +
 ppc/syslib/fw_bdt.c |  598 
 ppc/syslib/fw_bdt.h |  453 
 ppc/syslib/Makefile |4 
 asm-ppc/firmware.h  |   62 +++
 ppc/kernel/ppc_ksyms.c  |4 

Index: arch/ppc/Kconfig
===
--- c7d7a187a2125518e655dfeadffd38156239ffc3/arch/ppc/Kconfig  (mode:100644)
+++ eb4292a8874abcc926f536de90af0bdb001cf12e/arch/ppc/Kconfig  (mode:100644)
@@ -955,6 +955,35 @@
  some command-line options at build time by entering them here.  In
  most cases you will need to specify the root device here.
 
+choice
+   prompt "Firmware setup interface"
+   default FW_BDT
+   help
+ The bd_t structure setup by U-Boot is a flat structure with a
+ fixed structure that must be consistent between U-Boot and Linux.
+ Often that structure definition is out of date and inconsistent.
+ The Open Firmware Flattened Device Tree provides a less fragile
+ mechanism for communicating setup data from the firmware to Linux.
+
+ The Implementation of the Open Firwmare flattened Device Tree
+ hasn't been added to U-Boot yet, so select the bd_t option.
+
+config FW_BDT
+   bool "bd_t structure"
+   help
+ Select this option to use the traditional bd_t style interface
+ to pass residual data from U-Boot to the Linux startup code.
+
+ Select this choice if unsure.
+
+config FW_OF
+   bool "OF Flattened Device Tree"
+   help
+ Select this option to use a flattened Open Firmware device tree
+ to pass data from U-Boot to the Linux startup code.
+
+endchoice
+
 config AMIGA
bool
depends on APUS
Index: arch/ppc/syslib/fw_bdt.c
===
--- /dev/null  (tree:c7d7a187a2125518e655dfeadffd38156239ffc3)
+++ eb4292a8874abcc926f536de90af0bdb001cf12e/arch/ppc/syslib/fw_bdt.c  
(mode:100644)
@@ -0,0 +1,598 @@
+/*
+ * arch/ppc/syslib/fw_bdt.c
+ *
+ * Implements the interface to Firmware information based
+ * on U-Boot's bd_t structure definition.
+ *
+ * Maintainer: Kumar Gala 
+ *
+ * Copyright 2005 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "fw_bdt.h"
+
+
+/*
+ * The "residual" data area holds data supplied by the firmware in order
+ * to communicate initialization and setup data to the Linux startup.
+ */
+bd_t __res;
+static bd_t *binfo = &__res;
+
+EXPORT_SYMBOL(__res);
+
+
+/*
+ * Perform any initialization needed in order to setup the interface
+ * between the Firmware-supplied setup data and the Linux use of it.
+ *
+ * That is, copy the data pointed to by r3 to the __res "residual" structure.
+ */
+
+void __init
+fw_initialize(unsigned long r3)
+{
+   if (r3) {
+   memcpy((void *) &__res,
+  (void *) (r3 + KERNELBASE),
+  sizeof(bd_t));
+   }
+}
+
+
+/*
+ * Return the address of an in-memory structure that can be used
+ * to initialize the bd_t firware setup. Woo.
+ */
+
+void *
+fw_get_init_data(void)
+{
+   return &__res;
+}
+
+
+/*
+ * Return the start of DRAM memory.
+ */
+unsigned long
+fw_get_memory_start(void)
+{
+#if defined(FW_BDT_HAS_MEMSTART)
+return binfo->bi_memstart;
+#else
+   return 0;
+#endif
+}
+
+
+/*
+ * Return the amount of memory in bytes.
+ */
+unsigned long
+fw_get_memory_size(void)
+{
+#if defined(FW_BDT_HAS_MEMSIZE)
+return binfo->bi_memsize;
+#else
+   return 0;
+#endif
+}
+
+
+/*
+ * Return the start of FLASH memory.
+ */
+unsigned long
+fw_get_flash_start(void)
+{
+#if defined(FW_BDT_HAS_FLASHSTART)
+return binfo->bi_flashstart;
+#else
+   return 0;
+#endif
+}
+
+
+/*
+ * Return the amount of FLASH memory in bytes.
+ */
+unsigned long
+fw_get_flash_size(void)
+{
+#if defined(FW_BDT_HAS_FLASHSIZE)
+return binfo->bi_flashsize;
+#else
+   return 0;
+#endif
+}
+
+
+unsigned long
+fw_get_flash_offs

OF flat device tree for ppc32...

[Jon Loeliger]

On Thu, 2005-05-19 at 01:41, Jakob Viketoft wrote:
> Hello Jon!
> 
> Any news on the port of the OF-layer to ppc32? I'd love to hear some 
> more and it would be great be able to help out, even though I have some 
> heavy deadlines hanging over me for the next 2 months. From what I can 
> see on the list, there wasn't many comments on your first preparatory 
> code, but I for one thinks it's time to move it forward anyway.
> 
> What do you say?
> 
>   /Jakob

Folks,

I have updated my tree and patch to the latest GIT
as of last night.  The new patch is available here:

   http://www.jdl.com/bdt_cleanup_git.patch.gz

Signed-off-by: Jon Loeliger 

Please let me know if there are difficulties retrieving it.

This patch has a few caveats associated with it.
In particular, it does not address the entire

arch/ppc/boot/simple

issue at all.  And for that reason, this patch does
not yet actually remove the to-be-obsoleted ppcboot.h
that is otherwise unreferenced.  I am hopeful that
someone who is muchm ore familiar with that code can
pick up from this patch and Do The Right Thing there.

This patch in no-way eliminates the U-Boot-to-Kernel
interface yet.  It merely isolates it all to one location
and provides a functional interface to it.

Enjoy,
jdl

OF flat device tree for ppc32...

[Jon Loeliger]

On Thu, 2005-05-19 at 01:41, Jakob Viketoft wrote:
> Hello Jon!
> 
> Any news on the port of the OF-layer to ppc32? I'd love to hear some 
> more and it would be great be able to help out, even though I have some 
> heavy deadlines hanging over me for the next 2 months. From what I can 
> see on the list, there wasn't many comments on your first preparatory 
> code, but I for one thinks it's time to move it forward anyway.
> 
> What do you say?
> 
>   /Jakob

So, there were two positive comments that I received
as feedback on my initial suggestion, and no negative
comments.  (Minor patch deltas not withstanding.)

I am _almost_ actively back to working on this issue.

Right now, I am in the process of re-grabbing a new
tree from GIT-land and reconstructing my tree and patch
based on current top-of-GIT.

My desire will then be to re-submit the patch for real
and have it applied to the tree in an effort to isolate
the __res and friends to one localized area with a
well-defined interface.

I will then read Ben's proposal in detail and move
forward from there.

HTH!
jdl

Flat OF Device Tree for ppc32 [was: Platform bus/ppc sys model...]

[Jon Loeliger]

On Thu, 2005-04-14 at 04:54, Jakob Viketoft wrote:
> Has any more happened on this off-list,

Not by me.  A couple folks are also known to be on vacation.

>  or it is just in testing-mode right now?

likely.  Still waiting for feedback such as yours!  (Thanks!)

> I applied the changes to a 2.6.12-rc2 tree (with some minor rejects to 
> sort out) and it compiles and boots fine on my Memec FF1152 board with 
> the Virtex-II Pro chip (Xilinx ML300 config).

Excellent.

> A couple of small changes to be able to use the simple boot-loader is below.

I'll add these to my mix!

Thanks,
jdl

Flat OF Device Tree for ppc32 [was: Platform bus/ppc sys model...]

[Jon Loeliger]

On Thu, 2005-04-07 at 12:49, Tom Rini wrote:

> Please post to the list as an RFC.  Thanks.

Folks,

Apologies to those who have received this notice twice.
I first sent it to the list where it was summarily
denied for size reasons.

I have now posted a tgz file here instead:

http://www.jdl.com/bdt_cleanup.tgz

What follows is my original email content.


OK, for those keeping score over on the U-Boot list, _this_
message is really intended to be sent to the public list. :-)

Here (as noted above) are my diffs against a clone of
http://linux.bkbits.net/linux-2.6
as last pulled a couple days ago. (*)

Please consider this a Request For Comments for now.  Feel free
to apply it and test it out as well, of course. :-)  I'll sign-off
on it when it has ripened some more and gets a nod or two...

These changes relocate almost all of the ppcboot.h definitions
into new files, arc/ppc/syslib/fw_bdt.[ch] and front them
with a new, shim interface in include/asm-ppc/firmware.h.

There is a Kconfig option that allows you to select between
a "bd_t" interface and a non-existant "OF Flat dev tree"
interface.  Choose wisely (default) for now.  It adds the
new fw_bdt.o file.

Some potential gotchas or points to note:

- As of this patch, no interface to any board should change.
  This just isolates the scattered bd_t references to one place.

- On Kumar's advice arch/ppc/boot/simple was totally ignored.
  For now; this round.  It can be next on the hit parade easily.
  It holds the last reference to ppcboot.h still.

- Earlier cut-n-paste of some devices led to me changing a few
  files over in 68k land to remove some now-obsolete ppcboot.h
  related comments justs for completeness.

- I've compiled uImage using defconfigs for the following boards:

8560_adscpci690 ash redwood5
8540_adsads_8272TQM8260 est8260
rpx8260 bseip   mbx mpc834x_sys
ocotea  lite5200hdpulopec
TQM860L rpxlite radstone_ppc7d  walnut

- The file include/asm-ppc/ppcboot.h used to contain a nested
  include of linux/types.h that was tacitly used by many files.
  In ripping ppcboot.h out of many platform .h files, I've had
  to add direct #include  in several places.
  If your board isn't listed above and it looks really broken,
  consider if it needs a ?


Enjoy,
jdl

--
(*) -- BK is dead.  Long live BK!

Flat OF Device Tree for ppc32 [was: Platform bus/ppc sys model...]

[Jon Loeliger]

On Thu, 2005-04-07 at 12:20, Tom Rini wrote:
> Part of the point of this is to move to a defined interface :)

I've extracted a defined interface for the _current_ bd_t
structure so far.  I'm telling you, you're not going to
like it... :-)

So what do you want to do with it?  Specifically, my tree
is in this state:

- I have made two files, a .c and a .h that contain
  essentially a grand-union of all of the bd_t and 
  board_info structure definitions that I could find.

- I have introduced shim function definitions that are
  simple accessor functions to front the common structure
  definition.

It is semi gross in that this file contains a plethora of
#ifdef messes that span multiple PPC32 boards and architectures.
Whereas these used to be nicely distributed (:-)) they are
all gathered into one place that clearly demonstrates a 
few things:

- This is wrong and needs to be cleaned up more :-),

- Obvious refactoring for common functionality that
  is NOT board-specific is still needed,

- There are 51 unique fields in all the bd_t defs.

I am currently proving that various platforms still build.
I'm not going to be able to run-test any boards except
a limited few.

I will happily supply a diff of my messings to the list or
a few individuals who want it.

jdl

Flat OF Device Tree for ppc32 [was: Platform bus/ppc sys model...]

[Jon Loeliger]

On Thu, 2005-03-31 at 06:33, Jon Masters wrote:
> Kumar Gala wrote:
> 
> |> My intention was to give a device tree structure to the kernel at boot
> |> time via a (pseudo?) pointer in bd_info or similar. 

> This got resurrected recently. 

Hi!

> | I think this is reasonable.  The best device tree would be a flattened
> | OF tree since we are trying to move the world in that direction.  Jon
> | Masters around?
> 
> Yes, but I've been tied up with worky and magazine stuff again. If
> someone wants to work with me then this might actually happen.

Hi Jon,

I'm here and actively(!) working on it now.   Here is the very
rough plan as Kumar and I have discussed it.  Please feel free
to comment on it or offer suggestions.  Ben has suggested that
I start with the "second step" below.  I'd like to do a round
of cleanup first.

So far, I have taken the first step of isolating the references
to the global __res[] variable into one file and replacing all
references to the data in the bd_t structure with a thin, shim
layer of function calls that are nominally into an OF-like
interface.  I have done this for all the 85xx and 83xx boards
in my development tree, and am working on the others now.
This step effectively isolates the __res[] references to one
file where a well defined interface can be created to pose as
an OF Device Tree layer (briefly).

As a follow-up second step, I plan on introducing essentially
the same code currently in ppc64 to handle the flat device tree
and provide an interface to that data in exactly the same manner
as the ppc64 currently has.  I understand the desire to have the
flat-tree handling be "outside the kernel".

As a third step, the shim layer will be rewritten/augmented to
use the actual OF device tree data where it currently fronts
for the bd_t data.

Finally, as time permits and maintainers allow (read: prod),
the other (not 85xx, not 83xx) boards can have their setup code
converted to use the "real" OF device tree function calls.

When all of that is done, the shim layer can be removed, as needed.


Oh, yeah.  Um, also on my plate will be to construct the
original flat-tree blob in U-Boot to be handed to the kernel.
(I'll start with 85xx and 83xx, naturlich.)

We have not yet decided on the layout of that tree to determine
where all the attributes and devices really belong.  I will
also discuss with Wolfgang and crew how to generate that tree
over in U-Boot land.

Right?
 
Thanks,
jdl

Problem running Linux 2.6.11 on MPC8272ADS

[Jon Loeliger]

On Thu, 2005-03-31 at 02:22, Li Yang-r58472 wrote:
> Good point.
> There is also IMMR need to be passed from bootloader to kernel.  We
> can make more use of the u-boot bd_info mechanism.  But it binds ppc
> linux to u-boot boot loader.  I don't know if we should make it a
> porting convention.

Hi guys,

So, just for the record here, Kumar and I are moving the ppc32
line away from bd_t towards an OpenFirmware flattened device tree.
That data will still have a place for the IMMR to be passed.

Under another Subject:, I'll describe a brief outline of
The Plan So Far so people can take shots at it. :-)

> Best Regards,
> Leo

Thanks,
jdl

U-Boot hangs in relocate_code after sw reboot

[Jon Loeliger]

On Fri, 2005-03-04 at 09:53, Jaka Mo?nik wrote:
> hello!
> 
> I don't really know if this mailing list is the proper place to direct
> questions regarding U-Boot, but I've seen some preceding posts about it,
> so I thought I'd ask...

Let's start with:  The U-Boot list is over at:
u-boot-users 

> I've ported U-Boot over to a custom MPC8560 (PQ3) based board - it works
> well, 

Good...  So, what version did you start with?
And how custom is it?  We just might need a few more details here... :-)

> except that after a sw reboot (from linux kernel or u-boot
> itself),

There were some early releases of 8560 U-Boot code that
didn't do SW Reset right.  Let's make sure we are running
a modern U-Boot for the 85xx first.

>  it only gets to the part where it relocates itself to RAM and
> then hangs - the last debug output is 

There are some U-Boot FAQs down this line too.

> has anyone experienced similar problems? any hints on what to look at?

HTH,
jdl

MPC8560 problem to launch user application like /sbin/init

[Jon Loeliger]

On Thu, 2004-10-14 at 04:49, Laurent Lagrange wrote:
> Hi,
> 
> 
> > Have you turned on emulation of FP in the kernel?
> No I did not it, but with the FP emulation on, the Linux runs...
> Many thanks for your help.

Excellent!

> > > The console is mapped on SCC1 port.
> > > CCSRBAR is mapped at 0xF800 and immr at 0xF808.
> > I would suggest using the standard memory map the rest of
> > us use for 8560.  It makes the porting lots easier.
> Sure. But where can I find the standard rules ?
> Are the rules dependent on each demo board like 8560_ads ?
> Do the custom boots respect some rules ?

Uh, rules?  No, but in the U-Boot tree, you can find them
in the file u-boot/doc/README.mpc85xxads and, related,
README.mpc85xxcds.  Relevant section here:

2. MEMORY MAP TO WORK WITH LINUX KERNEL

2.1. For the initial bringup, we adopted a consistent memory scheme
 between u-boot and linux kernel, you can customize it based on your
 system requirements:

 0x_ 0x7fff_ DDR 2G
 0x8000_ 0x9fff_ PCI MEM 512M
 0xc000_ 0xdfff_ Rapid IO512M
 0xe000_ 0xe00f_ CCSR1M
 0xe200_ 0xe2ff_ PCI IO  16M
 0xf000_ 0xf7ff_ SDRAM   128M
 0xf800_ 0xf80f_ BCSR1M
 0xff00_ 0x_ FLASH (boot bank)   16M

and from the CDS README:

Memory Map
--

The memory map for u-boot and linux has been extended w.r.t. the ADS
platform to allow for utilization of all 85xx CDS devices.  The memory
map is setup for linux to operate properly.  The linux source when
configured for MPC85xx CDS has been updated to reflect the new memory
map.

The mapping is:

   0x_ 0x7fff_ DDR 2G
   0x8000_ 0x9fff_ PCI1 MEM512M
   0xa000_ 0xbfff_ PCI2 MEM512M
   0xe000_ 0xe00f_ CCSR1M
   0xe200_ 0xe2ff_ PCI1 IO 16M
   0xe300_ 0xe3ff_ PCI2 IO 16M
   0xf000_ 0xf7ff_ SDRAM   128M
   0xf800_ 0xf80f_ NVRAM/CADMUS (*)1M
   0xff00_ 0xff7f_ FLASH (2nd bank)8M
   0xff80_ 0x_ FLASH (boot bank)   8M

   (*) The system control registers (CADMUS) start at offset 0xfdb0_4000
   within the NVRAM/CADMUS region of memory.


You can get some of the details from the Linux code in the file

linuxppc-2.4/arch/ppc/platforms/mpc85xx_ads_common.h

HTH,
jdl

MPC8560 problem to launch user application like /sbin/init

[Jon Loeliger]

On Wed, 2004-10-13 at 22:13, Kumar Gala wrote:
> Have you turned on emulation of FP in the kernel?
> 
> - kumar
> 
> On Oct 13, 2004, at 4:01 PM, Dan Malek wrote:
> 
> >
> >
> > On Oct 13, 2004, at 1:07 PM, Laurent Lagrange wrote:
> >
> > > The console is mapped on SCC1 port.
> >  > CCSRBAR is mapped at 0xF800 and immr at 0xF808.
> >
> > I would suggest using the standard memory map the rest of
> >  us use for 8560.  It makes the porting lots easier.

Yeah, sticking with the standard memory map will likely help.

Are you using U-Boot to front this booting operation, or
just directly coding your own setup?


> > > All things run fine until I launch the /sbin/init file from a nfs
> > > networK.

Another popular failure mode of this step is the lack of
some library, file or permisssions on a file necessary to
run the init code.  A workaround is to statically link the
init code and see if that works too.

HTH,
jdl

[PATCH] MPC85XX TSEC driver: fix for mdio speed

[Jon Loeliger]

On Wed, 2004-07-14 at 02:00, Stefan Nickl wrote:

> Btw: Can support for the 8541 be expected anytime soon?
>  I added some #defines to my platform code, but I didn't look
>  closely into it's incarnation of the CPM yet.
>
> --
> Stefan Nickl
> Kontron Modular Computers

Just yesterday, I was given The Nod to release the 8555/8541
sources for U-Boot.  Linux likely follows shortly.

jdl


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

MPC85xx support

[Jon Loeliger]

On Thu, 2004-04-15 at 10:05, Dan Malek wrote:
> Jon Loeliger wrote:
>
> > I am planning to release an updated version of the mpc85xx support
> > for U-Boot in just a few days.  It will be updated to Rev 1.1 and
> > has major improvements to the TSEC driver.
>
> Major improvements?  I recently posted a patch for the RPC/STx 8560
> board that included some TSEC updates, I don't know if they have made
> it into the CVS.  If not, please snag that from the mailing list so
> they are not lost.

Yesterday and today I have sync'ed up our internal tree to include
the delta up to the U-Boot 1.1.0 release.  Relative to what we had
in our tree before that (circa 2004_01_26), the only changes to the
TSEC code were a bunch of volatile declaration changes.  Those mods
are effectively captured in our update.  If there was more than that,
since the 1.1.0 release, I'll go searching...


>   -- Dan

jdl


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

MPC85xx support

[Jon Loeliger]

On Thu, 2004-04-15 at 05:08, Gerrit Van de Velde wrote:
>
> Hi,
>
> I was wondering how well the mpc85xx of motorola (PowerPC e500 core) is
> currently supported in the linux/u-boot combination.
> Can anyone give some pointers about this matter ?
>
> Kind regards,
> Gerrit Van de Velde

Hi Gerrit,

I am planning to release an updated version of the mpc85xx support
for U-Boot in just a few days.  It will be updated to Rev 1.1 and
has major improvements to the TSEC driver.  An updated Linux release
is close as well, but I'll let my partner in crime speak there. :-)

Are there specific features you are concerned about?

jdl


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/