Re: [U-Boot] [PATCH 4/6] S5PC100: onenand driver for SMDKC100 support
Hi,
On Sat, Jun 27, 2009 at 2:54 AM, Scott Wood wrote:
> On Thu, Jun 25, 2009 at 05:10:37PM +0900, HeungJun Kim wrote:
>> This patch includes the onenand driver for SMDKC100 Board.
>>
>> Signed-off-by: HeungJun, Kim
>>
>> ---
>>
>> drivers/mtd/onenand/Makefile | 8 +-
>> drivers/mtd/onenand/s5p_onenand.c | 2034
>> +
>> include/linux/mtd/onenand_regs.h | 5 +
>> include/linux/mtd/s5p_onenand.h | 425
>
> Please try to refactor the existing onenand code to support controller
> variations, rather than duplicating parts of it.
>
> Or if you can find absolutely no common ground (but I hope you can), at
> least change the names so they don't conflict. Are you planning on
> supporting this in Linux? What is it going to look like there?
>
> Kyungmin, any thoughts? Why do we have a specific controller
> implementation in something generically named "onenand_base.c"? Or is
> this different because of a different type of onenand chip?
Right, I wrote the OneNAND drivers for s3c64xx/s5pc100 but now only
interface part are release at mtd & arm list.
The current status of this patch only *working* version. So I NAKed
this patch. next time Mr Kim will post the new OneNAND drivers
Thank you,
Kyungmin Park
>
> I don't understand OneNAND very well (and google doesn't turn up much but
> marketing), which makes including it under the same custodianship as NAND
> somewhat awkward. :-(
>
>> diff --git a/drivers/mtd/onenand/Makefile b/drivers/mtd/onenand/Makefile
>> index 1d35a57..aad1362 100644
>> --- a/drivers/mtd/onenand/Makefile
>> +++ b/drivers/mtd/onenand/Makefile
>> @@ -25,7 +25,13 @@ include $(TOPDIR)/config.mk
>>
>> LIB := $(obj)libonenand.a
>>
>> -COBJS-$(CONFIG_CMD_ONENAND) := onenand_uboot.o onenand_base.o onenand_bbt.o
>> +COBJS-$(CONFIG_CMD_ONENAND) := onenand_uboot.o
>> +
>> +ifdef CONFIG_S5PC1XX
>> +COBJS-$(CONFIG_CMD_ONENAND) += s5p_onenand.o
>> +else
>> +COBJS-$(CONFIG_CMD_ONENAND) += onenand_base.o onenand_bbt.o
>> +endif
>
> Why no bbt?
This driver checks the bad block at runtime at every access. :)
>
>> +/**
>> + * onenand_read_burst
>> + *
>> + * 16 Burst read: performance is improved up to 40%.
>> + */
>> +static void onenand_read_burst(void *dest, const void *src, size_t len)
>> +{
>> + int count;
>> +
>> + if (len % 16 != 0)
>> + return;
>> +
>> + count = len / 16;
>> +
>> + __asm__ __volatile__(
>> + " stmdb r13!, {r0-r3,r9-r12}\n"
>> + " mov r2, %0\n"
>> + "1:\n"
>> + " ldmia r1, {r9-r12}\n"
>> + " stmia r0!, {r9-r12}\n"
>> + " subs r2, r2, #0x1\n"
>> + " bne 1b\n"
>> + " ldmia r13!, {r0-r3,r9-r12}\n"::"r" (count));
>> +}
>
> What is this doing that we couldn't generically make memcpy do?
Even though It looks some strange. it has some performance gain. but
not general.
>
> -Scott
> ___
> 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
[U-Boot] help required urgently for usbtty support in uboot
Hi everyone, I'm working on USBTTY for uboot1.3.1 by adding my usb device code by setting the CONFIG_USB_TTY, CONFIG_USB_DEVICE and CFG_CONSOLE_IS_IN_ENV flags. Procedure 1)After booting the uboot with usbtty support, it will initialize my usb device with usbtty as cdc_acm device. 2)Then I have given the following commands setenv stderr usbtty; saveenv -working fine setenv stdin usbtty; setenv stdout usbtty;saveenv. After using this command, host windows PC not able to detect the cable. It stucks in console_setfile() function of common/console.c 3)But, if I do only the setenv stdin usbtty. USB Cable is detected as u-boot gadget on windows PC. From console_setfile() function of console.c, calling the getc() and tstc() functions of USBtty. I'm able to open the tera term with the new COM port. But I can't do any operations on this COM port. May be because of stdout is not set to usbtty. Please reply asap. Thanks for your support, Naveen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Flex-OneNAND driver merged to mainline kernel
Hi Scott.
Flex-OneNAND is merged to 2.6.31-rc1. I hope now
Flex-OneNAND can be merged to uboot.
We will rebase flex-OneNAND to uboot git.
- Original Message -
From: "Kyungmin Park"
To: "Scott Wood"
Cc:
Sent: Saturday, June 27, 2009 1:02 PM
Subject: Re: [U-Boot] [PATCH 4/6] S5PC100: onenand driver
for SMDKC100 support
Hi,
On Sat, Jun 27, 2009 at 2:54 AM, Scott
Wood wrote:
> On Thu, Jun 25, 2009 at 05:10:37PM +0900, HeungJun Kim
> wrote:
>> This patch includes the onenand driver for SMDKC100
>> Board.
>>
>> Signed-off-by: HeungJun, Kim
>>
>> ---
>>
>> drivers/mtd/onenand/Makefile | 8 +-
>> drivers/mtd/onenand/s5p_onenand.c | 2034
>> +
>> include/linux/mtd/onenand_regs.h | 5 +
>> include/linux/mtd/s5p_onenand.h | 425
>
> Please try to refactor the existing onenand code to
> support controller
> variations, rather than duplicating parts of it.
>
> Or if you can find absolutely no common ground (but I hope
> you can), at
> least change the names so they don't conflict. Are you
> planning on
> supporting this in Linux? What is it going to look like
> there?
>
> Kyungmin, any thoughts? Why do we have a specific
> controller
> implementation in something generically named
> "onenand_base.c"? Or is
> this different because of a different type of onenand
> chip?
Right, I wrote the OneNAND drivers for s3c64xx/s5pc100 but
now only
interface part are release at mtd & arm list.
The current status of this patch only *working* version. So
I NAKed
this patch. next time Mr Kim will post the new OneNAND
drivers
I did not get what is in New OneNAND drivers
Thank you,
Kyungmin Park
>
> I don't understand OneNAND very well (and google doesn't
> turn up much but
> marketing), which makes including it under the same
> custodianship as NAND
> somewhat awkward. :-(
>
>> diff --git a/drivers/mtd/onenand/Makefile
>> b/drivers/mtd/onenand/Makefile
>> index 1d35a57..aad1362 100644
>> --- a/drivers/mtd/onenand/Makefile
>> +++ b/drivers/mtd/onenand/Makefile
>> @@ -25,7 +25,13 @@ include $(TOPDIR)/config.mk
>>
>> LIB := $(obj)libonenand.a
>>
>> -COBJS-$(CONFIG_CMD_ONENAND) := onenand_uboot.o
>> onenand_base.o onenand_bbt.o
>> +COBJS-$(CONFIG_CMD_ONENAND) := onenand_uboot.o
>> +
>> +ifdef CONFIG_S5PC1XX
>> +COBJS-$(CONFIG_CMD_ONENAND) += s5p_onenand.o
>> +else
>> +COBJS-$(CONFIG_CMD_ONENAND) += onenand_base.o
>> onenand_bbt.o
>> +endif
>
> Why no bbt?
This driver checks the bad block at runtime at every access.
:)
>
>> +/**
>> + * onenand_read_burst
>> + *
>> + * 16 Burst read: performance is improved up to 40%.
>> + */
>> +static void onenand_read_burst(void *dest, const void
>> *src, size_t len)
>> +{
>> + int count;
>> +
>> + if (len % 16 != 0)
>> + return;
>> +
>> + count = len / 16;
>> +
>> + __asm__ __volatile__(
>> + " stmdb r13!, {r0-r3,r9-r12}\n"
>> + " mov r2, %0\n"
>> + "1:\n"
>> + " ldmia r1, {r9-r12}\n"
>> + " stmia r0!, {r9-r12}\n"
>> + " subs r2, r2, #0x1\n"
>> + " bne 1b\n"
>> + " ldmia r13!, {r0-r3,r9-r12}\n"::"r" (count));
>> +}
>
> What is this doing that we couldn't generically make
> memcpy do?
Even though It looks some strange. it has some performance
gain. but
not general.
Thanks
Amit
>
> -Scott
> ___
> 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
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-book and GPLv3? (fwd)
Detlev, Detlev Zundel schrieb: > Hi Jean-Christophe, > >> On 00:50 Fri 26 Jun , Richard Stallman wrote: ... >>> If you buy a car, or a medical tool for my own use, you deserve to be able >>> to change the software in it, just as you can change it physically. >> Certanly not when you use your car your are also on the public domain (road) >> so it your car have a system faillure you can kill yourself and kill other >> people. Remember that you are not allow to modify your car as your wish there >> is law that will forbiden you to do this in a lot' of country. > ... > > Of course you can modify your own car. This is *not* forbidden - why do > you claim such a thing? Heck you can even attach a rocket to it *as > long* as you don't use the car on public streets. If you do, all you > got to do is to get your modifications approved. No big deal, go to a > meeting and look at the cars there. > > I can even build my own car from scratch and get it certified. Maybe you are right. But for actually modifying safety critcal software (e.g. for airbag control, ABS/ESP control, not talking about break-by-wire/steer by wire systems) properly you will need MUCH more than the source code. You will need the requirements specifications, the SW design documentation, the test specifications. Wouldn't it make sense to add a paragraph to the GPL, stating that a company using GPL software in their system must also provide all that documentation to their customers? Only then the SW modification can be properly done? Don't forget that a proper test area is also needed, which can simulate all kind of street conditions. For ABS/Airbag you may also need a crash test environment including soem sample cars to try thigns out. Without access to these, you will not be able to prove proper system behaviour to the certification authorities. (set the irony tag wherever you find it suitable. Back to being earnest: I think the GPL is a very important license to generate open-source software and that the results on the SW quality are very significant. The switch to GPLv3 may make sense for many SW systems, mainly in the desktop/gadget area. Even the traditional industry has learned in the last few years, that open source software is nothing to be afraid of and that sharing the own general know how based on SW improvements is a benefit for all. But similar to the fact, that there is not ONE operating system fitting all needs and ONE SW package fitting all needs, there also is not ONE OS license, that fits to all requirements. So once again I think GPLv3 for U-Boot would avoid using it in many possible applications, which would be a loss for the project and its users. wkr, Thomas. -- Embedded Brains GmbH Thomas Doerfler Obere Lagerstr. 30 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18908079-2 Fax: +49-89-18908079-9 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-book and GPLv3? (fwd)
Detlev Zundel schrieb: > Hi Jean-Christophe, > >> On 00:50 Fri 26 Jun , Richard Stallman wrote: >>> If I use a GPLv3 bootloader in a medical tool, a car, Point of payment >>> terminal, >>> Military System, etc... it is a grave security flaw. >>> I'm not sure that you will be very happy if someone can modify the >>> Firmware >>> freely. As you may loose money to be killed and at the extrem kill >>> millions >>> of people. >>> >>> There is no need to exaggerate. Millions of people modify cars >>> physically, and it is not a dangerous practice. >> It is. >>> If you buy a car, or a medical tool for my own use, you deserve to be able >>> to change the software in it, just as you can change it physically. >> Certanly not when you use your car your are also on the public domain (road) >> so it your car have a system faillure you can kill yourself and kill other >> people. Remember that you are not allow to modify your car as your wish there >> is law that will forbiden you to do this in a lot' of country. > > It seems that you have very strong interests on the software side, which > need to be considered separately, but here you are really distorting > actual reality. As this example is likely best known to everybody, I'll > comment on this one - it seems currently too much work without a > prospect of any gain to comment on everything. > > Of course you can modify your own car. This is *not* forbidden - why do > you claim such a thing? Heck you can even attach a rocket to it *as > long* as you don't use the car on public streets. If you do, all you > got to do is to get your modifications approved. No big deal, go to a > meeting and look at the cars there. > > I can even build my own car from scratch and get it certified. > > Although I wanted to restrict myself to cars - it's the same with > planes. It is common practice for example to modify glider planes > (increasing wing span for example to be more competitive today) for > which the manufacturer even *does not exist* any more today. Admittedly > this is some work to get it certified, but it is doable by a private > person for sure, I personally know some. > > Actually I can even build my own *plane* and still get it certified > (this is not uncommon). > > Cheers > Detlev > -- Embedded Brains GmbH Thomas Doerfler Obere Lagerstr. 30 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18908079-2 Fax: +49-89-18908079-9 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] at91sam9260/9263: add back up fot the rst(reset controller).
On 10:32 Wed 24 Jun , Sedji Gaouaou wrote: > On the boards at91sam9260ek, at91sam9263ek and afed9260, the rstc register > was set to 0 after being set to 500 ms for the PHY reset. > Do backup the old reset length and restore it after the MACB initialisation. > > Signed-off-by: Sedji Gaouaou > --- > board/afeb9260/afeb9260.c |6 +- > board/atmel/at91sam9260ek/at91sam9260ek.c |6 +- > board/atmel/at91sam9263ek/at91sam9263ek.c |6 +- > 3 files changed, 15 insertions(+), 3 deletions(-) applied to u-boot-arm Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3][repost] nand: Add Marvell Kirkwood NAND driver
On 00:32 Fri 26 Jun , Prafulla Wadaskar wrote: > > > > -Original Message- > > From: Scott Wood [mailto:scottw...@freescale.com] > > Sent: Tuesday, June 23, 2009 3:35 AM > > To: Prafulla Wadaskar > > Cc: u-boot@lists.denx.de; Ashish Karkare; Prabhanjan Sarnaik; > > Ronen Shitrit > > Subject: Re: [U-Boot] [PATCH v2 1/3][repost] nand: Add > > Marvell Kirkwood NAND driver > > > > On Sun, Jun 14, 2009 at 10:32:47PM +0530, Prafulla Wadaskar wrote: > > > diff --git a/drivers/mtd/nand/kirkwood_nand.c > > > b/drivers/mtd/nand/kirkwood_nand.c > > > new file mode 100644 > > > index 000..9cdbe20 > > > --- /dev/null > > > +++ b/drivers/mtd/nand/kirkwood_nand.c > > > @@ -0,0 +1,81 @@ > > > +/* > > > + * Copyright (C) Marvell International Ltd. and its affiliates > > > > No year? > > > > > +#include > > > +#include > > > +#include > > > +#include > > > > I don't see kirkwood.h in upstream, so I guess this should go > > via an arch tree. > Hi Jean, > Similar to spi driver, can you please pull this driver too? > I am posting the new spin for suggested modification > please fix the year and I will Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] arm: add usb-phy init support for Kirkwood SoCs
On 00:50 Wed 24 Jun , Prafulla Wadaskar wrote: > On kirkwood by default USB PHY is disabled > and from Linux-2.6.29 onward, phy_version for kirkwood platforms > are programmed to EHCI_PHY_NA, expecting such platform specific > setup should be done by boot loader > > This patch provides arch specific requirement for usb-phy init > Nicolas could you explain why the kernel require such init in the boot loader? Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH/RFC] Support HSMMC2 and 3 on OMAP3.
Hi Hugo Vincent,
2009/6/27 Hugo Vincent :
> Adds support for the second and third HSMMC controllers on OMAP3 SoCs.
>
> Tested working on Gumstix Overo with a custom base-board containing
> external SD/MMC slots.
>
> Signed-off-by: Hugo Vincent
>
> diff --git a/board/omap3/overo/overo.h b/board/omap3/overo/overo.h
> index 4c06e6e..84c09da 100644
> --- a/board/omap3/overo/overo.h
> +++ b/board/omap3/overo/overo.h
> @@ -292,7 +292,7 @@ const omap3_sysinfo sysinfo = {
> MUX_VAL(CP(SYS_OFF_MODE), (IEN | PTD | DIS | M0)) /*SYS_OFF_MODE*/\
> MUX_VAL(CP(SYS_CLKOUT1), (IEN | PTD | DIS | M0)) /*SYS_CLKOUT1*/\
> MUX_VAL(CP(SYS_CLKOUT2), (IEN | PTU | EN | M4)) /*GPIO_186*/\
> - MUX_VAL(CP(ETK_CLK_ES2), (IDIS | PTU | EN | M2)) /*MMC3_CLK*/\
> + MUX_VAL(CP(ETK_CLK_ES2), (IEN | PTU | EN | M2)) /*MMC3_CLK*/\
> MUX_VAL(CP(ETK_CTL_ES2), (IEN | PTU | EN | M2)) /*MMC3_CMD*/\
> MUX_VAL(CP(ETK_D0_ES2), (IEN | PTU | EN | M4)) /*GPIO_14*/\
> MUX_VAL(CP(ETK_D1_ES2), (IEN | PTD | EN | M4)) /*GPIO_15 -
> X_GATE*/\
> diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c
> index 039fe59..7b99603 100644
> --- a/common/cmd_mmc.c
> +++ b/common/cmd_mmc.c
> @@ -65,11 +65,10 @@ int do_mmc (cmd_tbl_t *cmdtp, int flag, int argc,
> char *argv[])
> }
> } else if (argc == 3) {
> dev = (int)simple_strtoul(argv[2], NULL, 10);
> -
> -#ifdef CONFIG_SYS_MMC_SET_DEV
> - if (mmc_set_dev(dev) != 0)
> + if (mmc_legacy_init(dev) != 0) {
> + puts("No MMC card found\n");
> return 1;
> -#endif
> + }
> curr_device = dev;
> } else {
> cmd_usage(cmdtp);
why you reinit at "mmc device" command.
If you want to device init and device selecting at one time.
you can use mmc init command
e.g: # mmc init
> diff --git a/drivers/mmc/omap3_mmc.c b/drivers/mmc/omap3_mmc.c
> index 234fddf..a53fc3e 100644
> --- a/drivers/mmc/omap3_mmc.c
> +++ b/drivers/mmc/omap3_mmc.c
> @@ -50,12 +50,15 @@ const unsigned short mmc_transspeed_val[15][4] = {
> };
>
> mmc_card_data cur_card_data;
> -static block_dev_desc_t mmc_blk_dev;
> -static hsmmc_t *mmc_base = (hsmmc_t *)OMAP_HSMMC_BASE;
> +static block_dev_desc_t mmc_blk_dev[3];
> +static hsmmc_t *mmc_base = (hsmmc_t *)OMAP_HSMMC_BASE1;
>
> block_dev_desc_t *mmc_get_dev(int dev)
> {
> - return (block_dev_desc_t *) &mmc_blk_dev;
> + if (dev >= 1 && dev <= 3)
> + return (block_dev_desc_t *) &mmc_blk_dev[dev-1];
> + else
> + return NULL;
> }
>
> void twl4030_mmc_config(void)
> @@ -135,7 +138,8 @@ unsigned char mmc_init_setup(void)
> {
> unsigned int reg_val;
>
> - mmc_board_init();
> + if (mmc_get_dev_id() == 1)
> + mmc_board_init();
do not need to init for mmc2/3 about VMMC and devconf?
>
> writel(readl(&mmc_base->sysconfig) | MMC_SOFTRESET,
> &mmc_base->sysconfig);
> @@ -528,23 +532,58 @@ unsigned long mmc_bread(int dev_num, unsigned
> long blknr, lbaint_t blkcnt,
> return 1;
> }
>
> -int mmc_legacy_init(int verbose)
> +int mmc_legacy_init(int dev)
> {
> + mmc_set_dev_id(dev);
> if (configure_mmc(&cur_card_data) != 1)
> return 1;
>
> - mmc_blk_dev.if_type = IF_TYPE_MMC;
> - mmc_blk_dev.part_type = PART_TYPE_DOS;
> - mmc_blk_dev.dev = 0;
> - mmc_blk_dev.lun = 0;
> - mmc_blk_dev.type = 0;
> + block_dev_desc_t *mmcdev = mmc_get_dev(dev);
> + if (mmcdev == NULL)
> + return 1;
> +
> + mmcdev->if_type = IF_TYPE_MMC;
> + mmcdev->part_type = PART_TYPE_DOS;
> + mmcdev->dev = dev;
> + mmcdev->lun = 0;
> + mmcdev->type = 0;
>
> /* FIXME fill in the correct size (is set to 32MByte) */
> - mmc_blk_dev.blksz = MMCSD_SECTOR_SIZE;
> - mmc_blk_dev.lba = 0x1;
> - mmc_blk_dev.removable = 0;
> - mmc_blk_dev.block_read = mmc_bread;
> + mmcdev->blksz = MMCSD_SECTOR_SIZE;
> + mmcdev->lba = 0x1;
> + mmcdev->removable = 0;
> + mmcdev->block_read = mmc_bread;
>
> - fat_register_device(&mmc_blk_dev, 1);
> + fat_register_device(mmcdev, 1);
> return 0;
> }
> +
> +int mmc_set_dev_id(int devnum)
> +{
> + switch (devnum)
> + {
> + case 1:
> + mmc_base = (hsmmc_t *)OMAP_HSMMC_BASE1;
> + return 0;
> + case 2:
> + mmc_base = (hsmmc_t *)OMAP_HSMMC_BASE2;
> + return 0;
> + case 3:
> + mmc_base = (hsmmc_t *)OMAP_HSMMC_BASE3;
> + return 0;
> + default:
> + return 1;
> + }
> +}
> +
please check the style
> +int mmc_get_dev_id()
> +{
> +
Re: [U-Boot] [PATCH 1/2] arm: add usb-phy init support for Kirkwood SoCs
On Sat, 27 Jun 2009, Jean-Christophe PLAGNIOL-VILLARD wrote: > On 00:50 Wed 24 Jun , Prafulla Wadaskar wrote: > > On kirkwood by default USB PHY is disabled > > and from Linux-2.6.29 onward, phy_version for kirkwood platforms > > are programmed to EHCI_PHY_NA, expecting such platform specific > > setup should be done by boot loader > > > > This patch provides arch specific requirement for usb-phy init > > > Nicolas could you explain why the kernel require such init in the boot > loader? No particular reason other than the fact that no one made a patch for the kernel yet. Nicolas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] arm: add usb-phy init support for Kirkwood SoCs
On 13:11 Sat 27 Jun , Nicolas Pitre wrote: > On Sat, 27 Jun 2009, Jean-Christophe PLAGNIOL-VILLARD wrote: > > > On 00:50 Wed 24 Jun , Prafulla Wadaskar wrote: > > > On kirkwood by default USB PHY is disabled > > > and from Linux-2.6.29 onward, phy_version for kirkwood platforms > > > are programmed to EHCI_PHY_NA, expecting such platform specific > > > setup should be done by boot loader > > > > > > This patch provides arch specific requirement for usb-phy init > > > > > Nicolas could you explain why the kernel require such init in the boot > > loader? > > No particular reason other than the fact that no one made a patch for > the kernel yet. tks Prafulla, U-Boot is supposed to init the usb only if it use it so init it by default is not correct. Please fix it. Btw it will be nice to fix the kernel too Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-book and GPLv3? (fwd)
On 17:35 Fri 26 Jun , Richard Stallman wrote: > > The other systems that you speak of are not consumer products, so this > > requirement in GPLv3 does not apply to them. > in a Point of payment terminal it does not apply are sure? > > I am sure. Those are not consumer products. They are made for > businesses only. Wrong, as example your cell phone can be a part of the PPT, and your also have product on the market that allow you to use a PPT at home instead of just write your credit card number on a website. So your definition of consumer produts is dangerous and will not fit at all because you can not known what we can create > > You seem to be worried about something you haven't described clearly. > > I think you're afraid of shadows, but since you have not described > > them clearly, I really don't know. > as example with the v3 you force me to give you my private key that I use > to protect the product this is not acceptable > > To deny the key to the user is not acceptable. It makes the software > non-free, and gives the developer power over the user that nobody > should have. Certanly not, it will make the product not hackable certanly not the software non-free. Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-book and GPLv3? (fwd)
> - medical equipment: Think what nice features could be implemented into > these many machines located in the emergency room... Accessible to any > person who comes by. > > Being free to change your copy of a program does not mean you must let > anyone and everyone change your copy. For instance, the code on my > netbook is all free software, but it is not generally accessible to > anyone but me. none of your scenarios are applicable to the issues Thomas raised. My argument shows that his scenario is unrealistic in supposing that "any person who comes by" can change the software in computers in the hospital. If the hospital has the key to install modified software, "any person who comes by" will not know the key. Even most of the staff will not know it. There probably are ways that people could sabotage the equipment if they were determined to do so. Physically, that is. A person with experience in servicing these machines could find a way to make them work wrong but not obviously wrong in a couple of minutes. Computers don't change the situation. It makes no sense to demand a double set of bars over the window while ignoring the flimsy door with a weak lock. Therefore, there is no real issue with these medical devices. But even if there were, the requirement for installation information in GPLv3 does not apply to products specifically for hospitals, since they are not consumer products. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-book and GPLv3? (fwd)
then i guess since u-boot is already doing what is right, this thread is a = big=20 waste of time I hope the main developers of U-Boot will conclude that it is right to move to GPLv3. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-book and GPLv3? (fwd)
> > and this is why i dislike the GPLv3. the GPLv2 was all about the source, so > the conversation between developers and everyone else was "you can take my > source and modify it all you want, but i want to see the changes". sounds > fair. > > GPLv3 (ignoring the fix for the loophole with web applications) adds > *nothing* > to this premise. instead, it's used as an ideological club such that the > conversation is now "i have all these ideas about how software should and > shouldnt be utilized, so if you want to use my software, you too now have to > subscribe to my way of thinking and you have to show me the changes". > > so what does moving from GPLv2 to GPLv3 gain us in terms of protections ? > nothing. it does however allow us to restrict the people who want to use u- > boot to using it in only ways we've "blessed". that's plain wrong in my eyes > and none of our business in the first place. > > > I think it is not a coincidence that devices which can be updated with > > arbitrary firmware sells pretty good in the meantime. Who buys routers > > capable of running OpenWRT because of their original firmware? > > then let your wallet/politicians do the talking. i certainly do -- i avoid > purchasing any music/games encumbered with DRM, or companies that employ such > methods. but i'm above going around and forcing people to think the way i do > with licenses. agreed with Mike. Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3 pandora: update pin mux for rev3 boards
On 11:43 Fri 26 Jun , Grazvydas Ignotas wrote: > On Fri, Jun 26, 2009 at 12:59 AM, Jean-Christophe > PLAGNIOL-VILLARD wrote: > > On 14:57 Mon 08 Jun , Grazvydas Ignotas wrote: > >> The update consists of following changes: > >> - remove configuration of not connected pins, effectively > >> leaving them in safe mode. > >> - remove unused GPIOs, setup newly added ones. > >> - setup pulls for various GPIOs. Disable pulls for game > >> buttons, as they have external pulls. > >> - SDRC CS change based on recent patch for > >> Beagle and Overo. > >> > >> Old boards are no longer supported, but there was only > >> small number of test boards made. Updated configuration > >> is expected to be used for mass production. > > If user have old version in possession NACK > > There are only several old prototypes some developers have, there is > really no need to complicate code to support those boards. The old > boards will be replaced anyway as they don't fit into the case. If only one active user have the board we need to support it > > > this kind of huge update is non bisectable > > Yes but current boards don't even work with what is in mainline, so it > doesn't make much sense to bisect anyway. > > > so we do need to use a true mux api > > as the kernel lot's of other arch in u-boot > > You could be right, but I don't think I can contribute this at the > moment. Current mux api is good enough for single configuration we > need. no it's a mess to use and manage and duplicate code Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3 pandora: update pin mux for rev3 boards
On 19:12 Thu 25 Jun , Jason Kridner wrote: >On Thu, Jun 25, 2009 at 4:59 PM, Jean-Christophe PLAGNIOL-VILLARD > wrote: > > On 14:57 Mon 08 Jun , Grazvydas Ignotas wrote: > > The update consists of following changes: > > - remove configuration of not connected pins, effectively > > leaving them in safe mode. > > - remove unused GPIOs, setup newly added ones. > > - setup pulls for various GPIOs. Disable pulls for game > > buttons, as they have external pulls. > > - SDRC CS change based on recent patch for > > Beagle and Overo. > > > > Old boards are no longer supported, but there was only > > small number of test boards made. Updated configuration > > is expected to be used for mass production. > If user have old version in possession NACK > >I believe no users who would possibly object have the old version (or any >version) in possession. Only the core developers ever got these boards. >Is the expectation to create #ifdef or some sort of auto-detection >(unlikely possible)? untill the hardware will be really not anymore use yes please > > > this kind of huge update is non bisectable so we do need to use a true > mux api > as the kernel lot's of other arch in u-boot > >Why is it not bisectable? because your mix cleanup, fixup and new board support > >Do you have a "true mux api" to suggest? the same as the kernel one is the best for code sharing Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4 v2] arm nomadik: use 1000 as HZ value and rewrite timer code
On 11:19 Mon 22 Jun , Alessandro Rubini wrote:
> From: Alessandro Rubini
>
> This sets CONFIG_SYS_HZ to 1000 as required, and completely rewrites
> timer code, which is now both correct and much smaller. Unused
> functions like udelay_masked() have been removed as no driver uses
> them, even the ones that are not currently active for this board.
>
> Signed-off-by: Alessandro Rubini
> Acked-by: Andrea Gallo
for the record what is its precision now?
> ---
> cpu/arm926ejs/nomadik/timer.c | 190 +++-
> include/configs/nhk8815.h |2 +-
> 2 files changed, 53 insertions(+), 139 deletions(-)
>
> diff --git a/cpu/arm926ejs/nomadik/timer.c b/cpu/arm926ejs/nomadik/timer.c
> index 2870d24..3618c4a 100644
> --- a/cpu/arm926ejs/nomadik/timer.c
> +++ b/cpu/arm926ejs/nomadik/timer.c
> @@ -1,20 +1,5 @@
> /*
> - * (C) Copyright 2003
> - * Texas Instruments
> - *
> - * (C) Copyright 2002
> - * Sysgo Real-Time Solutions, GmbH
> - * Marius Groeger
> - *
> - * (C) Copyright 2002
> - * Sysgo Real-Time Solutions, GmbH
> - * Alex Zuepke
> - *
> - * (C) Copyright 2002-2004
> - * Gary Jennejohn, DENX Software Engineering,
> - *
> - * (C) Copyright 2004
> - * Philippe Robin, ARM Ltd.
> + * (C) Copyright 2009 Alessandro Rubini
> *
> * See file CREDITS for list of people who contributed to this
> * project.
> @@ -38,145 +23,74 @@
> #include
> #include
>
> -#define TIMER_LOAD_VAL 0x
> +/*
> + * Registers in the MTU block -- same as in linux
so please simply import it
> +*/
> +
> +#define MTU_IMSC 0x00/* Interrupt mask set/clear */
> +#define MTU_RIS 0x04/* Raw interrupt status */
> +#define MTU_MIS 0x08/* Masked interrupt status */
> +#define MTU_ICR 0x0C/* Interrupt clear register */
> +
> +/* per-timer registers take 0..3 as argument */
> +#define MTU_LR(x)(0x10 + 0x10 * (x) + 0x00) /* Load value */
> +#define MTU_VAL(x) (0x10 + 0x10 * (x) + 0x04) /* Current value */
> +#define MTU_CR(x)(0x10 + 0x10 * (x) + 0x08) /* Control reg */
> +#define MTU_BGLR(x) (0x10 + 0x10 * (x) + 0x0c) /* At next overflow */
> +
> +/* bits for the control register */
> +#define MTU_CRn_ENA 0x80
> +#define MTU_CRn_PERIODIC 0x40/* if 0 = free-running */
> +#define MTU_CRn_PRESCALE_MASK0x0c
> +#define MTU_CRn_PRESCALE_1 0x00
> +#define MTU_CRn_PRESCALE_16 0x04
> +#define MTU_CRn_PRESCALE_256 0x08
> +#define MTU_CRn_32BITS 0x02
> +#define MTU_CRn_ONESHOT 0x01/* if 0 = wraps reloading from
> BGLR*/
>
> -/* macro to read the 32 bit timer */
> -#define READ_TIMER readl(CONFIG_SYS_TIMERBASE + 20)
>
> -static ulong timestamp;
> -static ulong lastdec;
> +/*
> + * The timer is a decrementer, we'll left it free running at 2.4MHz.
> + * We have 2.4 ticks per microsecond and an overflow in almost 30min
> + */
> +#define TIMER_CLOCK (24*100*1000)
> +#define COUNT_TO_USEC(x) ((x)*5/12) /* overflows at 6min */
please add space before and after */
> +#define USEC_TO_COUNT(x) ((x)*12/5) /* overflows at 6min */
> +#define TICKS_PER_HZ (TIMER_CLOCK/CONFIG_SYS_HZ)
> +#define TICKS_TO_HZ(x) ((x)/TICKS_PER_HZ)
> +
> +/* macro to read the 32 bit timer: since it decrements, we invert read value
> */
> +#define READ_TIMER() (~readl(CONFIG_SYS_TIMERBASE + MTU_VAL(0)))
>
> -/* nothing really to do with interrupts, just starts up a counter. */
> +/* Configure a free-running, auto-wrap counter with no prescaler */
> int timer_init(void)
> {
> - /* Load timer with initial value */
> - writel(TIMER_LOAD_VAL, CONFIG_SYS_TIMERBASE + 16);
> -
> - /*
> - * Set timer to be enabled, free-running, no interrupts, 256 divider,
> - * 32-bit, wrap-mode
> - */
> - writel(0x8a, CONFIG_SYS_TIMERBASE + 24);
> -
> - /* init the timestamp and lastdec value */
> - reset_timer_masked();
> -
> + writel(MTU_CRn_ENA | MTU_CRn_PRESCALE_1 | MTU_CRn_32BITS,
> +CONFIG_SYS_TIMERBASE + MTU_CR(0));
> + reset_timer();
> return 0;
> }
>
> -/*
> - * timer without interrupts
> - */
> +/* Restart counting from 0 */
> void reset_timer(void)
> {
> - reset_timer_masked();
> + writel(0, CONFIG_SYS_TIMERBASE + MTU_LR(0)); /* Immediate effect */
> }
>
> +/* Return how many HZ passed since "base" */
> ulong get_timer(ulong base)
> {
> - return get_timer_masked() - base;
> -}
> -
> -void set_timer(ulong t)
> -{
> - timestamp = t;
> + ulong res = TICKS_TO_HZ(READ_TIMER()) - base;
please return directly
> + return res;
> }
>
Best Regards,
J.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] at91: Add esd gmbh MEESC board support
On 12:21 Tue 23 Jun , Daniel Gorsulowski wrote:
> This patch adds support for esd gmbh MEESC board.
> The MEESC is based on an Atmel AT91SAM9263 SoC.
>
> Signed-off-by: Daniel Gorsulowski
> ---
>
> Jean-Christophe: This patch requires an up-to-date mach-types.h,
> please sync it.
>
> diff --git a/board/esd/meesc/meesc.c b/board/esd/meesc/meesc.c
> new file mode 100644
> index 000..557a51c
> --- /dev/null
> +++ b/board/esd/meesc/meesc.c
> @@ -0,0 +1,211 @@
> +/*
> + * (C) Copyright 2007-2008
> + * Stelian Pop
> + * Lead Tech Design
> + *
> + * (C) Copyright 2009
> + * Daniel Gorsulowski
> + * esd electronic system design gmbh
> + *
> + * 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
please use
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +/*
> + * Miscelaneous platform dependent initialisations
> + */
it will be better to only read it only and store it in a static
> +int get_hw_rev(void)
> +{
> + int rev = at91_get_gpio_value(AT91_PIN_PB19);
please add an empty line
> + rev |= at91_get_gpio_value(AT91_PIN_PB20) << 1;
> + rev |= at91_get_gpio_value(AT91_PIN_PB21) << 2;
> + rev |= at91_get_gpio_value(AT91_PIN_PB22) << 3;
> +
> + if (rev == 15)
> + rev = 0;
> +
> + return rev;
> +}
> +
> +
> +int checkboard(void)
> +{
> + char str[32];
> + char buf[32];
> +
> + puts("Board: esd CAN-EtherCAT Gateway");
> + if (getenv_r("serial#", str, sizeof(str)) > 0) {
> + puts(", serial# ");
> + puts(str);
> + }
> + printf("\nHardware-revision: 1.%d\n", get_hw_rev());
> + printf("Crystal frequency:\t%8s MHz\n",
> + strmhz(buf, get_main_clk_rate()));
> + printf("CPU clock:\t\t%8s MHz\n",
> + strmhz(buf, get_cpu_clk_rate()));
> +#ifdef CONFIG_SHOW_VERBOSE_CLOCKINFO
> + printf("Master clock:\t\t%8s MHz\n",
> + strmhz(buf, get_mck_clk_rate()));
> + printf("PLL A clock:\t\t%8s MHz\n",
> + strmhz(buf, get_plla_clk_rate()));
> + printf("PLL B Reg.:\t\t0x%08X\n",
> + at91_sys_read(AT91_CKGR_PLLBR));
> + printf("PLL B clock:\t\t%8s MHz\n",
> + strmhz(buf, get_pllb_clk_rate()));
> +#endif
> + printf("Mach-type: %lu\n", gd->bd->bi_arch_number);
> + return 0;
> +}
please use cpu_info when it's possible to avoid copy & paste
> +int board_init(void)
> +{
> + /* Enable Ctrlc */
> + console_init_f();
no need
> +
> + /* Peripheral Clock Enable Register */
> + at91_sys_write(AT91_PMC_PCER, 1 << AT91SAM9263_ID_PIOA |
> + 1 << AT91SAM9263_ID_PIOB |
> + 1 << AT91SAM9263_ID_PIOCDE |
> + 1 << AT91SAM9263_ID_CAN);
> +
> + /* arch number of MEESC-Board */
> + gd->bd->bi_arch_number = MACH_TYPE_MEESC;
> +
> + /* adress of boot parameters */
> + gd->bd->bi_boot_params = PHYS_SDRAM + 0x100;
> +
> + at91_serial_hw_init();
> +#ifdef CONFIG_CMD_NAND
> + meesc_nand_hw_init();
> +#endif
> + meesc_ethercat_hw_init();
> +#ifdef CONFIG_HAS_DATAFLASH
> + at91_spi0_hw_init(1 << 0);
> +#endif
> +#ifdef CONFIG_MACB
> + meesc_macb_hw_init();
> +#endif
> + at91_set_A_periph(AT91_PIN_PA13, 0);/* CAN_TX */
> + at91_set_A_periph(AT91_PIN_PA14, 1);/* CAN_RX */
please add a at91_can_hw_init function
> + return 0;
> +}
> +
> +#ifndef __CONFIG_H
> +#define __CONFIG_H
> +
> +/* Common stuff */
> +#define AT91_CPU_NAME"AT91SAM9263"
please remove
> +#define CONFIG_SYS_HZ1000/* decrementer freq */
> +#define CONFIG_MEESC 1 /* Board is esd MEESC */
> +#define CONFIG_ARM926EJS 1 /* This is an ARM926EJS Core */
> +#define CONFIG_AT91SAM9263 1 /* It's an AT91SAM9263 SoC */
> +#define CONFIG_ENV_OVERWRITE 1
Re: [U-Boot] U-book and GPLv3? (fwd)
On Sat, 27 Jun 2009, Jean-Christophe PLAGNIOL-VILLARD wrote: > > > > and this is why i dislike the GPLv3. the GPLv2 was all about the > source, so > > the conversation between developers and everyone else was "you can > take my > > source and modify it all you want, but i want to see the changes". > sounds > > fair. > > > > GPLv3 (ignoring the fix for the loophole with web applications) adds > *nothing* > > to this premise. instead, it's used as an ideological club such that > the > > conversation is now "i have all these ideas about how software should > and > > shouldnt be utilized, so if you want to use my software, you too now > have to > > subscribe to my way of thinking and you have to show me the changes". > > > > so what does moving from GPLv2 to GPLv3 gain us in terms of > protections ? > > nothing. it does however allow us to restrict the people who want to > use u- > > boot to using it in only ways we've "blessed". that's plain wrong in > my eyes > > and none of our business in the first place. > > > > > I think it is not a coincidence that devices which can be updated > with > > > arbitrary firmware sells pretty good in the meantime. Who buys > routers > > > capable of running OpenWRT because of their original firmware? > > > > then let your wallet/politicians do the talking. i certainly do -- i > avoid > > purchasing any music/games encumbered with DRM, or companies that > employ such > > methods. but i'm above going around and forcing people to think the > way i do > > with licenses. > agreed with Mike. Second that. --- ** * k...@homeKOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ** ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Kernel patch for CONFIG_LOGBUFFER
Hi, I'm looking for a working patch for the Linux kernel 2.6.28.8 that would allow using CONFIG_LOGBUFFER (a kernel log buffer shared between U-Boot and the kernel). I'm using u-boot 1.3.3. When LOGBUFFER is enabled in the kernel configuration the kernel build fails with: kernel/built-in.o: In function `setup_ext_logbuff': : undefined reference to `setup_ext_logbuff_mem' Could anybody also tell me how the buffer location (I think the size is fixed to 16K) is communicated to the kernel, via a kernel command line parameter? If so, what is it? Thanks, Serguei The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] Support HSMMC2 and 3 on OMAP3
Adds support for the second and third HSMMC controllers on OMAP3 SoCs.
Tested working on Gumstix Overo with a custom base-board containing
external SD/MMC slots.
Version 2 incorporating changes suggested by Minkyu Kang
Signed-off-by: Hugo Vincent
diff --git a/board/omap3/overo/overo.h b/board/omap3/overo/overo.h
index 4c06e6e..84c09da 100644
--- a/board/omap3/overo/overo.h
+++ b/board/omap3/overo/overo.h
@@ -292,7 +292,7 @@ const omap3_sysinfo sysinfo = {
MUX_VAL(CP(SYS_OFF_MODE),(IEN | PTD | DIS | M0)) /*SYS_OFF_MODE*/\
MUX_VAL(CP(SYS_CLKOUT1), (IEN | PTD | DIS | M0)) /*SYS_CLKOUT1*/\
MUX_VAL(CP(SYS_CLKOUT2), (IEN | PTU | EN | M4)) /*GPIO_186*/\
- MUX_VAL(CP(ETK_CLK_ES2), (IDIS | PTU | EN | M2)) /*MMC3_CLK*/\
+ MUX_VAL(CP(ETK_CLK_ES2), (IEN | PTU | EN | M2)) /*MMC3_CLK*/\
MUX_VAL(CP(ETK_CTL_ES2), (IEN | PTU | EN | M2)) /*MMC3_CMD*/\
MUX_VAL(CP(ETK_D0_ES2), (IEN | PTU | EN | M4)) /*GPIO_14*/\
MUX_VAL(CP(ETK_D1_ES2), (IEN | PTD | EN | M4)) /*GPIO_15 -
X_GATE*/\
diff --git a/drivers/mmc/omap3_mmc.c b/drivers/mmc/omap3_mmc.c
index 234fddf..813839b 100644
--- a/drivers/mmc/omap3_mmc.c
+++ b/drivers/mmc/omap3_mmc.c
@@ -50,12 +50,15 @@ const unsigned short mmc_transspeed_val[15][4] = {
};
mmc_card_data cur_card_data;
-static block_dev_desc_t mmc_blk_dev;
-static hsmmc_t *mmc_base = (hsmmc_t *)OMAP_HSMMC_BASE;
+static block_dev_desc_t mmc_blk_dev[3];
+static hsmmc_t *mmc_base = (hsmmc_t *)OMAP_HSMMC_BASE1;
block_dev_desc_t *mmc_get_dev(int dev)
{
- return (block_dev_desc_t *) &mmc_blk_dev;
+ if (dev >= 1 && dev <= 3)
+ return (block_dev_desc_t *) &mmc_blk_dev[dev-1];
+ else
+ return NULL;
}
void twl4030_mmc_config(void)
@@ -75,14 +78,22 @@ unsigned char mmc_board_init(void)
{
t2_t *t2_base = (t2_t *)T2_BASE;
- twl4030_mmc_config();
+ /*
+* Power and transceiver setup for MMC controllers other than the
first
+* differs between OMAP3xxx implementations. On at least Gumstix
Overo,
+* no setup is required. FIXME HSMMC2 may require MMCSDIO2ADPCLKISEL
+*/
+ if (mmc_get_dev_id() == 1)
+ {
+ twl4030_mmc_config();
- writel(readl(&t2_base->pbias_lite) | PBIASLITEPWRDNZ1 |
- PBIASSPEEDCTRL0 | PBIASLITEPWRDNZ0,
- &t2_base->pbias_lite);
+ writel(readl(&t2_base->pbias_lite) | PBIASLITEPWRDNZ1 |
+ PBIASSPEEDCTRL0 | PBIASLITEPWRDNZ0,
+ &t2_base->pbias_lite);
- writel(readl(&t2_base->devconf0) | MMCSDIO1ADPCLKISEL,
- &t2_base->devconf0);
+ writel(readl(&t2_base->devconf0) | MMCSDIO1ADPCLKISEL,
+ &t2_base->devconf0);
+ }
return 1;
}
@@ -528,23 +539,59 @@ unsigned long mmc_bread(int dev_num, unsigned
long blknr, lbaint_t blkcnt,
return 1;
}
-int mmc_legacy_init(int verbose)
+int mmc_legacy_init(int dev)
{
+ mmc_set_dev(dev);
if (configure_mmc(&cur_card_data) != 1)
return 1;
- mmc_blk_dev.if_type = IF_TYPE_MMC;
- mmc_blk_dev.part_type = PART_TYPE_DOS;
- mmc_blk_dev.dev = 0;
- mmc_blk_dev.lun = 0;
- mmc_blk_dev.type = 0;
+ block_dev_desc_t *mmcdev = mmc_get_dev(dev);
+ if (mmcdev == NULL)
+ return 1;
+
+ mmcdev->if_type = IF_TYPE_MMC;
+ mmcdev->part_type = PART_TYPE_DOS;
+ mmcdev->dev = dev;
+ mmcdev->lun = 0;
+ mmcdev->type = 0;
/* FIXME fill in the correct size (is set to 32MByte) */
- mmc_blk_dev.blksz = MMCSD_SECTOR_SIZE;
- mmc_blk_dev.lba = 0x1;
- mmc_blk_dev.removable = 0;
- mmc_blk_dev.block_read = mmc_bread;
+ mmcdev->blksz = MMCSD_SECTOR_SIZE;
+ mmcdev->lba = 0x1;
+ mmcdev->removable = 0;
+ mmcdev->block_read = mmc_bread;
- fat_register_device(&mmc_blk_dev, 1);
+ fat_register_device(mmcdev, 1);
return 0;
}
+
+int mmc_set_dev(int devnum)
+{
+ switch (devnum) {
+ case 1:
+ mmc_base = (hsmmc_t *)OMAP_HSMMC_BASE1;
+ return 0;
+ case 2:
+ mmc_base = (hsmmc_t *)OMAP_HSMMC_BASE2;
+ return 0;
+ case 3:
+ mmc_base = (hsmmc_t *)OMAP_HSMMC_BASE3;
+ return 0;
+ default:
+ puts("No such MMC device\n");
+ return 1;
+ }
+}
+
+int mmc_get_dev_id()
+{
+ if (mmc_base == (hsmmc_t *)OMAP_HSMMC_BASE1)
+ return 1;
+ else if (mmc_base == (hsmmc_t *)OMAP_HSMMC_BASE2)
+ return 2;
+ else if (mmc_base == (hsmmc_t *)OMAP_HSMMC_BASE3)
+ return 3;
+ else
+ return -1;
+}
+
diff --git a/include/asm-arm/arch-omap3/clocks.h b/include/asm-arm/
arch-omap3/clocks.h
index 71a0cb6..7dc9366 100644
--- a/include/asm-arm/arch-omap3/clocks.h
+++
Re: [U-Boot] [PATCH/RFC] Support HSMMC2 and 3 on OMAP3.
Hi Minkyu
I've resent V2 of the patch to the list; hopefully it addresses your
concerns.
On 28/06/2009, at 4:35 AM, Minkyu Kang wrote:
> Hi Hugo Vincent,
>
> 2009/6/27 Hugo Vincent :
>> Adds support for the second and third HSMMC controllers on OMAP3
>> SoCs.
>>
>> Tested working on Gumstix Overo with a custom base-board containing
>> external SD/MMC slots.
>>
>> Signed-off-by: Hugo Vincent
>>
>> diff --git a/board/omap3/overo/overo.h b/board/omap3/overo/overo.h
>> index 4c06e6e..84c09da 100644
>> --- a/board/omap3/overo/overo.h
>> +++ b/board/omap3/overo/overo.h
>> @@ -292,7 +292,7 @@ const omap3_sysinfo sysinfo = {
>> MUX_VAL(CP(SYS_OFF_MODE),(IEN | PTD | DIS | M0)) /
>> *SYS_OFF_MODE*/\
>> MUX_VAL(CP(SYS_CLKOUT1), (IEN | PTD | DIS | M0)) /
>> *SYS_CLKOUT1*/\
>> MUX_VAL(CP(SYS_CLKOUT2), (IEN | PTU | EN | M4)) /*GPIO_186*/\
>> - MUX_VAL(CP(ETK_CLK_ES2), (IDIS | PTU | EN | M2)) /
>> *MMC3_CLK*/\
>> + MUX_VAL(CP(ETK_CLK_ES2), (IEN | PTU | EN | M2)) /
>> *MMC3_CLK*/\
>> MUX_VAL(CP(ETK_CTL_ES2), (IEN | PTU | EN | M2)) /*MMC3_CMD*/\
>> MUX_VAL(CP(ETK_D0_ES2), (IEN | PTU | EN | M4)) /*GPIO_14*/\
>> MUX_VAL(CP(ETK_D1_ES2), (IEN | PTD | EN | M4)) /*GPIO_15 -
>> X_GATE*/\
>> diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c
>> index 039fe59..7b99603 100644
>> --- a/common/cmd_mmc.c
>> +++ b/common/cmd_mmc.c
>> @@ -65,11 +65,10 @@ int do_mmc (cmd_tbl_t *cmdtp, int flag, int argc,
>> char *argv[])
>>}
>>} else if (argc == 3) {
>>dev = (int)simple_strtoul(argv[2], NULL, 10);
>> -
>> -#ifdef CONFIG_SYS_MMC_SET_DEV
>> - if (mmc_set_dev(dev) != 0)
>> + if (mmc_legacy_init(dev) != 0) {
>> + puts("No MMC card found\n");
>>return 1;
>> -#endif
>> + }
>>curr_device = dev;
>>} else {
>>cmd_usage(cmdtp);
>
> why you reinit at "mmc device" command.
> If you want to device init and device selecting at one time.
> you can use mmc init command
> e.g: # mmc init
Reverted to how it was and defined CONFIG_SYS_MMC_SET_DEV in my board
config.
>> diff --git a/drivers/mmc/omap3_mmc.c b/drivers/mmc/omap3_mmc.c
>> index 234fddf..a53fc3e 100644
>> --- a/drivers/mmc/omap3_mmc.c
>> +++ b/drivers/mmc/omap3_mmc.c
>> @@ -50,12 +50,15 @@ const unsigned short mmc_transspeed_val[15][4]
>> = {
>> };
>>
>> mmc_card_data cur_card_data;
>> -static block_dev_desc_t mmc_blk_dev;
>> -static hsmmc_t *mmc_base = (hsmmc_t *)OMAP_HSMMC_BASE;
>> +static block_dev_desc_t mmc_blk_dev[3];
>> +static hsmmc_t *mmc_base = (hsmmc_t *)OMAP_HSMMC_BASE1;
>>
>> block_dev_desc_t *mmc_get_dev(int dev)
>> {
>> - return (block_dev_desc_t *) &mmc_blk_dev;
>> + if (dev >= 1 && dev <= 3)
>> + return (block_dev_desc_t *) &mmc_blk_dev[dev-1];
>> + else
>> + return NULL;
>> }
>>
>> void twl4030_mmc_config(void)
>> @@ -135,7 +138,8 @@ unsigned char mmc_init_setup(void)
>> {
>>unsigned int reg_val;
>>
>> - mmc_board_init();
>> + if (mmc_get_dev_id() == 1)
>> + mmc_board_init();
>
> do not need to init for mmc2/3 about VMMC and devconf?
There doesn't seem to be much commonality amongst different OMAP35xx
boards as to how MMC2 and 3 are powered. My board (which uses a
Gumstix Overo) only uses the TWL4030 for powering MMC1, whereas 2 and
3 are powered externally. I've updated my patch with a comment to that
effect. Note that some boards use a non-transparent transceiver/level
translator on MMC2 that requires direction signals from the OMAP;
supporting this would take a bit more work.
Similarly, PBIAS setup is only for MMC1.
>>writel(readl(&mmc_base->sysconfig) | MMC_SOFTRESET,
>>&mmc_base->sysconfig);
>> @@ -528,23 +532,58 @@ unsigned long mmc_bread(int dev_num, unsigned
>> long blknr, lbaint_t blkcnt,
>>return 1;
>> }
>>
>> -int mmc_legacy_init(int verbose)
>> +int mmc_legacy_init(int dev)
>> {
>> + mmc_set_dev_id(dev);
>>if (configure_mmc(&cur_card_data) != 1)
>>return 1;
>>
>> - mmc_blk_dev.if_type = IF_TYPE_MMC;
>> - mmc_blk_dev.part_type = PART_TYPE_DOS;
>> - mmc_blk_dev.dev = 0;
>> - mmc_blk_dev.lun = 0;
>> - mmc_blk_dev.type = 0;
>> + block_dev_desc_t *mmcdev = mmc_get_dev(dev);
>> + if (mmcdev == NULL)
>> + return 1;
>> +
>> + mmcdev->if_type = IF_TYPE_MMC;
>> + mmcdev->part_type = PART_TYPE_DOS;
>> + mmcdev->dev = dev;
>> + mmcdev->lun = 0;
>> + mmcdev->type = 0;
>>
>>/* FIXME fill in the correct size (is set to 32MByte) */
>> - mmc_blk_dev.blksz = MMCSD_SECTOR_SIZE;
>> - mmc_blk_dev.lba = 0x1;
>> - mmc_blk_dev.removable = 0;
>> - mmc_blk_dev.block_read = mmc_bread;
Re: [U-Boot] [PATCH] OMAP3 pandora: update pin mux for rev3 boards
Dear Jean-Christophe, Jean-Christophe PLAGNIOL-VILLARD wrote: > On 19:12 Thu 25 Jun , Jason Kridner wrote: >>On Thu, Jun 25, 2009 at 4:59 PM, Jean-Christophe PLAGNIOL-VILLARD >> wrote: >> >> On 14:57 Mon 08 Jun , Grazvydas Ignotas wrote: >> > The update consists of following changes: >> > - remove configuration of not connected pins, effectively >> > leaving them in safe mode. >> > - remove unused GPIOs, setup newly added ones. >> > - setup pulls for various GPIOs. Disable pulls for game >> > buttons, as they have external pulls. >> > - SDRC CS change based on recent patch for >> > Beagle and Overo. >> > >> > Old boards are no longer supported, but there was only >> > small number of test boards made. Updated configuration >> > is expected to be used for mass production. >> If user have old version in possession NACK >> >>I believe no users who would possibly object have the old version (or any >>version) in possession. Only the core developers ever got these boards. >>Is the expectation to create #ifdef or some sort of auto-detection >>(unlikely possible)? > untill the hardware will be really not anymore use yes please If two or three people (from the board manufacturer?) which are more familiar with the development board situation than you say "we don't need it" then this should be accepted. If nobody uses the older boards any more (and this is what I understood they said: "There were only few older boards, we know where they are and they are replaced by new ones") then there is absolutely no reason to pollute U-Boot with support for it. There is no need to add dead code to U-Boot. We should trust the board maintainers somehow. >> this kind of huge update is non bisectable so we do need to use a true >> mux api >> as the kernel lot's of other arch in u-boot >> >>Why is it not bisectable? > because your mix cleanup, fixup and new board support >>Do you have a "true mux api" to suggest? > the same as the kernel one is the best for code sharing OMAP3 pin mux in kernel is totally broken. Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: Update MTD infrastructure to support 64bit device size
Dear Stefan, Stefan Roese wrote: > On Monday 22 June 2009 20:10:23 Dirk Behme wrote: >>> This is because it's a copy from the Linux code. Not sure if >>> we should change the coding style here. I really prefer to be >>> in sync with the Linux version. This makes future updates easier. >> You have to discuss this with Wolfgang, but he wasn't happy about it. >> Enjoy the time while he is on vacation ;) > > Yes, will do. ;) > >> 3. The major one: By the new 64bit variables, depending on tool chain, >> there are now calls to libgcc introduced. Depending on tool chain, >> this might work, or fail. As it does with one of my tool chains, which >> worked totally fine until here. It was my understanding that U-Boot >> shall not rely on libgcc, i.e. proper tool chain libraries. >> >> Having CONFIG_SYS_64BIT_VSPRINTF not defined, the linker needs >> "_lshrdi3", which comes from nand_base.o and nand_bbt.o. E.g. from >> "len = mtd->size >> (this->bbt_erase_shift + 2);" from nand_bbt.c. >> >> Having CONFIG_SYS_64BIT_VSPRINTF enabled, the linker requests >> _lshrdi3, _udivdi3, _umoddi3 and _clz from libgcc. >> >> Looking into U-Boot's lib_arm/ directory, we have already some low >> level math functions there to avoid libgcc. E.g. nand_bbt.c has >> references to _ashrdi3, too, but this is resolved by lib_arm's version >> what is fine. >> >> I'd like that NAND code is modified that only math is used which >> U-Boot provides and no libgcc is needed. > this is a already known problem by Stefan and I and solved > > two patchs was send to the ML Thanks for the hint! Do you kindly have the subjects or better links to mailing list archive? >>> http://git.denx.de/?p=u-boot/u-boot-arm.git;a=commit;h=cf96e690cb9840b4a5 >>> dc7e750be863228550b5ce >>> >>> and >>> >>> http://git.denx.de/?p=u-boot/u-boot-arm.git;a=commit;h=c5ae538c9bd359c137 >>> d306e431b2589ba91fbc08 >>> >>> both available in the "testing" branch of u-boot-arm. >> Yes, I found them. I was confused because I understood Jean-Christophe >> that they were posted to the list already in the past, and not while >> we were discussing about it ;) > > Jean-Christophe did post those patches a few days ago. > >>> From you comments on the list I see that you found those patches here >>> too. :) >>> >>> Do these patches fix the building problem for you? >> "testing" branch of u-boot-arm compiled fine for me, but I'm not sure >> if the NAND changes are in "testing" branch of u-boot-arm, too. > > I'm pretty sure they are, since Jean-Christophe used these patches exactly to > fix this NAND related problem on ARM. But it should be easy to check if the > patches are in here. git is your friend... ;) > >> Anyway, I would vote for moving these two commits as soon as possible >> into mainline to fix mainline, too. But there was some discussion >> about how to deal with Makefile changes to the patches Jean-Christophe >> sent to the list. >> >> Maybe we can find a solution for the Makefile issues of these patches >> discussed on this list and then move the fixes asap into mainline? > > Yes, I would really like to see those changes in mainline soon as well. I > have > to admit that I'm not a real Makefile "expert", so I don't have a real > expertise to get involved in this discussion. But I'll try to take another > look at this thread tomorrow. Sorry, I know, the first week after vacation is always quite busy ;) But any news on this? Many thanks Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
