powerpc: Restore core of mpc8xx

Signed-off-by Christophe Leroy <[email protected]>

---
v3: Fixed build error in arch/powerpc/include/asm/ppc.h ; removed commproc.h from 4xx

v2: Tom squashed patches 1-10 of the serie

  .travis.yml                            |    2 +
  MAINTAINERS                            |    7 +-
  README                                 |  104 ++-
  api/api_platform-powerpc.c             |    3 +-
  arch/powerpc/Kconfig                   |    4 +
  arch/powerpc/cpu/mpc8xx/Kconfig        |   13 +
  arch/powerpc/cpu/mpc8xx/Makefile       |   25 +
  arch/powerpc/cpu/mpc8xx/bedbug_860.c   |  314 ++++++++
  arch/powerpc/cpu/mpc8xx/config.mk      |    8 +
  arch/powerpc/cpu/mpc8xx/cpu.c          |  580 +++++++++++++
  arch/powerpc/cpu/mpc8xx/cpu_init.c     |  218 +++++
  arch/powerpc/cpu/mpc8xx/fdt.c          |   27 +
  arch/powerpc/cpu/mpc8xx/fec.c          |  933 +++++++++++++++++++++
  arch/powerpc/cpu/mpc8xx/fec.h          |   12 +
  arch/powerpc/cpu/mpc8xx/interrupts.c   |  278 +++++++
  arch/powerpc/cpu/mpc8xx/kgdb.S         |   54 ++
  arch/powerpc/cpu/mpc8xx/plprcr_write.S |  119 +++
  arch/powerpc/cpu/mpc8xx/scc.c          |  472 +++++++++++
  arch/powerpc/cpu/mpc8xx/serial.c       |  676 ++++++++++++++++
  arch/powerpc/cpu/mpc8xx/speed.c        |  385 +++++++++
  arch/powerpc/cpu/mpc8xx/spi.c          |  533 ++++++++++++
  arch/powerpc/cpu/mpc8xx/start.S        |  650 +++++++++++++++
  arch/powerpc/cpu/mpc8xx/traps.c        |  216 +++++
  arch/powerpc/cpu/mpc8xx/upatch.c       |  194 +++++
  arch/powerpc/cpu/mpc8xx/video.c        | 1123 ++++++++++++++++++++++++++
  arch/powerpc/include/asm/8xx_immap.h   |  515 ++++++++++++
  arch/powerpc/include/asm/cache.h       |   41 +-
  arch/powerpc/include/asm/global_data.h |    3 +
  arch/powerpc/include/asm/iopin_8xx.h   |  379 +++++++++
  arch/powerpc/include/asm/ppc.h         |   16 +
  arch/powerpc/include/asm/processor.h   |   17 +-
  arch/powerpc/include/asm/status_led.h  |   73 ++
  arch/powerpc/lib/Makefile              |    1 +
  arch/powerpc/lib/ide.c                 |  184 +++++
  arch/powerpc/lib/ide.h                 |   15 +
  arch/powerpc/lib/immap.c               |  564 +++++++++++++
  arch/powerpc/lib/time.c                |   11 +
  cmd/bdinfo.c                           |    3 +-
  cmd/bedbug.c                           |    4 +
  cmd/ide.c                              |    9 +-
  cmd/pcmcia.c                           |    4 +
  cmd/reginfo.c                          |   59 +-
  cmd/source.c                           |    3 +
  common/board_f.c                       |    5 +-
  common/board_r.c                       |   14 +
  common/bootm_os.c                      |   14 +-
  common/lcd.c                           |    4 +
  doc/README.MPC866                      |   24 +
  doc/README.fsl-clk                     |    5 +
  doc/README.scrapyard                   |    1 +
  drivers/block/ide.c                    |   11 +
  drivers/block/sil680.c                 |    1 +
  drivers/bootcount/bootcount.c          |    5 +
  drivers/i2c/i2c_core.c                 |   11 +
  drivers/i2c/soft_i2c.c                 |    4 +
  drivers/net/4xx_enet.c                 |    1 +
  drivers/pcmcia/Makefile                |    1 +
  drivers/pcmcia/mpc8xx_pcmcia.c         |  258 ++++++
  drivers/rtc/Makefile                   |    1 +
  drivers/rtc/mpc8xx.c                   |   60 ++
  drivers/serial/serial.c                |    3 -
  drivers/usb/gadget/Makefile            |    1 +
  drivers/usb/gadget/mpc8xx_udc.c        | 1386 ++++++++++++++++++++++++++++++++
  drivers/video/Makefile                 |    1 +
  drivers/video/mpc8xx_lcd.c             |  400 +++++++++
  examples/standalone/Makefile           |    2 +
  examples/standalone/test_burst.c       |  284 +++++++
  examples/standalone/test_burst.h       |   22 +
  examples/standalone/test_burst_lib.S   |  154 ++++
  examples/standalone/timer.c            |  333 ++++++++
  include/asm-generic/global_data.h      |    2 +-
  include/asm-generic/u-boot.h           |    3 +-
  include/commproc.h                     |  791 ++++++++++++++++++
  include/configs/CPCI4052.h             |    1 +
  include/configs/MIP405.h               |    1 +
  include/configs/PIP405.h               |    1 +
  include/configs/PLU405.h               |    1 +
  include/i2c.h                          |   24 +-
  include/lcd.h                          |    4 +-
  include/mpc823_lcd.h                   |   44 +
  include/net.h                          |    4 +
  include/pcmcia.h                       |   16 +-
  include/post.h                         |    7 +-
  include/ppc_asm.tmpl                   |   46 ++
  include/usb/mpc8xx_udc.h               |  178 ++++
  include/watchdog.h                     |    5 +
  post/Makefile                          |    1 +
  post/cpu/mpc8xx/Makefile               |    9 +
  post/cpu/mpc8xx/cache.c                |   62 ++
  post/cpu/mpc8xx/cache_8xx.S            |  477 +++++++++++
  post/cpu/mpc8xx/ether.c                |  530 ++++++++++++
  post/cpu/mpc8xx/spr.c                  |  132 +++
  post/cpu/mpc8xx/uart.c                 |  508 ++++++++++++
  post/cpu/mpc8xx/usb.c                  |  249 ++++++
  post/cpu/mpc8xx/watchdog.c             |   59 ++
  post/tests.c                           |   12 +
  scripts/config_whitelist.txt           |   62 +-
  97 files changed, 15032 insertions(+), 54 deletions(-)

create mode 100644 arch/powerpc/cpu/mpc8xx/Kconfig create mode 100644 arch/powerpc/cpu/mpc8xx/Makefile create mode 100644 arch/powerpc/cpu/mpc8xx/bedbug_860.c create mode 100644 arch/powerpc/cpu/mpc8xx/config.mk create mode 100644 arch/powerpc/cpu/mpc8xx/cpu.c create mode 100644 arch/powerpc/cpu/mpc8xx/cpu_init.c create mode 100644 arch/powerpc/cpu/mpc8xx/fdt.c create mode 100644 arch/powerpc/cpu/mpc8xx/fec.c create mode 100644 arch/powerpc/cpu/mpc8xx/fec.h create mode 100644 arch/powerpc/cpu/mpc8xx/interrupts.c create mode 100644 arch/powerpc/cpu/mpc8xx/kgdb.S create mode 100644 arch/powerpc/cpu/mpc8xx/plprcr_write.S create mode 100644 arch/powerpc/cpu/mpc8xx/scc.c create mode 100644 arch/powerpc/cpu/mpc8xx/serial.c create mode 100644 arch/powerpc/cpu/mpc8xx/speed.c create mode 100644 arch/powerpc/cpu/mpc8xx/spi.c create mode 100644 arch/powerpc/cpu/mpc8xx/start.S create mode 100644 arch/powerpc/cpu/mpc8xx/traps.c create mode 100644 arch/powerpc/cpu/mpc8xx/upatch.c create mode 100644 arch/powerpc/cpu/mpc8xx/video.c create mode 100644 arch/powerpc/include/asm/8xx_immap.h create mode 100644 arch/powerpc/include/asm/iopin_8xx.h create mode 100644 arch/powerpc/include/asm/status_led.h create mode 100644 arch/powerpc/lib/ide.c
create mode 100644 arch/powerpc/lib/ide.h
create mode 100644 arch/powerpc/lib/immap.c create mode 100644 doc/README.MPC866
create mode 100644 doc/README.fsl-clk
create mode 100644 drivers/pcmcia/mpc8xx_pcmcia.c create mode 100644 drivers/rtc/mpc8xx.c
create mode 100644 drivers/usb/gadget/mpc8xx_udc.c create mode 100644 drivers/video/mpc8xx_lcd.c create mode 100644 examples/standalone/test_burst.c create mode 100644 examples/standalone/test_burst.h create mode 100644 examples/standalone/test_burst_lib.S create mode 100644 examples/standalone/timer.c create mode 100644 include/commproc.h
create mode 100644 include/mpc823_lcd.h
create mode 100644 include/usb/mpc8xx_udc.h

