[U-Boot-Users] Pull request u-boot-blackfin.git
This cleans up and unifies much of the Blackfin cpu/arch directories.
The following changes since commit e5084af8ded58453cd07ec1af8b0f29f34122bbc: Detlev Zundel (1): Replace deprecated "ramdisk" with "ramdisk_size" kernel parameter.
are available in the git repository at:
git://www.denx.de/git/u-boot-blackfin.git master
Mike Frysinger (13): Blackfin: move bootldr command to common code Blackfin: convert BFIN_CPU to CONFIG_BFIN_CPU Blackfin: move on-chip MAC driver into drivers/net/ Blackfin: BF537-stamp: drop board-specific flash driver for CFI Blackfin: BF537-stamp: cleanup spi flash driver Blackfin: update MAINTAINERS list Blackfin: unify cpu and boot modes Blackfin: new cplbinfo command for viewing cplb tables Blackfin: add proper ELF markings to some assembly functions Blackfin: cleanup lib_blackfin/cache.c Blackfin: cleanup and overhaul common board init functions smc91111: use SSYNC() rather than asm(ssync) for Blackfin Blackfin: add error debug to serial driver
MAINTAINERS | 15 + Makefile | 4 +- blackfin_config.mk | 9 +- board/bf533-ezkit/Makefile | 2 +- board/bf533-ezkit/bf533-ezkit.c | 7 - board/bf533-ezkit/config.mk | 6 +- board/bf533-ezkit/u-boot.lds.S | 208 +++--- board/bf533-stamp/Makefile | 4 +- board/bf533-stamp/bf533-stamp.c | 7 - board/bf533-stamp/config.mk | 6 +- board/bf533-stamp/spi.c | 474 ------------ board/bf533-stamp/spi_flash.c | 2 + board/bf533-stamp/u-boot.lds.S | 206 +++--- board/bf537-stamp/Makefile | 4 +- board/bf537-stamp/bf537-stamp.c | 68 +-- board/bf537-stamp/config.mk | 10 +- board/bf537-stamp/flash-defines.h | 123 --- board/bf537-stamp/flash.c | 403 ---------- board/bf537-stamp/spi_flash.c | 815 ++++++++++++++++++++ board/bf537-stamp/stm_m25p64.c | 516 ------------- board/bf537-stamp/u-boot.lds.S | 258 +++---- board/bf561-ezkit/Makefile | 2 +- board/bf561-ezkit/config.mk | 6 +- board/bf561-ezkit/u-boot.lds.S | 209 +++--- common/Makefile | 2 + common/cmd_bootldr.c | 64 ++ common/cmd_cplbinfo.c | 59 ++ cpu/bf533/Makefile | 52 -- cpu/bf533/bf533_serial.h | 77 -- cpu/bf533/cache.S | 129 --- cpu/bf533/config.mk | 27 - cpu/bf533/cpu.c | 213 ----- cpu/bf533/cpu.h | 66 -- cpu/bf533/flush.S | 405 ---------- cpu/bf533/init_sdram.S | 183 ----- cpu/bf533/init_sdram_bootrom_initblock.S | 183 ----- cpu/bf533/interrupt.S | 244 ------ cpu/bf533/interrupts.c | 165 ---- cpu/bf533/ints.c | 112 --- cpu/bf533/serial.c | 186 ----- cpu/bf533/start.S | 313 -------- cpu/bf533/traps.c | 238 ------ cpu/bf533/video.c | 194 ----- cpu/bf533/video.h | 25 - cpu/bf537/Makefile | 52 -- cpu/bf537/cache.S | 129 --- cpu/bf537/config.mk | 27 - cpu/bf537/cpu.c | 219 ------ cpu/bf537/cpu.h | 66 -- cpu/bf537/flush.S | 403 ---------- cpu/bf537/init_sdram.S | 178 ----- cpu/bf537/init_sdram_bootrom_initblock.S | 203 ----- cpu/bf537/interrupt.S | 244 ------ cpu/bf537/interrupts.c | 170 ---- cpu/bf537/ints.c | 112 --- cpu/bf537/serial.c | 186 ----- cpu/bf537/serial.h | 77 -- cpu/bf537/start.S | 576 -------------- cpu/bf537/start1.S | 38 - cpu/bf537/traps.c | 239 ------ cpu/bf537/video.c | 194 ----- cpu/bf537/video.h | 25 - cpu/bf561/Makefile | 52 -- cpu/bf561/cache.S | 129 --- cpu/bf561/config.mk | 27 - cpu/bf561/cpu.c | 212 ----- cpu/bf561/cpu.h | 66 -- cpu/bf561/flush.S | 402 ---------- cpu/bf561/init_sdram.S | 175 ----- cpu/bf561/init_sdram_bootrom_initblock.S | 189 ----- cpu/bf561/interrupt.S | 244 ------ cpu/bf561/ints.c | 112 --- cpu/bf561/serial.c | 188 ----- cpu/bf561/serial.h | 77 -- cpu/bf561/start.S | 303 -------- cpu/bf561/start1.S | 38 - cpu/bf561/traps.c | 238 ------ cpu/bf561/video.c | 194 ----- cpu/bf561/video.h | 25 - cpu/blackfin/.gitignore | 1 + cpu/blackfin/Makefile | 65 ++ cpu/blackfin/bootrom-asm-offsets.awk | 41 + cpu/blackfin/bootrom-asm-offsets.c.in | 12 + cpu/blackfin/cache.S | 61 ++ cpu/blackfin/cpu.c | 141 ++++ cpu/{bf533/start1.S => blackfin/cpu.h} | 28 +- cpu/blackfin/flush.S | 230 ++++++ cpu/{bf537 => blackfin}/i2c.c | 98 ++- cpu/blackfin/initcode.c | 353 +++++++++ cpu/blackfin/interrupt.S | 33 + cpu/{bf561 => blackfin}/interrupts.c | 50 +- cpu/blackfin/reset.c | 96 +++ cpu/blackfin/serial.c | 163 ++++ cpu/blackfin/serial.h | 275 +++++++ cpu/blackfin/start.S | 219 ++++++ cpu/blackfin/system_map.S | 18 + cpu/blackfin/traps.c | 353 +++++++++ cpu/blackfin/watchdog.c | 25 + drivers/net/Makefile | 1 + .../ether_bf537.c => drivers/net/bfin_mac.c | 166 ++--- .../ether_bf537.h => drivers/net/bfin_mac.h | 32 +- drivers/net/smc91111.h | 4 +- include/asm-blackfin/blackfin-config-post.h | 6 +- include/configs/bf533-ezkit.h | 53 +- include/configs/bf533-stamp.h | 138 +--- include/configs/bf537-stamp.h | 143 +--- include/configs/bf561-ezkit.h | 42 +- lib_blackfin/Makefile | 6 +- lib_blackfin/bf533_linux.c | 85 -- lib_blackfin/bf533_string.c | 198 ----- lib_blackfin/bfin_string.c | 203 +++++ lib_blackfin/blackfin_board.h | 64 -- lib_blackfin/board.c | 432 ++++++----- lib_blackfin/boot.c | 54 ++ lib_blackfin/cache.c | 35 +- lib_blackfin/cache.h | 35 - lib_blackfin/memcmp.S | 3 + lib_blackfin/memcpy.S | 3 + lib_blackfin/memmove.S | 3 + lib_blackfin/memset.S | 3 + 120 files changed, 4250 insertions(+), 11831 deletions(-) delete mode 100644 board/bf533-stamp/spi.c create mode 100644 board/bf533-stamp/spi_flash.c delete mode 100644 board/bf537-stamp/flash-defines.h delete mode 100644 board/bf537-stamp/flash.c create mode 100644 board/bf537-stamp/spi_flash.c delete mode 100644 board/bf537-stamp/stm_m25p64.c create mode 100644 common/cmd_bootldr.c create mode 100644 common/cmd_cplbinfo.c delete mode 100644 cpu/bf533/Makefile delete mode 100644 cpu/bf533/bf533_serial.h delete mode 100644 cpu/bf533/cache.S delete mode 100644 cpu/bf533/config.mk delete mode 100644 cpu/bf533/cpu.c delete mode 100644 cpu/bf533/cpu.h delete mode 100644 cpu/bf533/flush.S delete mode 100644 cpu/bf533/init_sdram.S delete mode 100644 cpu/bf533/init_sdram_bootrom_initblock.S delete mode 100644 cpu/bf533/interrupt.S delete mode 100644 cpu/bf533/interrupts.c delete mode 100644 cpu/bf533/ints.c delete mode 100644 cpu/bf533/serial.c delete mode 100644 cpu/bf533/start.S delete mode 100644 cpu/bf533/traps.c delete mode 100644 cpu/bf533/video.c delete mode 100644 cpu/bf533/video.h delete mode 100644 cpu/bf537/Makefile delete mode 100644 cpu/bf537/cache.S delete mode 100644 cpu/bf537/config.mk delete mode 100644 cpu/bf537/cpu.c delete mode 100644 cpu/bf537/cpu.h delete mode 100644 cpu/bf537/flush.S delete mode 100644 cpu/bf537/init_sdram.S delete mode 100644 cpu/bf537/init_sdram_bootrom_initblock.S delete mode 100644 cpu/bf537/interrupt.S delete mode 100644 cpu/bf537/interrupts.c delete mode 100644 cpu/bf537/ints.c delete mode 100644 cpu/bf537/serial.c delete mode 100644 cpu/bf537/serial.h delete mode 100644 cpu/bf537/start.S delete mode 100644 cpu/bf537/start1.S delete mode 100644 cpu/bf537/traps.c delete mode 100644 cpu/bf537/video.c delete mode 100644 cpu/bf537/video.h delete mode 100644 cpu/bf561/Makefile delete mode 100644 cpu/bf561/cache.S delete mode 100644 cpu/bf561/config.mk delete mode 100644 cpu/bf561/cpu.c delete mode 100644 cpu/bf561/cpu.h delete mode 100644 cpu/bf561/flush.S delete mode 100644 cpu/bf561/init_sdram.S delete mode 100644 cpu/bf561/init_sdram_bootrom_initblock.S delete mode 100644 cpu/bf561/interrupt.S delete mode 100644 cpu/bf561/ints.c delete mode 100644 cpu/bf561/serial.c delete mode 100644 cpu/bf561/serial.h delete mode 100644 cpu/bf561/start.S delete mode 100644 cpu/bf561/start1.S delete mode 100644 cpu/bf561/traps.c delete mode 100644 cpu/bf561/video.c delete mode 100644 cpu/bf561/video.h create mode 100644 cpu/blackfin/.gitignore create mode 100644 cpu/blackfin/Makefile create mode 100755 cpu/blackfin/bootrom-asm-offsets.awk create mode 100644 cpu/blackfin/bootrom-asm-offsets.c.in create mode 100644 cpu/blackfin/cache.S create mode 100644 cpu/blackfin/cpu.c rename cpu/{bf533/start1.S => blackfin/cpu.h} (68%) create mode 100644 cpu/blackfin/flush.S rename cpu/{bf537 => blackfin}/i2c.c (75%) create mode 100644 cpu/blackfin/initcode.c create mode 100644 cpu/blackfin/interrupt.S rename cpu/{bf561 => blackfin}/interrupts.c (68%) create mode 100644 cpu/blackfin/reset.c create mode 100644 cpu/blackfin/serial.c create mode 100644 cpu/blackfin/serial.h create mode 100644 cpu/blackfin/start.S create mode 100644 cpu/blackfin/system_map.S create mode 100644 cpu/blackfin/traps.c create mode 100644 cpu/blackfin/watchdog.c rename board/bf537-stamp/ether_bf537.c => drivers/net/bfin_mac.c (77%) rename board/bf537-stamp/ether_bf537.h => drivers/net/bfin_mac.h (70%) delete mode 100644 lib_blackfin/bf533_linux.c delete mode 100644 lib_blackfin/bf533_string.c create mode 100644 lib_blackfin/bfin_string.c delete mode 100644 lib_blackfin/blackfin_board.h create mode 100644 lib_blackfin/boot.c delete mode 100644 lib_blackfin/cache.h
In message 200802230117.03679.vapier@gentoo.org you wrote:
Mike Frysinger (13): Blackfin: move bootldr command to common code Blackfin: convert BFIN_CPU to CONFIG_BFIN_CPU Blackfin: move on-chip MAC driver into drivers/net/ Blackfin: BF537-stamp: drop board-specific flash driver for CFI Blackfin: BF537-stamp: cleanup spi flash driver Blackfin: update MAINTAINERS list Blackfin: unify cpu and boot modes Blackfin: new cplbinfo command for viewing cplb tables Blackfin: add proper ELF markings to some assembly functions Blackfin: cleanup lib_blackfin/cache.c Blackfin: cleanup and overhaul common board init functions smc91111: use SSYNC() rather than asm(ssync) for Blackfin Blackfin: add error debug to serial driver
Hm... where are these changes coming from?
I don't think any of them have been poosted on the mailing list before?
And things like "new cplbinfo command" don't exactly look like bug fixesto me - remember that no merge window is open at the moment, so no new stuff may be added, just bugs fixed.
Please explain...
Best regards,
Wolfgang Denk
On Saturday 23 February 2008, Wolfgang Denk wrote:
In message 200802230117.03679.vapier@gentoo.org you wrote:
Mike Frysinger (13): Blackfin: move bootldr command to common code Blackfin: convert BFIN_CPU to CONFIG_BFIN_CPU Blackfin: move on-chip MAC driver into drivers/net/ Blackfin: BF537-stamp: drop board-specific flash driver for CFI Blackfin: BF537-stamp: cleanup spi flash driver Blackfin: update MAINTAINERS list Blackfin: unify cpu and boot modes Blackfin: new cplbinfo command for viewing cplb tables Blackfin: add proper ELF markings to some assembly functions Blackfin: cleanup lib_blackfin/cache.c Blackfin: cleanup and overhaul common board init functions smc91111: use SSYNC() rather than asm(ssync) for Blackfin Blackfin: add error debug to serial driver
Hm... where are these changes coming from?
i'm in the process of merging the u-boot fork that we've been using at blackfin.uclinux.org
I don't think any of them have been poosted on the mailing list before?
nope
And things like "new cplbinfo command" don't exactly look like bug fixesto me - remember that no merge window is open at the moment, so no new stuff may be added, just bugs fixed.
the Blackfin port in u-boot mainline has never worked, so i dont think it's a big deal ... and i still dont consider the mainline code "supported" until ive finished syncing all of the changes from the blackfin.uclinux.org svn into mainline. at that point, i can shut down our svn and switch it over to a read-only mirror of the git repo. -mike
In message 200802230359.32224.vapier@gentoo.org you wrote:
In message 200802230117.03679.vapier@gentoo.org you wrote:
Mike Frysinger (13): Blackfin: move bootldr command to common code Blackfin: convert BFIN_CPU to CONFIG_BFIN_CPU Blackfin: move on-chip MAC driver into drivers/net/ Blackfin: BF537-stamp: drop board-specific flash driver for CFI Blackfin: BF537-stamp: cleanup spi flash driver Blackfin: update MAINTAINERS list Blackfin: unify cpu and boot modes Blackfin: new cplbinfo command for viewing cplb tables Blackfin: add proper ELF markings to some assembly functions Blackfin: cleanup lib_blackfin/cache.c Blackfin: cleanup and overhaul common board init functions smc91111: use SSYNC() rather than asm(ssync) for Blackfin Blackfin: add error debug to serial driver
Hm... where are these changes coming from?
i'm in the process of merging the u-boot fork that we've been using at=20 blackfin.uclinux.org
I don't think any of them have been poosted on the mailing list before?
nope
Then that cannot go in now. We would break several rules at once: patches must be posted to the list first, and new stuff will get merged only when a merge window is open.
You shouldn't have sent this pull request now.
Best regards,
Wolfgang Denk
On Saturday 23 February 2008, Wolfgang Denk wrote:
In message 200802230359.32224.vapier@gentoo.org you wrote:
In message 200802230117.03679.vapier@gentoo.org you wrote:
Mike Frysinger (13): Blackfin: move bootldr command to common code Blackfin: convert BFIN_CPU to CONFIG_BFIN_CPU Blackfin: move on-chip MAC driver into drivers/net/ Blackfin: BF537-stamp: drop board-specific flash driver for CFI Blackfin: BF537-stamp: cleanup spi flash driver Blackfin: update MAINTAINERS list Blackfin: unify cpu and boot modes Blackfin: new cplbinfo command for viewing cplb tables Blackfin: add proper ELF markings to some assembly functions Blackfin: cleanup lib_blackfin/cache.c Blackfin: cleanup and overhaul common board init functions smc91111: use SSYNC() rather than asm(ssync) for Blackfin Blackfin: add error debug to serial driver
Hm... where are these changes coming from?
i'm in the process of merging the u-boot fork that we've been using at=20 blackfin.uclinux.org
I don't think any of them have been poosted on the mailing list before?
nope
Then that cannot go in now. We would break several rules at once: patches must be posted to the list first, and new stuff will get merged only when a merge window is open.
i understand where you're coming from, and i intend to follow the rules ... after Blackfin in mainline is actually usable. i'm being pragmatic here: since Blackfin literrally has never compiled/linked in the mainline releases, theres no way i could break it even more. delaying these updates to make mainline Blackfin u-boot usable is only that: delay.
as for posting the patches to the list, how do you know whether to merge it directly or pull from a repo ? -mike
On Sat, 23 Feb 2008 15:29:03 -0500 Mike Frysinger vapier@gentoo.org wrote:
i understand where you're coming from, and i intend to follow the rules ... after Blackfin in mainline is actually usable. i'm being pragmatic here: since Blackfin literrally has never compiled/linked in the mainline releases, theres no way i could break it even more. delaying these updates to make mainline Blackfin u-boot usable is only that: delay.
Come on, you know damn well it's not acceptable to add tons of new features (including, from the look of it, two new commands) this close to a release.
You should focus on getting the thing to work (why was it merged in the first place if it didn't work, btw?) not try to achieve feature-parity with the out-of-tree code.
There are way too many useless commands in the tree as it is, we don't want even more unreviewed crap sneaking in through the back door.
Haavard
On Saturday 23 February 2008, Haavard Skinnemoen wrote:
On Sat, 23 Feb 2008 15:29:03 -0500
Mike Frysinger vapier@gentoo.org wrote:
i understand where you're coming from, and i intend to follow the rules ... after Blackfin in mainline is actually usable. i'm being pragmatic here: since Blackfin literrally has never compiled/linked in the mainline releases, theres no way i could break it even more. delaying these updates to make mainline Blackfin u-boot usable is only that: delay.
Come on, you know damn well it's not acceptable to add tons of new features (including, from the look of it, two new commands) this close to a release.
i'd agree with you completely if Blackfin were currently usable
You should focus on getting the thing to work (why was it merged in the first place if it didn't work, btw?) not try to achieve feature-parity with the out-of-tree code.
ive had no involvement in the past development. if you want to say it sucked or complain about how it was done, i dont really care. only moving forward from the current situation matters to me.
as for getting it to work, i dont see the value in getting an old dead version of the Blackfin tree working when i have a clean rewritten tree to merge. if i get the old one to boot, so what ? the resulting code base isnt supported ... if someone says "i tried to do XYZ with the Blackfin code and it didnt work", i'm going to look at it and say "it works with this other code base, so i dont care. you can wait until i finish merging this tree."
There are way too many useless commands in the tree as it is, we don't want even more unreviewed crap sneaking in through the back door.
if you look at all the new commands you'll see that (1) they're optional and (2) they expose Blackfin specific functionality. these affect no other arches. -mike
On Sat, 23 Feb 2008 18:17:34 -0500 Mike Frysinger vapier@gentoo.org wrote:
ive had no involvement in the past development. if you want to say it sucked or complain about how it was done, i dont really care. only moving forward from the current situation matters to me.
I'm not saying it sucks. You're the one who said it's broken ;-)
as for getting it to work, i dont see the value in getting an old dead version of the Blackfin tree working when i have a clean rewritten tree to merge. if i get the old one to boot, so what ? the resulting code base isnt supported ... if someone says "i tried to do XYZ with the Blackfin code and it didnt work", i'm going to look at it and say "it works with this other code base, so i dont care. you can wait until i finish merging this tree."
That's why we do incremental improvements so that you can separate the fixes from the other stuff and submit them even if there isn't a merge window open.
There are way too many useless commands in the tree as it is, we don't want even more unreviewed crap sneaking in through the back door.
if you look at all the new commands you'll see that (1) they're optional and (2) they expose Blackfin specific functionality. these affect no other arches.
First, if they're blackfin-specific, what are they doing under common/?
Second, the SPI driver that broke the tree for almost four weeks was optional and ppc-specific. Have you run tests on all architectures so that you can be 100% sure that you're not breaking anything this late in the release cycle?
The avr32 architecture broke three times during the Linux 2.6.25-rc1 merge window, as did lots of other architectures (which isn't a huge deal since it was, after all, during the merge window, but it breaks bisectability). In two of the cases it was caused by patches that were deemed so simple that they didn't get proper review and were never exposed in -mm.
Which is why I've been a bit grumpy lately with respect to real and potential breakage in mainline, in case anyone wondered.
Your tree touches common code and you're asking for it to be merged without any review at all. I don't think that's a good idea.
Haavard
On Saturday 23 February 2008, Haavard Skinnemoen wrote:
Mike Frysinger vapier@gentoo.org wrote:
ive had no involvement in the past development. if you want to say it sucked or complain about how it was done, i dont really care. only moving forward from the current situation matters to me.
I'm not saying it sucks. You're the one who said it's broken ;-)
it is broken. broken as in it wont compile let alone link for any Blackfin code.
as for getting it to work, i dont see the value in getting an old dead version of the Blackfin tree working when i have a clean rewritten tree to merge. if i get the old one to boot, so what ? the resulting code base isnt supported ... if someone says "i tried to do XYZ with the Blackfin code and it didnt work", i'm going to look at it and say "it works with this other code base, so i dont care. you can wait until i finish merging this tree."
That's why we do incremental improvements so that you can separate the fixes from the other stuff and submit them even if there isn't a merge window open.
it's already been done
There are way too many useless commands in the tree as it is, we don't want even more unreviewed crap sneaking in through the back door.
if you look at all the new commands you'll see that (1) they're optional and (2) they expose Blackfin specific functionality. these affect no other arches.
First, if they're blackfin-specific, what are they doing under common/?
my understanding was that all commands go in common/. there's plenty of arch-specific commands in there already.
Second, the SPI driver that broke the tree for almost four weeks was optional and ppc-specific. Have you run tests on all architectures so that you can be 100% sure that you're not breaking anything this late in the release cycle?
i make my things conditionally compiled (see the Makefile). so yes, i'm 100% sure i'm not breaking anyone. if you add the CONFIG_xxx to your board config, well that's your fault ;).
Your tree touches common code
Blackfin-specific pieces of common code ... there's a difference
you're asking for it to be merged without any review at all. I don't think that's a good idea.
i'm asking for the Blackfin pieces to be merged regardless of "merge window". i'm making no requests wrt review. Wolfgang wants it reviewed first -- i'm fine with that. complaining that Blackfin changes are going in that arent "pure fixes" i dont care about (right now). -mike
In message 200802231907.22816.vapier@gentoo.org you wrote:
you're asking for it to be merged without any review at all. I don't think that's a good idea.
i'm asking for the Blackfin pieces to be merged regardless of "merge window".
I already said "no", and I see no reason to reconsider.
i'm making no requests wrt review. Wolfgang wants it reviewed first -- i'm fine with that. complaining that Blackfin changes are going in that arent "pure fixes" i dont care about (right now).
Hm.. you did read http://www.denx.de/wiki/UBoot/DevelopmentProcess - didn't you?
Best regards,
Wolfgang Denk
On Saturday 23 February 2008, Wolfgang Denk wrote:
In message 200802231907.22816.vapier@gentoo.org you wrote:
you're asking for it to be merged without any review at all. I don't think that's a good idea.
i'm asking for the Blackfin pieces to be merged regardless of "merge window".
I already said "no", and I see no reason to reconsider.
then the Blackfin tree stays broken. whatever, no skin off my back.
i'm making no requests wrt review. Wolfgang wants it reviewed first -- i'm fine with that. complaining that Blackfin changes are going in that arent "pure fixes" i dont care about (right now).
Hm.. you did read http://www.denx.de/wiki/UBoot/DevelopmentProcess - didn't you?
of course i have. writing out rules is to codify the spirit of the process so that people can jump in and know how things works. however, the point of the rules isnt to have a rigid unchanging methodology, but to keep things flowing in the spirit: merge windows allow new fun stuff while the non-merge time is for bugfixes only. this of course assumes that the tree in question is stable/usable in the first place. if it isnt, then there isnt much point to locking out changes to move it in that direction. -mike
In message 200802231939.51739.vapier@gentoo.org you wrote:
of course i have. writing out rules is to codify the spirit of the process so that people can jump in and know how things works. however, the point of the rules isnt to have a rigid unchanging methodology, but to keep things flowing in the spirit: merge windows allow new fun stuff while the non-merge time is for bugfixes only. this of course assumes that the tree in question is stable/usable in the first place. if it isnt, then there isnt much point to locking out changes to move it in that direction.
The tree in general is actually pretty stable/usable as of now; I know only of a few (minor) problems.
If the BF stuff is in bad shape, then I'm sorry about this, but 1) you could have posted your stuff in the merge window like everybody else, or 2) you have to wait until the next merge window like everybody else. I will not destabilize the whole tree for a single architecture.
If you have bug fixes, please go on and post these and I will make sure they go in as fast as possible.
But I will not add major new code now.
Best regards,
Wolfgang Denk
On Saturday 23 February 2008, Wolfgang Denk wrote:
In message 200802231939.51739.vapier@gentoo.org you wrote:
of course i have. writing out rules is to codify the spirit of the process so that people can jump in and know how things works. however, the point of the rules isnt to have a rigid unchanging methodology, but to keep things flowing in the spirit: merge windows allow new fun stuff while the non-merge time is for bugfixes only. this of course assumes that the tree in question is stable/usable in the first place. if it isnt, then there isnt much point to locking out changes to move it in that direction.
The tree in general is actually pretty stable/usable as of now; I know only of a few (minor) problems.
If the BF stuff is in bad shape, then I'm sorry about this, but 1) you could have posted your stuff in the merge window like everybody else, or 2) you have to wait until the next merge window like everybody else. I will not destabilize the whole tree for a single architecture.
If you have bug fixes, please go on and post these and I will make sure they go in as fast as possible.
But I will not add major new code now.
wrt Blackfin, those statements are conflicting. fixing the Blackfin tree involves major new code. of the changes i posted, only 2 or 3 touch Blackfin-specific pieces in files outside of Blackfin trees, and do so in a controlled manner (obj-$(CONFIG) in the Makefiles). those are not generally "bugfix" in nature though.
but you dont really care: it's big changes that havent been posted to the u-boot list for review, only been reviewed in the Blackfin fork on blackfin.uclinux.org by our team / customers over the last year. -mike
In message 200802232037.40287.vapier@gentoo.org you wrote:
wrt Blackfin, those statements are conflicting. fixing the Blackfin tree involves major new code. of the changes i posted, only 2 or 3 touch
Then it has to wait until the next merge window. That won't take that long.
but you dont really care: it's big changes that havent been posted to the u-boot list for review, only been reviewed in the Blackfin fork on blackfin.uclinux.org by our team / customers over the last year.
If I didn't care I would not continue to try to explain all this to you.
Best regards,
Wolfgang Denk
On Sat, 23 Feb 2008 19:07:22 -0500 Mike Frysinger vapier@gentoo.org wrote:
That's why we do incremental improvements so that you can separate the fixes from the other stuff and submit them even if there isn't a merge window open.
it's already been done
Then how come you're still trying to push 400k changesets outside the merge window?
my understanding was that all commands go in common/. there's plenty of arch-specific commands in there already.
I still think it's wrong...although if there's an existing consensus that all commands go under common/, I'm not going to argue further against it.
Second, the SPI driver that broke the tree for almost four weeks was optional and ppc-specific. Have you run tests on all architectures so that you can be 100% sure that you're not breaking anything this late in the release cycle?
i make my things conditionally compiled (see the Makefile). so yes, i'm 100% sure i'm not breaking anyone. if you add the CONFIG_xxx to your board config, well that's your fault ;).
Famous last words ;)
I take it you're absolutely sure that the new CONFIG_xxx symbols aren't already being used anywhere?
Your tree touches common code
Blackfin-specific pieces of common code ... there's a difference
Isn't that a contradiction? If it's blackfin-specific, it can't really be common, can it?
And are you sure that the commands cannot be reworked to be usable on other architectures as well? That sort of thing might come out of a review, you know...
you're asking for it to be merged without any review at all. I don't think that's a good idea.
i'm asking for the Blackfin pieces to be merged regardless of "merge window". i'm making no requests wrt review. Wolfgang wants it reviewed first -- i'm fine with that. complaining that Blackfin changes are going in that arent "pure fixes" i dont care about (right now).
Ok, I'm not all that concerned about the Blackfin stuff. But I think that, at a minimum, the stuff under common/ and drivers/ should be posted for review, and the stuff under driver/net should preferably go in through the Networking custodian.
Haavard
On Saturday 23 February 2008, Haavard Skinnemoen wrote:
Mike Frysinger vapier@gentoo.org wrote:
That's why we do incremental improvements so that you can separate the fixes from the other stuff and submit them even if there isn't a merge window open.
it's already been done
Then how come you're still trying to push 400k changesets outside the merge window?
as i said, i find the merge window irrelevant to Blackfin as until i'm done merging the external fork back into mainline. Wolfgang disagrees which means the process of getting Blackfin working is delayed.
my understanding was that all commands go in common/. there's plenty of arch-specific commands in there already.
I still think it's wrong...although if there's an existing consensus that all commands go under common/, I'm not going to argue further against it.
i'd agree as i used to put Blackfin specific commands in lib_blackfin/. but i figured folding back might as well go the currently accepted route. doesnt matter to me one way or the other.
Second, the SPI driver that broke the tree for almost four weeks was optional and ppc-specific. Have you run tests on all architectures so that you can be 100% sure that you're not breaking anything this late in the release cycle?
i make my things conditionally compiled (see the Makefile). so yes, i'm 100% sure i'm not breaking anyone. if you add the CONFIG_xxx to your board config, well that's your fault ;).
Famous last words ;)
I take it you're absolutely sure that the new CONFIG_xxx symbols aren't already being used anywhere?
grep says only Blackfin
Your tree touches common code
Blackfin-specific pieces of common code ... there's a difference
Isn't that a contradiction?
no ...
If it's blackfin-specific, it can't really be common, can it?
i'm just working with how u-boot is designed. u-boot has common code that has '#ifdef CONFIG_<ARCH>' and that is where the changes for Blackfin are.
And are you sure that the commands cannot be reworked to be usable on other architectures as well? That sort of thing might come out of a review, you know...
unless some other architecture is designing cache tables the same way as Blackfin, or designing their boot process to use the same exact file format that the Blackfin uses, then i doubt it's useful to anyone else.
you're asking for it to be merged without any review at all. I don't think that's a good idea.
i'm asking for the Blackfin pieces to be merged regardless of "merge window". i'm making no requests wrt review. Wolfgang wants it reviewed first -- i'm fine with that. complaining that Blackfin changes are going in that arent "pure fixes" i dont care about (right now).
Ok, I'm not all that concerned about the Blackfin stuff. But I think that, at a minimum, the stuff under common/ and drivers/ should be posted for review, and the stuff under driver/net should preferably go in through the Networking custodian.
i plan on taking them out of the public repo and posting them for review -mike
On 01:35 Sun 24 Feb , Haavard Skinnemoen wrote:
On Sat, 23 Feb 2008 19:07:22 -0500 Mike Frysinger vapier@gentoo.org wrote:
Your tree touches common code
Blackfin-specific pieces of common code ... there's a difference
Isn't that a contradiction? If it's blackfin-specific, it can't really be common, can it?
And are you sure that the commands cannot be reworked to be usable on other architectures as well? That sort of thing might come out of a review, you know...
As example the SPI flash will be good to merge it to the common drivers/mtd and be usable on other architectures
Best Regards, J.
On Sunday 24 February 2008, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 01:35 Sun 24 Feb , Haavard Skinnemoen wrote:
Mike Frysinger vapier@gentoo.org wrote:
Your tree touches common code
Blackfin-specific pieces of common code ... there's a difference
Isn't that a contradiction? If it's blackfin-specific, it can't really be common, can it?
And are you sure that the commands cannot be reworked to be usable on other architectures as well? That sort of thing might come out of a review, you know...
As example the SPI flash will be good to merge it to the common drivers/mtd and be usable on other architectures
which is already being done and no reason to hold up merging of code that affects Blackfin boards only -mike
In message 200802231529.04407.vapier@gentoo.org you wrote:
Then that cannot go in now. We would break several rules at once: patches must be posted to the list first, and new stuff will get merged only when a merge window is open.
since Blackfin literrally has never compiled/linked in the mainline releases, theres no way i could break it even more. delaying these updates to make mainline Blackfin u-boot usable is only that: delay.
Still the patches need to be reviewed first.
as for posting the patches to the list, how do you know whether to merge it directly or pull from a repo ?
In cases like this one, where there is a custodian who caresa about the topic of the patches, I wait for his pull request and then pull from the repo. The posting of the patches is primarily for giving others a chance to review the stuff *before* it goes into mainline.
Best regards,
Wolfgang Denk
On Saturday 23 February 2008, Wolfgang Denk wrote:
In message 200802231529.04407.vapier@gentoo.org you wrote:
Then that cannot go in now. We would break several rules at once: patches must be posted to the list first, and new stuff will get merged only when a merge window is open.
since Blackfin literrally has never compiled/linked in the mainline releases, theres no way i could break it even more. delaying these updates to make mainline Blackfin u-boot usable is only that: delay.
Still the patches need to be reviewed first.
fair enough. i'd point out for the cpu unification, the patch is 400k and i'm not about to go splitting it up just so the mailing list will accept it. if people actually care, they can read the diff in the git tree.
as for posting the patches to the list, how do you know whether to merge it directly or pull from a repo ?
In cases like this one, where there is a custodian who caresa about the topic of the patches, I wait for his pull request and then pull from the repo. The posting of the patches is primarily for giving others a chance to review the stuff *before* it goes into mainline.
so for all Blackfin patches, i'll post them and people may review them, but you wont merge them until i put them into my tree for you to pull ? -mike
In message 200802231819.56414.vapier@gentoo.org you wrote:
Still the patches need to be reviewed first.
fair enough. i'd point out for the cpu unification, the patch is 400k and i'm not about to go splitting it up just so the mailing list will accept it. if people actually care, they can read the diff in the git tree.
Mike, this is not the way you are supposed to react - not as a norman developer, and escpecially not as a custodian.
You want the stuff to go in, so please make it easy for us to review it.
In cases like this one, where there is a custodian who caresa about the topic of the patches, I wait for his pull request and then pull from the repo. The posting of the patches is primarily for giving others a chance to review the stuff *before* it goes into mainline.
so for all Blackfin patches, i'll post them and people may review them, but you wont merge them until i put them into my tree for you to pull ?
Correct - except that you already have those patches in some git repository, because otherwise you could not use git-format-patch and git-send-email to prepare resp. to send the patches.
Best regards,
Wolfgang Denk
On Saturday 23 February 2008, Wolfgang Denk wrote:
In message 200802231819.56414.vapier@gentoo.org you wrote:
Still the patches need to be reviewed first.
fair enough. i'd point out for the cpu unification, the patch is 400k and i'm not about to go splitting it up just so the mailing list will accept it. if people actually care, they can read the diff in the git tree.
Mike, this is not the way you are supposed to react - not as a norman developer, and escpecially not as a custodian.
You want the stuff to go in, so please make it easy for us to review it.
if you force us to use the mailing list (which is fine), then it should be easy to use the mailing list (which if i recall from the last time this came up, you arent going to change).
In cases like this one, where there is a custodian who caresa about the topic of the patches, I wait for his pull request and then pull from the repo. The posting of the patches is primarily for giving others a chance to review the stuff *before* it goes into mainline.
so for all Blackfin patches, i'll post them and people may review them, but you wont merge them until i put them into my tree for you to pull ?
Correct - except that you already have those patches in some git repository, because otherwise you could not use git-format-patch and git-send-email to prepare resp. to send the patches.
i'm not sure what you're trying to say. of course git-format-patch only works on patches that have been committed to a repo. -mike
In message 200802231909.43013.vapier@gentoo.org you wrote:
You want the stuff to go in, so please make it easy for us to review it.
if you force us to use the mailing list (which is fine), then it should be
This is the rules we agreed on. See http://www.denx.de/wiki/UBoot/DevelopmentProcess and http://www.denx.de/wiki/UBoot/Patches
easy to use the mailing list (which if i recall from the last time this came up, you arent going to change).
What do you mean? The size limit? We have a soft-limit of 40 k and a hard limit of 100k and a description for exceptions in http://www.denx.de/wiki/UBoot/Patches
But this doesn't save you from splitting your changes into small, orthogonal pieces.
so for all Blackfin patches, i'll post them and people may review them, but you wont merge them until i put them into my tree for you to pull ?
Correct - except that you already have those patches in some git repository, because otherwise you could not use git-format-patch and git-send-email to prepare resp. to send the patches.
i'm not sure what you're trying to say. of course git-format-patch only works on patches that have been committed to a repo.
I tried to answer your question - you asked "you wont merge them until i put them into my tree" and I confirmed this (as this is what a pull request from a custodian means). Your question seemed to imply that this was additional effort for you, so I tried to explain that it ain't, as you will already have such a repository ready to pull from (or rather to push into the custodia's repo from where I will pull) because you needed it to send the patches to the mailing list, and without sending patches first you cannot send a pull request.
Sorry if this sounds complicated. See http://www.denx.de/wiki/UBoot/DevelopmentProcess for details.
Best regards,
Wolfgang Denk
On Saturday 23 February 2008, Wolfgang Denk wrote:
In message 200802231909.43013.vapier@gentoo.org you wrote:
You want the stuff to go in, so please make it easy for us to review it.
easy to use the mailing list (which if i recall from the last time this came up, you arent going to change).
What do you mean? The size limit? We have a soft-limit of 40 k and a hard limit of 100k and a description for exceptions in http://www.denx.de/wiki/UBoot/Patches
But this doesn't save you from splitting your changes into small, orthogonal pieces.
the last thread i read you said it was going to stay at 40k and 100k was not going to happen.
so for all Blackfin patches, i'll post them and people may review them, but you wont merge them until i put them into my tree for you to pull ?
Correct - except that you already have those patches in some git repository, because otherwise you could not use git-format-patch and git-send-email to prepare resp. to send the patches.
i'm not sure what you're trying to say. of course git-format-patch only works on patches that have been committed to a repo.
I tried to answer your question - you asked "you wont merge them until i put them into my tree" and I confirmed this (as this is what a pull request from a custodian means). Your question seemed to imply that this was additional effort for you, so I tried to explain that it ain't, as you will already have such a repository ready to pull from (or rather to push into the custodia's repo from where I will pull) because you needed it to send the patches to the mailing list, and without sending patches first you cannot send a pull request.
i know how to format/email patches from git. i just wasnt sure you were telling/implying anything i didnt already know. it would seem not.
Sorry if this sounds complicated. See http://www.denx.de/wiki/UBoot/DevelopmentProcess for details.
i dont think it's complicated at all -mike
In message 200802232018.35652.vapier@gentoo.org you wrote:
the last thread i read you said it was going to stay at 40k and 100k was not going to happen.
I said I would not change the list's message size limit on the SourceForge server. Messages that exceed this size (40 kB = that's what I called soft-limit) need moderation. I will check these, and unless they are reasonable and below 100 kB I've been ACKimg these since that discussion.
i dont think it's complicated at all
Great. Then please play by those rules.
Best regards,
Wolfgang Denk
participants (4)
-
Haavard Skinnemoen -
Jean-Christophe PLAGNIOL-VILLARD -
Mike Frysinger -
Wolfgang Denk