October 2021 - kernelnewbies@kernelnewbies.org

error: impossible constraint in 'asm' when compiling kernel code with -O0 option
by ckim＠etri.re.kr Jan. 19, 2022

Jan. 19, 2022

In linux-5.4.21 code, To prevent some variables from being 'optimized out' during kernel code analysis using gdb, I added in drivers/iommu/Makefile, (replacing -O2 flags to -O0 flags for some files, I found http://www.joelfernandes.org/linux/2018/06/10/kernel-gdb.html ) CFLAGS_REMOVE_arm-smmu.o := -O2 CFLAGS_REMOVE_arm-smmu-impl.o := -O2 CFLAGS_REMOVE_io-pgtable-arm-v7s.o := -O2 CFLAGS_REMOVE_io-pgtable-arm.o := -O2 CFLAGS_REMOVE_of_iommu.o := -O2 CFLAGS_REMOVE_arm-smmu-v3.o := -O2 CFLAGS_arm-smmu.o := -O0 CFLAGS_arm-smmu-impl.o := -O0 CFLAGS_io-pgtable-arm-v7s.o := -O0 CFLAGS_io-pgtable-arm.o := -O0 CFLAGS_of_iommu.o := -O0 CFLAGS_arm-smmu-v3.o := -O0 But when I do make ARCH=arm64 CROSS_COMPILE=aarch64-none-elf- Image, I get CALL scripts/checksyscalls.sh CALL scripts/atomic/check-atomics.sh CHK include/generated/compile.h CC drivers/iommu/io-pgtable-arm.o In file included from ././include/linux/compiler_types.h:68, from <command-line>: ./arch/arm64/include/asm/jump_label.h: In function 'system_uses_lse_atomics': ./include/linux/compiler-gcc.h:120:38: warning: asm operand 0 probably doesn't match constraints 120 | #define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0) | ^~~ ./arch/arm64/include/asm/jump_label.h:38:2: note: in expansion of macro 'asm_volatile_goto' 38 | asm_volatile_goto( | ^~~~~~~~~~~~~~~~~ ./include/linux/compiler-gcc.h:120:38: warning: asm operand 0 probably doesn't match constraints 120 | #define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0) | ^~~ ./arch/arm64/include/asm/jump_label.h:38:2: note: in expansion of macro 'asm_volatile_goto' 38 | asm_volatile_goto( | ^~~~~~~~~~~~~~~~~ ./include/linux/compiler-gcc.h:120:38: error: impossible constraint in 'asm' 120 | #define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0) | ^~~ ./arch/arm64/include/asm/jump_label.h:38:2: note: in expansion of macro 'asm_volatile_goto' 38 | asm_volatile_goto( | ^~~~~~~~~~~~~~~~~ ./include/linux/compiler-gcc.h:120:38: error: impossible constraint in 'asm' 120 | #define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0) | ^~~ ./arch/arm64/include/asm/jump_label.h:38:2: note: in expansion of macro 'asm_volatile_goto' 38 | asm_volatile_goto( | ^~~~~~~~~~~~~~~~~ make[2]: *** [scripts/Makefile.build:266: drivers/iommu/io-pgtable-arm.o] Error 1 make[1]: *** [scripts/Makefile.build:509: drivers/iommu] Error 2 make: *** [Makefile:1652: drivers] Error 2 Does anybody know how can I use -O0 flag? (I tried -Og flag but some variables are still optimized out). Thank you! Chan Kim

4 3

Re: MTD: How to get actual image size from MTD partition
by Pintu Agarwal Nov. 12, 2021

Nov. 12, 2021

On Thu, 29 Jul 2021 at 17:33, Ezequiel Garcia <ezequiel(a)vanguardiasur.com.ar> wrote: > > On Thu, 29 Jul 2021 at 08:45, Richard Weinberger <richard(a)nod.at> wrote: > > > > Ezequiel, > > > > ----- Ursprüngliche Mail ----- > > > [snip] > > > > > > Ouch, so surprised that after all these years someone is doing squashfs/mtdblock > > > instead of using ubiblock :-) > > > > > > Can we patch either Kconfig or add some warn_once on mtdblock > > > usage, suggesting to use ubiblock instead? > > > > a hint in Kconfig makes IMHO sense. Do you want to send a patch? > > A warning is too much since on some tiny embedded system with NOR flash mtdblock is still > > a good choice. > > ubiblock is mostly useful for NAND flash. > > > > > I remember there was still some use case(s) for mtdblock but I can't remember > > > now what was it, perhaps we should document the expectations? > > > (Is that for JFFS2 to mount?) > > > > a long time ago mount didn't accept character devices, so you had to pass mtdblockX to mount > > JFFS2. > > This limitation is gone. > > > > OK, let me try to cook a patch for you. > Dear Eze and Richard, First of all, thank you so much for all your replies so far. Sorry, I have limited knowledge about NAND, MTD, UBI layers, but my current work involves all these so I am here. But I will surely share this information to our internal team about using ubiblock instead of mtdblock. However, I still fail to understand the problem and consequences of using mtdblock for rootfs instead of ubiblock. Last time, for my squashfs test, when I tried to replace the command line with ubiblock, I could not see any difference. How to visibly see the difference so that I can easily understand and explain the difference internally? Or, is there a document available somewhere to highlight the difference between the two? BTW, we have few raw nand partitions and few ubi volumes [including rootfs(squashfs), data(ubifs, rw)] So, I guess we should use ubiblock for all ubi volumes? Regarding Kconfig, I have few opinions. Yes, adding more description in Kconfig is a good choice. But I see that most of the time these kernel config options remains (as default) and platform developers never cares about the description. So, how to better create awareness among them, not to make these mistakes? One option is to capture these details as part of Kernel documentation. Right now when I search I could not find anything. Another option is to add a few (critical) warnings in kernel bootup logs to give some hint to the developer that there is probably something wrong. This will directly be visible to all and some developers will not like to ignore it. Or, maybe adding both options is also good. Thanks, Pintu

