[yocto] do_fetch linux hangs after defconfig/conf-fragment change

[Matthias.Heise]

Hi all,

I'm quite new to yocto and currently am playing around with all kinds of basic 
functions and procedures of yocto to step by step learn and get to know yocto 
and bitbake.
Currently I'm trying to store the kernel config settings in some way in my 
layer to have it modular. So I read about config fragments. Unfortunately I 
can't test what I did as when running bitbake the do_fetch for the linux source 
is started and doesn't end. Even when enabling/disabling only one line in the 
defconfig file, which I tried as test, this happens. That isn't normal is it ? 
What can I do about this ?
Thank you,
Best regards,
Mat


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] do_fetch linux hangs after defconfig/conf-fragment change

[Matthias.Heise]

> -Ursprüngliche Nachricht-
> Von: Samuel Stirtzel [mailto:s.stirt...@googlemail.com]
> Gesendet: Freitag, 28. November 2014 11:09
> An: Heise, Matthias
> Cc: yocto@yoctoproject.org
> Betreff: Re: [yocto] do_fetch linux hangs after defconfig/conf-fragment
> change
> 
> 2014-11-28 10:29 GMT+01:00  :
> > Hi all,
> >
> >
> >
> > I’m quite new to yocto and currently am playing around with all kinds
> > of basic functions and procedures of yocto to step by step learn and
> > get to know yocto and bitbake.
> >
> > Currently I’m trying to store the kernel config settings in some way
> > in my layer to have it modular. So I read about config fragments.
> > Unfortunately I can’t test what I did as when running bitbake the
> > do_fetch for the linux source is started and doesn’t end. Even when
> > enabling/disabling only one line in the defconfig file, which I tried
> > as test, this happens. That isn’t normal is it ? What can I do about this ?
> >
> > Thank you,
> >
> > Best regards,
> >
> > Mat
> >
> 
> Hi,
> 
> you can increase the bitbake debug level with the "-D" flag, it can be used
> multiple times like:
> bitbake -DDD 
> 
> Usually this should show enough information to see what's going wrong.
> 
> 
> 
> --
> Regards
> Samuel

This is what I found :

DEBUG: Mirror fetch failure for url 
http://downloads.yoctoproject.org/mirror/sources/git2_github.com.wandboard-org.linux.git.tar.gz
 (original url: 
git://github.com/wandboard-org/linux.git;branch=wandboard_imx_3.10.17_1.0.1_ga)
DEBUG: Fetcher failure: Fetch command failed with exit code 8, output:
http://downloads.yoctoproject.org/mirror/sources/git2_github.com.wandboard-org.linux.git.tar.gz:
2014-11-28 11:11:09 ERROR 404: Not Found.

After that :

DEBUG: Trying Upstream
.
.
.

And then it hangs here :

Currently 1 running tasks (1000 of 1988):
0: linux-wandboard-3.10.17-r0 do_fetch (pid 7070)


The source seems to be not there, which is a problem, but I'm asking myself 
also why it is fetched again

Regards 
Mat
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] do_fetch linux hangs after defconfig/conf-fragment change

[Matthias.Heise]

> -Ursprüngliche Nachricht-
> Von: Samuel Stirtzel [mailto:s.stirt...@googlemail.com]
> Gesendet: Freitag, 28. November 2014 13:55
> An: Heise, Matthias
> Cc: yocto@yoctoproject.org
> Betreff: Re: [yocto] do_fetch linux hangs after defconfig/conf-fragment
> change
> 
> 2014-11-28 11:29 GMT+01:00  :
> 
> >
> > This is what I found :
> >
> > DEBUG: Mirror fetch failure for url
> >
> http://downloads.yoctoproject.org/mirror/sources/git2_github.com.wandb
> > oard-org.linux.git.tar.gz (original url:
> > git://github.com/wandboard-
> org/linux.git;branch=wandboard_imx_3.10.17_
> > 1.0.1_ga)
> > DEBUG: Fetcher failure: Fetch command failed with exit code 8, output:
> >
> http://downloads.yoctoproject.org/mirror/sources/git2_github.com.wandb
> oard-org.linux.git.tar.gz:
> > 2014-11-28 11:11:09 ERROR 404: Not Found.
> >
> > After that :
> >
> > DEBUG: Trying Upstream
> > .
> > .
> > .
> >
> > And then it hangs here :
> >
> > Currently 1 running tasks (1000 of 1988):
> > 0: linux-wandboard-3.10.17-r0 do_fetch (pid 7070)
> >
> >
> > The source seems to be not there, which is a problem, but I'm asking
> > myself also why it is fetched again
> >
> 
> It's only a warning if a mirror reports error 404.
> Looks like your company firewall blocks outgoing connections for the git
> protocol (TCP-Port 9418).
> 
> Can you manually clone the git repository in your console?
> E.g. git clone git://github.com/wandboard-org/linux.git
> 
> 
> --
> Regards
> Samuel

I made the git setting to replace git:// with https:// which at least worked 
once ...
But when trying to clone as you suggested I'm asked for username and password 
for github.com !?

Regards 
Mat
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] do_fetch linux hangs after defconfig/conf-fragment change

[Matthias.Heise]

