Re: [U-Boot] [PATCH v5 05/11] exynos: dts: Adjust device tree files for U-Boot
And these, as you said I think, are HW description things that should be included in the master DT file upstream, right? Well we only need them because we are added 'reg' properties to the subnodes. There would certainly be no harm in including them upstream. The only bad thing I'm doing is the 'Replicate the ordering' bit. That should just go away once the GPIO numbering doesn't matter anymore (which requires that we use the device tree binding in GPIOs - this is the next step!). HI Simon, I'm trying to understand what you are saying here. Specifically, is this your solution to the GPIO renumbering problem that I've droning on and on about? jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 07/16] sandbox: dts: Add a serial console node
+ uart0: serial {
+ compatible = sandbox,serial;
+ u-boot,dm-pre-reloc;
Shouldn't that be handled by the driver. It's certainly something that's
only relevant to the internals of U-Boot, and hence inappropriate to put
into DT.
Hence the u-boot prefix. This is described in the driver model docs. I
have found a work-around (which forces a driver to be inited pre-reloc
if none is found) but I'm not 100% happy with it.
I'm arguing that the property shouldn't exist in DT at all. DT is supposed
to be a pure description of the HW, and not encode details that are specific
to the implementation of particular SW. The fact that U-Boot performs
relocation of its code during boot is completely irrelevant to a HW
description.
As such, the issue isn't whether there is a u-boot, prefix on that property,
but whether it's there at all.
Right. And I've arguing that U-Boot should use exactly the same
descriptions that are in the Kernel even. Those DTS descriptions should
be common, applicable to both or neither, exactly because they do
describe the HW and are agnostic WRT the SW that is using them.
HTH,
jdl
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Driver Model and DTS Parsing
Firstly we need to establish that GPIOs have names and that these should be supported in U-Boot. Without agreement on this point we might not get much further. Can I please press you on this point, as it is important to establish this first. Oh, you were talking about agreeing with me? I thought this was more of a general comment, since you'd indicated earlier that amending the gpio to handle names was outside the scope of this patchset, and GPIO names are basically only relevant if the user-interface exposes/handles the names. Yeah, but that applied to my request to use names that were derived and identified by those strings/names supplied in the DTS files. jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-boot] the first 0x20 bytes in u-boot.bin
On Thu, Jul 31, 2014 at 5:24 AM, tiger...@via-alliance.com wrote: Hi, Albert: I am studying 2014.07 release u-boot package. I found u-boot.bin's first bytes were not code in start.S . Taken for compling smdkv310 as an example: The compiled u-boot.bin's first 0x20 bytes were: 18 F0 9F E5 18 F0 9F E5 18 F0 9F E5 18 F0 9F E5 18 F0 9F E5 18 F0 9F E5 18 F0 9F E5 18 F0 9F E5 .. So, Is it equal to ldr pc, [pc,#0x18] ? Hard to say. Perhaps. You should study the linker script (*.lds) for this board. It is likely that the code you are seeing is the reset vector. jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] WIP for SPI
And I think I am saying that we already *have* it generalized for the GPIOs but only if we remove that renumbering function! Consider again that the U_CLASS lookup of a GPIO simply matches versus the range in each uclass data (gpio base and count). That search doesn't care about their order within the UCLASS_GPIO list. (Never mind that the renumbering breaks the association of the device base register and pin ranges as set up by the bind/probe code!) I wonder if we could do something similar then, where there is a default numbering if none is provided, but the GPIO devices are able to 'request' particular number ranges? I think we are talking past each other now. Isn't that already in place? One can already register a device with a range in the UCLASS so that the lookup happens and matches to a particular device instance. (But only assuming they are NOT renumbered.) What am I missing here? Thanks, jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 17/29] dm: Introduce device sequence numbering
HI Simon,
On Tue, Jul 8, 2014 at 10:38 PM, Simon Glass s...@chromium.org wrote:
In U-Boot it is pretty common to number devices from 0 and access them
on the command line using this numbering. While it may come to pass that
we will move away from this numbering, the possibility seems remote at
present.
Given that devices within a uclass will have an implied numbering, it
makes sense to build this into driver model as a core feature. The cost
is fairly small in terms of code and data space.
Hmmm. I'm not entirely in agreement here. I think this is the wrong
long-term approach, and this just reinforces the status quo rather than
allowing a migration to a better approach.
With each uclass having numbered devices we can ask for SPI port 0 or
serial port 1 and receive a single device.
That's nice, but we should allow them to be named by their actual
names as found in the device tree too.
Devices typically request a sequence number using aliases in the device
tree. These are resolved when the device is probed, to deal with conflicts.
Sequence numbers need not be sequential and holes are permitted.
So they are unreliably unpredictable, unless you also happen
to have the DTS decoder ring in hand too?
+This indicates that in the uclass called serial, the named node
+(/serial@2223) will be given sequence number 2. Any command or driver
+which requests serial device 2 will obtain this device.
+
+Some devices represent buses where the devices on the bus are numbered or
+addressed. For example, SPI typically numbers its slaves from 0, and I2C
+uses a 7-bit address. In these cases the 'reg' property of the subnode is
+used, for example:
+
+{
+ aliases {
+ spi2 = /spi@2230;
+ };
+
+ spi@2230 {
+ #address-cells = 1;
+ #size-cells = 1;
+ spi-flash@0 {
+ reg = 0;
+ ...
+ }
+ eeprom@1 {
+ reg = 1;
+ };
+ };
And not everyone agrees that this is the best approach, even in Linux land.
Specifically, we should be in agreement with Linux, and we should not
have our DTS stray from the definitions that Linux will accept for the same
devices. And this approach won't be bought by the Linux crowd. (Yes,
there are some that use a reg = 0; approach here, but there are many
that do not too. It's not a universally accepted approach.)
This concept is crucial.
I've said it before, and I will say it again if needed.
So: Sure, put this approach in, but make it be the backward compatible
approach. Also please put in a correct naming approach so that we can
move forward with a better longer term solution too.
Thanks,
jdl
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v2 1/1] driver/ddr: Fix DDR4 driver for ARM
On Mon, Jun 23, 2014 at 5:36 PM, York Sun york...@freescale.com wrote: Previously the driver was only tested on Power SoCs. Different barrier instructions are needed for ARM SoCs. Signed-off-by: York Sun york...@freescale.com --- Change log v2: use mb() and isb() instead of #ifdef Excellent. Thanks! jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] README: document the CONFIG_ENV_IS_IN_FAT option
On Tue, Jun 24, 2014 at 4:47 AM, Josh Wu josh...@atmel.com wrote: Josh, Any chance you want to patch the lack of CONFIG_ENV_IS_IN_SPI_FLASH documentation while you are in the area? :-) I think it's no problem ;-) I will do a patch for SPI_FLASH. Best Regards, Josh Wu Awesome! Thanks, jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] README: document the CONFIG_ENV_IS_IN_FAT option
On Mon, Jun 23, 2014 at 1:41 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 06/22/2014 08:41 PM, Josh Wu wrote: Signed-off-by: Josh Wu josh...@atmel.com A quick description might be nice. Otherwise, Josh, Any chance you want to patch the lack of CONFIG_ENV_IS_IN_SPI_FLASH documentation while you are in the area? :-) jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, U-boot, 1/2] common: cmd_nand: add nand ecclayout command
--- a/common/cmd_nand.c
+++ b/common/cmd_nand.c
@@ -462,6 +462,53 @@ static void adjust_size_for_badblocks(loff_t *size,
+ for (i = 0; i p-eccbytes; i++) {
+ if (i !(i % 9))
+ printf(\n);
+
+ printf(%2d , p-eccpos[i]);
+ }
Why 9?
It's to print a new line on every 9th character position.
I'll add a comment.
OK, Scott, breath... I got this one. It'll be OK...
Ivan,
I am confident Scott understood that a newline would
be generated every ninth-character. We all get that. I think
what Scott was asking was why the value 9 was chosen?
Why not 10? Or 8? Or 145? Was it to fit some arbitrary
line length or screen size? Would it make more sense to
use something familiar like a base 10 or half of base-16?
Thanks,
jdl
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] driver/ddr: Fix DDR4 driver for ARM
On Tue, Jun 17, 2014 at 5:07 PM, York Sun york...@freescale.com wrote:
Previously the driver was only tested on Power SoCs. Minor fix is needed
for ARM SoCs.
Signed-off-by: York Sun york...@freescale.com
Hi York!
--- a/drivers/ddr/fsl/fsl_ddr_gen4.c
+++ b/drivers/ddr/fsl/fsl_ddr_gen4.c
@@ -183,12 +184,20 @@ step2:
* we choose the max, that is 500 us for all of case.
*/
udelay(500);
+#ifdef CONFIG_PPC
asm volatile(sync;isync);
+#else
+ asm volatile(dsb sy;isb);
+#endif
/* Let the controller go */
temp_sdram_cfg = ddr_in32(ddr-sdram_cfg) ~SDRAM_CFG_BI;
ddr_out32(ddr-sdram_cfg, temp_sdram_cfg | SDRAM_CFG_MEM_EN);
+#ifdef CONFIG_PPC
asm volatile(sync;isync);
+#else
+ asm volatile(dsb sy;isb);
+#endif
total_gb_size_per_controller = 0;
for (i = 0; i CONFIG_CHIP_SELECTS_PER_CTRL; i++) {
This is a great example where we should try to introduce better abstractions
in much the same way that Linux has. Specifically, we (U-Boot) collective
might work toward some common lower-level abstractions such as a
memory_barrier() (and variants), and let those generic names get mapped
into architecture-specific implementations via a linked binding. Then this
code would not need to change, nor would #ifdefs be needed.
HTH,
jdl
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 05/15] dm: Rename struct device_id to udevice_id
On Tue, Jun 10, 2014 at 6:53 PM, Simon Glass s...@chromium.org wrote: It is best to avoid having any occurence of 'struct device' in driver model, so rename to achieve this. Signed-off-by: Simon Glass s...@chromium.org --- Hmm. It's not just a good idea, right? That change is upstream already so this is a compilation requirement now, right? jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 15/15] dm: Expand and improve the device lifecycle docs
On Tue, Jun 10, 2014 at 6:53 PM, Simon Glass s...@chromium.org wrote: The lifecycle of a device is an important part of driver model. Add to the existing documentation and clarify it. Reported-by: Jon Loeliger j...@jdl.com Signed-off-by: Simon Glass s...@chromium.org --- Thanks for Jon Loeliger j...@jdl.com for helping with the text and suggesting improvements. (Jon please comment/adjust to help clarify things further) This is way betterer now. Thanks! Nit typo: + e. If the driver provides a ofdata_to_platdata() method, then this is s/a/an/ + + Note: for a U_BOOT_DEVICE() declaration, the platform data is supplied as + a static pointer and is not allocated. For device tree, the platform + data is allocated during activation and freed during dectivation, + typically automatically using platdata_auto_alloc_size. But if that value + is 0 then U-Boot will not do the allocation/freeing and you will need to + do this yourself in your ofdata_to_platdata() and remove() methods. This + difference is tracked by the device's DM_FLAG_ALLOC_PDATA flag. The first sentence in that paragraph confused me because I knew where it was supposed to be headed: namely, the deallocation of the platdata. So when it used the not allocated phrase, I was taken aback. How about something like this instead?: Note: Because the platform data for a U_BOOT_DEVICE() is defined with a static pointer, it is not de-allocated during the remove() method. For a device instantiated using the device tree data, the platform data will be dynamically allocated, and thus needs to be deallocated during the remove() method. If the platdata_auto_alloc_size is non-zero, the deallocation happens automatically within the DM core. However, when platdata_auto_alloc_size is 0, both the allocation (in probe() or preferably ofdata_to_platdata()) and the deallocation in remove() are the responsibility of the driver author. If you'd like: Acked-by: Jon.Loeliger j...@jdl.com Thanks, jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 0/15] Collected driver model bug-fixes and docs
On Tue, Jun 10, 2014 at 6:53 PM, Simon Glass s...@chromium.org wrote: This series collects some of the patches from the Tegra GPIO conversion to driver model. That work is still in progress, but the bug fixes and iotracing feature should go into this release I think. Also the documentation improvements may as well follow since the existings docs are proven inadequate. Changes in v5: - Fix a few more typos Hi Simon, Thanks for gathering all these patches. I definitely think they should hit the shiny, new DM repo! Thanks, jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 10/15] dm: Allow driver model tests only for sandbox
On Tue, Jun 10, 2014 at 6:53 PM, Simon Glass s...@chromium.org wrote: The GPIO tests require the sandbox GPIO driver, so cannot be run on other platforms. Similarly for the 'dm test' command. Signed-off-by: Simon Glass s...@chromium.org --- Ja, gut. Tested-by: Jon Loeliger jon.loeli...@oracle.com jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] WIP for SPI
On Tue, Jun 10, 2014 at 10:54 PM, Simon Glass s...@chromium.org wrote: Hi Jon, I thought I should mention that I spent time on a flight to look at SPI with driver model. I have put the WIP code in branch 'working' in u-boot-dm.git. Note it doesn't work, and is very early. Also note that many of the patches have not been posted - I just want to make it clear what I am up to. Awesome! In doing this I had to sort out the numbering of devices. U-Boot has the concept of SPI bus 2 on its command line, and for now at lest we need to keep that working. So I have added sequence numbers to devices - so a device can be considered 'child number 3' of its parent, for example. The numbers don't need to be sequential. I suppose we could generalise this to GPIOs if it works out. And I think I am saying that we already *have* it generalized for the GPIOs but only if we remove that renumbering function! Consider again that the U_CLASS lookup of a GPIO simply matches versus the range in each uclass data (gpio base and count). That search doesn't care about their order within the UCLASS_GPIO list. (Never mind that the renumbering breaks the association of the device base register and pin ranges as set up by the bind/probe code!) My approach for scanning the SPI bus in the device tree is similar to what I suggested a week or so ago - I took the code from dm_scan_fdt() and put it in a function with a udevice parent and node parameters. It seems to work OK for this simple case. Nice! Thanks, jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 05/15] dm: Rename struct device_id to udevice_id
Didn't this hit upstream master already?
54c5d08a09e631f88738db54c75395c6457c2157
Or is this subsequent cleanup for straglers in this branch?
Thanks,
jdl
On Fri, Jun 6, 2014 at 2:13 PM, Simon Glass s...@chromium.org wrote:
It is best to avoid having any occurence of 'struct device' in driver
model, so rename to achieve this.
- Add new patch to rename struct device_id to udevice_id
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
doc/driver-model/README.txt | 2 +-
drivers/core/lists.c| 2 +-
drivers/demo/demo-shape.c | 2 +-
drivers/demo/demo-simple.c | 2 +-
drivers/gpio/sandbox.c | 2 +-
include/dm/device.h | 6 +++---
test/dm/test-fdt.c | 2 +-
7 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/doc/driver-model/README.txt b/doc/driver-model/README.txt
index dcecb9a..4af89b0 100644
--- a/doc/driver-model/README.txt
+++ b/doc/driver-model/README.txt
@@ -315,7 +315,7 @@ is little or no 'driver model' code to write.
- Moved some data from code into data structure - e.g. store a pointer to
the driver operations structure in the driver, rather than passing it
to the driver bind function.
-- Rename some structures to make them more similar to Linux (struct device
+- Rename some structures to make them more similar to Linux (struct udevice
instead of struct instance, struct platdata, etc.)
- Change the name 'core' to 'uclass', meaning U-Boot class. It seems that
this concept relates to a class of drivers (or a subsystem). We shouldn't
diff --git a/drivers/core/lists.c b/drivers/core/lists.c
index 205b140..9f2917f 100644
--- a/drivers/core/lists.c
+++ b/drivers/core/lists.c
@@ -94,7 +94,7 @@ int lists_bind_drivers(struct udevice *parent)
* tree error
*/
static int driver_check_compatible(const void *blob, int offset,
- const struct device_id *of_match)
+ const struct udevice_id *of_match)
{
int ret;
diff --git a/drivers/demo/demo-shape.c b/drivers/demo/demo-shape.c
index a68cc10..3fa9c59 100644
--- a/drivers/demo/demo-shape.c
+++ b/drivers/demo/demo-shape.c
@@ -111,7 +111,7 @@ static int shape_ofdata_to_platdata(struct udevice *dev)
return 0;
}
-static const struct device_id demo_shape_id[] = {
+static const struct udevice_id demo_shape_id[] = {
{ demo-shape, 0 },
{ },
};
diff --git a/drivers/demo/demo-simple.c b/drivers/demo/demo-simple.c
index 11def86..2bcb7df 100644
--- a/drivers/demo/demo-simple.c
+++ b/drivers/demo/demo-simple.c
@@ -32,7 +32,7 @@ static int demo_shape_ofdata_to_platdata(struct udevice
*dev)
return demo_parse_dt(dev);
}
-static const struct device_id demo_shape_id[] = {
+static const struct udevice_id demo_shape_id[] = {
{ demo-simple, 0 },
{ },
};
diff --git a/drivers/gpio/sandbox.c b/drivers/gpio/sandbox.c
index 09cebe2..75ada5d 100644
--- a/drivers/gpio/sandbox.c
+++ b/drivers/gpio/sandbox.c
@@ -239,7 +239,7 @@ static int gpio_sandbox_probe(struct udevice *dev)
return 0;
}
-static const struct device_id sandbox_gpio_ids[] = {
+static const struct udevice_id sandbox_gpio_ids[] = {
{ .compatible = sandbox,gpio },
{ }
};
diff --git a/include/dm/device.h b/include/dm/device.h
index ec04982..19f2039 100644
--- a/include/dm/device.h
+++ b/include/dm/device.h
@@ -75,11 +75,11 @@ struct udevice {
#define device_active(dev) ((dev)-flags DM_FLAG_ACTIVATED)
/**
- * struct device_id - Lists the compatible strings supported by a driver
+ * struct udevice_id - Lists the compatible strings supported by a driver
* @compatible: Compatible string
* @data: Data for this compatible string
*/
-struct device_id {
+struct udevice_id {
const char *compatible;
ulong data;
};
@@ -121,7 +121,7 @@ struct device_id {
struct driver {
char *name;
enum uclass_id id;
- const struct device_id *of_match;
+ const struct udevice_id *of_match;
int (*bind)(struct udevice *dev);
int (*probe)(struct udevice *dev);
int (*remove)(struct udevice *dev);
diff --git a/test/dm/test-fdt.c b/test/dm/test-fdt.c
index 6eccf11..98e3936 100644
--- a/test/dm/test-fdt.c
+++ b/test/dm/test-fdt.c
@@ -53,7 +53,7 @@ static int testfdt_drv_probe(struct udevice *dev)
return 0;
}
-static const struct device_id testfdt_ids[] = {
+static const struct udevice_id testfdt_ids[] = {
{
.compatible = denx,u-boot-fdt-test,
.data = DM_TEST_TYPE_FIRST },
--
2.0.0.526.g5318336
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
Re: [U-Boot] [PATCH v4 04/15] Makefile: Support include files for .dts files
diff --git a/arch/arm/dts/include/dt-bindings b/arch/arm/dts/include/dt-bindings new file mode 12 index 000..0cecb3d --- /dev/null +++ b/arch/arm/dts/include/dt-bindings @@ -0,0 +1 @@ +../../../../include/dt-bindings \ No newline at end of file Hmmm... is this right? jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 05/15] dm: Rename struct device_id to udevice_id
Gah. Sorry about that top-post. I hate gmail's collapsed stupid-shit representation. Sorry. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Driver Model and DTS Parsing
On Mon, Jun 2, 2014 at 8:26 PM, Simon Glass s...@chromium.org wrote: Driver model works by looking up compatible strings in the top-level nodes and binding a driver for each one it finds. I get that. I'm saying that isn't sufficient. The exynos pinctrl device tree binding does not have a compatible string in each of its banks. In fact it just has a single compatible string at the level above the banks. So there seems to be no alternative but to iterate through the banks binding devices as we go. So we get a bind call on the pinctrl node and then bind each of the banks. Right. That's fine for this board and DTS. However, the existing parsing structure isn't sufficient yet. Instead, I think it should be a recursive structure essentially identical in structure to the Linux of_platform_populate() function. There should be a compatible matching step, and then the call to bind the specific instance. Am I missing something here? Or is this code that just needs to be developed further still? Certainly this could be done, Excellent. I'm saying it should be done. Specifically, a recursive, top-down implementation will allow the right parent node to grab iterative control and handle the sub-nodes that can't handle themselves. Like the Linux DTS parsing, we'll need to add handling of bus nodes. But we have to put in place the top-down structure so that we *do* iterate through the parents properly and at multiple levels. ... and it's a small change but this code doesn't exist yet. OK, I'll play that game: It's an important change and it needs to exist soon. :-) I deliberately left this out of the implementation until we have I2C implemented, or something similar. Then it will be clearer what is needed here. My concern is partly that access to the device may be mediated through the parent and thus not discoverable by the child. As an example, the Chrome OS EC driver can attached to I2C, SPI or LPC. The connection needs to be made at the parent level, which provides a 'communications' layer for the generic driver. Right. A top-down approach will allow for that sort of handling. So in short I think we need to address these things and make the decisions as we go. For the same reason I didn't implement driver model for SPL or pre-relocation (although I have a series out for the latter now). A lot of things will be clearer to me when I2C is ported over. Sure. In the meantime, the GPIO model suffers. Understood. :-) So two procedural questions: First, is there a DM repo. No, I don't mean an x86 repo gathering DM patches. I mean an actual repo with a DM moderator? I ask because I am carrying around patches that are going to take for-*ever* to hit mainline... You know. Second, how would you like to advance the DM's DTS parsing infrastructure? Do you want me to take a crack some patches? Would you rather do it? Can we get a common basis of patches (repo) somewhere? Regards, Simon Thanks, jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Driver Model and DTS Parsing
Folks,
I'd like to discuss the new Driver Model's parsing of the DTS file
for the purposes of instancing and binding devices as I was not
able to get the existing code to work anything like I was expecting.
The current code only finds and binds the top-level nodes of the
DTS file. This leads to a bind function one-level above where it
should be for each of the actual device nodes and an extra parent
node that is empty. For example, the gpio_exynos_gpio_bind()
function here:
http://git.denx.de/?p=u-boot/u-boot-x86.git;a=blob;f=drivers/gpio/s5p_gpio.c;h=8100d50ed2da686353c593ed90693c441cf24b4f;hb=refs/heads/us-gpioc
Looks like this:
386 /**
387 * We have a top-level GPIO device with no actual GPIOs. It has a child
388 * device for each Exynos GPIO bank.
389 */
390 static int gpio_exynos_bind(struct device *parent)
391 {
392 struct exynos_gpio_platdata *plat = parent-platdata;
393 struct s5p_gpio_bank *bank;
394 const void *blob = gd-fdt_blob;
395 int node;
396
397 /* If this is a child device, there is nothing to do here */
398 if (plat)
399 return 0;
400
401 bank = (struct s5p_gpio_bank *)fdtdec_get_addr(gd-fdt_blob,
402
parent-of_offset, reg);
403 for (node = fdt_first_subnode(blob, parent-of_offset); node 0;
404 node = fdt_next_subnode(blob, node)) {
405 struct exynos_gpio_platdata *plat;
406 struct device *dev;
407 int ret;
408
409 plat = calloc(1, sizeof(*plat));
410 if (!plat)
411 return -ENOMEM;
412 plat-bank = bank;
413 plat-port_name = fdt_get_name(blob, node, NULL);
414
415 ret = device_bind(parent, parent-driver,
416 plat-port_name, plat, -1, dev);
417 if (ret)
418 return ret;
419 dev-of_offset = parent-of_offset;
420 bank++;
421 }
422
423 return 0;
424 }
Why is this function being called once at the parent node, which
then iterates over each device, instantiates and binds it? Why
isn't this function instead called once for each individual device
as matched from the DTS? Where did the compatible matching
and check take place in this implementation?
Instead, I think it should be a recursive structure essentially
identical in structure to the Linux of_platform_populate() function.
There should be a compatible matching step, and then the
call to bind the specific instance.
Am I missing something here? Or is this code that just needs to
be developed further still?
Thanks,
jdl
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Some Driver Model Ponderings
Hi U-Booters,
Over the past few days, I had an off-line conversation with Simon Glass
on the topic of the Driver Model. At his request, I've edited that
conversation into this piece of email for the U-Boot List in the
hopes that others in the community might also benefit.
Already, some documentation patches have been offered as a result.
http://patchwork.ozlabs.org/patch/352165/
But try to follow along. This is a conversation that occured over
several back-and-forth pieces of email. I've edited and spliced.
Hopefully, all the important pieces and parts are present without
offense or malice.
I start with the plea:
Hi Simon,
I write to you directly in an effort to
A) Get a new GPIO driver into U-Boot using the new Driver Model
B) Hopefully answer many lingering questions rapidly
the background:
Backing up a half step now... I need a PL061 ARM GPIO driver.
I have exactly one GPIO I need to drive. But I have 7 GPIO blocks
of 8 bits each. Rather than just hacking in yet another GPIO
hackery into the general U-Boot fray, I thought I'd try the new
driver model approach.
So I think I want, and have written, a simple PL061 driver that
fits these standard operations:
static const struct dm_gpio_ops gpio_pl061_ops = {
.request= pl061_gpio_request,
.free = pl061_gpio_free,
.direction_input= pl061_gpio_direction_input,
.direction_output = pl061_gpio_direction_output,
.get_value = pl061_gpio_get_value,
.set_value = pl061_gpio_set_value,
.get_state = pl061_gpio_get_state,
};
Each of those routines takes a struct device that is mapped into an
instance of the struct pl061_priv like so:
struct pl061_priv *priv = dev_get_priv(dev);
My priv structure is this:
struct pl061_priv {
u32 regs; /* GPIO bit-masked I/O space, controller */
u32 pad_regs; /* Pad control */
u32 gpio_base; /* GPIO range implemented by this device. */
u32 gpio_count;
};
Now, I want to build up 7 of these with different bases for the
'regs', and different segments of the global linear GPIO space,
8-bits apiece.
I am resonably convinced that the UCLASS_GPIO is going to help me do
this. And is supposed to. It is some combination of the probe,
bind, setup that I am not quite understanding yet.
At this point, Simon states that another reference implementation
has been pushed:
I just pushed us-gpioc to
http://git.denx.de/u-boot-x86.git
which includes another conversion - drivers/gpio/s5p_gpio.c.
It might be a bit closer to what you need.
So, my UCLASS related questions haven't all been answered yet,
but I also had questions about the relationships between the
various bits of data along the way: uc_priv, platdata, priv:
I'm not quite understanding the relationship of my pl061_priv
data to the so-called platdata.
Simon clarifies that:
priv is your device's private data, used while the device is running
(i.e. it is set up when the device is probed, and deleted when the
device is removed)
platdata is like Linux platform data. It provides the information
needed to start up the device - like its register addresses or
configuration options.
I make two observations about those two paragraphs that then
go on to cause a new documentation patch to be submitted.
My first observation is that nowhere in the as-yet-written
documentation abou the Driver Model is there any statement
about the lifetime of the data pieces. Until that first paragraph.
So I ask for more complete data-lifetime documentation.
Secondly, I also observe that there is no data-flow documented.
What is the sequence of data as it transitions through the
various bind, probe, use, and release phases?
Simon offers to document some data-lifetime, but quotes some
existing platdata documentation too:
platdata (data which tells the driver how
to operate on a particular platform)
Which just sets me off:
This is *exactly* the wording I am arguing against. :-)
That uses the same word to define the word. We need
*other* words to describe what is meant by platform data
in this context. Something like what you wrote in the
mail to me:
Examples of platform data might include:
- the base address of the IP blocks register space
- configuration options
- board-level physical switch settings
- something else obvious
- when using DTS, data parsed out of the device node
And perhaps a description of why it is needed in the first place:
The device driver needs instance data for about a device's
running state but may not be able to determine it. The
platform
Re: [U-Boot] [RFC PATCH 09/22] Remove form-feeds from dlmalloc.c
All in favor of the patch, but there is a typo here: These don't really server any purpose in the modern age, IMO. On the s/server/serve/ Note trailing 'r'. IMO, I'd toss out the ', IMO' too if it were my patch. Thanks, jdl On Sat, May 24, 2014 at 4:21 PM, Simon Glass s...@chromium.org wrote: These don't really server any purpose in the modern age, IMO. On the other hand they show up as annoying control characters in my editor, which then happily removes them. I believe we can drop these characters from the file. Signed-off-by: Simon Glass s...@chromium.org --- common/dlmalloc.c | 46 +++--- 1 file changed, 23 insertions(+), 23 deletions(-) diff --git a/common/dlmalloc.c b/common/dlmalloc.c index 3c70d5d..d1cd561 100644 --- a/common/dlmalloc.c +++ b/common/dlmalloc.c @@ -220,7 +220,7 @@ */ - + /* Preliminaries */ @@ -1132,7 +1132,7 @@ gAllocatedSize)) #endif - + /* Type declarations @@ -1272,7 +1272,7 @@ nextchunk- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ serviced via calls to mmap, and then later released via munmap. */ - + /* sizes, alignments */ #define SIZE_SZ(sizeof(INTERNAL_SIZE_T)) @@ -1297,7 +1297,7 @@ nextchunk- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ #define aligned_OK(m)(((unsigned long)((m)) (MALLOC_ALIGN_MASK)) == 0) - + /* Physical chunk operations @@ -1332,7 +1332,7 @@ nextchunk- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ #define chunk_at_offset(p, s) ((mchunkptr)(((char*)(p)) + (s))) - + /* Dealing with use bits @@ -1371,7 +1371,7 @@ nextchunk- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (((mchunkptr)(((char*)(p)) + (s)))-size = ~(PREV_INUSE)) - + /* Dealing with size fields @@ -1394,7 +1394,7 @@ nextchunk- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ #define set_foot(p, s) (((mchunkptr)((char*)(p) + (s)))-prev_size = (s)) - + /* @@ -1566,7 +1566,7 @@ void mem_malloc_init(ulong start, ulong size) #define is_small_request(nb) (nb MAX_SMALLBIN_SIZE - SMALLBIN_WIDTH) - + /* To help compensate for the large number of bins, a one-level index @@ -1590,7 +1590,7 @@ void mem_malloc_init(ulong start, ulong size) #define clear_binblock(ii) (binblocks_w = (mbinptr)(binblocks_r ~(idx2binblock(ii - + /* Other static bookkeeping data */ @@ -1628,7 +1628,7 @@ static unsigned int max_n_mmaps = 0; static unsigned long max_mmapped_mem = 0; #endif - + /* Debugging support @@ -1769,7 +1769,7 @@ static void do_check_malloced_chunk(p, s) mchunkptr p; INTERNAL_SIZE_T s; #define check_malloced_chunk(P,N) #endif - + /* Macro-based internal utilities @@ -1841,7 +1841,7 @@ static void do_check_malloced_chunk(p, s) mchunkptr p; INTERNAL_SIZE_T s; (last_remainder-fd = last_remainder-bk = last_remainder) - + /* Routines dealing with mmap(). */ @@ -1972,7 +1972,7 @@ static mchunkptr mremap_chunk(p, new_size) mchunkptr p; size_t new_size; #endif /* HAVE_MMAP */ - + /* Extend the top-most chunk by obtaining memory from system. @@ -2089,7 +2089,7 @@ static void malloc_extend_top(nb) INTERNAL_SIZE_T nb; } - + /* Main public routines */ @@ -2396,7 +2396,7 @@ Void_t* mALLOc(bytes) size_t bytes; } - + /* @@ -2513,7 +2513,7 @@ void fREe(mem) Void_t* mem; } - + /* @@ -2750,7 +2750,7 @@ Void_t* rEALLOc(oldmem, bytes) Void_t* oldmem; size_t bytes; } - + /* @@ -2868,7 +2868,7 @@ Void_t* mEMALIGn(alignment, bytes) size_t alignment; size_t bytes; } - + /* @@ -2975,7 +2975,7 @@ void cfree(mem) Void_t *mem; } #endif - + /* @@ -3056,7 +3056,7 @@ int malloc_trim(pad) size_t pad; } } - + /* malloc_usable_size: @@ -3092,7 +3092,7 @@ size_t malloc_usable_size(mem) Void_t* mem; } - + /* Utility to update current_mallinfo for malloc_stats and mallinfo() */ @@ -3136,7 +3136,7 @@ static void malloc_update_mallinfo() } #endif /* DEBUG */ - + /* @@ -3183,7 +3183,7 @@ struct mallinfo mALLINFo() #endif /* DEBUG */ - + /* mallopt: -- 1.9.1.423.g4596e3a ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] FDT: Fix DTC repository references
The Device Tree Compiler (DTC) used to have its master repository located on jdl.com. While it is still there, its official, new, shiny location is on kernel.org here: git://git.kernel.org/pub/scm/utils/dtc/dtc.git Update a few references to point there instead. Signed-off-by: Jon Loeliger j...@jdl.com --- doc/README.fdt-control | 4 ++-- doc/uImage.FIT/howto.txt | 5 - 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/doc/README.fdt-control b/doc/README.fdt-control index 86bae68..0ceebe7 100644 --- a/doc/README.fdt-control +++ b/doc/README.fdt-control @@ -66,11 +66,11 @@ Tools To use this feature you will need to get the device tree compiler here: - git://jdl.com/software/dtc.git + git://git.kernel.org/pub/scm/utils/dtc/dtc.git For example: - $ git clone git://jdl.com/software/dtc.git + $ git clone git://git.kernel.org/pub/scm/utils/dtc/dtc.git $ cd dtc $ make $ sudo make install diff --git a/doc/uImage.FIT/howto.txt b/doc/uImage.FIT/howto.txt index 526be55..14e316f 100644 --- a/doc/uImage.FIT/howto.txt +++ b/doc/uImage.FIT/howto.txt @@ -16,7 +16,10 @@ create an uImage in the new format: mkimage and dtc, although only one (mkimage) is invoked directly. dtc is called from within mkimage and operates behind the scenes, but needs to be present in the $PATH nevertheless. It is important that the dtc used has support for binary includes -- refer to -www.jdl.com for its latest version. mkimage (together with dtc) takes as input + + git://git.kernel.org/pub/scm/utils/dtc/dtc.git + +for its latest version. mkimage (together with dtc) takes as input an image source file, which describes the contents of the image and defines its various properties used during booting. By convention, image source file has the .its extension, also, the details of its format are given in -- 1.9.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 08/22] dm: Use '*' to indicate a device is activated
Why is '*' better than 'active' here?
At the very least, you need to convince me in the
log message.
Thanks,
jdl
On Sat, May 24, 2014 at 4:21 PM, Simon Glass s...@chromium.org wrote:
Make both dm enumeration commands support showing whether a driver is active
or not, and use a consistent indicator (an asterisk).
Signed-off-by: Simon Glass s...@chromium.org
---
test/dm/cmd_dm.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/test/dm/cmd_dm.c b/test/dm/cmd_dm.c
index c6b2eb8..ee02314 100644
--- a/test/dm/cmd_dm.c
+++ b/test/dm/cmd_dm.c
@@ -23,9 +23,9 @@ static int display_succ(struct device *in, char *buf)
char local[16];
struct device *pos, *n, *prev = NULL;
- printf(%s- %s @ %08x, buf, in-name, (uint)map_to_sysmem(in));
- if (in-flags DM_FLAG_ACTIVATED)
- puts( - activated);
+ printf(%s- %c %s @ %08x, buf,
+ in-flags DM_FLAG_ACTIVATED ? '*' : ' ',
+ in-name, (uint)map_to_sysmem(in));
puts(\n);
if (list_empty(in-child_head))
@@ -84,8 +84,9 @@ static int do_dm_dump_uclass(cmd_tbl_t *cmdtp, int flag,
int argc,
for (ret = uclass_first_device(id, dev);
dev;
ret = uclass_next_device(dev)) {
- printf( %s @ %08x:\n, dev-name,
- (uint)map_to_sysmem(dev));
+ printf( %c %s @ %08x:\n,
+ dev-flags DM_FLAG_ACTIVATED ? '*' : ' ',
+ dev-name, (uint)map_to_sysmem(dev));
}
puts(\n);
}
--
1.9.1.423.g4596e3a
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 17/22] dm: Expand and improve the device lifecycle docs
On Sat, May 24, 2014 at 4:21 PM, Simon Glass s...@chromium.org wrote: The lifecycle of a device is an important part of driver model. Add to the existing documentation and clarify it. Thanks for Jon Loeliger j...@jdl.com for helping with the text and suggesting improvements. (Jon please comment/adjust to help clarify things further) Clearly that line should be below the '---'. :-) Reported-by: Jon Loeliger j...@jdl.com Signed-off-by: Simon Glass s...@chromium.org --- A few nits, but otherwise feel free to add my ACK as well. Platform Data - +Platform data is like Linux platform data, if you are familiar with that. +It provides the board-specific information to start up a device. + +Why is this information not just stored in the device driver itself? The +idea is that the device driver is generic, and can in principle operate on +any board that has that type of device. For example, with modern +highly-complex SoCs it is common for the IP to come from an IP vendor, and +therefore (for example) the MMC controller may be the same on chips from +different vendors. It makes no sense to write independent drivers for the +MMC controller on each vendor's SoC, when they are all almost the same. +Similarly, we may have 6 UARTs in an SoC, all of which are mostly the same, +but lie at different addresses in the address space. + +Using the UART example, we have a single driver and it is instantiated 6 +times by supplying 6 lots of platform data. Each lot of platform data +gives the driver name and a pointer to a structure containing information +about this instance - e.g. the address of the register space. It may be that +one of the UARTS supports RS-485 operation - this can be added as a flag in +the platform data, which is set for this one port and clear for the rest. + +Think of your driver as a generic piece of code which knows how to talk to +a device, but needs to know where it is, any variant/option information and +so on. Platform data provides this link between the generic piece of code +and the specific way it is bound on a particular board. + +Examples of platform data include: + + - The base address of the IP block's register space + - Configuration options, like: + - the SPI polarity and maximum speed for a SPI controller + - the I2C speed to use for an I2C device + - the number of GPIOs available in a GPIO device + - Note this can be parsed from the Device Tree (see below) Not sure to what 'this' refers in that last bullet. Should that whole last line read more like: - Data that can be parsed from the Device Tree (see below) Where does the platform data come from? See demo-pdata.c which sets up a table of driver names and their associated platform data. This is a weak explanation of platform data origin. At the very least we need to say it is allocated per-device if needed, and then point to the demo-pdata.c as an *example*. The data can be interpreted by the drivers however they like - it is @@ -259,21 +296,30 @@ following device tree fragment: sides = 4; }; +This means that instead of having lots of U_BOOT_DEVICE() declarations in +the board file, we put these in the device tree. The allows a lot more s/The/This approach/ +generality, since the same board file can support many types of boards (e,g. +with the same SoC) just by using different device trees. An added benefit +is that the Linux device tree can be used, thus further simplifying the +task of board-bring up either for U-Boot or Linux devs (whoever gets to the +baord first!). I'd also s/devs/developers/. But that may be just me. :-) The easiest way to make this work it to add a few members to the driver: .platdata_auto_alloc_size = sizeof(struct dm_test_pdata), .ofdata_to_platdata = testfdt_ofdata_to_platdata, - .probe = testfdt_drv_probe, The 'auto_alloc' feature allowed space for the platdata to be allocated and zeroed before the driver's ofdata_to_platdata method is called. This -method reads the information out of the device tree and puts it in -dev-platdata. Then the probe method is called to set up the device. +method (which the driver writer supplies) should read the information out +of the device tree and puts it in dev-platdata. Thus when the probe method s/puts/put/..; But *which* method here? The ofdata_to_platdata()? I think that needs to be explicitly referenced in the text here: The ofdata_to_platdata() method, which the driver write supplies, should parse the device tree node for this device and place it in the dev-platdata. +is called later (to set up the device ready for use) the platform data will +be present. Note that both methods are optional. If you provide an ofdata_to_platdata -method then it wlil be called first (after bind). If you provide a probe -method it will be called next. +method then it wlil
Re: [U-Boot] [RFC PATCH 05/22] sandbox: Remove all drivers before exit
On Sat, May 24, 2014 at 4:21 PM, Simon Glass s...@chromium.org wrote: Drivers are supposed to be able to close down cleanly. To set a good example, make sandbox shut down its driver model drivers and remove them before exit. Right. But we should be careful here... It may be desirable to do the same more generally once driver model is more widely-used. This could be done during bootm, before U-Boot jumps to the OS. It seems far too early to make this change. Some drivers should probably NOT be shut down prior to bootm handing off to some other OS. It could be that their sole purpose for starting and running was to enable some continued driver state for the OS. I'm thinking of some clock, or PHY or maybe some aspect of the ARM SCU that should be left running. So maybe if there is a general shutdown pass, there might be a need for a flag to indicate that it is/isn't OK to do so at OS-hand-off time. jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 16/22] dm: Add a way to indicate a preferred device within a uclass
The preferred device can be specified with a DM_FLAG_PREFER flag or a
'dm,prefer' property in the device tree node.
It is possible that a better approach will come to light in the future, but
this gets around the problem as it currently stands.
Here's your clue that something isn't quite right here. Again, this looks like
the us of a DTS property to describe a SW functionality rather than describe
the HW itself.
I'm not sure what needs to be done here either, but maybe it centers on
a better understanding of *why* something is being preferred? And what
if it is preferred, then what does that really mean? And what if two devices
are labelled as preferred -- Is that OK? Who checks and enforces it?
Sure, this may be a hack for now, but it needs more thought.
HTH,
jdl
On Sat, May 24, 2014 at 4:21 PM, Simon Glass s...@chromium.org wrote:
Where there are serveral device options that can be chosen, often one is
preferred. This can normally be handled by aliases in the device tree.
However, when a device can be specified either with platform data or
with a device tree node, which one should dm use? This situation happens
with sandbox, where we want to use the device tree version if we have
a device tree, and fall back to the platform data version if not. We need
this to work because without a console U-Boot will not function.
The original approach was just to take the first device in the uclass and
use that, but this does not work because the ordering is unknown.
The preferred device can be specified with a DM_FLAG_PREFER flag or a
'dm,prefer' property in the device tree node.
It is possible that a better approach will come to light in the future, but
this gets around the problem as it currently stands.
Signed-off-by: Simon Glass s...@chromium.org
---
drivers/core/device.c| 5 +
drivers/core/uclass.c| 15 ++-
include/dm/device.h | 3 +++
include/dm/uclass-internal.h | 3 ++-
include/dm/uclass.h | 15 +++
test/dm/test-fdt.c | 14 ++
test/dm/test.dts | 1 +
7 files changed, 54 insertions(+), 2 deletions(-)
diff --git a/drivers/core/device.c b/drivers/core/device.c
index 2c2634e..6b2c8f9 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -10,6 +10,7 @@
*/
#include common.h
+#include fdtdec.h
#include malloc.h
#include dm/device.h
#include dm/device-internal.h
@@ -21,6 +22,8 @@
#include linux/err.h
#include linux/list.h
+DECLARE_GLOBAL_DATA_PTR;
+
/**
* device_chld_unbind() - Unbind all device's children from the device
*
@@ -95,6 +98,8 @@ int device_bind(struct device *parent, struct driver *drv,
const char *name,
dev-parent = parent;
dev-driver = drv;
dev-uclass = uc;
+ if (fdtdec_get_bool(gd-fdt_blob, of_offset, dm,prefer))
+ dev-flags |= DM_FLAG_PREFER;
if (!dev-platdata drv-platdata_auto_alloc_size)
dev-flags |= DM_FLAG_ALLOC_PDATA;
diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c
index afb5fdc..d02ea5e 100644
--- a/drivers/core/uclass.c
+++ b/drivers/core/uclass.c
@@ -149,7 +149,8 @@ int uclass_find_device(enum uclass_id id, int index,
struct device **devp)
return ret;
list_for_each_entry(dev, uc-dev_head, uclass_node) {
- if (!index--) {
+ if (index == -1 ? (dev-flags DM_FLAG_PREFER) :
+ !index--) {
*devp = dev;
return 0;
}
@@ -177,6 +178,18 @@ int uclass_get_device(enum uclass_id id, int index,
struct device **devp)
return 0;
}
+int uclass_get_preferred_device(enum uclass_id id, struct device **devp)
+{
+ int err;
+
+ err = uclass_get_device(id, -1, devp);
+ if (!err || err != -ENODEV)
+ return err;
+
+ /* Nothing found, just pick the first device */
+ return uclass_get_device(id, 0, devp);
+}
+
int uclass_first_device(enum uclass_id id, struct device **devp)
{
struct uclass *uc;
diff --git a/include/dm/device.h b/include/dm/device.h
index 32650fd..d3c04ed 100644
--- a/include/dm/device.h
+++ b/include/dm/device.h
@@ -26,6 +26,9 @@ struct driver_info;
/* DM should init this device prior to relocation */
#define DM_FLAG_PRE_RELOC (1 2)
+/* DM should prefer this driver when searching a uclass */
+#define DM_FLAG_PREFER (1 3)
+
/**
* struct device - An instance of a driver
*
diff --git a/include/dm/uclass-internal.h b/include/dm/uclass-internal.h
index cc65d52..79b4d9e 100644
--- a/include/dm/uclass-internal.h
+++ b/include/dm/uclass-internal.h
@@ -13,7 +13,8 @@
/**
* uclass_find_device() - Return n-th child of uclass
* @id:Id number of the uclass
- * @index: Position of the child in uclass's list
+ * @index:
Re: [U-Boot] [RFC PATCH 07/22] dm: Allow drivers to be marked 'before relocation'
Allow drivers to mark themselves as 'pre-reloc' which means that they will
be initialised prior to relocation. This can be done either with a driver
flag or with a 'dm,pre-reloc' device tree property.
Hmmm, dm,pre-reloc isn't really describing the hardware any more.
That's really a flag for the purpose of telling SW how it should work.
We really should be careful here to maintain the DTS content as a
description of the hardware.
HTH,
jdl
On Sat, May 24, 2014 at 4:21 PM, Simon Glass s...@chromium.org wrote:
Driver model currently only operates after relocation is complete. In this
state U-Boot typically has a small amount of memory available. In adding
support for driver model prior to relocation we must try to use as little
memory as possible.
In addition, on some machines the memory has not be inited and/or the CPU
is not running at full speed or the data cache is off. These can reduce
execution performance, so the less initialisation that is done before
relocation the better.
An immediately-obvious improvement is to only initialise drivers which are
actually going to be used before relocation. On many boards the only such
driver is a serial UART, so this provides a very large potential benefit.
Allow drivers to mark themselves as 'pre-reloc' which means that they will
be initialised prior to relocation. This can be done either with a driver
flag or with a 'dm,pre-reloc' device tree property.
To support this, the various dm scanning function now take a 'pre_reloc_only'
parameter which indicates that only drivers marked pre-reloc should be
bound.
Signed-off-by: Simon Glass s...@chromium.org
---
common/board_r.c | 4 ++--
doc/driver-model/README.txt | 23 +++---
drivers/core/device.c| 6 --
drivers/core/lists.c | 6 +++---
drivers/core/root.c | 11 +++
include/dm/device-internal.h | 6 --
include/dm/device.h | 5 +
include/dm/lists.h | 2 +-
include/dm/root.h| 8 ++--
test/dm/core.c | 47
++--
test/dm/test-driver.c| 11 +++
test/dm/test-fdt.c | 20 ++-
test/dm/test-main.c | 4 ++--
test/dm/test.dts | 11 +++
14 files changed, 128 insertions(+), 36 deletions(-)
diff --git a/common/board_r.c b/common/board_r.c
index d1f0aa9..d2a59ee 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -276,13 +276,13 @@ static int initr_dm(void)
debug(dm_init() failed: %d\n, ret);
return ret;
}
- ret = dm_scan_platdata();
+ ret = dm_scan_platdata(false);
if (ret) {
debug(dm_scan_platdata() failed: %d\n, ret);
return ret;
}
#ifdef CONFIG_OF_CONTROL
- ret = dm_scan_fdt(gd-fdt_blob);
+ ret = dm_scan_fdt(gd-fdt_blob, false);
if (ret) {
debug(dm_scan_fdt() failed: %d\n, ret);
return ret;
diff --git a/doc/driver-model/README.txt b/doc/driver-model/README.txt
index e0b395a..deacfe9 100644
--- a/doc/driver-model/README.txt
+++ b/doc/driver-model/README.txt
@@ -332,26 +332,35 @@ dealing with this might not be worth it.
- Implemented a GPIO system, trying to keep it simple
+Pre-Relocation Support
+--
+
+For pre-relocation we simply call the driver model init function. Only
+drivers marked with DM_FLAG_PRE_RELOC or the device tree 'dm,pre-reloc'
+flag are initialised prior to relocation. This helps to reduce the driver
+model overhead.
+
+Then post relocation we throw that away and re-init driver model again.
+For drivers which require some sort of continuity between pre- and
+post-relocation devices, we can provide access to the pre-relocation
+device pointers, but this is not currently implemented (the root device
+pointer is saved but not made available).
+
+
Things to punt for later
- SPL support - this will have to be present before many drivers can be
converted, but it seems like we can add it once we are happy with the
core implementation.
-- Pre-relocation support - similar story
-That is not to say that no thinking has gone into these - in fact there
+That is not to say that no thinking has gone into this - in fact there
is quite a lot there. However, getting these right is non-trivial and
there is a high cost associated with going down the wrong path.
For SPL, it may be possible to fit in a simplified driver model with only
bind and probe methods, to reduce size.
-For pre-relocation we can simply call the driver model init function. Then
-post relocation we throw that away and re-init driver model again. For
drivers
-which require some sort of continuity between pre- and post-relocation
-devices, we can provide access to the pre-relocation device pointers.
-
Re: [U-Boot] [RFC PATCH 17/22] dm: Expand and improve the device lifecycle docs
+2. U-Boot scans through top-level nodes in the the device tree. It looks +at the compatible string in each node and uses the of_match part of the +U_BOOT_DRIVER() structure to find the right driver for each node. It then Why is the scan only on the top level? My GPIO nodes are, for example, under an SOC node. Thanks, jdl On Sat, May 24, 2014 at 4:21 PM, Simon Glass s...@chromium.org wrote: The lifecycle of a device is an important part of driver model. Add to the existing documentation and clarify it. Thanks for Jon Loeliger j...@jdl.com for helping with the text and suggesting improvements. (Jon please comment/adjust to help clarify things further) Reported-by: Jon Loeliger j...@jdl.com Signed-off-by: Simon Glass s...@chromium.org --- doc/driver-model/README.txt | 197 ++-- 1 file changed, 191 insertions(+), 6 deletions(-) diff --git a/doc/driver-model/README.txt b/doc/driver-model/README.txt index deacfe9..90e0516 100644 --- a/doc/driver-model/README.txt +++ b/doc/driver-model/README.txt @@ -95,11 +95,12 @@ are provided in test/dm. To run them, try: You should see something like this: ...U-Boot banner... -Running 12 driver model tests +Running 15 driver model tests Test: dm_test_autobind Test: dm_test_autoprobe Test: dm_test_children Test: dm_test_fdt +Test: dm_test_fdt_pre_reloc Test: dm_test_gpio sandbox_gpio: sb_gpio_get_value: error: offset 4 not reserved Test: dm_test_leak @@ -109,6 +110,8 @@ You should see something like this: Test: dm_test_operations Test: dm_test_ordering Test: dm_test_platdata +Test: dm_test_pre_reloc +Test: dm_test_prefer Test: dm_test_remove Test: dm_test_uclass Failures: 0 @@ -222,6 +225,40 @@ device tree) and probe. Platform Data - +Platform data is like Linux platform data, if you are familiar with that. +It provides the board-specific information to start up a device. + +Why is this information not just stored in the device driver itself? The +idea is that the device driver is generic, and can in principle operate on +any board that has that type of device. For example, with modern +highly-complex SoCs it is common for the IP to come from an IP vendor, and +therefore (for example) the MMC controller may be the same on chips from +different vendors. It makes no sense to write independent drivers for the +MMC controller on each vendor's SoC, when they are all almost the same. +Similarly, we may have 6 UARTs in an SoC, all of which are mostly the same, +but lie at different addresses in the address space. + +Using the UART example, we have a single driver and it is instantiated 6 +times by supplying 6 lots of platform data. Each lot of platform data +gives the driver name and a pointer to a structure containing information +about this instance - e.g. the address of the register space. It may be that +one of the UARTS supports RS-485 operation - this can be added as a flag in +the platform data, which is set for this one port and clear for the rest. + +Think of your driver as a generic piece of code which knows how to talk to +a device, but needs to know where it is, any variant/option information and +so on. Platform data provides this link between the generic piece of code +and the specific way it is bound on a particular board. + +Examples of platform data include: + + - The base address of the IP block's register space + - Configuration options, like: + - the SPI polarity and maximum speed for a SPI controller + - the I2C speed to use for an I2C device + - the number of GPIOs available in a GPIO device + - Note this can be parsed from the Device Tree (see below) + Where does the platform data come from? See demo-pdata.c which sets up a table of driver names and their associated platform data. The data can be interpreted by the drivers however they like - it is @@ -259,21 +296,30 @@ following device tree fragment: sides = 4; }; +This means that instead of having lots of U_BOOT_DEVICE() declarations in +the board file, we put these in the device tree. The allows a lot more +generality, since the same board file can support many types of boards (e,g. +with the same SoC) just by using different device trees. An added benefit +is that the Linux device tree can be used, thus further simplifying the +task of board-bring up either for U-Boot or Linux devs (whoever gets to the +baord first!). The easiest way to make this work it to add a few members to the driver: .platdata_auto_alloc_size = sizeof(struct dm_test_pdata), .ofdata_to_platdata = testfdt_ofdata_to_platdata, - .probe = testfdt_drv_probe, The 'auto_alloc' feature allowed space for the platdata to be allocated and zeroed before the driver's ofdata_to_platdata method is called
Re: [U-Boot] spi_flash_probe returns zero idcodes and hangs
Amit, If you can, place a SPI protocol analyzer on the bus and trace its transactions. I recently debugged a similar symptom and discovered that I was not driving the Tx FIFO consistently enough to maintain the appearance of a single transaction on the ID request to the flash. How is your SPI device (flash, right?) being selected? If via a GPIO, are you sure you are driving it properly? If it is directly using a controller's slave-select line, you may need to ensure a full Tx FIFO for both the write and response. HTH, jdl On Sat, May 24, 2014 at 12:15 PM, Jagan Teki jagannadh.t...@gmail.com wrote: On Sat, May 24, 2014 at 10:27 PM, Amit Mahadik amitmahadi...@yahoo.com wrote: Hello All, I am using a custom ARM based development board running u-boot from PNOR memory. However, it does not have support for the Micron SPI flash memory (N25Q064A). I have added support for the micron memory in drivers/mtd/spi/stmicro.c file and included the flag CONFIG_SPI_FLASH_STMICRO in the config file and recompiled the u-boot source source. Then, ran it directly through RAM memory. The new u-boot ran from RAM. Now when I run sf probe 0 command I get the following output Got Idcodes 00: 00 00 00 00 and the code hangs after this. Looks like your driver itself is not returning any proper idcode. What id details you added - I think you're using old u-boot no stmicro.c in current u-boot, please re-base to master and try. thanks! -- Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC, PATCH v2 1/4] dm: rename device struct to udevice
Yeah, I was just bitten by this problem as well... FWIW, you might also... Acked-by: Jon Loeliger jon.loeli...@oracle.com Thanks, jdl On Thu, May 22, 2014 at 3:34 PM, Simon Glass s...@chromium.org wrote: +Tom Hi Heiko, On 22 May 2014 00:43, Heiko Schocher h...@denx.de wrote: using UBI and DM together leads in compiler error, as both define a struct device, so rename struct device in include/dm/device.h to struct udevice, as we use linux code (MTD/UBI/UBIFS some USB code,...) and cannot change the linux struct device Signed-off-by: Heiko Schocher h...@denx.de Cc: Simon Glass s...@chromium.org Cc: Marek Vasut ma...@denx.de I'm not 100% comfortable with this but if we really want to avoid changing kernel code that moves into U-Boot it is either this or a '#define device ldevice' at the top of the linux code/in a header. I'm not sure which is preferable. If Tom decides to apply this, I'd like to request that it be done soon, since it has wide impact on driver model code. Acked-by: Simon Glass s...@chromium.org Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 06/10] ARM: HYP/non-sec: allow relocation to secure RAM
On Wed, May 7, 2014 at 2:05 AM, Marc Zyngier marc.zyng...@arm.com wrote: On Fri, May 02 2014 at 10:03:37 pm BST, Jon Loeliger loeli...@gmail.com wrote: Mark, In your nonsec_init code, you suggest this change: + mrc p15, 0, r0, c1, c1, 2 movwr1, #0x3fff - movtr1, #0x0006 - mcr p15, 0, r1, c1, c1, 2 @ NSACR = all copros to non-sec + movtr1, #0x0004 + orr r0, r0, r1 + mcr p15, 0, r0, c1, c1, 2 @ NSACR = all copros to non-sec Leaving: mrc p15, 0, r0, c1, c1, 2 movwr1, #0x3fff movtr1, #0x0004 orr r0, r0, r1 mcr p15, 0, r0, c1, c1, 2 @ NSACR = all copros to non-sec That sets all the co-processor bits, but the man page suggests that only Just to be clear: which document are you referring to? Hmm... Lessee.. Uh, this one: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0388i/CIHEAIAJ.html So, Cortex-A9 TRM 4.3.13 That one happens to be r4p1, but the description is the same for my part rev (r2p9, IIRC). Anyway, those low bits are marked as UNK/SBZP, hence my concern for the apparent extra ON bits. copros with bits 10 and 11 should be modified. It also seems that if the The ARM ARM says that NSACR[13:0] is either RAZ/WI or writable from secure for unimplemented coprocessors. The ARM ARM uber alles. :-) So I believe the above is safe. If you wanted to be really picky, you'd start by reading CPACR, write either 1 or 3 to all the CPn fields, read it back again, see what sticks, and populate NSACR accordingly. Did I hear someone saying Boring? ;-) I'm sorry, did you say something? Sounded like you said Waw-waw waw-wah CPn waw ... PLE is enabled, we should mark it NS-enabled at bit 16 also:. Perhaps: mrcp15, 0, r0, c1, c1, 2 movwr1, #0x0c00 movtr1, #0x0005 orrr0, r0, r1 mcrp15, 0, r0, c1, c1, 2@ NSACR = all copros to non-sec We're getting into IMPDEF territory pretty quickly here. PLE only exists on A9, and is optionnal there (and probably doesn't exist on all versions, if memory serves well...). Ah. Gotcha. Blah blah Osprey ah-chew! Gesundheit! This could be implemented as a per-platform optional feature, though. What do you think? I think we should all convert to A57 on a Dickens ring and be done. In the meantime, it's likely not worth it to be this picky about the darn PLE bits, nor the rest of the NSACR bits. Especially if the ARM ARM says we can let it slide. M. -- Without deviation from the norm, progress is not possible. Yes, yes, Everybody got to deviate from the norm. jdl On Wed, May 7, 2014 at 2:05 AM, Marc Zyngier marc.zyng...@arm.com wrote: On Fri, May 02 2014 at 10:03:37 pm BST, Jon Loeliger loeli...@gmail.com wrote: Mark, In your nonsec_init code, you suggest this change: + mrc p15, 0, r0, c1, c1, 2 movwr1, #0x3fff - movtr1, #0x0006 - mcr p15, 0, r1, c1, c1, 2 @ NSACR = all copros to non-sec + movtr1, #0x0004 + orr r0, r0, r1 + mcr p15, 0, r0, c1, c1, 2 @ NSACR = all copros to non-sec Leaving: mrc p15, 0, r0, c1, c1, 2 movwr1, #0x3fff movtr1, #0x0004 orr r0, r0, r1 mcr p15, 0, r0, c1, c1, 2 @ NSACR = all copros to non-sec That sets all the co-processor bits, but the man page suggests that only Just to be clear: which document are you referring to? copros with bits 10 and 11 should be modified. It also seems that if the The ARM ARM says that NSACR[13:0] is either RAZ/WI or writable from secure for unimplemented coprocessors. So I believe the above is safe. If you wanted to be really picky, you'd start by reading CPACR, write either 1 or 3 to all the CPn fields, read it back again, see what sticks, and populate NSACR accordingly. Did I hear someone saying Boring? ;-) PLE is enabled, we should mark it NS-enabled at bit 16 also:. Perhaps: mrcp15, 0, r0, c1, c1, 2 movwr1, #0x0c00 movtr1, #0x0005 orrr0, r0, r1 mcrp15, 0, r0, c1, c1, 2@ NSACR = all copros to non-sec We're getting into IMPDEF territory pretty quickly here. PLE only exists on A9, and is optionnal there (and probably doesn't exist on all versions, if memory serves well...). This could be implemented as a per-platform optional feature, though. What do you think? M. -- Without deviation from the norm, progress is not possible. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 06/10] ARM: HYP/non-sec: allow relocation to secure RAM
/* * With the Secure Monitor at 0x0, its reset vector must also * then point off to the correct out-of-reset entry function. */ #define CONFIG_SECURE_MONITOR_RESET_FUNCTION_myplatform_cpu_entry #define CONFIG_ARMV7_SECURE_BASE0x0 That _myplatform_cpu_entry corresponds to your sunxi_cpu_entry code. Yup, makes sense. Nit-pick: make the _secure_reset a weak symbol that your platform code will overload, just like the rest of the PSCI stuff. Saves the #ifdef horror; ;-) Oh, good idea. I'll add that bit in. Thanks! So, yeah, I know that isn't a proper patch and all. :-) I'm just sending you more information to ponder for this patch series! If you would like to generalize your patch this way, please feel free to do so. If not, I can send a proper patch after this hits mainline or so. My prefered way would be indeed to have a proper patch on top of this to handle the coming out of reset case. You'll get proper credit for the idea! :-) Will do. Thanks, jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 00/10] ARMv7: add PSCI support to U-Boot
Mark, Not sure on which patch of your series to base the following comment, but thought it was worth bringing up for discussion nevertheless. So, over in U-Boot ARMv7's arch/arm/cpu/armv7/start.S code, there is a bit of code under the enty-point named cpu_init_cp15 that does some I-Cache/MMU/state and Errata fi-xup for the boot CPU. As it should. That's all splendid. However, any secondary CPU coming out of reset *after* the U-Boot is gone and only the secure monitor remains will still need to execute code that is substantially similar if not exactly the same. That means the same code block (that cpu_init_cp15 code) needs to be assembled into the original out-of-reset sequence for the boot CPU, and also needs to be assembled into the secure monitor code for secondary CPU out-of-reset sequences. We clearly can not directly refactor that function, extracting it and reusing it wiith the same entry-point as it needs to be linked into two different sections. We could put it in some header file and #include it into both places. We could define a macro and instantiate it in each place. We could do some hacky assemble it twice with different names thing. Thoughts? Thanks, jdl On Sat, Apr 26, 2014 at 7:17 AM, Marc Zyngier marc.zyng...@arm.com wrote: PSCI is an ARM standard that provides a generic interface that supervisory software can use to manage power in the following situations: - Core idle management - CPU hotplug - big.LITTLE migration models - System shutdown and reset It basically allows the kernel to offload these tasks to the firmware, and rely on common kernel side code that just calls into PSCI. More importantly, it gives a way to ensure that CPUs enter the kernel at the appropriate exception level (ie HYP mode, to allow the use of the virtualization extensions), even across events like CPUs being powered off/on or suspended. The main idea here is to turn some of the existing U-Boot code into a separate section that can live in secure RAM (or a reserved page of memory), containing a secure monitor that will implement the PSCI operations. This code will still be alive when U-Boot is long gone, hence the need for a piece of memory that will not be touched by the OS. This patch series contains 3 parts: - the first four patches are just bug fixes - the next two refactor the HYP/non-secure code to allow relocation in secure memory - the last four contain the generic PSCI code and DT infrastructure This implements the original 0.1 spec, as nobody implements the new 0.2 version so far. I plan to update this support to 0.2 once there is an official binding available (and support in the kernel). Most of the development has been done on an Allwinner A20 SoC, which is the main user of this code at the moment. I hope new SoCs will be using this method in the future (my primary goal for this series being to avoid more stupid SMP code from creeping up in the Linux kernel). As instructed, I've removed the A20 support code and made it a separate series, as there is now an effort to mainline this code (see Ian Campbell patch series). With these three series applied, the A20 now boots in HYP mode, Linux finds the secondary CPU without any SMP code present in the kernel, and runs KVM out of the box. The Xen/ARM guys managed to do the same fairly easily, as did at least one XVizor user. This code has also been tested on a VExpress TC2, running KVM with all 5 CPUs, in order to make sure there was no obvious regression. The code is also available at: git://git.kernel.org/pub/scm/linux/kernel/git/maz/u-boot.git wip/psci-v4 A fully merged branch with the A20 support is in the wip/psci-v4-a20 branch of the same repo. Cheers, M. From v3: - Return ARM_PSCI_RET_INVAL instead of ARM_PSCI_RET_NI when PSCI is entered with an invalid function code. - Fix !NONSEC compilation - Rebased on top of adcdeac From v2: - Dropped the secure stack allocation from the generic PSCI code. There was too little space there for it to be really useful, and the arch code knows a lot better about its requirements anyway. It is now the responsibility of the arch code to provide a stack. This allows it to get rid of the silly game with the thread registers that was confusing everyone... - Added provision for FIQ handling in secure mode. Allwinner A20 is going to require this for CPU_OFF. - Better integration of the FDT injection code with the rest of the code, fixing the truncated FDT issue that people have been reporting (courtesy of Ma Haijun). - Cleanup of the AW-specific code (stack allocation, timer macro). - Rebased on mainline U-Boot (on top of 22a240c32c13). From v1: - Complete rewrite, now directly relocating the secure code withing U-Boot, instead of having a separate psci blob. Ma Haijun (1): ARM: convert arch_fixup_memory_node to a generic FDT fixup function Marc Zyngier (9): ARM: HYP/non-sec: move switch to non-sec to the last
Re: [U-Boot] [PATCH v4 10/10] ARM: HYP/non-sec/PSCI: emit DT nodes
On Sat, Apr 26, 2014 at 7:17 AM, Marc Zyngier marc.zyng...@arm.com wrote:
diff --git a/arch/arm/cpu/armv7/virt-dt.c b/arch/arm/cpu/armv7/virt-dt.c
new file mode 100644
index 000..0b0d6a7
--- /dev/null
+++ b/arch/arm/cpu/armv7/virt-dt.c
+
+static int fdt_psci(void *fdt)
+{
+#ifdef CONFIG_ARMV7_PSCI
+ int nodeoff;
+ int tmp;
+
+ nodeoff = fdt_path_offset(fdt, /cpus);
+ if (nodeoff 0) {
+ printf(couldn't find /cpus\n);
+ return nodeoff;
+ }
+
+ /* add 'enable-method = psci' to each cpu node */
+ for (tmp = fdt_first_subnode(fdt, nodeoff);
+tmp = 0;
+tmp = fdt_next_subnode(fdt, tmp)) {
+ const struct fdt_property *prop;
+ int len;
+
+ prop = fdt_get_property(fdt, tmp, device_type, len);
+ if (!prop)
+ continue;
+ if (len 4)
+ continue;
+ if (strcmp(prop-data, cpu))
+ continue;
+
+ fdt_setprop_string(fdt, tmp, enable-method, psci);
+ }
+
+ nodeoff = fdt_path_offset(fdt, /psci);
+ if (nodeoff 0) {
+ nodeoff = fdt_path_offset(fdt, /);
+ if (nodeoff 0)
+ return nodeoff;
+
+ nodeoff = fdt_add_subnode(fdt, nodeoff, psci);
+ if (nodeoff 0)
+ return nodeoff;
+ }
+
+ tmp = fdt_setprop_string(fdt, nodeoff, compatible, arm,psci);
+ if (tmp)
+ return tmp;
+ tmp = fdt_setprop_string(fdt, nodeoff, method, smc);
+ if (tmp)
+ return tmp;
+ tmp = fdt_setprop_u32(fdt, nodeoff, cpu_suspend,
ARM_PSCI_FN_CPU_SUSPEND);
+ if (tmp)
+ return tmp;
+ tmp = fdt_setprop_u32(fdt, nodeoff, cpu_off, ARM_PSCI_FN_CPU_OFF);
+ if (tmp)
+ return tmp;
+ tmp = fdt_setprop_u32(fdt, nodeoff, cpu_on, ARM_PSCI_FN_CPU_ON);
+ if (tmp)
+ return tmp;
+ tmp = fdt_setprop_u32(fdt, nodeoff, migrate, ARM_PSCI_FN_MIGRATE);
+ if (tmp)
+ return tmp;
+#endif
+ return 0;
+}
So, I wonder if it would be better to be a bit more selective or cautious
about adding these nodes and properties. Specifically, if they are already
present in the device tree itself, perhaps they should be honored and left
alone?
I understand that U-Boot gets to define what it implements, and that if
the secure monitor code doesn't actually implement something, or for
that matter *does* implement it, it makes sense for U-Boot to be able
to state those facts in a device tree. However, the DTS may also be
stating what it has implemented or willing to honor on the Linux side
as well. So, yeah, there has to be agreement here.
But who gets to make the final adjustment to the device tree? U-boot
with this code, or the DTS author who may have hand coded specific
wishes and loaded a specific device tree?
HTH,
jdl
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 06/10] ARM: HYP/non-sec: allow relocation to secure RAM
Mark, I finally have all this working for me on an A9 system too! However, there were a few things that I had to change a bit. For example, by CPUs will always come out of reset at 0x0 and I do not have the ability to set their first-fetch address to anything else. To accommodate this, I need to ensure that the _monitor_vectors are loaded at address 0x0, and that the first entry in the exception vector (for reset) jumped to some notion of secure_reset code. So I changed this code: diff --git a/arch/arm/cpu/armv7/nonsec_virt.S b/arch/arm/cpu/armv7/nonsec_virt.S index b5c946f..2a43e3c 100644 --- a/arch/arm/cpu/armv7/nonsec_virt.S +++ b/arch/arm/cpu/armv7/nonsec_virt.S @@ -10,10 +10,13 @@ #include linux/linkage.h #include asm/gic.h #include asm/armv7.h +#include asm/proc-armv/ptrace.h .arch_extension sec .arch_extension virt + .pushsection ._secure.text, ax + .align 5 /* the vector table for secure state and HYP mode */ _monitor_vectors: @@ -22,51 +25,86 @@ _monitor_vectors: adr pc, _secure_monitor .word 0 .word 0 - adr pc, _hyp_trap + .word 0 .word 0 .word 0 +.macro is_cpu_virt_capable tmp + mrc p15, 0, \tmp, c0, c1, 1 @ read ID_PFR1 + and \tmp, \tmp, #CPUID_ARM_VIRT_MASK@ mask virtualization bits + cmp \tmp, #(1 CPUID_ARM_VIRT_SHIFT) +.endm So that it did this too: @@ -20,15 +20,23 @@ .align 5 /* the vector table for secure state and HYP mode */ _monitor_vectors: - .word 0 /* reset */ - .word 0 /* undef */ - adr pc, _secure_monitor + ldr pc, _secure_reset /* reset */ + .word 0 /* undef */ + adr pc, _secure_monitor /* SMC */ .word 0 .word 0 .word 0 .word 0 .word 0 + +_secure_reset: +#ifdef CONFIG_SECURE_MONITOR_RESET_FUNCTION + .word CONFIG_SECURE_MONITOR_RESET_FUNCTION +#else + .word 0 +#endif + .macro is_cpu_virt_capable tmp That enabled me to define CONFIG_SECURE_MONITOR_RESET_FUNCTION in my config header file: /* * With the Secure Monitor at 0x0, its reset vector must also * then point off to the correct out-of-reset entry function. */ #define CONFIG_SECURE_MONITOR_RESET_FUNCTION_myplatform_cpu_entry #define CONFIG_ARMV7_SECURE_BASE0x0 That _myplatform_cpu_entry corresponds to your sunxi_cpu_entry code. So, yeah, I know that isn't a proper patch and all. :-) I'm just sending you more information to ponder for this patch series! If you would like to generalize your patch this way, please feel free to do so. If not, I can send a proper patch after this hits mainline or so. HTH, jdl On Sat, Apr 26, 2014 at 7:17 AM, Marc Zyngier marc.zyng...@arm.com wrote: The current non-sec switching code suffers from one major issue: it cannot run in secure RAM, as a large part of u-boot still needs to be run while we're switched to non-secure. This patch reworks the whole HYP/non-secure strategy by: - making sure the secure code is the *last* thing u-boot executes before entering the payload - performing an exception return from secure mode directly into the payload - allowing the code to be dynamically relocated to secure RAM before switching to non-secure. This involves quite a bit of horrible code, specially as u-boot relocation is quite primitive. Signed-off-by: Marc Zyngier marc.zyng...@arm.com --- arch/arm/cpu/armv7/nonsec_virt.S | 161 +++ arch/arm/cpu/armv7/virt-v7.c | 59 +- arch/arm/include/asm/armv7.h | 10 ++- arch/arm/include/asm/secure.h| 26 +++ arch/arm/lib/bootm.c | 22 +++--- 5 files changed, 138 insertions(+), 140 deletions(-) create mode 100644 arch/arm/include/asm/secure.h diff --git a/arch/arm/cpu/armv7/nonsec_virt.S b/arch/arm/cpu/armv7/nonsec_virt.S index b5c946f..2a43e3c 100644 --- a/arch/arm/cpu/armv7/nonsec_virt.S +++ b/arch/arm/cpu/armv7/nonsec_virt.S @@ -10,10 +10,13 @@ #include linux/linkage.h #include asm/gic.h #include asm/armv7.h +#include asm/proc-armv/ptrace.h .arch_extension sec .arch_extension virt + .pushsection ._secure.text, ax + .align 5 /* the vector table for secure state and HYP mode */ _monitor_vectors: @@ -22,51 +25,86 @@ _monitor_vectors: adr pc, _secure_monitor .word 0 .word 0 - adr pc, _hyp_trap + .word 0 .word 0 .word 0 +.macro is_cpu_virt_capable tmp + mrc p15, 0, \tmp, c0, c1, 1 @ read ID_PFR1 + and \tmp, \tmp, #CPUID_ARM_VIRT_MASK@ mask virtualization bits + cmp \tmp, #(1 CPUID_ARM_VIRT_SHIFT) +.endm + /* * secure monitor handler * U-boot calls this software interrupt in start.S * This is executed on a smc instruction, we use a smc #0 to switch * to non-secure state. - * We use
Re: [U-Boot] [PATCH v4 06/10] ARM: HYP/non-sec: allow relocation to secure RAM
Mark, In your nonsec_init code, you suggest this change: + mrc p15, 0, r0, c1, c1, 2 movwr1, #0x3fff - movtr1, #0x0006 - mcr p15, 0, r1, c1, c1, 2 @ NSACR = all copros to non-sec + movtr1, #0x0004 + orr r0, r0, r1 + mcr p15, 0, r0, c1, c1, 2 @ NSACR = all copros to non-sec Leaving: mrc p15, 0, r0, c1, c1, 2 movwr1, #0x3fff movtr1, #0x0004 orr r0, r0, r1 mcr p15, 0, r0, c1, c1, 2 @ NSACR = all copros to non-sec That sets all the co-processor bits, but the man page suggests that only copros with bits 10 and 11 should be modified. It also seems that if the PLE is enabled, we should mark it NS-enabled at bit 16 also:. Perhaps: mrcp15, 0, r0, c1, c1, 2 movwr1, #0x0c00 movtr1, #0x0005 orrr0, r0, r1 mcrp15, 0, r0, c1, c1, 2@ NSACR = all copros to non-sec HTH, jdl On Fri, May 2, 2014 at 3:30 PM, Jon Loeliger loeli...@gmail.com wrote: Mark, I finally have all this working for me on an A9 system too! However, there were a few things that I had to change a bit. For example, by CPUs will always come out of reset at 0x0 and I do not have the ability to set their first-fetch address to anything else. To accommodate this, I need to ensure that the _monitor_vectors are loaded at address 0x0, and that the first entry in the exception vector (for reset) jumped to some notion of secure_reset code. So I changed this code: diff --git a/arch/arm/cpu/armv7/nonsec_virt.S b/arch/arm/cpu/armv7/nonsec_virt.S index b5c946f..2a43e3c 100644 --- a/arch/arm/cpu/armv7/nonsec_virt.S +++ b/arch/arm/cpu/armv7/nonsec_virt.S @@ -10,10 +10,13 @@ #include linux/linkage.h #include asm/gic.h #include asm/armv7.h +#include asm/proc-armv/ptrace.h .arch_extension sec .arch_extension virt + .pushsection ._secure.text, ax + .align 5 /* the vector table for secure state and HYP mode */ _monitor_vectors: @@ -22,51 +25,86 @@ _monitor_vectors: adr pc, _secure_monitor .word 0 .word 0 - adr pc, _hyp_trap + .word 0 .word 0 .word 0 +.macro is_cpu_virt_capable tmp + mrc p15, 0, \tmp, c0, c1, 1 @ read ID_PFR1 + and \tmp, \tmp, #CPUID_ARM_VIRT_MASK@ mask virtualization bits + cmp \tmp, #(1 CPUID_ARM_VIRT_SHIFT) +.endm So that it did this too: @@ -20,15 +20,23 @@ .align 5 /* the vector table for secure state and HYP mode */ _monitor_vectors: - .word 0 /* reset */ - .word 0 /* undef */ - adr pc, _secure_monitor + ldr pc, _secure_reset /* reset */ + .word 0 /* undef */ + adr pc, _secure_monitor /* SMC */ .word 0 .word 0 .word 0 .word 0 .word 0 + +_secure_reset: +#ifdef CONFIG_SECURE_MONITOR_RESET_FUNCTION + .word CONFIG_SECURE_MONITOR_RESET_FUNCTION +#else + .word 0 +#endif + .macro is_cpu_virt_capable tmp That enabled me to define CONFIG_SECURE_MONITOR_RESET_FUNCTION in my config header file: /* * With the Secure Monitor at 0x0, its reset vector must also * then point off to the correct out-of-reset entry function. */ #define CONFIG_SECURE_MONITOR_RESET_FUNCTION_myplatform_cpu_entry #define CONFIG_ARMV7_SECURE_BASE0x0 That _myplatform_cpu_entry corresponds to your sunxi_cpu_entry code. So, yeah, I know that isn't a proper patch and all. :-) I'm just sending you more information to ponder for this patch series! If you would like to generalize your patch this way, please feel free to do so. If not, I can send a proper patch after this hits mainline or so. HTH, jdl On Sat, Apr 26, 2014 at 7:17 AM, Marc Zyngier marc.zyng...@arm.com wrote: The current non-sec switching code suffers from one major issue: it cannot run in secure RAM, as a large part of u-boot still needs to be run while we're switched to non-secure. This patch reworks the whole HYP/non-secure strategy by: - making sure the secure code is the *last* thing u-boot executes before entering the payload - performing an exception return from secure mode directly into the payload - allowing the code to be dynamically relocated to secure RAM before switching to non-secure. This involves quite a bit of horrible code, specially as u-boot relocation is quite primitive. Signed-off-by: Marc Zyngier marc.zyng...@arm.com --- arch/arm/cpu/armv7/nonsec_virt.S | 161 +++ arch/arm/cpu/armv7/virt-v7.c | 59 +- arch/arm/include/asm/armv7.h | 10 ++- arch/arm/include/asm/secure.h| 26 +++ arch/arm/lib/bootm.c | 22 +++--- 5 files changed, 138 insertions(+), 140 deletions(-) create mode 100644 arch/arm/include/asm/secure.h diff --git a/arch/arm/cpu
Re: [U-Boot] [PATCH] Revert build: Use filechk rules to create and update u-boot.lds
On 04/20/2014 09:33 PM, Masahiro Yamada wrote: This reverts commit a8b993eb81c142a439c24b871a2317f765fe5397. Commit a8b993eb claims it fixes u-boot.lds rule by replacing $(call if_changed) with $(call filechk). But the problem had already been fixed by commit 395e60cd a few days before commit a8b993eb was posted. Bummer. Sorry about that. I didn't see Masahiro's patch. What is worse is $(call filechk) is too strong to fix the problem and looks weird. I'm sure I don't understand that critique at all. Looks weird? However, your patch (395e60cdc) is better in that it catches both the regular top-level and the SPL build's load scripts. Mine did not. jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 00/13] ARMv7: add PSCI support to u-boot
No, so far there hasn't been much discussion, and people seem happy with it. I have a couple of fixes lined up, but nothing major. So, I think PSCI 0.2 calls for function numbers in the 0x8400 range. Seems like we'll have to fix this in one of your patches: /* PSCI interface */ #define ARM_PSCI_FN_BASE0x95c1ba5e to be: #define ARM_PSCI_FN_BASE0x8400 Just thought I'd toss that out there, you know, if you were collecting fixes for a repost of your patches... :-) jdl On Thu, Apr 17, 2014 at 3:58 AM, Marc Zyngier marc.zyng...@arm.com wrote: On Thu, Apr 17 2014 at 9:34:24 am BST, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Marc, On Wed, 16 Apr 2014 17:09:07 +0100, Marc Zyngier marc.zyng...@arm.com wrote: On 16/04/14 15:45, Albert ARIBAUD wrote: Hi Marc, On Sat, 15 Feb 2014 13:36:24 +, Marc Zyngier marc.zyngier-5wv7dgni...@public.gmane.org wrote: PSCI is an ARM standard that provides a generic interface that supervisory software can use to manage power in the following situations: - Core idle management - CPU hotplug - big.LITTLE migration models - System shutdown and reset It basically allows the kernel to offload these tasks to the firmware, and rely on common kernel side code. More importantly, it gives a way to ensure that CPUs enter the kernel at the appropriate exception level (ie HYP mode, to allow the use of the virtualization extensions), even across events like CPUs being powered off/on or suspended. The main idea here is to turn some of the existing u-boot code into a separate section that can live in secure RAM (or a reserved page of memory), containing a secure monitor that will implement the PSCI operations. This code will still be alive when u-boot is long gone, hence the need for a piece of memory that will not be touched by the OS. This patch series contains 4 parts: - the first four patches are just bug fixes - the next two refactor the HYP/non-secure code to allow relocation in secure memory - the next four contain the generic PSCI code and DT infrastructure - the last three implement the CPU_ON method of the Allwinner A20 (aka sun7i). I realize the A20 u-boot code is not upstream yet (BTW is anyone actively working on that?), but hopefully that should give a good idea of how things are structured so far. The patches are against the mainline u-boot tree as of today, merged with the sunxi u-boot tree of the day and the first 10 patches will directly apply to mainline u-boot. As for using this code, it goes like this: sun7i# ext2load mmc 0:1 0x40008000 zImage ; ext2load mmc 0:1 0x6000 sun7i-a20-cubietruck.dtb 2270120 bytes read in 117 ms (18.5 MiB/s) 9138 bytes read in 3 ms (2.9 MiB/s) sun7i# fdt addr 0x6000 ; fdt resize ; fdt set ethernet0 mac-address [5a fe b0 07 b0 07] sun7i# setenv bootargs console=ttyS0,115200 earlyprintk ip=dhcp root=/dev/nfs nfsroot=/backup/a20_root,tcp sun7i# bootz 0x40008000 - 0x6000 The kernel now boots in HYP mode, finds its secondary CPU without any SMP code present in the kernel, and runs KVM out of the box. I've been told the Xen/ARM guys managed to do the same fairly easily. This code has also been tested on a VExpress TC2, running KVM with all 5 CPUs, in order to make sure there was no obvious regression. I'm wildly cross-posting this patch series, including to lists I'm not subscribed to. Please keep me on Cc for any comment you may have. The code is also available at: git://git.kernel.org/pub/scm/linux/kernel/git/maz/u-boot.git wip/psci Cheers, M. Marc, I'm unclear what you want to do with this series. You mention that its first 10 patches will apply to U-Boot, but I am not sure whether you are just indicating that it is possible to apply them or asking for these 10 patches to go in U-Boot mainline. Or is it something else yet? Well, I rarely write code just for the sake of forking a critical project ;-) So let's be 100% explicit: Yes, I'm hereby asking for these patches to be merged. They offer a service that is required by the Linux kernel as well as Xen. They are in active use on the Allwinner sun7i platform as well as Versatile Express (though the later doesn't have a PSCI implementation). Now, given that two months have gone past without much comment other than the odd hey, works great, I don't really know where to take that. Are you willing to review the patches? Well, I rarely ask about patches just for the sake of conversation. O:-) So yes, I am willing to review them -- and I suspect others are, as well. Nobody commented the V3 series on the U-Boot list -- save for Jon's comment about the series needing a rebase -- which could mean no one here is unhappy with them... or they were discussed and possibly acted upon on linux-sunxi, where the replies were redirected. I don't
[U-Boot] Fwd: [PATCH v3 00/13] ARMv7: add PSCI support to u-boot
[ Drat. I meant to send this to the U-Boot list, not just Albert. --jdl] -- Forwarded message -- From: Jon Loeliger loeli...@gmail.com Date: Thu, Apr 17, 2014 at 11:36 AM Subject: Re: [U-Boot] [PATCH v3 00/13] ARMv7: add PSCI support to u-boot To: Albert ARIBAUD albert.u.b...@aribaud.net On Thu, Apr 17, 2014 at 3:34 AM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Marc, So yes, I am willing to review them -- and I suspect others are, as well. Nobody commented the V3 series on the U-Boot list -- save for Jon's comment about the series needing a rebase -- which could mean no one here is unhappy with them... So, not *unhappy* with them, but definitely some review is needed. Also, there are aspects of the implementation that will need to be generalized a bit. For example, the sunxi code uses a magic register in its implementation that allows a core to come out of reset at a known (ie, given) non-0 address. My A9 core has CPUs coming out of reset at a fixed address of 0. That means my secure text must be at 0, and it must have a secure vector with a secure reset laid down at 0. Ultimately, this means that a small modification (adding a secure vector text section) to the LDS file will be needed to ensure that it is placed at 0 within the secure text section itself. No, I don't have all this working quite yet. :-) jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] build: Use filechk rules to create and update u-boot.lds
Prior to this patch, the top-level linker script u-boot.lds used a simple $(call if_changed) check when generated. That mechanism misses cases where a possible include file change induces a change in the u-boot.lds too. This patch converts it to a stronger check using ($call filechk) that will also notice differences in file contents and will catch changes due to pre-processing as well. Signed-off-by: Jon Loeliger jon.loeli...@oracle.com --- Makefile | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/Makefile b/Makefile index b807e5c..dcc42b2 100644 --- a/Makefile +++ b/Makefile @@ -1052,12 +1052,13 @@ depend dep: @echo '*** Warning: make $@ is unnecessary now.' # --- -quiet_cmd_cpp_lds = LDS $@ -cmd_cpp_lds = $(CPP) $(cpp_flags) $(LDPPFLAGS) -ansi -D__ASSEMBLY__ \ - -x assembler-with-cpp -P -o $@ $ +define filechk_ubootlds + ($(CPP) $(cpp_flags) $(LDPPFLAGS) -ansi -D__ASSEMBLY__ \ + -x assembler-with-cpp -P -o - -) +endef u-boot.lds: $(LDSCRIPT) prepare FORCE - $(call if_changed,cpp_lds) + $(call filechk,ubootlds) PHONY += nand_spl nand_spl: prepare -- 1.9.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 00/13] ARMv7: add PSCI support to u-boot
On 04/16/2014 11:09 AM, Marc Zyngier wrote: Marc, I'm unclear what you want to do with this series. You mention that its first 10 patches will apply to U-Boot, but I am not sure whether you are just indicating that it is possible to apply them or asking for these 10 patches to go in U-Boot mainline. Or is it something else yet? Well, I rarely write code just for the sake of forking a critical project ;-) So let's be 100% explicit: Yes, I'm hereby asking for these patches to be merged. They offer a service that is required by the Linux kernel as well as Xen. They are in active use on the Allwinner sun7i platform as well as Versatile Express (though the later doesn't have a PSCI implementation). Now, given that two months have gone past without much comment other than the odd hey, works great, I don't really know where to take that. Are you willing to review the patches? Thanks, M. I too need them. I am actively working on using them and bringing up another platform. They will need to be rebased to top of tree, though. jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] State of ARMv7 PSCI support?
Folks, I am curious about the state of the PSCI support on ARMv7, specifically the Cortex-A9, these days. I see that Marc Zyngier posted a 9 part patch a few months ago: [PATCH 0/9] ARMv7: add PSCI support to u-boot And I see that aspects of that series (Patch 1 Fix alignment requirements for vectors) have otherwise gone into mainline, but I was wondering if a rebased and more recent version of the patch series was available? I checked the ARM repo, and I can't find the series in there either. Is there a plan or interest in seeing this support added still? Thanks, jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 3/4] dtc/libfdt: introduce fdt types for annotation by endian checkers
Projects such as linux and u-boot run sparse on libfdt. libfdt contains the notion of endianness via usage of endian conversion functions such as fdt32_to_cpu. As such, in order to pass endian checks, libfdt has to annotate its fdt variables such that sparse can warn when mixing bitwise and regular integers. This patch adds these new fdtXX_t types and, ifdef __CHECKER__ (a symbol sparse defines), includes the bitwise annotation. Signed-off-by: Kim Phillips kim.phill...@freescale.com Applied. Thanks, jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4 v2] dtc/libfdt: introduce fdt types for annotation by endian checkers
Hi Kim,
I hope this addresses all your comments, David.
Which is why David didn't see this patch earlier. :-)
index 213d7fb..302d5cb 100644
--- a/libfdt/libfdt_env.h
+++ b/libfdt/libfdt_env.h
@@ -5,25 +5,63 @@
#include stdint.h
#include string.h
+#ifdef __CHECKER__
+#define __force __attribute__((force))
+#define __bitwise __attribute__((bitwise))
+typedef uint16_t __bitwise fdt16_t;
+typedef uint32_t __bitwise fdt32_t;
+typedef uint64_t __bitwise fdt64_t;
+#else
+#define __force
+#define __bitwise
+typedef uint16_t fdt16_t;
+typedef uint32_t fdt32_t;
+typedef uint64_t fdt64_t;
+#endif
Would this be simpler/better?
#ifdef __CHECKER__
#define __force __attribute__((force))
#define __bitwise __attribute__((bitwise))
#else
#define __force
#define __bitwise
#endif
typedef uint16_t __bitwise fdt16_t;
typedef uint32_t __bitwise fdt32_t;
typedef uint64_t __bitwise fdt64_t;
#define EXTRACT_BYTE(n) ((unsigned long long)((uint8_t *)x)[n])
-static inline uint16_t fdt16_to_cpu(uint16_t x)
-{
- return (EXTRACT_BYTE(0) 8) | EXTRACT_BYTE(1);
-}
-#define cpu_to_fdt16(x) fdt16_to_cpu(x)
+#define __SWAB16X ((EXTRACT_BYTE(0) 8) | EXTRACT_BYTE(1))
+#define __SWAB32X ((EXTRACT_BYTE(0) 24) | (EXTRACT_BYTE(1) 16) |
(EXTRACT_BYTE(2)
8) | EXTRACT_BYTE(3))
+#define __SWAB64X ((EXTRACT_BYTE(0) 56) | (EXTRACT_BYTE(1) 48) |
(EXTRACT_BYTE(2)
40) | (EXTRACT_BYTE(3) 32) \
+ | (EXTRACT_BYTE(4) 24) | (EXTRACT_BYTE(5) 16) |
(EXTRACT_BYTE(6) 8
) | EXTRACT_BYTE(7))
I dislike function-like macros that grab global names.
Instead, can we re-work 'x' in as a parameter:
#define EXTRACT_BYTE(x, n) ((unsigned long long)((uint8_t *)x)[n])
+#define DEF_FDT_TO_CPU(bits) \
+static inline uint##bits##_t fdt##bits##_to_cpu(fdt##bits##_t x) \
+{ \
+ if (*__first_byte == 0x11) \
+ return (__force uint##bits##_t)x; \
+ else \
+ return (__force uint##bits##_t)__SWAB##bits##X; \
}
Case check that last X...
-static inline uint64_t fdt64_to_cpu(uint64_t x)
-{
- return (EXTRACT_BYTE(0) 56) | (EXTRACT_BYTE(1) 48) |
(EXTRACT_BYTE(2) 40) |
(EXTRACT_BYTE(3) 32)
- | (EXTRACT_BYTE(4) 24) | (EXTRACT_BYTE(5) 16) |
(EXTRACT_BYTE(6) 8)
| EXTRACT_BYTE(7);
+#define DEF_CPU_TO_FDT(bits) \
+static inline fdt##bits##_t cpu_to_fdt##bits(uint##bits##_t x) \
+{ \
+ if (*__first_byte == 0x11) \
+ return (__force fdt##bits##_t)x; \
+ else \
+ return (__force fdt##bits##_t)__SWAB##bits##X; \
}
...and that one.
Thanks,
jdl
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Jon Loeliger is not maintaining any Freescale board.
From: Jon Loeliger j...@jdl.com Signed-off-by: Jon Loeliger j...@jdl.com --- Becky schrieb: On Dec 2, 2009, at 3:55 AM, Thirumalai wrote: Thank you denx. Hi Jon, The email address you used for Jon is invalid (we need to update the maintainers file - Jon should weigh in here). MAINTAINERS |9 - 1 files changed, 0 insertions(+), 9 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index d70a9d2..19a866b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -277,15 +277,6 @@ Nye Liu n...@zumanetworks.com ZUMAMPC7xx_74xx -Jon Loeliger j...@freescale.com - - MPC8540ADS MPC8540 - MPC8560ADS MPC8560 - MPC8541CDS MPC8541 - MPC8555CDS MPC8555 - - MPC8641HPCN MPC8641D - Ron Madrid i...@sheldoninst.com SIMPC8313 MPC8313 -- 1.6.2.rc0.90.g0753 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Status open patches: 8xxx
On Sun, 2009-02-22 at 01:00 +0100, Wolfgang Denk wrote: Dear Kim, Andy Jon, I have the following patches still marked as open in my list. Could you please have a look... 8xxx: 02/04 Jon Loeliger Re: [U-Boot] [PATCH 4/8] mpc86xx: Add support to populate addr map based on BATs 02/04 Jon Loeliger Re: [U-Boot] [PATCH 8/8] mpc8641hpcn: Change PCI MEM pci bus address 02/04 Jon Loeliger Re: [U-Boot] [PATCH 1/8] mpc8641hpcn: Set up outbound pci windows before inbound 02/04 Jon Loeliger Re: [U-Boot] [PATCH 5/8] mpc8641hpcn: Clean up PCI mapping concepts 02/12 Becky Bruce[U-Boot] [PATCH] mpc8641hpcn: Indicate 36-bit addr map in boot messages 02/12 Becky Bruce[U-Boot] [PATCH] MPC86xx: set CONFIG_MAX_MEM_MAPPED to 2G by default 02/12 Becky BruceRe: [U-Boot] [PATCH] MPC86xx: set CONFIG_MAX_MEM_MAPPED to 2G by default 02/12 Jon Loeliger Re: [U-Boot] [PATCH] MPC86xx: set CONFIG_MAX_MEM_MAPPED to 2G by default Best regards, Wolfgang Denk Wolfgang, It was my belief that all outstanding 86xx patches had either been Acked-by me and should be picked up by either Andy or Wolfgang, or had been subsumed into other already applied patches. Becky (or Kumar?), Could you verify that the 36-bit and address-map related patches are correct in WD's current master head and that you are happy with them? I thought we got them all there, but I could be wrong. Or maybe we need to wait for a set to be picked up with the 85xx tree from Andy still? Thanks, jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Status open patches: 8xxx
Becky Bruce wrote: This one should still apply and needs to be picked up, WD can pick it up directly because it's very small: 02/12 Becky Bruce[U-Boot] [PATCH] mpc8641hpcn: Indicate 36-bit addr map in boot messages OK, sounds fine by me. Thanks. The second one looks like it won't apply anymore due to a change from Stefan; I will submit a new one that WD can pick up directly as long as it's OK with you. Yep, consider it pre-Ack'ed. :-) Thanks, jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MPC86xx: set CONFIG_MAX_MEM_MAPPED to 2G by default
Becky Bruce wrote: Currently, we get 256MB as the default, but since all the 86xx board configs define a 2G BAT mapping for RAM, raise default to 2G. Signed-off-by: Becky Bruce bec...@kernel.crashing.org --- Oh, OK, consider it... Acked-by: Jon Loeliger j...@freescale.com for real. Thanks, jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix Freescale link scripts for newer GCCs
Wolfgang Denk wrote: Please don't. I really want to see this fixed for ALL affected boards, not only for a small subset so everbody forgets it again and we run into it later again and again. Trent - you have obviously already spend a lot of effort into analyzing this code - most probably more time than any other of us. Based on your experience and the effort you already spent I think it would be best if you could provided a patch to fix all boards. Just as a clarification, are you asking Trent to *fix* it for all boards, or to generate a patch that will apply to all boards? Specifically, I recall Trent's hesitation was he doesn't have access to most boards (not even all PPC boards), and he wasn't even sure it was a problem on some other ARCHes in the first place. But, if you are asking for an off-the-cuff patch that can be applied to all boards without testing by Trent, then I am confident he would be willing to help here. jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 1/12 Multiadapter/multibus I2C, common part 1
On Fri, 2009-02-13 at 09:03 +0100, Heiko Schocher wrote: Hello ksi, k...@koi8.net wrote: Signed-off-by: Sergey Kubushyn k...@koi8.net Patch aplies with warnings: Applying: 1/12 Multiadapter/multibus I2C, common part 1 /home/hs/i2c/u-boot-i2c/.git/rebase-apply/patch:630: trailing whitespace. /home/hs/i2c/u-boot-i2c/.git/rebase-apply/patch:688: trailing whitespace. /home/hs/i2c/u-boot-i2c/.git/rebase-apply/patch:765: trailing whitespace. /home/hs/i2c/u-boot-i2c/.git/rebase-apply/patch:808: trailing whitespace. /home/hs/i2c/u-boot-i2c/.git/rebase-apply/patch:1017: trailing whitespace. char*name; warning: 5 lines add whitespace errors. please fix Just do this instead always: git am -3 --whitespace=fix path/to.patch jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MPC86xx: set CONFIG_MAX_MEM_MAPPED to 2G by default
Becky Bruce wrote: By the way, this patch depends on Kumar's patch: 85xx: Fix how we map DDR memory (which itself depends on some other patches) Cheers, B OK. So, consider these 86xx patches... Acked-by: Jon Loeliger j...@freescale.com ...so that Andy (?) might pick up the whole lot of them. Thanks, jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/8] mpc8641hpcn: Clean up PCI mapping concepts
Becky Bruce wrote: Clean up PCI mapping concepts in the 8641 config - rename _BASE to _BUS, as it's actually a PCI bus address, separate virtual and physical addresses into _VIRT and _PHYS, and use each appopriately. Signed-off-by: Becky Bruce bec...@kernel.crashing.org Acked-by: Jon Loeliger j...@freescale.com Assuming someone else will now pick up this series. Thanks, jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/8] mpc8641hpcn: Set up outbound pci windows before inbound
Becky Bruce wrote: Because the inbound pci windows are mapped generously, set up the more specific outbound windows first. This way, when we search the pci regions for something, we will hit on the more specific region. This can actually be a problem on systems with large amounts of RAM. Signed-off-by: Becky Bruce bec...@kernel.crashing.org Acked-by: Jon Loeliger j...@freescale.com Assuming someone else will now pick up this series. Thanks, jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot newbie - question about the 'debug( )' function ...
On Wed, 2009-01-14 at 15:45 -0500, Jonathan Barrow wrote: In many of the sources, such as board.c, I notice calls to 'debug()'. The syntax looks similar to printf(), e.g.: debug (Stack Pointer at: %08lx\n, addr_sp); Is this output sent to the BDM, such as bdi2000? or Ethernet? posted to memory? Also, is debug() related to the setting in 'config.mk' : DBGFLAGS= -g # DDEBUG I can't seem to locate where it lives, so uncertain how it works. Thank You, J.J. Barrow Typically, I just put a #define DEBUG in a specific file or two that I'm interested in. That has to be done before the #include of common.h to be effective. Rebuild, reflash, read output on serial port. HTH, jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request for u-boot-mpc86xx
Wolfgang, The following changes since commit 950309c6436ff78d2166377da34bfdb0ae00a4a4: Wolfgang Denk (1): Merge branch 'master' of git://git.denx.de/u-boot-blackfin are available in the git repository at: git://www.denx.de/git/u-boot-mpc86xx.git master Becky Bruce (2): sbc8641d: Fix PCI mapping concepts mpc8610hpcd: Fix PCI mapping concepts board/freescale/mpc8610hpcd/law.c |4 +- board/freescale/mpc8610hpcd/mpc8610hpcd.c | 12 +- board/sbc8641d/law.c | 10 board/sbc8641d/sbc8641d.c |8 +++--- include/configs/MPC8610HPCD.h | 24 +++-- include/configs/sbc8641d.h| 32 6 files changed, 48 insertions(+), 42 deletions(-) Thanks, jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] freescale target?
On Thu, 2009-01-08 at 23:42 +, Daniel Ng wrote: Hi, Would someone please explain the effect of 'freescale' as a Makefile target? I've got a freescale MPC8272-based board but I'm not sure if I need this 'freescale' target that the other boards use eg.- MPC8266ADS_config: unconfig @$(MKCONFIG) $(@:_config=) ppc mpc8260 mpc8266ads freescale ^ That isn't a make target. That is an option to the mkconfig script. jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] FSL DDR @ 83xx
Andre Schwarz wrote: I don't believe anyone is currently working on getting the new ddr code to be used w/83xx. Feel free to submit patches that does this and we will review them as they are posted. - k After spending few hours it seems to work basically. This is what I've done : - add mpc8xxx(ddr/libddr.a to top level Makefile for 83xx - created mpc83xx/ddr-gen2.c and ported to meet ddr83xx_t - created board specific ddr.c for SPD accessor and basic setup. - created board specific ddr2_spd_eeprom_t (soldered memory) The board config got these #defines : #define CONFIG_FSL_DDR2 #define CONFIG_DDR_SPD #define CONFIG_NUM_DDR_CONTROLLERS 1 - this should go into mpc83xx header #define CONFIG_DIMM_SLOTS_PER_CTLR 1 #define CONFIG_CHIP_SELECTS_PER_CTRL1 Since spd_sdram.o is always build (mpc83xx/Makefile) and the code is also activated by CONFIG_SPD_EEPROM we should find a reasonable way to switch between old and new DDR code by some kind of #define. Is this the way to go ? Yes, it is. You will also need a per-board set of functions to answer the configuration issues in a way similar to the rest of the 85xx and 86xx boards. You will have to carefully juggle the presence of the new and old simultaneously (via CONFIG_FSL_DDR2, likely) until all the 83xx boards are supported under the new mechanism. jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] FSL DDR @ 83xx
Andre Schwarz wrote: I don't believe anyone is currently working on getting the new ddr code to be used w/83xx. Feel free to submit patches that does this and we will review them as they are posted. - k After spending few hours it seems to work basically. This is what I've done : - add mpc8xxx(ddr/libddr.a to top level Makefile for 83xx - created mpc83xx/ddr-gen2.c and ported to meet ddr83xx_t - created board specific ddr.c for SPD accessor and basic setup. - created board specific ddr2_spd_eeprom_t (soldered memory) The board config got these #defines : #define CONFIG_FSL_DDR2 #define CONFIG_DDR_SPD #define CONFIG_NUM_DDR_CONTROLLERS 1 - this should go into mpc83xx header #define CONFIG_DIMM_SLOTS_PER_CTLR 1 #define CONFIG_CHIP_SELECTS_PER_CTRL1 Since spd_sdram.o is always build (mpc83xx/Makefile) and the code is also activated by CONFIG_SPD_EEPROM we should find a reasonable way to switch between old and new DDR code by some kind of #define. Is this the way to go ? Yes, it is. You will also need a per-board set of functions to answer the configuration issues in a way similar to the rest of the 85xx and 86xx boards. You will have to carefully juggle the presence of the new and old simultaneously (via CONFIG_FSL_DDR2, likely) until all the 83xx boards are supported under the new mechanism. jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] FSL DDR @ 83xx
Andre Schwarz wrote:
mpc83xx/spd_sdram needs some fixes to work with latest chips :
1.
max_data_rate seems to be mishandled. Since it's twice the physical
clock we need much higher vaues for calculating optimum caslat ... or
use max_bus_clock instead. bus_clock seems to be reasonable since the
SPD timing values refer to clock and/or clock cycle time.
if (max_data_rate = 390 max_data_rate 460) { /* it is DDR 400 */
This is the top-level if - DDR-333 gives max_data_rate = 666 and
goes into
else if (max_data_rate = 323) { /* it is DDR 333 */
Additionally the caslat reduction code should use = and = for the
evaluation of clk_cycle2 and clk_cycle3. Otherwise it will only work for
a specific memory with SPD contents.
To make it short :
DDR-II-333 will be configured with caslat = 5 @ 133MHz Controller speed
- It would work fine with caslat = 3.
2.
Actually 3 bank adress bits are quite usual. This SPD values are not yet
evaluated.
3.
Termination schemes (150/75/50 Ohm) and driver characteristics are not
handled at all.
Most boards would need this or may only run stable with the most
conservative timings.
Does it make sense to fix these things or is the new DDR code the way
to go ?
Ultimately, one way or another, at the end of the day, when all
is said and done, the old way will be removed and the new way
will prevail. You know.
So, yeah, all of these per board configurations will have to
be supplied in a new file like each of the 85xx and 86xx boards
have done.
HTH,
jdl
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] FSL DDR @ 83xx
On Mon, 2008-12-08 at 18:02 +0100, Andre Schwarz wrote: Kim, I'd like to change my DDR setup code since it looks like my computed values are not perfectly stable on our 8343 based board. This implies using a fake SPD and the related code to set up the controller. Is the new common FSL DDR setup code (cpu/mpc8xxx/ddr/*) stable for 83xx or shall I stick to cpu/mpc83xx/spd_sdram.c for a while ? The new, common DDR code in use by the FSL boards does not yet cover the 83xx family, though the plan is to eventually do so. Patches in that direction, are, naturally, welcome... :-) jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] 85xx: seperate PIXIS virtual from physical address
On Tue, 2008-12-02 at 14:19 -0600, Kumar Gala wrote: Added a PIXIS_BASE_PHYS for use as the physical address and maintain PIXIS_BASE as the virtual address of the PIXIS fpga registers. This allows us to deal with 36-bit phys on these boards in the future. Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- Nit: s/seperate/separate/ here and 2/2. jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull requst u-boot-mpc86xx
Wolfgang,
The following changes since commit 2077e348c2a84901022ad95311b47b70361e6daa:
Scott Wood (1):
NAND: Fix misplaced return statement in nand_{read,write}_skip_bad().
are available in the git repository at:
git://www.denx.de/git/u-boot-mpc86xx.git master
Becky Bruce (1):
mpc8641: Fix error in README
Jon Loeliger (2):
86xx: Fix non-64-bit compilation problems.
Removed unused CONFIG_L1_INIT_RAM symbol.
doc/README.mpc8641hpcn| 10 +-
include/configs/MPC8349EMDS.h |1 -
include/configs/MPC8349ITX.h |1 -
include/configs/MPC8536DS.h |2 --
include/configs/MPC8540ADS.h |1 -
include/configs/MPC8540EVAL.h |1 -
include/configs/MPC8541CDS.h |1 -
include/configs/MPC8544DS.h |2 --
include/configs/MPC8548CDS.h |1 -
include/configs/MPC8555CDS.h |1 -
include/configs/MPC8560ADS.h |1 -
include/configs/MPC8568MDS.h |1 -
include/configs/MPC8572DS.h |2 --
include/configs/MPC8610HPCD.h | 15 ++-
include/configs/MPC8641HPCN.h |1 -
include/configs/MVBLM7.h |1 -
include/configs/PM854.h |1 -
include/configs/PM856.h |1 -
include/configs/SBC8540.h |1 -
include/configs/TQM834x.h |1 -
include/configs/TQM85xx.h |1 -
include/configs/sbc8349.h |1 -
include/configs/sbc8548.h |1 -
include/configs/sbc8560.h |1 -
include/configs/sbc8641d.h| 15 ++-
include/configs/socrates.h|1 -
include/configs/stxgp3.h |1 -
include/configs/stxssa.h |1 -
28 files changed, 33 insertions(+), 35 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] XPedite5200 board support
On Wed, 2008-11-26 at 11:15 -0600, Peter Tyser wrote: Initial support for Extreme Engineering Solutions XPedite5200 - a MPC8548-based PMC single board computer. Signed-off-by: Peter Tyser [EMAIL PROTECTED] diff --git a/include/configs/XPEDITE5200.h b/include/configs/XPEDITE5200.h new file mode 100644 index 000..701c060 +/* + * Use L1 as initial stack + */ +#define CONFIG_L1_INIT_RAM 1 The above symbol is being removed, and should not be re-introduced in your patch. +#define CONFIG_SYS_INIT_RAM_LOCK 1 +#define CONFIG_SYS_INIT_RAM_ADDR 0xe000 +#define CONFIG_SYS_INIT_RAM_END 0x4000 + Thanks, jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/2] XPedite5200 board support
On Mon, 2008-12-01 at 13:47 -0600, Peter Tyser wrote: Initial support for Extreme Engineering Solutions XPedite5200 - a MPC8548-based PMC single board computer. Signed-off-by: Peter Tyser [EMAIL PROTECTED] --- +/* + * Use L1 as initial stack + */ +#define CONFIG_SYS_INIT_RAM_LOCK 1 *sigh* Shouldn't introduce this here either... +#define CONFIG_SYS_INIT_RAM_ADDR 0xe000 +#define CONFIG_SYS_INIT_RAM_END 0x4000 + Thanks, jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/2] XPedite5200 board support
On Mon, 2008-12-01 at 14:31 -0600, Peter Tyser wrote: Which define are you referring to? A quick glance looks like these 3 defines are used legitimately. Am I missing something? Double *sigh*... I clearly didn't drink enough over the holidays (here). Ignore me. Sorry, jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc8641: Fix error in README
Becky Bruce wrote: I made some updates to the code that didn't make it into the README - fix this Signed-off-by: Becky Bruce [EMAIL PROTECTED] Applied to u-boot-mpc86xx. Thanks, jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] 86xx: Fix non-64-bit compilation problems.
Introducing 64-bit (36-bit) support for the MPC8641HPCN
failed to accomodate the other two 86xx boards.
Introduce definitions for CONFIG_SYS_CCSRBAR_PHYS_{LOW,HIGH}
CONFIG_SYS_CCSR_DEFAULT_DBAT{U,L} and CONFIG_SYS_CCSR_DEFAULT_IBAT{U,L}
with nominal 32-bit values.
Signed-off-by: Jon Loeliger [EMAIL PROTECTED]
Acked-by: Becky Bruce [EMAIL PROTECTED]
---
Guys,
I guess this is sort of a pass-the-brown-paper-bag patch.
I swear I built these boards earlier, and they built fine.
But clearly, there is a problem here that needs to be fixed.
Sorry,
jdl
include/configs/MPC8610HPCD.h | 14 ++
include/configs/sbc8641d.h| 14 ++
2 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/include/configs/MPC8610HPCD.h b/include/configs/MPC8610HPCD.h
index f2fe4a6..5685027 100644
--- a/include/configs/MPC8610HPCD.h
+++ b/include/configs/MPC8610HPCD.h
@@ -81,6 +81,9 @@
#define CONFIG_SYS_CCSRBAR 0xe000 /* relocated CCSRBAR */
#define CONFIG_SYS_IMMRCONFIG_SYS_CCSRBAR /* PQII uses
CONFIG_SYS_IMMR */
+#define CONFIG_SYS_CCSRBAR_PHYS_LOWCONFIG_SYS_CCSRBAR
+#define CONFIG_SYS_CCSRBAR_PHYS_HIGH 0x0
+
#define CONFIG_SYS_PCI1_ADDR (CONFIG_SYS_CCSRBAR+0x8000)
#define CONFIG_SYS_PCIE1_ADDR (CONFIG_SYS_CCSRBAR+0xa000)
#define CONFIG_SYS_PCIE2_ADDR (CONFIG_SYS_CCSRBAR+0x9000)
@@ -388,6 +391,17 @@
#define CONFIG_SYS_IBAT3L (CONFIG_SYS_CCSRBAR | BATL_PP_RW |
BATL_CACHEINHIBIT)
#define CONFIG_SYS_IBAT3U CONFIG_SYS_DBAT3U
+#if (CONFIG_SYS_CCSRBAR_DEFAULT != CONFIG_SYS_CCSRBAR)
+#define CONFIG_SYS_CCSR_DEFAULT_DBATL (CONFIG_SYS_CCSRBAR_DEFAULT \
+ | BATL_PP_RW | BATL_CACHEINHIBIT \
+ | BATL_GUARDEDSTORAGE)
+#define CONFIG_SYS_CCSR_DEFAULT_DBATU (CONFIG_SYS_CCSRBAR_DEFAULT \
+ | BATU_BL_1M | BATU_VS | BATU_VP)
+#define CONFIG_SYS_CCSR_DEFAULT_IBATL (CONFIG_SYS_CCSRBAR_DEFAULT \
+ | BATL_PP_RW | BATL_CACHEINHIBIT)
+#define CONFIG_SYS_CCSR_DEFAULT_IBATU CONFIG_SYS_CCSR_DEFAULT_DBATU
+#endif
+
/*
* BAT432M Cache-inhibited, guarded
* 0xe200_ 1M PCI-Express 2 I/O
diff --git a/include/configs/sbc8641d.h b/include/configs/sbc8641d.h
index 45d8179..fa97827 100644
--- a/include/configs/sbc8641d.h
+++ b/include/configs/sbc8641d.h
@@ -104,6 +104,9 @@
#define CONFIG_SYS_CCSRBAR 0xf800 /* relocated CCSRBAR */
#define CONFIG_SYS_IMMRCONFIG_SYS_CCSRBAR /* PQII uses
CONFIG_SYS_IMMR */
+#define CONFIG_SYS_CCSRBAR_PHYS_LOWCONFIG_SYS_CCSRBAR
+#define CONFIG_SYS_CCSRBAR_PHYS_HIGH 0x0
+
#define CONFIG_SYS_PCI1_ADDR (CONFIG_SYS_CCSRBAR+0x8000)
#define CONFIG_SYS_PCI2_ADDR (CONFIG_SYS_CCSRBAR+0x9000)
@@ -433,6 +436,17 @@
#define CONFIG_SYS_IBAT3L (CONFIG_SYS_CCSRBAR | BATL_PP_RW |
BATL_CACHEINHIBIT)
#define CONFIG_SYS_IBAT3U CONFIG_SYS_DBAT3U
+#if (CONFIG_SYS_CCSRBAR_DEFAULT != CONFIG_SYS_CCSRBAR)
+#define CONFIG_SYS_CCSR_DEFAULT_DBATL (CONFIG_SYS_CCSRBAR_DEFAULT \
+ | BATL_PP_RW | BATL_CACHEINHIBIT \
+ | BATL_GUARDEDSTORAGE)
+#define CONFIG_SYS_CCSR_DEFAULT_DBATU (CONFIG_SYS_CCSRBAR_DEFAULT \
+ | BATU_BL_1M | BATU_VS | BATU_VP)
+#define CONFIG_SYS_CCSR_DEFAULT_IBATL (CONFIG_SYS_CCSRBAR_DEFAULT \
+ | BATL_PP_RW | BATL_CACHEINHIBIT)
+#define CONFIG_SYS_CCSR_DEFAULT_IBATU CONFIG_SYS_CCSR_DEFAULT_DBATU
+#endif
+
/*
* BAT4 32MCache-inhibited, guarded
* 0xe200_ 16MPCI-Express 1 I/O
--
1.6.0.4.761.g47577
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Removed unused CONFIG_L1_INIT_RAM symbol.
Prevent further viral propogation of the unused symbol CONFIG_L1_INIT_RAM by just removing it. Signed-off-by: Jon Loeliger [EMAIL PROTECTED] --- include/configs/MPC8349EMDS.h |1 - include/configs/MPC8349ITX.h |1 - include/configs/MPC8536DS.h |2 -- include/configs/MPC8540ADS.h |1 - include/configs/MPC8540EVAL.h |1 - include/configs/MPC8541CDS.h |1 - include/configs/MPC8544DS.h |2 -- include/configs/MPC8548CDS.h |1 - include/configs/MPC8555CDS.h |1 - include/configs/MPC8560ADS.h |1 - include/configs/MPC8568MDS.h |1 - include/configs/MPC8572DS.h |2 -- include/configs/MPC8610HPCD.h |1 - include/configs/MPC8641HPCN.h |1 - include/configs/MVBLM7.h |1 - include/configs/PM854.h |1 - include/configs/PM856.h |1 - include/configs/SBC8540.h |1 - include/configs/TQM834x.h |1 - include/configs/TQM85xx.h |1 - include/configs/sbc8349.h |1 - include/configs/sbc8548.h |1 - include/configs/sbc8560.h |1 - include/configs/sbc8641d.h|1 - include/configs/socrates.h|1 - include/configs/stxgp3.h |1 - include/configs/stxssa.h |1 - 27 files changed, 0 insertions(+), 30 deletions(-) diff --git a/include/configs/MPC8349EMDS.h b/include/configs/MPC8349EMDS.h index bbdc211..8e82aac 100644 --- a/include/configs/MPC8349EMDS.h +++ b/include/configs/MPC8349EMDS.h @@ -193,7 +193,6 @@ #define CONFIG_SYS_BR1_PRELIM (CONFIG_SYS_BCSR|0x0801)/* Port-size=8bit, MSEL=GPCM */ #define CONFIG_SYS_OR1_PRELIM 0xE8F0 /* length 32K */ -#define CONFIG_L1_INIT_RAM #define CONFIG_SYS_INIT_RAM_LOCK 1 #define CONFIG_SYS_INIT_RAM_ADDR 0xFD00 /* Initial RAM address */ #define CONFIG_SYS_INIT_RAM_END0x1000 /* End of used area in RAM*/ diff --git a/include/configs/MPC8349ITX.h b/include/configs/MPC8349ITX.h index f633f24..14cbc45 100644 --- a/include/configs/MPC8349ITX.h +++ b/include/configs/MPC8349ITX.h @@ -266,7 +266,6 @@ boards, we say we have two, but don't display a message if we find only one. */ #undef CONFIG_SYS_RAMBOOT #endif -#define CONFIG_L1_INIT_RAM #define CONFIG_SYS_INIT_RAM_LOCK #define CONFIG_SYS_INIT_RAM_ADDR 0xFD00 /* Initial RAM address */ #define CONFIG_SYS_INIT_RAM_END0x1000 /* End of used area in RAM*/ diff --git a/include/configs/MPC8536DS.h b/include/configs/MPC8536DS.h index fff888a..f3eee23 100644 --- a/include/configs/MPC8536DS.h +++ b/include/configs/MPC8536DS.h @@ -231,8 +231,6 @@ extern unsigned long get_board_ddr_clk(unsigned long dummy); #define PIXIS_VCLKL0x1A/* VELA VCLKL register */ #define CONFIG_SYS_PIXIS_VBOOT_MASK0xc0 -/* define to use L1 as initial stack */ -#define CONFIG_L1_INIT_RAM #define CONFIG_SYS_INIT_RAM_LOCK 1 #define CONFIG_SYS_INIT_RAM_ADDR 0xffd0 /* Initial L1 address */ #define CONFIG_SYS_INIT_RAM_END0x4000 /* End of used area in RAM */ diff --git a/include/configs/MPC8540ADS.h b/include/configs/MPC8540ADS.h index 79a52d9..0b8fe6a 100644 --- a/include/configs/MPC8540ADS.h +++ b/include/configs/MPC8540ADS.h @@ -258,7 +258,6 @@ #define CONFIG_SYS_OR4_PRELIM 0xe1f1 #define CONFIG_SYS_BCSR(CONFIG_SYS_BR4_PRELIM 0x8000) -#define CONFIG_L1_INIT_RAM #define CONFIG_SYS_INIT_RAM_LOCK 1 #define CONFIG_SYS_INIT_RAM_ADDR 0xe401 /* Initial RAM address */ #define CONFIG_SYS_INIT_RAM_END0x4000 /* End of used area in RAM */ diff --git a/include/configs/MPC8540EVAL.h b/include/configs/MPC8540EVAL.h index 46a141a..21cf965 100644 --- a/include/configs/MPC8540EVAL.h +++ b/include/configs/MPC8540EVAL.h @@ -161,7 +161,6 @@ #define CONFIG_SYS_OR4_PRELIM 0xe1f1 #define CONFIG_SYS_BCSR(CONFIG_SYS_BR4_PRELIM 0x8000) -#define CONFIG_L1_INIT_RAM #define CONFIG_SYS_INIT_RAM_LOCK 1 #define CONFIG_SYS_INIT_RAM_ADDR 0x4000 /* Initial RAM address */ #define CONFIG_SYS_INIT_RAM_END0x4000 /* End of used area in RAM */ diff --git a/include/configs/MPC8541CDS.h b/include/configs/MPC8541CDS.h index 7ada8a2..eaa737b 100644 --- a/include/configs/MPC8541CDS.h +++ b/include/configs/MPC8541CDS.h @@ -281,7 +281,6 @@ extern unsigned long get_clock_freq(void); #define CONFIG_SYS_BR3_PRELIM 0xf8000801 #define CONFIG_SYS_OR3_PRELIM 0xfff00ff7 -#define CONFIG_L1_INIT_RAM #define CONFIG_SYS_INIT_RAM_LOCK 1 #define CONFIG_SYS_INIT_RAM_ADDR 0xe401 /* Initial RAM address */ #define CONFIG_SYS_INIT_RAM_END0x4000 /* End of used area in RAM */ diff --git a/include/configs/MPC8544DS.h b/include/configs/MPC8544DS.h index cdbbea6..ff24fa5 100644 --- a/include/configs/MPC8544DS.h +++ b/include/configs/MPC8544DS.h @@ -207,8 +207,6 @@ extern
Re: [U-Boot] Code style questions (weak functions, cpu/ v's lib_arch/)
Mike Frysinger wrote: i doubt it. the only hard fast rule is dont make Wolfgang disagreeable. -mike Come now! WD is never disagreeable! He may disagree with you, but I've always found him to be a rather pleasant sort of fellow! jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] XPedite5370 board support
Peter Tyser wrote: We have the standard Freescale DDR printf's turned into debug as that is much, much more verbose than the output above. Indeed :-( Hrm. Out of curiosity, which printf()s do you find noisy? Many boards I look at don't use TABS. In particular Freescale reference platforms. Many boards even have different amounts of spaces:) I don't see the value of indentation in this case as it doesn't increase readability and just makes already long lines even longer. Really? Which ones? We should clean those up! Thanks, jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull Request: u-boot-mpc86xx
On Tue, 2008-11-18 at 21:49 +0100, Wolfgang Denk wrote: are available in the git repository at: git://www.denx.de/git/u-boot-mpc86xx.git masterges since commit Applied, thanks. Best regards, Wolfgang Denk Thanks! jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc8641: fix address-cells default in old .dts detection
On Mon, 2008-11-10 at 19:45 -0600, Becky Bruce wrote: address-cells defaults to 2, not 1; so in the unlikely event that it isn't specified, this patch is required for correct operation. Signed-off-by: Becky Bruce [EMAIL PROTECTED] --- Applied and pushed out. Wolfgang, I added this to my custodian repo, so it will be present in the pull-request I sent out a few days ago. Thanks, jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] lib_ppc: Move trap_init to occur earlier
On Mon, 2008-11-03 at 10:18 -0600, Jon Loeliger wrote: On Fri, 2008-10-31 at 17:14 -0500, Becky Bruce wrote: Doing trap_init immediately once we're running from RAM means we're no longer dependent on the physical location of the flash on non-BookE platforms. Before trap_init, those platforms switch to real mode and go to 0xfff00100 on exception. After the switch, they go to 0x0100 This makes it easier to move the flash location. Signed-off-by: Becky Bruce [EMAIL PROTECTED] --- lib_ppc/board.c | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) Wolfgang, Will you pick this one up? Or would you like me to run it through u-boot-mpc86xx with the others? Thanks, jdl Wolfgang, I spoke to Becky about this patch and she says it is required for the rest of her 86xx patches to work. So I will pick this one up and run it through the u-boot-mpc86xx git tree. Thanks, jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull Request: u-boot-mpc86xx
The following changes since commit 1378174a1351c0285736863a665ab758fe8d5f71: Wolfgang Denk (1): Merge branch 'master' of /home/wd/git/u-boot/custodians are available in the git repository at: git://www.denx.de/git/u-boot-mpc86xx.git masterges since commit Becky Bruce (18): mpc8641: Stop supporting non-PCI_PNP configs mpc8641: Make PCI and RIO mutually exclusive, fix non-PCI build powerpc 86xx: Handle CCSR relocation earlier 86xx: Make dram_size a phys_size_t 8641HPCN: Config file cleanup powerpc: change 86xx SMP boot method mpc8641: Remove extra 0 from BR2 define mpc86xx: Move setup_bats into cpu_init_f mpc8641: only define CONFIG_ENV_SIZE once mpc8641: Drop imaginary second flash bank, map 8MB mpc8641: make DIAG_ADDR == FLASH_BASE mpc86xx: Use SRR0/1/rfi to enable address translation, not blr mpc86xx: Change early FLASH mapping to 1M at CONFIG_MONITOR_BASE_EARLY mpc8641: Change 32-bit memory map mpc8641: Support 36-bit physical addressing toplevel Makefile: Add MPC8641HPCN_36BIT target mpc8641: Try to detect old .dts files lib_ppc: Move trap_init to occur earlier Jon Loeliger (1): Merge commit 'wd/master' Makefile |8 +- board/freescale/mpc8610hpcd/mpc8610hpcd.c |6 +- board/freescale/mpc8641hpcn/config.mk |2 +- board/freescale/mpc8641hpcn/law.c | 35 ++-- board/freescale/mpc8641hpcn/mpc8641hpcn.c | 66 --- cpu/mpc86xx/Makefile |4 + cpu/mpc86xx/cpu_init.c|8 + cpu/mpc86xx/fdt.c | 21 ++ cpu/mpc86xx/mp.c | 68 +++ cpu/mpc86xx/mp.h |7 + cpu/mpc86xx/release.S | 169 + cpu/mpc86xx/start.S | 186 --- doc/README.mpc8641hpcn| 64 +-- include/configs/MPC8610HPCD.h | 40 +++- include/configs/MPC8641HPCN.h | 289 include/configs/sbc8641d.h| 16 ++ lib_ppc/board.c | 10 +- 17 files changed, 721 insertions(+), 278 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/9] mpc8641: Change 32-bit memory map
On Wed, 2008-11-05 at 14:55 -0600, Becky Bruce wrote: The memory map on the 8641hpcn is modified to look more like the 85xx boards; this is a step towards a more standardized layout going forward. As part of this change, we now relocate the flash. The regions for some of the mappings were far larger than they needed to be. I have reduced the mappings to match the actual sizes supported by the hardware. In addition I have removed the comments at the head of the BAT blocks in the config file, rather than updating them. These get horribly out of date, and it's a simple matter to look at the defines to see what they are set to since everything is right here in the same file. Signed-off-by: Becky Bruce [EMAIL PROTECTED] --- board/freescale/mpc8641hpcn/config.mk |2 +- board/freescale/mpc8641hpcn/law.c | 23 ++ cpu/mpc86xx/start.S |2 +- include/configs/MPC8641HPCN.h | 76 + 4 files changed, 54 insertions(+), 49 deletions(-) Does this affect any flash addresses mentioned in the README.mpc86xx too? jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/9] mpc8641: Change 32-bit memory map
On Thu, 2008-11-06 at 16:16 -0600, Scott Wood wrote: Becky Bruce wrote: We *do* need a comment in the release notes for this revision of u-boot that the map for 8641 has changed so it doesn't catch anyone by surprise. How about a runtime check in the board fdt code to print a warning if it finds an old device tree? Unfortunately, using new dts with old u-boot isn't as easy to detect. -Scott For the record, and admittedly not quite an answer to your issue at all, though I feel it would mitigate the pain dramatically, I have a version of the DTS file that uses my new expression language to completely abstract out the 32/36-bit differences and compile a DTB for either with the single flip of a -DUSE_36_BIT handed to the dtc command line. Even if no one cares. jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: change 86xx SMP boot method
On Mon, 2008-11-03 at 15:44 -0600, Becky Bruce wrote: We put the bootpg for the secondary cpus into memory and use BPTR to get to it. This is a step towards converting to the ePAPR boot methodology. Also, the code is written to deal properly with more than 4GB of RAM. Signed-off-by: Becky Bruce [EMAIL PROTECTED] Applied to u-boot-mpc86xx. Thanks, jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 86xx: Make dram_size a phys_size_t
On Fri, 2008-10-31 at 17:13 -0500, Becky Bruce wrote: It's currently a long and should be phys_size_t. Signed-off-by: Becky Bruce [EMAIL PROTECTED] Applied to u-boot-mpc86xx. Thanks, jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 8641HPCN: Config file cleanup
On Fri, 2008-10-31 at 17:13 -0500, Becky Bruce wrote: There are several items in the config file that were hardcoded but that should really be based on other config options, since the regions are contiguous and depend on being so. This cleans that up a bit. Also, add BR_PHYS_ADDR() macro to convert addresses into the proper format for BR registers. Signed-off-by: Becky Bruce [EMAIL PROTECTED] Applied to u-boot-mpc86xx. Thanks, jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc8641: Stop supporting non-PCI_PNP configs
On Fri, 2008-10-31 at 17:14 -0500, Becky Bruce wrote: We don't actually ever do this, remove the code so we can stop maintaining it. Signed-off-by: Becky Bruce [EMAIL PROTECTED] Applied to u-boot-mpc86xx. Thanks, jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc8641: Make PCI and RIO mutually exclusive, fix non-PCI build
On Fri, 2008-10-31 at 17:14 -0500, Becky Bruce wrote: You can't actually have both, and with some coming changes to change the memory map for the board and support 36-bit physical, we need the extra BAT that is being consumed by having both. I also make non-PCI configs build cleanly, for the sake of sanity. Signed-off-by: Becky Bruce [EMAIL PROTECTED] Applied to u-boot-mpc86xx. Thanks, jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] powerpc 86xx: Handle CCSR relocation earlier
On Sun, 2008-11-02 at 18:19 -0600, Becky Bruce wrote: Currently, the CCSR gets relocated while translation is enabled, meaning we need 2 BAT translations to get to both the old location and the new location. Also, the DEFAULT CCSR location has a dependency on the BAT that maps the FLASH region. Moving the relocation removes this unnecessary dependency. This makes it easier and more intutive to modify the board's memory map. Swap BATs 3 and 4 on 8610 so that all 86xx boards use the same BAT for CCSR space. Signed-off-by: Becky Bruce [EMAIL PROTECTED] Applied to u-boot-mpc86xx. Thanks, jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] lib_ppc: Move trap_init to occur earlier
On Fri, 2008-10-31 at 17:14 -0500, Becky Bruce wrote: Doing trap_init immediately once we're running from RAM means we're no longer dependent on the physical location of the flash on non-BookE platforms. Before trap_init, those platforms switch to real mode and go to 0xfff00100 on exception. After the switch, they go to 0x0100 This makes it easier to move the flash location. Signed-off-by: Becky Bruce [EMAIL PROTECTED] --- lib_ppc/board.c | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) Wolfgang, Will you pick this one up? Or would you like me to run it through u-boot-mpc86xx with the others? Thanks, jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 86xx: remove the unused definition
On Thu, 2008-10-23 at 21:19 +0800, Dave Liu wrote: Signed-off-by: Dave Liu [EMAIL PROTECTED] --- include/configs/MPC8610HPCD.h |9 - include/configs/MPC8641HPCN.h | 11 --- 2 files changed, 0 insertions(+), 20 deletions(-) Applied. Thanks, jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 74xx/7xx/86xx: Rename flush_data_cache to flush_dcache to match 85xx version
On Wed, 2008-10-15 at 11:23 +0200, Wolfgang Denk wrote: Dear Kumar Gala, In message [EMAIL PROTECTED] you wrote: Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- cpu/74xx_7xx/cache.S | 10 +- cpu/mpc86xx/cache.S | 10 +- 2 files changed, 10 insertions(+), 10 deletions(-) Applied to next branch. Jon, as this was for more than just 86xx I just went ahead. Hope that's OK with you. Sounds good! Thanks, jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-mpc86xx
The following changes since commit b1d0db1805c3395149777e507b6da53410abac4e:
Kumar Gala (1):
bootm: Added CONFIG_BOOTM_{LINUX, NETBSD, RTEMS}
are available in the git repository at:
git://www.denx.de/git/u-boot-mpc86xx.git master
Dave Liu (6):
86xx: Move the clear_tlbs before MMU turn on
86xx: remove the unused ddr_enable_ecc in the board file
86xx: remove the second DDR LAW setting for mpc8641hpcn
86xx: remove the unused code for 86xx family
86xx: remove the redundant r2 global data pointer save
86xx: remove the unused definition
board/freescale/mpc8610hpcd/mpc8610hpcd.c | 11 ---
board/freescale/mpc8641hpcn/law.c |3 ---
board/freescale/mpc8641hpcn/mpc8641hpcn.c | 11 ---
board/sbc8641d/sbc8641d.c | 11 ---
cpu/mpc86xx/start.S | 20
include/configs/MPC8610HPCD.h |9 -
include/configs/MPC8641HPCN.h | 11 ---
7 files changed, 4 insertions(+), 72 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/10] 86xx: Convert all fsl_pci_init users to new APIs
Converted MPC8610HCPD, MPC8641HPCN, and SBC8641D to use fsl_pci_setup_inbound_windows() and ft_fsl_pci_setup(). With these changes the board code is a bit smaller and we get dma-ranges set in the device tree for these boards. Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- ACK. jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MPC86xx unapplied patches
On Mon, 2008-10-13 at 13:58 +0200, Wolfgang Denk wrote: Dear Jon, In message [EMAIL PROTECTED] you wrote: 6185 08/19 Kumar Gala [U-Boot] [PATCH] 86xx: remove redudant code with lib_ppc/interrupts.c 6767 08/28 Nick Spence[U-Boot] [PATCH] mpc86xx: use r4 instead of r2 in lock_ram_in_cache a Sorry, got buried here. If these are still outstanding, please directly apply them. Understood, applied these two. Excellent! Thank you! Let me know if there are more. I don't think so. Thanks, jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] Make DDR interleaving mode work correctly
Andy Fleming wrote: If Kim and Jon approve, I'll pull these 6 patches into my 85xx-next branch. On Fri, Oct 3, 2008 at 11:36 AM, Haiying Wang [EMAIL PROTECTED] wrote: Fix some bugs: 1. Correctly set intlv_ctl in cs_config. 2. Correctly set sa, ea in cs_bnds when bank interleaving mode is enabled. 3. Set base_address and total memory for each ddr controller in memory controller interleaving mode. Signed-off-by: Haiying Wang [EMAIL PROTECTED] Sounds good by me. ACK. jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [Fwd: Re: [U-Boot-Users] FIT-image with fdt doesn't work]
Gah. List foo. Sorry. -- jdl Forwarded Message From: Jon Loeliger [EMAIL PROTECTED] To: Simon Pasch [EMAIL PROTECTED] Cc: u-boot-users [EMAIL PROTECTED] Subject: Re: [U-Boot-Users] FIT-image with fdt doesn't work Date: Tue, 30 Sep 2008 10:37:50 -0500 On Tue, 2008-09-30 at 14:06 +0200, Simon Pasch wrote: 3.) create a flat device tree blob (using dtc 1.2.0): dtc -b 0 -V 17 -R 4 -S 0x3000 -I dts -O dtb -f devicetree.dts target.dtb The -V 17 is the current default, so the option isn't needed. The -S 0x3000 may not be enough, and is really obsoleted but the -p pad-value option too. Try, oh, -p 0x1000 instead. If you have a large DTS or resulting DTB file, it might lead to problems like this: 7.) try to boot it: = bootm ## Booting kernel from FIT Image at 0070 ... Using '[EMAIL PROTECTED]' configuration Trying '[EMAIL PROTECTED]' kernel subimage Description: Vanilla Linux kernel Type: Kernel Image Compression: gzip compressed Data Start: 0x007000ec Data Size:4052683 Bytes = 3.9 MB Architecture: PowerPC OS: Linux Load Address: 0x Entry Point: 0x Hash algo:crc32 Hash value: d4c2683b Hash algo:sha1 Hash value: 0f3c591c4f201d8cc1020725da0639d0b04d065a Verifying Hash Integrity ... crc32+ sha1+ OK Uncompressing Kernel Image ... OK ## Flattened Device Tree from FIT Image at 0070 Using '[EMAIL PROTECTED]' configuration Trying '[EMAIL PROTECTED]' FDT blob subimage Description: Flattened Device Tree blob Type: Unknown Image Compression: Unknown Compression Data Start: 0x00add8e4 Data Size:12288 Bytes = 12 kB Hash algo:crc32 Hash value: e07e11d2 Hash algo:sha1 Hash value: 8ee8e8ce07508c534666f6d79fe89e46b8a7ae7a Verifying Hash Integrity ... crc32+ sha1+ OK ERROR: Not a FDT image - must RESET the board to recover. As you can see the image-type of the fdt changed from Flat Device Tree to Unknown Image after decompressing the kernel, but the hash integrity seems to be fine (?!) What am I doing wrong? What's missing? Do some length analysis and make sure you are not stomping on any images in memory too, especially after uncompressing. jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ppc4xx: Optimizations/Cleanups for IBM DDR2 Memory Controller
On Sat, 2008-08-30 at 11:22 +0200, Stefan Roese wrote: I used Evolution on Linux to send the patch using the instructions given in Documentation/email-clients in Linux kernel tree. I have problems using git send-email because we send emails using the Exchange server. OK, then this Evolution step seems to have introduced this problem. Too bad that even the instructions in the Linux Documention describe this correctly. Sorry, I can't help you here, I have no experience with Evolution. Perhaps somebody else can jump in here. Just make sure to select preformat instead of normal before you insert - text file on your patch. jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/24] FSL DDR: Remove duplicate setting of cs0_bnds register on 86xx.
Wolfgang Denk wrote: Dear Kumar Gala, In message [EMAIL PROTECTED] you wrote: Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- cpu/mpc86xx/ddr-8641.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) Applied. Jon, I hope it is OK that I pulled this in directly. Absolutely! No problem at all. And, Thank you! jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] RE: Some memory (DDR2 ECC Dual Rank) just doesn't work! Can anyone pointme to how to debug this hang?
Vince Asbridge wrote: Stephane, Thanks so much for your prompt reply. We will pursue your suggestions, and let the forum know what we find. We're at 1.3.0 uboot version. Vince -Original Message- From: Fillod Stephane [mailto:[EMAIL PROTECTED] Sent: Thursday, August 14, 2008 8:06 AM To: Vince Asbridge; linuxppc-embedded Cc: u-boot@lists.denx.de Subject: [PATCH] RE: Some memory (DDR2 ECC Dual Rank) just doesn't work! Can anyone pointme to how to debug this hang? Vince Asbridge wrote: We have an 8548 design, which implements a DDR2 on a SODIMM We have an issue with dual rank memory (specific part number Viking VR5DR287218EBSS1), which is a 1G ECC Registered SODIMM part, with two ranks. Our platform wires CS0 and CS1 to the SODIMM slot. At uBoot, all is well. Memory is discovered as ECC 533, 1G DDR2 64Bit 4 beat bursts, and mtest can read and write all 1G of the SODIMM. [...] Other DDR2s (identical except for vendor and # of ranks), work perfectly! Anyone got a clue what I could look at to try to figure this out? We've tried enable / disable ECC at uboot We've tried enable / disable Interleaving at uboot uboot always works (and can read/write entire DDR), Linux always hangs on boot! U-Boot is too gentle when testing SDRAM. Make sure the caches are enabled under U-Boot, and put on heavy stress with DMA, pipelined prefetch's, etc. This is what your CPU is enduring under Linux. Your question is definitely a question for the U-Boot mailing list. BTW, what is the version of U-Boot in use? U-Boot is still missing the following patch: MPC85xx BA bits not set for 3-bit bank address DIMM of CS1 The current implementation set the number of bank address bits (BA) in the processor for CS0 but not for CS1. Signed-off-by: Stephane Fillod [EMAIL PROTECTED] --- u-boot/cpu/mpc85xx/spd_sdram.c +++ u-boot/cpu/mpc85xx/spd_sdram.c @@ -365,6 +365,7 @@ ddr-cs1_config = ( 131 | (odt_rd_cfg 20) | (odt_wr_cfg 16) + | (ba_bits 14) | (spd.nrow_addr - 12) 8 | (spd.ncol_addr - 8) ); debug(DDR: cs1_bnds = 0x%08x\n, ddr-cs1_bnds); Otherwise, recompile with -DDEBUG and CFG_CMD_SDRAM, grab the Viking datasheet and a scope, and a full cup of coffee/tea much needed during cross-checking :-) That bug fix, along with many, many others, as well as some new support for multiple controllers and such are all present in the DDR re-write patch set that Kumar just posted. You may want to try that code too. It will be replacing the entire 85xx/86xx and eventually the 83xx line of memory controller initialization. It also contains some support for a pretty useful interactive DDR configuration setup mechanism too. jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Flatten device tree PPC linux
Fundu wrote: i'm using a the taishan board u-boot 1.2.0 and linux 2.4 Uh, OK. Those are both pretty darn old by now. does u-boot-1.2.0 pass a flatten device tree to the kernel ? Maybe. does this even matter ? Yes. also does linux-2.4 expect fdt ? Nope. You have to get to about 2.6.12 or 13 (ie, aboout 2 years ago) before it begins to matter for PowerPC boards. jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
