Re: [ptxdist] How to generate license report?

2018-03-28 Thread Andreas Pretzsch
On Di, 2018-03-27 at 09:26 +, Alm, Michael wrote:
> Also, it would be helpful to have a short-list with the package name, version 
> and license 
> type only, without all the license text. Maybe like this:
> 
> 'ptxdist license-report target short'
> 
> foo, 1.0, BSD
> bar, 2.8.1.5, GPLv2
> ...

Have a look at my patchset "license-report: also create CSV lists" just
sent to the list. It adds CSV generation to the regular process
(triggered by "ptxdist make license-report").
It might already solve your task.

Best regards,
  Andreas

-- 

carpe noctem engineering
Ingenieurbuero fuer Hard- & Software-Entwicklung Andreas Pretzsch
Dipl.-Ing. (FH) Andreas PretzschTel. +49-(0)7307-936088-1
Lange Strasse 28a   Fax: +49-(0)7307-936088-9
89250 Senden, Germany   email: a...@cn-eng.de


___
ptxdist mailing list
ptxdist@pengutronix.de

[ptxdist] [PATCH 1/2] scripts/lib: make_world_license: add suffix "_tex" to ptxd_make_world_license_write

2018-03-28 Thread Andreas Pretzsch
Rename "function ptxd_make_world_license_write" to
"ptxd_make_world_license_write_tex", to be clear about
what it creates (LaTeX file, then a PDF from it).

This change is purely cosmetic.
But we will add other generation functions later,
similiar to this. Therefore rename it.

Signed-off-by: Andreas Pretzsch 
---
Tested with PTXdist 2016.01.0, but given the minimal differences
against PTXdist 2018.03.0, I assume this is still fine.

 scripts/lib/ptxd_make_world_license.sh | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/scripts/lib/ptxd_make_world_license.sh 
b/scripts/lib/ptxd_make_world_license.sh
index 1a79387..bba8ca3 100644
--- a/scripts/lib/ptxd_make_world_license.sh
+++ b/scripts/lib/ptxd_make_world_license.sh
@@ -125,7 +125,7 @@ export -f ptxd_make_latex_escape
 # $pkg_license = the license string
 # $pkg_license_texts/$pkg_license_texts_guessed = license text files
 #
