1.4 development planning thread - page 15 - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: 1 ... 10 11 12 13 14 [15] 16 17 18 19 20   Go Down

1.4 development planning thread

  • 195 Replies
  • 79270 Views
*

Offline msl

  • *****
  • 1280
  • A720 IS, SX220 HS 1.01a
    • CHDK-DE links
Re: 1.4 development planning thread
« Reply #140 on: 05 / September / 2015, 17:17:51 »
Advertisements
Quote from: reyalp on 05 / September / 2015, 02:05:10
I checked the patch from #131 in as is.
Just as a note: autobuild CHDK-DE works fine.

msl
Logged
CHDK-DE:  CHDK-DE links
*

Offline srsa_4c

  • ******
  • 4451
Re: 1.4 development planning thread
« Reply #141 on: 05 / September / 2015, 18:58:10 »
The new style build process makes it possible to finally get rid of duplicate ports. Problem is, who's going to decide which one of them should go... I suspect that all those ports have small differences because not all changes were synched between them.
The list is (hopefully that's all):
- a810, a1300
- ixus135, ixus132
- sx260, sx240
Logged
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: 1.4 development planning thread
« Reply #142 on: 05 / September / 2015, 21:54:33 »
Quote from: srsa_4c on 05 / September / 2015, 18:58:10
The new style build process makes it possible to finally get rid of duplicate ports. Problem is, who's going to decide which one of them should go... I suspect that all those ports have small differences because not all changes were synched between them.
The list is (hopefully that's all):
- a810, a1300
- ixus135, ixus132
- sx260, sx240

One thing the this would change is that 'make firsub' etc will no longer work for the cameras that gets removed.

E.G. if the a810 becomes the source for the a1300 then 'make PLATFORM=a1300 PLATFORMSUB=100b firsub' will fail since the a1300 directories don't exist.

To build the a1300 you would need to add the TARGET_CAM, TARGET_FW and TARGET_PID values to the make command, CAM and FW are ok; but PID is not obvious.

One option would be to keep the platform/CAM/sub/FW directories, and only have a simple makefile.inc file in each one. All the other files can be removed from the platform and sub directories along with the loader directory.

The sample makefile.inc (for a1300) below seems to work - at least it builds; but I don't have any way to test it.
Code: [Select]
# 0x323e Found @ 0xfffe0040
TARGET_PID=12862
TARGET_CAM=a1300
TARGET_FW=$(PLATFORMSUB)

override PLATFORM=a810

include $(camfw)/makefile.inc

This solution might also mean that the TARGET_CAM, TARGET_FW and TARGET_PID values don't need to be stored in the camera_list.csv file and we could revert this back the simpler version (which might be more compatible with CHDK-Shell).

Phil.
Logged
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 philmoz

  • *****
  • 3450
    • Photos
Re: 1.4 development planning thread
« Reply #143 on: 05 / September / 2015, 22:41:43 »
Quote from: srsa_4c on 05 / September / 2015, 18:58:10
The new style build process makes it possible to finally get rid of duplicate ports. Problem is, who's going to decide which one of them should go... I suspect that all those ports have small differences because not all changes were synched between them.
The list is (hopefully that's all):
- a810, a1300
- ixus135, ixus132
- sx260, sx240

- a810, a1300        - minor differences, should be fairly easy to align them
- ixus135, ixus132  - no significant differences
- sx260, sx240       - probably not a good candidate, the SX260 has GPS which is enabled in platform_camera.h

Phil.
Logged
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

  • ******
  • 14128
Re: 1.4 development planning thread
« Reply #144 on: 06 / September / 2015, 00:45:14 »
Quote from: philmoz on 05 / September / 2015, 21:54:33
One option would be to keep the platform/CAM/sub/FW directories, and only have a simple makefile.inc file in each one. All the other files can be removed from the platform and sub directories along with the loader directory.
...
This solution might also mean that the TARGET_CAM, TARGET_FW and TARGET_PID values don't need to be stored in the camera_list.csv file and we could revert this back the simpler version (which might be more compatible with CHDK-Shell).
Without looking closely at the code, this sounds like a good direction to me.

Quote
- sx260, sx240       - probably not a good candidate, the SX260 has GPS which is enabled in platform_camera.h
One could put the GPS define in an ifdef on PLATFORMID in the platform_camera.h. Not sure if this would be a good thing
Logged
Don't forget what the H stands for.
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: 1.4 development planning thread
« Reply #145 on: 06 / September / 2015, 05:07:39 »
Attached patch is for the alternate method of handling the case where the same firmware exists for multiple cameras. It builds; but as I don't have any of the affected cameras I can't test it properly.

Changes:
- remove the PID, and Source Camera columns from camera_list.csv
- update auto_build.sh to cater for the removed columns
- fix Makefile when batch building all cameras with EABI
- add the necessary directories and files for SX270 & SX275 (these are the only affected cameras at the moment).

This is probably simpler than my previous version (with the extra columns in camera_list.csv).

This could also be applied to the cases where we currently copy one firmware version to another .zip file for a specific camera (e.g. a1100 100b & 100c). This would further simplify camera_list.csv and the build stuff, these versions could then also be built with a 'make firsub' command. The downside would be additional batch build time.

Phil.
Logged
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 msl

  • *****
  • 1280
  • A720 IS, SX220 HS 1.01a
    • CHDK-DE links
Re: 1.4 development planning thread
« Reply #146 on: 06 / September / 2015, 11:42:35 »
Interesting patch. This means that the current CHDK shell will be used again. I was able to successfully compile the SX280 via the GUI of the shell.  Only the duplicate firmware versions do not work. But that was to expected because of the changed structure.

This patch makes the repair of the CHDK shell easier. Thanks for that.

msl
Logged
CHDK-DE:  CHDK-DE links
*

Offline srsa_4c

  • ******
  • 4451
Re: 1.4 development planning thread
« Reply #147 on: 06 / September / 2015, 14:10:49 »
Quote from: philmoz on 06 / September / 2015, 05:07:39
Attached patch is for the alternate method of handling the case where the same firmware exists for multiple cameras. It builds; but as I don't have any of the affected cameras I can't test it properly.

Changes:
- remove the PID, and Source Camera columns from camera_list.csv
- update auto_build.sh to cater for the removed columns
- fix Makefile when batch building all cameras with EABI
- add the necessary directories and files for SX270 & SX275 (these are the only affected cameras at the moment).

This is probably simpler than my previous version (with the extra columns in camera_list.csv).
Thanks for this. Tried a batch build on the sx270-275-280 ports and found that the 'empty' ports don't build correctly. The reason seems to be the THUMB_FW define which auto_build.sh expects in platform/camera/makefile.inc.
Putting the files there seems to fix the issue. Alternatively, the script itself could also be modified to look in both possible makefile.inc files (this does not seem to be working yet, perhaps something else also relies on platform/camera/makefile.inc files?).
The main makefile's os-camera-lists target will also need to be adjusted (and I'll fix auto_build_parallel.sh too because I'm using it with my previously mentioned modification).
Quote
This could also be applied to the cases where we currently copy one firmware version to another .zip file for a specific camera (e.g. a1100 100b & 100c).
Well. I purposefully reintroduced copying of duplicate fw versions while I was working on reintegrating your patches earlier this year (the original patches also built each and every fw version separately, identical or not). I did that to shorten the time required for a batch build.
Quote
This would further simplify camera_list.csv and the build stuff
Can you show how this would look like?
Logged
*

Offline reyalp

  • ******
  • 14128
Re: 1.4 development planning thread
« Reply #148 on: 06 / September / 2015, 15:23:54 »
Quote from: srsa_4c on 06 / September / 2015, 14:10:49
Quote
This could also be applied to the cases where we currently copy one firmware version to another .zip file for a specific camera (e.g. a1100 100b & 100c).
Well. I purposefully reintroduced copying of duplicate fw versions while I was working on reintegrating your patches earlier this year (the original patches also built each and every fw version separately, identical or not). I did that to shorten the time required for a batch build.
FWIW, this could prevent the occasional confusion where people wonder why their 100b camera says it's running the 100c CHDK build. I don't think this is worth the extra build time by itself, but if it also simplifies the code I wouldn't be against it. We might be able to add a "skip copies" option for cases where we just want to test that all the source builds.

By my count there are ~50 of these sub copies, so the impact on batch builds would be noticeable.
Logged
Don't forget what the H stands for.
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: 1.4 development planning thread
« Reply #149 on: 06 / September / 2015, 17:05:17 »
Quote from: srsa_4c on 06 / September / 2015, 14:10:49
Quote
This could also be applied to the cases where we currently copy one firmware version to another .zip file for a specific camera (e.g. a1100 100b & 100c).
Well. I purposefully reintroduced copying of duplicate fw versions while I was working on reintegrating your patches earlier this year (the original patches also built each and every fw version separately, identical or not). I did that to shorten the time required for a batch build.
Quote
This would further simplify camera_list.csv and the build stuff
Can you show how this would look like?

The SOURCE_FIRMWARE column would not be needed (although if we left it there then CHDK-Shell would not break).

The rules for copying build versions could be removed, and the corresponding logic in auto_build.sh removed.

I'm not fussed either way, although if we keep the system of copying zip files for batch build then we should probably revert the logic (COPY_TO instead of SOURCE_FIRMWARE) so that CHDK-Shell will work.

We could potentially have both - copy the .zip files in a batch build, and have the dummy files/directories so that building a single camera/firmware version will work for all cases.

Phil.
Logged
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)
Pages: 1 ... 10 11 12 13 14 [15] 16 17 18 19 20   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal