Trying to update firmware on a hikey that was previously running u-boot just fine, I followed the "Board Recovery" section of the Getting Started page[1], but end up with the init sequence getting stuck in TEE-CORE init (console log below[2])
Any ideas what's going wrong?
I'm trying to update the firmware so I get serial output on the UART board. I'm currently only using the UART pins on the main board.
Kevin
[1] https://github.com/96boards/documentation/wiki/HiKeyGettingStarted#section-4
[2] debug EMMC boot: print init OK debug EMMC boot: send RST_N . debug EMMC boot: start eMMC boot...... load fastboot1!
Switch to aarch64 mode. CPU0 executes at 0xf9801000! INF TEE-CORE:init_primary_helper:322: Initializing (2f04385 #2 Sat Nov 28 10:50:14 UTC 2015 aarch64) INF TEE-CORE:init_teecore:81: teecore inits done
On 12/02/2015 06:57 PM, Kevin Hilman wrote:
Trying to update firmware on a hikey that was previously running u-boot just fine, I followed the "Board Recovery" section of the Getting Started page[1], but end up with the init sequence getting stuck in TEE-CORE init (console log below[2])
Any ideas what's going wrong?
I'm trying to update the firmware so I get serial output on the UART board. I'm currently only using the UART pins on the main board.
a couple of days ago I updated my firmware from fastboot to UEFI using the same instructions (4G emmc in my case). The first time I upgraded the bootloader it seems the partition table wasnt properly flashed so I had to do it twice. other than that, it all went smoothly.
did you notice any errors during the upgrade? also, did you update your rootfs (which now contains the kernel in /boot/..?)
I know this doesnt quite answer your question but I didnt hit the problem you are seeing and I havent done much work with op-tee
On 12/02/2015 06:57 PM, Kevin Hilman wrote:
debug EMMC boot: print init OK debug EMMC boot: send RST_N . debug EMMC boot: start eMMC boot...... load fastboot1!
actually this doesnt look like a UEFI boot. what bootloader are you programming?
Switch to aarch64 mode. CPU0 executes at 0xf9801000! INF TEE-CORE:init_primary_helper:322: Initializing (2f04385 #2 Sat Nov 28 10:50:14 UTC 2015 aarch64) INF TEE-CORE:init_teecore:81: teecore inits done _______________________________________________
On Wed, Dec 2, 2015 at 4:35 PM, Jorge Ramirez-Ortiz jorge.ramirez-ortiz@linaro.org wrote:
On 12/02/2015 06:57 PM, Kevin Hilman wrote:
debug EMMC boot: print init OK debug EMMC boot: send RST_N . debug EMMC boot: start eMMC boot...... load fastboot1!
actually this doesnt look like a UEFI boot. what bootloader are you programming?
I'm assuming it's UEFI: I followed the "Board Recovery" instructions verbatim: https://github.com/96boards/documentation/wiki/HiKeyGettingStarted#section-4
Kevin
On 12/02/2015 07:43 PM, Kevin Hilman wrote:
On Wed, Dec 2, 2015 at 4:35 PM, Jorge Ramirez-Ortiz jorge.ramirez-ortiz@linaro.org wrote:
On 12/02/2015 06:57 PM, Kevin Hilman wrote:
debug EMMC boot: print init OK debug EMMC boot: send RST_N . debug EMMC boot: start eMMC boot...... load fastboot1!
actually this doesnt look like a UEFI boot. what bootloader are you programming?
I'm assuming it's UEFI: I followed the "Board Recovery" instructions verbatim: https://github.com/96boards/documentation/wiki/HiKeyGettingStarted#section-4
Kevin
what partition table did you use (4G)?
this is what I see during early boot
NOTICE: Booting Trusted Firmware NOTICE: BL1: v1.1(release):e9b4909 NOTICE: BL1: Built : 10:50:16, Nov 28 2015 NOTICE: syspll frequency:1190494208Hz NOTICE: succeed to init lpddr3 rank0 dram phy INFO: lpddr3_freq_init, set ddrc 533mhz INFO: init ddr3 rank0 INFO: ddr3 rank1 init pass INFO: lpddr3_freq_init, set ddrc 800mhz INFO: init ddr3 rank0 INFO: ddr3 rank1 init pass INFO: Elpida DDR
... ...
seems to me UEFI wasnt updated
Hi Kevin,
On Thu, Dec 3, 2015 at 9:53 AM, Jorge Ramirez-Ortiz jorge.ramirez-ortiz@linaro.org wrote:
On 12/02/2015 07:43 PM, Kevin Hilman wrote:
On Wed, Dec 2, 2015 at 4:35 PM, Jorge Ramirez-Ortiz jorge.ramirez-ortiz@linaro.org wrote:
On 12/02/2015 06:57 PM, Kevin Hilman wrote:
debug EMMC boot: print init OK debug EMMC boot: send RST_N . debug EMMC boot: start eMMC boot...... load fastboot1!
actually this doesnt look like a UEFI boot. what bootloader are you programming?
I'm assuming it's UEFI: I followed the "Board Recovery" instructions verbatim: https://github.com/96boards/documentation/wiki/HiKeyGettingStarted#section-4
Kevin
what partition table did you use (4G)?
this is what I see during early boot
NOTICE: Booting Trusted Firmware NOTICE: BL1: v1.1(release):e9b4909 NOTICE: BL1: Built : 10:50:16, Nov 28 2015 NOTICE: syspll frequency:1190494208Hz NOTICE: succeed to init lpddr3 rank0 dram phy INFO: lpddr3_freq_init, set ddrc 533mhz INFO: init ddr3 rank0 INFO: ddr3 rank1 init pass INFO: lpddr3_freq_init, set ddrc 800mhz INFO: init ddr3 rank0 INFO: ddr3 rank1 init pass INFO: Elpida DDR
The main board is UART0, while the serial output on the UART board is UART3. All serial outputs (arm-tf, op-tee, uefi and kernel) used to be on UART0. Later arm-tf (except bl1), uefi and kernel moved to UART3, so you should see [2] on UART0 and then booting (log directly above) should continue on UART3, assuming you're using a recent enough image.
Are you not seeing anything on your console terminal connected to UART3?
... ...
seems to me UEFI wasnt updated _______________________________________________ Dev mailing list Dev@lists.96boards.org https://lists.96boards.org/mailman/listinfo/dev
Victor Chong victor.chong@linaro.org writes:
[...]
The main board is UART0, while the serial output on the UART board is UART3. All serial outputs (arm-tf, op-tee, uefi and kernel) used to be on UART0. Later arm-tf (except bl1), uefi and kernel moved to UART3, so you should see [2] on UART0 and then booting (log directly above) should continue on UART3, assuming you're using a recent enough image.
aaaaah! I wasn't expecting partial output on UART0, then on UART3.
After setting the right jumper settings on the UART board, I'm now seeing the BL1 on UART0 and the rest on UART3 (a.k.a. UART1 on the UART board... which is also confusing.)
Thanks for the explanation and the help.
Next step, built a mainline u-boot that's using the UART board...
Kevin
On Thursday, December 3, 2015, Kevin Hilman <khilman@kernel.org javascript:_e(%7B%7D,'cvml','khilman@kernel.org');> wrote:
aaaaah! I wasn't expecting partial output on UART0, then on UART3.
Yea.. the partial output can usually be ignored for the most part unless you're working on those components directly.
After setting the right jumper settings on the UART board, I'm now
seeing the BL1 on UART0 and the rest on UART3 (a.k.a. UART1 on the UART
board... which is also confusing.)
Oh right. You can set the jumper to UART0 as well if you don't have the 4-pin header on the main board so I guess technically the UART board is both 0 and 3, not just 3 (or 1 if we want to confuse ourselves further :s).
Thanks for the explanation and the help.
You're welcome.
Next step, built a mainline u-boot that's using the UART board...
Fyi both arm-tf and edk2 have a build time option to use UART0 for those who prefer it. Not sure if that's required for u-boot or not. For the kernel you can just change the boot command line to use UART0 so no rebuilding required. See https://github.com/96boards/documentation/wiki/HiKeyUEFI for details.
Kevin
On 3 Dec 2015 07:46, "Victor Chong" victor.chong@linaro.org wrote:
On Thursday, December 3, 2015, Kevin Hilman khilman@kernel.org wrote:
aaaaah! I wasn't expecting partial output on UART0, then on UART3.
Yea.. the partial output can usually be ignored for the most part unless
you're working on those components directly.
After setting the right jumper settings on the UART board, I'm now
seeing the BL1 on UART0 and the rest on UART3 (a.k.a. UART1 on the UART board... which is also confusing.)
It's more confusing than that. The UART board gives you UART2 & UART3. UART0 isn't available to it.
g.
Oh right. You can set the jumper to UART0 as well if you don't have the
4-pin header on the main board so I guess technically the UART board is both 0 and 3, not just 3 (or 1 if we want to confuse ourselves further :s).
Thanks for the explanation and the help.
You're welcome.
Next step, built a mainline u-boot that's using the UART board...
Fyi both arm-tf and edk2 have a build time option to use UART0 for those
who prefer it. Not sure if that's required for u-boot or not. For the kernel you can just change the boot command line to use UART0 so no rebuilding required. See https://github.com/96boards/documentation/wiki/HiKeyUEFI for details.
Kevin
Dev mailing list Dev@lists.96boards.org https://lists.96boards.org/mailman/listinfo/dev
On Thu, Dec 3, 2015 at 5:07 PM, Grant Likely glikely@secretlab.ca wrote:
On 3 Dec 2015 07:46, "Victor Chong" victor.chong@linaro.org wrote:
On Thursday, December 3, 2015, Kevin Hilman khilman@kernel.org wrote:
aaaaah! I wasn't expecting partial output on UART0, then on UART3.
Yea.. the partial output can usually be ignored for the most part unless you're working on those components directly.
After setting the right jumper settings on the UART board, I'm now
seeing the BL1 on UART0 and the rest on UART3 (a.k.a. UART1 on the UART board... which is also confusing.)
It's more confusing than that. The UART board gives you UART2 & UART3. UART0 isn't available to it.
Oh, sorry for the confusion! I've always thought that UART0 on the UART board gives you UART0 and UART1 give you UART3. So I guess UART0 gives you UART2 and UART1 gives your UART3. Yikes..
g.
Oh right. You can set the jumper to UART0 as well if you don't have the 4-pin header on the main board so I guess technically the UART board is both 0 and 3, not just 3 (or 1 if we want to confuse ourselves further :s).
Thanks for the explanation and the help.
You're welcome.
Next step, built a mainline u-boot that's using the UART board...
Fyi both arm-tf and edk2 have a build time option to use UART0 for those who prefer it. Not sure if that's required for u-boot or not. For the kernel you can just change the boot command line to use UART0 so no rebuilding required. See https://github.com/96boards/documentation/wiki/HiKeyUEFI for details.
Kevin
Dev mailing list Dev@lists.96boards.org https://lists.96boards.org/mailman/listinfo/dev
On 12/03/15 03:41, Victor Chong wrote:
On Thu, Dec 3, 2015 at 5:07 PM, Grant Likely glikely@secretlab.ca wrote:
It's more confusing than that. The UART board gives you UART2 & UART3. UART0 isn't available to it.
Oh, sorry for the confusion! I've always thought that UART0 on the UART board gives you UART0 and UART1 give you UART3. So I guess UART0 gives you UART2 and UART1 gives your UART3. Yikes..
Maybe someone who has this sorted out could draw a diagram and update the wiki?
Grant Likely glikely@secretlab.ca writes:
On 3 Dec 2015 07:46, "Victor Chong" victor.chong@linaro.org wrote:
On Thursday, December 3, 2015, Kevin Hilman khilman@kernel.org wrote:
aaaaah! I wasn't expecting partial output on UART0, then on UART3.
Yea.. the partial output can usually be ignored for the most part unless
you're working on those components directly.
After setting the right jumper settings on the UART board, I'm now seeing the BL1 on UART0 and the rest on UART3 (a.k.a. UART1 on the UART board... which is also confusing.)
It's more confusing than that. The UART board gives you UART2 & UART3. UART0 isn't available to it.
I suspect it's likely that hikey will not be the only one to have SoC UART numbering different that the UART board numbering. Maybe the UART board options should have different names, like UART_A and UART_B ?
Kevin
On 3 Dec 2015 22:32, "Kevin Hilman" khilman@kernel.org wrote:
Grant Likely glikely@secretlab.ca writes:
On 3 Dec 2015 07:46, "Victor Chong" victor.chong@linaro.org wrote:
On Thursday, December 3, 2015, Kevin Hilman khilman@kernel.org wrote:
aaaaah! I wasn't expecting partial output on UART0, then on UART3.
Yea.. the partial output can usually be ignored for the most part
unless
you're working on those components directly.
After setting the right jumper settings on the UART board, I'm now seeing the BL1 on UART0 and the rest on UART3 (a.k.a. UART1 on the
UART
board... which is also confusing.)
It's more confusing than that. The UART board gives you UART2 & UART3. UART0 isn't available to it.
I suspect it's likely that hikey will not be the only one to have SoC UART numbering different that the UART board numbering. Maybe the UART board options should have different names, like UART_A and UART_B ?
FWIW, I've been referring to them as LS-UART0 and LS-UART1. I agree that we should have a consistent naming convention. Same goes for the i2c buses.
g.
Kevin
On 04/12/15 01:09, Grant Likely wrote:
On 3 Dec 2015 22:32, "Kevin Hilman" <khilman@kernel.org mailto:khilman@kernel.org> wrote:
Grant Likely <glikely@secretlab.ca mailto:glikely@secretlab.ca> writes:
On 3 Dec 2015 07:46, "Victor Chong" <victor.chong@linaro.org
mailto:victor.chong@linaro.org> wrote:
On Thursday, December 3, 2015, Kevin Hilman <khilman@kernel.org
mailto:khilman@kernel.org> wrote:
aaaaah! I wasn't expecting partial output on UART0, then on UART3.
Yea.. the partial output can usually be ignored for the most part
unless
you're working on those components directly.
After setting the right jumper settings on the UART board, I'm now seeing the BL1 on UART0 and the rest on UART3 (a.k.a. UART1 on
the UART
board... which is also confusing.)
It's more confusing than that. The UART board gives you UART2 & UART3. UART0 isn't available to it.
I suspect it's likely that hikey will not be the only one to have SoC UART numbering different that the UART board numbering. Maybe the UART board options should have different names, like UART_A and UART_B ?
FWIW, I've been referring to them as LS-UART0 and LS-UART1. I agree that we should have a consistent naming convention. Same goes for the i2c buses.
That's exactly the terminology I've been using too (and I think independently).
Adding an LS- prefix does still risk confusion but is much easy to apply retrospectively to the specs...
Daniel.
On 12/3/15 4:32 PM, Kevin Hilman wrote:
Grant Likely glikely@secretlab.ca writes:
On 3 Dec 2015 07:46, "Victor Chong" victor.chong@linaro.org wrote:
On Thursday, December 3, 2015, Kevin Hilman khilman@kernel.org wrote:
aaaaah! I wasn't expecting partial output on UART0, then on UART3.
Yea.. the partial output can usually be ignored for the most part unless
you're working on those components directly.
After setting the right jumper settings on the UART board, I'm now seeing the BL1 on UART0 and the rest on UART3 (a.k.a. UART1 on the UART board... which is also confusing.)
It's more confusing than that. The UART board gives you UART2 & UART3. UART0 isn't available to it.
I suspect it's likely that hikey will not be the only one to have SoC UART numbering different that the UART board numbering. Maybe the UART board options should have different names, like UART_A and UART_B ?
It's the reason why we have UDEV rules now making the two UARTs on the LS connector /dev/tty96B0 and /dev/tty96B1 get rid of the confusion and make it MUCH easier to document things.
Kevin _______________________________________________ Dev mailing list Dev@lists.96boards.org https://lists.96boards.org/mailman/listinfo/dev
On Thu, Dec 3, 2015 at 10:35 PM, David Mandala davidm@linaro.org wrote:
On 12/3/15 4:32 PM, Kevin Hilman wrote:
Grant Likely glikely@secretlab.ca writes:
On 3 Dec 2015 07:46, "Victor Chong" victor.chong@linaro.org wrote:
On Thursday, December 3, 2015, Kevin Hilman khilman@kernel.org wrote:
aaaaah! I wasn't expecting partial output on UART0, then on UART3.
Yea.. the partial output can usually be ignored for the most part unless
you're working on those components directly.
After setting the right jumper settings on the UART board, I'm now seeing the BL1 on UART0 and the rest on UART3 (a.k.a. UART1 on the UART board... which is also confusing.)
It's more confusing than that. The UART board gives you UART2 & UART3. UART0 isn't available to it.
I suspect it's likely that hikey will not be the only one to have SoC UART numbering different that the UART board numbering. Maybe the UART board options should have different names, like UART_A and UART_B ?
It's the reason why we have UDEV rules now making the two UARTs on the LS connector /dev/tty96B0 and /dev/tty96B1 get rid of the confusion and make it MUCH easier to document things.
Please, no!
First, that only helps userspace. When I go add "console=tty96B0" and it doesn't work...
Second, now we need udev rules for every board. That will be fun when we have 96 of them.
We already have big enough problem with tty naming being: tty<some random soc naming>n. Ask the OMAP folks about how fun changing names was. IMO, we should move towards everything being ttySn.
We have aliases in DT to provide consistent numbering. We should use that so LS connector UARTs are consistently numbered. Alternatively, we could use "label" properties to provide standard labels. That is what label is for: providing a human readable label.
Anything in userspace that is 96boards specific is a flawed solution. These problems have nothing to do with 96boards, but are shortcomings in the kernel interfaces. Lets fix those and not be working around them.
Rob
Rob Herring rob.herring@linaro.org writes:
On Thu, Dec 3, 2015 at 10:35 PM, David Mandala davidm@linaro.org wrote:
[...]
It's the reason why we have UDEV rules now making the two UARTs on the LS connector /dev/tty96B0 and /dev/tty96B1 get rid of the confusion and make it MUCH easier to document things.
[...]
Anything in userspace that is 96boards specific is a flawed solution. These problems have nothing to do with 96boards, but are shortcomings in the kernel interfaces. Lets fix those and not be working around them.
+1
Much better said than the rant I had written up but deleted.
Kevin
On 12/8/15 12:10 PM, Kevin Hilman wrote:
Rob Herring rob.herring@linaro.org writes:
On Thu, Dec 3, 2015 at 10:35 PM, David Mandala davidm@linaro.org wrote:
[...]
It's the reason why we have UDEV rules now making the two UARTs on the LS connector /dev/tty96B0 and /dev/tty96B1 get rid of the confusion and make it MUCH easier to document things.
[...]
Anything in userspace that is 96boards specific is a flawed solution. These problems have nothing to do with 96boards, but are shortcomings in the kernel interfaces. Lets fix those and not be working around them.
+1
Much better said than the rant I had written up but deleted.
Kevin
I agree that the kernel space is the proper place to fix this but it will likely take years for that to happen, feel free to shock me and have a fix in the next kernel cycle. ;-P
David Mandala davidm@linaro.org writes:
On 12/8/15 12:10 PM, Kevin Hilman wrote:
Rob Herring rob.herring@linaro.org writes:
On Thu, Dec 3, 2015 at 10:35 PM, David Mandala davidm@linaro.org wrote:
[...]
It's the reason why we have UDEV rules now making the two UARTs on the LS connector /dev/tty96B0 and /dev/tty96B1 get rid of the confusion and make it MUCH easier to document things.
[...]
Anything in userspace that is 96boards specific is a flawed solution. These problems have nothing to do with 96boards, but are shortcomings in the kernel interfaces. Lets fix those and not be working around them.
[...]
I agree that the kernel space is the proper place to fix this but it will likely take years for that to happen, feel free to shock me and have a fix in the next kernel cycle. ;-P
It's taking many years because 96boards kernel development isn't focused on upstream. Instead, it's focused primarily on Linaro releases. Getting a DT fix like this upstream could happen very quickly, but first there has to be a willingnes to submit it.
Also, the other problem with the userspace fix you propose it assumes folks are actually using Linaro releases and/or willing to modify their host systems in 96boards-specifid ways. Not always a safe assumption.
Kevin
On 12/8/15 12:54 PM, Kevin Hilman wrote:
David Mandala davidm@linaro.org writes:
On 12/8/15 12:10 PM, Kevin Hilman wrote:
Rob Herring rob.herring@linaro.org writes:
On Thu, Dec 3, 2015 at 10:35 PM, David Mandala davidm@linaro.org wrote:
[...]
It's the reason why we have UDEV rules now making the two UARTs on the LS connector /dev/tty96B0 and /dev/tty96B1 get rid of the confusion and make it MUCH easier to document things.
[...]
Anything in userspace that is 96boards specific is a flawed solution. These problems have nothing to do with 96boards, but are shortcomings in the kernel interfaces. Lets fix those and not be working around them.
[...]
I agree that the kernel space is the proper place to fix this but it will likely take years for that to happen, feel free to shock me and have a fix in the next kernel cycle. ;-P
It's taking many years because 96boards kernel development isn't focused on upstream. Instead, it's focused primarily on Linaro releases. Getting a DT fix like this upstream could happen very quickly, but first there has to be a willingnes to submit it.
Also, the other problem with the userspace fix you propose it assumes folks are actually using Linaro releases and/or willing to modify their host systems in 96boards-specifid ways. Not always a safe assumption.
No for sure not a safe assumption, and while I've been known to be stupid, I'm not quite that stupid, so I make sure that all documentation I write, tells you how to tell if you need the udev file and points at github where the udev files and doc's are stored. If you are using your own build you can add the needed rule file and use it, or not if you prefer not to.
David
Kevin
On Tue, Dec 8, 2015 at 12:20 PM, David Mandala davidm@linaro.org wrote:
On 12/8/15 12:10 PM, Kevin Hilman wrote:
Rob Herring rob.herring@linaro.org writes:
On Thu, Dec 3, 2015 at 10:35 PM, David Mandala davidm@linaro.org wrote:
[...]
It's the reason why we have UDEV rules now making the two UARTs on the LS connector /dev/tty96B0 and /dev/tty96B1 get rid of the confusion and make it MUCH easier to document things.
[...]
Anything in userspace that is 96boards specific is a flawed solution. These problems have nothing to do with 96boards, but are shortcomings in the kernel interfaces. Lets fix those and not be working around them.
+1
Much better said than the rant I had written up but deleted.
Kevin
I agree that the kernel space is the proper place to fix this but it will likely take years for that to happen, feel free to shock me and have a fix in the next kernel cycle. ;-P
It's simply a matter of adding label properties to UARTs in dts files and defining the strings to use. I feel confident the DT maintainers would be okay with that. Then you have to get that information, and there are a couple of ways we could do that. The first is already supported. You just have to mine sysfs for it:
for f in $(ls -d /sys/class/tty/tty*); do label=$(cat $f/device/of_node/label) if [ "$label" = "LS-UART1" ]; then # you've found UART1, so do something with it. # $f/dev is the major:minor for the /dev node fi done
We could also expose it in a path that is not DT specific (in case there's ever any other firmware inferface we care about). That could either be generically done for any device with a label property or for tty devices in particular.
What concerns me more is not this specific case, but what are other problems like this in general. These are all problems easy enough to work-around in userspace for a handful of boards. But let's stop doing that and push these problems back to engineering teams. Sure, sometimes the answer may be it will take years, but don't assume that or not ask for it.
Rob
On 8 December 2015 at 18:06, Rob Herring rob.herring@linaro.org wrote:
On Thu, Dec 3, 2015 at 10:35 PM, David Mandala davidm@linaro.org wrote:
On 12/3/15 4:32 PM, Kevin Hilman wrote:
Grant Likely glikely@secretlab.ca writes:
On 3 Dec 2015 07:46, "Victor Chong" victor.chong@linaro.org wrote:
On Thursday, December 3, 2015, Kevin Hilman khilman@kernel.org wrote:
aaaaah! I wasn't expecting partial output on UART0, then on UART3.
Yea.. the partial output can usually be ignored for the most part unless
you're working on those components directly.
After setting the right jumper settings on the UART board, I'm now seeing the BL1 on UART0 and the rest on UART3 (a.k.a. UART1 on the UART board... which is also confusing.)
It's more confusing than that. The UART board gives you UART2 & UART3. UART0 isn't available to it.
I suspect it's likely that hikey will not be the only one to have SoC UART numbering different that the UART board numbering. Maybe the UART board options should have different names, like UART_A and UART_B ?
It's the reason why we have UDEV rules now making the two UARTs on the LS connector /dev/tty96B0 and /dev/tty96B1 get rid of the confusion and make it MUCH easier to document things.
Please, no!
First, that only helps userspace. When I go add "console=tty96B0" and it doesn't work...
Second, now we need udev rules for every board. That will be fun when we have 96 of them.
It gets better, have a look at the actual udev rule:
https://github.com/96boards/96boards-tools/blob/master/70-96boards-common.ru...
Udev rules used to provide a common UART device name across different boards # DragonBoard 410c KERNEL=="ttyMSM1", SYMLINK+="tty96B0" KERNEL=="ttyMSM0", SYMLINK+="tty96B1" # HiKey KERNEL=="ttyAMA2", SYMLINK+="tty96B0" KERNEL=="ttyAMA3", SYMLINK+="tty96B1"
I'm eagerly awaiting the next board that is using ARM or QC UART IP and hooks up the ports in a different order.
We already have big enough problem with tty naming being: tty<some random soc naming>n. Ask the OMAP folks about how fun changing names was. IMO, we should move towards everything being ttySn.
We have aliases in DT to provide consistent numbering. We should use that so LS connector UARTs are consistently numbered. Alternatively, we could use "label" properties to provide standard labels. That is what label is for: providing a human readable label.
Anything in userspace that is 96boards specific is a flawed solution. These problems have nothing to do with 96boards, but are shortcomings in the kernel interfaces. Lets fix those and not be working around them.
Rob _______________________________________________ Dev mailing list Dev@lists.96boards.org https://lists.96boards.org/mailman/listinfo/dev
gmail did something funny the first time sending this, retrying
---------- Forwarded message ---------- From: Koen Kooi koen.kooi@linaro.org Date: 9 December 2015 at 08:15 Subject: Re: [Dev] Board recovery fail: stuck in TEE-CORE init To: Rob Herring rob.herring@linaro.org Cc: David Mandala davidm@linaro.org, _=e2=80=8e?= dev@lists.96boards.org, =?UTF-8?Q?dev_=e2=80=8e_@lists.96boards.org
On 8 December 2015 at 18:06, Rob Herring rob.herring@linaro.org wrote:
On Thu, Dec 3, 2015 at 10:35 PM, David Mandala davidm@linaro.org wrote:
On 12/3/15 4:32 PM, Kevin Hilman wrote:
Grant Likely glikely@secretlab.ca writes:
On 3 Dec 2015 07:46, "Victor Chong" victor.chong@linaro.org wrote:
On Thursday, December 3, 2015, Kevin Hilman khilman@kernel.org wrote:
aaaaah! I wasn't expecting partial output on UART0, then on UART3.
Yea.. the partial output can usually be ignored for the most part unless
you're working on those components directly.
After setting the right jumper settings on the UART board, I'm now seeing the BL1 on UART0 and the rest on UART3 (a.k.a. UART1 on the UART board... which is also confusing.)
It's more confusing than that. The UART board gives you UART2 & UART3. UART0 isn't available to it.
I suspect it's likely that hikey will not be the only one to have SoC UART numbering different that the UART board numbering. Maybe the UART board options should have different names, like UART_A and UART_B ?
It's the reason why we have UDEV rules now making the two UARTs on the LS connector /dev/tty96B0 and /dev/tty96B1 get rid of the confusion and make it MUCH easier to document things.
Please, no!
First, that only helps userspace. When I go add "console=tty96B0" and it doesn't work...
Second, now we need udev rules for every board. That will be fun when we have 96 of them.
It gets better, have a look at the actual udev rule:
https://github.com/96boards/96boards-tools/blob/master/70-96boards-common.ru...
Udev rules used to provide a common UART device name across different boards # DragonBoard 410c KERNEL=="ttyMSM1", SYMLINK+="tty96B0" KERNEL=="ttyMSM0", SYMLINK+="tty96B1" # HiKey KERNEL=="ttyAMA2", SYMLINK+="tty96B0" KERNEL=="ttyAMA3", SYMLINK+="tty96B1"
I'm eagerly awaiting the next board that is using ARM or QC UART IP and hooks up the ports in a different order.
-
Daniel Thompson -
David Mandala -
Grant Likely -
Jorge Ramirez-Ortiz -
Kevin Hilman -
Koen Kooi -
Rob Herring -
Trevor Woerner -
Victor Chong