Quantcast

How to modify/add rootfs /etc/* configuration files/scripts in bitbake image recipe?

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

How to modify/add rootfs /etc/* configuration files/scripts in bitbake image recipe?

Donny3000
Hello All,

I'm becoming more familiar and proficient with openembedded, but I can't seem to figure out how to add my own configuration files (or modify existing configuration files) to the rootfs image.  For instance, if I'm making using the omap3-console-image recipe to create console image, but I want to add (or modify) a configuration file in /etc, how would I go about doing that? Having to modify and/or add files to the rootfs after it has been built, flashed onto the SD and then booted is getting pretty old.  If anyone can provide some insight, it would be greatly appreciated.

-Donald
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to modify/add rootfs /etc/* configuration files/scripts in bitbake image recipe?

MiLo
I usually create a new recipe for such configuration files, for example "recipes/my-company/my-company-wifi.bb" (to which you can conveniently add RDEPENDS to e.g. automatically draw in kernel modules and other packages).

For existing config files, I usually ask opkg where they came from (e.g. "opkg search /etc/network/interfaces") and then change the origin of the patch.

If you create a distro for your project, by simply copying an existing one, you can easily use its "override" to supply your specific config files and things without changing others too much.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to modify/add rootfs /etc/* configuration files/scripts in bitbake image recipe?

CaseyS
MiLo,

Thanks for the "opkg search" tip, I never knew about this feature and
this will greatly help modifying recipes in the future. But you
mentioned how you create your own recipes for certain configuration
files. I know a lot of people including myself alway complain that
their is a lack of example recipes more complicated then the simple
hello world recipe but less complicated then ones found in
org.openembedded.dev folder. With that in mind if you have the time
and inclination, I think it would help a lot of people if you could
post one of your custom recipes, stripped of any personal or
confidential information of course, so that it could help smooth out
the learning curve when it comes to writing recipes.

Casey

On Fri, Apr 27, 2012 at 9:26 AM, MiLo <[hidden email]> wrote:

> I usually create a new recipe for such configuration files, for example
> "recipes/my-company/my-company-wifi.bb" (to which you can conveniently add
> RDEPENDS to e.g. automatically draw in kernel modules and other packages).
>
> For existing config files, I usually ask opkg where they came from (e.g.
> "opkg search /etc/network/interfaces") and then change the origin of the
> patch.
>
> If you create a distro for your project, by simply copying an existing one,
> you can easily use its "override" to supply your specific config files and
> things without changing others too much.
>
> --
> View this message in context: http://gumstix.8.n6.nabble.com/How-to-modify-add-rootfs-etc-configuration-files-scripts-in-bitbake-image-recipe-tp4933162p4933915.html
> Sent from the Gumstix mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> gumstix-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gumstix-users

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
j
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to modify/add rootfs /etc/* configuration files/scripts in bitbake image recipe?

j
On 04/27/2012 08:44 AM, Casey St.Fleur wrote:

> MiLo,
>
> Thanks for the "opkg search" tip, I never knew about this feature and
> this will greatly help modifying recipes in the future. But you
> mentioned how you create your own recipes for certain configuration
> files. I know a lot of people including myself alway complain that
> their is a lack of example recipes more complicated then the simple
> hello world recipe but less complicated then ones found in
> org.openembedded.dev folder. With that in mind if you have the time
> and inclination, I think it would help a lot of people if you could
> post one of your custom recipes, stripped of any personal or
> confidential information of course, so that it could help smooth out
> the learning curve when it comes to writing recipes.
>
> Casey
>
> On Fri, Apr 27, 2012 at 9:26 AM, MiLo<[hidden email]>  wrote:
>> I usually create a new recipe for such configuration files, for example
>> "recipes/my-company/my-company-wifi.bb" (to which you can conveniently add
>> RDEPENDS to e.g. automatically draw in kernel modules and other packages).
>>
>> For existing config files, I usually ask opkg where they came from (e.g.
>> "opkg search /etc/network/interfaces") and then change the origin of the
>> patch.
>>
>> If you create a distro for your project, by simply copying an existing one,
>> you can easily use its "override" to supply your specific config files and
>> things without changing others too much.
>>
>> --
>> View this message in context: http://gumstix.8.n6.nabble.com/How-to-modify-add-rootfs-etc-configuration-files-scripts-in-bitbake-image-recipe-tp4933162p4933915.html
>> Sent from the Gumstix mailing list archive at Nabble.com.
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> gumstix-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gumstix-users
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> gumstix-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gumstix-users

I second that as I was just looking into doing the same thing finally.
Got tired of copying over all my configs after first boot of the device.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to modify/add rootfs /etc/* configuration files/scripts in bitbake image recipe?

Donny3000
In reply to this post by MiLo
Thanks Milo for the RDEPENDS suggestion.  I'll try that out. But, I echo the same sentiments of the other on this topic in regard to there not being enough example recipes to look at for help.  If you have the time I (as well as a lot others) would really appreciate it.

-Donald

MiLo wrote
I usually create a new recipe for such configuration files, for example "recipes/my-company/my-company-wifi.bb" (to which you can conveniently add RDEPENDS to e.g. automatically draw in kernel modules and other packages).

For existing config files, I usually ask opkg where they came from (e.g. "opkg search /etc/network/interfaces") and then change the origin of the patch.

If you create a distro for your project, by simply copying an existing one, you can easily use its "override" to supply your specific config files and things without changing others too much.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to modify/add rootfs /etc/* configuration files/scripts in bitbake image recipe?

Donny3000
In reply to this post by MiLo
Milo, your suggestion about create a new package for the configuration files worked out for me.  I also ended up modifying the configuration files of existing pacakges (e.g. wpa-supplicant, glibc) so they would install the modified configuration files.  Thanks for you input.

-Donny3000

MiLo wrote
I usually create a new recipe for such configuration files, for example "recipes/my-company/my-company-wifi.bb" (to which you can conveniently add RDEPENDS to e.g. automatically draw in kernel modules and other packages).

For existing config files, I usually ask opkg where they came from (e.g. "opkg search /etc/network/interfaces") and then change the origin of the patch.

If you create a distro for your project, by simply copying an existing one, you can easily use its "override" to supply your specific config files and things without changing others too much.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

kernel-3.3 madc patch

Keane, Ben (STRX)
Hi,

Recently I cloned the 3.3 kernel (remotes/origin/omap-3.3) from Sakoman's git server. I went to use the MADC via the sysfs interface (/sys/class/hwmon/hwmon1/device/) but that directory didn't exist.

The following is a patch I created to get the ADC's working on this branch.

diff --git a/arch/arm/mach-omap2/board-overo.c b/arch/arm/mach-omap2/board-overo.c
index 52c0cef..ba4c4da 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -363,6 +363,23 @@ static void __init overo_init_led(void)
 static inline void __init overo_init_led(void) { return; }
 #endif
 
+#ifdef CONFIG_TWL4030_MADC
+
+static struct platform_device madc_hwmon_device = {
+ .name = "twl4030_madc_hwmon",
+ .id = -1,
+};
+
+static void __init overo_init_madc_hwmon(void)
+{
+ platform_device_register(&madc_hwmon_device);
+}
+
+#else
+static inline void __init overo_init_madc_hwmon(void) { return; }
+#endif
+
+
 #if defined(CONFIG_KEYBOARD_GPIO) || defined(CONFIG_KEYBOARD_GPIO_MODULE)
 #include <linux/input.h>
 #include <linux/gpio_keys.h>
@@ -447,7 +464,7 @@ static struct twl4030_platform_data overo_twldata = {
 static int __init overo_i2c_init(void)
 {
  omap3_pmic_get_config(&overo_twldata,
- TWL_COMMON_PDATA_USB | TWL_COMMON_PDATA_AUDIO,
+ TWL_COMMON_PDATA_USB | TWL_COMMON_PDATA_AUDIO | TWL_COMMON_PDATA_MADC,
  TWL_COMMON_REGULATOR_VDAC | TWL_COMMON_REGULATOR_VPLL2);
 
  overo_twldata.vpll2->constraints.name = "VDVI";
@@ -519,6 +536,7 @@ static void __init overo_init(void)
  overo_display_init();
  overo_init_led();
  overo_init_keys();
+ overo_init_madc_hwmon();
 
  /* Ensure SDRC pins are mux'd for self-refresh */
  omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT);


Hopefully this is helpful,


Ben

PROPRIETARY: This e-mail contains proprietary information some or all of which may be legally privileged.  It is intended for the recipient only.  If an addressing or transmission error has misdirected this e-mail, please notify the authority by replying to this e-mail.  If you are not the intended recipient you must not use, disclose, distribute, copy, print, or rely on this e-mail.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: kernel-3.3 madc patch

Donny3000
Thanks for your response Ben, but I think your answer is geared more toward my "Tobi Expansion Board UART Pins?" topic.  But, I do have some question about what you did.  I noticed that you have an #ifdef block enabling your code if the kernel configuration variable CONFIG_TWL430_MADC is defined.  If I were to place similar code in a #ifdef block for the UART1 code, what kernel configuration parameters should I be looking for? Or should I just place the UART1 code in the board_overo.c file without the #ifdef block?

Keane, Ben (STRX) wrote
Hi,

Recently I cloned the 3.3 kernel (remotes/origin/omap-3.3) from Sakoman's git server. I went to use the MADC via the sysfs interface (/sys/class/hwmon/hwmon1/device/) but that directory didn't exist.

The following is a patch I created to get the ADC's working on this branch.

diff --git a/arch/arm/mach-omap2/board-overo.c b/arch/arm/mach-omap2/board-overo.c
index 52c0cef..ba4c4da 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -363,6 +363,23 @@ static void __init overo_init_led(void)
 static inline void __init overo_init_led(void) { return; }
 #endif
 