> -Ursprüngliche Nachricht-
> Von: Samuel Stirtzel [mailto:s.stirt...@googlemail.com]
> Gesendet: Freitag, 28. November 2014 14:24
> An: Heise, Matthias
> Cc: yocto@yoctoproject.org
> Betreff: Re: [yocto] do_fetch linux hangs after defconfig/conf-fragment
> change
> 
> 2014-11-28 14:09 GMT+01:00  :
> >
> > I made the git setting to replace git:// with https:// which at least worked
> once ...
> > But when trying to clone as you suggested I'm asked for username and
> password for github.com !?
> >
> 
> Strange, it works for me... takes some time but doesn't ask for
> username/password.
> 
> 
> 
> 
> --
> Regards
> Samuel

I executed "bitbake -c clean linux_wandboard" and retried, then it worked 
again. But still for me the question is open why the sources are re-fetched 
only because I enable/disable kernel options (in menuconfig). Shouldn't this be 
just a matter of re-compiling ?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] add a user via recipe

[Matthias.Heise]

Hi there,

I'm still trying to add a user via recipe. The method with

inherit extrausers
EXTRA_USER_PARAMS = "useradd -p 
'\$6\$53uYm/0Fnll\$Nc0RbHSvqRrd63Tw98TO3V1n25ORK9oR4QHqRIriXzLy0il/7.LIacX7mz7RJ1tdPIWiCJLNyQa7dKBNURqEg1'
 fstuser;"

Does not work (no errors just no user in image), as well as this :

ROOTFS_POSTPROCESS_COMMAND += "add_a_user;"

add_a_user(){
 useradd -p 
'\$6\$53uYm/0Fnll\$Nc0RbHSvqRrd63Tw98TO3V1n25ORK9oR4QHqRIriXzLy0il/7.LIacX7mz7RJ1tdPIWiCJLNyQa7dKBNURqEg1'
 fstuser;
}

Which results in an error during bitbake :
useradd: /etc/passwd.23966: Permission denied
useradd cannot lock /etc/passwd; try again later

any ideas to that ?
thanks,
regards
Mat
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] add a user via recipe

[Matthias.Heise]

Hi ChenQui,

thanks very much for your reply, the ROOTFS_POSTPROCESS_COMMAND does work now 
with
"useradd -root ${IMAGE_ROOTFS} -p . " as you suggested

However with the EXTRA_USERS_PARAMS the user is now added (thanks to the 
removed typo) but I can't add a valid password, neither encrypted nor 
cleartext, with or without <'  ' > around it


Von: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] Im 
Auftrag von ChenQi
Gesendet: Montag, 1. Dezember 2014 10:43
An: yocto@yoctoproject.org
Betreff: Re: [yocto] add a user via recipe

On 12/01/2014 04:46 PM, 
matthias.he...@atlas-elektronik.com 
wrote:
Hi there,

I'm still trying to add a user via recipe. The method with

inherit extrausers
EXTRA_USER_PARAMS = "useradd -p 
'\$6\$53uYm/0Fnll\$Nc0RbHSvqRrd63Tw98TO3V1n25ORK9oR4QHqRIriXzLy0il/7.LIacX7mz7RJ1tdPIWiCJLNyQa7dKBNURqEg1'
 fstuser;"


EXTRA_USERS_PARAMS instead of EXTRA_USER_PARAMS

Also, clear password is supported. E.g.
EXTRA_USERS_PARAMS = "useradd -P 'hello' tester;"

Does not work (no errors just no user in image), as well as this :

ROOTFS_POSTPROCESS_COMMAND += "add_a_user;"

add_a_user(){
 useradd -p 
'\$6\$53uYm/0Fnll\$Nc0RbHSvqRrd63Tw98TO3V1n25ORK9oR4QHqRIriXzLy0il/7.LIacX7mz7RJ1tdPIWiCJLNyQa7dKBNURqEg1'
 fstuser;
}

Which results in an error during bitbake :
useradd: /etc/passwd.23966: Permission denied
useradd cannot lock /etc/passwd; try again later


You need to pass '--root xxx' option to it.

//Chen Qi


any ideas to that ?
thanks,
regards
Mat



-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] add a user via recipe

[Matthias.Heise]

Ok, the EXTRA_USERS_PARAMS method now also works, it was the typo with USER and 
USERS and an encrypted password with '  ' around it which is needed, strangely 
the encrypted string for one and the same password all of a sudden was 
different, after re-generating it, it worked

Von: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] Im 
Auftrag von ChenQi
Gesendet: Montag, 1. Dezember 2014 10:43
An: yocto@yoctoproject.org
Betreff: Re: [yocto] add a user via recipe

On 12/01/2014 04:46 PM, 
matthias.he...@atlas-elektronik.com 
wrote:
Hi there,

I'm still trying to add a user via recipe. The method with

inherit extrausers
EXTRA_USER_PARAMS = "useradd -p 
'\$6\$53uYm/0Fnll\$Nc0RbHSvqRrd63Tw98TO3V1n25ORK9oR4QHqRIriXzLy0il/7.LIacX7mz7RJ1tdPIWiCJLNyQa7dKBNURqEg1'
 fstuser;"


EXTRA_USERS_PARAMS instead of EXTRA_USER_PARAMS

Also, clear password is supported. E.g.
EXTRA_USERS_PARAMS = "useradd -P 'hello' tester;"


Does not work (no errors just no user in image), as well as this :

ROOTFS_POSTPROCESS_COMMAND += "add_a_user;"

add_a_user(){
 useradd -p 
'\$6\$53uYm/0Fnll\$Nc0RbHSvqRrd63Tw98TO3V1n25ORK9oR4QHqRIriXzLy0il/7.LIacX7mz7RJ1tdPIWiCJLNyQa7dKBNURqEg1'
 fstuser;
}

