Netgear R7800 exploration (IPQ8065, QCA9984)

I've used this as basis https://source.codeaurora.org/quic/la/kernel/msm/log/?h=linaro/release/qcomlt-4.9
It contains all patches rebased for k4.9 already including kraut specific opp, clk and cpufreq patches
Check https://github.com/dissent1/r7800/tree/49-3/target/linux/ipq806x/patches-4.9 please
Besides there's absent ipq806x fix from Linux-next
https://github.com/dissent1/r7800/blob/49-3/target/linux/ipq806x/patches-4.9/001-arm-dts-qcom-Fix-ipq-board-clock-rates.patch
But we fail to boot up for some reason, though everything seems fine

@blogic actually a lot of patches are missing it seems

I compiled 4.9 image for R7800 based on blogic's code, but the result is the same.

The router does not boot properly. It actually ends up in the u-boot TFTP recovery mode (power led slowly blinking), so that I can just send a new firmware image via TFTP without needing to touch the reset button.

That makes me to think that somehow the kernel image gets invalidated very early. By u-boot?

That has now happened with both alternative 4.9 approaches.

But I have no serial console attached, so no additional info at this point.

Check my previous msg pls.

I know how to handle scm, there's only 1 clock and that is <&rpmcc RPM_DAYTONA_FABRIC_CLK>, but your commit is missing 3xx patches that adds support for ipq806x rpm clock controller

@dissent1 why did you not post these patches ?

looks like there are no ipq4xxx patches. can you update your tree with the missing patches you listed above so i can pull this lot into trunk as a replacement of what we have right now ? i'd like to start testing ipq4xxx after that

Erm, I've started k4.9 patches only yesterday and we can't boot up. We have no serial access so we can't check the exact reason.
But those patches are already in k4.4 tree in LEDE
https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/ipq806x/patches-4.4/305-add-board-clocks-and-rpmcc-into-DT.patch;h=be45895824064270f8bb6c89165aa7ef4db926e5;hb=HEAD
https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/ipq806x/patches-4.4/311-add-rpmcc-for-ipq806x.patch;h=bb9dd87dd65273f06b16949af5ce2c8900892501;hb=HEAD

The clocks fix patch has been submitted to upstream kernel after I've found that upstream clocks are incorrect, so it's in 305 patch along with rpmcc node.

Btw qcom-scm driver doesn't contain ipq806x compatibility string, so in DT it should be set as apq8064 or I'll made a patch to add the compatibility into the driver.

I'll rebase upon current head and make PR in a while

how do you want to prodceed ? use the patches i pushed and add the missing bits or try to make yours boot and add ipq4xxx support.

i would like to use as little of QCAs hacky work ad possible. its just too bad quality.

I'll rearrange your patches and make it a single commit on top of a current head.
Will also add 4.9 files and config symbols.
At the moment I have no means to make it bootable as I cannot verify the error because neither me nor anyone I know have access to serial console on the device.
I'm almost done, verifying the compilation and editing patch headers to reflect real commits in linaro repo on code-aurora.

Well bad quality or not, but those patches that are not upstream make the device work rock steady actually.

i have access on a ap148 eval kit. i can boot your tree if that helps ?

Does your tree boot on that kit? If yes, then it won't help unfortunately.
I suppose there's some issue with nand

i'll try your tree. the board does have nand.

Smem partition parser that is used for ap148 to parse partitions is dropped in k4.9 for now. It doesn't compile and I'm not sure it is gonna work because nand node layout has changed in nand driver. That's why I asked if your tree boots on ap148 because your tree has it dropped as well.
https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/ipq806x/patches-4.4/037-mtd-add-SMEM-parser-for-QCOM-platforms.patch;h=7c0c8035652a9b7a89d4623e6689027c88b9ac41;hb=HEAD

@blogic I'm finished with patches. Also added missing config symbols and files-4.9.
https://github.com/dissent1/r7800/commit/f40b829fc44c0c33b6dba666317fc19be68e61d4

I'm not sure how to number ipq40xx patches.

UPDATE: forgot to squash commits. Updated the link.

That's definitely nand issues or smth in device tree not corresponding to new nand driver though I've updated it as well.
Backporting the nand driver into k4.4 leads to a boot loop.

i'll try that tree today

@blogic @Heinz has provided the bootlog on TP-Link C2600, a spi nor device
`U-Boot 2012.07 [Standard IPQ806X.LN,unknown] (Aug 28 2015 - 19:57:21)

smem ram ptable found: ver: 0 len: 5
DRAM: 491 MiB
PCI0 Link Intialized
PCI1 Link Intialized
SF: Detected MX25U25635F with page size 4 KiB, total 32 MiB
00:01.0 - 17cb:0101 - Bridge device
01:00.0 - 168c:0040 - Network controller
02:01.0 - 17cb:0101 - Bridge device
03:00.0 - 168c:0040 - Network controller
NAND: ipq_nand: unknown NAND device manufacturer: 0 device: 0
ipq_nand: failed to identify device
SF: Detected MX25U25635F with page size 4 KiB, total 32 MiB
ipq_spi: page_size: 0x100, sector_size: 0x1000, size: 0x2000000
32 MiB
MMC:
*** Warning - bad CRC, using default environment

In: serial
Out: serial
Err: serial
Net: MAC1 addr:0:3:7f:ba:db:1
athrs17_reg_init: complete
athrs17_vlan_config ...done
S17c init done
MAC2 addr:0:3:7f:ba:db:2
eth0, eth1
boot in 2 seconds
FirmwareRecovery: Now doing bootipq
MMC Device 0 not found
MMC Device 0 not found

Loading from nand1, offset 0x1f0000
Image Name: ARM LEDE Linux-4.9.10
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1921894 Bytes = 1.8 MiB
Load Address: 42208000
Entry Point: 42208000
Automatic boot of image at addr 0x44000000 ...
Image Name: ARM LEDE Linux-4.9.10
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1921894 Bytes = 1.8 MiB
Load Address: 42208000
Entry Point: 42208000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
info: "mtdparts" not set
Using machid 0x1260 from environment

Starting kernel ...`

Seems not only a nand issue

does this also happen with the tree i pushed or after applying your patches or both trees ?

ok, this is related to your patches somehow. my board works with trunk but fails with your patches

There has been a leftover patch for ap148, I've deleted it now

I've got advised that it could be a serial driver or irq issue. But I'm not sure that any of patches can cause this.