I've just finished building our first rev of our 5282 product which places the
5282, RAM and ROM on-board. I'll be powering it up on Monday to start some
basic, basic testing.
Up until this point, we've been using Arcturus Networks' excellent uCdimm5282.
Of course, it has the uCbootloader fir
I have a MCF5282 design which utilizes two 128mbit (1meg x 32 x 4) DDR SDRAM
devices from Micron (MT48LC4M32B2TG). I've got an 80MHz clock and I'm pretty
sure I've got the SDRAM controller in the 5282 configured correctly:
DCR = 0x013f
DACR0 = 0x20001300
DMR0 = 0x0fc1
[pause]
DACR0 = 0x2000
On Wednesday 14 March 2007 7:35 pm, David McCullough wrote:
> If you boot te hsystem is a configuration that doesn't use much RAM and
> don't start and nasty big apps is the system idle (ie kswapd is
> behaving). If so what triggers it's rampage ?
I'd noticed this too (page_alloc2() high CPU use)
On Tuesday 01 May 2007 9:15 am, Ferry de Groot wrote:
> I've allready changed the flash bit width to 32-bit in block devices or do
> i need to make more specific changes. Erasing an sector seems to work
> almost fine. Except that it didn't fully erased the full memory range.
Assuming you changed
On Wednesday 02 May 2007 4:37 pm, Ferry de Groot wrote:
> Could you be more specific where I can find the CSAR in uClinux. So far as
> I saw these SDRAM initillisation were handled within DBUG. I've changed
> this part for DBUG bootloader, but not for uClinux unless this part is not
> needed.
You'
We all know that gdbserver's thread support is in the toilet, but I'm
wondering what the gurus do when it comes to trying to debug threaded
programs remotely.
The best idea I had on the matter was to have each thread call a dummy
function, stupid_gdbserver_hack(), which I could break on as gdbs
On Thursday 16 August 2007 1:46:24 pm Daniel Berenguer wrote:
> Ok, I've tried receiving a bunch of messages at the same time with the
> same result: CAN RX buffer overrun.
>
> MCF5282 + uClinux + can4linux v3.0 works well with a bus load under 3 %.
> Above that the "overrun" error appears.
>
> Sho
Good afternoon, everyone,
I've got a strange little scenario and I am wondering if I am alone, or just
doing something wrong.
MCF5282 system, running 2.4.31-uc0. If I boot with root=/dev/nfs, I can
netflash /dev/mtd1 and /dev/mtd2 (partitions on a 28F256P33T wired to #CS0).
If I have root=/d
On Friday 17 August 2007 12:23:09 pm Crane, Matthew wrote:
> You can chroot to a different root and then flash the device. Is rom1
> on the same 28F256P33T device?
I ended up using /dev/rom1 as the root filesystem since the kernel seemed
confused when I said /dev/mtd1. There are two flash devic
On Friday 17 August 2007 3:43:06 pm Crane, Matthew wrote:
> It doesn't have to be a mtd partition, it could be a tmpfs. Maybe you
> could pass mtdblock1 or the device number instead of mtd1 to get it to
> boot unconfused.
Yeah, it seems really strange that netflash has provision for reflashing a
On Friday 30 November 2007 08:29:07 Greg Ungerer wrote:
> I am sure some people will stand up and say threads work great
> for them on specific architectures.
Yes; custom MCF5282 design using an old (Arcturus-branded) uClinux-dist with
2.4.31-uc0. The main application is a communications bridge
On Wednesday 05 December 2007 10:54:42 Michael Schnell wrote:
> > However, I really do need to generate a break when the kernel performs a
> > memory access in the adress range 0x to 0x0080.
>
> Why do you think that such is possible ? A break on memory access to
> address ranges needs
On July 7, 2008 11:41:05 am Daniel Berenguer wrote:
> I'm trying to send/receive messages via RS485 using a simple MAX485 IC
> connected to a Netarm processor (Digi Connect-ME). The problem is that I
> need to enable/disable the transmit option through the UART RTS line but
> RTS remains high after
On July 8, 2008 11:53:32 am Chris Doré wrote:
> I'd probably just add an IOCTL allowing the feature to be enabled/disabled
> by an app. You may have to worry about other code touching that register
> and wiping out your RTSTX bit, depending on if that code blindly writes
> values to the reg or if
On July 9, 2008 01:06:47 pm Chris Doré wrote:
> I've never used MCFUART_UOP_RTS. You have to reset it every time you
> transmit?
Yes.
> In the case of the netarm, you need only set RTSTX once and it will toggle
> RTS active/inactive as necessary.
It's been over 2 years, but I don't think that t
On November 25, 2008 12:39:52 pm Allon Stern wrote:
> I have a device driver which works just fine on the pxa270 (2.6.26
> linux)
> In trying to get it working on the MCF5282, I find I get a bunch of
> interrupts recorded when in reality I should only have one.
> I see 44 interrupts instead of 1 (w
On December 9, 2008 05:29:11 am Frédéric DUBOIS wrote:
> We plan to double up the SDRAM size of our 5272-based board. It would be
> more convenient for us that the kernel automagically detects the size of
> the installed RAM instead of managing two different kernels or bootloaders;
> it would also
Good afternoon,
I've been asked about designing a board which can handle three USB2-to-VGA
adapters. I would be running X11 and just using the adapters as displays,
but I'm unsure about the actual bandwidth requirements for these things.
Has anyone used them before? They'd only be displaying
On March 28, 2008 12:13:57 pm David Harel wrote:
> When compiling for 3com (Vendor: 3com, Product to target: Xcopilot) I get:
> arch/m68knommu/platform/68328/ints.c:128: error: conflicting types for
> 'request_irq'
> include/linux/interrupt.h:82: error: previous declaration of
> 'request_irq' was h
On April 17, 2008 12:43:37 pm Jamie Lokier wrote:
> > Video streaming i would consider a large scale system. Why was a non
> > MMU processor selected for a video streaming application?
>
> Price and availability of a chip that did good video (HDTV even), and
> we didn't know the no-MMU penalty at
On December 22, 2009 11:11:30 am David Wooff wrote:
> It's slightly complicated because my FPGA is effectively a bridge to a
> number of hot-pluggable
> backplane I/O cards. It seems to me that I should probably attempt to
> structure it (the FPGA and backplane)
> as a bus with I/O card devices ha
On Thursday 01 April 2010 01:36:52 pm Fabio Giovagnini wrote:
> I' have connected my SCIF1 port (of sh2a 7203) to a MAX485, and the
> TXEn/!RxEn to an I/O port.
> I had the idea to write a driver for proc FS to manage the TxEn/!RxEn line
> and using the ttySCx driver to send and receive data at 3
On Thursday 01 April 2010 01:48:21 pm Lennart Sorensen wrote:
> Yeah I have only ever done it using a UART that can automatically control
> the direction based on the transmit FIFO containing data or not (with
> a programable delay before switching of the transmitter of course).
> I would hate to
On Thursday 01 April 2010 09:38:15 pm Philippe De Muyter wrote:
> We use a pure user-level solution with
>
> ioctl(fd, TIOCMBIS, TIOCM_RTS);
> /* wait some delay or rely on a CTS */
> write(fs, message, message_len);
> /* eventually wait for a message_len based delay*/
>
On Tuesday, July 06, 2010 11:26:04 pm Alexey Goncharov wrote:
> > Did you try "fflush()" after the "write()" syscall?
> fflush() is supposed to be used in combination with fwrite(), so.. i didn't
Ok, fine, did you try opening the deivce with O_SYNC to not return until the
data hits the port or wi
25 matches
Mail list logo
