November 2014 - U-Boot

[U-Boot] [PATCH v4] ARM: mxs: tools: Add support for boot progress display flag
by Alexey Ignatov 20 Nov '14

20 Nov '14

mkimage -T mxs now support new flag in config file: DISPLAYPROGRESS - makes boot process print HTLLC characters for each BootROM instruction. Signed-off-by: Alexey Ignatov <lexszero(a)gmail.com> --- arch/arm/cpu/arm926ejs/mxs/mxsimage-signed.cfg | 1 + arch/arm/cpu/arm926ejs/mxs/mxsimage.mx23.cfg | 1 + arch/arm/cpu/arm926ejs/mxs/mxsimage.mx28.cfg | 1 + doc/README.mxsimage | 13 +++++++++---- tools/mxsimage.c | 16 ++++++++++------ tools/mxsimage.h | 5 +++-- 6 files changed, 25 insertions(+), 12 deletions(-) Changes in v4: - minor fix, removed parentheses in SB_IMAGE_FLAGS_MASK definition Changes in v3: - removed VERBOSEPROGRESS flag - added DISPLAYPROGRESS flag to default mkimage configs, added documentation v2 contained an error, don't use it. diff --git a/arch/arm/cpu/arm926ejs/mxs/mxsimage-signed.cfg b/arch/arm/cpu/arm926ejs/mxs/mxsimage-signed.cfg index 1520bba..83953da 100644 --- a/arch/arm/cpu/arm926ejs/mxs/mxsimage-signed.cfg +++ b/arch/arm/cpu/arm926ejs/mxs/mxsimage-signed.cfg @@ -1,3 +1,4 @@ +DISPLAYPROGRESS SECTION 0x0 BOOTABLE TAG LAST LOAD 0x1000 spl/u-boot-spl.bin diff --git a/arch/arm/cpu/arm926ejs/mxs/mxsimage.mx23.cfg b/arch/arm/cpu/arm926ejs/mxs/mxsimage.mx23.cfg index 55510e9..e702809 100644 --- a/arch/arm/cpu/arm926ejs/mxs/mxsimage.mx23.cfg +++ b/arch/arm/cpu/arm926ejs/mxs/mxsimage.mx23.cfg @@ -1,3 +1,4 @@ +DISPLAYPROGRESS SECTION 0x0 BOOTABLE TAG LAST LOAD 0x1000 spl/u-boot-spl.bin diff --git a/arch/arm/cpu/arm926ejs/mxs/mxsimage.mx28.cfg b/arch/arm/cpu/arm926ejs/mxs/mxsimage.mx28.cfg index bb78cb0..3f7bf59 100644 --- a/arch/arm/cpu/arm926ejs/mxs/mxsimage.mx28.cfg +++ b/arch/arm/cpu/arm926ejs/mxs/mxsimage.mx28.cfg @@ -1,3 +1,4 @@ +DISPLAYPROGRESS SECTION 0x0 BOOTABLE TAG LAST LOAD 0x1000 spl/u-boot-spl.bin diff --git a/doc/README.mxsimage b/doc/README.mxsimage index 0d31cba..c3975ee 100644 --- a/doc/README.mxsimage +++ b/doc/README.mxsimage @@ -27,7 +27,7 @@ These semantics and rules will be outlined now. - Each line of the configuration file contains exactly one instruction. - Every numeric value must be encoded in hexadecimal and in format 0xabcdef12 . - The configuration file is a concatenation of blocks called "sections" and - optionally "DCD blocks" (see below). + optionally "DCD blocks" (see below), and optional flags lines. - Each "section" is started by the "SECTION" instruction. - The "SECTION" instruction has the following semantics: @@ -139,9 +139,14 @@ These semantics and rules will be outlined now. NOOP - This instruction does nothing. -- If the verbose output from the BootROM is enabled, the BootROM will produce a - letter on the Debug UART for each instruction it started processing. Here is a - mapping between the above instructions and the BootROM verbose output: + - An optional flags lines can be one of the following: + + DISPLAYPROGRESS + - Enable boot progress output form the BootROM. + +- If the boot progress output from the BootROM is enabled, the BootROM will + produce a letter on the Debug UART for each instruction it started processing. + Here is a mapping between the above instructions and the BootROM output: H -- SB Image header loaded T -- TAG instruction diff --git a/tools/mxsimage.c b/tools/mxsimage.c index 81c7f2d..ab18041 100644 --- a/tools/mxsimage.c +++ b/tools/mxsimage.c @@ -125,7 +125,7 @@ struct sb_image_ctx { unsigned int in_section:1; unsigned int in_dcd:1; /* Image configuration */ - unsigned int verbose_boot:1; + unsigned int display_progress:1; unsigned int silent_dump:1; char *input_filename; char *output_filename; @@ -1308,8 +1308,7 @@ static int sb_prefill_image_header(struct sb_image_ctx *ictx) sizeof(struct sb_sections_header) / SB_BLOCK_SIZE; hdr->timestamp_us = sb_get_timestamp() * 1000000; - /* FIXME -- add proper config option */ - hdr->flags = ictx->verbose_boot ? SB_IMAGE_FLAG_VERBOSE : 0, + hdr->flags = ictx->display_progress ? SB_IMAGE_FLAG_DISPLAY_PROGRESS : 0; /* FIXME -- We support only default key */ hdr->key_count = 1; @@ -1427,6 +1426,12 @@ static int sb_parse_line(struct sb_image_ctx *ictx, struct sb_cmd_list *cmd) } cmd->cmd = rptr; + + /* set DISPLAY_PROGRESS flag */ + if (!strcmp(tok, "DISPLAYPROGRESS")) { + ictx->display_progress = 1; + return 0; + } /* DCD */ if (!strcmp(tok, "DCD")) { @@ -1681,10 +1686,10 @@ static int sb_verify_image_header(struct sb_image_ctx *ictx, ntohs(hdr->component_version.minor), ntohs(hdr->component_version.revision)); - if (hdr->flags & ~SB_IMAGE_FLAG_VERBOSE) + if (hdr->flags & ~SB_IMAGE_FLAGS_MASK) ret = -EINVAL; soprintf(ictx, "%s Image flags: %s\n", stat[!!ret], - hdr->flags & SB_IMAGE_FLAG_VERBOSE ? "Verbose_boot" : ""); + hdr->flags & SB_IMAGE_FLAG_DISPLAY_PROGRESS ? "Display_progress" : ""); if (ret) return ret; @@ -2287,7 +2292,6 @@ static int mxsimage_generate(struct image_tool_params *params, ctx.cfg_filename = params->imagename; ctx.output_filename = params->imagefile; - ctx.verbose_boot = 1; ret = sb_build_tree_from_cfg(&ctx); if (ret) diff --git a/tools/mxsimage.h b/tools/mxsimage.h index 6cd59d2..88f72eb 100644 --- a/tools/mxsimage.h +++ b/tools/mxsimage.h @@ -81,8 +81,9 @@ struct sb_boot_image_header { #define SB_VERSION_MAJOR 1 #define SB_VERSION_MINOR 1 -/* Enable to HTLLC verbose boot report. */ -#define SB_IMAGE_FLAG_VERBOSE (1 << 0) +/* Enable to HTLLC boot report. */ +#define SB_IMAGE_FLAG_DISPLAY_PROGRESS (1 << 0) +#define SB_IMAGE_FLAGS_MASK SB_IMAGE_FLAG_DISPLAY_PROGRESS struct sb_key_dictionary_key { /* The CBC-MAC of image and sections header. */ -- 1.8.5.3

