gmane.comp.embedded.ptxdist.oselas.community

Re: Problem while using PTXdist with external kernel dir

Michael Olbrich — 2012-05-15T09:22:16

Mostly because nobody changed it. For the typical workflow it doesn't
really matter. Right now the decision to use the source in local_src is
made long after the make dependencies are created and evaluated. Changing
that is a bit more complex.

I suggest you use a fixed version for the kernel-header package, so the
timestamp won't change. This was one of the reasons why we introduced this
package in the first place.

Michael

Re: Problem while using PTXdist with external kernel dir

Tim Jaacks — 2012-05-14T18:06:50

Ah, that is definitely a good hint! We indeed have a case, where the timestamp of the source tar-ball changes. Every time we do a release build, we replace the tar-ball with a new version.
However, this dependency is quite strange in my opinion: Why does PTXdist care about the kernel tar-ball when an external kernel tree is used? I already wondered why the package has to exist at all in this case. I would state, if an external kernel tree it is present, PTXdist should use it, independent on the presence or the md5 sum or the timestamp of the according tar-ball. Why is this implemented this way?

Tim

Re: NFS on the mini2440

Dave Festing — 2012-05-14T18:06:20


Thanks for the tip!  I do not recall having to do that with previous PTXdist
versions, although it has been almost a year since I first used NFS,  Maybe,
that information needs to go in the Quickstart guide.

Re: Problem while using PTXdist with external kernel dir

Michael Olbrich — 2012-05-14T16:50:32

No, I just leave the links. The links have the platform suffix, so that
this is possible.


kernel-header.get only depends on the source tar-ball. Maybe the timestamp
here changes?

Michael

Re: NFS on the mini2440

Juergen Beisert — 2012-05-14T12:54:20

Hi Dave,

Dave Festing wrote:

Hmm, seems I have forgotten to enable support to load the kernel via NFS 
protocol.

$ ptxdist menuconfig barebox
    [*] Networking Support --->
         [ ]   nfs support 

If you enable this entry, Barebox also "understands" the 'nfs' command to load 
the kernel via NFS protocol.

A common way to run your target completely via network is to use the TFTP 
protocol to load the kernel and NFS for the root filesystem. 
The "kernel_loc=nfs" is just a different way to load the kernel (and the 
corresponding command is currently disabled in Barebox as mentioned above).


For the NFS root case the kernel does not need an information what filesystem 
is in use: there is _N_etwork_F_ile_S_ystem only.

