November 2012 - U-Boot

[U-Boot] usb: ehci: Take advantage of the new multi-controller feature for MXC
by Benoît Thébaudeau 18 Nov '12

18 Nov '12

Hi Marek, Thanks to Lucas' series coming with commits c7e3b2b and 676ae06, I'd like to use the multi-controller feature on MXC since most of these SoCs come with a USB IP supporting an OTG controller and multiple host-only controllers. Currently the MXC code in ehci-mx{c|5|6}.c just ignores the index passed to ehci_hcd_init() and the like, and there are 3 port-specific configs (CONFIG_MXC_USB_PORT, CONFIG_MXC_USB_FLAGS and CONFIG_MXC_USB_PORTSC). Not all USB ports from the USB IP will be available on each board for a given SoC, so we need a logical to physical USB port mapping. I would suggest something like the following. board.h: #define CONFIG_MXC_USB { \ { \ 0, \ MXC_EHCI_INTERNAL_PHY, \ MXC_EHCI_UTMI_16BIT | MXC_EHCI_MODE_UTMI \ }, { \ 1, \ MXC_EHCI_POWER_PINS_ENABLED | MXC_EHCI_PWR_PIN_ACTIVE_HIGH | \ MXC_EHCI_OC_PIN_ACTIVE_LOW, \ MXC_EHCI_MODE_ULPI \ }, \ } ehci-fsl.h: struct mxc_ehci_cfg { int port; u32 flags; u32 portsc; }; ehci-mx{c|5|6}.c: static const struct mxc_ehci_cfg cfg[CONFIG_USB_MAX_CONTROLLER_COUNT] = CONFIG_MXC_USB; Then, in ehci_hcd_init(), there would be the following replacements: - CONFIG_MXC_USB_PORT -> cfg[index].port, - CONFIG_MXC_USB_FLAGS -> cfg[index].flags, - CONFIG_MXC_USB_PORTSC -> cfg[index].portsc. What do you think? Best regards, Benoît

3 13

[U-Boot] Custodian branch base commits
by Stephen Warren 18 Nov '12

18 Nov '12

The instructions at: http://www.denx.de/wiki/U-Boot/CustodianGitTrees ... indicate that downstream branches should be rebased onto ${upstream}/master immediately prior to sending a pull request. I'm not sure this is correct any more, given that upstream master branches now pull in downstream branches via "git merge" rather than "git rebase". Should that page be changed? The question then becomes: What commit should downstream branches use as their baseline. I assert that they should be free to choose any commit in their upstream master branch (or merge in any upstream commit), or any further upstream branch all the way up to u-boot/master. As background, I want to send a commit to the Tegra tree that enables use of CONFIG_CMD_FS_GENERIC, and additionally, re-write bootcmd in Tegra's default environment to use the new shell commands that config option enables. However, the commits that implement CONFIG_CMD_FS_GENERIC are in u-boot/master but not yet in u-boot-arm/master. So, Tegra's master branch can't simply be based on current u-boot-arm/master, since if it was, applying my patch would break functionality until it was merged with u-boot/master and so picked up the actual implementation. Hopefully, u-boot-arm/master will merge in (or get reset to) u-boot/master fairly shortly. However, should Tegra's repo have to wait for this? Instead, I propose that 2nd-level custodians should be able to do something like: # (in u-boot-tegra.git, assuming everything is merged already) git checkout master git reset --hard u-boot/master git am patch_that_depends_on_uboot_master # send pull request to u-boot-arm/master # (in u-boot-tegra.git, assuming some patches already applied locally) git checkout master git merge u-boot/master git am patch_that_depends_on_uboot_master # send pull request to u-boot-arm/master This should work fine provided that u-boot/master and u-boot-arm/master guarantee never to rebase. If they don't make that guarantee, then I don't think we can be using merges at all anyway, so that shouldn't be an issue. What do people think?

5 12

[U-Boot] [PATCH] update .gitignore file
by Luka Perkov 18 Nov '12

18 Nov '12

