Re: [yocto] Source Code provision without full git repository history

[Waldvogel, Sebastian]

The point is that we want to deliver the Yocto build environment including the 
layers/recipes and the download directory (DL_DIR) to our customers as well.
The download directory shall contain an archive of the software modules / 
applications developed by my company. The customer has no access to the 
company's git repository.

We try to use as much as possible default functionality of Yocto and avoid 
developing additional delivery tools around Yocto.
A workaround would be manual extraction of the generated tarballs (including 
full git repo) and creating a new archive with git archive containing only the 
source files of the desired git revision.
In addition the SRC_URI of the related recipe need to be overwritten  by an 
.bbappend pointing to the tarball instead of the company git repo.

My favorite solution would be an additional attribute in the SRC_URI to control 
the behavior of the mirror tarball generation. E.g. SRC_URI = " 
git://git.company.url;nogithistory=1"

Best regards
Sebastian

>-Original Message-
>From: Daniel. [mailto:danielhi...@gmail.com]
>Sent: Thursday, March 09, 2017 5:28 PM
>To: Khem Raj
>Cc: Waldvogel, Sebastian; yocto@yoctoproject.org
>Subject: Re: [yocto] Source Code provision without full git repository history
>
>I'm not trying to be simplistic here, but, why not package the source
>releases to a tarball (with git archive or somthing) and provide it
>through a FTP server?
>
>Regards,
>
>2017-03-09 11:29 GMT-03:00 Khem Raj :
>>
>> On Thu, Mar 9, 2017 at 5:02 AM Waldvogel, Sebastian
>>  wrote:
>>>
>>> Hello,
>>>
>>>
>>>
>>> I am searching for a way in Yocto/BitBake to extract the source codes of
>>> the software applications developed by my company for delivery to our
>>> customers.
>>>
>>> The source codes shall be delivered as archive containing only the source
>>> files without the whole git repository history.
>>>
>>>
>>>
>>> Setup is that we have own Yocto layers/recipes referencing the company
>>> internal git repository (SRC_URI=”git://git.company.url”) and the concrete
>>> SRCREV to be used. Basic idea was to use the option
>>> BB_GENERATE_MIRROR_TARBALLS = "1" which generates an archive file
>with the
>>> application source code. Unfortunately the generated tarball contains the
>>> full bare cloned git repository with full history and not only the source
>>> files of the concrete SRCREV.
>>>
>>>
>>>
>>> As alternative I tried to use the archiver class. The generated tarballs
>>> contains the concrete source files but in addition the full git repository
>>> with history is contained too.
>>
>>
>> I am not sure if it is intended to keep SCM history though you might want to
>> file a bug
>>>
>>>
>>>
>>> Does anyone has an idea how to extract the concrete source files without
>>> git repository and history?
>>>
>>>
>>>
>>> Thank you very much for your help
>>>
>>> Sebastian Waldvogel
>>>
>>>
>>>
>>>
>>>
>>> --
>>> ___
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>
>
>
>--
>“If you're going to try, go all the way. Otherwise, don't even start. ..."
>  Charles Bukowski
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[linux-yocto] [kernel-cache][PATCH] features: add Intel Memory Protection Extensions

[Mikko Ylinen]

This commit adds a kernel feature to have the kernel support
for Intel Memory Protection Extensions (MPX).

A quote from kernel arch/x86/Kconfig:

"MPX provides hardware features that can be used in conjuction
with compiler-instrumented code to check memory references. It
is designed to detect buffer overflow or underflow bugs."

Intel MPX is available, e.g., on Skylake and on Goldmont (e.g.,
Intel 570x).

Signed-off-by: Mikko Ylinen 
---
 features/mpx/mpx.cfg | 1 +
 features/mpx/mpx.scc | 4 
 2 files changed, 5 insertions(+)
 create mode 100644 features/mpx/mpx.cfg
 create mode 100644 features/mpx/mpx.scc

diff --git a/features/mpx/mpx.cfg b/features/mpx/mpx.cfg
new file mode 100644
index ..ed1a6dae
--- /dev/null
+++ b/features/mpx/mpx.cfg
@@ -0,0 +1 @@
+CONFIG_X86_INTEL_MPX=y
diff --git a/features/mpx/mpx.scc b/features/mpx/mpx.scc
new file mode 100644
index ..1c9cc2a1
--- /dev/null
+++ b/features/mpx/mpx.scc
@@ -0,0 +1,4 @@
+define KFEATURE_DESCRIPTION "Intel MPX (Memory Protection Extensions)"
+define KFEATURE_COMPATIBILITY arch
+
+kconf hardware mpx.cfg
-- 
2.11.0

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

Re: [yocto] Raspberry Pi2 Fails to boot into LXDE.

[Yusuke Mitsuki]

Hello Steve

Would you try to other HDMI display such as PC monitor.

I suspects two points as follows.

* You enabled KMS(such as vc4graphics in MACHINE_FEATURE)
* Your display has not EDID.

If your HDMI settings in config.txt such as follows. There is a high
possibility that your HDMI display does not have EDID.

```
hdmi_group=2
hdmi_mode=87
```

When your display has not EDID, KMS will fail in initalization.
In such case, you have to create EDID file manually.

I hope this helps.


2017/03/10 14:43 "Gary Thomas" :

> On 2017-03-10 01:55, Steve Plant wrote:
>
>> OK, I have spent the last day googling my heart out trying to find the
>> Xorg.log file without any luck.
>>
>>
>> The problem is that due to the rpi hanging on boot, the only way I can
>> access the SD card to look for the file is place
>> it in a USB SD card reader and use my VirtualBox based Debian to "ls"
>> directores etc.
>>
>> Having established that there is no file located at /var/log/Xorg.log
>> (there isn't a log directory) but there is a
>> symbolic link in the var directory - goes nowhere.
>>
>>
>> After goggling I discovered that the file could also be in the
>> ~/.local/share/xorg/Xorg.0.log, however if I try to look
>> there I get "permission denied" and cannot seem to get to the root
>> directory of the card and I can't find a way around
>> this as I'm trying to access this directory through the USB card reader.
>>
>>
>> Looked everywhere with no answers, Is there anyone who could help me
>> here??
>>
>
> /var/log is on a volatile file system (i.e. it does not live on the SD
> card)
>
> If you can get into your board via SSH, you can copy the file and send it
>
> 
>> 
>> *From:* Khem Raj 
>> *Sent:* Wednesday, 8 March 2017 5:17 p.m.
>> *To:* Steve Plant
>> *Cc:* yocto@yoctoproject.org
>> *Subject:* Re: [yocto] Raspberry Pi2 Fails to boot into LXDE.
>>
>> On 17-03-08 12:40:51, Steve Plant wrote:
>>
>>> Hi All,
>>>
>>>
>>> Very new to all this linux world, and especially Yocto.
>>>
>>>
>>> I'm working on a embedded project at the moment using a raspberry pi2
>>> board.
>>>
>>>
>>> I have used toaster with Morty 2.2 to compile an image
>>> using"rpi-basic-image", to this I have added the following bitbake
>>> variables:
>>>
>>> Bitbake variables
>>>
>>> DISTRO
>>> poky
>>> DL_DIR
>>> /home/steve/poky/downloads
>>> IMAGE_FSTYPES
>>> ext3 jffs2 tar.bz2 rpi-sdimg
>>> IMAGE_INSTALL_append
>>> packagegroup-core-x11-base packagegroup-lxde-base connman
>>> PACKAGE_CLASSES
>>> package_rpm
>>> SSTATE_DIR
>>> /home/steve/poky/sstate-cache
>>>
>>> DISABLE_OVERSCAN
>>> 1
>>> GPU_MEM_1024
>>> 512
>>>
>>> I have dd'ed the image to an SD card increased the sdb2 partition to the
>>> max size and powered up the rpi. Everything looks fine to start with, as it
>>> displays the four raspberrys in the top left, then the white "Yocto
>>> Project" splash screen complete with small blue dot to the side appears,
>>> the progress bar moves across to 100 percent, then the screen turns black
>>> with a white
>>>
>> cursor in the middle and it appears to freeze with only a very dim one
>> second flash of the "act" led.
>>
>>>
>>>
>>> I have then connected the 7" touchscreen and apart from the added
>>> multicolored square at the very beginning I get the exact same boot up
>>> problem, hangs on the black screen with white cursor (good to see its all
>>> resized correctly for the TfT through!!)
>>>
>>>
>>> Before adding the packagegroup-core-x11-base and packagegroup-lxde-base
>>> I successfully copied over and ran the rpi-basic-image with no problem,
>>> ending up with a usable console.
>>>
>>>
>>> Looking for any help here, I'm thinking I've missed adding a package, or
>>> some type of local.conf instruction. any suggestions would be
>>> appreciated.
>>>
>>
>> Can you send the content of /var/log/Xorg.log file ?
>>
>
>
> --
> 
> Gary Thomas |  Consulting for the
> MLB Associates  |Embedded world
> 
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Raspberry Pi2 Fails to boot into LXDE.

[Gary Thomas]

On 2017-03-10 01:55, Steve Plant wrote:

OK, I have spent the last day googling my heart out trying to find the Xorg.log 
file without any luck.


The problem is that due to the rpi hanging on boot, the only way I can access 
the SD card to look for the file is place
it in a USB SD card reader and use my VirtualBox based Debian to "ls" 
directores etc.

Having established that there is no file located at /var/log/Xorg.log (there 
isn't a log directory) but there is a
symbolic link in the var directory - goes nowhere.


After goggling I discovered that the file could also be in the 
~/.local/share/xorg/Xorg.0.log, however if I try to look
there I get "permission denied" and cannot seem to get to the root directory of 
the card and I can't find a way around
this as I'm trying to access this directory through the USB card reader.


Looked everywhere with no answers, Is there anyone who could help me here??


/var/log is on a volatile file system (i.e. it does not live on the SD card)

If you can get into your board via SSH, you can copy the file and send it



*From:* Khem Raj 
*Sent:* Wednesday, 8 March 2017 5:17 p.m.
*To:* Steve Plant
*Cc:* yocto@yoctoproject.org
*Subject:* Re: [yocto] Raspberry Pi2 Fails to boot into LXDE.

On 17-03-08 12:40:51, Steve Plant wrote:

Hi All,


Very new to all this linux world, and especially Yocto.


I'm working on a embedded project at the moment using a raspberry pi2 board.


I have used toaster with Morty 2.2 to compile an image using"rpi-basic-image", 
to this I have added the following bitbake variables:

Bitbake variables

DISTRO
poky
DL_DIR
/home/steve/poky/downloads
IMAGE_FSTYPES
ext3 jffs2 tar.bz2 rpi-sdimg
IMAGE_INSTALL_append
packagegroup-core-x11-base packagegroup-lxde-base connman
PACKAGE_CLASSES
package_rpm
SSTATE_DIR
/home/steve/poky/sstate-cache

DISABLE_OVERSCAN
1
GPU_MEM_1024
512

I have dd'ed the image to an SD card increased the sdb2 partition to the max size and 
powered up the rpi. Everything looks fine to start with, as it displays the four 
raspberrys in the top left, then the white "Yocto Project" splash screen 
complete with small blue dot to the side appears, the progress bar moves across to 100 
percent, then the screen turns black with a white

cursor in the middle and it appears to freeze with only a very dim one second flash of 
the "act" led.



I have then connected the 7" touchscreen and apart from the added multicolored 
square at the very beginning I get the exact same boot up problem, hangs on the 
black screen with white cursor (good to see its all resized correctly for the TfT 
through!!)


Before adding the packagegroup-core-x11-base and packagegroup-lxde-base I 
successfully copied over and ran the rpi-basic-image with no problem, ending up 
with a usable console.


Looking for any help here, I'm thinking I've missed adding a package, or some 
type of local.conf instruction. any suggestions would be 
appreciated.


Can you send the content of /var/log/Xorg.log file ?



--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] Raspberry Pi2 Fails to boot into LXDE.

[Steve Plant]

OK, I have spent the last day googling my heart out trying to find the Xorg.log 
file without any luck.


The problem is that due to the rpi hanging on boot, the only way I can access 
the SD card to look for the file is place it in a USB SD card reader and use my 
VirtualBox based Debian to "ls" directores etc.

Having established that there is no file located at /var/log/Xorg.log (there 
isn't a log directory) but there is a symbolic link in the var directory - goes 
nowhere.


After goggling I discovered that the file could also be in the 
~/.local/share/xorg/Xorg.0.log, however if I try to look there I get 
"permission denied" and cannot seem to get to the root directory of the card 
and I can't find a way around this as I'm trying to access this directory 
through the USB card reader.


Looked everywhere with no answers, Is there anyone who could help me here??


Regards, Steve.



From: Khem Raj 
Sent: Wednesday, 8 March 2017 5:17 p.m.
To: Steve Plant
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Raspberry Pi2 Fails to boot into LXDE.

On 17-03-08 12:40:51, Steve Plant wrote:
> Hi All,
>
>
> Very new to all this linux world, and especially Yocto.
>
>
> I'm working on a embedded project at the moment using a raspberry pi2 board.
>
>
> I have used toaster with Morty 2.2 to compile an image 
> using"rpi-basic-image", to this I have added the following bitbake variables:
>
> Bitbake variables
>
> DISTRO
> poky
> DL_DIR
> /home/steve/poky/downloads
> IMAGE_FSTYPES
> ext3 jffs2 tar.bz2 rpi-sdimg
> IMAGE_INSTALL_append
> packagegroup-core-x11-base packagegroup-lxde-base connman
> PACKAGE_CLASSES
> package_rpm
> SSTATE_DIR
> /home/steve/poky/sstate-cache
>
> DISABLE_OVERSCAN
> 1
> GPU_MEM_1024
> 512
>
> I have dd'ed the image to an SD card increased the sdb2 partition to the max 
> size and powered up the rpi. Everything looks fine to start with, as it 
> displays the four raspberrys in the top left, then the white "Yocto Project" 
> splash screen complete with small blue dot to the side appears, the progress 
> bar moves across to 100 percent, then the screen turns black with a white 
> cursor in the middle and it appears to freeze with only a very dim one second 
> flash of the "act" led.
>
>
> I have then connected the 7" touchscreen and apart from the added 
> multicolored square at the very beginning I get the exact same boot up 
> problem, hangs on the black screen with white cursor (good to see its all 
> resized correctly for the TfT through!!)
>
>
> Before adding the packagegroup-core-x11-base and packagegroup-lxde-base I 
> successfully copied over and ran the rpi-basic-image with no problem, ending 
> up with a usable console.
>
>
> Looking for any help here, I'm thinking I've missed adding a package, or some 
> type of local.conf instruction. any suggestions would be 
> appreciated.

Can you send the content of /var/log/Xorg.log file ?

>
>
>
> Regards, Steve.

> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
yocto Info Page
lists.yoctoproject.org
Discussion of all things about the Yocto Project. Read our Community Guidelines 
or learn more about how to participate in other community discussions.



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

Re: [linux-yocto] [PULL REQUEST] Intel Axxia updates to linux-yocto-4.9

[Bruce Ashfield]

On 2017-03-09 10:02 AM, Daniel Dragomir wrote:

Hello Bruce!

This is the first pull request for Axxia changes on kernel 4.9 which were
ported from our 4.1 Yocto branches.
I checked all the patches with checkpatch.pl script and fixed all errors.
Also, I compiled Axxia BSP using both branches and successfully booted the 
board.


Thanks!



Please pull the patches from
https://github.com/axxia/axxia_yocto_linux_4.9_pull.git
into
git://git.yoctoproject.org/linux-yocto-4.9

Pull
standard/axxia/base-1.3 -> standard/axxia/base
standard/preempt-rt/axxia/base-1.3 -> standard/preempt-rt/axxia/base

If you add more patches to standard/(preempt-rt)/axxia/base beforehand
please notify me. I will rebase our changes so you can do a clean,
fast-forward pull.


They look fine to me, and I'm just going through an update cycle,
so I've now merged and pushed them to the repo.

Bruce



Thank you,
Daniel Dragomir


Anders Berg (14):
  arm64: dts: Add initial AXM56xx device tree
  arm64: Add Axxia NEMAC Gigabit Ethernet controller
  arm64: dts: Corrected SPI definitions for AXM56xx
  arm64: dts: Added SPI and flash for AXM56xx sim
  arm64: dts: Add VMFS node for simulation DT
  net: ethernet: Enable Axxia FEMAC driver
  arm64: dts: Add device tree for AXC67xx (Lionfish)
  arm64: dts: Fixed bad VMFS reg property
  net: ethernet: Add MDIO driver for LSI AXM55xx
  net: ethernet: Add driver for FEMAC on AXM55xx
  drivers: net: Add Axxia NEMAC driver
  arm64: dts: Add NEMAC device nodes
  net: nemac: Fix crash when using NEMAC from bootloader
  misc: lsi-ncr: Only use AMP lock on PPC platforms.

Charlie Paul (42):
  i2c: Support for i2c to the LSI axxia 5500 board
  fs/vmfs: Added VMFS support to Axxia BSP
  drivers/dma: Updated to support Axxia dma
  arch/arm/boot/dts: Files added to support axxia 5500 board
  arch/arm/boot: Changes to support the axxia BSP
  arch/arm/mach-axxia: kernel files to support the mach-axxia
  arch/arm: arm changes to support the axxia BSP
  misc: Changes made to support axxia BSP
  drivers/mtd: Changes to support the axxia BSP
  drivers/net/ethernet: Changes to support the axxia BSP
  drivers/rapidio/devices: Changes to support axxia BSP
  drivers/spi: Changes to support the axxia BSP
  drivers/hwmon: Changes made to support the axxia BSP
  drivers/tty: Changes to support the axxia BSP
  drivers/usb/host: Changes to support the axxia BSP
  fs/vmfs: Changes to add VMFS support for axxia.
  arch/arm/mach-axxia: Removed axxia_circular_queue
  arch/arm/mach-axxia: fixed compiler warning
  arch/arm/mach-axxia: fixed NO SMP
  arch/arm/mach-axxia: changed affinity parameter to cpu
  arch/arm/mach-axxia: Reverse checkpatch compatibility
  arch/arm/mach-axxia: Fixed L2 power up failure
  hwmon: Remove adt75 redundant driver
  arch/arm/axxia: Remove the axxia zImage.fm build
  fs/vmfs: Altered to allow vmfs to compile
  drivers/ethernet/lsi: Fixed code to support 4.1
  arm/mach-axxia: Updated to support linux 4.1
  drivers/misc: Updated to support linux 4.1
  fs/vmfs: Updated code to support linux 4.1
  arm64: mm: Removed calls to reset_pmuserenr_el0
  fs/vmfs: Updated to support the axxia on Linux 4.9
  drivers/rapidio: Update to support linux 4.9
  drivers/pci: updated to support axxia for 4.9
  drivers/net: Updated to support axxia on 4.9
  driver/net/ethernet: Updated to support axxia on 4.9
  drivers/misc: Updated to support axxia on 4.9
  drivers/i2c/busses: Updated to support axxia on 4.9
  arch/arm/mach-axxia: Updated to support 4.9 on the 5500
  i2c/busses: Updated to support 4.9 on the 5500
  drivers/net: Updated to support 4.9 on the 5500
  boot/dts/axxia: Updated to support 4.9 on the 5500
  arm/mach-axxia: allow interupts (16-32) set to LOW

David Mercado (1):
  kernel/irq/manage.c: Fix irq_set_affinity to allow use with buslocks

Fredrik Markstrom (1):
  usb ehci-ci13612: Enable HCD_BH mode in ci13612

Gary McGee (5):
  mach-axxia: Make AXXIA_NCR_RESET_CHECK a Kconfig Option
  power: reset: preliminary support for Axxia DDR Retention reset
  arch/arm/mach-axxia: Flush TLB
  axxia-reset.c: Use syscon address from device tree
  axxia: enable trng for axc6732-waco and axm5616-victoria

Geoff Levand (1):
  arm64: Enable the identity mapping to allow the MMU disabling

John Jacques (98):
  arch/arm64: Correct GIC Physical Address in Axxia
  arch/arm64: Correct GIC Physical Address in Axxia XLF
  axxia: Add dts for Emulation
  mrch/arm64/mach-axxia: Device Tree Updates for Emulation
  axxia: Updated Device Trees for Emulation and Simulation
  arch/arm64: Use SYSROOT If Defined
  arch/arm64: Add Device Tree for Axxia Emulation
  arch/arm64: Axxia Device Tree and Configuration Changes
  arch/arm64: Axxia Device Tree Update
  arch/arm64: Axxia Interrupt Number Updates
  arch/arm64: Update the Axxia Device Tree for Emulation
  arch/arm64: Correct physical addresses for Simulation dts
  arch/arm64: Axxia Device Tree Updates for the XLF Platform
  arch/arm64: Axxia Device Tree Update
  arch/arm64: Correct 

Re: [linux-yocto] [PATCH 0/9] Intel Axxia updates to linux-yocto-4.1

[Bruce Ashfield]

On 2017-03-09 11:22 AM, Daniel Dragomir wrote:

Hello Bruce!

This series of patches brings various improvements to the Intel Axxia
drivers from linux-yocto-4.1, including EDAC, VMFS, HWRNG, MISC and PCI
drivers and some updates in device trees for Intel Axxia boards.

If all the patches are ok, please pull them from
https://github.com/axxia/axxia_yocto_linux_4.1_pull.git
into
git://git.yoctoproject.org/linux-yocto-4.1
Pull
standard/axxia/base-1.51 -> standard/axxia/base
standard/preempt-rt/axxia/base-1.51 -> standard/preempt-rt/axxia/base

If you add more patches to standard/(preempt-rt)/axxia/base beforehand
please notify me. I will rebase our changes so you can do a clean,
fast-forward pull.


These look fine to me, and are now merged.

Bruce



Thank you,
Daniel Dragomir


John Jacques (5):
  edac: Added sm edac driver for AXM56XX family
  axxia: Device Tree Updates for 5600 GPIO
  axxia: Device Tree Updates for 6700 GPIO
  axxia: Update the VMFS Driver
  drivers/pci: Support the Updated Axxia PCIe/sRIO Coefficients

Marek Bykowski (2):
  char: hwrng: don't use static pointer to driver data as it goes to
.bss
  arch/arm/mach-axxia: adding atomicity to per_cpu data manipulation

Marek Majtyka (2):
  edac: Added cm edac driver for AXM56XX family
  edac: Added fixes for smem edac driver

 .../devicetree/bindings/arm/axxia/edac.txt |   14 +
 .../devicetree/bindings/arm/axxia/edac_cm.txt  |   21 +
 arch/arm/mach-axxia/axxia-gic.c|   32 +-
 arch/arm64/Kconfig |1 +
 arch/arm64/boot/dts/intel/axc67xx.dtsi |   16 +-
 arch/arm64/boot/dts/intel/axm5616-victoria.dts |   16 +
 arch/arm64/boot/dts/intel/axm56xx.dtsi |   45 +-
 arch/arm64/include/asm/edac.h  |   13 +
 drivers/char/hw_random/axxia-rng.c |8 +-
 drivers/edac/Kconfig   |   23 +-
 drivers/edac/Makefile  |4 +-
 drivers/edac/axxia_edac-cmc_56xx.c | 1223 
 drivers/edac/axxia_edac-mc.c   |   19 +-
 drivers/edac/axxia_edac-mc_56xx.c  | 1482 
 drivers/misc/axxia-oem.c   |   14 +-
 drivers/misc/axxia-pei.c   |  287 +++-
 drivers/pci/host/pcie-axxia.c  |5 +-
 fs/vmfs/inode.c|2 +-
 include/linux/axxia-pei.h  |2 +-
 19 files changed, 3167 insertions(+), 60 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/axxia/edac.txt
 create mode 100644 Documentation/devicetree/bindings/arm/axxia/edac_cm.txt
 create mode 100644 arch/arm64/include/asm/edac.h
 create mode 100644 drivers/edac/axxia_edac-cmc_56xx.c
 create mode 100644 drivers/edac/axxia_edac-mc_56xx.c



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

Re: [yocto] Intoducting myself: Applying for Outreachy

[Jeff Osier-Mixon]

Thanks, Leonardo & Armin

The Outreachy page for YP is here:

https://www.yoctoproject.org/outreachy-internship

any new potential interns can contact me directly

On Tue, Mar 7, 2017 at 9:24 AM, Soumya Gupta  wrote:

> Hi,
>
> Please look under Yocto under Participating Organisations
> 
> Thank you
>
> Best,
> Soumya Atul Gupta
> Final Year Undergraduate Student, ECE
> Netaji Subhas Institute of Technology
> New Delhi, India
>
>
> On Tue, Mar 7, 2017 at 10:38 PM, Leonardo Sandoval <
> leonardo.sandoval.gonza...@linux.intel.com> wrote:
>
>> On Tue, 2017-03-07 at 22:18 +0530, Soumya Gupta wrote:
>> > Hi all,
>> >
>> >
>> > My name is Soumya, an I am a final year Engineering undergraduate
>> > student from New Delhi. I would love to work to contribute to Yocto
>> > for the summer.
>> >
>> >
>> > I have been coding in Python for the past year and I am quite at ease
>> > with the same. It states on the Outreachy page, that there is a
>> > project relating to the building of autobuilders. I want to work on
>> > the same.
>>
>> can you point to that page?
>>
>> There is an autobuilder repo at git.yoctoproject.org, perhaps you can
>> start looking there.
>>
>> >
>> > Being a newbie, it would be great, if someone could guide me on the
>> > right path here
>> >
>> > Thanks already
>> >
>> >
>> > Best,
>> > Soumya Atul Gupta
>> > Final Year Undergraduate Student, ECE
>> > Netaji Subhas Institute of Technology
>> > New Delhi, India
>> >
>> >
>> > --
>> > ___
>> > yocto mailing list
>> > yocto@yoctoproject.org
>> > https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>


-- 
Jeff Osier-Mixon - Open Source Community Engineer, Intel Corporation
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Source Code provision without full git repository history

[Daniel.]

There are some tools to automate the testing and delivery that may
make the deployment less painfull. Jenkins and Buildbot are examples

Regards,

2017-03-09 13:28 GMT-03:00 Daniel. :
> I'm not trying to be simplistic here, but, why not package the source
> releases to a tarball (with git archive or somthing) and provide it
> through a FTP server?
>
> Regards,
>
> 2017-03-09 11:29 GMT-03:00 Khem Raj :
>>
>> On Thu, Mar 9, 2017 at 5:02 AM Waldvogel, Sebastian
>>  wrote:
>>>
>>> Hello,
>>>
>>>
>>>
>>> I am searching for a way in Yocto/BitBake to extract the source codes of
>>> the software applications developed by my company for delivery to our
>>> customers.
>>>
>>> The source codes shall be delivered as archive containing only the source
>>> files without the whole git repository history.
>>>
>>>
>>>
>>> Setup is that we have own Yocto layers/recipes referencing the company
>>> internal git repository (SRC_URI=”git://git.company.url”) and the concrete
>>> SRCREV to be used. Basic idea was to use the option
>>> BB_GENERATE_MIRROR_TARBALLS = "1" which generates an archive file with the
>>> application source code. Unfortunately the generated tarball contains the
>>> full bare cloned git repository with full history and not only the source
>>> files of the concrete SRCREV.
>>>
>>>
>>>
>>> As alternative I tried to use the archiver class. The generated tarballs
>>> contains the concrete source files but in addition the full git repository
>>> with history is contained too.
>>
>>
>> I am not sure if it is intended to keep SCM history though you might want to
>> file a bug
>>>
>>>
>>>
>>> Does anyone has an idea how to extract the concrete source files without
>>> git repository and history?
>>>
>>>
>>>
>>> Thank you very much for your help
>>>
>>> Sebastian Waldvogel
>>>
>>>
>>>
>>>
>>>
>>> --
>>> ___
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>
>
>
> --
> “If you're going to try, go all the way. Otherwise, don't even start. ..."
>   Charles Bukowski



-- 
“If you're going to try, go all the way. Otherwise, don't even start. ..."
  Charles Bukowski
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Source Code provision without full git repository history

[Daniel.]

I'm not trying to be simplistic here, but, why not package the source
releases to a tarball (with git archive or somthing) and provide it
through a FTP server?

Regards,

2017-03-09 11:29 GMT-03:00 Khem Raj :
>
> On Thu, Mar 9, 2017 at 5:02 AM Waldvogel, Sebastian
>  wrote:
>>
>> Hello,
>>
>>
>>
>> I am searching for a way in Yocto/BitBake to extract the source codes of
>> the software applications developed by my company for delivery to our
>> customers.
>>
>> The source codes shall be delivered as archive containing only the source
>> files without the whole git repository history.
>>
>>
>>
>> Setup is that we have own Yocto layers/recipes referencing the company
>> internal git repository (SRC_URI=”git://git.company.url”) and the concrete
>> SRCREV to be used. Basic idea was to use the option
>> BB_GENERATE_MIRROR_TARBALLS = "1" which generates an archive file with the
>> application source code. Unfortunately the generated tarball contains the
>> full bare cloned git repository with full history and not only the source
>> files of the concrete SRCREV.
>>
>>
>>
>> As alternative I tried to use the archiver class. The generated tarballs
>> contains the concrete source files but in addition the full git repository
>> with history is contained too.
>
>
> I am not sure if it is intended to keep SCM history though you might want to
> file a bug
>>
>>
>>
>> Does anyone has an idea how to extract the concrete source files without
>> git repository and history?
>>
>>
>>
>> Thank you very much for your help
>>
>> Sebastian Waldvogel
>>
>>
>>
>>
>>
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>



-- 
“If you're going to try, go all the way. Otherwise, don't even start. ..."
  Charles Bukowski
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [imx6qsabresd][morty] Locales not generated

[Fabio Emiliani]

Dear all,

I'm trying to configure locale support in Yocto. My taget machine is: 
imx6qsabresd (i.MX 6Quad Processor), yocto version is: morty.


I've created a base image with the command: bitbake core-image-base, 
then I've booted the image in my sabre board. Everything works fine 
except locales.


Reading in the docs I've found:

You can set |GLIBC_GENERATE_LOCALES| in your |local.conf| file. By 
default, all locales are generated. 
Link: 
http://www.yoctoproject.org/docs/1.8/mega-manual/mega-manual.html#var-GLIBC_GENERATE_LOCALES


In my build I've found only a locale, path: /usr/share/locale/en_GB, no 
other locales are generated. Executing the "locale" command I've got:



root@imx6qsabresd:/usr/share/locale# locale
LANG=
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=

Default locale is POSIX, not en_GB.

I've tried several options in my local.conf:

 * ENABLE_BINARY_LOCALE_GENERATION = "1" to enable the generation of
   locales at build time
 * IMAGE_INSTALL_append = " glibc-utils localedef" to add to the build
   locale and localdef
 * IMAGE_LINGUAS = "en-gb en-us zh-cn" to specify the add of additional
   packages

None of this options had effects.

Looking in the features list of the next yocto release I've found this bug:


https://bugzilla.yoctoproject.org/show_bug.cgi?id=9070
is it possible that curreny release has problems respect to locale 
generation?


_/Why locales are not generated? What do I have to configure to generate 
them?/_


Thanks in advance for your time

Regards,

Fabio Emiliani

--

*Fabio Emiliani*

*/Software Engineer/*

/Ph. +39 075 8298 530 /

/fabio.emili...@artgroup-spa.com/ 

DISCLAIMER
This email and any attachment may contain confidential information. If 
you are not the intended recipient you are not authorised to copy or 
disclose all or any part of it without the prior written consent of ART SpA.


/ART SpA – Step Forward With US - //www.artgroup-spa.com/logo_ART_firma-1//

/Ph. +39 075 8298 501 – Fax +39 075 8298 525 /

P*Please consider our environment  before printing this e-mail***

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

[linux-yocto] [PATCH 9/9] drivers/pci: Support the Updated Axxia PCIe/sRIO Coefficients

[Daniel Dragomir]

From: John Jacques 

Get the updated PCIe/sRIO parameters from the device tree and update
the appropriate SerDes registers.

Signed-off-by: John Jacques 
---
 drivers/misc/axxia-pei.c  | 287 +-
 drivers/pci/host/pcie-axxia.c |   5 +-
 include/linux/axxia-pei.h |   2 +-
 3 files changed, 290 insertions(+), 4 deletions(-)

diff --git a/drivers/misc/axxia-pei.c b/drivers/misc/axxia-pei.c
index bb40dd0..0d04ce7 100644
--- a/drivers/misc/axxia-pei.c
+++ b/drivers/misc/axxia-pei.c
@@ -41,6 +41,26 @@ static int is_6700;
 static void __iomem *pcie_gpreg0;
 static void __iomem *pcie_rc;
 
+static int is_pei_control_available;
+static int is_pei_control_v2;
+
+struct pei_coefficients {
+   unsigned version;
+   unsigned control;
+   unsigned primary_input_clock;
+   unsigned input_ref_clock_range;
+   unsigned lane_0_eq_main;
+   unsigned lane_0_eq_pre;
+   unsigned lane_0_eq_post;
+   unsigned lane_0_vboost;
+   unsigned lane_1_eq_main;
+   unsigned lane_1_eq_pre;
+   unsigned lane_1_eq_post;
+   unsigned lane_1_vboost;
+};
+
+static struct pei_coefficients coefficients;
+
 enum SataMode {
SATA0,
SATA1
@@ -753,12 +773,148 @@ enable_lane(u32 phy, u32 lane, enum Dir dir)
 
 /*
   
--
+  update_settings
+*/
+
+static void
+update_settings(void)
+{
+   int i;
+   unsigned int region;
+
+   /*
+ Make sure the parameters are version 2...
+   */
+
+   if (!is_pei_control_v2)
+   return;
+
+   region = NCP_REGION_ID(0x115, 0);
+
+   /*
+ Set per serdes values.
+   */
+
+   for (i = 0; i < 4; ++i) {
+   unsigned int offset;
+   unsigned int pic;
+   unsigned int ref_range;
+   unsigned int value;
+
+   offset = (0xf8 + (i * 0x18));
+
+   if (0 != (coefficients.primary_input_clock & (0xff << (i * 8
+   pic = 2;
+   else
+   pic = 0;
+
+   ref_range = (coefficients.input_ref_clock_range &
+(0xff << (i * 8))) >> (i * 8);
+
+   ncr_read32(region, offset, );
+   pr_debug("0x%x.0x%x.0x%x : 0x%x => ",
+ NCP_NODE_ID(region), NCP_TARGET_ID(region), offset,
+ value);
+   value &= ~0x72;
+   value |= pic;
+   value |= ref_range << 4;
+   pr_debug("0x%x\n", value);
+   ncr_write32(region, offset, value);
+   }
+
+   /*
+ Set per lane values.
+   */
+
+   for (i = 0; i < 8; ++i) {
+   unsigned int offset;
+   unsigned int eq_main;
+   unsigned int pre;
+   unsigned int post;
+   unsigned int boost;
+   unsigned int value;
+
+   if (4 > i) {
+   eq_main = coefficients.lane_0_eq_main;
+   pre = coefficients.lane_0_eq_pre;
+   post = coefficients.lane_0_eq_post;
+   boost = coefficients.lane_0_vboost;
+   } else {
+   eq_main = coefficients.lane_1_eq_main;
+   pre = coefficients.lane_1_eq_pre;
+   post = coefficients.lane_1_eq_post;
+   boost = coefficients.lane_1_vboost;
+   }
+
+   switch (i % 4) {
+   case 0:
+   eq_main &= 0x3f;
+   pre &= 0x3f;
+   post &= 0x3f;
+   boost &= 0x3f;
+   break;
+   case 1:
+   eq_main = (eq_main & 0x3f00) >> 8;
+   pre = (pre & 0x3f00) >> 8;
+   post = (post & 0x3f00) >> 8;
+   boost = (boost & 0x3f00) >> 8;
+   break;
+   case 2:
+   eq_main = (eq_main & 0x3f) >> 16;
+   pre = (pre & 0x3f) >> 16;
+   post = (post & 0x3f) >> 16;
+   boost = (boost & 0x3f) >> 16;
+   break;
+   case 3:
+   eq_main = (eq_main & 0x3f00) >> 24;
+   pre = (pre & 0x3f00) >> 24;
+   post = (post & 0x3f00) >> 24;
+   boost = (boost & 0x3f00) >> 24;
+   break;
+   default:
+   pr_err("Error setting coefficients!\n");
+   break;
+   }
+
+   offset = 0x18 + (i * 0x1c);
+
+   ncr_read32(region, offset, );
+   pr_debug("0x%x.0x%x.0x%x : 0x%x => ",
+ 

[linux-yocto] [PATCH 6/9] axxia: Update the VMFS Driver

[Daniel Dragomir]

From: John Jacques 

Update the driver based on inode_change_ok() change.

Fix compiler warnings.

Signed-off-by: John Jacques 
---
 drivers/misc/axxia-oem.c | 14 +++---
 fs/vmfs/inode.c  |  2 +-
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/misc/axxia-oem.c b/drivers/misc/axxia-oem.c
index 4db5c6c..f5846b8 100644
--- a/drivers/misc/axxia-oem.c
+++ b/drivers/misc/axxia-oem.c
@@ -57,7 +57,7 @@ invoke_oem_fn(struct oem_parameters *p)
 "mov %x3, x3" : "=r" (p->reg0), "=r" (p->reg1),
 "=r" (p->reg2), "=r" (p->reg3));
 
-   return 0;
+   return;
 }
 
 /*
@@ -101,7 +101,7 @@ axxia_dspc_write(struct file *file, const char __user 
*buffer,
if (copy_from_user(input, buffer, count))
return -EFAULT;
 
-   mask = kstrtoul(input, NULL, 0);
+   mask = kstrtoul(input, 0, 0);
axxia_dspc_set_state((unsigned int)mask);
 
return count;
@@ -154,7 +154,7 @@ axxia_actlr_el3_write(struct file *file, const char __user 
*buffer,
if (copy_from_user(input, buffer, count))
return -EFAULT;
 
-   axxia_actlr_el3_set(kstrtoul(input, NULL, 0));
+   axxia_actlr_el3_set(kstrtoul(input, 0, 0));
 
return count;
 }
@@ -206,7 +206,7 @@ axxia_actlr_el2_write(struct file *file, const char __user 
*buffer,
if (copy_from_user(input, buffer, count))
return -EFAULT;
 
-   axxia_actlr_el2_set(kstrtoul(input, NULL, 0));
+   axxia_actlr_el2_set(kstrtoul(input, 0, 0));
 
return count;
 }
@@ -267,7 +267,7 @@ axxia_dspc_set_state(unsigned long state)
if (0 != parameters.reg0)
pr_warn("Setting the DSP State Failed!\n");
 
-   return 0;
+   return;
 }
 EXPORT_SYMBOL(axxia_dspc_set_state);
 
@@ -308,7 +308,7 @@ axxia_actlr_el3_set(unsigned long input)
if (0 != parameters.reg0)
pr_warn("Setting ACTLR_EL3 Failed!\n");
 
-   return 0;
+   return;
 }
 EXPORT_SYMBOL(axxia_actlr_el3_set);
 
@@ -349,7 +349,7 @@ axxia_actlr_el2_set(unsigned long input)
if (0 != parameters.reg0)
pr_warn("Setting ACTLR_EL2 Failed!\n");
 
-   return 0;
+   return;
 }
 EXPORT_SYMBOL(axxia_actlr_el2_set);
 
diff --git a/fs/vmfs/inode.c b/fs/vmfs/inode.c
index fec0a31..4cf1212 100644
--- a/fs/vmfs/inode.c
+++ b/fs/vmfs/inode.c
@@ -484,7 +484,7 @@ int vmfs_notify_change(struct dentry *dentry, struct iattr 
*attr)
if (error)
goto out;
 
-   error = inode_change_ok(inode, attr);
+   error = setattr_prepare(dentry, attr);
if (error < 0)
goto out;
 
-- 
2.7.4

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

[linux-yocto] [PATCH 7/9] char: hwrng: don't use static pointer to driver data as it goes to .bss

[Daniel Dragomir]

From: Marek Bykowski 

Also do not pass a pointer to the pointer allocated in the stack to
the function as effectively you pass the address from the stack
frame which is nowhere after the frame returns.

Signed-off-by: Marek Bykowski 
---
 drivers/char/hw_random/axxia-rng.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/char/hw_random/axxia-rng.c 
b/drivers/char/hw_random/axxia-rng.c
index 7790493..42b1ba3 100644
--- a/drivers/char/hw_random/axxia-rng.c
+++ b/drivers/char/hw_random/axxia-rng.c
@@ -452,7 +452,7 @@ static DRIVER_ATTR(trng_test_mode, S_IRUGO | S_IWUSR,
  */
 static int trng_probe(struct platform_device *pdev)
 {
-   static struct trng_dev *dev;
+   struct trng_dev *dev;
void __iomem *regs;
int rc;
u32 *pregs;
@@ -464,7 +464,7 @@ static int trng_probe(struct platform_device *pdev)
rc = -ENOMEM;
goto err;
}
-   dev_set_drvdata(>dev, );
+   dev_set_drvdata(>dev, dev);
kref_init(>ref);
dev->pdev = pdev;
 
@@ -483,7 +483,7 @@ static int trng_probe(struct platform_device *pdev)
 #endif
/* Attach to IRQ */
dev->irq = irq_of_parse_and_map(pdev->dev.of_node, 0);
-   rc = request_irq(dev->irq, trng_isr, 0, "trng", );
+   rc = request_irq(dev->irq, trng_isr, 0, "trng", dev);
if (rc)
goto err;
 
@@ -546,7 +546,7 @@ static void trng_destroy(struct kref *ref)
if (test_and_clear_bit(FLAG_REGISTERED, >flags))
hwrng_unregister(>rng_dev);
if (dev->irq)
-   free_irq(dev->irq, );
+   free_irq(dev->irq, dev);
iounmap(dev->regs);
kfree(dev);
 }
-- 
2.7.4

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

[linux-yocto] [PATCH 5/9] axxia: Device Tree Updates for 6700 GPIO

[Daniel Dragomir]

From: John Jacques 

All of the GPIO interrupts (8) are for the GPIO lines in
the 2nd gpio block, not one interrupt for each of the first
eight blocks.

Signed-off-by: John Jacques 
---
 arch/arm64/boot/dts/intel/axc67xx.dtsi | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/boot/dts/intel/axc67xx.dtsi 
b/arch/arm64/boot/dts/intel/axc67xx.dtsi
index 77624e7..adf6404 100644
--- a/arch/arm64/boot/dts/intel/axc67xx.dtsi
+++ b/arch/arm64/boot/dts/intel/axc67xx.dtsi
@@ -460,7 +460,6 @@
compatible = "arm,pl061", "arm,primecell";
gpio-controller;
reg = <0x80 0x8070 0 0x1>;
-   interrupts = ;
clocks = <_per 0>;
clock-names = "apb_pclk";
status = "disabled";
@@ -471,7 +470,6 @@
compatible = "arm,pl061", "arm,primecell";
gpio-controller;
reg = <0x80 0x8071 0 0x1>;
-   interrupts = ;
clocks = <_per 0>;
clock-names = "apb_pclk";
status = "disabled";
@@ -482,7 +480,14 @@
compatible = "arm,pl061", "arm,primecell";
gpio-controller;
reg = <0x80 0x8072 0 0x1>;
-   interrupts = ;
+   interrupts = ,
+,
+,
+,
+,
+,
+,
+;
clocks = <_per 0>;
clock-names = "apb_pclk";
status = "disabled";
@@ -493,7 +498,6 @@
compatible = "arm,pl061", "arm,primecell";
gpio-controller;
reg = <0x80 0x8073 0 0x1>;
-   interrupts = ;
clocks = <_per 0>;
clock-names = "apb_pclk";
status = "disabled";
@@ -504,7 +508,6 @@
compatible = "arm,pl061", "arm,primecell";
gpio-controller;
reg = <0x80 0x8074 0 0x1>;
-   interrupts = ;
clocks = <_per 0>;
clock-names = "apb_pclk";
status = "disabled";
@@ -515,7 +518,6 @@
compatible = "arm,pl061", "arm,primecell";
gpio-controller;
reg = <0x80 0x8075 0 0x1>;
-   interrupts = ;
clocks = <_per 0>;
clock-names = "apb_pclk";
status = "disabled";
@@ -526,7 +528,6 @@
compatible = "arm,pl061", "arm,primecell";
gpio-controller;
reg = <0x80 0x8076 0 0x1>;
-   interrupts = ;
clocks = <_per 0>;
clock-names = "apb_pclk";
status = "disabled";
@@ -537,7 +538,6 @@
compatible = "arm,pl061", "arm,primecell";
gpio-controller;
reg = <0x80 0x8077 0 0x1>;
-   interrupts = ;
clocks = <_per 0>;
clock-names = "apb_pclk";
status = "disabled";
-- 
2.7.4

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

[linux-yocto] [PATCH 4/9] axxia: Device Tree Updates for 5600 GPIO

[Daniel Dragomir]

From: John Jacques 

Add missing interrupts to the second GPIO block.

Signed-off-by: John Jacques 
---
 arch/arm64/boot/dts/intel/axm56xx.dtsi | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/intel/axm56xx.dtsi 
b/arch/arm64/boot/dts/intel/axm56xx.dtsi
index 8444acf..78c2370 100644
--- a/arch/arm64/boot/dts/intel/axm56xx.dtsi
+++ b/arch/arm64/boot/dts/intel/axm56xx.dtsi
@@ -450,7 +450,14 @@
compatible = "arm,pl061", "arm,primecell";
gpio-controller;
reg = <0x80 0x8019 0 0x1>;
-   interrupts = ;
+   interrupts = ,
+,
+,
+,
+,
+,
+,
+;
clocks = <_per 0>;
clock-names = "apb_pclk";
status = "disabled";
-- 
2.7.4

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

[linux-yocto] [PATCH 2/9] edac: Added cm edac driver for AXM56XX family

[Daniel Dragomir]

From: Marek Majtyka 

  - Driver source code.
  - Device tree configuration.
  - Updated kbuild and documentation.

Signed-off-by: Marek Majtyka 
---
 .../devicetree/bindings/arm/axxia/edac_cm.txt  |   21 +
 arch/arm64/boot/dts/intel/axm5616-victoria.dts |8 +
 arch/arm64/boot/dts/intel/axm56xx.dtsi |   18 +
 drivers/edac/Kconfig   |9 +
 drivers/edac/Makefile  |1 +
 drivers/edac/axxia_edac-cmc_56xx.c | 1223 
 6 files changed, 1280 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/axxia/edac_cm.txt
 create mode 100644 drivers/edac/axxia_edac-cmc_56xx.c

diff --git a/Documentation/devicetree/bindings/arm/axxia/edac_cm.txt 
b/Documentation/devicetree/bindings/arm/axxia/edac_cm.txt
new file mode 100644
index 000..f61105e
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/axxia/edac_cm.txt
@@ -0,0 +1,21 @@
+Axxia Error Detection & Correction [EDAC]
+The EDAC accesses a range of registers in the memory controllers.
+
+Required properties:
+- compatible : should contain "intel,cmmon"
+- interrupts : Should contain the CMEM controller IRQ
+
+Example:
+   cm0: cm0@00080009 {
+compatible = "intel,cmmon";
+ reg = <0 0x0080009 0 0x1000>;
+ syscon = <>;
+ interrupts = <0 233 4>;
+   };
+
+   cm1: cm1@00090009 {
+compatible = "intel,cmmon";
+ reg = <0 0x0090009 0 0x1000>;
+ syscon = <>;
+ interrupts = <0 234 4>;
+   };
diff --git a/arch/arm64/boot/dts/intel/axm5616-victoria.dts 
b/arch/arm64/boot/dts/intel/axm5616-victoria.dts
index 89fa952..e033c64 100644
--- a/arch/arm64/boot/dts/intel/axm5616-victoria.dts
+++ b/arch/arm64/boot/dts/intel/axm5616-victoria.dts
@@ -213,3 +213,11 @@
  {
status = "okay";
 };
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
diff --git a/arch/arm64/boot/dts/intel/axm56xx.dtsi 
b/arch/arm64/boot/dts/intel/axm56xx.dtsi
index 7c531ab..8444acf 100644
--- a/arch/arm64/boot/dts/intel/axm56xx.dtsi
+++ b/arch/arm64/boot/dts/intel/axm56xx.dtsi
@@ -40,6 +40,8 @@
gpdma1= 
sm0   = 
sm1   = 
+   cm0   = 
+   cm1   = 
};
 
clocks {
@@ -135,6 +137,22 @@
status = "disabled";
};
 
+   cm0: cm0@00080009 {
+   compatible = "intel,cmmon";
+   reg = <0 0x00080009 0 0x1000>;
+   syscon = <>;
+   interrupts = <0 233 4>;
+   status = "disabled";
+   };
+
+   cm1: cm1@00090009 {
+   compatible = "intel,cmmon";
+   reg = <0 0x00090009 0 0x1000>;
+   syscon = <>;
+   interrupts = <0 234 4>;
+   status = "disabled";
+   };
+
usb0: usb@90 {
compatible = "intel,axxia-dwc3";
dma-coherent;
diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index 6863d2a..1a8d45e 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -404,6 +404,15 @@ config EDAC_AXXIA_SYSMEM_5500
  the System Memory error detection. System Memory error
  detection is interrupt driven.
 
+config EDAC_AXXIA_CMEM_5600
+   depends on ARCH_AXXIA
+   bool "AXXIA EDAC CMem Controller for 5600"
+   help
+ Support for Configuration Memory Denali controller error
+ detection on the AXXIA AXM56xx devices. This enables
+ the Configuration Memory error detection. Configuration Memory error
+ detection is interrupt driven.
+
 config EDAC_AXXIA_L3
tristate "AXXIA EDAC L3 Controller"
help
diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
index 65dfcf8..af3cd99 100644
--- a/drivers/edac/Makefile
+++ b/drivers/edac/Makefile
@@ -18,6 +18,7 @@ endif
 
 obj-$(CONFIG_EDAC_AXXIA_SYSMEM_5500)   += axxia_edac-mc.o
 obj-$(CONFIG_EDAC_AXXIA_SYSMEM_5600)   += axxia_edac-mc_56xx.o
+obj-$(CONFIG_EDAC_AXXIA_CMEM_5600) += axxia_edac-cmc_56xx.o
 obj-$(CONFIG_EDAC_AXXIA_L3)+= axxia_edac-l3.o
 obj-$(CONFIG_EDAC_AXXIA_L2_CPU)+= axxia_edac-l2_cpu.o
 obj-$(CONFIG_EDAC_GHES)+= ghes_edac.o
diff --git a/drivers/edac/axxia_edac-cmc_56xx.c 
b/drivers/edac/axxia_edac-cmc_56xx.c
new file mode 100644
index 000..f99c46d
--- /dev/null
+++ b/drivers/edac/axxia_edac-cmc_56xx.c
@@ -0,0 +1,1223 @@
+/*
+ * drivers/edac/axxia_edac-mc.c
+ *
+ * EDAC Driver for Intel's Axxia 5600 Configuration Memory Controller
+ *
+ * Copyright (C) 2016 Intel Inc.
+ *
+ * This file may be distributed under the terms of the
+ * GNU General Public License.
+ */
+
+#include 

[linux-yocto] [PATCH 3/9] edac: Added fixes for smem edac driver

[Daniel Dragomir]

From: Marek Majtyka 

 - Improved naming and code maintainability (defines).
 - Fixed faulty error handling scenario (stopping workqueue).

Signed-off-by: Marek Majtyka 
---
 drivers/edac/axxia_edac-mc_56xx.c | 53 +--
 1 file changed, 28 insertions(+), 25 deletions(-)

diff --git a/drivers/edac/axxia_edac-mc_56xx.c 
b/drivers/edac/axxia_edac-mc_56xx.c
index 54dac0e..f850ebe 100644
--- a/drivers/edac/axxia_edac-mc_56xx.c
+++ b/drivers/edac/axxia_edac-mc_56xx.c
@@ -45,8 +45,8 @@
 
 #define INTEL_EDAC_MOD_STR "axxia56xx_edac"
 
-#define APB2_SER3_PHY_ADDR 0x008002c0ULL
-#define APB2_SER3_PHY_SIZE 110008
+#define AXI2_SER3_PHY_ADDR 0x008002c0ULL
+#define AXI2_SER3_PHY_SIZE PAGE_SIZE
 
 #define SM_MPR_PAGE0x1
 
@@ -74,8 +74,7 @@
 #define SM_56XX_DENALI_CTL_61 0xf4
 #define SM_56XX_DENALI_CTL_62 0xf8
 
-/* TODO CHECK */
-#define APB2_PERSIST_SCRATCH0xdc
+#define SYSCON_PERSIST_SCRATCH  0xdc
 #define SMEM_PERSIST_SCRATCH_BIT (0x1 << 3)
 
 #define IRQ_NAME_LEN 16
@@ -90,6 +89,7 @@
 #define SM_INT_MASK_ALL_LOW (0x)
 #define SM_INT_MASK_HIGH (0x1)
 #define SM_INT_MASK_ALL_HIGH (0x7)
+#define ALIVE_NOTIFICATION_PERIOD (90*1000)
 
 static int log = 1;
 module_param(log, int, S_IRUGO|S_IWUSR);
@@ -603,7 +603,6 @@ struct mc_edac_data {
atomic_t dump_ready;
atomic_t event_ready;
atomic_t dump_in_progress;
-
 };
 
 struct intel_edac_dev_info {
@@ -617,7 +616,7 @@ struct intel_edac_dev_info {
int edac_idx;
u32 sm_region;
struct regmap *syscon;
-   void __iomem *apb2ser3_region;
+   void __iomem *axi2ser3_region;
struct edac_device_ctl_info *edac_dev;
void (*check)(struct edac_device_ctl_info *edac_dev);
 };
@@ -753,17 +752,17 @@ handle_events(struct intel_edac_dev_info *edac_dev,
if (force_restart && event_logging[i].fatal) {
if (IS_ERR(edac_dev->syscon)) {
set_val = readl(
-   edac_dev->apb2ser3_region
-   + APB2_PERSIST_SCRATCH);
+   edac_dev->axi2ser3_region
+   + SYSCON_PERSIST_SCRATCH);
/* set bit 3 in pscratch reg */
set_val = set_val
| SMEM_PERSIST_SCRATCH_BIT;
writel(set_val,
-   edac_dev->apb2ser3_region +
-   APB2_PERSIST_SCRATCH);
+   edac_dev->axi2ser3_region +
+   SYSCON_PERSIST_SCRATCH);
} else {
regmap_update_bits(edac_dev->syscon,
-   APB2_PERSIST_SCRATCH,
+   SYSCON_PERSIST_SCRATCH,
SMEM_PERSIST_SCRATCH_BIT,
SMEM_PERSIST_SCRATCH_BIT);
}
@@ -993,7 +992,7 @@ start:
/* keep hung up monitor happy 90 sec's */
if (0 == wait_event_timeout(dev_info->data->dump_wq,
atomic_read(_info->data->dump_in_progress),
-   msecs_to_jiffies(90*1000)))
+   msecs_to_jiffies(ALIVE_NOTIFICATION_PERIOD)))
goto start;
 
/* the only one running workqueue */
@@ -1006,7 +1005,7 @@ start:
goto error_read;
 
/* bits [3:2] cs number */
-   denali_ctl_57.read_mpr = 4*i + 1;
+   denali_ctl_57.read_mpr = 4*i + SM_MPR_PAGE;
if (ncr_write(dev_info->sm_region,
SM_56XX_DENALI_CTL_57,
4, (u32 *) _ctl_57))
@@ -1024,7 +1023,7 @@ start:
 
atomic_set(_info->data->dump_ready, 0);
/* collect data */
-   collect_mpr_dump(dev_info, 1, i);
+   collect_mpr_dump(dev_info, SM_MPR_PAGE, i);
}
 
/* process all dumps - update counters */
@@ -1068,7 +1067,7 @@ static void intel_sm_events_error_check(struct 
edac_device_ctl_info *edac_dev)
while (1) {
if (0 == wait_event_timeout(dev_info->data->event_wq,
atomic_read(_info->data->event_ready),
-   msecs_to_jiffies(90*1000)))
+   msecs_to_jiffies(ALIVE_NOTIFICATION_PERIOD)))
continue;
 
atomic_set(_info->data->event_ready, 0);
@@ -1185,7 +1184,6 @@ static int intel_edac_mc_probe(struct platform_device 
*pdev)
   

[linux-yocto] [PATCH 1/9] edac: Added sm edac driver for AXM56XX family

[Daniel Dragomir]

From: John Jacques 

  - Added arm64 edac support.
  - Adjusted AXM55xx edac driver for AXM56xx with
registers, regions, configs, naming, kbuild.
  - Separated source code for AXM56xx and AXM55xx.
  - Added MPR registers dump (page1) functionality.
  - Fixes (error handling, synchronization, etc).
  - Improved module error handling and naming.

Signed-off-by: Marek Majtyka 
Signed-off-by: John Jacques 
---
 .../devicetree/bindings/arm/axxia/edac.txt |   14 +
 arch/arm64/Kconfig |1 +
 arch/arm64/boot/dts/intel/axm5616-victoria.dts |8 +
 arch/arm64/boot/dts/intel/axm56xx.dtsi |   18 +
 arch/arm64/include/asm/edac.h  |   13 +
 drivers/edac/Kconfig   |   14 +-
 drivers/edac/Makefile  |3 +-
 drivers/edac/axxia_edac-mc.c   |   19 +-
 drivers/edac/axxia_edac-mc_56xx.c  | 1479 
 9 files changed, 1551 insertions(+), 18 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/axxia/edac.txt
 create mode 100644 arch/arm64/include/asm/edac.h
 create mode 100644 drivers/edac/axxia_edac-mc_56xx.c

diff --git a/Documentation/devicetree/bindings/arm/axxia/edac.txt 
b/Documentation/devicetree/bindings/arm/axxia/edac.txt
new file mode 100644
index 000..65078eb
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/axxia/edac.txt
@@ -0,0 +1,14 @@
+Axxia Error Detection & Correction [EDAC]
+The EDAC accesses a range of registers in the memory controllers.
+
+Required properties:
+- compatible : should contain "intel,smmon"
+- interrupts : Should contain the SYSMEM controller IRQ
+
+Example:
+   sm0: sm0@0022 {
+compatible = "intel,smmon";
+ reg = <0 0x0022 0 0x1000>;
+ syscon = <>;
+ interrupts = <0 238 4>;
+   };
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 03d63b3..a386e46 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -24,6 +24,7 @@ config ARM64
select COMMON_CLK
select CPU_PM if (SUSPEND || CPU_IDLE)
select DCACHE_WORD_ACCESS
+select EDAC_SUPPORT
select GENERIC_ALLOCATOR
select GENERIC_CLOCKEVENTS
select GENERIC_CLOCKEVENTS_BROADCAST if SMP
diff --git a/arch/arm64/boot/dts/intel/axm5616-victoria.dts 
b/arch/arm64/boot/dts/intel/axm5616-victoria.dts
index 9c787b4..89fa952 100644
--- a/arch/arm64/boot/dts/intel/axm5616-victoria.dts
+++ b/arch/arm64/boot/dts/intel/axm5616-victoria.dts
@@ -205,3 +205,11 @@
  {
status = "okay";
 };
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
diff --git a/arch/arm64/boot/dts/intel/axm56xx.dtsi 
b/arch/arm64/boot/dts/intel/axm56xx.dtsi
index 4ce9e92..7c531ab 100644
--- a/arch/arm64/boot/dts/intel/axm56xx.dtsi
+++ b/arch/arm64/boot/dts/intel/axm56xx.dtsi
@@ -38,6 +38,8 @@
i2c3  = 
gpdma0= 
gpdma1= 
+   sm0   = 
+   sm1   = 
};
 
clocks {
@@ -94,6 +96,22 @@
reg = <0x80 0x02c0 0 0x4>;
};
 
+   sm0: sm0@0022 {
+   compatible = "intel,smmon";
+   reg = <0 0x0022 0 0x1000>;
+   syscon = <>;
+   interrupts = <0 238 4>;
+   status = "disabled";
+   };
+
+   sm1: sm1@000f {
+   compatible = "intel,smmon";
+   reg = <0 0x000f 0 0x1000>;
+   syscon = <>;
+   interrupts = <0 239 4>;
+   status = "disabled";
+   };
+
reset: reset@8002C02008 {
compatible = "intel,axm56xx-reset";
syscon = <>;
diff --git a/arch/arm64/include/asm/edac.h b/arch/arm64/include/asm/edac.h
new file mode 100644
index 000..8218fa8
--- /dev/null
+++ b/arch/arm64/include/asm/edac.h
@@ -0,0 +1,13 @@
+#ifndef ASM_EDAC_H
+#define ASM_EDAC_H
+/*
+ * ECC atomic, DMA, SMP and interrupt safe scrub function.
+ * Implements the per arch atomic_scrub() that EDAC use for software
+ * ECC scrubbing.  It reads memory and then writes back the original
+ * value, allowing the hardware to detect and correct memory errors.
+ */
+static inline void atomic_scrub(void *va, u32 size)
+{
+   WARN_ONCE(1, "not implemented");
+}
+#endif
diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index 235bd4d..6863d2a 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -386,8 +386,18 @@ config EDAC_OCTEON_PCI
  Support for error detection and correction on the
  Cavium Octeon family of SOCs.
 
-config EDAC_AXXIA_SYSMEM
-   tristate "AXXIA EDAC SysMem Controller"
+config 

[linux-yocto] [PATCH 0/9] Intel Axxia updates to linux-yocto-4.1

[Daniel Dragomir]

Hello Bruce!

This series of patches brings various improvements to the Intel Axxia
drivers from linux-yocto-4.1, including EDAC, VMFS, HWRNG, MISC and PCI
drivers and some updates in device trees for Intel Axxia boards.

If all the patches are ok, please pull them from
https://github.com/axxia/axxia_yocto_linux_4.1_pull.git
into
git://git.yoctoproject.org/linux-yocto-4.1
Pull
standard/axxia/base-1.51 -> standard/axxia/base
standard/preempt-rt/axxia/base-1.51 -> standard/preempt-rt/axxia/base

If you add more patches to standard/(preempt-rt)/axxia/base beforehand
please notify me. I will rebase our changes so you can do a clean,
fast-forward pull.

Thank you,
Daniel Dragomir


John Jacques (5):
  edac: Added sm edac driver for AXM56XX family
  axxia: Device Tree Updates for 5600 GPIO
  axxia: Device Tree Updates for 6700 GPIO
  axxia: Update the VMFS Driver
  drivers/pci: Support the Updated Axxia PCIe/sRIO Coefficients

Marek Bykowski (2):
  char: hwrng: don't use static pointer to driver data as it goes to
.bss
  arch/arm/mach-axxia: adding atomicity to per_cpu data manipulation

Marek Majtyka (2):
  edac: Added cm edac driver for AXM56XX family
  edac: Added fixes for smem edac driver

 .../devicetree/bindings/arm/axxia/edac.txt |   14 +
 .../devicetree/bindings/arm/axxia/edac_cm.txt  |   21 +
 arch/arm/mach-axxia/axxia-gic.c|   32 +-
 arch/arm64/Kconfig |1 +
 arch/arm64/boot/dts/intel/axc67xx.dtsi |   16 +-
 arch/arm64/boot/dts/intel/axm5616-victoria.dts |   16 +
 arch/arm64/boot/dts/intel/axm56xx.dtsi |   45 +-
 arch/arm64/include/asm/edac.h  |   13 +
 drivers/char/hw_random/axxia-rng.c |8 +-
 drivers/edac/Kconfig   |   23 +-
 drivers/edac/Makefile  |4 +-
 drivers/edac/axxia_edac-cmc_56xx.c | 1223 
 drivers/edac/axxia_edac-mc.c   |   19 +-
 drivers/edac/axxia_edac-mc_56xx.c  | 1482 
 drivers/misc/axxia-oem.c   |   14 +-
 drivers/misc/axxia-pei.c   |  287 +++-
 drivers/pci/host/pcie-axxia.c  |5 +-
 fs/vmfs/inode.c|2 +-
 include/linux/axxia-pei.h  |2 +-
 19 files changed, 3167 insertions(+), 60 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/axxia/edac.txt
 create mode 100644 Documentation/devicetree/bindings/arm/axxia/edac_cm.txt
 create mode 100644 arch/arm64/include/asm/edac.h
 create mode 100644 drivers/edac/axxia_edac-cmc_56xx.c
 create mode 100644 drivers/edac/axxia_edac-mc_56xx.c

-- 
2.7.4

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

Re: [yocto] [meta-qt4][PATCH] qt4: don't override dbg package content

[Burton, Ross]

On 9 March 2017 at 15:53, Pascal Bach  wrote:

> The default from bitbake.conf is `FILES_${PN}-dbg = "/usr/lib/debug
> /usr/src/debug"`
> which is perfectly fine as a basis for Qt4.
>

Note that oe-core master (and morty, and maybe krogoth) doesn't need
FILES_PN-dbg to be set at all.

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

[yocto] [meta-qt4][PATCH] qt4: don't override dbg package content

[Pascal Bach]

The default from bitbake.conf is `FILES_${PN}-dbg = "/usr/lib/debug 
/usr/src/debug"`
which is perfectly fine as a basis for Qt4.
This also makes the recipe work with different debug split schemes.

Signed-off-by: Pascal Bach 
---
 recipes-qt4/qt4/qt4.inc | 1 -
 1 file changed, 1 deletion(-)

diff --git a/recipes-qt4/qt4/qt4.inc b/recipes-qt4/qt4/qt4.inc
index 2058e54..8f244ce 100644
--- a/recipes-qt4/qt4/qt4.inc
+++ b/recipes-qt4/qt4/qt4.inc
@@ -130,7 +130,6 @@ PACKAGES_DYNAMIC += "^${QT_BASE_NAME}-plugin-.* 
^${QT_BASE_NAME}-translation-.*
 ALLOW_EMPTY_${PN} = "1"
 FILES_${PN} = ""
 FILES_${PN}-dev = "${includedir}/${QT_DIR_NAME}/Qt/*"
-FILES_${PN}-dbg = "/usr/src/debug/"
 FILES_${QT_BASE_NAME}-demos-doc = "${docdir}/${QT_DIR_NAME}/qch/qt.qch"
 RRECOMMENDS_${PN} = "${LIB_PACKAGES} ${OTHER_PACKAGES}"
 RRECOMMENDS_${PN}-dev = "${DEV_PACKAGES}"
-- 
2.1.4

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

Re: [yocto] [meta-mingw][PATCH v2 0/19] Adding support for building QEMU for Windows

[Nathan Rossi]

On 30 January 2017 at 18:44, Nathan Rossi  wrote:
> This series enables a number of packages and dependencies to be built
> for mingw32. The goal is to enable the building and packaging of QEMU
> targeting mingw32 with support for SDL/VNC enabled as well as being able
> to execute the qemu* machines of oe-core/meta.
>
> The following series fixes a number of issues with compilation of
> certain components that are required to build and distribute QEMU. This
> series includes:
>
>  * Enabling 'secure-api' for mingw-w64-headers
>  * Fix/enable building of shared libraries for gettext
>  * Work around to avoid dependency on bash for glib-2.0, clean up of
>some glib-2.0 appends which are resolved in oe-core meta
>  * Better packaging of libgcc for easy use on Windows (deploy dll to
>bindir)
>  * Updating FILES_* to support locations for mingw32 output (bindir
>contains .dll) for libgcc, expat, libpcre, gettext, glib-2.0, libsdl,
>libgpg-error and libgcrypt
>  * Addition of PACKAGECONFIG options to libsdl, and configuring of
>PACKAGECONFIG for libsdl, glib-2.0 and libgcrypt to handle Windows
>only features and or ability to disable features that do not support
>mingw32/Windows
>  * Enabling build of libfdt in the dtc recipe, but skipping dtc itself
>  * Fixes for configuring libgpg-error and libgcrypt when targeting
>mingw32
>
> The intended build execution is to allow for 'buildtools-tarball' (or
> any populate_sdk target with 'nativesdk-qemu' in TOOLCHAIN_HOST_TASK) to
> create an output that includes all dependent nativesdk binaries as well
> as a nativesdk QEMU binaries. This series does not however address
> fixing the environment setup script or self-extracting installer shell
> script that is normally provided by buildtools-tarball.
>
> This series with the multiple oe-core/meta series was tested on the
> following target Windows platforms: Windows 10 (64-bit), Windows 8.1
> (64-bit) and Windows 7 SP1 (64-bit).
>
> The changes were also tested on the following Linux build hosts: Debian
> 8 (64-bit), Ubuntu 16.04 (64-bit), CentOS 7 (64-bit).
>
> For convenience this series is also available in the git repository:
>
>   https://github.com/nathanrossi/meta-mingw nrossi/mingw-qemu-v2
>
> This series partly depends on a set of series for oe-core/meta. The
> following series are required for building of QEMU (but not all parts of
> this series specifically), including dll packaging detection and
> libgcrypt support:
>
>   https://patchwork.openembedded.org/series/5049/
>   https://patchwork.openembedded.org/series/5050/
>   https://patchwork.openembedded.org/series/5051/
>   https://patchwork.openembedded.org/series/5052/
>   https://patchwork.openembedded.org/series/5053/

These patch series have been merged into oe-core. However the
gettext-libintl packaging patch was moved to a change in meta-mingw
layer as of v3 (see below).

I have updated and pushed a v3 branch of this meta-mingw series to the
meta-mingw-contrib repo here:

http://git.yoctoproject.org/cgit/cgit.cgi/meta-mingw-contrib/log/?h=nrossi/mingw-qemu-v3

Changes v3:
 * Updated changes to layer on current master of oe/meta
 * Squished the gettext libintl packaging and dll packaging patches
 * Moved the adding of the libintl packaging to meta-mingw

To avoid patch spam, I have skipped sending the v3 patches
individually to the list. Please let me know if patch emails are
desired.

Thanks,
Nathan
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [patchwork][PATCH] series.py: return bundle objects only when authenticated

[Jose Lamego]

If a non-authenticated user tries to get a series view from
patchwork web UI, a 500 error message is displayed caused by
the database access attempted when filtering the bundle objects.

This change allows not-logged users to acces series view by
returning an empty bundle variable, instead of trying to
access the database.

Signed-off-by: Jose Lamego 
---
 patchwork/views/series.py | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/patchwork/views/series.py b/patchwork/views/series.py
index cb3b721..765d2e5 100644
--- a/patchwork/views/series.py
+++ b/patchwork/views/series.py
@@ -48,7 +48,10 @@ class SeriesView(View):
 revisions = get_list_or_404(SeriesRevision, series=series)
 patchform = PatchForm(project=series.project)
 createbundleform = CreateBundleForm()
-bundles = Bundle.objects.filter(owner=request.user)
+if request.user.is_authenticated():
+bundles = Bundle.objects.filter(owner=request.user)
+else:
+bundles=""
 for revision in revisions:
 revision.patch_list = revision.ordered_patches().\
 select_related('state', 'submitter')
-- 
2.7.4

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

[linux-yocto] [PULL REQUEST] Intel Axxia updates to linux-yocto-4.9

[Daniel Dragomir]

Hello Bruce!

This is the first pull request for Axxia changes on kernel 4.9 which were
ported from our 4.1 Yocto branches.
I checked all the patches with checkpatch.pl script and fixed all errors.
Also, I compiled Axxia BSP using both branches and successfully booted the 
board.

Please pull the patches from
https://github.com/axxia/axxia_yocto_linux_4.9_pull.git
into
git://git.yoctoproject.org/linux-yocto-4.9

Pull
standard/axxia/base-1.3 -> standard/axxia/base
standard/preempt-rt/axxia/base-1.3 -> standard/preempt-rt/axxia/base

If you add more patches to standard/(preempt-rt)/axxia/base beforehand
please notify me. I will rebase our changes so you can do a clean,
fast-forward pull.

Thank you,
Daniel Dragomir


Anders Berg (14):
  arm64: dts: Add initial AXM56xx device tree
  arm64: Add Axxia NEMAC Gigabit Ethernet controller
  arm64: dts: Corrected SPI definitions for AXM56xx
  arm64: dts: Added SPI and flash for AXM56xx sim
  arm64: dts: Add VMFS node for simulation DT
  net: ethernet: Enable Axxia FEMAC driver
  arm64: dts: Add device tree for AXC67xx (Lionfish)
  arm64: dts: Fixed bad VMFS reg property
  net: ethernet: Add MDIO driver for LSI AXM55xx
  net: ethernet: Add driver for FEMAC on AXM55xx
  drivers: net: Add Axxia NEMAC driver
  arm64: dts: Add NEMAC device nodes
  net: nemac: Fix crash when using NEMAC from bootloader
  misc: lsi-ncr: Only use AMP lock on PPC platforms.

Charlie Paul (42):
  i2c: Support for i2c to the LSI axxia 5500 board
  fs/vmfs: Added VMFS support to Axxia BSP
  drivers/dma: Updated to support Axxia dma
  arch/arm/boot/dts: Files added to support axxia 5500 board
  arch/arm/boot: Changes to support the axxia BSP
  arch/arm/mach-axxia: kernel files to support the mach-axxia
  arch/arm: arm changes to support the axxia BSP
  misc: Changes made to support axxia BSP
  drivers/mtd: Changes to support the axxia BSP
  drivers/net/ethernet: Changes to support the axxia BSP
  drivers/rapidio/devices: Changes to support axxia BSP
  drivers/spi: Changes to support the axxia BSP
  drivers/hwmon: Changes made to support the axxia BSP
  drivers/tty: Changes to support the axxia BSP
  drivers/usb/host: Changes to support the axxia BSP
  fs/vmfs: Changes to add VMFS support for axxia.
  arch/arm/mach-axxia: Removed axxia_circular_queue
  arch/arm/mach-axxia: fixed compiler warning
  arch/arm/mach-axxia: fixed NO SMP
  arch/arm/mach-axxia: changed affinity parameter to cpu
  arch/arm/mach-axxia: Reverse checkpatch compatibility
  arch/arm/mach-axxia: Fixed L2 power up failure
  hwmon: Remove adt75 redundant driver
  arch/arm/axxia: Remove the axxia zImage.fm build
  fs/vmfs: Altered to allow vmfs to compile
  drivers/ethernet/lsi: Fixed code to support 4.1
  arm/mach-axxia: Updated to support linux 4.1
  drivers/misc: Updated to support linux 4.1
  fs/vmfs: Updated code to support linux 4.1
  arm64: mm: Removed calls to reset_pmuserenr_el0
  fs/vmfs: Updated to support the axxia on Linux 4.9
  drivers/rapidio: Update to support linux 4.9
  drivers/pci: updated to support axxia for 4.9
  drivers/net: Updated to support axxia on 4.9
  driver/net/ethernet: Updated to support axxia on 4.9
  drivers/misc: Updated to support axxia on 4.9
  drivers/i2c/busses: Updated to support axxia on 4.9
  arch/arm/mach-axxia: Updated to support 4.9 on the 5500
  i2c/busses: Updated to support 4.9 on the 5500
  drivers/net: Updated to support 4.9 on the 5500
  boot/dts/axxia: Updated to support 4.9 on the 5500
  arm/mach-axxia: allow interupts (16-32) set to LOW

David Mercado (1):
  kernel/irq/manage.c: Fix irq_set_affinity to allow use with buslocks

Fredrik Markstrom (1):
  usb ehci-ci13612: Enable HCD_BH mode in ci13612

Gary McGee (5):
  mach-axxia: Make AXXIA_NCR_RESET_CHECK a Kconfig Option
  power: reset: preliminary support for Axxia DDR Retention reset
  arch/arm/mach-axxia: Flush TLB
  axxia-reset.c: Use syscon address from device tree
  axxia: enable trng for axc6732-waco and axm5616-victoria

Geoff Levand (1):
  arm64: Enable the identity mapping to allow the MMU disabling

John Jacques (98):
  arch/arm64: Correct GIC Physical Address in Axxia
  arch/arm64: Correct GIC Physical Address in Axxia XLF
  axxia: Add dts for Emulation
  mrch/arm64/mach-axxia: Device Tree Updates for Emulation
  axxia: Updated Device Trees for Emulation and Simulation
  arch/arm64: Use SYSROOT If Defined
  arch/arm64: Add Device Tree for Axxia Emulation
  arch/arm64: Axxia Device Tree and Configuration Changes
  arch/arm64: Axxia Device Tree Update
  arch/arm64: Axxia Interrupt Number Updates
  arch/arm64: Update the Axxia Device Tree for Emulation
  arch/arm64: Correct physical addresses for Simulation dts
  arch/arm64: Axxia Device Tree Updates for the XLF Platform
  arch/arm64: Axxia Device Tree Update
  arch/arm64: Correct the addresses and interrupt numbers for AXC6700
  irqchip: Ignore bit 17 of GICD TYPER register in simulation
  arch/arm64: Correct interrupts number for simulation dts
  arch/arm64: 

Re: [yocto] Source Code provision without full git repository history

[Khem Raj]

On Thu, Mar 9, 2017 at 5:02 AM Waldvogel, Sebastian <
sebastian.waldvo...@vector.com> wrote:

> Hello,
>
>
>
> I am searching for a way in Yocto/BitBake to extract the source codes of
> the software applications developed by my company for delivery to our
> customers.
>
> The source codes shall be delivered as archive containing only the source
> files without the whole git repository history.
>
>
>
> Setup is that we have own Yocto layers/recipes referencing the company
> internal git repository (SRC_URI=”git://git.company.url”) and the concrete
> SRCREV to be used. Basic idea was to use the option
> BB_GENERATE_MIRROR_TARBALLS = "1" which generates an archive file with the
> application source code. Unfortunately the generated tarball contains the
> full bare cloned git repository with full history and not only the source
> files of the concrete SRCREV.
>
>
>
> As alternative I tried to use the archiver class
> .
> The generated tarballs contains the concrete source files but in addition
> the full git repository with history is contained too.
>

I am not sure if it is intended to keep SCM history though you might want
to file a bug

>
>
> Does anyone has an idea how to extract the concrete source files without
> git repository and history?
>
>
>
> Thank you very much for your help
>
> Sebastian Waldvogel
>
>
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Source Code provision without full git repository history

[Waldvogel, Sebastian]

Hello,

I am searching for a way in Yocto/BitBake to extract the source codes of the 
software applications developed by my company for delivery to our customers.
The source codes shall be delivered as archive containing only the source files 
without the whole git repository history.

Setup is that we have own Yocto layers/recipes referencing the company internal 
git repository (SRC_URI="git://git.company.url") and the concrete SRCREV to be 
used. Basic idea was to use the option BB_GENERATE_MIRROR_TARBALLS = "1" which 
generates an archive file with the application source code. Unfortunately the 
generated tarball contains the full bare cloned git repository with full 
history and not only the source files of the concrete SRCREV.

As alternative I tried to use the archiver 
class.
 The generated tarballs contains the concrete source files but in addition the 
full git repository with history is contained too.

Does anyone has an idea how to extract the concrete source files without git 
repository and history?

Thank you very much for your help
Sebastian Waldvogel


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

Re: [yocto] hddimg 4GB limit?

[Burton, Ross]

On 9 March 2017 at 07:04, Takashi Matsuzawa  wrote:

> I found hddimg 4GB-1 bye restriction because it creates a file called
> rootfs.img which is copied into FAT.
>
> That means rootfs.img size must be below FAT max file size...
>
>
Yes.  This is why I'd like to see hddimg removed and replaced with a
partition layout in wic that doesn't use a FAT container.

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

[yocto] [PATCH][meta-gplv2] bison: add missing patch from oe-core

[Martin Jansa]

* meta-gplv2/recipes-devtools/bison/bison_2.3.bb: Unable to get checksum for 
bison SRC_URI entry bison-2.3_m4.patch: file
 could not be found

Signed-off-by: Martin Jansa 
---
 recipes-devtools/bison/bison/bison-2.3_m4.patch | 591 
 1 file changed, 591 insertions(+)
 create mode 100644 recipes-devtools/bison/bison/bison-2.3_m4.patch

diff --git a/recipes-devtools/bison/bison/bison-2.3_m4.patch 
b/recipes-devtools/bison/bison/bison-2.3_m4.patch
new file mode 100644
index 000..348ce1d
--- /dev/null
+++ b/recipes-devtools/bison/bison/bison-2.3_m4.patch
@@ -0,0 +1,591 @@
+Upstream-Status: Pending
+
+#
+# Patch managed by http://www.mn-logistik.de/unsupported/pxa250/patcher
+#
+
+--- /dev/null
 bison-1.875/m4/inttypes-pri.m4
+@@ -0,0 +1,32 @@
++# inttypes-pri.m4 serial 1 (gettext-0.11.4)
++dnl Copyright (C) 1997-2002 Free Software Foundation, Inc.
++dnl This file is free software, distributed under the terms of the GNU
++dnl General Public License.  As a special exception to the GNU General
++dnl Public License, this file may be distributed as part of a program
++dnl that contains a configuration script generated by Autoconf, under
++dnl the same distribution terms as the rest of that program.
++
++dnl From Bruno Haible.
++
++# Define PRI_MACROS_BROKEN if  exists and defines the PRI*
++# macros to non-string values.  This is the case on AIX 4.3.3.
++
++AC_DEFUN([gt_INTTYPES_PRI],
++[
++  AC_REQUIRE([gt_HEADER_INTTYPES_H])
++  if test $gt_cv_header_inttypes_h = yes; then
++AC_CACHE_CHECK([whether the inttypes.h PRIxNN macros are broken],
++  gt_cv_inttypes_pri_broken,
++  [
++AC_TRY_COMPILE([#include 
++#ifdef PRId32
++char *p = PRId32;
++#endif
++], [], gt_cv_inttypes_pri_broken=no, gt_cv_inttypes_pri_broken=yes)
++  ])
++  fi
++  if test "$gt_cv_inttypes_pri_broken" = yes; then
++AC_DEFINE_UNQUOTED(PRI_MACROS_BROKEN, 1,
++  [Define if  exists and defines unusable PRI* macros.])
++  fi
++])
+--- /dev/null
 bison-1.875/m4/lcmessage.m4
+@@ -0,0 +1,32 @@
++# lcmessage.m4 serial 3 (gettext-0.11.3)
++dnl Copyright (C) 1995-2002 Free Software Foundation, Inc.
++dnl This file is free software, distributed under the terms of the GNU
++dnl General Public License.  As a special exception to the GNU General
++dnl Public License, this file may be distributed as part of a program
++dnl that contains a configuration script generated by Autoconf, under
++dnl the same distribution terms as the rest of that program.
++dnl
++dnl This file can can be used in projects which are not available under
++dnl the GNU General Public License or the GNU Library General Public
++dnl License but which still want to provide support for the GNU gettext
++dnl functionality.
++dnl Please note that the actual code of the GNU gettext library is covered
++dnl by the GNU Library General Public License, and the rest of the GNU
++dnl gettext package package is covered by the GNU General Public License.
++dnl They are *not* in the public domain.
++
++dnl Authors:
++dnl   Ulrich Drepper , 1995.
++
++# Check whether LC_MESSAGES is available in .
++
++AC_DEFUN([AM_LC_MESSAGES],
++[
++  AC_CACHE_CHECK([for LC_MESSAGES], am_cv_val_LC_MESSAGES,
++[AC_TRY_LINK([#include ], [return LC_MESSAGES],
++   am_cv_val_LC_MESSAGES=yes, am_cv_val_LC_MESSAGES=no)])
++  if test $am_cv_val_LC_MESSAGES = yes; then
++AC_DEFINE(HAVE_LC_MESSAGES, 1,
++  [Define if your  file defines LC_MESSAGES.])
++  fi
++])
+--- /dev/null
 bison-1.875/m4/uintmax_t.m4
+@@ -0,0 +1,29 @@
++# uintmax_t.m4 serial 6 (gettext-0.11)
++dnl Copyright (C) 1997-2002 Free Software Foundation, Inc.
++dnl This file is free software, distributed under the terms of the GNU
++dnl General Public License.  As a special exception to the GNU General
++dnl Public License, this file may be distributed as part of a program
++dnl that contains a configuration script generated by Autoconf, under
++dnl the same distribution terms as the rest of that program.
++
++dnl From Paul Eggert.
++
++AC_PREREQ(2.13)
++
++# Define uintmax_t to `unsigned long' or `unsigned long long'
++# if  does not exist.
++
++AC_DEFUN([jm_AC_TYPE_UINTMAX_T],
++[
++  AC_REQUIRE([jm_AC_HEADER_INTTYPES_H])
++  AC_REQUIRE([jm_AC_HEADER_STDINT_H])
++  if test $jm_ac_cv_header_inttypes_h = no && test $jm_ac_cv_header_stdint_h 
= no; then
++AC_REQUIRE([jm_AC_TYPE_UNSIGNED_LONG_LONG])
++test $ac_cv_type_unsigned_long_long = yes \
++  && ac_type='unsigned long long' \
++  || ac_type='unsigned long'
++AC_DEFINE_UNQUOTED(uintmax_t, $ac_type,
++  [Define to unsigned long or unsigned long long
++   if  and  don't define.])
++  fi
++])
+--- /dev/null
 bison-1.875/m4/glibc21.m4
+@@ -0,0 +1,32 @@
++# glibc21.m4 serial 2 (fileutils-4.1.3, gettext-0.10.40)
++dnl Copyright (C) 2000-2002 Free Software Foundation, Inc.
++dnl This file is free software, distributed under the terms of the GNU

Re: [yocto] cannot build image using sstate

[Patrick Ohly]

On Thu, 2017-03-09 at 09:59 +0200, Mircea Gliga wrote:
> Thanks! You are right, the do_deploy_append installs the
> image_signed.fit in the ${DEPLOY_DIR_IMAGE}(I should have kept that
> line in the previous mail also):
> do_deploy_append() {
> [...]
>  #this line creates the image_signed.fit file
>   mkimage  [...] image_signed.fit
>   install -m 0644  image_signed.fit ${DEPLOY_DIR_IMAGE}/.
> [...]
> }
> 
> The doc mentions in regards to DEPLOYDIR:
> "Recipes inheriting the deploy class should copy files to be deployed
> into DEPLOYDIR, and the class will take care of copying them into
> DEPLOY_DIR_IMAGE afterwards."
> 
> So I should just replace ${DEPLOY_DIR_IMAGE} with ${DEPLOYDIR} and I
> get the same behaviour as before + the benefit of sstate cache ?

Yes.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.



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

Re: [yocto] cannot build image using sstate

[Mircea Gliga]

Thanks! You are right, the do_deploy_append installs the 
image_signed.fit in the ${DEPLOY_DIR_IMAGE}(I should have kept that line 
in the previous mail also):

do_deploy_append() {
[...]
 #this line creates the image_signed.fit file
  mkimage  [...] image_signed.fit
  install -m 0644  image_signed.fit ${DEPLOY_DIR_IMAGE}/.
[...]
}

The doc mentions in regards to DEPLOYDIR:
"Recipes inheriting the |deploy| class should copy files to be deployed 
into |DEPLOYDIR|, and the class will take care of copying them into 
|DEPLOY_DIR_IMAGE| 
 
afterwards."


So I should just replace ${DEPLOY_DIR_IMAGE} with ${DEPLOYDIR} and I get 
the same behaviour as before + the benefit of sstate cache ?


Thanks


On 09/03/17 09:22, Patrick Ohly wrote:

On Thu, 2017-03-09 at 08:54 +0200, Mircea Gliga wrote:

Long story short: I have problems building an image, in a clean build
directory, reusing the shared state cache and downloads from a previous
build.
A file created in the do_deploy_append task is not created(restored)
anymore when building using a previous sstate.

And now the long description:
In my custom layer, in a kernel recipe, linux-stable.bb, I have appended
some operations to the `deploy` task, one of them is creating an U-Boot
FIT image:

linux-stable.bb:
do_deploy_append() {
[...]
  #this line creates the image_signed.fit file
   mkimage  [...] image_signed.fit

[...]
}

Are you writing image_signed.fit into the ${DEPLOYDIR} or
${DEPLOY_DIR_IMAGE}? When writing directly into ${DEPLOY_DIR_IMAGE}, you
bypass the mechanism which adds files to the sstate cache and then you
get exactly the problem you describe.



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