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

Reply via email to