u-boot.lst is located in include directory. Update .gitignore file accordingly. Signed-off-by: Luka Perkov <luka(a)openwrt.org> --- For more information look at git commit 97b24d3. .gitignore | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.gitignore b/.gitignore index 1ac43f2..a163728 100644 --- a/.gitignore +++ b/.gitignore @@ -38,12 +38,12 @@ /u-boot.sha1 /u-boot.dis /u-boot.lds -/u-boot.lst /u-boot.ubl /u-boot.ais /u-boot.dtb /u-boot.sb /u-boot.geany +/include/u-boot.lst # # Generated files

3 5

[U-Boot] Moschip ethernet adapter is not seen as ethernet device
by valdez valdez 17 Nov '12

17 Nov '12

Hello, I tried use my USB ETH adapter. Following README files I addes into beagle.h file (my board is beagleboard) this: #define CONFIG_USB_HOST_ETHER /* Enable USB Ethernet adapters */ #define CONFIG_USB_ETHER_ASIX /* Asix, or whatever driver(s) you want */ #define CONFIG_CMD_NET #define CONFIG_CMD_PING #define CONFIG_CMD_DHCP #define CONFIG_BOOTP_SUBNETMASK #define CONFIG_BOOTP_GATEWAY #define CONFIG_BOOTP_HOSTNAME #define CONFIG_BOOTP_BOOTPATH and into asix.c file this: { 0x9710, 0x7830, FLAG_TYPE_AX88172}, I based on what my host Linux showed to me: Vendor specific, USB Revision 2.0 - Moschip Semiconductor UA0025C 6e003e8f - Class: Vendor specific - PacketSize: 64 Configurations: 1 - Vendor: 0x9710 Product 0x7830 Version 1.0 Configuration: 1 - Interfaces: 1 Bus Powered Remote Wakeup 500mA Interface: 0 - Alternate Setting 0, Endpoints: 3 - Class Vendor specific - Endpoint 1 In Bulk MaxPacket 512 - Endpoint 2 Out Bulk MaxPacket 512 - Endpoint 3 In Interrupt MaxPacket 16 Interval 1ms But U-Boot don't see it as Ethernet Device, it only recognize it in tree: (Re)start USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 2 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found scanning usb for ethernet devices... 0 Ethernet Device(s) found OMAP3 beagleboard.org # usb tree USB device tree: 1 Hub (480 Mb/s, 0mA) | u-boot EHCI Host Controller | +-2 Vendor specific (480 Mb/s, 500mA) Moschip Semiconductor UA0025C 6e003e8f Could you help me with this, please?

1 0

Re: [U-Boot] [PATCH v2 6/8] omap_gpmc: BCH8 support (ELM based)
by Andreas Bießmann 17 Nov '12

17 Nov '12

