Add device tree support for ARM to U-Boot

RFC PATCH New John Rigby 12 participants 40 messages Aug 5, 2010 – Oct 27, 2010

Subsystems (6)

Arm (32-bit) PowerPC SPARC + UltraSPARC (sparc/sparc64) m68k architecture +2 more subsystems

lore

Share & tools

lore

John Rigby

author

2010-08-05 22:14 UTC #0 lore raw

cover Add device tree support for ARM to U-Boot

These patches add device tree support to the bootm command in u-boot for the ARM. I'm sending the patches to this list first for comments before sending it to the wider audience on the u-boot list.

The only testing so far has shown that this patch does not break non-dt booting. I don't have a dt enabled beagle kernel so I have not tried that yet.

John Rigby (3):
FDT: Add fixup support of multiple banks of memory
ARM: WIP: add flat device tree support
ARM: add config for beagle with fdt enabled

 MAKEALL                           |    1 +
 arch/arm/include/asm/config.h     |    1 +
 arch/arm/lib/bootm.c              |  128 ++++++++++++++-
 boards.cfg                        |    1 +
 common/cmd_bootm.c                |    5 +-
 common/fdt_support.c              |   86 +++++-----
 common/image.c                    |    7 +-
 include/configs/omap3_beagle_dt.h |  344 +++++++++++++++++++++++++++++++++++++
 include/fdt_support.h             |    1 +
 include/image.h                   |    2 +-
 10 files changed, 531 insertions(+), 45 deletions(-)
 create mode 100644 include/configs/omap3_beagle_dt.h

John Rigby

author

2010-08-05 22:14 UTC #1 lore raw

RFC 1/3 FDT: Add fixup support of multiple banks of memory

Add fdt_fixup_memory_banks and reimplement fdt_fixup_memory to use it.

Signed-off-by John Rigby <[email protected]>

---
 common/fdt_support.c  |   86 ++++++++++++++++++++++++++-----------------------
 include/fdt_support.h |    1 +
 2 files changed, 47 insertions(+), 40 deletions(-)

common/fdt_support.c +46 ~~-40~~

index 166f5e1..dc5f040 100644
@@ -362,10 +362,40 @@ void do_fixup_by_compat_u32(void *fdt, const char *compat,
 	do_fixup_by_compat(fdt, compat, prop, &val, 4, create);
 }
 
-int fdt_fixup_memory(void *blob, u64 start, u64 size)
+/*
+ * Get cells len in bytes
+ *     if #NNNN-cells property is 2 then len is 8
+ *     otherwise len is 4
+ */
+static int get_cells_len(void *blob, char *nr_cells_name)
+{
+	const u32 *cell;
+
+	cell = fdt_getprop(blob, 0, nr_cells_name, NULL);
+	if (cell && *cell == 2)
+		return 8;
+
+	return 4;
+}
+
+/*
+ * Write a 4 or 8 byte big endian cell
+ */
+static void write_cell(u8 *addr, u64 val, int size)
 {
-	int err, nodeoffset, len = 0;
-	u8 tmp[16];
+	int shift = (size - 1) * 8;
+	while (size-- > 0) {
+		*addr++ = (val >> shift) & 0xff;
+		shift -= 8;
+	}
+}
+
+int fdt_fixup_memory_banks(void *blob, u64 start[], u64 size[], int banks)
+{
+	int err, nodeoffset;
+	int addr_cell_len, size_cell_len, len;
+	u8 tmp[banks * 8];
+	int bank;
 	const u32 *addrcell, *sizecell;
 
 	err = fdt_check_header(blob);

@@ -391,44 +421,15 @@ int fdt_fixup_memory(void *blob, u64 start, u64 size)
 		return err;
 	}
 
-	addrcell = fdt_getprop(blob, 0, "#address-cells", NULL);
-	/* use shifts and mask to ensure endianness */
-	if ((addrcell) && (*addrcell == 2)) {
-		tmp[0] = (start >> 56) & 0xff;
-		tmp[1] = (start >> 48) & 0xff;
-		tmp[2] = (start >> 40) & 0xff;
-		tmp[3] = (start >> 32) & 0xff;
-		tmp[4] = (start >> 24) & 0xff;
-		tmp[5] = (start >> 16) & 0xff;
-		tmp[6] = (start >>  8) & 0xff;
-		tmp[7] = (start      ) & 0xff;
-		len = 8;
-	} else {
-		tmp[0] = (start >> 24) & 0xff;
-		tmp[1] = (start >> 16) & 0xff;
-		tmp[2] = (start >>  8) & 0xff;
-		tmp[3] = (start      ) & 0xff;
-		len = 4;
-	}
+	addr_cell_len = get_cells_len(blob, "#address-cells");
+	size_cell_len = get_cells_len(blob, "#size-cells");
 
-	sizecell = fdt_getprop(blob, 0, "#size-cells", NULL);
-	/* use shifts and mask to ensure endianness */
-	if ((sizecell) && (*sizecell == 2)) {
-		tmp[0+len] = (size >> 56) & 0xff;
-		tmp[1+len] = (size >> 48) & 0xff;
-		tmp[2+len] = (size >> 40) & 0xff;
-		tmp[3+len] = (size >> 32) & 0xff;
-		tmp[4+len] = (size >> 24) & 0xff;
-		tmp[5+len] = (size >> 16) & 0xff;
-		tmp[6+len] = (size >>  8) & 0xff;
-		tmp[7+len] = (size      ) & 0xff;
-		len += 8;
-	} else {
-		tmp[0+len] = (size >> 24) & 0xff;
-		tmp[1+len] = (size >> 16) & 0xff;
-		tmp[2+len] = (size >>  8) & 0xff;
-		tmp[3+len] = (size      ) & 0xff;
-		len += 4;
+	for (bank = 0, len = 0; bank < banks; bank++) {
+		write_cell(tmp + len, start, addr_cell_len);
+		len += addr_cell_len;
+
+		write_cell(tmp + len, start, size_cell_len);
+		len += size_cell_len;
 	}
 
 	err = fdt_setprop(blob, nodeoffset, "reg", tmp, len);

@@ -440,6 +441,11 @@ int fdt_fixup_memory(void *blob, u64 start, u64 size)
 	return 0;
 }
 
+int fdt_fixup_memory(void *blob, u64 start, u64 size)
+{
+	return fdt_fixup_memory_banks(blob, &start, &size, 1);
+}
+
 void fdt_fixup_ethernet(void *fdt)
 {
 	int node, i, j;

include/fdt_support.h +1 -0

index 871ef45..5f631ea 100644
@@ -48,6 +48,7 @@ void do_fixup_by_compat(void *fdt, const char *compat,
 void do_fixup_by_compat_u32(void *fdt, const char *compat,
 			    const char *prop, u32 val, int create);
 int fdt_fixup_memory(void *blob, u64 start, u64 size);
+int fdt_fixup_memory_banks(void *blob, u64 start[], u64 size[], int banks);
 void fdt_fixup_ethernet(void *fdt);
 int fdt_find_and_setprop(void *fdt, const char *node, const char *prop,
 			 const void *val, int len, int create);

Signature · 1 line

1.7.0.4

Kumar Gala

2010-08-05 23:26 UTC #2 lore raw

RFC 1/3 FDT: Add fixup support of multiple banks of memory

Quoted 8 lines · John Rigby

Add fdt_fixup_memory_banks and reimplement fdt_fixup_memory to use it.
Signed-off-by John Rigby <[email protected]>
---
common/fdt_support.c | 86 ++++++++++++++++++++++++++-----------------------
include/fdt_support.h | 1 +
2 files changed, 47 insertions(+), 40 deletions(-)

John,

Do you have any sense of how far you intend to go w/device tree's on ARM?

I ask because I've been thinking we actually need to have "live tree" structure representation in u-boot (much like the kernel) to allow us to do some of the manipulations we are doing more and more of.

The problem w/libfdt is that use of 'offsets' to get to nodes can be problematic if the offset changes while manipulating it. There are ways around thus but a number of functions we do would benefit from a more live tree.

Wondering how far you envision ARM going w/device tree and u-boot doing node creations and fix ups.

- k

John Rigby

2010-08-05 23:36 UTC #3 lore raw

RFC 1/3 FDT: Add fixup support of multiple banks of memory

Kumar,

Right now I'm only looking a basic support. I know there are those who believe that u-boot actually does more manipulation than it should. I'll let Grant speak up if he wants to:).

John

Quoted 28 lines · Kumar Gala

Quoted 8 lines · John Rigby
Add fdt_fixup_memory_banks and reimplement fdt_fixup_memory to use it.
Signed-off-by John Rigby <[email protected]>
---
common/fdt_support.c ?| ? 86 ++++++++++++++++++++++++++----------------------- include/fdt_support.h | ? ?1 +
2 files changed, 47 insertions(+), 40 deletions(-)
John,
Do you have any sense of how far you intend to go w/device tree's on ARM?
I ask because I've been thinking we actually need to have "live tree" structure representation in u-boot (much like the kernel) to allow us to do some of the manipulations we are doing more and more of.
The problem w/libfdt is that use of 'offsets' to get to nodes can be problematic if the offset changes while manipulating it. ?There are ways around thus but a number of functions we do would benefit from a more live tree.
Wondering how far you envision ARM going w/device tree and u-boot doing node creations and fix ups.
- k
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Grant Likely

2010-08-10 19:39 UTC #4 lore raw

RFC 1/3 FDT: Add fixup support of multiple banks of memory

Quoted 13 lines · John Rigby

Quoted 12 lines · Kumar Gala
Quoted 8 lines · John Rigby
Add fdt_fixup_memory_banks and reimplement fdt_fixup_memory to use it.
Signed-off-by John Rigby <[email protected]>
---
common/fdt_support.c ?| ? 86 ++++++++++++++++++++++++++----------------------- include/fdt_support.h | ? ?1 +
2 files changed, 47 insertions(+), 40 deletions(-)

Quoted 7 lines

Quoted 7 lines
John,
Do you have any sense of how far you intend to go w/device tree's on ARM?
I ask because I've been thinking we actually need to have "live tree" structure representation in u-boot (much like the kernel) to allow us to do some of the manipulations we are doing more and more of.
The problem w/libfdt is that use of 'offsets' to get to nodes can be problematic if the offset changes while manipulating it. ?There are ways around thus but a number of functions we do would benefit from a more live tree.

This is actually a really good point. Offsets changing under your feet is just asking for bugs. I could see this as being a legitimate justification for having a live tree model in libfdt and the ability to transition between the live and flat representations. I was against this when we chatted on IRC the other day as it sounds like overkill, but this is a legitimate concern. dtc has a live tree representation that could probably be migrated into libfdt.

Quoted 5 lines

Quoted 1 line
Wondering how far you envision ARM going w/device tree and u-boot doing node creations and fix ups.
Right now I'm only looking a basic support. I know there are those who believe that u-boot actually does more manipulation than it should. I'll let Grant speak up if he wants to:).

:-)

I still stand on my point that hard coding device tree manipulations is asking for trouble. IMNSHO, firmware should really be restricted to very well defined things in the device tree. I've been thinking about this a lot, and I'm going to write a "Recommended Practice" document for dealing with the .dtb at the firmware level. At the moment, I think firmware should be restricted to only touching the /chosen node, the /memory node, and updating well defined things like mac address, but only when the Ethernet node is dereferenced from an /aliases name instead of full path.

I *might* be able to be convinced that firmware should be allowed to modify other properties, but only if it isn't hard coded into the firmware (ie, by using a boot script or other method that can be changed without upgrading firmware). As we've discovered in the past, it is very easy to get into a situation where firmware must be upgraded to deal with a change in the device tree data. (ie. soc node name cannot be changed from "soc5200" to "soc" on the lite5200 because older versions of U-Boot do a pathname lookup) This risk can be mitigated if there are some well defined rules about what firmware is and is not allowed to modify in the tree.

Dan Malek

2010-08-10 20:17 UTC #5 lore raw

RFC 1/3 FDT: Add fixup support of multiple banks of memory

Quoted 3 lines · Grant Likely

..... At the
moment, I think firmware should be restricted to only touching the /chosen node, the /memory node,

I don't even want it updating these, except maybe for the processor clock speeds.

I'm trying to use device trees as a mechanism for providing resource allocation information in a partitioned, multi-core system. In this case, I don't want the boot firmware making updates to the device tree.

I understand in many cases it's quite convenient to have the boot firmware update the device tree prior to invoking the OS, but this is one time when it's not appreciated. I'm currently experimenting with two models, one using environment variables and another using some kind of device tree tagging (i.e. don't update value if it's not equal to some unique key). Neither method has proven to be better in all cases.