Which results in an error during bitbake :
useradd: /etc/passwd.23966: Permission denied
useradd cannot lock /etc/passwd; try again later


You need to pass '--root xxx' option to it.

//Chen Qi


any ideas to that ?
thanks,
regards
Mat



-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] how to start with custom interface/driver

[Matthias.Heise]

Hi all,

I'm aware of the fact, that this is probably not the right point to ask, but 
maybe you still can give me some hints and/or point me to the right place to 
ask.
What I would like to  do is to connect a certain interface-chip to the 
freescale imx6. I have a wandboard which doesn't use it, a new interface card 
could be made. The idea would be to use the flash interface as it provides data 
and address lines (so one could directly address the chip), a driver (x86) for 
that interface chip exists. So the task would be to have the driver control the 
chip via this certain interface and then incorporate this in a yocto-linux 
environment.
Any help and hint would be appreciated,
Thank you very much,
Regards,
Mat


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] u-boot precompiled ?

[Matthias.Heise]

Hi all,

I'm still trying to find out basic things about getting a system up and 
running. This question is about U-Boot, is it right that for example for my 
wandboard a pre-compiled *.imx is just downloaded ?
So if I want to make settings to U-Boot I make them directly in the source, 
compile it and re-direct in a recipe to take that new file as bootloader ? Or 
can I make the settings within a recipe and I just didn't find the spot ?
Thanks for your time,
Regards
Mat
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] u-boot precompiled ?

[Matthias.Heise]

Even if this is a stupid question a little advise would be nice ... like "don't 
ask so stupid questions, go read this and that" or something... no time ? 
Should I rather unsubscribe from this list until I'm an expert?

Von: Heise, Matthias
Gesendet: Mittwoch, 3. Dezember 2014 15:15
An: 'yocto@yoctoproject.org'
Betreff: u-boot precompiled ?

Hi all,

I'm still trying to find out basic things about getting a system up and 
running. This question is about U-Boot, is it right that for example for my 
wandboard a pre-compiled *.imx is just downloaded ?
So if I want to make settings to U-Boot I make them directly in the source, 
compile it and re-direct in a recipe to take that new file as bootloader ? Or 
can I make the settings within a recipe and I just didn't find the spot ?
Thanks for your time,
Regards
Mat
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] u-boot precompiled ?

[Matthias.Heise]

Hello Matt,

thanks very much for your reply, I was able to create a simple patch changing 
an u-boot setting as test and "bbappended" it. I just didn't believe before 
that the various u-boot settings are "hard-coded" but they obviously are in the 
".h", so patching it seems to be the only way for changing settings from 
within yocto, right?
Regards,
Mat

Von: Matt Schuckmann [mailto:matt.schuckm...@planar.com]
Gesendet: Donnerstag, 4. Dezember 2014 18:31
An: Heise, Matthias; yocto@yoctoproject.org
Betreff: RE: u-boot precompiled ?

Mat,

I'm fairly new to OpenEmbedded (4 months now and I still feel like a noobi but 
I'm trying to give back while the pain is still fresh in my mind)
For something like u-boot it kind of depends on what your changing. If you need 
to change the u-boot code and the changes are small then typically you'd create 
a patch f for your changes and then make them part of a .bbappend in your layer 
for the recipe. There are examples on the net for how to create a .bbappend and 
reference the patch file.

Generally your .bbappend can be as simple as:

FILESEXTRAPATHS_prepend = ":${THISDIR}/files"
SRC_URI += "files://xyzzy.patch"

Where your patches are in subdirectory of your recipe directory.

Remember that generally recipes are about how to obtain the code, build it and 
package it for distribution, you can do recipes that deal with a pre-built 
binary but that is generally not the case.

Hope this helps,

Matt S.



From: yocto-boun...@yoctoproject.org 
[mailto:yocto-boun...@yoctoproject.org] On Behalf Of 
matthias.he...@atlas-elektronik.com
Sent: Thursday, December 04, 2014 1:49 AM
To: yocto@yoctoproject.org
Subject: Re: [yocto] u-boot precompiled ?

Even if this is a stupid question a little advise would be nice ... like "don't 
ask so stupid questions, go read this and that" or something... no time ? 
Should I rather unsubscribe from this list until I'm an expert?

Von: Heise, Matthias
Gesendet: Mittwoch, 3. Dezember 2014 15:15
An: 'yocto@yoctoproject.org'
Betreff: u-boot precompiled ?

Hi all,

I'm still trying to find out basic things about getting a system up and 
running. This question is about U-Boot, is it right that for example for my 
wandboard a pre-compiled *.imx is just downloaded ?
So if I want to make settings to U-Boot I make them directly in the source, 
compile it and re-direct in a recipe to take that new file as bootloader ? Or 
can I make the settings within a recipe and I just didn't find the spot ?
Thanks for your time,
Regards
Mat
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] u-boot precompiled ?

[Matthias.Heise]

> -Ursprüngliche Nachricht-
> Von: yocto-boun...@yoctoproject.org [mailto:yocto-
> boun...@yoctoproject.org] Im Auftrag von Gary Thomas
> Gesendet: Freitag, 5. Dezember 2014 15:22
> An: yocto@yoctoproject.org
> Betreff: Re: [yocto] u-boot precompiled ?
> 
> On 2014-12-05 05:48, matthias.he...@atlas-elektronik.com wrote:
> > Hello Matt,
> >
> > thanks very much for your reply, I was able to create a simple patch
> > changing an u-boot setting as test and "bbappended" it. I just didn't
> believe before that the various u-boot settings are "hard-coded" but they
> obviously are in the ".h", so patching it seems to be the only way for
> changing settings from within yocto, right?
> 
> What U-Boot settings are you asking about?

