[PATCH u-boot] powerpc/mpc85xx: socrates: Re-enable building u-boot-socrates.bin

[PATCH u-boot] powerpc/mpc85xx: socrates: Re-enable building u-boot-socrates.bin

[Pali Rohár]

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 <pali@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(+)

diff --git a/arch/powerpc/cpu/mpc85xx/Kconfig b/arch/powerpc/cpu/mpc85xx/Kconfig
index 24d3f1f20c25..4c765efab7a5 100644
--- a/arch/powerpc/cpu/mpc85xx/Kconfig
+++ b/arch/powerpc/cpu/mpc85xx/Kconfig
@@ -72,6 +72,7 @@ choice
 config TARGET_SOCRATES
 	bool "Support socrates"
 	select ARCH_MPC8544
+	select BINMAN
 
 config TARGET_P3041DS
 	bool "Support P3041DS"
-- 
2.20.1

Re: [PATCH u-boot] powerpc/mpc85xx: socrates: Re-enable building u-boot-socrates.bin

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1845 bytes --]

On Wed, Dec 28, 2022 at 07:18:39PM +0100, 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 <pali@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?

So, in so far as CI can check for something like this, it does when we
enable it (akin to the build time size checks).  I think in this case,
some settings for CONFIG_BUILD_TARGET would help.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH u-boot] powerpc/mpc85xx: socrates: Re-enable building u-boot-socrates.bin

[Pali Rohár]

On Wednesday 28 December 2022 19:11:34 Tom Rini wrote:
> On Wed, Dec 28, 2022 at 07:18:39PM +0100, 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 <pali@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?
> 
> So, in so far as CI can check for something like this, it does when we
> enable it (akin to the build time size checks).  I think in this case,
> some settings for CONFIG_BUILD_TARGET would help.

Good point about CONFIG_BUILD_TARGET, but it works only for make
targets. Not for custom binman target about which make does not know.

Anyway, in additional patch I sent change which stops building of
u-boot.bin and rename u-boot-socrates.bin to u-boot.bin.

Re: [PATCH u-boot] powerpc/mpc85xx: socrates: Re-enable building u-boot-socrates.bin

[Heiko Schocher]

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 <pali@kernel.org>
> ---
> Heiko Schocher: Could you test if u-boot is still working on this board?

I will check ASAP ... last U-Boot version I have tried on this board is:

* d637294e26 - (tag: v2022.01) Prepare v2022.01

And looking into my yocto build directory, there is an u-boot-socrates.bin...

I try to find time to rebase to newest version, and look into, thanks!

bye,
Heiko

> 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(+)
> 
> diff --git a/arch/powerpc/cpu/mpc85xx/Kconfig b/arch/powerpc/cpu/mpc85xx/Kconfig
> index 24d3f1f20c25..4c765efab7a5 100644
> --- a/arch/powerpc/cpu/mpc85xx/Kconfig
> +++ b/arch/powerpc/cpu/mpc85xx/Kconfig
> @@ -72,6 +72,7 @@ choice
>  config TARGET_SOCRATES
>  	bool "Support socrates"
>  	select ARCH_MPC8544
> +	select BINMAN
>  
>  config TARGET_P3041DS
>  	bool "Support P3041DS"
> 

-- 
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: hs@denx.de

Re: [PATCH u-boot] powerpc/mpc85xx: socrates: Re-enable building u-boot-socrates.bin

[Pali Rohár]

Tom, would you take this patch to master?

On Wednesday 28 December 2022 19:18:39 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 <pali@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(+)
> 
> diff --git a/arch/powerpc/cpu/mpc85xx/Kconfig b/arch/powerpc/cpu/mpc85xx/Kconfig
> index 24d3f1f20c25..4c765efab7a5 100644
> --- a/arch/powerpc/cpu/mpc85xx/Kconfig
> +++ b/arch/powerpc/cpu/mpc85xx/Kconfig
> @@ -72,6 +72,7 @@ choice
>  config TARGET_SOCRATES
>  	bool "Support socrates"
>  	select ARCH_MPC8544
> +	select BINMAN
>  
>  config TARGET_P3041DS
>  	bool "Support P3041DS"
> -- 
> 2.20.1
> 

Re: [PATCH u-boot] powerpc/mpc85xx: socrates: Re-enable building u-boot-socrates.bin

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2471 bytes --]

On Fri, Dec 30, 2022 at 01:44:04PM +0100, Pali Rohár wrote:

> Tom, would you take this patch to master?

Yes, I'm just assuming Heiko will have a chance to test this before the
release on the 9th, thanks.

> 
> On Wednesday 28 December 2022 19:18:39 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 <pali@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(+)
> > 
> > diff --git a/arch/powerpc/cpu/mpc85xx/Kconfig b/arch/powerpc/cpu/mpc85xx/Kconfig
> > index 24d3f1f20c25..4c765efab7a5 100644
> > --- a/arch/powerpc/cpu/mpc85xx/Kconfig
> > +++ b/arch/powerpc/cpu/mpc85xx/Kconfig
> > @@ -72,6 +72,7 @@ choice
> >  config TARGET_SOCRATES
> >  	bool "Support socrates"
> >  	select ARCH_MPC8544
> > +	select BINMAN
> >  
> >  config TARGET_P3041DS
> >  	bool "Support P3041DS"
> > -- 
> > 2.20.1
> > 

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH u-boot] powerpc/mpc85xx: socrates: Re-enable building u-boot-socrates.bin

[Heiko Schocher]

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 <pali@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 <hs@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 ... 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

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

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: hs@denx.de

Re: [PATCH u-boot] powerpc/mpc85xx: socrates: Re-enable building u-boot-socrates.bin

[Pali Rohár]

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 <pali@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 <hs@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?

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

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

> 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: hs@denx.de

Re: [PATCH u-boot] powerpc/mpc85xx: socrates: Re-enable building u-boot-socrates.bin

[Heiko Schocher]

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 <pali@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 <hs@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 <sjg@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!

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: hs@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: hs@denx.de

Re: [PATCH u-boot] powerpc/mpc85xx: socrates: Re-enable building u-boot-socrates.bin

[Heiko Schocher]

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 <pali@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 <hs@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 <sjg@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 <trini@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 <pali@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.
"""

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: hs@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: hs@denx.de

Re: [PATCH u-boot] powerpc/mpc85xx: socrates: Re-enable building u-boot-socrates.bin

[Pali Rohár]

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 <pali@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 <hs@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 <sjg@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 <trini@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 <pali@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).

> 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: hs@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: hs@denx.de

Re: [PATCH u-boot] powerpc/mpc85xx: socrates: Re-enable building u-boot-socrates.bin

[Heiko Schocher]

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 <pali@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 <hs@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 <sjg@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 <trini@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 <pali@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.

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: hs@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: hs@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: hs@denx.de

Re: [PATCH u-boot] powerpc/mpc85xx: socrates: Re-enable building u-boot-socrates.bin

[Heiko Schocher]

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 <pali@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 <hs@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 <sjg@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 <trini@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 <pali@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 <trini@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 <trini@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: hs@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: hs@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: hs@denx.de

Re: [PATCH u-boot] powerpc/mpc85xx: socrates: Re-enable building u-boot-socrates.bin

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1516 bytes --]

On Wed, Dec 28, 2022 at 07:18:39PM +0100, 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 <pali@kernel.org>
> Tested-by: Heiko Schocher <hs@denx.de>

Applied to u-boot/master, thanks!

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH u-boot] powerpc/mpc85xx: socrates: Re-enable building u-boot-socrates.bin

[Pali Rohár]

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 <pali@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 <hs@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 <sjg@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 <trini@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 <pali@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 <trini@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 <trini@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: hs@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: hs@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: hs@denx.de