[U-Boot] [PATCH 13/13] mips: jz47xx: Add Creator CI20 platform

Marek Vasut
2017-02-15T22:08:24Z

On 02/15/2017 10:50 PM, Tom Rini wrote:
> On Wed, Feb 15, 2017 at 09:46:38PM +0100, Marek Vasut wrote:
>> On 02/15/2017 12:11 AM, Tom Rini wrote:
>>> On Wed, Feb 15, 2017 at 12:03:32AM +0100, Marek Vasut wrote:
>>>> On 02/14/2017 11:58 PM, Tom Rini wrote:
>>>>> On Sun, Feb 12, 2017 at 12:52:45PM +0100, Andreas F?rber wrote:
>>>>>> Hi Marek,
>>>>>>
>>>>>> Am 01.12.2016 um 02:06 schrieb Marek Vasut:
>>>>>>> From: Paul Burton <paul.burton@imgtec.com>
>>>>>>>
>>>>>>> Add support for the Creator CI20 platform based on the JZ4780 SoC.
>>>>>>> The DTS file comes from Linux 4.6 as of revision
>>>>>>> 78800558d104e003f9ae92e0107f1de39cf9de9f
>>>>>>>
>>>>>>> So far, there are still a few details which will have to be fixed
>>>>>>> once they are fleshed out in Linux:
>>>>>>> - pinmux: Thus far, this board just pokes the pinmux registers to
>>>>>>> set the pinmux. For MMC in SPL, this will have to stay.
>>>>>>> But for full u-boot a proper pinmux driver will have to
>>>>>>> be added once the pinmux semantics in DT are in mainline
>>>>>>> Linux.
>>>>>>> - ethernet,efuse: DT bindings are missing from mainline Linux.
>>>>>>>
>>>>>>> Signed-off-by: Marek Vasut <marex@denx.de>
>>>>>>> Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
>>>>>>> Cc: Paul Burton <paul.burton@imgtec.com>
>>>>>>> ---
>>>>>>> arch/mips/dts/Makefile | 1 +
>>>>>>> arch/mips/dts/ci20.dts | 114 ++++++++++++++
>>>>>>> arch/mips/mach-jz47xx/Kconfig | 11 ++
>>>>>>> board/imgtec/ci20/Kconfig | 35 +++++
>>>>>>> board/imgtec/ci20/Makefile | 5 +
>>>>>>> board/imgtec/ci20/README | 10 ++
>>>>>>> board/imgtec/ci20/ci20.c | 354 ++++++++++++++++++++++++++++++++++++++++++
>>>>>>> configs/ci20_defconfig | 28 ++++
>>>>>>> include/configs/ci20.h | 105 +++++++++++++
>>>>>>> 9 files changed, 663 insertions(+)
>>>>>>> create mode 100644 arch/mips/dts/ci20.dts
>>>>>>> create mode 100644 board/imgtec/ci20/Kconfig
>>>>>>> create mode 100644 board/imgtec/ci20/Makefile
>>>>>>> create mode 100644 board/imgtec/ci20/README
>>>>>>> create mode 100644 board/imgtec/ci20/ci20.c
>>>>>>> create mode 100644 configs/ci20_defconfig
>>>>>>> create mode 100644 include/configs/ci20.h
>>>>>>
>>>>>> I've looked into testing the remainder of this patchset, not seeing a
>>>>>> newer version. You can find my branch here:
>>>>>>
>>>>>> https://github.com/afaerber/u-boot/commits/ci20
>>>>> [snip]
>>>>>> LD spl/u-boot-spl
>>>>>> mipsel-suse-linux-ld.bfd: u-boot-spl section `.data' will not fit in
>>>>>> region `.sram'
>>>>>> mipsel-suse-linux-ld.bfd: region `.sram' overflowed by 288 bytes
>>>>>
>>>>> I can recreate that too here real quick, but can't test out changes on
>>>>> my Ci20 right now. Can you try:
>>>>>
>>>>> diff --git a/include/configs/ci20.h b/include/configs/ci20.h
>>>>> index 4503adb..9e2ad7b 100644
>>>>> --- a/include/configs/ci20.h
>>>>> +++ b/include/configs/ci20.h
>>>>> @@ -70,10 +70,10 @@
>>>>> /* SPL */
>>>>> #define CONFIG_SPL_FRAMEWORK
>>>>>
>>>>> -#define CONFIG_SPL_STACK 0xf4008000 /* only max. 2KB spare! */
>>>>> +#define CONFIG_SPL_STACK 0xf4008200 /* only max. 1.5KB spare! */
>>>>>
>>>>> #define CONFIG_SPL_TEXT_BASE 0xf4000a00
>>>>> -#define CONFIG_SPL_MAX_SIZE ((14 * 1024) - 0xa00)
>>>>> +#define CONFIG_SPL_MAX_SIZE ((14 * 1024) - 0x800)
>>>>
>>>> This will not work, the stack is configured at it's limit already.
>>>>
>>>>> #define CONFIG_SPL_BSS_START_ADDR 0xf4004000
>>>>> #define CONFIG_SPL_BSS_MAX_SIZE 0x00002000 /* 512KB, arbitrary */
>>>>>
>>>>>
>>>>> Now, off the top of my head I'm only giving myself a 50/50 chance of
>>>>> having moved the stack address in the correct direction. And note that
>>>>> I don't know why we say only max of 2KB for stack, and then ensure we
>>>>> have 2.5KB of room, but I've shifted 512 bytes from one side to the
>>>>> other. And it's quite probable that we should make use having SPL stack
>>>>> get moved into DDR
>>>>
>>>> You mean the DDR which you init in the SPL ? :)
>>>
>>> Yes, I mean the DDR which we init in the SPL, after we've init'd it, so
>>> that we can work more comfortably in cramped and constrained spaces.
>>
>> You know, you are still limited by the 14 kiB load limit of the BootROM.
>> I think there's more than 16 kiB of SRAM total, so there's no real
>> problem with the stack. The problem is that 14 kiB load limit of the
>> BootROM, it will NOT LOAD MORE than 14 kiB of code . I tried (because,
>> well, 14 kiB is too small). IT DOES NOT WORK.
>
> Can we use those last 2KiB of SRAM for our stack or does that freak out
> the BootROM?

IIRC I tried pretty much everything to squeeze more space out of this
chip and this is the only thing that worked.

> If so, we should tweak the above definitions to set the
> hard limit at 14 * SZ_1K and put stack at 0xf4004200 ?

Be my guest, research the hell out of this ... if you can figure
something out, great.

> Where is 0xf4008000 in the memory map?

RTFM , seriously ...

>>>>> , but I don't have the memory map handy either (and
>>>>> based on the above snippets I'm confused as CONFIG_SPL_BSS_START_ADDR
>>>>> should be in DDR space, I don't know if internal memory directly follows
>>>>> into DDR here or what).
>>>>>
>>>>> I do want to reiterate that I am eager to have Ci20 be working in
>>>>> mainline as I have one and I want to figure out how to include it in my
>>>>> farm, or at least manual testing from time to time. Thanks!
>>>>
>>>> Well, these patches were rotting on the list for year or so without
>>>> getting any attention, until the point I had to scream on the IRC to get
>>>> ANY review comments, multiple times, so I really see a lot of interest
>>>> in getting this in, indeed :)
>>>
>>> Yeah, I feel bad about not having more time for all of the various
>>> things I'd like to see happen, happen.
>>
>> You should ! ;-)
>>
>>> But that's why I bought the Ci20
>>> and Ci40 (and some other boards) as a regular person rather than try and
>>> get a freebie.
>>
>> I feel triggered by this, I also bought the CI20 (and not CI40, because
>> it wasn't available ... but I will buy one eventually when I feel like
>> delving into more masochistic stuff ...)
>
> Sorry, I was trying to point out that I have this board (and some
> others) that I've purchased and would like to have mainline U-Boot on,
> but cannot as I have not the time to try and pick them up as project
> boards. Thanks!

Well, I also don't have the time to keep rebasing this patchset over and
over and over and solving why the hell does it no longer fit AGAIN. So
too bad ...

--
Best regards,
Marek Vasut