On Monday 02 January 2023 09:29:10 Heiko Schocher wrote:
> Hello Pali
>
> On 01.01.23 07:57, Heiko Schocher wrote:
> > Hello Pali,
> >
> > On 31.12.22 16:37, Pali Rohár wrote:
> >> On Saturday 31 December 2022 16:31:57 Heiko Schocher wrote:
> >>> Hello Pali,
> >>>
> >>> On 31.12.22 14:36, Heiko Schocher wrote:
> >>>> Hello Pali,
> >>>>
> >>>> On 31.12.22 13:58, Pali Rohár wrote:
> >>>>> On Saturday 31 December 2022 10:36:07 Heiko Schocher wrote:
> >>>>>> Hello Pali,
> >>>>>>
> >>>>>> On 28.12.22 19:18, Pali Rohár wrote:
> >>>>>>> U-Boot build system builds final U-Boot binary for socrates board in
> >>>>>>> custom
> >>>>>>> file u-boot-socrates.bin (instead of standard u-boot.bin). Output
> >>>>>>> target
> >>>>>>> file u-boot-socrates.bin is generated by binman as defined in board
> >>>>>>> binman
> >>>>>>> config file arch/powerpc/dts/socrates-u-boot.dtsi.
> >>>>>>>
> >>>>>>> But binman was disabled in commit 5af42eafd7e1 ("Makefile: Reduce
> >>>>>>> usage of
> >>>>>>> custom mpc85xx u-boot.bin target") for all mpc85xx boards which do
> >>>>>>> not use
> >>>>>>> standard powerpc binman config file arch/powerpc/dts/u-boot.dtsi and
> >>>>>>> boards
> >>>>>>> which do not require binman at all.
> >>>>>>>
> >>>>>>> The only such mpc85xx board is socrates. So since that commit, U-Boot
> >>>>>>> does
> >>>>>>> not final binary for socrates board anymore.
> >>>>>>>
> >>>>>>> Fix this issue by re-enabling binman for socrates board. And build
> >>>>>>> process
> >>>>>>> starts again producing u-boot-socrates.bin binary.
> >>>>>>>
> >>>>>>> Note that build process for this socrates board always produce
> >>>>>>> u-boot.bin
> >>>>>>> binary which is broken and not usable for socrates board. Long term
> >>>>>>> solution should be to disable building broken binary u-boot.bin and
> >>>>>>> then
> >>>>>>> renaming u-boot-socrates.bin to u-boot.bin, or switching to use common
> >>>>>>> powerpc binman config file arch/powerpc/dts/socrates-u-boot.dtsi (if
> >>>>>>> it is
> >>>>>>> possible).
> >>>>>>>
> >>>>>>> Fixes: 5af42eafd7e1 ("Makefile: Reduce usage of custom mpc85xx
> >>>>>>> u-boot.bin target")
> >>>>>>> Signed-off-by: Pali Rohár <p...@kernel.org>
> >>>>>>> ---
> >>>>>>> Heiko Schocher: Could you test if u-boot is still working on this
> >>>>>>> board?
> >>>>>>>
> >>>>>>> Tom Rini: Cannot be this issue handled by CI? For example that CI
> >>>>>>> check
> >>>>>>> build process produce required output binaries?
> >>>>>>> ---
> >>>>>>> arch/powerpc/cpu/mpc85xx/Kconfig | 1 +
> >>>>>>> 1 file changed, 1 insertion(+)
> >>>>>>
> >>>>>> With this patch, u-boot-socrates.bin is build again, so yes...
> >>>>>>
> >>>>>> Tested-by: Heiko Schocher <h...@denx.de>
> >>>>>>
> >>>>>> ... but current u-boot does not boot anymore on this board ... I have
> >>>>>> to
> >>>>>> dig into, obvious difference I see in hexdump is:
> >>>>>>
> >>>>>> old (2022.01) u-boot:
> >>>>>> """
> >>>>>> 00001930 74 65 00 6f 66 66 73 65 74 00 73 74 64 6f 75 74
> >>>>>> |te.offset.stdout|
> >>>>>> 00001940 2d 70 61 74 68 00 ff ff ff ff ff ff ff ff ff ff
> >>>>>> |-path...........|
> >>>>>> 00001950 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >>>>>> |................|
> >>>>>> *
> >>>>>> 00020000 27 05 19 56 3c 60 e4 01 60 63 3f 10 38 63 fb f0
> >>>>>> |'..V<`..`c?.8c..|
> >>>>>> 00020010 3c 80 e4 01 60 84 40 00 38 00 00 00 38 84 ff fc
> >>>>>> |<...`.@.8...8...|
> >>>>>> 00020020 90 04 00 00 7c 04 18 40 40 82 ff f4 3c 80 e4 01
> >>>>>> |....|..@@...<...|
> >>>>>>
> >>>>>> """
> >>>>>>
> >>>>>> New
> >>>>>> """
> >>>>>> 00001930 74 65 00 6f 66 66 73 65 74 00 73 74 64 6f 75 74
> >>>>>> |te.offset.stdout|
> >>>>>> 00001940 2d 70 61 74 68 00 ff ff ff ff ff ff ff ff ff ff
> >>>>>> |-path...........|
> >>>>>> 00001950 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >>>>>> |................|
> >>>>>> *
> >>>>>> 00020000 3c 60 e4 01 60 63 3f 10 38 63 fb f0 3c 80 e4 01
> >>>>>> |<`..`c?.8c..<...|
> >>>>>> 00020010 60 84 40 00 38 00 00 00 38 84 ff fc 90 04 00 00
> >>>>>> |`.@.8...8.......|
> >>>>>> 00020020 7c 04 18 40 40 82 ff f4 3c 80 e4 01 60 84 3f 20
> >>>>>> ||..@@...<...`.? |
> >>>>>>
> >>>>>> """
> >>>>>>
> >>>>>> So "U-Boot magic" is misssing ...
> >>>>>
> >>>>> It was removed in commit 2dcf776ebcf7 ("powerpc: mpc85xx: Drop _start
> >>>>> symbol").
> >>>>> Was it used for something?
> >>>>
> >>>> I think (hope) not!
> >>>>
> >>>>>> reset vector at end of image is for both the same:
> >>>>>>
> >>>>>> 000bfff0 ff ff ff ff ff ff ff ff ff ff ff ff 4b ff f0 04
> >>>>>> |............K...|
> >>>>>> 000c0000
> >>>>>
> >>>>> 4b ff f0 04 is ppc branch instruction pos-0xffc, so to offset 0xbf000
> >>>>> in dumped file (not available in the output). I think this is correct.
> >>>>
> >>>> Yes, this is correct.
> >>>>
> >>>>>
> >>>>>> I have to dig deeper into it, to find out what have changed in the
> >>>>>> meantime,
> >>>>>> (Think I start a "git bisect") just find some more time for it...
> >>>>>
> >>>>> I think that git bisect would be needed to investigate what is the
> >>>>> problematic commit.
> >>>>>
> >>>>
> >>>> Just bisecting it ... and commit:
> >>>> """
> >>>> commit 985503439762c3168aeb80f529bb9bbcd773dd2c
> >>>> Author: Simon Glass <s...@chromium.org>
> >>>> Date: Thu Dec 16 20:59:31 2021 -0700
> >>>>
> >>>> fdt: Don't call board_fdt_blob_setup() without OF_BOARD
> >>>> """
> >>>>
> >>>> poped up ... so I enabled CONFIG_OF_BOARD for socrates build to get
> >>>> board specific function board_fdt_blob_setup() again called, and
> >>>> with this change board boots again, based on this commit!
> >>>>
> >>>> But ... building current head:
> >>>> 3089d12a02efd1dc5dce01e0ec0fda9142693b11
> >>>>
> >>>> with this change, again, no u-boot output ...so there is a next "git
> >>>> bisect"
> >>>> round necessary. I have to stop now, else I get an angry wife ... will
> >>>> continue
> >>>> next week... hopefully with a good result...
> >>>>
> >>>> Have a good slide to the new year!
> >>>
> >>> Next git bisect round shows up:
> >>> """
> >>> commit be7dbb60c5bfa38ea444fe7de1dca8bd35f83f5b (refs/bisect/bad)
> >>> Author: Tom Rini <tr...@konsulko.com>
> >>> Date: Sun Dec 12 22:12:30 2021 -0500
> >>>
> >>> Convert CONFIG_SYS_IMMR to Kconfig
> >>> """
> >>>
> >>> and yes, config symbol:
> >>>
> >>> CONFIG_SYS_IMMR=0xff700000
> >>>
> >>> is crap for socrates... you fixed this already in mainline with
> >>> """
> >>> commit 39f42fe20a8239c6a878f7fac03e758b2117009e
> >>> Author: Pali Rohár <p...@kernel.org>
> >>> Date: Mon May 2 18:29:25 2022 +0200
> >>>
> >>> powerpc: mpc85xx: Set default SYS_IMMR value for P1/P2 CPUs
> >>>
> >>> This reduce usage of per-board custom settings.
> >>> """
> >>
> >> This commit fixed SYS_IMMR only for ARCH_P1* and ARCH_P2*. Socrates is
> >> ARCH_MPC8544, so I'm not sure if that my commit really fixed it for
> >> MPC8544. Please recheck current master that CONFIG_SYS_IMMR is set to
> >> the same value as in old u-boot version where board worked fine.
> >>
> >> SYS_IMMR should be set to the CCSR address *after* CCSR relocation.
> >> And also check SYS_CCSRBAR_DEFAULT that is is CCSR address *befere* CCSR
> >> relocation (it should be reset address).
> >
> > Yes, I already checked it, looked fine. Will do a new bisect soon.
>
> Found the problematic commit:
> """
> commit 2f8a6db5d83b103e372172422a3d0aff873f1299
> Author: Tom Rini <tr...@konsulko.com>
> Date: Tue Dec 14 13:36:40 2021 -0500
>
> Finish conversion of CONFIG_SYS_CLK_FREQ to Kconfig
>
> In order to finish moving this symbol to Kconfig for all platforms, we
> need to do a few more things. First, for all platforms that define this
> to a function, introduce CONFIG_DYNAMIC_SYS_CLK_FREQ, similar to
> CONFIG_DYNAMIC_DDR_CLK_FREQ and populate clock_legacy.h. This entails
> also switching all users from CONFIG_SYS_CLK_FREQ to get_board_sys_clk()
> and updating a few preprocessor tests.
>
> With that done, all platforms that define a value here can be converted
> to Kconfig, and a fall-back of zero is sufficiently safe to use (and
> what is used today in cases where code may or may not have this
> available). Make sure that code which calls this function includes
> <clock_legacy.h> to get the prototype.
>
> Signed-off-by: Tom Rini <tr...@konsulko.com>
> """
>
> Adding:
> +CONFIG_SYS_CLK_FREQ=66666666
> to socrates_defconfig helps!
>
> But... now I see one more problem
> """
> U-Boot 2023.01-rc4 ...
>
> CPU: 8544, Version: 2.1, (0x80340121)
> Core: e500v2, Version: 2.3, (0x80210023)
> Clock Configuration:
> CPU0:666.667 MHz,
> CCB:333.333 MHz,
> DDR:166.667 MHz (333.333 MT/s data rate), LBC:333.333 MHz
> L1: D-cache 32 KiB enabled
> I-cache 32 KiB enabled
> Model: abb,socrates
> Board: Socrates, serial# 1012983726
> PCI1: 32 bit, 33 MHz (PCI_CLK)
> DRAM: Detected UDIMM M2SK-12MD4C06-M
> 512 MiB (DDR2, 64-bit, CL=4, ECC off)
> Core: 16 devices, 10 uclasses, devicetree: board
> Flash: 32 MiB
> L2: 256 KiB enabled
> NAND: 1024 MiB
> Loading Environment from Flash... OK
> In: serial
> Out: serial
> Err: serial
> PCI: Failed autoconfig bar 18
> PCI: Failed autoconfig bar 20
> Net: Bad trap at PC: f3da3dbc, SR: 29200, vector=e00
> NIP: F3DA3DBC XER: 00000000 LR: 1FF862C4 REGS: 1fb4a390 TRAP: 0e00 DAR:
> 00000000
> MSR: 00029200 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 00
>
> GPR00: 1FF86BDC 1FB4A480 1FB4BEC0 00000000 00000001 1FB4C298 00000009 000018B5
> GPR08: E0024000 F3DA3DBF 0000000F 1FB4A4C0 42000428 7AA2CCF8 00000000 1FFF0000
> GPR16: 1FFF1D1C 1FFF1D6C 1FFF0904 1FB4A3F8 1FFA8430 1FFA887E 1FFB4FAE 00000001
> GPR24: 1FFF2CC8 00000001 00000009 1FB4C298 00000000 00000001 1FFBF8D4 00000000
> Call backtrace:
> 1FF78ECC 1FF86BDC 1FF8580C 1FF76CAC 1FF78194 1FFA7700 1FF6A75C
> 1FF6AA78 1FF50F3C
> Exception in kernel pc f3da3dbc signal 0
>
> """
>
> Uff... at that the time a lot of problems came in ... I am so sorry, that my
> CI does not run currently :-(
>
> So ... next round if bisceting ...
Hello! This looks better. Everything is loaded, just PCI has some memory
issues. Have you tried to find why is PCI bus broken? I have one commit
for drivers/pci/pci_mpc85xx.c PCI driver which touches PCI config space
in git history. Maybe it could be related?
> bye,
> Heiko
> >
> > bye,
> > Heiko
> >>
> >>> but with current HEAD, board still does not boot, CONFIG_SYS_IMMR is
> >>> correct...
> >>>
> >>> puh... so I have to git bisect in a third round with correcting IMMR
> >>> value between your fix and commit be7dbb60c5
> >>>
> >>> bye,
> >>> Heiko
> >>>
> >>>>
> >>>> bye,
> >>>> Heiko
> >>>>
> >>>>
> >>>>>> Nevertheless, I think, this patch can go in...
> >>>>>>
> >>>>>> bye,
> >>>>>> Heiko
> >>>>>>
> >>>>>> --
> >>>>>> DENX Software Engineering GmbH, Managing Director: Erika Unter
> >>>>>> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> >>>>>> Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
> >>>>
> >>>>
> >>>> bye,
> >>>> Heiko
> >>>>
> >>>
> >>> --
> >>> DENX Software Engineering GmbH, Managing Director: Erika Unter
> >>> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> >>> Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
> >
>
> --
> DENX Software Engineering GmbH, Managing Director: Erika Unter
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