+#ifdef CONFIG_TWL4030_MADC
+
+static struct platform_device madc_hwmon_device = {
+ .name = "twl4030_madc_hwmon",
+ .id = -1,
+};
+
+static void __init overo_init_madc_hwmon(void)
+{
+ platform_device_register(&madc_hwmon_device);
+}
+
+#else
+static inline void __init overo_init_madc_hwmon(void) { return; }
+#endif
+
+
 #if defined(CONFIG_KEYBOARD_GPIO) || defined(CONFIG_KEYBOARD_GPIO_MODULE)
 #include <linux/input.h>
 #include <linux/gpio_keys.h>
@@ -447,7 +464,7 @@ static struct twl4030_platform_data overo_twldata = {
 static int __init overo_i2c_init(void)
 {
  omap3_pmic_get_config(&overo_twldata,
- TWL_COMMON_PDATA_USB | TWL_COMMON_PDATA_AUDIO,
+ TWL_COMMON_PDATA_USB | TWL_COMMON_PDATA_AUDIO | TWL_COMMON_PDATA_MADC,
  TWL_COMMON_REGULATOR_VDAC | TWL_COMMON_REGULATOR_VPLL2);
 
  overo_twldata.vpll2->constraints.name = "VDVI";
@@ -519,6 +536,7 @@ static void __init overo_init(void)
  overo_display_init();
  overo_init_led();
  overo_init_keys();
+ overo_init_madc_hwmon();
 
  /* Ensure SDRC pins are mux'd for self-refresh */
  omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT);


Hopefully this is helpful,


Ben
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: kernel-3.3 madc patch

Keane, Ben (STRX)
Hi Donny,

My message was to the group in general and about using the ADC's with Steve Sakoman's omap-3.3 branch of the kernel. This won't help you fix your uart issues sorry.

Ben

>-----Original Message-----
>From: Donny3000 [mailto:[hidden email]]
>Sent: Thursday, 3 May 2012 12:28 AM
>To: [hidden email]
>Subject: Re: [Gumstix-users] kernel-3.3 madc patch
>
>Thanks for your response Ben, but I think your answer is
>geared more toward my "
>http://gumstix.8.n6.nabble.com/Tobi-Expansion-Board-UART-pins-t
>d4940084.html
>Tobi Expansion Board UART Pins? " topic.  But, I do have some
>question about what you did.  I noticed that you have an
>#ifdef block enabling your code if the kernel configuration
>variable CONFIG_TWL430_MADC is defined.  If I were to place
>similar code in a #ifdef block for the UART1 code, what kernel
>configuration parameters should I be looking for? Or should I
>just place the
>UART1 code in the board_overo.c file without the #ifdef block?
>
>
>Keane, Ben (STRX) wrote
>>
>> Hi,
>>
>> Recently I cloned the 3.3 kernel (remotes/origin/omap-3.3) from
>> Sakoman's git server. I went to use the MADC via the sysfs interface
>> (/sys/class/hwmon/hwmon1/device/) but that directory didn't exist.
>>
>> The following is a patch I created to get the ADC's working on this
>> branch.
>>
>> diff --git a/arch/arm/mach-omap2/board-overo.c
>> b/arch/arm/mach-omap2/board-overo.c
>> index 52c0cef..ba4c4da 100644
>> --- a/arch/arm/mach-omap2/board-overo.c
>> +++ b/arch/arm/mach-omap2/board-overo.c
>> @@ -363,6 +363,23 @@ static void __init overo_init_led(void)  static
>> inline void __init overo_init_led(void) { return; }  #endif
>>  
>> +#ifdef CONFIG_TWL4030_MADC
>> +
>> +static struct platform_device madc_hwmon_device = {
>> + .name = "twl4030_madc_hwmon",
>> + .id = -1,
>> +};
>> +
>> +static void __init overo_init_madc_hwmon(void) {
>> + platform_device_register(&madc_hwmon_device);
>> +}
>> +
>> +#else
>> +static inline void __init overo_init_madc_hwmon(void) { return; }
>> +#endif
>> +
>> +
>>  #if defined(CONFIG_KEYBOARD_GPIO) ||
>> defined(CONFIG_KEYBOARD_GPIO_MODULE)
>>  #include &lt;linux/input.h&gt;
>>  #include &lt;linux/gpio_keys.h&gt;
>> @@ -447,7 +464,7 @@ static struct twl4030_platform_data
>overo_twldata
>> = {  static int __init overo_i2c_init(void)  {
>>   omap3_pmic_get_config(&overo_twldata,
>> - TWL_COMMON_PDATA_USB | TWL_COMMON_PDATA_AUDIO,
>> + TWL_COMMON_PDATA_USB | TWL_COMMON_PDATA_AUDIO |
>> +TWL_COMMON_PDATA_MADC,
>>   TWL_COMMON_REGULATOR_VDAC |
>TWL_COMMON_REGULATOR_VPLL2);
>>  
>>   overo_twldata.vpll2->constraints.name = "VDVI"; @@
>-519,6 +536,7 @@
>> static void __init overo_init(void)
>>   overo_display_init();
>>   overo_init_led();
>>   overo_init_keys();
>> + overo_init_madc_hwmon();
>>  
>>   /* Ensure SDRC pins are mux'd for self-refresh */
>>   omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT);
>>
>>
>> Hopefully this is helpful,
>>
>>
>> Ben
>
>--
>View this message in context:
>http://gumstix.8.n6.nabble.com/How-to-modify-add-rootfs-etc-con
>figuration-files-scripts-in-bitbake-image-recipe-tp4933162p4946383.html
>Sent from the Gumstix mailing list archive at Nabble.com.
>
>---------------------------------------------------------------
>---------------
>Live Security Virtual Conference
>Exclusive live event will cover all the ways today's security
>and threat landscape has changed and how IT managers can
>respond. Discussions will include endpoint security, mobile
>security and the latest in malware threats.
>http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>_______________________________________________
>gumstix-users mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/gumstix-users
>
>______________________________________________________________________
>CAUTION: This message was sent via the Public Internet and its
>authenticity cannot be guaranteed.
>

PROPRIETARY: This e-mail contains proprietary information some or all of which may be legally privileged.  It is intended for the recipient only.  If an addressing or transmission error has misdirected this e-mail, please notify the authority by replying to this e-mail.  If you are not the intended recipient you must not use, disclose, distribute, copy, print, or rely on this e-mail.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Loading...