Re: [U-Boot] UART2 Console in u-boot
hi, I got things working on UART2 as consolebut i still have issues in relocating.. its problem in my hardware...so things are going on well... thank u Mr.Stefan for the help extended Thanks Regards, Prathika R prathika wrote: hi, i did add the UART2 in the serial multi infrastructure at the end of my serial.c. i have also configured GPIO registers for enabling UART2 Tx and Rx lines. As I understand, these lines are also multiplexed with the boot strap lines of the PowerPC 440EP. Will this create any issue in the performance? As I already mentioned I have enabled #define CONFIG_UART2_CONSOLE and #define UART2_BASECFG_PERIPHERAL_BASE + 0x500 You have mentioned to enable the UART2 as default stdin and stdout...where do I enable that?? Thanks Regards, Prathika R Stefan Roese wrote: On Friday 17 April 2009, prathika wrote: i have ported u-boot this way to my board with few changes in the u-boot source code and the board is up and i have tested stand alone application execution also. So you did a real board port to your custom board? Or did you just change the yosemite files? Now as my requirement is that my console should be on UART2 as my UART0 and UART1 are coming out as RS 422 lines and only UART2 is RS232. I did some patch up work on UART0 lines and tested my u-boot porting. Ah, I though you wanted the console on UART1. Ok, then my solution does not work for you. I added a line #define UART2_BASECFG_PERIPHERAL_BASE + 0x500 I have now changed as below and I commented checking for #define UART0_CONSOLE and #define UART1_CONSOLE: #define UARTBASEUART2_BASE Is this OK?? Best would be to add the 3rd UART (UART2) to the SERIAL_MULTI infrastructure (see end of serial.c) and use this device as stdin/stdout/.. in your default environment. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ 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-Boot ARM merge strategy, was: there are non-DM6446 DaVinci chips
Hi Dirk,
On Fri, Apr 24, 2009 at 10:17 PM, Dirk Behme dirk.be...@googlemail.comwrote:
Dear Jean-Christophe,
David Brownell wrote:
...
http://lists.denx.de/pipermail/u-boot/2009-April/050802.html
the Patch series and this has been apply in the u-boot-arm/next
I see that branch now exists ... thanks! :)
Could you clarify the current merge cycle for me, by the way?
I know u-boot has switched to 2009.{01,03,05,...} releases,
which is a big win from where I sit!, with rc tags.
What I'm unclear on is what gets merged for 2009.05 versus
later. Are these next branches for the '05 release (which
hasn't yet hit rc1)? Or for '07 instead?
Yes, I have the same questions. I already tried to ask similar, but
didn't get an answer.
http://lists.denx.de/pipermail/u-boot/2009-April/05.html
Maybe my wording was a little unclear?
Dirk
Btw.: Now that -next exists, I can't find patch linked above in it,
though :(
My approach is that once the merge window closes, new patches that are not
bug fixes go into 'next', which is for the release after the current one (in
this case 07). When the merge window opens again, next goes to master and
the fun starts again. I can't say for sure if this is how all branches are
handled, though.
regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v8] Marvell MV88E61XX Switch Driver support
Hi Prafulla, Prafulla Wadaskar wrote: -Original Message- From: Ben Warren [mailto:biggerbadder...@gmail.com] Sent: Friday, April 24, 2009 7:00 PM To: Prafulla Wadaskar Cc: u-boot@lists.denx.de; Ashish Karkare; Prabhanjan Sarnaik; Ronen Shitrit Subject: Re: [PATCH v8] Marvell MV88E61XX Switch Driver support Prafulla Wadaskar wrote: Chips supported:- 1. 88E6161 6 port gbe swtich with 5 integrated PHYs 2. 88E6165 6 port gbe swtich with 5 integrated PHYs 2. 88E6132 3 port gbe swtich with 2 integrated PHYs Platform specific configuration supported default and router port vlan config supported Note: This driver is supported and tested against kirkwood egiga interface Contributors: Yotam Admon yo...@marvell.com Michael Blostein michae...@marvell.com Reviewed by: Ronen Shitrit rshit...@marvell.com Signed-off-by: Prafulla Wadaskar prafu...@marvell.com snip applied to net/next branch. Hi Ben Thanks I could not find this update at http://git.denx.de/?p=u-boot/u-boot-net.git;a=shortlog;h=refs/heads/next Is this process still in progress or the location is different one? Regards.. Prafulla. . . I kinda missed the last step of pushing my local changes to the denx repo. It's there now. regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot ARM merge strategy, was: there are non-DM6446 DaVinci chips
On Friday 24 April 2009, Dirk Behme wrote: Btw.: Now that -next exists, I can't find patch linked above in it, though :( http://git.denx.de/?p=u-boot/u-boot-arm.git;a=shortlog;h=refs/heads/next shows it ... respects SKIP_LOWLEVEL_INIT. Make sure to look at the next branch there; you can start from http://git.denx.de/?p=u-boot/u-boot-arm.git Then page to the bottom, heads -- next, then shortlog. They're all there, except the dm9000 eeprom bugfix. - Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot ARM merge strategy, was: there are non-DM6446 DaVinci chips
On Friday 24 April 2009, Ben Warren wrote: My approach is that once the merge window closes, new patches that are not bug fixes go into 'next', which is for the release after the current one (in this case 07). Then I'm curious how that dm9000 EEPROM reading bugfix landed in net/next ... or is the point that the merge window for 2009.05 is still open, since RC1 hasn't yet been tagged? My question on that one is how it ever happened in the first place! My thought was that only four boards in the tree seem to use that driver. The AT91sam9 board (whichever) explicitly disables the EEPROM access, as if maybe it were observed to be broken. Two of the other boards are kind of old, maybe not used much. And ISTR counting the fourth board as the one I was poking at, on which the bugfix was developed. When the merge window opens again, next goes to master and the fun starts again. I can't say for sure if this is how all branches are handled, though. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot ARM merge strategy
Hi Ben,
Ben Warren wrote:
Hi Dirk,
On Fri, Apr 24, 2009 at 10:17 PM, Dirk Behme dirk.be...@googlemail.comwrote:
Dear Jean-Christophe,
David Brownell wrote:
...
http://lists.denx.de/pipermail/u-boot/2009-April/050802.html
the Patch series and this has been apply in the u-boot-arm/next
I see that branch now exists ... thanks! :)
Could you clarify the current merge cycle for me, by the way?
I know u-boot has switched to 2009.{01,03,05,...} releases,
which is a big win from where I sit!, with rc tags.
What I'm unclear on is what gets merged for 2009.05 versus
later. Are these next branches for the '05 release (which
hasn't yet hit rc1)? Or for '07 instead?
Yes, I have the same questions. I already tried to ask similar, but
didn't get an answer.
http://lists.denx.de/pipermail/u-boot/2009-April/05.html
Maybe my wording was a little unclear?
Dirk
Btw.: Now that -next exists, I can't find patch linked above in it,
though :(
My approach is that once the merge window closes, new patches that are not
bug fixes go into 'next', which is for the release after the current one (in
this case 07). When the merge window opens again, next goes to master and
the fun starts again.
Yes, this is my basic understanding, too.
But there are always these ugly details ;)
- What's about patches that remove dead code, unused macros etc. IMHO
they can be handled like bug fixes and applied while rc?
- What's about patches that are sent while open merge window or
before, but need some update cycles and are finalized while rc?
- What about patches which are sent immediately after merge window
closed (hours - 1 or 2 days)? I already heard something like 'no
problem if it comes some hours later, if it is fine then I will still
apply it'.
What I personally find essential for patch submitters is the patch
dealing by custodian. It should be consistent and by this somehow
predictable. This helps patch submitters to get a feeling for 'this
patch has only a chance while merge window is open' or 'it's worth
sending this patch immediately, it will have a chance to be merge now'.
What confuses me is something like patch A is applied short time after
sent, patch B will be eventually applied later to next, patch C gets
no comments. With A and B doing the same stuff, and maybe C sent before A.
I can't say for sure if this is how all branches are
handled, though.
Let's wait for Jean-Christophe opinion.
Best regards
Dirk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot ARM merge strategy, was: there are non-DM6446 DaVinci chips
David Brownell wrote: On Friday 24 April 2009, Dirk Behme wrote: Btw.: Now that -next exists, I can't find patch linked above in it, though :( http://git.denx.de/?p=u-boot/u-boot-arm.git;a=shortlog;h=refs/heads/next shows it ... respects SKIP_LOWLEVEL_INIT. Make sure to look at the next branch there; you can start from http://git.denx.de/?p=u-boot/u-boot-arm.git Then page to the bottom, heads -- next, then shortlog. They're all there, except the dm9000 eeprom bugfix. Sorry for being unclear. Yes, your Davinci patches are there. With 'patch linked above' I meant OMAP3: Remove legacy NAND defines http://lists.denx.de/pipermail/u-boot/2009-April/05.html which Jean-Christophe mentioned to apply against -next: will be apply on the next. Or did I miss it in http://git.denx.de/?p=u-boot/u-boot-arm.git;a=shortlog;h=refs/heads/next again? Please correct me then (and send me some more coffee) ;) Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot ARM merge strategy, was: there are non-DM6446 DaVinci chips
Hi David, David Brownell wrote: On Friday 24 April 2009, Ben Warren wrote: My approach is that once the merge window closes, new patches that are not bug fixes go into 'next', which is for the release after the current one (in this case 07). Then I'm curious how that dm9000 EEPROM reading bugfix landed in net/next ... or is the point that the merge window for 2009.05 is still open, since RC1 hasn't yet been tagged? In this case a pretty good argument could be made that it's a bug fix and not a feature, so can go in 2009.05. Obviously bugs that break builds get more attention than ones that have been in code for a while and nobody noticed. I'll ask Wolfgang to pick it up directly. As you're noticing, how and when patches are picked up is open to many interpretations. regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot ARM merge strategy
Hi Dirk,
Dirk Behme wrote:
Hi Ben,
Ben Warren wrote:
Hi Dirk,
On Fri, Apr 24, 2009 at 10:17 PM, Dirk Behme
dirk.be...@googlemail.comwrote:
Dear Jean-Christophe,
David Brownell wrote:
...
http://lists.denx.de/pipermail/u-boot/2009-April/050802.html
the Patch series and this has been apply in the u-boot-arm/next
I see that branch now exists ... thanks! :)
Could you clarify the current merge cycle for me, by the way?
I know u-boot has switched to 2009.{01,03,05,...} releases,
which is a big win from where I sit!, with rc tags.
What I'm unclear on is what gets merged for 2009.05 versus
later. Are these next branches for the '05 release (which
hasn't yet hit rc1)? Or for '07 instead?
Yes, I have the same questions. I already tried to ask similar, but
didn't get an answer.
http://lists.denx.de/pipermail/u-boot/2009-April/05.html
Maybe my wording was a little unclear?
Dirk
Btw.: Now that -next exists, I can't find patch linked above in it,
though :(
My approach is that once the merge window closes, new patches that
are not
bug fixes go into 'next', which is for the release after the current
one (in
this case 07). When the merge window opens again, next goes to
master and
the fun starts again.
Yes, this is my basic understanding, too.
But there are always these ugly details ;)
- What's about patches that remove dead code, unused macros etc. IMHO
they can be handled like bug fixes and applied while rc?
I agree that cleanup patches should have more flexibility.
- What's about patches that are sent while open merge window or
before, but need some update cycles and are finalized while rc?
My policy is to look at the timestamp of the first revision. If it's
during the merge window, follow-on versions are OK too.
- What about patches which are sent immediately after merge window
closed (hours - 1 or 2 days)? I already heard something like 'no
problem if it comes some hours later, if it is fine then I will still
apply it'.
Well, since communication about the window state is rare at best, a good
argument can be made for flexibility here.
What I personally find essential for patch submitters is the patch
dealing by custodian. It should be consistent and by this somehow
predictable. This helps patch submitters to get a feeling for 'this
patch has only a chance while merge window is open' or 'it's worth
sending this patch immediately, it will have a chance to be merge now'.
Sure - consistency would be great. Unfortunately every custodian has
his own approach and it's a volunteer workforce. Definitely a goal
worth pursuing, though.
What confuses me is something like patch A is applied short time after
sent, patch B will be eventually applied later to next, patch C gets
no comments. With A and B doing the same stuff, and maybe C sent
before A.
Yeah, better and quicker feedback is a goal we should all be working
towards. Obviously small, trivial patches are easier to review than new
drivers, and so are typically applied more quickly.
I can't say for sure if this is how all branches are
handled, though.
Let's wait for Jean-Christophe opinion.
Best regards
Dirk
regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot ARM merge strategy, was: there are non-DM6446 DaVinci chips
On Saturday 25 April 2009, Ben Warren wrote: Then I'm curious how that dm9000 EEPROM reading bugfix landed in net/next ... or is the point that the merge window for 2009.05 is still open, since RC1 hasn't yet been tagged? In this case a pretty good argument could be made that it's a bug fix and not a feature, so can go in 2009.05. Right. It was one of a handful of bugfixes I've sent; I think only one minor one remains (adjusting columns for mtdpart output). Obviously bugs that break builds get more attention than ones that have been in code for a while and nobody noticed. I'll ask Wolfgang to pick it up directly. Saw that; thanks. As you're noticing, how and when patches are picked up is open to many interpretations. Yes. The issue is needing to guess what's up ... so for example, I seem to observe that merge window closed must not be the same as first RC is out, which isn't how the Linux process works. But that's the only example I've seen for how the new u-boot cycles should work... - Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot ARM merge strategy, was: there are non-DM6446 DaVinci chips
Dear David Brownell, In message 200904250003.51845.davi...@pacbell.net you wrote: Then I'm curious how that dm9000 EEPROM reading bugfix landed in net/next ... or is the point that the merge window for 2009.05 is still open, since RC1 hasn't yet been tagged? No. End of merge window and release of -rc1 are completely unrelated. The merge window for 2009.06 (6, not 5!) was closed on Fri Apr 03, 2009, 23:59:59 CET. We're in bug fixing mode. See also: http://www.denx.de/wiki/view/U-Boot/ReleaseCycle 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 Eeeek! 'eval' on strings should have been named 'evil'.-- Tom Phoenix in pine.gso.3.96.980526121813.27437n-100...@user2.teleport.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot ARM merge strategy
Dear Dirk, In message 49f2b6b9.7040...@googlemail.com you wrote: My approach is that once the merge window closes, new patches that are not bug fixes go into 'next', which is for the release after the current one (in this case 07). When the merge window opens again, next goes to master and the fun starts again. Yes, this is my basic understanding, too. Mine, too. Note however that I will not always and not automatically and not exactly at the end of the merge window create a next branch, but I'm in a somewhat specialposition anyway. But there are always these ugly details ;) - What's about patches that remove dead code, unused macros etc. IMHO they can be handled like bug fixes and applied while rc? They can, if the custodian accepts it, and.or if there is consensus on the ML. - What's about patches that are sent while open merge window or before, but need some update cycles and are finalized while rc? These should go in. People who put a lot of effort in their planning should not suffer from the fact that a custodian is slow on answering or reviewing their patches. Everything that has been sent to the list before the end of the MW should go in. - What about patches which are sent immediately after merge window closed (hours - 1 or 2 days)? I already heard something like 'no problem if it comes some hours later, if it is fine then I will still apply it'. Patch acceptance is not as critical as a financial transaction, or such. So if there is a slight delay, the custodian is free to turn a blind eye and accept it anyway. The idea of the development process is to make it foreseeable and plannable, but not to become a PITA or to slow down development. It makes much more sense if an engineer spends another day on testing and cleanup and submits the patch a couple of hours late, instead of submitting a green patch which will waste efforts from several prople during several rounds of review and reposts. What I personally find essential for patch submitters is the patch dealing by custodian. It should be consistent and by this somehow predictable. This helps patch submitters to get a feeling for 'this patch has only a chance while merge window is open' or 'it's worth sending this patch immediately, it will have a chance to be merge now'. But this should be clear: if sent while the merge indow is open, new stuff can go in. If the MW is closed, new stuff may go into next (if the respective custodian runs a next branch), otherwise it has to wait until the next MW. Bug fixes can go in any time. What confuses me is something like patch A is applied short time after sent, patch B will be eventually applied later to next, patch C gets no comments. With A and B doing the same stuff, and maybe C sent before A. I agree that this is not nice. In any case, there should be some comment from the respective custodian which makes *clear* what the patch state is. Even a I have no time now, will look into it later is better than nothing. Also, if there are remarks to a patch, these should leave no doubt if they were just comments and the patch will be accepted anyway, or if the patch should be reworked/resubmitted, or if the patch was rejected without chance to be included at all. I can't say for sure if this is how all branches are handled, though. Let's wait for Jean-Christophe opinion. Well, his opinion is one thing. But I think we can also expect from Jean-Christophe as ARM custodian that he delivers clear and under- standable feedback to all patch submitters. 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 Make it right before you make it faster. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot ARM merge strategy, was: there are non-DM6446 DaVinci chips
Dear David Brownell, In message 200904250105.41050.davi...@pacbell.net you wrote: Yes. The issue is needing to guess what's up ... so for example, I seem to observe that merge window closed must not be the same as first RC is out, which isn't how the Linux process works. But that's the only example I've seen for how the new u-boot cycles should work... Maybe I pout a little more meaning in the words release candiate. After the end of a merge window, there is usually still a long backlog of patches that has not been merged, and after that there are several rounds of debugging / bug fixing needed. IMO it makes little sense to call anything in this state a release candiate. That's why we still have no rc in the current release cycle. 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 I've finally learned what `upward compatible' means. It means we get to keep all our old mistakes. - Dennie van Tassel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot ARM merge strategy
Dear David, in message 200904250555.17450.davi...@pacbell.net you wrote: I think the questions on this topic reflect a reality that such status updates aren't yet visible enough. (The original question was generic, not ARM-specific.) I'm not going to push this information down people's throats. I love living free. Those who want that information can pick it up, those who don't will not get bothered. Is it really too much to ask that people have a look at the U-Boot web page every now and then? Is it really so difficult to find our when the merge window ends? Just type u-boot merge window at google and click on the very first link. Maybe I pout a little more meaning in the words release candiate. ISTR that Linus has said on occasion that RC doesn't mean release candidate! He. This is his interpretation, then. I take the freedom to use a different one :-) You're not actually running the merge window quite like Linux does; that backlog is one differentiator. Well, yes, I know. The tiome when I get the pull requests from the custodians is another one - being a major contribution to the former. That's why we still have no rc in the current release cycle. May be worth reconsidering that, if for no other reason than to make intermedite milestones less opaque ... example, there was no suitably titled announcement in the list archives that the 2009.05 release got re-labeled, but I did eventually find http://lists.denx.de/pipermail/u-boot/2009-April/050339.html Yes, that was when we discussed the change. I edited the web page within the same hour, IIRC. When the RC label just means we only integrate bugfixes now, that communicates such status with very little work. If folk miss some webpage, or mailing list post, they'll still know. Please allow me to stick with RC = release candidate, i. e. something that is at least reasonably compile tested and has at least the majority of patches included. 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 A quarrel is quickly settled when deserted by one party; there is no battle unless there be two. - Seneca ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] U-boot memory dump
Hi, I am using uboot on the MX31 PDk board. I am trying to dump the contents of a status register found at location 50004004. This status register shows the status of the SDHC( SD card host controller) like interrupt , card insertion, card removal etc. According to the MX31 manual, the status register i.e the contents at the corresponding memory location should change on events like card insertion and removal. But the contents aren't changing as expected. I have verified this with Linux and it works. i) Before card insertion = md.l 50004004 50004004: 30004000 0008 0040 ii)After card insertion = md.l 50004004 50004004: 30004000 0008 0040 Could anything be wrong with my u-boot image or the memory initialization(although anything going wrong with the init dosent make sense). Thanks in advance! Thanks, Alfred ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot ARM merge strategy
On 09:07 Sat 25 Apr , Dirk Behme wrote:
Hi Ben,
Ben Warren wrote:
Hi Dirk,
On Fri, Apr 24, 2009 at 10:17 PM, Dirk Behme
dirk.be...@googlemail.comwrote:
Dear Jean-Christophe,
David Brownell wrote:
...
http://lists.denx.de/pipermail/u-boot/2009-April/050802.html
the Patch series and this has been apply in the u-boot-arm/next
I see that branch now exists ... thanks! :)
Could you clarify the current merge cycle for me, by the way?
I know u-boot has switched to 2009.{01,03,05,...} releases,
which is a big win from where I sit!, with rc tags.
What I'm unclear on is what gets merged for 2009.05 versus
later. Are these next branches for the '05 release (which
hasn't yet hit rc1)? Or for '07 instead?
Yes, I have the same questions. I already tried to ask similar, but
didn't get an answer.
http://lists.denx.de/pipermail/u-boot/2009-April/05.html
Maybe my wording was a little unclear?
Dirk
Btw.: Now that -next exists, I can't find patch linked above in it,
though :(
My approach is that once the merge window closes, new patches that are not
bug fixes go into 'next', which is for the release after the current one (in
this case 07). When the merge window opens again, next goes to master and
the fun starts again.
Yes, this is my basic understanding, too.
But there are always these ugly details ;)
- What's about patches that remove dead code, unused macros etc. IMHO
they can be handled like bug fixes and applied while rc?
- What's about patches that are sent while open merge window or before,
but need some update cycles and are finalized while rc?
Depends, if the patch is send just before the merge just to have time to
finish it during the fix window NO
If the patch is really risky it will depends on it
Otherwise ok
- What about patches which are sent immediately after merge window
closed (hours - 1 or 2 days)? I already heard something like 'no problem
if it comes some hours later, if it is fine then I will still apply it'.
For me when the first version of a is send after the close of the merge and
it's not a bug fix, then it will go to the next MW. The only exception will be
if the patch come from an announce or a thread discussion and/or really improve
U-Boot. Otherwise no exception.
For next branch, it will depend if you have big change announce or big patch
series I will create one. Otherwise patch will simply wait until the MW.
For other branch, I'm not really a fan expect if it will help people to work
together an a specific task
Best Regards,
J.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot memory dump
On Sat, Apr 25, 2009 at 11:41:43AM -0500, alfred steele wrote: I am using uboot on the MX31 PDk board. I am trying to dump the contents of a status register found at location 50004004. This status register shows the status of the SDHC( SD card host controller) like interrupt , card insertion, card removal etc. According to the MX31 manual, the status register i.e the contents at the corresponding memory location should change on events like card insertion and removal. But the contents aren't changing as expected. I have verified this with Linux and it works. The difference is most probably that under Linux, your IOMUX is set up correctly. IOW, the CPU does not see any external peripherals unless you enable the pins for the specific function you're trying to use. Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot ARM merge strategy
Dear Jean-Christophe PLAGNIOL-VILLARD, In message 20090425170829.ga30...@game.jcrosoft.org you wrote: - What's about patches that are sent while open merge window or before, but need some update cycles and are finalized while rc? Depends, if the patch is send just before the merge just to have time to finish it during the fix window NO How do you reliably find out that this is the case? 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 The most difficult thing in the world is to know how to do a thing and to watch someone else doing it wrong, without commenting. -- T.H. White ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] OMAP3: Print correct silicon revision
Jean-Christophe PLAGNIOL-VILLARD wrote: On 22:40 Fri 24 Apr , Dirk Behme wrote: Dear Jean-Christophe, Jean-Christophe PLAGNIOL-VILLARD wrote: On 18:49 Fri 24 Apr , Dirk Behme wrote: Sanjeev Premi wrote: The function display_board_info() displays incorrect silicon revision - based on the return value from function get_cpu_rev(). This patch fixes the problem. Signed-off-by: Sanjeev Premi pr...@ti.com Signed-off-by: Dirk Behme dirk.be...@googlemail.com Tested-by: Dirk Behme dirk.be...@googlemail.com why the twice? I wanted to mention that I helped developing these patches and that I tested them on real HW. what do you mean by help? review or dev? if it's review I do not think the sob is correct Seriously, who cares? This extra information doesn't hurt anything so let it pass. --Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot ARM merge strategy
On 19:30 Sat 25 Apr , Wolfgang Denk wrote: Dear Jean-Christophe PLAGNIOL-VILLARD, In message 20090425170829.ga30...@game.jcrosoft.org you wrote: - What's about patches that are sent while open merge window or before, but need some update cycles and are finalized while rc? Depends, if the patch is send just before the merge just to have time to finish it during the fix window NO How do you reliably find out that this is the case? the patch is not finish and will clearly not work on the hard I've no example except a patch will is more a RFC than a really patch I've in mind Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot ARM merge strategy
Hi Wolfgang, On Saturday 25 April 2009, Wolfgang Denk wrote: in message 200904250555.17450.davi...@pacbell.net you wrote: I think the questions on this topic reflect a reality that such status updates aren't yet visible enough. (The original question was generic, not ARM-specific.) I'm not going to push this information down people's throats. I love living free. Those who want that information can pick it up, those who don't will not get bothered. Is it really too much to ask that people have a look at the U-Boot web page every now and then? It's not on the front page, which is where for example you'll see status for Linux (www.kernel.org) or GCC (gcc.gnu.org). And it's not visible in the source tree either. Is it really so difficult to find our when the merge window ends? By observation: yes. But also, when you *do* find the Official Statment it does so in reference to Linux processes ... which make that state very easy to find, via the rc1 git tags. Just type u-boot merge window at google and click on the very first link. Several other key infrastructure projects make it easy to find that info even without using a search engine. As a developer, I'd be more likely to look at the GIT summary for status of the GIT tree; its normally the first place to look for such things. Maybe I pout a little more meaning in the words release candiate. ISTR that Linus has said on occasion that RC doesn't mean release candidate! He. This is his interpretation, then. I take the freedom to use a different one :-) You won't find SuSE, RedHat, or Canonical using an rc1 kernel for even a beta distribution ... ;) You're not actually running the merge window quite like Linux does; that backlog is one differentiator. Well, yes, I know. The tiome when I get the pull requests from the custodians is another one - being a major contribution to the former. And Linux has had years to develop -- and motivate! -- its merge procedures ... it's a different team and process. Processes need constant tweaking though. And your process page strongly suggests you're using the Linux processes. Hence surprise and confusion when you aren't quite doing so, from folk who use those processes daily. Easily addressed though ... that web page can point out some differences. Make a few small things *obviously* different, and people will assume that other things may also differ. When the RC label just means we only integrate bugfixes now, that communicates such status with very little work. If folk miss some webpage, or mailing list post, they'll still know. Please allow me to stick with RC = release candidate, i. e. something that is at least reasonably compile tested and has at least the majority of patches included. I couldn't stop you, of course. All I'm doing is pointing out what others have also pointed out: that the current process is a bit opaque about some key points. And I'm trying to help with some small suggestions. Since you don't want to use an rc tag -- even rc0? -- maybe some other git tag could be used to flag merge window ended. A -pre, maybe. If there's some obvious indicator there, you wouldn't need to update the wiki except maybe to summarize key points of the process you want to publicize. And contributors wouldn't be scratching their heads, or starting long discussions on the list. ;) - Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot ARM merge strategy
On Saturday 25 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote: For me when the first version of a [patch] is send after the close of the merge and it's not a bug fix, then it will go to the next MW. The only exception will be if the patch come from an announce or a thread discussion and/or really improve U-Boot. Otherwise no exception. Wiki might usefully include this as part of that release cycle page that Wolfgang pointed out: * Bug fixes coming in after a merge window closes may still be included in the upcoming release if they are high enough priority. * Other patches coming in after the merge window will be held until the next merge window, possibly in a -next branch of a custodian tree. * Maintainers may, infrequently, make exceptions to those merge policies. It'd still be good to make the merge window ended state more visible, e.g. through *some* GIT tag. IMNSHO. - Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problems with ext2ls SD
Dear Karl, In message 669754ad0903281214x77796b95x76062f1c428ec...@mail.gmail.com you wrote: I am simply using fdisk under Ubuntu 8.04 and a 2GB SD card, I create a primary partition of type 0x83. When I run dumpe2fs it shows an inode size of 256 bytes. I confirm the problem. I finally found some time to run some tests, and was able to reproduce the problem. I even re-tested the old patch that Ryan Chen posted long ago (in July 2008), but as my earlier tests indicated, this patch is seriously broken and does not work at all. So we have to state that ext2 file system support in U-Boot is broken for recent ext2 versions which use bigger inode sizes. Best regards, Viele Grüße, 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 The most difficult thing in the world is to know how to do a thing and to watch someone else doing it wrong, without commenting. -- T.H. White ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP3: Pending patches
-Original Message- From: Dirk Behme [mailto:dirk.be...@googlemail.com] Sent: Saturday, April 25, 2009 11:05 AM To: U-Boot user list; Jean-Christophe PLAGNIOL-VILLARD; Premi, Sanjeev; Tom Rix Cc: Wolfgang Denk Subject: Re: OMAP3: Pending patches Short status update after scanning the recent mails: Dirk Behme wrote: To avoid loosing the overview, here my list of pending OMAP3 patches ready to be applied. From my point of view there are no open comments on these which will prevent to apply them. But please correct if I overlooked anything or add what (patches? comments?) I missed. 1. OMAP3: Beagle: Set pinmux conditionally for Rev C boards http://lists.denx.de/pipermail/u-boot/2009-April/051013.html 2. OMAP3: Remove legacy NAND defines http://lists.denx.de/pipermail/u-boot/2009-April/050882.html 3. OMAP3: Fix timer handling to 1ms and CONFIG_SYS_HZ to 1000 http://lists.denx.de/pipermail/u-boot/2009-April/051178.html 4. OMAP3: Fix changed mmc init command http://lists.denx.de/pipermail/u-boot/2009-April/051179.html 5. OMAP3: Remove unused board-types http://lists.denx.de/pipermail/u-boot/2009-April/051338.html We will try to switch to print_cpuinfo checkboard http://lists.denx.de/pipermail/u-boot/2009-April/051365.html Premi: Do you like to have a look? Hopefully it wouldn't be too hard. [SP] Sure, I will... Jean-Christophe: Please fix the test-only and add the documentation as requested by Wolfgang as soon as possible, that we can safely use it. http://lists.denx.de/pipermail/u-boot/2009-April/051382.html 6. OMAP3: Print correct silicon revision http://lists.denx.de/pipermail/u-boot/2009-April/051339.html 7. Zoom2 respin II (10 patches) http://lists.denx.de/pipermail/u-boot/2009-April/050863.html http://lists.denx.de/pipermail/u-boot/2009-April/050864.html http://lists.denx.de/pipermail/u-boot/2009-April/050865.html http://lists.denx.de/pipermail/u-boot/2009-April/050866.html http://lists.denx.de/pipermail/u-boot/2009-April/050868.html http://lists.denx.de/pipermail/u-boot/2009-April/050867.html http://lists.denx.de/pipermail/u-boot/2009-April/050869.html http://lists.denx.de/pipermail/u-boot/2009-April/050870.html http://lists.denx.de/pipermail/u-boot/2009-April/050871.html http://lists.denx.de/pipermail/u-boot/2009-April/050872.html After http://lists.denx.de/pipermail/u-boot/2009-April/051383.html http://lists.denx.de/pipermail/u-boot/2009-April/051384.html http://lists.denx.de/pipermail/u-boot/2009-April/051385.html http://lists.denx.de/pipermail/u-boot/2009-April/051386.html Tom has to check if an update of this series is necessary. Note: There might be some dependencies between some of these patches. Different authors, sent at different time, unfortunately this can't be avoided. So dependent on the order the patches will be applied, there might be some conflicts. Let us know them, we will try to update/fix then as soon as possible! Most probably 5. and 7. will have some conflicts, as 5. removes some code 7. assumes it is still there. If this results in a conflict, let us apply the 10 patches from 7. first and then update 5. Jean-Christophe: If series 7. needs an update, it would be really helpful if you could apply the other patches so that updated 7. can be rebased against them. This will reduce the risk of conflicts. Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Using Signed-off-by, was: OMAP3: Print correct silicon revision
Dear Jean-Christophe, Jean-Christophe PLAGNIOL-VILLARD wrote: On 22:40 Fri 24 Apr , Dirk Behme wrote: Dear Jean-Christophe, Jean-Christophe PLAGNIOL-VILLARD wrote: On 18:49 Fri 24 Apr , Dirk Behme wrote: Sanjeev Premi wrote: The function display_board_info() displays incorrect silicon revision - based on the return value from function get_cpu_rev(). This patch fixes the problem. Signed-off-by: Sanjeev Premi pr...@ti.com Signed-off-by: Dirk Behme dirk.be...@googlemail.com Tested-by: Dirk Behme dirk.be...@googlemail.com why the twice? I wanted to mention that I helped developing these patches and that I tested them on real HW. what do you mean by help? review or dev? Sorry, but I can't see what might be unclear with the string 'helped developing' I used regarding your question. if it's review I do not think the sob is correct Please elaborate more why in review case you think sob is not correct? Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] OMAP3: Print correct silicon revision
Ben Warren wrote: Jean-Christophe PLAGNIOL-VILLARD wrote: On 22:40 Fri 24 Apr , Dirk Behme wrote: Dear Jean-Christophe, Jean-Christophe PLAGNIOL-VILLARD wrote: On 18:49 Fri 24 Apr , Dirk Behme wrote: Sanjeev Premi wrote: The function display_board_info() displays incorrect silicon revision - based on the return value from function get_cpu_rev(). This patch fixes the problem. Signed-off-by: Sanjeev Premi pr...@ti.com Signed-off-by: Dirk Behme dirk.be...@googlemail.com Tested-by: Dirk Behme dirk.be...@googlemail.com why the twice? I wanted to mention that I helped developing these patches and that I tested them on real HW. what do you mean by help? review or dev? if it's review I do not think the sob is correct Seriously, who cares? This extra information doesn't hurt anything so let it pass. Yes, totally agreed. Thanks. Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] OMAP3: Remove unused board-types
Jean-Christophe PLAGNIOL-VILLARD wrote: On 23:01 Fri 24 Apr , Wolfgang Denk wrote: Dear Jean-Christophe PLAGNIOL-VILLARD, In message 20090424200323.gd2...@game.jcrosoft.org you wrote: What exactly do you mean by move the STD API? In which way should the STD API be moved, and what exactly is the STD API you are referring to? extract of arm init function #if defined(CONFIG_DISPLAY_CPUINFO) print_cpuinfo, /* display cpu info (and speed) */ #endif #if defined(CONFIG_DISPLAY_BOARDINFO) checkboard, /* display board info */ #endif I want we use the current API and not re-invent a new API for an arch only Well, if you conside rthis the standard API, this should (1) be documented somewhere, and (2) it must be fixed - at the moment, the code reads: lib_arm/board.c:int print_cpuinfo (void); /* test-only */ I would not dare to use such a function in my code given the test-only comment. sorry I've no time to clean every part of the arm as noone else are interrested in old code so yes it will be cleanup but later asI work on other part of the arm actually which I will finish first Uups :( And this is what I really have a problem with. We sent a patch which removes only dead code, i.e. which consist only of '-' lines (well, except for the removal of a parameter passed by a function ;) ). http://lists.denx.de/pipermail/u-boot/2009-April/051338.html Then we are asked to change other stuff which is touched by this removal, too, to get the patch applied (One could argue that a better way to deal with this would be to apply the code removal patch and ask for sending an *additional* patch to clean up API usage. And not make it dependent. But that's an other topic...) Then we find that the changes we are asked to do rely on code that is marked with 'test only' and needs documentation. And the request for this documentation (would it take more than 0.5h?) get the answer above. And now? What are we supposed to do? Change our patch based on 'test only' undocumented code? Or will a trivial 'remove dead code only' patch delayed until e.g. the Kconfig framework or e.g. the new clock framework or e.g. add what you want will be ready? And when will this be? A confused Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot ARM merge strategy
Wolfgang Denk wrote: Dear Ben Warren, In message 49f2bed7.9070...@gmail.com you wrote: - What about patches which are sent immediately after merge window closed (hours - 1 or 2 days)? I already heard something like 'no problem if it comes some hours later, if it is fine then I will still apply it'. Well, since communication about the window state is rare at best, a good argument can be made for flexibility here. While I agree on your comment on flexibility, I strongly repudiate the statement that the MW state is not clearly communicated. Please have a look at http://www.denx.de/wiki/view/U-Boot/ReleaseCycle and then tell me what exactly is not clear enough. With the discussion I think we can answer this question now with a short summary: a) All information is there b) Some people feel that copying this already available info to mailing list would ... just add a lot of noise to the ML, without any real new information .. c) On the other hand, some people seem to have the feeling that status updates aren't yet visible enough that the current process is a bit opaque about some key points ... IRC channel ... it seems that that's where the real action happens While my feeling tends to (c), too (this is why I e.g. asked for an IRC log), I accept (b) and agree with (a). Many thanks for this discussion, it already helped a lot, and best regards Dirk P.S.: Sorry if I didn't cite your argument or missed an essential one ;) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
