Bootloader with UFS support

Hello

I am using a Rootfs based on yocto project/OE. Instead of having the kernel as a partition I would prefer to have it on the root file system, easing the update. Therefore I need a bootloader that can fetch that file.

So far I have tried to use U-boot, but they do not seem to support UFS (and I could not find anyone working on that topic).

Has anyone experienced with a bootloader with UFS and ext3 capabilites? Or shall I just embrace Kexec? Or forget about this? :stuck_out_tongue:

Thanks!

AFAIK there is ongoing work to support u-boot (already supported with DB410C), though I don’t know the exact status, this is the way to have kernel loaded from rootfs.

As a workaround, I suggested a method to update bootimg kernel with the rootfs one: No HDMI after apt-get upgrade - #6 by Loic, this can be scripted (https://github.com/96boards/dt-update/pull/5/commits/1d3dd46cb05744029b3c13d4386a050643e21f0a).

The support for DB410c UFS is upstream? or in which repo?

DB410c support is in upstream uboot but DB410c does not have UFS… but eMMC/SDHCI.

DB820c has UFS, but there is no support , as you noticed, in uboot for UFS. While there was an initial uboot port for DB820c, it supports SD card only, and not UFS. we are not planning to add UFS support into uboot in the short term.

Yes, you can use mainline uboot for DB410C: git://git.denx.de/u-boot.git

git clone git://git.denx.de/u-boot.git
make dragonboard410c_config
make -j7
gzip u-boot-dtb.bin
cat u-boot-dtb.bin.gz u-boot.dtb > u-boot.gz+dtb
echo "not a ramdisk" > ramdisk.img
abootimg --create boot-db410c.img -k u-boot.gz+dtb -r ramdisk.img \
       -c pagesize=2048 -c kerneladdr=0x80008000 -c ramdiskaddr=0x81000000
fastboot flash boot boot-db410c.img

Any demo/early access available for this?

On a side note. Kexec seems to fail, so no petitboot for me :frowning:

