View unanswered posts | View active topics It is currently Sun May 19, 2019 7:11 am



Reply to topic  [ 32 posts ]  Go to page Previous  1, 2, 3, 4  Next
 Utilite Value won't boot; just black screen 
Author Message

Joined: Sat May 14, 2016 1:24 pm
Posts: 56
Post Re: Utilite Value won't boot; just black screen
Hi,

ArchLinuxARM has two kernels that may work for you:
  • linux-utilite-dt is based on Linux 3.10 developed by CompuLab. However, note that CompuLab never released an official stable version of this kernel branch.
  • linux-imx6 is based on Linux 3.14 and developed by Freescale/NXP (the SoC vendor).
    Due to pepedog [1] it is the prefered replacement for CompuLab's old 3.0.x kernel but no one tested it sufficently.
Both can be installed via pacman, e.g. via chroot. Propably, you have to adapt U-Boot's environment again for either kernel.

I have never tried the kernels above myself -- I use ArchLinuxARM with the mainline kernel (ArchLinuxARM offers a generic rootfs + mainline kernel [2]). The bad news here is that the mainline kernel has support only for the Utilite *Pro* but not the Utilite Value (nor the Standard model for that matter). Adding support is not that hard, it boils down to come up with a devicetree. Since we already have a devicetree for the Utilite Pro, it is indeed a matter of splitting that one up (into features supported by the Utilite Value and those which are only supported by the Pro model).
If you are ready for a little adventure and upstream support for the Utilite Value, I would be happy to support/help you :-).

Cheers,
Christopher

P.S.: Do not try to boot the Utilite *Value* with the imx6q-utilite-pro.dtb devicetree file. The Standard/Pro models have a different SoC than the Value; it may end badly.

[1] viewtopic.php?f=76&t=2464
[2] http://os.archlinuxarm.org/os/ArchLinux ... est.tar.gz


Sat Dec 30, 2017 11:45 pm
Profile

Joined: Tue Jan 07, 2014 12:07 am
Posts: 138
Location: Edinburgh, Scotland
Post Re: Utilite Value won't boot; just black screen
Ah yes, sorry I was forgetting that the device tree I mentioned is meant for the Pro.


Sat Dec 30, 2017 11:50 pm
Profile

Joined: Sun Jul 13, 2014 6:16 pm
Posts: 23
Location: Queens, New York City
Post Re: Utilite Value won't boot; just black screen
Hi, Christopher. I am up for a little adventure! I'm a bit out of my depth here, though. My technical background is in ASP.NET MVC development. I don't really know where to begin. But I'm willing to learn! Any advice? I did find this checklist for new ARM SoC vendors linked from Wikipedia. It's probably broader than is necessary to accomplish what I want, but I'm going to at least review it to start getting a hang of some of the lingo.

Thank you both for your help!


Mon Jan 01, 2018 6:26 am
Profile

Joined: Sun Jul 13, 2014 6:16 pm
Posts: 23
Location: Queens, New York City
Post Re: Utilite Value won't boot; just black screen
I found this description of the DTS format and the DTS for the Utilite Pro. I'm still only somewhat clued in as to what I'm reading, but thank goodness for web searches, right? This seems to be a good resource.


Tue Jan 02, 2018 2:28 am
Profile

Joined: Sat May 14, 2016 1:24 pm
Posts: 56
Post Re: Utilite Value won't boot; just black screen
Great!

Let's start slowly with a rough outline of what has to be done:
  • Split the devicetree(s)
  • Test it on real hardware (i.e. all "features" of the Utilite Value)
  • Submit the patches for upstreaming and address any comments (sometimes this involves redoing (partially) step 2)

I'm quite confident that given your logs and [1] I can quickly come up with a proper devicetree, since it's basically a matter of knowing which devices ("visible" or not) exist. However, if you want to do it, that's totally fine. We aren't in a hury, are we?

You have already found the correct "toplevel" devicetree source. Note that it includes the imx6q-cm-fx6.dts file. Indeed, the Utilite consists of two boards: the module board called cm-fx6 which is described in the imx6q-cm-fx6.dts file and the baseboard whose details are "added" in the imx6q-utilite-pro.dts file. Both files have to be split up. (CompuLab offers the cm-fx6 module as standalone or with different, more dev/industry oriented baseboards, too, thus the separation).

An example is the hummingboard. You'll find several *humminboard.dts[i] files (in the same directory as the imx6q-utilite-pro.dts). The module counterpart is called microsom. In the case you haven't already figured out: the suffix q in imx6q refers to the dual/quad variant of the imx6 SoC and the dl suffix to the dual lite/solo variant. The suffix qdl is used for common/shared files. The former SoC is used in the Utilite Pro and the latter in the Utilite Value. *.dts files are "complete" devicetree sources that are built and *.dtsi files are for inclusion only.

