mail archive of the barebox mailing list
 help / color / mirror / Atom feed
* [PATCH upstream 1/4] state: use packet attribute for on storage structs
From: Stefan Lengfeld @ 2016-11-02  7:54 UTC (permalink / raw)
  To: barebox

These structs are used for on-storage data layouts. They should be not
affected by different integer precisions and alignment optimizations of
32bit or 64bit machines. Using the architecture independent integer data
types, like uint32_t, achieves the former, using the packet attribute
the later.

Signed-off-by: Stefan Lengfeld <s.lengfeld@phytec.de>
---
 common/state/backend_bucket_circular.c | 2 +-
 common/state/backend_bucket_direct.c   | 2 +-
 common/state/backend_format_raw.c      | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/common/state/backend_bucket_circular.c b/common/state/backend_bucket_circular.c
index 72e165e..d8504e0 100644
--- a/common/state/backend_bucket_circular.c
+++ b/common/state/backend_bucket_circular.c
@@ -47,7 +47,7 @@ struct state_backend_storage_bucket_circular {
 	struct device_d *dev;
 };
 
-struct state_backend_storage_bucket_circular_meta {
+struct __attribute__((__packed__)) state_backend_storage_bucket_circular_meta {
 	uint32_t magic;
 	uint32_t written_length;
 };
diff --git a/common/state/backend_bucket_direct.c b/common/state/backend_bucket_direct.c
index 08892f0..5225433 100644
--- a/common/state/backend_bucket_direct.c
+++ b/common/state/backend_bucket_direct.c
@@ -32,7 +32,7 @@ struct state_backend_storage_bucket_direct {
 	struct device_d *dev;
 };
 
-struct state_backend_storage_bucket_direct_meta {
+struct __attribute__((__packed__)) state_backend_storage_bucket_direct_meta {
 	uint32_t magic;
 	uint32_t written_length;
 };
diff --git a/common/state/backend_format_raw.c b/common/state/backend_format_raw.c
index 4209424..e028ea6 100644
--- a/common/state/backend_format_raw.c
+++ b/common/state/backend_format_raw.c
@@ -37,7 +37,7 @@ struct state_backend_format_raw {
 	struct device_d *dev;
 };
 
-struct backend_raw_header {
+struct __attribute__((__packed__)) backend_raw_header {
 	uint32_t magic;
 	uint16_t reserved;
 	uint16_t data_len;
-- 
1.9.1


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply related

* [PATCH upstream 3/4] state: fix state is not saved when string variable is changed
From: Stefan Lengfeld @ 2016-11-02  7:54 UTC (permalink / raw)
  To: barebox
In-Reply-To: <1478073270-3527-1-git-send-email-s.lengfeld@phytec.de>

The dirty flag was not set properly.

Signed-off-by: Stefan Lengfeld <s.lengfeld@phytec.de>
---
 common/state/state_variables.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/state/state_variables.c b/common/state/state_variables.c
index 1e37856..fd072a0 100644
--- a/common/state/state_variables.c
+++ b/common/state/state_variables.c
@@ -383,7 +383,7 @@ static int state_string_set(struct param_d *p, void *priv)
 	if (ret)
 		return ret;
 
-	return state_set_dirty(p, sv->state);
+	return state_set_dirty(p, sv);
 }
 
 static int state_string_get(struct param_d *p, void *priv)
-- 
1.9.1


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply related

* [PATCH upstream 2/4] state: fix indentation
From: Stefan Lengfeld @ 2016-11-02  7:54 UTC (permalink / raw)
  To: barebox
In-Reply-To: <1478073270-3527-1-git-send-email-s.lengfeld@phytec.de>

Signed-off-by: Stefan Lengfeld <s.lengfeld@phytec.de>
---
 common/state/state_variables.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/common/state/state_variables.c b/common/state/state_variables.c
index efc2456..1e37856 100644
--- a/common/state/state_variables.c
+++ b/common/state/state_variables.c
@@ -441,9 +441,9 @@ static struct variable_type types[] = {
 	{
 		.type = STATE_TYPE_U8,
 		.type_name = "uint8",
-		 .export = state_uint32_export,
-		 .import = state_uint32_import,
-		 .create = state_uint8_create,
+		.export = state_uint32_export,
+		.import = state_uint32_import,
+		.create = state_uint8_create,
 	}, {
 		.type = STATE_TYPE_U32,
 		.type_name = "uint32",
-- 
1.9.1


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply related

* [PATCH upstream 4/4] docs: state: make string variable type clearer
From: Stefan Lengfeld @ 2016-11-02  7:54 UTC (permalink / raw)
  To: barebox
In-Reply-To: <1478073270-3527-1-git-send-email-s.lengfeld@phytec.de>

Only fixed length strings are supported. Make the wording clearer.

Signed-off-by: Stefan Lengfeld <s.lengfeld@phytec.de>
---
 Documentation/devicetree/bindings/barebox/barebox,state.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/barebox/barebox,state.rst b/Documentation/devicetree/bindings/barebox/barebox,state.rst
index e39245f..438cc43 100644
--- a/Documentation/devicetree/bindings/barebox/barebox,state.rst
+++ b/Documentation/devicetree/bindings/barebox/barebox,state.rst
@@ -51,8 +51,8 @@ variable. The node name may end with ``@<ADDRESS>``, but the suffix is
 stripped from the variable name.
 
 State variables have a type. Currenty supported types are: ``uint8``,
-``uint32``, ``enum32``, ``mac`` address or ``string``. Variable length
-strings are not planned.
+``uint32``, ``enum32``, ``mac`` address or ``string`` (fixed length string).
+Variable length strings are not planned.
 
 Required properties:
 
-- 
1.9.1


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply related

* [PATCH 1/2] fixup! watchdog: add designware driver
From: Steffen Trumtrar @ 2016-11-01  9:52 UTC (permalink / raw)
  To: barebox; +Cc: Steffen Trumtrar

Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
---
 drivers/watchdog/dw_wdt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/watchdog/dw_wdt.c b/drivers/watchdog/dw_wdt.c
index fa2752896c2f..8fd8c81e6c38 100644
--- a/drivers/watchdog/dw_wdt.c
+++ b/drivers/watchdog/dw_wdt.c
@@ -151,7 +151,7 @@ static int dw_wdt_drv_probe(struct device_d *dev)
 	if (ret)
 		return ret;
 
-	dw_wdt->rst = reset_control_get(dev, "dw-wdt");
+	dw_wdt->rst = reset_control_get(dev, NULL);
 	if (IS_ERR(dw_wdt->rst))
 		dev_warn(dev, "No reset lines. Will not be able to stop once started.\n");
 
-- 
2.10.1


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply related

* [PATCH 2/2] fixup! ARM: socfpga: dtsi: add dw-wdt reset lines
From: Steffen Trumtrar @ 2016-11-01  9:52 UTC (permalink / raw)
  To: barebox; +Cc: Steffen Trumtrar
In-Reply-To: <20161101095227.2087-1-s.trumtrar@pengutronix.de>

Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
---
 arch/arm/dts/socfpga.dtsi | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/dts/socfpga.dtsi b/arch/arm/dts/socfpga.dtsi
index 66d7f21dc6a3..5b141c23914c 100644
--- a/arch/arm/dts/socfpga.dtsi
+++ b/arch/arm/dts/socfpga.dtsi
@@ -52,10 +52,8 @@
 
 &watchdog0 {
 	resets = <&rst L4WD0_RESET>;
-	reset-names = "dw-wdt";
 };
 
 &watchdog1 {
 	resets = <&rst L4WD1_RESET>;
-	reset-names = "dw-wdt";
 };
-- 
2.10.1


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply related

* [PATCH 1/5] PCI: add some useful debug output
From: Lucas Stach @ 2016-11-01  8:58 UTC (permalink / raw)
  To: barebox

This makes diagnosing problems in address space allocation
much easier.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
---
 drivers/pci/pci.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 191561da0368..46f5d5f7de36 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -179,6 +179,7 @@ static void setup_device(struct pci_dev *dev, int max_bar)
 				pr_debug("BAR does not fit within bus IO res\n");
 				return;
 			}
+			pr_debug("pbar%d: allocated at 0x%08x\n", bar, last_io);
 			pci_write_config_dword(dev, PCI_BASE_ADDRESS_0 + bar * 4, last_io);
 			dev->resource[bar].flags = IORESOURCE_IO;
 			last_addr = last_io;
@@ -197,6 +198,7 @@ static void setup_device(struct pci_dev *dev, int max_bar)
 				pr_debug("BAR does not fit within bus p-mem res\n");
 				return;
 			}
+			pr_debug("pbar%d: allocated at 0x%08x\n", bar, last_mem_pref);
 			pci_write_config_dword(dev, PCI_BASE_ADDRESS_0 + bar * 4, last_mem_pref);
 			dev->resource[bar].flags = IORESOURCE_MEM |
 			                           IORESOURCE_PREFETCH;
@@ -215,6 +217,7 @@ static void setup_device(struct pci_dev *dev, int max_bar)
 				pr_debug("BAR does not fit within bus np-mem res\n");
 				return;
 			}
+			pr_debug("pbar%d: allocated at 0x%08x\n", bar, last_mem);
 			pci_write_config_dword(dev, PCI_BASE_ADDRESS_0 + bar * 4, last_mem);
 			dev->resource[bar].flags = IORESOURCE_MEM;
 			last_addr = last_mem;
@@ -286,18 +289,21 @@ static void postscan_setup_bridge(struct pci_dev *dev)
 
 	if (last_mem) {
 		last_mem = ALIGN(last_mem, SZ_1M);
+		pr_debug("bridge NP limit at 0x%08x\n", last_mem);
 		pci_write_config_word(dev, PCI_MEMORY_LIMIT,
 				      ((last_mem - 1) & 0xfff00000) >> 16);
 	}
 
 	if (last_mem_pref) {
 		last_mem_pref = ALIGN(last_mem_pref, SZ_1M);
+		pr_debug("bridge P limit at 0x%08x\n", last_mem_pref);
 		pci_write_config_word(dev, PCI_PREF_MEMORY_LIMIT,
 				      ((last_mem_pref - 1) & 0xfff00000) >> 16);
 	}
 
 	if (last_io) {
 		last_io = ALIGN(last_io, SZ_4K);
+		pr_debug("bridge IO limit at 0x%08x\n", last_io);
 		pci_write_config_byte(dev, PCI_IO_LIMIT,
 				((last_io - 1) & 0x0000f000) >> 8);
 		pci_write_config_word(dev, PCI_IO_LIMIT_UPPER16,
-- 
2.10.1


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply related

* [PATCH 5/5] PCI: split PCI hierarchy enumeration and config from device registration
From: Lucas Stach @ 2016-11-01  8:58 UTC (permalink / raw)
  To: barebox
In-Reply-To: <20161101085855.953-1-l.stach@pengutronix.de>

This gets rid of some of the special cases in the bus scanning function
by splitting hierarchy enumeration and configuration and the actual
device registration into 2 passes.

This ensures that the PCI hierarchy below a root port is completely
set up before any device driver is probed.

This simplifies the code and makes it less error prone, while moving
the PCI address space layout closer to the one used by Linux.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
---
 drivers/pci/pci.c | 31 ++++++++++++++++---------------
 1 file changed, 16 insertions(+), 15 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 12aafccde578..b2570eb15181 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -28,6 +28,20 @@ static struct pci_bus *pci_alloc_bus(void)
 	return b;
 }
 
+static void pci_bus_register_devices(struct pci_bus *bus)
+{
+	struct pci_dev *dev;
+	struct pci_bus *child_bus;
+
+	/* activate all devices on this bus */
+	list_for_each_entry(dev, &bus->devices, bus_list)
+		pci_register_device(dev);
+
+	/* walk down the hierarchy */
+	list_for_each_entry(child_bus, &bus->children, node)
+		pci_bus_register_devices(child_bus);
+}
+
 void register_pci_controller(struct pci_controller *hose)
 {
 	struct pci_bus *bus;
@@ -64,6 +78,7 @@ void register_pci_controller(struct pci_controller *hose)
 		last_io = 0;
 
 	pci_scan_bus(bus);
+	pci_bus_register_devices(bus);
 
 	list_add_tail(&bus->node, &pci_root_buses);
 
@@ -384,16 +399,8 @@ unsigned int pci_scan_bus(struct pci_bus *bus)
 			dev->rom_address = (l == 0xffffffff) ? 0 : l;
 
 			setup_device(dev, 6);
-			/*
-			 * If this device is on the root bus, there is no bridge
-			 * to configure, so we can activate it right away.
-			 */
-			if (!bus->parent_bus)
-				pci_register_device(dev);
 			break;
 		case PCI_HEADER_TYPE_BRIDGE:
-			setup_device(dev, 2);
-
 			child_bus = pci_alloc_bus();
 			/* inherit parent properties */
 			child_bus->host = bus->host;
@@ -412,18 +419,12 @@ unsigned int pci_scan_bus(struct pci_bus *bus)
 			list_add_tail(&child_bus->node, &bus->children);
 			dev->subordinate = child_bus;
 
-			/* activate bridge device */
-			pci_register_device(dev);
-
 			/* scan pci hierarchy behind bridge */
 			prescan_setup_bridge(dev);
 			pci_scan_bus(child_bus);
 			postscan_setup_bridge(dev);
 
-			/* finally active all devices behind the bridge */
-			list_for_each_entry(dev, &child_bus->devices, bus_list)
-				if (!dev->subordinate)
-					pci_register_device(dev);
+			setup_device(dev, 2);
 			break;
 		default:
 		bad:
-- 
2.10.1


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply related

* [PATCH 3/5] PCI: align address range before scanning bridge
From: Lucas Stach @ 2016-11-01  8:58 UTC (permalink / raw)
  To: barebox
In-Reply-To: <20161101085855.953-1-l.stach@pengutronix.de>

Otherwise we may end up with a too low base address and push
requests for the upstream bus onto the downstream side.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
---
 drivers/pci/pci.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index eb3ce0f3211a..19cda1f145bc 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -252,6 +252,7 @@ static void prescan_setup_bridge(struct pci_dev *dev)
 
 	if (last_mem) {
 		/* Set up memory and I/O filter limits, assume 32-bit I/O space */
+		last_mem = ALIGN(last_mem, SZ_1M);
 		pci_write_config_word(dev, PCI_MEMORY_BASE,
 				      (last_mem & 0xfff00000) >> 16);
 		cmdstat |= PCI_COMMAND_MEMORY;
@@ -259,6 +260,7 @@ static void prescan_setup_bridge(struct pci_dev *dev)
 
 	if (last_mem_pref) {
 		/* Set up memory and I/O filter limits, assume 32-bit I/O space */
+		last_mem_pref = ALIGN(last_mem_pref, SZ_1M);
 		pci_write_config_word(dev, PCI_PREF_MEMORY_BASE,
 				      (last_mem_pref & 0xfff00000) >> 16);
 		cmdstat |= PCI_COMMAND_MEMORY;
@@ -270,6 +272,7 @@ static void prescan_setup_bridge(struct pci_dev *dev)
 	}
 
 	if (last_io) {
+		last_io = ALIGN(last_io, SZ_4K);
 		pci_write_config_byte(dev, PCI_IO_BASE,
 				      (last_io & 0x0000f000) >> 8);
 		pci_write_config_word(dev, PCI_IO_BASE_UPPER16,
-- 
2.10.1


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply related

* [PATCH 4/5] PCI: align BAR address to BAR size
From: Lucas Stach @ 2016-11-01  8:58 UTC (permalink / raw)
  To: barebox
In-Reply-To: <20161101085855.953-1-l.stach@pengutronix.de>

PCI BARs require their address to be at least aligned to their
size, otherwise address decoding will fail as the base address
gets rounded down.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
---
 drivers/pci/pci.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 19cda1f145bc..12aafccde578 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -174,11 +174,12 @@ static void setup_device(struct pci_dev *dev, int max_bar)
 				continue;
 			}
 			pr_debug("pbar%d: mask=%08x io %d bytes\n", bar, mask, size);
-			if (last_io + size >
+			if (ALIGN(last_io, size) + size >
 			    dev->bus->resource[PCI_BUS_RESOURCE_IO]->end) {
 				pr_debug("BAR does not fit within bus IO res\n");
 				return;
 			}
+			last_io = ALIGN(last_io, size);
 			pr_debug("pbar%d: allocated at 0x%08x\n", bar, last_io);
 			pci_write_config_dword(dev, PCI_BASE_ADDRESS_0 + bar * 4, last_io);
 			dev->resource[bar].flags = IORESOURCE_IO;
@@ -193,11 +194,12 @@ static void setup_device(struct pci_dev *dev, int max_bar)
 			}
 			pr_debug("pbar%d: mask=%08x P memory %d bytes\n",
 			    bar, mask, size);
-			if (last_mem_pref + size >
+			if (ALIGN(last_mem_pref, size) + size >
 			    dev->bus->resource[PCI_BUS_RESOURCE_MEM_PREF]->end) {
 				pr_debug("BAR does not fit within bus p-mem res\n");
 				return;
 			}
+			last_mem_pref = ALIGN(last_mem_pref, size);
 			pr_debug("pbar%d: allocated at 0x%08x\n", bar, last_mem_pref);
 			pci_write_config_dword(dev, PCI_BASE_ADDRESS_0 + bar * 4, last_mem_pref);
 			dev->resource[bar].flags = IORESOURCE_MEM |
@@ -212,11 +214,12 @@ static void setup_device(struct pci_dev *dev, int max_bar)
 			}
 			pr_debug("pbar%d: mask=%08x NP memory %d bytes\n",
 			    bar, mask, size);
-			if (last_mem + size >
+			if (ALIGN(last_mem, size) + size >
 			    dev->bus->resource[PCI_BUS_RESOURCE_MEM]->end) {
 				pr_debug("BAR does not fit within bus np-mem res\n");
 				return;
 			}
+			last_mem = ALIGN(last_mem, size);
 			pr_debug("pbar%d: allocated at 0x%08x\n", bar, last_mem);
 			pci_write_config_dword(dev, PCI_BASE_ADDRESS_0 + bar * 4, last_mem);
 			dev->resource[bar].flags = IORESOURCE_MEM;
-- 
2.10.1


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply related

* [PATCH 2/5] PCI: only check specific flag for 64bit BAR
From: Lucas Stach @ 2016-11-01  8:58 UTC (permalink / raw)
  To: barebox
In-Reply-To: <20161101085855.953-1-l.stach@pengutronix.de>

The memory type may include other flags, so just check for
the 64bit allocation flag to see if the BAR is a 64bit one.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
---
 drivers/pci/pci.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 46f5d5f7de36..eb3ce0f3211a 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -227,8 +227,7 @@ static void setup_device(struct pci_dev *dev, int max_bar)
 		dev->resource[bar].start = last_addr;
 		dev->resource[bar].end = last_addr + size - 1;
 
-		if ((mask & PCI_BASE_ADDRESS_MEM_TYPE_MASK) ==
-		    PCI_BASE_ADDRESS_MEM_TYPE_64) {
+		if ((mask & PCI_BASE_ADDRESS_MEM_TYPE_64)) {
 			dev->resource[bar].flags |= IORESOURCE_MEM_64;
 			pci_write_config_dword(dev,
 			       PCI_BASE_ADDRESS_1 + bar * 4, 0);
-- 
2.10.1


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply related

* [PATCH] net: e1000: set edev parent pointer
From: Lucas Stach @ 2016-11-01  8:57 UTC (permalink / raw)
  To: barebox

This way the ethernet device will show up at the correct point
in the device hierarchy.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
---
 drivers/net/e1000/main.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/e1000/main.c b/drivers/net/e1000/main.c
index 77bcd179a824..6f9dddaf232a 100644
--- a/drivers/net/e1000/main.c
+++ b/drivers/net/e1000/main.c
@@ -3600,6 +3600,7 @@ static int e1000_probe(struct pci_dev *pdev, const struct pci_device_id *id)
 	e1000_get_ethaddr(edev, edev->ethaddr);
 
 	/* Set up the function pointers and register the device */
+	edev->parent = &pdev->dev;
 	edev->init = e1000_init;
 	edev->recv = e1000_poll;
 	edev->send = e1000_transmit;
-- 
2.10.1


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply related

* [PATCH] ARM: riotboard: fix barebox partition size
From: Lucas Stach @ 2016-10-31 21:20 UTC (permalink / raw)
  To: barebox

This was missed when updating all the partition sizes. The
environment partition has been moved to the correct location,
but the barebox partition size remained unchanged.

Signed-off-by: Lucas Stach <dev@lynxeye.de>
---
 arch/arm/dts/imx6s-riotboard.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/dts/imx6s-riotboard.dts b/arch/arm/dts/imx6s-riotboard.dts
index 7193f28..5758872 100644
--- a/arch/arm/dts/imx6s-riotboard.dts
+++ b/arch/arm/dts/imx6s-riotboard.dts
@@ -29,7 +29,7 @@
 
 	partition@0 {
 		label = "barebox";
-		reg = <0x0 0x80000>;
+		reg = <0x0 0xe0000>;
 	};
 
 	environment_usdhc4: partition@e0000 {
-- 
2.7.4


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply related

* [PATCH v2] net: e1000: fix i210 register remapping
From: Lucas Stach @ 2016-10-31 16:58 UTC (permalink / raw)
  To: barebox

Don't mask out the remapping flag before checking the register offset,
otherwise none of the switch statements will ever match.

Fixes: ff6a64d42ffc (e1000: Consolidate register offset fixups)
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
---
v2: don't break it the other way around
---
 drivers/net/e1000/regio.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/net/e1000/regio.c b/drivers/net/e1000/regio.c
index b2e9d7b6a7df..1610d5851f05 100644
--- a/drivers/net/e1000/regio.c
+++ b/drivers/net/e1000/regio.c
@@ -5,8 +5,6 @@
 static uint32_t e1000_true_offset(struct e1000_hw *hw, uint32_t reg)
 {
 	if (reg & E1000_MIGHT_BE_REMAPPED) {
-		reg &= ~E1000_MIGHT_BE_REMAPPED;
-
 		if (hw->mac_type == e1000_igb) {
 			switch (reg) {
 			case E1000_EEWR:
@@ -19,7 +17,8 @@ static uint32_t e1000_true_offset(struct e1000_hw *hw, uint32_t reg)
 				reg = E1000_I210_EEMNGCTL;
 				break;
 			}
-		};
+		}
+		reg &= ~E1000_MIGHT_BE_REMAPPED;
 	}
 
 	return reg;
-- 
2.10.1


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply related

* [PATCH] net: e1000: fix i210 register remapping
From: Lucas Stach @ 2016-10-31 16:55 UTC (permalink / raw)
  To: barebox

Don't mask out the remapping flag before checking the register offset,
otherwise none of the switch statements will ever match.

Fixes: ff6a64d42ffc (e1000: Consolidate register offset fixups)
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
---
 drivers/net/e1000/regio.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/e1000/regio.c b/drivers/net/e1000/regio.c
index b2e9d7b6a7df..17d08da3b8a2 100644
--- a/drivers/net/e1000/regio.c
+++ b/drivers/net/e1000/regio.c
@@ -5,8 +5,6 @@
 static uint32_t e1000_true_offset(struct e1000_hw *hw, uint32_t reg)
 {
 	if (reg & E1000_MIGHT_BE_REMAPPED) {
-		reg &= ~E1000_MIGHT_BE_REMAPPED;
-
 		if (hw->mac_type == e1000_igb) {
 			switch (reg) {
 			case E1000_EEWR:
@@ -19,7 +17,9 @@ static uint32_t e1000_true_offset(struct e1000_hw *hw, uint32_t reg)
 				reg = E1000_I210_EEMNGCTL;
 				break;
 			}
-		};
+		} else {
+			reg &= ~E1000_MIGHT_BE_REMAPPED;
+		}
 	}
 
 	return reg;
-- 
2.10.1


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply related

* Re: [PATCH v3 3/3] ARM: socfpga: dtsi: add dw-wdt reset lines
From: Sascha Hauer @ 2016-10-28  7:20 UTC (permalink / raw)
  To: Steffen Trumtrar; +Cc: barebox@lists.infradead.org, Trent Piepho
In-Reply-To: <20161027065856.tn4tdwtev5aexxyg@pengutronix.de>

On Thu, Oct 27, 2016 at 08:58:56AM +0200, Steffen Trumtrar wrote:
> On Wed, Oct 26, 2016 at 08:12:07PM +0000, Trent Piepho wrote:
> > On Mon, 2016-10-17 at 09:50 +0200, Steffen Trumtrar wrote:
> > > Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
> > > ---
> > >  arch/arm/dts/socfpga.dtsi | 10 ++++++++++
> > >  1 file changed, 10 insertions(+)
> > > 
> > > diff --git a/arch/arm/dts/socfpga.dtsi b/arch/arm/dts/socfpga.dtsi
> > > index d16758fdab46..66d7f21dc6a3 100644
> > > --- a/arch/arm/dts/socfpga.dtsi
> > > +++ b/arch/arm/dts/socfpga.dtsi
> > > @@ -49,3 +49,13 @@
> > >  &f2s_sdram_ref_clk {
> > >  	clock-frequency = <0>;
> > >  };
> > > +
> > > +&watchdog0 {
> > > +	resets = <&rst L4WD0_RESET>;
> > > +	reset-names = "dw-wdt";
> > 
> > This is the official binding?  The reset-names property is supposed to
> > be the name of the reset from the perspective of the device being
> > described, e.g. the watchdog.  Not the name from the perspective of the
> > reset controller.  Rather than "dw-wdt", the name should something like
> > "reset", which clearly doesn't add much information, which is why the
> > reset-names property is supposed to be optional.
> > 
> 
> There is no "official" binding. I wasn't really sure about this property
> and just tried to derive from other bindings. I don't care for this one,
> so I'm okay with removing it.

Could you send a fixup patch for this?

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply

* Re: [PATCH v2] ARM: dts: am33xx.dtsi: Add spi aliases
From: Sascha Hauer @ 2016-10-28  6:53 UTC (permalink / raw)
  To: Teresa Remmet; +Cc: barebox
In-Reply-To: <1477298184-32928-1-git-send-email-t.remmet@phytec.de>

On Mon, Oct 24, 2016 at 10:36:24AM +0200, Teresa Remmet wrote:
> We need to add the spi aliases to set the bus number correct in
> the driver.
> 
> Delete the spi1 alias again in the am33xx-strip.dtsi for MLO as
> the node is deleted there also.
> 
> Signed-off-by: Teresa Remmet <t.remmet@phytec.de>

Applied, thanks

Sascha

> ---
> Changes in v2:
> - Removed the first patch completly
> - Delete now spi1 alias in strip file
> - Updated commit message
> 
>  arch/arm/dts/am33xx-strip.dtsi | 1 +
>  arch/arm/dts/am33xx.dtsi       | 2 ++
>  2 files changed, 3 insertions(+)
> 
> diff --git a/arch/arm/dts/am33xx-strip.dtsi b/arch/arm/dts/am33xx-strip.dtsi
> index 2943fd1..83d23a8 100644
> --- a/arch/arm/dts/am33xx-strip.dtsi
> +++ b/arch/arm/dts/am33xx-strip.dtsi
> @@ -14,6 +14,7 @@
>  		/delete-property/ mmc2;
>  		/delete-property/ d_can0;
>  		/delete-property/ d_can1;
> +		/delete-property/ spi1;
>  	};
>  };
>  
> diff --git a/arch/arm/dts/am33xx.dtsi b/arch/arm/dts/am33xx.dtsi
> index 7ba0a0b..f1ee7b3 100644
> --- a/arch/arm/dts/am33xx.dtsi
> +++ b/arch/arm/dts/am33xx.dtsi
> @@ -18,5 +18,7 @@
>  		mmc0 = &mmc1;
>  		mmc1 = &mmc2;
>  		mmc2 = &mmc3;
> +		spi0 = &spi0;
> +		spi1 = &spi1;
>  	};
>  };
> -- 
> 1.9.1
> 
> 
> _______________________________________________
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox
> 

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply

* Re: Read kernel from static UBI volume
From: Sascha Hauer @ 2016-10-27  7:39 UTC (permalink / raw)
  To: Guillermo Rodriguez Garcia; +Cc: barebox
In-Reply-To: <CABDcava4zzJBLtku87=bmp5PdYy0TMejDgTpsoP8Z2zB5vQV-Q@mail.gmail.com>

On Thu, Oct 27, 2016 at 09:34:20AM +0200, Guillermo Rodriguez Garcia wrote:
> 2016-10-27 9:31 GMT+02:00 Sascha Hauer <s.hauer@pengutronix.de>:
> > On Thu, Oct 27, 2016 at 09:10:02AM +0200, Guillermo Rodriguez Garcia wrote:
> >> Hello all,
> >>
> >> I know Barebox can load files from UBIFS. However, is there support
> >> from booting a kernel directly from a static UBI volume?.
> >
> > bootm /dev/nand0.ubi.whatever should do.
> 
> That easy?
> 
> This is one of the reasons why I like barebox so much better than u-boot..
> 
> I assume this will just read the whole volume (as opposed to checking
> the zImage size and so on). Correct?

The bootm code only reads the actual image size.

> 
> Also will this do the UBI static volume CRC check?

You read a UBI volume using the UBI code which is more or less identical
to the Kernel, so I'd assume the code does whatever is necessary,
including the crc check.
I'm speaking a bit nebulous because I never used static UBI volumes
myself.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply

* Re: Read kernel from static UBI volume
From: Guillermo Rodriguez Garcia @ 2016-10-27  7:34 UTC (permalink / raw)
  To: Sascha Hauer; +Cc: barebox
In-Reply-To: <20161027073157.u6jmv6ux3xs4x46i@pengutronix.de>

2016-10-27 9:31 GMT+02:00 Sascha Hauer <s.hauer@pengutronix.de>:
> On Thu, Oct 27, 2016 at 09:10:02AM +0200, Guillermo Rodriguez Garcia wrote:
>> Hello all,
>>
>> I know Barebox can load files from UBIFS. However, is there support
>> from booting a kernel directly from a static UBI volume?.
>
> bootm /dev/nand0.ubi.whatever should do.

That easy?

This is one of the reasons why I like barebox so much better than u-boot..

I assume this will just read the whole volume (as opposed to checking
the zImage size and so on). Correct?

Also will this do the UBI static volume CRC check?

Guillermo Rodriguez Garcia
guille.rodriguez@gmail.com

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply

* Re: Read kernel from static UBI volume
From: Sascha Hauer @ 2016-10-27  7:31 UTC (permalink / raw)
  To: Guillermo Rodriguez Garcia; +Cc: barebox
In-Reply-To: <CABDcavZ08eW8scP2zi_5hUp7J8ex-xj17-n7SRx_5YNC3q-8eQ@mail.gmail.com>

On Thu, Oct 27, 2016 at 09:10:02AM +0200, Guillermo Rodriguez Garcia wrote:
> Hello all,
> 
> I know Barebox can load files from UBIFS. However, is there support
> from booting a kernel directly from a static UBI volume?.

bootm /dev/nand0.ubi.whatever should do.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply

* Re: Read kernel from static UBI volume
From: Guillermo Rodriguez Garcia @ 2016-10-27  7:29 UTC (permalink / raw)
  To: Uwe Kleine-König; +Cc: barebox
In-Reply-To: <20161027071810.g7web5cjygjqnus5@pengutronix.de>

Hello,

2016-10-27 9:18 GMT+02:00 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
> On Thu, Oct 27, 2016 at 09:10:02AM +0200, Guillermo Rodriguez Garcia wrote:
>> I know Barebox can load files from UBIFS. However, is there support
>> from booting a kernel directly from a static UBI volume?.
>
> Are you using ptxdist? If so, enable BLSPEC which results in the kernel
> being installed (together with a dtb if configured) in the rootfs and
> barebox can boot this easily.

Yes, but this is not what I want: I want to be able to read a kernel
from a static UBI volume, not from the rootfs. Is this possible ?

Guillermo Rodriguez Garcia
guille.rodriguez@gmail.com

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply

* Re: Read kernel from static UBI volume
From: Uwe Kleine-König @ 2016-10-27  7:18 UTC (permalink / raw)
  To: Guillermo Rodriguez Garcia; +Cc: barebox
In-Reply-To: <CABDcavZ08eW8scP2zi_5hUp7J8ex-xj17-n7SRx_5YNC3q-8eQ@mail.gmail.com>

On Thu, Oct 27, 2016 at 09:10:02AM +0200, Guillermo Rodriguez Garcia wrote:
> I know Barebox can load files from UBIFS. However, is there support
> from booting a kernel directly from a static UBI volume?.

Are you using ptxdist? If so, enable BLSPEC which results in the kernel
being installed (together with a dtb if configured) in the rootfs and
barebox can boot this easily.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply

* Read kernel from static UBI volume
From: Guillermo Rodriguez Garcia @ 2016-10-27  7:10 UTC (permalink / raw)
  To: barebox

Hello all,

I know Barebox can load files from UBIFS. However, is there support
from booting a kernel directly from a static UBI volume?.

Thanks,

Guillermo Rodriguez Garcia
guille.rodriguez@gmail.com

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply

* Re: [PATCH v3 3/3] ARM: socfpga: dtsi: add dw-wdt reset lines
From: Steffen Trumtrar @ 2016-10-27  6:58 UTC (permalink / raw)
  To: Trent Piepho; +Cc: barebox@lists.infradead.org
In-Reply-To: <1477512729.14501.14.camel@rtred1test09.kymeta.local>

On Wed, Oct 26, 2016 at 08:12:07PM +0000, Trent Piepho wrote:
> On Mon, 2016-10-17 at 09:50 +0200, Steffen Trumtrar wrote:
> > Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
> > ---
> >  arch/arm/dts/socfpga.dtsi | 10 ++++++++++
> >  1 file changed, 10 insertions(+)
> > 
> > diff --git a/arch/arm/dts/socfpga.dtsi b/arch/arm/dts/socfpga.dtsi
> > index d16758fdab46..66d7f21dc6a3 100644
> > --- a/arch/arm/dts/socfpga.dtsi
> > +++ b/arch/arm/dts/socfpga.dtsi
> > @@ -49,3 +49,13 @@
> >  &f2s_sdram_ref_clk {
> >  	clock-frequency = <0>;
> >  };
> > +
> > +&watchdog0 {
> > +	resets = <&rst L4WD0_RESET>;
> > +	reset-names = "dw-wdt";
> 
> This is the official binding?  The reset-names property is supposed to
> be the name of the reset from the perspective of the device being
> described, e.g. the watchdog.  Not the name from the perspective of the
> reset controller.  Rather than "dw-wdt", the name should something like
> "reset", which clearly doesn't add much information, which is why the
> reset-names property is supposed to be optional.
> 

There is no "official" binding. I wasn't really sure about this property
and just tried to derive from other bindings. I don't care for this one,
so I'm okay with removing it.

Thanks,
Steffen

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply

* Re: [PATCH v3 3/3] ARM: socfpga: dtsi: add dw-wdt reset lines
From: Trent Piepho @ 2016-10-26 20:12 UTC (permalink / raw)
  To: Steffen Trumtrar; +Cc: barebox@lists.infradead.org
In-Reply-To: <20161017075052.30802-3-s.trumtrar@pengutronix.de>

On Mon, 2016-10-17 at 09:50 +0200, Steffen Trumtrar wrote:
> Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
> ---
>  arch/arm/dts/socfpga.dtsi | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/arch/arm/dts/socfpga.dtsi b/arch/arm/dts/socfpga.dtsi
> index d16758fdab46..66d7f21dc6a3 100644
> --- a/arch/arm/dts/socfpga.dtsi
> +++ b/arch/arm/dts/socfpga.dtsi
> @@ -49,3 +49,13 @@
>  &f2s_sdram_ref_clk {
>  	clock-frequency = <0>;
>  };
> +
> +&watchdog0 {
> +	resets = <&rst L4WD0_RESET>;
> +	reset-names = "dw-wdt";

This is the official binding?  The reset-names property is supposed to
be the name of the reset from the perspective of the device being
described, e.g. the watchdog.  Not the name from the perspective of the
reset controller.  Rather than "dw-wdt", the name should something like
"reset", which clearly doesn't add much information, which is why the
reset-names property is supposed to be optional.

> +};
> +
> +&watchdog1 {
> +	resets = <&rst L4WD1_RESET>;
> +	reset-names = "dw-wdt";
> +};

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox