June 2023 - kernelnewbies@kernelnewbies.org - Kernelnewbies Mailing Lists

Source code organization
by Billie Alsup (balsup) April 23, 2024

April 23, 2024

I have a set of drivers that I would like to upstream. These are primarily MFD style drivers supporting Cisco-8000 FPGAs. The devices can be instantiated through multiple top level drivers, which provide the access mechanism for the MFD driver. For example, an FPGA can be accessed via PCI, or via i2c, or via SLPC, or via P2PM (a point-to-point interface). We currently build these drivers out of tree, under a single directory drivers/cisco. I note that existing drivers are spread out across the kernel tree, sometimes by bus (pci, i2c), sometimes by function (gpio, net/mdio, spi), and sometimes under the generic mfd. I would like to start the upstream review process for our drivers, but first want to get recommendations on the source code layout. Is it permissible to keep a top level directory such as drivers/cisco to organize our code? It is not only the source code that is affected, but also provides a central place for Kconfig entries. Our FPGAs have multiple logical blocks, each of which is handled by a different MFD driver, e.g. i2c controllers, gpio controllers, spi controllers, mdio controllers. There can be multiple instances of each block as well (so multiple MFD devices are instantiated for each driver). And of course, there can be multiple FPGAs in a system, each with different combinations of logical blocks. The drivers themselves are pretty specific to our FPGAs, thus it makes sense to use Kconfig to select a hardware platform to automatically select the set of MFD drivers (and top level bus drivers) that would apply. Would a source layout putting all the code under drivers/cisco be acceptable in this case, or do I need to move things around and spread out the Kconfig entries across directories? I note that a single drivers/cisco would simplify any related modifications to MAINTAINERS as well.

2 5

CONFLICT (content): Merge conflict in scripts/kconfig/Makefile
by Mario Marietto July 6, 2023

July 6, 2023

Hello. I'm trying to enable KVM virtualization on the Arm Chromebook using KVM-tool. This is the tutorial where I'm reading how to do that : https://community.arm.com/arm-community-blogs/b/architectures-and-processor… Below you can see what I did and the error that I've got : /home/marietto/Scrivania/Chromebook# git clone https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Cloning into 'linux-stable'... remote: Enumerating objects: 11487511, done. remote: Counting objects: 100% (3953/3953), done. remote: Compressing objects: 100% (2263/2263), done. remote: Total 11487511 (delta 2912), reused 2100 (delta 1686), pack-reused 11483558 Ricezione degli oggetti: 100% (11487511/11487511), 4.47 GiB | 6.32 MiB/s, done. Risoluzione dei delta: 100% (9170170/9170170), done. Checking out files: 100% (80340/80340), done. /home/marietto/Scrivania/Chromebook# cd linux-stable /home/marietto/Scrivania/Chromebook/linux-stable# git checkout Your branch is up to date with 'origin/master'. /home/marietto/Scrivania/Chromebook/linux-stable# git checkout origin/linux-5.4.y -b linux-5.4.y Checking out files: 100% (72207/72207), done. Branch 'linux-5.4.y' set up to track remote branch 'linux-5.4.y' from 'origin'. Switched to a new branch 'linux-5.4.y' /home/marietto/Scrivania/Chromebook/linux-stable# git remote add kvm-tool https://github.com/penberg/linux-kvm.git /home/marietto/Scrivania/Chromebook/linux-stable# git remote update Fetching origin Fetching kvm-tool remote: Enumerating objects: 11257, done. remote: Counting objects: 100% (676/676), done. remote: Total 11257 (delta 675), reused 675 (delta 675), pack-reused 10581 Ricezione degli oggetti: 100% (11257/11257), 2.57 MiB | 8.98 MiB/s, done. Risoluzione dei delta: 100% (7441/7441), completed with 36 local objects. Da https://github.com/penberg/linux-kvm * [nuovo branch] master -> kvm-tool/master * [nuovo branch] vga/core -> kvm-tool/vga/core /home/marietto/Scrivania/Chromebook/linux-stable# git merge kvm-tool/master Auto-merging scripts/kconfig/Makefile CONFLICT (content): Merge conflict in scripts/kconfig/Makefile Auto-merging arch/x86/Kconfig Auto-merging MAINTAINERS CONFLICT (content): Merge conflict in MAINTAINERS warning: inexact rename detection was skipped due to too many files. warning: you may want to set your merge.renamelimit variable to at least 30049 and retry the command. Automatic Merge failed; fix the conflicts and run the commit of the result. # git merge kvm-tool/master error: Merging is not possible because you have unmerged files. hint: Fix them up in the work tree, and then use 'git add/rm <file>' hint: as appropriate to mark resolution and make a commit. fatal: Exiting because of an unresolved conflict. this is the conflict I see inside the Makefile : <<<<<<< HEAD PHONY += xconfig gconfig menuconfig config localmodconfig localyesconfig build_menuconfig build_nconfig build_gconfig build_xconfig PHONY += oldconfig xconfig gconfig menuconfig config silentoldconfig update-po-config localmodconfig localyesconfig kvmconfig >>>>>>> kvm-tool/master Is there a chance to fix it ? thanks -- Mario.

2 1

Kernel module for a network interface - remove trailer from sk_buff on reception
by Abhiram V July 1, 2023

July 1, 2023

I am implementing the Parallel Redundancy Protocol (PRP, IEC standard 62439-3) as a kernel module for a school project of mine. The code for the module can be found at: https://github.com/ramv33/prp. I have used the code for the HSR module which implements PRP as a reference for my implementation since I have zero prior experience with kernel programming. Even though a lot of the design is different, I have used the module as a reference for what to do and how to do it. Let me provide a brief description of what PRP is and what it does. PRP is used to provide hitless redundancy (zero recovery time). It does this by having two parallel and independent Ethernet networks. A device is connected to both these networks (LAN_A and LAN_B). Whenever a frame is sent by the device, it duplicates the frame and appends a trailer (Redundancy Control Trailer - RCT) which contains a sequence number, LAN_Id (LAN_A=0xA or LAN_B=0xB) and an LSDU_size (Link Service Data Unit, i.e, Ethernet payload size minus the RCT), and a PRP_Suffix (0x88FB) for a total of 6 octets. On reception, the sequence number is used to detect and discard the duplicates, removes the RCT, and forwards the frames to the upper layers for processing. The duplication on transmission, discarding and removal of RCT on reception is done by the kernel module which acts as the Link Redundancy Entity (LRE) as specified in the standard. The LRE is implemented as a virtual network interface using a kernel module. The transmission is done by defining the ndo_start_xmit function in the netdev_ops structure of my net_device. The *problem* I have is on reception, specifically with the *removal of the RCT*. The receive handler is registered on device creation using netdev_rx_handler_register and netdev_upper_dev_link. The receive handler when it detects that the RCT is well-formed (correct PRP_Suffix, LSDU_size, LAN_ID for the NIC through which it was received), tries to strip the RCT before calling netif_rx() on the skb to forward it to the upper layers for processing. To strip the RCT, I call *skb_trim* as follows: skb_trim(skb, skb->len - PRP_RCTLEN /* 6 */); as given in the HSR module. I have used skb_dump both before and after the call to skb_trim and verified that the length is being reduced and that the tailroom is increased by 6 bytes. The problem is that when I call skb_trim, the packet is not received by the upper layers. Without calling skb_trim, the packet is received correctly but the RCT is consumed by the applications which should not be the case. I used wireshark to inspect the frames at both the sender and the receiver side on the two physical devices and observed the following: 1. At the receiver side - The IP payload length is different for the same frame received through LAN_A and LAN_B. The one received through LAN_B has a payload length 6 greater than that for LAN_A (*6 is the size of the RCT*). On checking the ip_rcv_core function, invalid IP payload length is one reason that the packet can be dropped. 2. At the sender side - The entire packet is the same minus the RCT's LAN_ID field for a frame-pair. The IP payload length is correct when I capture outgoing frames on the two physical devices. As mentioned at the top, the code is available at: https://github.com/ramv33/prp. Here is a brief overview of the code 1. The transmission is defined in *prp_tx.c* in *prp_send_skb* which is called by *prp_dev_xmit* function defined in *prp_dev.c* 2. The code that sets up the two slave devices to forward frames received to the virtual interface is defined in *prp_dev.c* in the function *prp_port_setup*. It is called by *prp_add_ports*, which is called by *prp_dev_finalize* which is called by the RTNL newlnk callback, 3. The receive handler that is defined in *prp_rx.c, *the function is *prp_recv_frame.* It checks if the frame has a valid RCT, duplicates discards, and then strips the RCT by calling *strip_rct *before calling *prp_net_if* which removes the Ethernet header and calls *netif_rx* Hope you can help me find a solution to the removal of the RCT. Point out any mistakes that I am making. Thank you in advance :)

3 5

How is 'addr_space' filled in the pcie endpoint controller device tree node?
by Chan Kim June 21, 2023

June 21, 2023

Hello linux experts and users, When I analyze https://elixir.bootlin.com/linux/v5.15.68/source/drivers/pci/controller/dwc/ pcie-designware-ep.c#L777, The struct dw_pcie_ep contains a member msi_mem and the driver generates msi interrupt by writing the given data at that address. (see line 533 of the dw_pcie_ep_raise_msi_irq function) So that address (ep->msi_mem) is the host address (probably GICV3's ITS's GITS_TRANSLATER register address) that the host has told the endpoint. But when I trace the code how the msi_mem (virtual address) is decided, I see (in processing order in the dw_pcie_ep_init function) : res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "addr_space"); ep->phys_base = res->start; ep->addr_size = resource_size(res); ret = pci_epc_mem_init(epc, ep->phys_base, ep->addr_size, ep->page_size); ep->msi_mem = pci_epc_mem_alloc_addr(epc, &ep->msi_mem_phys, epc->mem->window.page_size); the allocate function allocates some port of the "addr_space" range and returns the virtual address (and fills the second argument with physical address). Then is this 'addr_space' filled by the boot loader? How can I know the host's ITS register range seen from the endpoint? (I mean the host PCI bridge will have a translation function that converts upstream PCI address --> host CPU's physical address, or IO virtual address if the host uses IOMMU betwen the PCIe and ITS). Any comment will be really appreciated. Thank you! Chan Kim

1 0

PCie card information for ACPI and Device Tree systems
by Lucas Tanure June 17, 2023

June 17, 2023

Hi, How can the kernel read hardware information for a PCIe card if ACPI in the BIOS doesn't have it? The DSDT/ACPI information doesn't contain information about an external PCIe inserted in the motherboard, so how can the Kenerl discover its hardware information? If the kernel has the rule of not hardcoding hardware information in its driver, what is the method to get hardware information for a PCIe not part of the motherboard? And the same question for ARM device trees. How can the driver find hardware information about a PCIe card that is not in the loaded DTB for the system? Thanks Lucas

2 1

Re: [jimc:dd-fix-2g] BUILD REGRESSION 664531695395972a1684dbc3604731db280b479e
by jim.cromie＠gmail.com June 14, 2023

June 14, 2023