Thanks.

	-- Dan

Grant Likely

2010-08-10 20:26 UTC #6 lore raw

RFC 1/3 FDT: Add fixup support of multiple banks of memory

Quoted 9 lines · Dan Malek

Quoted 3 lines · Grant Likely
..... ?At the
moment, I think firmware should be restricted to only touching the /chosen node, the /memory node,
I don't even want it updating these, except maybe for the processor clock speeds.

Hi Dan! I'm glad you're reading as you're one of the use-cases I was thinking about. :-)

Quoted 4 lines

I'm trying to use device trees as a mechanism for providing resource allocation information in a partitioned, multi-core system. ?In this case, I don't want the boot firmware making updates to the device tree.

Yes, it is really problematic when boot firmware unconditionally makes device tree changes for this exact reason. However, it is also true that there is certain information that firmware really needs to hand off to the kernel, such as the boot parameters string. Traditionally, the chosen node has been the expected place to put that data, but I gather from your comment that even that causes problems in your use-case. (or is it the /memory node that is the issue?) Can you give a concrete example so I understand the issue? The /memory node update was implemented to match the historical behaviour of u-boot setting the memory size in the board_info structure, but perhaps that shouldn't be unconditional.

Quoted 7 lines

I understand in many cases it's quite convenient to have the boot firmware update the device tree prior to invoking the OS, but this is one time when it's not appreciated. ?I'm currently experimenting with two models, one using environment variables and another using some kind of device tree tagging (i.e. don't update value if it's not equal to some unique key). ?Neither method has proven to be better in all cases.

Cheers,
g.

Dan Malek

2010-08-10 21:17 UTC #7 lore raw

RFC 1/3 FDT: Add fixup support of multiple banks of memory

Quoted 2 lines · Grant Likely

Hi Dan! I'm glad you're reading as you're one of the use-cases I was thinking about. :-)

Hi Grant. Yeah, it's me, the "special" case :-)

Quoted 3 lines

....... but I
gather from your comment that even that causes problems in your use-case.

The /chosen hasn't really caused any trouble.

Quoted 1 line

(or is it the /memory node that is the issue?)

Yep, /memory is the big problem.

Quoted 5 lines

.... Can you
give a concrete example so I understand the issue? The /memory node update was implemented to match the historical behaviour of u-boot setting the memory size in the board_info structure, but perhaps that shouldn't be unconditional.

I use the /memory to define the start/size of the various partitions, which of course only one starts at the base address and none of them represent the entire memory space. Updating this as we do today is bad, but then I can think of other complex ways it could be useful. :-) Like... specify a percentage in the node property and have the firmware update base/size according to previous device tree requests. But, not today.

A little off topic, but since we tend to discuss device trees here. I think Hollis has discussed our use of an "enabled" property, which has become useful. It's becoming evident that it's valuable to define the entire device tree, but then have a property for the device that specified whether it's enabled for use in a particular partition. Today, we take a device tree, make copies for each partition, and modify "enabled" accordingly. I guess it could be extended to include partition information in the property, and we could then perhaps use a single tree for all partitions. The kernel or device drivers then test this to determine if this instance should be using this device. Anyway, just information I'd thought I'd pass along that is still brewing. I don't know if this has any value to boot firmware, maybe yet another way to control device tree updates.

Thanks.

	-- Dan

John Rigby

author

2010-08-10 21:03 UTC #8 lore raw

RFC 1/3 FDT: Add fixup support of multiple banks of memory

In reply to Grant Likely

Kumar, Grant:

Quoted 3 lines · Grant Likely

Quoted 2 lines · John Rigby
Quoted 1 line · Kumar Gala

....

Quoted 11 lines

Quoted 2 lines
Quoted 2 lines
The problem w/libfdt is that use of 'offsets' to get to nodes can be problematic if the offset changes while manipulating it. ?There are ways around thus but a number of functions we do would benefit from a more live tree.
This is actually a really good point. ?Offsets changing under your feet is just asking for bugs. ?I could see this as being a legitimate justification for having a live tree model in libfdt and the ability to transition between the live and flat representations. ?I was against this when we chatted on IRC the other day as it sounds like overkill, but this is a legitimate concern. ?dtc has a live tree representation that could probably be migrated into libfdt.

I don't think I fully understood Kumar's question when he first sent it. Now I want to understand. Are these gotcha's and workaround's with libfdt documented anywhere? If not then I would be willing to write up something. But I'll need some pointers to get me started. In the longer term how much work do you think it would be to make libfdt's internal representation dynamic? I would be willing spend some time on this if the consensus is that it is worth having.

Thanks,
John

Grant Likely

2010-08-10 21:09 UTC #9 lore raw

RFC 1/3 FDT: Add fixup support of multiple banks of memory

Quoted 21 lines · John Rigby

Kumar, Grant:
Quoted 3 lines · Grant Likely
Quoted 2 lines · John Rigby
Quoted 1 line · Kumar Gala
....
Quoted 11 lines
Quoted 2 lines
Quoted 2 lines
The problem w/libfdt is that use of 'offsets' to get to nodes can be problematic if the offset changes while manipulating it. ?There are ways around thus but a number of functions we do would benefit from a more live tree.
This is actually a really good point. ?Offsets changing under your feet is just asking for bugs. ?I could see this as being a legitimate justification for having a live tree model in libfdt and the ability to transition between the live and flat representations. ?I was against this when we chatted on IRC the other day as it sounds like overkill, but this is a legitimate concern. ?dtc has a live tree representation that could probably be migrated into libfdt.

Quoted 7 lines

I don't think I fully understood Kumar's question when he first sent it. ?Now I want to understand. ?Are these gotcha's and workaround's with libfdt documented anywhere? ?If not then I would be willing to write up something. ?But I'll need some pointers to get me started. In the longer term how much work do you think it would be to make libfdt's internal representation dynamic? ?I would be willing spend some time on this if the consensus is that it is worth having.

libfdt's implementation is *by design* static so that is can be easily supported in minimal firmwares. The live tree would be an additional model in addition to the flattree routines. Take a look in the dtc repo to see how the the device tree compiler uses it.

Scott Wood

2010-08-10 22:22 UTC #10 lore raw

RFC 1/3 FDT: Add fixup support of multiple banks of memory

In reply to Grant Likely

Quoted 11 lines · On Tue, 10 Aug 2010 13:39:57 -0600 Grant Likely <[email protected]>…

:-)
I still stand on my point that hard coding device tree manipulations is asking for trouble. IMNSHO, firmware should really be restricted to very well defined things in the device tree. I've been thinking about this a lot, and I'm going to write a "Recommended Practice" document for dealing with the .dtb at the firmware level. At the moment, I think firmware should be restricted to only touching the /chosen node, the /memory node, and updating well defined things like mac address, but only when the Ethernet node is dereferenced from an /aliases name instead of full path.

When I try to think of the fundamental difference between the above modifications and others, the main thing that I see is maturity/stability. There's nothing special about these except that we've already gone through the pain, and believe (but can't be certain) we've got it right now. We had problems with the /chosen node (must already exist, can't already exist, etc). We did other things before for MAC addresses (hard-coded paths, "mac-address" versus "local-mac-address", etc). What happens if we need multiple memory nodes? What happens if u-boot's use of aliases contradicts some other use? Are even additional types of clock updates off-limits? What about looking up by compatible and distinguishing by address?

I think a question we need to answer is, what *is* the device tree? Is it just a convenient way for Linux to organize its knowledge about the hardware -- in which case, would we have been better off by having firmware not touch it at all, and instead do something like cuImage with bd_t replaced by something more robust and extensible (but not as complicated as a full device tree)?

Or is the device tree a bundle of information handed to the OS by whatever came before it (be it firmware, a replaceable chunk of code sitting on top of firmware, a hypervisor, static partitioning provided by the system designer, or early Linux code to transform a known type of bad device tree into a good one)? This is what it was in Open Firmware, and is my understanding of what it was meant to be in ePAPR.

I think the latter is far more useful. It involves a greater compatibility challenge, but there are escape hatches short of replacing firmware. It scares me less than trying to maintain a static device tree for every way the p4080 reference board could be configured (and deal with support when people use the wrong one). :-)

Quoted 10 lines

I *might* be able to be convinced that firmware should be allowed to modify other properties, but only if it isn't hard coded into the firmware (ie, by using a boot script or other method that can be changed without upgrading firmware). As we've discovered in the past, it is very easy to get into a situation where firmware must be upgraded to deal with a change in the device tree data. (ie. soc node name cannot be changed from "soc5200" to "soc" on the lite5200 because older versions of U-Boot do a pathname lookup) This risk can be mitigated if there are some well defined rules about what firmware is and is not allowed to modify in the tree.

There are other ways to mitigate the risk, such as having a recovery mode that boots a different firmware image.

Even if you are stuck with firmware that wants to do broken device tree updates, there are options:
- Use a dts that works with the old firmware, and have a wrapper that fixes up whatever you wanted to change in the final tree after the firmware's done with it.
- Have two trees. Give u-boot a dtb it likes, and have glue code suck out important bits to stick into the real dtb. Kind of like cuImage, but with a noncompliant dtb instead of bd_t.
- Tell u-boot to not do any updates (I think this is possible if you use the subcommand version of bootm and do each stage manually -- or you could give uboot some dummy dtb that it likes and put the real thing in a dtbImage) and hard code everything in the dts.
- Just have the OS retain compatibility with the old binding, if it's not completely unusable.

Making the device tree manipulation code replaceable would be nice. In cases where we want to convey some knowledge from the fixed part of the firmware, it would not be too different from unconditionally doing the two-tree thing, except that the firmware tree would be simpler and not associated with the user-supplied dts (i.e. a "better bd_t"), and the glue code wouldn't be tied to a particular OS.

-Scott

Can Aydin

2010-09-28 09:56 UTC #11 lore raw

cover Add support for Freescale's 85xx and P1/P2xxx eSPI controller

In reply to Kumar Gala

Hi All,

This patch series adds support for the eSPI controller found on the newer range of Freescale SoCs including the 85xx, P1/P2xx (and I believe the P4xx) series.

The reason this is an RFC is that unfortunately the hardware on these chips does not permit indefinite SPI transactions on a given chip select. A chip select is asserted only when a 'transaction length' has been passed to the controller. Once the number of characters specified in the transaction length have been transmitted, the controller decides that the 'frame' has ended and de-asserts the chip select after a defined delay. It is not possible to initiate a second transfer without re-initialising the command register, and hence clearing and re-asserting a chip select signal.

This patch set addresses the issue by defining a read/write function in the spi_flash_internal API. Subsequent patches add the freescale eSPI driver and add support for it in the spansion driver and the P1/P2 board configuration header.

I'm pretty sure that there are better ways of doing this, especially if a driver model with support for driver quirks was implemented for instance. Until then however, I assume having some sort of ability to use the SPI controller on these boards would be better than not being able to do anything at all. If anyone has a better solution please feel free to comment.

Regards,

Can

  drivers/mtd/spi/spansion.c           |   60 ++++++++-
  drivers/mtd/spi/spi_flash.c          |   38 +++++-
  drivers/mtd/spi/spi_flash_internal.h |    9 ++
  drivers/spi/Makefile                 |    1 +
  drivers/spi/fsl_espi.c               |  251 
++++++++++++++++++++++++++++++++++
  include/configs/P1_P2_RDB.h          |   18 +++
  include/fsl_espi.h                   |   50 +++++++
  7 files changed, 419 insertions(+), 8 deletions(-)

mode change 100644 => 100755 drivers/mtd/spi/spansion.c mode change 100644 => 100755 drivers/mtd/spi/spi_flash.c mode change 100644 => 100755 drivers/mtd/spi/spi_flash_internal.h create mode 100755 drivers/spi/fsl_espi.c
create mode 100755 include/fsl_espi.h

Reinhard Meyer

2010-09-28 11:02 UTC #12 lore raw

cover Add support for Freescale's 85xx and P1/P2xxx eSPI controller

Dear Can Aydin,

Quoted 15 lines

The reason this is an RFC is that unfortunately the hardware on these chips does not permit indefinite SPI transactions on a given chip select. A chip select is asserted only when a 'transaction length' has been passed to the controller. Once the number of characters specified in the transaction length have been transmitted, the controller decides that the 'frame' has ended and de-asserts the chip select after a defined delay. It is not possible to initiate a second transfer without re-initialising the command register, and hence clearing and re-asserting a chip select signal.
This patch set addresses the issue by defining a read/write function in the spi_flash_internal API. Subsequent patches add the freescale eSPI driver and add support for it in the spansion driver and the P1/P2 board configuration header.

Quoted 6 lines

I'm pretty sure that there are better ways of doing this, especially if a driver model with support for driver quirks was implemented for instance. Until then however, I assume having some sort of ability to use the SPI controller on these boards would be better than not being able to do anything at all. If anyone has a better solution please feel free to comment.

Can the Chip Select Pins be used as GPIO? It might be simpler to do that than adding a speciality to common code.

Quoted 5 lines

   mode change 100644 =>  100755 drivers/mtd/spi/spansion.c
   mode change 100644 =>  100755 drivers/mtd/spi/spi_flash.c
   mode change 100644 =>  100755 drivers/mtd/spi/spi_flash_internal.h

create mode 100755 drivers/spi/fsl_espi.c
create mode 100755 include/fsl_espi.h

Having edited from W****** using Samba?
Make sure the file modes are and stay 644!

Without looking at the functionality I saw several coding style issues in the patch series:
+ if ( cmd_len&& cmd )
+ memcpy(buffer, cmd, cmd_len);
should be like "if (cmd_len && cmd)"

Similar space issues seem to happen all over your patches, examples:

+ for ( i = 0; i< size; i++)

+ return bus == 0&& cs< ESPI_MAX_CS_NUM;

+#define ESPI_COM_CS(x) ((x)<< 30)

You need to fix that globally...

Best Regards,

Reinhard

PS: you might want to wait and see if that patch in common code to fix a special hardware issue is welcome@all ;)

