Re: Debian in a Pcduino3
It seems that dtb(s) is an electronic shema (in a file), for that the kernel recognize the board (partially or completely). Thanks for the explanation, it is more clear now. However, i don't know if the dtb (and others modifications to do) can be done just in reading the electronic shema... but if it is necessary to have the physical board to know more precisely some I/O address, i can give some informations (there's an installed OS - not the one i want- with a Shell in the pcduino3 board) from this one. If it can help for the next dtb. Is there a mean to know when the dtb and others spécifications, enabling the install in pcduino3, will be in jessie ? I don't know how to find this information and where are the diff from jessie enouncing that... Great thanks for this work in the pcduino3... Le 28 déc. 2014 01:20, Karsten Merker mer...@debian.org a écrit : On Sat, Dec 27, 2014 at 11:18:25PM +0100, Patrice Go wrote: [using a dtb from a newer kernel with kernel 3.16] understood. don't have enough technical capacities and time to advance in that... is it something like that, that it would be necessary to do ? : http://olimex.wordpress.com/2013/09/18/7795/ Hello, the olimex page describes something completely different - it is about manually setting up a Debian rootfs with a linux-sunxi.org 3.4 kernel. The linux-sunxi.org 3.4 kernel does not use device-trees, but instead uses the Allwinner-specific fex system, which is incompatible with mainline kernels. I guess you need some more background information about Linux on arm-based systems: Historically, every arm-based system needed a specifically built kernel. This obviously did not scale well to a large number of systems, so people worked on a solution, which was found in the form of device-trees. A device-tree is a description of the hardware setup of a specific board. It contains information such as which I/O-pins are connected to which external devices and which non-probeable hardware components are built onto the board. Systems-on-Chip (SoC) like the Allwinner A20 give a hardware designer the possibility to use their I/O connectors for very different functions, which means that the very same I/O pin that is used for detecting the presence of an SD card on one board might be used to control the power supply of an ethernet PHY on another board. All this information is encoded in the board's device-tree, so that a single kernel which understands this device-tree information can run on lots of different boards, as long as a device-tree for that board exists and the kernel has the necessary drivers for the hardware components on the board. The kernel 3.16 in Jessie has drivers for several core components of the pcduino3 (like serial port, MMC controller, USB host controller, internal ethernet MAC, external ethernet PHY, SATA controller), but due to lack of a device-tree for the board, it does not know how several of the connectors or external components are wired to the SoC. If one provides the device-tree information for the board (which can be taken from kernel 3.17) to kernel 3.16, those drivers which are already available in kernel 3.16 can make use of it and thereby work on the new board. I hope this helps a bit in clearing up the confusion. Regards, Karsten -- Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung.
Re: Debian in a Pcduino3
On Tuesday 30 December 2014 15:36:34 Patrice Go wrote: It seems that dtb(s) is an electronic shema (in a file), for that the kernel recognize the board (partially or completely). Thanks for the explanation, it is more clear now. However, i don't know if the dtb (and others modifications to do) can be done just in reading the electronic shema... but if it is necessary to have the physical board to know more precisely some I/O address, i can give some informations (there's an installed OS - not the one i want- with a Shell in the pcduino3 board) from this one. If it can help for the next dtb. All you need to do is find the file from the 3.17 or later kernel (it can be found at kernel.org by looking at the git tree (I chose one from 3.18.1) at (this next is only one line):- https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/arch/arm/boot/dts?id=v3.18.1 you will find a file called:- sun7i-a20-pcduino3.dts This file is specifically the one for the pcduino3 and defines everything that the kernel needs to know to run on the pcduino3. Then follow the instructions in:- https://wiki.debian.org/InstallingDebianOn/Allwinner#Installing_on_systems_that_are_not_supported_out_of_the_box David Is there a mean to know when the dtb and others spécifications, enabling the install in pcduino3, will be in jessie ? I don't know how to find this information and where are the diff from jessie enouncing that... Great thanks for this work in the pcduino3... Le 28 déc. 2014 01:20, Karsten Merker mer...@debian.org a écrit : On Sat, Dec 27, 2014 at 11:18:25PM +0100, Patrice Go wrote: [using a dtb from a newer kernel with kernel 3.16] understood. don't have enough technical capacities and time to advance in that... is it something like that, that it would be necessary to do ? : http://olimex.wordpress.com/2013/09/18/7795/ Hello, the olimex page describes something completely different - it is about manually setting up a Debian rootfs with a linux-sunxi.org 3.4 kernel. The linux-sunxi.org 3.4 kernel does not use device-trees, but instead uses the Allwinner-specific fex system, which is incompatible with mainline kernels. I guess you need some more background information about Linux on arm-based systems: Historically, every arm-based system needed a specifically built kernel. This obviously did not scale well to a large number of systems, so people worked on a solution, which was found in the form of device-trees. A device-tree is a description of the hardware setup of a specific board. It contains information such as which I/O-pins are connected to which external devices and which non-probeable hardware components are built onto the board. Systems-on-Chip (SoC) like the Allwinner A20 give a hardware designer the possibility to use their I/O connectors for very different functions, which means that the very same I/O pin that is used for detecting the presence of an SD card on one board might be used to control the power supply of an ethernet PHY on another board. All this information is encoded in the board's device-tree, so that a single kernel which understands this device-tree information can run on lots of different boards, as long as a device-tree for that board exists and the kernel has the necessary drivers for the hardware components on the board. The kernel 3.16 in Jessie has drivers for several core components of the pcduino3 (like serial port, MMC controller, USB host controller, internal ethernet MAC, external ethernet PHY, SATA controller), but due to lack of a device-tree for the board, it does not know how several of the connectors or external components are wired to the SoC. If one provides the device-tree information for the board (which can be taken from kernel 3.17) to kernel 3.16, those drivers which are already available in kernel 3.16 can make use of it and thereby work on the new board. I hope this helps a bit in clearing up the confusion. Regards, Karsten -- Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1674594.Xpq5G3lv0i@stargate
Re: Providing (armhf) u-boot images together with d-i images?
On Sat, 2014-12-27 at 00:00 +0100, Karsten Merker wrote: attached is V2 of the patchset. Changes since V1: I should start by saying that I'm not personally particularly interested in this functionality, but I don't want to be a blocker for people who are so since I've been asked I'll give my 2pence... I've been wondering if this image generation should be in debian installer or if it should be a separate project (similar to how debian-cd is separate). The advantage of doing it separately would be that the images can be rev'd or expanded (e.g. to add a new platform) independently from the installer releases, plus we don't need to worry so much about exploding the size of the main installer releases as much. Just an idle thought really. Please could you post the diff in the lists of files generated by the build, including the sizes of the new stuff. FWIW review would be a lot easier if the patches were patchbombed to the list in the normal git send-email way rather than as multiple attachments on a single mail (people can kill-thread if they aren't interested), but here we go: 0001-Add-boot-arm-u-boot-image-config.patch Seems fine. 0002-Provide-u-boot-binaries-for-armhf-systems-without-u-.patch There would be a lot less shell-in-make quoting faff if there was a helper under util/ with the bulk of the code in. I think this isn't actually publishing the u-boot binaries, but rather sd-card images with the u-boot inlined, is that right? Is there any use in shipping the raw binaries too? 0003-Add-utils-gen-hd-image.patch I didn't review in detail, but perhaps the functionality of patch 0002 could be folded in? TBH I'm not sure what the distinction is between what 0002 does and what this script would produce (except I can see the script clearly has more functionality) 0004-Add-SD-card-image-build-support-for-hd-media-builds-.patch I don't think we need all of (.gz|.bz2|.xz) (like the README suggests, although it's not clear these are all actually present). Just one would do IMHO. It seems to be creating a copy of dtbs again, please lets try and keep it to one set of these files in the top level component. The README should describe how to actually do the concatenation. 0005-Add-SD-card-image-and-tftpboot-tarball-build-support.patch What is this providing? Is it a mini.iso like netboot sd image? I'm not sure how this is different from what the previous patches introduced. For the tftpboot part, u-boot supports standard pxelinux.cfg syntax configuration files -- would it be better to just generate a suitable one of those? 0006-Add-additional-dependencies-needed-for-building-boot.patch Seems ok. But by having this last at least half the previous patches won't work in isolation. Better IMHO to add each dependency as the dependency is introduced. I suppose my main overall concern is that this seems to be providing the same thing 3 or 4 times and I'm not sure what the difference between each of those things is (or perhaps as likely I've misunderstood what is going on somewhere along the line). I was already concerned about the proliferation of images which taking this approach was implying in general and adding a multiplier to that just makes me more uncomfortable. Perhaps a summary of the new toplevel output directories (i.e. things added alongside netboot, hd-media, network-console etc) describing what each one is would help? Ian. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1419953311.13595.190.ca...@debian.org
Re: Providing (armhf) u-boot images together with d-i images?
On 2014-12-30, Ian Campbell wrote:
I should start by saying that I'm not personally particularly interested
in this functionality, but I don't want to be a blocker for people who
are so since I've been asked I'll give my 2pence...
Thanks for taking the time.
I've been wondering if this image generation should be in debian
installer or if it should be a separate project (similar to how
debian-cd is separate).
I overall like the idea, all the parts (kernel, initrd, dtb) are already
shipped in d-i, and those that aren't (u-boot) are easy to depend
on. The bootscripts could still go into d-i, or this image generation
utility itself...
I would also hope that these images get shipped through some official
channel(like the .iso files produced by debian-cd), in a format that's
easy for the end-user to install, though. Not sure what it takes to make
that happen.
0004-Add-SD-card-image-build-support-for-hd-media-builds-.patch
...
It seems to be creating a copy of dtbs again, please lets try
and keep it to one set of these files in the top level
component.
Well, all the dtb files need to be on the concatenateable images so that
simply dd'ing the right u-boot files onto the card will be able to
boot. If the image was only made for a specific system, then it would be
possible to only include the relevent dtb files.
0005-Add-SD-card-image-and-tftpboot-tarball-build-support.patch
What is this providing? Is it a mini.iso like netboot sd image?
I think it is basically like the mini.iso on i386/amd64, yes.
I'm not sure how this is different from what the previous
patches introduced.
I think the difference is one is a set of netboot images, and the other
is a set of hd-media images.
For the tftpboot part, u-boot supports standard pxelinux.cfg
syntax configuration files -- would it be better to just
generate a suitable one of those?
Boot scripts allow the use of ${fdtfile}. As far as I understand, the
pxelinux.cfg syntax unfortunately lacks the ability to use u-boot
variables, and thus requires a different pxelinux.cfg for each system
that uses a different .dtb. Which doesn't seem particularly useful for
a single config for network booting...
I also think more systems support booting boot scripts than u-boot's
PXE emulation at this point.
I suppose my main overall concern is that this seems to be providing the
same thing 3 or 4 times and I'm not sure what the difference between
each of those things is (or perhaps as likely I've misunderstood what is
going on somewhere along the line). I was already concerned about the
proliferation of images which taking this approach was implying in
general and adding a multiplier to that just makes me more
uncomfortable.
If I'm reading it correctly(perhaps partly based on earlier descriptions
of the goal), there are several images produced:
* u-boot only for each supported platform
* hd-media full with u-boot + kernel + initrd + dtbs + bootscript for
each platform
* hd-media concatenateable with kernel + initrd + dtbs + bootscript
* netboot full with u-boot + kernel + initrd + dtbs + bootscript for
each platform (like mini.iso)
* netboot concatenateable with kernel + initrd + dtbs + bootscript
* netboot boot script for use with TFTP
The netboot/hd-media without u-boot are meant to be concatenated
together with the appropriate u-boot only images... so yes, there is
significant overlap between the image types.
The full images are obviously easier for the users to use, as it
requires writing a single image, but obviously proliferate the number of
images for each new supported platform.
The concatenateable images obviously save a lot of space, at the expense
of the user having to do additional steps and more complicated
documentation (and might be difficult on non-unix-like platforms?).
It probably doesn't make sense to ship both the concatenateable and full
images. I think Karsten wanted to enable both so that they could be
tested in the daily images, and then later pick which would ship with
Jessie?
I'm not attached to it all happening inside of debian-installer, just
hope that whatever's done makes it easy for the users to install debian
on some of these newish accessible low-power platforms...
live well,
vagrant
signature.asc
Description: PGP signature
Re: Debian in a Pcduino3
On Tue, Dec 30, 2014 at 11:04 PM, David Goodenough wrote: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/arch/arm/boot/dts?id=v3.18.1 you will find a file called:- sun7i-a20-pcduino3.dts A more direct link: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/plain/arch/arm/boot/dts/sun7i-a20-pcduino3.dts?id=v3.18.1 -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKTje6Ft5D4POwpzYTn1xBO=ppvcnq93dr3juqs_dhbgn0c...@mail.gmail.com
Re: Debian in a Pcduino3
On Tue, Dec 30, 2014 at 11:04 PM, David Goodenough wrote: Then follow the instructions in:- https://wiki.debian.org/InstallingDebianOn/Allwinner#Installing_on_systems_that_are_not_supported_out_of_the_box This is missing the instructions for converting from dts to dtb. -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caktje6emmlgbjgrmefmkczu_febstadvczdy42_2n+mjvd_...@mail.gmail.com
Re: Debian in a Pcduino3
On Wed, Dec 31, 2014 at 09:29:42AM +0800, Paul Wise wrote: On Tue, Dec 30, 2014 at 11:04 PM, David Goodenough wrote: Then follow the instructions in:- https://wiki.debian.org/InstallingDebianOn/Allwinner#Installing_on_systems_that_are_not_supported_out_of_the_box This is missing the instructions for converting from dts to dtb. apt-get install device-tree-compiler dtc -I dts -O dtb infile.dts outfile.dtb -- Len Sorensen -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141231024255.gp24...@csclub.uwaterloo.ca
Re: Debian in a Pcduino3
On Tue, Dec 30, 2014 at 08:58:47PM -0600, Robert Nelson wrote: Oh sunxi-*dts have pre-processor includes too. Oh great, so they need a trip through cpp first? Working on another project where i need to tweak and modify just the *.dts files i've forked this project: http://xenbits.xen.org/gitweb/?p=people/ianc/device-tree-rebasing.git;a=summary They sync with linus' tag's, you just have run make and it'll generate a proper *.dtb.. (although for all devices) IF/When the dts's are kicked out of mainline, something like that tree would host them for everyone. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141231032308.gq24...@csclub.uwaterloo.ca
Re: Debian in a Pcduino3
On Tue, Dec 30, 2014 at 9:23 PM, Lennart Sorensen lsore...@csclub.uwaterloo.ca wrote: On Tue, Dec 30, 2014 at 08:58:47PM -0600, Robert Nelson wrote: Oh sunxi-*dts have pre-processor includes too. Oh great, so they need a trip through cpp first? Yeap: 120 cmd_dtc = $(CPP) $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $ ; \ 121 $(DTC) -O dtb -o $@ -b 0 \ 122 -i $(src) $(DTC_FLAGS) \ 123 -d $(depfile).dtc.tmp $(dtc-tmp) ; \ 124 cat $(depfile).pre.tmp $(depfile).dtc.tmp $(depfile) http://xenbits.xen.org/gitweb/?p=people/ianc/device-tree-rebasing.git;a=blob;f=Makefile;hb=HEAD#l120 The mainline kernel version is a little harder to find, but it's similar.. Regards, -- Robert Nelson http://www.rcn-ee.com/ -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAOCHtYiwOThQ=sh3wjvqydndg9syce_e0_ybmxeupp5ju7l...@mail.gmail.com
Re: Debian in a Pcduino3
On Tue, Dec 30, 2014 at 9:26 PM, Robert Nelson robertcnel...@gmail.com wrote: On Tue, Dec 30, 2014 at 9:23 PM, Lennart Sorensen lsore...@csclub.uwaterloo.ca wrote: On Tue, Dec 30, 2014 at 08:58:47PM -0600, Robert Nelson wrote: Oh sunxi-*dts have pre-processor includes too. Oh great, so they need a trip through cpp first? Yeap: 120 cmd_dtc = $(CPP) $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $ ; \ 121 $(DTC) -O dtb -o $@ -b 0 \ 122 -i $(src) $(DTC_FLAGS) \ 123 -d $(depfile).dtc.tmp $(dtc-tmp) ; \ 124 cat $(depfile).pre.tmp $(depfile).dtc.tmp $(depfile) http://xenbits.xen.org/gitweb/?p=people/ianc/device-tree-rebasing.git;a=blob;f=Makefile;hb=HEAD#l120 The mainline kernel version is a little harder to find, but it's similar.. In reality, maybe the wiki should just point to using that repo? voodoo@hestia:/opt/git$ git clone git://xenbits.xen.org/people/ianc/device-tree-rebasing.git Cloning into 'device-tree-rebasing'... remote: Counting objects: 101320, done. remote: Compressing objects: 100% (52354/52354), done. remote: Total 101320 (delta 49759), reused 98142 (delta 47863) Receiving objects: 100% (101320/101320), 27.53 MiB | 3.25 MiB/s, done. Resolving deltas: 100% (49759/49759), done. Checking connectivity... done. voodoo@hestia:/opt/git$ cd device-tree-rebasing/ voodoo@hestia:/opt/git/device-tree-rebasing$ make src/arm/sun7i-a20-pcduino3.dtb DTC src/arm/sun7i-a20-pcduino3.dtb *.dtb from Linux 3.19-rc1 Regards, -- Robert Nelson http://www.rcn-ee.com/ -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAOCHtYi8SVGC1FjbSGQxscQ3juTo=kskemi42v=oo9nuktb...@mail.gmail.com
Re: ARM on Debian's Hardware Wanted web page?
On Mon, Oct 20, 2014 at 9:07 AM, Paul Wise wrote: The page is surprisingly effective; since I have joined DSA there were two offers of ARM hardware, the first was an undefined number of RPis (I redirected to debian-arm) and the second was enquiring what hardware is needed (mentioned DSA want rackable arm64 hardware and directed to debian-arm for other hardware). Just today we got an offer of a Zyxel NSA320 (no HDD), I suggested the donor contact the debian-arm list. That said, we should probably move the page to the wiki so that a larger group of people can update it. I wanted to ask about ARM hardware before doing that though. I have now done this, if anyone has a need for specific ARM hardware, please add a wiki page about it: https://wiki.debian.org/Hardware/Wanted -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKTje6Fv9a1qsyx2xUXtKbjSQBev=1=cu_vaRebg0GqzpWr=q...@mail.gmail.com
Re: Debian in a Pcduino3
:~# sh super_snip -f I just bought my PcDuino3-Nano. I want all of you to teach me how to become the best kernel developer because that is one of my purposes in of my life! I promise that I will spread the word all over the world in Nicañol and that I will Fuck the System (I will donate all profits to all human being and I will end with poverty)! PS: 0. I was touch by GOD in BanjaLuka on July 26, 2011(the day of my 27th birthday) and on December 19 of this year he contact me again and told me that all my wishes will become true. My only wish is your wish: I just wanted to changed the world :) 1. The first programming language that I was taught was Logo around when I was 6 or 7 years old. 2. My first Unix alike contact was around 2002 or 2003 and it was Red Hat 8.0, I made all my university projects when it was possible always using GNU/Linux and one time Amoeba. 3. I forgot to mention in DebConf11 that in wrote an XP alike interface written in Borland C++ from scratch, size 9.4 kB (9390 bytes) back in 2004 while I was cursing my university and that I want it now to migrate it to GNU C so it can run on all computers. 4. If someone want to help me with the C++ migration all you have to do is ask me for the code and I will send it. I love the Earth! Have a great life family! :) -- Marcelo Gutierrez Debian Lover Team POSOL http://podcast.softwarelibre.org.ni Linux User: 448194 Ubuntu User: 26821 http://mmgc84.taygon.com
Re: Debian in a Pcduino3
On Wed, Dec 31, 2014 at 2:37 PM, Marcelo Gutierrez wrote: I want all of you to teach me how to become the best kernel developer Please refer to this website and community: http://kernelnewbies.org/ -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKTje6FEm71805Hve4K7=YExQezysssa9d=-4ectzn8+d7x...@mail.gmail.com
