1.4 development planning thread - page 11 - General Discussion and Assistance - CHDK Forum

1.4 development planning thread

  • 195 Replies
  • 70217 Views
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: 1.4 development planning thread
« Reply #100 on: 04 / March / 2015, 19:51:57 »
Advertisements
I would not worry about auto_build_parallel.sh - I should probably remove this.
It is Windows only, and no longer works on 8.0 or 8.1 - seems Windows now refuses to run hundreds of command prompts simultaneously.

The MODULES stuff is tricky - I need to think about it some more.

Phil.
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

*

Offline reyalp

  • ******
  • 14082
Re: 1.4 development planning thread
« Reply #101 on: 04 / March / 2015, 22:15:06 »
One option for MODULES might be to leave CHDK/MODULES empty, and add the appropriate modules to the zip in a separate invocation. I'm not sure offhand if you can specify the destination directory in the zip without having the files in that structure, but at worst, you could make a tree like

bin/thumb2/CHDK/MODULES
bin/thumb/CHDK/MODULES

and then cd to the appropriate one and add CHDK/MODULES

I think we should avoid having both thumb2 and thumb modules in different directories or with different extensions in all the final zips. It's only a few hundred kb, but it adds up if you are building all the cameras. It might still be a good idea to have them named differently to minimize the chance of mixing them up if you move cards between cameras.

Quote
Finally, a different kind of problem: existing arm-elf toolchains (such as those on the autobuild server(s)) won't be able to build thumb-2 source successfully. How should this be dealt with?
The autobuild compilers will need to be updated before the thumb2 cameras are added to the autobuild. That doesn't have to happen before the source is merged though, they just have to stay disabled until it's ready.

FWIW, I still haven't resolved the issue with the GCC 4.8 build crashing A540 if zebra or histo are enabled. (mentioned here http://chdk.setepontos.com/index.php?topic=12232.msg120519#msg120519)
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 4451
Re: 1.4 development planning thread
« Reply #102 on: 05 / March / 2015, 11:40:30 »
I think we should avoid having both thumb2 and thumb modules (...) with different extensions in all the final zips. It's only a few hundred kb, but it adds up if you are building all the cameras.
zip's -i or -x options could be used to include only the right type of modules.
Quote
It might still be a good idea to have them named differently to minimize the chance of mixing them up if you move cards between cameras.
I agree. Any suggestion for the new extension? I can't come up with anything good if we'll continue using .flt for regular thumb modules.
Quote
FWIW, I still haven't resolved the issue with the GCC 4.8 build crashing A540 if zebra or histo are enabled. (mentioned here http://chdk.setepontos.com/index.php?topic=12232.msg120519#msg120519)
I think this is the only camera port with 352/704 framebuffer widths. Could be related? How hard is to reproduce this issue?

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: 1.4 development planning thread
« Reply #103 on: 05 / March / 2015, 15:52:54 »
Another idea for the MODULES problem.

In the current trunk all the module .flt files are built in the modules/.o directory for current cameras.
In your Digic6 version the .flt files are built in the modules/.o2 directory.

So we already have the ability for two different versions being built in different locations.
What the current batch build rules don't do is actually build the two different versions of the module files. This should be reasonably easy to fix.

If we change the rules that build the .zip files to always copy the modules from modules/$O to CHDK/MODULES when building the zip files then every build should get the right modules without changing any names. This might just require moving some lines from the CHDK/Makefile rules to the top level Makefile.

The module loader code already checks the architecture setting on the module file, so if try and use an SD card in a different camera without updating the module files it will give an error.

Phil.
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)


*

Offline srsa_4c

  • ******
  • 4451
Re: 1.4 development planning thread
« Reply #104 on: 05 / March / 2015, 19:39:30 »
Another idea for the MODULES problem.

In the current trunk all the module .flt files are built in the modules/.o directory for current cameras.
In your Digic6 version the .flt files are built in the modules/.o2 directory.

So we already have the ability for two different versions being built in different locations.
What the current batch build rules don't do is actually build the two different versions of the module files. This should be reasonably easy to fix.
I have created duplicate targets (-arm and -t2) for this purpose in my previous approach, I did not include them in this one yet.
Quote
If we change the rules that build the .zip files to always copy the modules from modules/$O to CHDK/MODULES when building the zip files then every build should get the right modules without changing any names.
That's essentially my 3rd proposal from here. I'll try doing that then.

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: 1.4 development planning thread
« Reply #105 on: 05 / March / 2015, 19:55:12 »
Another idea for the MODULES problem.

In the current trunk all the module .flt files are built in the modules/.o directory for current cameras.
In your Digic6 version the .flt files are built in the modules/.o2 directory.

So we already have the ability for two different versions being built in different locations.
What the current batch build rules don't do is actually build the two different versions of the module files. This should be reasonably easy to fix.
I have created duplicate targets (-arm and -t2) for this purpose in my previous approach, I did not include them in this one yet.

I think it might just need a line with '$(MAKE) -C modules THUMB_FW=1 clean all' added to the allmodules target in the root Makefile.

I can't test this at the moment - my main machine is restoring after a hardware failure.

Phil.
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

*

Offline srsa_4c

  • ******
  • 4451
Re: 1.4 development planning thread
« Reply #106 on: 06 / March / 2015, 12:51:58 »
I think it might just need a line with '$(MAKE) -C modules THUMB_FW=1 clean all' added to the allmodules target in the root Makefile.
Yes, that works. Added this and your previous suggested changes, also added the remaining changes from the make_target_v2 diff. I have added support for an optional fixed version of the bin_compat header (needed by thumb-2 ports). New diff is up under the same link.
Batch builds now seem to work. However, there's plenty more to optimize. I'm thinking about effectively restoring the previous COPY_TO method by re-using existing compatible zips (except for cases where P-IDs are different). Reducing redundant cleans in batch-clean is also planned.
Keeping the ability to build the ports in parallel would also be desirable, perhaps reyalp's suggestion (separate temporary dirs for modules) could be added too.

*

Offline srsa_4c

  • ******
  • 4451
Re: 1.4 development planning thread
« Reply #107 on: 08 / March / 2015, 13:37:46 »
I'm thinking about effectively restoring the previous COPY_TO method by re-using existing compatible zips (except for cases where P-IDs are different).
I have added these optimizations and made batch compilation possible with old arm-elf toolchains. I have set up a temporary repo here.


*

Offline srsa_4c

  • ******
  • 4451
Re: 1.4 development planning thread
« Reply #108 on: 09 / March / 2015, 20:00:01 »
I found something that looks like a very old "bug" in the main makefile. The firzipsub and firzipsubcomplete build actions produce archives with different names. Archives created by firzipsub have a prefix in their names according to the selected CHDK 'version' (CHDK or CHDK-DE). This is missing from the archives made by firzipsubcomplete. As a result, files from the autobuild do not have 'CHDK' in their name (the CHDK-DE autobuild seems to work this issue around, those archives start with 'CHDK-DE').
Since this looks like it has been broken since the beginning, should we "fix" this? If we do, I expect that we could easily break the autobuilds and zeno's tools.

*

Offline reyalp

  • ******
  • 14082
Re: 1.4 development planning thread
« Reply #109 on: 10 / March / 2015, 02:03:20 »
Since this looks like it has been broken since the beginning, should we "fix" this? If we do, I expect that we could easily break the autobuilds and zeno's tools.
I'd be inclined to leave it as is, at least until we have other reasons to muck with the autobuild.
Don't forget what the H stands for.

 

Related Topics