I have yet to see a good devicetree tutorial but the slides by Free Electrons' you linked seem to be quite good, indeed. We only need the "View" component, i.e. the devicetree description, bits, so you may skip the C code parts. Also more or less all "bindings" are documented in Documentation/devicetree/bindings .

Finally, it is a good idea to start with the git branch imx/dt of Shawn Guo [2] who is Linux's imx maintainer. There are already a few cleanup patches on top of Linus' tree destined for v4.16. It usually avoids merge/rebase conflicts.

As for the second point (testing), I recommand setting up two sd cards: one with a working (old) installation and a new sd card for the actual test runs.
Since you want to use ArchLinuxARM anyway, just create a single ext4 partition on the test sd card and mount it to, say, /mnt.
Then proceed with (execute as root user)
Code:
bsdtar -xpf ArchLinuxARM-armv7-latest.tar.gz -C /mnt
cd /mnt
ln -s boot/zImage zImage-cm-fx6

Once there is one, you have to place the devicetree to /mnt/cm-fx6.dtb .
(the tar.gz file is the generic multi-platform rootfs Chewi and I already referred to [3])

You also need to compile devicetrees; I usually do that with the working installation on the Utilite itself (on the SSD). With two sd cards this might be inconveniant. Do you have another armv7 board where you can plug in the testing sd cards in order to copy the devicetree blob to the sd card?
In either case, clone the repository [2] somewhere on the device on which you want to compile. Then checkout a new working branch:
Code:
git checkout -b utilite/wip-value imx/dt

For compilation you have to initialize the config with, e.g.
Code:
make imx_v6_v7_defconfig

Then you can compile devicetrees like
Code:
make imx6q-utilite-pro.dtb

The result is written to arch/arm/boot/dts/imx6q-utilite-pro.dtb .

The patch submission we can discuss later on. The only important thing is that someone (that'll be you) has to certify with a real name + email address that the patches had been tested.

Cheers,
Christopher

[1] https://github.com/utilite-computer/lin ... d-cm-fx6.c
[2] https://git.kernel.org/pub/scm/linux/ke ... /?h=imx/dt
[3] http://os.archlinuxarm.org/os/ArchLinux ... est.tar.gz


Tue Jan 02, 2018 4:05 pm
Profile

Joined: Sun Jul 13, 2014 6:16 pm
Posts: 23
Location: Queens, New York City
Post Re: Utilite Value won't boot; just black screen
No, I'm not in any hurry! Obviously, I've got a lot of reading to do, but to answer one of your questions, I don't have another ARM7 board. In fact, I can't even get a working Linux terminal on the board I do have! The TTY refused to take input using Utilite Linux ever since I updated U-Boot, and I get the message about kernel too old using Arch. It sounds like I'll need a Linux terminal on an ARM7 board at some point, so if you have any advice toward that end, I'd appreciate. My first inclination was to try to SSH into the device once it booted to the point of asking me for a Linux login over TTY, but it doesn't seem to have acquired an IP address over DHCP. Networking had been working before the U-Boot upgrade, but so was typing over TTY. If it's possible (necessary?) to emulate an ARM7 on my Mac or my Acer C720 running GalliumOS, that's an option, too.


Wed Jan 03, 2018 12:36 am
Profile

Joined: Sun Jul 13, 2014 6:16 pm
Posts: 23
Location: Queens, New York City
Post Re: Utilite Value won't boot; just black screen
There's a bit I'm not getting about the DTS and DSTI syntax and semantics. I have a few questions.

What are the relationships between labels and nodes? It seems you can have a label without a node name and address, a node name and address without a label, or both. Does a node without a node name and address have an implicit node address (and maybe an implicit node name)?

What does the ampersand character mean? Does it have different meanings in different contexts? I gather one use is as a "phandle", which 1) is a reference to another node and 2) is conceptually similar to the & operator in C/C++ in that it gets an "address" of sorts. Is that right?

There are nodes/labels in imx6q-utilite-pro.dts where the label starts with &. What does & mean in that context?

Is it accurate to say that the DTS is basically a description of a blob of bytes to be loaded into memory? (Hence DTB -- device tree blob?)

Some property names seem to sometimes have special meaning. Are these defined higher up in the "include chain" or somewhere higher beyond that? For example, "aliases" seems to mean something special.

Are #address-cells and #size-cells inherited by child nodes?

Is #address-cells the memory address of a register? (It's been a while since my computer architecture class and since I last did assembly programming, but what does it even mean for a register to have an address? Are the registers in ARM just memory locations?)

Do reg properties get assigned the first n cells based on #address-cells and then the next m cells based on #size-cells? As in, would #address-cells = 2; #size-cells = 0; reg = <1 2>; mean that a register address is described by a 64-bit number that is some combination of the bit representations of 1 and 2? And if #address0cells = 1; #size-cells = 1; had been specified instead, would that mean an address of 1 and a size of 64 bits? (2 specified in the second cell meaning two 32-bit cells?)

Thanks in advance!


Wed Jan 03, 2018 4:08 am
Profile

Joined: Tue Jan 07, 2014 12:07 am
Posts: 138
Location: Edinburgh, Scotland
Post Re: Utilite Value won't boot; just black screen
You could use a cross-compiler. This can be a minefield but for just building a kernel or device tree, there's less that can go wrong. I'm on Gentoo so building one is easy. Some distributions provide one. Unfortunately Arch doesn't seem to officially provide one but I did find this, which might get you going. You don't need the distcc stuff.


Wed Jan 03, 2018 10:34 am
Profile

Joined: Sat May 14, 2016 1:24 pm
Posts: 56
Post Re: Utilite Value won't boot; just black screen
An alternative to the cross-compiler is to compile the devicetree "manually" (unfortunately, Linux's build system can't do that without a cross-compiler, altough it is not required for the devicetree).
I'm assuming you'll use your GalliumOS and you have "build-essentials" installed (I'm not familiar with macOS).
Code:
make scripts #only required once
cpp -Iinclude -Iarch/arm/boot/dts -undef -x assembler-with-cpp -nostdinc -o cm-fx6.dts arch/arm/boot/dts/imx6q-utilite-pro.dts #this will create a temporary cm-fx6.dts file with all references and includes resolved
scripts/dtc/dtc -I dts -O dtb -o cm-fx6.dtb cm-fx6.dts #this will actually compile the devicetree; the result is written to cm-fx6.dtb

Taking a look at the intermediate cm-fx6.dts file might also be interessting for you.

In the long term we should deal with the input issue, too. I actualy thought that issue had been solved. I'm going to ask a few stupid questions, but who knows ;-).
  • Have you tried both ports?
  • Have you toogled flow control?
  • Does a USB-keyboard work (with a hdmi display)?
  • Have you tried another serial tool? (there are many, just google for it)
  • How have you installed the bootloader? If you used CompuLab's updater script, have you reset the environment?
  • What bootloader version is installed at the moment (searching through your previous post just yields 2009.x).

The network problem might be related because U-Boot has to pass the MAC-address of the network interface to the kernel --- no MAC-address, no network. It looks like your U-Boot doesn't do its job... it might be just that the environment is too old/had not been updated.

Don01001100 wrote:
What are the relationships between labels and nodes? It seems you can have a label without a node name and address, a node name and address without a label, or both. Does a node without a node name and address have an implicit node address (and maybe an implicit node name)?

We have to differentiate here between the description language and what we are describing. A node in the devicetree has always a name and a path (just like in a filesystem). Labels are syntactic sugar of the description language to refer to existing nodes, e.g. to add properties or subnodes). I think it's best to look at an example. Let's consider the node that describes the mmc controller used in the Utilite (the thing that talks to your sd card). It is a device built into the SoC and it is a common device of the DualLite/Solo and the Dual/Quad SoCs. Hence, it is defined imx6qdl.dtsi.
The node describing it has the name usdhc@2198000 (the @address part is a convention; it is the same address as given in the reg property).
It's path is /soc/aips-bus@2100000/usdhc@2198000 . (note that the soc node has no @-part, so we know it doesn't have an address.)

The mmc-controller is disabled by default because not all boards are using it. Thus, we have to enable it. We could do that as follows.
Code:
#include "imx6qdl.dtsi"

/ {
  soc {
    aips-bus@2100000 {
      usdhc@2198000 {
        status = "okay";
      };
    };
  };
};

The devicetree compiler would just merge the two trees (the one defined in imx6qdl.dtsi and the small one above to enable the mmc-controller).
However, this is quite cumpersome, image we would have to do this for every device we want to enable. Luckily, in imx6qdl.dtsi there is already defined a label for this node:
Code:
usdhc3: usdhc@2198000 {
  ...
};

The label is the part in front of the double dot ":". Now we can achieve the same as above by simply writing
Code:
#include "imx6qdl.dtsi"

&usdhc3 {
  status = "okay";
};

The ampersand characters tells the compiler that usdhc3 is not a node name but a label. Note that the compiler will replace (modulo formatting) the latter description with the former one --- labels are syntactic sugar.
This is more or less what happens at the bottom of imx6q-utilite-pro.dts (okay, a few more properties are added).

Most board devicetress are structured as the imx6q-utilite-pro.dts: first new devices are defined (on the board level). These are -- naturally -- children of the root node / { ... }; Afterwards, devices on the SoC-level are enabled and properties are added (e.g. connections to devices on the board are descripted, which pins are they routed to, etc.). These nodes are referenced by labels.