Trouble with __UNIQUE_ID Im getting an error which "shouldnt be possible", but is happening anyway. On Mon, Jun 12, 2023 at 2:55 PM kernel test robot <lkp(a)intel.com> wrote: > > tree/branch: https://github.com/jimc/linux.git dd-fix-2g > branch HEAD: 664531695395972a1684dbc3604731db280b479e drm-drivers: DRM_CLASSMAP_USE in 2nd batch of drivers, helpers > > Error/Warning: (recently discovered and may have been fixed) > > hppa-linux-ld: drivers/gpu/drm/nouveau/nouveau_drm.o:(__dyndbg_class_users+0x0): multiple definition of `__UNIQUE_ID_ddebug_class_user323'; drivers/gpu/drm/radeon/radeon_drv.o:(__dyndbg_class_users+0x0): first defined here > include/drm/drm_print.h:421:9: error: implicit declaration of function '_dynamic_func_call_cls' [-Werror=implicit-function-declaration] > riscv64-linux-ld: drivers/gpu/drm/gud/gud_drv.o:(__dyndbg_class_users+0x0): multiple definition of `__UNIQUE_ID_ddebug_class_user305'; drivers/gpu/drm/qxl/qxl_drv.o:(__dyndbg_class_users+0x0): first defined here > riscv64-linux-ld: drivers/gpu/drm/nouveau/nouveau_drm.o:(__dyndbg_class_users+0x0): multiple definition of `__UNIQUE_ID_ddebug_class_user374'; drivers/gpu/drm/radeon/radeon_drv.o:(__dyndbg_class_users+0x0): first defined here > > Error/Warning ids grouped by kconfigs: > > gcc_recent_errors > |-- parisc-allyesconfig > | `-- multiple-definition-of-__UNIQUE_ID_ddebug_class_user323-drivers-gpu-drm-radeon-radeon_drv.o:(__dyndbg_class_users):first-defined-here > |-- riscv-allyesconfig > | |-- multiple-definition-of-__UNIQUE_ID_ddebug_class_user305-drivers-gpu-drm-qxl-qxl_drv.o:(__dyndbg_class_users):first-defined-here > | `-- multiple-definition-of-__UNIQUE_ID_ddebug_class_user374-drivers-gpu-drm-radeon-radeon_drv.o:(__dyndbg_class_users):first-defined-here > `-- x86_64-randconfig-a015-20230612 > `-- include-drm-drm_print.h:error:implicit-declaration-of-function-_dynamic_func_call_cls > > elapsed time: 756m > > configs tested: 101 > configs skipped: 6 > > tested configs: > alpha allyesconfig gcc > alpha defconfig gcc > alpha randconfig-r022-20230612 gcc > arc allyesconfig gcc > arc defconfig gcc > arc randconfig-r015-20230612 gcc > arc randconfig-r043-20230612 gcc > arm allmodconfig gcc > arm allyesconfig gcc > arm defconfig gcc > arm randconfig-r046-20230612 clang > arm64 allyesconfig gcc > arm64 defconfig gcc > csky defconfig gcc > hexagon randconfig-r041-20230612 clang > hexagon randconfig-r045-20230612 clang > i386 allyesconfig gcc > i386 buildonly-randconfig-r006-20230612 clang > i386 debian-10.3 gcc > i386 defconfig gcc > i386 randconfig-i001-20230612 clang > i386 randconfig-i002-20230612 clang > i386 randconfig-i003-20230612 clang > i386 randconfig-i004-20230612 clang > i386 randconfig-i005-20230612 clang > i386 randconfig-i006-20230612 clang > i386 randconfig-i011-20230612 gcc > i386 randconfig-i012-20230612 gcc > i386 randconfig-i013-20230612 gcc > i386 randconfig-i014-20230612 gcc > i386 randconfig-i015-20230612 gcc > i386 randconfig-i016-20230612 gcc > i386 randconfig-r012-20230612 gcc > i386 randconfig-r014-20230612 gcc > i386 randconfig-r035-20230612 clang > loongarch allmodconfig gcc > loongarch allnoconfig gcc > loongarch buildonly-randconfig-r001-20230612 gcc > loongarch defconfig gcc > m68k allmodconfig gcc > m68k allyesconfig gcc > m68k buildonly-randconfig-r004-20230612 gcc > m68k defconfig gcc > mips allmodconfig gcc > mips allyesconfig gcc > mips randconfig-r001-20230612 gcc > mips randconfig-r011-20230612 clang > mips randconfig-r021-20230612 clang > nios2 defconfig gcc > nios2 randconfig-r032-20230612 gcc > openrisc randconfig-r013-20230612 gcc > openrisc randconfig-r024-20230612 gcc > parisc allyesconfig gcc > parisc defconfig gcc > parisc randconfig-r004-20230612 gcc > parisc64 defconfig gcc > powerpc allmodconfig gcc > powerpc allnoconfig gcc > powerpc buildonly-randconfig-r003-20230612 gcc > powerpc buildonly-randconfig-r005-20230612 gcc > riscv allmodconfig gcc > riscv allnoconfig gcc > riscv allyesconfig gcc > riscv defconfig gcc > riscv randconfig-r003-20230612 clang > riscv randconfig-r042-20230612 gcc > riscv rv32_defconfig gcc > s390 allmodconfig gcc > s390 allyesconfig gcc > s390 defconfig gcc > s390 randconfig-r016-20230612 gcc > s390 randconfig-r025-20230612 gcc > s390 randconfig-r033-20230612 clang > s390 randconfig-r044-20230612 gcc > sh allmodconfig gcc > sh randconfig-r002-20230612 gcc > sh randconfig-r031-20230612 gcc > sh randconfig-r036-20230612 gcc > sparc allyesconfig gcc > sparc defconfig gcc > um i386_defconfig gcc > um x86_64_defconfig gcc > x86_64 allyesconfig gcc > x86_64 buildonly-randconfig-r002-20230612 clang > x86_64 defconfig gcc > x86_64 kexec gcc > x86_64 randconfig-a001-20230612 clang > x86_64 randconfig-a002-20230612 clang > x86_64 randconfig-a003-20230612 clang > x86_64 randconfig-a004-20230612 clang > x86_64 randconfig-a005-20230612 clang > x86_64 randconfig-a006-20230612 clang > x86_64 randconfig-a011-20230612 gcc > x86_64 randconfig-a012-20230612 gcc > x86_64 randconfig-a013-20230612 gcc > x86_64 randconfig-a014-20230612 gcc > x86_64 randconfig-a015-20230612 gcc > x86_64 randconfig-a016-20230612 gcc > x86_64 randconfig-r005-20230612 clang > x86_64 rhel-8.3-rust clang > x86_64 rhel-8.3 gcc > > -- > 0-DAY CI Kernel Test Service > https://github.com/intel/lkp-tests/wiki the source of the error is this: /** * DYNDBG_CLASSMAP_USE - refer to a classmap, DEFINEd elsewhere. * @_var: name of the exported classmap var * * This registers a module's use of another module's classmap defn, so * dyndbg can authorize "class DRM_CORE ..." >control commands upon * this module. */ #define DYNDBG_CLASSMAP_USE(_var) \ DYNDBG_CLASSMAP_USE_(_var, __UNIQUE_ID(ddebug_class_user)) #define DYNDBG_CLASSMAP_USE_(_var, _uname) \ extern struct ddebug_class_map _var; \ struct ddebug_class_user __used \ __section("__dyndbg_class_users") _uname = { \ .user_mod_name = KBUILD_MODNAME, \ .map = &_var, \ } I have reproduced this locally, with various errors, depending upon config and make.cross args heres one example: AR vmlinux.a LD vmlinux.o ld: ld: DWARF error: could not find abbrev number 7629 drivers/gpu/drm/gud/gud_drv.o:(__dyndbg_class_users+0x0): multiple definition of `__UNIQUE_ID_ddebug_class_user303'; ld: DWARF error: could not find abbrev number 94 drivers/gpu/drm/qxl/qxl_drv.o:(__dyndbg_class_users+0x0): first defined here make[1]: *** [/home/jimc/projects/lx/wk-suren/scripts/Makefile.vmlinux_o:61: vmlinux.o] Error 1 make: *** [/home/jimc/projects/lx/wk-suren/Makefile:1231: vmlinux_o] Error 2 [jimc@frodo rand-046-clang]$ grep -E 'QXL|GUD' .config CONFIG_DRM_QXL=y CONFIG_DRM_GUD=y searching that error gives results suggesting an LTO linker error, but some of the hits are quite old. note- despite the path, this is not a clang error - I get a different message (but still an error) when using make.cross COMPILER=clang is there something subtle (or obvious) wrong with my macro ?

