Re: [U-Boot] [PATCH] usb: ehci: Fix test mode for connected ports
Hi Julius, On Thu, Sep 19, 2013 at 7:39 PM, Julius Werner wrote: > Hello Marek, > > 8 seemed like a reasonable value. It is not the only possible one. As > I said, the spec requires a minimum of 4.125 (125us to make sure the > current microframe finishes, and 16 * 125us to wait for the 16 full > microframes listed on page 20). 8 fulfills that constraint and leaves > a little more tolerance, but you could also use 5, 16 or 100. I really > don't care, so please just tell me what number you want to have if you > don't like 8, because it just doesn't matter. It is no more or less > magic than the 100ms used in most other handshake() calls (without any > #define or explanation). > It seems like you could do something like /* * This is the delay for ...the spec requires a minimum of ... */ #define SOME_SUITABLE_NAME 8000 at the top of the file and then use it twice in your function. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] socfpga: Adding Freeze Controller driver
Adding Freeze Controller driver. All HPS IOs need to be
in freeze state during pin mux or IO buffer configuration.
It is to avoid any glitch which might happen
during the configuration from propagating to external devices.
Signed-off-by: Chin Liang See
Cc: Wolfgang Denk
CC: Pavel Machek
Cc: Dinh Nguyen
---
Changes for v3
- Removed unused macro in freeze_controller.h
Changes for v2
- Removed FREEZE_CONTROLLER_FSM_HW
- Removed the get_timer_count_masked and convert to use delay in us
- Used shorter local variables
---
arch/arm/cpu/armv7/socfpga/Makefile|2 +-
arch/arm/cpu/armv7/socfpga/freeze_controller.c | 242
arch/arm/cpu/armv7/socfpga/spl.c | 16 ++
.../include/asm/arch-socfpga/freeze_controller.h | 50
4 files changed, 309 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/cpu/armv7/socfpga/freeze_controller.c
create mode 100644 arch/arm/include/asm/arch-socfpga/freeze_controller.h
diff --git a/arch/arm/cpu/armv7/socfpga/Makefile
b/arch/arm/cpu/armv7/socfpga/Makefile
index 0859e44..10d20f2 100644
--- a/arch/arm/cpu/armv7/socfpga/Makefile
+++ b/arch/arm/cpu/armv7/socfpga/Makefile
@@ -14,7 +14,7 @@ LIB = $(obj)lib$(SOC).o
SOBJS := lowlevel_init.o
COBJS-y:= misc.o timer.o reset_manager.o system_manager.o
-COBJS-$(CONFIG_SPL_BUILD) += spl.o
+COBJS-$(CONFIG_SPL_BUILD) += spl.o freeze_controller.o
COBJS := $(COBJS-y)
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
diff --git a/arch/arm/cpu/armv7/socfpga/freeze_controller.c
b/arch/arm/cpu/armv7/socfpga/freeze_controller.c
new file mode 100644
index 000..93ad22a
--- /dev/null
+++ b/arch/arm/cpu/armv7/socfpga/freeze_controller.c
@@ -0,0 +1,242 @@
+/*
+ * Copyright (C) 2013 Altera Corporation
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+
+#include
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+
+
+static const struct socfpga_freeze_controller *freeze_controller_base =
+ (void *)(SOCFPGA_SYSMGR_ADDRESS + SYSMGR_FRZCTRL_ADDRESS);
+
+/*
+ * Default state from cold reset is FREEZE_ALL; the global
+ * flag is set to TRUE to indicate the IO banks are frozen
+ */
+static uint32_t frzctrl_channel_freeze[FREEZE_CHANNEL_NUM]
+ = { FREEZE_CTRL_FROZEN, FREEZE_CTRL_FROZEN,
+ FREEZE_CTRL_FROZEN, FREEZE_CTRL_FROZEN};
+
+
+/* Freeze HPS IOs */
+u32 sys_mgr_frzctrl_freeze_req(u32 channel_id)
+{
+ u32 ioctrl_reg_offset;
+ u32 reg_value;
+ u32 reg_cfg_mask;
+
+ /* select software FSM */
+ writel(SYSMGR_FRZCTRL_SRC_VIO1_ENUM_SW, &freeze_controller_base->src);
+
+ /* Freeze channel ID checking and base address */
+ switch (channel_id) {
+ case 0:
+ case 1:
+ case 2:
+ ioctrl_reg_offset = (u32)(
+ &freeze_controller_base->vioctrl +
+ (channel_id << SYSMGR_FRZCTRL_VIOCTRL_SHIFT));
+
+ /*
+* Assert active low enrnsl, plniotri
+* and niotri signals
+*/
+ reg_cfg_mask =
+ SYSMGR_FRZCTRL_VIOCTRL_SLEW_MASK
+ | SYSMGR_FRZCTRL_VIOCTRL_WKPULLUP_MASK
+ | SYSMGR_FRZCTRL_VIOCTRL_TRISTATE_MASK;
+ clrbits_le32(ioctrl_reg_offset, reg_cfg_mask);
+
+ /*
+* Note: Delay for 20ns at min
+* Assert active low bhniotri signal and de-assert
+* active high csrdone
+*/
+ reg_cfg_mask
+ = SYSMGR_FRZCTRL_VIOCTRL_BUSHOLD_MASK
+ | SYSMGR_FRZCTRL_VIOCTRL_CFG_MASK;
+ clrbits_le32(ioctrl_reg_offset, reg_cfg_mask);
+
+ /* Set global flag to indicate channel is frozen */
+ frzctrl_channel_freeze[channel_id] = FREEZE_CTRL_FROZEN;
+ break;
+
+ case 3:
+ /*
+* Assert active low enrnsl, plniotri and
+* niotri signals
+*/
+ reg_cfg_mask
+ = SYSMGR_FRZCTRL_HIOCTRL_SLEW_MASK
+ | SYSMGR_FRZCTRL_HIOCTRL_WKPULLUP_MASK
+ | SYSMGR_FRZCTRL_HIOCTRL_TRISTATE_MASK;
+ clrbits_le32(&freeze_controller_base->hioctrl, reg_cfg_mask);
+
+ /*
+* Note: Delay for 40ns at min
+* assert active low bhniotri & nfrzdrv signals,
+* de-assert active high csrdone and assert
+* active high frzreg and nfrzdrv signals
+*/
+ reg_value = readl(&freeze_controller_base->hioctrl);
+ reg_cfg_mask
+ = SYSMGR_FRZCTRL_HIOCTRL_BUSHOLD_MASK
+ | SYSMGR_FRZCTRL_HIOCTRL_CFG_MASK;
+ reg_value
+ = (reg_value & ~reg_cfg_mask)
+ | SYSMGR_FRZCTRL_HIOCTRL_REGRST_MASK
+
Re: [U-Boot] [PATCH v2] socfpga: Adding Freeze Controller driver
Hi Pavel,
On Fri, 2013-09-20 at 00:55 +0200, ZY - pavel wrote:
> Hi!
>
> > Adding Freeze Controller driver. All HPS IOs need to be
> > in freeze state during pin mux or IO buffer configuration.
> > It is to avoid any glitch which might happen
> > during the configuration from propagating to external devices.
>
> So... code that is currently in u-boot appears to work, but may
> produce some unwanted electrical spikes. They don't matter on
> development boards, but we'd like to get rid of them for production. ?
>
> It would be nice to put some explanation as a comment into code.
Actually with current code, we still not yet to boot on real board yet.
That why I am working hard to get the code upstreamed asap. Of course,
appreciate your help too as you are very helpful.
>
> > Signed-off-by: Chin Liang See
> > Cc: Wolfgang Denk
> > CC: Pavel Machek
> > Cc: Dinh Nguyen
> > ---
> > Changes for v2
> > - Removed FREEZE_CONTROLLER_FSM_HW
> > - Removed the get_timer_count_masked and convert to use delay in us
> > - Used shorter local variables
>
> Thanks! Still there's a bit to go:
Yup, actually I miss out the header file after update the source file.
>
> > +#define SYSMGR_FRZCTRL_LOOP_PARAM (1000)
> > +#define SYSMGR_FRZCTRL_DELAY_LOOP_PARAM (10)
> > +#define SYSMGR_FRZCTRL_INTOSC_33 (33)
> > +#define SYSMGR_FRZCTRL_INTOSC_1000 (1000)
>
> We no longer need these, right?
Yup
>
> > +#define FREEZE_CHANNEL_NUM (4)
>
> Check this one, it may not be needed.
Actually we still need this to maintain the state of IO. It would be
useful for the next new driver "Scan Manager".
>
> > +typedef enum {
> > + FREEZE_CTRL_FROZEN = 0,
> > + FREEZE_CTRL_THAWED = 1
> > +} FREEZE_CTRL_CHAN_STATE;
>
> This definitely should not be needed.
Same as above
>
> > +typedef enum {
> > + FREEZE_CHANNEL_0 = 0, /* EMAC_IO & MIXED2_IO */
> > + FREEZE_CHANNEL_1, /* MIXED1_IO and FLASH_IO */
> > + FREEZE_CHANNEL_2, /* General IO */
> > + FREEZE_CHANNEL_3, /* DDR IO */
> > + FREEZE_CHANNEL_UNDEFINED
> > +} FreezeChannelSelect;
>
> CamelCaseIsUnwelcome. And actually haveing enum for numbers 0..3 looks
> like overkill. Could we just use plain numbers?
Good suggestion. We put that initially due to potential hardware change
in initial design. We can remove this now.
>
> > +typedef enum {
> > + FREEZE_CONTROLLER_FSM_SW = 0,
> > + FREEZE_CONTROLLER_FSM_HW,
> > + FREEZE_CONTROLLER_FSM_UNDEFINED
> > +} FreezeControllerFSMSelect;
>
> No longer needed.
Yup :)
>
> > +#define SYSMGR_FRZCTRL_HWCTRL_VIO1STATE_GET(x) (((x) & 0x0006)
> >> 1)
>
> Is this still used?
Nope, no more.
>
> > +#define SYSMGR_FRZCTRL_VIOCTRL_SHIFT 0x2
> > +
> > +u32 sys_mgr_frzctrl_freeze_req(FreezeChannelSelect channel_id,
> > + FreezeControllerFSMSelect fsm_select);
> > +u32 sys_mgr_frzctrl_thaw_req(FreezeChannelSelect channel_id,
> > + FreezeControllerFSMSelect fsm_select);
>
> We can remove second parameter here. And maybe use some more
> reasonable names.
>
> sysmgr_freeze_req / sysmgr_thaw_req?
Yup removed the second parameter. About the name freeze and thaw, its
how its labeled in hardware documentation. :)
>
> Thanks, and sorry for two-phase review.
No problem as you are very supportive.
Thanks
Chin Liang
> Pavel
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 16/17] nitrogen6x: add otg usb host/device mode support
On 9/19/2013 8:29 PM, Troy Kisky wrote:
Signed-off-by: Troy Kisky
---
v4: similar to Nitrogen6x: add otg usb ethernet gadget support
But I added pad setup for over current, otg_id, and power control
Added board_ehci_power function to enable power for host mode.
Removed otg_id selection done now in previous patch.
---
board/boundary/nitrogen6x/nitrogen6x.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/board/boundary/nitrogen6x/nitrogen6x.c
b/board/boundary/nitrogen6x/nitrogen6x.c
index c6efafc..9b07846 100644
--- a/board/boundary/nitrogen6x/nitrogen6x.c
+++ b/board/boundary/nitrogen6x/nitrogen6x.c
@@ -30,6 +30,7 @@
#include
DECLARE_GLOBAL_DATA_PTR;
+#define GP_USB_OTG_PWR IMX_GPIO_NR(3, 22)
#define UART_PAD_CTRL (PAD_CTL_PUS_100K_UP | \
PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | \
@@ -179,6 +180,14 @@ iomux_v3_cfg_t const enet_pads2[] = {
MX6_PAD_RGMII_RX_CTL__RGMII_RX_CTL | MUX_PAD_CTRL(ENET_PAD_CTRL),
};
+static iomux_v3_cfg_t const misc_pads[] = {
+ MX6_PAD_GPIO_1__USBOTG_ID | MUX_PAD_CTRL(WEAK_PULLUP),
+ MX6_PAD_KEY_COL4__USBOH3_USBOTG_OC | MUX_PAD_CTRL(WEAK_PULLUP),
+ MX6_PAD_EIM_D30__USBOH3_USBH1_OC| MUX_PAD_CTRL(WEAK_PULLUP),
+ /* OTG Power enable */
+ MX6_PAD_EIM_D22__GPIO_3_22 | MUX_PAD_CTRL(OUTPUT_40OHM),
+};
+
MX6_PAD_GPIO_1__USBOTG_ID is undefined, so please skip this patch and
let me correct.
The was defined in a patch by Eric that I missed including.
Thanks
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 5/5] B4860QDS: Add support of 2 stage NAND boot loader
On 09/20/2013 04:51 AM, Rommel Custodio wrote: Dear Prabhakar Kushwaha, Prabhakar Kushwaha freescale.com> writes: Thank you for the replies. You mention you use the PBL... but probably not a pblimage. The patch correctly fixes RAMBOOT_PBL as a trigger to generate the pblimage (u- boot.pbl) but there seems to be no RCW or PBI file defined. B4860 does support PBL based NAND boot. but I have yet to integrate u-boot-spl.bin to generated u-boot-spl.pbl. This is in my TODO list This is my understanding (if need be, take it with a grain of salt) The Makefiles need to be modified so that SPL build will create a pblimage. The "mkimage pblimage" needs to be executed only on the SPL binary. Then the top-level Makefile proceeds in concatenating the u-boot-spl.bin (now a pblimage) and u-boot.bin. yes. This is my next plan. I have one question, can this scenario be implemented on a P5040? i.e. simulate that CPC is around 128Kb and load u-boot via SPL? Now all corenet processors seem to only support pblimage booting. yes. This scenario can be implemented for P5040. Only need to create spl.c file + define constants. Seems easy enough :-) though I probably don't have the resources to actually implement it. Just a note. The pblimage booting is not very flexible now. Currently it assumes that u-boot.pbl will fit into CPC (configured as SRAM). This is OK for most processors (i.e P5040 with 1Mb CPC) but it will not work for others (i.e T1040/1042 with only 256Kb CPC). So there is a need to have SPL in this case. Me along with others are owner of T1040 platform. This whole exercise is done for T1040 & future soc which may have < 512K CPC. Once base patch of T1040QDS has been accepted(already in review state). I will send a patch set to add support of 2 Stage boot loader. Regards, Prabhakar ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 2/8] ARM: add secure monitor handler to switch to non-secure state
On Fri, Sep 20, 2013 at 08:08:45AM +0530, Mj Embd wrote: > On Fri, Sep 20, 2013 at 6:12 AM, Christoffer Dall < > christoffer.d...@linaro.org> wrote: > > > On Fri, Sep 20, 2013 at 03:20:15AM +0530, Mj Embd wrote: > > > Just checking, is the mcr p15,0,r1,c1,c1,0 in sync with the following > > text > > > . I could be wrong here, just checking > > > > In the future, if you can comment specifically inline on the lines of > > code you are targeting, it is easier for other people to address your > > concerns. > > > > > > > > B1.5.1 Arm Arch Ref Manual > > > > > >- > > > > > >To avoid security holes, software must not: > > > - > > > > > > — Change from Secure to Non-secure state by using an MSR or CPS > > > instruction > > > to switch from Monitor > > > > The important part here is that we don't change from S to NS by > > modifying the SCR, because monitor mode is always in secure mode, so the > > change only happens on the exception return. > > > > So yes, it's safe. > > > > -Christoffer > > > > Ok. Good Discussion. Thanks, > PS: Gmail auto wraps the previous msg in 3 dots, so sometimes I miss > inlining. > Thanks for pointing out. > No problem, thanks for looking at the code. -Christoffer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 17/17] nitrogen6x: add CONFIG_MV_UDC
Also, add other USB related config items. Signed-off-by: Troy Kisky --- v4: Updated commit message --- include/configs/nitrogen6x.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h index b1ca91e..06f173e 100644 --- a/include/configs/nitrogen6x.h +++ b/include/configs/nitrogen6x.h @@ -30,6 +30,12 @@ #define CONFIG_BOARD_EARLY_INIT_F #define CONFIG_MISC_INIT_R #define CONFIG_MXC_GPIO +#define CONFIG_MV_UDC +#define CONFIG_USBD_HS +#define CONFIG_USB_GADGET_DUALSPEED +#define CONFIG_USB_ETHER +#define CONFIG_USB_ETH_CDC +#define CONFIG_NETCONSOLE #define CONFIG_CMD_FUSE #ifdef CONFIG_CMD_FUSE -- 1.8.1.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 01/17] usb: gadget: mv_udc: don't check CONFIG_USB_MAX_CONTROLLER_COUNT
i.mx6 has 1 otg controller, and 3 host ports. So, CONFIG_USB_MAX_CONTROLLER_COUNT can be greater than 1 even though only 1 device mode controller is supported. Signed-off-by: Troy Kisky --- v4: new patch --- drivers/usb/gadget/mv_udc.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/usb/gadget/mv_udc.c b/drivers/usb/gadget/mv_udc.c index 7574e31..b87119c 100644 --- a/drivers/usb/gadget/mv_udc.c +++ b/drivers/usb/gadget/mv_udc.c @@ -17,10 +17,6 @@ #include #include -#if CONFIG_USB_MAX_CONTROLLER_COUNT > 1 -#error This driver only supports one single controller. -#endif - /* * Check if the system has too long cachelines. If the cachelines are * longer then 128b, the driver will not be able flush/invalidate data -- 1.8.1.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 08/17] usb: gadget: mv_udc: set is_dualspeed = 1
This controller support full and high speed.
Signed-off-by: Troy Kisky
---
v4: no change
---
drivers/usb/gadget/mv_udc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/gadget/mv_udc.c b/drivers/usb/gadget/mv_udc.c
index cc21306..b04ac47 100644
--- a/drivers/usb/gadget/mv_udc.c
+++ b/drivers/usb/gadget/mv_udc.c
@@ -109,6 +109,7 @@ static struct mv_drv controller = {
.gadget = {
.name = "mv_udc",
.ops= &mv_udc_ops,
+ .is_dualspeed = 1,
},
};
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 03/17] usb: gadget: ether set wMaxPacketSize
set wMaxPacketSize for full speed descriptors
fs_source_desc, fs_sink_desc to 64.
Full-speed bulk endpoint can have a maximum packet size of
8, 16, 32, or 64 bytes, so choice 64.
The hs_source_desc, hs_sink_desc, already have their wMaxPacketSize
set to 512. That is the only legal value for high speed bulk endpoints.
Signed-off-by: Troy Kisky
---
v4: expanded commit message
---
drivers/usb/gadget/ether.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index 700d5fb..988cffb 100644
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -635,6 +635,7 @@ fs_source_desc = {
.bEndpointAddress = USB_DIR_IN,
.bmAttributes = USB_ENDPOINT_XFER_BULK,
+ .wMaxPacketSize = __constant_cpu_to_le16(64),
};
static struct usb_endpoint_descriptor
@@ -644,6 +645,7 @@ fs_sink_desc = {
.bEndpointAddress = USB_DIR_OUT,
.bmAttributes = USB_ENDPOINT_XFER_BULK,
+ .wMaxPacketSize = __constant_cpu_to_le16(64),
};
static const struct usb_descriptor_header *fs_eth_function[11] = {
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 11/17] usb: gadget: mv_udc: flush item before head
Make sure the transfer descriptor is flushed
before the queue is updated so that the controller
will not see old information.
Signed-off-by: Troy Kisky
---
v4: no change
---
drivers/usb/gadget/mv_udc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/mv_udc.c b/drivers/usb/gadget/mv_udc.c
index 97bab93..075b039 100644
--- a/drivers/usb/gadget/mv_udc.c
+++ b/drivers/usb/gadget/mv_udc.c
@@ -347,21 +347,20 @@ static int mv_ep_queue(struct usb_ep *ep,
item->info = INFO_BYTES(len) | INFO_IOC | INFO_ACTIVE;
item->page0 = (uint32_t)mv_ep->b_buf;
item->page1 = ((uint32_t)mv_ep->b_buf & 0xf000) + 0x1000;
+ mv_flush_qtd(num);
head->next = (unsigned) item;
head->info = 0;
DBG("ept%d %s queue len %x, buffer %p\n",
num, in ? "in" : "out", len, mv_ep->b_buf);
+ mv_flush_qh(num);
if (in)
bit = EPT_TX(num);
else
bit = EPT_RX(num);
- mv_flush_qh(num);
- mv_flush_qtd(num);
-
writel(bit, &udc->epprime);
return 0;
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 04/17] usb: gadget: ether: return error from rx_submit if no request
This prevents a crash if tftpboot is given a bad filename.
rx_req will be released by eth_reset_config
which is called by eth_disconnect,
which is called using the .disconnect member of usb_gadget_driver by mv_pullup
in mv_udc
which is called using the .pullup member of usb_gadget_ops by
usb_gadget_disconnect
which is called by usb_eth_halt
which is called using the .halt member of eth_device by eth_halt
which is called by TftpHandler when TFTP_ERR_FILE_NOT_FOUND or
TFTP_ERR_ACCESS_DENIED occurs
Signed-off-by: Troy Kisky
---
v4: expanded commit message
---
drivers/usb/gadget/ether.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index 988cffb..cc6cc1f 100644
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -1536,6 +1536,8 @@ static int rx_submit(struct eth_dev *dev, struct
usb_request *req,
*/
debug("%s\n", __func__);
+ if (!req)
+ return -EINVAL;
size = (ETHER_HDR_SIZE + dev->mtu + RX_EXTRA);
size += dev->out_ep->maxpacket - 1;
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 15/17] mx6: iomux: add GPR1 defines for use with nitrogen6x
Select GPIO1 as the USB OTG ID pin for Nitrogen6x
Signed-off-by: Troy Kisky
---
v4: move the Nitrogen6x bits into this patch as well
---
arch/arm/include/asm/arch-mx6/iomux.h | 6 ++
board/boundary/nitrogen6x/nitrogen6x.c | 7 +++
2 files changed, 13 insertions(+)
diff --git a/arch/arm/include/asm/arch-mx6/iomux.h
b/arch/arm/include/asm/arch-mx6/iomux.h
index f4cfd4f..9e6d40f 100644
--- a/arch/arm/include/asm/arch-mx6/iomux.h
+++ b/arch/arm/include/asm/arch-mx6/iomux.h
@@ -10,6 +10,12 @@
#define MX6_IOMUXC_GPR70x020e001c
/*
+ * IOMUXC_GPR1 bit fields
+ */
+#define IOMUXC_GPR1_OTG_ID_ENET_RX_ERR (0<<13)
+#define IOMUXC_GPR1_OTG_ID_GPIO1 (1<<13)
+#define IOMUXC_GPR1_OTG_ID_MASK(1<<13)
+/*
* IOMUXC_GPR13 bit fields
*/
#define IOMUXC_GPR13_SDMA_STOP_REQ (1<<30)
diff --git a/board/boundary/nitrogen6x/nitrogen6x.c
b/board/boundary/nitrogen6x/nitrogen6x.c
index f664f6d..c6efafc 100644
--- a/board/boundary/nitrogen6x/nitrogen6x.c
+++ b/board/boundary/nitrogen6x/nitrogen6x.c
@@ -704,6 +704,13 @@ int overwrite_console(void)
int board_init(void)
{
+ struct iomuxc_base_regs *const iomuxc_regs
+ = (struct iomuxc_base_regs *)IOMUXC_BASE_ADDR;
+
+ clrsetbits_le32(&iomuxc_regs->gpr[1],
+ IOMUXC_GPR1_OTG_ID_MASK,
+ IOMUXC_GPR1_OTG_ID_GPIO1);
+
/* address of boot parameters */
gd->bd->bi_boot_params = PHYS_SDRAM + 0x100;
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 09/17] usb: gadget: mv_udc: fix full speed connections
Set maximum packet length in queue header to wMaxPacketSize
of endpoint.
Signed-off-by: Troy Kisky
---
v4: no change
---
drivers/usb/gadget/mv_udc.c | 48 -
1 file changed, 34 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/gadget/mv_udc.c b/drivers/usb/gadget/mv_udc.c
index b04ac47..c2df749 100644
--- a/drivers/usb/gadget/mv_udc.c
+++ b/drivers/usb/gadget/mv_udc.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -213,7 +214,7 @@ static void mv_ep_free_request(struct usb_ep *ep, struct
usb_request *_req)
return;
}
-static void ep_enable(int num, int in)
+static void ep_enable(int num, int in, int maxpacket)
{
struct ept_queue_head *head;
struct mv_udc *udc = (struct mv_udc *)controller.ctrl->hcor;
@@ -227,7 +228,7 @@ static void ep_enable(int num, int in)
n |= (CTRL_RXE | CTRL_RXR | CTRL_RXT_BULK);
if (num != 0) {
- head->config = CONFIG_MAX_PKT(EP_MAX_PACKET_SIZE) | CONFIG_ZLT;
+ head->config = CONFIG_MAX_PKT(maxpacket) | CONFIG_ZLT;
mv_flush_qh(num);
}
writel(n, &udc->epctrl[num]);
@@ -240,8 +241,21 @@ static int mv_ep_enable(struct usb_ep *ep,
int num, in;
num = desc->bEndpointAddress & USB_ENDPOINT_NUMBER_MASK;
in = (desc->bEndpointAddress & USB_DIR_IN) != 0;
- ep_enable(num, in);
mv_ep->desc = desc;
+
+ if (num) {
+ int max = get_unaligned_le16(&desc->wMaxPacketSize);
+
+ if ((max > 64) && (controller.gadget.speed == USB_SPEED_FULL))
+ max = 64;
+ if (ep->maxpacket != max) {
+ DBG("%s: from %d to %d\n", __func__,
+ ep->maxpacket, max);
+ ep->maxpacket = max;
+ }
+ }
+ ep_enable(num, in, ep->maxpacket);
+ DBG("%s: num=%d maxpacket=%d\n", __func__, num, ep->maxpacket);
return 0;
}
@@ -414,14 +428,16 @@ static void handle_setup(void)
if ((r.wValue == 0) && (r.wLength == 0)) {
req->length = 0;
for (i = 0; i < NUM_ENDPOINTS; i++) {
- if (!controller.ep[i].desc)
+ struct mv_ep *ep = &controller.ep[i];
+
+ if (!ep->desc)
continue;
- num = controller.ep[i].desc->bEndpointAddress
+ num = ep->desc->bEndpointAddress
& USB_ENDPOINT_NUMBER_MASK;
- in = (controller.ep[i].desc->bEndpointAddress
+ in = (ep->desc->bEndpointAddress
& USB_DIR_IN) != 0;
if ((num == _num) && (in == _in)) {
- ep_enable(num, in);
+ ep_enable(num, in, ep->ep.maxpacket);
usb_ep_queue(controller.gadget.ep0,
req, 0);
break;
@@ -505,15 +521,19 @@ void udc_irq(void)
DBG("-- suspend --\n");
if (n & STS_PCI) {
- DBG("-- portchange --\n");
+ int max = 64;
+ int speed = USB_SPEED_FULL;
+
bit = (readl(&udc->portsc) >> 26) & 3;
+ DBG("-- portchange %x %s\n", bit, (bit == 2) ? "High" : "Full");
if (bit == 2) {
- controller.gadget.speed = USB_SPEED_HIGH;
- for (i = 1; i < NUM_ENDPOINTS && n; i++)
- if (controller.ep[i].desc)
- controller.ep[i].ep.maxpacket = 512;
- } else {
- controller.gadget.speed = USB_SPEED_FULL;
+ speed = USB_SPEED_HIGH;
+ max = 512;
+ }
+ controller.gadget.speed = speed;
+ for (i = 1; i < NUM_ENDPOINTS; i++) {
+ if (controller.ep[i].ep.maxpacket > max)
+ controller.ep[i].ep.maxpacket = max;
}
}
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 12/17] usb: gadget: mv_udc: optimize ep_enable
Only get head if not ep0.
Signed-off-by: Troy Kisky
---
v4: no change
---
drivers/usb/gadget/mv_udc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/mv_udc.c b/drivers/usb/gadget/mv_udc.c
index 075b039..995585d 100644
--- a/drivers/usb/gadget/mv_udc.c
+++ b/drivers/usb/gadget/mv_udc.c
@@ -216,10 +216,8 @@ static void mv_ep_free_request(struct usb_ep *ep, struct
usb_request *_req)
static void ep_enable(int num, int in, int maxpacket)
{
- struct ept_queue_head *head;
struct mv_udc *udc = (struct mv_udc *)controller.ctrl->hcor;
unsigned n;
- head = mv_get_qh(num, in);
n = readl(&udc->epctrl[num]);
if (in)
@@ -228,6 +226,8 @@ static void ep_enable(int num, int in, int maxpacket)
n |= (CTRL_RXE | CTRL_RXR | CTRL_RXT_BULK);
if (num != 0) {
+ struct ept_queue_head *head = mv_get_qh(num, in);
+
head->config = CONFIG_MAX_PKT(maxpacket) | CONFIG_ZLT;
mv_flush_qh(num);
}
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 05/17] usb: gadget: mv_udc: split mv_udc.h file
Move defines only needed by mv_udc.c to a file
in the same directory.
This allows usbtty to compile for mv_udc,
but it still doesn't link.
Signed-off-by: Troy Kisky
---
v4: unchanged
---
drivers/usb/gadget/mv_udc.c | 6 +++
drivers/usb/gadget/mv_udc.h | 115 ++
include/usb/mv_udc.h| 118
3 files changed, 121 insertions(+), 118 deletions(-)
create mode 100644 drivers/usb/gadget/mv_udc.h
diff --git a/drivers/usb/gadget/mv_udc.c b/drivers/usb/gadget/mv_udc.c
index b87119c..322c04f 100644
--- a/drivers/usb/gadget/mv_udc.c
+++ b/drivers/usb/gadget/mv_udc.c
@@ -13,9 +13,15 @@
#include
#include
#include
+#include
#include
+#include
#include
+#include
+#include
#include
+#include "../host/ehci.h"
+#include "mv_udc.h"
/*
* Check if the system has too long cachelines. If the cachelines are
diff --git a/drivers/usb/gadget/mv_udc.h b/drivers/usb/gadget/mv_udc.h
new file mode 100644
index 000..c7d8b33
--- /dev/null
+++ b/drivers/usb/gadget/mv_udc.h
@@ -0,0 +1,115 @@
+/*
+ * Copyright 2011, Marvell Semiconductor Inc.
+ *
+ * Licensed under the GPL-2 or later.
+ */
+#ifndef __GADGET__MV_UDC_H__
+#define __GADGET__MV_UDC_H__
+
+#define NUM_ENDPOINTS 6
+
+struct mv_udc {
+#define MICRO_8FRAME 0x8
+#define USBCMD_ITC(x) x) > 0xff) ? 0xff : x) << 16)
+#define USBCMD_FS2 (1 << 15)
+#define USBCMD_RST (1 << 1)
+#define USBCMD_RUN (1)
+ u32 usbcmd; /* 0x140 */
+#define STS_SLI(1 << 8)
+#define STS_URI(1 << 6)
+#define STS_PCI(1 << 2)
+#define STS_UEI(1 << 1)
+#define STS_UI (1 << 0)
+ u32 usbsts; /* 0x144 */
+ u32 pad1[3];
+ u32 devaddr;/* 0x154 */
+ u32 epinitaddr; /* 0x158 */
+ u32 pad2[10];
+#define PTS_ENABLE 2
+#define PTS(x) (((x) & 0x3) << 30)
+#define PFSC (1 << 24)
+ u32 portsc; /* 0x184 */
+ u32 pad3[8];
+#define USBMODE_DEVICE 2
+ u32 usbmode;/* 0x1a8 */
+ u32 epstat; /* 0x1ac */
+#define EPT_TX(x) (1 << (((x) & 0x) + 16))
+#define EPT_RX(x) (1 << ((x) & 0x))
+ u32 epprime;/* 0x1b0 */
+ u32 epflush;/* 0x1b4 */
+ u32 pad4;
+ u32 epcomp; /* 0x1bc */
+#define CTRL_TXE (1 << 23)
+#define CTRL_TXR (1 << 22)
+#define CTRL_RXE (1 << 7)
+#define CTRL_RXR (1 << 6)
+#define CTRL_TXT_BULK (2 << 18)
+#define CTRL_RXT_BULK (2 << 2)
+ u32 epctrl[16]; /* 0x1c0 */
+};
+
+struct mv_ep {
+ struct usb_ep ep;
+ struct list_head queue;
+ const struct usb_endpoint_descriptor *desc;
+
+ struct usb_request req;
+ uint8_t *b_buf;
+ uint32_t b_len;
+ uint8_t b_fast[64] __aligned(ARCH_DMA_MINALIGN);
+};
+
+struct mv_drv {
+ struct usb_gadget gadget;
+ struct usb_gadget_driver*driver;
+ struct ehci_ctrl*ctrl;
+ struct ept_queue_head *epts;
+ struct ept_queue_item *items[2 * NUM_ENDPOINTS];
+ uint8_t *items_mem;
+ struct mv_epep[NUM_ENDPOINTS];
+};
+
+struct ept_queue_head {
+ unsigned config;
+ unsigned current; /* read-only */
+
+ unsigned next;
+ unsigned info;
+ unsigned page0;
+ unsigned page1;
+ unsigned page2;
+ unsigned page3;
+ unsigned page4;
+ unsigned reserved_0;
+
+ unsigned char setup_data[8];
+
+ unsigned reserved_1;
+ unsigned reserved_2;
+ unsigned reserved_3;
+ unsigned reserved_4;
+};
+
+#define CONFIG_MAX_PKT(n) ((n) << 16)
+#define CONFIG_ZLT (1 << 29) /* stop on zero-len xfer */
+#define CONFIG_IOS (1 << 15) /* IRQ on setup */
+
+struct ept_queue_item {
+ unsigned next;
+ unsigned info;
+ unsigned page0;
+ unsigned page1;
+ unsigned page2;
+ unsigned page3;
+ unsigned page4;
+ unsigned reserved;
+};
+
+#define TERMINATE 1
+#define INFO_BYTES(n) ((n) << 16)
+#define INFO_IOC (1 << 15)
+#define INFO_ACTIVE(1 << 7)
+#define INFO_HALTED(1 << 6)
+#define INFO_BUFFER_ERROR (1 << 5)
+#define INFO_TX_ERROR (1 << 3)
+#endif
diff --git a/include/usb/mv_udc.h b/include/usb/mv_udc.h
index c71516c..f6c7b5e 100644
--- a/include/usb/mv_udc.h
+++ b/include/usb/mv_udc.h
@@ -9,124 +9,6 @@
#ifndef __MV_UDC_H__
#define __MV_UDC_H__
-#include
-#include
-#include
-#include
-
-#include "../../drivers/usb/host/ehci.h"
-
-#define NUM_ENDPOINTS 6
-
-/* Endpoint parameters */
-#define MAX_ENDPOINTS 4
-
#define EP_MAX_PACKET_SIZE 0x200
#define EP0_MAX_PACKET_SIZE64
-
-struct mv_udc {
-#define MI
[U-Boot] [PATCH V4 13/17] usb: gadget: mv_udc: zero transfer descriptor memory on probe
Since we flush the TD, we may as well set it to a known value.
Signed-off-by: Troy Kisky
---
v4: no change
---
drivers/usb/gadget/mv_udc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/gadget/mv_udc.c b/drivers/usb/gadget/mv_udc.c
index 995585d..ea296cc 100644
--- a/drivers/usb/gadget/mv_udc.c
+++ b/drivers/usb/gadget/mv_udc.c
@@ -643,6 +643,7 @@ static int mvudc_probe(void)
free(controller.epts);
return -ENOMEM;
}
+ memset(controller.items_mem, 0, ilist_sz);
for (i = 0; i < 2 * NUM_ENDPOINTS; i++) {
/*
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 06/17] usb: udc: add udc.h include file
Move common definitions to udc.h
This allows musb_udc.h to be removed as well.
Signed-off-by: Troy Kisky
---
v4: updated commit message
removed ifdef UDC_BULK_HS_PACKET_SIZE since 512
is the only legal value, it shouldn't be overridden.
---
drivers/serial/usbtty.h | 3 +-
drivers/usb/gadget/designware_udc.c | 1 +
drivers/usb/gadget/mpc8xx_udc.c | 1 +
drivers/usb/gadget/omap1510_udc.c | 1 +
drivers/usb/gadget/pxa27x_udc.c | 1 +
drivers/usb/musb/musb_udc.c | 3 +-
include/usb/designware_udc.h| 31 ---
include/usb/mpc8xx_udc.h| 19 +---
include/usb/musb_udc.h | 40
include/usb/omap1510_udc.h | 27 ++--
include/usb/pxa27x_udc.h| 26 +---
include/usb/udc.h | 61 +
12 files changed, 73 insertions(+), 141 deletions(-)
delete mode 100644 include/usb/musb_udc.h
create mode 100644 include/usb/udc.h
diff --git a/drivers/serial/usbtty.h b/drivers/serial/usbtty.h
index e243a8e..819dec6 100644
--- a/drivers/serial/usbtty.h
+++ b/drivers/serial/usbtty.h
@@ -16,8 +16,6 @@
#include
#elif defined(CONFIG_OMAP1510)
#include
-#elif defined(CONFIG_MUSB_UDC)
-#include
#elif defined(CONFIG_CPU_PXA27X)
#include
#elif defined(CONFIG_DW_UDC)
@@ -26,6 +24,7 @@
#include
#endif
+#include
#include
/* If no VendorID/ProductID is defined in config.h, pretend to be Linux
diff --git a/drivers/usb/gadget/designware_udc.c
b/drivers/usb/gadget/designware_udc.c
index 1aab31b..b7c1038 100644
--- a/drivers/usb/gadget/designware_udc.c
+++ b/drivers/usb/gadget/designware_udc.c
@@ -14,6 +14,7 @@
#include
#include "ep0.h"
#include
+#include
#include
#define UDC_INIT_MDELAY80 /* Device settle delay */
diff --git a/drivers/usb/gadget/mpc8xx_udc.c b/drivers/usb/gadget/mpc8xx_udc.c
index 0207d39..7f72972 100644
--- a/drivers/usb/gadget/mpc8xx_udc.c
+++ b/drivers/usb/gadget/mpc8xx_udc.c
@@ -47,6 +47,7 @@
#include
#include
#include
+#include
#include "ep0.h"
diff --git a/drivers/usb/gadget/omap1510_udc.c
b/drivers/usb/gadget/omap1510_udc.c
index 8553fe5..bdc1b88 100644
--- a/drivers/usb/gadget/omap1510_udc.c
+++ b/drivers/usb/gadget/omap1510_udc.c
@@ -20,6 +20,7 @@
#endif
#include
#include
+#include
#include "ep0.h"
diff --git a/drivers/usb/gadget/pxa27x_udc.c b/drivers/usb/gadget/pxa27x_udc.c
index 05d1b56..733558d 100644
--- a/drivers/usb/gadget/pxa27x_udc.c
+++ b/drivers/usb/gadget/pxa27x_udc.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include "ep0.h"
diff --git a/drivers/usb/musb/musb_udc.c b/drivers/usb/musb/musb_udc.c
index 3e3e05e..87640f4 100644
--- a/drivers/usb/musb/musb_udc.c
+++ b/drivers/usb/musb/musb_udc.c
@@ -39,7 +39,8 @@
*/
#include
-#include
+#include
+#include
#include "../gadget/ep0.h"
#include "musb_core.h"
#if defined(CONFIG_USB_OMAP3)
diff --git a/include/usb/designware_udc.h b/include/usb/designware_udc.h
index 2e29a7e..2e1cdf1 100644
--- a/include/usb/designware_udc.h
+++ b/include/usb/designware_udc.h
@@ -174,19 +174,6 @@ struct udcfifo_regs {
};
/*
- * USBTTY definitions
- */
-#define EP0_MAX_PACKET_SIZE 64
-#define UDC_INT_ENDPOINT 1
-#define UDC_INT_PACKET_SIZE 64
-#define UDC_OUT_ENDPOINT 2
-#define UDC_BULK_PACKET_SIZE 64
-#define UDC_BULK_HS_PACKET_SIZE 512
-#define UDC_IN_ENDPOINT 3
-#define UDC_OUT_PACKET_SIZE 64
-#define UDC_IN_PACKET_SIZE64
-
-/*
* UDC endpoint definitions
*/
#define UDC_EP0 0
@@ -194,22 +181,4 @@ struct udcfifo_regs {
#define UDC_EP2 2
#define UDC_EP3 3
-/*
- * Function declarations
- */
-
-void udc_irq(void);
-
-void udc_set_nak(int epid);
-void udc_unset_nak(int epid);
-int udc_endpoint_write(struct usb_endpoint_instance *endpoint);
-int udc_init(void);
-void udc_enable(struct usb_device_instance *device);
-void udc_disable(void);
-void udc_connect(void);
-void udc_disconnect(void);
-void udc_startup_events(struct usb_device_instance *device);
-void udc_setup_ep(struct usb_device_instance *device, unsigned int ep,
- struct usb_endpoint_instance *endpoint);
-
#endif /* __DW_UDC_H */
diff --git a/include/usb/mpc8xx_udc.h b/include/usb/mpc8xx_udc.h
index 475dd41..9906c75 100644
--- a/include/usb/mpc8xx_udc.h
+++ b/include/usb/mpc8xx_udc.h
@@ -111,11 +111,9 @@
/* UDC device defines */
#define EP0_MAX_PACKET_SIZEEP_MAX_PKT
-#define UDC_OUT_ENDPOINT 0x02
+
#define UDC_OUT_PACKET_SIZEEP_MIN_PACKET_SIZE
-#define UDC_IN_ENDPOINT0x03
#define UDC_IN_PACKET_SIZE EP_MIN_PACKET_SIZE
-#define UDC_INT_ENDPOINT 0x01
#define UDC_INT_PACKET_SIZEUDC_IN_PACKET_SIZE
#define UDC_BULK_PACKET_SIZE EP_MIN_PACKET_SIZE
@@ -178,18 +176,
[U-Boot] [PATCH V4 07/17] usb: gadget: mv_udc: fix typo in error message
Change 'nfo=' to 'info='
Signed-off-by: Troy Kisky
---
v4: no change
---
drivers/usb/gadget/mv_udc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/mv_udc.c b/drivers/usb/gadget/mv_udc.c
index 322c04f..cc21306 100644
--- a/drivers/usb/gadget/mv_udc.c
+++ b/drivers/usb/gadget/mv_udc.c
@@ -368,8 +368,8 @@ static void handle_ep_complete(struct mv_ep *ep)
mv_invalidate_qtd(num);
if (item->info & 0xff)
- printf("EP%d/%s FAIL nfo=%x pg0=%x\n",
- num, in ? "in" : "out", item->info, item->page0);
+ printf("EP%d/%s FAIL info=%x pg0=%x\n",
+ num, in ? "in" : "out", item->info, item->page0);
len = (item->info >> 16) & 0x7fff;
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 00/17] Make mv_udc work for i.mx6
Hi Marek, Stefano Sorry, for the long delay between postings. This series is based on u-boot-usb/master branch. After this series, nitrogen6x works with tftpboot to transfer files over usb, and will recognize a usb stick in the OTG port. This V4 has been rebased to the latest u-boot-usb/master branch and changed to address Marek comments. The most noticeable change is the addition of "add support for host mode otg port" Stefano, if you would you like to take the last 3 patches, there should not be a problem. The patches are mostly independent, so if a patch has an issue, please feel free to skip it. An exception is 1/17 should be before 2/17 if Stefano's branch merges upstream first, otherwise nitrogen6x will get a build error. Thanks Troy Kisky (17): usb: gadget: mv_udc: don't check CONFIG_USB_MAX_CONTROLLER_COUNT usb: ehci-mx6: add support for host mode otg port usb: gadget: ether set wMaxPacketSize usb: gadget: ether: return error from rx_submit if no request usb: gadget: mv_udc: split mv_udc.h file usb: udc: add udc.h include file usb: gadget: mv_udc: fix typo in error message usb: gadget: mv_udc: set is_dualspeed = 1 usb: gadget: mv_udc: fix full speed connections usb: gadget: mv_udc: optimize bounce usb: gadget: mv_udc: flush item before head usb: gadget: mv_udc: optimize ep_enable usb: gadget: mv_udc: zero transfer descriptor memory on probe usb: gadget: mv_udc: clear desc upon ep_disable mx6: iomux: add GPR1 defines for use with nitrogen6x nitrogen6x: add otg usb host/device mode support nitrogen6x: add CONFIG_MV_UDC arch/arm/include/asm/arch-mx6/iomux.h | 6 ++ board/boundary/nitrogen6x/nitrogen6x.c | 33 drivers/serial/usbtty.h| 3 +- drivers/usb/gadget/designware_udc.c| 1 + drivers/usb/gadget/ether.c | 4 + drivers/usb/gadget/mpc8xx_udc.c| 1 + drivers/usb/gadget/mv_udc.c| 113 --- drivers/usb/gadget/mv_udc.h| 115 drivers/usb/gadget/omap1510_udc.c | 1 + drivers/usb/gadget/pxa27x_udc.c| 1 + drivers/usb/host/ehci-hcd.c| 7 ++ drivers/usb/host/ehci-mx6.c| 135 +++-- drivers/usb/musb/musb_udc.c| 3 +- include/configs/mx6qsabreauto.h| 2 +- include/configs/nitrogen6x.h | 8 +- include/usb/designware_udc.h | 31 include/usb/mpc8xx_udc.h | 19 + include/usb/musb_udc.h | 40 -- include/usb/mv_udc.h | 118 include/usb/omap1510_udc.h | 27 +-- include/usb/pxa27x_udc.h | 26 +-- include/usb/udc.h | 61 +++ 22 files changed, 409 insertions(+), 346 deletions(-) create mode 100644 drivers/usb/gadget/mv_udc.h delete mode 100644 include/usb/musb_udc.h create mode 100644 include/usb/udc.h -- 1.8.1.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 16/17] nitrogen6x: add otg usb host/device mode support
Signed-off-by: Troy Kisky
---
v4: similar to Nitrogen6x: add otg usb ethernet gadget support
But I added pad setup for over current, otg_id, and power control
Added board_ehci_power function to enable power for host mode.
Removed otg_id selection done now in previous patch.
---
board/boundary/nitrogen6x/nitrogen6x.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/board/boundary/nitrogen6x/nitrogen6x.c
b/board/boundary/nitrogen6x/nitrogen6x.c
index c6efafc..9b07846 100644
--- a/board/boundary/nitrogen6x/nitrogen6x.c
+++ b/board/boundary/nitrogen6x/nitrogen6x.c
@@ -30,6 +30,7 @@
#include
DECLARE_GLOBAL_DATA_PTR;
+#define GP_USB_OTG_PWR IMX_GPIO_NR(3, 22)
#define UART_PAD_CTRL (PAD_CTL_PUS_100K_UP | \
PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | \
@@ -179,6 +180,14 @@ iomux_v3_cfg_t const enet_pads2[] = {
MX6_PAD_RGMII_RX_CTL__RGMII_RX_CTL | MUX_PAD_CTRL(ENET_PAD_CTRL),
};
+static iomux_v3_cfg_t const misc_pads[] = {
+ MX6_PAD_GPIO_1__USBOTG_ID | MUX_PAD_CTRL(WEAK_PULLUP),
+ MX6_PAD_KEY_COL4__USBOH3_USBOTG_OC | MUX_PAD_CTRL(WEAK_PULLUP),
+ MX6_PAD_EIM_D30__USBOH3_USBH1_OC| MUX_PAD_CTRL(WEAK_PULLUP),
+ /* OTG Power enable */
+ MX6_PAD_EIM_D22__GPIO_3_22 | MUX_PAD_CTRL(OUTPUT_40OHM),
+};
+
/* wl1271 pads on nitrogen6x */
iomux_v3_cfg_t const wl12xx_pads[] = {
(MX6_PAD_NANDF_CS1__GPIO_6_14 & ~MUX_PAD_CTRL_MASK)
@@ -250,6 +259,15 @@ int board_ehci_hcd_init(int port)
return 0;
}
+
+int board_ehci_power(int port, int on)
+{
+ if (port)
+ return 0;
+ gpio_set_value(GP_USB_OTG_PWR, on);
+ return 0;
+}
+
#endif
#ifdef CONFIG_FSL_ESDHC
@@ -369,6 +387,11 @@ int board_eth_init(bd_t *bis)
free(bus);
}
#endif
+
+#ifdef CONFIG_MV_UDC
+ /* For otg ethernet*/
+ usb_eth_initialize(bis);
+#endif
return 0;
}
@@ -683,6 +706,7 @@ int board_early_init_f(void)
gpio_direction_input(WL12XX_WL_IRQ_GP);
gpio_direction_output(WL12XX_WL_ENABLE_GP, 0);
gpio_direction_output(WL12XX_BT_ENABLE_GP, 0);
+ gpio_direction_output(GP_USB_OTG_PWR, 0); /* OTG power off */
imx_iomux_v3_setup_multiple_pads(wl12xx_pads, ARRAY_SIZE(wl12xx_pads));
setup_buttons();
@@ -711,6 +735,8 @@ int board_init(void)
IOMUXC_GPR1_OTG_ID_MASK,
IOMUXC_GPR1_OTG_ID_GPIO1);
+ imx_iomux_v3_setup_multiple_pads(misc_pads, ARRAY_SIZE(misc_pads));
+
/* address of boot parameters */
gd->bd->bi_boot_params = PHYS_SDRAM + 0x100;
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 14/17] usb: gadget: mv_udc: clear desc upon ep_disable
desc is set at ep_enable, so for symmetry,
clear it at ep_disable.
Signed-off-by: Troy Kisky
v4: no change
---
drivers/usb/gadget/mv_udc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/gadget/mv_udc.c b/drivers/usb/gadget/mv_udc.c
index ea296cc..766df7f 100644
--- a/drivers/usb/gadget/mv_udc.c
+++ b/drivers/usb/gadget/mv_udc.c
@@ -261,6 +261,9 @@ static int mv_ep_enable(struct usb_ep *ep,
static int mv_ep_disable(struct usb_ep *ep)
{
+ struct mv_ep *mv_ep = container_of(ep, struct mv_ep, ep);
+
+ mv_ep->desc = NULL;
return 0;
}
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 10/17] usb: gadget: mv_udc: optimize bounce
Only perform one copy, either in the bounce
routine for IN transfers, or the debounce
rtn for OUT transfer.
On out transfers, only copy the number
of bytes received from the bounce buffer
Signed-off-by: Troy Kisky
---
v4: no change
---
drivers/usb/gadget/mv_udc.c | 37 -
1 file changed, 16 insertions(+), 21 deletions(-)
diff --git a/drivers/usb/gadget/mv_udc.c b/drivers/usb/gadget/mv_udc.c
index c2df749..97bab93 100644
--- a/drivers/usb/gadget/mv_udc.c
+++ b/drivers/usb/gadget/mv_udc.c
@@ -264,7 +264,7 @@ static int mv_ep_disable(struct usb_ep *ep)
return 0;
}
-static int mv_bounce(struct mv_ep *ep)
+static int mv_bounce(struct mv_ep *ep, int in)
{
uint32_t addr = (uint32_t)ep->req.buf;
uint32_t ba;
@@ -293,8 +293,8 @@ align:
if (!ep->b_buf)
return -ENOMEM;
}
-
- memcpy(ep->b_buf, ep->req.buf, ep->req.length);
+ if (in)
+ memcpy(ep->b_buf, ep->req.buf, ep->req.length);
flush:
ba = (uint32_t)ep->b_buf;
@@ -303,29 +303,25 @@ flush:
return 0;
}
-static void mv_debounce(struct mv_ep *ep)
+static void mv_debounce(struct mv_ep *ep, int in)
{
uint32_t addr = (uint32_t)ep->req.buf;
uint32_t ba = (uint32_t)ep->b_buf;
+ if (in) {
+ if (addr == ba)
+ return; /* not a bounce */
+ goto free;
+ }
invalidate_dcache_range(ba, ba + ep->b_len);
- /* Input buffer address is not aligned. */
- if (addr & (ARCH_DMA_MINALIGN - 1))
- goto copy;
-
- /* Input buffer length is not aligned. */
- if (ep->req.length & (ARCH_DMA_MINALIGN - 1))
- goto copy;
-
- /* The buffer is well aligned, only invalidate cache. */
- return;
+ if (addr == ba)
+ return; /* not a bounce */
-copy:
memcpy(ep->req.buf, ep->b_buf, ep->req.length);
-
+free:
/* Large payloads use allocated buffer, free it. */
- if (ep->req.length > 64)
+ if (ep->b_buf != ep->b_fast)
free(ep->b_buf);
}
@@ -343,7 +339,7 @@ static int mv_ep_queue(struct usb_ep *ep,
head = mv_get_qh(num, in);
len = req->length;
- ret = mv_bounce(mv_ep);
+ ret = mv_bounce(mv_ep, in);
if (ret)
return ret;
@@ -387,10 +383,9 @@ static void handle_ep_complete(struct mv_ep *ep)
num, in ? "in" : "out", item->info, item->page0);
len = (item->info >> 16) & 0x7fff;
-
- mv_debounce(ep);
-
ep->req.length -= len;
+ mv_debounce(ep, in);
+
DBG("ept%d %s complete %x\n",
num, in ? "in" : "out", len);
ep->req.complete(&ep->ep, &ep->req);
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 02/17] usb: ehci-mx6: add support for host mode otg port
Previously, only host1 was supported using an index of 0.
Now, otg has index 0, host1 is 1, host2 is 2, host3 is 3.
Since OTG requires usbmode to be set after reset, I added
a weak function ehci_hcd_init_after_reset to handle this,
and removed it from ehci_hcd_init. I also added a weak
function board_ehci_power to handle turning power on/off
for otg.
Signed-off-by: Troy Kisky
---
V4: new patch, replaces "usb: gadget: mv_udc: fix hardware udc address for
i.MX6"
and has the bonus of giving OTG host mode support
---
drivers/usb/host/ehci-hcd.c | 7 +++
drivers/usb/host/ehci-mx6.c | 135
include/configs/mx6qsabreauto.h | 2 +-
include/configs/nitrogen6x.h| 2 +-
4 files changed, 105 insertions(+), 41 deletions(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index fdad739..3c570ef 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -881,6 +881,11 @@ int usb_lowlevel_stop(int index)
return ehci_hcd_stop(index);
}
+int __weak ehci_hcd_init_after_reset(int index)
+{
+ return 0;
+}
+
int usb_lowlevel_init(int index, void **controller)
{
uint32_t reg;
@@ -900,6 +905,8 @@ int usb_lowlevel_init(int index, void **controller)
if (ehci_hcd_init(index, &ehcic[index].hccr, &ehcic[index].hcor))
return -1;
#endif
+ ehci_hcd_init_after_reset(index);
+
/* Set the high address word (aka segment) for 64-bit controller */
if (ehci_readl(&ehcic[index].hccr->cr_hccparams) & 1)
ehci_writel(ehcic[index].hcor->or_ctrldssegment, 0);
diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c
index eb24af5..41b444e 100644
--- a/drivers/usb/host/ehci-mx6.c
+++ b/drivers/usb/host/ehci-mx6.c
@@ -35,6 +35,7 @@
#define USBPHY_CTRL_CLKGATE0x4000
#define USBPHY_CTRL_ENUTMILEVEL3 0x8000
#define USBPHY_CTRL_ENUTMILEVEL2 0x4000
+#define USBPHY_CTRL_OTD_ID_BIT 27
#define ANADIG_USB2_CHRG_DETECT_EN_B 0x0010
#define ANADIG_USB2_CHRG_DETECT_CHK_CHRG_B 0x0008
@@ -49,52 +50,83 @@
#define UCTRL_OVER_CUR_DIS (1 << 7) /* Disable OTG Overcurrent Detection */
/* USBCMD */
-#define UH1_USBCMD_OFFSET 0x140
#define UCMD_RUN_STOP (1 << 0) /* controller run/stop */
#define UCMD_RESET (1 << 1) /* controller reset */
-static void usbh1_internal_phy_clock_gate(int on)
+static const unsigned phy_bases[] = {
+ USB_PHY0_BASE_ADDR,
+ USB_PHY1_BASE_ADDR,
+};
+
+static void usb_internal_phy_clock_gate(int index, int on)
{
- void __iomem *phy_reg = (void __iomem *)USB_PHY1_BASE_ADDR;
+ void __iomem *phy_reg;
+
+ if (index >= ARRAY_SIZE(phy_bases))
+ return;
+ phy_reg = (void __iomem *)phy_bases[index];
phy_reg += on ? USBPHY_CTRL_CLR : USBPHY_CTRL_SET;
__raw_writel(USBPHY_CTRL_CLKGATE, phy_reg);
}
-static void usbh1_power_config(void)
+static void usb_power_config(int index)
{
struct anatop_regs __iomem *anatop =
(struct anatop_regs __iomem *)ANATOP_BASE_ADDR;
+ void __iomem *chrg_detect;
+ void __iomem *pll_480_ctrl_clr;
+ void __iomem *pll_480_ctrl_set;
+
+ switch (index) {
+ case 0:
+ chrg_detect = &anatop->usb1_chrg_detect;
+ pll_480_ctrl_clr = &anatop->usb1_pll_480_ctrl_clr;
+ pll_480_ctrl_set = &anatop->usb1_pll_480_ctrl_set;
+ break;
+ case 1:
+ chrg_detect = &anatop->usb2_chrg_detect;
+ pll_480_ctrl_clr = &anatop->usb2_pll_480_ctrl_clr;
+ pll_480_ctrl_set = &anatop->usb2_pll_480_ctrl_set;
+ break;
+ default:
+ return;
+ }
/*
-* Some phy and power's special controls for host1
+* Some phy and power's special controls
* 1. The external charger detector needs to be disabled
* or the signal at DP will be poor
-* 2. The PLL's power and output to usb for host 1
+* 2. The PLL's power and output to usb
* is totally controlled by IC, so the Software only needs
* to enable them at initializtion.
*/
__raw_writel(ANADIG_USB2_CHRG_DETECT_EN_B |
ANADIG_USB2_CHRG_DETECT_CHK_CHRG_B,
-&anatop->usb2_chrg_detect);
+chrg_detect);
__raw_writel(ANADIG_USB2_PLL_480_CTRL_BYPASS,
-&anatop->usb2_pll_480_ctrl_clr);
+pll_480_ctrl_clr);
__raw_writel(ANADIG_USB2_PLL_480_CTRL_ENABLE |
ANADIG_USB2_PLL_480_CTRL_POWER |
ANADIG_USB2_PLL_480_CTRL_EN_USB_CLKS,
-&anatop->usb2_pll_480_ctrl_set);
+pll_480_ctrl_set);
}
-static int usbh1_phy_enable(void)
+static int usb_phy_enable(int index,
Re: [U-Boot] [UBOOT][PATCHv3 5/7] spi: add TI QSPI driver
Hi, 2013/9/18 Sourav Poddar : > From: Matt Porter > > Adds a SPI master driver for the TI QSPI peripheral. > > Signed-off-by: Matt Porter > Signed-off-by: Sourav Poddar > [Added quad read support and memory mapped support). > --- > drivers/spi/Makefile |1 + > drivers/spi/ti_qspi.c | 324 > + > 2 files changed, 325 insertions(+), 0 deletions(-) > create mode 100644 drivers/spi/ti_qspi.c > > diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile > index 91d24ce..e5941b0 100644 > --- a/drivers/spi/Makefile > +++ b/drivers/spi/Makefile > @@ -38,6 +38,7 @@ COBJS-$(CONFIG_FDT_SPI) += fdt_spi.o > COBJS-$(CONFIG_TEGRA20_SFLASH) += tegra20_sflash.o > COBJS-$(CONFIG_TEGRA20_SLINK) += tegra20_slink.o > COBJS-$(CONFIG_TEGRA114_SPI) += tegra114_spi.o > +COBJS-$(CONFIG_TI_QSPI) += ti_qspi.o > COBJS-$(CONFIG_XILINX_SPI) += xilinx_spi.o > COBJS-$(CONFIG_ZYNQ_SPI) += zynq_spi.o > > diff --git a/drivers/spi/ti_qspi.c b/drivers/spi/ti_qspi.c > new file mode 100644 > index 000..3e88cf4 > --- /dev/null > +++ b/drivers/spi/ti_qspi.c > @@ -0,0 +1,324 @@ > +/* > + * TI QSPI driver > + * > + * Copyright (C) 2013, Texas Instruments, Incorporated > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License as > + * published by the Free Software Foundation; either version 2 of > + * the License, or (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR /PURPOSE. See the > + * GNU General Public License for more details. > + */ Could you change to 'SPDX-License-Identifier:GPL-2.0+', please? Best regards, Nobuhiro -- Nobuhiro Iwamatsu ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 2/8] ARM: add secure monitor handler to switch to non-secure state
On Fri, Sep 20, 2013 at 6:12 AM, Christoffer Dall < christoffer.d...@linaro.org> wrote: > On Fri, Sep 20, 2013 at 03:20:15AM +0530, Mj Embd wrote: > > Just checking, is the mcr p15,0,r1,c1,c1,0 in sync with the following > text > > . I could be wrong here, just checking > > In the future, if you can comment specifically inline on the lines of > code you are targeting, it is easier for other people to address your > concerns. > > > > > B1.5.1 Arm Arch Ref Manual > > > >- > > > >To avoid security holes, software must not: > > - > > > > — Change from Secure to Non-secure state by using an MSR or CPS > > instruction > > to switch from Monitor > > The important part here is that we don't change from S to NS by > modifying the SCR, because monitor mode is always in secure mode, so the > change only happens on the exception return. > > So yes, it's safe. > > -Christoffer > Ok. Good Discussion. Thanks, PS: Gmail auto wraps the previous msg in 3 dots, so sometimes I miss inlining. Thanks for pointing out. > > > > > mode to some other mode while SCR.NS is 1. > >- > > > > — Use an MCR instruction that writes SCR.NS to change from Secure > to > > Non-secure state. This means ARM recommends that software does not > alter > > SCR.NS in any mode except Monitor mode. ARM deprecates changing > SCR.NS > > in any other mode. > > > > > > > > On Thu, Sep 19, 2013 at 9:36 PM, Andre Przywara > > wrote: > > > > > A prerequisite for using virtualization is to be in HYP mode, which > > > requires the CPU to be in non-secure state first. > > > Add a new file in arch/arm/cpu/armv7 to hold a monitor handler routine > > > which switches the CPU to non-secure state by setting the NS and > > > associated bits. > > > According to the ARM architecture reference manual this should not be > > > done in SVC mode, so we have to setup a SMC handler for this. > > > We create a new vector table to avoid interference with other boards. > > > The MVBAR register will be programmed later just before the smc call. > > > > > > Signed-off-by: Andre Przywara > > > --- > > > arch/arm/cpu/armv7/Makefile | 4 +++ > > > arch/arm/cpu/armv7/nonsec_virt.S | 54 > > > > > > 2 files changed, 58 insertions(+) > > > create mode 100644 arch/arm/cpu/armv7/nonsec_virt.S > > > > > > Changes: > > > v3..v4: clarify comments, w/s fixes > > > v4..v5: remove unneeded padding in the exception table > > > > > > diff --git a/arch/arm/cpu/armv7/Makefile b/arch/arm/cpu/armv7/Makefile > > > index b723e22..3466c7a 100644 > > > --- a/arch/arm/cpu/armv7/Makefile > > > +++ b/arch/arm/cpu/armv7/Makefile > > > @@ -20,6 +20,10 @@ ifneq > > > > ($(CONFIG_AM43XX)$(CONFIG_AM33XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CON > > > SOBJS += lowlevel_init.o > > > endif > > > > > > +ifneq ($(CONFIG_ARMV7_NONSEC),) > > > +SOBJS += nonsec_virt.o > > > +endif > > > + > > > SRCS := $(START:.o=.S) $(COBJS:.o=.c) > > > OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS)) > > > START := $(addprefix $(obj),$(START)) > > > diff --git a/arch/arm/cpu/armv7/nonsec_virt.S > > > b/arch/arm/cpu/armv7/nonsec_virt.S > > > new file mode 100644 > > > index 000..c21bca3 > > > --- /dev/null > > > +++ b/arch/arm/cpu/armv7/nonsec_virt.S > > > @@ -0,0 +1,54 @@ > > > +/* > > > + * code for switching cores into non-secure state > > > + * > > > + * Copyright (c) 2013 Andre Przywara > > > + * > > > + * See file CREDITS for list of people who contributed to this > > > + * project. > > > + * > > > + * This program is free software; you can redistribute it and/or > > > + * modify it under the terms of the GNU General Public License as > > > + * published by the Free Software Foundation; either version 2 of > > > + * the License, or (at your option) any later version. > > > + * > > > + * This program is distributed in the hope that it will be useful, > > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See > the > > > + * GNU General Public License for more details. > > > + * > > > + * You should have received a copy of the GNU General Public License > > > + * along with this program; if not, write to the Free Software > > > + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, > > > + * MA 02111-1307 USA > > > + */ > > > + > > > +#include > > > + > > > +/* the vector table for secure state */ > > > +_monitor_vectors: > > > + .word 0 /* reset */ > > > + .word 0 /* undef */ > > > + adr pc, _secure_monitor > > > + .word 0 > > > + .word 0 > > > + .word 0 > > > + .word 0 > > > + .word 0 > > > + > > > +/* > > > + * secure monitor handler > > > + * U-boot calls this "software interrupt" in start.S > > > + * This is executed on a "smc" instruction, we use a "smc #0" to > switch > > > + * to non-secure state. > > > + * We use only r0 and r1 here, due to constraints in t
[U-Boot] [PATCH v2 1/3] serial: sh: Add support R8A7790
This adds the preset value to register, and setup of baudrate.
Signed-off-by: Kouei Abe
Signed-off-by: Nobuhiro Iwamatsu
---
v2: no changes
drivers/serial/serial_sh.c | 1 +
drivers/serial/serial_sh.h | 13 +
2 files changed, 14 insertions(+)
diff --git a/drivers/serial/serial_sh.c b/drivers/serial/serial_sh.c
index 67cc0dc..0826d59 100644
--- a/drivers/serial/serial_sh.c
+++ b/drivers/serial/serial_sh.c
@@ -1,5 +1,6 @@
/*
* SuperH SCIF device driver.
+ * Copyright (C) 2013 Renesas Electronics Corporation
* Copyright (C) 2007,2008,2010 Nobuhiro Iwamatsu
* Copyright (C) 2002 - 2008 Paul Mundt
*
diff --git a/drivers/serial/serial_sh.h b/drivers/serial/serial_sh.h
index 7e38a3f..a6558af 100644
--- a/drivers/serial/serial_sh.h
+++ b/drivers/serial/serial_sh.h
@@ -224,6 +224,9 @@ struct uart_port {
# define SCSPTR3 0xffc60020/* 16 bit SCIF */
# define SCIF_ORER 0x0001 /* Overrun error bit */
# define SCSCR_INIT(port) 0x38/* TIE=0,RIE=0,TE=1,RE=1,REIE=1 */
+#elif defined(CONFIG_R8A7790)
+# define SCIF_ORER 0x0001
+# define SCSCR_INIT(port) 0x32/* TIE=0,RIE=0,TE=1,RE=1,REIE=0, */
#else
# error CPU subtype not defined
#endif
@@ -298,6 +301,9 @@ struct uart_port {
/* SH7763 SCIF2 support */
# define SCIF2_RFDC_MASK 0x001f
# define SCIF2_TXROOM_MAX 16
+#elif defined(CONFIG_R8A7790)
+# define SCIF_ERRORS (SCIF_PER | SCIF_FER | SCIF_ER | SCIF_BRK)
+# define SCIF_RFDC_MASK0x003f
#else
# define SCIF_ERRORS (SCIF_PER | SCIF_FER | SCIF_ER | SCIF_BRK)
# define SCIF_RFDC_MASK 0x001f
@@ -579,6 +585,10 @@ SCIF_FNS(SCSPTR,0, 0, 0, 0)
#else
SCIF_FNS(SCSPTR,0, 0, 0x20, 16)
#endif
+#if defined(CONFIG_R8A7790)
+SCIF_FNS(DL, 0, 0, 0x30, 16)
+SCIF_FNS(CKS, 0, 0, 0x34, 16)
+#endif
SCIF_FNS(SCLSR, 0, 0, 0x24, 16)
#endif
#endif
@@ -720,6 +730,9 @@ static inline int scbrr_calc(struct uart_port port, int
bps, int clk)
#define SCBRR_VALUE(bps, clk) scbrr_calc(sh_sci, bps, clk)
#elif defined(__H8300H__) || defined(__H8300S__)
#define SCBRR_VALUE(bps, clk) (((clk*1000/32)/bps)-1)
+#elif defined(CONFIG_R8A7790)
+#define SCBRR DL
+#define SCBRR_VALUE(bps, clk) (clk / bps / 16)
#else /* Generic SH */
#define SCBRR_VALUE(bps, clk) ((clk+16*bps)/(32*bps)-1)
#endif
--
1.8.4.rc3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: ehci: Fix test mode for connected ports
Hello Marek, 8 seemed like a reasonable value. It is not the only possible one. As I said, the spec requires a minimum of 4.125 (125us to make sure the current microframe finishes, and 16 * 125us to wait for the 16 full microframes listed on page 20). 8 fulfills that constraint and leaves a little more tolerance, but you could also use 5, 16 or 100. I really don't care, so please just tell me what number you want to have if you don't like 8, because it just doesn't matter. It is no more or less magic than the 100ms used in most other handshake() calls (without any #define or explanation). ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 2/8] ARM: add secure monitor handler to switch to non-secure state
On Fri, Sep 20, 2013 at 03:20:15AM +0530, Mj Embd wrote: > Just checking, is the mcr p15,0,r1,c1,c1,0 in sync with the following text > . I could be wrong here, just checking In the future, if you can comment specifically inline on the lines of code you are targeting, it is easier for other people to address your concerns. > > B1.5.1 Arm Arch Ref Manual > >- > >To avoid security holes, software must not: > - > > — Change from Secure to Non-secure state by using an MSR or CPS > instruction > to switch from Monitor The important part here is that we don't change from S to NS by modifying the SCR, because monitor mode is always in secure mode, so the change only happens on the exception return. So yes, it's safe. -Christoffer > > mode to some other mode while SCR.NS is 1. >- > > — Use an MCR instruction that writes SCR.NS to change from Secure to > Non-secure state. This means ARM recommends that software does not alter > SCR.NS in any mode except Monitor mode. ARM deprecates changing SCR.NS > in any other mode. > > > > On Thu, Sep 19, 2013 at 9:36 PM, Andre Przywara > wrote: > > > A prerequisite for using virtualization is to be in HYP mode, which > > requires the CPU to be in non-secure state first. > > Add a new file in arch/arm/cpu/armv7 to hold a monitor handler routine > > which switches the CPU to non-secure state by setting the NS and > > associated bits. > > According to the ARM architecture reference manual this should not be > > done in SVC mode, so we have to setup a SMC handler for this. > > We create a new vector table to avoid interference with other boards. > > The MVBAR register will be programmed later just before the smc call. > > > > Signed-off-by: Andre Przywara > > --- > > arch/arm/cpu/armv7/Makefile | 4 +++ > > arch/arm/cpu/armv7/nonsec_virt.S | 54 > > > > 2 files changed, 58 insertions(+) > > create mode 100644 arch/arm/cpu/armv7/nonsec_virt.S > > > > Changes: > > v3..v4: clarify comments, w/s fixes > > v4..v5: remove unneeded padding in the exception table > > > > diff --git a/arch/arm/cpu/armv7/Makefile b/arch/arm/cpu/armv7/Makefile > > index b723e22..3466c7a 100644 > > --- a/arch/arm/cpu/armv7/Makefile > > +++ b/arch/arm/cpu/armv7/Makefile > > @@ -20,6 +20,10 @@ ifneq > > ($(CONFIG_AM43XX)$(CONFIG_AM33XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CON > > SOBJS += lowlevel_init.o > > endif > > > > +ifneq ($(CONFIG_ARMV7_NONSEC),) > > +SOBJS += nonsec_virt.o > > +endif > > + > > SRCS := $(START:.o=.S) $(COBJS:.o=.c) > > OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS)) > > START := $(addprefix $(obj),$(START)) > > diff --git a/arch/arm/cpu/armv7/nonsec_virt.S > > b/arch/arm/cpu/armv7/nonsec_virt.S > > new file mode 100644 > > index 000..c21bca3 > > --- /dev/null > > +++ b/arch/arm/cpu/armv7/nonsec_virt.S > > @@ -0,0 +1,54 @@ > > +/* > > + * code for switching cores into non-secure state > > + * > > + * Copyright (c) 2013 Andre Przywara > > + * > > + * See file CREDITS for list of people who contributed to this > > + * project. > > + * > > + * This program is free software; you can redistribute it and/or > > + * modify it under the terms of the GNU General Public License as > > + * published by the Free Software Foundation; either version 2 of > > + * the License, or (at your option) any later version. > > + * > > + * This program is distributed in the hope that it will be useful, > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > > + * GNU General Public License for more details. > > + * > > + * You should have received a copy of the GNU General Public License > > + * along with this program; if not, write to the Free Software > > + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, > > + * MA 02111-1307 USA > > + */ > > + > > +#include > > + > > +/* the vector table for secure state */ > > +_monitor_vectors: > > + .word 0 /* reset */ > > + .word 0 /* undef */ > > + adr pc, _secure_monitor > > + .word 0 > > + .word 0 > > + .word 0 > > + .word 0 > > + .word 0 > > + > > +/* > > + * secure monitor handler > > + * U-boot calls this "software interrupt" in start.S > > + * This is executed on a "smc" instruction, we use a "smc #0" to switch > > + * to non-secure state. > > + * We use only r0 and r1 here, due to constraints in the caller. > > + */ > > + .align 5 > > +_secure_monitor: > > + mrc p15, 0, r1, c1, c1, 0 @ read SCR > > + bic r1, r1, #0x4e @ clear IRQ, FIQ, EA, nET > > bits > > + orr r1, r1, #0x31 @ enable NS, AW, FW bits > > + > > + mcr p15, 0, r1, c1, c1, 0 @ write SCR (with NS bit > > set) > > + > > + movspc, lr @ return to non-secure SVC > > + > > -- > >
Re: [U-Boot] [PATCH 1/2] arm: rmobile: kzm9g: Change clock definition of SCIF from CONFIG_SYS_CLK_FREQ to CONFIG_SH_SCIF_CLK_FREQ
Hi, Albert. (2013/09/19 18:09), Albert ARIBAUD wrote: Hi Nobuhiro, On Thu, 22 Aug 2013 13:05:49 +0900, Nobuhiro Iwamatsu wrote: Signed-off-by: Nobuhiro Iwamatsu --- include/configs/kzm9g.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/kzm9g.h b/include/configs/kzm9g.h index 222725c..6323050 100644 --- a/include/configs/kzm9g.h +++ b/include/configs/kzm9g.h @@ -125,6 +125,7 @@ #define CONFIG_GLOBAL_TIMER #define CONFIG_SYS_CLK_FREQ (4800) #define CONFIG_SYS_CPU_CLK(119600) +#define CONFIG_SH_SCIF_CLK_FREQ CONFIG_SYS_CLK_FREQ #define TMU_CLK_DIVIDER (4) /* 4 (default), 16, 64, 256 or 1024 */ #define CFG_HZ (1000) #define CONFIG_SYS_HZ CFG_HZ What's the point of this series? It only adds a define, but the current codebase does not use it anywhere, so obviously it's "dead code". This is used by drivers/serial/serial_sh.c. http://lists.denx.de/pipermail/u-boot/2013-August/161276.html I already applied this to my u-boot-sh repository. But I dont pull-request yet. I want to include in the next version of this change. > If there is a further series which needs this define, then include these patches in that further series. I see. I will be from next time, Is it OK? Amicalement, Best regards, Nobuhiro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] arm: rmobile: Add support lager board
Hi, Albert. (2013/09/19 18:04), Albert ARIBAUD wrote: Hi Nobuhiro, On Thu, 22 Aug 2013 13:23:28 +0900, Nobuhiro Iwamatsu wrote: diff --git a/arch/arm/include/asm/mach-types.h b/arch/arm/include/asm/mach-types.h index 440b041..67b88ad 100644 --- a/arch/arm/include/asm/mach-types.h +++ b/arch/arm/include/asm/mach-types.h @@ -1106,6 +1106,7 @@ extern unsigned int __machine_arch_type; #define MACH_TYPE_OMAP5_SEVM 3777 #define MACH_TYPE_ARMADILLO_800EVA 3863 #define MACH_TYPE_KZM9G4140 +#define MACH_TYPE_LAGER4538 Do not modify mach-types.h; if the machine type was reserved but is not yet in machine-types, then you should define the machine type in the board's header file, possibly with preprocessing directives to #error when the same definition appears in mach-types.h making the board's one obsolete. OK, I will remove this from patch. diff --git a/boards.cfg b/boards.cfg index be810c7..8e38d3c 100644 --- a/boards.cfg +++ b/boards.cfg @@ -341,6 +341,8 @@ u8500_href arm armv7 u8500 st-eric snowball arm armv7 snowball st-ericssonu8500 kzm9garm armv7 kzm9g kmc rmobile armadillo-800eva arm armv7 armadillo-800eva atmark-techno rmobile +lagerarm armv7 lager renesasrmobile +lager_norarm armv7 lager renesasrmobile lager:NORFLASH Please rebase as boards.cfg has changed, and do add maintainer addresses to these two lines. I see. I will update my patches and re-send. Thank you for your review! Amicalement, Best regards, Nobuhiro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot PPC405EX with DDR2 DIMM
Dear Steve Miller, Steve Miller tanisys.com> writes: > > > Questions: > > 1.Has anyone compiled u-boot for the 405EX using a DIMM, aka an > SPD defined RAM? > > 2. Is there something obvious that I need to place in the config > to get this to work? I compared this config to another product that > uses a 460SX. I did not see anything special that the 460SX was > configuring to make the system work with the SPD of the DIMM. I have not directly worked with the 405 (only 440 and 465). FWIW, defining CONFIG_DDR_SPD is not enough in some cases. You would also need to adjust timing parameters and row/column bits for your specific DIMM so that the DDR controller can correctly access all of your memory. All the best, Rommel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: mxs: Setup stack in JTAG mode
In case the MX23/MX28 is switched into JTAG mode via the BootMode select
switches, the BootROM bypasses the CPU core registers initialization.
This in turn means that the Stack Pointer (SP) register is not set as
it is in every other mode of operation, but instead is only zeroed out.
To prevent U-Boot SPL from crashing in this obscure JTAG mode, configure
the SP to point at the CONFIG_SYS_INIT_SP_ADDR if the SP is zeroed out.
Note that in case the SP is already configured, we must preserve that exact
SP value and must not modify it. This is important since in every other mode
but the JTAG mode, the SPL returns into the BootROM and BootROM in turn loads
U-Boot itself. If the SP were to be corrupted, the BootROM won't be able to
continue it's operation after returned from SPL and the system would crash.
Finally, add the JTAG mode switch identifier, so it's not recognised as
Unknown mode.
Signed-off-by: Marek Vasut
Cc: Stefano Babic
Cc: Fabio Estevam
Cc: Otavio Salvador
---
arch/arm/cpu/arm926ejs/mxs/start.S| 9 +
arch/arm/include/asm/arch-mxs/sys_proto.h | 2 ++
2 files changed, 11 insertions(+)
diff --git a/arch/arm/cpu/arm926ejs/mxs/start.S
b/arch/arm/cpu/arm926ejs/mxs/start.S
index 3e454ae..5de2bad 100644
--- a/arch/arm/cpu/arm926ejs/mxs/start.S
+++ b/arch/arm/cpu/arm926ejs/mxs/start.S
@@ -150,6 +150,15 @@ IRQ_STACK_START_IN:
_reset:
/*
+* If the CPU is configured in "Wait JTAG connection mode", the stack
+* pointer is not configured and is zero. This will cause crash when
+* trying to push data onto stack right below here. Load the SP and make
+* it point to the end of OCRAM if the SP is zero.
+*/
+ cmp sp, #0x
+ ldreq sp, =CONFIG_SYS_INIT_SP_ADDR
+
+ /*
* Store all registers on old stack pointer, this will allow us later to
* return to the BootROM and let the BootROM load U-Boot into RAM.
*
diff --git a/arch/arm/include/asm/arch-mxs/sys_proto.h
b/arch/arm/include/asm/arch-mxs/sys_proto.h
index 43c7dd6..09dfc90 100644
--- a/arch/arm/include/asm/arch-mxs/sys_proto.h
+++ b/arch/arm/include/asm/arch-mxs/sys_proto.h
@@ -46,6 +46,7 @@ static const struct mxs_pair mxs_boot_modes[] = {
{ 0x02, 0x1f, "SSP SPI #1, master, NOR" },
{ 0x03, 0x1f, "SSP SPI #2, master, NOR" },
{ 0x04, 0x1f, "NAND" },
+ { 0x06, 0x1f, "JTAG" },
{ 0x08, 0x1f, "SSP SPI #3, master, EEPROM" },
{ 0x09, 0x1f, "SSP SD/MMC #0" },
{ 0x0a, 0x1f, "SSP SD/MMC #1" },
@@ -60,6 +61,7 @@ static const struct mxs_pair mxs_boot_modes[] = {
{ 0x13, 0x1f, "SSP SPI #3, master, 1V8 NOR" },
{ 0x04, 0x1f, "NAND, 3V3" },
{ 0x14, 0x1f, "NAND, 1V8" },
+ { 0x06, 0x1f, "JTAG" },
{ 0x08, 0x1f, "SSP SPI #3, master, 3V3 EEPROM" },
{ 0x18, 0x1f, "SSP SPI #3, master, 1V8 EEPROM" },
{ 0x09, 0x1f, "SSP SD/MMC #0, 3V3" },
--
1.8.4.rc3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 5/5] B4860QDS: Add support of 2 stage NAND boot loader
Dear Prabhakar Kushwaha, Prabhakar Kushwaha freescale.com> writes: > > > > Thank you for the replies. > > You mention you use the PBL... but probably not a pblimage. The patch > > correctly fixes RAMBOOT_PBL as a trigger to generate the pblimage (u- > > boot.pbl) but there seems to be no RCW or PBI file defined. > > B4860 does support PBL based NAND boot. > but I have yet to integrate u-boot-spl.bin to generated u-boot-spl.pbl. > This is in my TODO list This is my understanding (if need be, take it with a grain of salt) The Makefiles need to be modified so that SPL build will create a pblimage. The "mkimage pblimage" needs to be executed only on the SPL binary. Then the top-level Makefile proceeds in concatenating the u-boot-spl.bin (now a pblimage) and u-boot.bin. > > I have one question, can this scenario be implemented on a P5040? i.e. > > simulate that CPC is around 128Kb and load u-boot via SPL? Now all corenet > > processors seem to only support pblimage booting. > > > > yes. This scenario can be implemented for P5040. Only need to create > spl.c file + define constants. Seems easy enough :-) though I probably don't have the resources to actually implement it. Just a note. The pblimage booting is not very flexible now. Currently it assumes that u-boot.pbl will fit into CPC (configured as SRAM). This is OK for most processors (i.e P5040 with 1Mb CPC) but it will not work for others (i.e T1040/1042 with only 256Kb CPC). So there is a need to have SPL in this case. All the best, Rommel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 3/8] ARM: add assembly routine to switch to non-secure state
On 20 September 2013 07:50, Mj Embd wrote: > [MJ] Ok got your point. Then what would be the steps to return from Monitor > to Hyp mode? You can't do it directly. While still in the Secure world you set up the HVBAR and a suitable vector table for hyp mode exceptions. Then you can drop back into NS-SVC, and execute an HVC instruction which puts you into hyp mode at the hvc entry point in your vector table. See patch 7 in the series. -- PMM ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 3/8] ARM: add assembly routine to switch to non-secure state
On 20 September 2013 06:55, Mj Embd wrote: > Hello Andre, > I need a bit clarification here, if you read the next line after the line > you have quoted. It clearly says that you can use a MCR to change from > Secure to NS in Monitor Mode No, it's not saying that, because Monitor mode is always Secure: this is exactly why an MCR to change SCR.NS is OK only in Monitor mode -- it doesn't change from Secure to Non-Secure. Only when you do an exception-return to leave Monitor mode will you drop into the NonSecure world. > "Use an MCR instruction that writes SCR.NS to change from Secure to > Non-secure state. This means ARM recommends that software does not alter > SCR.NS in any mode except Monitor mode. ARM deprecates changing SCR.NS in > any other mode." The text says "don't change from Secure to NonSecure by flipping SCR.NS". It then lays out the corollary: the only time you then can change SCR.NS is when it won't switch from Secure to NonSecure, which is when you're in Monitor mode. -- PMM ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] socfpga: Adding Freeze Controller driver
Hi!
> Adding Freeze Controller driver. All HPS IOs need to be
> in freeze state during pin mux or IO buffer configuration.
> It is to avoid any glitch which might happen
> during the configuration from propagating to external devices.
So... code that is currently in u-boot appears to work, but may
produce some unwanted electrical spikes. They don't matter on
development boards, but we'd like to get rid of them for production. ?
It would be nice to put some explanation as a comment into code.
> Signed-off-by: Chin Liang See
> Cc: Wolfgang Denk
> CC: Pavel Machek
> Cc: Dinh Nguyen
> ---
> Changes for v2
> - Removed FREEZE_CONTROLLER_FSM_HW
> - Removed the get_timer_count_masked and convert to use delay in us
> - Used shorter local variables
Thanks! Still there's a bit to go:
> +#define SYSMGR_FRZCTRL_LOOP_PARAM (1000)
> +#define SYSMGR_FRZCTRL_DELAY_LOOP_PARAM (10)
> +#define SYSMGR_FRZCTRL_INTOSC_33 (33)
> +#define SYSMGR_FRZCTRL_INTOSC_1000 (1000)
We no longer need these, right?
> +#define FREEZE_CHANNEL_NUM (4)
Check this one, it may not be needed.
> +typedef enum {
> + FREEZE_CTRL_FROZEN = 0,
> + FREEZE_CTRL_THAWED = 1
> +} FREEZE_CTRL_CHAN_STATE;
This definitely should not be needed.
> +typedef enum {
> + FREEZE_CHANNEL_0 = 0, /* EMAC_IO & MIXED2_IO */
> + FREEZE_CHANNEL_1, /* MIXED1_IO and FLASH_IO */
> + FREEZE_CHANNEL_2, /* General IO */
> + FREEZE_CHANNEL_3, /* DDR IO */
> + FREEZE_CHANNEL_UNDEFINED
> +} FreezeChannelSelect;
CamelCaseIsUnwelcome. And actually haveing enum for numbers 0..3 looks
like overkill. Could we just use plain numbers?
> +typedef enum {
> + FREEZE_CONTROLLER_FSM_SW = 0,
> + FREEZE_CONTROLLER_FSM_HW,
> + FREEZE_CONTROLLER_FSM_UNDEFINED
> +} FreezeControllerFSMSelect;
No longer needed.
> +#define SYSMGR_FRZCTRL_HWCTRL_VIO1STATE_GET(x) (((x) & 0x0006)
>> 1)
Is this still used?
> +#define SYSMGR_FRZCTRL_VIOCTRL_SHIFT 0x2
> +
> +u32 sys_mgr_frzctrl_freeze_req(FreezeChannelSelect channel_id,
> + FreezeControllerFSMSelect fsm_select);
> +u32 sys_mgr_frzctrl_thaw_req(FreezeChannelSelect channel_id,
> + FreezeControllerFSMSelect fsm_select);
We can remove second parameter here. And maybe use some more
reasonable names.
sysmgr_freeze_req / sysmgr_thaw_req?
Thanks, and sorry for two-phase review.
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 v5 3/8] ARM: add assembly routine to switch to non-secure state
On Fri, Sep 20, 2013 at 4:05 AM, Peter Maydell wrote: > On 20 September 2013 06:55, Mj Embd wrote: > > Hello Andre, > > I need a bit clarification here, if you read the next line after the line > > you have quoted. It clearly says that you can use a MCR to change from > > Secure to NS in Monitor Mode > > No, it's not saying that, because Monitor mode is always Secure: > this is exactly why an MCR to change SCR.NS is OK only in > Monitor mode -- it doesn't change from Secure to Non-Secure. > Only when you do an exception-return to leave Monitor mode > will you drop into the NonSecure world. > > > "Use an MCR instruction that writes SCR.NS to change from Secure to > > Non-secure state. This means ARM recommends that software does not alter > > SCR.NS in any mode except Monitor mode. ARM deprecates changing SCR.NS in > > any other mode." > > The text says "don't change from Secure to NonSecure by flipping > SCR.NS". It then lays out the corollary: the only time you then can > change SCR.NS is when it won't switch from Secure to NonSecure, > which is when you're in Monitor mode. > > [MJ] Ok got your point. Then what would be the steps to return from Monitor to Hyp mode? > -- PMM > -- -mj ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/12 V3] EXYNOS5: Create a common board file
Hi MJ, On Thu, Sep 19, 2013 at 12:59 AM, MJ embd wrote: > Hi @Samsung, > > Great that you have starting posting 5420 patches, one basic question > (a) What is the booting procedure for the secondary cores > (b) What is the booting procedure for the Little Secondary cores... > > Would you be pushing the patches for these as well > [best not to top-post] There are patches in the Chromium tree for handling this - I expect these will be upstreamed sometime after this initial set lands. Regards, Simon > > On 9/19/13, Simon Glass wrote: > > Hi Rajeshwari, > > > > On Wed, Sep 11, 2013 at 4:01 AM, Rajeshwari S Shinde < > > rajeshwar...@samsung.com> wrote: > > > >> Create a common board.c file for all functions which are common across > >> all EXYNOS5 platforms. > >> > >> exynos_init function is provided for platform cpecific code. > >> > > > > specific > > > > > >> > >> Signed-off-by: Rajeshwari S Shinde > >> > > > > Acked-by: Simon Glass > > > > > >> --- > >> Changes in V2: > >> - None > >> Changes in V3: > >> - None > >> arch/arm/include/asm/arch-exynos/board.h | 17 ++ > >> board/samsung/common/Makefile| 4 + > >> board/samsung/common/board.c | 312 > >> +++ > >> board/samsung/smdk5250/exynos5-dt.c | 269 > >> +- > >> board/samsung/smdk5250/smdk5250.c| 182 +- > >> include/configs/exynos5250-dt.h | 2 + > >> 6 files changed, 342 insertions(+), 444 deletions(-) > >> create mode 100644 arch/arm/include/asm/arch-exynos/board.h > >> create mode 100644 board/samsung/common/board.c > >> > >> > > > > > -- > -mj > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] config: consolidate CONFIG_SYS_HZ definition
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/19/2013 05:02 PM, Rob Herring wrote: > On Thu, Sep 19, 2013 at 2:06 PM, Tom Rini wrote: >> On Mon, Sep 09, 2013 at 05:41:46PM +0200, Wolfgang Denk wrote: >>> Dear Rob, >>> >>> In message <522de2ff.2080...@gmail.com> you wrote: What do I do with current boards that are wrong? I should make all these >>> >>> Good question... >>> boards have build errors or fix them to use 1000 which may break them at runtime depending on their possible misuse of CONFIG_SYS_HZ? include/configs/KAREF.h:#define CONFIG_SYS_HZ 100 /* decr freq: 1 ms ticks */ include/configs/M5271EVB.h:#define CONFIG_SYS_HZ 100 include/configs/METROBOX.h:#define CONFIG_SYS_HZ 100/* decr freq: 1 ms ticks */ include/configs/MVBLUE.h:#define CONFIG_SYS_HZ 1 include/configs/idmr.h:#define CONFIG_SYS_HZ (5000 / 64) include/configs/mini2440.h:#define CONFIG_SYS_HZ 1562500 include/configs/mx1ads.h:#define CONFIG_SYS_HZ 3686400 include/configs/omap3_zoom2.h:#define CONFIG_SYS_HZ ((V_SCLK) / (2 << CONFIG_SYS_PTV)) include/configs/omap730p2.h:#define CONFIG_SYS_HZ ((CONFIG_SYS_CLK_FREQ)/(2 << CONFIG_SYS_PTV)) include/configs/rsk7203.h:#define CONFIG_SYS_HZ (CONFIG_SYS_CLK_FREQ / CMT_CLK_DIVIDER) include/configs/rsk7264.h:#define CONFIG_SYS_HZ (CONFIG_SYS_CLK_FREQ / CMT_CLK_DIVIDER) include/configs/rsk7269.h:#define CONFIG_SYS_HZ (CONFIG_SYS_CLK_FREQ / CMT_CLK_DIVIDER) include/configs/scb9328.h:#define CONFIG_SYS_HZ 3686400 /* incrementer freq: 3.6864 MHz */ include/configs/versatile.h:#define CONFIG_SYS_HZ (100 / 256) >>> >>> Hm... which of these boards are actually still being maintained? >>> >>> KAREF and METROBOX are PPC systems, and the comment suggests that the >>> value is actually just a typo. Here it should be harmless to change >>> this to use 1000 Hz instead. Ditto probably for MVBLUE. The rest >>> might actually be dead? >>> >>> Guess we should have their builds break and make the board maintainers >>> fix them. If they don't (because the boards are unmaintained), we >>> will drop the board code from the repo. >> >> Actually breaking them will cause hell on the folks building everything. >> Lets correct the ones we can correct easily and poke maintainers for the >> rest so we know what we can/should move to orphaned or just drop. > > How about just a warning instead? Here's an updated list which missed some: > > include/configs/M5271EVB.h:#define CONFIG_SYS_HZ > 100 > include/configs/balloon3.h:#define CONFIG_SYS_HZ > 325 /* Timer @ 325 Hz */ > include/configs/idmr.h:#define CONFIG_SYS_HZ(5000 / > 64) > include/configs/mini2440.h:#define CONFIG_SYS_HZ > 1562500 > include/configs/mx1ads.h:#define CONFIG_SYS_HZ 3686400 > include/configs/omap3_zoom2.h:#define CONFIG_SYS_HZ > ((V_SCLK) / (2 << CONFIG_SYS_PTV)) > include/configs/omap730p2.h:#define CONFIG_SYS_HZ > ((CONFIG_SYS_CLK_FREQ)/(2 << CONFIG_SYS_PTV)) > include/configs/palmld.h:#defineCONFIG_SYS_HZ > 325 /* Timer @ 325 Hz */ > include/configs/palmtc.h:#defineCONFIG_SYS_HZ > 3686400 /* Timer @ 3686400 Hz */ > include/configs/rsk7203.h:#define CONFIG_SYS_HZ > (CONFIG_SYS_CLK_FREQ / CMT_CLK_DIVIDER) > include/configs/rsk7264.h:#define CONFIG_SYS_HZ > (CONFIG_SYS_CLK_FREQ / CMT_CLK_DIVIDER) > include/configs/rsk7269.h:#define CONFIG_SYS_HZ > (CONFIG_SYS_CLK_FREQ / CMT_CLK_DIVIDER) > include/configs/scb9328.h:#define CONFIG_SYS_HZ > 3686400 /* incrementer freq: 3.6864 MHz */ > include/configs/versatile.h:#define CONFIG_SYS_HZ > (100 / 256) > include/configs/zipitz2.h:#define CONFIG_SYS_HZ > 325 /* Timer @ 325 Hz */ I could live with that I think. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSO3cBAAoJENk4IS6UOR1W0I4P/0l+rxS4C6tiFmCIQo9Wtf2i owKufT+cvGsQCtzbH84g3gUR/0bLE+FTAslYLyZ8DptFqlpOnOtc+pHqlOVgWZAp R1mZyVz1jU+8bRkieDFb6tv6PFGcXAkcC37epKlVk6b9A0vJnm6xEXQ1Hwb7XGhG j5DZ8KeUXWYyGcn5SYY5wRMztWcfQMMZ8MQVbioD8LE2vh7E2QnWBio168yfUS8l rbvxoykj6fxikYCWcdlr7ov7adzCa+nmwc4u0qxXzXro5Nm0uZ98FnJSj0HmuaS0 ISG0VMO+E6BnBFOBhwYbAgKgSFvTdxM8yo5lU66UuzVwVYvqqANbHhAR0I+8e4v4 k8jlouvUcFuQycWAotZopfqPnHMpDx51UYEjIcgw+MvCc9KqIH07epDOKuq4TLgn tGrM2N6HyX+ofKjKB1r6zRrqECzbGu8E5fAZNf/JrNgUTbfFRhmMvLFJ7F99ZUb+ chjveTUsY2yCmadgwxrQjOTLBn9MCabFqkm/mGweN+EjjAKJ25aE+JgIj2izYLal B1AzToq8YmAHJcFne6FJX3n2DUPKJ0BahvOkGjos9/jJjJdMI0bZw1x/As0ea6ZO NPKgewt5F7/uyhFe+B4wyi9xCgamR/ICGwS/K/ooIxB6rs+M17bb+PiV6QbX1DV4 imnvmPivTmbhQ/mGMM6c =+vhz -END PGP SIGNATURE- ___ U-
Re: [U-Boot] [PATCH v5 3/8] ARM: add assembly routine to switch to non-secure state
Hello Andre, I need a bit clarification here, if you read the next line after the line you have quoted. It clearly says that you can use a MCR to change from Secure to NS in Monitor Mode "Use an MCR instruction that writes SCR.NS to change from Secure to Non-secure state. This means ARM recommends that software does not alter SCR.NS in any mode except Monitor mode. ARM deprecates changing SCR.NS in any other mode." On Fri, Sep 20, 2013 at 3:09 AM, Mj Embd wrote: > > > > On Fri, Sep 20, 2013 at 3:01 AM, Andre Przywara > wrote: > >> On 09/19/2013 10:38 PM, Mj Embd wrote: >> >>> Hello Christoffer, >>> >>> I agree with both of you points. >>> >>> What I found different in 2 approaches is that in your approach >>> S->Monitor->NS->Hyp using svc and hvc >>> >>> While the other approach is setting the M bits directly in cpsr >>> >>> Xen uses the following >>> >>> cpsid aif, #0x16 /* Enter Monitor Mode*/ >>> >>> ... >>> mrs r0, cpsr /* Copy the CPSR */ >>> add r0, r0, #0x4 /* 0x16 (Monitor) -> 0x1a (Hyp) */ >>> msr spsr_cxsf, r0 /* into the SPSR */ >>> movs pc, r3 /* Exception-return into Hyp mode */ >>> >>> The second one is a bit simpler as it does not involve fault handlers. >>> >> >> The ARM ARM recommends _not_ to do this: >> Read more at the ARMv7-A Architecture Reference Manual, section B1.5.1: >> Security states/Changing from Secure to Non-secure state: >> >> "To avoid security holes, software must not: >> --Change from Secure to Non-secure state by using an MSR or CPS >> instruction to switch from Monitor mode to some other mode while SCR.NS is >> 1. >> ..." >> >> >> Good one, As per this statement from Secure Monitor to Hyp Mode, HVC > should be used. But Secure Supervisor to Secure Monitor does not set NS=1 > so first part cpsid aif, #0x16 is valid ? > Or there is some other statement in the manual which I am not aware of ? > >> >>> I was just suggesting that the best approach to be used ... >>> >> >> Looks like this is what we do ;-) >> >> Regards, >> Andre. >> >> >> >>> On 9/20/13, Christoffer Dall wrote: >>> On Fri, Sep 20, 2013 at 01:27:48AM +0530, Mj Embd wrote: > two quick points > (a) xen already has a mode_switch code, so AFAIK xen might not use it > (as suggested by comment in another patch in this patch set) > For KVM the boot procedure for Hyp mode is quite clearly defined: the kernel must be booted in Hyp mode. I was under the impression that Xen wanted to use the same paradigm and rely on bootloaders to switch to Hyp mode and thereby get rid of the code in Xen. (b) There are 2 methods of switching from Secure to Hyp mode > one you have proposed another implemented in xen. I was suggesting > take the best approach > > Can you please be more specific? Not everyone here knows the Xen low-level mode switch details by heart. As far as I know, there is only one architecturally defined proper mode to switch from secure mode to non-secure mode, and the state that needs to be configured for Hyp-mode and NS-mode is well defined. Obviously two implementation can do things differently (different order, different programminge environment, etc.) but that doesn't mean one is better than the other. I think it would be more productive if you can simply look at this code and if you think some things are done more efficiently in Xen, please comment on that, which would be very helpful. I'm afraid there's no magic way to apply a block of Xen code into U-Boot wihtout manual adjustment anyway, or the other way around for that matter. -Christoffer >>> >>> >> > > > -- > -mj > -- -mj ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How do ARM platform initialize DDR?
On Tue, Sep 17, 2013 at 08:59:24AM -0700, York Sun wrote: > Albert, > > Pardon me if this is a dumb question. I have been working on powerpc > platforms in the past. Now we (the developers I work with) are exploring > ARM cores. I am searching how memory is initialized and found different > solutions. Some platforms have memory ready before u-boot even starts, > some simply write to a set of registers. I understand many platforms > don't share the IP of DDR controller. I am wondering if there is generic > DDR driver used by many ARM platforms, like the one we have for > powerpc/mpc85xx SoCs. Thinking back, as a rule of thumb, PowerPC has SPD I2C data available, usually. That's not the rule for ARM. One of a few choices happen: 1) ROM sets up DDR. 2) U-Boot/SPL sets up the DDR controller. The problem is that the DDR controller is usually vendor-specific. Perhaps the flip-side here is that there's not so much a generic DDR driver for mpc85xx but simply one vendor for mpc85xx. Taking arch/powerpc/cpu/mpc85xx/ddr-gen3.c as what you're talking about, arch/arm/cpu/armv7/omap-common/emif-common.c would be an ARM-world example (the 'EMIF' is found on a large variety of TI parts, not just "omap" ones). > > Regards, > > York > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot -- 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] How do ARM platform initialize DDR?
On 09/19/2013 02:33 PM, Tom Rini wrote: > On 09/19/2013 05:08 PM, York Sun wrote: >> On 09/19/2013 01:57 PM, Tom Rini wrote: >>> On Tue, Sep 17, 2013 at 08:59:24AM -0700, York Sun wrote: >>> Albert, Pardon me if this is a dumb question. I have been working on powerpc platforms in the past. Now we (the developers I work with) are exploring ARM cores. I am searching how memory is initialized and found different solutions. Some platforms have memory ready before u-boot even starts, some simply write to a set of registers. I understand many platforms don't share the IP of DDR controller. I am wondering if there is generic DDR driver used by many ARM platforms, like the one we have for powerpc/mpc85xx SoCs. >>> >>> Thinking back, as a rule of thumb, PowerPC has SPD I2C data >>> available, usually. That's not the rule for ARM. One of a few >>> choices happen: 1) ROM sets up DDR. 2) U-Boot/SPL sets up the DDR >>> controller. >>> > >> So for ARM platforms, the majority don't have the flexibility of >> using different DIMMs and/or clocks? > > It's a different world. Again, thinking back to the PowerPC boards > I've seen, they had "regular" DDR sockets. Most ARM boards don't. > You can design your board with whatever, and I know in prototyping > folks make do swapping chips in and out (and if you look at the omap > code, you can see where we have code to calculate the timing values > and print them, or use provided hard-coded values). Understood. We may have boards with DIMM slots. I do see value of a fully functional DDR driver here. > >>> The problem is that the DDR controller is usually >>> vendor-specific. Perhaps the flip-side here is that there's not >>> so much a generic DDR driver for mpc85xx but simply one vendor >>> for mpc85xx. Taking arch/powerpc/cpu/mpc85xx/ddr-gen3.c as what >>> you're talking about, >>> arch/arm/cpu/armv7/omap-common/emif-common.c would be an >>> ARM-world example (the 'EMIF' is found on a large variety of TI >>> parts, not just "omap" ones). > >> Does it make sense to share the Freescale DDR driver across ARM >> and Powerpc? Or does it make more sense to selectively copy the >> mpc8xxx DDR driver to Freescale ARM subfolder to start with. If the >> similarity sustains then we merge them into common driver. If not, >> we maintain two separated drivers. > >> For those who is not familiar with, Freescale is extending products >> to ARM cores. I am expecting peripherals stay relatively close, so >> many driver can be reused. > > I've been wondering when this would start to be visible. If we are > able to share the DDR controller code between mpc85xx and the ARM > stuff you're talking about, we'll have to sort out someplace within > drivers/ to place it, to avoid #include nightmares I suspect. Other > drivers should be easier to share at least :) > I did a quick and dirty hack yesterday to move DDR driver to drivers/ddr/fsl. I had to change many #include . York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 2/8] ARM: add secure monitor handler to switch to non-secure state
Just checking, is the mcr p15,0,r1,c1,c1,0 in sync with the following text . I could be wrong here, just checking B1.5.1 Arm Arch Ref Manual - To avoid security holes, software must not: - — Change from Secure to Non-secure state by using an MSR or CPS instruction to switch from Monitor mode to some other mode while SCR.NS is 1. - — Use an MCR instruction that writes SCR.NS to change from Secure to Non-secure state. This means ARM recommends that software does not alter SCR.NS in any mode except Monitor mode. ARM deprecates changing SCR.NS in any other mode. On Thu, Sep 19, 2013 at 9:36 PM, Andre Przywara wrote: > A prerequisite for using virtualization is to be in HYP mode, which > requires the CPU to be in non-secure state first. > Add a new file in arch/arm/cpu/armv7 to hold a monitor handler routine > which switches the CPU to non-secure state by setting the NS and > associated bits. > According to the ARM architecture reference manual this should not be > done in SVC mode, so we have to setup a SMC handler for this. > We create a new vector table to avoid interference with other boards. > The MVBAR register will be programmed later just before the smc call. > > Signed-off-by: Andre Przywara > --- > arch/arm/cpu/armv7/Makefile | 4 +++ > arch/arm/cpu/armv7/nonsec_virt.S | 54 > > 2 files changed, 58 insertions(+) > create mode 100644 arch/arm/cpu/armv7/nonsec_virt.S > > Changes: > v3..v4: clarify comments, w/s fixes > v4..v5: remove unneeded padding in the exception table > > diff --git a/arch/arm/cpu/armv7/Makefile b/arch/arm/cpu/armv7/Makefile > index b723e22..3466c7a 100644 > --- a/arch/arm/cpu/armv7/Makefile > +++ b/arch/arm/cpu/armv7/Makefile > @@ -20,6 +20,10 @@ ifneq > ($(CONFIG_AM43XX)$(CONFIG_AM33XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CON > SOBJS += lowlevel_init.o > endif > > +ifneq ($(CONFIG_ARMV7_NONSEC),) > +SOBJS += nonsec_virt.o > +endif > + > SRCS := $(START:.o=.S) $(COBJS:.o=.c) > OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS)) > START := $(addprefix $(obj),$(START)) > diff --git a/arch/arm/cpu/armv7/nonsec_virt.S > b/arch/arm/cpu/armv7/nonsec_virt.S > new file mode 100644 > index 000..c21bca3 > --- /dev/null > +++ b/arch/arm/cpu/armv7/nonsec_virt.S > @@ -0,0 +1,54 @@ > +/* > + * code for switching cores into non-secure state > + * > + * Copyright (c) 2013 Andre Przywara > + * > + * See file CREDITS for list of people who contributed to this > + * project. > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License as > + * published by the Free Software Foundation; either version 2 of > + * the License, or (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, > + * MA 02111-1307 USA > + */ > + > +#include > + > +/* the vector table for secure state */ > +_monitor_vectors: > + .word 0 /* reset */ > + .word 0 /* undef */ > + adr pc, _secure_monitor > + .word 0 > + .word 0 > + .word 0 > + .word 0 > + .word 0 > + > +/* > + * secure monitor handler > + * U-boot calls this "software interrupt" in start.S > + * This is executed on a "smc" instruction, we use a "smc #0" to switch > + * to non-secure state. > + * We use only r0 and r1 here, due to constraints in the caller. > + */ > + .align 5 > +_secure_monitor: > + mrc p15, 0, r1, c1, c1, 0 @ read SCR > + bic r1, r1, #0x4e @ clear IRQ, FIQ, EA, nET > bits > + orr r1, r1, #0x31 @ enable NS, AW, FW bits > + > + mcr p15, 0, r1, c1, c1, 0 @ write SCR (with NS bit > set) > + > + movspc, lr @ return to non-secure SVC > + > -- > 1.7.12.1 > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > -- -mj ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: ehci: Fix test mode for connected ports
Dear Julius Werner, > > Why 8 * 1000? It's not clear. > > I am not quite sure to be honest... it's been a while since I actually > wrote this patch. The EHCI spec gives no clear max for the > Periodic/Async Schedule disable (I assume not more than a frame, > though), and says the Run/Stop bit must halt within 16 microframes > (which would be 4.125ms). I guess 8 looked like a safe and not too > large value that still makes the line fit on 80 characters (and it's > not like most of the other timeouts in that file have a clear origin, > so it's in good company). What do you want me to change it to? I would like to hear a convincing argument why 8 is the good value. The amount of "I guess" in the text above does not convince me. It would be also good if you didn't sprinkle duplicates of this magic value all around , but instead #define it somewhere and put a beefy comment above it. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How do ARM platform initialize DDR?
On 09/19/2013 02:39 PM, Wolfgang Denk wrote: > Dear York Sun, > > In message <523b67d2.2050...@freescale.com> you wrote: >> >> So for ARM platforms, the majority don't have the flexibility of using >> different DIMMs and/or clocks? > > The majority of ARM systems are embedded designs which never use any > kind of DIMM, but raw soldered-on RAM chips. That explains a lot. > >> Does it make sense to share the Freescale DDR driver across ARM and >> Powerpc? Or does it make more sense to selectively copy the mpc8xxx DDR >> driver to Freescale ARM subfolder to start with. If the similarity > > You are probably in a beter position to answer that than us - how many > ARM systems are there around that use the same memory controller as > the MPC8xxx? Zero as far as I know. But this is changing and this is why I brought it up. I don't want to maintain two set of drivers if not necessary. > >> For those who is not familiar with, Freescale is extending products to >> ARM cores. I am expecting peripherals stay relatively close, so many >> driver can be reused. > > Well, I'm not sure which exact products you might have in mind here, > but from what we've seen so far with the i.MX2x (and mxs), i.MX3x, > iMX5x and i.MX6 systems, there are commnon IP blocks like the FEC, but > so far I haven't seen this with the memory controller. I hope I am not revealing a secret. :) It has been announced that new SoCs are coming. It is still too early. But I am preparing software for it. > > And I haven't seen any single FSL ARM board in our lab yet that was > using any kind ot DIMM or such. > Thanks for confirmation. I will let you know once I learn what the board will look like (not very soon). York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] config: consolidate CONFIG_SYS_HZ definition
On Thu, Sep 19, 2013 at 2:06 PM, Tom Rini wrote: > On Mon, Sep 09, 2013 at 05:41:46PM +0200, Wolfgang Denk wrote: >> Dear Rob, >> >> In message <522de2ff.2080...@gmail.com> you wrote: >> > >> > What do I do with current boards that are wrong? I should make all these >> >> Good question... >> >> > boards have build errors or fix them to use 1000 which may break them at >> > runtime depending on their possible misuse of CONFIG_SYS_HZ? >> > >> > include/configs/KAREF.h:#define CONFIG_SYS_HZ 100 >> > /* decr freq: 1 ms ticks */ >> > include/configs/M5271EVB.h:#define CONFIG_SYS_HZ >> > 100 >> > include/configs/METROBOX.h:#define CONFIG_SYS_HZ >> > 100/* decr freq: 1 ms ticks */ >> > include/configs/MVBLUE.h:#define CONFIG_SYS_HZ 1 >> > include/configs/idmr.h:#define CONFIG_SYS_HZ >> > (5000 / 64) >> > include/configs/mini2440.h:#define CONFIG_SYS_HZ >> > 1562500 >> > include/configs/mx1ads.h:#define CONFIG_SYS_HZ 3686400 >> > include/configs/omap3_zoom2.h:#define CONFIG_SYS_HZ >> > ((V_SCLK) / (2 << CONFIG_SYS_PTV)) >> > include/configs/omap730p2.h:#define CONFIG_SYS_HZ >> > ((CONFIG_SYS_CLK_FREQ)/(2 << CONFIG_SYS_PTV)) >> > include/configs/rsk7203.h:#define CONFIG_SYS_HZ >> > (CONFIG_SYS_CLK_FREQ / CMT_CLK_DIVIDER) >> > include/configs/rsk7264.h:#define CONFIG_SYS_HZ >> > (CONFIG_SYS_CLK_FREQ / CMT_CLK_DIVIDER) >> > include/configs/rsk7269.h:#define CONFIG_SYS_HZ >> > (CONFIG_SYS_CLK_FREQ / CMT_CLK_DIVIDER) >> > include/configs/scb9328.h:#define CONFIG_SYS_HZ 3686400 >> > /* incrementer freq: 3.6864 MHz */ >> > include/configs/versatile.h:#define CONFIG_SYS_HZ >> > (100 / 256) >> >> Hm... which of these boards are actually still being maintained? >> >> KAREF and METROBOX are PPC systems, and the comment suggests that the >> value is actually just a typo. Here it should be harmless to change >> this to use 1000 Hz instead. Ditto probably for MVBLUE. The rest >> might actually be dead? >> >> Guess we should have their builds break and make the board maintainers >> fix them. If they don't (because the boards are unmaintained), we >> will drop the board code from the repo. > > Actually breaking them will cause hell on the folks building everything. > Lets correct the ones we can correct easily and poke maintainers for the > rest so we know what we can/should move to orphaned or just drop. How about just a warning instead? Here's an updated list which missed some: include/configs/M5271EVB.h:#define CONFIG_SYS_HZ100 include/configs/balloon3.h:#define CONFIG_SYS_HZ 325 /* Timer @ 325 Hz */ include/configs/idmr.h:#define CONFIG_SYS_HZ(5000 / 64) include/configs/mini2440.h:#define CONFIG_SYS_HZ1562500 include/configs/mx1ads.h:#define CONFIG_SYS_HZ 3686400 include/configs/omap3_zoom2.h:#define CONFIG_SYS_HZ ((V_SCLK) / (2 << CONFIG_SYS_PTV)) include/configs/omap730p2.h:#define CONFIG_SYS_HZ ((CONFIG_SYS_CLK_FREQ)/(2 << CONFIG_SYS_PTV)) include/configs/palmld.h:#defineCONFIG_SYS_HZ 325 /* Timer @ 325 Hz */ include/configs/palmtc.h:#defineCONFIG_SYS_HZ 3686400 /* Timer @ 3686400 Hz */ include/configs/rsk7203.h:#define CONFIG_SYS_HZ (CONFIG_SYS_CLK_FREQ / CMT_CLK_DIVIDER) include/configs/rsk7264.h:#define CONFIG_SYS_HZ (CONFIG_SYS_CLK_FREQ / CMT_CLK_DIVIDER) include/configs/rsk7269.h:#define CONFIG_SYS_HZ (CONFIG_SYS_CLK_FREQ / CMT_CLK_DIVIDER) include/configs/scb9328.h:#define CONFIG_SYS_HZ 3686400 /* incrementer freq: 3.6864 MHz */ include/configs/versatile.h:#define CONFIG_SYS_HZ (100 / 256) include/configs/zipitz2.h:#define CONFIG_SYS_HZ 325 /* Timer @ 325 Hz */ Rob ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How do ARM platform initialize DDR?
Dear York Sun, In message <523b67d2.2050...@freescale.com> you wrote: > > So for ARM platforms, the majority don't have the flexibility of using > different DIMMs and/or clocks? The majority of ARM systems are embedded designs which never use any kind of DIMM, but raw soldered-on RAM chips. > Does it make sense to share the Freescale DDR driver across ARM and > Powerpc? Or does it make more sense to selectively copy the mpc8xxx DDR > driver to Freescale ARM subfolder to start with. If the similarity You are probably in a beter position to answer that than us - how many ARM systems are there around that use the same memory controller as the MPC8xxx? > For those who is not familiar with, Freescale is extending products to > ARM cores. I am expecting peripherals stay relatively close, so many > driver can be reused. Well, I'm not sure which exact products you might have in mind here, but from what we've seen so far with the i.MX2x (and mxs), i.MX3x, iMX5x and i.MX6 systems, there are commnon IP blocks like the FEC, but so far I haven't seen this with the memory controller. And I haven't seen any single FSL ARM board in our lab yet that was using any kind ot DIMM or such. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "In Christianity neither morality nor religion come into contact with reality at any point." - Friedrich Nietzsche ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 3/8] ARM: add assembly routine to switch to non-secure state
On Fri, Sep 20, 2013 at 3:01 AM, Andre Przywara wrote: > On 09/19/2013 10:38 PM, Mj Embd wrote: > >> Hello Christoffer, >> >> I agree with both of you points. >> >> What I found different in 2 approaches is that in your approach >> S->Monitor->NS->Hyp using svc and hvc >> >> While the other approach is setting the M bits directly in cpsr >> >> Xen uses the following >> >> cpsid aif, #0x16 /* Enter Monitor Mode*/ >> >> ... >> mrs r0, cpsr /* Copy the CPSR */ >> add r0, r0, #0x4 /* 0x16 (Monitor) -> 0x1a (Hyp) */ >> msr spsr_cxsf, r0 /* into the SPSR */ >> movs pc, r3 /* Exception-return into Hyp mode */ >> >> The second one is a bit simpler as it does not involve fault handlers. >> > > The ARM ARM recommends _not_ to do this: > Read more at the ARMv7-A Architecture Reference Manual, section B1.5.1: > Security states/Changing from Secure to Non-secure state: > > "To avoid security holes, software must not: > --Change from Secure to Non-secure state by using an MSR or CPS > instruction to switch from Monitor mode to some other mode while SCR.NS is > 1. > ..." > > > Good one, As per this statement from Secure Monitor to Hyp Mode, HVC should be used. But Secure Supervisor to Secure Monitor does not set NS=1 so first part cpsid aif, #0x16 is valid ? Or there is some other statement in the manual which I am not aware of ? > >> I was just suggesting that the best approach to be used ... >> > > Looks like this is what we do ;-) > > Regards, > Andre. > > > >> On 9/20/13, Christoffer Dall wrote: >> >>> On Fri, Sep 20, 2013 at 01:27:48AM +0530, Mj Embd wrote: >>> two quick points (a) xen already has a mode_switch code, so AFAIK xen might not use it (as suggested by comment in another patch in this patch set) >>> >>> For KVM the boot procedure for Hyp mode is quite clearly defined: the >>> kernel must be booted in Hyp mode. >>> >>> I was under the impression that Xen wanted to use the same paradigm and >>> rely on bootloaders to switch to Hyp mode and thereby get rid of the >>> code in Xen. >>> >>> (b) There are 2 methods of switching from Secure to Hyp mode one you have proposed another implemented in xen. I was suggesting take the best approach >>> Can you please be more specific? Not everyone here knows the Xen >>> low-level mode switch details by heart. As far as I know, there is only >>> one architecturally defined proper mode to switch from secure mode to >>> non-secure mode, and the state that needs to be configured for Hyp-mode >>> and NS-mode is well defined. Obviously two implementation can do things >>> differently (different order, different programminge environment, etc.) >>> but that doesn't mean one is better than the other. >>> >>> I think it would be more productive if you can simply look at this code >>> and if you think some things are done more efficiently in Xen, please >>> comment on that, which would be very helpful. I'm afraid there's no >>> magic way to apply a block of Xen code into U-Boot wihtout manual >>> adjustment anyway, or the other way around for that matter. >>> >>> -Christoffer >>> >>> >> >> > -- -mj ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How do ARM platform initialize DDR?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/19/2013 05:08 PM, York Sun wrote: > On 09/19/2013 01:57 PM, Tom Rini wrote: >> On Tue, Sep 17, 2013 at 08:59:24AM -0700, York Sun wrote: >> >>> Albert, >>> >>> Pardon me if this is a dumb question. I have been working on >>> powerpc platforms in the past. Now we (the developers I work >>> with) are exploring ARM cores. I am searching how memory is >>> initialized and found different solutions. Some platforms have >>> memory ready before u-boot even starts, some simply write to a >>> set of registers. I understand many platforms don't share the >>> IP of DDR controller. I am wondering if there is generic DDR >>> driver used by many ARM platforms, like the one we have for >>> powerpc/mpc85xx SoCs. >> >> Thinking back, as a rule of thumb, PowerPC has SPD I2C data >> available, usually. That's not the rule for ARM. One of a few >> choices happen: 1) ROM sets up DDR. 2) U-Boot/SPL sets up the DDR >> controller. >> > > So for ARM platforms, the majority don't have the flexibility of > using different DIMMs and/or clocks? It's a different world. Again, thinking back to the PowerPC boards I've seen, they had "regular" DDR sockets. Most ARM boards don't. You can design your board with whatever, and I know in prototyping folks make do swapping chips in and out (and if you look at the omap code, you can see where we have code to calculate the timing values and print them, or use provided hard-coded values). >> The problem is that the DDR controller is usually >> vendor-specific. Perhaps the flip-side here is that there's not >> so much a generic DDR driver for mpc85xx but simply one vendor >> for mpc85xx. Taking arch/powerpc/cpu/mpc85xx/ddr-gen3.c as what >> you're talking about, >> arch/arm/cpu/armv7/omap-common/emif-common.c would be an >> ARM-world example (the 'EMIF' is found on a large variety of TI >> parts, not just "omap" ones). > > Does it make sense to share the Freescale DDR driver across ARM > and Powerpc? Or does it make more sense to selectively copy the > mpc8xxx DDR driver to Freescale ARM subfolder to start with. If the > similarity sustains then we merge them into common driver. If not, > we maintain two separated drivers. > > For those who is not familiar with, Freescale is extending products > to ARM cores. I am expecting peripherals stay relatively close, so > many driver can be reused. I've been wondering when this would start to be visible. If we are able to share the DDR controller code between mpc85xx and the ARM stuff you're talking about, we'll have to sort out someplace within drivers/ to place it, to avoid #include nightmares I suspect. Other drivers should be easier to share at least :) - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSO22RAAoJENk4IS6UOR1WhJYQALM/XAMzPMMH4WJD8PkO7DqJ HB3WI2oopdm096Bfe8ZT2MPpuEm6OuIb/5HjacED0XxfCHT59NVxIo5tI51IEbqH 74k3LtvTMgADqVw092H3LsFFIJWPd0MsWCDian+NuAp8g03PK9eDOgczQujYflm/ cs6En1hYp+QolbxdHxpQ0HKwNxzA+bkT6JGzF2ziutp8P+wTHh5ypjtFCwF8h4cG IrGAhePYPHXZzCZYGRPWD0CXthcizXCuRCpykflEGpUsTOR0Cd/2UT0jBFh3aUCU jalrVG/LjhUWqO+IEzAhOtML4Z84oFLQQ5EBmwAOnt+ql6sxk2+L8kxEMWUzaE23 EppRrT7HDHI/Uc7ogeJP5JNjiYGmmp0dLhqIK3vIJ8pAyenj8TcOW2q0Y7eCrItN UPJNrYGLKXHC1f5OpfMSJG33lNRJY2oSI+D2ELENMtXBiC9y3nb8Lqar7GjJ6VQq BJcEbCNUT1IVqvCP/OsYKhtssqHdKYmjfSd9oOHonhwmZTqEyVh08/U1LIfIiYfa 7lody/RNVvnbUKjlojiBR6upJbfGC6YJSDQUzy02zf4gPNF01Q1rXO5fT6vfIa1z YVM5yV4MJ8F0Phma2uOk25NLgRmDcXeL4LCvpOOQUi3+ymMqMarmZwRdThARsBKh 1tFCkl3LA01CtGdZCzBI =INiu -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 3/8] ARM: add assembly routine to switch to non-secure state
On 09/19/2013 10:38 PM, Mj Embd wrote: Hello Christoffer, I agree with both of you points. What I found different in 2 approaches is that in your approach S->Monitor->NS->Hyp using svc and hvc While the other approach is setting the M bits directly in cpsr Xen uses the following cpsid aif, #0x16 /* Enter Monitor Mode*/ ... mrs r0, cpsr /* Copy the CPSR */ add r0, r0, #0x4 /* 0x16 (Monitor) -> 0x1a (Hyp) */ msr spsr_cxsf, r0 /* into the SPSR */ movs pc, r3 /* Exception-return into Hyp mode */ The second one is a bit simpler as it does not involve fault handlers. The ARM ARM recommends _not_ to do this: Read more at the ARMv7-A Architecture Reference Manual, section B1.5.1: Security states/Changing from Secure to Non-secure state: "To avoid security holes, software must not: --Change from Secure to Non-secure state by using an MSR or CPS instruction to switch from Monitor mode to some other mode while SCR.NS is 1. ..." I was just suggesting that the best approach to be used ... Looks like this is what we do ;-) Regards, Andre. On 9/20/13, Christoffer Dall wrote: On Fri, Sep 20, 2013 at 01:27:48AM +0530, Mj Embd wrote: two quick points (a) xen already has a mode_switch code, so AFAIK xen might not use it (as suggested by comment in another patch in this patch set) For KVM the boot procedure for Hyp mode is quite clearly defined: the kernel must be booted in Hyp mode. I was under the impression that Xen wanted to use the same paradigm and rely on bootloaders to switch to Hyp mode and thereby get rid of the code in Xen. (b) There are 2 methods of switching from Secure to Hyp mode one you have proposed another implemented in xen. I was suggesting take the best approach Can you please be more specific? Not everyone here knows the Xen low-level mode switch details by heart. As far as I know, there is only one architecturally defined proper mode to switch from secure mode to non-secure mode, and the state that needs to be configured for Hyp-mode and NS-mode is well defined. Obviously two implementation can do things differently (different order, different programminge environment, etc.) but that doesn't mean one is better than the other. I think it would be more productive if you can simply look at this code and if you think some things are done more efficiently in Xen, please comment on that, which would be very helpful. I'm afraid there's no magic way to apply a block of Xen code into U-Boot wihtout manual adjustment anyway, or the other way around for that matter. -Christoffer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: prevent using movt/movw address loads
On Sat, Aug 24, 2013 at 01:55:38PM +0200, Jeroen Hofstee wrote: > The movt/movw instruction can be used to hardcode an > memory location in the instruction itself. The linker > starts complaining about this if the compiler decides > to do so: "relocation R_ARM_MOVW_ABS_NC against `a local > symbol' can not be used" and it is not support by U-boot > as well. Prevent their use by requiring word relocations. > This allows u-boot to be build at other optimalization > levels then -Os. > > Signed-off-by: Jeroen Hofstee > Cc: tiger...@viatech.com.cn > Cc: Albert ARIBAUD > --- > arch/arm/config.mk | 8 ++-- > 1 file changed, 6 insertions(+), 2 deletions(-) Is this also something we need for llvm? I am hesitant here because as Wolfgang points out, -O0 is usually the wrong way to debug a problem and I'll add we're well into the age where debuggers work just fine with optimized code. If there's some -O2 enabled gcc flag we want because of a measurable performance win, we should add it specifically to -Os. -- 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 v5 3/8] ARM: add assembly routine to switch to non-secure state
On Thu, 2013-09-19 at 21:11 +0100, Christoffer Dall wrote: > On Fri, Sep 20, 2013 at 01:27:48AM +0530, Mj Embd wrote: > > two quick points > > (a) xen already has a mode_switch code, so AFAIK xen might not use it > > (as suggested by comment in another patch in this patch set) > > For KVM the boot procedure for Hyp mode is quite clearly defined: the > kernel must be booted in Hyp mode. > > I was under the impression that Xen wanted to use the same paradigm and > rely on bootloaders to switch to Hyp mode and thereby get rid of the > code in Xen. Absolutely correct, our needs are the same as KVM and we want to be booted in the same way. Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 3/8] ARM: add assembly routine to switch to non-secure state
On Fri, 2013-09-20 at 01:27 +0530, Mj Embd wrote: > two quick points > (a) xen already has a mode_switch code, so AFAIK xen might not use it > (as suggested by comment in another patch in this patch set) Xen absolutely wants to use this code. The stuff in Xen was there as a hack when this stuff wasn't present in the bootloader. The sooner it can be removed the happier I will be. Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How do ARM platform initialize DDR?
On 09/19/2013 01:57 PM, Tom Rini wrote: > On Tue, Sep 17, 2013 at 08:59:24AM -0700, York Sun wrote: > >> Albert, >> >> Pardon me if this is a dumb question. I have been working on powerpc >> platforms in the past. Now we (the developers I work with) are exploring >> ARM cores. I am searching how memory is initialized and found different >> solutions. Some platforms have memory ready before u-boot even starts, >> some simply write to a set of registers. I understand many platforms >> don't share the IP of DDR controller. I am wondering if there is generic >> DDR driver used by many ARM platforms, like the one we have for >> powerpc/mpc85xx SoCs. > > Thinking back, as a rule of thumb, PowerPC has SPD I2C data > available, usually. That's not the rule for ARM. One of a few choices > happen: > 1) ROM sets up DDR. > 2) U-Boot/SPL sets up the DDR controller. > So for ARM platforms, the majority don't have the flexibility of using different DIMMs and/or clocks? > The problem is that the DDR controller is usually vendor-specific. > Perhaps the flip-side here is that there's not so much a generic DDR > driver for mpc85xx but simply one vendor for mpc85xx. Taking > arch/powerpc/cpu/mpc85xx/ddr-gen3.c as what you're talking about, > arch/arm/cpu/armv7/omap-common/emif-common.c would be an ARM-world > example (the 'EMIF' is found on a large variety of TI parts, not just > "omap" ones). Does it make sense to share the Freescale DDR driver across ARM and Powerpc? Or does it make more sense to selectively copy the mpc8xxx DDR driver to Freescale ARM subfolder to start with. If the similarity sustains then we merge them into common driver. If not, we maintain two separated drivers. For those who is not familiar with, Freescale is extending products to ARM cores. I am expecting peripherals stay relatively close, so many driver can be reused. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 3/8] ARM: add assembly routine to switch to non-secure state
On 09/19/2013 09:57 PM, Mj Embd wrote: two quick points (a) xen already has a mode_switch code, so AFAIK xen might not use it (as suggested by comment in another patch in this patch set) Just a few days ago Ian sent out patches to remove this code from Xen. That code was never meant to survive, just to have something working to let people play with Xen easily. Xen now requires to be started in HYP mode, just like KVM. http://lists.xen.org/archives/html/xen-devel/2013-09/msg01690.html Patch 5/7 has more details. Regards, Andre. (b) There are 2 methods of switching from Secure to Hyp mode one you have proposed another implemented in xen. I was suggesting take the best approach On 9/20/13, Christoffer Dall wrote: On Thu, Sep 19, 2013 at 10:00:03PM +0530, Mj Embd wrote: Hi Andre, There is another approach taken in xen. (xen/arch/arm/mode_switch.S) Which do you think is the better approach Hi there, I'm not sure I completely understand your question. Do you think this patch series should be changed to take something from Xen? If so, can you please clarify why? For the record, this patch series has been reviewed and tested quite a lot for U-Boot and we would very much like to get this merged and avoid further churn, unless there's a compelling technical reason to change it. Thanks, -Christoffer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] NAND flash question
All, We have a design that has NAND as a secondary device (not the boot device). The last four pages of the NAND flash are reported as bad. Should this be true for all NAND flash devices we have? Thanks, Andy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NAND flash question
On 09/19/2013 04:04 PM, ANDY KENNEDY wrote: > All, > > We have a design that has NAND as a secondary device (not the boot > device). The last four pages of the NAND flash are reported as bad. > Should this be true for all NAND flash devices we have? > > No, I wouldn't think so. Manufacturers qualify their parts and mark bad blocks found during qualification testing. Most data sheets indicate that the number of bad blocks marked bad during manufacturer is below a set percentage(if above thent he part is rejected). Some parts that are meant to be used during boot (such as NAND meant for OMAP parts) will have certain blocks that are guaranteed good (i.e. the boot blocks). Past that bad blocks could be anywhere in a particular device. -- Peter Barada peter.bar...@logicpd.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 3/8] ARM: add assembly routine to switch to non-secure state
On Fri, Sep 20, 2013 at 01:27:48AM +0530, Mj Embd wrote: > two quick points > (a) xen already has a mode_switch code, so AFAIK xen might not use it > (as suggested by comment in another patch in this patch set) For KVM the boot procedure for Hyp mode is quite clearly defined: the kernel must be booted in Hyp mode. I was under the impression that Xen wanted to use the same paradigm and rely on bootloaders to switch to Hyp mode and thereby get rid of the code in Xen. > (b) There are 2 methods of switching from Secure to Hyp mode > one you have proposed another implemented in xen. I was suggesting > take the best approach > Can you please be more specific? Not everyone here knows the Xen low-level mode switch details by heart. As far as I know, there is only one architecturally defined proper mode to switch from secure mode to non-secure mode, and the state that needs to be configured for Hyp-mode and NS-mode is well defined. Obviously two implementation can do things differently (different order, different programminge environment, etc.) but that doesn't mean one is better than the other. I think it would be more productive if you can simply look at this code and if you think some things are done more efficiently in Xen, please comment on that, which would be very helpful. I'm afraid there's no magic way to apply a block of Xen code into U-Boot wihtout manual adjustment anyway, or the other way around for that matter. -Christoffer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 3/8] ARM: add assembly routine to switch to non-secure state
Hello Christoffer, I agree with both of you points. What I found different in 2 approaches is that in your approach S->Monitor->NS->Hyp using svc and hvc While the other approach is setting the M bits directly in cpsr Xen uses the following cpsid aif, #0x16 /* Enter Monitor Mode*/ ... mrs r0, cpsr /* Copy the CPSR */ add r0, r0, #0x4 /* 0x16 (Monitor) -> 0x1a (Hyp) */ msr spsr_cxsf, r0 /* into the SPSR */ movs pc, r3 /* Exception-return into Hyp mode */ The second one is a bit simpler as it does not involve fault handlers. I was just suggesting that the best approach to be used ... Best Regards, mj On 9/20/13, Christoffer Dall wrote: > On Fri, Sep 20, 2013 at 01:27:48AM +0530, Mj Embd wrote: >> two quick points >> (a) xen already has a mode_switch code, so AFAIK xen might not use it >> (as suggested by comment in another patch in this patch set) > > For KVM the boot procedure for Hyp mode is quite clearly defined: the > kernel must be booted in Hyp mode. > > I was under the impression that Xen wanted to use the same paradigm and > rely on bootloaders to switch to Hyp mode and thereby get rid of the > code in Xen. > >> (b) There are 2 methods of switching from Secure to Hyp mode >> one you have proposed another implemented in xen. I was suggesting >> take the best approach >> > > Can you please be more specific? Not everyone here knows the Xen > low-level mode switch details by heart. As far as I know, there is only > one architecturally defined proper mode to switch from secure mode to > non-secure mode, and the state that needs to be configured for Hyp-mode > and NS-mode is well defined. Obviously two implementation can do things > differently (different order, different programminge environment, etc.) > but that doesn't mean one is better than the other. > > I think it would be more productive if you can simply look at this code > and if you think some things are done more efficiently in Xen, please > comment on that, which would be very helpful. I'm afraid there's no > magic way to apply a block of Xen code into U-Boot wihtout manual > adjustment anyway, or the other way around for that matter. > > -Christoffer > -- -mj ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 3/8] ARM: add assembly routine to switch to non-secure state
two quick points (a) xen already has a mode_switch code, so AFAIK xen might not use it (as suggested by comment in another patch in this patch set) (b) There are 2 methods of switching from Secure to Hyp mode one you have proposed another implemented in xen. I was suggesting take the best approach On 9/20/13, Christoffer Dall wrote: > On Thu, Sep 19, 2013 at 10:00:03PM +0530, Mj Embd wrote: >> Hi Andre, >> >> There is another approach taken in xen. (xen/arch/arm/mode_switch.S) >> Which do you think is the better approach >> > Hi there, > > I'm not sure I completely understand your question. Do you think this > patch series should be changed to take something from Xen? If so, can > you please clarify why? > > For the record, this patch series has been reviewed and tested quite a > lot for U-Boot and we would very much like to get this merged and avoid > further churn, unless there's a compelling technical reason to change > it. > > Thanks, > -Christoffer > -- -mj ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] config: consolidate CONFIG_SYS_HZ definition
On Mon, Sep 09, 2013 at 05:41:46PM +0200, Wolfgang Denk wrote: > Dear Rob, > > In message <522de2ff.2080...@gmail.com> you wrote: > > > > What do I do with current boards that are wrong? I should make all these > > Good question... > > > boards have build errors or fix them to use 1000 which may break them at > > runtime depending on their possible misuse of CONFIG_SYS_HZ? > > > > include/configs/KAREF.h:#define CONFIG_SYS_HZ 100 > > /* decr freq: 1 ms ticks */ > > include/configs/M5271EVB.h:#define CONFIG_SYS_HZ > > 100 > > include/configs/METROBOX.h:#define CONFIG_SYS_HZ > > 100/* decr freq: 1 ms ticks */ > > include/configs/MVBLUE.h:#define CONFIG_SYS_HZ 1 > > include/configs/idmr.h:#define CONFIG_SYS_HZ > > (5000 / 64) > > include/configs/mini2440.h:#define CONFIG_SYS_HZ > > 1562500 > > include/configs/mx1ads.h:#define CONFIG_SYS_HZ 3686400 > > include/configs/omap3_zoom2.h:#define CONFIG_SYS_HZ > > ((V_SCLK) / (2 << CONFIG_SYS_PTV)) > > include/configs/omap730p2.h:#define CONFIG_SYS_HZ > > ((CONFIG_SYS_CLK_FREQ)/(2 << CONFIG_SYS_PTV)) > > include/configs/rsk7203.h:#define CONFIG_SYS_HZ > > (CONFIG_SYS_CLK_FREQ / CMT_CLK_DIVIDER) > > include/configs/rsk7264.h:#define CONFIG_SYS_HZ > > (CONFIG_SYS_CLK_FREQ / CMT_CLK_DIVIDER) > > include/configs/rsk7269.h:#define CONFIG_SYS_HZ > > (CONFIG_SYS_CLK_FREQ / CMT_CLK_DIVIDER) > > include/configs/scb9328.h:#define CONFIG_SYS_HZ 3686400 > > /* incrementer freq: 3.6864 MHz */ > > include/configs/versatile.h:#define CONFIG_SYS_HZ > > (100 / 256) > > Hm... which of these boards are actually still being maintained? > > KAREF and METROBOX are PPC systems, and the comment suggests that the > value is actually just a typo. Here it should be harmless to change > this to use 1000 Hz instead. Ditto probably for MVBLUE. The rest > might actually be dead? > > Guess we should have their builds break and make the board maintainers > fix them. If they don't (because the boards are unmaintained), we > will drop the board code from the repo. Actually breaking them will cause hell on the folks building everything. Lets correct the ones we can correct easily and poke maintainers for the rest so we know what we can/should move to orphaned or just drop. -- 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 v5 3/8] ARM: add assembly routine to switch to non-secure state
On Thu, Sep 19, 2013 at 10:00:03PM +0530, Mj Embd wrote: > Hi Andre, > > There is another approach taken in xen. (xen/arch/arm/mode_switch.S) > Which do you think is the better approach > Hi there, I'm not sure I completely understand your question. Do you think this patch series should be changed to take something from Xen? If so, can you please clarify why? For the record, this patch series has been reviewed and tested quite a lot for U-Boot and we would very much like to get this merged and avoid further churn, unless there's a compelling technical reason to change it. Thanks, -Christoffer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/3] i2c: fix init on generic board
Signed-off-by: Philippe Reynes
---
common/board_f.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/common/board_f.c b/common/board_f.c
index 0ada1af..f0664bc 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -249,7 +249,11 @@ void dram_init_banksize(void)
static int init_func_i2c(void)
{
puts("I2C: ");
+#ifdef CONFIG_SYS_I2C
+ i2c_init_all();
+#else
i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
+#endif
puts("ready\n");
return 0;
}
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/3] i2c: mxc: move to new subsystem
Signed-off-by: Philippe Reynes
---
README | 11 +++
arch/arm/cpu/armv7/mx5/clock.c |2 +-
arch/arm/cpu/armv7/mx6/clock.c |2 +-
arch/arm/imx-common/Makefile |2 +-
drivers/i2c/Makefile |2 +-
drivers/i2c/mxc_i2c.c | 137 +++-
6 files changed, 93 insertions(+), 63 deletions(-)
diff --git a/README b/README
index 63706be..5d9ecc2 100644
--- a/README
+++ b/README
@@ -1995,6 +1995,17 @@ CBFS (Coreboot Filesystem) support
- CONFIG_SYS_I2C_PPC4XX_CH0 activate hardware channel 0
- CONFIG_SYS_I2C_PPC4XX_CH1 activate hardware channel 1
+ - drivers/i2c/i2c_mxc.c
+ - activate this driver with CONFIG_SYS_I2C_MXC
+ - define speed for bus 1 with CONFIG_SYS_MXC_I2C1_SPEED
+ - define slave for bus 1 with CONFIG_SYS_MXC_I2C1_SLAVE
+ - define speed for bus 2 with CONFIG_SYS_MXC_I2C2_SPEED
+ - define slave for bus 2 with CONFIG_SYS_MXC_I2C2_SLAVE
+ - define speed for bus 3 with CONFIG_SYS_MXC_I2C3_SPEED
+ - define slave for bus 3 with CONFIG_SYS_MXC_I2C3_SLAVE
+ If thoses defines are not set, default value is 10
+ for speed, and 0 for slave.
+
additional defines:
CONFIG_SYS_NUM_I2C_BUSES
diff --git a/arch/arm/cpu/armv7/mx5/clock.c b/arch/arm/cpu/armv7/mx5/clock.c
index 6bef254..fb3b128 100644
--- a/arch/arm/cpu/armv7/mx5/clock.c
+++ b/arch/arm/cpu/armv7/mx5/clock.c
@@ -94,7 +94,7 @@ void enable_usboh3_clk(bool enable)
MXC_CCM_CCGR2_USBOH3_60M(cg));
}
-#ifdef CONFIG_I2C_MXC
+#ifdef CONFIG_SYS_I2C_MXC
/* i2c_num can be from 0, to 1 for i.MX51 and 2 for i.MX53 */
int enable_i2c_clk(unsigned char enable, unsigned i2c_num)
{
diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c
index 7efb0d2..8130827 100644
--- a/arch/arm/cpu/armv7/mx6/clock.c
+++ b/arch/arm/cpu/armv7/mx6/clock.c
@@ -48,7 +48,7 @@ void enable_usboh3_clk(unsigned char enable)
}
-#ifdef CONFIG_I2C_MXC
+#ifdef CONFIG_SYS_I2C_MXC
/* i2c_num can be from 0 - 2 */
int enable_i2c_clk(unsigned char enable, unsigned i2c_num)
{
diff --git a/arch/arm/imx-common/Makefile b/arch/arm/imx-common/Makefile
index 727a052..6c78dd9 100644
--- a/arch/arm/imx-common/Makefile
+++ b/arch/arm/imx-common/Makefile
@@ -16,7 +16,7 @@ COBJS-y = iomux-v3.o
endif
ifeq ($(SOC),$(filter $(SOC),mx5 mx6))
COBJS-y+= timer.o cpu.o speed.o
-COBJS-$(CONFIG_I2C_MXC) += i2c-mxv7.o
+COBJS-$(CONFIG_SYS_I2C_MXC) += i2c-mxv7.o
endif
ifeq ($(SOC),$(filter $(SOC),mx6 mxs))
COBJS-y+= misc.o
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index 37ccbd1..2433182 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -14,7 +14,6 @@ COBJS-$(CONFIG_DRIVER_DAVINCI_I2C) += davinci_i2c.o
COBJS-$(CONFIG_DW_I2C) += designware_i2c.o
COBJS-$(CONFIG_I2C_MVTWSI) += mvtwsi.o
COBJS-$(CONFIG_I2C_MV) += mv_i2c.o
-COBJS-$(CONFIG_I2C_MXC) += mxc_i2c.o
COBJS-$(CONFIG_I2C_MXS) += mxs_i2c.o
COBJS-$(CONFIG_DRIVER_OMAP1510_I2C) += omap1510_i2c.o
COBJS-$(CONFIG_DRIVER_OMAP24XX_I2C) += omap24xx_i2c.o
@@ -29,6 +28,7 @@ COBJS-$(CONFIG_SH_SH7734_I2C) += sh_sh7734_i2c.o
COBJS-$(CONFIG_SYS_I2C) += i2c_core.o
COBJS-$(CONFIG_SYS_I2C_FSL) += fsl_i2c.o
COBJS-$(CONFIG_SYS_I2C_FTI2C010) += fti2c010.o
+COBJS-$(CONFIG_SYS_I2C_MXC) += mxc_i2c.o
COBJS-$(CONFIG_SYS_I2C_PPC4XX) += ppc4xx_i2c.o
COBJS-$(CONFIG_SYS_I2C_SOFT) += soft_i2c.o
COBJS-$(CONFIG_SYS_I2C_TEGRA) += tegra_i2c.o
diff --git a/drivers/i2c/mxc_i2c.c b/drivers/i2c/mxc_i2c.c
index 06ba4e3..595019b 100644
--- a/drivers/i2c/mxc_i2c.c
+++ b/drivers/i2c/mxc_i2c.c
@@ -102,6 +102,28 @@ static u16 i2c_clk_div[50][2] = {
};
#endif
+
+#ifndef CONFIG_SYS_MXC_I2C1_SPEED
+#define CONFIG_SYS_MXC_I2C1_SPEED 10
+#endif
+#ifndef CONFIG_SYS_MXC_I2C2_SPEED
+#define CONFIG_SYS_MXC_I2C2_SPEED 10
+#endif
+#ifndef CONFIG_SYS_MXC_I2C3_SPEED
+#define CONFIG_SYS_MXC_I2C3_SPEED 10
+#endif
+
+#ifndef CONFIG_SYS_MXC_I2C1_SLAVE
+#define CONFIG_SYS_MXC_I2C1_SLAVE 0
+#endif
+#ifndef CONFIG_SYS_MXC_I2C2_SLAVE
+#define CONFIG_SYS_MXC_I2C2_SLAVE 0
+#endif
+#ifndef CONFIG_SYS_MXC_I2C3_SLAVE
+#define CONFIG_SYS_MXC_I2C3_SLAVE 0
+#endif
+
+
/*
* Calculate and set proper clock divider
*/
@@ -153,21 +175,6 @@ static int bus_i2c_set_bus_speed(void *base, int speed)
return 0;
}
-/*
- * Get I2C Speed
- */
-static unsigned int bus_i2c_get_bus_speed(void *base)
-{
- struct mxc_i2c_regs *i2c_regs = (struct mxc_i2c_regs *)base;
- u8 clk_idx = readb(&i2c_regs->ifdr);
- u8 clk_div;
-
- for (clk_div = 0; i2c_clk_div[clk_div][1] != clk_idx; clk_div++)
- ;
-
- return mxc_get_clock(MXC_I2C_CLK) / i2c_clk_div[clk_div][0];
-}
-
#define ST_BUS_IDLE (0 | (I2SR_IBB << 8))
#define ST_BUS_BUSY (I2SR_IBB | (I2SR_IBB << 8))
#define
[U-Boot] [PATCH v3 0/3] i2c, mxc: switch to new multibus/multiadapter framework
This serie is composed of three patches: - one to fix the i2c init on the generic board - one to port the i2c mxc driver to new subsystem - one to update all configurations with i2c mxc driver This serie was tested with success on armadeus apf27. Difference between v3 and v2: - change title of patch 2 (specify mxc) Difference between v2 and v1: - change title of the serie - use define for speed and slave for each i2c bus - sort i2c driver list - define mxc function as static - remove CONFIG_I2C_MULTI_BUS in config using i2c mxc Philippe Reynes (3): i2c: fix init on generic board i2c: mxc: move to new subsystem i2c: update config using mxc driver to new subsystem README| 11 +++ arch/arm/cpu/armv7/mx5/clock.c|2 +- arch/arm/cpu/armv7/mx6/clock.c|2 +- arch/arm/imx-common/Makefile |2 +- common/board_f.c |4 + drivers/i2c/Makefile |2 +- drivers/i2c/mxc_i2c.c | 137 + include/configs/apf27.h | 11 ++-- include/configs/flea3.h |9 +-- include/configs/imx31_phycore.h |7 +- include/configs/m53evk.h |7 +- include/configs/mx25pdk.h |7 +- include/configs/mx35pdk.h |7 +- include/configs/mx53ard.h |7 +- include/configs/mx53evk.h |7 +- include/configs/mx53loco.h|7 +- include/configs/mx53smd.h |7 +- include/configs/mx6qsabreauto.h |4 +- include/configs/nitrogen6x.h |4 +- include/configs/titanium.h|4 +- include/configs/vf610twr.h|7 +- include/configs/woodburn_common.h |7 +- 22 files changed, 143 insertions(+), 119 deletions(-) -- 1.7.4.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 3/3] i2c: update config using mxc driver to new subsystem
Signed-off-by: Philippe Reynes
---
include/configs/apf27.h | 11 ++-
include/configs/flea3.h |9 -
include/configs/imx31_phycore.h |7 +++
include/configs/m53evk.h |7 +++
include/configs/mx25pdk.h |7 +++
include/configs/mx35pdk.h |7 +++
include/configs/mx53ard.h |7 +++
include/configs/mx53evk.h |7 +++
include/configs/mx53loco.h|7 +++
include/configs/mx53smd.h |7 +++
include/configs/mx6qsabreauto.h |4 ++--
include/configs/nitrogen6x.h |4 ++--
include/configs/titanium.h|4 ++--
include/configs/vf610twr.h|7 +++
include/configs/woodburn_common.h |7 +++
15 files changed, 46 insertions(+), 56 deletions(-)
diff --git a/include/configs/apf27.h b/include/configs/apf27.h
index e7e258f..1193013 100644
--- a/include/configs/apf27.h
+++ b/include/configs/apf27.h
@@ -321,11 +321,12 @@
*/
#ifdef CONFIG_CMD_I2C
-#define CONFIG_HARD_I2C
-#define CONFIG_I2C_MXC
-#define CONFIG_SYS_I2C_BASEIMX_I2C1_BASE
-#define CONFIG_SYS_I2C_SPEED 10 /* 100 kHz */
-#define CONFIG_SYS_I2C_SLAVE 0x7F
+#define CONFIG_SYS_I2C
+#define CONFIG_SYS_I2C_MXC
+#define CONFIG_SYS_MXC_I2C1_SPEED 10 /* 100 kHz */
+#define CONFIG_SYS_MXC_I2C1_SLAVE 0x7F
+#define CONFIG_SYS_MXC_I2C2_SPEED 10 /* 100 kHz */
+#define CONFIG_SYS_MXC_I2C2_SLAVE 0x7F
#define CONFIG_SYS_I2C_NOPROBES{ }
#ifdef CONFIG_CMD_EEPROM
diff --git a/include/configs/flea3.h b/include/configs/flea3.h
index cfcaf1b..a330d39 100644
--- a/include/configs/flea3.h
+++ b/include/configs/flea3.h
@@ -50,11 +50,10 @@
/*
* Hardware drivers
*/
-#define CONFIG_HARD_I2C
-#define CONFIG_I2C_MXC
-#define CONFIG_SYS_I2C_BASEI2C3_BASE_ADDR
-#define CONFIG_SYS_I2C_SPEED 10
-#define CONFIG_SYS_I2C_SLAVE 0xfe
+#define CONFIG_SYS_I2C
+#define CONFIG_SYS_I2C_MXC
+#define CONFIG_SYS_SPD_BUS_NUM 2 /* I2C3 */
+#define CONFIG_SYS_MXC_I2C3_SLAVE 0xfe
#define CONFIG_MXC_SPI
#define CONFIG_MXC_GPIO
diff --git a/include/configs/imx31_phycore.h b/include/configs/imx31_phycore.h
index 720e1bf..db43f19 100644
--- a/include/configs/imx31_phycore.h
+++ b/include/configs/imx31_phycore.h
@@ -35,11 +35,10 @@
* Hardware drivers
*/
-#define CONFIG_HARD_I2C
-#define CONFIG_I2C_MXC
-#define CONFIG_SYS_I2C_BASEI2C2_BASE_ADDR
+#define CONFIG_SYS_I2C
+#define CONFIG_SYS_I2C_MXC
+#define CONFIG_SYS_SPD_BUS_NUM 1 /* I2C2 */
#define CONFIG_SYS_I2C_CLK_OFFSET I2C2_CLK_OFFSET
-#define CONFIG_SYS_I2C_SPEED 10
#define CONFIG_MXC_UART
#define CONFIG_MXC_UART_BASE UART1_BASE
diff --git a/include/configs/m53evk.h b/include/configs/m53evk.h
index ccb07e3..1fd8b72 100644
--- a/include/configs/m53evk.h
+++ b/include/configs/m53evk.h
@@ -161,10 +161,9 @@
* I2C
*/
#ifdef CONFIG_CMD_I2C
-#define CONFIG_HARD_I2C
-#define CONFIG_I2C_MXC
-#define CONFIG_SYS_I2C_BASEI2C2_BASE_ADDR
-#define CONFIG_SYS_I2C_SPEED 10
+#define CONFIG_SYS_I2C
+#define CONFIG_SYS_I2C_MXC
+#define CONFIG_SYS_SPD_BUS_NUM 1 /* I2C2 */
#endif
/*
diff --git a/include/configs/mx25pdk.h b/include/configs/mx25pdk.h
index 543c415..256b3c1 100644
--- a/include/configs/mx25pdk.h
+++ b/include/configs/mx25pdk.h
@@ -111,10 +111,9 @@
/* I2C Configs */
#define CONFIG_CMD_I2C
-#define CONFIG_HARD_I2C
-#define CONFIG_I2C_MXC
-#define CONFIG_SYS_I2C_BASEIMX_I2C_BASE
-#define CONFIG_SYS_I2C_SPEED 10
+#define CONFIG_SYS_I2C
+#define CONFIG_SYS_I2C_MXC
+#define CONFIG_SYS_SPD_BUS_NUM 0 /* I2C1 */
/* RTC */
#define CONFIG_RTC_IMXDI
diff --git a/include/configs/mx35pdk.h b/include/configs/mx35pdk.h
index 68b225a..8966581 100644
--- a/include/configs/mx35pdk.h
+++ b/include/configs/mx35pdk.h
@@ -41,10 +41,9 @@
/*
* Hardware drivers
*/
-#define CONFIG_HARD_I2C
-#define CONFIG_I2C_MXC
-#define CONFIG_SYS_I2C_BASEI2C1_BASE_ADDR
-#define CONFIG_SYS_I2C_SPEED 10
+#define CONFIG_SYS_I2C
+#define CONFIG_SYS_I2C_MXC
+#define CONFIG_SYS_SPD_BUS_NUM 0 /* I2C1 */
#define CONFIG_MXC_SPI
#define CONFIG_MXC_GPIO
diff --git a/include/configs/mx53ard.h b/include/configs/mx53ard.h
index 122ffd0..f0cc483 100644
--- a/include/configs/mx53ard.h
+++ b/include/configs/mx53ard.h
@@ -44,10 +44,9 @@
/* I2C Configs */
#define CONFIG_CMD_I2C
-#define CONFIG_HARD_I2C
-#define CONFIG_I2C_MXC
-#define CONFIG_SYS_I2C_BASEI2C2_BASE_ADDR
-#define CONFIG_SYS_I2C_SPEED10
+#define CONFIG_SYS_I2C
+#define CONFIG_SYS_I2C_MXC
+#define CONFIG_SYS_SPD_BUS_NUM 1 /* I2C2 */
/* MMC Configs */
#define CONFIG_FSL_ESDHC
diff --git a/include/configs/mx53evk.h b/include/configs/mx53evk.h
index d39ce7b..2beb433 100644
--- a/include/configs/mx53evk.
Re: [U-Boot] [PATCH v1 2/2] ti814x_evm: enable support for NAND
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/16/2013 05:51 AM, Gupta, Pekon wrote: >> On Tue, Aug 06, 2013 at 01:45:08PM +0530, Pekon Gupta wrote: >> >>> ti814x_evm has on-board socket for using Micron (MT29Fxx) family of >>> NAND devices to GPMC interface. This patch >>> - adds NAND related pin-mux configuration for same >>> - adds #defines for NAND partitions to TI814x configs >>> - enables support for NAND in TI814x configs > [snip] >> >>> @@ -186,6 +193,14 @@ >>> #define CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS 0x200 /* 256 KB */ >>> #define CONFIG_SYS_MMC_SD_FAT_BOOT_PARTITION1 >>> #define CONFIG_SPL_FAT_LOAD_PAYLOAD_NAME"u-boot.img" >>> + >>> +#ifdef CONFIG_SPL_OS_BOOT >>> +/* nand */ >>> +#define CONFIG_CMD_SPL_NAND_OFS0x00 /* >> end of u-boot */ >>> +#define CONFIG_SYS_NAND_SPL_KERNEL_OFFS0x28 >>> +#define CONFIG_CMD_SPL_WRITE_SIZE 0x1000 >>> +#endif >> >> Since you aren't adding the SD/MMC defines as well, nor setting >> SPL_OS_BOOT, lets drop these. >> > Sorry but dint get your feedback. > Following are used in SPL boot for loading env and kernel in falcon mode. > Referring: $UBOOT/common/spl/spl_nand.c > - CONFIG_SYS_NAND_SPL_KERNEL_OFFS > - CONFIG_CMD_SPL_WRITE_SIZE > - CONFIG_CMD_SPL_NAND_OFS > May be I put them in wrong place in include/configs/ti814x.h but these > are required for NAND SPL boot. Please confirm ? They are required for falcon mode yes, but only for falcon mode. And you don't set CONFIG_SPL_OS_BOOT to turn it on :) >>> @@ -242,5 +283,32 @@ >>> #define CONFIG_PHY_ADDR1 >>> #define CONFIG_PHY_ET1011C >>> #define CONFIG_PHY_ET1011C_TX_CLK_FIX >>> +#define CONFIG_NAND >>> +/* NAND support */ >>> +#ifdef CONFIG_NAND >>> +#define CONFIG_MTD_NAND_OMAP_BCH >>> +#define CONFIG_CMD_NAND >>> +#define CONFIG_CMD_MTDPARTS >>> +#define MTDIDS_DEFAULT "nand0=omap2-nand.0" >>> +#define MTDPARTS_DEFAULT "mtdparts=omap2- >> nand.0:128k(SPL)," \ >>> + "128k(u-boot-spl)," \ >>> + "2M(u-boot-main)," \ >>> + "128k(u-boot-env),4M(kernel),- >> (rootfs)" >> >> Lets get the partition tables right, we've still got 4 locations where >> ROM checks for something, so lets use those for SPL, then U-Boot, then >> U-Boot Env (redundant as well, please), and a block saved off for device >> tree/SPL OS "args" support, then kernel, rootfs. >> > I think TI814x ROM use different NAND layout than AM33xx devices. > I used following NAND layout given in link below as reference: > http://processors.wiki.ti.com/index.php/TI81XX_PSP_UBOOT_User_Guide#EVM_Switch_Settings > These devices belong to omap3 family, but now are merged with am33xx. Yeah. OMAP3 and AM33xx (and am43xx) share the same redundancy locations. The PSP layout here is sub-optimal is all. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSOz3pAAoJENk4IS6UOR1W5HoP/j+oIaehk8WgJ0NJUQhg2u5Q TSCiITuEhr8pmGXjnrxYhsHloq2icK4iCdZ45tLNQbDkmFZne7q+5uChOHSZZiwI DGGundQKkf84ECUq2jGXMtIVKQr0Ba8yb25l3rTqy+hfaqbfcg8ZNXxCQ4wKkCqj 4Z8n0gJodzxncPG48gCW1kbzyqg2ZnEwqgLuDuqu6DAhYOEu/lpouakGVRLOpe9r mRdSfu+edUf44zbQ6PEmHD67u1jCNwvc7RQ3Gk9cHM9Ma+9OsN8LULD5FvRovFmO KYYDW/v2tC23LBAjzMnfBzCMpo7Wd6FJVT7JMkT3SKWVdDkDRIG+PDUcZoMS0XcE UMbMnf2VHjFs9ccAL0dKZs4DrR0ECzoubCK+KdtecMFplOo/JDD03O6uMTMv+t32 uwa9UcJYK3w9pPVnng/zAvKTU4lmMkIh2sIM9kquJwoT2aJ3NFa0jjHZLkDNw7BD rie3ZQ5kH91ZMdvDuExkNnSt0pDuM95/ro4OeakRuWdKCure9Kszd+Nattrnc6wU 5gmWQ1rBELgg1ATSmWJEnyo7cORnCKSztyUZG/GTxlkKE+ScU/7wsm/ClAtDN7Of NZwDowfdU5TFdU1vFSk9aP2ShSldzG51GUm4IcwmXP98R0DDtVMiTC+CMxpgLRDh dmTwOEoBt8Vr4w7lPgDi =IPQo -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] ARM: make reserving the gd register a make variable
Hello Albert, On 09/19/2013 08:57 AM, Albert ARIBAUD wrote: On Sat, 17 Aug 2013 15:55:16 +0200, Jeroen Hofstee wrote: On 08/14/2013 08:25 PM, Jeroen Hofstee wrote: diff --git a/arch/arm/config.mk b/arch/arm/config.mk index 540a119..5e382ab 100644 --- a/arch/arm/config.mk +++ b/arch/arm/config.mk @@ -98,3 +98,5 @@ endif ifneq ($(CONFIG_SPL_BUILD),y) ALL-y+= checkarmreloc endif + +OPTION_FIXED_GD=$(call cc-option, -ffixed-r8) I am leaking some debug code here, this can simply be an assignment by value instead of a cc-option check. Does this mean you'll repost a version of this patch? yup, you get a v3. I intend to rebase on http://patchwork.ozlabs.org/patch/273377/ as well. Regards, Jeroen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] FIT: delete unnecessary casts
On 09/19/2013 05:10 AM, Masahiro Yamada wrote:
Becuase fdt_check_header function takes (const void *)
type argument, the argument should be passed to it
without being casted to (char *).
Signed-off-by: Masahiro Yamada
---
Changes for v2:
- fix commit log (purely cosmetic)
(s/img_addr/the argument/)
common/image-fdt.c | 2 +-
common/image-fit.c | 2 +-
common/image.c | 6 +-
tools/fit_image.c | 2 +-
4 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/common/image-fdt.c b/common/image-fdt.c
index 2e22cca..6f9ce7d 100644
--- a/common/image-fdt.c
+++ b/common/image-fdt.c
@@ -55,7 +55,7 @@ static const image_header_t *image_get_fdt(ulong fdt_addr)
fdt_error("uImage is compressed");
return NULL;
}
- if (fdt_check_header((char *)image_get_data(fdt_hdr)) != 0) {
+ if (fdt_check_header((void *)image_get_data(fdt_hdr)) != 0) {
fdt_error("uImage data is not a fdt");
return NULL;
}
Not that I care, this is fine with me. Was just
wondering if this cast is needed at all. AFAIK
it is a cpp thing (and MSVC?) to require it.
Regards,
Jeroen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] gpmi-nand driver and jffs2 support
Dear Hector Palacios, > On 09/19/2013 06:07 PM, Marek Vasut wrote: > > Dear Huang Shijie, > > > > Sorry, I think I got lost in the discussion. I will pull out. > > > > btw Hector, I managed to verify JFFS2 mounting doesn't work on 3.10 , now > > I'm trying to backport patches from -next and apply the GPMI NAND > > patchset, without much luck yet. > > Oops, sorry, did you mean you were trying to backport them into U-Boot? > Then please disregards my previous message. After applying the batch of patches, this is what I get. Interestingly enough, this JFFS2 was written from FSL 2.6.35 kernel. [ 24.118091] jffs2: mtd->read(0x100 bytes from 0x0) returned ECC error [ 24.164458] jffs2: mtd->read(0x1fa34 bytes from 0x5cc) returned ECC error [ 24.171377] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x05cc: 0x7953 i nstead [ 24.180969] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x05d0: 0xe837 i nstead [ 24.190675] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x05d8: 0x85ff i nstead [ 24.200274] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x05dc: 0xcde0 i nstead [ 24.209853] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x05e0: 0x7000 i nstead [ 24.219428] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x05e4: 0x020f i nstead [ 24.229000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x05e8: 0x0200 i nstead [ 24.238570] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x05ec: 0x2400 i nstead [ 24.248142] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x05f4: 0xa400 i nstead [ 24.257645] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0608: 0xacc8 i nstead [ 24.267191] jffs2: Further such events for this erase block will not be printed [ 24.275419] jffs2: jffs2_scan_inode_node(): CRC failed on node at 0x21c8: Read 0x, cal culated 0xd5be0e0f [ 24.287221] jffs2: jffs2_scan_inode_node(): CRC failed on node at 0x49d4: Read 0xd1f0, cal culated 0x34cb9a56 [ 24.300900] jffs2: jffs2_scan_inode_node(): CRC failed on node at 0xb9c0: Read 0x7fd74190, cal culated 0xfdbc37a5 [ 24.312171] jffs2: jffs2_scan_inode_node(): CRC failed on node at 0xd1f4: Read 0x1660, cal culated 0x00cb3014 [ 24.326509] jffs2: jffs2_scan_inode_node(): CRC failed on node at 0x000161d4: Read 0x9a50, cal culated 0xcd68c7e3 [ 24.338761] jffs2: jffs2_scan_inode_node(): CRC failed on node at 0x0001a1e4: Read 0x1450, cal culated 0xa3e78a6c [ 24.352739] jffs2: mtd->read(0xc28 bytes from 0x1f3d8) returned ECC error [ 24.359661] jffs2: Empty flash at 0x0001f3d4 ends at 0x0001f400 [ 24.366953] jffs2: mtd->read(0xbec bytes from 0x1f414) returned ECC error [ 24.374053] jffs2: Empty flash at 0x0001f410 ends at 0x0001f604 [ 24.381408] jffs2: mtd->read(0x9e8 bytes from 0x1f618) returned ECC error [ 24.388450] jffs2: Empty flash at 0x0001f614 ends at 0x0001fa00 [ 24.395141] jffs2: mtd->read(0x5f4 bytes from 0x1fa0c) returned ECC error [ 24.402059] jffs2: Empty flash at 0x0001fa08 ends at 0x0001fc00 [
Re: [U-Boot] [PATCH v3 02/28] sf: probe: Add new spi_flash_probe support
Hi Jagan,
On Thu, Sep 19, 2013 at 1:06 AM, Jagan Teki wrote:
> On Thu, Sep 19, 2013 at 11:46 AM, Simon Glass wrote:
> > Hi,
> >
> > On Sun, Sep 15, 2013 at 12:15 PM, Jagannadha Sutradharudu Teki <
> > jagannadha.sutradharudu-t...@xilinx.com> wrote:
> >
> >> Added new spi_flash_probe support, currently added N25Q*
> >> flash part attributes support.
> >>
> >> Updated the sector_size attributes as per the flash parts.
> >> Looks fine for with this sector_size for computing the size
> >> of flash.
> >>
> >> Defined CONFIG_SPI_FLASH_LEGACY for old probing style
> >> which is available on spi_flash_probe_legacy.c, this will
> >> removed soon once all flashes are supported in new spi_flash_probe.
> >>
> >> Signed-off-by: Jagannadha Sutradharudu Teki
> >> ---
> >> Changes for v3:
> >> - Fix warning issue.
> >> Changes for v2:
> >> - Removed CONFIG_SPI_FLASH_NEW, add CONFIG_SPI_FLASH_LEGACY
> >> - Enable CONFIG_SPI_FLASH_STMICRO in spi_flash_params table
> >> - Updated few structure members
> >>
> >> drivers/mtd/spi/Makefile | 1 +
> >> drivers/mtd/spi/spi_flash_probe.c| 229
> -
> >> drivers/mtd/spi/spi_flash_probe_legacy.c | 276
> >> +++
> >> 3 files changed, 385 insertions(+), 121 deletions(-)
> >> create mode 100644 drivers/mtd/spi/spi_flash_probe_legacy.c
> >>
> >>
> >> ...
> >
> >
> >> +/*
> >> + * The following table holds all device probe functions
> >> + *
> >> + * shift: number of continuation bytes before the ID
> >> + * idcode: the expected IDCODE or 0xff for non JEDEC devices
> >> + * probe: the function to call
> >> + *
> >> + * Non JEDEC devices should be ordered in the table such that
> >> + * the probe functions with best detection algorithms come first.
> >> + *
> >> + * Several matching entries are permitted, they will be tried
> >> + * in sequence until a probe function returns non NULL.
> >> + *
> >> + * IDCODE_CONT_LEN may be redefined if a device needs to declare a
> >> + * larger "shift" value. IDCODE_PART_LEN generally shouldn't be
> >> + * changed. This is the max number of bytes probe functions may
> >> + * examine when looking up part-specific identification info.
> >> + *
> >> + * Probe functions will be given the idcode buffer starting at their
> >> + * manu id byte (the "idcode" in the table below). In other words,
> >> + * all of the continuation bytes will be skipped (the "shift" below).
> >> + */
> >> +#define IDCODE_CONT_LEN 0
> >> +#define IDCODE_PART_LEN 5
> >> +static const struct {
> >> + const u8 shift;
> >> + const u8 idcode;
> >> + struct spi_flash *(*probe) (struct spi_slave *spi, u8 *idcode);
> >> +} flashes[] = {
> >> + /* Keep it sorted by define name */
> >> +#ifdef CONFIG_SPI_FLASH_ATMEL
> >> + { 0, 0x1f, spi_flash_probe_atmel, },
> >> +#endif
> >> +#ifdef CONFIG_SPI_FLASH_EON
> >> + { 0, 0x1c, spi_flash_probe_eon, },
> >> +#endif
> >> +#ifdef CONFIG_SPI_FLASH_GIGADEVICE
> >> + { 0, 0xc8, spi_flash_probe_gigadevice, },
> >> +#endif
> >> +#ifdef CONFIG_SPI_FLASH_MACRONIX
> >> + { 0, 0xc2, spi_flash_probe_macronix, },
> >> +#endif
> >> +#ifdef CONFIG_SPI_FLASH_SPANSION
> >> + { 0, 0x01, spi_flash_probe_spansion, },
> >> +#endif
> >> +#ifdef CONFIG_SPI_FLASH_SST
> >> + { 0, 0xbf, spi_flash_probe_sst, },
> >> +#endif
> >> +#ifdef CONFIG_SPI_FLASH_STMICRO
> >> + { 0, 0x20, spi_flash_probe_stmicro, },
> >> +#endif
> >> +#ifdef CONFIG_SPI_FLASH_WINBOND
> >> + { 0, 0xef, spi_flash_probe_winbond, },
> >> +#endif
> >> +#ifdef CONFIG_SPI_FRAM_RAMTRON
> >> + { 6, 0xc2, spi_fram_probe_ramtron, },
> >> +# undef IDCODE_CONT_LEN
> >> +# define IDCODE_CONT_LEN 6
> >> +#endif
> >> + /* Keep it sorted by best detection */
> >> +#ifdef CONFIG_SPI_FLASH_STMICRO
> >> + { 0, 0xff, spi_flash_probe_stmicro, },
> >> +#endif
> >> +#ifdef CONFIG_SPI_FRAM_RAMTRON_NON_JEDEC
> >> + { 0, 0xff, spi_fram_probe_ramtron, },
> >> +#endif
> >>
> >
> > Do you think it is worth using a linker list for this?
>
> I didn't understand what do you means by this?
> Can you please elaborate.
>
I mean that you could use the features of linker_lists.h - for example to
define macros to declare each driver, and then have this file look through
the available drivers.
U_BOOT_CMD() does this - see do_help() for how the list is scanned.
It's just an idea, perhaps for the future.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] mx6: compute PLL PFD frequencies rather than using defines
Signed-off-by: Pierre Aubert
CC: Stefano Babic
---
Change for V2: Use the right macros for computing PFD dividers.
arch/arm/cpu/armv7/mx6/clock.c | 56 ++---
arch/arm/include/asm/arch-mx6/crm_regs.h | 11 --
2 files changed, 42 insertions(+), 25 deletions(-)
diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c
index 7a29c9b..d0133e9 100644
--- a/arch/arm/cpu/armv7/mx6/clock.c
+++ b/arch/arm/cpu/armv7/mx6/clock.c
@@ -100,6 +100,32 @@ static u32 decode_pll(enum pll_clocks pll, u32 infreq)
}
/* NOTREACHED */
}
+static u32 mxc_get_pll_pfd(enum pll_clocks pll, int pfd_num)
+{
+ u32 div;
+ u64 freq;
+
+ switch (pll) {
+ case PLL_BUS:
+ if (pfd_num == 3) {
+ /* No PFD3 on PPL2 */
+ return 0;
+ }
+ div = __raw_readl(&imx_ccm->analog_pfd_528);
+ freq = (u64)decode_pll(PLL_BUS, MXC_HCLK);
+ break;
+ case PLL_USBOTG:
+ div = __raw_readl(&imx_ccm->analog_pfd_480);
+ freq = (u64)decode_pll(PLL_USBOTG, MXC_HCLK);
+ break;
+ default:
+ /* No PFD on other PLL */
+ return 0;
+ }
+
+ return (freq * 18) / ((div & ANATOP_PFD_FRAC_MASK(pfd_num)) >>
+ ANATOP_PFD_FRAC_SHIFT(pfd_num));
+}
static u32 get_mcu_main_clk(void)
{
@@ -144,13 +170,14 @@ u32 get_periph_clk(void)
freq = decode_pll(PLL_BUS, MXC_HCLK);
break;
case 1:
- freq = PLL2_PFD2_FREQ;
+ freq = mxc_get_pll_pfd(PLL_BUS, 2);
break;
case 2:
- freq = PLL2_PFD0_FREQ;
+ freq = mxc_get_pll_pfd(PLL_BUS, 0);
break;
case 3:
- freq = PLL2_PFD2_DIV_FREQ;
+ /* static / 2 divider */
+ freq = mxc_get_pll_pfd(PLL_BUS, 2) / 2;
break;
default:
break;
@@ -184,7 +211,7 @@ static u32 get_ipg_per_clk(void)
static u32 get_uart_clk(void)
{
u32 reg, uart_podf;
- u32 freq = PLL3_80M;
+ u32 freq = decode_pll(PLL_USBOTG, MXC_HCLK) / 6; /* static divider */
reg = __raw_readl(&imx_ccm->cscdr1);
#ifdef CONFIG_MX6SL
if (reg & MXC_CCM_CSCDR1_UART_CLK_SEL)
@@ -204,7 +231,7 @@ static u32 get_cspi_clk(void)
reg &= MXC_CCM_CSCDR2_ECSPI_CLK_PODF_MASK;
cspi_podf = reg >> MXC_CCM_CSCDR2_ECSPI_CLK_PODF_OFFSET;
- return PLL3_60M / (cspi_podf + 1);
+ return decode_pll(PLL_USBOTG, MXC_HCLK) / (8 * (cspi_podf + 1));
}
static u32 get_axi_clk(void)
@@ -217,9 +244,9 @@ static u32 get_axi_clk(void)
if (cbcdr & MXC_CCM_CBCDR_AXI_SEL) {
if (cbcdr & MXC_CCM_CBCDR_AXI_ALT_SEL)
- root_freq = PLL2_PFD2_FREQ;
+ root_freq = mxc_get_pll_pfd(PLL_BUS, 2);
else
- root_freq = PLL3_PFD1_FREQ;
+ root_freq = mxc_get_pll_pfd(PLL_USBOTG, 1);
} else
root_freq = get_periph_clk();
@@ -244,10 +271,10 @@ static u32 get_emi_slow_clk(void)
root_freq = decode_pll(PLL_USBOTG, MXC_HCLK);
break;
case 2:
- root_freq = PLL2_PFD2_FREQ;
+ root_freq = mxc_get_pll_pfd(PLL_BUS, 2);
break;
case 3:
- root_freq = PLL2_PFD0_FREQ;
+ root_freq = mxc_get_pll_pfd(PLL_BUS, 0);
break;
}
@@ -270,13 +297,14 @@ static u32 get_mmdc_ch0_clk(void)
freq = decode_pll(PLL_BUS, MXC_HCLK);
break;
case 1:
- freq = PLL2_PFD2_FREQ;
+ freq = mxc_get_pll_pfd(PLL_BUS, 2);
break;
case 2:
- freq = PLL2_PFD0_FREQ;
+ freq = mxc_get_pll_pfd(PLL_BUS, 0);
break;
case 3:
- freq = PLL2_PFD2_DIV_FREQ;
+ /* static / 2 divider */
+ freq = mxc_get_pll_pfd(PLL_BUS, 2) / 2;
}
return freq / (podf + 1);
@@ -329,9 +357,9 @@ static u32 get_usdhc_clk(u32 port)
}
if (clk_sel)
- root_freq = PLL2_PFD0_FREQ;
+ root_freq = mxc_get_pll_pfd(PLL_BUS, 0);
else
- root_freq = PLL2_PFD2_FREQ;
+ root_freq = mxc_get_pll_pfd(PLL_BUS, 2);
return root_freq / (usdhc_podf + 1);
}
diff --git a/arch/arm/include/asm/arch-mx6/crm_regs.h
b/arch/arm/include/asm/arch-mx6/crm_regs.h
index 5e6c4da..64f36f9 100644
--- a/arch/arm/include/asm/arch-mx6/crm_regs.h
+++ b/arch/arm/include/asm/arch-mx6/crm_regs.h
@@ -891,15 +891,
Re: [U-Boot] Annoying make debug messages at v2013.10-rc3
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/19/2013 02:39 AM, Albert ARIBAUD wrote:
> Hi Masahiro,
>
> On Wed, 18 Sep 2013 13:00:18 +0900, Masahiro Yamada
> wrote:
>
>> Hello Albert.
>>
>>
>> Commit 27af930e modified top Makefile as follows:
>>
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -838,7 +838,7 @@ unconfig:
>>
>> sinclude $(obj).boards.depend
>> $(obj).boards.depend: boards.cfg
>> - @awk '(NF && $$1 !~ /^#/) { print $$1 ": " $$1 "_config;
>> $$(MAKE)" }' $< > $@
>> + @awk '(NF && $$1 !~ /^#/) { print $$7 ": " $$7 "_config;
>> $$(MAKE) -d" }' $< > $@
>>
>> #
>> # Functions to generate common board directory names
>>
>>
>> I thought adding -d option is not what you intended.
>>
>> So, I posted a patch "[U-Boot] Makefile: Do not show make debug messages"
>> to delete -d option again.
>> Does my patch seem to be OK?
>
> Yes. BTW, you do not need to double patches with explanatory mails.
> Any explanations that you want to add but not be put in the commit,
> just put them below the commit message delimiter, the "---" line.
>
> Tom: do you want to pick this and Axel Lin's bang and Roger Meier's
> checkpatch fixes, or do I pick them in u-boot-arm?
Please grab them for u-boot-arm/master, thanks
- --
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJSOx/5AAoJENk4IS6UOR1WP4kQAKbQseppz334GdoLL3DyUnf9
trtAS8HNPOFp0FmMP6I9dbVyyjNNoZR7JXt/i7D/UQrT5D3nJpGwNEaxEj8Prbek
07lkstmasWoVP+qS7S7Cty1lbuyvbopmDQIEvu8RY5qLBowOlxT5ez/P1OIQGWF3
sYNU3bf5oqEdu+Sgk7DFkAsmQb3r5EZIysNkUwCzDtrxz1b0vMOhka7cSVfq8E9n
HoUzqpiILMNXyRCvvCdRzOD04JlTK9Mt3tb9x2N9x8RRIXF3VYrFglbjp4Fq4vev
jaBdSxYFEhhf1mxmGLg1et7PR6YkhJ4KQ4cekCpA86E26juL0A0J40Y9zR/jo0rG
9A3d7bbKyO4SIqEJGe1Dbo6U6aqZ34Bjc87OLYcRjpF42sqhQtIxaoq9+ecYLIya
5HhmF6/R0THLb2r7cJ22hzS7fB7lJNbqoZGB+YL7Do46vAD0Yz22uLqepbym5T3F
2OKqbN7kMa73gbWZIF1YsMRLNnNhHFoncKV4kq92/sELxdnv8yQmiDu+Rai4YMrS
4uCDGnVmvRodeTaZOZxmyAjXWoSSNRbsIYUivdPIl2iHDavCbri34x1hX0gnSWN+
PtqnUGmLKPHAEik7b8Bz1AjpITsi/wOsQsFx/7DOOkBjW6tPe8mx0Sn4k82YC+1o
toOn7+rCNGob/yk5bj0Z
=+6Ql
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 6/8] ARM: add SMP support for non-secure switch
Currently the non-secure switch is only done for the boot processor.
To enable full SMP support, we have to switch all secondary cores
into non-secure state also.
So we add an entry point for secondary CPUs coming out of low-power
state and make sure we put them into WFI again after having switched
to non-secure state.
For this we acknowledge and EOI the wake-up IPI, then go into WFI.
Once being kicked out of it later, we sanity check that the start
address has actually been changed (since another attempt to switch
to non-secure would block the core) and jump to the new address.
The actual CPU kick is done by sending an inter-processor interrupt
via the GIC to all CPU interfaces except the requesting processor.
The secondary cores will then setup their respective GIC CPU
interface.
While this approach is pretty universal across several ARMv7 boards,
we make this function weak in case someone needs to tweak this for
a specific board.
The way of setting the secondary's start address is board specific,
but mostly different only in the actual SMP pen address, so we also
provide a weak default implementation and just depend on the proper
address to be set in the config file.
Signed-off-by: Andre Przywara
---
arch/arm/cpu/armv7/nonsec_virt.S | 35 +++
arch/arm/cpu/armv7/virt-v7.c | 16 +++-
arch/arm/include/asm/armv7.h | 1 +
arch/arm/include/asm/gic.h | 2 ++
include/common.h | 2 ++
5 files changed, 55 insertions(+), 1 deletion(-)
Changes:
v3..v4: require smp_waitloop to be board specific, allow board
specific SMP kicking routine
v4..v5: provide weak default implementation of smp_waitloop
diff --git a/arch/arm/cpu/armv7/nonsec_virt.S b/arch/arm/cpu/armv7/nonsec_virt.S
index 3dd60b7..cbee8f7 100644
--- a/arch/arm/cpu/armv7/nonsec_virt.S
+++ b/arch/arm/cpu/armv7/nonsec_virt.S
@@ -58,6 +58,28 @@ _secure_monitor:
movspc, lr @ return to non-secure SVC
/*
+ * Secondary CPUs start here and call the code for the core specific parts
+ * of the non-secure and HYP mode transition. The GIC distributor specific
+ * code has already been executed by a C function before.
+ * Then they go back to wfi and wait to be woken up by the kernel again.
+ */
+ENTRY(_smp_pen)
+ mrs r0, cpsr
+ orr r0, r0, #0xc0
+ msr cpsr, r0@ disable interrupts
+ ldr r1, =_start
+ mcr p15, 0, r1, c12, c0, 0 @ set VBAR
+
+ bl _nonsec_init
+
+ ldr r1, [r0, #GICC_IAR] @ acknowledge IPI
+ str r1, [r0, #GICC_EOIR]@ signal end of interrupt
+
+ adr r0, _smp_pen@ do not use this address again
+ b smp_waitloop@ wait for IPIs, board specific
+ENDPROC(_smp_pen)
+
+/*
* Switch a core to non-secure state.
*
* 1. initialize the GIC per-core interface
@@ -138,3 +160,16 @@ ENTRY(_nonsec_init)
bx lr
ENDPROC(_nonsec_init)
+
+#ifdef CONFIG_SMP_PEN_ADDR
+/* void __weak smp_waitloop(unsigned previous_address); */
+ENTRY(smp_waitloop)
+ wfi
+ ldr r1, =CONFIG_SMP_PEN_ADDR@ load start address
+ ldr r1, [r1]
+ cmp r0, r1 @ make sure we dont execute this code
+ beq smp_waitloop@ again (due to a spurious wakeup)
+ mov pc, r1
+ENDPROC(smp_waitloop)
+.weak smp_waitloop
+#endif
diff --git a/arch/arm/cpu/armv7/virt-v7.c b/arch/arm/cpu/armv7/virt-v7.c
index 068ac85..a0b8742 100644
--- a/arch/arm/cpu/armv7/virt-v7.c
+++ b/arch/arm/cpu/armv7/virt-v7.c
@@ -79,6 +79,17 @@ static unsigned long get_gicd_base_address(void)
#endif
}
+static void kick_secondary_cpus_gic(unsigned long gicdaddr)
+{
+ /* kick all CPUs (except this one) by writing to GICD_SGIR */
+ writel(1U << 24, gicdaddr + GICD_SGIR);
+}
+
+void __weak smp_kick_all_cpus(void)
+{
+ kick_secondary_cpus_gic(gic_dist_addr);
+}
+
int armv7_switch_nonsec(void)
{
unsigned int reg;
@@ -115,7 +126,10 @@ int armv7_switch_nonsec(void)
for (i = 1; i <= itlinesnr; i++)
writel((unsigned)-1, gic_dist_addr + GICD_IGROUPRn + 4 * i);
- /* call the non-sec switching code on this CPU */
+ smp_set_core_boot_addr((unsigned long)_smp_pen, -1);
+ smp_kick_all_cpus();
+
+ /* call the non-sec switching code on this CPU also */
_nonsec_init();
return 0;
diff --git a/arch/arm/include/asm/armv7.h b/arch/arm/include/asm/armv7.h
index b352d43..2efd4bc 100644
--- a/arch/arm/include/asm/armv7.h
+++ b/arch/arm/include/asm/armv7.h
@@ -82,6 +82,7 @@ int armv7_switch_nonsec(void);
/* defined in assembly file */
unsigned int _nonsec_init(void);
+void _smp_pen(void);
#endif /* CONFIG_ARMV7_NONSEC */
#endif /* ! __ASSEMBLY__ */
diff --git a/arch/arm/include/asm/gic.h b/arch/arm/include/asm/gic.h
index c2b1e28..a0891cc 1
[U-Boot] [PATCH v5 7/8] ARM: extend non-secure switch to also go into HYP mode
For the KVM and XEN hypervisors to be usable, we need to enter the kernel in HYP mode. Now that we already are in non-secure state, HYP mode switching is within short reach. While doing the non-secure switch, we have to enable the HVC instruction and setup the HYP mode HVBAR (while still secure). The actual switch is done by dropping back from a HYP mode handler without actually leaving HYP mode, so we introduce a new handler routine in our new secure exception vector table. In the assembly switching routine we save and restore the banked LR and SP registers around the hypercall to do the actual HYP mode switch. The C routine first checks whether we are in HYP mode already and also whether the virtualization extensions are available. It also checks whether the HYP mode switch was finally successful. The bootm command part only calls the new function after the non-secure switch. Signed-off-by: Andre Przywara --- arch/arm/cpu/armv7/Makefile | 2 +- arch/arm/cpu/armv7/nonsec_virt.S | 43 +++- arch/arm/cpu/armv7/virt-v7.c | 37 ++ arch/arm/include/asm/armv7.h | 6 -- arch/arm/lib/bootm.c | 7 ++- 5 files changed, 86 insertions(+), 9 deletions(-) Changes: v3..v4: w/s fixes, embed error output v4..v5: none diff --git a/arch/arm/cpu/armv7/Makefile b/arch/arm/cpu/armv7/Makefile index 024c28b..ee4b021 100644 --- a/arch/arm/cpu/armv7/Makefile +++ b/arch/arm/cpu/armv7/Makefile @@ -20,7 +20,7 @@ ifneq ($(CONFIG_AM43XX)$(CONFIG_AM33XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CON SOBJS += lowlevel_init.o endif -ifneq ($(CONFIG_ARMV7_NONSEC),) +ifneq ($(CONFIG_ARMV7_NONSEC)$(CONFIG_ARMV7_VIRT),) SOBJS += nonsec_virt.o COBJS += virt-v7.o endif diff --git a/arch/arm/cpu/armv7/nonsec_virt.S b/arch/arm/cpu/armv7/nonsec_virt.S index cbee8f7..358348f 100644 --- a/arch/arm/cpu/armv7/nonsec_virt.S +++ b/arch/arm/cpu/armv7/nonsec_virt.S @@ -1,5 +1,5 @@ /* - * code for switching cores into non-secure state + * code for switching cores into non-secure state and into HYP mode * * Copyright (c) 2013 Andre Przywara * @@ -28,15 +28,16 @@ #include .arch_extension sec +.arch_extension virt -/* the vector table for secure state */ +/* the vector table for secure state and HYP mode */ _monitor_vectors: .word 0 /* reset */ .word 0 /* undef */ adr pc, _secure_monitor .word 0 .word 0 - .word 0 + adr pc, _hyp_trap .word 0 .word 0 @@ -53,10 +54,27 @@ _secure_monitor: bic r1, r1, #0x4e @ clear IRQ, FIQ, EA, nET bits orr r1, r1, #0x31 @ enable NS, AW, FW bits +#ifdef CONFIG_ARMV7_VIRT + mrc p15, 0, r0, c0, c1, 1 @ read ID_PFR1 + and r0, r0, #CPUID_ARM_VIRT_MASK@ mask virtualization bits + cmp r0, #(1 << CPUID_ARM_VIRT_SHIFT) + orreq r1, r1, #0x100 @ allow HVC instruction +#endif + mcr p15, 0, r1, c1, c1, 0 @ write SCR (with NS bit set) +#ifdef CONFIG_ARMV7_VIRT + mrceq p15, 0, r0, c12, c0, 1 @ get MVBAR value + mcreq p15, 4, r0, c12, c0, 0 @ write HVBAR +#endif + movspc, lr @ return to non-secure SVC +_hyp_trap: + mrs lr, elr_hyp @ for older asm: .byte 0x00, 0xe3, 0x0e, 0xe1 + mov pc, lr @ do no switch modes, but + @ return to caller + /* * Secondary CPUs start here and call the code for the core specific parts * of the non-secure and HYP mode transition. The GIC distributor specific @@ -71,9 +89,13 @@ ENTRY(_smp_pen) mcr p15, 0, r1, c12, c0, 0 @ set VBAR bl _nonsec_init + mov r12, r0 @ save GICC address +#ifdef CONFIG_ARMV7_VIRT + bl _switch_to_hyp +#endif - ldr r1, [r0, #GICC_IAR] @ acknowledge IPI - str r1, [r0, #GICC_EOIR]@ signal end of interrupt + ldr r1, [r12, #GICC_IAR]@ acknowledge IPI + str r1, [r12, #GICC_EOIR] @ signal end of interrupt adr r0, _smp_pen@ do not use this address again b smp_waitloop@ wait for IPIs, board specific @@ -173,3 +195,14 @@ ENTRY(smp_waitloop) ENDPROC(smp_waitloop) .weak smp_waitloop #endif + +ENTRY(_switch_to_hyp) + mov r0, lr + mov r1, sp @ save SVC copy of LR and SP + isb + hvc #0 @ for older asm: .byte 0x70, 0x00, 0x40, 0xe1 + mov sp, r1 + mov lr, r0 @ restore SVC copy of LR and SP + + bx lr +ENDPROC(_switch_to_hyp) diff --git a/arch/arm/cpu/armv7/virt-v7.c b/arch/arm/cpu/armv7/virt-v7.c index a0b8742..6de7fe7 100644
Re: [U-Boot] gpmi-nand driver and jffs2 support
On 09/19/2013 06:07 PM, Marek Vasut wrote: Dear Huang Shijie, Sorry, I think I got lost in the discussion. I will pull out. btw Hector, I managed to verify JFFS2 mounting doesn't work on 3.10 , now I'm trying to backport patches from -next and apply the GPMI NAND patchset, without much luck yet. Oops, sorry, did you mean you were trying to backport them into U-Boot? Then please disregards my previous message. Best regards, -- Hector Palacios ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 3/8] ARM: add assembly routine to switch to non-secure state
While actually switching to non-secure state is one thing, another part of this process is to make sure that we still have full access to the interrupt controller (GIC). The GIC is fully aware of secure vs. non-secure state, some registers are banked, others may be configured to be accessible from secure state only. To be as generic as possible, we get the GIC memory mapped address based on the PERIPHBASE value in the CBAR register. Since this register is not architecturally defined, we check the MIDR before to be from an A15 or A7. For CPUs not having the CBAR or boards with wrong information herein we allow providing the base address as a configuration variable. Now that we know the GIC address, we: a) allow private interrupts to be delivered to the core (GICD_IGROUPR0 = 0x) b) enable the CPU interface (GICC_CTLR[0] = 1) c) set the priority filter to allow non-secure interrupts (GICC_PMR = 0xFF) Also we allow access to all coprocessor interfaces from non-secure state by writing the appropriate bits in the NSACR register. The generic timer base frequency register is only accessible from secure state, so we have to program it now. Actually this should be done from primary firmware before, but some boards seems to omit this, so if needed we do this here with a board specific value. The Versatile Express board does not need this, so we remove the frequency from the configuration file here. After having switched to non-secure state, we also enable the non-secure GIC CPU interface, since this register is banked. Since we need to call this routine also directly from the smp_pen later (where we don't have any stack), we can only use caller saved registers r0-r3 and r12 to not mess with the compiler. Signed-off-by: Andre Przywara --- arch/arm/cpu/armv7/nonsec_virt.S| 86 + arch/arm/include/asm/armv7.h| 21 + arch/arm/include/asm/gic.h | 17 include/configs/vexpress_ca15_tc2.h | 2 - 4 files changed, 124 insertions(+), 2 deletions(-) create mode 100644 arch/arm/include/asm/gic.h Changes: v3..v4: clear reserved bits in CBAR v4..v5: none diff --git a/arch/arm/cpu/armv7/nonsec_virt.S b/arch/arm/cpu/armv7/nonsec_virt.S index c21bca3..3dd60b7 100644 --- a/arch/arm/cpu/armv7/nonsec_virt.S +++ b/arch/arm/cpu/armv7/nonsec_virt.S @@ -23,6 +23,11 @@ */ #include +#include +#include +#include + +.arch_extension sec /* the vector table for secure state */ _monitor_vectors: @@ -52,3 +57,84 @@ _secure_monitor: movspc, lr @ return to non-secure SVC +/* + * Switch a core to non-secure state. + * + * 1. initialize the GIC per-core interface + * 2. allow coprocessor access in non-secure modes + * 3. switch the cpu mode (by calling "smc #0") + * + * Called from smp_pen by secondary cores and directly by the BSP. + * Do not assume that the stack is available and only use registers + * r0-r3 and r12. + * + * PERIPHBASE is used to get the GIC address. This could be 40 bits long, + * though, but we check this in C before calling this function. + */ +ENTRY(_nonsec_init) +#ifdef CONFIG_ARM_GIC_BASE_ADDRESS + ldr r2, =CONFIG_ARM_GIC_BASE_ADDRESS +#else + mrc p15, 4, r2, c15, c0, 0 @ read CBAR + bfc r2, #0, #15 @ clear reserved bits +#endif + add r3, r2, #GIC_DIST_OFFSET@ GIC dist i/f offset + mvn r1, #0 @ all bits to 1 + str r1, [r3, #GICD_IGROUPRn]@ allow private interrupts + + mrc p15, 0, r0, c0, c0, 0 @ read MIDR + ldr r1, =MIDR_PRIMARY_PART_MASK + and r0, r0, r1 @ mask out variant and revision + + ldr r1, =MIDR_CORTEX_A7_R0P0 & MIDR_PRIMARY_PART_MASK + cmp r0, r1 @ check for Cortex-A7 + + ldr r1, =MIDR_CORTEX_A15_R0P0 & MIDR_PRIMARY_PART_MASK + cmpne r0, r1 @ check for Cortex-A15 + + movne r1, #GIC_CPU_OFFSET_A9 @ GIC CPU offset for A9 + moveq r1, #GIC_CPU_OFFSET_A15 @ GIC CPU offset for A15/A7 + add r3, r2, r1 @ r3 = GIC CPU i/f addr + + mov r1, #1 @ set GICC_CTLR[enable] + str r1, [r3, #GICC_CTLR]@ and clear all other bits + mov r1, #0xff + str r1, [r3, #GICC_PMR] @ set priority mask register + + movwr1, #0x3fff + movtr1, #0x0006 + mcr p15, 0, r1, c1, c1, 2 @ NSACR = all copros to non-sec + +/* The CNTFRQ register of the generic timer needs to be + * programmed in secure state. Some primary bootloaders / firmware + * omit this, so if the frequency is provided in the configuration, + * we do this here instead. + * But first check if we have the generic timer. + */ +#ifdef CONFIG_SYS_CLK_FREQ + mrc p15, 0, r0,
[U-Boot] [PATCH v5 8/8] ARM: VExpress: enable ARMv7 virt support for VExpress A15
To enable hypervisors utilizing the ARMv7 virtualization extension
on the Versatile Express board with the A15 core tile, we add the
required configuration variable.
Also we define the board specific smp_set_cpu_boot_addr() function to
set the start address for secondary cores in the VExpress specific
manner.
There is no need to provide a custom smp_waitloop() function here.
This also serves as an example for what to do when adding support for
new boards.
Signed-off-by: Andre Przywara
---
board/armltd/vexpress/vexpress_common.c | 15 +++
include/configs/vexpress_ca15_tc2.h | 5 +
2 files changed, 20 insertions(+)
Changes:
v3..v4: add VExpress' smp_set_core_boot_addr() and smp_waitloop()
v4..v5: remove VExpress specific smp_waitloop() in favor of
the generic implementation
diff --git a/board/armltd/vexpress/vexpress_common.c
b/board/armltd/vexpress/vexpress_common.c
index 4c7a7f4..56febd9 100644
--- a/board/armltd/vexpress/vexpress_common.c
+++ b/board/armltd/vexpress/vexpress_common.c
@@ -256,3 +256,18 @@ ulong get_tbclk(void)
{
return (ulong)CONFIG_SYS_HZ;
}
+
+#if defined(CONFIG_ARMV7_NONSEC) || defined(CONFIG_ARMV7_VIRT)
+/* Setting the address at which secondary cores start from.
+ * Versatile Express uses one address for all cores, so ignore corenr
+ */
+void smp_set_core_boot_addr(unsigned long addr, int corenr)
+{
+ /* The SYSFLAGS register on VExpress needs to be cleared first
+* by writing to the next address, since any writes to the address
+* at offset 0 will only be ORed in
+*/
+ writel(~0, CONFIG_SYSFLAGS_ADDR + 4);
+ writel(addr, CONFIG_SYSFLAGS_ADDR);
+}
+#endif
diff --git a/include/configs/vexpress_ca15_tc2.h
b/include/configs/vexpress_ca15_tc2.h
index 89ce1c7..0806034 100644
--- a/include/configs/vexpress_ca15_tc2.h
+++ b/include/configs/vexpress_ca15_tc2.h
@@ -15,4 +15,9 @@
#include "vexpress_common.h"
#define CONFIG_BOOTP_VCI_STRING "U-boot.armv7.vexpress_ca15x2_tc2"
+#define CONFIG_SYSFLAGS_ADDR 0x1c010030
+#define CONFIG_SMP_PEN_ADDRCONFIG_SYSFLAGS_ADDR
+
+#define CONFIG_ARMV7_VIRT
+
#endif
--
1.7.12.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 4/8] ARM: add C function to switch to non-secure state
The core specific part of the work is done in the assembly routine
in nonsec_virt.S, introduced with the previous patch, but for the full
glory we need to setup the GIC distributor interface once for the
whole system, which is done in C here.
The routine is placed in arch/arm/cpu/armv7 to allow easy access from
other ARMv7 boards.
We check the availability of the security extensions first.
Since we need a safe way to access the GIC, we use the PERIPHBASE
registers on Cortex-A15 and A7 CPUs and do some sanity checks.
Boards not implementing the CBAR can override this value via a
configuration file variable.
Then we actually do the GIC enablement:
a) enable the GIC distributor, both for non-secure and secure state
(GICD_CTLR[1:0] = 11b)
b) allow all interrupts to be handled from non-secure state
(GICD_IGROUPRn = 0x)
The core specific GIC setup is then done in the assembly routine.
Signed-off-by: Andre Przywara
---
arch/arm/cpu/armv7/Makefile | 1 +
arch/arm/cpu/armv7/virt-v7.c | 122 +++
arch/arm/include/asm/armv7.h | 3 ++
3 files changed, 126 insertions(+)
create mode 100644 arch/arm/cpu/armv7/virt-v7.c
Changes:
v3..v4: w/s fixes, change GIC address variable, embed error reporting,
remove bootm part (next patch)
v4..v5: only clear unbanked registers during GIC distributor init
diff --git a/arch/arm/cpu/armv7/Makefile b/arch/arm/cpu/armv7/Makefile
index 3466c7a..024c28b 100644
--- a/arch/arm/cpu/armv7/Makefile
+++ b/arch/arm/cpu/armv7/Makefile
@@ -22,6 +22,7 @@ endif
ifneq ($(CONFIG_ARMV7_NONSEC),)
SOBJS += nonsec_virt.o
+COBJS += virt-v7.o
endif
SRCS := $(START:.o=.S) $(COBJS:.o=.c)
diff --git a/arch/arm/cpu/armv7/virt-v7.c b/arch/arm/cpu/armv7/virt-v7.c
new file mode 100644
index 000..068ac85
--- /dev/null
+++ b/arch/arm/cpu/armv7/virt-v7.c
@@ -0,0 +1,122 @@
+/*
+ * (C) Copyright 2013
+ * Andre Przywara, Linaro
+ *
+ * Routines to transition ARMv7 processors from secure into non-secure state
+ * needed to enable ARMv7 virtualization for current hypervisors
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+#include
+
+unsigned long gic_dist_addr;
+
+static unsigned int read_id_pfr1(void)
+{
+ unsigned int reg;
+
+ asm("mrc p15, 0, %0, c0, c1, 1\n" : "=r"(reg));
+ return reg;
+}
+
+static unsigned long get_gicd_base_address(void)
+{
+#ifdef CONFIG_ARM_GIC_BASE_ADDRESS
+ return CONFIG_ARM_GIC_BASE_ADDRESS + GIC_DIST_OFFSET;
+#else
+ unsigned midr;
+ unsigned periphbase;
+
+ /* check whether we are an Cortex-A15 or A7.
+* The actual HYP switch should work with all CPUs supporting
+* the virtualization extension, but we need the GIC address,
+* which we know only for sure for those two CPUs.
+*/
+ asm("mrc p15, 0, %0, c0, c0, 0\n" : "=r"(midr));
+ switch (midr & MIDR_PRIMARY_PART_MASK) {
+ case MIDR_CORTEX_A9_R0P1:
+ case MIDR_CORTEX_A15_R0P0:
+ case MIDR_CORTEX_A7_R0P0:
+ break;
+ default:
+ printf("nonsec: could not determine GIC address.\n");
+ return -1;
+ }
+
+ /* get the GIC base address from the CBAR register */
+ asm("mrc p15, 4, %0, c15, c0, 0\n" : "=r" (periphbase));
+
+ /* the PERIPHBASE can be mapped above 4 GB (lower 8 bits used to
+* encode this). Bail out here since we cannot access this without
+* enabling paging.
+*/
+ if ((periphbase & 0xff) != 0) {
+ printf("nonsec: PERIPHBASE is above 4 GB, no access.\n");
+ return -1;
+ }
+
+ return (periphbase & CBAR_MASK) + GIC_DIST_OFFSET;
+#endif
+}
+
+int armv7_switch_nonsec(void)
+{
+ unsigned int reg;
+ unsigned itlinesnr, i;
+
+ /* check whether the CPU supports the security extensions */
+ reg = read_id_pfr1();
+ if ((reg & 0xF0) == 0) {
+ printf("nonsec: Security extensions not implemented.\n");
+ return -1;
+ }
+
+ /* the SCR register will be set directly in the monitor mode handler,
+* according to the spec one should not tinker with it in secure
[U-Boot] [PATCH v5 1/8] ARM: prepare armv7.h to be included from assembly source
armv7.h contains some useful constants, but also C prototypes. To include it also in assembly files, protect the non-assembly part appropriately. Signed-off-by: Andre Przywara --- arch/arm/include/asm/armv7.h | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) Changes: v3..v4: none v4..v5: none diff --git a/arch/arm/include/asm/armv7.h b/arch/arm/include/asm/armv7.h index 392d6a2..0f7cbbf 100644 --- a/arch/arm/include/asm/armv7.h +++ b/arch/arm/include/asm/armv7.h @@ -7,7 +7,6 @@ */ #ifndef ARMV7_H #define ARMV7_H -#include /* Cortex-A9 revisions */ #define MIDR_CORTEX_A9_R0P10x410FC091 @@ -41,6 +40,9 @@ #define ARMV7_CLIDR_CTYPE_INSTRUCTION_DATA 3 #define ARMV7_CLIDR_CTYPE_UNIFIED 4 +#ifndef __ASSEMBLY__ +#include + /* * CP15 Barrier instructions * Please note that we have separate barrier instructions in ARMv7 @@ -58,4 +60,6 @@ void v7_outer_cache_inval_all(void); void v7_outer_cache_flush_range(u32 start, u32 end); void v7_outer_cache_inval_range(u32 start, u32 end); +#endif /* ! __ASSEMBLY__ */ + #endif -- 1.7.12.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 5/8] ARM: trigger non-secure state switch during bootm execution
To actually trigger the non-secure switch we just implemented, call
the switching routine from within the bootm command implementation.
This way we automatically enable this feature without further user
intervention.
Signed-off-by: Andre Przywara
---
arch/arm/lib/bootm.c | 13 +
1 file changed, 13 insertions(+)
Changes:
v3..v4: (splitted of from former 4/7 patch)
v4..v5: none
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index eefb456..b3a961a 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -22,6 +22,10 @@
#include
#include
+#ifdef CONFIG_ARMV7_NONSEC
+#include
+#endif
+
DECLARE_GLOBAL_DATA_PTR;
static struct tag *params;
@@ -181,6 +185,14 @@ static void setup_end_tag(bd_t *bd)
__weak void setup_board_tags(struct tag **in_params) {}
+static void do_nonsec_virt_switch(void)
+{
+#if defined(CONFIG_ARMV7_NONSEC) || defined(CONFIG_ARMV7_VIRT)
+ if (armv7_switch_nonsec() == 0)
+ debug("entered non-secure state\n");
+#endif
+}
+
/* Subcommand: PREP */
static void boot_prep_linux(bootm_headers_t *images)
{
@@ -217,6 +229,7 @@ static void boot_prep_linux(bootm_headers_t *images)
printf("FDT and ATAGS support not compiled in - hanging\n");
hang();
}
+ do_nonsec_virt_switch();
}
/* Subcommand: GO */
--
1.7.12.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/12 V3] DWMMC: SMDK5420: Disable SMU for eMMC
Hi Rajeshwari, On Thu, Sep 19, 2013 at 9:42 AM, Rajeshwari Birje < rajeshwari.bi...@gmail.com> wrote: > Hi Simon, > > Thank you for comments. > Will add a check so that it will be executed only for Exynos5420 boards. > Also, I don't think an #ifdef for an SOC is permitted in driver code. Are these registers present in any DWMMC peripheral? I assume that they are a feature of the peripheral and that Samsung has not hacked the peripheral for 5420. If so, then I think it should be a flag passed to add_dwmci() to tell it whether to do this or not. Regards, Simon > > Thanks and Regards, > Rajeshwari. > > > On Thu, Sep 19, 2013 at 11:42 AM, Simon Glass wrote: > > Hi Rajeshwari, > > > > On Wed, Sep 11, 2013 at 4:01 AM, Rajeshwari S Shinde < > > rajeshwar...@samsung.com> wrote: > > > >> SMDK5420 has a new Security Management Unit added > >> for dwmmc driver, hence, configuring the control > >> registers to support booting via eMMC. > >> > >> Signed-off-by: Alim Akhtar > >> Signed-off-by: Rajeshwari Shinde > >> --- > >> Changes in V3: > >> - New patch. > >> drivers/mmc/dw_mmc.c | 7 +++ > >> include/dwmmc.h | 12 > >> 2 files changed, 19 insertions(+) > >> > >> diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c > >> index a82ee17..d763949 100644 > >> --- a/drivers/mmc/dw_mmc.c > >> +++ b/drivers/mmc/dw_mmc.c > >> @@ -300,6 +300,13 @@ static int dwmci_init(struct mmc *mmc) > >> struct dwmci_host *host = (struct dwmci_host *)mmc->priv; > >> u32 fifo_size; > >> > >> + dwmci_writel(host, EMMCP_MPSBEGIN0, 0); > >> + dwmci_writel(host, EMMCP_SEND0, 0); > >> + dwmci_writel(host, EMMCP_CTRL0, > >> + MPSCTRL_SECURE_READ_BIT | MPSCTRL_SECURE_WRITE_BIT | > >> + MPSCTRL_NON_SECURE_READ_BIT | > MPSCTRL_NON_SECURE_WRITE_BIT > >> | > >> + MPSCTRL_VALID); > >> + > >> > > > > Is this safe for all users of this file (Exynos5250, etc. ? > > > > Regards, > > Simon > > > > ___ > > U-Boot mailing list > > U-Boot@lists.denx.de > > http://lists.denx.de/mailman/listinfo/u-boot > > > > > > -- > Regards, > Rajeshwari Shinde > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 2/8] ARM: add secure monitor handler to switch to non-secure state
A prerequisite for using virtualization is to be in HYP mode, which requires the CPU to be in non-secure state first. Add a new file in arch/arm/cpu/armv7 to hold a monitor handler routine which switches the CPU to non-secure state by setting the NS and associated bits. According to the ARM architecture reference manual this should not be done in SVC mode, so we have to setup a SMC handler for this. We create a new vector table to avoid interference with other boards. The MVBAR register will be programmed later just before the smc call. Signed-off-by: Andre Przywara --- arch/arm/cpu/armv7/Makefile | 4 +++ arch/arm/cpu/armv7/nonsec_virt.S | 54 2 files changed, 58 insertions(+) create mode 100644 arch/arm/cpu/armv7/nonsec_virt.S Changes: v3..v4: clarify comments, w/s fixes v4..v5: remove unneeded padding in the exception table diff --git a/arch/arm/cpu/armv7/Makefile b/arch/arm/cpu/armv7/Makefile index b723e22..3466c7a 100644 --- a/arch/arm/cpu/armv7/Makefile +++ b/arch/arm/cpu/armv7/Makefile @@ -20,6 +20,10 @@ ifneq ($(CONFIG_AM43XX)$(CONFIG_AM33XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CON SOBJS += lowlevel_init.o endif +ifneq ($(CONFIG_ARMV7_NONSEC),) +SOBJS += nonsec_virt.o +endif + SRCS := $(START:.o=.S) $(COBJS:.o=.c) OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS)) START := $(addprefix $(obj),$(START)) diff --git a/arch/arm/cpu/armv7/nonsec_virt.S b/arch/arm/cpu/armv7/nonsec_virt.S new file mode 100644 index 000..c21bca3 --- /dev/null +++ b/arch/arm/cpu/armv7/nonsec_virt.S @@ -0,0 +1,54 @@ +/* + * code for switching cores into non-secure state + * + * Copyright (c) 2013 Andre Przywara + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#include + +/* the vector table for secure state */ +_monitor_vectors: + .word 0 /* reset */ + .word 0 /* undef */ + adr pc, _secure_monitor + .word 0 + .word 0 + .word 0 + .word 0 + .word 0 + +/* + * secure monitor handler + * U-boot calls this "software interrupt" in start.S + * This is executed on a "smc" instruction, we use a "smc #0" to switch + * to non-secure state. + * We use only r0 and r1 here, due to constraints in the caller. + */ + .align 5 +_secure_monitor: + mrc p15, 0, r1, c1, c1, 0 @ read SCR + bic r1, r1, #0x4e @ clear IRQ, FIQ, EA, nET bits + orr r1, r1, #0x31 @ enable NS, AW, FW bits + + mcr p15, 0, r1, c1, c1, 0 @ write SCR (with NS bit set) + + movspc, lr @ return to non-secure SVC + -- 1.7.12.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] gpmi-nand driver and jffs2 support
Dear Marek Vasut,
On 09/19/2013 06:07 PM, Marek Vasut wrote:
btw Hector, I managed to verify JFFS2 mounting doesn't work on 3.10 , now I'm
trying to backport patches from -next and apply the GPMI NAND patchset, without
much luck yet.
If it helps, to make it work on v3.10 I had to apply lots of commits (listed in
reverse order, from most recent to oldest):
53a9abf27213154d1ebaa54d111533f1e69d8ef3 mtd: mtd-abi: add a helper to detect the nand
type
44aabd5fe3423f5b2071379bd55e708d523a1b4c mtd: add a helper to detect the nand
type
2a2d49314b6a36eca80947ad021d01f7e6294291 mtd: add MTD_MLCNANDFLASH case for
mtd_type_show()
576c9744f0f62d0b8d207d74b9066f00f4bdd347 jffs2: do not support the MLC nand
654b09629a50fd1680afcce46514e9ffc6723418 mtd: fix the wrong mtd->type for nand
chip
95bc60491c394174cdbd1b24b0940fa61b6f2aec mtd: add more comment for
MTD_NANDFLASH/MTD_MLCNANDFLASH
b9032012d68cf881e48237336e79d783b69f2a1b mtd: gpmi: rewrite the gpmi_ecc_write_oob()
to support the jffs2
2c92e6f5e6a61020443ec3dbb7d51c6a84170f36 mtd: print out the cell information
for nand chip
01e1b2c398952ead5d8b3eb370dc7a31560e9c00 mtd: set the cell information for ONFI
nand
2dcd73d5c96067342fafeb088cc08872f68558d5 mtd: nand: rename the cellinfo to
bits_per_cell
40f5c3f65f9f2151ae5cdd9293af6d62f551d51a mtd: add a new field to mtd_info{}
a0181739d881f3e973ebfbe29769f0d4f08b26a4 mtd: add ECC info for nand_flash_dev{}
247db5b42147d0b764c6096e1b55c7f01439b9a5 mtd: add a helper to get the supported
features for ONFI nand
0db74df18a1dbd9814637ba891cc123f3b7a4bba mtd: add data structures for Extended
Parameter Page
f4ead19a666581c78a7f9d27379e4ee4850d38ae mtd: add datasheet's ECC information to
nand_chip{}
b47e2aa8f044092ea63a2b28d1ead0ff6bc54ac3 mtd: nand: remove NAND_BBT_SCANEMPTY
91eae06eb963ad7f5faf8f585f21d34921cb7830 mtd: nand: hide in-memory BBT implementation
details
4b8c49529b49e84a9472e52ffa2b452b48779563 mtd: nand_base: Only use GET/SET FEATURES
command on chips that support them.
8babb2385cfcd9ee24b62e2dd1577a1e05ef2f1f mtd: nand: fsmc: update of OF support
34b182c94acfc08e851af3500d8f3fa8b1d073e5 mtd: increase max OOB size to 744
b726168414d1ce3cff143e4bdc3f944459894388 mtd: nand: reword nand_chip bad block
interface comments
36b46f044704df158078beaa368284fdc435f34a mtd: mpc5121_nfc: cleanup clock API use
5afbc047077a88c38181b9d4de6bea70a140b5a0 mtd cs553x_nand: use kzalloc() instead
of memset
247f500f0903c084fa04f96e41aed049a3ec0709 mtd: atmel_nand: fix error return code in
atmel_nand_probe()
573f505290ac60920d2e4d4c39323acb14b7b0c4 mtd: remove alauda driver
240ca8e6f0f5689bc34130c5843fc7df40fc994a mtd: nand: mxc_nand: mark 'const'
properly
fdd0ddf7fac3ae18b8cbaf64a60a3f9591e124ac mtd: r852: Staticize local symbols
e979054e90b480bb62ac8ac2d69bbe13418f6514 mtd: nandsim: Staticize local symbols
cfa8de169b47502e0ce8b30b9a79b615b68af6b1 mtd: MTD_NAND_DENALI should depend on
HAS_DMA
d322e0477e11fdd9bdec1040a7c8d4e14ec3e188 mtd: fsmc_nand: simplify
platform_get_resource_byname/devm_ioremap_resource
f09f9d2061572d858856085d57d2f580fb60db0d mtd: atmel_nand: pmecc: fix bug fail to
correct bit error in 1024-bytes sector
8a7f3dbd96350bc1d3f012c14da682049eb89530 mtd: nand: fixup kerneldoc, rename
parameter
69d75957804c0cc214b705fee8c618bcca6c1671 mtd: gpmi: remove the nand_scan()
6aa28d55ddaf7ce5e245f835bfd0871ef3db492c mtd: set ONFI nand's default hooks in
nand_set_defaults()
3320916b8845e06d04cea7b492920829ce49ac0e mtd: set the ecc step size for master/slave
mtd_info
8d6a288d8b950b08a150f96781d365f770669898 mtd: nand: silence some shift wrap
warnings
38cd6478fb2b38b12525fbede22cf549e1581a3e mtd: simplify use of
devm_ioremap_resource
7b900eb9f497da080c3a46a50fe33ffa14e093aa mtd: nand: Allow to build pxa3xx_nand on
Orion platforms
2cd4ce5d72919da4a5eb48f63d50ccbb38d96b19 mtd: nand: pxa3xx: Allow devices with no dma
resources
383b9edf4a14193c819cb5f1cf841206da064095 mtd: nand: pxa3xx: Add __maybe_unused keyword
to enable_int()
4552440a0c279fac04e4a7216c36a537956a2acc mtd: nand: pxa3xx: Make dma code dependent on
dma capable platforms
475e1ad93c4bc100ad8ed82013669f8569471a96 mtd: nand: pxa3xx: Move cached registers to
info structure
8270cfd39ae136c10082287f612f825414a01950 mtd: nand: pxa3xx: Remove uneeded
internal cmdset
234f82f9269e2a96c4b6f3802121d8e307d29580 mtd: nand: pxa3xx: Remove hardcoded
mtd name
afa5a8a3750f428fe4c9f9a5840dfddfe4f7d503 mtd: nand: pxa3xx: Add a local loop
variable
dc33d8fcfc245dab443ef1a5172864bb6d3d2c94 mtd: nand: pxa3xx: Use 'length override' in
ONFI paramater page read
1b3334cf50d40eb1ef7f39d6e3396b30d5d085f0 mtd: nand: pxa3xx: Support command
buffer #3
33275c59dab511acd0fbb988519bd8dba670b7ff mtd: nand: pxa3xx: Allow to set/clear the
'spare enable' field
08f509aac14a0c7120f2885ac543c9758b00a518 mtd: nand: pxa3xx: Handle ECC and DMA
enable/disable properly
00187c3a76b6e3da79ef495ce2a6c68fe96ee0de mtd: nand: pxa3xx: Introduce
'marvell,armada370-nand' compa
[U-Boot] [PATCH v5 0/8] ARMv7: Add HYP mode switching support
(for GIT URL and Changelog see below)
ARM CPUs with the virtualization extension have a new mode called
HYP mode, which allows hypervisors to safely control and monitor
guests. The current hypervisor implementations (KVM and Xen)
require the kernel to be entered in that HYP mode.
This patch series introduces a configuration variable
CONFIG_ARMV7_VIRT which enables code to switch all cores into HYP
mode. This is done automatically during execution of the bootm
command.
The process of switching into HYP mode requires the CPU to be in
secure state initially when entering u-boot, it will then setup some
register and switch to non-secure state. This requires the GIC to be
programmed properly first. Explanations about the details are in the
commit messages of the respective patches.
The patches are structured like this:
1/8: prepare header file
2/8: add monitor handler (assembly)
3/8: add per CPU non-secure switch routine (assembly)
4/8: add system wide non-secure setup (C)
5/8: trigger non-secure switch during bootm command
6/8: add generic SMP functionality
7/8: add HYP mode switching
8/8: board specific code for ARM Versatile Express TC2
Since up to patch 6/8 this code works on non-virtualization capable
CPUs also and as there has been a request, there is now a second
configuration variable CONFIG_ARMV7_NONSEC, which omits the final
HYP mode switch and just goes into non-secure SVC state.
You can specify either (or none) of them, the code cares about
the dependency.
The code aims to be as generic as possible, though currently it has
only been tested on the Versatile Express TC-2 board. The last patch
thus enables the feature for that board and should serve as an
example for supporting other boards.
I have had reports from different parties of successful adaptions to
other boards as well (Arndale, Cubieboard, Chromebook), so I will
create a hypmode-ports branch in the below repository to collect
those patches and prepare them for upstreaming.
For convenience there is a GIT tree which you can pull these patches
from ("hypmode_v5" branch):
git://git.linaro.org/people/aprzywara/u-boot.git
Changes RFC..v1
* not a dedicated command anymore, code run by bootm & friends
* protecting code with #ifdefs to avoid unnecessary inclusion and
accidental crashing (when accessing restricted registers)
* moving prototypes to header file to meet checkpatch recommendation
* adding comment as proposed by Christoffer
Changes v1..v2
mostly style and code layout changes
* restructure assembly code to live in a new file and not start.S
* split smp, nonsec_init and hyp_init to be separate functions
* used named constants from common header files
* split C function to be more readable
* extend comments to be more precise and elaborate
* add provision to override GIC base address (needed for Arndale?)
* add configuration variable to enable VExpress specific SMP code
* use writel/readl for MMIO GIC accesses
* remove superfluous isb instructions
* more minor fixes
Changes v2..v3
* fix clobbering of GICC address actually spoiling the stack
* do CNTFRQ setup in assembly per core (and not only once per SoC)
* moving the new code files into arch/arm/cpu/armv7
* add config variable for doing non-secure switch only
* use actual HYP and secure instructions mnemonics instead of
the encoded byte sequence. This requires more recent compilers.
* make the identification of the CPU core more robust and saner
* use enum for error codes and rename them
* lots of smaller layout and style fixes
Changes v3..v4
* mask reserved bits in CBAR register
* move the VExpress board specific SMP code into the board directory
* embed error reporting in the respective functions and getting
rid of the error code enum at all (by popular demand ;-)
* minor style fixes
Changes v4..v5:
* remove unneeded padding in exception table
* only clear unbanked interrupts in GIC distributor for non-secure
* add a default weak implementation for the smp_waitloop() function,
there only needs to be provided the address of the SMP pen now
* fix compilation error with non-A15 VExpress boards
* adding patch specific changelogs for v3..v4 and v4..v5
Please review, comment ... and commit ;-)
Contributions and comments to support other boards are welcome.
Andre Przywara (8):
ARM: prepare armv7.h to be included from assembly source
ARM: add secure monitor handler to switch to non-secure state
ARM: add assembly routine to switch to non-secure state
ARM: add C function to switch to non-secure state
ARM: trigger non-secure state switch during bootm execution
ARM: add SMP support for non-secure switch
ARM: extend non-secure switch to also go into HYP mode
ARM: VExpress: enable ARMv7 virt support for VExpress A15
arch/arm/cpu/armv7/Makefile | 5 +
arch/arm/cpu/armv7/nonsec_virt.S| 208
arch/arm/cpu/armv7/virt-v7.c| 173 ++
arch/arm/include/asm/armv7.h| 33
Re: [U-Boot] [PATCH v5 3/8] ARM: add assembly routine to switch to non-secure state
Hi Andre, There is another approach taken in xen. (xen/arch/arm/mode_switch.S) Which do you think is the better approach Regards -mj On 9/19/13, Andre Przywara wrote: > While actually switching to non-secure state is one thing, another > part of this process is to make sure that we still have full access > to the interrupt controller (GIC). > The GIC is fully aware of secure vs. non-secure state, some > registers are banked, others may be configured to be accessible from > secure state only. > To be as generic as possible, we get the GIC memory mapped address > based on the PERIPHBASE value in the CBAR register. Since this > register is not architecturally defined, we check the MIDR before to > be from an A15 or A7. > For CPUs not having the CBAR or boards with wrong information herein > we allow providing the base address as a configuration variable. > > Now that we know the GIC address, we: > a) allow private interrupts to be delivered to the core >(GICD_IGROUPR0 = 0x) > b) enable the CPU interface (GICC_CTLR[0] = 1) > c) set the priority filter to allow non-secure interrupts >(GICC_PMR = 0xFF) > > Also we allow access to all coprocessor interfaces from non-secure > state by writing the appropriate bits in the NSACR register. > > The generic timer base frequency register is only accessible from > secure state, so we have to program it now. Actually this should be > done from primary firmware before, but some boards seems to omit > this, so if needed we do this here with a board specific value. > The Versatile Express board does not need this, so we remove the > frequency from the configuration file here. > > After having switched to non-secure state, we also enable the > non-secure GIC CPU interface, since this register is banked. > > Since we need to call this routine also directly from the smp_pen > later (where we don't have any stack), we can only use caller saved > registers r0-r3 and r12 to not mess with the compiler. > > Signed-off-by: Andre Przywara > --- > arch/arm/cpu/armv7/nonsec_virt.S| 86 > + > arch/arm/include/asm/armv7.h| 21 + > arch/arm/include/asm/gic.h | 17 > include/configs/vexpress_ca15_tc2.h | 2 - > 4 files changed, 124 insertions(+), 2 deletions(-) > create mode 100644 arch/arm/include/asm/gic.h > > Changes: > v3..v4: clear reserved bits in CBAR > v4..v5: none > > diff --git a/arch/arm/cpu/armv7/nonsec_virt.S > b/arch/arm/cpu/armv7/nonsec_virt.S > index c21bca3..3dd60b7 100644 > --- a/arch/arm/cpu/armv7/nonsec_virt.S > +++ b/arch/arm/cpu/armv7/nonsec_virt.S > @@ -23,6 +23,11 @@ > */ > > #include > +#include > +#include > +#include > + > +.arch_extension sec > > /* the vector table for secure state */ > _monitor_vectors: > @@ -52,3 +57,84 @@ _secure_monitor: > > movspc, lr @ return to non-secure SVC > > +/* > + * Switch a core to non-secure state. > + * > + * 1. initialize the GIC per-core interface > + * 2. allow coprocessor access in non-secure modes > + * 3. switch the cpu mode (by calling "smc #0") > + * > + * Called from smp_pen by secondary cores and directly by the BSP. > + * Do not assume that the stack is available and only use registers > + * r0-r3 and r12. > + * > + * PERIPHBASE is used to get the GIC address. This could be 40 bits long, > + * though, but we check this in C before calling this function. > + */ > +ENTRY(_nonsec_init) > +#ifdef CONFIG_ARM_GIC_BASE_ADDRESS > + ldr r2, =CONFIG_ARM_GIC_BASE_ADDRESS > +#else > + mrc p15, 4, r2, c15, c0, 0 @ read CBAR > + bfc r2, #0, #15 @ clear reserved bits > +#endif > + add r3, r2, #GIC_DIST_OFFSET@ GIC dist i/f offset > + mvn r1, #0 @ all bits to 1 > + str r1, [r3, #GICD_IGROUPRn]@ allow private interrupts > + > + mrc p15, 0, r0, c0, c0, 0 @ read MIDR > + ldr r1, =MIDR_PRIMARY_PART_MASK > + and r0, r0, r1 @ mask out variant and revision > + > + ldr r1, =MIDR_CORTEX_A7_R0P0 & MIDR_PRIMARY_PART_MASK > + cmp r0, r1 @ check for Cortex-A7 > + > + ldr r1, =MIDR_CORTEX_A15_R0P0 & MIDR_PRIMARY_PART_MASK > + cmpne r0, r1 @ check for Cortex-A15 > + > + movne r1, #GIC_CPU_OFFSET_A9 @ GIC CPU offset for A9 > + moveq r1, #GIC_CPU_OFFSET_A15 @ GIC CPU offset for A15/A7 > + add r3, r2, r1 @ r3 = GIC CPU i/f addr > + > + mov r1, #1 @ set GICC_CTLR[enable] > + str r1, [r3, #GICC_CTLR]@ and clear all other bits > + mov r1, #0xff > + str r1, [r3, #GICC_PMR] @ set priority mask register > + > + movwr1, #0x3fff > + movtr1, #0x0006 > + mcr p15, 0, r1, c1, c1, 2 @ NSACR = all copros t
Re: [U-Boot] gpmi-nand driver and jffs2 support
Dear Huang Shijie, Sorry, I think I got lost in the discussion. I will pull out. btw Hector, I managed to verify JFFS2 mounting doesn't work on 3.10 , now I'm trying to backport patches from -next and apply the GPMI NAND patchset, without much luck yet. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] gpmi-nand driver and jffs2 support
Dear Hector Palacios, > On 09/19/2013 06:07 PM, Marek Vasut wrote: > > Dear Huang Shijie, > > > > Sorry, I think I got lost in the discussion. I will pull out. > > > > btw Hector, I managed to verify JFFS2 mounting doesn't work on 3.10 , now > > I'm trying to backport patches from -next and apply the GPMI NAND > > patchset, without much luck yet. > > Oops, sorry, did you mean you were trying to backport them into U-Boot? > Then please disregards my previous message. You actually just saved me a lot of annoyance, thank you ;-) btw feel free to run into me on IRC (#u-boot on freenode) or jabber so we can work on the backporting-to-uboot part ;-) 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 12/12 V3] DWMMC: SMDK5420: Disable SMU for eMMC
Hi Simon, Thank you for comments. Will add a check so that it will be executed only for Exynos5420 boards. Thanks and Regards, Rajeshwari. On Thu, Sep 19, 2013 at 11:42 AM, Simon Glass wrote: > Hi Rajeshwari, > > On Wed, Sep 11, 2013 at 4:01 AM, Rajeshwari S Shinde < > rajeshwar...@samsung.com> wrote: > >> SMDK5420 has a new Security Management Unit added >> for dwmmc driver, hence, configuring the control >> registers to support booting via eMMC. >> >> Signed-off-by: Alim Akhtar >> Signed-off-by: Rajeshwari Shinde >> --- >> Changes in V3: >> - New patch. >> drivers/mmc/dw_mmc.c | 7 +++ >> include/dwmmc.h | 12 >> 2 files changed, 19 insertions(+) >> >> diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c >> index a82ee17..d763949 100644 >> --- a/drivers/mmc/dw_mmc.c >> +++ b/drivers/mmc/dw_mmc.c >> @@ -300,6 +300,13 @@ static int dwmci_init(struct mmc *mmc) >> struct dwmci_host *host = (struct dwmci_host *)mmc->priv; >> u32 fifo_size; >> >> + dwmci_writel(host, EMMCP_MPSBEGIN0, 0); >> + dwmci_writel(host, EMMCP_SEND0, 0); >> + dwmci_writel(host, EMMCP_CTRL0, >> + MPSCTRL_SECURE_READ_BIT | MPSCTRL_SECURE_WRITE_BIT | >> + MPSCTRL_NON_SECURE_READ_BIT | MPSCTRL_NON_SECURE_WRITE_BIT >> | >> + MPSCTRL_VALID); >> + >> > > Is this safe for all users of this file (Exynos5250, etc. ? > > Regards, > Simon > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > -- Regards, Rajeshwari Shinde ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] OMAP3: igep00x0: rename config file to omap3_igep00x0.h
Hi Javier,
On 09/19/2013 04:04 PM, Javier Martinez Canillas wrote:
> On Mon, Sep 2, 2013 at 1:52 PM, Enric Balletbo Serra
> wrote:
>> 2013/9/2 Javier Martinez Canillas :
>>> There seems to be a naming convention for the configuration
>>> files for boards using the same SoC family. This makes
>>> easier to do changes that affect different boards based
>>> on the same SoC.
>>>
>>> Since the IGEPv2 board and the IGEP COM Module use a TI
>>> OMAP35xx/DM37xx processor, is better to rename its board
>>> config to use this naming scheme.
>>>
>>> Signed-off-by: Javier Martinez Canillas
>>> ---
>>>
>>> Changes since v1:
>>> - Fix some issues in the commit changelog pointed out by Enric Balletbo.
>>>
>>> boards.cfg | 10 +-
>>> include/configs/igep00x0.h | 370
>>> ---
>>> include/configs/omap3_igep00x0.h | 370
>>> +++
>>> 3 files changed, 375 insertions(+), 375 deletions(-)
>>> delete mode 100644 include/configs/igep00x0.h
>>> create mode 100644 include/configs/omap3_igep00x0.h
>>>
>>> diff --git a/boards.cfg b/boards.cfg
>>> index d717226..8f1cb6e 100644
>>> --- a/boards.cfg
>>> +++ b/boards.cfg
>>> @@ -297,11 +297,11 @@ omap3_overo arm armv7
>>> overo -
>>> omap3_pandoraarm armv7 pandora -
>>> omap3
>>> dig297 arm armv7 dig297
>>> comelitomap3
>>> cm_t35 arm armv7 cm_t35
>>> compulab omap3
>>> -igep0020 arm armv7 igep00x0
>>> isee omap3
>>> igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_ONENAND
>>> -igep0020_nandarm armv7 igep00x0
>>> isee omap3
>>> igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_NAND
>>> -igep0030 arm armv7 igep00x0
>>> isee omap3
>>> igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND
>>> -igep0030_nandarm armv7 igep00x0
>>> isee omap3
>>> igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_NAND
>>> -igep0032 arm armv7 igep00x0
>>> isee omap3
>>> igep00x0:MACH_TYPE=MACH_TYPE_IGEP0032,BOOT_ONENAND
>>> +omap3_igep0020 arm armv7 igep00x0
>>> isee omap3
>>> omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_ONENAND
>>> +omap3_igep0020_nand arm armv7 igep00x0
>>> isee omap3
>>> omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_NAND
>>> +omap3_igep0030 arm armv7 igep00x0
>>> isee omap3
>>> omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND
>>> +omap3_igep0030_nand arm armv7 igep00x0
>>> isee omap3
>>> omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_NAND
>>> +omap3_igep0032 arm armv7 igep00x0
>>> isee omap3
>>> omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0032,BOOT_ONENAND
>>> am335x_igep0033 arm armv7 igep0033
>>> isee am33xx
>>> am3517_evm arm armv7 am3517evm
>>> logicpdomap3
>>> mt_ventoux arm armv7 mt_ventoux
>>> teejet omap3
>
>> Acked-by: Enric Balletbo i Serra
>
> These patches don't apply on master anymore after commit 27af930e9
> ("Merge and reformat boards.cfg and MAINTAINERS"). I'll rebase the
> patches and repost.
If you are about to repost, can you please add '-M' flag to
git format-patch command (if you use this command).
This will detect renames and lower the patch size...
--
Regards,
Igor
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How the ORx in MPC8641d soc Registers are filled?
On 09/19/2013 07:14 AM, Ashish wrote: > On Thursday 19 September 2013 11:50 AM, sun york-R58495 wrote: >> On Sep 18, 2013, at 9:54 PM, Ashish wrote: >> >>> York, >>> I am trying to understand how the fields of ORx registers are >>> filled. I am using MPC8641-HPCN board for evaluation purpose. In this >>> i am trying to connect a 16MB size 32 bit-port size Nor flash >>> (2xAT49bv6416). I am using Code Warrior for Bring up process. I have >>> tried to search for the fields how they are calculated but i get only >>> values not the way they calculates. Any thing/pointer that helps me >>> to explore how ORx register is filled would be very helpful. >>> >>> -- >>> --with Regards >>> Ashish Khetan >>> >> Ashish, >> >> There isn't much to calculate. Do you have access to the reference >> manual? It is available on www.freescale.com. Once you know the device >> type and physical connection, you are pretty much fixed with most >> fields. You only need to get the timing to match the bus speed and >> device speed. >> >> York >> >> > Thanks York, >Can i ask you to explain more about the ORx register? How the Timing > values are calculated? > Because The flash is connected using chip-select0 through Local bus > controller. I am getting only read from the flash but its not getting > erase/reprogrammed. > I used the following Register configuration: > SYSCLK is 100Mhz, MPX 400Mhz, CORE 800Mhz > BR0 FF001801 > OR0 FF006FF7 > LBCR > LCRR 8008 > So the Local Bus is working at 25Mhz. > Ashish, Your OR0 sets to slowest speed, so it should work. But I noticed you said and set the size to 16MB. Are you replacing the on-board NOR flash with the one you mentioned? I didn't check the spec of the part number. But if you did replace with a twice sized flash chip, you need to get the address signal connected. I don't believe MPC8641HPCN board has spare address line connected. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] socfpga: Adding Freeze Controller driver
Adding Freeze Controller driver. All HPS IOs need to be
in freeze state during pin mux or IO buffer configuration.
It is to avoid any glitch which might happen
during the configuration from propagating to external devices.
Signed-off-by: Chin Liang See
Cc: Wolfgang Denk
CC: Pavel Machek
Cc: Dinh Nguyen
---
Changes for v2
- Removed FREEZE_CONTROLLER_FSM_HW
- Removed the get_timer_count_masked and convert to use delay in us
- Used shorter local variables
---
arch/arm/cpu/armv7/socfpga/Makefile|2 +-
arch/arm/cpu/armv7/socfpga/freeze_controller.c | 249
arch/arm/cpu/armv7/socfpga/spl.c | 16 ++
.../include/asm/arch-socfpga/freeze_controller.h | 71 ++
4 files changed, 337 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/cpu/armv7/socfpga/freeze_controller.c
create mode 100644 arch/arm/include/asm/arch-socfpga/freeze_controller.h
diff --git a/arch/arm/cpu/armv7/socfpga/Makefile
b/arch/arm/cpu/armv7/socfpga/Makefile
index 0859e44..10d20f2 100644
--- a/arch/arm/cpu/armv7/socfpga/Makefile
+++ b/arch/arm/cpu/armv7/socfpga/Makefile
@@ -14,7 +14,7 @@ LIB = $(obj)lib$(SOC).o
SOBJS := lowlevel_init.o
COBJS-y:= misc.o timer.o reset_manager.o system_manager.o
-COBJS-$(CONFIG_SPL_BUILD) += spl.o
+COBJS-$(CONFIG_SPL_BUILD) += spl.o freeze_controller.o
COBJS := $(COBJS-y)
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
diff --git a/arch/arm/cpu/armv7/socfpga/freeze_controller.c
b/arch/arm/cpu/armv7/socfpga/freeze_controller.c
new file mode 100644
index 000..668c6d6
--- /dev/null
+++ b/arch/arm/cpu/armv7/socfpga/freeze_controller.c
@@ -0,0 +1,249 @@
+/*
+ * Copyright (C) 2013 Altera Corporation
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+
+#include
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+
+
+static const struct socfpga_freeze_controller *freeze_controller_base =
+ (void *)(SOCFPGA_SYSMGR_ADDRESS + SYSMGR_FRZCTRL_ADDRESS);
+
+/*
+ * Default state from cold reset is FREEZE_ALL; the global
+ * flag is set to TRUE to indicate the IO banks are frozen
+ */
+static uint32_t frzctrl_channel_freeze[FREEZE_CHANNEL_NUM]
+ = { FREEZE_CTRL_FROZEN, FREEZE_CTRL_FROZEN,
+ FREEZE_CTRL_FROZEN, FREEZE_CTRL_FROZEN};
+
+
+/* Freeze HPS IOs */
+u32 sys_mgr_frzctrl_freeze_req(FreezeChannelSelect channel_id,
+ FreezeControllerFSMSelect fsm_select)
+{
+ u32 ioctrl_reg_offset;
+ u32 reg_value;
+ u32 reg_cfg_mask;
+
+ if (FREEZE_CONTROLLER_FSM_SW != fsm_select)
+ return -EINVAL;
+
+ /* select software FSM */
+ writel(SYSMGR_FRZCTRL_SRC_VIO1_ENUM_SW, &freeze_controller_base->src);
+
+ /* Freeze channel ID checking and base address */
+ switch (channel_id) {
+ case FREEZE_CHANNEL_0:
+ case FREEZE_CHANNEL_1:
+ case FREEZE_CHANNEL_2:
+ ioctrl_reg_offset = (u32)(
+ &freeze_controller_base->vioctrl +
+ (channel_id << SYSMGR_FRZCTRL_VIOCTRL_SHIFT));
+
+ /*
+* Assert active low enrnsl, plniotri
+* and niotri signals
+*/
+ reg_cfg_mask =
+ SYSMGR_FRZCTRL_VIOCTRL_SLEW_MASK
+ | SYSMGR_FRZCTRL_VIOCTRL_WKPULLUP_MASK
+ | SYSMGR_FRZCTRL_VIOCTRL_TRISTATE_MASK;
+ clrbits_le32(ioctrl_reg_offset, reg_cfg_mask);
+
+ /*
+* Note: Delay for 20ns at min
+* Assert active low bhniotri signal and de-assert
+* active high csrdone
+*/
+ reg_cfg_mask
+ = SYSMGR_FRZCTRL_VIOCTRL_BUSHOLD_MASK
+ | SYSMGR_FRZCTRL_VIOCTRL_CFG_MASK;
+ clrbits_le32(ioctrl_reg_offset, reg_cfg_mask);
+
+ /* Set global flag to indicate channel is frozen */
+ frzctrl_channel_freeze[channel_id] = FREEZE_CTRL_FROZEN;
+ break;
+
+ case FREEZE_CHANNEL_3:
+ /*
+* Assert active low enrnsl, plniotri and
+* niotri signals
+*/
+ reg_cfg_mask
+ = SYSMGR_FRZCTRL_HIOCTRL_SLEW_MASK
+ | SYSMGR_FRZCTRL_HIOCTRL_WKPULLUP_MASK
+ | SYSMGR_FRZCTRL_HIOCTRL_TRISTATE_MASK;
+ clrbits_le32(&freeze_controller_base->hioctrl, reg_cfg_mask);
+
+ /*
+* Note: Delay for 40ns at min
+* assert active low bhniotri & nfrzdrv signals,
+* de-assert active high csrdone and assert
+* active high frzreg and nfrzdrv signals
+*/
+ reg_value = readl(&freeze_controller_base->hioctrl);
+ reg_cfg_mask
+ = SYSMGR_FRZCTRL_HIOCTRL_BUSHOLD_MASK
+ | SYSMGR_FRZ
Re: [U-Boot] [PATCH] socfpga: Adding Freeze Controller driver
Hi Pavel,
On Thu, 2013-09-19 at 14:11 +0200, ZY - pavel wrote:
> Hi!
>
> > Adding Freeze Controller driver. All HPS IOs need to be
> > in freeze state during pin mux or IO buffer configuration.
> > It is to avoid any glitch which might happen
> > during the configuration from propagating to external devices.
>
> Thanks for the patch.
Thanks to you too for the speedy feedback.
>
> (What version is it against? Aha, it depends on previous patches,
> right?)
I patched against latest release plus the last 2 patches for System
Manager & pin mux (other earlier patches already in latest release).
These patches already went through few round of reviews. I believe we
just need to wait Albert to apply them into master git :)
>
> AFAICT:
>
> FREEZE_CONTROLLER_FSM_HW is unused and can be removed.
Yup, they can removed. It was put initially as customer can use either
SW or HW state machine. But rethinking of this, most likely customer
will not change this area. So its good to remove the dead code.
>
> frzctrl_channel_freeze[] is write-only and can be removed.
Actually they will be used in other function within this driver. This
function is yet to be upstreamed. I plan to do it together with new
driver "Scan Manager" in later days. The Scan Manager will need this
function to work together. With that, is it ok that we maintain this
first?
>
> Local variables do not need frzctrl_ prefix.
Oops, seems overdone here... haha. I already fix it
>
> [I have fixed those, suggested incremental diff is attached. Please
> review & apply to your tree.]
Thanks and applied
>
> Is it really neccessary to introduce get_timer_count_masked? Replace
> the delays with udelay(1) and it should still work?
Good suggestion here. I converted them to use the delay now to avoid
creating the new timer functions. End of day, not much impact to
performance when converting clock cycles to microseconds.
I will send up the v2 in short time. Thanks again and have a fun day.
Chin Liang
>
> Thanks,
> Pavel
>
> diff --git a/arch/arm/cpu/armv7/socfpga/freeze_controller.c
> b/arch/arm/cpu/armv7/socfpga/freeze_controller.c
> index af612c9..058d9b5 100644
> --- a/arch/arm/cpu/armv7/socfpga/freeze_controller.c
> +++ b/arch/arm/cpu/armv7/socfpga/freeze_controller.c
> @@ -9,226 +9,183 @@
> #include
> #include
> #include
> +#include
>
> DECLARE_GLOBAL_DATA_PTR;
>
> +
> +
> static const struct socfpga_freeze_controller *freeze_controller_base =
> (void *)(SOCFPGA_SYSMGR_ADDRESS + SYSMGR_FRZCTRL_ADDRESS);
>
> -/*
> - * Default state from cold reset is FREEZE_ALL; the global
> - * flag is set to TRUE to indicate the IO banks are frozen
> - */
> -static uint32_t frzctrl_channel_freeze[FREEZE_CHANNEL_NUM]
> - = { FREEZE_CTRL_FROZEN, FREEZE_CTRL_FROZEN,
> - FREEZE_CTRL_FROZEN, FREEZE_CTRL_FROZEN};
> -
> -/* Get current state of freeze channel 1 (VIO) */
> -static inline u32 sys_mgr_frzctrl_frzchn1_state_get(void)
> -{
> - u32 frzchn1_state;
> - frzchn1_state = readl(&freeze_controller_base->hwctrl);
> - frzchn1_state = SYSMGR_FRZCTRL_HWCTRL_VIO1STATE_GET(frzchn1_state);
> - return frzchn1_state;
> -}
>
> /* Freeze HPS IOs */
> u32 sys_mgr_frzctrl_freeze_req(FreezeChannelSelect channel_id,
> - FreezeControllerFSMSelect fsm_select)
> +FreezeControllerFSMSelect fsm_select)
> {
> - u32 frzctrl_ioctrl_reg_offset;
> - u32 frzctrl_reg_value;
> - u32 frzctrl_reg_cfg_mask;
> + u32 ioctrl_reg_offset;
> + u32 reg_value;
> + u32 reg_cfg_mask;
> u32 i;
>
> - if (FREEZE_CONTROLLER_FSM_SW == fsm_select) {
> -
> - /* select software FSM */
> - writel(SYSMGR_FRZCTRL_SRC_VIO1_ENUM_SW,
> - &freeze_controller_base->src);
> -
> - /* Freeze channel ID checking and base address */
> - switch (channel_id) {
> - case FREEZE_CHANNEL_0:
> - case FREEZE_CHANNEL_1:
> - case FREEZE_CHANNEL_2:
> - frzctrl_ioctrl_reg_offset = (u32)(
> - &freeze_controller_base->vioctrl +
> - (channel_id << SYSMGR_FRZCTRL_VIOCTRL_SHIFT));
> -
> - /*
> - * Assert active low enrnsl, plniotri
> - * and niotri signals
> - */
> - frzctrl_reg_cfg_mask =
> - SYSMGR_FRZCTRL_VIOCTRL_SLEW_MASK
> - | SYSMGR_FRZCTRL_VIOCTRL_WKPULLUP_MASK
> - | SYSMGR_FRZCTRL_VIOCTRL_TRISTATE_MASK;
> - clrbits_le32(frzctrl_ioctrl_reg_offset,
> - frzctrl_reg_cfg_mask);
> -
> - /*
> - * Note: Delay for 20ns at min
> - * Assert active low bhniotri signal and de-assert
>
Re: [U-Boot] [PATCH v2 2/2] OMAP3: igep00x0: rename config file to omap3_igep00x0.h
On 09/19/2013 05:00 PM, Igor Grinberg wrote:
> Hi Javier,
>
> On 09/19/2013 04:04 PM, Javier Martinez Canillas wrote:
>> On Mon, Sep 2, 2013 at 1:52 PM, Enric Balletbo Serra
>> wrote:
>>> 2013/9/2 Javier Martinez Canillas :
There seems to be a naming convention for the configuration
files for boards using the same SoC family. This makes
easier to do changes that affect different boards based
on the same SoC.
Since the IGEPv2 board and the IGEP COM Module use a TI
OMAP35xx/DM37xx processor, is better to rename its board
config to use this naming scheme.
Signed-off-by: Javier Martinez Canillas
---
Changes since v1:
- Fix some issues in the commit changelog pointed out by Enric Balletbo.
boards.cfg | 10 +-
include/configs/igep00x0.h | 370
---
include/configs/omap3_igep00x0.h | 370
+++
3 files changed, 375 insertions(+), 375 deletions(-)
delete mode 100644 include/configs/igep00x0.h
create mode 100644 include/configs/omap3_igep00x0.h
diff --git a/boards.cfg b/boards.cfg
index d717226..8f1cb6e 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -297,11 +297,11 @@ omap3_overo arm armv7
overo -
omap3_pandoraarm armv7 pandora
- omap3
dig297 arm armv7 dig297
comelitomap3
cm_t35 arm armv7 cm_t35
compulab omap3
-igep0020 arm armv7 igep00x0
isee omap3
igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_ONENAND
-igep0020_nandarm armv7 igep00x0
isee omap3
igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_NAND
-igep0030 arm armv7 igep00x0
isee omap3
igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND
-igep0030_nandarm armv7 igep00x0
isee omap3
igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_NAND
-igep0032 arm armv7 igep00x0
isee omap3
igep00x0:MACH_TYPE=MACH_TYPE_IGEP0032,BOOT_ONENAND
+omap3_igep0020 arm armv7 igep00x0
isee omap3
omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_ONENAND
+omap3_igep0020_nand arm armv7 igep00x0
isee omap3
omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_NAND
+omap3_igep0030 arm armv7 igep00x0
isee omap3
omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND
+omap3_igep0030_nand arm armv7 igep00x0
isee omap3
omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_NAND
+omap3_igep0032 arm armv7 igep00x0
isee omap3
omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0032,BOOT_ONENAND
am335x_igep0033 arm armv7 igep0033
isee am33xx
am3517_evm arm armv7 am3517evm
logicpdomap3
mt_ventoux arm armv7 mt_ventoux
teejet omap3
>>
>>> Acked-by: Enric Balletbo i Serra
>>
>> These patches don't apply on master anymore after commit 27af930e9
>> ("Merge and reformat boards.cfg and MAINTAINERS"). I'll rebase the
>> patches and repost.
>
> If you are about to repost, can you please add '-M' flag to
> git format-patch command (if you use this command).
> This will detect renames and lower the patch size...
>
Hi Igor,
Yes I do use git format-patch and I'll use -M for the next version.
Thanks for the feedback and best regards,
Javier
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] OMAP3: igep00x0: rename config file to omap3_igep00x0.h
On Thu, Sep 19, 2013 at 5:13 PM, Javier Martinez Canillas
wrote:
> On 09/19/2013 05:00 PM, Igor Grinberg wrote:
>> Hi Javier,
>>
>> On 09/19/2013 04:04 PM, Javier Martinez Canillas wrote:
>>> On Mon, Sep 2, 2013 at 1:52 PM, Enric Balletbo Serra
>>> wrote:
2013/9/2 Javier Martinez Canillas :
> There seems to be a naming convention for the configuration
> files for boards using the same SoC family. This makes
> easier to do changes that affect different boards based
> on the same SoC.
>
> Since the IGEPv2 board and the IGEP COM Module use a TI
> OMAP35xx/DM37xx processor, is better to rename its board
> config to use this naming scheme.
>
> Signed-off-by: Javier Martinez Canillas
> ---
>
> Changes since v1:
> - Fix some issues in the commit changelog pointed out by Enric Balletbo.
>
> boards.cfg | 10 +-
> include/configs/igep00x0.h | 370
> ---
> include/configs/omap3_igep00x0.h | 370
> +++
> 3 files changed, 375 insertions(+), 375 deletions(-)
> delete mode 100644 include/configs/igep00x0.h
> create mode 100644 include/configs/omap3_igep00x0.h
>
> diff --git a/boards.cfg b/boards.cfg
> index d717226..8f1cb6e 100644
> --- a/boards.cfg
> +++ b/boards.cfg
> @@ -297,11 +297,11 @@ omap3_overo arm armv7
> overo -
> omap3_pandoraarm armv7 pandora
> - omap3
> dig297 arm armv7 dig297
> comelitomap3
> cm_t35 arm armv7 cm_t35
> compulab omap3
> -igep0020 arm armv7 igep00x0
> isee omap3
> igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_ONENAND
> -igep0020_nandarm armv7 igep00x0
> isee omap3
> igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_NAND
> -igep0030 arm armv7 igep00x0
> isee omap3
> igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND
> -igep0030_nandarm armv7 igep00x0
> isee omap3
> igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_NAND
> -igep0032 arm armv7 igep00x0
> isee omap3
> igep00x0:MACH_TYPE=MACH_TYPE_IGEP0032,BOOT_ONENAND
> +omap3_igep0020 arm armv7 igep00x0
> isee omap3
> omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_ONENAND
> +omap3_igep0020_nand arm armv7 igep00x0
> isee omap3
> omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_NAND
> +omap3_igep0030 arm armv7 igep00x0
> isee omap3
> omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND
> +omap3_igep0030_nand arm armv7 igep00x0
> isee omap3
> omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_NAND
> +omap3_igep0032 arm armv7 igep00x0
> isee omap3
> omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0032,BOOT_ONENAND
> am335x_igep0033 arm armv7 igep0033
> isee am33xx
> am3517_evm arm armv7 am3517evm
> logicpdomap3
> mt_ventoux arm armv7 mt_ventoux
> teejet omap3
>>>
Acked-by: Enric Balletbo i Serra
>>>
>>> These patches don't apply on master anymore after commit 27af930e9
>>> ("Merge and reformat boards.cfg and MAINTAINERS"). I'll rebase the
>>> patches and repost.
>>
>> If you are about to repost, can you please add '-M' flag to
>> git format-patch command (if you use this command).
>> This will detect renames and lower the patch size...
>>
>
> Hi Igor,
>
> Yes I do use git format-patch and I'll use -M for the next version.
>
> Thanks for the feedback and best regards,
> Javier
Hi Igor,
Yes I do use git format-patch and I'll use -M for the next version.
Thanks for the feedback and best regards,
Javier
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] doc: README.mxsimage: Use mkimage provided by U-boot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/15/2013 06:58 PM, Otavio Salvador wrote: > On Sun, Sep 15, 2013 at 1:50 PM, Fabio Estevam wrote: >> Hi Marek, >> >> On Sun, Sep 15, 2013 at 1:45 PM, Marek Vasut wrote: >> >>> Tom, are you OK with such a hack (invoking the in-tree mkimage) in the >>> documentation? >> >> This seems to be a common practice in the U-boot doc directory: >> >> doc/README.imximage:./tools/mkimage -l >> doc/README.imximage:./tools/mkimage -T imximage \ >> doc/README.imximage:./tools/mkimage -n >> ./board/freescale/mx51evk/imximage.cfg \ >> doc/README.kwbimage:./tools/mkimage -l >> doc/README.kwbimage:./tools/mkimage -n \ >> doc/README.kwbimage:./tools/mkimage -n >> ./board/Marvell/openrd_base/kwbimage.cfg >> doc/README.mxsimage: ./tools/mkimage -A arm -O u-boot -T mxsimage -n > to co >> doc/README.mxsimage: ./tools/mkimage -l >> doc/README.qemu-mips:# tools/mkimage -A mips -O linux -T kernel -C gzip -a >> 0x800 >> doc/README.ublimage:./tools/mkimage -l >> doc/README.ublimage:./tools/mkimage -T ublimage \ >> doc/README.ublimage:./tools/mkimage -n ./board/davinci/dm365evm/ublimage.cfg >> \ >> doc/SPL/README.am335x-network:$ ./tools/mkimage -A arm -O U-Boot -C none -T >> scri > > Acked-by: Otavio Salvador Acked-by: Tom Rini - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSOw63AAoJENk4IS6UOR1Ww5YP/0+t+Q4CFLv0TND3Tz/i/V0u j5ifPl0KBrYNkwJY+ZVjCCT2XqmTEVZstkUqCoyrFHwBc2+4hxa3Mc/ZpJwe1gIe yeUOxDNFE+NpZpSiwQ5nopqLy//de300u0ElDy3QqBJBwc0NIz4hnKetZiGPzIRF 0CSKng+jGoYKvNu3weOuA8dtA4AqbVzR6PMkJLQxgZSclp4wThLhf2PTMcsbhILw FJXDcuoUST3fkv24U/h2aqS1BYnMaCaVJh9l0keZs/PqtPEvuHjbQEieMTHVz51E Q8crfSy4yUimkqBAZzFTLpBrP9/TaXokXFuYJ/rWqVxT56f+MSQpsofyeKS9fR95 B8A9yAg+84XaG6tk9sbT+UNfzscdizPJXJnjL5wNrBykxXXbbCBawm2/lZMz2rw3 EIZelYrSuhHHZOOJCIEY0nPVXpEoIDn1ndr6uin7chsfdAtnAgSRTrcdf8qjlUnW 47DPDtKEi91BwFHc//k6jXEf69OCRSyecn8coF54ddEsRn7QDJRO791XvHKAvIUD PJkNG/rGTv/1J0sqHLAUuowl8tr+dFxJSGp3kHkX2JQ0LsrYqZJq1wDGTLZ8OPbF XXI8gFytDEC/TJnr8ft7Kl8iKqM6aYc7zLFAIe85P2CWbpsf+Y3C0NOug+5kXWJP 1T9P/B8OWZ1YRTGlwDj6 =SK11 -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] usb: new board-specific USB init interface
Dear Marek Vasut, > Dear Marek Vasut, > > > Dear Mateusz Zalega, > > > > > This commit unifies board-specific USB initialization implementations > > > under one symbol (usb_board_init), declaration of which is available in > > > usb.h. > > > > > > New API allows selective initialization of USB controllers whenever > > > needed. > > > > > > Signed-off-by: Mateusz Zalega > > > Signed-off-by: Kyungmin Park > > > Reviewed-by: Lukasz Majewski > > > Cc: Marek Vasut > > > Cc: Lukasz Majewski > > > Change-Id: Ia78a1378f30a55dd14598c9a1a1b4b8a762e2cd8 > > > --- > > > Changes since RFC (v1): > > > - NVIDIA Tegra doesn't postpone its USB init anymore > > > - board_usb_init()'s sole argument name was shortened > > > - networking code comment style (/* blurb...) dropped > > > - squashed RFC changes so that patch won't break bisect > > > > > > v2 changes: > > > - commit message fixup > > > > > > v3 changes: > > > - added 'index' argument to perform selective port initialization > > > > > > v4 changes: > > > - board_usb_init_fail() renamed to board_usb_cleanup() > > > - board_usb_cleanup() accepts controller index and init type > > > - DFU and UMS commands don't init all USB controllers anymore > > > - minor related fixes & refactorization > > > > How did you test it on all the ARM boards ? > > > > ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- BUILD_DIR=/tmp/u-boot-arm-build > > MAKEALL_LOGDIR=/tmp/u-boot-arm-log ./MAKEALL -a arm > > > > does this work for you ? > > Looks like this was a local issue here, sorry for the noise. Once the > builds finish, I will apply for -next. I checked powerpc and "arches" "glacier" and "glacier_nand" don't build. Can you please check and fix ? You can get the ELDK 5.4 PPC toolchain from [1]. http://www.denx.de/wiki/ELDK-5/ Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mx6: compute PLL PFD frequencies rather than using defines
Signed-off-by: Pierre Aubert
CC: Stefano Babic
---
arch/arm/cpu/armv7/mx6/clock.c | 75 --
arch/arm/include/asm/arch-mx6/crm_regs.h | 11
2 files changed, 61 insertions(+), 25 deletions(-)
diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c
index 7a29c9b..0c59541 100644
--- a/arch/arm/cpu/armv7/mx6/clock.c
+++ b/arch/arm/cpu/armv7/mx6/clock.c
@@ -100,6 +100,51 @@ static u32 decode_pll(enum pll_clocks pll, u32 infreq)
}
/* NOTREACHED */
}
+static u32 mxc_get_pll_pfd(enum pll_clocks pll, int pfd_num)
+{
+ u32 div;
+ u64 freq;
+
+ switch (pll) {
+ case PLL_BUS:
+ div = __raw_readl(&imx_ccm->analog_pfd_528);
+ freq = (u64)decode_pll(PLL_BUS, MXC_HCLK);
+ break;
+ case PLL_USBOTG:
+ div = __raw_readl(&imx_ccm->analog_pfd_480);
+ freq = (u64)decode_pll(PLL_USBOTG, MXC_HCLK);
+ break;
+ default:
+ /* No PFD on other PLL */
+ return 0;
+ }
+ freq *= 18;
+
+ switch (pfd_num) {
+ case 0:
+ div &= BM_ANADIG_PFD_528_PFD0_FRAC;
+ break;
+ case 1:
+ div &= BM_ANADIG_PFD_528_PFD1_FRAC;
+ div >>= BP_ANADIG_PFD_528_PFD1_FRAC;
+ break;
+ case 2:
+ div &= BM_ANADIG_PFD_528_PFD2_FRAC;
+ div >>= BP_ANADIG_PFD_528_PFD2_FRAC;
+ break;
+ case 3:
+ if (pll == PLL_SYS) {
+ /* No PFD3 on PPL2 */
+ return 0;
+ }
+ div &= BM_ANADIG_PFD_528_PFD3_FRAC;
+ div >>= BP_ANADIG_PFD_528_PFD3_FRAC;
+ break;
+ default:
+ return 0;
+ }
+ return freq / div;
+}
static u32 get_mcu_main_clk(void)
{
@@ -144,13 +189,14 @@ u32 get_periph_clk(void)
freq = decode_pll(PLL_BUS, MXC_HCLK);
break;
case 1:
- freq = PLL2_PFD2_FREQ;
+ freq = mxc_get_pll_pfd(PLL_BUS, 2);
break;
case 2:
- freq = PLL2_PFD0_FREQ;
+ freq = mxc_get_pll_pfd(PLL_BUS, 0);
break;
case 3:
- freq = PLL2_PFD2_DIV_FREQ;
+ /* static / 2 divider */
+ freq = mxc_get_pll_pfd(PLL_BUS, 2) / 2;
break;
default:
break;
@@ -184,7 +230,7 @@ static u32 get_ipg_per_clk(void)
static u32 get_uart_clk(void)
{
u32 reg, uart_podf;
- u32 freq = PLL3_80M;
+ u32 freq = decode_pll(PLL_USBOTG, MXC_HCLK) / 6; /* static divider */
reg = __raw_readl(&imx_ccm->cscdr1);
#ifdef CONFIG_MX6SL
if (reg & MXC_CCM_CSCDR1_UART_CLK_SEL)
@@ -204,7 +250,7 @@ static u32 get_cspi_clk(void)
reg &= MXC_CCM_CSCDR2_ECSPI_CLK_PODF_MASK;
cspi_podf = reg >> MXC_CCM_CSCDR2_ECSPI_CLK_PODF_OFFSET;
- return PLL3_60M / (cspi_podf + 1);
+ return decode_pll(PLL_USBOTG, MXC_HCLK) / (8 * (cspi_podf + 1));
}
static u32 get_axi_clk(void)
@@ -217,9 +263,9 @@ static u32 get_axi_clk(void)
if (cbcdr & MXC_CCM_CBCDR_AXI_SEL) {
if (cbcdr & MXC_CCM_CBCDR_AXI_ALT_SEL)
- root_freq = PLL2_PFD2_FREQ;
+ root_freq = mxc_get_pll_pfd(PLL_BUS, 2);
else
- root_freq = PLL3_PFD1_FREQ;
+ root_freq = mxc_get_pll_pfd(PLL_USBOTG, 1);
} else
root_freq = get_periph_clk();
@@ -244,10 +290,10 @@ static u32 get_emi_slow_clk(void)
root_freq = decode_pll(PLL_USBOTG, MXC_HCLK);
break;
case 2:
- root_freq = PLL2_PFD2_FREQ;
+ root_freq = mxc_get_pll_pfd(PLL_BUS, 2);
break;
case 3:
- root_freq = PLL2_PFD0_FREQ;
+ root_freq = mxc_get_pll_pfd(PLL_BUS, 0);
break;
}
@@ -270,13 +316,14 @@ static u32 get_mmdc_ch0_clk(void)
freq = decode_pll(PLL_BUS, MXC_HCLK);
break;
case 1:
- freq = PLL2_PFD2_FREQ;
+ freq = mxc_get_pll_pfd(PLL_BUS, 2);
break;
case 2:
- freq = PLL2_PFD0_FREQ;
+ freq = mxc_get_pll_pfd(PLL_BUS, 0);
break;
case 3:
- freq = PLL2_PFD2_DIV_FREQ;
+ /* static / 2 divider */
+ freq = mxc_get_pll_pfd(PLL_BUS, 2) / 2;
}
return freq / (podf + 1);
@@ -329,9 +376,9 @@ static u32 get_usdhc_clk(u32 port)
}
if (clk_sel)
- root_freq = PLL2_PFD0_FREQ;
+
Re: [U-Boot] [PATCH] mx6sabresd: Fix the fdt file for the mx6dl version
Hi Fabio, On 09/19/2013 04:57 AM, Fabio Estevam wrote: Hi Eric, On Wed, Sep 18, 2013 at 10:48 AM, Eric Nelson wrote: As you know, we're loading the kernel using a boot script, with various flavors for differing locations and environments, so we've found it easier to pass environment variables for board and CPU type to the boot script. https://github.com/boundarydevices/u-boot-imx6/commit/4a4fc304e4fe63cde7b3201f0daab5b1856870e4 This allows the boot script to produce the DTB name as shown here: https://github.com/boundarydevices/u-boot-imx6/blob/staging/board/boundary/nitrogen6x/6x_bootscript.txt#L72 If/when you move to a single binary for DQ/DL, you won't have a separate choice as shown above. Let me know your thoughts on this. Yes, it looks interesting for dealing with the single binary goal we want to achieve. We didn't generate a proper patch for lack of time, but I think that the small addition of code has merit. We also may want to discuss the specifics in more detail. When you have a chance please submit a patch. Will do. At least for the upcoming 2013.10, it would be nice to have my original patch of this thread applied for sabresd though. Works for me. My response wasn't a comment on this patch. You just prompted me to start a different discussion. Regards, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
