<mangix>
stintel: I remember a few ppc64 fixes from long ago that I never bothered to port in the packages feed. Let's see if they come back.
srslypascal is now known as Guest9087
srslypascal has joined #openwrt-devel
Guest9087 has quit [Ping timeout: 480 seconds]
minimal has joined #openwrt-devel
Luke-Jr has quit [Ping timeout: 480 seconds]
Luke-Jr has joined #openwrt-devel
minimal has quit []
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #openwrt-devel
rua has quit [Remote host closed the connection]
rua has joined #openwrt-devel
ashkan has joined #openwrt-devel
Luke-Jr has quit [Ping timeout: 480 seconds]
rmilecki has joined #openwrt-devel
Luke-Jr has joined #openwrt-devel
GNUmoon has quit [Ping timeout: 480 seconds]
valku has quit [Quit: valku]
srslypascal is now known as Guest9110
srslypascal has joined #openwrt-devel
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #openwrt-devel
Guest9110 has quit [Ping timeout: 480 seconds]
nitroshift has joined #openwrt-devel
ashkan has quit [Ping timeout: 480 seconds]
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
GNUmoon has joined #openwrt-devel
decke has joined #openwrt-devel
pmelange has joined #openwrt-devel
rua has quit [Quit: Leaving.]
<neggles>
yrrips: it's not a complicated process at all, but the UDR is not going to be a great choice for your first device to tear open :P
* blocktrron1
cries in U6-LR
<blocktrron1>
is it worse?
<neggles>
eh, the UDR is a U6-LR with a switch, 2x PoE out, 8/16G eMMC and a 128GB SATA SSD
<neggles>
running the unifi os stackup
<blocktrron1>
UD-R sounds like a nice mt7622 device, especially with all the additional I/O
<neggles>
they're also selling it (in EA at least) at a ludicrously low price
<blocktrron1>
Yes, I've saw that
<blocktrron1>
and the eMMC makes it quite attractive
<neggles>
even if it hits the market at twice the EA price
<neggles>
it'd be well worth it
<blocktrron1>
As the MediaTek SPi-NAND implementation makes it pretty much necessary to replace the bootloader
<blocktrron1>
Hopefully it's going to become a real product for once
<neggles>
also it looks like i was wrong and the display *doesn't* have a separate MCU, it's just hooked to the SPI bus, ST7789
<blocktrron1>
not Ubiquitit's ususal "Sell devices which we plan on discontinue before release to our most loyal customers"
<neggles>
they don't generally do that
<blocktrron1>
U6-MESH-LR
<blocktrron1>
U6-LR-EA
<neggles>
U6-Mesh and U6-Pro are still coming.
<neggles>
they're ipq50xx now.
<blocktrron1>
Yes
<blocktrron1>
and they sold off the mt7621 based once in EA
<neggles>
they were redesigned from the ground up because the mt7622 was not up to par with what people expected.
<neggles>
EA users are being sent ipq50xx models
<blocktrron1>
While they already filed the FCC changes for the new ones
<blocktrron1>
interesting, in EU i know of two cases where they received mt7621 for both
<neggles>
initially, yes
<blocktrron1>
^ proofing my point
<neggles>
um
<neggles>
how do you think they found out that the MT7622 models weren't up to snuff?
<neggles>
EA user feedback....
<blocktrron1>
It was mt7621 based
<blocktrron1>
not mt7622
<neggles>
anyone who got a 7621 LR should have been offered a retail LR
<neggles>
same as what happened with the first-batch NanoHDs
<neggles>
once the ipq50xx mesh/pro are ready they'll be sent out to people who bought the mediatek mesh/pro from Ea
<blocktrron1>
The pro was always ipq50xx
<neggles>
initial specs said mt7622
<neggles>
or rather, didn't match ipq50xx
pmelange has left #openwrt-devel [#openwrt-devel]
<blocktrron1>
The MT7622 pro became the U6-LR which was inititally mt7621 in EA
<blocktrron1>
But the pro was never sold (EA or GA) on mt7622 base
<blocktrron1>
What they indeed did was ship out U6-PRO labeled U6-LR-GAs (Myself received one such case)
<neggles>
interesting. first pro model I saw available was 2x2 on 2.4GHz, which the current LR is not
<neggles>
which seemed like a really weird decision
<Namidairo>
they could also just... not use the mtk-bmt
<neggles>
in any case if you've been sent a model that was replaced/upgraded they should replace it with an equivalent retail one, this is a policy they've explicitly stated multiple times
<blocktrron1>
I'll ask the person who received the EA hardware if he tried that
<neggles>
that doesn't apply to "we are not actually going to release a product under this name at all" stuff
<Namidairo>
the udr is at a pretty ridiculous price point for ubiquiti gear though
<blocktrron1>
neggles: U6-PRO is 2x2 ax
<neggles>
but they swapped out early NanoHDs which (iirc) didn't have proper support for both 802.3af modes and had a power supply whine issue
<blocktrron1>
U6-Lite and U6-LR is 2x2 resp. 4x4 802.11n in 2.4GHz
<Namidairo>
did they change the design or just slather got glue everywhere
<neggles>
the ipq50xx models were essentially starting from scratch after people declared the earlier mtk models to be garbage
<neggles>
which, well, they were
mangix has joined #openwrt-devel
<blocktrron1>
Yes, Ubiquiti MTK is a nightmare software-wise
<neggles>
the nanoHD being a notable exception in my experience
<neggles>
across a fleet of about 90
<blocktrron1>
Perofrmance on the U6-Lite is night and day difference with OpenWrt
<neggles>
nanoHD was flaky during the EA period but by the time it finally hit retail it was gooood
<neggles>
i can push 900mbps TCP through one if i'm careful :P (with a 3x3 client)
<neggles>
and, y'know, for a company with a whole bunch of 2.5GbE PoE switches available, they sure don't have a single 2.5GbE AP*
<neggles>
* okay the U6-LR might be able to be coaxed into it on account of the 2.5G PHY but shh
<Namidairo>
pretty sure there's no auto negotiate available for that
<neggles>
AIUI the reason we've not had the pro and mesh show up on the EA store again is that they're only being sent to people who bought the disappointing EA models
<neggles>
Namidairo: yet!
<Namidairo>
I'd have no other 2.5GbE hardware to test it regardless
<neggles>
i did rip a U6-PRO ipq50xx device tree out of a firmware blob recently, where'd i put it
<Namidairo>
also I'm pretty sure like half of the ubiquiti supply chain is in tatters right now
<Namidairo>
people are having a real bad time trying to get extra cameras
<neggles>
everyone's supply chain is in tatters right now
<neggles>
cisco are giving me 6 month minimum ETAs, probably 8
<Namidairo>
yeah but I get to pull up the EA page and see sold out everywhere whereas with cisco I need an accounts person
<neggles>
has the EA page ever *not* had everything interesting sold out?
<neggles>
typical half-life of EA stock is like an hour
<\x>
some wifi "6" will get it even its like that 256 qam over wifi 4. but yeah wifi 7 is 4k qam
<rsalvaterra>
The thing is… 4096 QAM on a noisy shared medium. On what circumstances? :/
<Namidairo>
presumably on 6E spectrum
<hitech95>
is the 21.02.1 broken for x86? I've spent the last two days trying to build it
<hitech95>
it fails on building ccache: In file included from /home/nicolo/cia/openwrt/build_dir/host/ccache-4.1/unittest/main.cpp:27: /home/nicolo/cia/openwrt/build_dir/host/ccache-4.1/unittest/../src/third_party/doctest.h:4084:47: error: size of array 'altStackMem' is not an integral constant-expression 4084 | static char altStackMem[4 * SIGSTKSZ];
<neggles>
hitech95: suggest you disable ccache and try again
<neggles>
do a make menuconfig, go into advanced configuration options, turn off "use ccache"
<hitech95>
I dont see the ccache option enabled. I'll double check that then!
<neggles>
otherwise make sure you're on the right git tag, delete build_dir / staging_dir / tmp, run `scripts/feeds/update -a && scripts/feeds/install -a && scripts/feeds/install -a`, delete .config, replace it with the contents of config.buildinfo, run `make menuconfig`
<neggles>
when in doubt, purge all the things and go again :P
<hitech95>
neggles: I've tried the last suggestion different times
<hitech95>
it seems consitant. Ive directly deleted the local git repo and pulled back again
<neggles>
did you make any changes to the config in menuconfig
<neggles>
and in your .config is `CONFIG_CCACHE` set?
<hitech95>
# CONFIG_CCACHE is not set CONFIG_CCACHE_DIR=""
<neggles>
how odd.
<hitech95>
I'll try with another machine., This was working fine with ath target.
<neggles>
weird.
<hitech95>
I'm testing with trunk lets see if the issue is there
<neggles>
maybe an environment variable?
<hitech95>
dont think so, it is a simple ubuntu machine
<yrrips>
neggles: yeah it looks like a bitch to open, not actually quite sure where to begin even, there are no visible screws and i tried to pry at the top and stuff but nothing obvious gave
<yrrips>
im just annoyed at ubnt at this point though so i might not even care if i break it eventually
<neggles>
yrrips: oh i meant in software, you probably don't really need to disassemble it
<neggles>
at least not to dump flash
<neggles>
can do that from ssh
<yrrips>
they say that "600mbps down/up is expected performance" even with all the fluff disabled
<yrrips>
neggles: oh, sorry. are we talking about the mtd partitions or _everything_?
<neggles>
any MTD it may have, and mmcblks
<neggles>
but not sda
<yrrips>
i've dumped the mtds at very least
<neggles>
also if you would happen to have a `dmesg` you can pastebin i would love to see it
<neggles>
australians don't get to buy EA things :(
<yrrips>
neggles: absolutely
rua has quit [Quit: Leaving.]
<neggles>
i'd wager it would not be difficult at all to get openwrt running on it
<neggles>
yrrips: from the FCC photos, the top cap is glued on and has 4 screws under it
<neggles>
wait no,
<neggles>
bottom cover
<yrrips>
ah, sits some rubbery stuff over it
<neggles>
yeah
<neggles>
that's just got pre-cut double stick tape
<neggles>
yrrips: that's odd - did you copy from a terminal or `> filename` ?
<neggles>
or is it literally just printing so many kernel message entries
<yrrips>
copy from the terminal
<hitech95>
neggles: master is building right now. I'll test 21.02.0 later
<neggles>
yrrips: try doing `dmesg > dmesg.txt`
<neggles>
or
<neggles>
it should be in one of the log folders but i can't remember which
<neggles>
probably /var/log/kernel.log
<yrrips>
yeah
<yrrips>
or /var/log/dmesg
<neggles>
but it's unifi os
<neggles>
so they might have hidden it
<neggles>
well moved it
<yrrips>
thats a good guess, ill poke in /var/log
<neggles>
heh
<neggles>
`find / -name '*kern*log*'`
<neggles>
the brute force approach is always fun
<yrrips>
sec, /var/log/kernel.log looks more interesting
<neggles>
yay they didn't move it
<neggles>
and, whatever `UBNT-WAVEMAX-AP` is, it's got spi flash, eMMC, and an ethernet switch
<neggles>
ipq5018 - UDR-Pro?
<hitech95>
yrrips: is that debian based? or openwrt based? I had some yubiquity products with apt installed :D apt-get update && apt-get upgrade and you get a new fancy brick.
<neggles>
cloud keys do debian, the UDR/UDM series are... *sort of* debian
<yrrips>
it's debian based
<neggles>
the actual services run in kube pods
<neggles>
...sort of
<neggles>
apparently nobody told ubiquiti that you're meant to split different services into different containers
<lemmi>
i/go maraike
<neggles>
so instead they just put debian in a container and called it `unifi-os`
<neggles>
on the plus side you can restart the container without breaking routing on a UDR while it restarts, so that's nice
<stintel>
say I'm looking for a MTK based 11ax router / AP with 2.4+5GHz ax, not just 5GHz, for a friend, so my PoE-PD hard requirement can be dropped, what should I be looking at?
<neggles>
UDM*
<yrrips>
neggles, kern.log is like 3MB so ill just empty it and give it another reboot
<yrrips>
too much hassle
<neggles>
yrrips: fair enough
<neggles>
stintel: putting two MT7915 cards into one of the PPC access points? :P
<stintel>
neggles: not for me ;)
<yrrips>
dunno why they use kern logging as they stout
<stintel>
so something ots and not too expensive preferably
<neggles>
tp-link eap?
<stintel>
they require PoE - normal people don't have that available ;p
<neggles>
i thought they had a DC jack on some of em and/or came with an injector
<stintel>
the wall models I've been testing come with neither
<neggles>
EAP660 HD has a 12V jack
<neggles>
so does 620HD it seems
<stintel>
and the EAP245 model is total shite, it's supposed to be ac wave2 but is slower than my oldest ac wave 1 ap
<stintel>
let's see, thanks
<neggles>
660 HD is an IPQ807x
<stintel>
eewww
nitroshift has quit [Quit: Gone that way --->]
<stintel>
that's unsupportable
<neggles>
i mean
<stintel>
it has to be MTK
<neggles>
to get 2.4GHz AX your choices are IPQ or find a vendor who elected to put two MT7915s into something
<neggles>
which seems unlikely when the 7622 has 4x4 N built in
<neggles>
hmmmm that is not dmesg so god knows where they've piped that to
<neggles>
but
<neggles>
oh!
<neggles>
there we go
<yrrips>
its kern.log
<yrrips>
but they
<neggles>
this does have early logs in it yeah
<neggles>
starts at 289
<yrrips>
i echo "" > /var/log/kern.log && reboot
<yrrips>
but
<yrrips>
yeah
<neggles>
this is fine
<stintel>
neggles: EAP615-Wall is 2.4/5GHz AX, and I'm sure people talked about other MTK based models that have the same
<yrrips>
they managed to fill it with garbage before
<stintel>
I just tend to ignore anything without PoE-PD
<neggles>
stintel: interesting
<neggles>
oh i guess the 7915 does come in that DBDC variant
<stintel>
yes
nitroshift has joined #openwrt-devel
<stintel>
the EAP615-Wall is like that
<neggles>
hmm
<neggles>
I wonder what the aruba ap22 is
<neggles>
probably broadcom
<stintel>
I think Linksys E8450 and Belkin RT3200 are an option
<neggles>
those are both N on 2.4
<neggles>
(and the same thing)
<neggles>
just one's murdered out for 'MERICA
<\x>
well, is 2.4GHz ax worth it? i think mt7622 has like 4x4 256qam (so basically ac modulation on n) on its 2.4GHz and most dont actually cared as they said it wont matter for 2.4GHz
<neggles>
without cross-band channel bonding it's
<neggles>
questionably useful
<neggles>
but it's the principle of the thing y'know
<stintel>
neggles: are you sure they are N on 2.4?
<neggles>
100% it uses the 4x4 radio in the MT7622
<neggles>
there's at least a few people in here who have one
<neggles>
"MediaTek MT7622 is the world’s first with 4x4n 802.11n/Bluetooth 5.0 system-on-chip..."
<neggles>
I was quite disappointed when someone - i think PaulFertser ? - told me
<stintel>
I'd say 2.4 ax is worth it because it's friendlier to the shared mediaum
<stintel>
I'm looking forward to replace ~10 ESP32-C3 with the C6 (wifi6) variant
<neggles>
definitely worth it for IoT stuff thanks to TWT etc. saving an awful lot of power
<stintel>
yep
<hitech95>
neggles: why disappointed? I'm disappointed that new chips from mtk still have fe switches in them!
<neggles>
hitech95: because it looked like there was a cheap dual band 4x4 AX access point with openwrt support available already :P
<yrrips>
neggles, do i need to do anything special to dump the mmcblk?
<neggles>
yrrips: `dd if=/dev/mmcblkX of=mmcblkY bs=1M` should do it - suggest you dump it to the SATA SSD :P
<neggles>
it won't be a particularly *clean* dump since services are running etc
<neggles>
but
<stintel>
mount -o remount,ro first ?
<neggles>
er, of=mmcblkX.bin
<neggles>
stintel: good point
<neggles>
i was going to go with `unifi-os stop`
<hitech95>
neggles: well i'm in another league having ipv4aas I cant use commercial routers anymore :( I'm waiting for decent cheap HW for AX. Then I'll probably build my custom AP... or Find a decent cheap unifi one to flash with openwrt.
<neggles>
U6-LR - which also happens to be nearly identical to the belinksyskin save for the lack of a switch - or wait for ipq5 to get decent support...
<neggles>
belinkinsys?
<stintel>
linkinsysbell!
<hitech95>
ha ha ha :D I'm on an aircube AC. With Openwrt. BTW talinkg about tha aircube, openwrt porting is broken I have a PR opened for moths with fixes :P
* stintel
reads 24V PoE and closes the tab
<neggles>
stintel: i cackled
<hitech95>
Dumb question about wireless configuration what is best DBDC or 4x4?
<neggles>
4x4 dual band is "better"
<hitech95>
stintel: why not poe? I love it!
<stintel>
hitech95: 24V PoE is not PoE
<neggles>
you could describe it as 4B4C
<stintel>
PoE is 802.3af/at/bt
<hitech95>
stintel: oh right... outy of standard
<stintel>
24V is non-standard crap
<neggles>
hey 24V is close enough to a standard
<neggles>
now cambium 28V
<neggles>
that's the real evil
<\x>
how useful is having bluetooth on an AP, why is mediatek touting it as a feature
<stintel>
it's very common these days
<hanetzer>
idk man. seems meh to me.
<hitech95>
neggles: I still ahve to properly understand how that passive poe works on hw level with GBE.
<stintel>
usefullness .. dunno :)
<neggles>
cambium 28V is also on the opposite set of pairs to the mikrotik/ubiquiti 24V and reverse polarity
<neggles>
you know, for reasons
<neggles>
hitech95: transformers!
<hitech95>
What I hate is that none of the ONT vendors are POE (standard or not). I have to have another power cord for those little bastards.
<neggles>
at either end of an ethernet link there are four tiny little 1:1 transformers, one on each pair
<neggles>
if you tap the center of the transformers on the device side
* hanetzer
would rather deal with another cord than nonstandard PoE
<neggles>
behold, volts
<neggles>
the only difference between 48V passive PoE and regular 802.3af PoE is whether the PSE actually checks for the right resistance before applying voltage
<hitech95>
neggles: yea I know that there are trasformers. they used to not use the pairs for the 100mbps links but now is the same but they use the traformers central taps to extract the power !?
<neggles>
hitech95: so the voltage is applied to a pair as a whole, which means the voltage differential *within one pair* is zero
<neggles>
the pairs are all isolated from each other by the transformers, which don't pass the DC through because, well, transformer
<hitech95>
got it. so it is not modulated or something it is just plain DC.
<neggles>
oh my bad
<neggles>
the center tap you tap, is on the cable side
<neggles>
not the ethernet transceiver side
<hitech95>
neggles: got it!
rua has joined #openwrt-devel
<neggles>
hitech95: the schematic for the pi cm4 io board shows it reasonably well
<neggles>
you end up with four center taps, one from each pair
<neggles>
with 2-pair PoE, one of the four taps will have +v, one will have -v
<neggles>
feed them into a bridge rectifier so you don't have to worry about the source polarity and away you go
<hitech95>
got it, now I understand how the poe etractors modules works :D That makes more sense in my head :D
<neggles>
the 4-pin PoE hat header on the pi 4 is just those 4 center taps
_0x4a6f has joined #openwrt-devel
<hitech95>
neggles: yep I know that picture very well I'm designing a carrier board for the CM4... when I'll finally get one :D
<neggles>
hehe, i have a couple they are very nice
[0x4A6F][m] has joined #openwrt-devel
<hitech95>
Is the Aircube AC DBDC? Wireless frontends are so messy. I've tried to figure it out. But having 2 antennas with 2 wireless interfaces 2x2 I suppose they are
<neggles>
but useless to me since the drivers for the PHY still don't support hardware timestamping / PTPv2
<neggles>
hitech95: if it's 2x2 and it's dual band, it's DBDC - the chipset may not be
<neggles>
ie there might be two 2x2 radios rather than one 2x2 dbdc radio
<neggles>
generally there will be two radios, single-radio dbdc is relatively recent afaik
<hitech95>
got it!
<neggles>
it makes no real difference from an "actually using the device" perspective
<hitech95>
yea, no idea if the calibration data contains this kind of information.
<hitech95>
BTW I've backodered the CM4 with wifi and EMMC lets see when it will arrive... My plan is than use an external 2x2 ampak wifi chipset for final design.
decke has quit [Quit: Leaving.]
<hitech95>
"free routers" guys with my isp should throw money to openwrt project to have a decent alternative hw/sw implementation on mtk hw nat. Dammit broadcom proprietary implementation gets to full throughput. And no commerical routers have MAP-T impelemented. nat46 gets its aroud at 40% of a gbit connection. with a mt7622
<hitech95>
does the mt7531 chip have the PPE or is only in the socs that have the MT7531 block in it?
* enyc
meeps
<enyc>
hitech95: Why oh why oh why don't we have more IPv6 in the world I wonder!
<hitech95>
enyc: IDK, my isp is v6 only since last week
<stintel>
is there any complete documentation how to pull something like that off with OpenWrt ?
<stintel>
e.g. I want an IPv6-only VLAN, that can access v4 Internet via my OpenWrt router
<stintel>
there are some packages but I have not found proper documentation
<hitech95>
stintel: you have to do a tunnel or something with openwrt. the thing is that you have to translate allt he addresses. quite similar to what MAP-E do.
<hitech95>
your openwrt wll act as a br
Gaspare has joined #openwrt-devel
<hitech95>
neggles: trunk succeded on building, I'm goint to test out my branch based on trunk. then Ill see if 21.02.0 works
<neggles>
okeydoke
<enyc>
hitech95: heh I'm keeping my /28 IPv4 + /48 IPv6 native dual stack for now thankyou-very-much =)
<hitech95>
enyc: it all depends from the ISP, if the ISP drops v4 and move to MAP-T you have to have a compatible router to do so. the only CPE capable so far is OpenWRT and the proprietary one from ISP. (broadcom HW)
minimal has joined #openwrt-devel
<\x>
i have ipv6 from my isp for like 2.5 years now
<\x>
they are dhcpv6-pd, works well
<stintel>
yeah I used to have proper v6 when I lived in Belgium still, one thing this country was good for
<\x>
but in the first month they had some sort of dual stack lite something like that, i never got that one to work properly
<stintel>
here in Bulgaria, ISPs completely ignore IPv6
<enyc>
hitech95: is the MAP-T autonegotiated via dhcpv6 or so ??
<enyc>
i.e. so router knows to do upstream IPv4 in that form, knows the IPv6 range to map to, etc etc...
<hitech95>
enyc: yep via dhcp option.
<hitech95>
i get a v6 prefix
<hitech95>
and the v4 traffic is routed thru nat46, it performs nat and transform v4 packets to v6
<hurricos>
Huh. Apparently the Okli loader is used when the default u-boot configuration is incompatible with OpenWrt for some reason (e.g. when the kernel decompresses to >8MB).
<hurricos>
I am very surprised that I never heard of Okli before. Can the Okli loader be used for powerpc / mpc85xx targets?
rua has quit [Ping timeout: 480 seconds]
<hurricos>
Ah, I see. One has to create a recipe for it, as in https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=b7013e9c4ad3b6944ac5a028d8ae9350be0859f0.
<hurricos>
I also can't find any good Okli-loader documentation, but frankly not that I've tried too hard.
<clayface>
I've run into this a few times, can't mount a directory as RO and then mount a file in that dir or a subdir as RW
<clayface>
eg, if enabling dnsmasq's TFTP server in /tmp (RO), and leaving dhcp.leases in /tmp (RW), dnsmasq won't start
rua has quit [Ping timeout: 480 seconds]
Gaspare has joined #openwrt-devel
rua has joined #openwrt-devel
<clayface>
I can't think of a workaround other than to procd_add_jail_mount_rw the dir when it contains a file that needs RW mounted. I think its not related to /tmp as mentioned in the URL
bluew has quit [Quit: Leaving]
* enyc
meeps
<dangole_>
clayface: just choose non-overlapping paths other than /tmp for leasefile and as root for the tftp server
dangole has joined #openwrt-devel
Gaspare has quit [Quit: Gaspare]
dangole_ has quit [Remote host closed the connection]
rua has quit [Ping timeout: 480 seconds]
<hurricos>
what are the possible compatibles for partitions? I know about fit images, but ..
rua has joined #openwrt-devel
<hurricos>
I'm thinking denx,split or somesuch. I can't use fit images because of u-boot, but I have a situation with a growing kernel where I'd like to make sure the kernel can grow as large as it needs into the rootfs area without sacrificing rootfs up-front
<hurricos>
ok, I have my answer basically from `find . -type f -name '*.dts' -o -name '*.dtsi' -print0 | xargs -0 grep partition@ -A 3 | grep -o compatible.* | awk '!x[$0]++;'`
<clayface>
dangole: Issue here is that a failure scenario is quite difficult to diagnose. Secondly, I wish to add support for log-facility which requires another RW mount and would increase the chance of this occurring
Borromini has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
Luke-Jr has quit [Ping timeout: 480 seconds]
danitool has joined #openwrt-devel
Luke-Jr has joined #openwrt-devel
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<zorun>
(just kidding, it's probably completely unrelated except for the name)
<Habbie>
:)
Luke-Jr has joined #openwrt-devel
fda has joined #openwrt-devel
fda- has quit [Ping timeout: 480 seconds]
test has joined #openwrt-devel
test has quit []
paper_ has quit [Quit: connection reset by purr]
paper_ has joined #openwrt-devel
paper_ has quit [Quit: connection reset by purr]
paper_ has joined #openwrt-devel
rmilecki has quit [Ping timeout: 480 seconds]
florian_ is now known as [florian]
<neggles>
hurricos: so uh
<neggles>
what I did was just merge the original dtb+kernel+initramfs+jffs2 partitions together into one called 'firmware' marked with `compatible = "denx,uimage";`