create mode 100644 post/cpu/mpc8xx/Makefile
create mode 100644 post/cpu/mpc8xx/cache.c
create mode 100644 post/cpu/mpc8xx/cache_8xx.S
create mode 100644 post/cpu/mpc8xx/ether.c
create mode 100644 post/cpu/mpc8xx/spr.c
create mode 100644 post/cpu/mpc8xx/uart.c
create mode 100644 post/cpu/mpc8xx/usb.c
create mode 100644 post/cpu/mpc8xx/watchdog.c

Signed-off-by Christophe Leroy <[email protected]>

---
v3: Fixed build error in arch/powerpc/include/asm/ppc.h ; removed commproc.h from 4xx

v2: Tom squashed patches 1-10 of the serie

Dear Christophe Leroy,

Quoted 4 lines · In message <[email protected]> you wrote:

Signed-off-by Christophe Leroy <[email protected]>

---
v3: Fixed build error in arch/powerpc/include/asm/ppc.h ; removed commproc.h from 4xx

Quoted 1 line

v2: Tom squashed patches 1-10 of the serie

Please see my previous comments to Tom's message. At least, please clean up the directory structure and get rid of unrelated (4xx) and untested/broken code (bedbug, probably kgdb, pcmcia, usb).

Also, are you going to support the whole family, including MPC823(E)? If not, we should also omit stuff like the 823 video support.

Quoted 4 lines

Please see my previous comments to Tom's message. At least, please clean up the directory structure and get rid of unrelated (4xx) and untested/broken code (bedbug, probably kgdb, pcmcia, usb).

I got 4xx unrelated stuff out in v3, as mentioned above.

Quoted 2 lines

Also, are you going to support the whole family, including MPC823(E)? If not, we should also omit stuff like the 823 video support.

I agree, but please no big-bang now. It is already complicated enough.

We have something that fits and that was unexpectedly removed entirely last week. Lets come back first to a well known - working situation and do the removal of unnecessary parts step by step as if we were 3 weeks ago. The more we wait to get 8xx back in, the more difficult it will be.

Dear Christophe,

Quoted 6 lines · In message <[email protected]> you wrote:

Quoted 4 lines

Please see my previous comments to Tom's message. At least, please clean up the directory structure and get rid of unrelated (4xx) and untested/broken code (bedbug, probably kgdb, pcmcia, usb).

I got 4xx unrelated stuff out in v3, as mentioned above.

I still see these files in your patch:

	drivers/net/4xx_enet.c
	include/configs/CPCI4052.h
	include/configs/MIP405.h
	include/configs/PIP405.h
	include/configs/PLU405.h

To me these look very much like PPC4xx related. In addition, it makes zero sense to keep PPC405 board config files without any related board code.

On the other hand I do not see a single board configuration for 8xx, so you cannot even compile the code for a MPC8xx board, or am I missing something?

Quoted 7 lines

Quoted 5 lines

Also, are you going to support the whole family, including MPC823(E)? If not, we should also omit stuff like the 823 video support.

I agree, but please no big-bang now. It is already complicated enough.

I try to get used to the idea of doing code level cleanup later, even though my personal feeling for re-adding known-to-be-broken code is not exactly positive.

But at least at file level we should perform the needed cleanup now:
- omit unrelated stuff
- omit known to be unsupported/untested/broken code
- move drivers to the correct places according to today's file system hierarchy.

As I explained before, I doubt that you will be able to test things like drivers/video/mpc8xx_lcd.c on your boards, and I strongly doubt that you are willing to invest efforts in adapting and testing things like PCMCIA, bedbug, SIL680 support, or USB on your hardware.

[In which way is the sil680 driver related to mpx8xx, btw?]

So when we know in advance that this old, crappy code will never be tested, why should we spend effforts even in adding it?

Quoted 5 lines

We have something that fits and that was unexpectedly removed entirely last week. Lets come back first to a well known - working situation and do the removal of unnecessary parts step by step as if we were 3 weeks ago. The more we wait to get 8xx back in, the more difficult it will be.

To be frank: you don't have a very extensive track record of working with the U-Boot community. At the moment all we have is your claim that you will care about 8xx in the furture. In the past, we have seen many precedents of "please add this code now, I know it is not really good, but I will fix it later, promised" - and then the code was in mainline, until somebody else digged into cleaning it up.

I've been using MPC8xx for 18 years, and I know all too well in how many places the code is in urgent need of a cleanup (heck, I'm even responsible for major parts of that mess - but those were the times way back then). I'm not sure if you already anticipate the size of job you have taken. Just looking at the POST code - are you aware how much effort it will be to adapt it to your board and to test it? And this is mandatory requirement if you want to have it added. It must be maintained, i. e. tested.

It would be very sad if we add this code now, and in a few weeks/months you say: oh, we don't need this, and I don't find time to care about it, let's remove it again. And this is what's bound to happen - I bet a beer or two that you have never used most of this code before, nor had a look at the code.

I think it is much, much better to perform at least the file level cleanup in a sngle step right at the beginning, starting with the minimum set of needed files for your system. Adding needed things later is a much better guaranteee for good code than removing unmaintained crap when it starts hurting.

So please check your own board configuration and come up with a list of needed features, and re-add only those, cleaning up file hierarchy while you go. See .sig below (non-random today).

Thanks.

Best regards,

Wolfgang Denk

Quoted 10 lines

Dear Christophe,

Quoted 6 lines · In message <[email protected]> you wrote:

Quoted 4 lines

Please see my previous comments to Tom's message. At least, please clean up the directory structure and get rid of unrelated (4xx) and untested/broken code (bedbug, probably kgdb, pcmcia, usb).

I got 4xx unrelated stuff out in v3, as mentioned above.

Quoted 7 lines

I still see these files in your patch:

    drivers/net/4xx_enet.c
    include/configs/CPCI4052.h
    include/configs/MIP405.h
    include/configs/PIP405.h
    include/configs/PLU405.h

Those are

#undef CONFIG_IDE_8xx_DIRECT

My patch brings back CONFIG_IDE_8xx_DIRECT, so if somebody has decided that this CONFIG_ shall explicitly be undefined for 4xx targets, I believe there is a reason and I cannot decide by myself to remove that.

Quoted 3 lines

To me these look very much like PPC4xx related. In addition, it makes zero sense to keep PPC405 board config files without any related board code.

Why do you say that ? There is a lot of code in arch/powerpc/ppc4xx/ and in configs/ you find the following defconfigs:

Quoted 3 lines

On the other hand I do not see a single board configuration for 8xx, so you cannot even compile the code for a MPC8xx board, or am I missing something?

Yes you are right, Tom asked me to bring back only the core part for the time being, until I have cleaned up the code for our two boards.

Quoted 16 lines

Quoted 4 lines

Quoted 2 lines

Also, are you going to support the whole family, including MPC823(E)? If not, we should also omit stuff like the 823 video support.

I agree, but please no big-bang now. It is already complicated enough.

I try to get used to the idea of doing code level cleanup later, even though my personal feeling for re-adding known-to-be-broken code is not exactly positive.

But at least at file level we should perform the needed cleanup now:
- omit unrelated stuff
- omit known to be unsupported/untested/broken code
- move drivers to the correct places according to today's file system hierarchy.

Quoted 4 lines

As I explained before, I doubt that you will be able to test things like drivers/video/mpc8xx_lcd.c on your boards, and I strongly doubt that you are willing to invest efforts in adapting and testing things like PCMCIA, bedbug, SIL680 support, or USB on your hardware.

Yes I agree, that's probably the first things I will remove (except USB probably).

Quoted 5 lines

[In which way is the sil680 driver related to mpx8xx, btw?]

So when we know in advance that this old, crappy code will never be tested, why should we spend effforts even in adding it?

Just because it was there 2 weeks ago. I prefer starting from a known situation.

Quoted 11 lines

Quoted 4 lines

We have something that fits and that was unexpectedly removed entirely last week. Lets come back first to a well known - working situation and do the removal of unnecessary parts step by step as if we were 3 weeks ago. The more we wait to get 8xx back in, the more difficult it will be.

To be frank: you don't have a very extensive track record of working with the U-Boot community. At the moment all we have is your claim that you will care about 8xx in the furture. In the past, we have seen many precedents of "please add this code now, I know it is not really good, but I will fix it later, promised" - and then the code was in mainline, until somebody else digged into cleaning it up.

Well, I don't know what to answer to that, I understand your reluctance but you probably also understand mine, I try crawling in one direction to get my boards in while others are removing more and more stuff (51xx, 82xx, 5xx ...) which makes the come back of 8xx more difficult each day.

Quoted 8 lines

I've been using MPC8xx for 18 years, and I know all too well in how many places the code is in urgent need of a cleanup (heck, I'm even responsible for major parts of that mess - but those were the times way back then). I'm not sure if you already anticipate the size of job you have taken. Just looking at the POST code - are you aware how much effort it will be to adapt it to your board and to test it? And this is mandatory requirement if you want to have it added. It must be maintained, i. e. tested.

We have it running on our boards and it works, it is just not in a clean submittable (doesn't respect the Codying Style, has several hard coded stuff in core parts, etc ...), so I cannot submit

it just now, and I fear that by end august/early septembre, when I come with my cleaned board code, so much modification have been done to uboot core that 8xx cannot be back without tones of reverts.

Quoted 7 lines

It would be very sad if we add this code now, and in a few weeks/months you say: oh, we don't need this, and I don't find time to care about it, let's remove it again. And this is what's bound to happen - I bet a beer or two that you have never used most of this code before, nor had a look at the code.

Quoted 6 lines

I think it is much, much better to perform at least the file level cleanup in a sngle step right at the beginning, starting with the minimum set of needed files for your system. Adding needed things later is a much better guaranteee for good code than removing unmaintained crap when it starts hurting.

Ok but please stop removing or deapply modifying additional stuff that impacts the 8xx.

Quoted 3 lines

So please check your own board configuration and come up with a list of needed features, and re-add only those, cleaning up file hierarchy while you go. See .sig below (non-random today).

Yes but that's not something that is doable in a few hours. So be compassionate and don't jeopardise it.

Thanks
Christophe

Quoted 7 lines

Thanks.

Best regards,

Wolfgang Denk

Hello Christophe,

Am 22.06.2017 um 13:20 schrieb Christophe LEROY:

Quoted 25 lines · Wolfgang Denk

Quoted 10 lines

Dear Christophe,

Quoted 6 lines · In message <[email protected]> you wrote:

Quoted 4 lines

Please see my previous comments to Tom's message. At least, please clean up the directory structure and get rid of unrelated (4xx) and untested/broken code (bedbug, probably kgdb, pcmcia, usb).

I got 4xx unrelated stuff out in v3, as mentioned above.

Quoted 7 lines

I still see these files in your patch:

    drivers/net/4xx_enet.c
    include/configs/CPCI4052.h
    include/configs/MIP405.h
    include/configs/PIP405.h
    include/configs/PLU405.h

Those are

#undef CONFIG_IDE_8xx_DIRECT

Quoted 5 lines

My patch brings back CONFIG_IDE_8xx_DIRECT, so if somebody has decided that this CONFIG_ shall
explicitly be undefined for 4xx targets, I believe there is a reason and I cannot decide by myself
to remove that.

That;s exactly a part of crap ... now, as this symbol is gone, no need for it to undef it in some none 8xx configs ...

Quoted 5 lines

Quoted 4 lines

To me these look very much like PPC4xx related. In addition, it makes zero sense to keep PPC405 board config files without any related board code.

Review

Quoted 11 lines

Why do you say that ? There is a lot of code in arch/powerpc/ppc4xx/ and in configs/ you find the
following defconfigs:

(quoted diff) +0 -8

-rw-r--r--. 1 root root 641 Jun 22 01:34 CPCI4052_defconfig
-rw-r--r--. 1 root root 871 Jun 22 01:34 MIP405_defconfig
-rw-r--r--. 1 root root 799 Jun 22 01:34 MIP405T_defconfig
-rw-r--r--. 1 root root 869 Jun 22 01:34 PIP405_defconfig
-rw-r--r--. 1 root root 675 Jun 22 01:34 PLU405_defconfig
-rw-r--r--. 1 root root 588 Jun 22 01:34 PMC405DE_defconfig
-rw-r--r--. 1 root root 449 Jun 22 01:34 VOM405_defconfig
-rw-r--r--. 1 root root 747 Jun 22 01:34 xilinx-ppc405-generic_defconfig

Actually I have the 4xx removal patches on my todo list, but did not find time yet to submit these. I hope I will find time for this next week. As far as the MPC8xx discussion is related, please consider 4xx as removed, too.

Quoted 5 lines

Quoted 4 lines

On the other hand I do not see a single board configuration for 8xx, so you cannot even compile the code for a MPC8xx board, or am I missing something?

Quoted 3 lines

Yes you are right, Tom asked me to bring back only the core part for the time being, until I have
cleaned up the code for our two boards.

Ok... but should we not have at least one (minimal) board configuration so you can at least build the code and see if it compiles? Whithout such test, the risk of broken, non-compiling code is huge!

Quoted 22 lines

Quoted 21 lines

Quoted 5 lines

Quoted 3 lines

Also, are you going to support the whole family, including MPC823(E)? If not, we should also omit stuff like the 823 video support.

I agree, but please no big-bang now. It is already complicated enough.

I try to get used to the idea of doing code level cleanup later, even though my personal feeling for re-adding known-to-be-broken code is not exactly positive.

But at least at file level we should perform the needed cleanup now:
- omit unrelated stuff
- omit known to be unsupported/untested/broken code
- move drivers to the correct places according to today's file system hierarchy.

As I explained before, I doubt that you will be able to test things like drivers/video/mpc8xx_lcd.c on your boards, and I strongly doubt that you are willing to invest efforts in adapting and testing things like PCMCIA, bedbug, SIL680 support, or USB on your hardware.

Quoted 2 lines

Yes I agree, that's probably the first things I will remove (except USB probably).

I am here in line with Wolfgang. Why bringing in code, you do not know about, if you need it?

Make a list of features you need for your board and only add this code. Or do you not know what you need?

Quoted 2 lines

Quoted 2 lines

[In which way is the sil680 driver related to mpx8xx, btw?]

Quoted 7 lines

Quoted 4 lines

So when we know in advance that this old, crappy code will never be tested, why should we spend effforts even in adding it?

Just because it was there 2 weeks ago. I prefer starting from a known situation.

???

The current (also known) situation is that we have no 8xx code in mainline, and we are free to re-add the necessary things to their correct locations - and omit everything where we do not know for sure that it will really be needed in the future. If later we lear that something is still missing, this is more easy to add then, instead of cleaning up again and removing unneeded parts.

Quoted 14 lines

Quoted 7 lines

Quoted 6 lines

We have something that fits and that was unexpectedly removed entirely last week. Lets come back first to a well known - working situation and do the removal of unnecessary parts step by step as if we were 3 weeks ago. The more we wait to get 8xx back in, the more difficult it will be.

Quoted 6 lines

To be frank: you don't have a very extensive track record of working with the U-Boot community. At the moment all we have is your claim that you will care about 8xx in the furture. In the past, we have seen many precedents of "please add this code now, I know it is not really good, but I will fix it later, promised" - and then the code was in mainline, until somebody else digged into cleaning it up.

Quoted 6 lines

Well, I don't know what to answer to that, I understand your reluctance but you probably also
understand mine, I try crawling in one direction to get my boards in while others are removing more
and more stuff (51xx, 82xx, 5xx ...) which makes the come back of 8xx more difficult each day.

And your solution is reverting none 8xx patches? Come on! Why is this a problem for bringing 8xx back?

I do not understand you here ... you have the old core 8xx files, and you only
have to add them to the current base, and bring them up again to compile
...

yes it is work, here and there, because mpc82xx and mpc8xx code wasn't cleanly
separated, unexplainable undef of 8xx defines in 4xx related configs ...

Time to clean it up!

U-Boot code changes from day to day ... do you mean, we should stop adding patches until you have your patches in?

If you are working on this right now in a private repository branched from the current mainline tree, then it is really little effort to rebase your work tree every few hours against the then current mainline tree. The 8xx code is not used anywhere else, so you should see only a few merge conflicts in Makefiles or Kconfig files while you go, and all these would be trivial to fix.

Actually cleaning up before submitting should be less work for you than re-adding the old cod now and cleaning it up in mainline later. Not to mention that you can squash unneeded intermediate results in your tree before the submission, so the patch series would even be smaller and easier to review.

Quoted 10 lines

Quoted 9 lines

I've been using MPC8xx for 18 years, and I know all too well in how many places the code is in urgent need of a cleanup (heck, I'm even responsible for major parts of that mess - but those were the times way back then). I'm not sure if you already anticipate the size of job you have taken. Just looking at the POST code - are you aware how much effort it will be to adapt it to your board and to test it? And this is mandatory requirement if you want to have it added. It must be maintained, i. e. tested.

Quoted 4 lines

We have it running on our boards and it works, it is just not in a clean submittable (doesn't
respect the Codying Style, has several hard coded stuff in core parts, etc ...), so I cannot submit

Ah! Now we came closer to the root of your problem!

I exactly feared such a statement as "several hard coded stuff in core parts" !!

Which changes in core parts?
Why do you need them?

And you do not want to adapt them at the moment, correct?

Quoted 5 lines

it just now, and I fear that by end august/early septembre, when I come with my cleaned board code,
so much modification have been done to uboot core that 8xx cannot be back without tones of reverts.

No, if you bring in with your patchset also the core 8xx support, you have a clean base for your patchset! And as I mentioned, yes code is in flow, but you can use git for rebasing with current mainline and fix merge problems ...

Quoted 14 lines

Quoted 13 lines

It would be very sad if we add this code now, and in a few weeks/months you say: oh, we don't need this, and I don't find time to care about it, let's remove it again. And this is what's bound to happen - I bet a beer or two that you have never used most of this code before, nor had a look at the code.

I think it is much, much better to perform at least the file level cleanup in a sngle step right at the beginning, starting with the minimum set of needed files for your system. Adding needed things later is a much better guaranteee for good code than removing unmaintained crap when it starts hurting.

Quoted 2 lines

Ok but please stop removing or deapply modifying additional stuff that impacts the 8xx.

Heh ... 8xx is removed. What should impact now 8xx support?

I cannot follow here your argumentation!

Quoted 4 lines

Quoted 3 lines

So please check your own board configuration and come up with a list of needed features, and re-add only those, cleaning up file hierarchy while you go. See .sig below (non-random today).

Quoted 3 lines

Yes but that's not something that is doable in a few hours. So be compassionate and don't jeopardise
it.

Yes, exactly, not work for a few hours ... that has nothing to do with being compassionate or jeopardise! Please do the necessary changes, send a cleaner patchset and we are happy about having mpc8xx back in a maintained state!

bye,
Heiko

Quoted 12 lines

Thanks
Christophe

Quoted 7 lines

Thanks.

Best regards,

Wolfgang Denk

Ok, noted. Please take care to not remove anything that is common with 8xx before 8xx is back.

Yes I realised that after Tom suggested to perform a travis-CI build, I'm working on it, should probably get something early next week, maybe tonight

Quoted 2 lines

Make a list of features you need for your board and only add this code. Or do you not know what you need?

Of course I know what I need.

Quoted 1 line

Quoted 1 line

Quoted 1 line

[In which way is the sil680 driver related to mpx8xx, btw?]

If it is not related, then it will go when I do the clean up. Lets do the things in order and perform atomic commits.

Here I really feel like being an hostage. Just because I didn't noticed early enough that the 8xx code was about to go away, now I have to pay the ransom of doing a huge cleanup to get it back ? To be honnest I really find it unfair.

I have volonteered to maintain the 8xx and I plan to perform the cleanup that have been awaited. Why don't you welcome that and allow me to do as if we were 2 weeks ago and the code had not go away yet ?

But doing that way we loose the history, years of good work by respective people. We take the risk to forget things to add back.

I prefer forgetting to remove something than forgetting to re-add something. Doing as you suggest we loose any opportunity to bisect when something that was working in previous versions is not working anymore. etc ...

git is all about doing atomic commits, to allow detailed explanation, to allow bissects, to ease reviews, etc.

You were looking for someone to take care of the 8xx, I'm here now. I need 8xx to be maintained for at least the next ten years, so I will take charge and do what needs to be done, but if it was not with a Knife under the throat it would be more rewarding.

Quoted 2 lines

And your solution is reverting none 8xx patches? Come on! Why is this a problem for bringing 8xx back?

Conflicts require manual actions, which often leads to human errors. That's my haunt here.

Yes I handled it, I reverted everything then I re-did the removal of 82xx etc ...

Quoted 1 line

Time to clean it up!

Yes I'm here for that. Start from the existing and clean step by step, with atomic commits so that everyone can see what has been done, how and why.

No, I mean we should get 8xx core back and allow cleaning it up in an ordered manner that allows us to keep track of history. Yes U-boot code changes from day to day, and that is exactly what I'd like to be allowed to do with the 8xx, clean it up day by day and follow the evolution of U-boot.

Quoted 6 lines

If you are working on this right now in a private repository branched from the current mainline tree, then it is really little effort to rebase your work tree every few hours against the then current mainline tree. The 8xx code is not used anywhere else, so you should see only a few merge conflicts in Makefiles or Kconfig files while you go, and all these would be trivial to fix.

rebasing every few hours ? If I could use that time to do something more usefull, wouldn't it be better for everyone ?

If for instance we re-introduce in a different place and with a different name some files you have just removed, we definitly loose the automatic history of those files. If we get it back at its original place and move it after, the history is kept, 'git blame' will show it up.

Quoted 2 lines

Which changes in core parts?
Why do you need them?

We most likely don't need them, I have to (re)move them, however it will require some time.

No, that's not correct. I want to adapt it, but again, I don't think it is a good idea to do it in a few hours, in a hurry.

Dear Christophe,

Quoted 3 lines · In message <[email protected]> you wrote:

Ok, noted. Please take care to not remove anything that is common with 8xx before 8xx is back.

8xx is gone. Please get used to that fact.

Quoted 4 lines

Yes I realised that after Tom suggested to perform a travis-CI build, I'm working on it, should probably get something early next week, maybe tonight

Please don't hurry. You lose nothing by doing things right instead of in a rush. On contrary.

Quoted 5 lines

Quoted 3 lines

Make a list of features you need for your board and only add this code. Or do you not know what you need?

Of course I know what I need.

OK, so please let's discuss it here, so we can review your patches in comparison with your requirements.

Please provide a list of features / drivers needed by your boards, and please also provide some information about the schedule you envision for the cleanup to take place.

Please understand that we are concerned about re-adding old, crappy and in a number of places known to be broken code again. We had a large number of such situations in the past, and with _very_ few exceptions in almost all cases he promised cleanup just never took place.

And if you look at your own arguments, you are actually feeding such concerns.

Quoted 4 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

[In which way is the sil680 driver related to mpx8xx, btw?]

If it is not related, then it will go when I do the clean up. Lets do the things in order and perform atomic commits.

No, this makes no sense to me. This is exactly where you will continue to see my NAKs: the code has already been removed, so please do not re-add it now if you already anticipate that you will remove it later.

Remember Shakespeare's Law of Prototyping: (Hamlet III, iv, 156-160)

O, throw away the worser part of it,
And live the purer with the other half.

:-)

Quoted 4 lines

Here I really feel like being an hostage. Just because I didn't noticed early enough that the 8xx code was about to go away, now I have to pay the ransom of doing a huge cleanup to get it back ? To be honnest I really find it unfair.

Please don't take this discussion on a personal level. Please understand that I (and certainly also Heiko) would be more than happy to see 8xx survive in a clean and well maintained state. But this discussion is not about being fair or not, it is about good code or bad one. Let's face it: apparently you never before cared much what is going on in U-Boot mainline, and now you attempt to jump into the job of a custodian. This job carries both great responsibility and requires a lot of dedication and enthusiasm. Normally we require people to have a proven track record for working with the community before they are even considered for this job.

And frankly: nobody asked you to take this job. If you step back, then 8xx is just gone, and that's it. Nobody else here sheds a tear, not even me, the author of large parts of this code.

Quoted 3 lines

I have volonteered to maintain the 8xx and I plan to perform the cleanup that have been awaited. Why don't you welcome that and allow me to do as if we were 2 weeks ago and the code had not go away yet ?

We welcome you, and we actually try to help you. You lack experience with working in mainline, and with working with the community. We've been here before and know pretty well what works and what is bound to cause trouble later. Being new in this job, you should listen to such advice and not fight it.

Quoted 4 lines

But doing that way we loose the history, years of good work by respective people. We take the risk to forget things to add back.

We don't lose any history. It's all still available in git. If you forget to add anything, then only because you don't need it - and did we not agree to add only the stuff that is really needed and omit all the ugly warts?

Remember Shakespeare's Law of Prototyping: (Hamlet III, iv, 156-160)

O, throw away the worser part of it,
And live the purer with the other half.

:-)

Quoted 4 lines

I prefer forgetting to remove something than forgetting to re-add something. Doing as you suggest we loose any opportunity to bisect when something that was working in previous versions is not working anymore. etc ...

As Heiko suggested, you can do all this in a local, private repository. When you have reached a clean, working state, then submit your clean and working patches to mainline. More is not needed.

Quoted 2 lines

git is all about doing atomic commits, to allow detailed explanation, to allow bissects, to ease reviews, etc.

Yes. But the existing code will not allow this. You will end up with a large collection of mess which you don't dare to remove because you don't understand what it might be needed for. You said this yourself several times before - see the discussion about this #undef thing.

But we don't want all this crap back. The code that goes back in must be maintained by you, which includes it must be tested. Which means you must use it on a regular base in production, or you will not be granted the needed resources for such unused and unneeded tests.

Quoted 4 lines

You were looking for someone to take care of the 8xx, I'm here now. I need 8xx to be maintained for at least the next ten years, so I will take charge and do what needs to be done, but if it was not with a Knife under the throat it would be more rewarding.

You completely misunderstand the job you are applying for. This is not about being rewarding in any way. Working as a custodian is a pastime similar to banging one's head against a wall, but with fewer opportunities for reward.

This is work, lots of boring and frustrating work. This is no fun job at all.

Nobody cared for the 8xx code for the past 8...10 years because there were no active users left. There is a lot of work to do.

Quoted 5 lines

Quoted 2 lines

And your solution is reverting none 8xx patches? Come on! Why is this a problem for bringing 8xx back?

Conflicts require manual actions, which often leads to human errors. That's my haunt here.

It is much more likely that you will oversee tons of dead, unused and broken code once you got a configuration for your board up and running. This might better meet your own interests, but it does not meet the interests of the community.

Quoted 2 lines

Yes I handled it, I reverted everything then I re-did the removal of 82xx etc ...

Sorry, but please accept that this approach will not be accepted.

Quoted 5 lines

Quoted 1 line

Time to clean it up!

Yes I'm here for that. Start from the existing and clean step by step, with atomic commits so that everyone can see what has been done, how and why.

The current status quo is that 8xx is gone.

Quoted 5 lines

No, I mean we should get 8xx core back and allow cleaning it up in an ordered manner that allows us to keep track of history. Yes U-boot code changes from day to day, and that is exactly what I'd like to be allowed to do with the 8xx, clean it up day by day and follow the evolution of U-boot.

You did not care about this for the past decades, and the risk is that you will just do the minimum amount of work to satisfy your own needs.

The only way to prevent that tons of crap get added and never cleaned up or removed is to accept only such code which you require yourself.

This is the same like building a minimal root file system. You can take a standard distribution and remove everything not needed, or you can take an empty system and add only what you need. The results are TOTALLY different.

We ask you to go the additive route, because otherwise we will have tons of mess in mainline, no matter how hard or how long you work.

Quoted 9 lines

Quoted 6 lines

If you are working on this right now in a private repository branched from the current mainline tree, then it is really little effort to rebase your work tree every few hours against the then current mainline tree. The 8xx code is not used anywhere else, so you should see only a few merge conflicts in Makefiles or Kconfig files while you go, and all these would be trivial to fix.

rebasing every few hours ? If I could use that time to do something more usefull, wouldn't it be better for everyone ?

This statement scares me pretty much. It sounds as if you also don't have much experience of working with git. Rebasing a work-in-progress tree against mainline is usually (*) a trivial process which just takes seconds, and you _should_ do it anyway, because the longer you wait, the more work will accumulate and the more complex the merge conflicts will become.

* Exceptions are when your changes touch a lot of code all over the place, in many different subsystems, like generic Kconfig rework, global renames / cleanup or such. but this is not the case here. Your 8xx is nearly fully orthogonal to other work, so in most cases you will see zero merge conflicts.

Quoted 4 lines

If for instance we re-introduce in a different place and with a different name some files you have just removed, we definitly loose the automatic history of those files. If we get it back at its original place and move it after, the history is kept, 'git blame' will show it up.

You are right. But we pay for this advantage the price of uncleanable and basically unmaintainable code - all the more so as the boards that once used it are gone. From the mainline point of view this disadvantage is much more important.

For yourself of course it makes a lot of sense to proceed this way. As maintainer of the code you want to have all this, and you are free to do it. As custodian, you can even do this in public in a branch of the mpc8xx repository (git://git.denx.de/u-boot-mpc8xx.git).

So no information will be lost - not for you, and not for the community.

But we do not want to do this mainline.

Please go on and wade through all the garbage and clean it up, and when the stuff is shiny and working, submit your patches to mainline. Start small, with a minimal system, so reviewing is easy, and it will go in easily.

Quoted 5 lines

Quoted 2 lines

Which changes in core parts?
Why do you need them?

We most likely don't need them, I have to (re)move them, however it will require some time.

Sorry, I don't want to have that.

Quoted 2 lines

No, that's not correct. I want to adapt it, but again, I don't think it is a good idea to do it in a few hours, in a hurry.

But that's exactly what you are pushing us for: we shall accept the old crap in a hurry. No, take all the time you need and clean it up first, please! It is not us who is pushing you.

I really suggest that for a start you post your list of requirements and schedule, so we have a base for understanding why you re-add certain things.

Thanks.

Wolfgang Denk

The schedule: No discontinuity is U-boot support for 8xx. In Septembre, we will start preparing the yearly SW update.

On Thu, Jun 29, 2017 at 06:51:14PM +0200, Christophe LEROY wrote:
[snip]

Quoted 2 lines

The schedule: No discontinuity is U-boot support for 8xx. In Septembre, we will start preparing the yearly SW update.

Please note that while I see that "yearly update" is part of the certification process, you're going to be keeping up with U-Boot more frequently than that, right?

Dear Wolfgang,

Quoted 8 lines · Wolfgang Denk

Dear Christophe,

Quoted 3 lines · In message <[email protected]> you wrote:

Ok, noted. Please take care to not remove anything that is common with 8xx before 8xx is back.

8xx is gone. Please get used to that fact.

Yes he is gone by accident, lets get it back as some orphan boards need it.

Quoted 7 lines

Quoted 4 lines

Yes I realised that after Tom suggested to perform a travis-CI build, I'm working on it, should probably get something early next week, maybe tonight

Please don't hurry. You lose nothing by doing things right instead of in a rush. On contrary.

I agree, but see below

Quoted 8 lines

Quoted 5 lines

Quoted 3 lines

Make a list of features you need for your board and only add this code. Or do you not know what you need?

Of course I know what I need.

OK, so please let's discuss it here, so we can review your patches in comparison with your requirements.

The requirements are:
1/ The boards are used in Air Trafic Control critical system. Therefore, EUROCAE ED153 and ESSAR6 standards apply.
(for those not familiar with SW in ATC, see
http://opentechday.nl/wp-content/uploads/2017/05/20170420-OpenTechDay-Using-Linux-in-Air-Traffic-Control-002.pdf).

Using OpenSource SW in ATC is challenging. In order to reach the required SW assurance level, we have two main possibilities
a/ Ensure that the SW is developped following the V cycle with all the associated documentation. b/ Ensure that a previous version of the SW has a good 'in-service experience' and the new version only introduces a reduced amount of modifications in source code.
2/ The SW has to be kept up to date (once a year) until at least 2027

Req 1/a/ not being an option here, 1/b/ is the only way.
For that, we need to be able to demonstrate that the 8xx support has been in the SW for several years WITHOUT any interruption. It means that the 8xx must be back as soon as possible (ideally before version 2017.07 gets out) and with as little differences as possible and with traceability of the differences. Therefore, we can't re-introduce something that is different from what has been in for years, without the commits showing the incremental changes. If not, the certification is garantied to fail.

Quoted 5 lines

Please provide a list of features / drivers needed by your boards, and please also provide some information about the schedule you envision for the cleanup to take place.

The schedule: No discontinuity is U-boot support for 8xx. In Septembre, we will start preparing the yearly SW update.

Quoted 1 line

Quoted 5 lines

Please understand that we are concerned about re-adding old, crappy and in a number of places known to be broken code again. We had a large number of such situations in the past, and with _very_ few exceptions in almost all cases he promised cleanup just never took place.

I have kept only the needed stuff in my soon-to come v5 version of the patch.

Quoted 45 lines

And if you look at your own arguments, you are actually feeding such concerns.

Quoted 4 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

[In which way is the sil680 driver related to mpx8xx, btw?]

If it is not related, then it will go when I do the clean up. Lets do the things in order and perform atomic commits.

No, this makes no sense to me. This is exactly where you will continue to see my NAKs: the code has already been removed, so please do not re-add it now if you already anticipate that you will remove it later.

Remember Shakespeare's Law of Prototyping: (Hamlet III, iv, 156-160)

O, throw away the worser part of it,
And live the purer with the other half.

:-)

Quoted 4 lines

Here I really feel like being an hostage. Just because I didn't noticed early enough that the 8xx code was about to go away, now I have to pay the ransom of doing a huge cleanup to get it back ? To be honnest I really find it unfair.

Please don't take this discussion on a personal level. Please understand that I (and certainly also Heiko) would be more than happy to see 8xx survive in a clean and well maintained state. But this discussion is not about being fair or not, it is about good code or bad one. Let's face it: apparently you never before cared much what is going on in U-Boot mainline, and now you attempt to jump into the job of a custodian. This job carries both great responsibility and requires a lot of dedication and enthusiasm. Normally we require people to have a proven track record for working with the community before they are even considered for this job.

And frankly: nobody asked you to take this job. If you step back, then 8xx is just gone, and that's it. Nobody else here sheds a tear, not even me, the author of large parts of this code.

Quoted 3 lines

I have volonteered to maintain the 8xx and I plan to perform the cleanup that have been awaited. Why don't you welcome that and allow me to do as if we were 2 weeks ago and the code had not go away yet ?

Quoted 5 lines

We welcome you, and we actually try to help you. You lack experience with working in mainline, and with working with the community. We've been here before and know pretty well what works and what is bound to cause trouble later. Being new in this job, you should listen to such advice and not fight it.

Your advices are welcome. Now you know my requirements, so your help is of course more than welcome.

Christophe

Quoted 178 lines

Quoted 4 lines

But doing that way we loose the history, years of good work by respective people. We take the risk to forget things to add back.

We don't lose any history. It's all still available in git. If you forget to add anything, then only because you don't need it - and did we not agree to add only the stuff that is really needed and omit all the ugly warts?

Remember Shakespeare's Law of Prototyping: (Hamlet III, iv, 156-160)

O, throw away the worser part of it,
And live the purer with the other half.

:-)

Quoted 4 lines

I prefer forgetting to remove something than forgetting to re-add something. Doing as you suggest we loose any opportunity to bisect when something that was working in previous versions is not working anymore. etc ...

As Heiko suggested, you can do all this in a local, private repository. When you have reached a clean, working state, then submit your clean and working patches to mainline. More is not needed.

Quoted 2 lines

git is all about doing atomic commits, to allow detailed explanation, to allow bissects, to ease reviews, etc.

Yes. But the existing code will not allow this. You will end up with a large collection of mess which you don't dare to remove because you don't understand what it might be needed for. You said this yourself several times before - see the discussion about this #undef thing.

But we don't want all this crap back. The code that goes back in must be maintained by you, which includes it must be tested. Which means you must use it on a regular base in production, or you will not be granted the needed resources for such unused and unneeded tests.

Quoted 4 lines

You were looking for someone to take care of the 8xx, I'm here now. I need 8xx to be maintained for at least the next ten years, so I will take charge and do what needs to be done, but if it was not with a Knife under the throat it would be more rewarding.

You completely misunderstand the job you are applying for. This is not about being rewarding in any way. Working as a custodian is a pastime similar to banging one's head against a wall, but with fewer opportunities for reward.

This is work, lots of boring and frustrating work. This is no fun job at all.