3 2

[U-Boot] [PATCH 1/5] arm: socfpga: dts: altr, rst-mgr.h: Move to SPDX license identifiers
by Stefan Roese 20 Nov '14

20 Nov '14

Signed-off-by: Stefan Roese <sr(a)denx.de> Cc: Chin Liang See <clsee(a)altera.com> Cc: Dinh Nguyen <dinguyen(a)altera.com> Cc: Vince Bridgers <vbridger(a)altera.com> Cc: Marek Vasut <marex(a)denx.de> Cc: Pavel Machek <pavel(a)denx.de> --- include/dt-bindings/reset/altr,rst-mgr.h | 9 +-------- 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/include/dt-bindings/reset/altr,rst-mgr.h b/include/dt-bindings/reset/altr,rst-mgr.h index 3f04908..351d8cd 100644 --- a/include/dt-bindings/reset/altr,rst-mgr.h +++ b/include/dt-bindings/reset/altr,rst-mgr.h @@ -1,14 +1,7 @@ /* * Copyright (c) 2014, Steffen Trumtrar <s.trumtrar(a)pengutronix.de> * - * This software is licensed under the terms of the GNU General Public - * License version 2, as published by the Free Software Foundation, and - * may be copied, distributed, and modified under those terms. - * - * 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. + * SPDX-License-Identifier: GPL-2.0 */ #ifndef _DT_BINDINGS_RESET_ALTR_RST_MGR_H -- 2.1.3