Dear Ilya Yanok, On 15.11.2012 21:08, Ilya Yanok wrote: > Dear Andreas, > > On Thu, Nov 15, 2012 at 2:25 PM, Andreas Bießmann > <andreas.devel(a)googlemail.com <mailto:andreas.devel@googlemail.com>> wrote: > > Dear Ilya Yanok, > > On 07.11.2012 00:06, Ilya Yanok wrote: > > From: Mansoor Ahamed <mansoor.ahamed(a)ti.com > <mailto:mansoor.ahamed@ti.com>> > > > > This patch adds support for BCH8 error correction code to omap_gpmc > > driver. We use GPMC to generate codes/syndromes but we need ELM to > find > > error locations from given syndrome. > > > > first of all, I wonder why this is so different than the kernel > implementation for BCH. I mean the API (and content) of this and commit > 8d602cf50d3bba864bc1438f486b626df69c87b3 mainline linux seems to differ. > The main question coming to mind is: Is the resulting OOB layout > compatible then? > > > Please note that these patches are AM33XX-specific (as we are using ELM > that, I think, just isn't available on OMAP3) so we use OOB layout that > is compatible with AM33xx ROM boot code. You are right, ELM is not available in OMAP3 devices. It seems the ROM loader of these devices only support the 1-Bit Hamming, but is also different to the OOB layout used for the SW 1-bit hamming provided by the Kernel. So we get here a lot of different OOB layouts ... I wonder if we can stick to e.g. the generic SW BCH layout (of linux kernel) for all but the ROM partition (where the SPL is placed). So the SPL need to know just one mechanism but software modifying that place needs to know about the 'special' ROM layout. > It's likely that this layout > doesn't match with the current kernel layout as RBL uses strange 14th > byte for BCH8 while only 13 bytes are needed. Sorry, what does RBL mean in that context? > There are some patches for > the kernel that make it use the same layout too but I don't if they are > going to be accepted soon. Ok, that would be required to write the SPL to flash. > Actually, the only assumption the code does about the OOB layout is that > ECC code occupies continuous area in the OOB. Well, but you have defined that for example it is written in big endian. I'm currently working on a omap3 enabled device that requires 4-bit ECC for all but the first block. And I'm searching for a clean solution that would be accepted mainline. I think it would be best to have the same OOB layout for the whole device but the SPL space (cause that needs to be read by ROM). The layout should be chosen at compile time of the SPL. What do you think about? Best regards Andreas Bießmann

2 3

[U-Boot] please pull u-boot-samsung master
by Minkyu Kang 16 Nov '12

16 Nov '12

Dear Albert, The following changes since commit ccfa398547ce0b579f2e7874e78948246c739237: arm1136: Fix enable_caches() (2012-11-10 12:28:22 +0100) are available in the git repository at: git://git.denx.de/u-boot-samsung master for you to fetch changes up to 7a5337732e3e05b2b0de1b592fa031b2c7b4f632: EXYNOS5: Enable SPI booting. (2012-11-15 21:08:21 +0900) ---------------------------------------------------------------- Ashok Kumar Reddy (1): ARM: arm1176: Define arch_cpu_init() for s3c64xx Chander Kashyap (1): Exynos5250: Enable PXE Support Hatim RV (3): EXYNOS: Add clock for SPI EXYNOS5: Add base address for SPI EXYNOS5: Enable SPI Marek Vasut (1): dm: wdt: Move s5p watchdog timer to drivers/watchdog/ Minkyu Kang (3): ARCH: EXYNOS: add support to match product id EXYNOS: Clock: Add common function for pll rate calculation s3c64xx: fix the compiler error and warning Piotr Wilczek (12): arm:exynos4:trats: Correct SDRAM configuration for trats arm:exynos4:trats: Fix SDRAM size arm:exynos4:pinmux: Modify the gpio function for mmc arm:exynos4:trats: Use pinmux for mmc configuration arm:exynos4:universal: Use pinmux for mmc configuration arm:exynos4:universal: Eliminated low level init arm: trats: Power down core 1 exynos4: universal_C210: use software SPI misc:max8998 Add LDO macros drivers: video: Add ld9040 video driver drivers: video: fix image position exynos4: universal_C210: add display support Rajeshwari Shinde (14): PMIC: MAX77686: Add support for MAX77686 SMDK5250: Config: Enable MAX77686 pmic chip SOUND: SAMSUNG: Add I2S driver SOUND: Add WM8994 codec Sound: Add command for audio playback EXYNOS: Add I2S registers EXYNOS: Add parameters required by I2S EXYNOS: Add pinmux for I2S EXYNOS: Add I2S base address EXYNOS: Add clock for I2S SMDK5250: Enable Sound EXYNOS5: Add pinmux support for SPI SPI: Add SPI Driver for EXYNOS. EXYNOS5: Enable SPI booting. Łukasz Majewski (1): gpio:fix: Proper handling of GPIO subsystem parts at Samsung devices Makefile | 1 + arch/arm/cpu/arm1176/s3c64xx/Makefile | 2 +- arch/arm/cpu/arm1176/s3c64xx/init.c | 26 + arch/arm/cpu/armv7/exynos/clock.c | 350 +++++++-- arch/arm/cpu/armv7/exynos/pinmux.c | 122 +++ arch/arm/cpu/armv7/s5p-common/Makefile | 1 - arch/arm/include/asm/arch-exynos/clk.h | 4 + arch/arm/include/asm/arch-exynos/clock.h | 29 + arch/arm/include/asm/arch-exynos/cpu.h | 18 + arch/arm/include/asm/arch-exynos/gpio.h | 19 + arch/arm/include/asm/arch-exynos/i2s-regs.h | 66 ++ arch/arm/include/asm/arch-exynos/periph.h | 7 + arch/arm/include/asm/arch-exynos/sound.h | 44 ++ arch/arm/include/asm/arch-exynos/spi.h | 78 ++ arch/arm/include/asm/arch-s5pc1xx/gpio.h | 7 +- board/samsung/smdk5250/Makefile | 2 +- board/samsung/smdk5250/smdk5250.c | 8 + board/samsung/smdk5250/{mmc_boot.c => spl_boot.c} | 31 +- board/samsung/trats/trats.c | 80 +- board/samsung/universal_c210/Makefile | 1 - board/samsung/universal_c210/lowlevel_init.S | 395 ---------- board/samsung/universal_c210/universal.c | 335 +++++++-- common/Makefile | 1 + common/cmd_sound.c | 96 +++ drivers/gpio/s5p_gpio.c | 6 +- drivers/misc/Makefile | 1 + drivers/misc/pmic_max77686.c | 42 ++ drivers/serial/s3c64xx.c | 3 +- drivers/sound/Makefile | 48 ++ drivers/sound/samsung-i2s.c | 358 +++++++++ drivers/sound/sound.c | 228 ++++++ drivers/sound/wm8994.c | 792 ++++++++++++++++++++ drivers/sound/wm8994.h | 87 +++ drivers/sound/wm8994_registers.h | 299 ++++++++ drivers/spi/Makefile | 1 + drivers/spi/exynos_spi.c | 367 +++++++++ drivers/video/Makefile | 1 + drivers/video/exynos_fb.c | 15 +- drivers/video/ld9040.c | 144 ++++ drivers/watchdog/Makefile | 1 + .../s5p-common/wdt.c => drivers/watchdog/s5p_wdt.c | 0 include/configs/s5pc210_universal.h | 36 + include/configs/smdk5250.h | 46 +- include/configs/trats.h | 17 +- include/i2s.h | 127 ++++ include/ld9040.h | 32 + include/max77686_pmic.h | 158 ++++ include/max8998_pmic.h | 2 + include/sound.h | 62 ++ 49 files changed, 3983 insertions(+), 613 deletions(-) create mode 100644 arch/arm/cpu/arm1176/s3c64xx/init.c create mode 100644 arch/arm/include/asm/arch-exynos/i2s-regs.h create mode 100644 arch/arm/include/asm/arch-exynos/sound.h create mode 100644 arch/arm/include/asm/arch-exynos/spi.h rename board/samsung/smdk5250/{mmc_boot.c => spl_boot.c} (66%) delete mode 100644 board/samsung/universal_c210/lowlevel_init.S create mode 100644 common/cmd_sound.c create mode 100644 drivers/misc/pmic_max77686.c create mode 100644 drivers/sound/Makefile create mode 100644 drivers/sound/samsung-i2s.c create mode 100644 drivers/sound/sound.c create mode 100644 drivers/sound/wm8994.c create mode 100644 drivers/sound/wm8994.h create mode 100644 drivers/sound/wm8994_registers.h create mode 100644 drivers/spi/exynos_spi.c create mode 100644 drivers/video/ld9040.c rename arch/arm/cpu/armv7/s5p-common/wdt.c => drivers/watchdog/s5p_wdt.c (100%) create mode 100644 include/i2s.h create mode 100644 include/ld9040.h create mode 100644 include/max77686_pmic.h create mode 100644 include/sound.h

2 3

[U-Boot] [PATCH] mx6: clock: Only show CSPI clock if CSPI is enabled
by Fabio Estevam 16 Nov '12

16 Nov '12

From: Fabio Estevam <fabio.estevam(a)freescale.com> If a board does not enable CSPI, there is no need to show the CSPI clock frequency as part of the 'clock' command. Reported-by: Dirk Behme <dirk.behme(a)gmail.com> Signed-off-by: Fabio Estevam <fabio.estevam(a)freescale.com> --- arch/arm/cpu/armv7/mx6/clock.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c index a01d96f..a50db70 100644 --- a/arch/arm/cpu/armv7/mx6/clock.c +++ b/arch/arm/cpu/armv7/mx6/clock.c @@ -404,7 +404,9 @@ int do_mx6_showclocks(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) printf("\n"); printf("IPG %8d kHz\n", mxc_get_clock(MXC_IPG_CLK) / 1000); printf("UART %8d kHz\n", mxc_get_clock(MXC_UART_CLK) / 1000); +#ifdef CONFIG_MXC_SPI printf("CSPI %8d kHz\n", mxc_get_clock(MXC_CSPI_CLK) / 1000); +#endif printf("AHB %8d kHz\n", mxc_get_clock(MXC_AHB_CLK) / 1000); printf("AXI %8d kHz\n", mxc_get_clock(MXC_AXI_CLK) / 1000); printf("DDR %8d kHz\n", mxc_get_clock(MXC_DDR_CLK) / 1000); -- 1.7.9.5

2 1

[U-Boot] [SPL mode] Question
by Lukasz Majewski 16 Nov '12

16 Nov '12

Hi Stefano, I've got some questions about Falcon mode and spl export command. I've looked into the ./common/cmd_spl.c at master branch SHA1: 59852d03867108217fe88e3bfc3e1e9cedfe63c5 Correct me if I'm wrong (or I've overlooked something). It looks that, this file version is a very early version. After reading "Falcon" mode README - I'd expect, that "spl export" will write either ATAGS or FDT to NAND (or any other memory). For this file it doesn't do that. Am I missing some additional patches? Since you stated, that Falcon mode is only (now) supported on NAND memory, I'd like to ask if it is acceptable to extend cmd_spl.c to write ATAGS/FDT image to eMMC or (better) to partition formatted as EXT4 of FAT? I can imagine a following scenario: 1. Use u-boot to generate ATAGS (from bootcmd args defined for board or cmd line parameters) or FDT blob with "spl export". Store it on a partition or eMMC. 2. Use SPL (second stage bootloader) to parse this blob, place ATAGS or FDT accordingly, read uImage and pass execution to it. What is your opinion? -- Best regards, Lukasz Majewski Samsung Poland R&D Center | Linux Platform Group

3 3

[U-Boot] [PATCH 01/13] mx31: Move EHCI definitions to ehci-fsl.h
by Benoît Thébaudeau 16 Nov '12

16 Nov '12

The EHCI definitions in i.MX31's imx-regs.h are MXC-generic, so move them to ehci-fsl.h so that all MXC SoCs can use them. Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau(a)advansee.com> Cc: Marek Vasut <marex(a)denx.de> Cc: Stefano Babic <sbabic(a)denx.de> --- .../arch/arm/include/asm/arch-mx31/imx-regs.h | 26 -------------------- .../include/usb/ehci-fsl.h | 22 +++++++++++++++++ 2 files changed, 22 insertions(+), 26 deletions(-) diff --git u-boot-usb-76454b2.orig/arch/arm/include/asm/arch-mx31/imx-regs.h u-boot-usb-76454b2/arch/arm/include/asm/arch-mx31/imx-regs.h index 8fd3d08..01a849d 100644 --- u-boot-usb-76454b2.orig/arch/arm/include/asm/arch-mx31/imx-regs.h +++ u-boot-usb-76454b2/arch/arm/include/asm/arch-mx31/imx-regs.h @@ -896,32 +896,6 @@ struct esdc_regs { #define MX31_AIPS1_BASE_ADDR 0x43f00000 #define IMX_USB_BASE (MX31_AIPS1_BASE_ADDR + 0x88000) -/* USB portsc */ -/* values for portsc field */ -#define MXC_EHCI_PHY_LOW_POWER_SUSPEND (1 << 23) -#define MXC_EHCI_FORCE_FS (1 << 24) -#define MXC_EHCI_UTMI_8BIT (0 << 28) -#define MXC_EHCI_UTMI_16BIT (1 << 28) -#define MXC_EHCI_SERIAL (1 << 29) -#define MXC_EHCI_MODE_UTMI (0 << 30) -#define MXC_EHCI_MODE_PHILIPS (1 << 30) -#define MXC_EHCI_MODE_ULPI (2 << 30) -#define MXC_EHCI_MODE_SERIAL (3 << 30) - -/* values for flags field */ -#define MXC_EHCI_INTERFACE_DIFF_UNI (0 << 0) -#define MXC_EHCI_INTERFACE_DIFF_BI (1 << 0) -#define MXC_EHCI_INTERFACE_SINGLE_UNI (2 << 0) -#define MXC_EHCI_INTERFACE_SINGLE_BI (3 << 0) -#define MXC_EHCI_INTERFACE_MASK (0xf) - -#define MXC_EHCI_POWER_PINS_ENABLED (1 << 5) -#define MXC_EHCI_TTL_ENABLED (1 << 6) - -#define MXC_EHCI_INTERNAL_PHY (1 << 7) -#define MXC_EHCI_IPPUE_DOWN (1 << 8) -#define MXC_EHCI_IPPUE_UP (1 << 9) - /* * CSPI register definitions */ diff --git u-boot-usb-76454b2.orig/include/usb/ehci-fsl.h u-boot-usb-76454b2/include/usb/ehci-fsl.h index 2869302..4dee5b0 100644 --- u-boot-usb-76454b2.orig/include/usb/ehci-fsl.h +++ u-boot-usb-76454b2/include/usb/ehci-fsl.h @@ -246,9 +246,31 @@ struct usb_ehci { /* * For MXC SOCs */ + +/* values for portsc field */ +#define MXC_EHCI_PHY_LOW_POWER_SUSPEND (1 << 23) +#define MXC_EHCI_FORCE_FS (1 << 24) +#define MXC_EHCI_UTMI_8BIT (0 << 28) +#define MXC_EHCI_UTMI_16BIT (1 << 28) +#define MXC_EHCI_SERIAL (1 << 29) +#define MXC_EHCI_MODE_UTMI (0 << 30) +#define MXC_EHCI_MODE_PHILIPS (1 << 30) +#define MXC_EHCI_MODE_ULPI (2 << 30) +#define MXC_EHCI_MODE_SERIAL (3 << 30) + +/* values for flags field */ +#define MXC_EHCI_INTERFACE_DIFF_UNI (0 << 0) +#define MXC_EHCI_INTERFACE_DIFF_BI (1 << 0) +#define MXC_EHCI_INTERFACE_SINGLE_UNI (2 << 0) +#define MXC_EHCI_INTERFACE_SINGLE_BI (3 << 0) +#define MXC_EHCI_INTERFACE_MASK (0xf) + #define MXC_EHCI_POWER_PINS_ENABLED (1 << 5) #define MXC_EHCI_TTL_ENABLED (1 << 6) + #define MXC_EHCI_INTERNAL_PHY (1 << 7) +#define MXC_EHCI_IPPUE_DOWN (1 << 8) +#define MXC_EHCI_IPPUE_UP (1 << 9) /* Board-specific initialization */ int board_ehci_hcd_init(int port);

5 53

[U-Boot] Bug in netconsole?
by Nick Thompson 16 Nov '12

16 Nov '12

I think there might be a bug in this commit: http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=commitdiff;h=2c8fe5120… The commit makes "the netconsole buffer size configurable". It adds CONFIG_NETCONSOLE_BUFFER_SIZE and maintains the original 512 default value used to define the length of input_buffer[]. nc_input_packet uses sizeof this to read packet data into input_buffer[]. This appears fine. The commit also adds to following in the output chain: @@ -214,7 +218,7 @@ static void nc_puts(const char *s) len = strlen(s); while (len) { - int send_len = min(len, 512); + int send_len = min(len, sizeof(input_buffer)); nc_send_packet(s, send_len); len -= send_len; s += send_len; I can't see how this code relates to the sizeof input_buffer. The nc_puts data is written directly into NetTxPacket (plus header offsets) which is set to 1536 + alignment bytes long. If input_buffer is bigger than this, a buffer overflow will occur. Obviously the default value of 512 will not trigger the problem. The 512 magic number possibly ought to be derived from PKTSIZE_ALIGN (net.h), but I don't think sizeof(input_buffer) is appropriate here. Regards, Nick.

2 1