All of lore.kernel.org
 help / color / mirror / Atom feed
* [Buildroot] Help: to understand build root
       [not found]     ` <CACEFAc0DRGJW8ghzBVudK-cqd0Lx-hhgQ6GgiaPdeCLzLn21NQ@mail.gmail.com>
@ 2020-05-05 16:59       ` Kunal Chauhan
  0 siblings, 0 replies; 5+ messages in thread
From: Kunal Chauhan @ 2020-05-05 16:59 UTC (permalink / raw)
  To: buildroot

Hi Team,

Q1.As busybox is a small flavour of linux os.if i am not wrong?

Q2. What is concept of build-root. As i have seen code base compiled and
create build-root folder .
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20200505/9a41868a/attachment.html>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Buildroot] Help: to understand build root
       [not found] <mailman.1722.1588710254.59095.buildroot@busybox.net>
@ 2020-05-06  4:58 ` Andreas Ziegler
  0 siblings, 0 replies; 5+ messages in thread
From: Andreas Ziegler @ 2020-05-06  4:58 UTC (permalink / raw)
  To: buildroot

Hi Kunal,

> Message: 12
> Date: Tue, 5 May 2020 22:29:10 +0530
> From: Kunal Chauhan <atkunalchauhan@gmail.com>
> To: buildroot at busybox.net
> Subject: [Buildroot] Help: to understand build root

> Q1.As busybox is a small flavour of linux os.if i am not wrong?
> 
> Q2. What is concept of build-root. As i have seen code base compiled 
> and
> create build-root folder .

Buildroot is a build system for embedded systems. It is comparable to 
e.g. Yocto and helps you to create a GNU/Linux based image, containing 
Linux kernel, init system and root filesystem, which can then be 
transferred to a target system. Think of firmware for IoT, a router, a 
media player, or a robot in manufacturing.

Buildroot images are static, you cannot install software after 
deployment.

Buildroot images can be small, production images are counted in MiB, not 
GiB.

Buildroot handles cross-compiling. Build and target system can have 
completely different architectures.

Buildroot recipes (see configs/*_defconfig) are meant as starting point 
for your own project(s). They bring a system up and make it responsive 
(console, network), the rest is up to you.

In case you have not seen it before, the Buildroot manual is here:

   https://buildroot.org/downloads/manual/manual.html#_about_buildroot

Kind regards,
Andreas

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Buildroot] Help: to understand build root
       [not found] <mailman.3803.1589018066.59095.buildroot@busybox.net>
@ 2020-05-09 15:32 ` Andreas Ziegler
  2020-05-09 18:14   ` Kunal Chauhan
  0 siblings, 1 reply; 5+ messages in thread
From: Andreas Ziegler @ 2020-05-09 15:32 UTC (permalink / raw)
  To: buildroot

Hi Kunal,

> Message: 1
> Date: Wed, 6 May 2020 12:24:57 +0530
> From: Kunal Chauhan <atkunalchauhan@gmail.com>
> To: buildroot at busybox.net
> Subject: Re: [Buildroot] Help: to understand build root (Andreas
> 	Ziegler)

> 1.Team just gone through the url given but still I am confused what is 
> the
> main purpose of making build_root directory, when we can compile our 
> source
> in different way.
> 2. May be I am not understanding the concept as I am  new to
> firmware concept. but question is also how the code is built and test 
> as a
> developer

As an embedded developer you would normally be seriously limited by the 
production hardware (where the finished product is supposed to run): not 
enough memory, no persistent storage, and just a serial console for 
talking to the machine. This is why people use different hardware for 
development and test/production.

On your development machine you would write code, do development tests, 
if necessary by using mock-ups for missing physical interfaces, and 
check in after you are satisfied.

The integration step pulls the software from the repository, packages it 
with other necessary binaries and generates a firmware image. This is 
where Buildroot comes into the picture. Buildroot is not a development 
environment, but an integration tool.

After deploying your image for integration testing on the target 
hardware, your options for debugging are limited. You could use, for 
example, instrumentation of the code or gdb (supports remote debugging) 
for this purpose.

It might make things easier if you told us something of your intended 
use case.

Kind regards,
Andreas

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Buildroot] Help: to understand build root
  2020-05-09 15:32 ` [Buildroot] Help: to understand build root Andreas Ziegler
@ 2020-05-09 18:14   ` Kunal Chauhan
  2020-05-09 18:54     ` Andreas Ziegler
  0 siblings, 1 reply; 5+ messages in thread