Starting with setting the boot-delay, via disabling the console, to setting up 
nfs- or other network-boot with it's parameters , or other boot sources

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] nfs-boot problem

[Matthias.Heise]

Hello,

I'm struggling getting my wandboard booting via tftp/nfs.
The first part was easy I just set up the tftp server and pointed it to the 
kernel image and *.dtb file,
in the wandboard.h of u-boot I set

#define CONFIG_BOOTCOMMAND \
   "run netboot;"

The kernel starts ok I think :

U-Boot 2014.10+fslc+g5fd0b60 (Dec 09 2014 - 11:39:57)

CPU:   Freescale i.MX6Q rev1.2 at 792 MHz
Reset cause: POR
Board: Wandboard
I2C:   ready
DRAM:  2 GiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1
*** Warning - bad CRC, using default environment

auto-detected panel HDMI
Display: HDMI (1024x768)
In:serial
Out:   serial
Err:   serial
Net:   FEC [PRIME]
Hit any key to stop autoboot:  0
Booting from net ...
BOOTP broadcast 1
DHCP client bound to address 10.42.0.84 (3 ms)
Using FEC device
TFTP from server 10.42.0.1; our IP address is 10.42.0.84
Filename 'zImage'.
Load address: 0x1200
Loading: #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 
 8.4 MiB/s
done
Bytes transferred = 5442656 (530c60 hex)
BOOTP broadcast 1
DHCP client bound to address 10.42.0.84 (2 ms)
Using FEC device
TFTP from server 10.42.0.1; our IP address is 10.42.0.84
Filename 'imx6q-wandboard.dtb'.
Load address: 0x1800
Loading: #
 4.1 MiB/s
done
Bytes transferred = 43370 (a96a hex)
Kernel image @ 0x1200 [ 0x00 - 0x530c60 ]
## Flattened Device Tree blob at 1800
   Booting using the fdt blob at 0x1800
   Using Device Tree in place at 1800, end 1800d969

Starting kernel ...

Booting Linux on physical CPU 0x0
Linux version 3.10.17-1.0.1-wandboard+ga6e7fc5 (theuser@debianDevHost) (gcc 
version 4.9.1 (GCC) ) #1 SMP PREEMPT Fri Nov 28 15:51:4
CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: Freescale i.MX6 Quad/DualLite (Device Tree), model: Wandboard Quad 
based on Freescale i.MX6 Quad
Truncating RAM at 1000-8fff to -7f7f (vmalloc region overlap).
cma: CMA: reserved 256 MiB at 6e00
Memory policy: ECC disabled, Data cache writealloc
PERCPU: Embedded 8 pages/cpu @81b57000 s8832 r8192 d15744 u32768
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 453136
Kernel command line: console=ttymxc0,115200 root=/dev/nfs ip=dhcp 
nfsroot=:,v3,tcp
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 262144 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 131072 (order: 7, 524288 bytes)
Memory: 1784MB = 1784MB total
Memory: 1534420k/1534420k available, 292396k reserved, 0K highmem
Virtual kernel memory layout:
vector  : 0x - 0x1000   (   4 kB)
fixmap  : 0xfff0 - 0xfffe   ( 896 kB)
vmalloc : 0xf000 - 0xff00   ( 240 MB)
lowmem  : 0x8000 - 0xef80   (1784 MB)
modules : 0x7f00 - 0x8000   (  16 MB)
  .text : 0x80008000 - 0x80c429c8   (12523 kB)
  .init : 0x80c43000 - 0x80c87280   ( 273 kB)
  .data : 0x80c88000 - 0x80cd9700   ( 326 kB)
   .bss : 0x80cd9700 - 0x80d3e8b8   ( 405 kB)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
Preemptible hierarchical RCU implementation.

.

then it tries to get the rootfs which fails. On the host I set up the nfs 
server and made some tests - it is accessible.

VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
snvs_rtc 20cc034.snvs-rtc-lp: setting system clock to 1970-01-01 00:00:01 UTC 
(1)
fec 2188000.ethernet eth0: Freescale FEC PHY driver [Generic PHY] 
(mii_bus:phy_addr=2188000.ethernet:01, irq=-1)
IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
libphy: 2188000.ethernet:01 - Link is Up - 1000/Full
IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Sending DHCP requests ., OK
IP-Config: Got DHCP answer from 10.42.0.1, my address

Re: [yocto] nfs-boot problem

[Matthias.Heise]

Hello Jim,
thank you for your reply, yes in the meantime I found out why that nfsroot path 
isn't set correctly, there is a wrong line in the "wandboard.h" in u-boot.
Now the regarding line looks like this
Kernel command line: console=ttymxc0,115200 root=/dev/nfs ip=dhcp 
nfsroot=192.168.1.1:/home/theuser/linktorootfs,v3,tcp
Which seems to be correct as the system starts now. The "rootpath" however is 
still empty.
The remaining problem I have is a write problem, somewhere a "rw" setting seems 
to be missing, although the "mount" command tells that the filesystem is 
mounted "rw".
As to the rootfs, this folder
fsl-community-bsp/build/tmp/work/wandboard_quad-poky-linux-gnueabi/core-image-minimal/1.0-r0/rootfs
seems to be exactly the structure that is packed into the image.tar.bz2 so I 
thought it is a good idea to directly use it as nfs share. Is there some reason 
not to do so ?
Thank you
Regards,
Mat



Von: Jim Rafert [mailto:j...@spectralogic.com]
Gesendet: Dienstag, 9. Dezember 2014 17:28
An: Heise, Matthias; yocto@yoctoproject.org
Betreff: RE: [yocto] nfs-boot problem

Hi Matthias,

Sorry, I missed the kernel command line in all the other gobbledy-gook put out 
by the boot.
Kernel command line: console=ttymxc0,115200 root=/dev/nfs ip=dhcp 
nfsroot=:,v3,tcp
That doesn't look right to me.

-Jim-



From: 
matthias.he...@atlas-elektronik.com 
[matthias.he...@atlas-elektronik.com]
Sent: Tuesday, December 09, 2014 5:17 AM
To: yocto@yoctoproject.org
Subject: [yocto] nfs-boot problem
Hello,

I'm struggling getting my wandboard booting via tftp/nfs.
The first part was easy I just set up the tftp server and pointed it to the 
kernel image and *.dtb file,
in the wandboard.h of u-boot I set

#define CONFIG_BOOTCOMMAND \
   "run netboot;"

The kernel starts ok I think :

U-Boot 2014.10+fslc+g5fd0b60 (Dec 09 2014 - 11:39:57)

CPU:   Freescale i.MX6Q rev1.2 at 792 MHz
Reset cause: POR
Board: Wandboard
I2C:   ready
DRAM:  2 GiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1
*** Warning - bad CRC, using default environment

auto-detected panel HDMI
Display: HDMI (1024x768)
In:serial
Out:   serial
Err:   serial
Net:   FEC [PRIME]
Hit any key to stop autoboot:  0
Booting from net ...
BOOTP broadcast 1
DHCP client bound to address 10.42.0.84 (3 ms)
Using FEC device
TFTP from server 10.42.0.1; our IP address is 10.42.0.84
Filename 'zImage'.
Load address: 0x1200
Loading: #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 
 8.4 MiB/s
done
Bytes transferred = 5442656 (530c60 hex)
BOOTP broadcast 1
DHCP client bound to address 10.42.0.84 (2 ms)
Using FEC device
TFTP from server 10.42.0.1; our IP address is 10.42.0.84
Filename 'imx6q-wandboard.dtb'.
Load address: 0x1800
Loading: #
 4.1 MiB/s
done
Bytes transferred = 43370 (a96a hex)
Kernel image @ 0x1200 [ 0x00 - 0x530c60 ]
## Flattened Device Tree blob at 1800
   Booting using the fdt blob at 0x1800
   Using Device Tree in place at 1800, end 1800d969

Starting kernel ...

Booting Linux on physical CPU 0x0
Linux version 3.10.17-1.0.1-wandboard+ga6e7fc5 (theuser@debianDevHost) (gcc 
version 4.9.1 (GCC) ) #1 SMP PREEMPT Fri Nov 28 15:51:4
CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: Freescale i.MX6 Quad/DualLite (Device Tree), model: Wandboard Quad 
based on Freescale i.MX6 Quad
Truncating RAM at 1000-8fff to -7f7f (vmalloc region overlap).
cma: CMA: reserved 256 MiB at 6e00
Memory policy: ECC disabled, Data cache writealloc
PERCPU: Embedded 8 pages/cpu @81b57000 s8832 r8192 d15744 u32768
Built 1 zonelists in Zone order, mobility grouping 

Re: [yocto] nfs-boot problem

[Matthias.Heise]

Update :

1.   I added a "rw" obviously at the right place as the nfs filesystem 
isn't marked as read-only anymore. Still there obviously is some write/rights 
issue as I get a lot of permission-related logs.  (see below)

2.   About the rootfs : I tried the unpacked filesystem from the *.tar.bz2  
and it doesn't work...(process just stops after the ALSA device list) why 
wouldn't it ?

Do you have any ideas to that ?

Thank you

Regards,

Mat



IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

IP-Config: Guessing netmask 255.255.255.0

IP-Config: Complete:

 device=eth0, hwaddr=00:1f:7b:b4:12:00, ipaddr=192.168.1.2, 
mask=255.255.255.0, gw=255.255.255.255

 host=192.168.1.2, domain=, nis-domain=(none)

 bootserver=255.255.255.255, rootserver=192.168.1.1, rootpath=

ALSA device list:

  #0: imx6-wandboard-sgtl5000

  #1: imx-spdif

  #2: imx-hdmi-soc

VFS: Mounted root (nfs filesystem) on device 0:11.

devtmpfs: mounted

Freeing unused kernel memory: 272K (80c43000 - 80c87000)

INIT: version 2.88 booting

Starting udev

udevd[171]: starting version 182

bootlogd: cannot allocate pseudo tty: No such file or directory

urandom start: failed.

Populating dev cache

/etc/rcS.d/S36udev-cache: line 33: /etc/udev-cache.tar.gz: Permission denied

/etc/rcS.d/S37populate-volatile.sh: line 56: /etc/volatile.cache.build: 
Permission denied

/etc/rcS.d/S37populate-volatile.sh: line 56: /etc/volatile.cache.build: 
Permission denied

/etc/rcS.d/S37populate-volatile.sh: line 56: /etc/volatile.cache.build: 
Permission denied

/etc/rcS.d/S37populate-volatile.sh: line 86: /etc/volatile.cache.build: 
Permission denied

/etc/rcS.d/S37populate-volatile.sh: line 86: /etc/volatile.cache.build: 
Permission denied

/etc/rcS.d/S37populate-volatile.sh: line 86: /etc/volatile.cache.build: 
Permission denied

/etc/rcS.d/S37populate-volatile.sh: line 86: /etc/volatile.cache.build: 
Permission denied

/etc/rcS.d/S37populate-volatile.sh: line 86: /etc/volatile.cache.build: 
Permission denied

/etc/rcS.d/S37populate-volatile.sh: line 56: /etc/volatile.cache.build: 
Permission denied

rm: can't remove '/tmp': Permission denied

ln: /tmp/tmp: Permission denied

/etc/rcS.d/S37populate-volatile.sh: line 33: /etc/volatile.cache.build: 
Permission denied

/etc/rcS.d/S37populate-volatile.sh: line 33: /etc/volatile.cache.build: 
Permission denied

/etc/rcS.d/S37populate-volatile.sh: line 86: /etc/volatile.cache.build: 
Permission denied

ln: /etc/resolv.conf: Permission denied

/etc/rcS.d/S37populate-volatile.sh: line 33: /etc/volatile.cache.build: 
Permission denied

/etc/rcS.d/S37populate-volatile.sh: line 33: /etc/volatile.cache.build: 
Permission denied

/etc/rcS.d/S37populate-volatile.sh: line 56: /etc/volatile.cache.build: 
Permission denied

/etc/rcS.d/S37populate-volatile.sh: line 33: /etc/volatile.cache.build: 
Permission denied

Wed Dec 10 10:00:44 UTC 2014

INIT: Entering runlevel: 5

Configuring network interfaces... ifup skipped for nfsroot interface eth0

run-parts: /etc/network/if-pre-up.d/nfsroot exited with code 1

mkdir: can't create directory '/etc/ssh': Permission denied

Starting rpcbind daemon...done.

creating NFS state directory: mkdir: can't create directory '/var/lib/nfs': 
Permission denied

mkdir: can't create directory 'rpc_pipefs': Permission denied

mkdir: can't create directory 'sm': Permission denied

mkdir: can't create directory 'sm.bak': Permission denied

mkdir: can't create directory 'statd': Permission denied

chown: sm: No such file or directory

chown: sm.bak: No such file or directory

chown: statd: Operation not permitted

rm: can't remove 'statd/state': Permission denied

/etc/rc5.d/S19nfscommon: line 42: statd/state: Permission denied

chown: /var/lib/nfs: Operation not permitted

done

starting statd: done

Starting syslogd/klogd: done



Poky (Yocto Project Reference Distro) 1.7 wandboard-quad /dev/ttymxc0



wandboard-quad login:



Von: Heise, Matthias
Gesendet: Mittwoch, 10. Dezember 2014 09:31
An: 'Jim Rafert'; yocto@yoctoproject.org
Betreff: AW: [yocto] nfs-boot problem

Hello Jim,
thank you for your reply, yes in the meantime I found out why that nfsroot path 
isn't set correctly, there is a wrong line in the "wandboard.h" in u-boot.
Now the regarding line looks like this
Kernel command line: console=ttymxc0,115200 root=/dev/nfs ip=dhcp 
nfsroot=192.168.1.1:/home/theuser/linktorootfs,v3,tcp
Which seems to be correct as the system starts now. The "rootpath" however is 
still empty.
The remaining problem I have is a write problem, somewhere a "rw" setting seems 
to be missing, although the "mount" command tells that the filesystem is 
mounted "rw".
As to the rootfs, this folder
fsl-community-bsp/build/tmp/work/wandboard_quad-poky-linux-gnueabi/core-image-minimal/1.0-r0/rootfs
seems to be exactly the structure that is packed into the image.tar.bz2 so I 
thought it is a good idea to directly use it as nfs share. Is there some reason 
not to do so ?
Thank you
Regards,
Mat

Re: [yocto] nfs-boot problem

[Matthias.Heise]

Hi Anders,

> -Ursprüngliche Nachricht-
> Von: Anders Darander [mailto:and...@chargestorm.se]
> Gesendet: Mittwoch, 10. Dezember 2014 11:24
> An: Heise, Matthias
> Cc: j...@spectralogic.com; yocto@yoctoproject.org
> Betreff: Re: [yocto] nfs-boot problem
> 
> * matthias.he...@atlas-elektronik.com  elektronik.com> [141210 09:35]:
> > As to the rootfs, this folder
> > fsl-community-bsp/build/tmp/work/wandboard_quad-poky-linux-
> gnueabi/cor
> > e-image-minimal/1.0-r0/rootfs seems to be exactly the structure that
> > is packed into the
> > image.tar.bz2 so I thought it is a good idea to directly use it as nfs
> > share. Is there some reason not to do so ?
> 
> Well, there're quite few. For instance file and directory ownership,
> permissions etc.
 
Yes, I can see that

>If you're not using devtmpfs, and thus would like static
> device nodes, they wouldn't be created in the build directory.

This is a little beyond my horizon, if you don't mind, could you please explain 
this a little, I may be lacking some knowledge here... sorry

 
> Thus, you really should be using the tarball when you want to run an nfsroot.

Tried again but again it didn't work, do you have an idea what could be wrong ?

> Cheers,
> Anders
> 
> --
> Anders Darander
> ChargeStorm AB / eStorm AB

Regards,
Mat
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] nfs-boot problem

