- kernelnewbies@kernelnewbies.org - Kernelnewbies Mailing Lists

How can I use id and schema page of a yaml file in the devicetree bindings document?
by Chan Kim Nov. 2, 2021

Nov. 2, 2021

Hello all In the file Documentation/devicetree/bindings/arm/primecell.yaml, I see in the beginning, # SPDX-License-Identifier: GPL-2.0 %YAML 1.2 --- $id: http://devicetree.org/schemas/arm/primecell.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# title: ARM Primecell Peripherals following the link in the id and schema just leads me to https://www.devicetree.org/schema/# and it says "These are not the schemas you are looking for." How can I open the links and use them? Thanks a lot! Regards, Chan Kim

1 0

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

Any tracing mechanism can track the executed instructions of a user process in the kernel?
by Dongliang Mu Oct. 18, 2021

Oct. 18, 2021

Hi all, I am writing to kindly ask one question: is there any tracing mechanism in Linux kernel that can trace all the executed instructions of a user process? If this user process is run on different processors, traces of this process on different processors should be also recorded. Any comment is welcome. -- My best regards to you. No System Is Safe! Dongliang Mu

7 10