1 1

Watching for new files/symlinks/devices in sysfs (possible? which syscall?)
by Richard June 13, 2023

June 13, 2023

Hi, is there a possibility, in sysfs, to watch for new symlinks (i.e. devices) beeing added to /sys/bus/usb/devices (like with inotify for normal directories)? I know you can use select() (userspace) and sysfs_notify() (kernelspace) for attributes , but is there something for folders and new devices (or symlinks)? Thanks, -- Richard

1 1

Better way to upstream a single-board computer?
by Lucas Tanure June 13, 2023

June 13, 2023

Hi, I have been trying to port Vim4 to Mainline for the past few weeks. Downstream branch: https://github.com/khadas/linux/tree/khadas-vims-5.4.y - First approach: The compatible string way In that 5.4 branches, clean the device tree to the bare minimum to have a serial console, sd-card mount and ethernet, and reduce the kernel config to only build the necessary modules. With those 2 in hand (minimum dts and config), I could port the necessary drivers for which the dts have compatible strings. I did manage to boot once a v6.3 kernel with that dts and config. But it would hang a few seconds after booting the kernel. And after a few days of trying to debug the problem without success, I decided to move to another approach. - Second approach: The fat patch I compared a clean 5.4 branch and khadas 5.4 branch and generated a big fat patch with around 2.5 million lines, where when applied to clean 5.4, it would boot and work. I started to chop the fat patch to remove stuff that did not need to get vim4 working with only serial, ethernet and sd-card. I managed to reduce to 1.3 million lines the fat patch, but after that, things started to hang and crash, so I was unable to move on. At this point, I realized that 5.4 khadas was actually an Android12-5.4 branch with amlogic and khadas stuff. - Thrid approch: The android fat patch I am doing the same thing as the second approach but using an android12-5.4-lts branch as the start, where the comparison shows me only the amlogic and khadas changes made. I am still going through this method, but it is promising. Right now, I have the fat patch with 0.9 million lines. My idea here is that when that fat patch becomes small enough, I can apply it to a clean 5.4 (no Android) to work it out more. And when that patch becomes something tinny, I could apply it on mainline, adjusting for the kernel version jump. - Fourth approach: The rebase way (On hold) I could compare the android12-5.4-lts git log with the khandas-5.4 log and start to cherry-pick patches to a clean 5.4 (no Android), but from experience, I think that's going to take forever, and it would be very hard to apply patches as they refer to an Android branch, not mainline. The intermediate goal is to have a patch on top of the mainline that boots vim4, no matter how ugly. With that in hand, I can start re-structuring and getting ready for upstream. Now my question for the community: Is there a better way to port a board to the mainline when you only have an old kernel that boots? Thanks Lucas Tanure

