14 Replies Latest reply on May 26, 2014 7:32 AM by colinbes

    BBB, BB-View and I2C port usage


      I am using  a BeagleBone Black with Angstrom OS and BB-View 4.3 inch LCD and am needing to use i2c as well.


      I see that the bb-view uses pins P9-17/18 which are i2c1 but that is also uses P-20 as GPIO for LED1.


      Question is, can I still somehow use I2C 2 (Pins P9_19/20) as I2C? Can I somehow disable LCD's use of this pin?



        • Re: BBB, BB-View and I2C port usage

          Since we don't have schematics, it's difficult to be 100% sure, however there appears to be nothing on the board that uses P9 17/18.  Those are connected to U26 on the underside of the board, but that's not installed. They also connect to pins 42 & 43 on the LCD connector, however on the 4.3" lcd board there's nothing connected to them.


          As for P9.20, it's connected via R52 to Q17, so as long as this doesn't load I2C2_SDA significantly then it should be possible to use. If not, then at the risk of your warranty, that can be fixed with a soldering iron easily enough.

          Either way, you'll need to make appropriate devicetree modifications in order to use it as i2c.


          Even if we were to assume that i2c1 really is in use, then you can still connect something to it as long as the address of the i2c device you're connecting does not conflict with whatever address the BB-View might be using.


          Whether the 7" version is the same I don't know, I have a 4.3" one myself.

            • Re: BBB, BB-View and I2C port usage

              As much as I like BBB and it's supported capes I must say it is extremely frustrating trying to get stuff to work - one of the downsides of configurability I guess. Too many options, too little documentation.


              I am not sure you can use I2C1 if it is being assigned by LCD Cape - I am not sure how to reconfigure cape, especially as we don't have access to dts file.


              Thanks for responding.



                • Re: BBB, BB-View and I2C port usage

                  Perhaps you misunderstand how the pieces come together.  The cape 'assigning' i2c1 only causes the two pins to be configured as i2c. It may also configure a driver at one or more i2c addresses on that bus (there are up to 128 devices on an single i2c bus).

                  Any I2C addresses that the cape doesn't configure are free for you to use.


                  The devicetree side is somewhat complex in it's own right, but made much more complex by the addition of the overlay system used by the BBB.

                  Normally, the dts files are available. Often in /lib/firmware along with the compiled dtb files, but that depends on the distro somewhat. However, if they're not available you can use the 'dtc' command (or Device Tree Compiler) to decompile a dtb back into a dts.

                  Doing this isn't ideal as the resulting file has a lot of numeric data where you'd have symbolic names in the original dts, but it is possible to decompile then change something and recompile.


                  The BB-View overlay source files are available in one of the BB-View downloads, I don't remember exactly which one right now, but they are there.

                    • Re: BBB, BB-View and I2C port usage



                      I do understand i2c and it's addressing but may be jumping to conclusions on how various capes use the devices - for example, the BB-View cape uses some analog inputs for touchscreen and due to this I lose access to the remaining unused analogs - I assumed because I can't get I2C to work that I am seeing the same thing.

                        • Re: BBB, BB-View and I2C port usage

                          I think the analog inputs might be a special case there, the hardware behind them is really a touch screen controller, not a simple ADC.

                          The docs say you get the choice of:

                          8 general-purpose ADC channels

                          4-wire TSC with 4 general-purpose ADC channels

                          5-wire TSC with 3 general-purpose ADC channels

                          8-wire TSC

                          I didn't look in detail how the drivers work, but it may simply be a case of having to chose either TSC or ADC driver and both can't access the same peripheral simultaneously.  Or, it may just need some special devicetree magic.

                          Looking at Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt (3.13 kernel source) it looks to be possible to setup a binding that allows both TSC and to use the remaining ADC channels. Not sure if the same would be possible on 3.8.x. The problem is likely to be more related to how any overlay files have been setup. If the BB-View overlay claims all 8 ADC pins, only uses four, and doesn't provide an adc node for the rest then you may not be able to use a second overlay to get the ADC enabled as the pins are claimed by the BB-View but left unused.  You may be able to fix that with some creative editing of the relevant dts files.


                          On the I2C side, I've certainly been able to use multiple devices on one bus even though the i2c bus itself is only configured in one place. So I'm willing to try to help you get it going if you want..

                          1 of 1 people found this helpful
                            • Re: BBB, BB-View and I2C port usage

                              Good input on the ADC site and this is something we may look into in the near future.


                              Good news on the I2C side, this makes me more comfortable. I've dug out the oscilloscope and will do some tests today but I think I may be doing something silly and most probably will need some help (or nudging in right direction. Let me know to touch base with you.



                                • Re: BBB, BB-View and I2C port usage

                                  you might find something useful here


                                  While that was aimed at the RIoTboard not the BBB, it shows what I did just to prove some activity on the i2c pins with use of i2cdetect and i2cdump. There's nothing all that different for the BBB, all the linux tools are the same. Scope is pretty much required to check what you think should be happening really is.. I spent far too long recently with i2c on a cubieboard2 only to find I had connected up SDA and SCL backwards

                                    • Re: Re: BBB, BB-View and I2C port usage

                                      I did some more experiments with scope hooked up to pins. To me it looks like installing BB-View somehow affects I2C operation.

                                      In summary, I started with a clean slate after reflashing BBB with latest Angstrom image. Without doing anything I could view and access two i2c ports, to access all three I needed to add BB-I2C1 to cape manager slots. i2cdetect worked and I could access i2c pins on P9_17/18 and P9_19/20 - I stick to pin numbers as the confusion around names/device/pin assignment is crazy confusing. Both Angstrom and Debian work as expected.

                                      Copying latest BB-View install files and installing as per section 6 in user manual results in i2cdetect accessing different pins (different to native install) and am now only able to access 2 i2c devices and not all three. (Note, device on bus 0 is the internal i2c and is not brought out to header.

                                      Somehow, somewhere BB-View install is seriously effecting i2c usage.


                                      I really don't understand how in native install 'i2cdetect -r 1' accesses pins P9_19/20 and in BB-View install it accesses P9_17/18. I may well be misunderstanding something here but my understanding is that i2c access on pins P9_19/20 is shared across all capes and that change in device bus naming/assignment can not be a good thing.


                                      It appears to me that something is not right with BB-View install.


                                      Willing to help where I can



                                        • Re: Re: BBB, BB-View and I2C port usage

                                          the numbering for /dev/i2c-* is done dynamically, in the order they're registered, so if for example you build a devicetree with only P9.19/20 defined then that becomes /dev/i2c-0

                                          define P9.17/18 after 19/20 in device tree and 17/18 gets to be /dev/i2c-1, swap the order in devicetree and they change in /dev as well.


                                          this obviously gets confusing when you look at the schematics and see i2c1, i2c2, i2c3 but you can get results like

                                          i2c3 = /dev/i2c-0

                                          i2c2 = /dev/i2c-1

                                          i2c1 = /dev/i2c-2


                                          capemgr circumvents this problem as it'll have a more physical view by using a reference inside devicetree to a section like


                                          i2c0: i2c@44e0b000 {

                                          compatible = "ti,omap4-i2c";

                                          #address-cells = <1>;

                                          #size-cells = <0>;

                                          ti,hwmods = "i2c1";

                                          reg = <0x44e0b000 0x1000>;

                                          interrupts = <70>;

                                          status = "enabled";



                                          by using a label like &i2c0 it gets a reference to the i2c bus at physical address 0x44e0b000 at which point it really doesn't care what /dev/i2c-* entry that bus gets.


                                          The /dev/i2c-* entries are actually provided by another driver called i2c-dev purely for userspace access. capemgr will function quite happily when i2c-dev isn't loaded and you have no /dev/i2c-* entries at all. It can do that as it has access to the i2c bus inside the kernel and never actually uses the /dev entries.


                                          Now this can definitely be confusing from a users perspective, but there isn't necessarily anything wrong. Getting yourself to a point where you understand what's happening is always the tricky part, especially when everything just looks wrong.


                                          Behind all of this you also have to consider the pinmux setup, for example the i2c1 pins that you see on P9.17/18  can be reconfigured to instead be presented on P9.24 & P9.26 which might allow you to use P9.17 as SPI0_CS0 and P9.18 as SPI0_DI.  Multiple levels of abstraction means there's multiple points of confusion, a steeper learning curve, and more work involved in trying to decipher what's actually going on.


                                          Anyway, here's a shortcut to work out which /dev/i2c-* entry maps to which physical i2c interface.. On the BBB do the following

                                          root@bblk01:~# ls /sys/class/i2c-dev/ -l

                                          total 0

                                          lrwxrwxrwx 1 root root 0 May 25 17:39 i2c-0 -> ../../devices/ocp.3/44e0b000.i2c/i2c-0/i2c-dev/i2c-0/

                                          lrwxrwxrwx 1 root root 0 May 25 17:39 i2c-1 -> ../../devices/ocp.3/4802a000.i2c/i2c-1/i2c-dev/i2c-1/

                                          lrwxrwxrwx 1 root root 0 May 25 17:39 i2c-2 -> ../../devices/ocp.3/4819c000.i2c/i2c-2/i2c-dev/i2c-2/

                                          the symlinks for the i2c-dev entries point to a path that includes the address used to access the peripheral. You're not quite done there though, you also need to know the pinmux settings to know which physical pins the peripheral has been mapped onto.  You can either use the devicetree source to determine that, or if you have debugfs enabled then you can find a lot of details under /sys/kernel/debug/pinctrl/44e10800.pinmux/*

                                          As you're probably noticing, most of the references you're seeing are to physical addresses like 44e0b000, so you end up needing to have a copy of the TI AM335x Technical Reference Manual open in another window so that you can work out what the numbers mean.


                                          Unfortunately, another problem is that as you switch between Angstrom, Debian and 3.8.x or 3.13/14 kernel versions then some of the details change... it may be as simple as the paths linked to in /sys/class/i2c-dev/ have ocp.5 instead of ocp.3, or the devicetree could have changed drastically and present you with a very different viewpoint.

                                          Some of these reasons combine to mean that it's not necessarily simple, or even a good idea, to try to compare things between different versions of angstrom, never mind between angstrom and debian.  The one thing that will stay constant is those 44e0b000 type addresses as they're defined by the hardware.


                                          In a lot of this stuff, we may be able to point you in the right direction, or try to explain some things. Getting your head around it to the point where you're comfortable with how it all fits together is something only you can do.  We'll help as much as we can,...

                                            • Re: Re: BBB, BB-View and I2C port usage

                                              I get all the potential confusion and mapping of devices, my explanation may be a bit terse but you can see from my findings that after installing BB-View image (which is scary in itself to even have to do this) that I lose access to an I2C port. I also agree on dangers of comparing debian/angstrom etc, although they tie up perfectly taking everything into account.


                                              One of the reasons I hooked an oscilloscope up and refer to actual pin access is to have a universal language and bypass confusion of what i2c-x means - at the end of the day if I don't mess with device tree I should see no change in devices. The device that is missing is managed at board level so not being able to access it (control of pins P9_19/20) is really confusing.


                                              What you don't address is where my missing i2c device to control pins P9_19/20 is and whether there is any explanation for this. Loading BB-View should not make this I2C device unavailable, especially considering its board level function. Now maybe I am kidding myself on what I understand and don't understand but I don't think so, but am open to learning and helping.


                                              In my case, after installing BB-View and loading BB-I2C1, ls /sys/class/i2c-dev/ -l only shows two I2C devices, not three as you show. Note that prior to installing BB-View I see all three as you show,  this is the main issue - I lose I2C which drives pins P9_19/20 which should never be lost as they are used by capes at board level themselves.


                                              Appreciate you taking the time and look forward to suggestions to debug this.


                                              As a thought, could this device be 'gone' due to GPIO assignment on pin P9_20 - this would appear to be a mistake to me.



                                                • Re: Re: BBB, BB-View and I2C port usage

                                                  Each physical pin can have up to eight different possible functions, but only one function can be enabled at a time. So yes, if the pin is being used for GPIO you can't also use it for i2c. If you try using overlays then the overlay will fail to load as there's a conflict of two things trying to use the same pin.

                                                  Even if not using overlays, two pinmux definitions for the same pin will cause an error message and the second function will fail to bind. When that happens, the driver won't load any the device you're looking for never appears.


                                                  When you say 'installing BB-View' what exactly do you mean?  Are you installing the complete BB-View angstrom image ?  Or just loading the BB-View dtbo file into an existing angstrom ? (with something like echo BB-VIEW-43-* > $SLOTS)

                                                  Simply loading a new overlay shouldn't cause anything to disappear, so if you do something like

                                                  ls /dev/i2c* and see three devices..

                                                  then do (without a reboot)

                                                  echo BB-VIEW > $SLOTS

                                                  ls /dev/i2c*

                                                  you should not see any change in available i2c devices. Although the overlay may fail to load if there's a conflict...


                                                  However, if you wipe the OS and reinstall something else the base devicetree may not be the same, if the new OS doesn't provide all three i2c busses even before it loads the BB-View overlay then your starting point is different and it's unlikely to be the BB-View itself that's causing it.


                                                  Anyway, here's what I see on a vanilla A5C BBB with the factory Angstrom image:


                                                  The Angstrom Distribution beaglebone ttyO0


                                                  Angstrom v2012.12 - Kernel 3.8.13


                                                  root@beaglebone:~# ls -l /dev/i2c*

                                                  crw------- 1 root root 89, 0 Jan  1 00:00 /dev/i2c-0

                                                  crw------- 1 root root 89, 1 Jan  1 00:00 /dev/i2c-1

                                                  root@beaglebone:~# i2cdetect -r 1

                                                  WARNING! This program can confuse your I2C bus, cause data loss and worse!

                                                  I will probe file /dev/i2c-1 using read byte commands.

                                                  I will probe address range 0x03-0x77.

                                                  Continue? [Y/n] y

                                                       0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f

                                                  00:          -- -- -- -- -- -- -- -- -- -- -- -- --

                                                  10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

                                                  20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

                                                  30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

                                                  40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

                                                  50: -- -- -- -- UU UU UU UU -- -- -- -- -- -- -- --

                                                  60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

                                                  70: -- -- -- -- -- -- -- --                        

                                                  root@beaglebone:~# ls -l /sys/class/i2c-dev/

                                                  total 0

                                                  lrwxrwxrwx 1 root root 0 Jan  1 00:00 i2c-0 -> ../../devices/ocp.2/44e0b000.i2c/i2c-0/i2c-dev/i2c-0

                                                  lrwxrwxrwx 1 root root 0 Jan  1 00:00 i2c-1 -> ../../devices/ocp.2/4819c000.i2c/i2c-1/i2c-dev/i2c-1

                                                  the cape eeproms are 4 devices at 0x54-0x57 on /dev/i2c-1 which is the i2c bus at 0x4819c000.  In the TRM you'll find

                                                  Showing that /dev/i2c-1 is the peripheral named I2C2.


                                                  Remember that my look into the same directory on a different image had

                                                  lrwxrwxrwx 1 root root 0 May 25 17:39 i2c-2 -> ../../devices/ocp.3/4819c000.i2c/i2c-2/i2c-dev/i2c-2/

                                                  which clearly shows you can't use the /dev entry to work out what pins are actually going to be used, and that you get different results from a different base dtb file.

                                                  (the 3.13 kernel I use has BB-View and all i2c interfaces enabled, but doesn't have capemgr and therefore I don't care about P9.18/19 being i2c2)


                                                  decompiling /boot/am335x-boneblack.dtb using "dtc -O dts -I dtb -o bb.dts /boot/am335x-boneblack.dtb" and looking at the result shows


                                                  pinmux_i2c0_pins {

                                                       pinctrl-single,pins = <0x188 0x70 0x18c 0x70>;

                                                       linux,phandle = <0x6>;

                                                       phandle = <0x6>;



                                                  pinmux_i2c2_pins {

                                                       pinctrl-single,pins = <0x178 0x73 0x17c 0x73>;

                                                       linux,phandle = <0x7>;

                                                       phandle = <0x7>;


                                                  where 0x178 and 0x17c are the pinmux addresses for P9.19 & P9.20.  Note that there's no section for i2c1_pins by default.


                                                  Later you'll find

                                                  i2c@4819c000 {

                                                       compatible = "ti,omap4-i2c";

                                                       #address-cells = <0x1>;

                                                       #size-cells = <0x0>;

                                                       ti,hwmods = "i2c3";

                                                       reg = <0x4819c000 0x1000>;

                                                       interrupts = <0x1e>;

                                                       status = "okay";

                                                       pinctrl-names = "default";

                                                       pinctrl-0 = <0x7>;

                                                       clock-frequency = <0x186a0>;

                                                       linux,phandle = <0x26>;

                                                       phandle = <0x26>;


                                                       cape_eeprom0@54 {

                                                            compatible = "at,24c256";

                                                            reg = <0x54>;

                                                            linux,phandle = <0xd>;

                                                            phandle = <0xd>;



                                                       cape_eeprom1@55 {

                                                            compatible = "at,24c256";

                                                            reg = <0x55>;

                                                            linux,phandle = <0xe>;

                                                            phandle = <0xe>;



                                                       cape_eeprom2@56 {

                                                            compatible = "at,24c256";

                                                            reg = <0x56>;

                                                            linux,phandle = <0xf>;

                                                            phandle = <0xf>;



                                                       cape_eeprom3@57 {

                                                            compatible = "at,24c256";

                                                            reg = <0x57>;

                                                            linux,phandle = <0x10>;

                                                            phandle = <0x10>;



                                                  showing how the cape eeproms are tied to the physical peripheral regardless of /dev entries.


                                                  Then later there's this:

                                                  bone_capemgr {

                                                       compatible = "ti,bone-capemgr";

                                                       status = "okay";

                                                       eeprom = <0xc>;


                                                       baseboardmaps {


                                                            board@0 {

                                                                 board-name = "A335BONE";

                                                                 compatible-name = "ti,beaglebone";

                                                                 linux,phandle = <0x4b>;

                                                                 phandle = <0x4b>;



                                                            board@1 {

                                                                 board-name = "A335BNLT";

                                                                 compatible-name = "ti,beaglebone-black";

                                                                 linux,phandle = <0x4c>;

                                                                 phandle = <0x4c>;




                                                       slots {


                                                            slot@0 {

                                                                 eeprom = <0xd>;


                                                  Note the 0xd in the eeprom line, this is the phandle used for cape_eeprom0@54 in the earlier section..  There's also nothing to stop you defining the eeprom to be on a different i2c bus if you feel like it. Or from pinmuxing I2C2 onto P9.21/22 for that matter


                                                  You can do exactly what I've done here on your problem BB-View setup to find out what's going on.  Remember though that the BB-View doesn't have a cape eeprom which forces you to manually enable it somehow - generally by some extra arguments on the kernel command line.

                                                  So it may simply be that while everything is configured otherwise identically, the pinmux_i2c2_pins section has been disabled/removed from the base dtb. Meaning that while capemgr will appear to work as normal it's simply unable to see any capes as any i2c access will never reach the outside world and you'll have to force load all overlays manually.

                                                  If that's the case, it's easily reversible, you just need to pick the bits of the devicetree that you want, remove the bits you don't and rebuild everything. Changing things that have something physically wired up may mean you need to get the soldering iron out in orger to prevent malfunctions though.


                                                  Ultimately it may simply be that as BB-View doesn't use the eeprom then that functionality has been sacrificed by it's designers. Whether we think that's a good idea or not almost certainly wasn't a factor in the decision.


                                                  Sorry for the long post... trying to work through devicetree quickly gets complex, and may not help anyway if we all have different base devicetree files as our starting points.  Hope you find some of this useful though.

                                                    • Re: Re: BBB, BB-View and I2C port usage

                                                      Thanks, no apologies needed for long reply and your time is much appreciated.


                                                      When I say 'installing BB-View' I am referring to installation instructions in BB-View User Manual V1.6 - where is instructs one to copy files and un-tar kernel module

                                                      • cp -f /media/udisk/uImage /boot/
                                                      • cp -f /media/udisk/*.dtb /boot/
                                                      • tar -xvf /media/udisk/kernel_modules.tar.gz - this is the real scary step to me and makes me uncomfortable
                                                      • cp am335-boneblack-lcd4.dtb am335x-boneblack.dtb

                                                      This is a destructive install and there is no easy way of undoing install if one wanted to revert to using HDMI port as example - if there is a better way to do this please let me know.


                                                      These are the files downloaded per instructions - note there is no BB-VIEW*.dtb (which would be my preference)

                                                      $ ls -l

                                                      total 73408

                                                      -rwxr-xr-x@ 1 cccc  staff     23798 Nov 21  2013 am335x-boneblack-lcd4.dtb

                                                      -rwxr-xr-x@ 1 cccc  staff     23798 Nov 21  2013 am335x-boneblack-lcd7.dtb

                                                      -rwxr-xr-x@ 1 cccc  staff     23798 Nov 21  2013 am335x-boneblack.dtb

                                                      -rwxr-xr-x@ 1 cccc  staff  33135741 Nov 21  2013 kernel_modules.gz

                                                      -rwxr-xr-x@ 1 cccc  staff   4371504 Nov 21  2013 uImage


                                                      Also, when reviewing listed i2c devices I don't see i2c at 0x4819C000 after BB-View install, I only see it prior to install.


                                                      Note, I did nothing else besides what's described in the manual. In my case it is definitely the case that installation of BB-View is removing I2C interface and is not due to any messing around with base OS install (besides what's stipulated in user manual).


                                                      My understanding is that the I2C on pins P9-19/20 are primarily for use by system for 'discovery' (my words) of capes and capability and can be used by other processes as long as there is no conflict in I2C addressing. It appears to me that BB-View not only doesn't support cape eeprom but also disables it removing this capability from the system - to me this is a degradation of BBB ecosystem and doubt it would be considered as a compatible cape (maybe I totally misunderstand, but clearly the i2c support is missing and in it's place I have a rather (resource) expensive led that I can toggle).


                                                      If there is another way to install BB-View (as you seem to be suggesting) then I'd really like to look into that, else it may be time to RMA devices ordered and look for more suitable (for this project) LCD solution.


                                                      Again, I appreciate your time on this, I am definitely learning more and hopefully this can help others as well.

                                                        • Re: Re: BBB, BB-View and I2C port usage

                                                          Right, maybe begins to make some sense... I've not used Angstrom in a very long time, so forgive if I end up sidetracked by stuff from other distros sometimes.


                                                          At a guess what you have there is a custom kernel that contains the modified driver for the touchscreen and a dtb that contains all of the details of the BBB itself along with the BB-View in one file. Depending on which display you have, you just copy am335x-boneblack-lcd7.dtp over the top of am335x-boneblack.dtb and switching is simple.  It also seems likely that other capes are effectively disabled with this configuration.


                                                          What you can probably do is compare the contents of your original angstrom am335x-boneblack.dtb with the new one provided for the BB-View to find out what they've done.


                                                          As for it being a destructive install, yes and no.. the files are limited to a few places. The modules all go to a directory under /lib/modules/<kernel_version> for example. So it's fairly easy to backup the originals and restore them, I'd think you could easily put together a script to do the swap.

                                                          You may even be lucky and the modules will be in different directories, in which case it's really just kernel and dtb that you would have to backup.


                                                          Is there any particular reason you have to stick to using angstrom?  New BBB boards are going to have Debian installed instead as the factory image, so possibly it's better to invest your time in Debian rather than angstrom.  Don't know if you've seen it, but there's a discussion on getting the BB-View working on the new debian builds here: http://www.element14.com/community/thread/31051/l/how-to-bb-view-on-latest-debian

                                                          If you read through that, you'll see that there is an overlay for the BB-View available in the angstrom source download. Louis did a good job figuring out what was needed to get everything working on debian, but even so there are signs later in the discussion that the base debian devicetree has changed somehow with a few people having problems getting the overlay to load without more modifications.

                                                          Even switching to debian may leave you with the same problem with I2C2, but with an overlay it may be simpler to resolve. (I never really looked too closely at the debian image as I'd already done my own linuxfromscratch build by then)


                                                          As for the BB-View being actively hostile to the rest of the cape system, yes I think we can take that for granted.  It requires changes to the touchscreen driver that are incompatible with CircuitCo LCD capes, and as you're seeing makes other things difficult as well. Since there's no way to force anyone to build compatible capes, I don't think the situation will get better.


                                                          From a personal point of view, I'm very close to thinking that the whole cape system is doomed to failure, or at least permanent life-support. Happy to discuss the reasons I think that separately if you like, but they're not really relevant to this discussion.