Can Aydin

2010-09-28 11:49 UTC #13 lore raw

cover Add support for Freescale's 85xx and P1/P2xxx eSPI controller

Dear Reinhard,

Quoted 22 lines · Reinhard Meyer

Dear Can Aydin,
Quoted 15 lines
The reason this is an RFC is that unfortunately the hardware on these chips does not permit indefinite SPI transactions on a given chip select. A chip select is asserted only when a 'transaction length' has been passed to the controller. Once the number of characters specified in the transaction length have been transmitted, the controller decides that the 'frame' has ended and de-asserts the chip select after a defined delay. It is not possible to initiate a second transfer without re-initialising the command register, and hence clearing and re-asserting a chip select signal.
This patch set addresses the issue by defining a read/write function in the spi_flash_internal API. Subsequent patches add the freescale eSPI driver and add support for it in the spansion driver and the P1/P2 board configuration header.
Quoted 6 lines
I'm pretty sure that there are better ways of doing this, especially if a driver model with support for driver quirks was implemented for instance. Until then however, I assume having some sort of ability to use the SPI controller on these boards would be better than not being able to do anything at all. If anyone has a better solution please feel free to comment.

Quoted 3 lines

Can the Chip Select Pins be used as GPIO? It might be simpler to do that than
adding a speciality to common code.

True, a GPIO pin could be re-purposed to serve as chip select, but that would involve a soldering iron and a steady hand as the P1/P2xxRDB boards are reference design boards sold by a lot of third party vendors (including Denx if I'm not mistaken) this would detract from the ability to just plug u-boot in and run with it.

People could also choose to bitbang the SPI on their custom hardware but again I feel that might defeat the purpose and spirit of u-boot. (Then again, I'm new so don't quote me on that).

Quoted 8 lines

Quoted 6 lines
   mode change 100644 =>  100755 drivers/mtd/spi/spansion.c
   mode change 100644 =>  100755 drivers/mtd/spi/spi_flash.c
   mode change 100644 =>  100755 drivers/mtd/spi/spi_flash_internal.h
create mode 100755 drivers/spi/fsl_espi.c
create mode 100755 include/fsl_espi.h
Having edited from W****** using Samba?
Make sure the file modes are and stay 644!

Dammit, I was hoping to not let on about that. Yes, I am unfortunately confined to a certain OS due to certain factors. Will fix those.

Quoted 16 lines

Without looking at the functionality I saw several coding style issues in the patch series:
(quoted diff) +2 -0
+    if ( cmd_len&&  cmd )
+        memcpy(buffer, cmd, cmd_len);
should be like "if (cmd_len && cmd)"
Similar space issues seem to happen all over your patches, examples:
(quoted diff) +3 -0
+    for ( i = 0; i<  size; i++)
 
+    return bus == 0&&  cs<  ESPI_MAX_CS_NUM;
 
+#define ESPI_COM_CS(x)        ((x)<<  30)

Quoted 1 line

You need to fix that globally...

Again I plead newbie. Will fix also.

Quoted 8 lines

Best Regards,
Reinhard
PS: you might want to wait and see if that patch in common code to fix a special hardware issue is welcome at all ;)

Well, even if the common code patch is rejected (and breaking the spi_flash abstraction was definitely not the high point of my day), at least the cmd_spi module will work with these boards if only the driver patch gets in. Even that might help those trying to get their own hw off the ground at least somewhat.

Can Aydin

2010-09-28 12:27 UTC #14 lore raw

cover Add support for Freescale's 85xx and P1/P2xxx eSPI controller

Quoted 11 lines

Quoted 5 lines
Can the Chip Select Pins be used as GPIO? It might be simpler to do that than
adding a speciality to common code.
True, a GPIO pin could be re-purposed to serve as chip select, but that would involve a soldering iron and a steady hand as the P1/P2xxRDB boards are reference design boards sold by a lot of third party vendors (including Denx if I'm not mistaken) this would detract from the ability to just plug u-boot in and run with it.

Quoted 4 lines

People could also choose to bitbang the SPI on their custom hardware but again I feel that might defeat the purpose and spirit of u-boot. (Then again, I'm new so don't quote me on that).

Quick followup, I may have misunderstood that question. The SPI pins can only be re-purposed as extra data pins for the SDHC. It's not possible to use them as GPIO.

Wolfgang Denk

2010-09-28 12:46 UTC #15 lore raw

cover Add support for Freescale's 85xx and P1/P2xxx eSPI controller

In reply to Can Aydin

Dear Can Aydin,

Quoted 6 lines · In message <[email protected]> you wrote:

Quoted 4 lines
Can the Chip Select Pins be used as GPIO? It might be simpler to do that than
adding a speciality to common code.
True, a GPIO pin could be re-purposed to serve as chip select, but that would involve a soldering iron and a steady hand as the P1/P2xxRDB

That was not the question.

Reinhard asked if the SPI Chip Select Pins could be configured such so that they can be used in GPIO mode instead of special function mode. That would make code way simpler.

Quoted 3 lines

People could also choose to bitbang the SPI on their custom hardware but again I feel that might defeat the purpose and spirit of u-boot. (Then again, I'm new so don't quote me on that).

Oops? Where exactly do you see conflicts with "the purpose and spirit" of U-Boot?

Best regards,

Wolfgang Denk

Signature · 6 lines

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Where humor is concerned there are no standards -- no  one  can  say
what is good or bad, although you can be sure that everyone will.
- John Kenneth Galbraith

Reinhard Meyer

2010-09-28 13:22 UTC #16 lore raw

cover Add support for Freescale's 85xx and P1/P2xxx eSPI controller

Dear Wolfgang Denk, Can Aydin,

Quoted 8 lines

Quoted 2 lines
True, a GPIO pin could be re-purposed to serve as chip select, but that would involve a soldering iron and a steady hand as the P1/P2xxRDB
That was not the question.
Reinhard asked if the SPI Chip Select Pins could be configured such so that they can be used in GPIO mode instead of special function mode. That would make code way simpler.

Exactly. Just have this pin work as GPIO, while the rest stays special function. But then, some SoCs can not individually assign pins to special functions but can only do that in groups. Maybe that's the issue here.

And then: currently an "sf write" is not restricted in the length of data written. It would be limited due to the malloc needed for the patch.

Reinhard

Can Aydin

2010-09-28 23:37 UTC #17 lore raw

cover Add support for Freescale's 85xx and P1/P2xxx eSPI controller

Quoted 11 lines · Reinhard Meyer

Dear Wolfgang Denk, Can Aydin,
Quoted 7 lines
Quoted 2 lines
True, a GPIO pin could be re-purposed to serve as chip select, but that would involve a soldering iron and a steady hand as the P1/P2xxRDB
That was not the question.
Reinhard asked if the SPI Chip Select Pins could be configured such so that they can be used in GPIO mode instead of special function mode. That would make code way simpler.
Exactly. Just have this pin work as GPIO, while the rest stays special function. But then, some SoCs can not individually assign pins to special functions but can only do that in groups. Maybe that's the issue here.

Yes, I realized that was the actual question after I sent the reply. Unfortunately GPIO is not an option for the SPI pins on these particular SoCs.
They can only be used either as SPI or as extra data pins for the SDHC.

Quoted 5 lines

And then: currently an "sf write" is not restricted in the length of data written. It would be limited due to the malloc needed for the patch.
Reinhard

Signature · 10 lines

*Can Aydin*
Software Engineer
Locata Corporation
can.aydin at locatacorp.com

Locata Corporation Pty Ltd
Level 1, 111 Canberra Ave
Griffith ACT 2603 Australia
Phone +612 6126 5734
Fax +612 6126 5704

Can Aydin

2010-09-28 23:50 UTC #18 lore raw

cover Add support for Freescale's 85xx and P1/P2xxx eSPI controller

In reply to Wolfgang Denk

Dear Wolfgang,

Quoted 7 lines · Wolfgang Denk

Quoted 5 lines
People could also choose to bitbang the SPI on their custom hardware but again I feel that might defeat the purpose and spirit of u-boot. (Then again, I'm new so don't quote me on that).
Oops? Where exactly do you see conflicts with "the purpose and spirit" of U-Boot?

I was mostly referring to u-boot's aim of being a universal boot loader. As an analogy to the Linux kernel, when attempting to support multiple architectures and platforms, there is often the inevitable case where unfortunate hardware quirks have to be handled by some sort of framework for dealing with special cases in the driver model.

As the SPI pins cannot be driven as GPIO, anyone who wants to use this particular feature will necessarily have to implement their own workarounds in the current u-boot code.

Would a better starting point be to just submit the driver(which works fine standalone with cmd_spi) and leave the discussions regarding spi_flash common code for further debate?

Can

Xie Shaohui-B21989

2010-10-13 10:25 UTC #19 lore raw

cover Add support for Freescale's 85xx and P1/P2xxx eSPI controller

In reply to Can Aydin

Hi Can,

Are there any differences between your patches and
http://lists.denx.de/pipermail/u-boot/2009-March/049093.html ?

Best Regards,
Shaohui Xie

Quoted 2 lines

-----Original Message-----
From: u-boot-bounces at lists.denx.de

[mailto:u-boot-bounces at lists.denx.de]

Quoted 4 lines

On Behalf Of Can Aydin
Sent: Tuesday, September 28, 2010 5:57 PM
To: u-boot at lists.denx.de
Subject: [U-Boot] [RFC] [PATCH 0/4] Add support for Freescale's 85xx

and

Quoted 7 lines

P1/P2xxx eSPI controller
Hi All,
This patch series adds support for the eSPI controller found on the

newer

Quoted 5 lines

range of Freescale SoCs including the 85xx, P1/P2xx (and I believe the P4xx) series.
The reason this is an RFC is that unfortunately the hardware on these chips does not permit indefinite SPI transactions on a given chip

select.

Quoted 2 lines

A chip select is asserted only when a 'transaction length' has been passed to the controller. Once the number of characters specified in

the

Quoted 1 line

transaction length have been transmitted, the controller decides that

the

Quoted 1 line

'frame' has ended and de-asserts the chip select after a defined

delay.

Quoted 1 line

It is not possible to initiate a second transfer without

re-initialising

Quoted 1 line

the command register, and hence clearing and re-asserting a chip

select

Quoted 3 lines

signal.
This patch set addresses the issue by defining a read/write function

Quoted 2 lines

the spi_flash_internal API. Subsequent patches add the freescale eSPI driver and add support for it in the spansion driver and the P1/P2

board

Quoted 3 lines

configuration header.
I'm pretty sure that there are better ways of doing this, especially

if a

Quoted 1 line

driver model with support for driver quirks was implemented for

instance.

Quoted 1 line

Until then however, I assume having some sort of ability to use the

SPI

Quoted 31 lines

controller on these boards would be better than not being able to do anything at all. If anyone has a better solution please feel free to comment.
Regards,
Can
--
  drivers/mtd/spi/spansion.c           |   60 ++++++++-
  drivers/mtd/spi/spi_flash.c          |   38 +++++-
  drivers/mtd/spi/spi_flash_internal.h |    9 ++
  drivers/spi/Makefile                 |    1 +
  drivers/spi/fsl_espi.c               |  251
++++++++++++++++++++++++++++++++++
  include/configs/P1_P2_RDB.h          |   18 +++
  include/fsl_espi.h                   |   50 +++++++
  7 files changed, 419 insertions(+), 8 deletions(-)
mode change 100644 => 100755 drivers/mtd/spi/spansion.c mode change 100644 => 100755 drivers/mtd/spi/spi_flash.c mode change 100644 => 100755 drivers/mtd/spi/spi_flash_internal.h create mode 100755 drivers/spi/fsl_espi.c
create mode 100755 include/fsl_espi.h
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Can Aydin

2010-10-27 10:50 UTC #20 lore raw

cover Add support for Freescale's 85xx and P1/P2xxx eSPI controller

Quoted 9 lines · On 13/10/2010 9:25 PM, Xie Shaohui-B21989 wrote:

Hi Can,
Are there any differences between your patches and
http://lists.denx.de/pipermail/u-boot/2009-March/049093.html ?
Best Regards,
Shaohui Xie

Hello Shaohui,

Firstly, I apologize for responding so late, we've been having some issues with our mail server.

In terms of differences, the big trivial one is that any modifications to common code such as spi_flash have been removed from the latest iteration of the patch. It is now just an eSPI driver with support added for cmd_spi in P1_P2_RDB.h.

You'll note that the more significant change is that the spi_xfer function works quite differently now; the older version called an 80us delay between the tx and rx buffer accesses and always assumed that the rx buffer had valid data, this caused problems when transferring large amounts data at higher clock rates as tx/rx over-/under-flows would cause data corruption.

Hence, additional macros have also been defined for the various register fields that need to be checked for tx/rx buffer states during the read/write cycle.

Smaller, more cosmetic changes have also been made to reduce magic numbers and such.

I've been trying to send in the v3 submission of the patch for a couple of days now but have not, as yet, succeeded in getting it through. Third time lucky I hope.

Regards,

Can

John Rigby

author

2010-08-05 22:14 UTC #21 lore raw

RFC 2/3 ARM: WIP: add flat device tree support

In reply to John Rigby

Add device tree support for ARM. Based on other existing implementations.

Signed-off-by John Rigby <[email protected]>

---
 arch/arm/include/asm/config.h |    1 +
 arch/arm/lib/bootm.c          |  128 ++++++++++++++++++++++++++++++++++++++++-
 common/cmd_bootm.c            |    5 +-
 common/image.c                |    7 ++-
 include/image.h               |    2 +-
 5 files changed, 138 insertions(+), 5 deletions(-)

arch/arm/include/asm/config.h +1 -0

index b76fd8e..9bca5bc 100644
@@ -23,5 +23,6 @@
 
 /* Relocation to SDRAM works on all ARM boards */
 #define CONFIG_RELOC_FIXUP_WORKS
+#define CONFIG_LMB
 
 #endif

arch/arm/lib/bootm.c +126 -2

162 lines not on this page · raw message

common/cmd_bootm.c +4 -1

index 594bccb..c6207cf 100644
@@ -301,7 +301,10 @@ static int bootm_start(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]
 		}
 
 #if defined(CONFIG_OF_LIBFDT)
-#if defined(CONFIG_PPC) || defined(CONFIG_M68K) || defined(CONFIG_SPARC)
+#if defined(CONFIG_PPC) || \
+    defined(CONFIG_M68K) || \
+    defined(CONFIG_SPARC) || \
+    defined(CONFIG_ARM)
 		/* find flattened device tree */
 		ret = boot_get_fdt (flag, argc, argv, &images,
 				    &images.ft_addr, &images.ft_len);

common/image.c +6 -1

index 6d8833e..6da38aa 100644
@@ -985,7 +985,10 @@ int boot_get_ramdisk (int argc, char * const argv[], bootm_headers_t *images,
 	return 0;
 }
 
-#if defined(CONFIG_PPC) || defined(CONFIG_M68K) || defined(CONFIG_SPARC)
+#if defined(CONFIG_PPC) || \
+    defined(CONFIG_M68K) || \
+    defined(CONFIG_SPARC) || \
+    defined(CONFIG_ARM)
 /**
  * boot_ramdisk_high - relocate init ramdisk
  * @lmb: pointer to lmb handle, will be used for memory mgmt

@@ -1206,9 +1209,11 @@ int boot_relocate_fdt (struct lmb *lmb, ulong bootmap_base,
 	if (fdt_blob < (char *)bootmap_base)
 		relocate = 1;
 
+#ifdef CONFIG_SYS_BOOTMAPSZ
 	if ((fdt_blob + *of_size + CONFIG_SYS_FDT_PAD) >=
 			((char *)CONFIG_SYS_BOOTMAPSZ + bootmap_base))
 		relocate = 1;
+#endif
 
 	/* move flattend device tree if needed */
 	if (relocate) {

include/image.h +1 -1

index bcc08d1..8f06cdc 100644
@@ -339,7 +339,7 @@ int boot_relocate_fdt (struct lmb *lmb, ulong bootmap_base,
 		char **of_flat_tree, ulong *of_size);
 #endif
 
-#if defined(CONFIG_PPC) || defined(CONFIG_M68K)
+#if defined(CONFIG_PPC) || defined(CONFIG_M68K) || defined(CONFIG_ARM)
 int boot_ramdisk_high (struct lmb *lmb, ulong rd_data, ulong rd_len,
 		  ulong *initrd_start, ulong *initrd_end);

Signature · 1 line

1.7.0.4

Wolfgang Denk

2010-08-05 22:31 UTC #22 lore raw

RFC 2/3 ARM: WIP: add flat device tree support

Dear John Rigby,

Quoted 22 lines · In message <[email protected]> you wrote:

Add device tree support for ARM. Based on other existing implementations.
...
arch/arm/lib/bootm.c +8 -0
+#ifdef CONFIG_USB_DEVICE
+	{
+		extern void udc_disconnect(void);
+		udc_disconnect();
+	}
+#endif
+
+	cleanup_before_linux();
Should the udc_disconnect(); call not be moved into cleanup_before_linux() ?
common/cmd_bootm.c +4 -0
+#if defined(CONFIG_PPC) || \
+    defined(CONFIG_M68K) || \
+    defined(CONFIG_SPARC) || \
+    defined(CONFIG_ARM)

Quoted 1 line

Please sort such lists.

Best regards,

Wolfgang Denk

Signature · 4 lines

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Why is an average signature file longer than an average Perl script??

John Rigby

author

2010-08-05 23:07 UTC #23 lore raw

RFC 2/3 ARM: WIP: add flat device tree support

Thanks for the quick review. I'll make your suggested fixes and resubmit.

Quoted 37 lines · Wolfgang Denk

Dear John Rigby,
Quoted 17 lines · In message <[email protected]> you wrote:
Add device tree support for ARM. ?Based on other existing implementations.
...
(quoted diff) +8 -0
+#ifdef CONFIG_USB_DEVICE
+ ? ? {
+ ? ? ? ? ? ? extern void udc_disconnect(void);
+ ? ? ? ? ? ? udc_disconnect();
+ ? ? }
+#endif
+
+ ? ? cleanup_before_linux();
Should the udc_disconnect(); call not be moved into cleanup_before_linux() ?
Quoted 6 lines
+#if defined(CONFIG_PPC) || \
+ ? ?defined(CONFIG_M68K) || \
+ ? ?defined(CONFIG_SPARC) || \
+ ? ?defined(CONFIG_ARM)
Please sort such lists.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, ? ? MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Why is an average signature file longer than an average Perl script??

Grant Likely

2010-08-10 19:44 UTC #24 lore raw

RFC 2/3 ARM: WIP: add flat device tree support

In reply to John Rigby

Quoted 2 lines · John Rigby

Add device tree support for ARM. ?Based on other existing implementations.

Hi John,

minor comments.

Quoted 29 lines

Signed-off-by John Rigby <[email protected]>
---
?arch/arm/include/asm/config.h | ? ?1 +
?arch/arm/lib/bootm.c ? ? ? ? ?| ?128 ++++++++++++++++++++++++++++++++++++++++-
?common/cmd_bootm.c ? ? ? ? ? ?| ? ?5 +-
?common/image.c ? ? ? ? ? ? ? ?| ? ?7 ++-
?include/image.h ? ? ? ? ? ? ? | ? ?2 +-
?5 files changed, 138 insertions(+), 5 deletions(-)
arch/arm/include/asm/config.h +0 -0
index b76fd8e..9bca5bc 100644
@@ -23,5 +23,6 @@
 
?/* Relocation to SDRAM works on all ARM boards */ ?#define CONFIG_RELOC_FIXUP_WORKS
+#define CONFIG_LMB
?#endif
arch/arm/lib/bootm.c +0 -0
index 3101321..e45d974 100644
@@ -27,6 +27,12 @@
?#include <u-boot/zlib.h>
?#include <asm/byteorder.h>

arch/arm/lib/bootm.c line 35

Quoted 6 lines

arch/arm/lib/bootm.c +6 -0

+#if defined(CONFIG_OF_LIBFDT)
+#include <fdt.h>
+#include <libfdt.h>
+#include <fdt_support.h>
+#endif
+

Can these be included unconditionally? Will they hurt anything when CONFIG_OF_LIBFDT is not selected? (and if they do, maybe the headers themselves should be fixed to be safe)

Quoted 86 lines

?DECLARE_GLOBAL_DATA_PTR;

?#if defined (CONFIG_SETUP_MEMORY_TAGS) || \

arch/arm/lib/bootm.c +0 -0

@@ -50,7 +56,34 @@ static void setup_end_tag (bd_t *bd);
 ?static struct tag *params;

?#endif /* CONFIG_SETUP_MEMORY_TAGS || CONFIG_CMDLINE_TAG || CONFIG_INITRD_TAG */

arch/arm/lib/bootm.c +28 -1

-int do_bootm_linux(int flag, int argc, char * const argv[], bootm_headers_t *images)
+static ulong get_sp(void);
+#if defined(CONFIG_OF_LIBFDT)
+static int bootm_linux_fdt(bootm_headers_t *images);
+#endif
+
+void arch_lmb_reserve(struct lmb *lmb)
+{
+ ? ? ? ulong sp;
+
+ ? ? ? /*
+ ? ? ? ?* Booting a (Linux) kernel image
+ ? ? ? ?*
+ ? ? ? ?* Allocate space for command line and board info - the
+ ? ? ? ?* address should be as high as possible within the reach of
+ ? ? ? ?* the kernel (see CONFIG_SYS_BOOTMAPSZ settings), but in unused
+ ? ? ? ?* memory, which means far enough below the current stack
+ ? ? ? ?* pointer.
+ ? ? ? ?*/
+ ? ? ? sp = get_sp();
+ ? ? ? debug("## Current stack ends at 0x%08lx ", sp);
+
+ ? ? ? /* adjust sp by 1K to be safe */
+ ? ? ? sp -= 1024;
+ ? ? ? lmb_reserve(lmb, sp,
+ ? ? ? ? ? ? ? ? ? gd->bd->bi_dram[0].start + gd->bd->bi_dram[0].size - sp);
+}
+
+int do_bootm_linux(int flag, int argc, char *argv[], bootm_headers_t *images)

?{
? ? ? ?bd_t ? ?*bd = gd->bd;
? ? ? ?char ? ?*s;

arch/arm/lib/bootm.c +5 -0

@@ -64,6 +97,11 @@ int do_bootm_linux(int flag, int argc, char * const argv[], bootm_headers_t *ima
 ? ? ? ?if ((flag != 0) && (flag != BOOTM_STATE_OS_GO))
 ? ? ? ? ? ? ? ?return 1;
 
+#ifdef CONFIG_OF_LIBFDT
+ ? ? ? if (images->ft_len)
+ ? ? ? ? ? ? ? return bootm_linux_fdt(images);
+#endif
+
 ? ? ? ?theKernel = (void (*)(int, int, uint))images->ep;
 
 ? ? ? ?s = getenv ("machid");

@@ -99,7 +137,7 @@ int do_bootm_linux(int flag, int argc, char * const argv[], bootm_headers_t *ima
 ? ? ? ?if (images->rd_start && images->rd_end)
 ? ? ? ? ? ? ? ?setup_initrd_tag (bd, images->rd_start, images->rd_end);

?#endif
- ? ? ? setup_end_tag (bd);
+ ? ? ? setup_end_tag(bd);
?#endif

? ? ? ?/* we assume that the kernel is in place */

arch/arm/lib/bootm.c +22 -0

@@ -120,6 +158,84 @@ int do_bootm_linux(int flag, int argc, char * const argv[], bootm_headers_t *ima
 ? ? ? ?return 1;
 ?}
 
+#if defined(CONFIG_OF_LIBFDT)
+static int fixup_memory_node(void *blob)
+{
+ ? ? ? bd_t ? ?*bd = gd->bd;
+ ? ? ? int bank;
+ ? ? ? u64 start[CONFIG_NR_DRAM_BANKS];
+ ? ? ? u64 size[CONFIG_NR_DRAM_BANKS];
+
+ ? ? ? for (bank = 0; bank < CONFIG_NR_DRAM_BANKS; bank++) {
+ ? ? ? ? ? ? ? start[bank] = bd->bi_dram[bank].start;
+ ? ? ? ? ? ? ? size[bank] = bd->bi_dram[bank].size;
+ ? ? ? }
+
+ ? ? ? return fdt_fixup_memory_banks(blob, start, size, CONFIG_NR_DRAM_BANKS);
+}
+
+static int bootm_linux_fdt(bootm_headers_t *images)
+{
+ ? ? ? ulong rd_len;
+ ? ? ? bd_t *bd = gd->bd;
+ ? ? ? char *s;
+ ? ? ? int machid = bd->bi_arch_number;

arch/arm/lib/bootm.c int do_bootm_linux(int flag, int argc, char * const argv[], bootm_headers_t *ima · line 192

Quoted 10 lines

arch/arm/lib/bootm.c +10 -0

+ ? ? ? void (*theKernel)(int zero, int dt_machid, void *dtblob);
+ ? ? ? ulong bootmap_base = getenv_bootm_low();
+ ? ? ? ulong of_size = images->ft_len;
+ ? ? ? char **of_flat_tree = &images->ft_addr;
+ ? ? ? ulong *initrd_start = &images->initrd_start;
+ ? ? ? ulong *initrd_end = &images->initrd_end;
+ ? ? ? struct lmb *lmb = &images->lmb;
+ ? ? ? int ret;
+
+ ? ? ? theKernel = (void (*)(int, int, void *))images->ep;

U-Boot naming convention is lowercase with underscores, just like the kernel.

Quoted 67 lines

arch/arm/lib/bootm.c +54 -0

+
+ ? ? ? s = getenv("machid");
+ ? ? ? if (s) {
+ ? ? ? ? ? ? ? machid = simple_strtoul(s, NULL, 16);
+ ? ? ? ? ? ? ? printf("Using machid 0x%x from environment\n", machid);
+ ? ? ? }
+
+ ? ? ? show_boot_progress(15);
+
+ ? ? ? rd_len = images->rd_end - images->rd_start;
+ ? ? ? ret = boot_ramdisk_high(lmb, images->rd_start, rd_len,
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? initrd_start, initrd_end);
+ ? ? ? if (ret)
+ ? ? ? ? ? ? ? return ret;
+
+ ? ? ? ret = boot_relocate_fdt(lmb, bootmap_base, of_flat_tree, &of_size);
+ ? ? ? if (ret)
+ ? ? ? ? ? ? ? return ret;
+
+ ? ? ? debug("## Transferring control to Linux (at address %08lx) ...\n",
+ ? ? ? ? ? ? ?(ulong) theKernel);
+
+ ? ? ? fdt_chosen(*of_flat_tree, 1);
+
+ ? ? ? fixup_memory_node(*of_flat_tree);
+
+ ? ? ? fdt_initrd(*of_flat_tree, *initrd_start, *initrd_end, 1);
+
+ ? ? ? /* we assume that the kernel is in place */
+ ? ? ? printf("\nStarting kernel ...\n\n");
+
+#ifdef CONFIG_USB_DEVICE
+ ? ? ? {
+ ? ? ? ? ? ? ? extern void udc_disconnect(void);
+ ? ? ? ? ? ? ? udc_disconnect();
+ ? ? ? }
+#endif
+
+ ? ? ? cleanup_before_linux();
+
+ ? ? ? theKernel(0, machid, *of_flat_tree);
+ ? ? ? /* does not return */
+
+ ? ? ? return 1;
+}
+#endif
 
 ?#if defined (CONFIG_SETUP_MEMORY_TAGS) || \
 ? ? defined (CONFIG_CMDLINE_TAG) || \

@@ -239,4 +355,12 @@ static void setup_end_tag (bd_t *bd)
 ? ? ? ?params->hdr.size = 0;
 ?}
 
+static ulong get_sp(void)
+{
+ ? ? ? ulong ret;
+
+ ? ? ? asm("mov %0, sp" : "=r"(ret) : );
+ ? ? ? return ret;
+}
+

?#endif /* CONFIG_SETUP_MEMORY_TAGS || CONFIG_CMDLINE_TAG || CONFIG_INITRD_TAG */

common/cmd_bootm.c +0 -0

index 594bccb..c6207cf 100644

common/cmd_bootm.c static int bootm_start(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[] · line 307

Quoted 8 lines

common/cmd_bootm.c +4 -1

@@ -301,7 +301,10 @@ static int bootm_start(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]
 ? ? ? ? ? ? ? ?}
 
 ?#if defined(CONFIG_OF_LIBFDT)
-#if defined(CONFIG_PPC) || defined(CONFIG_M68K) || defined(CONFIG_SPARC)
+#if defined(CONFIG_PPC) || \
+ ? ?defined(CONFIG_M68K) || \
+ ? ?defined(CONFIG_SPARC) || \
+ ? ?defined(CONFIG_ARM)

There's got to be a better way to do this. :-) Are there other architectures from PPC, M68K and SPARC that have OF_LIBFDT set?

Quoted 52 lines

? ? ? ? ? ? ? ?/* find flattened device tree */
? ? ? ? ? ? ? ?ret = boot_get_fdt (flag, argc, argv, &images, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?&images.ft_addr, &images.ft_len);
common/image.c +4 -1
index 6d8833e..6da38aa 100644
@@ -985,7 +985,10 @@ int boot_get_ramdisk (int argc, char * const argv[], bootm_headers_t *images,
 ? ? ? ?return 0;
 ?}
 
-#if defined(CONFIG_PPC) || defined(CONFIG_M68K) || defined(CONFIG_SPARC)
+#if defined(CONFIG_PPC) || \
+ ? ?defined(CONFIG_M68K) || \
+ ? ?defined(CONFIG_SPARC) || \
+ ? ?defined(CONFIG_ARM)
?/**
?* boot_ramdisk_high - relocate init ramdisk
?* @lmb: pointer to lmb handle, will be used for memory mgmt
common/image.c +1 -0
@@ -1206,9 +1209,11 @@ int boot_relocate_fdt (struct lmb *lmb, ulong bootmap_base,
 ? ? ? ?if (fdt_blob < (char *)bootmap_base)
 ? ? ? ? ? ? ? ?relocate = 1;
 
+#ifdef CONFIG_SYS_BOOTMAPSZ
? ? ? ?if ((fdt_blob + *of_size + CONFIG_SYS_FDT_PAD) >=
? ? ? ? ? ? ? ? ? ? ? ?((char *)CONFIG_SYS_BOOTMAPSZ + bootmap_base)) ? ? ? ? ? ? ? ?relocate = 1;
+#endif
? ? ? ?/* move flattend device tree if needed */
? ? ? ?if (relocate) {
include/image.h +0 -0
index bcc08d1..8f06cdc 100644
@@ -339,7 +339,7 @@ int boot_relocate_fdt (struct lmb *lmb, ulong bootmap_base,
 ? ? ? ? ? ? ? ?char **of_flat_tree, ulong *of_size);
?#endif
include/image.h +1 -1
-#if defined(CONFIG_PPC) || defined(CONFIG_M68K)
+#if defined(CONFIG_PPC) || defined(CONFIG_M68K) || defined(CONFIG_ARM)
?int boot_ramdisk_high (struct lmb *lmb, ulong rd_data, ulong rd_len, ? ? ? ? ? ? ? ? ?ulong *initrd_start, ulong *initrd_end);
--
1.7.0.4
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Signature · 2 lines

Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Grant Likely

2010-08-10 19:46 UTC #25 lore raw

RFC 2/3 ARM: WIP: add flat device tree support

Quoted 7 lines · Grant Likely

Quoted 2 lines · John Rigby
Add device tree support for ARM. ?Based on other existing implementations.
Hi John,
minor comments.

BTW, is the u-boot fdt support code little-endian safe? libfdt should be, but does the arm support use any code written for ppc that has not been little-endian scrubbed?

Quoted 278 lines

Quoted 30 lines

Signed-off-by John Rigby <[email protected]>
---
?arch/arm/include/asm/config.h | ? ?1 +
?arch/arm/lib/bootm.c ? ? ? ? ?| ?128 ++++++++++++++++++++++++++++++++++++++++-
?common/cmd_bootm.c ? ? ? ? ? ?| ? ?5 +-
?common/image.c ? ? ? ? ? ? ? ?| ? ?7 ++-
?include/image.h ? ? ? ? ? ? ? | ? ?2 +-
?5 files changed, 138 insertions(+), 5 deletions(-)
arch/arm/include/asm/config.h +0 -0
index b76fd8e..9bca5bc 100644
@@ -23,5 +23,6 @@
 
?/* Relocation to SDRAM works on all ARM boards */ ?#define CONFIG_RELOC_FIXUP_WORKS
+#define CONFIG_LMB
?#endif
arch/arm/lib/bootm.c +0 -0
index 3101321..e45d974 100644
@@ -27,6 +27,12 @@
?#include <u-boot/zlib.h>
?#include <asm/byteorder.h>

arch/arm/lib/bootm.c line 35

Quoted 6 lines

arch/arm/lib/bootm.c +6 -0

+#if defined(CONFIG_OF_LIBFDT)
+#include <fdt.h>
+#include <libfdt.h>
+#include <fdt_support.h>
+#endif
+

Can these be included unconditionally? ?Will they hurt anything when CONFIG_OF_LIBFDT is not selected? ?(and if they do, maybe the headers themselves should be fixed to be safe)

Quoted 86 lines

?DECLARE_GLOBAL_DATA_PTR;

?#if defined (CONFIG_SETUP_MEMORY_TAGS) || \

arch/arm/lib/bootm.c +0 -0

@@ -50,7 +56,34 @@ static void setup_end_tag (bd_t *bd);
 ?static struct tag *params;

?#endif /* CONFIG_SETUP_MEMORY_TAGS || CONFIG_CMDLINE_TAG || CONFIG_INITRD_TAG */

arch/arm/lib/bootm.c +28 -1

-int do_bootm_linux(int flag, int argc, char * const argv[], bootm_headers_t *images)
+static ulong get_sp(void);
+#if defined(CONFIG_OF_LIBFDT)
+static int bootm_linux_fdt(bootm_headers_t *images);
+#endif
+
+void arch_lmb_reserve(struct lmb *lmb)
+{
+ ? ? ? ulong sp;
+
+ ? ? ? /*
+ ? ? ? ?* Booting a (Linux) kernel image
+ ? ? ? ?*
+ ? ? ? ?* Allocate space for command line and board info - the
+ ? ? ? ?* address should be as high as possible within the reach of
+ ? ? ? ?* the kernel (see CONFIG_SYS_BOOTMAPSZ settings), but in unused
+ ? ? ? ?* memory, which means far enough below the current stack
+ ? ? ? ?* pointer.
+ ? ? ? ?*/
+ ? ? ? sp = get_sp();
+ ? ? ? debug("## Current stack ends at 0x%08lx ", sp);
+
+ ? ? ? /* adjust sp by 1K to be safe */
+ ? ? ? sp -= 1024;
+ ? ? ? lmb_reserve(lmb, sp,
+ ? ? ? ? ? ? ? ? ? gd->bd->bi_dram[0].start + gd->bd->bi_dram[0].size - sp);
+}
+
+int do_bootm_linux(int flag, int argc, char *argv[], bootm_headers_t *images)

?{
? ? ? ?bd_t ? ?*bd = gd->bd;
? ? ? ?char ? ?*s;

arch/arm/lib/bootm.c +5 -0

@@ -64,6 +97,11 @@ int do_bootm_linux(int flag, int argc, char * const argv[], bootm_headers_t *ima
 ? ? ? ?if ((flag != 0) && (flag != BOOTM_STATE_OS_GO))
 ? ? ? ? ? ? ? ?return 1;
 
+#ifdef CONFIG_OF_LIBFDT
+ ? ? ? if (images->ft_len)
+ ? ? ? ? ? ? ? return bootm_linux_fdt(images);
+#endif
+
 ? ? ? ?theKernel = (void (*)(int, int, uint))images->ep;
 
 ? ? ? ?s = getenv ("machid");

@@ -99,7 +137,7 @@ int do_bootm_linux(int flag, int argc, char * const argv[], bootm_headers_t *ima
 ? ? ? ?if (images->rd_start && images->rd_end)
 ? ? ? ? ? ? ? ?setup_initrd_tag (bd, images->rd_start, images->rd_end);

?#endif
- ? ? ? setup_end_tag (bd);
+ ? ? ? setup_end_tag(bd);
?#endif

? ? ? ?/* we assume that the kernel is in place */

arch/arm/lib/bootm.c +22 -0

@@ -120,6 +158,84 @@ int do_bootm_linux(int flag, int argc, char * const argv[], bootm_headers_t *ima
 ? ? ? ?return 1;
 ?}
 
+#if defined(CONFIG_OF_LIBFDT)
+static int fixup_memory_node(void *blob)
+{
+ ? ? ? bd_t ? ?*bd = gd->bd;
+ ? ? ? int bank;
+ ? ? ? u64 start[CONFIG_NR_DRAM_BANKS];
+ ? ? ? u64 size[CONFIG_NR_DRAM_BANKS];
+
+ ? ? ? for (bank = 0; bank < CONFIG_NR_DRAM_BANKS; bank++) {
+ ? ? ? ? ? ? ? start[bank] = bd->bi_dram[bank].start;
+ ? ? ? ? ? ? ? size[bank] = bd->bi_dram[bank].size;
+ ? ? ? }
+
+ ? ? ? return fdt_fixup_memory_banks(blob, start, size, CONFIG_NR_DRAM_BANKS);
+}
+
+static int bootm_linux_fdt(bootm_headers_t *images)
+{
+ ? ? ? ulong rd_len;
+ ? ? ? bd_t *bd = gd->bd;
+ ? ? ? char *s;
+ ? ? ? int machid = bd->bi_arch_number;

arch/arm/lib/bootm.c int do_bootm_linux(int flag, int argc, char * const argv[], bootm_headers_t *ima · line 192

Quoted 10 lines

arch/arm/lib/bootm.c +10 -0

+ ? ? ? void (*theKernel)(int zero, int dt_machid, void *dtblob);
+ ? ? ? ulong bootmap_base = getenv_bootm_low();
+ ? ? ? ulong of_size = images->ft_len;
+ ? ? ? char **of_flat_tree = &images->ft_addr;
+ ? ? ? ulong *initrd_start = &images->initrd_start;
+ ? ? ? ulong *initrd_end = &images->initrd_end;
+ ? ? ? struct lmb *lmb = &images->lmb;
+ ? ? ? int ret;
+
+ ? ? ? theKernel = (void (*)(int, int, void *))images->ep;

U-Boot naming convention is lowercase with underscores, just like the kernel.

Quoted 67 lines

arch/arm/lib/bootm.c +54 -0

+
+ ? ? ? s = getenv("machid");
+ ? ? ? if (s) {
+ ? ? ? ? ? ? ? machid = simple_strtoul(s, NULL, 16);
+ ? ? ? ? ? ? ? printf("Using machid 0x%x from environment\n", machid);
+ ? ? ? }
+
+ ? ? ? show_boot_progress(15);
+
+ ? ? ? rd_len = images->rd_end - images->rd_start;
+ ? ? ? ret = boot_ramdisk_high(lmb, images->rd_start, rd_len,
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? initrd_start, initrd_end);
+ ? ? ? if (ret)
+ ? ? ? ? ? ? ? return ret;
+
+ ? ? ? ret = boot_relocate_fdt(lmb, bootmap_base, of_flat_tree, &of_size);
+ ? ? ? if (ret)
+ ? ? ? ? ? ? ? return ret;
+
+ ? ? ? debug("## Transferring control to Linux (at address %08lx) ...\n",
+ ? ? ? ? ? ? ?(ulong) theKernel);
+
+ ? ? ? fdt_chosen(*of_flat_tree, 1);
+
+ ? ? ? fixup_memory_node(*of_flat_tree);
+
+ ? ? ? fdt_initrd(*of_flat_tree, *initrd_start, *initrd_end, 1);
+
+ ? ? ? /* we assume that the kernel is in place */
+ ? ? ? printf("\nStarting kernel ...\n\n");
+
+#ifdef CONFIG_USB_DEVICE
+ ? ? ? {
+ ? ? ? ? ? ? ? extern void udc_disconnect(void);
+ ? ? ? ? ? ? ? udc_disconnect();
+ ? ? ? }
+#endif
+
+ ? ? ? cleanup_before_linux();
+
+ ? ? ? theKernel(0, machid, *of_flat_tree);
+ ? ? ? /* does not return */
+
+ ? ? ? return 1;
+}
+#endif
 
 ?#if defined (CONFIG_SETUP_MEMORY_TAGS) || \
 ? ? defined (CONFIG_CMDLINE_TAG) || \

@@ -239,4 +355,12 @@ static void setup_end_tag (bd_t *bd)
 ? ? ? ?params->hdr.size = 0;
 ?}
 
+static ulong get_sp(void)
+{
+ ? ? ? ulong ret;
+
+ ? ? ? asm("mov %0, sp" : "=r"(ret) : );
+ ? ? ? return ret;
+}
+

?#endif /* CONFIG_SETUP_MEMORY_TAGS || CONFIG_CMDLINE_TAG || CONFIG_INITRD_TAG */

common/cmd_bootm.c +0 -0

index 594bccb..c6207cf 100644

common/cmd_bootm.c static int bootm_start(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[] · line 307

Quoted 8 lines

common/cmd_bootm.c +4 -1

@@ -301,7 +301,10 @@ static int bootm_start(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]
 ? ? ? ? ? ? ? ?}
 
 ?#if defined(CONFIG_OF_LIBFDT)
-#if defined(CONFIG_PPC) || defined(CONFIG_M68K) || defined(CONFIG_SPARC)
+#if defined(CONFIG_PPC) || \
+ ? ?defined(CONFIG_M68K) || \
+ ? ?defined(CONFIG_SPARC) || \
+ ? ?defined(CONFIG_ARM)

There's got to be a better way to do this. ?:-) ?Are there other architectures from PPC, M68K and SPARC that have OF_LIBFDT set?

Quoted 44 lines

? ? ? ? ? ? ? ?/* find flattened device tree */
? ? ? ? ? ? ? ?ret = boot_get_fdt (flag, argc, argv, &images, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?&images.ft_addr, &images.ft_len);
common/image.c +4 -1
index 6d8833e..6da38aa 100644
@@ -985,7 +985,10 @@ int boot_get_ramdisk (int argc, char * const argv[], bootm_headers_t *images,
 ? ? ? ?return 0;
 ?}
 
-#if defined(CONFIG_PPC) || defined(CONFIG_M68K) || defined(CONFIG_SPARC)
+#if defined(CONFIG_PPC) || \
+ ? ?defined(CONFIG_M68K) || \
+ ? ?defined(CONFIG_SPARC) || \
+ ? ?defined(CONFIG_ARM)
?/**
?* boot_ramdisk_high - relocate init ramdisk
?* @lmb: pointer to lmb handle, will be used for memory mgmt
common/image.c +1 -0
@@ -1206,9 +1209,11 @@ int boot_relocate_fdt (struct lmb *lmb, ulong bootmap_base,
 ? ? ? ?if (fdt_blob < (char *)bootmap_base)
 ? ? ? ? ? ? ? ?relocate = 1;
 
+#ifdef CONFIG_SYS_BOOTMAPSZ
? ? ? ?if ((fdt_blob + *of_size + CONFIG_SYS_FDT_PAD) >=
? ? ? ? ? ? ? ? ? ? ? ?((char *)CONFIG_SYS_BOOTMAPSZ + bootmap_base)) ? ? ? ? ? ? ? ?relocate = 1;
+#endif
? ? ? ?/* move flattend device tree if needed */
? ? ? ?if (relocate) {
include/image.h +0 -0
index bcc08d1..8f06cdc 100644
@@ -339,7 +339,7 @@ int boot_relocate_fdt (struct lmb *lmb, ulong bootmap_base,
 ? ? ? ? ? ? ? ?char **of_flat_tree, ulong *of_size);
?#endif
include/image.h +1 -1
-#if defined(CONFIG_PPC) || defined(CONFIG_M68K)
+#if defined(CONFIG_PPC) || defined(CONFIG_M68K) || defined(CONFIG_ARM)
?int boot_ramdisk_high (struct lmb *lmb, ulong rd_data, ulong rd_len, ? ? ? ? ? ? ? ? ?ulong *initrd_start, ulong *initrd_end);

Quoted 8 lines

--
1.7.0.4
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Signature · 2 lines

Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Albert ARIBAUD

2010-08-10 20:23 UTC #26 lore raw

RFC 2/3 ARM: WIP: add flat device tree support

In reply to Grant Likely

Le 10/08/2010 21:44, Grant Likely a ?crit :

Quoted 8 lines

common/cmd_bootm.c static int bootm_start(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[] · line 307
Quoted 6 lines
  #if defined(CONFIG_OF_LIBFDT)
common/cmd_bootm.c +4 -1
-#if defined(CONFIG_PPC) || defined(CONFIG_M68K) || defined(CONFIG_SPARC)
+#if defined(CONFIG_PPC) || \
+    defined(CONFIG_M68K) || \
+    defined(CONFIG_SPARC) || \
+    defined(CONFIG_ARM)
There's got to be a better way to do this. :-)

Reminds me of an issue I encountered in my orion5x ide support patch series where I also had modified a rather complex condition in cmd_ide.c, which determined whether swapping I/O byte reads was needed.

Wolfgang had asked me to replace with a condition on a single new CONFIG_IDE_SWAP_IO macro, which in turn had to be defined in various cpu, SoC or board config files.

The patch is there:
<http://article.gmane.org/gmane.comp.boot-loaders.u-boot/82109/match=ide>

Maybe the same principle could apply here?

Amicalement,

Signature · 1 line

Albert.

John Rigby

author

2010-08-10 20:48 UTC #27 lore raw

RFC 2/3 ARM: WIP: add flat device tree support

Thanks Albert, this is an excellent idea.

Quoted 32 lines · Albert ARIBAUD

Le 10/08/2010 21:44, Grant Likely a ?crit :
Quoted 8 lines
Review
Quoted 6 lines
? #if defined(CONFIG_OF_LIBFDT)
(quoted diff) +4 -1
-#if defined(CONFIG_PPC) || defined(CONFIG_M68K) || defined(CONFIG_SPARC)
+#if defined(CONFIG_PPC) || \
+ ? ?defined(CONFIG_M68K) || \
+ ? ?defined(CONFIG_SPARC) || \
+ ? ?defined(CONFIG_ARM)
There's got to be a better way to do this. ?:-)
Reminds me of an issue I encountered in my orion5x ide support patch series where I also had modified a rather complex condition in cmd_ide.c, which determined whether swapping I/O byte reads was needed.
Wolfgang had asked me to replace with a condition on a single new CONFIG_IDE_SWAP_IO macro, which in turn had to be defined in various cpu, SoC or board config files.
The patch is there:
<http://article.gmane.org/gmane.comp.boot-loaders.u-boot/82109/match=ide>
Maybe the same principle could apply here?
Amicalement,
--
Albert.
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Wolfgang Denk

2010-08-10 21:01 UTC #28 lore raw

RFC 2/3 ARM: WIP: add flat device tree support

Dear John Rigby,

Quoted 3 lines · In message <[email protected]> you…

Thanks Albert, this is an excellent idea.
On Tue, Aug 10, 2010 at 2:23 PM, Albert ARIBAUD <[email protected]> wr=

Full quote delted.

Please DO NOT top post / full quote.

Thanks.

Wolfgang Denk

Signature · 4 lines

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Our business is run on trust.  We trust you will pay in advance.

John Rigby

author

2010-08-05 22:14 UTC #29 lore raw

RFC 3/3 ARM: add config for beagle with fdt enabled

In reply to John Rigby

This is just for testing ARM device tree support. There is no device tree enabled arm kernel at the moment.

Signed-off-by John Rigby <[email protected]>

---
 MAKEALL                           |    1 +
 boards.cfg                        |    1 +
 include/configs/omap3_beagle_dt.h |  344 +++++++++++++++++++++++++++++++++++++
 3 files changed, 346 insertions(+), 0 deletions(-)
 create mode 100644 include/configs/omap3_beagle_dt.h

MAKEALL +1 -0

index b34ae33..cdecb28 100755
@@ -654,6 +654,7 @@ LIST_ARMV7="		\
 	devkit8000		\
 	mx51evk			\
 	omap3_beagle		\
+	omap3_beagle_dt		\
 	omap3_overo		\
 	omap3_evm		\
 	omap3_pandora		\

boards.cfg +1 -0

index a70f541..09ba103 100644
@@ -259,6 +259,7 @@ omap3_pandora	arm	armv7		pandora		-		omap3
 omap3_zoom1	arm	armv7		zoom1		logicpd		omap3
 omap3_zoom2	arm	armv7		zoom2		logicpd		omap3
 omap3_beagle	arm	armv7		beagle		ti		omap3
+omap3_beagle_dt	arm	armv7		beagle		ti		omap3
 omap3_evm	arm	armv7		evm		ti		omap3
 omap3_sdp3430	arm	armv7		sdp3430		ti		omap3
 omap4_panda	arm	armv7		panda		ti		omap4

include/configs/omap3_beagle_dt.h new file +344 -0

344 lines not on this page · raw message

Signature · 1 line

1.7.0.4

Wolfgang Denk

NAK

2010-08-05 22:35 UTC #30 lore raw

RFC 3/3 ARM: add config for beagle with fdt enabled

Dear John Rigby,

Quoted 10 lines · In message <[email protected]> you wrote:

This is just for testing ARM device tree support. There is no device tree enabled arm kernel at the moment.
Signed-off-by John Rigby <[email protected]>
---
 MAKEALL                           |    1 +
 boards.cfg                        |    1 +
 include/configs/omap3_beagle_dt.h |  344 +++++++++++++++++++++++++++++++++++++
 3 files changed, 346 insertions(+), 0 deletions(-)
 create mode 100644 include/configs/omap3_beagle_dt.h

NAK.

Please do not add a separate config file where only 9 out of 344 lines are different from the existing one.

Best regards,

Wolfgang Denk

Signature · 6 lines

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
We have found all life forms in the galaxy are  capable  of  superior
development.
	-- Kirk, "The Gamesters of Triskelion", stardate 3211.7

John Rigby

2010-08-05 23:04 UTC #31 lore raw

RFC 3/3 ARM: add config for beagle with fdt enabled

Thanks for your input.I agree completely. This part was only
included for reference. And the entire series is an RFC.

Quoted 35 lines · Wolfgang Denk

Dear John Rigby,
Quoted 10 lines · In message <[email protected]> you wrote:
This is just for testing ARM device tree support. ?There is no device tree enabled arm kernel at the moment.
Signed-off-by John Rigby <[email protected]>
---
?MAKEALL ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ?1 +
?boards.cfg ? ? ? ? ? ? ? ? ? ? ? ?| ? ?1 +
?include/configs/omap3_beagle_dt.h | ?344 +++++++++++++++++++++++++++++++++++++
?3 files changed, 346 insertions(+), 0 deletions(-) ?create mode 100644 include/configs/omap3_beagle_dt.h
NAK.
Please do not add a separate config file where only 9 out of 344 lines are different from the existing one.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, ? ? MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de We have found all life forms in the galaxy are ?capable ?of ?superior development.
? ? ? ?-- Kirk, "The Gamesters of Triskelion", stardate 3211.7
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

John Rigby

author

2010-09-01 16:53 UTC #32 lore raw

cover Device tree support for ARM

In reply to John Rigby

Here is a new version of patches for adding device tree support for ARM. I have tried to address all comments made to the previous RFC patch series.

John Rigby (5):
FDT: Add fixup support for multiple banks of memory
FDT: only call boot_get_fdt from generic code
boot: change some arch ifdefs to feature ifdefs
ARM: add flat device tree support
ARM: enable device tree for beagle

 arch/arm/include/asm/config.h     |    2 +
 arch/arm/lib/bootm.c              |  138 ++++++++++++++++++++++++++++++++----
 arch/m68k/include/asm/config.h    |    3 +
 arch/microblaze/lib/bootm.c       |   12 +---
 arch/nios2/lib/bootm.c            |   10 +--
 arch/powerpc/include/asm/config.h |    3 +
 arch/sparc/include/asm/config.h   |    1 +
 common/cmd_bootm.c                |    4 +-
 common/fdt_support.c              |   86 ++++++++++++-----------
 common/image.c                    |   12 ++-
 include/configs/omap3_beagle.h    |   10 ++-
 include/fdt_support.h             |    1 +
 include/image.h                   |    9 ++-
 13 files changed, 207 insertions(+), 84 deletions(-)

John Rigby

author

2010-09-01 16:53 UTC #33 lore raw

PATCH 1/5 FDT: Add fixup support for multiple banks of memory

In reply to John Rigby

Add fdt_fixup_memory_banks and reimplement fdt_fixup_memory using it.

Signed-off-by John Rigby <[email protected]>

---
 common/fdt_support.c  |   86 ++++++++++++++++++++++++++-----------------------
 include/fdt_support.h |    1 +
 2 files changed, 47 insertions(+), 40 deletions(-)

common/fdt_support.c +46 ~~-40~~

index 33336be..0b07534 100644
@@ -362,10 +362,40 @@ void do_fixup_by_compat_u32(void *fdt, const char *compat,
 	do_fixup_by_compat(fdt, compat, prop, &val, 4, create);
 }
 
-int fdt_fixup_memory(void *blob, u64 start, u64 size)
+/*
+ * Get cells len in bytes
+ *     if #NNNN-cells property is 2 then len is 8
+ *     otherwise len is 4
+ */
+static int get_cells_len(void *blob, char *nr_cells_name)
+{
+	const u32 *cell;
+
+	cell = fdt_getprop(blob, 0, nr_cells_name, NULL);
+	if (cell && *cell == 2)
+		return 8;
+
+	return 4;
+}
+
+/*
+ * Write a 4 or 8 byte big endian cell
+ */
+static void write_cell(u8 *addr, u64 val, int size)
 {
-	int err, nodeoffset, len = 0;
-	u8 tmp[16];
+	int shift = (size - 1) * 8;
+	while (size-- > 0) {
+		*addr++ = (val >> shift) & 0xff;
+		shift -= 8;
+	}
+}
+
+int fdt_fixup_memory_banks(void *blob, u64 start[], u64 size[], int banks)
+{
+	int err, nodeoffset;
+	int addr_cell_len, size_cell_len, len;
+	u8 tmp[banks * 8];
+	int bank;
 	const u32 *addrcell, *sizecell;
 
 	err = fdt_check_header(blob);

@@ -391,44 +421,15 @@ int fdt_fixup_memory(void *blob, u64 start, u64 size)
 		return err;
 	}
 
-	addrcell = fdt_getprop(blob, 0, "#address-cells", NULL);
-	/* use shifts and mask to ensure endianness */
-	if ((addrcell) && (*addrcell == 2)) {
-		tmp[0] = (start >> 56) & 0xff;
-		tmp[1] = (start >> 48) & 0xff;
-		tmp[2] = (start >> 40) & 0xff;
-		tmp[3] = (start >> 32) & 0xff;
-		tmp[4] = (start >> 24) & 0xff;
-		tmp[5] = (start >> 16) & 0xff;
-		tmp[6] = (start >>  8) & 0xff;
-		tmp[7] = (start      ) & 0xff;
-		len = 8;
-	} else {
-		tmp[0] = (start >> 24) & 0xff;
-		tmp[1] = (start >> 16) & 0xff;
-		tmp[2] = (start >>  8) & 0xff;
-		tmp[3] = (start      ) & 0xff;
-		len = 4;
-	}
+	addr_cell_len = get_cells_len(blob, "#address-cells");
+	size_cell_len = get_cells_len(blob, "#size-cells");
 
-	sizecell = fdt_getprop(blob, 0, "#size-cells", NULL);
-	/* use shifts and mask to ensure endianness */
-	if ((sizecell) && (*sizecell == 2)) {
-		tmp[0+len] = (size >> 56) & 0xff;
-		tmp[1+len] = (size >> 48) & 0xff;
-		tmp[2+len] = (size >> 40) & 0xff;
-		tmp[3+len] = (size >> 32) & 0xff;
-		tmp[4+len] = (size >> 24) & 0xff;
-		tmp[5+len] = (size >> 16) & 0xff;
-		tmp[6+len] = (size >>  8) & 0xff;
-		tmp[7+len] = (size      ) & 0xff;
-		len += 8;
-	} else {
-		tmp[0+len] = (size >> 24) & 0xff;
-		tmp[1+len] = (size >> 16) & 0xff;
-		tmp[2+len] = (size >>  8) & 0xff;
-		tmp[3+len] = (size      ) & 0xff;
-		len += 4;
+	for (bank = 0, len = 0; bank < banks; bank++) {
+		write_cell(tmp + len, start, addr_cell_len);
+		len += addr_cell_len;
+
+		write_cell(tmp + len, start, size_cell_len);
+		len += size_cell_len;
 	}
 
 	err = fdt_setprop(blob, nodeoffset, "reg", tmp, len);

@@ -440,6 +441,11 @@ int fdt_fixup_memory(void *blob, u64 start, u64 size)
 	return 0;
 }
 
+int fdt_fixup_memory(void *blob, u64 start, u64 size)
+{
+	return fdt_fixup_memory_banks(blob, &start, &size, 1);
+}
+
 void fdt_fixup_ethernet(void *fdt)
 {
 	int node, i, j;

include/fdt_support.h +1 -0

index 871ef45..5f631ea 100644
@@ -48,6 +48,7 @@ void do_fixup_by_compat(void *fdt, const char *compat,
 void do_fixup_by_compat_u32(void *fdt, const char *compat,
 			    const char *prop, u32 val, int create);
 int fdt_fixup_memory(void *blob, u64 start, u64 size);
+int fdt_fixup_memory_banks(void *blob, u64 start[], u64 size[], int banks);
 void fdt_fixup_ethernet(void *fdt);
 int fdt_find_and_setprop(void *fdt, const char *node, const char *prop,
 			 const void *val, int len, int create);

Signature · 1 line

1.7.0.4

John Rigby

author

2010-09-01 16:53 UTC #34 lore raw

PATCH 2/5 FDT: only call boot_get_fdt from generic code

In reply to John Rigby

All arches except nios2 and microblaze call boot_get_fdt from bootm_start in common/cmd_bootm.c.

Having nios2 and microblaze do so as well removes code from their respective do_bootm_linux routines and allows removal of a nasty ifdef from bootm_start.

Signed-off-by John Rigby <[email protected]>

---
 arch/microblaze/lib/bootm.c |   12 +++---------
 arch/nios2/lib/bootm.c      |   10 +++-------
 common/cmd_bootm.c          |    2 --
 3 files changed, 6 insertions(+), 18 deletions(-)

arch/microblaze/lib/bootm.c +3 -9

index 8e2c6d8..25f63d9 100644
@@ -46,12 +46,9 @@ int do_bootm_linux(int flag, int argc, char * const argv[], bootm_headers_t *ima
 
 	char	*of_flat_tree = NULL;
 #if defined(CONFIG_OF_LIBFDT)
-	ulong	of_size = 0;
-
-	/* find flattened device tree */
-	ret = boot_get_fdt (flag, argc, argv, images, &of_flat_tree, &of_size);
-	if (ret)
-		return 1;
+	/* did generic code already find a device tree? */
+	if (images->ft_len)
+		of_flat_tree = images->ft_addr;
 #endif
 
 	theKernel = (void (*)(char *, ulong, ulong))images->ep;

@@ -64,9 +61,6 @@ int do_bootm_linux(int flag, int argc, char * const argv[], bootm_headers_t *ima
 
 	show_boot_progress (15);
 
-	if (!(ulong) of_flat_tree)
-		of_flat_tree = (char *)simple_strtoul (argv[3], NULL, 16);
-
 #ifdef DEBUG
 	printf ("## Transferring control to Linux (at address 0x%08lx) " \
 				"ramdisk 0x%08lx, FDT 0x%08lx...\n",

arch/nios2/lib/bootm.c +3 -7

index e25a113..1ff6f0a 100644
@@ -36,14 +36,10 @@ int do_bootm_linux(int flag, int argc, char * const argv[], bootm_headers_t *ima
 	ulong initrd_end = images->rd_end;
 	char *of_flat_tree = NULL;
 #if defined(CONFIG_OF_LIBFDT)
-	ulong of_size = 0;
-
-	/* find flattened device tree */
-	if (boot_get_fdt(flag, argc, argv, images, &of_flat_tree, &of_size))
-		return 1;
+	/* did generic code already find a device tree? */
+	if (images->ft_len)
+		of_flat_tree = images->ft_addr;
 #endif
-	if (!of_flat_tree)
-		of_flat_tree = (char *)simple_strtoul(argv[3], NULL, 16);
 	if (of_flat_tree)
 		initrd_end = (ulong)of_flat_tree;

common/cmd_bootm.c +0 -2

index 4c6ed48..f12e2d1 100644
@@ -301,7 +301,6 @@ static int bootm_start(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]
 		}
 
 #if defined(CONFIG_OF_LIBFDT)
-#if defined(CONFIG_PPC) || defined(CONFIG_M68K) || defined(CONFIG_SPARC)
 		/* find flattened device tree */
 		ret = boot_get_fdt (flag, argc, argv, &images,
 				    &images.ft_addr, &images.ft_len);

@@ -312,7 +311,6 @@ static int bootm_start(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]
 
 		set_working_fdt_addr(images.ft_addr);
 #endif
-#endif
 	}
 
 	images.os.start = (ulong)os_hdr;

Signature · 1 line

1.7.0.4

John Rigby

author

2010-09-01 16:53 UTC #35 lore raw

PATCH 3/5 boot: change some arch ifdefs to feature ifdefs

In reply to John Rigby

The routines boot_ramdisk_high, boot_get_cmdline and boot_get_kbd are currently enabled by various combinations of CONFIG_M68K, CONFIG_POWERPC and CONFIG_SPARC.

Use CONFIG_<FEATURE> defines instead.

CONFIG_BOOT_RAMDISK_HIGH
CONFIG_BOOT_GET_CMDLINE
CONFIG_BOOT_GET_KBD

Define these as appropriate in arch/include/asm/config.h files.

Signed-off-by John Rigby <[email protected]>

---
 arch/m68k/include/asm/config.h    |    3 +++
 arch/powerpc/include/asm/config.h |    3 +++
 arch/sparc/include/asm/config.h   |    1 +
 common/cmd_bootm.c                |    2 +-
 common/image.c                    |   10 ++++++----
 include/image.h                   |    9 ++++++---
 6 files changed, 20 insertions(+), 8 deletions(-)

arch/m68k/include/asm/config.h +3 -0

index 36438be..1fbdf0a 100644
@@ -22,5 +22,8 @@
 #define _ASM_CONFIG_H_
 
 #define CONFIG_LMB
+#define CONFIG_BOOT_RAMDISK_HIGH
+#define CONFIG_BOOT_GET_CMDLINE
+#define CONFIG_BOOT_GET_KBD
 
 #endif

arch/powerpc/include/asm/config.h +3 -0

index d098657..788f27d 100644
@@ -22,6 +22,9 @@
 #define _ASM_CONFIG_H_
 
 #define CONFIG_LMB
+#define CONFIG_BOOT_RAMDISK_HIGH
+#define CONFIG_BOOT_GET_CMDLINE
+#define CONFIG_BOOT_GET_KBD
 
 #ifndef CONFIG_MAX_MEM_MAPPED
 #if defined(CONFIG_4xx) || defined(CONFIG_E500) || defined(CONFIG_MPC86xx)

arch/sparc/include/asm/config.h +1 -0

index 36438be..b072771 100644
@@ -22,5 +22,6 @@
 #define _ASM_CONFIG_H_
 
 #define CONFIG_LMB
+#define CONFIG_BOOT_RAMDISK_HIGH
 
 #endif

common/cmd_bootm.c +1 -1

index f12e2d1..9ad82e2 100644
@@ -521,7 +521,7 @@ int do_bootm_subcommand (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv
 			lmb_reserve(&images.lmb, images.os.load,
 					(load_end - images.os.load));
 			break;
-#if defined(CONFIG_PPC) || defined(CONFIG_M68K) || defined(CONFIG_SPARC)
+#ifdef CONFIG_BOOT_RAMDISK_HIGH
 		case BOOTM_STATE_RAMDISK:
 		{
 			ulong rd_len = images.rd_end - images.rd_start;

common/image.c +6 -4

index fcb938b..6b1ee6b 100644
@@ -991,7 +991,7 @@ int boot_get_ramdisk (int argc, char * const argv[], bootm_headers_t *images,
 	return 0;
 }
 
-#if defined(CONFIG_PPC) || defined(CONFIG_M68K) || defined(CONFIG_SPARC)
+#ifdef CONFIG_BOOT_RAMDISK_HIGH
 /**
  * boot_ramdisk_high - relocate init ramdisk
  * @lmb: pointer to lmb handle, will be used for memory mgmt

@@ -1080,7 +1080,7 @@ int boot_ramdisk_high (struct lmb *lmb, ulong rd_data, ulong rd_len,
 error:
 	return -1;
 }
-#endif /* defined(CONFIG_PPC) || defined(CONFIG_M68K) || defined(CONFIG_SPARC) */
+#endif /* CONFIG_BOOT_RAMDISK_HIGH */
 
 #ifdef CONFIG_OF_LIBFDT
 static void fdt_error (const char *msg)

@@ -1587,7 +1587,7 @@ error:
 }
 #endif /* CONFIG_OF_LIBFDT */
 
-#if defined(CONFIG_PPC) || defined(CONFIG_M68K)
+#ifdef CONFIG_BOOT_GET_CMDLINE
 /**
  * boot_get_cmdline - allocate and initialize kernel cmdline
  * @lmb: pointer to lmb handle, will be used for memory mgmt

@@ -1629,7 +1629,9 @@ int boot_get_cmdline (struct lmb *lmb, ulong *cmd_start, ulong *cmd_end,
 
 	return 0;
 }
+#endif /* CONFIG_BOOT_GET_CMDLINE */
 
+#ifdef CONFIG_BOOT_GET_KBD
 /**
  * boot_get_kbd - allocate and initialize kernel copy of board info
  * @lmb: pointer to lmb handle, will be used for memory mgmt

@@ -1662,7 +1664,7 @@ int boot_get_kbd (struct lmb *lmb, bd_t **kbd, ulong bootmap_base)
 
 	return 0;
 }
-#endif /* CONFIG_PPC || CONFIG_M68K */
+#endif /* CONFIG_BOOT_GET_KBD */
 #endif /* !USE_HOSTCC */
 
 #if defined(CONFIG_FIT)

include/image.h +6 -3

index bcc08d1..e94c15d 100644
@@ -339,14 +339,17 @@ int boot_relocate_fdt (struct lmb *lmb, ulong bootmap_base,
 		char **of_flat_tree, ulong *of_size);
 #endif
 
-#if defined(CONFIG_PPC) || defined(CONFIG_M68K)
+#ifdef CONFIG_BOOT_RAMDISK_HIGH
 int boot_ramdisk_high (struct lmb *lmb, ulong rd_data, ulong rd_len,
 		  ulong *initrd_start, ulong *initrd_end);
-
+#endif /* CONFIG_BOOT_RAMDISK_HIGH */
+#ifdef CONFIG_BOOT_GET_CMDLINE
 int boot_get_cmdline (struct lmb *lmb, ulong *cmd_start, ulong *cmd_end,
 			ulong bootmap_base);
+#endif /* CONFIG_BOOT_GET_CMDLINE */
+#ifdef CONFIG_BOOT_GET_KBD
 int boot_get_kbd (struct lmb *lmb, bd_t **kbd, ulong bootmap_base);
-#endif /* CONFIG_PPC || CONFIG_M68K */
+#endif /* CONFIG_BOOT_GET_KBD */
 #endif /* !USE_HOSTCC */
 
 /*******************************************************************/

Signature · 1 line

1.7.0.4

John Rigby

author

2010-09-01 16:53 UTC #36 lore raw

PATCH 4/5 ARM: add flat device tree support

In reply to John Rigby

Based on other architectures already supported.

Signed-off-by John Rigby <[email protected]>

---
 arch/arm/include/asm/config.h |    2 +
 arch/arm/lib/bootm.c          |  138 ++++++++++++++++++++++++++++++++++++-----
 common/image.c                |    2 +
 3 files changed, 126 insertions(+), 16 deletions(-)

arch/arm/include/asm/config.h +2 -0

index b76fd8e..ca3a367 100644
@@ -23,5 +23,7 @@
 
 /* Relocation to SDRAM works on all ARM boards */
 #define CONFIG_RELOC_FIXUP_WORKS
+#define CONFIG_LMB
+#define CONFIG_BOOT_RAMDISK_HIGH
 
 #endif

arch/arm/lib/bootm.c +122 ~~-16~~

187 lines not on this page · raw message

common/image.c +2 -0

index 6b1ee6b..9b0b57b 100644
@@ -1213,9 +1213,11 @@ int boot_relocate_fdt (struct lmb *lmb, ulong bootmap_base,
 	if (fdt_blob < (char *)bootmap_base)
 		relocate = 1;
 
+#ifdef CONFIG_SYS_BOOTMAPSZ
 	if ((fdt_blob + *of_size + CONFIG_SYS_FDT_PAD) >=
 			((char *)CONFIG_SYS_BOOTMAPSZ + bootmap_base))
 		relocate = 1;
+#endif
 
 	/* move flattend device tree if needed */
 	if (relocate) {

Signature · 1 line

1.7.0.4

Rob Herring

2010-10-06 15:26 UTC #37 lore raw

PATCH 4/5 ARM: add flat device tree support

Quoted 3 lines · John Rigby

Based on other architectures already supported.
Signed-off-by John Rigby<[email protected]>

Tested-by Rob Herring <[email protected]>

John Rigby

author

2010-09-01 16:53 UTC #38 lore raw

PATCH 5/5 ARM: enable device tree for beagle

In reply to John Rigby

For testing ARM device tree support

Signed-off-by John Rigby <[email protected]>

---
 include/configs/omap3_beagle.h |   10 ++++++++--
 1 files changed, 8 insertions(+), 2 deletions(-)

include/configs/omap3_beagle.h +8 -2

index ae5a791..6bd3c7b 100644
@@ -55,6 +55,9 @@
 #undef CONFIG_USE_IRQ				/* no support for IRQs */
 #define CONFIG_MISC_INIT_R
 
+#define CONFIG_OF_LIBFDT		1
+#define CONFIG_SYS_BOOTMAPSZ	    (8 << 20)
+
 #define CONFIG_CMDLINE_TAG		1	/* enable passing of ATAGs */
 #define CONFIG_SETUP_MEMORY_TAGS	1
 #define CONFIG_INITRD_TAG		1

@@ -148,6 +151,7 @@
 #define CONFIG_SYS_I2C_BUS		0
 #define CONFIG_SYS_I2C_BUS_SELECT	1
 #define CONFIG_DRIVER_OMAP34XX_I2C	1
+#define CONFIG_I2C_MULTI_BUS		1
 
 /*
  * TWL4030

@@ -158,6 +162,7 @@
 /*
  * Board NAND Info.
  */
+#define CONFIG_SYS_NAND_QUIET_TEST	1
 #define CONFIG_NAND_OMAP_GPMC
 #define CONFIG_SYS_NAND_ADDR		NAND_BASE	/* physical address */
 							/* to access nand */

@@ -183,6 +188,7 @@
 	"loadaddr=0x82000000\0" \
 	"usbtty=cdc_acm\0" \
 	"console=ttyS2,115200n8\0" \
+	"mpurate=500\0" \
 	"vram=12M\0" \
 	"dvimode=1024x768MR-16@60\0" \
 	"defaultdisplay=dvi\0" \

@@ -191,16 +197,16 @@
 	"nandroot=/dev/mtdblock4 rw\0" \
 	"nandrootfstype=jffs2\0" \
 	"mmcargs=setenv bootargs console=${console} " \
+		"mpurate=${mpurate} " \
 		"vram=${vram} " \
 		"omapfb.mode=dvi:${dvimode} " \
-		"omapfb.debug=y " \
 		"omapdss.def_disp=${defaultdisplay} " \
 		"root=${mmcroot} " \
 		"rootfstype=${mmcrootfstype}\0" \
 	"nandargs=setenv bootargs console=${console} " \
+		"mpurate=${mpurate} " \
 		"vram=${vram} " \
 		"omapfb.mode=dvi:${dvimode} " \
-		"omapfb.debug=y " \
 		"omapdss.def_disp=${defaultdisplay} " \
 		"root=${nandroot} " \
 		"rootfstype=${nandrootfstype}\0" \

Signature · 1 line

1.7.0.4

John Rigby

author

2010-09-01 16:59 UTC #39 lore raw

PATCH 5/5 ARM: enable device tree for beagle

Sorry, ignore this patch it has some left over cruft from a rebase.

Quoted 4 lines · John Rigby

For testing ARM device tree support
Signed-off-by John Rigby <[email protected]>
---