Connect the cable you normally plugin to the Pi into the 5 port switch then your pi to that switch and this should test the connectivity STP problem I believe is occurring.

First, if udhcpc is already getting a lease, then the FOS init is running, so it’s not really a kernel hang, it’s stopping somewhere in the init scripts after network up. Which makes me look straight at mode=debug in your bootargs. Debug mode in FOS is interactive, it waits for you to hit a key or type at a shell before it does anything. If the console you’re watching isn’t the one it’s prompting on, that looks exactly like a hang. I’d drop mode=debug for a run and see if it moves on, and separately get a serial console on the Pi (enable_uart in config.txt, add console=serial0,115200 alongside your tty1) so you can actually see where it stops instead of guessing from HDMI.

Second, you swapped the kernel but kept the stock FOS initrd. That’s fine in principle, but the FOG init was built against FOG’s own kernel config. Worth checking that the Pi kernel has everything the init expects when it mounts root from /dev/ram0 with that ramdisk_size, and that nothing later in the init is relying on a module or kernel feature the Pi build doesn’t ship. A serial log with loglevel=7 will tell you quickly.

Third, unrelated to the hang but it’ll bite you right after: for a capture (type=up) FOG normally points storage at the dev share, storage=IP:/images/dev/, not /images/. The image gets moved into /images/ by the server once the upload finishes. If you hand rolled the bootargs from a deploy example, that one’s easy to miss.

Also, since the target is a single USB SSD, you might get more mileage checking whether the FOS init even handles /dev/sda as a capture target the way you’d expect on ARM, but that’s step two. Get it past checkin first. Would be good to hear if Tom or Sebastian have opinions on running FOS with a non FOG kernel, I don’t think that’s a path many have gone down.

Regarding OPNsense, there isn’t anyone on the infrastructure team available to look into it right now; I can probably check on that Monday morning.

To be transparent with you, I’ve been retraining for a new career since February 2026 and only just obtained my IT diploma in July. What helps is that I’m persistent with projects and usually manage to get the job done. I’ll get back to you once I have the information regarding OPNsense.

U-Boot can’t be made to wait longer without a saved environment, and without an SD card you can’t save one. So this is fixed on the switch, not on the Pi: ask whoever runs it to enable PortFast (Cisco) / edge port (most others) on the ports the Pis plug into, or move to RSTP. That is a normal setting for any PXE client, not a Pi special case. If you want proof before asking, plug the Pi into a dumb unmanaged switch for one boot; if bootflow scan gets a lease first time, you have your answer.

Two more things from that screen:

• 0 Storage Device(s) found. Last time it found 1 (the USB SSD). If the SSD isn’t attached, there’s nothing to deploy to, so make sure it’s plugged in and powered for the deploy test.
• I still need the three things from my last post, and I can’t go further without them: whether FOG_TFTP_ROOT_DIR exists in FOG Settings → TFTP Server; the contents of /tftpboot/pxelinux.cfg/01-88-a2-9e-53-34-c0 after you queue a Deploy task; and ls -l /tftpboot/arm_Image /tftpboot/arm_init.cpio.gz. Those tell me whether the FOG side is doing its job on your rebuilt server. Everything else in this thread is now on the network side.

I created a new snapshot to avoid losing data again and having to start everything from scratch; right now, I’m stuck on this page on the Raspberry Pi.

Your screenshot is actually the best news so far, and it answers your “fine-tune” question with “there is nothing to type”:

U-Boot’s DHCP works now. DHCP client bound to address 192.168.203.77 (1 ms) — twice, once inside bootflow scan and once by hand. Whatever was blocking it on the old setup is gone. (The C0A8CB4D.img “File not found” right after is harmless: with no bootfile from DHCP, U-Boot guesses a name from its IP and fails to fetch it. setenv autoload no silences it, but you can’t save that without a card, and it costs nothing.)

bootflow scan is already doing the FOG boot path for you. Look at the top of your screen: after DHCP it asked the TFTP server for pxelinux.cfg/default-arm-bcm283x, then default-arm, then default (and, above what’s visible, 01-88-a2-9e-53-34-c0 first). That is pxe get — U-Boot runs it by itself as part of standard boot, no bootcmd, no environment, no boot.scr. Every one came back “File not found” because FOG only writes the 01-<mac> file while that host has a task queued, and nothing was queued. So the whole automation is: queue the task in the web UI, power the Pi on, done. No typing.

