Hi Stefan,
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).
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(): =>
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).
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 Did I forget something?
<snip>
You might also want to give the new version / patches from Weijie a try. He added SPL support and a "cleaner" init code for this SoC.
I'm interested in giving it a spin (and help debugging on another HW, if needed), but I would like to have a solid base from where to move, changing too many things at once is rarely a good strategy ;)
I fully agree.
I need to be able to start from SPI NOR, before I can commit to some other task
Thanks, Stefan
Many thanks Mauro