[Matthias.Heise]

> -Ursprüngliche Nachricht-
> Von: Anders Darander [mailto:and...@chargestorm.se]
> Gesendet: Mittwoch, 10. Dezember 2014 12:17
> An: Heise, Matthias
> Cc: j...@spectralogic.com; yocto@yoctoproject.org
> Betreff: Re: [yocto] nfs-boot problem
> 
> * matthias.he...@atlas-elektronik.com  elektronik.com> [141210 11:48]:
> > > -Ursprüngliche Nachricht-
> > > Von: Anders Darander [mailto:and...@chargestorm.se]
> > > Gesendet: Mittwoch, 10. Dezember 2014 11:24
> > > An: Heise, Matthias
> > > Cc: j...@spectralogic.com; yocto@yoctoproject.org
> > > Betreff: Re: [yocto] nfs-boot problem
> 
> > > * matthias.he...@atlas-elektronik.com  > > elektronik.com> [141210 09:35]:
> > > > As to the rootfs, this folder
> > > > fsl-community-bsp/build/tmp/work/wandboard_quad-poky-linux-
> > > gnueabi/cor
> > > > e-image-minimal/1.0-r0/rootfs seems to be exactly the structure
> > > > that is packed into the
> > > > image.tar.bz2 so I thought it is a good idea to directly use it as
> > > > nfs share. Is there some reason not to do so ?
> 
> > > Well, there're quite few. For instance file and directory ownership,
> > > permissions etc.
> 
> > Yes, I can see that
> 
> > >If you're not using devtmpfs, and thus would like static  device
> > >nodes, they wouldn't be created in the build directory.
> 
> > This is a little beyond my horizon, if you don't mind, could you
> > please explain this a little, I may be lacking some knowledge here...
> > sorry
> 
> Well, nowadays most people are letting the kernel create the device nodes
> itself (possibly with some extra help from udev/mdev). Though, on really tiny
> systems you might still want to manually create all device nodes statically
> during image create time. In that special case, the device node names will be
> available in the build directory .../rootfs, but they will be regular files, 
> not
> device nodes.

Ah, ok , thank you.

> 
> If you don't know about this, it's quite likely you don't have to bother with
> this at the moment.
> 

Ok ;-)


> > > Thus, you really should be using the tarball when you want to run an
> nfsroot.
> 
> > Tried again but again it didn't work, do you have an idea what could be
> wrong ?
> 
> What steps have you taken?
> 
> How have you unpacked and exported the rootfs?
> 
> If you have export e.g. /export/rootfs, it's usually enough (for a simple 
> image
> at least) to run `sudo tar xf rootfs.tar.bz2`.
> 

I did unpack and copy to correct location but didn't know I'd have to re-run 
"exportfs" after changing the directory (I just switched a link from the other 
working-but-not-advisable-rootfs to the unpacked tar.bz2 ). After doing so it 
works, thank you !
I only have some permission issues left, don't know if they are important :

INIT: version 2.88 booting
Starting udev
udevd[171]: starting version 182
bootlogd: cannot allocate pseudo tty: No such file or directory
Populating dev cache
mv: can't preserve ownership of '/etc/udev/cache.data': Operation not permitted
INIT: Entering runlevel: 5
Configuring network interfaces... ifup skipped for nfsroot interface eth0
run-parts: /etc/network/if-pre-up.d/nfsroot exited with code 1
Starting OpenBSD Secure Shell server: sshd
  generating ssh RSA key...
  generating ssh ECDSA key...
  generating ssh DSA key...
  generating ssh ED25519 key...
done.
Starting rpcbind daemon...done.
creating NFS state directory: chown: sm: Operation not permitted
chown: sm.bak: Operation not permitted
chown: statd: Operation not permitted
chown: /var/lib/nfs: Operation not permitted
done
starting statd: done
Starting syslogd/klogd: done

Poky (Yocto Project Reference Distro) 1.7 wandboard-quad /dev/ttymxc0

wandboard-quad login:

> Cheers,
> Anders
> --
> Anders Darander
> ChargeStorm AB / eStorm AB

Thank you,
regards,
Mat
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] can't pull any sources anymore

[Matthias.Heise]

Hi,

I'm not able to pull any sources for a little time now. As test I re-tried an 
already working setup by again following some tutorial and trying to setup a 
fresh repo. The repo init works but the sync fails. I should mention that due 
to network limitations I replace git:// urls with https:// . Is it possible 
that this doesn't work anymore (I mean it is replaced but maybe the online 
repos don't support it anymore seamlessly)?
Thanks

Mat

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] can't pull any sources anymore

[Matthias.Heise]

Hello Saul,



thanks for your reply, I'm running the "repo init" command as in many 
tutorials, this is the line :

repo init -u https://github.com/Freescale/fsl-community-bsp-platform -b dizzy



after the init I find following in the manifest.xml :







  

  

  

  



  

  

  



  





  



  

  

  







So you can see it is git.yoctoproject.org as well as others.

When running repo sync which as I understand it actually pulls the sources I 
get :



Fetching project Documentation

Fetching project poky

Fetching project repo

Fetching project meta-fsl-arm-extra

fatal: Invalid gitfile format: 
/home/theuser/fsl-community-bsp_NEWTEST/.repo/repo/.git/clone.bundle

fatal: The remote end hung up unexpectedly

Fetching projects:  12% (1/8)  Fetching project fsl-community-bsp-base

Fetching projects:  25% (2/8)  Fetching project meta-fsl-arm