Drop boot.scr entirely. Wrong image format for "source" command is because your boot.scr is plain text; source only runs mkimage-wrapped scripts. You don’t need to fix that, you need to stop using it — the pxe path replaces it.

So, on the rebuilt server, please confirm two things and then do one test:

• FOG Settings → TFTP Server has a FOG_TFTP_ROOT_DIR entry reading /tftpboot. If it doesn’t, the install is older than the fix; run the updater on the beta channel.
• Queue a Deploy task for Raspberry-test, then on the server cat /tftpboot/pxelinux.cfg/01-88-a2-9e-53-34-c0 — it should start # Generated by FOG Project and contain kernel arm_Image — and ls -l /tftpboot/arm_Image /tftpboot/arm_init.cpio.gz. Paste both here.
• Then just power-cycle the Pi and let bootflow scan run. It should now find the 01- file, pull arm_Image, and boot into FOS.

On “can’t get an IP via DHCP” during deployment: I need to know which DHCP. U-Boot’s is fine per your screenshot. If you mean FOS itself (after the kernel boots, the FOG banner, Attempting to check in never coming), that’s a different network stack — tell me which kernel booted (FOG’s arm_Image via the 01- file, or kernel8.img from your old script) and paste the lines around udhcpc / eth0. Text rather than a photo if at all possible; a serial adapter on the Pi’s UART pins makes that easy and is worth the few euros for a 200-unit project.

I finally managed to configure the Raspberry Pi image capture; now I just need to fine-tune it to avoid having to enter these commands in the U-Boot terminal:

dhcp
tftp ${scriptaddr} boot.scr
source ${scriptaddr}

Now I’m back to working on the deployment, but I can’t seem to get an IP address via DHCP—I don’t understand why.

Hi, I ran into a problem: my VM completely crashed, so I have to start over from scratch. I’m still stuck at the capture stage; Gemini can’t review the entire conversation history we had to get to this point, though I had already reached U-Boot.

When I’ve completed this step, I’ll take a snapshot of the VM this time.

1. Everything in /tftpboot/pxelinux.cfg/ is hand-written, and it’s the wrong format for pxe boot. 01-88-a2-9e-53-34-c0, boot.scr, default and default-arm all contain a U-Boot script (setenv …, tftp …, booti …). pxe boot doesn’t run scripts; it parses a PXELINUX-style config (label, kernel, initrd, append), finds no labels in yours, and does nothing. That’s your “downloads pxelinux, but then stops”, and it was never going to work regardless of the FOG bugs I fixed. Please don’t hand-write anything under pxelinux.cfg/: FOG owns the 01-<mac> names there, and its periodic reconcile deletes any 01- file whose host has no active task, so your file would vanish anyway. (boot.scr, if you ever wanted one, has to be a mkimage-wrapped binary in the TFTP root, not text under pxelinux.cfg/. You don’t need it; the pxe path is the whole thing.)