-ptxd_make_world_license_write() {
+ptxd_make_world_license_write_tex() {
 local guess
 local brl='{' brr='}'
 local pkg_chapter="$(ptxd_make_latex_escape ${pkg_label})"
@@ -207,7 +207,7 @@ ptxd_make_world_license_write() {
EOF
 done
 }
-export -f ptxd_make_world_license_write
+export -f ptxd_make_world_license_write_tex
 
 # Copy all patches according to the series file
 # $1 full path to the series file
@@ -461,7 +461,7 @@ changed: ${md5} -> $(md5sum "${lic}" | sed 's/ .*//')
ptxd_bailout "Failed to copy '$(ptxd_print_path "${file}")'"
 done &&
 
-ptxd_make_world_license_write | \
+ptxd_make_world_license_write_tex | \
 sed -e 's/%/\\%/g' > "${pkg_license_dir}/license-report.tex" &&
 check_pipe_status &&
 
-- 
2.9.3


___
ptxdist mailing list
ptxdist@pengutronix.de

[ptxdist] [PATCH 2/2] scripts/lib: also create CSV lists on "ptxdist make license-report"

2018-03-28 Thread Andreas Pretzsch
When calling "ptxdist make license-report", license reports for
both the target- and the host-tools-packages are created.

Based upon the license info files created during the regular build
process, LaTeX files are generated, which are then converted into
matching PDFs, containing package informations, license tags as well
as the licenses themselves.
These are called "report/license-report.pdf" respectively
"report/license-report-tools.pdf".

Extend this process to also create a list of these packages with the
most basic fields as CSV:
"name"|"version"|"licenses"|"flags"
"somepackage"|"1.2.3"|"Apache-2.0"|"attribution"
[...]

These are called "report/license-report.csv" respectively
"report/license-report-tools.csv".

The compliance report and distribution creation, trigger via
"ptxdist make license-compliance-distribution", is not modified,
as it essentially contains just a subset of the above packages,
namely all the Free and Open Source Software.
This could be extended by a CSV file, too, but it will not aid
in any verification of the overall distribution, as this has to
be checked in total, not only with respect to the FOSS parts.

Signed-off-by: Andreas Pretzsch 
---
Tested with PTXdist 2016.01.0, but given the minimal differences
against PTXdist 2018.03.0, I assume this is still fine.

 scripts/lib/ptxd_make_license_report.sh | 21 
 scripts/lib/ptxd_make_world_license.sh  | 59 +
 2 files changed, 80 insertions(+)

diff --git a/scripts/lib/ptxd_make_license_report.sh 
b/scripts/lib/ptxd_make_license_report.sh
index a6410d1..d6570ca 100644
--- a/scripts/lib/ptxd_make_license_report.sh
+++ b/scripts/lib/ptxd_make_license_report.sh
@@ -194,6 +194,27 @@ ptxd_make_license_report() {
ptxd_make_license_report_footer
 ) > "${ptx_license_target_tex}"
 
+ptx_license_target_csv="${ptx_report_dir}/${pkg_section}/$(basename 
"${ptx_license_target%.pdf}.csv")"
+(
+   local pkg_csv_file
+   ptxd_make_world_license_write_csv_header
+   for pkg in ${@}; do
+   pkg_lic="${ptxd_package_license_association[${pkg}]}"
+   if [ -z ${pkg_lic} ]; then
+   continue
+   fi
+   pkg_lic="${pkg_lic}/${pkg}"
+
+   pkg_csv_file="${ptx_report_dir}/${pkg_lic}/license-report.csv"
+   if [ -r "${pkg_csv_file}" ]; then
+   cat "${pkg_csv_file}"
+   else
+   ptxd_bailout "no $(ptxd_print_path "${pkg_csv_file}")"
+   fi
+   done
+   ptxd_make_world_license_write_csv_footer
+) > "${ptx_license_target_csv}"
+
 ptxd_make_license_report_build
 #mv "${ptx_license_target_tex%.tex}.pdf" "${ptx_license_target}"
 }
diff --git a/scripts/lib/ptxd_make_world_license.sh 
b/scripts/lib/ptxd_make_world_license.sh
index bba8ca3..39c696c 100644
--- a/scripts/lib/ptxd_make_world_license.sh
+++ b/scripts/lib/ptxd_make_world_license.sh
@@ -209,6 +209,63 @@ ptxd_make_world_license_write_tex() {
 }
 export -f ptxd_make_world_license_write_tex
 
