Debugging VoCore2 ROM Startup
Mauro Condarelli
mc5686 at mclink.it
Wed Jan 15 18:25:25 CET 2020
On 1/15/20 5:20 PM, Stefan Roese wrote:
> On 15.01.20 16:55, Mauro Condarelli wrote:
>
> <snip>
===8<------
> in particular:
>>
>> b0000010: 00065144
>> System Configuration Register 0 ->0000 0000 0000 0110 0101 0001 0100
>> 0100
>> 0000 0000 TEST_CODE : None
>> 000 Reserved
>> 0 0110 0101 BS_SHADOW : ???
>> 000 Rseserved
>> 1 DBG_JTAG_MODE 1: Normal Boot-up
>> 0 TEST_MODE_1 : ???
>> 1 XTAL_FREQ_SEL 1: 40MHz SMD (3225)
>> 0 EXT_BG 0: BG clock from PMU
>> 0 TEST_MODE_0 0: SUTIF
>> 010 CHIP_MODE 010: Boot from XTAL (boot from SPI 3-Byte
>> ADR)
>> 0 DRAM_TYPE 0: DDR2
>>
>> which looks good to me; as said the only difference is
>> the 3-Byte SPI Addr vs. 4-Byte SPI Addr; is it relevant?
>> AFAIK my soldered SPI NOR:
>>
>> SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total
>>
>> has 3-Byte SPI Address. From data sheet:
>> The Read Data Bytes (READ) command is followed by a 3-byte address
>> (A23-A0), ...
>> What is on LinkIt?
>
> Its strapped to 4-byte. And on the GARDENA board as well.
>
>> Does that change anything in u-boot?
>
> I would not expect this to change anything, if its configured to 3-byte
> other that that you can't access anything above 16 MiB.
My SPI NOR is 16 MiB, so I cannot access anything beyond that ;)
> If you are really out of ideas and its possible for you, then please
> change
> the strapping to 4-byte "chapter 3.4 Bootstrapping Pins Description".
That wouldn't be easy as it's a SMD resistor soldered directly on the
Module.
Let's keep that as "last resort".
===8<------
>>
>>>> Note: I assumed u-boot-mtmips.bin is linked at 9c000000, right?
>>>
>>> You don't need to know where it is linked to if you program it into
>>> SPI NOR. But yes, the first stage the SPL is linked to 0x9c000000.
>> Can You elaborate, please?
>
> Each image generated to boot from SPI NOR needs to be linked to 9c000000.
> This is what the ROM image (non-RAM) of mainline does and the SPL image
> of the dual image version (SPL plus main U-Boot proper) does.
>
>> I know for sure that if I flash at 30000 a u-boot that has been compiled
>> with SYS_TEXT_BASE = 0x9c000000 it will not start with "go 9c030000"
>> I need to rebuild with SYS_TEXT_BASE = 0x9c030000.
>
> But you flash at offset 0 in SPI NOR, right? That's where the SoC starts
> reading the bootloader binary after a reset or on power-up.
I was trying to say that, in my "secondary u-boot" attempts, where I
start from "paleolithic" and then do a "go <addr>" I need to put the
secondary at the same address specified in SYS_TEXT_BASE.
I mean:
if I want to boot directly from new then
SYS_TEXT_BASE = 0x9c000000
flash at start of SPI NOR
go 9c000000
else if I want to start "secondary" then
SYS_TEXT_BASE = 0x9c030000
flash at offset 30000 in SPI NOR
go 9c030000
Any other combination does not work (i.e.: I cannot flash and run at
start an u-boot compiled with SYS_TEXT_BASE = 0x9c030000 and
vice versa).
Note: I had to edit directly .config to change SYS_TEXT_BASE, apparently
it is visible in menuconfig only for ARM; am I missing something?
>
===8<------
I do have a led I can use for crude signalling, but I'm not really familiar
with mips Assembly.
Can You share the code to turn it on? (it is connected to
GPIO44/WLED(pin144).
>
> Thanks,
> Stefan
>
TiA!
Mauro
More information about the U-Boot
mailing list