Re: [linux-yocto] [PATCH 0/4] More security fragments

2019-08-12 Thread akuster808 


On 8/12/19 8:11 AM, Bruce Ashfield wrote:
> I've merged these to the 4.19/5.0/5.2 and master branches.

thanks.

-armin
>
> SRCREV updates will follow this week, once I get some more test cycles
> completed.
>
> Bruce
>
> On Sun, Aug 11, 2019 at 12:29 PM Armin Kuster  > wrote:
>
> It is time to move the kernel fragments out of meta-security to cache.
> It should make maintenance easier.
>
> Armin Kuster (4):
>   kernel-cache: add apparmor fragments
>   kernel-cache: add smack
>   kernel-cache: add ima fragments
>   kernel-cache: add yama security fragments
>
>  features/apparmor/apparmor.cfg         |  7 +++
>  features/apparmor/apparmor.scc         |  5 +
>  features/apparmor/apparmor_on_boot.cfg |  1 +
>  features/ima/ima.cfg                   | 18 ++
>  features/ima/ima.scc                   |  4 
>  features/ima/ima_evm_root_ca.cfg       |  3 +++
>  features/ima/modsign.cfg               |  3 +++
>  features/ima/modsign.scc               |  6 ++
>  features/smack/smack.cfg               | 10 ++
>  features/smack/smack.scc               |  4 
>  features/yama/yama.cfg                 |  1 +
>  features/yama/yama.scc                 |  4 
>  12 files changed, 66 insertions(+)
>  create mode 100644 features/apparmor/apparmor.cfg
>  create mode 100644 features/apparmor/apparmor.scc
>  create mode 100644 features/apparmor/apparmor_on_boot.cfg
>  create mode 100644 features/ima/ima.cfg
>  create mode 100644 features/ima/ima.scc
>  create mode 100644 features/ima/ima_evm_root_ca.cfg
>  create mode 100644 features/ima/modsign.cfg
>  create mode 100644 features/ima/modsign.scc
>  create mode 100644 features/smack/smack.cfg
>  create mode 100644 features/smack/smack.scc
>  create mode 100644 features/yama/yama.cfg
>  create mode 100644 features/yama/yama.scc
>
> -- 
> 2.17.1
>
> -- 
> ___
> linux-yocto mailing list
> linux-yocto@yoctoproject.org 
> https://lists.yoctoproject.org/listinfo/linux-yocto
>
>
>
> -- 
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
>

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [kernel-cache][PATCH] netfilter: Enable CONFIG_NETFILTER_XT_TARGET_LOG

2019-02-17 Thread akuster808 


On 2/15/19 5:13 PM, Tom Rini wrote:
> On Fri, Feb 15, 2019 at 10:46:13AM -0500, Bruce Ashfield wrote:
>
>> merged.
>>
>> SRCREV updates will be sent out with my next queue.
> Thanks.  What's the backport policy here?  I first ran into this issue
> back on Jethro (but that's a fair bit too far to expect a backport to)
> and I finally root caused this on thud.  Can this go back to thud/sumo
I think that depends on kernel versions supported by the stable
branches. Maybe patches for each branch for this repo? They need to be
posted than accepted/merged. Then I kernel recipes can be updated with
the new hashes.

- armin
> at least on your next round of changes there?
>
>



signature.asc
Description: OpenPGP digital signature
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [kernel-meta v4.14 0/3] Fix the config check warnings

2018-09-25 Thread akuster808 


On 09/25/2018 06:59 AM, Bruce Ashfield wrote:
> On 09/25/2018 03:32 AM, Kevin Hao wrote:
>> Cherry-pick three patches from yocto-4.18 branch to fix the config
>> check warnings for beaglebone boards.
>
> merged!
>
> Bruce

Should I backport this to sumo ?

- armin
>
>>
>> Kevin Hao (3):
>>    beaglebone: Drop the obsolete kernel options
>>    beaglebone: Drop the needless unsetting of the kernel options
>>    beaglebone: Clean up the cfg file
>>
>>   bsp/beaglebone/beaglebone.cfg | 67
>> ---
>>   1 file changed, 67 deletions(-)
>>
>

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] v4.12.x - stable updates comprising v4.12.28

2018-08-13 Thread akuster808 


On 08/13/2018 08:00 AM, Paul Gortmaker wrote:
> Bruce, Yocto kernel folks:
>
> Here is another 4.12.x stable update "extension" primarily created for
> the Yocto project, continuing on top of the previous v4.12.27 kernel.
>
> Hopefully people using 4.12.x have their plans well underway to move to
> a newer kernel, as I have been indicating for several releases now that
> my maintenance work on 4.12.x is coming to a close.  
Thank you for all your time and effort in maintaining this branch.

> There will probably
> be one more release in roughly two weeks, assuming we don't encounter
> any high profile CVE issues in the interim.
You included the fix for "CVE-2018-5390 kernel: TCP segments with random
offsets allow a remote denial of service (SegmentSmack)"

thanks,
Armin
>
> There are just over 80 commits here, based on commits chosen from what
> was used in existing 4.14.x stable releases.
>
> I've put this 4.12.x queue through the usual testing that I figured made
> sense, which is in line with that listed explicitly in previous release
> announcements.
>
> I did the signed tag just as per the previously released 4.12.x versions.
>
> Please find a signed v4.12.28 tag using this key:
>
> http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6
>
> in the repo in the kernel.org directory here:
>
>https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.12.y.git/
>git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.12.y.git
>
> for merge to standard/base in linux-yocto-4.12 and then out from there
> into the other base and BSP branches.
>
> For those who are interested, the evolution of the commits is here:
>
>https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.12.git/
>
> This repo isn't needed for anything; it just exists for transparency and
> so people can see the evolution of the raw commits that were originally
> selected to create this 4.12.x release.
>
> Paul.
> --

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] v4.12.x - stable updates comprising v4.12.24

2018-05-11 Thread akuster808 


On 05/10/2018 02:30 PM, Paul Gortmaker wrote:
> Bruce, Yocto kernel folks:
>
> Here is another 4.12.x stable update "extension" primarily created for
> the Yocto project, continuing on top of the previous v4.12.23 kernel.
Thanks for keeping this kernel version updated.
Much appreciated. I know much time and effort it takes to do this.


- armin
>
> There are about 90 commits here, and for the 2nd release in a row, we
> are with no real multi-commit topics, meaning things are remaining as
> what people expect to be normal for a stable release.  Again it is
> selected content based on what was used for 4.14-stable that would also
> be appropriate for the 4.12 kernel here.
>
> As usual, I've put this 4.12.x queue through the various testing that I
> figured made sense, which includes but is not limited to:
>
> -x86-64 sanity boot test + workloads of defconfig on COTS Core2 box.
> -build MIPS, PPC, ARM, ARM64 with defconfig
> -build x86-64 allmodconfig/allyesconfig
> -build i386 allmodconfig/allyesconfig
>
> I bumped the 4.12 Makefile and did the signed tag just as per the previously
> released 4.12.x versions.
>
> Please find a signed v4.12.24 tag using this key:
>
> http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6
>
> in the repo in the kernel.org directory here:
>
>https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.12.y.git/
>git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.12.y.git
>
> for merge to standard/base in linux-yocto-4.12 and then out from there
> into the other base and BSP branches.
>
> For those who are interested, the evolution of the commits is here:
>
>https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.12.git/
>
> This repo isn't needed for anything; it just exists for transparency and
> so people can see the raw commits that were used to create this 4.12.x
> release, similar to Greg's stable queue with the 4.14.x content
> mentioned above:
>
>https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/
>
> Paul.
> --

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [Yocto kernel 4.1 pull request]

2018-03-06 Thread akuster808 


On 03/05/2018 10:51 AM, Bruce Ashfield wrote:
> On 2018-03-04 7:34 PM, Armin Kuster wrote:
>> This series includes the lsb runqemu kvm boot issue [ Yocto #12570 ],
>> Spectre v1 and misc bug fixes 4.4 backports.
>>
>> The following changes since commit
>> 1368b7448d693cedb384f6e0b9a0237adb1b8259:
>>
>>    kaiser: x86: Fix NMI handling (2018-02-22 12:18:09 -0800)
>>
>> are available in the git repository at:
>>
>>   
>> https://github.com/MontaVista-OpenSourceTechnology/linux-nonlts-secfix
>> linux-4.1.y-lts
>
> I'm getting conflicts when I try and merge this into linux-yocto-4.1
> standard/base

> yow-bashfiel-d4 [/home/bruc...to-4.1.git]> git merge   linux-4.1.y-lts

I just noticed this. "git merge" wont work.

We had our metldown changes in before the sync to 4.1.49 so the order is
off. You will need to cherry-pick.


I doubled checked via:

git checkout standard/base
git fetch 
https://github.com/MontaVista-OpenSourceTechnology/linux-nonlts-secfix
linux-4.1.y-lts
git cherry-pick 07369b8
git cherry-pick 07369b8..ee7eeb3

sorry for making things more complicated.

- armin

> Auto-merging mm/vmstat.c
> Auto-merging mm/mmap.c
> Auto-merging kernel/module.c
> Auto-merging include/linux/cred.h
> Auto-merging arch/x86/mm/kaiser.c
> CONFLICT (add/add): Merge conflict in arch/x86/mm/kaiser.c
> Auto-merging arch/x86/mm/init.c
> Auto-merging arch/x86/lib/checksum_32.S
> Auto-merging arch/x86/kvm/x86.c
> Auto-merging arch/x86/kvm/vmx.c
> Auto-merging arch/x86/kernel/entry_64.S
> CONFLICT (content): Merge conflict in arch/x86/kernel/entry_64.S
> Auto-merging arch/x86/kernel/entry_32.S
> Auto-merging arch/x86/kernel/cpu/common.c
> Removing arch/x86/kernel/cpu/bugs_64.c
> Auto-merging arch/x86/kernel/cpu/bugs.c
> Auto-merging arch/x86/include/uapi/asm/msr-index.h
> Auto-merging arch/x86/include/asm/processor.h
> Auto-merging arch/x86/include/asm/kaiser.h
> CONFLICT (add/add): Merge conflict in arch/x86/include/asm/kaiser.h
> Auto-merging arch/x86/include/asm/cpufeature.h
> Auto-merging arch/x86/Makefile
> Auto-merging Documentation/kernel-parameters.txt
> CONFLICT (content): Merge conflict in Documentation/kernel-parameters.txt
> Recorded preimage for 'Documentation/kernel-parameters.txt'
> Recorded preimage for 'arch/x86/include/asm/kaiser.h'
> Recorded preimage for 'arch/x86/kernel/entry_64.S'
> Recorded preimage for 'arch/x86/mm/kaiser.c'
> Automatic merge failed; fix conflicts and then commit the result.
> yow-bashfiel-d4 [/home/bruc...to-4.1.git]>
>
> Judging by the conflicts, it looks like the first round of Meltdown
> fixes are being merged twice .. i.e. git isn't picking them up as the
> same commits.
>
> In case I'm doing something odd (I'm merging a LOT of kernel changes
> today). Can you look at this and see if you see the same thing ?
>
> Bruce
>
>>
>> for you to fetch changes up to ee7eeb3742f1a024b30ebcf98525871cad5a328c:
>>
>>    x86/vdso: Get pvclock data from the vvar VMA instead of the fixmap
>> (2018-03-01 15:14:04 -0800)
>>
>> 
>> Adam Borowski (1):
>>    x86/kbuild: enable modversions for symbols exported from asm
>>
>> Al Viro (1):
>>    EXPORT_SYMBOL() for asm
>>
>> Alexey Dobriyan (1):
>>    proc: much faster /proc/vmstat
>>
>> Andi Kleen (3):
>>    x86/retpoline/irq32: Convert assembler indirect jumps
>>    module: Add retpoline tag to VERMAGIC
>>    x86/retpoline: Optimize inline assembler for vmexit_fill_RSB
>>
>> Andrew Honig (1):
>>    KVM: x86: Add memory barrier on vmcs field lookup
>>
>> Andrey Ryabinin (7):
>>    mm/page-writeback: fix dirty_ratelimit calculation
>>    x86/asm: Use register variable to get stack pointer value
>>    x86/kasan: Add message about KASAN being initialized
>>    x86/kasan, mm: Introduce generic kasan_populate_zero_shadow()
>>    x86/kasan: Fix boot with KASAN=y and PROFILE_ANNOTATED_BRANCHES=y
>>    x86/kasan: Clear kasan_zero_page after TLB flush
>>    x86/kasan: Write protect kasan zero shadow
>>
>> Andy Lutomirski (8):
>>    x86/cpu: Factor out application of forced CPU caps
>>    selftests/x86: Add test_vsyscall
>>    x86/mm/32: Move setup_clear_cpu_cap(X86_FEATURE_PCID) earlier
>>    x86/asm: Make asm/alternative.h safe from assembly
>>    x86/asm: Re-add parts of the manual CFI infrastructure
>>    x86/asm/32: Make sync_core() handle missing CPUID on all
>> 32-bit kernels
>>    x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader
>>    x86/vdso: Get pvclock data from the vvar VMA instead of the
>> fixmap
>>
>> Ani Sinha (1):
>>    sysrq: Fix warning in sysrq generated crash.
>>
>> Arnd Bergmann (1):
>>    gcov: disable for COMPILE_TEST
>>
>> Ben Hutchings (2):
>>    x86/microcode/intel: Fix BDW late-loading revision check
>>    vsyscall: Fix permissions for emulate mode with KAISER/PTI
>>
>> Borislav Petkov (3):
>>    Map the vsyscall page with _PAGE_USER
>>   

