thanks @luz and @crispyoz for your input.

I fully agree with you, corners have been cut and this issue sets the record straight

you've helped me a lot by pointing out the possibility to adopt the mt76 driver as a replacement for the warp core, i will give that a try.

And it's not like this is completely voodoo wizardry to me, in this case it has been really cutting corners because of lack of time...
Very bad reason i know, but at least i'm honest about it

I'm going for that "simply super relaxing" feeling that @luz describes but that simply asks for some investments too...

So... Putting on the floaties

Thanks guys for the pointers...

cheers tony

this is absolutely great news Lazar, thanks!

i will really jump on this right away, happy that i can drop the feeble attempts i made myself

please give me some time to get this working in our product, and i'll be happy to start nagging you guys with feedback, i'm sure

cheers, tony

@luz and @crispyoz

thanks you guys, that was the best advice i ever followed
i just needed to be dragged over that line...

it has been a lot of trial and error, and i haven't answered all questions yet, but at this point the build environment spits out a complete firmware, including our own app with all custom files and dependencies...

i end up with a mainline openwrt with mt76 that gives me a console in 12 seconds, and is completely up and connected at the sta-end in 55...
i2c, gpio, alsa, everything in working order.

hopefully this also solves the problem i started this topic about... but that i have to test yet... i call this a big win anyway even without the problem fixed...

i did just realize that i'm building SNAPHOT at the moment, but hopefully i'll find an easy way to step back to current stable without hours of tinkering on menuconfig again

greetz, tony

Hey Lazar,

This is exactly what i was hoping for, thanks for that!
I guess this is just cloning and injecting the overlay into a "fresh" omega right?

Are there any concerns about using the same firmware version on both source and target?

I can imagine that you wouldn't want to clone that overlay (maybe containing older version packages) to a firmware thats newer than those packages? Or the other way around... Any thoughts on that?

I will keep on the safe side for now and will be checking for matching firmware versions using this method...

Cheers, Tony

@Lazar-Demin
thanks for that little push toward the image builder.

i'm still curious why the old mtd write method does not work for me anymore, but i think its more useful to point my energy towards the new and improved method...

I hope i still can bother you now and then, because i'm absolutely convinced i will find plenty of obstacles to be conquered

On that note, would it be better to report in the git issues or to discuss in the community?

thanks, tony

@Lazar-Demin
Thanks for the enthousiastic imagebuilder endorsement
i'll start doing my homework before i start asking questions about it...
Sound like i need to learn a new skill.

i'll try to elaborate on the nasty cloning problem first.

I never got this to work "in one go" with "my own" cloned custom openwrt 22.03 on any occasion. I can reproduce the problem every time i "flash" a fresh omega this way (mtd write).

I have a hunch it might break because the image is too big, filesize is 33226752, it seems like it does not finish the write completely and the os gets corrupted because of it. I even saw "broken pipe" at one point.
After a reboot into the cripple new os (with a lot of console complaining) i "mtd write" exactly the same custom image again and then it works out completely fine. (so the second writing is started from the first-flashed 22.03 "cripple" os)

The woraround i found now is to first
sysupgrade -F -n -v onion_omega2p-22.03.5-20240122.bin a fresh omega
let that reboot and then
mtd -r write pan230_v4.1-96_20240222.bin firmware

This works, taking a LOT of precious extra time, but no nastyness.

Needles to say it would be great to write in one go because of the time loss (times 200)

This "not completely finishing the write" used to happen to the first clones we spoke about two years ago too, with the original onion os, they gave the error "[e]Failed to erase block" after writing, but they ended up running completely fine so i stopped thinking about it.

hi Lazar, it's me again.

We have been working with OpenWRT 22.03 ever since you posted the good news "Beta OpenWRT 22.03 firmware available! Your feedback is needed"

I have had a hard time deciding where to post this question since you asked for feedback elsewhere, but this is where it all started for us.

The "dd if=/dev/mtd3 of=<IMAGE-NAME>.bin" trick has been great for a long time.We have cloned our product 100's of times with tthis method.

However it seems that the "new" OpenWRT is not so forgiving about this trick.

I've made a clone the same way as i did before, and all seemed well.

However during the write on a fresh Omega2S+ things get really nasty.

[  191.778153] jffs2: error: (483) jffs2_do_read_inode_internal: Argh. Special inode #16 with mode 0x2000 had more than one node
[  191.848147] jffs2: error: (483) jffs2_do_read_inode_internal: Argh. Special inode #16 with mode 0x2000 had more than one node
[  191.918210] jffs2: error: (483) jffs2_do_read_inode_internal: Argh. Special inode #16 with mode 0x2000 had more than one node
[  191.988187] jffs2: error: (483) jffs2_do_read_inode_internal: Argh. Special inode #16 with mode 0x2000 had more than one node
[  192.058167] jffs2: error: (483) jffs2_do_read_inode_internal: Argh. Special inode #16 with mode 0x2000 had more than one node
[  192.128210] jffs2: error: (483) jffs2_do_read_inode_internal: Argh. Special inode #16 with mode 0x2000 had more than one node

this does NOT stop....

after a very messy reboot a second firmware write with the same image makes everything good again

Probably it's all very obvious but i don't know how to do it the right way.
Using "mtd -r write <IMAGE-NAME>.bin firmware" definitely seems not to be the way anymore.

I noticed that with an openwrt.bin you advise using sysupgrade -F -n -v <SELECTED-FIRMWARE-IMAGE>.bin (in your technical doc )

I am not sure if i can use sysupgrade to write our clone, but my guess is no. (NOOOH!)

I hope you can give us some advice, since i now need to provision 200+ fresh Omega2s+ devices with our nice and perfectly running OpenWRT 22.03 image...

