I'm building an enterprise IPA file.
What's the maximum app size limit of the IPA file that I can build?
According to this apple link:
https://help.apple.com/app-store-connect/#/dev611e0a21f
1) Maximum executable file size (iOS 9.0 and later): 500 MB
--> What is the meaning of "Maximum executable file size? is it .h .m .a .framework files? how do I check it?
2) Your app’s total uncompressed size must be less than 4GB.
--> is this the size of the xarchive file?
1.) Maximum executable size
The documentation states:
each Mach-O executable file — for example, app_name.app/app_name — must not exceed these maximum file sizes:
for iOS 9.0 and later: 500 MB (For the total of all __TEXT sections in the binary.)
So you
uncompress your ipa file (which in fact is simply a zip file, just rename it :-)
go to Payload\app_name.app
find out the size of app_name
For example:
user$ unzip Enterprise.ipa
user$ cd Payload/Enterprise.app/
user$ size Enterprise
__TEXT __DATA __OBJC others dec hex
8192 4096 0 20480 32768 8000 Enterprise (for architecture armv7)
8192 4096 0 20480 32768 8000 Enterprise (for architecture armv7s)
So you simply sum up the size of the __TEXT sections and check if it fits.
2.) Total uncompressed size
This is simple the size of everything that gets uncompressed - see above: .ipa is simply a zip format, therefore just uncompress it and check the size of all:
user$ du -k Payload/
4 Payload//Enterprise.app/_CodeSignature
8 Payload//Enterprise.app/en.lproj
128 Payload//Enterprise.app
128 Payload/
(so here it's 128 kB, quite room for improvements I guess)
Related
I'm currently reading Master Embedded Linux Programming and I'm on the chapter where it goes into bootloaders, more specifically U-Boot for the Beaglebone Black.
I have built a crosscompiler and I'm able to build U-Boot, however I can't make it run the way it is described in the book.
After some experimentation and Google'ing, I can make it work by writing MLO and u-boot.img in raw mode (using these command)
However, if I put the files in a FAT32 MBR boot partition, the Beaglebone will not boot, it will only show a string of C's, which indicate that it is trying to get its bootloader from the serial interface and it has decided it cannot boot from SD card.
I have also studied this answer. According to that answer I should be doing everything correctly. I've tried to experiment with the MMC raw mode options in the U-Boot build configuration, but I've not been able to find a change that works.
I feel like there must be something obvious I'm missing, but I can't figure it out. Are there any things I can try to debug this further?
Update: some more details on the partition tables.
When using the "raw way" of putting LBO and u-boot.img on the SD cards, I have not created any partitions at all. This works:
$ sudo sfdisk /dev/sda -l
Disk /dev/sda: 117,75 GiB, 126437294080 bytes, 246947840 sectors
Disk model: MassStorageClass
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
When trying to use a boot partition, that does not work, I have this configuration:
$ sudo sfdisk /dev/sda -l
Disk /dev/sda: 117,75 GiB, 126437294080 bytes, 246947840 sectors
Disk model: MassStorageClass
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x3d985ec3
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 133119 131072 64M c W95 FAT32 (LBA)
Update 2: The contents of the boot partition is the exact same 2 files that I use for the raw writes, so they are confirmed to work:
$ ls -al
total 1000
drwxr-xr-x 2 peter peter 16384 Jan 1 1970 .
drwxr-x---+ 3 root root 4096 Jul 18 08:44 ..
-rw-r--r-- 1 peter peter 108184 Jul 14 13:56 MLO
-rw-r--r-- 1 peter peter 893144 Jul 14 13:56 u-boot.img
Update 3: I have already tried the following U-Boot options to try it go get to work (in the SPL / TPL menu):
"Support FAT filesystems" This is enabled by default. I can't really find a good reference for the U-Boot options, but I am guessing this is what enables booting from a FAT partition (which is what I'm trying to do)
"MCC raw mode: by sector" I have disabled this. As expected, this indeed breaks the booting in raw mode, which is the only thing I got working up till now.
"MCC raw mode: by partition". I have tried to enable this and using partition 1 to load U-Boot from. I'm not sure how to understand this option. I assume raw mode does not require partitions, but this asks for what partition to use...
In general, if any one can point me to a U-Boot configuration reference, that would already by very helpful. Right now, I'm just randomly turning things on and off that sound like they may help.
I have compiled the u-boot for beaglebone black but the only message that I can see is:
At elinux.org tutorial the expected result is some errors followed by the u-boot terminal available to use.
To build u-boot I've followed the steps:
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- distclean
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- am335x_evm_config
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-
my SD Card is set like this:
Disk /dev/sdd: 28,89 GiB, 31002198016 bytes, 60551168 sectors
Disk model: SD/MMC/MS PRO
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x33bcefe5
Device Boot Start End Sectors Size Id Type
/dev/sdd1 * 2048 2099199 2097152 1G c W95 FAT32 (LBA)
/dev/sdd2 2099200 60551167 58451968 27,9G 83 Linux
Unfotunetly I confirmed that was a hardware issue :(
Here is the Makefile: https://github.com/somersbmatthews/vault/blob/master/Makefile
Here is what happens when I run it:
somersbmatthews#pop-os:~/go/src/vault$ make static-dist dev-ui
--> Installing JavaScript assets
yarn install v1.19.1
[1/5] Validating package.json...
[2/5] Resolving packages...
success Already up-to-date.
Done in 0.75s.
> node-sass#4.14.1 install /home/somersbmatthews/go/src/vault/ui/node_modules/node-sass
> node scripts/install.js
node-sass build Binary found at /home/somersbmatthews/go/src/vault/ui/node_modules/node-sass/vendor/linux-x64-64/binding.node
> node-sass#4.14.1 postinstall /home/somersbmatthews/go/src/vault/ui/node_modules/node-sass
> node scripts/build.js
Binary found at /home/somersbmatthews/go/src/vault/ui/node_modules/node-sass/vendor/linux-x64-64/binding.node
Testing binary
Binary is fine
node-sass#4.14.1 /home/somersbmatthews/go/src/vault/ui/node_modules/node-sass
--> Building Ember application
yarn run v1.19.1
$ ember build -prod
INFORMATION (ember-cli-pretender)
ember-auto-import seems to be in your package dependencies.
As a result, you don't need pretender to be wrapped anymore.
You can install pretender and remove ember-cli-pretender.
⠋ BuildingWARNING: Option "nodeWorker" is deprecated since workerpool#5.0.0. Please use "workerType" instead.
WARNING: Option "nodeWorker" is deprecated since workerpool#5.0.0. Please use "workerType" instead.
WARNING: Option "nodeWorker" is deprecated since workerpool#5.0.0. Please use "workerType" instead.
Environment: production
⠏ BuildingThe 'this' keyword is equivalent to 'undefined' at the top level of an ES module, and has been rewritten
⠦ Building'#ember/string' is imported by ../../../../../../tmp/broccoli-607060b8WPADOlU6j8/cache-260-rollup/build/-private/system/normalize-model-name.js, but could not be resolved – treating it as an external dependency
'#ember/string' is imported by ../../../../../../tmp/broccoli-607060b8WPADOlU6j8/cache-260-rollup/build/-private/adapters/build-url-mixin.js, but could not be resolved – treating it as an external dependency
'#ember/string' is imported by ../../../../../../tmp/broccoli-607060b8WPADOlU6j8/cache-260-rollup/build/-private/system/debug/debug-adapter.js, but could not be resolved – treating it as an external dependency
⠏ Building[BABEL] Note: The code generator has deoptimised the styling of /home/somersbmatthews/go/src/vault/ui/node_modules/swagger-ui-dist/swagger-ui-bundle.js as it exceeds the max of 500KB.
Generating files needed by Storybook
Parsing /tmp/broccoli-607060b8WPADOlU6j8/out-630-broccoli_merge_trees/index.html
Generating preview-head.html
Generating files needed by Storybook
Generating .env
cleaning up...
Built project successfully. Stored in "../pkg/web_ui".
File sizes:
- ../pkg/web_ui/assets/chunk.3.e73ac42f48b4e5ab3d48.js: 1.08 MB (316.69 KB gzipped)
- ../pkg/web_ui/assets/node-asset-manifest.js: 1.02 KB (445 B gzipped)
- ../pkg/web_ui/assets/vault-895816690cab246cbd3b9423defc2f53.css: 482.96 KB (56.99 KB gzipped)
- ../pkg/web_ui/assets/vault-b8afdc29f93ad91f89268835698b0711.js: 1.2 MB (185.17 KB gzipped)
- ../pkg/web_ui/assets/vendor-8381b7eebdb7ea85cb88b80f3029e0e8.css: 14.21 KB (3.66 KB gzipped)
- ../pkg/web_ui/assets/vendor-ded9c2047ac30c216b8015683667178a.js: 1.82 MB (457.27 KB gzipped)
- ../pkg/web_ui/ember-fetch/fetch-fastboot-38cfd9007f94f81f5a2bc13690efc343.js: 1020 B (562 B gzipped)
- ../pkg/web_ui/engines-dist/kmip/assets/engine-ce86d837f49968e27331ecc744f8288d.js: 68.55 KB (9.29 KB gzipped)
- ../pkg/web_ui/engines-dist/kmip/assets/engine-vendor-d41d8cd98f00b204e9800998ecf8427e.css: 0 B
- ../pkg/web_ui/engines-dist/kmip/assets/engine-vendor-d41d8cd98f00b204e9800998ecf8427e.js: 0 B
- ../pkg/web_ui/engines-dist/kmip/config/environment-0123205ae026fc9ed3e41f1d552270f8.js: 86 B (100 B gzipped)
- ../pkg/web_ui/engines-dist/open-api-explorer/assets/engine-83cdd1e87b4c1568b63b394b62e6e0c5.js: 27.16 KB (5.14 KB gzipped)
- ../pkg/web_ui/engines-dist/open-api-explorer/assets/engine-9dcfdf942f31c3caa1d6dfd57c3cc072.css: 3.38 KB (829 B gzipped)
- ../pkg/web_ui/engines-dist/open-api-explorer/assets/engine-vendor-6faadde6d1de73cd00d4f818f4f60c75.css: 149.46 KB (22.77 KB gzipped)
- ../pkg/web_ui/engines-dist/open-api-explorer/assets/engine-vendor-d41d8cd98f00b204e9800998ecf8427e.js: 0 B
- ../pkg/web_ui/engines-dist/open-api-explorer/config/environment-6da0fcce17b2031e2559754701e92d69.js: 194 B (170 B gzipped)
- ../pkg/web_ui/engines-dist/replication/assets/engine-52dc634acbe2629436188771450e81ba.js: 97.81 KB (15.78 KB gzipped)
- ../pkg/web_ui/engines-dist/replication/assets/engine-vendor-d41d8cd98f00b204e9800998ecf8427e.css: 0 B
- ../pkg/web_ui/engines-dist/replication/assets/engine-vendor-d41d8cd98f00b204e9800998ecf8427e.js: 0 B
- ../pkg/web_ui/engines-dist/replication/config/environment-fcc3a0f22bdfd265a50708864776440a.js: 100 B (104 B gzipped)
- ../pkg/web_ui/sw-registration-65dd6e15d4d40ce435383a9edaccfc03.js: 1.14 KB (616 B gzipped)
- ../pkg/web_ui/sw.js: 1.26 KB (675 B gzipped)
Done in 70.33s.
--> Generating static assets
make[1]: Entering directory '/home/somersbmatthews/go/src/vault'
goimports -w $(find . -name '*.go' | grep -v pb.go | grep -v vendor)
make[1]: Leaving directory '/home/somersbmatthews/go/src/vault'
==> Checking compiled UI assets...
==> Checking that build is using go version >= 1.14.7...
==> Using go version 1.15.2...
==> Removing old directory...
==> Building...
flag provided but not defined: -gcflags
Usage: gox [options] [packages]
Gox cross-compiles Go applications in parallel.
If no specific operating systes or architectures are specified, Gox
will build for all pairs supported by your version of Go.
Options:
-arch="" Space-separated list of architectures to build for
-build-toolchain Build cross-compilation toolchain
-ldflags="" Additional '-ldflags' value to pass to go build
-os="" Space-separated list of operating systems to build for
-osarch="" Space-separated list of os/arch pairs to build for
-output="foo" Output path template. See below for more info
-parallel=-1 Amount of parallelism, defaults to number of CPUs
-verbose Verbose mode
Output path template:
The output path for the compiled binaries is specified with the
"-output" flag. The value is a string that is a Go text template.
The default value is "{{.Dir}}_{{.OS}}_{{.Arch}}". The variables and
their values should be self-explanatory.
Platforms (OS/Arch):
The operating systems and architectures to cross-compile for may be
specified with the "-arch" and "-os" flags. These are space separated lists
of valid GOOS/GOARCH values to build for, respectively. You may prefix an
OS or Arch with "!" to negate and not build for that platform. If the list
is made up of only negations, then the negations will come from the default
list.
Additionally, the "-osarch" flag may be used to specify complete os/arch
pairs that should be built or ignored. The syntax for this is what you would
expect: "darwin/amd64" would be a valid osarch value. Multiple can be space
separated. An os/arch pair can begin with "!" to not build for that platform.
The "-osarch" flag has the highest precedent when determing whether to
build for a platform. If it is included in the "-osarch" list, it will be
built even if the specific os and arch is negated in "-os" and "-arch",
respectively.
make: *** [Makefile:39: dev-ui] Error 2
Here is the full repo: https://github.com/somersbmatthews/vault
Lines 38 and 39 in the Makefile are:
dev-ui: assetcheck prep
#CGO_ENABLED=$(CGO_ENABLED) BUILD_TAGS='$(BUILD_TAGS) ui' VAULT_DEV_BUILD=1 sh -c "'$(CURDIR)/scripts/build.sh'"
How do I get more information on this error? "Error 2" appears twice in the code in two files as errors for a MongoDB dependency:
https://github.com/somersbmatthews/vault/blob/master/vendor/go.mongodb.org/mongo-driver/x/mongo/driver/auth/internal/gssapi/sspi_wrapper.h
https://github.com/somersbmatthews/vault/blob/master/vendor/go.mongodb.org/mongo-driver/x/mongo/driver/auth/internal/gssapi/gss_wrapper.h
Thanks for any help :)
Problem solved as per https://groups.google.com/g/vault-tool/c/xyV7-FMHrEE?pli=1
use command make bootstrap to update gox and other go tools.
NOTE: previous versions of gox will make an empty file called bindata.go Just delete this.
How can I test the memory footprints programs written for a RISC and a CISC processor?
Which one would require more memory and why?
So, the way I would do this is via experimentation. I would compile binaries for both types of architectures and then use gcc tools to see what the memory footprints are. For the following examples, I will compare x86_64 and RISCV architectures. First method I would use is the size tool which breaks down the various portions of an elf and reports the size.
# riscv64-unknown-elf-size Test.elf
Which will output something like this
text data bss dec hex filename
XXXXXX XXX XXXXXXX XXXXXXX XXXXXX Test.elf
Then compare that to the x86 version:
# size Test.exe
Which will output something like this
text data bss dec hex filename
XXXXXX XXX XXXXXXX XXXXXXX XXXXXX Test.exe
The other method is to convert your elf to a straight binary that will be bit for bit what is put into your memory ( this may not be true for more complex memory architectures, but we'll assume a simple case where it is all stored and executed from a RAM ). The tool for that is objcopy.
# riscv64-unknown-elf-objcopy -O binary Test.elf Test.elf.bin
# objcopy -O binary Test.exe Test.exe.bin
Then check the sizes of the two resulting bin files.
I have used spiffsimg to create a single file containing multiple lua files:
# ./spiffsimg -f lua.img -c 262144 -r lua.script
f 4227 init.lua
f 413 cfg.lua
f 2233 setupWifi.lua
f 7498 configServer.lua
f 558 cfgForm.htm
f 4255 setupConfig.lua
f 14192 main.lua
#
I then use esptool.py to flash the NodeMCU firmware and the file containing the lua files to the esp8266 (NodeMCU dev kit):
c:\esptool-master>c:\Python27\python esptool.py -p COM7 write_flash -fs 32m -fm dio 0x00000 nodemcu-dev-9-modules-2016-07-18-12-06-36-integer.bin 0x78000 lua.img
esptool.py v1.0.2-dev
Connecting...
Running Cesanta flasher stub...
Flash params set to 0x0240
Writing 446464 # 0x0... 446464 (100 %)
Wrote 446464 bytes at 0x0 in 38.9 seconds (91.9 kbit/s)...
Writing 262144 # 0x78000... 262144 (100 %)
Wrote 262144 bytes at 0x78000 in 22.8 seconds (91.9 kbit/s)...
Leaving...
I then run ESPLorer to check the status and get:
PORT OPEN 115200
Communication with MCU..Got answer! AutoDetect firmware...
Can't autodetect firmware, because proper answer not received.
NodeMCU custom build by frightanic.com
branch: dev
commit: b21b3e08aad633ccfd5fd29066400a06bb699ae2
SSL: true
modules: file,gpio,http,net,node,rtctime,tmr,uart,wifi
build built on: 2016-07-18 12:05
powered by Lua 5.1.4 on SDK 1.5.4(baaeaebb)
lua: cannot open init.lua
>
----------------------------
No files found.
----------------------------
>
Total : 3455015 bytes
Used : 0 bytes
Remain: 3455015 bytes
The NodeMCU firmware flashed correctly, but the lua files can't be located.
I have tried flashing to other locations (0x84000, 0x7c000), but I am just guessing at these locations based on reading threads on github.
I used the NodeMCU file.fscfg() routine to get the flash address and size. If I only flash the NodeMCU firmware I get the following:
print (file.fscfg())
524288 3653632
534288 is 0x80000, so I tried flashing only the spiffsimg file (lua.img) to 0x8000, then ran the same print statement and got:
print (file.fscfg())
786432 3391488
The flash address incremented by the exact number of bytes in the lua.img - which I don't understand, why would the flash address change? Is the first number returned by file.fscfg not the starting flash address, but the ending flash address?
What is the correct address for flashing an image file, contain lua files, that was created by spiffsimg?
The version of spiffsimg found here will provide the correct address for flashing an image file that contains lua files.
Do not use this version of spiffsimg as it is out of date.
To install the spiffsimg utility, you need to download and install the entire nodemcu-firmware package (into a linux environment, use make to install - note: make on my debian linux box generated an error, but i was able to go to the ../tools/spiffsimg subdirectory and run make on the Makefile found in that directory to create the utility).
The spiffsimg instructions found here are quite clear, with one exception: the file name you specify, with the -f parameter, needs to include the characters %x. The %x will be replaced with the address that the image file should be flashed to.
For example, the command
spiffsimage -f %x-luaFiles.img -S 4MB -U 465783 -r lua.script
will create a file, in the local directory, with a name like: 80000-luaFiles.img. Which means you should install that image file at address 0x80000 on the ESP8266.
I've never done that myself but I'm reasonably confident the correct answer can be extracted from the docs.
-f specifies the filename for the disk image. '%x' will be replaced
by the calculated offset of the file system.
And a bit further down
The disk image file is placed into the bin directory and it is named
0x<offset>-<size>.bin where the offset is the location where it
should be flashed, and the size is the size of the flash part.
However, there's a slight mismatch between the two statements. We may have a bug in the docs. If "'%x' will be replaced..." then I'd expected the final name won't contain 0x anymore.
Furthermore, it is possible to define a fixed SPIFFS position when you build the firmware.
#define SPIFFS_FIXED_LOCATION 0x100000
This specifies that the SPIFFS filesystem starts at 1Mb from the start of the flash. Unless
otherwise specified, it will run to the end of the flash (excluding
the 16k of space reserved by the SDK).