Re: [yocto] [meta-chip][RFC PATCH 3/3] chip: Add chip-u-boot-scr recipe and flash script

2017-06-18 Thread Trevor Woerner 
On Fri 2017-06-16 @ 05:15:40 PM, drew.mose...@mender.io wrote:
> +This script will take some time to execute.

true

> If you have a serial console connected to
> +your board, you will see the progress and a message on the console will 
> indicate when
> +the flashing is completed.

hmmm, never saw this. I have a console connected, the moment the script
started, on the console I got:

U-Boot SPL 2016.01 (Jun 19 2017 - 00:32:19)
DRAM: 512 MiB
CPU: 100800Hz, AXI/AHB/APB: 3/2/2
Trying to boot from

which looks right, the date+time are good.

Where I started the script I get:

# UBI_IMAGE=core-image-full-cmdline-chip.ubi
# tmp-glibc/deploy/images/chip/flash_CHIP_board.sh
100% []  3537 kB,  
557.5 kB/s 
100% []   616 kB,  
823.9 kB/s 
100% [] 2 kB,  
733.9 kB/s
100% [] 654311 kB,  
771.4 kB/s

> Additionally, once the image is properly flashed, the status
> +LED on the CHIP board will flash 30 times per second indicating that it is 
> safe to power
> +down your board and disable FEL mode.

I don't get any LED flashing, and nothing other than what I've pasted above on
the console.

Rebooting the board after flashing outside of FEL mode simply boots the
previous u-boot and image.

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

Re: [yocto] [meta-chip][RFC PATCH 3/3] chip: Add chip-u-boot-scr recipe and flash script

2017-06-18 Thread Trevor Woerner 
On Fri 2017-06-16 @ 05:15:40 PM, drew.mose...@mender.io wrote:
> diff --git a/README b/README
> index cccf59e..cf52e05 100644
> --- a/README
> +++ b/README
> @@ -59,4 +59,28 @@ To build a machine supported by this BSP layer follow the 
> next steps:

Please wrap the additions to the README to 80 columns.

>  II. Flashing a C.H.I.P. board
>  
>  
> -
> +As part of the build including this BSP layer, a U-Boot script and a shell 
> script
> +are created to assist in flashing your images to the CHIP board.  Note that 
> this
> +script assumes a maximum size for your UBI image of 0x0A00 bytes.  If 
> your UBI
> +image exceeds that, then you will need to adapt this to your environment.
> +
> +To successfully run this script you will first need to set your board into 
> FEL mode.
> +chip. https://docs.getchip.com/chip.html#flash-chip-with-an-os
> +Insert a wire into the U14 header between pin 7 (FEL) and GND.  Then connect 
> the
> +board with a USB cable to your build system.
> +
> +You need to specify the base filename of your UBI image using the UBI_IMAGE 
> shell
> +variable before invoking the generated script as follows:
> +
> +$ UBI_IMAGE=core-image-full-cmdline-chip.ubi 
> ./tmp/deploy/images/chip/flash_CHIP_board.sh

Outside of a udev tweak, this script needs to be run as root. It's traditional
to indicate commands run as root by prefixing them with a PS1 of '#'.

> +
> +This script will take some time to execute.  If you have a serial console 
> connected to
> +your board, you will see the progress and a message on the console will 
> indicate when
> +the flashing is completed. Additionally, once the image is properly flashed, 
> the status
> +LED on the CHIP board will flash 30 times per second indicating that it is 
> safe to power
> +down your board and disable FEL mode.
> +
> +WARNING: This will erase the entire contents of your CHIP board.
> +
> +NOTE: This setup is still compatible with the CHIP flashing utility available
> +at http://flash.getchip.com if you choose to reinstall the stock images.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-chip][RFC PATCH 2/3] chip: Build sunxi-tools-native.

2017-06-18 Thread Trevor Woerner 
On Fri, Jun 16, 2017 at 5:15 PM,   wrote:
> Add LAYERDEPENDS on meta-sunxi and add the sunxi-tools-native
> pacakage to EXTRA_IMAGEDEPENDS.


meta-chip's README should also indicate this dependency.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] RTL8192EU rev B (SMIC) ==> rtl8192eu_nic.bin ?

2017-06-18 Thread Riko Ho 

Hello Everyone,

How can I obtain : rtl8192eu_nic.bin?

I got this message :

