<Namidairo> rsalvaterra: I don't remember adding any mediatek-bmt tags in the dts...
<dangole> mangix: if your device worked well previously there won't be any difference. however, devices which actually do have some bad blocks in the area where the kernel is stored will now have working sysupgrade (which previously couldn't work because on mt7621 target there was no support for BMT/BBT in kernel)
<aparcar> mangix: I think I fixed your bug
<mangix> aparcar: it's Pepe's, not mine
<aparcar> I mean the CI stuff
pmelange has left #openwrt-devel [#openwrt-devel]
<mangix> right
<rsalvaterra> dangole: Mine has a bad block, but falls inside the ubi partition.
<mangix> Bad eraseblock 709 at 0x0000058a0000
<mangix> wonder where that is
<rsalvaterra> Relevant dmesg section: https://0bin.net/paste/CiuKfCzP#fonQXL6lc09kMLcRky44ouovBR1jioQ+8byy4FRCG+M
<Namidairo> I always wondered why all those toshiba nand units shipped with bad blocks
<mangix> rsalvaterra: strange. i don't get those ECC errors
<mangix> uhhh, WAT
<rsalvaterra> Namidairo: It's NAND. It may or may not have bad blocks. Depends on how lucky you are.
<mangix> oh I see
<mangix> it's the RAM that's 256MB
<Namidairo> it's weird, I didn't really see anyone report bad blocks until people starting pointing out the vendor changed
<rsalvaterra> mangix: In my case, both RAM and NAND are 128 MiB.
<Namidairo> as long as it's handled properly in the end, it's fine
<mangix> at this point I'm wondering if I need to edit my DTS based on the ea7xxx one
<mangix> ea7xxx one has alt_kernel and alt_rootfs whereas I just have alt_firmware
<mangix> dangole: can you review https://github.com/openwrt/openwrt/pull/4470 ?
<mangix> rsalvaterra: what device is that btw?
<rsalvaterra> mangix: Redmi AC2100
<dangole> mangix: not recently, but i had a look some months ago
<mangix> OK
<dangole> mangix: and looking at it again: yes, this should have BBT/BMT with ubi-region excluded as well.
<rsalvaterra> Namidairo: But it could be much worse… at least it's SLC NAND.
<mangix> dangole: I noticed the ea7xxx dts has alt_kernel and alt_rootfs. Any reason to also adapt it to the E7350? It currently just has alt_firmware.
<Namidairo> they usually spec the first bit of the flash as clean though
<Namidairo> so the crucial bits like bootloader will usually be fine.
<dangole> mangix: using automated mtd-splitters on a single firmware partition is nicer than hard-coding the sizes, as kernel-size may need to be increased in future. just not always possible, due to vendor loader limitations.
<Namidairo> half the loaders having broken lzma on that platform does not help
<dangole> Namidairo: I also saw excessive forward error correction for SPL on NAND, followed by having everything in UBI (e.g. oxnas burned-in romloader uses x8 FEC). in that way, no guarantees are needed.
<mangix> dangole: right. I noticed nbd's commit applies bbt to both the kernel and alt_kernel. So for this router, either apply it to the kernel only, or for both kernel and alt_kernel. no idea if the latter needs to be separated out in dts from alt_firmware or just referenced with offsets.
<dangole> mangix: you should store rootfs in UBI as well, so it's better to just have alt_kernel in first place, and have both kernel and alt_kernel (and uboot-env, ...) covered by BBT.
<dangole> mangix: sorry, that was confused. looking at the dts, this is really just naming
<dangole> mangix: so on this board, 0x0-0x580000 and 0x3180000-$end_of_flash should be covered by BBT/BMT, skipping only the UBI area and assuming OpenWrt will always be installed into primary boot slot, leaving vendor firmware in alt_firmware slot
<mangix> hmmm OK
dangole has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
cmonroe has quit [Ping timeout: 480 seconds]
dangole has quit [Remote host closed the connection]
cmonroe has joined #openwrt-devel
Piraty has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
piraty_ has quit [Ping timeout: 480 seconds]
danitool has quit [Ping timeout: 480 seconds]
victhor has quit [Remote host closed the connection]
cmonroe has quit [Ping timeout: 480 seconds]
valku has joined #openwrt-devel
goliath has joined #openwrt-devel
kb1sph has joined #openwrt-devel
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #openwrt-devel
valku has quit [Quit: valku]
ephemer0l has joined #openwrt-devel
ecloud has quit [Ping timeout: 480 seconds]
ecloud has joined #openwrt-devel
nitroshift has joined #openwrt-devel
hurricos has quit [Ping timeout: 480 seconds]
hurricos has joined #openwrt-devel
mattytap has joined #openwrt-devel
mattytap__ has joined #openwrt-devel
mattytap_ has quit [Ping timeout: 480 seconds]
Grommish has joined #openwrt-devel
mattytap_ has joined #openwrt-devel
mattytap has quit [Ping timeout: 480 seconds]
mattytap_ has quit []
mattytap__ has quit [Ping timeout: 480 seconds]
danitool has joined #openwrt-devel
<xback> is it still valid?
Grommish_ has joined #openwrt-devel
Grommish has quit [Ping timeout: 480 seconds]
arifre has quit [Remote host closed the connection]
<rsalvaterra> xback: I'm carrying it in my tree, yes. :)
<rsalvaterra> I haven't done any performance measurements, though. But mangix wrote the initial patch, maybe he has more details.
<rsalvaterra> We wanted to send this patch upstream, but getting performance number would be pretty much impossible, since the upstream driver is different from ours (and doesn't actually work, from what I've been told).
<mangix> the upstream driver works but only with ar9331 and other similar old SoCs
<mangix> none of which I have
<rsalvaterra> Anyway, I can't imagine how a patch to remove false sharing of cache lines would *hurt* performance. :P
<mangix> i could
<rsalvaterra> mangix: Right, I only have AR9344 and QCA9563.
<rsalvaterra> mangix: Yes, if the number of cache lines used would increase.
<rsalvaterra> Data cache pressure.
<mangix> making the struct smaller just saves RAM size
<mangix> i don't think the full ag71xx_int_stats struct is used
Grommish has joined #openwrt-devel
pmelange has joined #openwrt-devel
Grommish_ has quit [Ping timeout: 480 seconds]
srslypascal is now known as Guest549
srslypascal has joined #openwrt-devel
pmelange1 has joined #openwrt-devel
pmelange1 has quit []
pmelange1 has joined #openwrt-devel
pmelange has quit [Quit: Leaving.]
pmelange has joined #openwrt-devel
Guest549 has quit [Ping timeout: 480 seconds]
pmelange1 has quit [Ping timeout: 480 seconds]
floof58 has quit [Read error: No route to host]
floof58 has joined #openwrt-devel
pmelange has left #openwrt-devel [#openwrt-devel]
dangole has joined #openwrt-devel
Acinonyx_ has joined #openwrt-devel
Acinonyx has quit [Ping timeout: 480 seconds]
GNUmoon has quit [Ping timeout: 480 seconds]
GNUmoon has joined #openwrt-devel
<nitroshift> mangix, i closed the issue with transmission-daemon, it's wolfssl's fault
<nitroshift> it works ok with openssl / polarssl
gladiac is now known as Guest551
gladiac has joined #openwrt-devel
Guest551 has quit [Ping timeout: 480 seconds]
floof58_ has joined #openwrt-devel
floof58 has quit []
Grommish_ has joined #openwrt-devel
Grommish has quit [Ping timeout: 480 seconds]
Grommish_ has quit [Ping timeout: 480 seconds]
Grommish has joined #openwrt-devel
guidosarducci has joined #openwrt-devel
guidosarducci_ has quit [Ping timeout: 480 seconds]
Grommish_ has joined #openwrt-devel
Acinonyx has joined #openwrt-devel
Grommish has quit [Ping timeout: 480 seconds]
Acinonyx_ has quit [Ping timeout: 480 seconds]
Acinonyx_ has joined #openwrt-devel
Acinonyx has quit [Ping timeout: 480 seconds]
rua has quit [Remote host closed the connection]
dedeckeh has joined #openwrt-devel
rua has joined #openwrt-devel
Grommish has joined #openwrt-devel
Grommish_ has quit [Ping timeout: 480 seconds]
nitroshift has quit [Quit: Gone that way --->]
victhor has joined #openwrt-devel
danitool has quit [Ping timeout: 480 seconds]
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
tohojo has joined #openwrt-devel
danitool has joined #openwrt-devel
ecloud has quit [Ping timeout: 480 seconds]
ecloud has joined #openwrt-devel
Grommish has quit [Read error: Connection reset by peer]
Tapper has joined #openwrt-devel
<aparcar> [florian]: ideas on how we could debug the usage of an external toolchain together? I'd be delighted to speed up CI builds
<stintel> ugh. next issue. when booting from flash: Uncompressing Kernel Image ... lzma compressed: uncompress error 1
<stintel> if I change the KERNEL_LOADADDR from mt7621 default (0x80001000) to what OEM uses (0x81001000), that lzma error disappears, but the kernel doesn't boot.
<stintel> also with KERNEL_LOADADDR 0x81001000 the initrd also no longer boots
danitool_ has joined #openwrt-devel
danitool has quit [Read error: Connection reset by peer]
danitool_ has quit [Ping timeout: 480 seconds]
<hgl> jow, could you shed some light on the valid MTU range for an XFRM interface? I've no idea about it, so the PR is stuck now: https://github.com/openwrt/luci/pull/5642#discussion_r782979496
rua has quit [Remote host closed the connection]
rua has joined #openwrt-devel
<jow> hgl: so 68..1500
valku has joined #openwrt-devel
danitool_ has joined #openwrt-devel
<stintel> seems like I can make it work with lzma-loader, based on this forum post: https://forum.openwrt.org/t/compile-ramips-with-data-address-at-0x81001000-instead-of-0x80001000/97379
<stintel> do we have any documentation about lzma-loader, what it does and why that is needed in some cases?
danitool_ has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<dangole> stintel: i don't think there is any documentation for that. it's basically just an intermediate loader you can use in case of stock loader being to broken to load kernel. it requires memory-mapped access to the flash and decompresses kernel and starts it.
SamantazFox has quit [Remote host closed the connection]
SamantazFox has joined #openwrt-devel
<stintel> it would help if someone who really understands all of that stuff does a detailed writeup about it ... I found that now by trial and error but I have very little clue about why it's needed
<stintel> and if there are possibly cleaner ways to solve it
<stintel> I had to change LZMA_TEXT_START which isn't even set from a variable, so it's impossible to override on device level
<stintel> so I'm having a hard time believing this is the only way to fix the problem, otherwise that LZMA_TEXT_START would be set from a variable already
pmelange has joined #openwrt-devel
pmelange has left #openwrt-devel [#openwrt-devel]
minimal has joined #openwrt-devel
YSC has quit [Quit: ZNC - https://znc.in]
<dangole> LZMA_TEXT_START is the location in RAM (ie. somewhere in memory-mapped SPI-NOR area in phys ram) where the loader will start decompressing from. that depends on the flash layout, ie. where you are writing the loader and subsequent compressed data.
<dangole> stintel: vendors are never shy to introduce unbelievable amounts of useless complexity in the boot firmware (such as hard-coded size limits or stupid load address in ram with not a lot of space above) to break it for any but their own use-case.
cmonroe_ has joined #openwrt-devel
rua1 has joined #openwrt-devel
rua has quit [Remote host closed the connection]
cmonroe has joined #openwrt-devel
cmonroe_ has quit [Ping timeout: 480 seconds]
<f00b4r0> stintel: IIRC (I last looked at that code last year) lzma_loader reads an lzma-compressed kernel from LZMA_TEXT_START and expands it from LOADADDR, sets up cmdline and jumps
<f00b4r0> stintel: then there are several incarnations of it living in various subtargets, so your mileage may vary
<f00b4r0> I had written something about it, let's see if I can find it again
<f00b4r0> in-between I may have forgotten a step where it first moves the compressed data in place before uncompressing
victhor has quit [Remote host closed the connection]
<f00b4r0> stintel: I can't find my notes. If you have a specific question feel free to ask it may jog my memory.
<f00b4r0> also I don't remember LZMA_TEXT_START belonging to mapped SPI, IIRC everything is in RAM
<Slimey> where are the wpa_supplicant logs stored?
<dwfreed> they aren't; you can read them with logread
<dwfreed> openwrt does not write logs to disk because it would quickly wear out the flash on most consumer devices
<PaulFertser> Slimey: moreover, wpa_supplicant is compiled with most messages stripped out by default.
<PaulFertser> Slimey: so even with elevated debug level you won't be getting more info.
srslypascal is now known as Guest573
srslypascal has joined #openwrt-devel
<rmilecki> stintel: i can only answer why we need that
<rmilecki> stintel: we need LZMA compression as that is more optimal
<rmilecki> i should probably say: it results in smaller kernel size
<rmilecki> not every bootloader supports LZMA
<rmilecki> do we have LZMA loader
<stintel> ok that's the most obvious case, but in my case I had to use it work around an LZMA decompression error
<rmilecki> LZMA loader is small enough that it doesn't need to be LZMA compressed
<rmilecki> so we use LZMA loader to allow LZMA compressed kernel
<stintel> appreciate all the replies by the way
<rmilecki> stintel: some bootloaders have broken LZMA support - they e.g. can't handle big LZMA compressed kernels
<rmilecki> maybe that's the case
<rmilecki> ?
<stintel> see commit message of https://git.openwrt.org/e9d6a69f
<rmilecki> stintel: can't help with such details
<rmilecki> stintel: hauke understands those offsets
Guest573 has quit [Ping timeout: 480 seconds]
<stintel> thanks!
<rmilecki> (sorry hauke :p )
<stintel> :P
<stintel> ok I'm out for the weekend, please do keep responding and/or link me to relevant documentation
<rmilecki> stintel: check https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=4cd97e4760899172a1d6339ea5644992775e504e AND two commits I referenced in that commits body
<stintel> once I understand all of that shit I'll try to compile some guide
<f00b4r0> stintel: there are two decompression stages happening in that log
<f00b4r0> if I read it correctly
<f00b4r0> the first decompresses to 0x81001000, and loads that, which seems to be a second lzma-loader stage, which decompresses to 0x80001000 and loads that.
<f00b4r0> and that looks wrong, obviously.
<stintel> what log are you talking about?
<f00b4r0> s/in that log/in the log posted in the first message of the forum/
<stintel> ah
goliath has quit [Quit: SIGSEGV]
<f00b4r0> the hint is "OpenWRT kernel loader" being shown after "Starting kernel..." from the bootloader
<f00b4r0> I doubt a double lzma is a Good Thing™
<f00b4r0> :)
<f00b4r0> and in fact I'm right
<f00b4r0> see KERNEL := kernel-bin | append-dtb | lzma | loader-kernel | lzma | uImage lzma
<f00b4r0> that's quite "odd", to say the least
<stintel> I had to do something similar to get my device to boot
<stintel> KERNEL := kernel-bin | lzma | loader-kernel | lzma | fit lzma $$(KDIR)/image-$$(firstword $$(DEVICE_DTS)).dtb
<f00b4r0> can't it load plain elf or uimage?
<f00b4r0> somehow I fail to see how having multiple lzma stages could be a good idea
<stintel> it uses FIT images and I couldn't find an example of that combination
<stintel> but just lzma between kernel-bin and loader-kernel didn't work, nor did it work with just lzma between loader-kernel and fit-lzma
<stintel> I'm sure it's wrong, but I couldn't find any other way to get the thing to boot from flash so far
<stintel> hence my search for proper documentation about all this
<f00b4r0> kernel-bin | lzma | fit lzma wouldn't work?
<stintel> that results in the errors I wrote in the commit message of https://git.openwrt.org/e9d6a69f
hexagonwin has joined #openwrt-devel
hexagonwin has quit [Remote host closed the connection]
<f00b4r0> i see
<f00b4r0> so as rmilecki suggested, it's probable the bootloader can't deal with big lzma-compressed kernels
<stintel> but it can in the tftpboot case
<stintel> which only adds to the confusion
<f00b4r0> well, I'm not surprised. Though I've seen the opposite more often (not working tftboot, working flash boot). tftp boot process manages memory differently
<stintel> oh, gotta run, friends' flight about to land early
<f00b4r0> but I'm surprised to see lzma-loader itself lzma-compressed
<f00b4r0> ok
<f00b4r0> ttyl
<stintel> suddenly appeared on my piaware :P
<stintel> I think maybe fit lzma ... doesn't work if the lzma-loader isn't lzma compressed
<f00b4r0> yes of course it wouldn't
<stintel> not sure if can drop that lzma
<stintel> from fit
<stintel> I don't read Makefile fluently but to me it seemed that compression argument is non-optional
<f00b4r0> I'm not fit-fluent tbh :)
<aparcar> dangole: can we add tags to uclient etc? some alpine dev would like to add those packages to their repositories and would prefer tags rather than hashes
<f00b4r0> stintel: git grep shows a "fit none"
<stintel> indeed
<stintel> KERNEL := kernel-bin | lzma | loader-kernel | fit none $$(KDIR)/image-$$(firstword $$(DEVICE_DTS)).dtb
<f00b4r0> anyway, I'm sure there are people more helpful than I for dealing with the shenanigans of fit images. I confess my ignorance here
<stintel> will try that
<f00b4r0> I just think that double lzma is not a great idea (it's bound to be slow and non-optimal)
<[florian]> aparcar: was planning on looking into it this weekend
<aparcar> [florian]: thank you
<dangole> aparcar: i guess we could just tag the version which comes with each official OpenWrt release. it's a bit of work, we technically don't really need it and it's yet another aspect which needs to be maintained constantly. if we start to do that, we should use the tags also in our package builds as otherwise they will be subject to bitrot...
<Slimey> PaulFertser nm got it
<aparcar> dangole: I think it's a better approach than using the current "date" based appraoch
<aparcar> but I can also ask that on the ML and see what people think
<dangole> aparcar: we can use the date as tag name, that would at least eliminate the additional version number
<aparcar> seems a bit awkward...
<aparcar> dangole: do you mind briefly joining alpine-devel and discuss that with me and Aridiane?
Tapper has quit [Ping timeout: 480 seconds]
danitool has joined #openwrt-devel
dev1ce is now known as W
W is now known as Guest580
Guest580 has quit [Quit: ZNC - https://znc.in]
device has joined #openwrt-devel
device is now known as dev1ce
Tapper has joined #openwrt-devel
<jow> aparcar: semantic tags are additional work
<dwmw2_gone> jow: Please could I have ssh access to git.openwrt.org ?
<jow> dwmw2_gone: umh sure, I though you do already have it
<dwmw2_gone> perhaps I'm Doing It Wrong
<jow> no, there's indeed no key
<dwmw2_gone> $ git pull dwmw2@git.openwrt.org:/somewhere
<dwmw2_gone> dwmw2@git.openwrt.org: Permission denied (publickey).
<jow> any preferred key?
<jow> or shall I add all of them?
<dwmw2_gone> All please; I keep separate keys on separate machines (laptop, etc.)
<dwmw2_gone> Easier to revoke if they're separate :):
<jow> should be done
<dwmw2_gone> remote: /usr/bin/env: ‘python’: No such file or directory
<dwmw2_gone> To git.openwrt.org:openwrt/openwrt
<dwmw2_gone> error: failed to push some refs to 'git.openwrt.org:openwrt/openwrt'
<dwmw2_gone> ! [remote rejected] master -> master (pre-receive hook declined)
<jow> meh, I hate python
<jow> please retry
<dwmw2_gone> remote: Traceback (most recent call last):
<dwmw2_gone> remote: if line.startswith('The sender domain has a DMARC Reject/Quarantine policy'):
<dwmw2_gone> remote: TypeError: startswith first arg must be bytes or a tuple of bytes, not str
<dwmw2_gone> remote: File "/home/git/repositories/openwrt/openwrt.git/hooks/pre-receive.h00-check-commits", line 14, in <module>
<dwmw2_gone> To git.openwrt.org:openwrt/openwrt
<dwmw2_gone> ! [remote rejected] master -> master (pre-receive hook declined)
<dwmw2_gone> error: failed to push some refs to 'git.openwrt.org:openwrt/openwrt'
<dwmw2_gone> [dwoodhou@i7 master]$
<jow> sigh
<jow> hipster crap
<jow> and again please
<dwmw2_gone> remote: *** no recipients configured so no email will be sent
<dwmw2_gone> remote: *** for 'refs/heads/master' update 0765466a42f46f7357e260866a4284ed567bb7ad->557067d9b119ffe7f1e2029e0086491de105dfbc
<dwmw2_gone> remote: 0765466a42..557067d9b1 master -> master
<dwmw2_gone> remote: To github.com:openwrt/openwrt.git
<dwmw2_gone> remote: To github.com:lede-project/source.git
<dwmw2_gone> remote: 0765466a42..557067d9b1 master -> master
<dwmw2_gone> To git.openwrt.org:openwrt/openwrt
<dwmw2_gone> 0765466a42..557067d9b1 master -> master
<dwmw2_gone> Has worked; not sure if you care about the messages.
<dwmw2_gone> Thanks
<jow> fine
<dwmw2_gone> dangole: ↑ that was the mSATA support for U7623 fwiw
<dangole> dwmw2_gone: did you test the latest iteration of the patch series consolidating dtsi+dts to a single dts and unifying the board-name/compatible-string?
svlobanov has joined #openwrt-devel
danitool has quit [Ping timeout: 480 seconds]
<svlobanov> hi. Is there any test.sh example for CI? I can't find any package with test.sh script as example
<jow> svlobanov: the packages feed contains quite some test.sh examples
<f00b4r0> jow: I'm curious: do we have a preferred way to bundle an existing backup.tar.gz with an image created with imagebuilder?
<jow> f00b4r0: unpack it somewhere and pass FILES=backup/root/dir/
<f00b4r0> ok, that's what I suspected. The issue I see is possible snafu with file ownership
<svlobanov> jow: thanks. that was symlink issue with find...
<jow> f00b4r0: hm yes, entirely possible. Afair the image building routines naively clamp stuff to 755 / 644
<f00b4r0> jow: I'm tempted to stuff it somewhere in FILES (maybe root/backup.tar.gz) and unpack on device, kinda like what luci probably does
<f00b4r0> not ideal, but probably more robust
<f00b4r0> i wish there was a way to hijack the system that restores from rootfs_data stub :)
<jow> f00b4r0: see package/base-files/files/lib/preinit/80_mount_root
<jow> f00b4r0: likely sufficient to embed a "sysupgrade.tgz" at root
<f00b4r0> ah ha! Indeed!
<f00b4r0> I'll test that. Thanks for pointing this out!
<jow> or even add a custom /lib/preinit/NN_whatever hook that simply massages permissions
<f00b4r0> I think 80_mount_root provides exactly what I need with no fuss at all. No need to reinvent the wheel :)
<f00b4r0> the only downside is a bit of wasted space on the flash but I can live with that
svlobanov has quit [Remote host closed the connection]
svlobanov has joined #openwrt-devel
victhor has joined #openwrt-devel
<aparcar> jow: we found a different solution thank you
dangole_ has joined #openwrt-devel
dangole has quit [Remote host closed the connection]
dedeckeh has quit [Quit: Page closed]
dedeckeh has joined #openwrt-devel
dangole_ is now known as dangole
danitool has joined #openwrt-devel
danitool has quit [Ping timeout: 480 seconds]
danitool has joined #openwrt-devel
kenny has joined #openwrt-devel
victhor has quit [Remote host closed the connection]
danitool has quit [Ping timeout: 480 seconds]
dedeckeh has quit [Remote host closed the connection]
danitool has joined #openwrt-devel
danitool has quit [Ping timeout: 480 seconds]
<hurricos> the bootloader is on a soic-16
<hurricos> it's an LS1043
<hurricos> :breathing heavily:
<hurricos> :breathing VERY heavily:
<Habbie> can i get subtitles to the heavy breathing? :)
<hurricos> This is how I feel when I see vendors I hate using hardware I love that doesn't come with cert chains in bootrom
<Habbie> haha
<hurricos> but also
<hurricos> what is that MicroSemi SmartFusion2 MS2005 FPGA doing on the board?
<Habbie> ohh
<hurricos> It's Microsemi so
<Habbie> so
<hurricos> it's one of those vendors that actually cares
<hurricos> wait, I'm thinking of Microchip
<hurricos> wait, it was microchip this whole time. Yeah, I stand where I last spoke
<hurricos> Oh, it's possible that FPGA isn't used for any sort of offloading but just as a hardware component?
<owrt-snap-builds> Build [#424](https://buildbot.openwrt.org/master/images/#builders/61/builds/424) of `arc770/generic` completed successfully.
<Habbie> it's fpga, could be anything
<hurricos> true.
dansan has quit [Ping timeout: 480 seconds]
<hurricos> actually, now that I think, I'm not 100% sure if the Layerscape is booting off of that soic16 or if that's for the FPGA
<hurricos> also the image shows what appears to be ... is that an in-built chip socket on page 17?
<hurricos> right above the FPGA?
<karlp> do you reckon the big gap around U9 the flash chip is leaving space for a test clip for production programming?
<Habbie> page 17, or as my pdf reader calls it, 8
cmonroe has quit [Read error: Connection reset by peer]
<hurricos> lol @habbie
<hurricos> karlp: just in general this board is looking very dev-friendly
<hurricos> I mean. I might be mistaken about low-end LS chips all being cert-chain-free
<slh> the fpga would scare me ;)
<slh> who knows how it's related to the rest of the hardware
<hurricos> well, you can always take a pinout. Given the location I almost wonder if it's being used as a PCIe switch or ... something. hmmmmmmm
<hurricos> no, I doubt it, LS has enough on its own
<hurricos> hopefully the board boots from the clippable SPI
dansan has joined #openwrt-devel
<hurricos> if it does I'll see if I can compile a bootloader, should be simpler given it's so mature
<hurricos> assuming Meraki doesn't just
<hurricos> you know
<hurricos> let you
<hurricos> as they do with all other MX's
danitool has joined #openwrt-devel
cmonroe has joined #openwrt-devel
vchrizz1 has joined #openwrt-devel
vchrizz has quit [Read error: Connection reset by peer]
danitool has quit [Ping timeout: 480 seconds]
victhor has joined #openwrt-devel
awgh has joined #openwrt-devel
awgh__ has joined #openwrt-devel
awgh_ has quit [Ping timeout: 480 seconds]
awgh has quit [Ping timeout: 480 seconds]
Acinonyx has joined #openwrt-devel
Acinonyx_ has quit [Ping timeout: 480 seconds]