Re: [linux-yocto] [Yocto kernel 4.1 pull request]

2018-03-05 Thread akuster808 


On 03/05/2018 10:51 AM, Bruce Ashfield wrote:
> On 2018-03-04 7:34 PM, Armin Kuster wrote:
>> This series includes the lsb runqemu kvm boot issue [ Yocto #12570 ],
>> Spectre v1 and misc bug fixes 4.4 backports.
>>
>> The following changes since commit
>> 1368b7448d693cedb384f6e0b9a0237adb1b8259:
>>
>>    kaiser: x86: Fix NMI handling (2018-02-22 12:18:09 -0800)
>>
>> are available in the git repository at:
>>
>>   
>> https://github.com/MontaVista-OpenSourceTechnology/linux-nonlts-secfix
>> linux-4.1.y-lts
>
> I'm getting conflicts when I try and merge this into linux-yocto-4.1
> standard/base
>
> yow-bashfiel-d4 [/home/bruc...to-4.1.git]> git merge   linux-4.1.y-lts
> Auto-merging mm/vmstat.c
> Auto-merging mm/mmap.c
> Auto-merging kernel/module.c
> Auto-merging include/linux/cred.h
> Auto-merging arch/x86/mm/kaiser.c
> CONFLICT (add/add): Merge conflict in arch/x86/mm/kaiser.c
> Auto-merging arch/x86/mm/init.c
> Auto-merging arch/x86/lib/checksum_32.S
> Auto-merging arch/x86/kvm/x86.c
> Auto-merging arch/x86/kvm/vmx.c
> Auto-merging arch/x86/kernel/entry_64.S
> CONFLICT (content): Merge conflict in arch/x86/kernel/entry_64.S
> Auto-merging arch/x86/kernel/entry_32.S
> Auto-merging arch/x86/kernel/cpu/common.c
> Removing arch/x86/kernel/cpu/bugs_64.c
> Auto-merging arch/x86/kernel/cpu/bugs.c
> Auto-merging arch/x86/include/uapi/asm/msr-index.h
> Auto-merging arch/x86/include/asm/processor.h
> Auto-merging arch/x86/include/asm/kaiser.h
> CONFLICT (add/add): Merge conflict in arch/x86/include/asm/kaiser.h
> Auto-merging arch/x86/include/asm/cpufeature.h
> Auto-merging arch/x86/Makefile
> Auto-merging Documentation/kernel-parameters.txt
> CONFLICT (content): Merge conflict in Documentation/kernel-parameters.txt
> Recorded preimage for 'Documentation/kernel-parameters.txt'
> Recorded preimage for 'arch/x86/include/asm/kaiser.h'
> Recorded preimage for 'arch/x86/kernel/entry_64.S'
> Recorded preimage for 'arch/x86/mm/kaiser.c'
> Automatic merge failed; fix conflicts and then commit the result.
> yow-bashfiel-d4 [/home/bruc...to-4.1.git]>
>
> Judging by the conflicts, it looks like the first round of Meltdown
> fixes are being merged twice .. i.e. git isn't picking them up as the
> same commits.
I bet that is what is happen.  Let me double check and resend.
>
> In case I'm doing something odd (I'm merging a LOT of kernel changes
> today).
I know how that is. Good luck.

> Can you look at this and see if you see the same thing ?

Sure thing. Sorry for the bad pull request.

- armin
>
> Bruce
>
>>
>> for you to fetch changes up to ee7eeb3742f1a024b30ebcf98525871cad5a328c:
>>
>>    x86/vdso: Get pvclock data from the vvar VMA instead of the fixmap
>> (2018-03-01 15:14:04 -0800)
>>
>> 
>> Adam Borowski (1):
>>    x86/kbuild: enable modversions for symbols exported from asm
>>
>> Al Viro (1):
>>    EXPORT_SYMBOL() for asm
>>
>> Alexey Dobriyan (1):
>>    proc: much faster /proc/vmstat
>>
>> Andi Kleen (3):
>>    x86/retpoline/irq32: Convert assembler indirect jumps
>>    module: Add retpoline tag to VERMAGIC
>>    x86/retpoline: Optimize inline assembler for vmexit_fill_RSB
>>
>> Andrew Honig (1):
>>    KVM: x86: Add memory barrier on vmcs field lookup
>>
>> Andrey Ryabinin (7):
>>    mm/page-writeback: fix dirty_ratelimit calculation
>>    x86/asm: Use register variable to get stack pointer value
>>    x86/kasan: Add message about KASAN being initialized
>>    x86/kasan, mm: Introduce generic kasan_populate_zero_shadow()
>>    x86/kasan: Fix boot with KASAN=y and PROFILE_ANNOTATED_BRANCHES=y
>>    x86/kasan: Clear kasan_zero_page after TLB flush
>>    x86/kasan: Write protect kasan zero shadow
>>
>> Andy Lutomirski (8):
>>    x86/cpu: Factor out application of forced CPU caps
>>    selftests/x86: Add test_vsyscall
>>    x86/mm/32: Move setup_clear_cpu_cap(X86_FEATURE_PCID) earlier
>>    x86/asm: Make asm/alternative.h safe from assembly
>>    x86/asm: Re-add parts of the manual CFI infrastructure
>>    x86/asm/32: Make sync_core() handle missing CPUID on all
>> 32-bit kernels
>>    x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader
>>    x86/vdso: Get pvclock data from the vvar VMA instead of the
>> fixmap
>>
>> Ani Sinha (1):
>>    sysrq: Fix warning in sysrq generated crash.
>>
>> Arnd Bergmann (1):
>>    gcov: disable for COMPILE_TEST
>>
>> Ben Hutchings (2):
>>    x86/microcode/intel: Fix BDW late-loading revision check
>>    vsyscall: Fix permissions for emulate mode with KAISER/PTI
>>
>> Borislav Petkov (3):
>>    Map the vsyscall page with _PAGE_USER
>>    x86/cpu: Merge bugs.c and bugs_64.c
>>    x86/alternatives: Fix optimize_nops() checking
>>
>> Dave Hansen (3):
>>    x86/Documentation: Add PTI description
>>    x86/cpu/intel: Introduce macros for Intel family numbers
>>    x86/pti: Make unpoison

Re: [linux-yocto] Kernel 4.14 support in Yocto

2018-01-31 Thread akuster808 


On 01/31/2018 08:37 AM, Dragomir Daniel wrote:
> Hi Bruce!
>
>
> There is any plans to support 4.14 Kernel in Yocto (in rocko or future
> releases)?

We would not update the kernel in a stable release like Rocko.  We try
to maintain them to the best of our abilities.


+1 on the future release question.

- armin
>
>
> Best regards,
>
> Daniel
>

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] Custom wic imager plugin

2017-11-06 Thread akuster808 


On 11/05/2017 08:42 PM, Paul Knopf wrote:
> This was applied on to the pyro branch.

Is this a request to back port to pyro?

- armin
>
> From a0257c78cf918b84c7a5eb2730f8f783c175042d Mon Sep 17 00:00:00 2001
> From: Paul Knopf >
> Date: Mon, 30 Oct 2017 01:32:15 -0400
> Subject: [PATCH] Added support for customizing the imager plugin to use in
>  wic. It was hard coded to use the 'direct' plugin.
>
> ---
>  scripts/lib/wic/engine.py | 2 +-
>  scripts/wic               | 1 +
>  2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/scripts/lib/wic/engine.py b/scripts/lib/wic/engine.py
> index f59821fea6..9f95cb64e5 100644
> --- a/scripts/lib/wic/engine.py
> +++ b/scripts/lib/wic/engine.py
> @@ -184,7 +184,7 @@ def wic_create(wks_file, rootfs_dir, bootimg_dir,
> kernel_dir,
>      if not os.path.exists(options.outdir):
>          os.makedirs(options.outdir)
>  
> -    pname = 'direct'
> +    pname = options.imager
>      plugin_class = PluginMgr.get_plugins('imager').get(pname)
>      if not plugin_class:
>          raise WicError('Unknown plugin: %s' % pname)
> diff --git a/scripts/wic b/scripts/wic
> index a5f2dbfc6f..15e23211e5 100755
> --- a/scripts/wic
> +++ b/scripts/wic
> @@ -138,6 +138,7 @@ def wic_create_subcommand(args, usage_str):
>                             "bitbake variables")
>      parser.add_option("-D", "--debug", dest="debug", action="store_true",
>                        default=False, help="output debug information")
> +    parser.add_option("-i", "--imager", dest="imager",
> default="direct", help="The wic imager plugin")
>  
>      (options, args) = parser.parse_args(args)
>  
> -- 
> 2.14.2
>
>
> On Tue, Oct 31, 2017 at 8:32 AM, Ed Bartosh
> > wrote:
>
> On Sun, Oct 29, 2017 at 10:03:46PM -0400, Paul Knopf wrote:
> > I am able to create and use custom source plugins for wic, all good.
> >
> > However, I can't figure out how to use a custom imager plugin.
> The code has
> > support for it, but it is hard-coded to use "direct" as the
> plugin. There
> > is no way to configure it.
> >
> >
> 
> https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/scripts/lib/wic/engine.py?h=pyro#n187
> 
> 
> >
> >     pname = 'direct'
> >     plugin_class = PluginMgr.get_plugins('imager').get(pname)
> >     if not plugin_class:
> >         raise WicError('Unknown plugin: %s' % pname)
> >
> > Is this an oversight? Would you guys accept a patch?
>
> Looks like it is. Sure, please send a patch. I'll be happy to
> review it.
>
> --
> Regards,
> Ed
>
>
>
>

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [linux-yocto-4.8][PATCH] mm/workingset.c: fix implicit declaration of __list_lru_init_key

2017-09-22 Thread akuster808 
Cal,


On 09/22/2017 03:48 PM, California Sullivan wrote:
> __list_lru_init_key does not exist. We're looking for __list_lru_init as
> shown in the patch "26690f5 mm: workingset: fix premature shadow node
> shrinking with cgroups".
>
> Signed-off-by: California Sullivan 

I believe this fix is already in latest 4.8 preempt-base.

http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-4.8/commit/mm/workingset.c?h=standard/preempt-rt/base=26690f5a8bdf03966c5db20181089f86f8ca8eef

I am working on updating morty to the latest versions.

- armin

> ---
>
> This is for the standard/preempt-rt/base branch. Standard/base is OK.
>
>  mm/workingset.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/workingset.c b/mm/workingset.c
> index 1856fdb..5e953eb 100644
> --- a/mm/workingset.c
> +++ b/mm/workingset.c
> @@ -493,7 +493,7 @@ static int __init workingset_init(void)
>   pr_info("workingset: timestamp_bits=%d max_order=%d bucket_order=%u\n",
>  timestamp_bits, max_order, bucket_order);
>  
> - ret = __list_lru_init_key(&__workingset_shadow_nodes, true, 
> _nodes_key);
> + ret = __list_lru_init(&__workingset_shadow_nodes, true, 
> _nodes_key);
>   if (ret)
>   goto err;
>   ret = register_shrinker(_shadow_shrinker);


-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] v4.8.x - stable updates comprising v4.8.25

2017-07-24 Thread akuster808 

Paul,


On 07/24/2017 01:05 AM, Paul Gortmaker wrote:

Bruce, Yocto kernel folks:

Here is another 4.8.x stable update.  Continuing on top of the
previously released v4.8.24 kernel, we now have the appropriate content
from 4.9.22 to 4.9.24 (inclusive) applied on top of our latest 4.8
baseline.  Once again, I've combined several 4.9.x which results in
just under 200 backported commits out of that original 4.9.x range.

Of note, it includes the stack/heap CVE fixes backported from the
4.9.x stable release which were outside of the above range, but they
seemed worthy of jumping ahead in the 4.9.x queue that remains.

As usual, I've put this 4.8.x queue through the various testing that I
figured made sense, which includes but is not limited to:
I appreciate the time and effort in maintaining the 4.8 kernel. I do 
realize how much effort it takes to do this,


thanks,
Armin


-x86-64 sanity boot test + workloads of defconfig on COTS Core2 box.
-build MIPS, PPC, ARM, ARM64 with yocto .config and toolchains
-build x86-64 allmodconfig/allyesconfig
-build i386 allmodconfig/allyesconfig

I bumped the Makefile and did the signed tag just as per the previously
released 4.8.x versions.

Please find a signed v4.8.24 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in my kernel.org directory here:

https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.8.y.git/
git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.8.y.git

for merge to standard/base in linux-yocto-4.8 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.8.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see how the commits were adjusted to apply to the 4.8.x
kernel baseline in case people are interested.

Paul.
--


--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [PATCH] arm64: psci: move psci firmware calls out of line

2015-05-18 Thread akuster808 



On 05/18/2015 08:19 PM, Bruce Ashfield wrote:

Dropping the non-yocto interested parties from my reply, looks
like you git-send-email was picking up cc: folks.


Yeah, not intended. thought -a did that which I did not use.



Obviously this is for ARM and gcc5 ... but my question is, with
this, what do we have ? ARM building with gcc5 ?


Arm64 builds poky core-image-minimal. qemuarm64 boots



And to confirm, this is for 3.19 ? or 3.14 ?


3.19. Have not gotten around to 3.14.

- Armin


Bruce

On 2015-05-16 12:07 PM, Armin Kuster wrote:

From: Will Deacon will.dea...@arm.com

An arm64 allmodconfig fails to build with GCC 5 due to __asmeq
assertions in the PSCI firmware calling code firing due to mcount
preambles breaking our assumptions about register allocation of function
arguments:

   /tmp/ccDqJsJ6.s: Assembler messages:
   /tmp/ccDqJsJ6.s:60: Error: .err encountered
   /tmp/ccDqJsJ6.s:61: Error: .err encountered
   /tmp/ccDqJsJ6.s:62: Error: .err encountered
   /tmp/ccDqJsJ6.s:99: Error: .err encountered
   /tmp/ccDqJsJ6.s:100: Error: .err encountered
   /tmp/ccDqJsJ6.s:101: Error: .err encountered

This patch fixes the issue by moving the PSCI calls out-of-line into
their own assembly files, which are safe from the compiler's meddling
fingers.

Reported-by: Andy Whitcroft a...@canonical.com
Signed-off-by: Will Deacon will.dea...@arm.com
Signed-off-by: Catalin Marinas catalin.mari...@arm.com
Signed-off-by: Armin Kuter akus...@mvista.com
---
  arch/arm64/kernel/Makefile|  6 --
  arch/arm64/kernel/psci-call.S | 28 
  arch/arm64/kernel/psci.c  | 37
+++--
  3 files changed, 35 insertions(+), 36 deletions(-)
  create mode 100644 arch/arm64/kernel/psci-call.S

diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index eaa77ed..c8e9adc 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -15,8 +15,10 @@ CFLAGS_REMOVE_return_address.o = -pg
  arm64-obj-y:= cputable.o debug-monitors.o entry.o irq.o
fpsimd.o\
 entry-fpsimd.o process.o ptrace.o setup.o signal.o\
 sys.o stacktrace.o time.o traps.o io.o vdso.o\
-   hyp-stub.o psci.o cpu_ops.o insn.o return_address.o\
-   cpuinfo.o cpu_errata.o alternative.o
+   hyp-stub.o psci.o psci-call.o cpu_ops.o insn.o   \
+   return_address.o cpuinfo.o
cpu_errata.o  \
+   alternative.o
+

  arm64-obj-$(CONFIG_COMPAT)+= sys32.o kuser32.o signal32.o \
 sys_compat.o \
diff --git a/arch/arm64/kernel/psci-call.S
b/arch/arm64/kernel/psci-call.S
new file mode 100644
index 000..cf83e61
--- /dev/null
+++ b/arch/arm64/kernel/psci-call.S
@@ -0,0 +1,28 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Copyright (C) 2015 ARM Limited
+ *
+ * Author: Will Deacon will.dea...@arm.com
+ */
+
+#include linux/linkage.h
+
+/* int __invoke_psci_fn_hvc(u64 function_id, u64 arg0, u64 arg1, u64
arg2) */
+ENTRY(__invoke_psci_fn_hvc)
+hvc#0
+ret
+ENDPROC(__invoke_psci_fn_hvc)
+
+/* int __invoke_psci_fn_smc(u64 function_id, u64 arg0, u64 arg1, u64
arg2) */
+ENTRY(__invoke_psci_fn_smc)
+smc#0
+ret
+ENDPROC(__invoke_psci_fn_smc)
diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c
index f1dbca7..38c12f4 100644
--- a/arch/arm64/kernel/psci.c
+++ b/arch/arm64/kernel/psci.c
@@ -57,6 +57,9 @@ static struct psci_operations psci_ops;
  static int (*invoke_psci_fn)(u64, u64, u64, u64);
  typedef int (*psci_initcall_t)(const struct device_node *);

+asmlinkage int __invoke_psci_fn_hvc(u64, u64, u64, u64);
+asmlinkage int __invoke_psci_fn_smc(u64, u64, u64, u64);
+
  enum psci_function {
  PSCI_FN_CPU_SUSPEND,
  PSCI_FN_CPU_ON,
@@ -109,40 +112,6 @@ static void psci_power_state_unpack(u32 power_state,
  PSCI_0_2_POWER_STATE_AFFL_SHIFT;
  }

-/*
- * The following two functions are invoked via the invoke_psci_fn
pointer
- * and will not be inlined, allowing us to piggyback on the AAPCS.
- */
-static noinline int __invoke_psci_fn_hvc(u64 function_id, u64 arg0,
u64 arg1,
- u64 arg2)
-{
-asm volatile(
-__asmeq(%0, x0)
-__asmeq(%1, x1)
-__asmeq(%2, x2)
-__asmeq(%3, x3)
-hvc#0\n
-: +r (function_id)
-: r (arg0), r (arg1), r (arg2));
-
-return function_id;
-}
-
-static noinline int __invoke_psci_fn_smc(u64 function_id, u64 arg0,
u64 arg1,
-

Re: [linux-yocto] [PATCH v3] Meta: add qemuppc64 bsp config

2014-09-01 Thread akuster808 

Paul,

I appreciate time you took to respond and the feedback is enlightening 
to this process. I had a feeling I would have to go down this path 
(being lazy on my part).


I will be submitting V4 soon which I hope will meet the requirements.

kind regards,
Armin

On 08/31/2014 08:18 AM, Paul Gortmaker wrote:

[[linux-yocto] [PATCH v3] Meta: add qemuppc64 bsp config] On 30/08/2014 (Sat 
23:03) Armin Kuster wrote:


This is the initial meta data for qemu ppc64 bsp that supports
the IBM pseries power* arch which is supported in Qemu.

V2: Pruned config
   : Added standard.scc

V3: More cleanup
   : Added cfg/virtio.scc
   : Added features/input/input.scc
   : Added cfg/8250.scc

Signed-off-by: Armin Kuster akuster...@gmail.com
---
  .../bsp/qemu-ppc64/qemu-ppc64-standard.scc |  16 +
  .../cfg/kernel-cache/bsp/qemu-ppc64/qemu-ppc64.cfg | 641 +
  .../cfg/kernel-cache/bsp/qemu-ppc64/qemu-ppc64.scc |   2 +
  3 files changed, 659 insertions(+)
  create mode 100644 
meta/cfg/kernel-cache/bsp/qemu-ppc64/qemu-ppc64-standard.scc
  create mode 100644 meta/cfg/kernel-cache/bsp/qemu-ppc64/qemu-ppc64.cfg
  create mode 100644 meta/cfg/kernel-cache/bsp/qemu-ppc64/qemu-ppc64.scc

diff --git a/meta/cfg/kernel-cache/bsp/qemu-ppc64/qemu-ppc64-standard.scc 
b/meta/cfg/kernel-cache/bsp/qemu-ppc64/qemu-ppc64-standard.scc
new file mode 100644
index 000..f01e410
--- /dev/null
+++ b/meta/cfg/kernel-cache/bsp/qemu-ppc64/qemu-ppc64-standard.scc
@@ -0,0 +1,16 @@
+define KMACHINE qemuppc64
+define KTYPE standard
+define KARCH powerpc
+include ktypes/standard/standard.scc
+
+branch qemuppc
+
+include cfg/virtio.scc
+include features/input/input.scc
+inclide cfg/8250.scc
+
+include qemu-ppc64.scc
+
+# default policy for standard kernels
+include features/latencytop/latencytop.scc
+
diff --git a/meta/cfg/kernel-cache/bsp/qemu-ppc64/qemu-ppc64.cfg 
b/meta/cfg/kernel-cache/bsp/qemu-ppc64/qemu-ppc64.cfg
new file mode 100644
index 000..48a94f8
--- /dev/null
+++ b/meta/cfg/kernel-cache/bsp/qemu-ppc64/qemu-ppc64.cfg
@@ -0,0 +1,641 @@


It seems you've done a few passes to cut this down from a full
defconfig; perhaps I can give a few comments that will help take it a
bit further.  At 640 lines, it is better than a full defconfig, but
ideally it could be less than 100 lines and still be giving you a better
solution to what I think you want as a final solution.

General comments - things that are autodetected and/or look like the
defaults need not be specified.  It is better to take the defaults and
have your BSP keep with the times vs. being frozen in time, when it
comes to the secondary options that aren't critical to core boot up.
Meaning specify CPU selection, IRQ chip type and core hardware etc. but
leave the trivialities to track defaults.  A good example of this was the
old /dev/hda vs /dev/sda transition ; those who specified the legacy
PATA options got frozen in time on the abandoned kernel code.

Other examples:  Anything that starts with CONFIG_ARCH_HAS or
CONFIG_ARCH_SUPPORTS are internally set options that are based off your
core CPU and ARCH choices.  Specifying them is redundant.

Next - make your default policy to not don't bother specifying options
that aren't hardware specific.  Then you can go back in and add the few
items that actually do matter -- e.g. say your hardware booted from MTD
and so you'd found you really needed to ensure CONFIG_JFFS2_FS was set
for your flash filesystem, etc.

Why not specify the defaults?  In addition to not getting frozen in
time, imagine thinking beyond this one BSP.  Think of families of BSPs.
You could say the qemu BSPs across all arch represent one kind of
family.  Or intel BSPs with slightly different motherboard peripherals,
but all sharing the same core as another family.  Or an embedded company
who has a product line with a specific feature set support as another.

If you only specify the core hardware in your BSP, then it is highly
adaptible.  You plug your hardware fragment underneath the features
specified by the generic (non-hardware) fragment(s) for a family XYZ
BSP, and presto you now have your own XYZ variant for your hardware.
But if CONFIG_KEXEC=y breaks XYZ, and you've called out CONFIG_KEXEC
in your BSP specific fragment (for no real reason), well you won't
have a working XYZ BSP anymore; it won't adapt to the family settings.

I'll put some additional comments inline.


+CONFIG_PPC64=y
+# Processor support


comment not at top of this block ?


+CONFIG_PPC_BOOK3S_64=y
+CONFIG_GENERIC_CPU=y
+CONFIG_PPC_BOOK3S=y
+CONFIG_POWER3=y
+CONFIG_POWER4=y


Need both for qemu?  Which one specifically are you emulating?


+CONFIG_PPC_FPU=y
+CONFIG_ALTIVEC=y
+CONFIG_VSX=y
+CONFIG_PPC_STD_MMU=y
+CONFIG_PPC_STD_MMU_64=y


Both above should be defaults since you've already said PPC64


+CONFIG_PPC_MM_SLICES=y
+CONFIG_PPC_HAVE_PMU_SUPPORT=y


See CONFIG_..._HAS and CONFIG_..._SUPPORTS mentioned above.


+CONFIG_PPC_PERF_CTRS=y
+CONFIG_SMP=y

Re: [linux-yocto] [PATCH v2] Meta: add qemuppc64 bsp config

2014-08-31 Thread akuster808 



On 08/28/2014 08:41 AM, Bruce Ashfield wrote:

On 14-08-28 10:13 AM, Armin Kuster wrote:

This is the initial meta data for qemu ppc64 bsp that supports
the IBM pseries power* arch with is supported in Qemu.

V2: Pruned config
   : Added standard.scc


Looks much improved! See a few more comments below.


Thanks.

Took your suggestions and will be submitting V3 soon.

regards,
Armin




Signed-off-by: Armin Kuster akuster...@gmail.com
---
  .../bsp/qemu-ppc64/qemu-ppc64-standard.scc |  12 +
  .../cfg/kernel-cache/bsp/qemu-ppc64/qemu-ppc64.cfg | 776
+
  .../cfg/kernel-cache/bsp/qemu-ppc64/qemu-ppc64.scc |   2 +
  3 files changed, 790 insertions(+)
  create mode 100644
meta/cfg/kernel-cache/bsp/qemu-ppc64/qemu-ppc64-standard.scc
  create mode 100644 meta/cfg/kernel-cache/bsp/qemu-ppc64/qemu-ppc64.cfg
  create mode 100644 meta/cfg/kernel-cache/bsp/qemu-ppc64/qemu-ppc64.scc

diff --git
a/meta/cfg/kernel-cache/bsp/qemu-ppc64/qemu-ppc64-standard.scc
b/meta/cfg/kernel-cache/bsp/qemu-ppc64/qemu-ppc64-standard.scc
new file mode 100644
index 000..fe092ff
--- /dev/null
+++ b/meta/cfg/kernel-cache/bsp/qemu-ppc64/qemu-ppc64-standard.scc
@@ -0,0 +1,12 @@
+define KMACHINE qemuppc64
+define KTYPE standard
+define KARCH powerpc
+include ktypes/standard/standard.scc
+
+branch qemuppc
+
+include qemu-ppc64.scc
+
+# default policy for standard kernels
+include features/latencytop/latencytop.scc
+
diff --git a/meta/cfg/kernel-cache/bsp/qemu-ppc64/qemu-ppc64.cfg
b/meta/cfg/kernel-cache/bsp/qemu-ppc64/qemu-ppc64.cfg
new file mode 100644
index 000..b5b220c
--- /dev/null
+++ b/meta/cfg/kernel-cache/bsp/qemu-ppc64/qemu-ppc64.cfg
@@ -0,0 +1,776 @@
+CONFIG_PPC64=y
+# Processor support
+CONFIG_PPC_BOOK3S_64=y
+CONFIG_GENERIC_CPU=y
+CONFIG_PPC_BOOK3S=y
+CONFIG_POWER3=y
+CONFIG_POWER4=y
+CONFIG_PPC_FPU=y
+CONFIG_ALTIVEC=y
+CONFIG_VSX=y
+CONFIG_PPC_STD_MMU=y
+CONFIG_PPC_STD_MMU_64=y
+CONFIG_PPC_MM_SLICES=y
+CONFIG_PPC_HAVE_PMU_SUPPORT=y
+CONFIG_PPC_PERF_CTRS=y
+CONFIG_SMP=y
+CONFIG_NR_CPUS=2048
+CONFIG_PPC_DOORBELL=y
+CONFIG_CPU_BIG_ENDIAN=y
+CONFIG_64BIT=y
+CONFIG_WORD_SIZE=64
+CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
+CONFIG_ARCH_DMA_ADDR_T_64BIT=y
+CONFIG_MMU=y
+CONFIG_HAVE_SETUP_PER_CPU_AREA=y
+CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
+CONFIG_NR_IRQS=512
+CONFIG_STACKTRACE_SUPPORT=y
+CONFIG_HAVE_LATENCYTOP_SUPPORT=y
+CONFIG_TRACE_IRQFLAGS_SUPPORT=y
+CONFIG_LOCKDEP_SUPPORT=y
+CONFIG_RWSEM_XCHGADD_ALGORITHM=y
+CONFIG_ARCH_HAS_ILOG2_U32=y
+CONFIG_ARCH_HAS_ILOG2_U64=y
+CONFIG_GENERIC_HWEIGHT=y
+CONFIG_PPC=y
+CONFIG_PANIC_TIMEOUT=180
+CONFIG_COMPAT=y
+CONFIG_SYSVIPC_COMPAT=y
+CONFIG_SCHED_OMIT_FRAME_POINTER=y
+CONFIG_ARCH_MAY_HAVE_PC_FDC=y
+CONFIG_PPC_OF=y
+CONFIG_PPC_UDBG_16550=y
+CONFIG_AUDIT_ARCH=y
+CONFIG_GENERIC_BUG=y
+CONFIG_EPAPR_BOOT=y
+CONFIG_ARCH_HIBERNATION_POSSIBLE=y
+CONFIG_ARCH_SUSPEND_POSSIBLE=y
+CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
+CONFIG_ARCH_SUPPORTS_UPROBES=y
+CONFIG_PPC_EMULATE_SSTEP=y
+CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config
+CONFIG_IRQ_WORK=y
+
+
+# Platform support
+#
+CONFIG_PPC_POWERNV=y
+CONFIG_PPC_POWERNV_RTAS=y
+CONFIG_PPC_PSERIES=y
+CONFIG_PPC_SPLPAR=y
+CONFIG_PSERIES_MSI=y
+CONFIG_PSERIES_ENERGY=y
+CONFIG_SCANLOG=m
+CONFIG_IO_EVENT_IRQ=y
+CONFIG_LPARCFG=y
+CONFIG_PPC_SMLPAR=y
+CONFIG_CMM=y
+CONFIG_DTL=y
+CONFIG_PPC_NATIVE=y
+CONFIG_PPC_OF_BOOT_TRAMPOLINE=y
+CONFIG_PPC_SMP_MUXED_IPI=y
+CONFIG_MPIC=y
+CONFIG_PPC_I8259=y
+CONFIG_PPC_RTAS=y
+CONFIG_RTAS_ERROR_LOGGING=y
+CONFIG_PPC_RTAS_DAEMON=y
+CONFIG_RTAS_PROC=y
+CONFIG_RTAS_FLASH=m
+CONFIG_IBMVIO=y
+CONFIG_IBMEBUS=y
+CONFIG_EEH=y
+CONFIG_PPC_P7_NAP=y
+CONFIG_PPC_INDIRECT_PIO=y
+
+#
+# POWERPC CPU Idle Drivers
+#
+CONFIG_PSERIES_CPUIDLE=y
+CONFIG_POWERNV_CPUIDLE=y
+
+CONFIG_BINFMT_MISC=m
+CONFIG_COREDUMP=y
+CONFIG_HUGETLB_PAGE_SIZE_VARIABLE=y
+CONFIG_PPC_TRANSACTIONAL_MEM=y
+CONFIG_IOMMU_HELPER=y
+CONFIG_HOTPLUG_CPU=y
+CONFIG_ARCH_CPU_PROBE_RELEASE=y
+CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
+CONFIG_ARCH_HAS_WALK_MEMORY=y
+CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE=y
+CONFIG_PPC64_SUPPORTS_MEMORY_FAILURE=y
+CONFIG_KEXEC=y
+CONFIG_IRQ_ALL_CPUS=y
+CONFIG_NUMA=y
+CONFIG_NODES_SHIFT=8
+CONFIG_ARCH_SELECT_MEMORY_MODEL=y
+CONFIG_ARCH_SPARSEMEM_ENABLE=y
+CONFIG_ARCH_SPARSEMEM_DEFAULT=y
+CONFIG_SYS_SUPPORTS_HUGETLBFS=y
+CONFIG_SELECT_MEMORY_MODEL=y
+CONFIG_SPARSEMEM_MANUAL=y
+CONFIG_SPARSEMEM=y
+CONFIG_NEED_MULTIPLE_NODES=y
+CONFIG_HAVE_MEMORY_PRESENT=y
+CONFIG_SPARSEMEM_EXTREME=y
+CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
+CONFIG_SPARSEMEM_VMEMMAP=y
+CONFIG_HAVE_MEMBLOCK=y
+CONFIG_HAVE_MEMBLOCK_NODE_MAP=y
+CONFIG_MEMORY_ISOLATION=y
+CONFIG_HAVE_BOOTMEM_INFO_NODE=y
+CONFIG_MEMORY_HOTPLUG=y
+CONFIG_MEMORY_HOTPLUG_SPARSE=y
+CONFIG_MEMORY_HOTREMOVE=y
+CONFIG_PAGEFLAGS_EXTENDED=y
+CONFIG_SPLIT_PTLOCK_CPUS=4
+CONFIG_BALLOON_COMPACTION=y
+CONFIG_COMPACTION=y
+CONFIG_MIGRATION=y
+CONFIG_PHYS_ADDR_T_64BIT=y
+CONFIG_ZONE_DMA_FLAG=1
+CONFIG_BOUNCE=y
+CONFIG_MMU_NOTIFIER=y
+CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
+CONFIG_ARCH_SUPPORTS_MEMORY_FAILURE=y

[linux-yocto] yocto-kernel-tools

2014-08-29 Thread akuster808 

Hello,

I am trying to use the yocto-kernel-tools and when I run make install 
it errors out.


install: cannot stat ‘tools/generate_cfg’: No such file or directory

there is no 'generate_cfg' file in the sources.  What am I missing?

regards,
Armin

--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [PATCH] Meta: add qemuppc64 bsp config

2014-08-28 Thread akuster808 



On 08/28/2014 07:40 AM, Bruce Ashfield wrote:

On 14-08-28 10:29 AM, akuster808 wrote:



On 08/26/2014 09:39 PM, Bruce Ashfield wrote:

On 2014-08-26, 8:25 PM, akuster808 wrote:



On 08/26/2014 10:04 AM, Bruce Ashfield wrote:

On 14-08-26 11:05 AM, Armin Kuster wrote:

This is the initial meta data for qemu ppc64 bsp that supports
the IBM pseries power* arch with is supported in Qemu.


Thanks for the patch .. see below for some comments.



Yes, its not pretty but it works.


Do you have a bootlog capture ?


I can on getting one. is this normally need ( process question).


There's no firm process, but it is something that I've asked for over
the years, since it gives us a good reference to what was working when
the BSP was first introduced.



I am attaching the dmesg. I could not get QEMU to behave to give me a
serial console. could be an open firmware thing.

I have posted a 'V2' of meta changes.


Nice. I'll have a look shortly. One other question .. any other
tweaks that I need to get the right qemu support added ? I'll do
a build and boot test if I have the right instructions.



What is missing is the machine config and update linux-yocto.bb file and 
I have runqemu script changes.

I can send all those along too.  The tune files are in OE already.

The order of submission I am taking is tune files, yocto-linux, 
linux.bb, machine config then scripts. This seems to be the order of 
dependence for me. First time doing this, maybe there is a more 
appropriate order???


I can send you everything I have.

regards,
Armin






Cheers,

Bruce






  And a list of supported features ?
is the a doc on what is meant by features?


It's mainly features from the point of view of the h/w. i.e. what
ethernet is used (emulated or not), clock sources, etc. The yocto
reference BSPs capture some of this in the README files. Again, no
hard and fast rules .. but the more we know, the more I can not
break the board with merges, and when someone wanders by later, they'll
know what to expect.


Enternet
SCSI
USB
VGA (but X currently crashes)









Signed-off-by: Armin Kuster akuster...@gmail.com
---
  .../bsp/qemu-ppc64/qemu-ppc64-standard.scc |8 +
  .../cfg/kernel-cache/bsp/qemu-ppc64/qemu-ppc64.cfg | 2778

  .../cfg/kernel-cache/bsp/qemu-ppc64/qemu-ppc64.scc |1 +
  3 files changed, 2787 insertions(+)
  create mode 100644
meta/cfg/kernel-cache/bsp/qemu-ppc64/qemu-ppc64-standard.scc
  create mode 100644
meta/cfg/kernel-cache/bsp/qemu-ppc64/qemu-ppc64.cfg
  create mode 100644
meta/cfg/kernel-cache/bsp/qemu-ppc64/qemu-ppc64.scc

diff --git
a/meta/cfg/kernel-cache/bsp/qemu-ppc64/qemu-ppc64-standard.scc
b/meta/cfg/kernel-cache/bsp/qemu-ppc64/qemu-ppc64-standard.scc
new file mode 100644
index 000..bf48141
--- /dev/null
+++ b/meta/cfg/kernel-cache/bsp/qemu-ppc64/qemu-ppc64-standard.scc
@@ -0,0 +1,8 @@
+define KMACHINE qemuppc64
+define KTYPE standard
+define KARCH powerpc
+
+include ktypes/standard/standard.scc
+branch qemuppc
+
+include qemu-ppc64.scc
diff --git a/meta/cfg/kernel-cache/bsp/qemu-ppc64/qemu-ppc64.cfg
b/meta/cfg/kernel-cache/bsp/qemu-ppc64/qemu-ppc64.cfg
new file mode 100644
index 000..68c3264
--- /dev/null
+++ b/meta/cfg/kernel-cache/bsp/qemu-ppc64/qemu-ppc64.cfg
@@ -0,0 +1,2778 @@
+CONFIG_PPC64=y
+
+#
+# Processor support


This looks like a deconfig capture, which is fine as a starting point.


correct. easiest thing to do for now.


But it means that the consistency/policy of the base fragments is not
being used.

this is the goal I hope to achieve as I learn this process.



Are we saying that we don't know which ones are platform options ? A
visual pass can prune things down quickly .. see below:


I will take out my chainsaw and do a bit of trimming and clean up.


Excellent :)






+#
+CONFIG_PPC_BOOK3S_64=y
+# CONFIG_PPC_BOOK3E_64 is not set
+CONFIG_GENERIC_CPU=y
+# CONFIG_CELL_CPU is not set
+# CONFIG_POWER4_CPU is not set
+# CONFIG_POWER5_CPU is not set
+# CONFIG_POWER6_CPU is not set
+# CONFIG_POWER7_CPU is not set
+CONFIG_PPC_BOOK3S=y
+CONFIG_POWER3=y
+CONFIG_POWER4=y
+# CONFIG_TUNE_CELL is not set
+CONFIG_PPC_FPU=y
+CONFIG_ALTIVEC=y
+CONFIG_VSX=y
+# CONFIG_PPC_ICSWX is not set
+CONFIG_PPC_STD_MMU=y
+CONFIG_PPC_STD_MMU_64=y
+CONFIG_PPC_MM_SLICES=y
+CONFIG_PPC_HAVE_PMU_SUPPORT=y
+CONFIG_PPC_PERF_CTRS=y
+CONFIG_SMP=y
+CONFIG_NR_CPUS=2048
+CONFIG_PPC_DOORBELL=y
+CONFIG_CPU_BIG_ENDIAN=y
+# CONFIG_CPU_LITTLE_ENDIAN is not set
+CONFIG_64BIT=y
+CONFIG_WORD_SIZE=64
+CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
+CONFIG_ARCH_DMA_ADDR_T_64BIT=y
+CONFIG_MMU=y
+CONFIG_HAVE_SETUP_PER_CPU_AREA=y
+CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
+CONFIG_NR_IRQS=512
+CONFIG_STACKTRACE_SUPPORT=y
+CONFIG_HAVE_LATENCYTOP_SUPPORT=y
+CONFIG_TRACE_IRQFLAGS_SUPPORT=y
+CONFIG_LOCKDEP_SUPPORT=y
+CONFIG_RWSEM_XCHGADD_ALGORITHM=y
+CONFIG_ARCH_HAS_ILOG2_U32=y
+CONFIG_ARCH_HAS_ILOG2_U64=y
+CONFIG_GENERIC_HWEIGHT=y
+CONFIG_PPC=y
+# CONFIG_GENERIC_CSUM is not set
+CONFIG_EARLY_PRINTK=y


Things