To get FOG’s file: run the updater once more (PR #1679 is merged), then in the web UI queue a Capture task for Raspberry-test. Within a moment /tftpboot/pxelinux.cfg/01-88-a2-9e-53-34-c0 will be replaced by a file starting # Generated by FOG Project with kernel arm_Image and initrd arm_init.cpio.gz, and /tftpboot/arm_Image and /tftpboot/arm_init.cpio.gz will appear beside it. Paste that file back here. Your host settings are fine: arm64, image set, primary disk /dev/sda. (acpi=off in the kernel arguments does nothing on a Pi; harmless.)

2. saveenv failed because there is no SD card, so nothing you setenv survives a reboot. That’s actually fine for the end goal: the default bootcmd=bootflow scan already does DHCP and then pxe get / pxe boot on its own, no environment needed. So for a cardless fleet you don’t need bootcmd at all. What you do need is DHCP to work inside U-Boot, which brings us to:

3. DHCP. netretry yes was doing its job (“Retry time exceeded; starting again” is it retrying, not failing). With STP confirmed on the switch, the port is most likely blocking for the first ~30 seconds after U-Boot resets the NIC. One test settles it: run setenv netretry yes then dhcp, and wait a full 60 seconds before judging. If it gets a lease on the second or third cycle, that’s STP, and the fix is PortFast / edge-port on the Pi ports (the default bootflow scan won’t retry long enough on its own, and without an SD card you can’t persist netretry). If it still has nothing after 60 seconds, then it isn’t timing: check OPNsense’s DHCP log (Services → DHCPv4 → Log) for 88:a2:9e:53:34:c0 during the attempt and tell me whether a DISCOVER arrives and whether an OFFER goes out.

Once DHCP works and FOG’s file is in place, bootflow scan (or dhcp; pxe get; pxe boot by hand) should pull arm_Image and boot FOS. If it stops anywhere after that, the last lines on screen are what I need — pasted text, not a photo, if there’s any way to capture it.

I’m also showing you screenshots of my host and image to see if I made a mistake.

Hey, I’m sending you the screenshot of the test.
I’m also sending you the configs to see if I made a mistake.
My colleague told me that STP would be enabled on the switch but not in OPNsense.

Config u-boot

cat /tftpboot/pxelinux.cfg/01-88-a2-9e-53-34-c0

cat /tftpboot/pxelinux.cfg/boot.scr

cat /tftpboot/pxelinux.cfg/default

cat /tftpboot/pxelinux.cfg/default-arm

cat /tftpboot/pxelinux.cfg/default.bak

“Downloads pxelinux, but then stops” — partly expected, partly another FOG bug, now fixed.

• If there was no task queued for the Pi at that moment, the file FOG writes says localboot 0, which tells U-Boot “nothing to do, carry on to local disk”. That’s by design: no task, no imaging. So “stops” after a successful pxe get is correct behavior unless you’d queued a capture first.
• If there was a task queued, it would still have stopped, and that one is on me: the file named the kernel and init as http://… URLs, which is what boards with wget use. Your U-Boot’s pxe code can’t follow a URL — I checked U-Boot’s source (boot/pxe_utils.c every kernel and initrd line is fetched over TFTP, relative to wherever the config came from, so kernel http://… became a TFTP request for a file literally called that. Fixed in working-1.6 (PR #1679): the file now says kernel arm_Image / initrd arm_init.cpio.gz, and FOG copies those two files into /tftpboot itself the first time a task is queued for an ARM host, and again whenever the kernel is updated. Run the updater once more, queue a capture for the Pi, then on the server check that /tftpboot/pxelinux.cfg/01-88-a2-9e-53-34-c0 contains kernel arm_Image and that /tftpboot/arm_Image and /tftpboot/arm_init.cpio.gz exist.

The intermittent DHCP is a network-timing problem, not a FOG one, and Tom’s STP question is the right first suspect. On a switch port running classic spanning tree, the port doesn’t forward traffic for roughly 30 seconds after link-up (listening, then learning). U-Boot brings the link up and sends its DHCP discover immediately, retries for a few seconds, and gives up — that’s the “8 seconds searching”. The times it works are the times the port happened to already be forwarding. The Pi’s EEPROM boot succeeds because it retries for much longer. Two fixes, and I’d do both:

• On the switch: enable PortFast / edge-port (or RSTP) on the ports the Pis plug into. That’s the real fix and it helps every PXE client, not just the Pis.
• In U-Boot, so a slow port doesn’t kill the boot anyway:

setenv autoload no
setenv netretry yes
setenv bootcmd 'dhcp; pxe get; pxe boot'
saveenv

autoload no stops dhcp from also trying to TFTP a bootfile it was never given (that’s an extra timeout and a spurious failure in your sequence). netretry yes makes U-Boot keep retrying DHCP instead of giving up after a few seconds — the right call for a headless board that has nothing else to do, but be aware it means a Pi with no DHCP server on the wire will sit there retrying rather than dropping to the prompt.

If DHCP still fails after that, the next read is OPNsense’s DHCP log for that MAC: whether the discover even arrives, and what it offers. And as before, pasted text beats a screenshot — the exact lines around pxe boot are the ones I need next.

I do have the filename you requested.

When U-Boot starts, DHCP doesn’t work; it spends 8 seconds searching. Sometimes, when rebooting the Raspberry Pi, it manages to obtain an IP address, successfully detects the server’s IP, and downloads pxelinux, but then stops.

What I don’t understand is why U-Boot sometimes manages to get an IP address and sometimes doesn’t.

Correction: earlier I said pxe get “finding” pxelinux.cfg/01-88-a2-9e-53-34-c0 proved the file-generation side worked. It didn’t. U-Boot prints Retrieving file: ... before it sends the request, and the Loading: T T T T that follows means the server never answered at all. A file that really is missing gives you TFTP error: 'File not found', not timeouts. So the file-side was never proven, and it turns out it was broken on my side of the fence.

The FOG bug, now fixed: FOG was writing the 01-<mac> file under the directory it keeps the HTTP-served kernels in (/var/www/html/fog/service/ipxe/), not under /tftpboot. The TFTP daemon runs chrooted to /tftpboot, so the file existed but TFTP could never see it. That’s fixed in working-1.6 (PR #1664) with a new setting, FOG Settings → TFTP Server → FOG_TFTP_ROOT_DIR, which the installer sets to the real TFTP root. Run the updater once it’s merged and check that setting reads /tftpboot; after that, queue a task for the Pi and you should see /tftpboot/pxelinux.cfg/01-88-a2-9e-53-34-c0 appear on the server. Please confirm that file is there before the next boot test — it’s the one thing I can check in code but not on your box.

Your current boot loop is a different, earlier step. From the console shot: U-Boot itself loaded cardless, which means the Pi’s EEPROM network boot already pulled the firmware and u-boot.bin from /tftpboot over TFTP. That proves the OPNsense next-server, the FOG TFTP service and the firewall are all fine for this client — so ignore my earlier firewall angle. What’s looping is bootcmd=bootflow scan: that’s U-Boot’s standard-boot sequence, which tries mmc, usb, then ethernet, and the ethernet step starts with U-Boot’s own DHCP request (BOOTP broadcast 1, 2, 3...). That DHCP never succeeds, and it’s never been shown to work in this thread — your earlier manual test set ipaddr/serverip by hand and skipped DHCP entirely. The empty per-architecture filenames in OPNsense are fine, by the way: the pxe boot method doesn’t need a bootfile name at all. (Side note, unrelated to the Pi: the iPXE-class filename in OPNsense is what gets handed to a client that is already running iPXE, and FOG expects default.ipxe there, not ipxe.efi — with ipxe.efi your x86 UEFI clients will reload iPXE forever. Worth a look when you’re back on those.)

Two things to try at the U-Boot prompt, and please paste the exact text rather than a screenshot if you can:

dhcp

on its own. If it also loops on BOOTP, then U-Boot’s network driver isn’t getting a lease and we look at OPNsense’s DHCP log for that MAC (does the request even arrive, does it offer). If it does get an address, then:

pxe get
pxe boot

once the FOG update above is in and the 01-... file is confirmed on disk. If that works by hand, setenv bootcmd 'dhcp; pxe get; pxe boot' and saveenv gets you the automated path — bootflow scan should get there too, but the manual sequence tells us which step is at fault when it doesn’t.

Hi, I’m sending you the two screenshots—one from OPNsense and the other from the Raspberry Pi.

The new symptom is a different failure than before, and it’s outside anything FOG serves: looping on BOOTP with no attempt at Retrieving file... means it’s failing at DHCP/BOOTP negotiation, a step before pxe get would ever run. FOG can’t see that far back — the board never gets far enough to ask FOG anything.

You’ve also moved to a materially different boot path than what we’d been testing: cardless, via the Pi’s own network-boot EEPROM, rather than typing commands by hand at the U-Boot prompt. That matters here, because the EEPROM’s automatic network-boot flow runs its own boot sequence, built into that U-Boot, not necessarily the dhcp / pxe get / pxe boot lines from earlier in this thread — those were for a manually-typed bootcmd. If the EEPROM path uses bootp instead of dhcp, or expects OPNsense to hand it specific DHCP options, that’s a different thing to get right than what we tested manually.

Two things I’d need to actually say anything useful here, since I can’t see either from where I’m sitting:

1. What’s the board actually running right now — did the nano edit touch a persisted bootcmd (printenv bootcmd), or is this the EEPROM’s own default network-boot sequence with nothing custom in the loop at all?
2. In OPNsense’s DHCP config for that subnet, what are options 66 (next-server) and 67 (filename / bootfile-name) set to? The EEPROM’s PXE client needs those to know where to send its own request in the first place — if they’re pointing at the wrong place, or missing, U-Boot never gets the chance to see FOG at all, and that would produce exactly a BOOTP loop with nothing after it.

That’ll tell us whether this is a boot-script problem (fixable on your end) or a DHCP-options problem (fixable in OPNsense) — right now I genuinely can’t tell which from here.

Here is an update following our latest troubleshooting sessions and tests:

The !V@JL artifact: That part was indeed a leftover artifact from editing the file manually with nano. Once cleaned up, we hit a regression: the Raspberry Pi no longer downloads the 563-byte config file at all anymore. It now loops directly on BOOTP broadcast and times out without hitting the TFTP stage (Retrieving file... doesn't trigger anymore).

Goal & Architecture: The target deployment must remain 100% cardless (no local storage, no SD card, no USB drive used during boot), relying purely on the RPi 4 network boot EEPROM + OPNsense DHCP + FOG/U-Boot.

Regarding your earlier notes on TFTP/Firewall:

    We are running UFW on the FOG server, and we verified that nf_conntrack_tftp is active (lsmod | grep tftp confirmed).

    BOOT_external_tftp_server is not enabled (TFTP runs locally on the FOG box).

    The Pi and FOG server are on the same subnet, with no intermediate restrictive ACLs on that local segment.

The permission fix: We noted your mention about the file permissions fix for downloaded files not being set properly after upload in the working-1.6 branch. Could this regression (dropping back to infinite BOOTP loops instead of attempting the TFTP fetch) be tied to how the file is currently served or indexed, or is there a specific way U-Boot expects the handoff after DHCP?

So rather than “check your firewall” in general, four narrower things:

1. Which firewall are you actually running — ufw, firewalld, or plain iptables? The installer only auto-configures the first two; if it’s bare iptables, my original theory stands and you’d need to allow the ephemeral UDP range by hand.
2. If it’s ufw: lsmod | grep tftp — the installer tries to load nf_conntrack_tftp but silently continues if that fails, so it’s worth confirming it’s actually loaded rather than assumed.
3. Is BOOT_external_tftp_server set to “yes” in your FOG settings? If so and your TFTP is actually running on the FOG box itself, firewalld would have skipped opening it for you.
4. Are the Pi and the FOG server on the same subnet/VLAN, or is there a router, switch ACL, or (if this is a VM/cloud box) a security group between them? None of the above touches anything outside this box.

If you’ve got shell on the FOG server, tcpdump -ni <iface> port 69 or portrange 32768-60999 while you retry pxe get is still the fastest way to see whether the request goes out and nothing comes back (firewall/network) versus the request itself failing (something else entirely).

On the timeout itself: “found the file, then hung mid-transfer” (Retrieving file: ... succeeding, then Loading: T T T T T T / Retry count exceeded) points at TFTP’s own connection model, not at FOG. TFTP’s initial request goes to port 69, but the server then hands the rest of that transfer off to a different, randomly chosen UDP port for the actual data — so if there’s a firewall between the Pi and your FOG server that only allows port 69 through, the request succeeds (that’s why U-Boot found the file) and every packet after it gets silently dropped. That matches your symptom closely enough that I’d check it first: either open the OS’s ephemeral UDP range to your TFTP daemon, or (simpler if this is on the same box) confirm nothing’s filtering loopback/LAN traffic to it at all. If you’ve got shell on the FOG server, tcpdump -ni <iface> port 69 or portrange 32768-60999 while you retry pxe get should show the request going out and then nothing coming back, which would confirm it.

Separately — while looking into this I found a real gap on FOG’s side and fixed it regardless of whether it’s your actual cause: the file pxe get downloads wasn’t having its permissions set after upload, so if your TFTP daemon reads as a different user than the account FOG uploads over SFTP with, that alone could produce exactly this symptom (found the file, denied reading it). That fix is in the same working-1.6 branch now, so another update will pick it up. Worth ruling both things out — they’re not mutually exclusive.

On your scalability question: for 100–200 units, don’t script the SD card at all — the RPi 4’s own boot EEPROM supports network boot as the first boot mode, ahead of SD/USB, which is exactly what you want instead of the local-storage-timeout-then-BOOTP-fallback sequence you saw. rpi-eeprom-config (or the raspi-config boot order menu) lets you set that once, and once it’s set it’s a firmware-level property of the board, not something FOG or an SD card image controls — one flash per unit, and after that every power-on goes straight to network boot, no bootcmd persistence step needed on your end at all. I’d flash that as part of whatever imaging/provisioning process gets each Pi ready before it ever talks to FOG the first time, rather than trying to solve it per-deployment.

I don’t have a Pi 4 here to confirm the exact EEPROM boot-order syntax for your firmware revision, so double-check against Raspberry Pi’s own EEPROM config docs before you commit to a fleet-wide flash — but the “make network boot the default at the firmware level” shape of the answer is what actually gets you out of typing anything at the prompt.

"Hi again! Great news regarding the new TFTP fallback mechanism.

I tested it manually by setting the IP addresses:
Plaintext

setenv ipaddr 192.168.203.50
setenv serverip 192.168.203.113
pxe get

What happened:

U-Boot successfully found the correct path generated by FOG based on the MAC address (Retrieving file: pxelinux.cfg/01-88-a2-9e-53-34-c0).

However, the download times out (Loading: T T T T T T) and results in a Retry count exceeded.

For context: a deployment task was explicitly active and queued in the FOG web interface before running the test, so the file should be there.

Is there a specific TFTP block size or setting required in working-1.6 for U-Boot’s pxe get to successfully pull the file without timing out, or could it be related to firewall/TFTP service configuration on the server side?"

"To answer your question directly: yes, so far I have only been testing manually at the U-Boot prompt (=>).

My main concern right now is scalability. Since I need to deploy this across a fleet of 100 to 200 Raspberry Pi units, configuring each SD card manually or typing commands at the prompt for every single machine is not an option.

What is the recommended best practice in FOG working-1.6 to handle automation for a large fleet? Can the bootcmd be permanently stored in the Pi’s onboard EEPROM once, or can U-Boot fetch a boot script via TFTP automatically without manual card preparation?"

U-Boot’s pxe get command doesn’t need wget — every U-Boot build has it,
and unlike wget it isn’t configurable: it always fetches
pxelinux.cfg/01-<mac, dash-separated, lowercase> by TFTP from whatever
server your board’s serverip points at. FOG now keeps a real file at that
path for every host, kept in sync automatically whenever a task is queued,
completed, or canceled — so your boot sequence becomes just:

dhcp
pxe get
pxe boot

No URL, no query string, nothing for the “bad port”/no-wget class of problem
to trip over — the filename is fixed by the MAC, so there’s nothing to
substitute.

This just merged into working-1.6 — same branch you’re already tracking
(you quoted 1.6.0-beta.4707 a few hours ago; this landed after that), so
running your update again should pick it up. Two things to check once you
have:

• Settings → FTP/TFTP needs a TFTP host/username/password configured — same
  connection FOG already uses to upload your ARM kernel, so if that’s
  already working for you, you’re set.
• I still don’t have a Pi to test this against, same as everything else in
  this thread — if pxe get doesn’t find the file, or finds one FOG didn’t
  mean to serve, that’s exactly the kind of thing I need you to report back.

One thing from your last post I want to flag separately, because it looks
like a different problem from the wget one: the boot sequence you
described — times out on local storage, then falls into a BOOTP broadcast
loop that gives up with “Retry time exceeded” — reads like U-Boot’s own
default bootcmd running, not a custom one. That’s the standard
Raspberry Pi fallback behavior when nothing else answers, and it wouldn’t
run dhcp / pxe get / pxe boot at all, custom or not.

Everything you’ve described testing so far — the wget/pxe boot sequence,
the curl check, now pxe get — sounds like it’s been typed by hand at the
=> prompt each time. That proves the commands work, but it can’t be “fully
automated,” which was the goal from your very first post: nothing runs
automatically unless it’s persisted as bootcmd, either with
setenv bootcmd '...'; saveenv on the board itself, or as a boot.scr /
extlinux.conf your SD card or TFTP server hands U-Boot on its own at power-on.

Can you confirm which of those two you actually have in place right now? If
the answer is “neither yet — I’ve only been testing at the prompt,” that’s
probably the real blocker to automation, independent of wget vs. TFTP, and
worth sorting out before we look any further at the fetch mechanism itself.

Following your instructions, I checked the U-Boot prompt. When typing wget, it responds with:
Unknown command wget try help
So the U-Boot build on these boards does not include the wget command.

Also, for context on how the board behaves at boot, here is what happens visually during the startup sequence (attached photo): it tries to boot locally, times out on storage (mmc / usb), and then falls back to a standard network BOOTP broadcast loop (Retry time exceeded).

Given that U-Boot lacks wget and relies on standard BOOTP/PXE broadcast rather than direct HTTP fetching, what is the recommended way or fallback mechanism to have these boards pull their configuration from FOG?"