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.bur...@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 <ma...@denx.de> >>>>>>> Cc: Daniel Schwierzeck <daniel.schwierz...@gmail.com> >>>>>>> Cc: Paul Burton <paul.bur...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot