[U-Boot] OMAP3 Beagle patches (was: Merge Window closed, waiting for pull request)
On 05.02.2010 16:02, Tom wrote:
Dirk Behme wrote:
On Thu, Feb 4, 2010 at 8:30 PM, Paulraj, Sandeep
wrote:
On 20.01.2010 18:58, Paulraj, Sandeep wrote:
Subject: Re: [U-Boot] [STATUS] Merge Window closed, waiting for pull
requests
On 19.01.2010 23:30, Wolfgang Denk wrote:
Hi
as you probably have noticed, the merge window closed about 24 hours
ago. Checking my list, I still see s _long_ list of ARM related
patches that have not been processed yet. For many of them I haven't
seen any review comments, nor have architecture maintainer picked
these up and sent pull requests to Tom.
Can you please try and work on this now, so that we can have the
outstanding patches integrated into mainline in the next few days?
I'd like to see the Beagle rev C4 patches applied:
http://lists.denx.de/pipermail/u-boot/2010-January/066629.html
http://lists.denx.de/pipermail/u-boot/2010-January/066632.html
http://lists.denx.de/pipermail/u-boot/2010-January/066634.html
http://lists.denx.de/pipermail/u-boot/2010-January/066636.html
http://lists.denx.de/pipermail/u-boot/2010-January/066638.html
http://lists.denx.de/pipermail/u-boot/2010-January/066640.html
http://lists.denx.de/pipermail/u-boot/2010-January/066642.html
(The ml archive seems to have some issues with these patches. In my
inbox they seem to be fine, though)
Same with me but when I discussed offline with Tom, it appears as if
this set never made it to his Inbox.
We need just a little more time.
What's the recent status of this?
Tom had comments.
Do you (or anybody else) mind to send the archive links of the
comments? Just to be sure that everything will be covered and nothing
is missed ;)
Many thanks and best regards
Dirk
The big ones I remember are copyrights, documenting magic video
settings, clk tweeking needs to move to board level.
These weren't all of them, please see my full comments on 1/23
Ok, thanks.
I found some time to look at them, and I think I was able to
update/fix patches 1-3/7. At least they are compiling fine and I think
the comments are fixed. For reference please find them in attachment.
It seems I don't have time to look at the other patches, though. So
I'm not sure what to do with 1-3, now. Shall I send them as a seperate
series 1-3/3? I.e. splitting the 7 patch series into smaller chunks?
Or will anybody be able to look at the other comments asap? I'd really
like to get them in while this merge window if possible.
Best regards
Dirk
Subject: [PATCH 1/7 v2] ARM OMAP3: Update Beagle revision detection
From: Khasim Syed Mohammed
New BeagleBoard revision C4 uses a new ID. Update revision detection.
Signed-off-by: Dirk Behme
Signed-off-by: Syed Mohammed Khasim
---
Changes in v2: No changes, just make subject 'v2' consistent.
board/ti/beagle/beagle.c | 64 +--
board/ti/beagle/beagle.h |8 -
2 files changed, 46 insertions(+), 26 deletions(-)
Index: u-boot-main/board/ti/beagle/beagle.c
===
--- u-boot-main.orig/board/ti/beagle/beagle.c
+++ u-boot-main/board/ti/beagle/beagle.c
@@ -38,7 +38,7 @@
#include
#include "beagle.h"
-static int beagle_revision_c;
+static int beagle_revision;
/*
* Routine: board_init
@@ -60,41 +60,57 @@ int board_init(void)
/*
* Routine: beagle_get_revision
* Description: Return the revision of the BeagleBoard this code is running on.
- * If it is a revision Ax/Bx board, this function returns 0,
- * on a revision C board you will get a 1.
*/
int beagle_get_revision(void)
{
- return beagle_revision_c;
+ return beagle_revision;
}
/*
* Routine: beagle_identify
- * Description: Detect if we are running on a Beagle revision Ax/Bx or
- * Cx. This can be done by GPIO_171. If this is low, we are
- * running on a revision C board.
+ * Description: Detect if we are running on a Beagle revision Ax/Bx,
+ * C1/2/3, C4 or D. This can be done by reading
+ * the level of GPIO173, GPIO172 and GPIO171. This should
+ * result in
+ * GPIO173, GPIO172, GPIO171: 1 1 1 => Ax/Bx
+ * GPIO173, GPIO172, GPIO171: 1 1 0 => C1/2/3
+ * GPIO173, GPIO172, GPIO171: 1 0 1 => C4
+ * GPIO173, GPIO172, GPIO171: 0 0 0 => D
*/
void beagle_identify(void)
{
- beagle_revision_c = 0;
- if (!omap_request_gpio(171)) {
- unsigned int val;
-
- omap_set_gpio_direction(171, 1);
- val = omap_get_gpio_datain(171);
- omap_free_gpio(171);
-
- if (val)
- beagle_revision_c = 0;
- else
- beagle_revision_c = 1;
- }
+ omap_request_gpio(171);
+ omap_request_gpio(172);
+ omap_request_gpio(173);
+ omap_set_gpio_direction(171, 1);
+ omap_set_gpio_direction(172, 1);
+ omap_set_gpio_dire
Re: [U-Boot] [PATCH ARM 4/4] Change s3c24x0 register struct members to lower case
Dear Wolfgang and kevin, On 6 February 2010 23:24, Wolfgang Denk wrote: > Dear Minkyu Kang, > > In message <1f3430fb1002060418ydd28583sb6051dd1517fa...@mail.gmail.com> you > wrote: >> >> > Changes the names of the s3c24x0 register struct members from upper-case >> > to lower-case. > ... >> Sorry for late reply. >> I tried to review your patch series, >> but your patch is too confusion, because of files are scattered in >> every patches. > > Well, but that's only natural, as the use of these names is scattered > all over the place. > >> If possible, could you please remake patches? >> Please make to one file's modification by one patch. > > This request makes no sense at all. If you change a variable name, you > *must* change all places where it hgets used within the same commit. Agreed, but I didn't mention about patch 4. (It's my mistake that I replied at this mail) I think patch1, 2 and 3 are same type of change (about code style). So, I want to merge these patches, can be see one file's modification by one patch. > > The splitting you suggest would make things worse. > > Best regards, > > Wolfgang Denk > btw, I understood about kevin's concept. please rebase and resend the patch. Thanks. Minkyu Kang -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH ARM 4/4] Change s3c24x0 register struct members to lower case
On 07/02/2010 13:38, Minkyu Kang wrote: > Dear Wolfgang and kevin, > > On 6 February 2010 23:24, Wolfgang Denk wrote: >> Dear Minkyu Kang, >> >> In message<1f3430fb1002060418ydd28583sb6051dd1517fa...@mail.gmail.com> you >> wrote: >>> Changes the names of the s3c24x0 register struct members from upper-case to lower-case. >> ... >>> Sorry for late reply. >>> I tried to review your patch series, >>> but your patch is too confusion, because of files are scattered in >>> every patches. >> >> Well, but that's only natural, as the use of these names is scattered >> all over the place. >> >>> If possible, could you please remake patches? >>> Please make to one file's modification by one patch. >> >> This request makes no sense at all. If you change a variable name, you >> *must* change all places where it hgets used within the same commit. > > Agreed, > but I didn't mention about patch 4. (It's my mistake that I replied at > this mail) > > I think patch1, 2 and 3 are same type of change (about code style). > So, I want to merge these patches, > can be see one file's modification by one patch. Patches 1 and 2 contain only white-space changes and patch 3 contains only code style changes (moving external function prototypes to header files, removing unused code, making line lengths less than 81 characters, brackets around if/then/else/when/do blocks, generally anything that checkpatch.pl warns about). I can merge these together as long as nobody objects to having white-space and code style changes in a single patch? Kevin > >> >> The splitting you suggest would make things worse. >> >> Best regards, >> >> Wolfgang Denk >> > > btw, I understood about kevin's concept. > please rebase and resend the patch. > > Thanks. > Minkyu Kang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add bootcount to AT91
Anders Darander wrote: > Hi, > > On Thu, Jan 14, 2010 at 15:00, Anders Darander > wrote: >> From: Anders Darander >> >> Use AT91_GPBR 3 as a bootcount register. >> > > As a followup to Werners list of patches not incorporated (from some > time ago), I'd just like to get a comment on the status of this patch. > > > Should it get reworked somehow, or could it be integrated? > > Regards, > Anders Darander Please send me a link to the original patch. I will take a look Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3: workaround for ARM Cortex-A8 erratum 725233
Siarhei Siamashka wrote:
> 725233: PLD instructions executed with PLD data forwarding
> enabled can result in a processor deadlock
>
> Signed-off-by: Siarhei Siamashka
Please add a detailed comment on the errata.
Also looks like this jumping to ROM code.
Can this be done without a ROM code call ?
Tom
> ---
> cpu/arm_cortexa8/omap3/board.c |6 ++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/cpu/arm_cortexa8/omap3/board.c b/cpu/arm_cortexa8/omap3/board.c
> index 2aa69b3..7b78fa4 100644
> --- a/cpu/arm_cortexa8/omap3/board.c
> +++ b/cpu/arm_cortexa8/omap3/board.c
> @@ -146,6 +146,12 @@ void setup_auxcr()
> __asm__ __volatile__("orr r0, r0, #1 << 5");
> /* SMI instruction to call ROM Code API */
> __asm__ __volatile__(".word 0xE1600070");
> + /* Set PLD_FWD bit in L2AUXCR (Cortex-A8 erratum 725233 workaround) */
> + __asm__ __volatile__("mov r12, #0x2");
> + __asm__ __volatile__("mrc p15, 1, r0, c9, c0, 2");
> + __asm__ __volatile__("orr r0, r0, #1 << 27");
> + /* SMI instruction to call ROM Code API */
> + __asm__ __volatile__(".word 0xE1600070");
> __asm__ __volatile__("mov r0, %0":"=r"(i));
> __asm__ __volatile__("mov r12, %0":"=r"(j));
> }
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] OMAP3: Consolidate SDRC related operations
hvaib...@ti.com wrote:
> From: Vaibhav Hiremath
>
> Consolidated all SDRC related functions/operations into separate
> file - sdrc.c.
Please add a long comment to explain why this is necessary.
Something like..
'Generalizing omap memory setup is necessary to support the new emif4 interface
that for am3517 uses.. '
>
> Signed-off-by: Vaibhav Hiremath
> Signed-off-by: Sanjeev Premi
There is a regression.
Please check devkit8000
cpu/arm_cortexa8/omap3/libomap3.a(board.o): In function `checkboard':
.../cpu/arm_cortexa8/omap3/board.c:313: undefined reference to `is_mem_sdr'
cpu/arm_cortexa8/omap3/libomap3.a(board.o): In function `s_init':
.../cpu/arm_cortexa8/omap3/board.c:228: undefined reference to `mem_init'
cpu/arm_cortexa8/omap3/libomap3.a(mem.o): In function `mem_ok':
.../cpu/arm_cortexa8/omap3/mem.c:92: undefined reference to `get_sdr_cs_offset'
lib_arm/libarm.a(board.o):(.data+0x28): undefined reference to `dram_init'
The biggest problem with this patch is that though the comment says it is
a code movement patch, it has other changes it in. These changes must
be separated into its own patch(s).
Because of these problems, this is only a partial review.
> ---
> cpu/arm_cortexa8/omap3/Makefile|3 +
> cpu/arm_cortexa8/omap3/board.c | 34 +--
> u32 size)
> {
> diff --git a/cpu/arm_cortexa8/omap3/sdrc.c b/cpu/arm_cortexa8/omap3/sdrc.c
> new file mode 100644
> index 000..9a46155
> --- /dev/null
> +++ b/cpu/arm_cortexa8/omap3/sdrc.c
> @@ -0,0 +1,186 @@
> +/*
> + * Functions related to SDRC.
> + *
> + * This file has been created after exctracting and consolidating
> + * the SDRC related content from mem.c and board.c.
> + *
> + * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com/
> + *
Because this is code movement, include the original copyrights
> + * 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
> + */
> +
> +
> + if (!mem_ok(cs))
> + writel(0, &sdrc_base->cs[cs].mcfg);
> +}
> +
> +/**
Follow the multi-line comment.
Remove the extra '*'
This happens other places in this patch.
Fix globally
> + * dram_init - Sets uboots idea of sdram size
> + */
> +int dram_init(void)
> +{
> + DECLARE_GLOBAL_DATA_PTR;
> + unsigned int size0 = 0, size1 = 0;
> +
> + size0 = get_sdr_cs_size(CS0);
> + /*
> + * If a second bank of DDR is attached to CS1 this is
> + * where it can be started. Early init code will init
> + * memory on CS0.
> + */
> + if ((sysinfo.mtype == DDR_COMBO) || (sysinfo.mtype == DDR_STACKED)) {
> + do_sdrc_init(CS1, NOT_EARLY);
> + make_cs1_contiguous();
> +
> + size1 = get_sdr_cs_size(CS1);
This is different that a code movement change.
The comment of the change does not match what you have done.
Split the real changes into a separate patch.
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH ARM 4/4] Change s3c24x0 register struct members to lower case
Dear "kevin.morf...@fearnside-systems.co.uk", In message <4b6ec9d5.6060...@fearnside-systems.co.uk> you wrote: > > Patches 1 and 2 contain only white-space changes and patch 3 contains > only code style changes (moving external function prototypes to header > files, removing unused code, making line lengths less than 81 characters, > brackets around if/then/else/when/do blocks, generally anything that > checkpatch.pl warns about). I can merge these together as long as > nobody objects to having white-space and code style changes in a > single patch? I find this split (white-space changes only first, code style changes then) pretty logical. I would suggest to combine patches 1 + 2 because they belong together, and the split was done only to keep the size of the patch within the soft-limit of this mailing list. I would not fight against combining all 3 into a single commit, but I don't think it would make the code any better - just harder to follow the changes. I suggest not to do this, then - just combine 1+2 regardless of the mailing list limit, and rebase. Thanks. Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Any sufficiently advanced bug is indistinguishable from a feature. - Rich Kulawiec ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problem to link u-boot for sh2a 7203
Many many thanks for your answer. Best regards and good good work. Alle 19:32, sabato 6 febbraio 2010, Wolfgang Denk ha scritto: > Dear Fabio Giovagnini, > > please read http://www.netmeister.org/news/learn2quote.html - don't > top post / full quote, please. > > In message <201002061654.11412.fabio.giovagn...@aurion-tech.com> you wrote: > > for sure my borad is not an rsk 7203, being my board designed by me; but > > I followed the rsk 7203 schematics to connect NOR Flash, SDRAM, ETH, and > > NAND Flash. > > As on my own board, as on rsk board NOR flash in on CS0. > > So I think I am miss understanding something. > > 1) Does u-boot a sort of IPL so it is the program the microprocessor runs > > at power on reset? If yes, at 0x or 0x2000 (nt cached) should > > start the program? How it can run form 0x0C7C if it is SDRAM address > > space? > > I don't know your hardware, nor do I know the Renesas rsk7203 board. I > have no idea how your board's reset sequence looks like, nor how the > Renesas board loads and starts U-Boot. > > U-Boot can be configured in a plethora of different ways to fit all > sorts of hardware. > > If your board differs from the Renesas board, you will have to port > U-Boot to your hardware. As only you know the hardware, and as it is > you who defines things like memory map etc., only you can decide how > to do that. The Renesas board may, or may not, be a good starting > point. I cannot comment on this. > > Best regards, > > Wolfgang Denk -- Fabio Giovagnini Aurion s.r.l. CF e P.IVA 00885711200 Tel. +39.051.594.78.24 Cell. +39.335.8350919 www.aurion-tech.com account telefono VoIP skype (www.skype.com): aurion.giovagnini ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3: workaround for ARM Cortex-A8 erratum 725233
On Sunday 07 February 2010, Tom wrote: > Siarhei Siamashka wrote: > > 725233: PLD instructions executed with PLD data forwarding > > enabled can result in a processor deadlock > > > > Signed-off-by: Siarhei Siamashka > > Please add a detailed comment on the errata. The short summary is pretty much complete (PLD data forwarding is not working correctly and needs to be turned off to prevent problems). Though it really makes sense to add that: 1. only r1pX revisions of Cortex-A8 are affected 2. performance impact is practically non-existant The detailed description of this erratum is available in the official Cortex-A8 errata list. I'm not sure about directly copying full erratum description text here. Anyway, this workaround would be better submitted by somebody TI. I'm just "guilty" of triggering this deadlock with some ARM NEON optimizations from pixman library, so feel a bit of responsibility for it too. > Also looks like this jumping to ROM code. > Can this be done without a ROM code call ? I just added it to the part of code which is already doing similar things (sets L1NEON and other bits from AUXCR with some icky looking assembly via ROM code call). Most likely it can be also done in some other way. -- Best regards, Siarhei Samashka ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] SPI: Fix 32 bit transfers in mxc_spi.c
Magnus Lilja wrote:
> Commit f9b6a1575d9f1ca192e4cb60e547aa66f08baa3f, "i.MX31: fix SPI
> driver for shorter than 32 bit" broke 32 bit transfers. This patch
> makes single 32 bit transfer work again.
>
> Transfer lengths that are known not to work will abort and print
> an error message.
>
> Tested on i.MX31 Litekit and i.MX31 PDK using 32 bit transfers to
> the MC13783/ATLAS chip (using the 'date' command).
>
> Signed-off-by: Magnus Lilja
> ---
>
> As discussed on the mailing list, Guennadi Liakhovetski thinks that
> all transfers > 16 bits are broken. This patch fixes the 32 bit case
> and makes sure the user is notified if a broken bitlength is used.
>
> drivers/spi/mxc_spi.c |9 +
> 1 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c
> index fad9840..93c2bd7 100644
> --- a/drivers/spi/mxc_spi.c
> +++ b/drivers/spi/mxc_spi.c
> @@ -131,6 +131,13 @@ int spi_xfer(struct spi_slave *slave, unsigned int
> bitlen, const void *dout,
> return 1;
> }
>
> + /* This driver is currently partly broken, alert the user */
> + if (bitlen > 16 && bitlen != 32) {
I believe this check can be improved
The transfer loops over 32 bit blks.
so bitlen that are multiples of 32 should work.
so
bitlen != 32
can change to
(bitlen % 32)
Tom
> + printf("Error: SPI transfer with bitlen=%d is broken.\n",
> +bitlen);
> + return 1;
> + }
> +
> for (i = 0, in_l = (u32 *)din, out_l = (u32 *)dout;
>i < n_blks;
>i++, in_l++, out_l++, bitlen -= 32) {
> @@ -142,6 +149,8 @@ int spi_xfer(struct spi_slave *slave, unsigned int
> bitlen, const void *dout,
> *(u8 *)din = data;
> else if (bitlen < 17)
> *(u16 *)din = data;
> + else
> + *in_l = data;
> }
> }
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv2] OMAP3: Avoid re-write to PRM_CLKSRC_CTRL
Premi, Sanjeev wrote:
>> -Original Message-
>> From: Premi, Sanjeev
>> Sent: Friday, January 29, 2010 6:44 PM
>> To: u-boot@lists.denx.de
>> Cc: Premi, Sanjeev; Hiremath, Vaibhav
>> Subject: [PATCHv2] OMAP3: Avoid re-write to PRM_CLKSRC_CTRL
>>
>> The function get_osc_clk_speed() is used to determine the master
>> clock. If SYS_CLK is being divided by 2, the divider is changed
>> to 1 - without following any sequence.
>>
>> Before reaching this function, some of the clocks have already
>> been set (by x-loader or equiv) OR power-on defaults are in use.
>> This change is too sudden, leading to instability beyond certain
>> tolerance zone.
>>
>> The problem was observed with DM3730 (silimar to OMAP3630), on
>> the OMAP3EVM.
>>
>> This patch removes the step to change clock divider. Instead,
>> uses a multiplication factor (if needed). Mathematically, the
>> formula is unchanged.
>>
>> Tested on OMAP3EVM with OMAP3530 and DM3730.
>>
>> Signed-off-by: Sanjeev Premi
>> Signed-off-by: Hiremath Vaibhav
>> ---
>> cpu/arm_cortexa8/omap3/clock.c | 15 +++
>> 1 files changed, 11 insertions(+), 4 deletions(-)
>>
>> diff --git a/cpu/arm_cortexa8/omap3/clock.c
>> b/cpu/arm_cortexa8/omap3/clock.c
>> index 174c453..e8189b4 100644
>> --- a/cpu/arm_cortexa8/omap3/clock.c
>> +++ b/cpu/arm_cortexa8/omap3/clock.c
>> @@ -40,7 +40,7 @@
>>
>> **
>> ***/
>> u32 get_osc_clk_speed(void)
>> {
>> -u32 start, cstart, cend, cdiff, val;
>> +u32 start, cstart, cend, cdiff, cdiv, val;
>> struct prcm *prcm_base = (struct prcm *)PRCM_BASE;
>> struct prm *prm_base = (struct prm *)PRM_BASE;
>> struct gptimer *gpt1_base = (struct gptimer *)OMAP34XX_GPT1;
>> @@ -48,9 +48,13 @@ u32 get_osc_clk_speed(void)
>>
>> val = readl(&prm_base->clksrc_ctrl);
>>
>> -/* If SYS_CLK is being divided by 2, remove for now */
>> -val = (val & (~SYSCLKDIV_2)) | SYSCLKDIV_1;
>> -writel(val, &prm_base->clksrc_ctrl);
>> +if (val & SYSCLKDIV_2)
>> +cdiv = 2;
>> +else if (val & SYSCLKDIV_1)
>> +cdiv = 1;
>> +else
>> +/*Should never reach here! (Assume divider as 1) */
>> +cdiv = 1;
>>
>> /* enable timer2 */
>> val = readl(&prcm_base->clksel_wkup) | CLKSEL_GPT1;
>> @@ -83,6 +87,9 @@ u32 get_osc_clk_speed(void)
>> cend = readl(&gpt1_base->tcrr); /* get end
>> sys_clk count */
>> cdiff = cend - cstart; /* get elapsed ticks */
>>
>> +if (cdiv == 2)
>> +cdiff *= 2;
>> +
>> /* based on number of ticks assign speed */
>> if (cdiff > 19000)
>> return S38_4M;
>> --
>> 1.6.2.2
>>
>>
>
> Tom, Sandeep,
>
> Just wanted to check the status of this patch.
>
Ack-ed
This looks fine.
Thanks
Tom
> Best regards,
> Sanjeev
> ___
> 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] SMSC LAN8720 support
Hi all! I need enable the support of the new SMSC Ethernet PHY LAN8720 in AT91SAM based system. Can anybody give me a piece of advice how I can do it? Any help is appreciated! Regards, Max ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] edb93xx: enable the uart in devicecfg register
Matthias Kaehlcke wrote: > Hi Alessandro, > > El Sat, Feb 06, 2010 at 08:54:05PM +0100 Alessandro Rubini ha dit: > >> printf goes to uart1, but it will block forever waiting for >> busy to go off unless the uart is enabled first. >> >> Signed-off-by: Alessandro Rubini >> --- >> board/edb93xx/edb93xx.c |6 ++ >> 1 files changed, 6 insertions(+), 0 deletions(-) >> >> diff --git a/board/edb93xx/edb93xx.c b/board/edb93xx/edb93xx.c >> index 4df2246..dde30ff 100644 >> --- a/board/edb93xx/edb93xx.c >> +++ b/board/edb93xx/edb93xx.c >> @@ -64,6 +64,12 @@ int board_init(void) >> value |= SYSCON_PWRCNT_UART_BAUD; >> writel(value, &syscon->pwrcnt); >> >> +/* Enable the uart in devicecfg */ >> +value = readl(&syscon->devicecfg); >> +value |= 1<<18 /* U1EN */; > > using a constant like DEVCFG_U1EN would be preferrable, as the patch > is correct at the functional and coding style level i'll leave it to > Tom to decide if we fix this now or later > It is ok to fix this later. The patch set have been applied. Thanks Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] S5PC100: Moves the Macros to a common header file
Dear Naveen Krishna Ch, On 4 February 2010 14:17, Naveen Krishna Ch wrote: > From: Naveen Krishna CH > > The get_pll_clk(int) API returns the PLL frequency based on > the (int) argument which is defined locally in clock.c > > Moving that #define to common header file (clk.h) would > be helpful when using the API from other files. > > Signed-off-by: Naveen Krishna Ch > --- > cpu/arm_cortexa8/s5pc1xx/clock.c | 7 +-- > include/asm-arm/arch-s5pc1xx/clk.h | 6 ++ > 2 files changed, 7 insertions(+), 6 deletions(-) > > diff --git a/cpu/arm_cortexa8/s5pc1xx/clock.c > b/cpu/arm_cortexa8/s5pc1xx/clock.c > index a9e78dd..19619f9 100644 > --- a/cpu/arm_cortexa8/s5pc1xx/clock.c > +++ b/cpu/arm_cortexa8/s5pc1xx/clock.c > @@ -25,12 +25,7 @@ > #include > #include > #include > - > -#define APLL 0 > -#define MPLL 1 > -#define EPLL 2 > -#define HPLL 3 > -#define VPLL 4 > +#include > > #define CLK_M 0 > #define CLK_D 1 > diff --git a/include/asm-arm/arch-s5pc1xx/clk.h > b/include/asm-arm/arch-s5pc1xx/clk.h > index f1aa44f..3e59abe 100644 > --- a/include/asm-arm/arch-s5pc1xx/clk.h > +++ b/include/asm-arm/arch-s5pc1xx/clk.h > @@ -23,6 +23,12 @@ > #ifndef __ASM_ARM_ARCH_CLK_H_ > #define __ASM_ARM_ARCH_CLK_H_ > > +#define APLL 0 > +#define MPLL 1 > +#define EPLL 2 > +#define HPLL 3 > +#define VPLL 4 > + > void s5pc1xx_clock_init(void); > > extern unsigned long (*get_pll_clk)(int pllreg); > -- > 1.6.6 > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > applied to u-boot-samsung Thanks Minkyu Kang -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] How to random my mac in u-boot
Recently, we had a issue that we need to start more than one board at a time. The problem we are facing is that every board is using the same u-boot, which makes them all have the same mac address. Firstly, I think I can gives out a random MAC as we need, but I can not find any rand() or srand() function in U-Boot. My U-Boot version is 2009.11 and my board is based on MPC8247. Is there a chance that I can do this random job when U-Boot starts? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [beagleboard] Re: TI:OMAP: [PATCH 2/7] Enable I2C bus switching
On Sun, Feb 7, 2010 at 12:02 PM, Ben Warren wrote:
> Dirk,
>
> On 2/5/2010 11:30 PM, Dirk Behme wrote:
>>
>> On 24.01.2010 01:05, Tom wrote:
>>
>>>
>>> Khasim Syed Mohammed wrote:
>>>
From 9bb1c3501c8f098dac6e224c99e409ebf92b0ab9 Mon Sep 17 00:00:00 2001
From: Syed Mohammed Khasim
Date: Mon, 18 Jan 2010 18:11:14 +0530
Subject: [PATCH] Enable I2C bus switching
OMAP3 supports Multiple I2C channels, this patch allows
us to use i2c dev command to switch between busses.
Signed-off-by: Syed Mohammed Khasim
Acked-by: Heiko Schocher
---
drivers/i2c/omap24xx_i2c.c | 5 +
include/configs/omap3_beagle.h | 6 ++
2 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/omap24xx_i2c.c b/drivers/i2c/omap24xx_i2c.c
index ff18991..e8c8184 100644
--- a/drivers/i2c/omap24xx_i2c.c
+++ b/drivers/i2c/omap24xx_i2c.c
@@ -435,3 +435,8 @@ int i2c_set_bus_num(unsigned int bus)
return 0;
}
+
+int i2c_get_bus_num(void)
+{
+ return (int) current_bus;
+}
diff --git a/include/configs/omap3_beagle.h
b/include/configs/omap3_beagle.h
index a8abb0e..4d516a4 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -100,6 +100,12 @@
/* DDR - I use Micron DDR */
#define CONFIG_OMAP3_MICRON_DDR 1
+/* Enable Multi Bus support for I2C */
+#define CONFIG_I2C_MULTI_BUS 1
+
+/* Probe all devices */
+#define CONFIG_SYS_I2C_NOPROBES {0x0, 0x0}
>>>
>>> Most/All of the configs I reviewed set the addr element
>>> to a valid address. I do not believe 0 is a valid address
>>> on omap. If the intent is a double negative
>>> {0, 0} == probe all
>>> Then add a comment.
>>>
>>
>> I would fix this, but I have no idea what to add :( Any hint?
>>
>>
>
> CONFIG_SYS_I2C_NOPROBES doesn't have to be defined. It's there as a
> convenience in case there are devices that you don't want to be included
> when probing the bus. If there's nothing you want to skip, don't define it.
>>
With out this option enabled it fails to compile for Multi bus I2C support
More over, this patch is already accepted and has nothing more to do.
May be Tom is waiting for a re-submission along with other patches.
May be we can post only the beagle rev and I2C patch first.
Regards,
Khasim
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP3 Beagle patches (was: Merge Window closed, waiting for pull request)
On Sun, Feb 7, 2010 at 4:14 PM, Dirk Behme wrote: > On 05.02.2010 16:02, Tom wrote: >> >> Dirk Behme wrote: >>> >>> On Thu, Feb 4, 2010 at 8:30 PM, Paulraj, Sandeep >>> wrote: > On 20.01.2010 18:58, Paulraj, Sandeep wrote: >> >>> Subject: Re: [U-Boot] [STATUS] Merge Window closed, waiting for pull >>> requests >>> >>> On 19.01.2010 23:30, Wolfgang Denk wrote: Hi as you probably have noticed, the merge window closed about 24 hours ago. Checking my list, I still see s _long_ list of ARM related patches that have not been processed yet. For many of them I haven't seen any review comments, nor have architecture maintainer picked these up and sent pull requests to Tom. Can you please try and work on this now, so that we can have the outstanding patches integrated into mainline in the next few days? >>> >>> I'd like to see the Beagle rev C4 patches applied: >>> >>> http://lists.denx.de/pipermail/u-boot/2010-January/066629.html >>> http://lists.denx.de/pipermail/u-boot/2010-January/066632.html >>> http://lists.denx.de/pipermail/u-boot/2010-January/066634.html >>> http://lists.denx.de/pipermail/u-boot/2010-January/066636.html >>> http://lists.denx.de/pipermail/u-boot/2010-January/066638.html >>> http://lists.denx.de/pipermail/u-boot/2010-January/066640.html >>> http://lists.denx.de/pipermail/u-boot/2010-January/066642.html >>> >>> (The ml archive seems to have some issues with these patches. In my >>> inbox they seem to be fine, though) >> >> Same with me but when I discussed offline with Tom, it appears as if > > this set never made it to his Inbox. >> >> We need just a little more time. > > What's the recent status of this? Tom had comments. >>> >>> Do you (or anybody else) mind to send the archive links of the >>> comments? Just to be sure that everything will be covered and nothing >>> is missed ;) >>> >>> Many thanks and best regards >>> >>> Dirk >> >> The big ones I remember are copyrights, documenting magic video >> settings, clk tweeking needs to move to board level. >> These weren't all of them, please see my full comments on 1/23 > > Ok, thanks. > > I found some time to look at them, and I think I was able to update/fix > patches 1-3/7. At least they are compiling fine and I think the comments are > fixed. For reference please find them in attachment. > > It seems I don't have time to look at the other patches, though. So I'm not > sure what to do with 1-3, now. Shall I send them as a seperate series 1-3/3? > I.e. splitting the 7 patch series into smaller chunks? Or will anybody be > able to look at the other comments asap? I'd really like to get them in > while this merge window if possible. > I like the idea of submitting them as 1-3/3, I think I will get some time this week. I will try to look at other patches, but cannot guarantee on submission. Regards, Khasim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add bootcount to AT91
Hi Tom, On Sun, Feb 7, 2010 at 15:35, Tom wrote: >> From: Anders Darander >>> >>> Use AT91_GPBR 3 as a bootcount register. > Please send me a link to the original patch. > I will take a look > Tom Here is the link from Werners patch-status mail: http://article.gmane.org/gmane.comp.boot-loaders.u-boot/73640 (Sorry for bumping this thread that many times... I'm pretty sure that you're quite busy...) Best regards, Anders Darander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How to random my mac in u-boot
Dear Peter Pan, In message <48abf2c21002072147t7e67ba44i4298b39acc5d7...@mail.gmail.com> you wrote: > Recently, we had a issue that we need to start more than one board at > a time. The problem > we are facing is that every board is using the same u-boot, which > makes them all have the > same mac address. This means that you have a serious configuration problem in ypur U-Boot port: the U-Boot binary should never contain any MAN accress at all. I recommend to fix this now. > Firstly, I think I can gives out a random MAC as we need, but I can > not find any rand() or srand() > function in U-Boot. Instead of doing random things you should read the FAQ, especially here: http://www.denx.de/wiki/view/DULG/WhereCanIGetAValidMACAddress > Is there a chance that I can do this random job when U-Boot starts? You are not supposed to do that. For testing, you can use the gen_eth_addr program in the tools/ directory to generate "locally administered" MAC addresses, but these are NOT suitable for productions boards. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Objects in mirror are closer than they appear. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
