[RFC] Vocore2 MMC needs clock patches

[Mauro Condarelli]

Hi,
I'm clearly out of my depth:

=> icache flush
No arch specific invalidate_icache_all available!
=> dcache flush
No arch specific flush_dcache_all available!
=> icache off 
=> dcache off 

Ooops:
$ 0   : 00000000 00000000 87e806c8 00000000
$ 4   : ffffffd0 00000014 87e80518 87fce61c
$ 8   : 87e7bc00 00000010 00000000 fffffffc
$12   : 00000000 0000000f 00000006 00000007
$16   : ffffffd0 00000000 00000000 0000002f
$20   : 87e81350 87fe8528 00000000 00000001
$24   : 00000016 87f84130                 
$28   : 87f882a0 87e7bba8 87e81362 87fa9524
Hi    : 00000006
Lo    : 000640a2
epc   : 87fa1600 (text 80221600)
ra    : 87fa9524 (text 80229524)
Status: 00000006
Cause : d0008028 (ExcCode 0a)
PrId  : 00019655
### ERROR ### Please RESET the board ###

Thanks
Mauro

On 1/22/20 9:16 PM, Mauro Condarelli wrote:
> Hi Stefan,
>
> On 1/21/20 1:08 PM, Stefan Roese wrote:
>> Hi Mauro,
>>
>> On 21.01.20 12:27, Mauro Condarelli wrote:
>>> Thanks Weijie,
>>> I made the changes You suggested.
>>> I have also seen You sent a new version of Your patches.
>>> Since mine are based on yours I *think* I should suspend
>>> sending my VoCore2 patches till Yours are fixed and integrated
>>> into master.
>>>
>>> @Stefan Roese: is this the right course of action?
>> I think in the current state of Weijie's patches (v3), you can resume
>> sending your VoCore2 support based on this latest patchset to the
>> list. Please don't attach a patch but send it inline next time
>> (git send-email) to enable review.
> I will send next iteration as soon as I fix the reflash problem (see below).
>  
> ===8<----
>>> Side Question: Stefan wrote:
>>>> Most of this can be done by using the
>>>> RAM version now (again). There is no additional RAM booting target now
>>>> any more. You can use the normal U-Boot image for this now. Please note
>>>> the changes TEXT_BASE here. Its now 0x80200000.
>>> This actually seems to work right if I start from my original u-boot
>>> (1.1.3,
>>> flashed at start of SPI NOR), but it fails if I start from a flashed
>>> (at the
>>> same location) u-boot-mtmips.bin
>>> I *think* this happens because unpacking actually writes u-boot at
>>> 0x80200000 and runs it from there, so "load usb 0:1 80200000 u-boot.bin"
>>> (or equivalent) will overwrite the running u-boot and the following
>>> "go ${fileaddr}" fails:
>>>     ## Starting application at 0x80200000 ...
>>>     <DEAD>
>> No, U-Boot relocates itself to the end of RAM and runs from there. So
>> this should work. Perhaps a cache flush is missing.
>>
>> I'll give it a try on my LinkIt board as well later.
> Did You manage to test this?
> I am currently testing loading from "paleolithic" u-boot, but I want to fix
> this before I finalize VoCore2 patches.
>
> I tried to do some manual testing enabling CONFIG_CMD_CACHE, but this
> bombs with Weijie patches with:
>
>   LD      u-boot
> mipsel-linux-ld.bfd: cmd/built-in.o: in function `do_icache':
> cmd/cache.c:(.text.do_icache+0x5c): undefined reference to `icache_disable'
> mipsel-linux-ld.bfd: cmd/cache.c:(.text.do_icache+0x6c): undefined
> reference to `icache_enable'
> mipsel-linux-ld.bfd: cmd/cache.c:(.text.do_icache+0x8c): undefined
> reference to `icache_status'
> make: *** [Makefile:1697: u-boot] Error 1
>
> icache seems enabled unconditionally in
> arch/mips/mach-mtmips/mt7628/lowlevel_init.S::73+
>
> I will try to add dummy functions just-to-play.
>
> Please advise
>
>> Thanks,
>> Stefan
> Regards and Many Thanks
> Mauro
>