From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-it1-x12f.google.com ([2607:f8b0:4864:20::12f]) by metis.ext.pengutronix.de with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1gD2PH-0003G9-T9 for rauc@pengutronix.de; Thu, 18 Oct 2018 09:07:45 +0200 Received: by mail-it1-x12f.google.com with SMTP id c23-v6so5396913itd.5 for ; Thu, 18 Oct 2018 00:07:43 -0700 (PDT) MIME-Version: 1.0 References: <25a1ab58699c9c46783d4358039e1b2ce6de8f1c.camel@klsmartin.com> <567f7f37-dac2-4072-a66e-699231661b13@pengutronix.de> In-Reply-To: From: Abhishek Kumar Rai Date: Thu, 18 Oct 2018 12:37:29 +0530 Message-ID: Subject: Re: [RAUC] Regarding booting problem ,when booting manually List-Id: RAUC Project - Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0337784366==" Errors-To: rauc-bounces@pengutronix.de Sender: "RAUC" To: ejo@pengutronix.de Cc: Leif.Middelschulte@klsmartin.com, rauc@pengutronix.de --===============0337784366== Content-Type: multipart/alternative; boundary="00000000000063eb7d05787b7153" --00000000000063eb7d05787b7153 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi team, One more point that i missed adding. I am using BSP provided by our vendor and in that reboot and shutdown option are not gracefully exiting. They are giving kernel panic. There is only option to do power reset. could this have any impact on rauc behavior ? Regards, Abhishek Rai On Thu, Oct 18, 2018 at 12:21 PM Abhishek Kumar Rai < abhishekr@eximiusdesign.com> wrote: > Hi Enrico & Leif, > > Thanks for your prompt reply. > >> I am facing one issue after doing following steps: > >> 1. flashing any image in appfs. > >> 2. rauc status mark-active rootfs.0.(Activated rootfs.0) > > Is this update considered successful by rauc? What do the logs say? If > you're using systemd, you might want to check using `journalctl -u rauc`. > >> 3. reboot > >> It is booting from rootfs.1,instead of rootfs.0 which has been marked > active. > > If your update was indeed succesful, your boot target's > `remaining_attempts` (see [0]) are 0. > > >>I fear when using U-Boot he does not have the chance to use such a > sophisticated boot selection framework as barebox has ;) > I agree > > > >>But it would be worth making sure that the U-Boot scripts perform as > expected. > > >>For debugging, one can also take a look at the raw output of fw_printen= v > in userspace > >>before and after performing mark-good to see if the variables changed > according to your expectation. > > It could also help verifying if the variables look the same in U-Boot as > they do in userspace. > Please find output of command after doing $ rauc status mark-active > rootfs.0 > {{{ > $ > fw_printenv > > bootcmd=3Dfor b in ${bootcmd_list} ; do echo Running ${b} ; run ${b}; don= e > bootdelay=3D3 > baudrate=3D115200 > ethprime=3DFEC > loadaddr=3D0x12000000 > scriptaddr=3D0x11000000 > fdt_addr=3D0x18000000 > loadaddr=3D0x12000000 > console=3Dttymxc0 > baudrate=3D115200 > fdt_high=3D0xffffffff > initrd_high=3D0xffffffff > bootcmd_list=3Dusb_bootcmd net_bootcmd mmc_bootcmd > usb_dev=3D0 > usb_part=3D1 > usb_script=3Dusb_boot.scr > usb_load=3Dusb start && usb dev && load usb ${usb_dev}:${usb_part} > ${scriptaddr} boot/${usb_script} > usb_bootcmd=3Drun usb_load && source ${scriptaddr} > mmc_script=3Dmmc_boot.scr > mmc_dev=3D0 > mmc_part=3D1 > mmc_load=3Dload mmc ${mmc_dev}:${mmc_part} ${scriptaddr} boot/${mmc_scrip= t} > mmc_bootcmd=3Drun mmc_load && source ${scriptaddr} > net_script=3Dnet_boot.scr > ipaddr=3D192.168.168.2 > serverip=3D192.168.168.20 > nfsroot=3D/srv/nfs/tkmac > net_load=3Dnfs ${scriptaddr} ${nfsroot}/boot/${net_script} > net_bootcmd=3Drun net_load && source ${scriptaddr} > panel=3DTRULY-WVGA > video_args_hdmi=3Dsetenv video_args $video_args > video=3Dmxcfb${fb}:dev=3Dhdmi,1280x720M@60,if=3DRGB24 > video_args_lvds=3Dsetenv video_args $video_args > video=3Dmxcfb${fb}:dev=3Dldb,LDB-XGA,if=3DRGB666 > video_args_lcd=3Dsetenv video_args $video_args > video=3Dmxcfb${fb}:dev=3Dlcd,TRULY-WVGA,if=3DRGB24,rotate=3D3 > video_interfaces=3Dlcd > fb=3D0 > video_args_script=3Dfor v in ${video_interfaces}; do run video_args_${v}; > setexpr fb $fb + 1; done > BOOT_B_LEFT=3D3 > BOOT_app_LEFT=3D3 > BOOT_A_LEFT=3D3 > BOOT_ORDER=3DA app B > }}} > > > >> It seems that rauc status mark-active rootfs.0 is having some issue ? > > Again, you might want to check rauc's logs on this. > I have checked rauc logs rootfs.0 is marked active. > {{{ > root@eximius:~# journalctl -u > rauc > > -- Logs begin at Tue 2018-06-19 17:41:28 UTC, end at Tue 2018-06-19 > 17:49:47 UTC. -- > Jun 19 17:41:32 eximius systemd[1]: Starting Rauc Update Service... > Jun 19 17:41:32 eximius rauc[290]: Cannot open > /dev/disk/by-path/platform-219c000.usdhc: No such file or directory > Jun 19 17:41:32 eximius rauc[290]: Error: environment not initialized > Jun 19 17:41:32 eximius rauc[290]: rauc mark: Failed marking 'rootfs.1' a= s > good: Failed to run fw_setenv: Child process exited with code 1 > Jun 19 17:41:32 eximius systemd[1]: Started Rauc Update Service. > Jun 19 17:49:47 eximius rauc[290]: rauc mark: activated slot rootfs.0 > }}} > > > >>Yes, should be really hard to say where the issue comes from with the > current information. > >>Another crucial information that we need: Which version of RAUC do you > use? > {{{ > $rauc --version > rauc 0.4 > }}} > > Regards, > Abhishek Rai > > On Thu, Oct 18, 2018 at 11:27 AM Enrico Joerns wrote= : > >> On 10/18/18 7:29 AM, Middelschulte, Leif wrote: >> > Hello Abhishek, >> > >> > Am Donnerstag, den 18.10.2018, 10:46 +0530 schrieb Abhishek Kumar Rai: >> >> Hi Team, >> >> >> >> I am facing one issue after doing following steps: >> >> 1. flashing any image in appfs. >> >> 2. rauc status mark-active rootfs.0.(Activated rootfs.0) >> > Is this update considered successful by rauc? What do the logs say? If >> you're using systemd, you might want to check using `journalctl -u rauc`= . >> >> 3. reboot >> >> It is booting from rootfs.1,instead of rootfs.0 which has been marked >> active. >> > If your update was indeed succesful, your boot target's >> `remaining_attempts` (see [0]) are 0. >> >> I fear when using U-Boot he does not have the chance to use such a >> sophisticated boot selection framework as barebox has ;) >> >> But it would be worth making sure that the U-Boot scripts perform as >> expected. >> >> For debugging, one can also take a look at the raw output of fw_printenv >> in userspace >> before and after performing mark-good to see if the variables changed >> according to your expectation. >> >> It could also help verifying if the variables look the same in U-Boot as >> they do in userspace. >> >> >> It seems that rauc status mark-active rootfs.0 is having some issue ? >> > Again, you might want to check rauc's logs on this. >> >> Yes, should be really hard to say where the issue comes from with the >> current information. >> Another crucial information that we need: Which version of RAUC do you >> use? >> >> >> Regards, Enrico >> >> > [0] >> https://www.barebox.org/doc/latest/user/bootchooser.html#the-bootchooser= -algorithm >> > >> > BR, >> > >> > Leif >> > >> >> >> >> Please find system.conf content below >> >> {{{ >> >> $ cat /etc/rauc/system.conf >> >> [system] >> >> compatible=3Deximius >> >> bootloader=3Duboot >> >> mountprefix=3D/mnt/rauc >> >> statusfile=3D/factory/rauc.status >> >> >> >> [keyring] >> >> path=3Dcert.pem >> >> >> >> [slot.rootfs.0] >> >> #device=3D/dev/mmcblk1p1 >> >> device=3D/dev/disk/by-path/platform-219c000.usdhc-part1 >> >> type=3Dext4 >> >> bootname=3DA >> >> >> >> [slot.rootfs.1] >> >> #device=3D/dev/mmcblk1p2 >> >> device=3D/dev/disk/by-path/platform-219c000.usdhc-part2 >> >> type=3Dext4 >> >> bootname=3DB >> >> >> >> [slot.appfs.0] >> >> #device=3D/dev/mmcblk1p5 >> >> device=3D/dev/disk/by-path/platform-219c000.usdhc-part5 >> >> type=3Dext4 >> >> bootname=3Dapp >> >> }}} >> >> Please provide your valuable input or suggestions on the above proble= m. >> >> >> >> Regards, >> >> Abhishek Rai >> >> >> >> >> >> The information contained in this e-mail message (including any >> attachments) may be confidential, proprietary, privileged, or otherwise >> exempt from disclosure under applicable laws. It is intended >> >> to be conveyed only to the designated recipient(s). Any use, >> dissemination, distribution, printing, retaining or copying of this e-m= ail >> (including its attachments) by unintended recipient(s) is >> >> strictly prohibited and may be unlawful. If you are not an intended >> recipient of this e-mail, or believe that you have received this e-mail= in >> error, please notify the sender immediately (by >> >> replying to this e-mail), delete any and all copies of this e-mail >> (including any attachments) from your system, and do not disclose the >> content of this e-mail to any other person. Thank you for >> >> your cooperation. >> >> >> >> This e-mail message (including any attachments) may be confidential, >> proprietary, privileged, or otherwise exempt from disclosure under >> applicable laws. If you are not an intended recipient, please >> >> delete this message. Thank you. >> >> _______________________________________________ >> >> RAUC mailing list >> > _______________________________________________ >> > RAUC mailing list >> > >> >> -- >> Pengutronix e.K. | Enrico J=C3=B6rns = | >> Industrial Linux Solutions | http://www.pengutronix.de/ >> | >> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5080= | >> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555= | >> >> --=20 The information contained in this e-mail message (including=20 any=C2=A0 attachments) may be confidential, proprietary, privileged, or=20 otherwise exempt from disclosure under applicable laws. It is intended to=20 be=C2=A0 conveyed only to the designated recipient(s). Any use, dissemination,=C2=A0 distribution, printing, retaining or copying of this e-mail (including=20 its=C2=A0 attachments) by unintended recipient(s) is strictly prohibited and=20 may=C2=A0 be unlawful. If you are not an intended recipient of this e-mail, or=20 believe=C2=A0 that you have received this e-mail in error, please notify the=20 sender=C2=A0 immediately (by replying to this e-mail), delete any and all=20 copies of=C2=A0 this e-mail (including any attachments) from your system, and=20 do not disclose the content of this e-mail to any other person. Thank you=20 for your cooperation. --=20 _This e-mail message (including any=C2=A0attachments) may be confidential,= =20 proprietary, privileged, or otherwise=C2=A0exempt from disclosure under=20 applicable laws. If you are not an intended recipient, please delete this= =20 message. Thank you. _ --00000000000063eb7d05787b7153 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi team,

One more point that= i missed adding.
I am using BSP provided by our vendor and in th= at reboot and shutdown option are not gracefully exiting.
They ar= e giving kernel panic. There is only option to do power reset.
could this have any impact on rauc behavior ?
Regards,
Abhishek Rai

=
On Thu, Oct 18, 2018 at 12:= 21 PM Abhishek Kumar Rai <abhishekr@eximiusdesign.com> wrote:
Hi Enrico & Leif,

Thanks for your promp= t reply.
>> = I am facing one issue after doing following steps:
>> 1. flashing any image in appfs.
>> 2. rauc status mark-active rootfs.0.(Activated rootfs.0)
> Is this update considered successful by rauc? What do the logs say? If you're using systemd, you might want to check using `journalctl -u= =20 rauc`.
>> 3. reboot
>> It is booting from rootfs.1,instead of rootfs.0 which has been mar= ked active.
> If your update was indeed succesful, your boot target's `remaining= _attempts` (see [0]) are 0.

 >>I fear when using U-Boot he does not have the chance to use such a = sophisticated boot selection framework as barebox has ;)
I agree


>>But it would be worth making sure that the U-Boot scripts perform a= s expected.

>>For debugging, one can also take a look at the raw output of fw_pri= ntenv in userspace
>>before and after performing mark-good to see if the variables chang= ed according to your expectation.

It could also help verifying if the variables look the same in U-Boot as th= ey do in userspace.
Please find output = of command after doing $ rauc status mark-active rootfs.0
=
{{{
$ fw_printenv=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
b= ootcmd=3Dfor b in ${bootcmd_list} ; do echo Running ${b} ; run ${b}; donebootdelay=3D3
baudrate=3D115200
ethprime=3DFEC
loadaddr=3D0x1200= 0000
scriptaddr=3D0x11000000
fdt_addr=3D0x18000000
loadaddr=3D0x1= 2000000
console=3Dttymxc0
baudrate=3D115200
fdt_high=3D0xffffffff<= br>initrd_high=3D0xffffffff
bootcmd_list=3Dusb_bootcmd net_bootcmd mmc_b= ootcmd
usb_dev=3D0
usb_part=3D1
usb_script=3Dusb_boot.scr
usb_l= oad=3Dusb start && usb dev && load usb ${usb_dev}:${usb_par= t} ${scriptaddr} boot/${usb_script}
usb_bootcmd=3Drun usb_load &&= ; source ${scriptaddr}
mmc_script=3Dmmc_boot.scr
mmc_dev=3D0
mmc_p= art=3D1
mmc_load=3Dload mmc ${mmc_dev}:${mmc_part} ${scriptaddr} boot/${= mmc_script}
mmc_bootcmd=3Drun mmc_load && source ${scriptaddr}net_script=3Dnet_boot.scr
ipaddr=3D192.168.168.2
serverip=3D192.168= .168.20
nfsroot=3D/srv/nfs/tkmac
net_load=3Dnfs ${scriptaddr} ${nfsro= ot}/boot/${net_script}
net_bootcmd=3Drun net_load && source ${sc= riptaddr}
panel=3DTRULY-WVGA
video_args_hdmi=3Dsetenv video_args $vid= eo_args video=3Dmxcfb${fb}:dev=3Dhdmi,1280x720M@60,if=3DRGB24
video_args= _lvds=3Dsetenv video_args $video_args video=3Dmxcfb${fb}:dev=3Dldb,LDB-XGA,= if=3DRGB666
video_args_lcd=3Dsetenv video_args $video_args video=3Dmxcfb= ${fb}:dev=3Dlcd,TRULY-WVGA,if=3DRGB24,rotate=3D3
video_interfaces=3Dlcd<= br>fb=3D0
video_args_script=3Dfor v in ${video_interfaces}; do run video= _args_${v}; setexpr fb $fb + 1; done
BOOT_B_LEFT=3D3
BOOT_app_LEFT=3D= 3
BOOT_A_LEFT=3D3
BOOT_ORDER=3DA app B
}}}