+#
+# echo header for generated CSV:
+# "name"|"version"|"licenses"|"flags"
+#
+ptxd_make_world_license_write_csv_header() {
+   local -r STRING_QUOTE='"'
+   local -r CSV_SEPARATOR='|'
+   local l
+   l="${STRING_QUOTE}name${STRING_QUOTE}"
+   l="${l}${CSV_SEPARATOR}"
+   l="${l}${STRING_QUOTE}version${STRING_QUOTE}"
+   l="${l}${CSV_SEPARATOR}"
+   l="${l}${STRING_QUOTE}licenses${STRING_QUOTE}"
+   l="${l}${CSV_SEPARATOR}"
+   l="${l}${STRING_QUOTE}flags${STRING_QUOTE}"
+   l="${l}\n"
+   echo -ne "${l}"
+}
+export -f ptxd_make_world_license_write_csv_header
+#
+# generate a CSV for the package:
+# "somepackage"|"1.2.3"|"Apache-2.0"|"attribution"
+#
+ptxd_make_world_license_write_csv() {
+   local -r STRING_QUOTE='"'
+   local -r CSV_SEPARATOR='|'
+   local -a flags=( "${!pkg_license_flags[@]}" )
+   local l
+
+   # not required, seems to be filtered before:
+   #case "${pkg_license}" in
+   #*ignore*)
+   #   # ignore this package, e.g. do not list it in the report
+   #   return 0
+   #   ;;
+   #esac
+
+   l="${STRING_QUOTE}${pkg_label}${STRING_QUOTE}"
+   l="${l}${CSV_SEPARATOR}"
+   [ -n "${pkg_version}" ] && 
l="${l}${STRING_QUOTE}${pkg_version}${STRING_QUOTE}"
+   l="${l}${CSV_SEPARATOR}"
+   [ -n "${pkg_license}" ] && 
l="${l}${STRING_QUOTE}${pkg_license}${STRING_QUOTE}"
+   l="${l}${CSV_SEPARATOR}"
+   [ -n "${flags[*]}" ]&& 
l="${l}${STRING_QUOTE}${flags[*]}${STRING_QUOTE}"
+   l="${l}\n"
+   echo -ne "${l}"
+}
+export -f ptxd_make_world_license_write_csv
+#
+# echo footer for generated CSV
+#
+ptxd_make_world_license_write_csv_footer() {
+   # nothing to to
+   /bin/true
+}
+export -f ptxd_make_world_license_write_csv_footer
+
 # Copy all patches according to the series file
 # $1 

[ptxdist] [PATCH 0/2] license-report: also create CSV lists

2018-03-28 Thread Andreas Pretzsch
When calling "ptxdist make license-report", license reports for
both the target- and the host-tools-packages are created.

Based upon the license info files created during the regular build
process, LaTeX files are generated, which are then converted into
matching PDFs, containing package informations, license tags as well
as the licenses themselves.
These are called "report/license-report.pdf" respectively
"report/license-report-tools.pdf".

Extend this process to also create a list of these packages with the
most basic fields as CSV:
"name"|"version"|"licenses"|"flags"
"somepackage"|"1.2.3"|"Apache-2.0"|"attribution"
[...]

These are called "report/license-report.csv" respectively
"report/license-report-tools.csv".

This minimal report is much more suited for a comparison of different
builds resp. releases, and can be easily imported into some spreadsheet.
Which in turn is useful both for developers and legal department.
Keeping it minimal (e.g. no URL) most likely avoids CSV escaping hell.

Tested with PTXdist 2016.01.0, but given the minimal differences
against PTXdist 2018.03.0, I assume this is still fine. Albeit I did
not test it.

It is split into two commits (to ease local maintenance), but of course
could be squashed into one.
Also the commit subjects could be adapted, removing "scripts/lib", or
if squashed even simply to "license-report: also create CSV lists".

While all of this is working (and sufficient for my use case), it is
also a bit of a RFC. Just don't expect I'll do some _substantial_ rework
or improvement in a timely fashion...
So, feel free to squash and/or fixup at your own discretion.

Last, sorry for having this one delayed a year and a half before sending
mainline...

Andreas Pretzsch (2):
  scripts/lib: make_world_license: add suffix "_tex" to
ptxd_make_world_license_write
  scripts/lib: also create CSV lists on "ptxdist make license-report"

 scripts/lib/ptxd_make_license_report.sh | 21 +++
 scripts/lib/ptxd_make_world_license.sh  | 65 +++--
 2 files changed, 83 insertions(+), 3 deletions(-)

-- 
2.9.3


___
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] Including valgrind in the configuration doesn't trigger an un-optimized build of glibc.

2018-03-28 Thread Crim, Jason
Andrej,

Thanks for your information.  My setup includes glibc 2.20 rather than the 2.16 
referenced in your patch file, so I don't think it'll work directly (the source 
of 2.20 and 2.16 look pretty different - actually, I'm not even seeing the 
files referenced in the 2.16 source I pulled from the glibc archive today), but 
perhaps it'll help me find the answers I need.

