Re: [U-Boot] BCH8 support when we do not have ELM h/w engine.
Hi Pekon, 2014/1/13 Gupta, Pekon : > Hi Enric, > >> >>Hi Pekon, >> >>2013/12/10 Gupta, Pekon : >>> Hi Enric, >>> >>> Sorry I missed your earlier mail, so din't check this.. >>> >>>>From: Enric Balletbo Serra [mailto:eballe...@gmail.com] >>>>> >>>>> I saw that the OOB layout is not the same when I flash the rootfs from >>>>> the u-boot or from the kernel. For example: >>>>> >>>>> If the rootfs is flashed from the kernel the OOB data is like that: >>>>> >>>>> U-Boot # nand dump.oob 0x68 >>>>> Page 0068 dump: >>>>> OOB: >>>>> ff ff 79 43 68 64 3b 80 >>>>> b2 46 49 4d 58 2a 6d ff >>>>> 52 3f 7d 2a 7f a2 98 70 >>>>> 57 32 30 35 c7 ff ff ff >>>>> ff ff ff ff ff ff ff ff >>>>> ff ff ff ff ff ff ff ff >>>>> ff ff ff ff ff ff ff ff >>>>> ff ff ff ff ff ff ff ff >>>>> >>>>> If the rootfs is flashed for the u-boot the OOB data is like data: >>>>> >>>>> Page 0068 dump: >>>>> OOB: >>>>> ff ff 79 43 68 64 3b 80 >>>>> b2 46 49 4d 58 2a 6d 52 >>>>> 3f 7d 2a 7f a2 98 70 57 >>>>> 32 30 35 c7 ff ff ff ff >>>>> ff ff ff ff ff ff ff ff >>>>> ff ff ff ff ff ff ff ff >>>>> ff ff ff ff ff ff ff ff >>>>> ff ff ff ff ff ff ff ff >>>>> >>>>> Note that look the same except after byte number 16. In the first case is >>>>> ff 52 3f 7d 2a 7f a2 98 70 >>>>> and in the second case is >>>>> 52 3f 7d 2a 7f a2 98 70 >>>>> >>>>> It's possible that something is wrong writting the OOB data ? Any clue >>>>> ? I'm in the right direction or completely wrong ? >>>>> >>> Yes, there seems to be an mis-match between u-boot and kernel >>> ecc-layout. Give me a day's time, and I'll try to root cause this. >>> However, don't have OMAP3 boards, so I can test this only on other boards. >>> >>> with regards, pekon >> >>If I can help somehow just let me know. >> > I have posted the patches to fix this regression between u-boot and kernel. > And was expecting if you could test it confirm if this solves regression on > your > OMAP3 board. > http://lists.infradead.org/pipermail/linux-mtd/2014-January/051384.html > > You can download the patch from [1] > [1] http://lists.infradead.org/pipermail/linux-mtd/2013-December/050944.html > > > with regards, pekon Thanks for the patches, I tested and worked for me on our OMAP3 based boards, I'll answer the mail that you sent to the linux-omap ML. Sorry for the delay, cheers, Enric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH 0/7] TI: OMAP3: Use common config file.
Hi Tom,
2014/1/6 Tom Rini :
> On Mon, Dec 23, 2013 at 12:11:25PM +0100, Enric Balletbo Serra wrote:
>> 2013/12/6 Enric Balletbo i Serra :
>> > Hi all,
>> >
>> > Most of the boards based on TI processors uses common configuration files
>> > (ti_armv7_common.h, ti__common.h) to avoid duplication of code.
>> > This is right except for OMAP3-based boards. In order to use the same
>> > schema
>> > as used on am33xx, omap4, omap5 and dra7 TI processors these patches create
>> > a new ti_omap3_common.h (that include ti_armv7_common.h) with the purpose
>> > that
>> > all OMAP3 board can use it.
>> >
>> > Patches 1 and 2 just renames current omap4|omap5_common.h to
>> > ti_omap4|omap5_common.h to be coherent with current ti_am33xx_common.h,
>> > ti_armv7_common.h and the new ti_omap3_common.h. It's just a cosmetic
>> > change so
>> > if people don't like it I don't have any inconvenient to remove from these
>> > series.
>> >
>> > Patches 3 and 4 modifies the ti_armv7_common.h to be more compatible with
>> > OMAP3
>> > boards. For example, patch 3 removes the assumption that all ti_armv7 have
>> > an
>> > ELM hardware engine and patch 4 handles the case that the number of DRAM
>> > banks
>> > is defined at board level. The patch 5 is also required to integrate the
>> > use
>> > of ti_armv7_common.h on OMAP3 boards.
>> >
>> > Patch 6 creates the new ti_omap3_common.h to be used for any OMAP3-based
>> > board.
>> >
>> > And finally, patch 7 moves the IGEP boards to use the new common file. As I
>> > only have IGEP hardware to test these patches I decided only implement the
>> > use
>> > case for these boards. I don't have any inconvenient to move other OMAP3
>> > boards
>> > to use this schema but I prefer leave the decision to the board
>> > maintainers.
>> >
>> > Any comments, improvements, fixes are welcome.
>> >
>> > Best regards,
>> >
>> > Enric Balletbo i Serra (7):
>> > ARM: OMAP4: Rename to ti_omap4_common.h
>> > ARM: OMAP5: Rename to ti_omap5_common.h
>> > TI: armv7: Move ELM support to SoC configuration file.
>> > TI: armv7: Do not define the number DRAM banks if is already defined.
>> > ARM: OMAP3: Rename OMAP3_PUBLIC_SRAM_* to NON_SECURE_SRAM_*
>> > TI: OMAP3: Create common config files for TI OMAP3 platforms.
>> > OMAP3: igep00x0: Convert to ti_omap3_common.h.
>> >
>> > arch/arm/include/asm/arch-omap3/omap3.h| 6 +-
>> > include/configs/dra7xx_evm.h | 4 +-
>> > include/configs/omap3_igep00x0.h | 190
>> > +
>> > include/configs/omap4_panda.h | 4 +-
>> > include/configs/omap4_sdp4430.h| 4 +-
>> > include/configs/omap5_uevm.h | 4 +-
>> > include/configs/ti_am335x_common.h | 4 +
>> > include/configs/ti_armv7_common.h | 11 +-
>> > include/configs/ti_omap3_common.h | 73
>> > .../configs/{omap4_common.h => ti_omap4_common.h} | 10 +-
>> > .../configs/{omap5_common.h => ti_omap5_common.h} | 10 +-
>> > 11 files changed, 118 insertions(+), 202 deletions(-)
>> > create mode 100644 include/configs/ti_omap3_common.h
>> > rename include/configs/{omap4_common.h => ti_omap4_common.h} (95%)
>> > rename include/configs/{omap5_common.h => ti_omap5_common.h} (95%)
>>
>> Ping, any comment on this patch series ?
>
> I intend to pick this up after v2014.01. Thanks!
>
Now that merge window is open, did you try to pick these patches?
There is an issue that affect the IGEP boards introduced by commit
commit f33b9bd3984fb11e1d8566a866adc5957b1e1c9d
arm: omap3: Enable clocks for peripherals only if they are used
To fix the issue, I need to modify the omap3_igep00x0.h file and I'm
thinking that it's preferable wait and send the patch after these
patches.
Also there is any plan to create a branch for 2014.01 with fixes ?
Cheers,
Enric
> --
> Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH 0/7] TI: OMAP3: Use common config file.
Hi Tom,
2014/1/24 Tom Rini :
> On Fri, Jan 24, 2014 at 09:45:36AM +0100, Enric Balletbo Serra wrote:
>> Hi Tom,
>>
>> 2014/1/6 Tom Rini :
>> > On Mon, Dec 23, 2013 at 12:11:25PM +0100, Enric Balletbo Serra wrote:
>> >> 2013/12/6 Enric Balletbo i Serra :
>> >> > Hi all,
>> >> >
>> >> > Most of the boards based on TI processors uses common configuration
>> >> > files
>> >> > (ti_armv7_common.h, ti__common.h) to avoid duplication of
>> >> > code.
>> >> > This is right except for OMAP3-based boards. In order to use the same
>> >> > schema
>> >> > as used on am33xx, omap4, omap5 and dra7 TI processors these patches
>> >> > create
>> >> > a new ti_omap3_common.h (that include ti_armv7_common.h) with the
>> >> > purpose that
>> >> > all OMAP3 board can use it.
>> >> >
>> >> > Patches 1 and 2 just renames current omap4|omap5_common.h to
>> >> > ti_omap4|omap5_common.h to be coherent with current ti_am33xx_common.h,
>> >> > ti_armv7_common.h and the new ti_omap3_common.h. It's just a cosmetic
>> >> > change so
>> >> > if people don't like it I don't have any inconvenient to remove from
>> >> > these
>> >> > series.
>> >> >
>> >> > Patches 3 and 4 modifies the ti_armv7_common.h to be more compatible
>> >> > with OMAP3
>> >> > boards. For example, patch 3 removes the assumption that all ti_armv7
>> >> > have an
>> >> > ELM hardware engine and patch 4 handles the case that the number of
>> >> > DRAM banks
>> >> > is defined at board level. The patch 5 is also required to integrate
>> >> > the use
>> >> > of ti_armv7_common.h on OMAP3 boards.
>> >> >
>> >> > Patch 6 creates the new ti_omap3_common.h to be used for any
>> >> > OMAP3-based board.
>> >> >
>> >> > And finally, patch 7 moves the IGEP boards to use the new common file.
>> >> > As I
>> >> > only have IGEP hardware to test these patches I decided only implement
>> >> > the use
>> >> > case for these boards. I don't have any inconvenient to move other
>> >> > OMAP3 boards
>> >> > to use this schema but I prefer leave the decision to the board
>> >> > maintainers.
>> >> >
>> >> > Any comments, improvements, fixes are welcome.
>> >> >
>> >> > Best regards,
>> >> >
>> >> > Enric Balletbo i Serra (7):
>> >> > ARM: OMAP4: Rename to ti_omap4_common.h
>> >> > ARM: OMAP5: Rename to ti_omap5_common.h
>> >> > TI: armv7: Move ELM support to SoC configuration file.
>> >> > TI: armv7: Do not define the number DRAM banks if is already defined.
>> >> > ARM: OMAP3: Rename OMAP3_PUBLIC_SRAM_* to NON_SECURE_SRAM_*
>> >> > TI: OMAP3: Create common config files for TI OMAP3 platforms.
>> >> > OMAP3: igep00x0: Convert to ti_omap3_common.h.
>> >> >
>> >> > arch/arm/include/asm/arch-omap3/omap3.h| 6 +-
>> >> > include/configs/dra7xx_evm.h | 4 +-
>> >> > include/configs/omap3_igep00x0.h | 190
>> >> > +
>> >> > include/configs/omap4_panda.h | 4 +-
>> >> > include/configs/omap4_sdp4430.h| 4 +-
>> >> > include/configs/omap5_uevm.h | 4 +-
>> >> > include/configs/ti_am335x_common.h | 4 +
>> >> > include/configs/ti_armv7_common.h | 11 +-
>> >> > include/configs/ti_omap3_common.h | 73
>> >> > .../configs/{omap4_common.h => ti_omap4_common.h} | 10 +-
>> >> > .../configs/{omap5_common.h => ti_omap5_common.h} | 10 +-
>> >> > 11 files changed, 118 insertions(+), 202 deletions(-)
>> >> > create mode 100644 include/configs/ti_omap3_common.h
>> >> > rename include/configs/{omap4_common.h => ti_omap4_common.h} (95%)
>> >> > rename include/configs/{omap5_common.h => ti_omap5_common.h} (95%)
>> >>
>> >> Ping, any comment on this patch series ?
>> >
>> > I intend to pick this up after v2014.01. Thanks!
>> >
>>
>> Now that merge window is open, did you try to pick these patches?
>
> I'm planning to today.
>
Good to know, I'll wait then.
>> There is an issue that affect the IGEP boards introduced by commit
>>
>> commit f33b9bd3984fb11e1d8566a866adc5957b1e1c9d
>> arm: omap3: Enable clocks for peripherals only if they are used
>>
>> To fix the issue, I need to modify the omap3_igep00x0.h file and I'm
>> thinking that it's preferable wait and send the patch after these
>> patches.
>>
>> Also there is any plan to create a branch for 2014.01 with fixes ?
>
> Depends on how many other boards also need to re-enable some clocks I
> guess.
>
I don't know, maybe someone with OMAP3 hardware can verify if it's
affected. IGEP boards are affected, my bad that I don't had time to
test in RC cycle :(
> --
> Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3: igep00x0: Enable required clocks for GPIO that are used.
Hi Tom, 2014-01-25 22:52 GMT+01:00 Enric Balletbo i Serra : > Enable required clocks for GPIO to fix a boot issue introduced by commit > f33b9bd3984fb11e1d8566a866adc5957b1e1c9d (arm: omap3: Enable clocks for > peripherals only if they are used). > > Without this patch the u-boot freezes after the following messages > > OMAP36XX/37XX-GP ES1.2, CPU-OPP2, L3-200MHz, Max CPU Clock 1 Ghz > IGEPv2 + LPDDR/NAND > I2C: ready > DRAM: 512 MiB > NAND: 512 MiB > MMC: OMAP SD/MMC: 0 > > Diving into the issue, the sequence that produces the u-boot freezes is > > setup_net_chip >|--> gpio_direction_out > |--> _set_gpio_dataout >|--> __raw_writel > > To avoid this we just need enable the clocks for GPIOs that are used, but it > would be interesting implement a mechanism to protect these situations and > make sure that the clock is enabled when we request a GPIO. > > Signed-off-by: Enric Balletbo i Serra > --- > include/configs/omap3_igep00x0.h | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/include/configs/omap3_igep00x0.h > b/include/configs/omap3_igep00x0.h > index 20fbbec..8cc23c1 100644 > --- a/include/configs/omap3_igep00x0.h > +++ b/include/configs/omap3_igep00x0.h > @@ -37,6 +37,11 @@ > #define CONFIG_SHOW_BOOT_PROGRESS > #endif > > +/* GPIO banks */ > +#define CONFIG_OMAP3_GPIO_3/* GPIO64 .. 95 is in GPIO bank 3 */ > +#define CONFIG_OMAP3_GPIO_5/* GPIO128..159 is in GPIO bank 5 */ > +#define CONFIG_OMAP3_GPIO_6/* GPIO160..191 is in GPIO bank 6 */ > + > /* USB */ > #define CONFIG_MUSB_UDC1 > #define CONFIG_USB_OMAP3 1 > -- > 1.8.3.2 > Any plan or inconvenient to include this ? It's important as current support for IGEP boards is broken ... Thanks, Enric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/8] SATA support for omap5_uevm and dra7_evm
Hi Roger, 2013/11/11 Roger Quadros : > Hi, > > This series adds SATA support for OMAP5 uevm and DRA7 evm. > > Patches are also availabe at > g...@github.com:rogerq/u-boot.git sata > > v3: > - get rid of custom perror() macro, use printf > - Fixed coding sytle issues > > v2: > - Address review comments in the RFC series > - Fix cache align error in the ahci driver > - Added dra7 support > > cheers, > -roger > > Roger Quadros (8): > ahci: Error out with message on malloc() failure > ahci: Fix cache align error messages > ARM: OMAP5: Add Pipe3 PHY driver > ARM: OMAP5: Add PRCM and Control information for SATA > ARM: OMAP5: Add SATA platform glue > ARM: omap5_uevm: Add SATA support > ARM: DRA7xx: Add PRCM and Control information for SATA > ARM: dra7_evm: Add SATA support > > arch/arm/cpu/armv7/omap-common/Makefile| 5 + > arch/arm/cpu/armv7/omap-common/pipe3-phy.c | 231 > + > arch/arm/cpu/armv7/omap-common/pipe3-phy.h | 36 + > arch/arm/cpu/armv7/omap-common/sata.c | 75 ++ > arch/arm/cpu/armv7/omap5/prcm-regs.c | 7 + > arch/arm/include/asm/arch-omap5/clock.h| 3 + > arch/arm/include/asm/arch-omap5/omap.h | 3 + > arch/arm/include/asm/arch-omap5/sata.h | 48 ++ > arch/arm/include/asm/omap_common.h | 2 + > board/ti/dra7xx/evm.c | 7 + > board/ti/omap5_uevm/evm.c | 7 + > drivers/block/ahci.c | 18 ++- > include/configs/dra7xx_evm.h | 11 ++ > include/configs/omap5_uevm.h | 10 ++ > 14 files changed, 457 insertions(+), 6 deletions(-) > create mode 100644 arch/arm/cpu/armv7/omap-common/pipe3-phy.c > create mode 100644 arch/arm/cpu/armv7/omap-common/pipe3-phy.h > create mode 100644 arch/arm/cpu/armv7/omap-common/sata.c > create mode 100644 arch/arm/include/asm/arch-omap5/sata.h > > -- > 1.8.3.2 > I've tested the patches in my board and worked for me. Note, but, although the patches apply cleanly in current master branch the build is broken due this commit: commit 4e1aa8437ae5baed2be79fff09aa70a293e61467 Author: Masahiro Yamada Date: Thu Oct 17 17:34:48 2013 +0900 armv7: convert makefiles to Kbuild style You should apply the following change in your patch number 3 (U-Boot-v3-3-8-ARM-OMAP5-Add-Pipe3-PHY-driver.patch) diff --git a/arch/arm/cpu/armv7/omap-common/Makefile b/arch/arm/cpu/armv7/omap-common/Makefile index 679c1a1..59f5352 100644 --- a/arch/arm/cpu/armv7/omap-common/Makefile +++ b/arch/arm/cpu/armv7/omap-common/Makefile @@ -18,7 +18,7 @@ obj-y += abb.o endif ifneq ($(CONFIG_OMAP54XX),) -COBJS += pipe3-phy.o +obj-y += pipe3-phy.o obj-$(CONFIG_SCSI_AHCI_PLAT) += sata.o endif And rebase the patch number 5 (U-Boot-v3-5-8-ARM-OMAP5-Add-SATA-platform-glue.patch) as after the change doesn't apply. Despite this: Tested-by: Enric Balletbo i Serra Cheers, Enric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP3 i2c issues on IGEP, u-boot 2013.10
Hi Thomas,
CC'ing Javier MartÃnez
2013/11/27 Thomas Petazzoni :
> Hello,
>
> We've recently updated from u-boot 2013.04 to u-boot 2013.10 on our
> IGEP boards (OMAP3 based, U-Boot shows "OMAP36XX/37XX-GP ES1.2"), and
> we're seeing random I2C communication problems at startup.
>
Right, I've reproduced the issue. Any OMAP3-based board affected for
this issue ?
> Most of the time it's just:
>
> """
> Out: serial
> Err: serial
> i2c_write: pads on bus 0 probably not configured (status=0x10)
> Could not write grp_sel to reg 96 (2)
> Die ID #500400029ff80168300f0701b011
> """
>
> and the boot goes on fine.
>
> But sometimes it's something like the below (which goes on
> indefinitely, preventing the platform from booting):
>
> """
> NAND: 512 MiB
> MMC: OMAP SD/MMC: 0
> i2c_write: pads on bus 0 probably not configured (status=0x10)
> i2c_write: pads on bus 0 probably not configured (status=0x10)
> i2c_write: pads on bus 0 probably not configured (status=0x10)
> i2c_write: pads on bus 0 probably not configured (status=0x10)
> i2c_write: pads on bus 0 probably not configured (status=0x10)
> i2c_write: pads on bus 0 probably not configured (status=0x10)
> i2c_write: pads on bus 0 probably not configured (status=0x10)
> i2c_write: pads on bus 0 probably not configured (status=0x10)
> i2c_write: pads on bus 0 probably not configured (status=0x10)
> i2c_write: pads on bus 0 probably not configured (status=0x10)
> i2c_read (addr phase): pads on bus 0 probably not configured (status=0x10)
> TWL4030:USB:Read[0xfd] Error 2
> i2c_write: pads on bus 0 probably not configured (status=0x10)
> TWL4030:USB:Write[0xfd] Error 2
> i2c_read (addr phase): pads on bus 0 probably not configured (status=0x10)
> TWL4030:USB:Read[0xfe] Error 2
> i2c_write: pads on bus 0 probably not configured (status=0x10)
> TWL4030:USB:Write[0xfe] Error 2
> i2c_read (addr phase): pads on bus 0 probably not configured (status=0x10)
> TWL4030:USB:Read[0xfe] Error 2
> i2c_write: pads on bus 0 probably not configured (status=0x10)
> TWL4030:USB:Write[0xfe] Error 2
> i2c_read (addr phase): pads on bus 0 probably not configured (status=0x10)
> TWL4030:USB:Read[0xff] Error 2
> i2c_read (addr phase): pads on bus 0 probably not configured (status=0x10)
> TWL4030:USB:Read[0xff] Error 2
> i2c_read (addr phase): pads on bus 0 probably not configured (status=0x10)
> TWL4030:USB:Read[0xff] Error 2
> i2c_read (addr phase): pads on bus 0 probably not configured (status=0x10)
> TWL4030:USB:Read[0xff] Error 2
> i2c_read (addr phase): pads on bus 0 probably not configured (status=0x10)
> [... more of these indefinitely ...]
> """
>
Looks like there is problem with i2c pads, but seeing the code are configured.
> or it can be *some* error messages, but the boot goes on:
>
> """
> NAND: 512 MiB
> MMC: OMAP SD/MMC: 0
> i2c_write: pads on bus 0 probably not configured (status=0x10)
> TWL4030:USB:Write[0x6] Error 2
> i2c_write: pads on bus 0 probably not configured (status=0x10)
> TWL4030:USB:Write[0x6] Error 2
> i2c_read (addr phase): pads on bus 0 probably not configured (status=0x10)
> TWL4030:USB:Read[0xfe] Error 2
> i2c_write: pads on bus 0 probably not configured (status=0x10)
> TWL4030:USB:Write[0xfe] Error 2
> In:serial
> Out: serial
> Err: serial
> i2c_write: pads on bus 0 probably not configured (status=0x10)
> Could not write vsel to reg 7d (2)
> i2c_write: pads on bus 0 probably not configured (status=0x10)
> Could not write vsel to reg 91 (2)
> i2c_write: pads on bus 0 probably not configured (status=0x10)
> Could not write vsel to reg 99 (2)
> Die ID #500400029ff80168300f0701b011
> Net: smc911x-0
> Hit any key to stop autoboot: 0
> U-Boot #
> """
>
> I see that 960187ffa125b3938fec4b827bd9e8c04a204af8 ("ARM: OMAP: I2C:
> New read, write and probe functions") has changed significantly the
> OMAP I2C driver. And it turns out that reverting this commit actually
> fixes the problem. No more error messages, no more hang at boot. The
> commit message says that it was tested on OMAP4, OMAP5 and AM335x, but
> apparently OMAP3 isn't working all that well with this commit.
>
> Best regards,
I'll try to investigate more.
Best regards,
Enric
>
> Thomas Petazzoni
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP3 i2c issues on IGEP, u-boot 2013.10
Hi Thomas,
2013/11/27 Thomas Petazzoni :
> Dear Enric Balletbo Serra,
>
> On Wed, 27 Nov 2013 14:56:15 +0100, Enric Balletbo Serra wrote:
>
>> 2013/11/27 Thomas Petazzoni :
>> > Hello,
>> >
>> > We've recently updated from u-boot 2013.04 to u-boot 2013.10 on our
>> > IGEP boards (OMAP3 based, U-Boot shows "OMAP36XX/37XX-GP ES1.2"), and
>> > we're seeing random I2C communication problems at startup.
>>
>> Right, I've reproduced the issue. Any OMAP3-based board affected for
>> this issue ?
>
> Not sure to understand your question: my paragraph above mentions the
> IGEP board as being the platform on which I'm seeing this. So indeed, a
> OMAP3-based board is affected. But maybe I misunderstood your question.
>
Oops, sorry, bad question :)
Anybody knows if other OMAP3-based boards are affected for this issue ?
>> > I see that 960187ffa125b3938fec4b827bd9e8c04a204af8 ("ARM: OMAP: I2C:
>> > New read, write and probe functions") has changed significantly the
>> > OMAP I2C driver. And it turns out that reverting this commit actually
>> > fixes the problem. No more error messages, no more hang at boot. The
>> > commit message says that it was tested on OMAP4, OMAP5 and AM335x, but
>> > apparently OMAP3 isn't working all that well with this commit.
>> >
>> > Best regards,
>>
>> I'll try to investigate more.
>
> Thanks! In the mean time, I'll just keep this commit reverted.
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP3 i2c issues on IGEP, u-boot 2013.10
Hi all, 2013/11/27 Nikita Kiryanov : > On 11/27/2013 06:10 PM, Thomas Petazzoni wrote: >> >> Dear Nikita Kiryanov, >> >> On Wed, 27 Nov 2013 17:52:31 +0200, Nikita Kiryanov wrote: >> >>> The zeroing of the cnt register also happens in other places in the >>> driver, and it is entirely possible that they should be removed for >>> OMAP3s as well. >>> >>> In my patch I removed it only for i2c_write() because the original >>> driver also zeroed the cnt register in I/O functions- except in >>> i2c_write(), and I decided to follow the original driver's lead. >>> >>> What happens if you remove all the lines that zero the cnt register? >> >> >> It works. I've removed all the writew(0, ...cnt register...), and then >> I've done at least 20 boots of the IGEP board, and all of them were >> successful. >> >> I've attached the ugly patch that comments out all of those cases. Of >> course, it's not a patch intended for merging, just to show which >> locations I've commented. >> >> Since I've absolutely no idea of the background for the problem, would >> you mind submitting a proper patch with a good explanation? I will be >> happy to test it, of course. > > > Sure. I'm about to leave office though, so I'll prepare it tomorrow. > >> >> Thanks! >> >> Thomas >> > > > -- > Regards, > Nikita. Maybe I'm wrong but I think the problem could be related to that OMAP3430 and OMAP3630 has a different I2C revision and current code don't handle this correctly, As I know the I2C revision on OMAP3630 and OMAP4 is the same but different than OMAP3530. If the Tom's board uses the OMAP3530 processor this will explain why he's not affected for the issue. Others like me and Thomas, using DM3730, have the problem because the driver do not handle this, it supposes that we're using an OMAP3530. See for example the following code in drivers/i2c/omap24xx_i2c.c, #if defined(CONFIG_OMAP243X) || defined(CONFIG_OMAP34XX) /* * Have to enable interrupts for OMAP2/3, these IPs don't have * an 'irqstatus_raw' register and we shall have to poll 'stat' */ writew(I2C_IE_XRDY_IE | I2C_IE_RRDY_IE | I2C_IE_ARDY_IE | I2C_IE_NACK_IE | I2C_IE_AL_IE, &i2c_base->ie); #endif This is right for OMAP34/35xx but not for OMAP36xx and AM/DM37xx As a reference see the following patch introduced in the kernel: commit f518b482c89b3ff51804f09c14b1cedbef811b84 Author: Jon Hunter Date: Thu Jun 28 20:41:31 2012 +0530 i2c: omap: Correct I2C revision for OMAP3 The OMAP3530 is based upon the same silicon as the OMAP3430 and so the I2C revision is the same for 3430 and 3530. However, the OMAP3630 device has the same I2C revision as OMAP4. Correct the revision definition to reflect this. This patch is based on work done by Jon Hunter Changes from his patch - Update OMAP_I2C_REV_ON_3430 also to reflect that it is same as 3530 Reviewed-by: Felipe Balbi Signed-off-by: Jon Hunter Signed-off-by: Shubhrajyoti D Signed-off-by: Wolfram Sang Best regards, Enric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] arm: omap: i2c: don't zero cnt in i2c_write
Hi Nikita, 2013/11/28 Nikita Kiryanov : > Writing zero into I2Ci.I2C_CNT register causes random I2C failures in OMAP3 > based devices. This seems to be related to the following advisory which > apears in multiple erratas for OMAP3 SoCs (OMAP35xx, DM37xx), as well as > OMAP4430 TRM: > > Advisory: > I2C Module Does Not Allow 0-Byte Data Requests > Details: > When configured as the master, the I2C module does not allow 0-byte data > transfers. Note: Programming I2Ci.I2C_CNT[15:0]: DCOUNT = 0 will cause > undefined behavior. > Workaround(s): > No workaround. Do not use 0-byte data requests. > > The writes in question are unnecessary from a functional point of view. > Most of them are done after I/O has finished, and the only one that preceds > I/O (in i2c_probe()) is also unnecessary because a stop bit is sent before > actual data transmission takes place. > > Therefore, remove all writes that zero the cnt register. > > Cc: Heiko Schocher > Cc: Thomas Petazzoni > Cc: Tom Rini > Cc: Lubomir Popov > Cc: Enric Balletbo Serra > Signed-off-by: Nikita Kiryanov > --- > Changes in V2: > Removed all instances of writew(0, &i2c_base->cnt) instead of just the > one in i2c_write (following a test of V1 by Thomas Petazzoni). > > drivers/i2c/omap24xx_i2c.c | 6 -- > 1 file changed, 6 deletions(-) > > diff --git a/drivers/i2c/omap24xx_i2c.c b/drivers/i2c/omap24xx_i2c.c > index 3d38c03..c784004 100644 > --- a/drivers/i2c/omap24xx_i2c.c > +++ b/drivers/i2c/omap24xx_i2c.c > @@ -158,7 +158,6 @@ static void omap24_i2c_init(struct i2c_adapter *adap, int > speed, int slaveadd) > udelay(1000); > flush_fifo(adap); > writew(0x, &i2c_base->stat); > - writew(0, &i2c_base->cnt); > } > > static void flush_fifo(struct i2c_adapter *adap) > @@ -198,8 +197,6 @@ static int omap24_i2c_probe(struct i2c_adapter *adap, > uchar chip) > return res; > > /* No data transfer, slave addr only */ > - writew(0, &i2c_base->cnt); > - /* Set slave address */ > writew(chip, &i2c_base->sa); > /* Stop bit needed here */ > writew(I2C_CON_EN | I2C_CON_MST | I2C_CON_STT | I2C_CON_TRX | > @@ -234,7 +231,6 @@ static int omap24_i2c_probe(struct i2c_adapter *adap, > uchar chip) > pr_exit: > flush_fifo(adap); > writew(0x, &i2c_base->stat); > - writew(0, &i2c_base->cnt); > return res; > } > > @@ -372,7 +368,6 @@ static int omap24_i2c_read(struct i2c_adapter *adap, > uchar chip, uint addr, > rd_exit: > flush_fifo(adap); > writew(0x, &i2c_base->stat); > - writew(0, &i2c_base->cnt); > return i2c_error; > } > > @@ -473,7 +468,6 @@ static int omap24_i2c_write(struct i2c_adapter *adap, > uchar chip, uint addr, > wr_exit: > flush_fifo(adap); > writew(0x, &i2c_base->stat); > - writew(0, &i2c_base->cnt); > return i2c_error; > } > > -- > 1.8.1.2 > Tested with various OMAP3 IGEP boards (with OMAP353x and DM373x) and works. Thanks, Enric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [uBoot] TI: configs: Commonize the boot of different devices
Hi Tom, 2013/12/4 Tom Rini : > On Wed, Nov 20, 2013 at 01:40:18PM -0600, Dan Murphy wrote: > >> Commonize in the ti_armv7_common.h the boot scripts for >> USB, MMC and NAND. >> >> Each board file can then select which BOOT_TARGETS are applicable >> for the target board. >> And any parameters based on that. >> >> Finally removed the findfdt from the common file and made this more board >> specific as omap4_common should not reference panda. >> >> This implemenation was adopted from the tegra-common-post.h file. > > OK, implementation wise, I think we might need to adapt the -post > concept here too. That will let us remove from the config files > themselves a number of: > #ifdef FOO > #undef FOO > #endif > #define FOO > > And it will also let new boards like cm_t335 opt in to > ti_am335x_common.h but not have to pick our bootcmd if they don't want > to (tegra-common-post.h allows for that). While not a big deal, > possibly, for cm_t335 it's probably a bigger deal for getting the > siemens boards adapted too. > > I think this also shows that we need to handle the DFU env settings > parts strictly inside of am335x_evm.h. I'm toying with a patch to cover > this, now. > > Thanks! > > -- > Tom > Just a small question that is related with this. There is any plan to commonize the configuration code for OMAP3 platforms (ti_omap3_common.h) like AM335x ? Best regards, Enric > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [uBoot] TI: configs: Commonize the boot of different devices
2013/12/4 Tom Rini : > On Wed, Dec 04, 2013 at 03:14:08PM +0100, Enric Balletbo Serra wrote: >> Hi Tom, >> >> 2013/12/4 Tom Rini : >> > On Wed, Nov 20, 2013 at 01:40:18PM -0600, Dan Murphy wrote: >> > >> >> Commonize in the ti_armv7_common.h the boot scripts for >> >> USB, MMC and NAND. >> >> >> >> Each board file can then select which BOOT_TARGETS are applicable >> >> for the target board. >> >> And any parameters based on that. >> >> >> >> Finally removed the findfdt from the common file and made this more board >> >> specific as omap4_common should not reference panda. >> >> >> >> This implemenation was adopted from the tegra-common-post.h file. >> > >> > OK, implementation wise, I think we might need to adapt the -post >> > concept here too. That will let us remove from the config files >> > themselves a number of: >> > #ifdef FOO >> > #undef FOO >> > #endif >> > #define FOO >> > >> > And it will also let new boards like cm_t335 opt in to >> > ti_am335x_common.h but not have to pick our bootcmd if they don't want >> > to (tegra-common-post.h allows for that). While not a big deal, >> > possibly, for cm_t335 it's probably a bigger deal for getting the >> > siemens boards adapted too. >> > >> > I think this also shows that we need to handle the DFU env settings >> > parts strictly inside of am335x_evm.h. I'm toying with a patch to cover >> > this, now. >> > >> > Thanks! >> >> Just a small question that is related with this. There is any plan to >> commonize the configuration code for OMAP3 platforms >> (ti_omap3_common.h) like AM335x ? > > I would love to see it happen, yes. It's not high up on my priority > list right now (along with doing omap3_evm* stuff cleaner) so I'd also > love to see the patch come from someone else. > Ok, maybe I've time to do this, I'll try to send a RFC with this during this week. Best regards, Enric > -- > Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] BCH8 support when we do not have ELM h/w engine.
Dear Pekon, I'm trying to enable the support for BCH8 for platforms that do not have ELM hardware engine. Maybe I'm missing something but my first and quick attempt was applying the following patch: http://pastebin.com/VUjuGChR With this patch I'm able to switch to OMAP_ECC_BCH8_CODE_HW_DETECTION_SW with the nandecc hw bch8 command. Then I tried to flash a ubi rootfs into the nand, but the kernel can't mount the filesystem, I see messages like that: [3.703582] ecc unrecoverable error [3.707244] UBI warning: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 2:0, read only 64 bytes, retry OTOH, if I flash the rootfs from the kernel (my board sets the ecc to bch8) I don't have any problem, I can mount without problems. I saw that the OOB layout is not the same when I flash the rootfs from the u-boot or from the kernel. For example: If the rootfs is flashed from the kernel the OOB data is like that: U-Boot # nand dump.oob 0x68 Page 0068 dump: OOB: ff ff 79 43 68 64 3b 80 b2 46 49 4d 58 2a 6d ff 52 3f 7d 2a 7f a2 98 70 57 32 30 35 c7 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff If the rootfs is flashed for the u-boot the OOB data is like data: Page 0068 dump: OOB: ff ff 79 43 68 64 3b 80 b2 46 49 4d 58 2a 6d 52 3f 7d 2a 7f a2 98 70 57 32 30 35 c7 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Note that look the same except after byte number 16. In the first case is ff 52 3f 7d 2a 7f a2 98 70 and in the second case is 52 3f 7d 2a 7f a2 98 70 It's possible that something is wrong writting the OOB data ? Any clue ? I'm in the right direction or completely wrong ? Thanks in advance, Enric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: nand: omap: add CONFIG_SPL_NAND_DEVICE_WIDTH to determine NAND device bus-width
Hi Pekon,
Just a comment for OMAP3-based IGEP boards, see below ...
2013/12/5 Pekon Gupta :
> This patch adds CONFIG_SPL_NAND_DEVICE_WIDTH to specify bus-width of NAND
> device
> CONFIG_SPL_NAND_DEVICE_WIDTH == 16: NAND device with x16 bus-width
> CONFIG_SPL_NAND_DEVICE_WIDTH == 8: NAND device with x8 bus-width
>
> Need for a separate CONFIG_xx arise from following situations.
> (1) SPL NAND drivers does not have framework to parse ONFI parameter page.
>
> (2) if !defined(CONFIG_SYS_NAND_SELF_INIT)
> |- board_nand_init()
> |- nand_scan()
>|- nand_scan_ident()
>|- nand_scan_tail()
>This means board_nand_init() is called before nand_scan_ident(). So NAND
>controller is initialized before the actual probing of NAND device.
>However some controller (like GPMC) need to be specifically configured for
>bus-width of NAND device.
>In such cases, bus-width of the NAND device should be known in advance
>of actual device probing. Hence, CONFIG_SPL_NAND_DEVICE_WIDTH is useful.
>
> (3) Non-ONFI compliant devices need some mechanism to specify device bus-width
>to driver.
>
> Signed-off-by: Pekon Gupta
> ---
> doc/README.nand| 9 +
> drivers/mtd/nand/omap_gpmc.c | 14 ++
> include/configs/am335x_evm.h | 1 +
> include/configs/am335x_igep0033.h | 1 +
> include/configs/am3517_crane.h | 1 +
> include/configs/am3517_evm.h | 1 +
> include/configs/cm_t35.h | 1 +
> include/configs/devkit8000.h | 1 +
> include/configs/dig297.h | 1 +
> include/configs/mcx.h | 1 +
> include/configs/omap3_beagle.h | 1 +
> include/configs/omap3_evm_common.h | 2 +-
> include/configs/omap3_igep00x0.h | 1 +
> include/configs/omap3_logic.h | 1 +
> include/configs/omap3_overo.h | 1 +
> include/configs/omap3_pandora.h| 2 +-
> include/configs/omap3_zoom1.h | 1 +
> include/configs/omap3_zoom2.h | 1 +
> include/configs/siemens-am33x-common.h | 1 +
> include/configs/tam3517-common.h | 1 +
> include/configs/tricorder.h| 1 +
> 21 files changed, 38 insertions(+), 6 deletions(-)
>
> diff --git a/doc/README.nand b/doc/README.nand
> index b91f198..a07863a 100644
> --- a/doc/README.nand
> +++ b/doc/README.nand
> @@ -190,6 +190,15 @@ Configuration Options:
> This is used by SoC platforms which do not have built-in ELM
> hardware engine required for BCH ECC correction.
>
> + CONFIG_SPL_NAND_DEVICE_WIDTH
> + Specifies bus-width of the default NAND device connected to SoC.
> + This config is useful for driver which cannot self initialize or
> + parse ONFI parameter (like SPL drivers), or for supporting non-ONFI
> + compliant devices.
> + This config can take following values:
> + - 8: x8 NAND devices is connected
> + - 16: x16 NAND device is connected
> +
>
> Platform specific options
> =
> diff --git a/drivers/mtd/nand/omap_gpmc.c b/drivers/mtd/nand/omap_gpmc.c
> index fae00be..1870152 100644
> --- a/drivers/mtd/nand/omap_gpmc.c
> +++ b/drivers/mtd/nand/omap_gpmc.c
> @@ -861,13 +861,19 @@ int board_nand_init(struct nand_chip *nand)
> nand->priv = &bch_priv;
> nand->cmd_ctrl = omap_nand_hwcontrol;
> nand->options |= NAND_NO_PADDING | NAND_CACHEPRG;
> - /* If we are 16 bit dev, our gpmc config tells us that */
> - if ((readl(&gpmc_cfg->cs[cs].config1) & 0x3000) == 0x1000)
> - nand->options |= NAND_BUSWIDTH_16;
> -
> nand->chip_delay = 100;
> nand->ecc.layout = &omap_ecclayout;
>
> + /* configure driver and controller based on NAND device bus-width */
> + gpmc_config = readl(&gpmc_cfg->cs[cs].config1);
> + if (CONFIG_SPL_NAND_DEVICE_WIDTH == 16) {
> + nand->options |= NAND_BUSWIDTH_16;
> + writel(gpmc_config | (0x1 << 12), &gpmc_cfg->cs[cs].config1);
> + } else {
> + nand->options &= ~NAND_BUSWIDTH_16;
> + writel(gpmc_config & ~(0x1 << 12), &gpmc_cfg->cs[cs].config1);
> + }
> +
> /* select ECC scheme */
> #if defined(CONFIG_NAND_OMAP_ECCSCHEME)
> err = omap_select_ecc_scheme(nand, CONFIG_NAND_OMAP_ECCSCHEME,
> diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
> index 9ccbc20..5f5804e 100644
> --- a/include/configs/am335x_evm.h
> +++ b/include/configs/am335x_evm.h
> @@ -228,6 +228,7 @@
> #define CONFIG_SYS_NAND_PAGE_SIZE 2048
> #define CONFIG_SYS_NAND_OOBSIZE64
> #define CONFIG_SYS_NAND_BLOCK_SIZE (128*1024)
> +#define CONFIG_SPL_NAND_DEVICE_WIDTH 8
> #define CONFIG_SYS_NAND_BAD_BLOCK_POS NAND_LARGE_BADBLOCK_POS
> #define CONFIG_SYS_NAND_ECCPOS { 2, 3, 4, 5, 6, 7, 8, 9, \
>
Re: [U-Boot] BCH8 support when we do not have ELM h/w engine.
2013/12/4 Enric Balletbo Serra : > Dear Pekon, > > I'm trying to enable the support for BCH8 for platforms that do not > have ELM hardware engine. Maybe I'm missing something but my first and > quick attempt was applying the following patch: > > http://pastebin.com/VUjuGChR > > With this patch I'm able to switch to > OMAP_ECC_BCH8_CODE_HW_DETECTION_SW with the nandecc hw bch8 command. > > Then I tried to flash a ubi rootfs into the nand, but the kernel can't > mount the filesystem, I see messages like that: > > [3.703582] ecc unrecoverable error > [3.707244] UBI warning: ubi_io_read: error -74 (ECC error) while > reading 64 bytes from PEB 2:0, read only 64 bytes, retry > > OTOH, if I flash the rootfs from the kernel (my board sets the ecc to > bch8) I don't have any problem, I can mount without problems. > > I saw that the OOB layout is not the same when I flash the rootfs from > the u-boot or from the kernel. For example: > > If the rootfs is flashed from the kernel the OOB data is like that: > > U-Boot # nand dump.oob 0x68 > Page 0068 dump: > OOB: > ff ff 79 43 68 64 3b 80 > b2 46 49 4d 58 2a 6d ff > 52 3f 7d 2a 7f a2 98 70 > 57 32 30 35 c7 ff ff ff > ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff ff > > If the rootfs is flashed for the u-boot the OOB data is like data: > > Page 0068 dump: > OOB: > ff ff 79 43 68 64 3b 80 > b2 46 49 4d 58 2a 6d 52 > 3f 7d 2a 7f a2 98 70 57 > 32 30 35 c7 ff ff ff ff > ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff ff > > Note that look the same except after byte number 16. In the first case is > ff 52 3f 7d 2a 7f a2 98 70 > and in the second case is > 52 3f 7d 2a 7f a2 98 70 > > It's possible that something is wrong writting the OOB data ? Any clue > ? I'm in the right direction or completely wrong ? > > Thanks in advance, >Enric Any clue about this ? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] BCH8 support when we do not have ELM h/w engine.
Hi Pekon, 2013/12/10 Gupta, Pekon : > Hi Enric, > > Sorry I missed your earlier mail, so din't check this.. > >>From: Enric Balletbo Serra [mailto:eballe...@gmail.com] >>> >>> I saw that the OOB layout is not the same when I flash the rootfs from >>> the u-boot or from the kernel. For example: >>> >>> If the rootfs is flashed from the kernel the OOB data is like that: >>> >>> U-Boot # nand dump.oob 0x68 >>> Page 0068 dump: >>> OOB: >>> ff ff 79 43 68 64 3b 80 >>> b2 46 49 4d 58 2a 6d ff >>> 52 3f 7d 2a 7f a2 98 70 >>> 57 32 30 35 c7 ff ff ff >>> ff ff ff ff ff ff ff ff >>> ff ff ff ff ff ff ff ff >>> ff ff ff ff ff ff ff ff >>> ff ff ff ff ff ff ff ff >>> >>> If the rootfs is flashed for the u-boot the OOB data is like data: >>> >>> Page 0068 dump: >>> OOB: >>> ff ff 79 43 68 64 3b 80 >>> b2 46 49 4d 58 2a 6d 52 >>> 3f 7d 2a 7f a2 98 70 57 >>> 32 30 35 c7 ff ff ff ff >>> ff ff ff ff ff ff ff ff >>> ff ff ff ff ff ff ff ff >>> ff ff ff ff ff ff ff ff >>> ff ff ff ff ff ff ff ff >>> >>> Note that look the same except after byte number 16. In the first case is >>> ff 52 3f 7d 2a 7f a2 98 70 >>> and in the second case is >>> 52 3f 7d 2a 7f a2 98 70 >>> >>> It's possible that something is wrong writting the OOB data ? Any clue >>> ? I'm in the right direction or completely wrong ? >>> > Yes, there seems to be an mis-match between u-boot and kernel > ecc-layout. Give me a day's time, and I'll try to root cause this. > However, don't have OMAP3 boards, so I can test this only on other boards. > > with regards, pekon If I can help somehow just let me know. Thanks, Enric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/8] SATA support for omap5_uevm and dra7_evm
Hi Roger, 2013/12/4 Tom Rini : > On Mon, Nov 11, 2013 at 04:56:36PM +0200, Roger Quadros wrote: > >> Hi, >> >> This series adds SATA support for OMAP5 uevm and DRA7 evm. >> >> Patches are also availabe at >> g...@github.com:rogerq/u-boot.git sata >> >> v3: >> - get rid of custom perror() macro, use printf >> - Fixed coding sytle issues >> >> v2: >> - Address review comments in the RFC series >> - Fix cache align error in the ahci driver >> - Added dra7 support >> >> cheers, >> -roger >> >> Roger Quadros (8): >> ahci: Error out with message on malloc() failure >> ahci: Fix cache align error messages >> ARM: OMAP5: Add Pipe3 PHY driver >> ARM: OMAP5: Add PRCM and Control information for SATA >> ARM: OMAP5: Add SATA platform glue >> ARM: omap5_uevm: Add SATA support >> ARM: DRA7xx: Add PRCM and Control information for SATA >> ARM: dra7_evm: Add SATA support > > Applied to u-boot-ti/master, thanks! > Now that this will go to mainline, I wonder to know if there is any plan to add SPL support to boot from SATA ? Thanks, Enric > -- > Tom > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH 0/7] TI: OMAP3: Use common config file.
2013/12/6 Enric Balletbo i Serra :
> Hi all,
>
> Most of the boards based on TI processors uses common configuration files
> (ti_armv7_common.h, ti__common.h) to avoid duplication of code.
> This is right except for OMAP3-based boards. In order to use the same schema
> as used on am33xx, omap4, omap5 and dra7 TI processors these patches create
> a new ti_omap3_common.h (that include ti_armv7_common.h) with the purpose that
> all OMAP3 board can use it.
>
> Patches 1 and 2 just renames current omap4|omap5_common.h to
> ti_omap4|omap5_common.h to be coherent with current ti_am33xx_common.h,
> ti_armv7_common.h and the new ti_omap3_common.h. It's just a cosmetic change
> so
> if people don't like it I don't have any inconvenient to remove from these
> series.
>
> Patches 3 and 4 modifies the ti_armv7_common.h to be more compatible with
> OMAP3
> boards. For example, patch 3 removes the assumption that all ti_armv7 have an
> ELM hardware engine and patch 4 handles the case that the number of DRAM banks
> is defined at board level. The patch 5 is also required to integrate the use
> of ti_armv7_common.h on OMAP3 boards.
>
> Patch 6 creates the new ti_omap3_common.h to be used for any OMAP3-based
> board.
>
> And finally, patch 7 moves the IGEP boards to use the new common file. As I
> only have IGEP hardware to test these patches I decided only implement the use
> case for these boards. I don't have any inconvenient to move other OMAP3
> boards
> to use this schema but I prefer leave the decision to the board maintainers.
>
> Any comments, improvements, fixes are welcome.
>
> Best regards,
>
> Enric Balletbo i Serra (7):
> ARM: OMAP4: Rename to ti_omap4_common.h
> ARM: OMAP5: Rename to ti_omap5_common.h
> TI: armv7: Move ELM support to SoC configuration file.
> TI: armv7: Do not define the number DRAM banks if is already defined.
> ARM: OMAP3: Rename OMAP3_PUBLIC_SRAM_* to NON_SECURE_SRAM_*
> TI: OMAP3: Create common config files for TI OMAP3 platforms.
> OMAP3: igep00x0: Convert to ti_omap3_common.h.
>
> arch/arm/include/asm/arch-omap3/omap3.h| 6 +-
> include/configs/dra7xx_evm.h | 4 +-
> include/configs/omap3_igep00x0.h | 190
> +
> include/configs/omap4_panda.h | 4 +-
> include/configs/omap4_sdp4430.h| 4 +-
> include/configs/omap5_uevm.h | 4 +-
> include/configs/ti_am335x_common.h | 4 +
> include/configs/ti_armv7_common.h | 11 +-
> include/configs/ti_omap3_common.h | 73
> .../configs/{omap4_common.h => ti_omap4_common.h} | 10 +-
> .../configs/{omap5_common.h => ti_omap5_common.h} | 10 +-
> 11 files changed, 118 insertions(+), 202 deletions(-)
> create mode 100644 include/configs/ti_omap3_common.h
> rename include/configs/{omap4_common.h => ti_omap4_common.h} (95%)
> rename include/configs/{omap5_common.h => ti_omap5_common.h} (95%)
>
> --
> 1.8.1.2
>
Ping, any comment on this patch series ?
Thanks,
Enric
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Return value of run command
Hi all,
Should the command 'run something"' return the value that returns
"something" or just return "true" if can execute something and "false"
if it can't ?
I'll explain. Imagine you have a variable that loads a file from the
mmc but this files doesn't exist.
loadfile=load mmc ${mmcdev} ${loadaddr} my-file
In the case you do the following script
if run loadfile; then echo "true"; else echo "false"; fi
the result is always "true", either the file doesn't exist
OTOH, if you do :
if ${loadfile}; then echo "true"; else echo "false"; fi
Then the result is "true" if file exist and "false" if file doesn't exist.
For me looks like the "run something" command should return the result
of the command but this is not the behaviour. With current behaviour
something like CONFIG_EXTRA_ENV_SETTINGS from
include/configs/am335x_evm.h file,
129 "echo SD/MMC found on device ${mmcdev};" \
130 "if run loadbootenv; then " \
131 "echo Loaded environment from ${bootenv};" \
132 "run importbootenv;" \
133 "fi;" \
Either uEnv.txt file exist or not, the "run loadbootenv" always
returns true, so always tries to run "run importbootenv". I supose
this is not the expected behaviour.
The question is. It's a problem with run command or with the
definition of CONFIG_EXTRA_ENV_SETTING, that should be something like
that:
- 130 "if run loadbootenv; then " \
+ 130 "if ${loadbootenv}; then " \
Best regards,
Enric
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: nfs: add dynamic wait period
Hi all,
2013/1/26 Matthias Brugger
> 2012/12/11 Matthias Brugger :
> > This patch tackles the time out problem which leads to break the
> > boot process, when loading file over nfs. The patch does two things.
> >
> > First of all, we just ignore messages that arrive with a rpc_id smaller
> > then the client id. We just interpret this messages as answers to
> > formaly timed out messages.
> >
> > Second, when a time out occurs we double the time to wait, so that we
> > do not stress the server resending the last message.
>
> Any comment on the patch?
>
> >
> > Signed-off-by: Matthias Brugger
> > ---
> > net/nfs.c | 73
> +++--
> > 1 file changed, 52 insertions(+), 21 deletions(-)
> >
> > diff --git a/net/nfs.c b/net/nfs.c
> > index 7f2393f..84aeda1 100644
> > --- a/net/nfs.c
> > +++ b/net/nfs.c
> > @@ -37,10 +37,14 @@
> > # define NFS_TIMEOUT CONFIG_NFS_TIMEOUT
> > #endif
> >
> > +#define NFS_RPC_ERR1
> > +#define NFS_RPC_DROP 124
> > +
> > static int fs_mounted;
> > static unsigned long rpc_id;
> > static int nfs_offset = -1;
> > static int nfs_len;
> > +static ulong nfs_timeout = NFS_TIMEOUT;
> >
> > static char dirfh[NFS_FHSIZE]; /* file handle of directory */
> > static char filefh[NFS_FHSIZE]; /* file handle of kernel image */
> > @@ -399,8 +403,10 @@ rpc_lookup_reply(int prog, uchar *pkt, unsigned len)
> >
> > debug("%s\n", __func__);
> >
> > - if (ntohl(rpc_pkt.u.reply.id) != rpc_id)
> > - return -1;
> > + if (ntohl(rpc_pkt.u.reply.id) > rpc_id)
> > + return -NFS_RPC_ERR;
> > + else if (ntohl(rpc_pkt.u.reply.id) < rpc_id)
> > + return -NFS_RPC_DROP;
> >
> > if (rpc_pkt.u.reply.rstatus ||
> > rpc_pkt.u.reply.verifier ||
> > @@ -428,8 +434,10 @@ nfs_mount_reply(uchar *pkt, unsigned len)
> >
> > memcpy((unsigned char *)&rpc_pkt, pkt, len);
> >
> > - if (ntohl(rpc_pkt.u.reply.id) != rpc_id)
> > - return -1;
> > + if (ntohl(rpc_pkt.u.reply.id) > rpc_id)
> > + return -NFS_RPC_ERR;
> > + else if (ntohl(rpc_pkt.u.reply.id) < rpc_id)
> > + return -NFS_RPC_DROP;
> >
> > if (rpc_pkt.u.reply.rstatus ||
> > rpc_pkt.u.reply.verifier ||
> > @@ -452,8 +460,10 @@ nfs_umountall_reply(uchar *pkt, unsigned len)
> >
> > memcpy((unsigned char *)&rpc_pkt, pkt, len);
> >
> > - if (ntohl(rpc_pkt.u.reply.id) != rpc_id)
> > - return -1;
> > + if (ntohl(rpc_pkt.u.reply.id) > rpc_id)
> > + return -NFS_RPC_ERR;
> > + else if (ntohl(rpc_pkt.u.reply.id) < rpc_id)
> > + return -NFS_RPC_DROP;
> >
> > if (rpc_pkt.u.reply.rstatus ||
> > rpc_pkt.u.reply.verifier ||
> > @@ -475,8 +485,10 @@ nfs_lookup_reply(uchar *pkt, unsigned len)
> >
> > memcpy((unsigned char *)&rpc_pkt, pkt, len);
> >
> > - if (ntohl(rpc_pkt.u.reply.id) != rpc_id)
> > - return -1;
> > + if (ntohl(rpc_pkt.u.reply.id) > rpc_id)
> > + return -NFS_RPC_ERR;
> > + else if (ntohl(rpc_pkt.u.reply.id) < rpc_id)
> > + return -NFS_RPC_DROP;
> >
> > if (rpc_pkt.u.reply.rstatus ||
> > rpc_pkt.u.reply.verifier ||
> > @@ -499,8 +511,10 @@ nfs_readlink_reply(uchar *pkt, unsigned len)
> >
> > memcpy((unsigned char *)&rpc_pkt, pkt, len);
> >
> > - if (ntohl(rpc_pkt.u.reply.id) != rpc_id)
> > - return -1;
> > + if (ntohl(rpc_pkt.u.reply.id) > rpc_id)
> > + return -NFS_RPC_ERR;
> > + else if (ntohl(rpc_pkt.u.reply.id) < rpc_id)
> > + return -NFS_RPC_DROP;
> >
> > if (rpc_pkt.u.reply.rstatus ||
> > rpc_pkt.u.reply.verifier ||
> > @@ -534,8 +548,10 @@ nfs_read_reply(uchar *pkt, unsigned len)
> >
> > memcpy((uchar *)&rpc_pkt, pkt, sizeof(rpc_pkt.u.reply));
> >
> > - if (ntohl(rpc_pkt.u.reply.id) != rpc_id)
> > - return -1;
> > + if (ntohl(rpc_pkt.u.reply.id) > rpc_id)
> > + return -NFS_RPC_ERR;
> > + else if (ntohl(rpc_pkt.u.reply.id) < rpc_id)
> > + return -NFS_RPC_DROP;
> >
> > if (rpc_pkt.u.reply.rstatus ||
> > rpc_pkt.u.reply.verifier ||
> > @@ -574,7 +590,7 @@ NfsTimeout(void)
> > NetStartAgain();
> > } else {
> > puts("T ");
> > - NetSetTimeout(NFS_TIMEOUT, NfsTimeout);
> > + NetSetTimeout(nfs_timeout + NFS_TIMEOUT *
> NfsTimeoutCount, NfsTimeout);
> > NfsSend();
> > }
> > }
> > @@ -583,6 +599,7 @@ static void
> > NfsHandler(uchar *pkt, unsigned dest, IPaddr_t sip, unsigned src,
> unsigned len)
> > {
> > int rlen;
> > + int reply;
> >
> > debug("%s\n", __func__);
> >
> > @@ -591,19 +608,24 @@ NfsHandler(uchar *pkt, unsigned dest, IPaddr_t
> sip, unsigned src, unsigned l
Re: [U-Boot] [PATCH] net: nfs: add dynamic wait period
Hi Joe, Thanks for answer. 2013/4/12 Joe Hershberger > Hi Matthias and Enric, > > On Fri, Apr 12, 2013 at 3:08 AM, Enric Balletbo Serra > wrote: > > Hi all, > > > > 2013/1/26 Matthias Brugger > >> > >> 2012/12/11 Matthias Brugger : > >> > This patch tackles the time out problem which leads to break the > >> > boot process, when loading file over nfs. The patch does two things. > >> > > >> > First of all, we just ignore messages that arrive with a rpc_id > smaller > >> > then the client id. We just interpret this messages as answers to > >> > formaly timed out messages. > >> > > >> > Second, when a time out occurs we double the time to wait, so that we > >> > do not stress the server resending the last message. > >> > >> Any comment on the patch? > >> > >> Hi Joe and Wolfgang, > >> > >> any comment on this? > > > > > > I had a problem when I tried to load via NFS. Firstly I tried to load the > > dtb image via NFS, secondly I tried to load the kernel image but if it > > doesn't work and the file is never loaded. > > > > Applying this patch solved the problem, but seems nobody acked or > answered > > Matthias. Is this patch the proper fix ? In that case it's possible to > apply > > ? If not, any comments how to solve this problem. > > > > Best regards, > > Enric > > I apologize for the tardiness of dealing with patches this release > cycle. I've been swamped at work. I'll get to these soon. > > Enric, would you like to send a Tested-by? > > Thanks, > -Joe > I tested this patch with an IGEPv2 board and an IGEP COM AQUILA. Tested-by: Enric Balletbo i Serra ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Not able to boot using zImage
Hi all,
I've some problems trying to boot a zImage with following command after
load the zImage and the fdt file on memory:
U-Boot > fdt addr ${dtbaddr}; fdt resize; bootz ${loadaddr} - ${dtbaddr}
But the sistem stops at Starting kernel ...
File transfer via NFS from server 192.168.2.245; our IP address is
192.168.2.242
Filename '/srv/nfs/sandbox/0/am335x/boot/zImage'.
Load address: 0x8000
Loading: #
done
Bytes transferred = 4011728 (3d36d0 hex)
link up on port 0, speed 100, full duplex
Using cpsw device
File transfer via NFS from server 192.168.2.245; our IP address is
192.168.2.242
Filename '/srv/nfs/sandbox/0/am335x/boot/am335x-base0033.dtb'.
Load address: 0x8160
Loading: ###T T
Abort
## Flattened Device Tree blob at 8160
Booting using the fdt blob at 0x8160
reserving fdt memory region: addr=8160 size=3000
Loading Device Tree to 8fe3b000, end 8fe40fff ... OK
Starting kernel ...
The same commands using the uImage instead of zImage works without
problems. Is expected to work ? Any clue before diving into the problem ?
Thanks in advance,
Enric
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Not able to boot using zImage
Hi Tom,
Thanks for your quick reply.
2013/6/20 Tom Rini
> On Thu, Jun 20, 2013 at 12:27:02PM +0200, Enric Balletbo Serra wrote:
>
> > Hi all,
> >
> > I've some problems trying to boot a zImage with following command after
> > load the zImage and the fdt file on memory:
> >
> > U-Boot > fdt addr ${dtbaddr}; fdt resize; bootz ${loadaddr} - ${dtbaddr}
> [snip]
> > The same commands using the uImage instead of zImage works without
> > problems. Is expected to work ? Any clue before diving into the problem ?
>
> Same kernel tree? And you're setting bootargs before you do any of the
> above?
>
>
Yes, same kernel tree and I set the bootargs before. But I think it was my
bad, it's not an u-boot problem as I tested on beaglebone and works.
The difference between the two cases I tested are the address. The one that
doesn't work using zImage and works with uImage is
dtbaddr=0x8160
loadaddr=0x8000
If I change the addresses like the used in beaglebone, then works
dtbaddr=0x8020
loadaddr=0x80F8
I need to check exactly what is thge problem with these addresses. Anyway
it's not an u-boot problem. Thanks for the support.
Best regards,
Enric
--
> Tom
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Build error of u-boot mater branch
Hi Bo, 2013/6/27 Bo Shen : > Hi All, > When build u-boot master branch, I meet the following of error. > ---8>--- > lib/rsa/rsa-sign.c:26:25: fatal error: openssl/rsa.h: No such file or > directory > ---<8--- > > The master git commit id I build is: > 1b9591c2375d59be333c98c760e06605007e20c3 (ColdFire: Update the > arch_global_date changes for mcf5441x) > > And lib/rsa/rsa-sign.c commit id is: > 19c402afa2e1190f596f35a84ac049b10d814f1f (image: Add RSA support for > image signing) > > Best Regards, > Bo Shen > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot FYI, from IRC eballetbo: I remarked that this morning as well. Install openssl dev package and you should be ok eballetbo: I think this is now used by mkimage, for signing, presumably? vstehle: ok, i see, now these headers are required to build the host tools. Thanks You should install openssl dev package in your host machine. Hope it helps you, Enric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] OMAP3: igep00x0: allow booting with a FDT from MMC
Hi Javier,
2013/7/14 Javier Martinez Canillas :
> IGEP boards now have Device Tree support in the mainline
> kernel. To boot an IGEP board using a DT, a uEnv.txt plain
> text file could be used to define a custom uenvcmd that will
> be run by the default boot command.
>
> It is more convenient to change the default boot command to
> allow loading a FDT if it is stored in a uSD/MMC partition.
> If no FDT is found then the command behaves just as it used
> so this change won't break existing setup for current users.
>
> Signed-off-by: Javier Martinez Canillas
> ---
> board/isee/igep00x0/igep00x0.c | 14 ++
> include/configs/igep00x0.h |9 +
> 2 files changed, 23 insertions(+), 0 deletions(-)
>
> diff --git a/board/isee/igep00x0/igep00x0.c b/board/isee/igep00x0/igep00x0.c
> index 0d4679d..fdd2773 100644
> --- a/board/isee/igep00x0/igep00x0.c
> +++ b/board/isee/igep00x0/igep00x0.c
> @@ -154,6 +154,18 @@ int board_mmc_init(bd_t *bis)
> }
> #endif
>
> +void set_fdt(void)
> +{
> + switch (gd->bd->bi_arch_number) {
> + case MACH_TYPE_IGEP0020:
> + setenv("fdtfile", "omap3-igep0020.dtb");
> + break;
> + case MACH_TYPE_IGEP0030:
> + setenv("fdtfile", "omap3-igep0030.dtb");
> + break;
> + }
> +}
> +
> /*
> * Routine: misc_init_r
> * Description: Configure board specific parts
> @@ -166,6 +178,8 @@ int misc_init_r(void)
>
> dieid_num_r();
>
> + set_fdt();
> +
> return 0;
> }
>
> diff --git a/include/configs/igep00x0.h b/include/configs/igep00x0.h
> index 1d8090b..72752af 100644
> --- a/include/configs/igep00x0.h
> +++ b/include/configs/igep00x0.h
> @@ -149,6 +149,7 @@
> #define CONFIG_EXTRA_ENV_SETTINGS \
> "usbtty=cdc_acm\0" \
> "loadaddr=0x8200\0" \
> + "fdtaddr=0x8160\0" \
> "usbtty=cdc_acm\0" \
> "console=ttyO2,115200n8\0" \
> "mpurate=auto\0" \
> @@ -180,9 +181,12 @@
> "importbootenv=echo Importing environment from mmc ...; " \
> "env import -t $loadaddr $filesize\0" \
> "loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0" \
> + "loadfdt=fatload mmc ${mmcdev} ${fdtaddr} ${fdtfile}\0" \
> "mmcboot=echo Booting from mmc ...; " \
> "run mmcargs; " \
> "bootm ${loadaddr}\0" \
> + "mmcbootfdt=echo Booting with DT from mmc ...; " \
> + "bootm ${loadaddr} - ${fdtaddr}\0" \
> "nandboot=echo Booting from onenand ...; " \
> "run nandargs; " \
> "onenand read ${loadaddr} 28 40; " \
> @@ -199,6 +203,11 @@
> "run uenvcmd;" \
> "fi;" \
> "if run loaduimage; then " \
> + "if test -n $fdtfile; then " \
> + "if run loadfdt; then " \
> + "run mmcbootfdt;" \
> + "fi;" \
> + "fi;" \
> "run mmcboot;" \
> "fi;" \
> "fi;" \
> --
> 1.7.7.6
>
As merge window is closed, I think we have time to discuss a bit more
this patch before sending for next merge window. I think it's time to
redefine the default boot arguments for all IGEP boards and unify as
possible the bootargs for IGEP0020, IGEP0030, IGEP0032 and IGEP0033.
I made also some work in this line, but is not finished yet. We can
send a the patch series for next merge window. These are the things
that I think the patches should have.
1. Enable the use of CMD_EXT4, CMD_FS_GENERIC and zImage.
https://github.com/eballetbo/u-boot/commit/38036e80a66f266f2c3fae82906c5c46a575f06b
As uImage is deprecated we should use zImages.
2. Add support for Flattened Device Tree.
For IGEP0033
https://github.com/eballetbo/u-boot/commit/46ddafddc5bb6968190848d273b9ca8fbbd120de
For IGEP0020/30/32
Your patch
Note that I made some modifications on where the zImage and the DTB
file is located. MLO and u-boot.img are from boot partition, and
zImage and dtb file are from rootfs partition (/boot/ directory). What
do you think about this ?
3. Boot from NAND using a ubifs
https://github.com/eballetbo/u-boot/commit/ebd8ab99b02ccbf08b4d50c60107b04c8129a8dd
I think is better use ubifs instead of jffs2, also note that
the zImage and the dtb are from rootfs partition using the ubifsload.
More ideas, comments ...
I would like that the bootargs betwen IGEP0020/30/32 and IGEP0033 were
as similar as possible.
Best regards,
Enric
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC] Improve bootargs for IGEP boards.
Now that all the IGEP boards have Device Tree support and uImage is deprecated in favour of zImage, maybe, it's time to rethink the default boot command. We can also use this to unify the different bootargs between IGEP0020/30/32 and IGEP0033 that now are a bit different. IMHO, basically, there are two uses cases that must complain the default bootargs: Booting from a SD-card and booting from Flash. Below, I present different options and I would like people opine to select the best. BOOT FROM SD-CARD o 1st proposal: Two partition with following files: - boot (FAT) : MLO + u-boot.img + zImage + dtb files + uEnv.txt - rootfs (ext2/3/4) : filesystem + kernel modules. The rootfs can mount the boot partition to /boot o 2nd proposal: Two partitions with following files: - boot (FAT) : MLO + u-boot.img - rootfs (ext2/3/4) : zImage + dtb files + uEnv.txt + kernel modules + filesystem BOOT FROM NAND: o 1st proposal: (the traditional layout) 5 partitions: SPL U-Boot U-Boot Environment Kernel (raw) Rootfs With a Device Tree kernel the problem is that we should use the kernel with appended dtb file or load the dtb file from rootfs. And if we need to load the dtb file from the rootfs, why not load the kernel also ? o 2nd proposal: 4 partitions: SPL U-Boot U-Boot Environment Filesystem (ubifs): zImage + kernel modules + dtbs files + filesystem So, what do you think is the best approach to be the default environment ? Better layouts ? Advantages - disadvantages for every layout ? Opinions are welcome. Thanks in advance, Enric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv2 0/3] new IGEP board support
Hi Tom, Any comments on these patch series ? 2013/2/7 Javier Martinez Canillas : > On Thu, Feb 7, 2013 at 11:40 AM, [Enric Balletbo i Serra > wrote: >> From: Enric Balletbo i Serra >> >> Hi all, >> >> This is the second version to add support to the IGEP COM PROTON board in >> current mainline. >> >> These patches applies on top of u-boot-ti repository as the following patch >> is >> required. >> >> OMAP3: use a single board file for IGEP devices >> commit 076be4528851126b56f2c1b84d07834297797f6c >> From Javier Martinez Canillas >> >> Changes since v1: >> * Only define CONFIG_SHOW_BOOT_PROGRESS for the machines that have a boot >> progress (thanks to Javier) >> * Also define CONFIG_CMD_NET on IGEP0032 machine (thanks to Javier) >> * Add new patch in the serie to fix a missing include. >> >> Thanks a lot for your comments, >> >> Enric Balletbo i Serra (3): >> OMAP3: igep00x0: use official board names. >> OMAP3: igep00x0: add missing include mach-types.h in config. >> OMAP3: igep00x0: Add new IGEP COM PROTON. >> > > For all the patches: > > Reviewed-by: Javier Martinez Canillas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] ARM: Add support for IGEP COM AQUILA/CYGNUS
Hi Tom, Thanks for your comments. 2013/4/4 Tom Rini > On Wed, Apr 03, 2013 at 03:12:03PM +0200, Enric Balletbo i Serra wrote: > > > From: Enric Balletbo i Serra > > > > The IGEP COM AQUILA and CYGNUS are industrial processors modules with > > following highlights: > > > > o AM3352/AM3354 Texas Instruments processor > > o Cortex-A8 ARM CPU > > o 3.3 volts Inputs / Outputs use industrial > > o 256 MB DDR3 SDRAM / 128 Megabytes FLASH > > o MicroSD card reader on-board > > o Ethernet controller on-board > > o JTAG debug connector available > > o Designed for industrial range purposes > > > > Signed-off-by: Enric Balletbo i Serra > > In general, yay. But some specific comments that I know you inherited: > > [snip] > > +/* Display cpuinfo */ > > +#define CONFIG_DISPLAY_CPUINFO > > +/* Add libfdt-based support */ > > +#define CONFIG_OF_LIBFDT > > +/* Enable passing of ATAGs */ > > +#define CONFIG_CMDLINE_TAG > > +#define CONFIG_SETUP_MEMORY_TAGS > > +#define CONFIG_INITRD_TAG > > Do you really have to support ATAGS and FDT? Just confirming. > No, I'll remove. > > > +/* Commands to include */ > > +#include > > + > > +#define CONFIG_CMD_ASKENV > > +#define CONFIG_CMD_BOOTZ > > +#define CONFIG_CMD_DHCP > > +#define CONFIG_CMD_ECHO > > +#define CONFIG_CMD_EXT2 > > +#define CONFIG_CMD_EXT4 > > +#define CONFIG_CMD_FAT > > +#define CONFIG_CMD_FS_GENERIC > > With CONFIG_CMD_FS_GENERIC and CMD_EXT4 do you really need CMD_EXT2 set? > You have reason, has no sense, I'll remove too. > > [snip] > > +#define CONFIG_ENV_VARS_UBOOT_CONFIG > > +#define CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG > > +#define CONFIG_EXTRA_ENV_SETTINGS \ > > + "loadaddr=0x8020\0" \ > > + "fdtaddr=0x80F8\0" \ > > + "fdt_high=0x\0" \ > > + "rdaddr=0x8100\0" \ > > + "bootfile=/boot/uImage\0" \ > > + "fdtfile=\0" \ > > You're setting the config options to get an easy run-time way to set > fdtfile but not providing a script command to set it nor a C function. > If you don't need run-time detection, just set fdtfile :) > > I'll remove ftd related variables until fdt support is not tested. > > +/* > > + * memtest works on 8 MB in DRAM after skipping 32MB from > > + * start addr of ram disk > > + */ > > +#define CONFIG_SYS_MEMTEST_START (PHYS_DRAM_1 + (64 * 1024 * 1024)) > > +#define CONFIG_SYS_MEMTEST_END (CONFIG_SYS_MEMTEST_START \ > > + + (8 * 1024 * 1024)) > > The comment is wrong, and you can do any of: > - Opt-out of mtest (and see Wolfgang's readme on why that's probably a > good idea) > Readed and convinced. Thanks for this point. > - Correct this to be all of RAM, minus a bit for a reasonably-sized > U-Boot to be running in. > > [snip] > > +#define MTDIDS_DEFAULT "nand0=nand" > > +#define MTDPARTS_DEFAULT "mtdparts=nand:512k(SPL),"\ > > + "1920k(U-Boot),128k(U-Boot Env),"\ > > + "5m(Kernel),-(File System)" > > Setting aside such a large space for U-Boot is something else you > inherited, do you want to re-evaluate this or too late? > > Is not too late, I'll reduce the U-Boot space, do you think 512k is sufficient ? > > +#define CONFIG_SPL_NET_SUPPORT > > +#define CONFIG_SPL_NET_VCI_STRING"AM335x U-Boot SPL" > > +#define CONFIG_SPL_ETH_SUPPORT > > Keeping in mind the errata involved, does your board support CPSW SPL > without needed the erratad-out mode? > We'll change the default bootmode in production boards so has no sense define this. I'll remove. I'll send version 2, thanks again. Cheers, Enric > > -- > Tom > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] ARM: Add support for IGEP COM AQUILA/CYGNUS
Tom, One more question... 2013/4/4 Enric Balletbo Serra > Hi Tom, > > Thanks for your comments. > > > 2013/4/4 Tom Rini > >> On Wed, Apr 03, 2013 at 03:12:03PM +0200, Enric Balletbo i Serra wrote: >> >> > From: Enric Balletbo i Serra >> > >> > The IGEP COM AQUILA and CYGNUS are industrial processors modules with >> > following highlights: >> > >> > o AM3352/AM3354 Texas Instruments processor >> > o Cortex-A8 ARM CPU >> > o 3.3 volts Inputs / Outputs use industrial >> > o 256 MB DDR3 SDRAM / 128 Megabytes FLASH >> > o MicroSD card reader on-board >> > o Ethernet controller on-board >> > o JTAG debug connector available >> > o Designed for industrial range purposes >> > >> > Signed-off-by: Enric Balletbo i Serra >> >> In general, yay. But some specific comments that I know you inherited: >> >> [snip] >> > +/* Display cpuinfo */ >> > +#define CONFIG_DISPLAY_CPUINFO >> > +/* Add libfdt-based support */ >> > +#define CONFIG_OF_LIBFDT >> > +/* Enable passing of ATAGs */ >> > +#define CONFIG_CMDLINE_TAG >> > +#define CONFIG_SETUP_MEMORY_TAGS >> > +#define CONFIG_INITRD_TAG >> >> Do you really have to support ATAGS and FDT? Just confirming. >> > > No, I'll remove. > > >> >> > +/* Commands to include */ >> > +#include >> > + >> > +#define CONFIG_CMD_ASKENV >> > +#define CONFIG_CMD_BOOTZ >> > +#define CONFIG_CMD_DHCP >> > +#define CONFIG_CMD_ECHO >> > +#define CONFIG_CMD_EXT2 >> > +#define CONFIG_CMD_EXT4 >> > +#define CONFIG_CMD_FAT >> > +#define CONFIG_CMD_FS_GENERIC >> >> With CONFIG_CMD_FS_GENERIC and CMD_EXT4 do you really need CMD_EXT2 set? >> > > You have reason, has no sense, I'll remove too. > > > >> >> [snip] >> > +#define CONFIG_ENV_VARS_UBOOT_CONFIG >> > +#define CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG >> > +#define CONFIG_EXTRA_ENV_SETTINGS \ >> > + "loadaddr=0x8020\0" \ >> > + "fdtaddr=0x80F8\0" \ >> > + "fdt_high=0x\0" \ >> > + "rdaddr=0x8100\0" \ >> > + "bootfile=/boot/uImage\0" \ >> > + "fdtfile=\0" \ >> >> You're setting the config options to get an easy run-time way to set >> fdtfile but not providing a script command to set it nor a C function. >> If you don't need run-time detection, just set fdtfile :) >> >> > I'll remove ftd related variables until fdt support is not tested. > > > >> > +/* >> > + * memtest works on 8 MB in DRAM after skipping 32MB from >> > + * start addr of ram disk >> > + */ >> > +#define CONFIG_SYS_MEMTEST_START (PHYS_DRAM_1 + (64 * 1024 * 1024)) >> > +#define CONFIG_SYS_MEMTEST_END (CONFIG_SYS_MEMTEST_START >> \ >> > + + (8 * 1024 * 1024)) >> >> The comment is wrong, and you can do any of: >> - Opt-out of mtest (and see Wolfgang's readme on why that's probably a >> good idea) >> > > Readed and convinced. Thanks for this point. > As explained in Wolfgang's readme shouldn't remove CONFIG_CMD_MEMTEST from config_cmd_default.h ? > > >> - Correct this to be all of RAM, minus a bit for a reasonably-sized >> U-Boot to be running in. >> >> [snip] >> > +#define MTDIDS_DEFAULT "nand0=nand" >> > +#define MTDPARTS_DEFAULT "mtdparts=nand:512k(SPL),"\ >> > + "1920k(U-Boot),128k(U-Boot Env),"\ >> > + "5m(Kernel),-(File System)" >> >> Setting aside such a large space for U-Boot is something else you >> inherited, do you want to re-evaluate this or too late? >> >> > Is not too late, I'll reduce the U-Boot space, do you think 512k is > sufficient ? > > > >> > +#define CONFIG_SPL_NET_SUPPORT >> > +#define CONFIG_SPL_NET_VCI_STRING"AM335x U-Boot SPL" >> > +#define CONFIG_SPL_ETH_SUPPORT >> >> Keeping in mind the errata involved, does your board support CPSW SPL >> without needed the erratad-out mode? >> > > We'll change the default bootmode in production boards so has no sense > define this. I'll remove. > > I'll send version 2, thanks again. > > Cheers, >Enric > > > >> >> -- >> Tom >> > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] am335x_evm: am33xx_spl_board_init function and scale core frequency
Hi Tom,
Just a comment below ...
2013/7/19 Tom Rini :
> Add a am33xx_spl_board_init (and enable the PMICs) that we may see,
> depending on the board we are running on. In all cases, we see if we
> can rely on the efuse_sma register to tell us the maximum speed. In the
> case of Beaglebone White, we need to make sure we are on AC power, and
> are on later than rev A1, and then we can ramp up to the PG1.0 maximum
> of 720Mhz. In the case of Beaglebone Black, we are either on PG2.0 that
> supports 1GHz or PG2.1. As PG2.0 may or may not have efuse_sma set, we
> cannot rely on this probe. In the case of the GP EVM, EVM SK and IDK we
> need to rely on the efuse_sma if we are on PG2.1, and the defaults for
> PG1.0/2.0.
>
> Signed-off-by: Tom Rini
> ---
> arch/arm/include/asm/arch-am33xx/clocks_am33xx.h |8 ++
> board/ti/am335x/board.c | 155
> ++
> include/configs/am335x_evm.h |4 +
> 3 files changed, 167 insertions(+)
>
> diff --git a/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h
> b/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h
> index 89b63d9..834f24f 100644
> --- a/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h
> +++ b/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h
> @@ -24,6 +24,14 @@
> #define CONFIG_SYS_MPUCLK 550
> #endif
>
> +/* MAIN PLL Fdll supported frequencies */
> +#define MPUPLL_M_1000 1000
> +#define MPUPLL_M_800 800
> +#define MPUPLL_M_720 720
> +#define MPUPLL_M_600 600
> +#define MPUPLL_M_550 550
> +#define MPUPLL_M_300 300
> +
> extern void pll_init(void);
> extern void enable_emif_clocks(void);
> extern void enable_dmm_clocks(void);
> diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
> index fdbe26c..6544931 100644
> --- a/board/ti/am335x/board.c
> +++ b/board/ti/am335x/board.c
> @@ -33,6 +33,8 @@
> #include
> #include
> #include
> +#include
> +#include
> #include "board.h"
>
> DECLARE_GLOBAL_DATA_PTR;
> @@ -282,6 +284,159 @@ int spl_start_uboot(void)
> }
> #endif
>
> +void am33xx_spl_board_init(void)
> +{
> + int mpu_vdd, mpu_pll, sil_rev;
> +
> + /* Assume PG 1.0 */
> + mpu_pll = MPUPLL_M_720;
> +
> + sil_rev = readl(&cdev->deviceid) >> 28;
> + if (sil_rev == 1)
> + /* PG 2.0, efuse may not be set. */
> + mpu_pll = MPUPLL_M_800;
> + else if (sil_rev >= 2) {
> + /* Check what the efuse says our max speed is. */
> + int efuse_arm_mpu_max_freq;
> + efuse_arm_mpu_max_freq = readl(&cdev->efuse_sma);
> + switch ((efuse_arm_mpu_max_freq & DEVICE_ID_MASK)) {
> + case AM335X_ZCZ_1000:
> + mpu_pll = MPUPLL_M_1000;
> + break;
> + case AM335X_ZCZ_800:
> + mpu_pll = MPUPLL_M_800;
> + break;
> + case AM335X_ZCZ_720:
> + mpu_pll = MPUPLL_M_720;
> + break;
> + case AM335X_ZCZ_600:
> + case AM335X_ZCE_600:
> + mpu_pll = MPUPLL_M_600;
> + break;
> + case AM335X_ZCZ_300:
> + case AM335X_ZCE_300:
> + mpu_pll = MPUPLL_M_300;
> + break;
> + }
> + }
> +
> + if (board_is_bone() || board_is_bone_lt()) {
> + /* BeagleBone PMIC Code */
> + int usb_cur_lim;
> +
> + /*
> +* Only perform PMIC configurations if board rev > A1
> +* on Beaglebone White
> +*/
> + if (board_is_bone() && !strncmp(header.version, "00A1", 4))
> + return;
> +
> + if (i2c_probe(TPS65217_CHIP_PM))
> + return;
> +
> + /*
> +* On Beaglebone White we need to ensure we have AC power
> +* before increasing the frequency.
> +*/
> + if (board_is_bone()) {
> + uchar pmic_status_reg;
> + if (tps65217_reg_read(STATUS, &pmic_status_reg))
> + return;
> + if (!(pmic_status_reg & PWR_SRC_AC_BITMASK)) {
> + puts("No AC power, disabling frequency
> switch\n");
> + return;
> + }
> + }
> +
> + /*
> +* Increase USB current limit to 1300mA or 1800mA and set
> +* the MPU voltage controller as needed.
> +*/
> + if (mpu_pll == MPUPLL_M_1000) {
> + usb_cur_lim = USB_INPUT_CUR_LIMIT_1800MA;
> + mpu_vdd = DCDC_VOLT_SEL_1325MV;
> + } else {
> + usb_cur_lim = USB_INPUT_CUR_LIMIT_1300MA;
> +
Re: [U-Boot] [RFC] Improve bootargs for IGEP boards.
Hi Tom, Thanks for the answer. 2013/7/18 Tom Rini : > On Tue, Jul 16, 2013 at 10:00:16AM +0200, Enric Balletbo Serra wrote: > > [snip] >> o 2nd proposal: >> >> 4 partitions: >> SPL >> U-Boot >> U-Boot Environment >> Filesystem (ubifs): zImage + kernel modules + dtbs files + filesystem > > A slight change here would be 3 "partitions" > 1) "SPL" (that covers the redundant locations as well) > 2) U-Boot > 3) UBI container of: env, redundant env and either filesystem with > kernel+dtbs, or kernel and dtbs in their own volumes, I'm not sure which > is better there honestly. > > But I did want to highlight that we support U-Boot env in the UBI > container. > This looks interesting, can you provide more information about that ? Should I remove CONFIG_ENV_ADDR variable ? Could you provide an example ? Thanks in advance. Enric > -- > Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Improve bootargs for IGEP boards.
2013/7/23 Enric Balletbo Serra : > Hi Tom, > > Thanks for the answer. > > 2013/7/18 Tom Rini : >> On Tue, Jul 16, 2013 at 10:00:16AM +0200, Enric Balletbo Serra wrote: >> >> [snip] >>> o 2nd proposal: >>> >>> 4 partitions: >>> SPL >>> U-Boot >>> U-Boot Environment >>> Filesystem (ubifs): zImage + kernel modules + dtbs files + >>> filesystem >> >> A slight change here would be 3 "partitions" >> 1) "SPL" (that covers the redundant locations as well) >> 2) U-Boot >> 3) UBI container of: env, redundant env and either filesystem with >> kernel+dtbs, or kernel and dtbs in their own volumes, I'm not sure which >> is better there honestly. >> >> But I did want to highlight that we support U-Boot env in the UBI >> container. >> > > This looks interesting, can you provide more information about that ? > > Should I remove CONFIG_ENV_ADDR variable ? Could you provide an example ? > Ooops forget it ! I found the documentation about that in README. Thanks > Thanks in advance. > > Enric > >> -- >> Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] am335x_evm: am33xx_spl_board_init function and scale core frequency
Hi Tom,
2013/7/23 Dan Murphy :
> On 07/19/2013 02:00 PM, Tom Rini wrote:
>> Add a am33xx_spl_board_init (and enable the PMICs) that we may see,
>> depending on the board we are running on. In all cases, we see if we
>> can rely on the efuse_sma register to tell us the maximum speed. In the
>> case of Beaglebone White, we need to make sure we are on AC power, and
>> are on later than rev A1, and then we can ramp up to the PG1.0 maximum
>> of 720Mhz. In the case of Beaglebone Black, we are either on PG2.0 that
>> supports 1GHz or PG2.1. As PG2.0 may or may not have efuse_sma set, we
>> cannot rely on this probe. In the case of the GP EVM, EVM SK and IDK we
>> need to rely on the efuse_sma if we are on PG2.1, and the defaults for
>> PG1.0/2.0.
>>
>> Signed-off-by: Tom Rini
>> ---
>> arch/arm/include/asm/arch-am33xx/clocks_am33xx.h |8 ++
>> board/ti/am335x/board.c | 155
>> ++
>> include/configs/am335x_evm.h |4 +
>> 3 files changed, 167 insertions(+)
>>
>> diff --git a/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h
>> b/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h
>> index 89b63d9..834f24f 100644
>> --- a/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h
>> +++ b/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h
>> @@ -24,6 +24,14 @@
>> #define CONFIG_SYS_MPUCLK550
>> #endif
>>
>> +/* MAIN PLL Fdll supported frequencies */
>> +#define MPUPLL_M_10001000
>> +#define MPUPLL_M_800 800
>> +#define MPUPLL_M_720 720
>> +#define MPUPLL_M_600 600
>> +#define MPUPLL_M_550 550
>> +#define MPUPLL_M_300 300
>> +
>> extern void pll_init(void);
>> extern void enable_emif_clocks(void);
>> extern void enable_dmm_clocks(void);
>> diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
>> index fdbe26c..6544931 100644
>> --- a/board/ti/am335x/board.c
>> +++ b/board/ti/am335x/board.c
>> @@ -33,6 +33,8 @@
>> #include
>> #include
>> #include
>> +#include
>> +#include
>> #include "board.h"
>>
>> DECLARE_GLOBAL_DATA_PTR;
>> @@ -282,6 +284,159 @@ int spl_start_uboot(void)
>> }
>> #endif
>>
>> +void am33xx_spl_board_init(void)
>> +{
>> + int mpu_vdd, mpu_pll, sil_rev;
>> +
>> + /* Assume PG 1.0 */
>> + mpu_pll = MPUPLL_M_720;
>> +
>> + sil_rev = readl(&cdev->deviceid) >> 28;
>> + if (sil_rev == 1)
>> + /* PG 2.0, efuse may not be set. */
>> + mpu_pll = MPUPLL_M_800;
>> + else if (sil_rev >= 2) {
>> + /* Check what the efuse says our max speed is. */
>> + int efuse_arm_mpu_max_freq;
>> + efuse_arm_mpu_max_freq = readl(&cdev->efuse_sma);
>> + switch ((efuse_arm_mpu_max_freq & DEVICE_ID_MASK)) {
>> + case AM335X_ZCZ_1000:
>> + mpu_pll = MPUPLL_M_1000;
>> + break;
>> + case AM335X_ZCZ_800:
>> + mpu_pll = MPUPLL_M_800;
>> + break;
>> + case AM335X_ZCZ_720:
>> + mpu_pll = MPUPLL_M_720;
>> + break;
>> + case AM335X_ZCZ_600:
>> + case AM335X_ZCE_600:
>> + mpu_pll = MPUPLL_M_600;
>> + break;
>> + case AM335X_ZCZ_300:
>> + case AM335X_ZCE_300:
>> + mpu_pll = MPUPLL_M_300;
>> + break;
>> + }
>> + }
>> +
>> + if (board_is_bone() || board_is_bone_lt()) {
>> + /* BeagleBone PMIC Code */
>> + int usb_cur_lim;
>> +
>> + /*
>> + * Only perform PMIC configurations if board rev > A1
>> + * on Beaglebone White
>> + */
>> + if (board_is_bone() && !strncmp(header.version, "00A1", 4))
>> + return;
>> +
>> + if (i2c_probe(TPS65217_CHIP_PM))
>> + return;
>> +
>> + /*
>> + * On Beaglebone White we need to ensure we have AC power
>> + * before increasing the frequency.
>> + */
>> + if (board_is_bone()) {
>> + uchar pmic_status_reg;
>> + if (tps65217_reg_read(STATUS, &pmic_status_reg))
>> + return;
>> + if (!(pmic_status_reg & PWR_SRC_AC_BITMASK)) {
>> + puts("No AC power, disabling frequency
>> switch\n");
>> + return;
>> + }
>> + }
>> +
>> + /*
>> + * Increase USB current limit to 1300mA or 1800mA and set
>> + * the MPU voltage controller as needed.
>> + */
>> + if (mpu_pll == MPUPLL_M_1000) {
>> + usb_cur_lim = USB_INPUT_CUR_LIMIT_1800MA;
>> + mpu_vdd = DCDC_VOLT_SEL_1325MV;
>> + } else {
>> + usb_cur_lim = USB_INPUT_CUR_LIMIT_1300MA;
>> +
Re: [U-Boot] [PATCH v4 1/6] arm, am33xx: add defines for gmii_sel_register bits
Hi all,
Sorry for late reply, I was out of office.
2013/8/19 Tom Rini :
> On Mon, Aug 19, 2013 at 04:38:56PM +0200, Heiko Schocher wrote:
>
>> Signed-off-by: Heiko Schocher
>> Acked-by: Mugunthan V N
>
> Looks fine, but can we get this tested on the isee board too? It's a
> functional change there (since it was setting the NOTUSED bit that HW
> folks say really should not be set and will be marked as reserved in the
> next TRM respin). Thanks!
>
With this patch the IGEP COM AQUILA works as expected. Thanks.
Tested-by: Enric Balletbo i Serra
>>
>> ---
>> - changes for v2:
>> defined all bits used in the gmii_sel register as
>> Tom Rini suggested
>> - changes for v3:
>> rebased against u-boot-ti commit bb2a5d8f87fffb4fadfb205837decbd1b3e75f88
>> - changes for v4:
>> - rebased against u-boot-ti commit 425faf74cd8189c87919f7e72a0101c684ee3b9f
>> - add changes requested from Tom Rini:
>> - use after "#define" instead
>> - rename struct name "reserved" to "resv1"
>> - remove GMII1_SEL_NOTUSED and GMII2_SEL_NOTUSED defines, also
>> the GMII2_SEL_NOTUSED usage on the igep0033 board
>> - add "Acked-by: Mugunthan V N "
>> ---
>> arch/arm/include/asm/arch-am33xx/cpu.h | 19 +++
>> board/isee/igep0033/board.c| 6 ++
>> board/phytec/pcm051/board.c| 2 --
>> board/ti/am335x/board.c| 6 +-
>> 4 Dateien ge??ndert, 22 Zeilen hinzugef??gt(+), 11 Zeilen entfernt(-)
>>
>> diff --git a/arch/arm/include/asm/arch-am33xx/cpu.h
>> b/arch/arm/include/asm/arch-am33xx/cpu.h
>> index 10b56e0..f77ac1e 100644
>> --- a/arch/arm/include/asm/arch-am33xx/cpu.h
>> +++ b/arch/arm/include/asm/arch-am33xx/cpu.h
>> @@ -486,6 +486,25 @@ struct ctrl_dev {
>> unsigned int resv4[4];
>> unsigned int miisel;/* offset 0x50 */
>> };
>> +
>> +/* gmii_sel register defines */
>> +#define GMII1_SEL_MII0x0
>> +#define GMII1_SEL_RMII 0x1
>> +#define GMII1_SEL_RGMII 0x2
>> +#define GMII2_SEL_MII0x0
>> +#define GMII2_SEL_RMII 0x4
>> +#define GMII2_SEL_RGMII 0x8
>> +#define RGMII1_IDMODEBIT(4)
>> +#define RGMII2_IDMODEBIT(5)
>> +#define RMII1_IO_CLK_EN BIT(6)
>> +#define RMII2_IO_CLK_EN BIT(7)
>> +
>> +#define MII_MODE_ENABLE (GMII1_SEL_MII | GMII2_SEL_MII)
>> +#define RMII_MODE_ENABLE(GMII1_SEL_RMII | GMII2_SEL_RMII)
>> +#define RGMII_MODE_ENABLE(GMII1_SEL_RGMII | GMII2_SEL_RGMII)
>> +#define RGMII_INT_DELAY (RGMII1_IDMODE | RGMII2_IDMODE)
>> +#define RMII_CHIPCKL_ENABLE (RMII1_IO_CLK_EN | RMII2_IO_CLK_EN)
>> +
>> #endif /* __ASSEMBLY__ */
>> #endif /* __KERNEL_STRICT_NAMES */
>>
>> diff --git a/board/isee/igep0033/board.c b/board/isee/igep0033/board.c
>> index a24c22b..9e91f68 100644
>> --- a/board/isee/igep0033/board.c
>> +++ b/board/isee/igep0033/board.c
>> @@ -27,9 +27,6 @@
>>
>> DECLARE_GLOBAL_DATA_PTR;
>>
>> -/* MII mode defines */
>> -#define RMII_MODE_ENABLE 0x4D
>> -
>> static struct ctrl_dev *cdev = (struct ctrl_dev *)CTRL_DEVICE_BASE;
>>
>> #ifdef CONFIG_SPL_BUILD
>> @@ -158,7 +155,8 @@ int board_eth_init(bd_t *bis)
>> eth_setenv_enetaddr("ethaddr", mac_addr);
>> }
>>
>> - writel(RMII_MODE_ENABLE, &cdev->miisel);
>> + writel((GMII1_SEL_RMII | RMII1_IO_CLK_EN),
>> +&cdev->miisel);
>>
>> rv = cpsw_register(&cpsw_data);
>> if (rv < 0)
>> diff --git a/board/phytec/pcm051/board.c b/board/phytec/pcm051/board.c
>> index f53c5bb..e40b0bd 100644
>> --- a/board/phytec/pcm051/board.c
>> +++ b/board/phytec/pcm051/board.c
>> @@ -31,8 +31,6 @@
>> DECLARE_GLOBAL_DATA_PTR;
>>
>> /* MII mode defines */
>> -#define MII_MODE_ENABLE 0x0
>> -#define RGMII_MODE_ENABLE0xA
>> #define RMII_RGMII2_MODE_ENABLE 0x49
>>
>> static struct ctrl_dev *cdev = (struct ctrl_dev *)CTRL_DEVICE_BASE;
>> diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
>> index 04c37e2..cc04426 100644
>> --- a/board/ti/am335x/board.c
>> +++ b/board/ti/am335x/board.c
>> @@ -30,10 +30,6 @@
>>
>> DECLARE_GLOBAL_DATA_PTR;
>>
>> -/* MII mode defines */
>> -#define MII_MODE_ENABLE 0x0
>> -#define RGMII_MODE_ENABLE0x3A
>> -
>> /* GPIO that controls power to DDR on EVM-SK */
>> #define GPIO_DDR_VTT_EN 7
>>
>> @@ -460,7 +456,7 @@ int board_eth_init(bd_t *bis)
>> cpsw_slaves[0].phy_if = cpsw_slaves[1].phy_if =
>> PHY_INTERFACE_MODE_MII;
>> } else {
>> - writel(RGMII_MODE_ENABLE, &cdev->miisel);
>> + writel((RGMII_MODE_ENABLE | RGMII_INT_DELAY), &cdev->miisel);
>> cpsw_slaves[0].phy_if = cpsw_slaves[1].phy_if =
>> PHY_INTERFACE_MODE_RGMII;
>> }
>> --
>> 1.7.11.7
>>
>> ___
>> U-Boot mailing list
>>
Re: [U-Boot] [PATCH 1/2] ARM: IGEP0033: rename config file to am335x_igep0033.h
Hi Javier, Just an observation... 2013/8/31 Javier Martinez Canillas : > There seems to be a naming convention for the configuration > files for boards using the same SoC family. This makes > easier to do changes that affect different boards based > on the same SoC. > > Since the IGEP COM AQUILA use an AM3352/AM3354 processor is IGEP COM AQUILA can use AM3352/AM3354/AM3358 and AM3359, so maybe is better use AM335x here. > better to rename its board config to use this naming scheme. > > Signed-off-by: Javier Martinez Canillas > --- > boards.cfg|2 +- > include/configs/am335x_igep0033.h | 291 > + > include/configs/igep0033.h| 291 > - > 3 files changed, 292 insertions(+), 292 deletions(-) > create mode 100644 include/configs/am335x_igep0033.h > delete mode 100644 include/configs/igep0033.h > > diff --git a/boards.cfg b/boards.cfg > index 7ccc7ce..d717226 100644 > --- a/boards.cfg > +++ b/boards.cfg > @@ -302,7 +302,7 @@ igep0020_nandarm armv7 > igep00x0isee > igep0030 arm armv7 igep00x0 > isee omap3 > igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND > igep0030_nandarm armv7 igep00x0 > isee omap3 igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_NAND > igep0032 arm armv7 igep00x0 > isee omap3 > igep00x0:MACH_TYPE=MACH_TYPE_IGEP0032,BOOT_ONENAND > -igep0033 arm armv7 igep0033 > isee am33xx > +am335x_igep0033 arm armv7 igep0033 > isee am33xx > am3517_evm arm armv7 am3517evm > logicpdomap3 > mt_ventoux arm armv7 mt_ventoux > teejet omap3 > omap3_zoom1 arm armv7 zoom1 > logicpdomap3 > diff --git a/include/configs/am335x_igep0033.h > b/include/configs/am335x_igep0033.h > new file mode 100644 > index 000..e08fc14 > --- /dev/null > +++ b/include/configs/am335x_igep0033.h > @@ -0,0 +1,291 @@ > +/* > + * Copyright (C) 2013, ISEE 2007 SL - http://www.isee.biz/ > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License as > + * published by the Free Software Foundation version 2. > + * > + * This program is distributed "as is" WITHOUT ANY WARRANTY of any > + * kind, whether express or implied; without even the implied warranty > + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + */ > + > +#ifndef __CONFIG_IGEP0033_H > +#define __CONFIG_IGEP0033_H > + > +#define CONFIG_AM33XX > +#define CONFIG_OMAP > +#define CONFIG_OMAP_COMMON > + > +#include > + > +/* Mach type */ > +#define MACH_TYPE_IGEP0033 4521/* Until the next sync */ > +#define CONFIG_MACH_TYPE MACH_TYPE_IGEP0033 > + > +/* Clock defines */ > +#define V_OSCK 2400 /* Clock output from T2 */ > +#define V_SCLK (V_OSCK) > + > +#define CONFIG_ENV_SIZE(128 << 10) /* 128 KiB */ > +#define CONFIG_SYS_MALLOC_LEN (1024 << 10) > +#define CONFIG_SYS_LONGHELP/* undef to save memory */ > +#define CONFIG_SYS_HUSH_PARSER /* use "hush" command parser */ > +#define CONFIG_SYS_PROMPT "U-Boot# " > +#define CONFIG_SYS_NO_FLASH > + > +/* Display cpuinfo */ > +#define CONFIG_DISPLAY_CPUINFO > + > +/* Flattened Device Tree */ > +#define CONFIG_OF_LIBFDT > + > +/* Commands to include */ > +#include > + > +#define CONFIG_CMD_ASKENV > +#define CONFIG_CMD_BOOTZ > +#define CONFIG_CMD_DHCP > +#define CONFIG_CMD_ECHO > +#define CONFIG_CMD_EXT4 > +#define CONFIG_CMD_FAT > +#define CONFIG_CMD_FS_GENERIC > +#define CONFIG_CMD_MMC > +#define CONFIG_CMD_MTDPARTS > +#define CONFIG_CMD_NAND > +#define CONFIG_CMD_NET > +#define CONFIG_CMD_PING > +#define CONFIG_CMD_UBI > +#define CONFIG_CMD_UBIFS > + > +/* Make the verbose messages from UBI stop printing */ > +#define CONFIG_UBI_SILENCE_MSG > +#define CONFIG_UBIFS_SILENCE_MSG > + > +#define CONFIG_BOOTDELAY 1 /* negative for no autoboot */ > +#define CONFIG_ENV_VARS_UBOOT_CONFIG > +#define CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG > +#define CONFIG_EXTRA_ENV_SETTINGS \ > + "loadaddr=0x80F8\0" \ > + "dtbaddr=0x8020\0" \ > + "bootdir=/boot\0" \ > + "bootfile=zImage\0" \ > + "dtbfile=am335x-base0033.dtb\0" \ > + "console=ttyO0,115200n8\0" \ > + "mtdids=" MTDIDS_DEFAULT "\0" \ > + "mtdparts=" MTDPARTS_DEFAULT "\0" \ > + "mmcdev=0\0" \ > + "mmcroot=/dev/mmcblk
Re: [U-Boot] [PATCH 2/2] OMAP3: igep00x0: rename config file to omap3_igep00x0.h
Hi Javier, Just some minor changes ... 2013/8/31 Javier Martinez Canillas : > There seems to be a naming convention for the configuration > files for boards using the same SoC family. This makes > easier to do changes that affect different boards based > on the same SoC. > > Since the IGEP COM AQUILA use an AM3352/AM3354 processor is > better to rename its board config to use this naming scheme. > I thins the above comment doesn't apply to this patch, so better remove it. > Since the IGEPv2 board and the IGEP COM Module use an > OMAP3735/OMAP3735 processor is better to rename its board > config to use this naming scheme. The processors that are used in IGEPv2 Board are OMAP35xx/DM37xx > > Signed-off-by: Javier Martinez Canillas > --- > boards.cfg | 10 +- > include/configs/igep00x0.h | 370 > -- > include/configs/omap3_igep00x0.h | 370 > ++ > 3 files changed, 375 insertions(+), 375 deletions(-) > delete mode 100644 include/configs/igep00x0.h > create mode 100644 include/configs/omap3_igep00x0.h > > diff --git a/boards.cfg b/boards.cfg > index d717226..8f1cb6e 100644 > --- a/boards.cfg > +++ b/boards.cfg > @@ -297,11 +297,11 @@ omap3_overo arm armv7 > overo - > omap3_pandoraarm armv7 pandora - >omap3 > dig297 arm armv7 dig297 > comelitomap3 > cm_t35 arm armv7 cm_t35 > compulab omap3 > -igep0020 arm armv7 igep00x0 > isee omap3 > igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_ONENAND > -igep0020_nandarm armv7 igep00x0 > isee omap3 igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_NAND > -igep0030 arm armv7 igep00x0 > isee omap3 > igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND > -igep0030_nandarm armv7 igep00x0 > isee omap3 igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_NAND > -igep0032 arm armv7 igep00x0 > isee omap3 > igep00x0:MACH_TYPE=MACH_TYPE_IGEP0032,BOOT_ONENAND > +omap3_igep0020 arm armv7 igep00x0 > isee omap3 > omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_ONENAND > +omap3_igep0020_nand arm armv7 igep00x0 > isee omap3 > omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_NAND > +omap3_igep0030 arm armv7 igep00x0 > isee omap3 > omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND > +omap3_igep0030_nand arm armv7 igep00x0 > isee omap3 > omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_NAND > +omap3_igep0032 arm armv7 igep00x0 > isee omap3 > omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0032,BOOT_ONENAND > am335x_igep0033 arm armv7 igep0033 > isee am33xx > am3517_evm arm armv7 am3517evm > logicpdomap3 > mt_ventoux arm armv7 mt_ventoux > teejet omap3 > diff --git a/include/configs/igep00x0.h b/include/configs/igep00x0.h > deleted file mode 100644 > index 9982cf6..000 > --- a/include/configs/igep00x0.h > +++ /dev/null > @@ -1,370 +0,0 @@ > -/* > - * Common configuration settings for IGEP technology based boards > - * > - * (C) Copyright 2012 > - * ISEE 2007 SL, > - * > - * SPDX-License-Identifier:GPL-2.0+ > - */ > - > -#ifndef __IGEP00X0_H > -#define __IGEP00X0_H > - > -#include > - > -/* > - * High Level Configuration Options > - */ > -#define CONFIG_OMAP1 /* in a TI OMAP core */ > -#define CONFIG_OMAP34XX1 /* which is a 34XX */ > -#define CONFIG_OMAP_GPIO > -#define CONFIG_OMAP_COMMON > - > -#define CONFIG_SDRC/* The chip has SDRC controller */ > - > -#include > -#include > -#include > - > -/* > - * Display CPU and Board information > - */ > -#define CONFIG_DISPLAY_CPUINFO 1 > -#define CONFIG_DISPLAY_BOARDINFO 1 > - > -/* Clock Defines */ > -#define V_OSCK 2600/* Clock output from T2 */ > -#define V_SCLK (V_OSCK >> 1) > - > -#define CONFIG_MISC_INIT_R > - > -#define CONFIG_CMDLINE_TAG 1 /* enable passing of ATAGs */ > -#define CONFIG_SETUP_MEMORY_TAGS 1 > -#define CONFIG_INITRD_TAG 1 > -#define CONFIG_REVISION_TAG1 > - > -#define CONFIG_OF_LIBFDT > -#define CONFIG_CMD_BOOTZ >
Re: [U-Boot] [PATCH v2 2/2] OMAP3: igep00x0: rename config file to omap3_igep00x0.h
2013/9/2 Javier Martinez Canillas : > There seems to be a naming convention for the configuration > files for boards using the same SoC family. This makes > easier to do changes that affect different boards based > on the same SoC. > > Since the IGEPv2 board and the IGEP COM Module use a TI > OMAP35xx/DM37xx processor, is better to rename its board > config to use this naming scheme. > > Signed-off-by: Javier Martinez Canillas > --- > > Changes since v1: > - Fix some issues in the commit changelog pointed out by Enric Balletbo. > > boards.cfg | 10 +- > include/configs/igep00x0.h | 370 > --- > include/configs/omap3_igep00x0.h | 370 > +++ > 3 files changed, 375 insertions(+), 375 deletions(-) > delete mode 100644 include/configs/igep00x0.h > create mode 100644 include/configs/omap3_igep00x0.h > > diff --git a/boards.cfg b/boards.cfg > index d717226..8f1cb6e 100644 > --- a/boards.cfg > +++ b/boards.cfg > @@ -297,11 +297,11 @@ omap3_overo arm armv7 > overo - > omap3_pandoraarm armv7 pandora - >omap3 > dig297 arm armv7 dig297 > comelitomap3 > cm_t35 arm armv7 cm_t35 > compulab omap3 > -igep0020 arm armv7 igep00x0 > isee omap3 > igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_ONENAND > -igep0020_nandarm armv7 igep00x0 > isee omap3 igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_NAND > -igep0030 arm armv7 igep00x0 > isee omap3 > igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND > -igep0030_nandarm armv7 igep00x0 > isee omap3 igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_NAND > -igep0032 arm armv7 igep00x0 > isee omap3 > igep00x0:MACH_TYPE=MACH_TYPE_IGEP0032,BOOT_ONENAND > +omap3_igep0020 arm armv7 igep00x0 > isee omap3 > omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_ONENAND > +omap3_igep0020_nand arm armv7 igep00x0 > isee omap3 > omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_NAND > +omap3_igep0030 arm armv7 igep00x0 > isee omap3 > omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND > +omap3_igep0030_nand arm armv7 igep00x0 > isee omap3 > omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_NAND > +omap3_igep0032 arm armv7 igep00x0 > isee omap3 > omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0032,BOOT_ONENAND > am335x_igep0033 arm armv7 igep0033 > isee am33xx > am3517_evm arm armv7 am3517evm > logicpdomap3 > mt_ventoux arm armv7 mt_ventoux > teejet omap3 > diff --git a/include/configs/igep00x0.h b/include/configs/igep00x0.h > deleted file mode 100644 > index 9982cf6..000 > --- a/include/configs/igep00x0.h > +++ /dev/null > @@ -1,370 +0,0 @@ > -/* > - * Common configuration settings for IGEP technology based boards > - * > - * (C) Copyright 2012 > - * ISEE 2007 SL, > - * > - * SPDX-License-Identifier:GPL-2.0+ > - */ > - > -#ifndef __IGEP00X0_H > -#define __IGEP00X0_H > - > -#include > - > -/* > - * High Level Configuration Options > - */ > -#define CONFIG_OMAP1 /* in a TI OMAP core */ > -#define CONFIG_OMAP34XX1 /* which is a 34XX */ > -#define CONFIG_OMAP_GPIO > -#define CONFIG_OMAP_COMMON > - > -#define CONFIG_SDRC/* The chip has SDRC controller */ > - > -#include > -#include > -#include > - > -/* > - * Display CPU and Board information > - */ > -#define CONFIG_DISPLAY_CPUINFO 1 > -#define CONFIG_DISPLAY_BOARDINFO 1 > - > -/* Clock Defines */ > -#define V_OSCK 2600/* Clock output from T2 */ > -#define V_SCLK (V_OSCK >> 1) > - > -#define CONFIG_MISC_INIT_R > - > -#define CONFIG_CMDLINE_TAG 1 /* enable passing of ATAGs */ > -#define CONFIG_SETUP_MEMORY_TAGS 1 > -#define CONFIG_INITRD_TAG 1 > -#define CONFIG_REVISION_TAG1 > - > -#define CONFIG_OF_LIBFDT > -#define CONFIG_CMD_BOOTZ > -#define CONFIG_SUPPORT_RAW_INITRD > - > -/* > - * NS16550 Configuration > - */ > - > -#define V_NS16550_CLK 4800/* 48MHz (APLL96/2) */ > - > -#define CONFIG_SYS_NS16550 > -#define CONFI
Re: [U-Boot] [PATCH 0/1] Fix ethernet regression on pcm051
Hi Lars, 2013/9/26 Mugunthan V N : > On 9/25/2013 5:21 AM, Lars Poeschel wrote: >> From: Lars Poeschel >> >> I compiled and tried v2013.10-rc2 on pcm051 and it fails booting over >> tftp. I could bisect 2bf36ac638ab2db9f0295aa47064976eeebf80c1 as the >> cause of the problem. It moves bd_ram_ofs from the cpsw driver to the >> board files. Adding the bd_ram_ofs to the board file of pcm051 fixes >> the problem. That is what the patch does. >> A quick grep reveals, that igep0033 MAY also be affected. >> As the patch is simple and obivous and fixes a regression I'd like to >> get this in before the v2013.10 release. Many thanks to detect this, as you said the igep0033 machine is also affected for this, so this patch is required. Could you send a version 2 and add the patch for igep0033 in the series ?. You can also add my Tested-by: Enric Balletbo i Serra I'd like to get this series in before the v2013.10 release, too. >> >> Thanks >> >> Lars Poeschel (1): >> pcm051: Supply a bd_ram_ofs for the cpsw driver >> >> board/phytec/pcm051/board.c | 1 + >> 1 file changed, 1 insertion(+) >> > Acked-by: Mugunthan V N > > Regards > Mugunthan V N > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot Regards, Enric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: OMAP5: DDR3: Change io settings
Hi Sricharan,
2013/10/16 Sricharan R :
> Changing the IO settings to turn on VREF_DQ and
> disable weak pullup for DQS/nDQS.
>
> Signed-off-by: Sricharan R
> ---
> arch/arm/include/asm/arch-omap5/omap.h |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-omap5/omap.h
> b/arch/arm/include/asm/arch-omap5/omap.h
> index 414d37a..3c2306f 100644
> --- a/arch/arm/include/asm/arch-omap5/omap.h
> +++ b/arch/arm/include/asm/arch-omap5/omap.h
> @@ -145,9 +145,9 @@ struct s32ktimer {
> #define DDR_IO_2_VREF_CELLS_DDR3_VALUE 0x0
>
> #define DDR_IO_I_40OHM_SR_SLOWEST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x7C7C7C7C
> -#define DDR_IO_I_40OHM_SR_FAST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x64656465
> +#define DDR_IO_I_40OHM_SR_FAST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x64646464
> #define DDR_IO_0_VREF_CELLS_DDR3_VALUE_ES2 0xBAE8C631
> -#define DDR_IO_1_VREF_CELLS_DDR3_VALUE_ES2 0xB46318D8
> +#define DDR_IO_1_VREF_CELLS_DDR3_VALUE_ES2 0xBC6318DC
> #define DDR_IO_2_VREF_CELLS_DDR3_VALUE_ES2 0x8421
>
> #define EFUSE_1 0x45145100
> --
> 1.7.9.5
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
Sorry for my ignorance, I just want to know more ...
What's the purpose of this patch ? Solves any DDR3 problem on OMAP5 ? Improves ?
Thanks in advance,
Enric
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: OMAP5: DDR3: Change io settings
Hi Sricharan,
2013/10/16 Sricharan R :
> Hi,
>
> On Wednesday 16 October 2013 06:03 PM, Tom Rini wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 10/16/2013 07:34 AM, Enric Balletbo Serra wrote:
>>> Hi Sricharan,
>>>
>>> 2013/10/16 Sricharan R :
>>>> Changing the IO settings to turn on VREF_DQ and
>>>> disable weak pullup for DQS/nDQS.
>>>>
>>>> Signed-off-by: Sricharan R
>>>> ---
>>>> arch/arm/include/asm/arch-omap5/omap.h |4 ++--
>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/arch/arm/include/asm/arch-omap5/omap.h
>>>> b/arch/arm/include/asm/arch-omap5/omap.h
>>>> index 414d37a..3c2306f 100644
>>>> --- a/arch/arm/include/asm/arch-omap5/omap.h
>>>> +++ b/arch/arm/include/asm/arch-omap5/omap.h
>>>> @@ -145,9 +145,9 @@ struct s32ktimer {
>>>> #define DDR_IO_2_VREF_CELLS_DDR3_VALUE 0x0
>>>>
>>>> #define DDR_IO_I_40OHM_SR_SLOWEST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x7C7C7C7C
>>>> -#define DDR_IO_I_40OHM_SR_FAST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x64656465
>>>> +#define DDR_IO_I_40OHM_SR_FAST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x64646464
>>>> #define DDR_IO_0_VREF_CELLS_DDR3_VALUE_ES2 0xBAE8C631
>>>> -#define DDR_IO_1_VREF_CELLS_DDR3_VALUE_ES2 0xB46318D8
>>>> +#define DDR_IO_1_VREF_CELLS_DDR3_VALUE_ES2 0xBC6318DC
>>>> #define DDR_IO_2_VREF_CELLS_DDR3_VALUE_ES2 0x8421
>>>>
>>>> #define EFUSE_1 0x45145100
>>> Sorry for my ignorance, I just want to know more ...
>>>
>>> What's the purpose of this patch ? Solves any DDR3 problem on OMAP5 ?
>>> Improves ?
>> I suspect I know what this is about, but can we please have a more
>> verbose commit message here?
>
> Above the two changes improved DDR3 stability at extended temperature
> ranges above 83C.
>
> 1) The first change from 0x64656465 to 0x64646464 removes the weak pull
> on the DQ lines. Otherwise the DQ line was not staying at Vref when IDLE
> (retreats
> to ground) and because of this there were extra transitions and noise.
>
> 2) The second change was to enable internal VREF_DQ_OUT which otherwise was
> at 0V.
>
> Hope this helps. BTW, i will repost with a better commit log. Sorry.
>
> Regards,
> Sricharan
>
Many thanks for the explanation.
Best regards,
Enric
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: OMAP5: DDR3: Change io settings
Hi Brad and Sricharan, 2013/10/17 Sricharan R : > Hi Brad, > > On Thursday 17 October 2013 08:05 AM, Griffis, Brad wrote: >> First, Sricharan, thanks for putting together these patches and getting them >> posted so quickly. I approve of the code but wanted to comment on the >> commit message. Our previous (internal) thread had a hodge podge of issues, >> so I think there was some confusion there. In particular this comment was >> not 100% accurate: >> >>> 1) The first change from 0x64656465 to 0x64646464 removes the weak pull >>> on the DQ lines. Otherwise the DQ line was not staying at Vref when >>> IDLE (retreats >>> to ground) and because of this there were extra transitions and noise. >> It removes the weak pullup, yes. However, the DQ line not staying at VREF >> during IDLE was a different thing altogether and is not affected by this >> change. That's actually something that is hard-coded as part of the >> integration of the PHY into the SoC and is not configurable... >> >> This particular pullup affects both DQS and nDQS. We don't want to pull >> differential signals in the same direction. So, bottom line, disabling that >> weak pullup will improve the signal integrity. (I think I would leave the >> commit message at that.) >> >>> 2) The second change was to enable internal VREF_DQ_OUT which otherwise >>> was at 0V. >> The above description is entirely accurate and I would agree is suitable for >> the commit message. Here's a bit more detail for the archives... >> >> On the uEVM there are 4 DDR3 devices. The VREF for 2 of the devices is >> powered by the OMAP's VREF_CA_OUT pins. The VREF on the other 2 devices is >> powered by the OMAP's VREF_DQ_OUT pins. So the net effect here is that only >> half of the DDR3 devices were being supplied a VREF! This was clearly a >> mistake. This patch improves the robustness of the interface and was >> specifically seen to cure corruption observed at high temperatures on some >> boards. > Thanks for the accurate explanation, i will reword it with your suggestions > above. > > Regards, > Sricharan > Unfortunately, either, without your patch and with your patch applied on top of u-boot master, I'm still having issues with the memory on my uEVM. The board seems is working ok, It boots and I can use it normally without unexpected results, but doing a memtester I'm getting errors like this: # memtester 1500M 1 memtester version 4.2.2 (32-bit) Copyright (C) 2010 Charles Cazabon. Licensed under the GNU General Public License version 2 (only). pagesize is 4096 pagesizemask is 0xf000 want 1500MB (1572864000 bytes) got 1500MB (1572864000 bytes), trying mlock ...locked. Loop 1/1: Stuck Address : ok Random Value: FAILURE: 0x6ff35305 != 0x7ff35305 at offset 0x1dc1f2f0. FAILURE: 0x5b5f1d04 != 0x4b5f1d04 at offset 0x1df90aec. FAILURE: 0x7afb1b21 != 0x6afb1b21 at offset 0x1ee50aec. FAILURE: 0x6fbf70f6 != 0x7fbf70f6 at offset 0x1f15f2f0. FAILURE: 0xbffa76f0 != 0xaffa76f0 at offset 0x1f710aec. FAILURE: 0x8ff2323b != 0x9ff2323b at offset 0x2321f2f0. FAILURE: 0xf5ff18e7 != 0xe5ff18e7 at offset 0x259b0aec. FAILURE: 0x6bf988f2 != 0x7bf988f2 at offset 0x26bdf2f0. FAILURE: 0x9c069130 != 0x8c069130 at offset 0x1dc1f2f0. FAILURE: 0xa8aadf31 != 0xb8aadf31 at offset 0x1df90aec. FAILURE: 0x890ed914 != 0x990ed914 at offset 0x1ee50aec. FAILURE: 0x9c4ab2c3 != 0x8c4ab2c3 at offset 0x1f15f2f0. FAILURE: 0x4c0fb4c5 != 0x5c0fb4c5 at offset 0x1f710aec. FAILURE: 0x7c07f00e != 0x6c07f00e at offset 0x2321f2f0. FAILURE: 0x060adad2 != 0x160adad2 at offset 0x259b0aec. FAILURE: 0x980c4ac7 != 0x880c4ac7 at offset 0x26bdf2f0. Compare XOR : FAILURE: 0xcc2794e6 != 0xbc2794e6 at offset 0x1dc1f2f0. FAILURE: 0xd8cbe2e7 != 0xe8cbe2e7 at offset 0x1df90aec. FAILURE: 0xb92fdcca != 0xc92fdcca at offset 0x1ee50aec. FAILURE: 0xcc6bb679 != 0xbc6bb679 at offset 0x1f15f2f0. FAILURE: 0x7c30b87b != 0x8c30b87b at offset 0x1f710aec. FAILURE: 0xac28f3c4 != 0x9c28f3c4 at offset 0x2321f2f0. FAILURE: 0x362bde88 != 0x462bde88 at offset 0x259b0aec. FAILURE: 0xc82d4e7d != 0xb82d4e7d at offset 0x26bdf2f0. Compare SUB : ok Compare MUL : ok Compare DIV : ok Compare OR : ok Compare AND : ok Sequential Increment: ok Solid Bits : testing 60 FAILURE: 0xefff != 0x at offset 0x184bf2f0. Block Sequential: testing 59 FAILURE: 0x3b3b3b3b != 0x2b3b3b3b at offset 0x1b6ffaec. Checkerboard: testing 0 FAILURE: 0x4555 != 0x at offset 0x0507f2f0. Bit Spread : testing 0 FAILURE: 0xfffa != 0xeffa at offset 0x21b10aec. FAILURE: 0xfffa != 0xeffa at offset 0x2cbd0aec. Bit Flip: testing 2 FAILURE: 0xeffe != 0xfffe at offset 0x24d7f2f0. FAILURE: 0xeffe != 0xfffe at offset 0x2c05f2f0. Walking Ones: testing 0 FAILURE: 0xeffe != 0xfffe at offset 0x078df2f0. FAILURE: 0xeffe != 0xfffe at o
Re: [U-Boot] [RFC][PATCH 0/5] SATA support for OMAP5 uevm
Hi Roger, Thanks for the patches! 2013/11/6 Roger Quadros : > Hi, > > This series adds SATA support for OMAP5 uevm board. > > This is an RFC patchset for review only. Patches are based > on v2013.10. > > cheers, > -roger > > --- > Roger Quadros (5): > ahci: Error out with message on malloc() failure > ARM: OMAP5: Add Pipe3 PHY driver > ARM: OMAP5: Add PRCM and Control information for SATA > ARM: OMAP5: Add SATA platform glue > ARM: omap5_uevm: Add SATA support > > arch/arm/cpu/armv7/omap-common/Makefile| 7 + > arch/arm/cpu/armv7/omap-common/pipe3-phy.c | 233 > + > arch/arm/cpu/armv7/omap-common/pipe3-phy.h | 36 + > arch/arm/cpu/armv7/omap-common/sata.c | 78 ++ > arch/arm/cpu/armv7/omap5/prcm-regs.c | 5 + > arch/arm/include/asm/arch-omap5/clock.h| 3 + > arch/arm/include/asm/arch-omap5/omap.h | 3 + > arch/arm/include/asm/arch-omap5/sata.h | 48 ++ > arch/arm/include/asm/omap_common.h | 3 + > board/ti/omap5_uevm/evm.c | 7 + > drivers/block/ahci.c | 16 +- > include/configs/omap5_uevm.h | 10 ++ > 12 files changed, 447 insertions(+), 2 deletions(-) > create mode 100644 arch/arm/cpu/armv7/omap-common/pipe3-phy.c > create mode 100644 arch/arm/cpu/armv7/omap-common/pipe3-phy.h > create mode 100644 arch/arm/cpu/armv7/omap-common/sata.c > create mode 100644 arch/arm/include/asm/arch-omap5/sata.h > > -- > 1.8.3.2 > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot I applied your patches and worked perfectly, however I've two small issues. The first issue is that I see the following error: scanning bus for devices... ERROR: v7_dcache_inval_range - start address is not aligned - 0xfee48618 ERROR: v7_dcache_inval_range - stop address is not aligned - 0xfee48818 The second issue, and I'm not sure if the problem should be solved at u-boot level, is that I'm not able to access to the SATA disk at kernel level. I meant, if I boot to the system with latest stable u-boot the kernel recognizes the SATA disk and I'm able to mount, read and write to the disk. If I boot using u-boot with your patches applied the kernel doesn't recognizes the SATA disk and doesn't work. In that case the kernel reports the following error: ata1: COMRESET failed (errno=-16) Note that the kernel version that I'm using is 3.8.13 from git.ti.com. Cheers, Enric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/master
Hi Tom, 2014-03-06 16:45 GMT+01:00 Tom Rini : > Hey, > > The following changes since commit cc07294bc704694ae33db75b25ac557e5917a83f: > > arm: am335x: DXR2: Reset SMSC LAN9303 switch via GPIO upon bootup > (2014-03-04 09:42:07 -0500) > > are available in the git repository at: > > git://git.denx.de/u-boot-ti.git master > > for you to fetch changes up to 4b75fd510076f2261c5e21b9b8cf75c9f01ded3c: > > board/BuR/common: fix phy addresses (2014-03-06 10:43:50 -0500) > > > Hannes Petermaier (1): > board/BuR/common: fix phy addresses > > board/BuR/common/common.c |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > Thanks! > > -- > Tom > Would be possible add the following fix in next pull request ? http://lists.denx.de/pipermail/u-boot/2014-January/171884.html I sent some time ago and after various pull request was not included. It's ok or I need to change something ? Thanks, Enric > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap3: igep00x0: fix NAND_BOOT for igep_0020 and igep_0030
Hi Peko 2014-04-03 9:09 GMT+02:00 Pekon Gupta : > fixes commit e37e954eba3edb5015a0a02880d57517f57425d8 > OMAP3: igep00x0: Convert to ti_omap3_common.h. > > Above commit introduced compilation error when building igep0020 and igep0030 > boards for NAND boot. It removed 'CONFIG_SYS_NAND_U_BOOT_START' which tells > SPL/MLO offset of u-boot.img in NAND. > > Signed-off-by: Pekon Gupta > --- > include/configs/omap3_igep00x0.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/include/configs/omap3_igep00x0.h > b/include/configs/omap3_igep00x0.h > index 8b8583a..4e87d6b 100644 > --- a/include/configs/omap3_igep00x0.h > +++ b/include/configs/omap3_igep00x0.h > @@ -199,6 +199,8 @@ > #define CONFIG_SYS_NAND_ECCSIZE512 > #define CONFIG_SYS_NAND_ECCBYTES 3 > #define CONFIG_NAND_OMAP_ECCSCHEME OMAP_ECC_HAM1_CODE_HW > +#define CONFIG_SYS_NAND_U_BOOT_START CONFIG_SYS_TEXT_BASE > +#define CONFIG_SYS_NAND_U_BOOT_OFFS0x8 These two defines are defined in ti_armv7_common.h. The ti_armv7_common.h is included by ti_omap3_common.h, and omap3_igep00x0.h includes this file. So should not be necessary define this. I tried to build current mainline using igep0020_nand_config and built without errors for me. Which branch are you using ? > #endif > > #endif /* __IGEP00X0_H */ > -- > 1.8.5.1.163.gd7aced9 > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] OMAP3: igep00x0: add CONFIG_SPL_BOARD_INIT for CONFIG_SPL_NAND_SUPPORT
2012/12/28 Javier Martinez Canillas : > When booting an IGEPv2 board from NAND with SPL, U-Boot hangs > trying to read the OMAP General Purpose Memory Controller (GPMC). > > The reason is that the GPMC initialization function is called > inside spl_board_init() and this function is only executed when > CONFIG_SPL_BOARD_INIT is defined. > > Signed-off-by: Javier Martinez Canillas > --- > include/configs/igep00x0.h |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/include/configs/igep00x0.h b/include/configs/igep00x0.h > index 47f637e..2110e64 100644 > --- a/include/configs/igep00x0.h > +++ b/include/configs/igep00x0.h > @@ -318,6 +318,7 @@ > #define CONFIG_SYS_MMC_SD_FAT_BOOT_PARTITION 1 > #define CONFIG_SPL_FAT_LOAD_PAYLOAD_NAME "u-boot.img" > > +#define CONFIG_SPL_BOARD_INIT > #define CONFIG_SPL_LIBCOMMON_SUPPORT > #define CONFIG_SPL_LIBDISK_SUPPORT > #define CONFIG_SPL_I2C_SUPPORT > -- > 1.7.7.6 > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot Acked-by: Enric Balletbo i Serra ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] SPL: ONENAND: Support SPL to boot u-boot from OneNAND.
Hi Kyungmin,
Thanks for revisit the patch.
2013/2/5 Kyungmin Park :
> Hi,
>
> On Tue, Feb 5, 2013 at 6:23 PM, Enric Balletbo i Serra
> wrote:
>> From: Enric Balletbo i Serra
>>
>> This patch will allow use SPL to boot an u-boot from the OneNAND.
>>
>> Tested with IGEPv2 board with a OneNAND from Numonyx.
>>
>> Signed-off-by: Enric Balletbo i Serra
>> ---
>> arch/arm/cpu/armv7/omap3/board.c |2 +-
> It's not related with OneNAND SPL patch, can you split it two patches?
Ok, I'll do in v2.
>> common/spl/Makefile |1 +
>> common/spl/spl.c |5 +
>> common/spl/spl_onenand.c | 45
>> ++
>> 4 files changed, 52 insertions(+), 1 deletion(-)
>> create mode 100644 common/spl/spl_onenand.c
>>
>> diff --git a/arch/arm/cpu/armv7/omap3/board.c
>> b/arch/arm/cpu/armv7/omap3/board.c
>> index 89c587e..63063c8 100644
>> --- a/arch/arm/cpu/armv7/omap3/board.c
>> +++ b/arch/arm/cpu/armv7/omap3/board.c
>> @@ -110,7 +110,7 @@ int board_mmc_init(bd_t *bis)
>>
>> void spl_board_init(void)
>> {
>> -#ifdef CONFIG_SPL_NAND_SUPPORT
>> +#if defined(CONFIG_SPL_NAND_SUPPORT) || defined(CONFIG_SPL_ONENAND_SUPPORT)
>> gpmc_init();
>> #endif
>> #ifdef CONFIG_SPL_I2C_SUPPORT
>> diff --git a/common/spl/Makefile b/common/spl/Makefile
>> index 5698a23..da2afc1 100644
>> --- a/common/spl/Makefile
>> +++ b/common/spl/Makefile
>> @@ -18,6 +18,7 @@ COBJS-$(CONFIG_SPL_FRAMEWORK) += spl.o
>> COBJS-$(CONFIG_SPL_NOR_SUPPORT) += spl_nor.o
>> COBJS-$(CONFIG_SPL_YMODEM_SUPPORT) += spl_ymodem.o
>> COBJS-$(CONFIG_SPL_NAND_SUPPORT) += spl_nand.o
>> +COBJS-$(CONFIG_SPL_ONENAND_SUPPORT) += spl_onenand.o
>> COBJS-$(CONFIG_SPL_NET_SUPPORT) += spl_net.o
>> endif
>>
>> diff --git a/common/spl/spl.c b/common/spl/spl.c
>> index ff9ba7b..c584247 100644
>> --- a/common/spl/spl.c
>> +++ b/common/spl/spl.c
>> @@ -197,6 +197,11 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
>> spl_nand_load_image();
>> break;
>> #endif
>> +#ifdef CONFIG_SPL_ONENAND_SUPPORT
>> + case BOOT_DEVICE_ONE_NAND:
> ONE_NAND? It should be ONENAND.
Well, I used ONE_NAND because this define was already defined in
arch/arm/include/asm/arch-omap3/spl.h:29:#define BOOT_DEVICE_ONE_NAND 3
arch/arm/include/asm/arch-omap5/spl.h:30:#define BOOT_DEVICE_ONE_NAND4
arch/arm/include/asm/arch-omap4/spl.h:30:#define BOOT_DEVICE_ONE_NAND 4
arch/arm/include/asm/arch-mx35/spl.h:30:#define BOOT_DEVICE_ONE_NAND4
For me, also looks better use ONENAND, but then, I need to change all
these defines. What do you prefer ? Maintain the use of ONE_NAND or
change these defines ?
>> + spl_onenand_load_image();
>> + break;
>> +#endif
>> #ifdef CONFIG_SPL_NOR_SUPPORT
>> case BOOT_DEVICE_NOR:
>> spl_nor_load_image();
>> diff --git a/common/spl/spl_onenand.c b/common/spl/spl_onenand.c
>> new file mode 100644
>> index 000..247f97b
>> --- /dev/null
>> +++ b/common/spl/spl_onenand.c
>> @@ -0,0 +1,45 @@
>> +/*
>> + * Copyright (C) 2011
>> + * Corscience GmbH & Co. KG - Simon Schwarz
>> + *
>> + * See file CREDITS for list of people who contributed to this
>> + * project.
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License as
>> + * published by the Free Software Foundation; either version 2 of
>> + * the License, or (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program; if not, write to the Free Software
>> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
>> + * MA 02111-1307 USA
>> + */
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +void spl_onenand_load_image(void)
>> +{
>> + struct image_header *header;
>> + int *src __attribute__((unused));
>> + int *dst __attribute__((unused));
> why these are needed? just remove these.
>
Right, I'll remove.
> Thank you,
> Kyungmin Park
>> +
>> + debug("spl: onenand\n");
>> +
>> + /*use CONFIG_SYS_TEXT_BASE as temporary storage area */
>> + header = (struct image_header *)(CONFIG_SYS_TEXT_BASE);
>> + /* Load u-boot */
>> + onenand_spl_load_image(CONFIG_SYS_ONENAND_U_BOOT_OFFS,
>> + CONFIG_SYS_ONENAND_PAGE_SIZE, (void *)header);
>> + spl_parse_image_header(header);
>> + onenand_spl_load_image(CONFIG_SYS_ONENAND_U_BOOT_OFFS,
>> + spl_image.size, (void *)spl_image.load_addr);
>> +}
>> --
>> 1.7.10.4
>>
>> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>>
Re: [U-Boot] [PATCH 2/2] OMAP3: igep00x0: Add new IGEP COM PROTON.
Hi Javier,
Thanks for your comments.
2013/2/6 Javier Martinez Canillas :
> Hi Enric,
>
> On Wed, Feb 6, 2013 at 9:29 AM, Enric Balletbo i Serra
> wrote:
>> From: Enric Balletbo i Serra
>>
>> The IGEP COM PROTON is a new ultra compact module design with an
>> on-board ethernet controller.
>>
>> Signed-off-by: Enric Balletbo i Serra
>> ---
>> MAINTAINERS|1 +
>> board/isee/igep00x0/igep00x0.c |3 +++
>> board/isee/igep00x0/igep00x0.h |3 +++
>> boards.cfg |1 +
>> 4 files changed, 8 insertions(+)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index d3ed390..1aed6d9 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -607,6 +607,7 @@ Enric Balletbo i Serra
>>
>> igep0020ARM ARMV7 (OMAP3xx SoC)
>> igep0030ARM ARMV7 (OMAP3xx SoC)
>> + igep0032ARM ARMV7 (OMAP3xx SoC)
>>
>> Eric Benard
>>
>> diff --git a/board/isee/igep00x0/igep00x0.c b/board/isee/igep00x0/igep00x0.c
>> index 49fcf34..93aea8b 100644
>> --- a/board/isee/igep00x0/igep00x0.c
>> +++ b/board/isee/igep00x0/igep00x0.c
>> @@ -68,8 +68,11 @@ void show_boot_progress(int val)
>> return;
>> }
>>
>> +/* Skip in the case of IGEP0032 machine */
>> +#if !(CONFIG_MACH_TYPE == MACH_TYPE_IGEP0032)
>> if (!gpio_request(IGEP00X0_GPIO_LED, ""))
>> gpio_direction_output(IGEP00X0_GPIO_LED, 1);
>> +#endif
>> }
>> #endif
>>
>
> So, this board doesn't have a GPIO LED to show it boot status?
>
Yes, it has but not connected to one OMAP GPIO. There is a led to
indicate power and two leds connected to TWL. Maybe I could use one of
them but meanwhile I decided don't use these leds.
> If that's the case I think there is no point to call show_boot_progress().
> Since this function is only compiled when CONFIG_SHOW_BOOT_PROGRESS
> is defined. I think that a better approach is to just define it for the
> machines that have a boot progress GPIO LED. e.g:
>
> diff --git a/include/configs/igep00x0.h b/include/configs/igep00x0.h
> index 88eadb4..98eed0f 100644
> --- a/include/configs/igep00x0.h
> +++ b/include/configs/igep00x0.h
> @@ -85,8 +85,11 @@
> #define CONFIG_OMAP_HSMMC 1
> #define CONFIG_DOS_PARTITION 1
>
> +#if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0020) || \
> +(CONFIG_MACH_TYPE == MACH_TYPE_IGEP0030)
> /* define to enable boot progress via leds */
> #define CONFIG_SHOW_BOOT_PROGRESS
> +#endif
>
The problem is: if I disable the call to show_boot_progress in
igep00x0.h I'll get a compilation error in this function because
IGEP00X0_GPIO_LED is undeclared, so necessarily I need to protect the
call in igep00x0.c against this undefined reference. For that reason I
used the ifdef inside the show_boot_progress implementation.
> /* USB */
> #define CONFIG_MUSB_UDC1
>
>> diff --git a/board/isee/igep00x0/igep00x0.h b/board/isee/igep00x0/igep00x0.h
>> index dbc7cf6..f5fce9c 100644
>> --- a/board/isee/igep00x0/igep00x0.h
>> +++ b/board/isee/igep00x0/igep00x0.h
>> @@ -39,6 +39,9 @@ const omap3_sysinfo sysinfo = {
>> #if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0030)
>> "IGEP COM MODULE/ELECTRON",
>> #endif
>> +#if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0032)
>> + "IGEP COM PROTON",
>> +#endif
>> #if defined(CONFIG_ENV_IS_IN_ONENAND)
>> "ONENAND",
>> #else
>> diff --git a/boards.cfg b/boards.cfg
>> index 691a32a..8453836 100644
>> --- a/boards.cfg
>> +++ b/boards.cfg
>> @@ -259,6 +259,7 @@ igep0020 arm armv7
>> igep00x0isee
>> igep0020_nandarm armv7 igep00x0
>> isee omap3 igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_NAND
>> igep0030 arm armv7 igep00x0
>> isee omap3
>> igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND
>> igep0030_nandarm armv7 igep00x0
>> isee omap3 igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_NAND
>> +igep0032 arm armv7 igep00x0
>> isee omap3
>> igep00x0:MACH_TYPE=MACH_TYPE_IGEP0032,BOOT_ONENAND
>> am3517_evm arm armv7 am3517evm
>> logicpdomap3
>> mt_ventoux arm armv7 mt_ventoux
>> teejet omap3
>> omap3_zoom1 arm armv7 zoom1
>> logicpdomap3
>> --
>
> This doesn't have a NAND version too like IGEP0020 and IGEP0030 boards?
>
No, the IGEP0032 only has OneNAND.
> You said that this board has an on-board ethernet controller. Does
> this board use the
> SMC911X chip connected to the OMAP GPMC too? In that case I guess you need
> something like this to have CONFIG_CMD_NET enabled on
> board/isee/igep00x0/igep00x0.c
> for this board too:
>
> diff --git a/include/configs/igep00x0.h b/include/co
Re: [U-Boot] [PATCH 2/2] OMAP3: igep00x0: Add new IGEP COM PROTON.
Hi Javier,
2013/2/6 Javier Martinez Canillas :
> On Wed, Feb 6, 2013 at 3:42 PM, Enric Balletbo Serra
> wrote:
>> Hi Javier,
>>
>
> Hi Enric,
>
>> Thanks for your comments.
>>
>> 2013/2/6 Javier Martinez Canillas :
>>> Hi Enric,
>>>
>>> On Wed, Feb 6, 2013 at 9:29 AM, Enric Balletbo i Serra
>>> wrote:
>>>> From: Enric Balletbo i Serra
>>>>
>>>> The IGEP COM PROTON is a new ultra compact module design with an
>>>> on-board ethernet controller.
>>>>
>>>> Signed-off-by: Enric Balletbo i Serra
>>>> ---
>>>> MAINTAINERS|1 +
>>>> board/isee/igep00x0/igep00x0.c |3 +++
>>>> board/isee/igep00x0/igep00x0.h |3 +++
>>>> boards.cfg |1 +
>>>> 4 files changed, 8 insertions(+)
>>>>
>>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>>> index d3ed390..1aed6d9 100644
>>>> --- a/MAINTAINERS
>>>> +++ b/MAINTAINERS
>>>> @@ -607,6 +607,7 @@ Enric Balletbo i Serra
>>>>
>>>> igep0020ARM ARMV7 (OMAP3xx SoC)
>>>> igep0030ARM ARMV7 (OMAP3xx SoC)
>>>> + igep0032ARM ARMV7 (OMAP3xx SoC)
>>>>
>>>> Eric Benard
>>>>
>>>> diff --git a/board/isee/igep00x0/igep00x0.c
>>>> b/board/isee/igep00x0/igep00x0.c
>>>> index 49fcf34..93aea8b 100644
>>>> --- a/board/isee/igep00x0/igep00x0.c
>>>> +++ b/board/isee/igep00x0/igep00x0.c
>>>> @@ -68,8 +68,11 @@ void show_boot_progress(int val)
>>>> return;
>>>> }
>>>>
>>>> +/* Skip in the case of IGEP0032 machine */
>>>> +#if !(CONFIG_MACH_TYPE == MACH_TYPE_IGEP0032)
>>>> if (!gpio_request(IGEP00X0_GPIO_LED, ""))
>>>> gpio_direction_output(IGEP00X0_GPIO_LED, 1);
>>>> +#endif
>>>> }
>>>> #endif
>>>>
>>>
>>> So, this board doesn't have a GPIO LED to show it boot status?
>>>
>>
>> Yes, it has but not connected to one OMAP GPIO. There is a led to
>> indicate power and two leds connected to TWL. Maybe I could use one of
>> them but meanwhile I decided don't use these leds.
>>
>
> Agree
>
>>> If that's the case I think there is no point to call show_boot_progress().
>>> Since this function is only compiled when CONFIG_SHOW_BOOT_PROGRESS
>>> is defined. I think that a better approach is to just define it for the
>>> machines that have a boot progress GPIO LED. e.g:
>>>
>>> diff --git a/include/configs/igep00x0.h b/include/configs/igep00x0.h
>>> index 88eadb4..98eed0f 100644
>>> --- a/include/configs/igep00x0.h
>>> +++ b/include/configs/igep00x0.h
>>> @@ -85,8 +85,11 @@
>>> #define CONFIG_OMAP_HSMMC 1
>>> #define CONFIG_DOS_PARTITION 1
>>>
>>> +#if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0020) || \
>>> +(CONFIG_MACH_TYPE == MACH_TYPE_IGEP0030)
>>> /* define to enable boot progress via leds */
>>> #define CONFIG_SHOW_BOOT_PROGRESS
>>> +#endif
>>>
>>
>> The problem is: if I disable the call to show_boot_progress in
>> igep00x0.h I'll get a compilation error in this function because
>> IGEP00X0_GPIO_LED is undeclared, so necessarily I need to protect the
>> call in igep00x0.c against this undefined reference. For that reason I
>> used the ifdef inside the show_boot_progress implementation.
>>
>
> I'm confused now, why would that happen?
>
> IGEP00X0_GPIO_LED is only used in show_boot_progress and this function
> his shielded by:
>
> #if defined(CONFIG_SHOW_BOOT_PROGRESS) && !defined(CONFIG_SPL_BUILD)
> void show_boot_progress(int val)
> {
>if (val < 0) {
>/* something went wrong */
>return;
>}
>
>if (!gpio_request(IGEP00X0_GPIO_LED, ""))
>gpio_direction_output(IGEP00X0_GPIO_LED, 1);
> }
> #endif
>
> Which means that this function is only build when
> CONFIG_SHOW_BOOT_PROGRESS is defined.
>
> So, I don't see why not defining CONFIG_SHOW_BOOT_PROGRESS for
> MACH_TYPE_IGEP0032
> could lead to that build error (after all IGEP00X0_GPIO_LED is not
> been used in any other place)
>
Mmmm, right you have reason, let me dive into ... :-) Maybe I did
something wrong...
>>
Re: [U-Boot] [PATCH 2/2] SPL: ONENAND: Support SPL to boot u-boot from OneNAND.
Hi,
2013/2/5 Enric Balletbo Serra :
> Hi Kyungmin,
>
> Thanks for revisit the patch.
>
> 2013/2/5 Kyungmin Park :
>> Hi,
>>
>> On Tue, Feb 5, 2013 at 6:23 PM, Enric Balletbo i Serra
>> wrote:
>>> From: Enric Balletbo i Serra
>>>
>>> This patch will allow use SPL to boot an u-boot from the OneNAND.
>>>
>>> Tested with IGEPv2 board with a OneNAND from Numonyx.
>>>
>>> Signed-off-by: Enric Balletbo i Serra
>>> ---
>>> arch/arm/cpu/armv7/omap3/board.c |2 +-
>> It's not related with OneNAND SPL patch, can you split it two patches?
>
> Ok, I'll do in v2.
>
>>> common/spl/Makefile |1 +
>>> common/spl/spl.c |5 +
>>> common/spl/spl_onenand.c | 45
>>> ++
>>> 4 files changed, 52 insertions(+), 1 deletion(-)
>>> create mode 100644 common/spl/spl_onenand.c
>>>
>>> diff --git a/arch/arm/cpu/armv7/omap3/board.c
>>> b/arch/arm/cpu/armv7/omap3/board.c
>>> index 89c587e..63063c8 100644
>>> --- a/arch/arm/cpu/armv7/omap3/board.c
>>> +++ b/arch/arm/cpu/armv7/omap3/board.c
>>> @@ -110,7 +110,7 @@ int board_mmc_init(bd_t *bis)
>>>
>>> void spl_board_init(void)
>>> {
>>> -#ifdef CONFIG_SPL_NAND_SUPPORT
>>> +#if defined(CONFIG_SPL_NAND_SUPPORT) || defined(CONFIG_SPL_ONENAND_SUPPORT)
>>> gpmc_init();
>>> #endif
>>> #ifdef CONFIG_SPL_I2C_SUPPORT
>>> diff --git a/common/spl/Makefile b/common/spl/Makefile
>>> index 5698a23..da2afc1 100644
>>> --- a/common/spl/Makefile
>>> +++ b/common/spl/Makefile
>>> @@ -18,6 +18,7 @@ COBJS-$(CONFIG_SPL_FRAMEWORK) += spl.o
>>> COBJS-$(CONFIG_SPL_NOR_SUPPORT) += spl_nor.o
>>> COBJS-$(CONFIG_SPL_YMODEM_SUPPORT) += spl_ymodem.o
>>> COBJS-$(CONFIG_SPL_NAND_SUPPORT) += spl_nand.o
>>> +COBJS-$(CONFIG_SPL_ONENAND_SUPPORT) += spl_onenand.o
>>> COBJS-$(CONFIG_SPL_NET_SUPPORT) += spl_net.o
>>> endif
>>>
>>> diff --git a/common/spl/spl.c b/common/spl/spl.c
>>> index ff9ba7b..c584247 100644
>>> --- a/common/spl/spl.c
>>> +++ b/common/spl/spl.c
>>> @@ -197,6 +197,11 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
>>> spl_nand_load_image();
>>> break;
>>> #endif
>>> +#ifdef CONFIG_SPL_ONENAND_SUPPORT
>>> + case BOOT_DEVICE_ONE_NAND:
>> ONE_NAND? It should be ONENAND.
>
> Well, I used ONE_NAND because this define was already defined in
>
> arch/arm/include/asm/arch-omap3/spl.h:29:#define BOOT_DEVICE_ONE_NAND 3
> arch/arm/include/asm/arch-omap5/spl.h:30:#define BOOT_DEVICE_ONE_NAND4
> arch/arm/include/asm/arch-omap4/spl.h:30:#define BOOT_DEVICE_ONE_NAND 4
> arch/arm/include/asm/arch-mx35/spl.h:30:#define BOOT_DEVICE_ONE_NAND4
>
> For me, also looks better use ONENAND, but then, I need to change all
> these defines. What do you prefer ? Maintain the use of ONE_NAND or
> change these defines ?
>
Before sending version 2. Any comment on this ? I can use
BOOT_DEVICE_ONE_NAND or I should change for BOOT_DEVICE_ONENAND ?
>>> + spl_onenand_load_image();
>>> + break;
>>> +#endif
>>> #ifdef CONFIG_SPL_NOR_SUPPORT
>>> case BOOT_DEVICE_NOR:
>>> spl_nor_load_image();
>>> diff --git a/common/spl/spl_onenand.c b/common/spl/spl_onenand.c
>>> new file mode 100644
>>> index 000..247f97b
>>> --- /dev/null
>>> +++ b/common/spl/spl_onenand.c
>>> @@ -0,0 +1,45 @@
>>> +/*
>>> + * Copyright (C) 2011
>>> + * Corscience GmbH & Co. KG - Simon Schwarz
>>> + *
>>> + * See file CREDITS for list of people who contributed to this
>>> + * project.
>>> + *
>>> + * This program is free software; you can redistribute it and/or
>>> + * modify it under the terms of the GNU General Public License as
>>> + * published by the Free Software Foundation; either version 2 of
>>> + * the License, or (at your option) any later version.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>> + * GNU General Public License for more details.
>>> + *
>>> + * You should have received a copy of the GNU General Public License
>>>
Re: [U-Boot] [PATCH] OMAP3: igep0020: Add pad config for WIFI/BT GPIOs
Hi, 2012/10/28 Anders Hedlund : > This adds support for WIFI/BT GPIOs which were previously missing. > > Signed-off-by: Anders Hedlund > Cc: Enric Balletbo i Serra > Cc: Jonas Zetterberg > --- > board/isee/igep0020/igep0020.h |6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/board/isee/igep0020/igep0020.h b/board/isee/igep0020/igep0020.h > index 3335ecc..283b75e 100644 > --- a/board/isee/igep0020/igep0020.h > +++ b/board/isee/igep0020/igep0020.h > @@ -132,6 +132,12 @@ static void setup_net_chip(void); > MUX_VAL(CP(MMC1_DAT1), (IEN | PTU | EN | M0)) /* MMC1_DAT1 */\ > MUX_VAL(CP(MMC1_DAT2), (IEN | PTU | EN | M0)) /* MMC1_DAT2 */\ > MUX_VAL(CP(MMC1_DAT3), (IEN | PTU | EN | M0)) /* MMC1_DAT3 */\ > + MUX_VAL(CP(CAM_HS), (IDIS | PTU | DIS | M4)) /* GPIO_94 */\ > + MUX_VAL(CP(CAM_VS), (IDIS | PTU | DIS | M4)) /* GPIO_95 */\ > + MUX_VAL(CP(MMC2_DAT4), (IDIS | PTU | DIS | M4)) /* GPIO_136 */\ > + MUX_VAL(CP(MMC2_DAT5), (IDIS | PTU | DIS | M4)) /* GPIO_137 */\ > + MUX_VAL(CP(MMC2_DAT6), (IDIS | PTU | DIS | M4)) /* GPIO_138 */\ > + MUX_VAL(CP(MMC2_DAT7), (IDIS | PTU | DIS | M4)) /* GPIO_139 */\ > MUX_VAL(CP(UART3_TX_IRTX), (IDIS | PTD | DIS | M0)) /* UART3_TX */\ > MUX_VAL(CP(UART3_RX_IRRX), (IEN | PTD | DIS | M0)) /* UART3_RX */\ > MUX_VAL(CP(I2C1_SCL), (IEN | PTU | EN | M0)) /* I2C1_SCL */\ > -- > 1.7.10.4 > Thanks for the patch but u-boot should only mux the pins they use, as u-boot does not use wifi this is not applicable here. Did you have problems with wifi ? Then we should check if these pins are muxe'd at kernel level, I think so. Cheers, Enric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3: igep0020: Add pad config for WIFI/BT GPIOs
2012/10/29 Anders Hedlund : > 2012/10/29 Enric Balletbo Serra : >> Hi, >> >> 2012/10/28 Anders Hedlund : >>> This adds support for WIFI/BT GPIOs which were previously missing. >>> >>> Signed-off-by: Anders Hedlund >>> Cc: Enric Balletbo i Serra >>> Cc: Jonas Zetterberg >>> --- >>> board/isee/igep0020/igep0020.h |6 ++ >>> 1 file changed, 6 insertions(+) >>> >>> diff --git a/board/isee/igep0020/igep0020.h b/board/isee/igep0020/igep0020.h >>> index 3335ecc..283b75e 100644 >>> --- a/board/isee/igep0020/igep0020.h >>> +++ b/board/isee/igep0020/igep0020.h >>> @@ -132,6 +132,12 @@ static void setup_net_chip(void); >>> MUX_VAL(CP(MMC1_DAT1), (IEN | PTU | EN | M0)) /* MMC1_DAT1 >>> */\ >>> MUX_VAL(CP(MMC1_DAT2), (IEN | PTU | EN | M0)) /* MMC1_DAT2 >>> */\ >>> MUX_VAL(CP(MMC1_DAT3), (IEN | PTU | EN | M0)) /* MMC1_DAT3 >>> */\ >>> + MUX_VAL(CP(CAM_HS), (IDIS | PTU | DIS | M4)) /* GPIO_94 */\ >>> + MUX_VAL(CP(CAM_VS), (IDIS | PTU | DIS | M4)) /* GPIO_95 */\ >>> + MUX_VAL(CP(MMC2_DAT4), (IDIS | PTU | DIS | M4)) /* GPIO_136 */\ >>> + MUX_VAL(CP(MMC2_DAT5), (IDIS | PTU | DIS | M4)) /* GPIO_137 */\ >>> + MUX_VAL(CP(MMC2_DAT6), (IDIS | PTU | DIS | M4)) /* GPIO_138 */\ >>> + MUX_VAL(CP(MMC2_DAT7), (IDIS | PTU | DIS | M4)) /* GPIO_139 */\ >>> MUX_VAL(CP(UART3_TX_IRTX), (IDIS | PTD | DIS | M0)) /* UART3_TX */\ >>> MUX_VAL(CP(UART3_RX_IRRX), (IEN | PTD | DIS | M0)) /* UART3_RX */\ >>> MUX_VAL(CP(I2C1_SCL), (IEN | PTU | EN | M0)) /* I2C1_SCL */\ >>> -- >>> 1.7.10.4 >>> >> >> Thanks for the patch but u-boot should only mux the pins they use, as >> u-boot does not use wifi this is not applicable here. >> >> Did you have problems with wifi ? Then we should check if these pins >> are muxe'd at kernel level, I think so. > > Yes. In linux kernel v3.6 WIFI/BT does not work due to this issue. I > also have a fix for this but in my oppinion this kind of HW > configuration should be made in the boot loader. This was discussed before in this ML, and the result of the discussion was that bootloaders should set only the minimum required for the uboot functionality and kernel boot. So the way to fix this problem is muxing these pins in kernel. Cheers, Enric > > Br, > Anders > >> >> Cheers, >>Enric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Possible OMAP3 regression with current mainline
I just tried boot with my OMAP3 based board (IGEPv2) and I found that is broken in current mainline and v2015.01. The boot process stops at reading u-boot.img Did someone, with another OMAP3 board, have the same problem? I bisected the problem and looks that was introduced in following commit. commit b3f4ca1135edd66d14254089bbeb8077c6d0bb72 dm: omap3: Move to driver model for GPIO and serial Reverting the patch boots again. Any clue? Thanks in advance Enric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Possible OMAP3 regression with current mainline
Hi Simon, 2015-01-30 2:24 GMT+01:00 Simon Glass : > Hi Enric, > > On 26 January 2015 at 10:55, Enric Balletbo Serra wrote: >> I just tried boot with my OMAP3 based board (IGEPv2) and I found that >> is broken in current mainline and v2015.01. The boot process stops at >> >> reading u-boot.img >> >> Did someone, with another OMAP3 board, have the same problem? >> >> I bisected the problem and looks that was introduced in following commit. >> >> commit b3f4ca1135edd66d14254089bbeb8077c6d0bb72 >> dm: omap3: Move to driver model for GPIO and serial >> >> Reverting the patch boots again. Any clue? > > It looks like someone else had this problem: > > http://patchwork.ozlabs.org/patch/433866/ > This patch is made by me, I sent this patch :) But the patch only replaces the use of show_boot_progress for the STATUS_LED API, Which is better for that purpose. But the root problem is not solved. Looks like the problem is the gpio_request call inside the function show_boot_progress. If I'm not wrong the gpio_request implementation is different when device model is used, and for some reason doing a gpio_request inside the show_boot_progress function hangs. If I remove the gpio_request from show_boot_progress it boots as expected. What's the difference between gpio_request implementation when using DM or not? Maybe it's a malloc problem? Regards, Enric > Regards, > Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] igep00x0: Do not include config_distro_defaults.h directly
Hi Ladislav, Thanks for the patch, some comments below 2015-12-30 2:50 GMT+01:00 Ladislav Michl : > File is already included: > omap3_igep00x0.h -> ti_omap3_common.h -> ti_armv7_omap.h -> > ti_armv7_common.h -> config_distro_defaults.h > > Signed-off-by: Ladislav Michl > --- > include/configs/omap3_igep00x0.h | 10 +++--- > 1 file changed, 3 insertions(+), 7 deletions(-) > > diff --git a/include/configs/omap3_igep00x0.h > b/include/configs/omap3_igep00x0.h > index cf2bc3e..a64b38f 100644 > --- a/include/configs/omap3_igep00x0.h > +++ b/include/configs/omap3_igep00x0.h > @@ -43,7 +43,7 @@ > #else > #error "status LED not defined for this machine." > #endif > -#define RED_LED_DEV0 > +#define RED_LED_DEV0 any reason for this change ? > #define STATUS_LED_BIT RED_LED_GPIO > #define STATUS_LED_STATE STATUS_LED_ON > #define STATUS_LED_PERIOD (CONFIG_SYS_HZ / 2) > @@ -56,7 +56,7 @@ > #define CONFIG_OMAP3_GPIO_6/* GPIO160..191 is in GPIO bank 6 */ > > /* USB */ > -#define CONFIG_USB_MUSB_UDC1 > +#define CONFIG_USB_MUSB_UDC1 and this ? > #define CONFIG_USB_OMAP3 1 > #define CONFIG_TWL4030_USB 1 > > @@ -81,12 +81,8 @@ > #define CONFIG_CMD_DHCP > #define CONFIG_CMD_PING > > -/*#undef CONFIG_ENV_IS_NOWHERE*/ > - and this ? > #ifndef CONFIG_SPL_BUILD > > -#include > - > /* Environment */ > #define ENV_DEVICE_SETTINGS \ > "stdin=serial\0" \ > @@ -138,7 +134,7 @@ > #if defined(CONFIG_CMD_NET) > #define CONFIG_SMC911X > #define CONFIG_SMC911X_32_BIT > -#define CONFIG_SMC911X_BASE0x2C00 > +#define CONFIG_SMC911X_BASE0x2C00 again, any reason for this change? > #endif /* (CONFIG_CMD_NET) */ > > /* OneNAND boot config */ > -- > 2.1.4 > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot Also, can you send this patch and the other patch (igep00x0: cleanup ethernet support) as numbered patch series? Thanks, Enric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] armv7: Add missing newline after OMAP die ID
2016-01-03 18:24 GMT+01:00 Ladislav Michl :
> Signed-off-by: Ladislav Michl
> ---
> arch/arm/cpu/armv7/omap-common/utils.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/cpu/armv7/omap-common/utils.c
> b/arch/arm/cpu/armv7/omap-common/utils.c
> index 602d993..52ea734 100644
> --- a/arch/arm/cpu/armv7/omap-common/utils.c
> +++ b/arch/arm/cpu/armv7/omap-common/utils.c
> @@ -108,6 +108,6 @@ void omap_die_id_display(void)
>
> omap_die_id(die_id);
>
> - printf("OMAP die ID: %08x%08x%08x%08x", die_id[0], die_id[1],
> die_id[2],
> - die_id[3]);
> + printf("OMAP die ID: %08x%08x%08x%08x\n", die_id[0], die_id[1],
> + die_id[2], die_id[3]);
> }
> --
> 2.1.4
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
I personally find this a bit annoying too, so you have my ack
Acked-by: Enric Balletbo Serra
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv7 6/7] igep00x0: UBIize
Hi Ladis, Many thanks for your work on this, see some comments below ... 2016-01-21 7:07 GMT+01:00 Heiko Schocher : > Hello Ladislav, > > Am 17.01.2016 um 04:16 schrieb Ladislav Michl: >> >> Convert IGEP board to use UBI volumes for U-Boot, its environment and >> kernel. With exception of first four sectors read by SoC boot >> ROM whole NAND is UBI managed. As code is too big now, drop >> CONFIG_SPL_EXT_SUPPORT to make it fit. >> >> Signed-off-by: Ladislav Michl >> --- >> include/configs/omap3_igep00x0.h | 80 >> ++-- >> 1 file changed, 45 insertions(+), 35 deletions(-) > > > Reviewed-by: Heiko Schocher > > bye, > Heiko > >> >> diff --git a/include/configs/omap3_igep00x0.h >> b/include/configs/omap3_igep00x0.h >> index 5da6cfd..9afbcbe 100644 >> --- a/include/configs/omap3_igep00x0.h >> +++ b/include/configs/omap3_igep00x0.h >> @@ -74,6 +74,8 @@ >> #define CONFIG_CMD_CACHE >> #ifdef CONFIG_BOOT_ONENAND >> #define CONFIG_CMD_ONENAND/* ONENAND support */ >> +#else >> +#define CONFIG_CMD_UBI >> #endif >> #define CONFIG_CMD_DHCP >> #define CONFIG_CMD_PING >> @@ -86,6 +88,10 @@ >> "stdout=serial\0" \ >> "stderr=serial\0" >> >> +#define ENV_MTD_SETTINGS \ >> + "mtdids=nand0=gpmc-nand.0\0" \ >> + "mtdparts=mtdparts=gpmc-nand.0:512k(SPL),-(UBI)\0" >> + I think this should be protected by CONFIG_BOOT_NAND, if is defined CONFIG_BOOT_ONENAND the ENV_MTD_SETTINGS are wrong. Also, as we're changing the memory map, I'd like to change the reserved space for SPL to 2M instead of 512k, so we cover all NAND block sizes from (64KB to 512KB) >> #define MEM_LAYOUT_SETTINGS \ >> DEFAULT_LINUX_BOOT_ENV \ >> "scriptaddr=0x87E0\0" \ >> @@ -96,36 +102,15 @@ >> >> #include >> >> - >> #define CONFIG_EXTRA_ENV_SETTINGS \ >> ENV_DEVICE_SETTINGS \ >> + ENV_MTD_SETTINGS \ >> MEM_LAYOUT_SETTINGS \ >> BOOTENV >> >> #endif >> >> /* >> - * FLASH and environment organization >> - */ >> - >> -#ifdef CONFIG_BOOT_ONENAND >> -#define CONFIG_SYS_ONENAND_BASEONENAND_MAP >> - >> -#define ONENAND_ENV_OFFSET 0x26 /* environment starts >> here */ >> - >> -#define CONFIG_ENV_IS_IN_ONENAND 1 >> -#define CONFIG_ENV_SIZE(512 << 10) /* Total Size >> Environment */ >> -#define CONFIG_ENV_ADDRONENAND_ENV_OFFSET >> -#endif >> - >> -#ifdef CONFIG_NAND >> -#define CONFIG_ENV_OFFSET 0x26 /* environment starts >> here */ >> -#define CONFIG_ENV_IS_IN_NAND 1 >> -#define CONFIG_ENV_SIZE(512 << 10) /* Total Size >> Environment */ >> -#define CONFIG_ENV_ADDRNAND_ENV_OFFSET >> -#endif >> - >> -/* >>* SMSC911x Ethernet >>*/ >> #if defined(CONFIG_CMD_NET) >> @@ -134,19 +119,50 @@ >> #define CONFIG_SMC911X_BASE 0x2C00 >> #endif /* (CONFIG_CMD_NET) */ >> >> +/* >> + * FLASH and environment organization >> + */ >> +#ifdef CONFIG_NAND >> +#define CONFIG_SPL_UBI 1 >> +#define CONFIG_SPL_UBI_MAX_VOL_LEBS256 >> +#define CONFIG_SPL_UBI_MAX_PEB_SIZE(256*1024) >> +#define CONFIG_SPL_UBI_MAX_PEBS4096 >> +#define CONFIG_SPL_UBI_VOL_IDS 8 >> +#define CONFIG_SPL_UBI_LOAD_MONITOR_ID 0 >> +#define CONFIG_SPL_UBI_LOAD_KERNEL_ID 3 >> +#define CONFIG_SPL_UBI_LOAD_ARGS_ID4 >> +#define CONFIG_SPL_UBI_PEB_OFFSET 4 >> +#define CONFIG_SPL_UBI_VID_OFFSET 512 >> +#define CONFIG_SPL_UBI_LEB_START 2048 >> +#define CONFIG_SPL_UBI_INFO_ADDR 0x8808 >> + >> +#define CONFIG_ENV_IS_IN_UBI 1 >> +#define CONFIG_ENV_UBI_PART"UBI" >> +#define CONFIG_ENV_UBI_VOLUME "config" >> +#define CONFIG_ENV_UBI_VOLUME_REDUND "config_r" >> +#define CONFIG_UBI_SILENCE_MSG 1 >> +#define CONFIG_UBIFS_SILENCE_MSG 1 >> +#else >> +#define CONFIG_ENV_IS_NOWHERE >> +#endif >> +#define CONFIG_ENV_SIZE(32*1024) >> + >> +#define CONFIG_RBTREE >> +#define CONFIG_MTD_PARTITIONS >> +#define MTDIDS_DEFAULT "nand0=gpmc-nand.0" >> +#define MTDPARTS_DEFAULT >> "mtdparts=gpmc-nand.0:512k(SPL),-(UBI)" >> + Same comment as above. >> /* OneNAND boot config */ >> #ifdef CONFIG_BOOT_ONENAND >> #define CONFIG_SPL_ONENAND_SUPPORT >> -#define CONFIG_SYS_ONENAND_U_BOOT_OFFS 0x8 >> #define CONFIG_SYS_ONENAND_PAGE_SIZE 2048 >> -#define CONFIG_SPL_ONENAND_LOAD_ADDR0x8 >> -#define CONFIG_SPL_ONENAND_LOAD_SIZE\ >> - (512 * 1024 - CONFIG_SPL_ONENAND_LOAD_ADDR) >> - >> +#define CONFIG_SYS_ONENAND_BASEONENAND_MAP >> +#define CONFIG_SYS_ONENAND_U_BOOT_OFFS 0x8 >> #endif >> >> /* NAND boot config */ >> #ifdef CONFIG_NAND >> +#define CONFIG_SPL_NAND_SUPPORT >> #define CONFIG_SYS_NAND_BUSWIDTH_16BIT >> #define CONFIG_SYS_NAND_5_ADDR_CYCLE >> #define CONFIG_SYS_NAND_PAGE_COUNT64 >> @@
Re: [U-Boot] [PATCHv4 7/7] igep00x0: Falcon mode
2016-01-21 7:08 GMT+01:00 Heiko Schocher :
> Hello Ladislav,
>
> Am 17.01.2016 um 04:16 schrieb Ladislav Michl:
>>
>> Implement spl_start_uboot to let Falcon mode work.
>>
>> Signed-off-by: Ladislav Michl
>> ---
>> board/isee/igep00x0/igep00x0.c | 12
>> 1 file changed, 12 insertions(+)
>
>
> Reviewed-by: Heiko Schocher
>
> bye,
> Heiko
>
>>
>> diff --git a/board/isee/igep00x0/igep00x0.c
>> b/board/isee/igep00x0/igep00x0.c
>> index e2fce50..92811d8 100644
>> --- a/board/isee/igep00x0/igep00x0.c
>> +++ b/board/isee/igep00x0/igep00x0.c
>> @@ -10,6 +10,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -212,3 +213,14 @@ int board_eth_init(bd_t *bis)
>> #endif
>> }
>> #endif
>> +
>> +#ifdef CONFIG_SPL_OS_BOOT
>> +int spl_start_uboot(void)
>> +{
>> + /* break into full u-boot on 'c' */
>> + if (serial_tstc() && serial_getc() == 'c')
>> + return 1;
>> +
>> + return 0;
>> +}
>> +#endif
>>
>
> --
> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> 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
Acked-by: Enric Balletbo i Serra
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] igep00x0: remove #undef CONFIG_BOOTDELAY
2016-01-21 11:35 GMT+01:00 Ladislav Michl : > Do not undefine CONFIG_BOOTDELAY, so board can boot without user > intervention. > > Signed-off-by: Ladislav Michl > --- > include/configs/omap3_igep00x0.h | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/include/configs/omap3_igep00x0.h > b/include/configs/omap3_igep00x0.h > index 5da6cfd..5e33845 100644 > --- a/include/configs/omap3_igep00x0.h > +++ b/include/configs/omap3_igep00x0.h > @@ -19,8 +19,6 @@ > #include > #include > > -#undef CONFIG_BOOTDELAY > - > /* > * Display CPU and Board information > */ > -- > 2.1.4 > Acked-by: Enric Balletbo i Serra ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv7 6/7] igep00x0: UBIize
Hi, 2016-01-25 7:39 GMT+01:00 Heiko Schocher : > Hello Enric, Ladislav, > > Am 22.01.2016 um 23:35 schrieb Enric Balletbo Serra: >> >> Hi Ladis, >> >> Many thanks for your work on this, see some comments below ... > > > Sorry, pull request is sent with this patch, see: > > http://lists.denx.de/pipermail/u-boot/2016-January/239855.html > > @Ladislav: Please send changes in a follow up patch, thanks! > > > >> 2016-01-21 7:07 GMT+01:00 Heiko Schocher : >>> >>> Hello Ladislav, >>> >>> Am 17.01.2016 um 04:16 schrieb Ladislav Michl: >>>> >>>> >>>> Convert IGEP board to use UBI volumes for U-Boot, its environment and >>>> kernel. With exception of first four sectors read by SoC boot >>>> ROM whole NAND is UBI managed. As code is too big now, drop >>>> CONFIG_SPL_EXT_SUPPORT to make it fit. >>>> >>>> Signed-off-by: Ladislav Michl >>>> --- >>>>include/configs/omap3_igep00x0.h | 80 >>>> ++-- >>>>1 file changed, 45 insertions(+), 35 deletions(-) >>> >>> >>> >>> Reviewed-by: Heiko Schocher >>> >>> bye, >>> Heiko >>> >>>> >>>> diff --git a/include/configs/omap3_igep00x0.h >>>> b/include/configs/omap3_igep00x0.h >>>> index 5da6cfd..9afbcbe 100644 >>>> --- a/include/configs/omap3_igep00x0.h >>>> +++ b/include/configs/omap3_igep00x0.h >>>> @@ -74,6 +74,8 @@ >>>>#define CONFIG_CMD_CACHE >>>>#ifdef CONFIG_BOOT_ONENAND >>>>#define CONFIG_CMD_ONENAND/* ONENAND support */ >>>> +#else >>>> +#define CONFIG_CMD_UBI >>>>#endif >>>>#define CONFIG_CMD_DHCP >>>>#define CONFIG_CMD_PING >>>> @@ -86,6 +88,10 @@ >>>> "stdout=serial\0" \ >>>> "stderr=serial\0" >>>> >>>> +#define ENV_MTD_SETTINGS \ >>>> + "mtdids=nand0=gpmc-nand.0\0" \ >>>> + "mtdparts=mtdparts=gpmc-nand.0:512k(SPL),-(UBI)\0" >>>> + >> >> >> I think this should be protected by CONFIG_BOOT_NAND, if is defined >> CONFIG_BOOT_ONENAND the ENV_MTD_SETTINGS are wrong. > > > Good point ... > >> Also, as we're changing the memory map, I'd like to change the >> reserved space for SPL to 2M instead of 512k, so we cover all NAND >> block sizes from (64KB to 512KB) > > > I do not understand this, but I have no details about the hw ... > The ROM boot on OMAP reads the first 4 blocks searching for the SPL, in production is a practice flash the SPL 4 times. OneNAND/NAND devices can have different block sizes and the OMAP ROM boot supports block sizes from 64KB to 512K. For IGEP boards in particular, at least there are boards that have block size of 128K and 256K. What I would meant here is set as default the mtdparts variable to reserve 2M for SPL, just to cover all the cases. mtdparts=mtdparts=gpmc-nand.0:2m(SPL),-(UBI)\0 > >>>>#define MEM_LAYOUT_SETTINGS \ >>>> DEFAULT_LINUX_BOOT_ENV \ >>>> "scriptaddr=0x87E0\0" \ >>>> @@ -96,36 +102,15 @@ >>>> >>>>#include >>>> >>>> - >>>>#define CONFIG_EXTRA_ENV_SETTINGS \ >>>> ENV_DEVICE_SETTINGS \ >>>> + ENV_MTD_SETTINGS \ >>>> MEM_LAYOUT_SETTINGS \ >>>> BOOTENV >>>> >>>>#endif >>>> >>>>/* >>>> - * FLASH and environment organization >>>> - */ >>>> - >>>> -#ifdef CONFIG_BOOT_ONENAND >>>> -#define CONFIG_SYS_ONENAND_BASEONENAND_MAP >>>> - >>>> -#define ONENAND_ENV_OFFSET 0x26 /* environment starts >>>> here */ >>>> - >>>> -#define CONFIG_ENV_IS_IN_ONENAND 1 >>>> -#define CONFIG_ENV_SIZE(512 << 10) /* Total >>>> Size >>>> Environment */ >>>> -#define CONFIG_ENV_ADDRONENAND_ENV_OFFSET >>>> -#endif >>>> - >>>> -#ifdef CONFIG_NAND >>>> -#define CONFIG_ENV_OFFSET 0x26 /* environment starts >>>> here */ >>>> -#define CONFIG_ENV_IS_IN_NAND 1 >>>> -#define CONFIG_ENV_SIZE
Re: [U-Boot] [PATCHv7 6/7] igep00x0: UBIize
Hi Ladis, 2016-01-25 16:56 GMT+01:00 Ladislav Michl : > Hi Enric, > > On Mon, Jan 25, 2016 at 08:26:23AM +0100, Enric Balletbo Serra wrote: >> The ROM boot on OMAP reads the first 4 blocks searching for the SPL, >> in production is a practice flash the SPL 4 times. OneNAND/NAND >> devices can have different block sizes and the OMAP ROM boot supports >> block sizes from 64KB to 512K. For IGEP boards in particular, at least >> there are boards that have block size of 128K and 256K. What I would >> meant here is set as default the mtdparts variable to reserve 2M for >> SPL, just to cover all the cases. >> >> mtdparts=mtdparts=gpmc-nand.0:2m(SPL),-(UBI)\0 > > So far there was no ack or nack to yesterday's proposal making that > dynamic; Both boot ROM and ubispl code thinks in terms of eraseblocks, > only mtd needs fixed offset. So I'd like to see this offset calculated as > 4*block_size, not some "worst case" value... > > ladis Your proposal looks good to me. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] igep00x0: move SPL routines into separate file
2017-08-19 0:02 GMT+02:00 Pau Pajuelo :
> Tested-by: Pau Pajuelo
>
> 2017-08-17 3:06 GMT+02:00 Ladislav Michl :
>> Avoid cluttering board file with CONFIG_SPL_BUILD ifdefs
>> by moving SPL related functions into separate file.
>>
>> Signed-off-by: Ladislav Michl
>> ---
>> board/isee/igep00x0/Makefile | 6 +-
>> board/isee/igep00x0/common.c | 80 ++
>> board/isee/igep00x0/igep00x0.c | 128
>> -
>> board/isee/igep00x0/spl.c | 64 +
>> 4 files changed, 149 insertions(+), 129 deletions(-)
>>
>> diff --git a/board/isee/igep00x0/Makefile b/board/isee/igep00x0/Makefile
>> index 68b151c3c5..74594da771 100644
>> --- a/board/isee/igep00x0/Makefile
>> +++ b/board/isee/igep00x0/Makefile
>> @@ -5,4 +5,8 @@
>> # SPDX-License-Identifier: GPL-2.0+
>> #
>>
>> -obj-y := igep00x0.o
>> +ifdef CONFIG_SPL_BUILD
>> +obj-y := spl.o common.o
>> +else
>> +obj-y := igep00x0.o common.o
>> +endif
>> diff --git a/board/isee/igep00x0/common.c b/board/isee/igep00x0/common.c
>> new file mode 100644
>> index 00..b8f1c14f6a
>> --- /dev/null
>> +++ b/board/isee/igep00x0/common.c
>> @@ -0,0 +1,80 @@
>> +/*
>> + * SPDX-License-Identifier:GPL-2.0+
>> + */
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include "igep00x0.h"
>> +
>> +DECLARE_GLOBAL_DATA_PTR;
>> +
>> +/*
>> + * Routine: set_muxconf_regs
>> + * Description: Setting up the configuration Mux registers specific to the
>> + * hardware. Many pins need to be moved from protect to primary
>> + * mode.
>> + */
>> +void set_muxconf_regs(void)
>> +{
>> + MUX_DEFAULT();
>> +
>> +#if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0020)
>> + MUX_IGEP0020();
>> +#endif
>> +
>> +#if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0030)
>> + MUX_IGEP0030();
>> +#endif
>> +}
>> +
>> +/*
>> + * Routine: board_init
>> + * Description: Early hardware init.
>> + */
>> +int board_init(void)
>> +{
>> + int loops = 100;
>> +
>> + /* find out flash memory type, assume NAND first */
>> + gpmc_cs0_flash = MTD_DEV_TYPE_NAND;
>> + gpmc_init();
>> +
>> + /* Issue a RESET and then READID */
>> + writeb(NAND_CMD_RESET, &gpmc_cfg->cs[0].nand_cmd);
>> + writeb(NAND_CMD_STATUS, &gpmc_cfg->cs[0].nand_cmd);
>> + while ((readl(&gpmc_cfg->cs[0].nand_dat) & NAND_STATUS_READY)
>> + != NAND_STATUS_READY) {
>> + udelay(1);
>> + if (--loops == 0) {
>> + gpmc_cs0_flash = MTD_DEV_TYPE_ONENAND;
>> + gpmc_init();/* reinitialize for OneNAND */
>> + break;
>> + }
>> + }
>> +
>> + /* boot param addr */
>> + gd->bd->bi_boot_params = (OMAP34XX_SDRC_CS0 + 0x100);
>> +
>> +#if defined(CONFIG_LED_STATUS) && defined(CONFIG_LED_STATUS_BOOT_ENABLE)
>> + status_led_set(CONFIG_LED_STATUS_BOOT, CONFIG_LED_STATUS_ON);
>> +#endif
>> +
>> + return 0;
>> +}
>> +
>> +#if defined(CONFIG_MMC)
>> +int board_mmc_init(bd_t *bis)
>> +{
>> + return omap_mmc_init(0, 0, 0, -1, -1);
>> +}
>> +
>> +void board_mmc_power_init(void)
>> +{
>> + twl4030_power_mmc_init(0);
>> +}
>> +#endif
>> diff --git a/board/isee/igep00x0/igep00x0.c b/board/isee/igep00x0/igep00x0.c
>> index a7a75601dd..74f9bab093 100644
>> --- a/board/isee/igep00x0/igep00x0.c
>> +++ b/board/isee/igep00x0/igep00x0.c
>> @@ -20,15 +20,12 @@
>> #include
>> #include
>> #include
>> -#include
>> #include
>> #include
>> #include
>> #include
>> #include "igep00x0.h"
>>
>> -DECLARE_GLOBAL_DATA_PTR;
>> -
>> static const struct ns16550_platdata igep_serial = {
>> .base = OMAP34XX_UART3,
>> .reg_shift = 2,
>> @@ -41,98 +38,6 @@ U_BOOT_DEVICE(igep_uart) = {
>> &igep_serial
>> };
>>
>> -/*
>> - * Routine: board_init
>> - * Description: Early hardware init.
>> - */
>> -int board_init(void)
>> -{
>> - int loops = 100;
>> -
>> - /* find out flash memory type, assume NAND first */
>> - gpmc_cs0_flash = MTD_DEV_TYPE_NAND;
>> - gpmc_init();
>> -
>> - /* Issue a RESET and then READID */
>> - writeb(NAND_CMD_RESET, &gpmc_cfg->cs[0].nand_cmd);
>> - writeb(NAND_CMD_STATUS, &gpmc_cfg->cs[0].nand_cmd);
>> - while ((readl(&gpmc_cfg->cs[0].nand_dat) & NAND_STATUS_READY)
>> - != NAND_STATUS_READY) {
>> - udelay(1);
>> - if (--loops == 0) {
>> - gpmc_cs0_flash = MTD_DEV_TYPE_ONENAND;
>> - gpmc_init();/* reinitialize for OneNAND */
>> - break;
>> - }
>> - }
>> -
>> - /* boot param addr */
>> - gd->bd->bi_boot_params = (OMAP34XX_SDRC_CS0 + 0x100);
>> -
>> -#if defined(CONFIG_LED_STATUS) && defined(CONFIG_LED_STATUS_BOO
Re: [U-Boot] [PATCH] Convert CONFIG_NAND_OMAP_GPMC et al to Kconfig
2017-08-26 15:37 GMT+02:00 Simon Glass : > On 11 August 2017 at 07:03, Adam Ford wrote: >> This converts the following to Kconfig: >>CONFIG_NAND_OMAP_GPMC >>CONFIG_NAND_OMAP_GPMC_PREFETCH >>CONFIG_NAND_OMAP_ELM >>CONFIG_SYS_NAND_BUSWIDTH_16BIT >>CONFIG_SPL_NAND_AM33XX_BCH >>CONFIG_SPL_NAND_SIMPLE >> >> Signed-off-by: Adam Ford >> --- >> README | 4 --- >> arch/arm/mach-omap2/Kconfig| 18 + >> configs/am335x_baltos_defconfig| 2 +- >> configs/am335x_evm_defconfig | 1 + >> configs/am335x_evm_nor_defconfig | 1 + >> configs/am335x_evm_usbspl_defconfig| 1 + >> configs/am335x_hs_evm_defconfig| 1 + >> configs/am3517_crane_defconfig | 1 + >> configs/am3517_evm_defconfig | 2 ++ >> configs/chiliboard_defconfig | 2 +- >> configs/devkit8000_defconfig | 1 + >> configs/eco5pk_defconfig | 2 ++ >> configs/igep0020_defconfig | 1 + >> configs/igep0030_defconfig | 1 + >> configs/igep0032_defconfig | 1 + Tested by: Enric Balletbo i Serra >> configs/ipam390_defconfig | 1 + >> configs/mcx_defconfig | 2 ++ >> configs/mt_ventoux_defconfig | 2 ++ >> configs/omap3_beagle_defconfig | 1 + >> configs/omap3_evm_defconfig| 1 + >> configs/omap3_ha_defconfig | 1 + >> configs/omap3_logic_defconfig | 1 + >> configs/omap3_overo_defconfig | 1 + >> configs/omap3_pandora_defconfig| 1 + >> configs/omap3_zoom1_defconfig | 1 + >> configs/omapl138_lcdk_defconfig| 1 + >> configs/tao3530_defconfig | 1 + >> configs/ti816x_evm_defconfig | 2 ++ >> configs/twister_defconfig | 2 ++ >> drivers/mtd/nand/Kconfig | 47 >> +- >> include/configs/am335x_evm.h | 6 - >> include/configs/am335x_igep003x.h | 1 - >> include/configs/am3517_crane.h | 3 --- >> include/configs/am3517_evm.h | 4 --- >> include/configs/am43xx_evm.h | 5 >> include/configs/apf27.h| 1 - >> include/configs/baltos.h | 3 --- >> include/configs/bav335x.h | 5 >> include/configs/brppt1.h | 3 --- >> include/configs/chiliboard.h | 6 - >> include/configs/cm_t35.h | 2 -- >> include/configs/cm_t3517.h | 1 - >> include/configs/cm_t43.h | 1 - >> include/configs/da850evm.h | 1 - >> include/configs/devkit3250.h | 1 - >> include/configs/devkit8000.h | 1 - >> include/configs/dra7xx_evm.h | 6 - >> include/configs/ipam390.h | 1 - >> include/configs/mcx.h | 4 --- >> include/configs/omap3_beagle.h | 2 -- >> include/configs/omap3_cairo.h | 1 - >> include/configs/omap3_evm.h| 3 --- >> include/configs/omap3_igep00x0.h | 2 -- >> include/configs/omap3_logic.h | 3 --- >> include/configs/omap3_overo.h | 1 - >> include/configs/omap3_pandora.h| 1 - >> include/configs/omap3_zoom1.h | 1 - >> include/configs/omapl138_lcdk.h| 2 -- >> include/configs/pengwyn.h | 2 -- >> include/configs/siemens-am33x-common.h | 3 --- >> include/configs/tam3517-common.h | 4 --- >> include/configs/tao3530.h | 3 --- >> include/configs/tegra-common.h | 1 - >> include/configs/ti816x_evm.h | 5 >> include/configs/ti_am335x_common.h | 4 --- >> include/configs/ti_armv7_omap.h| 1 - >> include/configs/ti_omap3_common.h | 1 - >> include/configs/ti_omap4_common.h | 4 --- >> include/configs/ti_omap5_common.h | 4 --- >> include/configs/tricorder.h| 2 -- >> scripts/config_whitelist.txt | 5 >> 71 files changed, 97 insertions(+), 117 deletions(-) >> > > Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] armv7: fix order of OMAP die ID printing
2016-06-02 11:43 GMT+02:00 Ladislav Michl :
> Signed-off-by: Ladislav Michl
> ---
> diff --git a/arch/arm/cpu/armv7/omap-common/utils.c
> b/arch/arm/cpu/armv7/omap-common/utils.c
> index 52ea734..2d03ebf 100644
> --- a/arch/arm/cpu/armv7/omap-common/utils.c
> +++ b/arch/arm/cpu/armv7/omap-common/utils.c
> @@ -108,6 +108,6 @@ void omap_die_id_display(void)
>
> omap_die_id(die_id);
>
> - printf("OMAP die ID: %08x%08x%08x%08x\n", die_id[0], die_id[1],
> - die_id[2], die_id[3]);
> + printf("OMAP die ID: %08x%08x%08x%08x\n", die_id[3], die_id[2],
> + die_id[1], die_id[0]);
> }
Acked-by: Enric Balletbo i Serra
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap3_igep00x0.h: Drop SPL MMC support on BOOT_NAND
Hi Tom, 2016-04-25 16:44 GMT+02:00 Tom Rini : > In the case of booting from NAND on these boards, remove MMC support > from SPL so that we can continue to fit into the safest partitioning of > the available SRAM. > > Reported-by: Heiko Schocher > Cc: Enric Balletbo i Serra > Signed-off-by: Tom Rini > --- > include/configs/omap3_igep00x0.h | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/include/configs/omap3_igep00x0.h > b/include/configs/omap3_igep00x0.h > index 5e33845..3cdee02 100644 > --- a/include/configs/omap3_igep00x0.h > +++ b/include/configs/omap3_igep00x0.h > @@ -20,6 +20,16 @@ > #include > > /* > + * Remove non-NAND boot modes. > + */ > +#ifdef CONFIG_BOOT_NAND > +#undef CONFIG_SPL_LIBDISK_SUPPORT > +#undef CONFIG_SPL_MMC_SUPPORT > +#undef CONFIG_SPL_FAT_SUPPORT > +#undef CONFIG_SPL_EXT_SUPPORT > +#endif > + Hmm, this will break boot from a sdcard, on IGEP the same SPL binary is used to boot from flash or sdcard. The reason why we have two defconfigs is to select if the board has a ONENAND (igep00xx_defconfig) or a NAND (igep00xx_nand_defconfig) but both must have support for MMC. > +/* > * Display CPU and Board information > */ > #define CONFIG_DISPLAY_CPUINFO 1 > -- > 1.9.1 > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap3_igep00x0.h: Drop SPL MMC support on BOOT_NAND
Hi Tom, 2016-04-25 17:16 GMT+02:00 Tom Rini : > On Mon, Apr 25, 2016 at 05:09:50PM +0200, Enric Balletbo Serra wrote: >> Hi Tom, >> >> 2016-04-25 16:44 GMT+02:00 Tom Rini : >> > In the case of booting from NAND on these boards, remove MMC support >> > from SPL so that we can continue to fit into the safest partitioning of >> > the available SRAM. >> > >> > Reported-by: Heiko Schocher >> > Cc: Enric Balletbo i Serra >> > Signed-off-by: Tom Rini >> > --- >> > include/configs/omap3_igep00x0.h | 10 ++ >> > 1 file changed, 10 insertions(+) >> > >> > diff --git a/include/configs/omap3_igep00x0.h >> > b/include/configs/omap3_igep00x0.h >> > index 5e33845..3cdee02 100644 >> > --- a/include/configs/omap3_igep00x0.h >> > +++ b/include/configs/omap3_igep00x0.h >> > @@ -20,6 +20,16 @@ >> > #include >> > >> > /* >> > + * Remove non-NAND boot modes. >> > + */ >> > +#ifdef CONFIG_BOOT_NAND >> > +#undef CONFIG_SPL_LIBDISK_SUPPORT >> > +#undef CONFIG_SPL_MMC_SUPPORT >> > +#undef CONFIG_SPL_FAT_SUPPORT >> > +#undef CONFIG_SPL_EXT_SUPPORT >> > +#endif >> > + >> >> Hmm, this will break boot from a sdcard, on IGEP the same SPL binary >> is used to boot from flash or sdcard. The reason why we have two >> defconfigs is to select if the board has a ONENAND >> (igep00xx_defconfig) or a NAND (igep00xx_nand_defconfig) but both must >> have support for MMC. > > Ah, OK. So the next thing to do is see about changing > CONFIG_SPL_MAX_SIZE. Or if you don't use SPL EXT2/4 support already, > perhaps drop that? > We're really close to the limit, current size with my compiler is 57312. I saw that SPL_MAX_SIZE is set 54K in include/configs/ti_omap3_common.h, maybe we can grow a bit more the max SPL size? I will take a look what I'm not using but indeed EXT2/4 is not used at the moment in SPL. Regards, - Enric > -- > Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] igep00x0: Use all SRAM available for SPL.
Hi Heiko, 2016-04-27 6:25 GMT+02:00 Heiko Schocher : > Hello Enric, > > Am 26.04.2016 um 17:05 schrieb Enric Balletbo i Serra: >> >> Internal SRAM starts at 0x4020 and ends at 0x4020, so there >> are 64KB available to be used for SPL. This will also help some >> compilers to fit all the code into the allocated space. >> >> Signed-off-by: Enric Balletbo i Serra >> --- >> include/configs/omap3_igep00x0.h | 7 +++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/include/configs/omap3_igep00x0.h >> b/include/configs/omap3_igep00x0.h >> index 5da50a5..2459064 100644 >> --- a/include/configs/omap3_igep00x0.h >> +++ b/include/configs/omap3_igep00x0.h >> @@ -19,6 +19,13 @@ >> #include >> #include >> >> +/* SRAM starts at 0x4020 and ends at 0x4020 (64KB) */ >> +#undef CONFIG_SPL_MAX_SIZE >> +#undef CONFIG_SPL_TEXT_BASE >> + >> +#define CONFIG_SPL_MAX_SIZE(64*1024) >> +#define CONFIG_SPL_TEXT_BASE 0x4020 > > > Hmm... risky, as the SPL needs at last some bytes for stack, until > RAM is initialized and stack moved to it ... or do I miss something? > This is what I thought, orginally I thought CONFIG_SPL_MAX_SIZE(60*1024) /* 4KB for stack */ But then I saw that overo and logic boards set CONFIG_SPL_MAX_SIZE(64 * 1024) I send this version just to have some discussion. So, can we say that overo and logic boards are incorrect too (or at least risky)? And, Tom proposed a 4KB stack, do you think it's enough? Regards, Enric > bye, > Heiko > -- > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > 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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: am335x: select DM_GPIO
2016-08-30 11:51 GMT+02:00 Masahiro Yamada : > We are supposed to not add config entries with only "default y" > in board/SoC Kconfig files. > > Signed-off-by: Masahiro Yamada > --- > > arch/arm/Kconfig | 1 + > board/tcl/sl50/Kconfig | 6 -- > 2 files changed, 1 insertion(+), 6 deletions(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index c871eaf..03eaeda 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -459,6 +459,7 @@ config TARGET_AM335X_SL50 > select CPU_V7 > select SUPPORT_SPL > select DM > + select DM_GPIO > select DM_SERIAL > > config TARGET_BAV335X > diff --git a/board/tcl/sl50/Kconfig b/board/tcl/sl50/Kconfig > index 390a476..d0068d9 100644 > --- a/board/tcl/sl50/Kconfig > +++ b/board/tcl/sl50/Kconfig > @@ -22,10 +22,4 @@ config CONS_INDEX > board you may want something other than UART0 as for example the IDK > uses UART3 so enter 4 here. > > -config DM_GPIO > - default y > - > -config DM_SERIAL > - default y > - > endif > -- > 1.9.1 > Thanks, Acked-by: Enric Balletbo i Serra > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] omap3_igep00x0: Rework MACH_TYPE and status LED logic slightly
2017-01-10 23:22 GMT+01:00 Tom Rini : > The MACH_TYPE for IGEP0032 was never officially used and has been > removed from upstream, so we must not use it. In order to remove this > we need to rework the status LED logic. > > Cc: Enric Balletbo i Serra > Signed-off-by: Tom Rini > --- > configs/igep0032_defconfig | 1 - > include/configs/omap3_igep00x0.h | 5 ++--- > 2 files changed, 2 insertions(+), 4 deletions(-) > > diff --git a/configs/igep0032_defconfig b/configs/igep0032_defconfig > index dad8dfaf0c22..cd48e45171cb 100644 > --- a/configs/igep0032_defconfig > +++ b/configs/igep0032_defconfig > @@ -3,7 +3,6 @@ CONFIG_OMAP34XX=y > # CONFIG_SPL_EXT_SUPPORT is not set > CONFIG_TARGET_OMAP3_IGEP00X0=y > CONFIG_DISTRO_DEFAULTS=y > -CONFIG_SYS_EXTRA_OPTIONS="MACH_TYPE=MACH_TYPE_IGEP0032" > CONFIG_BOOTDELAY=3 > CONFIG_SYS_CONSOLE_IS_IN_ENV=y > CONFIG_SYS_CONSOLE_INFO_QUIET=y > diff --git a/include/configs/omap3_igep00x0.h > b/include/configs/omap3_igep00x0.h > index 30d3aa897f1b..e6d7db0da692 100644 > --- a/include/configs/omap3_igep00x0.h > +++ b/include/configs/omap3_igep00x0.h > @@ -28,7 +28,8 @@ > #define CONFIG_REVISION_TAG1 > > /* Status LED available for IGEP0020 and IGEP0030 but not IGEP0032 */ > -#if (CONFIG_MACH_TYPE != MACH_TYPE_IGEP0032) > +#if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0020) || \ > + (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0030) > #define CONFIG_STATUS_LED > #define CONFIG_BOARD_SPECIFIC_LED > #define CONFIG_GPIO_LED > @@ -36,8 +37,6 @@ > #define RED_LED_GPIO 27 > #elif (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0030) > #define RED_LED_GPIO 16 > -#else > -#error "status LED not defined for this machine." > #endif > #define RED_LED_DEV0 > #define STATUS_LED_BIT RED_LED_GPIO > -- > 1.9.1 > cc: Eduard and Pau I think that there are few boards in the field, an seems that anyone take care to upstream the dts files to the kernel. Currently I don't have this board so I can't support it, so from my side Acked-by: Enric Balletbo i Serra ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] omap3_igep00x0: Rework MACH_TYPE and status LED logic slightly
2017-01-11 16:05 GMT+01:00 Tom Rini : > On Wed, Jan 11, 2017 at 03:59:17PM +0100, Enric Balletbo Serra wrote: >> 2017-01-10 23:22 GMT+01:00 Tom Rini : >> > The MACH_TYPE for IGEP0032 was never officially used and has been >> > removed from upstream, so we must not use it. In order to remove this >> > we need to rework the status LED logic. >> > >> > Cc: Enric Balletbo i Serra >> > Signed-off-by: Tom Rini >> > --- >> > configs/igep0032_defconfig | 1 - >> > include/configs/omap3_igep00x0.h | 5 ++--- >> > 2 files changed, 2 insertions(+), 4 deletions(-) >> > >> > diff --git a/configs/igep0032_defconfig b/configs/igep0032_defconfig >> > index dad8dfaf0c22..cd48e45171cb 100644 >> > --- a/configs/igep0032_defconfig >> > +++ b/configs/igep0032_defconfig >> > @@ -3,7 +3,6 @@ CONFIG_OMAP34XX=y >> > # CONFIG_SPL_EXT_SUPPORT is not set >> > CONFIG_TARGET_OMAP3_IGEP00X0=y >> > CONFIG_DISTRO_DEFAULTS=y >> > -CONFIG_SYS_EXTRA_OPTIONS="MACH_TYPE=MACH_TYPE_IGEP0032" >> > CONFIG_BOOTDELAY=3 >> > CONFIG_SYS_CONSOLE_IS_IN_ENV=y >> > CONFIG_SYS_CONSOLE_INFO_QUIET=y >> > diff --git a/include/configs/omap3_igep00x0.h >> > b/include/configs/omap3_igep00x0.h >> > index 30d3aa897f1b..e6d7db0da692 100644 >> > --- a/include/configs/omap3_igep00x0.h >> > +++ b/include/configs/omap3_igep00x0.h >> > @@ -28,7 +28,8 @@ >> > #define CONFIG_REVISION_TAG1 >> > >> > /* Status LED available for IGEP0020 and IGEP0030 but not IGEP0032 */ >> > -#if (CONFIG_MACH_TYPE != MACH_TYPE_IGEP0032) >> > +#if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0020) || \ >> > + (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0030) >> > #define CONFIG_STATUS_LED >> > #define CONFIG_BOARD_SPECIFIC_LED >> > #define CONFIG_GPIO_LED >> > @@ -36,8 +37,6 @@ >> > #define RED_LED_GPIO 27 >> > #elif (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0030) >> > #define RED_LED_GPIO 16 >> > -#else >> > -#error "status LED not defined for this >> > machine."drivers/iio/common/cros_ec_sensors/Makefile >> > #endif >> > #define RED_LED_DEV0 >> > #define STATUS_LED_BIT RED_LED_GPIO >> > -- >> > 1.9.1 >> > >> >> cc: Eduard and Pau >> >> I think that there are few boards in the field, an seems that anyone >> take care to upstream the dts files to the kernel. Currently I don't >> have this board so I can't support it, so from my side >> >> Acked-by: Enric Balletbo i Serra > > Note that all the above patch does is remove ATAGS-based support as the > MACH_TYPE for the 0032 was reserved, but never used and thus the name > was removed. DT based support is unchanged. > > -- > Tom Yes, I saw it, thus my ack ... I just wondering if this board is really used and if we should completely remove it or not. Sorry for not having better explained ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] igep00x0: disable CONFIG_DISPLAY_BOARDINFO
Hi Ladis,
2016-09-20 11:04 GMT+02:00 Ladislav Michl :
> As a single U-Boot binary can now run on various board modifications,
> drop CONFIG_DISPLAY_BOARDINFO as there's no known way to distinguish
> between them. Also saves few bytes as a bonus.
>
> Signed-off-by: Ladislav Michl
> ---
> board/isee/igep00x0/igep00x0.c | 18 --
> include/configs/omap3_igep00x0.h | 5 +
> 2 files changed, 1 insertion(+), 22 deletions(-)
>
> diff --git a/board/isee/igep00x0/igep00x0.c b/board/isee/igep00x0/igep00x0.c
> index 808955e..71688cc 100644
> --- a/board/isee/igep00x0/igep00x0.c
> +++ b/board/isee/igep00x0/igep00x0.c
> @@ -27,24 +27,6 @@
>
> DECLARE_GLOBAL_DATA_PTR;
>
> -const omap3_sysinfo sysinfo = {
> - DDR_STACKED,
> -#if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0020)
> - "IGEPv2",
> -#endif
> -#if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0030)
> - "IGEP COM MODULE/ELECTRON",
> -#endif
> -#if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0032)
> - "IGEP COM PROTON",
> -#endif
> -#if defined(CONFIG_ENV_IS_IN_ONENAND)
> - "ONENAND",
> -#else
> - "NAND",
> -#endif
> -};
> -
> static const struct ns16550_platdata igep_serial = {
> .base = OMAP34XX_UART3,
> .reg_shift = 2,
> diff --git a/include/configs/omap3_igep00x0.h
> b/include/configs/omap3_igep00x0.h
> index 1f30710..2ae9737 100644
> --- a/include/configs/omap3_igep00x0.h
> +++ b/include/configs/omap3_igep00x0.h
> @@ -23,11 +23,8 @@
> #undef CONFIG_SPL_TEXT_BASE
> #define CONFIG_SPL_TEXT_BASE 0x4020
>
> -/*
> - * Display CPU and Board information
> - */
> +/* Display CPU information */
> #define CONFIG_DISPLAY_CPUINFO 1
> -#define CONFIG_DISPLAY_BOARDINFO 1
>
> #define CONFIG_MISC_INIT_R
>
> --
> 2.1.4
>
I must NACK for now these series, meanwhile I don't find time to look
at this deeply. I think this will break lots of things. For example,
will this u-boot boot a non-device tree based kernel without breaking
things? I don't think so, It's right that non-device tree kernels are
old but these are still used in lots of IGEP boards and I don't want
to break this, for now.
Please give me some time to look at this and think in all the use cases.
Thanks,
Enric.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] igep00x0: consolidate defconfigs
Hi, 2016-09-21 11:39 GMT+02:00 Ladislav Michl : > On Tue, Sep 20, 2016 at 08:26:36PM -0400, Tom Rini wrote: >> On Wed, Sep 21, 2016 at 01:52:21AM +0200, Ladislav Michl wrote: >> > On Tue, Sep 20, 2016 at 07:45:14PM -0400, Tom Rini wrote: > [snip] >> > > But why do we even need to set MACH_TYPE these days? >> > >> > That's only needed for non-device tree kernel boot. These boards run mostly >> > vendor provided kernels based on TI 2.6.32 or 2.6.37 kernel tree with >> > daughter boards specific patches on top of it. Enric is concerned not >> > to break that support, so I'm trying to keep it. >> >> OK, if you're still supporting stuff that old then yes, it makes sense. >> And we can't get this right at run time? > > I asked several times, if there's a way to differentiate those boards > (0020, 0030 and 0032) at runtime, but never get an answer. Of course > I'd like to see one U-Boot binary to rule them all, but I'm out of clue > there. Few people added to Cc... > There is no way to differentiate those boards at runtime, those boards are completely different platforms that share same processor, like BeagleBoard or OMAP3 Overos . For me what you're trying to do is join different platforms with the same processor, so why not join BeagleBone, Overos, and IGEPs and all other OMAP3 based platforms? > Another approach might be to configure U-Boot using FDT and translate > that information into MACH_TYPE and kernel command line to support > non-device tree enabled kernels. > That is what I would like to see someday ;) All OMAP3 based boards sharing the same binary and configure U-Boot using FDT. > ladis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] igep00x0: consolidate defconfigs
2016-09-21 14:51 GMT+02:00 Tom Rini : > On Wed, Sep 21, 2016 at 01:46:51PM +0200, Enric Balletbo Serra wrote: >> Hi, >> >> 2016-09-21 11:39 GMT+02:00 Ladislav Michl : >> > On Tue, Sep 20, 2016 at 08:26:36PM -0400, Tom Rini wrote: >> >> On Wed, Sep 21, 2016 at 01:52:21AM +0200, Ladislav Michl wrote: >> >> > On Tue, Sep 20, 2016 at 07:45:14PM -0400, Tom Rini wrote: >> > [snip] >> >> > > But why do we even need to set MACH_TYPE these days? >> >> > >> >> > That's only needed for non-device tree kernel boot. These boards run >> >> > mostly >> >> > vendor provided kernels based on TI 2.6.32 or 2.6.37 kernel tree with >> >> > daughter boards specific patches on top of it. Enric is concerned not >> >> > to break that support, so I'm trying to keep it. >> >> >> >> OK, if you're still supporting stuff that old then yes, it makes sense. >> >> And we can't get this right at run time? >> > >> > I asked several times, if there's a way to differentiate those boards >> > (0020, 0030 and 0032) at runtime, but never get an answer. Of course >> > I'd like to see one U-Boot binary to rule them all, but I'm out of clue >> > there. Few people added to Cc... >> >> There is no way to differentiate those boards at runtime, those boards >> are completely different platforms that share same processor, like >> BeagleBoard or OMAP3 Overos . For me what you're trying to do is join >> different platforms with the same processor, so why not join >> BeagleBone, Overos, and IGEPs and all other OMAP3 based platforms? > > Note that the different beagleboard used GPIOs to tell which platform is > which :) > Yes, but if I'm not mistaken you have different GPIOs for different hardware revisions of Beagleboard. For IGEPv2 this is also true, you have different GPIOs for different hardware revisions of IGEPv2. But we're talking about join two completely different boards, i.e join IGEPv2 (IGEP0020) with IGEP COM PROTON (IGEP0032) would be similar to join Beagleboard with OMAP3 OVERO COM. OTOH I think the Ladis work trying to join the IGEP boards is really interesting, just want to look deeper :) >> > Another approach might be to configure U-Boot using FDT and translate >> > that information into MACH_TYPE and kernel command line to support >> > non-device tree enabled kernels. >> >> That is what I would like to see someday ;) All OMAP3 based boards >> sharing the same binary and configure U-Boot using FDT. > > The probably trickiest part here is DDR config, which still punts things > down to a board specific MLO. But within an SoC this is probably a lot > closer than people might think. > > -- > Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv7 6/7] igep00x0: UBIize
2016-04-13 7:19 GMT+02:00 Heiko Schocher : > Hello Enric, > > > Am 25.01.2016 um 17:56 schrieb Enric Balletbo Serra: >> >> Hi Ladis, >> >> 2016-01-25 16:56 GMT+01:00 Ladislav Michl : >>> >>> Hi Enric, >>> >>> On Mon, Jan 25, 2016 at 08:26:23AM +0100, Enric Balletbo Serra wrote: >>>> >>>> The ROM boot on OMAP reads the first 4 blocks searching for the SPL, >>>> in production is a practice flash the SPL 4 times. OneNAND/NAND >>>> devices can have different block sizes and the OMAP ROM boot supports >>>> block sizes from 64KB to 512K. For IGEP boards in particular, at least >>>> there are boards that have block size of 128K and 256K. What I would >>>> meant here is set as default the mtdparts variable to reserve 2M for >>>> SPL, just to cover all the cases. >>>> >>>> mtdparts=mtdparts=gpmc-nand.0:2m(SPL),-(UBI)\0 >>> >>> >>> So far there was no ack or nack to yesterday's proposal making that >>> dynamic; Both boot ROM and ubispl code thinks in terms of eraseblocks, >>> only mtd needs fixed offset. So I'd like to see this offset calculated as >>> 4*block_size, not some "worst case" value... >>> >>> ladis >> >> >> Your proposal looks good to me. >> > > Are there any updates for this patch? The UBI SPL support is pending > for a while ... > > I pushed my last (rebased to mainline) state to: > > http://git.denx.de/?p=u-boot/u-boot-ubi.git;a=shortlog;h=refs/heads/ubi-spl > > without the 2 igep00x0 board patches: > > - [U-Boot,PATCHv7,6/7] igep00x0: UBIize > https://patchwork.ozlabs.org/patch/569214/ > > - [U-Boot,PATCHv4,7/7] igep00x0: Falcon mode > https://patchwork.ozlabs.org/patch/569215/ > > Could you please update your patches for the board support, so we can > push the UBI SPL support to mainline? > Ladis, did you have a chance to look and solve the latest comments I did? These patch series looks really interesting, like Heiko I would like to see these merged. > Thanks! > > > bye, > Heiko > -- > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > 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] [PATCHv7 6/7] igep00x0: UBIize
Hi Ladislav, 2016-04-13 13:39 GMT+02:00 Enric Balletbo Serra : > 2016-04-13 7:19 GMT+02:00 Heiko Schocher : >> Hello Enric, >> >> >> Am 25.01.2016 um 17:56 schrieb Enric Balletbo Serra: >>> >>> Hi Ladis, >>> >>> 2016-01-25 16:56 GMT+01:00 Ladislav Michl : >>>> >>>> Hi Enric, >>>> >>>> On Mon, Jan 25, 2016 at 08:26:23AM +0100, Enric Balletbo Serra wrote: >>>>> >>>>> The ROM boot on OMAP reads the first 4 blocks searching for the SPL, >>>>> in production is a practice flash the SPL 4 times. OneNAND/NAND >>>>> devices can have different block sizes and the OMAP ROM boot supports >>>>> block sizes from 64KB to 512K. For IGEP boards in particular, at least >>>>> there are boards that have block size of 128K and 256K. What I would >>>>> meant here is set as default the mtdparts variable to reserve 2M for >>>>> SPL, just to cover all the cases. >>>>> >>>>> mtdparts=mtdparts=gpmc-nand.0:2m(SPL),-(UBI)\0 >>>> >>>> >>>> So far there was no ack or nack to yesterday's proposal making that >>>> dynamic; Both boot ROM and ubispl code thinks in terms of eraseblocks, >>>> only mtd needs fixed offset. So I'd like to see this offset calculated as >>>> 4*block_size, not some "worst case" value... >>>> >>>> ladis >>> >>> >>> Your proposal looks good to me. >>> >> >> Are there any updates for this patch? The UBI SPL support is pending >> for a while ... >> >> I pushed my last (rebased to mainline) state to: >> >> http://git.denx.de/?p=u-boot/u-boot-ubi.git;a=shortlog;h=refs/heads/ubi-spl >> >> without the 2 igep00x0 board patches: >> >> - [U-Boot,PATCHv7,6/7] igep00x0: UBIize >> https://patchwork.ozlabs.org/patch/569214/ >> >> - [U-Boot,PATCHv4,7/7] igep00x0: Falcon mode >> https://patchwork.ozlabs.org/patch/569215/ >> >> Could you please update your patches for the board support, so we can >> push the UBI SPL support to mainline? >> > > Ladis, did you have a chance to look and solve the latest comments I did? > If you don't have enough time maybe I can pickup the patches and finish the work, if it's ok. I'll have some time this weekend. > These patch series looks really interesting, like Heiko I would like > to see these merged. > >> Thanks! >> >> >> bye, >> Heiko >> -- >> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk >> 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] [PATCH 1/2] configs: igep: Define default mtdids/mtdparts
+Ladis who might be also interested.
Missatge de Boris Brezillon del dia dl.,
10 de des. 2018 a les 16:38:
>
> We are trying to get rid of the weak board_mtdparts_default() function
> and we need to make sure igep defconfigs have proper proper
> CONFIG_MTD{IDS,PARTS}_DEFAULT before doing that.
>
> Signed-off-by: Boris Brezillon
> ---
> configs/igep0032_defconfig | 2 ++
> configs/igep00x0_defconfig | 2 ++
> 2 files changed, 4 insertions(+)
>
> diff --git a/configs/igep0032_defconfig b/configs/igep0032_defconfig
> index 383648789c53..d2a614c98f6d 100644
> --- a/configs/igep0032_defconfig
> +++ b/configs/igep0032_defconfig
> @@ -28,6 +28,8 @@ CONFIG_CMD_SPI=y
> CONFIG_CMD_CACHE=y
> CONFIG_CMD_EXT4_WRITE=y
> CONFIG_CMD_MTDPARTS=y
> +CONFIG_MTDIDS_DEFAULT="nand0=omap2-nand,onenand0=omap2-onenand"
> +CONFIG_MTDPARTS_DEFAULT="omap2-nand:512k(SPL),-(UBI);omap2-onenand:512k(SPL),-(UBI)"
> CONFIG_CMD_UBI=y
> # CONFIG_CMD_UBIFS is not set
> CONFIG_NET_RANDOM_ETHADDR=y
> diff --git a/configs/igep00x0_defconfig b/configs/igep00x0_defconfig
> index f2989e34e12e..5d3e109ee3c2 100644
> --- a/configs/igep00x0_defconfig
> +++ b/configs/igep00x0_defconfig
> @@ -28,6 +28,8 @@ CONFIG_CMD_SPI=y
> CONFIG_CMD_CACHE=y
> CONFIG_CMD_EXT4_WRITE=y
> CONFIG_CMD_MTDPARTS=y
> +CONFIG_MTDIDS_DEFAULT="nand0=omap2-nand,onenand0=omap2-onenand"
> +CONFIG_MTDPARTS_DEFAULT="omap2-nand:512k(SPL),-(UBI);omap2-onenand:512k(SPL),-(UBI)"
> CONFIG_CMD_UBI=y
> # CONFIG_CMD_UBIFS is not set
> CONFIG_NET_RANDOM_ETHADDR=y
> --
> 2.17.1
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] mtd: Get rid of board_mtdparts_default()
+Ladis who might be also interested.
Missatge de Boris Brezillon del dia dl.,
10 de des. 2018 a les 16:38:
>
> The only implementer of this function has been patched to use
> CONFIG_MTD{IDS,PARTS}_DEFAULT instead. Let's get rid of this function
> and the associated CONFIG_SYS_MTDPARTS_RUNTIME option.
>
> Signed-off-by: Boris Brezillon
> ---
> board/isee/igep00x0/igep00x0.c | 17 -
> cmd/mtdparts.c | 6 --
> drivers/mtd/mtd_uboot.c | 10 ++
> include/configs/omap3_igep00x0.h | 2 --
> scripts/config_whitelist.txt | 1 -
> 5 files changed, 2 insertions(+), 34 deletions(-)
>
> diff --git a/board/isee/igep00x0/igep00x0.c b/board/isee/igep00x0/igep00x0.c
> index 367af82d4a16..3552be6f3902 100644
> --- a/board/isee/igep00x0/igep00x0.c
> +++ b/board/isee/igep00x0/igep00x0.c
> @@ -239,20 +239,3 @@ int misc_init_r(void)
>
> return 0;
> }
> -
> -void board_mtdparts_default(const char **mtdids, const char **mtdparts)
> -{
> - struct mtd_info *mtd = get_mtd_device(NULL, 0);
> - if (mtd) {
> - static char ids[24];
> - static char parts[48];
> - const char *linux_name = "omap2-nand";
> - if (strncmp(mtd->name, "onenand0", 8) == 0)
> - linux_name = "omap2-onenand";
> - snprintf(ids, sizeof(ids), "%s=%s", mtd->name, linux_name);
> - snprintf(parts, sizeof(parts), "mtdparts=%s:%dk(SPL),-(UBI)",
> -linux_name, 4 * mtd->erasesize >> 10);
> - *mtdids = ids;
> - *mtdparts = parts;
> - }
> -}
> diff --git a/cmd/mtdparts.c b/cmd/mtdparts.c
> index f7ed1a077974..6b5644523898 100644
> --- a/cmd/mtdparts.c
> +++ b/cmd/mtdparts.c
> @@ -122,9 +122,6 @@ DECLARE_GLOBAL_DATA_PTR;
> #define MTDPARTS_DEFAULT NULL
> #endif
> #endif
> -#if defined(CONFIG_SYS_MTDPARTS_RUNTIME)
> -extern void board_mtdparts_default(const char **mtdids, const char
> **mtdparts);
> -#endif
> static const char *mtdids_default = MTDIDS_DEFAULT;
> static const char *mtdparts_default = MTDPARTS_DEFAULT;
>
> @@ -1733,9 +1730,6 @@ int mtdparts_init(void)
> memset(last_ids, 0, sizeof(last_ids));
> memset(last_parts, 0, sizeof(last_parts));
> memset(last_partition, 0, sizeof(last_partition));
> -#if defined(CONFIG_SYS_MTDPARTS_RUNTIME)
> - board_mtdparts_default(&mtdids_default, &mtdparts_default);
> -#endif
> use_defaults = 1;
> initialized = 1;
> }
> diff --git a/drivers/mtd/mtd_uboot.c b/drivers/mtd/mtd_uboot.c
> index d638f700d041..ed619abac390 100644
> --- a/drivers/mtd/mtd_uboot.c
> +++ b/drivers/mtd/mtd_uboot.c
> @@ -13,8 +13,6 @@
>
> #define MTD_NAME_MAX_LEN 20
>
> -void board_mtdparts_default(const char **mtdids, const char **mtdparts);
> -
> static const char *get_mtdids(void)
> {
> __maybe_unused const char *mtdparts = NULL;
> @@ -23,9 +21,7 @@ static const char *get_mtdids(void)
> if (mtdids)
> return mtdids;
>
> -#if defined(CONFIG_SYS_MTDPARTS_RUNTIME)
> - board_mtdparts_default(&mtdids, &mtdparts);
> -#elif defined(MTDIDS_DEFAULT)
> +#if defined(MTDIDS_DEFAULT)
> mtdids = MTDIDS_DEFAULT;
> #elif defined(CONFIG_MTDIDS_DEFAULT)
> mtdids = CONFIG_MTDIDS_DEFAULT;
> @@ -133,9 +129,7 @@ static const char *get_mtdparts(void)
> if (mtdparts || !use_defaults)
> return mtdparts;
>
> -#if defined(CONFIG_SYS_MTDPARTS_RUNTIME)
> - board_mtdparts_default(&mtdids, &mtdparts);
> -#elif defined(MTDPARTS_DEFAULT)
> +#if defined(MTDPARTS_DEFAULT)
> mtdparts = MTDPARTS_DEFAULT;
> #elif defined(CONFIG_MTDPARTS_DEFAULT)
> mtdparts = CONFIG_MTDPARTS_DEFAULT;
> diff --git a/include/configs/omap3_igep00x0.h
> b/include/configs/omap3_igep00x0.h
> index b9d65697521b..280a094cdbae 100644
> --- a/include/configs/omap3_igep00x0.h
> +++ b/include/configs/omap3_igep00x0.h
> @@ -87,8 +87,6 @@
>
> #endif
>
> -#define CONFIG_SYS_MTDPARTS_RUNTIME
> -
> /* OneNAND config */
> #define CONFIG_USE_ONENAND_BOARD_INIT
> #define CONFIG_SYS_ONENAND_BASEONENAND_MAP
> diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
> index b8addeaf693a..72608071c486 100644
> --- a/scripts/config_whitelist.txt
> +++ b/scripts/config_whitelist.txt
> @@ -3511,7 +3511,6 @@ CONFIG_SYS_MRAM_SIZE
> CONFIG_SYS_MSC0_VAL
> CONFIG_SYS_MSC1_VAL
> CONFIG_SYS_MSC2_VAL
> -CONFIG_SYS_MTDPARTS_RUNTIME
> CONFIG_SYS_MX5_CLK32
> CONFIG_SYS_MX5_HCLK
> CONFIG_SYS_MX6_CLK32
> --
> 2.17.1
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] configs: igep: Define default mtdids/mtdparts
Hi Boris,
Missatge de Enric Balletbo Serra del dia dl., 10
de des. 2018 a les 22:50:
>
> +Ladis who might be also interested.
> Missatge de Boris Brezillon del dia dl.,
> 10 de des. 2018 a les 16:38:
> >
> > We are trying to get rid of the weak board_mtdparts_default() function
> > and we need to make sure igep defconfigs have proper proper
> > CONFIG_MTD{IDS,PARTS}_DEFAULT before doing that.
> >
> > Signed-off-by: Boris Brezillon
> > ---
> > configs/igep0032_defconfig | 2 ++
> > configs/igep00x0_defconfig | 2 ++
> > 2 files changed, 4 insertions(+)
> >
> > diff --git a/configs/igep0032_defconfig b/configs/igep0032_defconfig
> > index 383648789c53..d2a614c98f6d 100644
> > --- a/configs/igep0032_defconfig
> > +++ b/configs/igep0032_defconfig
> > @@ -28,6 +28,8 @@ CONFIG_CMD_SPI=y
> > CONFIG_CMD_CACHE=y
> > CONFIG_CMD_EXT4_WRITE=y
> > CONFIG_CMD_MTDPARTS=y
> > +CONFIG_MTDIDS_DEFAULT="nand0=omap2-nand,onenand0=omap2-onenand"
> > +CONFIG_MTDPARTS_DEFAULT="omap2-nand:512k(SPL),-(UBI);omap2-onenand:512k(SPL),-(UBI)"
> > CONFIG_CMD_UBI=y
> > # CONFIG_CMD_UBIFS is not set
> > CONFIG_NET_RANDOM_ETHADDR=y
> > diff --git a/configs/igep00x0_defconfig b/configs/igep00x0_defconfig
> > index f2989e34e12e..5d3e109ee3c2 100644
> > --- a/configs/igep00x0_defconfig
> > +++ b/configs/igep00x0_defconfig
> > @@ -28,6 +28,8 @@ CONFIG_CMD_SPI=y
> > CONFIG_CMD_CACHE=y
> > CONFIG_CMD_EXT4_WRITE=y
> > CONFIG_CMD_MTDPARTS=y
> > +CONFIG_MTDIDS_DEFAULT="nand0=omap2-nand,onenand0=omap2-onenand"
> > +CONFIG_MTDPARTS_DEFAULT="omap2-nand:512k(SPL),-(UBI);omap2-onenand:512k(SPL),-(UBI)"
> > CONFIG_CMD_UBI=y
> > # CONFIG_CMD_UBIFS is not set
> > CONFIG_NET_RANDOM_ETHADDR=y
> > --
> > 2.17.1
> >
After do some tests, the patch lgtm
Acked-by: Enric Balletbo i Serra
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] mtd: Get rid of board_mtdparts_default()
Hi Boris,
Missatge de Boris Brezillon del dia dc.,
12 de des. 2018 a les 18:36:
>
> On Wed, 12 Dec 2018 12:37:04 +0100
> Ladislav Michl wrote:
>
> > Now problem is that IGEPv2 comes with quite many configurations, some of
> > them are even customized, so static configuration is a show stopper
> > mainly as I do not know what devices are in field.
> > Another issue is how ubispl code works: It expects struct ubispl_info
> > filled with (among others) peb_offset of ubi partition. ubispl code counts
> > in terms of eraseblocks regardless of their size. So we would need to touch
> > this number when using static mtdparts.
>
> Okay.
>
> >
> > > > Hence runtime detection. That code could be used
> > > > on all OMAP3 boards as BootROM reads up to first four sectors searching
> > > > for SPL (MLO).
> > >
> > > Note that, for the nand side of things, you can also automate that using
> > > a u-boot script:
> > >
> > > nand info; setexpr splsize ${nand_erasesize} * 4; setenv mtdparts
> > > mtdparts=omap2-nand:0x${splsize}(SPL),-(UBI)
> >
> > That seems as a way to go!
>
> Glad you like this idea.
>
> >
> > > Shouldn't be hard to patch the onenand cmd to also expose writesize,
> > > erasesize and oobsize.
> >
> > Side note: I never fully understand why is OneNAND using separate set of
> > commands.
>
> Hehe. That's exactly what Miquel tries to address with the mtd command
> (one command to rule them all).
>
> >
> > Could you hold merging your paches until I implement above idea and test
> > it on a few boards? I know u-boot is now using two months merge window,
> > which is unfortunate, so I'll try to do it as soon as possible, but I do
> > not think I'll finish it till end of week.
>
> No worries. This is not urgent and can definitely wait 2019.04.
>
Yes, will be good if we can have the Ladis work merged at the same
time. He will probably have more variety of boards than me to test
this, but from my side, and after do some tests the patch LGTM
Acked-by: Enric Balletbo i Serra
Thanks,
Enric
> Thanks,
>
> Boris
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 7/9] configs: migrate ubispl boards to KConfig
Missatge de Markus Klotzbuecher del dia dc., 15 de maig 2019 a les 15:16: > > From: Markus Klotzbuecher > > Migrate the ubispl configuration for the omap3_igep00x0 and > am335x_igep003x boards to KConfig. Both boards were built with > SOURCE_DATE_EPOCH=0 and found to be equal before and after. > > Signed-off-by: Markus Klotzbuecher > Cc: Heiko Schocher > Cc: Kyungmin Park > Cc: Javier MartÃnez Canillas > Cc: Enric Balletbo i Serra Acked-by: Enric Balletbo i Serra Thanks, Enric > --- > Changes for v2: new patch > > configs/am335x_igep003x_defconfig | 12 > configs/igep00x0_defconfig| 12 > include/configs/am335x_igep003x.h | 16 > include/configs/omap3_igep00x0.h | 14 -- > 4 files changed, 24 insertions(+), 30 deletions(-) > > diff --git a/configs/am335x_igep003x_defconfig > b/configs/am335x_igep003x_defconfig > index f44fb09b31..5874831ba1 100644 > --- a/configs/am335x_igep003x_defconfig > +++ b/configs/am335x_igep003x_defconfig > @@ -21,6 +21,18 @@ CONFIG_VERSION_VARIABLE=y > CONFIG_SPL_FS_EXT4=y > CONFIG_SPL_I2C_SUPPORT=y > CONFIG_SPL_MTD_SUPPORT=y > +CONFIG_SPL_UBI=y > +CONFIG_SPL_UBI_MAX_VOL_LEBS=256 > +CONFIG_SPL_UBI_MAX_PEB_SIZE=262144 > +CONFIG_SPL_UBI_MAX_PEBS=4096 > +CONFIG_SPL_UBI_PEB_OFFSET=4 > +CONFIG_SPL_UBI_VID_OFFSET=512 > +CONFIG_SPL_UBI_LEB_START=2048 > +CONFIG_SPL_UBI_INFO_ADDR=0x8808 > +CONFIG_SPL_UBI_VOL_IDS=8 > +CONFIG_SPL_UBI_LOAD_MONITOR_ID=0 > +CONFIG_SPL_UBI_LOAD_KERNEL_ID=3 > +CONFIG_SPL_UBI_LOAD_ARGS_ID=4 > CONFIG_SPL_OS_BOOT=y > CONFIG_SPL_POWER_SUPPORT=y > CONFIG_SPL_WATCHDOG_SUPPORT=y > diff --git a/configs/igep00x0_defconfig b/configs/igep00x0_defconfig > index 927d7f0ecd..ab11935f48 100644 > --- a/configs/igep00x0_defconfig > +++ b/configs/igep00x0_defconfig > @@ -17,6 +17,18 @@ CONFIG_SPL_TEXT_BASE=0x4020 > CONFIG_SPL_SYS_MALLOC_SIMPLE=y > # CONFIG_SPL_FS_EXT4 is not set > CONFIG_SPL_MTD_SUPPORT=y > +CONFIG_SPL_UBI=y > +CONFIG_SPL_UBI_MAX_VOL_LEBS=256 > +CONFIG_SPL_UBI_MAX_PEB_SIZE=262144 > +CONFIG_SPL_UBI_MAX_PEBS=4096 > +CONFIG_SPL_UBI_PEB_OFFSET=4 > +CONFIG_SPL_UBI_VID_OFFSET=512 > +CONFIG_SPL_UBI_LEB_START=2048 > +CONFIG_SPL_UBI_INFO_ADDR=0x8808 > +CONFIG_SPL_UBI_VOL_IDS=8 > +CONFIG_SPL_UBI_LOAD_MONITOR_ID=0 > +CONFIG_SPL_UBI_LOAD_KERNEL_ID=3 > +CONFIG_SPL_UBI_LOAD_ARGS_ID=4 > CONFIG_SPL_ONENAND_SUPPORT=y > CONFIG_SPL_OS_BOOT=y > CONFIG_CMD_SPL=y > diff --git a/include/configs/am335x_igep003x.h > b/include/configs/am335x_igep003x.h > index 5131cd38e4..5b5e16026e 100644 > --- a/include/configs/am335x_igep003x.h > +++ b/include/configs/am335x_igep003x.h > @@ -106,22 +106,6 @@ > /* NAND support */ > #define CONFIG_SYS_NAND_ONFI_DETECTION 1 > > -/* SPL */ > - > -/* UBI configuration */ > -#define CONFIG_SPL_UBI 1 > -#define CONFIG_SPL_UBI_MAX_VOL_LEBS256 > -#define CONFIG_SPL_UBI_MAX_PEB_SIZE(256*1024) > -#define CONFIG_SPL_UBI_MAX_PEBS4096 > -#define CONFIG_SPL_UBI_VOL_IDS 8 > -#define CONFIG_SPL_UBI_LOAD_MONITOR_ID 0 > -#define CONFIG_SPL_UBI_LOAD_KERNEL_ID 3 > -#define CONFIG_SPL_UBI_LOAD_ARGS_ID4 > -#define CONFIG_SPL_UBI_PEB_OFFSET 4 > -#define CONFIG_SPL_UBI_VID_OFFSET 512 > -#define CONFIG_SPL_UBI_LEB_START 2048 > -#define CONFIG_SPL_UBI_INFO_ADDR 0x8808 > - > /* NAND config */ > #define CONFIG_SYS_NAND_5_ADDR_CYCLE > #define CONFIG_SYS_NAND_PAGE_COUNT (CONFIG_SYS_NAND_BLOCK_SIZE / \ > diff --git a/include/configs/omap3_igep00x0.h > b/include/configs/omap3_igep00x0.h > index a95a9cc664..4ad7dc18b1 100644 > --- a/include/configs/omap3_igep00x0.h > +++ b/include/configs/omap3_igep00x0.h > @@ -96,18 +96,4 @@ > #define CONFIG_SYS_NAND_ECCBYTES 14 > #define CONFIG_NAND_OMAP_ECCSCHEME OMAP_ECC_BCH8_CODE_HW_DETECTION_SW > > -/* UBI configuration */ > -#define CONFIG_SPL_UBI 1 > -#define CONFIG_SPL_UBI_MAX_VOL_LEBS256 > -#define CONFIG_SPL_UBI_MAX_PEB_SIZE(256*1024) > -#define CONFIG_SPL_UBI_MAX_PEBS4096 > -#define CONFIG_SPL_UBI_VOL_IDS 8 > -#define CONFIG_SPL_UBI_LOAD_MONITOR_ID 0 > -#define CONFIG_SPL_UBI_LOAD_KERNEL_ID 3 > -#define CONFIG_SPL_UBI_LOAD_ARGS_ID4 > -#define CONFIG_SPL_UBI_PEB_OFFSET 4 > -#define CONFIG_SPL_UBI_VID_OFFSET 512 > -#define CONFIG_SPL_UBI_LEB_START 2048 > -#define CONFIG_SPL_UBI_INFO_ADDR 0x8808 > - > #endif /* __IGEP00X0_H */ > -- > 2.20.1 > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Getting rid of board_mtdparts_default()
Hello Boris,
Missatge de Boris Brezillon del dia dj.,
15 de nov. 2018 a les 16:58:
>
> Hello Enric,
>
> Miquel and I recently reworked drivers/mtd/mtdpart.c to get MTD
> partitions exposed as MTD devices (as is done in Linux) instead of
> having yet another abstraction to handle them (see what's currently
> done in cmd/{mtdparts,nand,sf,...}.c).
>
> This lead us to duplicate the mtdparts/mtdids parsing logic we found in
> cmd/mtdparts.c, and while doing that we noticed that one function is
> only implemented by igep boards: board_mtdparts_default().
>
> We'd like to get rid of this function if possible in order to simplify
> the mtdparts/mtdids retrieval logic, and there might be an easy
> solution to do that: use the CONFIG_{MTDPARTS,MTDIDS}_DEFAULT config
> options
>
> CONFIG_MTDPARTS_DEFAULT="omap2-nand:512k(SPL),-(UBI);omap2-onenand:512k(SPL),-(UBI)"
> CONFIG_MTDIDS_DEFAULT="nand0=omap2-nand,onenand0=omap2-onenand"
>
> It seems those defaults were built at runtime, and the only thing I'm
> not sure about is whether 512k for the SPL is always good. Looks like
> 4 eraseblocks are reserved for the SPL [1], but is the eraseblock size
> always 128k?
No, there are boards in the field that doesn't have and eraseblock
size of 128k, as far as I can remember there are at least boards with
an eraseblock of 64k, I don't remember though, boards with and
eraseblock size greater than 128k. About the 4 eraseblocks, there is a
reason for this., the blocks are reserved for the SPL because you can
flash 4 times (once per block) the SPL, the ROM code looks for an
image in the first four blocks and it detects the validity status of
these blocks. So, if the first one is corrupted, boots from the
second, if the second is corrupted looks for the third, etc.
Said this, I think that the main question is if it's fine to get rid
of this code. Ideally, we should cover all the cases, so assuming that
there aren't devices with an eraseblock size greater than 128k,
reserve 512k seems a good number. There is, though, a corner case
where this number is not fine. There are some boards that came with a
OneNand(DDP), the ROM code is only capable to read the odd blocks (1,
3, 5, 7...). So, in this case, you need to reserve 896k (128k NA 128k
NA 128k NA 128k ). Fwiw that was also not covered with current code.
To be honest, I wouldn't worry about this latest case, and in my
opinion, a fixed size of 512k is enough. Also, it's common now that
the first few blocks of NAND flash are guaranteed to be safe for the
first N erase cycles. So, I'm fine with the proposed fixed 512k for
SPL. Btw, good job.
Best regards,
Enric
> If you don't know about the eraseblock size, maybe you
> know which OneNAND/NAND parts are used on these boards?
>
> Regards,
>
> Boris
>
> [1]https://elixir.bootlin.com/u-boot/latest/source/board/isee/igep00x0/igep00x0.c#L254
>
> --
> Boris Brezillon, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Getting rid of board_mtdparts_default()
Missatge de Boris Brezillon del dia dj.,
15 de nov. 2018 a les 23:40:
>
> On Thu, 15 Nov 2018 23:18:46 +0100
> Enric Balletbo Serra wrote:
>
> > Hello Boris,
> >
> > Missatge de Boris Brezillon del dia dj.,
> > 15 de nov. 2018 a les 16:58:
> > >
> > > Hello Enric,
> > >
> > > Miquel and I recently reworked drivers/mtd/mtdpart.c to get MTD
> > > partitions exposed as MTD devices (as is done in Linux) instead of
> > > having yet another abstraction to handle them (see what's currently
> > > done in cmd/{mtdparts,nand,sf,...}.c).
> > >
> > > This lead us to duplicate the mtdparts/mtdids parsing logic we found in
> > > cmd/mtdparts.c, and while doing that we noticed that one function is
> > > only implemented by igep boards: board_mtdparts_default().
> > >
> > > We'd like to get rid of this function if possible in order to simplify
> > > the mtdparts/mtdids retrieval logic, and there might be an easy
> > > solution to do that: use the CONFIG_{MTDPARTS,MTDIDS}_DEFAULT config
> > > options
> > >
> > > CONFIG_MTDPARTS_DEFAULT="omap2-nand:512k(SPL),-(UBI);omap2-onenand:512k(SPL),-(UBI)"
> > > CONFIG_MTDIDS_DEFAULT="nand0=omap2-nand,onenand0=omap2-onenand"
> > >
> > > It seems those defaults were built at runtime, and the only thing I'm
> > > not sure about is whether 512k for the SPL is always good. Looks like
> > > 4 eraseblocks are reserved for the SPL [1], but is the eraseblock size
> > > always 128k?
> >
> > No, there are boards in the field that doesn't have and eraseblock
> > size of 128k, as far as I can remember there are at least boards with
> > an eraseblock of 64k, I don't remember though, boards with and
> > eraseblock size greater than 128k. About the 4 eraseblocks, there is a
> > reason for this., the blocks are reserved for the SPL because you can
> > flash 4 times (once per block) the SPL, the ROM code looks for an
> > image in the first four blocks and it detects the validity status of
> > these blocks. So, if the first one is corrupted, boots from the
> > second, if the second is corrupted looks for the third, etc.
> >
> > Said this, I think that the main question is if it's fine to get rid
> > of this code. Ideally, we should cover all the cases, so assuming that
> > there aren't devices with an eraseblock size greater than 128k,
> > reserve 512k seems a good number. There is, though, a corner case
> > where this number is not fine. There are some boards that came with a
> > OneNand(DDP), the ROM code is only capable to read the odd blocks (1,
> > 3, 5, 7...). So, in this case, you need to reserve 896k (128k NA 128k
> > NA 128k NA 128k ). Fwiw that was also not covered with current code.
> >
> > To be honest, I wouldn't worry about this latest case, and in my
> > opinion, a fixed size of 512k is enough. Also, it's common now that
> > the first few blocks of NAND flash are guaranteed to be safe for the
> > first N erase cycles. So, I'm fine with the proposed fixed 512k for
> > SPL. Btw, good job.
>
> Okay, so next question is, does anyone rely on the default
> partitioning? If that's the case we're screwed because using something
> different will break things (UBI will be smaller than expected and
> complain that blocks are missing).
I don't rely on the default partitioning and the few people I know
also don't rely on it. I can't talk for everyone as is more than 3
year I left from the company that makes the IGEP, although I am pretty
sure nobody relies on it. That partioning is the most common, so my
suggestion is to go ahead and let's see if somebody complains.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [RESEND PATCH 1/4] omap3: igep00x0: Increase malloc() pool size
Hi Javier,
Many thanks for your patches. They look great
Missatge de Javier Martinez Canillas del dia
ds., 18 de maig 2024 a les 15:06:
>
> From: Javier Martinez Canillas
>
> The IGEPv2 board boot started to fail since the commit afd4f15a39de ("spi:
> omap3_spi: Read platform data in ofdata_to_platdata()"). Because this made
> the OMAP3 SPI controller driver to allocate its platform data before doing
> a relocation, but the igep0x00 config sets this pool size to just 1 KiB.
>
> Increase the pre-relocation malloc heap size to 16 KiB, as is set by other
> OMAP3 boards. This not only restores booting but also makes it consistent.
>
> Leave the SPL pool size to the previous 1 KiB size since 16 KiB may not be
> a possible size in that constrained environment and is also the value that
> is set by other OMAP3 boards.
>
> Signed-off-by: Javier Martinez Canillas
Reviewed-by: Enric Balletbo i Serra
> ---
>
> configs/igep00x0_defconfig | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/configs/igep00x0_defconfig b/configs/igep00x0_defconfig
> index 261f71acc1dd..e4d25556e3f3 100644
> --- a/configs/igep00x0_defconfig
> +++ b/configs/igep00x0_defconfig
> @@ -1,6 +1,6 @@
> CONFIG_ARM=y
> CONFIG_ARCH_OMAP2PLUS=y
> -CONFIG_SYS_MALLOC_F_LEN=0x400
> +CONFIG_SYS_MALLOC_F_LEN=0x4000
> CONFIG_TI_COMMON_CMD_OPTIONS=y
> CONFIG_NR_DRAM_BANKS=2
> CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> @@ -10,6 +10,7 @@ CONFIG_DEFAULT_DEVICE_TREE="omap3-igep0020"
> CONFIG_SPL_TEXT_BASE=0x4020
> CONFIG_TARGET_OMAP3_IGEP00X0=y
> CONFIG_SYS_MONITOR_LEN=262144
> +CONFIG_SPL_SYS_MALLOC_F_LEN=0x400
> CONFIG_SPL=y
> CONFIG_DISTRO_DEFAULTS=y
> CONFIG_BOOTDELAY=3
> --
> 2.45.0
>
Re: [RESEND PATCH 2/4] omap3: igep0x00: Drop unused SPI support
Hi Javier, Missatge de Javier Martinez Canillas del dia ds., 18 de maig 2024 a les 15:06: > > From: Javier Martinez Canillas > > There are no SPI peripherals in neither the IGEPv2 board nor the IGEP COM > Module, so there's no reason to have this enabled in the boards defconfig. > > Signed-off-by: Javier Martinez Canillas Reviewed-by: Enric Balletbo i Serra > --- > > configs/igep00x0_defconfig | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/configs/igep00x0_defconfig b/configs/igep00x0_defconfig > index e4d25556e3f3..6df6c33e25ab 100644 > --- a/configs/igep00x0_defconfig > +++ b/configs/igep00x0_defconfig > @@ -82,7 +82,4 @@ CONFIG_SYS_NAND_OOBSIZE=0x40 > CONFIG_SYS_NAND_BUSWIDTH_16BIT=y > CONFIG_MTD_UBI_FASTMAP=y > CONFIG_CONS_INDEX=3 > -CONFIG_SPI=y > -CONFIG_DM_SPI=y > -CONFIG_OMAP3_SPI=y > CONFIG_BCH=y > -- > 2.45.0 >
Re: [RESEND PATCH 3/4] omap3: igep0x00: Update for DM SPL support
Hi Javier,
Thanks for the patches.
Missatge de Javier Martinez Canillas del dia
ds., 18 de maig 2024 a les 15:06:
>
> From: Javier Martinez Canillas
>
> This change is heavily based on commit e0cc7df9fdf2 ("omap3_beagle: Update
> for DM SPL support"), that did the same update for the OMAP3 Beagle board.
>
> Signed-off-by: Javier Martinez Canillas
Reviewed-by: Enric Balletbo i Serra
> ---
>
> arch/arm/dts/omap3-igep0020-u-boot.dtsi | 14 ++
> board/isee/igep00x0/igep00x0.c | 12
> configs/igep00x0_defconfig | 17 -
> 3 files changed, 10 insertions(+), 33 deletions(-)
>
> diff --git a/arch/arm/dts/omap3-igep0020-u-boot.dtsi
> b/arch/arm/dts/omap3-igep0020-u-boot.dtsi
> index 41beaf0900c3..2c03701c896a 100644
> --- a/arch/arm/dts/omap3-igep0020-u-boot.dtsi
> +++ b/arch/arm/dts/omap3-igep0020-u-boot.dtsi
> @@ -5,20 +5,10 @@
> * (C) Copyright 2017 Derald D. Woods
> */
>
> +#include "omap3-u-boot.dtsi"
> +
> / {
> chosen {
> stdout-path = &uart3;
> };
> };
> -
> -&uart1 {
> - reg-shift = <2>;
> -};
> -
> -&uart2 {
> - reg-shift = <2>;
> -};
> -
> -&uart3 {
> - reg-shift = <2>;
> -};
> diff --git a/board/isee/igep00x0/igep00x0.c b/board/isee/igep00x0/igep00x0.c
> index 8a3f290f678f..a35a7cd3b1f7 100644
> --- a/board/isee/igep00x0/igep00x0.c
> +++ b/board/isee/igep00x0/igep00x0.c
> @@ -29,18 +29,6 @@
> #include
> #include "igep00x0.h"
>
> -static const struct ns16550_plat igep_serial = {
> - .base = OMAP34XX_UART3,
> - .reg_shift = 2,
> - .clock = V_NS16550_CLK,
> - .fcr = UART_FCR_DEFVAL,
> -};
> -
> -U_BOOT_DRVINFO(igep_uart) = {
> - "ns16550_serial",
> - &igep_serial
> -};
> -
> /*
> * Routine: get_board_revision
> * Description: GPIO_28 and GPIO_129 are used to read board and revision from
> diff --git a/configs/igep00x0_defconfig b/configs/igep00x0_defconfig
> index 6df6c33e25ab..c1b873a17efb 100644
> --- a/configs/igep00x0_defconfig
> +++ b/configs/igep00x0_defconfig
> @@ -1,4 +1,6 @@
> CONFIG_ARM=y
> +# CONFIG_SPL_USE_ARCH_MEMCPY is not set
> +# CONFIG_SPL_USE_ARCH_MEMSET is not set
> CONFIG_ARCH_OMAP2PLUS=y
> CONFIG_SYS_MALLOC_F_LEN=0x4000
> CONFIG_TI_COMMON_CMD_OPTIONS=y
> @@ -40,16 +42,7 @@ CONFIG_SPL_UBI_LEB_START=2048
> CONFIG_SPL_UBI_INFO_ADDR=0x8808
> CONFIG_SPL_UBI_VOL_IDS=8
> CONFIG_SPL_UBI_LOAD_MONITOR_ID=0
> -CONFIG_SPL_UBI_LOAD_KERNEL_ID=3
> -CONFIG_SPL_UBI_LOAD_ARGS_ID=4
> CONFIG_SPL_ONENAND_SUPPORT=y
> -CONFIG_SPL_OS_BOOT=y
> -CONFIG_SPL_PAYLOAD_ARGS_ADDR=0x8400
> -CONFIG_SYS_NAND_SPL_KERNEL_OFFS=0x28
> -CONFIG_SPL_FALCON_BOOT_MMCSD=y
> -CONFIG_SYS_MMCSD_RAW_MODE_KERNEL_SECTOR=0x1700
> -CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTOR=0x1500
> -CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTORS=0x200
> CONFIG_CMD_SPL=y
> CONFIG_CMD_NAND=y
> CONFIG_CMD_ONENAND=y
> @@ -59,7 +52,11 @@ CONFIG_CMD_CACHE=y
> CONFIG_CMD_MTDPARTS=y
> CONFIG_CMD_UBI=y
> # CONFIG_CMD_UBIFS is not set
> +# CONFIG_SPL_EFI_PARTITION is not set
> +CONFIG_SPL_PARTITION_UUIDS=y
> CONFIG_OF_CONTROL=y
> +CONFIG_SPL_OF_CONTROL=y
> +CONFIG_OF_SPL_REMOVE_PROPS="clocks clock-names interrupt-parent"
> CONFIG_ENV_OVERWRITE=y
> CONFIG_ENV_IS_IN_UBI=y
> CONFIG_SYS_REDUNDAND_ENVIRONMENT=y
> @@ -69,6 +66,7 @@ CONFIG_ENV_UBI_VOLUME_REDUND="config_r"
> CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> CONFIG_VERSION_VARIABLE=y
> # CONFIG_NET is not set
> +CONFIG_SPL_DM=y
> CONFIG_SYS_I2C_LEGACY=y
> CONFIG_SPL_SYS_I2C_LEGACY=y
> CONFIG_MMC_OMAP_HS=y
> @@ -81,5 +79,6 @@ CONFIG_SYS_NAND_PAGE_SIZE=0x800
> CONFIG_SYS_NAND_OOBSIZE=0x40
> CONFIG_SYS_NAND_BUSWIDTH_16BIT=y
> CONFIG_MTD_UBI_FASTMAP=y
> +CONFIG_SPECIFY_CONSOLE_INDEX=y
> CONFIG_CONS_INDEX=3
> CONFIG_BCH=y
> --
> 2.45.0
>
Re: [RESEND PATCH 4/4] omap3: igep0x00: Migrate to use upstream DT
Hi Javier,
Yay, many thanks for this change.
Missatge de Sumit Garg del dia dl., 20 de maig
2024 a les 12:20:
>
> On Sat, 18 May 2024 at 18:36, Javier Martinez Canillas
> wrote:
> >
> > From: Javier Martinez Canillas
> >
> > Enable OF_UPSTREAM to use upstream DT and add a ti/omap/ prefix to the
> > DEFAULT_DEVICE_TREE config option.
> >
> > That way, a DTS from the upstream dts/upstream/src/ directory is used
> > instead of the arch/$(ARCH)/dts/ directory. These in turn are removed.
> >
> > Signed-off-by: Javier Martinez Canillas
Reviewed-by: Enric Balletbo i Serra
> > ---
> >
> > arch/arm/dts/Makefile | 3 -
> > arch/arm/dts/omap3-igep.dtsi| 247 --
> > arch/arm/dts/omap3-igep0020-common.dtsi | 261
> > arch/arm/dts/omap3-igep0020.dts | 47 -
> > configs/igep00x0_defconfig | 3 +-
> > 5 files changed, 2 insertions(+), 559 deletions(-)
> > delete mode 100644 arch/arm/dts/omap3-igep.dtsi
> > delete mode 100644 arch/arm/dts/omap3-igep0020-common.dtsi
> > delete mode 100644 arch/arm/dts/omap3-igep0020.dts
> >
>
> Acked-by: Sumit Garg
>
> -Sumit
>
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > index a5c82ebf7a5f..a9bd4921718e 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -1030,9 +1030,6 @@ dtb-$(CONFIG_TARGET_OMAP3_BEAGLE) += \
> >
> > dtb-$(CONFIG_TARGET_DEVKIT8000) += omap3-devkit8000.dtb
> >
> > -dtb-$(CONFIG_TARGET_OMAP3_IGEP00X0) += \
> > - omap3-igep0020.dtb
> > -
> > dtb-$(CONFIG_TARGET_OMAP4_PANDA) += \
> > omap4-panda.dtb \
> > omap4-panda-es.dtb
> > diff --git a/arch/arm/dts/omap3-igep.dtsi b/arch/arm/dts/omap3-igep.dtsi
> > deleted file mode 100644
> > index 219202610463..
> > --- a/arch/arm/dts/omap3-igep.dtsi
> > +++ /dev/null
> > @@ -1,247 +0,0 @@
> > -// SPDX-License-Identifier: GPL-2.0-only
> > -/*
> > - * Common device tree for IGEP boards based on AM/DM37x
> > - *
> > - * Copyright (C) 2012 Javier Martinez Canillas
> > - * Copyright (C) 2012 Enric Balletbo i Serra
> > - */
> > -/dts-v1/;
> > -
> > -#include "omap36xx.dtsi"
> > -
> > -/ {
> > - memory@8000 {
> > - device_type = "memory";
> > - reg = <0x8000 0x2000>; /* 512 MB */
> > - };
> > -
> > - chosen {
> > - stdout-path = &uart3;
> > - };
> > -
> > - sound {
> > - compatible = "ti,omap-twl4030";
> > - ti,model = "igep2";
> > - ti,mcbsp = <&mcbsp2>;
> > - };
> > -
> > - vdd33: regulator-vdd33 {
> > - compatible = "regulator-fixed";
> > - regulator-name = "vdd33";
> > - regulator-always-on;
> > - };
> > -
> > -};
> > -
> > -&omap3_pmx_core {
> > - gpmc_pins: pinmux_gpmc_pins {
> > - pinctrl-single,pins = <
> > - /* OneNAND seems to require PIN_INPUT on clock. */
> > -OMAP3_CORE1_IOPAD(0x20be, PIN_INPUT | MUX_MODE0)
> > /* gpmc_clk.gpmc_clk */
> > - >;
> > - };
> > -
> > - uart1_pins: pinmux_uart1_pins {
> > - pinctrl-single,pins = <
> > - OMAP3_CORE1_IOPAD(0x2182, PIN_INPUT | MUX_MODE0)
> > /* uart1_rx.uart1_rx */
> > - OMAP3_CORE1_IOPAD(0x217c, PIN_OUTPUT | MUX_MODE0)
> > /* uart1_tx.uart1_tx */
> > - >;
> > - };
> > -
> > - uart3_pins: pinmux_uart3_pins {
> > - pinctrl-single,pins = <
> > - OMAP3_CORE1_IOPAD(0x219e, PIN_INPUT | MUX_MODE0)
> > /* uart3_rx.uart3_rx */
> > - OMAP3_CORE1_IOPAD(0x21a0, PIN_OUTPUT | MUX_MODE0)
> > /* uart3_tx.uart3_tx */
> > - >;
> > - };
> > -
> > - mcbsp2_pins: pinmux_mcbsp2_pins {
> > - pinctrl-single,pins = <
> > - OMAP3_CORE1_IOPAD(0x213c, PIN_INPUT | MUX_MODE0)
> > /* mcbsp2_fsx.mcbsp2_fsx */
> > - OMAP3_CORE1_IOPAD(0x213e, PIN_INPUT | MUX_MODE0)
> > /* mcbsp2_clkx.mcbsp2_clkx */
> > - OMAP3_CORE1_IOPAD(0x2140, PIN_INPUT | MUX_MODE0)
> > /* mcbsp2_dr.mcbsp2.dr */
> > - OMAP3_CORE1_IOPAD(0x2142, PIN_OUTPUT | MUX_MODE0)
> > /* mcbsp2_dx.mcbsp2_dx */
> > - >;
> > - };
> > -
> > - mmc1_pins: pinmux_mmc1_pins {
> > - pinctrl-single,pins = <
> > - OMAP3_CORE1_IOPAD(0x2144, PIN_INPUT_PULLUP |
> > MUX_MODE0) /* sdmmc1_clk.sdmmc1_clk */
> > - OMAP3_CORE1_IOPAD(0x2146, PIN_INPUT_PULLUP |
> > MUX_MODE0) /* sdmmc1_cmd.sdmmc1_cmd */
> > - OMAP3_CORE1_IOPAD(0x2148, PIN_INPUT_PULLUP |
> > MUX_MODE0) /* sdmmc1_dat0.sdmmc1_dat0 */
> > - OMAP3_CORE1_IOPAD(0x214a, PIN_INPUT_PULLUP |