>> It seems that rauc status mark-active rootfs.0 is having some issu= e ?
> Again, you might want to check rauc's logs on this.
I have checked rauc logs = rootfs.0 is marked active.
{{{
root@eximius:~# journalctl -u rauc=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0
-- Logs begin at Tue 2018-06-19 17:41:28 UTC, end at= Tue 2018-06-19 17:49:47 UTC. --
Jun 19 17:41:32 eximius systemd[1]: Sta= rting Rauc Update Service...
Jun 19 17:41:32 eximius rauc[290]: Cannot o= pen /dev/disk/by-path/platform-219c000.usdhc: No such file or directory
= Jun 19 17:41:32 eximius rauc[290]: Error: environment not initialized
Ju= n 19 17:41:32 eximius rauc[290]: rauc mark: Failed marking 'rootfs.1= 9; as good: Failed to run fw_setenv: Child process exited with code 1
Ju= n 19 17:41:32 eximius systemd[1]: Started Rauc Update Service.
Jun 19 17= :49:47 eximius rauc[290]: rauc mark: activated slot rootfs.0
}}}


>>Yes, should be really hard to say where the issue comes from with t= he current information.
>>Another crucial information that we need: Which version of RAUC do = you use?
{{{
$rauc --version
rauc 0.4
}}}<= br>

Regards,
Abhishek Rai

On Thu, = Oct 18, 2018 at 11:27 AM Enrico Joerns <ejo@pengutronix.de> wrote:
On 10/18/18 7:29 AM, Middelschulte, Leif wrote:
> Hello Abhishek,
>
> Am Donnerstag, den 18.10.2018, 10:46 +0530 schrieb Abhishek Kumar Rai:=
>> Hi Team,
>>
>> I am facing one issue after doing following steps:
>> 1. flashing any image in appfs.
>> 2. rauc status mark-active rootfs.0.(Activated rootfs.0)
> Is this update considered successful by rauc? What do the logs say? If= you're using systemd, you might want to check using `journalctl -u rau= c`.
>> 3. reboot
>> It is booting from rootfs.1,instead of rootfs.0 which has been mar= ked active.
> If your update was indeed succesful, your boot target's `remaining= _attempts` (see [0]) are 0.

I fear when using U-Boot he does not have the chance to use such a sophisti= cated boot selection framework as barebox has ;)

But it would be worth making sure that the U-Boot scripts perform as expect= ed.

For debugging, one can also take a look at the raw output of fw_printenv in= userspace
before and after performing mark-good to see if the variables changed accor= ding to your expectation.

It could also help verifying if the variables look the same in U-Boot as th= ey do in userspace.

>> It seems that rauc status mark-active rootfs.0 is having some issu= e ?
> Again, you might want to check rauc's logs on this.

Yes, should be really hard to say where the issue comes from with the curre= nt information.
Another crucial information that we need: Which version of RAUC do you use?=


Regards, Enrico

> [0] https://w= ww.barebox.org/doc/latest/user/bootchooser.html#the-bootchooser-algorithm
>
> BR,
>
> Leif
>
>>=C2=A0 =C2=A0
>> Please find system.conf content below
>> {{{
>> $ cat /etc/rauc/system.conf
>> [system]
>> compatible=3Deximius
>> bootloader=3Duboot
>> mountprefix=3D/mnt/rauc
>> statusfile=3D/factory/rauc.status
>>
>> [keyring]
>> path=3Dcert.pem
>>
>> [slot.rootfs.0]
>> #device=3D/dev/mmcblk1p1
>> device=3D/dev/disk/by-path/platform-219c000.usdhc-part1
>> type=3Dext4
>> bootname=3DA
>>
>> [slot.rootfs.1]
>> #device=3D/dev/mmcblk1p2
>> device=3D/dev/disk/by-path/platform-219c000.usdhc-part2
>> type=3Dext4
>> bootname=3DB
>>
>> [slot.appfs.0]
>> #device=3D/dev/mmcblk1p5
>> device=3D/dev/disk/by-path/platform-219c000.usdhc-part5
>> type=3Dext4
>> bootname=3Dapp
>> }}}
>> Please provide your valuable input or suggestions on the above pro= blem.
>>
>> Regards,
>> Abhishek Rai
>>
>>
>>=C2=A0 =C2=A0The information contained in this e-mail message (incl= uding any=C2=A0 attachments) may be confidential, proprietary, privileged, = or otherwise exempt from disclosure under applicable laws. It is intended >> to be=C2=A0 conveyed only to the designated recipient(s). Any use,= dissemination,=C2=A0 distribution, printing, retaining or copying of this = e-mail (including its=C2=A0 attachments) by unintended recipient(s) is
>> strictly prohibited and may=C2=A0 be unlawful. If you are not an i= ntended recipient of this e-mail, or believe=C2=A0 that you have received t= his e-mail in error, please notify the sender=C2=A0 immediately (by
>> replying to this e-mail), delete any and all copies of=C2=A0 this = e-mail (including any attachments) from your system, and do not disclose th= e content of this e-mail to any other person. Thank you for
>> your cooperation.
>>
>> This e-mail message (including any attachments) may be confidentia= l, proprietary, privileged, or otherwise exempt from disclosure under appli= cable laws. If you are not an intended recipient, please
>> delete this message. Thank you.
>> _______________________________________________
>> RAUC mailing list
> _______________________________________________
> RAUC mailing list
>

--
Pengutronix e.K.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Enrico J=C3=B6rns=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
Industrial Linux Solutions=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0| http://www.pengutronix.de/=C2=A0 |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5080 |<= br> Amtsgericht Hildesheim, HRA 2686=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Fax:=C2=A0 =C2=A0+49-5121-206917-5555 |


The information contained in this e-mail message (including any=C2= =A0

attachments) may be confidential, proprietary, privileged, or othe= rwise

exempt from disclosure under applicable laws. It is intended to be= =C2=A0

conveyed only to the designated recipient(s). Any use, disseminati= on,=C2=A0

distribution, printing, retaining or copying of this e-mail (inclu= ding its=C2=A0

attachments) by unintended recipient(s) is strictly prohibited and= may=C2=A0

be unlawful. If you are not an intended recipient of this e-mail, = or believe=C2=A0

that you have received this e-mail in error, please notify the sen= der=C2=A0

immediately (by replying to this e-mail), delete any and all copie= s of=C2=A0

this e-mail (including any attachments) from your system, and do n= ot

disclose the content of this e-mail to any other person. Thank you= for your cooperation.

This e-mail message (including any=C2=A0attachments) may be= confidential, proprietary, privileged, or otherwise=C2=A0exempt from discl= osure under applicable laws. If you are not an intended recipient, please d= elete this message. Thank you.
--00000000000063eb7d05787b7153-- --===============0337784366== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KUkFVQyBtYWls aW5nIGxpc3Q= --===============0337784366==--