My results from readelf on libc.so.6 look a bit different:
>14499: 00058f21 0 FUNCGLOBAL DEFAULT   11 memcpy
>12773: 00056f11   740 FUNCGLOBAL DEFAULT   11 strcmp
>14536: 00057701   220 FUNCGLOBAL DEFAULT   11 strlen

there are no "FUNC  LOCAL   DEFAULT" for the base functions - though memcpy 
does have a size of 0 here.

My ld-2.20.so (which is the file valgrind referenced) yeilds similar results to 
yours:
>  916: 00012921 0 FUNCLOCAL  DEFAULT   10 memcpy
> 1033: 00011b31   740 FUNCLOCAL  DEFAULT   10 strcmp
> 1083: 00012041   220 FUNCLOCAL  DEFAULT   10 strlen
  
with the exception of strcmp and strlen.  Which makes sense given the valgrind 
output in my last message.  Replacing ld-2.20.so moved the error from strcmp to 
memcpy.

I'm actually seeing similar entries ('0 FUNCLOCAL  DEFAULT') for memcpy, 
memchr, index, memset, and strchr in ld-2.20.so.

 - Jason


-Original Message-
From: ptxdist [mailto:ptxdist-boun...@pengutronix.de] On Behalf Of 
andrej.gantv...@wago.com
Sent: Wednesday, March 28, 2018 6:02 AM
To: ptxdist@pengutronix.de
Subject: Re: [ptxdist] Including valgrind in the configuration doesn't trigger 
an un-optimized build of glibc.

Hi Jason,


we had experienced a similar problem with the OSELAS 2012.12.1 toolchain. 
In our case the problem was the missing .size directive in assembler 
reimplementations of strlen and memcpy from the linaro cortex-strings patch for 
glibc.

Does your "readelf -s /path/to/your/libc.so.6" output look like this?

...
828: 00019491 0 FUNC LOCAL DEFAULT 10 memcpy ...
949: 00018690 164 FUNC LOCAL DEFAULT 10 strcmp ...
996: 000189d1 0 FUNC LOCAL DEFAULT 10 strlen ...

Note the zeroes  in the 3rd column. If so, you may have the same problem.

You may find our workaround in the attachment. The patch has to be applied 
after the Linaro NEON patch. No idea why strcmp also had to be touched though.


Andrej

-Ursprüngliche Nachricht-
Von: ptxdist [mailto:ptxdist-boun...@pengutronix.de] Im Auftrag von Crim, Jason
Gesendet: Dienstag, 27. März 2018 1:54
An: ptxdist@pengutronix.de
Betreff: Re: [ptxdist] Including valgrind in the configuration doesn't trigger 
an un-optimized build of glibc.

Michael,

It looks like the toolchain is configured as OSELAS.Toolchain-2014.12.  I've 
recently been added to a team which had this existing ptxdist setup, so I've 
been trying to learn my way around ptxdist while trying to get valgrind enabled 
to test an issue.

The initial run of valgrind results in the message shown in my first message:
>
>   ==5596== Memcheck, a memory error detector
>   ==5596== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
>   ==5596== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright 
> info
>   ==5596== Command: /usr/bin/device
>   ==5596==
>
>   valgrind:  Fatal error at startup: a function redirection
>   valgrind:  which is mandatory for this platform-tool combination
>   valgrind:  cannot be set up.  Details of the redirection are:
>   valgrind:  
>   valgrind:  A must-be-redirected function
>   valgrind:  whose name matches the pattern:  strcmp
>   valgrind:  in an object with soname matching:   ld-linux-armhf.so.3
>   valgrind:  was not found whilst processing
>   valgrind:  symbols from the object with soname: ld-linux-armhf.so.3
>   valgrind:  
>   valgrind:  Possible fixes: (1, short term): install glibc's debuginfo
>   valgrind:  package on this machine.  (2, longer term): ask the packagers
>   valgrind:  for your Linux distribution to please in future ship a non-
>   valgrind:  stripped ld.so (or whatever the dynamic linker .so is called)
>   valgrind:  that exports the above-named function using the standard
>   valgrind:  calling conventions for this platform.  The package you need
>   valgrind:  to install for fix (1) is called
>   valgrind:  
>   valgrind:On Debian, Ubuntu: libc6-dbg
>   valgrind:On SuSE, openSuSE, Fedora, RHEL:   glibc-debuginfo
>   valgrind:  
>   valgrind:  Cannot continue -- exiting now.  Sorry.


Since ld-linux-armhf.so.3 is a symlink to ld-2.20.so, I copied ld-2.20.so from 
the root-debug/lib location and re-ran valgrind.  The referenced function 
changed, but the file it expected it in did not (for brevity, I've only 
retained the function and file lines).
>
>   ...
>   valgrind:  A must-be-redirected function
>  

Re: [ptxdist] Including valgrind in the configuration doesn't trigger an un-optimized build of glibc.

2018-03-28 Thread Andrej.Gantvorg
Hi Jason,


we had experienced a similar problem with the OSELAS 2012.12.1 toolchain. 
In our case the problem was the missing .size directive in assembler 
reimplementations of strlen and memcpy from the linaro cortex-strings patch for 
glibc.

Does your "readelf -s /path/to/your/libc.so.6" output look like this?

...
828: 00019491 0 FUNC LOCAL DEFAULT 10 memcpy
...
949: 00018690 164 FUNC LOCAL DEFAULT 10 strcmp
...
996: 000189d1 0 FUNC LOCAL DEFAULT 10 strlen
...

Note the zeroes  in the 3rd column. If so, you may have the same problem.

You may find our workaround in the attachment. The patch has to be applied 
after the Linaro NEON patch. No idea why strcmp also had to be touched though.


Andrej

-Ursprüngliche Nachricht-
Von: ptxdist [mailto:ptxdist-boun...@pengutronix.de] Im Auftrag von Crim, Jason
Gesendet: Dienstag, 27. März 2018 1:54
An: ptxdist@pengutronix.de
Betreff: Re: [ptxdist] Including valgrind in the configuration doesn't trigger 
an un-optimized build of glibc.

Michael,

It looks like the toolchain is configured as OSELAS.Toolchain-2014.12.  I've 
recently been added to a team which had this existing ptxdist setup, so I've 
been trying to learn my way around ptxdist while trying to get valgrind enabled 
to test an issue.

The initial run of valgrind results in the message shown in my first message:
>
>   ==5596== Memcheck, a memory error detector
>   ==5596== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
>   ==5596== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright 
> info
>   ==5596== Command: /usr/bin/device
>   ==5596==
>
>   valgrind:  Fatal error at startup: a function redirection
>   valgrind:  which is mandatory for this platform-tool combination
>   valgrind:  cannot be set up.  Details of the redirection are:
>   valgrind:  
>   valgrind:  A must-be-redirected function
>   valgrind:  whose name matches the pattern:  strcmp
>   valgrind:  in an object with soname matching:   ld-linux-armhf.so.3
>   valgrind:  was not found whilst processing
>   valgrind:  symbols from the object with soname: ld-linux-armhf.so.3
>   valgrind:  
>   valgrind:  Possible fixes: (1, short term): install glibc's debuginfo
>   valgrind:  package on this machine.  (2, longer term): ask the packagers
>   valgrind:  for your Linux distribution to please in future ship a non-
>   valgrind:  stripped ld.so (or whatever the dynamic linker .so is called)
>   valgrind:  that exports the above-named function using the standard
>   valgrind:  calling conventions for this platform.  The package you need
>   valgrind:  to install for fix (1) is called
>   valgrind:  
>   valgrind:On Debian, Ubuntu: libc6-dbg
>   valgrind:On SuSE, openSuSE, Fedora, RHEL:   glibc-debuginfo
>   valgrind:  
>   valgrind:  Cannot continue -- exiting now.  Sorry.


Since ld-linux-armhf.so.3 is a symlink to ld-2.20.so, I copied ld-2.20.so from 
the root-debug/lib location and re-ran valgrind.  The referenced function 
changed, but the file it expected it in did not (for brevity, I've only 
retained the function and file lines).
>
>   ...
>   valgrind:  A must-be-redirected function
>   valgrind:  whose name matches the pattern:  memcpy
>   valgrind:  in an object with soname matching:   ld-linux-armhf.so.3
>   valgrind:  was not found whilst processing
>   valgrind:  symbols from the object with soname: ld-linux-armhf.so.3
>   ...

The fact that the reference was expected in the same file, along with 
additional searching, led me to think that the optimization was the problem.


Thanks,
 - Jason



-Original Message-
From: ptxdist [mailto:ptxdist-boun...@pengutronix.de] On Behalf Of Michael 
Olbrich
Sent: Tuesday, March 27, 2018 3:34 AM
To: ptxdist@pengutronix.de
Subject: Re: [ptxdist] Including valgrind in the configuration doesn't trigger 
an un-optimized build of glibc.

Hi,

On Mon, Mar 26, 2018 at 07:03:21AM -0500, Crim, Jason wrote:
> I'd tried moving over the root-debug versions of the referenced files, 
> and was still hitting the error.  That's when I'd found the post 
> referencing the optimization levels.  I'll take a look at getting the 
> nfs-root running when I've got some time.

Hmm, strage, The only problems I've seen are with stripped binaries. Which 
toolchain are you using?

Michael

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

___
ptxdist mailing list
ptxdist@pengutronix.de
___
ptxdist mailing list
ptxdist@pengutronix.de



Re: [ptxdist] fwd: DistroKit not working for BeagleCore

2018-03-28 Thread Roland Hieber

Hi Benedikt,

when you get to the barebox boot prompt, can you boot successfully by 
typing "boot mmc0"?


In your logs I can see that barebox is adding the wrong rootfs option to 
the kernel command line, it probably wasn't enough to specify 
global.bootm.* variables. The "boot mmc0" command should autodetect the 
respective command line options for the kernel.


By the way, you can set the default boot target in barebox with
"nv boot.default=mmc0", followed by a reset. I think the barebox 
defaultenv sets this variable wrong on boot...


 - Roland

On 22.03.2018 18:11, Robert Schwebel wrote:

- Forwarded message from ptxdist-boun...@pengutronix.de -

Date: Thu, 22 Mar 2018 15:12:24 +0100
From: ptxdist-boun...@pengutronix.de
To: ptxdist-ow...@pengutronix.de
Subject: Auto-discard notification
Message-ID: 

The attached message has been automatically discarded.

Date: Thu, 22 Mar 2018 14:12:21 +
From: benedikt.wies...@rehau.com
To: ptxdist@pengutronix.de
Subject: DistroKit not working for BeagleCore
Message-ID: <24378802-adf9-4060-9acf-10cef12e1...@rehau.com>
X-Mailer: Lotus Notes Release 8.5.1FP1 January 05, 2010

Hi *,

  


I wanted to feel the power of ptxdist and tried to build an image for
beaglecore (which is a beaglebone black) with DistroKit-2018.03.0 and
OSELAS.Toolchain-2016.06.1/arm-v7a-linux-gnueabihf Toolchain.

  


Unfortunately nothing is really working. The Boot Process is stopping here:

  


barebox 2018.01.0-20180128-1 #1 Thu Mar 22 13:13:28 UTC 2018

Board: TI AM335x BeagleBone black

detected 'BeagleBone Black'

cpsw 4a10.ethernet: detected phy mask 0x1

mdio_bus: miibus0: probed

eth0: got preset MAC address: b0:d5:cc:cb:83:00

cpsw 4a10.ethernet: Failed to setup slave 1: I/O error

am335x-phy-driver 47401300.usb-phy: am_usbphy 8ffa9528 enabled

musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO
Rx, HB-ISO Tx, SoftConn)

musb-hdrc: MHDRC RTL version 2.0

musb-hdrc: setup fifo_mode 4

musb-hdrc: 28/31 max ep, 16384/16384 memory

am335x-phy-driver 47401b00.usb-phy: am_usbphy 8ffaaa88 enabled

musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO
Rx, HB-ISO Tx, SoftConn)

musb-hdrc: MHDRC RTL version 2.0

musb-hdrc: setup fifo_mode 4

musb-hdrc: 28/31 max ep, 16384/16384 memory

i2c-omap 44e0b000.i2c: bus 0 rev0.11 at 400 kHz

omap-hsmmc 4806.mmc: registered as 4806.mmc

mmc0: detected SD card version 2.0

mmc0: registered mmc0

omap-hsmmc 481d8000.mmc: registered as 481d8000.mmc

mmc1: detected MMC card version 4.5

mmc1: registered mmc1

netconsole: registered as netconsole-1

malloc space: 0x8fefeee0 -> 0x9fdfddbf (size 255 MiB)

environment load /mnt/mmc0.0/barebox.env: No such file or directory

Maybe you have to create the partition.

running /env/bin/init...

[?25hchanging USB current limit to 1300 mA... done

  


Hit m for menu or any other key to stop autoboot:3   2   1   0

bootchooser: Target list $global.bootchooser.targets is empty

Nothing bootable found on 'bootchooser'

booting 'net'

ip_route_get: No such file or directory

could not open /mnt/tftp/none-linux-generic: No route to host

Booting 'net' failed: No route to host

booting 'net' failed: No route to host

boot: No route to host

  


type exit to get to the menu

[1;32mbarebox@[1;36mTI AM335x BeagleBone black:

  

  


When trying to boot manually with (global.bootm.image=/mnt/mmc0.1/boot/zImage,
global.bootm.oftree=/mnt/mmc0.1/boot/am335x-boneblack.dtb):

  


Loading ARM Linux zImage '/mnt/mmc0.1/boot/zImage'

Loading devicetree from '/mnt/mmc0.1/boot/am335x-boneblack.dtb'

commandline: console=ttyO0,115200 console=ttyO0,115200n8  root=/dev/nfs nfsroot
=/home/none/nfsroot/generic,v3,tcp loglevel=5 systemd.log_level=warning
systemd.show_status=auto

[0.003601] timer_probe: no matching timers found

[0.245969] omap_hwmod: debugss: _wait_target_disable failed

[0.533505] hw perfevents: no interrupt-affinity property for /pmu,
guessing.

[0.836376] omap_voltage_late_init: Voltage driver support not added

[0.871536] mmc0: host does not support reading read-only switch, assuming
write-enable

[0.915997] cpufreq: cpufreq_online: CPU0: Running at unlisted freq: 50
KHz

[0.924074] cpufreq: cpufreq_online: CPU0: Unlisted initial frequency
changed to: 60 KHz

[0.935105] Root-NFS: no NFS server address

[0.940012] VFS: Unable to mount root fs via NFS, trying floppy.

[0.949346] VFS: Cannot open root device "nfs" or unknown-block(2,0): error
-6

[0.956876] Please append a correct "root=" boot option; here are the
available partitions:

[0.965846] b30015558144 mmcblk0

[0.965855]  driver: mmcblk

[0.973123]   b301   32768 mmcblk0p1 abe26147-01

[0.973130]

[0.980386]   b302  524288 mmcblk0p2 abe26147-02

[0.980392]

[0.987474]   b303  524288 mmcblk0p3