3 11

[U-Boot] [PATCH] cmd_fuse: return CMD_RET_FAILURE on error
by Hector Palacios 20 Nov '14

20 Nov '14

Fuse drivers, like the mxs_ocotp.c, may return negative error codes but the commands are not allowed to return negative error codes to the shell, otherwise the following error appears: "exit not allowed from main input shell." Signed-off-by: Hector Palacios <hector.palacios(a)digi.com> --- common/cmd_fuse.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/cmd_fuse.c b/common/cmd_fuse.c index abab9789b0df..d4bc0f6c94a1 100644 --- a/common/cmd_fuse.c +++ b/common/cmd_fuse.c @@ -128,7 +128,7 @@ static int do_fuse(cmd_tbl_t *cmdtp, int flag, int argc, char *const argv[]) err: puts("ERROR\n"); - return ret; + return CMD_RET_FAILURE; } U_BOOT_CMD(

2 1

[U-Boot] [PATCH] usb: ehci: do not set the LSB of Current qTD pointer
by Masahiro Yamada 19 Nov '14

19 Nov '14

According to EHCI specification, the LSB of DWORD 3 of Queue Head (Current qTD Pointer) is not T-bit, but always zero. Signed-off-by: Masahiro Yamada <yamada.m(a)jp.panasonic.com> --- drivers/usb/host/ehci-hcd.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c index c671c72..54e948a 100644 --- a/drivers/usb/host/ehci-hcd.c +++ b/drivers/usb/host/ehci-hcd.c @@ -971,7 +971,6 @@ int usb_lowlevel_init(int index, enum usb_init_type init, void **controller) qh_list->qh_link = cpu_to_hc32((uint32_t)qh_list | QH_LINK_TYPE_QH); qh_list->qh_endpt1 = cpu_to_hc32(QH_ENDPT1_H(1) | QH_ENDPT1_EPS(USB_SPEED_HIGH)); - qh_list->qh_curtd = cpu_to_hc32(QT_NEXT_TERMINATE); qh_list->qh_overlay.qt_next = cpu_to_hc32(QT_NEXT_TERMINATE); qh_list->qh_overlay.qt_altnext = cpu_to_hc32(QT_NEXT_TERMINATE); qh_list->qh_overlay.qt_token = -- 1.9.1

2 1

Re: [U-Boot] u-boot, fsl_espi.c driver
by Joakim Tjernlund 19 Nov '14

19 Nov '14

Ping? Joakim Tjernlund/Transmode wrote on 2014/10/29 19:43:14: > > "Mingkai.Hu(a)freescale.com" <Mingkai.Hu(a)freescale.com> wrote on 2014/10/28 12:17:24: > > > > Hi Joakim and York, > > Hi yourself, been travelling or a few days. > > > > > I apologize for the delayed response and thanks for your catch up, Joakim > > In order to get a higher transfer speed, the eSPI controller was designed to transfer multiple bytes at one transaction which is not comply with the SPI framework and the CS can't be inactive until one transfer finished, so we need to combine the multiple transfers into one transfer, that's the reason why there are more memory copy back and forth. > > hmm, can't make sense of this. If you can memcpy from/to memory you can also write/read the SPI FIFO > Also writing 4 bytes to the SPI FIFO at a time will not but you much if anything at all. It just > makes it impossible to use NF flag etc. > Speed will come from keeping the SPI FIFO non empty and not copying memory back and fourth. > CS can be controlled within the SPI framework already. > > > > > The driver has been tested on SPI flash and the transfer length larger than max_trans_len should be handled but half-duplex > was not handled. Is it possible to provide patch to make it workable for different devices? > > Not as the driver is written today. > > > > > 0x0b is the FAST READ command. The logic here is to move the pointer of receive buffer to receive new data when reading from NOR flash and the reading length is larger than the max_trans_len. > > What FAST READ command? Sounds like it is connected to the FLASH rather than SPI? if so that > need to go from the SPI driver and moved into some board specific addon. > > > > > Thanks, > > Mingkai > > > > ________________________________________ > > From: Sun York-R58495 > > Sent: Thursday, October 23, 2014 6:14 AM > > To: jagan Teki; Hu Mingkai-B21284 > > Cc: Joakim Tjernlund; Hou Zhiqiang-B48286; u-boot(a)lists.denx.de > > Subject: Re: u-boot, fsl_espi.c driver > > > > Jagan and Mingkai, > > > > Would you take a look when you have a chance? > > > > York > > > > > > On 10/22/2014 03:12 PM, Joakim Tjernlund wrote: > > > York Sun <yorksun(a)freescale.com> wrote on 2014/10/09 20:06:31: > > >> > > >> Dear Joakim, > > >> > > >> On 10/09/2014 10:43 AM, Joakim Tjernlund wrote: > > >>> York Sun <yorksun(a)freescale.com> wrote on 2014/10/09 18:25:40: > > >>>> > > >>>> Dear Joakim, > > >>>> > > >>>> Thanks for raising a concern. > > >>>> > > >>>> It's not fair to blame the last person who submitted a patch. We are > > > all > > >>> working > > >>> > > >>> No of course not, I just noticed you guys had been in there and > > > patched up > > >>> some problem > > >>> so I hoped you would be interested to fix the remaining problems. This > > > > > >>> driver should never > > >>> have been committed in the first place. > > >>> > > >>>> to make it better as an opensource comminuty. You have done a good > > > job > > >>> to hack > > >>>> it to work. Would it be nicer if you can submit this or improved > > > patch > > >>> to u-boot > > >>>> community for further review and testing, after putting informing > > > commit > > >>>> message? The mailing list address is CC'ed. > > >>> > > >>> Main problem with this driver is that TX does not work for: > > >>> len > max_tran_len (nor does RX) > > >>> does not TX the last odd bytes(len % 4 != 0) > > >>> Does not work with TX only(RX buf == NULL) > > >>> > > >>> Silently ignores SPI_LSB_FIRST > > >>> > > >>> On top of that it uses malloc all over and copies data back and forth > > > for > > >>> no good > > >>> reason, image a big SPI transfer with many MB(like my FPGA load). > > >>> > > >>> I am not in a good position fix this properly as my FPGA is TX only so > > > I > > >>> cannot test > > >>> RX at all(which is broken by my hack) > > >>> > > >>> Finally, just to illustrate the merits of this driver, after > > > transmission > > >>> is done > > >>> there is: > > >>> if (*buffer == 0x0b) { > > >>> data_in += tran_len; > > >>> data_len -= tran_len; > > >>> *(int *)buffer += tran_len; > > >>> } > > >>> what is the magic 0x0b test all about? > > >>> > > >> > > >> Thanks for the report. Driver maintainer (CC'ed) will take a look. > > >> > > >> York > > > > > > No reaction from maintainers, I don't think this driver is still > > > maintained. > > > > > > Jocke > > >

2 2

[U-Boot] [PATCH v3 1/3] arm: odroid: pmic77686: allow buck voltage settings
by Suriyan Ramasami 19 Nov '14

19 Nov '14

Allow to set the buck voltage for the max77686. This will be used to reset the SMC LAN9730 ethernet on the odroids. Signed-off-by: Suriyan Ramasami <suriyan.r(a)gmail.com> --- Changes in v3: * Correct ldo and buck validation logic * Jaehoon/Przemyslaw - Use negative errno values for error condistions * Albert - its buck not bucket Changes in v2: * Jaehoon - separate out this patch Changes in v1: - First try drivers/power/pmic/pmic_max77686.c | 52 +++++++++++++++++++++++++++++++++++--- include/power/max77686_pmic.h | 3 +++ 2 files changed, 52 insertions(+), 3 deletions(-) diff --git a/drivers/power/pmic/pmic_max77686.c b/drivers/power/pmic/pmic_max77686.c index df1fd91..95b1a57 100644 --- a/drivers/power/pmic/pmic_max77686.c +++ b/drivers/power/pmic/pmic_max77686.c @@ -42,11 +42,30 @@ static unsigned int max77686_ldo_volt2hex(int ldo, ulong uV) return 0; } +static int max77686_buck_volt2hex(int buck, ulong uV) +{ + int hex = 0; + + if (buck < 5 || buck > 9) { + debug("%s: buck %d is not supported\n", __func__, buck); + return -EINVAL; + } + + hex = (uV - 750000) / 50000; + + if (hex >= 0 && hex <= MAX77686_BUCK_VOLT_MAX_HEX) + return hex; + + debug("%s: %ld is wrong voltage value for BUCK%d\n", + __func__, uV, buck); + return -EINVAL; +} + int max77686_set_ldo_voltage(struct pmic *p, int ldo, ulong uV) { unsigned int val, ret, hex, adr; - if (ldo < 1 && ldo > 26) { + if (ldo < 1 || ldo > 26) { printf("%s: %d is wrong ldo number\n", __func__, ldo); return -1; } @@ -68,11 +87,38 @@ int max77686_set_ldo_voltage(struct pmic *p, int ldo, ulong uV) return ret; } +int max77686_set_buck_voltage(struct pmic *p, int buck, ulong uV) +{ + unsigned int val, adr; + int hex, ret; + + if (buck < 5 || buck > 9) { + printf("%s: %d is an unsupported bucket number\n", + __func__, buck); + return -EINVAL; + } + + adr = max77686_buck_addr[buck] + 1; + hex = max77686_buck_volt2hex(buck, uV); + + if (hex < 0) + return hex; + + ret = pmic_reg_read(p, adr, &val); + if (ret) + return ret; + + val &= ~MAX77686_BUCK_VOLT_MASK; + ret |= pmic_reg_write(p, adr, val | hex); + + return ret; +} + int max77686_set_ldo_mode(struct pmic *p, int ldo, char opmode) { unsigned int val, ret, adr, mode; - if (ldo < 1 && 26 < ldo) { + if (ldo < 1 || 26 < ldo) { printf("%s: %d is wrong ldo number\n", __func__, ldo); return -1; } @@ -157,7 +203,7 @@ int max77686_set_buck_mode(struct pmic *p, int buck, char opmode) /* mode */ switch (opmode) { case OPMODE_OFF: - mode = MAX77686_BUCK_MODE_OFF; + mode = MAX77686_BUCK_MODE_OFF << mode_shift; break; case OPMODE_STANDBY: switch (buck) { diff --git a/include/power/max77686_pmic.h b/include/power/max77686_pmic.h index c2a772a..b0e4255 100644 --- a/include/power/max77686_pmic.h +++ b/include/power/max77686_pmic.h @@ -150,6 +150,7 @@ enum { int max77686_set_ldo_voltage(struct pmic *p, int ldo, ulong uV); int max77686_set_ldo_mode(struct pmic *p, int ldo, char opmode); +int max77686_set_buck_voltage(struct pmic *p, int buck, ulong uV); int max77686_set_buck_mode(struct pmic *p, int buck, char opmode); #define MAX77686_LDO_VOLT_MAX_HEX 0x3f @@ -159,6 +160,8 @@ int max77686_set_buck_mode(struct pmic *p, int buck, char opmode); #define MAX77686_LDO_MODE_STANDBY (0x01 << 0x06) #define MAX77686_LDO_MODE_LPM (0x02 << 0x06) #define MAX77686_LDO_MODE_ON (0x03 << 0x06) +#define MAX77686_BUCK_VOLT_MAX_HEX 0x3f +#define MAX77686_BUCK_VOLT_MASK 0x3f #define MAX77686_BUCK_MODE_MASK 0x03 #define MAX77686_BUCK_MODE_SHIFT_1 0x00 #define MAX77686_BUCK_MODE_SHIFT_2 0x04 -- 1.9.1

4 16

[U-Boot] [PATCH 0/3] dm: display devices in a tree-like format for easy debug
by Masahiro Yamada 19 Nov '14

19 Nov '14

When I was reviewing I2C DM series, I found it difficult to track what is going on. "When is this node is bound/probe?" etc. I think this tool is helpful to know which device is bound/probe. Devices are listed like "tree" command does. Masahiro Yamada (3): lib: string: move strlcpy() to a common place dm: add a command to list devices in a tree-like format sandbox: enable showdev command common/Makefile | 1 + common/cmd_showdev.c | 72 ++++++++++++++++++++++++++++++++++++++++++++++ drivers/usb/gadget/ether.c | 24 ---------------- include/configs/sandbox.h | 1 + include/linux/string.h | 3 ++ lib/string.c | 25 ++++++++++++++++ 6 files changed, 102 insertions(+), 24 deletions(-) create mode 100644 common/cmd_showdev.c -- 1.9.1

1 3

[U-Boot] [PATCH v6 0/5] add i.MX6 thermal sensor driver
by nitin.garg＠freescale.com 19 Nov '14

19 Nov '14

From: Nitin Garg <nitin.garg(a)freescale.com> This patch set adds i.MX6 thermal sensor driver and enables it for mx6sabre boards. Also adds various anadig bit definitions as required for upcoming drivers. Changes in v6: -Aligned imx thermal driver macro defines with kernel Changes in v5: -Don't modify the copyright of cpu.c and crm_regs.h file Changes in v4: -Added imx6 thermal sensor as a driver -Renamed the config define to be more meaningful -Move the clock code to clock.c -Reusing ocotp driver for reading fuse -Fix check for calibration fuse not programmed -Aligned the slope computation with kernel -Added Anadig register defines as seperate commit Changes in v3: -adds the mx6 thermal driver support -adds the mx6 thermal support to mx6sabresd board. Changes in v2: -run checkpatch and fix reported issues Nitin Garg (4): mx6: clock: Add api to enable pll3 mx6: thermal: Add i.MX6 CPU thermal sensor support mx6: thermal: Check cpu temperature via thermal sensor mx6: thermal: Enable thermal sensor for mx6 sabre boards. arch/arm/cpu/armv7/mx6/clock.c | 25 ++++++ arch/arm/imx-common/cpu.c | 6 ++ arch/arm/include/asm/arch-mx6/clock.h | 1 + drivers/Makefile | 1 + drivers/thermal/Makefile | 8 ++ drivers/thermal/imx_thermal.c | 144 +++++++++++++++++++++++++++++++++ include/configs/mx6sabre_common.h | 3 +- include/imx_thermal.h | 15 ++++ 8 files changed, 202 insertions(+), 1 deletion(-) create mode 100644 drivers/thermal/Makefile create mode 100644 drivers/thermal/imx_thermal.c create mode 100644 include/imx_thermal.h -- 1.7.9.5

6 10

[U-Boot] [PATCH 1/5] sun6i: Make dram clk and zq value Kconfig options
by Hans de Goede 19 Nov '14

19 Nov '14

It turns out that there is a too large spread between boards to handle this with a default value, turn this into Kconfig options, and set the values the factory images are using for the Colombus and Mele_M9 boards. Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- arch/arm/cpu/armv7/sunxi/dram_sun6i.c | 12 +++++------- board/sunxi/Kconfig | 17 +++++++++++++++++ configs/Colombus_defconfig | 2 ++ configs/Mele_M9_defconfig | 2 ++ 4 files changed, 26 insertions(+), 7 deletions(-) diff --git a/arch/arm/cpu/armv7/sunxi/dram_sun6i.c b/arch/arm/cpu/armv7/sunxi/dram_sun6i.c index 10a6241..30439dc 100644 --- a/arch/arm/cpu/armv7/sunxi/dram_sun6i.c +++ b/arch/arm/cpu/armv7/sunxi/dram_sun6i.c @@ -17,9 +17,7 @@ #include <asm/arch/dram.h> #include <asm/arch/prcm.h> -/* DRAM clk & zq defaults, maybe turn these into Kconfig options ? */ -#define DRAM_CLK_DEFAULT 312000000 -#define DRAM_ZQ_DEFAULT 0x78 +#define DRAM_CLK (CONFIG_DRAM_CLK * 1000000) struct dram_sun6i_para { u8 bus_width; @@ -48,7 +46,7 @@ static void mctl_sys_init(void) (struct sunxi_ccm_reg *)SUNXI_CCM_BASE; const int dram_clk_div = 2; - clock_set_pll5(DRAM_CLK_DEFAULT * dram_clk_div); + clock_set_pll5(DRAM_CLK * dram_clk_div); clrsetbits_le32(&ccm->dram_clk_cfg, CCM_DRAMCLK_CFG_DIV0_MASK, CCM_DRAMCLK_CFG_DIV0(dram_clk_div) | CCM_DRAMCLK_CFG_RST | @@ -173,7 +171,7 @@ static void mctl_channel_init(int ch_index, struct dram_sun6i_para *para) await_completion(&mctl_phy->pgsr, 0x03, 0x03); - writel(DRAM_ZQ_DEFAULT, &mctl_phy->zq0cr1); + writel(CONFIG_DRAM_ZQ, &mctl_phy->zq0cr1); setbits_le32(&mctl_phy->pir, MCTL_PIR_CLEAR_STATUS); writel(MCTL_PIR_STEP1, &mctl_phy->pir); @@ -219,9 +217,9 @@ static void mctl_channel_init(int ch_index, struct dram_sun6i_para *para) await_completion(&mctl_ctl->sstat, 0x07, 0x01); /* Set number of clks per micro-second */ - writel(DRAM_CLK_DEFAULT / 1000000, &mctl_ctl->togcnt1u); + writel(DRAM_CLK / 1000000, &mctl_ctl->togcnt1u); /* Set number of clks per 100 nano-seconds */ - writel(DRAM_CLK_DEFAULT / 10000000, &mctl_ctl->togcnt100n); + writel(DRAM_CLK / 10000000, &mctl_ctl->togcnt100n); /* Set memory timing registers */ writel(MCTL_TREFI, &mctl_ctl->trefi); writel(MCTL_TMRD, &mctl_ctl->tmrd); diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig index 246cd9a..352f04e 100644 --- a/board/sunxi/Kconfig +++ b/board/sunxi/Kconfig @@ -32,6 +32,23 @@ config MACH_SUN8I endchoice +if MACH_SUN6I + +config DRAM_CLK + int "sun6i dram clock speed" if EXPERT + default 312 + ---help--- + Set the dram clock speed, valid range 240 - 480, must be a multiple + of 24. + +config DRAM_ZQ + int "sun6i dram zq value" if EXPERT + default 123 + ---help--- + Set the dram zq value. + +endif + config SYS_CONFIG_NAME string default "sun4i" if MACH_SUN4I diff --git a/configs/Colombus_defconfig b/configs/Colombus_defconfig index bef568d..5e245a3 100644 --- a/configs/Colombus_defconfig +++ b/configs/Colombus_defconfig @@ -4,3 +4,5 @@ CONFIG_FDTFILE="sun6i-a31-colombus.dtb" +S:CONFIG_ARCH_SUNXI=y +S:CONFIG_MACH_SUN6I=y +S:CONFIG_TARGET_COLOMBUS=y ++S:CONFIG_DRAM_CLK=288 ++S:CONFIG_DRAM_ZQ=379 diff --git a/configs/Mele_M9_defconfig b/configs/Mele_M9_defconfig index f46439f..7e50888 100644 --- a/configs/Mele_M9_defconfig +++ b/configs/Mele_M9_defconfig @@ -5,6 +5,8 @@ CONFIG_FDTFILE="sun6i-a31-m9.dtb" +S:CONFIG_ARCH_SUNXI=y +S:CONFIG_MACH_SUN6I=y +S:CONFIG_TARGET_MELE_M9=y ++S:CONFIG_DRAM_CLK=312 ++S:CONFIG_DRAM_ZQ=120 # Ethernet phy power +S:CONFIG_AXP221_DLDO1_VOLT=3300 # USB hub power -- 2.1.0

2 18

[U-Boot] loadb problem. Hangs on START_CHAR
by bomellberg 19 Nov '14

19 Nov '14

Hi. I'm working on getting u-boot running on a custom board. I am using code from Emcraft as a starting point. The cpu is NXP LPC4337. The board has external SDRAM and SPIFI flash, but no wired network. I can boot u-boot fine, and I can perform some memory operations with md and mw. I can load the Hello World standalone example using loads and run it with go. I cannot use the loadb command though. The transfer hangs at the beginning. Using some crude printing debugging I found that the START_CHAR is not received. >From cmd_load.c: I never get the "S", so the transfer never starts. I have tried Tera Term on Windows and C-Kermit on Linux, using the settings mentioned in the DULG. I have tried two different USB-to-RS232-3.3V dongles. A search in the archives shows a possible explanation in FIFO byte order, but I cannot find a place to alter this. Could it be the FIFO byte order for the UART is important for the kermit transfer, but not for the console? An oscilloscope picture of the kermit transfer's first bytes: <http://u-boot.10912.n7.nabble.com/file/n195144/tek00002.png> It sure looks like a 0x01 as the first byte. But the code doesn't reach the "S" debug. If I send 0x01 using RealTerm, I get the "S" debug. I can't figure this out. Thankful for any help. /Bo -- View this message in context: http://u-boot.10912.n7.nabble.com/loadb-problem-Hangs-on-START-CHAR-tp19514… Sent from the U-Boot mailing list archive at Nabble.com.

2 19