• Home
  • Help
  • Search
  • Login
  • Register
  Show Posts
Pages: [1] 2
1  Hardware and U-Boot firmware / U-Boot stuff / Re: uboot-envtools on: September 21, 2009, 01:16:21 AM
Hi all,

are there any news regarding this issue?

Many thanks,
Dieter
2  Linux Stuff / Kernel / Re: compiling 2.6.30 kernels for openrd on: July 28, 2009, 04:27:09 AM
Hi Dhaval,

are there any kernel / u-boot patches for openrd allready available? Have had a look at marvell git and there are no commits for openrd for now.
I'm willing to work as beta tester ;-)

Many thanks,
Dieter

To add:

Expect OpenRD support in mainline in next 2 weeks.

- Dhaval
3  Linux Stuff / Kernel / Re: Feature Request: USB driver handle overcurrent events; power on/off USB load sw on: June 30, 2009, 12:51:22 PM
Hm, read a bit in usb-devel mailin list archives.
It seems that linux usb stack doesn't care about overcurrent conditions.
http://kerneltrap.org/index.php?q=mailarchive/linux-usb-devel/2007/5/25/338088/thread
Maybe thats why no ehci driver cares about that???


Hi to all,

it would be very nice if the linux driver (ehci-orion) would support USB over current events and handles power on / off USB load switch on driver init /exit.
Are there any plans regarding this issues?

Thanks,
Dieter

4  General Category / General Discussion / Re: Plug Pictures on: June 30, 2009, 11:39:32 AM
Thanks a lot for Smiley
Dieter
are there framebuffer or X drivers available for the DisplayLink DVI adapters?

Sure. The development is happening on the libdlo mailing list.
A (currently) faster console alternative is my SlugTerm DL.
5  General Category / General Discussion / Re: Plug Pictures on: June 30, 2009, 09:53:39 AM
Sonic,

are there framebuffer or X drivers available for the DisplayLink DVI adapters?

Dieter

Sven - the plug looks really tiny near your 1080p screen.

The plug's @ 1920x1200. On the left is the Windows PC @ 2560x1600. No DisplayLink dual link DVI adapters yet  Roll Eyes
6  Linux Stuff / Kernel / Feature Request: USB driver handle overcurrent events; power on/off USB load sw on: June 30, 2009, 06:16:21 AM
Hi to all,

it would be very nice if the linux driver (ehci-orion) would support USB over current events and handles power on / off USB load switch on driver init /exit.
Are there any plans regarding this issues?

Thanks,
Dieter
7  Hardware and U-Boot firmware / Hardware / Re: USB in client mode on: June 26, 2009, 11:26:44 AM
AFAIK there is a bus power load switch on the plug - at least at my hardware revision.
So it shouldn't be so hard to disable bus power if driver loads in device mode?

