Jump to content

ManoftheSea

Members
  • Posts

    128
  • Joined

  • Last visited

Everything posted by ManoftheSea

  1. As far as I can tell, you've booted. OPNsense is running and unable to find the disk. I don't know anything about BSDs, or what driver you might need to find the SATA device on the espressobin. ahci0: <AHCI SATA controller> mem 0xe0000-0xe0177 irq 27 on simplebus1 This looks like it detected the controller. So yeah, I don't know why it didn't find the disk, but the problem appears to me to be the domain of freebsd, not of the bootloader firmware.
  2. br* is a bridge interface. The systemd configuration files have it set up so that all three ports are part of a single bridge. When you unmasked systemd-networkd, it probably got stuck at "waiting for network to be online", which has something like a 3 minute timeout. As you mentioned, systemd-networkd is masked by default, which is normal for every other armbian board. Switching to use Network Manager is a valid solution.
  3. Guys, are you familiar with systemd-networkd? /etc/network/interfaces is not how it's done anymore. Try checking the results of "nmcli"/"nmtui" or "networkctl" to see what is managing the interfaces, and then interact with those systems. I'm not so familiar with NetworkManager, but systemd-networkd keeps its files in /etc/systemd/network/.
  4. I switched to NixOS back in December, and so far have not been able to complete compiling u-boot on that system with any toolchain. The TF-A code needs to get into marvell git repos instead of just gathering binaries, it's not very clean. As such, I don't have any update on the issue either.
  5. @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.
  6. 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.
  7. 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
  8. 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.
  9. @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.
  10. @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.
  11. Thank you for your generous help and mentorship, Pali. I have submitted your suggested V2.
  12. 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.
  13. 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?
  14. 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.
  15. Network problem is known. Run "systemctl unmask systemd-networkd; systemctl start systemd-networkd"
  16. 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
  17. "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.
  18. 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?
  19. 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"
  20. I'm guessing you don't have a "scriptaddr" variable after the env update. Pali helped me track down a bug in u-boot, for which I've submitted a patch. Then, we'll need to build a new u-boot for ebins, to really resolve the issue. In the meantime, add env set scriptaddr 0x6d00000
  21. Yes, okay, I have compiled against the latest and see improvements, though I can't figure out exactly how the old bug worked. It's odd that it stomps on more variables than it seems like it should, but not ALL of the variables. I'll attempt to submit a patch to lists.denx.de.
  22. When I look at the compiled 2022.10, I find a block in mtd0 with That's 163 characters between the end of bootcmd and the beginning of scriptaddr. On my v7 which has shown the problem before running the 2022.04 firmware, I get 154 characters (adds "preboot=" but drops both mtdids and mtdparts) Let me see which of these variables survive the "env default -a"
  23. Oh, I see. The current logic finds the last character of the first variable in default environment, then moves 2 forward: that gives the first character of the second string. Which it then overwrites with the eth{,1,2,3)addr variables and the fdtfile, overwriting other default environment variables... which finishes by putting a null byte, overwriting the beginning of some variable and leaving a fragment. Yeah, I can see how it'd happen. Let's see, what vars: { bootcmd, arch, cpu, board, boardname, vendor, soc } are I believe included in the default config... arch=arm cpu=armv8 board=mvebu_armada-37xx boardname=mvebu_armada-37xx vendor=Marvell soc=mvebu 9 + 10 + 24 + 27 + 15 + 10 = 95 characters. eth*addrs is 9 + 10 + 10 + 10, and fdtfile string is... 44. 83 characters for a v5, or 86 for a v7. That doesn't quite line up, but seems very possible. Oh, but I'm looking at 2022.10... Let me dig out the old version.
  24. 180 bytes: Oh, that's fine then. I also understand you on sprintf, since it's doing variable insertion in the strings there. Which means strlen would be the more readable code, rather than either of our proposals here. If there were an error and ptr pointed one byte wrong in either direction, we'd either see eth3addr=00:11:22:33:44:55fdtfile=... or we'd just not have an fdtfile variable (as it's after a double null). It wouldn't affect scriptaddr. Well, if you'll continue to indulge my growing understanding. I see where there's 30 bytes of filler added for the four ethaddr. But "ethaddr=" is 8 characters (and a null), while eth?addr is 9 and null. Shouldn't the check be for the current environment mac be less than 21 or 20 characters? Why 17? Because a MAC is 17 characters... but then why reserve extra space? Maybe 12 extra bytes just don't matter? I suppose if eth{,1,2,3}addr aren't set, there's even more empty space. Okay, it's not important. Okay, I find EXTRA_ENV_SETTINGS in include/configs/mvebu_armada-37xx.h, which puts scriptaddr as the first variable and the extra buffer space at the end of the buffer. and then include/env_default populates variables and appends extra_env_settings, with "mtdparts" being the immediate predecessor if configured. Which means Default_environment cannot be an empty array, so that check is unnecessary, and doesn't have any variables of only 1 character. I don't see how scriptaddr can be overwritten in this function. I'm going to keep exploring.
  25. I found additional reports: https://github.com/mirrexagon/espressobin-nix/issues/6 You say a missing decrement... Maybe I misunderstand where the pointer ought to end up, I thought the end result was to point at the null at the end of the list, not the null at the end of the last string. These test cases: 1. The array of strings is empty, so there are only nulls: the end result is to immediately leave the outer loop, and ptr is pointing at the beginning of empty memory. Since the default environment is *probably* not empty, maybe this can be skipped. 2. First string is only 1 character before a null. Since the environment is "key=value" strings, maybe this can be ignored. The end result of my algorithm is to increment, find a null, increment, and finish - pointing at the second null to begin writing additional variables. 3. first string is multiple characters. enter while, increment, find not null, increment... until the null, move one more space, find a second null, and finish 4. 1 character and then a second string of one character: enter while, increment, finish inner, increment, find second string, enter while, increment, find null, increment, find null, finish pointing at second null, ready to write additional variables. Your later patch seems superfluous, but is there a reason for the change from sprintf earlier to strcpy later? For that matter, if we're going to use strlen here, why are we reinventing the wheel above? if (*ptr != '\0') { // Checks for empty default env while (i = strlen(ptr)) { ptr += i + 1; } } Yeah, I'm using a zero for strlen as false, maybe that's bad coding practice. As for writing a final null, what is the default_environment location? Is it initialized heap space, about to be written to the environment? We shouldn't need to write a null then, it's all nulls. And it looks like if someone intentionally filled ethaddr and eth{1,2,3}addr with 17 characters, the four of them could fill more than 60 characters of the buffer.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines