|
Re: normal user for Intel BSPs?
Jim Abernathy
On Jan 25, 2012, at 5:42 PM, Scott Garman wrote:
On 01/25/2012 02:18 PM, Darren Hart wrote:Thanks for these suggestions. I'll look them over and figure out what I want to do.On 01/25/2012 09:36 AM, jfabernathy wrote:Hi Jim, Darren:I've noticed that the meta-intel BSP come up with the defaultI'm adding Scott G. who I believe has been working on the useradd Jim A -- |
|
|
|
Re: normal user for Intel BSPs?
Scott Garman <scott.a.garman@...>
On 01/25/2012 02:18 PM, Darren Hart wrote:
On 01/25/2012 09:36 AM, jfabernathy wrote:Hi Jim, Darren:I've noticed that the meta-intel BSP come up with the defaultI'm adding Scott G. who I believe has been working on the useradd The useradd mechanism is for supporting custom users and groups in recipes. It sounds like what Jim may find more expedient would be to define a recipe which includes a first-boot script which creates the additional users/groups and then sets up custom ownership on the terminal, serial console user, etc. Otherwise you'd have to do this in several recipes. Using the first-boot script approach is documented here: http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#usingpoky-extend-addpkg-postinstalls Whereas using the useradd bitbake class is documented in an example recipe in meta-skeleton/recipes-skeleton/useradd/useradd-example.bb. There is also a slide deck you may find useful here: http://wiki.yoctoproject.org/wiki/images/e/e6/Custom_Users_Groups_in_Yocto1.1.pdf I'll also mention that I'm still shaking out bugs in the useradd mechanism. We have some race conditions that are complicating matters when building from sstate. So if you're using one of our stable releases, the first-boot script approach is probably your safest bet. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center |
|
|
|
Re: normal user for Intel BSPs?
Darren Hart <dvhart@...>
On 01/25/2012 09:36 AM, jfabernathy wrote:
I've noticed that the meta-intel BSP come up with the defaultI'm adding Scott G. who I believe has been working on the useradd scripts and such (to sanity check the following). I believe you should be able to setup new users by extending an image recipe with a new task to make the necessary useradd/mod etc calls on the rootfs prior to packaging it up. Scott, can you offer more detail on how that is done? -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel |
|
|
|
Re: [PATCH 0/2][KERNEL] new yocto/emgd-1.10 feature branch
Bruce Ashfield <bruce.ashfield@...>
On 12-01-25 03:30 PM, Tom Zanussi wrote:
On Tue, 2012-01-10 at 15:50 -0500, Bruce Ashfield wrote:Thanks Tom, I'm doing 3.0.x updates + 3.2 right now, so I'llOn 12-01-02 02:31 PM, tom.zanussi@... wrote:Hi Bruce,From: Tom Zanussi<tom.zanussi@...>Just pinging. I assume these are safe to merge now ? roll this into that update. ETA tomorrow. Bruce
|
|
|
|
Re: [PATCH 0/2][KERNEL] new yocto/emgd-1.10 feature branch
Tom Zanussi <tom.zanussi@...>
On Tue, 2012-01-10 at 15:50 -0500, Bruce Ashfield wrote:
On 12-01-02 02:31 PM, tom.zanussi@... wrote:Hi Bruce,From: Tom Zanussi<tom.zanussi@...>Just pinging. I assume these are safe to merge now ? Safe now, please merge at your convenience. Thanks, Tom Bruce |
|
|
|
normal user for Intel BSPs?
Jim Abernathy
I've noticed that the meta-intel BSP come up with the default terminal, serial console user, etc. as root. What would it take to make my own BSP that was exactly the same, but the default was a not admin user, but you could su or sudo to root?
Jim A |
|
|
|
Minutes: Yocto Project 1.2 M2 release readiness meeting
Liu, Song <song.liu@...>
Attendees:
Beth, Dave, Kevin, Joshua, Darren, Tom, Richard, Mark Hatle, Mark Orvek, Jessica, Denys, ScottR, Song Release criteria review: 1. Completed all P1 features for M2, some P2/P3 features did not make M2 and are pushed to M3, but most of them are either completed now or close to be completed at this point. 2. M2 RC1 passed full path test, all known issues are logged in Bugzilla. Beagleboard BSP has xServer issue, but not show stopper, users of this BSP can still use the M1 build. The reported HOB2 issue is already fixed. Core build system has 3 problems, 1 already fixed, the other 2 are being worked on. All none show stoppers. 3. The latest version of Fedora, Opensuse, Ubuntu has been tested, no new issues found. 4. Quality has been under control, the WDD number has been relatively stable. Since the beginning of the 1.2 release, we opened more than 100 medium+ bugs and we fixed more than that, so the overall trending for total outstanding medium+ bugs is down. Thanks to Richard and the whole team to make this happen. 5. Performance has a degradation, but stable compared with 1.1. Could be caused by enlarged BSP images (the problem is already fixed). Richard is going to take a look. QA will check this after coming back from their holidays for M3. 6. We exceeded our target for package update, and at 99% for patch upstream status update. Uclibc patches are still being worked on. 7. Remove marketing deliverable from milestone release. Voting: Intel/Dave: Go Wind River/Mark Hatle: Go TI/Denys: Go MontaVista/Mark Orvek: Go Linux Foundation/Richard: Go Next step: 1. Beth will have the release note reviewed 2. Beth will push out the release tarball and announce the release in the public mailing list. 3. Dave will write a blog entry. -----Original Appointment----- From: Liu, Song Sent: Tuesday, January 24, 2012 9:17 AM Subject: Yocto Project 1.2 M2 release readiness meeting When: Wednesday, January 25, 2012 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada). Where: 916-356-2663, 8-356-2663, Bridge: 94, Passcode: 5917456 https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.2_Status#Milestone_2 |
|
|
|
Re: overriding a class in custom layer
Chris Larson <clarson@...>
On Wed, Jan 25, 2012 at 8:56 AM, Paul Eggleton
<paul.eggleton@...> wrote: On Wednesday 25 January 2012 11:03:16 Joshua Immanuel wrote:On Tue, 2012-01-24 at 16:17 +0000, Paul Eggleton wrote:AFAIK we don't already have the ability to do this, but it sounds very useful.I'd also say, what is in the classes is intended to work for everyone,At present when we build an image, everything gets under one partition. That does sound nice. Actually, it'd also be nice to come up with a declarative way to express info about partitioning in general, which would ideally result in an automatic split up of the rootfs across those partitions when appropriate. Hmmm. -- Christopher Larson |
|
|
|
Re: Is there a recipe for evtest package?
Brian Hutchinson <b.hutchman@...>
On Wed, Jan 25, 2012 at 10:45 AM, Jack Mitchell <ml@...> wrote:
The way I tend to tackle this is to copy the recipe from meta-oe into my ownThanks!, I'll look into that. I had an OE based checkout so I just bitbaked the linux-input recipe for speed. I do want to figure out how to do this in Yocto though so thank for pointing me in the right direction. I didn't want to reinvent the wheel if there was already some established way of doing it that I just wasn't seeing. Regards, Brian |
|
|
|
Re: overriding a class in custom layer
Paul Eggleton
On Wednesday 25 January 2012 11:03:16 Joshua Immanuel wrote:
On Tue, 2012-01-24 at 16:17 +0000, Paul Eggleton wrote:AFAIK we don't already have the ability to do this, but it sounds very useful.I'd also say, what is in the classes is intended to work for everyone,At present when we build an image, everything gets under one partition. If it can be something that can be enabled and configured relatively easily then it would be great to have in OE-Core as I can imagine others making use of it. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre |
|
|
|
Re: Is there a recipe for evtest package?
Brian Hutchinson <b.hutchman@...>
On Wed, Jan 25, 2012 at 9:48 AM, Jack Mitchell <ml@...> wrote:
Hi Brian,Hi Jack, I'm still trying to get up-to-speed on how to work with Yocto .... would adding this layer be just like adding say poky extras? Regards, Brian |
|
|
|
Re: Is there a recipe for evtest package?
Jack Mitchell <ml@...>
On 25/01/12 14:42, Brian Hutchinson wrote:
Hi,Hi Brian, Your best bet is to adapt the one from meta-oe here: http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-support/evtest Cheers, Jack. |
|
|
|
Is there a recipe for evtest package?
Brian Hutchinson <b.hutchman@...>
Hi,
Looking for the evtest package in Yocto. Is there a meta data layer I can checkout that has it? Regards, Brian |
|
|
|
Re: overriding a class in custom layer
josh@hipro.co.in
Hello Paul,
Thanks for the reply. On Tue, 2012-01-24 at 16:17 +0000, Paul Eggleton wrote: I'd also say, what is in the classes is intended to work for everyone,At present when we build an image, everything gets under one partition. For my use case I need two images (denoting different partitions) 1. rootfs image (mount point: '/', mounted as ro) 2. data partition image (mount point: say '/data' mounted as rw) While generating the image, I construct the /etc/fstab file manually by representing filesystems by their uuids (generated using uuidgen). So, to set this uuid in generated image I try to override the image_types.bbclass and using tune2fs I set the uuid for the generated images. Is there any other better way of doing this? Regards Joshua -- Joshua Immanuel HiPro IT Solutions Private Limited http://hipro.co.in |
|
|
|
Re: [PATCH 6/6] meta-fri2: update README
Darren Hart <dvhart@...>
On 01/24/2012 04:00 PM, tom.zanussi@... wrote:
From: Tom Zanussi <tom.zanussi@...>Acked-by: Darren Hart <dvhart@...> ----- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel |
|
|
|
Re: [PATCH 3/6] meta-fri2: remove PREFERRED_VERSION for emgd-driver-bin
Darren Hart <dvhart@...>
On 01/24/2012 04:00 PM, tom.zanussi@... wrote:
From: Tom Zanussi <tom.zanussi@...>Acked-by: Darren Hart <dvhart@...> ----- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel |
|
|
|
[PATCH 6/6] meta-fri2: update README
tom.zanussi@...
From: Tom Zanussi <tom.zanussi@...>
The new emgd-driver-bin_1.10 recipe no longer requires manually extracting and installing emgd binaries, so remove the section that deals with that. It does require a new LICENSE_FLAGS_WHITELIST entry in local.conf, so add instructions detailing that. Signed-off-by: Tom Zanussi <tom.zanussi@...> --- meta-fri2/README | 86 +++++++---------------------------------------------- 1 files changed, 12 insertions(+), 74 deletions(-) diff --git a/meta-fri2/README b/meta-fri2/README index 2f8a5a4..df2fa87 100644 --- a/meta-fri2/README +++ b/meta-fri2/README @@ -8,7 +8,7 @@ processor, plus the Intel EG20T Platform Controller Hub (Tunnel Creek and various other machine-to-machine (m2m) capabilities. It also supports the E6xx embedded on-chip graphics via the Intel -Embedded Media and Graphics Driver (EMGD) 1.8 Driver. +Embedded Media and Graphics Driver (EMGD) 1.10 Driver. Dependencies @@ -43,8 +43,7 @@ Table of Contents ================= I. Building the meta-fri2 BSP layer - II. Special notes for building the meta-fri2 BSP layer -III. Booting the images in /binary + II. Booting the images in /binary I. Building the meta-fri2 BSP layer @@ -66,7 +65,7 @@ between BSPs) e.g.: The meta-fri2 layer contains support for two different machine configurations. These configurations are identical except for the fact that the one prefixed with 'fri2' makes use of the Intel-proprietary -EMGD 1.8 graphics driver, while the one prefixed with 'fri2-noemgd' +EMGD 1.10 graphics driver, while the one prefixed with 'fri2-noemgd' does not. If you want to enable the layer that supports EMGD graphics add the @@ -74,6 +73,13 @@ following to the local.conf file: MACHINE ?= "fri2" +The 'fri2' machine includes the emgd-driver-bin package, which has a +proprietary license that must be whitelisted by adding the string +"license_emgd-driver-bin_1.10" to the LICENSE_FLAGS_WHITELIST variable +in your local.conf. For example: + + LICENSE_FLAGS_WHITELIST = "license_emgd-driver-bin_1.10" + If you want to enable the layer that does not support EMGD graphics add the following to the local.conf file: @@ -99,76 +105,8 @@ equivalently check out the appropriate branch from the meta-intel repository at the same location. -II. Special notes for building the meta-fri2 BSP layer -====================================================== - -The meta-fri2 layer makes use of the proprietary Intel EMGD userspace -drivers when building the "fri2" machine (but not when building the -"fri2-noemgd" machine). If you got the BSP from the 'BSP Downloads' -section of the Yocto website, the EMGD binaries needed to perform the -build will already be present in the BSP, located in the -meta-intel/common/recipes-graphics/xorg-xserver/emgd-driver-bin-1.8 -directory, and you can ignore the rest of this section. - -If you didn't get the BSP from the 'BSP Downloads' section of the -Yocto website, you can download a tarball containing an rpm that -contains the binaries and extract the binaries from that, and copy -them to the proper location in the meta-fri2 layer. - -The following subsection describes that process in detail. - - -Downloading and extracting the binaries using the EMGD Linux tarball --------------------------------------------------------------------- - -The first step of the process is to download the EMGD 1.8 Driver. -Here is the current link to the URL from which it can be downloaded: - -http://edc.intel.com/Software/Downloads/EMGD/ - -In the Download Now tab, select: - -Intel® architecture-based product: Linux Tar Ball -Operating System: MeeGo* 1.2 IVI Linux* (kernel 2.6.37, X.server 1.9, Mesa 7.9) - -That will give you a large .tgz file: - -Lin_EMGD_1_8_RC_2032.tgz - -Extract the files in the tar file, which will in turn give you a -directory named IEMGD_HEAD_Linux. - -The binaries are contained in an rpm file; you can extract the -binaries from the rpm file using rpm2cpio and cpio: - -$ cd IEMGD_HEAD_Linux/MeeGo1.2 -$ rpm2cpio emgd-bin-2032-1.6.i586.rpm > emgd-bin-2032-1.6.i586.cpio -$ mkdir extracted; cd extracted -$ cpio -idv < ../emgd-bin-2032-1.6.i586.cpio - -Finally, you can copy the xorg-xserver binaries to the -emgd-driver-bin-1.8 directory in meta-intel/common: - -$ cp -a usr/lib meta-intel/common/recipes-graphics/xorg-xserver/emgd-driver-bin-1.8 - -You also need to copy the IEMGD License.txt file to the same directory: - -$ cp IEMGD_HEAD_Linux/License/License.txt meta-intel/common/recipes/xorg-xserver/emgd-driver-bin-1.8 - -Additionally, you should remove the following unused file from the -emgd binaries in order to avoid a packaging error at build-time: - -$ rm meta-intel/common/recipes-graphics/xorg-xserver/emgd-driver-bin-1.8/lib/dri/emgd_drv_video.so - -Finally, you need to remove the following file: - -$ rm meta-intel/common/recipes-graphics/xorg-xserver/emgd-driver-bin-1.8/lib/dri/emgd_drv_video.so - -At this point, you should be able to build meta-fri2 images as usual. - - -III. Booting the images in /binary -================================== +II. Booting the images in /binary +================================= This BSP contains bootable live images, which can be used to directly boot Yocto off of a USB flash drive. -- 1.7.0.4 |
|
|
|
[PATCH 5/6] meta-crownbay: update README
tom.zanussi@...
From: Tom Zanussi <tom.zanussi@...>
The new emgd-driver-bin_1.10 recipe no longer requires manually extracting and installing emgd binaries, so remove the section that deals with that. It does require a new LICENSE_FLAGS_WHITELIST entry in local.conf, so add instructions detailing that. Signed-off-by: Tom Zanussi <tom.zanussi@...> --- meta-crownbay/README | 97 ++++++------------------------------------------- 1 files changed, 12 insertions(+), 85 deletions(-) diff --git a/meta-crownbay/README b/meta-crownbay/README index 65289f7..b56c79a 100644 --- a/meta-crownbay/README +++ b/meta-crownbay/README @@ -6,7 +6,7 @@ The Crown Bay platform consists of the Intel Atom Z6xx processor, plus the Intel EG20T Platform Controller Hub (Tunnel Creek + Topcliff). It also supports the E6xx embedded on-chip graphics via the Intel -Embedded Media and Graphics Driver (EMGD) 1.8 Driver. +Embedded Media and Graphics Driver (EMGD) 1.10 Driver. Dependencies @@ -41,8 +41,7 @@ Table of Contents ================= I. Building the meta-crownbay BSP layer - II. Special notes for building the meta-crownbay BSP layer -III. Booting the images in /binary + II. Booting the images in /binary I. Building the meta-crownbay BSP layer @@ -64,7 +63,7 @@ common metadata shared between BSPs) e.g.: The meta-crownbay layer contains support for two different machine configurations. These configurations are identical except for the fact that the one prefixed with 'crownbay' makes use of the -Intel-proprietary EMGD 1.8 graphics driver, while the one prefixed +Intel-proprietary EMGD 1.10 graphics driver, while the one prefixed with 'crownbay-noemgd' does not. If you want to enable the layer that supports EMGD graphics add the @@ -72,6 +71,13 @@ following to the local.conf file: MACHINE ?= "crownbay" +The 'crownbay' machine includes the emgd-driver-bin package, which has +a proprietary license that must be whitelisted by adding the string +"license_emgd-driver-bin_1.10" to the LICENSE_FLAGS_WHITELIST variable +in your local.conf. For example: + + LICENSE_FLAGS_WHITELIST = "license_emgd-driver-bin_1.10" + If you want to enable the layer that does not support EMGD graphics add the following to the local.conf file: @@ -97,87 +103,8 @@ equivalently check out the appropriate branch from the meta-intel repository at the same location. -II. Special notes for building the meta-crownbay BSP layer -========================================================== - -The meta-crownbay layer makes use of the proprietary Intel EMGD -userspace drivers when building the "crownbay" machine (but not when -building the "crownbay-noemgd" machine). If you got the BSP from the -'BSP Downloads' section of the Yocto website, the EMGD binaries needed -to perform the build will already be present in the BSP, located in -the meta-intel/common/recipes-graphics/xorg-xserver/emgd-driver-bin-1.8 -directory, and you can ignore the rest of this section. - -If you didn't get the BSP from the 'BSP Downloads' section of the -Yocto website, you can download a tarball containing an rpm that -contains the binaries and extract the binaries from that, and copy -them to the proper location in the meta-crownbay layer. - -The following subsection describes that process in detail. - - -Downloading and extracting the binaries using the EMGD Linux tarball --------------------------------------------------------------------- - -The first step of the process is to download the EMGD 1.8 Driver. -Here is the current link to the URL from which it can be downloaded: - -http://edc.intel.com/Software/Downloads/EMGD/ - -In the Download Now tab, select: - -Intel® architecture-based product: Linux Tar Ball -Operating System: MeeGo* 1.2 IVI Linux* (kernel 2.6.37, X.server 1.9, Mesa 7.9) - -That will give you a large .tgz file: - -Lin_EMGD_1_8_RC_2032.tgz - -Extract the files in the tar file, which will in turn give you a -directory named IEMGD_HEAD_Linux. - -The binaries are contained in an rpm file; you can extract the -binaries from the rpm file using rpm2cpio and cpio: - -$ cd IEMGD_HEAD_Linux/MeeGo1.2 -$ rpm2cpio emgd-bin-2032-1.6.i586.rpm > emgd-bin-2032-1.6.i586.cpio -$ mkdir extracted; cd extracted -$ cpio -idv < ../emgd-bin-2032-1.6.i586.cpio - -You can now copy the xorg-xserver binaries to the emgd-driver-bin-1.8 -directory in meta-intel/common: - -$ cp -a usr/lib meta-intel/common/recipes-graphics/xorg-xserver/emgd-driver-bin-1.8 - -You also need to copy the IEMGD License.txt file to the same directory: - -$ cp IEMGD_HEAD_Linux/License/License.txt meta-intel/common/recipes/xorg-xserver/emgd-driver-bin-1.8 - -Finally, you need to extract and copy the video plugins to the -emgd-driver-bin-1.8 directory in meta-intel/common: - -$ cd IEMGD_HEAD_Linux/common/video_plugin -$ rpm2cpio gst-plugins-mixvideo-0.10.30-1.i586.rpm > gst-plugins-mixvideo-0.10.30-1.i586.cpio -$ rpm2cpio gst-plugins-va-0.10.7MFLD-1.i586.rpm > gst-plugins-va-0.10.7MFLD-1.i586.cpio -$ rpm2cpio gst-vabuffer-0.10.5MFLD-1.i586.rpm > gst-vabuffer-0.10.5MFLD-1.i586.cpio -$ rpm2cpio mixcommon-0.1.9-1.i586.rpm > mixcommon-0.1.9-1.i586.cpio -$ rpm2cpio mixvbp-0.1.24-1.i586.rpm > mixvbp-0.1.24-1.i586.cpio -$ rpm2cpio mixvideo-0.1.31-1.i586.rpm > mixvideo-0.1.31-1.i586.cpio -$ mkdir extracted; cd extracted -$ cpio -idv < ../gst-plugins-mixvideo-0.10.30-1.i586.cpio -$ cpio -idv < ../gst-plugins-va-0.10.7MFLD-1.i586.cpio -$ cpio -idv < ../gst-vabuffer-0.10.5MFLD-1.i586.cpio -$ cpio -idv < ../mixcommon-0.1.9-1.i586.cpio -$ cpio -idv < ../mixvbp-0.1.24-1.i586.cpio -$ cpio -idv < ../mixvideo-0.1.31-1.i586.cpio -$ rm usr/lib/*.so.0 -$ cp -a usr/lib meta-intel/common/recipes-graphics/xorg-xserver/emgd-driver-bin-1.8 - -At this point, you should be able to build meta-crownbay images as usual. - - -III. Booting the images in /binary -================================== +II. Booting the images in /binary +================================= This BSP contains bootable live images, which can be used to directly boot Yocto off of a USB flash drive. -- 1.7.0.4 |
|
|
|
[PATCH 4/6] meta-crownbay: remove PREFERRED_VERSION for emgd-driver-bin
tom.zanussi@...
From: Tom Zanussi <tom.zanussi@...>
crownbay specifies a preferred version of 1.8 for emgd, but there's really no reason to do that at this point - it should be able to use the new 1.10 version. Signed-off-by: Tom Zanussi <tom.zanussi@...> --- meta-crownbay/conf/machine/crownbay.conf | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/meta-crownbay/conf/machine/crownbay.conf b/meta-crownbay/conf/machine/crownbay.conf index 1bf3bdd..15bfd52 100644 --- a/meta-crownbay/conf/machine/crownbay.conf +++ b/meta-crownbay/conf/machine/crownbay.conf @@ -14,7 +14,6 @@ XSERVER ?= "${XSERVER_IA32_BASE} \ PREFERRED_VERSION_xserver-xorg ?= "1.9.3" PREFERRED_VERSION_mesa-dri ?= "7.11" -PREFERRED_VERSION_emgd-driver-bin ?= "1.8" APPEND += "video=vesafb vga=0x318" -- 1.7.0.4 |
|
|
|
[PATCH 3/6] meta-fri2: remove PREFERRED_VERSION for emgd-driver-bin
tom.zanussi@...
From: Tom Zanussi <tom.zanussi@...>
fri2 specifies a preferred version of 1.8 for emgd, but there's really no reason to do that at this point - it should be able to use the new 1.10 version. Signed-off-by: Tom Zanussi <tom.zanussi@...> --- meta-fri2/conf/machine/fri2.conf | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/meta-fri2/conf/machine/fri2.conf b/meta-fri2/conf/machine/fri2.conf index 9ae4287..c69aa40 100644 --- a/meta-fri2/conf/machine/fri2.conf +++ b/meta-fri2/conf/machine/fri2.conf @@ -17,7 +17,6 @@ XSERVER ?= "${XSERVER_IA32_BASE} \ PREFERRED_VERSION_xserver-xorg ?= "1.9.3" PREFERRED_VERSION_mesa-dri ?= "7.11" -PREFERRED_VERSION_emgd-driver-bin ?= "1.8" SYSLINUX_OPTS = "serial 0 115200" SERIAL_CONSOLE = "115200 ttyS0" -- 1.7.0.4 |
|
|