Jump to content


  • Posts

  • Joined

  • Last visited

Other groups


Contact Methods

  • Github

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @Pali Hi! I've run into this issue. I've got an ebin-v5 with cpu frequency stepping, and an ebin-v7 without, both on 5.15.86. Based on the CPU markings, the v7 is using platform firmware set for 1200 MHz. I'd be interested in seeing what ysou know, but claim no special skill. Likely, I'll just drop the u-boot config back to 1000 MHz even on the v7, if that solves it.
  2. In jammy, it's part of the systemd package, not broken out. In 22.10 and debian unstable, it's broken out to the systemd-boot package. If you keep your kernel at /boot/vmlinuz-6.0.0-6-amd64, then you instead run "kernel-install myKernel /boot/vmlinuz-6.0.0-6-amd64". At least one thought is going to be required to take manual control of installing non-standard kernels.
  3. How will systemd-boot guess the thoughts of users? Users will tell systemd-boot. As I said, you can use bootctl to select the next boot. Usually, the desired kernel is "the latest". But if you have an opinion, go ahead and type it in to the computer, over SSH or console or whatever. "I don't want to play nice with others" - Well, I can't help you there, but being interoperable with the best solution sounds like it's beneficial enough just for our own use, and the interoperability is a side benefit. "User must manually configure" - you're kidding, right? These configuration files are automatically generated and drop into the standard place. It's easier on ourselves, not harder. "Simple instructions" - apt install linux-image systemd-boot; kernel-install Balbes-ornery /usr/lib/linux/linux-6.1-balbes150 /usr/lib/linux/initrd; bootctl set-default Balbes-ornery
  4. What is a "system" or "core" as you use the words? systemd-boot can select next-boot from a running linux system, no monitor/USB needed. GRUB does terrible at detecting other distributions. systemd-boot is simple, a single app on ESP and some standardized config files. How can you claim it's complex without identifying GRUB as more so? It is supported fine in any new enough distro.
  5. @IgorI'm sorry I missed this ping. Extlinux is nice enough, but keeps all of the configuration within a single file, which makes it difficult to manage a multi-boot setup. GRUB is a long known bootloader, but it's full of so much legacy - I don't know anything it does better than another option, and plenty it does worse. It does have an advantage of drop-in include files, but it also likes to repeat itself over and over and over again. systemd-boot is nice and clean, but doesn't have support in Debian Stable.
  6. @ABF023It's not supported by armbian (yet?) but: If you put a UEFI application on an ESP on a GPT-partitioned disk in the right location, u-boot will boot it. And I think u-boot (2023.01-rc4, at least) will pass an internally saved DTB to the UEFI app. So you need to partition your disk as GPT, add a vfat filesystem with UEFI parttype (EF00 in gdisk), and put either the kernel or systemd-boot at EFI\BOOT\BOOTAA64.EFI (which systemd-boot will handle). This is possible in latest Ubuntu and Debian Unstable.
  7. Thank you for your generous help and mentorship, Pali. I have submitted your suggested V2.
  8. Thanks! So I tried the compilation, and the check added to the beginning of yours matches the first three instructions of the while( do ... while ) : test3: @ args = 0, pretend = 0, frame = 0 @ frame_needed = 0, uses_anonymous_args = 0 @ link register save eliminated. .L15: ldrb r3, [r0] @ zero_extendqisi2 cmp r3, #0 bxeq lr .L16: mov r3, r0 ldrb r2, [r0, #1]! @ zero_extendqisi2 cmp r2, #0 bne .L16 add r0, r3, #2 b .L15 Dang, that's tight! Only 9 instructions with the initial check, because it appears ARM64 has a "pre-index" addressing mode that updates the base register as part of the load. If I understand, that's able to replace the "add" from your loop. But looking at this, it strikes me that the code could be manually adjusted to not need the "mov" instruction. Of course, I have no idea if there are rules on branching before/after a load. ldrb r2, [r0] @ zero_extendqisi2 .L15: cmp r2, #0 bxeq lr .L16: ldrb r2, [r0, #1]! @ zero_extendqisi2 cmp r2, #0 bne .L16 ldrb r2, [r0, #1]! @ zero_extendqisi2 b .L15 But we're awfully far afield of bugfixing, we're into pre-mature optimization. I did enjoy the exercise. You've convinced me about the null byte. It doesn't harm, it would have helped catch the present bug, it has value in the future based on the change you mentioned to memory init. If I'm reworking the patch to include the terminating byte (which is entirely your code, if you're okay with me claiming it), I'll also use the tighter loop, and let the list and CC's provide the comments directly. It may take me a few days to once again cut the patch and communicate the changes.
  9. I am opposed. Let's discuss why. And I recognize that you have more experience here, so I appreciate if you explain your thinking so I can refine my understanding of what is important. Looking at the final null byte, I believe it's entirely superfluous. The entire region has already been nulled out with enough space to hold more than the strings we're writing. If, somehow, the fdtfile variable has begun stomping over other data, it would be better to discover the error by NOT nulling the beginning of the next variable location, as the logic that would read that data would make it visible that there is a problem. Looking back at what we've learned, the lack of "soc", "board", etc. variables should have told us something, but we didn't know what we didn't know. I have no desire to submit that as a patch. As for the "optimized" check for variables against the use of strlen, 9 bytes vs 14, but how long do you have to stare at the optimized version vs. immediately understanding the correctness of the algorithm. Plus, when you add the initial condition check, you may have a few more instructions. The loop itself from .L7 to the end is only 9 instructions. Uh, I don't know how to get the assembly as you did, to compare my optimized version. Do you think it's better to save the bytes at the cost of developer cognition?
  10. That later version (which I sent to the u-boot list, did you see it) was for readability. The code I proposed for size/speed was while (*ptr != '\0') { do { ptr++; } while (*ptr != '\0') ; ptr++; } There is an error in your code. if the environment is empty, you will increment and write new variables. These variables will not be able to be found, as the check for the beginning of the variables will always see the first null byte.
  11. Network problem is known. Run "systemctl unmask systemd-networkd; systemctl start systemd-networkd"
  12. Alright, that's actually promising, because that is something I might know how to help with. Like I said, you're getting the wrong device tree. So now, the question is *why*. And the answer is because the espressobin uses FIT images now. Ones that only include the v5 and v7 configurations. This is my fault, and I can fix it. But if you'd like to follow along, there's a script that runs when a kernel is installed that uses an .its file to create the FIT image. We would need to add the "v5-emmc" and "v7-emmc" configurations to it. Alternately, we can switch the ebin back to using the boot script, or go into using UEFI booting (my preference) which will allow u-boot to decide the correct DTB. https://github.com/armbian/build/pull/4521
  13. "cat /proc/device-tree/soc/internal-regs@d0000000/sdhci@d8000/status" This is "okay"? If it is okay, then it seems like there's some issue with the linux driver, for which I don't have an answer. If it is not okay, then we need to fix that, which I suspect is a problem of passing the device-tree.
  14. Sorry, I provided the directory, yes. Cat the "status" file within it - that should not say "disabled". If it is, your FDT is wrong. If it's enabled... hmm, I'll have to think more about that one. Do you have the dtb file available to u-boot? In /dtb/ or /boot/dtb?
  15. Can you tell me what FDT you're using? If you aren't passing the right tree, it may be disabling the emmc. Check by: "cat /proc/device-tree/soc/internal-regs@d0000000/sdhci@d8000"
  • Create New...