For the other sources (NAND, MMC) the user is free to select one of the 
available filesystems (for NAND UBIFS or JFFS2 for example, for MMC all other 
available filesystems). So, this information has to be forwarded to the 
kernel (most of the time autodetection does not work and bootin

Re: Problem while using PTXdist with external kernel dir

Tim Jaacks — 2012-05-14T11:38:01

Hi,


That sounds like a good idea. But can you select the kernel from a local
tree this way?


Yes, PTXCONF_PLATFORM is different for all platforms. The first stage
is kernel-header.get.

Tim

NFS on the mini2440

Dave Festing — 2012-05-14T11:01:08

Trying to set up NFS on another machine and have hit a problem:

.......
# autoboot settings
# can be either 'tftp', 'nfs', 'nand' or 'mmc'
kernel_loc=nfs
# can be either 'net', 'nand', 'initrd' or 'mmc'
rootfs_loc=net


running /env/bin/init...

Hit any key to stop autoboot:  0
Unknown command 'nfs' - try 'help'
mini2440:/ 

Well help doesn't list the options "nfs" or "mmc" and "net"


Also, there is no mention in the Quickstart guide for "rootfs_type", when using
NFS.  As I recall it is suppose to be jffs2 for NFS or is not required?

Thanks,
Dave

Re: Problem while using PTXdist with external kernel dir

Michael Olbrich — 2012-05-14T10:25:44

Hi,

On Thu, May 10, 2012 at 03:57:39PM +0200, Tim Jaacks wrote:

I usually have multiple scipts with
ptxdist --ptxconfig=... --platformconfig=... "$< at >"
that I call instead of ptxdist. This way I can avoid to select anything.


I think, that should not matter. Is PTXCONF_PLATFORM different for all
platforms?
What's the first kernel-header stage that is re-created?

Michael

Re: [ptxdist] Error building root file system usingPTXdist for Mini2440

Juergen Beisert — 2012-05-11T17:04:53

Hi Vishad,

Vishad Patel wrote:

\o/


From you last mail:

Did you extract the BSP on your Windows machine and then transfered it to the 
virtual machine? Maybe this destroys the 'end of line' encodings. This will 
end up with many funny error messages...


Thanks for the info.


You are welcome.

Regards,
Juergen

Re: [ptxdist] Error building root file system usingPTXdist for Mini2440

Juergen Beisert — 2012-05-11T06:08:27

Hi Vishad,

Vishad Patel wrote:

Looks sane.

I tried here the following with your files:

$ tar xf OSELAS.BSP-Pengutronix-Mini2440-2012.02.0.tgz
$ cd OSELAS.BSP-Pengutronix-Mini2440-2012.02.0
<replace the existing files with the ones you sent me>
$ ptxdist-2012.02.0 platform configs/platform-friendlyarm-mini2440/platformconfig-NAND-128M
info: selected platformconfig:
      'configs/platform-friendlyarm-mini2440/platformconfig-NAND-128M'
found and using toolchain:
'/opt/OSELAS.Toolchain-2011.11.1/arm-v4t-linux-gnueabi/gcc-4.6.2-glibc-2.14.1-binutils-2.21.1a-kernel-2.6.39-sanitized/bin
$ ptxdist-2012.02.0 select configs/ptxconfig
info: selected ptxconfig:
      'configs/ptxconfig'
$ ptxdist-2012.02.0 compile barebox

-------------------
target: barebox.get
-------------------

finished target barebox.get

-----------------------
target: barebox.extract
-----------------------

extract: pkg_src=/farhome/all_src/barebox-2011.05.0.tar.bz2
extract: pkg_extract_dir=OSELAS.BSP-Pengutronix-Mini2440-2012.02.0/platfor

Re: [ptxdist] Error building root file system usingPTXdist for Mini2440

Juergen Beisert — 2012-05-10T15:05:02

Hi Vishad,

Vishad Patel wrote:

Your build:
-----------

[...]
  CC      common/console.o
common/console.c: In function 'fprintf':
common/console.c:346:7: warning: variable 'i' set but not used [-Wunused-but-set-variable]
make[2]: *** No rule to make target `(copy)', needed by `barebox_default_env'.  Stop.

My build:
---------

[...]
  CC      common/console.o
common/console.c: In function 'fprintf':
common/console.c:346:7: warning: variable 'i' set but not used [-Wunused-but-set-variable]
saving contents of /tmp/tmp.9RKD04ginS to 
file /home/jb/work/Pengutronix/public_bsps/OSELAS.BSP-Pengutronix-Mini2440/platform-mini2440/build-target/barebox-2011.05.0/barebox_default_env
  CC      common/env.o
  CC      common/image.o
  CC      common/startup.o
  CC      common/misc.o
  CC      common/memsize.o
[...]

I guess you changed something in your platformconfig, didn't you?

Can you also send the used ptxconfig and platformconfig when you try to
build your BSP? Just to get an idea, what is different at your side.

Re: Problem while using PTXdist with external kernel dir

Tim Jaacks — 2012-05-10T13:57:39

Dear Michael,

thanks for the fast reply. We have automated switching between platforms in a bash script. It calls "ptxdist select", "ptxdist platform" and - besides some other stuff - creates the links to the kernel sources in local_src, as mentioned above. We do not want to keep these links all the time in order to keep the folder tidy, so we delete them when we switch to a different platform.
The platform specific options do not change. We can build the whole platform, do not change anything except for deleting and re-creating the external kernel tree links, and then kernel-headers get rebuilt on calling "ptxdist go". How can that be? Might it have anything to do with the timestamp of the links?

Best regards,
Tim

Re: Problem while using PTXdist with external kernel dir

Michael Olbrich — 2012-05-10T13:05:45

What does "switching between different platforms" mean? Different platforms
with different platformconfigs should have a differen <platform>-suffix.
You don't need to delete the links in local_src/ in that case.
Also note, that changes to the package specific options in platformconfig
trigger a rebuild of the package.

Michael

Re: [ptxdist] Error building root file system usingPTXdist for Mini2440

Juergen Beisert — 2012-05-10T11:43:22

Hi Vishad,

Vishad wrote:

Can you please try the following:

$ echo > platform-mini2440/logfile
$ ptxdist clean barebox
$ ptxdist targetinstall barebox

and send us the 'platform-mini2440/logfile'?

Regards,
Juergen

Problem while using PTXdist with external kernel dir

Tim Jaacks — 2012-05-10T09:39:36

Hello,

we are using PTXdist with an external kernel dir in local_src. The directories are correctly used, the extract step says " local directory instead of tar file, linking build dir". If we call "ptxdist go", the whole platform gets correctly built.
However, the directories we created (local_src/kernel.<platform> and local_src/kernel-header.<platform>) are only links to other places in our build tree. Sometimes we delete those links (when switching between different platforms) and re-create them later on (targeting the same, unchanged directory). If we now re-run "ptxdist go", the kernel-header package sometimes gets rebuilt, even though the state files are still present and nothing changed within the build tree. We have not managed to determine under which exact circumstances this happens, sometimes it gets rebuilt, sometimes not.
Does anybody have an idea, why this is the case and how we can prevent this? It is quite annoying, because we have a lot of packages which depend on the kernel headers, which

Re: [PATCH] Add QEMU as hosttool

Marc Kleine-Budde — 2012-05-08T17:05:39

you're right.

Marc

Re: [ptxdist] [PATCH] Add QEMU as hosttool

Marc Kleine-Budde — 2012-05-08T16:12:08

Where does it get PTXDIST_PLATFORMDIR from?

Marc

Re: [ptxdist] [PATCH] Add QEMU as hosttool

Bernhard Walle — 2012-05-08T15:50:55

Am 08.05.2012 09:12, schrieb Marc Kleine-Budde:

But configs/i586-qemu-2011.11.0/run isn't executed in
the ptxdist environment, is it?


Regards,
Bernhard

Re: [PATCH] Add QEMU as hosttool

Bernhard Walle — 2012-05-08T17:03:07

* Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ< at >public.gmane.org> [2012-05-08 18:12]:

From

  5 #
  6 # we need information about the platform
  7 #
  8 if [ ! -e "selected_platformconfig" ]; then
  9     echo "error: selected_platformconfig does not exist"
 10     echo "       please use 'ptxdist platform ...' or 'ptxdist --platformconfig=...'"
 11     exit 1
 12 fi
 13 
 14 source selected_platformconfig
 15 
 16 if [ -n "${PTXCONF_PLATFORM}" ]; then
 17     PTXDIST_PLATFORMDIR="./platform-${PTXCONF_PLATFORM}"
 18 else
 19     PTXDIST_PLATFORMDIR="."
 20 fi


Regards,
Bernhard

Re: [PATCH] Add QEMU as hosttool

Marc Kleine-Budde — 2012-05-08T07:12:38

sysroot-host/bin is part of the standard path within ptxdist.

Marc

[PATCH] Add QEMU as hosttool

Bernhard Walle — 2012-05-07T20:06:56

Build QEMU as part of the BSP and use our own QEMU in the startup
scripts.

Tested on Mac OS 10.7 and Arch Linux.

Signed-off-by: Bernhard Walle <bernhard-X9USDgGjgfuzQB+pC5nmwQ< at >public.gmane.org>
---
 configs/arm-qemu-2011.11.0/run                    |    2 +-
 configs/i586-qemu-2011.11.0/run                   |    8 +--
 configs/ptxconfig                                 |    1 +
 patches/qemu-1.0.1/0001-Fix-build-on-Mac-OS.patch |   72 +++++++++++++++++++++
 patches/qemu-1.0.1/series                         |    4 ++
 rules/host-qemu.in                                |    8 +++
 rules/host-qemu.make                              |   38 +++++++++++
 7 Dateien geändert, 125 Zeilen hinzugefügt(+), 8 Zeilen entfernt(-)
 create mode 100644 patches/qemu-1.0.1/0001-Fix-build-on-Mac-OS.patch
 create mode 100644 patches/qemu-1.0.1/series
 create mode 100644 rules/host-qemu.in
 create mode 100644 rules/host-qemu.make

diff --git a/configs/arm-qemu-2011.11.0/run b/configs/arm-qemu-2011.11.0/run
index a653ee4..d643e17