Don01001100 wrote:
What does the ampersand character mean? Does it have different meanings in different contexts? I gather one use is as a "phandle", which 1) is a reference to another node and 2) is conceptually similar to the & operator in C/C++ in that it gets an "address" of sorts. Is that right?

It means what follows is not a name but a label. One usage of labels we have already seen above. If a label occurs on the right hand side of an assignment ("="), the semantics are slightly different: the compiler will replace the label by the path of the node. For instance, in imx6q-utilite-pro.dts the pinctrl-0 property of the mmc-controller references the pin-control nodes which describe the configurations of the pins associated to the mmc-controller.

Actually, the compiler goes even further and replaces paths and labels by jump marks but IMHO this is just a technicallity and not important.

Don01001100 wrote:
There are nodes/labels in imx6q-utilite-pro.dts where the label starts with &. What does & mean in that context?

I hope that became clear. labels (except for their definitions) start with &, everything else is a name.

Don01001100 wrote:
Is it accurate to say that the DTS is basically a description of a blob of bytes to be loaded into memory? (Hence DTB -- device tree blob?)

Well, technically everything is a blob of bytes ;-). It's true that dtb can be read as device tree blob and is machine readable, while the dts (device tree source) is for us humans. You can translate them both ways (take a look at the dtc compiler used above, if you try this, you'll note that, when translating back into dts, there will be no labels and all trees are merged (every node appears only once).

Don01001100 wrote:
Some property names seem to sometimes have special meaning. Are these defined higher up in the "include chain" or somewhere higher beyond that? For example, "aliases" seems to mean something special.

Yes, there are nodes with a special meaning but they are not special syntactically. "aliases" for example is defined as a usual node. The definition in imx6q-utilite-pro.dts is merged with all /aliases nodes defined before it (in the files included) -- just like for every other node.

The /aliases node is "abused" by Linux to assign static device names, hence, why e.g. rtc0 and rtc1 are defined. It is also used by U-Boot to find the ethernet devices and assign the MAC-addresses. In some way the /aliases node provides "labels" for the machines.

Don01001100 wrote:
Are #address-cells and #size-cells inherited by child nodes?

I don't think so but I'm not sure...

Don01001100 wrote:
Is #address-cells the memory address of a register? (It's been a while since my computer architecture class and since I last did assembly programming, but what does it even mean for a register to have an address? Are the registers in ARM just memory locations?)

Do reg properties get assigned the first n cells based on #address-cells and then the next m cells based on #size-cells? As in, would #address-cells = 2; #size-cells = 0; reg = <1 2>; mean that a register address is described by a 64-bit number that is some combination of the bit representations of 1 and 2? And if #address0cells = 1; #size-cells = 1; had been specified instead, would that mean an address of 1 and a size of 64 bits? (2 specified in the second cell meaning two 32-bit cells?)

Not quite. On a 32-bit architecture each cell has 32-bit and #*-cells defines how many cells of the reg property value belong to the address part and how many to the size part -- so far so good. Usually, the address cells contain the address of the first register that belongs to the device. While most devices have a fixed number of registers, some don't (i.e. imagine a dma engine). For these devices the size cells specify the size/end of the memory region belonging to this device.

Note that this is just the common usage. There are others. For example, you can specify partitions in the devicetree. Then the address cells specify where the partition starts and the size-cells how big it is.

I hope this helps :-).
Cheers,
Christopher


Wed Jan 03, 2018 8:06 pm
Profile

Joined: Sun Jul 13, 2014 6:16 pm
Posts: 23
Location: Queens, New York City
Post Re: Utilite Value won't boot; just black screen
Good news and just news! The good news is that I got the terminal working, and I can also SSH into the device. The just news is that I don't know how I got the terminal working. I was messing around with stty, not really knowing what I was doing, and picocom started working. My guess is that icrln did the trick. I also had tried switching to the rear serial port on the Utilite and accidentally disconnected the HDMI cable. But progress!

I've taken a quick glance at your response, Chris, and I'm going to give it a more thorough read this weekend and see if I can make some progress. Thank you for your exhaustive reply!

edit: Oh, and I only stumbled across stty because I was looking into your suggestion to try an alternative to picocom and was trying to get screen to work. Anyway, like I said, progress!

edit: And, for posterity's sake, since who knows if this will come up in a web search one day, probably by me! Here are the TTY settings I was using when they were successful.

Code:
$ sudo stty -a -F /dev/ttyUSB0
speed 115200 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^H; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke -flusho -extproc


Fri Jan 05, 2018 5:23 am
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 32 posts ]  Go to page Previous  1, 2, 3, 4  Next

Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by STSoftware for PTF.