Support for Voipac X53-DMM-668 module and Voipac Baseboard

Signed-off-by Rostislav Lisovy <[email protected]>

drivers/net/fec_imx.c +5 -0

index 2f31352..6f883bf 100644
@@ -27,6 +27,8 @@
 #include <linux/clk.h>
 #include <linux/err.h>
 #include <of_net.h>
+#include <of_gpio.h>
+#include <gpio.h>
 
 #include <asm/mmu.h>
 

@@ -643,6 +645,9 @@ static int fec_probe(struct device_d *dev)
 	void *base;
 	int ret;
 	enum fec_type type;
+#ifdef CONFIG_OFDEVICE
+	int phy_reset;
+#endif
 
 	ret = dev_get_drvdata(dev, (unsigned long *)&type);
 	if (ret)

drivers/net/fec_imx.c +4 -0

+	udelay(10);
+	gpio_set_value(phy_reset, 1);
+#endif
+
 	/* Reset chip. */
 	writel(FEC_ECNTRL_RESET, fec->regs + FEC_ECNTRL);
 	while(readl(fec->regs + FEC_ECNTRL) & 1) {

Signature · 7 lines

1.7.10.4


_______________________________________________
barebox mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox

Quoted 10 lines · Rostislav Lisovy

Signed-off-by Rostislav Lisovy <[email protected]>

drivers/net/fec_imx.c +0 -0

index 2f31352..6f883bf 100644
@@ -671,6 +676,22 @@ static int fec_probe(struct device_d *dev)
 
 	fec->regs = dev_request_mem_region(dev, 0);
 

drivers/net/fec_imx.c static int fec_probe(struct device_d *dev) · line 679

Quoted 1 line

drivers/net/fec_imx.c +1 -0

+#ifdef CONFIG_OFDEVICE

use if (IS_ENABLED(CONFIG_OFDEVICE))

so we can improve the code coverage

drivers/net/fec_imx.c static int fec_probe(struct device_d *dev) · line 680

Quoted 1 line

drivers/net/fec_imx.c +1 -0

+	phy_reset = of_get_named_gpio(dev->device_node, "phy-reset-gpios", 0);

drivers/net/fec_imx.c static int fec_probe(struct device_d *dev) · line 690

Quoted 10 lines

drivers/net/fec_imx.c +10 -0

+	if (!gpio_is_valid(phy_reset))
+		goto err_free;
+
+	ret = gpio_request(phy_reset, "phy-reset");
+	if (ret) {
+		pr_err("Can not request gpio %d (phy-reset): %d\n", phy_reset, ret);
+		goto err_free;
+	}
+
+	gpio_direction_output(phy_reset, 0);

you need to check the return too

drivers/net/fec_imx.c static int fec_probe(struct device_d *dev) · line 692

Quoted 2 lines

drivers/net/fec_imx.c +2 -0

+	udelay(10);
+	gpio_set_value(phy_reset, 1);

drivers/net/fec_imx.c static int fec_probe(struct device_d *dev) · line 697

Quoted 4 lines

drivers/net/fec_imx.c +1 -0

+
 	/* Reset chip. */
 	writel(FEC_ECNTRL_RESET, fec->regs + FEC_ECNTRL);
 	while(readl(fec->regs + FEC_ECNTRL) & 1) {

Hello Jean-Christophe and Rosta,

Quoted 15 lines · On Tuesday 05 of November 2013 17:15:16 Jean-Christophe PLAGNIOL-VILLARD wrote:

drivers/net/fec_imx.c static int fec_probe(struct device_d *dev) · line 679

Quoted 11 lines · Rostislav Lisovy

Signed-off-by Rostislav Lisovy <[email protected]>

drivers/net/fec_imx.c +1 -0

index 2f31352..6f883bf 100644
@@ -671,6 +676,22 @@ static int fec_probe(struct device_d *dev)
 
 	fec->regs = dev_request_mem_region(dev, 0);
 
+#ifdef CONFIG_OFDEVICE

use if (IS_ENABLED(CONFIG_OFDEVICE))

Quoted 3 lines

so we can improve the code coverage

drivers/net/fec_imx.c static int fec_probe(struct device_d *dev) · line 680

Quoted 1 line

drivers/net/fec_imx.c +1 -0

+	phy_reset = of_get_named_gpio(dev->device_node, "phy-reset-gpios", 0);

I have question if the missing definition of reset pin should/must lead to whole ethernet interface removal/initialization abort.

Hi Rostislav,

Quoted 2 lines · Rostislav Lisovy

Signed-off-by Rostislav Lisovy <[email protected]>

arch/arm/boards/freescale-mx53-vmx53/env/config

Quoted 5 lines

arch/arm/boards/freescale-mx53-vmx53/env/config new file +0 -0

new file mode 100644
index 0000000..3d90172

Why not use defenv-2?

arch/arm/boards/freescale-mx53-vmx53/flash_header.c

Quoted 6 lines

arch/arm/boards/freescale-mx53-vmx53/flash_header.c new file +0 -0

new file mode 100644
index 0000000..a6864a6

I'm currently generating the flash images for new boards using the imx-image tool and also generate multi board images. This is a very flexible, though maybe hard to understand mechanism. Is this the reason you haven't used it or were you not aware of it?
I would rather see this board taking part in this new mechanism. Are you willing to port this over? Otherwise I could try and convert this patch, but I would depend on you testing the result.

Hello Sascha;

Quoted 5 lines · Sascha Hauer

Hi Rostislav,

Quoted 2 lines · Rostislav Lisovy

Signed-off-by Rostislav Lisovy <[email protected]>

Quoted 7 lines

arch/arm/boards/freescale-mx53-vmx53/env/config

Quoted 5 lines

arch/arm/boards/freescale-mx53-vmx53/env/config new file +0 -0

new file mode 100644
index 0000000..3d90172

Why not use defenv-2?

Ok; I will use it;

Quoted 14 lines

arch/arm/boards/freescale-mx53-vmx53/flash_header.c

Quoted 6 lines

arch/arm/boards/freescale-mx53-vmx53/flash_header.c new file +0 -0

new file mode 100644
index 0000000..a6864a6

I'm currently generating the flash images for new boards using the imx-image tool and also generate multi board images. This is a very flexible, though maybe hard to understand mechanism. Is this the reason you haven't used it or were you not aware of it?
I would rather see this board taking part in this new mechanism. Are you willing to port this over? Otherwise I could try and convert this patch, but I would depend on you testing the result.

I was investigating how the imx53-loco support is done, however I was not sure if the 'multiboard' is the preferred way.
I found your patchset
http://www.spinics.net/lists/u-boot-v2/msg15296.html shortly describing the functionality of the multiboard barebox -- I still do not understand the concept. The final binary has to hold just one particular 'flash_header', thus be able to boot just on one particular board.

I do
understand the flexibility of the devicetree, however something like the SDRAM configuration can not be chosen 'on the fly' by the PBL?

Quoted 33 lines · Rostislav Lisovy

Hello Sascha;

Quoted 5 lines · Sascha Hauer

Hi Rostislav,

Quoted 2 lines · Rostislav Lisovy

Signed-off-by Rostislav Lisovy <[email protected]>

Quoted 7 lines

arch/arm/boards/freescale-mx53-vmx53/env/config

Quoted 5 lines

arch/arm/boards/freescale-mx53-vmx53/env/config new file +0 -0

new file mode 100644
index 0000000..3d90172

Why not use defenv-2?

Ok; I will use it;

Quoted 14 lines

arch/arm/boards/freescale-mx53-vmx53/flash_header.c

Quoted 6 lines

arch/arm/boards/freescale-mx53-vmx53/flash_header.c new file +0 -0

new file mode 100644
index 0000000..a6864a6

I'm currently generating the flash images for new boards using the imx-image tool and also generate multi board images. This is a very flexible, though maybe hard to understand mechanism. Is this the reason you haven't used it or were you not aware of it?
I would rather see this board taking part in this new mechanism. Are you willing to port this over? Otherwise I could try and convert this patch, but I would depend on you testing the result.

Quoted 7 lines

I was investigating how the imx53-loco support is done, however I was not sure if the 'multiboard' is the preferred way.
I found your patchset
http://www.spinics.net/lists/u-boot-v2/msg15296.html shortly describing the functionality of the multiboard barebox -- I still do not understand the concept. The final binary has to hold just one particular 'flash_header', thus be able to boot just on one particular board.

The multi image support (I think multi image is more appropriate than multi board) doesn't mean that the same image is being run on multiple boards, it instead means that the same binary is used to generate multiple images. Each of these images is for a particular board. The advantage over the traditional mechanism is that you can have a single config for multiple boards. Of course this could be used to have a single config for completely different SoCs/Boards. This gives you a better compile coverage with less compilation. A more real life scenario might be that you have two boards which differ only in the amount of SDRAM. Instead of maintaining two configs for it you could use a single config and generate two images from it.

Quoted 3 lines

I do
understand the flexibility of the devicetree, however something like the SDRAM configuration can not be chosen 'on the fly' by the PBL?

The basic trick with the multi image support is that we compile multiple entry points (ENTRY_FUNCTION()). Which one is used for a particular image is later specified with the -e option to ld. So each image has one entry function specified with ENTRY_FUNCTION(). What you then do in this entry function is up to you. If your boards offer some possibility to detect the SDRAM setup then you can use it to dynamically detect and configure SDRAM. Then you would be able to use a single binary image on multiple boards with different SDRAM configuration.

On i.MX with the DCD header format the DCD is normally used to setup SDRAM. In this case it's not possible to have the same image for multiple boards. However, you could remove the SDRAM setup from DCD data and configure the flash header to load to the i.MX internal SRAM. then when in SRAM you could determine your board and setup the SDRAM from early code. This way a single image for multiple boards would be possible on i.MX aswell.

With multi image support we shift away from "compiling for a single board". Instead a board is simply an additional option. If this option makes a new image necessary, then this image will be generated along with images for other boards.
My vision is that we should not have defconfigs for particular boards. Instead we should have defconfigs which enable a certain feature set, for example:

- arm_full_defconfig: All features and all boards enabled, huge binary nobody uses in projects, but is useful for compile testing and development
- imx_defconfig: All i.MX boards enabled and all features necessary for i.MX. More practical in real life.
- noninteractive_defconfig: Do not prompt users, just boot.
- $VENDOR_defconfig: supports all boards from a vendor
- $PROJECT_defconfig: supports all boards for a particular project which uses different boards or variants of boards.

I hope this makes it a bit more clearer.

Sascha