**** BEGIN LOGGING AT Sun May 03 02:59:57 2020
May 03 03:08:27 <owrt-1907-builds> build #122 of lantiq/xrx200 is complete: Failure [failed kmodconfig]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/lantiq%2Fxrx200/builds/122  blamelist: Petr ?tetiar <ynezz@true.cz>, Chuanhong Guo <gch981213@gmail.com>, Sungbo Eo <mans0n@gorani.run>, Antonio Quartulli <a@unstable.cc>, Kevin Darbyshire-Bryant <ldir
May 03 03:08:27 <owrt-1907-builds> @darbyshire-bryant.me.uk>, Henrique de Moraes Holschuh <henrique@nic.br>, Felix Fietkau <nbd@nbd.name>, Pawel Dembicki <paweldembicki@gmail.com>
May 03 16:20:03 <owrt-1907-builds> build #123 of lantiq/xrx200 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/lantiq%2Fxrx200/builds/123
May 03 17:31:44 <fragtion> hope someone can help. i built 19.07.2 from tarball. my uname is now Linux OpenWrt 4.14.171, however now I can't install kernel module from http://downloads.openwrt.org/releases/19.07.2/targets/ramips/rt305x/kmods/4.14.171-1-9a90d552f1e8ed4f201155596f60004e/, due to error kernel (= 4.14.171-1-9a90d552f1e8ed4f201155596f60004e)
May 03 17:32:23 <fragtion> i guess my question is, why is official kmod url this long kernel revision string, or why does the tarball string not match up? and how can I fix this?
May 03 17:34:44 <fragtion> previously i installed from snapshot and had the long kernel version, but then i couldn't install standard packages because uname was not simply "4.14.171". so i'm going in circles here :/
May 03 17:36:00 <PaulFertser> fragtion: because kernel modules embed hash of config to ensure compatibility
May 03 17:36:16 <PaulFertser> fragtion: so when you self-build a kernel, install kmods that you build along with it.
May 03 17:37:13 <fragtion> thanks @PaulFertser.. is there any way to get the kmod installed to device at this point besides rebuilding the whole rom with that kmod implemented?
May 03 17:37:52 <PaulFertser> fragtion: you do not need to rebuild the whole "rom". You enable it in your menuconfig, build, copy to /tmp and opkg install it.
May 03 17:38:20 <fragtion> so i should basically build any modules manually rather than depend on downloads.openwrt.org kmod repo ?
May 03 17:38:36 <fragtion> what use is the repo then? I'm a bit confused
May 03 17:43:04 <fragtion> okay according to https://forum.archive.openwrt.org/viewtopic.php?id=39961, it seems the 'bad news' I'm interpreting from what you are saying is true, in that I will need to build my own kernel mods because my .config differs from release's? if i'm wrong please correct me to save time & headache XD
May 03 17:45:28 <fragtion> last post of that thread is suggesting it is possible to override .vermagic hash.. hrm..?
May 03 17:48:46 <PaulFertser> fragtion: the repo is for the kernel built by autobuilders.
May 03 17:49:09 <PaulFertser> fragtion: why is that you're willing to build your own kernel but not modules?
May 03 17:49:39 <fragtion> unsupported device so i had to build own kernel/rom
May 03 17:49:56 <fragtion> was hoping that by using official source, i could utilize repo kmods for 'convenience' aspect
May 03 17:50:17 <PaulFertser> Not having vermagic as a safe guard leads to many obscure bug reports.
May 03 17:50:34 <fragtion> I can imagine yeah
May 03 17:51:05 <fragtion> but I need a workaround :)
May 03 17:51:12 <PaulFertser> You can force depends
May 03 17:51:19 <PaulFertser> In opkg
May 03 17:52:20 <fragtion> hrm, just tried that but same error unfortunately
May 03 17:53:00 <fragtion> --force-checksum seems to work
May 03 17:55:19 <fragtion> ok perfect thanks for your help, this will do :D
May 03 17:56:45 <fragtion> Here is my work for the device in question btw (Tenda A6) -> https://github.com/fragtion/openwrt-hardware/tree/master/tenda-a6 -- it would be nice if official support could be added. it is very similar to already supported device "A5-V11"
May 03 18:09:08 <PaulFertser> fragtion: official support will depend on you sending patches to add it.
May 03 18:09:16 <PaulFertser> Most probably
May 03 18:11:44 <fragtion> is a pull request to github repo fine, as a mirror of the official openwrt git? if so which branch do I clone and push to? sorry if these are elementary FAQ/rtfm questions lol
May 03 18:13:47 <PaulFertser> fragtion: sometimes sending patches to the mailing list is faster but github pull requests work too, please check the wiki about more details.
May 03 18:14:04 <fragtion> ty
May 03 18:34:59 <gromero> PaulFertser: Hi. Do you happen to know what's the reset / power vector address on these mipsel 32 shipped with Acher C50?
May 03 18:35:22 <gromero> from Uboot I've tried these two addresses I've found in the docs: https://pastebin.com/raw/y6Ut21ye
May 03 18:35:43 <gromero> but I understand the MMU is actually disabled when on Uboot prompt?
May 03 18:38:15 <aparcar[m]> fragtion: send patches against master.
May 03 18:40:06 <PaulFertser> gromero: yes, MMU is normally disabled there, and SPI flash is sometimes mapped with a special hardware block to some address. If you have vendor u-boot sources you can see what address it's linked for.
May 03 18:42:43 <PaulFertser> aparcar[m]: hm, indeed https://openwrt.org/submitting-patches is not super-clear on the topic.
May 03 18:43:43 <aparcar[m]> PaulFertser: :)
May 03 18:44:11 <gromero> PaulFertser: oh so even tho MMU is off there is another mechanism to map the SPI flash, I see. But since these two addresses I've pointed out are the first ones (MMU on or MMU off) CPU must fetch the first instruction shoudn't I be able to read from either of them from Uboot?
May 03 18:44:54 <gromero> (regardless how SPI flash map is)
May 03 18:45:22 <PaulFertser> gromero: you should be if the flash is indeed mapped there and doesn't have that badd data.
May 03 18:45:33 <PaulFertser> gromero: but probably the flash is mapped elsewhere?
May 03 18:47:01 <gromero> probably is mapped elsewhere, but can the map (or by another mechanism or setup) change the vector / power address two? unless it got unmapped at that point I'm trying to examine the mem?
May 03 18:47:24 <gromero> s/address two/address too/
May 03 18:47:50 <PaulFertser> gromero: why are you sure the reset vector is there?
May 03 18:53:23 <gromero> PaulFertser: because of the mips32 docs I've found + https://www.nulltrace.org/2013/04/mips-bootstrapping.html plus a series of defines and hardcoded values in the uboot / qemu code:
May 03 18:53:24 <gromero> https://pastebin.com/raw/QuhYtfUk
May 03 18:53:45 <gromero> but I'm not really a mips expert
May 03 18:53:49 <PaulFertser> gromero: do you have serial boot log of vendor firmware on that specific device?
May 03 18:54:17 <gromero> nope, just the log from uboot
May 03 18:54:32 <gromero> I was not able to flash the original vendor fw back
May 03 18:54:40 <PaulFertser> gromero: so please show the log
May 03 18:54:55 <PaulFertser> gromero: and probably printenv
May 03 18:56:15 <gromero> PaulFertser: https://hastebin.com/raw/iberajezar
May 03 18:56:50 <PaulFertser> gromero: and when you do not interrupt the boot please
May 03 18:57:40 <gromero> PaulFertser: if I don't interrupt the boot it gets stuck forever on:
May 03 18:57:41 <gromero> continue to starting system.
May 03 18:57:42 <gromero>  0
May 03 18:57:52 <PaulFertser> gromero: and no addresses printed?
May 03 18:57:57 <gromero> nope
May 03 18:58:07 <gromero> I can boot  initramfs too if it helps...
May 03 18:58:52 <PaulFertser> gromero: if you can boot initramfs then you can change the flash contents obviously.
May 03 18:59:19 <Hauke> gromero: normally the reset vector points to some code in the boot rom of the chip
May 03 18:59:25 <gromero> PaulFertser: yes, I've tried using mtd as you said but I got "erase error" when trying to flash back the stock fw
May 03 18:59:34 <Hauke> then the code from the rom gets executed and that loads something from some flash
May 03 18:59:57 <swalker> updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html
May 03 19:00:04 <PaulFertser> gromero: so probably the flash is indeed damaged and your "md" shows accurate data.
May 03 19:00:19 <PaulFertser> gromero: or are you seeing different contents when booted?
May 03 19:00:35 <PaulFertser> Erase error is odd
May 03 19:01:12 <gromero> PaulFertser: you mean different comparing two different boots and inspecting a same given address?
May 03 19:02:00 <PaulFertser> gromero: I mean is Linux driver able to read anything at all from those flash areas?
May 03 19:02:00 <gromero> Hauke: I see, but isn't  the vector address something static which can't be changed and so I should be able to at least read it on uboot?
May 03 19:02:26 <gromero> PaulFertser: ah, I didn't try let me check
May 03 19:02:39 <gromero> I believe I can check that by dumping /dev/mem ?
May 03 19:02:51 <gromero> PaulFertser: ^
May 03 19:02:53 <PaulFertser> gromero: hexdump -C /dev/mtd2
May 03 19:02:55 <Hauke> greearb: it could be that you can configure these adresses when you integarte the MIPS core into the SoC
May 03 19:02:58 <PaulFertser> Or something along the lines
May 03 19:03:00 <Hauke> or that they are execute only
May 03 19:03:05 <Hauke> and not readable
May 03 19:03:05 <gromero> PaulFertser: right, let me try
May 03 19:04:08 <gromero> Hauke: ok, if we can configure the address that's new to me and an additional complication I need to be aware. thanks.
May 03 19:04:31 <PaulFertser> gromero: not we, but SoC designer
May 03 19:05:54 <Hauke> yes, PaulFertser is right I was talking about the time when the MIPS core gets inteagrted into the SoC, but I do not know what can be configured, I never saw these tools
May 03 19:05:55 <gromero> PaulFertser: sorry, yeah, I mean 'we' was a kind of unknown entity. sadly it don't see it mentioned on the MT7628 datasheet, but it's not really great
May 03 19:05:55 <PaulFertser> gromero: probably you can try lower frequency in DTS for the flash IC
May 03 19:06:16 <PaulFertser> gromero: and then flashing with mtd will start working
May 03 19:06:21 <PaulFertser> (hopefully)
May 03 19:07:05 <gromero> PaulFertser: what DTS you mean?
May 03 19:07:24 <gromero> or how : )
May 03 19:08:48 <gromero> PaulFertser: btw, before using the stock firmware with 'mtd' I skipped the 512 bytes
May 03 19:08:58 <gromero> (as in the owrt docs)
May 03 19:09:13 <gromero> although I think it can't be the cause for the "erase error"
May 03 19:09:30 <PaulFertser> gromero: you're booting OpenWrt initramfs and your flash is detected but somehow erasing fails, right? I suggest you change DTS file of OpenWrt to use much lower SPI frequency and retry.
May 03 19:10:44 <gromero> PaulFertser: got it. Btw ' hexdump -C /dev/mtd2' seems to work ok, I see at some point the strings of Uboot, for instance
May 03 19:11:13 <gromero> I'll give a try with a lower frequency
May 03 19:15:58 <gromero> PaulFertser: fyi, that's what happens currently:
May 03 19:15:59 <gromero> root@OpenWrt:/# mtd -r write /tmp/tplink.bin firmware
May 03 19:15:59 <gromero> Unlocking firmware ...
May 03 19:15:59 <gromero> Writing from /tmp/tplink.bin to firmware ...  [e]Failed to erase block
May 03 19:16:21 <gromero> it takes like 15 seconds to happens
May 03 19:16:48 <PaulFertser> gromero: check /proc/mtd to see what device corresponds to firmware
May 03 19:17:40 <gromero> PaulFertser: https://hastebin.com/raw/igaqetofin
May 03 19:17:50 <gromero> mtd2 so
May 03 19:18:02 <gromero> and:
May 03 19:18:03 <gromero> root@OpenWrt:/# mtd -r write /tmp/tplink.bin mtd2
May 03 19:18:03 <gromero> Could not open mtd device: mtd2
May 03 19:18:03 <gromero> Can't open device for writing!
May 03 19:18:12 <PaulFertser> gromero: what's in dmesg?
May 03 19:20:10 <gromero> PaulFertser: https://hastebin.com/raw/ikohanidun (full log)
May 03 19:26:03 <gromero> Hauke: PaulFertser well, I can also play a bit harder and desolder the SPI flash, writing it fully with a simple crafted code that prints to the serial it's location, that would give me with some luck the approximated real address where the core starts, right?
May 03 19:26:33 <gromero> (but naturally I'll check if I can find the vendor's uboot souce first)
May 03 19:26:42 <gromero> *source
May 03 19:28:53 <PaulFertser> gromero: if you can get initramfs running it's all you need for development.
May 03 19:29:03 <PaulFertser> gromero: just sort out the issues with mtd.
May 03 19:29:12 <PaulFertser> My first guess is that trying lower speed might be beneficial.
May 03 19:29:56 <gromero> PaulFertser: ok. I'll follow that direction. thanks!
May 03 19:30:13 <PaulFertser> gromero: you still need to get OpenWrt working on that board right?
May 03 19:31:25 <gromero> PaulFertser: well, yes, and one idea was to compare what stock firmware is doing in special to get the 2.4GHz working ok and that's not being done on openwrt
May 03 19:31:49 <gromero> that's why I want to flash the stock image ultimately (to compare settings etc)
May 03 19:32:31 <PaulFertser> gromero: you'll need proper mtd support in any case, so that's the first to fix, and then you'll be able to flash whatever at any moment.
May 03 19:32:39 <gromero> although I don't understand yet how I can flash an openwrt sysupgrade image from initramfs (thought sysupgrade tools would work for that but it didn't )
May 03 19:33:08 <PaulFertser> gromero: sysupgrade is using "mtd" under the hood for SPI NOR flash.
May 03 19:33:35 <gromero> ah, that's might explain why sysupgrade didn't work too
May 03 19:33:50 <gromero> great. I'll sort out what's happening with mtd
May 03 19:34:03 <gromero> PaulFertser: really appreciate your help
May 03 19:34:47 <PaulFertser> gromero: really wish you luck with your project :)
May 03 19:35:13 <gromero> PaulFertser: thanks :)
May 03 19:42:57 <Hauke> aparcar[m]: ping
May 03 19:43:31 <aparcar[m]> Hauke: I just sent you an email
May 03 19:43:33 <aparcar[m]> amazing rtt
May 03 19:44:16 <Hauke> aparcar[m]: I am just answering
May 03 19:45:18 <Hauke> aparcar[m]:what do they want to know?
May 03 19:45:26 <fragtion> aparcar[m]: will do thanks
May 03 19:46:21 <aparcar[m]> Hauke: I think some overall project description and concrete ideas for what should be done. If you are available for the next hour I'll update you
May 03 19:46:32 <Hauke> ok
May 03 19:46:34 <aparcar[m]> haven't looked to deep into it as I wasn't sure if this is of interest overall
May 03 19:47:12 <Hauke> I think you have to finish in 15 minutes
May 03 19:47:33 <Hauke> ah no it is tomorrow at 8 PM UTC
May 03 19:47:58 <aparcar[m]> :)
May 03 19:49:53 <aparcar[m]> Hauke: you have access to contact@openwrt.org right?
May 03 19:51:20 <Hauke> yes
May 03 20:23:03 <gromero> PaulFertser: just to be sure I've got you right, you meant experiment with a tweak like that right: https://hastebin.com/umuvigupud.diff ?
May 03 20:23:42 <PaulFertser> gromero: exactly
May 03 20:23:48 <gromero> PaulFertser: k
**** ENDING LOGGING AT Mon May 04 02:59:57 2020