The Mudita Pure phone (RT1051 target platform) has an eMMC storage of 16GB.
Due to RT1051 architecture, the executable can be run from SDRAM, DRAM or external flash (eMMC).
No matter which way you want to run the executable, you need to have all the necessary assets.
Everything from $BUILD_FOLDER/sys/ needs to be copied onto the eMMC.
Some assets can be omitted though e.g. for fonts the default fallback font will be used.
An executable can be uploaded directly to the memory in an executable (image) form. J-Link GDB Server enables this. J-Link Server messages "Download 15243 bytes…" represent this way of running the executable. The binary is lost on reset and/or power loss. Booting from SDRAM doesn't involve bootloader.
WARNING: Remember about switching off Automatic date and time function (in Settings->System->Date and time) otherwise Pure will hang/freeze after a while after starting debugging. Also remember to connect the USB to properly power the phone while debugging.
You need to upload the PurePhone.elf file. To do so run in three parallel consoles/sessions:
./StartJLinkServer.sh./StartJLinkServer.sh T6./run.sh <build folder> --product PurePhone./run.sh <build folder> --product BellHybrid/tmp/log.txt: JLinkRTTClient | tee /tmp/log.txtNOTE: Running on phone is done via gdb, this way enables you to debug running target.
The firmware is copied as a file to a special partition. When running from eMMC, the phone will always boot the image file which means it's permanently "flashed".
Booting from eMMC involves bootloader. There needs to be a working bootloader. The bootloader copies the firmware from the file to SDRAM and executes it each time the phone is started.
Files required to boot from eMMC are:
boot.bin.boot.json and .boot.json.crc32On linux you can use:
pureflashThe fastest command to burn image into the eMMC card: sudo pureflash <PurePhone.img> /dev/sdX
Note: Replace /dev/sdX with the disk name you found for your phone after connecting it to your computer.
dd or etcherYou can use any raw memory copy tool such as dd or etcher which will transfer the whole image built to the device memory. It will take much longer because it will copy the whole 16GB of memory.
dd example:
sudo dd if=./PurePhone.img of=/dev/sdb bs=1M status=progress conv=fsync 13:48:22
On MacOS you can use script:
./tools/macflash.shNOTE: End-user devices have direct access to the eMMC locked in bootloader.
Every device is loaded with additional updater software which is capable of updating any software package onto the device while keeping the last software as a backup. Updater utility is the only normal way to update devices running in-field and is used by Mudita Center.
NOTE: Providing a minimum viable update package and utility for the Open Source community is on our backlog. It can be created by trimming additional development API from: updater feature tests. You can ask for the development version of Mudita Center with "update from file" capability enabled.
Update package is described here: build targets
NOTE: all phones in field have eMMC access locked with a password, the following documentation is only for development devices or ones with eMMC unlocked or bypassed.
There are two ways to mount the phone as a USB MSC to gain full access to the memory - using a bootloader or Ozone debugger.
NOTE: Devices in field have password-locked bootloaders. This is by design - normal users shouldn't ever require access to raw eMMC.
We can have 3 types of partitions:
Both FAT and ext4 can be mounted natively on Linux, ext4 needs additional drivers on macOS. To access LittleFS you need to mount it via FUSE using the following command lfsfuse /dev/sdX <mount_point> --block_size=32768