Fetching projects:  37% (3/8)  Fetching project meta-openembedded

Fetching projects:  50% (4/8)  Fetching project meta-fsl-demos

error: Failed connect to git.openembedded.org:443; Connection refused while 
accessing https://git.openembedded.org/meta-openembedded/info/refs

fatal: HTTP request failed

Fetching projects:  62% (5/8)  fatal: 
https://git.yoctoproject.org/poky/info/refs not found: did you run git 
update-server-info on the server?

fatal: https://git.yoctoproject.org/meta-fsl-arm/info/refs not found: did you 
run git update-server-info on the server?

error: Failed connect to git.openembedded.org:443; Connection refused while 
accessing https://git.openembedded.org/meta-openembedded/info/refs

fatal: HTTP request failed

fatal: https://git.yoctoproject.org/meta-fsl-arm/info/refs not found: did you 
run git update-server-info on the server?

fatal: https://git.yoctoproject.org/poky/info/refs not found: did you run git 
update-server-info on the server?

error: Cannot fetch meta-openembedded

error: Cannot fetch poky

error: Cannot fetch meta-fsl-arm



error: Exited sync due to fetch errors



and here I'm stuck ...



> -Ursprüngliche Nachricht-

> Von: Saul Wold [mailto:s...@linux.intel.com]

> Gesendet: Freitag, 9. Januar 2015 17:08

> An: Heise, Matthias; yocto@yoctoproject.org

> Betreff: Re: [yocto] can't pull any sources anymore

>

> On 01/09/2015 06:10 AM, 
> matthias.he...@atlas-elektronik.com
>  wrote:

> > Hi,

> >

> > I'm not able to pull any sources for a little time now. As test I re-tried 
> > an

> already working setup by again following some tutorial and trying to setup a

> fresh repo. The repo init works but the sync fails. I should mention that due

> to network limitations I replace git:// urls with https:// . Is it possible 
> that this

> doesn't work anymore (I mean it is replaced but maybe the online repos

> don't support it anymore seamlessly)?

>

> Can you be more specific, are you talking about the git repos at

> git.yoctoproject.org or some other git source?

>

> You say a "repo init works", does that mean an initial clone or ?  What

> commands are you running?

>

> I think a little more information is needed here.

>

> Sau!

>

> > Thanks

> >

> > Mat

> >

> >

> >

> >
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] can't pull any sources anymore

[Matthias.Heise]

Hi Anders,

yes, in my git config I replace git:// with https:// I'm forced to do so as git 
doesn't go through the company network. If I change the url in the manifest.xml 
to 
https://git.yoctoproject.org/git/poky/ it works on that part but I didn't find 
out yet how the other links should look like for https:// . So the process 
breaks a little later again. I'm trying to get git cleared here but don't know 
how the chances are. Why must the urls be different for git and https ? ... ;-)
thanks,
Mat

> -Ursprüngliche Nachricht-
> Von: Anders Darander [mailto:and...@chargestorm.se]
> Gesendet: Montag, 12. Januar 2015 14:04
> An: Heise, Matthias
> Cc: s...@linux.intel.com; yocto@yoctoproject.org
> Betreff: Re: [yocto] can't pull any sources anymore
> 
> 
> * matthias.he...@atlas-elektronik.com  elektronik.com> [150112 08:22]:
> > thanks for your reply, I'm running the "repo init" command as in many
> tutorials, this is the line :
> 
> > repo init -u https://github.com/Freescale/fsl-community-bsp-platform
> > -b dizzy
> 
> I've just tried to replicate your steps, and everything works OK.
> 
> > after the init I find following in the manifest.xml :
> 
> >  
> >   
> >   
> 
> Look here, git://git.yoctoproject.org, which should be OK.
> 
> ...SNIP...
> > 
> 
> 
> 
> > So you can see it is git.yoctoproject.org as well as others.
> 
> > When running repo sync which as I understand it actually pulls the sources I
> get :
> 
> 
> 
> > Fetching project Documentation
> 
> > Fetching project poky
> 
> > Fetching project repo
> 
> > Fetching project meta-fsl-arm-extra
> 
> > fatal: Invalid gitfile format:
> > /home/theuser/fsl-community-
> bsp_NEWTEST/.repo/repo/.git/clone.bundle
> 
> > fatal: The remote end hung up unexpectedly
> 
> > Fetching projects:  12% (1/8)  Fetching project fsl-community-bsp-base
> 
> > Fetching projects:  25% (2/8)  Fetching project meta-fsl-arm
> 
> > Fetching projects:  37% (3/8)  Fetching project meta-openembedded
> 
> > Fetching projects:  50% (4/8)  Fetching project meta-fsl-demos
> 
> > error: Failed connect to git.openembedded.org:443; Connection refused
> > while accessing
> > https://git.openembedded.org/meta-openembedded/info/refs
> 
> > fatal: HTTP request failed
> 
> > Fetching projects:  62% (5/8)  fatal:
> https://git.yoctoproject.org/poky/info/refs not found: did you run git
> update-server-info on the server?
> 
> Look here, https://git.yoctoproject.org/poky... See that the protocol has
> been changed from git to https. Do you have any rules set up that in your git-
> configuration that rewrites URLs? The https:// URL should look like
> https://git.yoctoproject.org/git/poky/...
> 
> When `repo sync` works for me, I'm still getting the git:// URLs.
> 
> Cheers,
> Anders
> 
> --
> Anders Darander
> ChargeStorm AB / eStorm AB
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto