Hi,
Let’s say I have developed a lot of features and install lots of new library on my DragonBoard.
Now, what is the fastest way to copy all of that into a “brand new” DragonBoard ?
That is how do I volume-produce my result to new DragonBoard ?
Could I build my custom rootfs.img and flash it ?
Thanks for any help.
Best Regards,
John
hi,
there is no ‘trivial’ method. If i had to do that I would do:
the thing to avoid here is to copy from eMMC to USB while the eMMC is mounted at /, and the system running, that’s why i recommended using an initrd.
Hi John
I haven’t tried this, but when I was building a new kernel for the board (see post https://www.96boards.org/forums/topic/rebuilding-the-boot-partition-on-410c/ ) I was able to use dd to copy a file (the boot image) onto an entire partition. You could use this same technique to save your boot image and rootfs to a SDCard, then to later restore it on your next machine.
Don’t forget to change the MAC address in /lib/firmware/wlan/macaddr0 on each board you copy to, otherwise all of you machines will have the same MAC address.
Full Disclosure: I am an employee of Qualcomm Canada, any opinions expressed in this or any other post may not reflect the opinions of my employer.
If I had to do that I would do:
- create an init ramdisk with busybox, and boot it.
- at prompt mount emmc, and mount an external disk
- copy all emmc content to usb, make sure to copy and preserve files permissions (cp -a)
- on a PC, use make_ext4fs tool to create rootfs.img
or: do the same operation with init ramdisk on new board, and copy from USB to eMMC
This question is very similar to mine - which is “How should I set up jenkins to automate creation of a rootfs?”
I have built the kernel + created an initrd similar to the one that has been released. I used gunzip and cpio to verify the contents first. I have created the kernel, initrd, modules and device-tree. And I can manually move these to the board, untar them, install the kernel via fastboot into boot (mmcblk0p8), and reboot the board and everything works with the new kernel.
But really what I want to do is streamline the rootfs creation after I build the kernel, modules and dtb (to go into mmcblk0p10). Is there any documentation on how to cross compile this from a release as a starting point?
ndec, I noticed that you also responded in another thread about custom patches to tools such as make_ext4 when making rootfs.img
Can you please make a suggestion about how to automate the creation of rootfs with jenkins? Is there anything in releases to help aid with this process? - like say a way to config for cross compile busybox or something similar. But really it’s the automation of rootfs I’m interested in.
I have also tried to use linaro port of debian live-build, and additionally cross live-build and have not been able to do this successfully on my Intel machine. I find it not well documented, the apt sources are incorrect for qemu, and the README in the git more accurate, and there is no implementation for arm64 in the scripts… Debian echos most of this on their efforts. Regardless I can’t seem to get any of the configurations provided ‘as is’ to run, which suggests to me that there is something missing… even though the documentations claims to be x86 Precise (12.04)… there are some extra things that were released in Saucy (13.04) and Trusty (14.04) for qemu… and I’m not even really sure how live-build is using processor emulation anyway (maybe qemu-img?)… anyway…
I have given up on live-build method and I am looking for something else. Does anyone know where this type of procedure might be documented for arm64? If I have to roll my own, that’s fine - but I know that it must be automated in some fashion from linaro… question is how are you guys automating this?
hi,
I don’t think our processes are documented per-se… however our images are entirely built from scratch, and all the scripts we use on our Jenkins are public… So I can give you all the links, and maybe you can have a look… I know some people out there have been able to reproduce our Jenkins setup… We might even have all the IT/server side config available… but i am really not involved on that…
The image build process is mostly split in 2 jobs:
we create the base arm64 rootfs, we use live-build, but probably a patched version, which is in our archives. We create base image for -developer, -alip and maybe a few others. that creates generic rootfs by pulling packages from ubuntu (or debian) archives and our own archives.
then we have another job that builds the kernel/modules and assemble the rootfs from #1 with the modules. We use some fairly complex tools to do that… but again everything is out there in our archives, and our scripts…
So for ubuntu, the relevant jobs are:
https://ci.linaro.org/job/ubuntu-arm64-rootfs/
https://ci.linaro.org/job/lt-qcom-ubuntu-images-arm64/
and for Debian:
https://ci.linaro.org/job/debian-arm64-rootfs/
https://ci.linaro.org/job/lt-qcom-debian-images-arm64/
We have similar jobs for armv7, btw.
all our Jenkins jobs are under git here:
job/configs.git - (as JOB_NAME.yaml)
We have our own archive where we publish our debian packages. That includes host packages for tools we use during the build (qemu, live-build, …) as well as modified packages for the target.
Most of Linaro changes are in this ‘package overlay’:
http://repo.linaro.org/ubuntu/linaro-overlay/
While the QCOM specific changes are in a specific overlay
http://repo.linaro.org/ubuntu/qcom-overlay/
Though we are 1) trying to upstream our changes in Debian, 2) will be moving as much as possible into the linaro-overlay
So, I think in these scripts you have all you need. Our Jenkins nodes run on ubuntu 14.04. Until very recently all the builds were done on x86_64, we just switched to native builds for arm… so you should be able to run them on x86…
I recommend you look at them, and ask questions here, if you have any issue…
Isn’t there a way to create an image of the eMMC - the reverse of > fastboot flash ?
This is a cross-post (asking the same question twice) in a two year old thread. It is answered in the more recent thread:
