Ok,can you create a issue ticket on github for that issue?
Flashing over web interface wont work because @pepe2k does not support safeloader devices.
They have a special header.
Can you use tftp?
Also does MAC display in that gist match yours or do I need to change offset
The mac is different to the one on the label.
If the image header is not supported wouldn´t tftp then fail aswell?
Yeah,you are right.
I need to make LEDE image without safeloader
This means that your bootstrap configuration (pull-up/down resistors) is wrong.
It could be either mistake in hardware design or during manufacture (some short on PCB or wrong resistor placement). I have seen that on different TP-Link devices before.
safeloader is an image type, not just a header.
In fact, you can have different kernel/firmware header types within safeloader image.
Thanks for the explanation.
We will than currently manually return 0 so baud rate is correct because I doubt that only TP link device using different PLL configuration is CPE210 v2.
I will prepare LEDE image without safe loader today so we can check if the serial is working.
Here is the first attempt at image without safeloader:https://drive.google.com/drive/folders/0B1VOQQ-_EIXKd0xkaGtLa3huejQ?usp=sharing
MAC should be read correctly in LEDE now.
Still gotta figure out how to read it properly in u-boot.
pay attention to clocks: 406/250/125/ 15/ 25 MHz
they should either default to 650/400/200 or recovery-default 400/400/200
generic ar71xx image should still boot regardless of safeloader part
That is weird, by default since I did not manually set 550_400_200 they should default to 650_400_200.
I really need to compile latest and flash it on mine
Finally unsoldered flash on my CPE210 v2 and flashrom still refuses to detect it.
Most likely I am connecting pins wrong
Did you pull up the WP and the HOLD pins of the flash chip?
Have a look here: https://github.com/pepe2k/u-boot_mod/blob/master/u-boot/cpu/mips/ar7240/qca95xx_pll_init.S#L46
XTAL type (25/40 MHz) in my code is always detected based on bootstrap configuration, in low level initialization (clocks setup) and later, when e.g. LS/HS UART is configured.
I think you can add similar define option as for DRAM type detection, have a look here:
This option should allow to ignore XTAL type read from bootstrap configuration and use s static value instead, for "broken by design" boards.
But, I think that you should first look closely and carefully at your board PCB, maybe you made some short accidentally on GPIO15 line which IIRC is the one used for XTAL type detection? In fact, based on the datasheet, QCA953x series doesn't support 40 MHz XTAL. And what's more, I suppose that some internal parts of the SOC might be using XTAL type detection during bootstrap for other h/w configuration.
Or, if you or someone else have access to the same device, just check if the XTAL type detection is also broken there, just to make sure it's not a problem with your piece.
Yes,they were tied to VCC pin.
I will try on mine,as soon I get flashrom to detect the SPI flash.
GPIO 15 looks like this:
Without the flash chip installed into the board it measures 1.2V and the led glows a bit, dont know if this counts as high. Given the 10k i think they want to pull it low but fail (or maybe a short on my board).
If there is a error on the board wouldn´t the stock uboot fail as well if thats done correctly?
When robimarko flashes his chip and has the same problem we know more.
according to this, if SDRAM is not supported, there is a bug that makes code misdetect DDR as SDR:
i have this output in both u-boot builds:
BOARD: TP-Link TL-MR22U $3
SOC: QCA953x ver. 1 rev. 1
CPU: MIPS 24Kc
RAM: 32 MB SDR 16-bit CL3-4-4-10
FLASH: 16 MB Winbond W25Q128Well, QCA953X series supports only DDR1 and DDR2 RAM.
So that must be a bug.
Unfortunately, I still have not had time to get Flashrom working since I was given the task of getting LEDE to work on LigoDLB Propeller 5.
I think I am gonna flash it without taking a full dump before.
Also, TP-Link replied to my request for GPL sources for V2 since they ingeniously had just linked V1 sources for V2 also.
They stated that they have sent a request to engineers for new sources and that they will reply soon.
Also from reading datasheet it looks like in AR934X series GPIOs 0-3 are reserved for JTAG and cannot be used without disabling JTAG function otherwise.
Now I dont know if TP-Link even uses those GPIOs
Yes, it's a bug, in hardware. On software side, detection is done correctly, based on bootstrap register.
Have a look in code how DRAM setup is done for more details and answer why it's still working even if DRAM type selection is "broken" on the board/hardware.
It looks like TP-Link actually messed up the design.
Stock U-boot seems to also read wrong values and pass those to the kernel.
That means that they are using hardcoded clocks in firmware instead of ones passed by the bootloader.
That seems to be visible in stock bootlog at fifth line:
ath_sys_frequency: cpu apb ddr apb cpu 650 ddr 392 ahb 216
Just take a look at initframs image booted over TFTP clocks at line 70.
Clock for SoC is set at 1040 MHz, RAM is also wrong and the reference clock is read as 40MHz.
That must be the cause of all issues and possibly the reason why V3 is FCC certified and listed on TP-Link website.
I think that tomorrow I will finally have time to make U-boot that hardcodes correct values and then try to boot LEDE.
I can confirm this, TP-Link really messed up their design. I removed R113 from the board, which disconnects the third Wifi LED but the bootstrap is now correct. The clocks in uboot now show
CLOCKS: CPU/RAM/AHB/SPI/REF
650/400/200/ 25/ 25 MHz
and the kernel boots correctly when booting over tftp so hardcoding those values is the way to go.
Ok, will try it tomorrow.
But custom u-boot flashing would be a real no-go for 99.99% of people so there must be some way for LEDE kernel to also ignore u-boot passed arguments and use hardcoded ones.
Also, how did you flash custom U-boot?
TFTP and console combo or?
I flashed u-boot directly onto the flash chip with flashrom.
I am trying, but I cant get flashrom to detect SPI flash at all.
I gave up and resoldered it to CPE.
Good thing is that I did not break it actually.
Now gotta figure how to flash it using console and TFTP
Update: And got It bricked and gotta wait until CH341A programmer arrives from Hong Kong.