[U-Boot] [PATCH] FIX : IMX - command for validateion of images.
By defining CONFIG_SECURE_BOOT we made verify_header function available to use which is invoked by esbc_validate command. IMX platforms define only CONFIG_SECURE_BOOT and not cmd_esbc_validate and hence build will be break. In file included from /home/ulises/Security/Secure/u-boot-imx/include/fsl_validate.h:11:0, from /home/ulises/Security/Secure/u-boot-imx/board/freescale/common/fsl_validate.c:8: /home/ulises/Security/Secure/u-boot-imx/include/fsl_sec_mon.h:27:2: error: #error Neither CONFIG_SYS_FSL_SEC_MON_LE nor CONFIG_SYS_FSL_SEC_MON_BE defined #error Neither CONFIG_SYS_FSL_SEC_MON_LE nor CONFIG_SYS_FSL_SEC_MON_BE defined ^ In file included from /home/ulises/Security/Secure/u-boot-imx/board/freescale/common/fsl_validate.c:10:0: /home/ulises/Security/Secure/u-boot-imx/include/fsl_sfp.h:29:2: error: #error Neither CONFIG_SYS_FSL_SFP_LE nor CONFIG_SYS_FSL_SFP_BE is defined #error Neither CONFIG_SYS_FSL_SFP_LE nor CONFIG_SYS_FSL_SFP_BE is defined ^ /home/ulises/Security/Secure/u-boot-imx/board/freescale/common/fsl_validate.c:19:36: fatal error: asm/arch/immap_ls102xa.h: No such file or directory #include ^ compilation terminated. AS arch/arm/lib/vectors.o /home/ulises/Security/Secure/u-boot-imx/scripts/Makefile.build:276: recipe for target 'board/freescale/common/fsl_validate.o' failed make[2]: *** [board/freescale/common/fsl_validate.o] Error 1 /home/ulises/Security/Secure/u-boot-imx/Makefile:1112: recipe for target 'board/freescale/common' failed make[1]: *** [board/freescale/common] Error 2 make[1]: *** Waiting for unfinished jobs Signed-off-by: Gaurav Rana --- board/freescale/common/Makefile | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/board/freescale/common/Makefile b/board/freescale/common/Makefile index 7181cac..87d0578 100644 --- a/board/freescale/common/Makefile +++ b/board/freescale/common/Makefile @@ -74,8 +74,7 @@ obj-$(CONFIG_P5040DS) += p_corenet/ obj-$(CONFIG_LS102XA_NS_ACCESS)+= ns_access.o ifdef CONFIG_SECURE_BOOT -obj-y += fsl_validate.o -obj-$(CONFIG_CMD_ESBC_VALIDATE) += cmd_esbc_validate.o +obj-$(CONFIG_CMD_ESBC_VALIDATE) += fsl_validate.o cmd_esbc_validate.o endif endif -- 1.8.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH][v2] iMX: Fix compilation error when enabling SECURE_BOOT
Move the compilation of file fsl_validate.c in MACRO CONFIG_CMD_ESBC_VALIDATE. This file should be compiled only when the above MACRO is defined This caused a break in compilation of iMX platforms when compiling for SECURE_BOOT Signed-off-by: Gaurav Rana --- Changes in V2: Corrected the commit message. board/freescale/common/Makefile | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/board/freescale/common/Makefile b/board/freescale/common/Makefile index 7181cac..87d0578 100644 --- a/board/freescale/common/Makefile +++ b/board/freescale/common/Makefile @@ -74,8 +74,7 @@ obj-$(CONFIG_P5040DS) += p_corenet/ obj-$(CONFIG_LS102XA_NS_ACCESS)+= ns_access.o ifdef CONFIG_SECURE_BOOT -obj-y += fsl_validate.o -obj-$(CONFIG_CMD_ESBC_VALIDATE) += cmd_esbc_validate.o +obj-$(CONFIG_CMD_ESBC_VALIDATE) += fsl_validate.o cmd_esbc_validate.o endif endif -- 1.8.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] sun9i target support in u-boot?
Hello Alexander, On Sun, 2015-04-05 at 22:41 -0500, kallisti5 wrote: > Good evening! > > I'm looking at a port of Haiku (haiku-os.org) to the A80 cubieboard4. > I can't seem to figure out their u-boot from SD card process. > > Is there sun9i support in your branch / mainline? > > > kallisti5@eris ~ :) $ cat allwinner-bless.sh > #!/bin/bash > > wget > "https://github.com/cubieboard/CC-A80-binaries/raw/master/bin/u-boot-spl.bin"; > -O /tmp/boot0 > wget > "https://github.com/cubieboard/CC-A80-binaries/raw/master/bin/u-boot-sun9iw1p1.bin"; > > -O /tmp/boot1 > > dd if=/tmp/boot0 of=$1 bs=1024 seek=8 > dd if=/tmp/boot1 of=$1 bs=1024 seek=19096 Unfortunately I have almost nothing to do with U-Boot on Cubieboards. For more info please refer to http://linux-sunxi.org/U-Boot If your problem still stays unsolved I would recommend you to continue discussion on U-Boot mailing list (already CCed). Also I'm adding in CC Hans de Goede who's one of maintainers of U-Boot port for Sunxi. -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] sunxi: Complete i2c support for each supported platform
Hi Simon and Paul, On 05-04-15 22:56, Paul Kocialkowski wrote: Le dimanche 05 avril 2015 à 12:31 -0600, Simon Glass a écrit : Hi Paul, On 4 April 2015 at 14:49, Paul Kocialkowski wrote: Sunxi platforms come with at least 3 TWI (I2C) controllers and some platforms even have up to 5. This adds support for every controller on each supported platform, which is especially useful when using expansion ports on single-board- computers. Signed-off-by: Paul Kocialkowski --- arch/arm/include/asm/arch-sunxi/cpu_sun4i.h | 7 +++ arch/arm/include/asm/arch-sunxi/gpio.h | 15 +- arch/arm/include/asm/arch-sunxi/i2c.h | 13 + board/sunxi/Kconfig | 31 board/sunxi/board.c | 75 - 5 files changed, 138 insertions(+), 3 deletions(-) diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig index ccc2080..d3b5bad 100644 --- a/board/sunxi/Kconfig +++ b/board/sunxi/Kconfig @@ -269,6 +269,37 @@ config USB2_VBUS_PIN ---help--- See USB1_VBUS_PIN help text. +config I2C1_ENABLE + bool "Enable I2C/TWI controller 1" + default n + ---help--- + This allows enabling I2C/TWI controller 1 by muxing its pins, enabling + its clock and setting up the bus. This is especially useful on devices + with slaves connected to the bus or with pins exposed through e.g. an + expansion port/header. + +config I2C2_ENABLE + bool "Enable I2C/TWI controller 2" + default n + ---help--- + See I2C1_ENABLE help text. + +if MACH_SUN6I || MACH_SUN7I +config I2C3_ENABLE + bool "Enable I2C/TWI controller 3" + default n + ---help--- + See I2C1_ENABLE help text. +endif + +if MACH_SUN7I +config I2C4_ENABLE + bool "Enable I2C/TWI controller 4" + default n + ---help--- + See I2C1_ENABLE help text. +endif It seems wrong to me to add these when they are already in the device tree for the board. Can we not use that? Well, Hans has a point when saying that some users may use those pins as GPIO while some others may use the TWI/I2C functions, so it makes sense to make this configurable via Kconfig instead of being statically defined. If you would rather wait until we have driver model I2C on sunxi (mvtwsi, I think) then I'd be happy to do the conversion. It's pretty easy. I would be happy to see U-Boot on sunxi use devicetree and driver model for TWI/I2C as well (provided users can still configure what busses to enable). Still, I'd like to see this getting merged as a short term solution. How can we get sunxi moved over before there is an explosion of these sorts of things (as we have already seen with video options)? I fully support moving sunxi over the devicemodel + devicetree in my mind the following steps need to be taken: 0) Get the devicemode usb patches merged in to u-boot-dm/next Then on top pf u-boot-dm/next: 1) Move all the sunxi boards over to use dm + dt like we're already doing for the pcduino 2) Start using dm for usb on sunxi 3) Enable ohci support on sunxi boards next to ehci 4) Move other stuff over on a step by step basis Note that we will likely have a mix of Kconfig + devicetree for quite a while though since certain things which we support in u-boot are not supported in the kernel yet so they do not have stable devicetree bindings yet, video being the big one here. I think Hans will know better (than myself) how to do this right. Not really, other then having the the generic outline above in my head, I do not really have much experience with the devicemodel in u-boot yet, also I do not have all that much time to work one this, so help on this from you would certainly be very welcome. I can answer any sunxi questions you may have, and I believe it is safe to say that Simon can answer any device-model questions you may have. Regards, Hans p.s. Paul I'm still fine with taking your i2c patchset upstream for now, but I do agree with Simon that we need to move to the device model and the sooner we do that the better. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers:usb:fsl: Implement Erratum A-009116 for XHCI controller
> -Original Message- > From: Marek Vasut [mailto:ma...@denx.de] > Sent: Thursday, April 02, 2015 10:32 PM > To: Badola Nikhil-B46172 > Cc: u-boot@lists.denx.de > Subject: Re: [PATCH] drivers:usb:fsl: Implement Erratum A-009116 for XHCI > controller > > On Friday, March 27, 2015 at 04:47:54 AM, Nikhil Badola wrote: > > This adjusts (micro)frame length to appropriate value thus avoiding > > USB devices to time out over a longer run > > > > Signed-off-by: Nikhil Badola > > Hi, > > it seems the XHCI driver from Freescale was never applied, since no > maintainer was ever in CC and there was no effort from the author to contact > anyone after sending it out. That's rather unfortunate. Freescale XHCI driver's author is already talking with HW teams to see if there's some PHY shutdown sequence available for FSL socs...hence the delay. > > I briefly reviewed the driver which you linked and it seems like it is almost > exact copy of the xhci-omap.c . We certainly don't want this level of code > duplication. > I agree with the fact that code duplication should be minimized. However the driver for same controller would follow same initialization steps...until an effort is made in open-source by someone to write a single driver file with common initialization code, this code will keep getting duplicated. > Would it be possible for you to pick up that driver, work your change into it, > avoid the code duplication and repost the whole thing please ? > > Best regards, > Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Basic A33 support including dram init available in my personal repo
Hi Vishnu, On 01-03-15 19:42, Vishnu Patekar wrote: Allwinner A33 tablets comes with the libdram binary, fortunately I've found the libdram code at https://github.com/realthunder/a33_bootloader/tree/master/basic_loader/bsp/bsp_for_a67. I've integrated it with mainline u-boot, still lot to do to post it to upstream Basic A33 support including dram init available in my personal repo https://github.com/vishnupatekar/u-boot-sunxi/tree/a33-dram I could able to boot u-boot over fel, and get u-boot command prompt on microSD pins which are multiplexed with UART0. The device page for A33 tablet which I've is here: http://linux-sunxi.org/Softwinner_astar-rda Just a quick heads up that since I've some time to work on this now, and we've not seen any new code from you in a month, that I'm going to pick up your patches, clean them up and them submit them upstream. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Regarding patch: http://patchwork.ozlabs.org/patch/373593/
> -Original Message-
> From: Marek Vasut [mailto:ma...@denx.de]
> Sent: Monday, January 12, 2015 8:00 PM
> To: Mehresh Ramneek-B31383
> Cc: u-boot
> Subject: Re: Regarding patch: http://patchwork.ozlabs.org/patch/373593/
>
> On Monday, January 12, 2015 at 06:26:24 AM, Ramneek Mehresh wrote:
> > > -Original Message-
> > > From: Marek Vasut [mailto:ma...@denx.de]
> > > Sent: Thursday, December 18, 2014 4:46 PM
> > > To: u-boot
> > > Cc: Mehresh Ramneek-B31383
> > > Subject: Re: Regarding patch:
> > > http://patchwork.ozlabs.org/patch/373593/
> > >
> > > On Thursday, December 18, 2014 at 09:32:56 AM, Ramneek Mehresh
> wrote:
> > > > Hi Marex,
> > > >
> > > > Following u-boot patch is pending for your review for some time.
> > > > Please let me know if you have any concerns. fsl/usb: Add USB XHCI
> > >
> > > support:
> > > > http://patchwork.ozlabs.org/patch/373593/
> > >
> > > I missed the patch completely, sorry. Next time, please keep me on
> > > CC when submitting the patches, that helps a lot.
> > >
> > > As for the board_usb_init, you can drop the inline and the
> > > __board_usb_init() and do:
> > >
> > > __weak int board_usb_init(int index, enum usb_init_type init) {
> > >
> > > return 0;
> > >
> > > }
> >
> > Will do
> >
> > > The static void fsl_xhci_core_exit(struct fsl_xhci *fsl_xhci) must
> > > shut down the controller, which I don't see happening. Why?
> >
> > I could not locate any such requirement in IP documentation. Have
> > contacted local IP/PHY team for the same. Waiting for response from
> > them
>
> This is needed, so you don't start Linux with a running USB controller.
>
xhci controller is already stopped in
usb_stop->usb_lowlevel_stop->xhci_reset().
I could see CMD_RUN bit getting reset in this function before the controller is
reset.
So, from your previously stated requirement, controller is halted when Linux is
started.
Other people are shutting down PHY as part of xhci_core_exit(), not the
controller!!
We would not like to re-start and re-configure PHY inside Linux, and take phy
initialization
inside bootloader. I got word from hw team that they do not support phy
shutting down from sw. hence, we do not have any sequence for current socs to
shut down phy from sw. if required, I'll put forward a request to provide
this control in future socs.
> 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] Basic A33 support including dram init available in my personal repo
Hello Hans, I wish I could have spent more time working on it. however, I could not. Thanks for taking this up. On Mon, Apr 6, 2015 at 2:46 PM, Hans de Goede wrote: > Hi Vishnu, > > On 01-03-15 19:42, Vishnu Patekar wrote: > >> Allwinner A33 tablets comes with the libdram binary, fortunately I've >> found the libdram code at >> https://github.com/realthunder/a33_bootloader/ >> tree/master/basic_loader/bsp/bsp_for_a67. >> >> I've integrated it with mainline u-boot, still lot to do to post it to >> upstream >> >> Basic A33 support including dram init available in my personal repo >> https://github.com/vishnupatekar/u-boot-sunxi/tree/a33-dram >> >> I could able to boot u-boot over fel, and get u-boot command prompt on >> microSD pins which are multiplexed with UART0. >> >> The device page for A33 tablet which I've is here: >> http://linux-sunxi.org/Softwinner_astar-rda >> > > Just a quick heads up that since I've some time to work on this now, > and we've not seen any new code from you in a month, that I'm going to > pick up your patches, clean them up and them submit them upstream. > > Regards, > > Hans > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: am437x: mux: Update mux names
Correct and complete the mux names following AM437x Technical Reference Manual.
Signed-off-by: Bryan De Faria
---
arch/arm/include/asm/arch-am33xx/mux_am43xx.h | 87 +--
1 file changed, 56 insertions(+), 31 deletions(-)
diff --git a/arch/arm/include/asm/arch-am33xx/mux_am43xx.h
b/arch/arm/include/asm/arch-am33xx/mux_am43xx.h
index 98fc2b5..2f4a3d1 100644
--- a/arch/arm/include/asm/arch-am33xx/mux_am43xx.h
+++ b/arch/arm/include/asm/arch-am33xx/mux_am43xx.h
@@ -137,14 +137,62 @@ struct pad_signals {
int mcasp0_fsr;
int mcasp0_axr1;
int mcasp0_ahclkx;
- int xdma_event_intr0;
- int xdma_event_intr1;
+ int cam0_hd;
+ int cam0_vd;
+ int cam0_field;
+ int cam0_wen;
+ int cam0_pclk;
+ int cam0_data8;
+ int cam0_data9;
+ int cam1_data9;
+ int cam1_data8;
+ int cam1_hd;
+ int cam1_vd;
+ int cam1_pclk;
+ int cam1_field;
+ int cam1_wen;
+ int cam1_data0;
+ int cam1_data1;
+ int cam1_data2;
+ int cam1_data3;
+ int cam1_data4;
+ int cam1_data5;
+ int cam1_data6;
+ int cam1_data7;
+ int cam0_data0;
+ int cam0_data1;
+ int cam0_data2;
+ int cam0_data3;
+ int cam0_data4;
+ int cam0_data5;
+ int cam0_data6;
+ int cam0_data7;
+ int uart3_rxd;
+ int uart3_txd;
+ int uart3_ctsn;
+ int uart3_rtsn;
+ int gpio5_8;
+ int gpio5_9;
+ int gpio5_10;
+ int gpio5_11;
+ int gpio5_12;
+ int gpio5_13;
+ int spi4_sclk;
+ int spi4_d0;
+ int spi4_d1;
+ int spi4_cs0;
+ int spi2_sclk;
+ int spi2_d0;
+ int spi2_d1;
+ int spi2_cs0;
+ int xdma_evt_intr0;
+ int xdma_evt_intr1;
+ int clkreq;
int nresetin_out;
- int porz;
- int nnmi;
- int osc0_in;
- int osc0_out;
int rsvd1;
+ int nnmi;
+ int rsvd2;
+ int rsvd3;
int tms;
int tdi;
int tdo;
@@ -154,34 +202,11 @@ struct pad_signals {
int emu1;
int osc1_in;
int osc1_out;
- int pmic_power_en;
int rtc_porz;
- int rsvd2;
- int ext_wakeup;
- int enz_kaldo_1p8v;
- int usb0_dm;
- int usb0_dp;
- int usb0_ce;
- int usb0_id;
- int usb0_vbus;
+ int ext_wakeup0;
+ int pmic_power_en0;
int usb0_drvvbus;
- int usb1_dm;
- int usb1_dp;
- int usb1_ce;
- int usb1_id;
- int usb1_vbus;
int usb1_drvvbus;
- int ddr_resetn;
- int ddr_csn0;
- int ddr_cke;
- int ddr_ck;
- int ddr_nck;
- int ddr_casn;
- int ddr_rasn;
- int ddr_wen;
- int ddr_ba0;
- int ddr_ba1;
- int ddr_ba2;
};
#endif /* _MUX_AM43XX_H_ */
--
2.3.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv3 01/17] arm: socfpga: spl: Add main sdram code
Hi Marek, On Thu, Apr 2, 2015 at 9:00 PM, Marek Vasut wrote: > On Tuesday, March 31, 2015 at 08:41:46 AM, Wolfgang Denk wrote: >> Dear dingu...@opensource.altera.com, >> >> In message >> <1427752878-18426-2-git-send-email-dingu...@opensource.altera.com> you >> wrote: >> >> ... >> >> > +/* Register: sdr.ctrlgrp.ctrlcfg >> > */ +#define SDR_CTRLGRP_CTRLCFG_ADDRESS 0x5000 >> > +/* Register: sdr.ctrlgrp.dramtiming1 >> > */ +#define SDR_CTRLGRP_DRAMTIMING1_ADDRESS 0x5004 >> > +/* Register: sdr.ctrlgrp.dramtiming2 >> > */ +#define SDR_CTRLGRP_DRAMTIMING2_ADDRESS 0x5008 >> > +/* Register: sdr.ctrlgrp.dramtiming3 >> > */ +#define SDR_CTRLGRP_DRAMTIMING3_ADDRESS 0x500c >> > +/* Register: sdr.ctrlgrp.dramtiming4 >> > */ +#define SDR_CTRLGRP_DRAMTIMING4_ADDRESS 0x5010 >> > +/* Register: sdr.ctrlgrp.lowpwrtiming >> > */ +#define SDR_CTRLGRP_LOWPWRTIMING_ADDRESS 0x5014 >> > +/* Register: sdr.ctrlgrp.dramodt >> > */ +#define SDR_CTRLGRP_DRAMODT_ADDRESS 0x5018 >> > +/* Register: sdr.ctrlgrp.dramaddrw >> > */ +#define SDR_CTRLGRP_DRAMADDRW_ADDRESS 0x502c >> >> ... >> >> First, this whole block of registers should probably made a C struct. >> Also, the comments are pretty much redundant - they do not add any new >> information that is not already included in the #define, so they could >> be omitted to make the code easier to read. > > Hi! > > Sculpting this file into shape would be the most difficult part. I guess > Wolfgang already pointed out the largest issues. I also picked up most > of the series to make your life easier. > > Is there any way I can help you with getting this patch in shape ? > Thanks for picking up the other patches for the SPL. That helps out ALOT! I can focus on getting the SDRAM driver in better shape. Give me a week or 2 for an updated patch. Dinh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Where can I find u-boot which supports Raspberry Pi B+
Hi, I want to boot up Raspberry Pi B+ with u-boot. Where can I get a u-boot source code/image that can boot up my Raspberry Pi B+? Regards, Huan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1] ARMv7 TLB: Fixed TTBR0 and Table Descriptors to allow caching
The TTBR0 register and Table Descriptors of the ARMv7 TLB weren't being
properly set to allow for the configuration specified caching modes to
be active over DRAM. This commit fixes those issues.
Signed-off-by: Bryan Brinsko
Cc: Albert Aribaud
Cc: Marek Vasut
---
arch/arm/include/asm/system.h | 37 +
arch/arm/lib/cache-cp15.c | 14 ++
2 files changed, 51 insertions(+)
diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
index 2a5bed2..9cd2f1e 100644
--- a/arch/arm/include/asm/system.h
+++ b/arch/arm/include/asm/system.h
@@ -196,6 +196,28 @@ static inline void set_dacr(unsigned int val)
isb();
}
+#ifdef CONFIG_ARMV7
+/* Short-Descriptor Translation Table Level 1 Bits */
+#define TTB_SECT_NS_MASK (1 << 19)
+#define TTB_SECT_NG_MASK (1 << 17)
+#define TTB_SECT_S_MASK(1 << 16)
+/* Note: TTB AP bits are set elsewhere */
+#define TTB_SECT_TEX(x)((x & 0x7) << 12)
+#define TTB_SECT_DOMAIN(x) ((x & 0xf) << 5)
+#define TTB_SECT_XN_MASK (1 << 4)
+#define TTB_SECT_C_MASK(1 << 3)
+#define TTB_SECT_B_MASK(1 << 2)
+#define TTB_SECT (2 << 0)
+
+/* options available for data cache on each page */
+enum dcache_option {
+ DCACHE_OFF = TTB_SECT_S_MASK | TTB_SECT_DOMAIN(0) |
+ TTB_SECT_XN_MASK | TTB_SECT,
+ DCACHE_WRITETHROUGH = DCACHE_OFF | TTB_SECT_C_MASK,
+ DCACHE_WRITEBACK = DCACHE_WRITETHROUGH | TTB_SECT_B_MASK,
+ DCACHE_WRITEALLOC = DCACHE_WRITEBACK | TTB_SECT_TEX(1),
+};
+#else
/* options available for data cache on each page */
enum dcache_option {
DCACHE_OFF = 0x12,
@@ -203,6 +225,7 @@ enum dcache_option {
DCACHE_WRITEBACK = 0x1e,
DCACHE_WRITEALLOC = 0x16,
};
+#endif
/* Size of an MMU section */
enum {
@@ -210,6 +233,20 @@ enum {
MMU_SECTION_SIZE= 1 << MMU_SECTION_SHIFT,
};
+#ifdef CONFIG_ARMV7
+/* TTBR0 bits */
+#define TTBR0_BASE_ADDR_MASK 0xC000
+#define TTBR0_RGN_NC (0 << 3)
+#define TTBR0_RGN_WBWA (1 << 3)
+#define TTBR0_RGN_WT (2 << 3)
+#define TTBR0_RGN_WB (3 << 3)
+/* TTBR0[6] is IRGN[0] and TTBR[0] is IRGN[1] */
+#define TTBR0_IRGN_NC (0 << 0 | 0 << 6)
+#define TTBR0_IRGN_WBWA(0 << 0 | 1 << 6)
+#define TTBR0_IRGN_WT (1 << 0 | 0 << 6)
+#define TTBR0_IRGN_WB (1 << 0 | 1 << 6)
+#endif
+
/**
* Change the cache settings for a region.
*
diff --git a/arch/arm/lib/cache-cp15.c b/arch/arm/lib/cache-cp15.c
index 0291afa..c65e068 100644
--- a/arch/arm/lib/cache-cp15.c
+++ b/arch/arm/lib/cache-cp15.c
@@ -96,9 +96,23 @@ static inline void mmu_setup(void)
dram_bank_mmu_setup(i);
}
+#ifdef CONFIG_ARMV7
+ /* Set TTBR0 */
+ reg = gd->arch.tlb_addr & TTBR0_BASE_ADDR_MASK;
+#if defined(CONFIG_SYS_ARM_CACHE_WRITETHROUGH)
+ reg |= TTBR0_RGN_WT | TTBR0_IRGN_WT;
+#elif defined(CONFIG_SYS_ARM_CACHE_WRITEALLOC)
+ reg |= TTBR0_RGN_WBWA | TTBR0_IRGN_WBWA;
+#else
+ reg |= TTBR0_RGN_WB | TTBR0_IRGN_WB;
+#endif
+ asm volatile("mcr p15, 0, %0, c2, c0, 0"
+: : "r" (reg) : "memory");
+#else
/* Copy the page table address to cp15 */
asm volatile("mcr p15, 0, %0, c2, c0, 0"
: : "r" (gd->arch.tlb_addr) : "memory");
+#endif
/* Set the access control to all-supervisor */
asm volatile("mcr p15, 0, %0, c3, c0, 0"
: : "r" (~0));
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot: OpenRD Ultimate fails to build
I have a couple of ShevaPlugs, one OpenRD Base and one OpenRD Ultimate. If you’ll guide me thru the process, I’ll be glad to help with testing. The ShevaPlugs are currently idle, while the Base and Ultimate are occupied doing useful work. So I’d prefer to start with the SheevaPlugs if that’s OK with you. Rick On Apr 3, 2015, at 2:46 PM, Vagrant Cascadian wrote: > On 2015-03-25, drEagle wrote: >> Le 21/03/2015 15:53, Vagrant Cascadian a écrit : >>> It seems that OpenRD Ultimate with u-boot 2015.04-rc3 and newer no >>> longer builds from source, both in Debian and with mainline git. It >>> appears to have overgrown the size limits set for it: >> >> Looks like the NAND partition map had to be changed to give more space for >> u-boot. > > The following patch gets it to build by moving the env addr and offset > later. This might cause problems with new or existing u-boot > installations on openrd if the environment needs to be at a specific > location. I have no hardware to test, so no way of confirming this > directly: > > diff --git a/include/configs/openrd.h b/include/configs/openrd.h > index b6f80af..2f1e174 100644 > --- a/include/configs/openrd.h > +++ b/include/configs/openrd.h > @@ -72,12 +72,12 @@ > /* > * max 4k env size is enough, but in case of nand > * it has to be rounded to sector size > */ > #define CONFIG_ENV_SIZE 0x2 /* 128k */ > -#define CONFIG_ENV_ADDR 0x6 > -#define CONFIG_ENV_OFFSET0x6 /* env starts here */ > +#define CONFIG_ENV_ADDR 0x8 > +#define CONFIG_ENV_OFFSET0x8 /* env starts here */ > /* > * Environment is right behind U-Boot in flash. Make sure U-Boot > * doesn't grow into the environment area. > */ > #define CONFIG_BOARD_SIZE_LIMIT CONFIG_ENV_OFFSET > > > I'll likely remove openrd_ultimate from future uploads to Debian if I > can't get confirmation about how to fix this properly. > > > live well, > vagrant ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Including support for PowerPC-based Linkstations/Kuroboxes?
Hi.
I have a Kurobox HG, which is an embedded PowerPC NAS, and I am running a
very old binary of u-boot. This binary was precompiled and I took it from
http://downloads.buffalo.nas-central.org/LSHG_PPC/Bootloader/Uboot/Precompiled/obsolete/u-boot-hg.flash.bin
(If I'm not mistaken---it's been quite some time).
This corresponds to a patched u-boot 1.1.4, which is almost 10 years old.
The source code with instructions is at:
http://www.linuxnotincluded.pwp.blueyonder.co.uk/linkstation/u-boot.html
In particular, the interesting part is the patch:
http://www.linuxnotincluded.pwp.blueyonder.co.uk/linkstation/downloads/u-boot-1.1.4-list-2.1.0.diff.gz
Now, my question: would this be accepted to be integrated into upstream
u-boot?
If so, what would be the necessary steps? I know little about low-level
programming, but I am willing to learn and, also, to test everything on my
own Kurobox (in fact, I have two: one which is a Kurobox HD and another that
is a Kurobox HG; they are mostly the same, except for the HG, which has a
gigabit ethernet).
One of my goals would be to add support to Debian for it to be installed on
such machines (I already run Debian on them, but the process was too manual
and I want to automate everything and put as much as possible of the work in
the distribution).
Thanks in advance for any help,
Rogério Brito.
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Basic A33 support including dram init available in my personal repo
Hi, On 06-04-15 12:48, Vishnu Patekar wrote: Hello Hans, I wish I could have spent more time working on it. however, I could not. No problem, thanks for the initial code, and I'm happy to hear that you've no objections against me taking over from you. Thanks for taking this up. You're welcome. Regards, Hans On Mon, Apr 6, 2015 at 2:46 PM, Hans de Goede wrote: Hi Vishnu, On 01-03-15 19:42, Vishnu Patekar wrote: Allwinner A33 tablets comes with the libdram binary, fortunately I've found the libdram code at https://github.com/realthunder/a33_bootloader/ tree/master/basic_loader/bsp/bsp_for_a67. I've integrated it with mainline u-boot, still lot to do to post it to upstream Basic A33 support including dram init available in my personal repo https://github.com/vishnupatekar/u-boot-sunxi/tree/a33-dram I could able to boot u-boot over fel, and get u-boot command prompt on microSD pins which are multiplexed with UART0. The device page for A33 tablet which I've is here: http://linux-sunxi.org/Softwinner_astar-rda Just a quick heads up that since I've some time to work on this now, and we've not seen any new code from you in a month, that I'm going to pick up your patches, clean them up and them submit them upstream. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] cmd_mem: cleanups, catch bad usage
On Wed 2015-04-01 13:50:41, Pavel Machek wrote:
> Currently, memtest will silently accept bad data. Perform error
> checking on user intput.
>
> Signed-off-by: Pavel Machek
Ping? Tom, noone replys here, can you take the patch?
> diff --git a/common/cmd_mem.c b/common/cmd_mem.c
> index bfca59e..e6623b0 100644
> --- a/common/cmd_mem.c
> +++ b/common/cmd_mem.c
> @@ -994,10 +994,10 @@ static int do_mem_mtest(cmd_tbl_t *cmdtp, int flag, int
> argc,
> {
> ulong start, end;
> vu_long *buf, *dummy;
> - int iteration_limit;
> + int iteration_limit = 0;
> int ret;
> ulong errs = 0; /* number of errors, or -1 if interrupted */
> - ulong pattern;
> + ulong pattern = 0;
> int iteration;
> #if defined(CONFIG_SYS_ALT_MEMTEST)
> const int alt_test = 1;
> @@ -1005,25 +1005,29 @@ static int do_mem_mtest(cmd_tbl_t *cmdtp, int flag,
> int argc,
> const int alt_test = 0;
> #endif
>
> + start = CONFIG_SYS_MEMTEST_START;
> + end = CONFIG_SYS_MEMTEST_END;
> +
> if (argc > 1)
> - start = simple_strtoul(argv[1], NULL, 16);
> - else
> - start = CONFIG_SYS_MEMTEST_START;
> + if (strict_strtoul(argv[1], 16, &start) < 0)
> + return CMD_RET_USAGE;
>
> if (argc > 2)
> - end = simple_strtoul(argv[2], NULL, 16);
> - else
> - end = CONFIG_SYS_MEMTEST_END;
> + if (strict_strtoul(argv[2], 16, &end) < 0)
> + return CMD_RET_USAGE;
>
> if (argc > 3)
> - pattern = (ulong)simple_strtoul(argv[3], NULL, 16);
> - else
> - pattern = 0;
> + if (strict_strtoul(argv[3], 16, &pattern) < 0)
> + return CMD_RET_USAGE;
>
> if (argc > 4)
> - iteration_limit = (ulong)simple_strtoul(argv[4], NULL, 16);
> - else
> - iteration_limit = 0;
> + if (strict_strtoul(argv[4], 16, &iteration_limit) < 0)
> + return CMD_RET_USAGE;
> +
> + if (end < start) {
> + printf("Refusing to do empty test\n");
> + return -1;
> + }
>
> printf("Testing %08x ... %08x:\n", (uint)start, (uint)end);
> debug("%s:%d: start %#08lx end %#08lx\n", __func__, __LINE__,
> @@ -1074,7 +1078,7 @@ static int do_mem_mtest(cmd_tbl_t *cmdtp, int flag, int
> argc,
> ret = errs != 0;
> }
>
> - return ret; /* not reached */
> + return ret;
> }
> #endif /* CONFIG_CMD_MEMTEST */
>
>
--
(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
[U-Boot] fix makefiles to respect DTC setting
Top-level Makefile has option to select dtc binary, but it is ignored due to bug in Makefile.lib. Fix it. Signed-off-by: Pavel Machek diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 13af604..8731fc6 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -275,7 +275,7 @@ $(obj)/%.dtb.S: $(obj)/%.dtb quiet_cmd_dtc = DTC $@ # Modified for U-Boot cmd_dtc = $(CPP) $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $< ; \ - dtc -O dtb -o $@ -b 0 \ + $(DTC) -O dtb -o $@ -b 0 \ -i $(dir $<) $(DTC_FLAGS) \ -d $(depfile).dtc.tmp $(dtc-tmp) ; \ cat $(depfile).pre.tmp $(depfile).dtc.tmp > $(depfile) -- (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] imx: ipu: fix occasional hang following disabling of channel
On Sat, Apr 4, 2015 at 7:52 AM, Liu Ying wrote: > Hi Tim, > > Does your code base contain this patch[1]? > It probably addressed the same issue you meet. > > [1] http://lists.denx.de/pipermail/u-boot/2014-February/174533.html > > Regards, > Liu Ying Liu, It certainly does not - this issue was encountered back on 2014-04. I was hoping you might have some knowledge of this one! I will re-test for this specific issue now that I am re-based on master. Thanks, Tim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] usb: hub: allow pgood_delay to be specified via env
Some USB devices break the spec and require longer warm-up times. Allow
the usb_pgood_delay env variable to override the calculated time.
I have encountered this specficically with several different sized/branded USB
sticks with VID:PID 058f:6387 (Alcor Micro Corp. Transcend JetFlash) where I
need to set usb_pgood_delay to 2000ms to make them detectable.
Signed-off-by: Tim Harvey
---
common/usb_hub.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/common/usb_hub.c b/common/usb_hub.c
index 66b4a72..a0ef058 100644
--- a/common/usb_hub.c
+++ b/common/usb_hub.c
@@ -86,6 +86,7 @@ static void usb_hub_power_on(struct usb_hub_device *hub)
int i;
struct usb_device *dev;
unsigned pgood_delay = hub->desc.bPwrOn2PwrGood * 2;
+ const char *env;
dev = hub->pusb_dev;
@@ -98,7 +99,13 @@ static void usb_hub_power_on(struct usb_hub_device *hub)
/*
* Wait for power to become stable,
* plus spec-defined max time for device to connect
+* but allow this time to be increased via env variable as some
+* devices break the spec and require longer warm-up times
*/
+ env = getenv("usb_pgood_delay");
+ if (env)
+ pgood_delay = max(pgood_delay, simple_strtol(env, NULL, 0));
+ debug("pgood_delay=%dms\n", pgood_delay);
mdelay(pgood_delay + 1000);
}
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] fdt: add new fdt_fixup_display function to configure display
Add 'fdt_fixup_display' function to fixup device-tree for a specific
display. This is useful if a device-tree has configurations for multiple
display timings for undetectable displays.
Signed-off-by: Tim Harvey
---
common/fdt_support.c | 31 +++
include/fdt_support.h | 1 +
2 files changed, 32 insertions(+)
diff --git a/common/fdt_support.c b/common/fdt_support.c
index 8266bca..60609e5 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -1560,3 +1560,34 @@ int fdt_setup_simplefb_node(void *fdt, int node, u64
base_address, u32 width,
return 0;
}
+
+/*
+ * Update native-mode in display-timings from display environment variable.
+ * The node to update are specified by path.
+ */
+int fdt_fixup_display(void *blob, const char *path, const char *display)
+{
+ int off, toff;
+
+ if (!display || !path)
+ return -1;
+
+ toff = fdt_path_offset(blob, path);
+ if (toff >= 0)
+ toff = fdt_subnode_offset(blob, toff, "display-timings");
+ if (toff < 0)
+ return toff;
+
+ for (off = fdt_first_subnode(blob, toff);
+off >= 0;
+off = fdt_next_subnode(blob, off)) {
+ uint32_t handle = fdt_get_phandle(blob, off);
+ debug("%s:0x%x\n", fdt_get_name(blob, off, NULL),
+ fdt32_to_cpu(handle));
+ if (strcasecmp(fdt_get_name(blob, off, NULL), display) == 0) {
+ fdt_setprop_u32(blob, toff, "native-mode", handle);
+ break;
+ }
+ }
+ return toff;
+}
diff --git a/include/fdt_support.h b/include/fdt_support.h
index ae5e8a3..98379d3 100644
--- a/include/fdt_support.h
+++ b/include/fdt_support.h
@@ -46,6 +46,7 @@ void fdt_fixup_ethernet(void *fdt);
int fdt_find_and_setprop(void *fdt, const char *node, const char *prop,
const void *val, int len, int create);
void fdt_fixup_qe_firmware(void *fdt);
+int fdt_fixup_display(void *blob, const char *path, const char *display);
#if defined(CONFIG_HAS_FSL_DR_USB) || defined(CONFIG_HAS_FSL_MPH_USB)
void fdt_fixup_dr_usb(void *blob, bd_t *bd);
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] ubi/ubifs support for generic 'ls' and 'fsload' commands (CMD_FS_GENERIC)?
Stephen, Has anyone attempted to add generic fs support for ubi/ubifs to your knowledge? Regards, Tim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mx53loco: Disable printing cpuinfo
Since commit 32df39c741788e ("mx5: fix get_reset_cause") we have the following
boot messages on a mx53qsb:
U-Boot 2015.04-rc5-00029-gd68df02 (Apr 06 2015 - 11:15:39)
CPU: Freescale i.MX53 rev2.1 at 800 MHz
Reset cause: POR
Board: MX53 LOCO
I2C: ready
DRAM: 1 GiB
MMC: FSL_SDHC: 0, FSL_SDHC: 1
In:serial
Out: serial
Err: serial
CPU: Freescale i.MX53 rev2.1 at 1000 MHz
Reset cause: unknown reset
Net: FEC [PRIME]
The CPU and Reset cause lines appear twice.
Initially mx53 boots at 800MHz, then at a later point the PMIC is configured via
I2C to raise the CPU voltage so that it can run at 1GHz.
To avoid such misleading double printings, disable printing cpu info for now.
Signed-off-by: Fabio Estevam
---
board/freescale/mx53loco/mx53loco.c | 1 -
include/configs/mx53loco.h | 2 --
2 files changed, 3 deletions(-)
diff --git a/board/freescale/mx53loco/mx53loco.c
b/board/freescale/mx53loco/mx53loco.c
index 9ece6ec..1298788 100644
--- a/board/freescale/mx53loco/mx53loco.c
+++ b/board/freescale/mx53loco/mx53loco.c
@@ -389,7 +389,6 @@ int board_late_init(void)
{
if (!power_init())
clock_1GHz();
- print_cpuinfo();
return 0;
}
diff --git a/include/configs/mx53loco.h b/include/configs/mx53loco.h
index 8f92234..3551e02 100644
--- a/include/configs/mx53loco.h
+++ b/include/configs/mx53loco.h
@@ -24,8 +24,6 @@
#define CONFIG_SYS_GENERIC_BOARD
-#define CONFIG_DISPLAY_CPUINFO
-
/* Size of malloc() pool */
#define CONFIG_SYS_MALLOC_LEN (10 * 1024 * 1024)
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] printf("%d") breaks u-boot 2015.01+
Hi!
In u-boot 2015.04-rc, as soon as execution hits printf("%d"), it
hangs. (Usually, that's after "DRAM: " message).
Now, I have to admit I'm chainloading u-boot from
U-Boot 2013.01.01 (Mar 25 2015 - 15:57:21)
tftp 0x0140 .../u-boot.bin
Waiting for PHY auto negotiation to complete.. done
ENET Speed is 100 Mbps - FULL duplex connection
Using mii0 device
TFTP from server 10.0.0.6; our IP address is 10.0.0.99
...
Bytes transferred = 325004 (4f58c hex)
# go 0x0140
...but that worked well for 2014.10, (and is nearly mandatory in my
config).
I'm using cross-compiler from eldk-5.6, but eldk-5.4 crosscompiler
produces same behaviour, and both seem to work for 2014.10.
Any ideas?
Thanks,
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 v2 0/80] dm: Add USB support
On Monday, April 06, 2015 at 01:38:13 AM, Simon Glass wrote: > Hi Marek, Hi Simon, > On 26 March 2015 at 13:40, Marek Vasut wrote: > > On Wednesday, March 25, 2015 at 07:21:48 PM, Simon Glass wrote: > >> This series adds driver model support to USB. The intent is to permit > >> the various subsystems (OHCI, EHCI, XHCI) to co-exist and allow any > >> number of USB ports of different types. > >> > >> With the RFC series, only USB controllers had a real driver model > >> device. USB devices (including the hub in the controller) were not > >> modelled as driver model devices. > >> > >> While this was expedient, and produced much fewer patches, it is not a > >> long-term solution. Also, since then, driver model Ethernet support > >> (which USB can use) has been merged to u-boot-dm/next. It seems better > >> to bite the bullet and do a full conversion. > > > > Whew. > > > > Reviewed-by: Marek Vasut > > Thanks very much for working through these! > > Unless there are other comments I plan to apply this to u-boot-dm/next > in the next few days. I expect it will need some tweaking as boards > are moved over too. Please apply, I'm really looking forward to this. Thank you very much for putting all the effort into this ! 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] usb: hub: allow pgood_delay to be specified via env
On Monday, April 06, 2015 at 04:05:07 PM, Tim Harvey wrote: > Some USB devices break the spec and require longer warm-up times. Allow > the usb_pgood_delay env variable to override the calculated time. > > I have encountered this specficically with several different sized/branded > USB sticks with VID:PID 058f:6387 (Alcor Micro Corp. Transcend JetFlash) > where I need to set usb_pgood_delay to 2000ms to make them detectable. > > Signed-off-by: Tim Harvey Hi! this looks like a good idea. I have a hint for improvement -- in case you get a timeout waiting for the device to be detected, maybe the error message should mention that you can try setting this env variable and try again ? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] printf("%d") breaks u-boot 2015.01+
On Monday, April 06, 2015 at 04:40:09 PM, Pavel Machek wrote:
> Hi!
>
> In u-boot 2015.04-rc, as soon as execution hits printf("%d"), it
> hangs. (Usually, that's after "DRAM: " message).
printf("%d") expects an argument, so could it be that it touches
random piece of memory and thus hangs?
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] iMX: Fix compilation error when enabling SECURE_BOOT
Hi Gaurav, On 4/6/15 2:35 AM, Gaurav Rana wrote: Move the compilation of file fsl_validate.c in MACRO CONFIG_CMD_ESBC_VALIDATE. This file should be compiled only when the above MACRO is defined This caused a break in compilation of iMX platforms when compiling for SECURE_BOOT Signed-off-by: Gaurav Rana --- Changes in V2: Corrected the commit message. board/freescale/common/Makefile | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/board/freescale/common/Makefile b/board/freescale/common/Makefile index 7181cac..87d0578 100644 --- a/board/freescale/common/Makefile +++ b/board/freescale/common/Makefile @@ -74,8 +74,7 @@ obj-$(CONFIG_P5040DS) += p_corenet/ obj-$(CONFIG_LS102XA_NS_ACCESS) += ns_access.o ifdef CONFIG_SECURE_BOOT -obj-y += fsl_validate.o -obj-$(CONFIG_CMD_ESBC_VALIDATE) += cmd_esbc_validate.o +obj-$(CONFIG_CMD_ESBC_VALIDATE) += fsl_validate.o cmd_esbc_validate.o endif endif This fixes the issue. Tested on iMX6q and iMX6sx. Regards, Ulises Cardenas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers:usb:fsl: Implement Erratum A-009116 for XHCI controller
On Monday, April 06, 2015 at 10:59:09 AM, nikhil.bad...@freescale.com wrote: > > -Original Message- > > From: Marek Vasut [mailto:ma...@denx.de] > > Sent: Thursday, April 02, 2015 10:32 PM > > To: Badola Nikhil-B46172 > > Cc: u-boot@lists.denx.de > > Subject: Re: [PATCH] drivers:usb:fsl: Implement Erratum A-009116 for XHCI > > controller > > > > On Friday, March 27, 2015 at 04:47:54 AM, Nikhil Badola wrote: > > > This adjusts (micro)frame length to appropriate value thus avoiding > > > USB devices to time out over a longer run > > > > > > Signed-off-by: Nikhil Badola > > > > Hi, > > > > it seems the XHCI driver from Freescale was never applied, since no > > maintainer was ever in CC and there was no effort from the author to > > contact anyone after sending it out. That's rather unfortunate. > > Freescale XHCI driver's author is already talking with HW teams to see if > there's some PHY shutdown sequence available for FSL socs...hence the > delay. Hi, OK. > > I briefly reviewed the driver which you linked and it seems like it is > > almost exact copy of the xhci-omap.c . We certainly don't want this > > level of code duplication. > > I agree with the fact that code duplication should be minimized. However > the driver for same controller would follow same initialization > steps...until an effort is made in open-source by someone to write a > single driver file with common initialization code, this code will keep > getting duplicated. I agree. I won't allow such explicitly duplicated code in, so it's up to you to do the deduplication. Thanks :) > > Would it be possible for you to pick up that driver, work your change > > into it, avoid the code duplication and repost the whole thing please ? > > > > Best regards, > > Marek Vasut 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] ARM: bcm2835: use phys_to_bus() for mbox
On Sunday, April 05, 2015 at 04:48:24 AM, Stephen Warren wrote: > When we communicate with the VideoCore to perform property mailbox > transactions, that is a DMA operation as far as the property buffer > is concerned. Use phys_to_bus() on that buffer. > > Signed-off-by: Stephen Warren > --- > While this isn't USB-related, it does depend on patches that went into > the USB topic/dwc2 tree. Either this can be merged there, or we'll have > to wait until that branch is merged into u-boot/master and then merge > this. > > As best I can tell, this is the last place we need to do this. SDHCI has > potential but CONFIG_MMC_SDMA isn't set so I don't believe the code does > any DMA. LCD has potential, but the VideoCore allocates the display > surface, programs the display engine, and passes the surface's CPU pointer > back to the CPU in a firmware message, of U-Boot isn't involved in setting > up the DMA HW. > --- > arch/arm/cpu/arm1176/bcm2835/mbox.c | 5 +++-- I don't mind picking this up, but please rebase on top of u-boot/master, which contains d6c418e4b8036038505ac67bf5d85a19ca2c650d . 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] [PATCH v3 1/3] usb: usb_new_device return codes consistency
On Saturday, April 04, 2015 at 03:12:27 PM, Paul Kocialkowski wrote: > This makes use of errno return codes for representing error codes in a > unified way. > > Signed-off-by: Paul Kocialkowski Applied all three to u-boot-usb/next . 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] Regarding patch: http://patchwork.ozlabs.org/patch/373593/
On Monday, April 06, 2015 at 10:58:30 AM, Ramneek Mehresh wrote: [...] > > > > The static void fsl_xhci_core_exit(struct fsl_xhci *fsl_xhci) must > > > > shut down the controller, which I don't see happening. Why? > > > > > > I could not locate any such requirement in IP documentation. Have > > > contacted local IP/PHY team for the same. Waiting for response from > > > them > > > > This is needed, so you don't start Linux with a running USB controller. > > xhci controller is already stopped in > usb_stop->usb_lowlevel_stop->xhci_reset(). I could see CMD_RUN bit getting > reset in this function before the controller is reset. So, from your > previously stated requirement, controller is halted when Linux is started. > > Other people are shutting down PHY as part of xhci_core_exit(), not the > controller!! We would not like to re-start and re-configure PHY inside > Linux, and take phy initialization inside bootloader. I got word from hw > team that they do not support phy shutting down from sw. hence, we do not > have any sequence for current socs to shut down phy from sw. if required, > I'll put forward a request to provide this control in future socs. Hi, Is this similar hardware bug to the one which MX6 PCIe is suffering ? On MX6, the bug is that you cannot reset the PCIe and PCIe PHY from software, which means that if you start PCIe in U-Boot, you cannot reliably use it in Linux. Furthermore, if you reset the MX6 via WDT, you cannot start PCIe reliably in Linux even if PCIe is not used in U-Boot at all. Is this the same type of hardware screwup where the design team didn't think reset was necessary? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ubi/ubifs support for generic 'ls' and 'fsload' commands (CMD_FS_GENERIC)?
On 04/06/2015 08:18 AM, Tim Harvey wrote: Stephen, Has anyone attempted to add generic fs support for ubi/ubifs to your knowledge? Not that I'm aware of. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] ARM: mx6: Enable ARM errata workaround for 845369
From: Nitin Garg Since MX6 is Cortex-A9 r2p10, enable software workaround for errata 845369. The ARM errata 751472, 794072, 761320, 845369 only applied to the following configuration: This erratum affects configurations with either: - One processor if the ACP is present - Two or more processors i.MX6 family does not have the ACP and thus only the MPCore system will be impacted, which are the i.MX6DQ, i.MX6DL. Signed-off-by: Nitin Garg --- Changes in v2: Apply 751472, 794072, 761320, 845369 to i.MX6DQ, i.MX6DL only. include/configs/mx6_common.h |4 1 file changed, 4 insertions(+) diff --git a/include/configs/mx6_common.h b/include/configs/mx6_common.h index e0528ce..cc6b03e 100644 --- a/include/configs/mx6_common.h +++ b/include/configs/mx6_common.h @@ -18,9 +18,13 @@ #define __MX6_COMMON_H #define CONFIG_ARM_ERRATA_743622 +#if (defined(CONFIG_MX6Q) || defined(CONFIG_MX6DL) ||\ +defined(CONFIG_MX6QDL)) && !defined(CONFIG_MX6S) #define CONFIG_ARM_ERRATA_751472 #define CONFIG_ARM_ERRATA_794072 #define CONFIG_ARM_ERRATA_761320 +#define CONFIG_ARM_ERRATA_845369 +#endif #define CONFIG_BOARD_POSTCLK_INIT #ifndef CONFIG_SYS_L2CACHE_OFF -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] printf("%d") breaks u-boot 2015.01+
On Mon 2015-04-06 16:59:55, Marek Vasut wrote:
> On Monday, April 06, 2015 at 04:40:09 PM, Pavel Machek wrote:
> > Hi!
> >
> > In u-boot 2015.04-rc, as soon as execution hits printf("%d"), it
> > hangs. (Usually, that's after "DRAM: " message).
>
> printf("%d") expects an argument, so could it be that it touches
> random piece of memory and thus hangs?
It had an argument, sorry for confusion. I was actually doing this:
the test with %s works, the one with %d kills it.
I suspect too small stack...?
Pavel
int dram_init(void)
{
printf("dram init: print size\n");
- // printf("printf test: %x\n", 0x12345678);
- // printf("dram_init... %x\n", PHYS_SDRAM_1_SIZE);
- gd->ram_size = PHYS_SDRAM_1_SIZE /2; //get_ram_size((long *)PHYS_SDRAM_1,
PHYS_SDRAM_1_SIZE);
+ printf("printf test: %x\n", 0x12345678);
+ printf("dram_init... %x\n", PHYS_SDRAM_1_SIZE);
+ gd->ram_size = get_ram_size((long *)PHYS_SDRAM_1,
PHYS_SDRAM_1_SIZE);
printf("dram init: ram size set\n");
return 0;
}
@@ -108,6 +108,9 @@ int cpu_mmc_init(bd_t *bis)
int print_cpuinfo(void)
{
puts("CPU: Altera SoCFPGA Platform\n");
+ printf("printf test string: %s\n", "ahoj");
+ printf("printf test: %d\n", 1234567);
+ printf("printf test: %x\n", 0x12345678);
return 0;
}
--
(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 v2] ARM: mx6: Enable ARM errata workaround for 845369
Hi Nitin, On Mon, Apr 6, 2015 at 3:08 PM, wrote: > #define CONFIG_ARM_ERRATA_743622 > +#if (defined(CONFIG_MX6Q) || defined(CONFIG_MX6DL) ||\ > +defined(CONFIG_MX6QDL)) && !defined(CONFIG_MX6S) > #define CONFIG_ARM_ERRATA_751472 > #define CONFIG_ARM_ERRATA_794072 > #define CONFIG_ARM_ERRATA_761320 > +#define CONFIG_ARM_ERRATA_845369 > +#endif > #define CONFIG_BOARD_POSTCLK_INIT This patch should be split in two: - One that only applies the existing errata to multi-core - One that adds CONFIG_ARM_ERRATA_845369. Also, I would expect to see this patch as part of a series that introduces CONFIG_ARM_ERRATA_845369. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: mx6: Fix errata workarounds for i.MX6
From: Nitin Garg Since MX6 is Cortex-A9 r2p10, enable ARM errata 751472, 794072, 761320 only applied to the following configuration: This erratum affects configurations with either: - One processor if the ACP is present - Two or more processors i.MX6 family does not have the ACP and thus only the MPCore system will be impacted, which are the i.MX6DQ, i.MX6DL. Signed-off-by: Nitin Garg --- include/configs/mx6_common.h |3 +++ 1 file changed, 3 insertions(+) diff --git a/include/configs/mx6_common.h b/include/configs/mx6_common.h index e0528ce..e22336e 100644 --- a/include/configs/mx6_common.h +++ b/include/configs/mx6_common.h @@ -18,9 +18,12 @@ #define __MX6_COMMON_H #define CONFIG_ARM_ERRATA_743622 +#if (defined(CONFIG_MX6Q) || defined(CONFIG_MX6DL) ||\ +defined(CONFIG_MX6QDL)) && !defined(CONFIG_MX6S) #define CONFIG_ARM_ERRATA_751472 #define CONFIG_ARM_ERRATA_794072 #define CONFIG_ARM_ERRATA_761320 +#endif #define CONFIG_BOARD_POSTCLK_INIT #ifndef CONFIG_SYS_L2CACHE_OFF -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] printf("%d") breaks u-boot 2015.01+
On Monday, April 06, 2015 at 08:14:44 PM, Pavel Machek wrote:
> On Mon 2015-04-06 16:59:55, Marek Vasut wrote:
> > On Monday, April 06, 2015 at 04:40:09 PM, Pavel Machek wrote:
> > > Hi!
> > >
> > > In u-boot 2015.04-rc, as soon as execution hits printf("%d"), it
> > > hangs. (Usually, that's after "DRAM: " message).
> >
> > printf("%d") expects an argument, so could it be that it touches
> > random piece of memory and thus hangs?
>
> It had an argument, sorry for confusion. I was actually doing this:
> the test with %s works, the one with %d kills it.
>
> I suspect too small stack...?
Does this happen in the SPL ? You can check the stack placement and
utilization with BDI to verigy your hypothesis.
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/2] ARM: Add workaround for Cortex-A9 errata 845369
From: Nitin Garg Under very rare timing circumstances, transition into streaming mode might create a data corruption. Exists on all Cortex-A9 revisions. Signed-off-by: Nitin Garg --- Changes in v3: None Changes in v2: None README |1 + arch/arm/cpu/armv7/start.S |5 + 2 files changed, 6 insertions(+) diff --git a/README b/README index b7c2a17..8976041 100644 --- a/README +++ b/README @@ -683,6 +683,7 @@ The following options need to be configured: CONFIG_ARM_ERRATA_751472 CONFIG_ARM_ERRATA_794072 CONFIG_ARM_ERRATA_761320 + CONFIG_ARM_ERRATA_845369 If set, the workarounds for these ARM errata are applied early during U-Boot startup. Note that these options force the diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S index 5ed0f45..db77adb 100644 --- a/arch/arm/cpu/armv7/start.S +++ b/arch/arm/cpu/armv7/start.S @@ -164,6 +164,11 @@ ENTRY(cpu_init_cp15) orr r0, r0, #1 << 21@ set bit #21 mcr p15, 0, r0, c15, c0, 1 @ write diagnostic register #endif +#ifdef CONFIG_ARM_ERRATA_845369 + mrc p15, 0, r0, c15, c0, 1 @ read diagnostic register + orr r0, r0, #1 << 22@ set bit #22 + mcr p15, 0, r0, c15, c0, 1 @ write diagnostic register +#endif mov r5, lr @ Store my Caller mrc p15, 0, r1, c0, c0, 0 @ r1 has Read Main ID Register (MIDR) -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 3/3] ARM: mx6: Enable ARM errata workaround for 845369
From: Nitin Garg The ARM errata 845369 only applies to one processor if the ACP is present OR two or more processors. i.MX6 family does not have the ACP and thus only the MPCore system will be impacted, which are the i.MX6DQ, i.MX6DL. Signed-off-by: Nitin Garg --- Changes in v3: Split the patch as suggested by Fabio. Changes in v2: Apply 751472, 794072, 761320, 845369 to i.MX6DQ, i.MX6DL only. include/configs/mx6_common.h |1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/mx6_common.h b/include/configs/mx6_common.h index e22336e..cc6b03e 100644 --- a/include/configs/mx6_common.h +++ b/include/configs/mx6_common.h @@ -23,6 +23,7 @@ defined(CONFIG_MX6QDL)) && !defined(CONFIG_MX6S) #define CONFIG_ARM_ERRATA_751472 #define CONFIG_ARM_ERRATA_794072 #define CONFIG_ARM_ERRATA_761320 +#define CONFIG_ARM_ERRATA_845369 #endif #define CONFIG_BOARD_POSTCLK_INIT -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/3] ARM: Add workaround for Cortex-A9 errata 845369
From: Nitin Garg Under very rare timing circumstances, transition into streaming mode might create a data corruption. Exists on all Cortex-A9 revisions. Signed-off-by: Nitin Garg --- Changes in v3: None Changes in v2: None README |1 + arch/arm/cpu/armv7/start.S |5 + 2 files changed, 6 insertions(+) diff --git a/README b/README index b7c2a17..8976041 100644 --- a/README +++ b/README @@ -683,6 +683,7 @@ The following options need to be configured: CONFIG_ARM_ERRATA_751472 CONFIG_ARM_ERRATA_794072 CONFIG_ARM_ERRATA_761320 + CONFIG_ARM_ERRATA_845369 If set, the workarounds for these ARM errata are applied early during U-Boot startup. Note that these options force the diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S index 5ed0f45..db77adb 100644 --- a/arch/arm/cpu/armv7/start.S +++ b/arch/arm/cpu/armv7/start.S @@ -164,6 +164,11 @@ ENTRY(cpu_init_cp15) orr r0, r0, #1 << 21@ set bit #21 mcr p15, 0, r0, c15, c0, 1 @ write diagnostic register #endif +#ifdef CONFIG_ARM_ERRATA_845369 + mrc p15, 0, r0, c15, c0, 1 @ read diagnostic register + orr r0, r0, #1 << 22@ set bit #22 + mcr p15, 0, r0, c15, c0, 1 @ write diagnostic register +#endif mov r5, lr @ Store my Caller mrc p15, 0, r1, c0, c0, 0 @ r1 has Read Main ID Register (MIDR) -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/3] ARM: mx6: Fix errata workarounds for i.MX6
From: Nitin Garg Since MX6 is Cortex-A9 r2p10, enable ARM errata 751472, 794072, 761320 only applied to the following configuration: This erratum affects configurations with either: - One processor if the ACP is present - Two or more processors i.MX6 family does not have the ACP and thus only the MPCore system will be impacted, which are the i.MX6DQ, i.MX6DL. Signed-off-by: Nitin Garg --- Changes in v3: Split the patch as suggested by Fabio. Changes in v2: None include/configs/mx6_common.h |3 +++ 1 file changed, 3 insertions(+) diff --git a/include/configs/mx6_common.h b/include/configs/mx6_common.h index e0528ce..e22336e 100644 --- a/include/configs/mx6_common.h +++ b/include/configs/mx6_common.h @@ -18,9 +18,12 @@ #define __MX6_COMMON_H #define CONFIG_ARM_ERRATA_743622 +#if (defined(CONFIG_MX6Q) || defined(CONFIG_MX6DL) ||\ +defined(CONFIG_MX6QDL)) && !defined(CONFIG_MX6S) #define CONFIG_ARM_ERRATA_751472 #define CONFIG_ARM_ERRATA_794072 #define CONFIG_ARM_ERRATA_761320 +#endif #define CONFIG_BOARD_POSTCLK_INIT #ifndef CONFIG_SYS_L2CACHE_OFF -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/2] ARM: mx6: Enable ARM errata workaround for 845369
From: Nitin Garg The ARM errata 845369 only applies to one processor if the ACP is present OR two or more processors. i.MX6 family does not have the ACP and thus only the MPCore system will be impacted, which are the i.MX6DQ, i.MX6DL. Signed-off-by: Nitin Garg --- Changes in v3: Split the patch as suggested by Fabio. Changes in v2: Apply 751472, 794072, 761320, 845369 to i.MX6DQ, i.MX6DL only. include/configs/mx6_common.h |1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/mx6_common.h b/include/configs/mx6_common.h index e22336e..cc6b03e 100644 --- a/include/configs/mx6_common.h +++ b/include/configs/mx6_common.h @@ -23,6 +23,7 @@ defined(CONFIG_MX6QDL)) && !defined(CONFIG_MX6S) #define CONFIG_ARM_ERRATA_751472 #define CONFIG_ARM_ERRATA_794072 #define CONFIG_ARM_ERRATA_761320 +#define CONFIG_ARM_ERRATA_845369 #endif #define CONFIG_BOARD_POSTCLK_INIT -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] printf("%d") breaks u-boot 2015.01+
On Mon 2015-04-06 20:48:45, Marek Vasut wrote:
> On Monday, April 06, 2015 at 08:14:44 PM, Pavel Machek wrote:
> > On Mon 2015-04-06 16:59:55, Marek Vasut wrote:
> > > On Monday, April 06, 2015 at 04:40:09 PM, Pavel Machek wrote:
> > > > Hi!
> > > >
> > > > In u-boot 2015.04-rc, as soon as execution hits printf("%d"), it
> > > > hangs. (Usually, that's after "DRAM: " message).
> > >
> > > printf("%d") expects an argument, so could it be that it touches
> > > random piece of memory and thus hangs?
> >
> > It had an argument, sorry for confusion. I was actually doing this:
> > the test with %s works, the one with %d kills it.
> >
> > I suspect too small stack...?
>
> Does this happen in the SPL ? You can check the stack placement and
> utilization with BDI to verigy your hypothesis.
No, this is u-boot proper, and I'm chainloading it (see first mail) --
so unsupported configuration.
I'm preparing to flash the u-boot into the NOR, that should tell us if
it is chainloading problem or not.
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 0/23] net: cosmetic: Fix naming and other checkpatch.pl issues in net/
Hi Simon, On Fri, Apr 3, 2015 at 4:14 PM, Joe Hershberger wrote: > > This series is fairly disruptive in naming, so hopefully there aren't > many network stack changes in flight that will conflict with this. This > is based on top of dm/next for now so that the dm/eth series is assumed. > This will be rebased when that is, but will likely not have issues. > > Like ripping off a bandage, do it quick and all at once. It would be good if you can pull this in through dm/next if there are no oppositions, since this depends on that tree and will be disruptive if left out for any amount of time. > Joe Hershberger (21): > net: cosmetic: Change IPaddr_t to struct in_addr > net: cosmetic: Fixup var names related to boot file > net: cosmetic: Fixup var names for DHCP strings > net: cosmetic: Name ethaddr variables consistently > net: cosmetic: Cleanup internal packet buffer names > net: cosmetic: Fix var naming net <-> eth drivers > net: cosmetic: Clean up TFTP variables and functions > net: cosmetic: Clean up ARP variables and functions > net: cosmetic: Clean up DHCP variables and functions > net: cosmetic: Clean up NFS variables and functions > net: cosmetic: Clean up RARP variables and functions > net: cosmetic: Clean up SNTP variables and functions > net: cosmetic: Clean up ping variables and functions > net: cosmetic: Clean up CDP variables and functions > net: cosmetic: Clean up DNS variables and functions > net: cosmetic: Clean up netconsole variables and functions > net: cosmetic: Clean up cmd_net variables and functions > net: cosmetic: Fix checkpatch.pl failures in linklocal > net: cosmetic: Fix checkpatch.pl failures in eth.c > net: cosmetic: Fix checkpatch.pl failures in net.h > net: cosmetic: Fix checkpatch.pl failures in net.c > > Sergey Temerkhanov (2): > net: Fix incorrect DHCP/BOOTP packets on 64-bit systems > net: Convert protocol structures to use explicit sizes > > README | 6 +- > arch/arm/mach-davinci/misc.c | 2 +- > arch/mips/mach-au1x00/au1x00_eth.c | 12 +- > arch/powerpc/cpu/mpc8260/ether_fcc.c | 20 +- > arch/powerpc/cpu/mpc8260/ether_scc.c | 4 +- > arch/powerpc/cpu/mpc85xx/ether_fcc.c | 4 +- > arch/powerpc/cpu/mpc8xx/fec.c | 12 +- > arch/powerpc/cpu/mpc8xx/scc.c | 5 +- > board/BuR/common/common.c | 4 +- > board/ait/cam_enc_4xx/cam_enc_4xx.c| 2 +- > board/alphaproject/ap_sh4a_4a/ap_sh4a_4a.c | 2 +- > board/bct-brettl2/bct-brettl2.c| 2 +- > board/bf518f-ezbrd/bf518f-ezbrd.c | 4 +- > board/bf526-ezbrd/bf526-ezbrd.c| 4 +- > board/bf527-ezkit/bf527-ezkit.c| 4 +- > board/bf537-minotaur/bf537-minotaur.c | 2 +- > board/bf537-pnav/bf537-pnav.c | 2 +- > board/bf537-srv1/bf537-srv1.c | 2 +- > board/bf537-stamp/bf537-stamp.c| 4 +- > board/birdland/bav335x/board.c | 4 +- > board/buffalo/lsxl/lsxl.c | 2 +- > board/cm-bf527/cm-bf527.c | 4 +- > board/cm-bf537e/cm-bf537e.c| 2 +- > board/cm-bf537u/cm-bf537u.c| 2 +- > board/compulab/cm_fx6/cm_fx6.c | 2 +- > board/compulab/cm_t335/cm_t335.c | 2 +- > board/compulab/cm_t35/cm_t35.c | 2 +- > board/compulab/cm_t3517/cm_t3517.c | 4 +- > board/compulab/cm_t54/cm_t54.c | 4 +- > board/davinci/da8xxevm/da850evm.c | 6 +- > board/dnp5370/dnp5370.c| 4 +- > board/gumstix/pepper/board.c | 2 +- > board/ifm/ac14xx/ac14xx.c | 2 +- > board/ip04/ip04.c | 2 +- > board/isee/igep0033/board.c| 2 +- > board/phytec/pcm051/board.c| 2 +- > board/renesas/r0p7734/r0p7734.c| 2 +- > board/siemens/common/factoryset.c | 4 +- > board/siemens/pxm2/board.c | 2 +- > board/silica/pengwyn/board.c | 2 +- > board/tcm-bf518/tcm-bf518.c| 4 +- > board/tcm-bf537/tcm-bf537.c| 2 +- > board/ti/am335x/board.c| 6 +- > board/ti/am43xx/board.c| 4 +- > board/ti/beagle_x15/board.c| 4 +- > board/ti/dra7xx/evm.c | 4 +- > board/ti/ti814x/evm.c | 2 +- > common/cmd_elf.c | 2 +- > common/cmd_net.c | 133 +++ > common/cmd_pxe.c | 4 +- > common/spl/spl_net.c | 2 +- > common/update.c| 25 +- > doc/README.drivers.eth | 12 +- > doc/README.enetaddr| 2 +- > doc/README.link-local | 4 +- > drivers/net
[U-Boot] [PATCH v2 3/8] sandbox: Add support for bootz
Add dummy bootz_setup implementation allowing the u-boot sandbox to
run bootz. This recognizes both ARM and x86 zImages to validate a
valid zImage was loaded.
Signed-off-by: Sjoerd Simons
---
Changes in v2:
- Move into sandbox/lib/bootm.c
- convert to u-boot coding style
- Remove unneeded cast
arch/sandbox/lib/bootm.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/sandbox/lib/bootm.c b/arch/sandbox/lib/bootm.c
index 8ddf4ef..25c5aa4 100644
--- a/arch/sandbox/lib/bootm.c
+++ b/arch/sandbox/lib/bootm.c
@@ -8,6 +8,25 @@
DECLARE_GLOBAL_DATA_PTR;
+int bootz_setup(ulong image, ulong *start, ulong *end)
+{
+ uint8_t *zimage = map_sysmem(image, 0);
+ uint8_t arm_magic[] = { 0x18, 0x28, 0x6f, 0x01 };
+
+ if (memcmp(zimage + 0x202, "HdrS", 4) == 0) {
+ printf("setting up x86 zImage\n");
+ } else if (memcmp(zimage + 0x24, arm_magic, 4) == 0) {
+ printf("setting up ARM zImage\n");
+ } else {
+ printf("Unrecognized zImage\n");
+ return 1;
+ }
+
+ *start = 0xdead;
+ *end = 0xbeef;
+ return 0;
+}
+
int do_bootm_linux(int flag, int argc, char *argv[], bootm_headers_t *images)
{
if (flag & (BOOTM_STATE_OS_GO | BOOTM_STATE_OS_FAKE_GO)) {
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 4/8] sandbox: Renamed sb command to host
As suggested by Simon Glass, rename the sb command to host but keep the
old sb command as an alias
Signed-off-by: Sjoerd Simons
---
Changes in v2: None
common/Makefile | 2 +-
common/{cmd_sandbox.c => cmd_host.c} | 49 +++-
2 files changed, 33 insertions(+), 18 deletions(-)
rename common/{cmd_sandbox.c => cmd_host.c} (62%)
diff --git a/common/Makefile b/common/Makefile
index 7216a13..ccb5b99 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -151,7 +151,7 @@ obj-$(CONFIG_CMD_PXE) += cmd_pxe.o
obj-$(CONFIG_CMD_READ) += cmd_read.o
obj-$(CONFIG_CMD_REGINFO) += cmd_reginfo.o
obj-$(CONFIG_CMD_REISER) += cmd_reiser.o
-obj-$(CONFIG_SANDBOX) += cmd_sandbox.o
+obj-$(CONFIG_SANDBOX) += cmd_host.o
obj-$(CONFIG_CMD_SATA) += cmd_sata.o
obj-$(CONFIG_CMD_SF) += cmd_sf.o
obj-$(CONFIG_CMD_SCSI) += cmd_scsi.o
diff --git a/common/cmd_sandbox.c b/common/cmd_host.c
similarity index 62%
rename from common/cmd_sandbox.c
rename to common/cmd_host.c
index 4286969..d8a0bea 100644
--- a/common/cmd_sandbox.c
+++ b/common/cmd_host.c
@@ -10,25 +10,25 @@
#include
#include
-static int do_sandbox_load(cmd_tbl_t *cmdtp, int flag, int argc,
+static int do_host_load(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
{
return do_load(cmdtp, flag, argc, argv, FS_TYPE_SANDBOX);
}
-static int do_sandbox_ls(cmd_tbl_t *cmdtp, int flag, int argc,
+static int do_host_ls(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
{
return do_ls(cmdtp, flag, argc, argv, FS_TYPE_SANDBOX);
}
-static int do_sandbox_save(cmd_tbl_t *cmdtp, int flag, int argc,
+static int do_host_save(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
{
return do_save(cmdtp, flag, argc, argv, FS_TYPE_SANDBOX);
}
-static int do_sandbox_bind(cmd_tbl_t *cmdtp, int flag, int argc,
+static int do_host_bind(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
{
if (argc < 2 || argc > 3)
@@ -44,7 +44,7 @@ static int do_sandbox_bind(cmd_tbl_t *cmdtp, int flag, int
argc,
return host_dev_bind(dev, file);
}
-static int do_sandbox_info(cmd_tbl_t *cmdtp, int flag, int argc,
+static int do_host_info(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
{
if (argc < 1 || argc > 2)
@@ -85,25 +85,25 @@ static int do_sandbox_info(cmd_tbl_t *cmdtp, int flag, int
argc,
return 0;
}
-static cmd_tbl_t cmd_sandbox_sub[] = {
- U_BOOT_CMD_MKENT(load, 7, 0, do_sandbox_load, "", ""),
- U_BOOT_CMD_MKENT(ls, 3, 0, do_sandbox_ls, "", ""),
- U_BOOT_CMD_MKENT(save, 6, 0, do_sandbox_save, "", ""),
- U_BOOT_CMD_MKENT(bind, 3, 0, do_sandbox_bind, "", ""),
- U_BOOT_CMD_MKENT(info, 3, 0, do_sandbox_info, "", ""),
+static cmd_tbl_t cmd_host_sub[] = {
+ U_BOOT_CMD_MKENT(load, 7, 0, do_host_load, "", ""),
+ U_BOOT_CMD_MKENT(ls, 3, 0, do_host_ls, "", ""),
+ U_BOOT_CMD_MKENT(save, 6, 0, do_host_save, "", ""),
+ U_BOOT_CMD_MKENT(bind, 3, 0, do_host_bind, "", ""),
+ U_BOOT_CMD_MKENT(info, 3, 0, do_host_info, "", ""),
};
-static int do_sandbox(cmd_tbl_t *cmdtp, int flag, int argc,
+static int do_host(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
{
cmd_tbl_t *c;
- /* Skip past 'sandbox' */
+ /* Skip past 'host' */
argc--;
argv++;
- c = find_cmd_tbl(argv[0], cmd_sandbox_sub,
-ARRAY_SIZE(cmd_sandbox_sub));
+ c = find_cmd_tbl(argv[0], cmd_host_sub,
+ARRAY_SIZE(cmd_host_sub));
if (c)
return c->cmd(cmdtp, flag, argc, argv);
@@ -112,8 +112,8 @@ static int do_sandbox(cmd_tbl_t *cmdtp, int flag, int argc,
}
U_BOOT_CMD(
- sb, 8, 1, do_sandbox,
- "Miscellaneous sandbox commands",
+ sb, 8, 1, do_host,
+ "Deprecated use host command instead - Miscellaneous sandbox commands",
"load hostfs - [ ] - "
"load a file from host\n"
"sb ls hostfs - - list files on host\n"
@@ -124,3 +124,18 @@ U_BOOT_CMD(
"sb commands use the \"hostfs\" device. The \"host\" device is used\n"
"with standard IO commands such as fatls or ext2load"
);
+
+U_BOOT_CMD(
+ host, 8, 1, do_host,
+ "Miscellaneous host commands",
+ "load hostfs - [ ] - "
+ "load a file from host\n"
+ "host ls hostfs - - list files on host\n"
+ "host save hostfs -[] - "
+ "save a file to host\n"
+ "host bind [] - bind \"host\" device to file\n"
+ "host info []- show device binding & info\n"
+ "host commands use the \"hostfs\" device. The \"host\" device is used\n"
+ "with standard IO commands such as fatls or ext2l
[U-Boot] [PATCH v2 8/8] sandbox: add config_distro_defaults and config_distro_bootcmd
Make the sandbox setup more generic/examplary by including
config_distro_defaults.h and config_distro_bootcmd.h.
Among other things this makes it easy to test whether images will boot
though with the standard distro bootcmds by running e.g:
u-boot -c 'host bind 0 myimage.img ; boot'
By default there are 2 target host devices to emulate device with
multiple storage devices (e.g. internal ("host 0") and external
("host 1") and verify that the prioritization and fallbacks do work
correctly.
Signed-off-by: Sjoerd Simons
Reviewed by: Simon Glass
---
Changes in v2: None
include/configs/sandbox.h | 29 ++---
1 file changed, 26 insertions(+), 3 deletions(-)
diff --git a/include/configs/sandbox.h b/include/configs/sandbox.h
index febbfb6..02c83cd 100644
--- a/include/configs/sandbox.h
+++ b/include/configs/sandbox.h
@@ -75,7 +75,6 @@
#define CONFIG_CMDLINE_EDITING
#define CONFIG_COMMAND_HISTORY
#define CONFIG_AUTO_COMPLETE
-#define CONFIG_BOOTDELAY 3
#define CONFIG_ENV_SIZE8192
#define CONFIG_ENV_IS_NOWHERE
@@ -125,10 +124,21 @@
/* include default commands */
#include
+#include
+
+#define BOOT_TARGET_DEVICES(func) \
+ func(HOST, host, 1) \
+ func(HOST, host, 0)
+
+#include
/* We don't have networking support yet */
#undef CONFIG_CMD_NET
#undef CONFIG_CMD_NFS
+#undef CONFIG_CMD_PING
+
+/* Can't boot elf images */
+#undef CONFIG_CMD_ELF
#define CONFIG_CMD_HASH
#define CONFIG_HASH_VERIFY
@@ -165,16 +175,29 @@
#define CONFIG_KEYBOARD
-#define CONFIG_EXTRA_ENV_SETTINGS "stdin=serial,cros-ec-keyb\0" \
+#define EXTRA_ENV_SETTINGS "stdin=serial,cros-ec-keyb\0" \
"stdout=serial,lcd\0" \
"stderr=serial,lcd\0"
#else
-#define CONFIG_EXTRA_ENV_SETTINGS "stdin=serial\0" \
+#define EXTRA_ENV_SETTINGS "stdin=serial\0" \
"stdout=serial,lcd\0" \
"stderr=serial,lcd\0"
#endif
+#define MEM_LAYOUT_ENV_SETTINGS \
+ "bootm_size=0x1000\0" \
+ "kernel_addr_r=0x100\0" \
+ "fdt_addr_r=0xc0\0" \
+ "ramdisk_addr_r=0x200\0" \
+ "scriptaddr=0x1000\0" \
+ "pxefile_addr_r=0x2000\0"
+
+#define CONFIG_EXTRA_ENV_SETTINGS \
+ BOOTENV \
+ MEM_LAYOUT_ENV_SETTINGS \
+ EXTRA_ENV_SETTINGS
+
#define CONFIG_GZIP_COMPRESSED
#define CONFIG_BZIP2
#define CONFIG_LZO
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 6/8] config_distro_bootcmd.h: Add shared block definition for the host interface
Define the common shared block environment for the host interface in preperation for the sandbox build to use config_distro_bootcmd. Signed-off-by: Sjoerd Simons --- Changes in v2: None include/config_distro_bootcmd.h | 13 + 1 file changed, 13 insertions(+) diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h index d71e58d..3a360ca4 100644 --- a/include/config_distro_bootcmd.h +++ b/include/config_distro_bootcmd.h @@ -48,6 +48,18 @@ #define BOOTENV_DEV_NAME_BLKDEV(devtypeu, devtypel, instance) \ #devtypel #instance " " +#ifdef CONFIG_SANDBOX +#define BOOTENV_SHARED_HOSTBOOTENV_SHARED_BLKDEV(host) +#define BOOTENV_DEV_HOST BOOTENV_DEV_BLKDEV +#define BOOTENV_DEV_NAME_HOST BOOTENV_DEV_NAME_BLKDEV +#else +#define BOOTENV_SHARED_HOST +#define BOOTENV_DEV_HOST \ + BOOT_TARGET_DEVICES_references_HOST_without_CONFIG_SANDBOX +#define BOOTENV_DEV_NAME_HOST \ + BOOT_TARGET_DEVICES_references_HOST_without_CONFIG_SANDBOX +#endif + #ifdef CONFIG_CMD_MMC #define BOOTENV_SHARED_MMC BOOTENV_SHARED_BLKDEV(mmc) #define BOOTENV_DEV_MMCBOOTENV_DEV_BLKDEV @@ -167,6 +179,7 @@ #define BOOTENV_DEV(devtypeu, devtypel, instance) \ BOOTENV_DEV_##devtypeu(devtypeu, devtypel, instance) #define BOOTENV \ + BOOTENV_SHARED_HOST \ BOOTENV_SHARED_MMC \ BOOTENV_SHARED_USB \ BOOTENV_SHARED_SATA \ -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 7/8] pxe: Ensure all memory access is to mapped memory
Properly map memory through map_sysmem so that pxe can be used from the
sandbox.
Tested in sandbox as well as on jetson-tk1, odroid-xu3, snow as peach-pi
boards
Signed-off-by: Sjoerd Simons
---
Changes in v2:
- Prevent uncessary casts
- Always unmap mapped sysmem
- Consistently use base variable to refer to unmapped memory
- Various coding style fixes
common/cmd_pxe.c | 86
1 file changed, 56 insertions(+), 30 deletions(-)
diff --git a/common/cmd_pxe.c b/common/cmd_pxe.c
index 7e32c95..292f2c1 100644
--- a/common/cmd_pxe.c
+++ b/common/cmd_pxe.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include "menu.h"
#include "cli.h"
@@ -188,11 +189,12 @@ static int do_get_any(cmd_tbl_t *cmdtp, const char
*file_path, char *file_addr)
*
* Returns 1 for success, or < 0 on error.
*/
-static int get_relfile(cmd_tbl_t *cmdtp, const char *file_path, void
*file_addr)
+static int get_relfile(cmd_tbl_t *cmdtp, const char *file_path,
+ unsigned long file_addr)
{
size_t path_len;
char relfile[MAX_TFTP_PATH_LEN+1];
- char addr_buf[10];
+ char addr_buf[18];
int err;
err = get_bootfile_path(file_path, relfile, sizeof(relfile));
@@ -215,7 +217,7 @@ static int get_relfile(cmd_tbl_t *cmdtp, const char
*file_path, void *file_addr)
printf("Retrieving file: %s\n", relfile);
- sprintf(addr_buf, "%p", file_addr);
+ sprintf(addr_buf, "%lx", file_addr);
return do_getfile(cmdtp, relfile, addr_buf);
}
@@ -227,11 +229,13 @@ static int get_relfile(cmd_tbl_t *cmdtp, const char
*file_path, void *file_addr)
*
* Returns 1 on success, or < 0 for error.
*/
-static int get_pxe_file(cmd_tbl_t *cmdtp, const char *file_path, void
*file_addr)
+static int get_pxe_file(cmd_tbl_t *cmdtp, const char *file_path,
+ unsigned long file_addr)
{
unsigned long config_file_size;
char *tftp_filesize;
int err;
+ char *buf;
err = get_relfile(cmdtp, file_path, file_addr);
@@ -250,7 +254,9 @@ static int get_pxe_file(cmd_tbl_t *cmdtp, const char
*file_path, void *file_addr
if (strict_strtoul(tftp_filesize, 16, &config_file_size) < 0)
return -EINVAL;
- *(char *)(file_addr + config_file_size) = '\0';
+ buf = map_sysmem(file_addr + config_file_size, 1);
+ *buf = '\0';
+ unmap_sysmem(buf);
return 1;
}
@@ -266,7 +272,8 @@ static int get_pxe_file(cmd_tbl_t *cmdtp, const char
*file_path, void *file_addr
*
* Returns 1 on success or < 0 on error.
*/
-static int get_pxelinux_path(cmd_tbl_t *cmdtp, const char *file, void
*pxefile_addr_r)
+static int get_pxelinux_path(cmd_tbl_t *cmdtp, const char *file,
+ unsigned long pxefile_addr_r)
{
size_t base_len = strlen(PXELINUX_DIR);
char path[MAX_TFTP_PATH_LEN+1];
@@ -287,7 +294,7 @@ static int get_pxelinux_path(cmd_tbl_t *cmdtp, const char
*file, void *pxefile_a
*
* Returns 1 on success or < 0 on error.
*/
-static int pxe_uuid_path(cmd_tbl_t *cmdtp, void *pxefile_addr_r)
+static int pxe_uuid_path(cmd_tbl_t *cmdtp, unsigned long pxefile_addr_r)
{
char *uuid_str;
@@ -305,7 +312,7 @@ static int pxe_uuid_path(cmd_tbl_t *cmdtp, void
*pxefile_addr_r)
*
* Returns 1 on success or < 0 on error.
*/
-static int pxe_mac_path(cmd_tbl_t *cmdtp, void *pxefile_addr_r)
+static int pxe_mac_path(cmd_tbl_t *cmdtp, unsigned long pxefile_addr_r)
{
char mac_str[21];
int err;
@@ -325,7 +332,7 @@ static int pxe_mac_path(cmd_tbl_t *cmdtp, void
*pxefile_addr_r)
*
* Returns 1 on success or < 0 on error.
*/
-static int pxe_ipaddr_paths(cmd_tbl_t *cmdtp, void *pxefile_addr_r)
+static int pxe_ipaddr_paths(cmd_tbl_t *cmdtp, unsigned long pxefile_addr_r)
{
char ip_addr[9];
int mask_pos, err;
@@ -384,9 +391,9 @@ do_pxe_get(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
* Keep trying paths until we successfully get a file we're looking
* for.
*/
- if (pxe_uuid_path(cmdtp, (void *)pxefile_addr_r) > 0 ||
- pxe_mac_path(cmdtp, (void *)pxefile_addr_r) > 0 ||
- pxe_ipaddr_paths(cmdtp, (void *)pxefile_addr_r) > 0) {
+ if (pxe_uuid_path(cmdtp, pxefile_addr_r) > 0 ||
+ pxe_mac_path(cmdtp, pxefile_addr_r) > 0 ||
+ pxe_ipaddr_paths(cmdtp, pxefile_addr_r) > 0) {
printf("Config file found\n");
return 0;
@@ -394,7 +401,7 @@ do_pxe_get(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
while (pxe_default_paths[i]) {
if (get_pxelinux_path(cmdtp, pxe_default_paths[i],
- (void *)pxefile_addr_r) > 0) {
+ pxefile_addr_r) > 0) {
printf("Config file found\n");
return 0;
}
@@ -427,7 +434,7 @@ static int get_relfi
[U-Boot] [PATCH v2 2/8] sandbox: Split bootm code out into lib/bootm
Follow the convention of other architectures and move the platform
specific linux bootm code into sandbox/lib/bootm.c.
Signed-off-by: Sjoerd Simons
---
Changes in v2: None
arch/sandbox/cpu/cpu.c| 12
arch/sandbox/lib/Makefile | 1 +
arch/sandbox/lib/bootm.c | 21 +
3 files changed, 22 insertions(+), 12 deletions(-)
create mode 100644 arch/sandbox/lib/bootm.c
diff --git a/arch/sandbox/cpu/cpu.c b/arch/sandbox/cpu/cpu.c
index 1aa397c..a0c8106 100644
--- a/arch/sandbox/cpu/cpu.c
+++ b/arch/sandbox/cpu/cpu.c
@@ -40,18 +40,6 @@ unsigned long __attribute__((no_instrument_function))
timer_get_us(void)
return os_get_nsec() / 1000;
}
-int do_bootm_linux(int flag, int argc, char *argv[], bootm_headers_t *images)
-{
- if (flag & (BOOTM_STATE_OS_GO | BOOTM_STATE_OS_FAKE_GO)) {
- bootstage_mark(BOOTSTAGE_ID_RUN_OS);
- printf("## Transferring control to Linux (at address
%08lx)...\n",
- images->ep);
- reset_cpu(0);
- }
-
- return 0;
-}
-
int cleanup_before_linux(void)
{
return 0;
diff --git a/arch/sandbox/lib/Makefile b/arch/sandbox/lib/Makefile
index 4c1a38d..3c86cc2 100644
--- a/arch/sandbox/lib/Makefile
+++ b/arch/sandbox/lib/Makefile
@@ -9,3 +9,4 @@
obj-y += interrupts.o
+obj-$(CONFIG_CMD_BOOTM) += bootm.o
diff --git a/arch/sandbox/lib/bootm.c b/arch/sandbox/lib/bootm.c
new file mode 100644
index 000..8ddf4ef
--- /dev/null
+++ b/arch/sandbox/lib/bootm.c
@@ -0,0 +1,21 @@
+/*
+ * Copyright (c) 2011 The Chromium OS Authors.
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+int do_bootm_linux(int flag, int argc, char *argv[], bootm_headers_t *images)
+{
+ if (flag & (BOOTM_STATE_OS_GO | BOOTM_STATE_OS_FAKE_GO)) {
+ bootstage_mark(BOOTSTAGE_ID_RUN_OS);
+ printf("## Transferring control to Linux (at address
%08lx)...\n",
+ images->ep);
+ reset_cpu(0);
+ }
+
+ return 0;
+}
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/8] sandbox: only do sandboxfs for hostfs interface
Only do sandbox filesystem access when using the hostfs device
interface, rather then falling back to it in all cases. This prevents
confusion situations due to the fallback being taken rather then an
unsupported error being raised.
Signed-off-by: Sjoerd Simons
Reviewed-by: Simon Glass
---
Changes in v2:
- Minor comment coding style improvement
fs/sandbox/sandboxfs.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/fs/sandbox/sandboxfs.c b/fs/sandbox/sandboxfs.c
index a920bc0..5acfc03 100644
--- a/fs/sandbox/sandboxfs.c
+++ b/fs/sandbox/sandboxfs.c
@@ -10,7 +10,11 @@
int sandbox_fs_set_blk_dev(block_dev_desc_t *rbdd, disk_partition_t *info)
{
- return 0;
+ /*
+* Only accept a NULL block_dev_desc_t for the sandbox, which is when
+* hostfs interface is used
+*/
+ return rbdd != NULL;
}
int sandbox_fs_read_at(const char *filename, loff_t pos, void *buffer,
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 5/8] sandbox: Implement host dev [device]
A common pattern to check if a certain device exists (e.g. in
config_distro_bootcmd) is to use: dev [device]
Implement host dev [device] so this pattern can be used for sandbox host
devices.
Signed-off-by: Sjoerd Simons
---
Changes in v2: None
common/cmd_host.c | 44
1 file changed, 44 insertions(+)
diff --git a/common/cmd_host.c b/common/cmd_host.c
index d8a0bea..b47ed1c 100644
--- a/common/cmd_host.c
+++ b/common/cmd_host.c
@@ -10,6 +10,8 @@
#include
#include
+static int host_curr_device = -1;
+
static int do_host_load(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
{
@@ -85,12 +87,53 @@ static int do_host_info(cmd_tbl_t *cmdtp, int flag, int
argc,
return 0;
}
+static int do_host_dev(cmd_tbl_t *cmdtp, int flag, int argc,
+ char * const argv[])
+{
+ int dev;
+ char *ep;
+ block_dev_desc_t *blk_dev;
+ int ret;
+
+ if (argc < 1 || argc > 3)
+ return CMD_RET_USAGE;
+
+ if (argc == 1) {
+ if (host_curr_device < 0) {
+ printf("No current host device\n");
+ return 1;
+ }
+ printf("Current host device %d\n", host_curr_device);
+ return 0;
+ }
+
+ dev = simple_strtoul(argv[1], &ep, 16);
+ if (*ep) {
+ printf("** Bad device specification %s **\n", argv[2]);
+ return CMD_RET_USAGE;
+ }
+
+ ret = host_get_dev_err(dev, &blk_dev);
+ if (ret) {
+ if (ret == -ENOENT)
+ puts("Not bound to a backing file\n");
+ else if (ret == -ENODEV)
+ puts("Invalid host device number\n");
+
+ return 1;
+ }
+
+ host_curr_device = dev;
+ return 0;
+}
+
static cmd_tbl_t cmd_host_sub[] = {
U_BOOT_CMD_MKENT(load, 7, 0, do_host_load, "", ""),
U_BOOT_CMD_MKENT(ls, 3, 0, do_host_ls, "", ""),
U_BOOT_CMD_MKENT(save, 6, 0, do_host_save, "", ""),
U_BOOT_CMD_MKENT(bind, 3, 0, do_host_bind, "", ""),
U_BOOT_CMD_MKENT(info, 3, 0, do_host_info, "", ""),
+ U_BOOT_CMD_MKENT(dev, 0, 1, do_host_dev, "", ""),
};
static int do_host(cmd_tbl_t *cmdtp, int flag, int argc,
@@ -135,6 +178,7 @@ U_BOOT_CMD(
"save a file to host\n"
"host bind [] - bind \"host\" device to file\n"
"host info []- show device binding & info\n"
+ "host dev [] - Set or retrieve the current host device\n"
"host commands use the \"hostfs\" device. The \"host\" device is used\n"
"with standard IO commands such as fatls or ext2load"
);
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] printf("%d") breaks u-boot 2015.01+
On Monday, April 06, 2015 at 09:23:23 PM, Pavel Machek wrote:
> On Mon 2015-04-06 20:48:45, Marek Vasut wrote:
> > On Monday, April 06, 2015 at 08:14:44 PM, Pavel Machek wrote:
> > > On Mon 2015-04-06 16:59:55, Marek Vasut wrote:
> > > > On Monday, April 06, 2015 at 04:40:09 PM, Pavel Machek wrote:
> > > > > Hi!
> > > > >
> > > > > In u-boot 2015.04-rc, as soon as execution hits printf("%d"), it
> > > > > hangs. (Usually, that's after "DRAM: " message).
> > > >
> > > > printf("%d") expects an argument, so could it be that it touches
> > > > random piece of memory and thus hangs?
> > >
> > > It had an argument, sorry for confusion. I was actually doing this:
> > > the test with %s works, the one with %d kills it.
> > >
> > > I suspect too small stack...?
> >
> > Does this happen in the SPL ? You can check the stack placement and
> > utilization with BDI to verigy your hypothesis.
>
> No, this is u-boot proper, and I'm chainloading it (see first mail) --
> so unsupported configuration.
>
> I'm preparing to flash the u-boot into the NOR, that should tell us if
> it is chainloading problem or not.
OK, since this email was in-reply-to SPL patch series, I got confused.
Is it in any way related to this patchset then or not ?
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 09/11] dm: net: Adjust designware driver to support driver model
Hi Simon,
On Sun, Apr 5, 2015 at 5:07 PM, Simon Glass wrote:
>
> Add driver model support to the designware driver. This reuses most of the
> existing code except for some duplication in the probe() method.
>
> Signed-off-by: Simon Glass
> ---
Acked-by: Joe Hershberger
> Changes in v2:
> - Use the new recv() method and the free_pkt() method
>
> drivers/net/designware.c | 167
++-
> drivers/net/designware.h | 3 +-
> 2 files changed, 153 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/net/designware.c b/drivers/net/designware.c
> index 5b36d4f..a4fe7a4 100644
> --- a/drivers/net/designware.c
> +++ b/drivers/net/designware.c
> @@ -10,6 +10,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -18,6 +19,8 @@
> #include
> #include "designware.h"
>
> +DECLARE_GLOBAL_DATA_PTR;
> +
> #if !defined(CONFIG_PHYLIB)
> # error "DesignWare Ether MAC requires PHYLIB - missing CONFIG_PHYLIB"
> #endif
> @@ -343,11 +346,11 @@ static int _dw_eth_send(struct dw_eth_dev *priv,
void *packet, int length)
> return 0;
> }
>
> -static int _dw_eth_recv(struct dw_eth_dev *priv)
> +static int _dw_eth_recv(struct dw_eth_dev *priv, uchar **packetp)
> {
> u32 status, desc_num = priv->rx_currdescnum;
> struct dmamacdescr *desc_p = &priv->rx_mac_descrtable[desc_num];
> - int length = 0;
> + int length = -EAGAIN;
> uint32_t desc_start = (uint32_t)desc_p;
> uint32_t desc_end = desc_start +
> roundup(sizeof(*desc_p), ARCH_DMA_MINALIGN);
> @@ -368,26 +371,35 @@ static int _dw_eth_recv(struct dw_eth_dev *priv)
> /* Invalidate received data */
> data_end = data_start + roundup(length,
ARCH_DMA_MINALIGN);
> invalidate_dcache_range(data_start, data_end);
> + *packetp = desc_p->dmamac_addr;
> + }
>
> - NetReceive(desc_p->dmamac_addr, length);
This line will conflict when http://patchwork.ozlabs.org/patch/458099/ is
applied.
> + return length;
> +}
>
> - /*
> -* Make the current descriptor valid again and go to
> -* the next one
> -*/
> - desc_p->txrx_status |= DESC_RXSTS_OWNBYDMA;
> +static int _dw_free_pkt(struct dw_eth_dev *priv)
> +{
> + u32 desc_num = priv->rx_currdescnum;
> + struct dmamacdescr *desc_p = &priv->rx_mac_descrtable[desc_num];
> + uint32_t desc_start = (uint32_t)desc_p;
> + uint32_t desc_end = desc_start +
> + roundup(sizeof(*desc_p), ARCH_DMA_MINALIGN);
>
> - /* Flush only status field - others weren't changed */
> - flush_dcache_range(desc_start, desc_end);
> + /*
> +* Make the current descriptor valid again and go to
> +* the next one
> +*/
> + desc_p->txrx_status |= DESC_RXSTS_OWNBYDMA;
>
> - /* Test the wrap-around condition. */
> - if (++desc_num >= CONFIG_RX_DESCR_NUM)
> - desc_num = 0;
> - }
> + /* Flush only status field - others weren't changed */
> + flush_dcache_range(desc_start, desc_end);
>
> + /* Test the wrap-around condition. */
> + if (++desc_num >= CONFIG_RX_DESCR_NUM)
> + desc_num = 0;
> priv->rx_currdescnum = desc_num;
>
> - return length;
> + return 0;
> }
>
> static int dw_phy_init(struct dw_eth_dev *priv, void *dev)
> @@ -414,6 +426,7 @@ static int dw_phy_init(struct dw_eth_dev *priv, void
*dev)
> return 0;
> }
>
> +#ifndef CONFIG_DM_ETH
> static int dw_eth_init(struct eth_device *dev, bd_t *bis)
> {
> return _dw_eth_init(dev->priv, dev->enetaddr);
> @@ -426,7 +439,17 @@ static int dw_eth_send(struct eth_device *dev, void
*packet, int length)
>
> static int dw_eth_recv(struct eth_device *dev)
> {
> - return _dw_eth_recv(dev->priv);
> + uchar *packet;
> + int length;
> +
> + length = _dw_eth_recv(dev->priv, &packet);
> + if (length == -EAGAIN)
> + return 0;
> + NetReceive(packet, length);
This line will need to be updated in
http://patchwork.ozlabs.org/patch/458099/
> +
> + _dw_free_pkt(dev->priv);
> +
> + return 0;
> }
>
> static void dw_eth_halt(struct eth_device *dev)
> @@ -486,3 +509,115 @@ int designware_initialize(ulong base_addr, u32
interface)
>
> return dw_phy_init(priv, dev);
> }
> +#endif
> +
> +#ifdef CONFIG_DM_ETH
> +static int designware_eth_start(struct udevice *dev)
> +{
> + struct eth_pdata *pdata = dev_get_platdata(dev);
> +
> + return _dw_eth_init(dev->priv, pdata->enetaddr);
> +}
> +
> +static int designware_eth_send(struct udevice *dev, void *packet, int
length)
> +{
> + struct dw_eth_dev *priv = dev_get_priv(dev);
> +
> + return _dw_eth_send(priv, packet, length);
> +}
> +
> +static int designware_eth_recv(struct udevice *dev, u
Re: [U-Boot] [PATCH v2 3/8] sandbox: Add support for bootz
On 04/06/2015 03:02 PM, Sjoerd Simons wrote: Add dummy bootz_setup implementation allowing the u-boot sandbox to run bootz. This recognizes both ARM and x86 zImages to validate a valid zImage was loaded. diff --git a/arch/sandbox/lib/bootm.c b/arch/sandbox/lib/bootm.c +int bootz_setup(ulong image, ulong *start, ulong *end) + *start = 0xdead; + *end = 0xbeef; + return 0; Isn't that going to cause the rest of bootz to access or jump to some bogus address and crash? Aside from that, this series looks plausible, so, Acked-by: Stephen Warren (I read through patch 6 most thoroughly, briefly skimmed patch 7, and read the others fairly quickly, so take that as an ack primarily on patch 6 although I didn't see anything obviously wrong elsewhere). ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/8] Allow sandbox to use config_distro_bootcmd
Testing whether images will correctly boot with the standard distro
bootcmds can be rather time-consuming as it tends to require flashing
the images and booting on a device. Ditto for testing changes to
config_distro_bootcmd.
Adding support for sandbox to run distro bootcmds makes things a lot
more convenient.
Sjoerd Simons (8):
sandbox: only do sandboxfs for hostfs interface
sandbox: Split bootm code out into lib/bootm
sandbox: Add support for bootz
sandbox: Renamed sb command to host
sandbox: Implement host dev [device]
config_distro_bootcmd.h: Add shared block definition for the host
interface
pxe: Ensure all memory access is to mapped memory
sandbox: add config_distro_defaults and config_distro_bootcmd
arch/sandbox/cpu/cpu.c | 12 -
arch/sandbox/lib/Makefile| 1 +
arch/sandbox/lib/bootm.c | 40
common/Makefile | 2 +-
common/{cmd_sandbox.c => cmd_host.c} | 93 +---
common/cmd_pxe.c | 86 +
fs/sandbox/sandboxfs.c | 6 ++-
include/config_distro_bootcmd.h | 13 +
include/configs/sandbox.h| 29 +--
9 files changed, 218 insertions(+), 64 deletions(-)
create mode 100644 arch/sandbox/lib/bootm.c
rename common/{cmd_sandbox.c => cmd_host.c} (50%)
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/23] net: cosmetic: Fix naming and other checkpatch.pl issues in net/
Hi Joe, On 6 April 2015 at 14:41, Joe Hershberger wrote: > Hi Simon, > > On Fri, Apr 3, 2015 at 4:14 PM, Joe Hershberger > wrote: >> >> This series is fairly disruptive in naming, so hopefully there aren't >> many network stack changes in flight that will conflict with this. This >> is based on top of dm/next for now so that the dm/eth series is assumed. >> This will be rebased when that is, but will likely not have issues. >> >> Like ripping off a bandage, do it quick and all at once. > > It would be good if you can pull this in through dm/next if there are no > oppositions, since this depends on that tree and will be disruptive if left > out for any amount of time. OK I can do that. The merge window opens in a week so it is good timing. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] please pull u-boot-samsung master
On Mon, Apr 06, 2015 at 03:38:10PM +0900, Minkyu Kang wrote: > Dear Tom, > > The following changes since commit d68df028099235c5316eec1ed5f586f3744a8707: > > Merge git://git.denx.de/u-boot-arc (2015-04-03 09:14:44 -0400) > > are available in the git repository at: > > > http://git.denx.de/u-boot-samsung > > for you to fetch changes up to 1018b0a56a4719a64fb6867337a72d6a9343008b: > > config: exynos: trats2: Enable support for Image.itb at trats2 device > (2015-04-06 15:23:59 +0900) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-sunxi master
On Sat, Apr 04, 2015 at 03:41:08PM +0200, Hans de Goede wrote: > Hi Tom, > > Please pull u-boot-sunxi/master into master for a small bugfix for v2015.04. > This fixes the CONFIG_FDTFILE setting in a defconfig file so that we do not > end up loading the wrong dtb: > > The following changes since commit d68df028099235c5316eec1ed5f586f3744a8707: > > Merge git://git.denx.de/u-boot-arc (2015-04-03 09:14:44 -0400) > > are available in the git repository at: > > http://git.denx.de/u-boot-sunxi.git master > > for you to fetch changes up to 47bdb9f892667904aeab831b622d4a52b90b4de0: > > sunxi: Fix Orangepi_mini dtb filename (2015-04-04 15:37:22 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/80] dm: Add USB support
Hi Marek, On 6 April 2015 at 07:13, Marek Vasut wrote: > On Monday, April 06, 2015 at 01:38:13 AM, Simon Glass wrote: >> Hi Marek, > > Hi Simon, > >> On 26 March 2015 at 13:40, Marek Vasut wrote: >> > On Wednesday, March 25, 2015 at 07:21:48 PM, Simon Glass wrote: >> >> This series adds driver model support to USB. The intent is to permit >> >> the various subsystems (OHCI, EHCI, XHCI) to co-exist and allow any >> >> number of USB ports of different types. >> >> >> >> With the RFC series, only USB controllers had a real driver model >> >> device. USB devices (including the hub in the controller) were not >> >> modelled as driver model devices. >> >> >> >> While this was expedient, and produced much fewer patches, it is not a >> >> long-term solution. Also, since then, driver model Ethernet support >> >> (which USB can use) has been merged to u-boot-dm/next. It seems better >> >> to bite the bullet and do a full conversion. >> > >> > Whew. >> > >> > Reviewed-by: Marek Vasut >> >> Thanks very much for working through these! >> >> Unless there are other comments I plan to apply this to u-boot-dm/next >> in the next few days. I expect it will need some tweaking as boards >> are moved over too. > > Please apply, I'm really looking forward to this. > > Thank you very much for putting all the effort into this ! OK, I'll apply to u-boot-dm/next, do a bit more testing, and apply. It will be great to get this moved over. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] dm: spi: Convert Freescale QSPI driver to driver model
On 1 April 2015 at 01:19, Peng Fan wrote: > Hi Haikun, > > > On 4/1/2015 11:10 AM, Haikun Wang wrote: >> >> Move the Freescale QSPI driver over to driver model. >> >> Signed-off-by: Haikun Wang >> Signed-off-by: Peng Fan >> --- >> >> Changes in v2: >> - Fix build fail on mx6sxsabresd_spl issue >> - Add configure regmap endian in NO-DM model >> >> Changes in v1: None. >> [snip] > > Testey-by: Peng Fan Acked-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/3] ARM: mx6: Fix errata workarounds for i.MX6
On 4/6/2015 12:01 PM, nitin.g...@freescale.com wrote: > From: Nitin Garg > > Since MX6 is Cortex-A9 r2p10, enable ARM errata > 751472, 794072, 761320 only applied to the > following configuration: > > This erratum affects configurations with either: > - One processor if the ACP is present > - Two or more processors > > i.MX6 family does not have the ACP and thus only the MPCore > system will be impacted, which are the i.MX6DQ, i.MX6DL. > > Signed-off-by: Nitin Garg > --- > > Changes in v3: > Split the patch as suggested by Fabio. > > Changes in v2: None > > include/configs/mx6_common.h |3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/include/configs/mx6_common.h b/include/configs/mx6_common.h > index e0528ce..e22336e 100644 > --- a/include/configs/mx6_common.h > +++ b/include/configs/mx6_common.h > @@ -18,9 +18,12 @@ > #define __MX6_COMMON_H > > #define CONFIG_ARM_ERRATA_743622 > +#if (defined(CONFIG_MX6Q) || defined(CONFIG_MX6DL) ||\ > +defined(CONFIG_MX6QDL)) && !defined(CONFIG_MX6S) > #define CONFIG_ARM_ERRATA_751472 > #define CONFIG_ARM_ERRATA_794072 > #define CONFIG_ARM_ERRATA_761320 > +#endif We definitely want to allow 1 binary for CONFIG_MX6DL/ CONFIG_MX6S so perhaps this needs to be a runtime check ? Thanks Troy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] spi: omap3: Fix timeout handling
On Wed, Apr 01, 2015 at 04:21:50PM +0100, Andy Pont wrote:
> Hi David,
>
>
>
> > for (i = 0; i < len; i++) {
> > /* wait till TX register is empty (TXS == 1) */
> > + start = get_timer(0);
> > while (!(readl(&ds->regs->channel[ds->slave.cs].chstat) &
> > OMAP3_MCSPI_CHSTAT_TXS)) {
> > - if (--timeout <= 0) {
> > + if (get_timer(start) > SPI_WAIT_TIMEOUT) {
> > printf("SPI TXS timed out, status=0x%08x\n",
> >readl(&ds->regs->channel[ds-
> > >slave.cs].chstat));
> > return -1;
>
> I have a couple of questions...
>
> Firstly, when in SPL is there access to the get_timer() function?
We call timer_init() from board_init_r() in SPL, prior to diving down
into loading (or checking for Falcon vs Regular) so this is safe.
> Secondly, when using Falcon mode to load Linux directly from SPI (Falcon
> mode) then we want to maximise the throughput and save every CPU cycle we
> possibly can. Adding yet another function call into the for loop and hence
> calling it a couple of million times seems, on the face of it, like it is
> going to slow things down.
I'd like to see measurements to prove me wrong but this both seems like
a bad idea (optimizing by being incorrect, this gives us a correct
timeout check like other drivers do) and really unlikely I would think
to be noticable. Since we'll be doing the same code-paths in both
regular and SPL, trying to time things (by loading a big file) would be
easy enough I think. Thanks!
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] buildman: Make -V (verbose_build) really be verbose
On Sun, Apr 05, 2015 at 12:31:39PM -0600, Simon Glass wrote: > Hi Tom, > > On 1 April 2015 at 05:47, Tom Rini wrote: > > The help text for -V says we will pass V=1 but all it really did was not > > pass in -s. Change the logic to pass make V=1 with given to buildman -V or > > -s to make otherwise. > > > > Cc: Simon Glass > > Signed-off-by: Tom Rini > > --- > > tools/buildman/builderthread.py |4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > Acked-by: Simon Glass Thanks :) > See also: > > http://patchwork.ozlabs.org/patch/437051/ Also useful, but I ran into this when I was going "what lds script does X use again? Lemme build, wait, lemme verbose build, wait, what?" and saw we didn't save the V=1 output just regular output. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] MAKEALL: fix get_target_arch() to adjust to '-' in Status field
On Sun, Apr 05, 2015 at 12:31:44PM -0600, Simon Glass wrote: > Hi Tom, > > On 1 April 2015 at 05:19, Tom Rini wrote: > > On Tue, Mar 31, 2015 at 08:39:57PM -0600, Simon Glass wrote: > > > >> Hi Masahiro, > >> > >> On 30 March 2015 at 05:59, Masahiro Yamada > >> wrote: > >> > Since the Kconfig conversion, boards.cfg scanned by MAKEALL is > >> > generated by tools/genboardscfg.py. Every board is supposed to have > >> > its own MAINTAINERS that contains maintainer and status information, > >> > but, in fact, MAINTAINERS is missing from some boards. > >> > > >> > For such boards, the first field, Status, is filled with '-'. > >> > It causes a problem for "set" command, which ignores '-' in its > >> > arguments. Consequently, get_target_arch() returns a wrong field > >> > and MAKEALL fails to get a correct toolchain. > >> > > >> > Signed-off-by: Masahiro Yamada > >> > - Improve git description > >> > >> Should we perhaps apply the patch to deprecate MAKEALL? > > > > With the last patch I posted about what binaries to save all my usecases > > are covered now. > > OK, do you think we can wait until the merge window before doing > these? I don't see any great hurry. I can continue cursing and doing make O=temp by hand for a bit longer, sure ;) -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot: OpenRD Ultimate fails to build
On Sat, Apr 04, 2015 at 06:13:18PM +0200, drEagle wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Le 03/04/2015 23:46, Vagrant Cascadian a écrit : > > On 2015-03-25, drEagle wrote: > >> Le 21/03/2015 15:53, Vagrant Cascadian a écrit : > >>> It seems that OpenRD Ultimate with u-boot 2015.04-rc3 and newer no > >>> longer builds from source, both in Debian and with mainline git. It > >>> appears to have overgrown the size limits set for it: > >> > >> Looks like the NAND partition map had to be changed to give more space for > >> u-boot. > > > > The following patch gets it to build by moving the env addr and offset > > later. This might cause problems with new or existing u-boot > > installations on openrd if the environment needs to be at a specific > > location. I have no hardware to test, so no way of confirming this > > directly: > > > > diff --git a/include/configs/openrd.h b/include/configs/openrd.h > > index b6f80af..2f1e174 100644 > > --- a/include/configs/openrd.h > > +++ b/include/configs/openrd.h > > @@ -72,12 +72,12 @@ > > /* > > * max 4k env size is enough, but in case of nand > > * it has to be rounded to sector size > > */ > > #define CONFIG_ENV_SIZE0x2 /* 128k */ > > -#define CONFIG_ENV_ADDR0x6 > > -#define CONFIG_ENV_OFFSET 0x6 /* env starts here */ > > +#define CONFIG_ENV_ADDR0x8 > > +#define CONFIG_ENV_OFFSET 0x8 /* env starts here */ > > /* > > * Environment is right behind U-Boot in flash. Make sure U-Boot > > * doesn't grow into the environment area. > > */ > > #define CONFIG_BOARD_SIZE_LIMITCONFIG_ENV_OFFSET > > > > > > I'll likely remove openrd_ultimate from future uploads to Debian if I > > can't get confirmation about how to fix this properly. > > The same may be a problem for SHEEVAPLUG and GURUPLUG, may be also all > KIRKWOOD derivatives. > We need to get a more robust and compatible way to define the NAND PARTS, the > BOOTLOAD and the NAND UPGRADE. > Each distribution has differents needs. > > It's a discution needed upstream because it ill impact all distribution and > users. It's possible that by removing some CONFIG options things can fit under the size limit and not require env to be moved. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] ARM: bcm2835: use phys_to_bus() for mbox
When we communicate with the VideoCore to perform property mailbox
transactions, that is a DMA operation as far as the property buffer
is concerned. Use phys_to_bus() on that buffer.
Signed-off-by: Stephen Warren
---
v2: Rebase on top of bcm283x mbox header move.
While this isn't USB-related, it does depend on patches that went into
the USB topic/dwc2 tree. Either this can be merged there, or we'll have
to wait until that branch is merged into u-boot/master and then merge
this.
As best I can tell, this is the last place we need to do this. SDHCI has
potential but CONFIG_MMC_SDMA isn't set so I don't believe the code does
any DMA. LCD has potential, but the VideoCore allocates the display
surface, programs the display engine, and passes the surface's CPU pointer
back to the CPU in a firmware message, of U-Boot isn't involved in setting
up the DMA HW.
---
arch/arm/mach-bcm283x/mbox.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-bcm283x/mbox.c b/arch/arm/mach-bcm283x/mbox.c
index 3b17a31eacfd..1af9be78c68a 100644
--- a/arch/arm/mach-bcm283x/mbox.c
+++ b/arch/arm/mach-bcm283x/mbox.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#define TIMEOUT 1000 /* ms */
@@ -110,10 +111,10 @@ int bcm2835_mbox_call_prop(u32 chan, struct
bcm2835_mbox_hdr *buffer)
dump_buf(buffer);
#endif
- ret = bcm2835_mbox_call_raw(chan, (u32)buffer, &rbuffer);
+ ret = bcm2835_mbox_call_raw(chan, phys_to_bus((u32)buffer), &rbuffer);
if (ret)
return ret;
- if (rbuffer != (u32)buffer) {
+ if (rbuffer != phys_to_bus((u32)buffer)) {
printf("mbox: Response buffer mismatch\n");
return -1;
}
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ PATCH] patman: cover letter shows like 00/xx if more than 10 patches
HI, Simon
Thanks for the feedback.
On 4/6/2015 2:31 AM, Simon Glass wrote:
Hi Josh,
On 31 March 2015 at 20:54, Josh Wu wrote:
Hi, Simon
On 4/1/2015 10:04 AM, Simon Glass wrote:
Hi Josh,
On 30 March 2015 at 19:54, Josh Wu wrote:
Make cover letter shows like 0/x, 00/xx and 000/xxx etc.
Signed-off-by: Josh Wu
---
This is a quirk of patman that I've grown comfortable with. Still, we
should fix it. Thanks for the patch.
tools/patman/patchstream.py | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/tools/patman/patchstream.py b/tools/patman/patchstream.py
index 8c3a0ec..4bfb1e9 100644
--- a/tools/patman/patchstream.py
+++ b/tools/patman/patchstream.py
@@ -468,8 +468,13 @@ def InsertCoverLetter(fname, series, count):
prefix = series.GetPatchPrefix()
for line in lines:
if line.startswith('Subject:'):
-# TODO: if more than 10 patches this should save 00/xx, not
0/xx
-line = 'Subject: [%s 0/%d] %s\n' % (prefix, count, text[0])
+# if more than 10 patches this should save 00/xx, not 0/xx
s/save/say/
(my typo, I think)
;-) I'll fix this.
+zero_repeat = 1
+while (count / (10 ** zero_repeat) > 0):
+zero_repeat = zero_repeat + 1
How about:
zero_repeat = int(math.log10(count)) + 1
?
yes, it's better. just need to import the match lib.
I will change to this and sent v2 patch. Thanks.
BTW: speak of patman, I get an issue of using the "Series-prefix".
When I use Series-prefix like following in the commit:
Series-prefix: U-Boot][
Then I get the patman generated patch like:
[U-Boot][ PATCH]
^ a space here.
A space is before the 'PATCH', that annoys me. But I don't see you have such
space in your patches. Any advice to avoid the extra space?
Thanks in advance.
This is intentional, since if you use a prefix of 'RFC' we want to get
'RFC PATCH v2' instead of 'RFCPATCH v2'. See GetPatchPrefix().
yes, understood.
Why do
you want [U-Boot] anyway? That sounds more like the project than a
patch prefix. Perhaps you could add an option to prepend the project
in square brackets?
I tried a the project prefix, and that works for the format-patch
command. But it not work for patman.
here is my steps:
git config format.subjectprefix "U-Boot"
Now, when I run git format-patch, the generated patch will have
"[U-Boot]" prefix. But if I run "patman -c1 -n", the [U-Boot] prefix is
gone.
It seems patman overide the format.subjectprefix option of git. Do you
have an idea about what is the difference between the run "git
format-patch -1" and "patman -c1"?
thanks.
Best Regards,
Josh Wu
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: bcm2835: use phys_to_bus() for mbox
On Tuesday, April 07, 2015 at 04:28:39 AM, Stephen Warren wrote: > When we communicate with the VideoCore to perform property mailbox > transactions, that is a DMA operation as far as the property buffer > is concerned. Use phys_to_bus() on that buffer. > > Signed-off-by: Stephen Warren Applied to u-boot-usb topic/dwc2 , 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] [PATCH v2 80/80] dm: usb: Add a README for driver model
There are some typos. Please correct them, thanks.
On 03/26/2015 02:23 AM, Simon Glass wrote:
Add some documentation describing how USB is implemented with USB. This
might make things easier for people to understand.
Signed-off-by: Simon Glass
---
Changes in v2:
- Rewrite and expand series to support driver model fully
doc/driver-model/usb-info.txt | 415 ++
1 file changed, 415 insertions(+)
create mode 100644 doc/driver-model/usb-info.txt
diff --git a/doc/driver-model/usb-info.txt b/doc/driver-model/usb-info.txt
new file mode 100644
index 000..3762b6c
--- /dev/null
+++ b/doc/driver-model/usb-info.txt
@@ -0,0 +1,415 @@
+How USB works with driver model
+===
+
+Introduction
+
+
+Driver model USB support makes use of existing features but changes how
+drivers are found. This document provides some information intended to help
+understand how things work with USB in U-Boot when driver model is enabled.
+
+
+Enabling driver model for USB
+-
+
+A new CONFIG_DM_USB option is provided to enable driver model for USB. This
+causes the USB uclass to be included, and drops the equivalent code in
+usb.c. In particular the usb_init() function is then implemented by the
+uclass.
+
+
+Support for ECHI and XCHI
EHCI
XHCI
+-
+
+So far OHCI is not supported. Both EHCI and XHCI drivers should be declared
+as drivers in the USB uclass. For example:
+
+static const struct udevice_id ehci_usb_ids[] = {
+ { .compatible = "nvidia,tegra20-ehci", .data = USB_CTLR_T20 },
+ { .compatible = "nvidia,tegra30-ehci", .data = USB_CTLR_T30 },
+ { .compatible = "nvidia,tegra114-ehci", .data = USB_CTLR_T114 },
+ { }
+};
+
+U_BOOT_DRIVER(usb_ehci) = {
+ .name = "ehci_tegra",
+ .id = UCLASS_USB,
+ .of_match = ehci_usb_ids,
+ .ofdata_to_platdata = ehci_usb_ofdata_to_platdata,
+ .probe = tegra_ehci_usb_probe,
+ .remove = tegra_ehci_usb_remove,
+ .ops= &ehci_usb_ops,
+ .platdata_auto_alloc_size = sizeof(struct usb_platdata),
+ .priv_auto_alloc_size = sizeof(struct fdt_usb),
+ .flags = DM_FLAG_ALLOC_PRIV_DMA,
+};
+
+Here ehci_usb_ids is used to list the controllers that the driver supports.
+Each has its own data value. Controllers must be in the UCLASS_USB uclass.
+
+The ofdata_to_platdata() method allows the controller driver to grab any
+necessary settings from the device tree.
+
+The ops here are ehci_usb_ops. All EHCI drivers will use these same ops in
+most cases, since they are all ECHI-compatible. For ECHI there are also some
EHCI-compatible
For EHCI
+special operations that can be overriden when calling ehci_register().
overridden
+This defines a single controller, containing a root hub (which is required).
+The hub is emulated by a hub emulator, and the emulated hub has a single
+flash stick to emulate on one of its ports.
+
+When 'usb start' is used, the following 'dm tree' output will be available:
+
+ usb [ + ]`-- usb@1
+ usb_hub [ + ]`-- hub
+ usb_emul[ + ]|-- hub-emul
+ usb_emul[ + ]| `-- flash-stick
+ usb_mass_st [ + ]`-- usb_mass_storage
+
+
+This may look a confusing. Most of it mirrors the device tree, but the
may look confusing
--nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx53loco: Disable printing cpuinfo
> -Original Message-
> From: Fabio Estevam [mailto:fabio.este...@freescale.com]
> Sent: Monday, April 06, 2015 10:23 PM
> To: sba...@denx.de
> Cc: Liu Hui-R64343; u-boot@lists.denx.de; Estevam Fabio-R49496
> Subject: [PATCH] mx53loco: Disable printing cpuinfo
>
> Since commit 32df39c741788e ("mx5: fix get_reset_cause") we have the
> following boot messages on a mx53qsb:
>
> U-Boot 2015.04-rc5-00029-gd68df02 (Apr 06 2015 - 11:15:39)
>
> CPU: Freescale i.MX53 rev2.1 at 800 MHz
> Reset cause: POR
> Board: MX53 LOCO
> I2C: ready
> DRAM: 1 GiB
> MMC: FSL_SDHC: 0, FSL_SDHC: 1
> In:serial
> Out: serial
> Err: serial
> CPU: Freescale i.MX53 rev2.1 at 1000 MHz
> Reset cause: unknown reset
> Net: FEC [PRIME]
>
> The CPU and Reset cause lines appear twice.
>
> Initially mx53 boots at 800MHz, then at a later point the PMIC is
> configured via I2C to raise the CPU voltage so that it can run at 1GHz.
>
> To avoid such misleading double printings, disable printing cpu info for
> now.
>
> Signed-off-by: Fabio Estevam
Acked-by: Jason Liu
> ---
> board/freescale/mx53loco/mx53loco.c | 1 -
> include/configs/mx53loco.h | 2 --
> 2 files changed, 3 deletions(-)
>
> diff --git a/board/freescale/mx53loco/mx53loco.c
> b/board/freescale/mx53loco/mx53loco.c
> index 9ece6ec..1298788 100644
> --- a/board/freescale/mx53loco/mx53loco.c
> +++ b/board/freescale/mx53loco/mx53loco.c
> @@ -389,7 +389,6 @@ int board_late_init(void) {
> if (!power_init())
> clock_1GHz();
> - print_cpuinfo();
>
> return 0;
> }
> diff --git a/include/configs/mx53loco.h b/include/configs/mx53loco.h
> index 8f92234..3551e02 100644
> --- a/include/configs/mx53loco.h
> +++ b/include/configs/mx53loco.h
> @@ -24,8 +24,6 @@
>
> #define CONFIG_SYS_GENERIC_BOARD
>
> -#define CONFIG_DISPLAY_CPUINFO
> -
> /* Size of malloc() pool */
> #define CONFIG_SYS_MALLOC_LEN(10 * 1024 * 1024)
>
> --
> 1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] printf("%d") breaks u-boot 2015.01+
Hello Pavel,
Am 06.04.2015 16:40, schrieb Pavel Machek:
Hi!
In u-boot 2015.04-rc, as soon as execution hits printf("%d"), it
hangs. (Usually, that's after "DRAM: " message).
Now, I have to admit I'm chainloading u-boot from
U-Boot 2013.01.01 (Mar 25 2015 - 15:57:21)
tftp 0x0140 .../u-boot.bin
Waiting for PHY auto negotiation to complete.. done
ENET Speed is 100 Mbps - FULL duplex connection
Using mii0 device
TFTP from server 10.0.0.6; our IP address is 10.0.0.99
...
Bytes transferred = 325004 (4f58c hex)
# go 0x0140
...but that worked well for 2014.10, (and is nearly mandatory in my
config).
I'm using cross-compiler from eldk-5.6, but eldk-5.4 crosscompiler
produces same behaviour, and both seem to work for 2014.10.
Any ideas?
Do you have caches on?
Try to disable "dcache off" before "go ..." ...
or ...
diff --git a/common/cmd_boot.c b/common/cmd_boot.c
index 8f2e070..01825e6 100644
--- a/common/cmd_boot.c
+++ b/common/cmd_boot.c
@@ -19,6 +19,7 @@ __attribute__((weak))
unsigned long do_go_exec(ulong (*entry)(int, char * const []), int argc,
char * const argv[])
{
+ cleanup_before_linux();
return entry (argc, argv);
}
maybe this helps? I just stepped into same problem on an am335x,
but had not yet time to look deeper in it ...
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] i2c: mvtwsi: Support for up to 4 different controllers
Hello Hans,
Am 04.04.2015 14:13, schrieb Hans de Goede:
Hi,
On 04-04-15 13:27, Paul Kocialkowski wrote:
Orion5x, Kirkwood and Armada XP platforms come with a single TWSI (I2C) MVTWSI
controller. However, other platforms using MVTWSI may come with more: this is
the case on Allwinner (sunxi) platforms, where up to 4 controllers can be found
on the same chip.
Signed-off-by: Paul Kocialkowski
Looks good to me:
Acked-by: Hans de Goede
Heiko can you pick this one up please ? The second patch will likely
cause conflicts in the sunxi tree so I will pack that one up once
you've merged the first one, also I've some review remarks for the
second patch so that needs to be respun.
No need to wait for me, please pick up the hole series. I look
through the patch, and send my comments (now for v3). Then you
can pick up this patches through your sunxi tree.
bye,
Heiko
Regards,
Hans
---
arch/arm/include/asm/arch-sunxi/i2c.h| 2 +-
arch/arm/mach-kirkwood/include/mach/config.h | 2 +-
drivers/i2c/mvtwsi.c | 124 ---
include/configs/db-mv784mp-gp.h | 2 +-
include/configs/edminiv2.h | 2 +-
include/configs/maxbcm.h | 2 +-
6 files changed, 100 insertions(+), 34 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/i2c.h
b/arch/arm/include/asm/arch-sunxi/i2c.h
index dc5406b..502e3c6 100644
--- a/arch/arm/include/asm/arch-sunxi/i2c.h
+++ b/arch/arm/include/asm/arch-sunxi/i2c.h
@@ -8,7 +8,7 @@
#include
-#define CONFIG_I2C_MVTWSI_BASESUNXI_TWI0_BASE
+#define CONFIG_I2C_MVTWSI_BASE0SUNXI_TWI0_BASE
/* This is abp0-clk on sun4i/5i/7i / abp1-clk on sun6i/sun8i which is 24MHz */
#define CONFIG_SYS_TCLK2400
diff --git a/arch/arm/mach-kirkwood/include/mach/config.h
b/arch/arm/mach-kirkwood/include/mach/config.h
index e77ac40..d049395 100644
--- a/arch/arm/mach-kirkwood/include/mach/config.h
+++ b/arch/arm/mach-kirkwood/include/mach/config.h
@@ -44,7 +44,7 @@
#define CONFIG_SYS_INIT_SP_ADDR0xC8012000
#define CONFIG_NR_DRAM_BANKS_MAX2
-#define CONFIG_I2C_MVTWSI_BASEKW_TWSI_BASE
+#define CONFIG_I2C_MVTWSI_BASE0KW_TWSI_BASE
#define MV_UART_CONSOLE_BASEKW_UART0_BASE
#define MV_SATA_BASEKW_SATA_BASE
#define MV_SATA_PORT0_OFFSETKW_SATA_PORT0_OFFSET
diff --git a/drivers/i2c/mvtwsi.c b/drivers/i2c/mvtwsi.c
index 6f6edd5..331d73c 100644
--- a/drivers/i2c/mvtwsi.c
+++ b/drivers/i2c/mvtwsi.c
@@ -14,7 +14,7 @@
#include
/*
- * include a file that will provide CONFIG_I2C_MVTWSI_BASE
+ * include a file that will provide CONFIG_I2C_MVTWSI_BASE*
* and possibly other settings
*/
@@ -91,11 +91,37 @@ struct mvtwsi_registers {
#defineMVTWSI_STATUS_IDLE0xF8
/*
- * The single instance of the controller we'll be dealing with
+ * MVTWSI controller base
*/
-static struct mvtwsi_registers *twsi =
-(struct mvtwsi_registers *) CONFIG_I2C_MVTWSI_BASE;
+static struct mvtwsi_registers *twsi_get_base(struct i2c_adapter *adap)
+{
+switch (adap->hwadapnr) {
+case 0:
+return (struct mvtwsi_registers *) CONFIG_I2C_MVTWSI_BASE0;
+#ifdef CONFIG_I2C_MVTWSI_BASE1
+case 1:
+return (struct mvtwsi_registers *) CONFIG_I2C_MVTWSI_BASE1;
+#endif
+#ifdef CONFIG_I2C_MVTWSI_BASE2
+case 2:
+return (struct mvtwsi_registers *) CONFIG_I2C_MVTWSI_BASE2;
+#endif
+#ifdef CONFIG_I2C_MVTWSI_BASE3
+case 3:
+return (struct mvtwsi_registers *) CONFIG_I2C_MVTWSI_BASE3;
+#endif
+#ifdef CONFIG_I2C_MVTWSI_BASE4
+case 4:
+return (struct mvtwsi_registers *) CONFIG_I2C_MVTWSI_BASE4;
+#endif
+default:
+printf("Missing mvtwsi controller %d base\n", adap->hwadapnr);
+break;
+}
+
+return NULL;
+}
/*
* Returned statuses are 0 for success and nonzero otherwise.
@@ -117,8 +143,9 @@ static struct mvtwsi_registers *twsi =
* Wait for IFLG to raise, or return 'timeout'; then if status is as expected,
* return 0 (ok) or return 'wrong status'.
*/
-static int twsi_wait(int expected_status)
+static int twsi_wait(struct i2c_adapter *adap, int expected_status)
{
+struct mvtwsi_registers *twsi = twsi_get_base(adap);
int control, status;
int timeout = 1000;
@@ -153,35 +180,40 @@ static u8 twsi_control_flags = MVTWSI_CONTROL_TWSIEN;
* Assert the START condition, either in a single I2C transaction
* or inside back-to-back ones (repeated starts).
*/
-static int twsi_start(int expected_status)
+static int twsi_start(struct i2c_adapter *adap, int expected_status)
{
+struct mvtwsi_registers *twsi = twsi_get_base(adap);
+
/* globally set TWSIEN in case it was not */
twsi_control_flags |= MVTWSI_CONTROL_TWSIEN;
/* assert START */
writel(twsi_control_flags | MVTWSI_CONTROL_START, &twsi->control);
/* wait for controller to process START */
-return twsi_wait(expected_status);
+return twsi_wa
Re: [U-Boot] [PATCH v3 1/3] i2c: mvtwsi: Support for up to 4 different controllers
Hello Paul,
Am 05.04.2015 09:51, schrieb Paul Kocialkowski:
Orion5x, Kirkwood and Armada XP platforms come with a single TWSI (I2C) MVTWSI
controller. However, other platforms using MVTWSI may come with more: this is
the case on Allwinner (sunxi) platforms, where up to 4 controllers can be found
on the same chip.
Signed-off-by: Paul Kocialkowski
---
arch/arm/include/asm/arch-sunxi/i2c.h| 2 +-
arch/arm/mach-kirkwood/include/mach/config.h | 2 +-
drivers/i2c/mvtwsi.c | 124 ---
include/configs/db-mv784mp-gp.h | 2 +-
include/configs/edminiv2.h | 2 +-
include/configs/maxbcm.h | 2 +-
6 files changed, 100 insertions(+), 34 deletions(-)
Thanks for your work. No comments from me, beside of the fact,
that it would be nice if we could switch to use DM ;-)
Acked-by: Heiko Schocher
@Hans: please pick up the hole series, thanks!
bye,
Heiko
diff --git a/arch/arm/include/asm/arch-sunxi/i2c.h
b/arch/arm/include/asm/arch-sunxi/i2c.h
index dc5406b..502e3c6 100644
--- a/arch/arm/include/asm/arch-sunxi/i2c.h
+++ b/arch/arm/include/asm/arch-sunxi/i2c.h
@@ -8,7 +8,7 @@
#include
-#define CONFIG_I2C_MVTWSI_BASE SUNXI_TWI0_BASE
+#define CONFIG_I2C_MVTWSI_BASE0SUNXI_TWI0_BASE
/* This is abp0-clk on sun4i/5i/7i / abp1-clk on sun6i/sun8i which is 24MHz */
#define CONFIG_SYS_TCLK 2400
diff --git a/arch/arm/mach-kirkwood/include/mach/config.h
b/arch/arm/mach-kirkwood/include/mach/config.h
index e77ac40..d049395 100644
--- a/arch/arm/mach-kirkwood/include/mach/config.h
+++ b/arch/arm/mach-kirkwood/include/mach/config.h
@@ -44,7 +44,7 @@
#define CONFIG_SYS_INIT_SP_ADDR 0xC8012000
#define CONFIG_NR_DRAM_BANKS_MAX 2
-#define CONFIG_I2C_MVTWSI_BASE KW_TWSI_BASE
+#define CONFIG_I2C_MVTWSI_BASE0KW_TWSI_BASE
#define MV_UART_CONSOLE_BASE KW_UART0_BASE
#define MV_SATA_BASE KW_SATA_BASE
#define MV_SATA_PORT0_OFFSET KW_SATA_PORT0_OFFSET
diff --git a/drivers/i2c/mvtwsi.c b/drivers/i2c/mvtwsi.c
index 6f6edd5..331d73c 100644
--- a/drivers/i2c/mvtwsi.c
+++ b/drivers/i2c/mvtwsi.c
@@ -14,7 +14,7 @@
#include
/*
- * include a file that will provide CONFIG_I2C_MVTWSI_BASE
+ * include a file that will provide CONFIG_I2C_MVTWSI_BASE*
* and possibly other settings
*/
@@ -91,11 +91,37 @@ struct mvtwsi_registers {
#define MVTWSI_STATUS_IDLE 0xF8
/*
- * The single instance of the controller we'll be dealing with
+ * MVTWSI controller base
*/
-static struct mvtwsi_registers *twsi =
- (struct mvtwsi_registers *) CONFIG_I2C_MVTWSI_BASE;
+static struct mvtwsi_registers *twsi_get_base(struct i2c_adapter *adap)
+{
+ switch (adap->hwadapnr) {
+ case 0:
+ return (struct mvtwsi_registers *) CONFIG_I2C_MVTWSI_BASE0;
+#ifdef CONFIG_I2C_MVTWSI_BASE1
+ case 1:
+ return (struct mvtwsi_registers *) CONFIG_I2C_MVTWSI_BASE1;
+#endif
+#ifdef CONFIG_I2C_MVTWSI_BASE2
+ case 2:
+ return (struct mvtwsi_registers *) CONFIG_I2C_MVTWSI_BASE2;
+#endif
+#ifdef CONFIG_I2C_MVTWSI_BASE3
+ case 3:
+ return (struct mvtwsi_registers *) CONFIG_I2C_MVTWSI_BASE3;
+#endif
+#ifdef CONFIG_I2C_MVTWSI_BASE4
+ case 4:
+ return (struct mvtwsi_registers *) CONFIG_I2C_MVTWSI_BASE4;
+#endif
+ default:
+ printf("Missing mvtwsi controller %d base\n", adap->hwadapnr);
+ break;
+ }
+
+ return NULL;
+}
/*
* Returned statuses are 0 for success and nonzero otherwise.
@@ -117,8 +143,9 @@ static struct mvtwsi_registers *twsi =
* Wait for IFLG to raise, or return 'timeout'; then if status is as expected,
* return 0 (ok) or return 'wrong status'.
*/
-static int twsi_wait(int expected_status)
+static int twsi_wait(struct i2c_adapter *adap, int expected_status)
{
+ struct mvtwsi_registers *twsi = twsi_get_base(adap);
int control, status;
int timeout = 1000;
@@ -153,35 +180,40 @@ static u8 twsi_control_flags = MVTWSI_CONTROL_TWSIEN;
* Assert the START condition, either in a single I2C transaction
* or inside back-to-back ones (repeated starts).
*/
-static int twsi_start(int expected_status)
+static int twsi_start(struct i2c_adapter *adap, int expected_status)
{
+ struct mvtwsi_registers *twsi = twsi_get_base(adap);
+
/* globally set TWSIEN in case it was not */
twsi_control_flags |= MVTWSI_CONTROL_TWSIEN;
/* assert START */
writel(twsi_control_flags | MVTWSI_CONTROL_START, &twsi->control);
/* wait for controller to process START */
- return twsi_wait(expected_status);
+ return twsi_wait(adap, expected_status);
}
/*
* Send a byte (i2c address or data).
*/
-static int twsi_send(u8 byte, int expected_status)
+static int twsi_send(struct i2c_adapter *adap, u8 byte, int expected_statu
Re: [U-Boot] Regarding patch: http://patchwork.ozlabs.org/patch/373593/
> -Original Message- > From: Marek Vasut [mailto:ma...@denx.de] > Sent: Monday, April 06, 2015 8:42 PM > To: Mehresh Ramneek-B31383 > Cc: u-boot; s...@denx.de > Subject: Re: Regarding patch: http://patchwork.ozlabs.org/patch/373593/ > > On Monday, April 06, 2015 at 10:58:30 AM, Ramneek Mehresh wrote: > > [...] > > > > > > The static void fsl_xhci_core_exit(struct fsl_xhci *fsl_xhci) > > > > > must shut down the controller, which I don't see happening. Why? > > > > > > > > I could not locate any such requirement in IP documentation. Have > > > > contacted local IP/PHY team for the same. Waiting for response > > > > from them > > > > > > This is needed, so you don't start Linux with a running USB controller. > > > > xhci controller is already stopped in > > usb_stop->usb_lowlevel_stop->xhci_reset(). I could see CMD_RUN bit > > getting reset in this function before the controller is reset. So, > > from your previously stated requirement, controller is halted when Linux is > started. > > > > Other people are shutting down PHY as part of xhci_core_exit(), not > > the controller!! We would not like to re-start and re-configure PHY > > inside Linux, and take phy initialization inside bootloader. I got > > word from hw team that they do not support phy shutting down from sw. > > hence, we do not have any sequence for current socs to shut down phy > > from sw. if required, I'll put forward a request to provide this control in > future socs. > > Hi, > > Is this similar hardware bug to the one which MX6 PCIe is suffering ? On MX6, > the bug is that you cannot reset the PCIe and PCIe PHY from software, which > means that if you start PCIe in U-Boot, you cannot reliably use it in Linux. > Furthermore, if you reset the MX6 via WDT, you cannot start PCIe reliably in > Linux even if PCIe is not used in U-Boot at all. > > Is this the same type of hardware screwup where the design team didn't > think reset was necessary? > I have raised request for this feature in up-coming socs, and they have agreed to provide phy shut-down in future revs. However, this support is not available in current revs for which the code is sent. What do you suggest we should do for current socs? > 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 v3 1/3] i2c: mvtwsi: Support for up to 4 different controllers
Hi, On 07-04-15 07:24, Heiko Schocher wrote: Hello Paul, Am 05.04.2015 09:51, schrieb Paul Kocialkowski: Orion5x, Kirkwood and Armada XP platforms come with a single TWSI (I2C) MVTWSI controller. However, other platforms using MVTWSI may come with more: this is the case on Allwinner (sunxi) platforms, where up to 4 controllers can be found on the same chip. Signed-off-by: Paul Kocialkowski --- arch/arm/include/asm/arch-sunxi/i2c.h| 2 +- arch/arm/mach-kirkwood/include/mach/config.h | 2 +- drivers/i2c/mvtwsi.c | 124 --- include/configs/db-mv784mp-gp.h | 2 +- include/configs/edminiv2.h | 2 +- include/configs/maxbcm.h | 2 +- 6 files changed, 100 insertions(+), 34 deletions(-) Thanks for your work. No comments from me, beside of the fact, that it would be nice if we could switch to use DM ;-) Acked-by: Heiko Schocher @Hans: please pick up the hole series, thanks! Ok will do so as soon as there is a V4 addressing my last review comment. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/3] i2c: mvtwsi: Support for up to 4 different controllers
Le mardi 07 avril 2015 à 08:29 +0200, Hans de Goede a écrit : > Hi, > > On 07-04-15 07:24, Heiko Schocher wrote: > > Hello Paul, > > > > Am 05.04.2015 09:51, schrieb Paul Kocialkowski: > >> Orion5x, Kirkwood and Armada XP platforms come with a single TWSI (I2C) > >> MVTWSI > >> controller. However, other platforms using MVTWSI may come with more: this > >> is > >> the case on Allwinner (sunxi) platforms, where up to 4 controllers can be > >> found > >> on the same chip. > >> > >> Signed-off-by: Paul Kocialkowski > >> --- > >> arch/arm/include/asm/arch-sunxi/i2c.h| 2 +- > >> arch/arm/mach-kirkwood/include/mach/config.h | 2 +- > >> drivers/i2c/mvtwsi.c | 124 > >> --- > >> include/configs/db-mv784mp-gp.h | 2 +- > >> include/configs/edminiv2.h | 2 +- > >> include/configs/maxbcm.h | 2 +- > >> 6 files changed, 100 insertions(+), 34 deletions(-) > > > > Thanks for your work. No comments from me, beside of the fact, > > that it would be nice if we could switch to use DM ;-) > > > > Acked-by: Heiko Schocher > > > > @Hans: please pick up the hole series, thanks! > > Ok will do so as soon as there is a V4 addressing my last review > comment. Okay, I'll be submitting v4 soon then. Then it'll be time to take a close look at driver-model and device-tree! > Regards, > > Hans signature.asc Description: This is a digitally signed message part ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Regarding patch: http://patchwork.ozlabs.org/patch/373593/
Hi,
Le jeudi 18 décembre 2014 à 12:16 +0100, Marek Vasut a écrit :
> On Thursday, December 18, 2014 at 09:32:56 AM, Ramneek Mehresh wrote:
> > Hi Marex,
> >
> > Following u-boot patch is pending for your review for some time. Please let
> > me know if you have any concerns. fsl/usb: Add USB XHCI support:
> > http://patchwork.ozlabs.org/patch/373593/
>
> I missed the patch completely, sorry. Next time, please keep me on CC when
> submitting the patches, that helps a lot.
>
> As for the board_usb_init, you can drop the inline and the __board_usb_init()
> and do:
>
> __weak int board_usb_init(int index, enum usb_init_type init)
> {
> return 0;
> }
>
> The static void fsl_xhci_core_exit(struct fsl_xhci *fsl_xhci) must shut down
> the controller, which I don't see happening. Why?
By the way, this is already defined in common/usb.c, so it's probably
not worth duplicating it. On the other hand, it means that *HCI support
would be broken (it applies to all other drivers usb board_usb_init)
when not using CMD_USB, which I'm not sure is a good thing.
--
Paul Kocialkowski, Replicant developer
Replicant is a fully free Android distribution running on several
devices, a free software mobile operating system putting the emphasis on
freedom and privacy/security.
Website: http://www.replicant.us/
Blog: http://blog.replicant.us/
Wiki/tracker/forums: http://redmine.replicant.us/
signature.asc
Description: This is a digitally signed message part
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
