Porting to a new board

Porting to a new board

[Allen Kennedy Jr.]

Hello,
  I have read the documentation but I believe it to be out of date, as it
does not match up with the source from the git tree.

  To that end, I am trying to add a new board, and I can not figure out how
to do so.  My board uses the mx27 processor, and so I am attempting to
closely mimic one of the other mx27 boards, when following the steps here:
http://barebox.org/documentation/barebox-2011.05.0/dev_board.html

I find the following inconsistencies:
1. include/configs/<boardname>.h  -
the configs directory does not exist.
2. modify arch/<architecture>/Kconfig

   - add your board (MACH_*) to the list
   - add your default text base address for this architecture
   (ARCH_TEXT_BASE)
   - add BOARDINFO with valueable info for your board

None of this exists.

3. modify arch/<architecture>/Makefile:

   - add board-$(MACH_*) = <your board_dir>


This does not exist

And my board will not show up in the menu config.

Also I am finding it difficult to locate where I set things like flash
size, ram size, etc...  u-boot has a much simpler (if not less documented)
layout when it came to boards.  Alas I can not use u-boot, because of the
nand flash limitations, and thus why I am attempting to use barebox.

And finally there seems to be some confusiton both in the code and the
documentation about the difference between a board and a machine.  What is
the difference?

I'm sorry that there is a lot here, but I can not find the proper
documentation to answer these questions.


Also, for those that are curious, or can help me get around this issue.  I
attempting to get this going on a board with an mx27 booted from NAND
flash, so I believe I have to use the PBL option to setup and copy out of
nand to do the real booting.  If there is any advice on this, I would
appreciate it.  I have no other bootloader, only bare metal and a JTAG
device.


thank you.

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Porting to a new board

[Sascha Hauer]

On Wed, Sep 18, 2013 at 04:44:29PM -0500, Allen Kennedy Jr. wrote:
> Hello,
>   I have read the documentation but I believe it to be out of date, as it
> does not match up with the source from the git tree.

Yes, you're most probably right :(

> 
>   To that end, I am trying to add a new board, and I can not figure out how
> to do so.  My board uses the mx27 processor, and so I am attempting to
> closely mimic one of the other mx27 boards, when following the steps here:
> http://barebox.org/documentation/barebox-2011.05.0/dev_board.html
> 
> I find the following inconsistencies:
> 1. include/configs/<boardname>.h  -
> the configs directory does not exist.
> 2. modify arch/<architecture>/Kconfig
> 
>    - add your board (MACH_*) to the list
>    - add your default text base address for this architecture
>    (ARCH_TEXT_BASE)
>    - add BOARDINFO with valueable info for your board
> 
> None of this exists.
> 
> 3. modify arch/<architecture>/Makefile:
> 
>    - add board-$(MACH_*) = <your board_dir>
> 
> 
> This does not exist
> 
> And my board will not show up in the menu config.
> 
> Also I am finding it difficult to locate where I set things like flash
> size, ram size, etc...  u-boot has a much simpler (if not less documented)
> layout when it came to boards.  Alas I can not use u-boot, because of the
> nand flash limitations, and thus why I am attempting to use barebox.

Look at arch/arm/boards/pcm038/. It should contain enough information to
get you started. To hooking your board up to the build system look at
arch/arm/boards/Makefile and arch/arm/mach-imx/Kconfig.

> 
> And finally there seems to be some confusiton both in the code and the
> documentation about the difference between a board and a machine.  What is
> the difference?

What we have is:

- board: The PCB in front of you
- SoC: The System on Chip from vendors like Freescale, Marvell,...
- Architecture: Arm, PowerPC, Mips
- subarchitecture: i.MX, PXA, usually a subarchitecture is one of
  arch/*/mach-*

'machine' is sometimes used for 'SoC', sometimes for 'board' and
sometimes for 'subarchitecture'. The term shouldn't be used.

> 
> I'm sorry that there is a lot here, but I can not find the proper
> documentation to answer these questions.
> 
> 
> Also, for those that are curious, or can help me get around this issue.  I
> attempting to get this going on a board with an mx27 booted from NAND
> flash, so I believe I have to use the PBL option to setup and copy out of
> nand to do the real booting.  If there is any advice on this, I would
> appreciate it.  I have no other bootloader, only bare metal and a JTAG
> device.

You don't need the PBL option (you can use it if you want to, it will
make your binary smaller).

Basically what I would do is:

- Start with a nearly empty lowlevel.c (copy from
  arch/arm/boards/pcm038/lowlevel.c, remove SDRAM setup
- Setup the SDRAM via JTAG, make sure it works
- Figure out a way to send signs of life from your board (setup early
  UART, flash a LED), add this to early code
- upload the binary via JTAG to the already configured SDRAM, make it
  work.

This way you can get a working binary without having the complex process
of loading from NAND flash before seeing anything. Also with the working
binary you can use barebox to flash itself to NAND.

Hope that helps.

Sascha

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

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Porting to a new board

[Allen Kennedy Jr.]

Thanks for the great idea to start with a loaded image in ram.

I was able to get it to run, but I can't get the Ethernet to work.
I'm not entirely sure where to begin looking.

I hit devinfo and get:
<snip>
     `---- imx27-fec
          `---- miibus0
          `---- eth0
<...>
drivers:
<...>
SMSC LAN83C185
SMSC LAN8187
SMSC LAN8700
SMSC LAN911x Internal PHY
SMSC LAN8710/LAN8720
fec_imx
Generic PHY
</snip>

This would seem to indicate to me that the drivers are loading. And
that the register happened.
But I'm not sure where to go from here.

In another thread... the advice was given to check the MII address,
although I'm not sure how to interpret the data sheet.
It looks as though the address is 31.  But I could be wrong.  When I
try 31, and do a DHCP the processor hangs.
So I tried 0, and the processor hangs.

Is there a "scan the bus mode" I can use in the fec driver?  I don't
see one, but I may be looking in the wrong spot.

What else can I check?

thanks


On Thu, Sep 19, 2013 at 2:35 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> On Wed, Sep 18, 2013 at 04:44:29PM -0500, Allen Kennedy Jr. wrote:
>> Hello,
>>   I have read the documentation but I believe it to be out of date, as it
>> does not match up with the source from the git tree.
>
> Yes, you're most probably right :(
>
>>
>>   To that end, I am trying to add a new board, and I can not figure out how
>> to do so.  My board uses the mx27 processor, and so I am attempting to
>> closely mimic one of the other mx27 boards, when following the steps here:
>> http://barebox.org/documentation/barebox-2011.05.0/dev_board.html
>>
>> I find the following inconsistencies:
>> 1. include/configs/<boardname>.h  -
>> the configs directory does not exist.
>> 2. modify arch/<architecture>/Kconfig
>>
>>    - add your board (MACH_*) to the list
>>    - add your default text base address for this architecture
>>    (ARCH_TEXT_BASE)
>>    - add BOARDINFO with valueable info for your board
>>
>> None of this exists.
>>
>> 3. modify arch/<architecture>/Makefile:
>>
>>    - add board-$(MACH_*) = <your board_dir>
>>
>>
>> This does not exist
>>
>> And my board will not show up in the menu config.
>>
>> Also I am finding it difficult to locate where I set things like flash
>> size, ram size, etc...  u-boot has a much simpler (if not less documented)
>> layout when it came to boards.  Alas I can not use u-boot, because of the
>> nand flash limitations, and thus why I am attempting to use barebox.
>
> Look at arch/arm/boards/pcm038/. It should contain enough information to
> get you started. To hooking your board up to the build system look at
> arch/arm/boards/Makefile and arch/arm/mach-imx/Kconfig.
>
>>
>> And finally there seems to be some confusiton both in the code and the
>> documentation about the difference between a board and a machine.  What is
>> the difference?
>
> What we have is:
>
> - board: The PCB in front of you
> - SoC: The System on Chip from vendors like Freescale, Marvell,...
> - Architecture: Arm, PowerPC, Mips
> - subarchitecture: i.MX, PXA, usually a subarchitecture is one of
>   arch/*/mach-*
>
> 'machine' is sometimes used for 'SoC', sometimes for 'board' and
> sometimes for 'subarchitecture'. The term shouldn't be used.
>
>>
>> I'm sorry that there is a lot here, but I can not find the proper
>> documentation to answer these questions.
>>
>>
>> Also, for those that are curious, or can help me get around this issue.  I
>> attempting to get this going on a board with an mx27 booted from NAND
>> flash, so I believe I have to use the PBL option to setup and copy out of
>> nand to do the real booting.  If there is any advice on this, I would
>> appreciate it.  I have no other bootloader, only bare metal and a JTAG
>> device.
>
> You don't need the PBL option (you can use it if you want to, it will
> make your binary smaller).
>
> Basically what I would do is:
>
> - Start with a nearly empty lowlevel.c (copy from
>   arch/arm/boards/pcm038/lowlevel.c, remove SDRAM setup
> - Setup the SDRAM via JTAG, make sure it works
> - Figure out a way to send signs of life from your board (setup early
>   UART, flash a LED), add this to early code
> - upload the binary via JTAG to the already configured SDRAM, make it
>   work.
>
> This way you can get a working binary without having the complex process
> of loading from NAND flash before seeing anything. Also with the working
> binary you can use barebox to flash itself to NAND.
>
> Hope that helps.
>
> Sascha
>
> --
> Pengutronix e.K.                           |                             |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
>
> _______________________________________________
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Porting to a new board

[Sascha Hauer]

On Fri, Sep 20, 2013 at 04:02:44PM -0500, Allen Kennedy Jr. wrote:
> Thanks for the great idea to start with a loaded image in ram.
> 
> I was able to get it to run, but I can't get the Ethernet to work.
> I'm not entirely sure where to begin looking.
> 
> I hit devinfo and get:
> <snip>
>      `---- imx27-fec
>           `---- miibus0
>           `---- eth0
> <...>
> drivers:
> <...>
> SMSC LAN83C185
> SMSC LAN8187
> SMSC LAN8700
> SMSC LAN911x Internal PHY
> SMSC LAN8710/LAN8720
> fec_imx
> Generic PHY
> </snip>
> 
> This would seem to indicate to me that the drivers are loading. And
> that the register happened.
> But I'm not sure where to go from here.

What's the output of some network command, like for example 'dhcp'?

What's the output of 'md -w -s /dev/phy0'?

Problems with networking usually go down to problems with the phy.
What's the content of the platform data for the FEC? It should look
like:

static struct fec_platform_data fec_info = {
        .xcv_type = PHY_INTERFACE_MODE_MII,
        .phy_addr = -1,
};


With xcv_type being MII (I think it's the only possibility on i.MX27)
and phy_addr to either -1 for autodetecting the address or the correct
address. Use -1 to be on the safe side.

When 'md -w -s /dev/phy0' doesn't show any sensible register output then
your pinmux may be wrong or you haven't brought your phy out of reset
with some gpio.

> 
> In another thread... the advice was given to check the MII address,
> although I'm not sure how to interpret the data sheet.
> It looks as though the address is 31.  But I could be wrong.  When I
> try 31, and do a DHCP the processor hangs.
> So I tried 0, and the processor hangs.
> 
> Is there a "scan the bus mode" I can use in the fec driver?  I don't
> see one, but I may be looking in the wrong spot.

It's not in the FEC driver but in the generic MII support. As said, use
-1 as phy id.

Sascha

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

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Porting to a new board

[Allen Kennedy Jr.]

The power is stable.  The garbled message happens whenever too many
strings are printed out.  So I don't think that's anything to do with
my specific setup.  You might be able to reproduce it.  Try this:

md 0xa0000000+2000
<substitute the beginning of your ram range for 0xa0000000>

On Tue, Sep 24, 2013 at 11:33 AM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:
> On 10:00 Tue 24 Sep     , Allen Kennedy Jr. wrote:
>> The dhcp command gives:
>> "warning: No MAC address set. Using random address 62:1C:8B:DF:6D:4D"
>> Then the device console hangs, Ctrl-C does nothing.  Breaking into it
>> via JTAG, I see
>> the PC and LR are off in the weeds and the stack and registers
>> contains nothing of
>> indication as to where it went awry.
>>
>> md 0x1002b000 does show the FEC registers:
>>  md 0x1002b000
>> 1002b000: 00000600 00000000 00000000 00000600                ................
>> 1002b010: 00000000 00000000 00000000 00000000                ................
>> 1002b020: 00000600 f0000000 00000600 00000600                ................
>> 1002b030: 00000600 00000600 00000600 00000600                ................
>> 1002b040: 6f86782d 00000018 00060006 00040006                -x.o............
>> 1002b050: 6f86782d 00000018 000a0006 00080006                -x.o............
>> 1002b060: 00000000 c0000000 fffffffd fffffffd                ................
>> 1002b070: fffffffd fffffffd fffffffd fffffffd                ................
>> 1002b080: 000b0000 05ee0004 19000000 84680868                ............h.h.
>> 1002b090: ffffffff 00000000 10008208 33428006                ..............B3
>> 1002b0a0: 00c40000 ffffffff ffffffff ffffffff                ................
>> 1002b0b0: ffffffff ffffffff ffffffff ffffffff                ................
>> 1002b0c0: 00000000 00000000 00000000 00000000                ................
>> 1002b0d0: 02b20000 91cc3d09 00000000 0180c200                .....=..........
>> 1002b0e0: 00010000 068f6c9e b50d8808 00010020                .....l...... ...
>> 1002b0f0: 00000000 00000000 00000000 00000000                ................
>>
>>
>> iomem output:
>>  iomem
>> 0x00000000 - 0xffffffff (size 0x00000000) iomem
>>   0x10002000 - 0x10002fff (size 0x00001000) imx21-wdt0
>>   0x10003000 - 0x100030ff (size 0x00000100) imx1-gpt0
>>   0x1000a000 - 0x1000afff (size 0x00001000) imx21-uart0
>>   0x10015000 - 0x100150ff (size 0x00000100) imx1-gpio0
>>   0x10015100 - 0x100151ff (size 0x00000100) imx1-gpio1
>>   0x10015200 - 0x100152ff (size 0x00000100) imx1-gpio2
>>   0x10015300 - 0x100153ff (size 0x00000100) imx1-gpio3
>>   0x10015400 - 0x100154ff (size 0x00000100) imx1-gpio4
>>   0x10015500 - 0x100155ff (size 0x00000100) imx1-gpio5
>>   0x10027000 - 0x10027fff (size 0x00001000) imx27-ccm
>>   0x10028000 - 0x10028fff (size 0x00001000) imx_iim
>>   0x1002b000 - 0x1002bfff (size 0x00001000) imx27-fec
>>   0xa0000000 - 0xa7ffffff (size 0x08000000) ram0
>>     0xa7a00000 - 0xa7dfffff (size 0x00400000) malloc space
>>     0xa7e00000 - 0xa7e1afdf (size 0x0001afe0) barebox
>>     0xa7e1afe0 - 0xa7e20aaf (size 0x00005ad0) barebox data
>>     0xa7e20ab0 - 0xa7e24f4b (size 0x0000449c) bss
>>     0xa7ff8000 - 0xa7ffffff (size 0x00008000) stack
>>   0xd8001000 - 0xd8001fff (size 0x00001000) imx27-esdctl
>>
>> This seems valid to me... does anyone see anything missing?
>>
>> As to putting in some debug statements in the FEC driver, I put an
>> enter and exit line in each function.  Startup gave me this:
>> fec_probe enter
>> fec_alloc_receive_packets enter
>> fec_alloc_receive_packets exit
>> fec_init enter
>> fec_init exit
>> mdio_bus: miibus0: probed
>> fec_probe exit 0
>>
>> So that looks good I would think.
>>
>> The DHCP command as follows:
>> dhcp<enter>
>> warning: No MAC address set. Using random address 12:D4:85:77:78:E4
>> fec_set_hwaddr enter
>> fec_set_hwaddr exit
>> fec_open enter
>> fec_miibus_read enter
>> fec_miibus_read exit
>> <... more reads ... >
>> fec_miibus_read enter
>> fec_miibus_read exit
>> fec_miibus_write enter
>> fec_miibus_write exit
>> fec_miibus_read enter
>> fec_miibus_read exit
>> fec_miibus_read enter
>> fec_miibus_read exit
>> fec_miibus_write enter
>> fec_miibus_write exit
>> fec_miibus_read enter
>> fec_miibus_read exit
>> fec_miibus_write enter
>> fec_miibus_write exit
>> fec_rbd_init enter
>> fec_rbd_init exit
>> fec_tbd_init enter
>> fec_tbd_init exit
>> fec_rx_task_enable enter
>> fec_rx_task_enable exit
>> fec_open exit
>> fec_miibus_read enter
>> fec_miibus_read exit
>>
>> this is followed by many more reads, until the output garbles:
>> fec_miibus_read exit
>> fec_miibus_read enter
>> fec_miibus_read exit
>
> are you sure about the power of the board?
>
> because it seems a clock change otherwise
>
> Best Regards,
> J.
>> miiear
>> miiea
>> iibad
>> iibad
>> fibud
>> fibud e
>> febus us_enfeus_exiecs_rntec_s_xitc__retec_m_reit_mireaer_miret
>> mieadr
>> miiea
>> iibad
>> iibad
>> ibud
>> fibud
>> febus euenfecusexiec_s_nteec_s_xitc__reterc__reit
>> _mreaer
>> _mreat
>> mieadr
>> miead
>> iibad
>>
>> and the chip ends up in the weeds.
>>
>> Any thoughts?
>>
>>
>> On Tue, Sep 24, 2013 at 2:39 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
>> > On Mon, Sep 23, 2013 at 04:47:19PM -0500, Allen Kennedy Jr. wrote:
>> >> > What's the output of some network command, like for example 'dhcp'?
>> >>
>> >> This hangs the chip.
>> >
>> > This shouldn't happen. No reaction from the board at all? Does ctrl-c
>> > work? You could add some debug messages to the FEC driver to see where
>> > it hangs.
>> >
>> > One situation where a board might hang is when the clock is disabled,
>> > but I don't see how this can happen since it's explicitly enabled in
>> > arch/arm/mach-imx/clk-imx27.c
>> >
>> > What's the output of 'md 0x1002b000'? Does it show the FEC registers
>> > or does it hang the board aswell? The output of 'iomem' might also
>> > help.
>> >
>> > Sascha
>> >
>> > --
>> > Pengutronix e.K.                           |                             |
>> > Industrial Linux Solutions                 | http://www.pengutronix.de/  |
>> > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
>> > Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
>> >
>> > _______________________________________________
>> > barebox mailing list
>> > barebox@lists.infradead.org
>> > http://lists.infradead.org/mailman/listinfo/barebox
>>
>> _______________________________________________
>> barebox mailing list
>> barebox@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/barebox
>
> _______________________________________________
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Porting to a new board

[Jean-Christophe PLAGNIOL-VILLARD]

On 10:00 Tue 24 Sep     , Allen Kennedy Jr. wrote:
> The dhcp command gives:
> "warning: No MAC address set. Using random address 62:1C:8B:DF:6D:4D"
> Then the device console hangs, Ctrl-C does nothing.  Breaking into it
> via JTAG, I see
> the PC and LR are off in the weeds and the stack and registers
> contains nothing of
> indication as to where it went awry.
> 
> md 0x1002b000 does show the FEC registers:
>  md 0x1002b000
> 1002b000: 00000600 00000000 00000000 00000600                ................
> 1002b010: 00000000 00000000 00000000 00000000                ................
> 1002b020: 00000600 f0000000 00000600 00000600                ................
> 1002b030: 00000600 00000600 00000600 00000600                ................
> 1002b040: 6f86782d 00000018 00060006 00040006                -x.o............
> 1002b050: 6f86782d 00000018 000a0006 00080006                -x.o............
> 1002b060: 00000000 c0000000 fffffffd fffffffd                ................
> 1002b070: fffffffd fffffffd fffffffd fffffffd                ................
> 1002b080: 000b0000 05ee0004 19000000 84680868                ............h.h.
> 1002b090: ffffffff 00000000 10008208 33428006                ..............B3
> 1002b0a0: 00c40000 ffffffff ffffffff ffffffff                ................
> 1002b0b0: ffffffff ffffffff ffffffff ffffffff                ................
> 1002b0c0: 00000000 00000000 00000000 00000000                ................
> 1002b0d0: 02b20000 91cc3d09 00000000 0180c200                .....=..........
> 1002b0e0: 00010000 068f6c9e b50d8808 00010020                .....l...... ...
> 1002b0f0: 00000000 00000000 00000000 00000000                ................
> 
> 
> iomem output:
>  iomem
> 0x00000000 - 0xffffffff (size 0x00000000) iomem
>   0x10002000 - 0x10002fff (size 0x00001000) imx21-wdt0
>   0x10003000 - 0x100030ff (size 0x00000100) imx1-gpt0
>   0x1000a000 - 0x1000afff (size 0x00001000) imx21-uart0
>   0x10015000 - 0x100150ff (size 0x00000100) imx1-gpio0
>   0x10015100 - 0x100151ff (size 0x00000100) imx1-gpio1
>   0x10015200 - 0x100152ff (size 0x00000100) imx1-gpio2
>   0x10015300 - 0x100153ff (size 0x00000100) imx1-gpio3
>   0x10015400 - 0x100154ff (size 0x00000100) imx1-gpio4
>   0x10015500 - 0x100155ff (size 0x00000100) imx1-gpio5
>   0x10027000 - 0x10027fff (size 0x00001000) imx27-ccm
>   0x10028000 - 0x10028fff (size 0x00001000) imx_iim
>   0x1002b000 - 0x1002bfff (size 0x00001000) imx27-fec
>   0xa0000000 - 0xa7ffffff (size 0x08000000) ram0
>     0xa7a00000 - 0xa7dfffff (size 0x00400000) malloc space
>     0xa7e00000 - 0xa7e1afdf (size 0x0001afe0) barebox
>     0xa7e1afe0 - 0xa7e20aaf (size 0x00005ad0) barebox data
>     0xa7e20ab0 - 0xa7e24f4b (size 0x0000449c) bss
>     0xa7ff8000 - 0xa7ffffff (size 0x00008000) stack
>   0xd8001000 - 0xd8001fff (size 0x00001000) imx27-esdctl
> 
> This seems valid to me... does anyone see anything missing?
> 
> As to putting in some debug statements in the FEC driver, I put an
> enter and exit line in each function.  Startup gave me this:
> fec_probe enter
> fec_alloc_receive_packets enter
> fec_alloc_receive_packets exit
> fec_init enter
> fec_init exit
> mdio_bus: miibus0: probed
> fec_probe exit 0
> 
> So that looks good I would think.
> 
> The DHCP command as follows:
> dhcp<enter>
> warning: No MAC address set. Using random address 12:D4:85:77:78:E4
> fec_set_hwaddr enter
> fec_set_hwaddr exit
> fec_open enter
> fec_miibus_read enter
> fec_miibus_read exit
> <... more reads ... >
> fec_miibus_read enter
> fec_miibus_read exit
> fec_miibus_write enter
> fec_miibus_write exit
> fec_miibus_read enter
> fec_miibus_read exit
> fec_miibus_read enter
> fec_miibus_read exit
> fec_miibus_write enter
> fec_miibus_write exit
> fec_miibus_read enter
> fec_miibus_read exit
> fec_miibus_write enter
> fec_miibus_write exit
> fec_rbd_init enter
> fec_rbd_init exit
> fec_tbd_init enter
> fec_tbd_init exit
> fec_rx_task_enable enter
> fec_rx_task_enable exit
> fec_open exit
> fec_miibus_read enter
> fec_miibus_read exit
> 
> this is followed by many more reads, until the output garbles:
> fec_miibus_read exit
> fec_miibus_read enter
> fec_miibus_read exit

are you sure about the power of the board?

because it seems a clock change otherwise

Best Regards,
J.
> miiear
> miiea
> iibad
> iibad
> fibud
> fibud e
> febus us_enfeus_exiecs_rntec_s_xitc__retec_m_reit_mireaer_miret
> mieadr
> miiea
> iibad
> iibad
> ibud
> fibud
> febus euenfecusexiec_s_nteec_s_xitc__reterc__reit
> _mreaer
> _mreat
> mieadr
> miead
> iibad
> 
> and the chip ends up in the weeds.
> 
> Any thoughts?
> 
> 
> On Tue, Sep 24, 2013 at 2:39 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > On Mon, Sep 23, 2013 at 04:47:19PM -0500, Allen Kennedy Jr. wrote:
> >> > What's the output of some network command, like for example 'dhcp'?
> >>
> >> This hangs the chip.
> >
> > This shouldn't happen. No reaction from the board at all? Does ctrl-c
> > work? You could add some debug messages to the FEC driver to see where
> > it hangs.
> >
> > One situation where a board might hang is when the clock is disabled,
> > but I don't see how this can happen since it's explicitly enabled in
> > arch/arm/mach-imx/clk-imx27.c
> >
> > What's the output of 'md 0x1002b000'? Does it show the FEC registers
> > or does it hang the board aswell? The output of 'iomem' might also
> > help.
> >
> > Sascha
> >
> > --
> > Pengutronix e.K.                           |                             |
> > Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
> > Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
> >
> > _______________________________________________
> > barebox mailing list
> > barebox@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/barebox
> 
> _______________________________________________
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Porting to a new board

[Allen Kennedy Jr.]

The dhcp command gives:
"warning: No MAC address set. Using random address 62:1C:8B:DF:6D:4D"
Then the device console hangs, Ctrl-C does nothing.  Breaking into it
via JTAG, I see
the PC and LR are off in the weeds and the stack and registers
contains nothing of
indication as to where it went awry.

md 0x1002b000 does show the FEC registers:
 md 0x1002b000
1002b000: 00000600 00000000 00000000 00000600                ................
1002b010: 00000000 00000000 00000000 00000000                ................
1002b020: 00000600 f0000000 00000600 00000600                ................
1002b030: 00000600 00000600 00000600 00000600                ................
1002b040: 6f86782d 00000018 00060006 00040006                -x.o............
1002b050: 6f86782d 00000018 000a0006 00080006                -x.o............
1002b060: 00000000 c0000000 fffffffd fffffffd                ................
1002b070: fffffffd fffffffd fffffffd fffffffd                ................
1002b080: 000b0000 05ee0004 19000000 84680868                ............h.h.
1002b090: ffffffff 00000000 10008208 33428006                ..............B3
1002b0a0: 00c40000 ffffffff ffffffff ffffffff                ................
1002b0b0: ffffffff ffffffff ffffffff ffffffff                ................
1002b0c0: 00000000 00000000 00000000 00000000                ................
1002b0d0: 02b20000 91cc3d09 00000000 0180c200                .....=..........
1002b0e0: 00010000 068f6c9e b50d8808 00010020                .....l...... ...
1002b0f0: 00000000 00000000 00000000 00000000                ................


iomem output:
 iomem
0x00000000 - 0xffffffff (size 0x00000000) iomem
  0x10002000 - 0x10002fff (size 0x00001000) imx21-wdt0
  0x10003000 - 0x100030ff (size 0x00000100) imx1-gpt0
  0x1000a000 - 0x1000afff (size 0x00001000) imx21-uart0
  0x10015000 - 0x100150ff (size 0x00000100) imx1-gpio0
  0x10015100 - 0x100151ff (size 0x00000100) imx1-gpio1
  0x10015200 - 0x100152ff (size 0x00000100) imx1-gpio2
  0x10015300 - 0x100153ff (size 0x00000100) imx1-gpio3
  0x10015400 - 0x100154ff (size 0x00000100) imx1-gpio4
  0x10015500 - 0x100155ff (size 0x00000100) imx1-gpio5
  0x10027000 - 0x10027fff (size 0x00001000) imx27-ccm
  0x10028000 - 0x10028fff (size 0x00001000) imx_iim
  0x1002b000 - 0x1002bfff (size 0x00001000) imx27-fec
  0xa0000000 - 0xa7ffffff (size 0x08000000) ram0
    0xa7a00000 - 0xa7dfffff (size 0x00400000) malloc space
    0xa7e00000 - 0xa7e1afdf (size 0x0001afe0) barebox
    0xa7e1afe0 - 0xa7e20aaf (size 0x00005ad0) barebox data
    0xa7e20ab0 - 0xa7e24f4b (size 0x0000449c) bss
    0xa7ff8000 - 0xa7ffffff (size 0x00008000) stack
  0xd8001000 - 0xd8001fff (size 0x00001000) imx27-esdctl

This seems valid to me... does anyone see anything missing?

As to putting in some debug statements in the FEC driver, I put an
enter and exit line in each function.  Startup gave me this:
fec_probe enter
fec_alloc_receive_packets enter
fec_alloc_receive_packets exit
fec_init enter
fec_init exit
mdio_bus: miibus0: probed
fec_probe exit 0

So that looks good I would think.

The DHCP command as follows:
dhcp<enter>
warning: No MAC address set. Using random address 12:D4:85:77:78:E4
fec_set_hwaddr enter
fec_set_hwaddr exit
fec_open enter
fec_miibus_read enter
fec_miibus_read exit
<... more reads ... >
fec_miibus_read enter
fec_miibus_read exit
fec_miibus_write enter
fec_miibus_write exit
fec_miibus_read enter
fec_miibus_read exit
fec_miibus_read enter
fec_miibus_read exit
fec_miibus_write enter
fec_miibus_write exit
fec_miibus_read enter
fec_miibus_read exit
fec_miibus_write enter
fec_miibus_write exit
fec_rbd_init enter
fec_rbd_init exit
fec_tbd_init enter
fec_tbd_init exit
fec_rx_task_enable enter
fec_rx_task_enable exit
fec_open exit
fec_miibus_read enter
fec_miibus_read exit

this is followed by many more reads, until the output garbles:
fec_miibus_read exit
fec_miibus_read enter
fec_miibus_read exit
miiear
miiea
iibad
iibad
fibud
fibud e
febus us_enfeus_exiecs_rntec_s_xitc__retec_m_reit_mireaer_miret
mieadr
miiea
iibad
iibad
ibud
fibud
febus euenfecusexiec_s_nteec_s_xitc__reterc__reit
_mreaer
_mreat
mieadr
miead
iibad

and the chip ends up in the weeds.

Any thoughts?


On Tue, Sep 24, 2013 at 2:39 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> On Mon, Sep 23, 2013 at 04:47:19PM -0500, Allen Kennedy Jr. wrote:
>> > What's the output of some network command, like for example 'dhcp'?
>>
>> This hangs the chip.
>
> This shouldn't happen. No reaction from the board at all? Does ctrl-c
> work? You could add some debug messages to the FEC driver to see where
> it hangs.
>
> One situation where a board might hang is when the clock is disabled,
> but I don't see how this can happen since it's explicitly enabled in
> arch/arm/mach-imx/clk-imx27.c
>
> What's the output of 'md 0x1002b000'? Does it show the FEC registers
> or does it hang the board aswell? The output of 'iomem' might also
> help.
>
> Sascha
>
> --
> Pengutronix e.K.                           |                             |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
>
> _______________________________________________
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Porting to a new board

[Sascha Hauer]

On Mon, Sep 23, 2013 at 04:47:19PM -0500, Allen Kennedy Jr. wrote:
> > What's the output of some network command, like for example 'dhcp'?
> 
> This hangs the chip.

This shouldn't happen. No reaction from the board at all? Does ctrl-c
work? You could add some debug messages to the FEC driver to see where
it hangs.

One situation where a board might hang is when the clock is disabled,
but I don't see how this can happen since it's explicitly enabled in
arch/arm/mach-imx/clk-imx27.c

What's the output of 'md 0x1002b000'? Does it show the FEC registers
or does it hang the board aswell? The output of 'iomem' might also
help.

Sascha

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

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Porting to a new board

[Antony Pavlov]

On Mon, 23 Sep 2013 16:47:19 -0500
"Allen Kennedy Jr." <allen@kennedystuff.com> wrote:

> > What's the output of some network command, like for example 'dhcp'?
> 
> This hangs the chip.
> 
> >
> > What's the output of 'md -w -s /dev/phy0'?
> 
> Barebox:/ md -w -s /dev/phy0
> open: No such file or directory

N.B. we have the 'miitool' command.

> Indeed there is no phy0 device in the /dev directory.  It would appear
> this is where the trouble is.  Why would this be missing?

The /dev/phy0 device appears just after the first network usage (e.g. 'dhcp' command execution).

> > static struct fec_platform_data fec_info = {
> >         .xcv_type = PHY_INTERFACE_MODE_MII,
> >         .phy_addr = -1,
> > };
> 
> It looks exactly like that.
> 
> > When 'md -w -s /dev/phy0' doesn't show any sensible register output then
> > your pinmux may be wrong or you haven't brought your phy out of reset
> > with some gpio.
> 
> I have verified that that the GPIO for the reset is outputting a high,
> as it should be for the chip to not be in reset.
> 
> My pinmodes are set up thusly:
>    /* FEC */
>     PD0_AIN_FEC_TXD0 | GPIO_PUEN,
>     PD1_AIN_FEC_TXD1 | GPIO_PUEN,
>     PD2_AIN_FEC_TXD2 | GPIO_PUEN,
>     PD3_AIN_FEC_TXD3 | GPIO_PUEN,
>     PD4_AOUT_FEC_RX_ER | GPIO_PUEN,
>     PD5_AOUT_FEC_RXD1,
>     PD6_AOUT_FEC_RXD2 | GPIO_PUEN,
>     PD7_AOUT_FEC_RXD3 | GPIO_PUEN,
>     PD8_AF_FEC_MDIO | GPIO_PUEN,
>     PD9_AIN_FEC_MDC | GPIO_PUEN,
>     PD10_AOUT_FEC_CRS | GPIO_PUEN,
>     PD11_AOUT_FEC_TX_CLK | GPIO_PUEN,
>     PD12_AOUT_FEC_RXD0 | GPIO_PUEN,
>     PD13_AOUT_FEC_RX_DV | GPIO_PUEN,
>     PD14_AOUT_FEC_RX_CLK | GPIO_PUEN,
>     PD15_AOUT_FEC_COL | GPIO_PUEN,
>     PD16_AIN_FEC_TX_ER,
>     PF23_AIN_FEC_TX_EN,
> 
> And a double check shows that this matches the schematic.
> I probed the reset line with a scope, and indeed it is goes to the
> correct state before the attempt to register the FEC device.
> 
> thanks,
> -Allen
> 
> 
> On Sat, Sep 21, 2013 at 2:50 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > On Fri, Sep 20, 2013 at 04:02:44PM -0500, Allen Kennedy Jr. wrote:
> >> Thanks for the great idea to start with a loaded image in ram.
> >>
> >> I was able to get it to run, but I can't get the Ethernet to work.
> >> I'm not entirely sure where to begin looking.
> >>
> >> I hit devinfo and get:
> >> <snip>
> >>      `---- imx27-fec
> >>           `---- miibus0
> >>           `---- eth0
> >> <...>
> >> drivers:
> >> <...>
> >> SMSC LAN83C185
> >> SMSC LAN8187
> >> SMSC LAN8700
> >> SMSC LAN911x Internal PHY
> >> SMSC LAN8710/LAN8720
> >> fec_imx
> >> Generic PHY
> >> </snip>
> >>
> >> This would seem to indicate to me that the drivers are loading. And
> >> that the register happened.
> >> But I'm not sure where to go from here.
> >
> > What's the output of some network command, like for example 'dhcp'?
> >
> > What's the output of 'md -w -s /dev/phy0'?
> >
> > Problems with networking usually go down to problems with the phy.
> > What's the content of the platform data for the FEC? It should look
> > like:
> >
> > static struct fec_platform_data fec_info = {
> >         .xcv_type = PHY_INTERFACE_MODE_MII,
> >         .phy_addr = -1,
> > };
> >
> >
> > With xcv_type being MII (I think it's the only possibility on i.MX27)
> > and phy_addr to either -1 for autodetecting the address or the correct
> > address. Use -1 to be on the safe side.
> >
> > When 'md -w -s /dev/phy0' doesn't show any sensible register output then
> > your pinmux may be wrong or you haven't brought your phy out of reset
> > with some gpio.
> >
> >>
> >> In another thread... the advice was given to check the MII address,
> >> although I'm not sure how to interpret the data sheet.
> >> It looks as though the address is 31.  But I could be wrong.  When I
> >> try 31, and do a DHCP the processor hangs.
> >> So I tried 0, and the processor hangs.
> >>
> >> Is there a "scan the bus mode" I can use in the fec driver?  I don't
> >> see one, but I may be looking in the wrong spot.
> >
> > It's not in the FEC driver but in the generic MII support. As said, use
> > -1 as phy id.
> >
> > Sascha
> >
> > --
> > Pengutronix e.K.                           |                             |
> > Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
> > Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
> >
> > _______________________________________________
> > barebox mailing list
> > barebox@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/barebox
> 
> _______________________________________________
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox


-- 
-- 
Best regards,
  Antony Pavlov

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Porting to a new board

[Allen Kennedy Jr.]

> What's the output of some network command, like for example 'dhcp'?

This hangs the chip.

>
> What's the output of 'md -w -s /dev/phy0'?

Barebox:/ md -w -s /dev/phy0
open: No such file or directory

Indeed there is no phy0 device in the /dev directory.  It would appear
this is where the trouble is.  Why would this be missing?

> static struct fec_platform_data fec_info = {
>         .xcv_type = PHY_INTERFACE_MODE_MII,
>         .phy_addr = -1,
> };

It looks exactly like that.

> When 'md -w -s /dev/phy0' doesn't show any sensible register output then
> your pinmux may be wrong or you haven't brought your phy out of reset
> with some gpio.

I have verified that that the GPIO for the reset is outputting a high,
as it should be for the chip to not be in reset.

My pinmodes are set up thusly:
   /* FEC */
    PD0_AIN_FEC_TXD0 | GPIO_PUEN,
    PD1_AIN_FEC_TXD1 | GPIO_PUEN,
    PD2_AIN_FEC_TXD2 | GPIO_PUEN,
    PD3_AIN_FEC_TXD3 | GPIO_PUEN,
    PD4_AOUT_FEC_RX_ER | GPIO_PUEN,
    PD5_AOUT_FEC_RXD1,
    PD6_AOUT_FEC_RXD2 | GPIO_PUEN,
    PD7_AOUT_FEC_RXD3 | GPIO_PUEN,
    PD8_AF_FEC_MDIO | GPIO_PUEN,
    PD9_AIN_FEC_MDC | GPIO_PUEN,
    PD10_AOUT_FEC_CRS | GPIO_PUEN,
    PD11_AOUT_FEC_TX_CLK | GPIO_PUEN,
    PD12_AOUT_FEC_RXD0 | GPIO_PUEN,
    PD13_AOUT_FEC_RX_DV | GPIO_PUEN,
    PD14_AOUT_FEC_RX_CLK | GPIO_PUEN,
    PD15_AOUT_FEC_COL | GPIO_PUEN,
    PD16_AIN_FEC_TX_ER,
    PF23_AIN_FEC_TX_EN,

And a double check shows that this matches the schematic.
I probed the reset line with a scope, and indeed it is goes to the
correct state before the attempt to register the FEC device.

thanks,
-Allen


On Sat, Sep 21, 2013 at 2:50 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> On Fri, Sep 20, 2013 at 04:02:44PM -0500, Allen Kennedy Jr. wrote:
>> Thanks for the great idea to start with a loaded image in ram.
>>
>> I was able to get it to run, but I can't get the Ethernet to work.
>> I'm not entirely sure where to begin looking.
>>
>> I hit devinfo and get:
>> <snip>
>>      `---- imx27-fec
>>           `---- miibus0
>>           `---- eth0
>> <...>
>> drivers:
>> <...>
>> SMSC LAN83C185
>> SMSC LAN8187
>> SMSC LAN8700
>> SMSC LAN911x Internal PHY
>> SMSC LAN8710/LAN8720
>> fec_imx
>> Generic PHY
>> </snip>
>>
>> This would seem to indicate to me that the drivers are loading. And
>> that the register happened.
>> But I'm not sure where to go from here.
>
> What's the output of some network command, like for example 'dhcp'?
>
> What's the output of 'md -w -s /dev/phy0'?
>
> Problems with networking usually go down to problems with the phy.
> What's the content of the platform data for the FEC? It should look
> like:
>
> static struct fec_platform_data fec_info = {
>         .xcv_type = PHY_INTERFACE_MODE_MII,
>         .phy_addr = -1,
> };
>
>
> With xcv_type being MII (I think it's the only possibility on i.MX27)
> and phy_addr to either -1 for autodetecting the address or the correct
> address. Use -1 to be on the safe side.
>
> When 'md -w -s /dev/phy0' doesn't show any sensible register output then
> your pinmux may be wrong or you haven't brought your phy out of reset
> with some gpio.
>
>>
>> In another thread... the advice was given to check the MII address,
>> although I'm not sure how to interpret the data sheet.
>> It looks as though the address is 31.  But I could be wrong.  When I
>> try 31, and do a DHCP the processor hangs.
>> So I tried 0, and the processor hangs.
>>
>> Is there a "scan the bus mode" I can use in the fec driver?  I don't
>> see one, but I may be looking in the wrong spot.
>
> It's not in the FEC driver but in the generic MII support. As said, use
> -1 as phy id.
>
> Sascha
>
> --
> Pengutronix e.K.                           |                             |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
>
> _______________________________________________
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox