April 2014 - U-Boot

[U-Boot] [PATCH 0/9] Refactoring and Endian bug fixes of fdt_support
by Masahiro Yamada 15 Apr '14

15 Apr '14

Masahiro Yamada (9): fdt_support: delete unnecessary DECLARE_GLOBAL_DATA_PTR fdt_support: refactor with fdt_find_or_add_subnode helper func fdt_support: delete force argument of fdt_initrd() fdt_support: delete force argument of fdt_chosen() fdt_support: refactor fdt_fixup_stdout() function fdt_support: add 'const' qualifier for unchanged argument. fdt_support: fix an endian bug of fdt_fixup_memory_banks fdt_support: fix an endian bug of fdt_initrd() fdt_support: correct the return condition of fdt_initrd() arch/microblaze/lib/bootm.c | 2 +- common/cmd_fdt.c | 4 +- common/fdt_support.c | 295 +++++++++++++++++++++----------------------- common/image-fdt.c | 4 +- include/fdt_support.h | 4 +- 5 files changed, 151 insertions(+), 158 deletions(-) -- 1.8.3.2

2 12

[U-Boot] [PATCH v2 0/2] i2c: sh_i2c: bugfix: i2c probe command does not work
by Tetsuyuki Kobayashi 15 Apr '14

15 Apr '14

Hello, I found i2c probe command bug on kzm9g board and fixed it. The v1 patches are faild to post because I was not subscribing u-boot ML. Changes for v2: - correct typo in commit message. Tetsuyuki Kobayashi (2): i2c: sh_i2c: bugfix: i2c probe command does now work arm: kzm9g: Add CONFIG_SYS_GENERIC_BOARD drivers/i2c/sh_i2c.c | 2 +- include/configs/kzm9g.h | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) -- 1.7.9.5

4 15

[U-Boot] [PATCH RESEND-WITH-JUSTIFICATION] spi: soft_spi: Support NULL din/dout buffers
by Andrew Ruder 14 Apr '14

14 Apr '14

This mirrors the conventions used in other SPI drivers (kirkwood, davinci, atmel, et al) where the din/dout buffer can be NULL when the received/transmitted data isn't important. This reduces the need for allocating additional buffers when write-only/read-only functionality is needed. In the din == NULL case, the received data is simply not stored. In the dout == NULL case, zeroes are transmitted. Signed-off-by: Andrew Ruder <andrew.ruder(a)elecsyscorp.com> Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj(a)jcrosoft.com> Cc: Jagan Teki <jagannadh.teki(a)gmail.com> --- So going through and cleaning up some of my trees and determining which patches have not been taken. A little more justification for this patch - I've gone through all of the current SPI implementations and have determined what (if any) support the driver has for half duplex operation by giving NULL for one of the two buffers (din/dout). This greatly reduces the need for temporary buffers for writing or reading large amounts of half-duplex data to devices over SPI. Here's the list: altera_spi.c - SUPPORTS NULL din or dout andes_spi.c - REQUIRES NULL din or dout armada100_spi.c - SUPPORTS NULL din or dout atmel_spi.c - SUPPORTS NULL din or dout bfin_spi6xx.c - SUPPORTS NULL din or dout bfin_spi.c - SUPPORTS NULL din or dout cf_qspi.c - SUPPORTS NULL din or dout cf_spi.c - SUPPORTS NULL din or dout davinci_spi.c - SUPPORTS NULL din or dout exynos_spi.c - SUPPORTS NULL din or dout fdt_spi.c-tegra20_sf - SUPPORTS NULL din or dout fdt_spi.c-tegra20_sl - SUPPORTS NULL din or dout fdt_spi.c-tegra114 - SUPPORTS NULL din or dout fsl_espi.c - SUPPORTS NULL din (NOT dout) ftssp010_spi.c - SUPPORTS NULL din or dout ich.c - SUPPORTS NULL din or dout kirkwood_spi.c - SUPPORTS NULL din or dout mpc52xx_spi.c - NO SUPPORT mpc8xxx_spi.c - NO SUPPORT mxc_spi.c - NO SUPPORT mxs_spi.c - REQUIRES NULL din or dout oc_tiny_spi.c - SUPPORTS NULL din or dout omap3_spi.c - SUPPORTS NULL din or dout sandbox_spi.c - SUPPORTS NULL din or dout sh_qspi.c - SUPPORTS NULL din or dout sh_spi.c - SUPPORTS NULL din or dout soft_spi.c - NO SUPPORT ti_qspi.c - SUPPORTS NULL din or dout xilinx_spi.c - SUPPORTS NULL din or dout zynq_spi.c - SUPPORTS NULL din or dout Furthermore, this would not affect any board already using temporary buffers and it would continue to work as usual. The *only* obscure corner case that this will not work is if NULL (0x0) is a valid buffer address in your system and you are transferring SPI to/from it. This seems very unlikely and would probably break in other ways from library functions that check their arguments. drivers/spi/soft_spi.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/drivers/spi/soft_spi.c b/drivers/spi/soft_spi.c index 5d22351..5fdd091 100644 --- a/drivers/spi/soft_spi.c +++ b/drivers/spi/soft_spi.c @@ -137,9 +137,15 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen, * Check if it is time to work on a new byte. */ if((j % 8) == 0) { - tmpdout = *txd++; + if (txd) { + tmpdout = *txd++; + } else { + tmpdout = 0; + } if(j != 0) { - *rxd++ = tmpdin; + if (rxd) { + *rxd++ = tmpdin; + } } tmpdin = 0; } @@ -164,9 +170,11 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen, * bits over to left-justify them. Then store the last byte * read in. */ - if((bitlen % 8) != 0) - tmpdin <<= 8 - (bitlen % 8); - *rxd++ = tmpdin; + if (rxd) { + if((bitlen % 8) != 0) + tmpdin <<= 8 - (bitlen % 8); + *rxd++ = tmpdin; + } if (flags & SPI_XFER_END) spi_cs_deactivate(slave); -- 1.9.0.rc3.12.gbc97e2d

3 6

Re: [U-Boot] [PATCH v6 1/4] EXYNOS5: Add gpio pin numbering feature
by Akshay Saraswat 14 Apr '14

14 Apr '14

Hi Minkyu, Simon and Lukasz, >Dear Akshay, > >On 14/04/14 19:53, Lukasz Majewski wrote: >> Hi Akshay, >> >>> Hi Lukasz, >>> >>>> Hi Akshay, >>>> >>>> I'm not Samsung tree maintainer, but by chance I've come across those >>>> patches and... >>>> >>>> First question - why have you omitted u-boot-samsung tree maintainer? >>>> I've added Minkyu to CC. >>>> >>> >>> Minkyu has an email ID "promsoft(a)gmail.com" and I added that in CC. >>> Probably you don't know this email id :-) >> >> I do know it :-), but this is not the official one. >> >> Adding involved people to CC really speed up things :-) >> > >I am always sensing about SAMSUNG related patches. >Please don't worry about it :) > >>> >>>> >>>> Also in the cover letter you claim that this patch was "build tested" >>>> for Exynos4 based boards. Why didn't you add at least one maintainer >>>> of those boards to CC? >>>> >>> >>> In cover letter I have not mentioned anywhere that I have built or >>> tested these patches over Exynos4. >>> Patch 2/4 says "Build tested" >>> because Rajeshwari did build images for Exynos4 boards and that was >>> successfull but nobody tested booting those images. >> >> As Przemek written to you in the other mail. There is a build problem >> with trats2/trats boards. > >Please fix it. > >> >>> I do not possess any Exynos4 board. >> >> That is why it is a good practice to ask maintainer's of those boards >> to test it for you. >> >>> These patches are meant for >>> Exynos5 only. > >No. please consider Exynos4 also. >If you make patches for Exynos4 too, then it will be great job. >Przemek or Lukasz will help your test. > >> I borrowed an Origen board and doing changes for Exynos4 as well. I'll push next patch-set tomorrow with Exynos4 and 5 support together. >> We will probably go with your approach to make (_finally_) the gpio code >> consistent for Exynos4/5. >> >>> But Yes, there are compiler errors introduced for >>> smkc100 because of this new patch-set and I will fix them in the next >>> patch-set. > >next patch-set means v7? right? > Yes, next patch set would be v7. >> >> I'm a bit confused now. Was this patch set build tested or not? >> >>> >>>> >>>>> + >>>>> +/* A list of valid GPIO numbers for the asm-generic/gpio.h >>>>> interface */ +enum exynos5_gpio_pin { >>>>> + /* GPIO_PART1_STARTS */ >>>>> + EXYNOS5_GPIO_A00, /* 0 */ >>>>> + EXYNOS5_GPIO_A01, >>>>> + EXYNOS5_GPIO_A02, >>>>> + EXYNOS5_GPIO_A03, >>>>> + EXYNOS5_GPIO_A04, >>>> >>>> According to the patch description, you had a compilation error when >>>> were adding the support for Exynos 5250 and 5420. Why you fix the >>>> problem by rewriting the whole framework? >>>> >>> >>> This framework is not intended to fix compiler warnings or errors but >>> to make GPIO numbering easy to remember and sequential, without any >>> holes in between. >> >> Samsung boards were swinging from part+bank+pin number approach to >> sequential GPIO number from time to time. I think it is a good >> time to clean things up. >> >>> >>>> >>>> IN the patch 2/4 you have: >>>> >>>> - gpio_cfg_pin(start + i, GPIO_FUNC(0x2)); >>>> - gpio_set_pull(start + i, GPIO_PULL_NONE); >>>> - gpio_set_drv(start + i, GPIO_DRV_4X); >>>> + gpio_cfg_pin(start + i, S5P_GPIO_FUNC(0x2)); >>>> + gpio_set_pull(start + i, S5P_GPIO_PULL_NONE); >>>> + gpio_set_drv(start + i, S5P_GPIO_DRV_4X); >>>> >>>> What is the rationale to change the name to S5P_GPIO and not stick to >>>> GPIO_FUNC? In which way gpios for Exynos5 are different than for >>>> Exynos4? Cannot we finally reuse the Exynos 4 and 5 code? >>>> >>> >>> We have enum member GPIO_INPUT in common/cmd_gpio.c and GPIO_INPUT >>> define in arch-exynos/gpio.h. To remove such conflicts we renamed all >>> s5p defines from "GPIO_*" to "S5P_GPIO_*". >>> We are using the same s5p_gpio.c for both Exynos4 and 5 as far as I >>> know. I dont get the exact issue here. Do you want me to remove >>> "S5P_". Is that it ? >> >> S5P_ corresponds to at most Exynos4 SoC (Up till S5PV310). However, >> since the file is named s5p_gpio.c, then I think that S5P_ is a >> appropriate prefix. > >Actually I have plan to rename from S5P_ to EXYNOS_. but not now. >It look OK to me. > >> >>> >>>> >>>> With the same patch: >>>> >>>> - case PERIPH_ID_UART1: >>>> - bank = &gpio1->d0; >>>> - start = 0; >>>> + start = EXYNOS5_GPIO_D00; >>>> >>>> What is wrong with specifying the bank field? >>>> Why your gpio command cannot use the bank approach? >>>> >>> >>> Ultimately we are using banks and pin_nums specific to the bank only >>> after we extract exact bank from the sequential pin_num. >> >> Ok. >> >>> >>>> >>>> And one more question: Is this work compliant with new driver model, >>>> which will be accepted at the merge window after the v2014.04 >>>> release? >>>> >>>> >>>> If not, then there is no point to review this code, since GPIO would >>>> need to be adjusted to use this framework. >>>> >>> >>> Please explain more. I don't get this as well :-) >> >> My point is that the new driver model (introduced by Simon) is going to >> be included. I'm concern if after introduction of it we would need to >> rewrite the gpio code to comply with it. >> >>> >>>> -- >>>> Best regards, >>>> >>>> Lukasz Majewski >>>> >>>> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group >>>> >>> >>> Regards, >>> Akshay Saraswat >> >> >> > >Thanks, >Minkyu Kang. > Regards, Akshay Saraswat

2 1

[U-Boot] beagle-bone fdt booting problem
by Belisko Marek 14 Apr '14

14 Apr '14

Hi, I'm playing with fdt booting on beaglebone board. I'm using latest u-boot git HEAD (2c072c958bb544c72f0e848375803dbd6971f022) + I've added to am335x_evm confing : #ifndef CONFIG_SPL_BUILD #define CONFIG_OF_CONTROL #define CONFIG_OF_SEPARATE #endif I took beaglebone devicetree from kernel. Then I took patch [1] to build image from u-boot and my compiled DT blob. Booting this image always fails with: No valid FDT found - please append one to U-Boot binary, use u-boot-dtb.bin or define CONFIG_OF_EMBED. For sandbox, use -d <file.dtb> ** CONFIG_OF_CONTROL defined but no FDT - please see doc/README.fdt-control I poke around this and find out that when CONFIG_OF_SEPARATE is used then fdt_blob is set to address of .__end pointer. When evaluate image with hexdump it seems that fdt blob (in my particular case and configuration) is shifted by 312 bytes from .__end. When I point gd->fdt_blob (hack in code) to that address it boots fine. Any ideas what I'm doing wrong (I must do something wrong as it seems nobody complains :)). [1] - http://git.denx.de/?p=u-boot/u-boot-x86.git;a=commit;h=d4ab2022cdfe098e9381… BR, marek -- as simple and primitive as possible ------------------------------------------------- Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com

2 3

Re: [U-Boot] [PATCH v6 4/4] Config: Exynos5: Enable Generic GPIO and CMD configs
by Akshay Saraswat 14 Apr '14

14 Apr '14

Hi Simon, >Hi Akshay, > > >On 12 April 2014 13:33, Simon Glass <sjg(a)chromium.org> wrote: > >On 12 April 2014 02:43, Akshay Saraswat <akshay.s(a)samsung.com> wrote: > >From: Rajeshwari Shinde <rajeshwari.s(a)samsung.com> > >Enable configs for GPIO CMD and Generic GPIO. > >Signed-off-by: Rajeshwari Shinde <rajeshwari.s(a)samsung.com> >Signed-off-by: Akshay Saraswat <akshay.s(a)samsung.com> > > > >Acked-by: Simon Glass <sjg(a)chromium.org> > > >Tested on snow with backlight GPIOs. > > >One more question - it looks like Pit doesn't boot on ToT. It is missing a device tree file, but it seems to be more than that - have you had it working? > Yes, it's not booting over pit with this patch-set. I forgot to test them over pit. Will fix it. > >Regards, >Simon Regards, Akshay Saraswat

2 1

Re: [U-Boot] [PATCH v6 1/4] EXYNOS5: Add gpio pin numbering feature
by Akshay Saraswat 14 Apr '14

14 Apr '14

Hi Lukasz, >Hi Akshay, > >I'm not Samsung tree maintainer, but by chance I've come across those >patches and... > >First question - why have you omitted u-boot-samsung tree maintainer? >I've added Minkyu to CC. > Minkyu has an email ID "promsoft(a)gmail.com" and I added that in CC. Probably you don't know this email id :-) > >Also in the cover letter you claim that this patch was "build tested" >for Exynos4 based boards. Why didn't you add at least one maintainer of >those boards to CC? > In cover letter I have not mentioned anywhere that I have built or tested these patches over Exynos4. Patch 2/4 says "Build tested" because Rajeshwari did build images for Exynos4 boards and that was successfull but nobody tested booting those images. I do not possess any Exynos4 board. These patches are meant for Exynos5 only. But Yes, there are compiler errors introduced for smkc100 because of this new patch-set and I will fix them in the next patch-set. > >> + >> +/* A list of valid GPIO numbers for the asm-generic/gpio.h interface >> */ +enum exynos5_gpio_pin { >> + /* GPIO_PART1_STARTS */ >> + EXYNOS5_GPIO_A00, /* 0 */ >> + EXYNOS5_GPIO_A01, >> + EXYNOS5_GPIO_A02, >> + EXYNOS5_GPIO_A03, >> + EXYNOS5_GPIO_A04, > >According to the patch description, you had a compilation error when >were adding the support for Exynos 5250 and 5420. Why you fix the >problem by rewriting the whole framework? > This framework is not intended to fix compiler warnings or errors but to make GPIO numbering easy to remember and sequential, without any holes in between. > >IN the patch 2/4 you have: > >- gpio_cfg_pin(start + i, GPIO_FUNC(0x2)); >- gpio_set_pull(start + i, GPIO_PULL_NONE); >- gpio_set_drv(start + i, GPIO_DRV_4X); >+ gpio_cfg_pin(start + i, S5P_GPIO_FUNC(0x2)); >+ gpio_set_pull(start + i, S5P_GPIO_PULL_NONE); >+ gpio_set_drv(start + i, S5P_GPIO_DRV_4X); > >What is the rationale to change the name to S5P_GPIO and not stick to >GPIO_FUNC? In which way gpios for Exynos5 are different than for >Exynos4? Cannot we finally reuse the Exynos 4 and 5 code? > We have enum member GPIO_INPUT in common/cmd_gpio.c and GPIO_INPUT define in arch-exynos/gpio.h. To remove such conflicts we renamed all s5p defines from "GPIO_*" to "S5P_GPIO_*". We are using the same s5p_gpio.c for both Exynos4 and 5 as far as I know. I dont get the exact issue here. Do you want me to remove "S5P_". Is that it ? > >With the same patch: > >- case PERIPH_ID_UART1: >- bank = &gpio1->d0; >- start = 0; >+ start = EXYNOS5_GPIO_D00; > >What is wrong with specifying the bank field? >Why your gpio command cannot use the bank approach? > Ultimately we are using banks and pin_nums specific to the bank only after we extract exact bank from the sequential pin_num. > >And one more question: Is this work compliant with new driver model, >which will be accepted at the merge window after the v2014.04 release? > > >If not, then there is no point to review this code, since GPIO would >need to be adjusted to use this framework. > Please explain more. I don't get this as well :-) >-- >Best regards, > >Lukasz Majewski > >Samsung R&D Institute Poland (SRPOL) | Linux Platform Group > Regards, Akshay Saraswat

3 2

[U-Boot] Micron PC28F00AP30 flash support
by Andy Pont 14 Apr '14

14 Apr '14

Hello Stefan, I am looking at porting U-Boot to a board that is being designed with a Micron PC28D00AP30 NOR flash device and can't work out whether this is something that is already supported by U-Boot or whether it is work that I will need to undertake. I have had a good grep through the code and can't find any specific references to the device but don't know the CFI code well enough to know whether it will just detect it and work. According to the Micron datasheet, the device itself is 1Gb in density and has symmetrical 64Kword erase blocks. Any guidance would be much appreciated. Thanks in advance, Andy.

1 0

[U-Boot] [u-boot][coreboot-x86] Incremental Make fails
by Hua Yanghao 14 Apr '14

14 Apr '14

Hi, When doing make for coreboot-x86, in arch/x86/lib/Makefile it re-generates libgcc.a from the original toolchain libgcc.a and did some patching for certain libgcc functions. And this seems having some issues when you try to do incremental compilation. Steps to reproduce the issue: 1. Setup toolchain 2. make coreboot-x86 # sucess for the first time 3. make # second make fails with message: make[1]: Entering directory `/home/hua/git/u-boot/arch/x86/lib' make[1]: *** No rule to make target `.depend', needed by `built-in.o'. Stop. make[1]: Leaving directory `/home/hua/git/u-boot/arch/x86/lib' Can anyone give some hints in how to solve this issue? Regards, Yanghao

2 3

[U-Boot] [PATCH 0/2] i2c: sh_i2c: bugfix: i2c probe command does now work
by Tetsuyuki Kobayashi 14 Apr '14

14 Apr '14

Hello, I found i2c probe command bug on kzm9g board and fixed it. I know it is the last minute to v2014.04, but I want these patches merged. Please review. Tetsuyuki Kobayashi (2): i2c: sh_i2c: bugfix: i2c probe command does now work arm: kzm9g: Add CONFIG_SYS_GENERIC_BOARD drivers/i2c/sh_i2c.c | 2 +- include/configs/kzm9g.h | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) -- 1.7.9.5

1 3