Welcome, @csom! I had a good mind to go sign up to sweclockers and ask you how you got on. It seems like the best way to go about this is for someone to ask for a newer source drop. I suspect that the broadcom toolchain contains various image finishing tools. Did you manage to find that ( toolchains_bcm963xx_4.06L.02.tgz)?
I found about 75 different ways how not to build an initramfs for this platform via openwrt source. I think I'm close, but the load address is still wrong, and it crashes when I load via tftp (several examples in these forums). I want to have something working before I attempt to flash it, first. Don't want to wear out the flash. Anyway, I've been keeping away from manually finishing the vmlinux file... this particular board may need special touches. But it runs a standard kernel.
Many attempts via tftp look like this (note the wrong code and entry addrs):
*** Press any key to stop auto run (1 seconds) ***
Auto run second count down: 0
Retry loading it as a compressed image.
Loading 192.168.1.100:vmlinux ...
Finished loading 5264506 bytes
Code Address: 0x6D000080, Entry Address: 0x00574a3d
LZMA: Prossible old LZMA format, trying to decompress..
Decompression OK!
Entry at 0x00574a3d
Closing network.
Disabling Switch ports.
Flushing Receive Buffers...
0 buffers found.
Closing DMA Channels.
Starting program at 0x00574a3d
**Exception 8: EPC=C0A80100, Cause=80E4ABDA (Exc22 )
...
This was done using master, kernel version 5.10. Not tried the source only 5.15 yet. The bmips platform looks a lot more organized and complete. See differences
as you could see at start of this tread, it was successful boot via initramfs with , hmmm, 19.07 or 08 ??
yes, it was bmips target
sorry, but my device is dead, storm is killed ethernet ports, so i have no further way of experimenting
i know that was a mess with switch, it always show as 100mbps, suppose it was internal switch what i saw and not the external
anyway, gpio's are found, most of them, so .. good luck
and sorry i could not help any further
no, actually no
i booted ubuntu 14 in VM to try to compile, but no luck
and, believe me, INTENO was very very slow with responses about GPL
3 or 4 month to get this tarball, so i give up
I compiled with latest master and boot via initramfs, as @NPeca75.
But, still the Marvell switch is not visible, only the internal switch. But that is not used. The internal switch has just 100M interfaces.
My theory is that the CPU is connected with the MII interface to the Marvell switch and control via MDIO. But, I don´t know how to define the MDIO. I can´t find it in the bcm6328.dtsi.
OK - custom config? I just went with most defaults except to make a ramfs img.
Basically the same as mine. Can't get anything lzma compressed to get past Starting program at ..., or the elf loaders just seem to hang with e.g. 0x80a00000/4519626 - but is this because the kernels are bigger than 4MB?
Not sure - checking out lede 17 and grepping the DTS for those might shed some more light. Could just try commenting out and see what happens.
Is your device type the -R1? The sticker on the bottom should say XG6846-R1 or so.
Yes, the one I´m playing with is a XG6846-R1, but I have one XG6846 as well.
But, I dont know that the difference are, except the USB. The XG6846 has an USB connector.
I've successfully compiled the source on a Ubuntu 14 VM. I extracted the gz-file and in that folder I also put the toolchain uclibc-crosstools-gcc-4.4.2-1 so the ./consumer_install script install the toolchain in the right place. After that I used Apt to install build-essential bison flex lib32z1 lib32ncurses5 lib32stdc++6. Then to achieve a successful build the file userspace/private/apps/httpd/Makefile needs to be edited on line 9 and remove the html/*.gif-part since there are no .gif files in the http-directory.
@systemcrash I did not manage to find that file, sorry.
The only toolchain I use besides the prerequirements I mentioned is uclibc-crosstools-gcc-4.4.2-1 tar-file. I first tried Ubuntu 16.04 with minor problems and decided to try Fedora 16 since the readme sugests that and succeeded, I also tried Ubuntu 14.04 with a successful build.
The only thing that was a problem after that was the watchdog.sh-script in /sbin. This script monitors the TR069 client, so it’s not a big issue. But to get a 100% complete firmware I extracted this file from another already compiled firmware from my ISP, and then used that in my source-dir.
I use the compiled firmware on two of my XG6846-R1's. When I switched out the watchdog.sh-script the firmware worked flawlessly and has been online for almost 48 hours without any problems. I even use my own ACS-server to control them over TR069-protocol.
For a newer source I was in contact with iopsys.io who provide's a new software iowrt for these switches. I haven't got a response from them yet. I know that there exists a 01.99 version at least now because I got this answer from a Swedish retail seller who claimed that they used that version on their switches and this was over a year ago.
I guess that's about as close as one gets to a custom firmware with these devices, so far. The source drop contains a few .ko files intended for a single kernel version in the drop.
I've modified the consumer_relasese and added some features to busybox including lsmod, modinfo and vimand added iptables as a binary with including kernel modules.
I've also managed to list the modules loaded with lsmod. Maby the output can help with the switch issue?
