ripclap has quit [Read error: Connection reset by peer]
ripclap has joined #openwrt-devel
dansan has quit [Ping timeout: 480 seconds]
dansan has joined #openwrt-devel
dansan_ has joined #openwrt-devel
skynet2_ has quit []
dansan is now known as Guest8826
dansan_ is now known as dansan
valku has quit [Quit: valku]
sorinello has joined #openwrt-devel
suraj has joined #openwrt-devel
n3ph has joined #openwrt-devel
sorinello has quit [Quit: Leaving]
sorinello has joined #openwrt-devel
n3ph has quit [Ping timeout: 480 seconds]
goliath has joined #openwrt-devel
Guest8826 has quit []
Forst has joined #openwrt-devel
dansan has quit [Quit: Konversation terminated!]
suraj has quit [Remote host closed the connection]
dansan has joined #openwrt-devel
ddejean_ has joined #openwrt-devel
ddejean has quit [Ping timeout: 480 seconds]
ddejean_ has quit [Quit: leaving]
ddejean has joined #openwrt-devel
KGB-0 has joined #openwrt-devel
Ycarus has quit [Ping timeout: 480 seconds]
robimarko has joined #openwrt-devel
Ycarus has joined #openwrt-devel
noltari_ has quit [Read error: Connection reset by peer]
noltari has joined #openwrt-devel
gromero has quit [Ping timeout: 480 seconds]
vincejv- has joined #openwrt-devel
vincejv is now known as Guest8884
vincejv- is now known as vincejv
Guest8884 has quit [Ping timeout: 480 seconds]
Ycarus has quit [Ping timeout: 480 seconds]
anyn has joined #openwrt-devel
anyn has quit []
noahm has quit [Quit: reboot...]
Ycarus has joined #openwrt-devel
noahm has joined #openwrt-devel
gromero has joined #openwrt-devel
gromero has quit [Ping timeout: 480 seconds]
skynet2 has joined #openwrt-devel
skynet2_ has joined #openwrt-devel
skynet2 has quit [Ping timeout: 480 seconds]
efahl is now known as Guest8901
efahl has joined #openwrt-devel
Guest8901 has quit [Ping timeout: 480 seconds]
gromero has joined #openwrt-devel
gromero has quit [Read error: Connection reset by peer]
minimal has joined #openwrt-devel
gromero has joined #openwrt-devel
valku has joined #openwrt-devel
valku has quit []
valku has joined #openwrt-devel
drew32 has joined #openwrt-devel
<drew32>
trying to fix this issue: mtd: partition "rootfs" doesn't start on an erase/write block here is my boot log: https://textbin.net/dw9yba3y05
<drew32>
Wondering if I should add padding between the kernel and squashfs
<KanjiMonster>
drew32: openwrt (by default) uses a r/o rootfs, so its fine to not start at an erase/write block. Only the overlay partition rootfs_data needs to do so
<drew32>
That's what I thought. If you have a moment take a look at the boot log. I get jffs errors when it attempts to mount rootfs_data
<drew32>
this error: jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found ad
<drew32>
even if I manually try to mount it I get those errors too
<KanjiMonster>
that probably means that your image is missing a EOF marker to tell jffs2 that this partition needs to be erased
<KanjiMonster>
usually the rootfs has special markers at the end (that will then become the start of rootfs_data) that indicate to jffs2 that the partition is not formatted and requires so
<drew32>
hmm, is that something that can be set in menuconfig or kernel_menuconfig?
<KanjiMonster>
no, that would be part of your image commands, see include/image-commands.mk / Build/pad-rootfs
<KanjiMonster>
drew32: you shouldn't/can't hardcode your kernel length in the dts partition table, as it will change with every kernel update (or even when changing patches / kernel options)
<KanjiMonster>
you probably need some kind of custom partition parser that figures out the kernel length (and thus rootfs offset) from some kind of image header, or nvram variable, etc
<KanjiMonster>
how did the original firmware do it?
mko has quit [Remote host closed the connection]
mko has joined #openwrt-devel
<drew32>
orginial firmware used this: [ 6.260000] Creating 10 MTD partitions on "bcmsflash":
<drew32>
but couldn't find information on bcmsflash. Have worked with the bcm47xx parser, but it fails to detect partitions. That's why I went for manual
<drew32>
Since this device won't flash an image with a trx header, the bcm47xx parser cannot figure things out it seems
<KanjiMonster>
drew32: do you by chance have a vendor gpl tarball?
<drew32>
I don't I searched but meru seems to keep them behind a login
<KanjiMonster>
you could try to request the sources via a contact form or email anyway
<drew32>
Maybe. Or I might just have to modify the bcm47xx parser to use something besides trx to identify
mko has quit [Read error: Connection reset by peer]
mko has joined #openwrt-devel
n3ph has quit [Ping timeout: 480 seconds]
lucenera7 has quit [Read error: Connection reset by peer]
lucenera7 has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
drew32 has quit [Remote host closed the connection]
n3ph has joined #openwrt-devel
lucenera7 has quit [Read error: Connection reset by peer]
lucenera7 has joined #openwrt-devel
lucenera7 has quit [Read error: Network is unreachable]
lucenera7 has joined #openwrt-devel
goliath has joined #openwrt-devel
n3ph has quit [Ping timeout: 480 seconds]
lucenera7 has quit [Read error: Connection reset by peer]
<mrnuke>
Is there an official developer documentation for ucode? All I could find is https://ucode.mein.io/, which seems woefully out of date or incomplete. Is that the right starting place?
dansan has quit [Ping timeout: 480 seconds]
<schmars[m]>
mrnuke: yes that is the docs generated from ucode.git
Sawzall has quit [Read error: Connection reset by peer]
Sawzall has joined #openwrt-devel
Sawzall has quit [Read error: Connection reset by peer]
<mrnuke>
schmars[m]: Hmm. The mein.io doc doesn't talk about the 'case' statement. It only documents the 'get_first()' member of uci context. Are these omissions intended?
<schmars[m]>
i dont think they're intended, it's just incomplete or stuff changed
<schmars[m]>
pretty sure PRs are welcome :-)
<schmars[m]>
or just an issue with your observations is probably helpful too
Sawzall has joined #openwrt-devel
nixuser has quit [Ping timeout: 480 seconds]
lucascastro has quit [Remote host closed the connection]
lucascastro has joined #openwrt-devel
<mrnuke>
I am trying to find the networking device named `br-lan` with the uci ucode module. Is there an example on how to do this other than getting the entire config, and looping through all "@device[]" sections ?
<schmars[m]>
if its section is named you can do `uci.get_first("network", "device", "sectionname")`
<mrnuke>
get_first() gives me the first "device" section. Is there a .get_next() iterator for follow-on devices? It seems ithe only way to go through then is .get(), and looping through the object as if it were a dictionary
ScrewDriver1337 has quit [Ping timeout: 480 seconds]