Re: How to debug HW startup?
Hi Stefan,
update, see below.
On 1/14/20 12:08 AM, Mauro Condarelli wrote:
> Next episode of this telenovela:
>
> I rebuilt u-boot for ROM at BC03 (my code, very similar to LinkIt).
> I flashed it at 3 in SPI NOR:
>
> => usb start; sf probe
> starting USB...
> Bus ehci@101c: pinctrl_select_state_full('ehci@101c', 'default'):
> USB EHCI 1.00
> scanning bus ehci@101c for devices... 3 USB Device(s) found
> scanning usb for storage devices... 1 Storage Device(s) found
> SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total
> 16 MiB
> => load usb 0:1 8500 u-boot.secondary
> 390089 bytes read in 18 ms (20.7 MiB/s)
> => sf update ${fileaddr} 3 ${filesize}
> device 0 offset 0x3, size 0x5f3c9
> 390089 bytes written, 0 bytes skipped in 9.751s, speed 40952 B/s
> => reset
>
> Restarted old u-boot and jumped to new:
>
> U-Boot 1.1.3 (Apr 23 2017 - 14:59:01)
> VoCore2 > go bc03
> ## Starting application at 0xBC03 ...
> board_debug_uart_init():
>
> System stopped here several minutes, enough for me to start writing
> this email, then it continued boot sequence:
> board_debug_uart_init():
> board_early_init_f():
Here is the first strange thing:
apparently `board_debug_uart_init()` is called twice.
I am not 100% sure as code is full of `#ifdef`s, but it seems
first time it's called in `arch/mips/cpu/start.S`, most likely
in line 257 as I couldn't find traces of CONFIG_MIPS_INIT_STACK_IN_SRAM
(besides `arch/mips/cpu/Kconfig:381` where is defined,
defaults to `n` and none seems to touch anymore;
second strange thing is I find no trace of it in `.config`)
This, again, does not add-up (third "strange thing") because
I see nothing between calls to `debug_uart_init` (start.S:257)
and `board_init_f` (start.S:264) that could trigger a ~5min delay
(but I'm really out of my depth, here!) unless there's something
in the `printascii()`itself (e.g.: loop at serial_mtk.c:449 blocks).
> pinctrl_select_state_full('palmbus@1000', '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 - 23:21:39 +0100)
>
> CPU: MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr)
> Model: VoCore2
> DRAM: 128 MiB
> pinctrl_select_state_full('palmbus@1000', '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@1013', 'default'):
> pinctrl_select_state_full('sd_iot_mode', 'default'):
> pinctrl_select_state_full('clk48m@0', 'default'):
> pinctrl_select_state_full('mmc@1013', 'default'):
> mmc@1013: 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():
> =>
>
> Code, beside being targeted to ROM and with a different SYS_TEXT_BASE,
> is identical to what runs fine when started from RAM.
>
> I also tried copying flash to ram:
>
> => cp.b bc03 8001 5f3c9
> => go 8001
> ## Starting application at 0x8001 ...
> board_debug_uart_init():
> [04010D08][04010D08]
> DDR Calibration DQS reg =
> relocate_code Pointer at: 87f5c000
> ***
> Watchdog Reset Occurred
> ***
>
> ... but this is almost expected because I relocated at another address
> without changing SYS_TEXT_BASE.
>
> A further measurement shows booting u-boot from flash stops for
> almost 5 minutes (4m48s, using a manual stopwatch).
>
> I sincerely have no idea where to bang my head :(
>
> TiA
> Mauro
>
>
> On 1/13/20 3:14 PM, Mauro Condarelli wrote:
>> Hi Stefan,
>> unfortunately it does *not* work.
>>
>> Ram based is ok, but rom is just as silent as mine:
>>
>> => usb start; sf probe;
>> starting USB...
>> Bus ehci@101c: pinctrl_select_state_full('ehci@101c', 'default'):
>> USB EHCI 1.00
>> scanning bus ehci@101c for devices... 3 USB Device(s) found
>> scanning usb for storage devices... 1 Storage Device(s) found
>> pinctrl_select_state_full('spi@b00', 'default'):
>> SF: Detected gd25q128 with page size 256 Bytes, erase size 4 KiB, total
>> 16 MiB
>> => load usb 0:1 8500 u-boot_linkit.bin-rom
>> 455708 bytes read in 22 ms (19.8 MiB/s)
>> => sf update ${fileaddr} 0 ${filesize}
>> device 0 offset 0x0, size 0x6f41c
>> 455708 bytes written, 0 bytes skipped in 12.288s, speed 37966 B/s
>> => reset
>> resetting ...
>> pinctrl_select_state_full('syscon-reboot', 'default'):
>> pinctrl_select_state_full('syst
Re: How to debug HW startup?
Next episode of this telenovela:
I rebuilt u-boot for ROM at BC03 (my code, very similar to LinkIt).
I flashed it at 3 in SPI NOR:
=> usb start; sf probe
starting USB...
Bus ehci@101c: pinctrl_select_state_full('ehci@101c', 'default'):
USB EHCI 1.00
scanning bus ehci@101c for devices... 3 USB Device(s) found
scanning usb for storage devices... 1 Storage Device(s) found
SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total
16 MiB
=> load usb 0:1 8500 u-boot.secondary
390089 bytes read in 18 ms (20.7 MiB/s)
=> sf update ${fileaddr} 3 ${filesize}
device 0 offset 0x3, size 0x5f3c9
390089 bytes written, 0 bytes skipped in 9.751s, speed 40952 B/s
=> reset
Restarted old u-boot and jumped to new:
U-Boot 1.1.3 (Apr 23 2017 - 14:59:01)
VoCore2 > go bc03
## Starting application at 0xBC03 ...
board_debug_uart_init():
System stopped here several minutes, enough for me to start writing
this email, then it continued boot sequence:
board_debug_uart_init():
board_early_init_f():
pinctrl_select_state_full('palmbus@1000', '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 - 23:21:39 +0100)
CPU: MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr)
Model: VoCore2
DRAM: 128 MiB
pinctrl_select_state_full('palmbus@1000', '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@1013', 'default'):
pinctrl_select_state_full('sd_iot_mode', 'default'):
pinctrl_select_state_full('clk48m@0', 'default'):
pinctrl_select_state_full('mmc@1013', 'default'):
mmc@1013: 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():
=>
Code, beside being targeted to ROM and with a different SYS_TEXT_BASE,
is identical to what runs fine when started from RAM.
I also tried copying flash to ram:
=> cp.b bc03 8001 5f3c9
=> go 8001
## Starting application at 0x8001 ...
board_debug_uart_init():
[04010D08][04010D08]
DDR Calibration DQS reg =
relocate_code Pointer at: 87f5c000
***
Watchdog Reset Occurred
***
... but this is almost expected because I relocated at another address
without changing SYS_TEXT_BASE.
A further measurement shows booting u-boot from flash stops for
almost 5 minutes (4m48s, using a manual stopwatch).
I sincerely have no idea where to bang my head :(
TiA
Mauro
On 1/13/20 3:14 PM, Mauro Condarelli wrote:
> Hi Stefan,
> unfortunately it does *not* work.
>
> Ram based is ok, but rom is just as silent as mine:
>
> => usb start; sf probe;
> starting USB...
> Bus ehci@101c: pinctrl_select_state_full('ehci@101c', 'default'):
> USB EHCI 1.00
> scanning bus ehci@101c for devices... 3 USB Device(s) found
> scanning usb for storage devices... 1 Storage Device(s) found
> pinctrl_select_state_full('spi@b00', 'default'):
> SF: Detected gd25q128 with page size 256 Bytes, erase size 4 KiB, total
> 16 MiB
> => load usb 0:1 8500 u-boot_linkit.bin-rom
> 455708 bytes read in 22 ms (19.8 MiB/s)
> => sf update ${fileaddr} 0 ${filesize}
> device 0 offset 0x0, size 0x6f41c
> 455708 bytes written, 0 bytes skipped in 12.288s, speed 37966 B/s
> => reset
> resetting ...
> pinctrl_select_state_full('syscon-reboot', 'default'):
> pinctrl_select_state_full('system-controller@0', 'default'):
>
> I might have done something stupid; Now I need do stop, but I'll
> test again this evening.
>
> Many thanks
> Mauro
>
>
> On 1/13/20 1:45 PM, Stefan Roese wrote:
>> On 13.01.20 13:24, Mauro Condarelli wrote:
>>>
>>> On 1/13/20 12:39 PM, Stefan Roese wrote:
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 ne
Re: How to debug HW startup?
Hi Stefan,
unfortunately it does *not* work.
Ram based is ok, but rom is just as silent as mine:
=> usb start; sf probe;
starting USB...
Bus ehci@101c: pinctrl_select_state_full('ehci@101c', 'default'):
USB EHCI 1.00
scanning bus ehci@101c for devices... 3 USB Device(s) found
scanning usb for storage devices... 1 Storage Device(s) found
pinctrl_select_state_full('spi@b00', 'default'):
SF: Detected gd25q128 with page size 256 Bytes, erase size 4 KiB, total
16 MiB
=> load usb 0:1 8500 u-boot_linkit.bin-rom
455708 bytes read in 22 ms (19.8 MiB/s)
=> sf update ${fileaddr} 0 ${filesize}
device 0 offset 0x0, size 0x6f41c
455708 bytes written, 0 bytes skipped in 12.288s, speed 37966 B/s
=> reset
resetting ...
pinctrl_select_state_full('syscon-reboot', 'default'):
pinctrl_select_state_full('system-controller@0', 'default'):
I might have done something stupid; Now I need do stop, but I'll
test again this evening.
Many thanks
Mauro
On 1/13/20 1:45 PM, Stefan Roese wrote:
> On 13.01.20 13:24, Mauro Condarelli wrote:
>>
>>
>> On 1/13/20 12:39 PM, Stefan Roese wrote:
>>> 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 will try it.
>> Just to be on the safe side, could You attach a binary (or two: ROM and
>> RAM) to
>> the mail? If it works it would really give me a start base.
>
> See below.
>
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:
board_debug_uart_init():
board_early_init_f():
pinctrl_select_state_full('palmbus@1000', '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@1000', '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@1013', 'default'):
pinctrl_select_state_full('sd_iot_mode', 'default'):
pinctrl_select_state_full('clk48m@0', 'default'):
pinctrl_select_state_full('mmc@1013', 'default'):
mmc@1013: 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.
>> I will, but I was trying to say something different:
>> Apparently the stock software tries to initialize uart2 pinctrl and it
>> *seems* to succeed later in initialization.
>> This *seems* to indicate explicit pin setup in board_early_init_f() is
>> not strictly needed (we wo
Re: How to debug HW startup?
On 1/13/20 12:39 PM, Stefan Roese wrote:
> 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 will try it.
Just to be on the safe side, could You attach a binary (or two: ROM and
RAM) to
the mail? If it works it would really give me a start base.
>> 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:
>>
>> board_debug_uart_init():
>> board_early_init_f():
>> pinctrl_select_state_full('palmbus@1000', '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@1000', '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@1013', 'default'):
>> pinctrl_select_state_full('sd_iot_mode', 'default'):
>> pinctrl_select_state_full('clk48m@0', 'default'):
>> pinctrl_select_state_full('mmc@1013', 'default'):
>> mmc@1013: 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.
I will, but I was trying to say something different:
Apparently the stock software tries to initialize uart2 pinctrl and it
*seems* to succeed later in initialization.
This *seems* to indicate explicit pin setup in board_early_init_f() is
not strictly needed (we would lose only the first few lines even if
we don't fix the error).
I had a look to pinctrl-mt7628.c and it seems to do the right thing
upon call to ('uart2_pins', 'default'), so anything after that *should*
work even without low-level setup.
>>
>> 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.: 3 as "old" is
>> only
>> 183272 bytes long) and jump to the first location?
>> I assume I will have to relocate CONFIG_SYS_TEXT_BASE=0xbc03
>
> This is the TEXT_BASE for ROM based booting:
>
> CONFIG_SYS_TEXT_BASE=0x9c00
AFAIK 0x9c00 and 0xbc
Re: How to debug HW startup?
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:
board_debug_uart_init():
board_early_init_f():
pinctrl_select_state_full('palmbus@1000', '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@1000', '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@1013', 'default'):
pinctrl_select_state_full('sd_iot_mode', 'default'):
pinctrl_select_state_full('clk48m@0', 'default'):
pinctrl_select_state_full('mmc@1013', 'default'):
mmc@1013: 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.: 3 as "old" is only
183272 bytes long) and jump to the first location?
I assume I will have to relocate CONFIG_SYS_TEXT_BASE=0xbc03
This is the TEXT_BASE for ROM based booting:
CONFIG_SYS_TEXT_BASE=0x9c00
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
Re: How to debug HW startup?
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:
board_debug_uart_init():
board_early_init_f():
pinctrl_select_state_full('palmbus@1000', '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@1000', '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@1013', 'default'):
pinctrl_select_state_full('sd_iot_mode', 'default'):
pinctrl_select_state_full('clk48m@0', 'default'):
pinctrl_select_state_full('mmc@1013', 'default'):
mmc@1013: 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.: 3 as "old" is only
183272 bytes long) and jump to the first location?
I assume I will have to relocate CONFIG_SYS_TEXT_BASE=0xbc03
Did I forget something?
>
>
>>> 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
CONFIG_MIPS=y
CONFIG_SYS_TEXT_BASE=0x9c00
CONFIG_ENV_SIZE=0x1000
CONFIG_NR_DRAM_BANKS=1
CONFIG_DEBUG_UART_BOARD_INIT=y
CONFIG_DEBUG_UART_BASE=0x1e00
CONFIG_DEBUG_UART_CLOCK=4000
CONFIG_ARCH_MTMIPS=y
CONFIG_BOARD_VOCORE2=y
CONFIG_BOOT_ROM=y
CONFIG_ONBOARD_DDR2_SIZE_1024MBIT=y
CONFIG_ONBOARD_DDR2_CHIP_WIDTH_16BIT=y
CONFIG_MIPS_BOOT_FDT=y
CONFIG_DEBUG_UART=y
CONFIG_ENV_VARS_UBOOT_CONFIG=y
CONFIG_SYS_BOOT_GET_CMDLINE=y
CONFIG_SYS_BOOT_GET_KBD=y
# CONFIG_ARCH_FIXUP_FDT_MEMORY is not set
CONFIG_USE_BOOTARGS=y
CONFIG_LOGLEVEL=8
CONFIG_VERSION_VARIABLE=y
CONFIG_DISPLAY_BOARDINFO_LATE=y
CONFIG_ARCH_EARLY_INIT_R=y
CONFIG_ARCH_MISC_INIT=y
CONFIG_BOARD_EARLY_INIT_F=y
CONFIG_BOARD_EARLY_INIT_R=y
CONFIG_HUSH_PARSER=y
# CONFIG_AUTOBOOT is not set
# CONFIG_BOOTM_NETBSD is not set
# CONFIG_BOOTM_PLAN9 is not set
# CONFIG_BOOTM_RTEMS is not set
# CONFIG_BOOTM_VXWORKS is not set
# CONFIG_CMD_XIMG is not set
CONFIG_CMD_MEMINFO=y
CONFIG_CMD_GPIO=y
CONFIG_RANDOM_UUID=y
# CONFIG_CMD_LOADB is not set
# CONFIG_CMD_LOADS is not set
CONFIG_CMD_MMC=y
CONFIG_CMD_MTD=y
CONFIG_CMD_PART=y
CONFIG_CMD_SPI=y
CONFIG_CMD_USB=y
CONFIG_CMD_WDT=y
CONFIG_CMD_FAT=y
CONFIG_CMD_FS_GENERIC=y
CONFIG_CMD
Re: How to debug HW startup?
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? 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. Thanks, Stefan
Re: How to debug HW startup?
Many thanks. It appears I had completely misinterpreted the meaning of CONFIG_DEBUG_UART_CLOCK. I see now a correct output and a new warning message: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 right after "" notification. Tomorrow I'll try to understand what it means. I don't think I would have found it without You pointing in the right direction. MANY Thanks! Best regards Mauro Condarelli On 1/12/20 12:58 AM, Sean Anderson wrote: > On 1/11/20 4:38 PM, Mauro Condarelli wrote: >> Thanks Joel, >> unfortunately I already have that defined, even if I forgot to copy it. >> I attach my full .config for reference as I have no idea what I'm >> still missing. >> >> On 1/11/20 9:42 PM, Sean Anderson wrote: Could You share a Linkit _defconfig with early serial debug enabled? I'm decidedly missing something as, even enabling CONFIG_DEBUG_UART=y CONFIG_DEBUG_UART_BASE=0x1e00 CONFIG_DEBUG_UART_CLOCK=20 CONFIG_DEBUG_UART_SHIFT=2 CONFIG_DEBUG_UART_ANNOUNCE=y > So it looks like your clock is way too low. The unit for the clock is > Hz. From the device tree you sent, this board is based off > arch/mips/dts/mt7628a.dtsi, using uart2. The clock controller for this > board is compatible with "mediatek,mt7628-clk", and the driver is > located in "drivers/clk/mtmips/clk-mt7628.c". From that file, the uart2 > clock gets its frequency from CLK_SRC_PERI. Under mt7628_clk_get_rate, > the peripheral clock source depends on the value of > PERI_CLK_FROM_XTAL_SEL, which is initialized to 0 (as documented in the > data sheet). Therefore, the else clause is taken (unless configured > otherwise), so you should use 4000 for your clock. > >>> You need to pick a debug uart driver, e.g. CONFIG_DEBUG_UART_NS16550. >> As said I have it, but I'm not sure about the other parameters. >> Maybe a better choice would be CONFIG_DEBUG_UART_MTK. >> Having a "known good" configuration would help a lot. >> >> Regards >> Mauro >> >
Re: How to debug HW startup?
On 1/11/20 4:38 PM, Mauro Condarelli wrote: > Thanks Joel, > unfortunately I already have that defined, even if I forgot to copy it. > I attach my full .config for reference as I have no idea what I'm > still missing. > > On 1/11/20 9:42 PM, Sean Anderson wrote: >>> Could You share a Linkit _defconfig with early serial debug enabled? >>> I'm decidedly missing something as, even enabling >>> >>> CONFIG_DEBUG_UART=y >>> CONFIG_DEBUG_UART_BASE=0x1e00 >>> CONFIG_DEBUG_UART_CLOCK=20 >>> CONFIG_DEBUG_UART_SHIFT=2 >>> CONFIG_DEBUG_UART_ANNOUNCE=y So it looks like your clock is way too low. The unit for the clock is Hz. From the device tree you sent, this board is based off arch/mips/dts/mt7628a.dtsi, using uart2. The clock controller for this board is compatible with "mediatek,mt7628-clk", and the driver is located in "drivers/clk/mtmips/clk-mt7628.c". From that file, the uart2 clock gets its frequency from CLK_SRC_PERI. Under mt7628_clk_get_rate, the peripheral clock source depends on the value of PERI_CLK_FROM_XTAL_SEL, which is initialized to 0 (as documented in the data sheet). Therefore, the else clause is taken (unless configured otherwise), so you should use 4000 for your clock. >> You need to pick a debug uart driver, e.g. CONFIG_DEBUG_UART_NS16550. > As said I have it, but I'm not sure about the other parameters. > Maybe a better choice would be CONFIG_DEBUG_UART_MTK. > Having a "known good" configuration would help a lot. > > Regards > Mauro >
Re: How to debug HW startup?
Thanks Joel, unfortunately I already have that defined, even if I forgot to copy it. I attach my full .config for reference as I have no idea what I'm still missing. On 1/11/20 9:42 PM, Sean Anderson wrote: >> Could You share a Linkit _defconfig with early serial debug enabled? >> I'm decidedly missing something as, even enabling >> >> CONFIG_DEBUG_UART=y >> CONFIG_DEBUG_UART_BASE=0x1e00 >> CONFIG_DEBUG_UART_CLOCK=20 >> CONFIG_DEBUG_UART_SHIFT=2 >> CONFIG_DEBUG_UART_ANNOUNCE=y >> >> I still have plenty of errors: >> >> /home/mcon/vocore/__V2__/Buildroot/recov/host/bin/mipsel-linux-ld.bfd: >> arch/mips/cpu/start.o: in function `wr_done': >> (.text+0x650): undefined reference to `debug_uart_init' >> /home/mcon/vocore/__V2__/Buildroot/recov/host/bin/mipsel-linux-ld.bfd: >> (.text+0x654): undefined reference to `debug_uart_init' >> /home/mcon/vocore/__V2__/Buildroot/recov/host/bin/mipsel-linux-ld.bfd: >> board/vocore/vocore2/built-in.o: in function `board_early_init_f': >> (.text.board_early_init_f+0x10): undefined reference to `printhex8' >> /home/mcon/vocore/__V2__/Buildroot/recov/host/bin/mipsel-linux-ld.bfd: >> common/built-in.o: in function `putc': >> (.text.putc+0x18): undefined reference to `printch' >> /home/mcon/vocore/__V2__/Buildroot/recov/host/bin/mipsel-linux-ld.bfd: >> common/built-in.o: in function `puts': >> (.text.puts+0x2c): undefined reference to `printch' >> > You need to pick a debug uart driver, e.g. CONFIG_DEBUG_UART_NS16550. As said I have it, but I'm not sure about the other parameters. Maybe a better choice would be CONFIG_DEBUG_UART_MTK. Having a "known good" configuration would help a lot. Regards Mauro # # Automatically generated file; DO NOT EDIT. # U-Boot 2020.01 Configuration # CONFIG_HAVE_ARCH_IOREMAP=y # CONFIG_ARC is not set # CONFIG_ARM is not set # CONFIG_M68K is not set # CONFIG_MICROBLAZE is not set CONFIG_MIPS=y # CONFIG_NDS32 is not set # CONFIG_NIOS2 is not set # CONFIG_PPC is not set # CONFIG_RISCV is not set # CONFIG_SANDBOX is not set # CONFIG_SH is not set # CONFIG_X86 is not set # CONFIG_XTENSA is not set CONFIG_SYS_ARCH="mips" CONFIG_SYS_CPU="mips32" CONFIG_SYS_SOC="mt7628" CONFIG_SYS_VENDOR="vocore" CONFIG_SYS_BOARD="vocore2" CONFIG_SYS_CONFIG_NAME="vocore2" CONFIG_SYS_TEXT_BASE=0x8001 CONFIG_SYS_MALLOC_F_LEN=0x1000 CONFIG_ENV_SIZE=0x1000 CONFIG_DM_GPIO=y CONFIG_ERR_PTR_OFFSET=0x0 CONFIG_NR_DRAM_BANKS=1 CONFIG_BOOTSTAGE_STASH_ADDR=0 # CONFIG_DEBUG_UART_BOARD_INIT is not set CONFIG_DEBUG_UART_BASE=0x1e00 CONFIG_DEBUG_UART_CLOCK=20 CONFIG_IDENT_STRING="" # # MIPS architecture # # CONFIG_TARGET_QEMU_MIPS is not set # CONFIG_TARGET_MALTA is not set # CONFIG_TARGET_VCT is not set # CONFIG_ARCH_ATH79 is not set # CONFIG_ARCH_MSCC is not set # CONFIG_ARCH_BMIPS is not set CONFIG_ARCH_MTMIPS=y # CONFIG_ARCH_JZ47XX is not set # CONFIG_MACH_PIC32 is not set # CONFIG_TARGET_BOSTON is not set # CONFIG_TARGET_XILFPGA is not set CONFIG_SYS_DCACHE_SIZE=0 CONFIG_SYS_DCACHE_LINE_SIZE=0 CONFIG_SYS_ICACHE_SIZE=0 CONFIG_SYS_ICACHE_LINE_SIZE=0 # # MediaTek MIPS platforms # CONFIG_SOC_MT7628=y # CONFIG_BOARD_GARDENA_SMART_GATEWAY_MT7688 is not set # CONFIG_BOARD_LINKIT_SMART_7688 is not set CONFIG_BOARD_VOCORE2=y CONFIG_BOOT_RAM=y # CONFIG_BOOT_ROM is not set CONFIG_SUPPORTS_BOOT_RAM=y CONFIG_SYS_LITTLE_ENDIAN=y # CONFIG_CPU_MIPS32_R1 is not set CONFIG_CPU_MIPS32_R2=y # # General setup # CONFIG_ROM_EXCEPTION_VECTORS=y CONFIG_MIPS_CACHE_INDEX_BASE=0x8000 CONFIG_MIPS_RELOCATION_TABLE_SIZE=0x8000 # # OS boot interface # CONFIG_MIPS_BOOT_CMDLINE_LEGACY=y CONFIG_MIPS_BOOT_ENV_LEGACY=y CONFIG_MIPS_BOOT_FDT=y CONFIG_SUPPORTS_LITTLE_ENDIAN=y CONFIG_SUPPORTS_CPU_MIPS32_R1=y CONFIG_SUPPORTS_CPU_MIPS32_R2=y CONFIG_CPU_MIPS32=y CONFIG_MIPS_TUNE_24KC=y CONFIG_32BIT=y CONFIG_SYS_SCACHE_LINE_SIZE=0 CONFIG_SYS_CACHE_SIZE_AUTO=y CONFIG_MIPS_L1_CACHE_SHIFT_5=y CONFIG_MIPS_L1_CACHE_SHIFT=5 CONFIG_DEBUG_UART=y # CONFIG_AHCI is not set # # General setup # CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y # CONFIG_DISTRO_DEFAULTS is not set CONFIG_ENV_VARS_UBOOT_CONFIG=y CONFIG_SYS_BOOT_GET_CMDLINE=y CONFIG_SYS_BOOT_GET_KBD=y CONFIG_SYS_MALLOC_F=y CONFIG_EXPERT=y CONFIG_SYS_MALLOC_CLEAR_ON_INIT=y # CONFIG_TOOLS_DEBUG is not set # CONFIG_PHYS_64BIT is not set CONFIG_BUILD_TARGET="" # CONFIG_SYS_CUSTOM_LDSCRIPT is not set # # Boot images # # CONFIG_ANDROID_BOOT_IMAGE is not set # CONFIG_FIT is not set CONFIG_LEGACY_IMAGE_FORMAT=y # CONFIG_OF_BOARD_SETUP is not set # CONFIG_OF_SYSTEM_SETUP is not set # CONFIG_OF_STDOUT_VIA_ALIAS is not set CONFIG_SYS_EXTRA_OPTIONS="" CONFIG_HAVE_SYS_TEXT_BASE=y # CONFIG_ARCH_FIXUP_FDT_MEMORY is not set # # API # # CONFIG_API is not set # # Boot timing # # CONFIG_BOOTSTAGE is not set CONFIG_BOOTSTAGE_RECORD_COUNT=30 CONFIG_SPL_BOOTSTAGE_RECORD_COUNT=5 CONFIG_TPL_BOOTSTAGE_RECORD_COUNT=5 CONFIG_BOOTSTAGE_STASH_SIZE=0x1000 # CONFIG_SHOW_BOOT_PROGRESS is not set # # Boot media # # CONFIG_NAND_BOOT is not set # CONFIG_
Re: How to debug HW startup?
> Could You share a Linkit _defconfig with early serial debug enabled? > I'm decidedly missing something as, even enabling > > CONFIG_DEBUG_UART=y > CONFIG_DEBUG_UART_BASE=0x1e00 > CONFIG_DEBUG_UART_CLOCK=20 > CONFIG_DEBUG_UART_SHIFT=2 > CONFIG_DEBUG_UART_ANNOUNCE=y > > I still have plenty of errors: > > /home/mcon/vocore/__V2__/Buildroot/recov/host/bin/mipsel-linux-ld.bfd: > arch/mips/cpu/start.o: in function `wr_done': > (.text+0x650): undefined reference to `debug_uart_init' > /home/mcon/vocore/__V2__/Buildroot/recov/host/bin/mipsel-linux-ld.bfd: > (.text+0x654): undefined reference to `debug_uart_init' > /home/mcon/vocore/__V2__/Buildroot/recov/host/bin/mipsel-linux-ld.bfd: > board/vocore/vocore2/built-in.o: in function `board_early_init_f': > (.text.board_early_init_f+0x10): undefined reference to `printhex8' > /home/mcon/vocore/__V2__/Buildroot/recov/host/bin/mipsel-linux-ld.bfd: > common/built-in.o: in function `putc': > (.text.putc+0x18): undefined reference to `printch' > /home/mcon/vocore/__V2__/Buildroot/recov/host/bin/mipsel-linux-ld.bfd: > common/built-in.o: in function `puts': > (.text.puts+0x2c): undefined reference to `printch' > You need to pick a debug uart driver, e.g. CONFIG_DEBUG_UART_NS16550.
Re: How to debug HW startup?
Hi Stefan, 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 wanted, nonetheless, be prepared for further mishaps, but I have some other problems (see below). On 1/10/20 2:33 PM, Stefan Roese wrote: > Hi Mauro, > > (added Weijie to Cc) > > On 10.01.20 10:06, Mauro Condarelli wrote: >> >> >> On 1/10/20 7:31 AM, Stefan Roese wrote: >>> Hi Mauro, >>> >>> On 09.01.20 18:28, Mauro Condarelli wrote: I managed to brick my target. Situation: I have a board with a paleolithic (1.1.3) version of u-boot. I had been testing by loading in ram from USB: usb reset; fatload usb 0 8001 u-boot.bin; go 8001 and everything was ok. I changed a few settings (both defconfigs are attached below) and tried "the real thing" Unfortunately reflashing the actual boot produced a brick. It does not utter a single byte. >>> >>> Ugh. Too bad. >> I know... :( >> I will have to reflash the original using an external apparatus (which I don't have here, so I'll have to take target to another location, probably tomorrow morning), but question is: how do I debug such a situation? >>> >>> To debug very early problems, I suggest to use the DEBUG_UART interface >>> in U-Boot. I also used it quite a lot before - also on this platform. >>> >>> Please see: >>> >>> include/debug_uart.h: >>> >>> debug_uart_init(); >>> printhex8(0x01); >>> ... Could You share a Linkit _defconfig with early serial debug enabled? I'm decidedly missing something as, even enabling CONFIG_DEBUG_UART=y CONFIG_DEBUG_UART_BASE=0x1e00 CONFIG_DEBUG_UART_CLOCK=20 CONFIG_DEBUG_UART_SHIFT=2 CONFIG_DEBUG_UART_ANNOUNCE=y I still have plenty of errors: /home/mcon/vocore/__V2__/Buildroot/recov/host/bin/mipsel-linux-ld.bfd: arch/mips/cpu/start.o: in function `wr_done': (.text+0x650): undefined reference to `debug_uart_init' /home/mcon/vocore/__V2__/Buildroot/recov/host/bin/mipsel-linux-ld.bfd: (.text+0x654): undefined reference to `debug_uart_init' /home/mcon/vocore/__V2__/Buildroot/recov/host/bin/mipsel-linux-ld.bfd: board/vocore/vocore2/built-in.o: in function `board_early_init_f': (.text.board_early_init_f+0x10): undefined reference to `printhex8' /home/mcon/vocore/__V2__/Buildroot/recov/host/bin/mipsel-linux-ld.bfd: common/built-in.o: in function `putc': (.text.putc+0x18): undefined reference to `printch' /home/mcon/vocore/__V2__/Buildroot/recov/host/bin/mipsel-linux-ld.bfd: common/built-in.o: in function `puts': (.text.puts+0x2c): undefined reference to `printch' >>> >>> When using UART2 on the MT7628 please make sure to configure the pin >>> mux before using the debug uart. Otherwise nothing will get printed. >> I do *not* do anything explicitly in my code, but I have stanzas in .dts >> Is that supposed to be enough? (I attach my current .dts as I'm sorry to >> say I don't really fully grok .dts and I'm merely copying stanzas >> around). >> >> I have Your code in board/vocore/vocore2/board.c (attached), shouldn't >> that be enough? > > Yes, this should be enough when using UART2 IIRC. > > BTW: I just noticed that the VoCore uses the MT7628 and the LinkIt and > the GARDENA boards both use the MT7688. I don't remember the differences > but I don't think this should be a problem. AFAIK differences between MT7628 and MT7688 are restricted to WiFi radio section (MT7628 is 2r2t while MT7688 is 1r1t); any addendum to this I would like to know. >>> BTW: This might also be a problem on your board, if you use UART2 and >>> the muxing is not done no output will occur. >> I understand (see above). >> What could I have done so wrong? As You can see I changed only a few settings: --- configs/vocore_vocore2-ram_defconfig 2020-01-09 16:11:12.568096050 +0100 +++ configs/vocore_vocore2_defconfig 2020-01-09 16:07:10.528267378 +0100 @@ -1,9 +1,12 @@ CONFIG_MIPS=y -CONFIG_SYS_TEXT_BASE=0x8001 +CONFIG_SYS_TEXT_BASE=0x9c00 CONFIG_ENV_SIZE=0x1000 CONFIG_NR_DRAM_BANKS=1 CONFIG_ARCH_MTMIPS=y CONFIG_BOARD_VOCORE2=y +CONFIG_BOOT_ROM=y +CONFIG_ONBOARD_DDR2_SIZE_1024MBIT=y +CONFIG_ONBOARD_DDR2_CHIP_WIDTH_16BIT=y CONFIG_MIPS_BOOT_FDT=y CONFIG_ENV_VARS_UBOOT_CONFIG=y CONFIG_SYS_BOOT_GET_CMDLINE=y ... in a way that's very similar to boards based on the same SoC (linkit-smart-7688 and gardena-smart-gateway-mt7688). In the ancient u-boot I had to remove a header from the RAM version, but this was not needed with current u-boot. Did I forget some step? >>> >>> Did you never program U-Boot into SPI NOR before on your VoCore2? >> Yes. > > Autsch. > >> Up to now I've been using the RAM-version and loaded it from my old >> (paleolithic 1.1.3) vendor-provided u-boot. >> Note: I have modified and reflashed *that* u-boot several times, so I >> was kind of
Re: How to debug HW startup?
Hi Mauro, (added Weijie to Cc) On 10.01.20 10:06, Mauro Condarelli wrote: On 1/10/20 7:31 AM, Stefan Roese wrote: Hi Mauro, On 09.01.20 18:28, Mauro Condarelli wrote: I managed to brick my target. Situation: I have a board with a paleolithic (1.1.3) version of u-boot. I had been testing by loading in ram from USB: usb reset; fatload usb 0 8001 u-boot.bin; go 8001 and everything was ok. I changed a few settings (both defconfigs are attached below) and tried "the real thing" Unfortunately reflashing the actual boot produced a brick. It does not utter a single byte. Ugh. Too bad. I know... :( I will have to reflash the original using an external apparatus (which I don't have here, so I'll have to take target to another location, probably tomorrow morning), but question is: how do I debug such a situation? To debug very early problems, I suggest to use the DEBUG_UART interface in U-Boot. I also used it quite a lot before - also on this platform. Please see: include/debug_uart.h: debug_uart_init(); printhex8(0x01); ... When using UART2 on the MT7628 please make sure to configure the pin mux before using the debug uart. Otherwise nothing will get printed. I do *not* do anything explicitly in my code, but I have stanzas in .dts Is that supposed to be enough? (I attach my current .dts as I'm sorry to say I don't really fully grok .dts and I'm merely copying stanzas around). I have Your code in board/vocore/vocore2/board.c (attached), shouldn't that be enough? Yes, this should be enough when using UART2 IIRC. BTW: I just noticed that the VoCore uses the MT7628 and the LinkIt and the GARDENA boards both use the MT7688. I don't remember the differences but I don't think this should be a problem. BTW: This might also be a problem on your board, if you use UART2 and the muxing is not done no output will occur. I understand (see above). What could I have done so wrong? As You can see I changed only a few settings: --- configs/vocore_vocore2-ram_defconfig 2020-01-09 16:11:12.568096050 +0100 +++ configs/vocore_vocore2_defconfig 2020-01-09 16:07:10.528267378 +0100 @@ -1,9 +1,12 @@ CONFIG_MIPS=y -CONFIG_SYS_TEXT_BASE=0x8001 +CONFIG_SYS_TEXT_BASE=0x9c00 CONFIG_ENV_SIZE=0x1000 CONFIG_NR_DRAM_BANKS=1 CONFIG_ARCH_MTMIPS=y CONFIG_BOARD_VOCORE2=y +CONFIG_BOOT_ROM=y +CONFIG_ONBOARD_DDR2_SIZE_1024MBIT=y +CONFIG_ONBOARD_DDR2_CHIP_WIDTH_16BIT=y CONFIG_MIPS_BOOT_FDT=y CONFIG_ENV_VARS_UBOOT_CONFIG=y CONFIG_SYS_BOOT_GET_CMDLINE=y ... in a way that's very similar to boards based on the same SoC (linkit-smart-7688 and gardena-smart-gateway-mt7688). In the ancient u-boot I had to remove a header from the RAM version, but this was not needed with current u-boot. Did I forget some step? Did you never program U-Boot into SPI NOR before on your VoCore2? Yes. Autsch. Up to now I've been using the RAM-version and loaded it from my old (paleolithic 1.1.3) vendor-provided u-boot. Note: I have modified and reflashed *that* u-boot several times, so I was kind of confident I could do without much problem. Of course it's fully possible some initialization done by old code is missing in the new one. Which binary did you program? I flashed "u-boot.bin" which looks like a copy of "u-boot-dtb.bin"; Yes, both images are identical. this is exactly the same file I used for my RAM-based tests (after switching _defconfig and recompiling, of course). Do you have a list of differences of the LinkIt MT7688 and the VoCore2 board? Like DDR2 setup, UART etc? How do the fist line look like? Here my output: $ hexdump -n 256 u-boot.bin 000 013f 1000 4800 4080 010 * 100 Mine is quite similar: $ hexdump -n 256 u-boot.bin 000 013f 1000 4800 4080 010 * 100 Ok, this is not a problem. The image is the "correct" one. I'm about to go where there's a nailbed to reflash SPI NOR "from outside"; I plan to read back what's on flash before putting back the "old" u-boot to see if something went wrong while flashing (but I doubt it). Problem is how to proceed. Old code did a lot of hard-coded initialization (non-DT-based) which I don't (explicitly) do here (including a long RAM calibration I didn't even try to understand). The RAM code is nearly identical. The current mainline code is "cloned" from the MediaTek (paleolithic) version. So I don't suspect a problem here. This will change btw with the new code from Weijie. He re-wrote the early init code including the DDR/DDR2 code and its calibration. I already tested this code on the Linkit board and it worked there without any issues. Still the current DDR2 code "should" work on your board as well. I will bring back a certain number of working modules, so I will have a certain number of "tries" before I need to go back for hard reflashing; I should try t
Re: How to debug HW startup?
On 1/10/20 7:31 AM, Stefan Roese wrote:
> Hi Mauro,
>
> On 09.01.20 18:28, Mauro Condarelli wrote:
>> I managed to brick my target.
>>
>> Situation:
>> I have a board with a paleolithic (1.1.3) version of u-boot.
>> I had been testing by loading in ram from USB:
>> usb reset; fatload usb 0 8001 u-boot.bin; go 8001
>> and everything was ok.
>> I changed a few settings (both defconfigs are attached below)
>> and tried "the real thing"
>> Unfortunately reflashing the actual boot produced a brick.
>> It does not utter a single byte.
>
> Ugh. Too bad.
I know... :(
>> I will have to reflash the original using an external apparatus
>> (which I don't have here, so I'll have to take target to another
>> location, probably tomorrow morning), but question is:
>> how do I debug such a situation?
>
> To debug very early problems, I suggest to use the DEBUG_UART interface
> in U-Boot. I also used it quite a lot before - also on this platform.
>
> Please see:
>
> include/debug_uart.h:
>
> debug_uart_init();
> printhex8(0x01);
> ...
>
> When using UART2 on the MT7628 please make sure to configure the pin
> mux before using the debug uart. Otherwise nothing will get printed.
I do *not* do anything explicitly in my code, but I have stanzas in .dts
Is that supposed to be enough? (I attach my current .dts as I'm sorry to
say I don't really fully grok .dts and I'm merely copying stanzas around).
I have Your code in board/vocore/vocore2/board.c (attached), shouldn't
that be enough?
> BTW: This might also be a problem on your board, if you use UART2 and
> the muxing is not done no output will occur.
I understand (see above).
>> What could I have done so wrong?
>>
>> As You can see I changed only a few settings:
>>
>> --- configs/vocore_vocore2-ram_defconfig 2020-01-09
>> 16:11:12.568096050 +0100
>> +++ configs/vocore_vocore2_defconfig 2020-01-09 16:07:10.528267378
>> +0100
>> @@ -1,9 +1,12 @@
>> CONFIG_MIPS=y
>> -CONFIG_SYS_TEXT_BASE=0x8001
>> +CONFIG_SYS_TEXT_BASE=0x9c00
>> CONFIG_ENV_SIZE=0x1000
>> CONFIG_NR_DRAM_BANKS=1
>> CONFIG_ARCH_MTMIPS=y
>> CONFIG_BOARD_VOCORE2=y
>> +CONFIG_BOOT_ROM=y
>> +CONFIG_ONBOARD_DDR2_SIZE_1024MBIT=y
>> +CONFIG_ONBOARD_DDR2_CHIP_WIDTH_16BIT=y
>> CONFIG_MIPS_BOOT_FDT=y
>> CONFIG_ENV_VARS_UBOOT_CONFIG=y
>> CONFIG_SYS_BOOT_GET_CMDLINE=y
>> ... in a way that's very similar to boards based on the same SoC
>> (linkit-smart-7688 and gardena-smart-gateway-mt7688).
>>
>> In the ancient u-boot I had to remove a header from the RAM
>> version, but this was not needed with current u-boot.
>>
>> Did I forget some step?
>
> Did you never program U-Boot into SPI NOR before on your VoCore2?
Yes.
Up to now I've been using the RAM-version and loaded it from my old
(paleolithic 1.1.3) vendor-provided u-boot.
Note: I have modified and reflashed *that* u-boot several times, so I
was kind of confident I could do without much problem.
Of course it's fully possible some initialization done by old code is
missing in the new one.
> Which binary did you program?
I flashed "u-boot.bin" which looks like a copy of "u-boot-dtb.bin";
this is exactly the same file I used for my RAM-based tests
(after switching _defconfig and recompiling, of course).
> How do the fist line look like? Here my output:
>
> $ hexdump -n 256 u-boot.bin
> 000 013f 1000 4800 4080
> 010
> *
> 100
Mine is quite similar:
$ hexdump -n 256 u-boot.bin
000 013f 1000 4800 4080
010
*
100
I'm about to go where there's a nailbed to reflash SPI NOR
"from outside"; I plan to read back what's on flash before
putting back the "old" u-boot to see if something went wrong
while flashing (but I doubt it).
Problem is how to proceed.
Old code did a lot of hard-coded initialization (non-DT-based)
which I don't (explicitly) do here (including a long RAM calibration
I didn't even try to understand).
I will bring back a certain number of working modules, so I will
have a certain number of "tries" before I need to go back for
hard reflashing; I should try to minimize commuting ;)
> Thanks,
> Stefan
Many Thanks
Mauro
// SPDX-License-Identifier: GPL-2.0
#include
#include
/ {
#address-cells = <1>;
#size-cells = <1>;
compatible = "ralink,mt7628a-soc";
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu@0 {
compatible = "mti,mips24KEc";
device_type = "cpu";
reg = <0>;
};
};
cpuintc: interrupt-controller {
#address-cells = <0>;
#interrupt-cells = <1>;
interrupt-controller;
compatible = "mti,cpu-interrupt-controller";
};
clk48m: clk48m@0 {
compatible = "fixed-clock";
clock-
Re: How to debug HW startup?
Hi Mauro, On 09.01.20 18:28, Mauro Condarelli wrote: I managed to brick my target. Situation: I have a board with a paleolithic (1.1.3) version of u-boot. I had been testing by loading in ram from USB: usb reset; fatload usb 0 8001 u-boot.bin; go 8001 and everything was ok. I changed a few settings (both defconfigs are attached below) and tried "the real thing" Unfortunately reflashing the actual boot produced a brick. It does not utter a single byte. Ugh. Too bad. I will have to reflash the original using an external apparatus (which I don't have here, so I'll have to take target to another location, probably tomorrow morning), but question is: how do I debug such a situation? To debug very early problems, I suggest to use the DEBUG_UART interface in U-Boot. I also used it quite a lot before - also on this platform. Please see: include/debug_uart.h: debug_uart_init(); printhex8(0x01); ... When using UART2 on the MT7628 please make sure to configure the pin mux before using the debug uart. Otherwise nothing will get printed. BTW: This might also be a problem on your board, if you use UART2 and the muxing is not done no output will occur. What could I have done so wrong? As You can see I changed only a few settings: --- configs/vocore_vocore2-ram_defconfig 2020-01-09 16:11:12.568096050 +0100 +++ configs/vocore_vocore2_defconfig 2020-01-09 16:07:10.528267378 +0100 @@ -1,9 +1,12 @@ CONFIG_MIPS=y -CONFIG_SYS_TEXT_BASE=0x8001 +CONFIG_SYS_TEXT_BASE=0x9c00 CONFIG_ENV_SIZE=0x1000 CONFIG_NR_DRAM_BANKS=1 CONFIG_ARCH_MTMIPS=y CONFIG_BOARD_VOCORE2=y +CONFIG_BOOT_ROM=y +CONFIG_ONBOARD_DDR2_SIZE_1024MBIT=y +CONFIG_ONBOARD_DDR2_CHIP_WIDTH_16BIT=y CONFIG_MIPS_BOOT_FDT=y CONFIG_ENV_VARS_UBOOT_CONFIG=y CONFIG_SYS_BOOT_GET_CMDLINE=y ... in a way that's very similar to boards based on the same SoC (linkit-smart-7688 and gardena-smart-gateway-mt7688). In the ancient u-boot I had to remove a header from the RAM version, but this was not needed with current u-boot. Did I forget some step? Did you never program U-Boot into SPI NOR before on your VoCore2? Which binary did you program? How do the fist line look like? Here my output: $ hexdump -n 256 u-boot.bin 000 013f 1000 4800 4080 010 * 100 Thanks, Stefan