Thanks for the help... if you can offer any...

Cheers, Tony

PS,
i'm also looking at how the openwrt-imagebuilder-wrapper works, maybe thats a better path... but it will take me a long while to migrate everything we have in that direction i'm afraid.
Do you think that's the way to go in this case?

this is absolutely great news Lazar, thanks!

i will really jump on this right away, happy that i can drop the feeble attempts i made myself

please give me some time to get this working in our product, and i'll be happy to start nagging you guys with feedback, i'm sure

cheers, tony

Hi @crispyoz,

Sorry for the late reply, i have been trying to roll-back to the version where i observed this problem, but that seems a bit harder than i thought.

We've been testing with travelmate as a plugin these last couple of days, but if you say you haven't experienced the problem i described it gives me hope again to solve this without extra plugins...

I'll try to get back to you as soon as i achieve breaking it again...

bye tony

hi @luz

thanks for handing out that next step in the puzzle...

the learning curve feels quite steep to me (as a just starting out newbie) but i think i'm getting the hang of it.

first i had to break my current snapshot build system hopelessly, but that was a ritual offer that apparently had to be made...

as soon as i did a new pull instead of trying to switch over my current snapshot environment things were improving fast.

so, using that diff you mentioned it was easy to adapt my working config to 21.02, and things actually built without one warning or error... that was an immediate improvement already.

i added your plan44 feed too, that ledchain looked to good to pass up

i will be looking into p44build also, i'm already getting close to that "super relaxed" feel @crispyoz mentioned and who knows it will even get better...

Circling back to the wifi topic this started with, i noticed that with the mt76 i had to take a different approach than i used to.
i kind of got used to the fact that warp-core could (at least temporarily before it broke in my case) kept up the 'ap' end when 'sta' couldn't connect

mt76 on the other hand seems to just down the 'ap' end if 'sta' can't connect...
so... that was also not really what i was looking for either.

i did find however a nice plugin called travelmate that seems to offer some kind of solution.
it tries to connect the sta end, and if it doesn't succeed it stops trying and keeps the ap end up.

we'll see where that takes us the next couple of days....

anyaways, cheers guys, thanks for all the fish

tony

@luz and @crispyoz

thanks you guys, that was the best advice i ever followed
i just needed to be dragged over that line...

it has been a lot of trial and error, and i haven't answered all questions yet, but at this point the build environment spits out a complete firmware, including our own app with all custom files and dependencies...

i end up with a mainline openwrt with mt76 that gives me a console in 12 seconds, and is completely up and connected at the sta-end in 55...
i2c, gpio, alsa, everything in working order.

hopefully this also solves the problem i started this topic about... but that i have to test yet... i call this a big win anyway even without the problem fixed...

i did just realize that i'm building SNAPHOT at the moment, but hopefully i'll find an easy way to step back to current stable without hours of tinkering on menuconfig again

greetz, tony

thanks @luz and @crispyoz for your input.

I fully agree with you, corners have been cut and this issue sets the record straight

you've helped me a lot by pointing out the possibility to adopt the mt76 driver as a replacement for the warp core, i will give that a try.

And it's not like this is completely voodoo wizardry to me, in this case it has been really cutting corners because of lack of time...
Very bad reason i know, but at least i'm honest about it

I'm going for that "simply super relaxing" feeling that @luz describes but that simply asks for some investments too...

So... Putting on the floaties

Thanks guys for the pointers...

cheers tony

@crispyoz

our specific problem involves latency and packetloss, so i'm currently making graphs with continuous ping times while sending a steady stream of randomness...

top does not really show any weird behaviour as far as i can see, but maybe i just don't know where too look

thanks a lot for the info on the choice of driver, it sounds like a sensible consideration for onion to make. i was wondering about this for some time now.

in our application we don't use the nice gui that onion built, and if you think the MT driver has become more mature it might be a path we could examine further.

It would however mean that I have to educate myself first on how to swap those drivers around.... i don't think it's in my skill set yet how to do that, unless it is simply handled by opkg...
someone i know always says: "hope is just delayed disappointment"

manually configuring is not a problem, unless you mean the /etc/config/ methods disappear. most of the time i use the uci get/set/commit trickery anyway

i guess that this will become the first time i actually need to learn how to crosscompile or build a custom firmware, but there's no reason postpone the inevitable

thanks for your input, the search continues

greetings, tony

@crispyoz thanks for your thoughts.

I'm also afraid that this is a pile-up of different issues.

Our app is ofcourse using resources, but it -should- only send data through a connection that is really established. So if you only ask for that data in the direct ap connection, there will be no data through the sta connection.

Also without the app present it it's hard to notice the sluggishness of data transfer without building another way to test (and maybe make the same pitfall ;).
I have read left and right about applications where people noticed the same latency problems, for instance in a camera application.

It seems to simply surface more if you really start using the 'ap' connection next to the 'sta' connection

That's why we didn't notice before we started shipping.
(yup, i agree, failing test protocols, but still)

warp core is probably not designed to be used this way, it makes more sense that a user wants to use it with both connections in place at the same time, or with them putting 'ap' in the config to disable that functionality.

You say that the standard MT driver allows for turning off ap or sta seperately.

Do you mean that this setting does not work in the omega version at all?
I did notice that changing things like "option disable" under config wifi-iface 'ap' or config wifi-iface 'sta' don't give me the results i would expect, but it seems that changin option device_mode 'apsta' to just 'ap' under "config wifi-device 'radio0' " actually makes a difference.

Our problem also disappears when doing just that.

Anyway, i'll give your suggestions a try, thanks

Do you have any idea why Onion chose not to use the standard MT driver?

cheers
Tony

PS i love your case for the dash, thanks for that too