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 ...
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
