<rsalvaterra>
Either way, parsing by driver name is borderline insane. How is that even possible? What happens if another driver comes along which matches the same PCI IDs?
<dangole>
I also didn't know that even works. Hopefully we don't use that all over that target...
<rsalvaterra>
dangole: I… grepped. It's the majority.
<dangole>
rsalvaterra: kinda makes me hope that this is not the cause...
<rsalvaterra>
dangole: If it's not the cause, I'll just have to keep digging…
<rsalvaterra>
… either until I find the cause, or until someone less clueless beats me to the solution. :P
<dangole>
grift: just tried the selinux 3.2 update on my Linksys E8450, everything works like a charm so far
<dangole>
grift: two small things, probably related to mount_root/fstools changes, but everything works anywhere, apparently: https://termbin.com/waxx
<pinkunicorn>
tmn505, hello iv been trying to get your openwrt dvb packages to work with current openwrt and its beyond my abilities!
<pinkunicorn>
tmn505, i was wondering if you have any plans on getting your packages to work with current stable openwrt?
<guidosarducci>
rsalvaterra: are you planning to upstream that "limits.h" patch for libbpf? Although I couldn't reproduce your build issue, it should probably still get submitted. I was about to send this one before you posted yours: https://github.com/guidosarducci/iproute2/commits/master-fix-bpfglue-limits
<rsalvaterra>
guidosarducci: I don't know… I thought about it, but I don't feel comfortable submitting a correction for an issue only I'm seeing. Feels like a hack to me… :/
<guidosarducci>
rsalvaterra: I looked at it carefully, and it does seem like an upstream oversight but, yes, I'd like to know it's reproducible too.
<guidosarducci>
rsalvaterra: maybe when the build system issues stabilize you can try again and see if it hits you?
swalker has quit [Remote host closed the connection]
swalker has joined #openwrt-devel
dansan has joined #openwrt-devel
victhor has quit [Ping timeout: 265 seconds]
rsalvaterra has quit [Ping timeout: 240 seconds]
rsalvaterra has joined #openwrt-devel
rsalvaterra has quit [Ping timeout: 260 seconds]
kontaxis has quit [Remote host closed the connection]
pine127 has quit [Remote host closed the connection]
kontaxis has joined #openwrt-devel
pine127 has joined #openwrt-devel
hbug___ has joined #openwrt-devel
hbug__ has quit [Ping timeout: 268 seconds]
weijie has joined #openwrt-devel
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
weijie has quit [Quit: Ping timeout (120 seconds)]
tobleminer-tSYS has quit [Quit: AS4242423214]
tobleminer-tSYS has joined #openwrt-devel
_whitelogger has joined #openwrt-devel
pinkunicorn has quit [Quit: Leaving]
dangole has quit [Remote host closed the connection]
jmv09 has joined #openwrt-devel
jmv09 has quit [Ping timeout: 240 seconds]
rmilecki has joined #openwrt-devel
tchebb_ has joined #openwrt-devel
tchebb has quit [Ping timeout: 260 seconds]
tchebb_ is now known as tchebb
javi404 has quit [Quit: javi404]
javi404 has joined #openwrt-devel
Acinonyx has joined #openwrt-devel
Acinonyx_ has quit [Ping timeout: 264 seconds]
Acinonyx_ has joined #openwrt-devel
Acinonyx has quit [Ping timeout: 245 seconds]
dedeckeh has joined #openwrt-devel
black_ant has joined #openwrt-devel
black_ant has joined #openwrt-devel
ivanich has joined #openwrt-devel
Acinonyx has joined #openwrt-devel
Acinonyx_ has quit [Ping timeout: 264 seconds]
LoopHoldYoaBrown has quit [Quit: ZNC - http://znc.in]
Rene__ has quit [Remote host closed the connection]
rsalvaterra has joined #openwrt-devel
ivanich has quit [Quit: Konversation terminated!]
ivanich has joined #openwrt-devel
Rene__ has joined #openwrt-devel
LoopHoldYoaBrown has joined #openwrt-devel
<grift>
is stdowa a bot? do other package maintainers also get e-mail as soon as there is a new upstream version available for packages they maintain?
<grift>
dont get me wrong, i appreciate the reminders ... just wondering because the mails seem generic
<PaulFertser>
A bot created and maintained by a living person :)
<grift>
yes ok i should say a script
<grift>
o well that was me hoping anyone actually cared :P
Borromini has joined #openwrt-devel
<rsalvaterra>
I can't believe I had to do a TFTP recovery of the RM2100.
<PaulFertser>
grift: programmers care by creating caring programs :)
Tost has joined #openwrt-devel
ivanich has quit [Quit: Konversation terminated!]
ivanich has joined #openwrt-devel
<Borromini>
rsalvaterra: how so? what happened?
<rsalvaterra>
Borromini: Updated the image, no DHCP. Defined a static IP, tried to log in… connection reset by peer. Fail-safe boot, static IP, tried to log in again… connection reset by peer.
<rsalvaterra>
(╯°□°)╯︵ ┻━┻
<jow>
rsalvaterra: tried IPv6 link local?
<rsalvaterra>
jow: No, but the router itself was accessible, responded to ping. But for some reason dropbear f****d right off.
<jow>
ah ok
<rsalvaterra>
jow: This all started because current master stopped reading the mt76 EEPROM.
<rsalvaterra>
I was testing master 5.10 and I noticed the problem (invalid MAC addresses and basically unusable Wi-Fi due to missing caldata).
<rsalvaterra>
"Oh, 5.10 needs more baking on ramips, let's revert to 5.4", I thought.
<rsalvaterra>
I was pretty much shocked to discover I started having the same problem with 5.4.
<rsalvaterra>
I was going to try dangole's suggestion of matching the devices in the device tree by PCI ID, not driver name (https://paste.debian.net/1188361/), but couldn't really test it.
<rsalvaterra>
(By the way, matching by driver name is crazy.)
<stintel>
grift: stdowa is a person, he uses > Debian's devscripts' uscan utility, ~3000 watch files and a few ugly shell scripts
ivanich has quit [Remote host closed the connection]
<stintel>
he's in here as swalker
<grift>
ok, thanks. so I dont have to bother replying to those mails. good to know.
<aparcar[m]1>
jow: I rewrote the attendedsysupgrade app in javascript but it still misses multiple of the smart LuCI concepts. I'd appreciate your help on that a lot! https://github.com/openwrt/luci/pull/4145
<Borromini>
rsalvaterra: i assume still the same behaviour after tftp'ing a factory image?
<rsalvaterra>
Borromini: Haven't reinstalled OpenWrt yet, $dayjob takes most of the time. :)
<rsalvaterra>
There is another awkwardness I'm seeing in the MT7621 subtarget, though…
<rsalvaterra>
… why in heck do we have the HSDMA engine driver as a kernel module (kmod-hsdma-mtk), not even selected by default? Is there any problem with it?
<rsalvaterra>
I mean, the thing has its device node specified in the topmost device tree (mt7621.dtsi), so basically everything with a MT7621 SoC contains it.
<rsalvaterra>
And the kernel module is already limited to TARGET_ramips_mt7621. Why not just enabled it by default in the mt7621 kconfigs and be done with it?
zkrx has joined #openwrt-devel
<rsalvaterra>
I only found out about the DMA engine because I was actually reading the datasheet.
<Borromini>
are you running with the wireguard pr from lipnitsk?
<Borromini>
he also tacked on a driver rename patch for hsdma-mtk i think
<rsalvaterra>
Borromini: Yes, the WireGuard stuff hasn't caused me any problems at all.
<Borromini>
rsalvaterra: no, just asking because it has the rename. no problems with wg here either
<Borromini>
although i have to admit, i have spare stuff now to test new builds on, and i find myself way too often flashing my production devices first still :P
dedeckeh has quit [Quit: Connection closed]
<rsalvaterra>
Borromini: I consider all my devices to be "main" (well, except for the TL-WDR3600, which is "configured for holidays" :P).
damex has quit [Read error: Connection reset by peer]
damex has joined #openwrt-devel
damex has quit [Read error: Connection reset by peer]
damex has joined #openwrt-devel
damex has quit [Read error: Connection reset by peer]
damex has joined #openwrt-devel
dangole has joined #openwrt-devel
xback has quit [Read error: Connection reset by peer]
hsp has quit [Quit: WeeChat 3.0.1]
hsp has joined #openwrt-devel
<hurricos>
ynezz: Can you teach me how to set up https://gitlab.com/ynezz/openwrt-device-runtime-testing ? I have a container registry, an MR16, a serial cable, a static OpenWrt host with shell access and know how to install gitlab-runner.
<hurricos>
how's that :^)
<hurricos>
In exchange, I promise to help you hack on it. I have been blocking the upgrade pipeline for Newport Mesh despite Diane's insistence she get new firmware until I have an automatic testing process in place
<hurricos>
and you wouldn't want to disappoint an old mesh granny, now would you?
<hurricos>
Alternatively I can write a check >_>
<hurricos>
Given that I haven't seen ynezz comment in
<hurricos>
... a while, I should probably post on that gitlab page.
<ynezz>
the gitlab-runner is last step, you need to start with labgrid, automatic provisioning of the device over the serial console
<ynezz>
you need some kind of power source control as well, relay, wifi socket whatever
<ynezz>
then you can just run simple labgrid wrapper `.gitlab/scripts/testbed-device.py --target $LABGRID_TARGET boot_into shell` where $LABGRID_TARGET is your MR16 target you've added in .testbed/labgrid/default.yaml, for example mr16-initramfs for booting from initramfs or mr16-nor for flashing/booting from NOR flash
<hurricos>
I'll do that at lunch, drop my work into examples/mr16/README.md, then try to add the instructions somewhere higher in-tree
<hurricos>
s/drop/document
<ynezz>
I can add you to that project and you can edit wiki directly if you want
<hurricos>
Not a huge fan of gitlab wiki ;( happy to migrate the stuff there later once they're in .md's though
<ynezz>
ok, fine with me
<ynezz>
then maybe start docs/first-steps.md or such
<ynezz>
it doesn't matter, the content matters :)
pavlix has quit [Quit: Idle for 30+ days]
<grift>
dangole: can i get a `mount` and a `ls -alZ /tmp/etc` of that bananapi? something weird going on theres with dnsmasq initscript and /tmp/etc/dnsmasq*
<grift>
dangole: also can you tell me what that /dev/mmcblk0p130 is used for?
zkrx has quit [Ping timeout: 245 seconds]
<grift>
scratch that last question
<dangole>
mmcblk0p130 is the protective MBR covering the BPT partition table
<grift>
yes scratch that question
<grift>
i have a challenging time interpretting what dnsmasq init script does there
<grift>
some of the events reference /var/etc/dnsmasq.conf.cfg01411c and others reference /tmp/etc/dnsmasq.conf.cfg01411c
<grift>
i think it might be moving/renaming stuff accross tmpfs's?
<grift>
weird ...
<dangole>
filesystem weirdness is because /dev/mmcblk0p6 isn't mounted when using SELinux because mount_root fails, even in permissive mode
<dangole>
(ie. rootfs_overlay is missing)
<grift>
could it be that when dnsmasq init script creates that /var/etc/dnsmasq.conf.* file that /var is not a symlink to /tmp yet and that theres a tmpfs on /var?
<grift>
so why is it failing?
<grift>
if its just a broken symptom than i dont have to address it
<dangole>
grift: my bad, i missed to include mkfs.f2fs in the image...
<grift>
i address the other issues
<grift>
heh
<grift>
phew well atleast that explains it
<grift>
was trying to interpret what happened there and didnt add up
DonkeyHotei has joined #openwrt-devel
<grift>
ok well the bananapi should now also work with the new commit (provided its configured properly)
<grift>
would be real helpful if you could re-test it with updated policy and proper config
<grift>
as for differentiating between the different "partitions" on same storage. not sure if thats worth the trouble as not much can access storage anyway and we have to be conservative with rules, rules are better spent on containing services/system components
DonkeyHotei has quit [Ping timeout: 256 seconds]
<grift>
i noticed that the *full* policy grew over 200KiB so now efficiency comes into play
<grift>
i dont really think one partition is more important than another, for me its pretty simple anyone with access to raw storage can go around selinux. so if a domain has access to raw storage i consider it "trusted"
zkrx has joined #openwrt-devel
feriman has quit [Quit: WeeChat 3.0.1]
<grift>
selinux associates labels with security extended attributes and if you can access storage raw, then well no xattrs
dangole has quit [Remote host closed the connection]
<dangole>
grift: now with rootfs_data properly mounted, but still some minor issue with mkfs.f2fs
koniu has quit [Ping timeout: 268 seconds]
<grift>
dangole: thanks, will process, but its not the full picture (its in enforcing mode)
koniu has joined #openwrt-devel
<grift>
for example hostpad and wpa_supplicant traverse /proc/sys but since its enforcing i dont know where its trying to go
feriman has joined #openwrt-devel
<grift>
netifd (or some script that it runs) seemd to be trying to rm at least the /tmp/run/wpa_supplicant/wlan1 sock file but not sure if it also wants to delete the parent dir
rsalvaterra1 has joined #openwrt-devel
koniu has quit [Ping timeout: 268 seconds]
<dangole>
grift: once again in permissive mode, full-cycle with mkfs, config-restore and firstboot/jffs2reset: https://termbin.com/ncms
rsalvaterra has quit [Ping timeout: 256 seconds]
<grift>
also not sure what /etc/init.d/boot wants with "executing" /etc/init.d/{uhttpd,rpcd} i think its related to uci-defaults?
rsalvaterra1 has quit [Client Quit]
<grift>
right but that still hase mkfs.f2fs issues right because i still see those dnsmasq tmpfs issues
rsalvaterra has joined #openwrt-devel
<grift>
ill pick the events that make sense
<grift>
but there seems to be still something wrong with your filesystems there
<grift>
can you rm the cert and let it regenerate it?
<grift>
ie service uhttpd restart && ls -alZ /etc/uhttpd.crt
<grift>
because it should be able to create it with a proper label
<grift>
and for some reason it didnt
<dangole>
grift: i think all this havoc is because this luci-app start uhttpd in uci-defaults. it really shouldn't be doing that and i notified the author
<grift>
but the issue is that it seems this system isnt properly configured yet? i mean you said it yourself that theres outstanding issues
<dangole>
grift: here again some small things with mount_root and initializing overlay: https://termbin.com/zzcd
<grift>
i addressed what made sense, that dnsmasq stuff in that latest paste doesnt make sense to me
<dangole>
apart from that weirdness (of trying to restart uhttpd before the show has even started) everything else works and is configured. 1x AP, 1x STA, WAN, ...
<dangole>
most important is just that all that mount_root, config-restore, mount rootfs_data, ... works
<grift>
so youre scp'ing the backup.tgz from the router?
<dangole>
that's me making copying a backup made using 'sysupgrade -b /tmp/backup.tgz'
<dangole>
i do that so i can demonstrate the denied messages when doing 'firstboot'
<grift>
so thats legitimate access? ok well i guess that shouldnt be a problem
<grift>
acctually that is a problem ...
<dangole>
if we'd take this really serious then we should have something like /tmp/xfer either mounted as separate tmpfs with limited size or using quota, then use that for sysupgrade and in SELinux allow only that for user transfers via scp
<grift>
ok ill let it sink in for a while theres a lot going on in there and some of it just doesnt make sense
<dangole>
grift: i guess we'll see what is left after you did the obvious part and if it matters, we'll dig more
<dangole>
this is related to restoring configuration on block devices (ie. mmc)
dangole has quit [Quit: Leaving]
dangole has joined #openwrt-devel
<dangole>
/tmp/sysupgrade.tar is created by 'gzip -cd /dev/mmcblkXpY' (being uninitialized rootfs_data partition carrying the backup in that way). i uncompress it from there instead of copying it because gzip knows the size :)
<rsalvaterra>
dangole: Found and installed an old r14980 build on the RM2100. So far, so good, I've got the correct MAC addresses, so I assume it read the EEPROM correctly.
<dangole>
grift: ie. on EFI platforms like x86 and on all the more hacky rasbpi and the like we got a FAT filesystem as 'boot' partition and can use that to rescue config accross sysupgrade.
<grift>
ok and its a fixed name sysupgrade.tar
<grift>
so we can rely on that name
<dangole>
grift: on mt7622, where i recently cleaned that up so we don't need any stuff from the 80's (FAT) going on to boot OpenWrt, I made a new way more similar to how it's done on (raw-)flash based devices: simply put a tar.gz into the partition which will later be used for rootfs_data.
<dangole>
grift: yes, you can rely on that name
<dangole>
grift: it's hard-coded in fstools and base-files
<grift>
ill address the sysupgrade.tar from mounroot as well
<grift>
quite a bit of stuff going on ...
<dangole>
grift: yes, i was annoyed by all that legacy crap from raspbian creeping into our tree...
koniu has joined #openwrt-devel
<grift>
the thing is that we have to stay sharp here dont want to add policy to support bugs/misconfuration.. better safe than sorry
<grift>
esspecially with that uci-default stuff that went wrong
<dangole>
grift: if we got a target with U-Boot 2020.10 built from source for every board there is really no need to introduce filesystems from 40 years ago.
<dangole>
grift: so i used that opportunity and re-built the whole bootchain in many ways:
<dangole>
grift: 1. embed the rootfs(squashfs) into the uImage.FIT, so bootloader can verify that before starting kernel (which would fail if squashfs is corrupted)
<Grommish>
dangole: Some devices don't have a public uboot available.. My shield is a RHino MISP64 board with uboot 2013, but no way to update it
<dangole>
grift: 2. have a partition parser in Linux to then map the rootfs subimage of that FIT sitting either in Flash or GPT partition into a mountable block device (that's the mmcblk0p6 and mmcblk0p7)
<Grommish>
at least that I've found.. The OEM went out of business in 2015 and took the source with them
<grift>
and it is "stable"?
<grift>
ie youre done with that work?
<dangole>
Grommish: sure, this is not an option on all platforms and the old way to have initrd built-in and squashfs writting arbitrarily into the flash is of course still possible and the default
<grift>
no point is working on policy if the work is not done/stable yet
<Grommish>
dangole: *nod* I'm sure you all will make it work, I just wanted you to be aware updating uboot isn't an option for everyone :)
<dangole>
grift: i'm using that in production and blogic, aparcar and a few others are using all that on the Linksys E8450 (UBI). also the Bananapi R64 eMMC and SDMMC images work in that new way now, and people from the forums there have been using them for 2 weeks now
<rsalvaterra>
dangole: The current 21.01 snapshot (5th March) is also fine (Linux 5.4.99).
<dangole>
grift: ie. i'm not assuming things will change a lot there. some things may move from /lib/upgrade/platform.sh to /lib/upgrade/common.sh or /lib/function* if other platforms start using that way as well
<dangole>
rsalvaterra: but current snapshot, even with 5.4 fails?
<rsalvaterra>
dangole: Didn't go there yet, I'm starting a build from current master with kernel 5.4, but it's a good idea to install the current master snapshot, yes.
koniu has quit [Remote host closed the connection]
<grift>
ok so "mountroot" creates that /tmp/sysupgrade.tar, does it also do any restoring itself?
<grift>
because i suppose we dont see that scenario in the logs (restoring)
<Grommish>
grift: It shows up in the kmesg when it's restoring, or should
koniu has joined #openwrt-devel
<Grommish>
grift: 79_move_config
<Grommish>
(at least, that's what octeon target uses to restore)
<dangole>
grift: i'm of course hoping that rockchip, sunxi, bcm27xx, omap, ... will switch as well, also there we are generally building U-Boot from source or it's at least recent enough
<dangole>
Grommish: this is exactly what I got rid of
<dangole>
Grommish: take a look on how it's done in target/linux/mediatek/mt7622/base-files
<dangole>
(and fstools, which does the restoring part)
<rsalvaterra>
dangole: Blimey…! Today's master snapshot is fine too.
<grift>
dangole, going through all of this is probably going to require a bit of iteration. i added some rules that should make it a bit less noisy, and if you also ensure that the uhttpd uci-default stuff is fixed then a new run should make things a bit clearer where we stand currently
<dangole>
Grommish: This, ie. restoring config from tar.gz in (to-be-formatted, future) rootfs_data without the need of using some platform-specific FAT partition or other hacks can of course be used independently of bootloader support
<Grommish>
dangole: I am out of my knowledge depths. I just know how it works now :) where the backup is stored on the FAT partition as the tgz and then moved once the block devices come online
<dangole>
rsalvaterra: very nice to hear. could that have been related to your local build not being clean?
<rsalvaterra>
dangole: I'm starting to think so. I started this morning pushing the big red button (make dirclean). Let's see how it goes…
<dangole>
Grommish: do we build the bootloader from source and/or can we modify the environment to tell it to load FIT directly from partition instead of mounting FAT?
<Grommish>
dangole: Nope.. Cavium Marvell SoCs are notorious for no support, and in my case in particular, the issue is compounded by the OEM being long gone
<blogic>
"MIPS is developing a new industry-leading standards-based 8th generation architecture, which will be based on the open source RISC-V processor standard."
<blogic>
moment of silence for our old friend
Acinonyx has quit [Ping timeout: 264 seconds]
<rsalvaterra>
blogic: "Rise from your grave!" /Altered Beast
<blogic>
rsalvaterra: which part of "moment of silence for our old friend" was not clear ? ;-P
<dangole>
R.I.P.
<blogic>
dangole: real shame
<rsalvaterra>
Too soon, I guess… :P
koniu has quit [Ping timeout: 268 seconds]
<Grommish>
dangole: My initramfs/"kernel" is kept on the FAT partition and loaded via the octboot uboot call.
<rsalvaterra>
Oh, well… it was the oldest RISC architecture, wasn't it?
<zorun>
MIPS will be doing RISC-V?
* zorun
tries to imagine the confusion
<rsalvaterra>
Brace yourselves for further MIPS toolchain bitrot… :/
<stintel>
blogic: FYI, I'm not seeing any LLDP frames on eth0, switch or lan1 on my RTL8380 switch
<Grommish>
dangole: again, I'm out of my depths and you might have no issues with the way it works, i just wanted to give you a heads up on it because it didn't play nicely when I brought th target up in the beginning
<stintel>
blogic: well, only outgoing LLDP frames I mean
koniu has joined #openwrt-devel
koniu has quit [Remote host closed the connection]
<dangole>
Grommish: I guess if the bootloader relies in that FAT fs and we can't replace it easily, that's how it is then on that platform
<Grommish>
dangole: Gotcha
<dangole>
Grommish: still better than some ipq4xxx boards where vendors hard-coded the configuration to be picked by the bootloader to 'config@foo' -- while the '@' is longer allowed for use in node names in more recent U-Boot...
<dangole>
don't know if U-Boot did that deliberately to annoy QCA
koniu has joined #openwrt-devel
koniu has quit [Remote host closed the connection]
koniu has joined #openwrt-devel
koniu has quit [Remote host closed the connection]
<grift>
the gist is that i know "mountroot" creates the file but i dont know if its just state internal to "mountroot" or if eventually any other entities need access to it
<grift>
and anyone who will need access to /tmp/sysupgrade.tar will then also be able to access /tmp/.switch_jffs2
black_ant has quit [Ping timeout: 256 seconds]
<grift>
anyway i think i did as much as i could at this stage: outstanding issues: fix uhttpd uci-default bug and ensure that /etc/uhttpd.crt is labeled properly. 2. diagnose the dnsmasq /var/etc vs. /tmp/etc issues 3. there is a loose end where wpad wanted to traverse /proc/sys but no traces as to why it wanted that
<grift>
o and 4. in the first paste there was also a trace of some netifd script trying to delete /tmp/run/wpa_supplicant/wlan1 but it was incomplete due to setenforce 1 and needs to be reproduced
koniu has quit [Remote host closed the connection]
koniu has joined #openwrt-devel
<rsalvaterra>
dangole: Installing the image I built…
<rsalvaterra>
… and it's broken.
koniu has quit [Remote host closed the connection]
<grift>
i should probably just remove that whole mountroot domain, that thing cannot be contained ... no point in trying
jmv09 has quit [Quit: Connection closed]
koniu has joined #openwrt-devel
koniu has quit [Remote host closed the connection]
jmv09 has joined #openwrt-devel
<grift>
we need to reproduce the event where that sysupgrade.tar gets "restored" so that we can confirm that it doesnt mess up the labeling
koniu has joined #openwrt-devel
dangole has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
<dangole>
grift: don't give up, because in the end there are 3 generic methods and those should be supported. never mind platform hacks.
<dangole>
grift: it gets extracted here, just like the sysupgrade.tar.gz on other platforms:
<grift>
ok then thats not in the mountroot domain , so that should be fine
<dangole>
right. that's preinit. mount_root is only what is in fstools.git, ie. here: https://git.openwrt.org/?p=project/fstools.git;a=blob;f=mount_root.c
<grift>
yes so the file gets created in the mountroot.subj domain and then restored from sys.subj which has all the transition rules needed to ensure consistent labeling and has unconfined access
Acinonyx has joined #openwrt-devel
<grift>
should be fine
dangole has quit [Remote host closed the connection]
Acinonyx_ has quit [Ping timeout: 245 seconds]
dangole has joined #openwrt-devel
dedeckeh has quit [Quit: Connection closed]
ephemer0l has quit [Ping timeout: 276 seconds]
MentalPower has quit []
MentalPower has joined #openwrt-devel
<Hauke>
MIPS doing RISC-V now makes sense to me, they probably do not have the resources to maintain their architekture (Linux support, toolchain, ...) any more and could just sell their eixsting cores with a RISC-V front end.
<Hauke>
it is probably easier for them to sell RISC-V cores now than MIPS cores
<rsalvaterra>
Meh… RISC-V is more of the same.
<aparcar[m]1>
rsalvaterra: shush
<rsalvaterra>
aparcar[m]1: I want a Mill. :P
<dangole>
grift: looks all good regarding mount_root and all that now. just the remaining weird issues left: https://termbin.com/wpyw
<rsalvaterra>
It's still vapourware, but conceptually fascinating.
* Borromini
never heard of it
danitool has joined #openwrt-devel
<rsalvaterra>
Borromini: Watch the videos (especially the one about the belt). Beware, they're *long*. ;)
<grift>
dangole ok one issue solved (wpad)
<grift>
dangole: where is that code that makes /etc/init.d/boot execute /etc/init.d/{uhttpd,rpcd} and get attribute of /etc/uhttpd.crt?
<Borromini>
so no actual hardware expected to show up yet though?
<grift>
i assume thats from a uci-defaults script?
<Hauke>
dangole: on the Buffalo WSR-2533DHP2 the paralell nand chip is not found any more after upgarding from 5.4 to 5.10
<Hauke>
I am trying to get this into upstream OpeNWrt
<Hauke>
dangole: are you aware of a problem with parallel nand?
<rsalvaterra>
Borromini: Not yet. They're working on a shoestring budget, ironing out the toolchain side, FPGA will be next.
<Hauke>
dnthis is mt7622
<Hauke>
dangole:
<Borromini>
rsalvaterra: ok
<Borromini>
Hauke: do they sell these in europe?
<Hauke>
got mine from Japan
goliath has quit [Quit: SIGSEGV]
AUser has left #openwrt-devel ["Leaving"]
<Borromini>
yeah well thought that was Buffalo's market
<Borromini>
mt7622 and mt7615 it seems
<Hauke>
mt7622 and mt7615 is pretty nice, but mt7622 and mt7915 looks better
<Borromini>
;)
<Borromini>
i'm a bit surprised to see that ARM + ac combo
<Hauke>
The Buffalo WSR-2533DHP2 was released 1.5 years ago, at that time mt7915 was not ready
black_ant has joined #openwrt-devel
black_ant has joined #openwrt-devel
<Hauke>
it is strange that no devices reached the EU
<Borromini>
oh. nevermind me then. didn't know mt7622 had been around that long already
<Hauke>
banana pi r64 was the first device, released about 2 years ago
<Borromini>
ok
<Borromini>
btw, you were talking about how you suspected some minstrel patches about causing wireless instability the other day?
<Hauke>
yes
<Borromini>
any bumps in particular you're suspecting?
<Borromini>
last one i see in the tree is 072bfe2113
<Hauke>
Borromini: I just reverted all of the new patches ;-)
<Borromini>
ok :P
<dangole>
Hauke: I wasn't aware we got any MT7622 boards with parallel NAND
<dangole>
Hauke: I can update arm-trusted-firmware-mediatek to generate bl2 for those, and U-Boot, ...
<dangole>
Hauke: for 5.10, maybe it's just kconfig missing if you start with the vendor loader. Felix has also implemented supoort fr MTK's broken BBT/BMT implementation, but I strongly believe we should just use UBI instead.
<Hauke>
I am using the vendor u-boot
<Hauke>
when I select kernel 5.4 it finds the nand chip with kernel 5.10 it does not find the chip
<Hauke>
the controlelr is initilized
<dangole>
Hauke: the driver seems to be selected for 5.10, I guess you checked that DTS matches mediatek,mt7622-nfc
<grift>
dangole and a `ls -alZ /tmp | nc termbin.com 9999` please
<guidosarducci>
Hauke: I followed up on your comments around updating malta to 5.10. Could you review when you have a moment? Thanks: https://github.com/openwrt/openwrt/pull/3881.
<grift>
dangole can you determine what creates /tmp/etc ? (besides /etc/init.d/rcdnsmasq)
<grift>
something running before /etc/init.d/dnsmasq creates /tmp/etc with a bad label
<grift>
probably an init script
<grift>
grep -r etc /etc/init.d/ | grep mkdir
<dangole>
grift: uhttpd: mkdir -p /var/etc/uhttpd
<grift>
thanks
<dangole>
grift: again, those are just side effects of @aparcars wrong uci-defaults script starting uhttpd super early where it shuold not
<dangole>
grift: ie. ignore this
<grift>
dangole so that then means i can ignore pretty much all of your paste ....
<dangole>
grift: isn't that good news?
<grift>
i mean theres only one issue in there were wpa_supplicant and hostapd read/write ipv{4,6} net sysctls
<grift>
and i assume thats not a bug?
<grift>
k well then i guess i am done
<aparcar[m]1>
someone please run this command and tell me why some default packages appear twice: TOPDIR=$(pwd) make -C target/linux/mvebu/ val.DEFAULT_PACKAGES
<dangole>
Hauke: at least it didn't take days of digging. you already figured why? (i was having dinner and just read the diff now)
<Hauke>
I am looking at it now
<Hauke>
I think the timeout is wrong
<Hauke>
I am checking
<Hauke>
I just wansted to revert some patches and it worked after the first try
dangole has quit [Ping timeout: 264 seconds]
ephemer0l has joined #openwrt-devel
dangole has joined #openwrt-devel
<dangole>
Hauke: lucky ;)
<dangole>
Hauke: I wasn't that lucky with U-Boot 2021.04-rc3 breaking MMC on MT7622 (where U-Boot 2020.10 works). there are some obvious changes affecting exactly the relevant places (min speed adjustment and such), but reverting them didn't fix it...
<Hauke>
dangole: I was also suprised that it worked so fast
Borromini has quit [Quit: leaving]
<Hauke>
dangole: found the problem, I will send a patch upstream
<Hauke>
the condition in readl_poll_timeout() was wrong, this is a break condition
<Hauke>
I did this mistake also some time ago in other code
rmilecki has quit [Ping timeout: 246 seconds]
<dangole>
Hauke: does the romloader of the MT7622 support booting directly off parallel NAND? of is there an extra SPI chip for ATF bl2/preloader? Or just U-Boot SPL old-school?
<dangole>
Hauke: I'm asking because arm-trusted-firmware-mediatek only supports emmc, sdmmc, snand and snor
<dangole>
Hauke: so I'm wondering what to feed the bootrom on the pnand case and how it will load it
<Hauke>
if they supprot spi nand boot, I assume they also supprot p nand boot
<Hauke>
but I think spi nand is now cheaper than p nand
<dangole>
Hauke: it's the same old bootchain as on the Linksys/Belkin device apparently
<dangole>
Hauke: probably they just didn't make the effort to port that to TF-A (yet)
<dangole>
Hauke: nice to see that it loads the new-school FIT image without problems though :)
<dangole>
Hauke: ie. RAMDisk Image separate in the FIT, 'config@1' -> 'config-1'
<dangole>
Hauke: probably it won't support loadables (eg. squashfs) or ext-FIT yet.
<dangole>
Hauke: but good to see that my assumptions on what the old U-Boot from MTK SDK supports hold true for now
<Hauke>
there is a brcm trx header around the image
<Hauke>
also the initramfs
<dangole>
ouh. that's hacky. but i see those Original load address = 0x4007ff28, After skip trx_header, load address = 0x4007ff44, ...
<dangole>
yeah, and it's U-Boot SPL loading U-Boot loading ATF instead of the other way around, like they do now
<Hauke>
dangole: this device is 1.5 years old
<dangole>
Hauke: even the Linksys/Belin which are made starting from August 2020 come with that bootchain. I guess newer versions of MTK already contain it the new way as they published on github and we do in OpenWrt as well now, and we will see that in future devices.
<Hauke>
normally board vendors start with something at some point in time and they they do not want to change, because it is working
<Hauke>
dangole: which github are you talking about?
<dangole>
Hauke: so will be for MT7629
<dangole>
Hauke: github.com/mtk-openwrt
<dangole>
Hauke: in OpenWrt we already got package/arm-trusted-firmware-mediatek from there and I'm preparing U-Boot update in my stating tree (as I said, MMC is still too slow to be functional right now, but for SPI-NAND it already works very nicely with U-Boot 2021.04-rc3)
<Hauke>
nice
<dangole>
just that 'bromimage' tool is still binary only, someone outside of MTK and without NDA needs to make a clean re-write under some free license, I reckon...
<dangole>
ie. that currently breaks build on non-Linux buildhosts :(
<Hauke>
does it work on arm64 linux? ;-)
<dangole>
nope
<Hauke>
someone complains that the marvell U-Boot does not build on arm64 Linux
<dangole>
x86_64, and x32 only
<dangole>
there is also some rudimentary tooling in U-Boot's 'mkimage -T mtk_image' to replace 'bromimage' for other MTK SoCs but it's not sufficient for MT7622 apparently (I tried for days...)
plntyk has quit [Remote host closed the connection]
plntyk has joined #openwrt-devel
veonik has joined #openwrt-devel
xes_ has quit [Quit: bye..]
xes has joined #openwrt-devel
gromero_ has quit [Read error: Connection reset by peer]