[U-Boot-Users] U-boot & MonteJade start up
I'm trying to get u-boot up and running on an Intel MonteJade (IXDPG425) board without much luck.
I downloaded version 2.0 of the Npe code and placed it in the appropriate directory and the build worked fine. Getting it up and running on the board has proved more difficulat.
I'm using a Macraigor USB wiggler to download to the FLASH. If anyone has done this successfully then I would appreciate some pointers as I'm not sure what I've done thus far is correct.
As far as I understand it, the xscale starts up in little endian mode. The application is, however, big-endian. When I program the FLASH it appears to be big-endian, and I don't as yet understand where the transition from little endian occurs. The u-boot code in the current state doesn't go anywhere with no response from the serial port.
Is there some pre-bootloader code which does the transition to big-endian? If so, do I need to program this sepeartely? If not, where does the transition to big-endian occur and why does the code I see (in the srec file, for example) appear to start off big-endian? I can imagine ld getting pretty confused trying to link a little-endian snippet to a big-endian application.
Thanks
Jonathan Pratt
ELPRO Technologies Pty Ltd "Wireless Solutions Since 1983" ISO 9001:2000 Accredited ABN 17 010 627 835
9/12 Billabong St, Stafford, QLD, Australia 4053 Telephone: +61 7 3352 4533 Facsimile: +61 7 3352 4577
Web Site: http://www.elprotech.com
On Wednesday 02 May 2007 06:39, Jonathan Pratt wrote:
I'm trying to get u-boot up and running on an Intel MonteJade (IXDPG425) board without much luck.
I downloaded version 2.0 of the Npe code and placed it in the appropriate directory and the build worked fine. Getting it up and running on the board has proved more difficulat.
I'm using a Macraigor USB wiggler to download to the FLASH. If anyone has done this successfully then I would appreciate some pointers as I'm not sure what I've done thus far is correct.
As far as I understand it, the xscale starts up in little endian mode. The application is, however, big-endian. When I program the FLASH it appears to be big-endian, and I don't as yet understand where the transition from little endian occurs. The u-boot code in the current state doesn't go anywhere with no response from the serial port.
Is there some pre-bootloader code which does the transition to big-endian?
No.
If so, do I need to program this sepeartely? If not, where does the transition to big-endian occur and why does the code I see (in the srec file, for example) appear to start off big-endian?
Because it's compiled to be in big endian format. All IXP4xx U-Boot & Linux implementations I know of are done in big endian mode.
I can imagine ld getting pretty confused trying to link a little-endian snippet to a big-endian application.
I have to admit, that I don't know right now, where this big endian/little endian change is made. Perhaps some boot-strapping pin? Not sure, would have to look in the manual. Martijn? Could you jump in here?
For the 2 IXP4xx boards I used (ixdpg425 and pdnb3) I can say, that they "just work" with the current U-Boot implementation in big endian mode. And here definitely no pre-bootloader is required.
What exactly is your problem? Can you see where the U-Boot hangs with you debugger? You are aware that the IXDPG425 port uses UART1 (and not UART0) for console with 115200 baud.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk Office: Kirchenstr. 5, D-82194 Groebenzell, Germany =====================================================================
-----Original Message----- From: Stefan Roese [mailto:sr@denx.de] Sent: Wednesday, 2 May 2007 3:17 PM To: u-boot-users@lists.sourceforge.net Cc: Jonathan Pratt Subject: Re: [U-Boot-Users] U-boot & MonteJade start up
On Wednesday 02 May 2007 06:39, Jonathan Pratt wrote:
Is there some pre-bootloader code which does the transition to big-endian?
No.
If so, do I need to program this sepeartely? If not, where does the transition to big-endian occur and why does the code I see (in the srec file, for example) appear to start off big-endian?
Because it's compiled to be in big endian format. All IXP4xx U-Boot & Linux implementations I know of are done in big endian mode.
I can imagine ld getting pretty confused trying to link a little-endian snippet to a big-endian application.
I have to admit, that I don't know right now, where this big endian/little endian change is made. Perhaps some boot-strapping pin? Not sure, would have to look in the manual. Martijn? Could you jump in here?
When in doubt check the code, I guess.
I have been trawling the code and found that the reset vector points to the reset code, and the first thing it does is set big-endian-ness (load R0 with 0xF8 and write this value to CP15, register 1 - b7 is the endian-ness control bit).
From the IXP42x Developer's Manual the state of this bit is 0
(little-endian) on reset. I can't find any information about boot-strapping the endian-ness of the processor, or different behaviour of the excternal bus interface. I can imagine the switch over being problematic, but I can't find any documentaion as to how its done.
For the 2 IXP4xx boards I used (ixdpg425 and pdnb3) I can say, that they "just work" with the current U-Boot implementation in big endian mode. And here definitely no pre-bootloader is required.
What exactly is your problem? Can you see where the U-Boot hangs with you debugger? You are aware that the IXDPG425 port uses UART1 (and not UART0) for console with 115200 baud.
I'm having difficulty using the Macraigor USB wiggler. It doesn't seem to allow me to do a 'step' or 'go' with any useful result (ie the program counter doesn't appear to change). This is adding to my difficulties. I can't tell at the moment how far the code is getting before it dies.
I tried recompiling u-boot with UART2 as the console but had no better results. I believe that UART1 in u-boot is UART0 for the IXP425 (ie the console UART which is connected) and UART2 in u-boot is the other one that is not available on the IXDGP425 board. [but feel free to correct me if I'm wrong].
Best regards, Stefan
Thanks for your input Stefan.
Jonathan Pratt
Hi.
I have a IXP425 (IXDPG425 dev board) running u-boot [yay!] but I get the message 'No Ethernet Found' in the start up sequence. I would like to get ethernet working but I have been unable to find out what I should do so it happens.
When I used a pristine copy of u-boot, it wouldn't build for this target (couldn't make .depend in the cpu/ixp/npe directory or something similar). Since I had been building (snapgear) Linux using the Intel Open Access Library I copied IxNpeMicrocode.c from IPL_ixp400NpeLibrary-2_0.zip [ie version 2.0 of the NPE Library] into the cpu/ixp/npe directory. Admittedly this was just a guess as to what to do. U-boot now builds OK for this target, and I now have it running, but without ethernet.
Is there some doco somewhere that explains what to do next, or does someone have some insights to offer?
Thanks
Jonathan Pratt Senior Development Engineer
ELPRO Technologies Pty Ltd "Wireless Solutions Since 1983"
Hi Jonathan,
Jonathan Pratt a écrit :
When I used a pristine copy of u-boot, it wouldn't build for this target (couldn't make .depend in the cpu/ixp/npe directory or something similar). Since I had been building (snapgear) Linux using the Intel Open Access Library I copied IxNpeMicrocode.c from IPL_ixp400NpeLibrary-2_0.zip [ie version 2.0 of the NPE Library] into the cpu/ixp/npe directory. Admittedly this was just a guess as to what to do. U-boot now builds OK for this target, and I now have it running, but without ethernet.
You may check the Image Identifier in IxNpeMicrocode.c and be sure it's the same as in the defines in include/IxNpeMicrocode.h else the microcode search will fail and the NPE won't be loaded.
Eric
Hi Jonathan,
On Wednesday 09 May 2007, Jonathan Pratt wrote:
I have a IXP425 (IXDPG425 dev board) running u-boot [yay!] but I get the message 'No Ethernet Found' in the start up sequence. I would like to get ethernet working but I have been unable to find out what I should do so it happens.
When I used a pristine copy of u-boot, it wouldn't build for this target (couldn't make .depend in the cpu/ixp/npe directory or something similar). Since I had been building (snapgear) Linux using the Intel Open Access Library I copied IxNpeMicrocode.c from IPL_ixp400NpeLibrary-2_0.zip [ie version 2.0 of the NPE Library] into the cpu/ixp/npe directory. Admittedly this was just a guess as to what to do. U-boot now builds OK for this target, and I now have it running, but without ethernet.
Is there some doco somewhere that explains what to do next, or does someone have some insights to offer?
Did you set the "ethaddr" environment variable? If not, please do and reset the board after saving it. Could be that the driver only enables the interfaces when ethXaddr is set.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk Office: Kirchenstr. 5, D-82194 Groebenzell, Germany =====================================================================
Thanks.
For future reference, the ethernet mac id (ethaddr) needed to be set...
Jonathan Pratt Senior Development Engineer
-----Original Message----- From: Stefan Roese [mailto:sr@denx.de] Sent: Wednesday, 9 May 2007 7:53 PM To: u-boot-users@lists.sourceforge.net Cc: Jonathan Pratt Subject: Re: [U-Boot-Users] IXP425 ethernet & NPE microcode
Hi Jonathan,
On Wednesday 09 May 2007, Jonathan Pratt wrote:
I have a IXP425 (IXDPG425 dev board) running u-boot [yay!]
but I get
the message 'No Ethernet Found' in the start up sequence. I
would like
to get ethernet working but I have been unable to find out what I should do so it happens.
When I used a pristine copy of u-boot, it wouldn't build for this target (couldn't make .depend in the cpu/ixp/npe directory or something similar). Since I had been building (snapgear)
Linux using
the Intel Open Access Library I copied IxNpeMicrocode.c from IPL_ixp400NpeLibrary-2_0.zip [ie version 2.0 of the NPE
Library] into
the cpu/ixp/npe directory. Admittedly this was just a guess
as to what
to do. U-boot now builds OK for this target, and I now have it running, but without ethernet.
Is there some doco somewhere that explains what to do next, or does someone have some insights to offer?
Did you set the "ethaddr" environment variable? If not, please do and reset the board after saving it. Could be that the driver only enables the interfaces when ethXaddr is set.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk Office: Kirchenstr. 5, D-82194 Groebenzell, Germany =====================================================================
In message 7EDC24AB1ED682439657D3B7790609D39397CC@deepthought.Elpro.local you wrote:
similar). Since I had been building (snapgear) Linux using the Intel Open Access Library I copied IxNpeMicrocode.c from IPL_ixp400NpeLibrary-2_0.zip [ie version 2.0 of the NPE Library] into the cpu/ixp/npe directory. Admittedly this was just a guess as to what
Note that you cannot do this because of license conflicts.
Best regards,
Wolfgang Denk
Hi Wolfgang.
Is there another way of providing ethernet support for this platform without the license violation? Are there any legal ramifications that follow? (Are they more likely to come from Intel or elsewhere?)
It seems that u-boot wouldn't build until I added the file (I suppose that I could have tried disabling ethernet)...
Jonathan Pratt Senior Development Engineer
-----Original Message----- From: wd@denx.de [mailto:wd@denx.de] Sent: Thursday, 10 May 2007 8:37 AM To: Jonathan Pratt Cc: u-boot-users@lists.sourceforge.net; Stefan Roese Subject: Re: [U-Boot-Users] IXP425 ethernet & NPE microcode
In message <7EDC24AB1ED682439657D3B7790609D39397CC@deepthought.Elpro.loca l> you wrote:
similar). Since I had been building (snapgear) Linux using
the Intel
Open Access Library I copied IxNpeMicrocode.c from IPL_ixp400NpeLibrary-2_0.zip [ie version 2.0 of the NPE
Library] into
the cpu/ixp/npe directory. Admittedly this was just a guess
as to what
Note that you cannot do this because of license conflicts.
Best regards,
Wolfgang Denk
-- DENX Software Engineering GmbH, CEO: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de Let's say the docs present a simplified view of reality... :-) - Larry Wall in 6940@jpl-devvax.JPL.NASA.GOV
Hi Jonathan,
Is there another way of providing ethernet support for this platform without the license violation? Are there any legal ramifications that follow? (Are they more likely to come from Intel or elsewhere?)
It seems that u-boot wouldn't build until I added the file (I suppose that I could have tried disabling ethernet)...
Take a look at the www.nslu2-linux.org project.
The NSLU2 is a Linksys USB network storage device. It has the same issue with IXP4xx Intel firmware.
The Slug's, as they are fondly referred to, use RedBoot as a bootloader, and there exist various Linux kernels.
Look around the NSLU2 web site for comments on the Intel firmware. If there is nothing definitive there, I recall Rod Whitby posted messages to the nslu2-linux newsgroup explaining the requirements; check the archives, or join the group and ask Rod directly.
I haven't looked into the details, but I figured you might not be aware of the project, so this might help.
Regards, Dave
-----Original Message----- From: David Hawkins [mailto:dwh@ovro.caltech.edu] Sent: Thursday, 10 May 2007 9:16 AM To: Jonathan Pratt Cc: u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] IXP425 ethernet & NPE microcode
Hi Jonathan,
Is there another way of providing ethernet support for this
platform
without the license violation? Are there any legal
ramifications that
follow? (Are they more likely to come from Intel or elsewhere?)
It seems that u-boot wouldn't build until I added the file
(I suppose
that I could have tried disabling ethernet)...
Take a look at the www.nslu2-linux.org project.
The NSLU2 is a Linksys USB network storage device. It has the same issue with IXP4xx Intel firmware.
The Slug's, as they are fondly referred to, use RedBoot as a bootloader, and there exist various Linux kernels.
Look around the NSLU2 web site for comments on the Intel firmware. If there is nothing definitive there, I recall Rod Whitby posted messages to the nslu2-linux newsgroup explaining the requirements; check the archives, or join the group and ask Rod directly.
I haven't looked into the details, but I figured you might not be aware of the project, so this might help.
Regards, Dave
Thanks, David.
I was not aware of the project. They merely point out that it's a necessary evil. The Intel redistribution restrictions seem rather draconian, however.
I'm not sure about the conflict with u-boot (GPL), however, and whether the issues are more than philosophical.
Jonathan Pratt Senior Development Engineer
On Thursday 10 May 2007, Jonathan Pratt wrote:
I was not aware of the project. They merely point out that it's a necessary evil. The Intel redistribution restrictions seem rather draconian, however.
I'm not sure about the conflict with u-boot (GPL), however, and whether the issues are more than philosophical.
You can include the NPE binary into U-Boot as you did, but this violates the GPL and therefore you are not allowed to ship products using this resulting image.
The best solution for this problem right now, if to not included the NPE binary in the U-Boot build process, but program it into a separate FLASH sector, and let the NPE ethernet driver load the NPE's with the binary from this location. This way we don't have link the NPE binary into the U-Boot image. Unfortunately nobody found the time to implement this solution till now.
And furthermore, it would be very desireable to drop the current NPE U-Boot ethernet driver implementation based on the original Intel code with the complex and ugly Intel access library completely, and re-implement the driver based on the new Linux IXP4xx NPE ethernet drivers. There are currently 2 completely new drivers without the Intel access library which will result in lower memory footprint and much less and cleaner code.
Patches welcome! :-)
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk Office: Kirchenstr. 5, D-82194 Groebenzell, Germany =====================================================================
On Thursday 10 May 2007 07:16:50 Stefan Roese wrote:
On Thursday 10 May 2007, Jonathan Pratt wrote:
And furthermore, it would be very desireable to drop the current NPE U-Boot ethernet driver implementation based on the original Intel code with the complex and ugly Intel access library completely, and re-implement the driver based on the new Linux IXP4xx NPE ethernet drivers. There are currently 2 completely new drivers without the Intel access library which will result in lower memory footprint and much less and cleaner code.
That would be Christian Hohnstaedt chohnstaedt@innominate.com's driver which is (afaik) in mainstream by now, and Krzysztof Halasa khc@pm.waw.pl's driver, which is newer. There's a discussion about these drivers on linux-arm-kernel.
Getting either of those drivers fixed up and pushed to u-boot would be great. Of course, one will still need to put the microcode somewhere else due to licencing, but that's a minor matter.
Øyvind Repvik nslu2-linux developer
On Thursday 10 May 2007, Øyvind Repvik wrote:
And furthermore, it would be very desireable to drop the current NPE U-Boot ethernet driver implementation based on the original Intel code with the complex and ugly Intel access library completely, and re-implement the driver based on the new Linux IXP4xx NPE ethernet drivers. There are currently 2 completely new drivers without the Intel access library which will result in lower memory footprint and much less and cleaner code.
That would be Christian Hohnstaedt chohnstaedt@innominate.com's driver which is (afaik) in mainstream by now, and Krzysztof Halasa khc@pm.waw.pl's driver, which is newer. There's a discussion about these drivers on linux-arm-kernel.
Yes, but IIRC the one from Christian never made it into mainstream. And the new one from Krzysztof seems to get quite good reactions.
Getting either of those drivers fixed up and pushed to u-boot would be great.
Yes, both would be way better than the current implementation. Hopefully one of those drivers will make in into mainline and this should be the one to pick then.
Of course, one will still need to put the microcode somewhere else due to licencing, but that's a minor matter.
Yes, just a minor issue from the code point of view, but a big issue from the licensing point of view.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk Office: Kirchenstr. 5, D-82194 Groebenzell, Germany =====================================================================
participants (6)
-
David Hawkins -
Eric BENARD -
Jonathan Pratt -
Stefan Roese -
Wolfgang Denk -
Øyvind Repvik