<neggles>
all that should be needed is to put "compatible = "denx,uimage";" in the sort of "shadow firmware" partition
<neggles>
i left the split ones in there to make it more obvious where u-boot expects things to be & so i could replace just the fdt for testing :P
philipp64 has quit [Quit: philipp64]
<hurricos>
I got it workig
<hurricos>
working*
<hurricos>
no worries
<hurricos>
using the same method, though I did need to manually enable CONFIG_MTD_SPLIT_UIMAGE_FW
<hurricos>
also my compatible was on an image partition which was separate from the dtb
<hurricos>
yeah, see, you leave an explicit split between kernel and rootfs
<hurricos>
I expect kernel to grow so I don't want to reserve
<neggles>
hurricos: look at the partition at the bottom
<neggles>
but also yeah i just figured 16?MB would be enough
<hurricos>
Yeah, I noticed the partitions at the bottom
<hurricos>
but won't the kernel / rootfs partitions take precedence?
<hurricos>
oh wait
<neggles>
not if it's tagged with denx,uimage like it's meant to be
<hurricos>
well
<hurricos>
they agree
<hurricos>
because of the finicking you di on p1020.mk I reckon
<neggles>
there's no real reason the fixed kernel size has to be there, i just wanted to limit how big of a cp.b i had to do in alternate bootcmd
<hurricos>
yeah, I don't even bother with cp.b
<neggles>
and make it easier to swap out the kernel image during dev
<hurricos>
it's NOR
<hurricos>
I execute in place :d
<neggles>
that's how the original factory bootcmd worked too
<hurricos>
ar
<hurricos>
yar8
<neggles>
just wasn't sure it'd work
<neggles>
since original bootcmd also copied initramfs out first
ashkan has joined #openwrt-devel
<neggles>
but yeah you could delete the rootfs partition from the list, change the .mk to not pad the kernel out
<neggles>
add the `compatible = "denx,uimage"` to `firmware`
<neggles>
and away you go
<hurricos>
for the auto partitioning, you just have to make a denx,uimage compatible partition at where the kernel starts (I made one called `image`), then enable CONFIG_MTD_SPLIT_UIMAGE_FW
<neggles>
is CONFIG_MTD_SPLIT_UIMAGE_FW even necessary?
<hurricos>
I then enclose everything with `firmware` for flashing (so I can add the tiny dtb somewhere consistent)
<hurricos>
yes, it is
<hurricos>
otherwise denx,uimage won't be touched
<hurricos>
see drivers/mtd/mtdsplit_uimage.c
<hurricos>
or err
<hurricos>
drivers/mtd/mtdsplit/mtdsplit_uimage.c
<hurricos>
I think
<neggles>
yeah hence having dtb @ 0 and actual kernel/etc @ 0x40000
<hurricos>
it registers against only specific copmatibles
<hurricos>
and only ever gets compiled in if you have that kernel option selected
<neggles>
can you pass the DTB direct from NOR as well?
<hurricos>
yes
<hurricos>
because it gets relocated anyways
<neggles>
nice
<neggles>
can reclaim some ram then
<hurricos>
to somewhere under 1000000, whence the next problem
<hurricos>
another limit at 16MiB
<neggles>
ahhhh yeah I think that was the reason I capped the kernel at 16MiB
<neggles>
something i found disassembling uboot in ghidra
<hurricos>
I'm testing something to see if I can get 17MiB working, but testing is challenging since there's no md
<hurricos>
yes, CONFIG_SYS_BOOTMAPSZ. I have the source
rua has quit [Ping timeout: 480 seconds]
<hurricos>
it's 16 << 20
<neggles>
`setenv bootm_mapsize 0xblah`
<neggles>
might bypass
<hurricos>
You'd think, but no
<hurricos>
I set both bootm_mapsize and bootm_size
<hurricos>
31MB fails
<neggles>
oh wait this u-boot is too old for bootm_mapsize
<hurricos>
no, it has it
<hurricos>
it even grabs the env variable
<neggles>
h-uh
<hurricos>
no, you're right
<hurricos>
only does getenv_bootm_size :S
<neggles>
yeah i remember seeing it check bootm_size
<hurricos>
but that's just where it WANTS to relocate
<neggles>
and checking the 2009.whatever u-boot sources, it just assumes bootm_mapsize == bootm_size
<neggles>
they didn't split it out till later
<hurricos>
it's not where it MUST relocate
<hurricos>
(the fdt)
<neggles>
afaik bootm_mapsize dictates how much data it maps to bootm_start
<neggles>
before handing over execution
<hurricos>
so I'm basically testing whether the kernel, which defaults to its own specific value of map size (64M), will work
rua has joined #openwrt-devel
<neggles>
right
<hurricos>
because all it has to do is
<hurricos>
1) move the data into memory
<hurricos>
2) put the fdt somewhere
<hurricos>
3) set the registers on cpu0
<hurricos>
4) jump
<hurricos>
that's ALL it has to do on mpc85xx
snh_ has quit [Read error: Connection reset by peer]
<neggles>
doesn't the kernel assume that u-boot has done the copy/reloc for it as part of bootm?
<hurricos>
Yes, and that works fine
<hurricos>
as far as I can tell
<hurricos>
u-boot happily takes a 31MB kernel
<hurricos>
and moves it to 0
<neggles>
interesting, I thought it only copied bootm_size bytes
<hurricos>
err
<neggles>
and you'd end up with half a kernel if you fed it a 31mb one
<hurricos>
well let me set bootm_size lower than 48MB and re-test
<hurricos>
see if it complains
<hurricos>
it should, u-boot does memory allocation
<hurricos>
(mbl)
<hurricos>
(lmb*)
<neggles>
though i guess if you can set bootm_size to 48mb and the kernel doesn't leave that 48mb locked forever that works fine
<neggles>
just a bit slow on the initial copy
snh has joined #openwrt-devel
<neggles>
...not that it wasn't already
<hurricos>
well, I'm working with initramfs for just now
<hurricos>
so it's too fast to time :^)
<hurricos>
:grimacing: it's happy even when bootm_size is 0x1000000
<hurricos>
...
<hurricos>
maybe I could just cp.b
ashkan has quit [Ping timeout: 480 seconds]
<hurricos>
cp.b works ...
<neggles>
my boot command at the moment just does cp.b 0xstartofflash 0x6000000 0x40000; cp.b 0xstartofflash+0x40000 0x1000000 0xwhatever16mibis; bootm 0x1000000 - 0x6000000
<hurricos>
I reckon the fdt setup is failing to deal with some important stuff.
<hurricos>
Let me try a 17MB kernel
<neggles>
iirc the fdt needs to be in ram at least so u-boot can modify it
<neggles>
not sure what it actually modifies other than complaining that it can't find the L2 cache which is fine
<neggles>
oh it tries to set cmdline in chosen that's right
<hurricos>
yeah, the problem I'm encountering is when I dissect the fdt steps
<hurricos>
becuase bootm it fails when it can't relocate the fdt below 0x1000000
<hurricos>
I figure as with the ws-ap3825i, I can just do the fdt manipulation steps on my own
<hurricos>
but I still run into the fdt complaining it doesn't have space
<hurricos>
which makes sense fwiw
<hurricos>
insofar as the fdt is not lower than the u-boot CONFIG_SYS_BOOTMAPSZ
<hurricos>
so it can't increase in size ... unless perhaps I fdt resize forcefully / manually, let me try that
<hurricos>
it needs to resize to add its own location into itself
<hurricos>
so that the kernel does not allocate memory over it
<hurricos>
so the kernel can actually read it on boot
rua has quit [Ping timeout: 480 seconds]
<hurricos>
ok whatever I did made the fdt reserve memory OK
<hurricos>
I never checked `fdt rsvmem print`
<hurricos>
so I'm not sure if the theory I posited above was actually realistic
<hurricos>
oh ok I just did some major hack and now it no longer complains about being out of memory shit
<hurricos>
I have to copy paste my screen buffer so I don't forget this in case it actually works
rua has joined #openwrt-devel
<Namidairo>
something something picocom -x
<hurricos>
C-a : log
<hurricos>
I just forget to do it ahead of time
<hurricos>
I did a C-a h and have a hardcopy.0 so it's close neough
<hurricos>
also it didn't work
<Namidairo>
those are good too
<Namidairo>
unless they aren't.
<neggles>
so i have, `cp.b 0xec000000 0x6000000 0x40000; fdt addr 0x6000000; cp.b 0xec040000 0x1000000 0xbc0000; bootm 0x1000000 - 0x6000000`
<neggles>
as my actual boot command
<hurricos>
I know, I know
<hurricos>
I'm trying to bust out the largest kernel I can
<neggles>
i mean
<hurricos>
see if I can break out over the mapsize
<hurricos>
the initramfs kernel is 12.7MiB as-is
<hurricos>
by kernel 5.15 it may well be over 16MiB
<hurricos>
or 6.1
<hurricos>
right?
<neggles>
you could theoretically `cp.b 0xec040000 0x1000000 0x5000000`
<neggles>
and load an 80MB kernel
<hurricos>
no
<hurricos>
because as far as I've gotten the kernel won't actually boot
<hurricos>
if it's >= 16MiB
<hurricos>
either because there's some part if the boot procedure that U-boot is flaking out over due to the kernel being larger than CONFIG_SYS_BOOTMAPSZ
<hurricos>
or because of some memory map thing that I don't quite understand in the kernel
<neggles>
I vaguely recall it clamping bootm_size to a max of 16mib, and I assumed that dictates how much address/memory space the kernel has to work with during its initial setup
<hurricos>
the latter doesn't make sense fwiw
<hurricos>
because the kernel doesn't have any way to be communicated that information
<hurricos>
everything that the kernel gets is in RAM and in the cpu0 registers
<neggles>
(and the device tree)
<hurricos>
let me see if I can find the spec sheet that shows which registers ...
<hurricos>
device tree is in RAM :^)
<neggles>
but if the mmu is set up to only give the kernel CONFIG_SYS_BOOTMAPSZ of address initially
<hurricos>
specifically it's wherever you (or the bootm command) does `fdt move` to.
<hurricos>
ahhh mmu
<hurricos>
there we go
<neggles>
and the kernel tries to read past that before it gets to the bit where it's remapped things
<hurricos>
so there's some mmu setup stuff in u-boot that is done by touching MSRs
<hurricos>
for the WS-AP3825i
<hurricos>
I gotta find that
<hurricos>
that said
<hurricos>
mmu should give me the whole ram as it already does in u-boot
<neggles>
afaik it should be making a mapping from the first param of bootm to the kernel's load address that's BOOTMAPSZ long
<neggles>
ie if you bootm 0x1000000 it'll map 0x1000000 -> (0x1000000 + BOOTMAPSZ) to 0x0
<hurricos>
let me find the registers. I am very certain I had a freescale PDF about what gets set in those first 6 registers
<neggles>
since the kernel's load address is 0x0
<hurricos>
which confuses me as freescale doesn't write u-boot
<hurricos>
I should just read the bootm_loados source
<scappylappy>
me at 02:44 - whats that pinging?? answer - stintel really needs some sleep :P
valku has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
nitroshift has joined #openwrt-devel
valku has quit [Quit: valku]
GNUmoon has quit [Ping timeout: 480 seconds]
snh_ has joined #openwrt-devel
rmilecki has joined #openwrt-devel
snh has quit [Ping timeout: 480 seconds]
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
GNUmoon has joined #openwrt-devel
ashkan has joined #openwrt-devel
<hgl>
I'm writing a package for a go program. The package lives at <SDK>/package/foo. I want to imitate other go packages by using "include ../../lang/golang/golang-package.mk", but in my case the golang package lives at <SDK>/package/feeds/packages/golang, so the include directive fails. Should I change the include path or put my package somewhere else to make the path work?
<hgl>
actually, <SDK>/package/feeds/packages/golang doesn't contain the mk file, only <SDK>/feeds/packages/lang/golang contains it, should I temporarily use $(TOPDIR)/feeds/packages/lang/golang/golang-package.mk, and change it back when submit the package to github.com/openwrt/packages?
<rsalvaterra>
… is going to be painful. I don't know exactly how much those calls (preempt_{disable,enable}, pagefault_{disable,enable}, {enable,disable}_kernel_vsx) cost, but they look *expensive*.
<blocktrron1>
nbd: we're facing a problem with ath10k and block-acks since some weeks, where the ath10k AP sends out a block of frames which the STA never acknowledges until the AP sends a block-ack request.
<blocktrron1>
I have a pcap from the situation, but only when it is already broken, not from the moment it breaks. This is very spurious, you can be connected for hours before it kicking in, but it also might happen within 30 minutes
<blocktrron1>
I'm mentioning you, as you pushed 15d8c7a and a1a71a71 and might have an idea if they can be related to our issue
<blocktrron1>
nbd: thanks, i'm not sure in which extend the handling of a block-ack session is offloaded
<nbd>
it's completely offloaded
<blocktrron1>
nbd: may i send you the pcap anyhow, and you can have a quick look at what is wrong at the state of the client session?
<nbd>
yes
<blocktrron1>
I don't want to rule out that is is a problem with the client (Only reported with intel 9260 / ax200 on 5.15), but the mac80211 bump happened around the same time.
<blocktrron1>
Awesome, I'll upload it and send you a link
<rsalvaterra>
blocktrron1: I'd really love to have good things to say about iwlwifi in general… :P
<rsalvaterra>
… but then again, ath10k…
pmelange has joined #openwrt-devel
pmelange has left #openwrt-devel [#openwrt-devel]
srslypascal is now known as Guest9182
srslypascal has joined #openwrt-devel
victhor has joined #openwrt-devel
<enyc>
rsalvaterra: funny you stould say that I was just asking about wifi firmawres and safety in #openwrt
Guest9182 has quit [Ping timeout: 480 seconds]
fda- has joined #openwrt-devel
fda has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
<hgl>
is there a make command that builds a host tool specifically, like make host/golang/compile ?
goliath has joined #openwrt-devel
<hgl>
i should've RTFM, it's there.
scappylappy is now known as mattytap
fda has joined #openwrt-devel
fda- has quit [Ping timeout: 480 seconds]
Gaspare has joined #openwrt-devel
dedeckeh has quit [Remote host closed the connection]
<wulfy23>
nbd: 0b753722754ae66067408e15835e1d66161dcb41 @ 21.02.1 any chance of a capabilty check or similar
<wulfy23>
seems to break wifi on limited chips
<wulfy23>
thankyou!
<wulfy23>
(brcmfcrap ~43455 maybe some usb dongles)
<nbd>
i'll make hostapd ignore the error
PtitGNU has quit [Quit: Quassel terminated!]
PtitGNU has joined #openwrt-devel
Gaspare has quit [Quit: Gaspare]
<wulfy23>
cheers
goliath has quit [Quit: SIGSEGV]
minimal has joined #openwrt-devel
ashkan has quit [Ping timeout: 480 seconds]
<hauke>
nbd: I see the same problem in master
nitroshift has quit [Quit: Gone that way --->]
<hauke>
brcmfmac does not use mac80211 and it does not support qos_map_set
<hauke>
hostapd should check the driver capabilities first
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<ynezz>
hauke: BTW I've prepared 4.14.259 kernel bump https://git.openwrt.org/3553d01898ec68b987e001cafff2086a4e95e59a but the testing builds for ipq40xx/mvebu failed in kernel config stage due to upstream commit 48c2461f28fe ("ARM: 8800/1: use choice for kernel unwinders"), so I needed to adjust affected kernel configs, can you please check if I took correct approach?
<neggles>
is that necessary for all altivec invocations in ppc linux???
pmelange has joined #openwrt-devel
pmelange has left #openwrt-devel [#openwrt-devel]
fda has joined #openwrt-devel
fda| has joined #openwrt-devel
fda- has quit [Ping timeout: 480 seconds]
rmilecki has joined #openwrt-devel
fda has quit [Ping timeout: 480 seconds]
<rsalvaterra>
neggles: There must be a valid reason. Nobody sane would disable preemption and page faults lightheartedly. :/
<hurricos>
neggles: I've tried everything short of building a RAMBOOTable U-boot image
<hurricos>
I also checked that lzma / bzip2 / lzo are not actually implemented on the AP330
<hurricos>
Last shot is going to be to try a rootfs in a separate image
<hurricos>
I imagine a lot of boards' sysupgrade processes are going to stop being "boot initramfs, sysupgrade" and start being "boot kernel + rootfs, sysupgrade"
<hurricos>
due to kernel growth
<hurricos>
if the only PL2303 I have left at home weren't fake I'd be testing every board I have in arm's reach after e.g. 5.10 enablement for ath79
<hurricos>
since this is going to become a very common problem
<hurricos>
since a lot of nice boards have enough resources, but painful / trivial bootloader restrictions
<neggles>
hurricos: you’re right, only the gzip code path exists
<hurricos>
Yeah, it's in the source too, I just didn't really think to use my brain
<hurricos>
u-boot configuration management has changed a lot since ever
<neggles>
yeah, menuconfig u-boot has spoiled me :P
<hurricos>
fwiw this is all notwithstanding okli-loader ports
<hurricos>
actually
<hurricos>
uh
<neggles>
lack of self-decompressing ppc kernel images is annoying
<hurricos>
Do you know whether the lzma-loader is self-contained? I guess you package the whole image with lzma-loader ....
<neggles>
it is, afaik
<neggles>
but I think implementation is per-target/arch?
<hurricos>
It is
<hurricos>
For sure, it involves an arch-specific head.S plus some C code
<neggles>
assembly is not my forte by any means
<hurricos>
I just am struggling to visualize how lzma-loader is actually told what to load
<hurricos>
I guess if the bootm's target address is passed through to it, it could go and find itself pre-relocation to 0
<hurricos>
but that assumes one is not using NAND
<hurricos>
oh, wait, never mind
<hurricos>
that's not a problem, just have u-boot relocate to RAM first
<neggles>
i think it relies on itself being loaded to ram first?
<neggles>
yeah
<hurricos>
right.
<neggles>
u-boot “boots” lzma-loader
<hurricos>
OK, so right, the two paths *are* okli or kernel+rootfs
<hurricos>
(paths on the way to handling the problem of "initramfs kernel is too large to boot")
<neggles>
i guess now we know why they have a separate initramfs partition
<hurricos>
err, for okli targets?
<hurricos>
fwiw, okli is really rare as far as I've seen
rmilecki has quit [Ping timeout: 480 seconds]
<neggles>
oh no I mean the OEM AP330
<hurricos>
Ah, I think that's just convention
<neggles>
initramfs is stored separately to kernel
<hurricos>
the whole idea of storing things conveniently together is not something I've seen outside of OpenWrt
<hurricos>
and mind you it is very convenient
<neggles>
it does reduce how much it needs to uncompress tho
<hurricos>
right
<neggles>
and I guess that’s what FIT images are for these days?
<hurricos>
right!
<hurricos>
well, they were for* in 2012 and later
<hurricos>
WS-AP3710i supports FIT after all
<hurricos>
and 3715 and 3815
<neggles>
also q: aren’t gpl tarballs meant to contain code that actually builds and runs along with at least a config file?
<hurricos>
there's a README in there somewhere :^)
<hurricos>
isn't that enough?
<hurricos>
cough.
<neggles>
this uboot tarball is missing a bunch of stuff that they keep out of tree…
<neggles>
Including several headers and at least one makefile fragment
<neggles>
the code is not buildable
<hurricos>
I've spent a lot of time thinking about it and looking at it
<hurricos>
and I realized that I have at most 25000 days left to live
<neggles>
you can see said out of tree file paths in the two patches
<neggles>
>:(
<hurricos>
and if I spend another one trying to fight the way one vendor does one thing, and forget to look for the patterns between all vendors that can be used for gain
<hurricos>
I won't forgive myself
<neggles>
that’s entirely fair
<hurricos>
life's too short to not learn powerpc assembly as stintel has learned
<hurricos>
:6)
rua has quit [Ping timeout: 480 seconds]
<neggles>
is “making lzma-loader or okli work on ppc32 would be useful for all of mpc85xx” where you’re going with this 😝
<neggles>
probably useful for a few others too
<hurricos>
it would! but not today lol
<hurricos>
well, so
<hurricos>
it'd rescue WDR4900
<hurricos>
as an exampe
<hurricos>
Oh
<hurricos>
and I'll add
<hurricos>
wait, let me try something
<hurricos>
you can run a qemu ppce500v2 pretty easily
<hurricos>
e.g. `qemu-system-ppc -nographic -machine ppce500` -- the support is good and there
<neggles>
i think qemu has a p1020rdb profile in there even
<neggles>
not that peripherals or anything are important
rua has joined #openwrt-devel
<hurricos>
there may be some cpu specific stuff
<hurricos>
is what I was going to say, but I get the sense that mpc85xx means mpc85xx
<hurricos>
I have seen nothing short of a deep and lasting backwards compat from these boards
<neggles>
yeah, they don’t seem to be particularly picky
<hurricos>
I was reading about how to hit the wdt from a guide for a completely different generation of CPU
<hurricos>
(mpc5xx)
<neggles>
is it exactly the same
<hurricos>
exactly the same
* enyc
purrs
<neggles>
also wow nxp’s latest qoriq SDK still supports these chips
<hurricos>
Yep
<hurricos>
every day that goes by I think to myself
<enyc>
hurricos: hrrm how well can you at least boot most openwrt images, mips, arm, etc even if they fail to initialize all sorts of hardware, I wonder ?
<hurricos>
what are we doing living in a world where vendors throw away chips that will never die
<neggles>
enyc: if we make it to the kernel trying to initialize devices, that’s success
<hurricos>
enyc: huh?
<hurricos>
yeah, that's the goal
<hurricos>
device drivers are another realm and they have other beasts
<neggles>
just need to make the kernel loader work, whether it’s okli or lzma-loader
<hurricos>
okli *IS* lzma-loader
<neggles>
right
<hurricos>
okli is just the OpenWrt specific fork of it I think
<neggles>
ah ok
<hurricos>
in other news, update from gitlab ce v13.2.6 -> v14.0.5 -> v14.5.2 is done now
<hurricos>
no more random people mining monero on my server :)
<enyc>
hurricos: I was thinknig/meaning.. with qemu emulation
<hurricos>
enyc: ah right
<hurricos>
well mips has malta target
<hurricos>
arm has armvirt
<hurricos>
mpc85xx may not need its own virtualization target
<hurricos>
because it's so well supported
<hurricos>
but you won't get the whole system running
<hurricos>
emulation just makes things easier to run-test
<neggles>
yeah, saves a bunch of slow expect script shenanigans 😝
<hurricos>
:shudders:
<hurricos>
even though I haven't yet figured out how to package u-boot from flash so that qemu-system-ppc will actually run it
<hurricos>
u-boot wants an ELF
<hurricos>
e.g. /usr/share/qemu/u-boot.e500
<neggles>
oh you can just feed it `u-boot` instead of u-boot.bin
<hurricos>
no
<hurricos>
I mean
<\x>
i managed to get into my ont and get root, dual realtek radios, hisilicon fiber thing, broadcom cpu.
<neggles>
the one without an extension is uboot as an elf with debug info, no?
<\x>
what a weird setup
<hurricos>
a copy of a uImage from flash
<hurricos>
a u-boot uimage from /dev/mtd10 fron an Aerohive HiveAP 330
<neggles>
right
<hurricos>
....
<neggles>
i found a tool that turns uimages into elfs to shove into ghidra a while back
<hurricos>
Unfortunately Qemu is really opaque about how it actually starts executables
<neggles>
ah
<hurricos>
it all boils down to that qemu isn't meant to run baremetal bootloaders
<hurricos>
but with mpc85xx I'm really tempted to try harder to see if I can get something working
<hurricos>
considering how well supported they are
<hurricos>
:S
<hurricos>
Yeah, this doesn't look like it's going to work with a u-boot uImage
<hurricos>
I say uImage, I don't mean a Linux kernel that U-boot is intending to boot
<hurricos>
I mean the raw u-boot partition itself which `file`s as a uImage
rmilecki has joined #openwrt-devel
<scappylappy>
I've been using mpc85xx for a while now on a WG T30
Luke-Jr has quit [Ping timeout: 480 seconds]
<scappylappy>
In the end I left uboot unchanged, both the initramfs can be copied as uImage (as long as the uImage_t30 is not overwritten)
<scappylappy>
also I manually dd the root.ext4 to the appropraite partition according to uboot printenv and copied the kernel.bin to uImage
<scappylappy>
both methods work. Not sure if that helps
<scappylappy>
I overwrite the boot args at runtime from the kernel config as needed rather than saveenv in uboot
<scappylappy>
this means I can return device to OEM my just replacing SDCard with original watchguard one (and running a WG upgrade for good measure)
rmilecki has quit [Ping timeout: 480 seconds]
<blocktrron1>
hurricos: re mpc85xx - the far better solution would be to build a U-Boot without low level init code and use that as a second stage
<blocktrron1>
It is all upstream for mpc85xx and well documented
<blocktrron1>
The OpenWrt Kernel loader code is well if your interest is to circumvent broken decompression or can access the ROM within the memory map
<blocktrron1>
OTOH, the question is if it is worth the work, especially if you can fix it by rewriting U-Boot env which can be done as part of the sysupgrade routine
<blocktrron1>
Not now, but you can establish a baseline to execute a script in the tared archive which automatically updates the uenv
<hurricos>
I need to boot from RAM, but I haven't been able to actually figure out how to properly pass symbols. The documentation is from '13 and hasn't been substantially changed since then
floof58 has joined #openwrt-devel
<hurricos>
but in '13, U-boot could only be compiled with GCC4
<hurricos>
(so my toolchain just breaks)
<hurricos>
whereas today, the documentation is incoherent
<hurricos>
there is no such thing as a symbol matching .*RAMBOOT.*
<hurricos>
potentially because it's obviated
<hurricos>
I don't know what low-level init code u-boot actually performs
<hurricos>
neggles: I figured out the qemu thing
<hurricos>
it was just the u-image header having only magic
<hurricos>
it was completely garbage otherwise
<hurricos>
first 4 bytes (magic) correct, then it's missing 0x16 bytes of real data. fills them in instead with text.