Nobody cared for the 8xx code for the past 8...10 years because there were no active users left. There is a lot of work to do.

Quoted 5 lines

Quoted 2 lines

And your solution is reverting none 8xx patches? Come on! Why is this a problem for bringing 8xx back?

Conflicts require manual actions, which often leads to human errors. That's my haunt here.

It is much more likely that you will oversee tons of dead, unused and broken code once you got a configuration for your board up and running. This might better meet your own interests, but it does not meet the interests of the community.

Quoted 2 lines

Yes I handled it, I reverted everything then I re-did the removal of 82xx etc ...

Sorry, but please accept that this approach will not be accepted.

Quoted 5 lines

Quoted 1 line

Time to clean it up!

Yes I'm here for that. Start from the existing and clean step by step, with atomic commits so that everyone can see what has been done, how and why.

The current status quo is that 8xx is gone.

Quoted 5 lines

No, I mean we should get 8xx core back and allow cleaning it up in an ordered manner that allows us to keep track of history. Yes U-boot code changes from day to day, and that is exactly what I'd like to be allowed to do with the 8xx, clean it up day by day and follow the evolution of U-boot.

You did not care about this for the past decades, and the risk is that you will just do the minimum amount of work to satisfy your own needs.

The only way to prevent that tons of crap get added and never cleaned up or removed is to accept only such code which you require yourself.

This is the same like building a minimal root file system. You can take a standard distribution and remove everything not needed, or you can take an empty system and add only what you need. The results are TOTALLY different.

We ask you to go the additive route, because otherwise we will have tons of mess in mainline, no matter how hard or how long you work.

Quoted 9 lines

Quoted 6 lines

If you are working on this right now in a private repository branched from the current mainline tree, then it is really little effort to rebase your work tree every few hours against the then current mainline tree. The 8xx code is not used anywhere else, so you should see only a few merge conflicts in Makefiles or Kconfig files while you go, and all these would be trivial to fix.

rebasing every few hours ? If I could use that time to do something more usefull, wouldn't it be better for everyone ?

This statement scares me pretty much. It sounds as if you also don't have much experience of working with git. Rebasing a work-in-progress tree against mainline is usually (*) a trivial process which just takes seconds, and you _should_ do it anyway, because the longer you wait, the more work will accumulate and the more complex the merge conflicts will become.

* Exceptions are when your changes touch a lot of code all over the place, in many different subsystems, like generic Kconfig rework, global renames / cleanup or such. but this is not the case here. Your 8xx is nearly fully orthogonal to other work, so in most cases you will see zero merge conflicts.

Quoted 4 lines

If for instance we re-introduce in a different place and with a different name some files you have just removed, we definitly loose the automatic history of those files. If we get it back at its original place and move it after, the history is kept, 'git blame' will show it up.

You are right. But we pay for this advantage the price of uncleanable and basically unmaintainable code - all the more so as the boards that once used it are gone. From the mainline point of view this disadvantage is much more important.

For yourself of course it makes a lot of sense to proceed this way. As maintainer of the code you want to have all this, and you are free to do it. As custodian, you can even do this in public in a branch of the mpc8xx repository (git://git.denx.de/u-boot-mpc8xx.git).

So no information will be lost - not for you, and not for the community.

But we do not want to do this mainline.

Please go on and wade through all the garbage and clean it up, and when the stuff is shiny and working, submit your patches to mainline. Start small, with a minimal system, so reviewing is easy, and it will go in easily.

Quoted 5 lines

Quoted 2 lines

Which changes in core parts?
Why do you need them?

We most likely don't need them, I have to (re)move them, however it will require some time.

Sorry, I don't want to have that.

Quoted 2 lines

No, that's not correct. I want to adapt it, but again, I don't think it is a good idea to do it in a few hours, in a hurry.

But that's exactly what you are pushing us for: we shall accept the old crap in a hurry. No, take all the time you need and clean it up first, please! It is not us who is pushing you.

I really suggest that for a start you post your list of requirements and schedule, so we have a base for understanding why you re-add certain things.

Thanks.

Wolfgang Denk

Hello Christophe,

Am 29.06.2017 um 18:51 schrieb Christophe LEROY:

Quoted 52 lines

Dear Wolfgang,

Quoted 8 lines · Wolfgang Denk

Dear Christophe,

Quoted 3 lines · In message <[email protected]> you wrote:

Ok, noted. Please take care to not remove anything that is common with 8xx before 8xx is back.

8xx is gone. Please get used to that fact.

Yes he is gone by accident, lets get it back as some orphan boards need it.

Quoted 7 lines

Quoted 4 lines

Yes I realised that after Tom suggested to perform a travis-CI build, I'm working on it, should probably get something early next week, maybe tonight

Please don't hurry. You lose nothing by doing things right instead of in a rush. On contrary.

I agree, but see below

Quoted 8 lines

Quoted 5 lines

Quoted 3 lines

Make a list of features you need for your board and only add this code. Or do you not know what you need?

Of course I know what I need.

OK, so please let's discuss it here, so we can review your patches in comparison with your requirements.

The requirements are:
1/ The boards are used in Air Trafic Control critical system. Therefore, EUROCAE ED153 and ESSAR6
standards apply.
(for those not familiar with SW in ATC, see
http://opentechday.nl/wp-content/uploads/2017/05/20170420-OpenTechDay-Using-Linux-in-Air-Traffic-Control-002.pdf).

Using OpenSource SW in ATC is challenging. In order to reach the required SW assurance level, we
have two main possibilities
a/ Ensure that the SW is developped following the V cycle with all the associated documentation.
b/ Ensure that a previous version of the SW has a good 'in-service experience' and the new version
only introduces a reduced amount of modifications in source code. 2/ The SW has to be kept up to date (once a year) until at least 2027

Quoted 12 lines

Req 1/a/ not being an option here, 1/b/ is the only way. For that, we need to be able to demonstrate that the 8xx support has been in the SW for several
years WITHOUT any interruption. It means that the 8xx must be back as soon as possible (ideally
before version 2017.07 gets out) and with as little differences as possible and with traceability of
the differences. Therefore, we can't re-introduce something that is different from what has been in
for years, without the commits showing the incremental changes. If not, the certification is
garantied to fail.

So I do not understand why you didn't mainlined your boards, if you have such constraints! Sorry, we didn't know that your hw exists, until my remove patches...

Quoted 17 lines

Quoted 6 lines

Please provide a list of features / drivers needed by your boards, and please also provide some information about the schedule you envision for the cleanup to take place.

The schedule: No discontinuity is U-boot support for 8xx. In Septembre, we will start preparing the yearly SW update.

Quoted 6 lines

Please understand that we are concerned about re-adding old, crappy and in a number of places known to be broken code again. We had a large number of such situations in the past, and with _very_ few exceptions in almost all cases he promised cleanup just never took place.

Quoted 2 lines

I have kept only the needed stuff in my soon-to come v5 version of the patch.

Great. Thanks!

bye,
Heiko

Quoted 245 lines

Quoted 47 lines

And if you look at your own arguments, you are actually feeding such concerns.

Quoted 4 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

[In which way is the sil680 driver related to mpx8xx, btw?]

If it is not related, then it will go when I do the clean up. Lets do the things in order and perform atomic commits.

No, this makes no sense to me. This is exactly where you will continue to see my NAKs: the code has already been removed, so please do not re-add it now if you already anticipate that you will remove it later.

Remember Shakespeare's Law of Prototyping: (Hamlet III, iv, 156-160)

O, throw away the worser part of it,
And live the purer with the other half.

:-)

Quoted 4 lines

Here I really feel like being an hostage. Just because I didn't noticed early enough that the 8xx code was about to go away, now I have to pay the ransom of doing a huge cleanup to get it back ? To be honnest I really find it unfair.

Please don't take this discussion on a personal level. Please understand that I (and certainly also Heiko) would be more than happy to see 8xx survive in a clean and well maintained state. But this discussion is not about being fair or not, it is about good code or bad one. Let's face it: apparently you never before cared much what is going on in U-Boot mainline, and now you attempt to jump into the job of a custodian. This job carries both great responsibility and requires a lot of dedication and enthusiasm. Normally we require people to have a proven track record for working with the community before they are even considered for this job.

And frankly: nobody asked you to take this job. If you step back, then 8xx is just gone, and that's it. Nobody else here sheds a tear, not even me, the author of large parts of this code.

Quoted 5 lines

I have volonteered to maintain the 8xx and I plan to perform the cleanup
that have been awaited. Why don't you welcome that and allow me to do as
if we were 2 weeks ago and the code had not go away yet ?

Quoted 5 lines

We welcome you, and we actually try to help you. You lack experience with working in mainline, and with working with the community. We've been here before and know pretty well what works and what is bound to cause trouble later. Being new in this job, you should listen to such advice and not fight it.

Your advices are welcome. Now you know my requirements, so your help is of course more than welcome.

Christophe

Quoted 186 lines

Quoted 4 lines

But doing that way we loose the history, years of good work by respective people. We take the risk to forget things to add back.

We don't lose any history. It's all still available in git. If you forget to add anything, then only because you don't need it - and did we not agree to add only the stuff that is really needed and omit all the ugly warts?

Remember Shakespeare's Law of Prototyping: (Hamlet III, iv, 156-160)

O, throw away the worser part of it,
And live the purer with the other half.

:-)

Quoted 4 lines

I prefer forgetting to remove something than forgetting to re-add something. Doing as you suggest we loose any opportunity to bisect when something that was working in previous versions is not working anymore. etc ...

As Heiko suggested, you can do all this in a local, private repository. When you have reached a clean, working state, then submit your clean and working patches to mainline. More is not needed.

Quoted 3 lines

git is all about doing atomic commits, to allow detailed explanation, to
allow bissects, to ease reviews, etc.

Yes. But the existing code will not allow this. You will end up with a large collection of mess which you don't dare to remove because you don't understand what it might be needed for. You said this yourself several times before - see the discussion about this #undef thing.

But we don't want all this crap back. The code that goes back in must be maintained by you, which includes it must be tested. Which means you must use it on a regular base in production, or you will not be granted the needed resources for such unused and unneeded tests.

Quoted 5 lines

You were looking for someone to take care of the 8xx, I'm here now. I need 8xx to be maintained for at least the next ten years, so I will take charge and do what needs to be done, but if it was not with a Knife
under the throat it would be more rewarding.

You completely misunderstand the job you are applying for. This is not about being rewarding in any way. Working as a custodian is a pastime similar to banging one's head against a wall, but with fewer opportunities for reward.

This is work, lots of boring and frustrating work. This is no fun job at all.

Nobody cared for the 8xx code for the past 8...10 years because there were no active users left. There is a lot of work to do.

Quoted 6 lines

Quoted 3 lines

And your solution is reverting none 8xx patches? Come on! Why is this a
problem for bringing 8xx back?

Conflicts require manual actions, which often leads to human errors. That's my haunt here.

It is much more likely that you will oversee tons of dead, unused and broken code once you got a configuration for your board up and running. This might better meet your own interests, but it does not meet the interests of the community.

Quoted 2 lines

Yes I handled it, I reverted everything then I re-did the removal of 82xx etc ...

Sorry, but please accept that this approach will not be accepted.

Quoted 6 lines

Quoted 1 line

Time to clean it up!

Yes I'm here for that. Start from the existing and clean step by step, with atomic commits so that everyone can see what has been done, how and
why.

The current status quo is that 8xx is gone.

Quoted 6 lines

No, I mean we should get 8xx core back and allow cleaning it up in an ordered manner that allows us to keep track of history. Yes U-boot code changes from day to day, and that is exactly what I'd like to be allowed
to do with the 8xx, clean it up day by day and follow the evolution of U-boot.

You did not care about this for the past decades, and the risk is that you will just do the minimum amount of work to satisfy your own needs.

The only way to prevent that tons of crap get added and never cleaned up or removed is to accept only such code which you require yourself.

This is the same like building a minimal root file system. You can take a standard distribution and remove everything not needed, or you can take an empty system and add only what you need. The results are TOTALLY different.

We ask you to go the additive route, because otherwise we will have tons of mess in mainline, no matter how hard or how long you work.

Quoted 10 lines

Quoted 6 lines

If you are working on this right now in a private repository branched from the current mainline tree, then it is really little effort to rebase your work tree every few hours against the then current mainline tree. The 8xx code is not used anywhere else, so you should see only a few merge conflicts in Makefiles or Kconfig files while you go, and all these would be trivial to fix.

rebasing every few hours ? If I could use that time to do something more
usefull, wouldn't it be better for everyone ?

This statement scares me pretty much. It sounds as if you also don't have much experience of working with git. Rebasing a work-in-progress tree against mainline is usually (*) a trivial process which just takes seconds, and you _should_ do it anyway, because the longer you wait, the more work will accumulate and the more complex the merge conflicts will become.

* Exceptions are when your changes touch a lot of code all over the place, in many different subsystems, like generic Kconfig rework, global renames / cleanup or such. but this is not the case here. Your 8xx is nearly fully orthogonal to other work, so in most cases you will see zero merge conflicts.

Quoted 5 lines

If for instance we re-introduce in a different place and with a different name some files you have just removed, we definitly loose the automatic history of those files. If we get it back at its original place and move it after, the history is kept, 'git blame' will show it up.

You are right. But we pay for this advantage the price of uncleanable and basically unmaintainable code - all the more so as the boards that once used it are gone. From the mainline point of view this disadvantage is much more important.

For yourself of course it makes a lot of sense to proceed this way. As maintainer of the code you want to have all this, and you are free to do it. As custodian, you can even do this in public in a branch of the mpc8xx repository (git://git.denx.de/u-boot-mpc8xx.git).

So no information will be lost - not for you, and not for the community.

But we do not want to do this mainline.

Please go on and wade through all the garbage and clean it up, and when the stuff is shiny and working, submit your patches to mainline. Start small, with a minimal system, so reviewing is easy, and it will go in easily.

Quoted 6 lines

Quoted 2 lines

Which changes in core parts?
Why do you need them?

We most likely don't need them, I have to (re)move them, however it will
require some time.

Sorry, I don't want to have that.

Quoted 2 lines

No, that's not correct. I want to adapt it, but again, I don't think it is a good idea to do it in a few hours, in a hurry.

But that's exactly what you are pushing us for: we shall accept the old crap in a hurry. No, take all the time you need and clean it up first, please! It is not us who is pushing you.

I really suggest that for a start you post your list of requirements and schedule, so we have a base for understanding why you re-add certain things.

Thanks.

Wolfgang Denk

Quoted 2 lines

8xx is gone. Please get used to that fact.

Yes he is gone by accident, lets get it back as some orphan boards need it.

Quoted 2 lines

OK, so please let's discuss it here, so we can review your patches in comparison with your requirements.

The requirements are:

For that, we need to be able to demonstrate that the 8xx support has been in the SW for several years WITHOUT any interruption. It means that the 8xx must be back as soon as possible (ideally before version 2017.07

Quoted 3 lines

Please provide a list of features / drivers needed by your boards, and please also provide some information about the schedule you envision for the cleanup to take place.

The schedule: No discontinuity is U-boot support for 8xx.

In Septembre, we will start preparing the yearly SW update.

I have kept only the needed stuff in my soon-to come v5 version of the patch.

Your advices are welcome. Now you know my requirements, so your help is of course more than welcome.