On Thu, 2019-07-11 at 18:51 +0200, Jan Kiszka wrote:
[...]

4.19/arm/hitachi_omap_defconfig
4.19/arm/moxa_mxc_defconfig
4.19/arm/siemens_am335x-axm2_defconfig
4.19/arm/siemens_am335x-draco_defconfig
4.19/arm/siemens_am335x-dxr2_defconfig
4.19/arm/siemens_am335x-etamin_defconfig
4.19/arm/siemens_am57xx-pxm3_defconfig

Those can go, I'm not aware of their usage on 4.19. But do we have one for the
am335-x-based BBB, our reference board?

Good point. I have not yet tried running 4.19 on the BBB, but I can
look at adding one - or perhaps Nobuhiro or Pavel already has a
suitable config?

4.19/arm/toshiba_tegra_defconfig
4.19/arm/toshiba_zynq_defconfig
4.19/powerpc/toshiba_defconfig
4.19/x86/plathome_obsvx1.config
4.19/x86/siemens_i386-rt.config

I do not recall the history of that one anymore. We should have at least one -rt
config for x86 somewhere.

Yes, and also the build rules should check out -rt branches instead of
the main CIP branches when processing an -rt configuration.

4.19/x86/siemens_iot2000.config
4.19/x86/siemens_server_defconfig

Those two should stay.

But they need to be reviewed, as automatic config updates usually don't
cope with renaming of config symbols.

Ben.

4.19/x86/toshiba_defconfig

Ben.

Thanks,
Jan

--
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom

Hi Ben,

On Fri 2019-07-12 17:34:47, Ben Hutchings wrote:

On Thu, 2019-07-11 at 18:51 +0200, Jan Kiszka wrote:
[...]

4.19/arm/hitachi_omap_defconfig
4.19/arm/moxa_mxc_defconfig
4.19/arm/siemens_am335x-axm2_defconfig
4.19/arm/siemens_am335x-draco_defconfig
4.19/arm/siemens_am335x-dxr2_defconfig
4.19/arm/siemens_am335x-etamin_defconfig
4.19/arm/siemens_am57xx-pxm3_defconfig

Those can go, I'm not aware of their usage on 4.19. But do we have one for the
am335-x-based BBB, our reference board?

Good point. I have not yet tried running 4.19 on the BBB, but I can
look at adding one - or perhaps Nobuhiro or Pavel already has a
suitable config?

No easy access to BBB here, sorry.

I have added directory 4.19-rt and added config for socfpga I'd like
to be used for testing in Lava lab. It is not configuration that needs
to be officially supported with CIP project.

I hope that is okay.

If someone uses rt on some other hardware, I'd like to know.

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

On Sun 2019-07-21 19:58:40, Zoran S wrote:

Good point. I have not yet tried running 4.19 on the BBB, but I can
look at adding one - or perhaps Nobuhiro or Pavel already has a
suitable config?

Excellent point, which spares me time to begin the new email thread
about 4.19 BBB rt-config file.

Actually, I have one 4.19 BBB rt-config file, which at the end of trimming
goes to cycles (not able to set three parameters).

git clone git://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git
cd linux-cip
*git checkout -b cip_v4.19.13-cip1-rt1-rebase v4.19.13-cip1-rt1-rebase*
export TREE_NAME=cip-example
export ARCH=arm
export CROSS_COMPILE=arm-linux-gnueabihf-
make -j4 -k -s ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=build-arm
omap2plus_defconfig

I did adjust all the RT parameters, and at the end of three cycles of
compiling, I've got the following CONFIG file (attached to this email).

My problem is, that I ended with cyclic loop, since every time I start
compiling with:
make -j4 -k -s ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=build-arm

I end up with changed .config, with always three parameters changed:

I'm not sure I completely understand your problem. But "/" in
menuconfig is helpful:

*** 585,591 ****
#
# CONFIG_SUSPEND is not set
# CONFIG_HIBERNATION is not set
*! CONFIG_PM=y <<== (should be # CONFIG_PM is not set)*
CONFIG_PM_DEBUG=y
# CONFIG_PM_ADVANCED_DEBUG is not set
# CONFIG_APM_EMULATION is not set

│ Symbol: PM [=y]
│ Type : bool
│ Prompt: Device power management core functionality
│ Location:
│ (1) -> Power management options
│ Defined at kernel/power/Kconfig:144
│ Selected by [y]:
│ - ARCH_OMAP2PLUS_TYPICAL [=y] && (ARCH_MULTI_V6 [=y] ||
ARCH_MULTI_V7 │

-> you need to disable OMAP2PLUS_TYPICAL.

--- 2320,2325 ----
***************
*** 5469,5476 ****
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y

*! CONFIG_DEBUG_LOCK_ALLOC=y <<== (should be #
CONFIG_DEBUG_LOCK_ALLOC is

│ Symbol: DEBUG_LOCK_ALLOC [=y]
│ Type : bool
│ Prompt: Lock debugging: detect incorrect freeing of live locks
│ Location:
│ -> Kernel hacking
│ (1) -> Lock Debugging (spinlocks, mutexes, etc...)
│ Defined at lib/Kconfig.debug:1163
│ Depends on: DEBUG_KERNEL [=y] && LOCK_DEBUGGING_SUPPORT [=y]
│ Selects: DEBUG_SPINLOCK [=y] && DEBUG_MUTEXES [=y] &&
DEBUG_RT_MUTEXE │
│ Selected by [y]:
│ - DEBUG_WW_MUTEX_SLOWPATH [=y] && DEBUG_KERNEL [=y] &&
LOCK_DEBUGGING │

You need to disable DEBUG_WW_MUTEX_SLOWPATH AFAICT.


Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany