I still do not understand why the symlink are not generated (no /disk in /dev); from @Loic previous post it can be either bad GPT or udev rules. How can I check those udev rules are correct or wrong?
If you are using the initramfs from DB410C then you can be pretty confident the udev rules are correct.
Also note that the “sd” in “sd-device” stands for systemd and is not necessarily anything to do with an SD ard.
Thanks for the help.
When comparing logs between my custom board and a dev board, my logs start to fail after the error mentionned above:
Assertion ‘path_startswith(device->syspath, “/sys/”)’ failed at …/src/libsystemd/sd-device/sd-device.c:681, function sd_device_get_syspath( ). Aborting.
Aborted
Any idea what this error message is about? I have only found this bug report…
Is seems linked to “systemd-gpt-auto-generator”
I am giving it a try; From what I understood I need to generate rootfs.cpio with buildroot, use it as ramdisk when generating new boot.img that I can flash with fastboot and enjoy the new tools in initramfs to check my emmc, etc…
Is that correct?
What do you suggest to test the emmc?
edit: OK I could install buildroot, I can now make more tests
Using buildroot console, I tried fsck on /dev/mmcblk0p10 but got an error
fsck -t ext4 /dev/mmcblk0p10
fsck from util-linux 2.32
fsck: error 2 (No such file or directory) while executing fsck.ext4 for /dev/mmcblk0p10
I can use mmc tool to inspect my emmc but this doesn’t help my boot.
May I ask how do you see that the partition label is wrong ?
I could also “manually” mount the rootfs and then access it. But no correct full boot yet.
mount -t ext4 /dev/mmcblk0p10 /root
[ 238.639330] EXT4-fs (mmcblk0p10): mounted filesystem with ordered data mode. Opts: (null)
Also, for the record, I tried to boot without initrd (empty file), and with the command line modified to root=/dev/mmcblk0p10. Then I have more repeatable boot error: systemd-gpt-auto-generator error, see logs.
Lastly, could my troubles be due to the fact I use emmc5.0 (and not 4.5?). But I do not think so…
hi,
the gpt_both.bin file is generated from
https://git.linaro.org/landing-teams/working/qualcomm/db-boot-tools.git/
See:
gpt_both.bin is used when flashing the GPT with ‘fastboot flash partition’. When you are using QDL, you are using gpt_main.bin and gpt_backup.bin, and these files are released as binaries, and you can’t rebuild them yourself. So if you want to generate your own GPT, you have to use gpt_both.bin and fastboot to flash it.
The missing links in /dev could be related to this error in the boot:
[ 2.277884] systemd-udevd[1511]: unhandled level 2 translation fault (11) at 0xaaaaec000000, esr 0x92000006, in libc-2.26.so[ffff85483000+141000]
Things look really odd in that thread… I am tempting to say that the root cause is something different… like under powered CPU/board… Have you ever found a build that worked well (even a QCOM Android build)?
In any case, the best thing to do right now, is to boot into a ramdisk and stress test the system and the eMMC from the initrd (create/modify GPT on eMMC, read/write stress tests, … ).
oh… and just now, i notice your last sentence about emmc5.0… i don’t think it has been tested yet… see eMMC 4.5 vs eMMC 5.0
I’m ignoring your earlier question about how to build buildroot since it looks like you’ve got it running. Very glad to hear this. buildroot can bring in lots of useful diagnostics (making it easier to run the stress testing @anon91830841 recommended).
The file that is not found is probably fsck.ext4 rather than /dev/mmcblk0p10 . You need to enable it in the buildroot config (make menuconfig → Target packages → Filesystem and flash utilities → e2fsprogs → fsck).
Basically the next step is to tour make menuconfig in buildroot turning on some of the more interesting diagnostic tools. Personally I tend to use stress-ng (in Debugging, profiling and benchmark) but there’s many different tools you can choose from.
Daniel.
I could launch a few tests; I use stress and ramspeed for the memory tests.
Ramspeed and stress -c applied on the RAM gives good results.
For the emmc, it does not seems bad either. It fails with “stress -v -m 4 -t 2” but I double checked on my dev board (which works fine) and it fails also. Stress results are fine with stress -m parameters smaller than 4.
I monitored the voltages on the emmc while stressing, did not notice anything wrong.
Fyi, here are logs of buildroot console with tests such as manually mounting rootfs.
So this doesn’t tell me why my rootfs is not mounted at “normal” boot. I will give more trials on modifying the GPT; and see about this 5/4.5 emmc
It’s seems pretty clear my troubles are related to my hardware/custom memories. Any chance I have to modify the cdt (“sbc_1.0_8016.bin”) with my memory informations to get a correct boot? Or should I only have a look at the GPT?
Thank you,
Victor
I tried to flash Android for comparizon, using official release files from here
But I end up with this error at fastboot flash:
target reported max download size of 268435456 bytes
erasing ‘userdata’…
OKAY [ 0.350s]
sending ‘userdata’ (125938 KB)…
OKAY [ 18.367s]
writing ‘userdata’…
FAILED (remote: size too large)
finished. total time: 18.722s
Not sure I want to go through the pain of compiling new android kernel, as I do not have this error when flashing debian.
userdata is supposed to be an ‘empty’ partition on first boot. you should be able to resize it. I just tried, it’s not empty, but has small content, even though the image is 5GB.
here are commands to resize the image (to 1GB):
tar xf userdata.img.tar.xz
simg2img userdata.img userdata.img.raw
e2fsck -f userdata.img.raw
resize2fs userdata.img.raw 1G
img2simg userdata.img.raw userdata-resized.img
You should be able to flash it after that.
Thank you @anon91830841, that worked.
Android boot fails with following logs. There are some stranges numbers sequences in the logs. After that, It repeats constantly with:
[ 18.641896] msm_dba_get_probed_device: Device not found (adv7533, 0)
[ 18.647202] msm_dba_register_client: Device not found (adv7533, 0)
[ 18.653378] mdss_dba_utils_init: ds not configured
then reboots and start again…
This makes sense as I have no HDMI on my custom board.
I guess I have to modify the config and rebuild the android kernel… but I would rather use linux directly
In my custom Linux, I had modified the dtbs file by removing everything related to adv in the dtsi file. My kernel boots on a custom board with a SOM that has no HDMI, but does not boot on my custom board. Maybe there is something more I should do about that?
In buildroot, I have this result with fdisk -l:
# fdisk -l
Found valid GPT with protective MBR; using GPT
Disk /dev/mmcblk0: 7634944 sectors, 3728M
Logical sector size: 512
Disk identifier (GUID): 98101b32-bbe2-4bf2-a06e-2bb33d000c20
Partition table holds up to 12 entries
First usable sector is 34, last usable sector is 7634910
Number Start (sector) End (sector) Size Name
1 131072 131075 2048 cdt
2 262144 263167 512K sbl1
3 263168 264191 512K rpm
4 264192 266239 1024K tz
5 266240 267263 512K hyp
6 267264 267295 16384 sec
7 267296 269343 1024K aboot
8 269344 400415 64.0M boot
9 400416 402463 1024K devinfo
10 402464 7634910 3531M rootfs
Disk /dev/mmcblk0boot1: 2 MB, 2097152 bytes, 4096 sectors
64 cylinders, 4 heads, 16 sectors/track
Units: cylinders of 64 * 512 = 32768 bytes
Disk /dev/mmcblk0boot1 doesn't contain a valid partition table
Disk /dev/mmcblk0boot0: 2 MB, 2097152 bytes, 4096 sectors
64 cylinders, 4 heads, 16 sectors/track
Units: cylinders of 64 * 512 = 32768 bytes
Disk /dev/mmcblk0boot0 doesn't contain a valid partition table
not sure if this Disk /dev/mmcblk0boot0 doesn’t contain a valid partition table error could be a hint for me?
Otherwise my last hope is to find an hardware mistake now…
From Buildroot busybox, I can manually mount and access the rootfs with # mount -t ext4 /dev/mmcblk0p10 /root
Any idea how I can manually switch the root to this rootfs instead of the busybox?
Make the ramdisk invalid (the empty file should work) and the kernel will start honouring the root= argument again. Without a ramdisk you must use specify the rootfs explicitly (/dev/mmcblk0p10) rather than by name (/dev/disk/by-partlabel/boot).
Thank you Daniel;
Without ramdisk the error I have is more repetable (I still have this weird fault: /lib/systemd/system-generators/systemd-gpt-auto-generator terminated by signal SEGV. )
Logs look like this and I still cannot have a full correct boot.
Will have a deeper look at my hardware today.
I tried a new emmc with 8GB (MTFC8GAKAJCN-1M-WT) but the problem is still there.
One difference between my board and dragonboard is the following logs:
On my board: mmcblk0boot0: mmc0:0001 Q2J55L partition 1 2.00 MiB
On dragonboard, mmcblk0boot0 and boot1 are 4 MiB.
Does that matter? I am not sure about the purpose of those mmcblk0boot0/1 partitions…
Thank you,
The boot partitions are separate hardware partititons within eMMC. They need a special protocol to access and are intended to make it easier to separate the bootloader from the OS.
I don’t think it matters much in since I don’t think the DB410C boot ROM uses them. However it does means that you will still need a custom partition table because your main eMMC partition will be 4MB “too big”.
Not sure what the best way to resize them is… Looks like there might be support in u-boot to allow it but I’ve never tried doing any changes to the boot partitions myself.
Thank you for your anwer.
This is interesting, as I see it it could be the source of all my troubles
Will have a deeper look in the next few days, thank you again !
For completeness, here are the exact differences between my board and dragonboard:
dragonboard:
mmcblk0boot0: partition 1 4.00 MiB
mmcblk0boot1: partition 2 4.00 MiB
mmcblk0rpmb: partition 3 4.00 MiB
my custom board:
mmcblk0boot0: partition 1 2.00 MiB
mmcblk0boot1: partition 2 2.00 MiB
mmcblk0rpmb: partition 3 512 KiB
So my guess is that this is the reason there are troubles during the boot.
Here are the different options I consider to solve the problem:
- Resize the boot partitions in the emmc
I am not even sure my specific memory allows that
or - Replace the emmc with another chip that has same footprint and boot partitions sizes
or - Customize the partition tables (gpt files) so that the shift in size is taken into account.
I intend to try the latest option that seems the easiest way to do it. But I am not sure if those boot partitions sizes are taken into account in the GPT or in the rawprogram.xml file … Otherwise I could have a deeper look deeper to u-boot to resize the partitions but I have no experience with it (yet).
Thank you for your help,