2 7

Re: Kernel 4.14: Using dm-verity with squashfs rootfs - mounting issue
by Pintu Agarwal Oct. 29, 2021

Oct. 29, 2021

On Mon, 30 Aug 2021 at 22:25, Thomas Petazzoni <thomas.petazzoni(a)bootlin.com> wrote: > > Hello, > > On Mon, 30 Aug 2021 21:55:19 +0530 > Pintu Agarwal <pintu.ping(a)gmail.com> wrote: > > > Sorry for coming back to this again.. > > Unfortunately, none of the options is working for us with squashfs > > (bootloader, initramfs). > > initramfs have different kinds of challenges because of the partition > > size issue. > > So, our preferred option is still the bootloader command line approach.. > > > > Is there a proven and working solution of dm-verity with squashfs ? > > If yes, please share some references. > > > > The current problem with squashfs is that we could not append the > > verity-metadata to squashfs, so we store it on a separate volume and > > access it. > > Here, it definitely worked to append the hash tree to the squashfs > image and store them in the same partition. > > > By specifying it like : /dev/mtdblock53 > > > > Then we get the error like this: > > { > > [ 4.950276] device-mapper: init: attempting early device configuration. > > [ 4.957577] device-mapper: init: adding target '0 95384 verity 1 > > /dev/ubiblock0_0 /dev/mtdblock53 4096 4096 11923 8 sha256 > > 16da5e4bbc706e5d90511d2a3dae373b5d878f9aebd522cd614a4faaace6baa3 > > aee087a5be3b982978c923f566a94613496b417f2af592639bc80d141e34dfe7 10 > > restart_on_corruption ignore_zero_blocks use_fec_from_device > > /dev/mtdblock53 fec_roots 2 fec_blocks 12026 fec_start 12026' > > [ 4.975283] device-mapper: verity: sha256 using implementation > > "sha256-generic" > > [ 4.998728] device-mapper: init: dm-0 is ready > > Could you show the full kernel command line ? Shared below > > Do you see any other problem here with dm-verity cmdline or with squashfs ? > > > > Is squashfs ever proved to be working with dm-verity on higher kernel version ? > > Currently our kernel version is 4.14. > > I confirm we used squashfs on dm-verity successfully. For sure on 4.19, > perhaps on older kernels as well. ohh that means we already have a working reference. If possible can you share the details, even 4.19 or higher will be also a good reference. > > Or, another option is to use the new concept from 5.1 kernel that is: > > dm-mod.create = ? > How are you doing it today without dm-mod.create ? I think in 4.14 we don't have dm-mod.create right ? > Again, please give your complete kernel command line. > Here is our kernel command line: [ 0.000000] Kernel command line: ro rootwait console=ttyMSM0,115200,n8 .... verity="95384 11923 16da5e4bbc706e5d90511d2a3dae373b5d878f9aebd522cd614a4faaace6baa3 12026 " rootfstype=squashfs ubi.mtd=40,0,30 ubi.block=0,0 root=/dev/dm-0 .... init=/sbin/init root=/dev/dm-0 dm="rootfs none ro,0 95384 verity 1 /dev/ubiblock0_0 /dev/mtdblock53 4096 4096 11923 8 sha256 16da5e4bbc706e5d90511d2a3dae373b5d878f9aebd522cd614a4faaace6baa3 aee087a5be3b982978c923f566a94613496b417f2af592639bc80d141e34dfe7 10 restart_on_corruption ignore_zero_blocks use_fec_from_device /dev/mtdblock53 fec_roots 2 fec_blocks 12026 fec_start 12026" ... Do you see any issue here ? Can you share your command line for squashfs to compare ? Thank you, Pintu

3 6

DTC compile error (simple-bus unit address format error for #address-cells = <2> case)
by Chan Kim Oct. 27, 2021

Oct. 27, 2021

Hello all, Below is a part of arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi in linux kernel. This file is included by arch/arm64/boot/dts/arm/fvp-base-revc.dts. / { smb@8000000 { motherboard { arm,v2m-memory-map = "rs1"; compatible = "arm,vexpress,v2m-p1", "simple-bus"; #address-cells = <2>; /* SMB chipselect number and offset */ #size-cells = <1>; #interrupt-cells = <1>; ranges; flash@0,00000000 { compatible = "arm,vexpress-flash", "cfi-flash"; reg = <0 0x00000000 0x04000000>, <4 0x00000000 0x04000000>; bank-width = <4>; }; ethernet@2,02000000 { compatible = "smsc,lan91c111"; reg = <2 0x02000000 0x10000>; interrupts = <15>; }; When I compile the fvp-base-revc.dts file (following this method to handle pre-processing : https://stackoverflow.com/questions/50658326/device-tree-compiler-not-recogn izes-c-syntax-for-include-files), it gives me error below. arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi:20.21-25.6: Warning (simple_bus_reg): /smb@8000000/motherboard/flash@0,00000000: simple-bus unit address format error, expected "0" arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi:27.24-31.6: Warning (simple_bus_reg): /smb@8000000/motherboard/ethernet@2,02000000: simple-bus unit address format error, expected "202000000" The dtc is complaining about the address format `flash@0,00000000` or `ethernet@2,02000000`. But because the #address-cells = <2>, the node address should be given by chip select number and the offset (inside the chip select). How can I prevent this error? DTC version is 1.5.0. Any help will be appreciated. Thank you! Chan Kim

1 1

What does LOADADDR=0x20008000 mean in linux kernel make command? and what is kernel load address?
by Chan Kim Oct. 27, 2021

Oct. 27, 2021

Hello all, I'm learning u-boot these days and have a question. Using qemu model, I could (using qemu) load the "Image" (for arm64) on memory location I want and I could run the kernel booting using `booti ker_add initrd_addr dtb_addr` command. As you know in arm64, the uImage format is not supported. Then, when building linux kernel for arm (32 bit) using u-boot, what does "make LOADADDR=0x20008000 uImage" mean? Regardless of this LOADADDR, we can load (from SD card or network) the uImage anywhere we want using u-boot shell. Then what is this LOADADDR? Does it mean that when we run `bootm` command, the u-boot program relocates the kernel image inside the uImage to 0x20008000? (and the kernel built not using position independent, PC-relative addressing..using hard absolute addresses..) Some years ago, we used kernel start address during the build and I had to load the kernel image exactly on that address. But this time I could load 'Image' anywhere I want and could run it. Why? Is it because I (not knowingly) compiled the arm64 'Image' using position independent address(-PIE option)? If someone with expertise could explain to me what's happening here, I would really really appreciate it. Thank you. Best regards, Chan Kim

1 1

Re: Will two READ_ONCE()s in a row execute in order
by FMDF Oct. 25, 2021

Oct. 25, 2021

On Mon, 25 Oct 2021, 14:17 Zhang Zeren, <zhangzr23(a)gmail.com> wrote: > Thanks for your reply! I should have read more carefully... Besides, do > you know where can I find the specific rules of LKMM? > Once people used to say that this subject is good for "scaring little kids" (or something like that)... Introductory material can be found in the Linux kernel under the tools/memory-model/Documentation directory. For now, you'd better skip the files that are one level higher in tools/memory-model. IMO, best sources related to concurrency, ordering and memory model that I've ever read are Paul McKenney's papers and book (please use the Google search engine, Paul provides freely downloadable resources at his website). Regards, Fabio M. De Francesco

1 0

Will two READ_ONCE()s in a row execute in order
by Zhang Zeren Oct. 25, 2021

Oct. 25, 2021

Hi, I read an example in the Documentation/memory-barriers.txt, which says > > (*) On any given CPU, dependent memory accesses will be issued in order, with > respect to itself. This means that for: > > Q = READ_ONCE(P); D = READ_ONCE(*Q); > > the CPU will issue the following memory operations: > > Q = LOAD P, D = LOAD *Q > > and always in that order. However, on DEC Alpha, READ_ONCE() also > emits a memory-barrier instruction, so that a DEC Alpha CPU will > instead issue the following memory operations: > > Q = LOAD P, MEMORY_BARRIER, D = LOAD *Q, MEMORY_BARRIER > > As far as I understand it, linux kernel memory model (LKMM) guarantee two read operations execute in order. And if the CPU architecture offer an looser memory ordering (like Alpha), then the compiler must help to add a memory barrier after the load instruction to fufill the LKMM's standard. However i did a test using klitmus like this > P0(int *x, int *y) > { > WRITE_ONCE(*x, 1); > smp_wmb(); > WRITE_ONCE(*y, 1); > } > > P1(int *x, int *y) > { > int r0; > int r1; > > r0 = READ_ONCE(*y); > r1 = READ_ONCE(*x); > } > > exists (1:r0=1 /\ 1:r1=0) > I run this test in an aarch64 machine, and get the result > Histogram (4 states) > 1292209 :>1:r0=0; 1:r1=0; > 1585 *>1:r0=1; 1:r1=0; > 221437 :>1:r0=0; 1:r1=1; > 484769 :>1:r0=1; 1:r1=1; > Ok > > Witnesses > Positive: 1585, Negative: 1998415 > It seems that these two READ_ONCE()s can be executed in any order. But if I run this test in a x86 machine, which has a more strict memory model, result 1:r0=1; 1:r1=0; disappears. So the order depends on the memory model provided by the CPU architecture? Isn't this contradicted with memory-barrier.txt?

3 3

how is booting possible using kernel image in disk?..
by Chan Kim Oct. 21, 2021

Oct. 21, 2021

Hello, In my ubuntu 20.04 machine, ckim@ckim-ubuntu:~$ dmesg | grep 'Command' [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.11.0-36-generic root=UUID=5252b177-1243-4d3f-8a1a-ec7d0dcae011 ro quiet splash vt.handoff=7 ckim@ckim-ubuntu:~$ mount | grep boot /dev/sda2 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=iso8859-1,shortnam e=mixed,errors=remount-ro) The kernel image in /boot/ directory was used and the /boot directory is in /dev/sda2, a hard disk. I'm almost sure but is this possible because (my system used UEFI for booting, I can see /boot/efi/EFI/ directory) 1. the UEFI firmware has file system driver and could open the disk partition and used the kernel image to boot 2. the UEFI firmware detected the disk (using SCSI driver?) and edited the system hardware information (here maybe ACPI table) and passed it to linux kernel. Is my understanding correct? Thanks in advance. Regards, Chan Kim

1 0

is there a method to minize kernel size using menuconfig and minial driver?
by ckim＠etri.re.kr Oct. 21, 2021

Oct. 21, 2021

Hello list members, Is there a nice method to minimize the kernel Image size using 'make menuconfig'? I have to build a minimum linux Image supporting only interrupt controller, timer and uart.(for use in rtl simulation). (We are doing it for arm64) Any comment will be appreciated. Thanks! Chan Kim

3 2

How to mmap any address space using huge pages?
by Adam Turowski Oct. 21, 2021

Oct. 21, 2021

Hello all, I have a device and I need to mmap it into a user space using 1GB huge pages. AFAIK I cannot use HugeTLB nor THP because they're backed by the memory. The remap_pfn_range doesn't use huge pages neither. So I used a huge_fault handler to set up the pud descriptor myself (arm64 here, so no transparent puds) and that works. The problem is that the kernel warns about a bad pud when the vma mapping is removed, the zap_pud_range function doesn't accept block puds. The vunmap_pud_range function works with block puds and checks for their presence and calls the pud_clear_huge function. If I add this function call to the zap_pud_range function, the warnings are gone. Am I missing something? What is the proper way to mmap (and munmap) any address space using huge pages (esp. 1GB pages)? Thanks -- Regards, Adam Turowski

2 2