Dieter
well, i think software wise it's doable.
The only thing I would be afraid of giving such a method to newbies and they might accidently not tweak the Vbus voltage that the plug provides (since it's default is host) and might do some short circuit between a plug and a host PC.

8  Hardware and U-Boot firmware / Hardware / Re: Can the SheevaPlug be copied ? Is it FLOSS ? on: June 26, 2009, 11:11:58 AM
If the chips than you should have look for local distributors. Here in germany it is avnet memec. Maybe in the whole EU?
Dieter

You mean you want to buy SHPG in hundreds of quantity? Or the Kirkwood SoC?

If the plug then I suggest you contact Global Technologies (GTI) for that.

9  Hardware and U-Boot firmware / Hardware / Re: Received Open RD client today on: June 26, 2009, 11:08:44 AM
I will have a look at the schematics next week and figure out if the open-rd is an "enhanced" sheeva or if it's more different.
My first try running an git u-boot aren't succesful. The openrd-base board hangs after init egiga0 interface.

Dieter
Just got my Open RD client today. Should we open an area in the forum for this new version of the Marvell SoC?

I think before a forum is started, we ought to flush out the differences.  Is it simply an enhanced version of the SheevaPlug so that topics applying to certain components would apply to both platforms?  If so, then the forum should be carefully planned so we do not have disparate threads of topics that deal with the same component or part.  Ideally, postings that apply to both are probably best kept in the SheevaPlug area, whereas posts that touch on something not available on the SheevaPlug out to be in the new forum, e.g. something to do with the two RJ12 jacks.
10  Hardware and U-Boot firmware / Hardware / Re: Received Open RD client today on: June 25, 2009, 01:33:06 PM
I've got my OpenRD Base, too.
Maybe a good idea Wink

Dieter
Just got my Open RD client today. Should we open an area in the forum for this new version of the Marvell SoC?
11  Hardware and U-Boot firmware / Hardware / Re: SheevaPlug v2 - Hardware Requests on: June 23, 2009, 11:41:35 AM
Hi restamp,

IFAIK NAND isn't a memory mapped flash like NOR. It uses a 8 Bit mulitplexd Data/Adress/Command Bus. So the NAND flash doesn't limit the DDR Memory on board.
And also DDR isn't directly memory mapped. You have much more signals like bank select and such things.
If you are interested you can have a look at: http://en.wikipedia.org/wiki/DDR2_SDRAM

Dieter

A couple of us SheevaPlug owners were discussing the Plug over lunch yesterday, and I made the same comment -- that a Gig of memory would be nice.  One of the other guys pointed out that he thought the Marvel chip only brought out 30 bits of address:  30 bits == 1 GB of addressable memory, so with 1/2 GB of RAM and 1/2 GB of NAND, they appear to be maxed out.

(E-)Sata would be nice, though.
12  Hardware and U-Boot firmware / Hardware / Re: SheevaPlug v2 - Hardware Requests - Power JTAG interface from USB VBUS? on: June 23, 2009, 12:30:26 AM
Hi marvell developers,

first please let me say that the sheevaplug is a very nice box.
One suggestion I would have:

Maybe it would make handling of the plug more ease if the jtag / console interface would be powered from USB VBUS?
This would preventing the serial ports from disappear if someone disconnects power from the plug.

Dieter
13  Hardware and U-Boot firmware / U-Boot stuff / Re: Upgraded to open u-boot -> tftp not working anymore. on: June 22, 2009, 11:11:28 AM
This issue is allready fixed by Prafulla.

Updated driver can be found here:

http://lists.denx.de/pipermail/u-boot/2009-June/054314.html



Hi,

are there any news regarding this toppic?
It seems my board has exactly the same problems.
Can I do anything to help debugging?

Remarks:
@Prafulla:
I've done a test as you mentioned a few lines above.
It seems that this is an issue regarding 100MBit/Gigabit.
If I use a 100MBit/s Switch the error is shown.
With a Gigabit uplink network seems to be working!

Thanks,
Dieter

Ack.
14  Hardware and U-Boot firmware / U-Boot stuff / Re: Upgraded to open u-boot -> tftp not working anymore. on: June 22, 2009, 07:47:13 AM
Hi,

are there any news regarding this toppic?
It seems my board has exactly the same problems.
Can I do anything to help debugging?

Remarks:
@Prafulla:
I've done a test as you mentioned a few lines above.
It seems that this is an issue regarding 100MBit/Gigabit.
If I use a 100MBit/s Switch the error is shown.
With a Gigabit uplink network seems to be working!

Thanks,
Dieter

Ack.
15  Hardware and U-Boot firmware / U-Boot stuff / Re: New U-boot features on: June 22, 2009, 12:03:02 AM
Hi Prafulla, hi Rabeeh,

from your point of view this is surely right.
Sadly, I don't know what the intention of the marvell.git u-boot is.
If you only want to support the sheevaplug than you're right. There is no need for any enhancements.
But for a hardware develpers purposes there is maybe something different.
I'm developing highly customized boards for industrial customers for a few years now (formerly based on TI DaVinci and Netsilicon ARM9 CPUs)
and there was always the need to bring up some hardware before you start the kernel. The alternative was to do the initialisation in early kernel init code
which isn't much fun for me and gives some other problems Smiley
So GPIO and legacy serial protocols like I2C and SPI are very helpful!
This gives you the change to do all the setup on board level by using well defined interfaces and no need to hack somewhere deep inside u-boot.
Which makes it more easy to keep your u-boot up to date with upstream.

So if Marvell plans to support industrial customers too it would be a good idea to also support some legacy protocols inside u-boot - as many other archs
do.
The main purpose of u-boot is surely to boot the kernel but sometimes it is also essential to bring up some hardware (like PLLs for example) before you boot
the kernel.

What do you think about that?
Dieter

Hi all,

I think, bootloader should be limited to it's objective , i.e. boot the kernel and rfs from supported media SF, NANDF (additional  MMC, or USB), any specific h/w usage should be ported on OS level, otherwise boot loader may be equally fat AS kernel :-)

Mostly this is the approach with the u-boot development.

At this moment it U-boot Kirkwood support enables SF,NANDF and network interface, USB will be anther useful interface in the pipeline,
Apart from this I don't think other things are really needed in u-boot.

Regards..
Prafulla . .
 
Pages: [1] 2