Re: [U-Boot] [RFC PATCH 4/4 v3] mtd: sf: Add CONFIG_SPI_N25Q256A_RESET for software-reset
On 02.10.2014 01:07, Pavel Machek wrote: On Wed 2014-10-01 21:25:12, Stefan Roese wrote: On 01.10.2014 21:04, Jagan Teki wrote: This is needed for the SoCFPGA booting from SPI NOR flash e.g. (N25Q256A). With these changes, the SoCrates can boot and re-boot (reset) from SPI NOR flash without any problems. Seems like your SPI NOR reset logic is buggy. Does any of [1] apply to your board please? [1] http://www.rocketboards.org/foswiki/Documentation/SocBoardQspiBoot Yes. This seems to be that case. But I can't change it right now. So this solution with the soft-reset is better than nothing. If this is some think that must require, any possibility to this resetting prior to u-boot? like preloader or in first stage boot loader or something. Perhaps I was not clear with the intention of this patch. Its more to show how the problem with SPI flash on this platform / board (SoCrates in this case) can be solved. So that others have a reference. Thats why I marked it as RFC. Its not really meant for inclusion into mainline. The real solution is a board rework. If not possible, the preloader should be changed. As I don't have access to the preloader code right now, this solution (I know, its more a hack) didn't seem too bad. For the record, I do not think preloader is good place for such workaround. Preloader works with SDRAM, and should load real u-boot as fast as possible. If it does not need to touch SPI (it does not, right?) it should not need to work around bugs there. In this case, where the board boots from SPI NOR flash, the Preloader (SPL U-Boot version) does use SPI. To load the main U-Boot image from the SPI NOR flash. My current best guess is that this define in the Preloader (older SPL U-Boot version) causes these problems: #define CONFIG_SPI_FLASH_QUAD (1) Once I have full access to the Preloader source (in a few days hopefully) I can verify this. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: mx6: Add support for Kosagi Novena
On 28/09/2014 04:19, Marek Vasut wrote:
On Wednesday, September 24, 2014 at 06:57:06 PM, Sean Cross wrote:
[...]
+#define NOVENA_AUDIO_PWRON IMX_GPIO_NR(5, 17)
+#define NOVENA_HDMI_GHOST_HPD IMX_GPIO_NR(5, 4)
+#define NOVENA_PCIE_RESET_GPIO IMX_GPIO_NR(3, 29)
+#define NOVENA_PCIE_POWER_ON_GPIO IMX_GPIO_NR(7, 12)
+#define NOVENA_PCIE_WAKE_UP_GPIO IMX_GPIO_NR(3, 22)
+#define NOVENA_PCIE_DISABLE_GPIO IMX_GPIO_NR(2, 16)
Add NOVENA_FPGA_RESET_N_GPIO IMX_GPIO_NR(5, 7). If the FPGA has a
program loaded that doesn't let the I2C pins float, then the DDR3 SPD
will be unable to be read.
Added and I am now setting this GPIO to 0 so the FPGA is in reset throughout
the
SPL operation. It can be brought out of reset in U-Boot itself and only when
it's actually used, right ?
Correct. You can leave the FPGA in reset forever. If it is configured
in U-Boot, then it can be brought back out of reset.
+
+ /* UART clocks enabled and gd valid - init serial console */
+ preloader_console_init();
+
+ /* Start the DDR DRAM */
+ mx6dq_dram_iocfg(64, novena_ddr_ioregs, novena_grp_ioregs);
+ mx6_dram_cfg(novena_ddr_info, novena_mmdc_calib, elpida_4gib_1600);
+
+ /* Clear the BSS. */
+ memset(__bss_start, 0, __bss_end - __bss_start);
+
+ /* load/boot image from boot device */
+ board_init_r(NULL, 0);
+}
+
+void reset_cpu(ulong addr)
+{
+}
[...]
We just received final boards on Monday. I will try this out and report
back.
You should try one of the never patches .
I have built it and gotten it working on Novena. A few notes:
USB works, but appears to take a very long time to enumerate. I suspect
one of the hubs is still in reset. It finds the Asix Ethernet device,
but doesn't find a USB keyboard I have plugged in. Instead, running
usb start gives EHCI timed out on TD - token=0x80008c80, and the
keyboard shows up as Hub (12 Mb/s, 40mA) -- Lite-On Tech USB 1.1 2 port
downstream low-p.
The Ethernet address is obtained correctly from the EEPROM.
HDMI works.
SATA works.
FEC Ethernet can get an IP address.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RESEND] vf610twr: Tune DDR initialization settings
Am 2014-09-09 17:19, schrieb Stefano Babic: Hi Stefan, Albert, On 09/09/2014 17:14, Stefan Agner wrote: Hi Albert, The RESEND version of the patch is actually an updated version (maybe I should have increased the version number?) For me, that patch applies cleanly on U-Boot master 0b703dbcee7103f07804d0a4328d1593355c4324 patman: Fix detection of git version Also I tested on U-Boot ARM master and next branch, applies without errors for me. I have tried myself and I can confirm that patch can be applied fine. Albert, should I apply it to u-boot-imx (vf610twr is part of iMX) and then send it in my next PR ? I guess this would be the correct path to go. Any chance this still makes into 2014.10? -- Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: Add support for the Mele M3 board
On Wed, 2014-10-01 at 16:23 +0200, Hans de Goede wrote: The Mele M3 is yet another Allwinnner based Android top set box from Mele. It uses a housing similar to the A2000, but without the USM sata storage slot at the top. It features an A20 SoC, 1G RAM, 4G eMMC (unique for Allwinner devices), 100Mbit ethernet, HDMI out, 3 USB A receptacles, VGA, and A/V OUT connections. Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Ian Campbell i...@hellion.org.uk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please sync u-boot-arm/master with u-boot/master
Hi Masahiro, On Thu, 02 Oct 2014 12:53:05 +0900, Masahiro Yamada yamad...@jp.panasonic.com wrote: Ping? Albert, u-boot-arm/master is more than ten days old. I need to prepare my pull-request based on the latest commit. So, please update your repository. You do not need me to merge u-boot/master in order to send out your pull req; whatever mainline commit you need will be listed automatically (and I will have a choice of either merging u-boot/master before or after I pull your PR). In fact, I much prefer you to just build your branches (master or next) and make them available, then send a PR even though it needs ARM to pull from some other repo (be it mainline or another one). This way, Ican look at your branches and see directly what I will pull, and I can decide in which order I want to do it. So just send out your PR against u-boot-arm/master when you have it ready (make sure it is on your 'master' branch, though, because when I see a PR from a 'next' branch shorty before a release, I tend to either postpone it or pull it into my next branch). If you feel you need to call my attention to anything related to your PR, including dependency to some mainline commit not yet in ARM, then add this as a comment in the PR. Thanks, Masahiro Yamada Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] UBI issues on SAMA5D31 NOR flash
Hello Heiko, UBI error: vtbl_check: reserved_pebs 81, ubi-good_peb_count 80 UBI error: vtbl_check: too large reserved_pebs, good PEBs 80 Use of UBI is new to me so where are the PEBs configured? Good question ... looking into vtbl_check(), the reserved_pebs value is read from the record in the volume table: reserved_pebs = be32_to_cpu(vtbl[i].reserved_pebs); @reserved_pebs: how many physical eraseblocks are reserved for this volume I have changed the size of the partition as defined in U-Boot and also reduced the maximum image size when creating the UBI image and have found a combination that moves me on to the next error: U-Boot ubi part rootfs UBI: attaching mtd2 to ubi0 UBI: physical eraseblock size: 131072 bytes (128 KiB) UBI: logical eraseblock size:130944 bytes UBI: smallest flash I/O unit:1 UBI: VID header offset: 64 (aligned 64) UBI: data offset:128 - Warning: 1 protected sectors will not be erased! - Warning: 1 protected sectors will not be erased! - Warning: 1 protected sectors will not be erased! - Warning: 1 protected sectors will not be erased! - Warning: 1 protected sectors will not be erased! - Warning: 1 protected sectors will not be erased! - Warning: 1 protected sectors will not be erased! - Warning: 1 protected sectors will not be erased! - Warning: 1 protected sectors will not be erased! - Warning: 1 protected sectors will not be erased! - Warning: 1 protected sectors will not be erased! - Warning: 1 protected sectors will not be erased! - Warning: 1 protected sectors will not be erased! - Warning: 1 protected sectors will not be erased! - Warning: 1 protected sectors will not be erased! - Warning: 1 protected sectors will not be erased! - Warning: 1 protected sectors will not be erased! UBI error: ubi_io_write: error -5 while writing 64 bytes to PEB 0:0, written 0 bytes UBI error: erase_worker: failed to erase PEB 0, error -5 UBI error: erase_worker: bad physical eraseblock 0 detected UBI warning: ubi_ro_mode: switch to read-only mode UBI error: do_work: work failed with error code -5 UBI error: autoresize: cannot auto-resize volume 0 UBI error: ubi_init: cannot attach mtd2 UBI error: ubi_init: UBI error: cannot initialize UBI, error -30 UBI init error 30 Hopefully this may be the last hurdle to overcome but somehow I think maybe not! Regards, Andy. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please sync u-boot-arm/master with u-boot/master
On Thu, 2 Oct 2014 09:35:02 +0200, Albert ARIBAUD
albert.u.b...@aribaud.net wrote:
Hi Masahiro,
On Thu, 02 Oct 2014 12:53:05 +0900, Masahiro Yamada
yamad...@jp.panasonic.com wrote:
Ping?
Albert, u-boot-arm/master is more than ten days old.
I need to prepare my pull-request based on the
latest commit.
So, please update your repository.
Merge of u-boot/master done, fixes cm_fx6, six boards are still failing:
- openrd_{base,client,ultimate}:
u-boot.bin exceeds file size limit:
limit: 393216 bytes
actual: (varies) bytes
excess: (varies) bytes
- tricorder[_flash]
arm-linux-gnueabi-ld.bfd: u-boot-spl section `.u_boot_list'
will not fit in region `.sram'
arm-linux-gnueabi-ld.bfd: region `.sram' overflowed by 116 bytes
- trimslice
board/compulab/common/eeprom.c:37:24: error:
'CONFIG_SYS_I2C_EEPROM_BUS' undeclared (first use in this
function)
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please sync u-boot-arm/master with u-boot/master
Hi Albert,
On Thu, 2 Oct 2014 09:35:02 +0200
Albert ARIBAUD albert.u.b...@aribaud.net wrote:
Hi Masahiro,
On Thu, 02 Oct 2014 12:53:05 +0900, Masahiro Yamada
yamad...@jp.panasonic.com wrote:
Ping?
Albert, u-boot-arm/master is more than ten days old.
I need to prepare my pull-request based on the
latest commit.
So, please update your repository.
You do not need me to merge u-boot/master in order to send out your
pull req; whatever mainline commit you need will be listed
automatically (and I will have a choice of either merging u-boot/master
before or after I pull your PR).
Please teach me a little bit more.
Assme the HEAD of u-boo-arm/master is
commit 2a8c9c86b92a9ccee3c27286de317e19bb0530b3
Let's say I want to apply 7 patches
http://patchwork.ozlabs.org/patch/393819/
http://patchwork.ozlabs.org/patch/393818/
http://patchwork.ozlabs.org/patch/393815/
http://patchwork.ozlabs.org/patch/393875/
http://patchwork.ozlabs.org/patch/393814/
http://patchwork.ozlabs.org/patch/393814/
http://patchwork.ozlabs.org/patch/393813/
and then send a pull request to you.
Those seven patches are not applicable on commit 2a8c9c86b,
because some prerequisite commits are missing.
So, I need to apply them onto commit be9f643ae6aa9044c60fe80e3a2c10be8371c692
(= the HEAD of Tom's repo.)
In this case, how should I generate the pull-req message?
git request-pull be9f643 git://git.denx.de/u-boot-uniphier.git master
Is this OK?
The wiki page (http://www.denx.de/wiki/U-Boot/CustodianGitTrees)
says to do:
git request-pull ${upstream}/master git://git.denx.de/u-boot-${subrepo}.git
master
But
git request-pull 2a8c9c86b git://git.denx.de/u-boot-uniphier.git master
will output a list of too much commits.
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] UBI issues on SAMA5D31 NOR flash
Hello Andy, Am 02.10.2014 10:16, schrieb Andy Pont: Hello Heiko, UBI error: vtbl_check: reserved_pebs 81, ubi-good_peb_count 80 UBI error: vtbl_check: too large reserved_pebs, good PEBs 80 Use of UBI is new to me so where are the PEBs configured? Good question ... looking into vtbl_check(), the reserved_pebs value is read from the record in the volume table: reserved_pebs = be32_to_cpu(vtbl[i].reserved_pebs); @reserved_pebs: how many physical eraseblocks are reserved for this volume I have changed the size of the partition as defined in U-Boot and also reduced the maximum image size when creating the UBI image and have found a combination that moves me on to the next error: U-Boot ubi part rootfs UBI: attaching mtd2 to ubi0 UBI: physical eraseblock size: 131072 bytes (128 KiB) UBI: logical eraseblock size:130944 bytes UBI: smallest flash I/O unit:1 UBI: VID header offset: 64 (aligned 64) UBI: data offset:128 - Warning: 1 protected sectors will not be erased! - Warning: 1 protected sectors will not be erased! - Warning: 1 protected sectors will not be erased! - Warning: 1 protected sectors will not be erased! - Warning: 1 protected sectors will not be erased! - Warning: 1 protected sectors will not be erased! - Warning: 1 protected sectors will not be erased! - Warning: 1 protected sectors will not be erased! - Warning: 1 protected sectors will not be erased! - Warning: 1 protected sectors will not be erased! - Warning: 1 protected sectors will not be erased! - Warning: 1 protected sectors will not be erased! - Warning: 1 protected sectors will not be erased! - Warning: 1 protected sectors will not be erased! - Warning: 1 protected sectors will not be erased! - Warning: 1 protected sectors will not be erased! - Warning: 1 protected sectors will not be erased! UBI error: ubi_io_write: error -5 while writing 64 bytes to PEB 0:0, written 0 bytes What says flinfo ? It seems you have protected sectors on your nor flash ... you must unprotect them before using it ... UBI error: erase_worker: failed to erase PEB 0, error -5 UBI error: erase_worker: bad physical eraseblock 0 detected UBI warning: ubi_ro_mode: switch to read-only mode UBI error: do_work: work failed with error code -5 UBI error: autoresize: cannot auto-resize volume 0 UBI error: ubi_init: cannot attach mtd2 UBI error: ubi_init: UBI error: cannot initialize UBI, error -30 UBI init error 30 Hopefully this may be the last hurdle to overcome but somehow I think maybe not! Cheer up! bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] UBI issues on SAMA5D31 NOR flash
Hello Heiko, What says flinfo ? It seems you have protected sectors on your nor flash ... you must unprotect them before using it ... flinfo says that all sectors are read only as the flash device supports block locking and powers up with all sectors in their locked state. The board configuration file includes CONFIG_SYS_FLASH_PROTECTION in order to allow the protect off command to work prior to manual updates of the flash content. Cheer up! I'll try! :-) Regards, Andy. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] UBI issues on SAMA5D31 NOR flash
Hello Heiko, What says flinfo ? It seems you have protected sectors on your nor flash ... you must unprotect them before using it ... flinfo says that all sectors are read only as the flash device supports block locking and powers up with all sectors in their locked state. The board configuration file includes CONFIG_SYS_FLASH_PROTECTION in order to allow the protect off command to work prior to manual updates of the flash content. Running protect off on the UBI area before ubi part rootfs makes the command work without any issues. Now just have to figure out why the Linux kernel isn't detecting the partition and mounting it... Regards, Andy. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please sync u-boot-arm/master with u-boot/master
Hi Masahiro,
On Thu, 02 Oct 2014 17:33:48 +0900, Masahiro Yamada
yamad...@jp.panasonic.com wrote:
Hi Albert,
On Thu, 2 Oct 2014 09:35:02 +0200
Albert ARIBAUD albert.u.b...@aribaud.net wrote:
Hi Masahiro,
On Thu, 02 Oct 2014 12:53:05 +0900, Masahiro Yamada
yamad...@jp.panasonic.com wrote:
Ping?
Albert, u-boot-arm/master is more than ten days old.
I need to prepare my pull-request based on the
latest commit.
So, please update your repository.
You do not need me to merge u-boot/master in order to send out your
pull req; whatever mainline commit you need will be listed
automatically (and I will have a choice of either merging u-boot/master
before or after I pull your PR).
Please teach me a little bit more.
Assme the HEAD of u-boo-arm/master is
commit 2a8c9c86b92a9ccee3c27286de317e19bb0530b3
Let's say I want to apply 7 patches
http://patchwork.ozlabs.org/patch/393819/
http://patchwork.ozlabs.org/patch/393818/
http://patchwork.ozlabs.org/patch/393815/
http://patchwork.ozlabs.org/patch/393875/
http://patchwork.ozlabs.org/patch/393814/
http://patchwork.ozlabs.org/patch/393814/
http://patchwork.ozlabs.org/patch/393813/
and then send a pull request to you.
Those seven patches are not applicable on commit 2a8c9c86b,
because some prerequisite commits are missing.
So, I need to apply them onto commit be9f643ae6aa9044c60fe80e3a2c10be8371c692
(= the HEAD of Tom's repo.)
In this case, how should I generate the pull-req message?
git request-pull be9f643 git://git.denx.de/u-boot-uniphier.git master
Is this OK?
The wiki page (http://www.denx.de/wiki/U-Boot/CustodianGitTrees)
says to do:
git request-pull ${upstream}/master git://git.denx.de/u-boot-${subrepo}.git
master
But
git request-pull 2a8c9c86b git://git.denx.de/u-boot-uniphier.git master
will output a list of too much commits.
Never mind those additional commits: they are commits from
u-boot/master which are needed by your branch (or more exactly, which
you have based your branch upon) and which are not (yet) in
u-boot-arm/master.
Think of them as the common trunk of commits shared between
u-boot/master and your master branch.
If I apply u-boot/master first, the trunk commits will be pulled in,
and laster, when I apply your branch, the trunk will already be in
place and I4ll only pull your own commits.
OTOH, if I apply your branch first, the trunk commits will be pulled in
just the same; and when later I apply u-boot/master, the trunk commits
will already be in place and I'll only pull that part of u-boot/master
which I don't yet have.
Is this clearer?
Best Regards
Masahiro Yamada
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: set correct block size value in bfin sdh driver
Hi Sonic,
On Aug 6, 2014, at 1:14 PM, Sonic Zhang sonic@gmail.com wrote:
From: Sonic Zhang sonic.zh...@analog.com
Wait data transfer till the data end bit other than the data block end
bit is set.
Signed-off-by: Sonic Zhang sonic.zh...@analog.com
---
drivers/mmc/bfin_sdh.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/bfin_sdh.c b/drivers/mmc/bfin_sdh.c
index bcd6a3e..9bdfbbc 100644
--- a/drivers/mmc/bfin_sdh.c
+++ b/drivers/mmc/bfin_sdh.c
@@ -138,9 +138,9 @@ static int sdh_setup_data(struct mmc *mmc, struct
mmc_data *data)
if (data-flags MMC_DATA_WRITE)
return UNUSABLE_ERR;
#ifndef RSI_BLKSZ
- data_ctl |= ((ffs(data_size) - 1) 4);
+ data_ctl |= ((ffs(data-blocksize) - 1) 4);
#else
- bfin_write_SDH_BLK_SIZE(data_size);
+ bfin_write_SDH_BLK_SIZE(data-blocksize);
#endif
data_ctl |= DTX_DIR;
bfin_write_SDH_DATA_CTL(data_ctl);
@@ -189,7 +189,8 @@ static int bfin_sdh_request(struct mmc *mmc, struct
mmc_cmd *cmd,
do {
udelay(1);
status = bfin_read_SDH_STATUS();
- } while (!(status (DAT_BLK_END | DAT_END | DAT_TIME_OUT |
DAT_CRC_FAIL | RX_OVERRUN)));
+ } while (!(status (DAT_END | DAT_TIME_OUT | DAT_CRC_FAIL |
+ RX_OVERRUN)));
if (status DAT_TIME_OUT) {
bfin_write_SDH_STATUS_CLR(DAT_TIMEOUT_STAT);
--
1.8.2.3
Applied, thanks.
— Pantelis
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please sync u-boot-arm/master with u-boot/master
Hi Albert, On Thu, 2 Oct 2014 11:58:27 +0200 Albert ARIBAUD albert.u.b...@aribaud.net wrote: Never mind those additional commits: they are commits from u-boot/master which are needed by your branch (or more exactly, which you have based your branch upon) and which are not (yet) in u-boot-arm/master. Think of them as the common trunk of commits shared between u-boot/master and your master branch. If I apply u-boot/master first, the trunk commits will be pulled in, and laster, when I apply your branch, the trunk will already be in place and I4ll only pull your own commits. OTOH, if I apply your branch first, the trunk commits will be pulled in just the same; and when later I apply u-boot/master, the trunk commits will already be in place and I'll only pull that part of u-boot/master which I don't yet have. Yup, either will work fine. Is this clearer? Yes, thanks! I wanted to be sure because I am going to send my first pull-req in my entire life. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 08/11] dm: imx: Use gpio_request() to request GPIOs
Hi Simon, On 01/10/14 18:22, Simon Glass wrote: Hi Nikita, On 1 October 2014 05:58, Nikita Kiryanov nik...@compulab.co.il wrote: Hi Simon, On 17/09/14 18:02, Simon Glass wrote: GPIOs should be requested before use. Without this, driver model will not permit the GPIO to be used. Signed-off-by: Simon Glass s...@chromium.org This patch introduces a bunch of errors (once the driver model stuff is turned on), all related to the gpios never being freed, but requested anew when reinitializing subsystems. The errors are: CM-FX6 # sata init Warning: iSSD setup failed! AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl SATA mode flags: ncq stag pm led clo only pmp pio slum part SATA Device Info: S/N: 123900127157 Product model number: SanDisk SSD i100 8GB Firmware version: 11.56.00 Capacity: 15649200 sectors Is it correct to init something twice? Of course. A re-init is a common use case, not just for sata, and anyway the reason for a failed re-init shouldn't be because sata code is preventing itself from utilizing its own GPIOs. It has already been done when U-Boot boots I think. If it is, then are you thinking of changing cm_fx6_setup_issd() to cope with that? Yes. CM-FX6 # usb start (Re)start USB... USB0: USB OTG pwr gpio request failed: -16 USB OTG pwr gpio request failed: -16 USB EHCI 1.00 scanning bus 0 for devices... 2 USB Device(s) found USB1: USB hub rst gpio request failed: -16 USB hub rst gpio request failed: -16 USB EHCI 1.00 scanning bus 1 for devices... 6 USB Device(s) found scanning usb for storage devices... max USB Storage Device reached: 5 stopping 5 Storage Device(s) found CM-FX6 # sf probe mxc_spi: cannot setup gpio -16 SF: Failed to set up slave Failed to initialize SPI flash at 0:0 I took at look at how this works for SPI. The approach of calling a board function to find out the GPIO should go away with driver model - we can use device tree, or platform data if that is not yet available. Also if you change the board code to 'stash' the GPIO and not request it a second time, you will need to do that in every board. It seems better to me to make this change in the driver, at least for SPI. There are benefits to stashing (or a better word would be 'pre-claiming') it in board code. If a gpio is necessary for SPI to work, it is not really meant to be used by other users, even if it's not immediately requested on boot. Pre-claiming it in board code enforces this. board_spi_cs_gpio() was added very recently in commit 155fa9af9. Yes, that is one of my patches :) If you change it so that setup_cs_gpio() remembers the GPIO after calling board_spi_cs_gpio() then we can avoid passing the problem on to boards. I would like to revisit this debate after the SPI driver is converted to driver model. For now I favour the pre-claiming in board code approach. CM-FX6 # saveenv Saving Environment to SPI Flash... mxc_spi: cannot setup gpio -16 SF: Failed to set up slave *** Warning - spi_flash_probe() failed, using default environment Same issue. I am going to submit a modified version of the cm_fx6 patches to address these problems. I think those are already merged - I based my patches on your cm_fx6 patches and there were already in mainline. I was actually referring to a modified version of your patches that touches cm_fx6 code. That is, take your changes as follows: imx: Add error checking to setup_i2c() (sans the issd stuff) dm: imx: Use gpio_request() to request GPIOs (just the i2c-mxv7.c stuff) and add a new patch that refactors cm_fx6 init stuff. -- Regards, Nikita Kiryanov Regards, Simon -- Regards, Nikita Kiryanov ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: fix ERASE_GRP_DEF handling
Hi Hannes, On Aug 12, 2014, at 8:47 AM, Hannes Petermaier hannes.peterma...@br-automation.com wrote: Hi, Hannes. Hi Jaehoon, diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index a26f3ce..52a8e36 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -1010,6 +1010,8 @@ static int mmc_startup(struct mmc *mmc) if (err) return err; + else +ext_csd[EXT_CSD_ERASE_GROUP_DEF] = 1; When is this value read? a few lines above, have a look at line 967: /* check ext_csd version and capacity */ err = mmc_send_ext_csd(mmc, ext_csd); If i'm right, you means that it has to set before comparing with test_csd, right? yes, exactly thats what i mean. It's reasonable, but i'm not sure that hard-coding is right. why not ? we set the bit using mmc_switch, and only after success we alter our internal structure. It is reasonable in this context, but I’m wary of cases where a read would be required in case the write didn’t ‘take’. I’ll apply this for now. Best Regards, Jaehoon Chung best regards, Hannes Regards — Pantelis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] mmc: restore capacity when switching to partition 0
Hi Tom, On Sep 11, 2014, at 8:45 PM, Tom Rini tr...@ti.com wrote: On Tue, Sep 02, 2014 at 06:31:23PM -0500, Peter A. Bigot wrote: The capacity and lba for an MMC device with part_num 0 reflects the whole device. When mmc_switch_part() successfully switches to a partition, the capacity is changed to that partition. As partition 0 does not physically exist, attempts to switch back to the whole device will indicate an error, but the capacity setting for the whole device must still be restored to match the partition. Signed-off-by: Peter A. Bigot p...@pabigot.com Tested-by: Tom Rini tr...@ti.com I’m going to take this in. It’s required to get the bone to boot from a standard MMC and I’d rather not introduce another boneblack variant to get it to boot from MMC. -- Tom Tested-by: Pantelis Antoniou pa...@antoniou-consulting.com Acked-by: Pantelis Antoniou pa...@antoniou-consulting.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] env_mmc: correct fini partition to match init partition
Hi Peter, On Sep 3, 2014, at 8:22 PM, Peter A. Bigot p...@pabigot.com wrote: The code to set the MMC partition uses an weak function to obtain the correct partition number. Use that instead of the compile-time default when deciding whether it needs to switch back. Fixes: 6e7b7df4df43574 (env_mmc: support env partition setup in runtime) Signed-off-by: Peter A. Bigot p...@pabigot.com --- V3: * Add Fixes line as requested V2: * Preserve desired behavior of avoiding diagnostic when no HW partition supported * Supersedes https://patchwork.ozlabs.org/patch/385355/ common/env_mmc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/env_mmc.c b/common/env_mmc.c index a7621a8..14648e3 100644 --- a/common/env_mmc.c +++ b/common/env_mmc.c @@ -113,7 +113,7 @@ static void fini_mmc_for_env(struct mmc *mmc) #ifdef CONFIG_SPL_BUILD dev = 0; #endif - if (CONFIG_SYS_MMC_ENV_PART != mmc-part_num) + if (mmc_get_env_part(mmc) != mmc-part_num) mmc_switch_part(dev, mmc-part_num); #endif } -- 1.8.5.5 Applied, thanks. Acked-by: Pantelis Antoniou pa...@antoniou-consulting.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mvebu_mmc: Driver addition
Hi Mario,
On Aug 25, 2014, at 3:12 PM, Mario Schuknecht
mario.schukne...@dresearch-fe.de wrote:
In function mvebu_mmc_write notice command timeout. It is possible that a
command is done, but a timeout occurred.
Enable timeout in set bus function.
Set window registers. Without that I could not use the driver on a Kirkwood
88F6282 SoC.
Set high capacity and 52MHz driver feature.
Signed-off-by: Mario Schuknecht mario.schukne...@dresearch-fe.de
---
Changes in v2:
- Correct indentation
- Remove unneeded parentheses
- Use correct coding style for multi-line statements
drivers/mmc/mvebu_mmc.c | 62 -
1 file changed, 61 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/mvebu_mmc.c b/drivers/mmc/mvebu_mmc.c
index 9759198..d34e743 100644
--- a/drivers/mmc/mvebu_mmc.c
+++ b/drivers/mmc/mvebu_mmc.c
@@ -17,8 +17,12 @@
#include asm/arch/kirkwood.h
#include mvebu_mmc.h
+DECLARE_GLOBAL_DATA_PTR;
+
#define DRIVER_NAME MVEBU_MMC
+#define MVEBU_TARGET_DRAM 0
+
static void mvebu_mmc_write(u32 offs, u32 val)
{
writel(val, CONFIG_SYS_MMC_BASE + (offs));
@@ -164,6 +168,9 @@ static int mvebu_mmc_send_cmd(struct mmc *mmc, struct
mmc_cmd *cmd,
return TIMEOUT;
}
}
+ if (mvebu_mmc_read(SDIO_ERR_INTR_STATUS)
+ (SDIO_ERR_CMD_TIMEOUT | SDIO_ERR_DATA_TIMEOUT))
+ return TIMEOUT;
/* Handling response */
if (cmd-resp_type MMC_RSP_136) {
@@ -271,6 +278,7 @@ static void mvebu_mmc_set_bus(unsigned int bus)
/* default to maximum timeout */
ctrl_reg |= SDIO_HOST_CTRL_TMOUT(SDIO_HOST_CTRL_TMOUT_MAX);
+ ctrl_reg |= SDIO_HOST_CTRL_TMOUT_EN;
ctrl_reg |= SDIO_HOST_CTRL_PUSH_PULL_EN;
@@ -296,6 +304,55 @@ static void mvebu_mmc_set_ios(struct mmc *mmc)
mvebu_mmc_set_clk(mmc-clock);
}
+/*
+ * Set window register.
+ */
+static void mvebu_window_setup(void)
+{
+ int i;
+
+ for (i = 0; i 4; i++) {
+ mvebu_mmc_write(WINDOW_CTRL(i), 0);
+ mvebu_mmc_write(WINDOW_BASE(i), 0);
+ }
+ for (i = 0; i CONFIG_NR_DRAM_BANKS; i++) {
+ u32 size, base, attrib;
+
+ /* Enable DRAM bank */
+ switch (i) {
+ case 0:
+ attrib = KWCPU_ATTR_DRAM_CS0;
+ break;
+ case 1:
+ attrib = KWCPU_ATTR_DRAM_CS1;
+ break;
+ case 2:
+ attrib = KWCPU_ATTR_DRAM_CS2;
+ break;
+ case 3:
+ attrib = KWCPU_ATTR_DRAM_CS3;
+ break;
+ default:
+ /* invalide bank, disable access */
+ attrib = 0;
+ break;
+ }
+
+ size = gd-bd-bi_dram[i].size;
+ base = gd-bd-bi_dram[i].start;
+ if (size attrib) {
+ mvebu_mmc_write(WINDOW_CTRL(i),
+ MVCPU_WIN_CTRL_DATA(size,
+ MVEBU_TARGET_DRAM,
+ attrib,
+ MVCPU_WIN_ENABLE));
+ } else {
+ mvebu_mmc_write(WINDOW_CTRL(i), MVCPU_WIN_DISABLE);
+ }
+ mvebu_mmc_write(WINDOW_BASE(i), base);
+ }
+}
+
static int mvebu_mmc_initialize(struct mmc *mmc)
{
debug(%s: mvebu_mmc_initialize, DRIVER_NAME);
@@ -322,6 +379,8 @@ static int mvebu_mmc_initialize(struct mmc *mmc)
mvebu_mmc_write(SDIO_NOR_INTR_EN, 0);
mvebu_mmc_write(SDIO_ERR_INTR_EN, 0);
+ mvebu_window_setup();
+
/* SW reset */
mvebu_mmc_write(SDIO_SW_RESET, SDIO_SW_RESET_NOW);
@@ -342,7 +401,8 @@ static struct mmc_config mvebu_mmc_cfg = {
.f_min = MVEBU_MMC_BASE_FAST_CLOCK / MVEBU_MMC_BASE_DIV_MAX,
.f_max = MVEBU_MMC_CLOCKRATE_MAX,
.voltages = MMC_VDD_32_33 | MMC_VDD_33_34,
- .host_caps = MMC_MODE_4BIT | MMC_MODE_HS,
+ .host_caps = MMC_MODE_4BIT | MMC_MODE_HS | MMC_MODE_HC |
+ MMC_MODE_HS_52MHz,
.part_type = PART_TYPE_DOS,
.b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT,
};
--
1.8.4.5
Applied, thanks
Acked-by: Pantelis Antoniou pa...@antoniou-consulting.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: Fix mmc bus width
Hi Mario, On Sep 30, 2014, at 6:04 PM, Mario Schuknecht mario.schukne...@dresearch-fe.de wrote: After setting the bus width, the extended CSD register is read. Some selected fields are compared with previously read extended CSD register fields. In this comparison the EXT_CSD_ERASE_GROUP_DEF field is compared. But this field is previously written under certain circumstances. And then the comparison fails. Only compare read-only fields. Therefore compare field EXT_CSD_HC_WP_GRP_SIZE instead of field EXT_CSD_ERASE_GROUP_DEF. Signed-off-by: Mario Schuknecht mario.schukne...@dresearch-fe.de --- drivers/mmc/mmc.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index a26f3ce..d1faa9f 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -1127,10 +1127,11 @@ static int mmc_startup(struct mmc *mmc) mmc_set_bus_width(mmc, widths[idx]); err = mmc_send_ext_csd(mmc, test_csd); + /* Only compare read only fields */ if (!err ext_csd[EXT_CSD_PARTITIONING_SUPPORT] \ == test_csd[EXT_CSD_PARTITIONING_SUPPORT] - ext_csd[EXT_CSD_ERASE_GROUP_DEF] \ - == test_csd[EXT_CSD_ERASE_GROUP_DEF] \ + ext_csd[EXT_CSD_HC_WP_GRP_SIZE] \ + == test_csd[EXT_CSD_HC_WP_GRP_SIZE] \ ext_csd[EXT_CSD_REV] \ == test_csd[EXT_CSD_REV] ext_csd[EXT_CSD_HC_ERASE_GRP_SIZE] \ -- 1.8.4.5 Applied, thanks. Acked-by: Pantelis Antoniou pa...@antoniou-consulting.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] imx6: add Bachmann OT1200 board
This patch adds support for the OT1200 series of devices. Following components are used in u-boot: + ethernet + i2c + emmc + gpio For more details see README. Changes v1 v2 - make use of enable_cspi_clock(..) - fix usage of OUTPUT_40OHM define - added README Changes v2 v3 - improve spelling in README - added own copy of mx6q_4x_mt41j128.cfg Signed-off-by: Christian Gmeiner christian.gmei...@gmail.com --- arch/arm/Kconfig | 4 + board/bachmann/ot1200/Kconfig | 23 +++ board/bachmann/ot1200/MAINTAINERS | 6 + board/bachmann/ot1200/Makefile | 9 ++ board/bachmann/ot1200/README | 20 +++ board/bachmann/ot1200/mx6q_4x_mt41j128.cfg | 169 +++ board/bachmann/ot1200/ot1200.c | 251 + configs/ot1200_defconfig | 3 + include/configs/ot1200.h | 197 ++ 9 files changed, 682 insertions(+) create mode 100644 board/bachmann/ot1200/Kconfig create mode 100644 board/bachmann/ot1200/MAINTAINERS create mode 100644 board/bachmann/ot1200/Makefile create mode 100644 board/bachmann/ot1200/README create mode 100644 board/bachmann/ot1200/mx6q_4x_mt41j128.cfg create mode 100644 board/bachmann/ot1200/ot1200.c create mode 100644 configs/ot1200_defconfig create mode 100644 include/configs/ot1200.h diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 106aed9..8face21 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -414,6 +414,9 @@ config TARGET_HUMMINGBOARD config TARGET_TQMA6 bool TQ Systems TQMa6 board +config TARGET_OT1200 + bool Bachmann OT1200 + config OMAP34XX bool OMAP34XX SoC @@ -577,6 +580,7 @@ source board/atmel/at91sam9rlek/Kconfig source board/atmel/at91sam9x5ek/Kconfig source board/atmel/sama5d3_xplained/Kconfig source board/atmel/sama5d3xek/Kconfig +source board/bachmann/ot1200/Kconfig source board/balloon3/Kconfig source board/barco/titanium/Kconfig source board/bluegiga/apx4devkit/Kconfig diff --git a/board/bachmann/ot1200/Kconfig b/board/bachmann/ot1200/Kconfig new file mode 100644 index 000..55a825d --- /dev/null +++ b/board/bachmann/ot1200/Kconfig @@ -0,0 +1,23 @@ +if TARGET_OT1200 + +config SYS_CPU + string + default armv7 + +config SYS_BOARD + string + default ot1200 + +config SYS_VENDOR + string + default bachmann + +config SYS_SOC + string + default mx6 + +config SYS_CONFIG_NAME + string + default ot1200 + +endif diff --git a/board/bachmann/ot1200/MAINTAINERS b/board/bachmann/ot1200/MAINTAINERS new file mode 100644 index 000..ad75c24 --- /dev/null +++ b/board/bachmann/ot1200/MAINTAINERS @@ -0,0 +1,6 @@ +BACHMANN ELECTRONIC OT1200 BOARD +M: Christian Gmeiner christian.gmei...@gmail.com +S: Maintained +F: board/bachmann/ot1200 +F: include/configs/ot1200.h +F: configs/ot1200*_defconfig diff --git a/board/bachmann/ot1200/Makefile b/board/bachmann/ot1200/Makefile new file mode 100644 index 000..1bd42e8 --- /dev/null +++ b/board/bachmann/ot1200/Makefile @@ -0,0 +1,9 @@ +# +# Copyright (C) 2012-2013, Guennadi Liakhovetski l...@denx.de +# (C) Copyright 2012-2013 Freescale Semiconductor, Inc. +# Copyright (C) 2013, Boundary Devices i...@boundarydevices.com +# +# SPDX-License-Identifier: GPL-2.0+ +# + +obj-y := ot1200.o diff --git a/board/bachmann/ot1200/README b/board/bachmann/ot1200/README new file mode 100644 index 000..c03d44e --- /dev/null +++ b/board/bachmann/ot1200/README @@ -0,0 +1,20 @@ +U-Boot for the Bachmann electronic GmbH OT1200 devices + +There are two different versions of the base board, which differ +in the way ethernet is done. The variant detection is done during +runtime based on the address of the found phy. + +- mr variant +FEC is connected directly to an ethernet switch (KSZ8895). The ethernet +port is always up and auto-negotiation is not possible. + +- normal variant +FEC is connected to a normal phy and auto-negotiation is possible. + + +The variant name is part of the dtb file name loaded by u-boot. This +make is possible to boot the linux kernel and make use variant specific +devicetree (fixed-phy link). + +In order to support different display resoltuions/sizes the OT1200 devices +are making use of EDID data stored in an i2c EEPROM. diff --git a/board/bachmann/ot1200/mx6q_4x_mt41j128.cfg b/board/bachmann/ot1200/mx6q_4x_mt41j128.cfg new file mode 100644 index 000..bb6c60b --- /dev/null +++ b/board/bachmann/ot1200/mx6q_4x_mt41j128.cfg @@ -0,0 +1,169 @@ +/* + * Copyright (C) 2011 Freescale Semiconductor, Inc. + * Jason Liu r64...@freescale.com + * + * SPDX-License-Identifier:GPL-2.0+ + * + * Refer doc/README.imximage for more details about how-to configure + * and create imximage boot image + * + * The syntax is taken as close as possible with the kwbimage + */ + +/* image version */ +IMAGE_VERSION 2 + +/* + * Boot Device :
Re: [U-Boot] [PATCH v3] imx6: add Bachmann OT1200 board
Hi Christian, On Thu, 2 Oct 2014 13:33:46 +0200 Christian Gmeiner christian.gmei...@gmail.com wrote: --- /dev/null +++ b/board/bachmann/ot1200/Kconfig @@ -0,0 +1,23 @@ +if TARGET_OT1200 + +config SYS_CPU + string + default armv7 + +config SYS_BOARD + string + default ot1200 + +config SYS_VENDOR + string + default bachmann + +config SYS_SOC + string + default mx6 + +config SYS_CONFIG_NAME + string + default ot1200 + The type string is not mandatory since commit 461be2f96e4b87e5065208c6659a47dd0ad9e9f8. You can save 5 lines. Since it is not a big deal, I don't think you have to resend it just for fixing this. (I am just pointing out a minor thing I found by chance.) If you like or you have a chance to send v4 for another fix, I recommend you to drop string. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 09/10] kconfig: move CONFIG_OF_* to Kconfig
Hi. On Fri, 26 Sep 2014 09:49:01 -0400 Tom Rini tr...@ti.com wrote: On Thu, Sep 25, 2014 at 07:44:30AM -0600, Simon Glass wrote: Hi, On 25 September 2014 07:18, Tom Rini tr...@ti.com wrote: On Thu, Sep 25, 2014 at 04:38:09PM +0900, Masahiro Yamada wrote: Hi Simon, On Wed, 24 Sep 2014 17:08:11 -0600 Simon Glass s...@chromium.org wrote: +config OF_EMBED + bool Embedded DTB for DT control + help + If this option is enabled, the device tree will be picked up and + built into the U-Boot image. Can you please add This is suitable for debugging and development only and is not recommended for production devices. Why is CONFIG_OF_EMBED not recommended for production devices? It's kind-of a question for the devicetree folks. The last time (a while back now) I asked for some general advice on how a DT should be shipped with hardware, being able to update the DT without replacing the whole of firmware was seen as a good thing. Combine this with that we should try (yes, we can't today due to incompatible bindings) share the DT between U-Boot and the kernel (or really, U-Boot and anything but again, last I checked the BSD bindings were very very different), embedding doesn't seem good. Addressing the binding differences, it's hard to see what these are right now since the sorting and other churn in the Linux device tree files. I think it would be good to sync the U-Boot files to the Linux ones so we can see what bindings still differ. Yes, agreed. Interesting. If so, u-boot,dm-pre-reloc is a bad idea, isn't it? It seems a really U-Boot-specific property, although I only see it in test/dm/test.dts. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Boot reason in SPL for OMAP4
On Wed, Oct 01, 2014 at 12:13:50PM -0700, Gregoire Gentil wrote: On 10/01/2014 10:34 AM, Tom Rini wrote: On Tue, Sep 30, 2014 at 10:26:08AM -0700, Gregoire Gentil wrote: Hello, In TI x-loader, the boot reason is copied to a scratchpad 0x4A326000 as shown here: https://gitorious.org/x-loader/x-loader/source/HEAD:cpu/omap4/start.S#L102 How can I access the boot reason in u-boot or in the SPL? spl_boot_mode() and spl_boot_device(). Thank you. Yes, I found the calls. My point is that I need the boot_device after SPL and it's not transmitted down the chain. Doing the following reestablishes what the legacy x-loader was doing: *(volatile unsigned int *)(0x4A326000) = spl_boot_device(); I think that it's safe as the SRAM is not used after SPL, It's possibly good enough for your needs, yes. I had toyed with the idea of passing this down more formally and generically but hadn't gotten far. -- 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 v4 9/9] dm: imx: Move cm_fx6 to use driver model for serial and GPIO
Hi Simon, On 02/10/14 04:57, Simon Glass wrote: Now that serial and GPIO are available for iMX.6, move cm_fx6 over as an example. Acked-by: Igor Grinberg grinb...@compulab.co.il Signed-off-by: Simon Glass s...@chromium.org Acked-by: Nikita Kiryanov nik...@compulab.co.il -- Regards, Nikita Kiryanov ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] dm: imx: i2c: Use gpio_request() to request GPIOs
From: Simon Glass s...@chromium.org
GPIOs should be requested before use. Without this, driver model will
not permit the GPIO to be used.
Cc: Igor Grinberg grinb...@compulab.co.il
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Nikita Kiryanov nik...@compulab.co.il
---
arch/arm/imx-common/i2c-mxv7.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/arch/arm/imx-common/i2c-mxv7.c b/arch/arm/imx-common/i2c-mxv7.c
index 70cff5c..34f5387 100644
--- a/arch/arm/imx-common/i2c-mxv7.c
+++ b/arch/arm/imx-common/i2c-mxv7.c
@@ -4,6 +4,7 @@
* SPDX-License-Identifier:GPL-2.0+
*/
#include common.h
+#include malloc.h
#include asm/arch/clock.h
#include asm/arch/imx-regs.h
#include asm/errno.h
@@ -72,10 +73,27 @@ static void * const i2c_bases[] = {
int setup_i2c(unsigned i2c_index, int speed, int slave_addr,
struct i2c_pads_info *p)
{
+ char *name1, *name2;
int ret;
if (i2c_index = ARRAY_SIZE(i2c_bases))
return -EINVAL;
+
+ name1 = malloc(9);
+ name2 = malloc(9);
+ if (!name1 || !name2)
+ return -ENOMEM;
+
+ sprintf(name1, i2c_sda%d, i2c_index);
+ sprintf(name2, i2c_scl%d, i2c_index);
+ ret = gpio_request(p-sda.gp, name1);
+ if (ret)
+ goto err_req1;
+
+ ret = gpio_request(p-scl.gp, name2);
+ if (ret)
+ goto err_req2;
+
/* Enable i2c clock */
ret = enable_i2c_clk(1, i2c_index);
if (ret)
@@ -93,5 +111,12 @@ int setup_i2c(unsigned i2c_index, int speed, int slave_addr,
err_idle:
err_clk:
+ gpio_free(p-scl.gp);
+err_req2:
+ gpio_free(p-sda.gp);
+err_req1:
+ free(name1);
+ free(name2);
+
return ret;
}
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] arm: mx6: cm_fx6: use gpio request
Use gpio_request for all the gpios that are utilized by various
subsystems in cm-fx6, and refactor the relevant init functions
so that all gpios are requested during board_init(), not during
subsystem init, thus avoiding the need to manage gpio ownership
each time a subsystem is initialized.
The new division of labor is:
During board_init() muxes are setup and gpios are requested.
During subsystem init gpios are toggled.
Cc: Igor Grinberg grinb...@compulab.co.il
Cc: Simon Glass s...@chromium.org
Signed-off-by: Nikita Kiryanov nik...@compulab.co.il
---
board/compulab/cm_fx6/cm_fx6.c | 133 +
1 file changed, 94 insertions(+), 39 deletions(-)
diff --git a/board/compulab/cm_fx6/cm_fx6.c b/board/compulab/cm_fx6/cm_fx6.c
index 9c6e686..f0edc8f 100644
--- a/board/compulab/cm_fx6/cm_fx6.c
+++ b/board/compulab/cm_fx6/cm_fx6.c
@@ -69,16 +69,23 @@ static iomux_v3_cfg_t const sata_pads[] = {
IOMUX_PADS(PAD_EIM_BCLK__GPIO6_IO31 | MUX_PAD_CTRL(NO_PAD_CTRL)),
};
-static void cm_fx6_setup_issd(void)
+static int cm_fx6_setup_issd(void)
{
+ int ret, i;
+
SETUP_IOMUX_PADS(sata_pads);
- /* Make sure this gpio has logical 0 value */
- gpio_direction_output(CM_FX6_SATA_PWLOSS_INT, 0);
- udelay(100);
- cm_fx6_sata_power(0);
- mdelay(250);
- cm_fx6_sata_power(1);
+ for (i = 0; i ARRAY_SIZE(cm_fx6_issd_gpios); i++) {
+ ret = gpio_request(cm_fx6_issd_gpios[i], sata);
+ if (ret)
+ return ret;
+ }
+
+ ret = gpio_request(CM_FX6_SATA_PWLOSS_INT, sata_pwloss_int);
+ if (ret)
+ return ret;
+
+ return 0;
}
#define CM_FX6_SATA_INIT_RETRIES 10
@@ -86,7 +93,14 @@ int sata_initialize(void)
{
int err, i;
- cm_fx6_setup_issd();
+ /* Make sure this gpio has logical 0 value */
+ gpio_direction_output(CM_FX6_SATA_PWLOSS_INT, 0);
+ udelay(100);
+
+ cm_fx6_sata_power(0);
+ mdelay(250);
+ cm_fx6_sata_power(1);
+
for (i = 0; i CM_FX6_SATA_INIT_RETRIES; i++) {
err = setup_sata();
if (err) {
@@ -109,6 +123,8 @@ int sata_initialize(void)
return err;
}
+#else
+static int cm_fx6_setup_issd(void) { return 0; }
#endif
#ifdef CONFIG_SYS_I2C_MXC
@@ -177,35 +193,32 @@ static int cm_fx6_setup_i2c(void) { return 0; }
#define WEAK_PULLDOWN (PAD_CTL_PUS_100K_DOWN |\
PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | \
PAD_CTL_HYS | PAD_CTL_SRE_SLOW)
+#define MX6_USBNC_BASEADDR 0x2184800
+#define USBNC_USB_H1_PWR_POL (1 9)
-static int cm_fx6_usb_hub_reset(void)
+static int cm_fx6_setup_usb_host(void)
{
int err;
err = gpio_request(CM_FX6_USB_HUB_RST, usb hub rst);
- if (err) {
- printf(USB hub rst gpio request failed: %d\n, err);
- return -1;
- }
+ if (err)
+ return err;
+ SETUP_IOMUX_PAD(PAD_GPIO_0__USB_H1_PWR | MUX_PAD_CTRL(NO_PAD_CTRL));
SETUP_IOMUX_PAD(PAD_SD3_RST__GPIO7_IO08 | MUX_PAD_CTRL(NO_PAD_CTRL));
- gpio_direction_output(CM_FX6_USB_HUB_RST, 0);
- udelay(10);
- gpio_direction_output(CM_FX6_USB_HUB_RST, 1);
- mdelay(1);
return 0;
}
-static int cm_fx6_init_usb_otg(void)
+static int cm_fx6_setup_usb_otg(void)
{
- int ret;
+ int err;
struct iomuxc *iomux = (struct iomuxc *)IOMUXC_BASE_ADDR;
- ret = gpio_request(SB_FX6_USB_OTG_PWR, usb-pwr);
- if (ret) {
- printf(USB OTG pwr gpio request failed: %d\n, ret);
- return ret;
+ err = gpio_request(SB_FX6_USB_OTG_PWR, usb-pwr);
+ if (err) {
+ printf(USB OTG pwr gpio request failed: %d\n, err);
+ return err;
}
SETUP_IOMUX_PAD(PAD_EIM_D22__GPIO3_IO22 | MUX_PAD_CTRL(NO_PAD_CTRL));
@@ -216,25 +229,27 @@ static int cm_fx6_init_usb_otg(void)
return gpio_direction_output(SB_FX6_USB_OTG_PWR, 0);
}
-#define MX6_USBNC_BASEADDR 0x2184800
-#define USBNC_USB_H1_PWR_POL (1 9)
int board_ehci_hcd_init(int port)
{
+ int ret;
u32 *usbnc_usb_uh1_ctrl = (u32 *)(MX6_USBNC_BASEADDR + 4);
- switch (port) {
- case 0:
- return cm_fx6_init_usb_otg();
- case 1:
- SETUP_IOMUX_PAD(PAD_GPIO_0__USB_H1_PWR |
- MUX_PAD_CTRL(NO_PAD_CTRL));
+ /* Only 1 host controller in use. port 0 is OTG needs no attention */
+ if (port != 1)
+ return 0;
- /* Set PWR polarity to match power switch's enable polarity */
- setbits_le32(usbnc_usb_uh1_ctrl, USBNC_USB_H1_PWR_POL);
- return cm_fx6_usb_hub_reset();
- default:
- break;
- }
+ /* Set PWR polarity to match power switch's enable polarity */
+
Re: [U-Boot] [PATCH v4 6/9] dm: imx: Use gpio_request() to request GPIOs
Hi Simon,
On 02/10/14 04:57, Simon Glass wrote:
GPIOs should be requested before use. Without this, driver model will not
permit the GPIO to be used.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v4:
- Adjust error checking to permit calling gpio_request() multiple times
- Avoid doing low-level SATA init multiple times
- Move SATA changes into this patch
Changes in v3:
- Add a check for the Ethernet gpio_request() also
- Add a comment for the CONFIG_SPL_BUILD #ifdef
- Just warn when one of the board init stages fails
Changes in v2:
- Check return values of gpio_request()
arch/arm/imx-common/i2c-mxv7.c | 24 +
board/compulab/cm_fx6/cm_fx6.c | 61 --
board/compulab/cm_fx6/common.c | 14 +-
3 files changed, 84 insertions(+), 15 deletions(-)
diff --git a/arch/arm/imx-common/i2c-mxv7.c b/arch/arm/imx-common/i2c-mxv7.c
index 70cff5c..aaf6936 100644
--- a/arch/arm/imx-common/i2c-mxv7.c
+++ b/arch/arm/imx-common/i2c-mxv7.c
@@ -4,6 +4,7 @@
* SPDX-License-Identifier: GPL-2.0+
*/
#include common.h
+#include malloc.h
#include asm/arch/clock.h
#include asm/arch/imx-regs.h
#include asm/errno.h
@@ -72,10 +73,26 @@ static void * const i2c_bases[] = {
int setup_i2c(unsigned i2c_index, int speed, int slave_addr,
struct i2c_pads_info *p)
{
+ char *name1, *name2;
int ret;
if (i2c_index = ARRAY_SIZE(i2c_bases))
return -EINVAL;
+
+ name1 = malloc(9);
+ name2 = malloc(9);
+ if (!name1 || !name2)
+ return -ENOMEM;
You have a memory leak here if name1 is allocated but name2 is not.
+ sprintf(name1, i2c_sda%d, i2c_index);
+ sprintf(name2, i2c_scl%d, i2c_index);
+ ret = gpio_request(p-sda.gp, name1);
+ if (ret)
+ goto err_req1;
+
+ ret = gpio_request(p-scl.gp, name2);
+ if (ret)
+ goto err_req2;
+
/* Enable i2c clock */
ret = enable_i2c_clk(1, i2c_index);
if (ret)
@@ -93,5 +110,12 @@ int setup_i2c(unsigned i2c_index, int speed, int slave_addr,
err_idle:
err_clk:
+ gpio_free(p-scl.gp);
+err_req2:
+ gpio_free(p-sda.gp);
+err_req1:
+ free(name1);
+ free(name2);
+
return ret;
}
diff --git a/board/compulab/cm_fx6/cm_fx6.c b/board/compulab/cm_fx6/cm_fx6.c
index 9c6e686..53681d4 100644
--- a/board/compulab/cm_fx6/cm_fx6.c
+++ b/board/compulab/cm_fx6/cm_fx6.c
While this patch addresses the errors I mentioned in V3, I think that
the amount of additional checks this required demonstrates that these
init functions (which can be called multiple times) are not the best
place to do gpio requests.
I'm open to the idea that these requests will be handled by the
respective drivers (where applicable), but until that functionality is
implemented I think it's best to do them in board_init().
I'm attaching 2 patches, which split this patch into two, one for
i2c-mxv7.c, and the other for cm_fx6.c.
--
Regards,
Nikita Kiryanov
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2] Split dm: imx: Use gpio_request() to request GPIOs
This series splits the patch dm: imx: Use gpio_request() to request GPIOs into two patches, one for the i2c-mxv7.c stuff retaining Simon Glass as the author, and the other a rework of cm_fx6 subsystem init functions to accomodate calls to gpio_request(). Cc: Igor Grinberg grinb...@compulab.co.il Cc: Simon Glass s...@chromium.org Nikita Kiryanov (1): arm: mx6: cm_fx6: use gpio request Simon Glass (1): dm: imx: i2c: Use gpio_request() to request GPIOs arch/arm/imx-common/i2c-mxv7.c | 25 board/compulab/cm_fx6/cm_fx6.c | 133 + 2 files changed, 119 insertions(+), 39 deletions(-) -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 1/2] odroid: pmic77686: allow bucket voltage settings
Dear Suriyan,
I will try to test it after the weekend.
I'm working on a PMIC framework V3 with Trats2 as a base and the buck
mode/voltage for Max77686 are yet implemented in my code.
But this is okay because the new driver is fully reworked into new file
and the support to the old PMIC framework will be still keept before
move all the drivers to PMIC v3.
The RFC will send soon.
On 10/02/2014 03:45 PM, Suriyan Ramasami wrote:
Allow to set the bucket voltage for the max77686.
This will be used to reset the SMC LAN9730 ethernet on the odroids.
Signed-off-by: Suriyan Ramasami suriya...@gmail.com
---
drivers/power/pmic/pmic_max77686.c | 48 +-
include/power/max77686_pmic.h | 3 +++
2 files changed, 50 insertions(+), 1 deletion(-)
diff --git a/drivers/power/pmic/pmic_max77686.c
b/drivers/power/pmic/pmic_max77686.c
index df1fd91..1aeadb4 100644
--- a/drivers/power/pmic/pmic_max77686.c
+++ b/drivers/power/pmic/pmic_max77686.c
@@ -42,6 +42,25 @@ static unsigned int max77686_ldo_volt2hex(int ldo, ulong uV)
return 0;
}
+static unsigned int max77686_buck_volt2hex(int buck, ulong uV)
+{
+ unsigned int hex = 0;
+
+ if (buck 5 || buck 9) {
+ debug(%s: buck %d is not supported\n, __func__, buck);
+ return 0;
+ }
+
+ hex = (uV - 75) / 5;
+
+ 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 MAX77686_BUCK_VOLT_MAX_HEX + 1;
+}
+
int max77686_set_ldo_voltage(struct pmic *p, int ldo, ulong uV)
{
unsigned int val, ret, hex, adr;
@@ -68,6 +87,33 @@ 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, ret, hex, adr;
+
+ if (buck 5 buck 9) {
+ printf(%s: %d is an unsupported bucket number\n,
+ __func__, buck);
+ return -1;
+ }
+
+ adr = max77686_buck_addr[buck] + 1;
+ hex = max77686_buck_volt2hex(buck, uV);
+
+ if (hex == MAX77686_BUCK_VOLT_MAX_HEX + 1)
+ return -1;
+
+ ret = pmic_reg_read(p, adr, val);
+ if (ret)
+ return ret;
+
+ val = ~MAX77686_BUCK_VOLT_MASK;
+ val |= hex;
+ ret |= pmic_reg_write(p, adr, val);
+
+ return ret;
+}
+
int max77686_set_ldo_mode(struct pmic *p, int ldo, char opmode)
{
unsigned int val, ret, adr, mode;
@@ -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_MASK0x3f
#define MAX77686_BUCK_MODE_MASK 0x03
#define MAX77686_BUCK_MODE_SHIFT_10x00
#define MAX77686_BUCK_MODE_SHIFT_20x04
Best regards,
--
Przemyslaw Marczak
Samsung RD Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] tegra20: tamonten: Fix the early gpio init
To set gpio during the early init we now need to use
tegra_spl_gpio_direction_output(), copied from seaboard.
Change-Id: Id0aadb17a71b78e75e8c3f8de374102b3eab767b
Signed-off-by: Alban Bedel alban.be...@avionic-design.de
---
board/avionic-design/common/tamonten.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/board/avionic-design/common/tamonten.c
b/board/avionic-design/common/tamonten.c
index 9c86779..ea2425a 100644
--- a/board/avionic-design/common/tamonten.c
+++ b/board/avionic-design/common/tamonten.c
@@ -23,8 +23,10 @@
#ifdef CONFIG_BOARD_EARLY_INIT_F
void gpio_early_init(void)
{
+#ifndef CONFIG_SPL_BUILD
gpio_request(GPIO_PI4, NULL);
- gpio_direction_output(GPIO_PI4, 1);
+#endif
+ tegra_spl_gpio_direction_output(GPIO_PI4, 1);
}
#endif
--
2.1.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] tegra20: display: Add support for flipped panels
Add support for two new panel properties, flip-vertical and
flip-horizontal. If set the display controller will be setup to
correctly flip the image.
Change-Id: I324b5d2b0b7ebbde7e08e5f32509cf101c057c84
Signed-off-by: Alban Bedel alban.be...@avionic-design.de
---
arch/arm/cpu/armv7/tegra20/display.c| 20 ++--
arch/arm/include/asm/arch-tegra20/display.h | 4
2 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/armv7/tegra20/display.c
b/arch/arm/cpu/armv7/tegra20/display.c
index fd77f3f..b332dd4 100644
--- a/arch/arm/cpu/armv7/tegra20/display.c
+++ b/arch/arm/cpu/armv7/tegra20/display.c
@@ -20,6 +20,7 @@ static void update_window(struct dc_ctlr *dc, struct
disp_ctl_win *win)
{
unsigned h_dda, v_dda;
unsigned long val;
+ unsigned x, y;
val = readl(dc-cmd.disp_win_header);
val |= WINDOW_A_SELECT;
@@ -58,11 +59,22 @@ static void update_window(struct dc_ctlr *dc, struct
disp_ctl_win *win)
val = WIN_ENABLE;
if (win-bpp 24)
val |= COLOR_EXPAND;
+ if (win-flip_h)
+ val |= H_DIRECTION;
+ if (win-flip_v)
+ val |= V_DIRECTION;
writel(val, dc-win.win_opt);
+ x = win-x;
+ if (win-flip_h)
+ x += (win-w - 1) * (win-bpp / 8);
+ y = win-y;
+ if (win-flip_v)
+ y += win-h - 1;
+
writel((unsigned long)win-phys_addr, dc-winbuf.start_addr);
- writel(win-x, dc-winbuf.addr_h_offset);
- writel(win-y, dc-winbuf.addr_v_offset);
+ writel(x, dc-winbuf.addr_h_offset);
+ writel(y, dc-winbuf.addr_v_offset);
writel(0xff00, dc-win.blend_nokey);
writel(0xff00, dc-win.blend_1win);
@@ -204,6 +216,8 @@ int setup_window(struct disp_ctl_win *win, struct
fdt_disp_config *config)
win-out_y = 0;
win-out_w = config-width;
win-out_h = config-height;
+ win-flip_h = config-flip_h;
+ win-flip_v = config-flip_v;
win-phys_addr = config-frame_buffer;
win-stride = config-width * (1 config-log2_bpp) / 8;
debug(%s: depth = %d\n, __func__, config-log2_bpp);
@@ -258,6 +272,8 @@ static int tegra_decode_panel(const void *blob, int node,
config-width = fdtdec_get_int(blob, node, xres, -1);
config-height = fdtdec_get_int(blob, node, yres, -1);
+ config-flip_h = fdtdec_get_bool(blob, node, flip-horizontal);
+ config-flip_v = fdtdec_get_bool(blob, node, flip-vertical);
config-pixel_clock = fdtdec_get_int(blob, node, clock, 0);
if (!config-pixel_clock || config-width == -1 ||
config-height == -1) {
diff --git a/arch/arm/include/asm/arch-tegra20/display.h
b/arch/arm/include/asm/arch-tegra20/display.h
index a04c84e..05c7bd5 100644
--- a/arch/arm/include/asm/arch-tegra20/display.h
+++ b/arch/arm/include/asm/arch-tegra20/display.h
@@ -25,6 +25,8 @@ struct disp_ctl_win {
unsignedout_y; /* Top edge of output window (row) */
unsignedout_w; /* Width of output window in pixels */
unsignedout_h; /* Height of output window in pixels */
+ unsignedflip_h; /* Horizontally flip the image */
+ unsignedflip_v; /* Vertically flip the image */
};
#define FDT_LCD_TIMINGS4
@@ -53,6 +55,8 @@ struct fdt_disp_config {
int width; /* width in pixels */
int height; /* height in pixels */
int bpp;/* number of bits per pixel */
+ unsigned flip_h;/* Horizontally flip the image */
+ unsigned flip_v;/* Vertically flip the image */
/*
* log2 of number of bpp, in general, unless it bpp is 24 in which
--
2.1.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: tegra: Use mem size from MC in combination with get_ram_size()
On popular request this now completes the Warren's work started for
TK1:
aeb3fcb35956461077804720b8a252d50758d7e0
In addition to the move of using the Tegra memory controller (MC)
register rather than ODMDATA for T20, T30 and T114 as well it further
uses the generic get_ram_size() function (see common/memsize.c)
supposed to be used in each and every U-Boot portTM. Added benefit is
that it should catch 99% of hardware related (i. e. reliably
reproducible) memory errors as well.
Thoroughly tested on the various Toradex line of Tegra modules
available which unfortunately does not include T114 and T124 (yet at
least) plus on the Jetson TK1.
Based-on-work-by: Stephen Warren swar...@nvidia.com
Based-on-work-by: Tom Warren twar...@nvidia.com
Signed-off-by: Marcel Ziswiler mar...@ziswiler.com
---
arch/arm/cpu/tegra-common/board.c | 64 ++
arch/arm/include/asm/arch-tegra114/mc.h| 37 +
arch/arm/include/asm/arch-tegra114/tegra.h | 1 +
arch/arm/include/asm/arch-tegra20/mc.h | 36 +
arch/arm/include/asm/arch-tegra20/tegra.h | 1 +
arch/arm/include/asm/arch-tegra30/mc.h | 38 ++
arch/arm/include/asm/arch-tegra30/tegra.h | 1 +
7 files changed, 127 insertions(+), 51 deletions(-)
create mode 100644 arch/arm/include/asm/arch-tegra114/mc.h
create mode 100644 arch/arm/include/asm/arch-tegra20/mc.h
create mode 100644 arch/arm/include/asm/arch-tegra30/mc.h
diff --git a/arch/arm/cpu/tegra-common/board.c
b/arch/arm/cpu/tegra-common/board.c
index 433da09..a313061 100644
--- a/arch/arm/cpu/tegra-common/board.c
+++ b/arch/arm/cpu/tegra-common/board.c
@@ -9,6 +9,7 @@
#include asm/io.h
#include asm/arch/clock.h
#include asm/arch/funcmux.h
+#include asm/arch/mc.h
#include asm/arch/tegra.h
#include asm/arch-tegra/board.h
#include asm/arch-tegra/pmc.h
@@ -27,55 +28,6 @@ enum {
UART_COUNT = 5,
};
-#if defined(CONFIG_TEGRA20) || defined(CONFIG_TEGRA30) || \
- defined(CONFIG_TEGRA114)
-/*
- * Boot ROM initializes the odmdata in APBDEV_PMC_SCRATCH20_0,
- * so we are using this value to identify memory size.
- */
-unsigned int query_sdram_size(void)
-{
- struct pmc_ctlr *const pmc = (struct pmc_ctlr *)NV_PA_PMC_BASE;
- u32 reg;
-
- reg = readl(pmc-pmc_scratch20);
- debug(pmc-pmc_scratch20 (ODMData) = 0x%08x\n, reg);
-
-#if defined(CONFIG_TEGRA20)
- /* bits 30:28 in OdmData are used for RAM size on T20 */
- reg = 0x7000;
-
- switch ((reg) 28) {
- case 1:
- return 0x1000; /* 256 MB */
- case 0:
- case 2:
- default:
- return 0x2000; /* 512 MB */
- case 3:
- return 0x4000; /* 1GB */
- }
-#else /* Tegra30/Tegra114 */
- /* bits 31:28 in OdmData are used for RAM size on T30 */
- switch ((reg) 28) {
- case 0:
- case 1:
- default:
- return 0x1000; /* 256 MB */
- case 2:
- return 0x2000; /* 512 MB */
- case 3:
- return 0x3000; /* 768 MB */
- case 4:
- return 0x4000; /* 1GB */
- case 8:
- return 0x7ff0; /* 2GB - 1MB */
- }
-#endif
-}
-#else
-#include asm/arch/mc.h
-
/* Read the RAM size directly from the memory controller */
unsigned int query_sdram_size(void)
{
@@ -83,12 +35,22 @@ unsigned int query_sdram_size(void)
u32 size_mb;
size_mb = readl(mc-mc_emem_cfg);
+#if defined(CONFIG_TEGRA20)
+ debug(mc-mc_emem_cfg (MEM_SIZE_KB) = 0x%08x\n, size_mb);
+ size_mb = get_ram_size((void *)PHYS_SDRAM_1, size_mb * 1024);
+#else
debug(mc-mc_emem_cfg (MEM_SIZE_MB) = 0x%08x\n, size_mb);
+ size_mb = get_ram_size((void *)PHYS_SDRAM_1, size_mb * 1024 * 1024);
+#endif
- return size_mb * 1024 * 1024;
-}
+#if defined(CONFIG_TEGRA30) || defined(CONFIG_TEGRA114)
+ /* External memory limited to 2047 MB due to IROM/HI-VEC */
+ if (size_mb == 0x8000) size_mb -= 0x10;
#endif
+ return size_mb;
+}
+
int dram_init(void)
{
/* We do not initialise DRAM here. We just query the size */
diff --git a/arch/arm/include/asm/arch-tegra114/mc.h
b/arch/arm/include/asm/arch-tegra114/mc.h
new file mode 100644
index 000..044b1e0
--- /dev/null
+++ b/arch/arm/include/asm/arch-tegra114/mc.h
@@ -0,0 +1,37 @@
+/*
+ * (C) Copyright 2014
+ * NVIDIA Corporation www.nvidia.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _TEGRA114_MC_H_
+#define _TEGRA114_MC_H_
+
+/**
+ * Defines the memory controller registers we need/care about
+ */
+struct mc_ctlr {
+ u32 reserved0[4]; /* offset 0x00 - 0x0C */
+ u32 mc_smmu_config; /* offset 0x10 */
+ u32 mc_smmu_tlb_config; /* offset 0x14 */
+ u32 mc_smmu_ptc_config; /* offset 0x18 */
+
Re: [U-Boot] [PATCH] tegra20: tamonten: Fix the early gpio init
On 10/02/2014 09:14 AM, Alban Bedel wrote:
To set gpio during the early init we now need to use
tegra_spl_gpio_direction_output(), copied from seaboard.
Change-Id: Id0aadb17a71b78e75e8c3f8de374102b3eab767b
That shouldn't be present on upstream patches.
Signed-off-by: Alban Bedel alban.be...@avionic-design.de
---
board/avionic-design/common/tamonten.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/board/avionic-design/common/tamonten.c
b/board/avionic-design/common/tamonten.c
index 9c86779..ea2425a 100644
--- a/board/avionic-design/common/tamonten.c
+++ b/board/avionic-design/common/tamonten.c
@@ -23,8 +23,10 @@
#ifdef CONFIG_BOARD_EARLY_INIT_F
void gpio_early_init(void)
{
+#ifndef CONFIG_SPL_BUILD
gpio_request(GPIO_PI4, NULL);
- gpio_direction_output(GPIO_PI4, 1);
+#endif
+ tegra_spl_gpio_direction_output(GPIO_PI4, 1);
}
Surely you only want to call tegra_spl_*() from SPL, and not from
non-SPL code? In other words, don't you need something more like:
#ifdef CONFIG_SPL_BUILD
tegra_spl_gpio_direction_output(GPIO_PI4, 1);
#else
gpio_request(GPIO_PI4, NULL);
gpio_direction_output(GPIO_PI4, 1);
#endif
... although perhaps the SPL and non-SPL code should simply be separated
into separate files, so that there's no need for ifdefs, and it's
obvious if SPL and non-SPL code are duplicating the same work?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-boot] [Patch 0/5] keystone_net: use MDIO bus and eth PHY frameworks
This patch series optimize keystone_net driver to use MDIO bus and eht PHY frameworks. Based on [U-boot] [Patch v2 0/5] keystone2: serdes: add seredes driver https://www.mail-archive.com/u-boot@lists.denx.de/msg148694.html Ivan Khoronzhuk (5): net: phy: print a number of phy that is not found net: keystone_net: use mdio_reset function net: keystone_net: register MDIO bus net: keystone_net: register eth PHYs on MDIO bus net: keystone_net: use general get link function arch/arm/include/asm/ti-common/keystone_net.h | 1 + drivers/net/keystone_net.c| 166 +++--- drivers/net/phy/phy.c | 2 +- include/configs/ks2_evm.h | 3 +- 4 files changed, 76 insertions(+), 96 deletions(-) -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-boot] [Patch 3/5] net: keystone_net: register MDIO bus
Currently MDIO framework is not used to configure Ethernet PHY.
As result some of already implemented functions are duplicated.
So register MDIO bus in order to use it. On that stage it's just
registered, it'll be used as we start to use PHY framework.
Use mdio bus read/write/reset functions in the driver.
Acked-by: Vitaly Andrianov vita...@ti.com
Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
---
drivers/net/keystone_net.c | 93 +++---
1 file changed, 55 insertions(+), 38 deletions(-)
diff --git a/drivers/net/keystone_net.c b/drivers/net/keystone_net.c
index 3f9650c..265530a 100644
--- a/drivers/net/keystone_net.c
+++ b/drivers/net/keystone_net.c
@@ -17,6 +17,7 @@
#include asm/ti-common/keystone_serdes.h
unsigned int emac_open;
+static struct mii_dev *mdio_bus;
static unsigned int sys_has_mdio = 1;
#ifdef KEYSTONE2_EMAC_GIG_ENABLE
@@ -42,10 +43,6 @@ static void keystone2_net_serdes_setup(void);
static int gen_get_link_speed(int phy_addr);
-/* EMAC Addresses */
-static volatile struct mdio_regs *adap_mdio =
- (struct mdio_regs *)EMAC_MDIO_BASE_ADDR;
-
int keystone2_eth_read_mac_addr(struct eth_device *dev)
{
struct eth_priv_t *eth_priv;
@@ -70,64 +67,67 @@ int keystone2_eth_read_mac_addr(struct eth_device *dev)
return 0;
}
-static void keystone2_mdio_reset(void)
+/* MDIO */
+
+static int keystone2_mdio_reset(struct mii_dev *bus)
{
- u_int32_t clkdiv;
+ u_int32_t clkdiv;
+ struct mdio_regs *adap_mdio = bus-priv;
clkdiv = (EMAC_MDIO_BUS_FREQ / EMAC_MDIO_CLOCK_FREQ) - 1;
- writel((clkdiv 0x) |
- MDIO_CONTROL_ENABLE |
- MDIO_CONTROL_FAULT |
- MDIO_CONTROL_FAULT_ENABLE,
+ writel((clkdiv 0x) | MDIO_CONTROL_ENABLE |
+ MDIO_CONTROL_FAULT | MDIO_CONTROL_FAULT_ENABLE,
adap_mdio-control);
while (readl(adap_mdio-control) MDIO_CONTROL_IDLE)
;
+
+ return 0;
}
-/* Read a PHY register via MDIO inteface. Returns 1 on success, 0 otherwise */
-int keystone2_eth_phy_read(u_int8_t phy_addr, u_int8_t reg_num, u_int16_t
*data)
+/**
+ * keystone2_mdio_read - read a PHY register via MDIO interface.
+ * Blocks until operation is complete.
+ */
+static int keystone2_mdio_read(struct mii_dev *bus,
+ int addr, int devad, int reg)
{
- int tmp;
+ int tmp;
+ struct mdio_regs *adap_mdio = bus-priv;
while (readl(adap_mdio-useraccess0) MDIO_USERACCESS0_GO)
;
- writel(MDIO_USERACCESS0_GO |
- MDIO_USERACCESS0_WRITE_READ |
- ((reg_num 0x1f) 21) |
- ((phy_addr 0x1f) 16),
+ writel(MDIO_USERACCESS0_GO | MDIO_USERACCESS0_WRITE_READ |
+ ((reg 0x1f) 21) | ((addr 0x1f) 16),
adap_mdio-useraccess0);
/* Wait for command to complete */
while ((tmp = readl(adap_mdio-useraccess0)) MDIO_USERACCESS0_GO)
;
- if (tmp MDIO_USERACCESS0_ACK) {
- *data = tmp 0x;
- return 0;
- }
+ if (tmp MDIO_USERACCESS0_ACK)
+ return tmp 0x;
- *data = -1;
return -1;
}
-/*
- * Write to a PHY register via MDIO inteface.
+/**
+ * keystone2_mdio_write - write to a PHY register via MDIO interface.
* Blocks until operation is complete.
*/
-int keystone2_eth_phy_write(u_int8_t phy_addr, u_int8_t reg_num, u_int16_t
data)
+static int keystone2_mdio_write(struct mii_dev *bus,
+ int addr, int devad, int reg, u16 val)
{
+ struct mdio_regs *adap_mdio = bus-priv;
+
while (readl(adap_mdio-useraccess0) MDIO_USERACCESS0_GO)
;
- writel(MDIO_USERACCESS0_GO |
- MDIO_USERACCESS0_WRITE_WRITE |
- ((reg_num 0x1f) 21) |
- ((phy_addr 0x1f) 16) |
- (data 0x),
- adap_mdio-useraccess0);
+ writel(MDIO_USERACCESS0_GO | MDIO_USERACCESS0_WRITE_WRITE |
+ ((reg 0x1f) 21) | ((addr 0x1f) 16) |
+ (val 0x), adap_mdio-useraccess0);
/* Wait for command to complete */
while (readl(adap_mdio-useraccess0) MDIO_USERACCESS0_GO)
@@ -139,12 +139,12 @@ int keystone2_eth_phy_write(u_int8_t phy_addr, u_int8_t
reg_num, u_int16_t data)
/* PHY functions for a generic PHY */
static int gen_get_link_speed(int phy_addr)
{
- u_int16_t tmp;
+ u_int16_t tmp;
- if ((!keystone2_eth_phy_read(phy_addr, MII_STATUS_REG, tmp))
- (tmp 0x04)) {
+ tmp = mdio_bus-read(mdio_bus, phy_addr,
+MDIO_DEVAD_NONE, MII_STATUS_REG);
+ if (tmp 0x04)
return 0;
- }
return -1;
}
@@ -156,8 +156,10 @@ static void __attribute__((unused))
struct eth_priv_t *eth_priv = (struct eth_priv_t
[U-Boot] [U-boot] [Patch 5/5] net: keystone_net: use general get link function
The phy framework has function to get link, so use it
instead of own implementation.
There is no reason to check SGMII link while sending each
packet, phy link is enough. Check SGMII link only while
ethernet open.
Acked-by: Vitaly Andrianov vita...@ti.com
Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
---
drivers/net/keystone_net.c | 50 +-
include/configs/ks2_evm.h | 1 -
2 files changed, 5 insertions(+), 46 deletions(-)
diff --git a/drivers/net/keystone_net.c b/drivers/net/keystone_net.c
index c5eb243..8348a91 100644
--- a/drivers/net/keystone_net.c
+++ b/drivers/net/keystone_net.c
@@ -42,8 +42,6 @@ struct rx_buff_desc net_rx_buffs = {
static void keystone2_net_serdes_setup(void);
-static int gen_get_link_speed(int phy_addr);
-
int keystone2_eth_read_mac_addr(struct eth_device *dev)
{
struct eth_priv_t *eth_priv;
@@ -137,19 +135,6 @@ static int keystone2_mdio_write(struct mii_dev *bus,
return 0;
}
-/* PHY functions for a generic PHY */
-static int gen_get_link_speed(int phy_addr)
-{
- u_int16_t tmp;
-
- tmp = mdio_bus-read(mdio_bus, phy_addr,
-MDIO_DEVAD_NONE, MII_STATUS_REG);
- if (tmp 0x04)
- return 0;
-
- return -1;
-}
-
static void __attribute__((unused))
keystone2_eth_gigabit_enable(struct eth_device *dev)
{
@@ -180,35 +165,8 @@ int keystone_sgmii_link_status(int port)
status = __raw_readl(SGMII_STATUS_REG(port));
- return status SGMII_REG_STATUS_LINK;
-}
-
-
-int keystone_get_link_status(struct eth_device *dev)
-{
- struct eth_priv_t *eth_priv = (struct eth_priv_t *)dev-priv;
- int sgmii_link;
- int link_state = 0;
-#if CONFIG_GET_LINK_STATUS_ATTEMPTS 1
- int j;
-
- for (j = 0; (j CONFIG_GET_LINK_STATUS_ATTEMPTS) (link_state == 0);
-j++) {
-#endif
- sgmii_link =
- keystone_sgmii_link_status(eth_priv-slave_port - 1);
-
- if (sgmii_link) {
- link_state = 1;
-
- if (eth_priv-sgmii_link_type == SGMII_LINK_MAC_PHY)
- if (gen_get_link_speed(eth_priv-phy_addr))
- link_state = 0;
- }
-#if CONFIG_GET_LINK_STATUS_ATTEMPTS 1
- }
-#endif
- return link_state;
+ return (status SGMII_REG_STATUS_LOCK)
+ (status SGMII_REG_STATUS_LINK);
}
int keystone_sgmii_config(int port, int interface)
@@ -490,8 +448,10 @@ static int keystone2_eth_send_packet(struct eth_device
*dev,
{
int ret_status = -1;
struct eth_priv_t *eth_priv = (struct eth_priv_t *)dev-priv;
+ struct phy_device *phy_dev = eth_priv-phy_dev;
- if (keystone_get_link_status(dev) == 0)
+ genphy_update_link(phy_dev);
+ if (phy_dev-link == 0)
return -1;
if (cpmac_drv_send((u32 *)packet, length, eth_priv-slave_port) != 0)
diff --git a/include/configs/ks2_evm.h b/include/configs/ks2_evm.h
index 8d02d18..dcce7c3 100644
--- a/include/configs/ks2_evm.h
+++ b/include/configs/ks2_evm.h
@@ -103,7 +103,6 @@
#define CONFIG_BOOTP_SEND_HOSTNAME
#define CONFIG_NET_RETRY_COUNT 32
#define CONFIG_NET_MULTI
-#define CONFIG_GET_LINK_STATUS_ATTEMPTS5
#define CONFIG_SYS_SGMII_REFCLK_MHZ312
#define CONFIG_SYS_SGMII_LINERATE_MHZ 1250
#define CONFIG_SYS_SGMII_RATESCALE 2
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-boot] [Patch 1/5] net: phy: print a number of phy that is not found
In case when several Ethernet ports are supported it's convenient to see the number of phy that is not found. Acked-by: Vitaly Andrianov vita...@ti.com Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com --- drivers/net/phy/phy.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c index 1d6c14f..99b0b83 100644 --- a/drivers/net/phy/phy.c +++ b/drivers/net/phy/phy.c @@ -648,7 +648,7 @@ static struct phy_device *get_phy_device_by_mask(struct mii_dev *bus, if (phydev) return phydev; } - printf(Phy not found\n); + printf(Phy %d not found\n, ffs(phy_mask) - 1); return phy_device_create(bus, ffs(phy_mask) - 1, 0x, interface); } -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-boot] [Patch 4/5] net: keystone_net: register eth PHYs on MDIO bus
As MDIO bus has been added we can register PHYs with it.
After registration, the PHY driver will be probed according to the
hardware on board.
Startup PHY at the ethernet open.
Use phy_startup() instead of keystone_get_link_status() when eth open,
as it verifies PHY link inside and SGMII link is checked before.
Acked-by: Vitaly Andrianov vita...@ti.com
Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
---
arch/arm/include/asm/ti-common/keystone_net.h | 1 +
drivers/net/keystone_net.c| 19 ---
include/configs/ks2_evm.h | 2 ++
3 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/ti-common/keystone_net.h
b/arch/arm/include/asm/ti-common/keystone_net.h
index e56759d..011c03c 100644
--- a/arch/arm/include/asm/ti-common/keystone_net.h
+++ b/arch/arm/include/asm/ti-common/keystone_net.h
@@ -239,6 +239,7 @@ struct eth_priv_t {
int phy_addr;
int slave_port;
int sgmii_link_type;
+ struct phy_device *phy_dev;
};
int keystone2_emac_initialize(struct eth_priv_t *eth_priv);
diff --git a/drivers/net/keystone_net.c b/drivers/net/keystone_net.c
index 265530a..c5eb243 100644
--- a/drivers/net/keystone_net.c
+++ b/drivers/net/keystone_net.c
@@ -10,6 +10,7 @@
#include command.h
#include net.h
+#include phy.h
#include miiphy.h
#include malloc.h
#include asm/ti-common/keystone_nav.h
@@ -398,8 +399,8 @@ int32_t cpmac_drv_send(u32 *buffer, int num_bytes, int
slave_port_num)
/* Eth device open */
static int keystone2_eth_open(struct eth_device *dev, bd_t *bis)
{
- int link;
struct eth_priv_t *eth_priv = (struct eth_priv_t *)dev-priv;
+ struct phy_device *phy_dev = eth_priv-phy_dev;
debug(+ emac_open\n);
@@ -439,8 +440,8 @@ static int keystone2_eth_open(struct eth_device *dev, bd_t
*bis)
if (sys_has_mdio) {
keystone2_mdio_reset(mdio_bus);
- link = keystone_get_link_status(dev);
- if (link == 0) {
+ phy_startup(phy_dev);
+ if (phy_dev-link == 0) {
ksnav_close(netcp_pktdma);
qm_close();
return -1;
@@ -461,6 +462,9 @@ static int keystone2_eth_open(struct eth_device *dev, bd_t
*bis)
/* Eth device close */
void keystone2_eth_close(struct eth_device *dev)
{
+ struct eth_priv_t *eth_priv = (struct eth_priv_t *)dev-priv;
+ struct phy_device *phy_dev = eth_priv-phy_dev;
+
debug(+ emac_close\n);
if (!emac_open)
@@ -470,6 +474,7 @@ void keystone2_eth_close(struct eth_device *dev)
ksnav_close(netcp_pktdma);
qm_close();
+ phy_shutdown(phy_dev);
emac_open = 0;
@@ -522,6 +527,7 @@ int keystone2_emac_initialize(struct eth_priv_t *eth_priv)
{
int res;
struct eth_device *dev;
+ struct phy_device *phy_dev;
dev = malloc(sizeof(struct eth_device));
if (dev == NULL)
@@ -556,6 +562,13 @@ int keystone2_emac_initialize(struct eth_priv_t *eth_priv)
return res;
}
+ /* Create phy device and bind it with driver */
+ phy_dev = phy_connect(mdio_bus, eth_priv-phy_addr,
+ dev, PHY_INTERFACE_MODE_SGMII);
+
+ eth_priv-phy_dev = phy_dev;
+ phy_config(phy_dev);
+
return 0;
}
diff --git a/include/configs/ks2_evm.h b/include/configs/ks2_evm.h
index 7fbb648..8d02d18 100644
--- a/include/configs/ks2_evm.h
+++ b/include/configs/ks2_evm.h
@@ -94,6 +94,8 @@
#define CONFIG_SYS_SPI2_NUM_CS 4
/* Network Configuration */
+#define CONFIG_PHYLIB
+#define CONFIG_PHY_MARVELL
#define CONFIG_MII
#define CONFIG_BOOTP_DEFAULT
#define CONFIG_BOOTP_DNS
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-boot] [Patch 2/5] net: keystone_net: use mdio_reset function
Don't use mdio_enable twice while eth open. Also rename it to
keystone2_mdio_reset as more appropriate name.
Acked-by: Vitaly Andrianov vita...@ti.com
Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
---
drivers/net/keystone_net.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/net/keystone_net.c b/drivers/net/keystone_net.c
index 8a45fbd..3f9650c 100644
--- a/drivers/net/keystone_net.c
+++ b/drivers/net/keystone_net.c
@@ -38,7 +38,6 @@ struct rx_buff_desc net_rx_buffs = {
.rx_flow= 22,
};
-static void keystone2_eth_mdio_enable(void);
static void keystone2_net_serdes_setup(void);
static int gen_get_link_speed(int phy_addr);
@@ -71,7 +70,7 @@ int keystone2_eth_read_mac_addr(struct eth_device *dev)
return 0;
}
-static void keystone2_eth_mdio_enable(void)
+static void keystone2_mdio_reset(void)
{
u_int32_t clkdiv;
@@ -397,7 +396,6 @@ int32_t cpmac_drv_send(u32 *buffer, int num_bytes, int
slave_port_num)
/* Eth device open */
static int keystone2_eth_open(struct eth_device *dev, bd_t *bis)
{
- u_int32_t clkdiv;
int link;
struct eth_priv_t *eth_priv = (struct eth_priv_t *)dev-priv;
@@ -410,9 +408,6 @@ static int keystone2_eth_open(struct eth_device *dev, bd_t
*bis)
keystone2_net_serdes_setup();
- if (sys_has_mdio)
- keystone2_eth_mdio_enable();
-
keystone_sgmii_config(eth_priv-slave_port - 1,
eth_priv-sgmii_link_type);
@@ -440,14 +435,7 @@ static int keystone2_eth_open(struct eth_device *dev, bd_t
*bis)
hw_config_streaming_switch();
if (sys_has_mdio) {
- /* Init MDIO get link state */
- clkdiv = (EMAC_MDIO_BUS_FREQ / EMAC_MDIO_CLOCK_FREQ) - 1;
- writel((clkdiv 0xff) | MDIO_CONTROL_ENABLE |
- MDIO_CONTROL_FAULT, adap_mdio-control)
- ;
-
- /* We need to wait for MDIO to start */
- udelay(1000);
+ keystone2_mdio_reset();
link = keystone_get_link_status(dev);
if (link == 0) {
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 08/11] dm: imx: Use gpio_request() to request GPIOs
Hi Nikita, On 2 October 2014 04:28, Nikita Kiryanov nik...@compulab.co.il wrote: Hi Simon, On 01/10/14 18:22, Simon Glass wrote: Hi Nikita, On 1 October 2014 05:58, Nikita Kiryanov nik...@compulab.co.il wrote: Hi Simon, On 17/09/14 18:02, Simon Glass wrote: GPIOs should be requested before use. Without this, driver model will not permit the GPIO to be used. Signed-off-by: Simon Glass s...@chromium.org This patch introduces a bunch of errors (once the driver model stuff is turned on), all related to the gpios never being freed, but requested anew when reinitializing subsystems. The errors are: CM-FX6 # sata init Warning: iSSD setup failed! AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl SATA mode flags: ncq stag pm led clo only pmp pio slum part SATA Device Info: S/N: 123900127157 Product model number: SanDisk SSD i100 8GB Firmware version: 11.56.00 Capacity: 15649200 sectors Is it correct to init something twice? Of course. A re-init is a common use case, not just for sata, and anyway the reason for a failed re-init shouldn't be because sata code is preventing itself from utilizing its own GPIOs. Yes, it needs to handle re-init, not just init. It has already been done when U-Boot boots I think. If it is, then are you thinking of changing cm_fx6_setup_issd() to cope with that? Yes. CM-FX6 # usb start (Re)start USB... USB0: USB OTG pwr gpio request failed: -16 USB OTG pwr gpio request failed: -16 USB EHCI 1.00 scanning bus 0 for devices... 2 USB Device(s) found USB1: USB hub rst gpio request failed: -16 USB hub rst gpio request failed: -16 USB EHCI 1.00 scanning bus 1 for devices... 6 USB Device(s) found scanning usb for storage devices... max USB Storage Device reached: 5 stopping 5 Storage Device(s) found CM-FX6 # sf probe mxc_spi: cannot setup gpio -16 SF: Failed to set up slave Failed to initialize SPI flash at 0:0 I took at look at how this works for SPI. The approach of calling a board function to find out the GPIO should go away with driver model - we can use device tree, or platform data if that is not yet available. Also if you change the board code to 'stash' the GPIO and not request it a second time, you will need to do that in every board. It seems better to me to make this change in the driver, at least for SPI. There are benefits to stashing (or a better word would be 'pre-claiming') it in board code. If a gpio is necessary for SPI to work, it is not really meant to be used by other users, even if it's not immediately requested on boot. Pre-claiming it in board code enforces this. But my stash idea was not a good one as I mentioned in the other thread. I've thought about that quite a lot as part of the driver model work. Claiming GPIOs in board code doesn't feel right to me: 1. If using device tree, the GPIOs are in there, and it means the board code needs to go looking there as well as the driver. The board code actually needs to sniff around in the driver's device tree nodes. That just seems honky. 2. In the driver model world, we hope that board init will fade away to a large extent. Certainly it should be possible to specify most of what a driver needs in device tree or platform data. Getting rid of the explicit init calls in U-Boot (board_init_f(), board_init(), board_late_init(), board_early_init_f(), ...) is a nice effect of driver model I hope. 3. Even if not using device tree, and using platform data, where the board code may specify the platform data, it still feels honky for the board to be parsing its own data (designed for use by the driver) to claim GPIOs. 4. I don't really see why pre-claiming enforces anything. If two subsystems claim the same GPIO you are going to get an error somewhere in any case. 5. If you look at the calls that drivers make to find out information from the board file, or perform some init (mmc does this, USB, ethernet, etc.) it is mostly because the driver has no idea of the specifics of the board. Device tree and platform data fix exactly this problem. The driver has the best idea of when it needs to start up, when it needs this resource of that. In some cases the driver have the ability to operate in two modes (e.g. 4 bit or 8 bit SDIO, UART with/without flow control) and this means the init depends on the driver's mode. board_spi_cs_gpio() was added very recently in commit 155fa9af9. Yes, that is one of my patches :) If you change it so that setup_cs_gpio() remembers the GPIO after calling board_spi_cs_gpio() then we can avoid passing the problem on to boards. I would like to revisit this debate after the SPI driver is converted to driver model. For now I favour the pre-claiming in board code approach. OK, but see above. I feel this is going in the wrong direction for driver model at least. Are you interested in converting the SPI driver? CM-FX6 # saveenv Saving Environment to SPI Flash... mxc_spi: cannot setup gpio -16
Re: [U-Boot] Call for participation in the U-Boot Mini Summit 2014
Hi Alexey, thanks a lot for your willingness to do the presentation at the mini summit. As I personally thik your talk fits our agenda pretty well and nobody has said anything different, it is therefore accepted. Currently I plan for 20 minutes / 10 minutes QA slots, would this be ok for your talk also? Do you guys want to get my presentation beforehand or I may just bring it with me? It would be good to send a copy of the presentation beforehand just in case something breaks. Believe me - _something_ will ;) Cheers Detlev -- It's nice that the students coming to us already know Java. We just have to teach them how to program. -- Michael Sperber -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 6/9] dm: imx: Use gpio_request() to request GPIOs
Hi Nikita,
On 2 October 2014 08:18, Nikita Kiryanov nik...@compulab.co.il wrote:
Hi Simon,
On 02/10/14 04:57, Simon Glass wrote:
GPIOs should be requested before use. Without this, driver model will not
permit the GPIO to be used.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v4:
- Adjust error checking to permit calling gpio_request() multiple times
- Avoid doing low-level SATA init multiple times
- Move SATA changes into this patch
Changes in v3:
- Add a check for the Ethernet gpio_request() also
- Add a comment for the CONFIG_SPL_BUILD #ifdef
- Just warn when one of the board init stages fails
Changes in v2:
- Check return values of gpio_request()
arch/arm/imx-common/i2c-mxv7.c | 24 +
board/compulab/cm_fx6/cm_fx6.c | 61
--
board/compulab/cm_fx6/common.c | 14 +-
3 files changed, 84 insertions(+), 15 deletions(-)
diff --git a/arch/arm/imx-common/i2c-mxv7.c
b/arch/arm/imx-common/i2c-mxv7.c
index 70cff5c..aaf6936 100644
--- a/arch/arm/imx-common/i2c-mxv7.c
+++ b/arch/arm/imx-common/i2c-mxv7.c
@@ -4,6 +4,7 @@
* SPDX-License-Identifier: GPL-2.0+
*/
#include common.h
+#include malloc.h
#include asm/arch/clock.h
#include asm/arch/imx-regs.h
#include asm/errno.h
@@ -72,10 +73,26 @@ static void * const i2c_bases[] = {
int setup_i2c(unsigned i2c_index, int speed, int slave_addr,
struct i2c_pads_info *p)
{
+ char *name1, *name2;
int ret;
if (i2c_index = ARRAY_SIZE(i2c_bases))
return -EINVAL;
+
+ name1 = malloc(9);
+ name2 = malloc(9);
+ if (!name1 || !name2)
+ return -ENOMEM;
You have a memory leak here if name1 is allocated but name2 is not.
Yes. Actually there is also a memory leak if the devices are removed
(I'm not sure if I mentioned that somewhere, maybe on a Tegra thread).
I'm planning to address both of these as part of the gpio_request()
update, now that I think there are enough GPIO drivers to be
reasonably confident of the best approach.
+ sprintf(name1, i2c_sda%d, i2c_index);
+ sprintf(name2, i2c_scl%d, i2c_index);
+ ret = gpio_request(p-sda.gp, name1);
+ if (ret)
+ goto err_req1;
+
+ ret = gpio_request(p-scl.gp, name2);
+ if (ret)
+ goto err_req2;
+
/* Enable i2c clock */
ret = enable_i2c_clk(1, i2c_index);
if (ret)
@@ -93,5 +110,12 @@ int setup_i2c(unsigned i2c_index, int speed, int
slave_addr,
err_idle:
err_clk:
+ gpio_free(p-scl.gp);
+err_req2:
+ gpio_free(p-sda.gp);
+err_req1:
+ free(name1);
+ free(name2);
+
return ret;
}
diff --git a/board/compulab/cm_fx6/cm_fx6.c
b/board/compulab/cm_fx6/cm_fx6.c
index 9c6e686..53681d4 100644
--- a/board/compulab/cm_fx6/cm_fx6.c
+++ b/board/compulab/cm_fx6/cm_fx6.c
While this patch addresses the errors I mentioned in V3, I think that
the amount of additional checks this required demonstrates that these
init functions (which can be called multiple times) are not the best
place to do gpio requests.
Well ignoring the names, there are just the two checks for
gpio_request(), which you are going to need anyway I think.
I'm open to the idea that these requests will be handled by the
respective drivers (where applicable), but until that functionality is
implemented I think it's best to do them in board_init().
I'm not convinced that swapping this back to the board, only to swap
it back to the driver is a good plan.
I'm attaching 2 patches, which split this patch into two, one for
i2c-mxv7.c, and the other for cm_fx6.c.
OK will take a look, thanks.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra20: tamonten: Fix the early gpio init
On Thu, 02 Oct 2014 09:42:18 -0600
Stephen Warren swar...@wwwdotorg.org wrote:
On 10/02/2014 09:14 AM, Alban Bedel wrote:
To set gpio during the early init we now need to use
tegra_spl_gpio_direction_output(), copied from seaboard.
Change-Id: Id0aadb17a71b78e75e8c3f8de374102b3eab767b
That shouldn't be present on upstream patches.
Sorry about this.
Signed-off-by: Alban Bedel alban.be...@avionic-design.de
---
board/avionic-design/common/tamonten.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/board/avionic-design/common/tamonten.c
b/board/avionic-design/common/tamonten.c
index 9c86779..ea2425a 100644
--- a/board/avionic-design/common/tamonten.c
+++ b/board/avionic-design/common/tamonten.c
@@ -23,8 +23,10 @@
#ifdef CONFIG_BOARD_EARLY_INIT_F
void gpio_early_init(void)
{
+#ifndef CONFIG_SPL_BUILD
gpio_request(GPIO_PI4, NULL);
- gpio_direction_output(GPIO_PI4, 1);
+#endif
+ tegra_spl_gpio_direction_output(GPIO_PI4, 1);
}
Surely you only want to call tegra_spl_*() from SPL, and not from
non-SPL code? In other words, don't you need something more like:
#ifdef CONFIG_SPL_BUILD
tegra_spl_gpio_direction_output(GPIO_PI4, 1);
#else
gpio_request(GPIO_PI4, NULL);
gpio_direction_output(GPIO_PI4, 1);
#endif
Sadly not, at this point the gpio driver isn't available yet, that's
why one need to use tegra_spl_gpio_direction_output(). As mentioned in
the commit log I copied this from seaboard, assuming it would be
correct.
AFAICT the gpio_request() could be removed too, it doesn't work at this
point anyway.
... although perhaps the SPL and non-SPL code should simply be separated
into separate files, so that there's no need for ifdefs, and it's
obvious if SPL and non-SPL code are duplicating the same work?
Actually none of the code from tamonten.c is needed for the SPL, a
build with both function under #ifndef CONFIG_SPL_BUILD works just fine.
Any pointer on how I can get tamonten.c out of the SPL build?
Alban
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 42/42] ARM: tegra: colibri_t30: comment style fix
Signed-off-by: Marcel Ziswiler mar...@ziswiler.com
---
arch/arm/dts/tegra30-colibri.dts | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm/dts/tegra30-colibri.dts b/arch/arm/dts/tegra30-colibri.dts
index 43d03ca..8ede0c0 100644
--- a/arch/arm/dts/tegra30-colibri.dts
+++ b/arch/arm/dts/tegra30-colibri.dts
@@ -22,8 +22,10 @@
reg = 0x8000 0x4000;
};
- /* GEN1_I2C: I2C_SDA/SCL on SODIMM pin 194/196 (e.g. RTC on carrier
- board) */
+ /*
+* GEN1_I2C: I2C_SDA/SCL on SODIMM pin 194/196 (e.g. RTC on carrier
+* board)
+*/
i2c@7000c000 {
status = okay;
clock-frequency = 10;
@@ -39,8 +41,10 @@
clock-frequency = 10;
};
- /* PWR_I2C: power I2C to audio codec, PMIC, temperature sensor and
- touch screen controller */
+ /*
+* PWR_I2C: power I2C to audio codec, PMIC, temperature sensor and
+* touch screen controller
+*/
i2c@7000d000 {
status = okay;
clock-frequency = 10;
--
1.9.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-boot] [Patch 0/5] keystone2: add network support for K2E SoC and EVM
These patches add network support for Keystne2 Edison SoC boards. Based on [U-boot] [Patch 0/5] keystone_net: use MDIO bus and eth PHY frameworks https://www.mail-archive.com/u-boot@lists.denx.de/msg148974.html Hao Zhang (1): board: k2e_evm: add network support Ivan Khoronzhuk (4): ARM: keystone2: keysonte_nav: add support for K2E SoC net: keystone_serdes: add keystone K2E SoC support net: keystone_net: add Keystone2 K2E SoC support net: keystone_net: increase PHY auto negotiate time arch/arm/include/asm/arch-keystone/hardware-k2e.h | 20 +++ board/ti/ks2_evm/board_k2e.c | 68 ++- drivers/net/keystone_net.c| 47 ++-- include/configs/k2e_evm.h | 10 include/configs/ks2_evm.h | 1 + 5 files changed, 140 insertions(+), 6 deletions(-) -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-boot] [Patch 5/5] board: k2e_evm: add network support
From: Hao Zhang hzh...@ti.com
This patch adds network support code and enables keystone_net
driver usage for k2e_evm evaluation board.
Acked-by: Vitaly Andrianov vita...@ti.com
Acked-by: Murali Karicheri m-kariche...@ti.com
Signed-off-by: Hao Zhang hzh...@ti.com
Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
---
board/ti/ks2_evm/board_k2e.c | 68 +++-
include/configs/k2e_evm.h| 7 +
2 files changed, 74 insertions(+), 1 deletion(-)
diff --git a/board/ti/ks2_evm/board_k2e.c b/board/ti/ks2_evm/board_k2e.c
index 5472a43..b14a00e 100644
--- a/board/ti/ks2_evm/board_k2e.c
+++ b/board/ti/ks2_evm/board_k2e.c
@@ -10,6 +10,7 @@
#include common.h
#include asm/arch/ddr3.h
#include asm/arch/hardware.h
+#include asm/ti-common/keystone_net.h
DECLARE_GLOBAL_DATA_PTR;
@@ -35,10 +36,75 @@ static struct pll_init_data core_pll_config[] = {
CORE_PLL_1500,
};
-
static struct pll_init_data pa_pll_config =
PASS_PLL_1000;
+#ifdef CONFIG_DRIVER_TI_KEYSTONE_NET
+struct eth_priv_t eth_priv_cfg[] = {
+ {
+ .int_name= K2E_EMAC0,
+ .rx_flow = 0,
+ .phy_addr= 0,
+ .slave_port = 1,
+ .sgmii_link_type = SGMII_LINK_MAC_PHY,
+ },
+ {
+ .int_name= K2E_EMAC1,
+ .rx_flow = 8,
+ .phy_addr= 1,
+ .slave_port = 2,
+ .sgmii_link_type = SGMII_LINK_MAC_PHY,
+ },
+ {
+ .int_name= K2E_EMAC2,
+ .rx_flow = 16,
+ .phy_addr= 2,
+ .slave_port = 3,
+ .sgmii_link_type = SGMII_LINK_MAC_MAC_FORCED,
+ },
+ {
+ .int_name= K2E_EMAC3,
+ .rx_flow = 24,
+ .phy_addr= 3,
+ .slave_port = 4,
+ .sgmii_link_type = SGMII_LINK_MAC_MAC_FORCED,
+ },
+ {
+ .int_name= K2E_EMAC4,
+ .rx_flow = 32,
+ .phy_addr= 4,
+ .slave_port = 5,
+ .sgmii_link_type = SGMII_LINK_MAC_MAC_FORCED,
+ },
+ {
+ .int_name= K2E_EMAC5,
+ .rx_flow = 40,
+ .phy_addr= 5,
+ .slave_port = 6,
+ .sgmii_link_type = SGMII_LINK_MAC_MAC_FORCED,
+ },
+ {
+ .int_name= K2E_EMAC6,
+ .rx_flow = 48,
+ .phy_addr= 6,
+ .slave_port = 7,
+ .sgmii_link_type = SGMII_LINK_MAC_MAC_FORCED,
+ },
+ {
+ .int_name= K2E_EMAC7,
+ .rx_flow = 56,
+ .phy_addr= 7,
+ .slave_port = 8,
+ .sgmii_link_type = SGMII_LINK_MAC_MAC_FORCED,
+ },
+};
+
+int get_num_eth_ports(void)
+{
+ return sizeof(eth_priv_cfg) / sizeof(struct eth_priv_t);
+}
+#endif
+
#if defined(CONFIG_BOARD_EARLY_INIT_F)
int board_early_init_f(void)
{
diff --git a/include/configs/k2e_evm.h b/include/configs/k2e_evm.h
index fd45d61..dfb1835 100644
--- a/include/configs/k2e_evm.h
+++ b/include/configs/k2e_evm.h
@@ -34,6 +34,13 @@
/* NAND Configuration */
#define CONFIG_SYS_NAND_PAGE_2K
+/* Network */
+#define CONFIG_DRIVER_TI_KEYSTONE_NET
+#define CONFIG_TI_KSNAV
+#define CONFIG_KSNAV_PKTDMA_NETCP
+#define CONFIG_KSNET_NETCP_V1_5
+#define CONFIG_KSNET_CPSW_NUM_PORTS9
+
/* SerDes */
#define CONFIG_TI_KEYSTONE_SERDES
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-boot] [Patch 3/5] net: keystone_net: add Keystone2 K2E SoC support
The Keystone2 Edison SoC uses the same keystone net driver. This patch adds opportunity to use it by K2E SoCs. Acked-by: Vitaly Andrianov vita...@ti.com Acked-by: Murali Karicheri m-kariche...@ti.com Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com --- arch/arm/include/asm/arch-keystone/hardware-k2e.h | 3 +++ drivers/net/keystone_net.c| 5 + 2 files changed, 8 insertions(+) diff --git a/arch/arm/include/asm/arch-keystone/hardware-k2e.h b/arch/arm/include/asm/arch-keystone/hardware-k2e.h index 4eac5f8..ab0d5f9 100644 --- a/arch/arm/include/asm/arch-keystone/hardware-k2e.h +++ b/arch/arm/include/asm/arch-keystone/hardware-k2e.h @@ -58,4 +58,7 @@ #define KS2_NETCP_PDMA_RX_RCV_QUEUE4002 #define KS2_NETCP_PDMA_TX_SND_QUEUE896 +/* NETCP */ +#define KS2_NETCP_BASE 0x2400 + #endif diff --git a/drivers/net/keystone_net.c b/drivers/net/keystone_net.c index 6897dd9..889b273 100644 --- a/drivers/net/keystone_net.c +++ b/drivers/net/keystone_net.c @@ -289,6 +289,11 @@ int mac_sl_config(u_int16_t port, struct mac_sl_cfg *cfg) writel(cfg-max_rx_len, DEVICE_EMACSL_BASE(port) + CPGMACSL_REG_MAXLEN); writel(cfg-ctl, DEVICE_EMACSL_BASE(port) + CPGMACSL_REG_CTL); +#ifdef CONFIG_K2E_EVM + /* Map RX packet flow priority to 0 */ + writel(0, DEVICE_EMACSL_BASE(port) + CPGMACSL_REG_RX_PRI_MAP); +#endif + return ret; } -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-boot] [Patch 4/5] net: keystone_net: increase PHY auto negotiate time
The new Marvel PHY (88E1514) used on K2L/K2E EVM requires longer time
to auto negotiate with SoC's SGMII port.
It can take about 3 sec to up the PHY after reset, so add code to
expose sgmii auto negotiation waiting process.
Acked-by: Vitaly Andrianov vita...@ti.com
Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
---
drivers/net/keystone_net.c | 36 +++-
1 file changed, 31 insertions(+), 5 deletions(-)
diff --git a/drivers/net/keystone_net.c b/drivers/net/keystone_net.c
index 889b273..ddd2701 100644
--- a/drivers/net/keystone_net.c
+++ b/drivers/net/keystone_net.c
@@ -11,6 +11,7 @@
#include net.h
#include phy.h
+#include errno.h
#include miiphy.h
#include malloc.h
#include asm/ti-common/keystone_nav.h
@@ -30,6 +31,7 @@ static unsigned int sys_has_mdio = 1;
#define RX_BUFF_NUMS 24
#define RX_BUFF_LEN1520
#define MAX_SIZE_STREAM_BUFFER RX_BUFF_LEN
+#define SGMII_ANEG_TIMEOUT 4000
static u8 rx_buffs[RX_BUFF_NUMS * RX_BUFF_LEN] __aligned(16);
@@ -169,7 +171,7 @@ int keystone_sgmii_link_status(int port)
(status SGMII_REG_STATUS_LINK);
}
-int keystone_sgmii_config(int port, int interface)
+int keystone_sgmii_config(struct phy_device *phy_dev, int port, int interface)
{
unsigned int i, status, mask;
unsigned int mr_adv_ability, control;
@@ -230,11 +232,35 @@ int keystone_sgmii_config(int port, int interface)
if (control SGMII_REG_CONTROL_AUTONEG)
mask |= SGMII_REG_STATUS_AUTONEG;
- for (i = 0; i 1000; i++) {
+ status = __raw_readl(SGMII_STATUS_REG(port));
+ if ((status mask) == mask)
+ return 0;
+
+ printf(\n%s Waiting for SGMII auto negotiation to complete,
+ phy_dev-dev-name);
+ while ((status mask) != mask) {
+ /*
+* Timeout reached ?
+*/
+ if (i SGMII_ANEG_TIMEOUT) {
+ puts( TIMEOUT !\n);
+ phy_dev-link = 0;
+ return 0;
+ }
+
+ if (ctrlc()) {
+ puts(user interrupt!\n);
+ phy_dev-link = 0;
+ return -EINTR;
+ }
+
+ if ((i++ % 500) == 0)
+ printf(.);
+
+ udelay(1000); /* 1 ms */
status = __raw_readl(SGMII_STATUS_REG(port));
- if ((status mask) == mask)
- break;
}
+ puts( done\n);
return 0;
}
@@ -374,7 +400,7 @@ static int keystone2_eth_open(struct eth_device *dev, bd_t
*bis)
keystone2_net_serdes_setup();
- keystone_sgmii_config(eth_priv-slave_port - 1,
+ keystone_sgmii_config(phy_dev, eth_priv-slave_port - 1,
eth_priv-sgmii_link_type);
udelay(1);
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-boot] [Patch 1/5] ARM: keystone2: keysonte_nav: add support for K2E SoC
Keystone2 Edison SoC uses the same keystone navigator, but uses different NETCP PktDMA definitions. This patch adds required definitions. Acked-by: Vitaly Andrianov vita...@ti.com Acked-by: Murali Karicheri m-kariche...@ti.com Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com --- arch/arm/include/asm/arch-keystone/hardware-k2e.h | 13 + 1 file changed, 13 insertions(+) diff --git a/arch/arm/include/asm/arch-keystone/hardware-k2e.h b/arch/arm/include/asm/arch-keystone/hardware-k2e.h index 62172a4..f09aa93 100644 --- a/arch/arm/include/asm/arch-keystone/hardware-k2e.h +++ b/arch/arm/include/asm/arch-keystone/hardware-k2e.h @@ -41,4 +41,17 @@ /* Number of DSP cores */ #define KS2_NUM_DSPS 1 +/* NETCP pktdma */ +#define KS2_NETCP_PDMA_CTRL_BASE 0x24186000 +#define KS2_NETCP_PDMA_TX_BASE 0x24187000 +#define KS2_NETCP_PDMA_TX_CH_NUM 21 +#define KS2_NETCP_PDMA_RX_BASE 0x24188000 +#define KS2_NETCP_PDMA_RX_CH_NUM 91 +#define KS2_NETCP_PDMA_SCHED_BASE 0x24186100 +#define KS2_NETCP_PDMA_RX_FLOW_BASE0x24189000 +#define KS2_NETCP_PDMA_RX_FLOW_NUM 96 +#define KS2_NETCP_PDMA_RX_FREE_QUEUE 4001 +#define KS2_NETCP_PDMA_RX_RCV_QUEUE4002 +#define KS2_NETCP_PDMA_TX_SND_QUEUE896 + #endif -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-boot] [Patch 2/5] net: keystone_serdes: add keystone K2E SoC support
Keystone2 Edison SoC uses the same keystone SerDes driver. This patch adds support for K2E SoCs. Acked-by: Vitaly Andrianov vita...@ti.com Acked-by: Murali Karicheri m-kariche...@ti.com Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com --- arch/arm/include/asm/arch-keystone/hardware-k2e.h | 4 drivers/net/keystone_net.c| 6 ++ include/configs/k2e_evm.h | 3 +++ include/configs/ks2_evm.h | 1 + 4 files changed, 14 insertions(+) diff --git a/arch/arm/include/asm/arch-keystone/hardware-k2e.h b/arch/arm/include/asm/arch-keystone/hardware-k2e.h index f09aa93..4eac5f8 100644 --- a/arch/arm/include/asm/arch-keystone/hardware-k2e.h +++ b/arch/arm/include/asm/arch-keystone/hardware-k2e.h @@ -38,6 +38,10 @@ #define KS2_CIC2_DDR3_ECC_IRQ_NUM -1 /* not defined in K2E */ #define KS2_CIC2_DDR3_ECC_CHAN_NUM -1 /* not defined in K2E */ +/* SGMII SerDes */ +#define KS2_SGMII_SERDES2_BASE 0x02324000 +#define KS2_LANES_PER_SGMII_SERDES 4 + /* Number of DSP cores */ #define KS2_NUM_DSPS 1 diff --git a/drivers/net/keystone_net.c b/drivers/net/keystone_net.c index 8348a91..6897dd9 100644 --- a/drivers/net/keystone_net.c +++ b/drivers/net/keystone_net.c @@ -546,6 +546,12 @@ static void keystone2_net_serdes_setup(void) ks2_serdes_sgmii_156p25mhz, CONFIG_KSNET_SERDES_LANES_PER_SGMII); +#ifdef CONFIG_SOC_K2E + ks2_serdes_init(CONFIG_KSNET_SERDES_SGMII2_BASE, + ks2_serdes_sgmii_156p25mhz, + CONFIG_KSNET_SERDES_LANES_PER_SGMII); +#endif + /* wait till setup */ udelay(5000); } diff --git a/include/configs/k2e_evm.h b/include/configs/k2e_evm.h index 3502d10..fd45d61 100644 --- a/include/configs/k2e_evm.h +++ b/include/configs/k2e_evm.h @@ -34,4 +34,7 @@ /* NAND Configuration */ #define CONFIG_SYS_NAND_PAGE_2K +/* SerDes */ +#define CONFIG_TI_KEYSTONE_SERDES + #endif /* __CONFIG_K2E_EVM_H */ diff --git a/include/configs/ks2_evm.h b/include/configs/ks2_evm.h index dcce7c3..a92ab04 100644 --- a/include/configs/ks2_evm.h +++ b/include/configs/ks2_evm.h @@ -140,6 +140,7 @@ #define CONFIG_KSNET_MAC_ID_BASE KS2_MAC_ID_BASE_ADDR #define CONFIG_KSNET_NETCP_BASEKS2_NETCP_BASE #define CONFIG_KSNET_SERDES_SGMII_BASE KS2_SGMII_SERDES_BASE +#define CONFIG_KSNET_SERDES_SGMII2_BASEKS2_SGMII_SERDES2_BASE #define CONFIG_KSNET_SERDES_LANES_PER_SGMIIKS2_LANES_PER_SGMII_SERDES /* AEMIF */ -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] usb: gadget: fastboot: add max-download-size variable
On 14-10-01 07:37 PM, Marek Vasut wrote:
On Wednesday, October 01, 2014 at 10:38:57 PM, Steve Rae wrote:
On 14-09-30 12:05 PM, Eric Nelson wrote:
Current Android Fastboot seems to use 'max-download-size' instead
of 'downloadsize' variable to indicate the maximum size of sparse
segments.
See function get_target_sparse_limit() in file fastboot/fastboot.c
in the AOSP:
https://android.googlesource.com/platform/system/core/+/master
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
---
drivers/usb/gadget/f_fastboot.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/f_fastboot.c
b/drivers/usb/gadget/f_fastboot.c index 38c0965..f970f89 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -351,7 +351,8 @@ static void cb_getvar(struct usb_ep *ep, struct
usb_request *req)
strncat(response, FASTBOOT_VERSION, chars_left);
} else if (!strcmp_l1(bootloader-version, cmd)) {
strncat(response, U_BOOT_VERSION, chars_left);
- } else if (!strcmp_l1(downloadsize, cmd)) {
+ } else if (!strcmp_l1(downloadsize, cmd) ||
+ !strcmp_l1(max-download-size, cmd)) {
char str_num[12];
sprintf(str_num, %08x, CONFIG_USB_FASTBOOT_BUF_SIZE);
(the host version of fastboot that I'm using requires this change!)
Tested-by: Steve Rae s...@broadcom.com
Wow, so the previous code that was accepted was broken ? Did you know about that
breakage ?
It wasn't broken; let me try to clarify
It seems that different host versions of fastboot use either
downloadsize or max-download-size (I am not certain about the
history...) The original code has downloadsize, and with the host
version of fastboot that I am testing with (which uses
max-download-size), this reports as unknown variable - however, the
download still occurs successfully (there must be some default size that
it is using...) Therefore, it isn't broken (for me). However, Eric has
reported that for his host version of fastboot, that it stops!
So his changes (1/3 and 2/3) are required for his host version of
fastboot (and they work properly with my version)
Hope that clarifies it,
Thanks, Steve
PS. none of these host versions of fastboot have any version
identification -- so it is really difficult to determine what host
version we are actually talking about
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] U-Boot Mini Summit
Hi, the agenda for the U-Boot Mini Summit in a few days in Düsseldorf has now been finalized[1]. It is very encouraging to see such a lot of high-class content and I'm very excited to also meet a lot of new people. Please note that we would like to have as many custodians present as possible at 11:15 so that we can have a short round of introductions. I'm sure it will be a very pleasant experience to match names with faces known only from the mailing list so far :) Also note that the agenda allows everybody to attend Toms talk Redundant booting with U-Boot at 16:30[2] and of course it has no chance to collide with Mareks talk Secure and flexible boot with U-Boot on Wednesday at 15:30[2]. Thanks for all the input so far and I'm looking forward to seeing you all in a few days! Detlev [1] http://www.denx.de/wiki/U-Boot/MiniSummitELCE2014 [2] http://events.linuxfoundation.org/events/embedded-linux-conference-europe/program/schedule -- It's nice that the students coming to us already know Java. We just have to teach them how to program. -- Michael Sperber -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 4/4 v3] mtd: sf: Add CONFIG_SPI_N25Q256A_RESET for software-reset
On Thu 2014-10-02 04:47:23, Marek Vasut wrote: On Wednesday, October 01, 2014 at 09:04:48 PM, Jagan Teki wrote: On 2 October 2014 00:27, Stefan Roese s...@denx.de wrote: On 01.10.2014 20:25, Marek Vasut wrote: On Wednesday, October 01, 2014 at 05:13:11 PM, Stefan Roese wrote: This is needed for the SoCFPGA booting from SPI NOR flash e.g. (N25Q256A). With these changes, the SoCrates can boot and re-boot (reset) from SPI NOR flash without any problems. Seems like your SPI NOR reset logic is buggy. Does any of [1] apply to your board please? [1] http://www.rocketboards.org/foswiki/Documentation/SocBoardQspiBoot Yes. This seems to be that case. But I can't change it right now. So this solution with the soft-reset is better than nothing. If this is some think that must require, any possibility to this resetting prior to u-boot? like preloader or in first stage boot loader or something. You do understand, that this is a hardware bug on one particular board, right ? This can _not_ be reliably solved in software, not ever. I keep seeing people implementing one such workaround after the other in linux-mtd list, but sooner or later, they discover that their workaround is not reliable. Without proper reset logic in place, a system simply cannot reliably reboot, since it has no way to put all the hardware into defined state. Well, if you have 16M flash and if you need bootrom to work with it. AFAICT, as long as you avoid using SPI from bootrom (socrates will happily run from SD card, for example), reliable operation should be possible. And you can still use SPI from Linux and u-boot... Pavel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v1 2/2] odroid: usb: add support for usb host including ethernet
This change adds support for enabling the USB host features of the board.
This includes the USB3503A hub and the SMC LAN9730 ethernet controller
as well.
Credit goes to Tushar Behera (Linaro) for the function set_usb_ethaddr().
Signed-off-by: Suriyan Ramasami suriya...@gmail.com
---
arch/arm/cpu/armv7/exynos/power.c| 26 +++
arch/arm/dts/exynos4412-odroid.dts | 11 +++
arch/arm/include/asm/arch-exynos/cpu.h | 2 ++
arch/arm/include/asm/arch-exynos/ehci.h | 13
arch/arm/include/asm/arch-exynos/power.h | 7
board/samsung/odroid/odroid.c| 55
drivers/usb/host/ehci-exynos.c | 52 +-
include/configs/odroid.h | 13
8 files changed, 171 insertions(+), 8 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/power.c
b/arch/arm/cpu/armv7/exynos/power.c
index e1ab3d6..6578a07 100644
--- a/arch/arm/cpu/armv7/exynos/power.c
+++ b/arch/arm/cpu/armv7/exynos/power.c
@@ -53,10 +53,36 @@ void exynos5_set_usbhost_phy_ctrl(unsigned int enable)
}
}
+void exynos4412_set_usbhost_phy_ctrl(unsigned int enable)
+{
+ struct exynos4412_power *power =
+ (struct exynos4412_power *)samsung_get_base_power();
+
+ if (enable) {
+ /* Enabling USBHOST_PHY */
+ setbits_le32(power-usbhost_phy_control,
+POWER_USB_HOST_PHY_CTRL_EN);
+ setbits_le32(power-hsic1_phy_control,
+POWER_USB_HOST_PHY_CTRL_EN);
+ setbits_le32(power-hsic2_phy_control,
+POWER_USB_HOST_PHY_CTRL_EN);
+ } else {
+ /* Disabling USBHOST_PHY */
+ clrbits_le32(power-usbhost_phy_control,
+POWER_USB_HOST_PHY_CTRL_EN);
+ clrbits_le32(power-hsic1_phy_control,
+POWER_USB_HOST_PHY_CTRL_EN);
+ clrbits_le32(power-hsic2_phy_control,
+POWER_USB_HOST_PHY_CTRL_EN);
+ }
+}
+
void set_usbhost_phy_ctrl(unsigned int enable)
{
if (cpu_is_exynos5())
exynos5_set_usbhost_phy_ctrl(enable);
+ else if (proid_is_exynos4412())
+ exynos4412_set_usbhost_phy_ctrl(enable);
}
static void exynos5_set_usbdrd_phy_ctrl(unsigned int enable)
diff --git a/arch/arm/dts/exynos4412-odroid.dts
b/arch/arm/dts/exynos4412-odroid.dts
index 24d0bf1..8da8568 100644
--- a/arch/arm/dts/exynos4412-odroid.dts
+++ b/arch/arm/dts/exynos4412-odroid.dts
@@ -67,4 +67,15 @@
div = 0x3;
index = 4;
};
+
+ehci@1258 {
+compatible = samsung,exynos-ehci;
+reg = 0x1258 0x100;
+ #address-cells = 1;
+ #size-cells = 1;
+phy {
+compatible = samsung,exynos-usb-phy;
+reg = 0x125B 0x100;
+};
+};
};
diff --git a/arch/arm/include/asm/arch-exynos/cpu.h
b/arch/arm/include/asm/arch-exynos/cpu.h
index ba71714..fda21fb 100644
--- a/arch/arm/include/asm/arch-exynos/cpu.h
+++ b/arch/arm/include/asm/arch-exynos/cpu.h
@@ -18,6 +18,8 @@
#define EXYNOS4_GPIO_PART3_BASE0x0386
#define EXYNOS4_PRO_ID 0x1000
+#define EXYNOS4_GUID_LOW 0x1014
+#define EXYNOS4_GUID_HIGH 0x1018
#define EXYNOS4_SYSREG_BASE0x1001
#define EXYNOS4_POWER_BASE 0x1002
#define EXYNOS4_SWRESET0x10020400
diff --git a/arch/arm/include/asm/arch-exynos/ehci.h
b/arch/arm/include/asm/arch-exynos/ehci.h
index d2d70bd..3800fa9 100644
--- a/arch/arm/include/asm/arch-exynos/ehci.h
+++ b/arch/arm/include/asm/arch-exynos/ehci.h
@@ -12,6 +12,13 @@
#define CLK_24MHZ 5
+#define PHYPWR_NORMAL_MASK_PHY0 (0x39 0)
+#define PHYPWR_NORMAL_MASK_PHY1 (0x7 6)
+#define PHYPWR_NORMAL_MASK_HSIC0(0x7 9)
+#define PHYPWR_NORMAL_MASK_HSIC1(0x7 12)
+#define RSTCON_HOSTPHY_SWRST(0xf 3)
+#define RSTCON_SWRST(0x1 0)
+
#define HOST_CTRL0_PHYSWRSTALL (1 31)
#define HOST_CTRL0_COMMONON_N (1 9)
#define HOST_CTRL0_SIDDQ (1 6)
@@ -61,6 +68,12 @@ struct exynos_usb_phy {
unsigned int usbotgtune;
};
+struct exynos4412_usb_phy {
+ unsigned int usbphyctrl;
+ unsigned int usbphyclk;
+ unsigned int usbphyrstcon;
+};
+
/* Switch on the VBUS power. */
int board_usb_vbus_init(void);
diff --git a/arch/arm/include/asm/arch-exynos/power.h
b/arch/arm/include/asm/arch-exynos/power.h
index e8a98a5..3f97b31 100644
--- a/arch/arm/include/asm/arch-exynos/power.h
+++ b/arch/arm/include/asm/arch-exynos/power.h
@@ -210,6 +210,13 @@ struct exynos4_power {
[U-Boot] [PATCH v1 1/2] odroid: pmic77686: allow bucket voltage settings
Allow to set the bucket voltage for the max77686.
This will be used to reset the SMC LAN9730 ethernet on the odroids.
Signed-off-by: Suriyan Ramasami suriya...@gmail.com
---
drivers/power/pmic/pmic_max77686.c | 48 +-
include/power/max77686_pmic.h | 3 +++
2 files changed, 50 insertions(+), 1 deletion(-)
diff --git a/drivers/power/pmic/pmic_max77686.c
b/drivers/power/pmic/pmic_max77686.c
index df1fd91..1aeadb4 100644
--- a/drivers/power/pmic/pmic_max77686.c
+++ b/drivers/power/pmic/pmic_max77686.c
@@ -42,6 +42,25 @@ static unsigned int max77686_ldo_volt2hex(int ldo, ulong uV)
return 0;
}
+static unsigned int max77686_buck_volt2hex(int buck, ulong uV)
+{
+ unsigned int hex = 0;
+
+ if (buck 5 || buck 9) {
+ debug(%s: buck %d is not supported\n, __func__, buck);
+ return 0;
+ }
+
+ hex = (uV - 75) / 5;
+
+ 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 MAX77686_BUCK_VOLT_MAX_HEX + 1;
+}
+
int max77686_set_ldo_voltage(struct pmic *p, int ldo, ulong uV)
{
unsigned int val, ret, hex, adr;
@@ -68,6 +87,33 @@ 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, ret, hex, adr;
+
+ if (buck 5 buck 9) {
+ printf(%s: %d is an unsupported bucket number\n,
+ __func__, buck);
+ return -1;
+ }
+
+ adr = max77686_buck_addr[buck] + 1;
+ hex = max77686_buck_volt2hex(buck, uV);
+
+ if (hex == MAX77686_BUCK_VOLT_MAX_HEX + 1)
+ return -1;
+
+ ret = pmic_reg_read(p, adr, val);
+ if (ret)
+ return ret;
+
+ val = ~MAX77686_BUCK_VOLT_MASK;
+ val |= hex;
+ ret |= pmic_reg_write(p, adr, val);
+
+ return ret;
+}
+
int max77686_set_ldo_mode(struct pmic *p, int ldo, char opmode)
{
unsigned int val, ret, adr, mode;
@@ -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_MASK0x3f
#define MAX77686_BUCK_MODE_MASK0x03
#define MAX77686_BUCK_MODE_SHIFT_1 0x00
#define MAX77686_BUCK_MODE_SHIFT_2 0x04
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 4/4 v3] mtd: sf: Add CONFIG_SPI_N25Q256A_RESET for software-reset
On Thursday, October 02, 2014 at 10:40:52 AM, Pavel Machek wrote: On Thu 2014-10-02 04:47:23, Marek Vasut wrote: On Wednesday, October 01, 2014 at 09:04:48 PM, Jagan Teki wrote: On 2 October 2014 00:27, Stefan Roese s...@denx.de wrote: On 01.10.2014 20:25, Marek Vasut wrote: On Wednesday, October 01, 2014 at 05:13:11 PM, Stefan Roese wrote: This is needed for the SoCFPGA booting from SPI NOR flash e.g. (N25Q256A). With these changes, the SoCrates can boot and re-boot (reset) from SPI NOR flash without any problems. Seems like your SPI NOR reset logic is buggy. Does any of [1] apply to your board please? [1] http://www.rocketboards.org/foswiki/Documentation/SocBoardQspiBoot Yes. This seems to be that case. But I can't change it right now. So this solution with the soft-reset is better than nothing. If this is some think that must require, any possibility to this resetting prior to u-boot? like preloader or in first stage boot loader or something. You do understand, that this is a hardware bug on one particular board, right ? This can _not_ be reliably solved in software, not ever. I keep seeing people implementing one such workaround after the other in linux-mtd list, but sooner or later, they discover that their workaround is not reliable. Without proper reset logic in place, a system simply cannot reliably reboot, since it has no way to put all the hardware into defined state. Well, if you have 16M flash and if you need bootrom to work with it. AFAICT, as long as you avoid using SPI from bootrom (socrates will happily run from SD card, for example), reliable operation should be possible. And you can still use SPI from Linux and u-boot... SD has the same problem if you don't have proper reset logic for 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] [PATCH] tegra20: tamonten: Fix the early gpio init
On 10/02/2014 10:12 AM, Alban Bedel wrote:
On Thu, 02 Oct 2014 09:42:18 -0600
Stephen Warren swar...@wwwdotorg.org wrote:
On 10/02/2014 09:14 AM, Alban Bedel wrote:
To set gpio during the early init we now need to use
tegra_spl_gpio_direction_output(), copied from seaboard.
Change-Id: Id0aadb17a71b78e75e8c3f8de374102b3eab767b
That shouldn't be present on upstream patches.
Sorry about this.
Signed-off-by: Alban Bedel alban.be...@avionic-design.de
---
board/avionic-design/common/tamonten.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/board/avionic-design/common/tamonten.c
b/board/avionic-design/common/tamonten.c
index 9c86779..ea2425a 100644
--- a/board/avionic-design/common/tamonten.c
+++ b/board/avionic-design/common/tamonten.c
@@ -23,8 +23,10 @@
#ifdef CONFIG_BOARD_EARLY_INIT_F
void gpio_early_init(void)
{
+#ifndef CONFIG_SPL_BUILD
gpio_request(GPIO_PI4, NULL);
- gpio_direction_output(GPIO_PI4, 1);
+#endif
+ tegra_spl_gpio_direction_output(GPIO_PI4, 1);
}
Surely you only want to call tegra_spl_*() from SPL, and not from
non-SPL code? In other words, don't you need something more like:
#ifdef CONFIG_SPL_BUILD
tegra_spl_gpio_direction_output(GPIO_PI4, 1);
#else
gpio_request(GPIO_PI4, NULL);
gpio_direction_output(GPIO_PI4, 1);
#endif
Sadly not, at this point the gpio driver isn't available yet, that's
why one need to use tegra_spl_gpio_direction_output(). As mentioned in
the commit log I copied this from seaboard, assuming it would be
correct.
AFAICT the gpio_request() could be removed too, it doesn't work at this
point anyway.
Hmm. CC Simon to comment on which GPIO drivers are available in
SPL/non-SPL, and why the above ifdef doesn't work.
... although perhaps the SPL and non-SPL code should simply be separated
into separate files, so that there's no need for ifdefs, and it's
obvious if SPL and non-SPL code are duplicating the same work?
Actually none of the code from tamonten.c is needed for the SPL, a
build with both function under #ifndef CONFIG_SPL_BUILD works just fine.
Indeed, if manipulating the GPIO in SPL isn't even necessary, then just
wrapping the whole code in #ifndef CONFIG_SPL_BUILD makes sense to me.
Any pointer on how I can get tamonten.c out of the SPL build?
I'm not sure now that the Makefile structure has changed to Kbuild. It
might be as simple as:
obj-$(CONFIG_SPL_BUILD) += foo.o
(but using whatever the opposite of CONFIG_SPL_BUILD is.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra20: tamonten: Fix the early gpio init
Hi Alban,
On 2 October 2014 10:12, Alban Bedel alban.be...@avionic-design.de wrote:
On Thu, 02 Oct 2014 09:42:18 -0600
Stephen Warren swar...@wwwdotorg.org wrote:
On 10/02/2014 09:14 AM, Alban Bedel wrote:
To set gpio during the early init we now need to use
tegra_spl_gpio_direction_output(), copied from seaboard.
Change-Id: Id0aadb17a71b78e75e8c3f8de374102b3eab767b
That shouldn't be present on upstream patches.
Sorry about this.
If you use patman it will take these out for you automatically without
you having to think about it.
Signed-off-by: Alban Bedel alban.be...@avionic-design.de
---
board/avionic-design/common/tamonten.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/board/avionic-design/common/tamonten.c
b/board/avionic-design/common/tamonten.c
index 9c86779..ea2425a 100644
--- a/board/avionic-design/common/tamonten.c
+++ b/board/avionic-design/common/tamonten.c
@@ -23,8 +23,10 @@
#ifdef CONFIG_BOARD_EARLY_INIT_F
void gpio_early_init(void)
{
+#ifndef CONFIG_SPL_BUILD
gpio_request(GPIO_PI4, NULL);
- gpio_direction_output(GPIO_PI4, 1);
+#endif
+ tegra_spl_gpio_direction_output(GPIO_PI4, 1);
}
Surely you only want to call tegra_spl_*() from SPL, and not from
non-SPL code? In other words, don't you need something more like:
#ifdef CONFIG_SPL_BUILD
tegra_spl_gpio_direction_output(GPIO_PI4, 1);
#else
gpio_request(GPIO_PI4, NULL);
gpio_direction_output(GPIO_PI4, 1);
#endif
Sadly not, at this point the gpio driver isn't available yet, that's
why one need to use tegra_spl_gpio_direction_output(). As mentioned in
the commit log I copied this from seaboard, assuming it would be
correct.
AFAICT the gpio_request() could be removed too, it doesn't work at this
point anyway.
This is a temporary measure until the SPL series is applied to dm/next
at least (I expect sometime this month). While driver model is
available before relocation, the Tegra GPIO driver is not marked in
the device tree with u-boot,dm-pre-reloc, so is not available this
early. Device tree additions give Stephen a headache, and I decided it
was better for it not to work for now, and just use the SPL function.
There are three stages to consider:
1. SPL
2. U-Boot, before relocation
3. U-Boot, after relocation
At present, driver model does not support 1 (see dm/spl-working for
patches if you want to see this). It supports 2 but only for drivers
marked pre-relocation (except serial, for which a hack forces the
console to be bound and used in the device tree case without the
u-boot,dm-pre-reloc marker). It supports 3 fully.
There is a bit of an update on current status here:
http://www.denx.de/wiki/U-Boot/DriverModel
My approach with driver model is incremental, since that's the only
way to make any progress.
... although perhaps the SPL and non-SPL code should simply be separated
into separate files, so that there's no need for ifdefs, and it's
obvious if SPL and non-SPL code are duplicating the same work?
Actually none of the code from tamonten.c is needed for the SPL, a
build with both function under #ifndef CONFIG_SPL_BUILD works just fine.
Any pointer on how I can get tamonten.c out of the SPL build?
This should work:
ifndef CONFIG_SPL_BUILD
obj-y += tamonten.o
endif
But it seems odd to me. At least on seaboard I didn't get the SPL
message unless this code was executed.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra20: tamonten: Fix the early gpio init
On 10/02/2014 01:05 PM, Simon Glass wrote:
Hi Alban,
On 2 October 2014 10:12, Alban Bedel alban.be...@avionic-design.de wrote:
On Thu, 02 Oct 2014 09:42:18 -0600
Stephen Warren swar...@wwwdotorg.org wrote:
On 10/02/2014 09:14 AM, Alban Bedel wrote:
To set gpio during the early init we now need to use
tegra_spl_gpio_direction_output(), copied from seaboard.
Change-Id: Id0aadb17a71b78e75e8c3f8de374102b3eab767b
That shouldn't be present on upstream patches.
Sorry about this.
If you use patman it will take these out for you automatically without
you having to think about it.
Signed-off-by: Alban Bedel alban.be...@avionic-design.de
---
board/avionic-design/common/tamonten.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/board/avionic-design/common/tamonten.c
b/board/avionic-design/common/tamonten.c
index 9c86779..ea2425a 100644
--- a/board/avionic-design/common/tamonten.c
+++ b/board/avionic-design/common/tamonten.c
@@ -23,8 +23,10 @@
#ifdef CONFIG_BOARD_EARLY_INIT_F
void gpio_early_init(void)
{
+#ifndef CONFIG_SPL_BUILD
gpio_request(GPIO_PI4, NULL);
- gpio_direction_output(GPIO_PI4, 1);
+#endif
+ tegra_spl_gpio_direction_output(GPIO_PI4, 1);
}
Surely you only want to call tegra_spl_*() from SPL, and not from
non-SPL code? In other words, don't you need something more like:
#ifdef CONFIG_SPL_BUILD
tegra_spl_gpio_direction_output(GPIO_PI4, 1);
#else
gpio_request(GPIO_PI4, NULL);
gpio_direction_output(GPIO_PI4, 1);
#endif
Sadly not, at this point the gpio driver isn't available yet, that's
why one need to use tegra_spl_gpio_direction_output(). As mentioned in
the commit log I copied this from seaboard, assuming it would be
correct.
AFAICT the gpio_request() could be removed too, it doesn't work at this
point anyway.
This is a temporary measure until the SPL series is applied to dm/next
at least (I expect sometime this month). While driver model is
available before relocation, the Tegra GPIO driver is not marked in
the device tree with u-boot,dm-pre-reloc, so is not available this
early. Device tree additions give Stephen a headache, and I decided it
was better for it not to work for now, and just use the SPL function.
There are three stages to consider:
1. SPL
2. U-Boot, before relocation
3. U-Boot, after relocation
At present, driver model does not support 1 (see dm/spl-working for
patches if you want to see this). It supports 2 but only for drivers
marked pre-relocation (except serial, for which a hack forces the
console to be bound and used in the device tree case without the
u-boot,dm-pre-reloc marker). It supports 3 fully.
That's roughly what I expected. Given that, I fail to see why the
following wouldn't work then:
#ifdef CONFIG_SPL_BUILD
tegra_spl_gpio_direction_output(GPIO_PI4, 1);
#else
gpio_request(GPIO_PI4, NULL);
gpio_direction_output(GPIO_PI4, 1);
#endif
(or have just 1 of those two ifdef branches; presumably the GPIO only
needs to be initialized in one place not both?)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra20: tamonten: Fix the early gpio init
Hi Stephen,
On 2 October 2014 12:39, Stephen Warren swar...@wwwdotorg.org wrote:
On 10/02/2014 10:12 AM, Alban Bedel wrote:
On Thu, 02 Oct 2014 09:42:18 -0600
Stephen Warren swar...@wwwdotorg.org wrote:
On 10/02/2014 09:14 AM, Alban Bedel wrote:
To set gpio during the early init we now need to use
tegra_spl_gpio_direction_output(), copied from seaboard.
Change-Id: Id0aadb17a71b78e75e8c3f8de374102b3eab767b
That shouldn't be present on upstream patches.
Sorry about this.
Signed-off-by: Alban Bedel alban.be...@avionic-design.de
---
board/avionic-design/common/tamonten.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/board/avionic-design/common/tamonten.c
b/board/avionic-design/common/tamonten.c
index 9c86779..ea2425a 100644
--- a/board/avionic-design/common/tamonten.c
+++ b/board/avionic-design/common/tamonten.c
@@ -23,8 +23,10 @@
#ifdef CONFIG_BOARD_EARLY_INIT_F
void gpio_early_init(void)
{
+#ifndef CONFIG_SPL_BUILD
gpio_request(GPIO_PI4, NULL);
- gpio_direction_output(GPIO_PI4, 1);
+#endif
+ tegra_spl_gpio_direction_output(GPIO_PI4, 1);
}
Surely you only want to call tegra_spl_*() from SPL, and not from
non-SPL code? In other words, don't you need something more like:
#ifdef CONFIG_SPL_BUILD
tegra_spl_gpio_direction_output(GPIO_PI4, 1);
#else
gpio_request(GPIO_PI4, NULL);
gpio_direction_output(GPIO_PI4, 1);
#endif
Sadly not, at this point the gpio driver isn't available yet, that's
why one need to use tegra_spl_gpio_direction_output(). As mentioned in
the commit log I copied this from seaboard, assuming it would be
correct.
AFAICT the gpio_request() could be removed too, it doesn't work at this
point anyway.
Hmm. CC Simon to comment on which GPIO drivers are available in SPL/non-SPL,
and why the above ifdef doesn't work.
See my previous reply.
... although perhaps the SPL and non-SPL code should simply be separated
into separate files, so that there's no need for ifdefs, and it's
obvious if SPL and non-SPL code are duplicating the same work?
Actually none of the code from tamonten.c is needed for the SPL, a
build with both function under #ifndef CONFIG_SPL_BUILD works just fine.
I think this will drop the message. But I should have mentioned in my
other reply that we don't really need to call gpio_early_init_uart()
from board_early_init_f() if we are already calling it from
spl_board_init(). Separate issue to this patch of course.
Indeed, if manipulating the GPIO in SPL isn't even necessary, then just
wrapping the whole code in #ifndef CONFIG_SPL_BUILD makes sense to me.
Any pointer on how I can get tamonten.c out of the SPL build?
I'm not sure now that the Makefile structure has changed to Kbuild. It might
be as simple as:
obj-$(CONFIG_SPL_BUILD) += foo.o
(but using whatever the opposite of CONFIG_SPL_BUILD is.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra20: tamonten: Fix the early gpio init
Hi Stephen,
On 2 October 2014 13:08, Stephen Warren swar...@wwwdotorg.org wrote:
On 10/02/2014 01:05 PM, Simon Glass wrote:
Hi Alban,
On 2 October 2014 10:12, Alban Bedel alban.be...@avionic-design.de
wrote:
On Thu, 02 Oct 2014 09:42:18 -0600
Stephen Warren swar...@wwwdotorg.org wrote:
On 10/02/2014 09:14 AM, Alban Bedel wrote:
To set gpio during the early init we now need to use
tegra_spl_gpio_direction_output(), copied from seaboard.
Change-Id: Id0aadb17a71b78e75e8c3f8de374102b3eab767b
That shouldn't be present on upstream patches.
Sorry about this.
If you use patman it will take these out for you automatically without
you having to think about it.
Signed-off-by: Alban Bedel alban.be...@avionic-design.de
---
board/avionic-design/common/tamonten.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/board/avionic-design/common/tamonten.c
b/board/avionic-design/common/tamonten.c
index 9c86779..ea2425a 100644
--- a/board/avionic-design/common/tamonten.c
+++ b/board/avionic-design/common/tamonten.c
@@ -23,8 +23,10 @@
#ifdef CONFIG_BOARD_EARLY_INIT_F
void gpio_early_init(void)
{
+#ifndef CONFIG_SPL_BUILD
gpio_request(GPIO_PI4, NULL);
- gpio_direction_output(GPIO_PI4, 1);
+#endif
+ tegra_spl_gpio_direction_output(GPIO_PI4, 1);
}
Surely you only want to call tegra_spl_*() from SPL, and not from
non-SPL code? In other words, don't you need something more like:
#ifdef CONFIG_SPL_BUILD
tegra_spl_gpio_direction_output(GPIO_PI4, 1);
#else
gpio_request(GPIO_PI4, NULL);
gpio_direction_output(GPIO_PI4, 1);
#endif
Sadly not, at this point the gpio driver isn't available yet, that's
why one need to use tegra_spl_gpio_direction_output(). As mentioned in
the commit log I copied this from seaboard, assuming it would be
correct.
AFAICT the gpio_request() could be removed too, it doesn't work at this
point anyway.
This is a temporary measure until the SPL series is applied to dm/next
at least (I expect sometime this month). While driver model is
available before relocation, the Tegra GPIO driver is not marked in
the device tree with u-boot,dm-pre-reloc, so is not available this
early. Device tree additions give Stephen a headache, and I decided it
was better for it not to work for now, and just use the SPL function.
There are three stages to consider:
1. SPL
2. U-Boot, before relocation
3. U-Boot, after relocation
At present, driver model does not support 1 (see dm/spl-working for
patches if you want to see this). It supports 2 but only for drivers
marked pre-relocation (except serial, for which a hack forces the
console to be bound and used in the device tree case without the
u-boot,dm-pre-reloc marker). It supports 3 fully.
That's roughly what I expected. Given that, I fail to see why the following
wouldn't work then:
#ifdef CONFIG_SPL_BUILD
tegra_spl_gpio_direction_output(GPIO_PI4, 1);
#else
gpio_request(GPIO_PI4, NULL);
gpio_direction_output(GPIO_PI4, 1);
#endif
(or have just 1 of those two ifdef branches; presumably the GPIO only needs
to be initialized in one place not both?)
Yes that's true, although be aware that the gpio_request() and
gpio_direction_output() will in fact always fail at present, since
they are called before the GPIO driver is inited pre-reloc. But since
it has happened in SPL it doesn't matter.
I haven't tested this, and it's icky to rely on failure and not
checking the return code, and I slightly prefer Alban's solution at
least for now. This is only going to be a problem for another month or
so.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 01/32] nitrogen6x: implement board_cfb_skip() to disable text output
Several customers have asked to leave the display quiet during
boot, so allow the user to express this request by the presence
of environment variable novideo.
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
---
board/boundary/nitrogen6x/nitrogen6x.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/board/boundary/nitrogen6x/nitrogen6x.c
b/board/boundary/nitrogen6x/nitrogen6x.c
index 60a09f4..1a6edac 100644
--- a/board/boundary/nitrogen6x/nitrogen6x.c
+++ b/board/boundary/nitrogen6x/nitrogen6x.c
@@ -558,6 +558,11 @@ struct display_info_t const displays[] = {{
} } };
size_t display_count = ARRAY_SIZE(displays);
+int board_cfb_skip(void)
+{
+ return NULL != getenv(novideo);
+}
+
static void setup_display(void)
{
struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 00/32] ARM: i.MX: nitrogen6x clean up
This collection of patches comprises a set of updates that have been lingering in our Github repository. We're pushing them to main-line in preparation for the addition of a couple of boards that have also been lingering for a while. Patches 1-9 are tweaks to the mx6qsabrelite/nitrogen6x initialization code. Patches 10-18 add support for additional displays supported by the board(s) and tweak the HDMI detection. Patches 19-32 enable and configure various features through changes to include/configs/nitrogen6x.h. Diego Rondini (1): nitrogen6x: config: allow boot to USB stick Eric Nelson (24): nitrogen6x: implement board_cfb_skip() to disable text output nitrogen6x: configure SD2 pads for SDIO on USDHC2 nitrogen6x: power-down miscellanous peripherals nitrogen6x: staticize board file nitrogen6x: Allow U-Boot to be silent on UART2 nitrogen6x: prevent warnings about board_ehci* callbacks nitrogen6x: display: add qvga panel nitrogen6x: display: add support for LG-9.7 LVDS display nitrogen6x: display: add LDB-WXGA-S for SPWG 1280x800 displays nitrogen6x: display: add support for fusion 7 display nitrogen6x: display: add svga display (800x600) nitrogen6x: display: add Ampire 1024x600 panel nitrogen6x: display: add wvga-lvds panel nitrogen6x: display use I2C detect for HDMI nitrogen6x: config: add USB Mass Storage (ums) support nitrogen6x: config: add initrd_high nitrogen6x: config: expose SATA, then MMC over USB nitrogen6x: config: enable USB keyboard support nitrogen6x: config: add CONFIG_CMD_MEMTEST nitrogen6x: config: enable i2c edid nitrogen6x: config: disable logo nitrogen6x: config: configure usb_ether nitrogen6x: config: add gpio command nitrogen6x: config: enable Android fastboot Kevin Mihelich (2): nitrogen6x: config: use FS_GENERIC load command nitrogen6x: config: enable EXT4 filesystem Robert Winkler (1): nitrogen6x: display: add support lvds jeida screen Troy Kisky (4): nitrogen6x: simplify board_mmc_getcd nitrogen6x: configure SGTL5000, CSI camera clock outputs nitrogen6x: phy: add 100 us delay after phy reset nitrogen6x: config: allow more bootargs parameters board/boundary/nitrogen6x/nitrogen6x.c | 298 + include/configs/nitrogen6x.h | 98 +-- 2 files changed, 347 insertions(+), 49 deletions(-) -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 03/32] nitrogen6x: configure SD2 pads for SDIO on USDHC2
Pads SD2_CLK/CMD/DAT0-3 are connected to an SDIO WiFi device on
Nitrogen and unconnected on BD-SL-i.MX6 (sabre lite).
Configure them as SDIO pins to prevent them from being in a state
that confuses the WiFi part.
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
---
board/boundary/nitrogen6x/nitrogen6x.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/board/boundary/nitrogen6x/nitrogen6x.c
b/board/boundary/nitrogen6x/nitrogen6x.c
index e8cc243..bde299f 100644
--- a/board/boundary/nitrogen6x/nitrogen6x.c
+++ b/board/boundary/nitrogen6x/nitrogen6x.c
@@ -124,6 +124,15 @@ struct i2c_pads_info i2c_pad_info2 = {
}
};
+static iomux_v3_cfg_t const usdhc2_pads[] = {
+ MX6_PAD_SD2_CLK__SD2_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_SD2_CMD__SD2_CMD | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_SD2_DAT0__SD2_DATA0 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_SD2_DAT1__SD2_DATA1 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_SD2_DAT2__SD2_DATA2 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_SD2_DAT3__SD2_DATA3 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+};
+
iomux_v3_cfg_t const usdhc3_pads[] = {
MX6_PAD_SD3_CLK__SD3_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL),
MX6_PAD_SD3_CMD__SD3_CMD | MUX_PAD_CTRL(USDHC_PAD_CTRL),
@@ -657,6 +666,8 @@ int board_init(void)
#ifdef CONFIG_MXC_SPI
setup_spi();
#endif
+ imx_iomux_v3_setup_multiple_pads(
+ usdhc2_pads, ARRAY_SIZE(usdhc2_pads));
setup_i2c(0, CONFIG_SYS_I2C_SPEED, 0x7f, i2c_pad_info0);
setup_i2c(1, CONFIG_SYS_I2C_SPEED, 0x7f, i2c_pad_info1);
setup_i2c(2, CONFIG_SYS_I2C_SPEED, 0x7f, i2c_pad_info2);
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 05/32] nitrogen6x: configure SGTL5000, CSI camera clock outputs
From: Troy Kisky troy.ki...@boundarydevices.com
Configure CLKO outputs for SGTL5000, CSI camera.
The sys_mclk output for the SGTL500 in particular prevents
Windows CE from properly driving audio.
Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
---
board/boundary/nitrogen6x/nitrogen6x.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/board/boundary/nitrogen6x/nitrogen6x.c
b/board/boundary/nitrogen6x/nitrogen6x.c
index 38f0df8..96e2b74 100644
--- a/board/boundary/nitrogen6x/nitrogen6x.c
+++ b/board/boundary/nitrogen6x/nitrogen6x.c
@@ -622,8 +622,14 @@ static void setup_display(void)
}
#endif
-/* wl1271 pads on nitrogen6x */
static iomux_v3_cfg_t const init_pads[] = {
+ /* SGTL5000 sys_mclk */
+ NEW_PAD_CTRL(MX6_PAD_GPIO_0__CCM_CLKO1, OUTPUT_40OHM),
+
+ /* J5 - Camera MCLK */
+ NEW_PAD_CTRL(MX6_PAD_GPIO_3__CCM_CLKO2, OUTPUT_40OHM),
+
+ /* wl1271 pads on nitrogen6x */
/* WL12XX_WL_IRQ_GP */
NEW_PAD_CTRL(MX6_PAD_NANDF_CS1__GPIO6_IO14, WEAK_PULLDOWN),
/* WL12XX_WL_ENABLE_GP */
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 02/32] nitrogen6x: simplify board_mmc_getcd
From: Troy Kisky troy.ki...@boundarydevices.com
The same logic applies to both SD card slots, only with different
GPIOs and the code should make that easier to see.
Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com
---
board/boundary/nitrogen6x/nitrogen6x.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/board/boundary/nitrogen6x/nitrogen6x.c
b/board/boundary/nitrogen6x/nitrogen6x.c
index 1a6edac..e8cc243 100644
--- a/board/boundary/nitrogen6x/nitrogen6x.c
+++ b/board/boundary/nitrogen6x/nitrogen6x.c
@@ -279,17 +279,11 @@ struct fsl_esdhc_cfg usdhc_cfg[2] = {
int board_mmc_getcd(struct mmc *mmc)
{
struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc-priv;
- int ret;
-
- if (cfg-esdhc_base == USDHC3_BASE_ADDR) {
- gpio_direction_input(IMX_GPIO_NR(7, 0));
- ret = !gpio_get_value(IMX_GPIO_NR(7, 0));
- } else {
- gpio_direction_input(IMX_GPIO_NR(2, 6));
- ret = !gpio_get_value(IMX_GPIO_NR(2, 6));
- }
+ int gp_cd = (cfg-esdhc_base == USDHC3_BASE_ADDR) ? IMX_GPIO_NR(7, 0) :
+ IMX_GPIO_NR(2, 6);
- return ret;
+ gpio_direction_input(gp_cd);
+ return !gpio_get_value(gp_cd);
}
int board_mmc_init(bd_t *bis)
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 04/32] nitrogen6x: power-down miscellanous peripherals
Ensure that cameras and USB OTG power are in a stable (reset)
state at reset by configuring their pads and toggling GPIOs.
Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
---
board/boundary/nitrogen6x/nitrogen6x.c | 47 +++---
1 file changed, 43 insertions(+), 4 deletions(-)
diff --git a/board/boundary/nitrogen6x/nitrogen6x.c
b/board/boundary/nitrogen6x/nitrogen6x.c
index bde299f..38f0df8 100644
--- a/board/boundary/nitrogen6x/nitrogen6x.c
+++ b/board/boundary/nitrogen6x/nitrogen6x.c
@@ -622,17 +622,56 @@ static void setup_display(void)
}
#endif
+/* wl1271 pads on nitrogen6x */
+static iomux_v3_cfg_t const init_pads[] = {
+ /* WL12XX_WL_IRQ_GP */
+ NEW_PAD_CTRL(MX6_PAD_NANDF_CS1__GPIO6_IO14, WEAK_PULLDOWN),
+ /* WL12XX_WL_ENABLE_GP */
+ NEW_PAD_CTRL(MX6_PAD_NANDF_CS2__GPIO6_IO15, OUTPUT_40OHM),
+ /* WL12XX_BT_ENABLE_GP */
+ NEW_PAD_CTRL(MX6_PAD_NANDF_CS3__GPIO6_IO16, OUTPUT_40OHM),
+ /* USB otg power */
+ NEW_PAD_CTRL(MX6_PAD_EIM_D22__GPIO3_IO22, OUTPUT_40OHM),
+ NEW_PAD_CTRL(MX6_PAD_NANDF_D5__GPIO2_IO05, OUTPUT_40OHM),
+ NEW_PAD_CTRL(MX6_PAD_NANDF_WP_B__GPIO6_IO09, OUTPUT_40OHM),
+ NEW_PAD_CTRL(MX6_PAD_GPIO_8__GPIO1_IO08, OUTPUT_40OHM),
+ NEW_PAD_CTRL(MX6_PAD_GPIO_6__GPIO1_IO06, OUTPUT_40OHM),
+};
+
+#define WL12XX_WL_IRQ_GP IMX_GPIO_NR(6, 14)
+
+static unsigned gpios_out_low[] = {
+ /* Disable wl1271 */
+ IMX_GPIO_NR(6, 15), /* disable wireless */
+ IMX_GPIO_NR(6, 16), /* disable bluetooth */
+ IMX_GPIO_NR(3, 22), /* disable USB otg power */
+ IMX_GPIO_NR(2, 5), /* ov5640 mipi camera reset */
+ IMX_GPIO_NR(1, 8), /* ov5642 reset */
+};
+
+static unsigned gpios_out_high[] = {
+ IMX_GPIO_NR(1, 6), /* ov5642 powerdown */
+ IMX_GPIO_NR(6, 9), /* ov5640 mipi camera power down */
+};
+
+static void set_gpios(unsigned *p, int cnt, int val)
+{
+ int i;
+
+ for (i = 0; i cnt; i++)
+ gpio_direction_output(*p++, val);
+}
+
int board_early_init_f(void)
{
setup_iomux_uart();
- /* Disable wl1271 For Nitrogen6w */
+ set_gpios(gpios_out_high, ARRAY_SIZE(gpios_out_high), 1);
+ set_gpios(gpios_out_low, ARRAY_SIZE(gpios_out_low), 0);
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));
+ imx_iomux_v3_setup_multiple_pads(init_pads, ARRAY_SIZE(init_pads));
setup_buttons();
#if defined(CONFIG_VIDEO_IPUV3)
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 06/32] nitrogen6x: staticize board file
Declare locally-used data structures and functions as
static and pull in header files to prevent compiler warnings
of Should it be static? when building with make C=1.
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
---
board/boundary/nitrogen6x/nitrogen6x.c | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/board/boundary/nitrogen6x/nitrogen6x.c
b/board/boundary/nitrogen6x/nitrogen6x.c
index 96e2b74..e795492 100644
--- a/board/boundary/nitrogen6x/nitrogen6x.c
+++ b/board/boundary/nitrogen6x/nitrogen6x.c
@@ -28,6 +28,8 @@
#include asm/arch/crm_regs.h
#include asm/arch/mxc_hdmi.h
#include i2c.h
+#include input.h
+#include netdev.h
DECLARE_GLOBAL_DATA_PTR;
#define GP_USB_OTG_PWR IMX_GPIO_NR(3, 22)
@@ -70,12 +72,12 @@ int dram_init(void)
return 0;
}
-iomux_v3_cfg_t const uart1_pads[] = {
+static iomux_v3_cfg_t const uart1_pads[] = {
MX6_PAD_SD3_DAT6__UART1_RX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL),
MX6_PAD_SD3_DAT7__UART1_TX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL),
};
-iomux_v3_cfg_t const uart2_pads[] = {
+static iomux_v3_cfg_t const uart2_pads[] = {
MX6_PAD_EIM_D26__UART2_TX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL),
MX6_PAD_EIM_D27__UART2_RX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL),
};
@@ -83,7 +85,7 @@ iomux_v3_cfg_t const uart2_pads[] = {
#define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
/* I2C1, SGTL5000 */
-struct i2c_pads_info i2c_pad_info0 = {
+static struct i2c_pads_info i2c_pad_info0 = {
.scl = {
.i2c_mode = MX6_PAD_EIM_D21__I2C1_SCL | PC,
.gpio_mode = MX6_PAD_EIM_D21__GPIO3_IO21 | PC,
@@ -97,7 +99,7 @@ struct i2c_pads_info i2c_pad_info0 = {
};
/* I2C2 Camera, MIPI */
-struct i2c_pads_info i2c_pad_info1 = {
+static struct i2c_pads_info i2c_pad_info1 = {
.scl = {
.i2c_mode = MX6_PAD_KEY_COL3__I2C2_SCL | PC,
.gpio_mode = MX6_PAD_KEY_COL3__GPIO4_IO12 | PC,
@@ -111,7 +113,7 @@ struct i2c_pads_info i2c_pad_info1 = {
};
/* I2C3, J15 - RGB connector */
-struct i2c_pads_info i2c_pad_info2 = {
+static struct i2c_pads_info i2c_pad_info2 = {
.scl = {
.i2c_mode = MX6_PAD_GPIO_5__I2C3_SCL | PC,
.gpio_mode = MX6_PAD_GPIO_5__GPIO1_IO05 | PC,
@@ -133,7 +135,7 @@ static iomux_v3_cfg_t const usdhc2_pads[] = {
MX6_PAD_SD2_DAT3__SD2_DATA3 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
};
-iomux_v3_cfg_t const usdhc3_pads[] = {
+static iomux_v3_cfg_t const usdhc3_pads[] = {
MX6_PAD_SD3_CLK__SD3_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL),
MX6_PAD_SD3_CMD__SD3_CMD | MUX_PAD_CTRL(USDHC_PAD_CTRL),
MX6_PAD_SD3_DAT0__SD3_DATA0 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
@@ -143,7 +145,7 @@ iomux_v3_cfg_t const usdhc3_pads[] = {
MX6_PAD_SD3_DAT5__GPIO7_IO00| MUX_PAD_CTRL(NO_PAD_CTRL), /* CD */
};
-iomux_v3_cfg_t const usdhc4_pads[] = {
+static iomux_v3_cfg_t const usdhc4_pads[] = {
MX6_PAD_SD4_CLK__SD4_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL),
MX6_PAD_SD4_CMD__SD4_CMD | MUX_PAD_CTRL(USDHC_PAD_CTRL),
MX6_PAD_SD4_DAT0__SD4_DATA0 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
@@ -153,7 +155,7 @@ iomux_v3_cfg_t const usdhc4_pads[] = {
MX6_PAD_NANDF_D6__GPIO2_IO06| MUX_PAD_CTRL(NO_PAD_CTRL), /* CD */
};
-iomux_v3_cfg_t const enet_pads1[] = {
+static iomux_v3_cfg_t const enet_pads1[] = {
MX6_PAD_ENET_MDIO__ENET_MDIO| MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_ENET_MDC__ENET_MDC | MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_RGMII_TXC__RGMII_TXC| MUX_PAD_CTRL(ENET_PAD_CTRL),
@@ -180,7 +182,7 @@ iomux_v3_cfg_t const enet_pads1[] = {
MX6_PAD_ENET_RXD0__GPIO1_IO27 | MUX_PAD_CTRL(NO_PAD_CTRL),
};
-iomux_v3_cfg_t const enet_pads2[] = {
+static iomux_v3_cfg_t const enet_pads2[] = {
MX6_PAD_RGMII_RXC__RGMII_RXC| MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_RGMII_RD0__RGMII_RD0| MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_RGMII_RD1__RGMII_RD1| MUX_PAD_CTRL(ENET_PAD_CTRL),
@@ -198,7 +200,7 @@ static iomux_v3_cfg_t const misc_pads[] = {
};
/* wl1271 pads on nitrogen6x */
-iomux_v3_cfg_t const wl12xx_pads[] = {
+static iomux_v3_cfg_t const wl12xx_pads[] = {
(MX6_PAD_NANDF_CS1__GPIO6_IO14 ~MUX_PAD_CTRL_MASK)
| MUX_PAD_CTRL(WEAK_PULLDOWN),
(MX6_PAD_NANDF_CS2__GPIO6_IO15 ~MUX_PAD_CTRL_MASK)
@@ -246,7 +248,7 @@ static void setup_iomux_enet(void)
imx_iomux_v3_setup_multiple_pads(enet_pads2, ARRAY_SIZE(enet_pads2));
}
-iomux_v3_cfg_t const usb_pads[] = {
+static iomux_v3_cfg_t const usb_pads[] = {
MX6_PAD_GPIO_17__GPIO7_IO12 | MUX_PAD_CTRL(NO_PAD_CTRL),
};
@@ -280,7 +282,7 @@ int board_ehci_power(int port, int on)
#endif
#ifdef CONFIG_FSL_ESDHC
-struct fsl_esdhc_cfg usdhc_cfg[2] = {
+static struct fsl_esdhc_cfg usdhc_cfg[2] = {
{USDHC3_BASE_ADDR},
{USDHC4_BASE_ADDR},
};
@@ -331,7 +333,7 @@ int board_mmc_init(bd_t *bis)
#endif
#ifdef
[U-Boot] [PATCH 07/32] nitrogen6x: Allow U-Boot to be silent on UART2
Several customers are using UART2 (normally the serial console
for U-Boot) as connections to printers or other peripherals
that are not tolerant of stray inputs during reset.
Provide a simple way to eliminate output on the serial port
by conditionally configuring these pads as GPIOs during
U-Boot.
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
---
board/boundary/nitrogen6x/nitrogen6x.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/board/boundary/nitrogen6x/nitrogen6x.c
b/board/boundary/nitrogen6x/nitrogen6x.c
index e795492..621cdbc 100644
--- a/board/boundary/nitrogen6x/nitrogen6x.c
+++ b/board/boundary/nitrogen6x/nitrogen6x.c
@@ -77,9 +77,15 @@ static iomux_v3_cfg_t const uart1_pads[] = {
MX6_PAD_SD3_DAT7__UART1_TX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL),
};
+/* #define CONFIG_SILENT_UART */
static iomux_v3_cfg_t const uart2_pads[] = {
+#ifndef CONFIG_SILENT_UART
MX6_PAD_EIM_D26__UART2_TX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL),
MX6_PAD_EIM_D27__UART2_RX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL),
+#else
+ MX6_PAD_EIM_D26__GPIO3_IO26 | MUX_PAD_CTRL(UART_PAD_CTRL),
+ MX6_PAD_EIM_D27__GPIO3_IO27 | MUX_PAD_CTRL(UART_PAD_CTRL),
+#endif
};
#define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 08/32] nitrogen6x: phy: add 100 us delay after phy reset
From: Troy Kisky troy.ki...@boundarydevices.com
Testing shows that the Micrel PHY may not be completely out
of reset if accessed immediately.
Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
---
board/boundary/nitrogen6x/nitrogen6x.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/board/boundary/nitrogen6x/nitrogen6x.c
b/board/boundary/nitrogen6x/nitrogen6x.c
index 621cdbc..465f88f 100644
--- a/board/boundary/nitrogen6x/nitrogen6x.c
+++ b/board/boundary/nitrogen6x/nitrogen6x.c
@@ -252,6 +252,7 @@ static void setup_iomux_enet(void)
gpio_set_value(IMX_GPIO_NR(1, 27), 1); /* Nitrogen6X PHY reset */
imx_iomux_v3_setup_multiple_pads(enet_pads2, ARRAY_SIZE(enet_pads2));
+ udelay(100);/* Wait 100 us before using mii interface */
}
static iomux_v3_cfg_t const usb_pads[] = {
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 09/32] nitrogen6x: prevent warnings about board_ehci* callbacks
Include declarations of board_ehci callbacks to prevent compiler warnings and enforce function prototypes. Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com --- board/boundary/nitrogen6x/nitrogen6x.c | 1 + 1 file changed, 1 insertion(+) diff --git a/board/boundary/nitrogen6x/nitrogen6x.c b/board/boundary/nitrogen6x/nitrogen6x.c index 465f88f..2e945a4 100644 --- a/board/boundary/nitrogen6x/nitrogen6x.c +++ b/board/boundary/nitrogen6x/nitrogen6x.c @@ -30,6 +30,7 @@ #include i2c.h #include input.h #include netdev.h +#include usb/ehci-fsl.h DECLARE_GLOBAL_DATA_PTR; #define GP_USB_OTG_PWR IMX_GPIO_NR(3, 22) -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 10/32] nitrogen6x: display: add support lvds jeida screen
From: Robert Winkler robert.wink...@boundarydevices.com
Add support for Boundary Devices 7 and 10.1 1280x800 displays with
integrated FocalTech ft5x06 10-point touch controller.
Because they share the touch controller with the 1024x600 displays,
auto-detection is disabled and you must explicitly set the 'panel'
environment variable:
U-Boot setenv panel LDB-WXGA
U-Boot saveenv reset
Signed-off-by: Robert Winkler robert.wink...@boundarydevices.com
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
---
board/boundary/nitrogen6x/nitrogen6x.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/board/boundary/nitrogen6x/nitrogen6x.c
b/board/boundary/nitrogen6x/nitrogen6x.c
index 2e945a4..336a6f9 100644
--- a/board/boundary/nitrogen6x/nitrogen6x.c
+++ b/board/boundary/nitrogen6x/nitrogen6x.c
@@ -480,6 +480,17 @@ static void enable_lvds(struct display_info_t const *dev)
gpio_direction_output(LVDS_BACKLIGHT_GP, 1);
}
+static void enable_lvds_jeida(struct display_info_t const *dev)
+{
+ struct iomuxc *iomux = (struct iomuxc *)
+ IOMUXC_BASE_ADDR;
+ u32 reg = readl(iomux-gpr[2]);
+ reg |= IOMUXC_GPR2_DATA_WIDTH_CH0_24BIT
+|IOMUXC_GPR2_BIT_MAPPING_CH0_JEIDA;
+ writel(reg, iomux-gpr[2]);
+ gpio_direction_output(LVDS_BACKLIGHT_GP, 1);
+}
+
static void enable_rgb(struct display_info_t const *dev)
{
imx_iomux_v3_setup_multiple_pads(
@@ -509,6 +520,26 @@ struct display_info_t const displays[] = {{
.sync = FB_SYNC_EXT,
.vmode = FB_VMODE_NONINTERLACED
} }, {
+ .bus= 0,
+ .addr = 0,
+ .pixfmt = IPU_PIX_FMT_RGB24,
+ .detect = NULL,
+ .enable = enable_lvds_jeida,
+ .mode = {
+ .name = LDB-WXGA,
+ .refresh= 60,
+ .xres = 1280,
+ .yres = 800,
+ .pixclock = 14065,
+ .left_margin= 40,
+ .right_margin = 40,
+ .upper_margin = 3,
+ .lower_margin = 80,
+ .hsync_len = 10,
+ .vsync_len = 10,
+ .sync = FB_SYNC_EXT,
+ .vmode = FB_VMODE_NONINTERLACED
+} }, {
.bus= 2,
.addr = 0x4,
.pixfmt = IPU_PIX_FMT_LVDS666,
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 11/32] nitrogen6x: display: add qvga panel
Add support for a 1/4 VGA panel with a 24-bit RGB interface.
No auto-detection is enabled, so you must configure the 'panel'
environment variable to use this display:
U-Boot setenv panel qvga
U-Boot saveenv reset
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
---
board/boundary/nitrogen6x/nitrogen6x.c | 20
1 file changed, 20 insertions(+)
diff --git a/board/boundary/nitrogen6x/nitrogen6x.c
b/board/boundary/nitrogen6x/nitrogen6x.c
index 336a6f9..b2218c9f 100644
--- a/board/boundary/nitrogen6x/nitrogen6x.c
+++ b/board/boundary/nitrogen6x/nitrogen6x.c
@@ -599,6 +599,26 @@ struct display_info_t const displays[] = {{
.vsync_len = 10,
.sync = 0,
.vmode = FB_VMODE_NONINTERLACED
+} }, {
+ .bus= 0,
+ .addr = 0,
+ .pixfmt = IPU_PIX_FMT_RGB24,
+ .detect = NULL,
+ .enable = enable_rgb,
+ .mode = {
+ .name = qvga,
+ .refresh= 60,
+ .xres = 320,
+ .yres = 240,
+ .pixclock = 37037,
+ .left_margin= 38,
+ .right_margin = 37,
+ .upper_margin = 16,
+ .lower_margin = 15,
+ .hsync_len = 30,
+ .vsync_len = 3,
+ .sync = 0,
+ .vmode = FB_VMODE_NONINTERLACED
} } };
size_t display_count = ARRAY_SIZE(displays);
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 12/32] nitrogen6x: display: add support for LG-9.7 LVDS display
Add support for LG 9.7 LVDS panel (1024x768) with integrated eGalax
touch screen.
Note that this panel differs only slightly from the Hannstar XGA panel
(margins).
No auto-detection is available because it shares the same touch controller
as the Hannstar-XGA display, so you'll need to configure it through the
'panel' environment variable:
U-Boot setenv panel LG-9.7
U-Boot saveenv reset
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
---
board/boundary/nitrogen6x/nitrogen6x.c | 20
1 file changed, 20 insertions(+)
diff --git a/board/boundary/nitrogen6x/nitrogen6x.c
b/board/boundary/nitrogen6x/nitrogen6x.c
index b2218c9f..fd214ca 100644
--- a/board/boundary/nitrogen6x/nitrogen6x.c
+++ b/board/boundary/nitrogen6x/nitrogen6x.c
@@ -560,6 +560,26 @@ struct display_info_t const displays[] = {{
.sync = FB_SYNC_EXT,
.vmode = FB_VMODE_NONINTERLACED
} }, {
+ .bus= 0,
+ .addr = 0,
+ .pixfmt = IPU_PIX_FMT_LVDS666,
+ .detect = NULL,
+ .enable = enable_lvds,
+ .mode = {
+ .name = LG-9.7,
+ .refresh= 60,
+ .xres = 1024,
+ .yres = 768,
+ .pixclock = 15385, /* ~65MHz */
+ .left_margin= 480,
+ .right_margin = 260,
+ .upper_margin = 16,
+ .lower_margin = 6,
+ .hsync_len = 250,
+ .vsync_len = 10,
+ .sync = FB_SYNC_EXT,
+ .vmode = FB_VMODE_NONINTERLACED
+} }, {
.bus= 2,
.addr = 0x38,
.pixfmt = IPU_PIX_FMT_LVDS666,
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 14/32] nitrogen6x: display: add support for fusion 7 display
Add support for the Touch Revolution Fusion7 display: 800x480 RGB
with a custom F0710A resistive touch controller.
Auto-detection of this panel is supported so no configuration is
required.
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
---
board/boundary/nitrogen6x/nitrogen6x.c | 20
1 file changed, 20 insertions(+)
diff --git a/board/boundary/nitrogen6x/nitrogen6x.c
b/board/boundary/nitrogen6x/nitrogen6x.c
index 261fa7e..b1d85da 100644
--- a/board/boundary/nitrogen6x/nitrogen6x.c
+++ b/board/boundary/nitrogen6x/nitrogen6x.c
@@ -621,6 +621,26 @@ struct display_info_t const displays[] = {{
.vmode = FB_VMODE_NONINTERLACED
} }, {
.bus= 2,
+ .addr = 0x10,
+ .pixfmt = IPU_PIX_FMT_RGB666,
+ .detect = detect_i2c,
+ .enable = enable_rgb,
+ .mode = {
+ .name = fusion7,
+ .refresh= 60,
+ .xres = 800,
+ .yres = 480,
+ .pixclock = 33898,
+ .left_margin= 96,
+ .right_margin = 24,
+ .upper_margin = 3,
+ .lower_margin = 10,
+ .hsync_len = 72,
+ .vsync_len = 7,
+ .sync = 0x4002,
+ .vmode = FB_VMODE_NONINTERLACED
+} }, {
+ .bus= 2,
.addr = 0x48,
.pixfmt = IPU_PIX_FMT_RGB666,
.detect = detect_i2c,
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 15/32] nitrogen6x: display: add svga display (800x600)
Add support for 800x600 18-bit RGB displays using VESA GTF timings.
No auto-detection is supported, so you must configure this panel
manually through the 'panel' environment variable:
U-Boot setenv panel svga
U-Boot saveenv reset
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
---
board/boundary/nitrogen6x/nitrogen6x.c | 20
1 file changed, 20 insertions(+)
diff --git a/board/boundary/nitrogen6x/nitrogen6x.c
b/board/boundary/nitrogen6x/nitrogen6x.c
index b1d85da..6695f87 100644
--- a/board/boundary/nitrogen6x/nitrogen6x.c
+++ b/board/boundary/nitrogen6x/nitrogen6x.c
@@ -640,6 +640,26 @@ struct display_info_t const displays[] = {{
.sync = 0x4002,
.vmode = FB_VMODE_NONINTERLACED
} }, {
+ .bus= 0,
+ .addr = 0,
+ .pixfmt = IPU_PIX_FMT_RGB666,
+ .detect = NULL,
+ .enable = enable_rgb,
+ .mode = {
+ .name = svga,
+ .refresh= 60,
+ .xres = 800,
+ .yres = 600,
+ .pixclock = 15385,
+ .left_margin= 220,
+ .right_margin = 40,
+ .upper_margin = 21,
+ .lower_margin = 7,
+ .hsync_len = 60,
+ .vsync_len = 10,
+ .sync = 0,
+ .vmode = FB_VMODE_NONINTERLACED
+} }, {
.bus= 2,
.addr = 0x48,
.pixfmt = IPU_PIX_FMT_RGB666,
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 13/32] nitrogen6x: display: add LDB-WXGA-S for SPWG 1280x800 displays
This patch adds support for LVDS WXGA displays that use the SPWG encoding
standard instead of JEIDA.
No auto-detection is enabled and you must explicitly set the 'panel'
environment variable:
U-Boot setenv panel LDB-WXGA-S
U-Boot saveenv reset
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
---
board/boundary/nitrogen6x/nitrogen6x.c | 20
1 file changed, 20 insertions(+)
diff --git a/board/boundary/nitrogen6x/nitrogen6x.c
b/board/boundary/nitrogen6x/nitrogen6x.c
index fd214ca..261fa7e 100644
--- a/board/boundary/nitrogen6x/nitrogen6x.c
+++ b/board/boundary/nitrogen6x/nitrogen6x.c
@@ -540,6 +540,26 @@ struct display_info_t const displays[] = {{
.sync = FB_SYNC_EXT,
.vmode = FB_VMODE_NONINTERLACED
} }, {
+ .bus= 0,
+ .addr = 0,
+ .pixfmt = IPU_PIX_FMT_RGB24,
+ .detect = NULL,
+ .enable = enable_lvds,
+ .mode = {
+ .name = LDB-WXGA-S,
+ .refresh= 60,
+ .xres = 1280,
+ .yres = 800,
+ .pixclock = 14065,
+ .left_margin= 40,
+ .right_margin = 40,
+ .upper_margin = 3,
+ .lower_margin = 80,
+ .hsync_len = 10,
+ .vsync_len = 10,
+ .sync = FB_SYNC_EXT,
+ .vmode = FB_VMODE_NONINTERLACED
+} }, {
.bus= 2,
.addr = 0x4,
.pixfmt = IPU_PIX_FMT_LVDS666,
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 16/32] nitrogen6x: display: add Ampire 1024x600 panel
Add support for an Ampire 1024x600 LVDS panel with integrated Ilitek
capacitive touch screen.
Auto-detection is enabled, so no explicit configuration is needed.
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
---
board/boundary/nitrogen6x/nitrogen6x.c | 20
1 file changed, 20 insertions(+)
diff --git a/board/boundary/nitrogen6x/nitrogen6x.c
b/board/boundary/nitrogen6x/nitrogen6x.c
index 6695f87..c91e0c4 100644
--- a/board/boundary/nitrogen6x/nitrogen6x.c
+++ b/board/boundary/nitrogen6x/nitrogen6x.c
@@ -661,6 +661,26 @@ struct display_info_t const displays[] = {{
.vmode = FB_VMODE_NONINTERLACED
} }, {
.bus= 2,
+ .addr = 0x41,
+ .pixfmt = IPU_PIX_FMT_LVDS666,
+ .detect = detect_i2c,
+ .enable = enable_lvds,
+ .mode = {
+ .name = amp1024x600,
+ .refresh= 60,
+ .xres = 1024,
+ .yres = 600,
+ .pixclock = 15385,
+ .left_margin= 220,
+ .right_margin = 40,
+ .upper_margin = 21,
+ .lower_margin = 7,
+ .hsync_len = 60,
+ .vsync_len = 10,
+ .sync = FB_SYNC_EXT,
+ .vmode = FB_VMODE_NONINTERLACED
+} }, {
+ .bus= 2,
.addr = 0x48,
.pixfmt = IPU_PIX_FMT_RGB666,
.detect = detect_i2c,
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 17/32] nitrogen6x: display: add wvga-lvds panel
Add support for WVGA (800x480) panels using VESA GTF timings over
LVDS.
No auto-detection is supported, so you must configure this panel
manually through the 'panel' environment variable:
U-Boot setenv panel svga
U-Boot saveenv reset
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
---
board/boundary/nitrogen6x/nitrogen6x.c | 20
1 file changed, 20 insertions(+)
diff --git a/board/boundary/nitrogen6x/nitrogen6x.c
b/board/boundary/nitrogen6x/nitrogen6x.c
index c91e0c4..115ee81 100644
--- a/board/boundary/nitrogen6x/nitrogen6x.c
+++ b/board/boundary/nitrogen6x/nitrogen6x.c
@@ -680,6 +680,26 @@ struct display_info_t const displays[] = {{
.sync = FB_SYNC_EXT,
.vmode = FB_VMODE_NONINTERLACED
} }, {
+ .bus= 0,
+ .addr = 0,
+ .pixfmt = IPU_PIX_FMT_LVDS666,
+ .detect = 0,
+ .enable = enable_lvds,
+ .mode = {
+ .name = wvga-lvds,
+ .refresh= 57,
+ .xres = 800,
+ .yres = 480,
+ .pixclock = 15385,
+ .left_margin= 220,
+ .right_margin = 40,
+ .upper_margin = 21,
+ .lower_margin = 7,
+ .hsync_len = 60,
+ .vsync_len = 10,
+ .sync = FB_SYNC_EXT,
+ .vmode = FB_VMODE_NONINTERLACED
+} }, {
.bus= 2,
.addr = 0x48,
.pixfmt = IPU_PIX_FMT_RGB666,
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 20/32] nitrogen6x: config: allow boot to USB stick
From: Diego Rondini diego.rond...@kynetics.it
This patch enables boot to USB storage devices by expanding on the list
of boot devices.
Because the USB startup currently takes a long time, it places USB at
the end of the list of supported devices.
You can over-ride the boot order using the bootdevs environment variable.
For instance, this will make USB the first (highest priority) device:
U-Boot setenv bootdevs usb mmc sata
U-Boot saveenv
Signed-off-by: Diego Rondini diego.rond...@kynetics.it
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
---
include/configs/nitrogen6x.h | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h
index 5e9b743..21a25e0 100644
--- a/include/configs/nitrogen6x.h
+++ b/include/configs/nitrogen6x.h
@@ -173,7 +173,13 @@
#define CONFIG_DRIVE_MMC
#endif
-#define CONFIG_DRIVE_TYPES CONFIG_DRIVE_SATA CONFIG_DRIVE_MMC
+#ifdef CONFIG_USB_STORAGE
+#define CONFIG_DRIVE_USB usb
+#else
+#define CONFIG_DRIVE_USB
+#endif
+
+#define CONFIG_DRIVE_TYPES CONFIG_DRIVE_SATA CONFIG_DRIVE_MMC CONFIG_DRIVE_USB
#if defined(CONFIG_SABRELITE)
#define CONFIG_EXTRA_ENV_SETTINGS \
@@ -253,12 +259,16 @@
run netboot;
#else
#define CONFIG_EXTRA_ENV_SETTINGS \
+ bootdevs= CONFIG_DRIVE_TYPES \0 \
console=ttymxc1\0 \
clearenv=if sf probe || sf probe || sf probe 1 ; then \
sf erase 0xc 0x2000 \
echo restored environment to factory default ; fi\0 \
- bootcmd=for dtype in CONFIG_DRIVE_TYPES \
+ bootcmd=for dtype in ${bootdevs} \
; do \
+ if itest.s \xusb\ == \x${dtype}\ ; then \
+ usb start ; \
+ fi; \
for disk in 0 1 ; do ${dtype} dev ${disk} ; \
for fs in fat ext2 ; do \
${fs}load \
@@ -274,7 +284,7 @@
echo ; echo serial console at 115200, 8N1 ; echo ; \
echo details at http://boundarydevices.com/6q_bootscript ; \
setenv stdout serial\0 \
- upgradeu=for dtype in CONFIG_DRIVE_TYPES \
+ upgradeu=for dtype in ${bootdevs} \
; do \
for disk in 0 1 ; do ${dtype} dev ${disk} ; \
for fs in fat ext2 ; do \
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 21/32] nitrogen6x: config: use FS_GENERIC load command
From: Kevin Mihelich ke...@archlinuxarm.org
Remove the individual attempts to load using ext2 and fat, replace with the
generic load command supporting available filesystem types.
Signed-off-by: Kevin Mihelich ke...@archlinuxarm.org
---
include/configs/nitrogen6x.h | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h
index 21a25e0..2167d77 100644
--- a/include/configs/nitrogen6x.h
+++ b/include/configs/nitrogen6x.h
@@ -270,13 +270,11 @@
usb start ; \
fi; \
for disk in 0 1 ; do ${dtype} dev ${disk} ; \
- for fs in fat ext2 ; do \
- ${fs}load \
- ${dtype} ${disk}:1 \
- 10008000 \
- /6x_bootscript \
-source 10008000 ; \
- done ; \
+ load \
+ ${dtype} ${disk}:1 \
+ 10008000 \
+ /6x_bootscript \
+source 10008000 ; \
done ; \
done; \
setenv stdout serial,vga ; \
@@ -287,11 +285,9 @@
upgradeu=for dtype in ${bootdevs} \
; do \
for disk in 0 1 ; do ${dtype} dev ${disk} ; \
-for fs in fat ext2 ; do \
- ${fs}load ${dtype} ${disk}:1 10008000 \
- /6x_upgrade \
-source 10008000 ; \
- done ; \
+ load ${dtype} ${disk}:1 10008000 \
+ /6x_upgrade \
+source 10008000 ; \
done ; \
done\0 \
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 18/32] nitrogen6x: display use I2C detect for HDMI
The HPD pin and RX_SENSE registers have proven to be less reliable
than using I2C on the EDID pins for detection of an HDMI monitor.
In particular, when the HDMI output is reset through a reboot
cycle, the detect_hdmi() routine often bounces, resulting in
a failure to detect a connected monitor.
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
---
board/boundary/nitrogen6x/nitrogen6x.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/board/boundary/nitrogen6x/nitrogen6x.c
b/board/boundary/nitrogen6x/nitrogen6x.c
index 115ee81..269d62e 100644
--- a/board/boundary/nitrogen6x/nitrogen6x.c
+++ b/board/boundary/nitrogen6x/nitrogen6x.c
@@ -500,10 +500,10 @@ static void enable_rgb(struct display_info_t const *dev)
}
struct display_info_t const displays[] = {{
- .bus= -1,
- .addr = 0,
+ .bus= 1,
+ .addr = 0x50,
.pixfmt = IPU_PIX_FMT_RGB24,
- .detect = detect_hdmi,
+ .detect = detect_i2c,
.enable = do_enable_hdmi,
.mode = {
.name = HDMI,
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 19/32] nitrogen6x: config: add USB Mass Storage (ums) support
Add support for the USB mass storage to enable access to on-board storage (especially eMMC and SATA). Details at: http://boundarydevices.com/u-boot-usb-mass-storage-gadget/ Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com --- include/configs/nitrogen6x.h | 13 + 1 file changed, 13 insertions(+) diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h index 2a1eb3b..5e9b743 100644 --- a/include/configs/nitrogen6x.h +++ b/include/configs/nitrogen6x.h @@ -368,4 +368,17 @@ #define CONFIG_PCIE_IMX #endif +#define CONFIG_CMD_ELF + +#define CONFIG_USB_GADGET +#define CONFIG_CMD_USB_MASS_STORAGE +#define CONFIG_USB_GADGET_MASS_STORAGE +#define CONFIG_USBDOWNLOAD_GADGET +#define CONFIG_USB_GADGET_VBUS_DRAW2 + +/* Netchip IDs */ +#define CONFIG_G_DNL_VENDOR_NUM 0x0525 +#define CONFIG_G_DNL_PRODUCT_NUM 0xa4a5 +#define CONFIG_G_DNL_MANUFACTURER Boundary + #endif/* __CONFIG_H */ -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 25/32] nitrogen6x: config: add CONFIG_CMD_MEMTEST
Enable the 'mtest' command on Nitrogen6x and SABRE Lite boards. Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com --- include/configs/nitrogen6x.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h index d505191..82dc0fc 100644 --- a/include/configs/nitrogen6x.h +++ b/include/configs/nitrogen6x.h @@ -382,6 +382,7 @@ #define CONFIG_CMD_BMP #define CONFIG_CMD_TIME +#define CONFIG_CMD_MEMTEST #define CONFIG_SYS_ALT_MEMTEST #define CONFIG_CMD_BOOTZ -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 23/32] nitrogen6x: config: expose SATA, then MMC over USB
If no boot script was found, expose internal storage over the
USB mass storage gadget to allow easy programming.
This is especially useful when SD cards are inaccessible or when
loading SATA drives.
More details are available in this blog post:
http://boundarydevices.com/u-boot-usb-mass-storage-gadget/
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
---
include/configs/nitrogen6x.h | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h
index 3c24443..b31b922 100644
--- a/include/configs/nitrogen6x.h
+++ b/include/configs/nitrogen6x.h
@@ -180,6 +180,7 @@
#endif
#define CONFIG_DRIVE_TYPES CONFIG_DRIVE_SATA CONFIG_DRIVE_MMC CONFIG_DRIVE_USB
+#define CONFIG_UMSDEVS CONFIG_DRIVE_SATA CONFIG_DRIVE_MMC
#if defined(CONFIG_SABRELITE)
#define CONFIG_EXTRA_ENV_SETTINGS \
@@ -260,6 +261,7 @@
#else
#define CONFIG_EXTRA_ENV_SETTINGS \
bootdevs= CONFIG_DRIVE_TYPES \0 \
+ umsdevs= CONFIG_UMSDEVS \0 \
console=ttymxc1\0 \
clearenv=if sf probe || sf probe || sf probe 1 ; then \
sf erase 0xc 0x2000 \
@@ -281,7 +283,26 @@
echo ; echo 6x_bootscript not found ; \
echo ; echo serial console at 115200, 8N1 ; echo ; \
echo details at http://boundarydevices.com/6q_bootscript ; \
- setenv stdout serial\0 \
+ setenv stdout serial; \
+ setenv stdin serial,usbkbd; \
+ for dtype in ${umsdevs} ; do \
+ if itest.s sata == ${dtype}; then \
+ initcmd='sata init' ; \
+ else \
+ initcmd='mmc rescan' ; \
+ fi; \
+ for disk in 0 1 ; do \
+ if $initcmd $dtype dev $disk ; then \
+ setenv stdout serial,vga; \
+ echo expose ${dtype} ${disk} \
+ over USB; \
+ ums 0 $dtype $disk ; \
+ fi; \
+ done; \
+ done ; \
+ setenv stdout serial,vga; \
+ echo no block devices found; \
+ \0 \
initrd_high=0x\0 \
upgradeu=for dtype in ${bootdevs} \
; do \
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 22/32] nitrogen6x: config: add initrd_high
Support RAM disks by setting initrd_high. See commit 7e9603e
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
---
include/configs/nitrogen6x.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h
index 2167d77..3c24443 100644
--- a/include/configs/nitrogen6x.h
+++ b/include/configs/nitrogen6x.h
@@ -282,6 +282,7 @@
echo ; echo serial console at 115200, 8N1 ; echo ; \
echo details at http://boundarydevices.com/6q_bootscript ; \
setenv stdout serial\0 \
+ initrd_high=0x\0 \
upgradeu=for dtype in ${bootdevs} \
; do \
for disk in 0 1 ; do ${dtype} dev ${disk} ; \
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 24/32] nitrogen6x: config: enable USB keyboard support
Enable the use of USB keyboards on SABRE Lite and Nitrogen6x boards. Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com --- include/configs/nitrogen6x.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h index b31b922..d505191 100644 --- a/include/configs/nitrogen6x.h +++ b/include/configs/nitrogen6x.h @@ -122,6 +122,8 @@ #define CONFIG_EHCI_HCD_INIT_AFTER_RESET /* For OTG port */ #define CONFIG_MXC_USB_PORTSC (PORT_PTS_UTMI | PORT_PTS_PTW) #define CONFIG_MXC_USB_FLAGS 0 +#define CONFIG_USB_KEYBOARD +#define CONFIG_SYS_USB_EVENT_POLL_VIA_CONTROL_EP /* Miscellaneous commands */ #define CONFIG_CMD_BMODE -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 30/32] nitrogen6x: config: add gpio command
Enable the 'gpio' command to allow reading and toggling of GPIO pins. Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com --- include/configs/nitrogen6x.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h index 8afbded..df3e2bb 100644 --- a/include/configs/nitrogen6x.h +++ b/include/configs/nitrogen6x.h @@ -32,6 +32,7 @@ #define CONFIG_BOARD_EARLY_INIT_F #define CONFIG_MISC_INIT_R #define CONFIG_MXC_GPIO +#define CONFIG_CMD_GPIO #define CONFIG_CI_UDC #define CONFIG_USBD_HS #define CONFIG_USB_GADGET_DUALSPEED -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 27/32] nitrogen6x: config: allow more bootargs parameters
From: Troy Kisky troy.ki...@boundarydevices.com Increase the maximum number of arguments allowed by the Hush parser. This prevents errors when users or scripts aren't quoting parameters when setting the bootargs variable et al. Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com --- include/configs/nitrogen6x.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h index b911d06..50b6c5a 100644 --- a/include/configs/nitrogen6x.h +++ b/include/configs/nitrogen6x.h @@ -326,7 +326,7 @@ /* Print Buffer Size */ #define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE + sizeof(CONFIG_SYS_PROMPT) + 16) -#define CONFIG_SYS_MAXARGS16 +#define CONFIG_SYS_MAXARGS48 #define CONFIG_SYS_BARGSIZE CONFIG_SYS_CBSIZE #define CONFIG_SYS_MEMTEST_START 0x1000 -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 28/32] nitrogen6x: config: disable logo
Some users (QNX and Windows CE users in particular) have asked to disable the Penguin shown on the display at boot time. Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com --- include/configs/nitrogen6x.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h index 50b6c5a..60c942f 100644 --- a/include/configs/nitrogen6x.h +++ b/include/configs/nitrogen6x.h @@ -140,7 +140,6 @@ #define CONFIG_VIDEO_BMP_RLE8 #define CONFIG_SPLASH_SCREEN #define CONFIG_BMP_16BPP -#define CONFIG_VIDEO_LOGO #define CONFIG_IPUV3_CLK 26000 #define CONFIG_CMD_HDMIDETECT #define CONFIG_CONSOLE_MUX -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 29/32] nitrogen6x: config: configure usb_ether
Provide fixed USB networking mac addresses for host and client to enable
static configuration of host network stacks.
Include a command 'usbrecover' both to illustrate the use of the USB
ethernet gadget and also to allow quick booting of a kernel (uImage)
and ram disk (uramdisk).
Details and commentary are available here:
http://boundarydevices.com/u-boot-2014-01/#usbrecover
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
---
include/configs/nitrogen6x.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h
index 60c942f..8afbded 100644
--- a/include/configs/nitrogen6x.h
+++ b/include/configs/nitrogen6x.h
@@ -314,6 +314,16 @@
source 10008000 ; \
done ; \
done\0 \
+ usbnet_devaddr=00:19:b8:00:00:02\0 \
+ usbnet_hostaddr=00:19:b8:00:00:01\0 \
+ usbrecover=setenv ethact usb_ether; \
+ setenv ipaddr 10.0.0.2; \
+ setenv netmask 255.255.255.0; \
+ setenv serverip 10.0.0.1; \
+ setenv bootargs console=ttymxc1,115200; \
+ tftpboot 1080 10.0.0.1:uImage-${board}-recovery \
+ tftpboot 1280 10.0.0.1:uramdisk-${board}-recovery.img \
+bootm 1080 1280\0 \
#endif
/* Miscellaneous configurable options */
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 26/32] nitrogen6x: config: enable i2c edid
Enable the i2c edid command to query data from an attached HDMI monitor. Usage is typically this: U-Boot i2c dev 1 U-Boot i2c edid 0x50 ... Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com --- include/configs/nitrogen6x.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h index 82dc0fc..b911d06 100644 --- a/include/configs/nitrogen6x.h +++ b/include/configs/nitrogen6x.h @@ -63,6 +63,7 @@ #define CONFIG_SYS_I2C #define CONFIG_SYS_I2C_MXC #define CONFIG_SYS_I2C_SPEED 10 +#define CONFIG_I2C_EDID /* MMC Configs */ #define CONFIG_FSL_ESDHC -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 31/32] nitrogen6x: config: enable Android fastboot
Enable 'fastboot' command. This is currently enabled but not yet functional. Including it in the configuration will ease further testing and development as discussed on the mailing list. Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com --- include/configs/nitrogen6x.h | 5 + 1 file changed, 5 insertions(+) diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h index df3e2bb..f465d9e 100644 --- a/include/configs/nitrogen6x.h +++ b/include/configs/nitrogen6x.h @@ -423,4 +423,9 @@ #define CONFIG_G_DNL_PRODUCT_NUM 0xa4a5 #define CONFIG_G_DNL_MANUFACTURER Boundary +#define CONFIG_CMD_FASTBOOT +#define CONFIG_ANDROID_BOOT_IMAGE +#define CONFIG_USB_FASTBOOT_BUF_ADDR CONFIG_SYS_LOAD_ADDR +#define CONFIG_USB_FASTBOOT_BUF_SIZE 0x0700 + #endif/* __CONFIG_H */ -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 32/32] nitrogen6x: config: enable EXT4 filesystem
From: Kevin Mihelich ke...@archlinuxarm.org Support reading/writing ext4 partitions. Signed-off-by: Kevin Mihelich ke...@archlinuxarm.org Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com --- include/configs/nitrogen6x.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h index f465d9e..d08e333 100644 --- a/include/configs/nitrogen6x.h +++ b/include/configs/nitrogen6x.h @@ -77,6 +77,8 @@ #define CONFIG_GENERIC_MMC #define CONFIG_BOUNCE_BUFFER #define CONFIG_CMD_EXT2 +#define CONFIG_CMD_EXT4 +#define CONFIG_CMD_EXT4_WRITE #define CONFIG_CMD_FAT #define CONFIG_DOS_PARTITION -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] arm: mx6: cm_fx6: use gpio request
Hi Nikita, On 2 October 2014 08:17, Nikita Kiryanov nik...@compulab.co.il wrote: Use gpio_request for all the gpios that are utilized by various subsystems in cm-fx6, and refactor the relevant init functions so that all gpios are requested during board_init(), not during subsystem init, thus avoiding the need to manage gpio ownership each time a subsystem is initialized. The new division of labor is: During board_init() muxes are setup and gpios are requested. During subsystem init gpios are toggled. Cc: Igor Grinberg grinb...@compulab.co.il Cc: Simon Glass s...@chromium.org Signed-off-by: Nikita Kiryanov nik...@compulab.co.il Copying my comments from the other patch: I've thought about that quite a lot as part of the driver model work. Claiming GPIOs in board code doesn't feel right to me: 1. If using device tree, the GPIOs are in there, and it means the board code needs to go looking there as well as the driver. The board code actually needs to sniff around in the driver's device tree nodes. That just seems honky. 2. In the driver model world, we hope that board init will fade away to a large extent. Certainly it should be possible to specify most of what a driver needs in device tree or platform data. Getting rid of the explicit init calls in U-Boot (board_init_f(), board_init(), board_late_init(), board_early_init_f(), ...) is a nice effect of driver model I hope. 3. Even if not using device tree, and using platform data, where the board code may specify the platform data, it still feels honky for the board to be parsing its own data (designed for use by the driver) to claim GPIOs. 4. I don't really see why pre-claiming enforces anything. If two subsystems claim the same GPIO you are going to get an error somewhere in any case. 5. If you look at the calls that drivers make to find out information from the board file, or perform some init (mmc does this, USB, ethernet, etc.) it is mostly because the driver has no idea of the specifics of the board. Device tree and platform data fix exactly this problem. The driver has the best idea of when it needs to start up, when it needs this resource of that. In some cases the driver have the ability to operate in two modes (e.g. 4 bit or 8 bit SDIO, UART with/without flow control) and this means the init depends on the driver's mode. Having said that, it's your board and if you really want to go this way in the interim, then I'm not going to strongly object. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 1/2] odroid: pmic77686: allow bucket voltage settings
Hi Suriyan,
On Thu, 2 Oct 2014 06:45:58 -0700, Suriyan Ramasami
suriya...@gmail.com wrote:
Allow to set the bucket voltage for the max77686.
This will be used to reset the SMC LAN9730 ethernet on the odroids.
I believe the correct term is buck, not bucket.
Signed-off-by: Suriyan Ramasami suriya...@gmail.com
---
drivers/power/pmic/pmic_max77686.c | 48
+-
include/power/max77686_pmic.h | 3 +++
2 files changed, 50 insertions(+), 1 deletion(-)
diff --git a/drivers/power/pmic/pmic_max77686.c
b/drivers/power/pmic/pmic_max77686.c
index df1fd91..1aeadb4 100644
--- a/drivers/power/pmic/pmic_max77686.c
+++ b/drivers/power/pmic/pmic_max77686.c
@@ -42,6 +42,25 @@ static unsigned int max77686_ldo_volt2hex(int ldo, ulong
uV)
return 0;
}
+static unsigned int max77686_buck_volt2hex(int buck, ulong uV)
+{
+ unsigned int hex = 0;
+
+ if (buck 5 || buck 9) {
+ debug(%s: buck %d is not supported\n, __func__, buck);
+ return 0;
+ }
+
+ hex = (uV - 75) / 5;
+
+ 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 MAX77686_BUCK_VOLT_MAX_HEX + 1;
+}
+
int max77686_set_ldo_voltage(struct pmic *p, int ldo, ulong uV)
{
unsigned int val, ret, hex, adr;
@@ -68,6 +87,33 @@ 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, ret, hex, adr;
+
+ if (buck 5 buck 9) {
+ printf(%s: %d is an unsupported bucket number\n,
+__func__, buck);
+ return -1;
+ }
+
+ adr = max77686_buck_addr[buck] + 1;
+ hex = max77686_buck_volt2hex(buck, uV);
+
+ if (hex == MAX77686_BUCK_VOLT_MAX_HEX + 1)
+ return -1;
+
+ ret = pmic_reg_read(p, adr, val);
+ if (ret)
+ return ret;
+
+ val = ~MAX77686_BUCK_VOLT_MASK;
+ val |= hex;
+ ret |= pmic_reg_write(p, adr, val);
+
+ return ret;
+}
+
int max77686_set_ldo_mode(struct pmic *p, int ldo, char opmode)
{
unsigned int val, ret, adr, mode;
@@ -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_HEX0x3f
@@ -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
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot Mini Summit
Hi Detlev, On Thu, 02 Oct 2014 19:09:07 +0200, Detlev Zundel d...@denx.de wrote: Hi, the agenda for the U-Boot Mini Summit in a few days in Düsseldorf has now been finalized[1]. It is very encouraging to see such a lot of high-class content and I'm very excited to also meet a lot of new people. Please note that we would like to have as many custodians present as possible at 11:15 so that we can have a short round of introductions. I'm sure it will be a very pleasant experience to match names with faces known only from the mailing list so far :) I would have liked to attend, but for personal reasons could not free myself up. Is there any possibility of a Google Hangout or anything similar? Also note that the agenda allows everybody to attend Toms talk Redundant booting with U-Boot at 16:30[2] and of course it has no chance to collide with Mareks talk Secure and flexible boot with U-Boot on Wednesday at 15:30[2]. Thanks for all the input so far and I'm looking forward to seeing you all in a few days! Detlev [1] http://www.denx.de/wiki/U-Boot/MiniSummitELCE2014 [2] http://events.linuxfoundation.org/events/embedded-linux-conference-europe/program/schedule Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 1/2] odroid: pmic77686: allow bucket voltage settings
On Thu, Oct 2, 2014 at 2:03 PM, Albert ARIBAUD
albert.u.b...@aribaud.net wrote:
Hi Suriyan,
On Thu, 2 Oct 2014 06:45:58 -0700, Suriyan Ramasami
suriya...@gmail.com wrote:
Allow to set the bucket voltage for the max77686.
This will be used to reset the SMC LAN9730 ethernet on the odroids.
I believe the correct term is buck, not bucket.
Thanks Albert,
I always thought they stood for bucket! This prompted me to read up
on BUCK regulators. Thank you. I shall correct it in my next version.
- Suriyan
Signed-off-by: Suriyan Ramasami suriya...@gmail.com
---
drivers/power/pmic/pmic_max77686.c | 48
+-
include/power/max77686_pmic.h | 3 +++
2 files changed, 50 insertions(+), 1 deletion(-)
diff --git a/drivers/power/pmic/pmic_max77686.c
b/drivers/power/pmic/pmic_max77686.c
index df1fd91..1aeadb4 100644
--- a/drivers/power/pmic/pmic_max77686.c
+++ b/drivers/power/pmic/pmic_max77686.c
@@ -42,6 +42,25 @@ static unsigned int max77686_ldo_volt2hex(int ldo, ulong
uV)
return 0;
}
+static unsigned int max77686_buck_volt2hex(int buck, ulong uV)
+{
+ unsigned int hex = 0;
+
+ if (buck 5 || buck 9) {
+ debug(%s: buck %d is not supported\n, __func__, buck);
+ return 0;
+ }
+
+ hex = (uV - 75) / 5;
+
+ 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 MAX77686_BUCK_VOLT_MAX_HEX + 1;
+}
+
int max77686_set_ldo_voltage(struct pmic *p, int ldo, ulong uV)
{
unsigned int val, ret, hex, adr;
@@ -68,6 +87,33 @@ 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, ret, hex, adr;
+
+ if (buck 5 buck 9) {
+ printf(%s: %d is an unsupported bucket number\n,
+__func__, buck);
+ return -1;
+ }
+
+ adr = max77686_buck_addr[buck] + 1;
+ hex = max77686_buck_volt2hex(buck, uV);
+
+ if (hex == MAX77686_BUCK_VOLT_MAX_HEX + 1)
+ return -1;
+
+ ret = pmic_reg_read(p, adr, val);
+ if (ret)
+ return ret;
+
+ val = ~MAX77686_BUCK_VOLT_MASK;
+ val |= hex;
+ ret |= pmic_reg_write(p, adr, val);
+
+ return ret;
+}
+
int max77686_set_ldo_mode(struct pmic *p, int ldo, char opmode)
{
unsigned int val, ret, adr, mode;
@@ -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_HEX0x3f
@@ -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
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 1/2] odroid: pmic77686: allow bucket voltage settings
On Thu, Oct 2, 2014 at 7:31 AM, Przemyslaw Marczak
p.marc...@samsung.com wrote:
Dear Suriyan,
I will try to test it after the weekend.
I'm working on a PMIC framework V3 with Trats2 as a base and the buck
mode/voltage for Max77686 are yet implemented in my code.
But this is okay because the new driver is fully reworked into new file and
the support to the old PMIC framework will be still keept before move all
the drivers to PMIC v3.
The RFC will send soon.
Thanks Przemyslaw,
Just FYI, I tested the USB host on the Odroid U2, a U3 and an X2.
Regards
- Suriyan
On 10/02/2014 03:45 PM, Suriyan Ramasami wrote:
Allow to set the bucket voltage for the max77686.
This will be used to reset the SMC LAN9730 ethernet on the odroids.
Signed-off-by: Suriyan Ramasami suriya...@gmail.com
---
drivers/power/pmic/pmic_max77686.c | 48
+-
include/power/max77686_pmic.h | 3 +++
2 files changed, 50 insertions(+), 1 deletion(-)
diff --git a/drivers/power/pmic/pmic_max77686.c
b/drivers/power/pmic/pmic_max77686.c
index df1fd91..1aeadb4 100644
--- a/drivers/power/pmic/pmic_max77686.c
+++ b/drivers/power/pmic/pmic_max77686.c
@@ -42,6 +42,25 @@ static unsigned int max77686_ldo_volt2hex(int ldo,
ulong uV)
return 0;
}
+static unsigned int max77686_buck_volt2hex(int buck, ulong uV)
+{
+ unsigned int hex = 0;
+
+ if (buck 5 || buck 9) {
+ debug(%s: buck %d is not supported\n, __func__, buck);
+ return 0;
+ }
+
+ hex = (uV - 75) / 5;
+
+ 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 MAX77686_BUCK_VOLT_MAX_HEX + 1;
+}
+
int max77686_set_ldo_voltage(struct pmic *p, int ldo, ulong uV)
{
unsigned int val, ret, hex, adr;
@@ -68,6 +87,33 @@ 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, ret, hex, adr;
+
+ if (buck 5 buck 9) {
+ printf(%s: %d is an unsupported bucket number\n,
+ __func__, buck);
+ return -1;
+ }
+
+ adr = max77686_buck_addr[buck] + 1;
+ hex = max77686_buck_volt2hex(buck, uV);
+
+ if (hex == MAX77686_BUCK_VOLT_MAX_HEX + 1)
+ return -1;
+
+ ret = pmic_reg_read(p, adr, val);
+ if (ret)
+ return ret;
+
+ val = ~MAX77686_BUCK_VOLT_MASK;
+ val |= hex;
+ ret |= pmic_reg_write(p, adr, val);
+
+ return ret;
+}
+
int max77686_set_ldo_mode(struct pmic *p, int ldo, char opmode)
{
unsigned int val, ret, adr, mode;
@@ -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_MASK0x3f
#define MAX77686_BUCK_MODE_MASK 0x03
#define MAX77686_BUCK_MODE_SHIFT_10x00
#define MAX77686_BUCK_MODE_SHIFT_20x04
Best regards,
--
Przemyslaw Marczak
Samsung RD Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
