Hi Mauro,
On 13.01.20 11:24, Mauro Condarelli wrote:
On 1/13/20 7:53 AM, Stefan Roese wrote:
Hi Mauro,
On 11.01.20 20:00, Mauro Condarelli wrote:
I managed to find ONE of the reasons why my ROM build didn't run: I forgot to enable `CONFIG_BOARD_EARLY_INIT_F=y`.
I see. This explains of course, why your board does not boot without any "preloader".
I wanted, nonetheless, be prepared for further mishaps, but I have some other problems (see below).
Are these issues now fixed? I scanned the discussion about the DEBUG UART on the list. Is this working for you now or do you have any other issues still? Did you successfully boot your new U-Boot from SPI NOR?
Yes and no :(
I fixed my RAM-based problems, but booting from SPI NOR still refuses to utter a single byte. I do attach my defconfigs and my board.c for your reading pleasure (in case you have troubles getting asleep they should provide a good cure).
Before looking into this in more depth (I actually do have problems sleeping though, so I might take a look at it later ;)), why don't you re-start with your defconfig by using the linkit defconfig file. If you are lucky, the LinkIt binary might even work for the VoCore2. Or what are the differences except the SoC type and WLAN? Its the same DDR2 config and the same UART. So it might get you pretty far - also with ROM based booting.
I also added a couple of printouts in drivers/pinctrl/pinctrl-uclass.c and it turns out system tries to setup pins for uart2, but fails (maybe because pinctrl@60 is not yet setup correctly?). This is the output I get from RAM-based u-boot:
<debug_uart> board_debug_uart_init(): board_early_init_f(): pinctrl_select_state_full('palmbus@10000000', 'default'): pinctrl_select_state_full('uart2@e00', 'default'): pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 pinctrl_select_state_full('clkctrl@0x2c', 'default'):
U-Boot 2020.01-00370-g97a60844bd-dirty (Jan 13 2020 - 01:03:59 +0100)
CPU: MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr) Model: VoCore2 DRAM: 128 MiB pinctrl_select_state_full('palmbus@10000000', 'default'): pinctrl_select_state_full('pinctrl@60', 'default'): pinctrl_select_state_full('pin_state', 'default'): pinctrl_select_state_full('uart2@e00', 'default'): pinctrl_select_state_full('uart2_pins', 'default'): pinctrl_select_state_full('clkctrl@0x2c', 'default'): pinctrl_select_state_full('watchdog@100', 'default'): WDT: Started with servicing (60s timeout) board_early_init_r(): arch_early_init_r(): MMC: pinctrl_select_state_full('mmc@10130000', 'default'): pinctrl_select_state_full('sd_iot_mode', 'default'): pinctrl_select_state_full('clk48m@0', 'default'): pinctrl_select_state_full('mmc@10130000', 'default'): mmc@10130000: 0 Loading Environment from FAT... *** Warning - bad CRC, using default environment
In: uart2@e00 Out: uart2@e00 Err: uart2@e00 Model: VoCore2 arch_misc_init(): =>
I don't have all these pinctrl issues on LinkIt. I suspect a config issue and / or dts issue. Please compare.
ROM-based u-boot, as said, does not print *anything*, not even garbage. I'm beginning to suspect I have some mishap with start address or similar. I have absolutely no idea how to debug this without a JTAG probe (which I don't have and would be non-trivial to get working; soldering required).
Yes. JTAG requires soldering IIRC.
The only idea I currently have is to modify my "old" u-boot to do initialization and then jump to beginning of "new" u-boot. If I can make it work in an automatic way I can try removing initialization steps till I find the "culprit". Any better idea would be welcome, of course!
If I have to resort to that clumsy method, would be enough to put "new" in SPI NOR (of course at an higher address, e.g.: 30000 as "old" is only 183272 bytes long) and jump to the first location? I assume I will have to relocate CONFIG_SYS_TEXT_BASE=0xbc030000
This is the TEXT_BASE for ROM based booting:
CONFIG_SYS_TEXT_BASE=0x9c000000
Please see configs/linkit-smart-7688_defconfig.
Did I forget something?
Not sure. I still think using the linkit port as a base for SPI NOR based booting would be a very good test at least. Do you see any problems with this approach (board / SoC differences)?
Thanks, Stefan