RTL8192EU rev B (SMIC) 2T2R, TX queues 3, WiFi=1, BT=0, GPS=0, HI PA=0
usb 1-1: RTL8192EU MAC: 00:0b:81:a2:a5:60
usb 1-1: rtl8xxxu: Loading firmware rtlwifi/rtl8192eu_nic.bin
usb 1-1: Direct firmware load for rtlwifi/rtl8192eu_nic.bin failed with 
error -2

usb 1-1: request_firmware(rtlwifi/rtl8192eu_nic.bin) failed

Thanks,

On 18/06/17 15:49, Martin Jansa wrote:

You didn't say which versions you're using.

If you're using latest oe-core with gcc7 then you will need v3 version 
of this change:

http://lists.openembedded.org/pipermail/openembedded-devel/2017-June/113247.html
I'll send it later today.

> And how can I clean after building it ? It took about 70Gb of my drive

Like any other recipe:
bitbake -c clean foo

On Sun, Jun 18, 2017 at 1:41 AM, Riko Ho > wrote:


Hello Everyone,

I tried to compile chromium but never succeeded, took me already
12 hours and stopped on 99%,
I used bitbake for doing it,

Is chromium not compatible with arm CPU ? it was working with
X86_64 before.
And how can I clean after building it ? It took about 70Gb of my drive

Thanks
-- 
___

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





--
*

/***/
Sent by Ubuntu LTS 16.04,
谢谢,
Regards,
Riko Ho
/***/

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

Re: [yocto] dd image to sdcard ?

2017-06-18 Thread Riko Ho 

Thanks Guys,

I think this one will answer my question,

http://git.yoctoproject.org/cgit.cgi/poky/tree/README.hardware

Line 140...

|Texas Instruments Beaglebone (beaglebone) 
= ... Anyway I recompiled 
the image to get 'wic' file now. IMAGE_FSTYPES ="ext3 tar.bz2 wic" |



On 19/06/17 03:37, Maciej Borzęcki wrote:

On Sun, Jun 18, 2017 at 9:17 PM, Burton, Ross  wrote:

On 18 June 2017 at 12:48, Riko Ho  wrote:

Which one of these files can be downloaded by "dd" directly to SDcard ? or
how to write it to sdcard ?


The beaglebone BSP doesn't write a SD card image (although it probably
should now that wic exists).  Google has various pages explaining how a
beaglebone needs a SD card to be formatted,
https://github.com/linneman/planck/wiki/How-to-create-a-Boot-SD-Card-for-the-BeagleBone-black
was near the top of my search.


If you're using 'beaglebone' machine defined in meta-yocto-bsp, then
there is a corresponding wks file
https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-yocto-bsp/wic/beaglebone.wks
which should produce a bootable SD card image. Both `wic` and
`wic.bmap` are added to IMAGE_FSTYPES automatically.

Cheers,


--
*

/***/
Sent by Ubuntu LTS 16.04,
谢谢,
Regards,
Riko Ho
/***/

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

Re: [yocto] dd image to sdcard ?

2017-06-18 Thread Maciej Borzęcki 
On Sun, Jun 18, 2017 at 9:17 PM, Burton, Ross  wrote:
>
> On 18 June 2017 at 12:48, Riko Ho  wrote:
>>
>> Which one of these files can be downloaded by "dd" directly to SDcard ? or
>> how to write it to sdcard ?
>
>
> The beaglebone BSP doesn't write a SD card image (although it probably
> should now that wic exists).  Google has various pages explaining how a
> beaglebone needs a SD card to be formatted,
> https://github.com/linneman/planck/wiki/How-to-create-a-Boot-SD-Card-for-the-BeagleBone-black
> was near the top of my search.
>

If you're using 'beaglebone' machine defined in meta-yocto-bsp, then
there is a corresponding wks file
https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-yocto-bsp/wic/beaglebone.wks
which should produce a bootable SD card image. Both `wic` and
`wic.bmap` are added to IMAGE_FSTYPES automatically.

Cheers,
-- 
Maciej Borzecki
RnDity
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] dd image to sdcard ?

2017-06-18 Thread Burton, Ross 
On 18 June 2017 at 12:48, Riko Ho  wrote:

> Which one of these files can be downloaded by "dd" directly to SDcard ? or
> how to write it to sdcard ?
>

The beaglebone BSP doesn't write a SD card image (although it probably
should now that wic exists).  Google has various pages explaining how a
beaglebone needs a SD card to be formatted,
https://github.com/linneman/planck/wiki/How-to-create-a-Boot-SD-Card-for-the-BeagleBone-black
was near the top of my search.

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

Re: [yocto] [meta-raspberrypi][PATCH] sdcard_image-rpi.bbclass: deploy vfat partition

2017-06-18 Thread Matthew McClintock 
On Sat, Jun 17, 2017 at 11:41 AM, Khem Raj  wrote:
> On Sat, Jun 17, 2017 at 8:20 AM, Tom Rini  wrote:
>> On Fri, Jun 16, 2017 at 06:05:07PM -0700, Khem Raj wrote:
>>> On Fri, Jun 16, 2017 at 12:12 PM, Matthew McClintock
>>>  wrote:
>>> > This is useful to update the bootloader/vfat partition from u-boot when
>>> > you don't want to update everything:
>>> >
>>> > U-Boot> tftpboot 0x100 tmp/0VXje
>>> > Waiting for Ethernet connection... done.
>>> > Using sms0 device
>>> > TFTP from server 192.168.0.1; our IP address is 192.168.0.26
>>> > Filename 'image.vfat'.
>>> > Load address: 0x100
>>> > Loading: ##  40 MiB
>>> >  2.1 MiB/s
>>> > done
>>> > Bytes transferred = 41943040 (280 hex)
>>> > U-Boot> mmc part
>>> >
>>> > Partition Map for MMC device 0  --   Partition Type: DOS
>>> >
>>> > PartStart SectorNum Sectors UUIDType
>>> >   1 819281920   a63a4fbc-01 0c Boot
>>> >   2 90112   163840  a63a4fbc-02 83
>>> > U-Boot> mmc erase 0x2000 0x14000
>>> >
>>> > MMC erase: dev # 0, block # 8192, count 81920 ... 81920 blocks erased:
>>> > OK
>>> > U-Boot> mmc write 0x100 0x2000 0x14000
>>> >
>>> > MMC write: dev # 0, block # 8192, count 81920 ... 81920 blocks written:
>>> > OK
>>> > U-Boot>
>>> >
>>> > Signed-off-by: Matthew McClintock 
>>> > ---
>>> >  classes/sdcard_image-rpi.bbclass | 8 
>>> >  1 file changed, 8 insertions(+)
>>> >
>>> > diff --git a/classes/sdcard_image-rpi.bbclass 
>>> > b/classes/sdcard_image-rpi.bbclass
>>> > index af3e807..27a0dfc 100644
>>> > --- a/classes/sdcard_image-rpi.bbclass
>>> > +++ b/classes/sdcard_image-rpi.bbclass
>>> > @@ -72,6 +72,10 @@ SDIMG = 
>>> > "${IMGDEPLOYDIR}/${IMAGE_NAME}.rootfs.rpi-sdimg"
>>> >  # Additional files and/or directories to be copied into the vfat 
>>> > partition from the IMAGE_ROOTFS.
>>> >  FATPAYLOAD ?= ""
>>> >
>>> > +# SD card vfat partition image name
>>> > +SDIMG_VFAT = "${IMGDEPLOYDIR}/${IMAGE_NAME}.vfat"
>>> > +SDIMG_LINK_VFAT = "${IMGDEPLOYDIR}/${IMAGE_LINK_NAME}.vfat"
>>> > +
>>> >  IMAGE_CMD_rpi-sdimg () {
>>> >
>>> > # Align partitions
>>> > @@ -145,6 +149,10 @@ IMAGE_CMD_rpi-sdimg () {
>>> > echo "${IMAGE_NAME}" > ${WORKDIR}/image-version-info
>>> > mcopy -i ${WORKDIR}/boot.img -v ${WORKDIR}/image-version-info ::
>>> >
>>> > +# Deploy vfat partition
>>> > +cp ${WORKDIR}/boot.img ${SDIMG_VFAT}
>>> > +ln -sf ${SDIMG_VFAT} ${SDIMG_LINK_VFAT}
>>> > +
>>>
>>> it is of use if I am not using u-boot ? is there any penalty ?

Other than just having another thing copied into tmp there is no
effect, even if you're not using u-boot.

>>
>> The stock firmware also uses a vfat partition, so this could just as
>> easily hold those contents.
>
> yes it does, can it do the same operations like u-boot ?

Didn't see anything that lets you use networking and upgrade
partitions, etc like u-boot does.

FWIW using this to completely automate loading new images without the
need for a display or a local user.

The only remaining thing to sort out is the device tree, I'm having to
use the one passed for the first stage bootloader at the moment for
the board to come up right, I assume if I put a bad one there the
board might be bricked, once I sort out using a separate device tree
for just booting Linux I can update Linux and the device tree and
generally never need to worry about bricking a board.

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

Re: [yocto] Compiling meta-browser ==>chromium ? cleaning ?

2017-06-18 Thread Gunnar Andersson 

Riko Ho  wrote:

> Hello Everyone,
> 
> I tried to compile chromium but never succeeded, took me already 12 
> hours and stopped on 99%, I used bitbake for doing it,

Not sure what would cause it to just stop and it could have been some
temporary glitch?   Maybe you want to provide some logs of your build if
Martin's reference does not help.

> 
> Is chromium not compatible with arm CPU ? it was working with X86_64 
> before.

Is it a Wayland based project or X based desktop type?  

GENIVI worked with Igalia to update chromium support for Wayland.  You can
take a look at the feature branch for GENIVI Development Platform [1] if it
helps.  I think you'd need to work out why your build freezes completely
first, however.

Since it's a work in progress I don't guarantee that it is clean or easy to
follow yet.  A lot of workarounds and tweaks: [2]. We're temporarily on a
fork of ozone-wayland because of recent multi-screen support for example.

It builds and runs on Renesas R-Car generation 3 (64 bit ARMv8).  It builds
on Raspberry Pi as well but there's a runtime problem.  And of course x86_64
like e.g. Minnowboard.  It seems to need a few unique tweaks for every ARM
board so I guess it depends what you are doing.

Please feel free to help us get things extracted out of there and into meta-
browser and chromium or ozone upstream.  We're focusing first on fixing the
boards that don't work and then we'll know more what the final patches for
upstream should look like.

> And how can I clean after building it ? It took about 70Gb of my drive

You could also try  INHERIT += "rm_work"
see [3], item 4.


Hope this helps
- Gunnar

[1] https://github.com/genivi/genivi-dev-platform/tree/chromium/
[2] 
https://github.com/GENIVI/genivi-dev-platform/blob/chromium/meta-genivi-dev/meta-genivi-dev/recipes-extended/chromium/chromium-wayland_%25.bbappend
[3] 
http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#building-an-image-for-emulation
  

-- 
Gunnar Andersson 
Development Lead
GENIVI Alliance



> 
> Thanks

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

[yocto] dd image to sdcard ?

2017-06-18 Thread Riko Ho 

Hi Everyone,

Which one of these files can be downloaded by "dd" directly to SDcard ? 
or how to write it to sdcard ?


lrwxrwxrwx 1 bianchi77 bianchi77   61 Jun 18 19:34 
core-image-minimal-xfce-beaglebone.ext3 -> 
core-image-minimal-xfce-beaglebone-20170618070558.rootfs.ext3
lrwxrwxrwx 1 bianchi77 bianchi77   65 Jun 18 19:34 
core-image-minimal-xfce-beaglebone.manifest -> 
core-image-minimal-xfce-beaglebone-20170618070558.rootfs.manifest
lrwxrwxrwx 1 bianchi77 bianchi77   64 Jun 18 19:34 
core-image-minimal-xfce-beaglebone.tar.bz2 -> 
core-image-minimal-xfce-beaglebone-20170618070558.rootfs.tar.bz2


lrwxrwxrwx 1 bianchi77 bianchi77   25 Jun 18 18:17 MLO -> 
MLO-beaglebone-2017.01-r0
lrwxrwxrwx 1 bianchi77 bianchi77   25 Jun 18 18:17 MLO-beaglebone -> 
MLO-beaglebone-2017.01-r0

-rw-r--r-- 1 bianchi77 bianchi77  70K Jun 18 18:17 MLO-beaglebone-2017.01-r0
-rw-rw-r-- 2 bianchi77 bianchi77  48M Jun 18 19:21 
modules--4.10.9+git0+ad2e885015_fe0fb8da3d-r0-beaglebone-20170618070558.tgz
lrwxrwxrwx 2 bianchi77 bianchi77   75 Jun 18 19:21 
modules-beaglebone.tgz -> 
modules--4.10.9+git0+ad2e885015_fe0fb8da3d-r0-beaglebone-20170618070558.tgz
-rw-r--r-- 1 bianchi77 bianchi77 360K Jun 18 18:17 
u-boot-beaglebone-2017.01-r0.img
lrwxrwxrwx 1 bianchi77 bianchi77   32 Jun 18 18:17 u-boot-beaglebone.img 
-> u-boot-beaglebone-2017.01-r0.img
lrwxrwxrwx 1 bianchi77 bianchi77   32 Jun 18 18:17 u-boot.img -> 
u-boot-beaglebone-2017.01-r0.img
lrwxrwxrwx 2 bianchi77 bianchi77   74 Jun 18 19:21 zImage -> 
zImage--4.10.9+git0+ad2e885015_fe0fb8da3d-r0-beaglebone-20170618070558.bin
-rw-r--r-- 2 bianchi77 bianchi77  32K Jun 18 19:21 
zImage--4.10.9+git0+ad2e885015_fe0fb8da3d-r0-am335x-bone-20170618070558.dtb
-rw-r--r-- 2 bianchi77 bianchi77  34K Jun 18 19:21 
zImage--4.10.9+git0+ad2e885015_fe0fb8da3d-r0-am335x-boneblack-20170618070558.dtb
-rw-r--r-- 2 bianchi77 bianchi77 5.4M Jun 18 19:21 
zImage--4.10.9+git0+ad2e885015_fe0fb8da3d-r0-beaglebone-20170618070558.bin
lrwxrwxrwx 2 bianchi77 bianchi77   80 Jun 18 19:21 
zImage-am335x-boneblack.dtb -> 
zImage--4.10.9+git0+ad2e885015_fe0fb8da3d-r0-am335x-boneblack-20170618070558.dtb
lrwxrwxrwx 2 bianchi77 bianchi77   75 Jun 18 19:21 
zImage-am335x-bone.dtb -> 
zImage--4.10.9+git0+ad2e885015_fe0fb8da3d-r0-am335x-bone-20170618070558.dtb
lrwxrwxrwx 2 bianchi77 bianchi77   74 Jun 18 19:21 zImage-beaglebone.bin 
-> 
zImage--4.10.9+git0+ad2e885015_fe0fb8da3d-r0-beaglebone-20170618070558.bin




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

Re: [yocto] Compiling meta-browser ==>chromium ? cleaning ?

2017-06-18 Thread Riko Ho 

What version are you talking about ? how can I know that ?

Thanks


On 18/06/17 15:49, Martin Jansa wrote:

You didn't say which versions you're using.

If you're using latest oe-core with gcc7 then you will need v3 version 
of this change:

http://lists.openembedded.org/pipermail/openembedded-devel/2017-June/113247.html
I'll send it later today.

> And how can I clean after building it ? It took about 70Gb of my drive

Like any other recipe:
bitbake -c clean foo

On Sun, Jun 18, 2017 at 1:41 AM, Riko Ho > wrote:


Hello Everyone,

I tried to compile chromium but never succeeded, took me already
12 hours and stopped on 99%,
I used bitbake for doing it,

Is chromium not compatible with arm CPU ? it was working with
X86_64 before.
And how can I clean after building it ? It took about 70Gb of my drive

Thanks
-- 
___

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





--
*

/***/
Sent by Ubuntu LTS 16.04,
谢谢,
Regards,
Riko Ho
/***/

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

Re: [yocto] Compiling meta-browser ==>chromium ? cleaning ?

2017-06-18 Thread Martin Jansa 
You didn't say which versions you're using.

If you're using latest oe-core with gcc7 then you will need v3 version of
this change:
http://lists.openembedded.org/pipermail/openembedded-devel/2017-June/113247.html
I'll send it later today.

> And how can I clean after building it ? It took about 70Gb of my drive

Like any other recipe:
bitbake -c clean foo

On Sun, Jun 18, 2017 at 1:41 AM, Riko Ho  wrote:

> Hello Everyone,
>
> I tried to compile chromium but never succeeded, took me already 12 hours
> and stopped on 99%,
> I used bitbake for doing it,
>
> Is chromium not compatible with arm CPU ? it was working with X86_64
> before.
> And how can I clean after building it ? It took about 70Gb of my drive
>
> Thanks
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto