Hi Mauro,
On 15.01.20 10:04, Mauro Condarelli wrote:
On 15.01.20 00:55, Mauro Condarelli wrote:
I found *one* of the bugs in startup:
To enable UART2 pinmux setting:
void __iomem *gpio_mode;
gpio_mode = ioremap_nocache(MT76XX_GPIO1_MODE, 0x100);
clrbits_le32(gpio_mode, GENMASK(27, 26));
is not enough; you need also:
setbits_le32(gpio_mode, GENMASK(3, 2));
I actually use the more explicit, but hopefully equivalent:
#define MT76XX_GPIO1_MODE 0x10000060
#define MIPS_KSEG1_START 0xA0000000
uint32_t v, *a;
a = (uint32_t *)(MIPS_KSEG1_START + MT76XX_GPIO1_MODE);
v = *a;
v &= 0xF3FFFFFF;
v |= 0x0000000C;
*a = v;
It is unclear to me how Linkit port could work.
I double checked on LiniIt and it works without this bit 2/3
setting:
=> md b0000060 1
b0000060: 50050404 ...P
You can check this on your VoCore2 board by setting this value
from the prompt. If this works, then its not strictly needed.
This seems to be strictly needed on my board:
U-Boot 1.1.3 (Apr 23 2017 - 14:59:01)
VoCore2 > md b0000060 1
b0000060: 5505040c ...U
VoCore2 > mm b0000060
b0000060: 5505040c ? 55050404
<DEAD>
This is with the original "paleolithic" u-boot, of course, but it
should be a HW-related feature, should I try also with "current"
(RAM based)?
In your version above, you do *not* have configured bits 27:26
(UART2 GPIO mode) to 00b but to 01b (GPIO mode).
I did this test on my LinkIt and wrote your original value:
=> mw b0000060 5505040c�
<DEAD>
So this does not work for me.
You might want to try my value "50050404" with your 1.1.3 version
to see, if this works there. But I dount it.
I am surprised though as all I could find on differences between
MT7628 and MT7688 are is a reference on Mediatek site:
https://docs.labs.mediatek.com/resource/linkit-smart-7688/en/faq
Q: What’s MT7628 and how is it different from MT7688AN?
The MT7628 series are pin-to-pin compatible with the MT7688 series.
However, MT7628 comes with a 2T2R antenna, while MT7688 only supports
1T1R antenna.
(Incomplete!) comparison of the two datasheets did not show
relevant differences.
Anyways now my "secondary from ROM" approach now
works without the long delay described below.
Unfortunately this does not seem to be the whole story because
flashing u-boot linked directly in the "right palace":
SYS_TEXT_BASE = 0x9c000000
still refuses to display anything on serial; I assume some other
initialization is missing, but that will be another fight.
Any insight welcome.
Did my new image from yesterday produce any output on your board?
No.
Your image was as silent as mine.
Not a single char in serial line.
I see. If you really need a different UART2 mux setup in the GPIO1_MODE
register, this might explain the difference. I can generate a new image
(untested) with your GPIO1_MODE value of 5505040c for you to test. Just
let me know.
BTW: How do you flash the image into SPI NOR? From the new mainline
U-Boot loaded into RAM or from the ancient 1.1.3 version? Perhaps
something is going wrong in the flashing process?
I will try to read back after flashing, but I somewhat doubt that's the
problem.
Yes, please do.
I am using the new, RAM-based U-Boot to flash.
Actual sequence is:
usb reset; fatload usb 0 80010000 u-boot-ram.bin; go 80010000
usb start; sf probe;
load usb 0:1 85000000 u-boot-rom.bin; sf update ${fileaddr} u-boot
${filesize}
reset
where:
=> mtd list
List of MTD devices:
* nor0
- type: NOR flash
- block size: 0x1000 bytes
- min I/O: 0x1 bytes
- 0x000000000000-0x000001000000 : "nor0"
- 0x000000000000-0x00000007e000 : "u-boot"
- 0x00000007e000-0x00000007f000 : "env"
- 0x00000007f000-0x000000080000 : "factory"
- 0x000000080000-0x000000320000 : "kernel"
- 0x000000320000-0x000001000000 : "filesystem"
Equivalent sequences work correctly to flash kernel and (recovery)
filesystem.
Looks correct at first glance. Here my sequence:
=> printenv upd_uboot load_uboot update_uboot
upd_uboot=run load_uboot update_uboot
load_uboot=tftp ${loadaddr} ${tftpdir}/u-boot.bin
update_uboot=sf probe;sf update ${loadaddr} 0 ${filesize}
Thanks,
Stefan
