Difference between revisions of "Development for 10393"
From ElphelWiki
(→Flash vs micro SD) |
(→Flash vs micro SD) |
||
| Line 33: | Line 33: | ||
** provisions are made to limit write cycles and to prevent inadvertent file system changes | ** provisions are made to limit write cycles and to prevent inadvertent file system changes | ||
** overlayfs file system merges nonvolatile (flash) and volatile (ram disk) file systems, power-cycling discards all file modifications made during the last session | ** overlayfs file system merges nonvolatile (flash) and volatile (ram disk) file systems, power-cycling discards all file modifications made during the last session | ||
| − | ** an extra sync command (overlay_sync) and a proper reboot is required to commit file system changes to the system flash memory (see [[10393_manual#Change_default_ip_address]]). | + | ** an extra sync command (overlay_sync) and a proper reboot is required to commit file system changes to the system flash memory (see overlay_syn usage example [[10393_manual#Change_default_ip_address]]). |
===Environment tree=== | ===Environment tree=== | ||
Revision as of 17:27, 24 October 2018
Contents
Setup environment
Get sources and build default images: Instructions
top project
| file | description |
|---|---|
| projects-default.json |
|
| setup.py |
|
| check_versions.py | local repository vs running on target hardware version checker |
Flash vs micro SD
- micro SD cards work best for development
- replaceable
- changes get written to the card, no extra sync required
- flash works best for a production system:
- non-replaceable
- provisions are made to limit write cycles and to prevent inadvertent file system changes
- overlayfs file system merges nonvolatile (flash) and volatile (ram disk) file systems, power-cycling discards all file modifications made during the last session
- an extra sync command (overlay_sync) and a proper reboot is required to commit file system changes to the system flash memory (see overlay_syn usage example 10393_manual#Change_default_ip_address).
Environment tree
elphel393
├── bootable-images -> poky/build/tmp/deploy/images/elphel393/ - poky generated boot images
├── fpga-elphel - fpga projects, matching recipes are in meta/meta-elphel393/recipes-core/
│ ├── x359
│ ├── x393
│ └── x393_sata
├── linux-elphel - kernel - a kernel tree with Elphel's sources only - it is merged with the full kernel tree
├── meta - extra recipe layers for poky
│ ├── meta-elphel393 - Elphel's recipes: fpga, device tree, kernel and applications, lots of bbappends
│ ├── meta-ezynq - Elphel's recipes for u-boot
│ ├── meta-openembedded - recipes (like PHP) that were not included in poky 2.0
│ ├── meta-swupdate - swupdate recipes (not yet used)
│ └── meta-xilinx - Xilinx's recipes, help to build kernel and device tree
├── poky - poky tree
│ ├── build
│ │ └── conf
│ │ ├── bblayers.conf - paths to extra layers (generated by setup.py)
│ │ └── local.conf - have a look inside, local configuration (generated by setup.py)
│ └── meta - poky's recipes
├── rootfs-elphel - user applicatons projects and init scripts, matching recipes are found in meta/meta-elphel393/recipes-core/
│ ├── elphel-apps-autocampars - camera parameters manager - setup, store/restore, set default
│ ├── elphel-apps-autoexposure - autoexposure daemon
│ ├── elphel-apps-camogm - recorder program
│ ├── elphel-apps-editconf
│ ├── elphel-apps-gps - gps receiver application
│ ├── elphel-apps-histograms - histograms
│ ├── elphel-apps-imgsrv - image server
│ ├── elphel-apps-php-extension - php functions, compiled as a php extension (part of php recipe)
│ ├── elphel-apps-tempmon - temperature monitor
│ ├── elphel-init - system init script
│ ├── elphel-udev-rules - udev rules: drive automount
│ ├── elphel-web-393 - web GUIs
│ ├── elphel-web-camvc - main control GUI, ported from 353
│ └── elphel-web-hwmon - hardware monitor
└── tools
└── elphel-tools-update - useful scripts, e.g. create bootable mmc
Change repository address, branch, hash
- change uri: edit elphel393/projects.json
- change hash: edit elphel393/projects.json:
"elphel-apps-camogm":[ "https://git.elphel.com/Elphel/elphel-apps-camogm.git", "master","" <- leave empty to get the latest, add hash to freeze ],
- change branch: edit elphel393/poky/build/conf/local.conf
ELPHEL393_branches += "elphel-apps-camogm:framepars"
Kernel
Add new driver
- examples in elphel393/linux-elphel/src
- add new files to the tree
- do not forget KConfig and Makefiles
- change kernel config in elphel393_fixold/meta/meta-elphel393/recipes-kernel/linux/config/elphel393.cfg - clean then rebuild the kernel. The cfg file gets copied to the poky's kernel build directory.
Applications
Create new project
The best reference projects are in elphel393/rootfs-elphel/
- Place project files to elphel393/rootfs-elphel/
- Create a recipe in elphel393/meta/meta-elphel393/.../
- In the recipe set package name - it will go to the rootfs recipe elphel393/meta/meta-elphel393/recipes-core/images/core-image-elphel393.bb
- bitbake core-image-elphel393
Project structure
recipe
elphel393/meta/meta-elphel393/recipes-core/init/init_1.0.bb
Note: The recipe and the project sources are in different repos
in repository
rootfs-elphel/elphel-init/ ├── eclipse_project_setup ├── LICENSE ├── Makefile ├── README.md ├── run_bitbake.sh ├── src │ ├── init_elphel393 │ ├── init_elphel393.py │ ├── init_elphel393.sh │ ├── init_eyesis12.sh │ ├── init_eyesis_bottom2.sh │ └── Makefile └── VERSION
after building
rootfs-elphel/elphel-init/ ├── bitbake-logs -> /.../elphel393/poky/build/tmp/work/cortexa9-neon-poky-linux-gnueabi/init/1_0-60/temp ├── eclipse_project_setup ├── image -> /.../elphel393/poky/build/tmp/work/cortexa9-neon-poky-linux-gnueabi/init/1_0-60/image ├── LICENSE ├── Makefile ├── README.md ├── run_bitbake.sh ├── src │ ├── init_elphel393 │ ├── init_elphel393.py │ ├── init_elphel393.sh │ ├── init_eyesis12.sh │ ├── init_eyesis_bottom2.sh │ └── Makefile ├── sysroots -> /home/oleg/GIT/elphel393_fixold/poky/build/tmp/sysroots └── VERSION
