linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Sean MacLennan <smaclennan@pikatech.com>
To: LinuxPPC-dev <linuxppc-dev@ozlabs.org>
Subject: Could the DTS experts look at this?
Date: Fri, 08 Feb 2008 18:30:56 -0500	[thread overview]
Message-ID: <47ACE630.8090101@pikatech.com> (raw)

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);
	}
}

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?

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.

Cheers,
   Sean

             reply	other threads:[~2008-02-08 23:30 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-08 23:30 Sean MacLennan [this message]
2008-02-10  5:47 ` Could the DTS experts look at this? 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
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=47ACE630.8090101@pikatech.com \
    --to=smaclennan@pikatech.com \
    --cc=linuxppc-dev@ozlabs.org \
    /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).