linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Sean MacLennan <smaclennan@pikatech.com>
Cc: LinuxPPC-dev <linuxppc-dev@ozlabs.org>
Subject: Re: Could the DTS experts look at this?
Date: Mon, 11 Feb 2008 11:14:51 +1100	[thread overview]
Message-ID: <20080211001451.GA11572@localhost.localdomain> (raw)
In-Reply-To: <47ACE630.8090101@pikatech.com>

On Fri, Feb 08, 2008 at 06:30:56PM -0500, Sean MacLennan wrote:
> The Rev B warp is moving to a 4M NOR / 256M NAND flash setup from the 
> current 64M NOR / 64M NAND. I would like to keep support for the 64M NOR 
> so I modified the boot code to be a bit more dynamic. Here is the new 
> NOR parition layout in the DTS:
> 
> nor_flash@0,0 {
> 	compatible = "amd,s29gl512n", "cfi-flash";
> 	bank-width = <2>;
> 	reg = <0 0 4000000>;
> 	#address-cells = <1>;
> 	#size-cells = <1>;
> 	partition@300000 {
> 		label = "fpga";
> 		reg = <300000 40000>;
> 	};
> 	partition@340000 {
> 		label = "env";
> 		reg = <340000 40000>;
> 	};
> 	partition@380000 {
> 		label = "u-boot";
> 		reg = <380000 80000>;
> 	};
> };
> 
> Yes, the top of the NOR will be empty. Here is the code from 
> cuboot-warp.c to handle fixups for the 64M flash:
> 
> static void warp_fixup_one_nor(u32 from, u32 to)
> {
> 	void *devp;
> 	char name[40];
> 	u32 v[2];
> 
> 	sprintf(name, "/plb/opb/ebc/nor_flash@0,0/partition@%x", from);
> 
> 	devp = finddevice(name);
> 	if (!devp) return;
> 
> 	if (getprop(devp, "reg", v, sizeof(v)) == sizeof(v)) {
> 		v[0] = to;
> 		setprop(devp, "reg", v, sizeof(v));
> 
> 		printf("NOR 64M fixup %x -> %x\n", from, to);
> 	}
> }
> 
> 
> static void warp_fixups(void)
> {
> 	unsigned long sysclk = 66000000;
> 
> 	ibm440ep_fixup_clocks(sysclk, 11059200, 50000000);
> 	ibm4xx_sdram_fixup_memsize();
> 	ibm4xx_fixup_ebc_ranges("/plb/opb/ebc");
> 	dt_fixup_mac_addresses(&bd.bi_enetaddr);
> 
> 	/* Fixup for 64M flash on Rev A boards. */
> 	if(bd.bi_flashsize == 0x4000000) {
> 		warp_fixup_one_nor(0x300000, 0x3f00000);
> 		warp_fixup_one_nor(0x340000, 0x3f40000);
> 		warp_fixup_one_nor(0x380000, 0x3f80000);
> 	}
> }

This doesn't seem right.  warp_fixup_one_nor() changes only the
partition's offset, so you're not changing the size of any
partitions.  If you're not going to actually use any of the extra
flash space with 64M, I can't see why you'd bother moving around the
partitions you have.

> I have tested this with the 64M NOR, and it seems to work. However, are 
> there going to be problems with the partition name not matching the reg 
> address entry?

In practice, probably not.  We already do a similar fixup on Ebony for
different flash layouts that won't leave the unit names correct.  We
really should get this right - and the fdt_set_name() function that's
now in libfdt should make that possible, it just needs some wiring up
to use in the bootwrapper.  That can come later, though, for now I
think applying your fixups without correcting the unit addresses is
adequate.

> If anybody has suggestions on better ways to do this, fire away.
> 
> And looking at this code, and other board ports, why is sysclk a local 
> variable and all the other numbers hardcoded in the args? I left it the 
> same way as the others but it does look a bit strange.

I think this also came from Ebony.  IIRC, the sysclk isn't strictly
speaking fixed, although it almost always has initialized value.  The
point of the local variable was that I planned to replace the static
initialization with some sort of probing once I figured out the
details.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

  parent reply	other threads:[~2008-02-11  0:14 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-08 23:30 Could the DTS experts look at this? Sean MacLennan
2008-02-10  5:47 ` Arnd Bergmann
2008-02-10  6:05   ` Sean MacLennan
2008-02-11 17:57   ` Timur Tabi
2008-02-11 23:54     ` David Gibson
2008-02-11 23:56       ` David Gibson
2008-02-12  0:21         ` Arnd Bergmann
2008-02-12  0:36           ` David Gibson
2008-02-12 18:51             ` Scott Wood
2008-02-12 23:17               ` David Gibson
2008-02-12 23:41                 ` Timur Tabi
2008-02-12 23:50                   ` David Gibson
2008-02-12 15:44           ` Timur Tabi
2008-02-12 18:58             ` Grant Likely
2008-02-12 19:08               ` Timur Tabi
2008-02-12 19:34                 ` Grant Likely
2008-02-12 19:45                   ` Timur Tabi
2008-02-12 20:43                     ` Grant Likely
2008-02-12 23:35                     ` David Gibson
2008-02-12 23:50                       ` Timur Tabi
2008-02-13  0:10                       ` Grant Likely
2008-02-12 23:26                 ` David Gibson
2008-02-12 23:47                   ` Timur Tabi
2008-02-13  0:08                     ` David Gibson
2008-02-13  0:15                     ` Grant Likely
2008-02-12 23:21             ` David Gibson
2008-02-11  0:14 ` David Gibson [this message]
2008-02-11  2:40   ` Sean MacLennan
2008-02-11  3:11     ` David Gibson
2008-02-11  3:49       ` Sean MacLennan
2008-02-11 23:59         ` David Gibson
2008-02-12  1:07           ` Sean MacLennan
2008-02-12  0:20             ` David Gibson
2008-02-12  0:41               ` Sean MacLennan
2008-02-12  0:48                 ` David Gibson
2008-02-12 18:52                 ` Scott Wood
2008-02-12 19:03                   ` Grant Likely
2008-02-12 19:10                     ` Scott Wood
2008-02-17 10:22                       ` David Woodhouse

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080211001451.GA11572@localhost.localdomain \
    --to=david@gibson.dropbear.id.au \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=smaclennan@pikatech.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).