kexec --dtb=/mnt/boot/kk.dtb   --command-line="root=/dev/sda9 rw rootwait co
nsole=ttyMSM0,115200n8 androidboot.bootdevice=624000.ufshc androidboot.serialno=
14d2a437 androidboot.baseband=apq mdss_mdp.panel=0  earlyprintk earlycon=msm_ser
ial_dm,0x75b0000 debug ignore_loglevel ftrace=function ftrace_dump_on_oops" --de
bug --ramdisk=/mnt/boot/initrd -e
arch_process_options:148: command_line: root=/dev/sda9 rw rootwait console=ttyMSM0,115200n8 androidboot.bootdevice=624000.ufshc androidboot.serialno=14d2a437 androidboot.baseband=apq mdss_mdp.panel=0  earlyprintk earlycon=msm_serial_dm,0x75b0000 debug igno[   31.956266] sd 0:0:0:5: [sdf] Synchronizing SCSI cache
re_loglevel ftrace=function ftrace_dump_on_oops
arch_process_op[   31.966427] sd 0:0:0:4: [sde] Synchronizing SCSI cache
[   31.972596] sd 0:0:0:3: [sdd] Synchronizing SCSI cache
[   31.977724] sd 0:0:0:2: [sdc] Synchronizing SCSI cache
[   31.982961] sd 0:0:0:1: [sdb] Synchronizing SCSI cache
[   31.987957] sd 0:0:0:0: [sda] Synchronizing SCSI cache
tions:150: initrd: /mnt/boot/initrd
arch_process_options:151: dtb: /mnt/boot/kk.dtb
[   32.012577] kexec_core: Starting new kernel
[   32.012603] Disabling non-boot CPUs ...
[   32.062641] CPU1: shutdown
[   32.062718] psci: CPU1 killed.
[   32.106596] CPU2: shutdown
[   32.106698] psci: CPU2 killed.
[   32.160217] CPU3: shutdown
[   32.160299] psci: CPU3 killed.
[   32.168974] Bye!
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.14.53-qtec-linaro (oe-user@oe-host) (gcc version 7.3.0 (GCC)) #1 SMP PREEMPT Thu Aug 2 13:45:35 UTC 2018
[    0.000000] Boot CPU: AArch64 Processor [511f2112]
[    0.000000] Machine model: Qtechnology QT5506
[    0.000000] earlycon: msm_serial_dm0 at MMIO 0x00000000075b0000 (options '')
[    0.000000] bootconsole [msm_serial_dm0] enabled
[    0.000000] debug: ignoring loglevel setting.
[    0.000000] efi: Getting EFI parameters from FDT:
[    0.000000] efi: UEFI not found.
[    0.000000] Reserved memory: created DMA memory pool at 0x0000000090b00000, size 10 MiB
[    0.000000] OF: reserved mem: initialized node gpu@8f200000, compatible id shared-dma-pool
[    0.000000] cma: Reserved 16 MiB at 0x00000000ff000000
[    0.000000] NUMA: No NUMA configuration found
[    0.000000] NUMA: Faking a node at [mem 0x0000000000000000-0x000000013ea4ffff]
[    0.000000] NUMA: NODE_DATA [mem 0x13e9e6600-0x13e9e80ff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000080000000-0x00000000ffffffff]
[    0.000000]   Normal   [mem 0x0000000100000000-0x000000013ea4ffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000080000000-0x00000000857fffff]
[    0.000000]   node   0: [mem 0x0000000091700000-0x00000000a1dfffff]
[    0.000000]   node   0: [mem 0x00000000a2000000-0x000000013ea4ffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000080000000-0x000000013ea4ffff]
[    0.000000] On node 0 totalpages: 731472
[    0.000000]   DMA zone: 7420 pages used for memmap
[    0.000000]   DMA zone: 0 pages reserved
[    0.000000]   DMA zone: 474880 pages, LIFO batch:31
[    0.000000]   Normal zone: 4010 pages used for memmap
[    0.000000]   Normal zone: 256592 pages, LIFO batch:31
[    0.000000] psci: probing for conduit method from DT.
[    0.000000] psci: PSCIv1.0 detected in firmware.
[    0.000000] psci: Using standard PSCI v0.2 function IDs
[    0.000000] psci: MIGRATE_INFO_TYPE not supported.
[    0.000000] psci: SMC Calling Convention v1.0
[    0.000000] percpu: Embedded 24 pages/cpu @ffff8000be981000 s59800 r8192 d30312 u98304
[    0.000000] pcpu-alloc: s59800 r8192 d30312 u98304 alloc=24*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 
[    0.000000] Detected PIPT I-cache on CPU0
[    0.000000] CPU features: enabling workaround for Qualcomm Technologies Kryo erratum 1003
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 720042
[    0.000000] Policy zone: Normal
[    0.000000] Kernel command line: root=/dev/sda9 rw rootwait console=ttyMSM0,115200n8 androidboot.bootdevice=624000.ufshc androidboot.serialno=14d2a437 androidboot.baseband=apq mdss_mdp.panel=0  earlyprintk earlycon=msm_serial_dm,0x75b0000 debug ignore_loglevel ftrace=function ftrace_dump_on_oops
[    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    0.000000] software IO TLB [mem 0xfafff000-0xfefff000] (64MB) mapped at [ffff80007afff000-ffff80007effefff]
[    0.000000] Memory: 2772832K/2925888K available (11452K kernel code, 2068K rwdata, 5320K rodata, 1280K init, 434K bss, 136672K reserved, 16384K cma-reserved)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     modules : 0xffff000000000000 - 0xffff000008000000   (   128 MB)
[    0.000000]     vmalloc : 0xffff000008000000 - 0xffff7dffbfff0000   (129022 GB)
[    0.000000]       .text : 0xffff000008080000 - 0xffff000008bb0000   ( 11456 KB)
[    0.000000]     .rodata : 0xffff000008bb0000 - 0xffff0000090f0000   (  5376 KB)
[    0.000000]       .init : 0xffff0000090f0000 - 0xffff000009230000   (  1280 KB)
[    0.000000]       .data : 0xffff000009230000 - 0xffff000009435200   (  2069 KB)
[    0.000000]        .bss : 0xffff000009435200 - 0xffff0000094a1d80   (   435 KB)
[    0.000000]     fixed   : 0xffff7dfffe7f9000 - 0xffff7dfffec00000   (  4124 KB)
[    0.000000]     PCI I/O : 0xffff7dfffee00000 - 0xffff7dffffe00000   (    16 MB)
[    0.000000]     vmemmap : 0xffff7e0000000000 - 0xffff800000000000   (  2048 GB maximum)
[    0.000000]               0xffff7e0000000000 - 0xffff7e0002fa9400   (    47 MB actual)
[    0.000000]     memory  : 0xffff800000000000 - 0xffff8000bea50000   (  3050 MB)
[    0.000000] SLUB: HWalign=128, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[    0.000000] Preemptible hierarchical RCU implementation.
[    0.000000] 	RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=4.
[    0.000000] 	Tasks RCU enabled.
[    0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
[    0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
[    0.000000] GICv3: VLPI support, no direct LPI support
[    0.000000] GICv3: CPU0: found redistributor 0 region 0:0x0000000009c00000
[    0.000000] GICv2m: range[mem 0x09bd0000-0x09bd0fff], SPI[544:639]
[    0.000000] arch_timer: cp15 and mmio timer(s) running at 19.20MHz (virt/virt).
[    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns
[    0.000008] sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every 4398046511078ns
[    0.011063] Console: colour dummy device 80x25
[    0.018834] Calibrating delay loop (skipped), value calculated using timer frequency.. 38.40 BogoMIPS (lpj=76800)
[    0.023288] pid_max: default: 32768 minimum: 301
[    0.033731] Security Framework initialized
[    0.039883] Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
[    0.042990] Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
[    0.049464] Mount-cache hash table entries: 8192 (order: 4, 65536 bytes)
[    0.056642] Mountpoint-cache hash table entries: 8192 (order: 4, 65536 bytes)
[    0.079477] ASID allocator initialised with 32768 entries
[    0.087474] Hierarchical SRCU implementation.
[    0.100919] EFI services will not be available.
[    0.107654] smp: Bringing up secondary CPUs ...

Format: Log Type - Time(microsec) - Message - Optional Info
Log Type: B - Since Boot(Power On Reset),  D - Delta,  S - Statistic
S - QC_IMAGE_VERSION_STRING=BOOT.XF.1.0-00306
S - IMAGE_VARIANT_STRING=M8996LAB
S - OEM_IMAGE_VERSION_STRING=crm-ubuntu39

Hi Nicolas,

Is there any update on supporting UFS in u-boot (and for the db820c)?

Thanks!

hey,

there isn’t any work from our side. However I have seen UFS support patches on uboot mailing list:
https://www.mail-archive.com/u-boot@lists.denx.de/msg340337.html

Though I don’t know the exact status of these patches. But that would be the first step to get Uboot support on 820c.

Thanks for the quick response.

I’ve checked that the guy working on the UFS has a second patch version:
https://patchwork.ozlabs.org/project/uboot/list/?submitter=72140

ah, ok. that’s good. At least it’s moving forward.
Would you consider giving it a try on 820c? it is probably not straight forward , i have to say… but i don’t expect any of us to look into that any time soon otherwise.

Yes! We will consider giving a try for our next release once the patches for UFS support are merged. So, I will follow these patches series.