Re: [U-Boot] Memory test post relocation
Hello DaveKucharczyk, On Fri, 14 Nov 2014 15:22:43 -0700 (MST), DaveKucharczyk david.kucharc...@gmail.com wrote: If I set CONFIG_SYS_TEXT_BASE to start of RAM then I get no boot. Is there some kind of vector setup at the beginning of RAM? Possibly. Why not use 0x7780 as mx53loco uses now? It's not like the value matters much, as whatever it is, U-Boot will relocate itself as high as possible. Have a good weekend everybody. Cheers, Dave Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Memory test post relocation
Hello DaveKucharczyk, On Fri, 14 Nov 2014 13:20:09 -0700 (MST), DaveKucharczyk david.kucharc...@gmail.com wrote: Old u-boot was u-boot-2009.08. I guess the main source of frustration the last 3 weeks could be attributed to my lack of experience with u-boot and the fact that we were working with an old Freescale version of u-boot. Not to mention 5 years worth of changes between the versions. Most of the init functions seem to have moved in the boot sequence between u-boot-2009.08 and u-boot-2014.07. For instance, board_init was one of the first functions called before relocation to RAM, but now it called after relocation. When porting from a 5-years old version, you should think less in terms of function names and more in terms of functionality. Names can change, but setting chip selects or base address registers remains the same. It's a matter of porting the functionality. I have our board almost fully working with mainline u-boot-2014.07, but now I'm just trying to understand a few how's and why's before continuing. In u-boot-2009.08 we set CONFIG_SKIP_RELOCATE_UBOOT. When I run with DEBUG on I confirm that no relocation messages are reported, but this is due to the fact that u-boot-2009.08 did not have debug messages pertaining to relocation (that I can tell). I'm not sure how to confirm that relocation didn't actually happen and where it actually runs from on the mx53, but I can confirm that memory tests ran all the way to the end of RAM without issue. We did run the test from within dram_init though, which would be before relocation. Too bad that doesn't work in u-boot-2014.07. Wolfgang and myself at least have already toched on the subject: testing /all/ of the DDR is simply *not* possible, so whether your tests can go all the way to the end of the DDR (or start from as low as the DDR start) is not really relevant, since in any case, they will necessarily miss some other part of the DDR address space. If you *need* to test all of the DDR, then you *must* do it from code running in non-DDR RAM, eiher IRAM or locked cache; and since these are usually small, you probably have to do it from SPL, no U-Boot (which makes sense, since you should not load U-Boot into DDR before having tested it). Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Query on CONFIG_SYS_THUMB_BUILD
Hello Simon, On Fri, 14 Nov 2014 18:56:07 -0700, Simon Glass s...@chromium.org wrote: I believe you've built crt0.S for ARM, not Thumb. Yes, but I suspect that is a function of the build system. I checked the rest of U-Boot and most of it (including SPL) is Thumb 2. I suppose we could use Thumb 2 for crt0.S if all the instructions are supported. Ok. Just in case, I'll run a check on whether crt0.S can be assembled for Thumb and still wrk as expected. :) Do you have a list of source files which still build for ARM under CONFIG_SYS_THUMB_BUILD? I' would prefer all of the code to be thumb for consistence, except probably... exception :) entry points -- and even these should be able to run in full Thumb 2. Regards, Simon Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 0/5] add i.MX6 thermal sensor driver
Hello nitin.g...@freescale.com, On Fri, 14 Nov 2014 14:13:02 -0600, nitin.g...@freescale.com nitin.g...@freescale.com wrote: From: Nitin Garg nitin.g...@freescale.com This patch set adds i.MX6 thermal sensor driver and enables it for mx6sabre boards. Also adds various anadig bit definitions as required for upcoming drivers. Changes in v6: -Aligned imx thermal driver macro defines with kernel Changes in v5: -Don't modify the copyright of cpu.c and crm_regs.h file Changes in v4: -Added imx6 thermal sensor as a driver -Renamed the config define to be more meaningful -Move the clock code to clock.c -Reusing ocotp driver for reading fuse -Fix check for calibration fuse not programmed -Aligned the slope computation with kernel -Added Anadig register defines as seperate commit Changes in v3: -adds the mx6 thermal driver support -adds the mx6 thermal support to mx6sabresd board. Changes in v2: -run checkpatch and fix reported issues Nitin Garg (4): mx6: clock: Add api to enable pll3 mx6: thermal: Add i.MX6 CPU thermal sensor support mx6: thermal: Check cpu temperature via thermal sensor mx6: thermal: Enable thermal sensor for mx6 sabre boards. So, is it 5 as the cover letter says, or 4 as the patches say? If actually 4 and only the cover letter is wrong, then there's no need to repost. If actually 5, then please repost them all, renumbered accordingly. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Memory test post relocation
On Sat, 15 Nov 2014 13:26:49 +0100, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Wolfgang and myself at least have already toched on the subject: s/toched/touched/ Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] iMX6 DDR Calibration Value
Hi John, On 11/14/2014 03:19 AM, John Tobias wrote: Hi Fabio / Stefano, May be you could help me to get some answer regarding with calibrations value for DDR. I have a 4 custom boards based on iMX6SL (2) Micron DDR and (2) Samsung DDR. The boards has exact DDR footprints (like density, bus width and so on). In fact the uboot that I am using works on both DDR chips. I re-ran the DDR tools twice for each boards, entered the same information. The tools returned different calibration values for each boards but, the two results for each boards were the same. e.g: board1 Read DQS Gating calibration MPDGCTRL0 PHY0 (0x021b083c) = 0x412C0130 MPDGCTRL1 PHY0 (0x021b0840) = 0x01140118 Read calibration MPRDDLCTL PHY0 (0x021b0848) = 0x3E404244 Write calibration MPWRDLCTL PHY0 (0x021b0850) = 0x383C3E36 board2: Read DQS Gating calibration MPDGCTRL0 PHY0 (0x021b083c) = 0x412C0130 MPDGCTRL1 PHY0 (0x021b0840) = 0x01140118 Read calibration MPRDDLCTL PHY0 (0x021b0848) = 0x3E3E4244 Write calibration MPWRDLCTL PHY0 (0x021b0850) = 0x383C3E36 Is there any procedures or rules of thumb you follow dealing with the calibration settings?. As far as I know, the calibration values are actually settings for the delay lines, used to align data and clock signals. I can assure you that each separate imx6 chip, DDR chip, and each board are absolutely uniqie in their parameters, because there are manufacturing inaccuracies that can't be avoided. Also the ICs parameters change with temperature, and the PCB parameters (dielectric permittivity) changes with frequency. Just think about this - even 2 subsequent runs of DDR stress tester will return close, but not exactly the same calibration values. Now, on the positive side, these inaccuracies are not that big and usually it's quite safe to just perform the calibration with the FSL DDR stress tool on one of the boards and use these fixed values for all the boards. This is very easy to be done whem DDR ICs are soldered on the PCB, and somewhat harder to do when using SO-DIMMS (but I have a customer board already that's running this way without issues). I can also confirm that I've personally seen such approach even in automotive products. What's important is to make sure there are no big changes in the manufacturing process and components revisions, and that the boards (especially DDR area) are clean from flux/finger fat. If I remember correctly, the MMDC module has a mechanism to perform periodic fine recalibration that handles the slight fluctuations in the component parameters, while the software is running. If you are concerned with the temperature stability of your DDR calibration, you can always do a thermal chamber tests in the full temperature range of your product, just to be sure. Hope this helps. Kind regards, Nikolay PS: If you need more scientific approach to justify this to someone else, you can test a representative amount of your product boards, extract all calibration values, do a chart with normal distribution of the calibration values and select the values with highest probability. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] spi: Add designware master SPI DM driver used on SoCFPGA
On 14.11.2014 21:16, Marek Vasut wrote: On Wednesday, November 12, 2014 at 06:51:42 PM, Pavel Machek wrote: Hi! You tripped my spell-checker, sorry. This patch adds the driver for the Designware master SPI controller. This IP core is integrated on the Altera SoCFPGA. This implementation is a driver model (DM) implementation. So multiple SPI drivers can be used. Thats necessary, since SoCFPGA also integrates the Cadence QSPI controller used to connect the SPI NOR flashes. Without DM, using multiple SPI driver is not possible. drivers. This driver is very loosly based on the Linux driver. Most of the loosely? driver is removed. Only the polling loop for the transfer is really used from this driver. As we don't support interrupts and DMA right now. , as + * Very loosly based on the Linux driver version which is: loosely. (And citing filename here might be useful.) I fixed the text and I placed this whole driver patchset to u-boot-socfpga:topic/drivers/spi-20141114 Can you please fix the code so I can replace that one patch ? Or just send me one which I can squash into this patch, either way works. Yes. I'll take a look at it tomorrow or on Monday. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] arm: socfpga: Add Designware (DW) SPI support to config header
On 14.11.2014 21:18, Marek Vasut wrote: On Wednesday, November 12, 2014 at 06:53:54 PM, Pavel Machek wrote: On Fri 2014-11-07 13:50:34, Stefan Roese wrote: Enable support for the DW master SPI controller in the config header for the SoCFPGA. This controller can only be enabled, if DT support is enabled. Signed-off-by: Stefan Roese s...@denx.de Cc: Chin Liang See cl...@altera.com Cc: Dinh Nguyen dingu...@altera.com Cc: Vince Bridgers vbrid...@altera.com Cc: Marek Vasut ma...@denx.de Cc: Pavel Machek pa...@denx.de --- include/configs/socfpga_common.h | 12 1 file changed, 12 insertions(+) diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h index 9fc4212..830b956 100644 --- a/include/configs/socfpga_common.h +++ b/include/configs/socfpga_common.h @@ -191,6 +191,18 @@ unsigned int cm_get_qspi_controller_clk_hz(void); #define CONFIG_CMD_SF #endif +#ifdef CONFIG_OF_CONTROL /* DW SPI is controlled via DT */ +#define CONFIG_CMD_DM +#define CONFIG_DM +#define CONFIG_DM_SPI +#define CONFIG_DESIGNWARE_SPI +#ifndef __ASSEMBLY__ +unsigned int cm_get_spi_controller_clk_hz(void); +#define CONFIG_DW_SPI_REF_CLK cm_get_spi_controller_clk_hz() Putting prototypes into configuration file is ugly. Hiding function call into macro so that it looks like constant is evil. Is there better solution? The SPI driver should call this function directly. Or is there a reason why such a macro is used ? Historically. I'll check it again and will implement it differently in the next version. Tomorrow or on Monday. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] spi: Add designware master SPI DM driver used on SoCFPGA
On Saturday, November 15, 2014 at 02:33:27 PM, Stefan Roese wrote: On 14.11.2014 21:16, Marek Vasut wrote: On Wednesday, November 12, 2014 at 06:51:42 PM, Pavel Machek wrote: Hi! You tripped my spell-checker, sorry. This patch adds the driver for the Designware master SPI controller. This IP core is integrated on the Altera SoCFPGA. This implementation is a driver model (DM) implementation. So multiple SPI drivers can be used. Thats necessary, since SoCFPGA also integrates the Cadence QSPI controller used to connect the SPI NOR flashes. Without DM, using multiple SPI driver is not possible. drivers. This driver is very loosly based on the Linux driver. Most of the loosely? driver is removed. Only the polling loop for the transfer is really used from this driver. As we don't support interrupts and DMA right now. , as + * Very loosly based on the Linux driver version which is: loosely. (And citing filename here might be useful.) I fixed the text and I placed this whole driver patchset to u-boot-socfpga:topic/drivers/spi-20141114 Can you please fix the code so I can replace that one patch ? Or just send me one which I can squash into this patch, either way works. Yes. I'll take a look at it tomorrow or on Monday. Thank you ! Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] arm: socfpga: Add Designware (DW) SPI support to config header
On Saturday, November 15, 2014 at 02:35:03 PM, Stefan Roese wrote: On 14.11.2014 21:18, Marek Vasut wrote: On Wednesday, November 12, 2014 at 06:53:54 PM, Pavel Machek wrote: On Fri 2014-11-07 13:50:34, Stefan Roese wrote: Enable support for the DW master SPI controller in the config header for the SoCFPGA. This controller can only be enabled, if DT support is enabled. Signed-off-by: Stefan Roese s...@denx.de Cc: Chin Liang See cl...@altera.com Cc: Dinh Nguyen dingu...@altera.com Cc: Vince Bridgers vbrid...@altera.com Cc: Marek Vasut ma...@denx.de Cc: Pavel Machek pa...@denx.de --- include/configs/socfpga_common.h | 12 1 file changed, 12 insertions(+) diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h index 9fc4212..830b956 100644 --- a/include/configs/socfpga_common.h +++ b/include/configs/socfpga_common.h @@ -191,6 +191,18 @@ unsigned int cm_get_qspi_controller_clk_hz(void); #define CONFIG_CMD_SF #endif +#ifdef CONFIG_OF_CONTROL /* DW SPI is controlled via DT */ +#define CONFIG_CMD_DM +#define CONFIG_DM +#define CONFIG_DM_SPI +#define CONFIG_DESIGNWARE_SPI +#ifndef __ASSEMBLY__ +unsigned int cm_get_spi_controller_clk_hz(void); +#define CONFIG_DW_SPI_REF_CLKcm_get_spi_controller_clk_hz() Putting prototypes into configuration file is ugly. Hiding function call into macro so that it looks like constant is evil. Is there better solution? The SPI driver should call this function directly. Or is there a reason why such a macro is used ? Historically. I'll check it again and will implement it differently in the next version. Tomorrow or on Monday. Roger. Thank you! Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] sunxi: video: Add cfb console driver for sunxi
Hi, On 11/14/2014 09:24 PM, Anatolij Gustschin wrote: On Fri, 14 Nov 2014 21:17:39 +0100 Anatolij Gustschin ag...@denx.de wrote: ... this patch looks good, only a few minor comments below. I forgot to mention that with these comments addressed, you can add Thanks for the review! I'll go and address your comments in my local tree. Acked-by: Anatolij Gustschin ag...@denx.de And then add your acked-by. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] sunxi: video: Add simplefb support
Hi, On 11/14/2014 11:22 PM, Anatolij Gustschin wrote: On Fri, 14 Nov 2014 17:54:47 +0100 Hans de Goede hdego...@redhat.com wrote: ... diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index 532fdb7..d7d8571 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -204,6 +204,9 @@ */ #define CONFIG_SUNXI_FB_SIZE (8 20) +/* Do we want to initialize a simple FB? */ +#define CONFIG_VIDEO_DT_SIMPLEFB + #define CONFIG_VIDEO_SUNXI #define CONFIG_CFB_CONSOLE @@ -219,6 +222,11 @@ #define CONFIG_SYS_MEM_TOP_HIDE ((CONFIG_SUNXI_FB_SIZE + 0xFFF) ~0xFFF) +/* To be able to hook simplefb into dt */ +#ifdef CONFIG_VIDEO_DT_SIMPLEFB +#define CONFIG_OF_BOARD_SETUP +#endif defining CONFIG_OF_BOARD_SETUP should be independent of defining CONFIG_VIDEO or CONFIG_VIDEO_DT_SIMPLEFB. DT fixup by board setup code is often done i.e. for auto-detected memory size, adjusting different node properties or adding/deleting whole nodes. If someone defines CONFIG_OF_BOARD_SETUP for these purposes and also defines CONFIG_VIDEO_DT_SIMPLEFB, the already defined warnings will appear. This can be left as is for now, but should be addressed in the long term. Currently the only thing we need CONFIG_OF_BOARD_SETUP for on sunxi is CONFIG_VIDEO_DT_SIMPLEFB, so for now this makes sense, but your 100% right that long term we probably want to do this differently. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] wandboard: Fix error handling in board_mmc_init()
From: Fabio Estevam fabio.este...@freescale.com
When an invalid USDHC port is passed we should return -EINVAL instead of 0.
Also, return the error immediately on fsl_esdhc_initialize() failure.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
board/wandboard/wandboard.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/board/wandboard/wandboard.c b/board/wandboard/wandboard.c
index 3c8b7a5..1075c65 100644
--- a/board/wandboard/wandboard.c
+++ b/board/wandboard/wandboard.c
@@ -144,7 +144,7 @@ int board_mmc_getcd(struct mmc *mmc)
int board_mmc_init(bd_t *bis)
{
- s32 status = 0;
+ int ret;
u32 index = 0;
/*
@@ -173,13 +173,15 @@ int board_mmc_init(bd_t *bis)
printf(Warning: you configured more USDHC controllers
(%d) then supported by the board (%d)\n,
index + 1, CONFIG_SYS_FSL_USDHC_NUM);
- return status;
+ return -EINVAL;
}
- status |= fsl_esdhc_initialize(bis, usdhc_cfg[index]);
+ ret = fsl_esdhc_initialize(bis, usdhc_cfg[index]);
+ if (ret)
+ return ret;
}
- return status;
+ return 0;
}
static int mx6_rgmii_rework(struct phy_device *phydev)
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] mx53loco: Fix error handling in board_mmc_init()
From: Fabio Estevam fabio.este...@freescale.com When an invalid USDHC port is passed we should return -EINVAL instead of 0. Also, return the error immediately on fsl_esdhc_initialize() failure. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- board/freescale/mx53loco/mx53loco.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/board/freescale/mx53loco/mx53loco.c b/board/freescale/mx53loco/mx53loco.c index 7569ded..efcf4b3 100644 --- a/board/freescale/mx53loco/mx53loco.c +++ b/board/freescale/mx53loco/mx53loco.c @@ -186,7 +186,7 @@ int board_mmc_init(bd_t *bis) }; u32 index; - s32 status = 0; + int ret; esdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC_CLK); esdhc_cfg[1].sdhc_clk = mxc_get_clock(MXC_ESDHC3_CLK); @@ -205,12 +205,14 @@ int board_mmc_init(bd_t *bis) printf(Warning: you configured more ESDHC controller (%d) as supported by the board(2)\n, CONFIG_SYS_FSL_ESDHC_NUM); - return status; + return -EINVAL; } - status |= fsl_esdhc_initialize(bis, esdhc_cfg[index]); + ret = fsl_esdhc_initialize(bis, esdhc_cfg[index]); + if (ret) + return ret; } - return status; + return 0; } #endif -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mx6sabresd: State that only mx6q is supported in SPL
From: Fabio Estevam fabio.este...@freescale.com
Make clear that current SPL code only supports the mx6q variant.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
board/freescale/mx6sabresd/mx6sabresd.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/board/freescale/mx6sabresd/mx6sabresd.c
b/board/freescale/mx6sabresd/mx6sabresd.c
index 343c3b6..d5cd37d 100644
--- a/board/freescale/mx6sabresd/mx6sabresd.c
+++ b/board/freescale/mx6sabresd/mx6sabresd.c
@@ -754,10 +754,8 @@ static void gpr_init(void)
}
/*
- * This section require the differentiation
- * between iMX6 Sabre Families.
- * But for now, it will configure only for
- * SabreSD.
+ * This section requires the differentiation between iMX6 Sabre boards, but
+ * for now, it will configure only for the mx6q variant.
*/
static void spl_dram_init(void)
{
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm: socfpga: set skew settings for ethernet phy
On Fri 2014-11-14 21:02:48, Marek Vasut wrote: On Friday, November 14, 2014 at 11:23:27 AM, Pavel Machek wrote: On Thu 2014-11-13 11:23:41, dingu...@opensource.altera.com wrote: From: Dinh Nguyen dingu...@opensource.altera.com Set the PHY skew settings for the ethernet phy on the SOCFPGA Cyclone5 hardware. Is it to need similar settings for all ksz9021 phys? Should this go to drivers/ as I suggested with a patch? This is board specific, but with the driver model, this should be moved into the PHY driver and the values should be passed via platform data or DT. I will apply this now, since it fixes real issue. Hmm, could you apply the patch I posted, instead? It has configuration in socfpga_config.h -- platform data. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] spl: MMC U-Boot image load from raw partition
Hello Paul, On Thu, 13 Nov 2014 23:16:09 +0100, Paul Kocialkowski cont...@paulk.fr wrote: Le jeudi 13 novembre 2014 à 12:16 +0100, Albert ARIBAUD a écrit : Hello Tom, On Mon, 10 Nov 2014 13:46:09 -0500, Tom Rini tr...@ti.com wrote: On Sat, Nov 08, 2014 at 11:19:23PM +0100, Albert ARIBAUD wrote: Hello Paul, On Sat, 8 Nov 2014 23:14:54 +0100, Paul Kocialkowski cont...@paulk.fr wrote: This is a first attempt at adding support for U-Boot image load from raw partitions. It does not support OS boot as I cannot test it on my current setup. This is going to be useful for the Optimus Black port (please do not consider this as dead code because no board is using it right now, there will be one soon)! Well... Why don't you just post these two patches a little later, as part of the upcoming series which will add support for the Optimus Black? So to me the dead code thing is starting to get a lot more ambiguous since with Kconfig we'll need need every single possible choice enabled in some defconfig, just some way to turn it on, on a possibly relevant board. In this case, any OMAP3+ board would be a fine place to try this out, IFF it's done as a Kconfig choice. Not sure I'm understanding you right, but it seems to me we're in sync: as long as the code is enabled somewhere on some target, it is not dead code. I'm precisely asking that the code here be submitted along with the target that uses it. Or did I miss something? Well I think it makes sense to not call this dead code as long as it *can be* enabled and used on another supported board (for that matter, any OMAP3+ board will indeed do). If no board is calling this code right now, that is because none needs it. If none needs it, then it has no reason to be added. The day some board needs this code, the patch to add this code can be submitted along with the patch that calls this code. This is very different from e.g. the regulator code that I submitted, which is only relevant for devices with that particular piece of hardware (so far, none supported by U-Boot). So it makes sense to submit that regulator patch only along with support for a board that uses it. I don't see the difference. Paul Kocialkowski, Replicant developer Replicant is a fully free Android distribution Website: http://www.replicant.us/ Blog: http://blog.replicant.us/ Wiki/tracker/forums: http://redmine.replicant.us/ Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm: socfpga: set skew settings for ethernet phy
On Saturday, November 15, 2014 at 08:54:06 PM, Pavel Machek wrote: On Fri 2014-11-14 21:02:48, Marek Vasut wrote: On Friday, November 14, 2014 at 11:23:27 AM, Pavel Machek wrote: On Thu 2014-11-13 11:23:41, dingu...@opensource.altera.com wrote: From: Dinh Nguyen dingu...@opensource.altera.com Set the PHY skew settings for the ethernet phy on the SOCFPGA Cyclone5 hardware. Is it to need similar settings for all ksz9021 phys? Should this go to drivers/ as I suggested with a patch? This is board specific, but with the driver model, this should be moved into the PHY driver and the values should be passed via platform data or DT. I will apply this now, since it fixes real issue. Hmm, could you apply the patch I posted, instead? It has configuration in socfpga_config.h -- platform data. Hi! The patch you provided (if we're referring to the same patch, Message-ID: 20141113120956.GB30779@amd) breaks every board which uses the Micrel PHY, doesn't it ? The problem for all other boards would be the new CONFIG_* options which are added into the Micrel driver by that patch. Furthermore, the patch doesn't even apply, it was decided that the patch was an RFC, wasn't it ? Please correct me if I'm wrong. The way forward here would be for you to prepare a patch for the Micrel PHY driver, submit that one (make sure to CC Joe, the network custodian) and in the next step clean up the writes into PHY configuration from both the SoCFPGA CV and from Nitrogen 6x support (I recall I saw the same thing done for that board). Oh, and btw., the new CONFIG_* options should be documented somewhere, so please keep that in mind. Otherwise, the amount of various CONFIG_* options become an unmanagable mess. Thanks! Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Query on CONFIG_SYS_THUMB_BUILD
Hi Albert, On 15 November 2014 05:30, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hello Simon, On Fri, 14 Nov 2014 18:56:07 -0700, Simon Glass s...@chromium.org wrote: I believe you've built crt0.S for ARM, not Thumb. Yes, but I suspect that is a function of the build system. I checked the rest of U-Boot and most of it (including SPL) is Thumb 2. I suppose we could use Thumb 2 for crt0.S if all the instructions are supported. Ok. Just in case, I'll run a check on whether crt0.S can be assembled for Thumb and still wrk as expected. :) Do you have a list of source files which still build for ARM under CONFIG_SYS_THUMB_BUILD? I' would prefer all of the code to be thumb for consistence, except probably... exception :) entry points -- and even these should be able to run in full Thumb 2. No I don't have a list, but it might be all assembler files. I don't see why cro0.S would be special. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm: socfpga: set skew settings for ethernet phy
On Sat 2014-11-15 22:29:00, Marek Vasut wrote: On Saturday, November 15, 2014 at 08:54:06 PM, Pavel Machek wrote: On Fri 2014-11-14 21:02:48, Marek Vasut wrote: On Friday, November 14, 2014 at 11:23:27 AM, Pavel Machek wrote: On Thu 2014-11-13 11:23:41, dingu...@opensource.altera.com wrote: From: Dinh Nguyen dingu...@opensource.altera.com Set the PHY skew settings for the ethernet phy on the SOCFPGA Cyclone5 hardware. Is it to need similar settings for all ksz9021 phys? Should this go to drivers/ as I suggested with a patch? This is board specific, but with the driver model, this should be moved into the PHY driver and the values should be passed via platform data or DT. I will apply this now, since it fixes real issue. Hmm, could you apply the patch I posted, instead? It has configuration in socfpga_config.h -- platform data. Hi! The patch you provided (if we're referring to the same patch, Message-ID: 20141113120956.GB30779@amd) breaks every board which uses the Micrel PHY, doesn't it ? The problem for all other boards would be the new CONFIG_* options which are added into the Micrel driver by that patch. Furthermore, the patch doesn't even apply, it was decided that the patch was an RFC, wasn't it ? Please correct me if I'm wrong. The purpose of that mail was to show that there's better way, so that someone (you) would not apply bandaid when something close to real fix is available. I overlooked the breaks compilation part, but I'm sure it could have been solved with strategicaly placed #ifdef. Notice original patch submission in From pa...@denx.de Sat Oct 25 13:27:52 2014 Date: Sat, 25 Oct 2014 13:27:52 +0200 From: Pavel Machek pa...@denx.de Subject: [patch] net: micrel: configure skew values for Message-ID: 20141025112752.GA19599@amd it is cleaner then 20141113120956.GB30779@amd version. I don't think I received any reply there. But the patch you have just merged would interfere with my approach, and makes it unneccessary, so I'll let you solve it. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 0/5] add i.MX6 thermal sensor driver
On 11/15/2014 06:34 AM, Albert ARIBAUD wrote: Hello nitin.g...@freescale.com, On Fri, 14 Nov 2014 14:13:02 -0600, nitin.g...@freescale.com nitin.g...@freescale.com wrote: From: Nitin Garg nitin.g...@freescale.com This patch set adds i.MX6 thermal sensor driver and enables it for mx6sabre boards. Also adds various anadig bit definitions as required for upcoming drivers. Changes in v6: -Aligned imx thermal driver macro defines with kernel Changes in v5: -Don't modify the copyright of cpu.c and crm_regs.h file Changes in v4: -Added imx6 thermal sensor as a driver -Renamed the config define to be more meaningful -Move the clock code to clock.c -Reusing ocotp driver for reading fuse -Fix check for calibration fuse not programmed -Aligned the slope computation with kernel -Added Anadig register defines as seperate commit Changes in v3: -adds the mx6 thermal driver support -adds the mx6 thermal support to mx6sabresd board. Changes in v2: -run checkpatch and fix reported issues Nitin Garg (4): mx6: clock: Add api to enable pll3 mx6: thermal: Add i.MX6 CPU thermal sensor support mx6: thermal: Check cpu temperature via thermal sensor mx6: thermal: Enable thermal sensor for mx6 sabre boards. So, is it 5 as the cover letter says, or 4 as the patches say? If actually 4 and only the cover letter is wrong, then there's no need to repost. If actually 5, then please repost them all, renumbered accordingly. Amicalement, Just the cover subject is wrong (0/5 should be 0/4). Thanks, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/7] common/board_f: fix gcc warning on MIPS64
This fixes following warning when compiled with MIPS64
common/board_f.c: In function 'display_text_info':
common/board_f.c:150:2: warning: format '%X' expects argument i
of type 'unsigned int', but argument 2 has type 'long unsigned int'
[-Wformat=]
debug(U-Boot code: %08X - %08lX BSS: - %08lX\n,
Signed-off-by: Daniel Schwierzeck daniel.schwierz...@gmail.com
---
common/board_f.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/common/board_f.c b/common/board_f.c
index 57e8a67..d4d25d7 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -142,17 +142,19 @@ static int init_baud_rate(void)
static int display_text_info(void)
{
#ifndef CONFIG_SANDBOX
- ulong bss_start, bss_end;
+ ulong bss_start, bss_end, text_base;
bss_start = (ulong)__bss_start;
bss_end = (ulong)__bss_end;
- debug(U-Boot code: %08X - %08lX BSS: - %08lX\n,
#ifdef CONFIG_SYS_TEXT_BASE
- CONFIG_SYS_TEXT_BASE, bss_start, bss_end);
+ text_base = CONFIG_SYS_TEXT_BASE;
#else
- CONFIG_SYS_MONITOR_BASE, bss_start, bss_end);
+ text_base = CONFIG_SYS_MONITOR_BASE;
#endif
+
+ debug(U-Boot code: %08lX - %08lX BSS: - %08lX\n,
+ text_base, bss_start, bss_end);
#endif
#ifdef CONFIG_MODEM_SUPPORT
--
2.1.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/7] MIPS: dbau1x00: switch to generic board
Signed-off-by: Daniel Schwierzeck daniel.schwierz...@gmail.com --- include/configs/dbau1x00.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/configs/dbau1x00.h b/include/configs/dbau1x00.h index e0bf3dc..8a7447d 100644 --- a/include/configs/dbau1x00.h +++ b/include/configs/dbau1x00.h @@ -15,6 +15,9 @@ #define CONFIG_DBAU1X001 #define CONFIG_SOC_AU1X00 1 /* alchemy series cpu */ +#define CONFIG_SYS_GENERIC_BOARD +#define CONFIG_DISPLAY_BOARDINFO + #ifdef CONFIG_DBAU1000 /* Also known as Merlot */ #define CONFIG_SOC_AU1000 1 -- 2.1.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/7] common/board_f: add setup of initial stack frame for MIPS
The MIPS specific setup of the initial stack frame was not ported to generic board_f. Signed-off-by: Daniel Schwierzeck daniel.schwierz...@gmail.com --- common/board_f.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/common/board_f.c b/common/board_f.c index b5bebc9..57e8a67 100644 --- a/common/board_f.c +++ b/common/board_f.c @@ -579,7 +579,7 @@ static int reserve_stacks(void) gd-irq_sp = gd-start_addr_sp; # endif #else -# ifdef CONFIG_PPC +# if defined(CONFIG_PPC) || defined(CONFIG_MIPS) ulong *s; # endif @@ -609,6 +609,12 @@ static int reserve_stacks(void) s = (ulong *) gd-start_addr_sp; *s = 0; /* Terminate back chain */ *++s = 0; /* NULL return address */ +# elif defined(CONFIG_MIPS) + /* Clear initial stack frame */ + s = (ulong *) gd-start_addr_sp; + *s-- = 0; + *s-- = 0; + gd-start_addr_sp = (ulong) s; # endif /* Architecture specific code */ return 0; -- 2.1.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/7] MIPS: convert all boards to generic-board
Daniel Schwierzeck (7): common/board_f: add setup of initial stack frame for MIPS common/board_f: fix gcc warning on MIPS64 MIPS: dbau1x00: switch to generic board MIPS: pb1x00: switch to generic board MIPS: qemu_mips: switch to generic board MIPS: vct: switch to generic board MIPS: remove board.c arch/mips/lib/Makefile| 3 - arch/mips/lib/board.c | 320 -- common/board_f.c | 18 ++- include/configs/dbau1x00.h| 3 + include/configs/pb1x00.h | 3 + include/configs/qemu-mips.h | 3 + include/configs/qemu-mips64.h | 3 + include/configs/vct.h | 3 + 8 files changed, 28 insertions(+), 328 deletions(-) delete mode 100644 arch/mips/lib/board.c -- 2.1.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 7/7] MIPS: remove board.c
After all MIPS boards are switched to generic-board, the
MIPS specific board.c can be removed.
Signed-off-by: Daniel Schwierzeck daniel.schwierz...@gmail.com
---
arch/mips/lib/Makefile | 3 -
arch/mips/lib/board.c | 320 -
2 files changed, 323 deletions(-)
delete mode 100644 arch/mips/lib/board.c
diff --git a/arch/mips/lib/Makefile b/arch/mips/lib/Makefile
index e483e86..7f9b653 100644
--- a/arch/mips/lib/Makefile
+++ b/arch/mips/lib/Makefile
@@ -5,9 +5,6 @@
# SPDX-License-Identifier: GPL-2.0+
#
-ifndef CONFIG_SYS_GENERIC_BOARD
-obj-y += board.o
-endif
obj-y += io.o
obj-$(CONFIG_CMD_BOOTM) += bootm.o
diff --git a/arch/mips/lib/board.c b/arch/mips/lib/board.c
deleted file mode 100644
index 3feb020..000
--- a/arch/mips/lib/board.c
+++ /dev/null
@@ -1,320 +0,0 @@
-/*
- * (C) Copyright 2003
- * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#include common.h
-#include command.h
-#include malloc.h
-#include serial.h
-#include stdio_dev.h
-#include version.h
-#include net.h
-#include environment.h
-#include nand.h
-#include onenand_uboot.h
-#include spi.h
-
-#ifdef CONFIG_BITBANGMII
-#include miiphy.h
-#endif
-
-DECLARE_GLOBAL_DATA_PTR;
-
-ulong monitor_flash_len;
-
-static char *failed = *** failed ***\n;
-
-int __board_early_init_f(void)
-{
- /*
-* Nothing to do in this dummy implementation
-*/
- return 0;
-}
-int board_early_init_f(void)
- __attribute__((weak, alias(__board_early_init_f)));
-
-static int init_func_ram(void)
-{
-#ifdef CONFIG_BOARD_TYPES
- int board_type = gd-board_type;
-#else
- int board_type = 0; /* use dummy arg */
-#endif
- puts(DRAM: );
-
- gd-ram_size = initdram(board_type);
- if (gd-ram_size 0) {
- print_size(gd-ram_size, \n);
- return 0;
- }
- puts(failed);
- return 1;
-}
-
-static int display_banner(void)
-{
-
- printf(\n\n%s\n\n, version_string);
- return 0;
-}
-
-#ifndef CONFIG_SYS_NO_FLASH
-static void display_flash_config(ulong size)
-{
- puts(Flash: );
- print_size(size, \n);
-}
-#endif
-
-static int init_baudrate(void)
-{
- gd-baudrate = getenv_ulong(baudrate, 10, CONFIG_BAUDRATE);
- return 0;
-}
-
-
-/*
- * Breath some life into the board...
- *
- * The first part of initialization is running from Flash memory;
- * its main purpose is to initialize the RAM so that we
- * can relocate the monitor code to RAM.
- */
-
-/*
- * All attempts to come up with a common initialization sequence
- * that works for all boards and architectures failed: some of the
- * requirements are just _too_ different. To get rid of the resulting
- * mess of board dependend #ifdef'ed code we now make the whole
- * initialization sequence configurable to the user.
- *
- * The requirements for any new initalization function is simple: it
- * receives a pointer to the global data structure as it's only
- * argument, and returns an integer return code, where 0 means
- * continue and != 0 means fatal error, hang the system.
- */
-typedef int (init_fnc_t)(void);
-
-init_fnc_t *init_sequence[] = {
- board_early_init_f,
- timer_init,
- env_init, /* initialize environment */
- init_baudrate, /* initialize baudrate settings */
- serial_init,/* serial communications setup */
- console_init_f,
- display_banner, /* say that we are here */
- checkboard,
- init_func_ram,
- NULL,
-};
-
-
-void board_init_f(ulong bootflag)
-{
- gd_t gd_data, *id;
- bd_t *bd;
- init_fnc_t **init_fnc_ptr;
- ulong addr, addr_sp, len;
- ulong *s;
-
- /* Pointer is writable since we allocated a register for it.
-*/
- gd = gd_data;
- /* compiler optimization barrier needed for GCC = 3.4 */
- __asm__ __volatile__( : : : memory);
-
- memset((void *)gd, 0, sizeof(gd_t));
-
- for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
- if ((*init_fnc_ptr)() != 0)
- hang();
- }
-
- /*
-* Now that we have DRAM mapped and working, we can
-* relocate the code and continue running from DRAM.
-*/
- addr = CONFIG_SYS_SDRAM_BASE + gd-ram_size;
-
- /* We can reserve some RAM on top here.
-*/
-
- /* round down to next 4 kB limit.
-*/
- addr = ~(4096 - 1);
- debug(Top of RAM usable for U-Boot at: %08lx\n, addr);
-
- /* Reserve memory for U-Boot code, data bss
-* round down to next 16 kB limit
-*/
- len = bss_end() - CONFIG_SYS_MONITOR_BASE;
- addr -= len;
- addr = ~(16 * 1024 - 1);
-
- debug(Reserving %ldk for U-Boot at: %08lx\n, len 10, addr);
-
-/* Reserve memory for malloc() arena.
-*/
- addr_sp = addr
[U-Boot] [PATCH 5/7] MIPS: qemu_mips: switch to generic board
Signed-off-by: Daniel Schwierzeck daniel.schwierz...@gmail.com --- include/configs/qemu-mips.h | 3 +++ include/configs/qemu-mips64.h | 3 +++ 2 files changed, 6 insertions(+) diff --git a/include/configs/qemu-mips.h b/include/configs/qemu-mips.h index 98ed8bc..1548d3e 100644 --- a/include/configs/qemu-mips.h +++ b/include/configs/qemu-mips.h @@ -13,6 +13,9 @@ #define __CONFIG_H #define CONFIG_QEMU_MIPS + +#define CONFIG_SYS_GENERIC_BOARD +#define CONFIG_DISPLAY_BOARDINFO #define CONFIG_MISC_INIT_R #define CONFIG_BOOTDELAY 10 /* autoboot after 10 seconds */ diff --git a/include/configs/qemu-mips64.h b/include/configs/qemu-mips64.h index e8f5a4c..61cafad 100644 --- a/include/configs/qemu-mips64.h +++ b/include/configs/qemu-mips64.h @@ -13,6 +13,9 @@ #define __CONFIG_H #define CONFIG_QEMU_MIPS + +#define CONFIG_SYS_GENERIC_BOARD +#define CONFIG_DISPLAY_BOARDINFO #define CONFIG_MISC_INIT_R #define CONFIG_BOOTDELAY 10 /* autoboot after 10 seconds */ -- 2.1.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/7] MIPS: vct: switch to generic board
Signed-off-by: Daniel Schwierzeck daniel.schwierz...@gmail.com --- include/configs/vct.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/configs/vct.h b/include/configs/vct.h index 217ba2f..83e4163 100644 --- a/include/configs/vct.h +++ b/include/configs/vct.h @@ -25,6 +25,9 @@ #ifndef __CONFIG_H #define __CONFIG_H +#define CONFIG_SYS_GENERIC_BOARD +#define CONFIG_DISPLAY_BOARDINFO + #define CPU_CLOCK_RATE 32400 /* Clock for the MIPS core */ #define CONFIG_SYS_MIPS_TIMER_FREQ (CPU_CLOCK_RATE / 2) -- 2.1.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/7] MIPS: pb1x00: switch to generic board
Signed-off-by: Daniel Schwierzeck daniel.schwierz...@gmail.com --- include/configs/pb1x00.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/configs/pb1x00.h b/include/configs/pb1x00.h index 1c04a58..61e6af3 100644 --- a/include/configs/pb1x00.h +++ b/include/configs/pb1x00.h @@ -15,6 +15,9 @@ #define CONFIG_PB1X00 1 #define CONFIG_SOC_AU1X00 1 /* alchemy series cpu */ +#define CONFIG_SYS_GENERIC_BOARD +#define CONFIG_DISPLAY_BOARDINFO + #ifdef CONFIG_PB1000 #define CONFIG_SOC_AU1000 1 #else -- 2.1.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [patch] net: micrel: configure skew values for
On Saturday, October 25, 2014 at 01:27:52 PM, Pavel Machek wrote:
This adds skew timing configuration for micrel ksz9021
configuration. With this patch, I can add
#define CONFIG_KSZ9021_CLK_SKEW_ENVmicrel-ksz9021-clk-skew
#define CONFIG_KSZ9021_CLK_SKEW_VAL0xf0f0
#define CONFIG_KSZ9021_DATA_SKEW_ENV micrel-ksz9021-data-skew
#define CONFIG_KSZ9021_DATA_SKEW_VAL 0x0
to my board's configuration file, and get working networking in
u-boot.
Signed-off-by: Pavel Machek pa...@denx.de
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index 507b9a3..7e4dbd6 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -117,12 +119,31 @@ static int ksz9021_config(struct phy_device *phydev)
{
unsigned ctrl1000 = 0;
const unsigned master = CTRL1000_PREFER_MASTER |
- CTRL1000_CONFIG_MASTER | CTRL1000_MANUAL_CONFIG;
+ CTRL1000_CONFIG_MASTER | CTRL1000_MANUAL_CONFIG;
unsigned features = phydev-drv-features;
+ /* min rx data delay */
+ if (ksz9021_phy_extended_write(phydev,
+MII_KSZ9021_EXT_RGMII_RX_DATA_SKEW,
+
getenv_ulong(CONFIG_KSZ9021_DATA_SKEW_ENV, 16,
+
CONFIG_KSZ9021_DATA_SKEW_VAL)) 0)
+ return -1;
You should probably get rid of the getenv altogether and just let the board
define a static value in it's configuration (for now). In the long run, this
configuration value should be passed via the platform data or DT.
The new CONFIG_* macros should be documented, otherwise the sheer amount of
CONFIG_* in U-Boot will become impossible to manage. Speaking of CONFIG_*,
given that there is no default value for any of the new CONFIG_* macros, the
patch will break all boards using the Micrel PHY which do not define those
macros explicitly.
On a final note, not all boards using the Micrel PHY need to override those
registers, so this must also be solved in some way such that the behavior
of this driver doesn't change for the boards which do not implement this
override.
I am also curious if there will be more registers which would need such
explicit
override configuration option in the future or if these are all of them. I guess
we cannot tell right now.
[...]
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm: socfpga: set skew settings for ethernet phy
On Saturday, November 15, 2014 at 11:20:54 PM, Pavel Machek wrote: On Sat 2014-11-15 22:29:00, Marek Vasut wrote: On Saturday, November 15, 2014 at 08:54:06 PM, Pavel Machek wrote: On Fri 2014-11-14 21:02:48, Marek Vasut wrote: On Friday, November 14, 2014 at 11:23:27 AM, Pavel Machek wrote: On Thu 2014-11-13 11:23:41, dingu...@opensource.altera.com wrote: From: Dinh Nguyen dingu...@opensource.altera.com Set the PHY skew settings for the ethernet phy on the SOCFPGA Cyclone5 hardware. Is it to need similar settings for all ksz9021 phys? Should this go to drivers/ as I suggested with a patch? This is board specific, but with the driver model, this should be moved into the PHY driver and the values should be passed via platform data or DT. I will apply this now, since it fixes real issue. Hmm, could you apply the patch I posted, instead? It has configuration in socfpga_config.h -- platform data. Hi! The patch you provided (if we're referring to the same patch, Message-ID: 20141113120956.GB30779@amd) breaks every board which uses the Micrel PHY, doesn't it ? The problem for all other boards would be the new CONFIG_* options which are added into the Micrel driver by that patch. Furthermore, the patch doesn't even apply, it was decided that the patch was an RFC, wasn't it ? Please correct me if I'm wrong. The purpose of that mail was to show that there's better way, so that someone (you) would not apply bandaid when something close to real fix is available. I had to pick from two options -- apply a patch which solves a real problem now and which follows approach already implemented for a different board in mainline -- or wait until an RFC patch is done discussing and makes it into mainline. I decided to solve a real problem now and in case a proper fix/cleanup arrives afterward, I will only be happy about that. I overlooked the breaks compilation part, but I'm sure it could have been solved with strategicaly placed #ifdef. Notice original patch submission in From pa...@denx.de Sat Oct 25 13:27:52 2014 Date: Sat, 25 Oct 2014 13:27:52 +0200 From: Pavel Machek pa...@denx.de Subject: [patch] net: micrel: configure skew values for Message-ID: 20141025112752.GA19599@amd it is cleaner then 20141113120956.GB30779@amd version. I don't think I received any reply there. Sorry, I missed the new version. I'll comment on it separatelly. But the patch you have just merged would interfere with my approach, and makes it unneccessary, so I'll let you solve it. In fact, the Micrel PHY patch changes only the Micrel driver. This patch changes only the SoCFPGA CV board. They are two completely orthogonal patches. The Micrel PHY patch can just be followed by a cleanup patch which removes the explicitly PHY setup function from both the MX6 Nitrogen 6x and SoCFPGA boards. I don't see any problem with such cleanup, do you ? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/7] MIPS: bootm fixes and initial device tree support
This patch series fixes and prepares bootm to initially support the hand over of flattened device trees to the kernel. The first patch fixes the missing initramfs relocation if bootm is used without subcommands. Patches 3 and 4 make the legacy boot interface configurable. Patch 5 adds mem, rd_start and rd_size to kernel command line for targets those do not use the legacy Linux env. Patch 6 adds the required code to prepare a flattened device tree for the kernel. The final hand over to the kernel is not yet implemented. After the community agreed on the official MIPS boot interface for device trees, the corresponding code will be added. Daniel Schwierzeck (7): MIPS: bootm: add missing initramfs relocation MIPS: bootm: remove unused or redundant header files MIPS: bootm: refactor preparation of Linux kernel command line MIPS: bootm: refactor preparation of Linux kernel environment MIPS: bootm: add mem, rd_start and rd_size to kernel command line MIPS: bootm: prepare a flattened device tree for the kernel MIPS: bootm: add bootstage reporting arch/mips/Kconfig | 33 ++ arch/mips/lib/bootm.c | 121 ++ 2 files changed, 146 insertions(+), 8 deletions(-) -- 2.1.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/7] MIPS: bootm: add missing initramfs relocation
The initramfs is currently only relocated if the user calls
the bootm ramdisk subcommand. If bootm should be used without
subcommands, the arch-specific bootm code needs to implement
the relocation.
Signed-off-by: Daniel Schwierzeck daniel.schwierz...@gmail.com
---
arch/mips/lib/bootm.c | 20
1 file changed, 20 insertions(+)
diff --git a/arch/mips/lib/bootm.c b/arch/mips/lib/bootm.c
index 71bb0d2..f947fd6 100644
--- a/arch/mips/lib/bootm.c
+++ b/arch/mips/lib/bootm.c
@@ -52,6 +52,20 @@ void arch_lmb_reserve(struct lmb *lmb)
lmb_reserve(lmb, sp, CONFIG_SYS_SDRAM_BASE + gd-ram_size - sp);
}
+static int boot_setup_linux(bootm_headers_t *images)
+{
+ int ret;
+ ulong rd_len;
+
+ rd_len = images-rd_end - images-rd_start;
+ ret = boot_ramdisk_high(images-lmb, images-rd_start,
+ rd_len, images-initrd_start, images-initrd_end);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
static void linux_cmdline_init(void)
{
linux_argc = 1;
@@ -224,6 +238,8 @@ static void boot_jump_linux(bootm_headers_t *images)
int do_bootm_linux(int flag, int argc, char * const argv[],
bootm_headers_t *images)
{
+ int ret;
+
/* No need for those on MIPS */
if (flag BOOTM_STATE_OS_BD_T)
return -1;
@@ -243,6 +259,10 @@ int do_bootm_linux(int flag, int argc, char * const argv[],
return 0;
}
+ ret = boot_setup_linux(images);
+ if (ret)
+ return ret;
+
boot_cmdline_linux(images);
boot_prep_linux(images);
boot_jump_linux(images);
--
2.1.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/7] MIPS: bootm: remove unused or redundant header files
Signed-off-by: Daniel Schwierzeck daniel.schwierz...@gmail.com --- arch/mips/lib/bootm.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/arch/mips/lib/bootm.c b/arch/mips/lib/bootm.c index f947fd6..e0722d2 100644 --- a/arch/mips/lib/bootm.c +++ b/arch/mips/lib/bootm.c @@ -6,10 +6,7 @@ */ #include common.h -#include command.h #include image.h -#include u-boot/zlib.h -#include asm/byteorder.h #include asm/addrspace.h DECLARE_GLOBAL_DATA_PTR; -- 2.1.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/7] MIPS: bootm: refactor preparation of Linux kernel command line
Move preparation of Linux kernel command line in a separate
function and mark it as legacy. Add a Kconfig option to make
that legacy mode configurable.
Signed-off-by: Daniel Schwierzeck daniel.schwierz...@gmail.com
---
arch/mips/Kconfig | 13 +
arch/mips/lib/bootm.c | 16 ++--
2 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 4991da2..a5d5a33 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -116,6 +116,19 @@ config CPU_MIPS64_R2
endchoice
+menu OS boot interface
+
+config MIPS_BOOT_CMDLINE_LEGACY
+ bool Hand over legacy command line to Linux kernel
+ default y
+ help
+ Enable this option if you want U-Boot to hand over the Yamon-style
+ command line to the kernel. All bootargs will be prepared as argc/argv
+ compatible list. The argument count (argc) is stored in register $a0.
+ The address of the argument list (argv) is stored in register $a1.
+
+endmenu
+
config SUPPORTS_BIG_ENDIAN
bool
diff --git a/arch/mips/lib/bootm.c b/arch/mips/lib/bootm.c
index e0722d2..a028a47 100644
--- a/arch/mips/lib/bootm.c
+++ b/arch/mips/lib/bootm.c
@@ -20,6 +20,12 @@ DECLARE_GLOBAL_DATA_PTR;
#define mips_boot_malta0
#endif
+#if defined(CONFIG_MIPS_BOOT_CMDLINE_LEGACY)
+#define mips_boot_cmdline_legacy 1
+#else
+#define mips_boot_cmdline_legacy 0
+#endif
+
static int linux_argc;
static char **linux_argv;
static char *linux_argp;
@@ -92,7 +98,7 @@ static void linux_cmdline_dump(void)
debug( arg %03d: %s\n, i, linux_argv[i]);
}
-static void boot_cmdline_linux(bootm_headers_t *images)
+static void linux_cmdline_legacy(bootm_headers_t *images)
{
const char *bootargs, *next, *quote;
@@ -130,8 +136,14 @@ static void boot_cmdline_linux(bootm_headers_t *images)
bootargs = next;
}
+}
- linux_cmdline_dump();
+static void boot_cmdline_linux(bootm_headers_t *images)
+{
+ if (mips_boot_cmdline_legacy) {
+ linux_cmdline_legacy(images);
+ linux_cmdline_dump();
+ }
}
static void linux_env_init(void)
--
2.1.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 7/7] MIPS: bootm: add bootstage reporting
Signed-off-by: Daniel Schwierzeck daniel.schwierz...@gmail.com --- arch/mips/lib/bootm.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/mips/lib/bootm.c b/arch/mips/lib/bootm.c index 426f68a..d9d8396 100644 --- a/arch/mips/lib/bootm.c +++ b/arch/mips/lib/bootm.c @@ -310,8 +310,12 @@ static void boot_jump_linux(bootm_headers_t *images) if (mips_boot_malta) linux_extra = gd-ram_size; - /* we assume that the kernel is in place */ - printf(\nStarting kernel ...\n\n); +#ifdef CONFIG_BOOTSTAGE_FDT + bootstage_fdt_add_report(); +#endif +#ifdef CONFIG_BOOTSTAGE_REPORT + bootstage_report(); +#endif kernel(linux_argc, (ulong)linux_argv, (ulong)linux_env, linux_extra); } -- 2.1.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/7] MIPS: bootm: refactor preparation of Linux kernel environment
Move preparation of Linux kernel environment in a separate
function and mark it as legacy. Add a Kconfig option to make
that legacy mode configurable.
Signed-off-by: Daniel Schwierzeck daniel.schwierz...@gmail.com
---
arch/mips/Kconfig | 9 +
arch/mips/lib/bootm.c | 14 +-
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index a5d5a33..9b3ecea 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -127,6 +127,15 @@ config MIPS_BOOT_CMDLINE_LEGACY
compatible list. The argument count (argc) is stored in register $a0.
The address of the argument list (argv) is stored in register $a1.
+config MIPS_BOOT_ENV_LEGACY
+ bool Hand over legacy environment to Linux kernel
+ default y
+ help
+ Enable this option if you want U-Boot to hand over the Yamon-style
+ environment to the kernel. Information like memory size, initrd
+ address and size will be prepared as zero-terminated key/value list.
+ The address of the enviroment is stored in register $a2.
+
endmenu
config SUPPORTS_BIG_ENDIAN
diff --git a/arch/mips/lib/bootm.c b/arch/mips/lib/bootm.c
index a028a47..fa579b3 100644
--- a/arch/mips/lib/bootm.c
+++ b/arch/mips/lib/bootm.c
@@ -26,6 +26,12 @@ DECLARE_GLOBAL_DATA_PTR;
#define mips_boot_cmdline_legacy 0
#endif
+#if defined(CONFIG_MIPS_BOOT_ENV_LEGACY)
+#define mips_boot_env_legacy 1
+#else
+#define mips_boot_env_legacy 0
+#endif
+
static int linux_argc;
static char **linux_argv;
static char *linux_argp;
@@ -177,7 +183,7 @@ static void linux_env_set(const char *env_name, const char
*env_val)
}
}
-static void boot_prep_linux(bootm_headers_t *images)
+static void linux_env_legacy(bootm_headers_t *images)
{
char env_buf[12];
const char *cp;
@@ -225,6 +231,12 @@ static void boot_prep_linux(bootm_headers_t *images)
}
}
+static void boot_prep_linux(bootm_headers_t *images)
+{
+ if (mips_boot_env_legacy)
+ linux_env_legacy(images);
+}
+
static void boot_jump_linux(bootm_headers_t *images)
{
typedef void __noreturn (*kernel_entry_t)(int, ulong, ulong, ulong);
--
2.1.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/7] MIPS: bootm: prepare a flattened device tree for the kernel
Add the initial code to prepare a flattened device tree for
the kernel like relocating the FDT blob and fixing up the
/chosen and /memory nodes.
The final hand over to the kernel is not yet implemented. After
the community agreed on the MIPS boot interface for device trees,
the corresponding code will be added.
Signed-off-by: Daniel Schwierzeck daniel.schwierz...@gmail.com
---
arch/mips/Kconfig | 11 +++
arch/mips/lib/bootm.c | 38 --
2 files changed, 47 insertions(+), 2 deletions(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 9b3ecea..363f5ac 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -136,6 +136,17 @@ config MIPS_BOOT_ENV_LEGACY
address and size will be prepared as zero-terminated key/value list.
The address of the enviroment is stored in register $a2.
+config MIPS_BOOT_FDT
+ bool Hand over a flattened device tree to Linux kernel (INCOMPLETE)
+ default n
+ help
+ Enable this option if you want U-Boot to hand over a flattened
+ device tree to the kernel.
+
+ Note: the final hand over to the kernel is not yet implemented. After
+ the community agreed on the MIPS boot interface for device
trees,
+ the corresponding code will be added.
+
endmenu
config SUPPORTS_BIG_ENDIAN
diff --git a/arch/mips/lib/bootm.c b/arch/mips/lib/bootm.c
index 7a98f15..426f68a 100644
--- a/arch/mips/lib/bootm.c
+++ b/arch/mips/lib/bootm.c
@@ -7,6 +7,7 @@
#include common.h
#include image.h
+#include fdt_support.h
#include asm/addrspace.h
DECLARE_GLOBAL_DATA_PTR;
@@ -72,9 +73,39 @@ static int boot_setup_linux(bootm_headers_t *images)
if (ret)
return ret;
+#if defined(CONFIG_MIPS_BOOT_FDT) defined(CONFIG_OF_LIBFDT)
+ if (images-ft_len) {
+ boot_fdt_add_mem_rsv_regions(images-lmb, images-ft_addr);
+
+ ret = boot_relocate_fdt(images-lmb, images-ft_addr,
+ images-ft_len);
+ if (ret)
+ return ret;
+ }
+#endif
+
return 0;
}
+static void boot_setup_fdt(bootm_headers_t *images)
+{
+#if defined(CONFIG_MIPS_BOOT_FDT) defined(CONFIG_OF_LIBFDT)
+ u64 mem_start = 0;
+ u64 mem_size = gd-ram_size;
+
+ debug(## setup FDT\n);
+
+ fdt_chosen(images-ft_addr, 1);
+ fdt_fixup_memory_banks(images-ft_addr, mem_start, mem_size, 1);
+ fdt_fixup_ethernet(images-ft_addr);
+ fdt_initrd(images-ft_addr, images-initrd_start, images-initrd_end,
1);
+
+#if defined(CONFIG_OF_BOARD_SETUP)
+ ft_board_setup(images-ft_addr, gd-bd);
+#endif
+#endif
+}
+
static void linux_cmdline_init(void)
{
linux_argc = 1;
@@ -168,7 +199,7 @@ static void linux_cmdline_append(bootm_headers_t *images)
static void boot_cmdline_linux(bootm_headers_t *images)
{
- if (mips_boot_cmdline_legacy) {
+ if (mips_boot_cmdline_legacy !images-ft_len) {
linux_cmdline_legacy(images);
if (!mips_boot_env_legacy)
@@ -259,8 +290,11 @@ static void linux_env_legacy(bootm_headers_t *images)
static void boot_prep_linux(bootm_headers_t *images)
{
- if (mips_boot_env_legacy)
+ if (mips_boot_env_legacy !images-ft_len)
linux_env_legacy(images);
+
+ if (images-ft_len)
+ boot_setup_fdt(images);
}
static void boot_jump_linux(bootm_headers_t *images)
--
2.1.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/7] MIPS: bootm: add mem, rd_start and rd_size to kernel command line
If the user wants to boot a kernel without legacy environment,
information like memory size, initrd address and size should be
handed over to the kernel in the command line.
Signed-off-by: Daniel Schwierzeck daniel.schwierz...@gmail.com
---
arch/mips/lib/bootm.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/mips/lib/bootm.c b/arch/mips/lib/bootm.c
index fa579b3..7a98f15 100644
--- a/arch/mips/lib/bootm.c
+++ b/arch/mips/lib/bootm.c
@@ -144,10 +144,36 @@ static void linux_cmdline_legacy(bootm_headers_t *images)
}
}
+static void linux_cmdline_append(bootm_headers_t *images)
+{
+ char buf[24];
+ ulong mem, rd_start, rd_size;
+
+ /* append mem */
+ mem = gd-ram_size 20;
+ sprintf(buf, mem=%luM, mem);
+ linux_cmdline_set(buf, strlen(buf));
+
+ /* append rd_start and rd_size */
+ rd_start = images-initrd_start;
+ rd_size = images-initrd_end - images-initrd_start;
+
+ if (rd_size) {
+ sprintf(buf, rd_start=0x%08lX, rd_start);
+ linux_cmdline_set(buf, strlen(buf));
+ sprintf(buf, rd_size=0x%lX, rd_size);
+ linux_cmdline_set(buf, strlen(buf));
+ }
+}
+
static void boot_cmdline_linux(bootm_headers_t *images)
{
if (mips_boot_cmdline_legacy) {
linux_cmdline_legacy(images);
+
+ if (!mips_boot_env_legacy)
+ linux_cmdline_append(images);
+
linux_cmdline_dump();
}
}
--
2.1.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Query on CONFIG_SYS_THUMB_BUILD
Hello Simon, On Sat, 15 Nov 2014 15:10:47 -0700, Simon Glass s...@chromium.org wrote: Hi Albert, On 15 November 2014 05:30, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hello Simon, On Fri, 14 Nov 2014 18:56:07 -0700, Simon Glass s...@chromium.org wrote: I believe you've built crt0.S for ARM, not Thumb. Yes, but I suspect that is a function of the build system. I checked the rest of U-Boot and most of it (including SPL) is Thumb 2. I suppose we could use Thumb 2 for crt0.S if all the instructions are supported. Ok. Just in case, I'll run a check on whether crt0.S can be assembled for Thumb and still wrk as expected. :) Do you have a list of source files which still build for ARM under CONFIG_SYS_THUMB_BUILD? I' would prefer all of the code to be thumb for consistence, except probably... exception :) entry points -- and even these should be able to run in full Thumb 2. No I don't have a list, but it might be all assembler files. I don't see why cro0.S would be special. Ok, so after some research, .S files voluntarily not assembled in Thumb mode when -mthumb is defined in gcc because of this: Answer: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27237 (summary: -mthumb for gcc means 'use thumb2', while it means 'use dumb, 16-bit, thumb1' for GNU as, so this option is voluntarily not passed on to GNU as. You have to use .thumb in the .S file instead.) Second: getting a successful, though quick'n'dirty, build with vectors.S assembled in Thumb-2 mode needed surprisingly little change in vectors.S. I tried this with mx53loco, and it only required: - adding '.syntax unified'; - adding a .thumb directive -- *after* the vectors per se, which must still be assembled in ARM mode because current hardware always executes exceptions vectors in ARM mode (1); - using '.balign' instead of '.balignl' which causes the assembler to complain that it cannot fit an integer number of '0xdeadbeef' in the filling space; - making macro get_bad_stack use lr instead of r13, which Thumb does not allow in 'msr spsr,' instructions; - adding '.thumb_func' to all routines so that the linker makes all references to them odd and therefore, cause the CPU to enforce Thumb mode when branching to them. (1) although you *could* produce an ARM-based SoC that runs in Thumb mode by default. In this case, you'd have to make the vectors themselves Thumb too. Third: getting a successful *run* of the resulting file will require some work which I'm not going to do without a good incentive :) -- and so does producing a clean vectors.S, i.e. one which will assemble correctly for both ARM and Thumb. Regards, Simon Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