From: Kunal Chauhan @ 2020-05-09 18:14 UTC (permalink / raw)
  To: buildroot

Hi team,

Please need some clarity on some points

1.  If as a developer can i compile a single binary and test it without
running or compiling whole firware image.?

2. How firmware image extracts all binaries to system or to target harware?

Thanks
Kunal


On 9 May 2020 9:02 p.m., "Andreas Ziegler" <br015@umbiko.net> wrote:

> Hi Kunal,
>
> Message: 1
>> Date: Wed, 6 May 2020 12:24:57 +0530
>> From: Kunal Chauhan <atkunalchauhan@gmail.com>
>> To: buildroot at busybox.net
>> Subject: Re: [Buildroot] Help: to understand build root (Andreas
>>         Ziegler)
>>
>
> 1.Team just gone through the url given but still I am confused what is the
>> main purpose of making build_root directory, when we can compile our
>> source
>> in different way.
>> 2. May be I am not understanding the concept as I am  new to
>> firmware concept. but question is also how the code is built and test as a
>> developer
>>
>
> As an embedded developer you would normally be seriously limited by the
> production hardware (where the finished product is supposed to run): not
> enough memory, no persistent storage, and just a serial console for talking
> to the machine. This is why people use different hardware for development
> and test/production.
>
> On your development machine you would write code, do development tests, if
> necessary by using mock-ups for missing physical interfaces, and check in
> after you are satisfied.
>
> The integration step pulls the software from the repository, packages it
> with other necessary binaries and generates a firmware image. This is where
> Buildroot comes into the picture. Buildroot is not a development
> environment, but an integration tool.
>
> After deploying your image for integration testing on the target hardware,
> your options for debugging are limited. You could use, for example,
> instrumentation of the code or gdb (supports remote debugging) for this
> purpose.
>
> It might make things easier if you told us something of your intended use
> case.
>
> Kind regards,
> Andreas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20200509/51a25355/attachment.html>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Buildroot] Help: to understand build root
  2020-05-09 18:14   ` Kunal Chauhan
@ 2020-05-09 18:54     ` Andreas Ziegler
  0 siblings, 0 replies; 5+ messages in thread
From: Andreas Ziegler @ 2020-05-09 18:54 UTC (permalink / raw)
  To: buildroot

Hi Kunal,

I still have no clue what type of environment you are actually using, so 
part of this is just guessing.

On 2020-05-09 18:14, Kunal Chauhan wrote:
> Hi team,
> 
> Please need some clarity on some points
> 
> 1.  If as a developer can i compile a single binary and test it
> without running or compiling whole firware image.?

You can certainly modify and compile a single binary. If you have a 
running system, you can deploy it separately by copying it to it's 
proper location on the target system (e.g replace the last version with 
the new one). sftp is your friend.

> 2. How firmware image extracts all binaries to system or to target
> harware?

The internal structure of the firmware image depends on how it is built. 
A Buildroot image contains at least a Linux kernel and a root 
filesystem. Buildroot supports various formats, for example cpio, 
tarball or bootable disk image. A mechanism for auto-deployment is not 
included, normally you copy a file to a pre-determined location or use 
dd to flash a device.

Kind regards,
Andreas

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2020-05-09 18:54 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <mailman.3803.1589018066.59095.buildroot@busybox.net>
2020-05-09 15:32 ` [Buildroot] Help: to understand build root Andreas Ziegler
2020-05-09 18:14   ` Kunal Chauhan
2020-05-09 18:54     ` Andreas Ziegler
     [not found] <mailman.1722.1588710254.59095.buildroot@busybox.net>
2020-05-06  4:58 ` Andreas Ziegler
     [not found] <CACEFAc1QeQku=aibzMQe=2HFBvyzwPOgShZTUoV17SHtCVXOPA@mail.gmail.com>
     [not found] ` <CACEFAc01hFsebRqH5diNd2_8J6AGHczkBB3EJgh93OB139WWug@mail.gmail.com>
     [not found]   ` <CACEFAc3T1xqV8iUhOokt1cWUNY=TOoEWR+ULE8h9YXKGWew1KA@mail.gmail.com>
     [not found]     ` <CACEFAc0DRGJW8ghzBVudK-cqd0Lx-hhgQ6GgiaPdeCLzLn21NQ@mail.gmail.com>
2020-05-05 16:59       ` Kunal Chauhan

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.