1 0

RE: Running u-boot and linux on qemu arm64 virt machine, linux shell does not respond.. ==> solved!
by Chan Kim June 5, 2023

June 5, 2023

Hi, all, I found what the problem was and fixed it. In u-boot(v2022.07), I modified arch/arm/Kconfig and made CONFIG_GICV3 selected by CONFIG_ARCH_QEMU. And then in qemu_arm64_defconfig, added CONFIG_BOOTCOMMAND="booti 0x40400000 0x44000000 0x40000000" (this automatic boot, with my qemu command) I also had to add in include/configs/qemu-arm.h, #define GICD_BASE 0x8000000 #define GICR_BASE 0x80a0000 I think this is the only things I added to the u-boot code. (I removed GICR power-up code in my previous email, that wasn't necessary) Hope this helps someone later. Thank you! Chan Kim From: Chan Kim <ckim(a)etri.re.kr> Sent: Friday, June 2, 2023 6:28 PM To: U-Boot Mailing List <u-boot(a)lists.denx.de>; 'qemu-discuss(a)nongnu.org' <qemu-discuss(a)nongnu.org>; kernelnewbies(a)kernelnewbies.org Subject: Running u-boot and linux on qemu arm64 virt machine, linux shell does not respond.. Hello all, I'm trying to run u-boot and linux on qemu arm64 virt machine preferably without changing any source code. (u-boot v2022.07, linux 5.15.68, qemu 6.2.0, busybox 1.32.1) I have built u-boot using qemu_arm64_defconfig and I got u-boot(elf) and u-boot.bin. I built linux using defconfig but later I removed many CONFIG_* to reduce compile time and got Image(binary). Also, I built busybox and made ramdisk. Now this is the qemu command I used. (I referenced u-boot's include/configs/qemu-arm.h to determine the load addresses, set CONFIG_BOOTCOMMAND=" booti 0x40400000 0x44000000 0x40000000") ../temp/qemu-6.2.0/build/aarch64-softmmu/qemu-system-aarch64 -machine virt,gic-version=max,secure=on,virtualization=true -cpu max -m 4G -nographic -bios u-boot/u-boot.bin -device loader,file=../temp/linux-5.15.68/arch/arm64/boot/Image,addr=0x40400000 -device loader,file=initrd.img,addr=0x44000000 u-boot runs and automatically boots linunx and it boots OK to the shell prompt. But at the linux shell prompt, it doesn't respond to my keyboard input. It looks like the symptom I saw last year when system counter is not working(for real board only). (I added system counter device in our qemu virtual machine just to not cause panic during the system counter access with the same driver. The qemu machine for our board runs ok using u-boot-spl and linux after booting including shell program and simple driver test. I'm trying to use u-boot proper now). Also last year I had to power-on the GICR(for virtual machine and real board). So I tried adding the code to power up GICR but it is the same. (this part is missing in u-boot, but I saw it is in the arm-tf S/W). For your reference this is the change in u-boot's arch/arm/lib/gic_64.S. /* x9: ReDistributor Base Address of Current CPU */ 2: mov w10, #~0x2 ldr w11, [x9, GICR_WAKER] and w11, w11, w10 /* Clear ProcessorSleep */ str w11, [x9, GICR_WAKER] dsb st isb ==> /* x9: ReDistributor Base Address of Current CPU */ 2: // gicr power on, ckim mov w10, 2 str w10, [x9, GICR_PWRR] 5: ldr w10, [x9, GICR_PWRR] tbnz w10, #1, 5b /* Wait Children be Alive */ mov w10, #~0x2 ldr w11, [x9, GICR_WAKER] and w11, w11, w10 /* Clear ProcessorSleep */ str w11, [x9, GICR_WAKER] dsb st isb Can anyone suggest what I can try to solve this problem? (I mean, the problem of linux shell not responding in qemu virtual machine) I would appreciate it for any comment or help. Thank you. Chan Kim

1 0

Re: Missing Ubuntu tools on KernelBuild page
by Alan Perry June 3, 2023

June 3, 2023

I found two more tools needed to build with the Ubuntu 20.04 config, dwarves and zstd. alan On 6/3/23 9:00 AM, Alan Perry <alanp(a)snowmoose.com> wrote: > I am trying out the kernel building instructions in > https://kernelnewbies.org/KernelBuild with Ubuntu 20.04 and found > missing/incomplete info. I would fix it myself but I only just got here > and don't have access to do so. > > With regards to the "What tools do I need?" section, on Ubuntu, I found > that I also needed to install flex, bison, and libefi-dev. >

1 0